Jan 7, A UP project organizes the work and iterations across four major phases: – Inception -- approximate vision, business case, scope, vague estimates. – Elaboration – refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates. – Construction -- iterative implementation of the remaining lower risk and easier elements, and preparation for deployment. – Transition -- beta tests, deployment. The UP phases

Jan 7, Inception is not a requirements phase; rather, it is a feasibility phase, where just enough investigation is done to support a decision to continue or stop. Similarly, elaboration is not the requirements or design phase; rather, it is a phase where the core architecture is iteratively implemented, and high-risk issues are mitigated. The UP phases

Jan 7,

4 Discipline: – A set of activities in a subject area, such as the activities in the requirement analysis. The UP describes work activities, such as writing a use case, within disciplines. In the UP, an artifact is the general term for any work product: code, Web graphics, database schema, text documents, diagrams, models, and so on. The UP Disciplines

Jan 7, There are several disciplines in the UP; this course focuses on some artifacts in the following three disciplines: – Business Modeling - The Domain Model artifact, to visualize noteworthy concepts in the application domain. – Requirements - The Use-Case Model and Supplementary Specification artifacts to capture functional and non- functional requirements. – Design - The Design Model artifact, to design the software objects. The UP Disciplines

Jan 7, The UP Disciplines

Jan 7, As illustrated in the figure, during one iteration, work goes on in most or all disciplines. However, the relative effort across these disciplines changes over time. The following figure shows the changing relative effort with respect to the phases UP Disciplines and UP phases

Jan 7, UP Disciplines and phases

Jan 7, The book presents two case studies. With respect to the phases and disciplines, what is the focus of the case studies? The case studies emphasize the inception and elaboration phase. They focus on some artifacts in the Business Modeling, Requirements, and Design disciplines, as this is where requirements analysis, OOA/D, patterns, and the UML are primarily applied. UP Disciplines and UP phases

Jan 7, UP Disciplines and phases

Jan 7, All activities and artifacts (models, diagrams, documents, …) in UP are optional. The choice of practices and UP artifacts for a project may be written up in a short document called the Development Case (an artifact in the Environment discipline). Customize UP, The UP Development Case

Jan 7, Customize UP, The UP Development Case

Jan 7, From (last) lecture…. UP is a software development process. A software development process describes an approach to building, deploying, and possibly maintaining software. The Unified Process has emerged as a popular iterative software development process for building object-oriented systems. Small steps, rapid feedback, and adaptation are central ideas in iterative development. A key idea is that iterations are timeboxed, or fixed in length. Any analysis, modeling, development, or management practice based on the assumption that things are long-term stable (i.e., the waterfall) is fundamentally flawed. A UP project organizes the work and iterations across four major phases…. There are several disciplines in the UP; this course focuses on some artifacts in the following three disciplines….

Jan 7, Chapter 3, 4, 5, prepare for chapter 6 and 7,

Jan 7, Generally, applications include UI elements, core application logic, database access, and collaboration with external software or hardware components. Although OO technology can be applied at all levels, this introduction to OOA/D focuses on the core application logic layer, with some secondary discussion of the other layers. Chapter 3 Case Studies

Jan 7,

Jan 7, Chapter 3 Case Studies Case Study Strategy: Iterative Development + Iterative Learning.

Jan 7, Case One: The NextGen POS System. Using an iterative development strategy, we are going to proceed through requirements, object- oriented analysis, design, and implementation.

Jan 7, Case Two: The Monopoly Game System The software version of the game will run as a simulation. One person will start the game and indicate the number of simulated players, and then watch while the game runs to completion, presenting a trace of the activity during the simulated player turns.

Jan 7, Inception is the initial short step to establish a common vision and basic scope for the project. It will include analysis of perhaps 10% of – the use cases (?, chapter 6) – analysis of the critical non-functional requirement, – creation of a business case, and – preparation of the development environment so that programming can start in the following elaboration phase. Chapter 4. Inception is Not the Requirements Phase

Jan 7, Most projects require a short initial step in which the following kinds of questions are explored: – What is the vision and business case for this project? – Feasible? – Buy and/or build? – Rough unreliable range of cost: Is it $10K100K or in the millions? – Should we proceed or stop? Chapter 4. Inception is Not the Requirements Phase

Jan 7, KEEP IN MIND: – the purpose of the inception phase is not to define all the requirements, or generate a believable estimate or project plan. – Inception, is not the time do all requirements or create believable estimates or plans. That happens during elaboration. – Most requirements analysis occurs during the elaboration phase, in parallel with early production-quality programming and testing. Chapter 4. Inception is Not the Requirements Phase

Jan 7, Inception phase is normally short for most projects. It is to decide if the project is worth a serious investigation (during elaboration), not to do that investigation. Inception In one sentence: – Envision the product scope, vision, and business case. The main problem solved in one sentence: – Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in serious investigation? Chapter 4. Inception is Not the Requirements Phase

Jan 7, Artifacts in Inception

Jan 7, The purpose of inception is to collect just enough information to establish a common vision, decide if moving forward is feasible, and if the project is worth serious investigation in the elaboration phase. As such, perhaps beyond simple UML use case diagrams, not much diagramming is warranted. There is more focus in inception on understanding the basic scope and 10% of the requirements, expressed mostly in text forms. In practice, most UML diagramming will occur in the next phase---elaboration. Is UML involved in inception?

Jan 7, Objectives – Motivate doing evolutionary requirements. – Define the FURPS+ model. – Define the UP requirements artifacts. Chapter 5. Evolutionary Requirements

Jan 7, Requirements are capabilities and conditions to which the system and more broadly, the project must conform. One of the best practices of UP is manage requirements. Which means – a systematic approach to finding, documenting, organizing, and tracking the changing requirements of a system. Chapter 5. Evolutionary Requiements

Jan 7, How to do partial, evolutionary requirements analysis combined with early design and programming, in iterations? In other words, UP wants to do requirements iteratively and skillfully, and not being sloppy. The challenge in requirement analysis is to find, communicate, and remember (that usually means write down) what is really needed, in a form that clearly speaks to the client and development team members. Details in Ch 6 and 7. Chapter 5. Evolutionary Requirements

Jan 7, Do an iterative and evolutionary requirement analysis, not a waterfall one. Here is the evidence: Blame the waterfall again

Jan 7, Research shows on average, 25% of the requirements change on software projects. Any method that therefore attempts to freeze or fully define requirements at the start is fundamentally flawed, based on a false assumption, and fighting or denying the inevitable change. Do an iterative, evolutionary requirement analysis, i.e., – iterative and evolutionary requirements analysis combined with early timeboxed iterative development and frequent stakeholder participation, evaluation, and feedback on partial results. Blame the waterfall again

Jan 7, In the UP, requirements are categorized according to the FURPS+ model Functional - features, capabilities, security. Usability - human factors, help, documentation. Reliability - frequency of failure, recoverability, predictability. Performance - response times, throughput, accuracy, availability, resource usage. Supportability - adaptability, maintainability, internationalization, configurability. Types and Categories of Requirements in UP

Jan 7, The “+” sign means – Implementation - resource limitations, languages and tools, hardware,... – Interface - constraints imposed by interfacing with external systems. – Operations - system management in its operational setting. – Packaging - for example, a physical box. – Legal - licensing and so forth. Types and Categories of Requirements in UP

Jan 7, Use FURPS+ model as a checklist for requirements coverage, in order to reduce the risk of not considering some important facet of the system. A more general categorization of requirements: – Functional requirements – Non-functional requirements Types and Categories of Requirements in UP

Jan 7, Requirement Artifacts in UP

Jan 7, The UP offers several requirements artifacts. As with all UP artifacts, they are optional. Key ones include: – Use-Case Model : set of typical scenarios of using a system. CAPTURE functional (behavioral) requirements. – Supplementary Specification: Basically, everything not in the use cases. CAPTURE all non-functional requirements, such as performance or licensing. Requirement Artifacts in UP

Jan 7, The UP offers several requirements artifacts. As with all UP artifacts, they are optional. Key ones include: – Glossary : Glossary defines noteworthy terms. The data dictionary – Vision : Summarizes high-level requirements that are elaborated in the Use-Case Model and Supplementary Specification, and summarizes the business case for the project. Requirement Artifacts in UP

Jan 7, Business Rules: Business rules (also called Domain Rules) typically describe requirements or policies that transcend one software project - they are required in the domain or business, and many applications may need to conform to them. An excellent example is government tax laws. Requirement Artifacts in UP

Jan 7,

Jan 7, Thank you and See you next time.