Lovely Professional University

Assignment – I

Of

Software Project
Management

Submitted by:- Submitted to:-

Imran Ansari Pency Juneja
Roll No. – B50
Reg. No. – 10906851
Section – S1906
Q. 1.

As a programmer ,you are offered a promotion to project management but

you feel that you can make more effective contribution in technical rather
than a managerial role. Discuss whether you should accept the promotion

Ans.:-

MY CURRENT ROLE
Do the Job Well
First and foremost a programmer must do his or her current job well to be
considered for a promotion. After all, how can we be promoted to a new job if
we haven’t demonstrated competence in the current one? This includes
following all company and department SOPs, guidelines and other policies. I
wrote a paper called “Writing Code that Lasts” for SUGI 2004 1 that contains
many tips on how to excel in the technical side of our job, and I will not go into
those details again here.
We should get a copy of our job description plus look through annual reviews to
make sure we’re meeting or exceeding expectations. These will give us some
ideas on where to focus our energy for improvement in our current position.

Keep in mind that we can’t break away from our current job if nobody else can
do it. To avoid this situation, we need to write clear code and provide
appropriate documentation so that others can easily work with it.

Practice Good Manners

As we learned back when we were children, good manners can go a long way.
Treat others respectfully and with tact. Volunteer compliments, both in public
and in private. Others like to be appreciated for their efforts, and to know what
they’re doing well. Just be sure to be honest: no one likes a suck-up!
With criticisms be discreet and specific. For example, instead of announcing to
friends in the department
“Sue is such a bad programmer. Her code is totally wrong and she has no
idea what she’s doing!”
we should tell Sue, in private
 “Based on some code I reviewed, it seems you’re unfamiliar with PROC
LIFETEST. Here are some resources for you…”
Sue is likely to appreciate our helpful advice and the fact that we’re not playing
the role of “tattletale” to the manager. Sue will hopefully use this advice to
grow as a programmer, and this type of approach might even help keep her from
becoming defensive in the future when discussing her code with others.
Usually it’s better to initially discuss issues with the individual and avoid
bringing in management, if at all possible. Sometimes we must offer criticisms
of another employee to management, and in this event, again, we should do so
in private and stick to the facts.

Handle the Bad

Before running to our manager with complaints and problems, first give some
thought to solutions. We should enter our manager’s office not only with what’s
wrong, but at least one idea for how to fix it. For example, instead of saying
“That vendor never does what I tell them to do!”
we could say
“Our vendor doesn’t seem to understand my requests. I send them via
email, but do you think it might be a better idea if I scheduled regular
telecons instead?”
Our manager won’t always end up using one of our solutions, but is often able
to build off of them.
We also need to deal with bad news of delays to a project. We may be tempted
to put off letting others know that we’re behind on our project, hoping that
things will eventually work out. It’s better to warn our manager and project lead
early on of any potential delays because often they can help us overcome them.
With warning, our manager or project lead might be able to shift us resources,
reprioritize workloads, authorize overtime pay, or even extend the deadline. The
sooner they know about potential delays, the more help they can be. We all
know that when we’re in the middle of a crunch, adding new people to the team
usually doesn’t help because they don’t know what to do and we don’t have
time to train them; but if those same people were added earlier on, it might have
made all the difference. Finally, it makes our manager or project lead look bad
if they can’t deliver on time, so we want to do what we can to help them and
prevent surprises.
MY NEXT ROLE
Personal Research
Since probably grade school we’ve pondered the question “What do I want to
do when I grow up?” At that time we might have said a fire fighter, teacher, or
ice skater. Over time our career plans evolved, and suddenly it seems we’re
“grown up”! We’re still asking the “What do I want to do” question, it’s just the
timeframe that’s changed. Now we need to think about what we want to be
doing 2 years from now, 5 years from now, 10 years from now, etc.
There is a whole world of possibilities out there to choose from. For some it’s to
become a manager and later a director. For others it’s a more technical route.
We might want to remain in our current industry (e.g., biotech) or we might
want to give another industry a try. We need to give some thought to these
options and decide where to focus our energy.
For some of us, we’re not at all sure what we want to do. There are so many
options to choose from! Even if we do nothing else, we should make a list of:
• What it is we like about our current job
• What we don’t like or wish we could do less of
• What types of activities we’re not doing now that we’d like to do

Job Research
After completing the personal research to figure out what we want to do, we can
then tackle finding a job that has these traits. If we’re interested in finding
another position within our current company, we have many resources available
to us. Often there are job descriptions available via a company intranet, but if
not our manager and/or the HR department should be able to get these for us.
We can consider positions within and outside our own department, and should
think about not just the next job, but the entire direction of our career and the
various jobs that could help get us there: in other words, a career path.
Once we find positions of interest, we should then try to learn more about them.
A job description doesn’t usually tell the whole story. Find some people
currently in those positions, talk to them about what they really do, and see out
what they like/don’t like about the job.
It might be that our career objectives aren’t a good match for our current
company. Some examples include when:
 • We’ve been working with clinical trials data but have a burning desire to
work in the financial industry
• They expect no openings in the area we want to move into
• We want to move into or out of contracting/consulting

Q. 2.

The process of project planning is iterative. and must be continually

reviewed. Using example explain the major reasons and the causes for this.

Ans.:-

Iterative Development: A Form of Phased Development

Iterative development is a form of phased development, which is not a new

concept; project managers often use phases to break projects into discrete
sections within a project lifecycle. Each phase has a clearly stated objective, a
defined scope, and specific evaluation criteria. These phases are generally
accompanied by a schedule that defines the activities required to meet the stated
objectives.

Typical Phased Development Approach

Many systems and software engineering organizations use the following phases

• Product Definition Phase: Understand and scope the project.

• Proof-of-Concept Phase: Demonstrate that the product is feasible and
mitigate some key risks.
• Product Development Phase: Incorporate and complete the system's
functionality.
• Manufacturing and Production Transition Phase: Manufacture and
deliver the product to the market.

Within each of these four phases, they define clear objectives and follow a
development lifecycle that includes requirements, analysis and design, code and
unit test, subsystem integration, implementation, testing; and other disciplines,
such as configuration management.
The outcome of each phase is a tested product of known maturity. In their
implementation, however, these four phases allow for many variations. For
example, take the Product Development Phase. What is the expected duration of
this phase? Weeks, months, quarters (three months), years, tens of years? Also,
does the result of the Proof-of-Concept Phase form part of the final product, or
is it to be scrapped and redeveloped? Do all of the artifacts mature over time, or
is there an expectation that they have been "signed off" on, never to be updated
again?

Based on my experience, if the Proof-of-Concept Phase has run for several

months, then the Product Development Phase will likely run for quarters or
years. Planning and managing this effort can be difficult, because the defined
milestones are not good indicators of the project's "true" status. For example,
even when requirements are approved as 100 percent complete, in reality, many
more changes are expected before the end of the project.

Phased Development According to RUP

Now that we've looked at a common form of phased development, let's look at
phased development as defined by the Rational Unified Process® (RUP®),
which we will use as the basis of our methodology.

The RUP defines four phases for iterative development (see Figure 2). Each
phase provides the team with a specific focus to support the continuous and
controlled refinement of the requirements, architecture, design, and code. These
phases are:

• Inception: Define the scope and lifecycle of the project.

• Elaboration: Mitigate risks and create a stable baseline architecture.
• Construction: Develop the remainder of the system as efficiently as
possible.
• Transition: Train users to be self-sufficient; get customer acceptance of
the product.

The RUP advocates two levels of granularity for planning: a coarse grain for
the four phases of the project (outlined in the Software Development Plan), and
within each phase, a fine grain called an iteration (detailed in the Iteration
Plan).
 Within any phase, there will typically be one or more iterations of a
manageable duration (e.g., one week to many months), depending on the size of
the project.

In every iteration, relevant disciplines, such as project management,

requirements, analysis and design, coding, integration, testing, and so on, are
performed. The degree to which any one of these disciplines is performed will
vary according to the current phase of the project. The key goal of every
iteration is to produce an executable version of the system that is tested and
measured against the defined evaluation criteria.

Every iteration is planned in sufficient detail to ensure that all team members
have a clear and unambiguous understanding of the iteration's objectives, scope,
and evaluation criteria. This is so that only essential activities required to meet
the objectives and evaluation criteria are performed during the iteration. See the
below for details about other terms, RUP activities, and artifacts referred to in
this article.
Challenges of Iterative Development

Although iterative development has been demonstrated to improve project

planning, management, predictability, and time-to-market, it can also place new
pressures -- such as the need to learn new techniques -- on team members.
Iterative development might seem more complex than the traditional waterfall
approach (see Figure 3) because the project now appears to require many
"waterfall-like" cycles -- one (or more) per iteration -- rather than one per phase
or project (all four phases). In helping teams transition from waterfall to
iterative development, we must help them understand that we perform each
discipline (project management, requirements, analysis and design, coding,
integration, testing, and so on) as required in every iteration, not just once for
the entire project.

Q. 3.

If a software system is intangible, mention the different problems faced by

the project management team due to the intangibility of the system. Also
mention the reasons behind them.

Ans.:-
In it, I will argue that many issues related to software development processes,
and mainly to problems associated with such processes, can be explained by the
fact that software is an intangible product. I will suggest that if we adopt this
perspective when addressing software development processes, we might arrive
at different kinds of insights. Googling the expression "problems with software
development” results in more or less the following items: requirement
complexity, customers' inability to know all the requirements in advance,
changes in requirements, difficulties in managing frequent changes, process
bureaucracy, difficulties in estimating development times, budget overrun, and
the application of a wrong process for the development process.

A fast glance is sufficient to reveal that all these problems are connected to
people (mainly customers and team members) and that their origin is rooted in
human aspects (primarily cognitive and social) rather than in technological
ones. The outcomes of these problems are well known. Such outcomes include,
for example, buggy software products and customers who are unsatisfied with
the products they receive (some estimations indicate that about 75% of
customers are not pleased with the product they requested). The first outcome
mentioned clearly derives from a cognitive factor: testing software products is
not an easy or trivial task; the second outcome derives from a social issue,
namely the communication channels between customer and developers.

Later on in this column, I attempt to explain the importance of human aspects in

software development processes. The main reason for this is, in my opinion,
that software is a unique intangible entity with which the human mind has not
been shaped to cope during its evolution; therefore, our ability to deal with such
intangible artifacts is limited. It can be rightly argued that many intangible
entities have been dealt with during human evolution – dreams, fears, stories,
plans, and so on. This, of course, is true. The difference, however, between
software and such entities is expressed mainly in two features. First, these
entities are not products developed by someone for the use of someone else.
Second, software is not only an intangible product, it is also executed on a
computer. This means that the developed artifact is not the one that is actually
used by its users. The same argument that highlights software uniqueness is
very well applicable also with respect to other artifacts, such as knowledge and
the emerging discipline of knowledge management. Still, although knowledge
management deals with an intangible entity – knowledge – it is not a product
that is constructed by someone for the use of someone else.

As it turns out, and as is explained in what follows, software intangibility

influences almost every activity conducted in the course of software
development. For purposes of clarity, the term software will, hereinafter, mean
the code itself and not the product (the software tool or the application)
generated by the code. First, the fact that software is an intangible entity
increases the need for verbal communication between teammates and between
customers and developers. When wishing to communicate an idea, it is not
longer sufficient to point at something and form an impression based on sight; it
is no longer possible to touch it and make sense of its nature; it is not possible to
hear the sounds it makes and understand what this sound means. In general, our
ability to use our senses for software-related communication is limited;
therefore, the importance of verbal communication between teammates and
between teammates and customers is increased. If such communication is so
vital, then it is not surprising that if it goes wrong, problems emerge.

Second, when a team works on an intangible entity it is harder to build a

relationship of trust. The reason for this is that under the common belief that
knowledge is power, with both its positive and negative aspects, it is easier to
hide knowledge when the subject being dealt with is an intangible entity (simply
because it is easier to hide the fact that knowledge is not being shared). This
lack of trust has a back-influence on the communication between people, which,
as explained in the previous paragraph, has an important impact on the
successful performance of the software development task.

So far, we have seen how software intangibility influences mainly the social
aspect of software development. In the next paragraphs I will highlight the way
in which the fact that an intangible entity – software – is executed on a
computer further influences the entire process of software development, this
time mainly from a cognitive perspective.

First, the facts that software is an in tangible entity and is executed on a

computer enable us to create complex structures, made up of loops and
branches.

Q. 4.

Fixed size contracts, where contractors bids fixed price to complete a

system development , may be used to move project risk from client to the
contractor. If anything goes wrong contractor has to pay. Suggest how the
use of such contracts may increase the likelihood that product risk will
arise.

Ans.:-

At the start of the project

Selecting suppliers

The process of selecting suppliers is the subject of detailed methodologies. In

the ePMbook we will only summarise the considerations.
The style of selection will vary according to your needs and environment. We
saw above that there is a large range of contractual situations to consider. The
more significant the contract, the more attention you are likely to pay to the
selection and procurement processes.

Styles also vary noticeably between the public and private sector:

 In the public sector, the emphasis tends to be on completeness and

fairness. All potential vendors should be identified and given an equal
chance to win. Various rules, norms, standards and legal requirements
apply to regulate the process. Certain types of purchase can be made from
standard approved suppliers without the need to enter into a full selection
process. Rules are also relaxed for low-value contracts.
 In the private sector, the objective is usually to gain maximum benefit.
That might be achievable by making a rapid choice from a small number
of leading suppliers. It might also be possible to partner with a single
reliable supplier. Selection exercises are used only where there is a
genuine need to search the marketplace for the best supplier.

Start by defining what you need. Try to limit this to the genuine business
requirements. Do not make assumptions about the solution nor add in
unnecessary detail. To do so would restrict the vendors' ability to propose the
best overall solution to meet your needs.

Make sure it is clear (both to yourself and to potential bidders) which

requirements are so vital that you could not consider any proposal that failed to
address them . If the vendor can see that their proposal will be rejected, there is
no point in the bidder wasting their time or yours by responding to a Request
For Proposal. Be very careful, however, to restrict this to absolute needs that
could not be addressed some other way. It is common for people preparing
requirements documents to claim many things are mandatory - only to change
the rules when they realise no vendor can do everything.

In a classic selection process, these requirements are used to formulate a

Request For Proposal (RFP) which will be issued to potential vendors.
(Organisations use many different names for this concept - find out what
language is used in your organisation.) Each vendor will consider their
response. They will often need further interaction with you to explore your
precise requirements or explore possible directions. (In the public sector
scenario, anything you tell a competing vendor must be relayed to the others.)

After a reasonable period of time the vendors submit the proposals to you for
evaluation. Before they arrive you should have taken the time to define how you
will assess the responses. Develop a balanced view of the relative importance of
various requirements. Just because you asked 100 questions about accounting
and only 10 about the electronic storefront does not mean the accounting issues
outweigh the customer perspective.

You will probably want to perform other investigations to complement the

information in the formal proposal. For example, you might ask for
demonstrations, interview existing customers, investigate the vendor's financial
status and check their track record.

With a large number of potential vendors, it is common to narrow the field in

stages, maybe starting with a Request for Information to arrive at a short list,
followed by the Request for Proposal, and then narrow the field again before
conducting detailed investigations.

Where it is not necessary to make a selection decision on the basis of formal

tenders received, it may be more efficient to study the vendors, services and
products available then make a straightforward purchase decision. To do so, you
would need access to sufficient knowledge or information about the competing
options.

You might still approach several vendors and request information, prices etc.
The key difference is that you collect the information you need, then make a
decision. You do not ask them to submit formal bids against a specially
prepared RFQ document.

Following your decision in principle, typically you would still enter into
negotiations with the vendor to ensure you get a good deal that meets your
needs and avoids any contractual pitfalls.

The great advantage would be the time saving. Preparing a formal RFP can
often take several weeks. It will take a further period of weeks for it to be
received by the vendors, studied, queried, and responded to. On receipt of the
vendors' proposals you might then spend weeks reading, querying, investigating
and evaluating the detail.

This style of procurement is also the typical way you would hire individuals as
sub-contractors - for example contract programmers. You would evaluate the
individuals' career histories and capabilities, interview them, then attempt to
come to mutually agreed terms with those that you consider the most
appropriate.

Where the contract concerns a commodity item, you might pay even less
attention to the choice of item and vendor. If you need a projector, you might
simply find the nearest supplier and buy or hire one.

In some cases, significant contracts can be handled in this way, provided the
content is subject to pre-existing, approved purchase lists. For example, you
might be able to buy 100 PCs directly from an approved supplier or you might
be able to hire consultants through a framework contract.

Even in such cases, you may need to consider the detail of the contractual
relationship. Unless the transaction is a simple consumer purchase, you will
need to check the small print for warranties, terms and conditions etc.

Be particularly careful if the minor components are essential to your overall

solution. For example, if your design is based on a particular type of mobile
device you would not want to find that it ceases production shortly after you
have finished.

Q. 5.

Fixing and finding a software after delivery costs 100 times more than
finding & fixing a problem in early design hours. Discuss

Ans.:-

When an old idea is a good idea that improves to become a better idea, we
should all want to benefit from that evolution.Software Inspection was a good
idea when started in 1972. Inspections havecontinued to provide a quick return
on investment and perhaps one of thequickest for all the methods and processes
available to the software practitioner.

In a recent editorial in Informationweek [STA02], Stephanie Stahl, the editor,

says "In order to have great software, companies have to make completion dates
and deadlines a matter of history." She then quotes a Steven Jones who gave her
this input, "Bottom line, it will be passed to the next phase when it’s right. No
dates, no expectations set. When it’s right, it’s ready." Well, as has been known
for some time, Software Inspections not only make it right, but also makes it
ready at a lower cost. How can anyone in business who believes in quality resist
such an offer?

The following excerpts are from my recent book, High Quality Low Cost
Software Inspections, and are included here with the permission of my
publisher. [RAD02] While I cannot in this brief article address all aspects of the
Software Inspections evolution since 1972, I believe you will find excerpts
below that may stimulate you to further exploit Software Inspections. And if
you are one of those who have cast away Inspections for whatever reason, I
sincerely anticipate that you will try them again to your advantage.

Inspections have clear value independent of any model or standard for

software development.

When I am asked which Key Process Area in the SEI’s Capability maturity
Model (SW-CMM I think gives the most value or which should be the highest
priority, I always respond with Inspections (Peer Reviews in the SW-CMM). I
believed this to be true in the 1980’s and I still believe it today. With an honest
effort given to Inspections, we can open the eyes of management for more rapid
process improvement. Inspections never fail to deliver as promised, or prove to
be too difficult, when the preconditions are satisfied. We know how to make
Inspections successful.

So Why isn't Everyone Using Inspections

If Inspections provide significant benefit, why has adoption been so slow? Why
is not all of the software community using the method? The publicly published
data twenty-four years ago clearly demonstrated their effectiveness, and recent
reports continue to demonstrate their effectiveness. Why have Inspections not
taken a firmer root and achieved wider use?

The reasons for this vary. I believe this is partially due to views that Inspections
can only be done one way. This book will eliminate at least some of this
misunderstanding. Another reason for the resistance to Inspections is the view
that they are not easy to do well. There are factors, including social and
psychological, that we must consider. Management often views Inspections as
an added cost, when in fact Inspections will reduce costs during a project. We
will see throughout this book how Inspections save both cost and time.

Since the inception of Inspections, with the advent of each new development
tool or language, the providers and users seem to believe that Inspections do not
add value or are less necessary. This is clearly not true, since programmers still
make defects with these tools and languages. However there often is little
documentation as to how well Inspections work in these new environments, so a
false belief that Inspections do not apply may be propagated by myth. We will
see later in the book that Inspections do apply in these development
environments also.

Because of these and other factors, shortcuts in the Inspection process have
been taken without any proof that the change is an improvement. Some of these
homegrown changes cause the Inspection process to be less effective. In turn
the value of what was defined as the Inspection process is diminished. Thus
failure becomes a self-proving "fact."

Inspections may not be the most enjoyable engineering task compared to

designing and coding. Also, programmers are very possessive about artifacts
they create. Inspections are labor intensive and low tech, but they do work.

Do Good Programmers Make Defects?

How many times have you been convinced, absolutely convinced, that you had
either written a defect-free program or had "tested out" all of the defects only to
sadly discover that there was yet another "bug"? One has to wonder how we as
programmers have been able to repeatedly survive this cruel onslaught to our
egos. I am not talking about the slovenly programmer who in some instances
seems to develop as many defects as lines of code (LOC) in a program or
paragraphs in a document, or about the programmers who have found
themselves in a schedule crunch and don’t have enough time to develop their
best work. Rather, I am talking about that qualified programmer (you and I are
probably good examples; well, at least you), who does have sufficient time to
produce a defect-free piece of work. Yet, after the program is delivered to test
or to the user, defect fixes have to be applied to the work product. I am not
going to try to come to terms here with why this may happen, for there can be
many systemic reasons. Let it be known for now that good programmers do
indeed make defects, and if this is true for good programmers then it must
follow for all others in the population of programmers. All programmers can
and do want to learn from their injected defects. We will see later in the book
how both Inspections and Defect Prevention are natural combined processes for
programmers to use, when they are adapted for effective success.

Every organization or company hires the best people. At least that is what we
hear. One has to wonder where the worst people go. Some of them exist in
every organization. Most cultures will not easily accept the reality of a natural
distribution of capability and talent. It seems to be almost a taboo subject.
Nonetheless it exists in every organization. What we should want to do, and
what the SW-CMM enables, is to achieve a higher maturity and improved
capability in software processes for all people in an organization.

People and processes become more capable as an organization moves up the

SW-CMM levels. An example is shown in Figure 4 for the Inspection process
from organizations I have come across over the past twenty-eight years. This
figure represents by example that as an organization moves up the SW-CMM
ladder, the effectiveness; i.e., the percentage of defects removed with
Inspections increases with each level attained. Improved effectiveness should
also be seen in other processes as an organization’s maturity grows, but for
Inspections it is easier and faster to see.

Q. 6.

Using example discuss why it is important for a software project

management to produce an overall description of a system architecture at
an early stage in the system specification.

Ans.:-

Planning

The important task in creating a software product is extracting the requirements

or requirements analysis. Customers typically have an abstract idea of what they
want as an end result, but not what software should do. Incomplete, ambiguous,
or even contradictory requirements are recognized by skilled and experienced
software engineers at this point. Frequently demonstrating live code may help
reduce the risk that the requirements are incorrect.

Once the general requirements are gathered from the client, an analysis of the
scope of the development should be determined and clearly stated. This is often
called a scope document.

Certain functionality may be out of scope of the project as a function of cost or

as a result of unclear requirements at the start of development. If the
development is done externally, this document can be considered a legal
document so that if there are ever disputes, any ambiguity of what was promised
to the client can be clarified.

Implementation, testing and documenting

Implementation is the part of the process where software engineers actually

program the code for the project.

Software testing is an integral and important part of the software development

process. This part of the process ensures that defects are recognized as early as
possible.

Documenting the internal design of software for the purpose of future

maintenance and enhancement is done throughout development. This may also
include the writing of an API, be it external or internal. It is very important to
document everything in the project.

Deployment and maintenance

Deployment starts after the code is appropriately tested, is approved for release
and sold or otherwise distributed into a production environment.

Software Training and Support is important and a lot of developers fail to

realize that. It would not matter how much time and planning a development
team puts into creating software if nobody in an organization ends up using it.
People are often resistant to change and avoid venturing into an unfamiliar area,
so as a part of the deployment phase, it is very important to have training classes
for new clients of your software.

Maintaining and enhancing software to cope with newly discovered problems or

new requirements can take far more time than the initial development of the
software. It may be necessary to add code that does not fit the original design to
correct an unforeseen problem or it may be that a customer is requesting more
functionality and code can be added to accommodate their requests. If the labor
cost of the maintenance phase exceeds 25% of the prior-phases' labor cost, then
it is likely that the overall quality of at least one prior phase is poor. In that case,
management should consider the option of rebuilding the system (or portions)
before maintenance cost is out of control.

Bug Tracking System tools are often deployed at this stage of the process to
allow development teams to interface with customer/field teams testing the
software to identify any real or perceived issues. These software tools, both
open source and commercially licensed, provide a customizable process to
acquire, review, acknowledge, and respond to reported issues. (software
maintenance)
Software Development Models

Several models exist to streamline the development process. Each one has its
pros and cons, and it's up to the development team to adopt the most appropriate
one for the project. Sometimes a combination of the models may be more
suitable.

Waterfall Model

The waterfall model shows a process, where developers are to follow these
phases in order:

1. Requirements specification (Requirements analysis)

 2. Software Design
3. Integration
4. Testing (or Validation)
5. Deployment (or Installation)
6. Maintenance

In a strict Waterfall model, after each phase is finished, it proceeds to the next
one. Reviews may occur before moving to the next phase which allows for the
possibility of changes (which may involve a formal change control process).
Reviews may also be employed to ensure that the phase is indeed complete; the
phase completion criteria are often referred to as a "gate" that the project must
pass through to move to the next phase. Waterfall discourages revisiting and
revising any prior phase once it's complete. This "inflexibility" in a pure
Waterfall model has been a source of criticism by other more "flexible" models.

Spiral Model

The key characteristic of a Spiral model is risk management at regular stages in

the development cycle. In 1988, Barry Boehm published a formal software
system development "spiral model", which combines some key aspect of the
waterfall model and rapid prototyping methodologies, but provided emphasis in
a key area many felt had been neglected by other methodologies: deliberate
iterative risk analysis, particularly suited to large-scale complex systems.

The Spiral is visualized as a process passing through some number of iterations,

with the four quadrant diagram representative of the following activities:

1. formulate plans to: identify software targets, selected to implement the

program, clarify the project development restrictions;
2. Risk analysis: an analytical assessment of selected programs, to consider
how to identify and eliminate risk;
3. the implementation of the project: the implementation of software
development and verification;

Risk-driven spiral model, emphasizing the conditions of options and constraints

in order to support software reuse, software quality can help as a special goal of
integration into the product development. However, the spiral model has some
restrictive conditions, as follows:

1. spiral model emphasize risk analysis, but require customers to accept and
believe that much of this analysis, and make the relevant response is not
easy, therefore, this model is often adapted to large-scale internal
software development.
 2. If the implementation of risk analysis will greatly affect the profits of the
project, then risk analysis is meaningless, therefore, spiral model is only
suitable for large-scale software projects.
3. Good software developers should look for possible risks, an accurate
analysis of risk, otherwise it will lead to greater risk.

First stage is to determine the stage of the goal of accomplishing these

objectives, options and constraints, and then from the perspective of risk
analysis program, development strategy, and strive to remove all potential risks,
and sometimes necessary to achieve through the construction of the prototype.
If some risk can not be ruled out, the program to end immediately, or else start
the development of the next steps. Finally, evaluation results of the stage, and
the design of the next phase.

Iterative and Incremental Development

Iterative development prescribes the construction of initially small but ever

larger portions of a software project to help all those involved to uncover
important issues early before problems or faulty assumptions can lead to
disaster. Iterative processes are preferred by commercial developers because it
allows a potential of reaching the design goals of a customer who does not
know how to define what they want.