ASSIGNMENT 01 FRONT SHEET

Qualification BTEC Level 5 HND Diploma in Computing

Unit number and title Unit 09: Software Development Life Cycle

Submission date 31/03/2023 Date Received 1st submission

Re-submission Date 07/04/2023 Date Received 2nd submission

Student Name Nguyen Ngoc Chien Student ID GCH211388

Class GCH1102 Assessor name Do Quoc Binh

Student declaration
I certify that the assignment submission is entirely my own work and I fully understand the consequences of plagiarism. I understand that making a
false declaration is a form of malpractice.

Student’s signature Chien

Grading grid
P1 P2 P3 P4 M1 M2 D1 D2

1
❒ Summative Feedback: ❒ Resubmission Feedback:

Grade: Assessor Signature: Date:

Internal Verifier’s Comments:

Signature & Date:

2
Table of Contents
Task 1. SDLC model ................................................................................................................................................................................................................................... 4
1. Describe SDLC models ................................................................................................................................................................................................................... 4
Waterfall Model....................................................................................................................................................................................................................................... 4
V-Shaped Model...................................................................................................................................................................................................................................... 6
Agile Development .................................................................................................................................................................................................................................. 8
Spiral Model ............................................................................................................................................................................................................................................ 9
Comparison between Agile Model and Waterfall Model ...................................................................................................................................................................... 11
Suitable SDLC models for Tune Source project ................................................................................................................................................................................... 12
Selecting the Appropriate Development Methology ............................................................................................................................................................................. 14
2. Explain how risk is manged in the Spiral lifecycle model ............................................................................................................................................................ 16
Task 2. Feasibility study ............................................................................................................................................................................................................................ 18
1. The purpose of conducting a feasibility study for the project ....................................................................................................................................................... 18
2. How the three feasibility criteria (technical, economic, organizational) are applied to the project .............................................................................................. 20
Reference ................................................................................................................................................................................................................................................... 24

3
Task 1. SDLC model

1. Describe SDLC models

Waterfall Model

The waterfall model is the classical mode of software engineering. This model is on eof the oldest models and is widely used in government
projects and in many major companies. As this model emphasizes planning in early stages, it ensures design flaws before they develop. In
addtion, its intensive document and planning make it work well for projects in which quality control a major concern.
The pure waterfall lifecycle consists of serveral non-overlapping stages, as shown in the following figure. The model begins with establishing
system requirements and software requirements and continues with architectural design, detailed design, coding, testing, and maintenance. The
waterfall model serves as a baseline for many other lifecycle models.

Figure 1. Waterfall model

4
The following list details the steps for using the waterfall model:
 System requirement: Establishes the components for building the system, including the hardware requirements, software tools, and other
necessary components. Examples include decisions on hardware, such as plug-in boards (number of channels, acquisition speed, and so
on), and decisions on external pieces of software, such as databases or libraries.
 Software requirements: Establishes the expectations for software functionality and identifies which system requirements the software
affects. Requirements analysis includes determining interaction needed with other applications and databases, performance requirements,
user interface requirements, and so on.
 Architectural design: Determines the software framework of a system to meet the specific requirements. This design defines the major
components and the interaction of those components, but it does not define the structure of each component. The external interfaces and
tools used in the project can be determined by the designer.
 Detailed design: Examines the software components defined in the architectural design stage and produces a specification for how each
component is implemented.
 Coding : Implements the detailed design specification.
 Maintenance: Addresses problems and enhancement requests after the software releases.

The waterfall method does not prohibit returning to an earlier phase, for example, returning from the design phase to the requirements phase.
However, this involves costly rework. Each completed phase requires formal review and extensive documentation development. Thus, oversights
made in the requirements phase are expensive to correct later.
 Advantages:
 Easy to understand and implement.
 Widely used and know (in theory!).
 Reinforces good habits: define-before-design, design-before-code.
 Identifies deliverables and milestones.
 Document driven, URD, SRD, … etc. Published documentation standards, e.g. PSS-05.
 Works well on mature products and weak teams.

5
  Disadvantages:
 Idealized, doesn’ t match reality well.
 Doesn’t reflect iteractive nature of exploratory development.
 Unrealistic to expect accurate requirements so early in project.
 Software is delivered late in project, delays discovery of serious errors.
 Difficult and expensive to make changes to documents, “swimming upstream”.
 Significant administrative overhead, costly for small teams and projects.

V-Shaped Model

Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the
next phase begins. Testing is emphasized in this model more than the waterfall model. The testing procedures are developed early in the life cycle
before any coding is done, during each of the phases preceding implementation. Requirements begin the life cycle model just like the waterfall
model. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in requirements
gathering.

The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase in order to test the pieces
of the software systems ability to work together. However, the low-level design phase lies where the actual software components are designed,
and unit tests are created in this phase as well.

6
 Figure 2. V-Shaped Model

The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of
the V where the test plans developed earlier are now put to use.
 Advantages:
 Simple and easy to use
 Each phase has specific deliverables.
 Higher chance of success over the waterfall model due to the early development of test plans during the life cycle.
 Works well for small projects where requirements are easily understood.

7
  Disadvantages:
 Very grid like the waterfall model.
 Little flexibility and adjusting scope is difficult and expensive.
 Software is developed during the implementation phase, so no early prototypes of the software are produced.
 This Model does not provide a clear path for problems found during testing phases.

Agile Development

Agile development is a group of programming-centric methologies that focus on streamlining the SDLC. Much of the modeling and documentation
overhead is eliminated; instead, face-to-face communication is preferred. A project emphasizes simple, iterative application development in which
every iteration is a complete software project, including planning, requirements analysis, design, coding, testing, and documentation. (Figure 6).
Cycles are kept short (one to four weeks), and the development team focuses on adapting to the current business environment. There are serveral
popular approaches to agile development, including extreme programming (XP), Scrum, and dynamic systems development method (DSDM).

Extreme Programming

An approach to development, based on the development and delivery of very small increments of functionality. It relies on constant code
improvement, user involvement in the development team and pair wise programming . It can be difficult to keep the interest of customers
who are involved in the process. Team members may be unsuited to the intense involvement that characterizes agile methods. Prioritizing
changes can be difficult where there are multiple stakeholders. Maintaining simplicity requires extra work. Contracts may be a problem
as with other approaches to iterative development.

8
 Figure 4. Extreme programming

Spiral Model

The spiral model is similar to the incremental model, with more emphases placed on risk analysis. The spiral model has four phases: Planning,
Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model).
The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spiral builds on the baseline
spiral. Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate
solutions. A prototype is produced at the end of the risk analysis phase. Software is produced in the engineering phase, along with testing at the
end of the phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next
spiral. In the spiral model, the angular component represents progress, and the radius of the spiral represents cost.

9
 Figure 5. Spiral Model
 Advantages:
 High amount of risk analysis.
 Good for large and mission-critical projects.
 Software is produced early in the software life cycle.

10
  Disadvantages:
 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.

 Spiral model sectors:

 Objective setting: Specific objectives for the phase are identified.
 Risk assessment and reduction: Risks are assessed and activities are put in place to reduce the key risks.
 Development and validation: A development model for the system is chosen which can be any of the general models.
 Planning: The project is reviewed and the next phase of the spiral is planned.

Comparison between Agile Model and Waterfall Model

Agile development approaches have existed for over a decade. Agile development practices were created in part because of dissatisfaction with
the sequential, inflexible structure of waterfall-based approaches. Presently, agile development has made inroads into software development
organizations, and studies show an even split between agile and waterfall users. Many organizations are experimenting with agile even while
continuting to employ traditional waterfall approaches.

11
 Figure 6. Criteria for selecting a Methodology

Suitable SDLC models for Tune Source project

 Waterfall model is an old model and is used a lot in a small project, but the percent of failure in the project is very high if it used for
complex and object-oriented projects. Futhermore, the cost of correcting those flows is too high because we must update everything from
the documentation to the reasoning. Another way, if the software development documentation is not correctly completed, the project will
most likely go astray when developing this product.
 Moderately suitable for Tune Source

 V-model also contains some weakness that is not suitable for this project. All requirements are known up-front so this model cannot
readily manage dynamic changes in requirements. But, V-model does not contain risk analysis activitives, it is hard to manage risk and it
has high percent of projects failure.
 Moderately suitable for Tune Source

12
  Prototyping model involves creating a basic, working version of the software to obtain feedback from the users. This model may be most
suitable for Tune Source as the company is customer-focused and wants to make changes based on customers’ feedback. This model
allows Tune Source to test the initial version of the software to see if it is suitable for their needs.
 Moderately suitable for Tune Source

 Scrum model involves a team-based approach and relies heavily on collaboration between developers and customers. This model may
be least suitable for Tune Source as the company has an experienced IT department and has not expressed a desire for extensive customer
collaboration during the development process.
 Least suitable for Tune Source

 Spiral model involves a cyclical approach where the software is developed and then tested at each stage. This model may be moderately
suitable for Tune Source as the company has an experienced IT department that could handle the cyclical approach. This model allows
Tune Source to make changes to the development process as needed.
 Moderately suitable for Tune Source

Due to these reason, I choose Spiral model for Tune Source because:
 Environment is balance.
 The techonology used is dynamic or stable.
 There are many available resources and trainning techniques.
 Th requirements do not change on a regular basis.
 The project is short.

13
Selecting the Appropriate Development Methology

There are many methodologies. The first challenge faced by project managers is to select which methodology to use. Figure 9 summarizes some
important methodology selection criteria. One important item not discussed in this figure is the degree of experience of the analyst team. Many
of the RAD and agile development methodologies require the use of new tolls and techniques that have a significant learning curve. Often, these
tools and techniques can significantly increase the speed in which the methodology can deliver a final system.

Clarity of User Requirements

When the user requirements for what the system should do are unclear, it is difficult to understand them by talking about them and
explaining them with written reports. Users normally need to interact with technology to really understand what the new system can do
and how to best apply it to their needs. System prototying and throwaway prototyping are usually more appropriate when user requirements
are unclear, because they provide prototypes for users to interact with early in the SDLC. Agile development may also be appropriate if
on-site user input is available.

Familiarity with Technology

When the system will use new techonology with which the analysts and programmers are not familiar, applying the new technology early
in the methodology will improve the chance of success. If the system is designed without some familiarity with the base technology, risks
increase because the tools may not be capable of doing what is needed. Throwaway prototyping is particularly appropriate for situations
where there is a lack of familiarity with technology, because it explicitly encourages the developers to create design prototypes for areas
with high risks. Iterative development is good as well, because opportunities are created to investigate the technology in some depth before
the design is complete. While one might think that system prototyping would also be appropriate, it is much less so because the early
prototypes that are built usually only scratch the surface of the new technology. Typically, it is only after several prototypes and several
months that the developers discover weaknesses or problems in the new technology.

System Complexity
Complex systems require careful and detailed analysis and design. Throwaway prototyping is particularly well suited to such detailed
analysis and design, but system prototyping is not. The waterfall methodologies can handle complex systems, but without the ability to

14
get the system or prototypes into users’ hands early on, some key issues may be overlooked. Although iterative development
methodologies enable users to interact with the system early in the process, we have observed that project teams who follow these
methodologies tend to devote less attention to the analysis of the complete problem domain than they might if they were using other
methodologies.

System Reliability
System reliability is usually an important factor in system development. After all, who wants an unreliable system? However, reliability
is just one factor among serveral. For some applications, reliability is truly critical (e.g., medical equipment, missile control systems),
while for other applications it is merely important (e.g., games, Internet video). The V-model is useful when reliability is important, due
to its emphasis on testing. Throwaway prototyping is most appropriate when system reliability is a high priority, because detailed analysis
and design phases are combined with the ability for the project team to test many different approaches through design prototypes before
completing the design. System prototyping is generally not a good choice when reliability is critical, due to the lack of careful analysis
and design phases that are essential to dependable systems.

Short Time Schedules

Projects that have short time schedules are well suited for RAD methodologies because those methodologies are designed to increase the
speed of development. Iterative development and system prototyping are excellent choices when time lines are short because they best
enable the project team to adjust the functionality in the system on the basis of a specific delivery date. If the project schedule starts to
slip, it can be readjusted by removal of the functionality from the version or prototype under development. Waterfall-based methodologies
are the worst choice when time is at a premium, because they do not allow for easy schedule changes.

Schedule Visibility
One of the greatest challenges in systems development is knowing whether a project is on shedule. This is particularly true of the waterfall-
based methodologies because design and implementation occur at the end of the project. The RAD methodologies move many of the
critical design decisions to a position earlier in the project to help project managers recognize and address risk factors and keep
expectations incheck.

15
2. Explain how risk is manged in the Spiral lifecycle model

Boehm presented the spiral model as a risk –driven software development process model in 1988, in which the development process is led by
involved hazards. This methology tries to detect and analyze software project hazards while also assisting in risk reduction. Despite its risk-driven
nature, the key soursces of risk in this strategy are due to a heavy dependence on human factors and a sophicicated risk mangegement procedure.
According to Boeh, over a quarter of the time in this approach is spent on risk analysis, and it primaryly intended to address recognized risks in
the project. It not only gives us project flexibility, but it also alerts us to potential threats.

Risk management process

Risk management process involves:

 Identify Organiational Risks: By surveys, interviews, and solicitation of input across divisions an departments of Probability: The
likelihood of risk getting realized.
 Inherent Risk: The nature of the risk event
 Mitigation Control Effectiveness: The effectiveness of mitigation plans

Spiral development supports risk management in software projects in several ways summarized in the following:

 Spirals of evolutionary prototyping aimed at overcoming performance and user interface issues. These spirals aid in the reduction of main
hazards prior to the development phase.
 The risk analysis stage in each cycle the precededs each waterfall phase serves the objective of the spiral’s iterative aspect, which allows
the development process to return to the initial quadrant at any poin in time.
 The evaluation completed at the conclusion of each cycle with key stakeholders serves as a decision point to minimize lack of commitment
risks in the follwing cycle.
 Because of the risk analysis step performed at each cycle, spiral development is the greatest way to handle time and expense overun
concerns. At this point, the cost and time necessary for each cycle and calculated in advance to provide a clear picture of the project’s
essential status.

16
This helps the project manage and the developers get more control over these risks. (Spiral is also used to control risks associated with the
project’s rising complexity).

This is achieved by the partitioning activity conducted at the planning phase. (Decomposing the project into sections to be developed in parallel
spirals decreases time contention issues since more work may be accomplished within the same timeframe).

Risk management matrix

The Spiral Model’s Major Risk Sources Despite its risk-driven nature, spiral has its own risk sources, which are outlined below:

 A strong emphasis on the human aspect

 Process for managing risks in detail

Risk Item Level Action to Mitigate Communicate

Scope & Objective Extreme To prevent spending time Maintain regular contact
outside of the Framework, with consumers.
it is vital to think about an
explain a specific
Framework, as well as
have strong team
management skills.
Requirement Definition Medium Using tools to receive and Talk to the leaders in this
Change handle user requests. industry on a regular basis
Create the best product to to understand how to fix
meet clients’ demands. it.
Techinical Processes Medium The method model is Speak with the stakeholder
Change errorneous, and the and director, as well as the
project’s true essence does marketing and
not apply. Influence the development teams, to
project’s rate of progess. revise the Process model.

17
 Technology Employed Extreme Determine the Frequent meetings with
techonology required for workers provide direction
the project so that the for knowledge
team’s employees and the development, as do open
company’s viewpoint on sharing sessions in which
technology are individuals may offer their
compatible. Create a expertise and experience.
Technical Solution Matrix
to choose and pick
possibilities

Figure 7. Risk management matrix

Task 2. Feasibility study

1. The purpose of conducting a feasibility study for the project

Once the need for the system and its business requirements have been defined, the approval committee may authorize the systems analyst to
prepare a more detailed business case to better understand the proposed information system project. Feasibility analysis guides the organization
in determining whether to proceed with the project. Feasibility analysis also identifies the important risks associated with the project that must be
managed if the project is approved. As with the system request, each organization has its own process and format for the feasibility analysis, but
most include techniques to assess three areas: technical feasibility, economic feasibility, and organizational feasibility (see Figure 10). The results
of evaluating these three feasibility factors are combined into a feasibility study deliverable that is submitted to the approval committee at the end
of project initiation.

18
Figure 8. Feasibility Analysis Assessment Factors

19
2. How the three feasibility criteria (technical, economic, organizational) are applied to the project

Technical Feasibility
The first technique in the feasibility analysis is to assess the technical feasibility of the project, the extent to which the system can be
successfully designed, developed, and installed by the IT group. Technical feasibility analysis is, in essence, a technical risk analysis that
strives to answer the question: “Can we build it?”.
Many risks can endanger the successful completion of the project. First and foremost is the users’ and analysts’ familiarity with the
application. When analysts are unfamiliar with the business application area, they have a greater chance of misunderstanding the users or
missing opportunities for improvement. The risks increase dramatically when the users themselves are less familiar with an application,
such as with the development of a system to support a new business innovation (e.g., Microsoft starting up a new Internet dating service).
In general, the development of new systems is riskier than extensions to an existing syste, because existing systems tend to be better
understood.

Economic Feasibility
The second element of a feasibility analysis is to perform an economic feasibility analysis (also called a cost–benefit analysis). This attempts
to answer the question “Should we build the system?” Economic feasibility is determined by identifying costs and benefits associated with the
system, assigning values to them, calculating future cash flows, and measuring the financial worthiness of the project. As a result of this
analysis, the financial opportunities and risks of the project can be understood. Keep in mind that organizations have limited capital resources
and multiple projects will be competing for funding. The more expensive the project, the more rigorous and detailed the analysis should be.
Before illustrating this process with a detailed example, we first introduce the framework we will apply to evaluate project investments and
the common assessment measures that are used.

 Cash Flow Analysis and Measure: IT projects commonly involve an initial investment that procedures a stream of benefits over
time, along with some ongoing support costs. Therefore, the value of the project must be measured over time. Cash flows, both
inflows and outflows, are estimated over some future period. Then, these cash flows are evaluated using several techniques to
judge whether the projected benefits justify incurring the costs.

20
  Break-even point: Another common approach to measuring a project’s worth is the break-even point. The break-even point (also
called the payback method) is defined as the number of years it takes a firm to recover its original investment in the project cash
flow figure becomes positive during Year 3, so the initial investment is “paid back” over two years plus some fraction of the third
year.
The break-even point is intuitively easy to understand and does give an indication of a project’s liquidity, or the speed at which
the project generates cash returns. Also, projects that produce higher returns early in the project’s life are thought to be less risky,
since we can anticipate near-term events with more accuracy than we can long-term events. The break-even point ignores cash
flows that occur after the break-even point has been reached; therefore, it is biased against longer-term projects.

 Net Present Value (NPV)

The NPV is simply the difference between the total present value of the benefits and the total present value of the costs.
As long as the NPV is greater than zero, the project is considered economically acceptable. Unfortunately for this project, the NPV
is less than zero, indicating that for a required rate of return of 10%, this project should not be accepted. The required rate of return
would have to be something less than 6.65% before this project returns a positive NPV. This example illustrates the fact that
sometimes the “naïve” techniques of ROI and BEP find that the project appears acceptable, but the more rigorous and financially
correct NPV technique finds the project is actually unacceptable.

Organizational Feasibility
The final techinique used for feasibility analysis is to assess the organizational feasibility of the system: how well the system ultimately
will be accepted by its users and incorporated into the ongoing operations of the organization. There are many organizational factors that
can have an impact on the project, and seasoned developers know that organizational feasibility can be the most difficult feasibility
dimension to assess. In essence, an organizational feasibility analysis attempts to answer the question “If we build it, will they come?”

21
 Figure 9. Simple Cash Flow Projection

The champion is a high-level executive and is usually, but not always, the project sponsor who created the system request. The champion
supports the project by providing time and resources (e.g., money) and by giving political support within the organization by
communicating the importance of the system to other organizational decision makers. More than one champion is preferable because if
the champion leaves the organization, the support could leave as well.
While champions provide day-to-day support for the system, organizational management also needs to support the project. Such
management support conveys to the rest of the organization the belief that the system will make a valuable contribution and that necessary
resources will be made available. Ideally, management should encourage people in the organization to use the system and to accept the
many changes that the system will likely create.

22
The final feasibility study helps organizations make wiser investments regarding IS because it forces project teams to consider technical,
economic, and organizational factors that can affect their projects. It protects IT professionals from criticism by keeping the business units
educated about decisions and positioned as the leaders in the decision-making process. Remember—the feasibility study should be revised several
times during the project at points where the project team makes critical decisions about the system (e.g., before the design begins). The final
feasibility study can be used to support and explain the critical choices that are made throughout the SDLC.

23
Reference
1. Dennis, Wixom, Roth. “System Analysis & Design”, 2023.
2. R. G. Sabale, Dr. A. R. Dani. “Risk Management Using Spiral Model for Information Technology”, 2012.
3. Ian Sommerville, “Software Engineering”, Addison Wesley, 2004.
4. CTG. MFA – 003, “A Survey of System Development Process Models”, Models for Action Project: Developing Practical Approaches to
Electronic Records Management and Preservation, Center for Technology in Government University at Albany / Suny, 1998.
5. Steve Easterbrook, “Software Lifecycles”, University of Toronto Department of Cumputer Science, 2001.
6. Rlewallen, “Software Development Life Cycle Models”, 2005.
7. Barry Boehm, “Spiral Development Experience, Principles, and Refinements”, edited by Wilfred J. Hansen, 2000.

24