Custom Software Development
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.
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.
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.
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.
|Home | IT Consulting | Custom Software Development | Engineering Services | Business Re-Engineering | About Us | Contact Us | Employee Menu | CSS Menu by OpenCube|