Any standard software process model would primarily consist of two types of activities: A set of framework activities, which are always applicable, regardless of the project type, and a set of umbrella activities, which are the non SDLC activities that span across the entire software development life cycle.
At the end of this session, you will be able to:
- Define umbrella activities in a software life cycle
- Explain the usage and importance of the following umbrella activities:
a) Traceability Matrix-its definition, usage, and relevance in the SDLC
b) Peer Reviews, Forms of reviews, Planning and execution of peer reviews
The umbrella activities in a software development life cycle process include the following:
- Software Project Management
- Formal Technical Reviews
- Software Quality Assurance
- Software Configuration Management
- Re-usability Management
- Risk Management
- Measurement and Metrics
- Document Preparation and Production
Now, let us try to understand the concept of traceability and its importance in software development. For example, in an organization, the activities are departmentalized on the basis of the functionality to be served and employees are allocated to each department. A requirement traceability can be defined as a method for tracing each requirement from its point of origin, through each development phase and work product, to the delivered product. Thus, it helps in indicating, for each work product, the requirements this work product satisfies.
When there is absence of traceability: The product gets compromised since the development cannot be prioritized based on the order of criticality of the component, ultimately leading to missed functionality in the delivered software. Project management is compromised due to the lack of visibility of the components of the application being developed and their interconnections causing a major hindrance to continuous planning. Testing is compromised as the coverage is not verified at every stage of the life cycle. It becomes difficult to demonstrate that the product is ready. Finally, maintenance becomes difficult as identification and analysis of the impacted work products and requirements becomes tedious. This ultimately increases the complexity during testing.
Some benefits are that its availability ensures correct implementation of requirements as traceability gives a clear visibility of the interactions among the components within the system. The forward and backward visibility into the system actually helps in estimating the tasks and activities of the project with greater accuracy through a detailed impact analysis for the changes. This leads to effective project management and planning. Since traceability provides a highly visual view of the interrelationships between the various components, it can be used to identify the requirements that have not been covered and hence analyze the gaps between them. Traceability gives a complete idea about the dependencies and relationships of and between components. For any change in requirement that is requested by the customer, it facilitates impact analysis and simplifies the maintenance activities. Finally, traceability also helps to ensure that all the work is against current requirements and that the requirements are completely satisfied.
The roles and responsibilities with respect to the traceability matrix are explained in this page. Project manager ensures all required information is provided as needed, reviews the traceability matrix for completeness. Requirement analyst updates requirements traceability matrix as needed, support analysis as needed. Designer provides mapping of requirements to design products. Developer provides mapping of requirements to development products. Tester provides mapping of requirements to test products.
This page details the concept of Peer Review in software projects and identifies the importance and need of Peer Reviews. In software development, Peer Review refers to a type of Software Review in which a work product (any software deliverable, design, or document) is examined by its author and/or one or more colleagues of the author, in order to evaluate its technical content and quality. Management representatives should not be involved in conducting a peer review except when included because of specific technical expertise, or when the work product under review is a management-level document. Managers participating in a peer review should not be line managers of any other participants in the review.
Peer Review has to be planned at the start of the project where the PM or PL identifies the artifacts to be reviewed and the Peer Reviewers. The Review schedule of the individual items to be reviewed along with associated reviewer needs to be planned by the PL during the project execution. The Peer Review needs to be conducted by the assigned Reviewers.
- Umbrella activities span all the stages of the SDLC
- The concept of umbrella activities focuses on Requirement Traceability Matrix
- Requirement traceability matrix is needed to be maintained by projects to ensure that the requirements are adequately addressed
- Not maintaining a requirement traceability matrix results in problems including unsatisfied requirements, problems during delivery and maintenance
- Software Peer Review needs to be planned, performed, and logged.
Next Article: Configuration Management in Software Engineering