IJCSI International Journal of Computer Science Issues, Vol.

8, Issue 5, No 3, September 2011

ISSN (Online): 1694-0814
www.IJCSI.org 390

SWOT Analysis of Software Development Process Models

Ashish B. Sasankar1, Dr Vinay Chavan2
1
P.G. Department of Computer Science ,GHRIIT
Nagpur, Maharashtra, India

2
Department of Computer Science,S.K.Porwal College,Kamptee
Nagpur, Maharashtra, India

Now what a software lifecycle model is. Some definition

Abstract are:
Software worth billions and trillions of dollars have gone waste “framework of processes and activities concerned with the
in the past due to lack of proper techniques used for developing life cycle that may be organised into stages, which also
software resulting into software crisis. Historically , the processes acts as a common reference for communication and
of software development has played an important role in the
understanding” (ISO/IEC FDIS 12207:200726);
software engineering. A number of life cycle models have been
developed in last three decades. This paper is an attempt to “A partitioning of the life of a product or project into
Analyze the software process model using SWOT method. The phases.” (CMMI-DEV36. This is the definition for a
objective is to identify Strength ,Weakness ,Opportunities and lifecycle model of any product or service. This may be
Threats of Waterfall, Spiral, Prototype etc. software);
Keywords: SDLC,SWOT. “software life cycle models serve as a high-level definition
of the phases that occur during development. They are not
aimed at providing detailed definitions but at highlighting
1. Introduction the key activities and their interdependencies” (ISO/IEC
TR 1975940);
Software lifecycle models are representations of the “Lifecycle models describe the interrelationship between
sequence and interrelationship of broad phases within the software development phases” (The NASA Software Safety
software lifecycle. Their principal purpose is to provide a Guidebook31);
high-level plan for software lifecycle activities. They are
therefore essentially management tools. The use of a
software lifecycle model on a software project is 2. Process Model/Life Cycle Variations
important. Without the plan it provides, it can be difficult
to effectively manage the project. Professional system developers and the customers they
Within the field of Computer Science, a large number of serve share a common goal of building information
software lifecycle models have been proposed. Each model systems that effectively support business process
has its own strengths and weaknesses, and each is more objectives. In order to ensure that cost-effective, quality
appropriate in certain project circumstances than others. It systems are developed which address an organization’s
is generally recognised that no single software lifecycle business needs, developers employ some kind of system
model is appropriate in all circumstances. Because of this, development Process Model to direct the project’s life
for a particular software project, it is necessary to select a cycle. Typical activities performed include the
software lifecycle model that suits the project’s following:[1]
characteristics. This is an important decision. The use of an · System conceptualization
inappropriate software lifecycle model can increase · System requirements and benefits analysis
project costs and timescales and reduce software quality. · Project adoption and project scoping
· System design
· Specification of software requirements
· Architectural design
· Detailed design
· Unit development
· Software integration & testing
IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 5, No 3, September 2011
ISSN (Online): 1694-0814
www.IJCSI.org 391

· System integration & testing mature software process. In the absence of an organization-
· Installation at site wide software process, repeating results depends entirely
· Site testing and acceptance on having the same individuals available for the next
· Training and documentation project. Success that rests solely on the availability of
· Implementation specific individuals provides no basis for long-term
· Maintenance productivity and quality improvement throughout an
organization.”[4]
Process Model/Life-Cycle Variations
While nearly all system development efforts engage in 2.1 The Waterfall Model
some combination of the above tasks, they can be The Waterfall Model is the earliest method of structured
differentiated by the feedback and control methods system development. Although it has come under attack in
employed during development and the timing of activities. recent years for being too rigid and unrealistic when it
Most system development Process Models in use today comes to quickly meeting customer’s needs, the Waterfall
have evolved from three primary approaches: Ad-hoc Model is still widely used. It is attributed with providing
Development, Waterfall Model, and the Iterative process. the theoretical basis for other Process Models, because it
most closely resembles a “generic” model for software
Ad-hoc Development development.
Early systems development often took place in a rather
chaotic and haphazard manner, relying entirely on the
skills and experience of the individual staff members
performing the work. Today, many organizations still
practice Ad-hoc Development either entirely or for a
certain subset of their development (e.g. small projects).
The Software Engineering Institute at Carnegie Mellon
University [2] points out that with Ad-hoc Process Models,
“process capability is unpredictable because the software
process is constantly changed or modified as the work
progresses. Schedules, budgets, functionality, and product Figure 2 Waterfall model
quality are generally (inconsistent). Performance depends
on the capabilities of individuals and varies with their The Waterfall Model consists of the following steps:
innate skills, knowledge, and motivations. There are few · System Conceptualization. System Conceptualization
stable software processes in evidence, and performance refers to the consideration of all aspects of the targeted
can be predicted only by individual rather business function or process, with the goals of determining
thanorganizational capability.” [3] how each of those aspects relates with one another, and
which aspects will be incorporated into the system.
· Systems Analysis. This step refers to the gathering of
system requirements, with the goal of determining how
these requirements will be accommodated in the system.
Extensive communication between the customer and the
developer is essential.
· System Design. Once the requirements have been
collected and analyzed, it is necessary to identify in detail
how the system will be constructed to perform necessary
tasks. More specifically, the System Design phase is
focused on the data requirements (what information will be
processed in the system?), the software construction (how
Figure 1. Adhoc development will the application be constructed?), and the interface
construction (what will the system look like? What
“Even in undisciplined organizations, however, some standards will be followed?).
individual software projects produce excellent results. · Coding. Also known as programming, this step involves
When such projects succeed, it is generally through the the creation of the system software. Requirements and
heroic efforts of a dedicated team, rather than through systems specifications from the System Design step are
repeating the proven methods of an organization with a translated into machine readable computer code.
IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 5, No 3, September 2011
ISSN (Online): 1694-0814
www.IJCSI.org 392

· Testing. As the software is created and added to the and offer greater flexibility. With Iterative Development,
developing system, testing is performed to ensure that it is the project is divided into small parts. This allows the
working correctly and efficiently. Testing is generally development team to demonstrate results earlier on in the
focused on two areas: internal efficiency and external process and obtain valuable feedback from system users.
effectiveness. The goal of external effectiveness testing is Often, each iteration is actually a mini-Waterfall process
to verify that the software is functioning according to with the feedback from one phase providing vital
system design, and that it is performing all necessary information for the design of the next phase. In a variation
functions or sub-functions. The goal of internal testing is to of this model, the software products which are produced at
make sure that the computer code is efficient, standardized, the end of each step (or series of steps) can go into
and well documented. Testing can be a labor-intensive production immediately as incremental releases.
process, due to its iterative nature.

Problems/Challenges associated with the Waterfall

Model
Although the Waterfall Model has been used extensively
over the years in the production of many quality systems, it
is not without its problems. In recent years it has come
under attack, due to its rigid design and inflexible
procedure.
Criticisms fall into the following categories:
· Real projects rarely follow the sequential flow that the
model proposes.
· At the beginning of most projects there is often a great
deal of uncertainty about requirements and goals, and it is
therefore difficult for customers to identify these criteria
on a detailed level. The model does not accommodate this
natural uncertainty very well.
Figure 3. Iterative Development [5]
· Developing a system using the Waterfall Model can be a
long, painstaking process that does not yield a working
Problems/Challenges associated with the Iterative
version of the system until late in the process.
Model
While the Iterative Model addresses many of the problems
Critic
associated with the Waterfall Model, it does present new
The waterfall model lacks prescribed technique of
challenges.
implementing management control over a project;
· The user community needs to be actively involved
planning, controlling, and risk management are not
throughout the project. While this involvement is a
enveloped within the model itself. Moreover, forecasting
positive for the project, it is demanding on the time of the
the estimated time and cost are complicated for each stage.
staff and can add project delay.
The life cycle can take long as the original requirements
· Communication and coordination skills take center stage
may no longer be valid, with little possibility for
in project development.
prototyping.
· Informal requests for improvement after each phase may
The waterfall model of system development works best
lead to confusion -- a controlled mechanism for handling
when any reworking of products is kept to a minimum and
substantive requests needs to be developed.
the products remain unchanged. It still remains useful for
· The Iterative Model can lead to “scope creep,” since user
steady and non-volatile types of projects, and if properly
feedback following each phase may lead to increased
implemented, generates significant cost and timesaving. If
customer demands. As users see the system develop, they
the system is likely to go through significant changes and if
may realize the potential of other system capabilities which
the system requirements are unpredictable then different
would enhance their work.
approaches are recommended, one such alternate approach
is popularly know as the spiral model.
Critic
One traditional process model is the waterfall model and
2.2 Iterative Development according to Schacchi was only accepted just until the
The problems with the Waterfall Model created a demand early 1980s because of its lack of functionality. The
for a new method of developing systems which could waterfall model is said to be the easiest model to
provide faster results, require less up-front information, understand and I do believe with this. It is easily
IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 5, No 3, September 2011
ISSN (Online): 1694-0814
www.IJCSI.org 393

understood because it provides a sequential succession of Prototyping is comprised of the following steps:
phases to be followed but then it is not that reliable. Just · Requirements Definition/Collection. Similar to the
seeing a figure of the flow of the waterfall model you Conceptualization phase of the Waterfall Model, but not as
would just see the sequence of phases to go through but the comprehensive. The information collected is usually
problem here is it would not go through a cycle but just limited to a subset of the complete system requirements.
have a one-way flow just like a waterfall. Because of its · Design. Once the initial layer of requirements
simplicity it would only be suitable for certain classes of information is collected, or new information is gathered, it
software development and would not work well with the is rapidly integrated into a new or existing design so that it
other software like interactive applications. This model may be folded into the prototype.
does not have risk management and management during · Prototype Creation/Modification. The information
the life cycle and mainly document-driven or code-driven from the design is rapidly rolled into a prototype. This may
that is why it would not work as smoothly as the other mean the creation/modification of paper information, new
model. coding, or modifications to existing coding.
· Assessment. The prototype is presented to the customer
2.3 Variations on Iterative Development for review. Comments and suggestions are collected from
A number of Process Models have evolved from the the customer.
Iterative approach. All of these methods produce some · Prototype Refinement. Information collected from the
demonstrable software product early on in the process in customer is digested and the prototype is refined. The
order to obtain valuable feedback from system users or developer revises the prototype to make it more effective
other members of the project team. Several of these and efficient.
methods are described below. · System Implementation. In most cases, the system is
rewritten once requirements are understood. Sometimes,
Prototyping the Iterative process eventually produces a working system
The Prototyping Model was developed on the assumption that can be the cornserstone for the fully functional system.
that it is often difficult to know all of your requirements at
the beginning of a project. Typically, users know many of Problems/Challenges associated with the Prototyping
the objectives that they wish to address with a system, but Model
they do not know all the nuances of the data, nor do Criticisms of the Prototyping Model generally fall into the
they know the details of the system features and following categories:
capabilities. The Prototyping Model allows for these · Prototyping can lead to false expectations. Prototyping
conditions, and offers a development approach that yields often creates a situation where the customer mistakenly
results without first requiring all information up-front . believes that the system is “finished” when in fact it is not.
When using the Prototyping Model, the developer builds a More specifically, when using the Prototyping Model, the
simplified version of the proposed system and presents it pre-implementation versions of a system are really nothing
to the customer for consideration as part of the more than one-dimensional structures. The necessary,
development process. The customer in turn provides behind the-scenes work such as database normalization,
feedback to the developer, who goes back to refine the documentation, testing, and reviews for efficiency have not
system requirements to incorporate the additional been done. Thus the necessary underpinnings for the
information. Often, the prototype code is thrown away and system are not in place.
entirely new programs are developed once requirements · Prototyping can lead to poorly designed systems.
are identified. Because the primary goal of Prototyping is rapid
development, the design of the system can sometimes
There are a few different approaches that may be followed suffer because the system is built in a series of “layers”
when using the Prototyping Model: without a global consideration of the integration of all
· creation of the major user interfaces without any other components. While initial software development is
substantive coding in the background in order to give the often built to be a “throwaway, ” attempting to
users a “feel” for what the system will look like, retroactively produce a solid system design can sometimes
· development of an abbreviated version of the system that be problematic.
performs a limited subset of functions; development of a
paper system (depicting proposed screens, reports, 2.4 Variation of the Prototyping Model
relationships etc.), or · use of an existing system or system A popular variation of the Prototyping Model is called
components to demonstrate some functions that will be Rapid Application Development (RAD).
included in the developed system.[6]
IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 5, No 3, September 2011
ISSN (Online): 1694-0814
www.IJCSI.org 394

RAD introduces strict time limits on each development Specification is created to provide a rudimentary starting
phase and relies heavily on rapid application tools which point.
allow for quick development. · System Construction/Modification. A system is created
Critic and/or modified according to whatever information is
Criticisms of the Prototyping Model generally fall into the available.
following categories: · System Test. The system is tested to see what it does,
• Prototyping can lead to false expectations. Prototyping what can be learned from it, and how it may be improved.
often creates a situation where the customer mistakenly · System Implementation. After many iterations of the
believes that the system is “finished” when in fact it is not. previous two steps produce satisfactory results, the system
More specifically, when using the Prototyping Model, the is dubbed as “finished” and implemented.
pre-implementation versions of a system are really nothing
more than one-dimensional structures. The necessary, Problems/Challenges associated with the Exploratory
behindthe- scenes work such as database normalization, Model
documentation, testing, and reviews for efficiency have not There are numerous criticisms of the Exploratory Model:
been done. Thus the necessary underpinnings for the · It is limited to use with very high-level languages that
system are not in place. allow for rapid development, such as LISP.
· It is difficult to measure or predict its cost-effectiveness.
• Prototyping can lead to poorly designed systems. · As with the Prototyping Model, the use of the
Because the primary goal of prototyping is rapid Exploratory Model often yields inefficient or crudely
development, the design of the system can sometimes designed systems, since no forethought is given as to how
suffer because the system is built in a series of “layers” to produce a streamlined system.
without a global consideration of the integration of all
other components. While initial software development is The Spiral Model
often built to be a “throwaway, ” attempting to The Spiral Model was designed to include the best features
retroactively produce a solid system design can sometimes from the Waterfall and Prototyping Models, and introduces
be problematic. a new component - risk-assessment. The term “spiral” is
This model cannot be used in robust application. It is used to describe the process that is followed as the
convenient because it is fast from the word itself. It can development of the system takes place. Similar to the
replace the specification phase but not the design phase Prototyping Model, an initial version of the system is
because it mainly relates to the designing phase. In the developed, and then repetitively modified based on input
waterfall model every phase should directly right at the received from customer evaluations. Unlike the
first time while prototyping changes frequently and the Prototyping Model, however, the development of each
discarded if wrong. version of the system is carefully designed using the steps
involved in the Waterfall Model. With each iteration
2.5 The Exploratory Model around the spiral (beginning at the center and working
In some situations it is very difficult, if not impossible, to outward), progressively more complete versions of the
identify any of the requirements for a system at the system are built.6
beginning of the project. Theoretical areas such as
Artificial Intelligence are candidates for using the
Exploratory Model, because much of the research in these
areas is based on guess-work, estimation, and hypothesis.
In these cases, an assumption is made as to how the system
might work and then rapid iterations are used to quickly
incorporate suggested changes and build a usable system.
A distinguishing characteristic of the Exploratory Model is
the absence of precise specifications. Validation is based
on adequacy of the end result and not on its adherence to
pre-conceived requirements. R=Review
Figure 4. Spiral Model[7]
The Exploratory Model is extremely simple in its
construction; it is composed of the following steps: Risk assessment is included as a step in the development
· Initial Specification Development. Using whatever process as a means of evaluating each version of the
information is immediately available, a brief System system to determine whether or not development should
continue. If the customer decides that any identified risks
IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 5, No 3, September 2011
ISSN (Online): 1694-0814
www.IJCSI.org 395

are too great, the project may be halted. For example, if a 3. SWOT Analysis
substantial increase in cost or project completion time is
identified during one phase of risk assessment, the 3.1 Waterfall model:-
customer or the developer may decide that it does not 1) STRENGTH:-
make sense to continue with the project, since the
• Easy adaptability by Non Technical person(End-
increased cost or lengthened timeframe may make
user).
continuation of the project impractical or unfeasible.
• Provides structure to inexperienced staff.
The Spiral Model is made up of the following steps: • No planning needed.
· Project Objectives. Similar to the system conception • Works well for small projects with fixed and clear
phase of the Waterfall Model. Objectives are determined, requirements.
possible obstacles are identified and alternative approaches • Milestones are well defined and understood.
are weighed. • Sets requirements stability.
· Risk Assessment. Possible alternatives are examined by • Good for management control (plan, staff, track).
the developer, and associated risks/problems are identified. • Works well when quality is more important than
Resolutions of the risks are evaluated and weighed in the cost or schedule.
consideration of project continuation. Sometimes • Each phase has well defined inputs and outputs.
prototyping is used to clarify needs.
· Engineering & Production. Detailed requirements are 2) WEAKNESS:-
determined and the software piece is developed. • All requirements must be known upfront.
· Planning and Management. The customer is given an
• Deliverables created for each phase are
opportunity to analyze the results of the version created in
considered frozen inhibits flexibility.
the Engineering step and to offer feedback to the
• Longest tangible delivery time. The customer
developer.
does not see anything but the whole product when
it’s ready.
Problems/Challenges associated with the Spiral Model
• It can give a false impression of progress.
Due to the relative newness of the Spiral Model, it is
difficult to assess its strengths and weaknesses. However, • Does not reflect problem-solving nature of
the risk assessment component of the Spiral Model software development. i.e iterations of phases.
provides both developers and customers with a measuring • Integration is one big bang at the end.
tool that earlier Process Models do not have. The • Little opportunity for customer to preview the
measurement of risk is a feature that occurs everyday in system.
real-life situations, but (unfortunately) not as often in the • Unsuitable for large projects and where
system development industry. The practical nature of this requirements are not clear.
tool helps to make the Spiral Model a more realistic
Process Model than some of its predecessors. 3) OPPORTUNITIES:-
• Requirements are very well known.
Critic • Product definition is stable.
Another traditional process model is the spiral model • Technology is understood.
which is suggested by Barry Boehm in 1988. Spiral model • New version of an existing product.
is still regarded as one of the best model because it is a • Porting an existing product to a new platform.
combination of the prototyping model and the waterfall • Helpful for developing similar type of software.
model and comprises the strengths of the other software
models.. According to Boehm, "the major distinguishing
feature of the Spiral Model is that it creates a risk-driven 4) THREATS:-
approach to the software process rather than a primarily
document-driven or code-driven process. It incorporates The problem with the waterfall model is that it has
many of the strengths of other models and resolves many become hardwired into the thinking of project
of their difficulties" [Boehm 1988]. This model is better planners. It has become so pervasive that the
than the waterfall because it may allow iteration. The main requirements, design, build, and test progression is a
concept of the spiral model is that it aims to minimize risks given in most projects.
with the use of repeated use of prototypes so that certain In the early days of simple, stand-alone applications,
changes may be applied over again if there appears a the waterfall model worked well spawning a host of
problem upon the development. voluminous methodologies, but it does not suit the
IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 5, No 3, September 2011
ISSN (Online): 1694-0814
www.IJCSI.org 396

problems of the complex, risky, and integrated • Avoid the deal with the risk in surprise and make
projects that IT has to deliver today. some bigger damage. Try to control every step in
IT developed stand-alone, batch applications. The waterfall model.
complexities of integrating applications were only
• Do not forget to sign a contract after confirm the
dreamed of by ambitious database architects. Today,
hardly any development is made in isolation unless, requirement with enduser. So that they will not
like the NHS IT project, you give yourself the luxury ask you to add more extra functions in the
of a scorched earth IT strategy. Because of its origins, software.
the waterfall method does not address integration but • Do remember that confirm there is not any
ignores it until the end of the project, when we mistakes and potential risks in one step. And then
encounter the familiar task of trying to stitch together
start your next step.
disparate applications and change schedules to the
annoyance of the operations manager. • The Project manager must take the most
Another change in the nature of IT projects is that important point of the project. Concentrate
most of today's projects have a high proportion of resources on this point.
reuse - implementing packages and reusing • Change the way of work from passive to active.
frameworks. The waterfall idea of creating a detailed
set of requirements and then trying to find a package
that fits is neither economic not practical. 3.2 V-Shaped (Modified Waterfall) model:-
Increasingly, organisations are seeing the benefits of 1) STRENGTH:-
solution-constrained development rather than • Emphasize planning for verification and
greenfield design. validation of the product in early stages of
The steps in waterfall model are fixed and the steps product development.
cannot change them. Model is self restricted. • Each deliverable must be testable.
If the model is not perfect, there must be some • Higher chances of success as test planning starts
potential risks. Just as some poor descriptions and early in the SDLC cycle.
requirement changing are principal sources of project • Project management can track progress by
risk. In waterfall model if there is a misunderstanding milestones.
in the analysis phase and that could not be found. The • Quickest for project where requirements are fixed
result could be destructive. This is almost the slowest and clearly defined.
step of development. • Easy to use
”The most difficult part is the communication between
humans.” (Yacov, 2002).
How to manage the risks in the Waterfall model? 2) WEAKNESS:-
• Does not easily handle concurrent events.
• It cannot be possible to avoid all the risks in the • Does not handle iterations or phases.
waterfall model because of the waterfall model • No early prototypes are available.
itself. But there are still some ways to settle the • Needs ample skilled resources.
problems. If team have experienced members in • Does not easily handle dynamic changes in
Requirements.
every job and cannot have any mistakes from the
• Does not contain risk analysis activities.
very beginning to the very end, then waterfall
model is successful .
3) OPPORTUNITIES:-
• The general method is getting prepared before the
• Excellent choice for systems requiring high
project really started. Have a essential Risk reliability.
Analysis in the pre-phase can avoid the failure of • All requirements are known up-front.
every steps and rework which rise up the cost of • When it can be modified to handle changing
the project. requirements beyond analysis phase.
• Making a Scheme of risk team can take a fast • Solution and technology are known.
react in case there are some risk happened.
4) THREATS:-
• The V-Shaped model is inappropriate for
complex projects.
IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 5, No 3, September 2011
ISSN (Online): 1694-0814
www.IJCSI.org 397

• The V-shaped model should have risk to used for • As the requirements clarification stage of a
large scale projects where requirements are waterfall model.
unclearly defined and unfixed. • Develop user interfaces.
• The V-Shaped model should be chosen when • Short-lived demonstrations.
• New, original development.
ample technical resources are available with
• With the analysis and design portions of object-
needed technical expertise. Since, no prototypes oriented development.
are produced, there is a very high risk involved in
meeting customer expectations, therefore, 4) THREATS:-
confidence of customer should be very high in • Prototyping often creates a situation where the
order for choosing the V-Shaped model customer mistakenly believes that the system is
approach. "finished" when in fact it is not. More
specifically, when using the Prototyping Model,
the pre-implementation versions of a system are
3.3 Evolutionary Prototype model:- really nothing more than one-dimensional
1) STRENGTH:- structures. The necessary, behind-the-scenes work
• Customers can “see” the system requirements as such as database normalization ,documentation,
they are being gathered. testing, and reviews for efficiency have not been
• Gains customer’s confidence as developers and done.
customers are in sync with each other’s • The primary goal of Prototyping is rapid
expectations continuously. development, the design of the system can
• Developers learn from customers. sometimes suffer because the system is built in a
• Ideal for online systems where high level of series of "layers" without a global consideration
human computer interaction is involved. of the integration of all other components. While
• A more accurate end product. initial software development is often built to be a
• Very flexible, as changes in requirements can be "throwaway, " attempting to retroactively produce
accommodated much more easily with every new a solid system design can sometimes be
review and refining. problematic.
• Unexpected requirements accommodated.
• Allows for flexible design and development. 3.4 Rapid Application model:-
• Steady, visible signs of progress produced. 1) STRENGTH:-
• Interaction with the prototype stimulates • Reduced cycle time and improved productivity
awareness of additional needed functionality. with fewer people means lower costs.
• Software built through prototyping needs minimal • Time-box approach mitigates cost and schedule
user training as users get trained using the risk.
prototypes on their own from the very beginning • Customer involved throughout the complete cycle
of the project. minimizes risk of not achieving customer
• Integration requirements are very well understood satisfaction and business needs.
and deployment channels are decided at a very • Focus moves from documentation to code
early stage. (WYSIWYG).
• Uses modeling concepts to capture information
2) WEAKNESS:- about business, data, and processes.
• Tendency to abandon structured program • Increases reusability of components.
development for “code-and-fix” development • High modularization achieves a more flexible
• Bad reputation for “quick-and-dirty” methods. and maintainable system.
• Overall maintainability may be overlooked • Quick initial reviews occur.
• The customer may want the prototype delivered. • Encourages customer feedback.
• Process may continue forever (scope creep). • Integration from very beginning solves a lot of
integration issues.
3) OPPORTUNITIES:- • Business owners actively participate
• Requirements are unstable or have to be clarified.
2) WEAKNESS:-
IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 5, No 3, September 2011
ISSN (Online): 1694-0814
www.IJCSI.org 398

• Accelerated development process must give quick

responses to the user. 2) WEAKNESS:-
• Risk of never achieving closure. • Requires good planning and design.
• Hard to use with legacy systems. • Requires early definition of a complete and fully
• Requires a system that can be modularized. functional system to allow for the definition of
• Developers and customers must be committed to increments.
rapid-fire activities in an abbreviated time frame. • Well-defined module interfaces are required
• Depends on strong team and individual (some will be developed long before others)
performances for identifying business • Total cost of the complete system is not lower.
requirements.
• Only system that can be modularized can be built
3) OPPORTUNITIES:-
using RAD.
• Requires highly skilled developers/designers. • Risk, funding, schedule, program complexity, or
need for early realization of benefits.
• High dependency on modeling skills.
• Most of the requirements are known up-front but
• Inapplicable to cheaper projects as cost of
are expected to evolve over time.
modeling and automated code generation is very
high for cheaper budgeted projects to befit. • A need to get basic functionality to the market
early.
• On projects which have lengthy development
3) OPPORTUNITIES: schedules.
• On a project with new technology.
• Reasonably well-known requirements.
• User involved throughout the life cycle.
• Project can be time-boxed.
3.6 Spiral model:-
• Functionality delivered in increments.
1) STRENGTH:-
• High performance not required.
• Low technical risks. • Provides early indication of insurmountable risks,
• System can be modularized. without much cost.
• Users see the system early because of rapid
prototyping tools.
4) THREATS:- • Critical high-risk functions are developed first.
• Rapid Application Development is an iterative • The design does not have to be perfect.
• Users can be closely tied to all lifecycle steps.
and incremental process, there are certain risks to
• Early and frequent feedback from users.
using RAD. It can lead to a succession of
• Cumulative costs assessed frequently.
prototypes that never results in a satisfactory end
product.
2) WEAKNESS:-
• The risks in RAD as opposed to "waterfall"
• Time spent for evaluating risks too large for small
development are related to the fact that RAD does or low-risk projects.
not rely on a single requirements analysis phase. • Time spent planning, resetting objectives, doing
risk analysis and prototyping may be excessive.
• The model is complex.
3.5 Incremental model:- • Risk assessment expertise is required.
1) STRENGTH:- • Spiral may continue indefinitely.
• Develop high-risk or major functions first. • Developers must be reassigned during non-
• Each release delivers an operational product. development phase activities.
• Customer can respond to each build. • May be hard to define objective, verifiable
• Uses “divide and conquer” breakdown of tasks. milestones that indicate readiness to proceed
• Lowers initial delivery cost. through the next iteration.
• Initial product delivery is faster.
• Customers get important functionality early. 3) OPPORTUNITIES:-
• Risk of changing requirements is reduced. • When creation of a prototype is appropriate.
• More flexible than waterfall. • When costs and risk evaluation is important.
IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 5, No 3, September 2011
ISSN (Online): 1694-0814
www.IJCSI.org 399

• For medium to high-risk projects. [7] Kal Toth, Intellitech Consulting Inc. and Simon Fraser
• Long-term project commitment unwise because of University, from lecture notes: Software Engineering Best
Practices, 1997.
potential changes to economic priorities.
[8] Frank Kand, “A Contingency Based Approach to
• Users are unsure of their needs. Requirements Elicitation and Systems Development,” London
• Requirements are complex. School of Economics, J. Systems Software 1998; 40: pp. 3-6.
• New product line. [9]Bryant, A. (2000), “Chinese Encyclopaedias and Balinese
• Significant changes are expected (research and Cockfights – Lessons for Business Process Change and
exploration). Knowledge Management,” In Knowledge Engineering and
Knowledge Management,
[10]Wang, Y. (2002a), “The Real-Time Process Algebra
4) THREATS:-
(RTPA),” Annals of Software Engineering 14.
• The risk of spiral model is the events that took
place that makes the project not to achieve clients Prof. Ashish B. Sasankar had done MCA,
M.Phil(Comp. Sci), M.Tech(CSE) and
requirement or what the users want. pursuing Phd in Software Engineering from
RTM, Nagpur University(INDIA). He is having
12 years of Experience in Education field. He
is currently working in GHRIIT, Nagpur(India).
He had published 15 international and
4. Conclusions national papers. He is member of IEEE and
CSI .
Selecting an SDLC model can be compared in many ways
to the specification of user requirements, the more data Dr. Vinay Chavan had Phd ,Msc in computer science. He is
gathered and examined, the higher the chances for working as Professor in Computer Science Dept, S.K.Porwal
College Nagpur (INDIA) .
successful completion of the project. Just as the
specifications of user requirements are vital in the stages of
design and computer system development, so can the
knowledge and regulations which constitute the basis for
SDLC model selection determine the success or failure of a
given project.
A SWOT analysis is a tool to assess and to develop
strategies to remain competitive. To sum up, selecting an
appropriate SDLC model is a complex and a challenging
task, which requires not only broad theoretical knowledge,
but also consultation with experienced expert managers.

References
[1] Kal Toth, Intellitech Consulting Inc. and Simon Fraser
University; list is partially created from Software Engineering
Best Practices,1997.
[2] Information on the Software Engineering Institute can be
found at http://www.sei.cmu.edu.
[3] Mark C. Paulk, Charles V. Weber, Suzanne M. Garcia, Mary
Beth Chrissis, and Marilyn W. Bush, "Key Practices of the
Capability Maturity Model, Version 1.1," Software Engineering
Institute, February 1993, p 1.
[4] Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, and Charles
V. Weber, "Capability Maturity Model for Software, Version
1.1," Software Engineering Institute, February 1993, p 18.
[5] Kal Toth, Intellitech Consulting Inc. and Simon Fraser
University, from lecture notes: Software Engineering Best
Practices, 1997.
[6] Linda Spence, University of Sutherland, “Software
Engineering,” available at
http://osiris.sunderland.ac.uk/rif/linda_spence/HTML/contents.ht
ml