SSI understands and uses a 'best practices' methodology that conforms to recognized industry best practice principles for custom software development projects. SSI has adopted a custom software project engineering methodology that is repeatable and under management control. This methodology is based on the CMM Level 2 for software engineering and is divided into 5 Key Process Areas (KPAs) - 1. Requirements Management; 2. Software Project Planning; 3. Project Tracking and Oversight; 4. Software Quality Assurance; and 5. Software Configuration Management.

Requirements Management

The critical area of the Requirements Management KPA is the establishment of a requirements baseline and a process for managing change in requirements over the lifecycle of the project. SSI's software project engineering methodology employs an evolutionary process to establish the software requirements baseline. The first step in this evolutionary process is the Project Assessment and Scope Definition. In this stage, the high level customer needs are identified through a series of meetings and discussions with the key customer project stakeholders. Questions such as "What are the operational goals of this project? What current problems are we trying to solve? And, what is the success criteria for determining if we have been successful with this project?" are asked and answers are documented. The identified needs, goals, and success criteria are reviewed with the customer project stakeholders and prioritized. Then, SSI works with the project stakeholders to determine which of the identified needs and process areas will be addressed by the project. This becomes the Project Scope document. The scope document defines the concept and range of features of the proposed project.

The second step in the development of a software requirements baseline to expand on the project scope and develop a set of functional requirements for the software project. This set of functional requirements is a non-technical description of the software functionality that is required to meet the project's scope. This will result in the identification of one or more key functional areas. Each key functional area will be decomposed into detailed functionality. Each functional requirement (i.e. "the system shall provide the ability to report on expected mean time between failure for all equipment tracked by the system") must be traceable back to the scope established in the first step (scope statement example - "The planned system will automate the reporting of equipment metrics. Currently, these reports are labor intensive to generate and there is a high probability of error. This feature will allow the organization to realize greater labor usage efficiencies and information accuracy.") The scope document enables SSI and the customer to assess whether proposed functional requirements are appropriate for inclusion in the project. If a functional requirement cannot be traced back to one of the major features stated in the scope document, it should not be included in the functional requirements document. This second step can be expanded to a full system requirement if the proposed project will include new hardware, integration of disparate systems, or if the software project is only a part of a much larger system engineering project. A system requirements document will describe the required interaction between system components (hardware, other computer systems, mechanical devices, etc.) and the software project.

The third and final step in the development of a software requirements baseline is to decompose the functional requirements document down into very specific and discrete software requirements. The software requirements state exactly what the planned software project will do for the users of the system. During this step, SSI software engineers work with the customer stakeholders to decompose the functional requirements into specific software requirements. Before the software requirements baseline is finalized, software engineers review the requirements to ensure that the stated requirements can be implemented. Upon agreement on the requirements, a baseline is established.

From this baseline, all modifications to the software requirements must be made through the Software Requirements Change Process (SRCP). This process requires that the person proposing a Software Requirement Change (SRC) to do so in writing. The SRC is reviewed by the software project manager and the change is assessed for its impact to the project in terms of both cost and schedule. If both the cost and schedule impact are accepted by both the customer and SSI, the SRC becomes a part of the software requirement specification (SRS) and is reflected in the Software Design Document (SDD). In order to maintain version control of the SRS and SDD, the software requirements baseline is always preserved. Each SRC that is approved, and incorporated into the SRS and SDD, receives a new revision number and the revised SRS and SDD are also assigned this revision number. Additionally, the updated project plan that reflects the WBS task and schedule changes is assigned the same revision number. This allows each SRC to be tied to the revised SRS and project plan that resulted from the SRC. This process is repeated throughout the project as new SRCs are accepted into the system.

The Software Design Document (SDD) is also a key component of the Requirements Management process. While the SRS defines "what" the software must do, the SDD defines "how" the system will be designed to meet the SRS. The SDD is comprised of the software application's user interface, output contents and formats, and the database design specifications. Each element of the SDD must be linked back to a specific numbered paragraph in the SRS. This enforces the project's lifecycle tracability: each SDD element must trace directly to one or more SRS paragraphs and each SRS paragraph must trace directly to a key functional area of the project scope document. SSI uses the Rational Requisite Pro requirements management tool to enforce this tracability and as the final repository for the SRS and the SDD.

Software Project Planning

The Software Project Planning key process area focuses on the establishment of project tasks, task execution estimates, and a commitment to the task estimates by the software project team. Microsoft Project is used to document the software project tasks and develop a numbered Work Breakdown Structure (WBS). Project tasks are grouped into phases that include both the development of the software (requirements, design, development, and testing); the implementation of the software (installation, acceptance testing, and training), and continuous project management/engagement coordination. Each task in the WBS is assigned a time estimate expressed in hours or days. As a general rule no single task is permitted to have a time estimate greater than 40 hours/5 days. This ensures that potential problems/risks on a given task can be surfaced within a week's time, and therefore allowing project management to take corrective actions. The task estimates are reviewed with the software project team to obtain commitment to the estimates. This is a key step in the Software Project Planning KPA - the project team must commit to the task estimates in order for the project plan to be meaningful and executable. Without this commitment from the software project team, the initial plan is flawed. Once agreement on the tasks, their estimates, and a commitment to their execution is obtained, the project plan baseline is established within MS Project by storing the project plan baseline. As the project plan is executed, this baseline will be used to assess project status and progress. The final activity in this KPA is to establish a discrete project task number for each task in the project plan and reflect this task number in the SSI Project and Timesheet Tracking system. Project team members will use the task number assigned to the project tasks that they are working on when they record their work time. This becomes the basis for the next KPA - Project Tracking and Oversight.

Project Tracking and Oversight

The Project Tracking and Oversight key process area provides visibility into activities and status of the project itself. As software project team members execute their assigned tasks, actual results and performance are tracked against the software project plans. As the project proceeds, corrective actions are taken and managed to closure when actual results and performance deviate significantly from the project plan. Changes to project tasks commitments are agreed to by the affected team members and reflected in revisions of the software project plan. This process continues in an iterative fashion through the project completion and closeout.

Software Quality Assurance

Under the Software Quality Assurance (SQA) key process area of the Capability Maturity Model for Software, adherence of software work products and activities to the applicable programming standards, procedures, and requirements is verified objectively. The SQA team takes the software requirements specification and the defined general software development standards as a baseline to formulate the quality assurance testing plan for the software project. Using the SRS document, test cases are developed. These test cases are designed to verify that the software project is satisfying each of the requirements. Using software test management tools such as Rational's Test Manager each requirement defined in the SRS is linked to a specific set of test cases. These tools provide an automated method to verify that each requirement is represented by one or more test case. The development of the quality assurance test plan begins early in the project cycle, generally during the software design process. By starting the test plan process during software design, the early identification of faulty designs can be uncovered. When this occurs before actual software development begins, major project problems can be avoided at latter stages of the project. Additionally, the early development of the quality assurance test plan and test cases can uncover the need to expand or modify the software requirements. When this occurs, the requirements changes are handled via the Software Requirements Change Process, as described in the earlier discussion under Requirements Management. Prior to the completion of the quality assurance test plan and test cases, a thorough review is performed. This review verifies that each test case links back to a specific requirement and that the test case is able to verify that the requirement is met by the software. This ensures that the test plan has full tracablity back to the requirements. Additionally, the overall test plan is reviewed for logical completeness and acceptance within the total project plan.

As software development gets underway, execution of the test plan begins in parallel. By starting the system testing as software components are completed, early software bugs or non-conformance to the requirements are identified at the earliest possible stages. This allows for the early correction and modification to the software and before other dependent software components are developed, thereby saving the project significant time and effort in later project code rewriting and modifications.

As the project proceeds, the software development team is informed of the testing progress and results. Where necessary, the software development team can adjust its efforts as needed in order to ensure that the software work products are passing the test cases and meeting the requirements. Testing results are documented and shared with the project team. As software errors are found and corrected the quality assurance team must perform regression testing of any previously tested software components that might be effected by the corrected software code. This ensures that later bug fixes do not introduce problems in previously tested areas of the software project.

Software Quality Assurance is completed when the software satisfies all system test cases and the test plan has been executed to its completion. It is important to note that this process cannot be completed until all software coding has been completed.

Software Configuration Management

Under the Software Configuration Management key process area, SSI utilizes software configuration management tools to control the software product through its development lifecycle. Configuration management refers to control of the product, whether the final deliverable or an interim project artifact. As software code is completed and ready for testing, a version is assigned and the code is stored within a configuration management repository. This repository organizes all code modules into their identified versions. This allows for a full tracking of the versions of the software and the changes implemented between on version and another. This configuration management process can be a critical resource to the Software Quality Assurance team during regression testing when it uncovers errors in software components that were previously tested successfully. By having the version control of configuration management, the testing team can trace back through the revisions to discrete software components to determine what code changes caused the problem. SSI has used automated software configuration management tools such as SourceSafe and CVS to manage the version control process during its software development projects.

This methodology allows SSI to consistently deliver custom software development projects on time, within budget, while meeting the customer’s functional requirements.