UNIT I 

SOFTWARE PROCESS AND AGILE DEVELOPMEN                 

                                               9
• Introduction to Software Engineering, Software Process,
Perspective and Specialized Process Models –Introduction to
Agility-Agile process-Extreme programming-XP Process.
Software Engineering:
• Software Engineering is the application of a systematic, disciplined,
quantifiable approach to the development, operation, and
maintenance of software; that is, the application of engineering to
software.
Characteristics of software:
• Software is developed or engineered
• Software doesn’t wear-out
• Although the industry is moving toward component-based
construction, most software continues to be custom built.
Difference between program and software

Program Software
Small in size Large in size
Single developer Team developer
Adopt development Systematic development
No proper documentation Well documentation
Software Myths:
• Software myths are beliefs about software and the process used to
build it.
Types
• Management Myths
• Customer Myths
• Practitioner’s Myths
Management Myths:
Myth 1:
• We already have a book that’s full of standards and procedures for building software.
Won’t that provide my people with everything they need to know?
• Reality:
• The book of standards may very well exist, but is it used?
• Are software practitioners aware of its existence?
• Does it reflect modern software engineering practice? Is it complete? Is it adaptable?
• Is it streamlined to improve time-to-delivery while still maintaining a focus on quality?
• In many cases, the answer to all of these questions is no.
Myth 2:
• If we get behind schedule, we can add more programmers and catch up.
• Reality:
• Software development is not a mechanistic process like manufacturing.
• As new people are added, people who were working must spend time educating the
newcomers, thereby reducing the amount of time spent on productive development
effort.
• People can be added but only in a planned and well-coordinated manner.
Myth 3:
• If I decide to outsource the software project to a third party, I can just relax and let that
firm build it.
• Reality:
• If an organization does not understand how to manage and control software projects
internally, it will invariably struggle when it outsources software projects.
Customer Myths:

Myth 1:
• A general statement of objectives is sufficient to begin writing programs—we can fill in
the details later.
• Reality:
• Although a comprehensive and stable statement of requirements is not always possible,
an ambiguous “statement of objectives” is a recipe for disaster.
• Unambiguous requirements are developed only through effective and continuous
communication between customer and developer.
Myth 2:
• Software requirements continually change, but change can be easily accommodated
because software is flexible.
• Reality:
• It is true that software requirements change, but the impact of change varies with the
time at which it is introduced.
• When requirements changes are requested early the cost impact is relatively small.
• However, as time passes, the cost impact grows rapidly—resources have been
committed, a design framework has been established, and change can cause upheaval
that requires additional resources and major design modification.
Practitioner’s Myths:
Myth 1:
• Once we write the program and get it to work, our job is done.
• Reality:
• Industry data indicate that between 60 and 80 percent of all effort expended on
software will be expended after it is delivered to the customer for the first time.
Myth 2:
• Until I get the program “running” I have no way of assessing its quality.
• Reality:
• One of the most effective software quality assurance mechanisms can be applied from
the inception of a project—the technical review.
• Software reviews are a “quality filter” that have been found to be more effective than
testing for finding certain classes of software defects.
Myth 3:
• The only deliverable work product for a successful project is the working program.
• Reality:
• A working program is only one part of a software configuration that includes many
elements.
• A variety of work products (e.g., models, documents, plans) provide a foundation for
successful engineering and, more important, guidance for software support.
 

Myth 4:
• Software engineering will make us create voluminous and unnecessary documentation
and will invariably slow us down.
• Reality:
• Software engineering is not about creating documents.
• It is about creating a quality product.
• Better quality leads to reduced rework.
• And reduced rework results in faster delivery times
A Layered Technology:
• Software engineering is a fully layered technology.
• To develop a software, we need to go from one layer to another.
• All these layers are related to each other and each layer demands the fulfillment of
the previous layer.
A quality Focus:
• Every organization is rest on its commitment to quality.
• Total quality management, Six Sigma, or similar continuous improvement culture and it is
this culture ultimately leads to development of increasingly more effective approaches to
software engineering.
• The foundation that supports software engineering is a quality focus.
Process:
• Foundation for SE is the Process Layer
• SE process is the GLUE that holds all the technology layers together and enables the timely
development of computer software.
• Process defines a framework that must be established for effective delivery of software
engineering technology.
• The software process forms the basis for management control of software projects and
establishes the context in which technical methods are applied, work products are
produced, milestones are established, quality is ensured, and change is properly managed.
Methods:
• Software engineering methods provide the technical aspects for
building software.
• Methods encompass a broad array of tasks that include
communication, requirements analysis, design modeling, program
construction, testing, and support.
• Software engineering methods rely on the set of modeling activities
and other descriptive techniques.
Tools:
• Software engineering tools provide automated or semi-automated
support for the process and the methods.
• When tools are integrated so that information created by one tool can
be used by another, a system for the support of software
development, called CASE (computer-aided software engineering), is
established.
Software Process
• A process is a collection of
• Activities
• actions
• tasks
• that are performed when some work product is to be created.
• An activity strives to achieve a broad objective
 (e.g., communication with stakeholders) and is applied regardless of the application
domain, size of the project, complexity of the effort, or degree of rigor with which software
engineering is to be applied.
• An action (e.g., architectural design) encompasses a set of tasks that produce a major work
product (e.g., an architectural design model).
• A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
produces a tangible outcome.
 Each of these activities, actions, and tasks reside within a framework or model that defines their relationship
with the process and with one another.
• A process framework establishes the foundation for a complete
software engineering process by identifying a small number of
framework activities that are applicable to all software projects,
regardless of their size or complexity.
• In addition, the process framework encompasses a set of umbrella
activities that are applicable across the entire software process.
• A generic process framework for software engineering encompasses
five activities:
Communication
Planning
Modelling
Construction
Deployment
Communication.
• Before any technical work can commence, communicate and
collaborate with the customer (and other Stakeholder)
• The intent is to understand stakeholders’ objectives for the project and
to gather requirements that help define software features and
functions.
Planning.
the planning activity creates a “map” that helps guide the team as it
makes the journey.
• software project plan—defines the software engineering work by
describing the technical tasks to be conducted, the risks that are likely,
the resources that will be required, the work products to be produced,
and a work schedule.
Modeling.
• A software engineer creating models to better understand
software requirements and the design that will achieve those
requirements.
Construction. This activity combines code generation (either manual or
automated) and the testing that is required to uncover errors in the
code.
• Deployment. The software (as a complete entity or as a partially
completed increment) is delivered to the customer who evaluates the
delivered product and provides feedback based on the evaluation.
Umbrella Activities
• Software engineering process framework activities are complemented by a number of umbrella
activities.
• In general, umbrella activities are applied throughout a software project and help a software
team manage and control progress, quality, change, and risk.
• Typical umbrella activities include:
Software project tracking and control—allows the software team to assess progress against the project
plan and take any necessary action to maintain the schedule.
Risk management—assesses risks that may affect the outcome of the project or the quality of the product.
Software quality assurance—defines and conducts the activities required to ensure software quality.
Technical reviews—assesses software engineering work products in an effort to uncover and remove errors
before they are propagated to the next activity.
Measurement—defines and collects process, project, and product measures that assist the team in
delivering software that meets stakeholders’ needs; can be used in conjunction with all other framework and
umbrella activities.
Software configuration management—manages the effects of change
throughout the software process.
Reusability management—defines criteria for work product reuse (including
software components) and establishes mechanisms to achieve reusable
components.
Work product preparation and production—encompasses the activities
required to create work products such as models, documents, logs, forms,
and lists.
Process Flow
• Process flow—describes how the framework activities and the actions and tasks that
occur within each framework activity are organized with respect to sequence and
time.
• A linear process flow executes each of the five framework activities in sequence,
beginning with communication and culminating with deployment.
• An iterative process flow repeats one or more of the activities before proceeding to
the next.
• An evolutionary process flow executes the activities in a “circular” manner. Each circuit
through the five activities leads to a more complete version of the software.
• A parallel process flow executes one or more activities in parallel with other activities.
Prescriptive Process Models

• Prescriptive process models were originally proposed to bring order to the chaos of
software development.
• Traditional models have brought a certain amount of useful structure to software
engineering work and have provided a reasonably effective road map for software
teams.
• Following are prescriptive process models:
• Waterfall model
• Incremental Model
• RAD Model
• Evolutionary Process Model
• Prototype Model
• Spiral Model
• Concurrent Process Model
Waterfall Process Model
• The waterfall model, sometimes called the classic life cycle, suggests a
systematic, sequential approach to software development that begins
with customer specification of requirements and progresses through
planning, modeling, construction, and deployment, culminating in
ongoing support of the completed software
Limitations:
• The nature of the requirements will not change very much during development;
• The model implies that you should attempt to complete a given stage before
moving on to the next stage.
• Does not account for the fact that requirements constantly change.
• It also means that customers cannot use anything until the entire system is
complete.
• The model implies that once the product is finished, everything else is
maintenance.
• Surprises at the end are very expensive
• Some teams sit ideal for other teams to finish
• Therefore, this model is only appropriate when the requirements are well-
understood and changes will be fairly limited during the design process.
When to use waterfall model?
• Requirements are very well known, clear and fixed
• Product definition is stable
• Technology is understood
• There are no ambiguous requirements
• Ample resources with required expertise are available freely
• The project is short
Incremental Process Model
• The incremental model combines elements of linear and parallel process flows.
• The incremental model applies linear sequences in a staggered fashion as calendar time progresses.
Each linear sequence produces deliverable “increments” of the software
Advantages:
• Generates working software quickly and early during the software life cycle.
• This model is more flexible – less costly to change scope and requirements.
• It is easier to test and debug during a smaller iteration.
• In this model customer can respond to each built.
• Lowers initial delivery cost.
• Easier to manage risk because risky pieces are identified and handled during iteration.
Disadvantages:
• Needs good planning and design.
• Needs a clear and complete definition of the whole system before it can be broken down and built
incrementally.
• Total cost is higher than waterfall.
When to use
• This model can be used when the requirements of the complete
system are clearly defined and understood.
• Major requirements must be defined; however, some details can
evolve with time.
• There is a need to get a product to the market early.
• A new technology is being used.
• Resources with needed skill set are not available.
• There are some high risk features and goals.
Rapid Application Development model
• It is a type of incremental model. In RAD model the components or
functions are developed in parallel as if they were mini projects.
• The developments are time boxed, delivered and then assembled into
a working prototype.
• This can quickly give the customer something to see and use and to
provide feedback regarding the delivery and their requirements.
• Advantages:
• Reduced development time.
• Increases reusability of components
• Quick initial reviews occur
• Encourages customer feedback
• Integration from very beginning solves a lot of integration issues.
• Disadvantages:
• For large but scalable projects RAD requires sufficient human resources.
• Projects fail if developers and customers are not committed in a much
shortened time-frame.
• Problematic if system cannot be modularized.
• Not appropriate when technical risks are high (heavy use of new technology).
When to use RAD model?
• RAD should be used when there is a need to create a system that can
be modularized in 2-3 months of time.
• It should be used if there’s high availability of designers for modeling
and the budget is high enough to afford their cost along with the cost
of automated code generating tools.
• RAD SDLC model should be chosen only if resources with high
business knowledge are available and there is a need to produce the
system in a short span of time (2-3 months).
Prototype process model
• The basic idea here is that instead of freezing the requirements before a design or
coding can proceed, a throwaway prototype is built to understand the
requirements.
• This prototype is developed based on the currently known requirements.
• By using this prototype, the client can get an “actual feel” of the system, since the
interactions with prototype can enable the client to better understand the
requirements of the desired system.
• Prototyping is an attractive idea for complicated and large systems for which there
is no manual process or existing system to help determining the requirements.
• The prototype are usually not complete systems and many of the details are not
built in the prototype. The goal is to provide a system with overall functionality.
• Advantages:
• Users are actively involved in the development
• Since in this methodology a working model of the system is provided,
the users get a better understanding of the system being developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily
• Confusing or difficult functions can be identified
Disadvantages:
• Leads to implementing and then repairing way of building systems.
• Practically, this methodology may increase the complexity of the
system as scope of the system may expand beyond original plans.
• Incomplete application may cause application not to be used as the
full system was designed.
• When to use Prototype Model?
• Prototype model should be used when the desired system needs to
have a lot of interaction with the end users.
• Typically, online systems, web interfaces have a very high amount of
interaction with end users, are best suited for Prototype model. It
might take a while for a system to be built that allows ease of use and
needs minimal training for the end user.
• Prototyping ensures that the end users constantly work with the
system and provide a feedback which is incorporated in the prototype
to result in a useable system. They are excellent for designing good
human computer interface systems.
Spiral process model
• It was originally proposed by Barry Boehm, the spiral model is an evolutionary software process
model that couples the iterative nature of prototyping with the controlled and systematic
aspects of the waterfall model.
• It provides the potential for rapid development of increasingly more complete versions of the
software.
• The spiral development model is a risk-driven process model generator that is used to guide
multi- stakeholder concurrent engineering of software intensive systems.
• It has two main distinguishing features. One is a cyclic approach for incrementally growing a
system’s degree of definition and implementation while decreasing its degree of risk.
• The other is a set of anchor point milestones for ensuring stakeholder commitment to feasible
and mutually satisfactory system solutions
• A spiral model is divided into a set of framework activities defined by the software engineering
team
• The software team performs activities that are implied by a circuit
around the spiral in a clockwise direction beginning at the center.
• Anchor point milestones- a combination of work products and
conditions that are attained along the path of the spiral- are noted for
each evolutionary pass.
 The first circuit around the spiral might result in the development of a product specification;
subsequent passes around the spiral might be used to develop a prototype and then progressively more
sophisticated versions of the software.
 Each pass through the planning region results in adjustments to the project plan.
 Cost and schedule are adjusted based on feedback derived from the customer after delivery.
 In addition, the project manager adjusts the planned number of iterations required to complete the
software.
• Unlike other model, the spiral model can be adapted to apply throughout the life of
the computer software.
• Therefore, the first circuit around the spiral might represent a “concept
development project” that starts at the core of the spiral and continues for multiple
iterations until concept development is complete
• If the concept is to be developed into an actual product, the process proceeds
outward on the spiral and a “new product development project” commences.
• Is a realistic approach to the development of large-scale systems and software
• Uses prototyping as a risk reduction mechanism
• Maintains systematic stepwise approach with iterative framework
• Demands a direct consideration of technical risk at all stages of the project
• Advantages:
• High amount of risk analysis hence, avoidance of Risk is enhanced.
• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added at a later date.
• Software is produced early in the software life cycle.
• Disadvantages:
• Can be a costly model to use.
• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the risk analysis phase.
• Doesn’t work well for smaller projects.
When to use spiral process model?
• When costs and risk evaluation is important for medium to high-risk
projects.
• Long-term project commitment unwise because of potential changes
to economic priorities
• Users are unsure of their needs.
• Requirements are complex
• New product line Significant changes are expected (research and
exploration)
Concurrent Process Model
• The concurrent development model, sometimes called concurrent engineering,
allows a software team to represent iterative and concurrent elements of any of
the process models.
• For example, the modeling activity defined for the spiral model is accomplished by
invoking one or more of the following software engineering actions: prototyping,
analysis, and design.
• The activity—modeling—may be in any one of the states noted at any given time.
• Similarly, other activities, actions, or tasks (e.g., communication or construction)
can be represented in an analogous manner.
• All software engineering activities exist concurrently but reside in different states.
Specialized Process Models
• This model take on many of the characteristics of one or more of the
traditional models.
• However, these models tend to be applied when a specialized or
narrowly defined software engineering approach is chosen.
• Component based development
• The formal method model
• Aspect oriented software development.
Component Based Development
• Commercial off-the-shelf (COTS) software components, developed by
vendors who offer them as products
• provide targeted functionality with well-defined interfaces that
enable the component to be integrated into the software that is to be
built.
• The component-based development model incorporates many of the
characteristics of the spiral model.
• It is evolutionary in nature, demanding an iterative approach to the
creation of software.
• However, the component-based development model constructs
applications from prepackaged software components.
• The component-based development model incorporates the
following steps:
• Available component-based products are researched and evaluated for
the application domain in question.
• Component integration issues are considered.
• A software architecture is designed to accommodate the components.
• Components are integrated into the architecture.
• Comprehensive testing is conducted to ensure proper functionality.
• The component-based development model leads to software reuse,
and reusability provides software engineers with a number of
measurable benefits.
The formal methods model
• The formal methods model encompasses a set of activities that leads
to formal mathematical specification of computer software.
• Formal methods enable you to specify, develop, and verify a
computer-based system by applying a rigorous, mathematical
notation.
• A variation on this approach, called cleanroom software engineering
is currently applied by some software development organizations.
• When formal methods are used during development, they provide a
mechanism for eliminating many of the problems that are difficult to
overcome using other software engineering paradigms.
• Ambiguity, incompleteness, and inconsistency can be discovered and
corrected more easily through the application of mathematical
analysis.
• When formal methods are used during design, they serve as a basis
for program verification and therefore enable you to discover and
correct errors that might otherwise go undetected.
• the formal methods model offers the promise of defect-free software.
• Challenges:
• The development of formal models is currently quite time consuming and
expensive.
• Because few software developers have the necessary background to apply
formal methods, extensive training is required.
• It is difficult to use the models as a communication mechanism for technically
unsophisticated customers.
Aspect-oriented Software Development
• Aspect-oriented software development (AOSD) is a software design
solution that helps address the modularity issues that are not
properly resolved by other software approaches, like procedural,
structured and object-oriented programming (OOP).
• AOSD complements, rather than replaces, these other types of
software approaches.
• AOSD is also known as aspect-oriented programming (AOP) is a new
software engineering paradigm that provides a process and
methodological approach for defining, specifying, designing, and
constructing aspects.
• Grundy provides further discussion of aspects in the context of what he
calls aspect-oriented component engineering (AOCE):
AOCE uses a concept of horizontal slices through vertically-decomposed
software components, called “aspects,” to characterize cross-cutting
functional and non-functional properties of components.
 Common, systemic aspects include user interfaces, collaborative work,
distribution, persistency, memory management, transaction processing,
security, integrity and so on.
Components may provide or require one or more “aspect details” relating
to a particular aspect, such as a viewing mechanism, extensible
affordance and interface kind (user interface aspects); event generation,
transport and receiving (distribution aspects); data store/retrieve and
indexing (persistency aspects); authentication, encoding and access rights
(security aspects); transaction atomicity, concurrency control and logging
strategy (transaction aspects); and so on.
Each aspect detail has a number of properties, relating to functional
and/or non-functional characteristics of the aspect detail.
Agile Software Engineering
• What is it?
• Agile software engineering combines a philosophy and a set of
development guidelines.
• The philosophy encourages customer satisfaction and early
incremental delivery of software; small, highly motivated project
teams; informal methods; minimal software engineering work
products; and overall development simplicity.
• The development guidelines stress delivery over analysis and design
(although these activities are not discouraged), and active and
continuous communication between developers and customers.
• What does it?
• Software engineers and other project stakeholders (managers,
customers, end users) work together on an agile team—a team that is
self-organizing and in control of its own destiny. An agile team fosters
communication and collaboration among all who serve on it.
• An agile team is a nimble team able to appropriately respond to changes.
• Change is what software development is very much about.
• Changes in the software being built, changes to the team members, changes
because of new technology, changes of all kinds that may have an impact on the
product they build or the project that creates the product.
• Support for changes should be built-in everything we do in software, something we
embrace because it is the heart and soul of software.
• An agile team recognizes that software is developed by individuals working in
teams and that the skills of these people,
• their ability to collaborate is at the core for the success of the project.
• Agility is dynamic, content specific, aggressively change embracing, and
growth oriented
• It encourages team structures and attitudes that make communication
(among team members, between technologists and business people,
between software engineers and their managers) more simplistic.
• It emphasizes rapid delivery of operational software and de-emphasizes
the importance of intermediate work products.
• It recognizes that planning in an uncertain world has its limits and that a
project plan must be flexible.
• Agility can be applied to any software process.
Agile Process:
• Any agile software process is characterized in a manner that
addresses a number of key assumptions
• It is difficult to predict in advance which software requirements will persist
and which will change. It is equally difficult to predict how customer priorities
will change as the project proceeds.
• For many types of software, design and construction are interleaved. That is,
both activities should be performed in tandem so that design models are
proven as they are created. It is difficult to predict how much design is
necessary before construction is used to prove the design.
• Analysis, design, construction, and testing are not as predictable as we might
like.
Agility Principles
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the
shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust
them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-
to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity—the art of maximizing the amount of work not done—is essential.
• The best architectures, requirements, and designs emerge from self– organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly.
Agile Process Models:

• Extreme Programming (XP)

• Adaptive Software Development (ASD)
• Dynamic Systems Development Method (DSDM)
• Scrum
• Crystal
• Feature Driven Development (FDD)
• Agile Modeling (AM)
Agile Process Model
• Agile SDLC model is a combination of iterative and incremental
process models with focus on process adaptability and customer
satisfaction by rapid delivery of working software product.
• Agile Methods break the product into small incremental builds.
• Every iteration involves cross functional teams working
simultaneously on various areas like planning, requirements analysis,
design, coding, unit testing, and acceptance testing.
Advantages:
• Customer satisfaction by rapid, continuous delivery of useful software.
• Customers, developers and testers constantly interact with each other.
• Close, daily cooperation between business people and developers.
• Continuous attention to technical excellence and good design.
• Regular adaptation to changing circumstances.
• Even late changes in requirements are welcomed
Disadvantages:
• In case of some software, it is difficult to assess the effort required at the beginning of the software
development life cycle.
• There is lack of emphasis on necessary designing and documentation.
• The project can easily get taken off track if the customer representative is not clear what final outcome
that they want.
• Only senior programmers are capable of taking the kind of decisions required during the development
process.
Extreme Programming
• It is most widely used agile process model.
• XP uses an object-oriented approach as its preferred development
paradigm.
• Variant of XP called Industrial XP(IXP) has been proposed
• IXP refines XP and targets the agile process specifically for use within
large organizations.
XP values
• 5 values are derined for all work performed as part of XP.
• 5 values are
- communication, simplicity, feedback, courage and respect.
Communication:
• Between software engineers and other stakeholders
Simplicity:
• XP restricts developers to design only for immediate needs.
• Intent is to create a simple design that can be easily implemented.
• Later can be refactored
Feedback:
• Derived from three sources: implemented software, customer and other
software team members.
Courage
• Better word is discipline
• Agile team must have discipline to design for today recognizing that future
requirements may change dramatically.
Respect:
• Agile team inculcates respect among it members between other
stakeholders and team members and indirectly for the software itself.
XP process
• Uses object oriented approach
• it defines four framework activities Planning, Design, Coding, and Testing.
Planning
• Also called planning game begins with listening- requirement gathering
activity.
• Listening leads to creation of a set of stories (also called user stories)
• Each story is written by the customer and is placed on an index card
• The customer assigns a value (i.e. a priority) to the story
• Agile team assesses each story and assigns a cost
• Stories are grouped to for a deliverable increment
• A commitment is made on delivery date
• After the first increment “project velocity” is used to help define subsequent
delivery dates for other increments
Design
• Follows the keep it simple principle
• Encourage the use of CRC (class-responsibility-collaborator) cards
• For difficult design problems, suggests the creation of “spike
solutions”—a design prototype
• Encourages “refactoring”—an iterative refinement of the internal
program design
• Design occurs both before and after coding commences
Coding
• Recommends the construction of a series of unit tests for each of the stories before coding commences
• Encourages “pair programming”
• Developers work in pairs, checking each other's work and providing the support to always do a good job.
• Mechanism for real-time problem solving and real-time quality assurance.
• Refactoring is the process of changing a software system in such a way that it does not alter the external
behavior of the code yet improves the internal structure.
• It is a disciplined way to clean up code [and modify/simplify the internal design] that minimizes the
chances of introducing bugs. In essence, when you refactor you are improving the design of the code
after it has been written.

• Keeps the developers focused on the problem at hand

• Needs continuous integration with other portions (stories) of the s/w, which provides a “smoke testing”
environment
Testing
• Unit tests should be implemented using a framework to make testing
automated. This encourages a regression testing strategy.
• Integration and validation testing can occur on a daily basis
• Acceptance tests, also called customer tests, are specified by the
customer and executed to assess customer visible functionality
• Acceptance tests are derived from user stories
Adaptive Software Development (ASD)

• Adaptive Software Development (ASD) is a technique for building

complex software and systems. ASD focus on human collaboration
and team self-organization.
• ASD incorporates three phases Speculation, Collaboration, and
Learning.
Speculation
• Speculate” refers to the planning paradox—outcomes are
unpredictable, therefore, endless suppositions on a product’s look
and feel are not likely to lead to any business value.
• The big idea behind speculate is when we plan a product to its
smallest detail as in a requirements up front Waterfall variant, we
produce the product we intend and not the product the customer
needs.
• In the ASD mindset, planning is to speculation as intention is to need.
Collaboration
• Collaboration represents a balance between managing the doing and
creating and maintaining the collaborative environment.”
• Speculation says we can’t predict outcomes. If we can’t predict
outcomes, we can’t plan. If we can’t plan, traditional project
management theory suffers.
• Collaboration weights speculation in that a project manager plans the
work between the predictable parts of the environment and adapts to
the uncertainties of various factors—stakeholders, requirements,
software vendors, technology, etc.
Learning
• “Learning” cycles challenge all stakeholders and project team
members.
• Based on short iterations of design, build and testing, knowledge
accumulates from the small mistakes we make due to false
assumptions, poorly stated or ambiguous requirements or
misunderstanding the stakeholders’ needs.
• Correcting those mistakes through shared learning cycles leads to
greater positive experience and eventual mastery of the problem
domain.
Scrum

• Scrum (the name is derived from an activity that occurs during a rugby match) is an
agile software development method that was conceived by Jeff Sutherland and his
development team in the early 1990s.
• Scrum principles are consistent with the agile manifesto and are used to guide
development activities within a process that incorporates the five framework
activities: requirements, analysis, design, evolution, and delivery.
• Within each framework activity, work tasks occur within a process pattern called a
sprint.
• The work conducted within a sprint (the number of sprints required for each
framework activity will vary depending on product complexity and size) is adapted to
the problem at hand and is defined and often modified in real time by the Scrum team
• Scrum emphasizes the use of a set of software process patterns that have proven
effective for projects with tight timelines, changing requirements, and business
criticality.
• Each of these process patterns defines a set of development actions: Backlog—a
prioritized list of project requirements or features that provide business value for
the customer.
• Items can be added to the backlog at any time (this is how changes are
introduced).
• The product manager assesses the backlog and updates priorities as required.
• Sprints—consist of work units that are required to achieve a requirement defined
in the backlog that must be fit into a predefined time-box14 (typically 30 days).
• Changes (e.g., backlog work items) are not introduced during the sprint. Hence,
the sprint allows team members to work in a short-term, but stable environment.
• Scrum meetings—are short (typically 15 minutes) meetings held daily by the Scrum
team. Three key questions are asked and answered by all team members [Noy02]:
• What did you do since the last team meeting?
• What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting?
• A team leader, called a Scrum master, leads the meeting and assesses the
responses from each person.
• The Scrum meeting helps the team to uncover potential problems as early as
possible. Also, these daily meetings lead to “knowledge socialization”
• Demos—deliver the software increment to the customer so that functionality that
has been implemented can be demonstrated and evaluated by the customer.
• It is important to note that the demo may not contain all planned functionality, but
rather those functions that can be delivered within the time-box that was
established.
Dynamic System Development Method
(DSDM)
• The Dynamic Systems Development Method is an agile software development approach
that “provides a framework for building and maintaining systems which meet tight time
constraints through the use of incremental prototyping in a controlled project
environment”
• The DSDM philosophy is borrowed from a modified version of the Pareto principle—80
percent of an application can be delivered in 20 percent of the time it would take to
deliver the complete (100 percent) application
• .DSDM is an iterative software process in which each iteration follows the 80 percent rule.
• That is, only enough work is required for each increment to facilitate movement to the
next increment.
• The remaining detail can be completed later when more business requirements are
known or changes have been requested and accommodated.
• DSDM life cycle that defines three different iterative cycles, preceded by
two additional life cycle activities:
• Feasibility study—establishes the basic business requirements and
constraints associated with the application to be built and then assesses
whether the application is a viable candidate for the DSDM process.
• Business study—establishes the functional and information requirements
that will allow the application to provide business value; also, defines the
basic application architecture and identifies the maintainability
requirements for the application.
• Functional model iteration—produces a set of incremental prototypes
that demonstrate functionality for the customer.
• Design and build iteration—revisits prototypes built during functional
model iteration to ensure that each has been engineered in a manner that
will enable it to provide operational business value for end users.
• Implementation—places the latest software increment into the
operational environment.
• DSDM can be combined with XP to provide a combination approach
that defines a solid process model (the DSDM life cycle) with the nuts
and bolts practices (XP) that are required to build software
increments.
• In addition, the ASD concepts of collaboration and self-organizing
teams can be adapted to a combined process model.
Crystal
• Alistair Cockburn and Jim Highsmith created the Crystal family of agile methods in order to achieve a
software development approach that puts a premium on “maneuverability” during what Cockburn
characterizes as “a resource limited, cooperative game of invention and communication, with a primary goal
of delivering useful, working software and a secondary goal of setting up for the next game”
• To achieve maneuverability, Cockburn and Highsmith have defined a set of methodologies, each with core
elements that are common to all, and roles, process patterns, work products, and practice that are unique to
each.
• The Crystal methodology is one of the most lightweight, adaptable approaches to software development.
• Crystal is actually comprised of a family of agile methodologies such as Crystal Clear, Crystal Yellow, Crystal
Orange and others, whose unique characteristics are driven by several factors such as team size, system
criticality, and project priorities.
• This Crystal family addresses the realization that each project may require a slightly tailored set of policies,
practices, and processes in order to meet the project‘s unique characteristics.
• Several of the key tenets of Crystal include teamwork, communication, and simplicity, as well as reflection to
frequently adjust and improve the process.
• Like other agile process methodologies, Crystal promotes early, frequent delivery of working software, high
user involvement, adaptability, and the removal of bureaucracy or distractions.
Feature Driven Development (FDD)
• Feature Driven Development (FDD) was originally conceived by Peter
Coad and his colleagues as a practical process model for object-
oriented software engineering.
• Stephen Palmer and John Felsing have extended and improved Coad’s
work, describing an adaptive, agile process that can be applied to
moderately sized and larger software projects.
• Like other agile approaches, FDD adopts a philosophy that
• (1) emphasizes collaboration among people on an FDD team;
• (2) manages problem and project complexity using feature-based
decomposition followed by the integration of software increments, and
• (3) communication of technical detail using verbal, graphical, and text-
based means.
• In the context of FDD, a feature “is a client-valued function that can be
implemented in two weeks or less”
• The emphasis on the definition of featuresprovides the following benefits:
• Because features are small blocks of deliverable functionality, users can
describe them more easily; understand how they relate to one another
more readily; and better review them for ambiguity, error, or omissions.
 Features can be organized into a hierarchical business-related grouping.
Since a feature is the FDD deliverable software increment, the team
develops operational features every two weeks.
Because features are small, their design and code representations are
easier to inspect effectively.
Project planning, scheduling, and tracking are driven by the feature
hierarchy, rather than an arbitrarily adopted software engineering task
set.
• Coad and his colleagues [Coa99] suggest the following template for
defining a feature:
<action> the <result> <by for of to> a(n) <object>
• where an <object> is “a person, place, or thing (including roles, moments
in time or intervals of time, or catalog-entry-like descriptions).”
Example:
• Add the product to shopping cart
• Display the technical-specifications of the product
• Store the shipping-information for the customer
• A feature set groups related features into business-related categories
and is defined as:
<action><-ing> a(n) <object>
For example:
Making a product sale is a feature set that would encompass the
features noted earlier and others.
The FDD approach defines five “collaborating” framework activities (in FDD these are called “processes”) as
shown in Figure.
Lean Software Development
• LSD has adapted the principles of lean manufacturing to the world of software engineering.
• The lean principles that inspire the LSD process can be summarized as eliminate waste, build quality in,
create knowledge, defer commitment, deliver fast, respect people, and optimize the whole.
• Each of these principles can be adapted to the software process.
• For example, eliminate waste within the context of an agile software project can be interpreted to mean
• (1) adding no extraneous features or functions,
• (2) assessing the cost and schedule impact of any newly requested requirement,
• (3) removing any superfluous process steps,
• (4) establishing mechanisms to improve the way team members find information,
• (5) ensuring the testing finds as many errors as possible,
• (6) reducing the time required to request and get a decision that affects the software or the process that is
applied to create it, and
• (7) streamlining the manner in which information is transmitted to all stakeholders involved in the process
Agile Modeling (AM)
• Agile Modeling (AM) is a practice-based methodology for effective modeling
and documentation of software-based systems.
• Simply put, Agile Modeling (AM) is a collection of values, principles, and
practices for modeling software that can be applied on a software
development project in an effective and light-weight manner.
• Although AM suggests a wide array of “core” and “supplementary”
modeling principles, those that make AM unique are:
• Use multiple models. There are many different models and notations that
can be used to describe software. AM suggests that to provide needed
insight, each model should present a different aspect of the system and only
those models that provide value to their intended audience should be used.
• Agile modeling adopts all of the values that are consistent with the
agile manifesto. The agile modeling philosophy recognizes that an
agile team must have the courage to make decisions that may cause it
to reject a design and refactor.
• The team must also have the humility to recognize that technologists
do not have all the answers and that business experts and other
stakeholders should be respected and embraced.
• Although AM suggests a wide array of “core” and “supplementary”
modeling principles, those that make AM unique are
• Model with a purpose: A developer who uses AM should have a
specific goal in mind before creating the model.
• Use multiple models. There are many different models and notations that
can be used to describe software. Only a small subset is essential for most
projects.
• Travel light. As software engineering work proceeds, keep only those
models that will provide long-term value and jettison the rest.
• Content is more important than representation. Modeling should impart
information to its intended audience. A syntactically perfect model that
imparts little useful content is not as valuable as a model with flawed
notation that nevertheless provides valuable content for its audience.
• Know the models and the tools you use to create them. Understand the
strengths and weaknesses of each model and the tools that are used to
create it.
• Adapt locally. The modeling approach should be adapted to the needs of
the agile team.
Agile Unified Process (AUP)
• The Agile Unified Process (AUP) adopts a “serial in the large” and
“iterative in the small” philosophy for building computer-based
systems.
• By adopting the classic UP phased activities—inception, elaboration,
construction, and transition—AUP provides a serial overlay (i.e., a
linear sequence of software engineering activities) that enables a
team to visualize the overall process flow for a software project.
• However, within each of the activities, the team iterates to achieve
agility and to deliver meaningful software increments to end users as
rapidly as possible.
• Each AUP iteration addresses the following activities:
• Modeling. UML representations of the business and problem domains are created. However, to
stay agile, these models should be “just barely good enough” to allow the team to proceed.
• Implementation. Models are translated into source code.
• Testing. Like XP, the team designs and executes a series of tests to uncover errors and ensure
that the source code meets its requirements.
• Deployment. focuses on the delivery of a software increment and the acquisition of feedback
from end users.
• Configuration and project management. In the context of AUP, configuration management
addresses change management, risk management, and the control of any persistent work
products that are produced by the team.
• Environment management. Environment management coordinates a process infrastructure that
includes standards, tools, and other support technology available to the team.