PROGRAM TITLE: BTEC in Computing (Software Engineering)
UNIT TITLE: Software Development Lifecycles
ASSIGNMENT NUMBER: 1
ASSIGNMENT NAME: : Software Development Lifecycles
SUBMISSION DATE: 19/06/2022
DATE RECEIVED: 19/06/2022
TUTORIAL LECTURER: PHAM SON TUNG
WORD COUNT: 4600 words
STUDENT NAME: LƯƠNG VĂN DUY
STUDENT ID: BKC12178
MOBILE NUMBER: 0386987693
Summative Feedback:
Internal verification:
Contents
I. Describe different software development lifecycles. ......................................................... 4
1.1 Software Development Life Cycles. ................................................................................ 4
1.2 Describe two iterative and two sequential software lifecycle models. ............................ 5
Sequential Life Cycle Model ................................................................................................. 5
1.2.1 Waterfall Model ........................................................................................................ 5
1.2.2 V- Model ................................................................................................................... 6
Iterative Model ....................................................................................................................... 9
1.2.3 Spiral Model.............................................................................................................. 9
1.2.4 DSDM Model : ....................................................................................................... 11
1.3 Explain how risk is managed in these models. .............................................................. 13
1.3.1 Risk assessment....................................................................................................... 13
1.3.2 Risk assessment reports .......................................................................................... 13
1.3.3 Keys for a successful risk management program .................................................... 14
II. Explain the importance of a feasibility study .................................................................. 14
2.1 Feasibility studies and purpose of feasibility studies in SDLC ..................................... 14
2.2 Benefits of Conducting a Feasibility Study ................................................................... 17
2.3 Describe how technical solutions can be compared. ..................................................... 17
I. Describe different software development lifecycles.
1.1 Software Development Life Cycles.
Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test high-quality software. The SDLC aims to produce high-quality software that
meets or exceeds customer expectations and reaches completion within times and cost
estimates.
• SDLC is the acronym for Software Development Life Cycle.
• It is also called as Software Development Process.
• SDLC is a framework defining tasks performed at each step in the software
development process.
• ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to
be the standard that defines all the tasks required for developing and maintaining
software.
SDLC is a process followed for a software project, within a software organization. It consists
of a detailed plan describing how to develop, maintain, replace and alter or enhance specific
software. The life cycle defines a methodology for improving the quality of software and the
overall development process.
The following figure is a graphical representation of the various stages of a typical SDLC.
1.2 Describe two iterative and two sequential software lifecycle models.
There are various software development life cycle models defined and designed which are
followed during the software development process. These models are also referred to as
Software Development Process Models". Each process model follows a Series of steps unique
to its type to ensure success in the process of software development.
Following are the most important and popular SDLC models followed in the industry:
• Waterfall Model
• Iterative Model
• Spiral Model
• V-Model
• Big Bang Model
Other related methodologies are the Agile Model, RAD Model, Rapid Application
Development, and Prototyping Models.
Sequential life cycle model :
1.2.1 Waterfall Model :
The sequential phases in the 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 the first phase is studied and the system
design is prepared. This system design helps define the overall system architecture.
• Implementation − The system is first developed with unit functions, which are
integrated into 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 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 – Some issues 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.
1.2.1.1 Waterfall Model – Advantages
Development moves from concept, through design, implementation, testing,
installation, and 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.
1.2.1.2Waterfall 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 projects where requirements are at a moderate to high risk of changing.
So, risk and uncertainty are 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.
1.2.2 V- model :
❖ Business requirements :
In this first step, business analysts gather information about the needs of the user(client)
through interviews or meetings. Then the document called the user requirements is created.
The user requirements document describes all information of the application: the interface,
data, security, system’s function, and performance. The users will carefully review this
document because it would serve as a guideline for the system designers in the system design
stage. The user acceptance tests are also designed in this step.
❖ System requirements :
After analyzing and anunderstandingnd the detailed requirements document, it is time to
design the complete system. System engineers calculate possibilities and techniques that can
be performed to 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, and 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.
❖ High-level design (Architecture design) :
Based on the technical and financial possibility, software architects would realize the
system design by breaking down it into modules taking up different functionality, brief
functionality of each module, their interface relationships, dependencies, database tables,
architecture diagrams, and technical details. The integration tests would be designed in this
stage.
❖ Low-level design (Module design) :
In these 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 function 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 to the other modules in the
system construction and the other external systems. The unit tests can be developed in this
stage based on the internal module designs.
❖ Coding :
All of the design of the module is converted 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 going through numerous code reviews and is finally optimized for the best performance.
Unit testing is executed by the developers on the code written by them.
❖ Testing :
a. Unit Test Plans (UTPs) are developed in module design step would performance now.
The unit tests are a very necessary part of any application development procedure and
help eliminate most of the 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
checks that the module can execute exactly when isolated from the rest of the units of
the system.
b. Integration testing: Integration Test Plans are developed in the Architectural Design
step. Integration Testing was performed to make sure that all of the modules created
before which were tested independently in UTPs can coexist and communicate among
themselves within the system. Then Test results are shared with the client‘s team.
c. System testing: System testing is strictly related to the system design stage. Unlike
Unit and Integration Testing, System Test Plans are constructed by the client's team.
The 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 with the compatibility between hardware and software can be
discovered during this step.
d. 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 the user environment usessirealtic data to find out the incompatibility with the other
systems. UAT confirms that the complete system meets all the requirements of the user
is and ready for use in actual time. It also detected non-functional errors such as load
and performance defects in the real-time time user environment.
1.2.2.1 Advantages of V-Model
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.
1.2.2.2 Disadvantages of V-Model
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 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
functionality.
• No working software is produced until late during the life cycle.
Iterative Model
1.2.3 Spiral Model :
The spiral model has four phases. A software project repeatedly passes through these
phases in iterations called Spirals
❖ 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.
❖ Design
The Design phase starts with the conceptual design in the baseline spiral and involves the
architectural design, logical design of modules, physical product design, and the final design
in the subsequent spirals.
❖ Construct or Build
The Construct phase refers to the 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 to build is produced with a version number. These builds are sent to the customer for
feedback.
❖ 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 the 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.
• The 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
• The Spiral may go on indefinitely.
• A large number of intermediate stages require excessive documentation.
1.2.4 DSDM model :
The 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 being involved, and
Management is not committed to the project.
-The night principles of DSDM :
1. Active user involvement
2. Teams must be empowered to make their own decisions.
3. Frequent releases are more important than maximizing quality.
4. Primary criteria for deliverables is meeting business needs.
5. Iterative development is essential to reach the 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.
The Pros of the DSDM model :
❖ RESPONDING TO CHANGE
The biggest advantage of this model is responding to change and focusing on working on the
important 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 at the earliest time.
• Developers feel valued since they’re working on things that matter and will receive
frequent in-depth feedback from the very people using the product.
❖ ACCEPTING UNCERTAINTY
During the project, we may find a particular technical solution that 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.
❖ FASTER REVIEW CYCLES
To ensure that 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.
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
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 the Agile model can lead teams to engage 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 the Agile model, it
relies 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.
1.3 Explain how risk is managed in these models.
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 its
objectives.
1.3.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. The consequence is the level of impact that the potential risk
event can have on the achievement of business objectives..5 level rating scales in the risk
survey include: 25-Almost Certain, 20-likely, 15-Possible, 10-Unlikely, 5-Rare.
1.3.2 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 the project.
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 a luxury that a project cannot afford. Time schedules
must be 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.
1.3.3 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.
II. Explain the importance of a feasibility study
A feasibility study is used to assess the viability of a project, such as ensuring a project is
legally and technically feasible as well as economically reasonable.
It informs us if a project is worth the effort, in some case scenarios, a project may not be doable.
There might be several reasons for this, including the need for too many resources, which not
only prohibits those resources from doing other jobs but may also cost more than an entire firm
would make back by taking on a project that isn’t financially worthwhile.
A well-designed study should provide a historical context of the business or project, such as a
product description or service, financial reports, details of operations and management,
marketing research and policies, financial data, legal needs, and tax duties.
In general, such analyses come before technical development and project completion.
2.1 Feasibility studies and purpose of feasibility studies in SDLC
A feasibility study is used to assess the viability of a project, such as ensuring a project is
legally and technically feasible as well as economically reasonable.
It informs us if a project is worth the effort, in some case scenarios, a project may not be doable.
There might be several reasons for this, including the need for too many resources, which not
only prohibits those resources from doing other jobs but may also cost more than an entire firm
would make back by taking on a project that isn’t financially worthwhile.
A well-designed study should provide a historical context of the business or project, such as a
product description or service, financial reports, details of operations and management,
marketing research and policies, financial data, legal needs, and tax duties.
In general, such analyses come before technical development and project completion.
• Economic: Is it possible to complete this project within the budget approved by upper
management and stakeholders?
• Schedule: Determine whether or not the project can be completed within the timeframe
provided.
• Legal: Can this project meet the requirements of cyberlaw as well as other regulatory
compliances?
• Technical: Determine whether the software is compatible with the current computer
system.
• Operation feasibility: Are we able to create the operations that the client expects?
The feasibility study is a significant step in any SDLC process because it examines different
elements like the cost necessary for creating and executing the system, the time necessary for
each step of the system, etc.
If these significant variables are not considered, the organization and its development will
suffer, and the system would collapse completely.
So, to properly operate the project and the company, this stage is significant in the SDLC
process.
After analyzing system requirements, the next phase in the software development life cycle is
to analyze software requirements.
In other words, software requirement analysis is another name for a feasibility study.
The development team must communicate with clients, understand their requirements, and
analyze the system throughout this phase.
It would be able to create a report on the identified areas of difficulty by analyzing them in this
manner.
A thorough document or report is created in this phase by doing a comprehensive analysis in
this area, which includes details such as the project plan or schedule, the cost expected for
designing and executing the system, and target dates for each step of delivery of the system
produced, etc.
This phase is the foundation of the software development process since subsequent phases in
the software development life cycle are based on the analysis performed in this phase, hence
rigorous analysis must be performed in this phase.
Though the feasibility study cannot be concentrated on a particular area, some of the areas or
analyses that were done in the feasibility study are included below.
However, all of the processes outlined below will not be followed by every system constructed.
The feasibility study differs depending on the system that will be constructed.
• A feasibility analysis is conducted on the system under development to determine if the
system development process necessitates people training.
• This aids in the design of training sessions as needed in the future.
• Is the system designed with the ability to grow or transition to new technologies in the
future if necessary? Another study is being conducted to determine the system’s
mobility in the future.
• Is the system development cost prohibitively expensive, or does it come in under
budget? A cost-benefit analysis is performed. In other words, the project’s cost
feasibility is assessed.
• This assists in determining if the company will meet the planned expenditures and
assists the business in creating earlier and more effective preparations for meeting
additional expenditures due to system development.
• A decision is taken on the software to utilize to create the system. This study and
analysis will aid in determining the optimum system and organizational
implementation.
• This feasibility study considers variables such as scalability, installation, development,
and so on. In a nutshell, this feasibility assessment examines technical topics.
• This analysis aids in the improvement of the system’s efficiency. That is because
selecting the appropriate technology based on a study of the system demands aids in
boosting the system efficiency.
The aforementioned feasibility is analyses that aid in the development of the system.
However, the scope of the feasibility study does not end there.
The analysis or feasibility study also includes a maintenance stage analysis.
In other words, a feasibility study is conducted to determine how the system will be maintained
throughout the maintenance stage.
This aids with strategic planning for this period as well as risk analysis.
The study also aids in determining what training should be provided, and how and what
documentation should be generated to assist users and developers throughout the maintenance
phase.
2.2 Benefits of Conducting a Feasibility Study
There are several benefits to doing a feasibility study, some of which are listed below:
• This research, created as the first phase in the software development life cycle, includes
all of the analytic components that aid in thoroughly examining the system
requirements.
• Aids in identifying the risk variables involved in the system development and
deployment.
• The feasibility study aids in risk analysis planning.
• A feasibility study aids in the creation of a cost/benefit analysis, which aids in the
effective operation of the organization and system.
• A feasibility study aids in developing strategies for training developers to deploy the
system.
• A feasibility study is a report that might be used by the organization’s senior or top
management because the organization decides on cost estimation, funding, and other
vital decisions based on the report, which is critical for an organization to function
financially and for the system to work smoothly.
• So, before producing a product or software, it is crucial to do feasibility studies in some
or all of the areas stated, which will aid in the development and maintenance of the
program efficiently and effectively within budgeted expenditures
2.3 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 of each alternative. This becomes a useful
document for discussion because it presents the alternatives being reviewed and comparable
characteristics for each one.
Figure: Alternative matrix comparison.
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-productdevelopment/ [Accessed 19 Nov. 2018].
-Ijera.com. (2018). [online]
Availableat: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-anybusiness [Accessed 19 Nov. 2018].
-Arxen.com. (2018). [online] Available at:
http://www.arxen.com/descargas/PulzarCloud/Books/systems-analysis-and-design-with-uml-
5thedition.pdf [Accessed 19 Nov. 2018].
