Every new technology introduces new dimensions and challenges that must be considered when building software. Modern software teams are multidisciplinary and often need to include other profiles beyond developers and software engineers, such as data scientists, psychologists and AI experts.

These new profiles must be coordinated with the more “traditional” profiles. And may require more explicit guidelines to be able to integrate within software engineering processes in place at the company.  As such, enterprises need to revise, clarify and adapt their software engineering best practices and follow a clear process to manage the lifecycle of a product. In our opinion, this is going to revive the interest in software process modeling (and therefore on software process modeling languages), especially focused on new types of software, such as smart software.

Benefits of process modeling

Analysts, architects, engineers and other stakeholders engaged on a software development project often face typical challenges and flaws in managing and communicating knowledge and information about their internal and external processes that usually drive confusion and misalignment on expectations and goals.

Practices for both traditional and lean & agile software and systems development, spanning from business problem statement and requirements definition through acceptance testing, integration, deployment and operations, are well-known and spread across the industry due to their significant benefits. Standards define the activities, tasks, milestones, work products and roles & skills required to start, execute and successfully complete a development process in an organization given a specific situation, problem, goal and culture.

A fully-documented process helps teams to adopt and follow engineering best practices and is critical to complying with regulatory standards such as ISO 26262, SPICE, and CMMi. A framework that includes those processes provides full visibility and traceability about how the work is structured and required to be executed within an organization and its context, along with the responsibilities of their participants and the standards & knowledge it is based on. Those frameworks act as guidelines for configuration and execution, and must include models and metrics for monitoring and continuous improvement.

The new momentum

Machine Learning, the Internet of Things, Behavioral Software, Cyber-Physical Systems… New technologies and techniques have become rapidly in the last years a key core element of several software products. Traditionally, the first versions of those components have been developed by people from an area other than software engineering –like psychology, mathematics and statistics– and therefore are not used to follow engineering principles and best practices to build a modern application ready for mass consumption.

Nowadays, building competitive software requires a joint effort of people from different backgrounds. New technologies introduce new dimensions and challenges to be addressed when building software. Enterprises need to apply and adapt (software) engineering best practices and follow an end-to-end method to manage the development, deployment, monitoring and operating of hybrid systems at scale, by streamlining activities, and fostering knowledge sharing and collaboration across diverse skills. Their ultimate goal should be to increase the predictability, productivity and business impact of their teams. The lack of a process is a ballast for any modern software team configuration.

Note that this is a clear contrast from the agile trend, where “formal” process modeling was seen as least important. We believe it is now coming back as the needs for complex interdisciplinary software requires it.

A standard language for modeling software processes

The Software Process Engineering Metamodel Specification (SPEM) is an OMG’s standard used to describe software development processes or a family of related software development processes.

The elements of SPEM can be categorized into method contents or processes. Method content are the roles defining development skills and responsibilities, tasks that those roles perform, and artifacts or work products that are the inputs and outputs of the tasks. The elements of a given method content are then assets to be combined and included into any process. A development process is a sequence of tasks performed by roles and makes explicit how work products are created and evolve over time.

As the specification states:

“The scope of SPEM is purposely limited to the minimal elements necessary to define any software and systems development process, without adding specific features for particular development domains or disciplines. (…) SPEM 2.0 does not aim to be a generic process modeling language, nor does it even provide its own behavior modeling concepts. (…) SPEM 2.0 focuses on providing the additional information structures that you need for processes modeled with UML 2.0 Activities or BPMN/BPDM to describe an actual development process.”

Such an approach makes SPEM an extremely flexible metamodel for process engineers to model their company-specific processes, either by following and adopting a standard framework to their concrete needs and purposes, or by documenting their own processes from scratch.

Due to its “complementary” nature to UML 2.0 Activities or BPMN/BPDM specifications, SPEM has been adopted in a very scattered way by the different tool providers and other organizations. Thus, its aim and industry adoption is not quite clear: shall SPEM be used to adopt a model-driven engineering approach for process analysis and execution or it is yet another language limited to document specifications but not easing an actual process enactment? Does it cover an actual gap or could we continue using other specifications which, combined, provide the needed output?

Nevertheless, since the publication of SPEM 2.0 specification in 2008, most of the popular software modeling tools added its artifacts to their toolboxes and provided users with the ability to define processes following this standard. Let’s take a look at them.

Tools that support SPEM

While SPEM is the standard language for process modeling (with the caveats mentioned in the previous section), tool support for actually using it in practice is rather limited. Let’s see what are the available options.

Eclipse Process Framework Composer

The Eclipse Process Framework Composer is the tool and conceptual framework provided by the Eclipse group for authoring, tailoring and deploying development process frameworks. Its latest version is the 1.5.2 and was released back in 2018. Its first version supported their own specification language –named UMA– which was based on SPEM 1.1 and included some artifacts and extensions that were added to SPEM 2.0 shortly after. Latest mentions of EPF Composer in Eclipse forums date back from 2018 and the project, though promising and still downloadable and functioning, looks abandoned.

The main features of this platform encompass the authoring, configuring, publishing and browsing of methods and processes. All components of the SPEM specification are available in EPF Composer, including an explicit division between method content and processes.

The users of this platform can create processes either via breakdown structure editors or workflow diagram editors; from scratch or by adopting an existing framework. The platform’s key feature –as the main differentiator with other tools included in this post– is the ability to create and reuse process building blocks (known as capability patterns) that represent best practices that can be assembled to compose new processes and methods. In defining a process, then, one can use some or all of the elements of a method content library.

The EPF Composer’s installation package includes reusable plug-ins and method libraries for some common development frameworks, such as OpenUP, Extreme Programming and Scrum. So, the users can tailor, adapt, extend and enact these frameworks within their own organizations for their specific project needs.

Finally, the frameworks created with EPF Composer can be published and deployed as websites, so that all members of the organization can access and navigate through the complete up-to-date information, regulation and practices about their development processes. Processes could also be exported as templates for Microsoft Project.

IBM Engineering Lifecycle Optimization – Method Composer

A commercial equivalent of EPF Composer is the IBM Engineering Lifecycle Optimization – Method Composer, now in its version 7.6.2 that was released in 2020. It fully supports the SPEM 2.0 specification and we can describe this platform as an EPF Composer on steroids: this IBM solution is part of the company’s suite for software development, management and governance.

Apart from the main features available in the open-source platform, it includes an extended catalog of pre-defined processes such as RUP and some other relevant extensions:

• Since version 7.5.2, it is possible to extend the SPEM metamodel by adding element types or custom attributes and relationships to existing SPEM elements; for example: RACI relationships between roles and tasks.
• Users are able to select subsets of method content and processes from existing libraries, organize them in method packages, and set up a method configuration so that they can apply a subset of a full framework specification to a given specific context.
• Similarly, users can tailor existing method content and processes to fit the needs of an instance of a project. Processes can be customized by adding and/or removing activities, tasks, roles, and work products. Those changes can be saved in tailoring sessions so that the original framework library is not modified.
• The platform provides the capability of defining estimation models, its factors, and formulas.

It also provides integrations with different tools for version control and reporting, and allows users to collaborate and discuss online on process pages.

Enterprise Architect

Enterprise Architect is a multi-purpose enterprise solution for analysis, modeling, test and maintenance of systems, including software and processes. Its latest version is the 16 and was released on April, 21st 2022.

Within the software area / module of the solution, Enterprise Architect enables its users to document software development processes using SPEM 2.0. This specification is included as a UML 2 profile. The tool includes a template –not depicting any known framework or method– for quickly creating a simple model.

A user can define any element according to the SPEM specification, including workflow diagrams to describe the steps for performing a task and the components involved. Enterprise Architect enables users to switch between different views of a model diagram and also to collaborate via the tool so they can keep track of a journal of changes or discussions.

The models generated can be exported in interoperability formats such as XMI and other XML formats –the user can reference an XSL file for post-processing–. Additionally, the information can be published in HTML format in local files or in a Joomla site server, so all employees in an organization can browse the information included in the model.

MagicDraw UML

MagicDraw UML is a solution for analysis and modeling of software and systems. Its latest version is named 2021x and was released in 2021. The default version of MagicDraw UML doesn’t support the SPEM metamodel. It is available as a profile via plug-in.

For any given MagicDraw project, users can define the method content and different diagrams to include the processes of the method being defined. With MagicDraw users can create the following: activity detail, process component, team profile, work product dependency, and workflow diagrams; with all elements from the specification being available. There is no explicit separation between the method content and its processes.

A project can be saved as a template for other projects, so that users can reutilize existing methods (as a whole) to start creating new ones. Other export formats include XMI (UML, MOF, Eclipse) and EMF Ecore.

Miscellaneous

Beyond the main tools listed above, there are a few other tools that claim (or used to) support SPEM:

• Modelio (formerly Objecteering Modeler), although the company participated in the SPEM specification, it doesn’t have a SPEM profile –it supports XMI import, though, of the UML 2 profile. The last reference to SPEM in public forums is from 8 years ago.
• SPEM Designer has not been updated since 2010.
• Spemmet originally used to support SPEM 1.1 but it has never been updated.
• v-EPF is a web-based tool for the extended v-SPEM specification.

Takeaways

As we can see, the adoption of SPEM is very different from one tool to another but in general, we can say there is a limited adoption of SPEM in current modeling tools. 

When looking into scientific papers to see what tools are used in there, the most popular platform we see is the Eclipse Process Framework (EPF) Composer. It is used in 6 out of 10 reviewed papers, mostly focused on MDD activities. Still, when looking at papers that describe processes we often see that SPEM is not actually used for the description. 

One potential reason is that SPEM is so flexible, its purpose so ambitious, that it has a steep learning curve. This together with the limited tool support makes companies interested in process modeling to look for more “mainstream” alternatives. As of today, SPEM cannot be considered the rosetta  stone for describing, communicating and executing specific software development processes in the current fast-paced industry. Let’s see if the increasing needs for software modeling generate a broader adoption of SPEM (or SPEM extensions) that turn the tide. 

But for now, UML and BPMN are so popular (and with much better tool support) that are often used by companies that want to somehow draw their processes. Even if neither UML or BPMN include modeling primitives specific to software process modeling both are obviously capable of describing a myriad of different types of processes so it’s not surprising that they work “good enough” in many scenarios. As we said, this is also the case for research works where it is difficult to see references to SPEM in the last years.

Is, then, the time to deprecate SPEM? Time to revise and refresh it? Or are UML and BPMN combined, enough to model software development processes? Or, maybe, we need a new set of DSLs that target the process modeling needs of each of the new software engineering scenarios we need to cope with? 

Feel free to share your thoughts and point us to any potential SPEM (or any other tailored process modeling tool) you may know!