SEPM_MODULE 2 PPT.pptx

Software Engineering & Project Management
1
Department of Computer Science & Engineering
Course Code: 19CS3606 Semester: VI
Course Title: Software Engineering & Project Management Year: III
Faculty Name: Dr Meenakshi Malhotra

MODULE 2 :Syllabus
Process models:
A simple safety- critical system; System dependability; Availability and reliability, the
waterfall model, Incremental process models, Evolutionary process models, The Unified
process. Comparison of different models with case studies, Agile Development: Agile Tech,
Extreme Programming, and other Agile Process Models: Scrum Methodology
(TB1 : Ch3, TB2: 4.1, 5.3,5.4, 5.5.1)
2

3
Outline
 Process models:
 A simple safety- critical system;
 System dependability;
 Availability and reliability
 The waterfall model
 Incremental process models,
 Evolutionary process models
 The Unified process.
 Agile Process and Development.
 Extreme Programming.
 Agile Process Models- Scrum Methodology

 To explain what is meant by a critical system.
 To explain four dimensions of dependability
 To achieve dependability- avoid mistakes, detect or remove errors and limit damage caused by failure.
 Explain the different concepts and various software development models like
The waterfall model
Incremental process models,
Evolutionary process models
The Unified process.
Agile Process and Development.
Extreme Programming.
Agile Process Models- Scrum Methodology
Objectives

Critical Systems
A simple safety- critical system;
System dependability;
Availability and reliability,

 A critical system is a system which must be highly reliable and retain this
reliability.
Critical Systems
 Safety-critical systems are those systems whose failure could result in loss of
life, significant property damage or damage to the environment

Critical Systems
 Four types of critical systems:
• Safety Critical = >failure may result in injury, loss
of life or serious environmental damage.
• Mission Critical = > failure of some goal-directed activity.
• Business Critical => failure may result in very high costs
for the business using that system
• Security Critical => failure may result in breach of security

8
A general model of the design process

 The dependability of a system
reflects the user’s degree of trust
in that system.
 Usefulness and trustworthiness
are not the same thing.
 A system does not have to be
trusted to be useful.
System dependability

 The costs of critical system failure are so high that development methods may be
used that are not cost-effective for other types of system.
 Examples of development methods
• Formal methods of software development
• Static analysis
• External quality assurance
Development methods for critical systems

 Hardware failure:
• Components fail
 Software failure:
• mistakes in its specification, design or
implementation.
 Operational failure:
• Human operators
Socio-technical critical systems

Used by diabetics to simulate the
function of the pancreas which
manufactures insulin.
Measures blood glucose (sugar) using a
micro-sensor and computes the insulin
dose required to metabolize the glucose.
A Software-controlled Insulin Pump

High-level dependability requirements for insulin pump system:
 The system shall be available to deliver insulin when required.
 The system shall perform reliably and deliver the correct
amount of insulin to counteract the current level of blood sugar
Dependability

The dependability of a system <==>its trustworthiness.
Dependability
Principal dimensions of dependability are:
 Availability
 Reliability
 Safety
 Security

Dimensions of dependability
Integrity Confidentiality
Correctness Precision Timeliness

Other Dependability Properties

Dependability: other Dimensions
Repairability
Maintainability
Survivability
Error tolerance
diagnose the problem, access the component and make
changes to fix that component
• adapted economically to cope with new requirements and
• a low probability to introduce new errors into the system.
• deliver a minimal service. Three strategies to enhance
survivability—
• resistance to attack, attack recognition and recovery from
the damage caused by an attack
user input error are avoided and tolerated.

Dependability
vs
Performance
 Untrustworthy systems may be rejected by
their users
 System failure costs may be very high
 It is very difficult to tune systems to make
them more dependable
 It may be possible to compensate for poor
performance
 Untrustworthy systems may cause loss of
valuable information

Dependability costs tend to increase exponentially as increasing levels of
dependability are required
Dependability Costs

 Because of very high costs of dependability
achievement, it may be more cost effective
to accept untrustworthy systems and pay for
failure costs
 However, this depends on social and
political factors. A reputation for products
that can’t be trusted may lose future
business
 Depends on system type - for business
systems in particular, modest levels of
dependability may be adequate
Dependability Economics

 Reliability
 Availability
Both of these attributes can be expressed quantitatively
Availability and reliability
• The probability of failure-free system operation over a specified time in a
given environment for a given purpose
• The probability that a system, at a point in time, will be operational and
able to deliver the requested services

Reliability terminology
Term Description
Human error or
mistake
Human behavior that results in the introduction of faults into a system
System fault A characteristic of a software system that can lead to a system error.
System error An erroneous system state that can lead to system behavior that is unexpected
by system users.
System failure An event that occurs at some point in time when the system does not deliver a
service as expected by its users.

Reliability terminology
Term Description
Human error or
mistake
Human behavior that results in the introduction of faults into a system. For
example, in the wilderness weather system, a programmer might decide that the
way to compute the time for the next transmission is to add 1 hour to the current
time. This works except when the transmission time is between 23.00 and
midnight (midnight is 00.00 in the 24-hour clock).
System fault A characteristic of a software system that can lead to a system error. The fault is
the inclusion of the code to add 1 hour to the time of the last transmission,
without a check if the time is greater than or equal to 23.00.
System error An erroneous system state that can lead to system behavior that is unexpected
by system users. The value of transmission time is set incorrectly (to 24.XX rather
than 00.XX) when the faulty code is executed.
System failure An event that occurs at some point in time when the system does not deliver a
service as expected by its users. No weather data is transmitted because the time
is invalid.

 You can model a system as an input-outputs where some inputs will result in
erroneous outputs
 The reliability of the system is the probability that a particular input will lie in the
set of inputs that cause erroneous outputs
 Different people will use the system in different ways, so this probability is not a
static system attribute but depends on the system’s environment
Reliability modelling

Reliability Perception
SOFTWARE RELIABILITY is defined as the probability of failure-free operation of a
software system for a specified time in a specified environment.

 A study at IBM showed that removing 60% of
product defects resulted in a 3% improvement in
reliability
 Removing these does not affect the perceived
reliability
Reliability Improvement

Safety is a property of a system that reflects the system’s
ability to
 operate, normally or abnormally,
 without danger of causing human injury or death and
 without damage to the system’s environment
Safety

 Safety and reliability are related but distinct
 In general, reliability and availability are necessary but not sufficient
conditions for system safety
 Reliability is concerned with conformance to a given specification and
delivery of service
 Safety is concerned with ensuring system cannot cause damage
irrespective of whether or not it conforms to its specification
Safety and Reliability

 Hazard avoidance
 Hazard detection and removal
 Damage limitation
Safety achievement

 Accidents in complex systems rarely have a single cause as these
systems are designed to be resilient to a single point of failure
 Almost all accidents are a result of combinations of malfunctions
Normal accidents

 The security of a system is a system property that reflects the system’s ability to protect itself
from accidental or deliberate external attack.
 Security is becoming increasingly important as systems are networked so that external access
to the system through the Internet is possible
 Security is an essential pre-requisite for availability, reliability and safety
Security

Denial of service
Corruption of programs or data
Disclosure of confidential information
Damage from Insecurity

Vulnerability
avoidance
Attack
detection
and
elimination
Exposure
limitation
Security assurance

 Help in the software development
 Guide the software team through a set of
framework activities
 Process Models may be linear, incremental or
evolutionary
PROCESS MODELS The purpose of
process models is to
try to reduce the
chaos present in
developing new
software products.

 But are prescriptive models appropriate for a software world that thrives on
change?
PRESCRIPTIVE PROCESS MODELS
 If we reject traditional process models (and the order they imply) and
replace them with something less structured, do we make it impossible to
achieve coordination and coherence in software work?

Project Management Approaches
There are two main approaches to Project Management.
Agile
Approach
Waterfall
Approach

Waterfall vs.AgileApproach
The Standish Group Study—CHAOS Manifesto showed that software development projects
succeed three times more often when the agile approach is used.
CHAOS Project Database – 2002 to 2010

44
Software Process Models
The waterfall model
 Plan-driven model. Separate and distinct phases of specification and
development.
Incremental development
 Specification, development and validation are interleaved. May be plan-driven
or agile.
Integration and configuration
 The system is assembled from existing configurable components. May be plan-
driven or agile.
 In practice, most large systems are developed using a process that incorporates
elements from all of these models.

Used when requirements are well understood in the beginning
Also called classic life cycle
A systematic, sequential approach to Software development
Begins with customer specification of Requirements and
progresses through planning, modeling, construction and
deployment
THE WATERFALL MODEL

THE WATERFALL MODEL
Traditionally used to plan and deliver software development projects.

This model suggests a systematic, sequential approach to SW
development that begins at the system level and progresses through
analysis, design, code and testing
The Waterfall Model

Used when requirements are well understood in the
beginning
Also called classic life cycle
A systematic, sequential approach to Software
development
Begins with customer specification of Requirements
and progresses through planning, modeling,
construction and deployment
THE WATERFALL MODEL

51
The Waterfall Model Variation : V-model
V-model provides a way of
visualizing how
verification and
validation actions are
applied to earlier
engineering work.

52
Waterfall Model Phases
 There are separate identified phases in the waterfall model:
 Requirements analysis and definition
 System and software design
 Implementation and unit testing
 Integration and system testing
 Operation and maintenance
 The main drawback of the waterfall model is the difficulty of accommodating
change after the process is underway.
 In principle, a phase has to be complete before moving onto the next phase.

Real projects rarely follow the
sequential flow since they are always
iterative
The model requires requirements to be
explicitly spelled out in the beginning,
which is often difficult
A working model is not available until
late in the project time plan
PROBLEMS IN WATERFALL MODEL

 Linear sequential model is not suited for projects which are iterative
in nature
 Incremental model suits such projects
 Used when initial requirements are reasonably well-defined and
compelling need to provide limited functionality quickly
 Functionality expanded further in later releases
 Software is developed in increments
THE INCREMENTAL PROCESS MODEL

 Software releases in increments
 1st increment constitutes Core product
 Basic requirements are addressed
 Core product undergoes detailed evaluation by the customer
 As a result, plan is developed for the next increment
 Plan addresses the modification of core product to better meet the needs
of customer
 Process is repeated until the complete product is produced
THE INCREMENTAL MODEL

 An incremental software process model
 Having a short development cycle
 High-speed adoption of the waterfall model using a
component based construction approach
 Creates a fully functional system within a very short
span time of 60 to 90 days
THE RAD MODEL(Rapid Application Development)

 Multiple software teams work in parallel on different functions
 Modeling encompasses three major phases:
 Business modeling, Data modeling and process modeling
 Construction uses reusable components, automatic code generation and testing
Problems in RAD
★ Requires a number of RAD teams
★ Requires commitment from both developer and customer for rapid-
fire completion of activities
★ Requires modularity
★ Not suited when technical risks are high

 Software evolves over a period of time
 Business and product requirements often change as development proceeds
making a straight-line path to an end product unrealistic
 Evolutionary models are iterative and as such are applicable to modern day
applications
 Types of evolutionary models
 Prototyping
 Spiral model
 Concurrent development model
EVOLUTIONARY PROCESS MODEL

 Mock up or model( throw away version) of a software product
 Used when customer defines a set of objective but does not identify
the input, output, or processing requirements
 Developer is not sure of:
 Efficiency Of An Algorithm
 Adaptability Of An Operating System
 Human/Machine Interaction
PROTOTYPING

 Begins with requirement gathering
 Identify whatever requirements are known
 Outline areas where further definition is mandatory
 A quick design occur
 Quick design leads to the construction of prototype
 Prototype is evaluated by the customer
 Requirements are refined
 Prototype is turned to satisfy the needs of customer
STEPS IN PROTOTYPING

 In a rush to get it working, overall software quality or long term
maintainability are generally overlooked
 Use of inappropriate OS or PL
 Use of inefficient algorithm
LIMITATION OF PROTOTYPING

 An evolutionary model which combines the
best feature of the classical life cycle and the
iterative nature of prototype model
 Include new element : Risk element
 Starts in middle and continually visits the basic
tasks of communication, planning, modeling,
construction and deployment
THE SPIRAL MODEL

THE SPIRAL MODEL
 The spiral development model is a risk -driven process model generator that is
used to guide multi-stakeholder concurrent engineering of software intensive
systems.
 It has two main distinguishing features.
 One is a cyclic approach for incrementally growing a system’s degree of
definition and implementation while decreasing its degree of risk.
 The other is a set of anchor point milestones for ensuring stakeholder
commitment to feasible and mutually satisfactory system solutions.
Boehm [Boe01a] describes the model in the following manner:

THE SPIRAL MODEL
Anchor point milestones —a
combination of work products
and conditions that are
attained along the path of the
spiral— are noted for each
evolutionary pass.
A typical spiral model

COMMUNICATION
Tasks required are establish effective
communication between developer
PLANNING
Estimation
Scheduling
Risk analysis
MODELING
Analysis
Design
THE SPIRAL MODEL

CONSTRUCTION
Code
Test
DEPLOYMENT
Delivery
Feedback
THE SPIRAL MODEL

 Realistic approach to the development of large scale system and software
 Software evolves as process progresses
 Better understanding between developer and customer
 The first circuit might result in the development of a product specification
 Subsequent circuits develop a prototype
 And sophisticated version of software
THE SPIRAL MODEL
 If the management demands fixed-budget development (generally a
bad idea), the spiral can be a problem.
 As each circuit is completed, project cost is revisited and revised.

The Concurrent Development Model
Concurrent modeling defines a series of events that will trigger transitions from one
state to another state for each of the software engineering activities, actions, or tasks.
 Also called concurrent engineering
 Constitutes a series of framework activities, software engineering action, tasks and
their associated states

 All activities exist concurrently but reside in different states
 Applicable to all types of software development
 Event generated at one point in the process trigger transitions among
the states

 Difficult in project planning == > uncertain number of cycles required to construct the
product
 Speed of evolution is not known == > Chaos vs productivity
 Does not focus on flexibility and extensibility (more emphasis on high
quality)
 Requirement is balance between high quality and flexibility and
extensibility
A final comment on Evolutionary process
 The intent of evolutionary models is to develop high-quality software in an iterative or
incremental manner.
 However, it is possible to use an evolutionary process to emphasize flexibility,
extensibility, and speed of development

 Evolved by Rumbaugh, Booch, Jacobson
 Combines the best features their models
 Adopts additional features proposed by other experts
 Resulted in Unified Modeling Language(UML)
 A framework for Object-Oriented Software Engineering using UML
The Unified Process

• The Unifi ed Process is sometimes called the Rational Unified Process (RUP)
after the Rational Corporation (subsequently acquired by IBM), an early
contributor to the development and refinement of the UP and a builder of
complete environments (tools and technology) that support the process.
The Unified Process

1. Inception Phase
2. Elaboration Phase
3. Construction Phase
4. Transition Phase
Phases of Unified Process

Inception Phase: both customer communication and planning activities.
By collaborating with stakeholders, business requirements for the software are
identified;
a rough architecture for the system is proposed;
and a plan for the iterative, incremental nature of the ensuing project is developed.
Fundamental business requirements are described through a set of preliminary use cases
that describe which features and functions each major class of user's desires.
Architecture at this point is nothing more than a tentative outline of major subsystems and
the functions and features that populate them.
Planning identifies resources, assesses major risks, defines a schedule, and establishes a
basis for the phases that are to be applied as the software increment is developed.
Phases of the Unified Process
Tasks which are required to be completed during different phases

Elaboration Phase: both the communication and modeling activities.
refines and expands the preliminary use cases that were developed as part of the
inception phase and
expands the architectural representation to include five different views of the
software—
 the use case model,
 the analysis model,
 the design model,
 the implementation model, and
 the deployment model.
In some cases, elaboration creates an “executable architectural baseline” that
represents a “first cut” executable system.
The architectural baseline demonstrates the viability of the architecture
Modifications to the plan
are often made at this time.

construction Phase:.
 analysis and design models that were started during the elaboration phase
are completed to reflect the final version of the software increment.
 All necessary and required features and functions for the software
increment (i.e., the release) are then implemented in source code.
 unit tests are designed and executed for each.
 integration activities (component assembly and integration testing) are
conducted.
 Use cases are used to derive a suite of acceptance tests

Transition Phase:.
 latter stages of the generic construction activity and the first part of the
generic deployment (delivery and feedback) activity
 given to end users for beta testing, and
 user feedback reports both defects and necessary changes.
 the software team creates the necessary support information (e.g., user
manuals, troubleshooting guides, installation procedures) that is required for
the release.
 At the conclusion of the transition phase, the software increment becomes a
usable software release

Production Phase: coincides with the deployment activity
 the ongoing use of the software is monitored,
 support for the operating environment (infrastructure) is provided, and
 Defect reports and requests for changes are submitted and evaluated

Inception Phase
*Vision document
*Initial Use-Case model
*Initial Risk assessment
*Project Plan
Elaboration Phase
*Use-Case model
*Analysis model
*Software Architecture description
*Preliminary design model
*Preliminary model
Unified Process Work Products
Tasks which are required to be completed during different phases

Construction Phase
*Design model
*System components
*Test plan and procedure
*Test cases
*Manual
Transition Phase
*Delivered software increment
*Beta test results
*General user feedback
Unified Process Work Products
the five UP phases do not occur
in a sequence, but rather with
staggered concurrency.
Production Phase
*Monitor
*Support for operating environment
*Defect Reports
*Change Requests

Comparison between different software
development models

Agile Software Development Process

95
Agility
 The ability to create and respond to change in order to profit in a unstable global
business environment.
 The ability to quickly reprioritize use of resources when requirements,
technology, and knowledge shift.
 A very fast response to sudden market changes and emerging threats by
intensive customer interaction.
 Use of evolutionary, incremental, and iterative delivery to converge on an
optimal customer solution.
 Maximizing BUSINESS VALUE with right sized, just- enough, and just-in-time
processes and documentation.
Agility is ability to move quickly and easily.
It is a property consisting of quickness, lightness, &
ease of movement.

96
What is Agility?
Current Functionality
Change Request
Effective
response
to change
Effective
communication
among all
stakeholders
Organizing a team
so that it is in
control to perform
the work
Customer
Drawing the
customer onto
the team
Eliminate the
“us and them”
attitude
Development
Team
Rapid and Incremental delivery of
software

97
Agile Process
• Agile software process addresses few assumptions
 An agile process must adapt incrementally.
 To accomplish incremental adaptation, an agile team requires customer feedback (so that
the appropriate adaptations can be made).
Analysis, design, construction and testing are not as predictable as we might like.
Difficulty in predicting changes of requirements and customer priorities.
For many types of software; design and construction are interleaved (mixed).

98
Agile Process
 allows the project team to adapt tasks and to streamline them,
 conduct planning in a way that understands the fluidity of an agile
development approach,
 eliminate all but the most essential work products and keep them lean, and
 emphasize an incremental delivery strategy that gets working software to the
customer as rapidly as feasible for the product type and operational
environment.
The process be designed in a way that
Agility can be applied to any software process

99
Agile Process
An agile process reduces the cost of change because
 software is released in increments and
 change can be better controlled within an increment.

100
Agility Principles
• Highest priority is to satisfy the customer through early & continuous delivery of software
• Welcome changing requirements
• Deliver working software frequently
• Business people and developers must work together
• Build projects around motivated individuals
• Emphasize face-to-face conversation
• Working software is the measure of progress
• promote sustainable development.
• Continuous attention to technical excellence and good design
• Simplicity – the art of maximizing the amount of work done
• The best designs emerge from self-organizing teams
• The team tunes and adjusts its behaviour to become more effective

101
Where agile methodology not work
Project plan &
requirements are
clear & unlikely to
change
Unclear
understanding of
Agile Approach
among Teams
Big Enterprises where
team collaboration is
tough

102
Agile Process Models
Extreme Programming (XP)
Adaptive Software Development (ASD)
Dynamic Systems Development Method (DSDM)
Feature Driven Development (FDD)
Crystal
Agile Modelling (AM)

103
Extreme Programming (XP)
• The most widely used approach to agile software development
• A variant of XP called Industrial XP (IXP) has been proposed to target
process for large organizations
• It uses object oriented approach as its preferred development model
XP Values
 Communication: To achieve effective communication, it emphasized close & informal
(verbal) collaboration between customers and developers
 Simplicity: It restricts developers to design for immediate needs not for future needs
 Feedback: It is derived from three sources the implemented software, the customer and
other software team members, it uses Unit testing as primary testing
 Courage: It demands courage (discipline), there is often significant pressure to design for
future requirements, XP team must have the discipline (courage) to design for today
 Respect: XP team respect among members

104
The XP Process
It considers four framework activities
1. Planning  2. Design  3. Coding  4. Testing
class-responsibility-
collaborator (CRC)

105
The XP Process
It considers four framework activities
1. Planning  2. Design  3. Coding  4. Testing
CRC index Card

106
The XP Process Planning
User Stories
• Customers assigns value (priority)
• Developers assigns cost (number of development weeks)
Project velocity
• Computed at the end of first release
• =Number of stories implemented in first release
• Estimates for future release
• Guard against over-commitment

107
The XP Process cont.
• Keep-it-Simple (Design of extra functionality is discouraged)
• Preparation of CRC card is work project
• CRC cards identify and organize object oriented classes
• Spike Solutions (in case of difficult design problem is encountered)
• Operational prototype intended to clear confusion
• Refactoring
• Modify internals of code, No observable change
Design
CRC card
Spike Solutions
 If a difficult design problem is encountered as part
of the design of a story, XP recommends the
immediate creation of an operational prototype of
that portion of the design--- >Called a spike solution
 the design prototype is implemented and evaluated.
 The intent is to lower risk when true
implementation starts and to validate the original
estimates for the story containing the design
problem.
• 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 the
internal structure.
 It is a disciplined way to clean up code [and
modify/simplify the internal design] that minimizes
the chances of introducing bugs.
 In essence, when you refactor you are improving
the design of the code after it has been written.

108
The XP Process cont.
• Keep-it-Simple (Design of extra functionality is discouraged)
• Preparation of CRC card is work project
• CRC cards identify and organize object oriented classes
• Spike Solutions (in case of difficult design problem is encountered)
• Operational prototype intended to clear confusion
• Refactoring
• Modify internals of code, No observable change
Design
CRC card
Coding
• Develops a series of Unit test for stories included in current release
• Complete code perform unit-test to get immediate feedback
• XP recommend pair-programming, “Two heads are better than one”
• Integrate code with other team members, this “continuous integration” helps to
avoid compatibility & interfacing problems, “smoke testing” environment to
uncover errors early
• Unit test by developers & fix small problems
• Acceptance tests - Specified by customer
• This encourages regression testing strategy whenever code is modified
Testing

Agile Methods eXtreme Programming (XP)
XP is the second most common Agile method;
 it developed the practices of continuous integration and pair programming.

Agile Methods -Industrial eXtreme Programming (IXP)
IXP differs most from the original XP in
 its greater inclusion of management,
 its expanded role for customers, and
 its upgraded technical practices

Industrial eXtreme Programming (IXP)
IXP incorporates six new practices
1. Readiness assessment:
all members of the project community are on board,
2. Project community.
right people, with the right skills and training have been staged
3. Project chartering.
appropriate business justification for the project exists
4. Test-driven management.
establishes a series of measurable “destinations”
5. Retrospectives.
review examines “issues, events, and lessons-learned” across a software increment and/or the entire
software release.
6. Continuous learning.

What is Scrum?
A scrum is a method of restarting
play in rugby that involves players
packing closely together with their
heads down and attempting to
gain possession of the ball.
a usually brief and disorderly struggle or fight

113
What is Scrum?
It is a lightweight process framework.
Lightweight means the overhead of the process is kept as small as possible in order to maximize
the productivity.
Sprint
Product
Product Backlog Product Owner
Scrum is an agile process model which is used for developing the complex software systems.
Daily
Scrum
Meeting

Scrum
Of all Agile methods, Scrum is the most popular.
In fact nearly two thirds of all Agile projects use the Scrum method.

Agile Methods — Scrum
Scrum is a framework that uses tools and practices developed for other Agile
methods.

118
Scrum Framework at a Glance
Inputs from Customers,
Team, Managers
Product Owner
Product
Backlog
Sprint Planning
Meeting
Sprint
Backlog
Scrum
Master
Daily Scrum
Meetings
Sprint Review
Finished Work
Sprint Retrospective
Team Selects starting at
top as much as it can
commit to deliver by end
of sprint
Prioritized list of what is
required: features, bugs to fix...
Sprint end date and team
deliverable do not
change

119
Scrum cont.
Backlog
 It is a prioritized list of project requirements or features that must be provided to the
customer.
 The items can be included in the backlog at any time.
 The product manager analyses this list and updates the priorities as per the requirements.
User Stories

120
Scrum cont.
Sprint
 Theses are short duration milestones that allow teams to tackle a manageable chunk of a
project
 These are the work units that are needed to achieve the requirements mentioned in the
backlogs.
 Typically the sprints have a fixed duration or time box (of 2 to 4 weeks, 30 days).
 Change is not introduced during the sprint.
 Thus sprints allow the team members to work in a stable and short-term environment

123
Scrum Meetings
 There are 15 minutes daily meetings to report the completed activities, obstacles and
plan for next activities.
 Following are three questions that are mainly discussed during the meetings.
1. What are the tasks done since last meeting ?
2. What are the issues that team is facing ?
3. What are the next activities that are planned?
 The scrum master leads the meeting and analyses the response of each team member.
 Scrum meeting helps the team to uncover potential problems as early as possible
 It leads to “knowledge socialization” & promotes “self-organizing team structure”
Demo
Scrum cont.
 Deliver software increment to customer
 Implemented functionalities are demonstrated to the customer

124
Adaptive Software development (ASD)
• This is a technique for building complex software systems using iterative approach.
• ASD focus on working in collaboration and team self-organization.
ASD incorporates three phases
1. Speculation, 2. Collaboration & 3.
Learning
Speculation
 The adaptive cycle planning is conducted.
 In this cycle planning mainly three types of
information is used
Customer’s mission statement
Project constraints
(Delivery date, budgets etc…)
Basic requirements of the project

125
Adaptive Software development (ASD) cont.
Collaborati
on
 In this, collaboration among the
members of development team is a
key factor.
 For successful collaboration and
coordination it is necessary to have
following qualities in every individual
Learning
 Emphasize is on learning new
skills and techniques.
 There are three ways by which the
team members learn
Assist each other without resentment (offense)
Work hard Posses the required skill
set
Communicate problems and help each
other
Criticize without any hate
Focus groups
The feedback from the end-users is
obtained.
Formal technical review
This review is conducted for better quality.
Postmortems
Team analyses its own performance and
makes appropriate improvements.

126
Dynamic Systems Development Methods (DSDM)
Various phases of this life cycle model
 Feasibility study: By analysing the business requirements and constraints the
viability of the application is determined
 Business study: The functional and informational requirements are identified and
then the business value of the application is determined
 Functional model iteration: The incremental approach is adopted for
development
 Design and build iteration: If possible design and build activities can be carried
out in parallel

127
Feature Driven Development (FDD)
It is practical
process model
for object
oriented
software
engineering
In FDD, the feature means client valued
function.

128
Feature Driven Development (FDD) cont.
1. Develop overall
model
 The high-level walkthrough of scope
and detailed domain walkthrough are
conducted to create overall models.
2. Build feature list
 List of features is created and
expressed in the following form
<action> the <result> <by for of to> a(n)
<object>
For Ex. “Display product-specifications of the
product”
3. Plan by feature
 After completing the feature list the
development plan is created
Design by feature
 For each feature the sequence
diagram is created
Build by feature
 Finally the class owner develop the
actual code for their classes

SEPM_MODULE 2 PPT.pptx

Recommended

Recommended

More Related Content

Similar to SEPM_MODULE 2 PPT.pptx

Similar to SEPM_MODULE 2 PPT.pptx (20)

More from VaishaliBagewadikar

More from VaishaliBagewadikar (7)

Recently uploaded

Recently uploaded (20)

SEPM_MODULE 2 PPT.pptx