BTEC Level 5 HND Diploma in Computing: SDLC Report Analysis

This report provides a detailed analysis of the Software Development Life Cycle (SDLC), exploring both sequential and iterative software lifecycle models. It examines the Waterfall, Parallel, and V-model approaches within sequential models, and Iterative development, System Prototyping, and Throwaway Prototyping within iterative models. The report also delves into software risk management, explaining the risk management process and its application to a case study. Furthermore, it emphasizes the importance of feasibility studies, covering technical, economic, and organizational feasibility, and comparing technical solutions. The report concludes with an evaluation of solutions for a hypothetical scenario, summarizing the key aspects of SDLC and its practical implications.

ASSIGNMENT 01 FRONT SHEET
Qualification BTEC Level 5 HND Diploma in Computing
Unit number and title Unit 09: Software Development Life Cycle
Submission date Date Received 1st submission
Re-submission Date Date Received 2nd submission
Student Name Nguyễn Việt Hà Student ID GCH200035
Class GCH0903 Assessor name Đỗ Quốc Bình
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
Grading grid
P1 P2 P3 P4 M1 M2 D1 D2

❒ Summative Feedback: ❒ Resubmission Feedback:
Grade: Assessor Signature: Date:
Internal Verifier’s Comments:
Signature & Date:

Table of Contents:
I. Introduction ....................................................................................................................................................................................................................................... 5
II. The diffểrent systems development lifecycles.......................................................................................................................................................................... 5
1. Iterative and sequential software lifecycle models ..................................................................................................................................................................... 5
a. Sequential software lifecycle models ............................................................................................................................................................................................ 5
b. Iterative software lifecycle models ............................................................................................................................................................................................... 9
c. The best model for the project .................................................................................................................................................................................................... 14
2. Software Risk Management ........................................................................................................................................................................................................ 16
a. Risk management explanation and process .............................................................................................................................................................................. 16
b. Applying the concepts at Tune Source ...................................................................................................................................................................................... 17
III. The importance of feasibility study .................................................................................................................................................................................... 18
1. The purpose of feasibility study ............................................................................................................................................................................................. 18
2. Technical Feasibility ................................................................................................................................................................................................................ 19
3. Economic Feasibility................................................................................................................................................................................................................ 20
4. Organizational Feasibility ....................................................................................................................................................................................................... 21
5. How technical solutions can be compared ............................................................................................................................................................................. 23
6. Evaluate solutions for Tune Source ....................................................................................................................................................................................... 25
IV. Conclusion ........................................................................................................................................................................................................................ 26

Table of Figures:
Figure 1: Waterfall Development (Roth, Dennis and Wixom, 2013) .......................................................................................................................................................... 6
Figure 2: Parallel development (Roth, Dennis and Wixom, 2013) ............................................................................................................................................................. 7
Figure 3: V-model (Roth, Dennis and Wixom, 2013) ................................................................................................................................................................................. 8
Figure 4: Iterative development (Roth, Dennis and Wixom, 2013) .......................................................................................................................................................... 10
Figure 5: System Prototyping (Roth, Dennis and Wixom, 2013) .............................................................................................................................................................. 11
Figure 6: Throwaway Prototyping (Roth, Dennis and Wixom, 2013) ...................................................................................................................................................... 12
Figure 7: Extreme Programming (Roth, Dennis and Wixom, 2013) ......................................................................................................................................................... 13
Figure 8: Criteria for Selecting a Methodology (Roth, Dennis and Wixom, 2013) .................................................................................................................................. 14
Figure 9: Sample Risk Assessment (Roth, Dennis and Wixom, 2013) ..................................................................................................................................................... 17
Figure 10: Feasibility Analysis Assessment Factors (Roth, Dennis and Wixom, 2013) ........................................................................................................................... 19
Figure 11: Simple Cash Flow Projection (Roth, Dennis and Wixom, 2013) ............................................................................................................................................ 21

I. Introduction
A software development cycle is required for successful projects, thus this report will explain and assess the four software development processes or
software, as well as conduct research and analyze the feasibility stage. and construct Different methodologies for programming progress models are
chosen for the project. Furthermore, there are several models for designing huge, extremely efficient applications available today. Finally, the author will
examine the responses in order to determine the most appropriate, progressive, and practicable project configurations.
II. The diffểrent systems development lifecycles
According to Roth, Dennis and Wixom (2013), the system development life cycle is a key process that all system development initiatives follow
(SDLC). The SDLC begins with the planning phase, in which the project team determines the system's commercial value, conducts a feasibility study,
and develops a project plan. The team establishes an analysis strategy, obtains data, and creates a set of analysis models in the second phase, which is
the analysis phase. The team produces the design strategy, physical design, architecture design, interface design, database and file requirements, and
program design in the following step, the design phase. The system is constructed, implemented, and maintained in the last step, implementation.
1. Iterative and sequential software lifecycle models
a. Sequential software lifecycle models
Waterfall Development (Roth, Dennis and Wixom, 2013):
In waterfall development, analysts and users move from one phase to the next in a logical order. As the project progresses from phase to phase, the
primary deliverables for each phase are often voluminous (sometimes hundreds of pages) and are given to the approval committee and project sponsor
for approval. The work completed in one phase is authorized, and the next step begins. As the project proceeds from phase to phase, it flows like a
cascade. It is possible to travel backwards through the phases (for example, from design to analysis), but it is extremely difficult. (Imagine swimming
upstream in a waterfall like a salmon.)

Figure 1: Waterfall Development (Roth, Dennis and Wixom, 2013)
Waterfall development approaches offer the benefit of establishing requirements well before programming begins and restricting needs modifications
as the project progresses. The main drawbacks are that the design must be fully stated before programming can begin, that there is a considerable period
between the completion of the system proposal in the analysis phase and the delivery of the system, and that testing is virtually an afterthought in the
implementation phase. Furthermore, because deliverables are frequently a poor means of communication, critical needs may be lost in the voluminous
paperwork. If a key need is overlooked by the project team, costly post-implementation programming may be required. Because so much time has passed
between the initial idea and the actual implementation, users may forget the system's initial goal. Furthermore, in today's changing business world, a
system that suited the current environmental circumstances during the analysis phase may require significant modification when it is implemented to
meet the environment. This rework necessitates returning to the first step and making necessary modifications in each of the succeeding stages one by
one.
Parallel development

Figure 2: Parallel development (Roth, Dennis and Wixom, 2013)
Waterfall development may be divided into two types. Parallel development approaches arose in response to the prolonged timeframes associated
with waterfall development. Instead of designing and implementing the system in order, a general design for the entire system is carried out. The project
is then separated into a number of subprojects, each of which may be developed and implemented independently. When all of the subprojects are finished,
the system is provided after a final integration of the various components (Roth, Dennis and Wixom, 2013).
Because parallel development minimizes the time it takes to deploy a system, rework is less likely as a result of changes in the business environment.
The method still has issues due to the large number of deliverables. It also introduces a new issue: if the subprojects are not totally autonomous, design
decisions in one subproject may have an impact on another, and merging the subprojects at the conclusion of the project may be difficult (Roth, Dennis
and Wixom, 2013).
V-model

The V-model is a version of waterfall development that places a greater emphasis on testing. The development process progresses down the left-hand
slope of the V, establishing requirements and creating system components, as shown in Figure 2-4. The code is written at the base of the V. Component
testing, integration testing, and eventually acceptance testing are all done on the model's upward-sloping right side. This model's main premise is that
when requirements and components are developed, testing for those aspects is also established. Each level of testing is therefore explicitly related to a
section of the analysis or design phase, ensuring high-quality and relevant testing while also maximizing test effectiveness (Roth, Dennis and Wixom,
2013).
Figure 3: V-model (Roth, Dennis and Wixom, 2013)

The V-model is basic and intuitive, and it enhances overall system quality by emphasizing early test plan preparation. Testing experience and emphasis
are brought to the project sooner rather than later, and testers obtain early understanding of the project. However, it still suffers from the rigidity of the
waterfall development approach and is not necessarily suitable for dynamic environments (Roth, Dennis and Wixom, 2013).
b. Iterative software lifecycle models
Rapid Application Development (RAD) (Roth, Dennis and Wixom, 2013)
Rapid application development is a group of approaches that arose in reaction to the flaws and variants of waterfall development. Special techniques
and computer tools are used in RAD to speed up the analysis, design, and implementation phases in order to get a component of the system produced
and into the hands of users for assessment and feedback as rapidly as possible. CASE (computer-assisted software engineering) tools, JAD (joint
application development) sessions, fourth-generation/visual programming languages (e.g., Visual Basic.NET), and code generators all have a role to play
in RAD. While RAD can speed up and increase the quality of system development, it may also cause issues with managing user expectations. User
expectations may substantially rise and system needs may extend during the project when technologies are created more quickly and users get a deeper
grasp of information technology (sometimes known as scope creep or feature creep).

Figure 4: Iterative development (Roth, Dennis and Wixom, 2013)
RAD can be done in a number of ways. Iterative development divides a project into many versions that are produced in order. The system's first
version includes the most critical and essential needs. This version is produced fast using a mini-waterfall approach, and users may contribute useful
input that will be included into the next version of the system once it is deployed. Iterative development provides business value by swiftly delivering
an early version of the system to users. Important additional requirements may be found and added into succeeding versions when users interact with
the system. The main downside of iterative development is that consumers are forced to work with a deliberately unfinished system. Users must
recognize that only the system's most important needs will be provided in early versions, and they must be patient when new system versions are
introduced.

Figure 5: System Prototyping (Roth, Dennis and Wixom, 2013)
System prototyping combines the analysis, design, and implementation processes to create a reduced version of the proposed system that can be
given to users for input and review. The system prototype is a "fast and dirty" version of the system with limited functionality. The developers
reanalyze, rethink, and reimplement a second prototype that corrects problems and adds new features in response to customer feedback. This cycle is
repeated until the analysts, users, and sponsor agree that the prototype is functional enough to be deployed and utilized in the company. System
prototyping offers consumers with a system to assess rapidly and reassures them that progress is being made. When users have trouble communicating
system needs, this method comes in handy. However, prior to making design and execution decisions, there is a dearth of comprehensive, rigorous
examination. Early in the project, an inadequate grasp of the system's genuine needs may result in certain basic design restrictions in system
prototypes.
Throwaway Prototyping (The description of the throwaway prototyping is a modified version of the Spiral Development Model)

Figure 6: Throwaway Prototyping (Roth, Dennis and Wixom, 2013)
The development of prototypes is included in throwaway prototyping, although the prototypes are used largely to investigate design possibilities
rather than as the real new system (as in system prototyping). A rather detailed analysis step is performed in throwaway prototyping to gather requirements
and create ideas for the system design. However, many of the features suggested by users may be poorly understood, and there may be difficult
technological difficulties to resolve. Analyzing, developing, and creating a design prototype is used to investigate each of these challenges. A design
prototype isn't meant to be a fully functional system. It merely offers enough information to allow consumers to comprehend the issues at hand (Roth,
Dennis and Wixom, 2013).
Consider the case when users are unclear about how an order input system should operate. To assist people envision such a system, the analyst team
may create a set of HTML pages that can be accessed in a Web browser. A succession of mock-up screens look to be a system in this example, but they
accomplish nothing. Assume the project team is tasked with creating a complex graphics software in Java. To ensure that they could successfully develop
a full-fledged software, the team could build a piece of the program with false data (Roth, Dennis and Wixom, 2013).
During the analysis and design phases, a system produced using this process is likely to require numerous design prototypes. Each of the prototypes
is used to reduce the system's risk by ensuring that critical concerns are known before the real system is developed. The project goes into design and
implementation once the difficulties are overcome. The design prototypes are discarded at this phase, which is a significant distinction from system
prototyping, in which the prototypes grow into the final system (Roth, Dennis and Wixom, 2013).