Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational Unified Process (RUP) Dynamic Structure: Iterative Development

Preface This part describes the:  lifecycle structure of the RUP  that is, how the process rolls out over time. 2

Sequential Process 3

A Reasonable Approach Many engineering problems are solved using a sequential process 4

Sequential Process It has five steps: 1) Completely understand the problem  its requirements, and its constraints.  Capture them in writing and  get all interested parties to agree that  this is what they need to achieve. 5

Sequential Process 2) Design a solution that:  satisfies all requirements and constraints.  Examine this design carefully and  make sure that all interested parties agree that it is the right solution. 6

Sequential Process 3) Implement the solution  using your best engineering techniques. 4) Verify that the implementation  satisfies the stated requirements. 5) Deliver. Problem solved! 7

Sequential Process That is how skyscrapers and bridges are built. Civil engineers  hundreds years of Experimentation Software engineers  only a few decades to explore their field. 8

Sequential Process Software projects that use sequential process … aren’t Successful? Why (Reasons)? 1) wrong assumptions. 2) Context is different. 3) Human factors is important. 4) There is not experience of hundreds of years 9

Sequential Process Wrong Assumption 1: Requirements Will Be Frozen Requirements change for many reasons. 1) Users change 10

Sequential Process 2) Problem changes  Users don't really know what they want, but  they know what they do not want when they see it.  Therefore, efforts to  detail,  capture, and  freeze the requirements may ultimately lead to the delivery of a perfect system with respect to the requirements  but the wrong system with respect to the real problem at the time of delivery. 11

Sequential Process 3) The underlying technology changes. 4) The market changes. 12

Sequential Process 5) We cannot capture requirements with sufficient detail and precision.  Formal methods …  have held the promise of a solution,  but, they have not gained significant acceptance in the industry 13

Sequential Process Wrong Assumption 2: We Can Get the Design Right on Paper before Proceeding 14

Sequential Process Software engineering may be misnamed. At various times it more closely resembles a branch of  psychology,  sociology,  philosophy, or  art than engineering.  L aws of physics underlie the design of a bridge, …  but there is no strict equivalent in software design. Software is "soft" in this respect. 15

Overcoming Difficulties: Iterate! How do you eat an elephant? One bite at a time! If the sequential, or waterfall, approach is successful for short projects or those with a small amount of novelty or risk, why not break down the lifecycle of a large project into a succession of small waterfall projects? 16

Overcoming Difficulties: Iterate! In this way, you can address some requirements and some risks, design a little, implement a little, validate it, and then take on more requirements, design some more, build some more, validate, and so on, until you are finished. This is the iterative approach. 17

Overcoming Difficulties: Iterate! 18

Overcoming Difficulties: Iterate! The iterative technique is easy to illustrate but not very easy to achieve. 19

Gaining Control: Phases and Milestones From a project management perspective, we need a way to assess progress to ensure that we are not wandering aimlessly from iteration to iteration but are actually converging on a product. 20

Gaining Control: Phases and Milestones From a management perspective, we must also define points in time to operate as gating functions based on clear criteria. These milestones provide points at which we can decide to proceed, abort, or change 21

Gaining Control: Phases and Milestones Finally, we must partition the sequence of iterations according to specific short-term objectives. 22

Gaining Control: Phases and Milestones Progress will be measured in the number of use cases or features completed, as well as test cases passed, Performance requirements satisfied, and above all, risks eliminated. 23

Gaining Control: Phases and Milestones 24

Gaining Control: Phases and Milestones (1) Inception  Specifying the end-product vision and  its business case and  defining the scope of the project. (2) Elaboration  Planning the necessary activities and required resources;  specifying the features and  designing the architecture. 25

Gaining Control: Phases and Milestones (3) Construction  Building the product and  evolving the vision, the architecture, and the plans until …  the product (the completed vision)  is ready for delivery to its user community. (4) Transition  Transitioning the product to its users, which  includes manufacturing,  delivering,  training,  supporting, and  maintaining the product until users are satisfied. 26

Gaining Control: Phases and Milestones 27

Gaining Control: Phases and Milestones 28

A Shifting Focus across the Cycle Each iteration activities: analysis design implementation integration Test But from one iteration to the next and from one phase to the next, the emphasis on the various activities changes. 29

A Shifting Focus across the Cycle 30

The Inception Phase Objectives: 1) Establish the project's software scope and 2) boundary conditions, including an  acceptance criteria, and  descriptions of what is and is not part of the product.  Discriminate the critical use cases  that is, the primary scenarios of behavior that  will drive the system's functionality and  will shape the major design trade-offs. 31

The Inception Phase Objectives: 3) At least one candidate architecture 4) Estimate the overall  cost and  schedule for the entire project and  provide detailed estimates for the elaboration phase 5) Estimate risks (the sources of unpredictability). 32

The Inception Phase Essential activities : 1) Formulate the scope of the project, that is:  capture the context and  most important requirements and  constraints so that:  can derive acceptance criteria for the end product. 2) Plan and prepare a business case and 33

The Inception Phase 3) Evaluate  alternatives for risk management,  staffing,  project plan, and  trade-offs among  cost,  schedule, and  profitability. 4) Synthesize a candidate architecture,  evaluate trade-offs in design, and  assess make/buy/reuse decisions so that  cost, schedule, and resources can be estimated. 34

The Inception Phase Outcomes: 1) A vision document, that contains,  core requirements,  key features, and  main constraints 2) The use-case model survey that contains:  lists all use cases and  actors that  can be identified at this early stage 3) An initial project glossary 35 Also in Vision

The Inception Phase 4) An initial business case, which includes  Business context  Success criteria  Financial forecast 5) An initial risk assessment 6) A project plan, which shows  the phases and  Iterations and also  project scheduling 36 Also in Vision

The Inception Phase Milestone : Lifecycle Objective 1) Stakeholders concurrence on  scope definition and  cost and  schedule estimates 2) Requirements understanding as evidenced by the  fidelity of the primary use cases 3) Credibility of  cost and schedule estimates,  priorities,  risks, and  development process 37

The Inception Phase 5) Depth and breadth of any architectural prototype that was developed 6) Actual expenditures versus planned expenditures If the project fails to pass this milestone,  it may be canceled or  considerably rethought. 38

The Elaboration Phase elaboration phase is the most critical of the four phases Objectives: 1) Define, validate, and baseline the architecture as rapidly as practical. 2) Baseline the vision. 3) Baseline a high-fidelity plan for the construction phase. 4) Demonstrate that the  baseline architecture will  support this vision  for a reasonable cost in a reasonable time. 39

The Elaboration Phase Essential activities 1) Vision is presented in detail ( elaborated ), that is,  fully expressed, and  a solid understanding is established of the most critical use cases 2) Following are Elaborated:  Process,  Infrastructure,  Development environment  Tools  automation support. 40

The Elaboration Phase 3) The architecture is elaborated and the components are selected.  Potential components are evaluated,  make/buy/reuse decisions are sufficiently understood  Construction-phase cost and schedule with confidence is determined.  The selected architectural components are integrated and  Are assessed against the primary scenarios. 41

The Elaboration Phase Lessons learned from these activities may result in:  a redesign of the architecture,  taking into consideration alternative designs or  reconsideration of the requirements. 42

The Elaboration Phase Outcomes: 1) A use-case model (at least 80% complete) in which  All use cases have been identified in the use-case model survey,  All actors have been identified, and  Most use-case descriptions have been developed 2) Supplementary requirements that  capture the nonfunctional requirements and  any requirements that are not associated with a specific use case 3) A software architecture description. 43

The Elaboration Phase 4) An executable architectural prototype 5) A revised risk list and a revised business case 6) A development plan for the overall project, including:  shows iterations and  evaluation criteria for each iteration 7) An updated development case that specifies the process to be used 8) A preliminary user manual (optional) 44

The Elaboration Phase Milestone: Lifecycle Architecture 1) Is the vision of the product stable? 2) Is the architecture stable? 3) Does the major risks have been addressed (eliminated)? 4) Is the construction phase plan sufficiently detailed and accurate? 45

The Elaboration Phase 5) Do all stakeholders agree that  the current vision can be achieved …  if the current plan is executed to develop the complete system,  in the context of the current architecture? 6) Is the actual resource expenditure versus planned expenditure acceptable? If the project fails to pass this milestone, it may be aborted or considerably rethought. 46

The Construction Phase Objectives: 1) Minimize development costs by  optimizing resources and  avoiding unnecessary rework. 2) Achieve adequate quality as rapidly as practical. 3) Achieve useful versions (alpha, beta, and other test releases) as rapidly as practical. 47

The Construction Phase Outcomes 1) The software product integrated on the adequate platforms  Beta release 2) The user manuals 48

The Construction Phase Milestone : Initial Operational Capability 1) Is product release stable to be deployed in the user community? 2) Are all stakeholders ready for the transition into the user community? 3) Are the actual resource expenditures versus planned expenditures still acceptable? Transition may have to be postponed by one release if the project fails to reach this milestone. 49

The Transition Phase For some projects this lifecycle occur at the same time with: 1) S tarting the next generation or version of the product. 2) Delivery of the artifacts to a third party  responsible for  operation,  maintenance,  enhancements of the delivered system. 50

The Transition Phase Objectives: 1) Achieve user self-supportability. 2) Achieve stakeholder agreement that:  deployment baselines are complete and  consistent with the evaluation criteria of the vision. 51

The Transition Phase If new features must be added, Iteration is similar to those of the construction phase. 52

The Transition Phase This phase can range from simple to extremely complex …  Depending on the type of product,  For example:  a new release of an existing desktop, whereas  replacing a nation's air traffic control system 53

The Transition Phase Milestone: Product Release 1) Is the user satisfied? 2) Are the actual resources expenditures versus planned expenditures still acceptable? 54