[Document title]

Alfred Smith
Unit 09 : Systems Development Life Cycles
Unit 09 : Systems Development Life Cycles
Table of Contents

Question 1 1
Waterfall Model 2
Prototyping Model 2
Spiral Model 2
Agile Model 2
Question 2 1
Question 3 1
Bibliography 1
Q 1.1 Waterfall Model

The Waterfall model was one of the first sequential process models to be introduced for system
development life cycles in computing. The model illustrates a development method that is known as
a predictive type. The Waterfall model contains goals at each phase. The goals at the current phase

Requirements

Analysis

Design

Code

Testing

Maintenance

Figure 1.1
should be completed, to pass each phase. Once a phase is passed, there is no turning back and the
development cycle proceeds ahead (see fig. 1.1). Therefore the model should be used in smaller
projects where the exact requirements are known and fixed.

The model phases illustrated above are explained in-detail below.

Requirements: The Waterfall model starts off with the requirements phase. In this phase all the
necessary requirements for the system that is to be developed are taken note of from the client and
put down in a System Requirement Specification (SRS) document that serves as the definition of the
future development of the system.

Analysis: During this phase the requirements gathered during the initial phase are further analysed.
From this, an analysis of the requirements are prioritised and models are generated on how as to
these requirements can be fulfilled.

Design: In this phase, the designing of the system begins. By using the output generated during the
analysis phase, a design plan is created outlining the required software’s and hardware’s for the
development of the system. Furthermore another important generated outcome of this phase is the
system design specification document (SDS). This document contains the necessary information
required to develop the future system.
Code: This is the phase in which the coding of the system is done according to the specifications of
the requirements, models generated and designs formulated in the previous phases.

Testing: The testing phase carries out the required testing for the system coded during coding phase.
This includes quality assurance, beta testing and a variety of other testing modules that would relate
to the system coded. The main goal of this phase is to find and eliminate any bugs or errors in the
system, and ensuring the system is as per the SRS, before handing over to the client. If any bugs or
flaws are found these are rectified by revisiting the coding stage.

Maintenance: Once the system is installed and running at the client’s end, previously unnoticed
problems can arise. To take care of these and other ongoing issues is the purpose of this phase. If
the client requires any changes or has any new requirements the process is started over from the
beginning.

Advantages
 The model is relatively easy to use and understand.
 The model is easy to follow; as in to move down the model, each phase needs to be
completed one at a time, and each phase has its own set of goals making it easier to
manage.
 The model works very well for smaller projects, as very little planning is required.

Disadvantages
 As once the process is initiated, each phase needs to be completed, making it not possible to
revert to earlier phases if changes are presented during the process. This also makes it a bad
model to use for an ongoing project for this same reason.
 Since no software is produced until the last phases of the lifecycle, this can produce a risk as
a long time would be taken to see any results. Furthermore any testing would also be
delayed, posing more risks.
 As each phase has to be finalised before moving on, this can cause a long time to see results,
making this model not suitable for a large project therefore.
Q 1.2 Prototyping Model

The prototyping model is a software development model (see fig. 1.2), where after the initial
requirement gathering process, a quick design is conducted to help create a prototype. This
prototype is then shared with the customer to obtain a feedback. By utilising the feedback gained
from the customer, the prototype is then refined if required. If required the “design” to “review &
refine” cycle is repeated until the customer provides an approval. Once the approval is given by the
customer upon satisfaction on the prototype, the process moves on to the development stage.
Following this stage once the development is done, the usual mythologies for testing take place to
assure quality assurance and beta testing for the removal of bugs and errors. Finally in the
maintenance stage, the product is handed over to the customer and checked if there are any new
issues that require to be fixed onsite after delivery.

r o
P in g
typ
u sto
C er
m
esign
D Fe ed
ack
b
e view
R &
n
fi
R

The prototyping model should be used when the customer is not clear about the needed

Initial Requirements

Customer Approval

Maintenance Testing Development

Figure 1.2
requirement as it can help the both parties; the developer and the customer to be clear on what has
to be produced at the end, by a kind of trial and error of creating prototypes until the final prototype
is approved upon for development. This same reason can help in the cause of utilising this model in
intricate projects, as prototyping can help simplify the project, before the final development is done.

Advantages
  Because prototyping occurs initially, and repetitively, there is more customer involvement
from the very beginning. This can decrease the amount of time taken and costs to fix up
issues that could emerge later on. This also helps clear out the actual needed requirement.
 As the customer is more involved, a better end product can be facilitated due to the
constant feedback.
 Prototyping from the very beginning helps in breaking down and simplifying complex
problems.

Disadvantages
 As prototypes are made, before the final product, this could lead to an increase in costs and
also time, as the number of porotypes developed can be inconclusive until the customer
provides an approval on the chosen prototype.
 As the prototypes are shared with the customer from the very beginning, there is a chance
they could get confused between the final product and the prototype, as this is an iterative
process.
 There is a risk of insufficient analysis been done since the model depends mainly on
prototyping which can again increase the time involved in producing he final outcome.
Q 1.3 Spiral Model

The spiral model is an example of an iterative SDLC model. This is model comprises of 4 phases (see
fig. 1.3). Until the final system is produced, the project continues to repeat over the 4 phases in a
spiral fashion. In the first phase, requirements gathered and objectives are determined along with
the possible constrains. In phase 2, risks analysis occurs along with prototyping. In the third phase
the development takes place. This phase follows a structure that is similar to the Waterfall model. In
the last phase, evaluations take place which include deciding on any further requirements and
assessing all the previous actions taken place during the previous phases. If any changes are felt
required to undergo, then plans to tackle these are formulated and the model “spirals” into the yet
again the first phase and the cycle repeats itself.

Phase 1 Phase 2

Phase 4 Phase 3
Figure 1.3

The speciality of this model is that when compared to other SLDC models, this model has a phase
which focuses on primarily on risk analysis. This is important for when the project is large as it can
help ensure smooth operation throughout. Also another important aspect that is useful for this
being suitable for a large projects is that the model takes into account costs of project helping to
evaluate budgets. It is also suitable for projects where the frequent releases can be expected to
happen.

Advantages
 As it is an iterative model, changing or additional requirements can be accommodated in
newer release versions of a product.
 As there is a large focus put on risk management, this is very suitable for large projects.
Another factor is that this model can help evaluate budgets for large projects.
Disadvantages
 Since generally a single phase can take somewhere between 2-6 months and as this is an
iterative SLDC model, it can take a long time to complete, or go on indefinitely as a spiral.
 This model can prove to be high cost for a small project as there are many parts to it as well
as prototyping early during the process.
 The model is a complex as it has many smaller task parts to it, requiring a lot of
documentation to be prepared.
Q 1.4 Agile Model

The Agile model is yet another iterative SDLC model. However, the Agile model as the name suggests
is very a flexible model. Like any other usual model it starts off with the requirement gathering (see
fig. 1.4). From here onwards development takes place in stages, adding functionalities as
proceeding. In between the development stages, testing and integration is also done. This
development is high quality code and not prototyping. Once the stages of developments are
completed, the product is released and reviewed by the stakeholders and developers. If the solution
released is not accepted the process moves along to amend any changes required, and reprioritises
the requirements as per the feedback. From here the cycle repeats until the release is accepted.
Once accepted, the solution is then tested and released to the market. During the entire cycle, client
and users are kept in loop with the occurrences of the project.

Generally the focus of the model is to deliver a high quality product in the a short span of time. This
is made possible by the involvement of the developers and stakeholders during the entire course of

Figure 1.4
the SDLC. This model is suitable for businesses that require changes done in small increments, as
work is done in short peroids of time making it possible to add features.

Advantages
 The iterative stages in the model are done in very short time periods; generally 2-4 weeks.
This means a working solution is produced, very fast.
 By having the stakeholders in the loop during the cycle of the process means that exact
requirements are met for and late changes can also be accommodated, quickly. This also
means, the end solution will be most favourable by the stakeholders.

Disadvantages
 As this is an iterative model, there is no fixed end to the cycle, therefore the time period can
be indefinite.
 There is not enough priority given to documentation and design of the project.
 As the stakeholders are involved throughout the process, if they are not clear with the
requirement, there can be confusion, leading to time wastage.
Q 2. Risk Management in the Spiral Model

Risk management plays a significant part (see fig. 2) of the SDLC; the Spiral model.
Risk management in the model can be broken down into 3 parts; Risk Identification, Risk Assessment
and Risk Reduction. These are carried out during the life time of the model and are not limited to the
Risk Analysis stage.

Figure 2

As the Spiral model is a risk-driven model, risk management is done earlier, by identifying, assessing
and mitigating risks early on in the lifecycle of the model. The initial risk analysis provides as a base
in which primary identified risks to the project are taken into account and then evaluated to provide
the best solution to mitigate these risks. In the following risk analysis stages, the risks are further
analysed and suitable are provided and tested via prototyping, emulations, models and benchmarks.
If these do not mean satisfactory levels, the operation is iterated until a proper solution is made
available.

Furthermore by having validation stages such as Requirements Validation, Design Validation and
Verification, help in the risk management throughout out the SDLC process.

Another factor that further helps risk management in the Spiral model is the priority given for the
planning stages for the iterative phases, which is built upon the information garnered during the
previous stages, such as the Risk Analysis stages.
Q 3. Using Waterfall Model to Develop “Project Traffic Management” or any
other large project and Assessing the Benefits

The waterfall SDLC model can be used for any scale of project and is not necessarily bound to those
that are large or big. However, the model tends to be favourable to projects of a larger scale.

With the given Project Traffic Management, the requirements are clearly given. Also the goal of
project is fixed and exact. For example the sub system; “The Number Plate Recognition System for
Breaking of Red Light Rules” has a predefined objective. This would be to recognise number plates of
any vehicle that violates the rule of running a red light. Like this, every system mentioned under the
Project Traffic Management system has a set of fixed and clear objectives.

Even though development of the system would start later with the Waterfall model, every phase
(see fig 1.1) has a deliverable. For example during the Requirements phase the requirements of the
system would be identified and at the end of this phase a SRS document would be available. This
would need to be approved to progress to the next phase, as in the waterfall model each phase is
carried out one at a time and the current phase would have to completed to progress to the next
phase. This would benefit the project because it would mean less time required rather than
repeating the process when using an iterative model.

Changes are expensive and time consuming when using the Waterfall model. Thus by using the
deliverables from each phase, confirmations can be obtained and these costs and unnecessary time
consumptions can be minimised. Thus the project could progress on within a comfortable time
frame.

Since the Project Traffic Management is system that comprises of many subsystems, the Waterfall
model’s method of planning and documentation will help the project move along smoothly I a more
organised manner, as all the requirements would be first identified before moving onto the Analysis
phase, and thereafter the Design phase and so on.