State of the Art
In general, software process improvement (SPI) approaches are either inductive (bottom-up) or prescriptive (top-down) [1]. On the one hand, inductive approaches, such as the Basili’s Quality Improvement Paradigm [2], start by identifying and understanding the most critical processes in a software organization which are required to be improved. Improvement goals are, consequently, set and the process improvement is realized by a pilot project. However, inductive approaches have been criticized that they are applicable only when the organization processes are characterized by an adequate level of maturity [3]. One the other hand, prescriptive approaches, such as the Capability Maturity Model Integration (CMMI) [4] and ISO/IEC 15504 (also known as SPICE) [5], follow the “one size fits all” paradigm. They define sets of best practices (Key Process Areas) which are required to be evaluated, regardless the characteristics or the needs of an individual software organization under assessment. A prescriptive approach supports the benchmarking of an organization’s processes against these practices. A typical software process assessment/improvement project according to a prescriptive approach often demands large amount of resources and investment costs. For example, it can last between 18 and 24 months [6] and, thus, the SPI project imposes time and resource constraints which are difficult to be met by a small or a medium sized SW enterprise.
To meet the above problems, in the relevant literature, the so called “lightweight” SPI approaches have been proposed [1, 7]. A lightweight approach does not require extensive resources to be deployed in the SPI project and allows the flexible consideration of certain process areas which are the most critical for a specific organization (e.g. Project Management, Requirements Engineering, Testing, etc.).
However, a practical problem that remains open in most SPI approaches is that their application focuses mainly on providing answers on “what a software company should perform in order to improve its processes” and not on “how a software process improvement project will be conducted” [6]. To get answers in the second question the relevant literature proposes a number of process modeling approaches and process analysis/assessment techniques. The objective of a process modeling approach [e.g., 8, 9] is, first of all, to get an understanding of the current (as-is) process and then to propose a process redesign (to-be process) that will be more effective and efficient than the current one. The aim of analysis/assessment techniques is to perform measurements/estimations for the budget, time, scope and resource requirements of the SPI project and analyze the project results (success factors) with respect to the initial project objectives [10, 11].
In particular, the following success factors have to be considered when performing a SPI project [12]:
(i) the cost of initiating the SPI project (SPI initiation threshold), in terms of resource/time constraints,
(ii) the degree of commitment/involvement of the organization members of personnel (top management, middle management and development staff), in order to ensure the wide acceptance of all required process changes, and
(iii) the degree that the SPI project will support the time planning of the improvement activities, as well as the risk estimation/analysis of the possible SPI project failures.
In a previous research project supported by the ARCHIMEDES II Research Program (the project was called MISSION SMP – Model based Integrated Environment to Support Simulation in Software Project Management) our research efforts have been mainly concentrated on process modeling approaches [13], 14, 15]. The current project (SPRINT SMEs) will give us the opportunity to continue our research efforts and cooperation towards the definition of a unified and practical framework that will support the systematic application of robust software process analysis techniques. SPRINT SMEs will particularly emphasize on supporting the assessment of the above SPI success factors mainly in the context of Requirements Engineering (RE) improvement projects (SPIRE projects). RE is a crucial process in software development that in contemporary software life-cycle models has to be applied repeatedly in all phases of the software life-cycle to ensure that the final software product will meet the end-customer needs [16]. Empirical research shows that more than 60% of software projects present failures because they do not adopt a systematic RE process [17]. Such a process has to follow a set of activities (e.g., requirements elicitation, requirements analysis/specification, requirements validation, requirements documentation, risk analysis, cost estimation as well as requirements management) and its systematic application influences positively the technological/managerial maturity of software products and, consequently, increases the organization competitive advantages.
The main source for RE difficulties arises from the distinctive “nature” of the RE process compared to other Software Engineering (SE) processes [18]. RE focuses on the (large) problem space area, by defining the problem that is to be solved by a software system, while other SE processes emphasize on the (more limited) solution space area, by defining/implementing/testing the behavior of a software system. RE starts with analyzing an ambiguous problem description and defining the system environmental conditions, and must, finally, result in a concrete technical solution that is amenable to implementation. However, the conditions in the environment of a software system can be various, complex and unconstrained and thus, the complexity of RE tasks grows significantly. The intrinsic limitation of human information processing and obstacles in interaction/mutual understanding between designers and multiple stakeholders also make RE an inherently difficult process. RE should emphasize on reconciling the relationships between non-technical staff (customers/end-users) and technical staff, gaining involvement from all parts and providing results (requirements artifacts) which are understandable and useful to all.
