Rational Unified Process is a process of software engineering. It provides disciplined methods for dispatching tasks and responsibilities in the development organization. Its goal is to ensure high quality products that meet the end user needs under the presence of the foreseeable schedule and budget.
What is the Rational Unified Process? Rational Unified Process is a process of software engineering. It provides disciplined methods for dispatching tasks and responsibilities in the development organization. Its goal is to ensure high quality products that meet the end user needs under the presence of the foreseeable schedule and budget.
Rational Unified Process is a process product developed and maintained by Rational. The development team of Rational Unified Process collaborates with customers, partners, Rational Products Groups and Consultants to ensure the continuous renewal of development process to reflect new experience and continuous evolutionary practices.
Rational Unified Process improves team productivity. For all key development activities, it provides knowledge base for each team member to access the knowledge of the criteria, template, and tool guidance. Through understanding of the same knowledge base,
Whether you are a need for analysis, design, test project management, or configuration management, you can ensure that all members share the same knowledge, process and development software.
Activity creation and maintenance model of Rational Unified Process. Rational Unified Process emphasizes the development and maintenance model - a semantic rich software system expression, not emphasizing a large number of text work.
Rational Unified Process is a guide to use UNIfied Modeling Language (UML). UML is a good communication requirement, architecture and design of industrial standard languages. UML is created by Rational Software and is now maintained by a standardized object management agency (OMG).
Rational Unified Process provides automated tool support for most development processes. They are used to create and maintain a wide range of products of software development process (visual modeling, programming, testing, etc.) - especially models. In addition, it is also very valuable in terms of the change management and configuration management of each iterative process.
Rational Unified Process is a configurable process. No development process can be suitable for all software development. Rational Unified Process is also applicable to small development teams for large development organizations. Rational Unified Process has established a concise and clear process structure to provide versatility for the development process family. Also, it can be changed to accommodate different situations. It also includes development kits that provide support for the development process that adapts to a particular organization.
Rational Unified Process captures the best practices for many modern software development processes in a wide range of projects and agencies. Deploying these best practices - using Rational Unified Process as a guide - providing a large number of key advantages to the development team. In the next section, we describe the 6 basic best practices of Rational Unified Process.
The effective deployment of 6 best practices Rational Unified Process describes how to develop a commercially verified software development method for a secure deployment of a software development team. They are called "best practices" not only because you can accurately quantify their value, and they are widely used by many successful institutions. In order to make the entire team effectively utilize best practices, Rational Unified Process provides the necessary guidelines, templates and tool guidance for each team member;
Iterative Development Software Demand Management Use components-based architecture visualization software modeling verification software quality control software change
Iterative Development Products - In the face of today's complex software systems, use continuous development methods:, such as first defining the entire problem, design a complete solution, preparing software and final testing products, is impossible. A iterative method capable of generating an effective solution can be generated by a series of refinement, several progressive repetition processes. Rational Unified Process supports iterative development methods focusing on the highest risk in each stage in the life cycle, greatly reduces the risk of projects. Iterative methods help reduce risk-regular, executable versions to make end users constantly intervention and feedback. Because each iterative process ends in executable versions, the development team stays on the result, frequent status check helps ensure that the project can be performed on time. Iterative method is equally easier to change the demand, characteristics, and schedule. Demand Management - Rational Unified Process describes how to extract, organize and document the functions and restrictions; tracking and documentation compromise; capture and conduct business needs exchange. The use of use cases and scenes is proved to be an excellent way to capture functional demand and ensure that they can drive design, implementation, and software tests, so that the final system can meet the needs of end users. They provide continuous and trackable clues to the development and distribution system. __
Component-based architecture - the process focuses on the baseline of early development and robust can perform system structures before the development of development. It describes how to design flexible, can accommodate, intuitive and easy to understand, and promote effective software reuse elastic structures. Rational Unified Process supports component-based software development. The component is a module and subsystem that implements a clear function. Rational Unified Process provides a systematic approach to defining architectures using new and existing components. They are assembled as a well-defined structure, or special, underlying structures such as industrial grade reuse components such as Internet, CORBA and COM.
Visual Software Modeling - The development process shows how the software can visualize, capture architecture, and components. This allows you to hide detail and use the "Graphics Megail" to write code. Visualization Abstraction helps you communicate different aspects of software, how to observe how each element is fitted, ensuring that the component module is consistent with the code, maintains the consistency of design and implementation, and promotes clear communication. The industrial grade standard Unified Modeling Language (UML) created by Rational Software Co., Ltd. is the basis for successful visualization software modeling.
Verify software quality - poor application performance and reliability are dramatic demonstrations showing today's software acceptability. Thus, quality should be verified based on reliability, functionality, application, and system performance. Rational Unified Process Help Plan, Design, Implementation, Executive, and Evaluate these Test Types. Quality Assessment is built into process, all activities, including all members, using objective metrics and standards, and is not separation activities for post-type or separate groups.
Control software change - the ability to manage changes - determine that each modification is acceptable, can be tracked - it is necessary to change the environment. The development process describes how to control, track and monitor modifications to ensure successful iteration development. It also guides how to create a secure work area for each developer by isolating modifications and controlling the modifications of the entire software product (eg, model, code, document, etc.). In addition, it operates by describing how to perform automation integration and establish management, making the team like a single unit.
Process introduction
Two-dimensional structure
The development process can be expressed in a two-dimensional structure or in two coordinate axes:
The horizontal axis represents the time when the development process is developed, reflecting the dynamic structure of the process. It is expressed in terms cycle, phase, iteration, and milestone. The longitudinal axis exhibits a static structure of the process: how to describe the term activity, the product, the product, the role (Worker), and workflow). Iterative model diagram shows the two-dimensional structure of the process
Stage and iteration-Timeline This is a dynamic organizational structure along the development process.
The software life cycle is decomposed into a cycle, and every cycle works in a new generation of products. Rational Unified Process The cycle is divided into four consecutive phases.
Initial stage refinement stage construction phase delivery phase
Each phase is ended in a good definition milestone - some key decisions must be made, so the key target must be reached.
Stage and main milestones during the process
Each stage has a clear goal.
The initial phase
The goal of the initial stage is to establish a business case and determine the boundary of the project.
In order to achieve this purpose, all external entities that interact with the system must be identified, and the interaction characteristics are defined at higher levels. It includes identifying all use cases and describes some important use cases. Business case includes acceptance specifications, risk assessments, resource estimates, and stages of the main milestones.
This stage is very important, in this stage, focusing on the main risks of business and demand in engineering throughout the project. For development projects based on the original system, the initial phase may be short.
The main objectives in this stage are as follows:
Clarify the scope and boundary conditions of the software system, including prospects from functional angles, product acceptance standards and which do not do related decisions clearly distinguish between system-case-case-case-case, and main function scenarios, at least A candidate software architecture that meets the main scene requirements For the initial project cost and schedule estimation of the entire project (more detailed estimate will be made in subsequent refinement phases) estimate potential risks (mainly refer to various uncertain) Potential risks caused by factors) Prepare the support environment of the project
The output of the initial stage is:
Blueprint Document Core Demand Key Features Main Constrained Overall Bluemap Original Model (10% ~ 20%) Original Project Glossary (Possible Partially Expressed as Business Model) Original business case, including business context, acceptance specifications (annual mapping, Market recognition, etc.), cost is expected to be original risk assessment one or more prototypes
Milestone: The goal of life cycle
At the end of the initial phase, it is the first important milestone: life cycle target milestone. Initial phase review standard:
Risk bearers Definition cost schedule estimation to reach a consensus to understand the concept of understanding of demand for demand / schedule, priority, risk, and development process to develop architecture prototype and planned expenses Comparison
If these milestones are not passed, the item may be canceled or re-considered carefully.
Refinement phase
The goal of the refining phase is to analyze the problem area, establish a sound architecture basis, prepare the project plan, and phase out the highest risk in the project.
In order to achieve this, the system must have "mile wide and inch deep". The decision of the architecture must be made on the basis of understanding the entire system: its range, main functions and non-functional needs such as performance.
It is easy to argue, and the refinement phase is the most critical phase in the four phases. At the end of this phase, hard "project" can be considered ended, and the project has undergone the final trial day: decision-making project submits to the construction and delivery phase. For most items, this is equivalent to transition from mobile, relaxed, dexterous, low-risk operations to high cost, high risks and has a greater inertia. The process must be able to accommodate changes, and the refinement phase activity ensures that the structure, demand and plan are sufficiently stable, and the risk is sufficiently reduced, so it can be predetermined for the development results to predetermine cost and schedule. Conceptually, its realistic degree is consistent in the necessary level of the institution's implementation of the fixed construction phase.
In the refinement phase, the active structure is established in one or more iterative processes, depending on the scope, scale, risk and advanced level of the project. The workload must deal with the key use case identified in the initial phase, and the key use case reveals the risk of project main technologies. Usually our goal is an evolutionable prototype consisting of product quality level components, but this does not exclude development of one or more exploratory, abandoned prototypes, such as: design / demand compromise, component feasibility study, or To investors, customers, the final user demonstration version, etc. The main objectives in this stage are as follows:
Make sure the software structure, demand, plan is sufficiently stable; ensure that project risks have been reduced to the extent to which the cost and schedule of the entire project can be expected. The main risks on the software structure of the project have been resolved or handled. Establish a baseline of the software architecture by completing the main scene on the software structure. Build an evolutionary product prototype containing high quality components. Note The baselined software architecture ensures that system requirements can be controlled within a reasonable cost and time range. Establish a support environment for products.
The output of the initial stage is:
The use case model (at least 80%) - all use cases are identified, most of the examples describe the description of the need for the demand software architecture description of the required software architecture description _ can be implemented by the required software architecture Risk list and business case overall project development plan, including textured project plan, showing iterative processes and corresponding audit criteria Indicate the initial version of the updated development case user manual for the use process (optional)
Milestone: Structure of life cycle
The end of the refinement phase is the second important milestone: the structural milestone of the life cycle. At this point, check the detailed system objectives
And scope, structural selection, and main risks. The main audit criteria include answering the following questions:
Is the blueprint of the product stable? Is the architecture stable? Does the executable demo version showing the problem of the resolution of the risk factor has been processed and reliable to resolve the plan in detail and accurate? Is it reliable for reviewing infrastructure? If the current plan has been implemented in an existing architecture environment, all risk assists agree that the blueprint is achievable? Is the actual cost expenditure and the planned expenses acceptable?
If these milestones are not passed, the item may be canceled or re-considered carefully.
Building phase
In the construction phase, all remaining components and application functions are developed and integrated into the product, and all features are detailed.
In a sense, in a sense, it is a focus on the management of resources and control operations to optimize cost, schedule, and quality. In this regard, the idea of management has experienced the transition of intellectual assets in the initial stage and refinement phase to the construction phase and delivery phase.
Many projects are large enough to produce many parallel incremental build processes, which can greatly accelerate the validity of version released; and increase the complexity of resource management and workflow synchronization. A robust architecture and easy-to-understand plan are highly associated. In other words, the key quality on the architecture is an easy degree of construct. This is also the reason why the architecture and the plan of the plan are emphasized in the refinement phase.
The main objectives in this stage are as follows:
By optimizing resources and avoiding unnecessary rework, the minimization of development costs According to the actual needs, the appropriate quality target is actually necessary to form various versions (Alpha, Beta, and Other Test Release) to complete analysis, design, development of all necessary features. And the test work develops a loop gradual way to develop a complete product that can be submitted to end users to determine that software site users have made relevant preparations for the product to achieve a certain degree of parallel development mechanism.
The output of the build phase is the product that can be delivered to the end user. It mins include:
Integrated Product User Manual on Specific Platform Current Version Description
Milestone: initial operation capacity
The end of the creation phase is the third important project milestone (initial function milestone). At this moment, it is decided whether software, environment, and users can operate without exposing projects to high risk. This version is also often referred to as "Beta" version. The main audit criteria in the construction phase include answering the following questions:
Does the product are sufficiently stable and mature to release to users? Whether all risk assumes are ready to hand over to users? Is the actual cost and plan fees still can still be accepted?
If you cannot pass these milestones, your handover has to be delayed.
Delivery phase
The purpose of the delivery phase is to deliver software products to user groups.
As long as the product is released to end users, the problem often appears: requires the development of new versions, correcting problems, or completing delayed issues.
When the baseline matures sufficiently to the end user, the delivery phase is entered. It typically requires that some available system subsets are developed to the received quality level and user documentation, thereby delivering all parts of the user can have a positive effect. This includes:
Control the user's expectation value, verify the "Beta Test" of the new system and the replaced translation of the alternative existing system and the transition to the market, deploy, and sales team
The construction phase focuses on submitting the product to the user. Typically, this phase includes several repetition processes, including Beba versions, universal versions, BUG patching and enhancements. A considerable amount of work consumption is developed for user-oriented documents and training users. Supports users and process users' feedback when used in initial products. This point of the development of life cycles, user feedback is mainly limited to product performance adjustment, configuration, installation, and use problems.
The goal of this phase is to ensure that software products can be submitted to end users. This stage can be divided into several cycles according to actual needs. The specific objectives of this stage are as follows:
Performing a BETA test to meet the needs of BETA testing and old systems to submit training for end users and product support staff to market and product sales departments and specific deployment related project activities coordinated BUG revision / improvement performance and Usability (USAbility), etc., based on complete Vision and product acceptance criteria to make the final deployment to assess the satisfaction of user requirements to achieve various risks to the product deployment baseline has completed the completed consensus to reach various risks to the product deployment complies with Vision Standard consensus
This phase may vary from very simple to extreme complicated ranges in accordance with the type of product. For example, the new version of the existing desktop products may be very simple, while the traffic system replacing international airport will be very complicated.
Milestone: product release
The end point in the delivery phase is the fourth important project milestone, product release milestones. At this point, it is decided whether the target has reached or start another cycle. In many cases, the milestone will overlap with the initial stage of the next cycle.
The review standards in the publishing phase mainly include the following two questions:
Is the user satisfied? Is the actual cost and the comparison of the plan fees still be accepted?
Iteration process
Each stage of Rational Unified Process can be further decomposed into iterative processes. The iterative process is a complete development cycle that leads to the executable product version (internal and external). It is a subset of the final product, from an iterative process to the other iterative process incrementally formed final system.
Benefits of iterative methods
Compared with traditional waterfall methods, iterative processes have the following advantages:
Reduced risk, more easily reused project teams for controlling highness, can learn better overall quality in development
Static structure of the process during the development process defines "Who" "When" "How to" "to do" something ". Four main modeling elements are used to express Rational Unified Process:
Role ("Who", "How to" Products, "Workflows", "When", "Workflow", Product, Role
Role, activity and work products
Character
The role defines the behavior and responsibility of individuals or groups of several people. It can be considered that the role is "hats" in the project group. Some individuals can wear multiple different hats. This is a very important difference. Because it is usually easy to think that the role is considered to be a personal or group itself, in Unified Process, the role also defines how to complete the work. The responsibility assigned to the role includes both a series of activities, as well as the owner of the product.
People and characters
activity
An activity of a role is a work unit that may be requested in this role. The event has a clear purpose, usually exhibiting some products, such as models, classes, plans, etc. Each activity is assigned to a specific role. Activity usually takes a few hours to several days, often involving one role, affecting one or a small amount of product. The event should be used as a plan and progress constituent element; if the activity is too small, it will be ignored, and if it is too big, progress has to be expressed as an integral part of the activity.
An example of an activity:
Plan an iterative process, corresponding role: Project manager finds USE Cases and Actors, corresponding roles: system analyst review design, corresponding role: design auditor execute performance test, corresponding role: Performance tester
product
The product is generated, modified, or a piece of information used in the process. The product is the actual product of the project, the items generated by the project, or use it when the final product is moved. The product is used as a role to perform an input input, and is also the output of the activity. In object-oriented design terms, such as operations are operated on an active object (role), the product is the parameters of these activities.
Products can have different forms:
Model, such as a USE-CASE model or design model model constitutes an element, that is, elements in the model, such as class, use case (USE case) or subsystem, such as business case or software structure document source code executable
Workflow
Relying on roles, activities, and product enumerations do not form a process. A method is taken to describe the active sequence that produces a number of valuable meaningful results, displaying the interaction between the roles.
Workflow is a sequence of activity with observable results.
In the UML terminology, the workflow can be expressed as a sequence diagram, a synergistic diagram, or an active diagram. In this context, the form of activity is used.
Workflow sample
Note that all dependencies between activities are not always possible or actually. Often intended more intellectuals more closely, especially when they involve the same role or individual. People are not machines. For people, workflows cannot be translated into procedures by literally, which is accurately, mechanically.
In the next section, we will discuss the most basic workflow during the development process, called the core workflow.
Core Workflows Rational Unified Process has 9 core workflows representing all roles and activity logical packets.
9 core process workflow
Core workflow is divided into 6 core "project" workflows
Commercial modeling workflow demand workflow analysis and design workflow to achieve workflow test workflow distribution workflow
And 3 core "support" workflow
Project management workflow configuration and change control workflow environment workflow
Although 6 core engineering workflow enable people to remember several stages in the traditional waterfall process, it should pay attention to the stage in the iterative process, and these workflows have been accessed again in the entire life period. 9 core workflows are used in the actual complete workflow in the project, and repeated in each iteration.
Commercial modeling
In order to determine the main problems of business engineering, software engineering staff and business engineers cannot communicate correctly. This has led to the output of commercial engineering, and it is not used as software development input, and vice versa. Rational Unified Process provides the same language and procedures for both groups, and shows how to create and maintain direct trackability in business and software models. In commercial modeling, use commercial use to document the business process, ensuring that all support business process staff in the organization reach a consensus. Commercial use cases are analyzed to understand how the business process is supported, and these are verified in the business object model.
Many projects may not be commercial modeling.
demand
The goal of demand workflow is to describe the system should do "what" and allow developers and users to reach a consensus on this description. In order to achieve this goal, the functions and constraints needed for extraction, organization, documentation; tracking, for trade-shek and deciding to form a document.
The blueprint is created and the demand is extracted. Actor represents users and other systems that may interact with the development system are specified. Use case is identified, indicating the behavior of the system. Because USE Case is developed according to the requirements of the Actor, the contact between the system and the user is more closely. The system shows the use case model for the regeneration system.
Sample use case model
Each use case is carefully described. Example Description Display how the system interacts with the Actor and the system. The demand for non-functionality is reflected in the supplementary description.
Use Case acts as a role in the development cycle clues throughout the system. The same use case model is used in the design phase and the test phase during the demand capture phase.
Analysis and design
The goal of analyzing design workflow is to display the system "how" is "implemented" in the implementation phase. You need a system:
In the specific implementation environment, the tasks and functions specified in the Example Example Description are met to meet all demand robust (if the function needs change, easy to change)
The analysis design results are a design model and an optional analysis model. The design model is an abstraction of the source code; the design model acts as a "blueprint" that is formed and prepared by the source code.
The design model consists of a design class and some description. Design classes are organized into a design package and design subsystem with a good interface, and the description reflects how the class objects can cooperate with the function of implementing the use case.
The following figure is a part of the design model example of the above-case model.
Part of the design model
Design activities are designated by architecture design. The product and verification of the structure is the main focus of the early iteration. The structure is expressed by several structural views that capture the decision of the main architectural design. Essentially, the structure view is abstract and simplified throughout the design, and the details are placed on the side, making important features more clear. Structure is not only a carrier medium of a good design model, but also enhances any quality of the model being created in the development of the system.
achieve
The purpose of implementing the stage:
Define the organizational structure of the code - Implement the class and object in the form of a hierarchical implement subsystem - the development of the components will be tested as a unit as a unit in the form of a component (source file, binary file, executable). The structural set generated by the implementator (or group) is an executable system.
The system is implemented by completing the component. Rational Unified Process describes how to reuse existing components, or implement new components defined by a good liability, making the system easier to use, improve the reusability of the system.
The component is configured to form a subsystem. Subsystems are behaving as a directory form with additional structures or management information. For example, a subsystem can be created as a folder or directory in a file system, or a package in Rational Apex for C or Ada, or Java.
test
The purpose of the test is:
The correct integration of the interaction of the verification object verifies that all requirements are properly implemented and ensure that the defects before the software is released.
Rational Unified Process proposes an iterative method that is tested throughout the project, allowing as early as possible to find defects, fundamentally reduced the cost of modifying defects. Test is similar to a three-dimensional model, which is performed from reliability, functionality, application and system performance. The process describes several phases, plan, design, implementation, execution, and review of how to experience test life cycle from each dimension. In addition, when and how to introduce a strategy for test automation. It is very important to test automation using iteration, which allows regression testing for each new product at each iteration.
release
The goal of publishing workflow is to successfully generate versions and distribute software to end users. It includes a wide range of activities.
The product software package installation software that generates software itself provides users with help
In many cases, it also includes the following activities
Planning and carrying the existing software or data formal acceptance of the BETA test version
Although the release of workflow is mainly concentrated in the delivery phase, there is many activities that need to be prepared to create a post-release preparation for the early stages.
The publishing and environment in Rational Unified Process contains less content than other workflows.
Project management
Software Project Management is an art that balances the mutual conflict goals, managing risks, overcoming various restrictions to successfully issue software that meets investment users and users. Such less unworthy successful projects are undoubtedly a certificate of difficulty of this task.
Workflow is mainly concentrated in special aspects of iterative development process. This section Our goal is to provide the following things to make this task easier.
Manage the framework plan of the management project, equipped, executed, monitoring the practice of management risks
It is not a successful spiritan medicine, but it provides a way to manage the program to significantly improve software successfully release.
Configuration and change management
In this workflow, it is depicted to control a large number of outputs in a project consisting of multiple members. Control helps to avoid confusion, ensuring that the product has been conflicted with the following problems.
Synchronous Update - When two or more characters are working on the same product, the last modifier will destroy the former. Notification is not reached - When the problem in a product shared by several developers is resolved, modification is not notified to some developers multiple versions - many large projects have been developed. A version may be used by customers, another version is used to test, and the third version is in the development phase. If the problem is discovered in any of these versions, modifying needs to be prolonged in all versions, making confusion, resulting in expensive modifications and duplication, unless the change is well controlled and monitored.
The workflow provides a number of variants in the guidelines management evolution system to track the version of the given software creation. Implement on site-specific development strategies based on user-defined version rules construction programs or entire versions.
Workflow describes how to manage parallel development, distributed development, how to automate creation projects. This is especially important in the repetition process that needs frequent compilation of the link every day. If there is no strong automation, it is impossible, and it also expounds the reasons, time and personnel of the product, time, and personnel to maintain audit records.
Workflow has also covered changes in demand management, how to report shortcomings, how to manage in their life cycle, and how to use defects to track progress and development tendency.
surroundings
The purpose of environmental workflow is to provide software development organizations - Process and Tool - Software Development Team requires their support.
Workflow focuses on the activities of the process of configuring the process in the project environment, and focusing on the activities of supporting the development specifications of the project. Providing a gradual guidance manual, introducing how to implement the process in your organization.
The environmental workflow also includes a customization of guidelines, templates, and tool development toolboxes. The development toolbox is discussed in more detail in this paper.
The environmental workflow is not involved in specific aspects such as choice, acquisition, making it operational and maintenance development environment.
Rational Unified Process - Specific Products Rational Unified Process products include:
Knowledge Basis that can use Web search - provides guidelines for all key development activities on all key development activities. The knowledge foundation is further divided into: Extension guidelines for all members of all components of the software life period. It provides guidelines for guidance for both high-level thinking and guidance for daily dull activities. This guide is published as an HTML format to facilitate a stand-alone desktop access. Tool guidance covers guidance from the entire lifecycle tool. Similarly, it is released in HTML format. For details, see "Tool Integration". Examples of Rational Rose and templates provide a reference for information on how to organize Rational ROSE when following Rational Unified Process. The SODA template provides more than 10 SODA templates to assist software documentation. The Microsoft Word Template provides more than 30 templates to help workflow and all partial documentation of all lifeiod. Microsoft Project Plans Many project managers have discovered that it is difficult to make project plans to reflect iterative development methods. This template provides a good start based on Rational Unified Process. Development Kit describes how to customize and extend the Rational Unified Process to a specific requirement to adopt the method or project, while providing tools and templates to assist this job. Development Toolkin is set forth in this section. Addison-Wesley published, "Rational Unified Process A Introduction" in Philippe Kruchten. This book is 277 pages, which provides a good introduction and summary of the development process and knowledge foundation.
Knowledge basis browsing
Rational Unified Process allows you to browse any popular browsers such as: IE, Netscape Navigator. With Rational Unified Process, you only need a little mouse click to get the required information. The knowledge foundation contains many hypertext links, and various process elements are expressed by interactive patterns, which is easy to find relevant information. Strong search engine, index, "resource manager appearance" tree browsing makes it easy to use this process. The browsing button allows you to turn the page before and after reading.
Information is performed in several different views, allowing you to view information on roles, specific activities or workflows. For key project roles, provide a guidance process that is easy to learn.
Interactive images and navigable buttons make the find specific information more convenient
Development kit for customization process
Rational Unified Process is universal and complete, as described in its name. However, in some cases, the software development process needs to be modified, adjusted, and tailored to accommodate specific characteristics, constraints, and mechanisms. In particular, the process should not be blindly followed, forming many useless work, producing unwanted products. It should be as refining and can quickly present high quality software.
The development process includes a development kit that includes guidance how to customize the process to meet the specific needs of institutions or projects. The toolkit also includes a creation process, as well as derived and operational templates such as search engines, indexing, location maps, tree browsers, and the like. The development kit allows custom organizational structures to maintain the sensation of Rational Unified Process.
The higher the development process, the more difficult it is customized to the future process version. The development kit describes strategies, tools, and techniques for reducing customized transplantation.
Tool integration
Software engineering processes requires all activities of tools to support system life, especially in support for development, maintenance, and a variety of products - especially models. Iterative development processes propose special requirements for the toolset used, such as the integration of tools and two-way projects between model codes. Similarly, tools that support tracking requirements, document automation, and test automation, such as promoting regression testing. Rational Unified Process can be used with a wide range of tools, including Rational and other suppliers of products. Rational provides a number of tools that effectively support Rational Unified Process. A list of tools that support Rational Unified Process is provided below.
Rational Unified Process provides tool guidelines for most products. Tool guidelines are described in detail how to operate tools to implement a guide to the development process (ie, what kind of window, the information in the dialog and how to roam). Tool Guidelines Allows the actual operating tools that are independent of the tools to day-to-day work.
Rational Requisite? Pro - By making demand easier writing, communication, and modifying all development groups throughout the application development, you can update and track in real time. Rational ClearQuest? - Window-based and web demand change management products, the project team can track and manage all change activities in the development of life. RATIONAL ROSE? 98 - The world leading visual modeling tool for commercial process modeling, demand analysis, construction structure design. Rational Soda? - Tools for automated product documentation for the entire software development process, greatly reduces the time and cost of documentation work. Rational Purify? - C / C components and application developers use the run error check tool to help check the memory error. Rational Visual Quantify? - Advanced Performance Evaluation Tools used by C / C , VB, Java components, and application developers help assess performance bottlenecks. Rational Visual Purecoverage? - Automatic software test coverage tool allows developers to fully effectively test their applications. Rational TeamTest - Functional tests created, maintained, and executes, allowing full testing code and determining whether the software meets the desired needs and performance. Rational PerformanceStudio? - Review and expect easy-to-use, accurate and upgraded tools for Client / Server and Web system performance. Rational ClearCase? - Software configuration tools that dominate the market, providing project managers to track the evolution of each software development project.
Rational Unified Process's History Rational Unified Process has reached many years of maturity and reflects the collective experience of many people and companies. Let us briefly look at the history shown below:
Evolution history of the Rational Unified Process
From time to time, Rational Unified Process is the direct successor of Rational Objectory Process (Version 4). Rational Unified Process has merged data engineering, commercial modeling, project management, and configuration management areas, the latter as a result of constructed with Prue ATRIA. It is more closely integrated to the Rational Software Toolset. Rational Unified Process is a synthesis of "Rational Approach" and Objectory Process (Version 3), after the 1995 Rational Software Company is merged with Objectory AB. From its Objectory, inherit the process structure and the center concept of the USE CASE. From its Rational background, it is an iterative development and architecture system elaboration. The version also includes the Requisite, Inc Configuration Management section and the detailed test process of inheriting from SQA,? INC. Finally, the development process is the first in the unified modeling language (UML0.8). Objectory Process is created in 1987 in Ericsson experience in Ivar Jacobson. This process is called the product of his company Objectory AB. Due to the use of the USE Case concept and object-oriented approach, it quickly got the recognition of the software industry and integrated by many world-class companies. A simple version of Objectory Process as a textbook was published in 1992.
Rational Unified Process is a specific, detailed instance of a more general method, which is introduced in Ivar Jacobson, Grady Booch, and James Rumbaugh. "The Unified Software Development Process" is introduced.
Reference
