What is ProcessExperience.Org?
ProcessExperience.Org is a public knowledge base that shares the experiences of practitioners in using different software development methodologies. This portal introduces an Evidence-Based Repository of Method Fragments , in which For every method fragment (piece of a software development method), the Objectives that it aims to contribute , as well as the Requisites that are needed for its successful enactment, have been collected. As a distinguishing characteristic, this repository is evidence-based, as it provides contextual evidences from empirical studies, which explain situations in which a particular objective or requisite of a method fragment had been met or not.

What are the different parts of this portal?

  • Main Repository: The main repository is composed of a set of method fragments (e.g. Pair Programming) that have been introduced by different methodologies (e.g. XP). For each method fragment the main repository provides two tables: (1) Table of Objectives, which lists the objectives that the method fragment can contribute to them and (2) Table of Requisites, which lists the requisites that are needed for its successful enactment in an organization. For every objective/requisite that has been mentioned for a method fragment the repository provides evidence(s) from published empirical studies which have examined and reported the relation of the method fragment and the objective/requisite. You can lick here to access the main repository.

  • Method Objectives: This table lists all of the objectives that different method fragments may contribute to them. These objectives have been extracted from reviewing a large number of empirical studies that has tested various method fragments in different situations. For every objective you can see the method fragments that may contribute to it by clicking the "Related Fragments" link in front of the name of objective. In this table method objectives have been categorized in two classes, major and minor, where a major objective groups a collection of relevant minor objectives, or in other words, minor objectives are sub-objectives of major ones. For instance, "Improved Collaboration" is a major objective, grouping minor objectives such as "Closer collaboration of customer and development team", "Shorter feedback cycle from customer to development team", etc. You can click here to access the table of method objectives.

  • Method Requisites: This table lists all of the requisites that we have so far identified for different method fragments. Like method objectives, their requisites have been also extracted by reviewing published empirical studies, which have reported the need for certain conditions in order to successfully implement a method fragment in an organization. Method requisites are also categorized into major and minor requisites, where each major requisite is decomposed into a number of minor requisites. You can click here to access the table of method requisites.

  • Studies: This table lists all of the empirical studies that have been so far reviewed, for extracting method objectives/requisites, and populating the repository. You can click here to access the table of studies.


How have we collected the knowledge of this repository?
The knowledge of this repository has been gathered through Systematic Review of empirical studies on different methodologies, in particular the agile methods. i.e. the objectives and requisites of each method fragment have been synthesized by reviewing results from experiments or reported experiences, not from the motivational description of an method. In addition, this repository offers a visualization of fragments' data, using a goal-oriented notation. For further information about the structure of this repository and its applications, please view our publications page.

How to read the tables of this repository?

  • Table of Objectives of each Method Fragment: As mentioned before, for each method fragment this table shows the objectives that can be contributed by the method fragment. This table is composed of five columns:

    • Major Objective - Name of the major objective that the method fragment contribute to.
    • Minor Objective - Name of the minor objective that the method fragment contribute to.
    • Contribution Value - The kind of contribution that the method fragment makes to the minor/major. objective (++: Strongly Positive, +:Positive, -:Negative, --: Strongly Negative). Positive contributions imply the fact that the enactment of method fragment (under the specified situation) can help the achievement of major/minor objective, and negative imply the fact that the enactment of method fragment (under the specified situation) can causes the denial of major/minor objective,

    • Study - The reference to study (or studies) which reported the contribution(s) of method fragment to this objective.
    • Situation - short description of the project/organization situation, under which the contribution has been reported.

    For example the following row of the objective table of Pair Programming (PP) should be read as: As reported in studies "[25] Pikkarainen2008 and [30] O'Daniel2008", the use of PP in situation of "Pairing Professional Developers, or developers with similar expertise", can cause Strong Negative impact to the achievement (almost denial) of the minor objective "Increased productivity" and its major objective "Improved Effectiveness (performance)".

    Major Objective Minor Objective Contribution Value Study Situation
    Improved Effectiveness (performance) Increased productivity -- [25] Pikkarainen2008, [30] O'Daniel2008 Pairing Professional Developers, or developers with similar expertise
  • Table of Requisites of each Method Fragment: As mentioned before, for each method fragment this table shows the needed requisites that are required for its successful enactment in an organization. This table is composed of five columns:

    • Major Requisite - Name of the major requisite that this method fragment depends to.
    • Minor Requisite - Name of the minor requisite that this method fragment depends to.
    • Requisite Satisfaction Value - To what extent this requisite was satisfied in the situations of the empirical study which had reported it. Satisfaction degrees can take one of the following values (S - Satisfied, PS - Partially Satisfied, U - Undefined, D - Denied, PD - Partly Denied)

    • Study - The reference to study (or studies) which reported the need(s) of method fragment to this requisite.
    • Situation - short description of the project/organization situation, under which the requisite has been reported.
  • For example the following row of the requisite table of Pair Programming (PP) should be read as: As reported in study "[15] Chong2007", one of the requisites of PP is the "Equal engagement of both programmers". This requisite can be considered as a sub-requisite of "Collaboration be Good" (which a needed condition for the successful enactment of PP in an organization). The organization in which the empirical study had been performed could satisfy this requisite. The distinguishing characteristic of this study was "Pairing programmers with equal expertise".

    Major Requisite Minor Requisite Requisite Satisfaction Value Study Situation
    Collaboration be Good Equal engagement of both programmers S [15] Chong2007 Pairing programmers with equal expertise


How to read the graphical models of this repository?

Graphical models of a method fragment can be explained as to be composed of three layers: In the middle of each model, the method fragment is represented - At the top layer, the objectives of method fragment (complete list of objectives, or those which are related to a certain major objective) are visualized - and the bottom layer the requisites of method fragment are represented.

For example, this model shows a sample visualization of an agile method fragment. It depicts some of the objectives to which pair programming contributes. For instance, it shows that pair programming makes a positive (+) contribution to the objective "Better Time to Market". This model also shows the dependency of the AMF pair programming on some of its requisites, e.g., "Effective Collaboration of Pairs".