Models:- 1) Rational Unified Model (RUP) 2) Agile Software Development Model

1. Introduction to
Software Eng
Maryam

2. Rational Unified Process
Process
● configurable
– no single process is suitable for all
software development.
– adapts to small & large development
teams
● documentation
– model based artifacts
– UML

3. Building blocks of RUP
 Building blocks
● roles (who) – responsibilities
● tasks (how) – unit of work – result
oriented – should be useful
● work products (what) – resultant
product

4. Life-cycle Phases
 four phases
inception,
elaboration,
construction,
transition
● characteristics
– sequential in nature
sounds like waterfall methodology
– each phase focuses on a
key objective
milestone delivery

5. RUP – Lifecycle Phases
 Inception
-- vision document
--scope the system
– identify major
players
– risk, cost etc
 Elaboration
- risk identification -
problem domain
- analysis &
architecture
 Construction
--build the software
-- can be broken down
into iterations
Transition
--transition from
development to
production

6. RUP WorkFlows
 Business modeling
● domain
understanding
 Requirements
● vision document &
use cases
 Analysis & Design
● blueprint for
system realization
 Implementation
● develop
components Test
● testing throughout
the project
 Deployment
● product releases
● software delivery

7. RUP

8. RUP Best Practices
 Develop iteratively
● not possible to
– define the problem upfront
– design the entire solution
● each iteration ends with a release
Manage requirements
● use case to capture functional
requirements
● should be traceable

9. RUP Best Practices
 Use components Model visually
● different models to communicate
– different aspects
– with different stakeholders
– UML

10. RUP Best Practices
 Verify quality
● review
– functional requirements
– non-functional requirements
● should be part of the process Control
changes
● continuous integration

11. Agile Development
 is an umbrella
term for
several
iterative and
incremental
software
development
methodologie
s.

12.  XP is based on
◦ four values
◦ twelve practices

13. Values of XP
 Communication. Most projects fail because of poor
communication. So implement practices that force
communication in a positive fashion.
◦ This is one of the four Agile values – a bit reworded but really the
same value.
 Simlicity. Develop the simplest product that meets the
customer’s needs
 Feedback. Developers must obtain and value feedback
from the customer, from the system, and from each other.
◦ The same as standard Agile values: value customer collaboration
over contract negotiation.
 Courage. Be prepared to make hard decisions that
support the other principles and practices.

14. Extreme Programming Practices
Knowledge

15. Planning Game
 Business and development cooperate to produce max business
value as quickly as possible.
 The planning game:
◦ Business comes up with a list of desired features.
◦ Each feature is written out as a User Story,
 feature has a name, and is described in broad strokes what is required.
◦ User stories are typically written on 4x6 cards.
◦ Development estimates how much effort each story will take, and how
much effort the team can produce in a given time interval.
◦ Business then decides
 order of stories to implement,
 And when and how often to produce a production release of the system

16. Simple Design
 Simplest possible design to get job done.
 Requirements will change tomorrow, do
what's needed to meet today's requirements
 Design in XP is not a one-time; an all-the-
time thing. Have design steps in
◦ release planning
◦ iteration planning,
◦ teams engage in quick design sessions and design
revisions through refactoring,
 through the course of the entire project.

17. Metaphor
 Extreme Programming teams develop a common
vision of how the program works, which we call the
"metaphor".
 At its best, the metaphor is a simple evocative
description of how the program works.
 XP teams use
 common system of names to be sure that everyone
understands how the system works
 and where to look to find the functionality you're
looking for,
 or to find the right place to put the functionality
you're about to add.

18. Test First
 XP teams focus on validation of the software
at all times
 Programmers develop software by writing
tests first, and then code that fulfills the
requirements reflected in the tests.
 Customers provide acceptance tests that
enable them to be certain that the features
they need are provided.

19. Refactoring
 XP Team Refactor out any duplicate code
generated in a coding session.
 Refactoring is simplified due to extensive
use of automated test cases.

20. Pair Programming
 All production code is written by two programmers
sitting at one machine.
◦ This practice ensures that all code is reviewed as it is
written and results in better Design, testing and better
code.
 Some programmers object to pair programming
without ever trying it.
◦ It does take some practice to do well, and you need to do it
well for a few weeks to see the results.
◦ Ninety percent of programmers who learn pair programming
prefer it, so it is recommended to all teams.
 Pairing, in addition to providing better code and tests,
also serves to communicate knowledge throughout
the team.

21. Collective Owner Ship
 No single person "owns" a module.
 Any developer is expected to be able to
work on any part of the codebase at any
time.

22. Continuous Integration
 All changes are integrated into the codebase at least daily.
 Unit tests have to run 100% both before and after integration.
◦ Infrequent integration leads to serious problems on a project.
 Although integration is critical to shipping good working code, the
team is not practiced at it, and often it is delegated to people not
familiar with the whole system.
 Problems creep in at integration time that are not detected by
any of the testing that takes place on an un-integrated system.
 Code freezes mean that you have long time periods when the
programmers could be working on important shippable features,
but that those features must be held back.

23. Sustainable Pace(40 Hrs week)
 Programmers go home on time.
◦ In crunch mode, up to one week of overtime is
allowed.
 Multiple consecutive weeks of overtime
are treated as a sign that something is
very wrong with the process and/or
schedule

24. OnSite Customer
 Development team has continuous
access to the customer who will actually
be using the system.
 For initiatives with lots of customers, a
customer representative (i.e. Product
Manager) will be designated for
Development team access.

25. Coding Standards
 Everyone codes to the same standards.
 The specifics of the standard are not
important: what is important is that all of
the code looks familiar, in support of
collective ownership

26. Small Release
 The development team needs to release
iterative versions of the system to the
customers often. Some teams deploy new
software into production every day.
 The release planning meeting is used to
plan small units of functionality that make
good business sense and can be released
into the customer's environment early in
the project.