1

Software Development Life Cycle

Assignment 1

Prepared for :

Mr. Le Van Minh

Greenwich University Da Nang

Prepared by:

Le Vo Thang

18, November, 2018

 2

Table of Contents
P1. Describe two iterative and two sequential software
lifecycle models.

*Sequential life cycle model : ............................................................................................. 3

1.Waterfall Model :.................................................................................................................. 3
2.V- model : ............................................................................................................................ 6

* Iterative Model ....................................................................................................................10

1.Spiral Model : .....................................................................................................................10
2.DSDM model : ....................................................................................................................12

P2. Explain how risk is managed in the Spiral lifecycle

model.

1.Risk assessment : .................................................................................................................15

2. Calculating Inherent Risk : ....................................................................................................15
3.Risk assessment reports: .......................................................................................................16
4. Keys for a successful risk management program : ...............................................................16

P3.Explain the purpose of a feasibility report 17

P4 .Describe how technical solutions can be compared. 18

REFERENCES 19
 3

P1. Describe two iterative and two

sequential software lifecycle models.

*Sequential life cycle model :

1.Waterfall Model :
*The sequential phases in Waterfall model are :

 Requirement Gathering and analysis − The requirements of the system are

captured in this phase and documented in a requirement specification
document.

 System Design − The requirement document in first phase are studied in this
phase and the system design is prepared. This system design helps defining the
overall system architecture.

 Implementation − The system is first developed unit functions, which are

integrated in the next phase. Each unit is developed and tested for its
functionality, which is referred to as Unit Testing.

 Integration and Testing − All the units developed in the implementation phase
are integrated into a system after testing of each unit. Post integration the entire
system is tested for any faults and failures.

 Deployment of system − Once the functional and non-functional testing is

done; the product is deployed in the customer environment or released into the
market.

 Maintenance − There are some issues which come up in the client environment.
To fix those issues, patches are released. Also to enhance the product some
better versions are released. Maintenance is done to deliver these changes in
the customer environment.
 4

Waterfall Model – Advantages

Development moves from concept, through design, implementation, testing,

installation, troubleshooting, and ends up at operation and maintenance. Each phase
of development proceeds in strict order.

Some of the major advantages of the Waterfall Model are as follows :

 Simple and easy to understand and use

 Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.

 Phases are processed and completed one at a time.

 Works well for smaller projects where requirements are very well understood.

 Clearly defined stages.

 Well understood milestones.

 Easy to arrange tasks.

 Process and results are well documented.

 5

Waterfall Model – Disadvantages

-The major disadvantages of the Waterfall Model are as follows :

 No working software is produced until late during the life cycle.

 High amounts of risk and uncertainty.

 Not a good model for complex and object-oriented projects.

 Poor model for long and ongoing projects.

 Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.

 It is difficult to measure progress within stages.

 Cannot accommodate changing requirements.

 Adjusting scope during the life cycle can end a project.

 Integration is done as a "big-bang. at the very end, which doesn't allow

identifying any technological or business bottleneck or challenges early.
 6

2.V- model :

2.1. Business requirements :

In this first step, business analysts gathering information about the needs of the
user(client) by interview or meeting. Then the document called the user requirements
is created. The user requirements document describe all information of the application :
the interface, data, security, system ‘s functional, performance. The users will carefully
review this document because it would serve as the guideline for the system designers
in the system design stage. The user acceptance tests are also designed in this step.

2.2 System requirements :

After analyze and understand the detailed requirements document, it is the time to
design the complete system. System engineers calculate possibilities and techniques
that can be performed follow the user requirements.If any of the requirements are
inappropriate , the user is notified of the problem.Then the resolution is suggested and
the requirements document is edited after that.In this step, the application specification
document is generated for the development stage.It contains the general, menu
structures, data structures system organization.The system test plan is developed in
this step, the earlier the system test plan is prepared , the more time for unit testing
executed later.

2.3. High level design (Architecture design) :

Based on the technical and financial possibility , software architects would realize the
system design by broken down it into modules taking up different functionality, brief
functionality of each module, their interface relationships, dependencies, database
tables, architecture diagrams, technology details . The integration tests would be
designed in this stage.
 7

2.4. Low level design (Module design) :

In this steps , the designed system is broken up into smaller modules with the very
specification details so the developers can start coding .The module design document
will contain a detailed functional of the modules :

+ All elements of the database tables.

+ All interface details with complete API references.

+All dependency issues

+Error message listings

+Complete input and outputs for a module.

It is very important that the module designed is appropriate with the other modules in
the system construction and the the other external systems.The unit tests can be
developed in this stage based on the internal module designs.

2.5.Coding :

All of the modules design is convertered into code by the developers in this step. The
most suitable programming language is decided according to the system and
architecture requirements. The coding is implemented based on the coding guidelines
and standards. The code is went through numerous code reviews and finally optimized
for the best performance. Unit testing is executed by the developers on the code written
by them.
 8

2.6. Testing :

2.6.1.Unit Test Plans (UTPs) are developed in module design step would performance
now. The unit tests are a very necessary part of any application develop procedure and
helps eliminate most of errors that can generate at a very early phase.

A unit like a program module is the smallest entity in the whole system. Unit testing
check that the module can execute exactly when isolated from the rest of the units of
system.

2.6.2.Integration testing :

Integration Test Plans are developed in the Architectural Design step. Integration
Testing performed to make sure that all of the modules created before which tested
independently in UTPs can coexist and communicate among themselves within the
system.Then Test results are shared with the client ‘s team.

2.6.3.System testing :

System testing is strictly related with the system design stage. Unlike Unit and
Integration Testing , System Test Plans are constructed by client's team. System Test
plan ensures that all of the client ’s expectations are met. The entire application ’s
system is tested for its functionality, interdependency and communication. System
Testing authenticates that functional and non-functional requirements are met. Load
and performance testing, stress testing, regression testing.Most of the problems about
the compatibility beetween hardware and software can be discovered during this step.

2.6.4.Acceptance testing:

User Acceptance Test (UAT) Plans are developed in the Requirements Analysis step.
Test Plans are constructed by the user. UAT is executed in user environment and using
realistic data to find out the incompatibility with the other systems . UAT confirms that
complete system meets all the requirement of user and ready for use in actual time. It
also detects the non-functional errors such as load and performance defects in the real
time user environment.
 9

*V-Model - Pros and Cons

-The advantages of the V-Model method are as follows

 This is a highly-disciplined model and Phases are completed one at a time.

 Works well for smaller projects where requirements are very well understood.

 Simple and easy to understand and use.

 Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a
review process.

-The disadvantages of the V-Model method are as follows

 High risk and uncertainty.

 Not a good model for complex and object-oriented projects.

 Poor model for long and ongoing projects.

 Not suitable for the projects where requirements are at a moderate to high risk of changing.

 Once an application is in the testing stage, it is difficult to go back and change a

functionality.

 No working software is produced until late during the life cycle.

 10

* Iterative Model

1.Spiral Model :

The spiral model has four phases. A software project repeatedly passes through these
phases in iterations called Spirals.

1.1 Identification
This phase starts with gathering the business requirements in the baseline spiral. In the
subsequent spirals as the product matures, identification of system requirements,
subsystem requirements and unit requirements are all done in this phase.

This phase also includes understanding the system requirements by continuous

communication between the customer and the system analyst. At the end of the spiral,
the product is deployed in the identified market.

1.2 Design
The Design phase starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and the final
design in the subsequent spirals.

1.3 Construct or Build

The Construct phase refers to production of the actual software product at every spiral.
In the baseline spiral, when the product is just thought of and the design is being
developed a POC (Proof of Concept) is developed in this phase to get customer
feedback.

Then in the subsequent spirals with higher clarity on requirements and design details a
working model of the software called build is produced with a version number. These
builds are sent to the customer for feedback.
 11

1.4. Evaluation and Risk Analysis

Risk Analysis includes identifying, estimating and monitoring the technical feasibility
and management risks, such as schedule slippage and cost overrun. After testing the
build, at the end of first iteration, the customer evaluates the software and provides
feedback.

The following illustration is a representation of the Spiral Model, listing the activities in
each phase.
Based on the customer evaluation, the software development process enters the next iteration
and subsequently follows the linear approach to implement the feedback suggested by the
customer. The process of iterations along the spiral continues throughout the life of the
software.

The advantages of the Spiral SDLC Model are as follows

 Changing requirements can be accommodated.

 Allows extensive use of prototypes.

 Requirements can be captured more accurately.

 Users see the system early.

 Development can be divided into smaller parts and the risky parts can be developed earlier
which helps in better risk management.

The disadvantages of the Spiral SDLC Model are as follows

 Management is more complex.

 End of the project may not be known early.

 Not suitable for small or low risk projects and could be expensive for small projects.

 Process is complex

 Spiral may go on indefinitely.

 Large number of intermediate stages requires excessive documentation.

 12

2.DSDM model :

Dynamic systems development method (DSDM) was first created in 1994 and originally
sought to provide some discipline to the rapid application development (RAD) method.
DSDM Atern is the latest version of the popular Dynamic Systems Development Model
approach to Agile.

It Eliminates problems of: Going over-budget, Missing deadlines, Users not involved,
Management not commited in the project.

-The night principles of DSDM :

1. Active user involvement

2. Teams must be empowered to make their own decisions.

3. Frequent releases more important than maximizing quality.

4. Primary criteria for deliverables is meeting business needs.

5. Iterative development is essential to reach correct solution.

6. Any change during development can be reversed.

7. The most high level requirements should be unchangeable.

8. Testing shall occur throughout the lifecycle of the project.

9. All stakeholders must cooperate and communicate.

 13

*The Pros of DSDM model :

1.RESPONDING TO CHANGE

The biggest advantage of this model is responding to change and focus on working
on importance part of projects. An Agile team has a list of the most important things
they can work on; when they finish the most important thing on that list, they move
to the next most important thing…and repeat again and again. This type of focus
has many benefits:

-Customers get solutions to the problems they value most in the earliest time.

-Developers feel valued, since they’re working on things that actually matter and will
receive frequent in-depth feedback from the very people using the product.

2.ACCEPTING UNCERTAINTY

During the project we may find a particular technical solution doesn’t meet the
needs of customers, or we might discover there’s an entirely different problem
underneath the stated problem. Applying Agile principles to our approach allows us
to accept the unknown and prioritize discovery and experimentation to drive out
uncertainty before we fully commit to a solution.

3. FASTER REVIEW CYCLES

To ensure that new discoveries are contemplated and current efforts are evaluated. Most
Agile practices either time-box efforts (Scrum) or control the amount of “work in progress” to
ensure efforts are completed within a reasonable amount of time. Those efforts are then
reviewed with customers .
 14

*The Cons of DSDM Development

LACK OF UNDERSTANDING

The biggest drawback of Agile development is most people don’t understand what it
means to be Agile. Many companies “want” to be Agile, but don’t invest the time,
money, or effort to actually educate management or employees about how the
principles apply and what methodologies will work best within their culture and
organization

With the change in process or people, not investing in understanding why we’re making
the change so that change will almost inevitably lead to failure.

FLEXIBILITY CAN LEAD TO BAD BEHAVIORS

The flexibility of Agile model can lead teams engaging in bad behaviors, and “blaming”
the resulting outcomes on Agile itself, rather than the wrong choices made by the team.

No product can succeed without some level of process and tools, some negotiation of
deliverables or some form of plan.when a company decides to change to Agile model,
it rely on internal people with “experience” that lead the change; if their experience is
based on poor fundamentals, then their next Agile processes will suffer many of the
same limitations.

CHALLENGES AT SCALE
In recent years, there have been many attempts at building scalable Agile system
architectures. These concepts have been driven primarily by the difficulty of effectively
scaling the work teams do into larger and larger organizations.

When the ideal size of a scrum team is most often positioned at between 5 and 9
people and your development team consists of 500 developers, how do you manage
the interrelationships between those small teams while still maintaining a cohesive
approach? Most Agile methodologies were designed for small, nimble,young
organizations to adopt and adapt, but only in recent years have there been real efforts
to identify and establish scalable Agile practices large organizations can apply.
 15

P2. Explain how risk is managed in the

Spiral lifecycle model.

-An effective risk management process is an important component of a successful IT

security program. .The risk management process should not be treated primarily as a
technical function carried out by the IT experts who operate and manage the IT system,
but as an essential management function of the organization. The principal goal of an
organization‘s risk management process should be to protect the organization and its
ability to perform their objectives..

1.Risk assessment :
Risk assessment is the first process in the risk management methodology.Using risk
assessment to determine the extent of the potential threat and the resulting impact of
that adverse event on the organization. Consequence is the level of impact that the
potential risk event can have on the achievement of business objectives..5 level rating
scale in the risk survey including : 25-Almost Certain, 20-likely, 15-Possible, 10-
Unlikely, 5-Rare.

2. Calculating Inherent Risk :

Inherent risk specify the exposure arising from a risk event before any action has been
taken to manage it. Inherent Risk = Consequence X Probability Inherent risk rating will
be exhibited on a 4 level rating scale : Extreme Risk, High Risk, Moderate Risk, Low
Risk.
 16

3.Risk assessment reports:

There are different kinds of risk assessment reports. Detail -Risk Report : detail risks at
different stages based on cost, schedule, resource and manpower factors. Scope - Risk
Report: The scope statement or mission statement may be assessed for risks at the
beginning of a projec. Cost Evaluation Risk Report: Cost or funds are at constant risk in
a project. It has to be maintained and controlled with as little deviation as possible from
the forecasted values.. Schedule Evaluation Risk Report: Time is luxury that a project
cannot afford. It is imperative that time schedules are met with as little delay as
possible. Time delays can impact the progress of a project and put it at risk. Such risks
are documented in the schedule evaluation risk report. Technical Evaluation Risk
Report: Risks related to resources, manpower and departments fall under this category.
Risks arising due to quality constraints and those which are due to design errors and
poor planning also fall under this group.

4. Keys for a successful risk management

program :

(1) Senior management‘s commitment.

(2) The full support and participation of the IT team

(3) The competence of the risk assessment team, which must have the expertise to
apply the risk assessment methodology to a specific site and system, identify mission
risks, and provide cost-effective safeguards that meet the needs of the organization.

(4) The awareness and cooperation of members of the user community, who must
follow procedures and comply with the implemented controls to safeguard the mission
of their organization.
 17

P3.Explain the purpose of a feasibility

report.

A project feasibility study is a comprehensive report that examines in detail the five frames of
analysis of a given project. It also takes into consideration its four Ps, its risks and POVs, and its
constraints (calendar, costs, and norms of quality). The goal is to determine whether the project
should go ahead, be redesigned, or else abandoned altogether.

The five frames of analysis are: The frame of definition; the frame of contextual risks; the frame
of potentiality; the parametric frame; the frame of dominant and contingency strategies.

The four Ps are traditionally defined as Plan, Processes, People, and Power. The risks are
considered to be external to the project (e.g., weather conditions) and are divided in eight
categories: (Plan) financial and organizational (e.g., government structure for a private project);
(Processes) environmental and technological; (People) marketing and sociocultural; and
(Power) legal and political. POVs are Points of Vulnerability: they differ from risks in the sense
that they are internal to the project and can be controlled or else eliminated.

A feasibility study examines the practicability of a proposal or idea. The principal function of this
is to determine if the project will continue or not. In business, feasibility studies work in a number
of reasons.

The feasibility report will look at how a certain proposal can work in a long-term basis or endure
financial risks that may come. It is also helpful in recognizing potential cash flow. Another
important purpose is that it helps planners focus on the project and narrow down the
possibilities. Accordingly, a feasibility study can provide reasons not to pursue the said project
or proposal. When it comes to the operational aspect, the analysis determines whether the plan
has the necessary resources for it to be practicable. Feasibility report will also help we figure out
whether or not the people will support the subsequent product or service. Additionally, it
provided knowledge on the trends because a feasibility study looks at the present-day market
and studies the anticipated growth of your target business sector.

Feasibility studies are prevalent in all business industries. Whether Hotel, Hospitality,
Restaurant, Real Estate, Medical, Office or Industrial. Getting a head start on a Feasibility study
will ensure you save time and money on the project.
 18

P4 .Describe how technical solutions

can be compared.

An alternative matrix can be used to organize the pros and cons of the design
alternatives so that the best solution will be chosen in the end. This matrix is created
using the same steps as the feasibility analysis. The only difference is that the
alternative matrix combines several feasibility analyses into one matrix
so that the alternatives can easily be compared. An alternative matrix is a grid that
contains the technical, budget, and organizational feasibilities for each system
candidate.
Sometimes weights are provided for different parts of the matrix to show when
some criteria are more important to the final decision.To create the alternative matrix,
draw a grid with the alternatives across the top and different criteria (feasibilities, pros,
cons,…) along the side.
Next, fill in the grid with detailed descriptions about each alternative. This becomes a
useful document for discussion because it clearly presents the alternatives being
reviewed and comparable characteristics for each one.

Figure 1 : Alternative matrix comparison.

 19

REFERENCES

-www.tutorialspoint.com. (2018). SDLC Quick Guide. [online] Available at:

https://www.tutorialspoint.com/sdlc/sdlc_quick_guide.htm [Accessed 19 Nov. 2018].

-UserVoice Blog. (2018). The Pros and Cons of Agile Product Development | UserVoice Blog.
[online] Available at: https://community.uservoice.com/blog/the-pros-and-cons-of-agile-product-
development/ [Accessed 19 Nov. 2018].

-Ijera.com. (2018). [online] Available at: https://www.ijera.com/papers/Vol2_issue4/DJ24712716.pdf

[Accessed 19 Nov. 2018].

-En.wikipedia.org. (2018). Feasibility study. [online] Available at:

https://en.wikipedia.org/wiki/Feasibility_study#Formal_definition [Accessed 19 Nov. 2018].

-Trumanmox.com. (2018). Why a Feasibility Study is Important for any Business | TrumanMox.
[online] Available at: https://www.trumanmox.com/why-a-feasibility-study-is-important-for-any-
business [Accessed 19 Nov. 2018].

-Arxen.com. (2018). [online] Available at:

http://www.arxen.com/descargas/PulzarCloud/Books/systems-analysis-and-design-with-uml-5th-
edition.pdf [Accessed 19 Nov. 2018].