Managing the Software Life-cycle
SENG 623: Unified Process Group
Kobe DavisLinda CaiGuy Davis
|
|
Managing the Software Life-cycleSENG 623: Unified Process Group |
Kobe DavisLinda CaiGuy Davis
|
|
|
| Abstract | |
|
The Unified Process is a development framework for software engineering which stresses six best practices:
In order to accomplish these goals, the Unified Process is use-case driven, architecture-centric, and iterative and incremental in its approach. The Unified Process can be tailored to specific project situations and as such has similarities to Agile methodologies. | |
| 1 Introduction | |
1.1 HistoryIn 1987 Ivar Jacobson created Objectory AB after leaving Ericsson. He then began development of a process called Objectory (Object Factory) which expanded on the ideas he had already developed at Ericsson. In 1995 the Rational Software Corporation acquired Objectory AB. Rational had developed a number of its own software development practices and work was begun merging the various processes. Use-cases had been established through Objectory AB and from Rational came the ideas of iterative and incremental development as well as architecture. The first result of this process was the Rational Objectory Process. At the same time UML was being developed/released at Rational, the Rational Objectory Process made is of UML for all of its models. Through further mergers and acquisitions Rational expanded the Rational Objectory Process and released the Rational Unified Process in 1998. 1.2 OverviewUnified Process is a software development process. A software development process is the set of activities needed to transform a user’s requirements into a software system. The Unified Process is more than a single process; it is generic process framework that can be specialized for a very large class of software systems, for different application areas, different types of organizations, different competence levels, and different project sizes. [Jacobson et al. 1999]
| |
| 2 People, Project, Product, Process | |
|
The Unified Process recognized four aspects of software development as being equally important: People; Project; Product; Process and (Tools). 2.1 The DefinitionsPeople: The architects, developers, testers, and their supporting management, plus users, customers, and other stakeholders are the prime movers in a software project. Project: The organizational element through which software development is managed. The outcome of a project is a released product. Product: Artifacts that are created during the life of the project, such as models, source code, executables, and documentation. Process: A software engineering process is a definition of the complete set of activities needed to transform users’ requirements into a product. A process is a template for creating projects. Tools: Software that is used to automate the activities defined in the process. 2.2 People -- SW is “an intensely human endeavour”.
2.3 Project – make the product.
2.4 Product – is the end result of a software project.
2.5 Process – directs projects
2.6 Tools – Impact Process.
| |
| 3 Use Case Driven | |
3.1 Definition3.1.1 UserThe term user refers not only to human users but also to other systems. In this sense, the term user represents someone or something (such as another system outside the proposed system) that interacts with the system being developed. 3.1.2 Use CaseIn response to the user’s request, the system performs a sequence of actions that provide the user with a result of value. An interaction of this sort is a use case. A use case is a piece of functionality in the system that gives a user a result of value. A use case describes a sequence of actions a system performs that yields an observable result of value to a particular actor. 3.1.3 Use-Case ModelUse cases capture functional requirements. All the use cases together make up the Use-Case Model that describes the complete functionality of the system. A user-case model consists of actors, use cases, and relations among them. Actors represent everything that must exchange information with the system, including what are typically called users. When an actor uses the system, the system performs a use case. A good use case is a sequence of transactions that yields a measurable result of value for an actor. The collection of use cases is they system’s complete functionality. [ACM 1992] 3.1.4 Use-Case drivenUse-Case driven means that the development process follows a flow- it proceeds through a series of work-flow that derive from the use cases. Use cases are specified, use cases are designed, and at the end use cases are the source from which the testers construct the test cases. 3.2 Why Use–Case DrivenA software system is brought into existence to serve its users. Therefore, to build a successful system we must know what its prospective users want and need. The two main reasons we use use-cases are: [Jacobson et al. 1999]
"Use case driven" means writing the user manual first, then writing the code. This practice reinforces the fundamental notion that a system must conform to the needs of the users, instead of your users conforming to the system. [Rosenberg, 2001] 3.3 Capturing the RequirementsThe goal of the requirements process, as defined in the Unified Process, is to describe what the system should do in terms of functionalities, and allow the developers and the customers to agree on this description. Use cases are the most important requirements artifact: [Krutchen 1999]
3.4 Driving the Development Process3.4.1 Use Case DrivenUse cases are used to drive the whole development process in the following ways:
3.4.2 Initiating the development processThe work-flows of a project development are initiated from the use cases. Use cases provide major input:
 Figure 1 The Work-flows, which initiated from the Use Cases A use case model with all the use cases and their relationships to users. An analysis model has two purposes:
A design model defines:
3.4.3 Binding the core work-flows togetherBased on the use-case model, developers create a series of design and implementation models that realize the use cases. The developers review each successive model for conformance to the use-case model. The testers test the implementation to ensure that the components of the implementation model correctly implement the use case. For each iteration, use cases drive through the whole set of work-flows from requirements capture, via analysis, design and implementation, to test. In this way, the use cases not only initiate the development process but bind it together. While it is true that use cases drive the process, they are not selected in isolation. They are developed in tandem with the system architecture. That is, the use cases drive the system architecture and the system architecture influences the selection of the use cases. Therefore, the system architecture and the use cases mature as the life cycle continues.  Figure 2 Use Cases bind the core workflows together 3.5 More about Use Cases3.5.1 Carrying out iterative developmentIn the development life cycle, each iteration procedure, except for the very first one in a project, is driven by the use cases through all the work-flows. We also can illustrate in another way, in each iteration procedure, a number of use cases is identified and implemented. 3.5.2 Devising the architectureBy selecting the right set of use cases – the architecturally significant use cases – to realize during the first few iterations, we can implement a system with a stable architecture. 3.5.3 Providing a starting point for the user manual As we know, each use case describes one way of using the system. Thus, use cases are an ideal starting point for explaining how the user can interact with the system. 3.5.4 Good Estimation Tool Use cases can help to decide which paths need the best performance, to select the most important paths to focus on when designing the user interface, and to optimize the allocation of the system resource by estimating how many times or how often different use cases are performed.
3.6 How to capture the Use Cases3.6.1 Representing the Functional Requirements The use-case model helps the customer, users, and developers agree on how to use the system. We all know, most of the systems have many types of users. Each type of user is represented as an actor. Actors use the system as they interact with use cases. All the actors and the use cases of a system made up a use-case model. 3.6.2 Defining the Actors
We find use cases by looking at how the users need to use the system to do their work. Each such way of using the system that adds value to the users is a candidate use case. 3.7 Realizing the Use CasesFrom the use cases we create the following models, Analysis Model, Design Model, and Implementation Model. We also use the use cases to test the final implementation. During analysis and design, the use-case model is transformed into an analysis model and then a design model. With each iteration, a few of the highest risk use cases are analyzed to create use-case realizations. We create a first cut at a design or conceptual model creating and/or reusing classifiers and relationships where needed. The design model is created with the analysis model as input. Where the analysis model was a conceptual model, the design model is also created with the implementation environment in mind. The design model becomes the blueprint for implementation. The executable model is created from the blueprint or design model. This model includes everything needed to produce and executable system. Finally, testing would verify if the system has being correctly implemented it’s specification. Tests are devised and executed for each use case.
3.8 Use case driven planning3.8.1 IntroductionThis is the approach promoted by the Rational Unified Process in which your project is organized into iterations where you fully develop and potentially deploy (at least internally) a portion of your system. Following this approach, one or more use cases are assigned to each iteration.[Scott W.Ambler,Dec.,2000] 3.8.2 Advantages of this approach
3.8.3 Weaknesses of use-case-driven requirements work-flowIn our experience, we have found that a fully specified set of use cases for a system often does a great job of stating many of the requirements for that system. But just as often there are also a significant number of requirements that do not fit well within this modeling technique. Especially for non-functional requirements (e.g., specifications for usability, reliability, performance, maintainability, supportability), it is usually best to use the traditional method for stating requirements. In most circumstances use cases should simply be applied as an added form of expression which increases understandability, as opposed to simply replacing the specification of requirements in the traditional fashion.
 Figure 3: Role of Use Cases in System Development | |
| 4 Architecture Centric | |
|
The Unified Process' reliance on use case models helps to provide the developing system with function. However the other key component of product design and development is its form. The form a product takes is often referred to as it's architecture. The Unified Process recognizes the interaction of form and function by being "architecture centric". [Jacobson et al. 1999]. The software architecture comprises the most important static and dynamic aspects of the system. It provides a critical, high-level view of a system, leaving the distraction of details aside. The architecture of the system is expected to evolve along with the product throughout its life-cycle. At all times, the architecture provides a common vision linking the various stakeholders in the project together. 4.1 The Need for an ArchitectureIn general the need for architecture is directly proportional to the size and complexity of a project. As the size of project team grows, an architectural view is needed to keep the work of sub-teams and individual developers from diverging and becoming incoherent. As well, software systems are becoming more and more complex to implement. In particular, the number of software components and the dependencies that they introduce is increasing. Architecture is an effective tool for abstracting away the complexity of the system. As well, a good architecture is instrumental in helping to reduce the dependencies between development tasks. By using a modular design with well-defined interfaces, the architecture can promote concurrent development which reduces the overall project schedule. These interfaces are essentially a means of reducing the communication needed for effective work between team members. This type of modular design has been codified in to certain design patterns, such as Boundary-Control-Entity. [Jacobson et. al. 1999] Another benefit of an architecture-centric approach is that reuse of standardized components is encouraged. This is similar to the reuse of certain types of building supplies during the construction of a home. While the level of component standardization is nowhere near as advanced in the domain of software engineering, there are component models such as Java-Beans being advanced. [Sun Microsystems, 2002] Finally, the architecture must be flexible enough to evolve through the life-cycle of the product. A brittle architecture can greatly hinder developer who must alter functionality as the requirements change. It is often this inflexibility to change the brings about the software's abandonment at the end of its life-cycle. 4.2 Use Cases and ArchitectureThe Unified Process also describes the interaction of the use cases and the overall architecture. In general, the architecture should support the most cost-effective implementation of the use cases. [Jacobson et. al., 1999] Use cases are not the only factor influencing the architecture. Other impacts on the system architecture include: [Jacobson et. al. 1999]
All of these impacts effect how the use cases will be implemented. The architecture takes them into account during the elicitation of the deployment model. The project team helps to define the architecture by determining the set of use cases felt by the customer to be critical. These often include those use cases that mitigate the most risk and cover the most useful functionality.  Figure #4: Relation between Use Cases and Architecture [Jacobson et. al., 1999] As shown in Figure 4, the architecture and the use case model both feedback to improve the other. This iterative process of refining both the architecture and the use case model is a cornerstone of the Unified Process. 4.3 Architecture BaselineThe creation of an initial architecture occurs in a number of iterations, primarily during the elaboration phase of the project. The key process areas of analysis, design, implementation and test are all included to varying degrees. [Jacobson et. al., 1999] The goal at this stage is the internal release of an architectural baseline which provides varying degrees of information in the various models produced during the Unified Process.  Figure 5: Example architecture baseline showing state of models [Jacobson et. al. 1999] Of course, during the early stages of the project, the use case and analysis models are more complete than the deployment model as shown in the example in Figure 5. However, each component does have some though and effort put into it. This initial baseline is the foundation for the design and implementation of the product. Ideally the baseline will include a document summarizing the state of the component models listed above. This description should include use cases, subsystems, interfaces, some classes and components, nodes, and collaborations. [Jacobson et. al., 1999] The architectural description is an excellent way of communicating the high-level project design to the stakeholders at an early stage to ensure that the project is on the right track. | |
| 5 Iterative and Incremental | |
|
The Unified Process deals with changing project conditions such as new requirements or functionality, technology advances, and unseen risks by working iteratively and incrementally. An iteration is a complete cycle through a set of work-flows resulting in a release, either internally or externally.[Rational. 2002] An increment is growth in the product resulting from the iterative development. [Jacobson et. al., 1999] 5.1 Unified Process Life-Cycle PhasesBefore considering the Unified Process iteration, an understanding of the larger product life-cycle is needed. The Unified Process identifies four phases comprising a single generation of product development as show below in Figure 6.  Figure 6: Milestones separate the Phases [Rational, 2002] The inception phase concentrates on generating the business case and determining the project scope. It requires use case elicitation by evaluating all key stakeholders in the system. This phase also provides an initial risk assessment to help determine project viability. A project plan including a rough schedule is also created. [Rational, 2002] The elaboration phase analyzes the problem domain, establishes a sound architectural foundation, and eliminates the highest risk elements facing the project. The use case model should be nearly complete and must include all critical requirements. Significantly more detail is added to the project plan at this stage, updating early estimates. Typically this phase generates an evolutionary prototype that will be built upon in later phases, however throw-away prototyping is not precluded. The milestone at the end of this phase includes the decision of whether to commit to full construction of the product. [Rational, 2002] The construction phase entails the development and integration of all remaining subsystems and functionality. Testing occurs throughout this phase. At the end of this phase, the product is complete and ready for initial deployment, typically in a "beta" release. User documentation is another artifact from this phase. [Rational, 2002] The transition phase primarily concerns with correcting issues discovered during the previous stage. One the product is complete, a full deployment is performed taking into consideration legacy systems, training, and conversion of operational databases. The goal of this phase is to achieve user self-supportability. [Rational, 2002] A perceptive reader will likely notice that at this point the phases look suspiciously like the much derided waterfall model. It is important to remember that these phases are repeated throughout the operational lifetime of the system, until its eventual retirement. As well, the iterative nature of the Unified Process becomes apparent when one looks closely at the iterations which make up each phase. 5.2 Components of an IterationWithin a phase, a number of iterations may occur. The number of iterations per phase is not fixed and is decided during project planning. Each iteration is comprised of nine work-flows described below. The amount of time spent in each work-flow should be tailored by the project team to suit the project circumstances and its position in the overall life-cycle.  Figure 7: Iterative Development in the Unified Process [Rational, 2002] The relation between phases, iterations, and work-flows is show above in Figure 7. Notice the weighting of various work-flows at different time-points. 5.2.1 Business ModelingThe Unified Process recommends the use of business use cases as a documentation tool to enhance communication between business and engineering members on the project team. As well a business object model can be developed in this work-flow. 5.2.2 RequirementsThis work-flow is intended to elicit and document the required functionality of the system to the satisfaction of the customers and the project team. Actors and interfaces are identified and described in detailed use cases. 5.2.3 Analysis and DesignThis stage should indicate how the system will be implemented in the next stage. In particular, a design model and analysis model may be created to serve as the blueprint for the source code. Interfaces between subsystems and the collaboration between important design classes should be described. [Rational, 2002] 5.2.4 ImplementationThe complete set of source code is generated in this step resulting in executable binaries. The design from the previous step is fleshed out, all code unit tested and various modules are integrated into a working product. 5.2.5 TestThis stage is primarily concerned with black box testing and integration testing of the completed code base. As well, the original requirements specification is tested against to ensure that all use cases have been covered during the implementation. Nonfunctional requirements are also tested during this stage. 5.2.6 DeploymentDeployment involves packaging, distributing, installing software for users as well as providing technical assistance to them. It can include organizing beta tests, formal acceptance, and migration of existing data. Much of the work here is performed in the transition phase, however it can be successfully planned in earlier phases. [Rational, 2002] 5.2.7 Project ManagementProject management is considered a supporting work-flow for the previous core work-flows. It requires management of project risk, handling project constraints and balancing competing interests to ensure the project remains on track. The Unified Process provides a general framework for managing software-intensive projects. [Rational, 2002] 5.2.8 Configuration ManagementSCM is a critical supporting work-flow that should be applied throughout the entire life-cycle of the product. Proper SCM allows the multiple variants (releases) of a product to be controlled throughout their lifespan. An official change request policy can also result in fewer errors being introduced to the code base as new development proceeds. 5.2.9 EnvironmentThis work-flow is concerned with ensuring that all the needed tools and processes are in place to effectively support the development team. A process improvement effort can also be included in this step. [Rational, 2002] 5.3 Benefits of an Iterative and Incremental ApproachA key benefit of the iterative and incremental approach to software development is management of risk. Iterating through the steps listed above allows for initial choices to be questioned and corrected if wrong. This allows for earlier detection and mitigation of project risk which greatly decreases its impact.  Figure 8: Iterative development leads to earlier risk reduction [Jacobson et. al., 1999] By concentrating on risk management in the inception and elaboration phases of each cycle, the Unified Process is a significant improvement over the traditional waterfall model. [Jacobson et. al., 1999] Another benefit of the Unified Process is the generation of a robust architecture in the early phases. The architectural baseline produced at the end of the elaboration phase satisfies key requirements, overcomes key risks, and resolves central development problems. [Jacobson et. al. 1999] By iterating through such work-flows as implementation, test, and deployment early in the project, the architecture is vetted against the entire process. This results in a more realistic architecture at an early stage. Probably the most important benefit of an iterative approach is seen when handling changing requirements. By having a system in partial operation early on, it is possible to get valuable feedback from users. [Jacobson et. al., 1999] An when the users inevitably suggest changes, it is much easier to handle them earlier than later on in the product's life-cycle. Avoidance of the inevitable problems caused by a "big-bang" integration such as used in the waterfall model is another key benefit of the Unified Process' iterative approach.  Figure 9: Iteration reduces product integration time [Jacobson et. al., 1999] By ensuring that integration is repeated task throughout the development cycle, problems are discovered early and can be corrected quickly with less impact to the project schedule. Ideally the project can achieve continuous integration. The use of iterations also familiarizes the entire project team with all nine work-flows listed above. By repeating each work-flow many times, the team members become more proficient at the tasks required of them. This enables faster training and skill acquisition by the team members which can pay dividends when the project enters "crunch-time". | |
| 6 RUP | |
6.1 RUP vs. UPThe Unified Process is the non-commercial version of the Rational Unified Process. It can be purchased in the form of Jacobson, Booch, and Rumbaugh's book without ever using a product from Rational or writing them a cheque. So what does the Rational Unified Process offer over and above the Unified Process?
6.2 RUP in IndustryRational Software's website http://www.rational.com provides a number of success stories from various organizations which have implemented and are using RUP. While not entirely empirical they show the widespread acceptance for RUP and it's practices. The various success stories quote wide ranging improvements in software development processes and results. | |
| 7 Comparison to Agile | |
7.1 Waterfall or AgileIn the preceding section we can see that the Unified Process sets itself apart from the waterfall processes by operating on an iterative and incremental basis. Rather than implementing each stage of the process sequentially UP allows for change and does not force the user to complete one stage of the process before starting another. From this we can see that UP has evolved past a purely waterfall process. The next question in today's market is 'Is the Unified Process an Agile Process?'. Currently Rational Software Corporation is marketing RUP (the commercial version of the Unified Process) as being an agile process. And is trying to show that it can be tailored to be as agile as the other 'hot' agile processes like XP and RUP. Following is a comparison of RUP to XP/Agile process based on some key areas;
7.2 Basis for XP?The following is an excerpt from Object-Oriented Analysis and Design with Applications by Grady Booch, Robert Martin and Jim Newkirk it describes the relationship between the Unified Process and Extreme Programming. We discussed a minimal implementation of RUP which we called dX . The principles and practices of dX were identified several years ago by Ward Cunningham, Kent Beck, Ron Jeffries, and a host of other developers and methodologists. They have used this process on several projects with significant success. Because of that success, they have gathered quite a following. They call the process Extreme Programming; or for short: XP. | |
| 9 Appendix | |||||||||||
9.1 ReferencesJacobson, Booch, and Rumbaugh. The Unified Software Development Process. Addison-Wesley. Boston, MA. 1999. Rational Software Corp. Rational Unified Process: Best Practises for Software Development Teams. 2002. http://www.rational.com/products/whitepapers/100420.jsp Sun Microsystems Ltd. JavaBeans Component Architecture. 2002. http://java.sun.com/products/javabeans/ Grady Booch, Robert Martin and Jim Newkirk Object-Oriented Analysis and Design with Applications (3rd Edition). Per Kroll The RUP: An Industry-wide Platform for Best Practices http://www.therationaledge.com/content/dec_01/f_TheRUP_pk.html Jacobson I., Christerson M., Johnson P., Overgaard G., Object-Oriented Software Engineering – A Use Case Driven Approach, Addison Wesley – ACM Press,1992 Doug Rosenberg, Kendall Scott,Top Ten Use Case Mistakes, Feb.,2001 http://www.sdmagazine.com/documents/s=815/sdm0102c/ Krutchen P., Use Case Storyboards in the Rational Unified Process, Workshop on Integrating Human Factors in Use Case and OO Methods. 12th European Conference on Object-Oriented Programming. Lisbon, Portugal, June 14-20, 1999. Scott W. Ambler Strategies for requirements-based planning, President, Ronin International,December 2000. Leslee Probasco, Dean Leffingwell,Combining Software Requirements Specifications with Use-Case Modeling, Rational Software H. Antunes, A. Seffah, T. Radhakrishnan, S. Pestina, Unifying User-Centered and Use-Case Driven Requirements Engineering Lifecycle 9.2 Glossary
|
|
|
SENG 623: Unified Process Group Last Modified: |
|
|
Kobe DavisLinda CaiGuy Davis
|
