UNIVERSITY INSTITUTE OF TECHNOLOGY

RAJIV GANDHI PROUDYOGIKI VISHWAVIDYALAYA

BHOPAL (M. P.)

Submitted as Minor Training Report in Partial fulfillment for the award of Graduate Degree in
Bachelor of Engineering in Information Technology.

Submitted to: Submitted By:

Mrs. Asmita Moghe Ankit Saxena
IT Semester VII
(0101IT061004)
 DEPARTMENT OF INFORMATION TECHNOLGY

UNIVERSITY INSTITUTE OF TECHNOLOGY

RAJIV GANDHI PROUDYOGIKI VISHWAVIDYALAYA

BHOPAL (M.P)

June – 2009

CERTIFICATE
This is to certify that the Training Report being submitted by Ankit Saxena, student of the
Seventh Semester, Degree in Information Technology has done his work as MINOR TRAINING
REPORT for the Partial fulfillment of the degree from RGPV, Bhopal (M.P.) is a record of
bonafide work done by him under our supervision.

Prof. Asmita Moghe Prof. Roopam Gupta

Reader Head

Information Technology Information Technology

UIT RGPV Bhopal UIT RGPV Bhopal

2|Page
 ACKNOWLEDGEMENT

I take the opportunity to express my cordial gratitude and deep sense of indebtedness
to my guide Mr Tilak Raj Kapoor for the valuable guidance and inspiration throughout the
project duration. I feel Thankful to him for his innovative ideas, which led to successful
completion of this training. I feel proud and fortunate to work under such an outstanding
mentor in the field of Software Development Life Cycle. He has always welcomed my problem
and helped me to clear my doubt. I will always be grateful to him for providing me moral
support and sufficient time.

I owe sincere thanks to The HOD, Department of Information Technology, Prof. Roopam
Gupta Madam, who gave us this opportunity to go out and explore the real industrial
experience.

At the same time, I would like to thank Prof. Asmita Moghe Madam and all other faculty
members and all non-teaching staff in Information Technology Department for their valuable
co-operation.

Ankit Saxena

IT, Sem VII

UIT RGPV Bhopal

3|Page
 Table of Contents

Sr. Contents Page

1. Software Development Life Cycle 5

2. Software Development Methodology 8

2.1 Waterfall Model 9

2.2 Prototyping 11

2.3 Spiral Model 16

2.4 Rapid Application Development 18

3. Agile Software Development 19

4. Feature Driven Development 21

5. Scrum 23

6. Extreme Programming 24

7. Adaptive Software Development 25

8. Rational Unified Process 25

9. Dynamic System Development Method 26

10 References 29
.

1. Software Development Life Cycle

4|Page
The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems
engineering and software engineering, is the process of creating or altering systems, and the
models and methodologies that people use to develop these systems.

System Development Life Cycle (SDLC) is any logical process used by a systems analyst to
develop an information system, including requirements, validation, training, and user
ownership. Any SDLC should result in a high quality system that meets or exceeds customer
expectations, reaches completion within time and cost estimates, works effectively and
efficiently in the current and planned Information Technology infrastructure, and is inexpensive
to maintain and cost-effective to enhance.

Computer systems have become more complex and often (especially with the advent
of Service-Oriented Architecture) link multiple traditional systems potentially supplied by
different software vendors. SDLC models can be described along a spectrum of agile to iterative
to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight processes
which allow for rapid changes along the development cycle. Some agile and iterative
proponents confuse the term SDLC with sequential or "more traditional" processes; however,
SDLC is an umbrella term for all methodologies for the design, implementation, and release of
software. Systems Development Life Cycle (SDLC) adheres to important phases that are
essential for developers, such as planning, analysis, design, and implementation.

5|Page
Some argue that the SDLC no longer applies to models like Agile computing, but it is still a term
widely in use in Technology circles. The SDLC practice has advantages in traditional models of
software development that lends itself more to a structured environment. The disadvantages to
using the SDLC methodology is when there is need for iterative development or (i.e. web
development or e-commerce) where stakeholders need to review on a regular basis the
software being designed. Instead of viewing SDLC from a strength or weakness perspective, it is
far more important to take the best practices from the SDLC model and apply it to whatever
may be most appropriate for the software being designed.

6|Page
Strength and Weaknesses of SDLC

Strengths Weaknesses
1. Control. 1. Increased development time.
2. Monitor Large projects. 2. Increased development cost.
3. Detailed steps. 3. Systems must be defined up front.
4. Evaluate costs and completion targets. 4. Rigidity.
5. Hard to estimate costs, project
5. Documentation.
overruns.
6. Well defined user input. 6. User input is sometimes limited.
7. Ease of maintenance.
8. Development and design standards.
9. Tolerates changes in MIS staffing.

7|Page
 2. Software Development Methodology

A software development methodology refers to the framework that is used to structure, plan,

and control the process of developing an information system. A wide variety of such
frameworks have evolved over the years, each with its own recognized strengths and
weaknesses. One system development methodology is not necessarily suitable for use by all
projects. Each of the available methodologies is best suited to specific kinds of projects, based
on various technical, organizational, project and team considerations. [1]

The framework of a software development methodology consists of:

 A software development philosophy, with the approach or approaches of the software

development process
 Multiple tools, models and methods, to assist in the software development process.
These frameworks are often bound to some kind of organization, which further develops,
supports the use, and promotes the methodology. The methodology is often documented in
some kind of formal documentation.

Every software development methodology has more or less its own approach to software
development. There is a set of more general approaches, which are developed into several
specific methodologies. These approaches are:

1. Waterfall: linear framework type.

2. Prototyping: iterative framework type
3. Spiral: combination linear and iterative framework type
4. Rapid Application Development (RAD): Iterative Framework Type

8|Page
 2.1 Waterfall model

Overview

The waterfall model is a sequential software development process, in which progress is seen as

flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation,
Analysis, Design (validation), Construction, Testing and maintenance. The waterfall
development model has its origins in the manufacturing and construction industries; highly
structured physical environments in which after-the-fact changes are prohibitively costly, if not
impossible. Since no formal software development methodologies existed at the time, this
hardware-oriented model was simply adapted for software development.

The first formal description of the waterfall model is often cited to be an article published in
1970 by Winston W. Royce (1929–1995), although Royce did not use the term "waterfall" in this
article. Royce was presenting this model as an example of a flawed, non-working model (Royce
1970). This is in fact the way the term has generally been used in writing about software
development—as a way to criticize a commonly used software practice.

In Royce's original Waterfall model, the following phases are followed in order:

1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA Validation)
6. Installation
7. Maintenance

To follow the waterfall model, one proceeds from one phase to the next in a purely sequential
manner. For example, one first completes requirements specification, which is set in stone.
When the requirements are fully completed, one proceeds to design. The software in question
is designed and a blueprint is drawn for implementers (coders) to follow — this design should
be a plan for implementing the requirements given. When the design is fully completed, an
implementation of that design is made by coders. Towards the later stages of this
implementation phase, separate software components produced are combined to introduce
new functionality and reduced risk through the removal of errors.

Thus the waterfall model maintains that one should move to a phase only when its preceding
phase is completed and perfected. However, there are various modified waterfall

9|Page
models (including Royce's final model) that may include slight or major variations upon this
process.

Figure 1: Waterfall Model

Criticism

The waterfall model is argued by many to be a bad idea in practice. This is mainly because of
their belief that it is impossible for any non-trivial project to get one phase of a software
product's lifecycle perfected, before moving on to the next phases and learning from them.
Designers may not be aware of future implementation difficulties when writing a design for an
unimplemented software product. That is, it may become clear in the implementation phase
that a particular area of program functionality is extraordinarily difficult to implement. If this is
the case, it is better to revise the design than to persist in using a design that was made based
on faulty predictions and that does not account for the newly discovered problem areas. Even
without such changing of the specification during implementation, there are the possibilities of
either to start a new SW project from a scratch, "on a green field", or to continue some already
existing, "a brown field" (from construction again). The waterfall methodology can be used for

10 | P a g e
continuous enhancement, even for existing SW, originally from another team. As well as in the
case when the system's analyst fails to capture the customer requirements correctly, the
resulting impacts on the following phases (mainly the coding) still can be tamed by this
methodology, in practice: A challenging job for a QA team. The idea behind the waterfall model
may be "measure twice; cut once", and those opposed to the waterfall model argue that this
idea tends to fall apart when the problem being measured is constantly changing due to
requirement modifications and new realizations about the problem itself. As a solution can
serve some "investment of man-time", ordering some experienced developer to spend time
on refactoring, to consolidate the SW back together. Another approach is to prevent these
needs by a predicting design, targeting modularity with interfaces.

11 | P a g e
 2.2 Prototyping

Software prototyping, an activity during certain software development, is the creation

of prototypes, i.e., incomplete versions of the software program being developed.

A prototype typically simulates only a few aspects of the features of the eventual program, and

may be completely different from the eventual implementation.

The conventional purpose of a prototype is to allow users of the software to evaluate

developers' proposals for the design of the eventual product by actually trying them out, rather
than having to interpret and evaluate the design based on descriptions. Prototyping can also be
used by end users to describe and prove requirements that developers have not considered, so
“controlling can be a key factor in the commercial relationship between solution providers and
their clients.

Prototyping has several benefits: The software designer and implementer can obtain feedback
from the users early in the project. The client and the contractor can compare if the software
made matches the software specification, according to which the software program is built. It
also allows the software engineer some insight into the accuracy of initial project estimates and
whether the deadlines and milestones proposed can be successfully met. The degree of
completeness and the techniques used in the prototyping have been in development and
debate since its proposal in the early 1970s.[6]

This process is in contrast with the 1960s and 1970s monolithic development cycle of building
the entire program first and then working out any inconsistencies between design and
implementation, which led to higher software costs and poor estimates of time and cost. The
monolithic approach has been dubbed the "Slaying the (software) Dragon" technique, since it
assumes that the software designer and developer is a single hero who has to slay the entire
dragon alone. Prototyping can also avoid the great expense and difficulty of changing a finished
software product.

The process of prototyping involves the following steps

 Identify basic requirements

Determine basic requirements including the input and output information desired.
Details, such as security, can typically be ignored.
 Develop Initial Prototype

The initial prototype is developed that includes only user interfaces.

12 | P a g e
  Review

The customers, including end-users, examine the prototype and provide feedback on
additions or changes.
 Revise and Enhance the Prototype

Using the feedback both the specifications and the prototype can be improved.
Negotiation about what is within the scope of the contract/product may be necessary. If
changes are introduced then a repeat of steps #3 ands #4 may be needed.
Software prototyping has many variants. However, all the methods are in some way based on
two major Types of prototyping: Throwaway Prototyping and Evolutionary Prototyping.

Figure 2: Prototyping Model

13 | P a g e
Advantages of Prototyping

There are many advantages to using prototyping in software development – some tangible,
some abstract.

 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. 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 final product that has greater tangible and intangible quality.
The final product is more likely to satisfy the users desire for look, feel and performance.

Disadvantages of Prototyping

Using, or perhaps misusing, prototyping can also have disadvantages.

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

14 | P a g e
  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 solution provider 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.
 Developer attachment to prototype: Developers can also become attached to
prototypes they have spent a great deal of effort producing; this can lead to problems
like attempting to convert a limited prototype into a final system when it does not have
an appropriate underlying architecture. (This may suggest that throwaway prototyping,
rather than evolutionary prototyping, should be used.)
 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.
 Expense of implementing prototyping: the start up costs for building a development
team focused on prototyping may be high. Many companies have development
methodologies in place, and changing them can mean retraining, retooling, or both.
Many companies tend to just jump into the prototyping without bothering to retrain
their workers as much as they should.
 A common problem with adopting prototyping technology is high expectations for
productivity with insufficient effort behind the learning curve. In addition to training for
the use of a prototyping technique, there is an often overlooked need for developing
corporate and project specific underlying structure to support the technology. When
this underlying structure is omitted, lower productivity can often result .

15 | P a g e
 2.3 Spiral Model

The spiral model is a software development process combining elements of

both design and prototyping-in-stages, in an effort to combine advantages of top-down and
bottom-up concepts. Also known as the spiral lifecycle model (or spiral development), it is a
systems development method (SDM) used in information technology (IT). This model of
development combines the features of the prototyping model and the waterfall model. The
spiral model is intended for large, expensive and complicated projects.

The steps in the spiral model iteration can be generalized as follows:

1. The new system requirements are defined in as much detail as possible. This usually

involves interviewing a number of users representing all the external or internal users
and other aspects of the existing system.
2. A preliminary design is created for the new system. This phase is the most important
part of "Spiral Model". In this phase all possible (and available) alternatives, which can
help in developing a cost effective project are analyzed and strategies are decided to
use them. This phase has been added specially in order to identify and resolve all the
possible risks in the project development. If risks indicate any kind of uncertainty in
requirements, prototyping may be used to proceed with the available data and find out
possible solution in order to deal with the potential changes in the requirements.
3. A first prototype of the new system is constructed from the preliminary design. This is
usually a scaled-down system, and represents an approximation of the characteristics of
the final product.
4. A second prototype is evolved by a fourfold procedure:

a) evaluating the first prototype in terms of its strengths, weaknesses, and risks;
b) defining the requirements of the second prototype;
c) planning and designing the second prototype;
d) Constructing and testing the second prototype.

16 | P a g e
 Figure 3: Spiral Model

17 | P a g e
 2.4 Rapid Application Development

Rapid Application Development (RAD) refers to a type of software development

methodology that uses minimal planning in favor of rapid prototyping. The "planning" of
software developed using RAD is interleaved with writing the software itself. The lack of
extensive pre-planning generally allows software to be written much faster, and makes it easier
to change requirements. The shift from traditional session-based client/server development to
open session less and collaborative development like Web 2.0 has increased the need for faster
iterations through the phases of the SDLC. This, coupled with the growing utilization of open
source frameworks and products in core commercial development, has, for many developers,
rekindled interest in finding a silver bullet RAD methodology.

Although most RAD methodologies foster software re-use, small team structure and distributed
system development, most RAD practitioners recognize that, ultimately, there is no single
“rapid” methodology that can provide an order of magnitude improvement over any other
development methodology.

All flavors of RAD have the potential for providing a good framework for faster product
development with improved code quality, but successful implementation and benefits often
hinge on project type, schedule, software release cycle and corporate culture. It may also be of
interest that some of the largest software vendors such as Microsoft and IBM] do not
extensively utilize RAD in the development of their flagship products and for the most part,
they still primarily rely on traditional waterfall methodologies with some degree of spiraling.

18 | P a g e
 3. Agile Software Development

Agile software development refers to a group of software development methodologies based

on iterative development, where requirements and solutions evolve through collaboration
between self-organizing cross-functional teams. The term was coined in the year 2001 when
the Agile Manifesto was formulated.

Agile methods generally promote a disciplined project management process that encourages
frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-
organization and accountability, a set of engineering best practices that allow for rapid delivery
of high-quality software, and a business approach that aligns development with customer
needs and company goals. Conceptual foundations of this framework are found in modern
approaches to operations management and analysis, such as lean manufacturing, soft systems
methodology, speech act theory (network of conversations approach), and Six Sigma.

Agile methods are a family of development processes, not a single approach to software
development. The Agile Manifesto states:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Some of the principles behind the Agile Manifesto are:

 Customer satisfaction by rapid, continuous delivery of useful software

 Working software is delivered frequently (weeks rather than months)
 Working software is the principal measure of progress
 Even late changes in requirements are welcomed
 Close, daily cooperation between business people and developers
 Face-to-face conversation is the best form of communication (co-location)
 Projects are built around motivated individuals, who should be trusted
 Continuous attention to technical excellence and good design

19 | P a g e
 Simplicity
 Self-organizing teams
 Regular adaptation to changing circumstances
The manifesto spawned a movement in the software industry known as agile software
development.

The functioning principles of Agile can be found in lean manufacturing and six sigma. These
concepts include error proofing, eliminating waste, creating flow, adding customer value, and
empowering workers. The concepts were first formally espoused in the 14 principles of
the Toyota Way, the two pillars of the Toyota Production System (Just-in-time and smart
automation), the 5S methodology, and Deming’s 14 points. These have been summarized in the
seven points of lean software development.

Figure 4: Agile SDLC Phases

20 | P a g e
 4. Feature Driven Development

Feature Driven Development (FDD) is an iterative and incremental software development

process. It is one of a number of Agile methods for developing software and forms part of
the Agile Alliance. FDD blends a number of industry-recognized best practices into a cohesive
whole. These practices are all driven from a client-valued functionality (feature) perspective. Its
main purpose is to deliver tangible, working software repeatedly in a timely manner.

FDD is a model-driven short-iteration process that consists of five basic activities. For accurate
state reporting and keeping track of the software development project, milestones that mark
the progress made on each feature are defined. This section gives a high level overview of the
activities.

 Develop Overall Model

The project starts with a high-level walkthrough of the scope of the system and its context.
Next, detailed domain walkthroughs are held for each modeling area. In support of each
domain, walkthrough models are then composed by small groups which are presented for peer
review and discussion. One of the proposed models or a merge of them is selected which
becomes the model for that particular domain area. Domain area models are merged into an
overall model, the overall model shape being adjusted along the way.
 Build Feature List
The knowledge that is gathered during the initial modeling is used to identify a list of features.
This is done by functionally decomposing the domain into subject areas. Subject areas each
contain business activities, the steps within each business activity form the categorized feature
list. Features in this respect are small pieces of client-valued functions expressed in the form
<action> <result> <object>, for example: ´Calculate the total of a sale´ or ´Validate the password
of a user´. Features should not take more than two weeks to complete, else they should be
broken down into smaller pieces.
 Plan By Feature
Now that the feature list is complete, the next step is to produce the development plan. Class
ownership is done by ordering and assigning features (or feature sets) as classes to
chief programmers.

21 | P a g e
  Design By Feature
A design package is produced for each feature. A chief programmer selects a small group of
features that are to be developed within two weeks. Together with the corresponding class
owners, the chief programmer works out detailed sequence diagrams for each feature and
refines the overall model. Next, the class and method prologues are written and finally a design
inspection is held.
 Build By Feature
After a successful design inspection a per feature activity to produce a completed client-valued
function (feature) is being produced. The class owners develop the actual code for their classes.
After a unit test and a successful code inspection, the completed feature is promoted to the
main build.
 Milestones
Since features are small, completing a feature is a relatively small task. For accurate state
reporting and keeping track of the software development project it is however important to
mark the progress made on each feature. FDD therefore defines six milestones per feature that
are to be completed sequentially. The first three milestones are completed during the Design
By Feature activity, the last three are completed during the Build By Feature activity. To help
with tracking progress, a percentage complete is assigned to each milestone. In the table below
the milestones (and their completion percentage) are shown. A feature that is still being coded
is 44% complete (Domain Walkthrough 1%, Design 40% and Design Inspection 3% = 44%).

5. Scrum

22 | P a g e
Scrum is an iterative incremental framework for managing complex work (such as new product
development) commonly used with agile software development. Although the word is not an
acronym, some companies implementing the process have been known to spell it with capital
letters as SCRUM. This may be due to one of Ken Schwaber's early papers, which capitalized
SCRUM in the title.

Although Scrum was intended for management of software development projects, it can be
used to run software maintenance teams, or as a general project/program management
approach.

Scrum is a "process skeleton," which contains sets of practices and predefined roles. The main
roles in Scrum are:

1. the "ScrumMaster", who maintains the processes (typically in lieu of a project

manager);
2. the "Product Owner", who represents the stakeholders;
3. the "Team", a cross-functional group of about 7 people who do the actual analysis,
design, implementation, testing, etc.
During each "sprint", typically a two to four week period (with the length being decided by the
team), the team creates a potentially shippable product increment (for example, working and
tested software). The set of features that go into a sprint come from the product "backlog,"
which is a prioritized set of high level requirements of work to be done. Which backlog items go
into the sprint is determined during the sprint planning meeting. During this meeting, the
Product Owner informs the team of the items in the product backlog that he or she wants
completed. The team then determines how much of this they can commit to complete during
the next sprint. During a sprint, no one is allowed to change the sprint backlog, which means
that the requirements are frozen for that sprint. After a sprint is completed, the team
demonstrates the use of the software.

Scrum enables the creation of self-organizing teams by encouraging co-location of all team
members, and verbal communication across all team members and disciplines that are involved
in the project.

A key principle of Scrum is its recognition that during a project the customers can change their
minds about what they want and need (often called requirements churn), and that unpredicted
challenges cannot be easily addressed in a traditional predictive or planned manner. As such,
Scrum adopts an empirical approach—accepting that the problem cannot be fully understood

23 | P a g e
or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to
emerging requirements.

There are several implementations of systems for managing the Scrum process, which range
from yellow stickers and whiteboards, to software packages. One of Scrum's biggest advantages
is that it is very easy to learn and requires little effort to start using.

6. Extreme Programming (XP) 

Extreme Programming (XP) is a software development methodology which is intended to

improve software quality and responsiveness to changing customer requirements. As a type
of agile software development, it advocates frequent "releases" in short development cycles
(timeboxing), which is intended to improve productivity and introduce checkpoints where new
customer requirements can be adopted.

Other elements of Extreme Programming include: programming in pairs or doing

extensive code review, unit testing of all code, avoiding programming of features until they are
actually needed, a flat management structure, simplicity and clarity in code, expecting changes
in the customer's requirements as time passes and the problem is better understood, and
frequent communication with the customer and among programmers. The methodology takes
its name from the idea that the beneficial elements of traditional software engineering
practices are taken to "extreme" levels, on the theory that if some is good, more is better. It is
unrelated to "cowboy coding", which is more free-form and unplanned. It does not advocate
"death march" work schedules, but instead working at a sustainable pace.

Critics have noted several potential drawbacks, including problems with unstable requirements,
no documented compromises of user conflicts, and lack of an overall design spec or document.

7. Adaptive Software Development

24 | P a g e
Adaptive Software Development is a software development process that grew out of rapid
application development work by Jim Highsmith and Sam Bayer. ASD embodies the principle
that continuous adaptation of the process to the work at hand is the normal state of affairs.

ASD replaces the traditional waterfall cycle with a repeating series of speculate, collaborate,

and learn cycles. This dynamic cycle provides for continuous learning and adaptation to the
emergent state of the project. The characteristics of an ASD life cycle are that it is mission
focused, feature based, iterative, time boxed, risk driven, and change tolerant.

The word “speculate” refers to the paradox of planning – it is more likely to assume that all
stakeholders are comparably wrong for certain aspects of the project’s mission, while trying to
define it. Collaboration refers to the efforts for balancing the work based on predictable parts
of the environment (planning and guiding them) and adapting to the uncertain surrounding mix
of changes caused by various factors – technology, requirements, stakeholders, software
vendors, etc. The learning cycles, challenging all stakeholders, are based on the short iterations
with design, build and testing. During these iterations the knowledge is gathered by making
small mistakes based on false assumptions and correcting those mistakes, thus leading to
greater experience and eventually mastery in the problem domain. 

8. Rational Unified Process (RUP)

The Rational Unified Process (RUP) is an iterative software development process framework

created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single
concrete prescriptive process, but rather an adaptable process framework, intended to be
tailored by the development organizations and software project teams that will select the
elements of the process that are appropriate for their needs.

9. Dynamic Systems Development Method (DSDM)

25 | P a g e
Dynamic Systems Development Method (DSDM) is a software development
methodology originally based upon the Rapid Application Development methodology. DSDM is
an iterative and incremental approach that emphasizes continuous user involvement.

Its goal is to deliver software systems on time and on budget while adjusting for changing
requirements along the development process. DSDM is one of a number of Agile methods for
developing software, and it forms a part of the Agile Alliance.

As an extension of rapid application development, DSDM focuses on Information

Systems projects that are characterized by tight schedules and budgets. DSDM addresses the
most common failures of information systems projects, including exceeding budgets, missing
deadlines, and lack of user involvement and top-management commitment. By encouraging the
use of RAD, however, careless adoption of DSDM may increase the risk of cutting too many
corners. DSDM consists of

 Three phases: pre-project phase, project life-cycle phase, and post-project phase.

 A project life-cycle phase subdivided into 5 stages: feasibility study, business
study, functional model iteration, design and build iteration, and implementation.
In some circumstances, there are possibilities to integrate practices from other methodologies,
such as Rational Unified Process (RUP), Extreme Programming (XP), and PRINCE2, as
complements to DSDM. Another agile method that has some similarity in process and concept
to DSDM is Scrum.

DSDM was developed in the United Kingdom in the 1990s by the DSDM Consortium, an
association of vendors and experts in the field of software engineering created with the
objective of "jointly developing and promoting an independent RAD framework" by combining
their best practice experiences. The DSDM Consortium is a not-for-profit, vendor-independent
organization which owns and administers the DSDM framework. The first version was
completed in January 1995 and was published in February 1995. The current version in use (as
of April 2006) is Version 4.2: Framework for Business Centered Development, and was released
in May 2003. In July 2006, DSDM Public Version 4.2 [1] was made available for individuals to view
and use; however, anyone reselling DSDM must still be a member of the not-for-profit
consortium.

26 | P a g e
 Figure 5: DSDM Development Process

Principles
There are 9 underlying principles consisting of four foundations and five starting-points.

 User involvement is the main key in running an efficient and effective project, where
both users and developers share a workplace, so that the decisions can be made accurately.
 The project team must be empowered to make decisions that are important to the
progress of the project without waiting for higher-level approval.
 A focus on frequent delivery of products, with assumption that to deliver something
"good enough" earlier is always better than to deliver everything "perfectly" in the end. By
delivering product frequently from an early stage of the project, the product can be tested
and reviewed where the test record and review document can be taken into account at the
next iteration or phase.
 The main criteria for acceptance of a "deliverable" is delivering a system that addresses
the current business needs. Delivering a perfect system which addresses all possible
business needs is less important than focusing on critical functionalities.
 Development is iterative and incremental and driven by users’ feedback to converge on
an effective business solution.
 All changes during the development are reversible.
 The high level scope and requirements should be base-lined before the project starts.

27 | P a g e
 Testing is carried out throughout the project life-cycle.
 Communication and cooperation among all project stakeholders is required to be
efficient and effective.

10. References

28 | P a g e
  Software Engineering, Version 6

Roger Pressman, TMH Publishers

  An Integrated Approach to Software Engineering

Pankaj Jalote

 http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
Online Encyclopedia

29 | P a g e