Introduction

A good way to understand OpenUP is to think of it as targeted to teams that have the following objectives:

• Apply the minimally necessary process that brings value.
• Avoid being overloaded with unproductive formal work products.
• Use a process that can be tailored and extended for additional needs that may arise during the software development lifecycle.

In order to be applied to as many project environments as possible, OpenUP is a process that has the following characteristics:

• Minimal - only fundamental content is included
• Complete - it can be manifested as an entire process to build a system
• Extensible - it can be used as a foundation on which process content can be added or tailored as needed

Minimal

OpenUP is considered an agile, lightweight process that promotes software development best practices such as:

• iterative development
• team collaboration
• continuous integration and tests
• frequent deliveries of working software
• adaptation to changes, and so on.

Other factors also count when determining the size of process material, such as the number of method elements like roles, tasks, artifacts and guidance.

OpenUP provides descriptions of responsibilities, skills and competencies of the fundamental roles in a team. See the list of Roles for more details.

OpenUP provides the essential artifacts needed to capture and communicate decisions. Ultimately, the process is not governed by artifact creation. For example, thinking about design is more important than documenting the design; assessing and planning an iteration is about promoting team collaboration instead of creating plans that are written in stone. In addition, for each artifact, OpenUP suggests informal representations or provides informal templates as starting points for teams that do not need to create their own. The team decides what the most appropriate form to be applied is. See the list of Work Products organized by domains.

Tasks in OpenUP are clear and focused on results. Text is usually short and objective, describing how individuals should collaborate to achieve objectives. Steps are short descriptions of what to achieve, and point to external guidance on how to do it. See the list of Tasks organized by disciplines.

OpenUP recommends the least amount of process guidance a team should use in order to be successful. Teams may have different names or responsibilities for roles, may perform tasks in or have different representations for artifacts, but they still want to follow the principles and practices described in OpenUP to increase the chances of project success.

Complete

OpenUP is considered a complete process because it covers the essential disciplines in a software development lifecycle by guiding the team in the following high level activities:

• Customer needs and requirements are elicited and captured, with continuous customer involvement.
• A robust architecture for the system is evolved, addressing technical risks and promoting team organization.
• For each requirement, a technical solution is designed, implemented and tested, which conforms to the architectural decisions.
• The system is evaluated by tests that validate customer requirements.
• Defects and enhancements feed back into development.
• Work is prioritized, iterations are planned and assessed, and team members take on work to be done.

However, OpenUP assumes that the project team is not responsible for certain activities and decisions that are assigned to other areas of the organization, such as:

• Creation of the business case is dealt with by management who decides whether or not the project is worth investing in, what is the return on investment, and so on.
• Environment setup - some organizational issues may not be in the scope of the team, such as: installation, configuration and licensing of development tools and configuration management tools; development process customization and publishing, etc.
• Deployment and operation - addressed at an organizational rather than a team level.

Other areas of concern are also not present in OpenUP, because small teams do not need to deal with the formality or overhead of these areas. They include, but are not limited to:

• Advanced configuration management
• Advanced requirements management
• Program and portfolio management

Extensible

OpenUP can be adopted by projects as it is, out-of-the-box, because it's minimal and complete.

However, different projects may have different needs. Organizations may be interested in customizing some aspects of OpenUP to adapt it to their projects. These are some examples of possible customization:

• Add new or rename existing roles
• Add steps to existing tasks
• Create new guidelines on a given technique
• Remove a given content area
• Modify existing or add new templates to artifacts
• Modify or create a new process lifecycle
• Add or remove process content
• Add guidance on how to achieve compliance
• Add guidance specific to a technology being used
• Replace or augment one of the layers with new content (e.g. by changing or adding material to how management is performed)
• Etc.

OpenUP can be customized and extended by using the EPF Composer tool, which allows you to author, configure and publish methods. With EPF Composer, you can add, remove and change elements according to your team needs, then publish the content to serve as guidance for your team.

See more information about customization in Supporting Material: Resources for Customizing Methods.