ASSIGNMENT 01 FRONT SHEET

Qualification BTEC Level 5 HND Diploma in Computing

Unit number and title Unit 09: Software Development Life Cycle

Submission date Date Received 1st submission

Re-submission Date Date Received 2nd submission

Student Name NGUYEN VAN DAT Student ID GCS210929

Class GCS1007 Assessor name

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

Student’s signature

Grading grid
P1 P2 P3 P4 M1 M2 D1 D2
❒ Summative Feedback: ❒ Resubmission Feedback:

Grade: Assessor Signature: Date:

Internal Verifier’s Comments:

Signature & Date:

 TABLE OF CONTENTS
P1 Describe two iterative and two sequential software lifecycle models. ................................................................................... 6
1. Introduction to SDLC .................................................................................................................................................................................................... 6
2.Two sequential software lifecycle models ............................................................................................................................................................ 7
2.1. Waterfall model ........................................................................................................................................................................................................ 7
2.2 V Mode .......................................................................................................................................................................................................................... 9
3. Two interative software lifecycle models ..........................................................................................................................................................11
3.1. Incremental Development .................................................................................................................................................................................11
3.2 Spiral model ..............................................................................................................................................................................................................14
4. The model is used in the Tune Source project .................................................................................................................................................16
P2. Explain how risk is managed in the Spiral lifecycle model. ...................................................................................................... 16
1.Risk management ..........................................................................................................................................................................................................16
2. Risk management process ........................................................................................................................................................................................16
3. Risk management matrix in Tune Source project ..........................................................................................................................................17
3.1 Risk Matrix Definition ..........................................................................................................................................................................................17
3.2 Risk management matrix of Tune Source project ....................................................................................................................................17
4. How to manage risks in the Spiral lifecycle model. .......................................................................................................................................18
P3. Explain the purpose of a feasibility report. ..................................................................................................................................... 19
1. What is a feasibility study .........................................................................................................................................................................................19
 2. The purpose of a feasibility report .......................................................................................................................................................................20
3. Feasibility study on Tune Source project ...........................................................................................................................................................21
3.1 Economic feasibility ..............................................................................................................................................................................................21
3.2 Organizational feasibility ....................................................................................................................................................................................22
P4. Describe how technical solutions can be compared. ................................................................................................................... 22
1. What is a requirements .............................................................................................................................................................................................22
2. Types of requirements ...............................................................................................................................................................................................23
3. How to determine requirements ...........................................................................................................................................................................25
4. Requirements elicitation techniques ...................................................................................................................................................................26
4.1 Interviews ..................................................................................................................................................................................................................26
4.2 Joint Application Development (JAD) .............................................................................................................................................................26
4.3 Questionnaires.........................................................................................................................................................................................................27
REFERENCES ......................................................................................................................................................................................................... 28
 TABLE OF FIGURE
Figure 1: Definition of SDLC ....................................................................................................................................................................................... 6

Figure 2: Waterfall model............................................................................................................................................................................................ 7

Figure 3: V Mode ...........................................................................................................................................................................................................10

Figure 4: Incremental Development .....................................................................................................................................................................12

Figure 5: Spiral model .................................................................................................................................................................................................15

Figure 6: What is a feasibility study ......................................................................................................................................................................20

Figure 7: requirements ...............................................................................................................................................................................................23

Figure 8: Functional requirements .......................................................................................................................................................................24

Figure 9: Non-functional requirements ..............................................................................................................................................................25

 ANSREW ASSIGNMENT 1

P1 Describe two iterative and two sequential software lifecycle models.

1. Introduction to SDLC
a. Definition of SDLC
A need analysis, requirements analysis, design, testing, and implementation are all parts of the system development life
cycle (SDLC), which is the process for developing information systems. Application development and information systems
development are common names for the SDLC.

Figure 1: Definition of SDLC

b. Purposes of SDLC
 An SDLC methodology's primary objective is to provide IT project managers with the tools they require to facilitate
the successful implementation of systems that support the university's strategic and operational goals.
2. Two sequential software lifecycle models
2.1. Waterfall model
- Definition: The waterfall paradigm was one of the first methods used in software development. It is widely used in
the realm of software engineering. This model proposes that the software development process is divided into multiple
stages, each of which is associated with a different set of activities and materials. Sequencing software development projects
is made easier by the waterfall paradigm; a new phase is only started when the previous one is finished.

Figure 2: Waterfall model

The software development process used in the Waterfall paradigm is sequential and linear. It is broken up into
discrete phases that go in a particular order. The Waterfall model typically has the following:
  Requirements Analysis and Gathering: During this phase, the software project's requirements are found and
recorded in writing. To do this, stakeholders' information must be gathered, their needs must be assessed, and
the project's scope must be established.
 System Design: The system design phase starts once the requirements are established. The modules,
components, and their relationships are all part of the overall architecture of the software system as it is
designed here. The basis for the ensuing development process is laid during this stage.
 Implementation: The actual writing of code or the creation of software based on design specifications occurs
during the implementation stage. The design documents serve as a guide for programmers or developers while
they develop the software.
 Software is put through a thorough testing step after it has been developed. Testers make that the program
works as intended and complies with the requirements. This step makes sure that any flaws or faults are found
and fixed.
 Deployment: After the program has though a comprehensive testing process and been given the all-clear, it is
installed or deployed on the system or environment that it is meant to be used in. Data migration, user training,
and system integration are some of the tasks involved at this stage.
- Advantages of Waterfall model:
Benefits of the waterfall model include:
 This model is simple, clear, and useful.
 Because of the rigor of the paradigm, management is made straightforward because each phase has clear deliverables
and a review process.
 Each phase is processed and completed independently in this architecture. Phases don't overlap.
 The waterfall methodology is advantageous for smaller projects with clearly specified requirements.
- Disadvantages of Waterfall model:
 Once an application is in the testing stage, it can be difficult to go back and make corrections to something that wasn't
thoroughly thought out in the design stage.
  No working software is produced all the way through the life cycle.
 There is a lot of risk and uncertainty.
 Intricate and object-oriented operations should not be performed using this paradigm.
 Unsuitable as a paradigm for ongoing, lengthy undertakings.
 Projects where there is a moderate to high likelihood of requirement modifications are inappropriate.

2.2 V Mode
- Definition: V model extends the waterfall model. but not the waterfall model. Testing happens simultaneously with the
cycle of software development since, according to the V model, each step of testing corresponds to a stage of software
development.
 Figure 3: V Mode
The relationship between each phase of the development life cycle and its corresponding testing phase is highlighted
by the V-model, a framework for software development and testing. The V-model is so named because of how it looks like
the letter "V." The following stages make up the V-model:
 Gathering and Analyzing needs: In this step, the software system's needs are gathered, recorded, and examined.
Users, clients, and business analysts are just a few of the stakeholders who frequently provide the
requirements.
 System Design: Following the collection of the requirements, the system design phase is launched. The entire
system, including its architecture, modules, and interfaces, must be high-level designed. The design must adhere
to the given specifications.
 Subsystem Design: The high-level system design is broken down into more manageable subsystems or modules
during this phase. Each subsystem is given a detailed design, outlining how it will function individually and
connect with other subsystems.
 Coding and unit testing: Using the designs for each module or subsystem as a guide, the actual source code is
written during the coding phase. Individual pieces of code are subjected to unit testing to make sure they work
properly when run separately.
 Integration and system testing: After each module has been created and tested, the system as a whole is put
together. To make that the integrated system works as expected and complies with the requirements,
integration testing is done.
 Acceptance Testing: During this stage, the system is examined in light of the acceptance standards established
by the clients or end users. It verifies whether the system is prepared for deployment and complies with user
needs.
 Deployment: The system is put into use in the production environment after passing acceptance testing. The
software must be installed, set up, and made accessible to users.
  Maintenance: To keep the system reliable and current, the maintenance phase entails continuing support and
maintenance tasks like bug patching, additions, and upgrades.
Advantages of V Model:
 The usage is easy and practical.
 Testing-related activities, including as planning and creating tests, are performed before coding. Time is saved
significantly as a result of this. As a result, the waterfall approach has a better chance of being successful.
 Thanks to proactive defect tracking, defects are found early on.
 Prevents the errors from getting worse.
 It is useful for small projects with straightforward requirements.
Disadvantages of V Model
 The least flexible and most rigid
 Because software is developed during the implementation phase, there are no early software prototypes made.
 If changes are made during the project, the test papers and requirement documents must be updated.

3. Two interative software lifecycle models

3.1. Incremental Development

- Definition: The incremental model, a method for developing software, separates requirements into a
number of separate modules that each perform a different function in the development cycle. Analysis, design,
implementation, testing/verification, and maintenance are the phases of incremental development.
 Figure 4: Incremental Development
Small, incremental steps or increments are used to build the system in incremental development, an iterative software
development methodology. Each increment offers only a portion of the full system's capability. The following are often
included in the stages of incremental development:
 Gathering of Requirements: At this stage, stakeholders are gathered to provide the system with the first set of
requirements. Based on their significance and interdependencies, the needs are assessed, prioritized, and
broken down into smaller increments.
 Design and Planning: The design and planning stage starts when the requirements are determined. The initial
increment's design and the system's overall architecture have been established. Future increment dependencies
and interactions should be considered throughout design.
 Implementation: At this step, the development team begins putting the first increment's design into practice.
Delivering the functionality designated for any given increment is the main goal of the development process.
 Any viable software development methodology, including waterfall, agile, or a hybrid approach, may be used for
the implementation.
 Testing and Integration: Each increment is tested as it is produced to make sure it complies with the
requirements and works as intended. To ensure that the recently generated increment interfaces seamlessly
with the current system components, integration testing is carried out.
 Evaluation and feedback: Stakeholders, such as clients or end users, review each increment after it has been
completed. Their opinions and feedback are gathered in order to evaluate the functionality that has been given
in terms of performance, usability, and general satisfaction. This feedback helps prioritize upcoming
development initiatives and guides the succeeding increments.
 Delivery of Increments: An increment is sent to clients or end users when it has been tried, tested, and accepted.
The given increment may only offer a portion of the full system's capabilities, but it should still be useful and
beneficial to the consumers.
 Iterative development: For each next increment, the aforementioned processes are repeated. The requirements
are examined, followed by the execution of design and planning, development, testing, and integration tasks. As
the system is developed, the increments are gradually built and provided.
 After the entire system has been delivered, maintenance and improvement operations are carried out. On the
basis of customer feedback or shifting requirements, these operations could include bug fixes, upgrades, and the
addition of new features or capabilities.
Advantages of Incremental Development:
 The development of the application will proceed quickly throughout the software life cycle.
 It is flexible and affordable to alter the criteria and scope.
 Modifications can be made at any stage of the creation process.
 This model costs less when compared to others.
 Customer input is welcome in every building.
 Errors are easy to identify
 Disadvantages of Incremental Development:
 Planning and design must be done carefully.
 Issues with the system architecture may occur if all requirements for the whole software lifecycle are not
gathered up front.
 Due to the rigidity of each iteration phase and the fact that they do not overlap, fixing a flaw in one unit requires
adjustments in all units, which takes a lot of time.

3.2 Spiral model

Definition: Spiral diagrams are used to simulate the software development process. It blends a waterfall paradigm
into an iterative methodology. The Spiral Model helps with the adoption of software development elements from several
process models for the software project based on distinct risk patterns, offering an efficient development process.
 Figure 5: Spiral model
The stages in the Spiral Model:
 Planning for the subsequent step and each phase: The first step of the spiral model is the planning phase,
which determines the project's scope and creates a strategy for the spiral's subsequent iteration.
 Risk Analysis: The risk analysis phase involves the discovery and evaluation of project-related risks.
 Engineering: from the engineering phase, the program is developed using the requirements gathered from
earlier iterations as a reference.
 Execution and Evaluation: During the evaluation stage, the software is analyzed to determine whether it is of
good quality and meets the needs of the client.
Advantages of Spiral model:
 Later, functionality can be added or changes can be made.
 Cost estimation is made straightforward by the prototype's small-scale fabrication.
 Continuous or repetitive development is advantageous for risk management.
 Features are swiftly and carefully introduced in spiral growth.
 We always appreciate hearing from our customers.
Disadvantages of Spiral model:
 The potential for exceeding the allocated spending limit or deadline.
 Spiral development, which is only used for large projects and necessitates skill in risk assessment, is
also required.
 The smooth operation of the spiral model requires strict adherence to the protocol.
 Since there are transitional phases, documentation is more extensive.
 Spiral software development is not advised for smaller projects because it may be rather expensive.
 4. The model is used in the Tune Source project
Considering that there is a strong relationship between partners and project implementers in the Spiral model, I will
probably opt to employ it for the Tune Source project. Constant communication is necessary in order to produce the best
result possible using agile approaches.

P2. Explain how risk is managed in the Spiral lifecycle model.

1. Risk management
Risk management is the process of identifying, assessing, and controlling risks to an organization's assets and
revenue. These risks can be brought on by a variety of factors, including monetary uncertainty, legal obligations,
technology issues, strategic management errors, accidents, and natural disasters.

2. Risk management process

Understanding risks and opportunities, how they could affect a project or organization, and how to respond to
them is possible through the risk management process, which is a well-defined methodology.
The important steps in the risk management process are:
 Finding risks entails figuring out the possibility of each risk event happening as well as any potential
impacts. This is done through the risk analysis approach. After comparing the amount of each risk, each
risk is graded according to its significance and impact.
 Risk analysis and assessment: One step in the risk analysis process is to estimate the possibility of each
risk event happening as well as any potential impacts. The relative magnitudes of each risk are examined
and each risk is graded according to its importance and impact.
 Risk reduction and monitoring: Reducing risks to project objectives is accomplished through the process
of planning, creating, and putting into practice solutions and techniques. To identify, monitor, and assess
the risks and potential outcomes of completing a particular project, such as developing a new product, a
 project team may decide to apply risk mitigation approaches. A part of risk mitigation involves dealing
with project problems and their implications.
 Risk management is a continuous process that evolves over time. By repeating the steps and keeping
ongoing monitoring, it is feasible to ensure that both predicted and known risks are completely covered.

3. Risk management matrix in Tune Source project

3.1 Risk Matrix Definition

During the risk assessment stage of project planning, a tool called a risk assessment matrix, also called a risk
control matrix, is employed. Project risks are recognized, recorded, and their likelihood as well as the possible harm or
disruption they might cause are assessed.
The risk assessment matrix provides a visual representation of the risk analysis and groups hazards according
to the likelihood that they will happen and the gravity or impact of those events. This tool provides all team members
and key stakeholders with a rapid, efficient way to gain a complete understanding of the project risks.

3.2 Risk management matrix of Tune Source project

The project Tune Source's sample risk management matrix is displayed below:
- High Risk:
+ There have been technical problems with website development.
+ Online attacks or data leaks
+ Regulations controlling the music industry are being changed.
+ Major participants in the project leave.
- Mitigation:
+ Implement a backup strategy for essential staff members, such as resource identification or cross-training.
+ To reduce technological problems, regularly maintain your website.
 Plus, spend money on system measurements and checks.
+ Stay informed about any changes to the laws governing the music industry, and seek legal advice as needed.
- Moderate Risk:
+ The existence of other online music merchants
+ The decline in demand for physical CDs
+ Variations in consumer interests and preferences
+ Defects in the supply chain
- Mitigation:
+ Monitor competitors while maintaining competitive pricing and product offerings.
+ Consider expanding your musical repertoire to include vinyl recordings and digital downloads.
+ Conduct regular consumer surveys to stay abreast of evolving tastes and preferences
+ Establish trustworthy relationships with suppliers and put contingency plans in place in case of interruptions
- Low Risk:
+ Client complains
+ Delay in delivery
+ Inaccurate orders
+ Minor website issues
- Mitigation:
+ Regularly maintain the website to avoid problems
+ Implement quality control measures to reduce incorrect and poor orders
+ Work with delivery services to ensure swift and reliable delivery
+ Have a process in place for quickly resolving and handling customer complaints

4. How to manage risks in the Spiral lifecycle model.

The steps to manage risk in the Spiral model:
 Identify Risks: Have a discussion about possible risks with the project team and stakeholders.
  Risk analysis involves evaluating the likelihood, significance, and uncertainty of identified risks.
 Create measures to lessen the occurrence and impact of risks as part of a plan for mitigation.
 Monitor hazards: Keep an eye out for any new hazards that may arise and evaluate the success of any mitigation
strategies.
 Take appropriate action in response to hazards depending on their seriousness and probable consequences.
 Maintain a record of hazards, mitigation strategies, and their current status. Dispute with interested parties.
 Apply an iterative strategy, incorporating risk management into each spiral iteration.

P3. Explain the purpose of a feasibility report.

1. What is a feasibility study

A feasibility study is a comprehensive analysis that takes into account all of the significant aspects in order to
determine the likelihood that a proposed project will succeed.

The main criterion used to judge company performance may be return on investment, or if the enterprise will make
enough money to pay for the expenditure. Numerous other important factors, such as their effects on the environment and
local economy, can be found on either the positive or negative side.

However, there are still a number of things to consider before moving forward with any course of action. Project
managers can utilize feasibility studies to evaluate the risk and value of following a course of action.
 Figure 6: What is a feasibility study

2. The purpose of a feasibility report

The purpose of a feasibility report is to evaluate the potential success of project routes or solutions and
choose the most promising one. In order to help readers assess the viability of each solution, the feasibility report's
goal is to illustrate several approaches to problem solving or project implementation. On the basis of the analysis in
the report, readers can decide whether to take the study's recommendations for the best course of action. Using this
in-depth examination of all available options, businesses may make the best decisions for projects and situations.
3. Feasibility study on Tune Source project
An analysis of a project's technical and financial viability is called a feasibility study. Conducting a feasibility
study for the Tune Source project might be accomplished using the following steps:
Tell us about the project: Clearly state the goals and purposes of the Tune Source project, as well as the service
or good it hopes to produce.
An examination of the market Conduct market research to determine whether the market requires the product
or service being offered. Analyze the potential clients, the competition, and the target market.
To decide whether the project is viable, examine it from a technical perspective.
Consider how readily accessible the equipment and technology needed to develop and market the product or
service are.
Calculate the project's startup costs, ongoing operating expenditures, and potential revenue sources as part of
your financial analysis. Determine whether the project is financially feasible by weighing the costs and benefits.
Determine any laws or regulations that must be observed and think about the possibility that they will be
contested in court.
Risk assessment: Identify and investigate any risks and challenges that may have an impact on the project's
success, such as market competition, technology limitations, or shifts in the economy.
Using the analysis' results as a basis, decide whether the Tune Source project is viable. If the initiative is viable,
make recommendations for how to move forward. If it is not practicable, propose some workable alternatives.

3.1 Economic feasibility

Economic viability refers to a project or business venture's ability to generate enough revenue to cover its costs
and provide an acceptable return on investment. It comprises analyzing the benefits and drawbacks of a project, as
well as its anticipated financial outcomes from sales or other sources of income and the costs of its components—
materials, labor, and equipment. Economic viability is a key consideration when considering whether to proceed with
 a project or business. In conjunction with other types of feasibility study, such as technical and operational feasibility,
it is widely employed.

3.2 Organizational feasibility

Evaluation of management's capacity and resource availability to launch a product or concept on the market is
the aim of organizational feasibility. In order to execute its target areas, the company needs evaluate the management
team's skill set. Managerial aptitude is frequently demonstrated by the founders' excitement for the business concept,
as well as by their industry expertise, educational background, and professional experience. Founders should be
honest with themselves when rating these categories. Resource sufficiency examines the resources that the venture
will need to progress in order to assess whether an entrepreneur has an adequate number of non-financial resources
successfully. The business should assess its strengths in six to twelve different categories of such essential non-
financial resources, such as the availability of office space, the quality of the labor pool, the likelihood of obtaining
intellectual property protections (if necessary), the willingness of high-quality employees to join the business, and its
propensity to form advantageous strategic alliances. If the assessment reveals that crucial resources are not available
in adequate amounts, the project may not be possible as it is now planned.

P4. Describe how technical solutions can be compared.

1. What is a requirements
An expectation or obligation that is formally expressed, implicitly accepted by all people, or that is governed by
law. "Common understanding" in the viewpoint of the organization and other parties concerned denotes a
requirement or expectation that is taken for granted in usual behavior. The term "stated requirement" refers to a
requirement that has been made known, typically through written material. An idiom can be used to express a certain
form of requirement, such as a requirement for a customer, a requirement for quality management, a requirement for
 a product, or a demand for quality. The organization itself may set requirements, or a number of interested parties
may do so.
The term "requirements" in the context of software development refers to the features, functions, and qualities
that a system, good, or service must have to satisfy the needs of its users.

Figure 7: requirements

2. Types of requirements
There are two main types of requirements:
- Functional requirements:
Functional requirements are characteristics or abilities of a product that developers must incorporate to enable
users to do their tasks. The development team and the stakeholders must therefore be made aware of them.
Functional requirements frequently describe the behavior of a system under specific conditions.
 Figure 8: Functional requirements
- Non-functional requirements:
Non-functional requirements are a list of guidelines for the restrictions and characteristics of software or
systems. Non-functional requirements are any needs that do not have accompanying functional requirements. They
set the criteria by which the effectiveness of the system will be judged rather than concentrating on behavior.
 Figure 9: Non-functional requirements

3. How to determine requirements

There are numerous methods for authenticating requests. Include:
Testing: We look through the requirements documents again while testing the requirements to make sure that
no hint notes are missing. During this test, we also check the tracability of each request. For this, a traceability matrix
needs to be created. This matrix guarantees that all requests are taken carefully and that all specifications are
reasonable. In addition, we examine the formatting of the requests during this examination. We examine the
requirements to make sure they are well-written and clear.
 Prototyping is a process for simulating or modeling a system that developers have constructed. This method is
particularly popular for validating requests between parties due to the simplicity with which users and stakeholders
may uncover errors. We are only able to communicate with and gather feedback from users and stakeholders.
Test Design: We first build the test team, and after that, we go through a quick procedure to create test cases.
The requirements specification, where each need is supported by a test, can be used to immediately produce
functional tests. On the other hand, testing non-functional requirements can be difficult because each test must be
linked to its related requirement. You can use this to find informative gaps or typos in your criteria.
Requirements review: To identify any potential problems, a group of knowledgeable people evaluates the
requirements meticulously and methodically. Once they have discussed the problems and found a solution, they meet
again. The several standards are put on a checklist, which the evaluator goes through and marks off as they are met in
order to provide a formal assessment by marking the necessary boxes. After then, the final approval is finished.

4. Requirements elicitation techniques

4.1 Interviews
The method most frequently used to elicit needs is this one. It is important to build trust between business
analysts and stakeholders through interviewing approaches. This method involves posing questions to stakeholders in
order to gather information.
In a structured interview, the interviewer poses a predetermined list of inquiries. You should take into account
using the 5 Why strategy to land the job. Once all of your concerns have been addressed, the interview process is over.
Open-ended questions are used to gather comprehensive data.

4.2 Joint Application Development (JAD)

A process called Joint Application Development (JAD) uses a series of collaborative workshops, or JAD
sessions, to involve the client or end user in the design and development of an application. The JAD approach
was developed by IBM employees Chuck Morris and Tony Crawford in the late 1970s, and courses to teach it
began in 1980.
The JAD methodology is thought to offer speedier turnaround times and higher levels of client
satisfaction than the more traditional approach because the client is involved at every stage of the
development process. On the other hand, in the traditional way of system development, the developer studies
the requirements of the system and develops an application using customer input collected through a series
of interviews.
By adopting methods like software component reuse and less formal procedures, rapid application
development (RAD), a variation on JAD, creates applications more quickly.

4.3 Questionnaires
A questionnaire is a type of research tool that asks a series of questions or provides additional prompts
in order to elicit information from respondents. In a study questionnaire, open-ended and closed-ended items
are frequently combined.
With open-ended, protracted questions, the respondent has the chance to dig into more depth. In 1838,
the Statistical Society of London created the first study questionnaire.
Both quantitative and qualitative data may be obtained through a data gathering questionnaire. Even if it may
or may not be presented in the form of the survey, a questionnaire is always a part of it.
 REFERENCES
1. Altvater, A. (2023) What is SDLC? understand the software development life cycle, Stackify. Available at:
https://stackify.com/what-is-sdlc/ (Accessed: 16 June 2023).
2. Contributor, T.T. (2019) What is spiral model and how is it used?, Software Quality. TechTarget. Available
at: https://www.techtarget.com/searchsoftwarequality/definition/spiral-model (Accessed: 16 June
2023).
3. Agile model (software engineering) - javatpoint (no date) www.javatpoint.com. Available at:
https://www.javatpoint.com/software-engineering-agile-model (Accessed: 16 June 2023).
4. Xuan Truong et al. (2021) Waterfall model in SDLC? Advantages & Disadvantages, Tập đoàn edX - Happy
Company. Available at: https://edxgroup.vn/2021/04/11/waterfallmodel-in-sdlc-advantages-
disadvantages/ (Accessed: 16 June 2023).
5. Government of Canada, C.C.for O.H.and S. (2023) Hazard and risk - risk assessment : Osh answers,
Canadian Centre for Occupational Health and Safety. Available at:
https://www.ccohs.ca/oshanswers/hsprograms/risk_assessment.html (Accessed: 16 June 2023).
6. Government of Canada, C.C.for O.H.and S. (2023) Hazard and risk - risk assessment : Osh answers,
Canadian Centre for Occupational Health and Safety. Available at:
https://www.ccohs.ca/oshanswers/hsprograms/risk_assessment.html (Accessed: 16 June 2023).
7. Team, T.I. (2022) Feasibility study, Investopedia. Investopedia. Available at:
https://www.investopedia.com/terms/f/feasibility-study.asp (Accessed: 16 June 2023).
8. .Daniels, R. and Richard DanielsAuthor at Business Study NotesHello everyone! This is Richard Daniels
(2021) What is feasibility study? 10 types of feasibility study, Business Study Notes. Available at:
https://www.businessstudynotes.com/finance/projectmanagement/types-feasibility-study/ (Accessed:
16 June 2023).
9. What is ASP.NET?: The open source web framework (no date) Umbraco. Available at:
https://umbraco.com/knowledge-base/aspnet/ (Accessed: 16 June 2023).