ASSIGNMENT 1 FRONT SHEET

Qualification BTEC Level 5 HND Diploma in Computing

Unit number and title Unit 9: Software Development Life Cycle

Submission date 26/1/2020 Date Received 1st submission

Re-submission Date Date Received 2nd submission

Student Name Le Phuc Vinh Tuong Student ID GCD191271

Class GCD0806 Assessor name srikanthraju

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 Tuong

Grading grid

P1 P2 P3 P4 M1 M2 D1 D2
 Summative Feedback:  Resubmission Feedback:

Grade: Assessor Signature: Date:

Internal Verifier’s Comments:

Signature & Date:

 Catalog
INTRODUCTION.......................................................................................................................................................... 6

SOFTWARE DEVELOPMENT LIFE CYCLE MODEL.............................................................................................................8

SDLC MODELS.......................................................................................................................................................... 11

I. Waterfall:...................................................................................................................................................................11

II. The V-model:............................................................................................................................................................ 14

III. Prototyping model :................................................................................................................................................ 18

IV. Scrum Model:..........................................................................................................................................................21

V. Spiral model:............................................................................................................................................................22

LEVEL OF RISK EFFECTS OF MODELS.............................................................................................................................26

1. WHAT IS THE SUITABLE SDLC MODEL FOR THE TUNE SOURCE SOFTWARE PROJECT?........................................... 27

2. RISKS AND THE WAY TO MANAGE THEM IN THE SOFTWARE PROJECT:..................................................................28

3. WHAT IS RISK MANAGEMENT AND WHY WE NEED TO MANAGE RISK IN SOFTWARE PROJECT?..........................30

4. THE PURPOSE OF CONDUCTING A FEASIBILITY STUDY FOR THE PROJECT:...................................... 43

5. FEASIBILITY CRITERIA AND TECHNICAL SOLUTIONS:................................................................................................45

REFERENCES..................................................................................................................................................................48
Image 1 : SDLC Model.............................................................................................................................................9

Image 2 : Basic phases in software development with SDLC................................................................................. 9

Image 3 : WaterFall...............................................................................................................................................11

Image 4 : V- Model............................................................................................................................................... 15

Image 5 : Prototyping........................................................................................................................................... 18

Image 6 : Scrum Model.........................................................................................................................................21

Image 7 : Spiral Model..........................................................................................................................................23

Image 8 : Rick Management................................................................................................................................. 31

Table 1 : Spiral Model Phases...............................................................................................................................25

Table 2 : Advantages and Disadvantages............................................................................................................ 25

Table 3 : Risk classification................................................................................................................................... 32

 INTRODUCTION
Tune Source is a company headquartered in southern California. Tune Source is the brainchild of three
entrepreneurs with ties to the music industry: John Margolis, Megan Taylor, and Phil Cooper. Originally,
John and Phil partnered to open a number of brick and mortar stores in southern California specialising
in hard-to-find and classic jazz, rock, country, and folk recordings. Megan soon was invited to join the
partnership because of her contacts and knowledge of classical music. Tune Source quickly became
known as the place to go to find rare audio recordings. Annual sales last year were $40 million with
annual growth at about 3%–5% per year. Tune Source currently has a website that enables customers to
search for and purchase CDs. This site was initially developed by an Internet consulting firm and is hosted
by a prominent local Internet Service Provider (ISP) in Los Angeles. The IT department at Tune Source has
become experienced with Internet technology as it has worked with the ISP to maintain the site.

System Request

Project Sponsor: Carly Edwards, Assistant Vice President, Marketing

Business Need: This project has been initiated to increase sales by creating the capability of selling digital
music downloads to customers through kiosks in our stores, and over the Internet using our website.

Business Requirements: Using the Web or in-store kiosks, customers will be able to search for and
purchase digital music downloads. The specific functionality that the system should have includes the
following:

 Search for music in our digital music archive.

 Listen to music samples.
 Purchase individual downloads at a fixed fee per download.
 Establish a customer subscription account permitting unlimited downloads for a monthly fee.
 Purchase music download gift cards.

Business Value: We expect that Tune Source will increase sales by enabling existing customers to
purchase specific digital music tracks and by reaching new customers who are interested in our unique
archive of rare and hard-to-find music. We expect to gain a new revenue stream from customer
subscriptions to our download services. We expect some increase in cross-selling, as customers who
have downloaded a track or two of a CD decide to purchase the entire CD in a store or through our
website. We also expect a new revenue stream from the sale of music download gift cards.

Conservative estimates of tangible value to the company include the following:

 $757,500 in sales from individual music downloads

 $950,000 in sales from customer subscriptions
 $205,000 in additional in-store or website CD sales
 $153,000 in sales from music download gift cards

Special Issues or Constraints:

 The marketing department views this as a strategic system. The ability to offer digital music
downloads is critical in order to remain competitive in our market niche. Our music archive of
rare and hard-to-find music is an asset that is currently underutilized.
 Many of our current loyal customers have been requesting this capability, and we need to
provide this service or face the loss of these customers’ business.
 Because customers have a number of music download options available to them elsewhere, we
need to bring this system to the market as soon as possible.
 SOFTWARE DEVELOPMENT LIFE CYCLE MODEL
In this section, I will define and illustrate five of the Life Cycle Creation Software Models that include:

Waterfall SDLC Model, V-shaped SDLC Model, Agile SDLC Model, Spiral SDLC Model and Prototyping
Model.

I'm also going to offer my collection and description of the lifecycle app development model I guess.

Identify those risks and discuss an approach to handling the project would be the most effective for the
aforementioned project.

WHAT IS SOFTWARE DEVELOPMENT LIFE CYCLE?

System Development Lifecycle (SDLC) is the development process that identifies structure,

approaches, business needs, designing, building, and delivers a software system clearly and

transparently, SDLC applied to develop a software system with high quality, useful and reliable to

customers.

There are 5 models of SDLC available, namely: Waterfall model, RAD model, Bigbang model, Iterative

model, V-shaped model, Spiral model, Incremental Model and Agile model. Each SDLC model has its

own advantages and disadvantages and suitable for each different elements of system.
 Image 1: SDLC Model

In General, there are four basic phases in software development with SDLC, including planning,

analysis, design, and implementation.

Image 2: Basic phases in software development with SDLC

The above stages are all carried out sequentially from the beginning of the planning process to the
conclusion of the planning period.

Phase of creation (providing products to users).

However, depending on the various projects, it is important to illustrate additional phases in the process.

Creation process or addressing these stages of development in a particular way (iterative, incremental...)

SDLC models usually include some part of the following activities: ▪ Planning and Visualization

▪ Requirement Analysis

▪ Software Modeling and Design

Figure 3: SDLC Operations (Manzoor Ahmad Rather, Mr. Vivek Bhatnagar, 2015)

▪ Coding

▪ Documentation

▪ Testing

▪ Deployment and Maintenance

I will give a description and explanation of each SDLC model below.

 SDLC MODELS
I. Waterfall:

Image 3: WaterFall

First presented by Dr. Winston W. Royce in an article published in 1970, The Waterfall Model describes a
software development process. The waterfall model focuses on the logical progression of the steps taken
during the software development life cycle (SDLC), like the steps in which a stream of water falls over a
waterfall. Although the popularity of this model has decreased significantly over the past few years as
more agile methods are preferred, the natural logic of the sequential process used in this method is not.
undeniable, and it is still a common design process in the IT industry.

1. 6 phases of the waterfall model:

The actual application of the waterfall model in a project is a fairly straightforward process, thanks in
large part to the step-by-step feature of the model itself. Depending on the developer (or at the time)
there are slight variations in the numbers and details of the steps in a waterfall model. But for the most
part, all concepts are the same and have a broad vision of the steps to take with an idea and developing
a complete application.

 Identifying the requirements: With the first phase, the possible requirements of an application are
analyzed systematically with the aim of creating a specific document for future development. The
 result to be achieved in this phase is a document describing the requirements that define what the
application will perform, but not specifically how it will function.

 Analysis: In the next phase, the system is analyzed so that it can generate a suitable model and logic
of the system that will be used in the application.

 Design: This phase largely deals with technical design requirements, such as programming languages,
data layers, services, etc. A typical design will be completed as specifically as possible. It will describe
exactly how the system logic mentioned in the analysis will be executed.

 Coding: The final coding work is done in this fourth phase, which implements all the models, logic of
the system, and integration services that have been clarified in the previous phases.

 Testing: At phase five, QA, Beta tester, and all testers will search and report bugs in the system that
need to be addressed. Usually when this phase there will be some repetitive (but necessary) work of
the Coding phase, so that the detected technical errors will be completely resolved.

 Operation: Finally, the application will be deployed in the real environment. However, the operation
phase is not just about getting the project out of the way, it also includes support and maintenance
to keep the application up to date

2. Advantages of the waterfall model.

Although the waterfall model has gradually disappeared over the past few years in favor of more agile
models, it still offers a number of benefits, especially in large projects and organizations that need
Completion stages and stages of work lie within these waterfalls.

 Well-adapted to flexible groups: Although not only the waterfall model has this advantage, its
application helps the whole project be well maintained, has an overarching goal and structured
design thanks to sketching and documenting beforehand. This is great for large groups that often
have members leaving or joining new during the project life cycle. It allows the core design of a
project to be placed primarily within a particular document, not just one team member.
 Imposing a tightly structured organization: This can be seen as a burden rather than an advantage,
but the truth is to maintain the waterfall model that captures the project, and even organizes a the
project is extremely precise, strictly following its design and construction. Large projects will need to
include specific processes to manage all aspects of the project, from design and development to
testing and implementation.

 Allow early design changes: Although it will be difficult to make design changes at later stages, the
waterfall method makes implementing changes at the beginning of the application lifecycle fairly
easy. Since there is no code or any implementation at this stage, editing documents is quick and
extremely simple.

 Suitable for landmark-oriented projects: When applying the sequence structure of a waterfall
model, projects are great for organizations that are well-performing based primarily on landmarks or
dates. With its clear and specific phases, the team members can easily understand and prepare for it.
It's also simpler to have a schedule for the entire process and set a few specific dates or milestones
for each stage. Of course this does not mean that software development is not delayed, but the
waterfall model will be suitable for projects with deadlines.

3. Disadvantages of the waterfall model:

Although a few times when Dr. Royce first announced it, the waterfall model was considered a major
breakthrough in 1970. After more than four centuries, a few major downsides have shown why the
difficult model is still desirable. waited as expected and was replaced by today's Agile models.

 Poor adaptive design constraint: Although it is possible to write a separate book on the subject, the
most important shortcoming of the waterfall model is the ability to adapt to change throughout the
entire development cycle. When testing in the fifth phase reveals some errors in the system design,
it not only requires a big step backwards to the old steps, in some cases also destroys the integrity of
the whole system. system. While the vast majority of teams and experienced programmers will have
a hard time making such late findings in the first place, this can still happen, especially when phases
are typically left at the end. of the whole cycle.
 Ignore user feedback at the following stages: Because there is a strict step-by-step process, the
waterfall model has difficulty getting user feedback at later stages of the product life cycle. Project
manager can of course bring the process back to previous stages because of new requirements or
changes from the client, but this would be extremely costly and time consuming for both the
development team and the customer.

 Delayed testing time: While most modern SDLC models include testing as an inevitable part and
always throughout every development process, the waterfall model to test into end of life cycle. Not
only does this make the majority of technical errors or even design problems undetected until the
end of the life cycle, it also easily causes the habit of writing poor quality code as testing is usually
quite small. and too late.

4. When to apply Waterfall:

 Apply Waterfall when it best understands the project's requirements, requirements are clear and
have high stability.

 Mastering the developed technology.

 There are no ambiguous requirements.

 Rich development resources and high technical expertise.

 Suitable for small and short term projects.

II. The V-model:

The V-model is a type of SDLC model where process executes in a sequential manner in V-shape. It is
also known as Verification and Validation model. It is based on the association of a testing phase for
each corresponding development stage. Development of each step directly associated with the testing
phase. The next phase starts only after completion of the previous phase i.e. for each development
activity, there is a testing activity corresponding to it.
 Image 4: V- Model

Verification: It involves static analysis technique (review) done without executing code. It is the
process of evaluation of the product development phase to find whether specified requirements meet.

Validation: It involves dynamic analysis technique (functional, non-functional), testing done by

executing code. Validation is the process to evaluate the software after the completion of the
development phase to determine whether software meets the customer expectations and
requirements.

So V-Model contains Verification phases on one side of the Validation phases on the other side.
Verification and Validation phases are joined by coding phase in V-shape. Thus it is called V-Model.
1. Stages in the V model:

a) Design Phase:

 Requirement Analysis: This phase contains detailed communication with the customer to
understand their requirements and expectations. This stage is known as Requirement Gathering.
 System Design: This phase contains the system design and the complete hardware and
communication setup for developing product.
 Architectural Design: System design is broken down further into modules taking up different
functionalities. The data transfer and communication between the internal modules and with the
outside world (other systems) is clearly understood.
 Module Design: In this phase the system breaks dowm into small modules. The detailed design of
modules is specified, also known as Low-Level Design (LLD).
b) Testing Phases:

 Unit Testing: Unit Test Plans are developed during module design phase. These Unit Test Plans are
executed to eliminate bugs at code or unit level.
 Integration testing: After completion of unit testing Integration testing is performed. In
integration testing, the modules are integrated and the system is tested. Integration testing is
performed on the Architecture design phase. This test verifies the communication of modules
among themselves.
 System Testing: System testing test the complete application with its functionality, inter
dependency, and communication.It tests the functional and non-functional requirements of the
developed application.
 User Acceptance Testing (UAT): UAT is performed in a user environment that resembles the
production environment. UAT verifies that the delivered system meets user’s requirement and
system is ready for use in real world.
Industrial Challange: As the industry has evolved, the technologies have become more complex,
increasingly faster, and forever changing, however, there remains a set of basic principles and
concepts that are as applicable today as when IT was in its infancy.

 Accurately define and refine user requirements.

 Design and build an application according to the authorized user requirements.
 Validate that the application they had built adhered to the authorized business requirements.
2. Principles of V-Model:

 Large to Small: In V-Model, testing is done in a hierarchical perspective, For example,

requirements identified by the project team, create High-Level Design, and Detailed Design phases
of the project. As each of these phases is completed the requirements, they are defining become
more and more refined and detailed.
 Data/Process Integrity: This principle states that the successful design of any project requires the
incorporation and cohesion of both data and processes. Process elements must be identified at
each and every requirements.
 Scalability: This principle states that the V-Model concept has the flexibility to accommodate any
IT project irrespective of its size, complexity or duration.
 Cross Referencing: Direct correlation between requirements and corresponding testing activity is
known as cross-referencing.
 Tangible Documentation: This principle states that every project needs to create a document. This
documentation is required and applied by both the project development team and the support
team. Documentation is used to maintaining the application once it is available in a production
environment.
3. Advantages:

 This is a highly disciplined model and Phases are completed one at a time.
 V-Model is used for small projects where project requirements are clear.
 Simple and easy to understand and use.
 This model focuses on verification and validation activities early in the life cycle thereby enhancing
the probability of building an error-free and good quality product.
 It enables project management to track progress accurately.
4. Disadvantages:

 High risk and uncertainty.

 It is not a good for complex and object-oriented projects.
 It is not suitable for projects where requirements are not clear and contains high risk of changing.
 This model does not support iteration of phases.
 It does not easily handle concurrent events.
5. When to use?:
 Where requirements are clearly defined and fixed.
 The V-Model is used when ample technical resources are available with technical expertise.
III. Prototyping model :
Prototyping is defined as the process of developing a working replication of a product or system that
has to be engineered. It offers a small scale facsimile of the end product and is used for obtaining
customer feedback as described below:

Image 5: Prototyping
The Prototyping Model is one of the most popularly used Software Development Life Cycle Models
(SDLC models).This model is used when the customers do not know the exact project requirements
beforehand. In this model, a prototype of the end product is first developed, tested and refined as per
customer feedback repeatedly till a final acceptable prototype is achieved which forms the basis for
developing the final product.

In this process model, the system is partially implemented before or during the analysis phase thereby
giving the customers an opportunity to see the product early in the life cycle. The process starts by
interviewing the customers and developing the incomplete high-level paper model. This document is
used to build the initial prototype supporting only the basic functionality as desired by the customer.
Once the customer figures out the problems, the prototype is further refined to eliminate them. The
process continues until the user approves the prototype and finds the working model to be
satisfactory.

1. four types of Prototyping model available:

A) Rapid Throwaway Prototyping

This technique offers a useful method of exploring ideas and getting customer feedback for each of
them. In this method, a developed prototype need not necessarily be a part of the ultimately accepted
prototype. Customer feedback helps in preventing unnecessary design faults and hence, the final
prototype developed is of better quality.

B) Evolutionary Prototyping
In this method, the prototype developed initially is incrementally refined on the basis of customer
feedback till it finally gets accepted. In comparison to Rapid Throwaway Prototyping, it offers a better
approach which saves time as well as effort. This is because developing a prototype from scratch for
every iteration of the process can sometimes be very frustrating for the developers.

C) Incremental Prototyping

In this type of incremental Prototyping, the final expected product is broken into different small pieces
of prototypes and being developed individually. In the end, when all individual pieces are properly
developed, then the different prototypes are collectively merged into a single final product in their
predefined order. It’s a very efficient approach which reduces the complexity of the development
process, where the goal is divided into sub-parts and each sub-part is developed individually. The time
interval between the project begin and final delivery is substantially reduced because all parts of the
system are prototyped and tested simultaneously. Of course, there might be the possibility that the
pieces just not fit together due to some lack ness in the development phase – this can only be fixed by
careful and complete plotting of the entire system before prototyping starts.

D) Extreme Prototyping

This method is mainly used for web development. It is consists of three sequential independent phases:
D.1) In this phase a basic prototype with all the existing static pages are presented in the HTML format.

D.2) In the 2nd phase, Functional screens are made with a simulate data process using a prototype
services layer.

D.3) This is the final step where all the services are implemented and associated with the final
prototype.

2. Advantages :

 The customers get to see the partial product early in the life cycle. This ensures a greater level of
customer satisfaction and comfort.
 New requirements can be easily accommodated as there is scope for refinement.
 Missing functionalities can be easily figured out.
 Errors can be detected much earlier thereby saving a lot of effort and cost, besides enhancing the
quality of the software.
 The developed prototype can be reused by the developer for more complicated projects in the
future.
 Flexibility in design.
3. Disadvantages :

 Costly w.r.t time as well as money.

 There may be too much variation in requirements each time the prototype is evaluated by the
customer.
 Poor Documentation due to continuously changing customer requirements.
 It is very difficult for developers to accommodate all the changes demanded by the customer.
 There is uncertainty in determining the number of iterations that would be required before the
prototype is finally accepted by the customer.
 After seeing an early prototype, the customers sometimes demand the actual product to be
delivered soon.
 Developers in a hurry to build prototypes may end up with sub-optimal solutions.
 The customer might lose interest in the product if he/she is not satisfied with the initial prototype.
When to use?

The Prototyping Model should be used when the requirements of the product are not clearly
understood or are unstable. It can also be used if requirements are changing quickly. This model can be
successfully used for developing user interfaces, high technology software-intensive systems, and
systems with complex algorithms and interfaces. It is also a very good choice to demonstrate the
technical feasibility of the product.

IV. Scrum Model:

Scrum is a framework for projects. It falls under the agile methodology and defines roles, procedures,
tools, processes to make sure to deliver an efficient and effective project well on time through
iterative development cycles. As per a report, there are almost 70% of the software teams who use
scrum or scrum hybrid.

Image 6: Scrum Model

This methodology is basically followed where there is the demand of high development process, high
involvement of stakeholders. Scrum methodology repeatedly monitors software development while
the project is being developed.
Scrum Software Development Methodology has a major focus on the responsibility, teamwork, and
iterative progress towards a well-defined business goal.

1. Advantages:

 Transparent system pushes developers to comply with their assignments and deliver it on time.

 Defined deadline at every step keep developers motivated and empowered at every step.

 Feedback at every level of the project ensures that quality project is delivered in the end.

2. Disadvantages:

 Difficult to plan, structure and organize a project with no clear mission and vision.

 Frequent changes in the project lead to a delay in the delivery time of the project.

 Utilizes more resources and stakeholder’s involvement in every small detail change and discussion.

V. Spiral model:

Spiral model is one of the most important Software Development Life Cycle models, which provides
support for Risk Handling. In its diagrammatic representation, it looks like a spiral with many loops.
The exact number of loops of the spiral is unknown and can vary from project to project. Each loop of
the spiral is called a Phase of the software development process. The exact number of phases needed
to develop the product can be varied by the project manager depending upon the project risks. As the
project manager dynamically determines the number of phases, so the project manager has an
important role to develop a product using spiral model.

The Radius of the spiral at any point represents the expenses(cost) of the project so far, and the
angular dimension represents the progress made so far in the current phase.
Below diagram shows the different phases of the Spiral Model:

Image 7: Spiral Model

Each phase of Spiral Model is divided into four quadrants as shown in the above figure. The functions
of these four quadrants are discussed below-
1. Objectives determination and identify alternative solutions: Requirements are gathered from the
customers and the objectives are identified, elaborated and analyzed at the start of every phase.
Then alternative solutions possible for the phase are proposed in this quadrant.
2. Identify and resolve Risks: During the second quadrant all the possible solutions are evaluated to
select the best possible solution. Then the risks associated with that solution is identified and the
risks are resolved using the best possible strategy. At the end of this quadrant, Prototype is built
for the best possible solution.
3. Develop next version of the Product: During the third quadrant, the identified features are
developed and verified through testing. At the end of the third quadrant, the next version of the
software is available.
4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so far
developed version of the software. In the end, planning for the next phase is started.
1. Why Spiral Model is called Meta Model ?
The Spiral model is called as a Meta Model because it subsumes all the other SDLC models. For
example, a single loop spiral actually represents the Iterative Waterfall Model. The spiral model
incorporates the stepwise approach of the Classical Waterfall Model. The spiral model uses the
approach of Prototyping Model by building a prototype at the start of each phase as a risk handling
technique. Also, the spiral model can be considered as supporting the evolutionary model – the
iterations along the spiral can be considered as evolutionary levels through which the complete system
is built.

2. Spiral Model Phases:

Spiral Model Phases Activities performed during phase

 Identification of potential risk is done while risk

mitigation strategy is planned and finalized
Risk Analysis
  It includes testing, coding and deploying
software at the customer site
Engineering

 Evaluation of software by the customer. Also,

includes identifying and monitoring risks such
Evaluation as schedule slippage and cost overrun

Table 1: Spiral Model Phases

3. Spiral Model Advantages and Disadvantages:

Advantages Disadvantages
 Additional functionality or changes can be done
 Risk of not meeting the schedule or budget
at a later stage

 Cost estimation becomes easy as the prototype  Spiral development works best for large projects
building is done in small fragments only also demands risk assessment expertise

 Continuous or repeated development helps in  For its smooth operation spiral model protocol
risk management needs to be followed strictly

 Development is fast and features are added in a  Documentation is more as it has intermediate
systematic way in Spiral development phases

 Spiral software development is not advisable for

 There is always a space for customer feedback
smaller project, it might cost them a lot

Table 2: Advantages and Disadvantages

 LEVEL OF RISK EFFECTS OF MODELS

WATERFALL MODEL V-MODEL AGILE-MODEL

-Use when requirements are very clear and fixed. -Use for small and medium - Use for projects that are fickle, with no clear
projects with well-defined requirements.
-Short project, stable product definition, no vague
requirements.
requirements - To implement a new feature, developers only need to
-Technical resources work a few days, or even just a few hours.
- The technology used is well understood by the
available with required
team. - Unlike waterfall model in agile model requires specific
technical expertise.
plan to get started.
- Resources with the required expertise are
- It is necessary to depend
available - Any changes can be discussed. New features can then
on customer confidence to
be implemented or removed based on customer
- Customer interaction has very little effect on choose a V-model
feedback. This enables customers to get the system they
product development. When the product is ready, approach. Since there are
want.
it can only be tested by the end user. no prototypes given, the
risk is very high related to Both the system developer and the stakeholders find that
-When the product is in development and if any meeting customer they also have more freedom of time and choice than if
problems occur the cost of fixing such problems is expectations. row.
the software is developed in a rigid sequential manner.
very high because we need to update everywhere
from documentation to logic. - When changes are needed. Such changes can be done
very quickly and at a low cost.
1. WHAT IS THE SUITABLE SDLC MODEL FOR THE TUNE SOURCE SOFTWARE PROJECT?

As a project manager, I propose designing this project with the use of Spiral software with the
description and study of two iterative and bi-sequential life cycle software models.

Let me explain briefly the product Tune Source and its architecture layout to show that my claim is
plausible, that the SDLC model Spiral is sufficient.

First, I notice in the first project that Tune Source Company's annual growth and annual revenues are a
strong, capable company, with annual growth of approx. 3 percent – 5 percent each year. The purpose of
this project is to raise sales and build new sources of income through significant financial capability. They
are prepared to pay large prices for making the right tech product to prevent the first spiral dilemma
(which is costly to apply in the project).

Second, the business Tune Root has internet experience and skills, as its website helps consumers to
search and purchase CDs. You have also worked on the website of Internet consultancy firms and ISPs.
The development of Spiral model would offer great advantages for the project. The Adapted Source
Company would be able to fix the issues they had when they developed and managed their previous
website system; it will easily come up with plans to solve the problems or improvements in the spiral
implementation life cycle for this project as well as to resolve others. As I said, the Spiral focuses on
assessing and handling the threats and obstacles posed by clients. It is an essential investment project
such that a perfect, low-risk project is of the utmost importance.

Third, it's a major undertaking. Much of this is difficult with the feature needs and the link between
hardware and software; certain mechanisms require time to create and build systematically. This
includes processes (payment mechanism, security mechanism, authentication mechanism, advanced
database ...). Because of the complexity of certain functions and the time taken to create a helical
pattern, features can be built easily and systems build based on their complexity. For each stage of
development, the spiral pattern outlines a tight spiral which may be replicated as anomalies occur in one
of the stages following assessment and adjustment.The project will remain fluid and 11 threats of time
testing and functions will be readily considered without creating any hurdles. This will allow the project
to operate smoothly. This is all why the spiral model fits with this initiative. These are all my breakdowns
of why the helical model for this project works.

Next, I will identify some of the risks that the project encounters when applying the spiral model and the
direction in which to manage those risks.

2. RISKS AND THE WAY TO MANAGE THEM IN THE SOFTWARE PROJECT:

In this section, I will describe what risk is, why we need to manage risk in a software project.

A. WHAT IS RISK?

Risk is part of project development for any company in any industry. Many projects run into risks that
threaten their success and keep it from growing.

Risk is defined as any factor that affects the success of project development. The probabilities of an
event, proposition or requirement and their consequences for the project are all considered risk.

Types of risks in software development projects

Many threats can compromise the success of software development projects. Sample risks in software
projects include:

Management doesn't prevent delays and failures, leading to unrestricted spending.

The management using the project management framework is not suitable for project management.

The project design does not have the requirements of the user and the quality standards of the IT
department.

SDLC documentation ignores important aspects like data security.

An information system lacks controls to ensure valid and accurate transaction processing.

Common causes of these types of risks in software development

The crash can happen at any stage of SDLC. Let's take a look at some of the common reasons for seen
bugs in software development.
 Technology is always changing:

Technology changes rapidly, and software developers must adapt. Over time, the industry adopts new
development platforms, tools, techniques, standards, and protocols. These changes make software
development quite unpredictable.

Continuing training is critical in engineering to reduce the risks that come with new technology. Project
failures are sometimes the result of misapplication of proven tools.

The same applies when choosing the application and system architecture to use. Coding in the wrong
environment could mean an impending project failure. Extensive consulting can help the team choose
the best platform for the project.

 Change in request:

Engineering projects begin with understanding all of the user's needs while remembering system
features, functions and services. Collecting requests are often tedious and long.

For example, some stakeholders may have personal agendas and they'll ignore anything that threatens
to block their plans. Furthermore, user needs can grow at the prototyping and integration stages of the
product.

Adjustments may be needed throughout the software development process. However, some changes in
user requests do not automatically translate into functional requirements. Discrepancies can lead to
project failure.

 Incomplete performance test:

Most business applications are accessible to users at different levels depending on whether they are
managers, employees or vendors. An essential factor to note is data security, furthermore when third
parties are part of the end user.

A vulnerable software product can make an organization vulnerable to cybercrime. Product inspection
throughout the project is very important to ensure that all modules are working as intended.
 Organizational problem:

Project management is at the heart of creating successful software products. The team leader must plan
the team to develop the needs, as well as the customer expectations, in order to effectively implement
the project. The manager must find the talent that matches the different project tasks.

If the project manager has problems communicating, developers may misinterpret the project's scope.
The team may eventually miss deadlines or build a product that doesn't match customer expectations.
There must be a policy around stakeholder engagement and information sharing to avoid
misunderstandings.

B. The danger of the Tune Root Company project includes:

 Economic danger (inability to finance project development ...)

 Environmental threats (errors in construction, implementation and design, deterioration of project

quality ...)

 Planing chance (project development planning and work allocation unreasonable making project
deadlock ...)

 Corporate threats (producing products to market that do not meet customer expectations and fail
value...)

 Vulnerability qualifying (project participants are not qualified in project development, analysis and
assessment of related issues ...)

3. WHAT IS RISK MANAGEMENT AND WHY WE NEED TO MANAGE RISK IN SOFTWARE PROJECT?

Risk management is the process of identifying, evaluating, planning responses, and reacting to
events/conditions, both positive and negative, that can occur throughout the life of a project. The goal of
project risk management is to increase the likelihood and/or effect of positive risks (opportunities) and
to reduce the likelihood and/or impact of negative risks (threats), to Optimize your project's chances of
success.
Risks should be identified and managed from the start of a project and regularly updated while the
project is in progress. The Project manager and team review what happened in the project, the project's
current status, and what hasn't happened, then reassess potential hazards and opportunities.

Image 8: Rick Management

A. Risk classification:

A standardized list of risks, it can help us ensure that risks are not missed in the implementation of
projects. Are these categories in common sectors or from sources of risk experienced by the company or
similar projects.

Regulatory, current law, environmental,

External risks government issues; market shifts; the issue of
project execution locations.

Change about the process or budget; change the

Internal risk
scope; inexperienced team members; issues of
 people, human resources, consulting, and
equipment..

Technical risk Changes in technology, process engineering

Stability of customers, terms and conditions in

Commercial risk
contracts, suppliers.

Only a small fraction of the risk (about 10%) is

Unforeseen risks
unpredictable.

Table 3: Risk classification

B. Risk management process:

Must understand the risk management process is very important in project management. We must know
what will happen and when and understand that risk management can change the way project is
managed. For large projects, proper risk management is an integral part of the planning process. The
seven risk management processes include:

 Risk management planning

 Identify your risks

 Perform a qualitative analysis of risks

 Perform a quantitative risk analysis

 Planning for risk response

 Implementation of risk response

 Risk monitoring

1. Risk management planning process:

Once the risk management planning is completed, we have a risk management plan in place.
  Risk strategy

 Methodology

 Roles and responsibilities

 Funding

 Timing

 Risk categories

 Risk appetite / thresholds

 Definitions of risk probability and World

 Probability and impact matrix

 Reporting formats

 Tracking

2. Risk identification process:

a) Risk register:

Risk register is a list of individual identified risks of the project, helping to capture details of risk. The
results of performing qualitative analysis, risk response planning, implementation of risk response and
risk monitoring will also be recorded in the risk registers.

- List of identified risks: Risks should be presented with the most clarity and specificity. Each individual
risk is provided with a unique identifier in the risk register.

- Potential risk owners: Potential risk owners (will be explained below) that can be identified at this
process, and will be reconfirmed during qualitative analysis.

- Potential response plan: There will be times when the response is determined concurrently with the
risk. These potential response options should be added to the risk registers once the risk is identified and
will be confirmed during the risk response planning process.
 - Root Cause of Risk: Provide valuable information for later use for risk response planning and risk
reassessment in the project, as well as for project reference. Future. A risk is likely to reappear in the
project if its root cause has not been identified and addressed.

- Updated risk portfolio: Our project can detect new types of risks, and can add to the standard
corporate checklist.

b) Risk report:

- Overall project risk sources: Identifies the most important factors that lead to the overall risk of the
project.

- Summary information on individual risks: Summary information such as number of identified threats
and opportunities, allocating risk across categories of risks, trends, ...

- Additional information: May be included in the risk report, subject to the reporting requirements
specified in the risk management plan.
3. The process of performing risk analysis:

Key tools and techniques used in the process of performing risk analysis:

- Risk data quality assessment:

- Risk probability and impact assessment : We need to consider the likelihood of a particular risk, as well
as assess its impact, considering its impact on one or more of the project's objectives such as progress,
cost, quality, and quality or performance. Low-impact and probable risks can be included in the risk
register, in the form of a watchlist for future follow-up.

- Evaluation of other parameters: The project team may consider other risk characteristics (other than
the likelihood and impact) when assessing the priority for individual risks.

- Risk categorization: Project risks can be classified according to the following sections, to define the
project scopes most affected by uncertainty:

 Sources of risk (eg, use the risk breakdown structure - RBS)

 Project affected areas (for example, use the work breakdown structure - WBS)
 Common root causes.
 4. Do a risk analysis:

 Compare Qualitative Risk Analysis and Quantitative Risk Analysis:

Qualitative risk analysis Quantitative risk analysis

Less often done, depending on the project type, the project risk and the
Usage level Usually done with all risks, all projects
availability of the data used to conduct the quantitative analysis.

Prioritize risks using a predefined rating scale. Further analysis of the highest priority risks.

Quantify the possible outcomes of the project and evaluate the probability of
achieving specific project objectives.
Risks will be scored based on their likelihood and
How to do it impact on project objectives if they occur. Provides a quantitative approach to decision-making when there is uncertainty.

Create a realistic and achievable cost, schedule, or range goal

The appropriate risk classification will also be To perform quantitative risk analysis, required: high quality input data, project
included. risk priority list (from qualitative risk analysis process)

Analytical level In the individual risk layer At the project floor

Subjective assessment of likelihood and impact of

Purpose Evaluate the probability of estimating the project time and cost
risks

Nature Easy and fast execution It takes time to do it

Support tools No special tools or software needed Need some special engineering tools
5. Planning for risk response:
Risk response strategies
Strategy Use Purpose Act

Avoid is when the project team takes

Examples of Avoid actions can include
action to remove the threat or
The overall risk / risk of the removing the cause of a threat, extending
protect the project from its impact.
Avoid project progress, changing the project strategy, or
Avoiding may involve changing some
Likely to happen is Has high priority, impact, reducing scope. Some risks can be avoided
aspect of the project management
zero and probability of by clarifying requirements, gathering
plan or changing the endangered
occurrence information, improving communication or
target to completely eliminate the
gaining expertise..
threat, reducing its likelihood to zero

An extraction strategy can be

selected for high-priority
For example, responses might include
opportunities for which the
assigning the organization's most talented
Exploit Opportunities / risks
organization wants to ensure that the
personnel to a project to reduce
overall in the project
100% chance of opportunity is realized. This strategy
completion times, using new technology or
happening High priority seeks to capture the benefits
upgrading technology to reduce costs, and
associated with a particular
time.
opportunity by ensuring that it
inevitably happens, increasing the
 probability of occurrence by 100%.

in risk reduction, action is taken to

reduce the likelihood of a threat Examples of threat mitigation include
appearing and / or impacting. Early adopting less complex procedures,
The overall risk / risk of the mitigation action is often more conducting more tests, or choosing a more
project effective than trying to repair stable contractor, designing redundancy
Mitigate
damage after a threat has occurred. for a complex system could reduce impact
There is priority, high
on the project due to malfunction of the
impact Where the likelihood cannot be
system components.
reduced, mitigation action can reduce
the impact by targeting factors that
increase the severity.

The Enhance Strategy is used to

increase the likelihood and / or
When probabilities cannot be increased,
impact of opportunities. Early
Opportunities / risks impact can be increased by targeting
reinforcement is often more effective
Enhance overall in the project factors that increase the magnitude of the
than trying to improve benefits after
There is priority, high benefit. Examples of enhanced
an opportunity has occurred. The
impact opportunity include adding more
likelihood of an opportunity can be
resources to the activity ending early.
increased by focusing attention on its
cause..
 Transfer includes the transfer of a The transfer can be achieved by a variety
threat to a third party to manage the of actions, including but not limited to: the
The overall risk / risk of the
Transfer risk and be affected if a threat occurs. use of insurance, deposits, warranties,
project
Transfer of risk usually involves guarantees, ... Agreements can be used to
Has low priority
paying part of the cost of the risk to transfer liability. Risks specific to another
the risk taker. party..

Share involves passing an opportunity

to a third party to re-share some of
Opportunities / risks the benefits if an opportunity occurs. Examples of sharing include forming a
Share
overall in the project It is important to choose the third partnership, group, company, or joint

Has low priority party shared carefully so that they venture to share opportunities.
can best capture the opportunity for
the benefit of the project.

Escalate is appropriate where the

Threats / opportunities are usually
project team or sponsor agrees that a
presented up to the level of relevance to
threat / opportunity is outside the
the target that will be affected if a threat /
Threats / Opportunities scope of the project or the proposed
Escalate opportunity occurs.
Has low priority risk response would be beyond the
Project Manager's jurisdiction. Threats / opportunities submitted are NOT
further monitored by the project team
Risk escalated will be managed at the
after reporting, although they may be
program, portfolio or other relevant
 parts of the organization, NOT the recorded in the risk register
project level.

Taking the risk acknowledges the The most common strategy for positive
existence of a threat / opportunity, acceptance is to set a contingency, which
but NO proactive action is taken. This includes time, budget, or resources to deal
strategy can be suited to low priority with the threat or take advantage of
Risk / Opportunity / risk
threats / opportunities and it can also opportunities if it happens (contingency
Accept overall the project
be applied when it is not possible or reserves).
Has low priority ineffective to address threats /
Passive acceptance does not include taking
opportunities in any way. other.
active action beyond periodic review to
Acceptance can be either active or ensure that risks do not change
passive. significantly
6. Implementation of risk response:

Implementation of risk responses is the process of implementing the agreed risk response plans,
ensuring that the agreed risk response plans are implemented to address the overall project risks,
minimize threats and maximize individual project opportunities.

7. Risk monitoring:

Risk management involves the monitoring phase of enforcing the negotiated risk action strategy, the
evaluation of defined threats, the discovery and review of potential risks and the evaluation of the
regulation's performance. The whole project's Risk Officer. Risk monitoring helps one to take project
decisions on the basis of existing project risk information and risk information. This is accomplished in
the project.

To ensure that the project team and stakeholders are aware of the current level of risk, continuous
monitoring of new project risks, changed or obsolete risks and changes about the overall level of risk of
the project by applying a risk monitoring process. Risk monitoring determines whether:

 Are the risk response measures implemented effectively?

 How has the overall project risk level changed?

 How has the status of individual risks changed?

 How new risks have arisen?

 Is risk management still appropriate?

 Are the project assumptions still valid?

 How are risk management policies and procedures being followed?

 How are contingency reserves for the cost or progress requested by the revision?

 Is the project strategy still valid

 C. RISK IN TUNE SOURCE SOFTWARE PROJECT AND THE WAY TO MANAGE THEM:

I will give some of the risks that I think will happen in Tune Source's project using the Spiral SDLC model; I also provide solutions and
approaches to manage those risks.

RISK ASSESSMENT

Risk level Reason Solution

The overall risk / risk of Development for Tune Set up a search and pick the relevant personnel
the project Source will be delayed if
Picked forum for experience.
project team members do
High probability of risk
not use them or do not ensuring guaranteed jobs for all workforce
RISK 1 have much experience in
Thier project experience. We can test and split up their talents into project
implementing them.
stages, each with varying degrees and levels of difficulty. Difficult duties are
allocated to skilled workers and suitable tasks are reserved for staff of
medium to low qualifications.

The overall risk / risk of Project development not  Plan and set milestones of development stages
RISK 2 the project meeting proposal
 Consensus is required based on development.
Average probability of risk plan, causing the project  procedure,
to be delayed, overdue.
 Select technology to be developed.

 Handling of the risks involved.

4. THE PURPOSE OF CONDUCTING A FEASIBILITY STUDY FOR THE PROJECT:

A. WHAT IS FEASIBILITY STUDY, WHAT IS THE BENEFITS OF FEASIBILITY STUDY IN

SOFTWARE PROJECT?

 The feasibility report lets corporate executives and consumers identify the crucial challenges in the

the project, such as time viability to meet targets, project costs, extent of implementation

Realization.

 The feasibility study attempts to examine the benefits and drawbacks of a software product, The
probability and possibility of success until they consent and invest a great deal of time, commitment
and resources on the production of the proposal.

 Stop blind trust in projects that could cause the business difficulties.

B. THE PURPOSE OF FEASIBILITY STUDY IN DEVELOP A SOFTWARE PROJECT:

 Implementation studies typically focus on the following project elements when agreeing to develop:

Economy: project economic development, financing and start-ups required to prosper

What is the benefit of the project or project? Compete and opportunities for the market.

Organization: project personnel tools. The management structure of the organization follows the
specifications of the project. The experience and skills of the company workforce in executing programs.

Technology: The project' s technical factors include how the product is designed to satisfy the project's
business needs (technological specifications, growth, implementation process, design, etc.).

 The key facets of the project feasibility analysis are:

 Consider project viability: consider project feasibility, target customers,

The opportunity for actual success, the challenges and setbacks faced by the team. It too It

Support quantify the costs needed to produce a perfect commodity for a client
Investing in growth.

 Investigate sector and company growth opportunities: by looking at projects through feasibility

The study study, leadership and the initiative can achieve success

Business from which to decide and approach the project.

 Save time and money: Feasibility tests have major financial and time repercussions

makes sense with respect to the time and expense needed for a software project .

Planning ideas are subject to publishing during the development and execution of a project

The challenge, the probability of the project loss. This lowers the construction time for projects.

And costs at the point of production.

 Opportunity to identify and evaluate risks: Risks in software projects will be studied further

detailed in the planning stage and based on each software development life cycle model.

However, with the initial risks identified and evaluated from the feasibility study, the risks are large

that makes the project difficult or delayed will be considered.

 Feasibility study to ensure the feasibility of the project from economic to technical. It will help the
company and the client determine whether this project should work or not if the project is worth
the investment.

C. FEASIBILITY STUDY IN TUNE SOURCE SOFTWARE PROJECT:

A feasibility analysis helps to decide whether the project is feasible for the Tune Root project.

The following problems in the project will be investigated before the release decision via the feasibility
study.

 Should we satisfy Tune Source's market specifications for our project?

 What is the reason why and ought we to do the project of Tune Source? Will this project have any
advantages?

 What are the big threats posed during the whole life of the project? The effect on the project of
these risks? Is it possible to resolve or minimize those risks?

 Is the project sponsored by new ideas? What is that? What is that? Is it true or unrealistic? What is
the opportunity for growth?

 Is this initiative going to fulfill the human capital and tools? Have staff familiarity of work?

 What is this project's projected budget? Will the construction budget project have any effect on any
details?

The feasibility study would improve the company's chances of completion, along with Tune Source, with
a detailed vision of the planned project.

5. FEASIBILITY CRITERIA AND TECHNICAL SOLUTIONS:

A. FEASIBILITY CRITERIA:
In this section, I will discuss and outline the implementation of the three requirements of viability,
including technical ones in the Tune Source project, fiscal, operational. I share my view on whether this
proposal is viable or not, through the aforementioned review.

 Applying the three parameters of viability including the scientific, economic and organizational
criteria Tune Source, I will sequentially carry out the following tasks:

 Step 1: Goods produced by this project; specifics of Tune Source Company's market requirements;
and Tune Source Company knowledge and the project.

 Step 2: Evaluating the industry challenges encountered by the project and the excess of the
demographic that is reached by the Tune Root Project.

 Step 3 (Economic analysis): The costs involved in carrying out the project, the income produced by
the project, guaranteeing the payback and problems which affect the expense of developing the
projects, the degree of control.
 Step 4 (Technical Analysis): The technologies available for project creation, the functions that meet
the needs of the organization, the need to use company technology and the need to improve
functions, etc.

 Step 5: Consider what the human capital are needed to carry out the project, experience, know-how,
knowledge etc. (organization analysis).

 Step 6 (Time Analysis): is the time needed for the production of the Tune Source, relative to the
time needed, is the project planned or issues impacting the progress created by the congestion of
the project.

 Step 7 (Study and Decision): review the project's feasibility study from the above stages and
determine whether or not it is to execute the project.

B. DOES THE PROJECT FEASIBLE?

I consider this to be a possible and feasibility project, based on the above-mentioned phases of the
feasibility study.

First, The project targets to customers who are dedicated to Tune Source and to anyone who constantly
finds rare tracks on the internet. First, this is a website music service provider project.

Second, since Tune Source is a business with great income and credibility, they still hold expertise in
creating and managing goods from the internet, which previously discovered and marketed songs.

Thirdly, the latest technologies are enough to accommodate the opportunities for growth

A collaborative project between payment systems, hosting, platform supply and consumer project

Related allocation to other goods such as (e-commerce platforms) so that they won't be

Complicated to build, update and manage potential programs.

D. ALTERNATIVE TECHNICAL SOLUTIONS:

 ALTERNATIVE TECHNICAL SOLUTIONS IN TUNE SOURCE SOFTWARE PROJECT:

To return to the Tune Source project we would revisit the business specifications of the project, which
functions should have included in the functionality required by the Tune Source, before suggesting
technical solutions for this draft.

The Tune Source company's order is:

 Assist clients in the digital media library and scan for music.

 Help consumers to hear before buying music samples.

 Support for billing, which allows users to buy downloads at a fixed charge. • Support in billing, that
helps clients buy musical gift cards for download.

 Provides an account recording system which enables customers to download unlimited music

and a subscription charge to listen to

 Refine, update support and music archive creation. Support the best use of this framework

Currently. Actually.

We have two sides to consider on the basis of the above applications by Tune Source

The first thing we will do, is to use HTML, CSS and JavaScript, along with certain frameworks and gui for
Tune, since this is a website at the front end of the website Tune Source of music service.

Second, the music discovery and suggestion algorithm processing, payment processing, client account
management, a strong database system coordination, etc. The website has many programming
languages, such as C #, Ruby, PHP, etc. and much context, and framework. The website has many
development languages to pick from.

The pile comprises components including (Operating System Server, Web Server, Application Server,
Database Server, and Back-end Programming Language). The stack relies on various systems and
programming languages; each stack is targeted at meeting the unique needs of each software framework.
 REFERENCES
Anon., n.d. The Software Development Life Cycle (SDLC), s.l.: s.n.
Dennis, A. and Haley, W., 2009. Systems Analysis and Design.. s.l.:John Wiley & Sons Ltd..
Divya Tanwar, 2016. SOFTWARE DEVELOPMENT MODELS AND THEIR REAL ASPECTS, s.l.:
s.n.
Haneen Hijazi, Thair Khdour & Abdulsalam Alarabeyyat, 2012. A Review of Risk Management in
Different Software, s.l.: s.n.
Kim, D. Y., 2019. A Design Methodology Using Prototyping Based on the Digital-Physical Models
in the Architectural Design Process, s.l.: s.n.
Manzoor Ahmad Rather, Mr. Vivek Bhatnagar, 2015. A COMPARATIVE STUDY OF SOFTWARE,
s.l.: s.n.
Nabil Mohammed Ali Munassar & A. Govardhan, 2010. A Comparison Between Five Models Of
Software Engineering, s.l.: