• Permalink

    Part 3: Software Development Life Cycle — The Solution Design

Part 3: Software Development Life Cycle — The Solution Design

The Solution Design stage begins upon Customer and stakeholder approval of the System Requirements Review (SRR) and its associated artifacts. Solution Design is specific to Scrum projects only. Design is not typically required for Kanban process cycles involving Problem Reports and smaller “break-fix” tasks. Partnet’s Solution Design stage consists of two elements: functional design and technical design.

Functional Design: User stories form the basis for functional design and planning. User stories are short, textual statements corresponding to a specific feature or business need that the software solution must fulfill. Requirement Managers write user stories based on the approved solution requirements. During functional design, user-story reviews are convened with members of the Delivery Team to formally discuss each user story in detail and specify its acceptance criteria. All outstanding questions and assumptions are documented for follow-up with the Customer and other external stakeholders. User stories are then allocated into specific development tasks and subtasks that constitute the Product Backlog.

Technical Design: In parallel with user-story reviews, our development and engineering group prepares the technical design solution. Aspects of the technical design include:

Analysis of necessary changes to the general solution architecture.
Review new interfaces for third parties.
Protection of system security posture.
Identification of required hardware components, operating systems, and network architecture.
Research supporting software technologies and libraries.
Determination of necessary changes to the data model(s).

Partnet convenes an internal design review to collect and incorporate final feedback on the designed solution from Software Developers, Test Engineers, Configuration Managers, Project Managers, security specialists, and support staff. This review focuses on specific items affecting the solution design, such as:

Ensuring the design minimizes development and maintenance costs.
Identifying opportunities for business-user configuration (i.e., administrative utilities that allow the Customer to configure and manage the software without new […]

  • Permalink

    Part 2: Software Development Life Cycle — Incorporating New and Emerging Requirements

Part 2: Software Development Life Cycle — Incorporating New and Emerging Requirements

Partnet’s development team understands that requirements are volatile by nature and are inevitably subject to change during the course of development. New and emerging requirements often occur as the result of unforeseen constraints, capability gaps, user implications, or newly-identified stakeholders. Our Agile methodologies provide the flexibility required to quickly and responsibly react to such changes without putting other priorities at risk.

New and emerging requirements should be presented to the Partnet development team by the customer in the form of a new or updated functional specification. Our Requirement Managers follow industry best practices to thoroughly assess all new requirements. Careful business analysis is performed to:

Determine any impacts to the existing system.
Identify the best implementation approach.
Mitigate risk to the customer and end users.

Upon identification of a new requirement, Partnet will work with the customer to define business objectives and desired outcomes. Requirement Managers will carefully assess the new requirement against the deployed defined or existing solution to:

Identify capability gaps.
Assess impact to current functionality.
Identify affected stakeholders.
Identify transition requirements.
Document risks and constraints.

Partnet Requirement Managers will present this assessment in the System Requirements Review (SRR). The SRR will document the stated, unapproved requirements along with a recommended implementation approach. Also, the Partnet Project Manager will identify the estimated cost and time necessary to implement the new requirement. Once the additional cost and time are approved by the customer, Partnet will follow its standard requirement procedures elicit, refine, and formalize the solution requirements. Requirement Managers thoroughly maintain requirements traceability to ensure that substantive changes are documented and versioned as new requirements are incorporated into the designed solution.

Partnet expects the customer to be a key stakeholder in the gathering and approval of all requirements—including new and emerging requirements. Consequently, the customer […]

  • Permalink

    Part 1: The Importance of a Defined Software Development Life Cycle

Part 1: The Importance of a Defined Software Development Life Cycle

I’ve been thinking lately about how important it is for a company to have a well-defined process for the Software Development Life Cycle, or SDLC as we like to call it. I’m going to do a series a blogs to share our SLDC process.

Partnet’s SDLC employs industry-best practices in accordance with Agile principles and methods. Our approach ensures that the right product is delivered in the required time frame, while providing visibility into the solution’s development. As part of our Agile Development approach, we employ both Scrum and Kanban methodologies.

Partnet’s SLDC is a multistage process. The first step in the SDLC is to make sure that each development projects start with stable, well-defined requirements. Our Requirement Managers use industry-best requirement management practices as defined by the Business Analysis Body of Knowledge (BABOK).

The requirements manager coordinates and schedules requirements gathering activities with each stakeholder group. These activities may take the form of interviews, video teleconferences, requirement workshops, questionnaires, or other forms of outreach. In some cases, multiple rounds of requirements gathering activities may be required as the results are documented and consolidated.

This step ends with the preparation of a formal requirements package. The requirements package describes desired outcome(s), assumptions, and constraints associated to a given business requirement. A requirements package may be presented in any number of formats, including but not limited to:

Functional specifications
Screen mockups and page wire frames
Flowcharts, sequence diagrams, data flow diagrams and other visual models
Data dictionary
Use cases and scenarios
User Roles
Goal or desired outcome
Benefit to the customers and stakeholders

The Partnet team completes the Requirements Step by meeting with the customer and other stakeholders to conduct a formal System Requirements Review. This involves distribution of the requirements package(s) for stakeholder approval. Signatures are collected […]

Are Government Agencies Drowning in Data?

Recently Federal Computer Week featured an article entitled: Why agencies are drowning in data. The article was based on a recent survey by Semantic Corporation on effective big data strategies. The survey found that that the main reasons for agencies feeling overwhelmed were data governance and data security. I think, however, they were asking the wrong questions.

The government is currently producing and making available huge amounts of data. I agree that this data needs to be kept secure and managed so it can be made available to the appropriate users. However, I think the bigger question is who is taking the time to look at the data and what are they doing with the information. Take acquisition data, for instance. There are volumes of data about what the government is purchasing, who in the government is making the purchases and what they are buying. Government analysts could be asking questions like:

Are we getting the best price possible on specific commodities?
Does one agency negotiate better prices than other agencies?
Why don’t we all get those good prices?
Which contract vehicles are most cost effective?
Is lowest price always the best answer?
Do we get more returns on commercial items that were purchased due to lower prices?

The list could go on and on. The problem is that no one is really looking at the data — truly analyzing it. Analysis of this type is very common in the private sector as businesses try to understand where they fit in a marketplace and how to make their supply chain run more efficiently. Government employees do not look at themselves as running a business.  They are always looking for cheaper prices and more efficient business practices, but often do not have the […]

Communicating with the Government Round-Up

Last month my colleague Gabrielle Zimmerman wrote a two-part blog series on Communicating with the Government. I put it out for discussion on LinkedIn asking for people’s experience with communicating with government and learned a lot.

eCommerce for Government IS Different

The differences between government eCommerce and eCommerce for commercial business might be difficult to notice at first glance, but these differences are key to a successful government eCommerce solution.

Customers Voice High Praise for DOD EMALL

The DOD EMALL Program Office at the Defense Logistics Agency Headquarters recently sent a survey to customers asking the impact to their mission if DOD EMALL were no longer available. The application received high praise from the users. Here are just a few of their responses.

DLA Land and Maritime

“If we were to lose access to DOD EMALL Tire corridor, it would have a significant negative effect. Currently we use the website to validate NSN’s sources of supply for all DOD buyers and we provide our customers with validated spec sheets that they can use to verify the accuracy of the product they have received. There is no other database that will give me this ability. I am in that database every day reviewing, updating or retrieving data for a customer or a buyer. This section of the DOD EMALL has allowed other organization (TARDEC/TACOM) to easily assist with research and identify inconstancies with the data so that I can properly maintain the NSN’s through the cataloging actions. This is the best way for all organizations to see the same information on one system.”

DLA HQ

“It would make a big impact, I support 26 offices, so it would slow down our supply for the DLA offices I support.”

Magellan Aerospace

“As a broad stroke perspective from Procurement, lead time would be the greatest impact to our delivery schedule. The material purchased through DOD EMALL is not readily available on the open market or the OEM in most instances. GEAE is our main repair line, lead times ranging up to 725 days.”

USAF AFMC – Robins Air Force Base

“EMALL is very important to us at the F-15 SPO. We have a contract with Korean Air Lines (KAL) to complete the Programmed Depot Maintenance (PDM) on the USAF F-15s stationed at Kadena AS, Okinawa, […]

Government Acquisition Players Benefit from eCommerce

No matter whose perspective you use, eCommerce is a good idea for government acquisition. Unfortunately it is a much underutilized tool in the government acquisition tool box. Why do you think the federal government has been slow in utilizing this technology that has been around for almost 20 years?

B2B VS B2G: How eCommerce Can Save the Government Money

Business to Business (B2B) markets have impacted the business community for a number of years now. Their positive impact on the economy is evident in several ways.

6 Things You Didn’t Know About DOD EMALL

DOD EMALL is the one-stop shopping, enterprise-wide eCommerce site for the Department of Defense. The eCommerce site supports over 30 Million SKUs and has 40,000 active users, but that’s just scratching the surface. While DOD EMALL can be used to purchase everything from office supplies to weapon system parts, there are a number of other useful features that you might not be aware of within DOD EMALL.

DOD EMALL supports contracts from all the military services, the Department of Homeland Security, Defense Commissary Agency (DECA), GSA and as well as the Defense Logistics Agency (DLA). Any Federal agency with an IDIQ or BPA contract can place it on DOD EMALL. At this time, there is no charge for this service. This is an excellent opportunity for smaller agencies to have their own eCommerce site without the investment.
DOD EMALL makes it easy to support a large group of people with their acquisition needs. If your office has a single purchase cardholder and many personnel with purchasing needs but not purchasing power, DOD EMALL can help you support your staff. Agency personnel can register with DOD EMALL as a Shopper. Shoppers have the ability to complete all their shopping, but not the ability to purchase. Staff members without purchasing power can still build a virtual cart filled with the items that they want, but instead of completing the order, these Shoppers simply send their virtual cart to the office purchase cardholder. The purchase cardholder has the ability to merge multiple shopping carts together to consolidate buys while still retaining the individual details of the orders. This way, when the order comes in, they can easily sort out who ordered what. This is an incredibly convenient way to […]

Google+