Systems Development Process

Systems Development Life-Cycle Models

The Systems Development Life-cycle (SDLC) process typically consists of the following 7 development phases:

1. Planning
2. Requirements
3. Design
4. Implementation
5. Verification
6. Deployment
7. Maintenance

An SDLC methodology, or model, is a specific definition of the order of the execution of these phases, the number of times each phase is executed, the length of the development cycles, and other parameters. Let’s have a brief look at some of the well-known SDLC models, many of them originated in SW engineering, but most are equally applicable and are in wide use in all disciplines:

• Waterfall Model

  The Waterfall Model emphasizes a linear progression of development phases from the beginning to the end of each project. Each phase must be completed before starting the next phase. Therefore, the quality and completeness of deliverables created in each phase is the key to the project success. As most development projects need much more flexibility, this model is rarely used today.

• Iterative Model

  The Iterative Model repeats cycles focusing on smaller portions of overall functionality at a time. It enables starting with a simple implementation of a subset of the requirements and iteratively enhances evolving versions until the full system is implemented. Its main advantage compared to the Waterfall Model is that it gives working versions of the developed system earlier and therefore changes are less expensive. It is also used in other models as a basis for each repetitive life-cycle development.

• “V” Model

  The “V” Model emphasizes requirements-driven design and testing to produce a rigorous systems development life-cycle. The left side of “V” Model represents the decomposition of requirements to design, and the right side represents integration, verification, and validation on the components, subsystems, and system level. The traceability between requirements, design, and tests enables the creation of high-quality documentation to ensure product quality and compliance with industry standards. The iterative “V” Model is therefore very popular in regulated industries, such as automotive, aerospace & defense, medical devices, railway, etc, where requirements are well known up-front.

• Spiral Model

  The Spiral Model is an iterative risk-driven development model. Each iteration of the spiral represents a complete SDLC that consists of the following phases: objective determination, risk analysis, engineering & evaluation, and plan of the next iteration. The main advantage of the Spiral Model is its flexibility to accommodate changes, customer involvement and emphasis on early addressing of risks. This model is therefore popular for large and complex projects with evolving requirements and a high degree of risk.

When looking at the various SDLC models, we can see that they differ in many aspects: the number and lengths of the development cycles, as well as the number, format, thoroughness, and completeness of the documents and artifacts that are produced in each development phase. Still, most of them share the following characteristics:

• Product development is done in cycles (only the Waterfall Model has one cycle).
• In each cycle, a predefined set of documents is being written/updated, reviewed and carried out.
• Ideally, these documents should be based on predefined reusable templates to assure that all required issues are addressed by the development methodology.

There are some exceptions. Particularly, some agile methods (such as Kanban) do not need to iterate development cycles and enable continuous integration, delivery, or deployment of SW products through effective team collaboration and automation of SW build, test, and deployment tasks.

If you develop a non-critical SW product using an agile method (such as Kanban) then you can simply manage requirements by writing user stories on sticky notes, or in a task-tracking tool (such as Jira). However, development of multi-disciplinary products usually implies the adoption of a traditional SLDC model (such as the “V” Model), a need for rigorous documentation, and a necessary implementation of a specialized requirements management tool to finish the project successfully. Let’s demonstrate in this tutorial the advantages of using ReqView for such projects.

Development Models Supported by ReqView

One of the most important characteristics of ReqView is that it supports almost any SDLC model, and it does not enforce any specific development methodology on you. ReqView can even support different development models in different sub-projects within the same project. This comes very handy in a multi-disciplinary project, when collaborating development teams usually use different development methodologies and different document templates.

ReqView has powerful documentation, versioning, and traceability capabilities. It provides a framework for writing, updating, and managing documents that capture project artifacts (needs, requirements, risks, design, tests, etc.), amending the artifacts with extra relevant information and process control data, link relevant artifacts and query information and links. Supporting a specific development model becomes the question of writing documents, in the format that is relevant to the development model in use. ReqView enables this by easily configurable project and document templates.

ReqView comes with the following document templates:

• ISO 29148: specify business, stakeholder, system, SW or HW requirements using the international standard ISO/IEC/IEE 29148 — Systems and software engineering — Life cycle processes — Requirements engineering
• Volere: manage SW product needs, requirements, issues, and definitions based on the Volere Requirements Specification Template
• User Stories: manage user stories for agile SW development based on User Stories Applied
• FMEA: manage risks using the Failure Mode and Effects Analysis method
• OWASP ASVS: manage SW security requirements based on the OWASP Application Security Verification Standard standard

These are only a sample of ReqView capabilities. If you want to use a different methodology that requires different templates, you can easily create document templates that suit the methodology you want to use to develop your project. In the next chapters of this tutorial, we will demonstrate how to create the needed ReqView document templates for a different methodology.

Selection of Development Model for UNEX Example Project

One of the first steps in planning a project is the selection of the development methodology (or methodologies) that will be used in the project. This selection depends on factors like project size, disciplines, and nature (for example, mission-critical, transportation or medical), customer constraints, team and organization expertise, to name a few. Usually, there is more than one development methodology that can support the successful development of a given project.

We will select the “V” Model and the MIL-STD-498 – Military Standard Software Development and Documentation standard for our UNEX example project. Choosing the “V” model for this project is a natural choice. The selection of the MIL-STD-498 standard, dated back to 1994, deserves some explanation:

• Compatibility: Despite its age, it is compatible with the latest standards. It later got "civilized" as J-STD-016. Finally, it became part of the current international standard ISO/IEC/IEEE 12207 Systems and software engineering — Software life cycle processes and harmonized with ISO/IEC/IEE 15288 — Systems and software engineering — System life cycle processes. The use of MIL-STD-498 development process provides a good fit to these latest standards.

• No Dependencies: It is completely self-sufficient, and invokes no other standard.

• Methodologies: It was designed with grand design, incremental, and even evolutionary development methodologies in mind.

• Flexibility: It officially supports customization and adaptation to different projects. It even includes an official tailoring guide.

• Document Templates: It provides reusable document templates (called Data Item Descriptions (DIDs)) for all documents defined by the standard, including detailed writing instructions, which is rare for current standards.

• Public Domain: All documentation and document templates are freely available on the internet. For instance, see this Github repository containing all MIL-STD-498 all DIDs in PDF and HTML.

You can read more about this standard in the blog post MIL-STD-498: A forgotten military standard that saves me weeks of work by Kristof Kovacs.

Besides, using the “V” Model and MIL-STD-498 provides a good opportunity to demonstrate the creation of new document templates in ReqView.

In the next Chapter 4, we will demonstrate how to create ReqView document and project templates for our UNEX example project.