EMPROSS Business Sectors
Business Development | more
Technology Development & Digitization | more
Green Development | more
Governmental Development | more
Strategic Development | more
Project Management and Innovation Services | more
Technocratic Enterprise Engineering | more
Research and Development | more


An Empirical Adjustable Software Process Assessment Model for Software Intensive Small and Medium Size Enterprises 

A software process assessment is a disciplined examination of the software processes used by an organization based on a process model.  The objective is to determine the maturity level of those processes, as measured against a process improvement roadmap.  The result shall identify and characterize current practices, identifying area of strengths and weaknesses, and the ability of current practices to control or avoid significant causes of poor (software) quality, cost and schedule.  The assessment findings can also be used as indicators of the capability of those processes to achieve the quality, cost and schedule goals of software development with a high degree of predictability.

A software process assessment aims in other words not to solve problems but to identify them.  The basic assessment objectives are: 

  • To learn how the organization works 
  • To identify its major problems 
  • To enroll its opinion in the process   

The assessment importance was clearly stated by John Gardner  when said that ‘most organizations are not suffering because they can’t solve their problems, but because they won’t see their problems’.  It is a common mistake of armature management to focus on finding solutions, failing to define the problems that caused them.  Dale Zand, a professor at NYU’s School of Business notes that when managers say ‘I don’t want to hear your problems, I want to hear your solutions’, they are taking the wrong approach . 

The whole assessment concept s based on a collaborative process towards software process improving and organizational improvement as a result.  

1. The Empirical Adjusted Software Process Assessment Model (ASPAM) 

After studying many SMEs, in Europe and in Greece in Particular, an empirical software process assessment model has been developed specifically for the needs of SISMEs.   This empirical model can be viewed and used as a key towards opening the software process improvement challenge for the SIESMEs. 

To describe better the key concept of this empirical methodology we use the key word ‘Adjustable’, to indicate that the assessment process can vary between organizations on the number of questions asked, the depth expected from each answer, the way a question will be asked (written, or verbally), and many other activities.   The goal is to make the assessed organization an ally by helping it overcome its doubt about the effectiveness of the assessment. 

2. Phases and Stages of the ASPAM

The Adjustable Software Process Assessment Method is composed of 10 phases:           

1) Initiate the Assessment

2) Documentation of the current practices

3) Evaluation of the Current practices documentation

4) Commenting the current Practices

5) Development of Improvement Points

6) Categorization of Improvement Points

7) Propose a SPI Plan

8) Review the proposed SPI Plan

9) Final Assessments Results and SPI Plan

10) Disseminate through the organization the Final Assessments Results and SPI Plan. 

3. Deliverables of the ASPAM

The implementation of each phase of the ASPAM creates activity documentation.  This documentation (doc), along with the documentation of the tools and techniques used to conduct the assessment is the total ASPAM deliverables.

ASPAM major documentation per phase

1.         a) Assessment Implementation Plan

            b) Introduction Training Material

2.         a) Current practices (anonymously) document.

            b) Consolidated Current practices (anonymously) doc.

3.         a) Review feedback doc. 

            b)  Modified Consolidated (anonymously) doc. (if needed)

4.         a) Comparison of current practices with best practices in the area (sector), with the best practices,

  with the international standards, and with the goals of the organization doc.

  b) Identification of success/failure implementation factors doc.

            c) Comparisons/causes for the maturity of each current practice doc.

5.         a) Improvement points doc. (for each improvement point with activities, implementation time, effort and cost).

6.         a) Dependencies among improvement points doc.

b) Hierarchy of improvement points (by dependencies, necessity, risk, cost, implementation time,

and implementation  effort)  doc.

7.         a) Most feasible SPI plan, by the management, doc.

            b) Most feasible SPI plan, by the assessor, doc.

8.         a) Improvement Points Ballot

            b) Most feasible SPI plan, by the assessed team, doc.

9.         a) Final SPI Plan doc.

10.       a) Dissemination (training) material doc.

The long deliverables list aims to document all the major activities of the ASPAM.  Dealing with SISMEs it is wise to have at hand documentation at any time. 

4. Conclusion 

Quality in software, and in IT systems in general, does not derive only form the large-scale organizations that sign the big and technologically impressive contracts.  Managing the subcontractors has always been an issue towards managing the quality and the control of a project.  Indeed the subcontracting management concepts have been given significant importance, and are considered as one of the key process areas in the CMMI Level 2 requirements . 

So far, managing the subcontractors, actually the SISMEs, is an issue of the larger organizations who can afford (financially and organizationally) the implementation of subcontracting management techniques.  ASPAM comes to reverse this quality seeking issue.  If the SISMEs have the ability to improve (at least up to one degree) their quality, then the effort made by the larger organizations to manage them, will be less and will increase the reliability and quality not only of the product developed but also of the collaboration between them as well.   On the other hand, there are SISMEs, not interested in subcontracting, but develop software for either their own smaller customers, or for internal purposes.    In any case SISMEs deserve a chance to look forwards towards their SPI with affordable, empirical and adjustable methods.  Models like ASPAM, can significantly contribute as start up tools towards Software Process Improvements in the Software Intensive Small and Medium Enterprises. 


For further information please contact us.