Software Development Life Cycle
Overview
This document covers the Software Development Life Cycle (SDLC) for Home Base Web Solutions. Home Base implements a RUP methodology. We know that Agile is the new hot thing, but if you really look at Agile, the processes within each SCRUM can and should closely resemble those of a RUP process. Since Home Base is a smaller shop, no project passes the initiation phase of project management if the estimated time to completion is over a month. We may create a program that consists of several smaller projects, each of which is about a month in duration, but no project can last longer than a month. So if you are really a die hard SDLC nut, you can technically call our process AGILE if you want. Our ideas are the same: Clients want to see results, requirements inevitably change over time, we really like getting paid, and big long processes get confusing. So without further ado:
SDLC Phases
The SDLC phases have been derived from the Rational Unified Process (RUP), the Project Management Institute’s Project Management Body of Knowledge (PMBOK), and Home Base Web Solutions best practices. The following phases cover all the major components of the SDLC while identifying the goals, roles, and deliverables. Each phase will be completed in order as it appears in figure 1.
The Home Base Software Development Life Cycle
Figure 1: The phases follow a modified Unified Process.
Inception
Using business process analysis, Unified Modeling Language (UML) techniques, stakeholder interviews, and collaborative definition of application functionality, the Inception phase produces Scope definition for the project as well as a Functional Specification defining what functions the application must be able to perform. Use Cases, an outcome of Inception, are used to determine functional requirements. Figure 2 shows a diagram of the flow of events utilized during Inception to capture the scope of what the solution will deliver. Inception is a collaborative process working with the customer.
Inception Phase Flow
Figure 2: The steps that take part in the inception phase are depicted in order to produce the final functional specification.
The objective for inception will cover defining the customers need. Once this objective is complete the following conditions should be met.
- A clear understanding of the problem that needs to be solved.
- The current processes that are in use today to solve the problem.
- The benefits of solving the problem and their value.
Deliverables
Once the requirements gathering process is completed the following will be delivered.
- Scope Definition – The original requirements usually created by the client that defines the action items.
- Use Cases (Started) – A document that contains each of the application processes and what each step the application can take after each command. In the inception phase these should end up around 15 percent complete and will be finished in the elaboration phase.
- Functional Specification – A detail specification that entails what is going to get done.
Team Involvement
During the inception phase the following roles will need to participate in the inception process.
- Development Staff
- Product Management
- Project Stakeholders
Elaboration
During Elaboration the project team continues to collaborate with your to create a Technical Design Specification that defines how the solution will complete features defined in the Functional Specification. Figure 3 shows the flow of events to produce a Technical Design Specification.
Elaboration Phase Flow
Figure 3: The elements of the elaboration phase are shown in detail in order to produce the final technical specification.
The objective for elaboration covers taking the captured requirements and further defining them into design documentation that can be used by the development staff to write the end software product.
Industry standard UML diagrams are used to communicate the system to be built. For example, users (Actors) interact with functionality in the system (Use Cases) and are subsequently depicted in a Use Case Diagram (see Figure 4 below).
Example Use Case Diagram
Figure 4: An example use case diagram is shown with the actors and processes. (Adapted from UML Distilled)
The flow of events is depicted as a UML Partition Diagram which is sometimes referred to as a Swimlane diagram (see Figure 5 below). The advantage to this exercise is that it encourages parallel processing of the system and lends itself to multithreaded development and effectively communicates how a system flows.
UML Partition “Swim lane” Diagram
Figure 5: The flow of events depicted as a UML partition diagram. (Adapted from UML Distilled)
Once this objective is complete the following conditions should be met.
- Designer / Developer will be able to take the supplied requirements and determine if enough information has been captured to create an application design.
- A process for gathering additional requirements if information is missing.
- Process for capturing design documentation so developers can create the requested functionality.
- Design documentation will solve the captured requirements and nothing more.
- Completed User Interface designs or Prototypes.
Deliverables
Once the analysis and design process is completed the following will be delivered.
- Technical Specification – A detail document containing how the application is going to be built.
- Completed Use Cases – A document that contains each of the application processes and what each step the application can take after each command.
- User Interfaces – A document or developed prototype that contains example screen shots and details how the application is to be laid out.
Team Involvement
During this stage the following roles will need to participate in the elaboration process.
- Project Management
- Development staff
Construction
During the construction the team builds application components or infrastructure elements per the approved Functional and Design specifications. Sets of milestones are defined to allow project stakeholders to establish checkpoints that ensure adherence to both requirements and schedule.
Once this objective is complete the following conditions should be met.
- Developers have completed coding the application.
- Quality Assurance has tested the application.
Deliverables
Once the software development process is completed the following will be delivered.
- Completed Application.
- Document containing test cases based on the use cases.
- Installation and deployment guides.
Team Involvement
During this stage the following roles will need to participate in the construction process.
- Project Management
- Development staff
- Quality Assurance
Transition
In the transition stage the team supports the client’s execution of their User Acceptance Testing (UAT) plan. Once the UAT is complete the project is promoted to production.
- Quality Assurance has confirmed the production application is working.
- The client has completed User Acceptance Testing (UAT). UAT will be performed in a staging environment prior to production deployment.
- The developed application has been deployed to a production environment.
Deliverables
Once the deployment process is completed the following will be delivered.
- Updated Functional specification, Technical specification, User Interface, Use Cases, and Test Cases.
Team Involvement
During this stage the following roles will need to participate in the transition process.
- Project Management
- Development staff
- Quality Assurance
- Support Staff
- Project Stakeholders
Support and Maintenance
In the support and maintenance phase the application will be monitored to ensure it runs at the intended level of quality.
Deliverables
Once the maintenance process is completed the following will be delivered.
- Documented process for identifying and escalating bug reports. In this will be the validation process and escalation process.
- Documented process for bug assignment and prioritization.
Team Involvement
During this stage the following roles will need to participate in the support and maintenance process.
- Support Staff
- Quality Assurance
Appendix A: Use Case Template
Business Requirements
Business requirements describe the functionality that the envisioned system will provide. The next section provides a short description of the methodology used herein to document requirements this is followed by the requirements. We will provide samples of Use Cases that will be developed in the next phase before application construction begins.
Documentation Methodology
Our experience indicates that a combination of business process workflows and Use Case descriptions provides a highly effective and efficient form of communicating business requirements.
Actors
Actors are considered to be any person or system that interacts with the system being documented. The following sections describe the key Actors (roles) within the system, and how they interact with one another.
| Name | Description |
|---|---|
Use Cases
Use cases provide a detailed business description of how significant actions within a business process are accomplished. They include detailed descriptions of any business rules associated with a function, the expected workflow surrounding an action in cases of success and failure.
Developing Use Cases is an iterative process that involves more detail as new scenarios are discovered and described. Early iterations of Use Cases may contain a very high-level, low-detail view of how an Actor interacts with the system. In some cases, early Use Cases may only contain a Summary and a preliminary list of Actors involved. As more information is gathered, and a better understanding is established, Use Cases begin to mature and details are added to accurately reflect the processes involved.
Use Case Descriptions
Use Case Descriptions contain a written account of the way that Actors interact with the system. Use cases are split into three logical segments, the use case description, the expected workflow description, and the alternate workflow description(s).
Use Case Description Format
For the purposes of this document each topic in a Use Case Description is defined below:
| Topic | Description |
|---|---|
| Summary | The Summary contains a very short description of the Use Case | Business Events | Business Events are triggers that stimulate activity within the business. Business Events must be atomic and observable | Actors | At least one or more of the Actors defined in the system is involved in every Use Case. This topic tells which ones apply. | Assumptions | Any assumptions made in the creation of the Use Case. As details of the Use Case are refined, assumptions begin to disappear. When assumptions are removed or are not present, this topic will contain a simple “N/A” for Not Applicable. | Preconditions | Preconditions identify what must be in place before the Use Case carries out its duties. | Description | The description contains an account of the details in a Use Case. It contains more information than the Summary and describes the aspects of the process not covered by other topics in the Use Case. | Associations | A list of other use cases that this use case is extended by or is used by | Inputs Summary | Summary level listing of data input by the actor(s). Note that inputs in this document will be expanded upon / altered during the development process of the application. | Outputs Summary | Summary level listing of data output by the system. | Alternatives Paths and Exceptions | An alternative path is a sequence of actions in a Use Case that only happens in special circumstances.
An exception occurs when the system forces an Actor through an alternative path rather than the Actor choosing the path voluntarily. |
Post conditions | Post conditions identify what must be in place after the Use Case carries out its duties. | Termination Outcomes | The conditions and results for unsuccessful completion of the use case. | Notes | Information that is not directly part of the use case but arises while working on the use case. |
Events
This section describes the events that occur as part of the fulfillment of the use case detailed in the Use Case Description. The following format is used to describe both the flow of events and any alternate flow(s) that may exist.
| Flow Name | Description |
|---|
The “Flow Name” column is used to group the flow or portions of the flow being described. In the case where a use case has several segmented flows that make up the main workflow, each segment would be named in this column for clarity. The “Description” column contains a description of what will happen at the prescribed point in the workflow.
Appendix B: Quality Assurance Process
To improve the quality assurance process, a set of testing principles should be defined and followed. A Quality Assurance Analyst could help define this process.
There are generally 4 main levels of software testing carried out:
- Unit Testing in which the basic components of the software system are tested to verify that the detailed design for the unit has been correctly implemented.
- Integration testing in which progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a whole.
- System testing in which the software is integrated to the overall product and tested to show that all requirements are met. Since the Quality Assurance area is not well developed, it is recommended that System Testing be a manual process. Once the area matures automated test tools can used for regression testing. At the moment, it is suggested to have the regression testing done manually by following the defined test scripts.
- Acceptance testing is a further level of testing in accordance with requirements. Occasionally, Acceptance testing, upon which the acceptance of the complete software is based. The clients often do this.