SOFTWARE ENGINEERING

B.Tech II-I sem

 Unit-1
 Introduction to Software Engineering : The
evolving role of software, Changing Nature of
Software, Software myths.

 A Generic view of process : Software engineering-

A layered technology, a process framework, The
Capability Maturity Model Integration (CMMI),.

 Process models: The waterfall model, Spiral model

and Agile Methodology
 INTRODUCTION
• Software engineering provides a standard procedure to
design and develop a software.
• The term software engineering is the product of two
words 1.Software 2.Engineering.

1.Software: The s/w is a collection of integrated

programs.
2.Engineering: It is a application of science, tools &
methods to find cost effective solution to problems.
Definition: Software Engineering is the process of
designing, developing, testing, and maintaining
software.
 What is Software Engineering?
Differences between Program And Software Engineering

 Programming
 Individual Writes Complete Program
 One Person, One Computer
 Well-Defined Problem
 Programming-in-the-Small

 Software Engineering
 Individuals Write Program Components
 Team Assembles Complete Program
 Programming-in-the-Large
What is the difference between software engineering and computer
science?

Computer Science Software Engineering

is concerned with
 theory  the practicalities of developing
 fundamentals  delivering useful software

Computer science theories are currently insufficient to act as a complete

underpinning for software engineering, BUT it is a foundation for practical
aspects of software engineering
 What is Good Software?
 Software has number of attributes which decide whether it
is a good or bad .
 The definition of a good software changes with the person
who evaluates it.
 The software is required by the customer , used by the end
users of an organization and developed by software
engineer .
 Each one will evaluate the different attributes differently in
order to decide whether the software is good.
 What are the attributes of good
software?
The software should deliver the required functionality and
performance to the user and should be maintainable, dependable,
Efficiency, and usability..

 Maintainability
 Software must evolve to meet changing needs
 Dependability
 Software must be trustworthy
 Efficiency
 Software should not make wasteful use of system resources
 Usability
 Software must be usable by the users for which it was designed
 Software - Characteristics
 Software has a dual role. It is a product, but also a vehicle
for delivering a product.

 Software is a logical rather than a physical system element.

 Software has characteristics that differ considerably from

those of hardware.

 Software is developed or engineered, it is not manufactured in

the classical sense

 Software doesn’t “wear out”

 Most software is custom-built, rather than being assembled

from existing components.
Software - Characteristics
 It is intangible, meaning it cannot be seen or touched.
 It is non-perishable, meaning it does not degrade over time.
 It is easy to replicate, meaning it can be copied and distributed easily.
 It can be complex, meaning it can have many interrelated parts and
features.
 It can be difficult to understand and modify, especially for large and
complex systems.
 It can be affected by changing requirements, meaning it may need to be
updated or modified as the needs of users change.
 It can be impacted by bugs and other issues, meaning it may need to be
tested and debugged to ensure it works as intended.

Software doesn’t “wear out”

CHARACTERISTICS OF HARDWARE

12
The Evolving role of software
 Dual role of Software
A Product

Information transformer-producing, managing

-
and displaying
As Vehicle for delivering a product
- Control of computer(operating system)
- Efforts communication of information(network)
and the creation of other programs(software tools)

13
 Software Evolution
 Software Evolution is a term which refers to the
process of developing software initially, then
timely updating it for various reasons, i.e., to add
new features or to remove obsolete functionalities
etc.
 The evolution process includes fundamental
activities of change analysis, release planning,
system implementation and releasing a system to
customers.
 The necessity of Software evolution
 Software evaluation is necessary just because of the
following reasons:

 Change in requirement with time

 Environment change
 Errors and bugs
 Security risks
 For having new functionality and features
Software Evolution
Laws used for Software Evolution
 Law of continuing change
 Law of increasing complexity
 Law of conservation of organization stability
 Law of conservation of familiarity
 Law of self Regulation
 Law of continuing Growth
 The feedback system law
 Law of Declining Quality
THE CHANGING NATURE OF SOFTWARE

 Some Broad Categories of software are

challenges for software engineers
 System software
 Application software
 Engineering and scientific software
 Embedded software
 Web-applications
 Artificial intelligence software
 Internet Software

18
 THE CHANGING NATURE OF SOFTWARE
 System software: System software is a collection of programs
written to service other programs Ex.OS
 Application software : It is a group of program designed for end
users.
Ex. Email
 Engineering and scientific software: Engineering and scientific
software have been characterized by "number crunching"
algorithms. Ex. CAD
 Embedded software
-- resides in read-only memory
--is used to control products and systems for the consumer and
industrial markets.
Ex. GPS devices,modren smart watches
19
THE CHANGING NATURE OF SOFTWARE
 Web Applications: It is a client- server computer program
Which the client runs in a web browser.
Ex. Online auction
 Artificial intelligence software:
It is a machine learning includes algorithm that are developed to
tell a computer how to respond to something by example.
It uses a structure as close as possible to human brain.
Ex. Speech recognition.
 Internet Software :
Programs that support internet accesses and applications. For
example, search engine, browser, e-commerce software, authoring
tools.
20
 LEGACY SOFTWARE
 Legacy software are older programs that are
developed decades ago.
(or)
Legacy software refers to older software solutions
that businesses continue to use even after they've
become outdated.
 The quality of legacy software is poor because it
has inextensible design,convoluted code, poor and
nonexistent documentation,test cases and results
that are not achieved.
21
 Astime passes legacy systems
evolve due to following reasons:
 The software must be adapted to meet the needs of
new computing environment or technology.
 The software must be enhanced to implement new
business requirements.
 The software must be extended to make it
interoperable with more modern systems or
database
 The software must be re architected to make it
viable within a network environment.
22
 Who uses Legacy software
 Companies use it to fulfill their operational needs, though the
software they use may not have the new advancements or updates.
For example, a company may use old computers that have legacy
software. The software may store data efficiently, even if new
software systems have larger storage capacities.
 Companies typically use legacy software when they have older
technology systems. Often, older machines are only compatible
with software from the same period, so it's easier for companies to
use legacy software instead of purchasing new equipment. While
using legacy software, IT professionals need to observe extra
security protocols, perform frequent data backups, convert files to
compatible formats with new software and drivers and purchase
additional storage.
 SOFTWARE MYTHS
 Widely held but false view
 Def:Software myths are misleading
attitudes that have caused serious
problems for managers and technical
people alike. Software myths propagate
misinformation and confusion
 Three types of myth

- Management myth
- Customer myth
- Practitioner’s myth 24
 MANAGEMENT MYTHS
 Myth(1)
-The available standards and procedures for s/w
are enough.
 Myth(2)
-Each organization feel that they have state-of-art
software development tools since they have latest
computer.
 Myth(3)
-Adding more programmers when the work is
behind schedule can catch up.
 Myth(4)
-Outsourcing the software project to third party,
we can relax and let that party build it. 25
 CUSTOMER MYTH
Myth(1)

- General statement of objective is enough

to begin writing programs, the details can
be filled in later.
Myth(2)

-Software is easy to change because

software is flexible

26
 PRACTITIONER’S MYTH
 Myth(1)
-Once the program is written, the job has
been done.
 Myth(2)
-Until the program is running, there is no
way of assessing the quality.
 Myth(3)
-The only deliverable work product is the
working program
 Myth(4)
-Software Engineering creates unnecessary
documentation and invariably slows down 27
software development.
 SOFTWARE MYTHS
Widely held but false view
Propagate misinformation and confusion
S/W myths are belief about the s/w & the
process used to build it.
Three types of myth

- Management myth
- Customer myth
- Practitioner’s myth
28
 Management myths
Managers with software responsibility are often under
pressure to maintain budgets, keep schedules from
slipping, and improve quality.
Following are the management myths:
Myth 1: We already have a book that’s full of standards
and procedures for building software, won’t that provide
my people with everything they need to know?
Reality: The book of standards may very well exist, but
isn’t used. Most software practitioners aren’t aware of its
existence. Also, it doesn’t reflect modern software
engineering practices and is also complete.
Contd..
Myth 2: My people have state-of-the-art software
development tools, after all, we buy them the
newest computers.
Reality: It takes much more than the latest model
mainframe, workstation, or PC to do high-quality
software development. 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.
Contd..
Myth 3: If we get behind schedule, we can add
more programmers and catch up
Reality: Software development is not a
mechanistic process like manufacturing. As new
people are added, people who were working
must spend time educating the newcomers,
thereby reducing the amount of time spent on
productive development effort. People can be
added but only in a planned and well-coordinated
manner.
Contd..
Myth 4: If I decide to outsource the software
project to a third party, I can just relax and let
that firm build it.
Reality: If an organization does not understand
how to manage and control software projects
internally, it will invariably struggle when it
outsources software projects.
 Customer myths:
Customer myths lead to false expectations (by the
customer) and ultimately, dissatisfaction with the
developer
Myth 1: 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 functions, behavior,
performance, interfaces, design constraints, and
validation criteria is essential.
 Contd..
Myth 2: 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 at which it is
introduced. When changes are requested during software
design, the cost impact grows rapidly. Resources have
been committed and a design framework has been
established. Change can cause heavy additional costs.
Change, when requested after software is in production,
can be much more expensive than the same change
requested earlier.
 Practitioner’s myths
Myth 1: Once we write the program and get it to work, our
job is done.
Reality: Industry data indicate that between 60 and 80
percent of all effort expended on software will be
expended after it is delivered to the customer for the
first time.
Myth 2: Until I get the program “running” I have no way
of assessing its quality.
Reality: One of the most effective software quality
assurance mechanisms can be applied from the inception
of a project—the formal technical review.
 Contd..
Myth 3: The only Deliverable work product for a successful
project is the working Program..
Reality: A working Program is only one part of a software
configuration that include many elements. Documentation
Provides a foundation for successful engineering and
more importantly, guidance for software support
Myth 4: Software Engineering will make us create
voluminous and unnecessary documentation and
invariably slow us down.
Reality: Software Engineering is not about creating
documents. It is about creating Quality leads to Reduced
rework & reduced rework results in faster delivery times.
A Generic view of process

Software engineering- A layered technology, a

process framework, The Capability Maturity
Model Integration (CMMI
A Generic view of process
SOFTWARE ENGINEERING-A LAYERED TECHNOLOGY

Tools

Methods

Process

Quality of Focus

Fig: Software Engineering-A layered technology

38
SOFTWARE ENGINEERING-A LAYERED TECHNOLOGY
 Quality focus:
 It defines the continuous process improvement principles of
software.
It provides integrity that means providing security to the software
so that data can be accessed by only an authorized person, no
outsider can access the data. It also focuses on maintainability and
usability..
 Process
It is key that binds all the layers together which enables the
development of software before the deadline or on time.

Process defines a framework that must be established for the

effective delivery of software engineering technology.

The software process covers all the activities, actions, and39

tasks
required to be carried out for software development.
•Communication: It is the first and foremost thing for the development
of software. Communication is necessary to know the actual demand of
the client.

•Planning: It basically means drawing a map for reduced the

complication of development.

•Modeling: In this process, a model is created according to the client for

better understanding.

•Construction: It includes the coding and testing of the problem.

•Deployment:- It includes the delivery of software to the client for

evaluation and feedback.
 SOFTWARE ENGINEERING-A LAYERED TECHNOLOGY

 Methods
During the process of software development the answers to all
“how-to-do” questions are given by method.
It has the information of all the tasks which includes communication,
requirement analysis, design modeling, program construction, testing,
and support.

 Tools
Software engineering tools provide a self-operating system for
processes and methods.
Tools are integrated which means information created by one tool can
be use d by another.

41
 SOFTWARE PROCESS FRAMEWORK
 Establishes the foundation for a complete software process
 Identifiesa number of framework activities applicable to
all software projects
 Also include a set of umbrella activities that are applicable
across the entire software process.
Software process includes:

Tasks – focus on a small, specific objective.

Action – set of tasks that produce a major work product.
•Activities – group of related tasks and actions for a major
objective. 42
 A PROCESS FRAMEWORK

Process Framework activities:

The process framework is required for representing common
process activities. Five framework activities are described in
a process framework for software engineering.
Communication(consumers)
Planning(work schedule)
Modeling(Analysis of Requirements & Design)
Construction(Code Generation &Testing)
Deployment (Product)

45
 A PROCESS FRAMEWORK
 Generic view of engineering complimented by a number
of umbrella activities
 Software project tracking and control
 Risk management
 Software quality assurance
 Formal technical reviews
 Software configuration management
 Document preparation and production
 Reusability management
 Measurement

46
1.Software project tracking and control: Take action to
keep the project on time by comparing the project’s progress
against the plan.

2.Risk management: The risks that may affect project

outcomes or quality can be analyzed.

3.Software quality assurance: These are activities required

to maintain software quality.

4.Formal technical reviews: It is required to assess

engineering work products to uncover and remove errors
before they propagate to the next activity.
5.Software configuration management: Managing of
configuration process when any change in the software
occurs.
6.Work product preparation and production: The
activities to create models, documents, logs, forms, and
lists are carried out.
7.Reusability management: It defines criteria for work
product reuse. Reusable work items should be backed up,
and reusable software components should be achieved.

8.Measurement: Project and product measures are used to

assist the software team in delivering the required
software.
 Capability maturity model
integration (CMMI)
• CMM was developed by the SEI (Software engineering
institute), a research and development center. It is not a
s/w process model. CMMI used as a benchmark to
“measure the maturity of an organizations”. CMMI is
the successor to CMM
Objectives of CMMI :
1.Fulfilling customer needs and expectations.
2.Value creation for investors/stockholders.
3.Market growth is increased.
4.Improved quality of products and services.
5.Enhanced reputation in Industry.
CMMI – Maturity Levels :
In CMMI there are five maturity levels described as
follows :

Level 1 : Initial
Level 2 : Repeatable
Level 3 : Defined
Level 4 : Managed
Level 5 : Optimized
 Level 1 : Initial [Work is performed
informally]

• processes are poorly managed or controlled.

• unpredictable outcomes of processes

involved.

• ad hoc and chaotic approach used.

• No KPAs (Key Process Areas) defined.

• Lowest quality and highest risk.

Level 2 : Repeatable [Work is planned and
tracked]
 requirements are managed.

 processes are planned and controlled.

 projects are managed and implemented according to

their documented plans.

 This risk involved is lower than Initial level, but still

exists.

 Quality is better than Initial level.

.
Level 3 : Work is well-defined

• This level includes all characteristics defined for

level 2
• All this level the s/w process for management and
engineering activities are well-defined and
documented.

• Medium quality and medium risk involved.

• Focus is process standardization.

Level 4 : Work is well-managed

• quantitative objectives for process performance and

quality are set.

• quantitative objectives are based on customer

requirements, organization needs, etc.

• process performance measures are analyzed

quantitatively.
• higher quality of processes is achieved.
• lower risk
Level 5 : Work is well-optimized
• continuous improvement in processes and their
performance.
• improvement has to be both incremental and innovative.
• highest quality of processes.
• lowest risk in processes and their performance.
Tata Consultancy Services (TCS)
Infosys
Wipro Limited
HCL Technologies
Tech Mahindra
Cognizant Technology Solutions
Larsen & Toubro Infotech (LTI)
Mindtree
Capgemini India
Hexaware Technologies
.

PROCESS MODELS
What is a software process model?

Software process model is an abstraction of

the software development process. The models
specify the stages and order of a process.

So, think of this as a representation of

the order of activities of the process and
the sequence in which they are performed.
There are many kinds of process models for meeting
different requirements. We refer to these as SDLC
models (Software Development Life Cycle models).
The most popular and important SDLC models are as
follows:

•Waterfall model
•V model
•Incremental model
•RAD model
•Agile model
•Iterative model
•Prototype model
•Spiral model
SOFTWARE DEVELOPMET LIFE
CYCLE
 Requirements Gathering and
Analysis
• In this phase, We collect all the requirements
from the customer through discussion and
written in requirement specification document
called SRSsoft ware requirements specificationdocument.

• The SRS document is the base of the software

project because this document helps to develop
the whole software project.
 Design
• Inthis phase,Based on the SRS documents
prepare the system design.
• Inthe system design, we define system
arthitecture,componets,modules…..
• This helps define overall system architecture.
• Like requirements, the design is
documented
(Software Design Document (SDD).
Coding or Implementation
 In this phase, where programmers start to
develop the software by writing the code using
the programming languages.
 The code generation step performs this task.
Testing
• The testing team run our software and
check whether software gives us the desired
result or not.
• The testing process focuses on the logical
internals of the software, on the functional
externals
Deployment

• Once thetesting is the product is

delivered todone;
the environment or
customer
released into the market.
. Maintenance
• Maintenance is the task performed by every user once
the software has been delivered to the customer,
installed, and operational.
• Maintenance is the backbone of software success.
• If any changes are there in the software, contact the
developer
 The waterfall model
 The Waterfall Model is a software development
model, which was the first process Model to be
introduced by Dr.Winston W.Royce..
 This is the oldest and the most widely used model
for software engineering.
 It is also referred to as a linear-sequential life
cycle model. This means each phase must be
completed before the next phase can begin i.e
one phase to another phace.
also known as Linear life cycle model or
classic life cycle model
WATERFALL MODEL
 Project initiation & requirement gathering
 What is the Problem to Solve?
 What Does Customer Need/Want?
 Interactions Between SE and Customer
 Identify and Document System Requirements
 Generate User Manuals and Test Plans
• Planning
 Prioritize the requirements
 Plan the process
WATERFALL MODEL
 Analysis and design
 How is the Problem to be Solved?
 High-Level Design
 Determine Components/Modules
 Transition to Detailed Design
 Detail Functionality of Components/Modules
 Coding and Testing
 Writing Code to Meet Component/Module Design
Specifications
 Individual Test Modules in Isolation
 Integration of Components/Modules into Subsystems
 Integration of Subsystems into Final Program
 WATERFALL MODEL
 Deployment
 System Delivered to Customer/Market
 Bug Fixes and Version Releases Over Time
Strengths
 Easy to understand, easy to use
 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff, track)
 Works well when quality is more important than cost
or schedule
 Waterfall Drawbacks
 All projects cannot follow linear process
 All requirements must be known upfront
 Few business systems have stable requirements.
 The customer must have patience. A working version of
the program will not be available until late in the project
time-span
 Inappropriate to changes
When to use the Waterfall
Model
 Requirements are very well known
 Product definition is stable
 Technology is understood
 New version of an existing product
 Porting an existing product to a new platform.
 SPIRAL MODEL

 The Spiral Model is a Software Development Life Cycle

(SDLC) model that provides a systematic and iterative approach to
software development. In its diagrammatic representation, looks
like a spiral with many loops.

• The spiral model is combines the both waterfall and iterative

model.

• Each phase in spiral model begins with design goal and ends with
customer reviews.

• Using the spiral model, software is developed in a series of

incremental releases.
SPIRAL MODEL
What Are the Phases of Spiral Model?
The Spiral Model is a risk-driven model, meaning that the focus is
on managing risk through multiple iterations of the software
development process. It consists of the following phases:
1. Planning
The first phase of the Spiral Model is the planning phase, where the scope of the
project is determined and a plan is created for the next iteration of the spiral.
2. Risk Analysis
In the risk analysis phase, the risks associated with the project are identified and
evaluated.
3. Engineering
In the engineering phase, the software is developed based on the requirements
gathered in the previous iteration.
4. Evaluation
In the evaluation phase, the software is evaluated to determine if it meets the
customer’s requirements and if it is of high quality.
5. Planning
The next iteration of the spiral begins with a new planning phase, based on the
results of the evaluation
Spiral Model Strengths
• Risk Handling
• Good for large projects.
• Flexibility in Requirements.
• Customer Satisfaction.

Drawbacks of the Spiral Model

• Difficulty in time management
• Documentation is more due to the intermediate stages.
• It is not suitable for smaller projects.
• Expensive
When to use Spiral Model
 When creation of a prototype is appropriate
 When costs and risk evaluation is important
 For medium to high-risk projects
 Long-term project commitment unwise because of
potential changes to economic priorities
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected
Agile Methodology
What is Agile Methodology?
The Agile methodology is a project management and software
development approach that emphasizes flexibility, collaboration, and
customer-centricity.
It is the latest model used by major companies today like Facebook,
google, amazon, etc.
It follows the iterative as well as incremental approach that
emphasizes the importance of delivering of working product very
quickly.
Or
What is Agile?
Agile is a project management and software development approach
that aims to be more effective.
1.It focuses on delivering smaller pieces of work regularly instead of
one big launch.
2.This allows teams to adapt to changes quickly and provide customer
value faster.
Human Factors 8
 The process molds to the needs of the people and team. 2
 Competence.

 Common focus.
 Collaboration.

 Decision-making ability.
 Fuzzy problem-solving ability.
 Mutual trust and respect.
 Self-organization.
Agility and the Cost of Change
8
3
Agile Model
The meaning of Agile is swift or versatile. "Agile process
model" Agile SDLC model is a combination of iterative and
incremental process models with focus on process adaptability and
customer satisfaction by rapid delivery of working software
product..
 Each iteration is considered as a short time "frame" in the Agile
process model, which typically lasts from one to four weeks.

 The division of the entire project into smaller parts helps to

minimize the project risk and to reduce the overall project delivery
time requirements.

 Each iteration involves a team working through a full software

development life cycle before a working product is demonstrated
to the client.
Phases of Agile Model:
1.Requirements gathering
2.Design the requirements
3.Construction/ iteration
4.Testing/ Quality assurance
5.Deployment
6.Feedback
1. Requirements gathering: In this phase, you must define the
requirements. You should explain business opportunities and plan the time
and effort needed to build the project. Based on this information, you can
evaluate technical and economic feasibility.

2.Design the requirements: When you have identified the project,

work with stakeholders to define requirements. You can use the user flow
diagram or the high-level UML diagram to show the work of new features
and show how it will apply to your existing system.
3. Construction/ iteration: When the team defines the requirements,
the work begins. Designers and developers start working on their
project, which aims to deploy a working product. The product will
undergo various stages of improvement, so it includes simple, minimal
functionality.
4. Testing: In this phase, the Quality Assurance team examines the
product's performance and looks for the bug.
5. Deployment: In this phase, the team issues a product for the user's
work environment.
6. Feedback: After releasing the product, the last step is feedback. In
this, the team receives feedback about the product and works through
the feedback.
Advantage of Agile Method:
1.Frequent Delivery
2.Face-to-Face Communication with clients.
3.Efficient design and fulfils the business requirement.
4.Anytime changes are acceptable.
5.It reduces total development time.

Disadvantages(Cons) of Agile Model:

1.Due to the shortage of formal documents, it creates confusion and
crucial decisions taken throughout various phases can be
misinterpreted at any time by different team members.

2.Due to the lack of proper documentation, once the project

completes and the developers allotted to another project,
maintenance of the finished project can become a difficulty.
When to use the Agile Model?
1.Unclear or Changing Requirements:
2.Complex Projects:
3.Customer Focus:
4.Quick Time-to-Market:
5.Small to Medium Teams:
6.Team Skills:
7.Collaboration: .
8.Regular Updates:
9.Transparency:
10.Risk Control:
11.Innovation:
12.Continuous Improvement:
Agile Testing Methods:

•Scrum
•Crystal
•DynamicSoftware Development Method(DSDM)
•Feature Driven Development(FDD)
•Lean Software Development
•eXtreme Programming(XP)
Scrum 9
 Originally proposed by Schwaber and Beedle 2
 Scrum—distinguishing features
Development work is partitioned into “packets”
Testing and documentation are on-going as the product
is constructed
Work occurs in “sprints” and is derived from a
“backlog” of existing requirements
Meetings are very short and sometimes conducted
without chairs
“demos” are delivered to the customer with the time-
box allocated
Scrum Development process
SCRUM is an agile development process focused primarily on ways
to manage tasks in team-based development conditions.

There are three roles in it, and their responsibilities are

•Scrum Master: The scrum can set up the master team,

arrange the meeting and remove obstacles for the process

•Product owner: The product owner makes the product

backlog, prioritizes the delay and is responsible for the
distribution of functionality on each repetition.

•Scrum Team: The team manages its work and organizes the
work to complete the sprint or cycle.
Scrum 9
4

A sprint is a set period of time during which specific

work has to be completed and made ready for review.
9
5
 Crystal
There are three concepts of this method-
1.Chartering: Multi activities are involved in this phase such as
making a development team, performing feasibility analysis,
developing plans, etc.
2.Cyclic delivery: under this, two more cycles consist, these are:
1. Team updates the release plan.
2. Integrated product delivers to the users.
3.Wrap up: According to the user environment, this phase performs
deployment, post-deployment.
Crystal—distinguishing features
 Actually a family of process models that allow
“maneuverability” based on problem characteristics
 Face-to-face communication is emphasized
 Suggests the use of “reflection workshops” to
review the work habits of the team
Adaptive Software Development(ASD)
9
 Originally proposed by Jim Highsmith 7

 ASD — distinguishing features

 Mission-driven planning
 Component-based focus
 Uses “time-boxing”
 Explicit consideration of risks
 Emphasizes collaboration for requirements
gathering
 Emphasizes “learning” throughout the process
Adaptive Software Development
9
8
Dynamic Systems Development Method
9
 DSDM—distinguishing features 9
 Similar in most respects to XP and/or ASD
Guiding principles
Active user involvement is imperative.
DSDM teams must be empowered to make decisions.
The focus is on frequent delivery of products.
Fitness for business purpose is the essential criterion
for acceptance of deliverables.
Iterative and incremental development is necessary
to converge on an accurate business solution.
All changes during development are reversible.
Requirements are baselined at a high level
Testing is integrated throughout the life-cycle.
 Dynamic Systems Development Method
1
0
0

DSDM Life Cycle (with permission of the DSDM consortium)

 Feature Driven Development(FDD)
 Originally
1
proposed by Peter Coad et al 0
 FDD—distinguishing features 1
 Emphasis is on defining “features”
 a feature “is a client-valued function that can be
implemented in two weeks or less.”
 Uses a feature template
<action> the <result> <by | for | of | to> a(n)
<object>
 A features list is created and “plan by feature” is
conducted
 Design and construction merge in FDD
Feature Driven
1
Development 0
2
eXtreme Programming(XP)

This type of methodology is used when customers are

constantly changing demands or requirements, or when
they are not sure about the system's performance.
 Extreme Programming (XP)
 XP Design 1
Follows the KIS principle 0
Encourage the use of CRC cards
4
For difficult design problems, suggests the creation of “spike
solutions”—a design prototype
Encourages “refactoring”—an iterative refinement of the internal
program design
 XP Coding
Recommends the construction of a unit test for a store before
coding commences
Encourages “pair programming”
 XP Testing
All unit tests are executed daily
“Acceptance tests” are defined by the customer and executed to
assess customer visible functionality
Extreme Programming (XP) 1
0
5
1
0
7
Lean Software Development:
Lean software development methodology follows the principle "just
in time production." The lean method indicates the increasing speed
of software development and reducing costs. Lean development can
be summarized in seven phases.

1.Eliminating Waste
2.Amplifying learning
3.Defer commitment (deciding as late as possible)
4.Early delivery
5.Empowering the team
6.Building Integrity
7.Optimize the whole
 Agility Principles - I
1. Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
Agile processes harness change for the customer's
competitive advantage.
3. Deliver working software frequently, from a couple of weeks
to a couple of months, with a preference to the shorter
timescale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the
job done.
6. The most efficient and effective method of conveying
information to and within a development team is face–to–
face conversation.
Agility Principles - II
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.
The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good
design enhances agility.
10. Simplicity – the art of maximizing the amount of
work not done – is essential.
11. The best architectures, requirements, and designs
emerge from self–organizing teams.
12. At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.