Software Development is a tricky business. The standard approach is to treat software development like other engineering projects – with the expectation that engineering level predictive standards are applicable. However, software is different – much different. The differences are driven by:

· The environment of the software development project is ambiguous

· Project requirements typically change sixty (60) percent once the project vision has been created[1].

· Technical complexity leads to greater variance – projects often have to be pioneers by implementing a technical solution for the first time.

· Software development is a people intensive process – governed by random and unpredictable events and human behavior

· Ambiguity of requirements translates to increased project risk. To operate effectively within the environment of “squishy” requirements, iterations are often performed in an attempt to mitigate risk, do what can be done, and get early feedback from the customer. Requirements generate requirements – thus early iterations will likely generate additional project requirements as the customer continues to finalize the definition of what they want.

The default assumption is that a stepwise sequenced set of events occurring in a waterfall fashion will lead to project success for any given software project. Business owners, product salesman, and project managers with experience in other disciplines that lend themselves to well known, stable, and predictable environments will inevitably want to apply the techniques that are in their comfort zone when working on a software project. The methodology applied to other project domains outside of software is typically a stepwise sequenced (waterfall) approach. The application of a waterfall methodology often (due the conditions above) leaves the software project manager, project owner, and development team angry, frustrated, and often delivering late or not at all. Over thirty (30) percent of software projects are cancelled before delivery. Eighty six percent of software projects fail to deliver, deliver late, or exceed their projected budget. Sixty five (65) percent of “very large” information technology (IT) projects are cancelled prior to delivery[2].

What’s it all about

One can dramatically improve these dismal statistics by selecting a methodology that is compatible with their project. Even then, further efficiencies can be gained by further tailoring the selected methodology to the specifics of the project. This white paper describes a system and method for selecting a compatible methodology for your project. This document is a white paper version of a patent titled “System and Method for Software Methodology Evaluation and Selection”. We begin by defining something called a Project Context. Taking a Copernican view, the project context is placed in the center of the universe for all relevant software project discussions. An OO approach to describing a project is taken. A project context is made up of multiple components including People, Process, and Technology (Figure 1). Each component has multiple attributes. Component attribute values can be assigned by the key stakeholders, project manager, team members, or via an outside assessment service.

Creating and defining a methodology model was the second critical element of the underlying patent. A methodology model not only has a data element for each attribute of a project context, but also defines shadow minimum and maximum compatibility range data elements for each project context attribute. A methodology model may also have some elements unique to itself, but is guaranteed to have a common set of attributes and the following methodology model items for each project context attribute: methodology model attribute; minimum compatibility range; maximum compatibility range. Establishing minimum and maximum values within the methodology model allows concepts like simulation, statistics, and statistical forecasting to be useful. The concept of using software project context simulation along with the techniques of mathematical statistics, regression analysis, and statistical forecasting was the third critical element of the underlying patent.

Now that a project context has been defined, rule evaluation can be performed on the attribute values. Rules and rule-sets can be defined for the various component and project attributes. For example:

· Project size > 10

· Number of tiers > 3

· Product build duration > 2

The concept of project rules can be taken further. Now that attributes and rules exist, a scoring mechanism can be created. The proposition that a scoring interface exists for each methodology was the fourth critical element of the patent. Each methodology model file can be scored against the project context. Rules capture a relationship between one or more project or methodology data elements and a given value(s). A rule-set contains two or more rules. Rules and rule-sets are given nicknames. Rules can be written against data in the project context, and the methodology model (attribute, min value, max value).

Example rules utilizing a methodology model are:

· Project size > methodology model project size compatible minimum

· Number of tiers < methodology model number of tiers compatible maximum

· Number of time zones > methodology model number of compatible time zones.

Later, we shall see that rules can also be written against something called the “methodology compatibility matrix”, but we reserve that for the advanced topics section.

The concept and creation of a methodology compatibility matrix was the fifth critical element of the patent. To determine the most appropriate methodology, we score the project against methodology after methodology (model after model) to find the best (most compatible) score. If the project attribute value is within the minimum to maximum attribute values (compatibility range) specified for that methodology, points are awarded. If the project attribute value is outside the compatibility range, points are not awarded and/or are deducted. The methodology file with the greatest number of points wins – and is most compatible for that given project.

Extending rules into the realm of patterns and defining the existence of a methodology pattern framework for a software development project context was the sixth critical element of the underlying patent. Working from the rich set of data provided by the project context attributes, methodology model data elements, and compatibility matrix cell values, the rule and rule-sets that provide predictive behavior are actually methodology patterns. In addition to methodology patterns, because two of the primary components of the project context are people and process, patterns for team composition and methodology selection also emerge. A separate white paper, title “Software Development Patterns” is being published as a complementary white paper. “Software Development Patterns” shows how patterns are not just for J2EE or the technology world but can be equally applicable and useful to the business world. The specification and definition of a re-usable rule and pattern-mining framework (useful for any subject matter) is the seventh critical element of the underlying patent. The framework consists of defining a context object for the problem at hand, modeling the context, identifying rules, defining a compatibility matrix (if exists), and mining those rules for subsequent Patterns. Context analysis driven patterns on methodology, team composition, leadership, organizational behavior, human behavior, and marketing are all possible – the area of business is particularly ripe for context definition, modeling, rule definition, and pattern mining.

Applying the concepts, value to the reader

The concepts in this white paper can provide effective guidance, information, and solutions when used in the following situations:

· Software project bidding time. Before bidding on a fixed price project, model your project and assign attribute values to your project context instance. Score your proposed project model to determine the “best fit” methodology and create a more accurate and profitable bid. Simulate your project by assigning your context different attribute values and re-scoring to determine key people, process, or technology choice transition points that drive the methodology selection or subsequent list of “fits” / “misfits” best practice recommendations.

· Providing a Methodology assessment service. The service consists of one or more resources interviewing the project team members, stakeholders, and project review board members and assigning the attribute values to the project context being assessed. The skilled methodology assessment team assigns values to the project context data model being studied. From there, a manual or automated scoring process takes place to determine if the project is using a compatible methodology. A list of best practice recommendations (fit / misfit output from the methodology selection process) can then be presented to the project owners, participants, and project Steering Committee. The fit / misfit data captures all “fit” and “misfit” data during the scoring process of all methodologies. Additionally, a set of fit / misfit data is presented between the chosen best methodology and the project context being studies. Even though a best or most compatible methodology was chosen, some attribute values may still have anomalies. Knowing those anomalies in advance would be extremely valuable to the project team to further tweak the methodology and put in place risk mitigation plans.

· Assessing a current project based on:

o Best fit and/or what if analysis. The project manager can ask “what if” questions (simulations) to determine if a new attribute value will change the recommended methodology or generate new incompatibility warnings. For example, a project owner and manager have adopted extreme programming on a project with current funding of $2.8 million per year. The CIO calls the project owner and informs her that the project funding is increasing 60%, to $4.15 million. With an assumed project growth of 10 people, the project team could reassess their new Project Context to see if there is a different recommended methodology and if any new or changed fit / misfit best practice patterns / anti-patterns appear.

o The rules and rule-sets within the solution represent a built in library of software development and methodology best practices. During the scoring process, a list of attribute fits / misfits by methodology can be compiled for output. Thus, even for the recommended methodology, a list of special items to pay attention to (warnings) is available.

· Building successful software project teams. Software is a people intensive process. By examining the attributes defined in the People component of the Project Context, teams can be built that have built in risk mitigation strategies to many of the known causes of software project failures. By creating a focus on the People involved and aligning the software project with a compatible methodology, the chances for project success jump dramatically via built in risk mitigation, using a compatible methodology, and having the fit / misfits (patterns, anti-patterns) of the selected methodology (and others) explicitly identified to enable risk mitigation and team compensation strategies from day one.

While many of the concepts within this white paper are not limited to software development (in particular the re-usable pattern mining framework), we have chosen to specifically focus on that domain within the document.

Software Methodology

A software methodology is a social construction that includes the roles, skills, learning, activities, techniques, deliverables, standards, habits, and culture of an organization as it develops software. Software methodologies can fall across a range from lightweight to heavyweight. Software methodologies include, but are not limited to, SunTone Architecture Methodology, Unified Process, Rational Unified Process, Enterprise Unified Process, RUP-Lite, eXtreme Programming, Waterfall, Feature Driven Development ( FDD ) Process, DSDM, Personal Software Process, Team Software Process, Object Oriented Software Process, OPEN, and SCRUM.

One software methodology does not fit all software development circumstances just as one glove does not fit all hands. For software developers, process/project managers, and business stakeholders, it is desirable to know how to choose the best-fit methodology for a project. By tailoring and selecting a best-fit methodology, one can enhance the productivity of software teams, as well as improve upon the dismal industry statistics regarding software project failures[3].

Context, Context, who has the context

Context. It seems almost everything in the Java world has a context these days. Servlet, EJB, JNDI, Applet, SOAP, Graphics, Security, Page, Initial, and Event – they all have Context objects defined for them somewhere in the J2EE platform or Apache add-on services. So why not Project?

What is a Context?

Freedictionary.com defines “context” as

· The part or parts of something written or printed, as of Scripture, which precede or follow a text or quoted sentence, or are so intimately associated with it as to throw light upon its meaning.

That last part is interesting – “throw light” – keep that in mind as we discuss context simulation and regression analysis.

Die.net has the following definition:

· That which surrounds, and gives meaning to, something else.

“Surrounds, and gives meaning to” is interesting. Keep that in mind as we discuss an object-oriented approach to context definition. Surrounding almost sounds like a wrapper object – composition certainly comes to mind.

Earchitecture.org has the following definition:

· That which surrounds, and g