Throughout the software industry there are a lot of great ideas and knowledge available about how to effectively develop software. Nowadays, development teams need and have access to a wide range of information. Not only do they need to acquire detailed information about specific development technologies such as Java, Java EE, Eclipse, SOA technologies, .NET, as well as various development and tool environments, but they also need to figure out how to organize their work along modern development best practices such as agile, iterative, architecture-centric, risk- and quality-driven software
development.

Some problems development organizations face when they leave their developers to find such information for themselves
are:

• team members will not have centralized and easy access to the same body of information when they need it, i.e., different developers might rely on different sources and versions of the same information;
• it is difficult to combine and integrate content and development processes that are made available in their own proprietary format, as every book and publication presents method content and process using a different representation and presentation style;
• it is hard to define an organized and systematic development approach that is right-sized to their needs, i.e., addresses their specific culture, standardized practices, and compliance requirements.

The Software and Systems Process Engineering Meta-model (SPEM) is a process engineering meta-model as well as conceptual framework, which can provide the necessary concepts for modeling, documenting, presenting, managing, interchanging, and enacting development methods and processes. An implementation of this meta-model would be targeted at process engineers, project leads, project and program managers who are responsible for maintaining and implementing processes for their development organizations or individual projects.

[The figure above] presents a conceptual framework for the usage of a SPEM 2.0 implementation:

• To provide a standardized representation and managed libraries of reusable method content: Developers need to understand the methods and key practices of software development. They need to be familiar with the basic development tasks, such as how to elicit and manage requirements, how to do analysis and design, how to implement for a design or for a test case, how to test implementations against requirements, how to manage the project scope and change, and so on. They further need to understand the work products such tasks create as well as which skills are required. SPEM 2.0 aims to support development practitioners in setting-up a knowledge base of intellectual capital for software and systems development that would allow them to manage and deploy their content using a standardized format. Such content could be licensed, acquired, and, more importantly, their own homegrown content consisting of, for example, method definitions, whitepapers, guidelines, templates, principles, best practices, internal procedures and regulations, training material, and any other general descriptions of how to develop software. This knowledge base can be used for reference and education and forms the basis for developing processes (see the next bullet point).
• To support systematic development, management, and growth of development processes: Development teams need to define how to apply their development methods and best practices throughout a project lifecycle. In other words, they need to define or select a development process. For example, requirements management methods have to be applied in one fashion during the early phases of a project, where the focus is more on elicitation of stakeholder needs and requirements and scoping a vision. The same methods have to be performed in a different fashion during later phases, where the focus is on managing requirements updates and changes and performing impact analysis of these requirements changes. The same requirements methods might also be applied differently if the project develops a new system or maintains an existing system as well as depending on the teams and distribution of the teams. A development process model needs to support expressing these differences. Teams also need a clear understanding of how the different tasks within the methods relate to each other: for example, how the change management method impacts the requirements management method as well as the regression testing method through out the lifecycle. SPEM 2.0 supports the systematic creation of processes based on reusable method content. Lifecycle independent method content can be placed into a process for a specific development lifecycle. Such processes can be represented as workflows and/or breakdown structures. Within these process the reused method content can then be refined for its specific context. SPEM 2.0 also provides the conceptual foundation for process engineers and project managers for selecting, tailoring, and rapidly assembling processes for their concrete development projects. The vision for SPEM 2.0 is that vendors can sell with their SPEM 2.0 implementation catalogs of pre-defined processes for typical project situations that can be adapted to individual needs. Within these catalogs, the implementation could offer process building blocks or process patterns that represent references processes for specific disciplines, technologies, or development styles. These process patterns could form a toolkit for quickly assembling processes based on project specific needs.
• To support deployment of just the method content and process needed by defining configurations of processes and method content: No development project is exactly like another and the same development process is never executed twice. Reference frameworks for development processes such as CMMI define different levels of maturity for processes. Each level entails different characteristics for the process definition as well as enactment in an organization or project for each level. For example, CMMI defines a “managed process” as performed activities that can be recognized as implementations of development practices. Such a process has certain characteristics: it is planned and executed in accordance with policies; it employs skilled people, having adequate resources to produce controlled outputs; it involves relevant stakeholders; it is monitored, controlled, and reviewed; and it is evaluated for adherence to its process description. By contrast, a “defined process” is a managed process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines. A defined process has a maintained process description and contributes work products, measures, and other process-improvement information to the organizational process assets. The notions of Activity Use, Configurability, and Variability for development processes (as well as method content) in SPEM 2.0 exactly address the needs for defined processes. These concepts provide capabilities for reuse of processes or process patterns, for modeling variability (i.e., processes that comprise of configurable alternative parts) and for tailoring allowing users to define their own extensions, omissions, and variability points on reused standard processes. Hence, the SPEM usage scenario is that organizations can provide libraries of reusable process and method using the capabilities describes in the first two bullet points. Team leads can then select and tailor the method content and processes that they require. They can then describe these selections and customizations with a SPEM Method Configuration, which they can deploy to their teams, only providing the content they really need.
• To support the enactment of a process for development projects: A process definition only provides value if it impacts and steers development teams’ behavior. Processes as well as guiding method content need to be available in the context of daily work of project managers, technical leads, and developers. They therefore need to be deployed in formats that are ready for enactment with the process enactment systems of the team’s choice. Typical enactment systems are project and resource planning systems, work backlog tracking systems, and workflow engines. SPEM 2.0 provides process definition structures that allow process engineers to express how a process shall be enacted within these systems. For example, SPEM 2.0 process definition can include information that indicates that modeled work definitions shall be repeated several times in a project (modeling iterations) or that there could be multiple occurrences of work definitions that can be performed in parallel.

Although, the SPEM 2.0 meta-model has been designed around the support for this framework, many other usage scenarios could be realized as well. For example, Chapter 2 defines different compliance points and discusses different implementation scenarios that might realize a variation of the scenarios depicted in [the figure above].