1. Rekayasa Perangkat Lunak Part-7
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

2. Outline of this presentation
The Generic Software Process Model
Extreme Programming
Rational Unified Process
Opportunistic Approach
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

3. Generic Software Process Model
eXtreeme Programming
Traditional Software Lifecycle:
Listen - Design - Code - Test
XP lifecycle
Listen - Test - Code - Design
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

4. Generic Software Process Model
eXtreeme Programming
XP is based on the extreme application of 12 practices (guidelines or rules) that support each other:
Planning game
Frequent releases
System metaphor
Simple design
Tests
Refactoring
Pair programming
Collective code ownership
Continuous Integration
Forty-hour week
On-site customer
Coding standards
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

5. Generic Software Process Model
eXtreeme Programming
Listen to customers while gathering requirements
Develop test cases (functional tests and unit tests)
Code the objects
Design (refactor) as more objects are added to the system
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

6. Generic Software Process Model
eXtreeme Programming
Short definition
lightweight process model for OO software development
What’s in the name?
code is in the centre of the process
practices are applied extremely
What is new in XP?
none of the ideas or practices in XP are new
the combination of practices and their extreme application is new
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

7. Generic Software Process Model
eXtreeme Programming
Pieces: user stories
Players: customer & developer
Moves:
User story writing
requirements are written by the customer on small index cards
user stories are written in business language
and describe things that the system needs to do
each user story is assigned a business value
Planning Game
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

8. Generic Software Process Model
eXtreeme Programming
The development process is highly iterative
A release cycle is usually up to 3 months
A release cycle consists of iterations up to 3 weeks
In each iteration the selected user stories are implemented
Each user story is split in programming tasks of 1-3 days
small and frequent releases provide frequent feedback from the customer
Frequent Releases
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

9. Generic Software Process Model
eXtreeme Programming
Synonym for system-architecture ?
The system metaphor provides a broad view of the project’s goal
It defines the overall theme to which developers and clients can relate
Common concept of what the system is like
The system is built around one (or more) system metaphor from which classes, methods, variables and basic responsibilities are derived
System Metaphor
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

10. Generic Software Process Model
eXtreeme Programming
Do the simplest thing that could possible work
create the best (simple) design you can
You aren’t going to need it
do not spend time implementing potential future functionality (requirements will change)
Put in what you need when you need it
Simple design ensures that there is less
to communicate
to test
to refactor
Simple Design
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

11. Generic Software Process Model
eXtreeme Programming
Tests play the most important and central role in XP
Tests are written before the code is developed
forces concentration on the interface
accelerates development
safety net for coding and refactoring
If user stories are considered as the requirements then Tests can be considered as the specification of the system
Test(1)
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

12. Generic Software Process Model
eXtreeme Programming
2 kinds of test:
Acceptance tests (functional tests)
clients provide test cases for their stories
developers transform these in automatic tests
Unit tests
developers write tests for their classes (before implementing the classes)
All unit tests must run 100% successfully all the time
Test (2)
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

13. Generic Software Process Model
eXtreeme Programming
Change it even if it is not broken!
Process of improving code while preserving its function
The aim of refactoring is to
make the design simpler
make the code more understandable
improve the tolerance of code to change
The code should not need any comments
There is no documentation in XP
The code and the user stories are the only documents
Refactoring
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

14. Generic Software Process Model
eXtreeme Programming
Two programmers sit together in front of a workstation
one enters code
one reviews the code and thinks
Second most important practice after tests
Pairs change continuously (few times in a day)
every programmer knows all the aspects of the system
a programmer can be easily replaced in the middle of the project
Ensures continuous code inspection (SE)
Pair Programming
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

15. Generic Software Process Model
eXtreeme Programming
The code does not belong to any programmer but to the team
Any programmer can (actually should) change any of the code at any time in order to
make it simpler
make it better
Everybody tries to produce a high-quality system
code gets cleaner
system gets better all the time
everybody is familiar with most of the system
Collective Code Ownership
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

16. Generic Software Process Model
eXtreeme Programming
Daily integration at least
The whole system is built (integrated) every couple of hours
XP feedback cycle:
develop unit test
code
integrate
run all units tests (100%)
release
A working tested system is always available
Continuous Integration
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

17. Generic Software Process Model
eXtreeme Programming
“Overtime is defined as time in the office when you don’t want to be there” Ron Jeffries
Programmers should not work more than one week of overtime
If more is needed then something is wrong with the schedule
Keep people happy and balanced
Rested programmers are more likely to refactor effectively, think of valuable tests and handle the strong team interaction
40 Hour Week
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

18. Generic Software Process Model
eXtreeme Programming
User stories are not detailed, so there are always questions to ask the customer
The customer must always be available
to resolve ambiguities
set priorities
provide test cases
Customer is considered part of the team
On-site Customer
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

19. Generic Software Process Model
eXtreeme Programming
Coding standards make pair progamming and collective code ownership easier
Common name choosing scheme
Common code formatting
Coding Standards
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

20. Generic Software Process Model
Rational Unified Process
Recognizes that system building is model building
Organizes work in a process-oriented way
Manages the system life-cycle
“from womb-to-tomb”

21. Generic Software Process Model
Rational Unified Process
Is risk-driven
Is cyclical
Every cycle results in a new system generation
Every cycle consists of a number of phases
Every phase consists of a number of iterations

22. Generic Software Process Model
Rational Unified Process
time
Inception
Elaboration
Construction
Transition
Major milestones
The Process has four phases
Inception: defining the scope of the project
Elaboration: planning the project, specifying features and designing the architecture
Construction: building the product
Transition: deployment to the user community
From a Time perspective the process consists of four phases. These phases will be discussed in detail later in the course.
Inception - The good idea: Specifying the end-product vision and its business case; defining the scope of the project.
Elaboration - Planning the necessary activities and required resources; specifying the features and designing the architecture.
Construction - Building the product and evolving the vision, architecture, and plans until the product - the completed vision - is ready for transfer to the user community.
Transition - Transitioning the product to the user community, which includes manufacturing, delivering, and developing training on the product until the users are satisfied.

23. Generic Software Process Model
Rational Unified Process
Inception
Elaboration
Construction
Transition
preliminary iteration(s)
iteration #1
iteration #2. . .
iteration #n
iteration #n+1
iteration #n
iteration #n
Releases
time
Each phase consists of one or several iterations. Each iteration results in a release of an executable product.
(In an early iteration, the executable product can be a simple prototype. )
An iteration is a complete development loop ending in a release of an executable product, an increment of the final product under development.

24. Generic Software Process Model
Rational Unified Process
The process has four process components
Requirements analysis
Design
Implementation
Test
And two supporting components
Project Management
Process Configuration

25. Generic Software Process Model
Rational Unified Process
Key Characteristic of the Process
Architecture-centric
Iterative and Incremental
Use case-driven

26. Generic Software Process Model
Rational Unified Process
Dealing with the Complexity or Process
Start with Use Cases as if we had an ideal world
Then proceed with Architecture to consider realities
Finally Iterative & Incremental to manage the project

27. Use Cases bind these work steps together
Generic Software Process Model
Rational Unified Process
Use Case Driven Development
All process components, from requirements capture to test, are driven by use cases
Capture, Clarify
and Validate
the Use Cases
Analyze
Realize
Design and
Implementation
Verify that the
Use Cases are
fulfilled
Test
Use Cases bind these work steps together

28. Generic Software Process Model
Rational Unified Process
Use Case Driven Development
The use cases defined for a system are the basis for the entire development process. The use cases drive the development:
In requirements analysis the use cases are used to capture the requirements
In design you identify classes from the use-cases
In implementation you implement the use cases
In test you verify the use cases during test
The use cases constitute test cases

29. Generic Software Process Model
Rational Unified Process
Use Case Driven Development (cont.)
Use cases play several roles during the software-engineering process.
They are used as a basis for iterative development
They form a foundation for what is described in user manuals
They may be used as ordering units
For example, a customer can get a system configured with a particular mix of use cases

30. Requirements Analysis
Generic Software Process Model
Rational Unified Process
Each process component is associated with a particular model.
Process Components and Models
Use-Case Model
Design Model
Implementation Model
Test Model
realized by
implemented by
verified by
Requirements Analysis
Design
Implementation
Test

31. Generic Software Process Model
Opportunistic Software System Development
Increasing user demands and costs are driving the software development industry
composition of new systems from readily available software components,
including other systems.
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

32. Generic Software Process Model
Opportunistic Software System Development
opportunistic systems are not composed of
neatly designed homogeneous software pieces
with clear boundaries
and well-described functionality
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

33. Generic Software Process Model
Opportunistic Software System Development
Focuses on
finding and gluing together
pieces of software that were never
designed to work together:
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

34. Generic Software Process Model
Opportunistic Software System Development
In this approach, only few rules exist for:
design,
construction, or
process management.
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

35. Generic Software Process Model
Opportunistic Software System Development
The emphasis is on:
smart engineering, creativity, innovation,
and imaginative ways of
finding and gluing software to provide interoperable and maintainable systems
that meet users' needs.
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

36. Generic Software Process Model
Opportunistic Software System Development
The emergence of the opportunistic approach poses both challenges and prospects for today's developers.
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

37. Generic Software Process Model
Opportunistic Software System Development
Practitioners need unique sets of skills, tools, and techniques, coupled with imagination and innovation to cope with the underlying demands.
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

38. Generic Software Process Model
Opportunistic Software System Development
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi

39. Finished,
Questions?
Rekayasa Perangkat Lunak Copyright © Feb-2009 by Fakultas Teknologi Informasi