Higher Nationals in Computing
Unit 9: Software Development Life Cycle
ASSIGNMENT 1
Learner’s name:HUYNH CONG HUY
ID: GCS210720
Class:GCS1005C
Subject code: 1631
Assessor name: PHAN MINH TAM
Assignment due: 18/ 2 / 2 0 2 3
Assignment submitted: 18 / 2/2023
ASSIGNMENT 1 FRONT SHEET
Qualification
BTEC Level 5 HND Diploma in Computing
Unit number and title
Unit 9: Software Development Life Cycle
Submission date
Date Received 1st submission
18/02/2023
Re-submission Date
Date Received 2nd submission
Student Name
Huynh Cong Huy
Student ID
GCS210720
Class
GCS1005C
Assessor name
Phan Minh Tam
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
Assignment Brief 01 (RQF)
Higher National Certificate/Diploma in Business
Student Name/ID Number:
GCS210720
Unit Number and Title:
Unit 09: Software Development Life Cycle
Academic Year:
Unit Assessor:
PHAN MINH TAM
Assignment Title:
Plan a software development life cycle
Issue Date:
07/12/2020
Submission Date:
18/2/2023
Internal Verifier Name:
Date:
Submission Format:
Format:
● The submission is in the form of 1 document.
● You must use the Times font with 12pt size, turn on page numbering; set line spacing to 1.3
and margins to be as follows: left = 1.25cm, right = 1cm, top = 1cm, bottom = 1cm. Citation
and references must follow the Harvard referencing style.
Submission:
● Students are compulsory to submit the assignment in due date and in a way requested by the
Tutor.
● The form of submission will be a soft copy posted on http://cms.greenwich.edu.vn/.
● Remember to convert the word file into PDF file before the submission on CMS.
Note:
1
● The individual Assignment must be your own work, and not copied by or from another
●
student.
If you use ideas, quotes or data (such as diagrams) from books, journals or other sources,
you must reference your sources, using the Harvard style.
● Make sure that you understand and follow the guidelines to avoid plagiarism. Failure to
comply this requirement will result in a failed assignment.
Unit Learning Outcomes:
LO1 Describe different software development lifecycles.
LO2 Explain the importance of a feasibility study.
Assignment Brief and Guidance:
Assignment scenario
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
2
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,
Tasks
we need to bring this system to the market as soon as possible.
Complete the following tasks:
3
Task 1 – SDLC model
You are a project manager of a company named ABC. Your company has been hired by Tune Source
to carry out a project that helps them develop a software for the requirements specified in the
system request. As the first step, you need to:
1. Describe the following SDLC models: waterfall, v-model, prototyping, scrum and spiral. Choose
one that you think suitable for the project and explain why.
● 350 - 500 words for each model.
● Explanation: 400 – 600 words.
Discuss the suitability of each of the SDLC models for the project. For each model, specify
whether it is most, moderately or least suitable.
● Word limit: 800 - 1000 words.
Discuss the merits of applying the waterfall model to a large software development project.
● Word limit: 800 – 1200 words.
2. Identify some risks and discuss an approach to manage them.
You will have the present what is Risk Management process with clear illustrations and
explanations.
Then you will create a Risk Management Matrix to assess and manage risks of Tune Source
project.
● Word limit: 600 – 1000 words.
Task 2 – Feasibility study
1. Discuss the purpose of conducting a feasibility study for the project.
● Word limit: 400 – 600 words.
2. Discuss how the three feasibility criteria (technical, economic, organizational) are applied to the
project. Discuss whether the project is feasible.
Discuss alternative technical solutions using the alternative matrix.
● Word limit: 1200 – 1500 words.
3. Explain the components of a feasibility report.
4
Discussion economic feasibility study on Tune Source project (NPV, Cashflow, Break-Even
Point)
● Word limit 350 – 500 words.
Discussion organizational feasibility study on Tune Source project
● Word limit 350 – 500 words.
4. Assess the impact of each feasibility criterion on a software investigation.
Discussion and represent as feasibility alternatives matrix for Tune Source project
● Word limit: 500 – 700 words.
Learning Outcomes and Assessment Criteria (Assignment 01):
Learning Outcome
LO1 Describe different
software development
lifecycles
Pass
P1 Describe two
iterative and two
importance of a
feasibility study
Distinction
M1 Describe, with an
D1 Assess the merits
particular lifecycle
Waterfall lifecycle
example, why a
sequential software
lifecycle models.
model is selected for a
P2 Explain how risk is
development
managed in the Spiral
environment.
lifecycle model.
LO2 Explain the
Merit
P3 Explain the
purpose of a feasibility
M2 Discuss the
report.
components of a
P4 Describe how
feasibility report.
technical solutions can
be compared.
5
of applying the
model to a large
software development
project.
D2 Assess the impact
of different feasibility
criteria on a software
investigation.
❒ Summative Feedback:
Grade:
❒ Resubmission Feedback:
Assessor Signature:
Date:
Signature & Date:
6
Catalog
Higher Nationals in Computing ......................................................................................................................................................................1
Assignment Brief 01 (RQF) ........................................................................................................................................................................... 1
Higher National Certificate/Diploma in Business .......................................................................................................................................... 1
ASSIGNMENT 1 ANSWERS ........................................................................................................................................................................8
1. Introduce SDLC .................................................................................................................................................................................................. 9
1.2. Purposes of SDLC ................................................................................................................................................................................... 9
2. Two sequential software lifecycle models ................................................................................................................................................10
2.1. Waterfall model ..................................................................................................................................................................................... 10
2.1.1. Definition ............................................................................................................................................................................................10
2.1.2. Advantages ......................................................................................................................................................................................... 11
2.1.3. Disadvantages .....................................................................................................................................................................................11
2.1.4. When to use ........................................................................................................................................................................................ 12
2.2. V-model .................................................................................................................................................................................................12
2.2.1. Definition ...................................................................................................................................................................................12
2.2.2. Advantages ......................................................................................................................................................................................... 13
2.2.3. Disadvantages .....................................................................................................................................................................................14
2.2.4. When to use ........................................................................................................................................................................................ 14
3. Two interactive software lifecycle models ............................................................................................................................................... 14
3.1. Incremental Development ......................................................................................................................................................................14
3.1.1. Definition ............................................................................................................................................................................................14
The various phases of incremental model are as follows: ...................................................................................................................... 15
3.1.2. Advantages ......................................................................................................................................................................................... 15
3.1.3. Disadvantages .....................................................................................................................................................................................16
3.1.4. When to use ........................................................................................................................................................................................ 16
3.2. Scrum .................................................................................................................................................................................................... 16
3.2.1. Definition ............................................................................................................................................................................................16
3.2.2. Advantages ......................................................................................................................................................................................... 18
3.2.3. Disadvantages .....................................................................................................................................................................................18
3.2.4. When to use ........................................................................................................................................................................................ 18
4. The model is used in the Tune Source project ..........................................................................................................................................18
P2 Explain how risk managed in the Spiral lifecycle model ........................................................................................................................ 19
1. Risk management ..................................................................................................................................................................................... 19
2. Risk management process ........................................................................................................................................................................ 20
3. Risk management matrix in Tune Source project ................................................................................................................................22
4. How to manage risks in the Spiral lifecycle project ............................................................................................................................. 24
Risk Assessment .................................................................................................................................................................................................. 24
P3 Explain the purpose of feasibility report ................................................................................................................................................. 25
1. What is feasibility study ........................................................................................................................................................................... 25
2. The purpose of feasibility report .............................................................................................................................................................. 26
3. Feasibility study on Tune Source project ................................................................................................................................................. 27
3.1. Economic feasibility .............................................................................................................................................................................. 27
3.2. Organizational feasibility ...................................................................................................................................................................... 27
3.3. Technical feasibility .............................................................................................................................................................................. 28
P4 Describe how technical solutions can be compared ................................................................................................................................29
1. What is requirements ................................................................................................................................................................................ 29
2. Types of requirements .............................................................................................................................................................................. 29
2.1. Functional requirements ........................................................................................................................................................................ 29
2.2. Non-functional requirements .................................................................................................................................................................30
3. How to determine requirements ................................................................................................................................................................31
4. Requirements elicitation techniques ......................................................................................................................................................... 32
4.1. Interviews .............................................................................................................................................................................................. 32
4.1.1. Steps ................................................................................................................................................................................................... 32
4.1.2. Selecting interviewees ........................................................................................................................................................................ 32
4.1.3. Designing interview questions ............................................................................................................................................................33
4.1.4. Preparing for the interview ................................................................................................................................................................. 34
4.1.5. Conducting for the interview ..............................................................................................................................................................34
4.1.6. Post-interview follow-up .................................................................................................................................................................... 34
4.2. Joint Application Development (JAD) .................................................................................................................................................. 34
4.2.1. Definition ............................................................................................................................................................................................34
4.2.2. Selecting participants ..........................................................................................................................................................................35
7
4.2.3. Designing the JDA session and Preparing for the JDA sessions ........................................................................................................ 35
4.2.4. Conducting the JDA session ...............................................................................................................................................................35
4.2.5. Post JAD follow-up ............................................................................................................................................................................ 36
4.3. Questionnaires ....................................................................................................................................................................................... 36
4.4. Document Analysis ............................................................................................................................................................................... 36
4.5. Observation ........................................................................................................................................................................................... 37
5. Comparison of requirements elicitation techniques ................................................................................................................................. 37
REFERENCES .............................................................................................................................................................................................38
ASSIGNMENT 1 ANSWERS
8
P1 Describe two iterative and two sequential software life cycle models
1. Introduce SDLC
1.1. Definition of SDLC
 SDLC is a method for developing software that assures the quality and accuracy of the finished
product. The SDLC process is designed to develop high-quality software that meets client
requirements. The system development should be completed within the schedule and budget
constraints. SDLC is a step-by-step process that outlines how to design, construct, and maintain
software. Each stage of the SDLC life cycle has its own set of processes and deliverables that
feed into the next. The Software Development Life Cycle (SDLC) is also known as the
Application Development Life Cycle
 The Software Development Life Cycle (SDLC) refers to a methodology with clearly defined
processes for creating high-quality software. in detail, the SDLC methodology focuses on the
following phases of software development:
• Requirement analysis
• Planning
• Software design such as architectural design
• Software development
• Testing
• Deployment
1.2. Purposes of SDLC
9
 The purpose of the SDLC approach is to provide IT Project Managers with the tools to help
ensure successful implementation of systems that meet the University's strategic and business
goals.
2. Two sequential software lifecycle models
2.1. Waterfall model
2.1.1. Definition
 The Waterfall Model displays the software development process in a linear sequential flow.
This means that every step of the development cycle can only begin once the previous step is
completed. In this model of the waterfall, the phases do not overlap. Illustration:
 Waterfall approach was the first SDLC model to be commonly used in software engineering to
ensure the performance of the project. The entire process of software development is split into
different phases in the "Waterfall" approach. Usually, the result of one step in this Waterfall
model serves as a sequential reference for the next process

Requirement Gathering and analysis − All possible requirements of the system to be developed are
captured in this phase and documented in a requirement specification document.
10

System Design − The requirement specifications from the first phase are studied in this phase and the
system design is prepared. This system design helps in specifying hardware and system requirements

and helps in defining the overall system architecture.
Implementation − With inputs from the system design, the system is first developed in small programs
called units, which are integrated into the next phase. Each unit is developed and tested for its



functionality, which is referred to as Unit Testing.
Integration and Testing − All the units developed in the implementation phase are integrated into a
system after testing of each unit. Post integration of the entire system is tested for any faults and failures.
Deployment of system − Once the functional and non-functional testing is done; the product is deployed
in the customer environment or released into the market.
Maintenance − There are some issues that come up in the client environment. To fix those issues,
patches are released. Also to enhance the product some better versions are released. Maintenance is
done to deliver these changes in the customer environment.
2.1.2. Advantages
-
It uses a clear structure.
-
The waterfall model determines the end goal early.
-
The waterfall model keeps a project to a specific timescale.
-
It reinforces good testing habits.
-
The progression of the waterfall model is intuitive.
It transfers information in superior ways when compared to other methodologies.
There are fewer financial surprises with the waterfall method.
2.1.3. Disadvantages
-
The waterfall model doesn’t support making changes.
-
This method excludes end-users and clients.
-
It can invalidate the work you’ve previously accomplished.
It delays testing until after the completion of the project.
The waterfall model can promote longer delivery times.
It typically works better for small projects.
Working models aren’t available until the latter stages of a project.
11
2.1.4. When to use
-
Requirements are clear and fixed that may not change.
-
It is good to use this model when the technology is well understood.
-
There are no ambiguous requirements (no confusion).
The project is short and cast is low.
Risk is zero or minimum.
2.2. V-model
2.2.1. Definition
 In computing, a parallel programming model is an abstraction of parallel computer architecture,
with which it is convenient to express algorithms and their composition in programs. The value
of a programming model can be judged on its generality: how well a range of different
problems can be expressed for a variety of different architectures, and its performance.
There are the various phases of Verification Phase of V-model:
12

Business requirement analysis: This is the first step where product requirements understood from
the customer's side. This phase contains detailed communication to understand customer's


expectations and exact requirements.
System Design: In this stage system engineers analyze and interpret the business of the proposed
system by studying the user requirements document.
Architecture Design: The baseline in selecting the architecture is that it should understand all which
typically consists of the list of modules, brief functionality of each module, their interface relationships,
dependencies, database tables, architecture diagrams, technology detail, etc. The integration testing


model is carried out in a particular phase.
Module Design: In the module design phase, the system breaks down into small modules. The detailed
design of the modules is specified, which is known as Low-Level Design
Coding Phase: After designing, the coding phase is started. Based on the requirements, a suitable
programming language is decided. There are some guidelines and standards for coding. Before checking
in the repository, the final build is optimized for better performance, and the code goes through many
code reviews to check the performance.
There are the various phases of Validation Phase of V-model:

Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module design phase.
These UTPs are executed to eliminate errors at code level or unit level. A unit is the smallest entity
which can independently exist, e.g., a program module. Unit testing verifies that the smallest entity can

function correctly when isolated from the rest of the codes/ units.
Integration Testing: Integration Test Plans are developed during the Architectural Design Phase.
These tests verify that groups created and tested independently can coexist and communicate among

themselves.
System Testing: System Tests Plans are developed during System Design Phase. Unlike Unit and
Integration Test Plans, System Tests Plans are composed by the client?s business team. System Test

ensures that expectations from an application developer are met.
Acceptance Testing: Acceptance testing is related to the business requirement analysis part. It includes
testing the software product in user atmosphere. Acceptance tests reveal the compatibility problems
with the different systems, which is available within the user atmosphere. It conjointly discovers the
non-functional problems like load and performance defects within the real user atmosphere.
2.2.2. Advantages

Easy to Understand.

Testing Methods like planning, test designing happens well before coding.

This saves a lot of time. Hence a higher chance of success over the waterfall model.
13

Avoids the downward flow of the defects.

Works well for small plans where requirements are easily understood.
2.2.3. Disadvantages

Very rigid and least flexible.

Not a good for a complex project.

Software is developed during the implementation stage, so no early prototypes of the
software are produced.

If any changes happen in the midway, then the test documents along with the required
documents, has to be updated.
2.2.4. When to use

When the requirement is well defined and not ambiguous.

The V-shaped model should be used for small to medium-sized projects where requirements are
clearly defined and fixed.

The V-shaped model should be chosen when sample technical resources are available with essential
technical expertise.
3. Two interactive software lifecycle models
3.1. Incremental Development
3.1.1. Definition
 Incremental development is a software development approach that focuses on breaking down
large projects into smaller, incremental tasks. This approach allows development teams to
focus on short iterations or "sprints" that can be completed in a much shorter time frame. By
taking this iterative approach, development teams can often progress faster, while giving them
the opportunity to process feedback and revise their plans as needed.
14
The various phases of incremental model are as follows:

Requirement analysis: In the first phase of the incremental model, the product analysis expertise
identifies the requirements. And the system functional requirements are understood by the requirement

analysis team. To develop the software under the incremental model, this phase performs a crucial role.
Design & Development: In this phase of the Incremental model of SDLC, the design of the system
functionality and the development method are finished with success. When software develops new

practicality, the incremental model uses style and development phase.
Testing: In the incremental model, the testing phase checks the performance of each existing function as
well as additional functionality. In the testing phase, the various methods are used to test the behavior of

each task.
Implementation: Implementation phase enables the coding phase of the development system. It involves
the final coding that design in the designing and development phase and tests the functionality in the
testing phase. After completion of this phase, the number of the product working is enhanced and
upgraded up to the final system product
3.1.2. Advantages
-
Generates working software quickly and early during the software life cycle.
This model is more flexible – less costly to change scope and requirements.
15
-
It is easier to test and debug during a smaller iteration.
-
Lowers initial delivery cost.
-
In this model customer can respond to each built.
3.1.3. Disadvantages
-
Needs good planning and design.
Needs a clear and complete definition of the whole system before it can be broken
down and built incrementally.
Total cost is higher than waterfall.
3.1.4. When to use






This model can be used when the requirements of the complete system are clearly defined
and understood.
Major requirements must be defined; however, some details can evolve with time.
There is a need to get a product to the market early.
A new technology is being used
Resources with needed skill set are not available
There are some high risk features and goals.
3.2. Scrum
3.2.1. Definition
 Scrum is a project management framework. It adheres to the agile approach and specifies roles,
procedures, tools, and processes to ensure that an efficient and successful project is delivered
on schedule via iterative development cycles (Jagdish Bhatt, 2021).
 The Scrum Software Development Methodology places a strong emphasis on accountability,
cooperation, and iterative progress toward a well-defined business goal (Jagdish Bhatt, 2021).
16

SCRUM TEAM: On the project, everyone works together to complete the set of tasks that they have
collectively committed to complete within a sprint. Consequently, scrum teams develop a profound

form of camaraderie and a feeling as well that “we’re all in this together.
PRODUCT BACKLOG: The Product Backlogs (which is the master list of all functionality desired in the
product) are maintained by scrum master. The product owner then describes the top items to the team.


The team then determines which items they can complete during coming sprint.
SCRUM MASTER: The Scrum Master facilitates the daily scrum and becomes responsible for removing
any hindrances that are brought up by the team during meetings.
PRODUCT OWNER: Product owner is a scrum development role for a person who represents the
business or user community and is responsible for working with the user group to determine what

features will be in the product release.
SPRINT: a fixed timeframe (usually two weeks) that is repeatedly
used to deliver selected features from the backlog. The objective is to produce valuable product

increments from each sprint.
SPRINT PLANNING: a collaborative event to kick off the sprint. The
planning session defines the overall goal of the sprint i.e. what backlog items the team will realistically
17
complete, and how that work will be done.
3.2.2. Advantages
-
A transparent system encourages developers to complete their tasks.
-
Feedback at each stage of the project guarantees that a high-quality result is produced.
-
Defined deadlines at each stage keep developers motivated and empowered at all times.
3.2.3. Disadvantages
-
It is difficult to plan, structure, and manage a project in the absence of a defined objective.
-
More resource are used, and stakeholders are involved in every minute detail modification.
-
Frequent modifications in the project cause a delay in the project's delivery schedule.
3.2.4. When to use
 Scrum is a simple agile process framework that is mostly used to manage software
development.
 Scrum is:






Lightweight due to the limited number of mandated elements
There are three roles: Product Owner, Scrum Master (typically a Project Manager), and
Team (often a Product Manager)
Sprint Planning, Daily Scrum, and Retrospective are the three meetings.
There are three artifacts: Burndown chart, Product Backlog, Sprint Backlog
Because it maximizes responsiveness to changing consumer demands, agile is a good choice.
A process framework is so named because it is not a process itself, but rather a set of
practices and concepts around which a process might be created
4. The model is used in the Tune Source project
 Scrum enables products to be fully functional throughout the development process, so testing
and adjustments can be made at any time.
 This methodology is well-suited to projects that require smaller delivery teams where
continuous development and implementation is required. Scrum’s testing functionality is
thorough, and adjustments can be made quickly.
18
 It’s an agile methodology that approaches projects from a Minimum Viable Product (MVP)
viewpoint, testing and improving on an ongoing basis. Scrum offers flexibility and ensures that
project managers are in constant contact with the development team.
 Although fixes and adjustments can be carried out quickly, changes aren’t always documented,
so precise planning is required before the project begins.
 Scrum’s methodology requires a high level of management, so senior developers often need to
be assigned the role of manager, overseeing progress.
P2 Explain how risk managed in the Spiral lifecycle model
1. Risk management
 Risk management is an activity of building a systematic and scientific process in order to find,
prevent and find solutions to minimize risks that may arise in the course of business activities.
business activities, causing disadvantages and limitations for enterprises. The implementation
of risk management plans not only helps to keep business activities and development goals on
track, but also a way for enterprises to actively seize new opportunities, improve its
competitive advantage in the market.
19
2. Risk management process
 Risk in business activities is a hidden factor that is difficult to detect and capture, so making a
risk management plan for an enterprise is always considered a difficult task. And in order for
the business to be able to perform the best risk management tasks, you need to implement a
methodical and detailed process.
Identify the Risks
 The four main risk categories of risk are hazard risks, such as fires or injuries; operational risks, including
turnover and supplier failure; financial risks, such as economic recession; and strategic risks, which
include new competitors and brand reputation.
 Being able to identify what types of risk you have is vital to the risk management process.
 Organizations can identify their risk through experience and internal history, consulting with an industry
professional, and external research.
 Other ways to identify risk within an organization includes interviews, group brainstorming, and focus
groups.
20
 Once an organization identifies their risk in each category, they can then analyze the risk in more detail.
 Risks management is an important process because it empowers a business with the necessary tools so
that it can adequately identify and deal with potential risks.
Analyze the Risk
 In many cases, problem resolution involves identifying the problem and then finding an appropriate
solution.
 However, before figuring out how best to handle risks, a business should locate the cause of the risks by
asking the question, “What caused such a risk and how could it influence the business?”
 For example, to determine the severity and seriousness of the risk it is necessary to see how many business
functions the risk affects.
 When a risk management solution is implemented one of the most important basic steps is to map risks to
different documents, policies, procedures, and business processes.
 This means that the system will already have a mapped risk framework that will evaluate risks and let you
know the far-reaching effects of each risk.
 Some questions to consider when analyzing risk include:




What can go wrong?
How will it effect the organization?
What can be done?
If something happens, how will the organization pay for it?
Evaluate or Rank the Risk
 Risks need to be ranked and prioritized from most severe to lowest level of risk.
 Risks that can be catastrophic to the organization are ranked highest while risks that simply just cause an
inconvenience are ranked lower on the list.
21
 By knowing the level of the risk and the impact it will have on the organization, management knows how
best to intervene if an when a series of risks occur.
Treat the Risk
 Now that your organization has identified the risks and ranked them in order of high to low, each risk
needs to be eliminated or contained as much as possible.
 This is usually done by connecting with the experts in each department or field to which the risk belongs to.
 Meeting with individuals to discuss the risk and solution is key to understanding how to eliminate or
contain as well as treat the risk should it happen.
Monitor and Review the Risk
 Unfortunately, there are some risks that cannot be completely eliminated and risk management isn't
something that has a start and finish, or end result.
 It is an ongoing process within an organization that is constantly changing.
 The organization, its environment, and its risks are constantly changing, so the process should be
consistently revisited.
 If an organization gradually formalizes its risk management process and develops a risk culture, it will
become more resilient and adaptable in the face of change.
3. Risk management matrix in Tune Source project
Risk
Cause

Time is not precisely
Effect

estimated
Schedule risk

Inadequate resource
The project's completion date
has been pushed back.

Placed the project participants
under a lot of stress
22
Posibility
40%
allocation

Project scope is frequently
expanded

Failure to identity and
complete a function.

Budget estimation that is

incorrect or incorrect

Budget risk

Make it harder to satisfy the
project's demands
Project scope expansion that

Affect project’s revenue
wasn’t expected

Causing budget loss
50%
Inappropriate budget
management

Budget tracking that isn’t up
to standard



Customer trust is eroded
management

Postpone progress

A decrease in product
There is less skilled member
performance
in team
Productivity
risk
Ineffective project

25%
Changes in requirement are
frequent

Implementation is really
difficult.


Make clients lose faith in you
requirement on a regular

A decrease in product
basis
Poor code
quality and
Changes in software

technical
performance
The technology used isn’t
10%
well-developed enough

There are numerous flaws in
the checking code.
23
4. How to manage risks in the Spiral lifecycle project
 Some risks that the Tune Source project may face :
Risk Assessment
Risk 1: Poor risk management
Inadequate risk management can be dangerous in and of itself. Effective risk
management is necessary for software development teams to recognize and respond
to concerns.
Likelihood of risk
Medium probability of risk
Ways to address this risk
 Identifying possible hazards
Potential impact on the project
This risk likely will increase the time to complete
programming task by 70%
 Determine the probability of each danger
 Developing risk mitigation strategies
Risk 2: Code Issues
 Risks must be carefully monitored
In software development, poor code quality is a severe risk. fail due to rushed work and a number of
other factors. When employing low-quality code, mistakes may occur when resolving defects and
logical projects. Bugs, logical errors, and other programming difficulties can arise.
Likelihood of risk
High probability of risk
Ways to address this risk
 Testing codes frequently
 Using coding best practices
Potential impact on the project
This risk likely will increase the time to complete
programming task by 90%
Risk 3: Low productivity
Productivity issues may potentially constitute a risk in software development.
Productivity issues in software development teams can emerge as a result of delays, employee
weariness, and a range of other factors
24
Likelihood of risk
Low probability of risk
Ways to address this risk
 Developing a well-paced project strategy to
reduce stress and prevent burnout
 Effectively communicating project
information and challenges.
Potential impact on the project
This risk likely will increase the time to complete
programming task by 60%
 Managing risks in a Spiral lifecycle project is an essential part of ensuring successful outcomes.
A few key steps can help you manage risk in a Spiral lifecycle project:





Identify risks: First, you should identify potential risks and create a risk register to track and
manage them.
Assess risks: Assess the potential impact of each risk and the likelihood of it occurring.
Develop action plans: Develop action plans to mitigate risks and create contingency plans in
order to plan for and respond to risks.
Monitor and review: Monitor progress against the risk register and regularly review it to
ensure risks are effectively managed.
Communicate: Openly communicate risks, action plans, and contingencies to stakeholders and
team members to ensure they are informed and aware of the situation.
P3 Explain the purpose of feasibility report
1. What is feasibility study
 A feasibility study is simply an evaluation of a proposed project plan or method's viability.
 This is accomplished by examining factors such as technical, economic, legal, operational, and
time feasibility. The feasibility study, also known as a feasibility analysis,serves as the
foundation foryour project plan. This is because the feasibility analysis determines the project's
viability
25
2. The purpose of feasibility report

Tune Source will need a feasibility assessment because its main product is rare recordings. Its
selling is predicated on the rarity and collectability of their recordings. This raises a slew of
possible concerns that must be addressed before considering regulations. Customers will be
able to search for and purchase digital music downloads through the Web or in-store kiosks.
26
3. Feasibility study on Tune Source project
3.1. Economic feasibility
 Economic feasibility is a sort of cost-benefit analysis of the project being examined which
determines whether it can be implemented. This concept involves assessing and analyzing the
potential of a project to help the decision-making process by critically and rationally defining
its related strengths, limitations, opportunities and threats, the resources that would be
required to execute the project, and determining its chances of success. This covers business
research, economic analysis, scientific analysis and strategic analysis.
Development Costs
Operational Costs
Development team
salaries
400.000$
Software updates fees
70.000$
Consultant fees
10.000$
Software licensing fees
10.000$
Office and equipment
200.000$
Hardware upgrades
50.000$
Training fee
150.000$
Operation system fees
100.000$
Hardware and software
70.000$
User training fees
50.000$
Server cost
5.000$
Vendor installation
15.000$
Tangible Value
Individual music downloads
679.000$
Customer subscription
850.000$
In-store of website CD sales
189.000$
Music download gift card
200.000$
3.2. Organizational feasibility
 Tune Source hopes to increase earnings by allowing existing customers to purchase specific digital music songs
and by reaching new consumers interested in our unique and hard-to-find music store.
 The project sponsors are early people who realize the potential of the project and decide to invest in support.
This program began with the goal of increasing sales by allowing us to sell digital music downloads to customers
through kiosks in our shops and on our website.
27
 According to some surveys, users claim that they are already excited about this project because they will be able
to buy some of the original tunes from the producer more easily.
3.3. Technical feasibility
 According requirement, Tune Source has given the project with all of the essential technology. CSS, JavaScript,
C#, HTML, and other technologies were used in the project.
 When it comes to building helpful features for the website, they make the project simple. These technologies
also make it easier to alter the website to fit the demands of consumers and project managers.
 The project makes use of server technologies. The website is built on a variety of servers, including a Web server,
SQL server, Database server, and others.
28
P4 Describe how technical solutions can be compared
1. What is requirements
 A requirement is a statement of what the system must do or what characteristics it needs to
have.
 Requirements describe:





What the business needs (business requirements)
What the users need to do (user requirements)
What the software should do (functional requirements)
Characteristics the system should have (non-functional requirements), and
How the system should be built (system requirements)
2. Types of requirements
2.1. Functional requirements
 Functional requirements are requirements that define the desired behaviour of a system or component. They
typically specify how a system should operate and what external interface services it should provide in order to
meet the needs of the users.
 The functionality of a system must be thoroughly specified in order for it to meet its intended purpose.
Functional requirements are typically tracked through use cases and specialized software applications.
Example of Functional Requirements
29
2.2. Non-functional requirements
 Non-functional requirements are requirements that define the quality of a system or component. These are
often related to performance, scalability, security, availability, flexibility, maintainability, and other attributes of
the system.
 Non-functional requirements must be clearly specified in order to ensure that the system meets the desired
quality standards. Non-functional requirements can be handled through design documents and test cases.
Example of Non-functional Requirements
30
3. How to determine requirements
 To determine the requirements for a project
Step 1: Create a plan
 Start by identifying relevant project stakeholders.
Next, decide:

What techniques you will use to identify and gather requirements.

How to document the various outputs from these activities.

How to finalize requirements with stakeholders.
Step 2: Identify and Gather Requirements




Reviewing existing documentation, such as the project plan, company strategy, and technical documents.
Observing end-users as they carry out their day-to-day tasks.
If the goal of the project is to improve an existing product or service, use this product/service as much as
possible.
Conduct workshops to map the ‘As-Is’ state for existing products and services.
Step 3: Review and Prioritize Requirements
 In this step, requirements are reviewed and analyzed against the goals and business case of the project.Record
the outputs in requirements documentation, for example, a simple table with high-level details. Be sure to
record any assumptions about the requirements along with processes for quality control.
Step 4: Finalize Requirements
 The approved document becomes an input to project scope, including the WBS, and acts as a performance
baseline during project execution.
 It’s also a good idea to create a Requirements Traceability Matrix, a document (or SharePoint list!) linking
requirements to deliverables.
 The document can include:

A unique requirement name and number.

A description of the requirement.

Categorization or a means of grouping similar requirements together.

Dependencies between requirements.

Processes for testing, validation, and quality control.

Relevant notes about the requirement.
Step 5: Manage Requirements
During project execution, you need to:
31
Ensure your team is working on activities to deliver the requirements.
Leverage the Requirements Traceability Matrix to manage change requests carefully to avoid scope creep.
Assess new requirements that emerge due to testing or quality checks.



4. Requirements elicitation techniques
The analyst should recognize that important side effects of the process of determining

requirements include buildingpolitical support for the project and establishing trust between
the project team and the users.
 The analyst should carefully determinewho is included in the process of determining
requirements
4.1. Interviews
4.1.1. Steps
The most commonly used requirementselicitation technique

Basic steps:






Selecting Interviewees
Designing Interview Questions
Preparing for the Interview
Conducting the Interview
Post-Interview Follow-up
4.1.2. Selecting interviewees

Interview schedule
32




Including people at different levels of the organization
Managers
Users
Other key stakeholders
4.1.3. Designing interview questions
33
4.1.4. Preparing for the interview
Prepare a general interview plan

Confirm areas of knowledge

Set priorities in case of time shortage




Prepare the interviewee
Schedule
Inform of reason for interview Inform of areas of discussion
4.1.5. Conducting for the interview
Appear to be professional and unbiased.

Record all information.

Be sure you understand the issues thatare discussed.

Separate facts from opinions.

Give interviewee time to ask questions,and brief explain what will

happen next.
4.1.6. Post-interview follow-up



After the interview, the analysts needs toprepare an interview report.
The report includes interview notes.
The report is sent to interviewee with a request to read it and inform the
analyst of clarification and updates
4.2. Joint Application Development (JAD)
4.2.1. Definition

JAD is an information gathering techniquethat allows the project
team, users, and management to work together to identify


requirements for the system.
It can reduce scope creep by 50%,
JAD is a structure process in which 10 to 20 users meet under the direction of
a facilitator skilled in JAD techniques.
34
4.2.2. Selecting participants
Name
Andria McCleallan
Jennifer Draper
Mark Goodin
Anne Asher
Position
Purpose of interview
Director, Accounting
Strategic vision for new
accounting system
Manager, Accounts Receivable
Current problem with accounts
receivable process
Manager, Accounts Payable
Current problem with accounts
receivable process
Supervisor, Data Entry
Accounts receivable and payable
processes
4.2.3. Designing the JDA session and Preparing for the JDA sessions
Types of Questions
Example
Closed-Ended Questions
Open-Ended Question

How many telephone orders are received per day ?

How do custom place orders ?

What information is missing from the months sales report ?

What do you think about the way invoices are currently processed ?

What are some of the problems you face on a daily basis ?

Probing Questions
What are some of the improvements you would like to see in the
way invoices are processed

Why ?

Can you give me an example ?

Can you explain that in a bit more detail ?
Including people at different levels of the organization


Managers

Users
Other key
stakeholders
4.2.4. Conducting the JDA session


Most JAD sessions follow formal agenda andground rules.
The JAD facilitator performs three keyfunctions:


Keep session on track, following the agenda.
Help the group understand the technical termsand jargon.
35
 Record group’s input on a public display area. The facilitator must remain neutral at all time
and help the group through the process.
4.2.5. Post JAD follow-up


Postsession report is prepared and circulated among
session attendees
The report should be completed approximately a week to two after the JAD
session
4.3. Questionnaires
 A questionnaire is a set of written questions for obtaining information from individuals.
• Selecting participants - using a sample of people who are representative of the entire group.
• Designing the questionnaire – following good practice guidelines.
• Administering the questionnaire – improving the response rates.
 Good questionnaire design
4.4. Document Analysis
 Document analysis is used to understand the as-is system.
 Forms, reports, policy manuals, organization charts describe the formal system that the
organization uses.
 The “real” or informal system differs from the formal one, and reveals what needs to be changed.
 The indication that system needs to be changed is when users create new forms or make
changes to the existing forms/reports.
36
4.5. Observation
 Observation – the act of watching processes being performed.
 It is a powerful tool to gain insight into the as is system, and to check the validity of
information gathered from other sources.
 Nonetheless, people tend to be extremely careful in their behaviors when they are being
watched.
5.
Comparison of requirements elicitation techniques
37
REFERENCES
1. Try QA, (2022). What is incremental model-advantages, disadvantages and when to
use it? [Online]. Available at: https://tryqa.com/what-is-incremental-modeladvantages-disadvantages-and-when-to-use-it/ [Accessed February 18, 2023]
2. Coggle, (2020). Reuse-oriented-software-engineering. [Online]. Available at:
https://coggle.it/diagram/XGV8BXV4-l8bE9SE/t/reuse-oriented-softwareengineering [Accessed February 18, 2023]
3. Mohammed. H, Parallel Development Model. [Online]. Available at:
https://www.researchgate.net/figure/Parallel-Development-Model_fig4_336304283
[Accessed February 18, 2023]
4. Logica, (2023) . Agile Development - Advantages, Disadvantages and when to use it?
Available at: https://www.360logica.com/blog/agile-development-advantagesdisadvantages-and-when-to-use-it/ [Accessed February 18, 2023]
5. Ionos. E, (2019). Extreme Programming. [Online]. Available at:
https://www.ionos.com/digitalguide/websites/web-development/extremeprogramming/ [Accessed February 18, 2023]
6. Rev. T, (2016). System Development Lifecycle (SDLC). [Online]. Available at:
https://www.mtu.edu/it/security/policies-procedures-guidelines/informationsecurity-program/system-development-lifecycle/ [Accessed February 18, 2023]
7. Marquette. W, (2018). WHAT IS RISK MANAGEMENT? [Online]. Available at:
https://www.marquette.edu/riskunit/riskmanagement/whatis.shtml [Accessed
February 18, 2023]
8. Hoot. I, (2022). 5 Main types of SDLC Models: Overview. [Online]. Available at:
https://ithoot.com/article/5-main-types-of-sdlc-models-overview [Accessed
February 18, 2023]
9. Nasser. D, (2020). Feasibility studies. [Online]. Available at:
https://wasserdreinull.de/en/our-offers/testcenter-and-servicelab/feasibilitystudies/ [Accessed February 18, 2023]
10. Wiki, (2022). Software Development Process. [Online]. Available at:
https://en.wikipedia.org/wiki/Software_development_process [Accessed February
18, 2023]
38
39
40