Content uploaded by Hanna Oktaba
Author content
All content in this area was uploaded by Hanna Oktaba on Feb 23, 2015
Content may be subject to copyright.
Available via license: CC BY 4.0
Content may be subject to copyright.
From MoProSoft Level 2 to ISO/IEC 29110 Basic Profile:
Bridging the Gap
Miguel Morales Trujillo
1,2
, Teresa Ventura
2
, Hanna Oktaba
1,2
and Rodrigo Torres
3
1
Graduate Science and Engineering Computing, National Autonomous University of Mexico
Mexico City, Mexico
{migmor, hanna.oktaba}@ciencias.unam.mx
2
General Direction of Computing and Information Technologies and Communication,
National Autonomous University of Mexico
Mexico City, Mexico
tventura@unam.mx
3
INNEVO
Mexico City, Mexico
rtorres@innevo.com
Abstract. The spread of the interest and the need for process reference models,
specifically for small and medium software development organizations, has
been a catalyst for generating ISO/IEC 29110 Software Engineering —
Lifecycle profiles for Very Small Entities. Based on the Mexican standard
NMX-I-059-NYCE-2005, better known as MoProSoft, ISO/IEC 29110 is the
first international standard specifically designed for very small entities.
Thanks to the COMPETISOFT Project and MoProSoft, the background
knowledge and models adoption experience have been introduced in Latin
America. In Mexico more than 300 organizations have been evaluated in NMX-
I-059-NYCE-2005, and in 2009 MoProSoft became a national standard in Peru.
As a whole, it gives small software development organizations in the region an
advantage in adopting an international standard.
This paper clarifies the gap between ISO/IEC 29110 and MoProSoft level 2. As
a result of a theoretical and practical review both standards were mapped,
coverage between them was defined and some recommendations were
suggested to adopt the Basic Profile of the new international standard starting
from the Mexican standard.
Keywords: ISO/IEC 29110, MoProSoft, gap, coverage, adoption, very small
entities.
1 Introduction
The increase of the processes capabilities of a software development organization is
regularly guided by a process reference model, for that reason the models should be
attached to the environment and maturity of the organization.
The need for process reference models, specifically those designed for small and
medium organizations, aroused the creation of standards that would fit the particular
environment and accomplish objectives of those organizations.
MoProSoft [1], a process reference model developed in Mexico, is one of the first
widely known efforts, and then comes its offspring COMPETISOFT [2], generated by
the Latin American organizations and research groups, thus bringing to the region a
culture of models adoption and increasing competitiveness.
Those attempts were taken into account by Working Group 24 (WG 24) of
ISO/IEC [3], who focused on creating an international standard for very small entities
ISO/IEC 29110 [4], based on the experience acquired from developing MoProSoft.
Considering the common origins, the similarity of the target audience and
objectives that pursue both standards, a mapping between the ISO/IEC 29110 Basic
Profile and MoProSoft was carried out and presented in this work. One of our main
concerns was the question: What is needed to be done or improved in order to achieve
ISO/IEC 29110 Basic Profile if the organization has already adopted MoProSoft level
2?
Finding a clear answer to this question would be a step forward in motivating
MoProSoft evaluated organizations to also obtain international recognition adopting
ISO/IEC 29110. This work was done by the UNAM specialists in software process
together with consultants from INNEVO [24] who have experience in the adoption of
the Mexican standard and an expert involved in the development of both standards.
This paper is organized as follows: in part 2 we present the Mexican standard for
software industry MoProSoft, part 3 shows the origins and structure of ISO/IEC
29110. Later, in part 4 the mapping between standards is presented; part 5
concentrates and interprets the results and in part 6 we present our answer to the
question. Finally we conclude.
2 MoProSoft
In 2002 the Ministry of Economy in Mexico [5], launched a call for proposals to
create a process reference model that would accumulate up-to-date sets of best
practices in the industry of software development of the country.
The proposal was developed together with the National Autonomous University of
Mexico (UNAM) [6], the Mexican Association for the Quality in Software
Engineering (AMCIS) [7] and the Ministry of Economy, under the coordination of
Hanna Oktaba, a coauthor of this paper.
At the beginning of 2004 the process reference (MoProSoft) and evaluation
(EvalProSoft) [8] models were defined and by mid 2004 the controlled testing of both
models started.
The controlled testing objective was to demonstrate the feasibility of increasing
process capability levels of a software development organization in a short period of
time. The group of study was composed of four organizations, each made up of about
18 members.
The average starting process capability level of the organizations was 0.13 and at
the end of the test resulted in 1.19, achieving these results in eight months. By the end
of the testing period, each organization got to level 1 of MoProSoft, similar to
maturity level 2 CMMI [9].
By the third quarter of 2005 MoProSoft was turned into the Mexican standard
NMX-I-059-NYCE-2005 – Information Technology – Software – Development and
Maintenance Process Reference Model and Evaluation Model [10]. This Mexican
standard is composed of four parts:
• Part 01 Concepts and products definition
• Part 02 Process requirements (MoProSoft)
• Part 03 Process implementation guidelines
• Part 04 Evaluation principles (EvalProSoft)
The normalization work was strictly coordinated by the association of Electronics
Standardization and Certification (NYCE) [11].
The MoProSoft process model consists of three layers or categories:
• High Management: contains the Business Management process.
• Management: composed of the Process Management, Projects
Management and Resources Management processes.
• Operation: includes the Specific Project Management process (SPM),
Software Development and Maintenance process (SDM).
The three-layer approach reflects the structure of majority of software development
organizations in Mexico. Consequently by the end of 2010 more than 300
organizations in Mexico were certified under NMX-I-059-NYCE-2005.
This work targets mainly the Operation layer, which contains core processes, due
to their critical importance for software development organizations.
2.1 MoProSoft in Latin America
In Latin America the Mexican standard gathered momentum when the Ibero-
American Program for Science, Technology and Development (CYTED) [12],
granted the project COMPETISOFT: Process improvement to enhance the
competitiveness of small and medium organizations in Latin America [2].
COMPETISOFT defined three objectives: (i) To create a common methodological
framework in Latin America. (ii) To spread the process culture into the researchers,
academics and students communities. (iii) To influence in the standardization and
certification entities, in order to establish a common and mutually recognized
mechanism [2].
Initially MoProSoft provided a base for COMPETISOFT which turns out expanded
and enhanced. The main improvements were the incorporation of the Software
Maintenance agile process [13] to the Operation layer, along with the inclusion of the
experience and viewpoints of 13 countries and 23 research groups.
Another effort was made in Peru, where National Institute for the Defense of
Competition and Protection of Intellectual Property (INDECOPI) [14] developed a
technical standard based on MoProSoft, the Software Engineering: Software
Development and Maintenance Process and Evaluation Models NTP 291.100:2009
[15]. The Peruvian standard was published in 2009.
2.2 Colored Version
After the publication of the Mexican standard, a colored version of MoProSoft was
presented [16]. In that version each task and work product is colored according to
their capability level, see Table 1, in order to facilitate their understanding and clarify
their scope.
The capability levels of the processes are defined according to the Mexican
standard NMX-I-006/02-NYCE-2004 Information Technology – Process Assessment –
Part 02: Realization [17], which in its turn is based on the international standard
ISO/IEC 15504-2: 2003 Information technology – Process assessment – Part 2:
Performing an assessment [18].
Table 1. ISO/IEC 15504-2:2003 capability levels and their corresponding colours.
ISO/IEC 15504
-
2:2003
Capability Levels
Level
Level Name
Assigned
Color
5
Optimizing process
Clear
4
Predictable process
Pink
3
Established process
Green
2
Managed process
Blue
1
Performed process
Yellow
0
Incomplete process
Not used
In this work the colored version was used to define the capability level of an
organization, in this case we took into account the tasks and work products
corresponding to MoProSoft level 2, that is to say, all yellow and blue tasks and work
products were considered for the mapping.
3 ISO/IEC 29110
In 2005 the Subcommittee 7 [19] of ISO/IEC Joint Technical Committee 1 decided to
start a new project with the objective of creating an international standard addressed
to the Software Life Cycle Profiles and Guidelines to be used in Very Small Entities
(VSEs), organizations with less than 25 employees.
For that purpose WG 24 was created taking charge of a new project under the
coordination of Tanin Uthayanaka from Thailand [19]. Having identified problems
that affect small organizations, WG24 defined a set of objectives for the group to
achieve by implementing the new project of standard, ISO/IEC 29110 Software
engineering — Lifecycle profiles for Very Small Entities (VSEs) [4].
The first meeting of WG24 took place in Thailand in 2006, and was attended by
the United States, India, Ireland, Belgium, Finland, Luxembourg, Canada, New
Zealand, South Korea and Mexico. During the meeting the group made the decision to
take the Mexican standard as a basis for their work [20].
The ISO/IEC 29110 standard is composed of five parts arranged into three groups,
being this the family of documents:
• Overview
o Part 1 Overview
• Profiles
o Part 2 Framework and Taxonomy
o Part 4 Specifications of VSE Profiles
• Guides
o Part 3 Assessment Guide
o Part 5 Management and Engineering Guide
Overview presents the main concepts to gain a better understanding and to make
use of the documents of the standard.
Profiles are defined with the purpose of concentrating the essentials of the rest of
the documents, in order to be tailored to organization’s needs and characteristics.
The Framework and Taxonomy part specifies common elements of each defined
profile, while Specifications of VSE Profiles lays down the components and structure
for each created profile.
The Guides part defines applying principles to develop an assessment in order to
determine the processes capability and maturity of the organization, in Assessment
Guide. Also Management and Engineering Guide offers orientation about the use and
implementation of each profile.
At the moment, part 5 for Basic profile of the Generic profiles group is published.
Other three generic profiles: Entry, specific for startup entities; Intermediate and
Advanced are under development. The scope of this work is centered on Basic
Profile.
3.1 Basic Profile
Basic Profile was published in May 2011, known as ISO/IEC 29110-5-1-2 [21],
where digit 1 means that it is a generic profile, and digit 2 represents a consecutive
number. Previous to the Basic Profile comes the Entry Profile therefore getting
number 1.
The rationale of Basic Profile is to define a software development and project
management guide for a subset of processes and outcomes of ISO/IEC 12207 [22] and
products of ISO/IEC 15289 [23], appropriate for characteristics and needs of VSEs
[21].
Basic Profile describes a software development of a single application by a single
project team with no special risk or situational factors. This kind of project may be
carried out to fulfill an external or internal contract [21].
Software Implementation (SI) and Project Management (PM) are the two processes
that compose Basic Profile. The reason to include PM is that VSEs’ core business is
software development and their financial success depends on project profits [21].
The PM process input is the customer’s Statement of Work, used to create Project
Plan. The execution of the SI process is driven by the Project Plan. The PM Project
Assessment and Control activities compare project progress against the Project Plan
and actions are taken to eliminate deviations or incorporate changes into it. The PM
Project Closure activity delivers Software Configuration, produced by SI, and gets the
customer’s agreement to formalize the end of the project. A project repository is
established to save work products and to control their versions during the project.
The purpose of the PM process is to establish and carry out activities of SI process
in an efficient way, which allows fulfilling the project’s objectives within the
expected quality, time and costs. The purpose of the SI process is to define a
systematic performance of the Analysis, Design, Construction, Integration and Tests
activities for new or modified software products according to specific requirements.
4 Mapping ISO/IEC 29110-5-1-2 and MoProSoft
The mapping was made taking into consideration an organization evaluated in
MoProSoft level 2 and asking oneself: What is needed to be done or improved in
order to achieve ISO/IEC 29110 Basic Profile if the organization has already adopted
MoProSoft level 2?
Finding the proper answer will clarify the gap and ease the transition between
standards, providing the organization with benefits of international recognition.
Therefore, the tasks and work products of each process of ISO/IEC 29110-5-1-2
were faced against the tasks and work products of the equivalent process in
MoProSoft, as shown in Table 2.
Table 2. Equivalence between processes involved in the mapping.
MoProSoft
ISO/IEC 29110-5-1-2
Specific Project Management (SPM)
Project Management (PM)
Software Development and
Maintenance (SDM)
Software Implementation (SI)
For consistency and simplicity reasons, the acronyms used to refer to each task
were taken considering notations used in each standard, see Table 3. It is important to
note that, according to the table above, it is possible to use the same acronym for both
types of tasks in the Mexican standard, since a task from PM is always mapped
against a SPM task, and a task from SI, if mapped, will always be against SDM.
Table 3. Acronyms used to refer to each task.
MoProSoft ISO/IEC 29110-5-1-2
Specific Project Management
A#.#
Project Management PM.#.#
Software Development and
Maintenance
Software Implementation SI.#.#
Alongside with the task mapping, mapping corresponding to work products was
carried out.
4.1 Metrics
The capability ratings defined in ISO/IEC 15504-2:2003 [18] were used to determine
the Coverage values essential for this work, see Table 4, with the aim of defining the
Coverage level (C). Then a Score was associated to each C value, which in its turn is
used to define the Quantitative level (Q).
Table 4. ISO/IEC 15504-2:2003 Capability ratings and scores assigned.
ISO/IEC 15504
-
2:2003
Capability Ratings
Rating
Coverage
level
Percentage
Score assigned
1
Totally
(T)
85
-
100%
1.0
2
Largely (L)
50
-
85%
0.7
3
Partially (P)
15
-
50%
0.3
4
Not achieved (N)
0
-
15%
0.0
The C and Q values apply for tasks (C
T
or Q
T
), work products (C
W
or Q
W
) and
process (C
P
or Q
P
).
For example, the C
T
value of the task SI.3.5 is obtained like that:
(
)
SI.3.5 L
T
C
=
And the Q
T
value for the same task as follows:
(
)
(
)
(
)
SI.3.5 L 0.7
T T T
Q C Q= =
The C
W
and Q
W
are calculated in the same way.
The Q
P
is calculated by the sum of each of the quantitative levels of the process
tasks divided between the total num of the process tasks:
( )
(
)
(
)
_
T T i
P
Q C T
Q process acronym
T
=
∑
Where T is the set of tasks, and each T
i
is a task of the process, for example:
( )
36.9
SI 0.9
41
P
Q = =
Finally, the C
P
can be calculated using the Q
P
value and the values of Table 4,
then:
(
)
SI T
P
C
=
Those values are used to clarify the gap between standards, and are presented in
the Numerical results section.
4.2 Coverage Rules
The coverage rules that guided the mapping are based on the interpretation of written
texts of each standard, their inputs and outputs as well as general objectives.
All compared tasks were considered equal; so to say we assumed that they require
the same amount of effort, time and resources to be fulfilled. That is why it is crucial
to emphasize that the coverage values obtained after applying those criteria may not
match those applied by an accreditation body during an assessment process. Each of
the coverage rules were detailed for Tasks and Work Products.
4.2.1 Tasks
A task from ISO/IEC 29110-5-1-2 is considered totally covered if there exist one or
more tasks from MoProSoft that fully accomplish its purpose, an example is shown in
Table 5. The first column presents the task to cover; the second column shows the
task that covers it; the third one includes Quantitative level and the last one Coverage
level. In the example below, the task SI.5.4 of ISO/IEC29110-5-1-2 is totally covered
by the task A5.6 of MoProSoft.
Table 5. Example of a totally covered task.
ISO/IEC 29110-5-1-2 MoProSoft Q C
SI.5.4 Perform software tests using Test
Cases and Test Procedures for integration
testing and document results in Test
Report.
A5.6 Execute the system
testing according to
System Test Plan,
document the results in
System Test Report.
1.0 T
A task is considered largely covered if there exist one or more tasks that cover a
part of it. The effort needed to fill in the gap is taken into account, based on the
recommendation to achieve the totally covered qualification. Table 6 shows a largely
covered task. In this example the task PM.1.14 of ISO/IEC29110-5-1-2 is largely
covered by the task A1.16 of MoProSoft. The gap between this task and the required
by the international standard could be closed if the Recommendation is observed.
Table 6. Example of a largely covered task.
ISO/IEC 29110
-
5
-
1
-
2
MoProSoft
Q
C
PM.1.14 Review and accept
Project Plan
.
Customer reviews and accepts Project
Plan, making sure that the Project Plan
elements match Statement of Work.
A1.16 Validate Project
Plan and Development
Plan.
0.7 L
Recommendation
MoProSoft
does not mention
that
Client
has the responsibility to accept or reject
Project Plan, for this reason it is necessary to agree previously with the Client on its
acceptance.
A task is considered partially covered if there exists a task that tries to cover it, or
if its objective is achieved in a clear way by the execution of the whole process. Table
7 gives an example of a partially covered task. In this case the task SI.3.2 of
ISO/IEC29110-5-1-2 is partially covered, the reason is that it results obvious that an
understanding of requirements is executed, in some way, by the organization, whether
the Mexican standard specifies it or not.
Table 7. Example of a partially covered task.
ISO/IEC 29110
-
5
-
1
-
2
MoProSoft
Q
C
SI.3.2 Understand
Requirements
Specifications.
- 0.3 P
Finally, a task is not achieved if there does not exist a task with the same or similar
objective. In this case the task will have to be done entirely on its own, in order to
implement the standard. Table 8 shows a not achieved task.
Table 8. Example of a not achieved task.
ISO/IEC 29110
-
5
-
1
-
2
MoProSoft
Q
C
PM.1.10 Document the
Version Control
Strategy in the Project Plan.
- 0.0 N
4.2.2 Work Products
A work product is an artifact generated while executing a task or a set of tasks. Both
standards include a section that lists each work product and their characteristics. The
MoProSoft’s sections are: Inputs, Outputs and Intern Products, while the
ISO/IEC29110-5-1-2’s section is: 9. Product description.
For the purpose of this work, these sections were taken as guidelines for the
mapping and scope limits. We applied the same rules of coverage defined for the
tasks.
5 Numerical Results
This section displays numerical values obtained from tasks and work products
mappings. Finding the answer to the initial question What is needed to be done or
improved in order to achieve ISO/IEC 29110 Basic Profile if the organization has
already adopted MoProSoft level 2? we will use the values Q and C, explained
earlier.
5.1 Values Obtained for Quantitative and Coverage Levels of Tasks
ISO/IEC 29110-5-1-2 presents 26 tasks in the PM process, 18 of them are totally
covered by MoProSoft, 3 are largely covered and 5 are not achieved. The Q
P
of PM
process is 0.77, obtained from:
( )
(
)
(
)
(
)
(
)
18 1.0 3 0.7 0 0.3 5 0.0
20.1
PM 0.77
26 26
P
Q
× + × + × + ×
= = =
The SI process has 41 tasks defined, 34 are totally covered by MoProSoft, 2 are
largely covered, 5 partially covered and none is not achieved. The Q
P
of SI process is
0.9, detailed as follows:
( )
(
)
(
)
(
)
(
)
34 1.0 2 0.7 5 0.3 0 0.0
36.9
SI 0.90
41 41
P
Q
× + × + × + ×
= = =
Consequently Table 9 demonstrates a summary of values obtained from mapping
the tasks.
Table 9. Mapping results.
ISO/IEC
29110-5-1-2
Processes
Tasks Score Q
P
Totally
covered
Largely
covered
Partially
covered
Not
achieved
PM 26 20.1 0.77 18 3 0 5
SI 41 36.9 0.90 34 2 5 0
Total 67 57.0 0.85 52 5 5 5
We can conclude that an organization evaluated in MoProSoft level 2 covers 85%
of tasks defined in ISO/IEC 29110-5-1-2. It is viable to bridge the gap between both
standards, for the sake of total tasks coverage, by following the suggestions given in
the section Bridging the Gap.
5.2 Values Obtained for Quantitative and Coverage Levels of Work Products
ISO/IEC29110-5-1-2 defines 22 work products, 20 are totally covered by the work
products defined in MoProSoft, one is largely covered and one is not achieved. Not
totally covered work products are demonstrated in Table 12 below.
The Q
W
value that involves all the work products was calculated as follows:
( )
(
)
(
)
(
)
(
)
20 1.0 1 0.7 0 0.3 1 0.0
20.7
PM SI 0.94
22 22
W
Q
× + × + × + ×
∧ = = =
6 Bridging the Gap
We should note that only tasks and work products qualified less than totally covered
will be presented, taking into account all those qualified as largely, partially or not
achieved.
6.1 Not Totally Covered Tasks
This section concentrates all the tasks identified as not totally covered by MoProSoft,
mentioning those with values L, P or N. Moreover we offer a recommendation for
each task to achieve a T value. The PM process tasks are presented in Table 10.
Table 10. Not totally covered tasks of Project Management.
ISO/IEC 29110
-
5
-
1
-
2
MoProSoft
Q
C
PM.1.8 Calculate and document the
project’s Estimated Effort and Cost.
A1.1
0
Evaluate and
document the Estimated
Cost of the project.
0.7 L
Recommendation
In MoProSoft calculating Estimated Effort is not explicitly mentioned. However, the
Cost value is calculated, which implies that the effort estimates need to be calculated
in some way, for instance in hours. Notice that this calculation is not obligatory.
ISO/IEC 29110-5-1-2 MoProSoft Q C
PM.1.14 Review and accept Project Plan.
Customer reviews and accepts Project
Plan, making sure that the Project Plan
elements match Statement of Work.
A1.16 Validate Project
Plan and Development
Plan.
0.7 L
Recommendation
MoProSoft
does not mention that
Client
has the responsibility to accept or reject
Project Plan, for this reason it is necessary to agree previously with the Client on its
acceptance.
ISO/IEC 29110
-
5
-
1
-
2
MoProSoft
Q
C
PM.2.1 Monitor the
Project
Plan
execution and record actual data in
Progress Status Record.
A3.3
Create
Monitoring
Report considering
Activities Report.
0.7 L
Recommendation
MoProSoft
doe
s not explicitly
suggest to record actual data in
Progress Status
Record, yet the work product Monitoring Report is designed for that purpose.
ISO/IEC 29110
-
5
-
1
-
2
MoProSoft
Q
C
PM.1
.1
0
Document the
Version
Control
Strategy in the Project Plan.
- 0.0 N
PM.1.15
Establish the project repository
using the Version Control Strategy.
- 0.0 N
PM.2.5
Perform backup according to the
Version Control Strategy.
- 0.0 N
PM.2.6
Perform
Project
Repository
recovery using the Project Repository
Backup, if necessary.
- 0.0 N
PM.4.2 Update Project Repository. - 0.0 N
Recommendation
MoProSoft does not require a special repository for the project, however there exists
a repository called Knowledge Database that includes all the data related to the
organization. It already includes the project, for that reason it is necessary to define
the management of Project Repository and Version Control Strategy in a similar way
as the Knowledge Database management is defined.
In Table 11 we offer recommendations for the tasks corresponding to the SI
process.
Table 11. Tasks of Software Implementation not totally covered.
ISO/IEC 29110
-
5
-
1
-
2
MoProSoft
Q
C
SI.3.5
Establish or update
Test
Cases
and
Test Procedures for integration testing
based on Requirements Specification and
Software Design.
Customer provides testing data, if needed.
A3.7 Develop or modify
Integration Testing Plan.
0.7 L
Recommendation
MoProSoft
provides
a work product called
Integration Testing
Plan
. This pl
an
should include Test Cases and Test Procedures explicitly.
ISO/IEC 29110-5-1-2 MoProSoft Q C
SI.5.6 Update Traceability Record if
appropriate.
- 0.7 L
Recommendation
Even though
MoProSoft
doe
s not
take it as
a task
, it defines a work product called
Traceability Registry especially for this purpose. Refer to it to perform the task.
ISO/IEC 29110-5-1-2 MoProSoft Q C
SI.1.2 Set or update the implementation
environment.
- 0.3 P
SI.3.2
Understand
Requirements
Specifications.
- 0.3 P
SI.4.2
Understand
Software
Design
.
-
0.3
P
SI.5.2 Understand
Test
Cases
and
Test
Procedures.
Set or update the testing environment.
- 0.3 P
SI.6.2 Understand Software
Configuration.
- 0.3 P
Recommendation
The mentioned above tasks are not explicitly stated in
MoProSoft
,
nevertheless it
appears clear that if any of those tasks are not carried out properly, software
construction won’t be possible.
6.2 Not Totally Covered Work Products
This section focuses on the work products identified as not totally covered by
MoProSoft, see Table 12.
Table 12. Not totally covered work products.
ISO/IEC 29110-5-1-2 MoProSoft Q C
Project Repository Knowledge Database 0.7 L
Recommendation
MoProSoft does not require a special repository for the project, however there exists
a repository called Knowledge Database that includes all the data related to the
organization. It already includes the project, but it is strongly advisable
to
create
a
specific repository for the project following the adequate management policies as in
the Knowledge Database.
ISO/IEC 29110
-
5
-
1
-
2
MoProSoft
Q
C
Project Repository Backup
Knowledge Database
0.0
N
Recommendation
MoProSoft
does not define
a mechanism to
create
a specific repository for the
project. In order to generate this product, it will be necessary to create a backup and
define the management policies to do it.
After all we can declare that what is needed to cover the international standard
starting from MoProSoft level 2, is feasible to achieve in a short period of time and
with little amount of effort following the recommendations, thus getting a great return
of investment.
Conclusions and Future Work
This paper describes a mapping between the international standard ISO/IEC 29110-5-
1-2 and the Mexican standard NMX-I-059-NYCE-2005, MoProSoft. As a result of
the theoretical and practical review done by specialists in software processes,
consultants from INNEVO with experience in the adoption of the Mexican standard
and the expert participation of a close developer of both standards, the gap between
standards was clarified and punctual recommendations in order to adopt the
international standard starting from MoProSoft level 2 were offered.
The MoProSoft broad scope of influence in Latin America, thanks to
COMPETISOFT and NTP 291.100:2009, serves as a strong factor to believe that
software development organizations in the region receive a real opportunity to adopt
an international standard. Besides, the coverage values obtained from the mapping,
0.77 for PM process and 0.9 for SI process, suggest an attainable objective of
reaching not only national, but international recognition as well.
Finally we conclude that an organization evaluated in MoProSoft level 2 covered
85% of tasks and 94% of work products defined in ISO/IEC 29110-5-1-2, making it
possible to acquire an international standard in a short period of time and little effort
if the suggested recommendations are followed.
Acknowledgements
This work has been possible thanks to MC. Marcela Peñaloza Báez and Fermín Marín
Arzate General Directors of DCV-DGTIC-UNAM and INNEVO respectively. Also
we would like to thank Nubia Fernández from DCV-DGTIC-UNAM and Mauricio
Arreola from INNEVO for their constant participation.
References
1. Oktaba, H.: MoProSoft: A Software Process Model for Small Enterprises. In: Proceedings
of the First International Research Workshop for Process Improvement in Small Settings,
pp. 93-100. Software Engineer Institute, Carnegie Mellon University. (2005)
2. Oktaba, H., Piattini, M., García, F., Pino, F., Alquicira, C., y Ruiz, F.: Software Process
Improvement: The COMPETISOFT Project. IEEE Computer. Vol. 40 N.10. p: 21-28.
(2007)
3. International Organization for Standardization (ISO), http://www.iso.org 06/11/11
4. Standard ISO/IEC 29110:2011 Software engineering -- Lifecycle profiles for Very Small
Entities (VSEs). (2011)
5. Ministry of Economy, http://www.economia.gob.mx/ 06/11/11
6. Universidad Nacional Autónoma de México, http://www.unam.mx 06/11/11
7. Asociación Mexicana para la Calidad en la Ingeniería del Software (AMCIS),
http://www.software.net.mx defunct.
8. NMX-I-059-NYCE-2005 parte 4: Tecnología de la información - Software - Modelos de
procesos y evaluación para desarrollo y mantenimiento de software - Parte 4: Directrices
para la evaluación. (2005)
9. Terminan pruebas controladas de MoProSoft, Software Guru, Mayo (2005)
http://www.sg.com.mx/content/view/53/99999999 06/11/11
10. NMX-I-059-NYCE-2005 parte 2: Tecnología de la información - Software - Modelos de
procesos y evaluación para desarrollo y mantenimiento de software - Parte 2: Requisitos y
procesos. (2005)
11. Normalización y Certificación Electrónica (NYCE), http://www.nyce.org.mx 06/11/11
12. Programa Iberoamericano de Ciencia y Tecnología para el Desarrollo (CYTED),
http://www.cyted.org 06/11/11
13. Pino, F., Triñanes, J., García, F., Piattini, M.: Agil_MANTEMA Una metodología de
mantenimiento de software para pequeñas organizaciones. JIISBD ’08, p: 171-182 (2008)
14. Instituto Nacional de Defensa de la Competencia y de la Protección de la Propiedad
Intelectual (INDECOPI), http://www.indecopi.gob.pe 06/11/11
15. NTP 291.100-1:2009 Ingeniería de Software: Modelos de procesos y evaluación para
desarrollo y mantenimiento de software. (2009)
16. Modelo de Procesos para la Industria de Software: MoProSoft por Niveles de Capacidad de
Procesos, Versión 1.3 (2005)
http://www.comunidadmoprosoft.org.mx/COMUNIDAD_MOPROSOFTADM/Documentos
/V_1.3_MoProSoft_por_niveles_de_capacidad_de_procesos.pdf 06/11/11
17. NMX-I-15504-2-NYCE-2010 parte 2: Tecnología de la información - Evaluación de los
procesos- Parte 2: Realización de una evaluación. (2010)
18. Standard ISO/IEC 15504-2:2003. Information Technology - Process assessment - Part 2
Performing an assessment. (2003)
19. ISO/IEC JTC1/SC7 Software and Systems Engineering, http://www.jtc1-sc7.org/ 06/11/11
20. Oktaba, H.: Tejiendo Nuestra Red: Ya Nació ISO/IEC 29110 Perfil Básico, Software Guru,
Septiembre (2011) http://www.sg.com.mx/content/view/1211 06/11/11
21. Standard ISO/IEC 29110-5-1-2:2011 Software engineering -- Lifecycle profiles for Very
Small Entities (VSEs) -- Part 5-1-2: Management and engineering guide: Generic profile
group: Basic profile. (2011)
22. Standard ISO/IEC 12207:2008 Systems and software engineering -- Software life cycle
processes. (2008)
23. Standard ISO/IEC 15289:2006 Systems and software engineering -- Content of life-cycle
information products (documentation). (2006)
24. INNEVO, http://www.innevo.com 06/11/11
