Software Development Process : Navigation Tree

Bread Crumbs: Main Page
Navigation Tree PNG
The software development process is a prescribed ordering of activities governed by guidelines and structured by templates and tools that produces a product in a consistently repeatable manner. Requirements engineering assesses the feasibility of a project and if deemed feasible, gleans precise and accurate requirements which, when fulfilled, culminate in the correct system for the customer. Requirements verification and validation requires reviewing requirements according to an inspection checklist in order to evaluate the correctness of their attributes. Rejecting a requirement requires the reviewer to clearly indicate the reason the requirement is being rejected. A requirement that has errors can still be accepted pending correction of the identified errors. By contrast, a rejected requirement is altogether incorrect. A requirement may be accepted or may be accepted pending the correction of noted errors. This requirement will become an official part of the SRS. Architecture design and detailed design are two fundamental facets of system design. Architecture design is more abstract than detailed design and it specifies the fundamental structure and patterns of the system under development. Detailed design focuses on all of the implementation details necessary to implement the architecture that is specified. Design verification and validation requires reviewing the design artifacts according to an inspection checklist in order to evaluate the validity of the design and verify its correctness. Implementation is the creation of source code from the design artifacts. Implementation involves peer reviewing source code and addressing all review findings. Implementation also requires the use of build tools to create binary files that are executable on the target. Implementation also encompasses unit-testing the source code as it is being developed and fixing defects as they are discovered. Testing along with code reviews verify the correct functioning of the components according to the design as well as valid functioning of the components according to the requirements and system model. Maintenance is the manifestation of the organization's commitment to the customer. Typical maintenance activities include providing fixes for reported errors and providing fix packs or incremental maintenance releases to deploy accumulated error fixes to the install base. Depending on the number of options and the complexity of the analysis necessary, assessing feasibility can range from just answering a few questions to make the assessment to using a mathematically rigorous decision analysis process like AHP (Analytic Hierarchy Process). Eliciting the requirements requires getting questions answered. An interview questionnaire is an effective way to accomplish this task. Once the raw information from the customer is available, accurate and precise requirements must then be distilled out of that raw information. This will require using a system model to abstract the behavior of the desired system so that customer consensus can be obtained. All of this work will culminate in the creation of a vision document. Requirements are first stated in prose. They are then elaborated using requirement specification templates. The Systems Requirement Specification (SRS) document contains all of the official system requirements. On some projects, this might only be a section of a larger project document. On yet other projects, this might be a requirements database that can generate an extract of all requirements as a report at any time. For this software development process, the system specification artifact is a document that captures development artifacts generated during requirements engineering phase that will be instrumental to the later development phases. The architecture design of the system will have a large impact on the system's ability to fulfill both functional and non-functional requirements. The correct design patterns, mechanisms, and technology must be specified in the design of the architecture. Interface design of the system needs to stabilize very early in the development process in order to begin creating the stubbed-out function tests that call the API functions that are part of the system's external interface (V-Development). Detailed design of the system is the last design activity before implementation begins. The hardest design problems must be addressed by the detailed design or the design is not complete. The detailed design is still an abstraction as compared to source code, but should be detailed enough to ensure that translation to source is a precise mapping instead of a rough interpretation. Source code creation should be performed in accordance with the project coding standard. Although the coding activity is sometimes regarded as the most important part of the entire software development process, it is in fact a translation from non-executable design information into executable artifacts, the source code files (via build tools which translate the human-readable source code into machine-readable binary). When building source code, project toolsets are used and errors are recorded. The errors will be recorded as part of the metrics data collected. The interview questions must be carefully constructed to ensure that correct and complete information is obtained regarding the expectations of the system to be developed. The system model is an abstraction of the system the customer has told you they want. It is important that there is consensus between the project team and the customer regarding the correctness of the system model since requirements will be derived from the system model. The vision document is the final artifact that is produced as part of requirements elicitation and analysis. The vision document represents the common understanding between the customer and the project team of the system that is to be developed. All source code should be peer reviewed according to a checklist. This includes unit test source code as well (test harness code, test driver code, stub code, etc.). PSP (Personal Software Process) metrics should be recorded to provide data for analysis so that process improvements can be made. Unit tests are structural, white box tests that should attempt to provide maximum execution path coverage including off-nominal (error) paths. The project plan is a compendium of all of the project documents that are used to manage the resources of a software development project in order to achieve a successful outcome. A project work must be broken down into discrete tasks that can then be estimated and allocated appropriate resources. Project tasks need to be identified and their scope of effort quantified. Project tasks must also be analyzed so that all task interdependencies can be identified. This activity results in a structure called the Work Breakdown Structure or WBS. Once a project has been discretized into distinct units of work or tasks, then team members must be assigned to the tasks in such a way that each task has the required number of person-hours allocated to the task in order to meet the schedule demands of the project. Activity network diagrams help project managers to identify dependencies and critical paths. Identifying critical paths is important in regards to allocating resources in an optimal fashion. Any schedule slip on the critical path directly translates to a project-wide schedule slip and should therefore be avoided. An activity bar chart is another way (in addition to the activity network diagram) of visually rendering the dependencies (or lack thereof) between the various project tasks. This type of chart is often referred to as a Gantt chart. It is important to balance the load among staff members. Team members will need to be able to take vacations, attend training, and perhaps lend support to other ongoing projects within the organization. A Staff Allocatoin Versus Time diagram is one way of displaying the workload for each staff member in the context of the project's schedule. Before expensive resources are invested in a project, it is important to thoroughly analyze all options to ensure that developing the system make sense from a cost-benefit perspective. If two options appear to be roughly equal in regards to their desirability, it will be imporant to break the tie by conducting a second assessment of those options that are considered equal and best. Given a most desired option, before that option can be acted upon, it must be analyzed regarding its feasibility and validity. The option that appeals most to the developing organization might not be what the customer actually wants or can even afford. The developing organization must ensure that tools requirements, skill set requirements, and resources exist to implement the chosen option. In the unfortunate case where the most desirable option is not feasible, it becomes necessary to evaluate the feasibility and validity of the next most desirable option. This process continues until a desirable and feasible option is chosen. After the feasibility of all of the solution options are completely evaluated, a feasibility report will need to be created that captures and elaborates the findings of the assessment group. Unit tests are structural, white box tests that should attempt to provide maximum execution path coverage including off-nominal (error) paths. Module testing is the testing of complete code objects as produced by the compiler when built from source. Sub-system integration testing focuses on testing the external APIs (Application Programming Interfaces) between sub-systems. The system testing procedure tests for errors resulting from unexpected interactions among sub-systems and system components. Acceptance testing is the final exam of a software development project. The title of this type of testing has a very positive meaning; however, there is no guarantee of acceptance. An acceptance test suite is intended to exercise the system in its target environment under standard loads with standard user interaction patterns.


Navigation Tree Key:
Box Text Expansion
Acc Req Accept Requirement
Acce Tst Acceptance Testing
Activ Netwrk Activity Network and Milestone Description
Activity Bar Char Activity Bar Chart
Add Req to SRS Add Requirement to SRS (System Requirements Specification)
Allo Pers Allocation of Personnel to Tasks
Ana Nx Feas Analyze Feasibility of Next Most Desired Option
Arch Des Architecture Design
Arch & Det Des Architecture Design and Detailed Design
Assess Feas Assess Feasibility
Bld Build
Code Code
Code Rev Code Review
Cond Inter Conduct Interview(s)
Creat Feas Rpt Create Feasibility Report
Creat Sys Model Create System Model
Creat Sys Spec Create System Specification
Creat Vis Doc
 Create Vision Document
Des V&V Design Verification and Validation
Desi Ana
 Desirability Analysis
Det Des Detailed Design
Elicit & Ana Req Elicit and Analyze Requirements
Feas Ana Feasibility Analysis
Impl Implementation
Maint Maintenance
Modu Tst Module Testing
Proj Plan Project Plan
Re-Ana Desir Re-Analyze Desirability of Most Desired Options
Rej Req Reject Requirement
Req Engr Requirements Engineering
Req V&V Requirements Verification and Validation
Spec Req Specify Requirements
Staff Alloca Staff Allocation Versus Time
SW Dev Proc Software Development Process
Sy Int Tst Sub-System Integration Testing
Sysm Tst System Testing
Task Durat Task Durations and Dependencies
Tst Testing
Unit Tst Unit Testing
Xface Des Interface Design

References

Appendix

No part of this work should be produced or used without the permission of the authors: Michael Turner and Dr. Sharon A White.