2. Sofware Process 2
Time boxing
Time boxing – fix an iteration duration, determine
specs. acc.
Development is done iteratively in fixed duration
time boxes
Each time box divided in fixed stages
Each stage approximately equal in duration
Each stage performs a clearly defined task that can
be done independently
Use pipelining concepts to execute iterations in
3. Sofware Process 3
Time Boxed Iterations
General iterative
development – fix the
functionality for each
iteration, then plan and
execute it
In time boxed
iterations – fix the
duration of iteration
and adjust the
functionality to fit in
◦ Completion time is fixed,
the functionality to be
delivered is flexible
4. Sofware Process 4
Example
An iteration with three stages – Analyis,
Build, Deploy
◦ These stages are appx. equal in many situations
◦ Can adjust durations by determining the
boundaries
◦ Can adjust duration by adjusting the team size
for each stage
There is a dedicated team for each stage
(A, B, and D)
When one stage team finishes, it hands
over the project to the next team -
Pipelining
6. Sofware Process 6
Pipelined Execution
AT starts executing it-1
AT finishes, hands over it-1 to BT,
starts executing it-2
AT finishes it-2, hands over to BT; BT
finishes it-1, hands over to DT; AT
starts it-3, BT starts it-2 (and DT, it-1)
…
7. Sofware Process 7
Time boxed Iteration usage
This itself very useful in many situations
Has predictable delivery times
Overall product release and marketing can be
better planned
Makes time a non-negotiable parameter and
helps focus attention on schedule
Prevents requirements bloating
Overall dev. time is still unchanged
8. Sofware Process 8
Timeboxing execution
First iteration finishes at time T
Second finishes at T+T/3; third at T+2 T/3,
and so on
In steady state, delivery every T/3 time
If T is 3 weeks, first delivery after 3 wks, 2nd
after 4 wks, 3rd after 5 wks,…
In linear execution, delivery times will be 3
wks, 6 wks, 9 wks,…
9. Sofware Process 9
Timeboxing execution
Duration of each iteration still the same
Total work done in a time box is also the same
Productivity of a time box is same
Yet, average cycle time or delivery time has
reduced to a third
10. Sofware Process 10
Team Size
In linear execution of iterations, the same
team performs all stages
If each stage has a team of S, in linear
execution the team size is S
In pipelined execution, the team size is
three times (one for each stage)
I.e. the total team size in time boxing is
larger; and this reduces cycle time
11. Sofware Process 11
Work Allocation of Teams
Requirements
Team
Requirements
Analysis for TB1
Requirements
Analysis for TB3
Requirements
Analysis for TB2
Requirements
Analysis for TB4
Build Team
Deployment
Team
Build for TB1 Build for TB2 Build for TB3
Deployment for TB1Deployment for TB2
Build for TB4
Deployment for TB3
Requirements
Team
Requirements
Analysis for TB1
Requirements
Analysis for TB3
Requirements
Analysis for TB2
Requirements
Analysis for TB4
Build Team
Deployment
Team
Build for TB1 Build for TB2 Build for TB3
Deployment for TB1Deployment for TB2
Build for TB4
Deployment for TB3
12. Sofware Process 12
Team Size
Merely by increasing the team size we
cannot reduce cycle time - Brook’s law
Time boxing allows structured way to add
manpower to reduce cycle time
Note that we cannot change the time of an
iteration – Brook’s law still holds
Work allocation different to allow larger
team to function properly
13. Sofware Process 13
Timeboxing
Advantages: Shortened delivery times,
iterative, distributed execution
Disadvantages: Larger teams, proj. mgmt
is harder, high synchronization needed, CM
is harder
Applicability: When short delivery times v.
imp.; architecture is stable; flexibility in
feature grouping
14. Agile Models
Iterative + incremental process
Focus -> flexibility in producing software quickly and
capably
Agile:
◦ break the product into small incremental builds.
◦ these builds are provided in iterations.
◦ each iteration typically lasts from about one to three
weeks
◦ At the end of the iteration, a working product is
displayed to the customer and important
stakeholders
15.
16. Following are the Agile manifesto principles:
◦ Value individuals and interactions over process
and tools
◦ Prefer to invest time in producing working
software rather than in producing comprehensive
documentation
◦ Focus on continuous customer collaboration to
get proper product requirements.
◦ Responding to change rather than on creating a
plan and then following it
17. Agility Principles
1) Highest priority is to satisfy the customer through early
and continuous delivery of valuable software.
2) Welcome changing requirements, even late in
development.
3) Deliver working software frequently, from a couple of
weeks to months
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.
18. 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.
19. THE POLITICS OF AGILE DEVELOPMENT
Jim Highsmith states “Traditional methodologists
are a bunch of stick-in-the-muds who’d rather
produce flawless documentation than a working
system that meets business needs”.
As a counterpart he states “Light-weight, ‘agile’
methodologists are a bunch of glorified hackers
who are going to be in for a heck of a surprise
when they try to scale up their toys into enterprise-
wide software”
Customer Interaction (backbone), Open
communication with minimum documentation -
Agile methodology
20. Agile Vs Traditional SDLC
Models
Agile is based on the adaptive software development
methods
Traditional SDLC models like the waterfall model is based on
a predictive approach.
Predictive methods depend on the requirement analysis
and planning done in the beginning of cycle with strict
change management
In Adaptive approach, feature driven development and the
team adapts to the changing product requirements
dynamically.
21. Human Factors
Some of fundamental characteristics and skills that will facilitate the
implementation of agile practices at its core.
1) Competency: The staff should be competent in knowing
software and the technologies
2) Collaboration:
◦ Ability to work in a team
◦ Cooperate among themselves involved in project
3) Focus:
◦ Common goal:
“Deliver customer an increment of working software in
agreed time”
◦ Continuous adaptations, always improving the process as
needed.
22. 4) Decision making:
◦ Development team should have freedom, in technical
matters and project.
◦ Company can suggest good practice, but in the end is
the staff (self-organizing) which will adopt the methods or
processes that you think best.
◦ Development team must learn to deal with conflicting
situations, ambiguity and frequent changes, which will
facilitate the continual improvement process.
23. 4) Trust and respect:
◦ Team must be consistent
◦ Team demonstrate trust and respect needed to make a
strong team.
◦ Main Objective: Make the team strong enough that the
whole is greater than the sum of its parts.
5) Self organization:
◦ Self organized Team to perform the work.
◦ Continuous evaluation for process improvement
◦ Self organization has technical benefits : Team selects
how much work believed to be capable of performing the
iteration and commits.
24. There Is Nothing Noble In Being Superior
To Your Fellow Man; True Nobility Is Being
Superior To Your Former Self.
25. Some Agile Methods
Rapid Application Development (RAD)
Extreme Programming (XP)
Rational Unify Process (RUP)
Adaptive Software Development (ASD)
Feature Driven Development (FDD)
Crystal Clear
Incremental SDLC
Scrum
Dynamic Software Development Method (DSDM)
26. Sofware Process 26
EXTREME PROGRAMMING (XP)
eXtreme Programming (XP) is one of the most popular
An XP project starts with user stories, which are short description
of user needs
◦ Details are not included
◦ User stories written on a separate card
Team estimates time to implement a user story – Rough Estimates
Release planning is done
◦ Defines which stories are to be built in which release, & release
dates
◦ Encourages Frequent and small releases
◦ Acceptance tests built from user stories; used to test before
release
◦ Bugs found in AT are fixed in next release
28. Sofware Process 28
Overall Process
Development done in iterations of a few
weeks each
◦ Iteration starts with planning, in which stories to
be implemented are selected – high risk high
value are chosen first
◦ Details of stories obtained during the
development are implemented
◦ Failed AT of previous iteration are also fixed
29. Sofware Process 29
XP - Summary
Well suited for situations where volume and
pace of requirements is high
Customer is willing to engage heavily with
the team
The team is collocated and is not too large
(less than 20 or so)
Requires strong capability in team
members
30. Prototyping + Iterative development with no specific
planning
Focus:
◦ Gather customer requirements
◦ Early testing of the prototypes by the customer using iterative
concept
◦ Reuse of the existing prototypes (components)
◦ Continuous integration and rapid delivery
No detailed preplanning - easier to incorporate the changes
Team comprises of developers, domain experts, customer
representatives and other IT resources
Rapid Application Model (RAD)
31.
32. RAD Phases
Requirements planning phase
◦ Structured discussion of business problems
◦ Does System planning and analysis
◦ Users, managers, and IT staff members discuss and
agree on business needs, project scope, constraints,
and system requirements.
◦ It ends when the team agrees on the key issues and
obtains management authorization to continue
33. User description phase
◦ automated tools capture information from users
◦ Users interact with systems analysts and develop models
and prototypes that represent all system processes,
inputs, and outputs.
◦ Use tools & techniques to translate user needs into
working models.
◦ Continuous interactive process to understand, modify,
and eventually approve a working model.
34. Construction phase
◦ Uses productivity tools, such as code generators,
screen generators, etc. inside a time-box. (“Do
until done”)
◦ Users continue to participate and suggest
changes or improvements
◦ Tasks are programming and application
development, coding, unit-integration, and
system testing.
35. Cutover phase
◦ System installation, user acceptance testing and
user training
◦ Resembles the final tasks
◦ New system is built, delivered, and placed in
operation
◦ Tasks are data conversion, full-scale testing,
system changeover, user training.
36. RAD Strengths
Changing requirements can be accommodated.
Progress can be measured.
Iteration time can be short with use of powerful
RAD tools.
Productivity with fewer people in a short time.
Reduced development time.
Increases reusability of components.
Quick initial reviews occur.
Encourages customer feedback.
Integration from very beginning solves a lot of
integration issues.
37. RAD Weaknesses
Dependency on technically strong team members for
identifying business requirements.
Only system that can be modularized can be built using RAD.
Requires highly skilled developers/designers.
High dependency on modeling skills.
Inapplicable to cheaper projects as cost of modeling and
automated code generation is very high.
Management complexity is more.
Suitable for systems that are component based and scalable.
Requires user involvement throughout the life cycle.
Suitable for project requiring shorter development times.
38. When to use RAD
Reasonably well-known requirements
User involved throughout the life cycle
Project can be time-boxed
Functionality delivered in increments
High performance not required
Low technical risks
System can be modularized
39. Sofware Process 39
Rational Unified
Process(RUP)
Iterative model
Software development is divided into cycles, each
cycle delivering a fully working system
Each cycle executed as separate project
Execution of a cycle is broken into four consecutive
phases, each phase ending with a milestone
achievement
40. Sofware Process 40
Phases in a Project
◦ Inception phase: ends with Lifecycle Objectives
milestone; vision and high level capability of
system defined
◦ Elaboration phase: Lifecycle architecture
milestone; most requirements defined and
architecture designed
◦ Construction phase: Initial operational
capability milestone
◦ Transition phase: Product release; transition
product from development to production
42. Sofware Process 42
Execution of phases
Each phase itself can be done in multiple
iterations, each iteration having an
external/internal customer
Generally construction has multiple
iterations; elaboration can also be
meaningfully done in multiple iterations
43. Advantages of Agile Model
Realistic approach
Promotes teamwork and cross training
Flexibility to developers
Functionality can be developed rapidly and
demonstrated
Resource requirements are minimum.
Suitable for fixed or changing requirements
Delivers early partial working solutions
Good model for environments that change steadily
Minimal rules, documentation easily employed
Enables concurrent development and delivery within an
overall planned context.
Little or no planning required
Easy to manage
44. Disadvantages of Agile Model
Not suitable for handling complex dependencies.
More risk of sustainability, maintainability and extensibility.
Strict delivery management
Depends heavily on customer interaction, so if customer is
not clear, team can be driven in the wrong direction.
High individual dependency, since there is minimum
documentation generated.
Transfer of technology to new team members may be quite
challenging due to lack of documentation.
45. Sofware Process 45
Summary
Process is a means to achieve project objectives of high
QP
Process models define generic process, which can form
basis of project process
Process typically has stages, each stage focusing on an
identifiable task
Many models for development process have been
proposed
Model should be selected based on the nature of the
problem
Hinweis der Redaktion
imeboxing is a planning technique common in planning projects (typically for software development), where the schedule is divided into a number of separate time periods (timeboxes, normally two to six weeks long), with each part having its own deliverables, deadline and budget. Timeboxing is a core aspect of rapid application development (RAD) software development processes such as dynamic systems development method (DSDM) and agile software development.
Timeboxes are used as a form of risk management, especially for tasks that may easily extend past their deadlines. The end date (deadline) is one of the primary drivers in the planning and should not be changed as it is usually linked to a delivery date of the product. If the team exceeds the deadline, the team failed in proper planning and / or effective execution of the plan. This can be the result of: the wrong people on the wrong job (lack of communication between teams, lack of experience, lack of commitment / drive / motivation, lack of speed) or underestimation of the (complexity of the) requirements.
When the team exceeds the deadline, the following actions might be taken after conferring with the Client:
Dropping requirements of lower impact (the ones that will not be directly missed by the user)
Working overtime to compensate for the time lost
Moving the deadline