TABLE OF CONTENT
Rapid Application development (RAD) Processes ............................................................................................... 2
Various RAD (Rapid Application Development) Methodologies ........................................................................ 5
1.
Agile Software Development ........................................................................................................................ 5
2.
Joint Application Development (JAD) ......................................................................................................... 9
3.
EXTREME PROGRAMMING (XP) ......................................................................................................... 13
4.
Scrum Development Process ...................................................................................................................... 20
5.
Lean software development (LD) ............................................................................................................... 24
References ........................................................................................................................................................... 28
1
Rapid Application development (RAD) Processes
Today, business moves faster, and clients tend to change their minds more frequently over the course of a project’s
development life cycle. Of course, they expect the development team to adapt to their needs and modify the
structure of an application quickly. Fortunately, the use of scripting languages like Perl and PHP makes it easy to
apply other programming strategies, such as rapid application development (RAD).Rapid Application Development
process deals with Software engineering/management field. It refers to the type of Software development process
which minimizes the pre planning phase, and results in more rapid software development lifecycle. RAD is a
methodology for compressing the analysis, design, build, and test phases into a series of short, iterative development
cycles. The idea behind this methodology is to start developing as early as possible so that clients can review a
working prototype and offer additional direction. The application then gets built in an iterative process, releasing
rich versions in short development cycles.
RAD calls for the interactive use of structured techniques and
prototyping to define user's requirements and design the final system. Using structured techniques, the developer
first builds preliminary data models and business process models of the business requirements. Prototyping then
helps the analyst and users to verify those requirements and to formally refine the data and process models. This
results in a combined business requirements and technical design statement to be used for constructing new systems.
Figure1. Showing two different development process
Problem with Traditional style (Structure System Design and Analysis style)
RAD has a number of distinct advantages over the traditional sequential development model Figure1.
Some of the difficulties faced by the team member using traditional style of development are
 Applications took so long to build that requirements got changed before the system was
complete. Resulting in inadequate or even unusable systems.
 Another problem was the assumption that a methodical requirements analysis phase alone would
identify all the critical requirements, which is not very true.
 The cause of the problem was identified in the strict adherence to completion of one lifecycle
stage before moving on to the next lifecycle stage. Specifically, building an application based on
requirements that have been frozen at a point in time means that the longer development takes,
the more likely that business needs will change and invalidate the requirements that the system
being developed is based upon.
2
Factors for Rapid Development
Fast development does not mean a "quick and dirty" process. There should be no compromise between
speed of development and quality. Several factors contribute to the success of rapid development by
improving both the quality of the delivered system and the speed of delivery. Factors important for rapid
development include:
* Intensive involvement of the end user in the design of the system.
* Use of prototyping, which helps users visualize and make adjustments to the system.
* Use of an integrated CASE toolset to enforce technical integrity in modeling and designing the system.
* Use of a CASE repository to facilitate the re-use of proven templates, components and systems.
* Use of an integrated CASE toolset to generate bug-free code from a fully validated design.
* User involvement in the Construction stage, allowing the details to be adjusted if necessary.
* Development of a task structure that encourages parallel project activities.
Various Stages of RAD
Requirements Planning
The Requirements Planning stage consists of a review of the areas immediately associated with the
proposed system. This review produces a broad definition of the system requirements in terms of the
functions the system will support. The deliverables from the Requirements Planning stage include an
outline system area model (entity and process models) of the area under study, a definition of the system's
scope, and a cost justification for the new system.
User Design
The User Design stage consists of a detailed analysis of the business activities related to the proposed
system. Key users, meeting in workshops, decompose business functions and define entity types
associated with the system. They complete the analysis by creating action diagrams defining the
interactions between processes and data. Following the analysis, the design of the system is outlined.
System procedures are designed, and preliminary layouts of screens are developed. Prototypes of critical
procedures are built and reviewed. A plan for implementing the system is prepared.
Construction
In the Construction stage, a small team of developers, working directly with users, finalizes the design
and builds the system. The software construction process consists of a series of "design-and-build" steps
in which the users have the opportunity to fine-tune the requirements and review the resulting software
implementation. This stage also includes preparing for the cutover to production.
In addition to the tested software, Construction stage deliverables include documentation and instructions
necessary to operate the new application, and routines and procedures needed to put the system into
operation.
Implementation
The implementation stage involves implementing the new system and managing the change from the old
system environment to the new one. This may include implementing bridges between existing and new
systems, converting data, and training users. User acceptance is the end point of the implementation stage.
3
Core Elements of Rapid Application Development
RAD has many core elements that make it a unique methodology including prototyping, iterative
development, time boxing, team members, management approach, and RAD tools.
Prototyping
A key aspect of RAD is the construction of a prototype for the purpose of jumpstarting design and
flushing out user requirements. The objective is to build a feature light version of the finished product in
as short an amount of time as possible, preferably days. The initial prototype serves as a proof of concept
for the client, but more importantly serves as a talking point and tool for refining requirements.
Developing prototypes quickly is accomplished with Computer Aided Software Engineering CASE tools
that focus on capturing requirements, converting them to a data model, converting the data model to a
database, and generating code all in one tool
Iterative Development
Iterative development means creating increasingly functional versions of a system in short development
cycles. Each version is reviewed with the client to produce requirements that feed the next version. The
process is repeated until all functionality has been developed. The ideal length of iterations is between
one day (which is closer to Agile Methodologies) and three weeks. Each development cycle provides the
user an opportunity to provide feedback, refine requirements, and view progress (in focus group session
meetings). It is ultimately the iterative development that solves the problems inherent in the inflexible
methodologies created in the 1970's.
Time Boxing
Time boxing is the process of putting off features to future application versions in order to complete the
current version in as short amount of time as possible. Strict time boxing is an important aspect of RAD,
because without it scope creep can threaten to lengthen development iterations, thus limiting client
feedback, minimizing the benefits of iterative development, and potentially reverting the process back to a
waterfall methodology approach.
Team Members
The RAD methodology recommends the use of small teams that consist of experienced, versatile, and
motivated members that are able to perform multiple roles. As the client plays a vital role in the
development process, dedicated client resources must be available during the initial Joint Application
Development (JAD) sessions as well as Focus Group Sessions conducted at the end of development
cycles. Development teams should ideally have experience in Rapid Application Development and should
have experience with the Computer Aided Software Engineering tools.
Management Approach
Active and involved management is vital to mitigate the risks of lengthened development cycles, client
misunderstandings, and missed deadlines. Above all management must be stalwart and consistent in their
desire to use the Rapid Application Development methodology. In addition to enforcing a strict timeline,
management must focus on team member selection, team motivation, and on clearing bureaucratic or
political obstacles.
RAD Tools
One of the primary objectives of the Rapid Application Development methodology developed by James
Martin in the late 1980's was to take advantage of the latest technology available to speed development.
Clearly the technology of the 1980's is obsolete today, but RAD's focus of the latest tools is as important
4
today as it was when the methodology was initially created. This article has a section dedicated to tools
following the process section.
Advantages
Increased Speed, As the name suggests, Rapid Application Development's primary advantage lies in an application's
increased development speed and decreased time to delivery. The goal of delivering applications quickly is
addressed through the use of Computer Aided Software Engineering or CASE tools, which focus on converting
requirements to code as quickly as possible, as well as Time Boxing, in which features are pushed out to future
releases in order to complete a feature light version quickly.
Increased Quality, Increased quality is a primary focus of the Rapid Application Development methodology, but the
term has a different meaning than is traditionally associated with Custom Application Development. Prior to RAD,
and perhaps more intuitively, quality in development was both the degree to which an application conforms to
specifications and a lack of defects once the application is delivered. According to RAD, quality is defined as both
the degree to which a delivered application meets the needs of users as well as the degree to which a delivered
system has low maintenance costs. Rapid Application Development attempts to deliver on quality through the heavy
involving of users in the analysis and particularly the design stages.
Disadvantages
Reduced Scalability, Because RAD focuses on development of a prototype that is iteratively developed into a full
system, the delivered solution may lack the scalability of a solution that was designed as a full application from the
start.
Reduced Feature, Due to time boxing, where features are pushed off to later versions in favor of delivering an
application in a short time frame, RAD may produce applications that are less full featured than traditionally
developed applications. This concern should be addressed as soon as possible through clear communication with the
client as to what will be delivered and when.
Various RAD (Rapid Application Development) Methodologies
Different types of RAD development methodologies and utilize a selected method for a small project life cycle.
1. Agile Software Development
Agile software development methods attempt to offer once again an answer to the eager business
community asking for lighter weight along with faster and nimbler software development processes. This
is especially the case with the rapidly growing and volatile Interact software industry as well as with the
emerging mobile application environment application. 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.
Agile methods break tasks into small increments with minimal planning, and do not directly involve longterm planning. Iterations are short time frames ("time boxes") that typically last from one to four weeks.
All iterations involves a team working through a full software development cycle including planning,
requirements analysis, design, coding, unit testing, and acceptance testing when a working product is
demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes
quickly. Stakeholders produce documentation as required. Iteration may not add enough functionality to
warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of
iteration. An agile software project intends to be capable of releasing new software at the end of iteration.
5
At the end of iteration, the team reevaluates project priorities. Multiple iterations may be required to
release a product or new features. Team composition in an agile project is usually cross functional and
self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team
members. Team members normally take responsibility for tasks that deliver the functionality iteration
requires. Agile methods emphasize real-time communication, preferably face-to-face, over written
documents. Most agile teams are located in a bullpen and include all the people necessary to finish the
software. At a minimum, this includes programmers and the people who define the product such as
product managers, business analysts, or actual customers. The bullpen may also include testers, interface
designers, technical writers, and management. Agile methods also emphasize working software as the
primary measure of progress.
An Introduction to Agile Software development Process
Studies have shown that traditional plan driven software development methodologies are not used in
practice. It has been argued that traditional methodologies are too mechanistic to be used in detail. As a
result, industrial software developers have become skeptical about new solutions that are difficult to grasp
and thus remain unused. Agile software development methods, “officially” started with publication of the
agile manifesto, make an attempt to bring about a paradigm shift in the field of software engineering.
Agile methods claim to place more emphasis on people, interaction, working software, customer
collaboration, and change, rather than on processes, tool, contract and plans. A number of promising new
methodologies claiming conformance to these agile principles have been introduced. Yet, no systematic
review of the agile methods has been attempted [1].
Agile methods: Embracing Change
Agile methods stress productivity and values over heavyweight process overhead and artifacts. The Agile
Manifesto [3], a concise summary of agile values, was written and signed in 2001 although agile methods
have existed since the early 90s. Agile methods promote an iterative mechanism for producing software,
and they further increase the iterative nature of the software lifecycle by tightening design-code-test loop
to at least once a day (if not much more frequently) as opposed to once per iteration [2].
Real Life Examples of Agile Development process
A man was hanging Christmas lights and found a way to incorporate test driven development (TDD) and
continuous integration (CI) into putting up the lights. He put up his lights, then turned them on and found
he had a problem. Here he had broken the first rule of agile development - Test First! Of course, any
reasonably competent handyman would have known to try plugging in each strand of lights before
beginning the life-threatening task of suspending them from the roof - right?
Case study on Agile Development Methods
Based
on
industrial
data
from
one
company
(Bitonic
Solutions
Inc.
http://www.bitonic.ca/frontpage/index.html), a comparison in the productivity of agile methods with more
conventional approaches have been done. Bitonic was using ad-hoc OO software development practices
(use cases, UML design, etc.) before adopting agile development techniques. Besides switching to
lightweight approaches in 2001, the company context stayed more or less stable over the timeframe
providing the data for investigation: the data was gathered from work for the same client on the same
product and the team was stable over the time when agile approaches were introduced [9].
6
Results
5 releases were developed using agile practices, 9 releases followed their original process, 2 releases were
in the transition phase and were excluded when we computed the average results below.
The results indicate strong productivity increases after adopting agile practices. If productivity is defined
based on number of features delivered to the customer, productivity decreases are visible after adopting
agile development methods. The summary of the discussion is that Bitonic is now addressing much more
complicated features than in the beginning of the project and, hence, would argue that a 4.96% decrease
in the number of features delivered to the customer per hour in fact is an increase of their development
productivity.
Advantages of Agile Software Development Process
There are lot of advantages which come along Agile Software Development, following are list of some of
them [4].
One huge advantage of Agile Development over all other processes is that it emphasizes on testing as
early as possible and as thorough as possible.
Revenue, The iterative nature of agile development means features are delivered incrementally, enabling
some
benefits
to
be
realized
early
as
the
product
continues
to
develop.
Speed-to-market, Research suggests about 80% of all market leaders were first to market. As well as the
higher revenue from incremental delivery, agile development philosophy also supports the notion of early
and
regular
releases,
and
'perpetual
beta.
Quality, A key principle of agile development is that testing is integrated throughout the lifecycle,
enabling regular inspection of the working product as it develops. This allows the product owner to make
adjustments if necessary and gives the product team early sight of any quality issues.
Visibility, Agile development principles encourage active 'user' involvement throughout the product's
development and a very cooperative collaborative approach. This provides excellent visibility for key
stakeholders, both of the project's progress and of the product itself, which in turn helps to ensure that
expectations
are
effectively
managed.
Risk Management, Small incremental releases made visible to the product owner and product team
through its development help to identify any issues early and make it easier to respond to change. The
clear visibility in agile development helps to ensure that any necessary decisions can be taken at the
earliest possible opportunity, while there's still time to make a material difference to the outcome.
Flexibility / Agility, In traditional development projects, we write a big spec up-front and then tell
business owners how expensive it is to change anything, particularly as the project goes on. In fear of
scope creep and a never-ending project, we resist changes and put people through a change control
committee to keep them to the essential minimum. Agile development principles are different. In agile
development, change is accepted. In fact, it's expected. Because the one thing that's certain in life is
change. Instead the timescale is fixed and requirements emerge and evolve as the product is developed.
Of course for this to work, it's imperative to have an actively involved stakeholder who understands this
concept and makes the necessary trade-off decisions, trading existing scope for new.
Cost Control, The above approach of fixed timescales and evolving requirements enables a fixed budget.
7
The
scope
of
the
product
and
its
features
are
variable,
rather
than
the
cost.
Business Engagement/Customer Satisfaction, The active involvement of a user representative and/or
product owner, the high visibility of the product and progress, and the flexibility to change when change
is needed, creates much better business engagement and customer satisfaction. This is an important
benefit that can create much more positive and enduring working relationships.
Right Product, Above all other points, the ability for agile development requirements to emerge and
evolve, and the ability to embrace change (with the appropriate trade-offs), the team builds the right
product. It's all too common in more traditional projects to deliver a "successful" project in IT terms and
find that the product is not what was expected, needed or hoped for. In agile development, the emphasis is
absolutely
on
building
the
right
product.
More Enjoyable, Active involvement, cooperation and collaboration make agile development team, a
much more enjoyable place for most people. Instead of big specs, we discuss requirements in workshops.
Instead of lengthy status reports, we collaborate around a task-board discussing progress. Instead of long
project plans and change management committees, we discuss what's right for the product and project and
the team is empowered to make decisions. In my experience this makes it a much more rewarding
approach for everyone. In turn this helps to create highly motivated, high performance teams that are
highly cooperative.
Disadvantages of Agile Software Development Process
There are several advantages and disadvantages for any development process. Here are some of the
disadvantages behind Agile software development process [4].
Active user involvement and close collaboration are required throughout the development cycle. This is
very engaging, rewarding and ensures delivery of the right product. It's the fundamental principle in agile
that ensures expectations are well managed. And since the definition of failure is not meeting
expectations, these are critical success factors for any project. However these principles are very
demanding on the user representative's time and require a big commitment for the duration of the project.
Requirements emerge and evolve throughout the development. This creates the very meaning of agile flexibility. Flexibility to change course as needed and to ensure delivery of the right product. There are
two big flip sides to this principle though. One is the potential for scope creep, which we all know can
create the risk of ever-lasting projects. The other is that there is much less predictability, at the start of the
project and during, about what the project is actually going to deliver. This can make it harder to define a
business case for the project, and harder to negotiate fixed price projects. Without the maturity of a strong
and clear vision, and the discipline of fixing timescales and trading scope, this is potentially very
dangerous.
Agile requirements are barely sufficient. This eliminates wasted effort on deliverables that don't last (i.e.
aren't part of the finished product), which saves time and therefore money. Requirements are clarified just
in time for development and can be documented in much less detail due to the timeliness of
conversations. However this can mean less information available to new starters in the team about
features and how they should work. It can also create potential misunderstandings if the teamwork and
communication aren't at their best, and difficulties for team members (especially testers) that are used to
everything being defined up front. The belief in agile is that it's quicker to refractor the product along the
way than to try to define everything completely up front, which arguably is impossible. And this risk is
managed closely through the incremental approach to development and frequent delivery of product.
8
Testing is integrated throughout the lifecycle. This helps to ensure quality throughout the project without
the need for a lengthy and unpredictable test phase at the end of the project. However it does imply that
testers are needed throughout the project and this effectively increases the cost of resources on the project.
This does have the effect of reducing some very significant risks that have proven through research to
cause many projects to fail. The cost of a long and unpredictable test phase can, in my experience of
waterfall, cause huge unexpected costs when a project over-runs. However there is an additional cost to
the project to adopt continuous testing throughout.
Frequent delivery of product and the need to sign off each feature as done before moving on to the next
makes UAT (user acceptance testing) continuous and therefore potentially quite onerous. The users or
product owner needs to be ready and available for prompt testing of the features as they are delivered and
throughout the entire duration of the project. This can be quite time-consuming but helps drastically to
ensure a quality product that meets user expectations.
Finally, common feedback is that agile development is rather intense for developers. The need to really
complete each feature 100% within iteration, and the relentlessness of iterations, can be mentally quite
tiring so it's important to find a sustainable pace for the team.
2. Joint Application Development (JAD)
JAD (Joint Application Development) is a methodology that involves the client or end user in the design
and development of an application, through a succession of collaborative workshops called JAD sessions.
The JAD approach, in comparison with the more traditional practice, is thought to lead to faster
development times and greater client satisfaction, because the client is involved throughout the
development process. In comparison, in the traditional approach to systems development, the developer
investigates the system requirements and develops an application, with client input consisting of a series
of interviews. Joint Application Development (JAD) is a process used in the Systems Development Life
Cycle (SDLC) to collect business requirements while developing new information systems for a
company. "The JAD process also includes approaches for enhancing user participation, expediting
development, and improving the quality of specifications." It consists of a workshop where “knowledge
workers and IT specialists meet, sometimes for several days, to define and review the business
requirements for the system [5].” The attendees include high level management officials who will ensure
the product provides the needed reports and information at the end. This acts as “a management process,
which allows Corporate Information Services (IS) departments to work more effectively with users in a
shorter time frame [6].”
Basic Components of JAD session
Figure 2, shows various components of JAD session. The descriptions of these basic components of JAD
session are listed below [8]:
Executive Sponsor: The executive who charters the project, the system owner. They must be high enough
in the organization to be able to make decisions and provide the necessary resources and support for the
project. They might attend the opening and closing session.
9
PROJECT Leader/manager: Generally the leader of the application development team answers
questions about the project regarding scope, time, coordination issues and resources. They may contribute
to the sessions as long as they do not inhibit the participants.
FACILITATOR/SESSION LEADER: Chairs the meeting and directs traffic by keeping the group on the
meeting agenda. The facilitator is responsible for identifying those issues that can be solved as part of the
meeting and those which need to be assigned at the end of the meeting for follow-up investigation and
resolution. The facilitator serves the participants and does not contribute information to the meeting.
Scribe/Modeler/Recorder/Documentation Expert: Records and publish the proceedings of the meeting
and does not contribute information to the meeting.
PARTICIPANTS: Customers in the business area directly or indirectly being affected by this project,
who are experts in their field and can make decisions about their work. They are the source of the input to
the session.
OBSERVERS: Generally members of the application development team assigned to the project. They are
to sit behind the participants and are to silently observe the proceedings.
Figure 2: A typical JAD meeting room
Steps in Performing JAD
There are 9 key steps in performing JAD process [7]
1. Identify project objectives and limitations it is vital to have clear objectives for the workshop and
for the project as a whole. The pre-workshop activities, the planning and scoping, set the expectations of
the workshop sponsors and participants. Scoping identifies the business functions that are within the
scope of the project. It also tries to assess both the project design and implementation complexity. The
political sensitivity of the project should be assessed. Has this been tried in the past? How many false
starts were there? How many implementation failures were there? Sizing is important. For best results,
systems projects should be sized so that a complete design - right down to screens and menus - can be
designed in 8 to 10 workshop days.
10
2. Identify critical success factors, it is important to identify the critical success factors for both the
development project and the business function being studied. How will we know that the planned changes
have been effective? How will success be measured? Planning for outcomes assessment helps us judge
the effectiveness and the quality of the implemented system over its entire operational life.
3. Define project deliverables, in general, the deliverables from a workshop are documentation and a
design. It is important to define the form and level of detail of the workshop documentation. What types
of diagrams will be provided? What type or form of narrative will be supplied? It is a good idea to start
using a CASE tool for diagramming support right from the start. Most of the available tools have well to
great diagramming capabilities but their narrative support is generally weak. The narrative is best
produced with your standard word processing software.
4. Define the schedule of workshop activities, Workshops vary in length from one to five days. The
initial workshop for a project should not be less than three days. It takes the participants most of the first
day to get comfortable with their roles, with each other, and with the environment. The second day is
spent learning to understand each other and developing a common language with which to communicate
issues and concerns. By the third day, everyone is working together on the problem and real productivity
is achieved. After the initial workshop, the team building has been done. Shorter workshops can be
scheduled for subsequent phases of the project, for instance, to verify a prototype. However, it will take
the participants from one to three hours to re-establish the team psychology of the initial workshop.
5. Select the participants these are the business users, the IS professionals, and the outside experts that
will be needed for a successful workshop. These are the true "back bones" of the meeting who will drive
the changes.
6. Prepare the workshop material before the workshop, the project manager and the facilitator perform
an analysis and build a preliminary design or straw man to focus the workshop. The workshop material
consists of documentation, worksheets, diagrams, and even props that will help the participants
understand the business function under investigation.
7. Organize workshop activities and exercises, Facilitator must design workshop exercises and
activities to provide interim deliverables that build towards the final output of the workshop. The preworkshop activities help design those workshop exercises.
8. Prepare, inform, and educate the workshop participants, all of the participants in the workshop
must be made aware of the objectives and limitations of the project and the expected deliverables of the
workshop. Briefing of participants should take place 1 to 5 days before the workshop. This briefing may
be teleconferenced if participants are widely dispersed. The briefing document might be called the
Familiarization Guide, Briefing Guide, Project Scope Definition, or the Management Definition Guide or anything else that seems appropriate. It is a document of eight to twelve pages, and it provides a clear
definition of the scope of the project for the participants. The briefing itself lasts two to four hours. It
provides the psychological preparation everyone needs to move forward into the workshop.
9. Coordinate workshop logistics, Workshops should be held off-site to avoid interruptions. Projectors,
screens, PCS, tables, markers, masking tape, Post-It notes, and lots of other props should be prepared.
What specific facilities and props are needed is up to the facilitator. They can vary from simple flip charts
11
to electronic white boards. In any case, the layout of the room must promote the communication and
interaction of the participants.
Example of JAD process
For example, for a Business Area Analysis, what is appropriate? A decomposition diagram, a high-level
entity-relationship diagram, A normalized data model, A state transition diagram, A dependency diagram,
All of the above, None of the above. It is important to define the level of technical diagramming that is
appropriate to the environment. The most important thing about a diagram is that the users must
understand it. Once the diagram choice is made, the facilitator designs exercises into the workshop
agenda to get the group to develop those diagrams. A workshop combines exercises that are serially
oriented to build on one another, and parallel exercises, with each sub-team working on a piece of the
problem or working on the same thing for a different functional area. High-intensity exercises led by the
facilitator energize the group and direct it towards a specific goal. Low-intensity exercises allow for
detailed discussions before decisions. The discussions can involve the total group or teams can work out
the issues and present a limited number of suggestions for the whole group to consider. To integrate the
participants, the facilitator can match people with similar expertise from different departments. To help
participants learn from each other, he can mix the expertise. It's up to the facilitator to mix and match the
sub-team members to accomplish the organizational, cultural, and political objectives of the workshop. A
workshop operates on both the technical level and the political level. It is the facilitator's job to build
consensus and communications, to force issues out early in the process. There is no need to worry about
the technical implementation of a system if the underlying business issues cannot be resolved [7].
Advantages of JAD
If the above guidelines are followed closely, chances are, the JAD will be successful. A successful JAD
session should provide these benefits [8]:
Reduced system development time, In JAD, information can be obtained and validated in a shorter time
frame by involving all participants (or at least a representative set of participants) who have a stake in the
outcome of the session. JAD eliminates process delays and has been shown to reduce application
development time between 20% to 50%.
Improved system quality and productivity, much of the system’s quality depends on the requirements
gathered. JAD involves users in the development life cycle, lets users define their requirements, thus
ensures that the system developed satisfies the actual activities of the business JAD is quoted the best
method for collecting requirements from the users, customers, or customer advocates.
Reduced system cost, much of the system development cost is in terms of man-hours of both system
developers and business users involved. Reduced development time reduces the labor cost for developers,
as well as users. Important process like requirement gathering requires the involvement and commitment
of business area experts. The cost of taking them away from their daily operation is very high. JAD can
reduce the involvement time of these business experts and hence reduce the cost further. Cost is also
reduced by catching errors, misunderstandings and mistakes early in the development phrase. Studies
have found that a majority of system errors result from early analysis errors, and the earlier these errors
are corrected, the much less they will cost. The JAD sessions let designers and users work together in the
very early of the development cycle, defining the scope, requirements of projects, resolving conflicts
12
among different user groups. It put many efforts early in the life cycle in order to improve the quality and
increase productivity and to reduce cost.
Enhanced communication and relationship, JAD helps in building good relationships between business
end-users and IT personnel.
Cultivate ownership, Easier acceptance (buy-in) and stronger commitment by users. The involvement of
business end-users is no longer on advisory or consultation spectrum. It is the participation and
contribution in the project development life cycle. The more users contribute to the system, the easier for
them to accept it and commit to it.
Reduced function creep, is one of the best ways to reduce function creep, most of which results from
poor initial requirements.
Enhanced education for participants and observers, By participating in JAD and be the medium
between other users and IT, the business end-users will be kept fully informed about the progress of the
system development.
Disadvantages of JAD
JAD is very useful development process, but it also has some negative point like as follows:
It opens up a lot of scope for inter-personal conflict.
More expensive and can be cumbersome.
3. EXTREME PROGRAMMING (XP)
Extreme Programming (XP), 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. XP is a software
engineering methodology which is intended to improve software quality and responsiveness to changing
customer requirements. As a type of agile software development (discuss above), it advocates frequent
"releases" in short development cycles (time boxing), 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.
Extreme Programming is successful because it stresses customer satisfaction. Instead of delivering
everything you could possibly want on some date far in the future this process delivers the software you
need as you need it. Extreme Programming empowers your developers to confidently respond to changing
customer requirements, even late in the life cycle. Extreme Programming emphasizes teamwork.
Managers, customers, and developers are all equal partners in a collaborative team. Extreme
Programming implements a simple, yet effective environment enabling teams to become highly
productive. The team self-organizes around the problem to solve it as efficiently as possible. Contrary to
13
what many think, extreme programming has nothing to do with large, difficult, or complex projects.
Extreme Programming, or XP, is a lightweight discipline of software development based on principles of
simplicity, communication, feedback, and courage. XP is designed for use with small teams who need to
develop software quickly in an environment of rapidly-changing requirements.
XP Practices
XP can be summed up in twelve “practices” [10], they are described as follow
The Planning Process, The XP planning process allows the XP “customer" to define the business value
of desired features, and uses cost estimates provided by the programmers, to choose what needs to be
done and what needs to be deferred. The effect of XP's planning process is that it is easy to steer the
project to success.
Small Releases, XP teams put a simple system into production early, and update it frequently on a very
short cycle. Every release should be as small as possible containing the most valuable business
requirements. Small releases provide the sense of accomplishment that is often missing in big projects.
Metaphor, XP teams use a common “system of names" and a common system description that guides
development and communication. Metaphors help in making the technology more understandable in
human terms, especially to clients. At one level metaphor and architecture are synonyms – they are both
intended to provide a broad view of project’s goal. XP uses metaphors in an attempt to define an overall
coherent theme to which both developers and business clients can relate.
Simple Design, A program built with XP should be the simplest program that meets the current
requirements. There is not much building for the “future". Instead, the focus is on providing business
value. Of course it is necessary to ensure that you have a good design, and in XP this is brought about
through “refactoring”. Simple design has two parts: One, design for the functionality that has been
defined; Second, to create a best design that can deliver that functionality.
Testing, XP teams focus on validation of the software at all times. Programmers develop software by
writing tests first, and then software that fulfills the requirements reflected in the tests. Customers provide
acceptance tests that enable them to be certain that the features they need are provided. XP uses two types
of testing: unit & functional. Unit testing determine whether a given feature works as intended. A
programmer writes as many automated tests as they can think of that might "break" the code; if all tests
run successfully, then the coding is complete. Every piece of code that is written is tested before moving
on to the next feature.
Refactoring, XP teams improve the design of the system throughout the entire development. This is done
by keeping the software clean: without duplication, with high communication, simple, yet complete. It is
ongoing redesign of software to improve its responsiveness to change.
Pair Programming, XP programmers write all production code in pairs, two programmers working
together at one machine. Pair programming has been shown by many experiments to produce better
software at similar or lower cost than programmers working alone. Pair programming is a software
development technique in which two programmers work together at one work station. One types in code
while the other reviews each line of code as it is typed in. The person typing is called the driver. The
person reviewing the code is called the observer or navigator. The two programmers switch roles
frequently (possibly every 30 minutes or less).While reviewing, the observer also considers the strategic
14
direction of the work, coming up with ideas for improvements and likely future problems to address. This
frees the driver to focus all of his or her attention on the "tactical" aspects of completing the current task,
using the observer as a safety net and guide.
Collective Ownership, All the code belongs to all the programmers. This lets the team go at full speed,
because when something needs changing, it can be changed without delay. XP provides collective
ownership as practice that anyone on the project can change any of the code at any time.
Continuous Integration, XP teams integrate and build the software system multiple times per day. This
keeps all the programmers on the same page, and enables very rapid progress. Perhaps surprisingly,
integrating more frequently tends to eliminate integration problems that plague teams who integrate less
often.
40-hour Week, Tired programmers make more mistakes. XP teams do not work excessive overtime,
keeping them fresh, healthy, and effective. Programmers go home on time. In crunch mode, up to one
week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that
something is very wrong with the process.
On-site Customer, An XP project is steered by a dedicated individual who is empowered to determine
requirements, set priorities, and answer questions as the programmers have them. The effect of being
there is that communication improves, with less hard-copy documentation - often one of the most
expensive parts of a software project. Development team has continuous access to a real live customer,
that is, someone who will actually be using the system. For commercial software with lots of customers, a
customer proxy (usually the product manager) is used instead.
Coding Standard, for a team to work effectively in pairs, and to share ownership of all the code, all the
programmers need to write the code in the same way, with rules that make sure the code communicates
clearly. XP practices are supportive of each other. For example if you do pair programming and let
anyone modify the communal code, then coding standards would need to be necessity.
XP Principles
Basic Principles, describe below [11]:
Rapid Feedback, Extreme Programming sees feedback as most useful if it is done rapidly and expresses
that the time between an action and its feedback is critical to learning and making changes. Unlike
traditional system development methods, contact with the customer occurs in more frequent iterations.
The customer has clear insight into the system that is being developed. He or she can give feedback and
steer the development as needed. So whether it’s hourly builds or frequent functionality testing with the
customer, XP embraces change by frequent feedback. Whether it’s a fixing an object that failed a test case
or refactoring a design that is resisting a change, high change environment requires a much different
understanding of feedback. Unit tests also contribute to the rapid feedback principle. When writing code,
the unit test provides direct feedback as to how the system reacts to the changes one has made. If, for
instance, the changes affect a part of the system that is not in the scope of the programmer who made
them, that programmer will not notice the flaw. There is a large chance that this bug will appear when the
system is in production.
Assume simplicity, XP ask each team member, “What is the simplest thing that could possibly work”. XP
believes in making it simple today and create an environment in which the cost of change tomorrow is
low. This is about treating every problem as if its solution were "extremely simple". Traditional system
15
development methods say to plan for the future and to code for reusability. Extreme programming rejects
these ideas. The advocates of Extreme Programming say that making big changes all at once does not
work. Extreme Programming applies incremental changes: for example, a system might have small
releases every three weeks. When many little steps are made, the customer has more control over the
development process and the system that is being developed.
Embracing Change, The principle of embracing change is about not working against changes but
embracing them. For instance, if at one of the iterative meetings it appears that the customer's
requirements have changed dramatically, programmers are to embrace this and plan the new requirements
for the next iteration.
XP Values
Communication, XP focuses on building person to person, mutual understanding of the problem
environment through minimal formal documentation and maximum face to face interaction. Everyone is
part of the team and we communicate face - face daily. We will work together on everything from
requirements to code. We will create the best solution to our problem that we can together. Building
software systems requires communicating system requirements to the developers of the system. In formal
software development methodologies, this task is accomplished through documentation. Extreme
programming techniques can be viewed as methods for rapidly building and disseminating institutional
knowledge among members of a development team. The goal is to give all developers a shared view of
the system, which matches the view held by the users of the system. To this end, Extreme Programming
favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal
communication, and feedback [12].
Simplicity, Extreme programming encourages starting with the simplest solution. Extra functionality can
then be added later. The difference between this approach and more conventional system development
methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next
week. This is sometimes summed up as the "you're not going to need it" approach. Proponents of XP
acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system;
their claim is that this is more than compensated for by the advantage of not investing in possible future
requirements that might change before they become relevant. Coding and designing for uncertain future
requirements implies the risk of spending resources on something that might not be needed. Related to the
"communication" value, simplicity in design and coding should improve the quality of communication.
Most programmers in the team could easily understand a simple design with very simple code [12].
Feedback
Within Extreme Programming, feedback relates to different dimensions of the system development:
Feedback from the system: by writing unit tests, or running periodic integration tests, the programmers
have direct feedback from the state of the system after implementing changes. Feedback from the
customer: The functional tests (aka acceptance tests) are written by the customer and the testers. They
will get concrete feedback about the current state of their system. This review is planned once in every
two or three weeks so the customer can easily steer the development. Feedback from the team: When
customers come up with new requirements in the planning game the team directly gives an estimation of
the time that it will take to implement. Feedback is closely related to communication and simplicity.
Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will
break. The direct feedback from the system tells programmers to recode this part. A customer is able to
test the system periodically according to the functional requirements, known as user stories [12].
16
Courage
Several practices embody courage. One is the commandment to always design and code for today and not
for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to
implement anything else. Courage enables developers to feel comfortable with refactoring their code
when necessary. This means reviewing the existing system and modifying it so that future changes can be
implemented more easily. Another example of courage knows when to throw code away: courage to
remove source code that is obsolete, no matter how much effort was used to create that source code. Also,
courage means persistence: A programmer might be stuck on a complex problem for an entire day, then
solve the problem quickly the next day, if only they are persistent.
Respect
The respect value manifests in several ways. In Extreme Programming, team members respect each other
because programmers should never commit changes that break compilation, that make existing unit-tests
fail, or that otherwise delay the work of their peers. Members respect their work by always striving for
high quality and seeking for the best design for the solution at hand through refactoring. Adopting the
four earlier values leads to respect gained from others in the team. Nobody on the team should feel
unappreciated or ignored. This ensures high level of motivation and encourages loyalty toward the team,
and the goal of the project. This value is very dependent upon the other values, and is very much oriented
toward people in a team [12].
XP Activities
The four basic activities of Extreme Programming are:
Coding, You code because if you don't code, at the end of the day you haven't done anything. XP says
that the only truly important product of the system development process is code. Without code you have
nothing. Coding can be drawing diagrams that will generate code, scripting a web-based system or coding
a program that needs to be compile d. Coding can also be used to figure out the most suitable solution.
For instance, XP would advocate that faced with several alternatives for a programming problem, one
should simply code all solutions and determine with automated tests (see below) which solution is most
suitable. Coding can also help to communicate thoughts about programming problems. A programmer
dealing with a complex programming problem and finding it hard to explain the solution to fellow
programmers might code it and use the code to demonstrate what he or she means.
Testing, You test because if you don't test, you don't know when you are done coding. One cannot be
certain of anything unless one has tested it. Testing is not a perceived, primary need for the customer. A
lot of software is shipped without proper testing and still works (more or less). In software development,
XP says this means that one cannot be certain that a function works unless one tests it. You can be
uncertain whether what you coded is what you meant. To test this uncertainty, XP uses Unit Tests. These
are automated tests that test the code. The programmer will try to write as many tests he or she can think
of that might break the code he or she is writing; if all tests run successfully then the coding is complete.
You can be uncertain whether what you meant is what you should have meant. To test this uncertainty,
XP uses acceptance tests based on the requirements given by the customer in the exploration phase of
release planning.
Listening, You listen because if you don't listen you don't know what to code or what to test.
Programmers do not necessarily know anything about the business side of the system under development.
The business side determines the function of the system. For the programmers to find what the
17
functionality of the system should be, they have to listen to business. Programmers have to listen to what
the customer needs. Also, they have to try to understand the business problem, and to give the customer
feedback about his or her problem, to improve the customer's own understanding of his or her problem.
Communication between the customer and programmer is further addressed in The Planning Game.
Designing, and you design so you can keep coding and testing and listening indefinitely (good design
allows extension of the system with changes in only one place). From the point of view of simplicity, one
could say that system development doesn't need more than coding, testing and listening. If those activities
are performed well, the result should always be a system that works. In practice, this will not work. One
can come a long way without designing but at a given time one will get stuck. The system becomes too
complex and the dependencies within the system cease to be clear. One can avoid this by creating a
design structure that organizes the logic in the system. Good design will avoid lots of dependencies within
a system; this means that changing one part of the system will not affect other parts of the system.
Figure 3 Describes flow chart of XP
Figure 3 shows how Extreme Programming's rules work together. Customers enjoy being partners in the
software process, developers actively contribute regardless of experience level, and managers concentrate
on communication and relationships. Unproductive activities have been trimmed to reduce costs and
frustration of everyone involved.
Examples on Extreme Programming
A longitudinal case study evaluating the effects of adopting the Extreme Programming (XP) methodology
was performed at Sabre Airline Solutions™. The Sabre team was a characteristically agile team in that
they had no need to scale or re-scope XP for their project parameters and organizational environment.
The case study compares two releases of the same product. One release was completed just prior to the
team’s adoption of the XP methodology, and the other was completed after approximately two years of
XP use [13].
Results
Comparisons of the new release project results to the old release project results show a 50% increase in
18
productivity, a 65% improvement in pre-release quality, and a 35% improvement in post-release quality.
These findings suggest that, over time, adopting the XP process can result in increased productivity and
quality [13].
Advantages of XP (Extreme Programming)
Customer focus, Customer focus increase the chance that the software produced will actually meet the
needs of the users
Decrease Risk, The focus on small, incremental release decreases the risk on your project: by showing
that your approach works and by putting functionality in the hands of your users, enabling them to
provide timely feedback regarding your work.
Testing, Continuous testing and integration helps to increase the quality of work.
NO Process, XP is attractive to programmers who normally are unwilling to adopt a software process,
enabling your organization to manage its software efforts better.
For developers, XP allows you to focus on coding and avoid needless paperwork and meetings. It
provides a more social atmosphere, more opportunities to learn new skills, and a chance to go home at a
decent time each night. It gives you very frequent feelings of achievement, and generally allows you to
produce code that you feel good about.
For the Customer, XP creates working software faster, and that software tends to have very few defects.
It allows you to change your mind whenever you need to, with minimal cost and almost no complaining
from the developers. It produces reliable estimates so you can coordinate your schedule easier.
For management, XP delivers working software for less money, and the software is more likely to do
what the end users actually want. It cuts risk in a couple ways: 1) It allows you to "pull the plug" on
development at almost any time, and still have highly valuable code, and probably even a valuable
working (if incomplete) application. 2) It reduces your dependence on individual superstars, and at the
same time can improve employee satisfaction and retention.
Disadvantages (XP Extreme Programming)
XP is geared toward a single project, developed and maintained by a single team.
XP will not work in an environment where a customer or manager insists on a complete specification or
design before they begin programming.
XP will not work in an environment where programmers are separated geographically.
XP has not been proven to work with systems that have scalability issues (new applications must integrate
into existing systems).
The biggest disadvantage: Extreme Programming is hard to do. It's difficult to get many developers to
accept the practices, and it takes a lot of discipline to keep doing them all. Customers may not like the
idea of having to be so involved. Management may have trouble adapting to a process that, itself, adapts
to the changing needs of the business.
19
XP calls for a family of new management methods but does not provide the management training and
guidance needed for these methods to be accepted and effectively practiced.
4. Scrum Development Process
Scrum is an iterative incremental framework for managing complex work (such as new product
development) commonly used with agile software development. 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. The stated, accepted philosophy for systems development
is that the development process is a well-understood approach that can be planned, estimated, and
successfully completed. This has proven incorrect in practice. SCRUM assumes that the systems
development process is an unpredictable, complicated process that can only be roughly described as an
overall progression. SCRUM defines the systems development process as a loose set of activities that
combines known, workable tools and techniques with the best that a development team can devise to
build systems. Since these activities are loose, controls to manage the process and inherent risk are used.
SCRUM is an enhancement of the commonly used iterative/incremental object-oriented development
cycle [14].
Figure 4 Scrum developments Process
Artifacts of Scrum Process
Product backlog (Figure 4), the product backlog is a high-level document for the entire project. It
contains backlog items: broad descriptions of all required features, wish-list items, etc. prioritized by
business value. It is the "What" that will be built. It is open and editable by anyone and contains rough
estimates of both business value and development effort. Those estimates help the Product Owner to
gauge the timeline and, to a limited extent, priority. For example, if the "add spell-check" and "add table
support" features have the same business value, the one with the smallest development effort will
probably have higher priority, because the Rate of interest (ROI) is higher. The product backlog is
property of the Product Owner. The Product Owner sets business value. Development effort is set by the
Team [15].
20
Sprint backlog (Figure 4), the sprint backlog is a document containing information about how the team is
going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best
practice, tasks are normally estimated between four and sixteen hours of work. With this level of detail
the whole team understands exactly what to do and anyone can potentially pick a task from the list. Tasks
on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed,
according to the set priority and the team member skills. The sprint backlog is property of the Team.
Estimations are set by the Team.
Burn down, the Sprint burn down chart is a publicly displayed chart showing remaining work in the
sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick
visualizations for reference. There are also other types of burn down, for example the Release Burn down
Chart that shows the amount of work left to complete the target commitment for a Product Release
(normally spanning through multiple iterations) and the Alternative Release Burn down Chart, which
basically does the same, but allows to show clearly scope changes into a Release Content, by resetting the
baseline.
Roles
The Scrum team performs the actual work of problem solvers and designers. The team normally consists
of 5-9 people – a group size that experience and research has shown to be best for this type of work. T he
team members decide how the work is arranged and how assignments are distributed. There are no set
project roles – everyone should be able to swap tasks with another member. Naturally, this does not
prevent individual members from being experts in a field [15].
Product owner represents the voice of the customer and ensures that the Scrum Team works with the
right things from a business perspective. The Product Owner administers a Product Backlog – a current
to-do list where all the specifications for a product are listed according to how profitable they are deemed
to be. The document is visible to the entire organization so that everyone is aware of what to expect in
future releases of the product. The Product Owner is often a customer, but can also be part of the internal
organization. The task requires comprehensive knowledge about engineering, marketing and business
processes.
Scrum master is a combination of coach, fixer and gatekeeper. The Scrum Master meets with the team
every day in brief meetings, Daily Scrums. When someone outside the project has an important issue to
discuss with the team, the Scrum Master tries to ensure that the designers are disturbed as little as possible
in their work. The Scrum Master always adopts a here and-now perspective to the work. The focus is
always on providing the team with the best possible circumstances for realizing the goals fixed for the
Sprint. After each Sprint, the Scrum Master holds an Evaluation Meeting with the Scrum team – a Sprint
Retrospective – during which experiences and conclusions are reviewed. The purpose is to elevate the
team’s level of knowledge and heighten motivation prior to the next Sprint.
PROCESS
Creating a backlog
The Product Owner compiles all the requests and specifications that are the basis of the changes of the
product, such as new functions and bug fixes. After the goals have been defined, the entirety is broken
down into segments. Each such segment should in part create business value and in part be subdeliverable. A prioritized list is made at the same time – the Product Owner personally makes the
decisions at this point. In what order should the changes be made and delivered? The result is a to-do list
21
arranged according to how the market’s demands and customer’s requests change over time. When it is
time to start a new Sprint, the Product Owner “freezes” the foremost items on the to-do list and summons
the Scrum Team to a meeting [15].
The sprint phase
Of the Sprint’s 30 calendar days, the first are set aside to create a Sprint Backlog. When the tasks and
required time has been determined, the Product Owner lets go. As of now the Scrum Team works under
its own responsibility. If the group has been properly composed, the work will be self organizing.
Daily Scrum
Every day, at the same time, the Scrum Master and the Scrum Team have a brief meeting. The purpose is
to eliminate all speed impediments for the group. Each of the participants should in some way answer
three questions [15]:
• What have you done since the last meeting?
• What will you do between now and the next meeting?
• Is there anything preventing you from doing what you have planned?
The first two questions give the meeting participants full insight into how the project is progressing. The
third question provides a basis for problem solving – ranging from a new computer mouse to
organizational changes at the company. Anyone may attend and listen at the meeting, but only the Scrum
Master and the team members may speak.
SCRUM CHARACTERISTICS
SCRUM projects have the following characteristics [14]:






Flexible deliverable, the content of the deliverable is dictated by the environment.
Flexible schedule, the deliverable may be required sooner or later than initially planned.
Small teams, each team has no more than 6 members. There may be multiple teams within a
project.
Frequent reviews, team progress is reviewed as frequently as environmental complexity and risk
dictates (usually 1 to 4 week cycles). A functional executable must be prepared by each team for
each review.
Collaboration, intra and inter-collaboration is expected during the project.
Object Oriented, each team will address a set of related objects, with clear interfaces and behavior.
SCRUM Methodology
The system development process is complicated and complex. Therefore maximum flexibility and
appropriate control is required. Evolution favors those that operate with maximum exposure to
environmental change and have optimized for flexible adaptation to change. Evolution deselects those
who have insulated themselves from environmental change and have minimized chaos and complexity in
their environment.
An approach is needed that enables development teams to operate adaptively within a complex
environment using imprecise processes. Complex system development occurs under rapidly changing
circumstances. Producing orderly systems under chaotic circumstances requires maximum flexibility.
The closer the development team operates to the edge of chaos, while still maintaining order, the more
competitive and useful the resulting system will be. Langton has modeled this effect in computer
simulations and his work has provided this as a fundamental theorem in complexity theory. Methodology
may well be the most important factor in determining the probability of success [14].
Methodologies that encourage and support flexibility have a high degree of tolerance for changes in other
22
variables. With these methodologies, the development process is regarded as unpredictable at the onset,
and control mechanisms are put in place to manage the unpredictability.
Figure5. SCRUM Methodology [14]
Characteristics of SCRUM Methodology are:
• First and last phases (Planning and Closure) consist of defined processes, where all processes, inputs
and outputs are well defined. The knowledge of how to do these processes is explicit. The flow is linear,
with some iteration in the planning phase.
• The Sprint phase is an empirical process. Many of the processes in the sprint phase are unidentified or
uncontrolled. It is treated as a black box that requires external controls. Accordingly, controls, including
risk management, are put on iteration of the Sprint phase to avoid chaos while maximizing flexibility.
• Sprints are nonlinear and flexible. Where available, explicit process knowledge is used; otherwise tacit
knowledge and trial and error is used to build process knowledge. Sprints are used to evolve the final
product.
• Project is open to the environment until the Closure phase. The deliverable can be changed at any time
during the Planning and Sprint phases of the project. The project remains open to environmental
complexity, including competitive, time, quality, and financial pressures, throughout these phases.
• Deliverable is determined during the project based on the environment.
Case Study
In July 2007, a Senior Engineer from the then new Events 2.0 project team recommended implementing
development using the Scrum approach. Although we were enthusiastic, we were not prepared. As is
typical for XING, we quickly sought out an available Scrum Master and began our Scrum experiment.
Results
Our conclusion so far: Introducing Scrum is not easy and requires substantial modifications to the
organization and product development processes. For us, it has already paid off because of the capability
to react quickly and adeptly to dynamic requirements on our platform and better usage of our skill
potentials. We feel well prepared as we look to the future.
Advantages
There many advantages of using Scrum in an organization some of them are listed below [14]:
Traditional development methodologies are designed only to respond to the unpredictability of the
external and development environments at the start of an enhancement cycle. Such newer approaches as
the Boehm spiral methodology and its variants are still limited in their ability to respond to changing
23
requirements once the project has started.
The SCRUM methodology, on the other hand, is designed to be quite flexible throughout. It provides
control mechanisms for planning a product release and then managing variables as the project progresses.
This enables organizations to change the project and deliverables at any point in time, delivering the most
appropriate release.
The SCRUM methodology frees developers to devise the most ingenious solutions throughout the project,
as learning occurs and the environment changes.
Small, collaborative teams of developers are able to share tacit knowledge about development processes.
An excellent training environment for all parties is provided.
Object oriented technology provides the basis for the SCRUM methodology. Objects, or product
features, offer a discrete and manageable environment. Procedural code, with its many and intertwined
interfaces, is inappropriate for the SCRUM methodology. SCRUM may be selectively applied to
procedural systems with clean interfaces and strong data orientation.
Disadvantages
Every development process has some advantages and some disadvantages, so here we are mentioning
some of the downside of using Scrum:
Scrum is not effective for small projects
Expensive to implement
Training is required
Scrum also means you have to be in close contact with your external stakeholders so all-important things
are on your backlog. This is not always feasible and may delay or upset them.
5. Lean software development (LD)
“Lean technology is a philosophy of making a conscious choice to radically redefine and dynamically
optimize strategy, systems, processes and services and add value to clients, employees and shareholders”.
Lean software development is a translation of lean manufacturing principles and practices to the software
development domain. . Adapted from the Toyota Production System, a pro-lean subculture is emerging
from within the agile Software development community. Lean manufacturing or lean production, which is
often known simply as "Lean", is a production practice that considers the expenditure of resources for any
goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination.
They may be clearly identified, but are poorly acknowledged. The problems of the software development
planet are responsible for most of the project failures that force managements worldwide to put more rigid
processes in place to ensure compliance. More stringent processes at each stage are making the whole
process a “Concrete-Life jacket”. By using Lean Production/Manufacturing principles not only quality
concerns and other issues can be resolved, but also a continuous improvement cycle can be built in to the
process. This can help in improving the quality of the software solutions/products each time a new
software solution/product is built [17].
In software industry, developers often say, “Life would be so much easier if customers would just stop
changing their minds”. In fact, there is a very easy way to keep customers from changing their minds –
give them what they ask for so fast that they don’t have the time to change their minds. The idea behind
lean thinking is exactly this, let customers delay their decisions about exactly what they want as long as
possible, and when they ask for something, give it to them so fast they don’t have time to change their
minds. The way to deliver things rapidly is to deliver them in small packages. The bigger the increment
24
of functionality you try to deliver, the longer it takes to decide what is needed and then get it developed,
tested, and deployed. Maintenance programmers have known this for years. When a piece of production
code breaks, they find the cause, create a patch, test it rigorously, and release it to production – usually in
the space of a few hours or days [16].
Principles of Lean Software Development Process
There are seven principles of Lean Software Development, drawn from the seven principles of Lean
Thinking. These principles are not cookbook recipes for software development, but guideposts for
devising appropriate practices for your environment.
Eliminate waste
The first step in lean thinking is to understand what “value” is and what activities and resources are
absolutely necessary to create the value. Since no one wants to consider what they do as waste, the job of
determining what value is and what adds value is something that needs to be done at a fairly high level.
All lean thinking starts with a re-examination of what waste is and an aggressive campaign to eliminate it.
Quite simply, anything you do that does not add value from the customer perspective is waste. The seven
wastes of software development are [16]:
→ Partially Done Work (the “inventory” of a development process)
→ Extra Processes (easy to find in documentation-centric development)
→ Extra Features (develop only what customers want right now)
→ Task Switching (everyone should do one thing at a time)
→ waiting (for instructions, for information)
→ Handoffs (tons of tacit knowledge gets lost)
→ Defects (at least defects that are not quickly caught by a test)
Amplify learning
Software development is a continuous learning process with the additional challenge of development
teams and end product sizes. The best approach for improving a software development environment is to
amplify learning. Running tests as soon as the code is written should prevent the accumulation of defects.
Instead of adding more documentation or detailed planning, different ideas could be tried by writing code
and building. Presenting screens to the end-users and getting their input could simplify the process of user
requirements gathering. The learning process is sped up by usage of short iteration cycles – each one
coupled with refactoring and integration testing. Increasing feedback via short feedback sessions with
Customers helps when determining the current phase of development and adjusting efforts for future
improvements. During those short sessions both Customer representatives and the development team
learn more about the domain problem and figure out possible solutions for further development. Thus the
Customers better understand their needs, based on the existing result of development efforts, and the
developers learn how to better satisfy those needs. Another idea in the communication and learning
process with a Customer is set-based development – this concentrates on communicating the constraints
of the future solution and not the possible solutions, thus promoting the birth of the solution via dialog
with the Customer.
Empower those who add value
A basic principle of Lean Production is to drive decisions down to the lowest possible level, delegating
decision-making tools and authority to the people "on the floor." Often when software development
environments under-perform, the instinctive reaction is to impose more rigid processes, specifying in
greater detail how people should do their jobs. Lean Production principles suggest exactly the opposite
approach. When there are problems in manufacturing, a team of outside experts is not sent in to document
in more detail how the process should be run. Instead, people on the manufacturing floor are given tools
25
to evaluate and improve their own areas. They work in collaborative teams with the charter to improve
their own processes and the links to nearby processes for which they are suppliers or customers. Their
supervisors are trained in methods of forming and encouraging work teams to solve their own. Another
mistaken belief has been the consideration of people as resources. People might be resources from the
point of view of a statistical data sheet, but in software development, as well as any organizational
business, people do need something more than just the list of tasks and the assurance that they will not be
disturbed during the completion of the tasks. People need motivation and a higher purpose to work for –
purpose within the reachable reality, with the assurance that the team might choose its own commitments.
The developers should be given access to Customer; the team leader should provide support and help in
difficult situations, as well as make sure that skepticism does not ruin the team’s spirit [17].
Build Integrity In
There are two kinds of integrity – perceived integrity and conceptual integrity. Software with perceived
integrity delights the customer – it’s exactly what they want even though they didn’t know how to ask for
it. Conceptual integrity means that all of the parts of a software system work together to achieve a
smooth, well functioning whole. Software with conceptual integrity presents the user with a single
metaphor of how a task is to be done. You don’t have one way of buying airline tickets if you are paying
with cash and a totally different way if you are using frequent flier miles. You don’t use kilometers in one
module and miles in another. Conceptual integrity is achieved through continuous, detailed information
flow between various technical people working on a system. There is only one way to achieve this, people
have to talk to each other, early and often. There can be no throwing things over the wall, no lines
between supplier, development team, support team, customer. Everyone should be involved in detailed
discussions of the design as it develops, from the earliest days of the program [17].
Deliver as fast as possible
The goal is to let your customer take an options-based approach to making decisions, letting them delay
their decisions a long as possible so they can make decisions based on the best possible information. Once
your customers decide what they want, your goal should be to create that value just as fast as possible.
This means no delay in deciding what requests to approve, no delay in staffing, immediate clarification of
requirements, no time-consuming handoffs, no delay in testing, no delay for integration, no delay in
deployment. In a mature software development organization, all of this happens in one smooth, rapid flow
in response to a customer need.
Maximizing flow
In lean software development, the idea is to maximize the flow of information and delivered value. In
lean production, Maximizing flow does not mean automation. Instead it means limiting what has to be
transferred, and transferring that as few times as possible over the shortest distance with the widest
communication bandwidth. Similarly in software development the idea is to eliminate as many documents
and handoffs as possible. In the lean software development emphasis is to pair a skilled development
team with a skilled customer team and to give them the responsibility and authority to develop the system
in small, rapid increments, driven by the customer priority and feedback.
Delay Commitment
Delaying commitment means keeping your options open as long as possible. The fundamental lean
concept is to delay irreversible decisions until they can be made based on known events, rather than
forecasts. Economic markets develop options as a way to deal with uncertainty.
See the Whole
26
When you look at them closely, most theories of how to manage software projects are based on a theory
of disaggregation: break the whole into individual parts and optimize each one. Lean thinking suggests
that optimizing individual parts almost always leads to sub-optimized overall system. The best way to
avoid sub-optimization and encourage collaboration is to make people accountable for what they can
influence, not just what they can control. This means measuring performance one level higher than you
would expect. Measure the team’s defect count, not that of individuals. Make testing as accountable for
defect- free code as developers. To some it seems unfair to hold a team accountable for individual
performance, but lean organizations have found that individuals are rarely able to change the system
which influences their performance. However a team, working together and responsible for its own
processes, can and will make dramatic improvements.
Case study
Develop a small business loan processing system in twelve months with minimum initial investment.
Factors such as meeting international requirements, a technology base that was new to the company, and
utilizing an internationally dispersed work force added to the complexity of the project. This company
abandoned the time tested waterfall development approach and embraced new Lean Software
Development principles. Small cross functional teams including end-users were created, trained and
empowered to deliver the end product in incremental phases called iterations. Adopting new techniques
necessitated changes to the traditional project management, tracking and reporting [19].
Results
Within three months the team delivered the first functional system for user acceptance testing. Thereafter
monthly iterations were delivered to expand the features and capabilities of the system. The full feature
set was delivered within the twelve-month period and maintained the original budget. Development time
and initial investment was reduced by over 50% compared to similar products [19].
Advantages
Organizations that understood and applied lean values, principles, and processes have experienced very
significant benefits such as the following:
Lead time reduction of up to 75%
On time delivery rate up to 100%
Productivity improvements of over 80%
Scrap reductions of up to 95%
Space utilization improvements of over 25%
Set-up time reductions of over 85%
Machine down time reductions of 70%
Total project time reduced by 70-90%
Project rework reduced by 60-90%
Project costs reduced by 50-70%
Customer Focus, Waste is anything that does not provide timely customer value. Have you identified
who your customers are? Do you know what these customers really want? Do you know how long it
takes to deliver that value? To find out how well your organization delivers customer value, Lean
development process takes care of all of these by starting analyzing the value stream.
Process Flow, An agile software development team can add features in any order and can release a
working version of the software at the end of any iteration. When manufacturing plants learned how to
make any product in any order, Just-in-Time manufacturing became practical. Now that software
27
developers have learned to add any feature in any order, and deliver working software in two-weeks or
thereabouts, Just-in-Time software development is possible with Lean development process.
Local Responsibility, In Lean development developers and domain experts who jointly develop a deep
understanding of the domain design the best software.
Data Based Decisions, When the goal is to hit a moving target, learning-based software development is
the approach to use. Experienced development teams can implement individual features in any order and
deliver deployable code in less than a month. Learning-based software development deploys small
feature sets in priority order, providing both rapid feedback and immediate business value. Successful
software companies have used this approach for many years.
Lean Thinking, for Software Development is all about driving down this risky inventory and putting it
to work providing customer value as quickly as possible.
Disadvantages
The Lean model ignores the social part of complex systems.
The main drawback of using Lean alone as a process improvement methodology is lack of strategic
supply chain direction. Lean efforts will certainly yield results but can lead to islands of excellence within
an organization if used alone and the time from effort to any significant results can be long
REFERENCES
[1] Agile Software Development Methods Review and Analysis.
Pekka Abrahamsson, Outi Salo & Jussi Ronkainen; University of Oulu
VTT Electronics, VTT Publication 478.
http://www.vtt.fi/inf/pdf/publications/2002/P478.pdf
[2] An Introduction to Agile Software Development;
Victor Szalvay, co-founder
Danube Technologies, Bellevue, WA 98005
http://www.danube.com/docs/Intro_to_Agile.pdf
[3] The Agile Manifesto;
http://www.agilemanifesto.org/
[4] Agile Software Development made easy
http://www.agile-software-development.com/2007/06/10-good-reasons-to-do-agile-development.html
[5] Haag, Stephen; Maeve Cummings, Donald J. McCubbrey,
Pinsonneult, and Donovan (2006). "Phase 2: Analysis".
Information Management Systems for the Information Age.
McGraw-Hill Ryerson. ISBN 978-0072819472.
[6] Jennerich, Bill (November 1990). "Joint Application Design:
Business Requirements Analysis for Successful Re-Engineering".
http://www.bee.net/bluebird/jaddoc.htm. Retrieved 2009-02-06.
[7] Joint Application Design; Wikipedia
http://en.wikipedia.org/wiki/Joint_application_design
[8] Mei C.Yatco. “Joint Application Design/Development”
http://www.umsl.edu/~sauterv/analysis/JAD.html
[9] Frank Maurer & Sebastien Martel
Agile Software Development: An Industrial Case Study
University of Calgary
Department of Computer Science
http://fc-md.umd.edu/projects/Agile/Maurer.htm
28
[10] Mike Grant: Introduction to extreme Programming
http://www.acm.jhu.edu/peer-teach/xp/xp.pdf
[11] Jim Highsmith: Extreme programming
[12] Extreme Programming: Wikipedia
http://en.wikipedia.org/wiki/Extreme_Programming
[13] Lucas Layman , Laurie Williams, Lynn Cunningham
North Carolina University, Computer Science Department
http://collaboration.csc.ncsu.edu/laurie/Papers/ADC.pdf
[14] Ken Schwaber ; SCRUM Development Process
http://jeffsutherland.com/oopsla/schwapub.pdf
[15] Scrum in five minutes
http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf
[16] Mary Poppendieck: Lean Software Development (left)
http://www.poppendieck.com/pdfs/Lean_Software_Development.pdf
[17] Desari Ravi Kumar: Lean Software Development ( right)
http://www.projectperfect.com.au/downloads/Info/info_lean_development.pdf
[18] Lean Software Institute: Introduction to Lean Software Development
http://www.leansoftwareinstitute.com/art_ilsd.php
[19] Case study| Lean Software development
http://www.guidonps.com/ideas-and-resources/case-studies/information-technology/Loan%20Software%20Case%20Study.pdf
29