Spem software process

These elements will be used in the Section 4 case study. This compliance is related to the process capacity as specified in these two models. Process capability is defined as the refinement degree and institutionalization that the process is executed in the organization or in the organizational unit [17].

Spider-PE [18] is a support set of tools designed in order to support the software process enactment. This software tool was conceived in. Table 1. Instantiated process elements [9]. Furthermore, this tool is designed in order to validate the proposed language and framework. The study presented in [5] was the Spider-PE main reference regarding the flexibility concept during enactment.

This environment adopts the formal specification with graph grammars approach to assist the enactment of the processes modeled in this language. This formal enactment only occurs on the elements that compose the Instantiated Processes structure shown in Table 1.

This occurs because these processes are enacted by an organization considering the resources available and the specific characteristics of software that will be produced [14]. This choice was made because both approaches aim at making the SPEM 2.

The purpose of this packets structure is to provide organizations with the means to define a conceptual structure and the necessary concepts for the semi-automated enactment of their development processes. For a better understanding, it will be presented only a subset of these language concepts, selected according to their relevance for understanding the case study presented in Section 4.

In this package we highlight the importance of the Activity component. This is a Work Breakdown Element and Work Definition specialization which defines the general unit of work within a process as well as a process itself. The Process class represents a set of work definitions partially ordered with the intention of achieving development goals, such as the specific software system delivery.

These processes are characterized as Phases and Milestones sequences and expressing the product development life cycle. Phase represents a significant period of time for a project. Usually there are events that occur in the phase end, such as a control point, a milestone or the delivery of a product to the customer. Milestone is a Work Breakdown Element that represents a significant event for a development project.

Events usually occur in the Milestone such as an important decision-making or the delivery of a working version of the software. Iteration consists of a set of activities and tasks that should be exe cuted in a loop.

At the iteration end a Milestone can occur. Finally, the Task Use class in this package was also highlighted. This class must provide information related to the resources involved during the enactment of a represented task. The process will evolve from one state to another during the enactment. In this context, state means the situation in which the process is in relation to the enactment: not started, enacting, paused, finalized.

Through these states, it is possible to determine the current stage of the project development. Thus, it is necessary to define concepts for the characterization of all these process states during the enactment. This is the Process Parameters package goal. Furthermore, we used concepts of states related to the enactment time of process elements Time State class from the xSPEM approach [7]. Finally, this package used elements from the SPSM approach [19]. These properties contained in the Process Parameters package can be classified as universal and existential.

The universal properties are those which must be completed in each enactment. For instance, every activity must start and end; once an activity is finalized, it has to stay in this state. These states are defined in the State Type and Process State classes. The existential properties are those that must be true at least for an enactment.

As an example, each activity must be performed in a time between the expected Start Time and the expected End Time.

Additional resources are necessary in order to adjust the process of a project. This involves to define specific properties for activity scheduling and resource allocation. In this package it is redefined the Activity class, adding to its definition the expected time interval during which an activity must be enacted expected Start Time and expected End Time and the real time in which this activity occurs real Start Time and real End Time so that comparisons could be made.

These allow the process enactment evolution through the Event Types package. Figure 2. We defined the Process Trace package based upon the xSPEM [7] because this approach has the same purpose as the approach proposed in this paper: to record the process enactment. These events may be produced by the process Exogenous Event or produced in the process Endogenous Event.

In this context, rules define pre and post-conditions in a manner similar to an inference engine of a specialist system [5]. This section presents only a subset of rules, selected according to their relevance to the case study, described in Section 4. This specification indicates a step-by-step enactment rules application on defined scenarios.

Thus, we have:. First, a task can assume the states: not Started, started, paused and finished. In order to apply rules to these aspects, it is necessary to extend the Task Use element in order to introduce attributes that reflect the dynamic information the current task state and the internal clock concept. However, this concept should be taken into consideration by the enactment mechanism to adopt this language. An abstract observation of the operational semantics of processes enactment in relation to these properties can be performed.

Considering t as the task to be performed, whose initial state is not Started, the state transitions relations are presented in the Figure 3. Attached to each task, there is the concept of internal clock to check its enactment time status. Finally, we carried out an analysis of these standards through specific characteristics considered necessary to model and to represent software processes.

Since the earliest development projects of large software systems, a major concern of the organizations was to provide a strategy to manage the complexity of software development activities [1]. Thus, several life cycle models have been proposed for software development e. Waterfall, Spiral and Incremental Model.

However, the granularity of these life cycle models was too high and did not describe the basic elements of the process, such as roles used [2]. Then there was the need to describe, in the processes, more information about what the organizations are actually doing during the development of software e.

From this necessity arose the concept of Process Models. A process model can be defined as a formal description of the software development where several types of information should be integrated in order to indicate when, where, how, why and by whom the steps are performed [3].

The process models usage brings a unique set of advantages for organizations [5]: allows the process to be understood more easily; allows the identification of process elements that can be improved; allows the processes reuse; and supports the process management.

In order to build a software process model it is necessary a modeling language which defines a set of notations needed to represent the elements that compose a software process [5].

There are several languages for software process modeling, highlighting: SPEM Software Process Engineering Metamodel Specification [6] that uses the UML Unified Modeling Language notations, defining a specific stereotypes set to support software process modeling; and the BPMN Business Process Modeling Notation [7], an approach that treats the software process as a business process, as well as other organizational processes.

These two languages are widely spread, largely due to the support they receive from OMG Object Management Group [8]—a worldwide recognized organization which aims to approve and maintain open standards for object-oriented applications. Parallel to the emergence of these process models, there is the emergence of several quality models that are also strong indicators of the high importance of methods that contribute to improving the software process [9]. Most of these programs require that the processes are represented in some way, thus indicating the importance of process modeling as it provides a way to represent these processes [10].

Obtaining Process Improvement Program certifications adds competitive value to the organizations both in the national and international levels. These programs aim to help organizations defining and continuously improveing software processes.

This maturity model aims to provide guidelines for process improvement and the products and services development. This paper has two main objectives. The first is to establish a standard structure for software process. This mapping provides the basis for analyzing these modeling languages in relation to their expressiveness in software processes representation.

In addition to this introduction, Section 2 presents the related works to this research. In order to validate this analysis, a case study is presented in Section 4. Section 5 proposes an analysis to assess which of these languages is best suited for the representation of software processes. Finally, Section 6 presents the conclusions of this paper.

A proposal similar to that presented in this paper is discussed in [9], which proposes the modeling of the CMMI guide concepts from the SPEM notation as a basis for software processes modeling.

The goal of this proposal is to capture information on the compliance and compatibility of CMMI in relation to SPEM, identifying the software process components and their relationships.

However, this proposal does not evaluate the modeling languages available to justify the choice of language adopted in its metamodel. There are two approaches that propose the automatized enactment of software processes development modeled after the SPEM standard [1,12].

However, models transformations impose refinement stages before they can be executed. These refinement stages demand a great effort in maintaining the mapping between models in the case of any change in the process, causing the loss of appropriate semantics. A comparative study of several standards for processes modeling, including SPEM and BPMN, is presented in [13], and in relation to the characteristics considered necessary to achieve this purpose.

However, this approach presents no practical validation of the research conducted. Through the mapping presented in the current paper, it is possible to observe which of these models have components that are semantically equivalent to each other. For some non-equivalent components, compliance was achieved by establishing conditions, restrictions or compositions of more than one component of the target model.

It will be further explained in the Subsection 3. From the case study described in Section 4, it is possible to observe a practical scenario of how the models relate to each other, allowing the extraction of relevant information to a proposal that meets the main practices and recommendations inherent to software processes within a model quality.

Subsequently, an analysis of the structural and behavioral representation of these notations is performed. Before performing the mapping, it is necessary to define a software process as a software process model and its diagrammatic representation. Thus, the overall structure of the composition of software processes used in this paper is based upon a model derived from an foundational ontology, named UFO Unified Foundational Ontology [14], applied in the software processes area in the ODE Project Ontology-based software development environment.

This software process ontology shown in Figure 1 was developed to establish a common concept for software organizations exchange information regarding their software processes. Figure 1.

Software process model derived from ODE project [14]. According to this ontology [14], Processes are collections of related activities that must be performed during the development of a product.

Therefore, a Process consists of a structured set of Activities and all the infrastructure involved to perform them. In turn, Activities are the tasks or work that should be performed.

An Activity requires Resources and can consume or produce Artifacts. An Activity can adopt a Procedure to accomplish this. This Activity can be decomposed into other Activities. The later kind of Activity are also known as Pre-Activities. The concept of Activity is present in all models of software process as it generates Artifacts from input Artifacts and other resources.

Activities may represent any level of the process, e. In order to describe the process stage and associated activities, there is the concept of LifecycleModel. This concept defines the structure and the approach to organize the activities into process Phases. The Lifecycle starts when a software is designed and comes to an end when the software has been discontinued. Therefore, the Lifecycle contains a set of development activities, operations and maintenance. Aligned with this concept, there is the Combination which defines how a set of Phases of a LifecycleModel should be performed and specifies the LifecycleModel, which can be sequential or iterative.

What is new in v5. What's new in 3. PDF Library. Registered Users. Enterprise Architect Pro Cloud Server. All Users. Index Model Domains Modeling Languages.