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

Re-submission Date Date Received 2nd submission

Student Name Tran Quang Binh Student ID GCH190821

Class GCH0802 Assessor name Do Quoc Binh

Student declaration

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

Student’s signature

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
Introduction ............................................................................................................................................................ 5

Software Development Life Cycle and Methodologies/Models (P1) ......................................................................... 5

SDLC Models ....................................................................................................................................................... 9

Suitable Model for Tune Source’s project development..................................................................................... 16

Risk Management (P2) .......................................................................................................................................... 18

Risk Assessment ................................................................................................................................................ 18

Risk Identifcation and Approach Plan ................................................................................................................ 19

Project Feasibility (P3 + P4) ................................................................................................................................... 20

Feasibility Analysis (P3) ..................................................................................................................................... 20

Feasibility Criteria (P4) ...................................................................................................................................... 21

References ............................................................................................................................................................ 26

Figure 1: Waterfall ................................................................................................................................................ 10

Figure 2: V-Shape .................................................................................................................................................. 12
Figure 3: Criteria for choosing model..................................................................................................................... 16
Figure 4: Risk assessment table ............................................................................................................................. 19
Figure 5: Feasibilty Criteria .................................................................................................................................... 21
Figure 6: Project's skateholders ............................................................................................................................. 24
Introduction
This assignment will discuss and evaluate 4 models of development software, feasibility
researches and analysis conduction. Finally, it will examine the technical solutions to choose the
most efficient and reasonable way of implementing the project.

Software Development Life Cycle and Methodologies/Models (P1)

According to Alan Dennis, the author of System Analysis and Design, the softwares development
life cycle (SDLC) is the process of determining how an information system can support business
needs, designing the system, building, and delivering it to users. (Dennis, 2012, p. 6)

As he stated in his book, he showed that in 2010 $2.4 trillion was spent by organizations and
governments on IT hardware, software, and services worldwide. This spending level was projected
to increase by 3.5% in 2011. However, he also stated that the study in 2008 found the chance of
success of 68% technology projects is “improbable” as most of the projects which weren’t
abbandoned are delivered later than expected, here is a sample of just a few notable software
glitches that occurred in 2010:

• A software error resulted in Toys R Us double billing some shoppers for pur-chases made
on Black Friday.
• Verizon Wireless had to refund $50 million to customers due to billing system errors.
 • Chase banking customers were unable to access their online banking accountsfor over 24
hours due to a computer glitch.
• McAfee’s anti-virus software product caused its users’ computers to lock up. McAfee
offered affected customers a free 2-year subscription and reimbursementfor costs incurred
to repair the machines.
• A U.S. Navy drone (unmanned aerial vehicle) reportedly flew into restricted air space near
Washington D.C. when operators lost control for about 20 minutesdue to a software issue.

This give us an insight of the importance of SDLC to the success of major organizations. Also, it
showed how small errors which is from poor management at developing and testing stage can
lead to castratrophic damage to the economic.

The software development lifecycle forms the basis for the methods and procedures used to
develop software or computer systems. Methodology is a listing guide and provides a plan for
SDLC implementation. Various methodologies and patterns have evolved, some of which are
classified as repeating and sequential. SDLC models usually 4 have stages:

Planning phase

(Dennis, 2012, p. 13)

The first stage is planning, which is about the fundamental process of understanding why an
information system should be developed and defining how the project team works, and this phase
consists of two steps:

Step one is done during the initial evaluation of the project and by asking questions such as how
much money the project will cost or how the project can deliver value after it is published to find
understand whether it should be done or not.

Step two is called project management in which the project manager will create a project plan and
the whole team will follow that plan to develop the project.
Analysing phase

(Dennis, 2012, p. 13)

In this phase, the project team will identify who are the users whom the project will be delivered to,
what benefits the system would provide where and when the system would be used, etc. the team
should identify the current system, opportunities and a concept for the future system. Analyzing
phase has three steps:

The first step is an analysis strategy developed to guide the project team’s efforts. Such a strategy usually
includes a study of the current system (called the as-is system) and its problems, and envisioning ways to
design a new system (called the to-be system).

The second step is identifying user requirements, and it can be implemented through interviews, group
workshops, or questionnaires. The analysis of this information—in conjunction with input from the project
sponsor and many other people—leads to the development of a concept for a new system. The system
concept is then used as a basis to develop a set of business analysis models that describes how the business
will operate if the new system were developed. The set typically includes models that represent the data
and processes necessary to support the underlying business process.

The last step is about system proposal which is the combination of the analyses, system concept, and
models, and it presents to the project sponsor and other key decision makers who will decide whether the
project should continue to move forward.

Design phase

(Dennis, 2012, p. 14)

The design phase decides how the system will operate in terms of the hardware, software, and
network infrastructure that will be in place; the user interface, forms, and reports that will be
used; and the specific programs, databases, and files thatwill be needed. Although most of the
strategic decisions about the system are madein the development of the system concept during
the analysis phase, the steps in thedesign phase determine exactly how the system will operate.
The design phase has four steps:

Firstly, the design strategy must be determined. This clarifies whether the system will be
developed by the company’s own programmers, whether its development will be outsourced to
another firm (usually a consulting firm), or whether the com- pany will buy an existing software
package.

Secondly, this leads to the development of the basic architecture design for the system
thatdescribes the hardware, software, and network infrastructure that will be used. Inmost cases,
the system will add to or change the infrastructure that already existsin the organization. The
interface design specifies how the users will movethrough the system (e.g., by navigation methods
such as menus and on-screen buttons) and the forms and reports that the system will use.

Thirdly, the database and file specifications are developed. These define exactly what data will be
stored and where they will be stored. And finally, the analyst development team designs the
programs, which needed to be written, their functions, and feature.

Implementation phase

(Dennis, 2012, p. 15)

Implementation phase is the final phase in the SDLC, during this phase, the new system is
build (or in some cases purchased or installed).

This phase often has the most attention due to it isusually the longest and the most expensive.
It has 3 stages:

The first stage is system construction. The system is now built and tested to make sure that the
system behaves and performs as expected. Due to the fact that the expense for fixing bugs is
extremely costly, testing is the most crucial and important in the implementation phase. Most of
the companies and organizations allocate more time and attention on testing than program the
software.
Next, the installation of the new system happened. When the new system is installed, the old
system will be turned off. The training plan for users is developed, it is very important to teach
users on how to use, manage and adapt to the new system.
The analyst team develops a support plan for the new system. This support plan contains a formal
or informal post-implementation revise, and a systematic approach for determining changes for
the system if needed.

SDLC Models
So, we got the concept of SDLC Model which contain steps and phases that sequentially process
from one to another. There are various models for developer to follow to develop a project, each
one has its own features which may work with certain project but not with others.

Waterfall Model

(Dennis, 2012, p. 51)

Designed for project managers, designers and developers working in building computer systems.
This model works sequentially from one stage to the next. The waterfall model using the basic
phase mentioned in the previous section: Planning, Analysis, Design and Implementation.
 Figure 1: Waterfall

Advantage Disadvantage
• Each stage has been predetermined • The biggest problem of the waterfall is

as well as landmarks can provide. that the project can only move forward
and cannot go back a step is the design
• Easy to follow and understand
phase or planning phase has issues, it
will be very difficult and complicated
in the implementation phase.
• Usually, the customers and clients
have not a clear thought about
requirements in the future system. Any
changes in the requirement and
 features of the system will cause many
troubles.
• Any changes, error or bugs whether
big or small which arise after finishing
the software might cause serious
problems.

• One major setback of this model is the

working software cannot be control,
use
or lie in hand of the client until the
software is fully completed

V-shape Model

(Dennis, 2012, p. 53)

V-shape model is a variation of the original waterfall development. This model focuses
more on testing. Therefore, the key concept of this model is that it must have a specified
requirement and components designed and testing for those elements are defined. Each testing
level is connected to a factor of analysis and design phase, this will make sure and maximize the
quality, relevant testing, and test effectiveness.
 Figure 2: V-Shape

Advantage Disadvantage
• This is a highly-disciplined model and • High risk and uncertainty.
Phases are completed one at a time. • Not a good model for complex and
• Works well for smaller projects where object-oriented projects.
requirements are very well • Poor model for long and ongoing
understood. projects.
• Simple and easy to understand and • Not suitable for the projects where
use. requirements are at a moderate to
• Easy to manage due to the rigidity of high risk of changing.
the model. Each phase has specific • Once an application is in the testing
deliverables and a review process. stage, it is difficult to go back and
change a functionality.
• No working software is produced until
late during the life cycle.
Spiral Model

The spiral model based on the experience with refinements of the waterfall model, when it
used for large government projects. This model combines elements of both design and prototypein-
stages, this model also is combination of advantages of top-down and bottom-up concepts.
Spiral model is a meta-model and other model can implement it. (Boehm, 2005, p. 64)

Advantage Disadvantage
• Changing requirements can be • Management is more complex.
accommodated.
• End of the project may not be known
• Allows extensive use of prototypes. early.
• Requirements can be captured more
• Not suitable for small or low risk
accurately.
projects and could be expensive for
• Users see the system early. small projects.
• Development can be divided into
• Process is complex
smaller parts and the risky parts can be
• Spiral may go on indefinitely.
developed earlier which helps in better
• Large number of intermediate stages
risk management.
requires excessive documentation.

Prototype Model

There are different types of software prototypes used in the industry. Following are the major
software prototyping types used widely −

Throwaway prototyping is also called as rapid or close ended prototyping. This type of prototyping
uses very little efforts with minimum requirement analysis to build a prototype. Once the actual
requirements are understood, the prototype is discarded and the actual system is developed with
a much clear understanding of user requirements. (Dennis, 2012, p. 56)

Extreme prototyping is used in the web development domain. It consists of three sequential
phases. First, a basic prototype with all the existing pages is presented in the HTML format. Then
the data processing is simulated using a prototype services layer. Finally, the services are
implemented and integrated to the final prototype. This process is called Extreme Prototyping
used to draw attention to the second phase of the process, where a fully functional UI is developed
with very little regard to the actual services. (Dennis, 2012, p. 57)

Advantage Disadvantage

• Increased user involvement in the • Risk of insufficient requirement

product even before its analysis owing to too much
implementation. dependency on the prototype.

• Since a working model of the system is • Users may get confused in the
displayed, the users get a better prototypes and actual systems.
understanding of the system being
• Practically, this methodology may
developed.
increase the complexity of the system
• Reduces time and cost as the defects as scope of the system may expand
can be detected much earlier. beyond original plans.

• Quicker user feedback is available • Developers may try to reuse the

leading to better solutions. existing prototypes to build the actual
system, even when it is not technically
• Missing functionality can be identified
feasible.
easily.
• The effort invested in building
• Confusing or difficult functions can be
prototypes may be too much if it is not
identified.
monitored properly.
Agile Model

Agile model believes that every project needs to be handled differently and the existing methods
need to be tailored to best suit the project requirements. In Agile, the tasks are divided to time
boxes (small time frames) to deliver specific features for a release. Iterative approach is taken and
working software build is delivered after each iteration. Each build is incremental in terms of
features; the final build holds all the features required by the customer. (Dennis, 2012, p. 57)

Advantage Disadvantage

• Is a very realistic approach to software • Not suitable for handling complex

development. dependencies.

• Promotes teamwork and cross training. • More risk of sustainability,

maintainability and extensibility.
• Functionality can be developed rapidly
and demonstrated. • An overall plan, an agile leader and
agile PM practice is a must without
• Resource requirements are minimum.
which it will not work.
• Suitable for fixed or changing
• Strict delivery management dictates the
requirements
scope, functionality to be delivered,
• Delivers early partial working solutions.
and adjustments to meet the
• Good model for environments that deadlines.
change steadily.
• Depends heavily on customer
• Minimal rules, documentation easily interaction, so if customer is not clear,
employed. team can be driven in the wrong
direction.
 • Enables concurrent development and • There is a very high individual
delivery within an overall planned dependency, since there is minimum
context. documentation generated.

• Little or no planning required. • Transfer of technology to new team

members may be quite challenging
• Easy to manage.
due to lack of documentation.
• Gives flexibility to developers.

Suitable Model for Tune Source’s project development

As stated above, each model has its own advantages and disadvantages which only suitable with
specific projects. In order to determine which is suitable for the project, each model’s
characteristic should be align with other’s.

Figure 3: Criteria for choosing model

First thing to consider is the clarify of requirements, unclear requirement may cause unexpected
change or increase the risk of having undesirable design to the user after development. Agile
model works best with this situation because it allows change to happen and flexible even after
development. However, it is not the case with Tune Source, according to assignment brief, it is
stated very clear about intended features and requirements for the project so that Agile Model
isn’t suitable anymore.

Secondly, we should consider the technology familiarity of the employees who participate in the
project. If it is the first time the company do this kind of project, it’s best to use Throwaway
Prototyping Model. Applying the new technology at the start of the methodology will improve a
project's success rate. However, according to assignment breif, Tune Source’s IT department are
experienced in Internet Technology along with their experience working with ISPs to maintain
websites. So that there won’t be the idea of using Prototyping Model, instead Waterfall seem to
be the best choice among other choice.

Thirdly, to deal with the complexity of the system, the waterfall can be very is useful, however,
without prototyping, key issues can be overlooked. In the case of Tune Source, the system is very
complicated due to many requirements; so, using the waterfall model can be a great idea. The
project is managed by Carly Edwards, a senior in the the marketing department was the one who
initially suggested to develop this project, he was very clear about its requirements of the project
and under his management, it is very unlikely that the main problem is ignored.

Finally, reliability of a system is very important, systems that require high reliability often relate to
human life, military activities and key projects have direct effect on business benefits. This can be
done using waterfall variations like the V-shape Model.

In the Tune Source project, this project is very important for the company because of the
marketing department sees it as a strategic system that helps the company maintain a competitive
advantage.

Using the waterfall model can be a good idea as it is great when it comes to handling this problem
project type, to continue in each phase, the project must be well documented and approved by
approval committee. This will ensure that the project is on the right track suitable features.
To sum up, after reviewing all the critera, I suggest using waterfall as it is the most suitable model
for this project considering all both pros and cons of all available models.

Risk Management (P2)

Risk management is a discipline which aims are to determine, solve, and minimize software risk
items before they turn into threats to a software development process or operation or become
primary sources of costly software rework. (Boehm, 2005, p. 1)

According to Boehm, there are 5 steps of risk management plan:

• Identify the type of risks.

• Develop a plan to address every risk form.
• Review the risk, plan and outcome list form regularly.
• In monthly plan updates, mark the hazard item status and compare it with the previous
month.
• Initiate correct risk-type techniques

Risk Assessment
This process is to focus on estimating the likelihood and severe of a risk, this should be done before
taking any measure to mitigate the risk. In other word, we need to consider both factors which are
Consquence/Impact and Probablity/Likelyhood of the risk in order to determine the category of the
risk.
 Figure 4: Risk assessment table

As we see, the more red-ish the color is, the more serious the risk is. There are 3 level of risk
which is: minor, moderate, major and extreme. Major risk could severely decrease success
chance of the project and extreme risk may cause the loss to the company or even damage the
reputation and make the company loses to the rivals in competition.

Risk Identifcation and Approach Plan

Since we knew what risk assessment is, the task is now identifying all the possible risks that may
occur to Tune Source’s project.

Risk name Likelyhood Impact Risk level Approach Plan

The cost Likely Serious Major Make a to-do-list for the project to
exceeds the avoid unintended costs, also choose
project’s to solve problems carefully with
budget minimal feasible cost.
The developed Rare Castratropic Major Clarify the user requirement and
website does make tasks base on it. Design
not meet user wireframe and testing.
requirement
 Lack personel Rare Very little Minor Try to assign new employee to do the
due to sudden job as soon as possible.
retired or
moving out
Unintended Most Little Moderate Using wireframe to design, prevent
errors in likely overlooked bugs by actively
design debugging at developemt stage.

Project Feasibility (P3 + P4)

Feasibility Analysis (P3)
Feasibility analysis’ aims are to guide the company in identifying if they want to proceed
with the project or terminate it. Moreover, the analysis also determines the seriousness of risks
that related to the project and those risks should be managed is the project is under-going. A
feasibility report contains 3 areas of assessment: technical feasibility, economic feasibility, and
organizational feasibility. At the end of project initiation, the report of evaluating those areas
combines into a feasibility study and submits to the committee. (Dennis, 2012, p. 23)
 Figure 5: Feasibilty Criteria

Feasibility Criteria (P4)

Technical feasibility

The first technique in the feasibility analysis is to assess the technical feasibility of the project, the
extent to which the system can be successfully designed, developed, and installed by the IT group.
Technical feasibility analysis is, in essence, a technical risk analysis that strives to answer the
question: “Can we build it?”. Many risks can endanger the successful completion of the project.

First and foremost is the users’ and analysts’ familiarity with the website. When analysts are
unfamiliar with the website, they have a greater chance of misunderstanding the users or missing
opportunities for improvement. The risks increase dramatically when the users themselves are
less familiar with the new website, such as with the development of a system to support a new
business innovatio. In general, the development ofnew systems is riskier than extensions to an
existing system, because existing systems tend to be better understood. Another potential
technical risk is familiarity with the technology. If systems using technology that has not been used
before, will likely result in a significant breakdown and failure will happen. Let's give an example
developing a web system with Node.js, it is still considered risky because the framework is still
new and many companies have no experience developing it yet.

Project size is an important aspect that should be considered, all attributes like number of staffs
on the development team, time required to complete the project, quantity of features in website.
The larger the systems, the more risks they will face as they become more complicated and,
therefore, difficult to manage. For example, developing an ordinary e-commerce site is easier than
developing a complex system like Google Maps or Google Translate.

Ultimately, project managers should worry about the compatibility of new software with old
systems that already exist in the organization. Usually, a system is developed for integration into
a system exists within a company, so it is very important to consider compatibility when
developing a new system. The new system may depend on data stored in the old system the
system to operate. For example, when Google developed Messenger.com, they had to make sure
that Messenger.com has all the friends that already exist on Facebook.com.

Tune Source also have all the risks mentioned above, however we can still say that technically,
Tune Source’s website project is feasible. The first reason Tune Source’s customer has been
familiar with the concept of the upcoming website, because the company has had a website that
helps customers find and buy physical CDs. The second reason is the IT department at Tune Source
has been also familiar with Internet technology because they are already working with the ISP to
maintain the website. Although the company has some familiarity with music search online,
however, their experience with music download and subscription services are still limited. This can
be very difficult for Marketing and IT department to adapt to the new system. Because they only
have knowledge about selling physical CDs. Another risk that must be considered is that there is a
lot of music streaming and subscription-based companies that already exist and compete with
Tune Source's new system, for example: Spotify.com, iTunes.com.
Economic Feasibility

(Dennis, 2012, p. 25)

The next technique is economic feasibility analysis or cost-benefit analysis. This helps answer the question:
"Should we build it?" The report examines the costs and benefits involved into the project, calculate the
numbers and measure the financial adequacy. The results of this analysis will help the committee
confidently decide and determine finances oppunities and risks can come. Most of a company's resources
are limited, many projects will have to compete for a portion of this resource. The more expensive the
project, the more detailed report should be. This is definitely not a prblem with Tune Source because no
company will just let their money fly around uncontrolablely, financial management is the job of Finance
Department.

Of course, economically, the project is feasible. The cost of server maintenance, ISP, buildings is not on
par with the benefits gain from the project. The first reason is the high demand on the upcoming website,
loyal customer will definitely be happy if the website is completed, and Tune Source may gain a lot more
reputation than before along with the increasinng of customers and profit.

In short, the profit will be much more than the cost, so there is no reason for Tune Source find this project
unfeasible.

Organizational Feasibility

(Dennis, 2012, p. 33)

Finally, the remained technique is to evaluate the organizational feasibility of the system.
This study would answer the question:” How well the new system will be pick up and accepted by
targeted customers?” or in short:” if we built, will they come?” Organizational feasibility could be
the hardest assessment since there are many organizational factors could impact the project .

One way to assess a project's organizational feasibility is to understand whether the project objectives are
aligned with the business objectives. The strategic alignment is the fit between the project and the
business strategy - the larger the association, the more risk-free the project, from an organizational
feasibility perspective. For example, if the marketing department has decided to focus more on the
customer, then a CRM project that generates integrated customer information will have a strong strategic
fit with the marketing objective. Many projects fail if the IT department initiates them alone and has little
or no alignment with the business unit or organization's strategies.

The second way to assess an organization's feasibility is to conduct a stakeholder analysis. A stakeholder
is a person, group or organization that can affect (or can be affected by) a new system. In general, the
most important stakeholders in introducing a new system are the project champion, system user and
manager at the organizational level, but the system sometimes affects the stakeholders as well.
concerned. other. For example, the IS department may be a system related party because the jobs or roles
of the IS can be significantly changed after the system is deployed. A major stakeholder - apart from
champions, users, and management - in the Microsoft project that embedded Internet Explorer as part of
the Windows standard is the US Department of Justice. The champion is a senior operator and often, but
not always, the project sponsor, who creates the system requirement. The Champion supports the project
by providing time and resources (e.g. money) and by providing political support to the organization by
imparting the importance of the system to decision makers. organ. It's a good idea to play more than one
champion because if that champion leaves the organization, the support might also too.

Figure 6: Project's skateholders

Along with the project champion, an important part of the stakeholders is the organization management.
Organized management will encourage and convince that the new system will benefit the organization.
Eventually the users, they will be the new system users when it is released. Usually, the user discusses it
with the project team at an early stage and disappears until the software is complete and ready for use.
User engagement should be encouraged during system development as they can provide valuable
feedback and correct and direct project in the right direction.

Thus, from organizational perspective, this project has low risk. The top executives of the company have a
strong interest in the project, and the project champion, Carly Edwards, is a respected and knowledgeable
marketing executive. The users of the system, Internet consumers and in-store kiosk users, are expected
to appreciate the entry of Tune Source into the music downloadarena. Management at the stores may
have some concern about lost CD sales; however, since customers have so many other options available
formusic downloads, this system may prevent our losing those customers to other digital music sources
and may provide us with the opportunity to cross-sell those customers from our CD inventory.

Alternative technical solution

Evaluation Relative Custom Score Custom Score
Criteria Importance built built
(Weight) Technology Technology
Technical
Issues
Familiarity 20 3 3
with the
software Using Using PHP
Technology 20 JavaScript 5 4
familiarity
Compability 10 3 3
Project size 10 3 5
Maintenance 15 3 5
fee
Total score 265 295

Conclusion
In conclusion, the report stated all the criteria outlined in the asignment brief, explain the definition of
SDLC and SDLC models, risk management and plan to approach the risk. The report also explained the
purpose of the feasibility report and how Tune Source meet all the feasibility critera thus conclude that
digital music distribution platform is in line with this Tune Source project.
References
Boehm, b. W. (2005). A Spiral Model of Software Development.

Dennis, A. (2012). Systems analysis and design.