This website uses cookies to manage authentication, navigation, and other functions. By using our website, you agree that we can place these types of cookies on your device.

View e-Privacy Directive Documents

You have declined cookies. This decision can be reversed.

You have allowed cookies to be placed on your computer. This decision can be reversed.

Description

sdPP Element Description

Rational Unified Process is a software development process that together with the UML are the most widely used standard methodology for analysis, implementation and documentation of object-oriented systems.
It is based on three main pillars:

  • Use case driven Process: In RUP use cases are not only a tool for specifying system requirements. They also guide the design, implementation and testing. Are an integrator and a working guide, establishing traceability between artifacts generated throughout the project phases.
  • Process centered around the architecture: The architecture involves the most significant static and dynamic aspects of the system, is related to decisions that indicate how it should be built the system and helps to determine in what order.
  • Iterative and Incremental process: the strategy proposed in RUP is to have an iterative and incremental process where work is divided into smaller parts or mini projects. Allowing that the balance between use cases and architecture is achieved during each mini project and throughout the development process. Each mini project can be seen as an iteration (a more or less complete tour along all critical workflows) which produces an increase in the product.

The structure of the process is divided into five phases, which in turn are subdivided into iterations as shown in the following graph:

In each of the phases are carried out a number of activities, generating certain products or artifacts. These phases are described in more detail below:

  • Start: It defines the business model and the project scope. The most important use cases are designed, and ultimately you get an overview of the system.
  • Preparation: We analyze the problem domain, and the architecture is defined.
  • Construction: Held the system implementation.
  • Transition: The details are finalized. This includes complete documentation, training end users, and overall adjustment-related tasks, configuration, installation, and ease of use of the product.
In the sdPP Model the description is a textual field that provides a short explanation of its use and application, as well as the methodology, reference framework or best practices the sdPP came from.

WBS

sdPP Element Description

In the sdPP Model a Work Breakdown Structure (WBS) is used to organize the methodology activities. It is an organizational view of the activities proposed by the sdPP that helps the project manager understand the hierarchy between the activities

Workflow

sdPP Element Workflow

Business Modeling

Requirements

Analysis and Design

Implementation

Test

Deployment

Project Management

Environment


Configuration and Change Management

The workflow, in the sdPP model, indicate the recommended sequence to perform the activities described in the WBS. The UML activity diagram was adopted to define the workflow between the activities. The workflow guides the project manager through the activities indicating the order in which the activities should be carried out

Productflow

sdPP Element Product Flow

Requirements

Analysis and Design

Implementation

Test

Deployment

Project Management

Configuration and Change Management

The sdPP model uses the "productflow" field, for indicating how the products flow between activities. Typically an activity has a set of input products required to execute it and a set of output products that are the result of the activity execution. These products flow between the activities following the workflow.

To Dos

sdPP Element Description

To Dos:

  • Create at least two artifacts: Vision and risk list.
  • Organize iterations and milestones in accordance with the objectives of the beginning stages, design, construction and delivery.
  • Use iterations fixed in time from 2 to 6 weeks.
  • Program asap when known in detail only some of the requirements.
  • Refine the requirements from the feedback from users rather than large and detailed analysis.
  • Schedule first high-risk items and great value.
  • Achieve soon cohesive architecture.
  • Reuse existing components.
  • Continuously check the quality.
  • fully test the software on each iteration - unit, integration and performance.
  • Encourage continuous integration.
  • Perform visual modeling before programming, but in each iteration.
  • Using whiteboards or flip charts.
  • Fit models in a CASE tool.
  • reverse engineer the code developed.
  • Find, organize and follow the requirements.
  • Version control, change requests and establishing baselines at the end of each iteration.
  • Attack risks early and continuously.
  • Deliver value to the customer early and often
  • Focus on developing executable software from the first iterations.
  • Accommodate change soon.
  • Achieve executable architecture early.
  • Preference for component-based architectures using reused and reusable elements.
  • Work together as a team.
  • Quality is a way of life, not an alternative.

Not to Dos:

  • Iterations too long.
  • Iterations are not limited in time.
  • Iterations that do not end in a baseline integrated and tested.
  • Process complex project with many products.
  • Document system architecture completed in the development phase.
  • Describe the phases as the waterfall lifecycle.
  • suggest iterations over 6 weeks.
  • Propose a beginning phase that lasts many weeks of strong planning and analysis.
  • Encourage the creation of many products rather than reduce as much as possible.
  • Develop throwaway prototypes during the development phase.
In the sdPP model, a set of “to-dos” is given with recommendations based on the best practices and lessons learned. This “to-dos” list tries to establish the tacit knowledge based on experience about the methodologies, reference frameworks and best practices. A “to-do” is neither an activity nor a part of the workflow (i.e. “work in pairs” cannot be an activity).

Requirements

sdPP Element Requirements

  • RUP roles divided into five groups: Analysts, Developers, Managers, Specialists and Other Tests.
  • The duration of one iteration may vary between 2 weeks and 6 months.
  • The duration of the entire project should not go beyond 54 months.
The sdPP model defines a set of requirements that the project manager should be able to satisfy in order to apply the solution given by the pattern. These requirements have nothing in common with software requirements; they define the preconditions to be met in order to apply the solution proposed by sdPP.

Metadatas

sdPP Element Description
Reliable backup: NA Online Update: NA
Data communications: NA Complex interface: NA
Distributed functions: 2 Complex processing: 1
Perfomance: 1 Reusability: 1
Heavily used configuration: NA Installation ease: 0,5
Online data entry: NA Multiple sites: NA
Operational ease: NA Facilitate change: NA
The sdPP model classify the models with a set of metadatas. We have defined fourteen quantitative numeric fields with values from 0 to 5. Those fourteen fields describe what kind of software development projects sdPP is appropriate for.

Risks

sdPP Element Risks

  • Team members have to be experts in their field to develop software under this methodology.
  • The development process is too complex and disorganized.
  • In art projects using new technologies, component reuse is not possible. Thus saving time that could have been done, it will be impossible to meet.
  • Integration across the software development process in theory sounds great. But in practice in major development projects with multiple streams, only serve to increase confusion and cause more problems during the testing stages.
The sdPP model defines a set of risks the project manager would assume if the solution were applied. These risks warn the project manager about possible problems in the project execution. The project manager must understand these risks to try and avoid them.
Copyright © 2017 Diego Martín. All Rights Reserved.