Modelling software process

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Modelling Software Process, Process Description and Improvement.

The concept of model is not new in software engineering as we all use some ort of models whenever we think about any kind of problems. The simplest form of models could be when we talk to each other, and when we construct methods, and even we some time try to understand the phenomena's. We also prepare some models when we prepare lecture for teaching. It would not be wrong if we say that every day we sue some kind of models all the time. This shows that models have never been actually invented but they have been around since human existence [JL2003 ]. This shows that, nobody can actually just define what a model is but we may expect that other people will do accept this definition; the literature review shows that there is no consistent common understanding of models. In this essay this ambiguity is ignored, and the term “model” is defined in a since that there is no conflicting opinions. In short we can say that the ability for modelling is not attained but given to us actually from the birth. The term “model” is taken the Latin word modulus,. In Latin it means measure, rule or pattern. The best examples could be toy railways and dolls, maps, architectural models of buildings structures. However, in software engineering examples could be like process models, design patterns, class diagrams.

Now the question is how to differentiate models from other artefacts, we need principles. According to Stachowiak [SH2003] work, any candidate who fulfils these three rules can be said to be models. The first rule is referred as mapping and there is an original object that is mapped to the model. In this process the object is referred to as “the original”. The second is reduction which states not all the properties of the original working system are mapped on to the model, but the model is some how reduced or abstract view of the system. The last is Pragmatic this rule states that the model could replace the original for some purpose. This means to show that the model is useful.

A stated above process modelling is an important application of modelling in the field of the software engineering. We can say that the area of software evolution processes is associated to both software evolution and software processes. We must know that the software evolution and software processes are both two important areas in software engineering. Due to the importance up till now much of the work has been done. Most of the research topics/ trends include methodologies, technologies, tools and management.

Before going further we shall actually know what is a software process? Software processes actually indicate a set of interconnected processes in the software life cycle. It provides a framework so as to manage all activities that can very easily go out of control in software development. It is important to note that different software projects actually require different software processes. In software development the actual program, code documentation all are produced as a result of the activities defined by the software processes [PRS2000]. Work at reference show that the concept of software process is showing a rich duality between practices that are considered as good for developing software products and practical practices that are good for developing processes. At first this focus was primarily concentrating on process programming languages and tools, but later on this approach has been broadened to yield highly useful insights into software process requirements, process architectures, process change management, process families and process asset libraries with reusable and composable process components, enabling more gainful realisation of higher software process maturity levels [BB 2006].

The Standard for Information Technology and Software Life Cycle Processes (ISO/IEC

12207 Standard) defines a software process as a set of interconnected activities, which transform inputs into outputs. Each process is further explained in terms of its own essential activities, each of which is further described in terms of its constituent tasks. An activity under a process is a set of interrelated tasks. A task is actually expressed in the form of self-declaration, requirement and recommendation or permissible action [ISO + IEC 1998].

The ISO groups all the respective activities that may be performed during the life cycle of software which consists of five primary processes, eight supporting processes and four organisational processes. However, each life cycle process is divided into a set of related activities whereas, each activity is further sub divided into a set of tasks [ISO + IEC 1998]. These processes are explained below:

  1. Primary processes (ISO and IEC 1998): acquisition process, supply process, development process, operation process and maintenance process
  2. Supporting processes (ISO and IEC 1998): documentation process, configuration management process, quality assurance process, verification process, validation process, joint review process, audit process and problem resolution process
  3. Organisational processes (ISO and IEC 1998): management process, infrastructure process, improvement process and training process.

The work at [OLJ1987], which also won the ICSE9 Award in 1997, Osterweil presented an approach which is recognised as the most accepted view that software processes are software too. He also suggested that it is important to create software process descriptions to guide key software processes that these descriptions must be made as precise as possible. The author further stated that these processes then become guides for the effective application of computing power in support of the execution of processes instantiated from these descriptions.

A software process is modelled and which reflects the abstract and static part of the of the process. Whereas, process description is a detailed and concrete representation of a software process. It is important to note there exist a key difference between a process and process description. For example we can say that process is a vehicle for doing a job whereas, process description is a specification of how to perform the job. The process itself is considered as dynamic entity and the process description is considered as dynamic entity. We can say that it is the difference between a class or instance class [OLJ 1987+OLJ 1997].

Software development is considered as the execution of a process by a collection of agents, some of these agents could be human and some of which could be the tools. It is important that the Humans agent must be using some powerful process abstractions. The phrase “software process is software too” states that the processes by which software is created are a considered as particular type of software, and most probably this is some sort of subtype of the larger universe of software [OLJ 2003].

The activity of creation software process models using any approach is called software process modelling (SPM). Software process models is defined by a

meta-model or a modelling language using any modelling language or tool. A software process description language (SPDL) could be used to describe detail of a software process. The Object Management Group (OMG) presented layered architecture of modelling which consists of four layers, as shown in Fig. 2.1 (OMG 2002), which describes the relationship stated above.

The acting process or the real-world production process is placed at level M0. Whereas, the corresponding definitions are placed at level M1. The meta-model is placed at level M2 and which provide a template for level M1. A meta-model is also defined as an instance of the MOF (Meta-Object Facility) meta-meta-model [OMG 2002].

There do exist various approaches for modelling software processes, but most important and used approaches are top-down and bottom-up. The software process models consist of the informal, the semi-formal and the formal models. The graphs, tables, natural languages, computer languages and mathematical expressions are mostly included in description tools of software process. A process research reveals that graphical process models are especially useful in raising human awareness and perception about process characteristics. Obviously, the most efficient models include high-level of abstractions that support brief visualisation [CCO 2000].

The modelling approach in process is an efficient abstract approach and has recently been receiving much more attention recently. A number of studies and research in related areas show how various application software modelling formalisms model software processes. The best examples would be Petri Nets, finite state machines and data flow diagrams. All these examples have been used to model software processes such as at citation [BFG1993],[FA 2000]. There is no universality. This means that different types of process models are good for different things as each one has different requirements.

The models are developed based on the approach that model normally address narrow problem and mostly it is the abstract representation of the software process [OLJ 1997+OLJ2003]. Process models require coherent support for some characteristics that are not nearly adequately important in traditional programming languages. They must be coherent in specifying which activities are to be executed by which kinds of agents whether that is human or tool [OLJ 2003].

In this paragraph we discuss some of the resent works in process modelling as well as process description. [KD 2004] work mainly focused on creating a model that could intrinsically supports the structuring of processes from existing activities. The first contribution of this research is an abstraction of the product that enables the activities to be compared. The second major contribution is a reduction in problem space for the identification and quantification of the factors that persuade how well engineers create new and modify existing software products.

The authors research mostly concentrated on software aspects and their defined approach support both software process management as well as software process modelling. The important point is that their aspects can monitor, enforce or even partially implement conformity with desired development practices. Their work also provided a provision for a precise description of a software development process [MK 2006].

The work done at [AI2003] suggest that software processes is a blueprints and emphasises that actual design is independent from use, and thus this shows that dt software process designers and users are also independent from each other. This approach software processes are considered as recipes where developers individually and collectively contribute to the design their own software processes by facilitation, reflection and improvisation.

Cangussu et al. presented an approach that could be used for modelling the system test phase. This approach use control theory and its respective usefulness for computing the effort required to reduce the number of errors in life cycle phase and the scheduled slippage under a changing process environment. Their model is considered as successful milestone along the road to practical theory of software process control (CDM2002).

The Unified Process makes use the Unified Modelling Language for preparation of all blueprints of the software system. This approach is use-case driven, architecture-centric, iterative and incremental. However, this unified process repeats over a series of cycles making up the life of a system cycle. This process has become much more popular as can be extracted from the reference (JBR1999).

Doppke et al. research make use of the virtual environments, MUDs (Multi-User Dimensions) in the domain of software processes. Their work defined a mapping, or metaphor, that allow the representation of software processes within a MUD. The system resulting from this mapping allow the modelling and execution of software processes by distributed agents (DHW1998).

Some researchers pointed out a number of questions including: “How can we lift the level of abstraction in which the framework instantiation is expressed, reasoned about and is implemented?” The other question is that “How can the high-level design abstractions that were used to develop the framework be used during framework instantiation instead of using source code as is done currently?” and the third is “How can we define extended design abstractions that can allow framework instantiation to be explicitly represented and validated?”

Oliveira et al. proposed an approach to framework instantiation problem based on software processes that addresses these issues. They used explicit and declarative ways for the framework design models. Their work supported changes to this design based on explicit instantiation tasks. In this way, the framework instantiation can be executed in a valid and controlled manner [OAF+ 2004].

Lardjane et al. proposed an approach to incorporate software process models in a distributed context. Their approach is based on the mixture of process fragments (components) defined with the UML notation. The incorporation methodology allows unifying the various fragments both at the static level and at the dynamic level. This approach provides various solutions for the integration of conflicts and also gives the possibility of improving and designing a new software process models by the merging of reusable process fragments [LN 2003].

Zhao et al. presented an approach for application to the agent technology to software process modelling and process centred software engineering environments. In their work , software processes are considered as the alliance of a group of process agents. The group know how to manage the software development activities over all and can act in the way software developers take into consideration the planning, enacting and reflecting on their work [ZCL2005].

Zhang et al. proposed an architecture based software process model (ABSP). The ABSP model consists of six sub process. This approach actually divides software process into sub processes which are requirements, design, documentation, review, implementation, and evolution. If we compare this approach with the traditional software process model, the ABSP model is advantages over traditional model in terms explicit structure, easy understand ability, better portability and large, reusable granularity (ZH2003).

Kornstaedt et al. proposed a concept and prototyping through tool implementation so as to systematically collect process knowledge in the form of annotations. These annotations are then analysed, integrated and incorporated into the process model, This allow users to learn from previous experiences [KR2002].

Due to various software development methodologies, they raised the need to evaluate and compare their efficiencies respectively. Germain et al. work perform this sort of comparison by having different teams apply different process models in the implementation of multiple versions of common specifications [GR2005]. Apart from this , Lehman and his colleagues also made major contributions [LR2002] in this respective area.

Software process modelling languages (PMLs) and process description languages (PDLs) are the tools used to define software processes. Software processes are much more complex entities and humans must use some powerful process abstractions tools and for this purpose research in software engineering have created number languages [OLJ2003]. The use of these languages makes it easy and possible to represent process in a precise and comprehensive way [FA2000]. This could include all those activities that have to be accomplished to achieve the process objectives (for example to develop and test a module). This also show the importance of the roles of the people in the process such as the software analyst, team leader and project manager. The structure and nature of the artefacts to be created and maintained are also of prime importance in software process modelling for example requirements specification documents, code modules and test cases. The last and most important is the tools to be used for example CASE tools and compilers. We know that process are divided among humans and software agents so the processes must be architecture in such a way that they shall specify that they could be executed be which agent.

In special cases where human are also acting as agents, the software process definition must be very very careful to present to the human required contextual information about the activity to be performed, and to accord the human considerable latitude and choice of how that particular activity is to be performed [OLJ 2003]. The work of Fuggetta suggested that PML must be tolerant enough so that it allows for incomplete, informal and partial specification (FA2000).

Some of the research work in the area of the process modelling and description is as under:

Osterweil and his colleagues produced number of results in this particular area. Their first process modelling language which was based on Ada, APPL/A [SHO1990+SHO1995] showed that software processes can be defined by using a procedural language but the important consideration was provide reactive control constructs in that respective language. We can say that they followed some how different with the notion of process programming. Their approach is used the idea that processes can be described using the same kind of languages that are mostly used to create conventional software. This view has been initially supported with the development of APPL/A and another description language, known as Little-JIL [CLM+ 2000]. Both of these languages incorporate constructs and concepts typical of different programming languages. The Little-JIL is a language for programming coordination in processes and is an executable high-level programming language with a formal graphical syntax. The Little-JIL explicitly defined operational semantics. It tried to resolve the conflicting objectives of providing constructs to support a wide variety of process abstractions. This include organisations, activities, artefacts, resources, events, agents, and exceptions and creating a language that is easy to use and understandable by non-programmers [CLM+ 2000].

Cobleigh et al. described how FLAVERS, a finite state verification system, has been used to verify properties of processes that have been defined using Little-JIL. It is demonstrated that process abstractions can be quite effective in supporting precise process definitions, but the underlying semantic complexity poses challenges for static analysis (CCO 2000).

Lerner described how Little-JIL processes are translated into models and also reported on analysis results which have uncovered seven errors in the Little-JIL interpreter that were previously unknown as well as an error in a software process that had previously been analysed by using a different approach without finding the error (LBS 2004).

Warboys et al. designed a second-generation process language which incorporates significant departures from conventional thinking. Firstly, a process is viewed as a set of mediated collaborations rather than as a set of partially ordered activities. Secondly, emphasis is given to how process models are developed, used and enhanced over a potentially long lifetime. In particular, the issue of composing both new and existing model fragments is central to the development approach [WBG+ 1999].

Jaccheri et al. Their work contributed another process modelling language E3 and respective support tool, which are consider for process model elicitation. The E3 language is an object-oriented modelling language with a graphical interface. In this language associations are a means to express constraints and facilitate reuse. The E3p-draw tool supports the creation and management of E3 models. It also provides a view mechanism that is helpful in the checking of models according to different perspectives [JPL1998].

The work of Nitto et al. focused at assessing the option of employing a subset of UML as an executable process modelling language. Their work proposed a formalisation of the semantics of the UML subset and later presented the translation of UML process models into source code, which can be acted out in a process-centred environment. They proposed and considered that process modelling by using the UML would be much more easier and available to a larger community of software developers (NLS+ 2002).

Atkinson et al. presented an evolutionary process modelling language that supports the evolutionary model development. They suggested a tool for performing model verification and used the modelling language and tool on a model for distributed software development (AWN 2004).

Chen proposed a concurrent software process language (CSPL). CSPL used an n approach to combine the object-oriented Ada95-like syntax with UNIX shell scripts in a software process language. The language particularly designed for software processes such as work assignment statements, communication-related statements, role units, tool units and relation units (CJY1997).

Cook et al. proposed techniques for identifying and measuring the discrepancies between models and executions, this is called process validation. Process validation takes a process execution and a process model as input, and it measures the level of correspondence between the two. The techniques actually provide detail of information once a high-level measurement indicates the presence of a problem [CW 1999].

SPADE is an environment that not only supports the analysis, design and enactment of software processes. SPADE also consists of a language called SLANG which is considered as a domain specific language for software process modelling and enactment. A software process is considered as a set of similar activities that are executed concurrently according to their logical precedence and, at the same time, scheduled to meet some global deadlines. The concept of activity is some what central for the description of a software process in SPADE (BFG1993).

Sliski et al. presented their work where the tool utilisation model is specified by a process. Their approach consists of a user-interface specification that describes how the user interface could respond to, or reflect, progress through the execution of the process definition. It is the easiest way to develop alternative processes. This also provides varying levels and styles of guidance. This also makes responsive to evolution in the processes, user interfaces or toolset (SBC+2001).

It is important and we must always remember that no Software processes can be defined once for all. With the progress in development cycle each respective process need to be continuously updated and may be even refined to increase their usefulness and quality to deal with software development. Therefore, software process improvement (SPI) is considered as one of the driving force in the software industry. It is important to note that process improvement is a dynamic and detailed activity. SPI not only include the activity during the process modelling and process implementation but do include the process measurement, process assessment, process optimisation and control [JP 2000+WL2001)]. In all these processes the method of process improvement actually determines the relevant technologies for implementation of the process improvement. In this branch of the research in the process modelling the SPI has so for has achieved good progress in both the academic community and industry. Nowadays, there are mainly two approaches to implement process improvement, one approach is model-driven and the other is measurement-driven [QXC+2003]. The former, standards such as ISO 9000 and CMM, mostly stressed at improving the maturity of an organisation's process capability and implements top-down measurement approaches. The activities of relevant improvement are based on a definite assessment model. However, the latter constantly collects feedback from the process measurement activities and takes respective improvement actions to so as to solve the problems produced during the process execution [CF 2002+QXC+2003]

The Capability Maturity Model (CMM) which is developed by the Software Engineering Institute (SEI) at Carnegie Mellon University has an important role in SPI. In order to find out the status of e an organisation's current state of process maturity, the SEI presented an assessment mechanism that results in a five point grading scheme. The SEI second approach towards the global effectiveness provides a measure for a company's software engineering practices and based on this approach it establishes a five process maturity levels. In these levels the higher level represents the process improvement in contrast to a lower level. The SEI has actually attached process areas (KPAs) with each of the maturity levels. The KPAs present them as se software engineering functions for example software project planning, requirements management that must be present to satisfy good practice at a particular level [PRS 2000].

The Capability Maturity Model Integration (CMMI) project is produced as post effect from the success of the CMM for software. This expansion created several challenges for companies that desired to apply more than one model; it was observed that overlaps, conflicts in content, differences in architecture and guidance gas drastically increased the cost and difficulty of organisation-wide improvement. Along with this new CMMI models have been developed that consists supplier sourcing and integrated product and process development [SEI 2004].

It is important to remember that the CMM quality models and the ISO 9001 standard have defined the requirements for an ideal company. These enable us to use the respective reference model in order to assess the state of a company and to find out whether any degree of improvement has been achieved or to be achieved [FA 2000; TMO1997]. Based on These models a sufficient progress has been made and some of which we are disusing during the coming paragraphs of this essay.

Beecham et al. presented his work in which he described that how the requirements engineering (RE) process is decomposed and prioritised according to maturity goals set by CMM. Their works focus and tries to help practitioners to define their RE process with a view to setting realistic goals for improvement [BHR 2005].

Based on the approach of CMM, ISO/IEC 15504 and ISO 9000-3 others, Wu et al. proposed a methodology which is based on the approach to use benchmark adaptable software process improvement (MBASPI). In their work they introduced the main components of its support environment (MBASPI/E). Their approach was based the philosophy of “balance and optimum”. This could be achieved through large granular software process reuse and by using a modelling language for creation of the unified models of practical development, and through the endorsement of all these models under the support environment along with domain knowledge. Software developer companies are forced to use and adopt some process standards. This could result in achieving a higher capability maturity level so as realise a continuous software process improvement natively [WYY 2004].

Another question is that whether the Knowledge management can be used to support SPI. Falbo et al. proposed the knowledge management approach that an be adopted in an organisation at CMM level 3 in order to support to support organisational process couturing to projects and process improvement which is based on metric data collected from past projects [FBV 2004].

Tianfield presented an approach which is based an autonomic framework for quantitative SPI. This approach embodies an autonomic mechanism which brings forth self-organisation for software process improvement [TH2003]. It is also possible that SPI may require changes in the process models. Hence, it is equally important to evaluate the maintainability of these models in order to facilitate their respective evolution. Garcia et al. work states that the results produced with the replication of an experiment to could validate a set of metrics for software process models. Based on this result we can obtain a set of useful indicators of the understandability and modifiability [GPR 2005].

Jalote et al. research work show control charts could be used for monitoring and improving software processes, particularly quality control processes like reviews and testing. In their work the come out with developing a respective cost model for using

control charts for a software process approach for optimum control limits that can be determined [JS2002].

The short summary of this essay is to show how models could be used to model software process, and to pin point the important research work done so for the improvement of the process description. In the last section of this essay we explained what is SPI and what are the respective challenges for the SPSI


[ PRS2000] Pressman RS (2000) Software engineering: a practitioner's approach (ed5). McGraw Hill,New York

[BB2006] Boehm B (2006) A view of 20th and 21st century software engineering. In: Proceedings of the 28th international conference on software engineering. ACM Press, New York.

[ISO+IEC1998] ISO, IEC (1998) ISO/IEC 12207 standard for information technologyâ€"software life cycle Processes

[OLJ1987] Osterweil LJ (1987) Software processes are software too. In: Proceedings of the 9th international conference on software engineering. ACM Press, New York.

[OLJ1997] Osterweil LJ (1997) Software processes are software too, revisited: an invited talk on the most influential paper of ICSE 9. In: Proceedings of the 19th international conference on software engineering. ACM Press, New York.

[OLJ2003] Osterweil LJ (2003) Understanding process and the quest for deeper questions in

software engineering research. ACM SIGSOFT Software Engineering Notes.

[OMG] OMG (2002) Software process engineering metamodel specification. Object Management Group.

[CCO2000] Cobleigh JM, Clarke LA, Osterweil LJ (2000) Verifying properties of process definitions. In: Proceedings of the 2000 ACM SIGSOFT international symposium on software testing and analysis. ACM Press, New York.

[BFG1993] Bandinelli S, Fuggetta A, Grigolli S (1993) Process modeling in-the-large with SLANG. In: Proceedings of the 2nd international conference on software process. IEEE Computer Society Press, Washington DC.

[FA2000] Fuggetta A (2000) Software process: a roadmap. In: Proceedings of the conference on the future of software engineering. ACM Press, New York.

[KD2004] Kirk D (2004) A flexible software process model. In: Proceedings of the 26th international conference on software engineering. IEEE Computer Society, Washington DC.

[MK2006] Mishali O, Katz S (2006) Using aspects to support the software process: XP over eclipse. In: Proceedings of the 5th international conference on aspect-oriented software development. ACM Press, New York.

[AI2003] Aaen I (2003) Software process improvement: blueprints versus recipes. IEEE Software .

[CDM2002] Cangussu JW, De Carlo RA, Mathur AP (2002) A formal model of the software test process. IEEE Transactions on Software Engineering.

[JBR1999] Jacobson I, Booch G, Rumbaugh J (1999) The unified software development process.Addison-Wesley, London.

[DHW1998] Doppke JC, Heimbigner D, Wolf AL (1998) Software process modeling and executionwithin virtual environments. ACM Transactions on Software Engineering and Methodology.

[OAF+2004] Oliveira TC, Alencar PSC, Filho IM, Lucena CJPD, Cowan DD (2004) Software processrepresentation and analysis for framework instantiation. IEEE Transactions on SoftwareEngineering.

[LN2003] Lardjane N, Nacer MA (2003) Distributed software process models: an integration

methodology. In: Proceedings of ACS/IEEE international conference on computer systems

and applications. IEEE Computer Society, Washington DC, p 44

[ZCL2005] Zhao X, Chan K, Li M (2005) Applying agent technology to software process modelingand process-centered software engineering environment. In: Proceedings of the 2005ACM symposium on applied computing. ACM Press, New York.

[ZH2003] Zhang Y, He Y (2003) Architecture-based software process model. ACM SIGSOFT

Software Engineering Notes.

[KR2002] Kornstaedt UB, Reinert R (2002) A concept to support process model maintenance

through systematic experience capture. In: Proceedings of the 14th international conference

on software engineering and knowledge engineering. ACM Press, New York.

[GR2005] Germain ̉ۡ, Robillard PN (2005) Engineering-based processes and agile methodologies

for software development: a comparative case study. Journal of Systems and Software .

[LR2002] Lehman MM, Ramil JF (2002) Behavioural modelling of long-lived evolution processes:

some issues and an example. Journal of Software Maintenance: Research and Practice .

[SHO1990] Sutton SM Jr, Heimbigner DM, Osterweil LJ (1990) Language constructs for managing

change in process-centered environments. In: Proceedings of the 4th ACM SIGSOFT

symposium on software development environments. ACM Press, New York.

[SHO1995] Sutton SM Jr, Heimbigner DM, Osterweil LJ (1995) APPL/Aâ€"a language for softwareprocess programming. ACM Transactions on Software Engineering and Methodology .

[CLM+2000] Cass AG, Lerner BS, McCall EK, Osterweil LJ, Sutton SM, Wise A (2000) Little-JIL/ Juliette: a process definition language and interpreter. In: Proceedings of the 22nd international

conference on software engineering. ACM Press, New York.

[CCO2000] Cobleigh JM, Clarke LA, Osterweil LJ (2000) Verifying properties of process definitions. In: Proceedings of the 2000 ACM SIGSOFT international symposium on software testing and analysis. ACM Press, New York.

[CLO+200] Cass AG, Lerner BS, McCall EK, Osterweil LJ, Sutton SM, Wise A (2000) Little-JIL/ Juliette: a process definition language and interpreter. In: Proceedings of the 22nd international conference on software engineering. ACM Press, New York.

[LBS2004] Lerner BS (2004) Verifying process models built using parameterized state machines. In: Proceedings of the 2004 ACM SIGSOFT international symposium on software testing and analysis. ACM Press, New York.

[WBG+1999] Warboys BC, Balasubramaniam D, Greenwood RM, Kirby GNC, Mayes K, Morrison R, Munro DS (1999) Collaboration and composition: issues for a second generation process language. In: Proceedings of the 7th European software engineering conference held jointly with the 7th ACM SIGSOFT international symposium on foundations of software engineering. Springer-Verlag, London.

[JPL1998] Jaccheri M, Picco GP, Lago P (1998) Eliciting software process models with the E3 language. ACM Transactions on Software Engineering and Methodology .

[NLS+2002] Nitto ED, Lavazza L, Schiavoni M, Tracanella E, Trombetta M (2002) Deriving executable process descriptions from UML. In: Proceedings of the 24th international conference on software engineering. ACM Press, New York.

[AWN2004] Atkinson DC, Weeks DC, Noll J (2004) The design of evolutionary process modelling languages. In: Proceedings of the 11th Asia-Pacific software engineering conference. IEEE Computer Society, Washington DC.

[CJY1997] Chen JYJ (1997) CSPL: An Ada95-like, Unix-based process environment. IEEE Transactions

on Software Engineering .

[CW1999] Cook JE, Wolf AL (1999) Software process validation: quantitatively measuring the correspondence of a process to a model. ACM Transactions on Software Engineering and Methodology .

[BFG1993] Bandinelli S, Fuggetta A, Grigolli S (1993) Process modeling in-the-large with SLANG. In: Proceedings of the 2nd international conference on software process. IEEE Computer Society Press, Washington DC.

[SBC+2001] Sliski TJ, Billmers MP, Clarke LA, Osterweil LJ (2001) An architecture for flexible, evolvable process-driven user-guidance environments. In: Proceedings of the 8th European software engineering conference held jointly with 9th ACM SIGSOFT international symposium on foundations of software engineering. ACM Press, New York.

[JP200] Jalote P (2000) CMM in practice: process for executing software projects at information systems. Addison-Wesley, Los Angeles

[WL2001] Wang X, Leung HKN (2001) A benchmark-based adaptable software process model. In: Proceedings of the 27th Euromicro conference workshop on software process and product improvement. IEEE Computer Society, Washington DC.

[QXC+2003] Qiao B, Yang H, Chu W, Xu B (2003) Bridging legacy systems to model driven architecture. In: Proceedings of the 27th annual international conference on computer software and applications. IEEE Computer Society, Washington DC.

[CF2002] Conradi R, Fuggetta A (2002) Improving software process improvement. IEEE Software

[SEI2004] SEI (2004) 2004 Software Engineering Institute annual report.

[TMO1997] Tingey MO (1997) Comparing ISO 9000, Malcolm Baldrige, and the SEI CMM for software. Prentice Hall, New York

[BHR2005] Beecham S, Hall T, Rainer A (2005) Defining a requirements process improvement model.

Software Quality Control.

[WYY2004] Wu M, Ying J, Yu C (2004) A methodology and its support environment for benchmarkbased adaptable software process improvement. In: Proceedings of IEEE international conference on systems, man and cybernetics. IEEE Computer Society, Washington DC.

[FBV2004] Falbo RA, Borges LSM, Valente FFR (2004) Using knowledge management to improve

software process performance in a CMM level 3 organization. In: Proceedings of the 4th international conference on quality software. IEEE Computer Society, Washington DC.

[TH2003] Tianfield H (2003) An autonomic framework for quantitative software process improvement.

In: Proceedings of IEEE international conference on industrial informatics. IEEE Computer Society, Washington DC.

[GPR+2005] Garcia F, Piattini M, Ruiz F, Visaggio CA (2005) Maintainability of software process models: an empirical study. In: Proceedings of the 9th European conference on software maintenance and reengineering. IEEE Computer Society, Washington DC.

[JS2002] Jalote P, Saxena A (2002) Optimum control limits for employing statistical process control in software process. IEEE Transactions on Software Engineering.

[ JL2003]Jochen Ludewig, Models in software engineering, Springer-Verlag 2003

[ SH2003] Stachowiak, H. (1973) Allgemeine