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. [CITATION Ala12 \p 6 \l 1033 ]

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

[CITATION Ala12 \p 13 \l 1033 ]

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

[CITATION Ala12 \p 13 \l 1033 ]

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

[CITATION Ala12 \p 14 \l 1033 ]

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

[CITATION Ala12 \p 15 \l 1033 ]

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

[CITATION Ala12 \p 51 \l 1033 ]

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
 Each stage has been predetermined
as well as landmarks can provide.
 Easy to follow and understand
Disadvantage
 The biggest problem of the waterfall is
that the project can only move forward
and cannot go back a step is the design
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

[CITATION Ala12 \p 53 \l 1033 ]

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
 This is a highly-disciplined model and
Phases are completed one at a time.
 Works well for smaller projects where
requirements are very well
understood.
 Simple and easy to understand and
use.
 Easy to manage due to the rigidity of
the model. Each phase has specific
deliverables and a review process.
Disadvantage
 High risk and uncertainty.
 Not a good model for complex and
object-oriented projects.
 Poor model for long and ongoing
projects.
 Not suitable for the projects where
requirements are at a moderate to
high risk of changing.
 Once an application is in the testing
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. [CITATION bar88 \p 64 \l 1033 ]

Advantage
 Changing requirements can be
accommodated.
 Allows extensive use of prototypes.
 Requirements can be captured more
accurately.
 Users see the system early.
 Development can be divided into
smaller parts and the risky parts can be
developed earlier which helps in better
risk management.
Disadvantage
 Management is more complex.
 End of the project may not be known
early.
 Not suitable for small or low risk
projects and could be expensive for
small projects.
 Process is complex
 Spiral may go on indefinitely.
 Large number of intermediate stages
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. [CITATION Ala12 \p 56 \l 1033 ]
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. [CITATION Ala12 \p 57 \l 1033 ]

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  Users may get confused in the
is 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. [CITATION Ala12 \p 57 \l
1033 ]

Advantage Disadvantage
 Is a very realistic approach to software  Not suitable for handling complex
development. dependencies.

 Promotes teamwork and cross  More risk of sustainability,

training. maintainability and extensibility.

 Functionality can be developed rapidly  An overall plan, an agile leader and

and demonstrated. agile PM practice is a must without
which it will not work.
 Resource requirements are minimum.
 Strict delivery management dictates
 Suitable for fixed or changing
the scope, functionality to be
requirements
delivered, and adjustments to meet
 Delivers early partial working the deadlines.
solutions.
 Depends heavily on customer
 Good model for environments that interaction, so if customer is not clear,
change steadily. team can be driven in the wrong

 Minimal rules, documentation easily direction.

employed.  There is a very high individual

 Enables concurrent development and dependency, since there is minimum

delivery within an overall planned documentation generated.

context.  Transfer of technology to new team

 Little or no planning required. 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. [CITATION bar88 \p 1 \l 1033 ]

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 Likelyhoo Impact Risk level Approach Plan

d
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. [CITATION Ala12 \p 23 \l 1033 ]

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

[CITATION Ala12 \p 25 \l 1033 ]

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

[CITATION Ala12 \p 33 \l 1033 ]

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 theproject 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.
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.