Software Process Improvement

COMPUTING PRACTICES
Software Process
Improvement:
The Competisoft Project
Competisoft provides the Latin American software industry with
a reference framework for improvement and certification of its
software processes.The project is based on proven solutions,
including the MoProSoft model that four Mexican software
companies applied to increase their processes’ capacity level.
Hanna Oktaba
National Autonomous
University of Mexico
Félix García,
Mario Piattini,
and Francisco
Ruiz
Alarcos Research Group
Francisco J.
Pino
University of Cauca,
Colombia
Claudia Alquicira
Ultrasist
S
oftware constitutes an important industry for developing Latin American countries. The small- and medium-sized companies that account
for up to half the industry’s employment face serious problems, however,
when they start to grow. In many cases, the absence of a visible software-development process creates chaos for the entire organization,
including its products.1 The companies’ lack of competitiveness seriously limits
their growth.2
USING EXISTING REFERENCE MODELS
Recently, small Latin American software companies have tried to improve their
software processes’ capability as a fundamental step toward increasing product
quality. They’ve addressed two main concerns:
• their image, a key factor for establishing and maintaining a position in the
global marketplace; and
• the efficiency and effectiveness of software process management.
Many of these businesses deploy reference models proposed by the Software
Engineering Institute (SEI), the Capability Maturity Model Institute (CMMI),
or the International Organization for Standardization (ISO). However, these reference models’ complex recommendations and significant time and resource commitment make their application difficult for small organizations.3-5
The situation is especially troublesome for small Latin American organizations
due to the absence of tailor-made process reference models and the adoption of
models defined in other countries without suitable adaptation. Indeed, softwareprocess-improvement advocate Sami Zahran6 observed that an organization will
reject a process if it doesn’t match its culture, just as the human body will reject
a mismatched transplanted organ. Software-engineering researcher Tore Dyba,
meanwhile, noted that cultural differences play a role in the success of software
process improvement.7
0018-9162/07/$25.00 © 2007 IEEE
Published by the IEEE Computer Society
October 2007
21
Standards Application in Very Small Enterprises
Claude Y. Laporte, École de Technologie Supérieure
International software-engineering standards weren’t
written with very small enterprises (fewer than 25
employees) in mind, even though a majority of organizations fall into this category. Microenterprises (nine or
fewer employees) represent 93 percent of companies in
Europe, 56 percent in the US, and 66 percent of total
employment globally.1 As Table A shows, a 2004 survey
of the Montreal area’s IT sector found that 78 percent of
software-development companies had 25 or fewer
employees, and 50 percent had fewer than 10 employees (http://profs.logti.etsmtl.ca/claporte/English/
Publications/index.html).
Since ISO/IEC software standards are difficult to apply
in such settings, WG24, an ISO/IEC JTC1 SC7 working
group, has been established to develop international
standard profiles and technical reports to help VSEs comTable A. Employment by different-sized softwaredevelopment companies in the Montreal area (2004).
Size
(employees)
1 to 25
26 to 100
Over 100
Total
Software companies
Number Percent
540
127
26
693
78
18
4
100
Jobs
Number Percent
5,105
6,221
6,056
17,382
29
36
35
100
The SEI emphasizes that it’s expensive and difficult to
implement CMMI and the Standard CMMI Appraisal
Method for Process Improvement (SCAMPI) in the US.2,8
Applying these models would be even more expensive
and difficult for Latin American companies, which must
make copyright and certification payments to the US.
With limited resources, small companies generally
need external assistance in planning and implementing
process improvement to keep abreast of state-of-the-art
software-engineering research and practice. Furthermore, the current international life-cycle processes
(ISO/IEC 12207 and ISO/IEC 15288) don’t explicitly
address the needs of small organizations. The new
ISO/IEC JTC1 SC7 Working Group 24, which was
created to develop software life-cycle profiles and guidelines for very small enterprises (those with fewer than
25 employees), recognizes the need to adapt ISO/IEC
12207 increasingly to small organizations. The “Standards Application in Very Small Enterprises” sidebar
provides additional information about these efforts.
Several researchers seek to adapt models for process
assessment and improvement (mainly from ISO and SEI)
22
Computer
ply with ISO software-engineering standards (www.
tudor.lu/spice2006). The group will use parts of ISO
standards and parts of national standards to create a
profile, defined as a set of one or more base standards
necessary to fulfill a particular function.
Australia, Belgium, Canada, the Czech Republic,
Finland, India, Ireland, Italy, Japan, Korea, Luxembourg,
Mexico, South Africa, Thailand, and the United
Kingdom are participating in WG24, along with the
IEEE Computer Society and the International Council
on Systems Engineering.
WG24 surveyed VSEs to identify problems and potential solutions to help them apply standards and become
more competitive. Available in English, French, German,
Korean, Portuguese, Russian, Spanish, Thai, and Turkish,
the survey yielded more than 444 responses from 32
countries. About half the responses were from Latin
American countries, mainly Brazil, Colombia, and Mexico.
When respondents were asked why they didn’t use
standards,
• 28 percent indicated a lack of resources (expertise,
budget, time),
• 24 percent indicated that customers or management
didn’t require them, and
• 15 percent indicated they were bureaucratic and difficult to apply.
to the special characteristics of small organizations. The
SEI’s Proceedings of the First International Research
Workshop for Process Improvement in Small Settings,9
for example, includes many articles on the challenges of
process improvement in small organizations.
THE MOPROSOFT EXPERIENCE
Mexico’s attempts to improve its software industry
led to development of the Process Model for the
Software Industry (Modelo de Procesos para la Industria
de Software) reference model in 2002.10 MoProSoft built
on the well-known practices of the SEI’s now-retired
Capability Maturity Model for Software, ISO 9000:
2000, the Project Management Institute’s project management body of knowledge (PMBOK), and others. It
offered a new process structure, some new process-documentation elements, a more precise process relationship, and an explicit process-improvement mechanism.
In addition to conforming with ISO/IEC 15504, the
government needed a model suitable for small- and
medium-sized enterprises, inexpensive to adopt and
assess, feasible as a national standard, specific for soft-
More than 74 percent of respondents indicated it
was important to be either recognized or certified.
Among the respondents, 40 percent requested ISO
certification, and 28 percent requested market recognition. A national certification interested only 4 percent
of the respondents. Regarding the need for assistance,
62 percent ask for more guidance and examples, and
55 percent require lightweight and easy-to-understand
standards provided with examples, templates, and
checklists.
In 1997, the council responsible for IEEE Software
Engineering Standards surveyed software-engineering-standards users to improve those standards.2
The 148 responses, mainly from the US and companies with more than 100 employees, indicated that
IEEE standards needed examples, templates, a lifecycle process definition, and support for metrics and
measurement.
At its 2005 meeting, WG24 considered that
Mexico’s MoProSoft could serve as the basis for a first
working draft, even though the standard is aimed at
larger enterprises. The following year, WG24 tailored
the Mexican standard for VSEs, and earlier this year
decided to develop Profile 1 using the tailored
Mexican standard.
To help VSEs implement forthcoming ISO profiles,
the group also decided to develop deployment kits
ware-development and maintenance organizations, and
defined as a set of processes based on internationally
recognized practices.
MoProSoft was complemented by the EvalProSoft
process-assessment method,9 based on the recommendations of ISO/IEC 15504 (Part 2). Trials of MoProSoft
and EvalProSoft in four Mexican companies confirmed
the model’s suitability for small organizations with low
maturity levels, borne out by the improvements achieved
and the low cost of process adoption.9
In August 2005, Mexico approved MoProSoft and
EvalProSoft as standard NMX-059-NYCE-2005. Together, they were intended to provide Mexico’s software
industry with an easy-to-understand model based on
best international practices that would help organizations standardize their practices.
Process model structure
Defining the process model’s structure requires analyzing the structure of software-development enterprises.
In most firms—even microenterprises with fewer than
10 people—top management makes decisions on the
that would enable VSEs to rapidly deploy a subset of
the total profile. For example, a VSE could attend a
half-day workshop about version control. The deployment kit would contain the information required to
deploy version control, such as a description of the
process, guides, templates, checklists, an evaluation
form, and an installation and user guide for an open
software version-control tool.
WG24 also plans pilot projects to validate the
approach and obtain feedback to improve the documents before seeking ISO/IEC publication. Production
of a working draft is set for 2007, a final draft in 2009,
and ISO/IEC publication in 2010.
References
1. Organisation for Economic Co-Operation and Development,
Small and Medium Enterprise Outlook, OECD, 2002.
2. S.K. Land, “Results of the IEEE Survey of Software Engineering Standards Users,” Proc. Int’l Software Eng. Standards
Symp. and Forum, Emerging Int’l Standards (ISESS 97), IEEE
Press, 1997, pp. 242–270.
Claude Y. Laporte is a professor in the Department of Software
and IT Engineering at École de Technologie Supérieure in
Montreal. Contact him at claude.y.laporte@etsmtl.ca.
business’s direction, middle management is responsible
for project and resource procurement and control, and
an operations group develops projects using allotted
resources. The members of those groups acknowledge
responsibilities through their assigned roles, which have
vertical authority alignment and horizontal collaboration relationships.
We considered three process categories:
• Top management. Members of this category are concerned with business-management practices and
direct and receive reports from middle management.
• Middle management. Members of this category deal
with process-, project-, and resource-management
practices in line with top management’s business
goals. They provide elements for the performance of
operations processes, receive and evaluate the information those processes generate, and inform top management of the results. The resource-management
process includes three subprocesses: human resources
and work environment; goods, services, and infrastructure; and knowledge of the organization.
October 2007
23
m M
an id
ag dle
em
en
t
Process management
Project management
Resource management
Op
er
at
io
ns
m
an To
ag p
em
en
t
Business management
Specific project administration
Software development and maintenance
Figure 1. MoProSoft’s process categories. An analysis of the
structure of software-development enterprises provided the
basis for the process categories.
• Operations. Members of this category address the
practices of software-development and -maintenance
projects. They perform activities using elements
management provides and deliver reports and the
software products generated.
We based these categories on management and governance structure, as Figure 1 shows.
Process pattern
The model’s innovative process pattern, the set of
elements needed to document a process, consists of a
general process definition, tailoring guidelines, and a
practices section.
The general process definition includes the process
name, category, and purpose; an abstract of process
activities; goals, goal indicators, responsibility, and
authority roles; subprocesses (if any) and related
processes; inputs, outputs, and internal products; and
bibliographical references.
Tailoring guidelines suggest the possible process modifications, which shouldn’t affect achieving process goals.
The practices section includes recommended training
practices, exceptional situation management, use of
lessons learned, and a UML activity diagram. It identifies the roles involved in the process, the training
required, and the infrastructure resources needed to support activities. The practices session describes product
verifications and any required validations as well as activities associating them with the process goals and the roles
involved. It lists products that should be incorporated
into the organization’s knowledge base and exemplifies
process measurements for each goal indicator.
Organizations use this pattern to document all
MoProSoft processes. An organization that decides to
introduce standardized processes without knowing how
to do so can start with this model as the initial process
documentation and adjust it with local techniques, prod24
Computer
ucts form, and terminology. The process pattern also
facilitates the inclusion of new processes in the model.
For example, if the organization needs a client-service
process, it can use the pattern to define and incorporate
the model.
Interrelated processes
MoProSoft processes are interrelated. The process pattern defines its relationship based on product interchange and role participation. Each output product that
the process generates is explicitly identified as the input
product in one or more other processes. The same
process that generates internal products also “consumes” them.
The process relationship based on role participation
means that some roles of one process participate in activities of others. This interrelation makes it possible to follow the product and workflow between processes and
facilitates the assignment of personal responsibilities
through roles. It’s particularly important for small organizations where a few people must play several roles.
Assessing other standards
Organizations can use MoProSoft as a vehicle to assess
or audit other standards. Several studies show coverage
of 92 percent of the requirements of ISO 9000:2000;11 95
percent of the process purposes in Annex F of ISO 12207
within the scope of the MoProSoft processes; and 77
percent of the specific and general goals and practices of
CMMI 1.1 Level 2.12
According to the MoProSoft model, an organization
should establish its own strategies for setting up the
processes it defines, and the processes should evolve in
line with suggestions for improvement. That will allow
coverage of the organization’s strategic plan objectives
and setting of increasingly ambitious goals. In this way,
the company can reach maturity progressively through
ongoing process improvement.
Testing MoProSoft
In 2004, four trials were run in typical small Mexican
software companies to evaluate the ease of application
and usefulness of MoProSoft as a software process
model for small companies and to determine the cost of
the EvalProSoft assessment method.
Initial assessments to establish the baseline capabilities of the enterprise processes showed them all to be
between 0 and 1. Over the next six months, consultants
coached the companies on MoProSoft tailoring and
adoption. When the companies were assessed a second
time, all enterprises achieved an average increase of 1.08
in the capacity level of all their processes.
Table 1 shows the number of employees, the total
improvement effort in hours, and the effort per person for
each company. The last column indicates the average
capacity improvement per process. It’s interesting to
observe the relationship between the effort per
person and the average process improvement.
For example, Company C invested the largest
number of hours per person and achieved the
greatest process improvement. The average number of employees was 18, and the average effort
per person was 21.28 hours over six months.
THE COMPETISOFT APPROACH
Table 1. Improvement experience using MoProSoft.
Company
A
B
C
D
Average
In 2005, several researchers and practitioners
recognized the importance of an improvement
and certification framework for small organizations. They proposed Competisoft to the IberoAmerican Science and Technology Development
Program (Programa Iberoamericano de Ciencia y
Tecnología para el Desarrollo), a group created in 1984
for multilateral scientific and technological cooperation
and supported by 21 Latin American countries plus
Spain and Portugal. CYTED aims to establish cooperation between university research groups, R&D institutes, and innovative companies in the countries
involved to transfer scientific and technological results
to productive systems and social politics.
Participants applied action research, a collaborative
approach featuring continual feedback between the
researchers and companies in the definition, refinement,
and application of the Competisoft model. Participants
in Competisoft fell into two main categories:
• researchers from universities in Argentina, Brazil,
Chile, Colombia, Costa Rica, Cuba, Ecuador, Mexico,
Peru, Portugal, Spain, Uruguay, and Venezuela; and
• the critical reference group, consisting of the
Argentinian IRAM (Institute for Standardization
and Certification), the government of Argentina’s
Neuquén region, and small companies,
including five from Colombia, four
from Peru, three from Spain, and one
each from Argentina, Chile, Ecuador,
Mexico, and Uruguay.
To develop the Competisoft project, we
studied different Latin American initiatives,
such as MoProSoft, the Brazilian Process
Improvement Model (Melhoria de Processos do Software Brasileiro), and also agile
software process improvement (SPI). The
Spanish Ministry of Public Administration’s
Métrica v3 was also considered, since it’s
aimed at improving software processes
and products.
As Figure 2 shows, we developed Competisoft by borrowing heavily from wellknown assessment methods intended for
small companies, especially MoProSoft, as
a process reference model. In fact, we can
Employees Total effort
(hours)
17
8
17
29
18
Effort per
Average
person (hours) improvement
479
199
628
221
383
28.18
24.88
36.94
7.62
21.28
1.00
1.00
1.56
0.78
1.08
view Competisoft as an evolution of MoProSoft, with
researchers’ and practitioners’ experience in software
process deployment and improvement leading to a new
process reference and evaluation model that enhances
MoProSoft and EvalProSoft, and a new process-improvement model based on agile SPI.
Process reference model
The Competisoft process reference model incorporates several improvements and refinements.
Process management. We developed a self-assessment questionnaire that can help small organizations
with the first contact with the assessment and improvement of their process maturity.
Project management.We selected basic software project measurements and indicators aligned to the project
and process objectives. We integrated them with the
administration of specific projects and with the software-development processes to facilitate use by small
organizations. We’re also tackling the improvement of
estimation techniques, a fundamental need in small
organizations but one that’s difficult to understand and
apply in these settings.
Figure 2. Competisoft project overview. Several different Latin American initiatives were studied for Competisoft.
October 2007
25
COMPETISOFT
Evaluation Method
CAPABILITY
Dimension
Level 5: Optimizing (2 attributes)
Level 4: Predictable (2 attributes)
Level 3: Established (2 attributes)
Level 2: Managed (2 attributes)
ISO/IEC 15504-5:2006(E)
For each attribute PA 1.1 to PA 5.2
Process capability assessment (Level 1 to 5)
based on Process Attribute Indicators (PAI)
- GP: Generic Practice
- GR: Generic Resource
- GWP: Generic Work Product
Level 1: Performed (1 attribute)
Level 0: Incomplete
HIGH DIRECTION
(DIR)
Category
Business Management
Category
MANAGEMENT
(MAN)
Process Management
Project Management
Human Resources Management
Goods, Services, and Infrastructure Management
Knowledge Management
OPERATION
(OPE)
Category
Specific Project Administration
Software Development
Software Maintenance
Level 1
Elements (from COMPETISOFT)
for process performance assessment
based on: · Purpose
· Description
· Objectives
· Indicator
· ...
COMPETISOFT
Reference
Model
PROCESS
Dimension
Figure 3. Competisoft evaluation model. Based on EvalProSoft, the model defines a set of measures for estimating the capability
and performance of software processes.
Development. We built in examples of deployment
guidelines for requirements, analysis and design, construction, testing, and measurement activities to facilitate
application in small organizations. The deployment guides
describe techniques and specific work products, suggest
support tools, recommend a bibliography, and provide an
application example. This strategy gives small organizations more flexibility in running the development process,
as companies of this kind tend to integrate techniques from
different approaches depending on the context.
Maintenance. It’s important to tackle maintenance
separately from development, as their nature and characteristics are different and many development techniques, tools, model processes, and so on aren’t directly
applicable to maintenance. Indeed, many small organizations must develop pure software-maintenance projects, which makes it important for them to apply
specific maintenance methodologies.
In this regard, the Competisoft approach has developed a maintenance process adapting the Mantema12
and Scrum methodologies to small organizations. This
process defines two levels of maintenance services: basic,
which includes urgent, nonurgent, and perfective kinds
of maintenance; and advanced, which is concerned with
adaptive and preventive maintenance.
We’re currently tackling several other issues associated
26
Computer
with the reference model. In addition to improvements
proposed for specific processes, two aspects common to
all processes are the incorporation of free and open
source software—a key element for small organizations
to reduce costs—and development of specific techniques
for the improvement of systems usability.
Business management. As small organizations work
to better align their business objectives and information technologies, we need to include virtual enterprises
and intercompany connectivity, a key requirement to
guarantee the survival of small organization clusters in
today’s marketplace.
Resource management. We’ll emphasize the importance of reusability by developing an experience base
structured according to the processes in the reference
model. To this end, we’ll consider other similar experiences.13 Indeed, Competisoft places great importance on
the experience base from the outset at all organizational
levels, regardless of the quality of the components stored
in the base, as they may all be useful. We also recognize
the value of a more formal, yet still lightweight, method
of eliciting experience that’s easy for a small organization to use, providing guidance and structure to assist
users in creating more experiences for the base. Other
important issues to address are documentation and configuration management.
Evaluation model
The Competisoft evaluation model is based on the
EvalProSoft model. The first task was to define a set
of measures for estimating the capability and performance of software processes. The aim was to help small
organizations carry out their assessments by reducing
subjectivity and making the process more formal.
As Figure 3 shows, the measures are grouped into two
main types:
• The capability measures, which use process attribute
indicators to evaluate process capability (from Level
1 to 5) on the basis of generic practices, resources,
and work products; and
• The performance measures, which are based on purpose, description, work products, and activities from
the Competisoft reference model.
The organization is also developing a software tool
with a Web interface to support the evaluation model.
Improvement model
The Competisoft improvement model is based on agile
SPI, which establishes the elements necessary for economically running improvement programs in small organizations. The model defines PmCompetisoft, an improvement process that follows the process pattern defined in
Competisoft. Designed to be easier and more intuitive for
small software organizations, PmCompetisoft offers
•
•
•
•
•
early and continuous achievements of improvement,
continuous and fast process diagnosis,
elemental process measurement,
effective group communication, and
continuous learning.
PmCompetisoft is a lightweight process that follows an
iterative and incremental approach to guide the implementation of an improvement cycle. To achieve this,
PmCompetisoft is highly influenced by the Ideal model as
well as by agile methodologies such as eXtreme Programming and Scrum. It’s composed of one or more improvement cycles, each one involving five activities: initiating
the cycle, diagnosing the process, formulating improvements, executing improvements, and revising the cycle.
The model clearly defines these activities by describing the
roles involved, the expected work products, and, for each
work product, a fully detailed self-content template.
Furthermore, the Competisoft improvement model
defines a set of high-priority processes for small organizations implementing a process-improvement project.
The strategy’s fundamental principle is that companies
must connect process improvement with the other software process-management responsibilities. A consultant
guide must advise the program leader on using PmCompetisoft to start a process-improvement cycle.
T
o date, Competisoft has resulted in the development of a common methodological framework
suitable for small Latin American organizations
and oriented toward continual software process
improvement. The project has introduced the Latin
American software industry to a process-improvement
culture, and it has introduced standardization and certification organizations to methodological principles.
Currently, six small companies are applying the
Competisoft model over a four-month period. The goal
is to increase by one the process capability and measure
the effort required to conduct the improvement. We will
generate new versions of the process reference, evaluation, and improvement models on the basis of feedback
and lessons learned. ■
References
1. J. Batista and A. Dias de Figueiredo, “SPI in a Very Small
Team: A Case with CMM,” Software Process: Improvement
and Practice, vol. 5, no. 4, 2000, pp. 243-250.
2. Mayer & Bunge Informática, Panorama de la Industria del
Software en Latinoamérica, 2004, p. 97.
3. H.K.N. Leung and T.C.F. Yuen, “A Process Framework for
Small Projects,” Software Process: Improvement and Practice, vol. 6, no. 2, 2001, pp. 67-83.
4. H. Saiedian and N. Carr, “Characterizing a Software Process
Maturity Model for Small Organizations,” ACM SIGICE
Bull., vol. 23, no. 1, 1997, pp. 2-11.
5. P. Maller, C. Ochoa, and J. Silva, “Lightening the Software
Production Process in a CMM Level 5 Framework,” IEEE
Latin America Trans., vol. 3, no. 1, 2005, pp. 14-21.
6. S. Zahran, Software Process Improvement: Practical Guidelines for Business Success, Addison-Wesley, 1998.
7. T. Dyba, “An Empirical Investigation of the Key Factors for
Success in Software Process Improvement,” IEEE Trans. Software Eng., vol. 31, no. 5, 2005, pp. 410-424.
8. M.B. Chrissis et al., CMMI Interpretive Guidance Project:
What We Learned, special report CMU/SEI-2004-SR-008,
Software Eng. Institute, 2004; www.sei.cmu.edu/pub/
documents/04.reports/pdf/04sr008.pdf.
9. S. García, C. Graettinger, and K. Kost, eds., Proc. 1st Int’l
Research Workshop for Process Improvement in Small Settings, special report CMU/SEI-2006-SR-001, Software Eng.
Institute, 2006; www.sei.cmu.edu/pub/documents/06.reports/
pdf/06sr001.pdf.
10. H. Oktaba, “MoProSoft: A Software Process Model for Small
Enterprises,” Proc. 1st Int’l Research Workshop for Process
Improvement in Small Settings, special report CMU/SEI-2006SR-001; Software Eng. Institute, 2006, pp. 93-101; www.sei.
cmu.edu/pub/documents/06.reports/pdf/06sr001.pdf.
11. M. Oyvind, “Comparación del Modelo de Procesos para la
Industria de Software (MoProSoft) con las Normas y Modelos de Referencia,” master’s thesis, National Autonomous University of Mexico, 2005.
October 2007
27
12. G. Rivera and E. Montero, “Mapeo de CMMI Nivel 2 con
MoProSoft,” internal report, Mexican Ministry of Economy,
2004.
13. M. Polo, M. Piattini, and F. Ruiz, “Using a Qualitative
Research Method for Building a Software Maintenance
Methodology,” Software Practice and Experience, vol. 32,
no. 13, 2002, pp. 1239-1260.
14. F. Kurniawati and R. Jeffery, “The Use and Effects of an Electronic Process Guide and Experience Repository: A Longitudinal Study,” J. Information and Software Technology, 2005,
pp. 1-12.
Hanna Oktaba, a professor of computer science at the
National Autonomous University of Mexico, is the technical director of Competisoft. Her research interests include
software engineering, object-oriented technology, and software process models and improvement. Oktaba received a
PhD in computer science from the University of Warsaw,
Poland. She is a Mexican delegate to WG24. Contact her at
ho@fciencias.unam.mx.
Félix García is a lecturer in the Department of Information
Technologies and Systems at the University of Castilla-La
Mancha (UCLM), where he is a member of the Alarcos
Research Group, specializing in information systems, databases, and software engineering. His research interests
include business process management, software processes,
software measurement, and agile methods. He received a
PhD in computer science from UCLM. Contact him at
felix.garcia@uclm.es.
Mario Piattini, general director of Competisoft, is a professor in the Department of Information Technologies and
Systems at UCLM, where he leads the Alarcos Research
Group. His research interests include software quality, metrics, and maintenance. Piattini received a PhD in computer
science from the Polytechnic University of Madrid. He is a
member of the IEEE Computer Society and the ACM. Contact him at mario.piattini@uclm.es.
Francisco Ruiz is an associate professor in the Department
of Information Technologies and Systems at UCLM, where
he is a member of the Alarcos Research Group. His research
interests include business process modeling and measurement, software measurement, software process technology,
and methodologies for planning and managing software
projects. Ruiz received a PhD in computer science from
UCLM. He is a member of the IEEE Computer Society and
the ACM. Contact him at francisco.ruizg@uclm.es.
Francisco J. Pino is a lecturer on the electronic and telecommunications engineering faculty at the University of Cauca,
Popayán, Colombia, and is currently a PhD student in computer science at UCLM. His research interests focus on software process improvement in small companies. Contact him
at fjpino@unicauca.edu.co.
Claudia Alquicira is a consultant in software process
improvement at Ultrasist and a Competisoft team member.
She received an MS in computer science from the National
Autonomous University of Mexico. Contact her at alqcae@
gmail.com.
Wa n t e d
Editor
f o r
in Chief
2 0 0 9 – 2 0 1 1
Computing in Science & Engineering (www.computer.org/cise) is a copublication of the IEEE Computer Society (www.computer.org)
and the American Institute of Physics (http://cise.aip.org) that supports the development of computing tools and methods as well as
their effective use in theoretical, computational, and experimental science, engineering, and education. The magazine seeks an editor
in chief with exceptional vision and a broad background and familiarity with the users and uses of computation in the whole spectrum
of science and engineering fields.
Each applicant should submit
A resume, including publications and editorial experience.
A cover letter outlining how the applicant would provide leadership for CiSE.
The two-year term for the new EIC begins January 2009. Applications and nominations received by 1 November 2007 will receive
full consideration, but applications will be accepted until the post is filled. Visit http://cise.aip.org/ or www.computer.org/cise for
additional information, and send nominations, inquiries, and applications materials to Dianne O’Leary (oleary@cs.umd.edu).
28
Computer