Software Engineering (303105253)

Unit – 1: Introduction to Software & Software Engineering

Dr. Rachit Adhvaryu,
Assistant Professor, Computer Science & Engineering
 Outline
Looping
▪ Software, Characteristics of Software, Software Application Domains
▪ Software Engineering, Software Engineering Layered Approach
▪ Software Process, Process Framework Activities , Umbrella Activities
▪ Software Myths
• Management Myth
• Customer Myth
• Practitioner's/Developer Myth)
▪ Software Process Models
• The Waterfall Model
• Incremental Process Model
• Prototyping Model, Spiral Model
• Spiral Model
• Rapid Application Development Model (RAD)
▪ Component based Development
Why to Study Software Engineering?
Software Development Life Cycle without Software Engineering

1 2 3 4 5
How the How the How the How the How the
Customer Project System Programmer Business
Explains Leader Analyst Works Consultant
Requirement understand it design it on it describe it

3
Why to Study Software Engineering?
Software Development Life Cycle without Software Engineering

6 7 8 9 10

How the What How the How it What the

Project Operations Customer was customer
documented Installed billed supported really needed

4
SDLC without Software Engineering

Customer Requirement Solution The software

• Have one trunk • Have one trunk development
• Have four legs • Have four legs process needs to be
• Should carry load both • Should carry load both engineered
passenger & cargo passenger & cargo
• Black in color • Black in color
to avoid the
• Should be herbivorous • Should be herbivorous communication gap
& to meet the actual
Our value requirements of
customer
added,
within stipulated budget
also gives & time
milk
5
Software Engineering
Engineering

Design Build Product

Software Engineering

6
Software is dead…..!
 The old School view of Software
 You buy it
 You own it &
 It’s your job to manage it
 That is coming to an end

 Because of web 3.0 & extensive computing power,

there is a different generation of software
 It is delivered via Internet
 It looks exactly like it’s residing on each user’s
computing device
 Actually it reside on far away server

7
What is Software?

Software is
1) Computer program that when executed provide desired features, function & performance
2) Data Structure that enable programs to easily manipulate information
3) Descriptive information in both hard and soft copy that describes the operation and use of
programs

+ +
Computer Data Documents
Program Structure Soft & Hard
8
List of documentation & manuals
Formal Specification
Analysis / Documentation Manuals
Context Diagram
Specification
Data Flow Diagram
User Manuals Operational
Manuals
Documentation

Flow Charts
Design
Manuals

ER Diagram System Installation

Overview Guide
Source Code Listings
Implementation Beginner’s
Cross-Reference Listings Guide Tutorials System
Administration
Test Data Guide
Reference
Testing Guide
Test Results

9
Characteristics of Software
 Software is developed or engineered
 It is not manufactured like hardware
▪ Manufacturing phase can introduce quality problem that are nonexistent (or easily
corrected) for software
▪ Both requires construction of “product” but approaches are different
 Software doesn’t “wear-out” Increate failure rate due to
Change side effect
Infant
“Wear out”
Failure Rate

Failure Rate
morality

Actual Curve

Idealized Curve
Time Time

Bathtub curve of hardware failure Software failure curve

10
Software Application Domains

System
• System Software
Software
• Application Software Point of Sale,
Artificial Customized
• Engineering / Application
intelligence Software
Software
Scientific Software Software

• Embedded Software Software

• Product line Software Application Engineering
Web
• Web Application Domains / Scientific
Application
Software
• Artificial intelligence
Software
Product line Embedded
Software Software

11
Software Engineering

Software engineering is the establishment and use of sound

engineering principles in order to obtain economical software
that is reliable and works efficiently in real machines.

Software Engineering is the science and art of building (designing and writing programs) a
software systems that are:
1) on time
2) on budget
3) with acceptable performance
4) with correct operation

12
Software Engineering Layered Approach

Software Engineering Tools allows automation of activities which helps

to perform systematic activities. A system for the support of software
development, called computer-aided software engineering (CASE).
Examples: Testing Tools, Bug/Issue Tracking Tools etc…

It provides technical how-to’s for building software, it

encompasses many tasks including communication,
requirement analysis, design modeling, program
construction, testing and support

It is a foundation of Software Engineering, It is the glue that

holds the technology layers, It defines a framework activities

Defines continuous process improvement principles

13
Software Engineering Layered Approach Cont.Software Engineering is a layered technology
Quality
 Main principle of Software Engineering is Quality Focus.
 An engineering approach must have a focus on quality.
 Total Quality Management (TQM), Six Sigma, ISO 9001, ISO 9000-3, CAPABILITY MATURITY
MODEL (CMM), CMMI & similar approaches encourages a continuous process improvement
culture
Process Layer
 It is a foundation of Software Engineering, It is the glue that holds the technology layers together
and enables logical and timely development of computer software.
 It defines a framework with activities for effective delivery of software engineering technology
 It establish the context in which technical methods are applied, work products (models,
documents, data, reports, forms, etc.) are produced, milestones are established, quality is
ensured, and change is properly managed.

14
Software Engineering Layered Approach Cont.
Method
 It provides technical how-to’s for building software
 It encompasses many tasks including communication, requirement analysis, design
modeling, program construction, testing and support

Tools
 Software engineering tools provide automated or semiautomated support for the process
and the methods
 Computer‐aided software engineering (CASE) is the scientific application of a set of tools
and methods to a software system which is meant to result in high‐quality, defect‐free, and
maintainable software products.
 CASE tools automate many of the activities involved in various life cycle phases.

15
Software Process
 A process is a collection of activities, actions and tasks that are performed when some work
product is to be created
 A process is not a rigid prescription for how to build the software, rather it is adaptable
approach that enables the people doing the work to pick and choose the appropriate set of
work actions and tasks
 An activity try to achieve a broad objective (e.g., communication with stakeholders)
 An activity is applied regardless of the application domain, size of the project, complexity of
the effort, or degree of accuracy with which software engineering is to be applied.
 An action (e.g., architectural design) encompasses a set of tasks that produce a major work
product (e.g., an architectural design model).
 A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
produces a noticeable outcome.
 Each of these activities, actions & tasks reside within a framework or model

16
Software Process Software Process Framework
 Figure represents “The Software Process” Process framework
 Each framework activity is populated by Umbrella activities
set of software engineering actions framework activity #1
Software Engineering action #1.1
 Each software engineering action is Task Sets Work tasks

Software Process
defined by a task set that identifies work … Work products
to be completed, product to be produced, … Quality assurance points
quality assurance points & milestones to Software Engineering action #1.k
indicate progress Task Sets Work tasks
… Work products
… Quality assurance points
The purpose of software process is
framework activity #n
 to deliver software in timely manner and
 within sufficient quality to satisfy those
 Who has given proposal for software
development and
 Those who will use software
17
Process Framework Activities (CPMCD)
A process framework establishes the foundation for complete software engineering process, it encompasses five activities

Communication Communication with Planning Software Project Plan which

Customers / stockholders defines workflow that is to follow.
to understand project It describes technical task, risks,
requirements for defining resources, product to be
software features produced & work schedule
Modeling Creating models to Construction Code Generation
understand requirements (manual or automated)
and shows design of &
software to achieve Testing
requirements (to uncover errors in the code)
Deliver Software to Customer
Deployment Collect feedback from customer based on evaluation
Software Support
18
Umbrella Activities
 Umbrella activities applied throughout the software project & help
a software team to manage and control progress, quality, change
& risks
 Umbrella activities are those which
keep running in the background
throughout the software development

Software project Software quality

Risk Management It establish a
Tracking & Control assurance
skeleton
Technical Reviews Measurement
Reusability
architecture
Management for software
Software Configuration Management engineering
Work product preparation and production work.
19
Umbrella Activities Cont.
 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 (evaluates) risks that may affect the outcome of the project or
the quality of the product.
 Software quality assurance: defines and conducts the activities required to ensure software
quality.
 Technical reviews: assesses software engineering work products in an effort to uncover
and remove errors before they are propagated to the next activity.
 Measurement: defines and collects process, project and product measures that assist the
team in delivering software that meets stakeholders’ needs.
 Software configuration management: it manages the effects of change throughout the
software process.

20
Umbrella Activities Cont.
 Reusability management: it defines criteria for work product reuse (including software
components) and establishes mechanisms to achieve reusable components.
 Work product preparation and production: it encompasses (includes) the activities required
to create work products such as models, documents, logs, forms and lists.

21
Software Myths Beliefs about software and the process used to build it.

Management Myths

Customer Myths

“Misleading Attitudes
Practitioner's
that cause serious (Developer) Myths
problem” are myths.
22
Management myth - 1 & 2
We have standards and procedures We have the newest computers and
to build a system, which is enough. development tools.

Reality Reality
 Are software practitioners aware of  It takes much more than the latest
standard’s existence? model computers to do high-quality
 Does it reflect modern software software development.
engineering practice?  Computer-aided software engineering
 Is it complete? (CASE) tools are more important than
hardware.
 Is it streamlined to improve time to delivery
while still maintaining a focus on quality?
 In many cases, the answer to all of these
questions is "no.“
23
Management myth - 3 & 4
We can add more programmers and I outsourced the development activity,
can catch up the schedule. now I can relax and can wait for the
final working product.
Reality Reality
 Software development is not a mechanistic  If an organization does not understand
process like manufacturing. how to manage and control software
 In the words of Fred Brooks : "adding projects internally, it will invariably
people to a late software project makes it struggle when it outsources software
later." projects.
 People who were working must spend time
educating the newcomers.
 People can be added but only in a planned
and well-coordinated manner.

24
Customer myth - 1 & 2
A general statement of objectives Requirement Changes can be easily
(requirements) is sufficient to start a accommodated because software is
development. very flexible.
Reality Reality
 Comprehensive (detailed) statements of  It is true that software requirements
requirements is not always possible, an change, but the impact of change varies
ambiguous (unclear) “statement of with the time at which it is introduced.
objectives” can lead to disaster.  When requirements changes are
 Unambiguous (clear) requirements can be requested early the cost impact is
gathered only through effective and relatively small.
continuous communication between
customer and developer.

25
Practitioner's (Developer) myth – 1 & 2
Once we write the program, our job is I can’t access quality until it is
done. running.

Reality Reality
 Experts say "the sooner you begin 'writing  One of the most effective software
code', the longer it will take you to get quality assurance mechanisms can be
done." applied from the beginning of a project -
 Industry data indicates that 60 to 80 % the technical review.
effort expended on software will be after it  Software reviews are more effective
is delivered to the customer for the first “quality filter” than testing for finding
time. software defects.

26
Practitioner's (Developer) myth – 3 & 4
Working program is the only Software engineering is about
deliverable work product. unnecessary documentation.

Reality Reality
 A working program is only one part of a  Software engineering is not about
software configuration. creating documents. It is about creating
 A variety of work products (e.g., models, a quality product.
documents, plans) provide a foundation for  Better quality leads to reduced rework.
successful engineering and, more And reduced rework results in faster
important, guidance for software support. delivery times.

27
Software Process Models The process model is the abstract representation of process.

 Also known as Software development life cycle SDLC

(SDLC) or Application development life cycle
Models Communication Phases
 Process models prescribe a distinct set of
activities, actions, tasks and milestones
(deliverables) required to engineer high quality
software.
Deployment SDLC Planning

Software
 Process models are not perfect, but provide Development
roadmap for software engineering work.
Life
 Software models provide stability, control and Cycle
organization to a process that if not managed can
easily get out of control. Construction Modeling
 Software process models are adapted (adjusted)
to meet the needs of software engineers and
managers for a specific project.
28
Different Process Models
 Process model is selected based on Process Models
different parameters
 Type of the project & people  Waterfall Model (Linear Sequential Model)
 Complexity of the project  Incremental Process Model
 Size of team
 Expertise of people in team  Prototyping Model
 Working environment of team  The Spiral Model
 Software delivery deadline  Rapid Application Development Model
 Agile Model

29
The Waterfall Model Classic life cycle or linear sequential model

Communication
• Project initiation
Planning
• Requirements
gathering • Estimating
Modeling
• Scheduling
• Tracking • Analysis
Construction
• Design
• Coding
Deployment
• Testing
• Delivery
• Support
• Feedback

When requirements for a problems are well understood then this model is used in
which work flow from communication to deployment is linear
30
The Waterfall Model
When to use ? Advantages
 Requirements are very well known, clear  Simple to implement and manage
and fixed
 Product definition is stable Drawbacks
 Technology is understood  Unable to accommodate changes at later
stages, that is required in most of the
 There are no ambiguous (unclear)
cases.
requirements
 Working version is not available during
 Ample (sufficient) resources with required
development. Which can lead the
expertise are available freely
development with major mistakes.
 The project is short
 Deadlock can occur due to delay in any
step.
 Not suitable for large projects.

31
Incremental Process Model
 There are many situations in which initial software requirements are reasonably well defined,
but the overall scope of the development effort prevent a purely linear process.
 In addition, there may be a compelling need to provide a limited set of software functionality
to users quickly and then refine and expand on that functionality in later software releases.
 In such cases, there is a need of a process model that is designed to produce the software in
increments.

32
 Incremental Process Model
Software Functionality & Features

Project Calendar Time

 The incremental model combines elements of linear and parallel process flows.
 This model applies linear sequence in a iterative manner.
 Initially core working product is delivered.
 Each linear sequence produces deliverable “increments” of the software.

33
Incremental Process Model
e.g. word-processing software developed using the incremental model
 It might deliver basic file management, editing and
document production functions in the first increment
 more sophisticated editing in the second increment; Advantages
 spelling and grammar checking in the third increment;  Generates working software quickly
and and early during the software life
cycle.
 advanced page layout capability in the fourth
increment.  It is easier to test and debug during a
smaller iteration.
When to use ?
 Customer can respond to each built.
 When the requirements of the complete system  Lowers initial delivery cost.
are clearly defined and understood but staffing is  Easier to manage risk because risky
unavailable for a complete implementation by pieces are identified and handled
the business deadline. during iteration.
34
Evolutionary Process Models
 When a set of core product or system requirements is well understood but the details of
product or system extensions have yet to be defined.
 In this situation there is a need of process model which specially designed to accommodate
product that evolve with time.
 Evolutionary Process Models are specially meant for that which produce an increasingly more
complete version of the software with each iteration.
 Evolutionary Models are iterative.
 They are characterized in a manner that enables you to develop increasingly more complete
versions of the software.
 Evolutionary models are
 Prototyping Model
 Spiral Model

35
Prototyping model
When to use ?
 Customers have general objectives of software but do not have detailed requirements for
functions & features.
 Developers are not sure about efficiency of an algorithm & technical feasibilities.

 It serves as a mechanism for identifying software requirements.

 Prototype can be serve as “the first system”.
 Both stakeholders and software engineers like prototyping model
 Users get feel for the actual system
 Developers get to build something immediately

36
Prototyping model cont.
It works as follow
 Communicate with stockholders & define
objective of Software
Deployment & Communication
Feedback  Identify requirements & design quick plan
 Model a quick design (focuses on visible
part of software)

 Construct Prototype & deploy

Construction of
Prototype Quick Plan  Stakeholders evaluate this prototype and
provides feedback
 Iteration occurs and prototype is tuned
Modeling Quick based on feedback
Design
37
Prototyping model cont.
Problem Areas
 Customer demand that “a few fixes” be applied to make the prototype a working product,
due to that software quality suffers as a result
 Developer often makes implementation in order to get a prototype working quickly; without
considering other factors in mind like OS, Programming language, etc.

Advantages
 Users are actively involved in the development
 Since in this methodology a working model of the system is provided, the users get a better
understanding of the system being developed
 Errors can be detected much earlier

38
The Spiral Model

 It provides the potential for rapid development.

 Software is developed in a series of
evolutionary releases.
 Early iteration release might be prototype but
later iterations provides more complete version
of software.
 It is divided into framework activities
(C,P,M,C,D). Each activity represent one
segment of the spiral
 Each pass through the planning region results
in adjustments to
 the project plan
 Cost & schedule based on feedback

39
The Spiral Model Cont.
When to use Spiral Model? Advantages
 For development of large scale /  High amount of risk analysis hence, avoidance of Risk
high-risk projects. is enhanced.
 When costs and risk evaluation  Strong approval and documentation control.
is important.  Additional functionality can be added at a later date.
 Users are unsure of their needs.  Software is produced early in the Software Life Cycle.
 Requirements are complex.
Disadvantages
 New product line.
 Significant (considerable)  Can be a costly model to use.
changes are expected.  Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk
analysis phase.
 Doesn’t work well for smaller projects.
40
Rapid Application Development Model (RAD) It is a type of
incremental model in
Team - 1 which; components or
Communication functions are
Modeling
developed in parallel.
Construction
Planning • Integration
• Delivery Rapid development
Team - 2 • Feedback is achieved by
• Business Modeling
component based
Modeling Deployment construction
• Data Modeling Construction
• Process
Modeling This can quickly
Team - 3
• Component give the customer
Modeling Reuse something to see
• Automatic Code
Construction Generation
and use and to
• Testing provide feedback.
41
Rapid Application Development Model (RAD) Cont.
Communication  This phase is used to understand business problem.

Planning  Multiple software teams work in parallel on different systems/modules.

Modeling Construction
 Business Modeling: Information flow among the  It highlighting the use of pre-
business. existing software component.
 Ex. What kind of information drives (moves)?
 Who is going to generate information? Deployment
 From where information comes and goes?
 Integration of modules
 Data Modeling: Information refine into set of data developed by parallel teams,
objects that are needed to support business. delivery of integrated software
 Process Modeling: Data object transforms to and feedback comes under
information flow necessary to implement deployment phase.
business.
42
Rapid Application Development Model (RAD) Cont.
When to Use?
 There is a need to create a system that can be modularized in 2-3 months of time.
 High availability of designers and budget for modeling along with the cost of automated
code generating tools.
 Resources with high business knowledge are available.
Advantages Drawback
 Reduced development time.  For large but scalable projects, RAD requires
sufficient human resources.
 Increases reusability of components.
 Projects fail if developers and customers are
 Quick initial reviews occur. not committed in a much shortened time-frame.
 Encourages customer feedback.  Problematic if system can not be modularized.
 Integration from very beginning solves  Not appropriate when technical risks are high
a lot of integration issues. (heavy use of new technology).
43
Component based Development
 Commercial off the shelf (COTS) software components are offered as product.
 COTS provides set of functionality with well defined interfaces that enables component to be
integrated into software.
 The component based development model incorporates many characteristics of the spiral
model.
 It is evolutionary in nature.
 Component based development model constructs applications from prepackaged software
components.
 Modeling and construction activities begin with the identification of components.

44
Component based Development
Component based development incorporates the following steps
1. Available component-based products are researched & evaluated for software
development.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Testing is conducted to insure proper functionality.

Advantages
 It leads to software reuse.
 It reduces development cycle time.
 Reduction in project cost.

45
Product & Process
 If the process is weak, the end product will suffer. But more confidence on process is also
dangerous.
 People gain more satisfaction from the creative process as they do from the end product.
 Like an artist enjoys the brush strokes as much as the framed result.
 A writer enjoys the search for the proper metaphor (comparison) as much as the finished book.
 As software professional, you should also derive as much satisfaction from the process as
the end product.
 The duality (contrast) of product and process is one important element in keeping creative
people engaged as software engineering continues to evolve.

46
Agility Agility is ability to move quickly and easily.

It is a property consisting of quickness, lightness, & ease of movement.

 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.

47
 What is Agility? Cont.
Current Functionality
Rapid and Incremental delivery of software
Effective
response
to change
Change Request

Organizing a team Effective

so that it is in communication
control to perform among all
the work stakeholders
Development

Drawing the Eliminate the

Team

customer onto “us and them”

the team attitude
Customer
48
Agile Process
 Agile software process addresses few assumptions

Difficulty in predicting changes of requirements and customer priorities.

For many types of software; design and construction are interleaved (mixed).

Analysis, design, construction and testing are not as predictable as we might like.

 An agile process must adapt incrementally.

 To accomplish incremental adaptation, an agile team requires customer feedback (so that
the appropriate adaptations can be made).

49
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
 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

50
Where agile methodology not work

Project plan & Unclear understanding Big Enterprises where

requirements are clear of Agile Approach team collaboration is
& unlikely to change among Teams tough

51
Agile Process Models

Extreme Programming (XP)

Adaptive Software Development (ASD)

Dynamic Systems Development Method (DSDM)

Feature Driven Development (FDD)

Crystal

Agile Modelling (AM)

52
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
53
The XP Process
It considers four framework activities Planning
1. Planning  2. Design  3. Coding  4. Testing 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

54
The XP Process cont.
CRC card • Keep-it-Simple (Design of extra functionality is discouraged)
• Preparation of CRC card is work project
• CRC cards identify and organize object oriented classes
Design

• Spike Solutions (in case of difficult design problem is encountered)

• Operational prototype intended to clear confusion
• Refactoring
• Modify internals of code, No observable change

• Develops a series of Unit test for stories included in current release

• Complete code perform unit-test to get immediate feedback
Coding

• 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

Testing

• Acceptance tests - Specified by customer

• This encourages regression testing strategy whenever code is modified
55
What is Scrum? Scrum is an agile process model which is used for developing the complex software systems.

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.

Product Backlog Product Owner

Product
A scrum is a method of restarting

Daily Scrum Meeting

Sprint
play in rugby that involves players
packing closely together with their
heads down and attempting to gain
possession of the ball.

56
Scrum framework at a glance
Inputs from Customers,
Team Selects starting at
Team, Managers
top as much as it can
commit to deliver by end Scrum
Daily Scrum
Master
of sprint Meetings

Sprint Review

Product Owner

Finished Work

Product Sprint Planning Sprint

Backlog Meeting Backlog

Sprint end date and team Sprint Retrospective

Prioritized list of what is deliverable do not change
required: features, bugs to fix...
57
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.
Sprint
 These are the work units that are needed to achieve the requirements mentioned in the
backlogs.
 Typically the sprints have fixed duration or time box (of 2 to 4 weeks, 30 days).
 Change are not introduced during the sprint.
 Thus sprints allow the team members to work in stable and short-term environment

58
Scrum cont.
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
 Deliver software increment to customer
 Implemented functionalities are demonstrated to the customer
59
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 Speculation

1. Speculation, 2. Collaboration & 3. Learning  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

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

61
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
 Implementation: The software increment is placed in the working environment

62
Feature Driven Development (FDD)

It is practical
process model
for object
oriented
software
engineering

In FDD, the feature means client valued function.

63
Feature Driven Development (FDD) cont.
1. Develop overall model Design by feature
 The high-level walkthrough of scope and  For each feature the sequence diagram
detailed domain walkthrough are conducted is created
to create overall models.
Build by feature
2. Build feature list
 Finally the class owner develop the
 List of features is created and expressed in actual code for their classes
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
64
Thanks