DOI: http://dx.doi.org/10.18180/tecciencia.2014.17.9

Functional Prototype of a Web Information System to Assist Planning Software Projects, Based on CMMI-DEV 1.2

Prototipo funcional de un Sistema de información web de ayuda a proyectos de software de planificación basado en CMMI-DEV 1.2

Javier Mosquera Díaz¹, Oscar Ocampo Cortés², Luz Stella García Monsalve³

¹ Escuela Colombiana de Carreras Industriales (ECCI), Bogotá, Colombia, ceo.anstek@gmail.com
² Escuela Colombiana de Carreras Industriales (ECCI), Bogotá, Colombia, andressocampocortes@hotmail.com
³ Escuela Colombiana de Carreras Industriales (ECCI), Bogotá, Colombia, lucesgarmon@hotmail.com

How to cite: Mosquera Díaz, J. et al., Functional prototype of a web information system to assist planning software projects, based on CMMIdev 1.2, TECCIENCIA, Vol. 9 No. 17, 67-77, 2014, DOI: http://dx.doi.org/10.18180/tecciencia.2014.17.9

Received: 16/Aug/2014 Accepted: 20/Sep/2014 Published: 30/Nov/2014

Abstract

This project addresses all the stages of the basic life cycle of the development of an Information System to plan software projects, bearing in mind the best practices model called Capability Maturity Model Integration - DEV 1.2 (CMMI - DEV 1.2) created by Carnegie Mellon University, at Pittsburgh, PA¹. The model offers a structure to improve development processes, besides the maintenance and acquisition of technology tools. One of the stages addressed by the CMMI second level maturity is called Project Planning (PP); this CMMI Process Area centers on establishing and maintaining the planning of the different activities of a project and, thus, permit MSMEs to repeat the success cases accomplished during prior developments, obtain a good Project Plan, adequately manage relationships with the people involved and finally achieve maintenance of the planning. Project Planning is indispensable for a company to start the path toward managing its processes with good execution practices; planning is considered one of the most important stages in developing a technological project. The MSMEs dedicated to software development and that want to add value to their processes and which work under the structure of a best practices model, must have these tools to improve the performance of their processes and optimize costs.

Keywords: CMMI, MSMEs, Planning, Software, Project.

Resumen

El proyecto relacionado en este artículo aborda todas las etapas del ciclo de vida básico del desarrollo de un Sistema de Información para la planificación de proyectos de software, teniendo en cuenta el modelo de mejores prácticas llamado Capability Maturity Model Integration - DEV 1.2 (CMMI - DEV 1.2) creado por la Universidad Carnegie Mellon de Pittsburgh Pensilvania, el modelo brinda una estructura para la mejora de los procesos de desarrollo, además del mantenimiento y adquisición de herramientas de tecnología. Una de las etapas que aborda el nivel de madurez 2 del modelo CMMI se llama Planificación de Proyectos (PP), esta área de proceso CMMI se centra en establecer y mantener la planificación de las diferentes actividades de un proyecto y así permitir a las MIPYMES repetir los casos de éxito logrados en desarrollos anteriores, obtener un buen plan de proyecto, gestionar de forma adecuada la relación con las personas involucradas y finalmente lograr la realización de un mantenimiento de la planificación. Planificación de Proyectos es indispensable para que una compañía inicie el camino hacia la gestión de sus procesos con buenas prácticas de ejecución, la planificación se considera una de las etapas más importantes en el desarrollo de un proyecto tecnológico; las MIPYMES que estén dedicadas al desarrollo de software, que quieran agregar valor a sus procesos y que trabajen bajo la estructura de un modelo de mejores prácticas, deben contar con estas herramientas para mejorar el rendimiento de los procesos y optimizar costos.

Palabras claves: CMMI, MIPYMES, Planificación, Software, Proyecto.

1 Introduction

For software developing MSMEs, the planning process is one of the most costly and time consuming stages when addressing a new project. Through new information technologies tools have been created to contribute to improve and organize the planning of new technology developments, but their high costs become a problem for the company.

Of all the market planning tools, few offer the possibility of planning a development project under a scheme of existing and guaranteed methodology to construct technology systems; this is why for an MSME starting a planning stage of a new project becomes lengthy and costly, to the point of making it necessary to adapt a development scheme offered by the market tools to the methodology elected by the business [1].

The project described herein shows the construction of a technological prototype that assists the planning process of MSMEs, allowing them to use Capability Maturity Model Integration (CMMI) in its second level of maturity and - specifically - in the Project Planning (PP) Process Area to save time and money, besides managing to adapt its processes to a development scheme recognized and successfully tested in the market.

2 Theoretical framework

Capability Maturity Model Integration (CMMI) is a maturity model to improve processes to develop products and services. [2]

2.1. Levels of CMMI analysis

2.1.1. Initial Level:
This level includes software developing enterprises that do not have specified processes or which have not been certified by CMMI due to diverse circumstances of the Project, like: development is not measurable, high budgets, delayed and lack of compliance with deliveries, lack of control during different states of said project.

2.1.2. Managed Level:
At this level, the project is managed and controlled during its development, besides offering transparency and the possibility of knowing status at any moment.

2.1.3. Defined Level:
At this level, the project - both in management as in development is established, documented, and has metrics to validate its results clearly and concisely, permitting to reach concrete and detailed objectives.

2.1.4. Qualitatively Managed Level:
The projects use measurable objectives to meet the needs of clients and the organization. Metrics are used to manage the organization.

2.1.5. Optimized Level:
Processes of projects and of the organization are aimed at improving activities. These are incremental and innovative improvements of the processes that through metrics are identified, evaluated, and placed into practice.

For an enterprise to establish itself in any of the maturity levels, it needs to closely comply with all the process areas of the level.

2.2. Process Areas
Each of the CMMI Process Areas lists a set of practices, which must be executed jointly to comply with the objectives proposed in the maturity levels.

The Process Areas are divided into generic goals (GG) and specific goals (SG), which are specific for the Process Area in question and are, in turn, divided into specific practices and generic practices.

Figure 2 presents the scaled representation of the model and seeks to explain the conception and distribution corresponding to the process areas.

The base process area for the research and development of the functional prototype is Project Planning (PP) of the second level of maturity, previously described.

2.2.1. Description of generic goals (GG).
Generic goals apply for all the Process Areas of the levels of maturity (in CMMI, second level of maturity). It can be noted in Figure 2 that generic goals are divided into generic practices and these are, in turn, aimed at the company's organizational and processes level [3].

According to the CMMI model in level 2 a generic goal (GG) permits institutionalizing the process managed.

2.2.2. Description of generic practices. These are global objectives traced, which must be complied in each of the Process Areas.

2.2.3. Description of the specific goals (SG). The specific goals describe each of the phases that correspond to the development of the Process Area.

2.2.4. Description of the specific practices: the specific practices describe each of the objectives of their Specific Goal in development.

2.3. Specific goals and Specific practices of PP [4]

2.3.1. SG1. Establish estimations:
The main objective of this Specific Goal is to assess the management of planning estimations; with this, the company is in the capacity to organize, coordinate and guide this important stage in projects.

Software engineering [5] establishes that within the planning stage, the factors used during the estimation are:

• Requirements of the project
• Reach of the project
• Methodology
• Chronogram
Specific practices of SG1:

• SP 1.1 Estimate the reach of the project
• SP 1.2 Establish estimations of attributes of work products and tasks
• SP 1.3 Determine the estimation of effort and cost

2.3.2. SG 2 Develop a Project Plan:
The main objective of this Specific Goal is to assess the creation and maintenance of a Project Plan for its integral management.

A Project Plan is a primary document used to manage and control the project's execution.

Specific practices of the SG2:
• SP 2.1 Establish a budget and a calendar
• SP 2.2 Identify risks of the project
• SP 2.3 Plan the Data Management
• SP 2.4 Plan Resources
• SP 2.5 Plan the need for knowledge
• SP 2.6 Plan involvement of interested parties
• SP 2.7 Establish Project Plan

2.3.3. SG 3.3 Obtain Commitment with the Plan:
The objective of this Specific Goal is to establish a structure that guarantees full commitment from the people involved in the Project Plan.

Specific practices of SG3:
• SP 3.1 Review plans that affect the project
• ·SP 3.2 Conciliate the level of work and resources
• ·SP 3.3 Obtain commitment with the plan

Agile Methodologies and CMMI:
CMMI proposes a WHAT to comply to develop a product with good practices that can be repeated project after project, while agile methodologies establish HOW to carry out the activities proposed by the model; these methodologies - for the most part - are used medium and small projects, which is ideal for MSMEs. [6].

The importance of planning in the development of a software project:

"Planning is highly important because it provides an integrating structure with the strategic and operational plans, besides determining the reach, competitive advantage, resource assignment, risks, technological factors, strategic objectives, and organizational environment."²

For software development, it is the most critical stage where the individual or people responsible for the theme are in charge of defining the project's activities, like:

• Determine resources
• Determine commitments
• Determine reach
• Analyze risks of the project
• Determine a Project Plan

3. State-of-the-art

In recent years, the Colombian government has given more importance to the software industry by making efforts for it to have a greater impact on the Colombian economy and so it can compete in the international market. According to the Colombian Federation of the Software Industry and IT (FEDESOFT), the Colombian market for software and information technologies (TI) registered 8% growth during 2011, with sales above US$280-million, reported by the 730 enterprises registered in the sector [7]. Government has created different certification programs in the CMMI maturity model to have more Colombian enterprises achieve said certification and, hence, more competitiveness in the market.

Tools and guides are required to facilitate understanding and development of the CMMI maturity model, given that it introduces different components that are not clear on the steps to follow. Additionally, in small companies it is difficult to develop the tasks of the model [1].

In Spain, the software industry is made up mostly by MSMEs, which seek a plus with their clients permitting them to grow and obtain higher benefits and gains. Most of them seek to focus on improving products to increase the quality and capacity of their processes to achieve their organizational objectives; these MSMEs are hardly ever CMMI certified because this requires high costs, large amount of time, physical resources, and human talent. [8]

The implementation process of the CMMI second level demands analysis in each of the stages of the process that fulfills the specific and generic goals of all the Process Areas of the second level of maturity; the initial verification stage permits identifying inconveniences of enterprises in developing software projects, which directly affect the quality of these developments and the costs of administration. Thereafter, a detailed study should be conducted of the maturity model and, thus, define the objectives of each Process Area, the tools and actions that will allow accomplishing each of the objectives. [9]

4. Procedure

Figure 3 shows an XP Methodological Scheme for the functional prototype of a web information system that assists planning of software projects, based on CMMI-DEV 1.2 and which was used in the project.

Project development was carried out in the following order:

4.1. Recognition of the problem in MSMEs

The MSMEs have become one of the most significant sectors at the production and development level for the nation; in Colombia, legislation 590 of 2000 issued to promote their development defines them as "Every unit of economic exploitation, carried out by natural or legal person, in entrepreneurial, agricultural, industrial, commercial activities or services, rural or urban"³.

Currently, this force of economic development is in a process of transition and growth in which it is constantly obligated to confront problems and challenges that are normally different to those faced by larger enterprises. Generally, MSMEs have reduced work groups, limited budgets, and information technology environments of lower complexity than their bigger counterparts; nevertheless, they are obligated to comply with the same standards and requisites as the large companies. They must optimize their levels of service, control costs, and adapt processes in their IT departments to the needs of the business to be aligned with market demands.

These software development MSMEs generally have processes to develop their objectives, policies, missions, and visions; however, they do not have organized each of the procedures that make up said processes and/or are not well defined, which makes repeating a success case in any of the projects they develop difficult and random.

This lack of organization and planning often increases budgets, hinders delivery of projects on established dates, increases overtime payments for employees, and impedes adequate control on the state of the projects

However, even with these limitations and/or lack of organization, the contributions made by MSMEs in the nation's economic development are recognized by government and higher education institutions, as well as by the macro level industrial sector, responding to these contributions through strategic alliances that permit supporting and projecting them toward a more precise growth objective, so that a transformation is accomplished in the growth model involving the competitiveness concept as an essential instrument to achieve success [10]. For this, continuous improvement models like CMMI exist.

4.2. Planning as integrating structure in Project Development

Considering that each of the SG - SP of the Process Area Project Planning (PP) of the CMMI maturity model-DEV 1.2, a modular scheme was designed that permits identifying the functionalities of the web system prototype; this scheme is shown in Table 1.

4.3. Integration of CMMI during the MSME planning stage through software engineering methodology

To implement the Web Information System prototype that assists software planning projects based on CMMI-DEV 1.2., the XP development methodology was used, given that it is rapid, efficient, and detailed in the different aspects of necessary requirements for any solution.

The XP methodology speaks of iterations, histories, and tasks, understanding the first as phases, the second as requirements, and the third as the activities that must be performed for each requirement [5].

4.3.1. Project management:

This initial phase makes a global approach of the project sought, introducing the needs and level of importance of each of the activities required.

4.3.1.1. Project Planning: this stage considers the needs and determines the different iterations to be developed.

• Initial planning: this stage will collect, analyze, and classify the information of the documentation of the CMMI DEV 1.2 maturity model. The initial ideas about the project will also be described, these ideas may include: review of the Process Areas that comprise the model's second level of maturity, detailed analysis of each of the generic goals and specific goals of the Process Area PP.

• Iterations: this presentation document will show a description of the histories carried out in this iteration, along with their functional tests, screen captures and, finally, the incidences occurring in this iteration.

• History: this level of the methodology will define the Histories or requirements belonging to each iteration or phase.

• Task: will be the different activities that will be performed to carry out a history.

4.3.2. Implementation:

The implementation process consists in carrying out each of the phases planned within the project management. Said phases address the themes related with the database, user interfaces, modulation of the system to be developed, and the different reports required to comply with that established in management.

4.3.2.1. Database:
Upon ending the development of each management item proposed, we must conduct tests of the development. The database must be included in planning the project management, given that it is indispensable to develop the Information System proposed.

• Planning: to develop the database it is necessary to know the different modules required to be implemented in the system to be developed; for this, we must know the different software requirements and the database engine that will be used.

• Implementation: the implementation process of the database includes the elaboration of the model-entity relationship, the necessary script necessary for the real creation of the repository, complying with all the characteristics identified in the MER proposed; lastly, from the implementation emerges the system's data dictionary, which must be included in the project's technical documentation.

• Tests: the tests of databases consist in identifying that the entities of the database created cover all the needs of the different requirements indicated for the project to be developed.

4.3.2.2. Development processes of interfaces:
To manage user interfaces, a modular diagram should be constructed of the system that permits identifying its navigation, the system's screens will be included in the documentation of the system's use, which explains how each screen functions.

• Planning: planning the project's interfaces generates, as a result, the modular diagram of the system, permitting knowledge of its navigation; besides, offering a greater perspective of the input information necessary for the system's correct operation.

• Implementation: upon implementing the user interfaces, bear in mind that the fields must comply with all the characteristics related to the information that will be captured; these should also be constructed intuitively for the user, avoiding confusion in the use of the interfaces.

• Tests: to conduct the tests of the interfaces, it is necessary to validate that each of the screens constructed complies with the requirement for which it was created, besides validating the correct input of the information and that it operates correctly the processes it should fulfill; this information can be included in written records.

4.3.2.3. Elaboration of the source code: to develop the source code, different writing standards must be defined, permitting to identify the structure of the code's comments, the structure of functions, methods, variable classes, etc., which will also facilitate a correct programming practice in the system's development equipment.

4.3.3. Tests:
The process of tests consists in complying with the test schemes for each of the modules planned. These are general tests for the whole system.

5. Results and development of a functional prototype

As a result, we present the different modules that comply with the SG and SP of the CMMI's Process Area PP. These modules are reflected on the web system in the following user interfaces:

5.1. Management of types of product and life cycle:

To design a standard and reusable structure applicable to each project regardless of its size, we considered the different types of products, methodologies, and life cycles a project can have according to its nature.

5.1.1. Types of Product:
The types of product mean in this project nothing more than the different products and services a software developing company offers to its clients. Each type of product has defined size and nature, which are administered in the prototype according to the criterion of each enterprise or user.

5.1.2. Life cycle of the product:
The product's life cycle defined in the prototype serves to detail each of the stages that must be fulfilled in each of the types of products the company has. The cycle, type of delivery, and deliverable document are defined for each type of product.

The type of delivery emphasizes on whether the stage of the cycle is developed to comply with a single stage of the type of product or of the methodology associated.

5.1.3. Methodologies:
This functionality serves to obtain information from the different methodologies used in the company. Each of them has a name and a reference file that can be consulted as knowledge management and institutionalization of the process.

5.2. Management of Estimations:

The start of the project's management of estimations was done with a model that permits managing their definition, in legal, development, and requirement aspects. This model is associated to each project and it is easily administrated and configured in the prototype; this indicates that it is not obligatory to input all the information, given that according to the project's size or nature this may not be necessary.

5.2.1. General information of the project:

The model created to manage the definition of the project comprises the project's general data, additional data, objectives, general requirements, legal aspects, contractual issues, and restrictions.

• General data: obtains information like the code, name, and client, type of product, starting date, and delivery date of the project.

• Additional data: estimated cost, real cost, estimated time in hours, real time in hours, methodology associated to the type of product, and an option for the user to choose to control costs and times of the project. The system's real cost and the real time is calculated according to the activities programmed in the WBS. If the prototype's user chooses to control costs and times, the system issues a warning and will not permit assignment of activities from the WBS, physical resources, and human talent that surpass the estimated cost. This will allow users to focus the assistance structure based on the size of the project to economic level.

• Charter: for the information on the project's charter, an option was developed in the system that permits associating onto the project: Objectives, General requirements, Legal aspects, Contractual issues, and Restrictions.

5.3. Reach of the project:

The estimation of the reach of the project was designed in the system through a Work Breakdown Structure (WBS). This structure permits managing the different phases, activities, tasks, and calendar of the project.

5.3.1. Phases:
Obtains information like the code, name, interested party, individual responsible, and description of the phase.

5.3.2. Activities:
Obtains information like parent phase, code, name, individual responsible, description, and reach of the activity.

5.3.3. Tasks: Tasks:
Obtains information like parent phase, parent activity, code, name, initial date, final date, predecessor task, progress, priority, if the task is a milestone, observations, and individual responsible. Upon defining the task starting and finishing dates, the system calculates this time and compares it against the estimated time placed in the project's definition. If the user chose to control times and surpasses the estimated time, the system will not permit creating the task and emits a warning.

• Calendar: a Gantt-type calendar is presented in structured manner according to the task starting and finishing dates.

5.4. Resource model and Communications:

The resource model presented by the system is designed in two parts: configuration of resource information per enterprise and their aggregation into the different projects, in the phases, activities and tasks of the WBS to determine the duration of the project and the cost of each resource.

5.4.1. Configuration of resource information

• Human talent: information is obtained on the name, document, hourly rate, and skill profile. The skill profiles associated provide essential information to add the resource to a project, among the skill profiles we can have: Project Manager, Development Engineer, Support Engineer, etc.

• Physical resources: information is obtained on the name of the technical resource and hourly depreciation rate.

• Working days and holidays: information is obtained of the working days in the company, as well as the number of hours per day, information should also be obtained of holidays with their respective dates and names.

5.4.2. Aggregation of resources to different projects

• Human talent: from the human talent configured, a list is deployed to assign the human talent in the project. The human talent aggregated to the project remains available to assign it to the WBS.

• Physical resources: from the physical resources configured, these same are assigned; users can assign the amount of each resource.

• Working days: permits modifying, per project, the hours to work per day.

5.4.3. Project Communication Model:

The communication model presented in the prototype is constructed dynamically according to the assignment of human talent within the WBS. The principle of communication is given in the following manner:

• The person responsible for the task has direct communication with the individual responsible for the activity associated, and has no direct communication with those responsible for other activities, responsible for the phase and responsible for the project.

• The person responsible for the activity has direct communication with those responsible for the tasks associated to the activity and with the person responsible for the phase, and has no direct communication with the person responsible for the project.

• The person responsible for the phase has direct communication with those responsible for the activities associated to the phase and with the person responsible for the project, and has no direct communication with those responsible for the tasks of the activities of the phase.

5.5. Risk management:

The risk management scheme in the prototype was designed considering that these must be analyzed and identified to be kept in mind when planning the project.

Bearing in mind that performing the risks at the level of detail of each of the tasks, these would be risks in development and phase level these would be very general, it was decided in the prototype to define risks by activities defined during planning.

A risk can have many causes; one cause can have many prevention controls and these, in turn, must be included within the work plan; additionally, a cause can have many correction controls.

Risk management in the prototype is carried out in the following manner: Record of the different risks, causes associated to a risk, and correction and prevention controls associated to the causes and a consultation interface of the risks matrix.

5.5.1. Project Plan:

The prototype has as final module the presentation of a report module from which each of the characteristics planned can be printed in it, making up what is called the Project Plan.

6. Conclusions

• The exploration conducted on the continuous maturity model improvement (CMMI) reveals that said standard is broadly supported at the international level; besides, the Colombian government is quite interested in having enterprises adopt it and gain competitiveness with it, which is why this project's theme will be of interest among the IT community.

• Use of software tools that help an MSME to work its processes based on the CMMI maturity model accomplishes the objective of raising awareness of the good practices and of their use in the company to improve it processes, but this certification process continues being a long and difficult path to reach.

• Construction of the functional prototype manages to define a standard of good practices for each enterprise in the MSME category, given that with said prototype we can adopt and register the good practices obtained with the execution of different projects throughout its existence. Because it is constructed under CMMI, it allows for the good practices adopted during project execution to be reused in new developments of equal magnitude and similar characteristics, turning the execution stage into an activity of continuous improvement due to proper management when planning the execution of each new solution to cover the needs of clients.

7. Future work

The maturity model in its level 2 comprises seven process areas, of which in this project emphasis was made on Project Planning; for future work, we recommend developing tools that complement the remaining six process areas and benefit MSMEs with a product that covers the totality of the level of maturity managed.

Notes

References

[1] A. Alvarado, J. Luna y O. Najar, «Sistema ultiagente para autoevaluación con fines de certificación en CMMI,» Revista Avances investigación en ingeniería, vol. 6, nº 10, pp. 90-101, 2009.         [ Links ]

[2] M. Chrissis, M. Konrad y S. Shrum, CMMI: Guía para la integración de procesos y la mejora de productos, Madrid: Pearson Eduación S.A., 2009.         [ Links ]

[3] «Tecnologías de las Información al servicio de sus ideas.,» Comex TIC, Solluciones de negocio., [En línea]. Available: http://www.grupocomex.com/areas-de-proceso-CMMi.aspx.         [ Links ]

[4] «Software- Quality- Assurance.org. CMMI- project Planning (PP),» [En línea]. Available: http://www.software-quality-assurance.org/cmmi-project-planning.html.         [ Links ]

[5] I. Sommerville, Ingeniería del software. Septima Edición., Madrid: Pearson Education. S. A., 2005.         [ Links ]

[6] H. Glazer, J. Dalton, D. Anderson, M. Konrad y S. Shrum, «CMMI or Agile: Why not embrace Both!Tehnical Note.,» Software Engineering process management, Pittsburgh, 2008.         [ Links ]

[7] Fedesoft, «Hacia donde va la industria del software,» Fedesoft, [En línea]. Available: http://fedesoft.org/novedades/hacia-donde-va-la-industria-del-software.         [ Links ]

[8] J. M. Navarro y J. Garzás, «Experiencia en la implantación de CMMI-DEV v1.2 en una micropyme con metodologias agiles de software libre,» Revista española de innovación, calidad e ingeniería de software, vol. 6, nº 1, pp. 6-16, 2010.         [ Links ]

[9] N. Villegas, G. Tamura y C. Picazzo, «Análisis descriptivo del proceso de implementación del nivel 2 del modelo CMMI en una empresa regional de desarrollo de software,» Sistemas y Telemática, vol. 6, nº 12, pp. 89-109, 2008.         [ Links ]

[10] D. Villegas y I. Toro, «Las pymes: una mirada a partir de la experiencia académica del MBA,» Revista MBA EAFIT, pp. 86-101, 2010.         [ Links ]