 |
|
|||||||||||||||||
Rational Unified ProcessThe Rational Unified Process is an iterative software design method created by the Rational Software Corporation, now a division of IBM. It describes how to deploy software effectively using commercially proven techniques. It is not a process but a process framework or meta-model. It encompasses a large number of different activities, and is designed to be tailored, in the sense of selecting only the needed features suited for a particular software project, considering its size and type. It is recognized to be particularly applicable to larger software development teams working on large projects. The writers or developers of this Software engineering Process focused on diagnosing the characteristics of different software projects that failed; by doing this they tried to recognize what the common aspects were that made these software projects to fail. They also looked at the existing software engineering Processes and their solutions for these symptoms that caused the failure of these projects. The symptoms are:
What seems to be the case is that project failure is caused by a combination of several of these symptoms even though each project fails in a unique way. Thus, the outcome was a Software best practice that attacks the basic causes of software failure. The paragraphs below describe these six best practices. Knowing the problems that cause software project failures does not guarantee a software engineer to develop a successful software product. The software engineer knows the problem but he/she does not know the solution to overcome this problem. To give the software engineers and software project managers the solutions to these problems The Rational Unified Process Product has been developed. (Please note: this article has been abstracted from RUP as defined by the Rational Corporation, which is responsible for its development. It also attempts to be concise, outlining the reasoning behind the RUP as opposed to the specific methodologies used) Alternate approaches within the field of software engineering include:
The Rational Unified Process ProductThe Rational Unified Process Product is a web site description of the Rational Unified Process. This product is delivered and maintained by Rational Software; now a division of IBM. The fundamentals of the rational unified process are the implementation of the six best practices. By implementing iterative development, requirements management, component-based architecture, visual modeling software, software quality verification, and controlling software changes the rational unified process tries to prevent software projects failure by tackling and attacking the problems that cause software project failures. The process product is a document that tells a team of developers and project managers how to implement the process for the current development project or in the organization if it is meant for long term use with in the organization. Other documents describe what the activities of the different engineers are and which products (Artifacts) they should produce. In the process product there are also guidelines that tell how to produce an artifact. The process product also describes which tools to use when you are working on an artifact, besides tools there are possibilities to use temples when working on an artifact. The Rational Unified Process overview
The Rational Unified Process ArchitectureThe Rational Unified Process has been design with techniques similar to techniques that are used to design software. Especially, the process has an underlying object-oriented model, using Unified Modeling Language UML. The right side of the figure above shows the process structure. The dynamic aspects of RUPThe dynamic aspects of the process show how the process evolves by going through cycles, Phases, iterations and milestones. CyclesA development cycle in this context means the time between the start of software development process and end of that process. In the rational Unified process the software product lifecycle is broken in to cycles. The software lifecycle means the time that the software product is either functionally or economically usable. Within each development cycle a new release of the software product is realized. The rational unified process divides a development cycle into four phases. The phases are:
PhasesA software project can be divided into four or five parts with each a main purpose. At the start of a project the feasibility of the project must be checked looking at the risks, budget, available human and other resources etc. In the rational unified process this happens in a part or rather phase called the inception phase. As noted above the rational unified process comprises three other phases called Elaboration, Construction and Transition. Other software development processes often divide the process in five phases called: analysis, design, implement, integrate, test. The achievements of the phases are examined with milestones that are well defined in RUP. An import remark is that phases can also be divided into iterations. The Inception PhaseIn this phase a business case which includes: Business context, Success factors such as (expected revenue, market recognition, etc), and Financial forecast are established. Besides a business case a basic use case model, project plan, initial risk assessment and a document that generally describes the project (the core project requirements, constraints and key features) are realized. The rational unified process examines at the end of the inception phase whether the required criteria for this phase are met. The required criteria are:
If the project does not pass for this milestone, it may be cancelled or prior decision must be well rethought to fix risks that can cause project failure. The Elaboration PhaseThe Elaboration phase is where big things happened!, in this phase the problem domain analysis is made and also the architecture of the project gets its basic form. There is big step from this to next because this step means transition from low-risk operation to high-risk operation. This phase must also pass a milestone called a lifecycle architecture milestone which examines existence of a stable architecture, stable vision of the product etc. The Construction PhaseIn this phase the main focus goes to the development of components and other features of the system that is being developed. This is the phase when coding takes place. At the end of this phase the first release of the software product is expected and this is a major criterion of its milestone. The Transition PhaseThe transition is phase where the product moved from the development organization to the client organization. IterationsThe phases in the rational unified process can be divided into several iterations. An iteration can be explained as mini project within a project. This name is caused by the nature that of an iterations in the rational unified process. In the process an iteration goes through all the workflows, and usually results in an executable product, which is not is not complete but a subset of the final system in development. Dividing the projects phases has allot of advantages such risk mitigation in an early phase of the project but it is also much more difficult then the traditional sequential approach and needs much more guidance and effort. The rational Unified Process has a workflow called The Project Management Workflow and this workflow has sub-workflows that guide the project manager how to answer questions about the iteration management. This workflow shows that planning an iterative project means that two kinds of plans are needed: the phase plan and the iteration plan. A project has only ONE phase plan but many iteration plans. An example that depicts the difference between the traditional sequential approach and the iterative approach is given below. Example
MilestonesIn the rational unified process there are four major milestones. Each of these milestones is a moment in the timeline and exactly at the end of each phase. Milestones are planned and the progress of the project is examined when the milestone is reached. If the expectations are not satisfied and the criteria are not met depending on the phase of the project the project can be stopped or a new iteration can be started to revisit the bottlenecks. To emphasize the links between phases and milestones a Meta-model of a milestone will be depicted. Model will be added soon The dynamic view of the rational unified process can be meta-modelled as follows: Model will be added soon Static aspects of the RUPThe static aspects view of the process describes who are doing what, when and how they are doing it. The who in the sentence is called worker in the rational unified process. The what is called artifact The when is called workflow The how is called activity This side of the process is called static because it describes how things are done. It is more or less not dependent on the project that is at hand. For example the description of the tasks and deliverables of a use-case designer are same for each project. WorkersWorker is a word that defines the behaviour and responsibilities of a person or a group of persons that are forming a team. The rational unified process notes that a workers are individuals; instead the roles of these individuals. To understand what this means here is an example: A person can be a graphical user interface designer in a given day and the same person can be a use case designer the day after, so this person represents two workers in the different workdays. ArtifactsArtifacts are the outcomes of activities. During a software process alot of documents and models are produced while working towards the end of the project, these products are called artifacts in the rational unified process. Other software development processes use other terms such as work product or work unit when referring to products that are called artifacts by the rational unified process. ActivitiesActivities are performances of workers when executing tasks. In the rational unified process each worker has activities and these activities define the work that is supposed to done by this worker. WorkflowsWorkflow means a sequence of activities. The rational unified process organizes it’s workflows as following:
In the process all workers and activities are divided over nine core workflows. The division of the workflows is based on logical groupings. The nine core workflows are then farther divided into six core engineering workflows and three supporting workflows.
And the three supporting workflows are:
Workflow Example Model will be added soon With this kind of illustrations the rational unified process tries to depict the sequence of activities which is equivalent to workflows. The arrows between the two workflows show the dependencies between the workflows. Remark: It is not always possible to represent all the dependencies between the activities, because people don’t necessarily follow the workflows as machines. Business modellingThe aim of business modelling is to establish a better understanding or a 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, must unsure a common understand of the target organisation between customers, end users and developers. The rational unified process business modeling workflow describes how to describe a vision of the organisation in which the system will be deployed and using this vision as a basis a way to outline the process, roles and responsibilities. Why business modellingIt’s obvious that organisations are becoming more and more dependent on software and hardware systems (IT). With this as fact it is important for information system engineers to know that the applications that are too be developed need to fit into these organizations. Investments in IT are caused because organizations realize that they can gain competitive advantage with the help of IT and they are waiting from these applications to add value into the business instead of causing headaches and loos of productivity. So, it is important to try to understand the business domain before, or in parallel with, a software development project. The internet hype is driving the importance of business modeling when developing software products. Thanks to the internet it is now possible for companies to offer their products and services to markets without geographical obstacles. Companies that want to take advantage of these opportunities must automate their business process. (Companies purchasing raw materials and parts on the internet or those trying to sell their products through e-commerce are examples.) using software engineering techniques for business modelingThe purpose of business modeling is achieving proper understanding between business engineering and software engineering. By using similar techniques while modeling the ‘business’ and the ‘software’ a common language can be created which is a good thing for both business and software engineers. Similarities between notations in business engineering and software engineering in RUPBusiness notation Software notation Business actor (Customers, vendors, partners) Actor (End user) Business use case (business processes) Use case (System processes)
Six captured best practices of RUP
Develop software iterativelyGiven the time it takes to develop large sophisticated software systems it is not possible to define the problem and build the solution in a single step. Requirements will often change throughout a project's development, due to architectural constraints, customer's needs or a greater understanding of the original problem. Iteration allows greater understanding of a project through successive refinements and addresses a project's highest risk items as the highest priority task - at every stage of iteration. Ideally each iteration ends up with an executable release – this helps reduce a project's risk profile, allows greater customer feedback and helps developers stay focused. In the wikipage iterative and incremental development a wide description of the concept is given. Iterative Development is in this context the approach that is recommended by the rational unified process. Allot of software development processes recommend a traditional waterfall approach. According to the rational unified process this approach is generally better then the linear or the waterfall approach because of the following reasons:
Manage requirementsRequirements Management in the rational unified process is concerned with meeting the needs of end users by identifying and specifying what they need. So, requirements management must identify, organize, communicate and manage the changing requirements. Requirements Management is one of the six best practices in the rational unified process because effective requirements management has several benefits that can lead to realization of successful software project. These benefits include the following:
The rational Unified Process implemented a section about requirements management because they believe that managing requirements improves the chance of success to software development project. Use component based architectureComponent Based Architecture creates a system that is easily extensible, promotes software reuse and intuitively understandable. A component often relates to an object in Object-oriented programming. Software Architecture is becoming more and more important as systems that are to be developed become bigger and more complex. The Rational Unified Process focuses on producing the basic architecture in the early iterations. This architecture then becomes a kind of prototype architecture in the initial development cycle. From the initial development cycle this architecture evolves with the next iterations to become the final system architecture. The Rational Unified Process provides documentations that systematically guide the developers to design, develop and if needed improve an architecture. It also provides design rules and constraints to capture architectural rules. By developing iteratively it is possible to gradually identify components. These components can be developed, bought or reused. The Rational Unified Process supports component-based development. These components are often assembled within existing infrastructures such as CORBA and COM, or J2EE. Visually model softwareAbstracting your programming from its code and representing it using graphical building blocks is an effective way to get an overall picture of a solution. This makes it easier for technical staff on a project to figure out how best to implement a given set of inter-related logics, and also builds an intermediary between the business process and actual code making it happen through information technology. A model in this context is a visualisation and at the same time simplification of complex system that we can’t easily understand if such a model did not existed. The Rational Unified Process focuses very much on developing models of the system that is being developed. The Unified Modeling Language (UML) which is also developed by Rational Software is used for modeling Use-Cases, Class diagrams and much more. The rational Unified Process describes which models you need, why you need these models and how the models could be built. Verify software qualityQuality Assessment is the most common failing point of all software projects, often an afterthought in such projects and even handled by a different team. The RUP assists in planning quality control and assessment built into the entire process involving all members of a team. In doing so, The Rational Unified Process has surprisingly no worker in charge of quality!. In many software development processes there is quality manager that checks the quality of each product when it is finished. The Rational Unified Process assumes that quality is not added by only one person but by all members of the team. The Rational Unified Process focuses on meeting the expected level of product quality. Within the Rational Unified Process there is test workflow that is with a primary purpose of measuring the level of the product quality. Control changes to softwareIn all software projects change is inevitable, the RUP defines methods to control, track and monitor changes. As a seemingly small change can affect applications in entirely unpredictable ways this is essential for a successful project. The RUP also defines secure workspaces allowing a programmer to be guaranteed that changes in another system will not affect his system. This ties in heavily with Component based architectures. By following an iterative approach the need for Configuration and Change Management will be even more necessary because each iteration will produce allot of artifacts. These artifacts will not be developed once but are updated again and again in an iterative development such as the RUP. The Rational Unified Process has a Configuration and Change Management workflow that deals with three things:
The rational unified process describes with these three things being sub-aspects of the configuration and change management workflow how to control, monitor and track changes in artefacts to enable a successful iterative development. Configuration ManagementThe Configuration management view of the configuration and change management workflow is responsible for the systematic structuring of the products. In projects allot of the produced artefacts such as documents and models are placed under version control which must make sure that changes are visible. The visualization of change is realized by developing multiple versions of an artefact. The configuration and change management also keeps track of dependencies between artifacts; because it’s important to know which artefacts must be revisited if a change is made to another artefact. Change Request ManagementDuring the system development process many artifacts with several versions exist. A controlling process that keeps track of the proposals for change is needed. This process is in fact CRM. A detailed description of CRM is given in wikipage change management. Status and Measurement ManagementChange requests have states such as new, logged, approved, assigned and complete. A change request also has attributes such as root cause, or nature (like defect and enhancement), priority etc. If these states and attributes are stored in database useful reports about the progress of the project could be produced.
See also
External links
The contents of this article are licensed from Wikipedia.org under the GNU Free Documentation License.
How to see transparent copy 01-04-2007 01:21:04 |
|
