|
The Rational Unified Process (RUP) is an iterative software development process created by the Rational Software Corporation, now a division of IBM. The RUP is an extensive refinement of the (generic) Unified Process. To meet Wikipedias quality standards, this article or section may require cleanup. ...
Software requirements analysis is the activity of eliciting, analyzing, and recording requirements for software systems. ...
Software architecture or software systems architecture can best be thought of as a representation of an engineered (or To Be Engineered) software system, and the process and discipline for effectively implementing the design(s) for such a system. ...
Computer programming (often simply programming or coding) is the craft of writing a set of commands or instructions that can later be compiled and/or interpreted and then inherently transformed to an executable that an electronic machine can execute or run. Programming requires mainly logic, but has elements of science...
Software testing is the process used to help identify the correctness, completeness, security and quality of developed computer software. ...
This article needs to be wikified. ...
Agile software development is a conceptual framework for undertaking software engineering projects. ...
The Cleanroom Software Engineering process is a software development process intended to produce software with a certifiable level of reliability. ...
Iterative and Incremental development is a software development process, as opposed to more traditional waterfall model. ...
// History Application Development refers to the developing of programming applications and differs from programming itself in that it has a higher level of responsibility, including for requirement capturing and testing. ...
The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. ...
The waterfall model is a software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. ...
Extreme Programming (XP) is a software engineering methodology, the most prominent of several agile software development methodologies. ...
Software Configuration Management (SCM) is part of configuration management (CM). ...
Software Documentation or Source Code Documentation is written text that accompanies computer software. ...
Project management is the discipline of organizing and managing resources in such a way that these resources deliver all the work required to complete a project within defined scope, time, and cost constraints. ...
Iteration is the repetition of a process, typically within a computer program. ...
To meet Wikipedias quality standards, this article or section may require cleanup. ...
Rational Software was an independent software development company until 2003, when it was bought by IBM. It sought to advance its customers practice of Modern Software Engineering through process, tools, and services. ...
now. ...
The IBM Rational Unified Process (RUP) is an iterative software development process created by the Rational Software Corporation, now a division of IBM. The RUP is not a single concrete prescriptive process, but rather an adaptable process framework. ...
The RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. In software development, a framework is a defined support structure in which another software project can be organized and developed. ...
The Rational Unified Process (RUP) is also a software process product, originally developed by Rational Software, and now available from IBM. The product includes a hyperlinked knowledge base with sample artifacts and detailed descriptions for many different types of activities. RUP is included in the IBM Rational Method Composer (RMC) product which allows customization of the process. Rational Software was an independent software development company until 2003, when it was bought by IBM. It sought to advance its customers practice of Modern Software Engineering through process, tools, and services. ...
now. ...
The term artifact in connection with software development is largely associated with specific development methods or processes e. ...
Background
History The roots of the Rational Process go back to the original spiral model of Barry Boehm. Ken Hartman, one of the key RUP contributors, collaborated with Boehm on research and writing. The Rational Approach was developed at Rational Software in the 1980s and 1990s. The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. ...
Barry W. Boehm is known for many contributions to software engineering. ...
Rational Software was an independent software development company until 2003, when it was bought by IBM. It sought to advance its customers practice of Modern Software Engineering through process, tools, and services. ...
In 1995 Rational Software acquired the Swedish Company Objectory AB. The Rational Unified Process was the result of the merger of the Rational Approach and the Objectory process developed by Objectory founder Ivar Jacobson. The first results of that merger was the Rational Objectory Process, designed to an Objectory-like process, but suitable to wean Objectory users to the Rational Rose tool. When that goal was accomplished, the name was changed. The first version of the Rational Unified Process, version 5.0, was released in 1998. The chief architect was Philippe Kruchten. Objectory Systems was a software company based in Sweden that was instrumental in the development of Object-oriented program design. ...
Objectory is an object-oriented methodology mostly created by Ivar Jacobson, who is also responsible for object-oriented software engineering. ...
Ivar Hjalmar Jacobson (born in Ystad, Sweden, on September 2, 1939) is a Swedish computer scientist. ...
Philippe Kruchten was formerly the Director of Process Development (RUP) at Rational Software. ...
Design objectives The creators and developers of the process focused on diagnosing the characteristics of different failed software projects; by doing so they tried to recognize the root causes of these failures. They also looked at the existing software engineering processes and their solutions for these symptoms.
A representative list of failure causes includes the following:
- Ad hoc requirements management
- Ambiguous and imprecise communication
- Brittle architecture (architecture that does not work properly under stress)
- Overwhelming complexity
- Undetected inconsistencies in requirements, designs, and implementations
- Insufficient testing
- Subjective assessment of project status
- Failure to attack risks
- Uncontrolled change propagation
- Insufficient automation
Project failure is caused by a combination of several symptoms, though each project fails in a unique way. The outcome of their study was a system of software best practices they named the Rational Unified Process. Ad hoc is a Latin phrase which means for this [purpose]. It generally signifies a solution that has been tailored to a specific purpose, such as a tailor-made suit, a handcrafted network protocol, and specific-purpose equation and things like that. ...
Automation (ancient Greek: = self dictated) or industrial automation or numerical control is the use of control systems (e. ...
Computer software (or simply software) refers to one or more computer programs and data held in the storage of a computer for some purpose. ...
The term best practice generally refers to the best possible way of doing something; it is commonly used in the fields of business management, software engineering, and medicine, and increasingly in government. ...
The Process was designed with the same techniques the team used to design software; it has an underlying object-oriented model, using Unified Modeling Language (UML). In software engineering, the Unified Modeling Language (UML) is a non-proprietary specification language for object modeling. ...
Principles and best practices RUP is based on a set of software development principles and best practices, for instance: - Develop software iteratively
- Manage requirements
- Use component based architecture
- Visually model software
- Verify software quality
- Control changes to software
Develop software iteratively Given 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 the project to be successively refined and addresses a project's highest risk items as the highest priority task. 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.
The RUP uses iterative and incremental development for the following reasons: Iterative and Incremental development is a software development process, as opposed to more traditional waterfall model. ...
- Integration is done step by step during the development process, limiting it to fewer elements.
- Integration is less complex, making it more cost effective.
- Parts are separately designed and/or implemented and can be easily identified for later reuse.
- Requirement changes are noted and can be accommodated.
- Risks are attacked early in development since each iteration gives the opportunity for more risks to be identified.
- Software architecture is improved by repeated scrutiny.
Using iterations, a project will have one overall phase plan, but multiple iteration plans. Involvement from stakeholders is often encouraged at each milestone. In this manner, milestones serve as a means to obtain stakeholder buy in while providing a constant measure against requirements and organizational readiness for the pending launch.
Manage requirements Requirements management in RUP is concerned with meeting the needs of end users by identifying and specifying what they need and identifying when those needs change. Its benefits include the following: Requirements management is the science and art of gathering and managing user, business, technical, and functional requirements within a product development project. ...
- The correct requirements generate the correct product; the customer's needs are met.
- Necessary features will be included, reducing post-development cost.
RUP suggests that the management of requirements has the following activities:
Analyze the problem is about agreeing on the problem and creating the measures that will prove its value to the organization.
Understand stakeholder needs is about sharing the problem and value with key stakeholders and finding out what their needs are surrounding the solution idea.
Define the system is about creating features from needs and outlining use cases, activities which show nicely the high-level requirements and the overall usage model of the system.
Manage the scope of the system is about modifying the scope of what you will deliver based on results so far and selecting the order in which to attack the use-case flows.
Refine the system definition is about detailing use-case flows with the stakeholders in order to create a detailed Software Requirements Specification (SRS) that can serve as the contract between your team and your client and that can drive design and test activities. ...
Manage changing requirements is about how to handle incoming requirement changes once the project has begun.
Use component-based architecture Component-based architecture creates a system that is easily extensible, intuitively understandable and promotes software reuse. A component often relates to a set of objects in object-oriented programming. In computer science, object-oriented programming is a computer programming paradigm. ...
Software architecture is increasing in importance as systems are becoming larger and more complex. RUP focuses on producing the basic architecture in early iterations. This architecture then becomes a prototype in the initial development cycle. The architecture evolves with each iteration to become the final system architecture. RUP also asserts design rules and constraints to capture architectural rules. By developing iteratively it is possible to gradually identify components which can then be developed, bought or reused. These components are often assembled within existing infrastructures such as CORBA and COM, or Java EE. Software architecture or software systems architecture can best be thought of as a representation of an engineered (or To Be Engineered) software system, and the process and discipline for effectively implementing the design(s) for such a system. ...
In computing, Common Object Request Broker Architecture (CORBA) is a standard for software componentry, created and controlled by the Object Management Group (OMG). ...
Component Object Model (COM) is a Microsoft platform for software componentry introduced by Microsoft in 1993. ...
Java 2 Platform, Enterprise Edition or Java EE (formerly also J2EE) is a programming platform — part of the Java platform — for developing and running distributed multi-tier architecture applications, based largely on modular components running on an application server. ...
Visually model software Abstracting your programming from its code and representing it using graphical building blocks is an effective way to get an overall picture of a solution. Using this representation, technical resources can determine how best to implement a given set of inter-related logics. It also builds an intermediary between the business process and actual code through information technology. A model in this context is a visualization and at the same time a simplification of a complex design. RUP specifies which models are necessary and why.
The Unified Modeling Language (UML) can be used for modeling Use-Cases, Class diagrams and other objects. RUP also discusses other ways to build models.
Verify software quality Quality assessment is the most common failing point of software projects, since it is often an afterthought and sometimes even handled by a different team. RUP assists in planning quality control and assessment by building it into the entire process and involving all members of a team. No worker is specifically assigned to quality; RUP assumed that each member of the team is responsible for quality during the entire process. The process focuses on meeting the expected level of quality and provides test workflows to measure this level. Quality Assessment includes evaluation, grading and measurement process to assess design, development, production, installation, servicing and documentation, includes the regulation of the quality of raw materials, assemblies, products and components. ...
Control changes to software In all software projects, change is inevitable. RUP defines methods to control, track and monitor changes. RUP also defines secure workspaces, guaranteeing a software engineer's system will not be affected by changes in another system. The concept ties in heavily with component based architectures.
Project lifecycle
 A typical project profile showing the relative sizes of the four phases The RUP lifecycle has been created by assembling the content elements (described below) into semi-ordered sequences. Consequently the RUP lifecycle is available as a work breakdown structure, which could be customized to address the specific needs of a project. The RUP lifecycle organizes the tasks into phases and iterations. Image File history File links UnifiedProcessProjectProfile20060708. ...
A project has four phases:
- Inception phase
- Elaboration phase
- Construction phase
- Transition phase
Inception phase In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated. After these are completed, the project is checked against the following criteria: A business Case is a part of the project mandate, or separate document referenced by the project mandate (depending on the scale of the project), produced before a project is initiated. ...
During the inception phase of a RUP project, the key stakeholders should establish criteria by which the project can be judged to have succeeded. ...
In software engineering and system engineering, a use case is a technique for capturing functional requirements of systems and systems-of-systems. ...
- Stakeholder concurrence on scope definition and cost/schedule estimates.
- Requirements understanding as evidenced by the fidelity of the primary use cases.
- Credibility of the cost/schedule estimates, priorities, risks, and development process.
- Depth and breadth of any architectural prototype that was developed.
- Actual expenditures versus planned expenditures.
If the project does not pass this milestone, called the Lifecycle Objective Milestone, it can either be cancelled or it can repeat this phase after being redesigned to better meet the criteria. A stakeholder was originally a person who holds money or other property while its owner is being determined. ...
A Spanish kilometre stone A milestone on the Boston Post Road in Harvard Square, Massachusetts, USA Slate milestone near Bangor, Wales A milestone or kilometre sign is one of a series of numbered markers placed along a road at regular intervals, typically at the side of the road or in...
Elaboration phase The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form. Wikipedia does not have an article with this exact name. ...
This phase must pass the Lifecycle Architecture Milestone by meeting the following criteria:
- A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete.
- A description of the software architecture in a software system development process.
- An executable architecture that realizes architecturally significant use cases.
- Business case and risk list which are revised.
- A development plan for the overall project.
If the project cannot pass this milestone, there is still time for it to be cancelled or redesigned. After leaving this phase, the project transitions into a high-risk operations where changes are much more difficult and detrimental when made.
Construction phase In this phase the main focus goes to the development of components and other features of the system being designed. This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments that produce demonstrable prototypes.
This phase produces the first external release of the software. Its conclusion is marked by the Initial Operational Capability Milestone.
Transition phase In the transition phase, the product has moved from the development organization to the end user. The activities of this phase include training of the end users and maintainers and beta testing of the system to validate it against the end users' expectations. The product is also checked against the quality level set in the Inception phase. If it does not meet this level, or the standards of the end users, the entire cycle in this phase begins again.
If all objectives are met, the Product Release Milestone is reached and the development cycle ends.
Disciplines and workflows
 The Rational Unified Process RUP is based on a set of building blocks, or content elements, describing what is to be produced, the necessary skills required and the step-by-step explanation describing how specific development goals are achieved. Image File history File links RationalUnifiedProcess. ...
The main building blocks, or content elements, are the following:
- Roles (who) – A Role defines a set of related skills, competencies, and responsibilities.
- Work Products (what) – A Work Product represents something resulting from a task, including all the documents and models produced while working through the process.
- Tasks (how) – A Task describes a unit of work assigned to a Role that provides a meaningful result.
Within each iteration, the tasks are categorized into nine Disciplines:
Engineering Disciplines:
- Business modeling discipline
- Requirements discipline
- Analysis and design discipline
- Implementation discipline
- Test discipline
- Deployment discipline
Supporting Disciplines: - Configuration and change management discipline
- Project management discipline
- Environment discipline
Business modeling discipline Organizations are becoming more dependent on IT systems, making it imperative that information system engineers know how the applications they are developing fit into the organization. Businesses invest in IT when they understand the competitive advantage and value added by the technology. Information Technology (IT)[1] is a broad subject concerned with the use of technology in managing and processing information, especially in large organizations. ...
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. They must also ensure a common understanding of the target organization between customers, end users and developers.
Business modeling explains how to describe a vision of the organization in which the system will be deployed and how to then use this vision as a basis to outline the process, roles and responsibilities.
Requirements discipline The goal of the Requirements is to describe what the system should do and allows the developers and the customer to agree on that description. To achieve this, analysts 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 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. In software engineering, a use case is a technique for capturing the potential requirements of a new system or software change. ...
Artifacts used in requirements:
- Use Case Model
- Use Cases
- Supplementary specifications
- Glossary
- Storyboards, as a basis for User-Interface Prototypes
These artifacts can be combined and packaged together to define a Software Requirements Specification (SRS).
Analysis and design discipline The goal of Analysis and Design is to show how the system will be realized in the implementation phase. You want to build a system that: - Performs—in a specific implementation environment—the tasks and functions specified in the use-case descriptions.
- Fulfills all its requirements.
- Is easy to change when functional requirements change.
Analysis and Design results in a design model and optionally 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 is structured and written.The design model consists of design classes structured into design packages and design subsystems with well-defined interfaces, representing what will become components in the implementation. It also contains descriptions of how objects of these design classes collaborate to perform use cases.
Implementation discipline The purposes of implementation are: - To define the organization of the code, in terms of implementation subsystems organized in layers.
- To implement classes and objects in terms of components (source files, binaries, executables, and others).
- To test the developed components as units.
- To integrate the results produced by individual implementers (or teams), into an executable system.
Systems are realized through implementation of components. The process describes how you reuse existing components, or implement new components with well defined responsibility, making the system easier to maintain, and increasing the possibilities to reuse
Test discipline The purposes of the Test discipline are: - To verify the interaction between objects.
- To verify the proper integration of all components of the software.
- To verify that all requirements have been correctly implemented.
- To identify and ensure defects are addressed prior to the deployment of the software
The Rational Unified Process proposes an iterative approach, which means that you test throughout the project. This allows you to find defects as early as possible, which radically reduces the cost of fixing the defect. Test are carried out along three quality dimensions reliability, functionality, application performance and system performance. For each of these quality dimensions, the process describes how you go through the test lifecycle of planning, design, implementation, execution and evaluation.
Deployment discipline The purpose of deployment is to successfully produce product releases, and deliver the software to its end users. It covers a wide range of activities including: - Producing external releases of the software
- Packaging the software
- Distributing the software
- Installing the software
- Providing help and assistance to users
Although deployment activities are mostly centered around the transition phase, many of the activities need to be included in earlier phases to prepare for deployment at the end of the construction phase.The Deployment and Environment workflows of the Rational Unified Process contain less detail than other workflows.
Configuration and Change management discipline The Change Management discipline in RUP deals with three specific areas: - Configuration management
- Change request management
- Status and measurement management
Configuration management Configuration management is responsible for the systematic structuring of the products. Artifacts such as documents and models need to be under version control and these changes must be visible. It also keeps track of dependencies between artifacts so all related articles are updated when changes are made.
Change request management During the system development process many artifacts with several versions exist. CRM keeps track of the proposals for change. Change management is the process of developing a planned approach to change in an organization. ...
Status and measurement management Change 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. These states and attributes are stored in database so useful reports about the progress of the project can be produced. Rational also has a product to maintain change requests called ClearQuest. This activity has procedures to be follow.
Project management discipline Project planning in the RUP occurs at two levels. There is a coarse-grained or Phase plan which describes the entire project, and a series of fine-grained or Iteration plans which describe the iterations.
However, this discipline of the Rational Unified Process (RUP) does not attempt to cover all aspects of project management. For example, it does not cover issues such as:
- Managing people: hiring, training, coaching
- Managing budget: defining, allocating, and so forth
- Managing contracts, with suppliers and customers
This discipline focuses mainly on the important aspects of an iterative development process: - Risk management
- Planning an iterative project, through the lifecycle and for a particular iteration
- Monitoring progress of an iterative project, metrics
Project management discipline contain a number of other Plans and Artifact the is used to control the project and monitring its performance such Plans are: - The Phase Plan (The Software Development Plan)
- The Iteration Plan
Phase plan Each project is treated as Phase this phase is controlled and measured by The Software Development Plan which is grouped from a subset of monitoring plans: - The Measurement Plan Defines the measurement goals, the associated metrics, and the primitive metrics to be collected in the project to monitor its progress.
- The Risk Management Plan details how to manage the risks associated with a project. It details the risk management tasks that will be carried out, assigned responsibilities, and any additional resources required for the risk management activity. On a smaller scale project, this plan may be embedded within the Software Development Plan.
- The Risk list A sorted list of known and open risks to the project, sorted in decreasing order of importance and associated with specific mitigation or contingency actions.
- The Problem Resolution Plan The Problem Resolution Plan describes the process used to report, analyze, and resolve problems that occur during the project.
- The Product Acceptance Plan The Product Acceptance Plan describes how the customer will evaluate the deliverable artifacts from a project to determine if they meet a predefined set of acceptance criteria. It details these acceptance criteria, and identifies the product acceptance tasks (including identification of the test cases that need to be developed) that will be carried out, and assigned responsibilities and required resources. On a smaller scale project, this plan may be embedded within the Software Development Plan.
Iteration plan The iteration plan is fine-grained plan with a time-sequenced set of activities and tasks, with assigned resources, containing task dependencies, for the iteration.
There are typically two iteration plans active at any point in time.
- The current iteration plan is used to track progress in the current iteration.
- The next iteration plan is used to plan the upcoming iteration. This plan is prepared toward the end of the current iteration.
Therefor there are often two such plans: one for the current iteration and one under construction for the next iteration.
To define the contents of an iteration you need:
- the project plan
- the current status of the project (on track, late, large number of problems, requirements creep, and so on.)
- a list of scenarios or use cases that must be completed by the end of the iteration
- a list of risks that must be addressed by the end of the iteration
- a list of changes that must be incorporated in the product (bug fixes, changes in requirements)
- a list of major classes or packages that must be completely implemented
These lists must be ranked. The objectives of an iteration should be aggressive so that when difficulties arise, items can be dropped from the iterations based on their ranks.
Therefore there is a set of supported Artifact that help in measuring and building each iteration plan
The Artifact The Artifact used are: - The Iteration Assessment captures the result of an iteration, the degree to which the evaluation criteria were met, lessons learned, and changes to be done.
- The project measurements is the project's active repository of metrics data. It contains the most current project, resources, process, and product measurements at the primitive and derived level.
- The periodic Status Assessment provides a mechanism for managing everyone's expectations throughout the project lifecycle to ensure that the expectations of all parties are synchronized and consistent.
- The work order The work order is the Project Manager's means of communicating what is to be done, and when, to the responsible staff. It becomes an internal contract between the Project Manager and those assigned responsibility for completion.
- The Issues List is a way to record and track problems, exceptions, anomalies, or other incomplete tasks requiring attention.
Environment discipline The environment discipline focuses on the activities necessary to configure the process for a project. It describes the activities required to develop the guidelines in support of a project. The purpose of the environment activities is to provide the software development organization with the software development environment-both processes and tools-that will support the development team.
The Environment discipline workflow is breaked down into three main steps:
Prepare Environment for Project Preparing the development environment for a means turning the underlying development process into an enactable project-specific development process. This involves :
- defining how the project is going to use the configured development process.
- developing a development case describing deviations of the underlying process.
- qualifying artifact selections with timing and formality requirements.
- preparing project-specific assets, like guidelines and templates, according to the development case.
- producing a list of candidate tools to use for development.
Prepare Environment for an Iteration The purpose of this workflow detail is to ensure that the project environment is ready for the upcoming iteration. This includes process and tools.
this work is focused mainly on:
- Complete the Development Case to get ready for the iteration.
- Prepare and, if necessary, customize tools to use within the iteration.
- Verify that the tools have been correctly configured and installed.
- Prepare a set of project-specific templates and guidelines to support the development of *project artifacts in the iteration.
- Make sure that all the changes made to the project environment are properly communicated to *the project members
Support Environment During an Iteration support the developers in their use of tools and process during an iteration.This includes installation of required software, ensuring that the hardware is functioning properly and that potential network issues are resolved without delays.
The IBM Rational Method Composer product The RUP process framework within IBM Rational Method Composer includes: - A process content library based on the best practices adopted in thousands of projects worldwide.
- Out-of-the-box delivery processes to provide the project manager with a quick starting point for planning and initiating a project. A delivery process will provide an initial project template, identify what milestones to have in the project, what work products to delivered by each milestone, and what resources are needed for each phase.
- Capability patterns that allow project managers to rapidly add or remove reusable chunks of processes addressing common problems. Since no two projects are alike, project managers need to rapidly modify the process to address the specific project needs.
The IBM Rational Method Composer (RMC) is a commercial product (built on top of Eclipse) for authoring, configuring, viewing, and publishing processes.
RMC has two main purposes:
- RMC is a content management system that provides a common management structure and look and feel for all process content. All content managed in RMC can be published to html and deployed to Web servers for distributed usage.
- RMC provides process engineers and project managers with the capability of selecting, tailoring, and rapidly assembling processes for their concrete development projects. RMC provides catalogs of pre-defined processes (like RUP) for typical project situations that can be adapted to individual needs. It also provides process building blocks called capability patterns that represent best development practices for specific disciplines, technologies, or development styles. These building blocks form a toolkit for quickly assembling processes based on project specific needs. Finally, the documented processes created with RMC can be published and deployed as Web sites. They can also be deployed as project plan templates for IBM Rational Portfolio Manager.
In additional to full RUP, RMC provides RUP plug-ins (extensions to the RUP content that can only be installed on top of RUP) for important areas such as service-oriented architectures (RUP for SOA), systems development (RUP SE), packaged application development (RUP for COTS), program and portfolio management, etc. New delivery processes are added frequently and are made available via the IBM developerWorks Website.
There is an open source version of IBM RMC created as part of the Eclipse Process Framework (EPF) project. The EPF tool contains full process authoring and publishing capabilities. The main difference between EPF and the Rational Method Composer tool is the lack of integrations with other IBM Rational tools such as Rational Portfolio Manager and Rational Software Architect as well as lack of a migration capability from Rational Process Workbench. EPF comes with OpenUP/Basic, a new agile process for small teams applying RUP principles and practices. The Eclipse Process Framework (EPF) is an open source project that is managed by the Eclipse Foundation. ...
The OpenUP/Basic is the most agile and lightweight form of OpenUP, an open source software development process developed as part of the Eclipse Process Framework (EPF, an open source process framework developed within the Eclipse open source organization). ...
Limitations If the users of RUP do not understand that RUP is a process framework, they may perceive it as a weighty and expensive process. RUP was not intended, not envisioned and not promoted to be used straight "out of the box". The IBM Rational Method Composer product has been created to address this limitation and help process engineers and project managers customize the RUP for their project needs. OpenUP/Basic, the lightweight and open source version of RUP, is another attempt to address this limitation. The OpenUP/Basic is the most agile and lightweight form of OpenUP, an open source software development process developed as part of the Eclipse Process Framework (EPF, an open source process framework developed within the Eclipse open source organization). ...
See also
Refinements and variations The Agile Unified Process (AUP) is a simplified version of the Rational Unified Process (RUP). ...
The Open Unified Process (OpenUP) is an open-source software development process, created as part of the Eclipse Process Framework (EPF) project. ...
The Eclipse Process Framework (EPF) is an open source project that is managed by the Eclipse Foundation. ...
The OpenUP/Basic is the most agile and lightweight form of OpenUP, an open source software development process developed as part of the Eclipse Process Framework (EPF, an open source process framework developed within the Eclipse open source organization). ...
The Enterprise Unified Process (EUP) is an extension of the Rational Unified Process. ...
The IBM Rational Unified Process (RUP) is an iterative software development process created by the Rational Software Corporation, now a division of IBM. The RUP is not a single concrete prescriptive process, but rather an adaptable process framework. ...
Alternative frameworks Alternate approaches within the field of software engineering include: The Cleanroom Software Engineering process is a software development process intended to produce software with a certifiable level of reliability. ...
The DSDM (Dynamic Systems Development Method) is a method that provides a framework for Rapid Application Development (RAD), supported by its continuous user involvement in an iterative development and incremental approach which is responsive to changing requirements, in order to develop a system that meets the business needs on time...
Extreme Programming (XP) is a software engineering methodology, the most prominent of several agile software development methodologies. ...
Scrum is an agile method for project management. ...
Systems engineering (or systems design engineering) as a field originated around the time of World War II. Large or highly complex engineering projects, such as the development of a new airliner or warship, are often decomposed into stages and managed throughout the entire life of the product or system. ...
Microsoft® Solutions Framework (MSF) is a deliberate and disciplined approach to technology projects based on a defined set of principles, models, disciplines, concepts, guidelines, and proven practices from Microsoft. ...
Software engineering Agile software development is a conceptual framework for undertaking software engineering projects. ...
Software Engineering (SE) is the discipline of designing, creating, and maintaining software by applying technologies and practices from computer science, project management, engineering, application domains and other fields. ...
To meet Wikipedias quality standards, this article or section may require cleanup. ...
Software component representations: above the representation used in UML, below the representation commonly used by Microsofts COM objects. ...
It has been suggested that this article or section be merged into Software development process. ...
Computer programming (often simply programming or coding) is the craft of writing a set of commands or instructions that can later be compiled and/or interpreted and then inherently transformed to an executable that an electronic machine can execute or run. Programming requires mainly logic, but has elements of science...
In engineering and manufacturing, quality control and quality engineering are involved in developing systems which ensure that products or services are designed and produced to meet or exceed customer requirements and expectations. ...
Extreme Programming (XP) is a software engineering methodology, the most prominent of several agile software development methodologies. ...
Agile Modeling is a supplement to other Agile Methodologies such as: Extreme Programming (XP) Scrum [1] Answers to Criticisms The principles and values of Agile Modeling practises help to mitigate the criticisms of Agile Software Development. ...
Books - 2006: Agility and Discipline Made Easy: Practices from OpenUP and RUP
Per Kroll, Bruce MacIsaac [1] - 2003: Rational Unified Process Made Easy, The: A Practitioner's Guide to the RUP
Per kroll [2] - 1999: The Unified Software Development Process
Ivar Jacobson, Grady Booch, and James Rumbaugh [3] Ivar Hjalmar Jacobson (born in Ystad, Sweden, on September 2, 1939) is a Swedish computer scientist. ...
Grady Booch is a software designer, a software methodologist and a Design Pattern enthusiast. ...
Dr. James Rumbaugh is one of the leading methologists of modern software, he joined Rational Software in 1994. ...
- 1998: The Rational Unified Process: An Introduction
Philippe Kruchten [4] 2003: 3rd ed: [5] Philippe Kruchten was formerly the Director of Process Development (RUP) at Rational Software. ...
External links |
Feeds |
Contact