In addition, objective measures of progress are captured. Some reworking takes place from one iteration to the next, but this, too, is carefully controlled.
Manage Requirements Requirements management is a systematic approach to eliciting, organizing, communicating, and managing the changing requirements of a software-intensive system or application. The fundamental measure of quality is whether a system does what it is supposed to do.
With the Rational Unified Process, this can be more easily assessed because all stakeholders have a common understanding of what must be built and tested. Fixing errors in requirements is very expensive. With effective requirements management, you can decrease these errors early in the development, thereby cutting project costs and preventing delays. Requirements management facilitates the involvement of users early in the process, helping to ensure that the application meets their needs.
Well-managed requirements build a common understanding of the project needs and commitments among the stakeholders: users, customers, management, designers, and testers. It is often difficult to look at a traditional object-oriented system model and tell how the system does what it is supposed to do. This difficulty stems from the lack of a consistent, visible thread through the system when it performs certain tasks.
In the Rational Unified Process, use cases provide that thread by defining the behavior performed by a system. Use cases are not required in object orientation, nor are they a compulsory vehicle in the Rational Unified Process.
Where they are appropriate, however, they provide an important link between system requirements and other development artifacts, such as design and tests. Other object-oriented methods provide use-case-like representation but use different names for it, such as scenarios or threads.
The Rational Unified Process is a use-case-driven approach, which means that the use cases defined for the system can serve as the foundation for the rest of the development process.
Use cases used for capturing requirements play a major role in several of the process workflows, especially design, test, user-interface design, and project management. They are also critical to business modeling. Use Component-Based Architecture Use cases drive the Rational Unified Process throughout the entire lifecycle, but design activities center on architecture -- either system architecture or, for software-intensive systems, software architecture.
The main focus of early iterations is to produce and validate a software architecture. In the initial development cycle, this takes the form of an executable architectural prototype that gradually evolves, through subsequent iterations, into the final system.
The Rational Unified Process provides a methodical, systematic way to design, develop, and validate an architecture. It offers templates for describing an architecture based on the concept of multiple architectural views. The design process component contains specific activities aimed at identifying architectural constraints and architecturally significant elements, as well as guidelines on how to make architectural choices.
The management process shows how planning the early iterations takes into account the design of an architecture and the resolution of major technical risks. A component can be defined as a nontrivial piece of software: a module, package, or subsystem that fulfills a clear function, has a clear boundary, and can be integrated into a well-defined architecture.
It is the physical realization of an abstraction in your design. These components can be individually tested and gradually integrated to form the whole system. Reusable components are typically larger than mere collections of utilities or class libraries. They form the basis of reuse within an organization, increasing overall software productivity and quality. The first point above exploits the old concepts of modularity and encapsulation, bringing the concepts underlying object-oriented technology a step further.
The final two points shift software development from programming software one line at a time to composing software by assembling components. The Rational Unified Process supports component-based development in several ways.
The architecture enumerates the components and the ways they integrate, as well as the fundamental mechanisms and patterns by which they interact. Visually Model Software Models are simplifications of reality; they help us to understand and shape both a problem and its solution, and to comprehend large, complex systems that we could not otherwise understand as a whole.
A large part of the Rational Unified Process is about developing and maintaining models of the system under development. The Unified Modeling Language UML is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.
It gives you a standard means of writing the system's blueprints, covering conceptual items such as business processes and system functions, as well as concrete items such as classes written in a specific programming language, database schemas, and reusable software components. While it provides the vocabulary to express various models, the UML does not tell you how to develop software.
It describes the models you need, why you need them, and how to construct them. Continuously Verify Quality Often people ask why there is no worker in charge of quality in the Rational Unified Process. The answer is that quality is not added to a product by a few people. Instead, quality is the responsibility of every member of the development organization.
In software development, our concern about quality is focused on two areas: product quality and process quality. Additionally, process quality is concerned with the quality of the artifacts such as iteration plans, test plans, use-case realizations, design model, and so on produced in support of the principal product.
Control Changes to Software Particularly in an iterative development, many work products are often modified. By allowing flexibility in the planning and execution of the development and by allowing the requirements to evolve, iterative development emphasizes the vital issues of keeping track of changes and ensuring that everything and everyone is in sync.
Focused closely on the needs of the development organization, change management is a systematic approach to managing changes in requirements, design, and implementation. Change management is tied to configuration management and measurements. More than a thousand companies were using the Rational Unified Process at the end of They use it in various application domains, for both large and small projects.
This shows the versatility and wide applicability of the Rational Unified Process. This is a sign of change in our industry: as the time-to-market pressure increases, as well as the demand for quality, companies are looking at learning from others' experience, and are ready to adopt proven best practices.
The way these organizations use the Rational Unified Process also varies greatly: some use it very formally; they have evolved their own company process from the Rational Unified Process, which they follow with great care. Other organizations have a more informal usage, taking the Rational Unified Process as a repository of advice, templates, and guidance that they use as they go along -- as a sort of "electronic coach" on software engineering. By working with these customers, observing how they use the RUP, listening to their feedback, looking at the additions they make to the process to address specific concerns, the RUP development team at Rational continues to refine the process for the benefit of all.
For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you! To browse Academia. Log in with Facebook Log in with Google. Remember me on this computer. Enter the email address you signed up with and we'll email you a reset link. Need an account? Click here to sign up.
Download Free PDF. Ashraf Anwar, Ashraf Anwar. A short summary of this paper. Download Download PDF. Translate PDF. Wennerlund then proposed the Unified Process [1]. This paper represents an overview of Rational Unified Process; its history, and practices involved; stressing its advantages and disadvantages. A comparison with other approaches is mentioned in context; whenever appropriate. According to Rational; developers of Rational Rose and the Unified Modeling Language, RUP is like an online mentor that provides guidelines, templates, and examples for all aspects and stages of program development.
RUP and similar products -- such as Object-Oriented Software Process OOSP , and the OPEN Process -- are comprehensive software engineering tools that combine the procedural aspects of development such as defined stages, techniques, and practices with other components of development such as documents, diagrams, models, manuals, help files, code samples, final source code, etc… within a unifying framework.
Such factors are especially important when dealing with huge projects in big enterprises. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget.
The development team for the RUP is working closely with customers, partners, Rational product groups, as well as Rational consultant organization; to ensure that the process is continuously updated and improved upon; to reflect recent experiences, evolving practices, and proven best practices. By having all team members accessing the same knowledge base, no matter if you work with requirements, design, test, project management, or configuration management; they ensure that all team members use Unified Process activities to create and maintain models.
Rather than focusing on the production of large amount of paper documents, the Unified Process emphasizes the development and maintenance of models; semantically rich representations of the software system under development.
The UML is an industry-standard language that allows us to clearly communicate requirements, architectures and designs. The Rational Unified Process is supported by tools, which automate large parts of the process. Those tools are used to create and maintain the various artifactsmodels in particularof the software engineering process: visual modeling, programming, testing, etc. They are invaluable in supporting all the bookkeeping associated with change management, and configuration management; that accompanies iterations in RUP.
RUP is a configurable process. No single process is suitable for all sorts of software development. The Unified Process fits small development teams; as well as large development organizations. The Unified Process is founded on a simple and clear process architecture that provides commonality across a family of processes.
Yet, it can be varied to accommodate different situations. It contains a Development Kit, providing support for configuring the process to suit the needs of a given organization. The RUP captures many of the best practices in modern software development in a form that is suitable for a wide range of projects and organizations.
See Figures 1 and 2 below. The dynamic perspective shows the RUP phases over time. The processes shown in this perspective are dynamic i. The static perspective shows the statics aspects of the RUP phrases. This perspective is made of things that do not change themselves but work to change the dynamic processes. The practice perspective is made of the good practices used during the process. Those are practices well known of their effectiveness and usefulness through previous work and experience.
It is expressed in terms of cycles, phases, iterations and milestones. It is expressed in terms of activities, artifacts, workers and workflows. A RUP project has four phases: inception, elaboration, construction, and transition; as in Figure 4 below.
Each phase has one or more iterations and is completed with a milestone. At that point, the project progress is assessed, and major decisions are made based on that progress.
The focus of the iterations in each phase is to produce technical deliverables that will fulfill the phase objectives. The project has to be validated; so that a budget can be approved. A business case for the project is produced which includes the business environment, success factors such as expected revenue, or return on investment: ROI and financial forecast [12].
After everything has been prepared, the project team should be able to decide whether to proceed or not. This is somewhat similar to approving a feasibility study [9]. A vision document should be prepared i. If the project does not pass that milestone, it can either be cancelled or it can be redesigned so that it can fulfill the constraints and criteria missing. The purpose of this phase is to create a basic system the architecture of the system which will answer major technical questions; i.
At the end of this phase, the project team should be able to decide whether they can build a successfully working system. Prototypes that lessen the technical risks that were identified in the previous stage. This is the second milestone, and is known as the Lifecycle Architecture Milestone. If the project is unable to pass this milestone, it can either be cancelled or redesigned. A decision to proceed should be taken carefully because after this stage, the project become a high-risk operation where changes are harder to make, and could have a damaging effect.
The main focus is on developing components and other features. Most of the coding is done in this phase; as well as extensive testing. In large projects, there may be several construction phases; this is helpful as it allows the use cases to be divided into smaller, more manageable segments. At the end of this stage, the project team should have user manuals and a beta version of the system ready to be evaluated.
The transition stage can be delayed if the product is not stable enough to be tested by end users, or if the actual resource expenditures are not acceptable when compared to planned expenditures.
The system must fulfill the software requirements and needs of its users; so in this stage, the system is evaluated and refined based on feedback from the users. This phase also includes training end users. The product is also checked against the quality standards that were set in the inception phase. At the end of this phase, the system is released and the project is evaluated. This is the last milestone and is known as the Product Release Milestone.
This phase concludes the RUP software development cycle. Each phase will include some or all of the development workflows disciplines. However, the amount of work in each workflow will differ in each phase. For example, in the inception phase, most of the work will focus on business modeling and obtaining requirements.
But in the construction phase, the focal point will be implementation. Workflows relate activities, artifacts, and roles in sequences that produce valuable results. We could regard a worker as a "hat" an individual can wear in the project. One individual may wear many different hats. This is an important distinction; because it is natural to think of a worker as the individual or team itself.
But in the Unified Process the worker is more the role defining how an individual should carry out the work. The responsibilities we assign to a worker include both to perform a certain set of activities; as well as being owner of a set of artifacts. The activity has a clear purpose, usually expressed in terms of creating or updating some artifacts, such as a model, class, or plan.
Every activity is assigned to a specific worker. The granularity of an activity is generally a few hours to a few days; it usually involves one worker, and affects one or only a small number of artifacts. Notice that Mary; the second actor, is the Use-Case creator and worker. Her activity is to fill in the details of Use-Cases. Artifacts are typically the tangible products of the project; the things the project produces or uses while working towards the final product.
Artifacts are used as input by workers to perform an activity, and are the result or output of such activities. We need a way to describe meaningful sequences of activities that produce some valuable results, and to show interactions between workers.
A workflow is a sequence of activities that produces a result of observable value; i. In UML terms, a workflow can be expressed as a sequence diagram, a collaboration diagram, or an activity diagram. Business modeling workflow 2. Requirements workflow; Figure 7 above 3.
Implementation workflow 5. Testing workflow 6. Deployment workflow Figure 8 below shows an example of workflow with actors involved. Environment workflow 2. Configuration and Change Management workflow 3. Project Management workflow 3. Businesses invest in IT when they understand the competitive advantage and value added by the technology.
The aim of business modeling is to first establish a better understanding and communication channel between business engineering and software engineering. Understanding the business means that software engineers must understand the structure and the dynamics of the target organization the client , the current problems in the organization and possible improvements [13].
They must also ensure a common understanding of the target organization between customers, end users and developers. This leads to the output from business engineering not being used properly as input to the software development effort, and vice-versa.
The Rational Unified Process addresses this by providing a common language and process for both communities, as well as showing how to create and maintain direct traceability between business and software models [14]. In business modelling, we document business processes using so called business use cases. This assures a common understanding among all stakeholders of what business processes that need to be supported in the organization.
The Rational Unified Process business use cases are analyzed to understand how the business should support the business processes; partly through using Best Practices for Software Development Teams. This support is documented in a business object-model. However, many projects may choose not to do business modeling; though.
The goal of the Requirements workflow is to describe what the system should do and allows the developers and the customers to agree on that description. To achieve this, we elicit, organize, and document required functionality and constraints; track and document tradeoffs and decisions.
A Vision document is created, and stakeholder needs are elicited. Actors are identified, representing the various users, and any other system that may interact with the system being developed.
Use-Cases are identified; representing the behavior of the system. Because use cases are developed according to the actor's needs, the system is more likely to be relevant to the users. Figure 9 shows an example of a use-case model for a recycling-machine system.
Is easy to change when requirements change; i. Design phase results in a design model, and analysis phase optionally results in an analysis model. The design model serves as an abstraction of the source code; that is, the design model acts as a 'blueprint' of how the source code will be structured and written.
The design model consists of design classes structured into packages and subsystems with well-defined interfaces, representing what will become components in the implementation.
0コメント