Professional Documents
Culture Documents
Internal verification:
Contents
Describe different software development lifecycles ............................................................... 5
1. Introduction: ........................................................................................................... 5
3. Describe two iterative and two sequential software lifecycle models. .................... 7
3.9. Explain how risk is managed in the Spiral lifecycle model. .................................. 15
3.10. Spiral development supports risk management in software projects in several ways
summarized in the following: ...................................................................................... 16
5. Automation........................................................................................................... 20
6. Elimination of human errors ................................................................................. 20
Advantages
It is very easy, realistic approach that provides flexibility to developers. And teamwork
promotes and cross training.
Disadvantages
As there are strict delivery management adjustments can be dictated to meet deadlines.
It is very difficult to implement this model without overall plan, an agile leader and agile
project manager.
If customer representative is not clear about the outcome of project then team can easily
get off the track.
During the development transfer or recruiting of new member in project will be quite
challenging due to lack of documentation.
3.2.V-Model
V-Model is mostly known as the validation and verification software development process
model (The Vee Model), and It is one of the most know software development methodology.
Although it is considered as an improvement to the waterfall model and it has some similarities as
the process also based on sequential steps moving down in a linear way, it differs from the waterfall
model as the steps move upwards after the coding phase to form the typical V shape. This V shape
demonstrates the relationships between each phase of the development life cycle and its associated
phase of testing.
V-Model Model Advantages
The Waterfall Model is a linear sequential flow. In which progress is seen as flowing
steadily downwards (like a waterfall) through the phases of software implementation. This
means that any phase in the development process begins only if the previous phase is complete.
The waterfall approach does not define the process to go back to the previous phase to handle
changes in requirement.
Waterfall Model contains the main phases similarly to other process models, you can
read this article for more information about phases definitions.
Waterfall Model Advantages
It is very easy to explain to the business users and explain the output of each phase.
Structures approach.
Stages and activities are well defined.
It is easier for project managers to plan, schedule the project, utilize the resources, and
define the milestones easily.
Validation and verification at each phase ensure early detection of
errors/misunderstanding at the same phase.
Each phase has specific deliverables.
Waterfall Model Disadvantages
A prototype typically simulates only a few aspects of, and may be completely different
from, the final product
Advantage
Reduced time and costs: Prototyping can improve the quality of requirements and
specifications provided to developers. Because changes cost exponentially more to implement as
they are detected later in development, the early determination of what the user really wants can
result in faster and less expensive software.
Improved and increased user involvement: Prototyping requires user involvement and
allows them to see and interact with a prototype allowing them to provide better and more
complete feedback and specifications.[6] The presence of the prototype being examined by the
user prevents many misunderstandings and miscommunications that occur when each side
believe the other understands what they said. Since users know the problem domain better than
anyone on the development team does, increased interaction can result in a final product that has
greater tangible and intangible quality. The final product is more likely to satisfy the user's desire
for look, feel and performance.
Disadvantage
Insufficient analysis: The focus on a limited prototype can distract developers from
properly analyzing the complete project. This can lead to overlooking better solutions,
preparation of incomplete specifications or the conversion of limited prototypes into poorly
engineered final projects that are hard to maintain. Further, since a prototype is limited in
functionality it may not scale well if the prototype is used as the basis of a final deliverable,
which may not be noticed if developers are too focused on building a prototype as a model.
User confusion of prototype and finished system: Users can begin to think that a
prototype, intended to be thrown away, is actually a final system that merely needs to be finished
or polished. (They are, for example, often unaware of the effort needed to add error-checking
and security features which a prototype may not have.) This can lead them to expect the
prototype to accurately model the performance of the final system when this is not the intent of
the developers. Users can also become attached to features that were included in a prototype for
consideration and then removed from the specification for a final system. If users are able to
require all proposed features be included in the final system this can lead to conflict.
Developer misunderstanding of user objectives: Developers may assume that users share
their objectives (e.g. to deliver core functionality on time and within budget), without
understanding wider commercial issues. For example, user representatives attending Enterprise
software (e.g. PeopleSoft) events may have seen demonstrations of "transaction auditing" (where
changes are logged and displayed in a difference grid view) without being told that this feature
demands additional coding and often requires more hardware to handle extra database accesses.
Users might believe they can demand auditing on every field, whereas developers might think
this is feature creep because they have made assumptions about the extent of user requirements.
If the developer has committed delivery before the user requirements were reviewed, developers
are between a rock and a hard place, particularly if user management derives some advantage
from their failure to implement requirements.
Excessive development time of the prototype: A key property to prototyping is the fact
that it is supposed to be done quickly. If the developers lose sight of this fact, they very well may
try to develop a prototype that is too complex. When the prototype is thrown away the precisely
developed requirements that it provides may not yield a sufficient increase in productivity to
make up for the time spent developing the prototype. Users can become stuck in debates over
details of the prototype, holding up the development team and delaying the final product.
There are various risks involved in the agile model and while developing the software we
have to be aware about those risks before starting our project. Among those various risks the
very first common risk is lacking details in task descriptions. We have to make sure that all
details are present and clear for the team so they know exactly what they are creating and the
best way to write these out are in the form of user stories or technical requirements. Another risk
usually encountered while going through agile model is priorities or directions change.
Sometimes the priorities of the project changes and thus features that were not originally planned
take top priority over the others.
When this happens, it’s important to make sure the clients know about the effect of those
changes on the developing system and even also the timeline and budget of project as mentioned
in earlier meetings. Another risk which many companies faces while adapting agile model in
their software development process is lack of documentation which leads to misunderstanding
among the developers. Because of poor documentation in this model when the current
programmer or any other member of development team leaves then it will be very difficult for
the new recruiters to get adapted with development scenario as there will be less documentation
and he won’t be able to grab the speed with other members. If the customer representative isn’t
clear about the outcome of project then team can easily get off the track so this risk should not be
underestimated while developing team and client representative should be well known about the
features that clients wants to get in system.
3.10. Spiral development supports risk management in software projects in several ways
summarized in the following:
The initial risk analysis that acts as a look-ahead step and aims at:
o Identifying most risks threaten the project.
o Classifying risks into user interface risks and development risks
o Evaluate these risks to decide upon the risks to handle through each cycle.
Moreover, this classification helps developers in implementing risk resolution techniques such as
prototyping and benchmarking.
The evolutionary prototyping spirals that aim at resolving performance and user
interface related risks. These spirals help in reducing major risks before proceeding into the
development process.
The risk analysis stage at each cycle that precedes each phase of the waterfall
phases in purpose of:
o Resolving program development and interface control risks inherent from the start
of the project.
o Evaluating and resolving the new risks that might arise after changing any of the
objectives, alternatives, or constraints at the beginning of the cycle.
The iterative feature of the spiral which allows the development process to go back
to the first quadrant at any point in progress which allows:
o Objectives, alternatives and constraints to change as more attractive alternatives
exist.
o New technology to be incorporated easily during the development process.
o The maximum optimization of project resources usage.
o To deal with poorly done activities in the earlier phases.
The review conducted at the end of each cycle with main stakeholders as a decision
point to avoid the lack of commitment risks during the next cycle.
Time and cost overrun risks are best managed using spiral development due to the
risk analysis stage conducted at each cycle. In this stage, the cost and time required for each cycle
are analyzed in advance to give a clear picture about the critical state of the project.
This helps the project manager and the developers get more control over these risks.
Risks related to the increased complexity of the project are also managed using
spiral.
This is achieved by the partitioning activity conducted at the planning phase.
o Decomposing the project into portions to be developed in parallel spirals obviously
reduces time contention related risks, since more work could be achieved during the same interval.
Major Sources of Risk in the Spiral Model Despite its risk driven nature, spiral has its own
sources of risks which are summarized in the following:
High reliance on the human factor
o All the activities related to identifying, analyzing, and resolving risks rely on the
experience of developers and their abilities in identifying and managing risks. If these abilities are
unavailable, major risks might remain hidden for several lifecycles and discovered late when it
matured into real problems. At that time, the cost of rework to recover from these risks becomes
very high.
Detailed risk management process
o Cost and schedule risks might increase using spiral due to its iterative feature,
especially for low risk projects wherein risk assessment is not required to be at this level of
granularity.
Explain the importance of a feasibility study
1. Introduction importance of feasibility study
“A feasibility study is an analysis used in measuring the ability and likelihood
to complete a project successfully including all relevant factors. It must account for factors that
affect it such as economic, technological, legal and scheduling factors. The feasibility study
helps to “frame” and “flesh-out” specific business scenarios so they can be studied in-depth.
Project managers use feasibility studies to determine potential positive and negative outcomes of
a project before investing a considerable amount of time and money into it.” (Don Hofstrand,
October, 2009) It tests the viability of opinion, a project or even new business. It is the
preliminary study undertaken before the real work of project starts to ascertain the likelihood of
the project’s success.
The main purpose of feasibility study is to emphasize the problems which could occur if
one pursues project and determines if, after considering all significant factors, the project is a
good idea.
Financial study : Financial planning is very important to handle the different operations
of the organization within the budget limits. In financial research, the researchers cover the
assessment of total capital requirements, sales and prices, break even outputs, amount of sales
required to attain profit in the business. It helps entrepreneurs to get an idea about how much
money is required for handling a business project successfully.
Capacity: 6 GB
Email Address : 6
Email forwarder : 6
Mail list : 2
Park Domains: 0
Cost : 2000$
Referrence :
https://desklib.com/2021/7/1/software-development-life-cycle-sdlc-
assignment/?fbclid=IwAR32StHaxxmlhWJ_oS-
vP2jeuebLML1Lu69x5cmG8PlYexan2WNlBMIw4g4
https://signup.base.vn/b118-hrm-plus-
cc/?utm_source=coc_coc&utm_medium=conversion&utm_campaign=b118-hrm-ns-
cc&utm_content=b118-hrm-ns-
cc&utm_term=ph%E1%BA%A7n%20m%E1%BB%81m%20doanh%20nghi%E1%BB%87p&
md=_05be50vdanX6qmsEHAREeliJjBybQaLpCmWke22GfHE5dC8NQZ2Xc9NtWBJAkb8pU
cNys401mD8N2jJyuSDQBRxXMH8G1hW4BBQx7d*Ko9areBxMPPSI7azhHu5IWdcZsNfs.