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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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”

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

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.

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+2 . . . iteration #n+1 . . . 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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