Software Development Process 2 | Traditional Software Phases, Software Lifecycle Models, and…

Software Development Process 2 | Traditional Software Phases, Software Lifecycle Models, and Common Software Development Mistakes

1. Traditional Software Phases

(1) Review: Traditional Software Phases

We have talked about the traditional software phases in the last article. And before we have a more detailed introduction of it, let’s first review its components.

• Requirement Engineering
• Design
• Implementation
• Verification and Validation
• Maintenance

(2) The Definition of Requirement Engineering

Requirement Engineering is the process of establishing the needs of stakeholders that are to be solved by the software.

(3) Importance of Requirement Engineering

In general, the cost of correcting an error depends on the number of subsequent decisions that are based on it. Therefore, errors made in understanding requirements have the potential for the greatest cost because many other design decisions depend on them and many other follow-up decisions depend on them. The cost grows dramatically as we go from the requirements phase to the maintenance phase because if we discover a problem later, to correct the error we’re left to undo a lot of the decisions that we had made before.

(4) Steps to Collect Right Requirements

In order to avoid the cost of a late correction, we have to collect the requirements in the right way through the following steps,

• Elicitation: the collection of requirements from stakeholders and other sources and can be done in a variety of ways
• Requirement Analysis: this involves the study and a deeper understanding of the collective requirements
• Specification of requirements: the collective requirements are suitably represented, organized, and saved so that they can be shared
• Validation: it is to make sure the softwares are complete, consistent, not redundant, and so on. So that they have satisfied a set of important properties for requirements
• Requirement management: this accounts for changes to requirements during the lifetime of the project.

In reality, as we will see, this is an iterative process instead of a linear process, in which we will go on and cover different phases in an iterative fashion.

(5) The Definition of Software Design

The software design is a phase where software requirements are analyzed in order to produce a description of the internal structure and organization of the system. This description will serve as the basis for the construction of the actual system.

(6) Common Design Activities

Traditionally, the software design phase consists of a series of design activities, normally consisting of,

• architectural design phase
• abstract specification
• interface design
• component design
• data structure
• algorithm design

Note that these are just possible components of design activity, and a design activity can actually be constructed in many different ways. These activities result in a bunch of design products. For example,

• system structure and architecture
• software specification
• interface specification
• component specification
• data structure specification
• algorithm specification

(7) The Definition of Implementation

In the implementation phase, what we do is to basically take care of realizing the design of the system that we just created for creating a natural software system.

(8) Four Principles of Software Implementation

Basically, there are 4 fundamental principles or four pillars that can affect the way in which the software is constructed.

• reduction of complexity: this aims to build software that is easier to understand and use
• anticipation of diversity: this principle takes into account that software construction might change in various ways over time and in many different cases, the softwares may involve many unexpected kinds of ways. Therefore, we want to anticipate some of these changes
• structuring for validation (aka. design for testability): what this means is that we want to build software so that it is easily testable during the subsequent validation and verification activities
• use of internal or external standards: it is important that the software conforms to a set of internal or external standards and this is especially true within specific organizations and or domains

(9) The Definition of Verification and Validation

After we build our system, verification and validation is the phase of software development that aims to check if the software system meets the specification and fulfills its intended purpose.

• Validation: Did we build the right system? Will it make the customers happy?
• Verification: Did we build the system right? Did we build a system that actually implements the specification that we defined?

(10) Levels of Verification and Validation

Another aspect that we would like to talk about is that verification and validation can be performed at different levels. In particular,

• it can be performed at the unit level: test individual units
• it can be performed at the integration level: test the interaction between different units
• it can be performed at the system level: test the system as a whole

(11) The Definition of Maintenance

As we have discussed before, software development efforts normally result in the delivery of a software product that satisfies the user requirements. After the release of a software product to its final users, many things can happen. For example,

• environment might change
• there might be new libraries
• there might be new systems in which our software has to operate
• there might be future requests: this means the customers may want to do something different with the program that was given to them
• users may find out problems with the software, and they may file bug reports

(12) Three Maintenance Activities

Specifically, in response to these problems, the software developers created three kinds of maintenance activities,

• Corrective maintenance to eliminate problems with the code
• Perfective maintenance to accommodate feature requests, and in some cases just to improve the software, for example, to make it more efficient
• Adaptive maintenance to take care of the environment changes.

After these activities have been performed, the software developers will produce a new version of the application, release it, and the cycle will continue throughout the lifetime of the software. That’s why maintenance is a fundamental activity and a very expensive one.

(13) The Definition of Regression Testing

One of the reasons why maintenance is expensive is regression testing, which is the activity of retesting software after it has been modified to make sure that the changes in your performance to the software work as expected, and to make sure that your changes did not introduce any unforeseen effect.

2. Software Process/Lifecycle Models

(1) The Definition of Software Lifecycle Models

The software lifecycle models, also named the software process models, are prescriptive models of what should happen from the very beginning to the very end of a software development process.

The main function of these models is to determine the order of the different activities so that we know which one should come first and which one should follow. Another function of these models is to determine the transition criteria between activities.

(2) The Definition of Waterfall Process Model

The grandfather of all the other software lifecycle models is the waterfall model. In the waterfall model, the project progresses to an orderly sequence of steps, from the initial software concept, down until the final phase of system testing. The ordered phases are,

• software concept
• requirement analysis
• architecture design
• detailed design
• coding and debugging
• system testing

At the end of each phase, there will be a review to determine whether the project is ready to advance to the next phase.

The pure waterfall model performs well for software products in which there is a stable product definition. This means that the domain is well known and the technologies involved are well understood. In these kinds of domains, the waterfall model helps you to find errors in the early, local stages of the projects.

(3) The Evaluation of Waterfall Process Model

The main advantage of the waterfall model is that it allows you to find errors early. However, the main disadvantages of the waterfall model arise from the fact that it is not flexible, because it is difficult to fully specify requirements at the beginning of a project.

(4) The History of Spiral Process

The spiral model was first described by Barry Boehm in his paper from 1986 that was entitled A Spiral Model of Software Development and Enhancement. One of the main characteristics of that paper is that it was describing the spiral model using a diagram which has become very popular.

(5) The Definition of Spiral Process Model

The spiral model is an incremental risk-oriented lifecycle model that has four main phases.

• Determine objectives: requirements will be gathered
• Identify and resolve risks: risks and alternate solutions will be identified, and a prototype will be produced
• Development and tests: produce software and tests for it
• Plan the next iteration: the output of the project, so far, is evaluated, and the next iteration is planned

What the spiral process prescribes is a way of developing software by going through these phases in an iterative way, in which we learn more and more of the software, we identify more and more, and account for, more and more risks, and we go more and more towards our final release.

(6) Advantages for Using the Spiral Model

There are several advantages for this model,

• Risk reduction: extensive risk analysis does reduce the chances of the project to fail
• Flexibility: functionality can be added at a later phase because of the iterative nature of the process
• Deliverability: software is produced early in the software lifecycle. So at any iteration, we have something to show for our development
• Feedback Accessibility: we are able to get early feedback from the customer about what we have produced

(7) Disadvantages for Using the Spiral Model

However, there are still some disadvantages.

• Risk analysis requires highly specific expertise, and the whole success of the project is depending on that
• Risk analysis is way more complex than other models, and therefore, it can be costly to implement

(8) The Definition of Evolutionary Prototyping Model

Another lifecycle model is called the evolutionary prototyping model, and it works in four main phases,

• start from an initial concept
• design and implement a prototype based on this initial concept
• refine the prototype until it is acceptable
• complete and release the prototype

When developing a system using evolutionary prototyping, the system is continually refined and rebuilt. So it is actually an ideal process when not all requirements are well understood, which is a very common situation.

(9) Reality for Evolutionary Prototyping Model

Because it is common that not all the requirements are well understood, developers start by developing the parts of the system that might not be very clear at the stage. The partial system is then shown to the customer, and the customer’s feedback is used to drive the next iteration, in which either changes are made to the current features or new features are added. So either the current prototype is improved or the prototype is extended.

When the customer agrees that the prototype is good enough, the developers will complete the remaining work on the system and release the prototype as the final product.

(10) Evolutionary Prototyping Model: Evaluation

There are some advantages to this model. For example,

• developers can get immediate feedback

However, there are also some disadvantages. For example,

• the project is difficult to plan: for example, it is difficult to predict how long the developing process will take because the number of iterations is uncertain

(11) The Definition of Rational Unified Process (RUP)

The rational unified process (RUP) is a very popular process model based on UML. RUP works in an iterative way, which means that it performs different iterations, and at each iteration, it performs four phases.

• interception: to scope the system
• elaboration: to perform domain analysis and define the basic architecture
• construction: the bulk of the development actually occurs
• transition: to go from development to production

In each one of these four phases, we perform standard software engineering activities, like

• business modeling
• requirement gathering
• analysis and design
• implementation
• test
• deployment
• etc.

and we do them to different extents based on the phase in which we are.

(12) The Definition of Agile Process Model

The agile model is, in fact, a group of software development methods that are based on highly iterative and incremental development. In particular, the method we will talk about is called test-driven development (TDD).

(13) The Definition of Test-Driven Development

The TDD is based on the iteration of three main phases and we mark them in different colors,

• RED (fail): we write test cases that encode our requirements, and for which we have not written code yet, they will definitely fall
• GREEN (pass): after we make the test enough code to make the test cases pass, we have a set of test cases that are all passing
• YELLOW (refactor): because the structure of the code deteriorates over time if we keep adding pieces, we have to modify the code to make it more readable and more maintainable. In general, we modify to improve the design of the code.

(14) Model Selection

Now we have discussed plenty of models, and want we want to focus on is how to select the appropriate model for a project. A good model can ensure the success of the project, while a wrong can potentially make the project fail. To decide which model to choose, we have to take into consideration many factors,

• requirement understanding: hard or easy one?
• expected lifetime: quick or long-term support?
• risk: do we know the domain and technologies?
• schedule constraints: how many resources do we have?
• interaction with managements or customers: do we have a continuous interaction? Do we have some initial phases or some checking points?
• expertise: do we have the right people to handle the work?

For example, for the development of a software control system, we can use the pure waterfall model because the requirements are clear. For the development of a software for midcourse corrections, both the spiral model and the evolutionary prototyping can be used because it can be too expensive to update the course if we use a pure waterfall process.

3. Well-known Ineffective Development Practices

(1) Mistakes Involving People

• Heroics: too much emphasis on can-do attitudes. This discourages cooperation.
• Wrong working environment: all the people would like to work in a good environment
• Poor people management: The lack of leadership creates an unhappy atmosphere and people will leave the teams. Another common one is to add people to the project behind schedule, and it costs to bring the new people to the right speed.

(2) Mistakes Involving Process

• Scheduling issue: the team is unable to come out with an unrealistic schedule
• Planning issue: insufficient planning or abundant planning due to pressure, usually lead inexorably to failure
• Unforeseen failures: failures on the constructor’s ends lead to downstream effects

(3) Mistakes Involving Product

• Gold plating: people tend to have more requirements than they actually need
• Feature creep: adding more features to a product that were not initially planned
• Research ≠ Development: working on a project that strains on the limit of computer science

(4) Mistakes Involving Technology

• Silver-bullet syndrome: too much reliance on the advertised benefits of some previously unused technology
• Switch or add tools in the middle of a project: introducing a new tool can usually have a steep learning curve
• Lack of automated version control: easy to make mistakes, and unable to find an out-of-date version back