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.


sdPP Element Description

Extreme Programming (XP) was proposed by Kent Beck in 1996. It is a type of agile software development process, and it encourages software development starting with the simplest solution. The extra functionalities are added later on, and the results are improved by constant refactorings. As such, refactoring is an essential technique in XP.

The main difference from other traditional methodologies is that it emphasizes adaptability instead of predictability. XP advocates believe that on the fly changes in requirements are natural, inevitable and even desirable in software development. They believe that being able to adapt to changing requirements at any point in the lifecycle of the project is a better and more realistic approach than trying to define all requirements at the beginning of the project and then make efforts to monitor changes in the requirements.

Extreme programming takes the best practices of software development methodologies according to the specific project needs and implement them dynamically during the software lifecycle.

The main grounds of XP are: communication, simplicity, feedback, respect and courage.

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.


sdPP Element Description
  • Iteration 0
    • Initiate project
  • Construction iterations
    • Select priority work items
    • Iteration
      • Daily stand-up meeting
      • Daily work
      • Independent testing
    • Iteration review
    • Retrospective
  • Release
    • Release system into production
  • Production
    • Operate and support system in production
  • Retirement
    • Remove system form production
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


sdPP Element Workflow

This is a small example of XP workflow diagrammed with the help of our tool.


Inner workflow for the activity "Iteration"


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


sdPP Element Product Flow

This is a small example of XP producflow diagrammed with the help of our tool.


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:

  • Planning: User-stories are necessary for analysis. They should be prioritized and each of them will have an incremental development.
  • Small releases: First versions will contain the minimum, most useful or necessary set of requirements for the global system.
  • Metaphorical system: Each project must have an associated metaphor providing easy criteria to name the following stages of the project.
  • Simple design: Because requirements change on a daily basis, or at least they should, simple designs are mandatory.
  • Continuous testing: Before implementing any new feature of the system, a corresponding test has to be defined.
  • Refactoring: When a new feature is introduced and it has much in common with previous ones, it is highly recommended to eliminate duplicate code; not worrying about the correctness of the new implementation because the tests will assert the correct functioning of the whole system.
  • Pair programming: Work in pairs, using just one single computer. This way, one person reviews the other’s code while it is being written.
  • Collective code ownership: Anyone can edit any module at any time, and no one has the property of any module.
  • Continuous Integration: All changes are entered into the system at least once a day.
  • Weeks of 40 hours of work: Developers should go home on time.
  • Customer on our place: There should always be a system user accessible by the team members.
  • Coding Standards: Everyone must use the same programming style criteria. As such, it wouldn´t be possible to determine who wrote a specific part of the implementation.

Not to Dos:

  • Duplicate code fragments.
  • Start a new iteration without customer approval.
  • The developers work in separate rooms.
  • No customer with the team.
  • XP is only iterative development + Minimum Documentation + Unit Testing.
  • Coding before writing unit tests.
  • The customer does not decide.
  • No acceptance tests at each iteration.
  • Static design.
  • Having just one single person from the client working with the team.
  • Pair with a partner for a long time.
  • Do not integrate the quality assurance team in the project.
  • Write design documentation after coding.
  • Little modeling.
  • Only use pair programming with junior programmers.
  • The observer cannot easily see the monitor.
  • Team members not knowing XP and its foundations.
  • Too long meetings and without clear objectives.
  • Not using a dedicated tester.
  • The client and the big boss are not aligned.
  • The customer who writes the acceptance tests is not the same one that as executes them.
  • Too long iterations.
  • No time boxed iterations.
  • Iteration not ending with a fully integrated baseline.
  • Each iteration ending with a delivery to the user.
  • Predictive planning.
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).


sdPP Element Requirements

  • It is necessary to have a system to help managing the methodology.
  • It is necessary to educate the staff to perform correct XP developments.
  • Staff must be able to work in groups because the development is done in pairs.
  • The team is used to quick developments.
  • Staff must be used to meet a schedule of 40 hours a week.
  • It is necessary to have a common room to hold meetings.
  • All developers should be in one room.
  • The room must have food (basically "snacks for positive reinforcement").
  • Each day begins with an opening meeting.
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.


sdPP Element Description
Reliable backup: NA Online Update: NA
Data communications: 5 Complex interface: 1
Distributed functions: NA Complex processing: 1
Perfomance: 4 Reusability: 3
Heavily used configuration: 3 Installation ease: NA
Online data entry: NA Multiple sites: 0
Operational ease: 4 Facilitate change: 5
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.


sdPP Element Risks

  • Programming pairs should not be split to produce more, as this would infringe a XP requirement.
  • If the team is not trained in XP, the project might fail.
  • The team must not be tempted with the possibility of working more than 40 hours work each week.
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.