Whichever software life cycle is adopted, the software engineering activities briefly described in the following sections will need to be carried out.
1- Requirements Analysis and Specification
In this phase, the user’s requirements are identified and analyzed. The requirements of the system to be developed are specified in a Software Requirements Specification (SRS). The SRS is an external specification of the software. Its goal is to provide a complete description of what the system’s external behavior is without describing how the system works internally. The issues of what constitutes a SRS are described lucidly in Davis (1993).
With some systems, such as embedded systems, in which the software is part of a larger hardware/software system, it is likely that a systems requirements analysis and specification phase precedes the software requirements analysis and specification.
With this approach, system functional requirements are allocated to software and hardware before software requirements analysis begins (Davis 1993).
2- Architectural Design
A software architecture (Bass, Clements, and Kazman 2003; Shaw and Garlan 1996) separates the overall structure of the system, in terms of components and their interconnections, from the internal details of the individual components. The emphasis on components and their interconnections is sometimes referred to as programming-in-the-large, and detailed design of individual components is referred to as programming-in-the-small. During this phase, the system is structured into its constituent components and the interfaces between these components are defined.
3- Detailed Design
During the detailed design phase, the algorithmic details of each system component are defined. This is often achieved using a Program Design Language (PDL) notation, also referred to as Structured English or pseudocode. Internal data structures are also designed.
4- Coding
During the coding phase, each component is coded in the programming language selected for the project. Usually a set of coding and documentation standards have to be adhered to.
5- Software testing
Because of the difficulty of detecting errors and then locating and correcting the detected errors, software systems are usually tested in several stages (Ammann and Offutt 2008). Unit and integration testing are “white box” testing approaches, requiring knowledge of the internals of the software; system testing is a “black box” testing approach based on the software requirements specification, without knowledge
of the software internals.
5.1 Unit Testing
In unit testing, an individual component is tested before it is combined with other components. Unit testing approaches use test-coverage criteria. Frequently used test-coverage criteria are statement coverage and branch coverage.
Statement coverage requires that each statement should be executed at least once.
Branch coverage requires that every possible outcome of each branch should be tested at least once.
5.2 Integration Testing
Integration testing involves combining tested components into progressively more complex groupings of components and then testing these groupings until the whole software system has been put together and the interfaces tested.
5.3 System Testing
System testing is the process of testing an integrated hardware and software system to verify that the system meets its specified requirements (IEEE 1990). The whole system or major subsystems are tested to determine conformance with the requirements specification. To achieve greater objectivity, it is preferable to have system testing performed by an independent test team.
During system testing, several features of the software system need to be tested (Beizer 1995). These include the following:
■ Functional testing. To determine that the system performs the functions described in the requirements specification.
■ Load (stress) testing. To determine whether the system can handle the large and varied workload it is expected to handle when operational.
■ Performance testing. To test that the system meets its response time requirements.
5.4 Acceptance Testing
The user organization or its representative usually carries out acceptance testing, typically at the user installation, prior to acceptance of the system. Most of the issues relating to system testing also apply to acceptance testing.
Thanks to Dr. Hassan Gomma 2011 book "Software Modeling and Design".
1- Requirements Analysis and Specification
In this phase, the user’s requirements are identified and analyzed. The requirements of the system to be developed are specified in a Software Requirements Specification (SRS). The SRS is an external specification of the software. Its goal is to provide a complete description of what the system’s external behavior is without describing how the system works internally. The issues of what constitutes a SRS are described lucidly in Davis (1993).
With some systems, such as embedded systems, in which the software is part of a larger hardware/software system, it is likely that a systems requirements analysis and specification phase precedes the software requirements analysis and specification.
With this approach, system functional requirements are allocated to software and hardware before software requirements analysis begins (Davis 1993).
2- Architectural Design
A software architecture (Bass, Clements, and Kazman 2003; Shaw and Garlan 1996) separates the overall structure of the system, in terms of components and their interconnections, from the internal details of the individual components. The emphasis on components and their interconnections is sometimes referred to as programming-in-the-large, and detailed design of individual components is referred to as programming-in-the-small. During this phase, the system is structured into its constituent components and the interfaces between these components are defined.
3- Detailed Design
During the detailed design phase, the algorithmic details of each system component are defined. This is often achieved using a Program Design Language (PDL) notation, also referred to as Structured English or pseudocode. Internal data structures are also designed.
4- Coding
During the coding phase, each component is coded in the programming language selected for the project. Usually a set of coding and documentation standards have to be adhered to.
5- Software testing
Because of the difficulty of detecting errors and then locating and correcting the detected errors, software systems are usually tested in several stages (Ammann and Offutt 2008). Unit and integration testing are “white box” testing approaches, requiring knowledge of the internals of the software; system testing is a “black box” testing approach based on the software requirements specification, without knowledge
of the software internals.
5.1 Unit Testing
In unit testing, an individual component is tested before it is combined with other components. Unit testing approaches use test-coverage criteria. Frequently used test-coverage criteria are statement coverage and branch coverage.
Statement coverage requires that each statement should be executed at least once.
Branch coverage requires that every possible outcome of each branch should be tested at least once.
5.2 Integration Testing
Integration testing involves combining tested components into progressively more complex groupings of components and then testing these groupings until the whole software system has been put together and the interfaces tested.
5.3 System Testing
System testing is the process of testing an integrated hardware and software system to verify that the system meets its specified requirements (IEEE 1990). The whole system or major subsystems are tested to determine conformance with the requirements specification. To achieve greater objectivity, it is preferable to have system testing performed by an independent test team.
During system testing, several features of the software system need to be tested (Beizer 1995). These include the following:
■ Functional testing. To determine that the system performs the functions described in the requirements specification.
■ Load (stress) testing. To determine whether the system can handle the large and varied workload it is expected to handle when operational.
■ Performance testing. To test that the system meets its response time requirements.
5.4 Acceptance Testing
The user organization or its representative usually carries out acceptance testing, typically at the user installation, prior to acceptance of the system. Most of the issues relating to system testing also apply to acceptance testing.
Thanks to Dr. Hassan Gomma 2011 book "Software Modeling and Design".
No comments :
Post a Comment