Software Engineering (PCCO6010T)

Credits : 03
Examination Scheme
Term Test : 15 Marks
Teacher Assessment : 20 Marks
End Sem Exam : 65 Marks
Total Marks : 100 Marks

Prerequisite:
1. Concepts of Object Oriented Programming & Methodology.
2. Knowledge of developing applications with front end & back end connectivity.

By-Prof.Mr. P. R. Patil
• Course Objectives: To provide the knowledge of Standard Software Engineering discipline.

By-Prof.Mr. P. R. Patil
 Unit-I
10 Hrs.

• Introduction to Software Engineering and Process Models: Nature of Software, Software

Engineering, Software Process, CMM, Generic Process Model.
• Prescriptive Process Models: The Waterfall Model, V Model.
• Incremental Process Model: Incremental Model.
• Evolutionary Process Models: Prototyping Paradigm, The Spiral Model.
• Concurrent Process Models: Concurrent Process Model.
• The Unified Process
• Agile Methodology: Agility Principals, Agile Process Models: Extreme Programming (XP), Adaptive
Software Development (ASD), Dynamic Systems Development Method (DSDM), Scrum, Crystal, Feature
Driven Development (FDD), Agile Modeling (AM), Kanban Model.

By-Prof.Mr. P. R. Patil
 General definition of Software Engineering
Software engineering involves a process, a collection
of methods (practice) and an array(collection) of
tools that allow professionals to build high quality
computer software.

The IEEE definition of Software Engineering

(1) The application of a systematic, disciplined,
quantifiable approach to the development, operation,
and maintenance of software; that is, the application
of engineering to software.
(2) The study of approaches as in (1).

By-Prof.Mr. P. R. Patil
 THE NATURE OF SOFTWARE
Defining Software
Software is: (1) instructions (computer programs) that when executed provide
desired features, function, and performance; (2) data structures that enable
the programs to effectively manipulate information, and (3) descriptive
information in both hard copy and virtual forms that describes the operation
and use of the programs.
software characteristics
1. Software is developed or engineered; it is not manufactured in the classical sense.
2. Although the industry is moving toward component-based construction, most software
continues to be custom built.
3. Software doesn’t “wear out.” But it does deteriorate!
4. Although the industry is moving toward component-based
construction, most software continues to be custom built.
By-Prof.Mr. P. R. Patil
 Figure 1: Failure curve
for hardware

Figure 1.2: Failure curves

for software

By-Prof.Mr. P. R. Patil
Software Application Domains
• System software
a collection of programs written to service other programs. Some system software (e.g., compilers, editors,
and file management utilities) processes complex, but determinate, information structures. Other systems
applications (e.g., operating system components, drivers, networking software, telecommunications
processors) process largely indeterminate data.
• Application software
stand-alone programs that solve a specific business need. Applications in this area
process business or technical data in a way that facilitates business operations or
management/technical decision making

By-Prof.Mr. P. R. Patil
• Engineering/scientific software
characterized by “number crunching” algorithms. Computer-aided design, system simulation, and other
interactive applications have begun to take on real-time and even system software characteristics.
• Embedded software
software—resides within a product or system and is used to implement and control features and
functions for the end user and for the system itself
• Product-line software
designed to provide a specific capability for use by many different customers. Product-line software can
focus on a limited and esoteric marketplace (e.g., inventory control products)
• Web applications
called “WebApps,” this network-centric software category spans a wide array of applications. In their
simplest form, WebApps can be little more than a set of linked hypertext files that present information
using text and limited graphics

By-Prof.Mr. P. R. Patil
• Artificial intelligence software
- makes use of nonnumerical algorithms to solve complex problems that are not amenable to
computation or straightforward analysis. Applications within this area include robotics, expert systems,
pattern recognition

By-Prof.Mr. P. R. Patil
New Challenges
• Open-world computing
• Netsourcing
• Open source
Legacy software (A poor quality software)
• Some other programs are older, in some cases much older.
• Legacy software systems . . . were developed decades ago and have been continually
modified to meet changes in business requirements and computing platforms. The
production of such systems is causing headaches for large organizations who find them
costly to maintain and risky to evolve.

By-Prof.Mr. P. R. Patil
 Legacy Software
• Many legacy systems remain supportive to core business functions and are
‘essential’ to the business. What to do?
• What types of changes are made to legacy systems?
 The software must be adapted to meet the needs of new computing environments or technology.
 The software must be enhanced to implement new business requirements.
 The software must be extended to make it interoperable with other more modern systems or
databases.
 The software must be re-architected to make it feasible within a network environment.

By-Prof.Mr. P. R. Patil
 THE SOFTWARE PROCESS
A process is a collection of activities, actions, and tasks that are performed when some work product is to be
created.
A generic process framework for software engineering encompasses five activities:
 Communication
important to communicate and collaborate with the customer and other stakeholders. The intent is to
understand stakeholders’ objectives for the project and to gather requirements
 Planning
planning activity creates a “map” that helps, guide the. The map—called a software project plan—defines
the software engineering work by describing the technical tasks to be conducted
 Modeling
creating models to better understand software requirements and the design that will achieve
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

By-Prof.Mr. P. R. Patil
 Software engineering process framework activities are complemented by a number of umbrella activities
 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.
 Technical reviews
assesses software engineering work products in an effort to uncover and remove errors before they are
propagated to the next activity.
 Software quality assurance
defines and conducts the activities required to ensure software quality.
 Measurement
Measurement—defines and collects process, project, and product measures that assist the team in
delivering software that meets stakeholders’ needs

By-Prof.Mr. P. R. Patil
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.

By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
 Process Pattern

• Pattern Name
Initial context-Describes the conditions under which
• Forces the pattern applies.
• Types Problem
• Stage pattern
• Task pattern Solution-Describes how to implement the pattern
• Phase pattern successfully

Resulting Context-Describes the conditions that will

result once the pattern has been successfully
implemented
Related Patterns
Known Uses and Examples

By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
 Process Assessment and Improvement
• Process patterns must be coupled with solid software engineering practice
• The process itself can be assessed to ensure that it meets a set of basic process criteria
that is essential for a successful software engineering.
• A number of different approaches to software process assessment
• Standard CMMI Assessment Method for Process Improvement(SCAMPI)- initiating, diagnosing,
establishing, acting, and learning
• CMM-Based Appraisal for Internal Process Improvement (CBA IPI)-
• SPICE (ISO/IEC15504)
• ISO 9001:2000 for Software

By-Prof.Mr. P. R. Patil
 SOFTWARE ENGINEERING PRACTICE
The Essence of Practice
• Understand the problem (communication and analysis).
• Plan a solution (modeling and software design).
• Carry out the plan (code generation).
• Examine the result for accuracy (testing and quality assurance).
General Principles
1. The Reason It All Exists
-A software system exists for one reason: to provide value to its users . “Does this add
real value to the system?” If the answer is “no,” don’t do it.
2. KISS (Keep It Simple, Stupid!)
All design should be as simple as possible, but no simpler. This facilitates having a more
easily understood and easily maintained system.
3. Maintain the Vision
A clear vision is essential to the success of a software project
By-Prof.Mr. P. R. Patil
4. What You Produce, Others Will Consume
always specify, design, and implement knowing someone else will have to understand what you are doing
5. Be Open to the Future
system with a long lifetime has more value. systems must be ready to adapt to these and other changes.
Never design yourself into a corner. Always ask “what if,” and prepare for all possible answers by creating
systems that solve the general problem.
6. Plan Ahead for Reuse
Reuse saves time and effort. Achieving a high level of reuse is arguably the hardest goal to accomplish in
developing a software system. Planning ahead for reuse reduces the cost and increases the value of both
the reusable components and the systems into which they are incorporated.
7. Think!
Placing clear, complete thought before action almost always produces better results. When you think about
something, you are more likely to do it right. You also gain knowledge about how to do it right again

By-Prof.Mr. P. R. Patil
 Software Myths
Management Myths
i)Myth: We already have a book that's full of standards and procedures for building
software,
Reality: but is it used? Are software practitioners aware of its existence? Is it
complete
ii)Myth: My people have state-of-the-art software development tools,
Reality: Computer-Aided Software Engineering (CASE) tools are more important
than hardware for achieving good quality and productivity, yet the majority of
software developers still do not use them effectively.

By-Prof.Mr. P. R. Patil
iii)Myth: If we get behind schedule, we can add more programmers and catch up
Reality: “Adding people to a late software project makes it later”. However, as new
people are added, people who were working must spend time educating the
newcomers. People can be added but only in a planned and well-coordinated manner.
iv)Myth: 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 be problematic to build that project.

By-Prof.Mr. P. R. Patil
 Customer’s Myths
i)Myth: A general statement of objectives is sufficient to begin writing programs,
we can fill in the details later.
Reality: A poor up-front definition is the major cause of failed software efforts. A
formal and detailed description of the information domain, function, behavior,
performance, interfaces, design constraints, and validation criteria is essential which
is determined only after thorough communication between customer and developer.
ii)Myth: Project 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 & cost is increases.

By-Prof.Mr. P. R. Patil
 Practitioner Myths
(Related To Practitioner or Programmer)
i)Myth: Once we write the program and get it to work, our job is done.
Reality: “ The sooner you begin 'writing code', the longer it'll take you to get done”.
ii)Myth: 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. Documentation provides a foundation for successful
engineering and, more important, guidance for software support.

By-Prof.Mr. P. R. Patil
A GENERIC PROCESS MODEL

A software process Process flow

framework By-Prof.Mr. P. R. Patil
 A GENERIC PROCESS MODEL
 A generic process framework for software engineering defines five framework activities—communication, planning,
modeling, construction, and deployment. In addition, a set of umbrella activities—project tracking and control, risk
management, quality assurance, configuration management, technical reviews
 Defining a Framework Activity
-What actions are appropriate for a framework activity, given the nature of the problem to be solved, the characteristics
of the people doing the work, and the stakeholders who are sponsoring the project?
- action encompasses are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.

 Identifying a Task Set

- number of different task sets—each a collection of software engineering work tasks, related work products, quality
assurance points, and project milestones

By-Prof.Mr. P. R. Patil
 Process Patterns A process pattern describes a process-related problem that is encountered during software engineering
work, identifies the environment in which the problem has been encountered, and suggests one or more proven
solutions to the problem.
Ambler has proposed a template for describing a process pattern:
 Pattern Name
The pattern is given a meaningful name describing it within the context of the software process (e.g.,
TechnicalReviews).
 Forces
The environment in which the pattern is encountered and the issues that make the problem visible and may affect its
solution.
 Type-three types:
1. Stage pattern—defines a problem associated with a framework activity for the process .
2. Task pattern—defines a problem associated with a software engineering action or work task and relevant to successful
software engineering practice (e.g., R equirementsGathering is a task pattern).
• Phase pattern—define the sequence of framework activities that occurs within the process.
• Ex: SpiralModel or Prototyping.

By-Prof.Mr. P. R. Patil
 PROCESS ASSESSMENT AND IMPROVEMENT
Standard CMMI Assessment Method for Process Improvement (SCAMPI)
- provides a five-step process assessment model that incorporates five phases: initiating, diagnosing,
establishing, acting, and learning. The SCAMPI method uses the SEI CMMI as the basis for assessment.
CMM-Based Appraisal for Internal Process Improvement (CBA IPI)
- provides a diagnostic technique for assessing the relative maturity of a software organization; uses the SEI
CMM as the basis for the assessment.
SPICE (ISO/IEC15504)
- a standard that defines a set of requirements for software process assessment. The intent of the standard is
to assist organizations in developing an objective evaluation of the efficacy of any defined software process.
ISO 9001:2000 for Software
- a generic standard that applies to any organization that wants to improve the overall quality of the products,
systems, or services that it provides

By-Prof.Mr. P. R. Patil
 CMMI
Overview

Quality
Frameworks

By-Prof.Mr. P. R. Patil
Outline
• Introduction
• High level overview of CMMI

By-Prof.Mr. P. R. Patil
 What is CMMI?
• CMMI (Capability Maturity Model Integration) is a proven industry framework to improve product
quality and development efficiency for both hardware and software
• Sponsored by US Department of Defence in cooperation with Carnegie Mellon
University and the Software Engineering Institute (SEI)
• Many companies have been involved in CMMI definition such as Motorola and
Ericsson
• CMMI has been established as a model to improve business results
• CMMI, staged, uses 5 levels to describe the maturity of the organization, same as predecessor
CMM
• Vastly improved version of the CMM
• Emphasis on business needs, integration and institutionalization

By-Prof.Mr. P. R. Patil
 CMMI Models within the Framework
• Models:
• Systems Engineering + Software Engineering (SE/SW)
• Systems Engineering + Software Engineering + Integrated Product and Process Development (IPPD)
• Systems Engineering + Software Engineering + Integrated Product and Process Development + Supplier Sourcing
(SS)
• Software Engineering only
• Representation options:
• Staged
• Continuous
• The CMMI definition of “Systems Engineering” -
“The interdisciplinary approach governing the total technical and managerial effort required to transform a set
of customer needs, expectations and constraints into a product solution and to support that solution throughout
the product’s life.” This includes both hardware and software.

By-Prof.Mr. P. R. Patil
CMMI Staged Representation - 5 Maturity Levels

Level 5 Process performance

continually improved through
incremental and innovative
Optimizing technological improvements.
Level 4
Processes are controlled using
Quantitatively
statistical and other quantitative
Managed
techniques.
Level 3
Processes are well characterized and
understood. Processes, standards,
Defined
procedures, tools, etc. are defined at the
Level 2 organizational (Organization X ) level.
Proactive.
Managed Processes are planned, documented, performed,
monitored, and controlled at the project level. Often
Level 1 reactive.

Initial Processes are unpredictable, poorly controlled, reactive.

By-Prof.Mr. P. R. Patil
 Maturity Level 1
Initial
• Maturity Level 1 deals with performed processes.
• Processes are unpredictable, poorly controlled, reactive.
• The process performance may not be stable and may not meet specific objectives such as
quality, cost, and schedule, but useful work can be done.

By-Prof.Mr. P. R. Patil
 Maturity Level 2
Managed at the Project Level
• Maturity Level 2 deals with managed processes.
• A managed process is a performed process that is also:
• Planned and executed in accordance with policy
• Employs skilled people
• Adequate resources are available
• Controlled outputs are produced
• Stakeholders are involved
• The process is reviewed and evaluated for adherence to requirements
• Processes are planned, documented, performed, monitored, and controlled at the project
level. Often reactive.
• The managed process comes closer to achieving the specific objectives such as quality, cost,
and schedule.

By-Prof.Mr. P. R. Patil
 Maturity Level 3
Defined at the Organization Level
• Maturity Level 3 deals with defined processes.
• A defined process is a managed process that:
• Well defined, understood, deployed and executed across the entire organization.
Proactive.
• Processes, standards, procedures, tools, etc. are defined at the organizational
(Organization X ) level. Project or local tailoring is allowed, however it must be
based on the organization’s set of standard processes and defined per the
organization’s tailoring guidelines.
• Major portions of the organization cannot “opt out.”

By-Prof.Mr. P. R. Patil
 Behaviors at the Five Levels
Maturity Level Process Characteristics Behaviors

Focus on "fire prevention";

Focus is on continuous improvement anticipated and
Optimizing quantitative improvement desired, and impacts assessed.

Quantitatively Process is measured Greater sense of teamwork and inter-

and controlled dependencies
Managed

Process is characterized Reliance on defined process.

Defined for the organization and People understand, support and
is proactive follow the process.

Process is characterized Over reliance on experience of good

Managed for projects and is often people – when they go, the process
reactive goes. “Heroics.”

Process is unpredictable, Focus on "fire fighting";

Initial poorly controlled, and effectiveness low – frustration high.
reactive
By-Prof.Mr. P. R. Patil
CMMI Components
• Within each of the 5 Maturity Levels, there are basic functions that need to be
performed – these are called Process Areas (PAs).
• For Maturity Level 2 there are 7 Process Areas that must be completely satisfied.
• For Maturity Level 3 there are 11 Process Areas that must be completely satisfied.
• Given the interactions and overlap, it becomes more efficient to work the Maturity
Level 2 and 3 issues concurrently.
• Within each PA there are Goals to be achieved and within each Goal there are Practices,
work products, etc. to be followed that will support each of the Goals.

By-Prof.Mr. P. R. Patil
 CMMI Process Areas
Maturity Level Project Managment Engineering Process Management Support
5 Organizational Innovation & Deployment Causal Analysis & Resolution
Optimizing
4 Quantitative Project Mngt Organizational Process Performance
Quantitatively
Managed
3 Integrated Project Mngt Requirements Development Organizational Process Focus Decision Analysis & Resolution
Defined Risk Management Technical Solution Organizational Process Definition
Product Integration Organizational Training
Verification
Validation
2 Project Planning Requirements Mngt Measurement & Analysis
Managed Project Monitoring & Process & Product Quality Assurance
Control Configuration Mngt
Supplier Agreement Mngt

1
Initial

By-Prof.Mr. P. R. Patil
 CMMI Terminology & Structure
Maturity Levels (1 - 5)

Process Area 1 Process Area 2 Process Area n

Required. Specific for Specific Generic Required. Common

Goals Goals across all process areas.
each process area.
Common Features

Commitment Ability Directing Verifying

to Perform to Perform Implementation Implementation

Specific Generic
Practices
Required Required Practices

Sub practices, typical work products, Sub practices, typical work products,
discipline amplifications, generic discipline amplifications, generic
practice elaborations, goal and practice elaborations, goal and
practice titles, goal and practice notes, practice titles, goal and practice notes,
and references and references

By-Prof.Mr. P. R. Patil
 Example
For the Requirements Management Process Area:
An example Goal (required):
“Manage Requirements”
An example Practice to support the Goal (required):
“Maintain bi-directional traceability of requirements”
Examples (suggested, but not required) of typical Work Products might be
Requirements traceability matrix or
Requirements tracking system

By-Prof.Mr. P. R. Patil
 Yet another CMMI term:
Institutionalization
• This is the most difficult part of CMMI implementation and the portion where managers play
the biggest role and have the biggest impact
• Building and reinforcement of corporate culture that supports methods, practices and
procedures so they are the ongoing way of business……..
• Must be able to demonstrate institutionalization of all CMMI process areas for all
organizations, technologies, etc.
• Required for all Process Areas

By-Prof.Mr. P. R. Patil
CMMI Resources
• Software Engineering Institute's CMMI website:
http://www.sei.cmu.edu/cmmi/

By-Prof.Mr. P. R. Patil
PRESCRIPTIVE PROCESS MODELS
1. The Waterfall Model

By-Prof.Mr. P. R. Patil
• 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.
• A variation in the representation of the waterfall model is called the V-model .
• As a software team moves down the left side of the V, basic problem requirements are
refined into progressively more detailed and technical representations of the problem
and its solution.
• oldest paradigm for software engineering.
• serve as a useful process model in situations where requirements are fixed and work is to
proceed to completion in a linear manner.

By-Prof.Mr. P. R. Patil
PRESCRIPTIVE PROCESS MODELS
2. Incremental Process Models

By-Prof.Mr. P. R. Patil
• The incremental model combines elements of linear and parallel process flows.
• When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed but many supplementary features (some known, others unknown)
remain undelivered.
• The core product is used by the customer (or undergoes detailed evaluation). As a result of use
and/or evaluation, a plan is developed for the next increment.
• The plan addresses the modification of the core product to better meet the needs of the customer
and the delivery of additional features and functionality.
• This process is repeated following the delivery of each increment, until the complete product is
produced.
• focuses on the delivery of an operational product with each increment.

By-Prof.Mr. P. R. Patil
PRESCRIPTIVE PROCESS MODELS
3. Evolutionary Process Models
I. Prototyping

By-Prof.Mr. P. R. Patil
• The prototyping paradigm begins with communication.
• You meet with other stakeholders to define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is mandatory.
• A prototyping iteration is planned quickly, and modeling (in the form of a “quick design”) occurs.
• A quick design focuses on a representation of those aspects of the software that will be visible to
end users (e.g., human interface layout or output display formats).
• The quick design leads to the construction of a prototype.
• The prototype is deployed and evaluated by stakeholders, who provide feedback that is used to
further refine requirements .
• prototype serves as a mechanism for identifying software requirements. If a working
prototype is to be built, you can make use of existing program fragments or apply tools .
• The prototype can serve as “the first system “

By-Prof.Mr. P. R. Patil
PRESCRIPTIVE PROCESS MODELS
II. The Spiral Model

By-Prof.Mr. P. R. Patil
• 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.
• 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 .
• Software is developed in a series of evolutionary releases. During early iterations, the release might be a
model or prototype. During later iterations, increasingly more complete versions of the engineered system
are produced.
• divided into a set of framework activities defined by the software engineering team.
• The spiral model is a realistic approach to the development of large-scale systems and software

By-Prof.Mr. P. R. Patil
PRESCRIPTIVE PROCESS MODELS
4. Concurrent Models

By-Prof.Mr. P. R. Patil
• called concurrent engineering, allows a software team to represent iterative
and concurrent elements of any of the process models.
• All software engineering activities exist concurrently but reside in different
states.
• Concurrent modeling defines a series of events that will trigger transitions
from state to state for each of the software engineering activities, actions, or
tasks .
• Concurrent modeling is applicable to all types of software development and
provides an accurate picture of the current state of a project.

By-Prof.Mr. P. R. Patil
The Unified Process

By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
Rational Unified Process
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Rational Unified Process (RUP)

• One commercial implementation of the Unified Process
• Developed by Jacobson, Booch, Rumbaugh
• Evolved from the Objectory process and the earlier Ericsson approach
• Now an IBM product1
• Vocabulary and concepts
• Artefacts, roles, disciplines, activities
• Use case-driven, architecture-centered, iterative, incremental, risk management-oriented
• RUP is a process Use Case-Driven Process
framework (not a
process on its own)
• Intended to be
customized to
project needs

[1] http://www-01.ibm.com/software/awdtools/rup/

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

RUP Vocabulary (1)

• Artefact
• Data element produced during the development (document, diagram, report, source code,
model…)
• Role
• Set of skills and responsibilities
• RUP defines 30 roles to be assigned (not all need to be fulfilled, depends on the project)
• 4 role categories: analysts, developers, testers, and managers
• Activity
• Small, definable, reusable task that can be allocated to a single role

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

RUP Vocabulary (2)

• Discipline
• Set of activities resulting in a given set of artefacts
• RUP includes 9 disciplines: engineering (business modeling, requirements, analysis and design,
implementation, test, deployment) and support (configuration and change management, project
management, environment)
• Guidance for a discipline is provided as workflows: sequence of activities that produces a result
of observable value

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Disciplines, Phases, and Iterations

Identify most of the Identify and detail
Detail the use cases Track and capture
use cases to define
(80% of the requirements) remaining use cases requirements changes
scope, detail critical
use cases (10%)

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Inception Phase
• Overriding goal is obtaining buy-in from all interested parties
• Initial requirements capture
• Cost-benefit analysis
• Initial risk analysis
• Project scope definition
• Defining a candidate architecture
• Development of a disposable prototype
• Initial use case model (10%-20% complete)
• First pass at a domain model

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Elaboration Phase
• Requirements Analysis and Capture
• Use Case Analysis
• Use Cases (80% written and reviewed by end of phase)
• Use Case Model (80% done)
• Scenarios
• Sequence and Collaboration Diagrams

• Class, Activity, Component, State Diagrams

• Glossary (so users and developers can speak common vocabulary)
• Domain Model
• To understand the problem: the system’s requirements as they exist within the context of the problem
domain
• Risk Assessment Plan revised
• Architecture Document

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Construction Phase
• Focus is on implementation of the design
• Cumulative increase in functionality
• Greater depth of implementation (stubs fleshed out)
• Greater stability begins to appear
• Implement all details, not only those of central architectural value
• Analysis continues, but design and coding predominate

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Transition Phase
• The transition phase consists of the transfer of the system to the user community
• Includes manufacturing, shipping, installation, training, technical support, and maintenance
• Development team begins to shrink
• Control is moved to maintenance team
• Alpha, Beta, and final releases
• Software updates
• Integration with existing systems (legacy, existing versions…)

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Business Modeling Discipline

• Objectives
• Understand the structure and the dynamics of the organization in which a system is to be
deployed (the target organization)
• Understand current problems in the target organization and identify improvement potential
• Ensure that customers, end users, and developers have a common understanding of the target
organization
• Derive the system requirements needed to support the target organization
• Explains how to describe a vision of the organization in which the system will be
deployed and how to then use this vision as a basis to outline the process, roles,
and responsibilities

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Business Modeling Discipline – Artefacts

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Business Modeling Discipline – Roles

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Requirements Discipline
• Establish and maintain agreement with the customers and other stakeholders on
what the system should do
• Provide system developers with a better understanding of the system requirements
• Define the boundaries of the system
• Provide a basis for planning the technical contents of iterations
• Provide a basis for estimating the cost and time to develop the system

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Requirements Discipline – Artefacts

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Requirements Discipline – Roles

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Requirements Discipline – Tasks

• Includes the following tasks
• List candidate requirements
• Candidate features that could become requirements
• Understand system context
• Based on business model, domain model or simple glossary
• Capture functional requirements
• Develop use cases and user interface support of use cases
• Capture non-functional requirements
• Tied to use cases or domain concepts
• Defined as supplementary requirements
• Validate requirements

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Other Disciplines – Engineering (1)

• Analysis and Design Discipline
• Transform the requirements into a design of the system-to-be
• Evolve a robust architecture for the system
• Adapt the design to match the implementation environment
• Implementation Discipline
• Define the organization of the implementation
• Implement the design elements
• Unit test the implementation
• Integrate the results produced by individual implementers (or teams), resulting in an executable
system

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Other Disciplines – Engineering (2)

• Test Discipline
• Find and document defects in software quality
• Provide general advice about perceived software quality
• Prove the validity of the assumptions made in design and requirement specifications through
concrete demonstration
• Validate that the software product functions as designed
• Validate that the software product functions as required (that is, the requirements have been
implemented appropriately)
• Deployment Discipline
• Ensure that the software product is available for its end users

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Supporting Disciplines
• Configuration & Change Management Discipline
• Identify configuration items
• Restrict changes to those items
• Audit changes made to those items
• Define and manage configurations of those items
• Project Management Discipline
• Manage a software-intensive project; manage risk
• Plan, staff, execute, and monitor a project
• Environment Discipline
• Provide the software development organization with the software development environment –
both processes and tools – that will support the development team
• This includes configuring the process for a particular project, as well as developing guidelines in
support of the project

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

RUP Best Practices

• RUP is a set of best practices
• Guidelines for creating good documents, models...
• Focus on having the right process (neither too heavy nor insufficient)
• Iterative development
• Each iteration considers the 9 disciplines to some degree
• Requirements management to establish an understanding of customer / project
• With use cases, requirements management tools and processes
• Component based architecture
• Promotes reusability, unit testing
• Visual modeling (using UML)
• Continuous verification of quality (reviews, metrics, indicators…)
• Change management (baselines, change requests…)

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

RUP and Agility?

• There is no contradiction between these two terms
• A definition of agile processes can lead to a cumbersome process…
• A definition of rich processes can lead to an agile process…

• Customizable software process engineering frameworks

• Rational Method Composer
• A tool for defining and monitoring your own development process
• http://www-01.ibm.com/software/awdtools/rmc/

• Eclipse Process Framework (EPF) – an Eclipse Project

• Predefined and extensible roles, tasks, and development styles
• Integration of tools - Metamodel-based
• http://www.eclipse.org/epf/

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 AGILE PROCESS
 What Is An Agile Process
 Agility Principles
• The Agile Alliance defines agility principles for those who want to achieve agility:
• Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.

By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
• 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.

By-Prof.Mr. P. R. Patil
 •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.
 The Politics of Agile Development
 Human Factors
- Agile development focuses on the talents and skills of individuals, molding the process to
specific people and teams
 Competence.
- Skill and knowledge of process can and should be taught to all people who serve as agile team
members.
 Common focus
- focused on one goal
- the team will also focus on continual adaptations (small and large)
 Collaboration.
- team members must collaborate—with one another and all other stakeholders.
By-Prof.Mr. P. R. Patil
 Self-organization
(1) the agile team organizes itself for the work to be done,
(2) the team organizes the process to best accommodate its local environment.
(3) the team organizes the work schedule to best achieve delivery of the software increment.
 Decision-making ability.
- team is given autonomy—decision-making authority for both technical and project issues.
 Fuzzy problem-solving ability
- team must accept the fact that the problem they are solving today may not be the problem that needs to
be solved tomorrow.
 Mutual trust and respect

By-Prof.Mr. P. R. Patil
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Agile Manifesto (http://agilemanifesto.org)

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Values of Agile Methods (1)

• Individuals and Interactions vs. Process and Tools
• Individuals create value, therefore focus on them
• Without a skilled craftsman, the best tools are useless
• Working Software vs. Comprehensive Documentation
• A heavy process generates exhaustive documentation with all its drawbacks: ambiguity of
language, cost of preparation, cost of maintenance to keep it up-to-date…
• These documents are an illusion of progress
• In agile methods, a single criterion measures the progress of a project: working software!
• Documentation is a concrete support that helps produce software

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Values of Agile Methods (2)

• Customer Collaboration vs. Contract Negotiation
• If negotiation protects you more or less from financial risk, it can cause project failure and result
in endless trials where everybody loses eventually
• We must abandon the war with the customer / supplier and think as one team with a common
goal: a successful project
• Responding to Change vs. Following a Plan
• A predefined plan tends to make us unresponsive to events that occur during the project
• Agile methods are designed to accommodate change, ensuring an accurate and adaptive
strategic plan

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Principles of the Agile Manifesto (1)

• Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software
• Welcome changing requirements, even late in development – agile processes
harness change for the customer's competitive advantage
• Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference for the shorter period
• 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

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Principles of the Agile Manifesto (2)

• Working software is the primary measure of project progress
• Agile processes promote a sustainable pace of 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

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Examples of Agile Approaches

• Extreme Programming (XP) • Microsoft Solutions Framework (MSF)
• Scrum • Agile Data
• Open Unified Process (OpenUP) • Agile Modeling
• Adaptive Software Development • Agile Unified Process (AUP)
(ASD) • Essential Unified Process (EssUP)
• Crystal Clear • Getting Real
• DSDM •…
• Feature Driven Development
• Lean software development
• Agile documentation
• Agile ICONIX

see http://en.wikipedia.org/wiki/Agile_software_development

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

When to use in general?

• The culture of the organization is supportive of collaboration
• Team members are trusted (competence & confidence)
• The organization is willing to live with the decisions developers make
• Fewer but competent team members
• Ideally less than 10 co-located team members
• Environment that facilitates rapid communication between team members
• Agile approaches are appropriate when requirements are difficult to predict, or
change often
• Situation where prototyping is required

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

When not to use?

• Agile approaches are not appropriate for every project
• Hard to use for
• Large projects (>20 developers)
• Distributed teams
• Working environments not adapted to close collaboration
• Critical applications (business-critical, safety-critical…)
• Projects where a substantial specification is required prior to coding
• When structure is rigid, e.g., military “Command-and-control” type projects

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 EXTREME PROGRAMMING (XP)
 XP Values
- communication, simplicity, feedback, courage, and respect. Each of these values is used as a driver for
specific XP activities, actions, and tasks
 The XP Process
 Planning
-begins with listening—a requirements gathering activity that enables the technical members of the XP team
to understand the business context .
- creation of a set of “stories” (also called user stories) that describe required output, features, and
functionality for software to be built. Each story is written by the customer and is placed on an index card.
- assign a cost—measured in development weeks—to it.
 Design
 Coding
 Testing

By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
Industrial XP
-IXP is an organic evolution of XP.
- customer-centric, test-driven spirit.
- IXP differs most from the original XP in its greater inclusion of management, its expanded role for
customers, and its upgraded technical practices.

Readiness assessment
(1) an appropriate development environment exists to support IXP, (2) the team will be populated by the
proper set of stakeholders, (3) the organization has a distinct quality program and supports continuous
improvement, (4) the organizational culture will support the new values of an agile team, and (5) the
broader project community will be populated appropriately.

By-Prof.Mr. P. R. Patil
 Project community
- people on the team must be well-trained, adaptable and skilled, and have the proper temperament to
contribute to a self-organizing team
 Project chartering
- examines the context of the project to determine how it complements, extends, or replaces existing
systems or processes
 Test-driven management
- requires measurable criteria for assessing the state of the project and the progress
 Retrospectives
-IXP team conducts a specialized technical review after a software increment is delivered. Called a
retrospective
 Continuous learn
- XP team are encouraged (and possibly, incented) to learn new methods and techniques that can lead
to a higher quality product.
 The XP Debate

By-Prof.Mr. P. R. Patil
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Extreme Programming (XP) (1)

• Software is Listening, Testing, Coding, Designing. That's all there is to software.
Anyone who tells you different is selling something.1
• Listen to customers while gathering requirements, develop test cases (functional tests and unit
tests), code the objects, design (refactor) as more objects are added to the system
• Listen – Test
Test Design – Code – Test Design
• XP is a software development approach introduced by Kent Beck, Ward
Cunningham, Ron Jeffries (~2000)
• Lightweight process model for OO software development
• Quick product delivery while retaining flexibility and maintaining quality
• Indented for small to medium size projects with a well integrated team
• Small teams (up to 10-15 programmers)

[1] Kent Beck, author of Extreme Programming Explained

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Extreme Programming (XP) (2)

• Why extreme?
• XP is based on the extreme application of 12 practices (guidelines or rules) that support each
other
• There is no real new practice, but the combination of practices and their extreme application is
new
• Code is at the centre of the process
• All non-production related tasks are superfluous
• Technical documentation = commented source code
• Other documentation is a waste of time (e.g., UML diagrams)
• Elements of success
• Common workplace and working hours
• All tests must be automated and executed in short time
• On-site customer
• Developer and client must commit 100% to XP practices
SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

12 XP Practices

Source: http://www.xprogramming.com/

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Elements of Extreme Programming

• Roles • Activities (cont’d)
• Clients (and tester), developer, sponsors • Spike Solutions
• Artefacts • Simple Design
• Metaphors • Writing and Running Tests
• User stories (prioritized) • Refactoring
• Tasks, unit tests, functional tests, code • Pair Programming
• Activities • Collective Code Ownership
• Planning Game • Continuous Integration
• Writing User Stories • 40 Hour Week
• Frequent Releases • On-site Customer
• System Metaphor • Coding Standards
• Stand Up Meeting
• Backlog

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Planning Game (1)

• Pieces
• User Stories Story: Broken phone call
When a telephone call is interrupted because
• Players of network disconnection, pre-emption, or
whatever, the system provides a
• Customer & Developer “disconnected” tone in the user’s ear for three
seconds, then automatically hangs up and
• Moves reestablishes a dial tone.

• User story writing

• Requirements are written by the customer on small index cards (simple, effective… and disposable)
• User stories are written in business language and describe things that the system needs to do
• Each user story is assigned a business value
• For a few months-long project, there may be 50-100 user stories

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Planning Game (2)

• Moves (cont’d)
• Story estimation
• Each user story is assigned a cost by the developer
• Cost is measured in ideal development weeks (1-3 person weeks)
• No interruptions, know exactly what to do

• A story is split by the customer if it takes longer than 3 weeks to implement

• If less than one week, it is too detailed and needs to be combined
• Estimate risk (high, medium, low)
• Commitment
• Customer and developer decide which user stories constitute the next release
• Value and risk first
• Developer orders the user stories of the next release so that more valuable or riskier stories are moved
earlier in the schedule

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

User Stories (1)

• A short description of the behavior of the system from the point of view of the
customer/user
• Use the customer/user’s terminology without technical jargon
• One for each major feature in the system
• Must be written by the customers/users
• Are used to create time estimates for release planning
• Replace a large requirements document

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

User Stories (2)

• Drive the creation of the acceptance tests
• One or more tests to verify that a story has been properly implemented
• Different than requirements
• Should only provide enough detail to make a reasonably low risk estimate of how long the story
will take to implement
• Different than use cases
• Written by customer, not programmers
• User stories have 3 crucial aspects
• Card (= enough information to identify
the story)
• Conversation
• Customer and programmers discuss the story to elaborate on the details
• Verbal when possible, but documented when required
• Confirmation (= acceptance tests)
SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Frequent Releases
• Highly iterative development process – release cycle of up to 3 months – iterations
of up to 3 weeks
• Short cycles during which the four phases take place in parallel
• Functional system delivered at the end of each cycle
• Frequent feedback from the customer
• In each iteration the selected user stories are implemented
• Each user story is split into programming tasks of 1-3 days

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

System Metaphor
• System metaphor provides a broad view of the project’s goal
• Overall theme to which developers and clients can relate
• The system is built around one (or more) system metaphors
• If the metaphor is well chosen, it leads to design approaches, class names, better
communication...
• Chrysler is a manufacturing company; we make cars. Using a manufacturing metaphor to define
the project was an important first step in getting the team (and management) on a level playing
field. The concepts of lines, parts, bins, jobs, and stations are metaphors understood throughout
the company. The team had the benefit of a very rich domain model developed by members of
the team in the project's first iteration. It gave the members of the project an edge in
understanding an extremely complex domain.1
• The computer is like an office.

[1] Chrysler Comprehensive Compensation project, Garzaniti 1997

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Spike Solution
• Need a mutual understanding of architecture
• XP does not do a big design up front
• No architecture phase

• Architectural Spike
• Very simple program to test out solutions for tough technical or design problems – a throwaway
prototype
• May lead to a system metaphor

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Simple Design
• Do the simplest thing that could possibly work
• Create the best (simplest) design you can
• Do not spend time implementing potential future functionality (requirements will change)

• Put in what you need when you need it

• A simple design ensures that there is less

• to communicate
• to test
• to refactor

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Tests
• Tests play the most important and central role in XP
• Tests are written before the code is developed
• Forces concentration on the interface; accelerates development; safety net for coding and
refactoring
• All tests are automated (test suites, testing framework)
• If user stories are considered the requirements, then tests may be considered as
the specification of the system
• Two kinds of test
• Acceptance tests (functional tests)
• Clients provide test cases for their stories
• Developers transform these into automatic tests
• Unit tests
• Developers write tests for their classes (before implementing the classes)
• All unit tests must run 100% successfully all the time
SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Refactoring
• 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 its internal structure.1

• The aim of refactoring is to

• Make the design simpler
• Make the code more understandable
• Improve the tolerance of code to change
• Useful names should be used (system metaphor)
• Refactoring is continuous design
• Remove duplicate code
• Tests guarantee that refactoring did not break anything that worked!

[1] Martin Fowler

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Pair Programming (1)

• Pairs change continuously (few times during a day)
• Every programmer knows all aspects of the system
• A programmer can be easily replaced in the middle of the project

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Pair Programming (2)

• Costs 10-15% more than standalone programming
• Code is simpler (fewer LOC) with less defects (15%)
• Ensures continuous code inspection

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Collective Code Ownership

• The code does not belong to any programmer but to the team
• Any programmer can (actually should) change any of the code at any time in order
to
• Make it simpler
• Make it better
• Encourages the entire team to work more closely together
• Everybody tries to produce a high-quality system
• Code gets cleaner
• System gets better all the time
• Everybody is familiar with most of the system

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Continuous Integration
• Daily integration at least
• The whole system is built (integrated) every couple of hours
• A working, tested system is always available

• XP feedback cycle
• Develop unit test
• Code
• Integrate
• Run all units tests (100%)
• Release

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

40 Hour Week
• Overtime is defined as time in the office when you do not want to be there.1

• If there is overtime one week, the next week should not include more overtime
• If more is needed then something is wrong with the schedule

• Keep people happy and balanced

• Rested programmers are more likely to refactor effectively, think of valuable tests,
and handle the strong team interaction

[1] Ron Jeffries

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

On-site Customer
• The customer must always be available
• To resolve ambiguities
• Set priorities
• Provide test cases
• User stories are not detailed, so there are always questions to ask the customer
• Customer is considered part of the team

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Coding Standards
• Coding standards make pair programming and collective code ownership easier

• Common scheme for choosing names

• Common code formatting

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Stand Up Meeting
• Daily at the beginning of the day, 15min long, standing up

• Not for problem solving

• Anyone may attend but only team members/sponsor/manager talk
• Helps avoid other unproductive meetings

• Make commitments in front of your peers

• What did you do yesterday?
• What will you do today?
• What, if anything, is in your way?

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Backlog
• Keep track of what needs to be done
• Prioritized – value and risk
• May contain user stories

• Requirements

Stand up meeting

Iteration

Backlog Release Product

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

12 XP Practices Revisited
• XP practices are not new
• They are supposed to be used all together to get the full value of the approach
• The practices work together to create synergy

• The full value of XP will not come until all the practices are in place. Many of the
practices can be adopted piecemeal, but their effects will be multiplied when they
are in place together.1

[1] Ken Beck

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

XP Process – Overview

Source: http://www.extremeprogramming.org/

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

XP Process – Details of one “Iteration”

Source: http://www.extremeprogramming.org/

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

XP Process – Details of one “Development”

Source: http://www.extremeprogramming.org/

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

XP Process – Details of one “Collective Code Ownership”

Source: http://www.extremeprogramming.org/

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Comparison – Requirements
• Requirements in RUP
• Use cases
• Requirements documents (including non-functional requirements)

• Requirements in XP
• User stories on cards
• On-site customers with strong involvement

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Comparison – Risks (1)

General risks: Wrong/bad requirements, changing
requirements, schedule and costs overruns
• RUP: Risks
• Do the use cases adequately describe all requirements ?
• RUP: Risk management
• Iterations, architecture for known risks, prioritization of use cases
• XP: Risks
• Difficulty in having an on-site customer with a complete view of the
client side and the ability to write stories & tests
• NFRs not covered
• Traceability?
• XP: Risk management
• Iterations (very short), extreme simplicity, user stories selected by
customer, estimates by developer
• Stories that are difficult to estimate are considered higher risk

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Comparison – Risks (2)

• Risk: later iterations may require more sophisticated design than the earlier
iterations
• RUP is predictive: elaboration phase considers all use cases and focuses on the ones with the
highest impact on the architecture
• Time wasted if some use cases end up being dropped
• First delivery delayed
• XP is adaptive: keep design simple and refactor when needed (extreme refactoring)
• Can end up being very difficult if later iterations introduce major changes

• Risk: developers leave and new developers join

• RUP: documentation of the architecture and key scenarios
• XP: use of pair programming to teach new developers and to ensure knowledge of the system is
well distributed

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Suggested Improvements to XP
• eXtreme Requirements (Leite)
• http://www-di.inf.puc-rio.br/~julio/Slct-pub/XR.pdf
• eXtreme Requirements improved (Leite and Leonardi)
• http://www.mm.di.uoa.gr/~rouvas/ssi/caise2002/23480420.pdf
• EasyWinWin (Grünbacher and Hofer)
• http://www.agilealliance.com/show/909
• XP modified (Nawrocki et al.)
• http://www.cs.put.poznan.pl/jnawrocki/publica/re02-essen.doc

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

eXtreme Requirements (XR)

• Five improvements (or processes)
• Notion of scenario and process
• Non-functional requirements (constraints)
• Traceability (lexicon)
• Derivation of situations from scenarios
• Formal expression of scenarios

• XR improved
• Business rule concept
• Interviews, workshops

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

EasyWinWin
• Complements XP with requirements negotiation
• Defines 7 activities that guide stakeholders through a negotiation process
• Review and expand negotiation topics (features, services, interfaces, system properties, cost,
schedule…)
• Brainstorm stakeholder interest
• Converge on win-win conditions
• Capture a glossary of terms
• Prioritize win-win conditions (polling used (a) to determine priorities of win-win conditions, and (b)
to reveal conflicts and different perceptions among stakeholders)
• Reveal issues and constraints (examine the results of the prioritization poll to analyze patterns of
agreement and disagreement)
• Identify issues, options, and agreements

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

XP modified
• Three improvements to XP
• Written requirements documentation
• Several customer representatives
• Requirements engineering phase

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Is agile better? The debate is still on! (1)

• Daniel Berry (on XP and RE)
• However, all the data I have seen say that full RE is the most cost-effective way to produce
quality software, and that it will beat out any agile method any time in the cost and quality
attributes.
• When all the details are hammered out during an RE process that lasts until it is done (and not
until a predetermined date), the development proceeds so much quicker and with so few bugs!

• Chrysler Comprehensive Compensation (C3) project – Success or Failure?

• http://calla.ics.uci.edu/histories/ccc/
• http://c2.com/cgi/wiki?CthreeProjectTerminated

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
 Rational Unified Process Agile Methods Overview Extreme Programming Practices XP Process Conclusion

Is agile better? The debate is still on! (2)

• After seeing heavy and light processes, the decision is not always binary
• It really depends on your context and your project
• What are your needs?
• What are the appropriate artifacts (documents, models…)?
• What are the tasks and roles?
• What are the appropriate tools?
• What process elements are adequate and how to assemble them?
• Based on an analysis of your context and project, you should be able to make the
appropriate decisions

• See also mandatory supplementary material by Alan M. Davies posted on the

course website

SEG3101 (Fall 2010). Integrating Requirements Engineering into Software Engineering Processes.
Adaptive Software Development (ASD)

By-Prof.Mr. P. R. Patil
 By-Prof.Mr. P. R. Patil

ADAPTIVE LIFE CYCLE

 By-Prof.Mr. P. R. Patil

ADAPTIVE SOFTWARE DEVELOPMENT

Adaptive software development replaces the traditional
waterfall cycle with a repeating series of speculate,
collaborate, and learn cycles. This dynamic cycle
provides for continuous learning and adaptation to the
emergent state of the project. The characteristics of an
ASD life cycle are that it is mission focused, feature
based, iterative, time boxed, risk driven, and change
tolerant.
 By-Prof.Mr. P. R. Patil

 The adaptive model is built on a different world view. While cyclical

like the evolutionary model, the phase names reflect the
unpredictable realm of increasingly complex systems (see Figure 3).
Adaptive development goes further than its evolutionary heritage in
two key ways. First, it explicitly replaces determinism with
emergence. Second, it goes beyond a change in life cycle to a deeper
change in management style. The difference can be subtle. For
example, as the environment changes, those using a deterministic
model would look for a new set of cause-and-effect rules, while those
using the adaptive model know there are no such rules to find.
 By-Prof.Mr. P. R. Patil
ADAPTIVE SOFTWARE DEVELOPMENT
PROCESS
 1) Speculate:

 In complex environments,
planning is a paradox. According
to CAS theory, outcomes are
unpredictable. Yet wandering
around, endlessly experimenting
on what a product should look
like is not likely to lead to
profitability either. "Planning,"
whether it is applied to overall
product specifications or detail
project management tasks, is
too deterministic a word. It
carries too much historical
baggage. "Speculate" is offered
as a replacement.
 By-Prof.Mr. P. R. Patil

CONT…
 When we speculate, it's not that we don't define a mission to the
best of our ability. (I use "mission" as a summary term for objectives,
vision, goals, and outline requirements.) It simply admits the obvious
-- in some important dimensions of our mission statements, we are
more than likely wrong. Whether we misread our customer's needs,
or technology changes, or competitors come out with a better
mousetrap, the probability of mistakes is high. So let's be honest,
postulate a general idea of where we are going, and put
mechanisms in place to adapt. In a complex environment, following a
plan produces the product you intended -- just not the product you
need.
 By-Prof.Mr. P. R. Patil

 2) Collaborate:
 Managing in a complex
environment is scary as hell --
it is also a blast. If we can't
predict (plan), then we can't
control in the traditional
management sense. If we
can't control, then a significant
set of current management
practices is no longer
operable, or more specifically,
only operable for those parts
of the development process
that are predictable.
 By-Prof.Mr. P. R. Patil

CONT…
 Collaboration, in this context, portrays a balance between managing
the doing (the main thrust of traditional management) and creating
and maintaining the collaborative environment needed for
emergence. As projects become increasingly complex, the balance
swings much more toward the latter. At times it seems almost
mystical, but in field after field, from physics to cellular automata to
some of my client's projects, emergence has, well, . . . emerged [4,
5]. We have all experienced emergent results on some special
project, but it somehow seemed nearly accidental, not something to
count on in a crunch. CAS provides some comfort that it is not
accidental.
 By-Prof.Mr. P. R. Patil

CONT…

 For a project manager, maintaining this balance means two

things. First, he or she has to decide which parts of the project
are predictable. For example, we can predict that without
appropriate configuration control procedures, a software project
of any size can implode. For parts that are unpredictable, he or
she has to establish an environment in which the wild and
wonderful properties of emergence -- basically open,
collaborative, messy, exciting, diverse, anxiety-ridden, and
emotion-laden -- can exist.
 By-Prof.Mr. P. R. Patil

CONT…

 Unfortunately, at least for some people, CAS postulates certain

conditions for emergent behavior. The most important is that it
happens at the edge of chaos. Whether in physics, biology,
business, or human behavior, it appears that there are three
broad categories of environments -- stable, unstable (or chaotic),
and a transition zone labeled the "edge of chaos."
 By-Prof.Mr. P. R. Patil

CONT…

 The edge of chaos is the constantly shifting battle zone between

stagnation and anarchy, the one place where a complex system
can be spontaneous, adaptive, and alive [5].
 By-Prof.Mr. P. R. Patil

CONT…

 In human terms, being in chaos is analogous to being psychotic.

So the trick is to lead a project team away from the familiar and
the stable toward chaos, but not all the way. Success comes to
those who can hold anxiety, who can attune themselves to
paradox and uncertainty. Innovation, creativity, and emergent
results are born in the transition zone at the edge of chaos.
 By-Prof.Mr. P. R. Patil

 3) Learn:
 Collaborative activities build
products. Learning activities
expose those products to a
variety of stakeholders to
ascertain value. Customer
focus groups, technical
reviews, beta testing, and
postmortems are all
practices that expose results
to scrutiny.
 By-Prof.Mr. P. R. Patil

CONT…
 Learning, according to the dictionary, is gaining mastery through
experience. In an adaptive environment, learning challenges all
stakeholders, including both developers and customers, to
examine their assumptions and use the results of each
development cycle to learn the direction of the next. The cycles
need to be short, so teams can learn from small rather than
large mistakes. They also need to be double-loop, so teams
learn both about product changes and more fundamental
changes in underlying assumptions about how the products are
being developed.
 By-Prof.Mr. P. R. Patil

CONT…

 Speculate -- Collaborate -- Learn

 If you examine the speculate -- collaborate -- learn cycle, even
briefly, it becomes obvious that the three stages overlap. It is
difficult to collaborate without learning or to learn without
collaborating. They are purposely messy, nonlinear, overlapping
terms -- how could terms that describe an adaptive framework
be otherwise?
 By-Prof.Mr. P. R. Patil

CONT…
 For many project leaders and project teams, adaptive development
is a terrifying prospect. First, we knock away the foundation pillar of
cause and effect, so we can't say for sure what needs to be done
next. Next we force the team into meeting deliverable goals, but we
admit we don't know exactly what they are. Then when they then get
anxious and concerned about all the "seemingly inefficient" groping
around for solutions (because of the needed diversity and multiple
interactions), we have to say that high anxiety is part of the new
game, and it won't go away. And finally, when a successful product
emerges, to many it seems almost accidental. It is not a place for the
timid.
 By-Prof.Mr. P. R. Patil

CONT…

 Are there organizations practicing adaptive development? I

would offer Microsoft as an example of a company that excels
because its management style exemplifies adaptive
development. For all the techniques and practices discussed in
books like Microsoft Secrets [3], I believe Microsoft prospers
because at the core of these practices lies the abandonment of
determinism and an embrace of the messiness of speculation --
collaboration -- learning.
 Adaptive SDLC
Combines RAD with software engineering best practices
• Project initiation
• Adaptive cycle planning
• Concurrent component engineering
• Quality review
• Final QA and release

By-Prof.Mr. P. R. Patil
 Adaptive Steps
1. Project initialization – determine intent of project
2. Determine the project time-box (estimation duration of the
project)
3. Determine the optimal number of cycles and the time-box for
each
4. Write an objective statement for each cycle
5. Assign primary components to each cycle
6. Develop a project task list
7. Review the success of a cycle
8. Plan the next cycle

By-Prof.Mr. P. R. Patil
 Dynamic Systems Development Method (DSDM)
• DSDM 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”
• 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.
• The DSDM Consortium (www.dsdm.org) is a worldwide group of member companies
• DSDM life cycle that defines three different iterative cycles, preceded by two additional life cycle activities:
- Feasibility study - Implementation
- Business study
- Functional model iteration
- Design and build iteration
By-Prof.Mr. P. R. Patil
 Scrum
• Scrum is an agile software development method that was conceived by Jeff Sutherland and his development
team in the early 1990s.
• In recent years, further development on the Scrum methods has been performed by Schwaber and Beedle
• Scrum principles are consistent with the agile manifesto and are used to guide development activities within
a process that incorporates the following 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.

By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
• Scrum emphasizes the use of a set of software process patterns
• 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-box (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 :
• 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.

By-Prof.Mr. P. R. Patil
 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”.
• 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 family is actually a set of example agile processes that have been proven effective for different
types of projects.
• The intent is to allow agile teams to select the member of the crystal family that is most appropriate for
their project and environment.

By-Prof.Mr. P. R. Patil
 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.
• 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.

FDD emphasizes software quality assurance activities by encouraging an incremental development strategy, the
use of design and code inspections, the application of software quality assurance audits, the collection of
metrics, and the use of patterns (for analysis, design, and construction).
• 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 features provides the following benefits:
By-Prof.Mr. P. R. Patil
 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>

Examples of features for an e-commerce application might be:

1. Add the product to shopping cart
2. Display the technical-specifications of the product
3. Store the shipping-information for the customer

By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
• A feature set groups related features into business-related categories and is defined as:
<action><-ing> a(n) <object>
For example:
1.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.
 FDD provides greater emphasis on project management guidelines and techniques than many other agile methods.
 As projects grow in size and complexity, ad hoc project management is often inadequate.
 It is essential for developers, their managers, and other stakeholders to understand project status—what
accomplishments have been made and problems have been encountered.
 If deadline pressure is significant, it is critical to determine if software increments (features) are properly scheduled.
 To accomplish this, FDD defines six milestones during the design and implementation of a feature: “design
walkthrough, design, design inspection, code, code inspection, promote to build”

By-Prof.Mr. P. R. Patil
 Agile Modeling (AM)
• There are many situations in which software engineers must build large, business critical systems. The scope and
complexity of such systems must be modeled so that
(1) all constituencies can better understand what needs to be accomplished,
(2) the problem can be partitioned effectively among the people who must solve it, and
(3) quality can be assessed as the system is being engineered and built.

 Over the past 30 years, a wide variety of software engineering modeling methods and notation have been proposed for
analysis and design (both architectural and component-level).
 These methods have merit, but they have proven to be difficult to apply and challenging to sustain (over many projects).
Part of the problem is the “weight” of these modeling methods.
 By this I mean the volume of notation required, the degree of formalism suggested, the sheer size of the models for
large projects, and the difficulty in maintaining the model(s) as changes occur.
 Yet analysis and design modeling have substantial benefit for large projects—if for no other reason than to make these
projects intellectually manageable.
 Is there an agile approach to software engineering modeling that might provide an alternative?
 At “The Official Agile Modeling Site,” Scott Ambler describes agile modelling (AM) in the following manner:

By-Prof.Mr. P. R. Patil
“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. Agile models are more
effective than traditional models because they are just barely good,
they don’t have to be perfect.”

By-Prof.Mr. P. R. Patil
• 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 :
1.Model with a purpose.:- A developer who uses AM should have a specific goal (e.g., to communicate information to the
customer or to help better understand some aspect of the software) in mind before creating the model. Once the goal for the
model is identified, the type of notation to be used and level of detail required will be more obvious.
2.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. 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.
3.Travel light. As software engineering work proceeds, keep only those models that will provide long-term value and jettison
the rest. Every work product that is kept must be maintained as changes occur. This represents work that slows the team
down. Ambler notes that “Every time you decide to keep a model you trade-off agility for the convenience of having that
information available to your team in an abstract manner (hence potentially enhancing communication within your team as
well as with project stakeholders).”
4.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.
5.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.
6. Adapt locally. The modeling approach should be adapted to the needs of the agile team.

By-Prof.Mr. P. R. Patil
 Kanban Model
• What is Kanban?
-Kanban is a very popular framework for development in the agile software development methodology. It provides a
transparent way of visualizing the tasks and work capacity of a team. It mainly uses physical and digital boards to allow the
team members to visualize the current state of the project they are working on.
-Kanban originated in Toyota in the 1940s. Kanban’s meaning in Japanese is “billboards.” The Kanban board has columns
and story cards. The columns are nothing, but workflow states and cards are nothing but a demonstration of the actual task
a team member is performing.
Kanban is a popular framework used to implement agile and DevOps software development.

More detail :- https://www.atlassian.com/agile/kanban

By-Prof.Mr. P. R. Patil
Kanban Board
Kanban board is used to depict the flow of tasks across the value stream. The Kanban board −
• Provides easy access to everyone involved in the project.
• Facilitates communication as and when necessary.
• Progress of the tasks are visually displayed.
• Bottlenecks are visible as soon as they occur.
Advantages of Kanban board
• The major advantages of using a Kanban board are −
Empowerment of Team − This means −
• Team is allowed to take decisions as and when required.
• Team collaboratively resolves the bottlenecks.
• Team has access to the relevant information.
• Team continually communicates with customer.
Continuous Delivery − This means −
• Focus on work completion.
• Limited requirements at any point of time.
• Focus on delivering value to the customer.
• Emphasis on whole project.
By-Prof.Mr. P. R. Patil
Using Kanban Techniques
to Control Incremental
Development

Jeff Patton
AgileProductDesign.com
[email protected]
Download this presentation at: www.agileproductdesign.com/downloads/patton_kanban.ppt
In this short talk we’ll cover:

1. What is a Kanban System and how

does it apply to software development?
2. How to set up a development team
Kanban System
3. Applying Lean thinking to software
development
看板 – Kanban cards limit excess work
in progress
看板 – Kanban literally means
“visual card,” “signboard,” or
“billboard.”
Toyota originally used Kanban
cards to limit the amount of
inventory tied up in “work in
progress” on a manufacturing floor
Not only is excess inventory waste,
time spent producing it is time
that could be expended elsewhere
Kanban cards act as a form of
“currency” representing how WIP
is allowed in a system.
Kanban simulation
Let’s simulate a simple process, then see if we can
improve it by adding a Kanban system.

I’ll need 5 volunteers to manufacture the latest in

high-tech aircraft
Why use Kanban in Software
Development?
(we’re not building aircraft – or anything tangible really)
Time-boxed iterative development has challenges
Common problems include:
•Short time-boxes give more frequent opportunity to
measure progress and inspect software but force
development items to be smaller
•Smaller development items are often too small to be
valuable and difficult to identify
•Quality of requirements suffers as analysts rush to prepare
for upcoming cycles
•Quality of current development suffers when busy analysts
are unable to inspect software or answer questions during
development
•Quality often suffers as testers race to complete work late
in the development time-box
Inside an iteration, effort across roles is
uneven

Development work often continues throughout a cycle

while testing starts late and never seems to get enough time
 Using a Kanban approach in
software drops time-boxed
iterations in favor of focusing on
continuous flow.
 How to set up a simple Kanban
system for a software development
team.
1. Define a work process flow

This simple process flow has the steps:

1.elaboration & acceptance criteria
2.development
3.test
4.deployment

Look at the typical flow for features, stories, or work

packages and describe typical process steps
2. Lay out a visual Kanban board

Place an expedite track above the main

left to right queue

Place “done and waiting” queues between

each work queue
(in this example they’re placed below)

Place a goals column on the left, then a waiting queue, the

process steps, and a final “done” column to the right
3. Decide on limits for items in queue and work in
progress

This board uses painters tape to indicate

available “slots” for work in progress

A good limit is a factor of the number of people in a role that can work
on an item in a given process step. Start with number of people * 1.5
4. Place prioritized goals on the left column of the
board

Having goals visible:

•promotes focus
•helps us prioritize
•helps us manage feature scope &
requirements

A good goal describes the outcome we hope to achieve after software

ships. Goals help keep focus on the larger outcome.
5. Start the board by placing stories or features in
queue

Product owners manage the waiting

queue

Mark on the story or feature card the date it entered the queue. This
begins our measurement of cycle time.
6. Move features through the process flow as work is
completed

As the story enters the first process step, mark that date on the card.
This is the start date. As it’s finished, mark that date on the card. This
is the finish date.
7. Use the dates on the cards to calculate cycle time

Cycle time = finish date – start date

The average cycle time from the date the
item enters the board is the wait time
from this point in the queue

Use average cycle time to set wait times from different points on the
board. Pay attention to flow and bottlenecks: relieving bottlenecks as
quickly as possible.
Display and manage cycle times
Disneyland’s
public display of
cycle-times

Reduce the number of Kanban slots allowed until cycle time remains
unchanged
Reduce the size of development items
•Work in progress is actually the number of items * the average size of items
Identify and act on bottlenecks immediately
•Relieve repeated bottlenecks by changing the number and types of people in
each role and cross training
Kanban Boards
Kanban Boards
Kanban Boards
Kanban Boards
Kanban Boards
Explode large process steps into tasks to improve
visibility
When a feature, user story, or work item is large:
 Takes longer than a couple days to complete
 Requires that multiple people collaborate on its completion
Decompose that step into cards to track independently

Feature to Tasks in Tasks Feature

develop Tasks in queue progress complete complete
Kanban Board with Task Decomposition
Use cumulative flow diagrams to visualize work in
progress

www.agilemanagement.net/Articles/Papers/BorConManagingwithCumulat.html
Use cumulative flow diagrams to visualize work in
progress

www.agilemanagement.net/Articles/Papers/BorConManagingwithCumulat.html
Keep time-boxed product and process inspection
Keep regular time-boxes in your process as a cue for product
inspection:
•Evaluate the quality of the growing product from a functional,
engineering, and user experience perspective

Evaluate your pace of development:

•Look at the number of development items completed relative to goals
•Look at the average cycle time per development item
•Calculate the ratio of developer days per completed item. Use this
ratio to estimate the completion time for undeveloped items
•Adjust your development plan as necessary

Evaluate and adjust the process you’re using

•Use a process reflection session to identify changes you could make to
improve your product or pace
Ending cycles right: http://www.stickyminds.com/s.asp?F=S14865_COL_2
Begin looking at your process using Lean thinking

Cockburn’s Software Engineering in the 21st Century:

http://alistair.cockburn.us/Software+engineering+in+the+21st+century.ppt
Since we’re engaged in “knowledge work” look at
the cycle time of validated decisions, or knowledge

Cockburn’s Software Engineering in the 21st Century:

http://alistair.cockburn.us/Software+engineering+in+the+21st+century.ppt
Often the feedback loop is overlooked – it’s the
invisible backed-up queue

Cockburn’s Software Engineering in the 21st Century:

http://alistair.cockburn.us/Software+engineering+in+the+21st+century.ppt
Setting up a simple Kanban system starts to
focus the team on the cycle-time of
delivered work and gives a way to detect
and begin to resolve bottlenecks
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil
By-Prof.Mr. P. R. Patil