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

Craig Larman is a Canadian software engineer who specializes in iterative development methodologies, Agile Software Development, Analysis and Object Oriented Design and UML modeling.


Craig Larman chooses iterative development compared to other alternatives such as waterfall development. No restrictions as to what methods can be used, as it provides a set of best practices that can be followed with any of them. Larman uses best practice methodologies such as Scrum, XP, RUP, and Evo in a method (Larman prefer to call it a methodology) object oriented.
Its iterative incremental use case allows full development of a software system based on an initial working prototype whose functionalities are spreading and culminating in the development of that system.


Type of methodology: Incremental and iterative.


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

The task called "Planning and Requirement Specification" has the following inner workflow:



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


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:

  • Agile Modeling.
  • Establish and reiterate the same vision about the project among all team members.
  • Product Sheets: Marketers and requirements promote the early creation of product data sheets containing future budgets, comparisons, etc... to help clarify the physical limit, vision and definition of high-level requirements.
  • Track requirements in iterations.
  • Involve customer and product requirements.
  • Make brainstorming and / or brainwriting.
  • The development should be done in a common room, so it is necessary airy room with room for all members of the development team.
  • Within that room desks should be close to encourage open communication.
  • It must have white boards where you can draw freehand diagrams and models.
  • It must have a digital camera to film it drawn on whiteboards.
  • You should have a computer with two projectors (for which you need a dual graphics card).
  • All project support tools (wikis, server, etc...) Should be ready before the first iteration.
  • It should give a priority to each risk.
  • Use developments centered architecture (beginning and focus on it).
  • Use developments based on use cases.
  • Do not lose sight of the end system or intermediate milestones.
  • Having several development cycles for each production version.
  • Encourage customer relations.
  • Encourage self-directed teams.
  • The ideal speed is one that can be maintained indefinitely.
  • Simplicity is important.

Not to Dos:

  • Be clear about the difference between cascade development and iterative development, and not try to superimpose both types of development.
  • During the iteration changes can not by stakeholders.
  • Do not "fix" what is not broken, ie if the code works, do not waste time trying to improve it.
  • The dates for completion of each iteration can not be changed, are fixed.
  • Do not excessively enhance the process, believe in him and his immutability.
  • Do not create an excessive amount of documentation
  • Do not dispose of prototypes.
  • Do not set the time-boxes too big or small.
  • Do not put little emphasis on feedback.
  • Do not allow the estimation is made by sources outside the project.
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

  • Customer satisfaction at all times.
  • Small incremental delivery.
  • The client is for the development team
  • There is no difference in the development team.
  • Those involved in the development must be motivated.
  • To enable development teams to make their own decisions.
  • Allow all equipment to get an overview of the project.
  • Estimated daily work.
  • Communication between members must be face to face.
  • The development should be as simple as possible.
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: 2
Distributed functions: 2 Complex processing: 2
Perfomance: 4 Reusability: 2
Heavily used configuration: NA Installation ease: NA
Online data entry: NA Multiple sites: 3
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

The disadvantage of this type of incremental processes proposed by Craig Larman is too high expectations of customers and management, due to early visibility of user interface prototypes created releases.

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.