1 / 21

TK2023 Object-Oriented Software Engineering

TK2023 Object-Oriented Software Engineering. CHAPTER 2 INTRODUCTION TO THE UNIFIED PROCESS. INTRODUCTION. A software development process describes an approach to building, deploying and possibly maintaining software. Requirements. Design. Implementation. Testing. Maintenance.

Télécharger la présentation

TK2023 Object-Oriented Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. TK2023 Object-Oriented Software Engineering CHAPTER 2 INTRODUCTION TO THE UNIFIED PROCESS

  2. INTRODUCTION • A software development process describes an approach to building, deploying and possibly maintaining software.

  3. Requirements Design Implementation Testing Maintenance

  4. This course is about object-oriented software development. In particular, it focuses on the Unified Process (UP). • UP is a software development process framework which combines commonly accepted best practices into a cohesive and well-documented description. • The Rational Unified Process (RUP) is a detailed refinement of the UP. It is a process product developed and maintained by IBM.

  5. This chapter is an introduction to the UP which covers the following: • Iterative Development • Embracing Change • Phases • Disciplines

  6. ITERATIVE DEVELOPMENT • A very important "best practice" promoted by the UP is the iterative and incremental development approach to software development. • In this approach, development is organized into a series of short, fixed-length iterations. • The outcome of each iteration is a tested, integrated, and executable system. • Each iteration is a "mini-project"; it includes its own requirement analysis, design, implementation and testing activities.

  7. The iterative lifecycle is based on the successive enlargement and refinement of a system through multiple iterations, with cyclic feedback and adaptation as core drivers to converge upon a suitable system. • The system grows incrementally over time, iteration by iteration.

  8. Feedback from Requirements Requirements iteration N leads to refinement and Design Design Time adaptation of the requirements and Implementation & Implementation & design in iteration Test & Integration Test & Integration N + 1 . & More Design & More Design Final Integration Final Integration & System Test & System Test 3 weeks ( for example ) Iterations are fixed in The system grows length , or timeboxed . incrementally .

  9. Each iteration tackles a small subset of requirements. The output of an iteration is an executable but incomplete system. It is not an experimental or throw-away prototype. It is also not ready to deliver into production but it is a production-grade subset of the final system. • Note that it is also possible for an iteration to improve existing software instead of handling new requirements. For example, an iteration may focus on the performance of a subsystem.

  10. EMBRACING CHANGE • Reality: Change is inevitable in software development. Normally, clients are not clear about what they really want. • UP balances the need to agree upon and stabilize a set of requirements with the reality of changing requirements.

  11. In the UP, each iteration results in an executable release developed based on a small subset of requirements. • Using that release, early feedback can be obtained through users, stakeholders, developers and tests. From the feedback, requirements can be clarified, corrected or even added. Risky and critical design decisions can be resolved early rather than late.

  12. ITERATION LENGTH • The length of an iteration is important. The UP recommends an iteration length of between two and six weeks. • Iteration length too short => can be difficult to obtain meaningful throughput and feedback. • Iteration length too long => increases complexity and feedback is delayed which defeats the purpose of iterative development. • The length for each iteration is fixed. Date slippage is discouraged.

  13. ADVANTAGES OF ITERATIVE DEVELOPMENT • Early rather than late mitigation of high risks (technical, requirements, objectives, usability, etc) • Early visible progress • Early feedback, user engagement, and adaptation, leading to a refined system that more closely meets the real needs of the stakeholders. • Managed complexity • The learning within an iteration can be methodically used to improve the development process itself, iteration by iteration.

  14. PHASES IN UNIFIED PROCESS • Inception • Approximate vision, business case, scope, vague estimates • This phase is like a feasibility phase. Adequate investigation is done to support a decision to continue or stop • Elaboration • Refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates. • In this phase, the core architecture is iteratively implemented, and high risk issues are mitigated.

  15. Construction • Iterative implementation of the remaining lower risk and easier elements, and preparation for deployment. • Transition • Beta tests, deployment.

  16. development cycle phase iteration inc. elaboration construction transition increment final production milestone release release The difference An iteration end- A stable executable (delta) between the At this point, the point when some subset of the final releases of 2 system is released significant decision product. The end of subsequent for production use. or evaluation occurs. each iteration is a iterations. minor release.

  17. DISCIPLINES IN UNIFIED PROCESS • In the UP, an artifact is the general term for any work product: code, Web graphics, database schema, text documents, diagrams, models, etc. • In the UP, a discipline is a set of activities (and related artifacts) in one subject area. For example, the Requirements discipline refers to the set of activities and artifacts within requirements analysis.

  18. DISCIPLINES AND PHASES • During one iteration, work goes on in most or all disciplines. However, the relative effort across these disciplines changes over time. incep- transi- Sample elaboration construction tion tion UP Disciplines The relative effort in Business Modeling disciplines shifts across the phases. Requirements This example is Design suggestive, not literal. Implementation ... ...

  19. DISCIPLINES AND PHASES A four-week iteration (for example). A mini-project that includes work in most disciplines, ending in a stable executable. Note that although an iteration includes Sample work in most UP Disciplines disciplines, the relative effort and Business Modeling emphasis change over time. Focus Requirements of this This example is book Design suggestive, not literal. Implementation Test Deployment Configuration & Change Management Project Management Environment Iterations

More Related