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.
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.
Analysis And Design Discipline
The goal of analysis and design is to show how the system will be realized in the implementation phase. The aim is 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 packages and 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 that 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. Tests are carried out along four 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. Change Request Management keeps track of the proposals for change.
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 followed.
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.
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
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 broken down into three main steps:
Prepare Environment For Project : Preparing the development environment for a project 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.
|