Guía de los Fundamentos de Ingeniería de Software

Conocimiento

Versión 2004

SWEBOK ®

Un proyecto de la IEEE Computer Society

Comité de Prácticas Profesionales

© IEEE - 2004 Versión ® SWEBOK es una marca de servicio oficial del IEEE
© IEEE - 2004 Versión
 Guía de los Fundamentos de Ingeniería de Software
Conocimiento

2004 Versión

SWEBOK ®

editores ejecutivos
Alain Abran, Escuela de Tecnología Superior
James W. Moore, El MITRE Corp.

editores
Pierre Bourque, Escuela de Tecnología Superior
Robert Dupuis, Universidad de Quebec en Montreal

Proyecto campeon
Leonard L. Tripp, Presidente del Comité de Prácticas Profesionales,
IEEE Computer Society (2001-2003)

http://computer.org

Los Alamitos, California

Washington • Bruselas • Tokio

© IEEE - 2004 Versión ® SWEBOK es una marca de servicio oficial del IEEE
 Biblioteca del Congreso de datos Catalogación en la Publicación

Guía de la swebok: Versión 2004

/ editores ejecutivos, Alain Abran, James W. Moore; editores, Pierre Bourque, Robert Dupuis,
Leonard L. Tripp.
pag. cm.
1. La ingeniería de software. 2. Los programas informáticos - Desarrollo. YO.
Abran, Alain, 1949- . II. Moore, James W., 1948- .
A completar

2001005442

Copyright © 2004 por el Instituto de Ingenieros Eléctricos y Electrónicos, Inc. Todos los derechos reservados.

Derechos de autor y reimpresión Permisos: Este documento puede ser copiado, en su totalidad o en parte, en cualquier forma o por cualquier medio, como es, o con alteraciones, siempre
que (1) las alteraciones están claramente marcadas como alteraciones y (2) este aviso de copyright está incluido sin modificar en cualquier dupdo. Cualquier otro uso o distribución de este
documento queda prohibida sin la previa autorización expresa de la IEEE.

Se utiliza este documento con la condición de que indemnizar y mantener indemne IEEE de cualquier y toda responsabilidad o daños a sí mismo oa su hardware o software, o de
terceros, incluyendo los honorarios de abogados, costas judiciales y otros costos y gastos relacionados, que surjan para el uso de este documento, independientemente de la causa de
dicha responsabilidad.

IEEE hace que este documento disponible en "TAL CUAL" y no garantiza, expresa o implícita, AS A LA EXACTITUD, CAPACIDAD, COMERCIABILIDAD eficiencia o funcionamiento
de este DOCUMENTO. En ningún caso, IEEE RESPONSABLE DE CUALQUIER GENERAL, consecuente, indirecto incidental, ejemplar, o daños especiales, EVEN IF IEEE HA
ADVERTIDO DE LA posibilidad de tales daños.

A completar

Copias adicionales pueden ser solicitados a:

IEEE Computer Society Centro de Servicio IEEE IEEE Computer Society

Centro de atención al cliente 445 Hoes Lane, Oficina Asia / Pacífico
Los Vaqueros 10662 Círculo PO Box 1331 Watanabe Bldg., 1-4-2
PO Box 3014 Piscataway, NJ 08855-1331 Minami-Aoyama
Los Alamitos, CA 90720-1314 Tel: + 1-732-981-0060 Minato-ku, Tokio 107-0062
Tel: + 1-714-821-8380 Fax: + 1-732-981-9667 JAPÓN
Fax: + 1-714-821-4641 http://shop.ieee.org/store/ Tel: + 81-3-3408-3118
E-mail: cs.books@computer.org customer-service@ieee.org Fax: + 81-3-3408-3553
tokyo.ofc@computer.org

Editorial: Angela Burgess

Grupo Jefe de Redacción, CS Press: Deborah Plummer
Publicidad / Promociones: Tom Fink Producción
Editor: Bob Werner impreso en los Estados
Unidos de América

© IEEE - 2004 Versión

T CAPAZ DE do ONTENIDOS
F RÓLOGO ................................................. .................................................. ............................... vii Comités SWEBOK
............................................... .................................................. ............... ix Prefacio a la Guía SWEBOK
............................. .................................................. ................ xviii C CAPÍTULO 1
yo INTRODUCCIÓN AL GRAMO UÍA ................................................. ......................... 1-1
do CAPÍTULO 2 S REQUISITOS DEL SOFTWARE ................................................ ............................... 2-1
do CAPÍTULO 3 S OFTWARE re ESIGN ................................................. .......................................... 3-1
do CAPÍTULO 4 S OFTWARE do ONSTRUCCIÓN ................................................. ............................. 4-1
do CAPÍTULO 5 S OFTWARE T PRUEB ................................................. ......................................... 5-1
do CAPÍTULO 6 S OFTWARE METRO ANTENIMIENTO ................................................. .............................. 6-1
do CAPÍTULO 7 S OFTWARE do ONFIGURACIÓN METRO GESTIÓN ................................................. ... 7-1
do CAPÍTULO 8 S OFTWARE mi NGENIERÍA METRO GESTIÓN ................................................. ........ 8-1
do CAPÍTULO 9 S OFTWARE mi NGENIERÍA PAG PROCESO ................................................. ................. 9-1
do CAPÍTULO 10 S OFTWARE mi NGENIERÍA T Y OOLS METRO ÉTODOS ........................................... 10-1 C CAPÍTULO 11 S OFTWARE Q
CALIDAD ................................................. ...................................... 11-1 C CAPÍTULO 12 K ONOCIMIENTO UN REAS DE LA R EXALTADO re ISCIPLINES
...................... .... ... Un ..12-1 PÉNDICE Alaska ONOCIMIENTO UN REA re DESCRIPCIÓN S ESPECIFICACIONES DE LA

2004 V Ersion DE LA GRAMO NOTIFICACIONES AL S OFTWARE mi NGENIERÍA

segundo ODY DE K ONOCIMIENTO ................................................. .................................... A-1

Apéndice SER VOLUTION DE LA GRAMO UÍA ................................................. .............................. B-1 A PÉNDICE California sIGNACIÓN
DE IEEE Y ISO S OFTWARE mi NGENIERÍA S NORMAS PARA
SWEBOK K ONOCIMIENTO UN REAS ................................................. ..................... C-1
UN PÉNDICE corriente continua CLASIFICACIÓN DEL T OPICS UN egún segundo TELAR ' S T AXONOMY ................ D-1

© IEEE - 2004 Versión v

vi © IEEE - 2004 Versión
 F RÓLOGO

En esta guía, el IEEE Computer Society establece por primera vez una línea de base para el conjunto de conocimientos para el campo de la
ingeniería de software, y el trabajo cumple parcialmente la responsabilidad de la sociedad para promover el avance de la teoría y la práctica en este
campo. De este modo, la Sociedad se ha guiado por la experiencia de disciplinas con historias más largas, pero no estaba vinculado por sus problemas
o sus soluciones.

Cabe señalar que la Guía no pretende definir el conjunto de conocimientos, sino más bien para servir como un compendio y guías para el conjunto de
conocimientos que se ha venido desarrollando y evolucionando en las últimas cuatro décadas. Por otra parte, este conjunto de conocimientos no es estática. los Guía
debe, necesariamente, desarrollar y evolucionar a medida que madura la ingeniería de software. Sin embargo, constituye un valioso elemento de la infraestructura
de la ingeniería de software.

En 1958, John Tukey, el estadístico de renombre mundial, acuñó el término software. El termino Ingeniería de software
se utilizó en el título de una conferencia de la OTAN celebrada en Alemania en 1968. El IEEE Computer Society publicó por primera vez su
Las transacciones en Ingeniería de Software en 1972. El comité establecido en la IEEE Computer Society para el desarrollo de estándares de
ingeniería de software fue fundada en 1976.

La primera visión integral de la ingeniería de software para salir de la IEEE Computer Society fue resultado de un esfuerzo dirigido por Fletcher Buckley para
desarrollar el estándar IEEE 730 para el aseguramiento de la calidad del software, que se completó en
1979. El propósito de la norma IEEE Std 730 era proporcionar uniformes, requisitos mínimos aceptables para la preparación y contenido de los planes de
aseguramiento de la calidad del software. Esta norma fue influyente en la realización de las normas de desarrollo de los siguientes temas: gestión de
configuración, pruebas de software, requisitos de software, diseño de software, y la verificación y validación de software.

Durante el periodo 1981-1985, la IEEE Computer Society llevó a cabo una serie de talleres sobre la aplicación de las normas de ingeniería de software.
Estos talleres profesionales involucrados compartan sus experiencias con las normas existentes. Los talleres también se llevaron a cabo sesiones de
planificación para las futuras normas, incluyendo uno que incluya las medidas y las métricas para los productos y procesos de ingeniería de software. La
planificación también resultó en IEEE Std 1002, Taxonomía de Estándares de Ingeniería de Software (1986), que proporciona una nueva visión holística de la
ingeniería de software. La norma describe la forma y el contenido de una taxonomía estándares de ingeniería de software. Se explican los diferentes tipos de
estándares de ingeniería de software, sus relaciones funcionales y externos, y el papel de las diversas funciones que participan en el ciclo de vida del software.

En 1990, se inició la planificación de una norma internacional con una visión global. La planificación se centró en la conciliación de los puntos de vista del
proceso de software de IEEE Std 1074 y la norma revisada 2167A de EE.UU. Departamento de Defensa. La revisión fue finalmente publicado como DoD Std 498.
La norma internacional se completó en 1995 con la designación, ISO / IEC12207, y se le dio el título de estándar para los procesos de ciclo de vida del software.
Std ISO / IEC 12207 proporciona un importante punto de partida para el conjunto de conocimientos capturados en este libro.

Era la Junta IEEE Computer Society de Gobernadores la aprobación de la moción presentada en mayo de 1993 mediante Fletcher Buckley, que dio
lugar a la redacción de este libro. La Association for Computing Machinery Consejo (ACM) aprobó una moción relacionada en agosto de 1993. Los dos
movimientos condujeron a un comité conjunto bajo la dirección de Mario Barbacci y Stuart Zweben que sirvió como co-presidentes. La declaración de la
misión de la comisión conjunta era “Establecer los conjuntos apropiados (s) de criterios y normas para la práctica profesional de la ingeniería de software
sobre el cual las decisiones industriales, certificación profesional, y programas de estudios pueden basarse.” Los grupos de trabajo del Comité Directivo
organizada en las siguientes áreas:

1. Definir requeridos conjunto de conocimientos y prácticas recomendadas;

2. Definir Ética y Normas Profesionales;

3. Definir la Educación Los planes de estudios de pregrado, postgrado y educación continua. Este libro suministra el primer componente: se
requiere conjunto de conocimientos y recomendar prácticas. El código de ética y práctica profesional de la ingeniería de software se completó en
1998 y aprobado tanto por el Consejo de ACM y la IEEE Computer Society Junta de Gobernadores. Ha sido adoptado por numerosas empresas y
otras organizaciones y está incluido en varios libros de texto recientes.

El plan de estudios para los estudiantes está siendo completada por un esfuerzo conjunto de la IEEE Computer Society y la ACM, y se
espera que esté terminado en 2004.

© IEEE - 2004 Versión vii

 Cada profesión se basa en un conjunto de conocimientos y prácticas recomendadas, a pesar de que no siempre se definen de una manera precisa. En
muchos casos, éstos se documentan formalmente, por lo general en una forma que les permite ser utilizado para fines tales como la acreditación de programas
académicos, el desarrollo de programas de educación y formación, la certificación de especialistas, o licencia profesional. En general, una sociedad profesional
u organismo relacionado mantiene la custodia de una definición formal de este tipo. En los casos en que no exista tal formalidad, el conjunto de conocimientos y
prácticas recomendadas son “generalmente reconocido” por los médicos y puede ser codificado en una variedad de maneras para diferentes usos.

Se espera que los lectores encontrarán este libro útil para guiarlos hacia el conocimiento y los recursos que necesitan en su desarrollo profesional
permanente como profesionales de la ingeniería de software.

El libro está dedicado a Fletcher Buckley en reconocimiento a su compromiso con la promoción de la ingeniería de software como una disciplina profesional y
su excelencia como un practicante de ingeniería de software en aplicaciones de radar.

Leonard L. Tripp, Fellow de IEEE 2003

Presidente del Comité de Prácticas Profesionales, IEEE Computer Society, (2001-2003)

Presidente del Comité Directivo Conjunto IEEE Computer Society y ACM para el Establecimiento de
Ingeniería de Software como una silla de Profesión (1998-1999), Comité de Normas de Ingeniería de Software,
IEEE Computer Society (1992-1998)

viii © IEEE - 2004 Versión

 UN sociado mi ditores
Las siguientes personas sirvieron como editores asociados, ya sea para la versión de ensayo publicado en 2001
o para la versión 2004.

Requisitos de Software
PeterSawyer y Gerald Kotonya, Departamento de Informática, Universidad de Lancaster, Reino Unido, {} p.sawyer {g.kotonya}@lancaster.ac.uk

Diseño de software
Chico Tremblay, departamento de Informática, UQAM, Canadá, tremblay.guy@uqam.ca
Construcción de software
Steve McConnell, Construx Software, EE.UU., Steve.McConnell@construx.com
Terry Bollinger, la MITRE Corporation, EE.UU., terry@mitre.org
Philippe Gabrini, departamento de Informática, UQAM, Canadá,
gabrini.philippe@uqam.ca
Luis Martín, departamento de Informática, UQAM, Canadá,
martin.louis@uqam.ca
Software Pruebas
Antonia Bertolino y Eda Marchetti, ISTI-CNR, Italia, antonia.bertolino
{} {} eda.marchetti @ isti.cnr.it
Mantenimiento del software
Thomas M. Pigoski, Techsoft Inc., EE.UU., tmpigoski@techsoft.com
Alain abril de Escuela de Tecnología Superior, Canadá, aapril@ele.etsmtl.ca
Gestión de la Configuración de Software
John A. Scott, Lawrence Livermore National Laboratory, EE.UU., scott7 @ LLNL, gov
David Nisse, EE.UU., nissed@worldnet.att.net
Gestión de Ingeniería de Software
Dennis Frailey, Raytheon Company, EE.UU., DJFrailey@Raytheon.com
Stephen G. MacDonell, Universidad de Tecnología de Auckland, Nueva Zelanda,
smacdone@aut.ac.nz
Andrew R. Gray, Universidad de Otago, Nueva Zelanda
Proceso de Ingeniería de Software
Khaled El Eman, sirvió mientras que en el Consejo de Investigación Nacional de Canadá, Canadá,
khaled.el-emam@nrc-cnrc.gc.ca
Herramientas de software y métodos Engineerting
David Carrington, Facultad de Tecnología de la Información y la ingeniería eléctrica, la Universidad de
Queensland, Australia, davec@itee.uq.edu.au

Calidad del software

Alain abril de Escuela de Tecnología Superior, Canadá, aapril@ele.etsmtl.ca
Dolores Wallace, se retiró del Instituto Nacional de Estándares y Tecnología, EE.UU.
Dolores.Wallace@nist.gov
Larry Reeker, NIST, EE.UU., Larry.Reeker@nist.gov
referencias Editor
Marc Bouisset, departamento de Informática, UQAM, Bouisset.Marc@uqam.ca

© IEEE - 2004 Versión ix

X © IEEE - 2004 Versión
 Asesor industrial
segundo UNTA

En el momento de la publicación, las siguientes personas formaron el Consejo Asesor Industrial:

Mario R. Barbacci, Software Engineering Institute, que representa la IEEE Computer

Society

Carl Chang, representando Computing Curricula 2001

François Coallier, Escuela de Tecnología Superior, hablando como IEC JTC 1 / SC7 Presidente ISO /

Charles Howell, La Corporación MITRE Anatol Kark, Consejo

Nacional de Investigación de Canadá

Philippe Kruchten, Universidad de British Columbia, sirvió como representante de Rational Software

Laure Le Bars, SAP Labs (Canadá) Steve

McConnell, Construx Software Dan Nash,

Raytheon Company

Fred Otto, Consejo Canadiense de Ingenieros Profesionales (CCPE) Richard Metz,

The Boeing Company

Larry Reeker, Instituto Nacional de Estándares y Tecnología, Ministerio de

Comercio, EE.UU.

Las siguientes personas sirven junto con el IAB en la Junta de Control de Cambios Ejecutivo para la edición de 2004:

Donald Bagert, Rose-Hulman Institute of Technology, represening el Comité de Prácticas Profesionales

IEEE Computer Society

Ann Sobel, Universidad de Miami, en representación del Comité de Dirección de Informática Los planes de estudios de

Ingeniería de Software

© IEEE - 2004 Versión xi

 PAG ANEL DE mi XPERTOS

Las siguientes personas que se presentan en el panel de expertos para la preparación de la versión de prueba de la Guía:

Steve McConnell, Construx Software Roger Pressman, RS

Pressman y Asociados Ian Sommerville, Universidad de

Lancaster, Reino Unido

xii © IEEE - 2004 Versión

 R EVISIÓN T EAM
Las siguientes personas participaron en el proceso de revisión de esta guía, para la versión de prueba y / o para la versión 2004.
Abbas, Rasha, Australia Abran, Alain,
Canadá Accioly, Carlos, Brasil Ackerman,
Frank, EE.UU. Akiyama, Yoshihiro, Japón
Al-Abdullah, Mohammad, EE.UU.
Alarcón, Miren Idoia, España Alawy,
Ahmed, EE.UU. Alleman, Glen, EE.UU.
Allen, Bob, Canadá Allen, David, EE.UU.
Amorosa, Francesco, Italia Amyot,
Daniel, Canadá Andrade, Daniel, Brasil
abril, Alain, Canadá
Arroyo-Figueror, Javier, EE.UU. Ashford,
Sonny, EE.UU. Atsushi, Sawada, Japón
Backitis Jr., Frank, EE.UU. Bagert,
Donald, EE.UU. Baker, Jr., David, EE.UU.
Baker, Theodore, EE.UU. Baldwin, Mark,
EE.UU. Bales, David , Reino Unido
Bamberger, Judy, EE.UU. Banerjee,
Bakul, EE.UU. Barber, Scott, EE.UU.
Barker, Harry, Reino Unido Barnes, Julie,
EE.UU. Barney, David, Australia Barros,
Rafael, Colombia Bastarache, Louis,
Canadá Bayer, Steven, EE.UU. Beaulac,
Adeline , Canadá Beck, William, EE.UU.
Beckman, Kathleen, EE.UU. A
continuación, Doreen, EE.UU.
Benediktsson, Oddur, Islandia
Ben-Menachem, Mordejai, Israel
Bergeron, Alain, Canadá Berler,
Alexander, Grecia Bernet, Martin,
EE.UU. Bernstein, Larry, EE.UU.
Bertram, Martin, Alemania Bialik,
Tracy, EE.UU. Bielikova, María,
Eslovaquia
© IEEE - 2004 Versión
Bierwolf, Robert, Países Bajos Bisbal,
Jesús, Irlanda Boivin, Michel, Canadá
Bolton, Michael, Canadá Bomitali,
Evelino, Italia Bonderer, Reto, Suiza
Bonk, Francisco, EE.UU. Booch,
Grady, EE.UU. Booker, Glenn,
EE.UU. Börstler, Jürgen, Suecia
Borzovs, Juris, Letonia Botting,
Richard, EE.UU. Bourque, Pierre,
Canadá Bowen, Thomas, EE.UU.
Boyd, Milt, EE.UU. Boyer, Ken,
EE.UU. Brashear, Phil, EE.UU.
Briggs, Steve, EE.UU. brillante,
Daniela, EE.UU. Brosseau, Jim,
Canadá Brotbeck, George, EE.UU.
Brown, Normand, Canadá Bruhn,
Anna, EE.UU. Brune, Kevin, EE.UU.
Bryant, Jeanne, EE.UU. Buglione,
Luigi, Italia Bullock, James, EE.UU.
Burns, Robert, EE.UU. Burnstein,
Ilene, EE.UU. Byrne, Edward, EE.UU.
Calizaya, Percy, Perú Carreón, Juan,
EE.UU. Carroll, Sue, EE.UU.
Carruthers, Kate, Australia Caruso,
Richard, EE.UU. Carvalho, Paul,
Canadá Case, Pam, EE.UU.
Cavanaugh, John, EE.UU. Celia, John
A.,EE.UU. Chalupa Sampaio, Alberto
Antonio, Portugal Chan, FT, Hong
Kong Chan, Keith, Hong Kong
Chandra, AK, India Chang, Wen-Kui,
Taiwán Chapin, Ned, EE.UU.
xiii
Charette, Robert, EE.UU. Chevrier,
Marielle, Canadá Chi, Donald, EE.UU.
Chiew, Vincent, Canadá Chilenski, John,
EE.UU. Chow, Keith, Italia Ciciliani,
Ricardo, Argentina Clark, Glenda, EE.UU.
Cleavenger, Darrell, EE.UU. Cloos,
Romain, Luxemburgo Coallier, François,
Canadá Coblenza, Brenda, EE.UU.
Cohen, Phil, Australia Collard, Ross,
Nueva Zelanda Collignon, Stephane,
Australia Connors, Kathy Jo, EE.UU.
Cooper, Daniel, EE.UU. Councill, Bill,
EE.UU. Cox, Margery, EE.UU. Cunin,
Pierre -Yves, Francia DaLuz, José,
EE.UU. Dampier, David, EE.UU. Daneva,
Maya, Canadá Daneva, Maya, Canadá
Daughtry, Taz, EE.UU. Davis, Ruth,
EE.UU. De Cesare, Sergio, Reino Unido
Dekleva, Sasa, EE.UU. Del Castillo,
Federico, Perú Del Dago, Gustavo,
Argentina DeWeese, Perry, EE.UU. Di
Nunno, Donn, EE.UU.-Díaz Herrera,
Jorge, EE.UU. Dieste, Oscar, España
Dion, Francis, Canadá Dixon, Wes,
EE.UU. Dolado, Javier,España
Donaldson, John, Reino Unido Dorantes,
Marco, México Dorofee, Audrey, EE.UU.
Douglass, Keith, Canadá Du, Weichang,
Canadá Duben, Anthony, EE.UU. Dudash,
Edward, EE.UU. Duncan, Scott, EE.UU.
Duong, Vinh, Canadá Durham, George,
Estados Unidos
Dutil, Daniel, Canadá Dutton,
Jeffrey, EE.UU. Ebert, Christof,
Francia Edge, Gary, EE.UU.
Edwards, Helen Maria, Reino Unido
El-Kadi, Amr, Egipto Endres, David,
EE.UU.
Engelmann, Franz, Suiza Escue, Marilyn,
EE.UU. Espinoza, Marco, Perú Fay,
Istvan, Hungría Fayad, Mohamed, EE.UU.
Fendrich, John, EE.UU. Ferguson,
Robert, EE.UU. Fernández, Eduardo,
EE.UU. Fernández-Sánchez, José Luis,
España
Filgueiras, Lucía, Brasil Finkelstein,
Anthony, Reino Unido Flinchbaugh,
Scott, EE.UU. Forrey, Arden, EE.UU.
Fortenberry, Kirby, EE.UU. Foster,
Henrietta, EE.UU. Fowler, Martin,
EE.UU. Fowler, John Jr., EE.UU. Fox,
Christopher, EE.UU. Frankl, Phyllis ,
EE.UU. Freibergs, Imants, Letonia
Frezza, Stephen, EE.UU. Fruehauf,
Karol, Suiza Fuggetta, Alfonso, Italia
Fujii, Roger, EE.UU. Fuschi, David
Luigi, Italia Fuschi, David Luigi, Italia
Gabrini, Philippe, Canadá Gagnon,
Eric, Canadá Ganor , Eitan, Israel
Garbajosa, Juan, España Garceau,
Benoît, Canadá García-Palencia,
Omar, Colombia
Garner, Barry, EE.UU. Gelperin,
David, EE.UU. Gersting, Judith,
Hawaii Giesler, Gregg, EE.UU. Gil,
Indalecio, España Gilchrist, Thomas,
EE.UU. Giurescu, Nicolae, Canadá
vidrio, Robert, EE.UU. Glynn, Garth,
Reino Unido Asistentes, Ron,
EE.UU. Gogates, Gregory, EE.UU.
Goldsmith, Robin, EE.UU.
Goodbrand, Alan, Canadá Gorski,
Janusz, Polonia Graybill, Marcos,
USA
Gresse von Wangenheim, Christiane, Brasil
Grigonis, George, EE.UU. Gupta, Arun,
EE.UU. Gustafson, David, EE.UU. Gutcher,
Frank, EE.UU. Haas, Bob, EE.UU. Agar,
Jon, EE.UU. Hagstrom, Erick, EE.UU.
Hailey, Victoria Hall, Duncan , Nueva
Zelanda Haller, John, EE.UU.
Halstead-Nussloch, Richard, EE.UU. Hamm,
Linda, EE.UU. Hankewitz, Lutz, Alemania
Harker, Rob, EE.UU. Hart, Hal, EE.UU. Hart,
Ronald, EE.UU. Hartner, Clinton, EE.UU.
Hayeck, Elie, EE.UU. él, Zhonglin, Reino
Unido Hedger, Dick, EE.UU. Hefner, Rick,
EE.UU. Heinrich, Marcos, EE.UU. Heinze,
Sherry, Canadá Hensel, Alan, EE.UU.
Herrmann, Debra, EE.UU. Hesse, Wolfgang,
Alemania Hilburn, Thomas, EE.UU. Hill,
Michael, EE.UU. Ho, Vinh, Canadá Hodgen,
Bruce, Australia Hodges, Brett, Canadá
Hoffman, Douglas, Canadá Hoffman,
Michael, EE.UU. Hoganson, Tammy,
EE.UU. Hollocker, Chuck, EE.UU. Horch,
John, EE.UU. Howard, Adrian, Reino Unido
Huang, Hui Min ,EE.UU. Hung, Chih-Cheng,
EE.UU. Hung, Peter, EE.UU. Hunt, Teresa,
EE.UU. Hunter, John, EE.UU. Hvannberg,
Ebba Thora, Islandia Hybertson, Duane,
EE.UU. Ikiz, Seckin, Turquía Iyengar,
Dwaraka, EE.UU. Jackelen, George,
EE.UU. Jaeger , Dawn, EE.UU. Jahnke,
Jens, Canadá James, Jean, EE.UU. Jino,
Mario, Brasil Johnson, Vandy, EE.UU.
xiv
Jones, Griffin, EE.UU. Jones, James E.,
EE.UU. Jones, Alan, Reino Unido Jones,
James, EE.UU. Jones, Larry, Canadá
Jones, Paul, EE.UU. Ju, Dehua,
China-Juan Martínez, Fernando Manuel-,
España Juhasz, Zoltan, Hungría Juristo,
Natalia, España Kaiser, Michael, Suiza
Kambic, George, EE.UU. Kamthan,
Pankaj, Canadá Kaner, Cem, EE.UU.
Kark, Anatol, Canadá Kasser, Joe, EE.UU.
Kasser, José, Australia Katz, Alf, Australia
Kececi, Nihal, Canadá Kell, Penélope,
EE.UU. Kelly, Diane, Canadá Kelly, Frank,
EE.UU. Kenett, Ron, Israel Kenney, Mary
L., EE.UU. Kerievsky, Joshua, EE.UU.
Kerr, John, EE.UU. Kierzyk, Robert,
EE.UU. Kinsner, W., Canadá Kirkpatrick
Harry, EE.UU. Kittiel, Linda, EE.UU.
Klappholz, David, EE.UU. Klein, Joshua,
Israel Caballero, Claire, Reino Unido
Knoke, Peter, EE.UU. Ko, Roy, Hong Kong
Kolewe, Ralph, Canadá Komal, Surinder
Singh, Canadá Kovalovsky, Stefan, Austria
Krauth,Péter, Hungría Krishnan, Nirmala,
EE.UU. Kromholz, Alfred, Canadá
Kruchten, Philippe, Canadá Kuehner,
Natanael, Canadá Kwok, Hung Shui,
Canadá Lacroix, Dominique, Canadá
LaMotte, Stephen W., EE.UU. Tierra,
Susan, EE.UU. Lange, Douglas, EE.UU.
Laporte, Claude, Canadá Lawlis, Patricia,
EE.UU. Le, Thach, EE.UU. Leavitt,
Randal, Canadá Lebel Réjean, Canadá
Leciston, David, EE.UU. Lee, Chanyoung,
EE.UU.
© IEEE - 2004 Versión
Lehman, Meir (Manny), Reino Unido Leigh,
William, EE.UU. Lembo, Jim, EE.UU. lenss,
John, EE.UU. Leonard, Eugene, EE.UU.
Lethbridge, Timoteo, Canadá Leung,
Hareton, Hong Kong Lever, Ronald, Países
Bajos Levesque, Ghislain, Canadá Ley,
Earl, EE.UU.
Linders, Ben, Países Bajos
Linscomb, Dennis, EE.UU. poco,
Joyce Currie, EE.UU. Logan, Jim,
EE.UU.
De largo, Carol, Reino Unido Lounis,
Hakim, Canadá baja, Graham,
Australia Lutz, Michael, EE.UU. Lynch,
Gary, EE.UU. Machado, Cristina, Brasil
MacKay, Stephen, Canadá MacKenzie,
Garth, EE.UU. MacNeil, Paul, EE.UU.
Magel, Kenneth, EE.UU. red, Harold,
EE.UU. Malak, Renee, EE.UU.
Maldonado, José Carlos, Brasil Marcos,
Esperanza, España Marinescu, Radu,
Rumania Marm, Waldo, Perú Marusca,
Ioan, Canadá Matlen, Duane, EE.UU.
Matsumoto, Yoshihiro, Japón McBride,
Tom, Australia McCarthy, Glenn, EE.UU.
McChesney, Ian, Reino Unido McCormick,
Thomas, Canadá McCown, Christian,
EE.UU. McDonald, Jim, EE.UU. McGrath
Carroll, Sue, EE.UU. McHutchison, Diane,
EE.UU. McKinnell, Brian, Canadá
McMichael, Robert, EE.UU. McMillan,
William, EE.UU. McQuaid, Patricia, EE.UU.
Mead, Nancy , ESTADOS UNIDOS
Meeuse, Jaap, Países Bajos Meier,
Michael, EE.UU. Meisenzahl, Christopher,
EE.UU. Melhart, Bonnie, EE.UU. Mengel,
Susan, EE.UU. Meredith, Denis, EE.UU.
Meyerhoff, Dirk, Alemania Mili, Hafedh,
Canadá Miller, Chris, Países Bajos Miller,
Keith, Estados Unidos
© IEEE - 2004 Versión
Miller, Mark, EE.UU. Miranda, Eduardo,
Canadá Mistrik, Ivan, Alemania
Mitasiunas, Antanas, Lituania Modell,
Howard, EE.UU. Modell, Staiger, EE.UU.
Modesitt, Kenneth, EE.UU. Moland,
Kathryn, EE.UU. Moldavsky, Symon,
Ucrania Montequín, Vicente R. , España
Moreno, Ana María, España Mosiuoa,
Tseliso, Lesotho Moudrý, James, EE.UU.
Msheik, Hamdan, Canadá Mularz, Diane,
EE.UU. Mullens, David, EE.UU.
Müllerburg, Monika, Alemania Murali,
Nagarajan, Australia Murphy, Mike,
EE.UU. Napier, John, EE.UU.
Narasimhadevara, Sudha, Canadá
Narawane, Ranjana, India Narayanan,
Ramanathan, India Navarro Ramírez,
Daniel, México
Navas Plano, Francisco, España Navrat,
Pavol, Eslovaquia Neumann, Dolly,
EE.UU.-Nguyen Kim, Hong, Canadá
Nikandros, George, Australia Nishiyama,
Tetsuto, Japón Nunn, David, EE.UU.
O'Donoghue, David, Irlanda Oliver, David
John, Australia Olson, Keith, EE.UU.
Oskarsson, Östen, Suecia Ostrom,
Donald, EE.UU. Oudshoorn, Michael,
Australia Owen, cereza, EE.UU. Pai,
Hsueh-Ieng, Canadá Parrish, Lee,
EE.UU. Parsons, Samuel, EE.UU. Patel,
Dilip, Reino Unido Paulk, Marcos, EE.UU.
Pavelka, Jan, República Checa Pavlov,
Vladimir, Ucrania Pawlyszyn, Blanche,
EE.UU. Pecceu, Didier, Francia Perisic,
Branko, Yugoslavia Perry, Dale, EE.UU.
Peters, Dennis, Canadá Petersen, Erik,
Australia Pfahl, Dietmar, Alemania
Pfeiffer , Martin, Alemania Phillips,
Dwayne, EE.UU.
xv
Phipps, Robert, EE.UU. Phister, Paul,
EE.UU. Phister, Jr., Paul, EE.UU. Piattini,
Mario, España Piersall, Jeff, EE.UU. Pillai,
SK, India Pinder, Alan, Reino Unido
Pinheiro, Francisco A., Brasil Plekhanova,
Valentina, Estados Unido Poon, Peter,
EE.UU. Poppendieck, María, EE.UU.
Powell, Mace, EE.UU. Predenkoski,
María, EE.UU. Prescott, Allen, EE.UU.
Pressman, Roger, EE.UU. Precio, Arte,
EE.UU. Precio, Margaretha, EE.UU.
Pullum, Laura, EE.UU. sobrecargo, Keith,
EE.UU. Purssey, John, Australia
Pustaver, John, EE.UU. Quinn, Anne,
EE.UU. Radnell, David, Australia Rae,
Andrew, Reino Unido Rafea, Ahmed,
Egipto Ramsden, Patrick, Australia Rao,
N.Vyaghrewara, India Rawsthorne, Dan,
EE.UU. lector , Katherine, EE.UU. Reddy,
Vijay, EE.UU. Redwine, Samuel, EE.UU.
Reed, Karl, Australia Reedy, Ann, EE.UU.
Reeker, Larry, EE.UU. Rethard, Tom,
EE.UU. Reussner, Ralf, Alemania Ríos,
Joaquín, España Risbec, Felipe,Francia
Roach, Steve, EE.UU. Robillard, Pierre,
Canadá Rocha, Zalkind, Brasil Rodeiro
Iglesias, Javier, España
Rodríguez-Dapena, Patricia, España
Rogoway, Paul, Israel Rontondi, Guido,
Italia Roose, Philippe, Francia Rosca,
Daniela, EE.UU. Rosenberg , Linda,
EE.UU. Rourke, Michael, Australia Rout,
Terry, Australia Rufer, Russ, EE.UU.
Ruiz, Francisco, España Ruocco,
Anthony, EE.UU. Rutherfoord, Rebecca,
EE.UU.
Ryan, Michael, Irlanda Salustri,
Filippo, Canadá Salustri, Filippo,
Canadá Salwin, Arthur, EE.UU.
Sanden, Bo, EE.UU.
Sandmayr, Helmut, Suiza Santana Filho,
Ozeas Vieira, Brasil
Sato, Tomonobu, satyadas Japón,
Antony, EE.UU. Satyadas, Antony,
EE.UU. Schaaf, Robert, EE.UU.
Scheper, Charlotte, EE.UU. Schiffel,
Jeffrey, EE.UU. Schlicht, cuenta,
EE.UU. Schrott, William, EE.UU.
Schwarm, Stephen, EE.UU.
Schweppe, Edmund, EE.UU. Sebern,
Marcos, EE.UU. Seffah, Ahmed,
Canadá Selby, Nancy, EE.UU. Selph,
William, EE.UU. Sen, Dhruba,
EE.UU. Senechal, Raymond, EE.UU.
Sepúlveda, Christian, EE.UU. Setlur,
Atul, EE.UU. Sharp, David, EE.UU.
Shepard, Terry, Canadá Pastor, Alan,
Alemania Shillato, Rrobert W, EE.UU.
Shintani, Katsutoshi, Japón Silva,
Andrés, España Silva, Andrés,
España Singer, Carl, EE.UU. Sinnett,
Paul, Reino Unido Sintzoff, André,
Francia Sitte, Renate, Australia Cielo,
Richard, EE.UU. Caritas, Kevin,
EE.UU. Smith, David, EE.UU.
Sophatsathit, Peraphon, Tailandia
Sorensen, Reed, EE.UU. Soundarajan,
Neelam, EE.UU. Sousa Santos, Federico,
Portugal Spillers, Marcos, EE.UU.
Spinellis, Diomidis, Grecia Splaine, Steve,
EE.UU. Springer, Donald, EE.UU. Staiger,
John, EE.UU. Starai, Thomas, EE.UU.
Steurs, Stefan, Bélgica St-Pierre, Denis,
Canadá Stroulia, Eleni, Canadá
Subramanian, KS, India Sundaram, Sai,
Reino Unido Swanek, James, EE.UU.
Swearingen, Sandra, EE.UU. Szymkowiak,
Paul, Canadá Tamai, Tetsuo, Japón
Tasker, Dan, Nueva Zelanda Taylor ,
Stanford, EE.UU. Terekhov, Andrey A.,
Federación de Rusia, Terski, Matt, EE.UU.
Thayer, Richard, EE.UU. Thomas,
Michael, EE.UU. Thompson, A. Allan,
Australia Thompson, John Barrie, Reino
Unido Tito, Jason, EE.UU. Tockey, Steve,
EE.UU. Tovar, Edmundo, España
Towhidnejad, Massood, EE.UU. Trellue,
Patricia, USA Trèves, Nicolas, Francia
Troy, Elliot, EE.UU. Tsui, Frank, EE.UU.
Tsuneo, Furuyama, Japón Tuohy,
Kenney,EE.UU. Tuohy, Marsha P., EE.UU.
Turczyn, Stephen, EE.UU. Upchurch,
Richard, EE.UU.
xvi
Urbanowicz, Theodore, EE.UU. Van Duine,
Dan, EE.UU. Van Ekris, Jaap, Países Bajos
Van Oosterhout, Bram, Australia Vander
Plaats, Jim, EE.UU. Vegas, Sira, España
Verner, junio, EE.UU. Villas-Boas, André,
Brasil Vollman, Thomas, EE.UU. Walker,
Richard, Australia Walsh, Bucky, EE.UU.
Wang, Yingxu, Suecia desgaste, Larry,
EE.UU. Weigel, Richard, EE.UU.
Weinstock, Charles, EE.UU. Wenyin, Liu,
china Werner, Linda, EE.UU. Wheeler,
David, EE.UU. blanca, Nathan, EE.UU.
blanca, Stephanie, EE.UU. Whitmire, Scott,
EE.UU. Wijbrans, Klaas, Países Bajos
Wijbrans-Roodbergen, Margot, Países
Bajos Wilkie, Frederick, Reino Unido Wille,
Cornelius, Alemania Wilson, Charles,
EE.UU. Wilson, León, EE.UU. Wilson,
Russell, EE.UU. Woechan, Kenneth,
EE.UU. Woit, Denise, Canadá Yadin,
Aharon, Israel Yih, Swu, Taiwán joven,
Michal, EE.UU. Yrivarren, Jorge, Perú
Znotka, Juergen, Alemania Zuser,
Wolfgang,Austria Zvegintzov, Nicholas,
EE.UU. Zweben, Stu, EE.UU.
© IEEE - 2004 Versión
 La siguiente moción fue aprobada por unanimidad por el Consejo Asesor Industrial
el 6 de febrero de 2004.

El Consejo Asesor Industrial encuentra que la ingeniería del cuerpo software de proyecto Conocimiento iniciada en 1998 se ha
completado con éxito; y hace suya la versión de la Guía de la SWEBOK 2004 y lo recomienda a la Junta IEEE Computer Society
de Gobernadores para su aprobación.

La siguiente moción aprobada por el Consejo IEEE Computer Society de Gobernadores

en febrero de 2004.

Movido, que la Junta de Gobernadores de la IEEE Computer Society aprueba la edición de la Guía de la Ingeniería de Software de
Administración de Conocimiento 2004 y autoriza al Presidente del Comité de Prácticas Profesionales para continuar con la impresión.

© IEEE - 2004 Versión xvii

xviii © IEEE - 2004 Versión
 PAG REVESTIR DE NUEVO
La ingeniería de software es una disciplina emergente y hay
tendencias inequívocas que indican un creciente nivel de madurez:
Varias universidades de todo el mundo ofrecen títulos de
grado en ingeniería de software. Por ejemplo, estos grados se
ofrecen en la Universidad de Nueva Gales del Sur (Australia),
Universidad de McMaster (Canadá), el Instituto de Tecnología
de Rochester (EE.UU.), la Universidad de Sheffield (Reino
Unido) y otras universidades. En los EE.UU,
la Acreditación de Ingeniería
Comisión de la Junta de Acreditación de Ingeniería y
Tecnología (INSTIGAR)
responsable de la acreditación de programas de ingeniería de
software de grado.
La Sociedad de Procesamiento de la Información de Canadá ha
publicado criterios para acreditar los programas universitarios de
grado de ingeniería de software. Modelo de Capacidad y Madurez
del Software Engineering Institute for Software (SW CMM) y el
Modelo de Madurez de nueva capacidad
Integración
(CMMI) se utilizan para evaluar la capacidad de organización de
ingeniería de software. Las famosas normas de gestión de
calidad ISO 9000 se han aplicado a la ingeniería de software por
la nueva norma ISO / IEC 90003.
La Junta de Ingenieros Profesionales de Texas ha comenzado a
licenciar los ingenieros de software profesionales. La Asociación de
Ingenieros Profesionales y geocientíficos de la Columbia Británica
(APEGBC) ha comenzado a registrar los ingenieros profesionales
de software y del Ingenieros Profesionales de Ontario (PEO) ha
anunciado también los requisitos para la concesión de licencias. La
Association for Computing Machinery (ACM) y la Sociedad de
Computación del Instituto de Ingenieros Eléctricos y Electrónicos
(IEEE) han desarrollado conjuntamente y adoptado un Código de
Ética y Práctica Profesional para los profesionales de ingeniería de
software 1.
El IEEE Computer Society ofrece la certificación Profesional
Desarrollo de Software Certificado para la ingeniería de
software. El Instituto para la Certificación de Profesionales de
Informática (CIPC)
1 El ACM / CS Software Código de Ética y de Ingeniería
La práctica profesional se puede encontrar en:
http://www.computer.org/certification/ethics.htm
© IEEE - 2004 Versión
ha ofrecido durante mucho tiempo una certificación para los profesionales de la
informática.
Todos estos esfuerzos se basan en la presunción de que existe un
conjunto de conocimientos que debe ser dominado por la práctica de
los ingenieros de software. El cuerpo de conocimiento existe en la
literatura que se ha acumulado en los últimos treinta años. Este libro
proporciona una guía para que el cuerpo de conocimientos.
PAG ROPÓSITO
El propósito de la Guía de la Ingeniería de Software de Administración de
Conocimiento es proporcionar una caracterización validado consensually-
es de los límites de la disciplina de la ingeniería de software y proporcionar un
acceso tópica en el Cuerpo de Conocimiento de apoyo que la disciplina. El
Cuerpo de Conocimiento se subdivide en diez áreas de ingeniería de
software Conocimiento (KA), además de un capítulo adicional que
proporciona una visión general de las áreas de conocimiento de las
disciplinas fuertemente relacionados. Las descripciones de la KAS están
diseñados para discriminar entre los diversos conceptos importantes, lo que
permite a los lectores a encontrar su camino rápidamente a temas de
interés. Al encontrar un tema, se recomienda acudir a documentos clave o
capítulos de libros seleccionados, ya que de manera sucinta presentan el
conocimiento. En navegar por la guía, los lectores en cuenta que el
contenido es marcadamente diferente de Ciencias de la Computación. Así
como la ingeniería eléctrica se basa en la ciencia de la física, la ingeniería
de software debe basarse, entre otros, a la informática. En ambos casos, sin
embargo, el énfasis es necesariamente diferente. Los científicos se
extienden nuestro conocimiento de las leyes de la naturaleza, mientras que
los ingenieros aplican las leyes de la naturaleza para construir artefactos
útiles, en virtud de una serie de limitaciones. Por lo tanto, el énfasis de la
Guía se coloca sobre la construcción de artefactos de software útiles.
Los lectores también se dará cuenta de que muchos aspectos importantes de la
tecnología de la información, que pueden constituir un importante conocimiento de
ingeniería de software, no están cubiertos en la Guía;
que incluyen: programación específica
lenguajes, bases de datos y redes relacionales. Esto es una consecuencia de
un enfoque basado en la ingeniería. En todos los campos, no
Sólo informática de los diseñadores de
planes de estudios de ingeniería se han dado cuenta que las tecnologías
específicas son reemplazadas mucho más rápidamente que la fuerza de
trabajo de ingeniería. Un ingeniero debe estar equipado con el conocimiento
esencial que apoya la selección de
la tecnología apropiada en el
tiempo apropiado en la circunstancia adecuada. por
xix
ejemplo, el software podría construirse en Fortran utilizando la
descomposición funcional o en C ++ usando técnicas orientadas a
objetos. Las técnicas para la configuración de instancias de software de
estos sistemas serían muy diferentes. Pero,
los principios y objetivos de
gestión de la configuración siguen siendo los mismos. La guía, por tanto,
no se centra en las tecnologías que cambian rápidamente, aunque se
describen sus principios generales en áreas de conocimiento relevantes.
Estas exclusiones demuestran que esta guía es necesariamente
incompleto. La guía abarca los conocimientos de ingeniería de software
que es necesario, pero no suficiente para un ingeniero de software. La
práctica de los ingenieros de software tendrá que saber muchas cosas
acerca de la informática, gestión de proyectos e ingeniería de sistemas,
por nombrar algunos-que caen fuera del Cuerpo de Conocimiento que
se caracteriza por la presente Guía. Sin embargo, indica que esta
información debe ser conocido por los ingenieros de software no es lo
mismo que afirmar que este conocimiento está dentro de los límites de
la disciplina de la ingeniería de software. En su lugar, debe tenerse en
cuenta que los ingenieros de software necesitan saber algunas cosas
tomadas de otras disciplinas, y ese es el planteamiento de esta Guía.
Asi que, esta guía caracteriza el Cuerpo de Conocimiento que cae
dentro del ámbito de la ingeniería de software y proporciona referencias
a información relevante de otras disciplinas. Un capítulo de la Guía
proporciona una descripción taxonómica de las disciplinas relacionadas
con derivados de fuentes autorizadas.
El énfasis en la práctica de la ingeniería lleva la guía hacia una fuerte
relación con la literatura normativa. La mayor parte de la literatura
informática, tecnología de la información e ingeniería de software
proporciona información útil a los ingenieros de software, pero una
parte relativamente pequeña es normativa. Un documento normativo
prescribe lo que un ingeniero debe hacer en una situación
especificada en lugar de proporcionar información que pueda ser útil.
La literatura normativa es validado por consenso entre los
profesionales formados y se concentra en las normas y documentos
relacionados. Desde el principio, el proyecto SWEBOK fue concebido
como teniendo una fuerte relación con la literatura normativa de la
ingeniería de software. Los dos principales organismos de
normalización para la ingeniería de software (Comité de Normas de
Ingeniería IEEE Computer Society Software e ISO / IEC JTC 1 / SC7)
están representados en el proyecto. En última instancia, esperamos
que las normas prácticas de ingeniería de software contendrán
principios atribuirse directamente a la Guía.
yo NTENDED UN úblico
La guía está orientada a una variedad de audiencias, en todo el mundo. Su
objetivo es servir a las organizaciones públicas y privadas en la necesidad de
una visión coherente del software
xx
ingeniería para definir los requisitos de educación y formación,
clasificación trabajos, desarrollando
políticas de evaluación de desempeño o que especifican las tareas de
desarrollo de software. También se ocupa de la práctica, o dirigiendo,
ingenieros de software y los funcionarios
responsable de la política pública con respecto a la concesión de licencias y las
normas profesionales. Además, las asociaciones profesionales y educadores
que definen las reglas de certificación, las políticas de acreditación de los
programas de estudios universitarios, y directrices para la práctica profesional
se beneficiarán de SWEBOK, así como los estudiantes que están aprendiendo
la profesión de ingeniería de software y educadores y formadores que
participan en la definición del contenido planes de estudios y curso.
mi VOLUTION DE LA GRAMO GUÍA DEL USUARIO
De 1993 a 2000, el IEEE Computer Society y de la Association for
Computing Machinery (ACM) cooperaron en la promoción de la
profesionalización de la ingeniería de software a través de su Comité
de Coordinación conjunta de Ingeniería de Software (SWECC). El
Código de Ética se completó bajo la administración de la SWECC
principalmente a través de esfuerzos voluntarios. El proyecto fue
iniciado por SWEBOK la SWECC en
1998.
El alcance del proyecto SWEBOK, la variedad de
comunidades involucradas, y la necesidad de una amplia
participación sugirieron la necesidad de tiempo completo en lugar de
la gestión de voluntarios. Para este fin, la Sociedad Informática
IEEE-contrajo el Laboratorio de Investigación de Software de
Gestión de Ingeniería de la Universidad de Quebec en Montreal
(UQAM) para gestionar el esfuerzo. En los últimos años, se ha unido
a la UQAM por el Superior de Tecnología École, Montreal, Quebec.
El plan de proyecto compuesto por tres fases sucesivas: Hombre de
paja, Stoneman y Ironman. Un primer prototipo, Strawman, demostró
cómo podría organizarse el proyecto. La publicación de la versión de
prueba de amplia difusión de la Guía en 2001 marcó el final de la
fase de Stoneman del proyecto e inició un período de uso juicio.
El equipo del proyecto desarrolló dos importantes principios para guiar
el proyecto: transparencia y consenso.
Por transparencia, nos referimos a que el proceso de desarrollo en sí está
documentado, publicado y difundido de manera que las decisiones
importantes y el estado son visibles para todas las partes involucradas. Por
consenso, se entiende que el único método práctico para legitimar una
declaración de este tipo es a través de una amplia participación y el acuerdo
de todos los sectores importantes de la comunidad pertinente. Literalmente
cientos de colaboradores, revisores, y el juicio
© IEEE - 2004 Versión
usuarios han jugado un papel importante en la producción del documento actual.
Al igual que cualquier proyecto de software, el proyecto SWEBOK tiene muchas
partes interesadas, algunas de las cuales están representadas formalmente. Un
Consejo Asesor Industrial, compuesto por representantes de la industria
(Boeing, Construx de software, la MITRE Corporation, Rational Software,
Sistemas de Raytheon, y laboratorios de Canadá-SAP), los organismos de
investigación
(Nacional Instituto de Estándares y
Tecnología, Consejo Nacional de Investigación de Canadá), el
Consejo Canadiense de Ingenieros Profesionales, y la IEEE Computer
Society, han proporcionado apoyo financiero para el proyecto.
generoso apoyo de la IAB nos permite hacer que los productos del
proyecto SWEBOK a disposición del público sin ningún tipo de cargo
(visita http://www.swebok.org).
de miembros de IAB
complementado con las sillas de la norma ISO / IEC JTC 1 / SC7 y la iniciativa de
computación relacionados con los planes de estudio 2001. Los comentarios IAB y
aprueba los planes del proyecto, supervisa la creación de consenso y los
procesos de revisión, promueve el proyecto, y da credibilidad al esfuerzo. En
general, se garantiza la relevancia de los esfuerzos para real las necesidades
mundiales.
La versión de prueba de la Guía fue el producto de una extensa revisión y
comentarios. En tres ciclos de revisión pública, un total de
aproximadamente 500 los colaboradores de 42 países proporcionan
aproximadamente 9.000 comentarios, todos los cuales están disponibles en
www.swebok.org. Para producir la versión actual, hemos lanzado la versión
de prueba para el uso extenso ensayo. aplicación de prueba en estudios
especializados resultó en 17 artículos que describen los aspectos positivos
de la guía, así como los aspectos que necesitan mejorar. Una encuesta
basada en la web capturado experiencia adicional: 573 personas de 55
países registrados para la encuesta; 124 los colaboradores de 21 países
efectivamente prestados comentarios-1020 de
ellos. Adicional
sugerencias para mejorar el resultado de enlace con las
organizaciones y los esfuerzos: IEEE-CS / ACM Computing carreras
de Ingeniería de Software; el proyecto IEEE-CS Certificado de
desarrollo de software profesional; ISO / IEC JTC 1 / SC7 (ingeniería
de software y sistemas
normas), el IEEE Software
Comité de Normas de Ingeniería; el americano
Sociedad para la Calidad, División de Software; y una sociedad
profesional de la ingeniería, el Consejo Canadiense de Ingenieros
Profesionales.
do AMBIOS S esde T RIAL V ersion
El objetivo general de la revisión actual era mejorar la legibilidad,
consistencia y facilidad de uso de la Guía. Esto implicó una reescritura
general de todo el texto para hacer el estilo coherente en todo el
documento. En varios casos, el desglose por temas de los KA fue
reorganizado para que sea más fácil de usar, pero estábamos cuidado
de incluir la misma información que fue aprobada por
© IEEE - 2004 Versión
el proceso de consenso antes. Se actualizó la lista de referencia por
lo que sería más fácil de obtener las referencias.
el uso de ensayo dio lugar a la recomendación de que tres áreas de
conocimiento deben reescribirse. Los profesionales señalaron que la
construcción KA era difícil de aplicar en un contexto práctico. El KA
Gestión se percibe como demasiado cerca de la gestión general y no
suficientemente específicas a las preocupaciones de ingeniería de
software. El KA Calidad fue visto como una mezcla incómoda de la
calidad del proceso y la calidad del producto; fue revisado para
enfatizar este último. Por último, algunos KAs fueron revisados ​para
eliminar el material duplicar la de otra KAs.
es L IMITACIONES
A pesar de que la Guía ha pasado por un desarrollo elaborado y
proceso de revisión, el seguimiento
limitaciones de este proceso deben ser reconocidos y declararon:
La ingeniería de software continúa siendo infundido con la nueva
tecnología y nuevas prácticas. La aceptación de nuevas técnicas
crece y las técnicas más antiguas se descartan. Los temas que
aparecen como “generalmente aceptado” en esta Guía son
cuidadosamente seleccionados en este momento.
Inevitablemente, sin embargo, la selección tendrá que
evolucionar. La cantidad de literatura que se ha publicado en la
ingeniería de software es considerable y el material de referencia
incluido en esta Guía no debe ser visto como una selección
definitiva, sino más bien como una selección razonable.
Obviamente, hay otros autores excelentes y excelentes
referencias que las incluidas en la Guía. En el caso de la guía, se
seleccionaron las referencias porque están escritos en Inglés,
fácilmente disponible, reciente, de fácil lectura, y tomados como
grupo-proporcionar cobertura de los temas dentro del material de
referencia importante y muy relevante KA escrito en otros idiomas
aparte del Inglés se han omitido en el material de referencia
seleccionado. Además, hay que considerar que
La ingeniería de software es una disciplina emergente. Esto es
especialmente cierto si se compara con ciertas disciplinas de
ingeniería más establecidos. Esto significa, en concreto que los
límites entre las áreas de conocimiento de ingeniería de
software y entre ingeniería de software y sus disciplinas
relacionadas siguen siendo una cuestión de evolución continua.
Por lo tanto, el contenido de esta guía deben ser vistos como una
caracterización “informado y razonable” de la swebok y como se
xxi
la línea de base para la futura evolución. Además, tenga en cuenta los responsables políticos de todo el mundo con respecto a la práctica y la
que la Guía no pretende ni pretende sustituir o modificar en forma definición de la ingeniería de software de ingeniería y, en particular.
alguna las leyes, normas y procedimientos que han sido definidos
por el oficial público

xxii © IEEE - 2004 Versión

Alain Abran James W. Moore
Editores ejecutivos de la Guía
Escuela de Tecnología Superior La Corporación MITRE
para el Cuerpo de Ingeniería
de Software
Conocimiento

Pierre Bourque Robert Dupuis

Los editores de la Guía de la
École de Technologie Supérieure Universidad de Quebec en Montreal
Ingeniería de Software
Cuerpo de conocimientos

Leonard Tripp
Presidente del Comité de
1999 Presidente
Prácticas Profesionales, IEEE
IEEE Computer Society
Computer Society

(2001-2003)

2004

El sitio web del proyecto SWEBOK es http://www.swebok.org/

reconocer la contribución indispensable de los cientos de

UN CKNOWLEDGMENTS
El editorial SWEBOK equipo de agradecimiento
agradece el apoyo proporcionado por los miembros del
Consejo Asesor Industrial. La financiación de este proyecto
ha sido proporcionada por la ACM, Boeing,
el Consejo Canadiense de
Ingenieros, Construx software, el equipo IEEE
Sociedad, MITRE
corporación, el Instituto Nacional de Estándares y Tecnología,
el Consejo Nacional de Investigación de Canadá, Rational
Software, Raytheon Company, y SAP Labs (Canadá). El
equipo está agradecido por el defensor proporcionado por el
Grupo de Expertos. El equipo también aprecia el importante
trabajo realizado por los Editores Asociados. También nos
gustaría expresar nuestro agradecimiento por el trabajo inicial
sobre las descripciones Área de Conocimiento completados
por Imants Freibergs, Stephen Frezza, Andrew Gray, Vinh T.
Ho, Michael Lutz, Larry Reeker, Guy Tremblay, Chris Verhoef,
y Sybille Wolff. El equipo editorial también debe
colaboradores. El equipo editorial también desea agradecer a
las siguientes personas que han contribuido al proyecto de
varias maneras: Marcos Ardis, Yussef Belkebir, Michel
Boivin, Julie Bonneau, Simon Bouchard, François Cossette,
Vinh Duong, Gilles Gauthier, Michèle Hébert, Paula Espino,
Richard W. Heiman, Julie Hudon,
Idrissa
Konkobo, René Koppel Lucette Lapointe, Claude Laporte,
Luis Molinié, Hamdan Msheik, Iphigénie N'Diyae, Serge
Oligny, Suzanne Paquette, Keith Paton, Dave Raimundo,
Normand Séguin, Paul Sinnett, Denis St-Pierre, Dale Strok,
Pascale Tardif , Louise Thibaudeau, Dolores Wallace,
Evariste Valery Bevo Wandji, y Michal joven.
Por último, seguramente hay otras personas que han contribuido
a esta guía, ya sea directa o indirectamente, cuyos nombres se
han omitido inadvertidamente. Para esas personas, ofrecemos
nuestro reconocimiento tácito y disculpas por tener un
reconocimiento explícito omitido aquí.

© IEEE - 2004 Versión xxiii

xxiv © IEEE - 2004 Versión

GUÍA DEL USUARIO
A pesar de los millones de profesionales de software en todo el mundo y
la presencia ubicua de software en nuestra sociedad, la ingeniería de
software ha alcanzado recientemente el estado de una disciplina de
ingeniería legítimo y una profesión reconocida.
El logro de consenso por la profesión en un cuerpo de la base de
conocimiento es un hito clave en todas las disciplinas y había sido
identificado por la IEEE Computer Society como cruciales para la evolución
de la ingeniería de software hacia el estatus profesional. Esta guía, escrita
bajo los auspicios del Comité de Prácticas Profesionales, es parte de un
proyecto de varios años diseñado para llegar a un consenso.
W SOMBRERO ES S OFTWARE mi NGENIERÍA?
El IEEE Computer Society define la ingeniería de software como:
“(1) La aplicación de un enfoque disciplinado cuantificable sistemática,
para el desarrollo, operación y mantenimiento de software; es decir, la
aplicación de la ingeniería de software.
(2) El estudio de los enfoques como en (1) “. 1
W Hat es una R ECOGNIZED PAG ROFESSION?
Para la ingeniería de software para ser plenamente conocida como una
disciplina de ingeniería legítimo y una profesión reconocida, un consenso
sobre un cuerpo de la base de conocimiento es imprescindible. Este hecho
está bien ilustrado por Starr cuando define lo que puede considerarse una
disciplina legítima y una profesión reconocida. En su libro ganador del premio
Pulitzer en la historia de la profesión médica en los EE.UU., afirma que:
“La legitimación de la autoridad profesional implica tres reclamaciones
distintivos: en primer lugar, que el conocimiento y la competencia de los
profesionales han sido validada por la comunidad de sus pares;
segundo,
conocimiento consensualmente validado descansa sobre bases racionales,
científicas; y en tercer lugar, que el juicio y el asesoramiento de los
profesionales están orientados a un conjunto de valores fundamentales, como
la salud. Estos aspectos de la legitimidad se corresponden con los tipos de
atributos-colegiales, cognitivos y morales, por lo general incluidas en la
expresión “profesión”. 2
1
“IEEE Standard Glosario de Terminología de Ingeniería de Software,” IEEE,
Piscataway, NJ std 610.12-1990, 1990.
2
P. Starr, la transformación social de la medicina americana: Básico
© IEEE - 2004 Versión
do CAPÍTULO 1 I INTRODUCCIÓN AL GRAMO
W HAT son los do ARACTERÍSTICAS DE A PAG ROFESSION?
Gary Ford y Norman Gibbs estudiaron varias profesiones reconocidas,
incluyendo la medicina, derecho, ingeniería y contabilidad. 3 Llegaron a la
conclusión de que una profesión de la ingeniería se caracteriza por varios
componentes:
Una inicial educación profesional en un plan de estudios validado por la
sociedad a través acreditación
El registro de aptitud para la práctica a través voluntaria
proceso de dar un título u obligatoria licencias
Especializado desarrollo de habilidades y educación profesional
continua
el apoyo comunitario a través de una sociedad profesional
Un compromiso con las normas de conducta a menudo se prescribe en una código
ético
Esta guía contribuye a los tres primeros de estos componentes. La
articulación de un conjunto de conocimientos es un paso esencial hacia el
desarrollo de una profesión, ya que representa un amplio consenso en
cuanto a lo que un profesional de la ingeniería de software debe saber. Sin
tal consenso, no examen de licencia puede ser validada, no curriculum
puede preparar a un individuo por un examen, y no hay criterios se pueden
formular para la acreditación de un programa de estudios. El desarrollo de
consenso es también un requisito previo
a la adopción de coherencia habilidades
desarrollo y programas de educación continua profesional en las
organizaciones.
W HAT son los O OBJETIVOS DE LA SWEBOK P PROYECTO?
La Guía no debe confundirse con el Cuerpo de Conocimiento mismo, que
ya existe en la literatura publicada. El propósito de la Guía es describir qué
parte del cuerpo de conocimiento es generalmente aceptado, para
organizar esa porción, y para proporcionar un acceso tópica a la misma.
que este
Información adicional sobre el significado dado a “generalmente aceptado”
se puede encontrar a continuación y en el Apéndice
A.
La Guía de los Fundamentos de Ingeniería de Software
Libros, 1982. p. 15.
3 G. Ford y NE Gibbs, “ Una Profesión maduro de software
Ingenieria, ”Software Engineering Institute, Universidad Carnegie Mellon, de Pittsburgh,
Pennsylvania, CMU Técnico / SEI-96-TR
004, enero de 1996.
1-1
Conocimiento (SWEBOK) se estableció con los cinco objetivos
siguientes:
1. Para promover una visión coherente de la ingeniería de software en todo
el mundo
2. Para aclarar el lugar y establecer los límites de la ingeniería de
software con respecto para otro
disciplinas como la informática, gestión de proyectos,
computadora Ingenieria,
matemáticas
3. Para caracterizar el contenido de la disciplina de la ingeniería de
software
4. Para proporcionar un acceso tópica en la Ingeniería de Software de
Administración de Conocimiento
5. Para proporcionar una base para el desarrollo curricular y de
certificación individual y el material de la concesión de licencias
El primero de estos objetivos, una vista de todo el mundo consistente de
ingeniería de software, fue apoyada por un proceso de desarrollo que dedica
aproximadamente 500 colaboradores de 42 países en la fase Stoneman
(1998 a 2001) que conduce a la versión de prueba, y más de 120
colaboradores de 21 países en la fase de Ironman (2003) que conduce a la
versión 2004. Más información sobre el proceso de desarrollo se puede
encontrar en el prólogo y en el sitio Web (www.swebok.org). Las sociedades
profesionales y aprendidos y los organismos públicos involucrados en la
ingeniería de software se pusieron en contacto oficialmente, conscientes de
este proyecto, e invitados a participar en el proceso de revisión. editores
asociados fueron reclutados de América del Norte, la cuenca del Pacífico, y
Europa. Las presentaciones sobre el proyecto se hicieron en varios lugares
internacionales y más están programadas para el próximo año.
El segundo de los objetivos, el deseo de establecer un límite para la
ingeniería de software, motiva la organización fundamental de la Guía. El
material que se reconoce como estar dentro de esta disciplina se organiza en
las diez primeras áreas de conocimiento (KAS) que figuran en la Tabla 1.
Cada uno de estos Kas es tratado como un capítulo de esta Guía.
tabla 1 Las áreas de conocimiento SWEBOK (KAS). Requisitos de software
Software de diseño de software de mantenimiento de la construcción de software
Las pruebas de software
herramientas y métodos de ingeniería de software de
proceso de ingeniería de gestión de ingeniería de software
software de gestión de configuración de software de
calidad de software
En el establecimiento de un límite, también es importante identificar qué
disciplinas comparten ese límite, ya menudo una intersección común, la
ingeniería de software. Con este fin, la Guía también reconoce ocho disciplinas
relacionadas, que se enumeran en la Tabla 2 (véase el capítulo 12, las
disciplinas relacionadas de Ingeniería de Software). Los ingenieros de software
deben, por supuesto, tener conocimiento del material de estos campos (y las
descripciones KA pueden hacer referencia a ellos). No es, sin embargo, un
objetivo de la Guía SWEBOK para caracterizar el conocimiento de las
y disciplinas relacionadas, sino más bien lo que el conocimiento es visto como
propios de la ingeniería de software.
Tabla 2 disciplinas relacionadas.
Ingeniería Informática Gestión de proyectos
Ciencias de la Computación Gestión de la calidad
administración la ergonomía del software
Matemáticas Ingeniería de Sistemas
MARIDO IERARCHICAL O ORGANIZACIÓN
La organización de los KA descripciones o capítulos soportes
el tercero de objetivos del proyecto, una
caracterización de los contenidos de la ingeniería de software. Las especificaciones
detalladas proporcionadas por el equipo de redacción del proyecto para los editores
asociados en relación con los contenidos de las descripciones KA se pueden
encontrar en el Apéndice
A.
La Guía se usa una organización jerárquica para descomponer cada KA en un
conjunto de temas con etiquetas reconocibles. Un desglose de dos o tres niveles
proporciona una forma razonable para buscar temas de interés. La guía trata los
temas seleccionados de una manera compatible con las principales escuelas de
pensamiento y con las averías que se encuentran generalmente en la industria y
en la literatura de ingeniería de software y estándares. Las averías de
temas no presumen particular,
dominios de aplicación, negocio utiliza, la gestión
filosofías, métodos de desarrollo, y así sucesivamente. La extensión de la
descripción de cada tema es sólo eso necesitaba comprender la naturaleza
generalmente aceptada de los temas y para que el lector encontrará éxito
material de referencia. Después de todo, el Cuerpo de Conocimiento se
encuentra en el material de referencia a sí mismos, y no en la Guía.
R Material y EFERENCIA METRO ATRIX
Para proporcionar un acceso tópica en el conocimiento de la cuarta parte de los
objetivos del proyecto, la guía identifica material de referencia para cada KA,
incluyendo capítulos de libros, artículos técnicos referenciados, u otras fuentes
reconocidas de información autorizada. Cada descripción KA también incluye
una matriz que relaciona el material de referencia a los temas mencionados. El
volumen total de literatura citada se pretende que sea adecuado para el
dominio, mediante la realización de una educación universitaria más cuatro
años de experiencia. En esta edición de la Guía, se asignaron todas KAs
1-2 © IEEE - 2004 Versión
alrededor de 500 páginas de material de referencia, y esta fue la incluido en el material de estudio para El software
especificación se invitó a los editores asociados a aplicar. Se puede ingeniería examen de licencia que los graduados tomarían después de
argumentar que algunos Kas, tales como diseño de software, por ejemplo, ganar cuatro años de experiencia laboral. A pesar de que este criterio es
merecen más páginas de material de referencia que otros. Dicha modulación específico para el estilo de los EEUU de la educación y no
se puede aplicar en futuras ediciones de la Guía. necesariamente se aplica a otros países, consideramos que es útil. Sin
embargo, los dos
definiciones de conocimiento generalmente aceptado deben ser vistos como
Cabe señalar que la Guía no pretende ser exhaustivo en sus citas. Mucho
complementarios.
material que es a la vez conveniente y excelente no se hace referencia. El
material fue seleccionado en parte porque, considerado en su colección
que proporciona cobertura de los temas descritos. L IMITACIONES RELACIONADOS CON EL formato de libro

re EPTH DE T RATAMIENTO
Desde el principio, se planteó la cuestión de la profundidad del tratamiento
de la Guía debe proporcionar. El equipo del proyecto adoptó un enfoque
que apoya la quinta parte del proyecto de
objetivos proporcionando una
el desarrollo curricular, la certificación y concesión de licencias. El equipo de
redacción aplica el criterio de generalmente aceptado
conocimiento, deben distinguirse de los conocimientos avanzados y la
investigación (sobre la base de la madurez) y de conocimiento
especializado (por motivos de carácter general de aplicación). La
definición procede de la Gestión de Proyectos
Instituto:
el conocimiento se aplica a la mayoría de los proyectos de la mayor parte del tiempo, y un
amplio consenso
eficacia". 4
El formato de libro para el que fue concebido esta edición tiene sus
limitaciones. La naturaleza de los contenidos sería mejor servido mediante
una estructura de hipertexto, donde un tema estaría vinculada a temas
distintos a los anteriores y posteriores a él en una lista inmediatamente.
Algunos límites entre Kas, sub-áreas, y así sucesivamente, también son a
veces relativamente arbitraria. Estos límites no se debe dar demasiada
Fundación para importancia. En la medida de lo posible, los punteros y enlaces se han dado
en el texto cuando sea relevante y útil.
Los vínculos entre KAs no son del tipo de entrada-salida. La KAS están
destinados a ser puntos de vista sobre el conocimiento que uno debe
poseer en ingeniería de software con respecto al KA en cuestión. La
“La forma generalmente aceptada
descomposición de la disciplina dentro KAs y el orden en que se
presentan los KAs no han de ser asimilado con cualquier método o
valida sus valor y
modelo particular. Los métodos se describen en el KA apropiado en la
Guía, y la propia guía no es uno de ellos.

Generalmente aceptado
las prácticas tradicionales establecidas
T ÉL K ONOCIMIENTO UN REAS
recomendados por muchas organizaciones
Prácticas utilizados sólo para ciertos tipos

Figura 1 traza los once capítulos y los temas importantes incorporados

dentro de ellos. Los primeros cinco KAs se presentan en la secuencia
tradicional ciclo de vida cascada. Sin embargo, esto no implica que la
Especializado

de software

Guía adopta o fomente el modelo de cascada, o cualquier otro modelo.

Avanzada e Investigación La KAS posteriores se presentan en orden alfabético, y los de las
prácticas innovadoras probados y utilizados solamente por disciplinas relacionadas se presentan en el capítulo anterior. Esto es
algunas organizaciones y conceptos todavía siendo idéntico a la secuencia en que se presentan en esta guía.
desarrolladas y probadas en organizaciones de

investigación

S ESTRUCTURA DE LAS DESCRIPCIONES KA

Figura 1 Categorías de conocimiento Sin embargo, el término Las descripciones KA se estructuran como sigue. En la introducción, se
“generalmente aceptado” no implica que el conocimiento designado debe presentan una breve definición de la KA, y una visión general de su
aplicarse de manera uniforme a todos los de ingeniería de software esfuerzos alcance y de su relación con otros KAs.
-cada las necesidades del proyecto determinan que-pero sí implica que,
ingenieros de software capaces competentes deben estar equipados con este
El desglose de los temas constituye el núcleo de cada descripción de
conocimiento para su aplicación potencial. Más precisamente, el conocimiento
KA, que describe la descomposición de la KA en sub-áreas, temas y
generalmente aceptado debe ser subtemas. Para cada tema o tópico sub, se da una breve descripción,
junto con una o más referencias.

4
Se eligió el material de referencia porque es
Una guía para la Dirección de Proyectos del Conocimiento, Edición 2000, Project
considerar que constituyen la mejor presentación de los conocimientos en
Management Institute, Newport Square, Pensilvania. www.pmi.org.
relación con el tema, teniendo en cuenta la

© IEEE - 2004 Versión 1-3

limitaciones impuestas sobre la elección de referencias (ver arriba). Una
matriz vincula los temas que el material de referencia. La última parte de la
descripción KA es la lista de referencias recomendadas. Apéndice A de
cada KA incluye sugerencias para la lectura adicional para aquellos
usuarios que deseen aprender más sobre los temas KA. Apéndice B se
presenta la lista de las normas más relevantes para el KA. Tenga en
cuenta que las citas entre corchetes “[]” en el texto
identificar las referencias recomendadas, mientras que los encerrados
entre paréntesis “()” identificar las referencias habituales utilizados para escribir o
para justificar el texto. Las primeras son para ser encontrado en la sección
correspondiente de la KA y el último en el Apéndice A de la KA.
Breves resúmenes de las descripciones KA y apéndices se dan a continuación.
Requisitos de software KA (véase la Figura 2, columna A)
Un requisito se define como una propiedad que debe ser exhibido con el fin de
resolver algunos problemas del mundo real. La primera subárea conocimiento
es s Requisitos OFTWARE fundamentos.
Eso incluye definiciones de software
requisitos de sí mismos, sino también de los principales tipos de requisitos:
Comparación productos y procesos, funcionales, frente a las propiedades
emergentes no funcionales. El sub-zona también describe la importancia de
los requisitos cuantificables y distingue entre sistemas y los requisitos de
software. La sub-área segundo conocimiento es el r proceso equirements, que
introduce el proceso en sí, la orientación de las cinco sub-áreas restantes y
mostrando cómo la ingeniería de requisitos encaja con los otros procesos
de ingeniería de software.
En él se describen los modelos de procesos, actores del proceso,
soporte de procesos y gestión, y la calidad y mejora de procesos.
La tercera sub-área es la obtención de requisitos, que se ocupa de los
requisitos de software donde provienen y cómo el ingeniero de software
pueden recogerlos. Incluye fuentes requisito y técnicas de obtención. El
cuarto sub-área, análisis de requerimientos, tiene que ver con el proceso
de análisis de las necesidades de:
detectar y resolver los conflictos entre los requisitos de descubrir
los límites del software y cómo debe interactuar con su entorno
elaborar
Requisitos del sistema a software
Requisitos
Requisitos análisis incluye requisitos
clasificación, el modelado conceptual, diseño arquitectónico y
requisitos asignación, y requisitos
negociación.
El quinto subárea es especificación de requisitos.
especificación de requisitos típicamente se refiere a la producción de un
documento, o su equivalente electrónico, que puede ser revisado
sistemáticamente, evaluada y aprobada. Para sistemas complejos, en
particular los de
1-4
la participación de los componentes no sustanciales de software, a medida que
se producen hasta tres diferentes tipos de documentos: definición del sistema,
sistema de especificación de requisitos, especificaciones y requisitos de
software. La sub-área se describen todos
tres documentos y el subyacente
ocupaciones. El sexto sub-área es validación de requisitos, cuyo objetivo es
recoger cualquier problema antes de recursos se comprometen a abordar
los requisitos. validación de requisitos tiene que ver con el proceso de
examinar los documentos de requisitos para garantizar que se están
definiendo el sistema correcto (es decir, el sistema que el usuario espera).
Se subdivide en las descripciones de la conducta de los requisitos de los
comentarios, prototipado y validación de modelos y pruebas de aceptación.
La séptima y última subzona es consideraciones prácticas.
En él se describen los temas que deben ser entendidos en la práctica.
El primer tema es la naturaleza iterativa del proceso de requisitos. El
siguiente tres temas son
fundamentalmente en la gestión del cambio y el mantenimiento de los
requisitos en un estado que refleja con precisión el software a construir,
o que ya se ha construido. Incluye la gestión del cambio, los atributos de
los requisitos y exigencias de rastreo. El último tema es la medición
requisitos.
Diseño de software KA (véase la figura 2, la columna b)
Según la definición IEEE [IEEE610.12-90], el diseño es tanto “el
proceso de definición de la arquitectura, componentes, interfaces y otras
características de un sistema o componente” y “el resultado del proceso
[que]”. El KA se divide en seis sub-áreas. El primero
presentes sub-área el diseño de software
fundamentos, que forman una base subyacente a la comprensión de la
función y el alcance de diseño de software. Estos son los conceptos
generales de soporte lógico, el contexto del diseño de software, el proceso de
diseño de software, y las técnicas favorables para el diseño de software. Los
segundos grupos sub-área juntos el cuestiones clave en el diseño de
software. Incluyen concurrencia, control y manejo de eventos, distribución de
componentes, el error y el manejo de excepciones y tolerancia a fallos, la
interacción y la presentación, y la persistencia de datos. La tercera sub-área
es estructura y arquitectura de software,
los temas de los cuales son estructuras arquitectónicas y puntos de vista,
estilos arquitectónicos, patrones de diseño, y, por último, las familias de
programas y marcos. El cuarto sub-área describe software de análisis de la
calidad del diseño y la evaluación. Si bien no es un entero KA dedicado a la
calidad del software, esta sub-área se presentan los temas específicamente
relacionados con el diseño de software. Estos aspectos son los atributos de
calidad, análisis de calidad y técnicas de evaluación y medidas. La quinta
sub-área es notaciones de software de diseño, que son
© IEEE - 2004 Versión
divididos en las descripciones estructurales y de comportamiento. La última subzona
describe software de estrategias y métodos de diseño. En primer lugar, se describen
estrategias generales, seguido de métodos de diseño orientados a la función, los
métodos de diseño orientado a objetos,
estructura de datos diseño centrado,
diseño basado en componentes, y otros.
Construcción de Software KA (Véase la Figura 2, la columna c)
construcción de software se refiere a la creación detallada de software que
trabaja, significativa a través de una combinación de codificación, verificación,
pruebas unitarias, pruebas de integración y depuración. El KA incluye tres
sub-áreas. La primera sub-área es fundamentos de la construcción de software.
Los tres primeros temas son los principios básicos de la construcción: minimizar la
complejidad, anticipar el cambio, y las cuestiones técnicas, las cuestiones de gestión, la estimación de costos de
construir para su verificación. El último tema se describen las normas para la
construcción. El segundo sub-área describe la gestión de la construcción.
Los temas son los modelos de construcción, construcción
la planificación y la medición de la construcción. Las terceras cubiertas sub-área consideraciones Los temas aquí son los procesos de mantenimiento y actividades de
prácticas. Los temas son diseño de la construcción, construcción idiomas, codificación,
prueba de la construcción, la reutilización, la calidad de la construcción, y la
integración.
Pruebas de software (Véase la Figura 2, la columna d)
Pruebas de software consiste en la verificación dinámica del comportamiento de un
programa en un conjunto finito de casos de prueba, adecuadamente seleccionado
de entre el dominio ejecuciones generalmente infinito, contra el comportamiento
esperado. Incluye cinco subzonas.
Comienza con una descripción de fundamentos de pruebas de software. En primer
lugar, se presenta la terminología relacionados con las pruebas, a continuación, se
describen las cuestiones clave de la prueba, y finalmente se cubre la relación de
pruebas para otras actividades.
El segundo sub-área es los niveles de prueba. Estos se dividen entre los
objetivos de las pruebas y los objetivos de las pruebas.
La tercera sub-área es técnicas de prueba. La primera categoría incluye las
pruebas basadas en la intuición y la experiencia del probador. Un segundo
grupo comprende técnicas ESPECIFICACIÓN base, seguido de técnicas
basadas en el código, técnicas basadas en la falla, técnicas basadas en el
uso, y las técnicas relativas a la naturaleza de la aplicación. También se
presenta una discusión de cómo seleccionar y combinar las técnicas
apropiadas. La cuarta cubiertas sub-área medidas relacionadas con la
prueba. Las medidas se agrupan en los relacionados con la evaluación del
programa bajo prueba y la evaluación de las pruebas realizadas.
La última subzona describe la proceso de prueba, e incluye
© IEEE - 2004 Versión
consideraciones prácticas y las actividades de prueba.
Mantenimiento del software (Véase la Figura 2, la columna e)
Una vez en funcionamiento, se descubren anomalías, cambian los entornos
operativos, y las nuevas necesidades de los usuarios superficie. La fase de
mantenimiento del ciclo de vida comienza al momento de entrega de las actividades de
mantenimiento, pero son mucho más precoces. El software de mantenimiento KA se
divide en cuatro sub-áreas. los
primero Se presenta mantenimiento del software
fundamentos: definiciones y terminología, la naturaleza de mantenimiento, la
necesidad de mantenimiento, la mayoría de los costos de mantenimiento, la
evolución del software, y las categorías de mantenimiento. Los segundos grupos
sub-área juntos el cuestiones clave en el mantenimiento del software. Estas son
mantenimiento, y la medición de mantenimiento de software. La tercera sub-área
se describe la proceso de mantenimiento.
mantenimiento.
Las técnicas para el mantenimiento constituyen la cuarta subárea. Estos
incluyen comprensión del programa, re-
la ingeniería y la ingeniería inversa.
Gestión de la Configuración de Software (véase la Figura 3, la columna f)
Software Configuration Management (SCM) es la disciplina de la identificación
de la configuración del software en distintos puntos en el tiempo con el
propósito de los cambios que controlan de forma sistemática
a la configuración y de
mantenimiento de la integridad y la trazabilidad de el
configuración de todo el ciclo de vida del sistema. Este KA incluye seis
sub-áreas. La primera sub-área es gestión del proceso de SMC. Cubre los
temas del contexto de la organización de SCM, limitaciones y orientación
para SMC, la planificación de SMC, el propio plan de SMC, y la vigilancia
de SMC. El segundo sub-área
es configuración del software
identificación, que identifica elementos para ser controlados, establece esquemas
de identificación de los elementos y sus versiones, y establece las herramientas
y técnicas a utilizar en la adquisición y la gestión de elementos controlados. Los
primeros temas de esta subzona son la identificación de los elementos que
deben ser controlados y la biblioteca de software. La tercera sub-área es control
de la configuración de software,
que es la gestión de los cambios durante el ciclo de vida del software. Los
temas son: en primer lugar, solicitar, evaluar y aprobar los cambios de
software; segundo, implementar
cambios en el software; y en tercer lugar, las desviaciones, y las renuncias. El cuarto
sub-área es software de contabilidad estado de configuración. Sus temas son el software
de información de estado de configuración e informe de estado de configuración de
software.
1-5
La quinta sub-área es software de auditoría de configuración. Se compone de
software de auditoría de configuración funcional, software de auditoría de
configuración física, y las auditorías en proceso de una línea de base de software.
El último sub-área es gestión de versiones de software y entrega, que abarca la
construcción de software y gestión de versiones de software.
Gestión de Ingeniería de Software (Véase la Figura 3, la columna g)
La Ingeniería de Software de Gestión de KA se refiere a la gestión y
medición de la ingeniería de software. Si bien la medición es un aspecto
importante de todos los Kas, es aquí donde se presenta el tema de los
programas de medición. Hay seis sub-áreas de gestión de la ingeniería de
software. El primer proyecto de software de gestión de cinco tapa y el
sexto se describen los programas de medición de software. La primera
sub-área es iniciación y definición del alcance, que comprende la
determinación y la negociación de requisitos, análisis de viabilidad, y un
proceso para el examen y la revisión de los requisitos. El segundo
sub-área es la planificación de proyectos de software, e incluye la
planificación de procesos, los resultados que determinan, el esfuerzo, el
horario y la estimación de costos, asignación de recursos, la gestión de
riesgos, gestión de calidad,
y el plan
administración.
La tercera sub-área es software de la promulgación del proyecto. Los temas
aquí son ejecución de los planes, la gestión de contratos de proveedores, la
aplicación del proceso de medición, el monitor de procesos, proceso de control ,?
y elaboración de informes. El cuarto sub-área es revisión y evaluación, que
incluye los temas de la determinación de la satisfacción de las necesidades y
revisar y evaluar el desempeño. La quinta sub-área describe cierre: la
determinación de las actividades de cierre y de cierre.
Finalmente, el sexto sub-área describe medición de la ingeniería de
software, más específicamente, los programas de medición. medidas de
producto y de proceso se describen en la Ingeniería de Procesos de
Software KA. Muchos de los otros KAs también describen medidas
específicas para su KA. Los temas de esta sub-área son: establecer y
sostener la medición
compromiso, el plan de la medición
proceso, lleve a cabo el proceso de medición, y evaluar la medición.
Proceso de Ingeniería de Software (Véase la Figura 3, la columna h)
El Proceso de Ingeniería de Software KA se refiere a la definición,
implementación, evaluación, medición, gestión, cambiar y mejorar el
proceso de ingeniería de software en sí. Se divide en cuatro sub-áreas.
La primera presenta sub-área y la implementación de procesos
1-6
cambio. Los temas aquí son la infraestructura proceso, el ciclo de gestión de
procesos de software, modelos para la implementación de procesos y el
cambio, y las consideraciones prácticas. El segundo sub-área se ocupa de definición
del proceso. Incluye los temas de los modelos del ciclo de vida del software,
procesos de ciclo de vida del software, notaciones para las definiciones de
proceso, la adaptación de procesos y automatización La tercera sub-área es evaluación
de procesos. Los temas incluyen aquí los modelos de evaluación de procesos y
métodos de evaluación de proceso. El cuarto sub-área describe procesos y
productos mediciones. El proceso de ingeniería de software cubre la medición
general de los productos, así como la medición del proceso en general. se
describen las medidas específicas a Kas, en la KA relevante. Los temas son los
procesos de medición, la medición de productos de software, la calidad de los
resultados de las mediciones, modelos de información de software y técnicas
de medición de procesos.
Herramientas de ingeniería de software y Métodos (véase la figura
3, columna i)
La ingeniería de software Herramientas y Métodos KA incluye tanto herramientas
de ingeniería de software y métodos de ingeniería de software. los herramientas de
ingeniería de software subárea utiliza la misma estructura que la propia guía, con
un tema para cada uno de los otros nueve de ingeniería de software de Kas. Se
proporciona un tema adicional: temas complejos de instrumentos, tales como
técnicas de integración de herramientas, que son aplicables a todas las clases de
herramientas potencialmente. los métodos de ingeniería de software sub-área se
divide en cuatro subsecciones: métodos heurísticos que se ocupan de los
enfoques informales,
métodos formales que se ocupan de
enfoques de base matemática y métodos de creación de prototipos que se
ocupan de desarrollo de software enfoques basados ​en diversas formas de
creación de prototipos.
Calidad de Software (véase la Figura 3, columna j)
La calidad KA software se ocupa de las consideraciones de calidad de
software que trascienden los procesos del ciclo de vida del software. Dado
que la calidad del software es una preocupación omnipresente en la ingeniería
de software, también se considera en muchos de los otros Kas, y el lector se
dará cuenta de punteros a esas KAs lo largo de este KA. La descripción de
este KA cubre tres sub-áreas. La primera sub-área se describe la fundamentos
de calidad de software tales como la cultura de ingeniería de software y la
ética, el valor y los costos de calidad, los modelos y las características de
calidad y mejora de la calidad. Las segundas cubiertas sub-área procesos de
gestión de calidad del software. Los temas aquí son software de garantía de
calidad, verificación y validación, y las revisiones y auditorías. La tercera y
última subzona describe práctico
© IEEE - 2004 Versión
consideraciones relacionados con la calidad del software. Los temas son los
requisitos de software de calidad, caracterización de defectos, técnicas de gestión
de calidad de software, y la medición de la calidad del software.
usuarios), en apoyo del quinto objetivo del proyecto, las tasas de cuarto
apéndice cada tema con uno de un conjunto de categorías pedagógicas
comúnmente atribuida a Benjamín Bloom. El concepto es que los objetivos
educativos se pueden clasificar en seis categorías que representan el aumento
de la profundidad: conocimiento, comprensión, aplicación, análisis, síntesis y

Disciplinas relacionadas DE Ingeniería de Software (véase la Figura 3, la columna evaluación. Los resultados de este ejercicio para todos los KAs se pueden

k) encontrar en el Apéndice D. Este apéndice no debe, sin embargo, ser visto

como una clasificación definitiva, pero mucho más como punto de partida.
El último capítulo se titula Disciplinas relacionadas de ingeniería de software. Con
el fin de circunscribir la ingeniería de software, es necesario identificar las
disciplinas con las que la ingeniería de software comparte una frontera común.
En este capítulo se identifica, en orden alfabético, estas disciplinas
relacionadas. Para cada disciplina relacionada, y el uso de una fuente
reconocida basado en el consenso tal como se encuentra, se identifican:

una definición informativa (cuando sea posible); una lista de

KAs. Las disciplinas relacionadas son:

Ingeniería Informática Gestión de proyectos

Ciencias de la Computación Gestión de la calidad

administración la ergonomía del software

Matemáticas Ingeniería de Sistemas

UN PÉNDICES

Apéndice A. KA Descripción Especificaciones

El apéndice se describen las especificaciones proporcionadas por el equipo

editorial de los editores asociados de los contenidos, referencias, formato y
estilo de las descripciones KA recomendado.

UN PÉNDICE B. E VOLUTION DE LA GRAMO GUÍA DEL USUARIO

El segundo apéndice se describe la propuesta del proyecto para la evolución

de la Guía. La Guía 2004 es simplemente la actual edición de una guía que
seguir evolucionando para satisfacer las necesidades de la comunidad de
ingeniería de software. La planificación de la evolución todavía no es
completa, sino un esquema provisional del proceso se proporciona en este
apéndice. Al escribir estas líneas, este proceso ha sido aprobado por Consejo
Asesor Industrial del proyecto e informó a la Junta de Gobernadores de la
IEEE Computer Society, pero aún no está bien financiado o puesto en
práctica.

UN PÉNDICE C. A SIGNACIÓN DE NORMAS A KA S

El tercer apéndice es un índice anotado de las normas más relevantes,

sobre todo del IEEE y de la ISO, asignado a la KAS de la Guía
SWEBOK.

UN PÉNDICE D. B CLASIFICACIONES TELAR

A modo de ayuda, en particular a los desarrolladores del plan de estudios (y otra

© IEEE - 2004 Versión 1-7

 Guía de la Ingeniería de Software de Administración de Conocimiento
Versión 2004

Requisitos de Construcción de Mantenimiento

Diseño de software Pruebas de software
Software software del software

Requisitos de Fundamentos Fundamentos Fundamentos de

Fundamentos del diseño
software de software sofware de mantenimiento de
de software
Fundamentos Construcción prueba software

Cuestiones clave en

requisitos Cuestiones clave en el Construcción de el mantenimiento

Niveles de prueba
Proceso diseño de software la gestión de software

Proceso de mantenimiento
la obtención de Estructura del software y Consideraciones
Técnicas de prueba
requisitos Arquitectura prácticas

Las técnicas para

Diseño Análisis y
mantenimiento
Validación Medidas de ensayo
Evaluación de la
Análisis relacionados
Calidad de Software

Requisitos dede
Especificación Diseño de software Proceso

requisitos notaciones de prueba

Software de Diseño y
Requisitos
Estrategias
métodos

Consideraciones
prácticas

(un) (segundo) (do) (re) (mi)

Figura 2 - En primer lugar cinco KAs

1-8 © IEEE - 2004 Versión

 Guía de la Ingeniería de Software de Administración de Conocimiento

(2004 Version)

Gestión de la Gestión de Proceso de Herramientas de conocimiento de

Configuración de Ingeniería de Ingeniería de ingeniería de software Calidad del software las disciplinas
Software Software Software y Métodos relacionadas

La gestión de la Iniciación y Definición Proceso de Ingeniería

software Procesos de Gestión de
Proceso de SMC del Alcance implementación y Informática
Cambio Calidad de Software
prototipos de software
Herramientas
Fundamentos de

Identificación de la Proyecto de software Definición del Calidad del Software Ciencias de la

Herramientas de diseño de software

configuración de Planificación proceso Computación

Construcción de software
software
Herramientas

Herramientas de
Proyecto de software Evaluación del
Herramientas de prueba de software
Consideraciones administración
Configuración del Promulgación proceso prácticas
software Mantenimiento del software
Herramientas
Controlar
Proceso y
Revisión y Matemáticas
medición del
El software de
Evaluación producto
contabilidad de estado de ingeniería
software de software
Herramientas de administración de
Gestión de
configuración Ingeniería de software
Herramientas de ingeniería
proyectos
Herramientas de procesos

gestión de configuración de software

Cierre Herramientas de calidad de software de

Configuración del Gestión de la

software Herramienta Varios calidad
Cuestiones
Revisión de cuentas
Medición de Métodos de
Ingeniería de La ergonomía de
Software de gestión
Software software
de emisiones y
Entrega Los métodos heurísticos

Ingeniería de
Métodos formales
Sistemas

Requisitos Métodos de

(F) (gramo) (marido) (yo) (J) (k) áreas de

figura 3 - últimos seis KAs

© IEEE - 2004 Versión 1-9

1-10 © IEEE - 2004 Versión
 do CAPÍTULO 2 S OFTWARE R
EQUERIMIENTOS
UN CRONYMS
TROZO DE CUERO Gráfico Acíclico Dirigido
FSM Funcional de la medida del
INCOSE Consejo Internacional sobre Sistemas de Inge- niería
TDAA Análisis estructurado y nique Diseño Tech-
UML Lenguaje de Modelado Unificado
yo INTRODUCCIÓN
Los requisitos de software Área de Conocimiento (KA) se ocupa de la
obtención, análisis, especificación y validación de los requisitos de
software. Es ampliamente admitie- ron dentro de la industria del software
que el software Engineer- proyectos ing son críticamente vulnerables
cuando estas actividades se realizan mal.
Requisitos de software expresan las necesidades y limitaciones impuestas a un
producto de software que contribuyen a la solu- ción de algún problema en el
mundo real. [Kot00]
El 'ingeniería de requisitos' plazo es ampliamente utilizado en el campo
para indicar la manipulación sistemática de requisitos. Por razones de
coherencia, sin embargo, este término no se utiliza en la Guía, ya que se ha
decidido que el uso del término 'ingeniería' para actividades distintas de las
de ingeniería de software es que hay que evitar en esta edición de la Guía.
Por la misma razón, 'requisitos ingeniero', un término que aparece en la
parte de la literatura, no se utilizarán tampoco. En cambio, el término
'ingeniero de software', o, en algunos casos específicos, se utilizará
'requisitos especialista', este último donde el papel en cuestión se realiza
generalmente por una persona que no sea un ingeniero de software. Esto
no implica, sin embargo, que un ingeniero de software no pudo realizar la
función.
El desglose KA es ampliamente compatible con las seccio- nes de IEEE
12207 que se refieren a las actividades de requisitos. (IEEE12207.1-96)
Un riesgo inherente en la descomposición propuesta es que un proceso de
caída-como agua puede inferir. Para protegerse contra esto, subárea 2, Los
requisitos del proceso, está diseñado para proporcionar una visión general de alto
nivel del proceso de requisitos por conjunto- ting los recursos y las limitaciones
con las que opera el proceso y que actúan para configurarlo. Una descomposición
alternativa podría utilizar una estructura basada en el producto (requisitos del
sistema, los requisitos de software, prototipos, casos de uso, y así
sucesivamente). El proceso basado-
© IEEE - 2004 Versión
desglose refleja el hecho de que el proceso de requisitos, si ha de tener éxito,
debe ser considerado como un proceso que implica complejo, actividades
estrechamente acoplados (tanto secuenciales y concurrente), en lugar de como
una discreta, de una sola vez la actividad realizada en el inicio de un proyecto de
desarrollo de software.
Los requisitos de software KA se relaciona estrechamente con el diseño de
software, pruebas de software, software de manteni- miento, gestión de
configuración de software, software de gestión de Ingeniería de Software
Ingeniería de Procesos y Calidad de Software de Kas.
segundo REAKDOWN DE TEMAS PARA S OFTWARE
R EQUERIMIENTOS
1. Requisitos de software Fundamentos
1.1. Definición de un requisito de software
En su forma más básica, un requisito de software es una propiedad que debe
exhibir el fin de resolver un problema en el mundo real. La Guía se refiere a
los requisitos de 'software', ya que se ocupa de los problemas que deben
abordarse mediante software. Por lo tanto, un requisito de software es una
propiedad que debe ser exhibida por el software desarrollado o adaptado para
resolver un problema particular. El problema puede ser para automatizar parte
de una tarea de alguien que va a utilizar el software, para apoyar los procesos
de negocio de la organización que ha encargado el software, para cor- rect
defectos del software existente, para controlar un vicio de-, y muchos Más. El
funcionamiento de los usuarios, procesos de negocio, y dispositivos suele ser
compleja. Por extensión, por lo tanto, los requisitos de software en particular
son típicamente una combinación compleja de requisitos de diferentes
personas en diferentes niveles de una organización y desde el entorno en el
que funcionará el software. Una propiedad esencial de todos los requisitos de
software es que sean verificables. Puede ser difícil o costoso para verificar
ciertos requisitos de software. Por ejemplo, la verificación del requisito de
caudal en el centro de llamadas puede nego- cessitate el desarrollo de
software de simulación. Tanto los requisitos de software y personal de calidad
de software deben asegurarse de que los requisitos pueden ser verificados
dentro de las limitaciones de los recursos disponibles. Requisitos tienen otros
atributos, además de las propiedades havioral BE- que expresan. Los
ejemplos más comunes incluyen una clasificación de prioridad para permitir
compensaciones en la cara de los recursos finitos y un valor de estado para
permitir pro- greso proyecto para ser monitoreado. Típicamente, se identifican
de forma única los requisitos de software para que puedan ser sometidos a
2-1
control de la configuración de software y control durante el ciclo de vida del software deberá ser escrito en Ada. '). Estas se conocen a veces como requisitos del
de neumáticos es-. [Kot00; Pfl01; Som05; Tha97] proceso.

1.2. Requisitos del producto y de proceso Algunos de los requisitos de software generan los requisitos del proceso implícitos.
La elección de la técnica de verificación es un ejemplo. Otro podría ser el uso de
Una distinción puede hacerse entre producto y parámetros proceso parámetros.
técnicas de análisis de OU particularmente exigentes en este ámbito (tales como
Parámetros del producto son los requisitos de software para ser desarrollados
los métodos de especificación formal) para reducir los fallos que pueden conducir a
(por ejemplo, 'El software verificará que un estudiante cumple con todos los
insuficiente fiabilidad. requisitos de proceso también pueden ser impuestas
requisitos previos antes de que él o ella se registra para un curso.').
directamente por la organización de desarrollo, su cliente, o un tercero, tal como un
regulador de la seguridad [Kot00; Som97].
Un parámetro del proceso es esencialmente una restricción en el sarrollo
de- del software (por ejemplo, 'El software

Requisitos de
Software

Requisitos de
requisitos la obtención de requisitos Especificación de requisitos de Consideraciones
software
Proceso requisitos Análisis requisitos Validación prácticas
Fundamentos

Definición de un Definición del La naturaleza iterativa de

requisitos requisitos requisitos críticas
requisito de Los modelos de proceso sistema de los requisitos del proceso
Fuentes Clasificación
software documentos

Requisitos del Sistemas

técnicas de Modelado Gestión del
producto y de Los actores del proceso Especificación de prototipado
obtención conceptual cambio
proceso Requisitos

Diseño y
Requisitos Especificación de
Administración y requisitos Modelo de requisitos
funcionales y no Requerimientos de
Apoyo Proceso arquitectónicos validación Atributos
funcionales Software
Asignación

Propiedades Proceso de Calidad y requisitos de Prueba de requisitos de

emergentes Mejora Negociación aceptacion rastreo

Requisitos La medición de
cuantificables Requisitos

Requisitos del
sistema y
requisitos de
software

Figura 1 Desglose de los temas para el KA Requisitos de software

1.3. Requisitos funcionales y no funcionales Funcional requisitos requisitos de rendimiento, requisitos de mantenimiento, requisitos de
describen las funciones que el software es ejecutar; por ejemplo, el seguridad, requisitos de fiabilidad, o uno de muchos otros tipos de
formato de algún texto o la modulación de una señal. A veces se requisitos de software. Estos temas también se discuten en la calidad

conocen como capacidades. del software KA. [Kot00; Som97]

No funcionales los requisitos son los que actúan para con- colar la 1.4. Propiedades emergentes
solución. requisitos no funcionales son algunas veces conocidas como Algunos requisitos representan las propiedades emergentes de software; es
las restricciones o requisitos de calidad. Pueden ser clasificados de decir, requisitos que no pueden ser abordados por un solo componente, pero
acuerdo a si son que dependen para su satisfactoria

2-2 © IEEE - 2004 Versión

facción de cómo interactúen todos los componentes de software. El requisito de
caudal para un centro de llamadas, por ejemplo, dependerá de cómo el sistema
telefónico, sistema de informa- ción, y los operadores de todos interactuaron en
condiciones reales de funcionamiento. Las propiedades emergentes dependen
fundamentalmente de la arquitectura del sistema. [Som05]
1.5. Requisitos cuantificables
Requisitos de software deben expresarse tan claramente y sin
ambigüedad como sea posible, y, en su caso, cuantitativamente. Es
importante evitar los requisitos de vagas y no verificables que dependen
para su interpretación en un juicio subjetivo ( 'El software debe ser
confiable'; 'El software debe ser fácil de usar'). Esto es particularmente
importante para los requisitos no funcionales. Dos ejemplos de requisitos
cuantificados son los siguientes: software de un centro de llamadas debe
aumentar el rendimiento del centro en un 20%; y un sistema tendrá una
probabilidad de generar un error fatal durante cualquier hora de operación
de menos de 1 * 10 8. El requisito de caudal está en un nivel muy alto y
tendrá que ser utilizado para derivar una serie de requisitos detallados. El
requisito de fiabilidad estará fuertemente con- colar la arquitectura del
sistema. [Dav93; Som05]
1.6. Requisitos del sistema y requisitos de software
En este tema, sistema significa ' una combinación de interacción de elementos
para llevar a cabo un objetivo definido. Estos incluyen hardware, software,
firmware, personas, información, técnicas, instalaciones, servicios y otros
elementos de apoyo, 'Como se define por el Consejo Internacional sobre
Sistemas de Inge- niería (INCOSE00).
Sistema los requisitos son los requisitos para el sistema en su conjunto. En unos
componentes de software del sistema que contienen,
software requisitos se derivan de requisitos del sistema.
La literatura sobre los requisitos a veces llama a los requisitos del sistema ''
necesidades de los usuarios. La guía define los requisitos del usuario '' de una
manera restringida como los requisitos de los clientes del sistema o usuarios
finales. Los requisitos del sistema, por el contrario, abarcan necesidades de los
usuarios, los requisitos de otras partes interesadas (tales como au- toridades de
regulación), y los requisitos sin una fuente humana identificable.
2. Requisitos Proceso
En esta sección se presenta el proceso de requisitos de software, la orientación de
las cinco sub-áreas restantes y mostrando cómo el proceso se ajusta perfectamente
a los requisitos del proceso general de la ingeniería de software. [Dav93; Som05]
2.1. Los modelos de proceso
El objetivo de este tema es el de proporcionar un entendimiento de que el
proceso de requisitos:
No es una actividad discreta front-end del ciclo de vida del software, sino
más bien un proceso iniciado en la COMIENZO
© IEEE - 2004 Versión
Ning de un proyecto y continuando a ser refinado a lo largo del
ciclo de vida
identifica los requisitos de software como elementos de configuración, y los
gestiona utilizando las mismas prácticas de gestión de configuración de
software como otros pro- ductos de los procesos del ciclo de vida del
software necesita ser adaptado al contexto de la organización y el proyecto
En particular, el tema tiene que ver con cómo se configuran las activi-
dades de obtención, análisis, especificación y validación de los diferentes
tipos de proyectos y con- straints. El tema también incluye actividades que
proporcionan la entrada en el proceso de requisitos, tales como el
marketing y estudios de viabilidad. [Kot00; Rob99; Som97; Som05]
2.2. Los actores del proceso
Este tema se presentan las funciones de las personas que partici- par en el
proceso de requisitos. Este proceso se funda- mental interdisciplinario, y el
especialista requisitos necesita para mediar entre el dominio de la parte
interesada y el de la ingeniería de software. A menudo hay muchas personas
involucradas, además del especialista requisitos, cada uno de los cuales
tiene una participación en el programa. Los grupos de interés variarán de
proyectos, pero siempre incluyen US- ERS / operadores y clientes (que no
tiene por qué ser el mismo). [Gog93]
Ejemplos típicos de grupos de interés de software incluyen (pero no se
limitan a):
Usuarios-Este grupo comprende aquellos que operará el software. A menudo es la
gente Prising un grupo heterogéneo com- con diferentes funciones y requisitos.
Clientes-Este grupo comprende a los destinatarios de software o que representan el
mercado objetivo de software. analistas de un mercado de productos para el mercado
masivo no tendrán un cliente puesta en marcha, por lo que per- sonas de marketing son
a menudo necesaria para establecer las necesidades del mercado y para actuar como
clientes de proxy. se regulan los reguladores-Muchos dominios de aplicación, como la
banca y el transporte público. Software en estos dominios debe cumplir con los requisitos
de las autoridades reguladoras. Los ingenieros de software-Estas personas tienen un
interés le- gitimate en sacar provecho de desarrollo del software, por ejemplo, la
reutilización de componentes en otros productos. Si, en este escenario, un cliente de un
producto en particular tiene requisitos específicos que comprometen el potencial de
reutilización de componentes, los ingenieros de software deben sopesar cuidadosamente
su propio juego contra los del cliente. No será posible satisfacer perfectamente las
necesidades de todas las partes interesadas, y es el trabajo del ingeniero de software
para negociar las compensaciones que son tanto aceptables para los principales grupos
de interés y dentro de las limitaciones presupuestarias, técnicas, normativas, y otros. Un
requisito previo para esto es que se identifique a todos los interesados, la naturaleza de
su y es el trabajo del ingeniero de software para negociar las compensaciones que son
tanto aceptables para los principales grupos de interés y dentro de las limitaciones
presupuestarias, técnicas, normativas, y otros. Un requisito previo para esto es que se
identifique a todos los interesados, la naturaleza de su y es el trabajo del ingeniero de
software para negociar las compensaciones que son tanto aceptables para los
principales grupos de interés y dentro de las limitaciones presupuestarias, técnicas,
normativas, y otros. Un requisito previo para esto es que se identifique a todos los
interesados, la naturaleza de su
2-3
'Juego' analizó, y sus requisitos suscitó. [Dav93; Kot00; Rob99; Som97;
You01]
2.3. Administración y Apoyo Proceso
Este tema se presentan los recursos de gestión de proyectos requeridos y
consumidos por el proceso de requisitos. Establece el contexto de la primera
subárea ( Iniciación y Definición del Alcance) de la Ingeniería de Software
Hombre- agement KA. Su propósito principal es hacer que el vínculo entre
las actividades de los procesos identificados en 2.1 y los problemas de
costo, recursos humanos, capacitación y herramientas. [Rob99; Som97;
You01]
2.4. Proceso de Calidad y Mejora
En este tema se refiere a la evaluación de la calidad y la mejora del
proceso de requisitos. Su propósito es hacer hincapié en el papel clave que
juega el proceso de requerimientos en términos de costo y oportunidad de
un producto de software, y de la satisfacción del cliente con él [Som97].
Esto ayudará a orientar el proceso de requisitos de las normas de calidad y
modelos de mejora de procesos de software y sistemas. La calidad del
proceso y la mejora está estrechamente relacionado con la calidad tanto
KA Software y la Ingeniería de Procesos de Software KA. De particular
interés son los temas de los atributos de calidad de software y urement
medi-, y la definición de procesos de software. En este tema cu- ERS:
la cobertura proceso de requisitos para los estándares mejoría de
procesos y modelos
requisitos de las medidas de proceso y la evaluación comparativa de
planificación e implementación de mejora [Kot00; Som97; You01]
3. la obtención de requisitos
[Dav93; Gog93; Lou95; Pfl01]
La obtención de requisitos, donde se ocupa de los requisitos de software
vienen y cómo la inge- Neer software puede recogerlos. Es la primera
etapa en la construcción de una comprensión del problema se requiere el
software de resolver. Se trata fundamentalmente de una actividad
humana, y es donde se identifican y relaciones estable- cido entre el
equipo de desarrollo y el cliente los grupos de interés. Se denomina
diversamente 'captura de requisitos', 'requisitos descubrimiento', y
'adquisición requisitos.
Uno de los principios fundamentales de ING buen software Engineer- es que
exista una buena comunicación entre los usuarios de software e ingenieros de
software. Antes de que comience el desarrollo, los especialistas requisitos
pueden formar el conducto para esta comunicación. Deben mediar entre el
dominio de los usuarios de software (y otras partes interesadas) y el mundo de
la técnica del ingeniero de software.
2-4
3.1. requisitos Fuentes
[Dav93; Gog93; Pfl01]
Requisitos tienen muchas fuentes en el software típico, y es esencial que
ser identificados y evaluados por su impacto en él todas las fuentes
potenciales. Este tema está diseñado para promover el conocimiento de las
diversas fuentes de requisitos de software y de los marcos para la gestión
de los mismos. Los puntos principales son:
Metas. El término meta (a veces llamada 'empresa comercial' o 'factor
crítico de éxito') se refiere a los objetivos generales, de alto nivel de
software. Objetivos proporcionan la motivación para el software, pero
son de- diez vagamente formulado. Los ingenieros de software deben
prestar especial atención a la evaluación del valor (tivo relación a la
prioridad) y el costo de las metas. Un estudio de viabilidad es una forma
relativamente barata de hacer esto. [Lou95]. Conocimiento del dominio.
El ingeniero de software necesita adquirir o tener a su disposición, el
conocimiento sobre el dominio de apli- cación. Esto les permite inferir el
conocimiento tácito de que las partes interesadas no se articulan,
evaluar las ventajas y desventajas que serán necesarios entre los
requisitos en conflicto, y, a veces, para actuar como un campeón
'usuario'. Las partes interesadas (ver tema 2.2 Los actores del proceso). Gran
parte del software ha sido insatisfactorio, ya que ha hecho hincapié en
las necesidades de un grupo de tenedores stake- a expensas de las de
los demás. Por lo tanto, el software se entrega, que es difícil de usar o
que subvierte las estructuras culturales o políticas de la organización del
cliente. El ingeniero de software tiene que identificar, representar y
gestionar los puntos de vista '' de muchos tipos diferentes de grupos de
interés. [Kot00].
El entorno operativo. Requisitos se derivan del entorno en el que se
ejecutará el programa. Estos pueden ser, por ejemplo, las
limitaciones de tiempo en las restricciones del software o de
interoperabilidad en tiempo real en un entorno de oficina. Estos
deben buscarse activamente, ya que pueden afectar en gran medida
la viabilidad y el coste del software, y restringir las opciones de
diseño. [Tha97]
El entorno de la organización. El software se requiere a menudo para
apoyar un proceso de negocio, la selección de los cuales puede estar
condicionado por la estructura, cul- tura, y la política interna de la
organización. El ingeniero de software tiene que ser sensible a estos,
ya que, en general, el nuevo software no debe forzar el cambio no
planificadas en el proceso de negocio.
3.2. técnicas de obtención
[Dav93; Kot00; Lou95; Pfl01] Una vez se han identificado las
fuentes de requisitos, el ingeniero de software puede comenzar la
obtención de requisitos de ellos. Este tema se centra en técnicas para
conseguir los interesados ​humanos para articular sus necesidades. Es una
zona muy difícil y el ingeniero de software tiene que ser
© IEEE - 2004 Versión
sensibilizado al hecho de que (por ejemplo) los usuarios pueden tener
dificultades para describir sus tareas, puede dejar la formación in- importante no
declarado, o pueden ser dispuestos o no pueden cooperar. Es particularmente
importante entender que la provocación no es una actividad pasiva, y que,
incluso si COOP erativa y articular las partes interesadas están disponibles, el
ingeniero de soft- ware tiene que trabajar duro para obtener la informa- ción
correcta. Existe un número de técnicas para hacer esto, siendo los principales:
[Gog93]
Entrevistas, unos medios 'tradicionales' de la obtención de re-
quirements. Es importante entender las ventajas y limitaciones de
entrevistas, y la forma en que debe llevarse a cabo.
Escenarios, un medio valioso para proporcionar contexto a la elicitación de
requisitos del usuario. Permiten que el ingeniero de software para
proporcionar un marco para las preguntas sobre las tareas del usuario al
permitir que 'what if' y 'cómo se hace esto' preguntas que se le pregunte.
El tipo más común de escenario es el caso de uso. Hay un enlace aquí
para tema 4.2. ( Modelado Conceptual), Be- causa notaciones de
escenarios tales como casos de uso y diagramas son comunes en el
software de modelado. Prototipos, una herramienta valiosa para aclarar
requisitos poco claros. Pueden actuar de una manera similar a la esce-
narios proporcionando a los usuarios un contexto en el que puedan
entender mejor lo que la información que necesitan para ofrecer. Hay una
amplia gama de técnicas de tipificación prototipos, a partir de papel de
maquetas de diseños de pantalla para las versiones beta-test de los
productos de software, y un fuerte solapamiento de su uso para la
obtención de requisitos y el uso de prototipos para la validación de
requisitos (ver tema 6.2 Creación de prototipos).
reuniones facilitadas. El propósito de estos es para tratar de
lograr un efecto acumulativo mediante el cual un grupo de
personas puede aportar una visión más clara en su software
quirements re- que trabajando individualmente. Pueden
intercambiar ideas y refinar las ideas que pueden ser difíciles de
llevar a la superficie a través de entrevistas. Otra ven- taja es que
los requisitos conflictivos superficie desde el principio en una
forma que permite a las partes interesadas reconocen donde hay
conflicto. Cuando funciona bien, esta técnica puede resultar en
un conjunto más rico y más coherente de los requisitos de lo que
podría ser capaz achiev-. Sin embargo, las reuniones deben ser
manejados cuidadosa- mente (de ahí la necesidad de un
facilitador) para evitar una situación que se produzcan en las
habilidades críticas del equipo son erosionadas por la lealtad al
grupo,
Observación. La importancia del contexto de software dentro del
entorno de la organización ha llevado a la adaptación de las técnicas
de observación de los requisitos elicitación. Los ingenieros de
software aprenden acerca de las tareas del usuario sumergiéndose
en el ment ambiente y la observación de cómo los usuarios
interactúan con su software y entre sí. Estas técnicas son
© IEEE - 2004 Versión
relativamente caro, pero son instructivas porque ilustran que muchas
tareas de usuario y procesos de negocio son demasiado sutil y
complejo por sus actores para describir fácilmente.
Análisis 4. Requisitos
[Som05]
Este tema tiene que ver con el proceso de análisis quirements re- a:
detectar y resolver los conflictos entre los requisitos de descubrir los
límites del software y la forma en que debe interactuar con sus requisitos
de medio ambiente elaborado sistema para generar requisitos de
software
La visión tradicional de análisis de requisitos ha sido que se reducirá a
modelado conceptual usando uno de una serie de métodos de análisis,
tales como el análi- sis Estructurado y Diseño Technique (SADT). Si bien
el modelado conceptual es importante, incluimos la clasificación de los
requisitos para ayudar a informar a las compensaciones entre los
requisitos (clasificación requisitos) y el proceso de creación de estas
compensaciones (requisitos de negociación). [Dav93]
Se debe tener cuidado para describir los requisitos de forma suficientemente precisa
para permitir que los requisitos para ser validados, su aplicación a ser verificada, y
sus costos para ser acoplado estimación.
4.1. requisitos Clasificación
[Dav93; Kot00; Som05] Los requisitos pueden ser clasificadas
en varias dimensiones. Ejemplos incluyen:
Si el requisito es funcional o no funcional (ver tema 1.3 Requisitos
funcionales y no funcional).
Si el requisito se deriva de uno o más requisitos de alto nivel o un
emergente prop- erty (ver tema 1.4 Propiedades emergentes), o
está siendo impuesta directamente en el software por un actor o
alguna otra fuente.
Si el requisito es en el producto o el proceso. Requisitos en el
proceso pueden limitar la elección del contratista, el proceso de
ingeniería de software para ser adoptado, o las normas que
deben ser respetados.
La prioridad requisito. En general, cuanto mayor sea la prioridad, más
esencial es el requisito para cumplir con los objetivos generales del
software. A menudo clasificada en una escala de punto fijo tal como
obligatorio, altamente deseable, deseable, u opcional, la prioridad a
menudo tiene que ser equilibrada contra el costo de rrollo y aplicación
desa-. El alcance de la prescripción. Ámbito de aplicación se refiere a
la medida en que un requisito afecta a los componentes de software y
de software. Algunos de los requisitos, par-
2-5
 ticularmente a algunos que no funcionales, tienen un alcance global en
que su satisfacción no puede ser asignado a un componente discreto.
Por lo tanto, un requisito de ámbito global puede afectar fuertemente el
software arqui- tectura y el diseño de muchos componentes, mientras
que uno con un alcance limitado pueden ofrecer un nú- mero de
opciones de diseño y tienen poco impacto en la satisfacción de otras
necesidades.
Volatilidad / estabilidad. Algunos de los requisitos cambiarán durante el
ciclo de vida del software, e incluso durante el propio proceso de
desarrollo. Es útil si alguna estimación de la probabilidad de que un
requisito de cambio se puede hacer. Por ejemplo, en una plicatura de la
banca AP, los requisitos para las funciones para el cálculo y el interés
de crédito a las cuentas de los clientes tienden a ser más estable que un
requisito para apoyar un tipo particu- lar de la cuenta libre de impuestos.
El primero refleja una característica fundamental del dominio de la
banca (que ac- conteos pueden ganar intereses), mientras que los
segundos pueden dejarlo obsoleto por un cambio de gobierno legis-
lación. Marcar requisitos potencialmente volátiles puede ayudar al
ingeniero de software de establecer un diseño que es más tolerante de
cambio.
Otras clasificaciones pueden ser apropiadas, dependiendo de la práctica
habitual de la organización y la propia aplicación.
Hay una fuerte superposición entre los requisitos de información y
requisitos atributos clasifi- (ver tema 7.3 los requisitos atributos).
4.2. Modelado conceptual
[Dav93; Kot00; Som05]
El desarrollo de modelos de un problema del mundo real es clave para el análisis
de los requisitos de software. Su propósito es ayudar en la comprensión del
problema, en lugar de iniciar el diseño de la solución. Por lo tanto, los modelos
conceptuales com- modelos de premios de entidades de la ured config dominio
del problema para reflejar sus relaciones del mundo real y Encies Dependiendo.
Hay varios tipos de modelos pueden ser desarrollados. Estos incluyen datos y flujos de
control, modelos de estado, trazas de eventos, las interacciones del usuario, modelos de
objetos, modelos de datos, y muchos otros. Los factores que influyen en la elección del
modelo incluyen:
La naturaleza del problema. Algunos tipos de software exigen ser
analizados que ciertos aspectos particularmente rigurosa. Por ejemplo, el
flujo de control y modelos de estado es probable que sean más importantes
para el software en tiempo real para el software de gestión de la
información, mientras que por lo general sería lo contrario de los modelos
de datos.
La experiencia del ingeniero de software. A menudo es más
productivo para adoptar una notación de modelado o método con el
que el ingeniero de software tiene expe- riencia.
2-6
Los requisitos del proceso del cliente. ERS adaptado para el cliente
pueden imponer su notación favorecida o método, o prohibir cualquier con las
que están familiarizados. Este factor puede entrar en conflicto con el factor
anterior. La disponibilidad de métodos y herramientas. Anotaciones o métodos
que no están bien soportados por la formación y herramientas no pueden
lograr una amplia aceptación, incluso si son adecuados para determinados
tipos de problemas. Tenga en cuenta que, en casi todos los casos, es útil
comenzar Building Pro- un modelo del contexto del software. El contexto
software proporciona una conexión entre los programas informáticos
destinados y su entorno externo. Esto es crucial para entender el contexto del
software en su entorno operativo y para identificar sus interfaces con el medio
ambiente. El problema de la modelización está estrechamente unida con la de
los métodos. A efectos prácticos, un método es una notación (o conjunto de
notaciones) soportado por un proceso que guía la aplicación de las notaciones.
Hay poca evidencia empírica para apoyar las reclamaciones por la
superioridad de una sobre otra notación ción. Sin embargo, la aceptación
generalizada de un método o una notación particular puede conducir a la
puesta en común beneficioso a nivel in- dustria de habilidades y
conocimientos. Esta es actual- mente la situación con el UML (Unified
Modeling Language). (UML04)
modelos formales usando notaciones sobre la base de las matemáticas
discretas y que tienen su origen en el razonamiento lógico, han hecho un
impacto en algunos dominios especializados. Estos pueden ser impuestas por
los clientes o normas, o pueden ofrecer ventajas convincentes para el análisis
de ciertas funciones o componentes críticos.
En este tema no trata de 'enseñar' un estilo de modelado en particular o notación,
sino que proporciona una guía sobre la actitud de PUR y la intención de modelado.
Dos estándares proporcionan notaciones que pueden ser útiles en la
realización de modelado conceptual-IEEE Std 1320.1, IDEF0 para el
modelado funcional; e IEEE Std 1320.2, IDEF1X97 (IDEFObject) para el
modelado de información.
4.3. Diseño y requisitos arquitectónicos Asignación
[Dav93; Som05]
En algún momento, la arquitectura de la solución debe ser derivado. El
diseño arquitectónico es el punto en el que el proceso se superpone con los
requisitos de software o sistemas de diseño, e ilustra lo imposible que es
limpiamente de- par de las dos tareas. [Som01] Este tema está
estrechamente re- lated a la Estructura del software y Arquitectura subárea en
el diseño de software KA. En muchos casos, el ingeniero de software actúa
como arquitecto de software debido a que el proceso de análisis y
elaboración de los requisitos que exige ser identificados los componentes
que serán responsables de la satisfacción de las necesidades. Se trata de los
requisitos de asigna- ción-la asignación, a los componentes, de la
responsabilidad de satisfacer los requisitos.
© IEEE - 2004 Versión
Asignación es importante para permitir el análisis detallado de quirements re-. Por lo tanto, por
ejemplo, una vez que un conjunto de requisitos se ha asignado a un componente, los requisitos
individuales se pueden analizar aún más para descubrir nuevos requisitos sobre cómo el
componente necesita interactuar con otros componentes con el fin de satisfacer los requisitos
asignados. En grandes proyectos, la asignación estimula una nueva ronda de análisis para cada
subsistema. Como ejemplo, los requisitos para un rendimiento de frenado en particular para un
coche (distancia de frenado, la seguridad en malas condiciones de conducción, la suavidad de
aplicación, la presión del pedal necesarios, y así sucesivamente) puede ser asignada al
hardware de frenado (conjuntos mecánicos e hidráulicos) y una sistema de frenado antibloqueo
(ABS). Sólo cuando un requisito para un sistema de frenado anti-bloqueo ha sido identificado, y
los requisitos que le sea asignada, se pueden usar las capacidades del ABS, el frenado
cerámica de hardware, y propiedades emergentes (tales como el peso del coche) para
identificar los requisitos detallados de software ABS. El diseño arquitectónico está
estrechamente identificada con el modelado conceptual. El mapeo de entidades del dominio del
mundo real para los componentes de software no siempre es evidente, por lo que el diseño
arqui- tectural se identifica como un tema aparte. Los re- quirements de notaciones y métodos
son básicamente los mismos tanto para el modelado conceptual y el diseño arquitectónico. IEEE
Std 1471-2000, Práctica Recomendada para arqui- Descripción tectural de Software de
Sistemas Intensivos, gestas cias un enfoque de múltiples punto de vista para describir la
arquitectura de sistemas y sus elementos de software. (IEEE1471-00) y propiedades
emergentes (tales como el peso del coche) ser utilizados para identificar los requisitos
detallados de software ABS. El diseño arquitectónico está estrechamente identificada con el
modelado conceptual. El mapeo de entidades del dominio del mundo real para los componentes
de software no siempre es evidente, por lo que el diseño arqui- tectural se identifica como un
tema aparte. Los re- quirements de notaciones y métodos son básicamente los mismos tanto
para el modelado conceptual y el diseño arquitectónico. IEEE Std 1471-2000, Práctica
Recomendada para arqui- Descripción tectural de Software de Sistemas Intensivos, gestas cias
un enfoque de múltiples punto de vista para describir la arquitectura de sistemas y sus
elementos de software. (IEEE1471-00) y propiedades emergentes (tales como el peso del coche) ser utilizados contenido
4.4. requisitos de Negociación
Otro término comúnmente utilizado para este sub-tema es 'solución a los
conflictos con-'. Esto se refiere a la resolución de problemas con los requisitos
donde los conflictos se producen entre dos soportes stake- que requieren
características mutuamente incompatibles, entre las necesidades y los recursos,
o entre funcional y no funcional
requisitos, por ejemplo. [Kot00,
Som97] En la mayoría de los casos, no es aconsejable para el software de inge-
Neer para tomar una decisión unilateral, y por lo que se convierte en Essary nece-
consultar con la parte interesada (s) para llegar a un consenso sobre una
compensación adecuada. A menudo es importante por razones contractuales que
tales decisiones permitir rastrear al cliente. Hemos clasificado esto como un tema
de análisis de requisitos soft- ware porque los problemas surgen como el resultado
del análisis. Sin embargo, un fuerte caso también se puede hacer por considerarla
validación tema ción a los requisitos.
5. Requisitos Especificación
Para la mayoría de las carreras de ingeniería, el término 'especificación' se
refiere a la asignación de valores numéricos o los límites a los objetivos de
diseño de un producto. (Vin90) sistemas físicos típicos tienen un número
relativamente pequeño de tales valores. El software típico tiene un gran número
de requisitos, y el em- phasis se comparte entre la realización de la cuanti
cación numérica y la gestión de la complejidad de la interacción
© IEEE - 2004 Versión
entre el gran número de requisitos. Así, en el software jerga de la ingeniería,
'especificación de requisitos de software' se refiere generalmente a la
producción de un documento, o su equivalente electrónico, que puede ser
sistemáticamente re- vista, evaluada y aprobada. Para sistemas complejos,
en particular los que implican componentes sustanciales no de software,
como se producen hasta tres diferentes tipos de docu- mentos: definición del
sistema, los requisitos del sistema, y ​los requisitos de software. Para los
productos de software simple, sólo se requiere el tercero de estos. Los tres
documentos se describen aquí, con el entendimiento de que se pueden
combinar según sea apropiado. Una descripción de la ingeniería de sistemas
se puede encontrar en el capítulo 12, disciplinas de la ingeniería de software
relacionados.
5.1. El Documento de Definición del Sistema
Este documento (a veces conocido como el documento de requerimientos del
usuario o el concepto de operaciones) registra los requisitos del sistema. Se
define el sistema de alto nivel quirements re- desde la perspectiva de dominio.
Su número de lectores incluye representantes de los usuarios del sistema /
clientes (marketing puede desempeñar estas funciones de soft- ware impulsada
por el mercado), por lo que su contenido debe ser expresada en términos de los
principales do-. El documento enumera los requisitos del sistema, junto con la
información de fondo sobre los objetivos globales para el sistema, su entorno de
destino y una declaración de las limitaciones, supuestos y requisitos no
funcionales. Puede incluir modelos conceptuales diseñados para IL-lustrate el
contexto del sistema, escenarios de uso y las entidades del dominio prin- cipal,
así como los datos, información y flujos de trabajo. IEEE Std 1362, Concepto de
Operaciones de documentos, proporciona asesoramiento sobre la preparación y
el para
delos
identificar dicho documento.
requisitos detallados(IEEE1362-98)
de software ABS. El diseño arquitectónico está estrechamente identificada
5.2. Requisitos del sistema Especificación
[Dav93; Kot00; Rob99; Tha97] Los desarrolladores de sistemas con
software y componentes no sustanciales de software, un avión moderno, por
ejemplo, a menudo se separan de la descripción de los requisitos del sistema
de la descripción de los requisitos de software. En esta vista, se especifican
los requisitos del sistema, los requisitos de software se derivan de los
requisitos del sistema y, a continuación se especifican los requisitos para los
componentes de software. Estrictamente hablando, la especificación de los
requisitos del sistema es una actividad de ingeniería de sistemas y cae fuera
del alcance de esta guía. IEEE Std 1233 es una guía para el desarrollo de los
requisitos del sistema. (IEEE1233-98)
5.3. Especificación de Requerimientos de Software
[Kot00; Rob99] especificación de requisitos de software establece la
base para un acuerdo entre los clientes y los contratistas o alicates SUP- (en
los proyectos impulsados ​por el mercado, estas funciones pueden ser jugados
por las divisiones de marketing y desarrollo) en lo que el producto de software
es hacer, así como lo no se espera que haga. Para los lectores no técnicos, el
documento de especificación de requisitos de soft- ware es a menudo AC-
2-7
pañado por una definición docu- mento requisitos de software. revisar el documento (s). Los documentos de requisitos están sujetos a las
mismas prácticas de gestión de configuración de software como las demás
prestaciones de los procesos de Cy-CLE de vida del software. (Bry94, Ros98)
especificación de requisitos de software permite una evaluación rigurosa de los

requisitos de diseño antes de comenzar y se reduce el rediseño más tarde. También

debe proporcionar una base realista para la estimación de los costos del producto, Es normal para programar explícitamente uno o más puntos en el proceso de

riesgos y horarios. Las organizaciones también pueden utilizar un software requisitos los requisitos en los que se validó con los requisitos. El objetivo es recoger
cualquier problema antes de re- cursos se han comprometido a hacer frente
speci- documento ficación para desarrollar sus propios planes de validación y
a las necesidades. validación de requisitos tiene que ver con el proceso de
verificación de manera más productiva.
examinar el documento de requisitos para garantizar que define el software
adecuado (es decir, el software que los usuarios esperan). [Kot00]
especificación de requisitos de software proporciona una base informada para
transferir un producto de software para nuevos usuarios o máquinas nuevas. Por
último, puede proporcionar una base para la mejora del software.
6.1. requisitos críticas
[Kot00; Som05; Tha97] Tal vez la forma más común de validación
Requisitos de software se escriben a menudo en len- guaje natural, pero, en la
es por inspec- ción o revisión del documento (s) requisitos. Un grupo de
especificación de requisitos de software, esto puede ser complementado por las
revisores se le asigna un breve para buscar errores, suposiciones
descripciones formales o semi-formales. La selección de las anotaciones
erróneas, falta de claridad, y la desviación estándar de la práctica. La
apropiadas permite requisitos particulares y aspectos de la arquitectura de
composición del grupo que con- conductos de la revisión es importante (al
software que se describirán con mayor precisión y concisión de lenguaje natural.
menos un representante del cliente debe ser incluido para un proyecto
La regla general es que las notaciones se deben utilizar que permiten a los
impulsado por el cliente, por ejemplo), y puede ayudar a proporcionar
requisitos para ser descritos como pre precisamente como sea posible. Esto es
particularmente crucial para la seguridad operacional críticos y ciertos otros tipos orientación sobre lo que debe buscar en la forma de listas de verificación.

de software fiable. Sin embargo, la elección de la notación suele estar limitado por Los comentarios pueden ser constituidos en la finalización del documento
la formación, habilidades y preferencias de los lectores Thors y au- del de definición del sistema, el documento de especificación del sistema, el
documento. documento de especificación de requisitos de software, la especificación
de línea de base para un nuevo lanzamiento, o en cualquier otro paso en
el proceso. IEEE Std 1028 proporciona orientación sobre la realización de
dichas revisiones. Re- vistas y auditorías.
Una serie de indicadores de calidad han sido desarrollados que pueden utilizarse
para relacionar la calidad del software especificación quirements re- a otras variables
del proyecto, tales como el coste, la aceptación, el rendimiento, el horario, la
reproducibilidad, etc. Los indicadores de calidad para las declaraciones de
especificación de los requisitos de software individuales incluir imperativos, las
Directivas, frases débiles, las opciones y las continuaciones. Indicadores para toda la
6.2. prototipado
especificación de requisitos de software docu- mento incluyen el tamaño, la
[Dav93; Kot00; Som05; Tha97] prototipos es comúnmente un medio
legibilidad, la especificación, la profundidad y la estructura del texto. [Dav93; Tha97]
(Ros98)
para validar la interpretación que el ingeniero de software de los requisitos de
software, así como para la obtención de nuevos requisitos. Al igual que con la
elicitación, hay una gama de técnicas de prototipado y un número de puntos
IEEE tiene un estándar, IEEE Std 830 [IEEE830-98], para la producción en el proceso donde prototipo validación ción puede ser apropiado. La
y el contenido de la especificación de requisitos de software. También, ventaja de prototipos es que pueden hacer que sea más fácil interpretar los
IEEE 1465 (similar a ISO / IEC
supuestos del software niería Neer y, si es necesario, dar Feed- útil volver
12119), es un estándar de tratamiento de requisitos de calidad en los paquetes de
sobre por qué están equivocados. Por ejemplo, el comportamiento dinámico
software. (IEEE1465-98)
de una interfaz de usuario se puede entender mejor a través de un prototipo
de animación que a través textual de- cripción o gráficos modelos. También
6. Requisitos de validación
hay desventajas, sin embargo. Estos incluyen el peligro de aten- ción de los
[Dav93]
usuarios distraerse del núcleo subyacente dad funcional- por cuestiones
Los documentos de los requisitos pueden estar sujetos a procedimientos de cosméticas o problemas de calidad con el prototipo. Por esta razón, varias
validación y verificación. Los requisitos pueden ser validados para asegurar personas recomiendan prototipos que evitan el software, tales como
que el ingeniero de software tiene sub estaban los requisitos, y también es maquetas basadas en rotafolio. Los prototipos pueden ser costosos de
importante verificar que un documento se ajusta a los requisitos Standards desarrollar. Sin embargo, si evitan el desperdicio de recursos que supone
compañía, y que es comprensible, coherente y com- pleta. Las notaciones tratar de satisfacer los requisitos erróneos, su coste se puede justificar más
formales ofrecen la importante ventaja de permitir que las dos últimas fácilmente.
propiedades a ser probada (en un sentido re- stricted, por lo menos). Las
diferentes partes interesadas, incluidos los representantes del cliente y
desarrollador, deberían

2-8 © IEEE - 2004 Versión

6.3. Modelo de validación
[Dav93; Kot00; Tha97]
Por lo general es necesario para validar la calidad de los els MOD- desarrollados
durante el análisis. Por ejemplo, en modelos de objetos, es útil para llevar a cabo un
análisis estático para verificar la existencia de rutas de comunicación entre objetos
que, en el dominio de las partes interesadas, los datos de cambio. Si se utilizan las
notaciones de especificación formal, es posible utilizar el razonamiento formal para
demostrar propiedades de las especificaciones.
6.4. Prueba de aceptacion
[Dav93]
Una propiedad esencial de un requisito de software es que debe ser posible
validar que el producto final satisface. Requisitos que no pueden ser
validados son en realidad 'desea'. por lo tanto, una tarea importante es la
Planificación de cómo comprobar cada requisito. En la mayoría de los casos,
la firma DE- pruebas de aceptación hace esto.
Identificación y diseño de pruebas de aceptación puede ser culto cultad para los
requisitos no funcionales (véase el tema 1.3 fun- cional y requisitos no
funcionales). Para ser validada de fecha, primero tienen que ser analizados para
el punto en que se pueden expresar cuantitativamente.
Información adicional se puede encontrar en el software de Exámenes ing KA,
subtema 2.2.4 Las pruebas de conformidad.
7. Consideraciones prácticas
El primer nivel de descomposición de sub-áreas que se presentan en este KA
puede parecer para describir una secuencia lineal de activi- dades. Esta es una
visión simplificada del proceso. [Dav93] El proceso requisitos abarca todo el ciclo
de vida del software. La gestión del cambio y el mantenimiento de los requisitos en
un estado que refleja con precisión el software que se construirán, o que se ha
construido, son la clave para el ceso Suc del proceso de ingeniería de software.
[Kot00; Lou95] No todas las organizaciones tienen una cultura de documentar y
gestionar los requisitos. Es frecuente en empresas de nueva creación dinámica,
impulsada por un fuerte 'visión de producto' y los recursos limi- ITED, para ver la
documentación de requisitos como una sobrecarga innecesaria. Muy a menudo,
sin embargo, ya que estas empresas expandirse, a medida que crece su base de
clientes, y como su producto comienza a evolucionar, descubren que necesitan
para recuperar los requisitos que motivaron las distintas prestaciones de productos
con el fin de evaluar el impacto de los cambios propuestos. Por lo tanto, la
documentación y los requisitos de cambiar ción manage- son clave para el éxito de
cualquier proceso de requisitos.
7.1. naturaleza iterativa del proceso Requisitos
[Kot00; You01]
Existe una presión general en la industria del software para los ciclos de desarrollo cada
vez más cortos, y esto es particularmente notable sus poblaciones en sectores altamente
competitivos impulsados ​por el mercado. Por otra parte, la mayoría de los proyectos se
ven limitados de alguna manera por su entorno, y muchos son actualizaciones o
revisiones
© IEEE - 2004 Versión
de, el software existente en el que se da por la arquitectura. En la práctica, por lo
tanto, es casi siempre poco práctico im- plemento el proceso de requisitos como
lineal, determinista proceso de TIC en los que los requisitos de software son
provocados a partir de los grupos de interés, la línea base, asignados y
entregados al equipo de desarrollo de software. Sin duda, es un mito que los
requisitos para grandes proyectos de software están siempre perfectamente
entendidas o perfectamente especificados. [Som97] En lugar de ello, los
requisitos normalmente iterar hacia un nivel de calidad y el detalle que es
suficiente para permitir que las decisiones de diseño y de adquisiciones a
realizar. En algunos proyectos, esto puede dar lugar a los requisitos que se
baselined antes de todas sus propiedades se entienden completamente. Se corre
el riesgo de retrabajo costoso si surgen problemas tarde en el software Engineer-
proceso ing. Sin embargo, ingenieros de software están necesariamente
limitados por los planes de gestión de proyectos y deben allí- proa tomar medidas
para asegurar que la 'calidad' de las exigencias es tan alto como sea posible
dados los recursos disponibles. Deben, por ejemplo, hacer explícitos los
supuestos que sustentan los requisitos, así como los problemas conocidos.
En casi todos los casos, los requisitos de conocimiento sigue
evolucionando como diseño y desarrollo de producto. Esto a menudo
conduce a la revisión de los requisitos finales del ciclo de vida. Quizás el
punto más crucial en la ingeniería de requisitos es la comprensión de que
una proporción significativa de los requisitos será cambio. Esto es a veces
debido a errores en el análisis, pero con frecuencia es una conse-
cuencia inevitable de cambio en el 'medio ambiente': por ejemplo, el
entorno operativo o de negocio del cliente, o el mer- cado en el que el
software deben vender. Cualquiera que sea la causa, es importante
reconocer la inevitabilidad del cambio y tomar medidas para mitigar sus
efectos. El cambio tiene que ser manejados edad asegurando que los
cambios propuestos pasan por un proceso de revisión y aprobación de-
multado, y, mediante la aplicación de Care- requisitos ful rastreo, análisis
de impacto, y la gestión de configuración de software (ver el software de
gestión de configuraciones ción KA) . Por lo tanto, el proceso de
requisitos no es sólo una tarea para el usuario en el desarrollo de
software, pero se extiende por todo el ciclo de vida del software. En una
típica Ject pro,
7.2. Gestión del cambio
[Kot00]
La gestión del cambio es fundamental para la gestión de re- quirements. En
este tema se describe el papel del cambio agement hombre-, los
procedimientos que deben estar en su lugar, y el análisis que se debe aplicar a
los cambios propuestos. Tiene fuertes vínculos con el Software de Gestión de
la Configuración KA.
7.3. requisitos Atributos
[Kot00]
Los requisitos deben consistir no sólo en una especificación de lo que se
requiere, sino también de la información auxiliar que
2-9
ayuda a controlar e interpretar los requisitos. Esto debe incluir las diversas satisfacerla (por ejemplo, de un requisito del sistema en los requisitos de
dimensiones de clasificación de la quirement re (ver tema 4.1 Requisitos de software que se han elaborado a partir de ella, y en en los módulos de
clasificación) y el método de verificación o un plan de prueba de código que lo implementan). Los requisitos de seguimiento para un proyecto
aceptación. También puede incluir información adicional, como una
típico formarán un complejo gráfico acíclico dirigido (DAG) de requisitos.
justificación de resumen para cada requisito, la fuente de cada
requerimiento, y un historial de cambios. Los requisitos más importantes
atribuyen, sin embargo, es un identificador que al-mínimos los requisitos 7.5. La medición de Requisitos
para ser identificado de forma única y no ambigua.
Como cuestión práctica, suele ser útil tener algún concepto de 'volumen'
de los requisitos para un producto de software particu- lar. Este número es
útil para evaluar el 'tamaño' de un cambio en los requisitos, en la
estimación del coste de una tarea de desarrollo o mantenimiento, o
7.4. requisitos de rastreo
simplemente para su uso como el denominador en otras mediciones.
[Kot00]
Medición tamaño funcional (FSM) es una técnica para evaluar el tamaño
Requisitos de rastreo se ocupa de la recuperación de la fuente de los de un cuerpo de requisitos funcionales. IEEE Std
requisitos y la predicción de los efectos de los requisitos. El rastreo es
fundamental para la realización de análisis de impacto cuando los 14.143,1 define el concepto de FSM. [IEEE14143.1-00] Normas de ISO /
requisitos cambian. Un requisito debe ser trazable hacia atrás a los IEC y otras fuentes describen métodos FSM cular par-
requisitos y los titulares stake- que motivaron que (de un requisito de
software de nuevo a la exigencia (s) del sistema que ayuda a satisfacer,
Información adicional sobre la medición de tamaño y Standards se
por ejemplo). Por el contrario, un requisito debe ser hacia delante trazables
encuentra en la Ingeniería de Procesos de Software KA.
a los requisitos y las entidades de diseño que

2-10 © IEEE - 2004 Versión

METRO ATRIX DE TEMAS VS. MATERIAL DE REFERENCIA

[IEEE141
[IEEE830

[Som97]

[Som05]
[Gog93]

43,1-00]

[Rob99]

[You01]
[Dav93]

[Lou95]

[Tha97]
[Kot00]

[Pfl01]
- 98]
1. Requisitos de software Fundamentos

1.1 Definición de un requisito de software * * c5 c1

1.2 Requisitos de producto y proceso * c1

1.3 Requisitos funcionales y no funcionales
* c1

1.4 Propiedades Emergentes c2

C3S
1.5 Requisitos cuantificables c6
4

1.6 Requisitos del sistema y requisitos de

software
2. Requisitos Proceso * c5

2.1 Los modelos de proceso C2S1 * c2 c3

2.2 Actores Proceso c2 * C2S2 c3 c2 c3

Administración y Apoyo 2.3 Proceso c3 c2 C2, C7

2.4 Proceso de Calidad y Mejora c2s4 c2 c5

3. la obtención de requisitos * * * *
3.1 Requisitos Fuentes c2 * c3s1 * * c1

3.2 técnicas de obtención c2 * c3s2 * *

Análisis 4. Requisitos * c6

4.1 Requisitos de Clasificación * c8s1 c6

4.2 Modelado Conceptual * * c7

4.3 Diseño Arquitectónico y requisitos de asignación
* c10

4.4 Requisitos de Negociación c3s4 *

5. Requisitos Especificación

5.1 El Documento de Definición del Sistema

5.2 La especificación de requisitos del sistema * * C9 c3

5.3 La especificación de requisitos de software * * * C9 c3

6. Requisitos de Validación * *
6.1 Requisitos críticas c4s1 c6 c5

6.2 Prototipos c6 c4s2 c8 c6

Validación 6.3 Modelo * c4s3 c5

6.4 Pruebas de Aceptación *

7. Consideraciones prácticas * * *
7.1 naturaleza iterativa del proceso Requisitos
c5s1 c2 c6

7.2 Gestión del Cambio c5s3

7.3 Atributos Requisito c5s2

7.4 Requisitos de rastreo c5s4

7.5 Requisitos de medición *

© IEEE - 2004 Versión 2-11


R ECOMMENDED R EFERENCIAS PARA S OFTWARE
R EQUERIMIENTOS
[Dav93] AM Davis, Requisitos de software: Objetos, funciones y
estados: Prentice-Hall, 1993.
[Gog93] J. Goguen y C. Linde, "Técnicas para la obtención de
requisitos", presentado en el International Sympo- Sium en Ingeniería
de Requerimientos, San Diego, Califor- nia, 1993
Sons, 2000.
[Lou95] P. Loucopulos y V. Karakostas, Sistemas de re-quirements
Ingeniería: McGraw-Hill, 1995. [Pfl01] SL Pfleeger, "Ingeniería de
Software: Teoría y Práctica", Segunda ed: Prentice-Hall, 2001, Cap. 4.
[Rob99] S. Robertson y J. Robertson, Dominar el proceso de los
requisitos: Addison-Wesley, 1999. [Som97] I. Sommerville y P. Sawyer,
"ingeniería Requisitos: Una guía de buenas prácticas", John Wiley and
Sons, 1997, cap. 1-2.

[IEEE830-98] IEEE Std 830-1998, IEEE Práctica Recomendada para los

requisitos de software Especificaciones: IEEE, [Som05] I. Sommerville, "Ingeniería de Software," SeV Enth Ed.:
1998. Addison-Wesley, 2005. [Tha97] RH Thayer y M. Dorfman, Eds,
(IEEE14143.1-00) IEEE std 14143.1- "Requisitos de software de ingeniería." IEEE Computer Society Press,
2000 // ISO / IEC14143-1: 1998, Tecnología Información- 1997, 176-205, 389-404. [You01] RR Usted, Requisitos Prácticas
Tamaño de software de medición-funcional Parte Medición- 1: eficaces:
Definiciones de conceptos: IEEE, 2000. [Kot00] G. Kotonya y I.
Sommerville, Requisitos técnicos: procesos y técnicas: John Wiley and Addison-Wesley, 2001.

2-12 © IEEE - 2004 Versión


UN PÉNDICE A. L LISTA DE F ás R EADINGS
(Ale02) I. Alexander y R. Stevens, Escribiendo quirements Mejor Re-: Addison-Wesley,
Tech- gía en Educación Industrial", presentado en la Conferencia Interna-
2002.
(Ard97) M. Ardis, "Métodos formales para telecomunicaciones Requisitos del
sistema ción: Un estudio de estandarizados Idiomas," Anales de Ingeniería
de Software, vol. 3, 1997 (Ber97) V. Berzins y otros, "Un modelo de evolución
de Requisitos para Prototipos asistido por ordenador", presentado en la
Novena Conferencia Internacional IEEE sobre Ingeniería de Software e
Ingeniería del Conocimiento, Skokie, Illinois: Instituto de Sistemas de
Conocimiento, 1997
(Bey95) H. Beyer y K. Holtzblatt, "Aprendiz con el cliente," Communications
of the ACM, vol. 38, ISS.
5, 45-52, mayo de 1995
(Bru95) G. Bruno y R. Agarwal, "Validación de Requisitos de software El
uso de modelos operativos", presentado en Segundo Simposio sobre
Técnicas calidad del software y los criterios de adquisición, Florencia, Italia,
1995
(Bry94) E. Bryne, "IEEE Standard 830: Práctica Recomendada para
Requerimientos de Software," pre-tantes en la Conferencia Internacional
IEEE en Ingeniería de Requerimientos, 1994
(Buc94) G. Bucci y otros, "Un Dual LANGUAGE orientada a objetos para
especificar Reactive Systems," presentado en la Conferencia
Internacional IEEE sobre Requisitos niería Inge-, 1994
(Bus95) D. Avutarda y P. Lundy, "Mejora suave Sys tems Análisis con
el modelado formal", presentado en Sec- ond Simposio Internacional
sobre Requisitos Engineer- ing, 1995
(Che94) M. Chechik y J. Gannon, "Automated verificables cación de los
requisitos de aplicación", presentado en Actas del Simposio
Internacional de Pruebas de Software y análisis, número especial de
1994
(Chu95) L. Chung y B. Nixon, "Tratar con los requisitos funcionales no-:
Tres estudios experimentales de un enfoque orientado al proceso",
presentado en Decimoséptima Conferencia Internacional IEEE sobre
Ingeniería de Software, 1995
(Cia97) P. Ciancarini y otros, "Ingeniería formales requerimientos: un
método de análisis y pruebas para la tos Z Docu-" Anales de Ingeniería
de Software, vol. 3, 1997 (Cre94) R. Crespo, "necesitamos identificar las
exigencias de las declaraciones de los requisitos no funcionales",
presentado en el Taller Internacional sobre Ingeniería mentos requisito:
Fundamentos de la Calidad del Software, 1994
(Cur94) P. Curran y otros, "BORIS-R especificación de los requisitos de un
software a gran escala Intensive sis- tema", presentado en la obtención de
requisitos para Software- Based Systems, 1994
(Dar97) R. Darimont y J. Souquières, "Reutilizando Requisitos fun- cional:
un enfoque orientado al proceso," pre-tantes en el Simposio Internacional
IEEE en Ingeniería de Requerimientos, 1997
(Dav94) A. Davis y P. Hsia, "Dar voz para volver a quirements
Ingeniería: Editores invitados Introducción"
© IEEE - 2004 Versión
rements Ingeniería: Editores invitados Introducción" IEEE Software, vol. 11,
ISS. 2, 12-16, Marzo, 1994 (Def94) J. Defoe, "Requisitos de Ingeniería
cional IEEE en Ingeniería de Requerimientos, 1994 (Dem97) E. Demirors,
"Un marco de la pizarra para apoyar a los equipos de desarrollo de
software "presentado en la Conferencia Internacional IEEE Novena de
Ingeniería del Software e Ingeniería del conocimiento, Skokie, Illinois:
conocimiento Systems Institute, 1997 (Die95) M. Diepstraten," Requisitos
de sistema de mando y control Análisis de Requerimientos y del sistema
especí - ficación para un sistema táctico ", presentado en Primera
Conferencia Internacional IEEE sobre Ingeniería de Sistemas complejos
de computadora, 1995
(Dob94) J. Dobson y R. Strens, "Requisitos de organización Definición de
Tecnología de la Información," pre-tantes en la Conferencia Internacional
IEEE en Ingeniería de Requerimientos, 1994
(Duf95) D. Duffy y otros, "Un marco para el análisis automatizado de los
requisitos Usando razonamiento", presentado en la Séptima Conferencia
Internacional sobre Sistemas de Infor- mación avanzada ingeniería, 1995
(Eas95) S. y B. Easterbrook Nuseibe, "Gestión De - consistencias en una
especificación en evolución ", presentado en el Segundo Simposio
Internacional sobre los requisitos de inge- niería, 1995
(Edw95) M. Edwards y otros, "Resumen: Un obtención de requisitos, captura y
proceso de análisis de prototipos de herramientas para Grandes Sistemas
Complejos", presentado en Primera Conferencia Internacional IEEE sobre
Ingeniería de sistemas informáticos complejos, 1995
(ElE95) K. El-Emam y N. Madhavji, "Requisitos de Prácticas de
Ingeniería en Sistemas de Información Desa- ción: A Case Study
múltiple", presentado en el Segundo Simposio Inter- nacional en
Ingeniería de Requerimientos, 1995 (Fai97) R. Fairley y R . Thayer, "el
concepto de Opera- ciones: El puente de los requisitos operacionales a
las especificaciones técnicas," Anales de la ingeniería de software, vol.
3, 1997
(Fic95) S. y M. Fickas pluma, "Requisitos de moni- Toring en entornos
dinámicos", presentado en Segundo Simposio Internacional sobre
Ingeniería de Requisitos, 1995
(Fie95) R. Campos y otros, "Un Enfoque Centrado en la tarea de analizar los
requisitos de tolerancia de errores humanos," pre-tantes en el Segundo
Simposio Internacional sobre Ingeniería de Requisitos, 1995
(Gha94) J. Ghajar-Dowlatshahi y A. Varnekar, "Rapid Prototyping en fase de
especificación de requisitos de Cesión de Software de Sistemas", presentado
en la Cuarta Internacional Sympo- Sium en Ingeniería de Sistemas,
Sunnyvale, California: Consejo Nacional de Ingeniería de Sistemas, 1994 (
Gib95) M. Gibson, "dominio reutilización del conocimiento Durante Ingeniería
de Requisitos", presentado en Séptima Conferencia Interna- cional de
Información avanzada Ingeniería de Sistemas (Caise '95), 1995
2-13
(Gol94) L. Goldin y D. Berry, "AbstFinder: Un prototipo de abstracción
Buscador de texto en lenguaje natural para su uso en la obtención de
requisitos: Diseño, Metodología y Evaluación", presentado en IEEE
Internacional Conferen- cia en Ingeniería de Requerimientos, 1994
(Got97) O. gotelé y A. Finkelstein, "Requisitos Ampliación de trazabilidad:
lecciones aprendidas a partir de un estudio de caso de industria",
presentado en el Simposio Internacional IEEE en Ingeniería de
Requerimientos, 1997 (Hei96) M. Heimdahl, "errores introducidos durante
el TACS II especificación de requisitos de esfuerzo: Un Estudio de Caso
retrospectivo tiva ", presentado en Decimoctava Conferencia Interna- cional
IEEE en Ingeniería de Software, 1996 (Hei96a) C. Heitmeyer y otros, 'la
consistencia automatizada requisitos de control de Especificaciones' ciones
ACM transac- en Ingeniería de Software y metodología, vol. 5, ISS. 3,
231-261, julio de 1996
(Hol95) K. Holtzblatt y H. Beyer, "Requisitos reunie- Ering: El factor
humano," Communications of the ACM,
vol. 38, ISS. 5, 31-32, mayo de 1995
(Hud96) E. Hudlicka, "Técnicas de obtención de requisitos con
conocimiento directo Elicitación In-: Comparación de tres métodos",
presentado en la Segunda Conferencia Internacional IEEE en Ingeniería de
Requerimientos, 1996 (Hug94) K. Hughes y otros, "una taxonomía para
requisito mentos técnicas de análisis ", presentado en la Conferencia
Interna- cional IEEE en Ingeniería de Requerimientos, 1994 (Hug95) J.
Hughes y otros, 'la presentación de Etnografía en el Proceso de Requisitos',
presentado en el Segundo Simposio IEEE Inter- nacional sobre Ingeniería
de Requisitos, 1995 (Hut94 .) ATF Hutt, Ed, "objeto Análisis y Diseño -.
Comparación de los métodos de objeto Análisis y Diseño - Descripción de
los Métodos". John Wiley & Sons, 1994. (INCOSE00) INCOSE, Cómo: Guía
para todos los ingenieros, Versión 2: Consejo Internacional de Ingeniería de
Sistemas,
2000.
(Jac95) M. Jackson, Requisitos de software y especifi- caciones. Reading,
Massachusetts: Addison Wesley, 1995. (Jac97) M. Jackson, "El
significado de los requisitos,"
Anales de Ingeniería de Software, vol. 3, 1997 (Jon96) S. Jones y C. Britton,
"Obtención temprana y Definición de los requisitos para un Sistema de
Información Multimedia Interactiva", presentado en Segunda Conferencia
Interna- cional IEEE en Ingeniería de Requerimientos, 1996 (Kir96) T. Kirner
y A . Davis, "los requisitos no funcionales para sistemas de tiempo real," Los
avances en las computadoras,
1996
(Kle97) M. Klein, "Manejo de excepciones en los requisitos de
colaboración Adquisición", presentado en el Simposio IEEE Interna- cional
en Ingeniería de Requerimientos, 1997 (Kos97) R. Kosman, "Una
metodología de dos pasos para volver Requisitos Duce Defectos" Annals
of Software Inge- niería, vol. 3, 1997
(Kro95) J. Krogstie y otros, "Hacia una posición más profunda comprensión de
la Calidad en Ingeniería de Requisitos," pre-tantes en la Séptima Conferencia
Internacional sobre Ingeniería de Sistemas de Información Avanzados (Caise
'95), 1995
2-14
(Lal95) V. Lalioti y B. Theodoulidis, "Escenarios visuales para la validación
de la especificación de requisitos", presentado en la Séptima Conferencia
Internacional sobre Ingeniería de Software e Ingeniería del Conocimiento,
Skokie, Illinois: Conocimiento Systems Institute, 1995 (Lam95) A. v .
Lamsweerde y otros, "dirigido a un objetivo Elabo- ración de Requisitos
para un programador de reuniones: proble- mas y lecciones aprendidas",
presentado en Segundo Simposio Interna- cional en Ingeniería de
Requerimientos, 1995 (Lei97) J. Leite y otros, "Mejora un Requisitos línea
de base con los escenarios ", presentado en el Simposio Internacional IEEE
en Ingeniería de Requerimientos, 1997 (Ler97) F. Lerch y col., 'Uso de
periments Ex simulación-Basados ​para Requisitos de software de
ingeniería'
Anales de Ingeniería de Software, vol. 3, 1997 (Lev94) N. Leveson y
otros, "Requisitos Especificación para Proceso-Control Systems," IEEE
Transactions on Software Engineering, vol. 20, ISS. 9, 684-707, ber sep-,
1994
(Lut96a) R. y R. Lutz Woodhouse, "Contribuciones de SFMEA a análisis
de requisitos", presentado en la Segunda Conferencia Internacional
IEEE sobre Requisitos de Ingenie- ría, 1996
(Lut97) ​R. y R. Lutz Woodhouse, "Requisitos de lisis Ana- utilizando
adelante y hacia atrás Buscar" Anales de Ingeniería de Software, vol. 3,
1997 (Mac96) L. Macaulay, Ingeniería de Requisitos. Lon- dres Reino
Unido: Springer, 1996.
(Mai95) N. Maiden y otros, "mecanismos computacionales para Requisitos
Distribuidos Ingeniería", presentado en la Séptima Conferencia Internacional
sobre Ingeniería de Software e Ingeniería del Conocimiento, Skokie, Illinois:
Instituto de Sistemas de Conocimiento, 1995
(Mar94) B. Mar, "Requisitos para el Desarrollo de Requisitos de
software", presentado en el Cuarto Simposio Internacional sobre
Ingeniería de Sistemas, Sunnyvale, Califor- nia, 1994
(Mas97) P. y A. Massonet. V Lamsweerde, "analógico reutilización de los
marcos Requisitos", presentado en el Simposio Internacional IEEE en
Ingeniería de Requerimientos de 1997
(McF95) I. McFarland y I. Reilly, "Requisitos ceability Trabasso en un
entorno de desarrollo integrado", presentado en Segundo Simposio
Internacional sobre Ingeniería de Requisitos, 1995
(Mea94) N. Mead, "El papel de la arquitectura de software en Ingeniería de
Requisitos", presentado en la Conferencia Interna- cional IEEE en Ingeniería
de Requerimientos, 1994 (Mos95) D. Mostert y S. v. Solms, "una técnica para
incluir la seguridad del ordenador , seguridad y capacidad de recuperación
Requisitos como parte de la especificación de requisitos,"
Diario de sistemas y software, vol. 31, ISS. 1, 45-53 de octubre de 1995
(Myl95) J. Mylopoulos y otros, "múltiples puntos de vista de lisis Ana- de
Proceso de Software memoria descriptiva," ciones IEEE transac- en Ingeniería
de Software, 1995 (Nis92) K. Nishimura y S. Honiden ", representando y
© IEEE - 2004 Versión
Uso de requisitos no funcionales: un enfoque orientado al proceso" IEEE
Transactions on Software Engineering,
De diciembre de 1992
(Nis97) H. Nissen y otros, "Ver-Dirigida Ingeniería de Requisitos: un
marco y Metamodel", presentado en la Novena Conferencia Internacional
IEEE sobre Ingeniería de Software e Ingeniería del Conocimiento, Skokie,
Illinois: Instituto de Sistemas de Conocimiento, 1997
(OBr96) L. O'Brien, "A partir de casos de uso de la base de datos: Im-
plementar un sistema de seguimiento Requisitos" Desarrollo de software, vol. 4,
ISS. 2, 43-47, febrero de 1996 (UML04) Object Management Group, "Unified
Modeling Language", 2004, disponible en http://www.uml.org (Opd94) A.
Opdahl, "Ingeniería de Requisitos de Software de rendimiento" presentado en
la tienda de Trabajo- Internacional en Ingeniería de Requerimientos:
Fundamentos de la Cesión de Software de Calidad, 1994
(Pin96) F. Pinheiro y J. Goguen, "Una herramienta orientada a objetos para
Rastreo de Requisitos," IEEE Software, vol. 13, ISS. 2, 52-64, marzo de 1996
(Pla96) G. Playle y C. Schroeder, "tos requisitos de software Obtención:
Problemas, herramientas y técnicas,"
Interferencias: El Diario de Defensa Ingeniería de Software,
vol. 9, ISS. 12, 19-24, diciembre de 1996
(Poh94) K. Pohl y otros, "La aplicación de las técnicas de IA para volver a
quirements Ingeniería: La naturaleza del prototipo," pre-tantes en IEEE Taller
sobre cuestiones de investigación en la intersección entre la ingeniería de
software y Artificial In- teligencia, 1994
(Por95) A. Porter y otros, "Comparación de métodos de detección de
Requisitos de software inspecciones: Un experimento replicado," IEEE
Transactions on ingeniería de software, vol. 21, ISS. 6, 563-575, junio,
1995
(Pot95) C. Potts y otros, "Una evaluación de análisis de requisitos basados ​en
la investigación para un servidor de Internet", presentado en el Segundo
Simposio Internacional Requisitos gineering En-, 1995
(Pot97) C. Potts y I. Hsi, "abstracción y el contexto en Ingeniería de
Requisitos: Hacia una síntesis," Anales de Ingeniería de Software, vol. 3,
1997
(Pot97a) C. Potts y W. Newstetter, "naturalista mensaje y la Ingeniería de
Requisitos: La reconciliación de sus cimientos retical teo", presentado en el
Simposio Internacional IEEE en Ingeniería de Requerimientos, 1997
(Ram95) B. Ramesh y otros, "implementar los requisitos de trazabilidad:
Un estudio de caso ", presentado en Segundo Simposio Internacional
sobre Ingeniería de Requisitos, 1995 (Reg95) B. Regnell y otros, 'la mejora
de la ven enfoque de casos de uso DRI a la Ingeniería de Requisitos',
presentado en el Segundo Simposio Internacional IEEE en Ingeniería de
Requerimientos, 1995
(Reu94) H. Reubenstein, "El papel del software arquitecturas tura en
Ingeniería de Requisitos de software", presentado en la Conferencia
Internacional IEEE en Ingeniería de Requerimientos, 1994
(Rob94) J. Robertson y S. Robertson, "Complete Sys
© IEEE - 2004 Versión
Análisis TEMS," vol 1 y 2. Los acantilados de Englewood, New Jer- sey:. Prentice
Hall, 1994.
(Rob94a) W. Robinson y S. Fickas, "Apoyo Multi-Perspectiva Ingeniería
de Requisitos", presentado en la Conferencia Internacional IEEE en
Ingeniería de Requerimientos, 1994
(Ros98) L. Rosenberg, TF Martillo y LL Huffman, "Requisitos, ensayos y
mediciones", presentado en el 15 Anual del Pacífico noroeste Conferencia
sobre la calidad del software, Utah, 1998
(Sch94) W. Schoening, "el gran paso siguiente en Ingeniería de Sistemas
Herramientas: La integración automatizadas Requisitos Herramientas con
ordenador simulado Síntesis y prueba," pre-tantes en el Cuarto Simposio
Internacional sobre Ingeniería de Sistemas, de Sunnyvale, California, 1994
(She94) M. Shekaran, "El papel de la arquitectura de software en Ingeniería de
Requisitos", presentado en la Conferencia Interna- cional IEEE en Ingeniería
de Requerimientos, 1994 (Sid97) J. Siddiqi y otros, "para los requisitos de
calidad a través de animadas especificaciones formales," Anales de Ingeniería
de Software, vol. 3, 1997
(Span97) G. Spanoudakis y A. Finkelstein, "Reconcil- ing Requisitos: Un
método para gestionar la interferencia, la incoherencia, y el conflicto," Annals
of Software Inge- niería, vol. 3, 1997
(Ste94) R. Stevens, "Requisitos estructurados", presentado en Cuarto
Simposio Internacional sobre Sistemas de ING Engineer-, Sunnyvale,
California, 1994 (Vin90) WG Vincenti, Lo que los ingenieros saber y
como saben son - Estudios analíticos forman Aeronáutica His- toria. Baltimore
y Londres: John Hopkins University Press, 1990. (Wei03) K. Weigers, Requisitos
de Software, 2ª ed: Microsoft Press, 2003.
(Whi95) S. White y M. Edwards, "Requisitos de una taxonomía para la
Especificación de Sistemas Complejos", presentado en Primera Conferencia
Internacional IEEE sobre Ingeniería de sistemas informáticos complejos,
1995 (Wil99) B. Wiley, Requisitos del sistema esenciales: Una Guía Práctica
de Métodos dirigido por eventos: Addison-Wesley, 1999.
(Wyd96) T. Wyder, "Requisitos Grabar vídeos con casos de uso" Desarrollo
de software, vol. 4, ISS. 2, 36-40, ro de fe-, 1996
(Yen97) J. y W. Yen Tiao, "Un análisis de relaciones de intercambio
sistemático de requisitos en conflicto imprecisos," pre-tantes en el Simposio
Internacional IEEE en Ingeniería de Requerimientos de 1997
(Yu97) E. Yu, "Hacia el puerto Modelado y Razonamiento SUP- de
Requisitos temprana fase de ingeniería," pre-tantes en el Simposio
Internacional IEEE en Ingeniería de Requerimientos de 1997
(Zav96) P. Zave y M. Jackson, "donde las operaciones vienen de? Una
técnica multiparadigma Especificación"
IEEE Transactions on Software Engineering ,, vol. 22, ISS.
7, 508-528, julio de 1996
2-15
 (IEEE1465-98) IEEE std 1465-
UN PÉNDICE B. L LISTA DE S NORMAS 1998 // ISO / IEC12119: 1994, La adopción de la norma IEEE Norma
(IEEE830-98) IEEE Std 830-1998, IEEE Práctica Recomendada para los Internacional ISO / IEC12119: 1994 (E), los requisitos ción
requisitos de software Especificaciones: IEEE, Tecnología-paquetes de software con calidad de Informa- y pruebas: IEEE,
1998. 1998. (IEEEP1471-00) IEEE Std 1471-2000, IEEE recomiendan especialmente
(IEEE1028-97) IEEE Std 1028-1997 (R2002), Norma IEEE para software para la Práctica de arquitectura de software Descriptionos sistemas intensivos: Grupo
comentarios: IEEE, 1997. (IEEE1233-98) IEEE Std 1233-1998, "Guía de de Trabajo de la arquitectura del Comité de Normas de Ingeniería de Software,
IEEE para el Desarrollo de Requisitos del sistema Especificaciones", 2000. (IEEE12207.0-96)
1998 (IEEE1320.1-98) IEEE Std 1.320,1-1.998, Norma IEEE para
modelado funcional Idioma-sintaxis y la semántica de IDEF0: IEEE 1998. IEEE / EIA 12207.0-
1996 // ISO / IEC12207: 1995, Implementación de la industria Int. Std. ISO /
IEC 12207: 95, Norma para Tecnología de la Información-Software Procesos
(IEEE1320.2-98) IEEE Std 1.320,2 hasta 1998, "Norma IEEE para del ciclo de vida, IEEE, 1996. (IEEE14143.1-00)
Modelado Conceptual Idioma en sintaxis y los tics Seman- para IDEFIX97 IEEE std 14143.1-
(IDEFObjetct)," IEEE, 1998. (IEEE1362-98) IEEE Std 1362-1998, IEEE 2000 // ISO / IEC14143-1: 1998, Tecnología Información-
Guía de Tecnología de la Información del Sistema-Definición-Concepto de Tamaño de software de medición-funcional Parte Medición- 1:
Operaciones (CONOPS) Documento: IEEE 1998. Definiciones de conceptos: IEEE, 2000.

2-16 © IEEE - 2004 Versión

 do CAPÍTULO 3 S OFTWARE
re DISEÑO
UN CRONYMS
Responsabilidades de colaboración ADL Arquitectura
Lenguajes de descripción de CRC tarjeta ERD
Entidad-Relación Diagramas de IDL
Interfaz Descripción Diagrama de flujo de
datos DFD Idiomas
PDL pseudo-código y el diseño basado en componentes Programa de
Diseño Idiomas CDB
yo INTRODUCCIÓN
Diseño se define en [IEEE610.12-90] ya que tanto “el proceso de definición de
la arquitectura, componentes, interfaces y otras características de un sistema
o componente” y “el resultado del proceso [que].” Como un proceso, diseño de
software es la actividad del ciclo de vida de ingeniería de software en el que
se analizan los requisitos de software con el fin de pro- ducir una descripción
de la estructura interna del software que va a servir de base para su
construcción. Más precisamente, un diseño de software (el resultado) debe
describir la arquitectura de software, es decir, cómo se descompone y se
organiza en componentes-y las interfaces entre los componentes de software.
También debe describir los componentes a un nivel de detalle que permita su
construcción. El diseño de software juega un papel importante en el desarrollo
de software: que permite a los ingenieros de software para producir varios
modelos que forman una especie de anteproyecto de la solución a
implementar. Podemos analizar y evaluar estos modelos para determinar si
son o no nos permitirán cumplir con los diversos requisitos. También podemos
examinar y evaluar diversas soluciones alternativas y compensaciones.
Finalmente, podemos utilizar los modelos resultantes para planificar las
actividades desa- rrollo posteriores, además de su uso como entrada y el
punto de partida de la construcción y prueba.
En una lista estándar de los procesos del ciclo de vida del software, tales como IEEE
/ EIA 12207 Procesos del ciclo de vida del software [IEEE12207.0-96], diseño de
software consta de dos activi- dades que se ajustan entre el análisis de los requisitos
de software y la construcción de software:
diseño de la arquitectura de software ( a veces llamado el diseño de nivel
superior): describir la estructura de alto nivel de software y la organización y la
identificación de los distintos componentes
Software de diseño de detalle: la descripción de cada componente suficiente para
permitir que para su construcción.
© IEEE - 2004 Versión
En cuanto al alcance del área de Diseño de Software conocimiento (KA), la
corriente Descripción KA no discute todos los temas cuyo nombre contiene la
palabra “diseño”. En la terminología de Tom DeMarco (DeM99), el KA dis-
cussed en este capítulo trata principalmente con D-diseño (diseño posición
descomposición, software de mapas en piezas componentes). Sin embargo,
debido a su importancia en el creciente campo de la arquitectura de software,
también vamos a tratar FP-diseño (diseño de modelo familiar, cuyo objetivo es
establecer puntos en común explotables en una familia de software). Por el
contrario, el software de diseño KA no se ocupa de la I-diseño (diseño
invención, generalmente se realiza durante el proceso de requisitos de software
con el objetivo de conceptualizar y el software espe- cifying para satisfacer las
necesidades y requerimientos descubiertos), ya que este tema debe ser
considerado como parte del análisis de exigencias y especificaciones. La
descripción del software de diseño KA se relaciona específicamente con
requisitos de software, software de construcción, Gestión de Ingeniería de
Software, Calidad de Software y Re- Disciplinas RELAClONADAS de Ingeniería
de Software.
segundo REAKDOWN DE T OPICS PARA S DISEÑO DEL SOFTWARE
1. Fundamentos del Diseño de Software
La conceptos, nociones y terminología introducida aquí forman una base
subyacente para la comprensión de la función y el alcance del diseño de
software.
1.1. Conceptos generales de diseño
El software no es el único campo en el que está implicado el diseño. En el sentido más
general, podemos ver el diseño como una forma de resolución de problemas. [Bud03: c1]
Por ejemplo, el concepto de una malvado
la solución de un problema sin solución definitiva, es interesante en términos de la
comprensión de los límites del diseño. [Bud04: c1] Un número de otras nociones y
conceptos También son de interés en la comprensión del diseño en su sentido general:
objetivos, las limitaciones, las alternativas, las representaciones y las soluciones.
[Smi93]
1.2. Contexto de Diseño de Software
Para entender el papel del diseño de software, es importante entender el
contexto en el que se inserta, el software de inge- niería ciclo de vida. Por lo
tanto, es importante comprender las características principales del análisis de
los requisitos de software de diseño de software vs vs vs construcción de
software de prueba del software. [IEEE12207.0-96]; Lis01: c11; Mar02; Pfl01:
c2; Pre04: c2]
3-1
1.3. Software de Diseño de Procesos 1.4.2. Acoplamiento y cohesión

El diseño de software se considera generalmente un proceso de dos pasos: [Bas03; Acoplamiento se define como la fuerza de los barcos relación entre
Dor02: v1c4s2; Fre83: I; IEEE12207.0-96]; módulos, mientras cohesión se define por cómo los elementos que

Lis01: c13; Mar02: D] componen un módulo se re RELAClONADAS. [Bas98: C6; Jal97: c5;
Pfl01: c5; Pre04: c9]
1.3.1. Diseño arquitectonico
1.4.3. La descomposición y la modularización
Diseño arquitectonico describe cómo el software se de- compuesta
y organizada en componentes (la arquitectura de software) La descomposición y modularización gran software en un número de los
[IEEEP1471-00] independientes más pequeños, por lo general con el objetivo de colocar
diferentes funcionalidades o responsa- bilidades en diferentes
1.3.2. Diseño detallado
componentes. [Bas98: C6; Bus96: c6; Jal97: c5; Pfl01: c5; Pre04: c9]
Diseño detallado describe el comportamiento específico de estos
componentes.
1.4.4. La encapsulación / ocultación de información
El resultado de este proceso es un conjunto de modelos y artefactos que
La encapsulación / ocultación de información significa la agrupación y el
registran las principales decisiones que se han tomado. [Bud04: c2;
envasado de los elementos y detalles internos de una abstracción y
IEE1016-98; Lis01: c13; Pre04: c9
haciendo esos detalles inaccesible. [Bas98: C6; Bus96: c6; Jal97: c5;
1.4. Técnicas de Activación Pfl01: c5; Pre04: c9]

De acuerdo con la Diccionario de ingles Oxford, un principio es “una verdad básica o
una ley general ... que se utiliza como base de un razonamiento o una guía para la
acción.” principios de diseño de software, también llamado permitiendo técnicas [ Bus96],
son nociones clave que se consideran fundamentales para muchos diferentes
enfoques de diseño de software y conceptos. Las técnicas que permiten son los
siguientes: [Bas98: C6; Bus96: c6; IEEE1016-98; Jal97: C5, C6; Lis01: c1, c3; Pfl01:
c5; Pre04: c9]
1.4.1. Abstracción
Abstracción es “el proceso de olvido información para que las cosas que
son diferentes pueden ser tratados como si fueran lo mismo”. [Lis01] En
el contexto del diseño de soft- ware, dos mecanismos clave de
abstracción son parametrización y especificación. Abstracción por la
especificación conduce a tres tipos principales de la abstracción:
abstracción de procedimientos, la abstracción de datos y control
1.4.5. La separación de la interfaz y la implementación de la interfaz de
separación e implementación implica la definición de un componente
mediante la especificación de una interfaz pública, conocido por los
clientes, aparte de los detalles de cómo se realiza el componente.
[Bas98: C6; Bos00: c10; Lis01: c1, C9]
1.4.6. Suficiencia, integridad y primitivismo alcanzar la suficiencia,
integridad y primitivismo significa la garantía de un componente
de software cap- turas todas las características importantes de
una abstracción, y nada más.
[Bus96: C6; Lis01: c5]

(iteración) abstracción. [Bas98: C6;

Jal97: C5, C6; Lis01: C1, C2, C5, C6; Pre04: c1]

Diseño de software

Diseño Análisis y Software de Diseño y

Fundamentos del diseño Cuestiones clave en el Estructura del software y Las notaciones de
Evaluación de la Estrategias
de software diseño de software Arquitectura diseño de software
Calidad de Software métodos

Diseño general Atributos de calidad descripciones

Las estrategias generales
concurrencia estructuras
conceptos estructurales (visión
arquitectónicas y
estática)
puntos de vista
El contexto del diseño Control y manejo
de software de eventos evaluación (estructurada)
descripciones de comportamiento

(Visión dinámica) funciones de trazado

Distribución de los (macroarchitectural
calidad y técnicas de Orientado a objetos
componentes patrones) diseño orientado a
software análisis medidas de
arquitectónicos
proceso de diseño de Los patrones de diseño
diseño de datos
excepción y culpa
(microarquitectura
y línea de mano centrada structrure
técnicas de Activación El tolerancia
presentación de errores patrones) Los estilos
Interacción y Basado en Componentes
Las familias de los programas
diseño
y marcos

la persistencia de datos
Otros metodos

Figura 1 Desglose de los temas para el Diseño de Software KA

3-2 © IEEE - 2004 Versión

2. Cuestiones clave en el diseño de software
Una serie de cuestiones clave debe ser tratado en el diseño de software. Algunos
son problemas de calidad que todo el software debe abordar, por ejemplo, el
rendimiento. Otra cuestión importante es cómo descomponer, organizar y
componentes de software paquete. Esto es tan fundamental que todos los ches
diseño approa- deben tener en cuenta que de una manera u otra (ver tema 1.4
Técnicas de Activación y sub-área 6 Software de Diseño y Estrategias Mehtods). Por amplia que implica el estudio de las estructuras y arquitecturas de software de una
el contrario, otras cuestiones “acuerdo con algún aspecto del comportamiento del
software que no es de dominio apli- cación, sino que se ocupa de algunos de los
dominios de apoyo”. [Bos00] Tales temas, que a menudo de corte transversal la
funcionalidad del sistema, se han referido como aspectos:
“[Aspectos] tienden a no ser unidades de composición de- funcional del software,
sino más bien a ser propiedades que afectan al Formance per o semántica de los
componentes en formas sistémicas” (Kic97). Un número de estas cuestiones
clave, transversales son los siguientes (presentado en orden alfabético):
2.1. concurrencia
Cómo descomponer el software en los procesos, las tareas y las discusiones y tratar
con eficacia relacionada, atomicidad, nización de sincronismo, y cuestiones de
programación. [Bos00: c5; Mar02: CDS; Mey97: c30; Pre04: c9]
2.2. Control y manejo de Eventos
Cómo organizar los datos y el flujo de control, cómo manejar tivo reac- y eventos
temporales a través de diversos mecanismos, tales como
implícito invocación y devoluciones de llamadas. [Bas98: c5;
Mey97: c32; Pfl01: c5]
2.3. Distribución de Componentes
Cómo distribuir el software en el hardware, cómo se comunican los
componentes, cómo middleware se puede utilizar para tratar con el
software heterogéneo. [Bas03: c16; Bos00: c5; Bus96: c2 Mar94: DD;
Mey97: c30; Pre04: c30]
2.4. Error y control de excepciones y la tolerancia a fallos
Cómo prevenir y tolerar fallos y hacer frente a condiciones excepcionales.
[Lis01: c4; Mey97: c12; Pfl01: c5]
2.5. Interacción y Presentación
La forma de estructurar y organizar las interacciones con los usuarios y la
presentación de información (por ejemplo, sepa- ración de presentación y la
lógica de negocio mediante el Modelo- Vista-Controlador
enfoque). [Bas98: C6; Bos00: c5;
Bus96: c2; Lis01: c13; Mey97: c32] Es de señalar que este tema no se trata de
especificar detalles de la interfaz de usuario, que es la tarea de diseño de la interfaz
de usuario (una parte de Software ergonomía); ver Disciplinas de Ingeniería de
Software relacionadas.
2.6. Persistencia de datos
¿Cómo de larga vida son los datos para ser manipulados. [Bos00: c5; Mey97: c31]
© IEEE - 2004 Versión
3. Estructura del software y Arquitectura
En su sentido más estricto, una arquitectura de software es “una descripción de los
subsistemas y componentes de un sistema de software y las relaciones entre
ellos”. (Bus96: c6) ture arquitecturas de este modo intenta definir el interior estructura
- de acuerdo con la Diccionario de ingles Oxford, “La forma en que se construye
algo u organizada” -del software resultante. A mediados de la década de 1990, sin
embargo, soft- ware arquitectura empezado a surgir como una disciplina más
manera más genérica [Sha96]. Esto dio lugar a una serie de ideas interesantes
sobre el diseño de software en diferentes niveles de abstracción. Algunos de
estos conceptos pueden ser útiles en el diseño arquitectónico (por ejemplo, el
estilo arquitectónico) de un software específico, así como durante su diseño
detallado (por ejemplo, de nivel más bajo patrones de diseño). Pero también
pueden ser útiles para el diseño de sistemas genéricos, lo que lleva al diseño de
familias de programas (también conocido como líneas de productos).
Curiosamente, la mayoría de estos conceptos puede ser visto como Los intentos de
describir, y por lo tanto volver a utilizar, diseño genérico knowl- borde.
3.1. Las estructuras arquitectónicas y puntos de vista
Las diferentes facetas de alto nivel de un diseño de software pueden y deben ser
descritos y documentados. Estas facetas son a menudo llamados puntos de vista: “Una
vista representa un aspecto parcial de una arquitectura de soft- ware que muestra
propiedades específicas de un sistema de Software” [Bus96: c6]. Estos puntos de
vista distintos se refieren a cuestiones distintas asociadas con el software de
diseño para ejem- plo, la vista lógica (satisfaciendo los mentos funcionales
requisitos) vs. la vista de proceso (problemas de concurrencia) vs. la vista física
(problemas de distribución) vs. el desarrollo vista (cómo el diseño se divide en
unidades de ejecución). Otros autores utilizan diferentes terminologías, como BE-
havioral vs vs funcional estructural frente a vistas de modelado de datos. En
resumen, un diseño de software es un artefacto de múltiples facetas producido por
el proceso de diseño y, en general com- puesto de puntos de vista relativamente
independientes y ortogonales. [Bas03: c2; Boo99: c31; Bud04: c5; Bus96: c6;
IEEE1016-98; IEEE1471-00] estilos arquitectónicos (patrones macroarchitectural)
Un estilo arquitectónico es “un conjunto de restricciones en una arquitec- tura [que]
define un conjunto o una familia de arquitecturas que les satisfactoria FIES” [Bas03:
c2]. Un estilo arquitectónico de este modo puede ser visto como un meta-modelo de
organización que puede proporcionar alto nivel de software (su macroarquitectura).
Varios autores han identificado una serie de grandes estilos arquitectónicos. [Bas03:
c5; Boo99: c28; Bos00: c6; Bus96: C1, C6; Pfl01: c5]
Estructura general (por ejemplo, capas, tubos y tros FIL-, pizarra)
Los sistemas distribuidos (por ejemplo, cliente-servidor, de tres niveles, agente)
Los sistemas interactivos (por ejemplo, Model-View- Controller,
Presentación-Abstracción-Control)
3-3
 sistemas adaptables (por ejemplo, micro-kernel, re- flexión)
Otros (por ejemplo, por lotes, intérpretes, proceso de con- trol, basado en
reglas).
3.2. Patrones de diseño (patrones) microarquitectónicas
Sucintamente descrito, un patrón es “una solución común a un problema común
en un contexto dado”. (Jac99) Mientras arqui- estilos tectural pueden ser vistos
como patrones que describen la organización de alto nivel de software (su macro
arqui- tectura), otros patrones de diseño se puede utilizar para describir los
detalles en un nivel inferior locales más (su micro arquitectura). [Bas98: c13;
Boo99: c28; Bus96: c1; Mar02: DP]
patrones de creación (por ejemplo, constructor, fábrica, prototipo, y
Singleton)
patrones estructurales (por ejemplo, adaptador, puente, com- puesto,
decorador, fachada, peso mosca, y el proxy) Los patrones de
comportamiento (por ejemplo, comandos, intérprete, iterador, mediador,
recuerdo, observador, estado, estrategia, plantilla, visitante )
3.3. Las familias de los programas y marcos
Un enfoque posible para permitir la reutilización de los signos y los componentes de
software de- es diseñar familias de software, también conocido como software líneas de
productos. Esto se puede hacer mediante la que se identifica los puntos en común entre
los miembros de estas familias y mediante el uso de componentes reutilizables y
personalizables para dar cuenta de la variabilidad entre los miembros de la familia.
[Bos00: c7, c10; Bas98: c15; Pre04: c30]
En la programación OO, una noción relacionada clave es que del marco: un
subsistema de software parcialmente completo que puede ser extendido por
apropiadamente instanciar plug-ins específicos (también conocido como Puntos
calientes). [ Bos00: c11; Boo99: c28; Bus96: c6]
4. Análisis de Calidad de Software de Diseño y Evaluación
En esta sección se incluye una serie de calidad y evaluación de los temas que se
relacionan específicamente con el diseño de software. La mayoría están cubiertos de
manera general en la calidad del software KA.
4.1. Atributos de calidad
Varios atributos se consideran generalmente importantes para la obtención de
un diseño de software de buena calidad varios “lazos” ili- (mantenibilidad,
portabilidad, capacidad de prueba, trazabilidad), varios “sas” (corrección,
robustez), incluyendo “Ness FIT- de propósito”.
[Bos00: c5; Bud04: C4; Bus96: c6;
ISO9126.1-01; ISO15026-98; Mar94: D; Mey97: C3;
Pfl01: c5] Una distinción interesante es la que existe entre los atributos de calidad
perceptible en tiempo de ejecución (rendimiento, seguridad, disponibilidad,
funcionalidad, facilidad de uso), los que no discernible en tiempo de ejecución
(modificabilidad, portabilidad, dad reusabil-, integrabilidad y la capacidad de prueba)
, y las relacionadas con cualidades intrínsecas de la arquitectura (integridad
conceptual, rectness cor- y completitud, edificabilidad). [Bas03: c4]
3-4
4.2. Análisis de calidad y técnicas de evaluación
Varias herramientas y técnicas pueden ayudar a garantizar la calidad de un diseño de
software.
las revisiones de diseño de software: informal o semiformal, a menudo a base
de grupo, las técnicas para comprobar y garantizar la cali- dad de los
artefactos de diseño (por ejemplo, la arquitectura revisiones [Bas03: c11], las
revisiones de diseño e inspecciones [Bud04: C4; Fre83: VIII; IEEE1028- 97;
Jal97: C5, C7; Lis01: c14; Pfl01: c5],
basado en escenarios técnicas
[Bas98: c9; Bos00: c5], requisitos rastreo
[Dor02: v1c4s2; Pfl01: c11])
Análisis estático: (No ejecutable) análisis estático formal o semiformal que se
puede utilizar para evaluar una señal de- (por ejemplo, análisis de árbol de
fallos o automatizado comprobación cruzada) [Jal97: c5; Pfl01: c5]
Simulación y creación de prototipos: técnicas dinámicas para evaluar
un diseño (por ejemplo, ción o viabilidad rendimiento simula- prototipo
[Bas98: c10; Bos00: c5; Bud04: c4; Pfl01: c5])
4.3. medidas
Las medidas pueden ser utilizados para evaluar o estimar cuantitativamente diversos
aspectos de tamaño, estructura, o la calidad de un diseño de software. La mayoría de
las medidas que se han propuesto en general, dependen del método utilizado para la
producción del diseño. Estas medidas se clasifican en dos grandes categorías:
medidas (estructurada) de diseño orientado a la función de: la estructura del
diseño, obtenida principalmente a través de la descomposición funcional;
generalmente representado como un diagrama de estructura (a veces llamado
un diagrama jerárquico) en el que diversas medidas se pueden calcular [Jal97:
C5, C7, Pre04: c15]
medidas de diseño orientado a objetos: la estructura general del diseño es a
menudo representado como un diagrama de clases, en la que se pueden
calcular diversas medidas. Medidas sobre las propiedades del contenido interno
de cada clase también se pueden calcular [Jal97: c6, c7; Pre04: c15]
5. Diseño de Software notaciones
Existen muchas notaciones y lenguajes para representar artefactos de diseño de
software. Algunos se utilizan principalmente para describir la organización estructural
de un di- seño, otros para representar el comportamiento del software. Ciertas
notaciones se utilizan sobre todo durante el diseño arquitec- tural y otros,
principalmente durante el diseño detallado, al- aunque algunas anotaciones se pueden
utilizar en ambas etapas. Otras medidas, además, algunas notaciones se utilizan sobre
todo en el contexto de métodos especí- espe- (ver la El software de diseño estrategias y
métodos sub-área). Aquí, se clasifican en ciones notaciones para describir la vista
estructural (estático) vs. la vista BE- havioral (dinámico).
5.1. Descripciones estructurales (ver estático)
Las siguientes anotaciones, en su mayoría (pero no siempre) gráfica, describen y
representan los aspectos estructurales de un software de diseño, es decir, que
describen los componentes principales y la forma en que están interconectados (visión
estática):
© IEEE - 2004 Versión
 Descripción de la arquitectura idiomas (AVD): textual, a menudo formal,
idiomas utiliza para describir un software ar- quitectura en términos de
componentes y conectores [Bas03: c12]
Clase y objeto diagramas: se utiliza para representar un conjunto de
clases (y objetos) y sus interrelaciones [Boo99: c8, c14; Jal97: C5,
C6]
diagramas de componentes: utiliza para representar un conjunto de compo-
nentes ( “físico y parte reemplazable [s] de un sistema que [conforme] para
y [proporcionar] la realización de un conjunto de interfaces” [Boo99]) y sus
interrelaciones [Boo99: c12, c31]
tarjetas de responsabilidades de colaboración (CRC): usado para denotar los
nombres de los componentes (clase), sus responsabilidades y nombres de
sus componentes colaboradoras [Boo99: C4; Bus96]
Los diagramas de despliegue: se utiliza para representar un conjunto de nodos
(físicas) y sus interrelaciones, y, por lo tanto, para modelar los aspectos físicos
de un sistema [Boo99: c30]
diagramas entidad-relación (ERD): se utiliza para representar modelos
conceptuales de datos almacenados en la información siste- mas [Bud04: C6;
Dor02: v1c5; Mar02: DR]
Descripción de la interfaz de idiomas (IDL): PROGRAMACION- como los
lenguajes utilizados para definir las interfaces (nombres y tipos de operaciones
exportadas) de componentes de software [Bas98: c8; Boo99: c11]
Jackson diagramas de estructura: se usa para describir las estructuras de datos
en términos de secuencia, selección, y la iteración [Bud04: C6; Mar02: DR]
los diagramas de estructura: se usa para describir la estructura de los
programas de llamadas (llamadas qué módulo, y se llama por que otro
módulo) [Bud04: c6; Jal97: c5; Mar02: DR; Pre04: c10]
5.2. Descripciones de comportamiento (ver dinámico)
Las siguientes notaciones y lenguajes, algunos gráfica y textual alguna, se utilizan
para describir el comportamiento dinámico de software y componentes. Muchas
de estas notaciones son útiles sobre todo, pero no exclusivamente, durante el
diseño detallado.
diagramas de actividad: utilizado para mostrar el flujo de control de la actividad (
“ejecución no atómica en curso dentro de una máquina de estado”) a la actividad
[Boo99: c19]
diagramas de colaboración: utilizan para mostrar las interacciones que se
producen entre un grupo de objetos, donde el énfasis está en los objetos, sus
enlaces, y los mensajes que intercambian en estos enlaces [Boo99: c18]
diagramas de flujo de datos (DFDs): utilizado para mostrar el flujo de datos entre
un conjunto de procesos [Bud04: C6; Mar02: DR; Pre04: c8]
Las tablas de decisión y diagramas: se utiliza para representar combinaciones
complejas com- de condiciones y acciones
[Pre04: c11]
© IEEE - 2004 Versión
Diagramas de flujo y diagramas de flujo estructurados: utilizado para represen-
enviado el flujo de control y las acciones asociadas a ser realizadas [Fre83: VII;
Mar02: DR; Pre04: c11]
Los diagramas de secuencia: utilizado para mostrar las interacciones entre un
grupo de objetos, con énfasis en el ordenamiento tiempo- de mensajes
[Boo99: c18]
transición y statechart diagramas de estado: utilizado para mostrar el flujo de
control de estado a estado en una máquina de estado [Boo99: c24; Bud04: c6;
Mar02: DR; Jal97: c7]
lenguajes de especificación formales: lenguajes textuales que utilizan nociones
básicas de la matemática (por ejemplo, la lógica, conjunto, secuencia) para
definir rigurosamente y de manera abstracta interfaces y comportamiento de los
componentes de software, a menudo en términos de pre- y post-condiciones
[Bud04: C18; Dor02: v1c6s5; Mey97: c11]
Pseudo-código y el diseño de programas idiomas (PDL):
estructurados, los lenguajes de programación que se usa para de- escriba,
generalmente en la etapa de diseño detallado, el beha- Vior de un
procedimiento o método [Bud04: C6; Fre83: VII; Jal97: c7; Pre04: c8, c11]
6. Diseño de Software estrategias y métodos
Existen varios generales estrategias para ayudar a guiar el proceso de diseño. [Bud04:
c9, Mar02: D] En contraste con las estrategias erales generaciones, métodos son más
específicos en cuanto a que generaciones ralmente sugieren y proporcionan un
conjunto de notaciones para ser utilizado con el método, una descripción del proceso
que se utilizará cuando se sigue el método y un conjunto de directrices en el uso del
método. [Bud04: C8] Tales métodos son útiles como un medio de transferencia de
conocimiento y como un marco común para equipos de ingenieros de software. [Bud03:
c8] Véase también la Soft-Herramientas de ingeniería cerámica y Métodos KA.
6.1. Las estrategias generales
Algunos ejemplos citados con frecuencia de estrategias generales útiles en el
proceso de diseño son de divide y vencerás y refinamiento paso a paso [Bud04: c12;
Fre83: V], de arriba hacia abajo vs. estrategias de abajo hacia arriba [Jal97: c5; Lis01:
c13], la abstracción de datos y ocultar infor- mación [Fre83: V], el uso de la heurística
[Bud04: c8], el uso de modelos y lenguajes de patrones [Bud04: c10; Bus96: c5], el
uso de un enfoque iterativo e incremental. [Pfl01: c2]
6.2. orientados a funciones específicas (estructurado) Diseño
[Bud04: c14; Dor02: v1c6s4; Fre83: V; Jal97: c5; Pre04: c9,
c10]
Este es uno de los métodos clásicos de diseño de software, donde los centros de
descomposición en la identificación de las principales funciones del software y luego
elaborar y refinar ellos de una manera de arriba hacia abajo. Diseño estructurado se
utiliza generalmente después de un análisis estructurado, lo que produce, entre otras
cosas, diagramas de flujo de datos y las descripciones de proceso asociada. Los
investigadores han propuesto diversas estrategias (por ejemplo, el análisis de la
transformación, análisis de transacciones) y heurística (por ejemplo, fan-in / fan-out, el
alcance de efecto vs. alcance de control) para transformar un DFD en un software
archi- tecture generalmente representado como un gráfico de estructura.
3-5
6.3. Diseño orientado a objetos
[Bud0: c16; Dor02: v1: c6s2, s3; Fre83: VI; Jal97: c6; Mar02: D;
Pre04: c9]
Se han propuesto numerosos métodos de diseño de software basados ​en objetos. El
campo ha evolucionado desde el diseño basado a objetos principios de la década de
1980 (sustantivo = objeto; verbo = método; adjetivo = atributo) a través del diseño OO,
donde la herencia y polimorfismo juegan un papel clave, al campo del diseño basado
en componentes , donde la meta-información se puede definir y se accede a (a través
de la reflexión, por ejemplo). Aunque las raíces del diseño orientado a objetos
provienen del concepto de abstracción de datos, diseño impulsado por la
responsabilidad también se ha propuesto como un enfoque alternativo al diseño
orientado a objetos.
ingeniero de software se describen en primer lugar las estructuras de entrada y salida de
datos (utilizando diagramas de estructura de Jackson ?, a la postura in-) y luego se
desarrolla la estructura de control del programa en base a estos diagramas de estructura
de datos. Se han propuesto varias heurísticas para tratar los casos de ejem- plo
especiales, cuando hay una falta de correspondencia entre las estructuras de entrada y
salida.
6.5. Diseño basado en componentes (CDB)
Un componente de software es una unidad independiente, que tiene bien interfaces y
dependencias definidos que pueden estar compuestos y desplegado de forma
independiente. aborda cuestiones de diseño basadas en componentes relacionados con
la prestación, desarrollo, e integradora rejilla de tales componentes con el fin de mejorar
la reutilización. [Bud04: c11]

6.4. Diseño Centrado en la estructura de datos

6.6. Otros metodos
[Bud04: c15; Fre83: III, VII; Mar02: D]
También existen otros enfoques interesantes pero menos convencionales:
diseño Data-estructura centrada (por ejemplo, Jackson, Warnier-Orr)
métodos formales y rigurosos [Bud04: c18; Dor02: c5; Fre83; Mey97: c11; Pre04:
comienza a partir de las estructuras de datos de un programa manipula en c29] y los métodos de transformación. [Pfl98: c2]
lugar de partir de la función que realiza. los

3-6 © IEEE - 2004 Versión

 [IEEE1016-98] [I mi EE1028-97] [I m
{} Bas98 [Boo99] [Bos00] [Bud03] [B
METRO ATERIAL
c2 c1

c2s4 c2s3 c6s3

3-7 v1c4s2

0.0 -
2-22

* *

* *

[Jal97] [Lis01] [Mar02] * {Mar94}96]

c5s1,
c5s2,
c6s2

[Pre04] [Smi93]
c4s3-c4s5 C1S1,

[ISO15026-98]
c13s3 c1s2, c13s1, c11s1
c3s1-c3s3,
77-85, c5s8,
125-128, c13s2

[Mey97] [Pfl01]
c9s1-c9s3

[ISO9126-01]
*
{DD} CDS
Consulte
re re
la
sección siguiente

c32s2 c32s4,
c31 c12 c30 c30

c32s5

c5s5 c5s3 c5s2, C2S2

c5s5

c30 C9 C9 C9 c2

*
 3-8

© IEEE - 2004 Versión

c7s4
c6s5,

c15
c5s6,
*
576

[YO
c7s3
c4

c5s7,

c11s5

SO9 1 26-01] [ISO15026-98] [Jal97] [Lis01] [Mar02] * {} Mar94

c14s1

[Mey97] [Pfl01] [Pre04] [Smi93]

542-
v1c4s2

c5s5,

{Bas98} [Boo99] [Bos00] [Bud03] [Bus96]

c5s3, c5s4

[IEEE1016-98] [IEEE1028-97] [IEEE1471-0

c5s6,
*
*

c3
c4

{RE}

c5s5
c6s4
c11s4

C30
c6s2

DP
c1s1-
c1s3

c6s2
c1s1-,

c5s3
c1s3

*
*
c5

c6s1
 [Pre04] [Smi93]
[IEEE
C6, C18

[IEEE1028-97]
c18 c11 C15 c16 c14 c8, c6
c10, c12

[Mey97] [Pfl01]
c5s4

[IEEE1016-98]
429

c5s1-

* {} Mar94
3-9 v1c6s3 v1c6s2 v1c6s4
181- v1c5

[Mar02][Fre83]
,
192

[Lis01][Dor02]
395- 514- 210, 201- 420- 328- 533- 320, 304- 513 506 -490, 485-

[Bus96]
407 532 436 352 539

[Boo99]
[ISO9126-01
{Bas98} [Jal97]
[Bos00] [Bud03]
] [ISO15026-98]
c5s1.4 c5s3,
c6s4 c5s4 c7s2

6S3 c

c13s13

DR DR
re re

c11 c11

C2S2 C2S2

c9, c10 c8, c11

C29 c10
C9
 [IEEE12207.0-96] IEEE / EIA 12207.0-
R ECOMMENDED R EFERENCIAS PARA S OFTWARE 1996 // ISO / IEC12207: 1995, Implementación de la industria Int. Std. ISO /
re DISEÑO IEC 12207: 95, Norma de Información tecnolo- gía-Software Procesos del ciclo

[Bas98] L. Bass, P. Clements y R. Kazman, Arquitectura de software en la de vida, vol. IEEE, 1996. [ISO9126-01] ISO / IEC 9126-1: 2001, Ingeniería de

práctica: Addison-Wesley, 1998. [Bas03] L. Bass, P. Clements y R. software, la calidad del producto-Parte 1: Modelo de Calidad: ISO e IEC,

Kazman, Arquitectura de software en la práctica, Segunda ed:

Addison-Wesley,
2003.
[Boo99] G. Booch, J. Rumbaugh y I. Jacobson, El Modelado Unificado guía de
idiomas de usuario, Primera ed: Addison-Wesley, 1999. [Bos00] J. Bosch, Diseño
y uso de software Arquitecturas: La adopción y el desarrollo de un enfoque de
línea de producto, Primera edición: ACM Press, 2000. [Bud04] D. Budgen, Diseño
de software, Segunda ed: Addison-Wesley, 2004.
2001.
[ISO15026-98] ISO / IEC 15026 a 1998, Información tecnolo- gía - integridad
del sistema y software de niveles: ISO e IEC,
1998. [Jal97] P. Jalote, Un enfoque integrado sobre Software En-
gineering, Segunda ed. Nueva York: Springer-Verlag, 1997. [Lis01] B. y J.
Liskov Guttag, Desarrollo de programación en Java: Abstracción,
especificación de diseño, y orientado a objetos, Primera ed:
Addison-Wesley, 2001. [Mar94] JJ Marciniak, Enciclopedia de software
Inge- niería: J. Wiley & Sons, 1994. Las referencias a la Enciclopedia son
mínimos como DOL:

[Bus96] F. Buschmann, R. Meunier, H. Rohnert, P. Som- merlad y M. Stal, orientado

patrón-Software arquitecturas tura: un sistema de modelos, Primera edición:
John Wiley & Sons,
1996.
basado en componenent CDB = Diseño D = Diseño DD = Diseño
[Dor02] M. Dorfman y RH Thayer, Eds., "Ingeniería de Software". (Vol. 1 y del Sistema Distribuido de DR = Diseño Representación [Mar02] JJ
Vol. 2), IEEE Computer Society Press, 2002.
Marciniak, Enciclopedia de software Inge- niería, Segunda ed: J. Wiley &
Sons, 2002. [Mey97] B. Meyer, Orientada a Objetos ción Software
[Fre83] P. Freeman y AI Wasserman, Tutorial sobre técnicas de diseño soft-
Construc-, Segunda ed: Prentice-Hall, 1997. [Pfl01] Pfleeger SL, Ingeniería
ware, Cuarta Edición: IEEE Computer socie- ETY Press, 1983.
de Software: Teoría y Práctica, Segunda ed: Prentice-Hall, 2001. [] Pre04
RS Pressman, Ingeniería de Software: Un Enfoque de Tioner prác-, ed
[IEEE610.12-90] IEEE Std 610.12-1990 (R2002), Glosario IEEE Estándar
Sexto: McGraw-Hill, 2004. [Smi93] G. Smith y G. Browne, "fundamentos
de Ingeniería de Software Terminología:
IEEE, 1990. conceptuales del diseño de la solución de problemas" IEEE Transactions

[IEEE1016-98] IEEE Std 1016-1998, IEEE Práctica Recomendada para las on Systems, el hombre y la cibernética, vol. 23, ISS. 5, 1209-1219,

descripciones de diseño de software: IEEE, 1998. [IEEE1028-97] IEEE Std septiembre-octubre,

1028-1997 (R2002), Dard IEEE Están- de software comentarios: IEEE, 1997.

[IEEE1471-00] IEEE Std 1471-2000, IEEE Práctica Recomendada para la
arquitectura de software Descriptionos sistemas intensivos: Grupo de Trabajo
de la arquitectura de la Comisión de Normas de Ingeniería de Software, 2000.

1993.

3-10 © IEEE - 2004 Versión


UN PÉNDICE A. L LISTA DE F ás R EADINGS
(Boo94a) G. Booch, Análisis orientado a objetos y el diseño con
aplicaciones, Segunda ed: The Benjamin / Cummings Publishing Company,
Inc., 1994. (Coa91) P. Coad y E. Yourdon, Diseño Orientado a Objetos:
Yourdon Press, 1991. (Cro84) N. Cruz, Los avances en metodología de
diseño:
John Wiley & Sons, 1984.
(DSo99) DF D'Souza y AC Wills, Objetos, componentes y marcos con
UML - El proach Catálisis: Ap- Addison-Wesley, 1999.
(Dem99) T. DeMarco, "La paradoja de software arquitecturas tura y Diseño" Ponencia
Premio Stevens, De agosto de 1999 (Fen98) NE Fenton y Pfleeger SL, Las
métricas de software: un enfoque riguroso y práctico, Segunda ed:
International Thomson Computer Press, 1998. (Fow99) M. Fowler, Refactoring:
mejorar el diseño de código existente: Addison-Wesley, 1999. (Fow03) M.
Fowler, Los patrones de arquitectura de aplicación empresarial, Primera ed.
Boston, MA: Addison-Wesley, 2003. (Gam95) E. Gamma, R. Helm, R.
Johnson y J. Vlissides,
Patrones de diseño: Elementos de software reutilizables orientada a
objetos: Addison-Wesley, 1995. (Hut94) ATF Hutt, Objeto de Análisis y
Diseño - La comparación de métodos. Objeto de Análisis y Diseño - descrip-
ción de los métodos: John Wiley & Sons, 1994. (Jac99) I. Jacobson, G.
Booch y J. Rumbaugh, El proceso de desarrollo de software Uni-ficado: Addison-Wesley,
1999.
(Kic97) G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda,
C. Lopes, J.-M. Loingtier y J. Irwin, "programación orientada a aspectos",
presentado en ECOOP '97 - Orientado a Objetos
© IEEE - 2004 Versión
Programación de 1997
(Kru95) PB Kruchten, "The 4 + 1 vista de modelo de ture arquitec-," IEEE
Software, vol. 12, ISS. 6, 42-50, 1995 (Lar98) C. Larman, La aplicación de
UML y Patrones: Una introducción a Orientada a Objetos Análisis y
Diseño: Prentice-Hall, 1998. (McC93) S. McConnell, Código completo:
Manual práctico del software de construcción: Microsoft Press,
1993. (Pag00) M. Página-Jones, Fundamentos de diseño orientada a objetos
en UML: Addison-Wesley, 2000. (Pet92) H. Petroski, Al ingeniero es humano:
El papel de la insuficiencia en el éxito del diseño: Vintage Books, 1992.
(Pre95) W. Pree, Patrones de diseño para el desarrollo de software orientado
a objetos: Addison-Wesley y ACM Press,
1995. (Rie96) AJ Riel, Orientado a Objetos La heurística de diseño:
Addison-Wesley, 1996.
(Rum91) J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy y W. Lorensen, Orientada
a Objetos Modelado y Diseño:
Prentice-Hall, 1991. (Sha96) M. Shaw y D. Garlan, arquitectura de
software: Perspectivas sobre una disciplina emergente: Prentice Hall,
1996. (Som05) I. Sommerville, Ingeniería de software, Sexta edición:
Addison-Wesley, 2001.
(Wie98) R. Wieringa, "A Survey of estructurado y objeto: métodos de
especificación de software orientado y Técnicas"
ACM Computing Surveys, vol. 30, ISS. 4, 459-527, 1998 (Wir90) R.
Wirfs-Brock, B. Wilkerson y L. Wiener,
El diseño de software orientado a objetos: Prentice-Hall, 1990.
3-11
 La práctica de arquitectura de software Descriptionos sistemas intensivos: Grupo
de Trabajo de la arquitectura del Comité de Normas de Ingeniería de
Software, 2000. (IEEE12207.0-96)
UN PÉNDICE B. L LISTA DE S NORMAS IEEE / EIA 12207.0-
1996 // ISO / IEC12207: 1995, Implementación de la industria Int. Std. ISO /
(IEEE610.12-90) IEEE Std 610.12-1990 (R2002), Glosario IEEE Estándar
IEC 12207: 95, Norma de Información tecnolo- gía-Software Procesos del ciclo
de Ingeniería de Software Terminología:
de vida, vol. IEEE, 1996. (ISO9126-01) ISO / IEC 9126-1: 2001, Ingeniería de
IEEE, 1990.
software, la calidad del producto-Parte 1: Modelo de Calidad: ISO e IEC,
(IEEE1016-98) IEEE Std 1016-1998, IEEE Práctica Recomendada para las
descripciones de diseño de software: IEEE, 1998. (IEEE1028-97) IEEE Std
2001.
1028-1997 (R2002), Dard IEEE Están- de software comentarios: IEEE, 1997.
(ISO15026-98) ISO / IEC 15026 a 1998, Información tecnolo- gía - integridad
(IEEE1471-00) IEEE Std 1471-2000, IEEE Recomendado
del sistema y software de niveles: ISO e IEC,
1998.

3-12 © IEEE - 2004 Versión

 do CAPÍTULO 4 S OFTWARE do

ONSTRUCCIÓN

la gestión de proyectos, en la medida en la gestión de cons- trucción puede

UN CRONYMS presentar retos considerables.

Dios mio grupo de administración de objetos

segundo REAKDOWN DE T OPICS PARA S OFTWARE do ONSTRUCCIÓN
UML Lenguaje de Modelado Unificado
El detalle de la construcción del software KA es pre SENTED continuación,
junto con una breve descripción de los principales temas asociados a ella.
yo INTRODUCCIÓN referencias apropiadas también se dan para cada uno de los temas. La Figura
1 da una representación gráfica de la descomposición de nivel superior de la
La construcción software término se refiere a la crea- ción detallada de software de
desglose de este KA.
trabajo, significativa a través de una combinación de la codificación, la verificación, la
unidad de pruebas, las pruebas de integración, y la depuración.

1. Fundamentos de construcción de software

El software de construcción área de conocimiento está vinculado a todos los
Los fundamentos de la construcción de software incluyen
demás Kas, más fuertemente a Diseño de software y pruebas de software. Esto se
debe a que el proceso de construcción de software en sí consiste en el diseño de Minimizar la complejidad del cambio
software y la actividad significativa prueba. También utiliza la salida de diseño y
Anticipando La construcción de
ofrece una de las entradas de la prueba, tanto en el diseño y las pruebas siendo
estándares de verificación en la
las actividades, no la KAS en este caso. límites detallados entre el diseño,
construcción y pruebas (si alguna) variarán dependiendo de los procesos del ciclo construcción
de vida del software que se utilizan en un proyecto.
Los tres primeros conceptos se aplican al diseño, así como a con- trucción. Las
siguientes secciones se definen estos conceptos y describen cómo se aplican a la
construcción.
Aunque algunos de diseño detallado se puede realizar antes de la construcción, tanto el
1.1. Minimizar la complejidad [ Bec99; Ben00; Hun00; Ker99; Mag93; McC04]
trabajo de diseño se realiza dentro de la actividad de la construcción en sí. Así, la
Un factor importante en cómo las personas transmiten intención de ordenadores es la
construcción del software KA está estrechamente vinculado con el software de diseño
capacidad muy limitada de las personas para mantener las estructuras complejas e
KA. A lo largo de la construcción, tanto los ingenieros de software de prueba de unidad
información en sus memorias de trabajo, especialmente durante largos períodos de
e integración a prueba su trabajo. Por lo tanto, el Software Con- trucción KA está
tiempo. Esto conduce a uno de los pilotos más fuertes en la construcción de software:
estrechamente vinculada a la Prueba de Software KA también.
minimizar la complejidad. La necesidad de reducir la complejidad se aplica
esencialmente a todos los aspectos de la construcción de software, y es
particularmente crítico para el proceso de verificación y comprobación de con-
construcción de software normalmente produce el mayor volu- men de los elementos de trucciones de software.
configuración que necesitan ser administrados en un proyecto de software (archivos de

origen, el contenido, los casos de prueba, y así sucesivamente). Por lo tanto, la construcción

del software KA también está estrechamente ligada a la Gestión de la Configuración de

En la construcción de software, complejidad reducida se logra a través hincapié
Software KA. Desde la construcción de software se basa en gran medida de las en la creación de código que es simple y fácil de leer en lugar de inteligente.
herramientas y métodos, y es probablemente la herramienta más intensivas de la KAS, que

está vinculada a las herramientas de ingeniería de software y métodos KA.

Mientras que la calidad del software es importante en todos los Kas, código es la entrega
definitiva de un proyecto de software, y por lo tanto la calidad del software también está
estrechamente vinculada a Software Con- trucción.
minimizando la complejidad se lleva a cabo a través de hacer uso de las
normas, que se discute en el tema 1.4 Normas de Construcción, ya través de
numerosas técnicas específicas que se resumen en el tema 3.3 Codificación. También
se Apoyado por las técnicas de construcción de calidad centrado-resumidos
en el tema 3.5 Construcción de Calidad.

1.2. pronóstico del cambio

Entre las disciplinas de la ingeniería de software relacionados, la construcción
[Ben00; Ker99; McC04] La mayoría del software va a cambiar con el
del software KA es más afín a la informática en su uso del conocimiento de
tiempo, y la anticipación de los cambios que impulsa muchos aspectos de la
algoritmos y de de- prácticas de codificación de cola, los cuales a menudo se
construcción de software. El software es una parte inevitable de cambiar bientes
consideran pertenecientes al dominio de la informática. También se relaciona
externa

© IEEE - 2004 Versión 4-1

am-, y cambios en los ambientes externos afectan al software de diversas Dardos para lenguajes como Java y C ++) métodos de comunicación (por
maneras. ejemplo, normas para formatos de documentos y contenidos) plataformas (por

anticipar el cambio es apoyado por muchas técnicas específicas que se resumen ejemplo, estándares de interfaz de programador de llamadas al sistema
en el tema 3.3 Codificación. operativo)

1.3. La construcción de Verificación

[Ben00; Hun00; Ker99; Mag93; McC04] La construcción de medios de
verificación de construcción de software de tal manera que los fallos se pueden
descubrían fácilmente por los ingenieros de software de escritura de software, así como
durante las pruebas independientes y las actividades operacionales. Las técnicas
específicas que apoyan la construcción para la verificación incluyen siguiendo los
estándares de codificación para apoyar puntos de vista de código re, la unidad de
pruebas, la organización de código para apoyar pruebas automatizadas, y el uso
restringido de las estructuras del lenguaje complejas o difíciles de comprender, entre
otros.
herramienta (por ejemplo, las normas para esquemáticas ciones notaciones
como UML (Unified Modeling Language))
El uso de estándares externos. La construcción depende de la utilización de
estándares externos para lenguajes de construcción, herramientas de
construcción, interfaces técnicas, y las interacciones entre el software de
construcción y otra de Kas. Normas proceden de numerosas fuentes,
incluyendo hardware y software especificaciones de interfaz, como el Grupo de
Gestión de objetos (OMG) y las organizaciones internacionales, como la IEEE
o ISO.

1.4. Normas de construcción El uso de estándares internos. Las normas también pueden ser creados sobre una base
de organización a nivel corporativo o para su uso en proyectos específicos. Estas
[IEEE12207-95; McC04]
normas apoyan la coordinación de las actividades de grupo, lo que minimiza la
Normas que afectan directamente a problemas de construcción incluyen
complejidad, la anticipación del cambio, y la construcción para su verificación.
lenguajes de programación (por ejemplo, el lenguaje Están-

Construcción de software

Fundamentos
Construcción de Consideraciones
de software
la gestión prácticas
Construcción

Complejidad minimizando Modelos de construcción diseño de la construcción

cambio
Verificación pronóstico del Codificación
La construcción de Planificación de construcción

Medición de construcción Prueba de la construcción

Reutilización Construcción Idiomas

Normas de
construcción La construcción de calidad

Integración

Figura 1. Desglose de los temas para la Construcción de Software KA.

extenso trabajo de diseño y planificación detallada. Los enfoques más

2. Gestión de la Construcción
lineales tienden a enfatizar las actividades que pre- ceder construcción
2.1. Modelos de construcción [ Bec99; McC04] Numerosos modelos han sido (requisitos y el diseño), y tienden a crear separaciones más claras entre las

creados para el desarrollo de software, algunos de los cuales hacen hincapié en la

construcción más que otros. Algunos modelos son más lineal desde el punto de vista
constructivo, como por ejemplo la cascada y realizaron modelos de ciclo de vida de
entrega. Estos modelos tratan construcción como una actividad que se produce sólo
actividades. En estos modelos, el énfasis principal de la construcción puede
ser de codificación.
Otros modelos son más iterativo, como totyping evolutiva pro, la

después del trabajo requisito previo importante se ha completado, incluyendo requisitos

programación extrema, y ​scrum. Estos enfoques tienden a tratar a la
construcción como una actividad que se produce simultáneamente con otras
detallados de trabajo, (las líneas anteriores necesitan ser llevado hacia abajo por
activi- dades de desarrollo de software, incluidos los requisitos, el diseño y la
debajo de la figura)
planificación, o

4-2 © IEEE - 2004 Versión

ellos se superpone. Estos enfoques tienden a diseño, ing de bacalao y mezclar las Al igual que los trabajadores de la construcción la construcción de una estructura física deben

actividades de prueba, y que a menudo tratan la combinación de actividades como la adaptarse al hacer modificaciones a pequeña escala para dar cuenta de las lagunas no previstos

construcción. en los planes del constructor, trabajadores de la construcción de software deben hacer

modificaciones en una escala más pequeña o más grande para dar cuerpo a los detalles del
En consecuencia, lo que se considera ser “construcción” depende en cierta
diseño de software Du- ing construcción.
medida en el modelo de ciclo de vida utilizado.

2.2. Ordenación de la Edificación

[Bec99; McC04]
La elección del método de construcción es un aspecto clave de la actividad de
planificación de la construcción. La elección del método de construcción afecta el
grado en que se llevan a cabo las obras de construcción requisito previo, el orden
en que se realizan, y el grado en el que se espera que esté terminado antes de
que comience el trabajo de construcción.
El enfoque de la construcción afecta a la capacidad del proyecto para reducir la
complejidad, anticiparse a los cambios, y construir para su verificación. Cada uno
Los detalles de la actividad de diseño en el ámbito de la construcción son
esencialmente el mismo que el descrito en el Software DE- firmar KA, pero se
aplican en una escala más pequeña.
3.2. Idiomas de construcción
[Hun00; McC04]
lenguas de construcción incluir todas las formas de comunica- ción por el que un ser
humano puede especificar una solución problema ejecutable a un ordenador. El tipo
más simple del lenguaje es una construcción idioma con- figuración, en el que los
ingenieros de software elegir entre un conjunto limitado de opciones predefinidas para

de estos objetivos también pueden ser tratadas en el proceso, los requisitos y los crear instalaciones nuevas o personalizadas de software. Los archivos de configuración

niveles de diseño, sino que también se verá afectado por la elección del método de basados ​en texto que se utilizan tanto en los sistemas operativos Windows y Unix son

construcción. ejemplos de esto, y las listas de selección de estilo de menú de algunos generadores
de programas constituyen otro.

planificación de la construcción también define el orden en que se crean com-

ponentes e integrada, los procesos de gestión de calidad de software, la
asignación de la asignación de tareas a los ingenieros de software específicos, idiomas Toolkit se utilizan para construir aplicaciones fuera de las cajas de herramientas
y las otras tareas, accord- ing al método elegido. (conjuntos integrados de partes reutilizables de aplicación específica), y son más complejos
que los idiomas de configuración. idiomas Toolkit pueden definirse explícitamente como
lenguajes de programación de aplicaciones (por ejemplo, scripts), o simplemente pueden
2.3. Medición de la construcción
estar implicados por el conjunto de interfaces de un kit de herramientas.
[McC04]

Numerosas actividades de construcción y artefactos pueden ser medi- ured, incluyendo

Lenguajes de programación son el tipo más flexible de las lenguas cons- trucción.
el código desarrollado, código modificado, re código utilizado, código destruida, la
También contienen la menor cantidad de información sobre áreas específicas de
complejidad del código, estadísticas de inspección de código, culpa y
aplicación y procesos de desa- rrollo, y por lo tanto requieren más entrenamiento y
culpa-fix-encontrar tarifas, esfuerzo, e ING schedul-. Estas mediciones pueden ser útiles
habilidad para utilizar con eficacia.
para los propósitos de la gestión de la construcción, lo que garantiza la calidad durante
la construcción, mejorando el proceso de construcción, así como por otras razones. Ver
Hay tres tipos generales de notación utilizadas para lenguajes de
la Ingeniería de Procesos de Software KA para más información sobre las mediciones.
programación, a saber:

Lingüística

formal Visual
3. Consideraciones prácticas

La construcción es una actividad en la que el software tiene que ponerse de

notaciones lingüísticas se distinguen en particular por el uso de cadenas de
acuerdo con straints con- reales arbitrarias y caóticas, y hacerlo exactamente.
palabras-como de texto para representar complejas construcciones soft- ware, y la
Debido a su proximidad al mundo real limitaciones, la construcción está más
combinación de tales cadenas de palabras-como en patrones que tienen una
impulsado por consideraciones prácticas que algunos otros Kas, y el software de
sintaxis frase similar. se utiliza correctamente, cada uno de tales cadena debe
inge- niería es quizás lo más artesanal como en el área de la construcción.
tener una fuerte connotación mántica SE- proporcionar una comprensión intuitiva
inmediata de lo que sucederá cuando se ejecuta la construcción de software
3.1. Diseño de la construcción
subyacente.
[Bec99; Ben00; Hun00; IEEE12207-95; Mag93; McC04]

Las notaciones formales depender menos de significados intuitivos y cotidianas de

palabras y cadenas de texto, y más en las definiciones respaldadas por definiciones
Algunos proyectos asigna mayor actividad de diseño para la construcción; otros a una
precisas, no ambiguas, y formales (o matemáticos). notaciones formales de construcción
fase se centró explícitamente en el diseño. Independientemente de la asignación
y métodos formales están en el corazón de la mayoría de las formas de programa-
exacta, algún trabajo de diseño detallado se producirá a nivel de la construcción, y
sistema ming, donde la precisión, comportamiento en el tiempo, y la capacidad de prueba
que el trabajo de diseño tiende a ser dictado por las limitaciones impuestas por el
son más importantes que la facilidad de mapeo en lenguaje natural. construcciones
inamovibles problema del mundo real que está siendo tratado por el software.
formales también utilizan formas definidas con precisión de

© IEEE - 2004 Versión 4-3

la combinación de símbolos que evitan la ambigüedad de muchas construcciones de
lenguaje natural.
notaciones visuales confiar mucho menos en las notaciones nes orientados a texto, tanto
de construcción lingüística y formal, y en lugar de confiar en la interpretación visual directa
y la colocación de las entidades visuales que representan el software subyacente. Visual
de la construcción tiende a ser algo limitado por la dificultad de hacer declaraciones
“complejas” utilizando sólo el movimiento de las entidades visuales en una pantalla. Sin
embargo, también puede ser una herramienta roso pow- en los casos en que la tarea de
programación principal es simplemente para construir y “ajustar” una interfaz visual de un
programa, el comportamiento detallado de los cuales habían sido definidos anteriormente.
3.3. Codificación
[Ben00; IEEE12207-95; McC04]
Las siguientes consideraciones se aplican al software con- trucción actividad
codificación:
Las técnicas para crear el código fuente comprensible, incluyendo
denominación y el código fuente de diseño
El uso de clases, tipos enumerados, variables, constantes con nombre, y
otras entidades similares uso de estructuras de control
Manipulación de las condiciones-tanto el error errores y excepciones previstas (de entrada
de datos erróneos, por ejemplo) Prevención de fallos de seguridad a nivel de código
(tampón carreras exceso o desbordamiento de índice de matriz, por ejemplo) El uso de
recursos mediante el uso de mecanismos de exclusión y la disciplina en el acceso
recursos reutilizables en serie (in- cluyendo las discusiones o las cerraduras de bases de
datos)
Organización del código fuente (en enunciados, rutinas, clases, paquetes,
u otras estructuras) de ajuste Código Código documentación
3.4. Prueba de la construcción
[Bec99; Hun00; Mag93; McC04]
Construcción implica dos formas de pruebas, que a menudo son realizadas por el
ingeniero de software que escribió el código:
Unidad de prueba Las pruebas
de integración
El propósito de las pruebas de la construcción es el de reducir la brecha entre el
momento en que los fallos se insertan en el código y el tiempo se detectan los
fallos. En algunos casos, las pruebas de cons- trucción se realiza después de
código ha sido escrito. En otros casos, los casos de prueba pueden crearse antes
de código está escrito.
pruebas de construcción típicamente implica un subconjunto de tipos de pruebas
que se describen en el Testing de Software KA. Por ejemplo, las pruebas de
construcción no suelen incluir las pruebas del sistema, las pruebas alfa, pruebas
beta, pruebas de estrés, pruebas de configuración, las pruebas de usabilidad, u
otros tipos especia-, más espe- de pruebas.
Dos estándares han sido publicados sobre el tema: IEEE Std 829-1998, IEEE Estándar
para la Documentación de software de prueba
4-4
e IEEE Std 1008-1987, IEEE estándar para el software de pruebas unitarias.
Ver también las correspondientes sub-temas en el Software Test-ing KA: 2.1.1 Examen
de la unidad y 2.1.2 Pruebas de integración
para material de referencia más especializado.
3.5. Reutilizar
[IEEE1517-99; Som05]. Como se indica en la introducción de
(IEEE1517-99): “La aplicación de la reutilización del software implica algo más que la
creación y uso de bibliotecas de activos. Se requiere la formalización de la práctica de
reutilización mediante la integración de procesos de reutilización y activi- dades en el ciclo de
vida del software.”Sin embargo, la reutilización es lo suficientemente impor- tante en la
construcción de software que se incluye aquí como tema.
Las tareas relacionadas con la reutilización en la construcción de software durante la codificación y
las pruebas son:
la selección de las unidades reutilizables, bases de datos, procedimientos de prueba, o los
datos de prueba de la evaluación de código o prueba reutilización la presentación de la
información reutilización en código nuevo, procedimientos de prueba, o datos de prueba.
3.6. construcción de Calidad
[Bec99; Hun00; IEEE12207-95; Mag93; McC04]
Existen numerosas técnicas para asegurar la calidad del código, ya que se
construye. Las técnicas primarios utilizados para construc- ción incluyen:
Las pruebas unitarias y pruebas de integración (como se menciona en el tema 3.4 Prueba
de la construcción)
Ensayos primer desarrollo (véase también la Prueba de Software KA, tema 2.2
Objetivos de la prueba)
Código pisar Uso de las
afirmaciones de
depuración
Revisiones técnicas (véase también la calidad del software KA, subtema 3.3 Revisiones
técnicas)
El análisis estático (IEEE1028) (véase también el software de cali- dad KA, tema
3.3 Revisiones y auditorías)
La técnica o técnicas específicas seleccionadas dependen de la naturaleza del software
que está siendo construido, así como en las habilidades conjunto de los ingenieros de
software que realizan la cons- trucción.
actividades de calidad de construcción se diferencian de otras actividades de calidad por su
enfoque. calidad de la construcción activi- lazos se centran en código y en los artefactos que
están estrechamente relacionados con el código: diseños, como a pequeña escala en
comparación con otros artefactos que están conectados directamente al menos el código,
como re- quirements, diseños de alto nivel, y los planes .
© IEEE - 2004 Versión
3.7. Integración Preocupaciones relacionadas con la integración de la construcción incluyen la
Planificación de la secuencia en la que se integrarán componentes, creando un
[Bec99; IEEE12207-95; McC04]
andamio para soportar versiones provisionales de la soft- ware, determinar el grado
Una actividad clave durante la construcción es la integración de rutinas
de pruebas y la calidad del trabajo realizado en los componentes antes de que se
construidos por separado, clases, componentes y subsistemas. Además, puede
integran, y la determinación de puntos en el proyecto en el que se prueban versiones
necesitar ser integrado con otros TEMS software o hardware Systematic un
provisionales del software.
sistema de software en particular.

© IEEE - 2004 Versión 4-5

 Matriz de Temas vs. Material de Referencia

12207.0]
[Ben00]

[Mag93]
[Hun00]
[Bec99]

[Ker99]

[Som05]
1517]

[Mcc04]
[IEEE

[IEEE
1. Fundamentos de construcción de
software

c2, c3,
C7-C9,
C24, C27,
1.1 minimiza la complejidad c17 c2, c3 C7, C8 c2, c3 c6 C28, C31,
C32, C34

C3-C5,
c11, c13, C24, C31,
1.2 pronóstico del cambio c2, c9
c14 C32, C34

c8,
1.3 La construcción de veri- c21, c23, C1, C5, c2, c3, c5,
c4 c20-c23,
ficación c34, c43 C6 c7
c31, c34
1.4 Estándares en cons- trucción
X c4

2. Gestión de Construc- ción

C2, C3,
2.1 Construcción Modals c10
C27, C29

C3, C4,
c12, c15,
2.2 Ordenación de la Edificación C21,
c21
C27-C29

urement 2.3 Construcción

c25, c28
medi-

3. consideraciones prácticas

c8-c10, C3, C5,

3.1 Diseño de la construcción c17 c33 X c6
p175-6 C24

3.2 len- guas de C12, C14

c4
construcción c20

C5-C19,
3.3 Codificación C6-C10 X
C25-C26

3.4 Prueba de construcción c18 c34, c43 X c4 c22, c23

3.5 reutilización X c14

c8,
3.6 Construcción de Calidad c18 c18 X c4, c6, c7
c20-c25
3.7 Integración c16 X c29

4-6 © IEEE - 2004 Versión

 1996 // ISO / IEC12207: 1995, Implementación de la industria Int. Std. ISO /
R ECOMMENDED R EFERENCIAS PARA S OFTWARE do ONSTRUCCIÓN IEC 12207: 95, Norma para Tecnología de la Información-Software
Procesos del ciclo de vida, vol. IEEE,
1996.
[Bec99] K. Beck, "Extreme Programming Explained: aceptar el cambio",
[Ker99a] BW Kernighan y R. Pike, "La Práctica de Programación",
Addison-Wesley, 1999, Cap. 10, 12,
Addison-Wesley, 1999, Cap. 2, 3, 5, 6,
15, 16-18, 21.
9.
[Ben00a] J. Bentley, "perlas de programación", Segunda ed:
[Mag93] S. Maguire, "Escribir código Solid: Técnicas de Microsoft para el
Addison-Wesley, 2000, Cap. 2-4, 6-11, 13, 14, pp. 175-
desarrollo de software C libre de errores," Microsoft Press, 1993, Cap.
176.
2-7. [McC04] S. McConnell, Código completo: Manual práctico de
[Hun00] A. Hunt y D. Thomas, "The Pragmatic Pro- Grammer," construcción del software, Microsoft Press, 2 Dakota del Norte
Addison-Wesley, 2000, Cap. 7, 8 12, 14-21,
23, 33, 34, 36-40, 42, 43.
edición, 2004.
[IEEE1517-99] IEEE Std 1517-1999, Norma IEEE sobre Tecnología de la
[Som05] I. Sommerville, "Ingeniería de Software", SeV Enth ed:
Información del Ciclo de Vida-Software Procesos procesos- Reutilización: IEEE,
Addison-Wesley, 2005.
1999. [IEEE12207.0-96]
IEEE / EIA 12207.0-

© IEEE - 2004 Versión 4-7

 Código: Microsoft Press, 2002. (Hum97b) WS Humphrey, Introducción al
UN PÉNDICE A. L LISTA DE F ás R EADINGS Proceso de Software Personal: Addison-Wesley, 1997. (Mey97) B. Meyer,
"Construc- ción de software orientada a objetos," Segunda ed:
(Bar98) TT Barker, Escribiendo Documentación de software: un enfoque
Prentice-Hall, 1997, Cap. 6, 10, 11. (Set96) R. Sethi, "Lenguajes de
orientado a la tarea: Allyn y Bacon, 1998. (Bec02) K. Beck, "desarrollo
Programación: Conceptos y construcciones," Segunda ed: Addison-Wesley,
basado en pruebas: Por ejem- plo," Addison-Wesley, 2002. (Fow99) M.
1996, Partes II -
Fowler y col, Refactoring: mejorar el diseño de código existente: Addison-Wesley,
1999. (How02) M. Howard y DC Leblanc, escribiendo seguro
V.

4-8 © IEEE - 2004 Versión

 (IEEE1517-99) IEEE Std 1517-1999, Norma IEEE sobre Tecnología de la
UN PÉNDICE B. L LISTA DE S NORMAS Información del Ciclo de Vida-Software Procesos procesos- Reutilización: IEEE,
1999. (IEEE12207.0-96)
(IEEE829-98) IEEE Std 829-1998, IEEE estándar para el software de
IEEE / EIA 12207.0-
documentación de prueba: IEEE, 1998. (IEEE1008-87) IEEE Std 1008-1987
1996 // ISO / IEC12207: 1995, Implementación de la industria Int. Std. ISO /
(R2003), IEEE estándar para el software de pruebas unitarias: IEEE, 1987.
IEC 12207: 95, Norma para Tecnología de la Información-Software
(IEEE1028-97) IEEE Std 1028-1997 (R2002), Norma IEEE para software Procesos del ciclo de vida, vol. IEEE,
comentarios: IEEE 1997. 1996.

© IEEE - 2004 Versión 4-9

4-10 © IEEE - 2004 Versión
 do CAPÍTULO 5 S OFTWARE
T PRUEB
UN CRONYM
SRET Software de Pruebas de confiabilidad Engineered
yo INTRODUCCIÓN
La prueba es una actividad realizada para evaluar la calidad del producto, y para mejorarla,
mediante la identificación de defectos y problemas. Pruebas de software consiste en la dinámica
la verificación del comportamiento de un programa en una finito un conjunto de casos de
prueba, adecuadamente
seleccionado Del dominio de las ejecuciones por lo general infinita, en contra de la esperado comportamiento.
En la definición anterior, palabras en cursiva corresponden a cuestiones clave en la
identificación del área de conocimiento de pruebas de software. En particular:
Dinámica: Este término significa que las pruebas siempre implica la ejecución
del programa en los insumos (valorados). Para ser precisos, el valor de
entrada por sí sola no siempre es suficiente para determinar una prueba, ya
que un sistema determinista compleja, no podría reaccionar a la misma
entrada con comportamientos diferentes, dependiendo del estado del sistema.
En este KA, sin embargo, el término “entrada” se mantendrá, con la
convención implícita que su significado también incluye un estado de la
entrada especificada, en aquellos casos en que se necesita. Diferente de las
pruebas, y complementaria a la misma, son técnicas estáticas, como se
describe en la calidad del software KA
Finito: Incluso en los programas simples, por lo que muchos casos de prueba
son teóricamente posible que la prueba exhaustiva podría requerir meses o
años para su ejecución. Por eso, en la práctica todo el equipo de prueba
general puede considerarse infinita. Las pruebas siempre implica un equilibrio
entre los recursos y los horarios limitados, y los requisitos de la prueba
inherentemente ilimitado
Seleccionado: Las muchas técnicas de prueba propuestos difieren esencialmente
en la forma de seleccionar el juego de prueba, y los ingenieros de software deben
ser conscientes de que los diferentes criterios de selección pueden producir muy
diferentes grados de eficacia. Cómo identificar el criterio de selección más
adecuado bajo condiciones dadas es un problema muy complejo; en la práctica,
se aplican técnicas de análisis de riesgo y experiencia de ingeniería de prueba
Esperado: Debe ser posible, aunque no siempre es fácil, para decidir si
los resultados observados de la ejecución del programa son aceptables o
no, de lo contrario el esfuerzo de prueba sería inútil. El comportamiento
observado puede ser verificada contra las expectativas del usuario
(comúnmente conocidas como pruebas de validación), contra una
especificación (Pruebas de verificación), o, por último, en contra de
el comportamiento esperado implícita de
© IEEE - 2004 Versión
requisitos o expectativas razonables. Véase, en los requisitos de
software KA, tema 6.4 Prueba de aceptacion
La vista de las pruebas de software ha evolucionado hacia una más constructiva.
Testing ya no se ve como una actividad que se inicia sólo después de la fase de
codificación se ha completado, con el propósito limitado de fallos de detección. Las
pruebas de software se ve ahora como una actividad que debe abarcar todo el
proceso de desarrollo y mantenimiento, y es en sí mismo una parte importante de la
construcción real del producto. De hecho, la planificación de las pruebas deben
comenzar con las primeras etapas del proceso de requerimiento, y los planes y
procedimientos de prueba debe ser sistemática y continua desarrollado, y,
posiblemente, refinado, conforme avanza el desarrollo. Estas actividades de
planificación y el diseño de la prueba en sí constituyen una contribución útil para los
diseñadores para poner de relieve las debilidades potenciales (como descuidos de
diseño o contradicciones y omisiones o ambigüedades en la documentación).
Actualmente se considera que la actitud correcta hacia la calidad es uno de
prevención: es, obviamente, mucho mejor para evitar los problemas que a
corregirlos. Las pruebas deben ser visto, entonces, principalmente como un medio
para comprobar no sólo si la prevención ha sido eficaz, sino también para la
identificación de fallas en aquellos casos en los que, por alguna razón, no ha sido
eficaz. Es quizás obvio, pero vale la pena reconocer, que, incluso después de la
finalización con éxito de una amplia campaña de prueba, el software aún podría
contener errores. El remedio para los fallos de software experimentados después
del parto es proporcionada por las acciones de mantenimiento correctivo.
Mantenimiento del software
temas se tratan en el Software
Mantenimiento KA.
En la calidad del software KA (Véase el apartado 3.3 Las técnicas de gestión de
calidad de software), técnicas de gestión de calidad de software son principalmente
clasifican en: estático técnicas (sin la ejecución de código), y dinámica técnicas (la
ejecución de código). Ambas categorías son útiles. Esta área de conocimiento se
centra en técnicas dinámicas. Las pruebas de software también está relacionado con
la construcción de software (ver tema 3.4 Prueba de la construcción en ese KA).
Unitarias y pruebas de integración están íntimamente relacionados con la construcción
de software, si no es parte de ella.
segundo REAKDOWN DE T OPICS
El desglose de pruebas de software KA de temas se muestra en la Figura 1. La
primero subzona describe Pruebas de software
Fundamentos. Cubre las definiciones básicas en el campo de pruebas de
software, la terminología básica y las cuestiones clave, y su relación con otras
actividades. El segundo sub-área, Niveles de prueba, consta de dos
(ortogonales) temas: 2.1 enumera los niveles en los que la prueba
5-1
de software de gran tradicionalmente se subdivide; y 2.2 considera prueba para las se plantea). Criterios para hacer frente a la primera pregunta se denominan adecuación
condiciones o propiedades específicas, y se conoce como objetivos de la prueba. No de la prueba criterios, mientras que los relativos a la segunda pregunta son el selección
todos los tipos de pruebas se aplican a todos los productos de software, ni ha sido de prueba criterios. Varios Técnicas de prueba se han desarrollado en las últimas
incluido todos los tipos posibles. décadas, y todavía se están proponiendo nuevas. técnicas generalmente
aceptados están cubiertos en la subzona 3.
El objetivo blanco de prueba y la prueba en conjunto determinan cómo se identifica el
equipo de prueba, tanto en cuanto a su consistencia,
Las medidas relacionadas con la prueba- se tratan en la subzona 4. Por último, en relación con
la cantidad de pruebas es suficiente para lograr el objetivo declarado -y su
cuestiones Proceso de prueba están cubiertos en la zona de sub- 5.
composición- que los casos de prueba deben seleccionarse para lograr el objetivo
establecido ( aunque por lo general el “para alcanzar el objetivo perseguido” parte
queda implícito y sólo la primera parte de las dos preguntas en cursiva
anteriormente

Pruebas de software

Fundamentos de pruebas Técnicas de Medidas de ensayo

Niveles de prueba Proceso de prueba
de software prueba relacionados

Terminología de pruebas El objetivo de la Evaluación de la prueba el Consideraciones

Basada en la intuición y la
relacionados Prueba marco del Programa prácticas
experiencia del Tester

objetivos de
Teclas Problemas La evaluación de las Las actividades de prueba
Pruebas
basada en la especificación pruebas realizadas

Las relaciones de las

pruebas para Otros

Código de base
Ocupaciones

en el uso

por culpa basada

Basado en la naturaleza

de la solicitud

La selección y la
combinación de técnicas

Figura 1 Desglose de los temas para los ensayos KA software.

varios otros. Esta terminología se define precisamente en el estándar IEEE

1. Fundamentos de Software Testing
610.12-1990, Standard Glosario de Terminología Ingeniería de Software
1.1. terminología relacionados con las pruebas (IEEE610-90), y también se discute en la calidad del software KA. Es esencial
distinguir claramente entre el porque de un mal funcionamiento, para los que el
1.1.1. Las definiciones de las pruebas y la terminología relacionada [Bei90: c1;
término culpa o defecto será utilizado aquí, y un efecto no deseado observado
Jor02: c2; Lyu96: c2s2.2] (IEEE610.12-
en servicio entregado del sistema, que se denomina fracaso. Los exámenes
90)
pueden detectar fallos, pero son los fallos que pueden y deben ser
Una introducción completa a la Prueba KA Software se proporciona en las eliminados. Sin embargo, se debe reconocer que la causa de un fallo no
referencias recomendadas. siempre puede ser identificado de forma inequívoca. No existen criterios
1.1.2. Las fallas fallas vs. teóricos para determinar definitivamente qué culpa causó la falla observada.
Podría decirse que era la falla que tuvo que ser modificado para eliminar el
[Jor02: c2; Lyu96: c2s2.2; Per95: C1; Pfl01: c8]
problema, pero otras modificaciones podría haber funcionado igual de bien.
(IEEE610.12-90; IEEE982.1-88)
Para evitar
Muchos términos se utilizan en la literatura de ingeniería de software para describir un mal
funcionamiento, en particular avería, fallo, error, y

5-2 © IEEE - 2004 Versión

ambigüedad, algunos autores prefieren hablar de entradas de fallo causante ( Fra98) en 1.2.7. la capacidad de prueba

lugar de fallos, es decir, aquellos conjuntos de entradas que hacen que aparezca un
[Bei90: c3, c13] (Bac90; Ber96a; Voa95) El término “capacidad de
fracaso.
prueba de software” tiene dos relacionados, pero diferentes, significados: por
1.2. Cuestiones clave una parte, se refiere al grado en el que es fácil para un software para cumplir

1.2.1. criterios de selección de las pruebas / criterios de suficiencia de la prueba (o reglas de una determinado criterio de cobertura de la prueba, como en (Bac90); Por otro

parada) lado, se define como la probabilidad, posiblemente mide estadísticamente, que

el software expondrá una falla bajo prueba, Si es defectuoso, como en (Voa95,
[Pfl01: c8s7.3; Zhu97: S1.1] (Wey83; Wey91; Zhu97) Un criterio de selección
Ber96a). Ambos significados son importantes.
de pruebas es un medio de decidir cuál debería ser un conjunto adecuado de casos de
prueba. Un criterio de selección puede ser utilizado para la selección de los casos de
prueba, o para comprobar si es o no una suite de prueba seleccionado es adecuado, es
1.3. Las relaciones de las pruebas a otras actividades
decir, para decidir si es o no la prueba se puede detener. Véase también el tema sub- Terminación,
bajo el tema 5.1 problemas de gestión. Las pruebas de software se relaciona con, pero diferente de, la gestión de la calidad
del software estática técnicas, pruebas de
corrección, depuración y programación. Sin embargo, es informativa para considerar
1.2.2. Pruebas eficacia / Objetivos para pruebas
la prueba desde el punto de vista de los analistas de la calidad del software y de los
[Bei90: c1s1.4; Per95: c21] (Fra98)
certificadores.
La prueba es la observación de una muestra de ejecuciones del programa.
Probando vs. técnicas estáticas software de gestión de la calidad ver
Selección de la muestra puede ser guiada por diferentes objetivos: es sólo a la
también la calidad del software KA, subárea
luz del objetivo perseguido que la eficacia de la unidad de prueba se puede
2. Procesos de software de gestión de calidad
evaluar.
[Bei90: c1; Per95: c17] (IEEE1008-87) de prueba de exactitud vs.
1.2.3. Las pruebas para la identificación de defectos [Bei90:
Pruebas y verificación formal [Bei90: c1s5; Pfl01: c8]
c1; Kan99: c1]

En las pruebas para la identificación de defectos, una prueba exitosa es una que
Prueba de comparación de depuración. Véase también la construcción del
hace que el sistema fallará. Esto es bastante diferente de las pruebas para
software KA, tema 3.4 Prueba de la construcción
demostrar que el software cumple con su
[Bei90: c1s2.1] (IEEE1008-87) Prueba vs. programación. Véase
especificaciones, u otras propiedades deseadas, en el que las pruebas de caso es
exitoso si no se observan (significativos) fracasos. también la construcción del software KA, tema 3.4 Prueba de la
construcción
1.2.4. El problema oráculo [Bei90: c1]
[Bei90: c1s2.3] Pruebas y Certificación
(Ber96, Wey83)
(Wak99)
Un oráculo es cualquier agente (humano o mecánico) que decide si o no un
programa comportó correctamente en un ensayo dado, y en consecuencia 2. Niveles de prueba
produce un veredicto de “pase” o “fallo”. Existen muchos tipos diferentes de
oráculos, y la automatización de Oracle puede ser muy difícil y costoso. 2.1. El objetivo de la prueba

Las pruebas de software se realiza generalmente a diferentes niveles

a lo largo de los procesos de desarrollo y mantenimiento. Es decir, el objetivo de la
1.2.5. limitaciones teóricas y prácticas de las pruebas de [Kan99: c2]
prueba puede variar: un módulo individual, un grupo de tales módulos
(How76)
(relacionadas por finalidad, uso, comportamiento, o estructura), o un sistema
la teoría de las pruebas advierte contra atribuir un nivel injustificado de confianza
conjunto. [Bei90: c1; Jor02: c13; Pfl01: c8] Tres etapas de prueba puede ser
para serie de pruebas aprobadas. Desafortunadamente, los resultados más
grandes distinguirse conceptualmente, a saber Unidad, Integración y Sistema. Sin
establecidos de la teoría de las pruebas son negativas, ya que afirman que la
modelo de proceso se da a entender, ni son ninguna de esas tres etapas
prueba nunca puede alcanzar a diferencia de lo que realmente logra. La cita más
asumidas para tener mayor importancia que los otros dos.
famoso en este sentido es el aforismo Dijkstra que “las pruebas de programa puede
ser utilizado para mostrar la presencia de insectos, pero nunca para demostrar su
2.1.1. Examen de la unidad
ausencia.” La razón obvia es que la prueba completa no es viable en el software
real. Debido a esto, las pruebas deben ser impulsada en función del riesgo, y puede [Bei90: c1; Per95: c17; Pfl01: c8s7.3] prueba (IEEE1008-87) Unidad
ser visto como una estrategia de gestión de riesgos. verifica el funcionamiento en el aislamiento de piezas de software que son
comprobables por separado. Dependiendo del contexto, estos podrían ser los
diferentes subprogramas, o un componente más grande hecha de unidades

1.2.6. El problema de los caminos factibles [Bei90: fuertemente relacionados. Una unidad de ensayo se define con mayor precisión en
el estándar IEEE para el software de pruebas unitarias (IEEE1008-87), que
c3]
también describe un enfoque integrado de la unidad de pruebas sistemático y
caminos no factibles, las trayectorias de flujo de control que no pueden ser ejercidos por
documentado. Típicamente, la unidad de pruebas se produce con acceso al código
cualquier dato de entrada, son un problema significativo en las pruebas orientado al trayecto,
siendo probado y con el apoyo de
y en particular en la derivación automática de entradas de prueba para técnicas de ensayo
basadas en código.

© IEEE - 2004 Versión 5-3

Herramientas de depuración, y podría involucrar a los programadores que escribieron el código.
2.1.2. Pruebas de integración
[Jor02: c13,14; Pfl01: c8s7.4]
Las pruebas de integración es el proceso de verificar la interacción entre componentes
de software. estrategias de pruebas de integración clásicos, como el de arriba hacia
abajo o de abajo hacia arriba, se utilizan con el software tradicional, jerárquicamente
estructurada. estrategias de integración sistemáticas modernas son bastante
arquitectura dirigida, lo que implica la integración de los componentes de software o
subsistemas en base a las discusiones funcionales identificados. Las pruebas de
integración es una actividad continua, en cada etapa de la que los ingenieros de
software deben abstraer de nivel inferior
Referencias recomendadas para este tema describen el conjunto de objetivos de la
prueba potenciales. Los sub-temas que aparecen a continuación son los más
frecuentemente citado en la literatura. Tenga en cuenta que algunos tipos de pruebas
son más apropiados para los paquetes de software a medida, instalación pruebas, por
ejemplo; y otros para productos genéricos, como beta pruebas.
2.3.1. Aceptación / pruebas de calificación [Per95: c10; Pfl01: c9s8.5]
(IEEE12207.0-96: s5.3.9) Las pruebas de aceptación comprueba el
comportamiento del sistema en contra de los requisitos del cliente, sin embargo,
estos pueden haber sido expresado; los clientes se comprometen, o especificar,
tareas típicas para comprobar que se han cumplido sus requisitos, o que la
organización ha identificado estos para el mercado de destino para el software.
Esta actividad pruebas pueden o no implicar los desarrolladores del sistema.

perspectivas y concentrarse en el
perspectivas del nivel en el que están integrando. A excepción de software
pequeño, simple, pruebas de integración, estrategias incrementales sistemáticas 2.3.2. las pruebas de instalación [Per95: C9;
son generalmente preferidos para poner todos los componentes juntos a la vez, lo
Pfl01: c9s8.6]
que se llama prueba pictóricamente “big bang”.
Por lo general, después de la finalización de las pruebas de software y la aceptación, el
software puede ser verificada después de la instalación en el entorno de destino. las pruebas
2.1.3. Las pruebas del sistema [Jor02: c15;
de instalación se puede ver como las pruebas del sistema llevado a cabo una vez más de
Pfl01: c9] acuerdo con los requisitos de configuración de hardware. Los procedimientos de instalación
también pueden ser verificados.
Las pruebas del sistema tiene que ver con el comportamiento de un sistema en
su conjunto. La mayoría de los fallos funcionales ya debería haber sido
identificado durante unitarias y pruebas de integración. Las pruebas del sistema 2.3.3. Alfa y beta testing [Kan99:
se considera generalmente adecuado para comparar el sistema a los requisitos
c13]
del sistema no funcionales, tales como la seguridad, la velocidad, precisión y
Antes de que se libere el software, se da a veces a un conjunto pequeño,
fiabilidad. Externo
representativo de usuarios potenciales para uso de prueba, ya sea en casa ( alfa la
interfaces con otras aplicaciones,
prueba) o externo ( beta pruebas). Estos usuarios reportan problemas con el
servicios públicos, dispositivos de hardware, o el medio ambiente operativo también se
producto. Alfa y beta uso es a menudo incontrolable, y la prueba no siempre se
evalúan en este nivel. Ver el Software
hace referencia a un plan de pruebas.
KA requisitos para obtener más información sobre los requisitos funcionales y
no funcionales.
2.3.4. Pruebas de conformidad / Pruebas funcionales de pruebas / Corrección
2.2. Objetivos de las Pruebas

2.3. [Per95: c8; Pfl01: c9s8.3]

[Kan99: c7; Per95: c8] (Wak99) Pruebas de conformidad está
La prueba se llevó a cabo a la vista de un objetivo específico, que aparece más o
destinada a validar si o no el comportamiento observado del software probado
menos explícitamente, y con mayor o menor precisión. Indicando el objetivo en
se ajusta a sus especificaciones.
términos precisos, cuantitativos permite el control que se establecerá sobre el
proceso de prueba. La prueba puede ser dirigido a la verificación de diferentes
propiedades. Los casos de prueba pueden ser diseñados para comprobar que las 2.3.5. logro fiabilidad y evaluación [Lyu96: c7; Pfl01: c9s.8.4] (Pos96) para ayudar a

especificaciones funcionales se aplican correctamente, que se refiere de diversas identificar los fallos, la prueba es un medio para mejorar la fiabilidad. Por el

maneras en la literatura como la conformidad
pruebas, exactitud pruebas o funcional pruebas. Sin embargo, varias otras
propiedades no funcionales pueden ser probados, incluyendo el
rendimiento, fiabilidad y facilidad de uso, entre muchos otros.
contrario, mediante la generación al azar casos de prueba de acuerdo con el perfil
operativo, las medidas estadísticas de fiabilidad se pueden derivar. El uso de
modelos de crecimiento fiabilidad, ambos objetivos pueden perseguirse entre sí
(véase también el subtema

4.1.4 prueba de vida, evaluación de la fiabilidad).

Otros objetivos importantes para el ensayo incluyen (pero no se limitan a) la
2.3.6. Pruebas de regresión
seguridad de medición, evaluación de la usabilidad, y la aceptación, para lo cual se
tendrán diferentes enfoques. Tenga en cuenta que el objetivo de la prueba varía [Kan99: c7; Per95: c11, c12; Pfl01: c9s8.1] (Rot96) De acuerdo con

según el destino de la prueba; en general, los propósitos diferentes que se abordarán (IEEE610.12-90), pruebas de regresión es la “repetición de pruebas selectiva de un

en un nivel diferente de la prueba. sistema o componente para verificar que las modificaciones no han causado
efectos no deseados [...]”. En la práctica, la idea es mostrar que el software que
previamente

5-4 © IEEE - 2004 Versión

¿pasaron la? pruebas todavía lo hace. Beizer (Bei90) la define como la repetición de las
pruebas destinadas a demostrar que el comportamiento del software es sin cambios,
excepto la medida en que sea necesario.
Obviamente una compensación debe ser hecha entre la garantía dada por
regresión probando cada vez que se realiza un cambio y los recursos necesarios
para hacerlo.
Las pruebas de regresión puede llevarse a cabo en cada uno de los niveles de ensayo
descritos en el tema 2.1 El objetivo de la prueba, y puede aplicarse a las pruebas
funcionales y no funcionales.
2.3.7. Pruebas de rendimiento
[Per95: c17; Pfl01: c9s8.3] (Wak99)
Esto está específicamente dirigido a verificar que el software cumple con los requisitos
de funcionamiento específicos, por ejemplo, la capacidad y el tiempo de respuesta. Un
tipo específico de pruebas de rendimiento es la prueba de volumen (Per95: p185, p487;
Pfl01: p401), en el que se trataron limitaciones del programa o internos del sistema.
2.3.8. Pruebas de estrés
[Per95: c17; Pfl01: c9s8.3]
Las pruebas de estrés ejerce un software a la carga máxima de diseño, así como más
allá de ella.
2.3.9. Regreso a las pruebas de espalda
Un conjunto de prueba solo se realiza en dos versiones implementadas de un producto
de software, y los resultados se comparan.
2.3.10. las pruebas de recuperación [Per95: c17; Pfl01: c9s8.3] prueba de recuperación está
dirigido a comprobar la capacidad de reinicio de software después de un “desastre”.
2.3.11. pruebas de configuración [Kan99:
c8; Pfl01: c9s8.3]
En los casos donde el software se construye para servir a diferentes usuarios, pruebas
de configuración analiza el software en virtud de las diversas configuraciones
especificadas.
2.3.12. Usabilidad pruebas [Per95: c8;
Pfl01: c9s8.3]
Este proceso evalúa lo fácil que es para los usuarios finales a utilizar y aprender el
software, incluyendo la documentación del usuario, la eficacia con las funciones del
software de apoyo tareas del usuario, y, por último, su capacidad para recuperarse de los
errores del usuario.
2.3.13. desarrollo basado en pruebas [Bec02]
desarrollo basado en pruebas no es una técnica de prueba per se, promoviendo el uso
de pruebas como un sustituto de un documento de especificación de requisitos en lugar
de como un control independiente que
el software ha implementado correctamente los requisitos.
3. Técnicas de Prueba
Uno de los objetivos de la prueba es revelar tanto potencial para el fracaso como
sea posible, y muchos se han desarrollado técnicas para hacer esto, que tratan de
“romper” el programa, mediante la ejecución de una o más pruebas extraídas de las
clases identificadas
© IEEE - 2004 Versión
de ejecuciones considera equivalente. El principio subyacente que conduce tales
técnicas es ser lo más sistemática posible en la identificación de un conjunto
representativo de los comportamientos del programa; por ejemplo, teniendo en
cuenta las subclases del dominio de entrada, los escenarios, los estados, y flujo de
datos. Es difícil encontrar una base homogénea para la clasificación de todas las
técnicas y el utilizado aquí debe ser visto como un compromiso. La clasificación se
basa en cómo las pruebas se generan a partir de la intuición del ingeniero de
software y la experiencia, las especificaciones, la estructura del código, las fallas
(reales o artificiales) a ser descubiertos, el uso de campo, o, por último, la
naturaleza de la aplicación. A veces, estas técnicas se clasifican como caja blanca, también
llamado caja de vidrio, Si las pruebas se basan en la información sobre la forma en
que el software ha sido diseñado o codificado, o como caja negra si los casos de
prueba se basan únicamente en el comportamiento de entrada / salida. Una última
categoría se refiere a su uso combinado de dos o más técnicas. Obviamente, estas
técnicas no se utilizan con la misma frecuencia por todos los practicantes. Incluido
en la lista son los que un ingeniero de software debe saber.
3.1. Sobre la base de la intuición y la experiencia del ingeniero de software
3.1.1. las pruebas ad hoc
[Kan99: c1]
Quizás la técnica más ampliamente practicado la prueba sigue siendo especial:
las pruebas se derivan confiar en el ingeniero de software de habilidad, intuición y
experiencia con programas similares. pruebas Ad hoc podría ser útil para la
identificación de pruebas especiales, aquellos que no capturado fácilmente por
técnicas formalizados.
3.1.2. Prueba exploratoria
pruebas exploratorias se define como aprendizaje simultáneo, diseño de la prueba,
y la ejecución de la prueba; es decir, las pruebas no se definen por adelantado en
un plan de pruebas establecido, pero están diseñados de forma dinámica,
ejecutados, y modificados. La eficacia de pruebas exploratorias se basa en el
conocimiento de los ingenieros de software, que se puede derivar de varias
fuentes: el comportamiento del producto observada durante la prueba, la
familiaridad con la aplicación, la plataforma, el proceso falla, el tipo de posibles
fallos y fracasos, el riesgo asociado un producto en particular, y así sucesivamente.
[Kan01: c3]
3.2. las técnicas basadas en la especificación
3.2.1. Equivalencia de partición [Jor02:
c7; Kan99: c7]
El dominio de entrada se subdivide en una colección de subconjuntos, o clases
equivalentes, que se consideran equivalentes de acuerdo con una relación
especificada, y un conjunto representativo de pruebas (a veces sólo uno) se toma
de cada clase.
3.2.2. análisis de Límites-valor [Jor02:
C6; Kan99: c7]
Los casos de prueba se eligen en y cerca de los límites del dominio de las
variables de entrada, con la lógica subyacente que muchos defectos tienden a
concentrarse cerca de los valores extremos
5-5
de los insumos. Una extensión de esta técnica es comprobación de la solidez, en el que las variables se definen, utilizados, y mataron (indefinido). El criterio más fuerte,
los casos de prueba se eligen también fuera del dominio de entrada de variables, todos los caminos definición de uso, requiere que, para cada variable, se ejecuta
para poner a prueba la robustez programa para cada segmento de trayectoria de flujo de control de una definición de esa variable a
entradas inesperadas o erróneos. un uso de esa definición. Con el fin de reducir el número de caminos necesarios,
se emplean estrategias más débiles tales como todo-definiciones y todos los usos.
3.2.3. Tabla de decisiones [Bei90:

c10s3] (Jor02)

Las tablas de decisión representan las relaciones lógicas entre las condiciones
3.3.3. modelos de referencia para basado en el código pruebas
(aproximadamente, insumos) y acciones (aproximadamente, salidas). Los casos de prueba
(Flowgraph, gráfico de llamadas)
se derivan sistemáticamente por teniendo en cuenta todas las combinaciones posibles de
[Bei90: c3; Jor02: c5].
las condiciones y acciones. A técnicas relacionadas es causa-efecto gráfica. [ Pfl01: c9]
Aunque no es una técnica en sí misma, la estructura de control de un programa se
representa gráficamente utilizando un flowgraph en técnicas de ensayo basadas en
3.2.4. De estado finito de máquina basado [Bei90:
código. A flowgraph es un gráfico dirigido los nodos y arcos de los cuales
c11; Jor02: c8]
corresponden a los elementos de programa. Por ejemplo, los nodos pueden
Al modelar un programa como una máquina de estados finitos, las pruebas pueden ser representar declaraciones o secuencias ininterrumpidas de estados, y los arcos de la
seleccionados con el fin de cubrir los estados y las transiciones en él. transferencia de control entre los nodos.

3.2.5. Pruebas de las especificaciones formales [Zhu97:

3.4. Las técnicas basadas en fallo
S2.2] (Ber91; Dic93; Hor95)
3.5. (Mor90)
Dando las especificaciones en un lenguaje formal permite la derivación automática de
casos de prueba funcionales, y, al mismo tiempo, proporciona una salida de Con diferentes grados de formalización, técnicas de ensayo basado en fallo diseñar
referencia, un oráculo, para la comprobación de los resultados de pruebas. Existen casos de prueba destinados específicamente a revelar categorías de fallos probables
métodos para derivar casos de prueba de modelo basado en (Dic93, Hor95) o de las o predefinidas.
especificaciones algebraicas. (Ber91)
3.5.1. Error adivinar

3.2.6. Las pruebas al azar [Bei90: c13;
Kan99: c7]
Las pruebas se generan puramente al azar, que no debe confundirse con la prueba
estadística del perfil operativo como se describe en sub-tema 3.5.1 perfil operativo. Esta
forma de pruebas se encuentra bajo el título de la entrada basada en la
especificación, ya que al menos debe ser conocido el dominio de entrada, para ser
capaz de recoger puntos al azar dentro de ella.
3.3. técnicas basadas en código
[Kan99: c7]
En adivinar de error, los casos de prueba están diseñados específicamente por los
ingenieros de software tratando de averiguar los fallos más plausibles en un programa
dado. Una buena fuente de información es la historia de los fallos detectados en los
proyectos anteriores, así como la experiencia del ingeniero de software.
3.5.2. Mutación pruebas [Per95: c17; Zhu97: S3.2-S3.3] A mutante es una versión
ligeramente modificada del programa bajo prueba, que difiere de ella por un cambio
pequeño, sintáctica. Cada caso de prueba ejerce mutantes tanto el original y todas
generadas: si un caso de prueba tiene éxito en la identificación de la diferencia entre

3.3.1. criterios basados ​en el flujo de control [Bei90: C3; el programa y un mutante, se dice que este último sea “muerto”. Originalmente
concebido como una técnica para evaluar un conjunto de prueba (véase 4.2), las
Jor02: c10] (Zhu97)
pruebas de mutación es también un criterio de prueba en sí mismo: o bien pruebas
criterios de cobertura basada en el control de flujo está destinada a cubrir todas las se generan aleatoriamente hasta que suficientes mutantes han muerto, o pruebas
declaraciones o bloques de instrucciones en un programa, o combinaciones de ellos están diseñadas específicamente para matar mutantes supervivientes. En este
especifica. Se han propuesto varios criterios de cobertura, como la cobertura de decisión último caso, las pruebas de mutación también puede ser categorizado como una
/ condición. El más fuerte de los criterios basados ​en el flujo de control es la prueba de
técnica basada en el código. El supuesto subyacente de pruebas de mutación, el
ruta, cuyo objetivo es ejecutar todas las trayectorias de flujo de control de entrada-salida
efecto de acoplamiento, es que, mediante la búsqueda de fallos sintácticos simples,
a la flowgraph. Dado que las pruebas de ruta generalmente no es factible debido a los
faltas más complejos, pero los reales, serán encontrados. Para que la técnica sea
bucles, otros criterios menos estrictos, tienden a ser utilizados en la práctica, tales como
eficaz, un gran número de mutantes debe derivarse de forma automática de una
pruebas de requisitos, pruebas rama, y ​la condición / pruebas de decisión. La
manera sistemática.
adecuación de estas pruebas se mide en porcentajes; por ejemplo, cuando todas las
ramas se han ejecutado al menos una vez por las pruebas, se dice que ha sido
alcanzado el 100% de cobertura de rama.

3.3.2. criterios basados ​en el flujo de datos [Bei90:

c5] (Jor02; Zhu97)

En las pruebas basadas en el flujo de datos, el control de flowgraph está

anotado con información acerca de cómo el programa

5-6 © IEEE - 2004 Versión

3.6. técnicas basadas en el uso
3.6.1. perfil operativo
[Jor02: c15; Lyu96: c5; Pfl01: c9]
En las pruebas para la evaluación de la fiabilidad, el entorno de prueba debe
reproducir el entorno operativo del software lo más cerca posible. La idea es
inferir, a partir de los resultados de las pruebas observadas, el futuro
fiabilidad del software cuando está en uso real. Para ello, las entradas se les
asigna una distribución de probabilidad, o perfil, de acuerdo con su aparición
en la operación real.
3.6.2. Software de Pruebas de confiabilidad Engineered [Lyu96: c6]
Software Fiabilidad Engineered Testing (SRET) es un método de prueba
que abarca todo el proceso de desarrollo, por lo que la prueba está
“diseñado y guiado por objetivos de fiabilidad y espera uso relativo y
criticidad de funciones diferentes en el campo.”
3.7. Las técnicas basadas en la naturaleza de la aplicación
Las técnicas anteriores se aplican a todo tipo de software. Sin embargo, para algunos
tipos de aplicaciones, se requiere algún conocimiento adicional para la derivación de
prueba. Se proporciona una lista de algunos campos de prueba especializados aquí,
en base a la naturaleza de la aplicación que se está probando:
Orientado a objetos de prueba [Jor02: c17; Pfl01: c8s7.5] (Bin00)
las pruebas de las pruebas basadas en
Web pruebas de interfaz gráfica de usuario
basada en componentes [Jor20]
Las pruebas de los programas concurrentes (Car91) las pruebas de
conformidad de protocolo (Pos96; Boc94) las pruebas de sistemas de tiempo
real (Sch94) las pruebas de los sistemas de seguridad crítica (IEEE1228-94)
3.8. Seleccionando y combinando técnicas
3.8.1. Funcional y estructural
[Bei90: c1s.2.2; Jor02: c2, c9, c12; Per95: c17] (Pos96)
técnicas de ensayo basadas en código basado en la memoria descriptiva y se
contrastan a menudo como funcional vs. pruebas estructurales. Estos dos enfoques
para prueba de selección no deben ser vistos como alternativa, sino más bien como
complementaria; de hecho, se utilizan diferentes fuentes de información, y han
demostrado para resaltar diferentes tipos de problemas. Pueden ser utilizados en
combinación, dependiendo de consideraciones presupuestarias.
3.8.2. Determinista vs. aleatorio (Ham92;
Lyu96: p541-547)
Los casos de prueba pueden seleccionarse de una manera determinista, de
acuerdo con una de las diversas técnicas de la lista, o al azar extraídas de alguna
distribución de insumos, tal como se suele hacer en las pruebas de fiabilidad.
Varios analítica y empírica
© IEEE - 2004 Versión
comparaciones se han llevado a cabo para analizar las condiciones que hacen
que un enfoque más eficaz que el otro.
4. Medidas relacionadas con Test-
A veces, prueba técnicas se confunden con la prueba
objetivos. técnicas de prueba deben ser vistos como auxiliares que ayudan a
asegurar el logro de los objetivos de la prueba. Por ejemplo, la cobertura de la
rama es una técnica popular prueba. El logro de una medida de cobertura de
sucursales especificado no debe ser considerado como el objetivo de la prueba
per se: es un medio para mejorar las posibilidades de encontrar fallos mediante
el ejercicio de forma sistemática todas las ramas del programa fuera de un punto
de decisión. Para evitar este tipo de malentendidos, una clara distinción debe
hacerse entre las medidas relacionadas con la prueba-, que proporcionan una
evaluación del programa que se está probando en base a las salidas de prueba
observadas, y los que evalúan la minuciosidad de la prueba. información
adicional sobre los programas de medición se proporciona en la Ingeniería de
Software de Gestión de KA, subzona 6.
Software Ingeniería de medición. Adicional
información sobre las medidas se puede encontrar en el Proceso de Ingeniería
de Software KA, subzona 4. Proceso y medición del producto.
La medición se considera generalmente como fundamental para el análisis de
calidad. La medición también se puede utilizar para optimizar la planificación y
ejecución de las pruebas. Gestión de pruebas puede utilizar varias medidas de
proceso para monitorear el progreso. Medidas relativas al proceso de prueba a
efectos de gestión se consideran
en tema 5.1 Práctico
Consideraciones.
4.1. La evaluación del programa bajo prueba (IEEE982.1-
98)
4.1.1. mediciones programa de ayuda en la planificación y el diseño de las
pruebas
[Bei90: c7s4.2; Jor02: c9] (Ber96; IEEE982.1-88) Las medidas basadas en el
tamaño del programa (por ejemplo, líneas de código fuente o de función puntos) o en la
estructura del programa (como complejidad) se utilizan para guiar las pruebas. Las
medidas estructurales también pueden incluir mediciones entre los módulos de
programa, en términos de la frecuencia con la que los módulos se llaman entre sí.
4.1.2. Avería tipos, clasificación y estadísticas [Bei90: c2; Jor02: c2; Pfl01:
c8] (Bei90; IEEE1044-93; Kan99; Lyu96) La literatura de pruebas es
rica en clasificaciones y taxonomías de fallos. Para que el análisis sea
más eficaz, es importante saber qué tipos de fallos se podrían encontrar
en el software bajo prueba, y la frecuencia relativa con la que se han
producido estos fallos en el pasado. Esta información puede ser muy
útil
en la fabricación de la calidad
predicciones, así como para la mejora de procesos. Más información se
puede encontrar en la calidad del software KA, tema
3.2 Caracterización de defectos. existe un estándar IEEE sobre cómo clasificar las
“anomalías” de software (IEEE1044-93).
5-7
4.1.3. densidad de culpa
[Per95: c20] (IEEE982.1-88; Lyu96: c9) Un programa bajo prueba se
puede evaluar mediante el recuento y la clasificación de los fallos descubiertos
por sus tipos. Para cada clase de fallo, la densidad de fallo se mide como la
basado. Algunos también argumentan que esta técnica se debe utilizar con mucho
cuidado, ya que la inserción de fallos en el software implica el riesgo evidente de
dejarlos allí.
4.2.3. puntuación de mutaciones [Zhu97:

relación entre el número de fallos encontrados y el tamaño del programa. S3.2 S3.3-]

En las pruebas de mutación (ver sub-tema 3.4.2), la proporción de mutantes matado

4.1.4. prueba de vida, evaluación fiabilidad [Pfl01: para el número total de mutantes generados puede ser una medida de la eficacia del
equipo de prueba ejecutado.
c9] (Pos96: p146-154)
4.2.4. Comparación y la eficacia relativa de las diferentes técnicas
Una estimación estadística de la fiabilidad del software, que puede ser
obtenido por el logro fiabilidad y evaluación (ver subtema 2.2.5), se puede
utilizar para evaluar un producto y decidir si es o no la prueba se puede [Jor02: c9, c12; Per95: c17; Zhu97: s5] (Fra93; Fra98; Pos96:
detener.
p64-72)
4.1.5. modelos de crecimiento Fiabilidad [Lyu96: C7; Pfl01:
Se han realizado varios estudios para comparar la eficacia relativa de las
c9] (Lyu96: c3, c4) diferentes técnicas de prueba. Es importante ser preciso en cuanto a la
propiedad contra la cual se están evaluando las técnicas; lo que, por ejemplo,
modelos de crecimiento Fiabilidad proporcionan una predicción de fiabilidad
es el significado exacto dado al término “eficacia”? Interpretaciones posibles
basado en los fallos observados bajo confiabilidad
son: el número de pruebas necesarias para encontrar el primer fracaso, la
logros y evaluación (ver subtema 2.2.5). Ellos asumen, en general, que las fallas
proporción entre el número de defectos encontrados a través de pruebas de
que causaron las fallas observadas se han fijado (aunque algunos modelos
todos los defectos encontrados durante y después de la prueba, o cuánto se
también aceptan correcciones imperfectas), y por lo tanto, en promedio, la
ha mejorado la fiabilidad. comparaciones analíticas y empíricas entre
fiabilidad del producto muestra una tendencia creciente. Ahora existen decenas
diferentes técnicas se han llevado a cabo de acuerdo con cada una de las
de modelos publicados. Muchos están establecidas en algunos supuestos
nociones de eficacia especificados anteriormente.
comunes, mientras que otros son distintos. En particular, estos modelos se
dividen en el fracaso de conteo y fracaso en el intervalo entre- modelos.

Proceso 5. Prueba
4.2. La evaluación de las pruebas realizadas
Conceptos de pruebas, estrategias, técnicas y medidas deben integrarse en un proceso
4.2.1. medidas de cobertura / exhaustividad [Jor02: C9;
definido y controlado que está dirigido por la gente. El proceso de prueba es compatible
Pfl01: c8] (IEEE982.1-88) con las actividades de ensayo y proporciona orientación a los equipos de prueba, desde la
planificación de prueba para probar la evaluación de salida, de tal manera que
Varios criterios de suficiencia de prueba requieren que los casos de prueba
proporcionen una seguridad justificada de que los objetivos de la prueba se cumplirán
ejercen sistemáticamente un conjunto de elementos identificados en el programa
costo-eficacia.
o en las especificaciones (véase la sub-zona 3). Para evaluar la rigurosidad de
las pruebas ejecutadas, los probadores pueden controlar los elementos
cubiertos, por lo que pueden medir de forma dinámica la relación entre los 5.1. Consideraciones prácticas
elementos cubiertos y su número total. Por ejemplo, es posible medir el
5.1.1. Actitudes / programación sin ego [Bei90: c13s3.2; Pfl01: c8] Un componente
porcentaje de ramas cubiertas de la flowgraph programa, o la de los requisitos
muy importante de la prueba con éxito es una actitud de colaboración hacia las
funcionales ejercidas entre los enumerados en el documento de especificaciones.
actividades de prueba y garantía de calidad. Los gerentes tienen un papel clave en
criterios de adecuación basados ​en códigos requieren instrumentación apropiada
la promoción de una recepción favorable en general hacia el descubrimiento falla
del programa que se está probando.
durante el desarrollo y mantenimiento; por ejemplo, mediante la prevención de un
modo de pensar de la propiedad entre los programadores de código, de modo que
no se sentirá responsable de los fallos revelados por su código.
4.2.2. la siembra de fallos

[Pfl01: c8] (Zhu97: S3.1)

Algunos fallos son introducidos artificialmente en el programa antes de la

prueba. Cuando se ejecutan las pruebas, algunos de estos fallos sin semillas
será revelado, y posiblemente algunos fallos que eran ya habrá también. En
teoría, dependiendo de cuál de los defectos artificiales se descubrió, y
cuántos, poniendo a prueba la eficacia puede ser evaluado, y el número
restante de fallos genuinos puede ser estimado. En la práctica, los
estadísticos cuestionan la distribución y representatividad de fallos sembradas
en relación con fallos genuinos y el pequeño tamaño de la muestra en la que
cualquier extrapolaciones son
5.1.2. guías de prueba
[Kan01]
Las fases de prueba podrían ser guiadas por diversos objetivos, por ejemplo: en la prueba
basada en el riesgo, que utiliza los riesgos de los productos para priorizar y enfocar la estrategia
de prueba; o en pruebas basadas en el escenario, en el cual los casos de prueba se definen
basándose en escenarios de software específicas.

5-8 © IEEE - 2004 Versión

5.1.3. gestión de procesos de prueba
[Bec02: III; Per95: C1-C4; Pfl01: c9] (IEEE1074: 97; IEEE12207.0-96:
s5.3.9, s5.4.2, s6.4, S6.5) actividades de prueba llevados a cabo en diferentes
niveles (ver sub-área 2.
Niveles de prueba) deben organizarse, junto con las personas, herramientas,
políticas y medidas, en un proceso bien definido que es una parte integral del
ciclo de vida. En IEEE estándar EIA / 12207.0, las pruebas no se describe como
un proceso autónomo, pero los principios de las actividades de prueba se
incluyen junto con los dos de los cinco procesos del ciclo de vida primarios y
apoyar el proceso. En IEEE Std 1074, las pruebas se agrupa con otras
actividades de evaluación como parte integral de todo el ciclo de vida.
5.1.4. Prueba documentación y trabajo productos
[Bei90: c13s5; Kan99: c12; Per95: c19; Pfl01: c9s8.8]
(IEEE829-98)
La documentación es una parte integral de la formalización del proceso de prueba. El
estándar IEEE para la Documentación de software de prueba (IEEE829-98) proporciona
una buena descripción de documentos de prueba y de su relación con los otros y con el
proceso de prueba. documentos de prueba pueden incluir, entre otros, plan de pruebas,
la prueba Especificaciones de Diseño, Especificación de Procedimiento de prueba,
casos de prueba de especificación, registro de la prueba, y la prueba de incidente o
problema de informe. El software bajo prueba está documentado como el artículo de
prueba. la documentación de prueba debe ser producido y continuamente actualizada,
para el mismo nivel de calidad que los demás tipos de documentación en la ingeniería
de software.
5.1.5. contra equipo de prueba interna independiente [Bei90: c13s2.2-c13s2.3;
Kan99: c15; Per95: C4; Pfl01: c9]
Formalización del proceso de prueba puede implicar la formalización de la organización
del equipo de pruebas también. El equipo de pruebas puede estar compuesto por
miembros internos (es decir, en el equipo del proyecto, que participan o no en la
construcción de software), por miembros externos,
con la esperanza de traer una perspectiva imparcial,
independiente, o, por último, de los dos miembros internos y externos. Las
consideraciones de costos, horarios, niveles de madurez de las
organizaciones involucradas, y la criticidad de la aplicación pueden
determinar la decisión.
5.1.6. Costo / estimación de esfuerzo y otras medidas de proceso [Per95: C4,
C21] (Per95: Apéndice B; Pos96: p139- 145; IEEE982.1-88)
Una serie de medidas relacionadas con los recursos gastados en las pruebas, así como a
la relativa eficacia de búsqueda de errores de las diversas fases de prueba, son utilizados
por los administradores para controlar y mejorar el proceso de prueba. Estas medidas de
prueba pueden cubrir aspectos tales como: número de casos de prueba especificados, el
número de casos de prueba ejecutados, el número de casos de prueba pasó, y el número
de casos de prueba falló, entre otros.
Evaluación de los informes de fase de prueba se puede combinar con el análisis de causa
raíz para evaluar la efectividad del proceso de prueba en la búsqueda de fallos tan pronto
como sea posible. Tal evaluación podría
© IEEE - 2004 Versión
estar asociado con el análisis de riesgos. Por otra parte, los recursos que
merece la pena el gasto en las pruebas deben ser acordes con el uso /
criticidad de la aplicación: diferentes técnicas tienen diferentes costos, y
producen diferentes niveles de confianza en la fiabilidad del producto.
5.1.7. Terminación [Bei90: c2s2.4;
Per95: C2]
Una decisión debe ser hecha en cuanto a la cantidad de pruebas es suficiente y
cuando una etapa de prueba puede ser terminado. Minuciosidad medidas, tales como
la cobertura de código alcanzado o integridad funcional, así como estimaciones de la
densidad de culpa o de seguridad de funcionamiento, proporcionan un apoyo útil,
pero no son suficientes por sí solas. La decisión también implica consideraciones
sobre los costes y los riesgos incurridos por el potencial de fallos restantes, en
contraposición a los costos que implica al continuar la prueba. Ver también subtema
1.2.1 criterios de selección de las pruebas / criterios de suficiencia de la prueba.
5.1.8. patrones de reutilización de prueba y prueba
[Bei90: c13s5]
Para llevar a cabo pruebas o mantenimiento en un costo manera organizada y /
efectiva, los medios utilizados para probar cada parte del software deben ser
reutilizados de forma sistemática. Este repositorio de materiales de prueba debe
estar bajo el control de la gestión de configuración de software, de modo que los
cambios en los requisitos de software o el diseño se pueden reflejar en cambios en el
alcance de las pruebas realizadas.
Las soluciones de ensayo adoptadas para probar algunos tipos de aplicaciones, en
determinadas circunstancias, con las motivaciones detrás de las decisiones tomadas, forman
un patrón de prueba que también podrá ser documentados para su posterior reutilización en
proyectos similares.
5.2. Las actividades de prueba
Bajo este tema, se da una breve descripción de las actividades de prueba; tan a
menudo implica la siguiente descripción, manejo exitoso de las actividades de
prueba depende en gran medida del proceso de Gestión de la Configuración de
Software.
5.2.1. Planificación
[Kan99: c12; Per95: c19; Pfl01: c8s7.6] (IEEE82998: S4; IEEE1008-87:
S1-S3) Al igual que cualquier otro aspecto de la gestión de proyectos, actividades de
prueba debe ser planeado. Los aspectos clave de la planificación de pruebas incluyen
la coordinación del personal, la gestión de instalaciones de prueba disponibles y el
equipo (que puede incluir medios magnéticos, planes de pruebas y procedimientos), y
la planificación de los posibles resultados indeseables. Si se mantiene más de una
línea de base del software, a continuación, una consideración importante es la
planificación del tiempo y el esfuerzo necesarios para garantizar que el entorno de
prueba se establece en la configuración adecuada.
5.2.2. Test-caso de la generación [Kan99: c7] (Pos96: c2; IEEE1008-87: s4,
s5) Generación de casos de prueba se basa en el nivel de pruebas a
realizar, y las técnicas de ensayo particulares. Prueba
5-9
casos deben estar bajo el control de la gestión de configuración de software e
incluir los resultados esperados para cada prueba.
5.2.3. el desarrollo de medio ambiente [Kan99:
c11]
El entorno utilizado para la prueba debe ser compatible con las herramientas de
ingeniería de software. Se debe facilitar el desarrollo y control de casos de
prueba, así como el registro y la recuperación de los resultados esperados,
guiones y otros materiales de prueba.
5.2.4. Ejecución
[Bei90: c13; Kan99: c11] (IEEE1008-87: S6, S7) Ejecución de
pruebas debe incorporar un principio básico de la experimentación científica:
todo lo realizado durante la prueba se debe realizar y documentar con
suficiente claridad que otra persona pueda replicar los resultados. Por lo tanto,
las pruebas deben realizarse de acuerdo con los procedimientos
documentados usando una versión claramente definida del software bajo
prueba.
5.2.5. Evaluación resultados de las pruebas
[Per95: c20, c21] (Pos96: p18-20, p131-138) Los resultados del
ensayo debe ser evaluado para determinar si o no la prueba ha tenido
éxito. En la mayoría de los casos, 'exitoso' significa que
el software realiza como
era de esperar, y no tenía ningún principales resultados inesperados. No todos los
resultados inesperados son necesariamente los fallos, sin embargo, pero podrían
ser juzgados a ser simplemente ruido. Antes de que un fallo se puede quitar, es
necesario un esfuerzo de análisis y depuración de aislar, identificar y describir.
Cuando
5-10
resultados de las pruebas son particularmente importantes, una junta de revisión formal
puede ser convocado para evaluarlas.
5.2.6. Problema de registro de informes / Test [Kan99: c5; Per95: c20] (IEEE829-98:
S9-S10) Las actividades de prueba se pueden introducir en un registro de prueba para
identificar cuándo se llevó a cabo una prueba, que se realiza el examen, lo que la
configuración del software fue la base para la prueba, y otra información de identificación
correspondiente. resultados de prueba inesperados o incorrectos pueden ser grabados
en un sistema de información problema, los datos de los cuales forman la base para la
depuración más tarde y para la fijación de los problemas que se observaron como fallas
durante la prueba. Además, las anomalías no clasificados como fallos podrían ser
documentados en caso de que más tarde resultan ser más grave de lo previsto
inicialmente. Los informes de prueba son también una contribución al proceso de
solicitud de Gestión del Cambio (véase el Software Configuration Management KA,
subzona 3. Configuración del software de control).
5.2.7. seguimiento de defectos
[Kan99: c6]
Las fallas observadas durante las pruebas son más a menudo debido a
fallos o defectos en el software. Tales defectos pueden ser analizados
para determinar cuando se introdujeron en el software, ¿qué tipo de error
causado a crearse (requisitos mal definidos,
incorrecta declaración de variables,
pérdida de memoria, error de sintaxis de programación, por ejemplo), y cuando
podían haber sido observada por primera vez en el software. información de
seguimiento de defectos se utiliza para determinar qué aspectos de la ingeniería de
software necesitan mejora y la eficacia de los análisis y las pruebas anteriores han
sido.
© IEEE - 2004 Versión
 METRO ATRIX DE T OPICS VS. R EFERENCIA METRO ATERIAL

[Bec02] [Bei90] [Jor02] [Kan99 [Kan01] [Lyu96] [Per95] [Pfl01] [Zhu97]

1. Fundamentos de
Software Testing

5.3. Terminología relacionados con

las pruebas

Las definiciones de las pruebas y la

c1 c2 c2s2.2
terminología relacionada

Las fallas fallas vs. c2 c2s2.2 c1 c8

5.4. Cuestiones clave

criterios de selección de las pruebas / criterios de

suficiencia de la prueba (o reglas de parada) c8s7.3 S1.1

Pruebas
eficacia / Objetivos de la prueba c1s1.4 c21

Las pruebas para la identificación de defectos c1 c1

El problema de Oracle c1
limitaciones teóricas y prácticas
c2
de las pruebas
El problema de los caminos factibles c3
la capacidad de prueba C3, C13

5.5. Las relaciones de las pruebas para otras

actividades
Prueba de técnicas de análisis
c1 c17
estático vs.
Las pruebas de exactitud frente a pruebas y
c1s5 c8
verificación formal

Prueba de depuración vs. c1s2.1

Las pruebas contra Programación c1s2.3
Pruebas y Certificación

2. Niveles de prueba

5.6. El objetivo de las pruebas c1 c13 c8

Examen de la unidad c1 c17 c8s7.3

Pruebas de integración c13, c14 c8s7.4
Las pruebas del sistema c15 C9

5.7. Objetivos de las Pruebas c8 c9s8.3

Aceptación / pruebas de calificación c10 c9s8.5

las pruebas de instalación C9 c9s8.6
Alfa y Beta de pruebas c13
Pruebas de conformidad / Pruebas funcionales
de pruebas / Corrección c7 c8

logro fiabilidad y la evaluación

c7 c9s8.4
mediante pruebas
Pruebas de regresión c7 c11, c12 c9s8.1
Pruebas de rendimiento c17 c9s8.3
Pruebas de estrés c17 c9s8.3
De nuevo-nuevo la prueba prueba

de recuperación c17 c9s8.3

pruebas de configuración c8 c9s8.3
Las pruebas de usabilidad c8 c9s8.3
desarrollo basado en pruebas III

© IEEE - 2004 Versión 5-11

 [Bec02] [Bei90] [Jor02] [Kan99] [Kan01] [Lyu96] [Per95] [Pfl01] [Zhu97]

3. Técnicas de Prueba

5.8. Basada en la intuición y la experiencia

del Tester
las pruebas ad hoc c1
Prueba exploratoria c3

5.9. basada en la especificación

Partición de equivalencia c7 c7
análisis de Límites-valor c6 c7
tabla de decisiones c10s3 C9
basada en la máquina de estados finitos c11 c8
Pruebas de las especificaciones formales S2.2
Las pruebas al azar c13 c7

5.10. Código de base

criterios basados ​en el flujo de control c3 c10 c8
criterios basados ​en el flujo de datos c5
modelos de referencia para las pruebas basadas en
c3 c5
código

5.11. basada en la culpa

error de adivinanzas c7
Las pruebas de mutación c17 S3.2, S3.3

5.12. basada en el uso

perfil operativo c15 c5 C9
Software de Pruebas de confiabilidad Engineered
c6

5.13. Basado en la naturaleza de la

solicitud
prueba orientada a objetos c17 c8s7.5
Pruebas Pruebas Pruebas interfaz gráfica de

usuario basada en web basado en

componentes c20
Las pruebas de los programas concurrentes pruebas

de conformidad de protocolo de pruebas de los

sistemas de distribución de pruebas de sistemas de

tiempo real

5.14. La selección y la combinación de

técnicas
Funcional y estructural c1s2.2 c1, c11s11.3 c17
Determinista vs aleatoria

5-12 © IEEE - 2004 Versión

 [Bec02] [Bei90] [Jor02] [Kan99 [Kan01] [Lyu96] [Per95] [Pfl01] [Zhu97]

4. Medidas de ensayo relacionados

5.15. Evaluación del Programa bajo

prueba
mediciones programa de ayuda en la
c7s4.2 C9
planificación y diseño de la prueba.
Tipos, clasificación y estadísticas de averías
c2 c1 c8

densidad de culpa c20

prueba de vida, evaluación de la fiabilidad C9

modelos de crecimiento fiabilidad c7 C9

5.16. La evaluación de las pruebas

realizadas
Cobertura / medidas rigurosidad C9 c8
la siembra de fallos c8
puntuación de mutaciones S3.2, S3.3
Comparación y relativa
c8, c11 c17 s5
efectividad de diferentes técnicas

Proceso 5. Prueba

5.17. Consideraciones prácticas

Actitudes / programación sin ego c13s3.2 c8
guías de prueba III C5
gestión de procesos de prueba C1-C4 C9

la documentación de prueba y productos de

c13s5 c12 c19 c9s8.8
trabajo

c13s2.2,
frente interno equipo de pruebas independiente c15 c4 C9
c1s2.3
Costo / estimación de esfuerzo y otras medidas
C4, C21
de proceso

Terminación c2s2.4 c2
reutilización de prueba y patrones de prueba c13s5

5.18. Las actividades de prueba

Planificación c12 c19 c87s7.6

generación de casos de prueba c7
desarrollo entorno de prueba c11
Ejecución c13 c11
Evaluación resultados de las pruebas c20, c21
informe de problemas de registro / prueba c5 c20
seguimiento de defectos c6

© IEEE - 2004 Versión 5-13

 Aprendido en Pruebas de Software: Wiley Publishing ordenador,
R ECOMMENDED R EFERENCIAS PARA S OFTWARE T PRUEB 2001.

[Lyu96] MR Lyu, "Manual de Ingeniería de Software Fiabilidad," Mc

[Bec02] K. Beck, "Desarrollo basado en pruebas por
Graw-Hill-/ IEEE, 1996, Cap. 2s2.2, 5-
Ejemplo ", Addison-Wesley, 2002.
7.
[Bei90] B. Beizer, "Técnicas de pruebas de software," Internacional
[Per95] W. Perry, "Métodos eficaces para las pruebas de software",
Thomson Press, 1990, cap. 1-3, 5, 7s4, 10s3, 11, 13.
Wiley, 1995, Cap. 1-4, 9, 10-12, 17, 19-21. [Pfl01] SL Pfleeger,
"Ingeniería de Software: Teoría y Práctica", Segunda ed: Prentice-Hall,
[Jor02] PC Jorgensen, "Pruebas de Software: El enfoque de un artesano,"
2001, Cap. 8, 9. [Zhu97] H. Zhu, PAV Hall y JHR mayo, "Unidad de
Segunda edición, CRC Press, 2004, Cap. 2, 5-
10, 12-15, 17, 20. Software Cobertura de la prueba y suficiencia" ACM Computing Surveys, vol.
29, ISS. 4, 366-427 (secciones 1,
[Kan99] C. Kaner, J. Falk y HQ Nguyen, "Testing Software de
ordenador," Segunda ed: Wiley, 1999, Cap. 1, 2, 5-8, 11-13, 15.
2.2, 3.2, 3.3), de diciembre de 1997

[Kan01] C. Kaner, J. Bach y B. Pettichord, lecciones

5-14 © IEEE - 2004 Versión


UN PÉNDICE A. L LISTA DE F ás R EADINGS
(Bac90) R. Bache y M. Müllerburg, "Medidas la capacidad de prueba como
base para la Garantía de Calidad," Software Engineering Journal, vol. 5,
86-92, marzo de 1990 (Bei90) B. Beizer, "Técnicas de pruebas de software,"
Segunda ed: International Thomson Press, 1990. (Ber91) G. Bernot, MC
Gaudel y B. Marre, "Pruebas de software basados ​en Las especificaciones
formales: una teoría y una herramienta ", Software Engineering Journal, 387-405,
noviembre de 1991
(Ber96) A. y M. Bertolino Marre: "¿Cuántos caminos son necesarios para
las pruebas rama ?," El Diario de sistemas y software, vol. 35, ISS. 2,
95-106, 1996
(Ber96a) A. Bertolino y L. Strigini, "Sobre el uso de las medidas de la
capacidad de prueba para la evaluación de la fiabilidad,"
IEEE Transactions on Software Engineering, vol. 22, ISS.
2, 97-108, de febrero de 1996 (Bin00) RV Binder, Prueba de modelos
orientados a objetos de sistemas, modelos y herramientas: Addison-Wesley,
2000. (Boc94) GV Bochmann y A. Petrenko, "Protocolo de prueba: Examen de
los métodos y relevancia para las pruebas de software", presentados en ACM
Proc. En t. Simposio sobre Sw de ensayos y análisis (Issta' 94), Seattle,
Washington, EE.UU., 1994
(Car91) RH Carver y KC Tai, "Replay y pruebas de programas
concurrentes," IEEE Software, 66-74, Marzo de 1991
(Dic93) J. Dick y A. Faivre, "Automatización de la generación y
secuenciación de casos de prueba de las especificaciones Modelo-
base", presentado en FME'93: Método Formal Industrial- Strenght, LNCS
670, 1993
(Fran93) P. Frankl y E. Weyuker, "Un análisis formal de la detección de
fallo capacidad de los métodos de prueba," IEEE Transactions on
Software Engineering, vol. 19, ISS. 3, 202-, Marzo, 1993
(Fran98) P. Frankl, D. Hamlet, B. Littlewood y L. Strigini, "Evaluación de
métodos de prueba por la fiabilidad entregado," IEEE Transactions on
Software Engineering,
vol. 24, ISS. 8, 586-601, agosto de 1998
(Ham92) D. Hamlet, "¿Estamos poniendo a prueba la verdadera fiabilidad ?,"
IEEE Software, 21-27, Julio, 1992
(Hor95) H. y J. Horcher Peleska, "Uso de especificaciones formales para
apoyar pruebas de software," Software de calidad Diario, vol. 4, 309-327,
1995
(How76) WE Howden, "La fiabilidad del Camino Estrategia de evaluación
Análisis" IEEE Transactions on Software Engineering, vol. 2, ISS. 3, 208-215,
septiembre de 1976 (Jor02) PC Jorgensen, "Pruebas de Software: El enfoque
de un artesano," Segunda edición, CRC Press, 2004.
© IEEE - 2004 Versión 5-15
(Kan99) C. Kaner, J. Falk y HQ Nguyen, "Testing Software de
ordenador," Segunda ed: Wiley, 1999. (Lyu96) MR Lyu, Manual de
Ingeniería de Software Fiabilidad: Mc-Graw-Hill / IEEE, 1996. (Mor90) LJ
Morell, "Teoría de la Fault-Based Testing"
IEEE Transactions on Software Engineering, vol. 16, ISS.
8, 844-857, agosto de 1990
(Ost88) TJ Ostrand y MJ Balcer, "El método de reparto Categoria- para
la Especificación y Generación de Pruebas Funcionales" Comunicaciones
del ACM, vol. 31, ISS.
3, 676-686, junio, 1988
(Ost98) T. Ostrand, A. Anodide, H. Foster y T. Goradia, "un entorno visual
Desarrollo de prueba para sistemas de interfaz gráfica de usuario",
presentado en ACM Proc. En t. Simposio sobre Sw de ensayos y análisis
(Issta' 98), Clearwater Beach, Florida, EE.UU., 1998 (Per95) W. Perry, Métodos
eficaces para Pruebas de Software:
Wiley, 1995.
(Pfl01) SL Pfleeger, "Ingeniería de Software: Teoría y Práctica", Segunda ed:
Prentice-Hall, 2001, Cap. 8, 9. (Pos96) RM Poston, La automatización de
pruebas de Software basada en la especificación: IEEE, 1996.
(Rot96) G. Rothermel y MJ Harrold, "El análisis de las pruebas de
regresión Técnicas de selección" IEEE
Las transacciones en Ingeniería de Software, vol. 22, ISS. 8, 529-, agosto de
1996
(Sch94) W. Schütz, "Cuestiones fundamentales en las inspecciones
Distribuido Sistemas de Tiempo Real" Real-Time Systems Journal, vol. 7,
ISS. 2, 129-157, septiembre de 1994 (Voa95) JM Voas y KW Miller,
"Capacidad de prueba del software: La nueva verificación" IEEE Software, 17-
28, mayo de 1995
(Wak99) S. Wakid, DR DR Kuhn y Wallace, "Hacia creíble Prueba de TI
y Certificación," IEEE Software, 39-47, julio-agosto de 1999 (Wey82) EJ
Weyuker, "en las pruebas de programas no comprobables," El Diario del
ordenador, vol. 25, ISS. 4, 465-
470, 1982
(Wey83) EJ Weyuker, "Evaluación de la Prueba de Suficiencia de datos a través
del Programa de inferencia" ACM Trans. en
Lenguajes de Programación y Sistemas, vol. 5, ISS. 4, 641-
655, octubre de 1983
(Wey91) EJ Weyuker, SN Weiss y D. Hamlet, "Comparación de
estrategias de prueba Programa", presentado en Proc. Simposio sobre
ensayos, análisis y verificación TAV 4, Victoria, Columbia Británica,
1991 (Zhu97) H. Zhu, PAV Hall y JHR mayo, "Unidad de Software
Cobertura de la prueba y suficiencia" ACM Computing Surveys, vol. 29,
ISS. 4, 366-427, diciembre de 1997
 Estándar para el software de pruebas unitarias: IEEE, 1987. (IEEE1044-93)
UN PÉNDICE B. L LISTA DE S NORMAS IEEE Std 1044-1993 (R2002), Norma IEEE para la Clasificación de
Software de Anomalías:
(IEEE610.12-90) IEEE Std 610.12-1990 (R2002), Glosario IEEE
IEEE, 1993.
Estándar de Ingeniería de Software Terminología:
IEEE, 1990. (IEEE1228-94) IEEE Std 1228-1994, Estándar para los planes de seguridad del

(IEEE829-98) IEEE Std 829-1998, Estándar para la Documentación de la software: IEEE, 1994. (IEEE12207.0-96)

comprobación del software: IEEE, 1998. (IEEE982.1-88) IEEE Std 982,1 a IEEE / EIA 12207.0-

1988, Diccionario estándar IEEE de Medidas para producir software fiable:
IEEE, 1988.
(IEEE1008-87) IEEE Std 1008-1987 (R2003), IEEE
1996 // ISO / IEC12207: 1995, Industria Implementación de Int. Std. ISO /
IEC 12207: 95, Norma para Tecnología de la Información-Software
Procesos del Ciclo de Vida, vol. IEEE,
1996.

5-16 © IEEE - 2004 Versión

 do CAPÍTULO 6 S OFTWARE METRO
ANTENIMIENTO
UN CRONYMS
CMMi Capability Maturity Model Integration
ICSM Conferencia Internacional sobre Mantenimiento de
Software
SMC Gestión de la Configuración de Software
SQA Software de Control de Calidad
V&V Verificación y validación
Y2K año 2000
yo INTRODUCCIÓN
los esfuerzos de desarrollo de software como resultado la entrega de un producto
de software que satisfaga las necesidades del usuario. En consecuencia, el
producto de software debe cambiar o evolucionar. Una vez en funcionamiento, los
defectos se descubren, cambian entornos operativos, y los nuevos requisitos de los
usuarios superficie. La fase de mantenimiento del ciclo de vida comienza después
de un período de garantía o post-implantación de entrega apoyo, pero las
actividades de mantenimiento producirse mucho antes. El mantenimiento de
software es una parte integral de un ciclo de vida del software. Sin embargo, no ha,
históricamente, recibido el mismo grado de atención que
las otras fases tienen.
Históricamente, el desarrollo de software ha tenido un perfil mucho más alto que el
mantenimiento del software en la mayoría de las organizaciones. Esto está
cambiando, ya que las empresas se esfuerzan para exprimir el máximo rendimiento
de su inversión en el desarrollo de software, manteniendo el software que opera el
mayor tiempo posible. La preocupación por el Año 2000 de vuelco (Y2K) centraron
la atención significativa en la fase de mantenimiento de software, y el paradigma de
código abierto ha traído más atención a la cuestión del mantenimiento de artefactos
de software desarrollados por otros.
En la Guía, el mantenimiento del software se define como el conjunto de
actividades necesarias para proporcionar soporte rentable de software. Las
actividades se llevaron a cabo durante la etapa previa a la entrega, así como
durante la etapa de post-parto. actividades previas a la entrega incluyen la
planificación para las operaciones posteriores a la entrega, para el mantenimiento,
y para la determinación de la logística
actividades de transición. Fijar una entrega
actividades incluyen la modificación de software, capacitación y operativo o
interfaz con una mesa de ayuda.
El software de mantenimiento KA está relacionado con todos los demás aspectos de
la ingeniería de software. Por lo tanto, esta descripción KA está vinculado a todos los
demás capítulos de la Guía.
© IEEE - 2004 Versión
segundo REAKDOWN DE T OPICS PARA S OFTWARE METRO ANTENIMIENTO
El desglose de mantenimiento de software KA de temas se muestra en la
Figura 1.
1. Fundamentos de mantenimiento de software
Esta primera sección presenta los conceptos y terminología que forman una base
subyacente a la comprensión de la función y el alcance del mantenimiento del
software. Los temas proporcionan definiciones y hacer hincapié en por qué hay una
necesidad de mantenimiento. Categorías de mantenimiento de software son
fundamentales para la comprensión de su significado subyacente.
1.1. Definiciones y terminología
[IEEE1219-98: s3.1.12; IEEE12207.0-96: S3.1, S5.5; ISO14764-99:
S6.1]
El mantenimiento del software se define en el estándar IEEE para el
mantenimiento de software, IEEE 1219, como la modificación de un producto de
software después de la entrega para corregir defectos, para mejorar el
rendimiento u otros atributos, o para adaptar el producto a un entorno
modificado. La norma también se ocupa de las actividades de mantenimiento
antes de la entrega del producto de software, pero sólo en un apéndice
información de la norma.
El estándar IEEE / EIA 12207 para los procesos del ciclo de vida del software
representa esencialmente el mantenimiento como uno de los procesos del ciclo
de vida primarias, y describe el mantenimiento como el proceso de un producto
de software de someterse a la “modificación al código y la documentación
asociada, debido a un problema o la necesidad de mejora . El objetivo es
modificar el producto software existente, preservando su integridad.”ISO / IEC
14764, el estándar internacional para el mantenimiento de software, define el
mantenimiento del software en los mismos términos como IEEE / EIA 12207 y
hace hincapié en los aspectos previos a la entrega de mantenimiento,
planificación , por ejemplo.
1.2. Naturaleza de Mantenimiento
[Pfl01: c11s11.2]
mantenimiento de software sostiene el producto de software en toda
su operativa ciclo vital. Modificación
las solicitudes se registran y se realiza un seguimiento, el impacto de los cambios
propuestos se determina, código de software y otros artefactos se modifican, la prueba
se lleva a cabo, y una nueva versión del producto de software se libera. Además, la
formación y el apoyo diario se proporcionan a los usuarios. Pfleeger [Pfl01] establece
que “el mantenimiento tiene un alcance más amplio, con más para realizar un
seguimiento y control” de desarrollo.
6-1
Un mantenedor está definido por IEEE / EIA 12207 como una
organización que lleva a cabo actividades de mantenimiento
[IEEE12207.0-96]. En este KA, el término se referirá en ocasiones a
personas que realizan esas actividades, lo que contrasta con los
desarrolladores.
IEEE / EIA 12207 identifica las principales actividades de mantenimiento de
software como: Proceso implementación;
problema y el análisis de modificación; aplicación modificación;
mantenimiento revisión / aceptación;
migración; y la jubilación. Estas actividades se describen en el tema 3.2 Actividades
de mantenimiento.
Mantenedores pueden aprender de los conocimientos del desarrollador
del software. El contacto con los desarrolladores y la participación
temprana por el mantenedor ayuda a reducir el esfuerzo de
mantenimiento. En algunos casos, el ingeniero de software no puede ser
alcanzado o ha pasado a otras tareas, lo que crea un desafío adicional
para los mantenedores. El mantenimiento debe tomar los productos del
desarrollo, código, o documentación, por ejemplo, y apoyar de forma
inmediata y evolucionar / mantenerlas progresivamente
encima el software vida ciclo.

Mantenimiento del software

Fundamentos de Cuestiones clave en

Mantenimiento Las técnicas para
mantenimiento de el mantenimiento
Proceso mantenimiento
software de software

Definiciones y Problemas
Los procesos de mantenimiento programa de Comprensión
terminología técnicos

Actividades de mantenimiento Reingeniería

Naturaleza de Asuntos
Mantenimiento Gerenciales

Ingeniería inversa
Estimación de costes de
La necesidad de mantenimiento
mantenimiento

La mayoría de los costos de

Medición de mantenimiento de
mantenimiento
software

Evolución de soffware

Categorías de
Mantenimiento

Figura 1 Desglose de los temas para el mantenimiento del software KA

1.3. La necesidad de mantenimiento a las acciones correctivas y de software no correctoras. Mantenimiento

debe ser realizado con el fin de:
[Pfl01: c11.s11.2; Pig97: c2s2.3; Tak97: c1] mantenimiento es necesario para
asegurar que el software continúa para satisfacer las necesidades del usuario. El corregir fallas Mejorar el diseño

mantenimiento es aplicable al software desarrollado usando cualquier modelo de Implementar mejoras

vida del software de ciclo (por ejemplo, en espiral). El sistema cambia debido

6- 2 © IEEE - 2004 Versión

 Interfaz con otros sistemas las decisiones de mantenimiento son ayudados por la comprensión de lo que ocurre
con los sistemas (y software) con el tiempo. Otros afirman que el mantenimiento se
Adaptar los programas de manera que diferentes de hardware, software, las
continúa el desarrollo, con la excepción de que hay una entrada adicional (o
características del sistema y de telecomunicaciones instalaciones se pueden utilizar
restricción) -existing de software grande nunca es completa y continúa evolucionando.
A medida que evoluciona, crece más compleja si no se toman algunas medidas para
Migrar software heredado
reducir esta complejidad.
retirarse de software El mantenedor

de ocupaciones comprender las cuatro llave Dado que el software demuestra el comportamiento y tendencias regular, estos
características, de acuerdo con Pfleeger [Pfl01]: pueden ser medidos. Los intentos de desarrollar modelos de predicción para
estimar han hecho el esfuerzo de mantenimiento, y, como resultado, las
Mantener el control sobre las funciones del día a día del software
herramientas de gestión útiles se han desarrollado. [Art88], (Bel72)

Mantener el control sobre la modificación del software El perfeccionamiento de

1.6. Categorías de Mantenimiento
las funciones existentes
[Art88: c1s1.2; Lie78; Dor02: v1c9s1.5; IEEE121998: s3.1.1, s3.1.2, s3.1.7,
La prevención de rendimiento del software de la degradación a niveles
A.1.7; ISO1476499: S4.1, S4.3, S4.10, s4.11, S6.2; Pig97: c2s2.3] Lientz y
inaceptables
Swanson definen inicialmente tres categorías de mantenimiento: correctivo,
1.4. La mayoría de los costos de mantenimiento
adaptativo, y perfective. [Lie78; IEEE 1219-1298] Esta definición se actualiza
[Abr93: 63-90; Pfl01: c11s11.3; Pig97: C3; PRE01: más tarde en la Norma para Mantenimiento de Software Ingeniería de
c30s2.1, c30s2.2] Software-ISO / IEC 14764 para incluir cuatro categorías, de la siguiente

Mantenimiento consume una parte importante de los recursos financieros del ciclo de manera:
vida del software. Una percepción común de mantenimiento de software es que se
limita a fijar los fallos. Sin embargo, estudios y encuestas en los últimos años han
El mantenimiento correctivo: modificación reactiva de un producto de software
indicado que la mayoría, más del 80%, del esfuerzo de mantenimiento de software se
lleva a cabo después de la entrega para corregir problemas descubiertos
utiliza para acciones no correctoras.
[Abr93, Pig97, PRE01] Jones
mantenimiento adaptativo: La modificación de un producto de software se realiza
(Jon91) describe la forma en que los responsables de mantenimiento de software a
después de la entrega para mantener un producto de software utilizable en un
menudo mejoras y correcciones de grupo juntos en sus informes de gestión. Esta
inclusión de las solicitudes de mejora con los informes de problemas contribuye a entorno cambiante cambiado o mantenimiento perfectivo: Modificación de un

algunos de los conceptos erróneos con respecto a los altos costos de correcciones. producto de software después de la entrega para mejorar el rendimiento o

La comprensión de las categorías de mantenimiento de software ayuda a capacidad de mantenimiento

comprender la estructura de los costes de mantenimiento de software. Además, la

comprensión de los factores que influyen en la capacidad de mantenimiento de un
El mantenimiento preventivo: La modificación de un producto de software
sistema puede ayudar a contener los costos. Pfleeger [Pfl01] presenta algunos de
después de la entrega para detectar fallas latentes y correctos en el
los factores técnicos y no técnicos que afectan a los costes de mantenimiento de
producto de software antes de que sean eficaces fallas
software, de la siguiente manera:

ISO / IEC 14764 clasifica mantenimiento adaptativo y perfectivo como mejoras.

También agrupa las categorías de mantenimiento correctivo y preventivo en
Novedosa aplicación
una categoría de la corrección, como se muestra en la Tabla 1. El
Tipo de Software mantenimiento preventivo, la categoría más nuevo, lo más a menudo se
realiza en los productos de software donde la seguridad es crítica.
El mantenimiento del software software de la disponibilidad de

personal período de vida características de calidad de hardware

Corrección Mejora
de software diseño, construcción,
documentación y las pruebas Proactivo Preventivo perfectivo

1.5. Evolución de Software Reactivo Correctivo Adaptado

[Art88: c1s1.0, S1.1, S1.2, c11, S1.1, S1.2; Leh97: 108-124], (Bel72)
Tabla 1: las categorías de mantenimiento de software

Lehman abordó por primera vez el mantenimiento del software y la evolución de

los sistemas en 1969. Durante un período de veinte años, su investigación
condujo a la formulación de ocho “leyes de la evolución”. [Leh97] Las principales
conclusiones son el hecho de que el mantenimiento es desarrollos evolutivos, y
que
2. Temas clave en el mantenimiento de software
Una serie de cuestiones clave debe ser tratada para garantizar el
mantenimiento eficaz de software. Es importante entender que el
mantenimiento del software proporciona único

© IEEE - 2004 Versión 6-3

desafíos técnicos y de gestión para los ingenieros de software. Tratando de
encontrar un fallo en el software que contiene 500 mil líneas de código que el
ingeniero de software no se desarrolló es un buen ejemplo. Del mismo modo,
compitiendo con los desarrolladores de software de recursos es una batalla
constante. La planificación de una versión futura, mientras que la codificación de
la próxima versión y el envío de parches de emergencia para la versión actual,
también crea un desafío. La siguiente sección presenta algunas de las cuestiones
técnicas y de gestión relacionados con el mantenimiento del software. Se han
agrupado bajo los siguientes encabezados de los temas:
Cuestiones técnicas de gestión
de los problemas de estimación
de costos y Medidas
2.1. Problemas técnicos
2.1.1. comprensión limitada
[Dor02: v1c9s1.11.4; Pfl01: c11s11.3; Tak97: c3] comprensión
limitada se refiere a la rapidez con que un ingeniero de software puede
entender dónde hacer un cambio o una corrección en el software que este
individuo no se desarrolló. Las investigaciones indican que alrededor del 40%
al 60% del esfuerzo de mantenimiento
está dedicada a la comprensión de la
software para ser modificado. Por lo tanto, el tema de la comprensión software
es de gran interés para los ingenieros de software. Comprensión
Es más dificil en texto orientado
la representación, en el código fuente, por ejemplo, donde a menudo es difícil trazar
la evolución del software a través de sus publicaciones / versiones si los cambios no
se documentan y cuando los desarrolladores no están disponibles para explicarlo,
que suele ser el caso. Por lo tanto, los ingenieros de software pueden tener
inicialmente una comprensión limitada del software, y mucho tiene que hacer para
remediar esto.
2.1.2. Pruebas
[Art88: c9; Pfl01: c11s11.3]
El costo de la repetición de la prueba completa en una pieza importante de software
puede ser significativo en términos de tiempo y dinero. Las pruebas de regresión, la
repetición de pruebas selectiva de un componente de software o para verificar que
las modificaciones no han causado efectos no deseados, es importante para el
mantenimiento. Así, encontrar tiempo para probar es a menudo difícil. También
existe el reto de coordinar las pruebas cuando diferentes miembros del equipo de
mantenimiento están trabajando en diferentes problemas al mismo tiempo. [Plf01]
Cuando software realiza las funciones críticas, puede que sea imposible llevarlo
fuera de línea para la prueba. La Prueba KA Software proporciona información y
referencias adicionales sobre el asunto en sus pruebas de regresión subtema 2.2.6.
2.1.3. Análisis de impacto
[Art88: c3; Dor02: v1c9s1.10; Pfl01: c11s11.5] análisis de impacto
describe cómo llevar a cabo, de manera rentable, un análisis completo del
impacto de un cambio en la ya existente
6- 4
software. Mantenedores deben poseer un conocimiento profundo de la
estructura y el contenido [Pfl01] del software. Ellos usan este conocimiento para
llevar a cabo análisis de impacto, que identifica a todos los sistemas y
productos de software afectadas por una solicitud de cambio de software y
desarrolla una estimación de los recursos necesarios para llevar a cabo el
cambio. [Art88] Además, se determina el riesgo de hacer el cambio. La solicitud
de cambio, a veces se llama una petición de modificación (MR) y, a menudo
llamado un informe de problemas (PR), primero debe ser analizado y traducido
en términos de software. [Dor02] Se lleva a cabo después de una solicitud de
cambio entra en el proceso de gestión de configuración de software. Arthur
[art88] establece que los objetivos del análisis de impacto son:
Determinación del alcance de un cambio con el fin de planificar y
ejecutar el trabajo
Desarrollo de estimaciones precisas de los recursos necesarios para llevar
a cabo el trabajo de análisis del costo / beneficios de la comunicación para
el cambio solicitado a otros de la complejidad de un cambio dado
La gravedad de un problema a menudo se utiliza para decidir cómo y cuándo se
solucionará el problema. El ingeniero de software a continuación, identifica los
componentes afectados. Varias soluciones posibles se proporcionan a continuación,
se hace una recomendación sobre el mejor curso de acción.
Software diseñado con capacidad de mantenimiento en mente facilita en gran medida
el análisis del impacto. Más información se puede encontrar en el software de gestión
de la configuración KA.
2.1.4. mantenibilidad
[ISO14764-99: s6.8s6.8.1; Pfl01: c9s9.4; Pig97: c16] ¿Cómo se puede
promover y seguir en cuestiones de capacidad de mantenimiento durante el
desarrollo? El IEEE [IEEE610.12-90] define mantenibilidad como la facilidad con
la que el software puede ser mantenida, mejorado, adaptado, o corregido para
satisfacer los requisitos especificados. ISO / IEC define mantenibilidad como
una de las características de calidad (ISO9126-01). Mantenibilidad
sub-características deben especificarse, revisados ​y controlados durante las
actividades de desarrollo de software con el fin de reducir los costes de
mantenimiento. Si esto se realiza con éxito, la capacidad de mantenimiento del
software mejorará. Esto es a menudo difícil de lograr debido a la capacidad de
mantenimiento sub-características no son un foco importante durante el proceso
de desarrollo de software. Los desarrolladores están preocupados con muchas
otras cosas y, a menudo ignoran las necesidades del mantenedor. Esto a su
vez puede, ya menudo lo hace,
resultado en una falta de sistema
documentación, que es la principal causa de dificultades en la comprensión del
programa y análisis de impacto. También se ha observado que la presencia de
procesos sistemáticos y maduros, técnicas y herramientas de ayuda para
mejorar la capacidad de mantenimiento de un sistema.
© IEEE - 2004 Versión
2.2. Asuntos Gerenciales
2.2.1. Alineamiento con los objetivos de organización [Ben00:
c6sa; Dor02: v1c9s1.6]
objetivos de la organización describen cómo demostrar el retorno de la inversión de las
actividades de mantenimiento de software. Bennett [Ben00] afirma que “el desarrollo de
software inicial es por lo general basado en proyectos, con una escala de tiempo definido
y presupuesto. El énfasis principal es entregar a tiempo y dentro del presupuesto para
satisfacer las necesidades del usuario. Por el contrario, el mantenimiento de software a
menudo tiene el objetivo de extender la vida de un software para el mayor tiempo posible.
Además, puede ser impulsado por la necesidad de satisfacer la demanda del usuario para
actualizaciones de software y Realce mentos. En ambos casos, el retorno de la inversión
es mucho menos clara, por lo que la vista a nivel de la alta dirección es a menudo de una
importante actividad que consume recursos significativos sin ningún beneficio
cuantificable clara para la organización “.
2.2.2. dotación de personal
[Dek92: 10-17; Dor02: v1c9s1.6; Par86: c4s8-c4s11] (Lie81)
Dotación de personal se refiere a la manera de atraer y mantener al personal de
mantenimiento de software. Mantenimiento a menudo no es visto como un trabajo glamoroso.
Deklava proporciona una lista de los problemas relacionados con la dotación de personal en
base a datos de la encuesta. [Dek92] Como resultado, el personal de mantenimiento de
software son frecuentemente vistos como “ciudadanos de segunda clase” (Lie81) y la moral,
por lo tanto sufre. [Dor02]
2.2.3. Proceso
[Pau93; Ben00: c6sb; Dor02: v1c9s1.3] proceso de software es un
conjunto de actividades, métodos, prácticas y transformaciones que las personas
utilizan para desarrollar y mantener el software y los productos asociados. [Pau93]
En el nivel de proceso, las actividades de mantenimiento de software comparte
mucho en común con el desarrollo de software (por ejemplo, gestión de
configuración de software es una actividad crucial en ambos). [Ben00] El
mantenimiento también requiere varias actividades que no se encuentran en
desarrollo de software (ver sección
3.2 sobre las actividades únicas para más detalles). Estas actividades presentan desafíos
para la gestión. [Dor02]
2.2.4. Aspectos de organización de mantenimiento [Pfl01:
c12s12.1-c12s12.3; Par86: c4s7; Pig97: c2s2.5;
Tak97: c8]
Aspectos organizativos describen cómo identificar a qué organización y / o
función será responsable del mantenimiento del software. El equipo que
desarrolla el software no está necesariamente asignado para mantener el
software una vez que esté en funcionamiento.
Al decidir dónde se ubicará la función de mantenimiento de software, las organizaciones
de ingeniería de software pueden ser, por ejemplo, quedarse con el desarrollador
original o ir a un equipo separado (o personal de mantenimiento). A menudo, la opción
mantenedor se elige para asegurar que el software funciona correctamente y evoluciona
para satisfacer las necesidades cambiantes de los usuarios. Puesto que hay
© IEEE - 2004 Versión
muchos pros y los contras de cada una de estas opciones [Par86, Pig97], la
decisión debe hacerse sobre una base de caso por caso. Lo que es importante es
la delegación o asignación de la responsabilidad de mantenimiento a un solo
grupo o persona [Pig97], independientemente de la estructura de la organización.
2.2.5. La externalización
[Dor02: v1c9s1.7; Pig97: c9s9.1, S9.2], (Car94; McC02)
La externalización de mantenimiento se está convirtiendo en una industria importante.
Las grandes empresas están externalizando carteras enteras de sistemas de
software, incluyendo el mantenimiento del software. Más a menudo, la opción de la
externalización se ha seleccionado para el software crítico de menos de misión, ya
que las empresas no están dispuestos a perder el control del software utilizado en su
negocio principal. Carey (Car94) informa que algunos externalizar sólo si pueden
encontrar la manera de mantener el control estratégico. Sin embargo, las medidas de
control son difíciles de encontrar. Uno de los principales retos para las empresas
externas es determinar el alcance de los servicios de mantenimiento requeridos y los
detalles contractuales. McCracken (McC02) afirma que el 50% de los subcontratistas
prestan servicios sin ningún tipo de acuerdo de nivel de servicio claro. Las empresas
de subcontratación suelen pasar varios meses evaluar el software antes de que
entren en una relación contractual
relación. [Dor02] Otro reto
identificado es la transición del software para el proveedor externo. [Pig97]
2.3. Estimación de costes de mantenimiento
Los ingenieros de software deben entender las diferentes categorías de
mantenimiento de software, expuestos anteriormente, con el fin de abordar la
cuestión de estimar el costo de mantenimiento del software. Para fines de
planificación, estimación de costos es un aspecto importante del mantenimiento
del software.
2.3.1. Estimación de costos
[Art88: c3; Boe81: c30; Jon98: c27; Pfl01: c11s11.3; Pig97: c8]
Se mencionó en el subtema 2.1.3, el análisis del impacto, que el análisis de impacto
identifica todos los sistemas y productos de software afectadas por una solicitud de
cambio de software y desarrolla una estimación de los recursos necesarios para
llevar a cabo ese cambio. [Art88]
estimaciones de los costos de mantenimiento se ven afectados por muchos factores
técnicos y no técnicos. ISO / IEC14764 establece que “los dos métodos más
populares a los recursos de estimación para el mantenimiento del software son el uso
de modelos paramétricos y el uso de la experiencia” [ISO14764-99: s7.4.1]. Muy a
menudo, se utiliza una combinación de éstos.
2.3.2. Los modelos paramétricos
[Ben00: s7; Boe81: c30; Jon98: c27; Pfl01: c11s11.3] Algunos trabajos se
han realizado en la aplicación de modelos de costos paramétrico para el
mantenimiento del software. [Boe81, Ben00] De importancia es que se necesitan
datos de proyectos anteriores con el fin de utilizar los modelos. Jones [Jon98] discute
todos los aspectos
6-5
de la estimación costos, incluso puntos de función Dicha lista incluye una serie de medidas para cada uno de los cuatro sub-características de
(IEEE14143.1-00), y proporciona un capítulo detallado sobre la estimación de facilidad de mantenimiento:
mantenimiento.
analizabilidad: Las medidas de esfuerzo del mantenedor o recursos
2.3.3. Experiencia gastados en tratar de diagnosticar deficiencias o causas del fracaso, o en

[ISO14764-00: s7, s7.2, s7.2.1, s7.2.4; Pig97: c8; Sta94] la identificación de las partes a ser modificados

Posibilidad de cambiar: Las medidas de esfuerzo del mantenedor asociados con la

La experiencia, en la forma de juicio de expertos (utilizando la técnica Delphi, por
implementación de una modificación especificada
ejemplo), analogías, y una estructura de división del trabajo, varios enfoques que
deberían utilizarse para aumentar los datos de modelos paramétricos. Es Estabilidad: Medidas del comportamiento inesperado de software, entre
evidente que el mejor enfoque para la estimación de mantenimiento es la ellos el encontrado durante las pruebas
combinación de datos empíricos y experiencia. Estos datos deben ser
la capacidad de prueba: Medidas del mantenedor de los usuarios y esfuerzo en tratar
proporcionados como resultado de un programa de medición.
de probar el software modificado algunas medidas de la capacidad de mantenimiento de

software se pueden obtener utilizando herramientas comerciales disponibles. (Lag96;

2.4. Medición de mantenimiento de software
Apr00)
[IEEE1061-98: A.2; Pig97: c14s14.6; Gra87; Tak97: c6s6.1-c6s6.3]
3. Proceso de Mantenimiento

Grady y Caswell [Gra87] discutir el establecimiento de una

los Proceso de mantenimiento subárea proporciona referencias y estándares
corporativa en todo el programa de medición de software, en el que la medición de
utilizados para implementar el proceso de mantenimiento del software. los Actividades
mantenimiento de software formularios y datos
de mantenimiento tema que diferencia el mantenimiento del desarrollo y muestra
se describen colección. El Software Práctico y sistemas de medición
su relación con otras actividades de ingeniería de software. La necesidad de
(PSM) proyecto describe un proceso de medición emisión- impulsado que
procesos de ingeniería de software está bien documentada. CMMi • modelos se
es utilizado por muchos
aplican
organizaciones y es bastante práctico. [McG01] Existen medidas de
software que son comunes a todos los esfuerzos, las siguientes al software
los procesos de mantenimiento, y son similares a los procesos de los desarrolladores.
categorías de las cuales se ha identificado el Software Engineering
[SEI01] Capacidad de Mantenimiento de Software
Institute (SEI): tamaño; esfuerzo; programar; y calidad. [Pig97] Estas
Los modelos de madurez que abordan los procesos únicos de
medidas constituyen un buen punto de partida para el mantenedor. La
mantenimiento del software se describen en (Apr03, Nie02, Kaj01).
discusión de los procesos y productos de medición se presenta en la
Ingeniería de Procesos de Software KA. El programa de medición de
software se describe en el Software Engineering Management KA. 3.1. Los procesos de mantenimiento
[IEEE1219-98: s4; ISO14764-99: S8; IEEE12207.0- 96: S5.5; Par86: c7s1;
Pig97: c5; Tak97: c2] procesos de mantenimiento proporcionan actividades
necesarias y las entradas / salidas detalladas a esas actividades, y se describen
2.4.1. Las medidas específicas
en las normas de mantenimiento de software IEEE 1219 e ISO / IEC
[Car90: S2-S3; IEEE1219-98: Tabla 3; Sta94: 239- 249]

14764.
Abran [Abr93] presenta las técnicas de benchmarking interno para comparar
El modelo de proceso de mantenimiento descrito en la Norma para el Mantenimiento de
las diferentes organizaciones de mantenimiento internos. El mantenedor debe
Software (IEEE 1219) comienza con el esfuerzo de mantenimiento del software durante
determinar qué medidas son adecuadas para la organización de que se trate.
la etapa posterior a la entrega y discute elementos tales como la planificación de
[IEEE1219- 98; ISO9126-01; Sta94] sugiere medidas que son más específicos
mantenimiento. Ese proceso se representa en la Figura 3.
de los programas de medición de mantenimiento de software.

6- 6 © IEEE - 2004 Versión

 Figura 2 Los IEEE1219-98 mantenimiento del proceso Actividades

ISO / IEC 14764 [ISO14764-99] es una elaboración del proceso de 12207,0-96 Retiro problema proceso de implementación y
mantenimiento IEEE / EIA. Las actividades del proceso de mantenimiento de la
análisis de Modificación Modificación
norma ISO / IEC son similares a los de la IEEE, excepto que se agregan un poco
Implementación de Revisión de Mantenimiento /
diferente. Las actividades de los procesos de mantenimiento desarrollados por
ISO / IEC se muestran en la Figura 4. Aceptación de Migración de Software

Implementación

de procesos Takang y Grubb [Tak97] proporcionan un historial de modelos de procesos de

mantenimiento que condujeron al desarrollo de los modelos de IEEE e ISO / IEC
proceso. Parikh [Par86] también da una buena visión general de un proceso de
mantenimiento genérico. Recientemente, las metodologías ágiles han surgido
que promueven procesos de luz. Este requisito surge de la cada vez mayor
demanda de entregas rápidas de los servicios de mantenimiento. Algunos
experimentos con el mantenimiento Xtreme se presentan en (Poo01).
Análisis de ntenance Mai
problemas y Revisión/

Modificación Aceptación
3.2. Actividades de mantenimiento

Como ya se ha señalado, muchas actividades de mantenimiento son similares a las de

desarrollo de software. Mantenedores de realizar el análisis, diseño, codificación, pruebas
Implementación y documentación. Deben realizar un seguimiento de los requisitos en sus actividades tal
modificación como se hace en el desarrollo, y actualizar la documentación a medida que cambian las
líneas de base.
ISO / IEC14764 recomienda que, cuando una
mantenedor se refiere a un proceso de desarrollo similar, debe adaptarlo a sus
necesidades específicas [ISO14764-99: s8.3.2.1, 2]. Sin embargo, para el

Migración mantenimiento del software, algunas actividades implican procesos únicos para el
Jubilación mantenimiento del software.

figura 3 ISO / IEC 14764-00 proceso de mantenimiento del software 3.2.1. actividades únicas [art88: C3; Dor02: v1c9s1.9.1; IEEE1219-
98: S4.1, S4.2; ISO14764-99: s8.2.2.1, s8.3.2.1; Pfl01:
c11s11.2]

Cada una de las actividades de mantenimiento de software 14764 primaria ISO / IEC
se subdivide en tareas, de la siguiente manera. Hay una serie de procesos, actividades y prácticas que son únicos para el
mantenimiento del software, por ejemplo:

© IEEE - 2004 Versión 6-7

 Transición: una secuencia controlada y coordinada de las actividades
durante el cual el software se transfiere progresivamente desde el
desarrollador para el mantenedor [Dek92, Pig97] Modificación
Solicitud aceptación / rechazo:
modificación Solicitud de trabajo sobre un cierto
Tamaño / esfuerzo / complejidad pueden ser rechazados por los mantenedores y
desviados a un desarrollador [Dor02], (Apr01) Solicitud de Modificación y Informe de
problemas de informaciones: una función de soporte al usuario final que
desencadena la
evaluación, priorización y cálculo de costos de las solicitudes de modificación
[Ben00]
Análisis de impacto (véase la sección 2.1.3 para más detalles) de soporte de
software: ayuda y asesoramiento a los usuarios en relación con una solicitud de
información (por ejemplo, reglas de negocio, validación, significado de datos y
solicitudes ad-hoc / informes) (Apr03)
Acuerdos de Nivel de Servicio (SLAs) y contratos de mantenimiento
especializados (de dominio específico) que son responsabilidad de los
mantenedores (Apr01)
3.2.2. Las actividades de apoyo
[IEEE1219-98: A.7, A.11; IEEE12207.0-96: c6, c7; ITI01;
Pig97: c10s10.2, c18]; (Kaj01)
Mantenedores también pueden realizar actividades de apoyo, como la planificación del
mantenimiento de software, gestión de configuración de software, verificación y validación, el
aseguramiento de la calidad del software, las revisiones, auditorías, y la formación de los
usuarios.
Otra de las actividades de apoyo, formación mantenedor, también es necesaria.
[Pig97; IEEE12207.0-96] (Kaj01)
3.2.3. actividad de planificación de mantenimiento
[IEEE1219-98: A.3; ISO14764-99: S7; ITI01; Pig97: C7,
C8]
Una actividad importante para el mantenimiento del software es la planificación, y
mantenedores debe abordar los problemas asociados con una serie de perspectivas de
planificación:
La planificación empresarial (nivel organizativo) Planificación de mantenimiento
(nivel de transición) Release / versión de planificación (nivel de software)
software de planificación de solicitud de cambio individual (nivel de solicitud)
A nivel de petición individual, la planificación se lleva a cabo durante el análisis de
impacto (consulte subtema 2.1.3 Análisis de impacto para más detalles). La
actividad de planificación de entregas / versión requiere que el mantenedor [ITI01]:
Recoger las fechas de disponibilidad de las solicitudes individuales
De acuerdo con los usuarios sobre el contenido de versiones posteriores
versiones /
Identificar los conflictos potenciales y desarrollar alternativas
6- 8
Evaluar el riesgo de un comunicado dado y desarrollar un plan de respaldo en
caso de problemas debe surgir Informar a todas las partes interesadas Considerando
que los proyectos de desarrollo de software normalmente puede durar desde algunos
meses hasta unos pocos años, la fase de mantenimiento suele durar muchos años.
Haciendo estimaciones de los recursos es un elemento clave de la planificación del
mantenimiento. Esos recursos deben ser incluidos en los presupuestos de planificación
de proyectos de los desarrolladores. Software de planificación de mantenimiento debe
comenzar con la decisión de desarrollar un nuevo sistema y deben considerar los
objetivos de calidad (IEEE1061-98). Un documento de reflexión debe ser desarrollado,
seguido de un plan de mantenimiento. El documento de concepto para el mantenimiento
[ISO14764- 99: s7.2] debe abordar:
El alcance de la adaptación de mantenimiento del software de la
identificación del software de proceso de mantenimiento
el mantenimiento de software
organización
Una estimación de mantenimiento del software cuesta El siguiente
paso es desarrollar un plan de mantenimiento de software correspondiente.
Este plan debe ser preparado durante el desarrollo de software, y debe
especificar cómo los usuarios solicitar modificaciones de software o reportar
problemas. Software de planificación de mantenimiento [Pig97] se aborda en
IEEE 1219 [IEEE1219-98]
e ISO / IEC 14764.
[ISO14764-99] ISO / IEC14764 proporciona directrices para un plan de
mantenimiento.
Por último, al más alto nivel, la organización de mantenimiento tendrá que llevar a
cabo actividades de planificación de negocios (y los recursos humanos,
presupuestarios financieros) al igual que todas las otras divisiones de la
organización. La gestión del conocimiento requerido para ello puede encontrarse
en las disciplinas relacionadas con el capítulo de Ingeniería de Software.
3.2.4. gestión de configuración de software [art88: C2, C10; IEEE1219-98:
A.11; IEEE12207.0- 96: S6.2; Pfl01: c11s11.5; Tak97: c7] El estándar
IEEE para el Mantenimiento de Software, IEEE 1219 [IEEE1219-98],
describe software configuración
gestión como un elemento fundamental del proceso de mantenimiento.
procedimientos de gestión de configuración de software deben proporcionar
para la verificación, validación y auditoría de cada paso necesario para
identificar, autorizar, implementar y liberar el producto de software.
No es suficiente con realizar un seguimiento de las solicitudes de modificación o
informes de problemas. El producto de software y los cambios realizados a la misma
deben ser controlados. Este control se estableció mediante la implementación y
aplicación de un proceso de gestión de configuración de software aprobado (SMC).
La Administración de KA del software de configuración proporciona detalles de SMC
y se analiza el proceso mediante el cual se presentaron las solicitudes de cambio de
software, evaluados y aprobados. SMC para el mantenimiento de software es
diferente de SMC para el software
© IEEE - 2004 Versión
el desarrollo en el número de pequeños cambios que deben ser controlados en el
software operativo. El proceso de SMC se implementa mediante el desarrollo y
siguiendo un plan de gestión de la configuración y los procedimientos operativos.
Mantenedores participan en las Juntas de Control de configuración para
determinar el contenido de la próxima versión / versión.
3.2.5. La calidad del software
[Art98: c7s4; IEE12207.0-96: S6.3; IEEE1219- 98: A.7;
ISO14764-99: s5.5.3.2]
No es suficiente, o bien, simplemente espero que el aumento de la calidad
dará como resultado del mantenimiento de software. Se debe planificarse y
procesos implementados para apoyar el proceso de mantenimiento. Las
actividades y técnicas para la Calidad de Software (SQA), V & V, opiniones
y auditorías deben ser seleccionados de común acuerdo con todos los
demás procesos para alcanzar el nivel deseado de calidad. También se
recomienda que el mantenedor de adaptar el desarrollo de software
procesos, técnicas y resultados, por ejemplo,
documentación de las pruebas, y prueba resultados.
[ISO14764-99]
Más detalles se pueden encontrar en la calidad del software KA.
4. Técnicas de Mantenimiento
Esta subzona presenta algunas de las técnicas generalmente aceptados utilizados en
el mantenimiento del software.
4.1. programa de Comprensión
[Arn92: c14; Dor02: v1c9s1.11.4; Tak97: c3] Los programadores pasar un
tiempo considerable en la lectura y la comprensión de los programas con el fin de
implementar los cambios. navegadores de código son herramientas clave para la
comprensión del programa. documentación clara y concisa puede ayudar en la
comprensión del programa.
© IEEE - 2004 Versión
4.2. reingeniería
[Arn92: c1, c3-C6; Dor02: v1c9s1.11.4; IEEE1219-98:
B.2], (Fow99)
Reingeniería se define como el examen y la alteración de software para
reconstituir en una nueva forma, e incluye la posterior aplicación de la
nueva forma. Dorfman y Thayer [Dor02] estado que la reingeniería es la
forma más radical (y caro) de alteración. Otros creen que la reingeniería se
puede utilizar para los cambios de menor importancia. A menudo no se
lleva a cabo para mejorar la mantenibilidad, pero para reemplazar el
envejecimiento de software heredado. Arnold [Arn92] ofrece un amplio
compendio de temas,
por ejemplo:
conceptos, herramientas y técnicas, estudios de casos, y los riesgos y beneficios
asociados con la reingeniería.
4.3. Ingeniería inversa
[Arn92: c12; Dor02: v1c9s1.11.3; IEEE1219-98: B.3; Tak97: c4,
Hen01]
La ingeniería inversa es el proceso de análisis de software para identificar los
componentes del software y sus interrelaciones y crear representaciones del
software en otra forma o en los niveles más altos de abstracción. La
ingeniería inversa es pasiva; no cambia el software, o resultado de un nuevo
software. los esfuerzos de ingeniería inversa producen gráficos de llamada y
gráficos de flujo de control de código fuente. Un tipo de ingeniería inversa es
redocumentación. Otro tipo es la recuperación de diseño [Dor02]. Refactoring
es la transformación de programas que reorganiza un programa sin cambiar
su comportamiento, y es una forma de ingeniería inversa que busca mejorar
la estructura del programa. (Fow99) Por último, los datos de ingeniería
inversa ha ganado en importancia en los últimos años en los esquemas
lógicos se recuperan de las bases de datos físicos. (Hen01)
6-9
 [Ben00]
s4

organizativos

c1s1.2 c1s1.0-

[Boe81]
c3 c3 C9 c1s1.2,

c11s1.1,

c11s1.2

6- 10
s5,
S6a, s7 s10.1, S11.4

[Car90]
s7 s7 s7
S6B S6a S6c s5
s10.2,

S9.3, S11.4 S10.3

[Dek92]
c30 c30

c4s11

[Dor97]
[IEEE610.12-90]
10-17

[IEEE1061-98]
v1c9s1.7 Aspectos v1c9s1.6 Personal v1c9s1.1 v1c9s1.1 v1c9s1.1 v1c9s1.5

0.3 0.1- 1.4

[IEEE1219-98]
s3.1.1, s3.1.12
A.1.7

s3.1.2,

s3.1.7,

© IEEE - 2004 Versión

[IEEE12207.0-96]
s3, S5.5

[ISO14764-00]
s7, 0, s4.11,
S6.8, S6.2 S4.1, S6.1
s7.2,

s7.2.1, s7.2.4 s6.8.1 s4.3s4.1

[Jon98]
c27 c27

108-124

[Leh97]
c4s7 Proceso

[Par86]
Experiencia
c11s11.3 c12s12.3 c12s12.1 c11s11.5 El c11s11.3 c11s11.3 c11s11.2 c11s11.2
c9s9.4

[Pfl01]
-

c9s9.2 c2s2.5 c2s2.3 c2s2.3

[Pig97]
c16
c8 Los c3

c9s9.1-

C31

[Pre04]
[Sta94]
[Tak97]

La Prueba c1
 c1, c3-c6

c12 c14

C2, C10
c7s4
c3
Planificación

6-11 S9.2, S9.2, S11.4 S7,

S8, S9.2, S9.3,
s2,
S6B, S9.2, S6B S9.1 S9.2 S9.1,
S10.3, S11.2, s8
S11.3, S11.5 S11.4, S11.4, S11.5 S9.2,
s10.1,
S11.5 S11.4 s10.1

S2-S3

C8 Software

v1c9s1.1 v1c9s1.1 v1c9s1.1 v1c9s1.9

1.3 1.4 1.4

.
1
c6s6.1-

A.7, A.11 S4.1-S4.2

Tabla 3
A.11
B.3 B.2 A.7 A.3
s4

C18

C6, C7
S6.3 S6.2 S5.5

s5.5.3.2 s8.2.2.1,

s7 s8

s8.3.2.1

c7s1

c11s11.5 c11s11.2

c10s10.2 c14s14.6
C7, ,
c5

239-249

c6s6.3
c4 c3 c7 c2

R ECOMMENDED R EFERENCIAS PARA S OFTWARE
METRO ANTENIMIENTO
[Abr93] A. Abran y H. Nguyenkim, "Medición del proceso de
mantenimiento a partir de una Demand-Based
Perspectiva," Diario de Mantenimiento de Software: Investigación y
Práctica, vol. 5, ISS. 2, 63-90, 1993 [] Arn93 RS Arnold, La reingeniería del
software: IEEE Computer Society, 1993. [Art98] LJ Arthur, Evolución del
software: El reto de mantenimiento de software: John Wiley & Sons, 1988.
[Ben00] KH Bennett, "Mantenimiento de Software: Un tutorial," en Ingeniería
de software, M. Dorfman y R. Thayer, Eds .: IEEE Computer Society
Press, 2000. [Boe81] BW Boehm, Software Economía Ingeniería:
Prentice-Hall, 1981.
[Car90] Tarjeta de DN y RL de vidrio, La medición de la calidad del diseño de
software: Prentice Hall, 1990. [Dek92] S. Dekleva,
"Estudio Delphi de software
Los problemas de mantenimiento ", presentado en Actas de la Conferencia
Internacional sobre el mantenimiento de software, 1992 [Dor02] M. Dorfman
y RH Thayer, Eds., "Ingeniería de Software."(Vol. 1 y Vol. 2), IEEE
Computer Society Press, 2002 .
[Gra87] RB Grady y DL Caswell, Métricas de Software: se establece un
programa de toda la compañía. Englewood Cliffs NJ, EE.UU.: Prentice-Hall,
1987.
[IEEE610.12-90] IEEE Std 610.12-1990 (R2002), Glosario IEEE Estándar
de Ingeniería de Software Terminología:
IEEE, 1990.
[IEEE1061-98] IEEE Std 1061-1998, Norma IEEE para una metodología de
métricas de software de calidad: IEEE, 1998. [IEEE1219-98] IEEE Std
1219-1998, Norma IEEE para Mantenimiento de Software: IEEE, 1998.
[IEEE12207.0-96]
IEEE / EIA 12207.0-
1996 // ISO / IEC12207: 1995, Implementación de la industria Int. Std.
ISO / IEC 12207: 95, Norma de Información
6- 12
Tecnología de software procesa ciclo de vida, vol. IEEE,
1996.
[ISO9126-01] ISO / IEC 9126-1: 2001, Software
Ingeniería-producto Calidad-Parte 1: Modelo de Calidad: ISO e IEC, 2001.
[ISO14764-99]
ISO / IEC 14764-1999, Software
Mantenimiento de ingeniería del software: ISO e IEC, 1999. [ITI01] IT
Infrastructure Library "prestación de servicios y soporte de servicio," Stationary
Office, Oficina del Gobierno de Comercio de 2001 [Jon98] TC Jones, La
estimación de los costos de software: McGraw-Hill, 1998.
[Leh97] MM Lehman, "Leyes de la Evolución del software Revisited",
presentado en EWSPT96, 1997 [Lie78] B. Lienz, EB Swanson y GE
Tompkins, "Características de Mantenimiento de Aplicaciones de
software"
Communications of the ACM, vol. 21, 1978 [Par86] G. Parikh, Manual de
Mantenimiento de Software:
John Wiley & Sons, 1986. [Pfl01] Pfleeger SL, Ingeniería de Software:
Teoría y Práctica, Segunda ed: Prentice-Hall, 2001. [Pig97] TM Pigoski, Mantenimiento
de Software práctico: Mejores prácticas para la gestión de su inversión en
software,
Primera edición: John Wiley & Sons, 1997. [] Pre04 RS Pressman, Ingeniería
de Software: Enfoque para profesionales, ed Sexto: McGraw-Hill, 2004.
[SEI01] Software Engineering Institute,
"Capacidad
Modelo integrado de madurez, v1.1," CMU / SEI-2002-TR
002, ESC-TR-2002-002, de diciembre de 2001 [Sta94] GE Stark, LC Kern
y CV Vowell, "Un software de métrica
para Apoyo de programación
Administración," Diario de sistemas y software, vol. 24, ISS. 3, marzo de
1994 [Tak97] A. Takang y P. Grubb, Conceptos de software de
mantenimiento y la práctica: Internacional Thomson Computer Press, 1997.
© IEEE - 2004 Versión

UN PÉNDICE A. L LISTA DE F ás R EADINGS
(Abr93) A. Abran, "Mantenimiento y Productividad Estudios de Calidad:
Comentarios sobre la comparación de la Industria", presentado en Actas de la
Conferencia de mantenimiento de software, ICSM93, Montreal, 1993
(Apr00) A. abril y D. Al-Shurougi, "Medición del producto de software para
la evaluación de proveedores", presentado en FESMA2000, Madrid, 2000
(Apr01) A. abril de J. Bouman, A. y D. Al-Abran Shurougi, "Mantenimiento
de Software en un Acuerdo de Nivel de Servicio: El control de las
expectativas del cliente", presentado en la Conferencia Europea de
software de medición, Heidelberg, Alemania, 2001
(Apr03) A. abril de A. y R. Abran Dumke, "capacidad de mantenimiento de
software Modelo de Madurez (SM-CMM): Medición del Desempeño de
Procesos", presentado en el 13 Wokshop Internacional sobre software de
medición _ IWSM2003, Montreal, 2003
(Bas85) VR Basili, "Evaluación cuantitativa de Software Metodología",
presentado en la Conferencia de ordenador primeras diligencias Pan-Pacífico
de 1985
(Bel72) L. Belady y MM Lehman, "Una introducción a la dinámica del
crecimiento", en Estadística Informática de Evaluación del Desempeño, W.
Freiberger, Ed. Nueva York: Academic Press, 1972.
(Ben00) KH Bennett y VT Rajlich, "Mantenimiento Software y Evolución:
Una hoja de ruta," en El futuro de la Ingeniería de Software, A. Finkelstein,
Ed .: ACM Press,
2000.
(Bol95) C. Boldyreff, E. Burd, R. Hather, R. Mortimer, M. y E. Munro más
joven, "El enfoque de AMES Comprensión de aplicación: Un estudio de
caso", presentado en las Actas de la Conferencia Internacional sobre
Mantenimiento de Software -1995, Los Alamitos, CA, 1995 (Boo94) G.
Booch y D. Bryan, Ingeniería de Software con Ada, Tercera edición:
Benjamin / Cummings, 1994. (Cap94) MA y M. Capretz Munro, "Problemas
de administración de configuración de software en el mantenimiento de los
sistemas existentes," Diario de Mantenimiento de Software: Investigación y
Práctica, vol. 6, ISS. 2, 1994 (Car92)
J. Cardow, "No se puede enseñar Software
Mantenimiento !," presentado en Actas de la Sexta Reunión Anual y
Conferencia de El software
Management Association, 1992
(Car94) D. Carey, "Ejecutivo de mesa redonda sobre temas de negocios en
externalización- tomar la decisión" CIO Canadá,
ISS. Junio ​/ Julio de 1994
(Dor97) M. Dorfman y RH Thayer, Eds., "Ingeniería de Software". IEEE
Computer Society Press, 1997. (Dor02) M. Dorfman y RH Thayer, Eds.,
"Software
© IEEE - 2004 Versión
Engineering."(Vol. 1 y Vol. 2), IEEE Computer Society Press, 2002.
(Fow99) M. Fowler y col, Refactoring: mejorar el diseño de código
existente: Addison-Wesley, 1999. (Gra87) RB Grady y DL Caswell, Métricas
de Software: se establece un programa de toda la compañía. Englewood
Cliffs NJ, EE.UU.: Prentice-Hall, 1987. (Gra92) RB Grady, Software
Metrics prácticas para la gestión de proyectos y gestión de procesos: Prentice
Hall, Englewood Cliffs, NJ 07632, 1992. (Jon91) C.
Jones, Aplicada de software de medición:
McGraw-Hill, 1991.
(Kaj01) M. Kajko-Mattson, "motivar el Modelo de Madurez de
mantenimiento correctivo (cm3)", presentado en 7ª Conferencia
Internacional sobre Ingeniería de sistemas complejos, 2001
(Kaj01a) M. Kajko-Mattson, S. Forssander y U. Olsson, "correctiva
Madurez mantenimiento Modelo: Educación y Formación del
mantenedor", presentado en Internacional
Conferencia sobre Ingeniería de Software, 2001 (Kho95) TM
Khoshgoftaar, RM Szabo y JM Voas, "Módulo Programa de Detección con
baja capacidad de prueba", presentado en Actas de la Conferencia
Internacional de Software Mantenimiento-1995, Los Alamitos, CA, 1995
(Lag96) B . Laguë y A. abril "Mapeo de las métricas internas de
mantenibilidad ISO9126 a una herramienta de investigación industrial",
presentado en SESS, Montreal, 1996 (Leh85) MM Lehman y lA Belady, Programa
de Evolución: Procesos de Software Cambiar. ( Londres) Ltd .: Academic
Press Inc., 1985.
(Leh97) MM Lehman, "Leyes de la Evolución del software Revisited",
presentado en EWSPT96, 1997 (Lie81) BP Lientz y EB Swanson, "Los
problemas en mainteanance software de aplicación" Comunicaciones del
ACM, vol. 24, ISS. 11, 763-769, 1981 (McC02) B. McCracken,
"Tomar el control de ESO
Rendimiento ", presentado en InfoServer LLC, de Dallas, Texas, 2002
(Nie02) F. Niessink, V. Clerk y H. v. Vliet, "The IT Capability Maturity
Model," liberación L2 + 3-0,3 proyecto, 2002, disponible en
http://www.itservicecmm.org/doc/itscmm -123
0.3.pdf
(Oma91) PW Omán, J. y D. Hagemeister Ash, "una definición y taxonomía
para el software de mantenimiento, la" Universidad de Idaho, Ingeniería de
Software laboratorio de pruebas, el informe técnico, 91-08 TR de noviembre
de 1991 (Oma92) Omán y P. J. Hagemeister, "métricas para la evaluación
del software del sistema de mantenimiento," presentado en las Actas de la
Conferencia Internacional de Software Mantenimiento-1992, los Alamitos,
CA, 1992 (Pig93) TM Pigoski, "Software Mantenible: ¿por qué
6-13
Queremos y cómo conseguirlo ", presentado en Actas de la Tercera Ingeniería
de Software Investigación Foro de noviembre
1993, de la Universidad de West Florida Press, 1993 (Pig94) TM Pigoski,
"Mantenimiento de Software", en
Enciclopedia de la Ingeniería de Software. Nueva York, Nueva York: John Wiley &
Sons, 1994.
(Pol03) M. Polo, M. Piattini y FR (editores), Eds., "Advances
en software de gestión de mantenimiento:
Tecnologías y soluciones .." Hershey, PA, Idea Group Publishing, 2003.
(Poo00) C. Poole y W. Huisman, "Uso de la programación extrema en un
entorno de mantenimiento," IEEE Software, ISS. Noviembre / Diciembre,
42-50, 2001 (Put97) ​LH Putman y W. Myers, "Software Industrial Strength
- Gestión eficaz utilizando la medición", Los Alamitos, CA, 1997
6- 14
(Sch99) SR Ajedrez, Ingeniería clásica y software orientada a objetos con
UML y C ++: McGraw-Hill,
1999.
(Sch97) Schneberger SL, Cliente / Servidor de mantenimiento de
software: McGraw-Hill, 1997. (Sch87) NF Schneidewind, "El estado de
mantenimiento de software", presentado en Actas de la IEEE, 1987
(Som96) I. Sommerville, Ingeniería de software, Quinta ed:
Addison-Wesley, 1996.
(Val94) JD Vallett, SE Condon, L. Briand, YM Kim y VR Basili, "basándose
en la experiencia de la fábrica para el mantenimiento", presentado en
Actas del Taller de Ingeniería de Software, Software Engineering
Laboratory, 1994
© IEEE - 2004 Versión
 (IEEE14143.1-00) IEEE std 14143.1-
UN PÉNDICE A. L LISTA DE S NORMAS 2000 // ISO / IEC14143-1: 1998, Tecnología Información-
Software de medición-funcional Medida del tamaño-Parte 1: Definiciones
(IEEE610.12-90) IEEE Std 610.12-1990 (R2002), Glosario IEEE Estándar
de conceptos: IEEE, 2000. (ISO9126-01)
de Ingeniería de Software Terminología:
ISO / IEC 9126-1: 2001, Software
IEEE, 1990.
Ingeniería-producto Calidad-Parte 1: Modelo de Calidad: ISO e IEC, 2001.
(IEEE1061-98) IEEE Std 1061-1998, Norma IEEE para una metodología de
(ISO14764-99)
métricas de software de calidad: IEEE, 1998. (IEEE1219-98) IEEE Std
ISO / IEC 14764-1999, Software
1219-1998, Norma IEEE para Mantenimiento de Software: IEEE, 1998. Mantenimiento de ingeniería del software: ISO e IEC, 1999. (ISO15271-98) ISO /
(IEEE12207.0-96) IEC TR 15271: 1998, Tecnología de la Información - Guía para la norma ISO /
IEEE / EIA 12207.0- IEC 12207, (Software Proceso del ciclo de vida): ISO e IEC, 1998. [Abr93]
1996 // ISO / IEC12207: 1995, Implementación de la industria Int. Std.
ISO / IEC 12207: 95, Norma para Tecnología de la
Información-Software Procesos del ciclo de vida, vol. IEEE,
1996.

© IEEE - 2004 Versión 6-15

6- dieciséis © IEEE - 2004 Versión
 do CAPÍTULO 7

S OFTWARE do ONFIGURACIÓN METRO GESTIÓN

gestión de configuración de software (SCM) es un proceso del ciclo de vida

UN CRONYMS del software de apoyo (IEEE12207.0-96) que beneficia
gestión de proyectos, desarrollo y
CCB Configuration Control Board las actividades de mantenimiento, las actividades de aseguramiento, y los
CM Gestión de la configuración clientes y usuarios del producto final. Los conceptos de gestión de la

FCA Auditoría de Configuración Funcional configuración se aplican a todos los artículos que deben ser controlados, aunque
hay algunas diferencias en la implementación entre CM hardware y software
MTBF Tiempo medio entre fallos

PCA Auditoría de Configuración física CM.

SCCE Junta de Control de Configuración de Software SMC está estrechamente relacionado con la actividad de aseguramiento de la
SCI Software Elemento de Configuración calidad del software (SQA). Como se define en la calidad del software KA, SQA
procesos garantizan que El software
SMC Gestión de la Configuración de Software
productos y procesos en el ciclo de vida del proyecto se ajustan a sus requerimientos
PGCS Plan de Gestión de la Configuración de Software especificados por la planificación, la promulgación, y la realización de un conjunto de

SCR Solicitud de cambio de software actividades para proporcionar la confianza adecuada de que la calidad se está
construyendo en el software. actividades de SCM ayudan en el cumplimiento de
SCSA El software de contabilidad de estado de configuración
estos objetivos SQA. En algunos contextos del proyecto (véase, por ejemplo,
Capacidad de SEI / CMMi del Software del Instituto de Ingeniería IEEE730-02), SQA requisitos específicos prescriben ciertas actividades de SCM.
Integración del Modelo de Madurez

SQA Software de Control de Calidad

SRS Software de especificación de requisitos Las actividades de SCM son: gestión y planificación del proceso de SMC,
identificación de la configuración de software,
USNRC Comisión de Regulación Nuclear
el control del software de configuración, estado de la configuración de software,
auditoría de configuración de software y gestión de versiones de software y
yo INTRODUCCIÓN
entrega. La figura 1 muestra una representación estilizada de estas actividades.

Un sistema puede ser definido como un conjunto de componentes organizados

para llevar a cabo una función específica o conjunto de funciones (IEEE Coordinación de cambiar de actividad ( “Code Management”)

610.12-90). La configuración de un sistema es las características funcionales y / o Autorización de Cambios

(Hacerse cambios deberían?)
Soporta Equipo de Mantenimiento de

atención al cliente

físicas de hardware, firmware o software, o una combinación de estos, como se

indica en la documentación técnica y conseguido en un producto. (Buc96) Puede Estado de: Gestión de Proyectos del producto
Integridad física y
Equipo de Desarrollo de

también ser pensado como una colección de versiones específicas de los Aseguramiento funcional

elementos de hardware, firmware, software o combinados de acuerdo con los

procedimientos de construcción específicos para servir a un propósito particular. gestión MGMT. y Determinación Procesamiento Revisión de cuentas
planificación del estado de de liberación
de la configuración Desarrollo de la

gestión

PGCS Equipo

(CM), entonces, es la disciplina de la identificación de la

configuración de un sistema en distintos puntos en el tiempo para el propósito Identificación Control de configuración

de controlar sistemáticamente cambios en la configuración, y el mantenimiento

de la integridad y la trazabilidad de Figura 1. SCM Actividades

la configuración en toda la vida útil del sistema

El software de configuración de administración de KA se relaciona con todos
ciclo (Ber97) Se define formalmente (IEEE610.12-90) como: “. Una disciplina
los demás Kas, ya que el objeto de la gestión de la configuración es el
aplicando dirección técnica y administrativa y de vigilancia para: identificar y
artefacto producido y utilizado en todo el proceso de ingeniería de software.
documentar las características funcionales y físicas de un elemento de
configuración, los cambios de control a esas características, ficha e informar
de procesamiento de cambio y la situación de la ejecución, y verificar el
cumplimiento de los requisitos especificados “.

© IEEE - 2004 Versión 7-1


segundo REAKDOWN DE T OPICS PARA SMC
1. Gestión del Proceso de SMC
SCM controla la evolución y la integridad de un producto mediante la
identificación de sus elementos, la gestión y el control del cambio, y la
verificación, la grabación, y la información sobre la información de configuración.
Desde la perspectiva del ingeniero de software, SCM facilita las actividades de
desarrollo y aplicación de los cambios. Una implementación exitosa de SMC
requiere una planificación y una gestión cuidadosa. Esto, a su vez, requiere una
comprensión del contexto de la organización para, y las limitaciones impuestas
a, el diseño y la implementación del proceso de SMC.
1.1. Contexto de organización de SMC
[Ber92: c4; Dar90: c2; IEEE828-98: c4s2.1] Para planificar un
proceso de SMC para un proyecto, es necesario comprender el contexto de la
organización y las relaciones entre los elementos de la organización. SMC
interactúa con otras actividades o elementos de la organización. Los elementos
de la organización responsable de la ingeniería de software procesos de apoyo
pueden estructurarse de varias maneras. Aunque la responsabilidad de llevar a
cabo ciertas tareas SCM podría ser asignado a otras partes de la organización,
tales como la organización de desarrollo, la responsabilidad general de SMC
menudo recae sobre un elemento de organización distinta o persona
designada. El software se desarrolló con frecuencia como parte de un sistema
más grande que contiene los elementos de hardware y firmware. En este caso,
las actividades de SCM se llevan a cabo en paralelo con las actividades de
hardware y firmware CM, y deben ser compatibles con CM a nivel de sistema.
Buckley [Buc96: c2] describe SMC dentro de este contexto. Tenga en cuenta
que el firmware contiene hardware y software, por lo tanto, ambos conceptos
CM de hardware y software son aplicables.
SMC podría interactuar con la actividad de aseguramiento de la calidad de una
organización en temas como la gestión de documentos y artículos no conformes.
Respecto al primero, algunos artículos bajo control SMC también pueden incluir
datos sobre los proyectos sujetos a las disposiciones de la garantía de calidad de la
organización
7-2
programa. Gestión de elementos no conformes es por lo general la responsabilidad de la
actividad de aseguramiento de la calidad; Sin embargo, SCM puede ayudar con el
seguimiento y la presentación de informes sobre los elementos de configuración de
software que caen en esta categoría. Tal vez la relación más estrecha es con las
organizaciones de desarrollo de software y mantenimiento. Es dentro de este contexto
que muchas de las tareas de control de la configuración del software se llevan a cabo.
Con frecuencia, las mismas herramientas compatibles con los propósitos de desarrollo,
mantenimiento, y SMC.
1.2. Limitaciones y orientación para el proceso SMC
[Ber92: c5; IEEE828-98: c4s1, c4s2.3; Moo98] Las restricciones que
afectan, y orientación para el proceso de SMC provenir de varias fuentes. Las
políticas y procedimientos establecidos en los niveles de organización corporativos
u otros podrían influir o prescribir el diseño y la implementación del proceso de
SMC para un proyecto determinado. Además, el contrato entre el comprador y el
proveedor podría contener disposiciones que inciden en el proceso de SMC. Por
ejemplo, podrían ser necesarias ciertas auditorías de configuración, o puede ser
especificado que ciertos artículos pueden colocar bajo CM. Cuando los productos
de software para ser desarrollados tienen el potencial de afectar a la seguridad
pública, los organismos reguladores externos pueden imponer restricciones
(véase, por ejemplo, USNRC1.169-97). Finalmente, el proceso del ciclo de vida del
software particular elegido para un proyecto de software y las herramientas
seleccionadas para implementar el software afecta al diseño y la implementación
del proceso de SMC. [Ber92]
Una guía para el diseño y la implementación de un proceso de SMC también
se puede obtener de 'mejores prácticas', como se refleja en las normas sobre
la ingeniería de software emitida por los diversos organismos de
normalización. Moore [Moo98] proporciona una guía para estas organizaciones
y sus normas. La mejor práctica se refleja también en los modelos de mejora
de procesos y evaluación de procesos como
El software
Madurez de Capacidades del Instituto de Ingeniería de Integración del
modelo (SEI / CMMi) (SEI01) y IEC15504 Software Ingeniería de Procesos
de Evaluación-ISO / (ISO / IEC
15504-98).
© IEEE - 2004 Versión
 Gestión de la Configuración de Software

Configuración Gestión de la
Gestión del Identificación de Configuración Configuración
del software Entrega de
Proceso de la configuración de del software del software
Determinación Software y
SMC software Controlar Revisión de cuentas
del estado de Entrega

Contexto de Los productos de

Solicitar, evaluar Configuración Configuración Gestión de la
organización de SMC identificación a ser
y aprobar del software funcional de Entrega de
controlado
Cambios en el Configuración software
Software
Limitaciones y Configuración
software del software de Auditoría de
del software construcción de
orientación para la
información de Configuración de
planificación del Configuración software
Configuration estado Software Física
del software
proceso de SMC Control Board Software Informes de
Configuración
SMC Software Proceso de
de los elementos estado Auditoría en
Organización y de software Solicitud de Cambio proceso de
responsabilidades Versiones
auditorías de una
SVN Recursos y relaciones entre
línea de base del
Implementar
Horarios Herramienta los elementos de
Modificaciones en el software
de selección software de línea
software y
de base La
e adquisición del desviaciones
implementación software de dispensas
Proveedor / configuración
Subcontratista Artículos
Control de Interfaz
software
de Control
Library
Plan de Gestión de
la Configuración de
Software

La vigilancia de las

SMC

Medidas SCM
y
Medición

En-Proceso de
Auditorías de SMC

Figura 2 Desglose de los temas para el Software Configuration Management KA

1.3. La planificación de SMC 1.3.1. SMC organización y responsabilidades [Ber92: c7; Buc96: C3; IEEE828-98:
[Dar90: c2; IEEE12207.0-96: c6.s2.1; Som01: c4s2] Para evitar la confusión sobre quién llevará a cabo las actividades de SCM
c29]
dados o tareas, las organizaciones que participan en el proceso de SMC
La planificación de un proceso de SMC para un proyecto dado debe ser coherente necesidad
con el contexto de la organización, las restricciones aplicables, orientación
para ser claramente identificado. Específico
comúnmente aceptada, y la naturaleza del proyecto (por ejemplo, el tamaño y la
responsabilidades para las actividades o tareas SCM dados también tienen que ser
criticidad). Las actividades principales
asignados a entidades de organización, ya sea por título o por el elemento de la
cubierto son: Configuración del software
organización. La autoridad y la presentación de informes canales globales para SMC
Identificación, Control de Software de Configuración, Configuración de Software de
también deben ser identificados, aunque esto puede ser logrado en la etapa de
Contabilidad estado, la configuración de auditoría del software y software de
planificación de la gestión de proyectos o la garantía de calidad.
gestión de emisiones y entrega. Además, cuestiones como la organización y
responsabilidades, recursos y horarios, la selección de herramientas y la
aplicación, el control de proveedores y subcontratistas, y el control de la interfaz 1.3.2. SMC Recursos y horarios [Ber92: c7; Buc96: C3; IEEE828-98: c4s4; c4s5]

son típicamente considerados. Los resultados de la actividad de planificación se Planificación de SMC identifica el personal y las herramientas que participan en la
registran en un Plan de SCM (SCMP), que es típicamente sujeto a SQA revisión y realización de actividades y tareas de SCM. Se abordan cuestiones de
auditoría. programación mediante el establecimiento de secuencias necesarias

© IEEE - 2004 Versión 7-3

de las tareas de SCM y la identificación de sus relaciones con los programas de los Código de sistemas Líneas de base, BCC DBMS, Código Mgmt Sistemas
de Mgmt Bibliotecas,
proyectos y los hitos establecidos en la fase de planificación de la gestión de proyectos.
SCR

También se especifican los requisitos de formación necesarios para la ejecución de los

planes y la formación de los nuevos miembros del personal. Planificación Control de Determinación Gestión de Revisión de cuentas

del estado de liberación y

gestión entrega

1.3.3. Selección de herramienta y la aplicación [Ber92: PGCS

Desarrollo
Equipo
c15; Con98: c6; PRE01: c31]

Los diferentes tipos de capacidades de herramientas y procedimientos para su La identificación de configuración

utilización, apoyan las actividades de SCM. Dependiendo de la situación, estas

capacidades de la herramienta pueden estar disponibles con una combinación de Implementación Evaluación Release Procedimientos

Cambio y Autorización y
herramientas manuales, herramientas automatizadas que proporcionen una única del cambio de auditoría

Aprobación Preparación
capacidad de SMC, herramientas automatizadas que integran una gama de SCM (y
quizás otras) capacidades, o entornos de herramientas integradas que satisfacen las
figura 3 Caracterización de las herramientas de SCM y relacionados
necesidades de múltiples participantes en el proceso de ingeniería de software (por
procedimientos
ejemplo, SCM, de desarrollo, V y V). apoyo herramienta automatizada se convierte
En este ejemplo, los sistemas de gestión de código de apoyar el funcionamiento de las
cada vez más importante, y cada vez más difícil de establecer, ya que los proyectos
bibliotecas de software mediante el control de acceso a los elementos de la biblioteca, la
crecen en tamaño y, como entornos de proyectos se vuelven más complejas. Estas
coordinación de las actividades de múltiples usuarios, y ayudar a hacer cumplir los
procedimientos operativos. Otras herramientas apoyan el proceso de construcción de
herramienta
software y documentación de la versión de los elementos de software contenidos en las
capacidades proporcionan soporte para:
bibliotecas. Herramientas para la gestión de solicitudes de cambio de software compatibles
la Biblioteca SMC
con los procedimientos de control de cambios aplicados a elementos de software
la solicitud de cambio de software (SCR) y los procedimientos de aprobación controladas. Otro
herramientas pueden proporcionar la base de datos

código (y el trabajo relacionado productos) y las tareas de gestión de capacidades de gestión y de información para la gestión, desarrollo,
y las actividades de aseguramiento de la calidad. Como
cambios
se mencionó anteriormente, las capacidades de varios tipos de herramientas pueden ser
la presentación de informes de estado de configuración de software y la recogida de
integrados en sistemas SCM, que a su vez están estrechamente acoplados a varias otras
mediciones de SCM
actividades de software. En la planificación, el ingeniero de software recoge herramientas
software de auditoría de configuración SCM aptos para el trabajo. Planificación considera los problemas que puedan surgir en la

gestión y seguimiento de la documentación de software que realiza el
software construye
gestión y seguimiento de versiones de software y su entrega
aplicación de estas herramientas, especialmente si alguna forma de cambio de cultura es
necesario. Una visión general de los sistemas de SCM y consideraciones de selección se
da en [Dar90: c3, AppA], y un estudio de caso sobre la selección de un sistema SCM se da
en [Mid97]. Información complementaria sobre las herramientas de SCM se puede
encontrar en las herramientas de ingeniería de software y métodos KA.

Las herramientas utilizadas en estas áreas también pueden proporcionar

mediciones para la mejora de procesos. Royce [Roy98] describe siete medidas
básicas de valor en la gestión de procesos de ingeniería de software. La
1.3.4. Proveedor / Subcontratista de control [Ber92: c13; Buc96: c11; IEEE828-98:
información disponible sobre las distintas herramientas de SCM se refiere al
c4s3.6] Un proyecto de software puede adquirir o hacer uso de los productos de
indicador de gestión de trabajo y el progreso de Royce y sus indicadores de
software adquiridos, tales como compiladores y otras herramientas. la planificación
calidad de Cambio de Tráfico y la estabilidad, Chatarra y modularidad, retrabajo
SMC considera si y cómo se tomarán estos elementos bajo control de
y adaptabilidad, y MTBF (tiempo medio entre fallos) y la madurez. Al informar
sobre estos indicadores se pueden organizar de diferentes maneras, configuración (por ejemplo, integrados en las bibliotecas de proyecto) y cómo los
cambios o actualizaciones serán evaluados y gestionados.

como por el software

elemento de configuración o por tipo de cambio solicitado. La figura 4

muestra una asignación de representante de herramienta Consideraciones similares se aplican al software subcontratado. En este caso, los
capacidades y procedimientos a SCM Actividades. requisitos de SCM a ser impuestas sobre el proceso de SMC del subcontratista
como parte del subcontrato y también necesitan ser establecidos los medios para
la vigilancia del cumplimiento. Este último incluye la consideración de lo que debe
estar disponible para la vigilancia del cumplimiento efectivo de información SMC.

7-4 © IEEE - 2004 Versión

1.3.5. control de la interfaz
[IEEE828-98: c4s3.5]
Cuando un elemento de software de interfaz con otro elemento de software o
hardware, un cambio a cualquiera de elemento puede afectar al otro. La
planificación para el proceso de SMC considera cómo se identificarán los
elementos de interfaz y cómo se gestionen y cambios en los elementos. El papel
SMC puede ser parte de un proceso a nivel de sistema más grande para la
especificación y control de la interfaz, y puede involucrar a las especificaciones de
interfaz, planes de control de interfaz, y los documentos de control de interfaz. En
este caso, la planificación de SMC para el control de la interfaz tiene lugar dentro
del contexto del proceso a nivel de sistema. Una discusión de los resultados de las
actividades de control de interfaz se da en [Ber92: c12].
1.4. Plan de SMC [ Ber92: c7; Buc96: C3; Pau93: L2-81] Los
resultados de la planificación SMC para un proyecto dado se registran en un
Plan de Software Configuration Management (SCMP), un 'documento vivo' que
sirve como referencia para el proceso de SMC. Se mantiene (es decir,
actualizada y aprobada) según sea necesario durante el ciclo de vida del
software. En la ejecución del PGCS, normalmente es necesario desarrollar una
serie de procedimientos más detallados, subordinados que define cómo los
requisitos específicos se llevará a cabo durante las actividades del día a día.
Orientación sobre la creación y mantenimiento de un SCMP, basado en la
información producida por la actividad de planificación, está disponible de un
número de fuentes, tales como [IEEE828- 98: c4]. Esta referencia proporciona
requisitos para la información a estar contenidas en un SCMP. También define
y describe seis categorías de información SMC que se incluirán en un PGCS:
Introducción (objetivo, el alcance, los términos utilizados)
Gestión de SMC (organización, responsabilidades,
autoridades, políticas aplicables, directivas,
procedimientos)
Actividades SCM (configuración identificación,
control de la configuración, y así sucesivamente)
Horarios de SCM (coordinación con otras actividades del proyecto)
Recursos SCM (herramientas, recursos físicos y recursos humanos)
Mantenimiento PGCS
1.5. La vigilancia de la Gestión de la Configuración de
Software
[Pau93: L2-87]
Después del proceso de SMC se ha implementado, un cierto grado de vigilancia
puede ser necesario para garantizar que las disposiciones de la PGCS se llevan
a cabo correctamente (véase, por ejemplo [Buc96]). No es probable que sean
los requisitos específicos de SQA para garantizar el cumplimiento de los
procesos y procedimientos especificados SCM. Esto podría implicar una
autoridad SMC asegurar que
los que tienen asignado
responsabilidad realizar las tareas definidas SCM correctamente.
© IEEE - 2004 Versión
La autoridad de control de calidad de software, como parte de una actividad de
auditoría de cumplimiento, también puede realizar esta vigilancia.
El uso de herramientas de SCM integrados con capacidad de control de procesos puede
hacer más fácil la tarea de vigilancia. Algunas herramientas facilitan la conformidad del
proceso al tiempo que proporciona flexibilidad para el ingeniero de software para adaptar
los procedimientos. Otras herramientas de cumplir proceso, dejando el ingeniero de
software con menos flexibilidad. requisitos de vigilancia y el nivel de flexibilidad para ser
proporcionados al ingeniero de software son consideraciones importantes en la selección
de herramientas.
1.5.1. medidas SCM y la medición [Buc96: C3;
Roy98]
SCM medidas pueden ser diseñados para proporcionar información específica sobre
el producto en evolución o para proporcionar información sobre el funcionamiento del
proceso de SMC. Uno de los objetivos relacionados con el proceso de seguimiento
de SMC es descubrir las oportunidades de mejora de procesos. Las mediciones de
los procesos SCM proporcionan un buen medio para el seguimiento de la eficacia de
las actividades de SCM de manera continua. Estas mediciones son útiles para
caracterizar el estado actual del proceso, así como en proporcionar una base para
hacer comparaciones en el tiempo. El análisis de las mediciones puede producir
puntos de vista principales para procesar cambios y actualizaciones
correspondientes al SCMP.
Bibliotecas de software y las diversas posibilidades de herramientas SCM
proporcionan fuentes para extraer información acerca de las características del
proceso de SMC (así como el abastecimiento y la gestión de proyectos
información). Por ejemplo,
información sobre el tiempo requerido para llevar a cabo varios tipos de
cambios sería útil en la evaluación de los criterios para determinar qué
niveles de autoridad son óptimas para la autorización de ciertos tipos de
cambios. Se debe tener cuidado para mantener el foco de la vigilancia en
las ideas que se pueden obtener a partir de las mediciones, no en las
y
propias mediciones. La discusión de los procesos y productos de
medición se presenta en la Ingeniería de Procesos de Software KA. El
programa de medición de software se describe en el Software Engineering
Management KA.
1.5.2. En proceso de auditorías SMC [Buc96:
c15]
Las auditorías pueden ser llevadas a cabo durante el proceso de ingeniería de
software para investigar el estado actual de los elementos específicos de la
configuración o para evaluar la aplicación del proceso de SMC. En-proceso de
auditoría de SMC proporciona un mecanismo más formal para el seguimiento de los
aspectos seleccionados del proceso y puede ser coordinado con la función SQA.
Véase también la subzona 5. Auditoría del software de configuración.
7-5

Identificación 2. Configuración del software
[IEEE12207.0-96: c6s2.2]
La actividad de identificación de configuración de software identifica elementos
para ser controlados, establece esquemas de identificación de los elementos y sus
versiones, y establece las herramientas y técnicas a utilizar en la adquisición y la
gestión de elementos controlados. Estas actividades proporcionan la base para las
otras actividades de la SCM.
2.1. Los productos de identificación a ser controlado
[Ber92: c8; IEEE828-98: c4s3.1; Pau93: L2-83; Som05:
c29]
Un primer paso en el control de cambio es identificar los elementos de software que
deben ser controlados. Esto implica la comprensión de la configuración del software en
el contexto de la configuración del sistema, la selección de los elementos de
configuración de software, desarrollo de una estrategia para los elementos de software
de etiquetado y la descripción de sus relaciones, y la identificación de las líneas de base
que se utiliza, junto con el procedimiento para la adquisición de una línea de base de los
artículos .
2.1.1. configuración Software [Buc96: c4;
c6, Pre04: c27]
Una configuración de software es el conjunto de características
funcionales y físicas de software como se establece en la documentación
técnica o logrado en un producto (IEEE610.12-90). Puede ser visto como
parte de una configuración general del sistema.
2.1.2. elemento de configuración de software [Buc96: C4; C6;
Con98: c2; Pre04: c27]
Un elemento de configuración de software (SCI) es una agregación de software
designado para gestión de la configuración, y es tratado como una entidad única
en el proceso de SCM (IEEE610.12-
90). Una variedad de artículos, además del código en sí mismo, se controla típicamente
por SMC. los elementos de software con potencial para convertirse en LIC incluyen
planos, especificaciones y documentación de diseño, ensayos de materiales,
herramientas de software, la fuente y el código ejecutable, librerías de código, datos y
diccionarios de datos y documentación
para instalación, mantenimiento,
operaciones, y el uso de software.
Selección de LIC es un proceso importante en el que se debe lograr un equilibrio
entre proporcionar una visibilidad adecuada para los propósitos de control de
proyectos y proporcionar un número manejable de artículos controlados. Una lista
de criterios para la selección SCI se da en [Ber92].
2.1.3. Software relaciones entre los elementos de configuración [Con98:
c2; Pre04: c27]
Las relaciones estructurales entre los LIC seleccionados, y sus partes
constituyentes, afectan a otras actividades o tareas SCM, tales como la construcción
de software o el análisis del impacto de los cambios propuestos. seguimiento
adecuado de estas relaciones también es importante para apoyar la trazabilidad. El
diseño del esquema de identificación para el LIC debe considerar la necesidad de
asignar los elementos identificados a la estructura del software, así como
7-6
la necesidad de apoyar la evolución de los elementos de software y sus
relaciones.
2.1.4. Versión de software
[Bab86: c2]
los elementos de software evolucionan a medida que avanza un proyecto de software. UN
versión de un elemento de software es un elemento identificado y especificado en particular.
Puede ser considerado como un estado de un elemento en evolución. [Con98: c3-c5] A revisión
es una nueva versión de un elemento que está destinado a reemplazar la antigua versión
del artículo. UN
variante es una nueva versión de un elemento que se añadirá a la configuración sin
tener que reemplazar la versión antigua.
2.1.5. Base
[Bab86: c5; Buc96: C4; Pre04: c27] Una línea de base software es un
conjunto de elementos de configuración de software designadas formalmente y fijos
en un momento específico durante el ciclo de vida del software. El término también
se utiliza para referirse a una versión particular de un elemento de configuración de
software que ha sido acordado. En cualquier caso, la línea de base sólo puede
modificarse a través de procedimientos formales de control de cambios. Una línea
de base, junto con todos los cambios aprobados en la línea de base, representa la
configuración actual aprobado. líneas de base comúnmente utilizados son los,
asignados, y las líneas de base funcionales de desarrollo de productos (véase, por
ejemplo, [Ber92]). La línea de base funcional corresponde a los requisitos del
sistema revisado. La línea de base asignado corresponde a la especificación y el
software de los requisitos de software revisado
interfaz requisitos
especificación. La línea de base del desarrollo representa la configuración de
software que evoluciona a la hora seleccionada durante el ciclo de vida del software.
Cambio autoridad de esta línea de base normalmente recae principalmente en la
organización de desarrollo, pero puede ser compartida con otras organizaciones (por
ejemplo, SMC o de prueba). La línea de base del producto se corresponde con el
producto de software completado entregado para
sistema
integración. Las líneas de base que se utilizará para un proyecto dado, junto con sus
correspondientes niveles de autoridad necesaria para aprobar el cambio, se
identifican típicamente en el PGCS.
2.1.6. La adquisición de los elementos de configuración de software [Buc96:
c4]
los elementos de configuración de software se colocan bajo control SCM en
diferentes momentos; es decir, que se incorporan en una línea de base en particular
en un punto particular en el ciclo de vida del software. El evento desencadenante es
la realización de algún tipo de tarea formal de aceptación, tales como una revisión
formal. La Figura 2 caracteriza el crecimiento de artículos baselined como las
ganancias del ciclo de vida. Esta cifra se basa en el modelo de cascada para los
propósitos de la ilustración solamente; los subíndices usados ​en la figura indican
versiones de los artículos en evolución. La solicitud de cambio de software (SCR) se
describe en el tema 3.1 Solicitar, evaluar y aprobar los cambios de software.
© IEEE - 2004 Versión
 se aprueban determinados cambios, el apoyo a la aplicación de esos
requisitos Diseño Preparación de pruebas Aceptación
revisión revisión revisión cambios, y el concepto de desviaciones formales de los requisitos del
proyecto, así como exenciones de ellos. La información derivada de estas
SRS UN
SRS do SRS re actividades es útil en la medición de tráfico el cambio y la rotura, y los
SRS segundo
aspectos de reproceso.
SDD segundo SDD do
SDD UN

control de SCR de
Código UN Código segundo
3.1. Solicitar, evaluar y cambios que aprueba Software
modelos SRS
Los Los

control de SCR de
[IEEE828-98: c4s3.2; Pre04: c27; Som05: c29] El primer paso en la
planes de prueba UN planes de prueba segundo
SRS, modelos SDD gestión de los cambios a los artículos controlados es determinar qué cambios
Manual de hacer. El proceso de solicitud de cambio de software (véase la figura 5)
SCR de control de usuario UN proporciona los procedimientos formales para la entrega y el registro de las
SRS, Código SDD,
Prueba de
solicitudes de cambio, evaluar el coste potencial y el impacto de un cambio
planes de prueba

regresión DB UN
Figura 4 Adquisición de artículos
Tras la adquisición de un SCI, cambios en el elemento deben ser aprobados
formalmente como apropiado para el SCI y la línea de base que participan, como
se define en el PGCS. Después de la aprobación, el elemento se incorpora en la
línea de base software de acuerdo con el procedimiento adecuado.
propuesto, y aceptar, modificar o rechazar el cambio propuesto. Las solicitudes de
cambios en los elementos de configuración de software pueden ser originados por
cualquier persona en cualquier momento del ciclo de vida del software y pueden
incluir una propuesta de solución y la prioridad solicitada. Una fuente de
solicitudes de cambio es el inicio de una acción correctiva en respuesta a informes
de problemas. Independientemente de la fuente, el tipo de cambio (por ejemplo,
defecto o mejora) que se registra en el SCR.

2.2. software Library

[Bab86: c2; c5; Buc96: C4; IEEE828- 98: c4s3.1; Pau93: L2-82; Som01: c29] Una

biblioteca de software es una colección controlada de software y la documentación relacionada Necesidad de Investigación
Cambio preliminar
diseñado para ayudar en el desarrollo de software, uso y mantenimiento (IEEE610.12-90).

También es fundamental para las actividades de entrega y gestión de versiones de software.

Cambios indicados
Existen varios tipos de bibliotecas podrían ser utilizados, cada uno correspondiente a un para el elemento
Rechazado
informar
CCBReview
controlado Solicitante
determinado nivel de madurez del elemento software. Por ejemplo, una biblioteca de trabajo

podría apoyar la codificación y una biblioteca de soporte proyecto podría apoyar la prueba, Aprobado
SCR generada

mientras que una librería maestra podría ser utilizado para los productos terminados. Un nivel o actualizados
Asignar al
ingeniero de por lo general también existe

adecuado de control SCM (línea de base y nivel de autoridad para el cambio asociado) está software 'Ruta de emergencia'. Los

cambios pueden ser

asociado con cada biblioteca. Seguridad, en términos de control de acceso y los dispositivos de implementados con el proceso de
Programación,
SCR evalúa incompleta cambio lleva a cabo después
reserva, es un aspecto clave de la gestión de la biblioteca. Un modelo de una biblioteca de diseño, prueba, cambio
completo
completar
software se describe en [Ber92: c14]. La herramienta (s) que se utiliza para cada biblioteca debe

ser compatible con las necesidades de control de SMC para esa biblioteca, tanto en términos de
control de LIC y controlar el acceso a la biblioteca. A nivel biblioteca de trabajo, se trata de una
capacidad de gestión de código de servir a los desarrolladores, mantenedores, y SCM. Se centra
en la gestión de las versiones de los elementos de software, mientras que el apoyo a las
actividades de múltiples desarrolladores. En los niveles más altos de control, el acceso es más
restringida y SCM es el usuario principal. Se centra en la gestión de las versiones de los
elementos de software, mientras que el apoyo a las actividades de múltiples desarrolladores. En
los niveles más altos de control, el acceso es más restringida y SCM es el usuario principal. Se
centra en la gestión de las versiones de los elementos de software, mientras que el apoyo a las
actividades de múltiples desarrolladores. En los niveles más altos de control, el acceso es más
restringida y SCM es el usuario principal.
Figura 5 Flujo de un proceso de Control de Cambios Esto proporciona
una oportunidad para el seguimiento de defectos y la recolección de mediciones
de la actividad por tipo de cambio de cambio. Una vez que se recibe una SCR,
una evaluación técnica (también conocido como un análisis de impacto) se lleva a
cabo para determinar la extensión de las modificaciones que serían necesarias se
debe aceptar la solicitud de cambio. Una buena comprensión de las relaciones
entre el software (y, posiblemente, hardware) elementos es importante para esta
tarea. Por último, una autoridad establecida, en consonancia con la línea de base
afectada, el SCI involucrados, y la naturaleza del cambio, evaluará los aspectos
técnicos y de gestión de la solicitud de cambio y, o bien aceptar, modificar,
rechazar o posponer el cambio propuesto.

Estas bibliotecas son también una importante fuente de información para las
mediciones de trabajo y progreso.
3. Control de Configuración de Software
[IEEE12207.0-96: c6s2.3; Pau93: L2-84] control de la configuración
del software se ocupa de la gestión de cambios durante el ciclo de vida del
3.1.1. Junta de Control de Configuración de Software [Ber92: C9; Buc96: c9, c11;
Pre04: c27] La ​autoridad para aceptar o rechazar los cambios propuestos se
apoya con una entidad típicamente conocida como un tablero de control de
configuración (CCB). En proyectos más pequeños, esta autoridad puede residir de
manera efectiva con el líder o una persona asignada en lugar de una tabla de
varias personas. Puede haber varios niveles de autoridad cambian dependiendo

software. Cubre el proceso para determinar qué cambios hacer, la de una variedad

autoridad de

© IEEE - 2004 Versión 7-7

de criterios, tales como el carácter crítico del tema planteado y la naturaleza del
cambio (por ejemplo, impacto en el presupuesto y el calendario), o el punto
actual en el ciclo de vida. La composición de los CCBs se utilizan para un
sistema dado varía en función de estos criterios (un representante SCM
siempre estaría presente). Todos los interesados, de acuerdo al nivel de la
CCB, están representados. Cuando el alcance de la autoridad de un CCB es
estrictamente de software, que se conoce como una Junta de Control de
Configuración de Software (SCCE). Las actividades de la CCB son típicamente
sujetos a auditoría o revisión de calidad del software.
3.1.2. proceso de solicitud de cambio de software [Buc96:
c9, c11; Pre04: c27]
Una solicitud de cambio de software eficaz (SCR) proceso requiere el uso de
herramientas de apoyo y los procedimientos que van desde los formularios en papel y
un procedimiento documentado para una herramienta electrónica para solicitudes de
cambio de origen, hacer cumplir el flujo del proceso de cambio, la captura de
decisiones CCB, y presentación de informes proceso de cambio información. Un
vínculo entre esta capacidad de la herramienta y el sistema de notificación de
problema puede facilitar el seguimiento de soluciones para problemas detectados.
descripciones de cambio de proceso y las formas de apoyo (información) se dan en
una variedad de referencias, por ejemplo [Ber92: c9].
3.2. Cambios en el software de aplicación
[Bab86: C6; Ber92: C9; Buc96: c9, c11; IEEE828- 98: c4s3.2.4;
Pre04: c27; Som05: c29] SCRs aprobados se implementan utilizando los
procedimientos de software definidos de acuerdo con los requisitos de
programación aplicables. Puesto que un número de SCRs aprobados podría
implementarse de forma simultánea, es necesario proporcionar un medio para
el seguimiento que SCRs se incorporan en las versiones de software
particulares y líneas de base. Como parte del cierre del proceso de cambio,
completaron cambios pueden someterse a auditorías de configuración y
verificación de la calidad del software. Esto incluye asegurarse de que se han
realizado cambios aprobados. El proceso de solicitud de cambio descrito
anteriormente típicamente documentará el SCM (y otra) información de
aprobación para el cambio.
La implementación real de un cambio se apoya en la biblioteca
herramientacapacidades, que proporcionan versión
gestión y apoyo repositorio de código. Como mínimo, estas herramientas
proporcionan capacidades de control de versiones y Registro de entrada / salida
asociados. herramientas más potentes pueden apoyar el desarrollo paralelo y
entornos distribuidos geográficamente. Estas herramientas se pueden manifestar
como aplicaciones especializadas separadas bajo el control de un grupo de SMC
independiente. También pueden aparecer como una parte integrada del entorno
de la ingeniería de software. Por último, pueden ser tan elemental como un
sistema de control de cambios rudimentaria provisto de un sistema operativo.
3.3. Desviaciones y renuncias
[Ber92: c9; Buc96: c12]
Las limitaciones impuestas a un esfuerzo de ingeniería de software o las
especificaciones producidas durante el desarrollo
7-8
actividades podrían contener disposiciones que no pueden ser satisfechas en
el punto designado en el ciclo de vida. Una desviación es una autorización
para salir de una disposición antes del desarrollo del artículo. La renuncia es
una autorización para usar un objeto, a raíz de su desarrollo, que se aparta de
la provisión de alguna manera. En estos casos, un proceso formal se utiliza
para obtener la aprobación de las desviaciones de las renuncias, o de, las
disposiciones.
4. Configuración de software de contabilidad Estado
[IEEE12207.0-96: c6s2.4; Pau93: L2-85; Pre04: c27; Som05: c29]
Software de contabilidad estado de configuración (SCSA) es el registro y
comunicación de la información necesaria para la gestión eficaz de la
configuración del software.
4.1. Software de información de estado de configuración
[Buc96: c13; IEEE828-98: c4s3.3] Los diseños de actividad SCSA y
opera un sistema para la captura y presentación de la información necesaria a
medida que avanza el ciclo de vida. Al igual que en cualquier sistema de
información, el
información de estado de configuración para ser administrado para las
configuraciones cambiantes deben ser identificados, recogidos, y mantenido.
Diversa información y las mediciones son necesarias para apoyar el proceso de
SMC y para cumplir con el estado de configuración de informes necesidades de
gestión, ingeniería de software, y otras actividades relacionadas. Los tipos de
información disponibles incluyen la identificación de la configuración aprobada,
así como la identificación y el estado actual implementación de los cambios,
desviaciones, y las renuncias. Una lista parcial de los elementos de datos
importantes se da en [Ber92: c10].
Algún tipo de apoyo herramienta automatizada es necesaria para llevar a cabo la
recogida de datos SCSA y las tareas de informes. Esto podría ser una capacidad de
base de datos, o podría ser una herramienta independiente o una capacidad de un
entorno de herramientas más amplio e integrado.
4.2. Informes de estado de configuración de software
[Ber92: c10; Buc96: c13] la información registrada puede ser
utilizado por varios elementos de organización y de proyectos, incluyendo el
equipo de desarrollo, el equipo de mantenimiento, gestión de proyectos y
actividades de calidad de software. Informes pueden tomar la forma de consultas
ad hoc para responder a preguntas específicas o la producción periódica de
informes pre-diseñados. Parte de la información producida por la actividad
contable de estado durante el curso del ciclo de vida podría convertirse en los
registros de control de calidad.
Además de informar el estado actual de la configuración, la información
obtenida por el SCSA puede servir como base para varias mediciones de
interés a la gestión, el desarrollo, y SMC. Los ejemplos incluyen el número
de solicitudes de cambio por SCI y el tiempo medio necesario para
ejecutar una solicitud de cambio.
© IEEE - 2004 Versión

Auditoría 5. Configuración del software
[IEEE828-98: c4s3.4; IEEE12207.0-96: c6s2.5; Pau93:
L2-86; Pre04: c276c27]
Una auditoría de software es una actividad realizada para evaluar de forma
independiente la conformidad de los productos y procesos de software aplicables
a reglamentos, normas, directrices, planes,
y procedimientos (IEEE1028-97). Las auditorías son
llevado a cabo de acuerdo con un proceso bien definido que consiste en diversas
funciones y responsabilidades auditor. En consecuencia, cada auditoría debe ser
cuidadosamente planificado. Una auditoría puede requerir una serie de personas para
llevar a cabo una variedad de tareas durante un período relativamente corto de tiempo.
Herramientas para apoyar la planificación y realización de una auditoría puede facilitar
enormemente el proceso. Orientación para la realización de las auditorías de software está
disponible en varias referencias, como [Ber92: c11; Buc96: c15] y (IEEE1028-97).
La actividad de auditoría de configuración de software determina la medida en
que un elemento satisface las características funcionales y físicas requeridas.
auditorías informal de este tipo puede llevarse a cabo en puntos clave del ciclo
de vida. Hay dos tipos de auditorías formales podrían ser requeridos por el
contrato de gobierno (por ejemplo, en los contratos que garanticen software
crítico): la Auditoría funcional de configuración (FCA) y la configuración de
auditoría física (PCA).
La conclusión con éxito de
estas auditorías pueden ser un requisito previo para el establecimiento de la línea
base del producto. Buckley [Buc96: c15] contrasta los efectos de la FCA y PCA
en contextos de hardware frente de software, y recomienda una cuidadosa
evaluación de la necesidad de un software de FCA y PCA antes de realizar ellos.
5.1. Software de Auditoría de Configuración Funcional
El propósito de la FCA software es para asegurar que el elemento de software
auditado es consistente con sus especificaciones de gobierno. La salida de las
actividades de verificación y validación de software es un insumo clave para esta
auditoría.
5.2. Auditoría de Configuración física de software
El propósito de la auditoría configuración física de software (PCA) es
asegurar que el diseño y la referencia
documentación es consistente con el producto de software como incorporado.
5.3. En proceso de auditorías de una línea de base del software
Como se mencionó anteriormente, las auditorías pueden llevarse a cabo durante el proceso
de desarrollo para investigar el estado actual de los elementos específicos de la
configuración. En este caso, una auditoría se podría aplicar a los elementos de línea de
base de la muestra para asegurar que el rendimiento es consistente con las
especificaciones o para asegurar que la documentación de la evolución sigue siendo
compatible con el elemento de referencia en desarrollo.
6. El software de administración de lanzamientos y Entrega
[IEEE12207.0-96: c6s2.6]
El término “liberación” se utiliza en este contexto para referirse a la distribución de
un elemento de configuración de software fuera de la actividad de desarrollo. Esto
incluye versiones internas en las
© IEEE - 2004 Versión
así como la distribución a los clientes. Cuando diferentes versiones de un elemento
de software están disponibles para la entrega, tales como versiones para diferentes
plataformas o versiones con diferentes capacidades, con frecuencia es necesario
volver a crear versiones específicas y empaquetar los materiales adecuados para la
entrega de la versión. La biblioteca de software es un elemento clave en la
realización de tareas de liberación y entrega.
6.1. Edificio de software
[Bab86: C6; Som05: c29] edificio Software es la actividad de la
combinación de las versiones correctas de los elementos de configuración de
software, utilizando los datos de configuración apropiados, en un programa
ejecutable para la entrega a un cliente u otro receptor, tal como la actividad de
pruebas. Para sistemas con hardware o firmware, el programa ejecutable se
entrega a la actividad de la construcción del sistema. Construir instrucciones de
asegurar que las medidas adecuadas se toman construcción y en la secuencia
correcta. Además de la creación de software para los nuevos lanzamientos, por lo
general es también necesaria para SMC para tener la capacidad de reproducir
versiones anteriores para la recuperación, pruebas, mantenimiento o efectos
adicionales de liberación.
El software se construye a partir de versiones particulares de herramientas de apoyo,
tales como compiladores. Puede ser que sea necesario reconstruir una copia exacta de
un elemento de configuración de software previamente construida. En este caso, las
herramientas de apoyo y las instrucciones de construcción asociados deben estar bajo el
control de SMC para garantizar la disponibilidad de las versiones correctas de las
herramientas. Una capacidad de herramienta es útil para la selección de las versiones
correctas de los elementos de software para un entorno de destino dado y para
automatizar el proceso de construcción del software de las versiones seleccionadas y
datos de configuración apropiados. Para grandes proyectos con el desarrollo paralelo o
desarrollo distribuido
ambientes, esta capacidad
herramienta es
necesario. Más entornos de ingeniería de software
proporcionar esta capacidad. Estas herramientas varían en complejidad desde que
requiere el ingeniero de software para aprender un lenguaje de programación especializada
a los enfoques orientados a gráficos que ocultan gran parte de la complejidad de una
instalación de acumulación “inteligente”.
El proceso de construcción y los productos son a menudo objeto de verificación de la
calidad del software. Las salidas del proceso de construcción podrían ser necesarios para
referencia futura y pueden convertirse en los registros de control de calidad.
6.2. Gestión de la Entrega de Software
[Som05: c29]
Software gestión de la liberación engloba el
la identificación, el empaquetado, y la entrega de los elementos de un producto, por
ejemplo, el programa ejecutable, documentación, notas de liberación, y datos de
configuración. Teniendo en cuenta que los cambios de producto pueden producirse de
manera continua, una preocupación por la gestión de la liberación es determinar cuándo
deben emitir un comunicado. La gravedad de los problemas abordados por la liberación
y mediciones de las densidades de fallos de versiones anteriores afecta esta decisión.
(Som01) La tarea de envasado debe identificar qué elementos del producto han de ser
entregadas, y luego seleccione el
7-9
variantes correctas de esos elementos, teniendo en cuenta la aplicación prevista Los sistemas. Un ejemplo sería un caso en el que se requiere el proveedor de
del producto. La información que documenta el contenido físico de un comunicado notificar a un cliente de problemas recientemente denunciados.
es conocido como un documento de descripción de versión. Las notas de
publicación suelen describir nuevas capacidades,
Se necesita una capacidad de herramienta para apoyar estas funciones de
problemas conocidos, y la plataforma
gestión de versiones. Es útil tener una relación con la capacidad de herramienta
requisitos necesarios para el funcionamiento adecuado del producto. El paquete que
de apoyo al proceso de solicitud de cambio con el fin de asignar los contenidos
se lanzará también contiene instrucciones de instalación o actualización. Este último
de liberación de los SCR que se han recibido. Esta capacidad herramienta
puede ser complicado por el hecho de que algunos usuarios actuales podrían tener
también puede mantener información sobre diversas plataformas de destino y en
versiones que son varias las viejas versiones. Por último, en algunos casos, la
diversos entornos de clientes.
actividad de gestión de versiones podrían ser necesarias para realizar un seguimiento
de la distribución del producto a diferentes clientes o de destino

7-10 © IEEE - 2004 Versión

 C2, C5

[Bab86]
c6 c6 c5 c2

7-11

[Ber92]
c11 c10 c10 C9 C9 C9 C9 c14 c8 c7 c12 c13 c15 c7 c7 c5 c4
* *

c9, c11 c9, c11 c9, c11 c4, c6 c4, c6

[Buc96]
c15 c13 c13 c12 c4 c4 c4 c15 c3 c3 c11 c3 c3 c2
*

[Con98]
c2 c2 c6

c3, App A

[Dar9 0 ]
c2 c2

c4s1, c4s2.3

[IEEE828-98]
c4s4,
c4s3.2.4
c4s3.4 c4s3.3 c4s3.2 c4s3.1 c4s3.1 c4s3.5 control c4s2.1
recursos
c4 c4

[IEEE12207.0-96]
c6s2.6 c6s2.5 c6s2.4 c6s2.3 c6s2.2
6.2.1

[Mid9 7 ]
*

[Moo9 8 ]
*

[Pau9 3 ]
L2-86 L2-85 L2-84 L2-82 L2-83 L2-81
medidas

c26, c27

[Pre04]
c27 c27 c27 proceso c27 c27 c27 Las c27
relaciones

188-202,

[Roy98]
*

[Som0 5 ]
c29 c29 c29 c29 tablero c29 La organización
 1996 // ISO / IEC12207: 1995, Implementación de la industria Int. Std.
R ECOMMENDED R EFERENCIAS PARA SMC ISO / IEC 12207: 95, Norma para Tecnología de la
Información-Software Procesos del ciclo de vida, vol. IEEE,
[Bab86] WA Babich, Configuración del software 1996.
Gestión, coordinación de la productividad del equipo:
[Mid97] AK Midha, "Configuración del software
Addison-Wesley, 1986. [Ber92] HR
Gestión para el siglo 21" Bell Labs Technical Journal, vol. 2, ISS. 1,
Berlack, Configuración del software
154-165, Winter, 1997 [Moo98] JW Moore, Estándares de Ingeniería de
Administración. Nueva York: John Wiley & Sons, 1992. [Buc96]
Software, Plan de trabajo de un usuario. Los Alamitos, CA: IEEE Computer
FJ Buckley, Configuración de Aplicación Society, 1998.
Gestión: hardware, software y firmware, Segunda ed. Los Alamitos, CA:
IEEE Computer Society Press,
[Pau93] MC Paulk y otros, "Prácticas clave del Modelo de Madurez de la
1996.
Capacidad, Versión 1.1," Instituto de Ingeniería de Software de la
[Con98] R. Conradi y B. Westfechtel, "Modelos de versión para
Universidad Carnegie Mellon, Informe Técnico CMU / SEI-93-TR-025,
Gestión de la Configuración de Software," ACM Computing
1993 [Pre04] RS Pressman, Ingeniería de Software: Enfoque para
Surveys, vol. 30, ISS. 2, junio, 1998 [Dar90] SA Dart, Espectro de
profesionales, ed Sexto: McGraw-Hill, 2004. [Roy98] W. Royce, Software
funcionalidad en Sistemas de Gestión de la Configuración. Carnegie
de gestión de proyecto, un Estados Marco: Addison-Wesley, 1998.
Mellon University: Software Engineering Institute, 1990. [IEEE828-98]
[Som05] I. Sommerville, Ingeniería de software, Séptima edición:
IEEE Std 828 a 1.998, Norma IEEE para los planes de gestión de
Addison-Wesley, 2005.
configuración de software: IEEE, 1998. [IEEE12207.0-96]

IEEE / EIA 12207.0-

7-12 © IEEE - 2004 Versión

 (Hoe02) A. vd Hoek ", Amarillo Gestión de la Configuración
UN PÉNDICE A. L LISTA DE F ás R EADINGS Páginas," 2002, disponible a
http://www.cmtoday.com/yp/configuration_management.ht ml
(Bab86) WA Babich, Configuración del software
Gestión, coordinación de la productividad del equipo:
(Hum89) W. Humphrey, Gestión del proceso de software:
Addison-Wesley, 1986. (Ber92) HR
Massachusetts: Addison Wesley, 1989. (Pau95) MC Paulk y al, El Modelo
Berlack, Configuración del software
de Madurez de la Capacidad, Directrices para la mejora del proceso de
Administración. Nueva York: John Wiley & Sons, 1992. (Ber97)
software.
EH Bersoff, "Elementos de Software Reading, Massachusetts: Addison-Wesley, 1995. (Som01a)
Gestión de la Configuración ", en Ingeniería de software, M. Dorfman y RH
I. Sommerville, "Configuración del software
Thayer, Eds. Los Alamitos, CA: IEEE Computer Society Press, 1997.
Gestión ", presentado en CISE SMC-6 Taller, Berlín, 2001
(Buc96) FJ Buckley,
Configuración de Aplicación
Guía de normativas (USNRC1.169-97) USNRC 1.169, "Planes de Gestión de
Gestión: hardware, software y firmware, Segunda ed. Los Alamitos, CA:
la configuración del software del ordenador digital que se utiliza en sistemas
IEEE Computer Society Press,
de seguridad de las centrales nucleares", presentado en la Comisión de
1996.
Regulación Nuclear, Washington DC, 1997
(ElE98) K. El-Emam y otros, "SPICE, La Teoría y Práctica de Software de
la mejora de procesos y la determinación de la capacidad", presentado en
(Vin88) J. Vicente, A. Waters y J. Sinclair, Software Quality Assurance:
la IEEE Computer Society, Los Alamitos, CA, 1998 (Est95)
Práctica y Implementación.
Englewood Cliffs, Nueva Jersey: Prentice-Hall, 1988. (Whi91) D. Whitgift, Métodos
J. Estublier, "Software Configuración
y herramientas para la gestión de la configuración del software. Chichester,
Gestión ", presentado en CISE SCM-4 y SCM-5 Talleres Papeles
Inglaterra: John Wiley & Sons, 1991.
seleccionados, Berlín, 1995 (Gra92) RB Grady, Software Metrics prácticas
para la gestión de proyectos y gestión de procesos: Prentice Hall,
Englewood Cliffs, NJ 07632, 1992.

© IEEE - 2004 Versión 7-13

 1996.
UN PÉNDICE B. L LISTA DE S NORMAS (IEEE12207.1-96) IEEE / EIA 12207,1-1996, Industria
Implementación de Int. Std. ISO / IEC 12207: 95, Norma para Tecnología de la
Información-Software Procesos del ciclo de vida
(IEEE730-02) IEEE Std 730 a 2.002, Norma IEEE para Planes de - Los datos del ciclo de vida: IEEE, 1996.
Aseguramiento de Calidad de Software: IEEE, 2002. (IEEE828-98) IEEE Std (IEEE12207.2-97)
IEEE / EIA 12.207,2-1.997, Industria
828-1998, Norma IEEE para los planes de gestión de configuración de
Implementación de Int. Std. ISO / IEC 12207: 95, Norma para Tecnología de la
software: IEEE, 1998. (IEEE1028-97) IEEE Std 1028-1997 (R2002), Norma Información-Software Procesos del ciclo de vida
IEEE para software comentarios: IEEE, 1997. (IEEE12207.0-96) - Implementación. consideraciones: IEEE, 1997. (ISO15846-98) ISO / IEC
TR 15846: 1998, tecnología Información
IEEE / EIA 12207.0- - Ciclo de vida del software Procesos -
1996 // ISO / IEC12207: 1995, Implementación de la industria Int. Std. Gestión de la Configuración. Ginebra, Suiza ,: ISO e IEC, 1998.
ISO / IEC 12207: 95, Norma para Tecnología de la
Información-Software Procesos del ciclo de vida, vol. IEEE,

7-14 © IEEE - 2004 Versión

 do CAPÍTULO 8

S OFTWARE mi NGENIERÍA METRO GESTIÓN

UN CRONYM

PMBOK Guía a el proyecto No es disminuir la importancia de la gestión de la organización.

administración Cuerpo de
Conocimiento Desde el enlace a las disciplinas relacionadas-obviamente-gestión es
SQA Software de Control de Calidad importante, que se describirá con más detalle que en las otras
descripciones KA. Aspectos de la gestión de la organización son
yo INTRODUCCIÓN importantes en términos de su impacto en la ingeniería de software,
administración de políticas, por ejemplo: las políticas y normas de
Software de gestión de ingeniería se puede definir como la aplicación
organización constituyen el marco en el que se lleva a cabo la ingeniería
de administración las actividades de planificación,
de software. Estas políticas pueden necesitar ser influenciado por las
coordinar, medir, monitorear, controlar e informar a garantizar que el
exigencias de un desarrollo efectivo y mantenimiento de software, y una
desarrollo y mantenimiento de software es sistemático, disciplinado, y se
serie de políticas específicas de software ingeniería- puede ser necesario
cuantificó (IEEE610.12-90).
establecer una gestión eficaz de la ingeniería de software a nivel de
organización. Por ejemplo, las políticas son generalmente necesarios para
Por tanto, el software de administración de Ingeniería KA se refiere a la establecer
gestión y medición de la ingeniería de software. Si bien la medición es un
aspecto importante de todos los Kas, es aquí donde se presenta el tema procesos específicos de toda la organización o
de los programas de mediciones. procedimientos para tareas tales como el diseño de ingeniería de software,
implementar, estimar, rastreo, y
la presentación de informes. Este tipo de políticas son esenciales para una gestión
Si bien es cierto que, en cierto sentido, debería ser posible para gestionar la
eficaz de ingeniería de software a largo plazo, mediante el establecimiento de una
ingeniería de software de la misma manera que cualquier otro proceso
(complejo), hay aspectos específicos de los productos de software y los base consistente sobre la cual analizar los resultados anteriores y realizar

procesos del ciclo de vida del software que complican eficaz de gestión-solo mejoras, por ejemplo. Otro aspecto importante de la gestión de personal de

algunos de los cuales son los siguientes:
La percepción de los clientes es tal que a menudo hay una falta de
apreciación de la complejidad inherente a la ingeniería de software,
particularmente en relación con el impacto de los cambios en los
requisitos.
Es casi inevitable que la ingeniería de software propios procesos
generará la necesidad de requisitos nuevos o modificados cliente.
Como resultado, el software se construye a menudo en un proceso iterativo en lugar de una
secuencia de tareas cerradas.
La ingeniería de software incorpora necesariamente aspectos de la
creatividad y la disciplina, manteniendo un equilibrio adecuado entre los
dos es a menudo difícil. El grado de novedad y complejidad del software es
a menudo extremadamente alta.
Hay una rápida tasa de cambio en la tecnología subyacente. Con
gestión es: políticas y procedimientos para la contratación, la capacitación y
motivación del personal, y orientación para el desarrollo profesional son
importantes no sólo a nivel de proyecto, sino también para el éxito a largo plazo de
una organización. el personal de ingeniería de software pueden presentar gestión
de la formación o el personal único
retos (para ejemplo,
el mantenimiento de la moneda en un contexto donde la tecnología
subyacente sufre un cambio continuo y rápido). gestión de la comunicación
también se menciona a menudo como una, pero se pasa por alto los aspectos
principales de la actuación de los individuos en un campo en el que es
necesaria la comprensión precisa de las necesidades del usuario y de las
necesidades complejas y diseños. Por último, la gestión de carteras, que es la
capacidad de tener una visión de conjunto, no sólo del conjunto de software
en fase de desarrollo, sino también del software ya está en uso en una
organización,
es necesario.
Por otra parte, la reutilización de software es un factor clave en el mantenimiento
y la mejora de la productividad y la competitividad. reutilización efectiva requiere

Respeto una visión estratégica que refleja la energía y los requisitos de esta técnica única.
Además de comprender los aspectos de gestión que son influenciados de forma
a la ingeniería de software, administración
las actividades suceden a tres niveles: de organización y única por el software, los ingenieros de software deben tener algún conocimiento

la gestión de infraestructuras, gestión de proyectos, y la planificación y el de los aspectos más generales, incluso en los primeros cuatro años después de

control del programa de medición. Los dos últimos se tratan en detalle en esta la graduación que se apunta en la Guía.

descripción KA. Sin embargo, esta

© IEEE - 2004 Versión 8-1

La cultura organizacional y el comportamiento, y la gestión de la empresa funcional
en términos de adquisiciones, gestión de la cadena de suministro, comercialización,
ventas y distribución, todos tienen una influencia, aunque sea indirectamente, en
procesos de ingeniería de software de una organización.
Correspondiente a este KA es la noción de gestión de proyectos, como “la
construcción de artefactos de software útiles” es normalmente administrado en
forma de programas (tal vez) de los proyectos individuales. En este sentido,
nos encontramos con un amplio apoyo en la Guía para la Gestión de
Proyectos (PMBOK) (PMI00), que a su vez incluye la siguiente dirección de
proyectos de Kas: gestión de proyectos de integración, gestión del alcance del
proyecto, la gestión del tiempo de proyectos, gestión de costos del proyecto,
gestión de la calidad del proyecto, gestión de recursos humanos del proyecto,
y el proyecto
gestión de las comunicaciones. Es evidente que todos estos temas tienen
relación directa con el software de administración de Ingeniería KA. Para
intentar duplicar el contenido de la Guía PMBOK aquí sería imposible e
inadecuado. En su lugar, se sugiere que el lector interesado en la gestión
de proyectos más allá de lo
es específico de software
proyectos de ingeniería consultan la propia PMBOK. La gestión de proyectos también
se encuentra en las disciplinas relacionadas con el capítulo de Ingeniería de Software.
La Dirección de Ingeniería de Software KA consiste tanto en el proceso de
gestión de proyectos de software, en sus primeros cinco sub-áreas, y la
medición de la ingeniería de software en la última subzona. Si bien estos dos
temas son a menudo considerados como separados, y de hecho lo hacen
poseen muchos aspectos únicos, su estrecha relación ha llevado a su
tratamiento combinado en este KA. Por desgracia, una percepción común de
la industria del software es que ofrece productos finales, por encima del
presupuesto, y de mala calidad e incierto
funcionalidad. La medición-informada
-gestión de un principio asumido de cualquier disciplina de ingeniería
cierto-puede ayudar a girar alrededor de esta percepción. En esencia, la
gestión sin medición, cualitativo y cuantitativo, sugiere una falta de rigor, y
la medición sin gestión sugiere una falta de propósito o contexto. De la
misma manera, sin embargo, la gestión y la medición sin conocimiento
experto es igualmente ineficaz, por lo que debemos tener cuidado de
evitar un excesivo énfasis en los aspectos cuantitativos de Gestión de
Ingeniería de Software (SEM). La gestión eficaz requiere una combinación
de números y experiencia.
Las siguientes definiciones de trabajo se adoptan aquí:
Proceso de gestión se refiere a las actividades que se llevan a cabo
con el fin de garantizar que los procesos de ingeniería de software se
llevan a cabo de una manera consistente con las políticas, objetivos y
normas de la organización.
Medición se refiere a la asignación de valores y etiquetas a los
aspectos de ingeniería de software (productos, procesos y recursos
definidos por [Fen98]) y los modelos que se derivan de ellos, si estos
8-2
modelos se desarrollan utilizando estadística, experto
conocimiento, u otras técnicas. Los proyectos de ingeniería de
gestión de sub-áreas de software hace un amplio uso de
la ingeniería de software
sub-área de medición.
No inesperadamente, este KA está estrechamente relacionado con otros
en la Guía para el SWEBOK, y la lectura de las siguientes descripciones
KA en conjunción con éste sería particularmente útil.
Requisitos de Software, donde algunas de las actividades a realizar
durante la fase de definición de Iniciación y alcance del proyecto se
describen
Gestión de la Configuración de Software, ya que esto se refiere a la
identificación, el control, la contabilidad de estado, y la auditoría de la
configuración de software, junto con la administración de versiones de software
y entrega
Proceso de Ingeniería de Software, porque los procesos y proyectos están
estrechamente relacionados (esto KA también describe el proceso y la medición
del producto)
La calidad del software, como la calidad es constantemente un objetivo de la gestión y
es un objetivo de muchas actividades que debe ser administrado
segundo REAKDOWN DE T OPICS PARA S OFTWARE mi NGENIERÍA
METRO GESTIÓN
A medida que la Ingeniería de Software de Gestión de KA es visto aquí como
un proceso organizativo que incorpora la noción de proceso y gestión de
proyectos, hemos creado una crisis que es a la vez basado en temas y la vida
basadas en el ciclo. Sin embargo, la base principal de la ruptura de nivel
superior es el proceso de gestión de un proyecto de ingeniería de software.
Hay seis subzonas. Los primeros cinco subzonas siguen en gran medida la
IEEE / EIA Proceso de Gestión de 12207. Los seis sub-áreas son:
Iniciación y definición del alcance, que trata de la decisión de iniciar un
proyecto de ingeniería de software
la planificación de proyectos de software, las cuales aborda las actividades
realizadas para prepararse para una ingeniería de software con éxito, desde
una perspectiva de gestión
promulgación de proyectos de software, que se ocupa de las actividades de gestión de la
ingeniería de software generalmente aceptados que se producen durante la ingeniería
de software
Revisión y evaluación, que se refieren a la seguridad de que el software es
satisfactoria
Cierre, que se ocupa de las actividades posteriores a la finalización de un proyecto de
ingeniería de software
medición de la ingeniería de software, que se ocupa del desarrollo y la
aplicación efectiva de los programas de medición
en ingeniería de software
organizaciones (IEEE12207.0-96) El desglose de mantenimiento de
software KA de temas se muestra en la Figura 1.
© IEEE - 2004 Versión
 Ingeniería de software
administración

Iniciación y Definición Proyecto de software Proyecto de software Revisión y SW Ingeniería de

Cierre
del Alcance Planificación Promulgación Evaluación medición

La determinación y la La determinación de Establecer y

Implementación de Cierre la
negociación de los Planificación de procesos satisfacción de los mantener el Plan
Planes determinación
requisitos requisitos Compromiso
Medición El
Revisión y proceso de
Análisis de determinar Implementación de Actividades de
Evaluación del medición
viabilidad entregables Proveedores Gestión cierre
desempeño
de contratos de

Proceso de medida
Proceso para el Esfuerzo, Planificar y Realizar el
examen y revisión Estimación de Costos proceso de
de los requisitos medición

Asignación de evaluar Medición

Process monitor
recursos

Gestión de Proceso de control

riesgos

Gestión de la
informes
calidad

Gestión del plan

Figura 1 Desglose de los temas de la Ingeniería de Software de Gestión de KA

Figura 1 Desglose de los temas de la Ingeniería de Software de Gestión de KA

métodos de software de exigencia para la obtención de requisitos (por ejemplo, de

1. Iniciación y Definición del Alcance
El enfoque de este conjunto de actividades se encuentra en la determinación
efectiva de los requisitos de software a través de diversos métodos de obtención y
la evaluación de la viabilidad del proyecto a partir de una variedad de puntos de
vista. Una vez que se ha establecido la viabilidad, la tarea pendiente dentro de
este proceso es la especificación de requisitos de validación y procedimientos de
cambio (véase también los requisitos de software KA).
observación), el análisis (por ejemplo, el modelado de datos, de casos de uso de
modelado), especificación y validación (por ejemplo, creación de prototipos) deben
ser seleccionados y aplicados, teniendo en cuenta las diversas perspectivas de los
interesados . Esto lleva a la determinación del alcance del proyecto, objetivos y
limitaciones. Esto es siempre una actividad importante, ya que establece los límites
visibles para el conjunto de tareas que se están realizando, y es particularmente
cierto cuando la novedad de la empresa es alta. Información adicional se puede
encontrar en los requisitos de software KA.

1.1. La determinación y la negociación de los requisitos

[Dor02: v2c4; Pfl01: C4; Pre04: c7; Som05: c5]

© IEEE - 2004 Versión 8-3

1.2. Factibilidad análisis (técnico, Operacional,
financiera, social / política)
[Pre04: C6; Som05: c6]
Los ingenieros de software? Se debe asegurar que la capacidad y los recursos
necesarios están disponibles en forma de personas, experiencia, instalaciones,
infraestructura y apoyo (ya sea interna o externamente) para asegurar que el
proyecto puede ser completado con éxito en una manera oportuna y rentable
(utilizando, por ejemplo, una matriz requisito-capacidad). A menudo, esto
requiere un poco de 'bola del parque' estimación de esfuerzo y costo basado
en métodos adecuados (por ejemplo, técnicas analogía expertos informados).
1.3. Proceso para el examen y la revisión de los requisitos
Dada la inevitabilidad del cambio, es vital que se llegue a un acuerdo entre las
partes interesadas en este punto temprano como a los medios por los cuales el
alcance y requisitos han de ser examinado y revisado (por ejemplo, a través de
procedimientos de gestión de cambios acordados). Esto implica claramente
ese alcance y
requisitos no serán 'inamovibles', pero pueden y deben ser revisados ​en puntos
predeterminados como se desarrolla el proceso (por ejemplo, en las revisiones
de diseño, revisiones de gestión). Si se aceptan los cambios, entonces algún tipo
de análisis de trazabilidad y análisis de riesgos (ver tema 2..5 Gestión de riesgos)
se debe utilizar para determinar el impacto de esos cambios. Un enfoque de
cambio administrado también debe ser útil cuando se trata de tiempo para
revisar el resultado del proyecto, ya que el alcance y los requisitos deben
servir de base para la evaluación del éxito. [Som05: c6] Véase también el
control de la configuración de software
sub-área de El software
Configuración KA Gestión.
2. Planificación de proyectos de software
El proceso de planificación iterativa es informado por el alcance y los
requisitos y por el establecimiento de viabilidad. En este punto, los
procesos del ciclo de vida del software se evalúan y el más apropiado
(dada la naturaleza del proyecto, su grado de novedad, su complejidad
funcional y técnica, sus requisitos de calidad, etc.) se selecciona. En su
caso, el proyecto en sí está prevista a continuación, en forma de una
descomposición jerárquica de
Tareas, el asociado
entregables de cada tarea se especifican y se caracterizaron en términos
de calidad y otros atributos de acuerdo con los requisitos establecidos, y el
esfuerzo detallada, horario, y se llevaron a cabo la estimación de costos.
Los recursos se asignan entonces a las tareas a fin de optimizar la
productividad del personal (a nivel individual, equipo, y los niveles de
organización), el equipo y la utilización de materiales, y la adhesión a
horario. detallado de gestión de riesgos se lleva a cabo y el 'perfil de riesgo'
del proyecto se discute entre, y aceptado por todas las partes interesadas
pertinentes. procesos integrales de gestión de la calidad del software se
determinan como parte del proceso de planificación en forma de
procedimientos y responsabilidades para la garantía de la calidad del
software, verificación y validación, opiniones y auditorías (ver la calidad KA
Software). Como un proceso iterativo,
8-4
curso de gestión de planes, revisión y revisión también se expresan con claridad y estuvieron
de acuerdo.
2.1. Planificación de procesos
La selección del modelo de ciclo de vida del software apropiado (por ejemplo,
espiral, prototipado evolutivo) y la adaptación e implementación
de los procesos del ciclo de vida del software apropiadas se llevan a cabo a la
luz del alcance y los requisitos del proyecto en particular. También se
seleccionan los métodos y herramientas pertinentes. [Dor02: v1c6, v2c8;
Pfl01: c2; Pre04: c2; Rei02: c1, c3, c5; Som05: C3; Tha97: c3] A nivel de
proyecto, métodos y herramientas apropiadas se utilizan para descomponer el
proyecto en tareas, con entradas asociadas, salidas y condiciones de
finalización (por ejemplo, el trabajo de estructura descomposición). [Dor02:
v2c7; Pfl01: C3; Pre04: c21; Rei02: c4, c5; Som05: C4; Tha97: c4, c6] Esto a
su vez influye en las decisiones sobre la estructura del programa y
organización de alto nivel del proyecto.
2.2. determinar entregables
El producto (s) de cada tarea (por ejemplo, el diseño arquitectónico, informe de
inspección) se especifican y se caracterizó. [Pfl01: c3; Pre04: c24; Tha97: c4] Las
oportunidades para reutilizar los componentes de software de los desarrollos
anteriores o para utilizar fuera de la plataforma de productos de software se
evalúan. El uso de software de terceros y adquiridos se planifican y se
seleccionan los proveedores.
2.3. Esfuerzo, horario, y la estimación de costos
Sobre la base de la descomposición de tareas, entradas y salidas, el rango
esperado esfuerzo requerido para cada tarea se determina utilizando un modelo de
estimación calibrada en base a datos históricos tamaño de esfuerzo donde
disponibles y pertinentes, u otros métodos como el juicio de expertos.
dependencias de tareas se establecen y posibles cuellos de botella se identifican
mediante métodos adecuados (por ejemplo, análisis de ruta crítica). Los cuellos de
botella se resuelven cuando sea posible, y el calendario esperado de tareas con
proyectado horas de inicio, duración, y los tiempos finales es producida (por
ejemplo, diagrama PERT). necesidades de recursos (personas,
herramientas) se traducen en costos
estimados. [Dor02: v2c7; Fen98: c12; Pfl01: C3; Pre04: c23, c24; Rei02:
C5, C6; Som05: c4, c23; Tha97: c5] Esta es una actividad altamente
iterativo que debe ser negociado y revisado hasta que se alcanza un
consenso entre los interesados ​afectados (principalmente de ingeniería y
gestión).
2.4. Asignación de recursos
[Pfl01: c3; Pre04: c24; Rei02: c8, c9; Som05: C4; Tha97: c6,
c7]
Equipos, instalaciones y personas están asociados con las tareas
programadas, incluyendo la asignación de responsabilidades para la
terminación (utilizando, por ejemplo, un diagrama de Gantt). Esta actividad
está informado y limitada por la disponibilidad de recursos y su uso óptimo en
esas circunstancias, así como por las cuestiones relativas al personal (por
ejemplo, la productividad de
individuos / equipos, la dinámica del equipo,
organización y estructuras de equipo).
© IEEE - 2004 Versión
2.5. Gestión de riesgos
La identificación de riesgos y análisis (lo que puede salir mal, ¿cómo y por qué,
y cuáles son las consecuencias probables), evaluación crítica de riesgo (que
son los riesgos más significativos en términos de exposición, lo que podemos
hacer algo al respecto en términos de apalancamiento), el riesgo se llevaron a
cabo todas mitigación y planes de contingencia (la formulación de una
estrategia para hacer frente a los riesgos y gestionar el perfil de riesgo).
métodos de evaluación de riesgos (por ejemplo, árboles de decisión y
simulaciones de procesos) se debe utilizar con el fin de destacar y evaluar los
riesgos. políticas de abandono del proyecto también se deben determinar en
este punto de la discusión con todos los demás interesados. [Dor02: v2c7;
Pfl01: C3; Pre04: c25; Rei02: c11; Som05: C4; Tha97: c4] aspectos de
software-única de riesgo, como la tendencia ingenieros de software para añadir
características no deseadas o los riesgos asociados en la naturaleza intangible
del software,
2.6. Gestión de la calidad
[Dor02: v1c8, v2c3-c5; Pre04: c26; Rei02: c10; Som05: c24,
c25; Tha97: c9, c10]
La calidad se define en términos de atributos pertinentes del proyecto
específico y cualquier producto (s) asociado, tal vez en términos
cuantitativos y cualitativos. Estas características de calidad se han
determinado en la especificación de requisitos detallados de software. Ver
también los requisitos de software KA.
Los umbrales para la adhesión a la calidad se establecen para cada indicador según
corresponda a las expectativas de las partes interesadas para el software en
cuestión. Los procedimientos relativos a la SQA en curso en todo el proceso y para
el producto de verificación (de entrega) y la validación también se especifican en
esta etapa (por ejemplo, las revisiones e inspecciones técnicas) (véase también la
calidad del software KA).
2.7. plan de gestión
[Som05: c4; Tha97: c4]
¿Cómo se gestionará el proyecto y cómo el plan será administrado también debe
ser planificada. La presentación de informes, seguimiento y control del proyecto
debe corresponder al proceso de ingeniería de software seleccionado y las
realidades del proyecto, y debe reflejarse en los diversos artefactos que serán
utilizados para la gestión de la misma. Sin embargo, en un entorno donde el
cambio es una expectativa en lugar de un choque, es vital que los planes se
administran a sí mismos. Esto requiere que la adhesión a los planes de ser
dirigida de manera sistemática, ha de examinarse, informó, y, en su caso,
revisada. Planes asociados a otros procesos de apoyo orientados a la gestión
(por ejemplo, la documentación, gestión de configuración de software, y la
resolución del problema) también deben ser gestionados de la misma manera.
3. La promulgación del proyecto de software
se implementan los planes, y se promulgan los procesos incorporados en
los planes. En todo momento, hay un enfoque en el cumplimiento de los
planes, con una imperiosa
© IEEE - 2004 Versión
expectativa de que esta adhesión dará lugar a la exitosa satisfacción de
necesidades de los interesados ​y el logro de los objetivos del proyecto.
Fundamental para la incorporación son las actividades de gestión en curso de
medición, supervisión, control y presentación de informes.
3.1. Implementación de planes
[Pfl01: c3; Som05: c4]
El proyecto se inicia y las actividades de los proyectos se llevan a cabo de
acuerdo con el calendario. En el proceso, se utilizan los recursos (por
ejemplo, el esfuerzo personal, la financiación) y los resultados se producen
(por ejemplo, documentos de diseño arquitectónico, casos de prueba).
3.2. la gestión de contratos con proveedor
[Som05: c4]
Preparar y ejecutar los acuerdos con los proveedores, monitorear el
desempeño del proveedor, y aceptar productos del proveedor,
incorporándolos en su caso.
3.3. Aplicación del proceso de medición
[Fen98: c13, c14; Pre04: c22; Rei02: c10, c12; Tha97: C3, C10]
El proceso de medición se promulgó junto con el proyecto de software, asegurando
que se recogen los datos relevantes y útiles (véanse también los temas 6.2 Planificar
el proceso de medición y 6,3
Realizar el proceso de medición).
3.4. Process monitor
[Dor02: v1c8, v2c2-C5, C7; Rei02: c10; Som05: c25; Tha97: c3; c9]
La adhesión a los diversos planes se evalúa continuamente y a intervalos
predeterminados. Se analizan los resultados y condiciones de finalización
para cada tarea. Entregables se evalúan en términos de sus características
requeridas (por ejemplo, a través de revisiones y auditorías). gasto
esfuerzo, horario de la adherencia y los costes hasta la fecha se
investigan, y se examina el uso de recursos. El perfil de riesgo del
proyecto, se revisa y se evalúa la adherencia a los requisitos de calidad.
Los datos de medición se modelan y se analizaron. se lleva a cabo análisis de la
varianza basado en la desviación de real de los resultados y valores esperados.
Esto puede ser en forma de exceso de costos, cronograma deslizamiento, y
similares. se lleva a cabo la identificación y el análisis de otros datos de medición de
calidad y de valores atípicos (por ejemplo, el análisis de la densidad de defectos). La
exposición al riesgo y el apalancamiento se vuelven a calcular y decisiones árboles,
simulaciones, y así sucesivamente se vuelva a ejecutar a la luz de los nuevos datos.
Estas actividades permiten la detección del problema e identificación excepción
basada en umbrales excedido. Se informaron los resultados según sea necesario y,
desde luego, donde se superan los umbrales aceptables.
3.5. Proceso de control
[Dor02: v2c7; Rei02: c10; Tha97: c3, C9] Los resultados de las actividades
de supervisión de procesos proporcionan la base sobre la cual se toman las
decisiones de acción. Dónde
8-5
apropiada, y donde se modelan y lograron el impacto y los riesgos
asociados, se pueden realizar cambios al proyecto. Esto puede tomar la
forma de acción correctiva (por ejemplo, volver a probar ciertos
componentes), Puede implicar la
incorporación de contingencias para que hechos similares se evitan (por
ejemplo, la decisión de utilizar la creación de prototipos para ayudar en la
validación de los requisitos de software), y / o puede implicar la revisión de los
diversos planes y otros documentos del proyecto (por ejemplo, la especificación
de requisitos) a acomodar
los resultados inesperados y su
trascendencia.
En algunos casos, puede llevar al abandono del proyecto.
En todos los casos, los procedimientos de control de cambios y
gestión de configuración de software se cumplen (véase también el Software
Configuration Management KA), las decisiones se documentan y se comunican a
todas las partes pertinentes, se revisan los planes y modifican cuando es
necesario, y los datos pertinentes se registra en el centro base de datos (véase
también el tema 6.3 Realizar el proceso de medición).
3.6. informes
[Rei02: c10; Tha97: C3, C10]
En períodos determinados y acordados, se informa de la adhesión a los planes, tanto
dentro de la organización (por ejemplo, para el comité directivo cartera de proyectos) y
para los interesados ​externos (por ejemplo clientes, usuarios). Los informes de esta
naturaleza deberían centrarse en el cumplimiento general, en contraposición a la
información detallada que se requiere con frecuencia dentro del equipo del proyecto.
4. Revisión y Evaluación
En los puntos críticos en el proyecto, el progreso general hacia el logro de los
objetivos planteados y la satisfacción de las partes interesadas
Se evalúan los requisitos. Similar,
evaluaciones de la eficacia del proceso global hasta la fecha, el personal
implicado, y las herramientas y métodos empleados también se realizan a
hitos particulares.
4.1. La determinación de la satisfacción de las necesidades
[Rei02: c10; Tha97: C3, C10]
Desde la consecución de los interesados ​(usuarios y clientes) satisfacción es uno de
nuestros principales objetivos, es importante que el progreso hacia este objetivo se
evaluará formalmente y de forma periódica. Esto ocurre en el logro de los
principales hitos del proyecto (por ejemplo la confirmación de la arquitectura de
diseño de software, integración de software de revisión técnica). Variaciones de las
expectativas se identifican y se toman las medidas adecuadas. Al igual que en la
actividad proceso de control anterior (ver tema 3.5
Proceso de control), en todos los casos cambian los procedimientos de control y de
gestión de configuración de software se cumplen (véase el Software Configuration
Management KA), las decisiones se documentan y se comunican a todas las
partes pertinentes, se revisan los planes y modifican cuando es necesario, y los
datos correspondientes se registran en la base de datos central ( véase también el
tema 6.3 Realizar el proceso de medición). Más información también se puede
encontrar en el Testing de Software KA,
8-6
en el tema 2.2 Objetivos de las Pruebas y en la calidad del software KA, en el
tema 2.3 Revisiones y auditorías.
4.2. Revisar y evaluar el desempeño
[Dor02: v1c8, v2c3, C5; Pfl01: c8, c9; Rei02: c10; Tha97: C3, C10]
evaluaciones de desempeño periódicas para el personal del proyecto
proporciona una visión en cuanto a la probabilidad de cumplimiento de los
planes, así como posibles áreas de dificultad (por ejemplo, conflictos
miembros del equipo). Los diversos métodos, herramientas y técnicas
empleadas son evaluados por su eficacia e idoneidad, y el propio proceso se
evalúa sistemáticamente y periódicamente por su relevancia, utilidad y
eficacia en el contexto del proyecto. En su caso, se realizan cambios y
gestionados.
5. Cierre
El proyecto alcanza cierre cuando se han aprobado y completado todos los
planes y procesos incorporados. En esta etapa, se revisan los criterios para
el éxito del proyecto. Una vez que se establece el cierre, se llevan a cabo
de archivo, post mortem, y de mejora de procesos actividades.
5.1. La determinación de cierre
[Dor02: v1c8, v2c3, C5; Rei02: c10; Tha97: C3, C10] las funciones
especificadas en los planes están completos, y el logro satisfactorio de los
criterios de terminación es
confirmado. Todos los productos previstos se han entregado con características
aceptables. Requisitos estén seleccionadas y confirmadas como satisfecho, y se
han alcanzado los objetivos del proyecto. Estos procesos implican generalmente
todas las partes interesadas y el resultado en la documentación de aceptación
del cliente y los informes de problemas conocidos restantes.
5.2. Las actividades de cierre
[Pfl01: c12; Som05: c4]
Tras el cierre se haya confirmado, archivo de los materiales del proyecto se lleva
a cabo de acuerdo con los métodos de actores-acordado,
ubicación y duración. base de datos de medición de la
organización se actualiza con los datos finales del proyecto y análisis
posteriores a los proyectos se llevan a cabo. La autopsia proyecto se realiza
para que los temas, problemas y oportunidades encontradas durante el
proceso (sobre todo a través de la revisión y evaluación, véase subárea 4.) se
analizan, se extraigan lecciones del proceso y se introducen en el aprendizaje
y la mejora de los esfuerzos de organización ( véase también la Ingeniería de
Software Proceso KA).
6. Medición de Ingeniería de Software
[ISO15939-02]
La importancia de la medición y su papel en mejores prácticas de gestión es
ampliamente reconocido, por lo que su importancia sólo puede aumentar en
los próximos años. La medición efectiva se ha convertido en una de las piedras
angulares de la madurez de la organización.
© IEEE - 2004 Versión
Términos clave sobre las medidas de software y métodos de medición se
han definido en [ISO15939-02] sobre la base del vocabulario internacional
ISO de la metrología [ISO93]. Sin embargo,
Los lectores encuentro terminología
las diferencias en la literatura; por ejemplo, el termino
“métrica” se utiliza a veces en lugar de “medidas”. Este tema sigue norma
internacional ISO / IEC 15939, que describe un proceso que define las
actividades y tareas necesarias para implementar un proceso de medición
de software e incluye, además, un modelo de información de medición.
6.1. Establecer y mantener el compromiso de Medición
Aceptar requisitos para la medición. Cada
medición esfuerzo debe guiarse por
objetivos de la organización y accionado por un conjunto de medición
requisitos establecido por
organización y el proyecto. Por ejemplo, uno de los objetivos de la
organización podría ser “el primero en el mercado con nuevos
productos”. [Fen98: c3, c13; Pre04: c22] Esto a su vez podría generar
un requisito ese factores
contribuir a este objetivo se medirá por lo que los proyectos podrían ser
manejados para cumplir este objetivo.
- Definir el alcance de la medición. La unidad organizativa a la que
cada requisito de medición se va a aplicar debe ser establecido.
Esto puede consistir en un área funcional, un solo proyecto, un
solo sitio, o incluso toda la empresa. Todas
subsecuente
tareas de medición relacionadas con este requisito deben estar
dentro del alcance definido. Además, se deben identificar los grupos
de interés.
- Compromiso de gestión y personal
medición. El compromiso debe ser establecido formalmente, comunica,
y apoyado por los recursos (ver siguiente punto). Comprometer recursos
para la medición. El compromiso de la organización para la medición es un
factor esencial para el éxito, como lo demuestra la asignación de los
recursos para la ejecución del proceso de medición. Asignación de
recursos incluye la asignación de responsabilidades para las distintas
tareas del proceso de medición (por ejemplo, usuario, analista, y
bibliotecario) y proporcionando una adecuada financiación, la formación,
las herramientas y el apoyo para llevar a cabo el proceso de forma
duradera.
6.2. Planificar el proceso de medición
Caracterizar la unidad organizativa. La unidad de organización
proporciona el contexto para la medición, por lo que es importante
hacer este contexto explícito y articular los supuestos que encarna y
las limitaciones que impone. Caracterización puede ser en términos
de organización
procesos, solicitud dominios,
tecnología, y organizativo interfaces. Un
modelo de proceso de organización es también típicamente un elemento
de la unidad de caracterización organizativa [ISO15939-02: 5.2.1].
© IEEE - 2004 Versión
Identificar las necesidades de información. Las necesidades de información se
basan en los objetivos, limitaciones, riesgos y problemas de la unidad
organizativa. Ellos se pueden derivar de negocio, objetivos de la organización,
regulación y / o de productos. Ellos deben ser identificados y priorizados. A
continuación, un subconjunto a tratar deberá ser seleccionado y los resultados
documentados,
comunicado, y revisado por
partes interesadas [ISO15939-02: 5.2.2]. Optar por medidas. medidas candidatos
deben ser seleccionados, con claros vínculos con las necesidades de información.
Medidas deben entonces ser seleccionados en base a las prioridades de las
necesidades de información y otros criterios tales como coste de la recogida, el
grado de interrupción del proceso durante la recogida, la facilidad de análisis, la
facilidad de obtención, datos precisos y consistentes, y así sucesivamente
[ISO15939-02: 5,2 0.3 y Apéndice C]. Definir la recolección de datos,
el
análisis, y generación de informes
procedimientos. Esto abarca procedimientos de recogida y horarios,
almacenamiento, verificación, análisis, informes y gestión de la
configuración de datos [ISO15939-02:
5.2.4].
Definir los criterios para la evaluación de los productos de información.
Criterios para la evaluación están influenciados por los objetivos técnicos
y de negocio de la unidad organizativa. Los productos de información
incluyen los asociados con el producto que se produce, así como los
asociados con los procesos que se utilizan para administrar y medir el
proyecto [ISO15939-02: 5.2.5 y Apéndices D, E]. Revisión,
aprobar, y proporcionar recursos para
tareas de medición.
a - El plan de medición debe ser revisado y aprobado por los
interesados ​apropiados. Esto incluye todos los procedimientos de
recopilación de datos, almacenamiento, análisis y procedimientos de
información; criterios de evaluación; horarios; y responsabilidades.
Los criterios para la revisión de estos artefactos deberían haberse
establecido a nivel de unidad organizativa o superior y deben
utilizarse como base para estas revisiones. Dichos criterios deben
tener en cuenta la experiencia previa, la disponibilidad de recursos, y
las posibles interrupciones a los proyectos cuando se proponen
cambios con respecto a las prácticas actuales. Aprobación
demuestra el compromiso
a la medida proceso
[ISO15939-02: 5.2.6.1 y Apéndice F].
- Recursos debe ponerse a disposición para
implementar el planificado y aprobado
tareas de medición. La disponibilidad de recursos puede ser puesta
en escena en los casos en que los cambios han de ser pilotado
antes del despliegue generalizado. Deberán tener en cuenta a los
recursos necesarios para la implementación exitosa de nuevos
procedimientos o medidas [ISO15939-02: 5.2.6.2]. Adquirir e
implementar tecnologías de apoyo. Esto incluye
evaluación de disponible secundario
tecnologías, selección de lo más apropiado
8-7
 tecnologías, la adquisición de esas tecnologías y despliegue de
esas tecnologías [ISO15939-02:
5.2.7].
6.3. Realizar el proceso de medición
Integrar procedimientos de medición con los procesos pertinentes. Los
procedimientos de medición, tales como la recogida de datos, deben
integrarse en los procesos que se está midiendo. Esto puede implicar el
cambio de los procesos actuales para dar cabida a la recogida de datos o
actividades de generación. También puede implicar el análisis de los
procesos actuales para reducir al mínimo esfuerzo adicional y la evaluación
del efecto de los empleados para asegurar que
el
Se aceptarán procedimientos de medición. problemas de moral y otros
factores humanos deben ser considerados. Además, los procedimientos de
medición deben ser comunicados a los que proporcionan los datos, es
posible que la formación que debe proporcionarse, y por lo general debe ser
apoyado. Análisis de datos y los procedimientos de información típicamente
deben integrarse en procesos de organización y / o de proyecto en una
manera similar [ISO15939-02: 5.3.1]. Recolectar datos. Los datos deben ser
recogidos, verificados, y se almacenan [ISO15939-02: 5.3.2].
Analizar los datos y desarrollar productos de información. Los datos pueden
ser agregados, transformadas, o re-codificados como parte del proceso de
análisis, utilizando un grado de rigor apropiado a la naturaleza de los datos y
las necesidades de información. Los resultados de este análisis son
típicamente indicadores tales como gráficos, números u otras indicaciones
que deben ser interpretadas, resultando en conclusiones iniciales a ser
presentado a las partes interesadas. Los resultados y conclusiones deben
ser revisados, usando un proceso definido por la organización (que puede
ser formal o informal). Los proveedores de datos y usuarios de medida
deben participar en la revisión de los datos para asegurarse de que son
significativos, y precisa, y que pueden dar lugar a acciones razonables
[ISO15939-02: 5.3.3 y el Apéndice G].
8-8
Comunicar los resultados. Los productos de información deben estar
documentados y comunicados a los usuarios y
partes interesadas [ISO15939-02: 5.3.4].
6.4. evaluar Medición
Evaluar productos de información. Evaluar productos de información
respecto a los criterios de evaluación establecidos y determinar las
fortalezas y debilidades de los productos de información. Esto puede ser
realizado por un proceso interno o una auditoría externa y debe incluir
retroalimentación de los usuarios de medición. lecciones aprendidas de
registro en una base de datos adecuada [ISO15939-02: 5.4.1 y el
Apéndice D].
Evaluar el proceso de medición. Evalúa el
proceso de medición frente a los criterios de evaluación establecidos y
determinar las fortalezas y debilidades del proceso. Esto puede ser
realizado por un proceso interno o una auditoría externa y debe incluir
retroalimentación de los usuarios de medición. lecciones aprendidas de
registro en una base de datos adecuada [ISO15939-02: 5.4.1 y el
Apéndice D].
Identificar las mejoras potenciales. Tales mejoras pueden ser
cambios en el formato de los indicadores, los cambios en unidades
medidas, o reclasificación de categorías. Determinar los costos y
beneficios de las mejoras potenciales y seleccionar acciones de
mejora correspondientes. Comunicar las mejoras propuestas para el
propietario del proceso de medición y las partes interesadas para su
revisión y aprobación. También comunicarse falta de mejoras
potenciales si el análisis no logra identificar mejoras [ISO15939-02:
5.4.2].
© IEEE - 2004 Versión
 METRO ATRIX DE T OPICS VS. R EFERENCIA METRO ATERIAL

[Dor02] [ ISO15939-02] [Fen98] [Pfl01] [Pre04] [Rei02] [Som05] [Tha97]

1. Iniciación y definición del alcance

1.1 Determinación de las necesidades y la

v2c4 c4 c7 c5
negociación

análisis 1.2 Viabilidad c6 c6

1.3 Proceso para el examen y la revisión de los

c6
requisitos

2. software de planificación

v1c6, v2c7,
Proceso de planificación 2.1 c2, c3 C2, C21 C1, C3, C5 C3, C4 c3, c4, c6
v2c8

2.2 Determinar entregables c3 c24 c4

23 Esfuerzo, el horario y la estimación de costos v2c7 c12 c3 C23, C24 C5, C6 C4, C23 c5

2.4 Asignación de recursos c3 c24 C8, C9 c4 C6, C7

gestión 2.5 Riesgo v2c7 c3 c25 c11 c4 c4

v1c8, v2c3-
2.6 gestión de calidad c26 c10 c24, c25 c9, c10
c5

2.7 plan de gestión c4 c4

La promulgación 3. Proyecto de Software

3.1 Implementación de planes c3 c4

la gestión de contratos 3.2 Proveedor c4

3.3 Aplicación del proceso de medición

C13C, 14 c22 c10, c12 C3, C10

v1c8, v2c2-
3.4 Monitor de proceso c10 c25 c3, C9
C5, C7

3.5 proceso de Control v2c7 c10 c3, C9

3.6 Reporte c10 C3, C10

4. Revisión y evaluación

4.1 La determinación de la satisfacción de las

c10 C3, C10
necesidades

4.2 Revisión y rendimiento evaluar v1c8, v2c3, C8, C9 c10 C3, C10
c5

5. Cierre

v1c8, v2c3,
5.1 Determinación de cierre c10 C3, C10
c5

5.2 Las actividades de cierre c12 c4

6. Software de Ingeniería de medición *

6.1 Establecer y mantener el compromiso de

C3, C13 c22
medición

6,2 planificar el proceso de medición c5, C, D, E, F

6.3 Realizar el proceso de medición c5, G

6.4 Evaluar la medición c5, D

© IEEE - 2004 Versión 8-9


R ECOMMENDED R EFERENCIAS PARA S OFTWARE
mi NGENIERÍA METRO GESTIÓN
[Dor02] M. Dorfman y RH Thayer, Eds., "Ingeniería de Software". (Vol. 1 y
Vol. 2), IEEE Computer Society Press, 2002, vol. 1, cap. 6, 8, Vol. 2, Cap.
3, 4, 5, 7, 8. [Fen98] NE Fenton y SL Pfleeger, "Métricas de Software: un
enfoque riguroso y práctico," Segunda ed: International Thomson
Computer Press, 1998, Cap. 1-14. [ISO15939-02]
ISO / IEC 15939: 2002, Software
Ingeniería de Software-Proceso de medida: ISO e IEC,
2002.
[Pfl01] SL Pfleeger, "Ingeniería de Software: Teoría y Práctica", Segunda
ed: Prentice-Hall, 2001, Cap 2-
4,8,9,12,13.
[] Pre04 RS Pressman, "Ingeniería de Software: El enfoque de un
practicante," Sexto ed: McGraw-Hill, 2004, Cap. 2, 6, 7, 22-26.
[Rei02] DJ Reifer, Ed., "Gestión de software." IEEE Computer Society,
2002, Cap. 1-6, 7-12, 13. [Som05] I. Sommerville, "Ingeniería de
Software", ed Séptimo: Addison-Wesley, 2005, Cap. 3-6, 23-25. [Tha97]
RH Thayer, Ed., "Ingeniería de Software de Gestión de Proyectos." IEEE
Computer Society, 1997, Cap. 1-10.

8-10 © IEEE - 2004 Versión


UN PÉNDICE A. L LISTA DE F ás R EADINGS
(Adl99) TR Adler, JG Leonard y RK Nordgren, "Mejora de la Gestión de
Riesgos: El paso de eliminación del riesgo de Riesgos Prevención" Software
Tecnología de la Información y, vol. 41, 29-34, 1999
(Bai98) R. Baines, "en todas las disciplinas: Riesgo, diseño, método, proceso
y herramientas" IEEE Software, 61-64, julio / agosto de 1998
(Bin97) RV Binder, "¿Puede un modelo de trabajo de fabricación de calidad de
software ?," IEEE Software, 101-102,105, septiembre / octubre de 1997
(Boe97) BW Boehm y T. DeMarco, "Gestión de Riesgos de software" IEEE
Software, 17-19, mayo / junio de 1997 (Bri96) LC Briand, S. Morasca y VR
Basili, "Propiedad basada en Ingeniería de Software de medición"
IEEE Transactions on Software Engineering, vol. 22, ISS. 1, 68-86, 1996
(Bri96a) L. Briand, KE Emam y S. Morasca, "en la solicitud de medida
Teoría en Ingeniería de Software" Empírica Ingeniería de Software, vol. 1,
61-
88, 1996
(Bri97) LC Briand, S. Morasca y VR Basili, "Respuesta a: Comentarios
sobre 'basado en la propiedad de Ingeniería de Software de medición:
Refinación la Addivity
Propiedades," IEEE Transactions on Software Engineering,
vol. 23, ISS. 3, 196-197, 1997
(Bro87) FPJ Brooks, "no son la panacea: Esencia y Accidentes de
Ingeniería de Software" Computadora, 10-19, abril, 1987
(Cap96) J. Capers, Aplicada de software de medición: Asegurando
productividad y calidad, Segunda ed: McGraw-Hill, Inc., 1996.
(Car97) MJ Carr, "Gestión del riesgo no puede ser para todos" IEEE
Software, 21-24, mayo / junio de 1997 (Cha96) RN Charette, "a gran
escala de gestión de proyectos es gestión de riesgos" IEEE Software, 110-117, (Hal97) T. Hall y N. Fenton, "Implementación de Software Metrics
julio de 1996 (Cha97) RN Charette, KM Adams y MB blanca, "Gestión del
riesgo en Mantenimiento de Software" IEEE Software,
43-50, mayo / junio de 1997
(Col96) B. Collier, T. y P. DeMarco Fearey, "un proceso definido para el
Proyecto de Revisión post-mortem" IEEE Software,
65-72, julio de 1996
(Con97) EH Conrow y PS Shishido, "Implementación de Software de Gestión
de Riesgos en proyectos intensivos," IEEE Software, 83-89, mayo / junio de
1997
(Dav98) AM Davis, "Predicciones y despedidas" IEEE Software, 6-9, julio /
agosto, 1998
(Dem87) T. DeMarco y T. Lister, Peopleware: Proyectos Productivos y
Equipos: Dorset House Publishing,
1987.
(Dem96) T. DeMarco y A. Miller, "Gestión de grandes proyectos de
software" IEEE Software, 24-27, julio de 1996 (Fav98) J. Favaro y SL
Pfleeger, "Realización de desarrollo de software
Decisiones de inversión," ACM SIGSoft
Ingeniería de Software Notas, vol. 23, ISS. 5, 69-74, 1998 (Fay96) ME
Fayad y M. Cline, "Gestión de Object-
© IEEE - 2004 Versión
Desarrollo de Software Orientado" Computadora, 26-31, septiembre de 1996
(Fen98) NE Fenton y Pfleeger SL, Las métricas de software: un enfoque
riguroso y práctico, Segunda ed: International Thomson Computer Press,
1998. (Fle99) R. Fleming, "una nueva perspectiva sobre viejos problemas"
IEEE Software, 106-113, enero / febrero de 1999
(Fug98) A. Fuggetta, L. Lavazza, S. Morasca, S. Cinti, G. y E. Oldano
Orazi, "Aplicación de GQM en un software de fábricas industriales," ACM
Transactions on Software Engineering y Metodología, vol. 7, ISS. 4,
411-448, 1998 (Gar97) PR Garvey, DJ Phair y JA Wilson, "una
arquitectura de información para la evaluación y gestión de riesgos" IEEE
Software, 25-34, mayo / junio de 1997 (Gem97) A. Gemmer, "Gestión de
Riesgo: Más allá del proceso," Computadora, 33-43 de mayo de 1997
(Gla97) RL de cristal, "Los altibajos del programador estrés," Communications
of the ACM, vol. 40, ISS. 4, 17-19, 1997
(Gla98) RL de cristal, "remedios a corto plazo y largo plazo para proyectos
de Runaway" Communications of the ACM, vol. 41, ISS. 7, 13-15, 1998
(Gla98a) RL de cristal, "¿Cómo no para prepararse para un trabajo de
consultoría, Consultoría y Otros Feo verdades"
Communications of the ACM, vol. 41, ISS. 12, 11-13, 1998 (Gla99) RL de
cristal, "Las realidades de software de tecnología de Pagos" Communications
of the ACM, vol.
42, ISS. 2, 74-79, 1999
(Gra99) R. Grable, J. Jernigan, C. Pogue y D. Divis, "Métrica para Pequeños
Proyectos: Experiencias en la SED," IEEE Software, 21-29, marzo / abril de
1999 (Gra87) RB Grady y DL Caswell, Métricas de Software: se establece un
programa de toda la compañía. Englewood Cliffs NJ, EE.UU.: Prentice-Hall,
1987.
programas eficaces" IEEE Software, 55-64, marzo / abril de 1997
(Hen99) SM Henry y KT Stevens, "Uso de papel de liderazgo de Belbin
para mejorar la eficacia del equipo: Una investigación empírica" Diario de
sistemas y software,
vol. 44, 241-250, 1999
(Hoh99) L. Hohmann, "El entrenar el Administrador de Novato,"
IEEE Software, 16-19, enero / febrero de 1999 (Hsi96) P. Hsia, "Hacer
visible de desarrollo de software,"
IEEE Software, 23-26, marzo de 1996 (Hum97) WS Humphrey, Dirección de
Personas técnicas: Innovación, Trabajo en equipo, y el Proceso de Software: Addison-Wesley,
1997. (IEEE12207.0-96)
IEEE / EIA 12207.0-
1996 // ISO / IEC12207: 1995, Implementación de la industria Int. Std.
ISO / IEC 12207: 95, Norma para Tecnología de la
Información-Software Procesos del ciclo de vida, vol. IEEE,
1996.
(Jac98) M. Jackman, "remedios homeopáticos para el equipo de toxicidad" IEEE
Software, 43-45, julio / agosto, 1998 (Kan97) K. Kansala, "La integración de la
evaluación de riesgos con
8-11
Estimación de costos," IEEE Software, 61-67, mayo / junio de 1997 (Kar97) J.
Karlsson y K. Ryan, "A Costo-Valor Aproximación de fijación de las
prioridades" IEEE Software, 87-74, septiembre / octubre de 1997
(Kar96) DW Karolak, "Ingeniería de Software de Gestión de Riesgos" IEEE
Computer Society, 1996 (Kau99) K. Kautz, "Tener sentido de medida para
las organizaciones pequeñas," IEEE Software, 14-20, marzo / abril de
1999
(Kei98) M. Keil, PE Cule, K. Lyytinen y RC Schmict, "un marco para
identificar los riesgos del proyecto de software" Communications of the
ACM, vol. 41, ISS. 11, 76-
83, 1998
(Ker99) B. Kernighan y R. Pike, "Búsqueda de mejoras en el rendimiento" IEEE
Software, 61-65, marzo / abril de 1999 (Kit97) B. Kitchenham y S. Linkman,
"Estimaciones, la incertidumbre y el riesgo," IEEE Software, 69-74, mayo /
junio de 1997
(Lat98) F. v. Latum, R. v. Solingen, M. OIVO, B. Hoisl,
D.Rombach y G. Ruhe, "Adoptar GQM-Basado
Medición en un entorno industrial," IEEE
Software, 78-86, enero-febrero de 1998
(Leu96) HKN Leung, "un índice de riesgo de Productores de Software" Mantenimiento
de Software: Investigación y Práctica,
vol. 8, 281-294, 1996
(Lis97) T. Lister, "Gestión de riesgos es Proyecto
Gestión para adultos," IEEE Software, 20-22, mayo / junio de 1997
(Mac96) K. Mackey, "¿Por qué le pasan cosas malas a los buenos proyectos" IEEE
Software, 27-32, mayo de 1996
(Mac98) K. Mackey, "Más allá de Dilbert: la creación de culturas que funcionan," IEEE Problem," Software Engineering Institute, Carnegie Mellon University CMU
Software, 48-49, enero / febrero de 1998 (Mad97) RJ Madachy, "Evaluación de
Riesgo heurístico El uso de Factores de costo," IEEE Software, 51-59, mayo /
junio de 1997 (McC96) SC McConell, Desarrollo rápido: La doma Horarios
Software salvajes: Microsoft Press, 1996. (McC97) SC McConnell, Proyecto de
Software Guía de supervivencia:
Microsoft Press, 1997.
(McC99) SC McConell, "Ingeniería de software
Principios" IEEE Software, 6-8, marzo / abril de 1999 (Moy97) T.
Moynihan, "Proyecto ¿Qué experiencia
Los gerentes evaluar el riesgo" IEEE Software, 35-41, mayo / junio de 1997
(Ncs98) P. NCSI, "Gestión de Proyectos OO Mejor" IEEE Software, 50-60,
julio / agosto de 1998
(Nol99) AJ Nolan, "aprender de éxito," IEEE Software, 97-105, enero /
febrero de 1999
(Off97) RJ Offen y R. Jeffery, "Establecimiento de software
8-12
Programas de medición" IEEE Software, 45-53, marzo / abril de 1997
(Par96) KVC Parris, "Implementación de rendición de cuentas"
IEEE Software, 83-93, julio de 1996 (Pfl97) SL Pfleeger, "Evaluación de
Medición (editor invitado de
Introducción)," IEEE Software, 25-26,
Marzo / abril de 1997
(Pfl97a) Pfleeger SL, R. Jeffery, B. y B. Curtis Kitchenham, "Informe sobre
el estado de software de medición"
IEEE Software, 33-43, marzo / abril de 1997 (Put97) ​LH Putman y W.
Myers, "Software Industrial Strength - Gestión eficaz utilizando la
medición", Los Alamitos, CA, 1997
(Rob99) PN Robillard, "El papel del conocimiento en el desarrollo de
software" Communications of the ACM, vol.
42, ISS. 1, 87-92, 1999
(Rod97) AG Rodrigues y TM Williams, "Dinámica de Sistemas de
Software de Gestión de Proyectos: Hacia el desarrollo de una formal
Marco Integrado"
Revista Europea de Sistemas de Información, vol. 6, 51-66, 1997
(Rop97) J. Ropponen y K. Lyytinen: "¿Puede el software de Gestión de Riesgos
Mejorar el Desarrollo del Sistema: Un
Estudio exploratorio," Revista Europea de Sistemas de Información, vol. 6,
41-50, 1997
(Sch99) C. Schmidt, P. Dart, L. Johnston, L. Sterling y P. Thorne,
"Desincentivos para comunicar el riesgo: una paradoja Riesgo," Software
Tecnología de la Información y, vol. 41, 403-411, 1999
(Sco92) RL v Scoy,. "El riesgo de desarrollo de software: Oportunidad, No
/ SEI-92-TR-30, 1992 (Sla98) SA Masacre, DE Harter y MS Krishnan, "
evaluando
el costo de La calidad del software,"
Communications of the ACM, vol. 41, ISS. .. 8, 67-73, 1998 (Sol98) R. v
Solingen, R. Berghout y F. v Latum, "Interrumpe: sólo un minuto no es
nunca," IEEE Software, 97-103, septiembre / octubre de 1998 (Whi95) N.
Whitten, La gestión de proyectos de desarrollo de software: Las fórmulas
para el éxito: Wiley, 1995. (Wil99) B. Wiley, Requisitos del sistema
esenciales: Una Guía Práctica de Métodos dirigido por eventos: Addison-Wesley,
1999.
(Zel98) MV Zelkowitz y DR Wallace, "Modelos experimentales para la
validación de la tecnología" Computadora, vol. 31, ISS.
5, 23-31, 1998
© IEEE - 2004 Versión
 Tecnología de software procesa ciclo de vida, vol. IEEE,
UN PÉNDICE B. L LISTA DE S NORMAS
1996.
(IEEE610.12-90) IEEE Std 610.12-1990 (R2002), Glosario IEEE Estándar (ISO15939-02) ISO / IEC 15939: 2002, Software
de Ingeniería de Software Terminología: Ingeniería de Software-Proceso de medida: ISO e IEC,
IEEE, 1990. 2002.
(IEEE12207.0-96) IEEE / EIA 12207.0- Gestión (PMI00) Proyecto Normas del Instituto
1996 // ISO / IEC12207: 1995, Implementación de la industria Int. Std. Comité, Una guía para la Dirección de Proyectos (PMBOK): Project
ISO / IEC 12207: 95, Norma de Información Management Institute, 2000.

© IEEE - 2004 Versión 8-13

8-14 © IEEE - 2004 Versión
 do CAPÍTULO 9 S OFTWARE mi NGENIERÍA

PAG PROCESO

la organización. Este significado se utiliza en el KA en muy pocos

casos.
UN CRONYMS Esta KA se aplica a cualquier parte de la gestión de los procesos del ciclo de
vida del software, que está implantando el cambio de procedimiento o
CMMi Capability Maturity Model Integration
tecnología para el proceso o producto mejoría.
EF La experiencia de la fábrica

FP Punto de función
proceso de ingeniería de software es relevante no sólo para las grandes
HRM Administración de recursos humanos organizaciones. Por el contrario, las actividades pueden, y han sido relacionados
IDEAL Iniciando-Diagnóstico-Establishing- interino de con el proceso, realizado con éxito por pequeñas organiza- ciones, equipos y
tendencia (modelo) personas. El objetivo de la gestión de los procesos del ciclo de vida del software

Dios mio grupo de administración de objetos es implementar procesos nuevos o mejores en las prácticas reales, ya sean
individuales, proyecto o la organización. Este KA no aborda explícitamente los
QIP Mejora la calidad del paradigma
recursos humanos agement man- (HRM), por ejemplo, como se realiza en el
GAMBAS REBOZADAS CMM basada similares para el proceso de mejoría
People CMM (Cur02) y sistemas de procesos de ingeniería [ISO1528-028; IEEE
con el CMMi
1220-1298]. También hay que reconocer que muchos problemas de software
SCE El software de evaluación de capacidad
Engineer- proceso ing están estrechamente relacionados con otras disciplinas,
SEPG Procesos de Software Engineering Group como la gestión, aunque a veces el uso de una terminología diferente.

yo INTRODUCCIÓN
El Proceso de Ingeniería de Software KA puede ser examinado en dos
niveles. El primer nivel abarca las actividades técnicas y de gestión dentro
del ciclo de vida del software PROCESOS DE que se realizan durante la
adquisición de software, de- sarrollo, mantenimiento y retiro. El segundo
segundo REAKDOWN DE T OPICS PARA S OFTWARE
es el meta-nivel, que se ocupa de la definición, imple- mentación,
mi NGENIERÍA PAG PROCESO
evaluación, medición, gestión, el cambio y la mejora de los procesos del
ciclo de vida del software sí mismos. El primer nivel está cubierto por la La Figura 1 muestra el desglose de temas en este KA.

otra Kas, en la Guía. Este KA se refiere a la segunda. El término “proceso

1. Implementación de procesos y Cambio
de ingeniería de software” puede interpretarse de diferentes maneras, y
Esta sub-área se centra en el cambio organizativo. Se de- escribas la infraestructura,
esto puede causar confusión.
actividades, modelos y consideraciones prácticas para la implementación de
procesos y el cambio. Aquí descrito es la situación en la que los procesos son
pleados de- por primera vez (por ejemplo, la introducción de un proceso de inspec-
Uno de los significados, donde la palabra el se utiliza, como en el
ción dentro de un proyecto o un método que cubre el ciclo de vida completo), y donde
proceso de ingeniería de software, podría implicar que sólo hay una
se cambian los procesos actuales (por ejemplo, la introducción de una herramienta, o
manera correcta de realizar tareas de ingeniería de software. Este
la optimización de un procedimiento). Esto también puede ser denominado evolución
significado se evita en la Guía, porque no existe tal proceso. Normas tales
del proceso. En ambos casos, las prácticas existentes tienen que ser modificados. Si
como IEEE12207 hablan de la ingeniería de software procesos, lo que
las modificaciones son extensas, a continuación, también pueden ser necesarios
significa que hay muchos procesos que intervienen, tales como Proceso de
cambios en la cultura organizativa.
desa- rrollo o Proceso de Gestión de la Configuración. Un segundo
significado se refiere a la discusión general de los procesos relacionados
con la ingeniería de software. Este es el significado previsto en el título de
este KA, y la que más se pretende en la descripción KA. Finalmente, un
tercer significado podría significar el conjunto real de las actividades
realizadas dentro de una organización, lo que podría ser visto como un
proceso, especialmente desde dentro

© IEEE - 2004 Versión 9-1

 Proceso de Ingeniería
de Software

Implementación
Proceso y
de procesos y el Definición del Evaluación del
medición del
Cambio proceso proceso
producto

Modelos de Ciclo de vida del Modelos de evaluación de

Infraestructura Medición de procesos
software procesos
proceso

Ciclo de software de Ciclo de vida del Métodos de Los productos de software

gestión de procesos software Procesos evaluación de de medición

procesos

Modelos para la
Notaciones para Calidad de los resultados de
implementación de procesos
Definiciones de medición
y Cambio
procesos

Información de software
Consideraciones La adaptación de procesos
Modelos
prácticas

Técnicas
Automatización
proceso de
medición

Figura 1. Desglose de los temas para el Proceso de Ingeniería de Software KA

1.1. infraestructura de procesos establecer, tal como un comité directivo para supervisar el esfuerzo proceso de

[IEEE12207.0-96; ISO15504-98; SEL96] Este tema incluye los conocimientos ingeniería de software. Una descripción de una infraestructura para la mejora del
proceso en general se proporciona en [McF96]. Existen dos tipos principales de
relacionados con la infraestructura de procesos de ingeniería de software.
infraestruc- tura se utilizan en la práctica: la Ingeniería de Software Grupo de
Procesos y la fábrica de experiencia.
Para establecer los procesos del ciclo de vida del software, es necesario contar con
una infraestructura adecuada en el lugar, lo que significa que los recursos deben
1.1.1. Procesos de Software Engineering Group (SEPG) La SEPG está
estar disponibles (personal competente, herramientas y financiación) y las
destinado a ser el foco central de la mejora de procesos de ingeniería de
responsabilidades asignadas. Cuando estas tareas se han completado, es una
indicación del compromiso de ges- tión para ción, y la propiedad de, el software en- software, y tiene una serie de responsabilidades en cuanto a la iniciación y el

esfuerzo gineering proceso. Varios comités pueden tener que mantenimiento de la misma. Estos se describen en [Fow90].

9-2 © IEEE - 2004 Versión

1.1.2. Experience Factory (EF) Directrices sobre la aplicación del proceso y el cambio dentro de las

El concepto de la EF separa la organización del proyecto (la organización
de desarrollo de software, por ejemplo) de la Organización de Mejora. La
organización del proyecto se centra en el desarrollo y mantenimiento de
software, mientras que la EF tiene que ver con la mejora de ingeniería de
software proc- ess.
organizaciones de ingeniería de software, incluyendo la planificación de acciones,
la formación, la gestión de patrocinio y compromiso, y la selección de proyectos
piloto y que cubren tanto los procesos y herramientas, se dan en [Moi98; San98;
Sti99]. se reportan estudios empíricos sobre los factores de éxito para el cambio
en el proceso (ElE99a). El papel de agentes de cambio en esta actividad se
discute en (Hut94). implementación de procesos y el cambio también puede ser

La EF se pretende institucionalizar el aprendizaje colectivo de una organización visto como una instancia de consultoría (ya sea interna o externamente nal).
mediante el desarrollo, la actualización y la entrega a la organización del proyecto paquetes
de experiencia ( por ejem- plo, guías, modelos y cursos de formación), también
conocida como activos de los procesos. La organización del proyecto ofrece la EF
sus productos, los planes utilizados en su desarrollo, y los datos recogidos durante
Uno puede también ver el cambio organizativo de la perspec- tiva de transferencia
el desarrollo y funcionamiento. Ejemplos de paquetes de experiencia se presentan
de tecnología (Rog83). artículos de ingeniería de software que discuten la
en [Bas92].
transferencia de tecnología y las Características de los receptores de las nuevas
tecnologías (que podría in- tecnologías relacionadas con los procesos clude) son
1.2. ciclo de gestión de procesos de software
(Pfl99; Rag89). Hay dos maneras de abordar el proceso de evaluación de la
[Bas92; Fow90; IEEE12207.0-96; ISO15504-98;
aplicación y el cambio, ya sea en términos de cambios en el proceso en sí mismo o
Mcf96; SEL96]
en términos de cambios en los resultados del proceso (por ejemplo, la medición del
La gestión de los procesos de software consta de cuatro actividades retorno de la inversión de hacer el cambio). Una mirada pragmática en lo que
secuenciadas en un ciclo iterativo que permite la retroalimentación continuas puede lograrse a partir de tales estudios de evaluación se da en (Her98). Una
con y mejora del proceso de software: visión general de cómo evaluar la implementación de procesos y el cambio, y
ejemplos de estudios que lo hacen, se pueden encontrar en [Gol99], (Kit98; Kra99;
los Establecer la infraestructura Proceso la actividad consiste en establecer
McG94).
el compromiso para procesar la aplicación y el cambio (incluyendo la
obtención de gestión de buy-in), y la puesta en marcha de una
infraestructura adecuada (fuentes y responsabilidades re) para que esto
ocurra. El objetivo de la Planificación la actividad es entender los objetivos
2. Definición del proceso
de negocio y las necesidades del proceso de la persona, proyecto o la
Una definición de proceso puede ser un procedimiento, una política o una Dard
organización actual, para identificar sus fortalezas y debilidades, y para
Están-. los procesos del ciclo de vida del software se definen para un nú- mero de
hacer un plan para la implementación de procesos y el cambio. El objetivo
razones, incluyendo el aumento de la calidad del pro- ducto, lo que facilita la
de Implementación de procesos y el Cambio es ejecutar el plan,
comprensión humana y la comunicación, el apoyo a la mejora de procesos,
implementar nuevos procesos (que pueden incluir, por ejemplo, el
apoyando el proceso de agement hombre-, proporcionar orientación proceso
despliegue de herramientas y la formación del personal), y / o cambiar los
automatizado, y la disponibilidad automatizada apoyo ejecución. Los tipos de
procesos existentes.
definiciones de procesos necesarios dependerá, al menos en parte, de la razón de la
definición.

Evaluación del proceso se ocupa de averiguar qué tan bien fueron la puesta
También hay que señalar que el contexto del proyecto y la organización
en práctica y el cambio, si los beneficios esperados se materializaron. Los
determinará el tipo de definición de proceso que es más útil. Las variables
resultados se utilizan entonces como entrada para los ciclos posteriores.
importantes a tener en cuenta incluyen la naturaleza de la obra (por ejemplo,
el mantenimiento o desa- rrollo), el dominio de aplicación, el modelo de ciclo
1.3. Modelos para la implementación de procesos y el cambio de vida y la madurez de la organización.
Dos modelos generales que han surgido para conducir la implementación de
procesos y el cambio son la Mejora paradigma de la calidad (PMC) [SEL96] y
2.1. Los modelos del ciclo de vida del software
el modelo ideal [McF96]. Los dos paradigmas se comparan en [SEL96].
Evaluación de la aplicación y los resultados del proceso de cambio puede ser [Pfl01: c2; IEEE12207.0-96] modelos del ciclo de vida del software sirven como

cualitativa o cuantitativa.
1.4. Consideraciones prácticas
implementación de procesos y el cambio constituyen una instancia de cambio
organizativo. La mayoría de los esfuerzos exitosos de cambio organizacional
tratan el cambio como un proyecto en sí mismo, con planes apropiados, monitoreo
y revisión.
una definición de alto nivel de las fases que se producen durante el desarrollo. Ellos
no tienen por objeto proporcionar definiciones detalladas, pero al poner de relieve las
actividades clave y sus interdependencias. Ejemplos de modelos de ciclo de vida del
software son el modelo de cascada, el modelo de prototipos de usar y tirar, desarrollo
evolutivo, entrega incrementales / iterativo, el modelo espiral, modelo de software
reutilizable, y la síntesis de software automatizado. Las comparaciones

© IEEE - 2004 Versión 9-3

hijos de estos modelos se proporcionan en [Com97], (Dav88), y un método para
seleccionar entre muchos de ellos en (ale91).
2.2. los procesos del ciclo de vida del software
Las definiciones de los procesos del ciclo de vida del software tienden a ser más detallados que
los modelos del ciclo de vida del software. Sin embargo, los procesos del ciclo de vida del
software no intentan ordenar sus procesos en el tiempo. Esto significa que, en principio, los
procesos del ciclo de vida del software se pueden organizar para adaptarse a cualquiera de los
modelos del ciclo de vida del software. La principal referencia en esta área es IEEE / EIA
12.207,0: Tecnología de la Información - Procesos del ciclo de vida del software [ IEEE12207.0-96].
que está destinada a armonizar las notaciones de modelado. Esto se denomina
El IEEE 1074: 1997 en los procesos del ciclo de vida de desarrollo también
proporciona una lista de los procesos y actividades para el desarrollo y
mantenimiento de software [IEEE1074-97], así como una lista de actividades del
ciclo de vida que se pueden asignar a los procesos y organizadas de la misma así
como cualquiera de los modelos del ciclo de vida del software. Además, identifica
y une a otros estándares de software IEEE a estas actividades. En principio, IEEE
Std 1074 se puede utilizar para construir procesos que se ajusten a cualquiera de
los modelos de ciclo de vida. Normas que se centran en los procesos de
mantenimiento son: IEEE Std 1219- 1998 e ISO 14764: 1998 [IEEE1219-98].
Otras normas importantes que proporcionan las definiciones de proceso incluyen:
IEEE Std 1540: Software de Gestión de Riesgos (IEEE1540-01)
IEEE Std 1517: Procesos de reutilización de software (IEEE1517-
99)
ISO / IEC 15939: Proceso de medida Software [ISO15939-02]. Ver
también la Dirección de Ingeniería de Software KA para una
descripción detallada de este proceso.
En algunas situaciones, los procesos de ingeniería de software deben
definirse teniendo en cuenta los procesos de organización para la gestión de
la calidad. ISO 9001 [ISO9001-00] proporciona los requisitos para los
procesos de gestión de calidad, e ISO / IEC 90003 interpreta los requisitos
para organiza- ciones de desarrollo de software (ISO9003-04).
Algunos procesos del ciclo de vida del software hacen hincapié en la rápida ery
deliv- y fuerte participación de los usuarios, es decir, métodos ágiles como Extreme
Programming [Bec99]. Una forma del problema selec- ción se refiere a la elección a
lo largo del plan- impulsado eje método ágil. Un enfoque basado en el riesgo de
tomar esa decisión se describe en (Boe03a).
2.3. Notaciones para Definiciones de procesos
Los procesos pueden ser definidas en diferentes niveles de abstracción (por
ejemplo, definiciones genéricas vs. definiciones adaptadas, descriptivo vs.
prescriptivo vs. proscriptivas) [Pfl01]. Variabilidad elementos OU de un proceso
pueden ser definidas, por ejemplo, activi- dades, los productos (artefactos), y
recursos. obras marcos detallada que la estructura de los tipos de información
necesaria para definir procesos se describen en (Mad94).
9-4
Hay un número de notaciones que se utilizan para definir pro- cesos (SPC92).
Una diferencia clave entre ellos es en el tipo de información de los marcos
mencionados anteriormente de- fina, la captura y el uso. El ingeniero de software
debe ser consciente de los siguientes enfoques: el flujo de datos diagramas, en
cuanto a la finalidad del proceso y los resultados [ISO15504-98], como una lista
de procesos descompuesto en actividades que lo componen y las tareas
definidas en lenguaje natural [IEEE12207.0-96] , Statecharts (Har98), ETVX
(Rad85), modelado (Yu94), SADT notación (Mcg93), redes de Petri (Ban95)
Actor-Dependencia; IDEF0 (IEEE1320.1-98), y basado en reglas (Bar95). Más
recientemente, un estándar de modelado de procesos se ha publican los OMG
la SPEM (Proceso de Ingeniería de Software Meta-Modelo) especificación.
[OMG02]
2.4. proceso de adaptación
[IEEE12207.0-96; ISO15504-98; Joh99] Es importante tener en cuenta que los
procesos predefinidos -incluso los estandarizadas-deben ser adaptados a las
necesidades locales, por ejemplo, el contexto organizacional, el tamaño del proyecto,
los requisitos normativos, prácticas de la industria, y las culturas corporativas.
Algunos estándares, tales como IEEE / EIA 12207, contienen mecanismos y
recomendaciones para llevar a cabo la adaptación.
2.5. Automatización
[Pfl01: c2]
Las herramientas automatizadas o bien apoyan la ejecución de las definiciones de proceso
o que proporcionan una guía para los seres humanos que realizan los procesos definidos.
En los casos en que se realizó el análisis de proceso, algunas herramientas permiten
diferentes tipos de simulaciones (por ejemplo, de simulación de eventos discretos). Además,
existen herramientas que soportan cada una de las notaciones de definición de procesos
anteriores. Además, estas herramientas pueden eje- lindo definiciones del proceso para
proporcionar soporte automatizado para los procesos reales, o para automatizar
completamente en algunos casos. Una visión general de las herramientas de modelado de
procesos se puede encontrar en [Fin94] y de entornos de proceso centrado en (Gar96). El
trabajo sobre la aplicación de la Internet para el suministro de orientación proceso en tiempo
real se describe en (Kel98).
3. Proceso de Evaluación
evaluación de proceso se lleva a cabo utilizando tanto un modelo de evaluación y un
método de evaluación. En algunos casos, el término “valoración” se utiliza en lugar
de la evaluación, y el término “evaluación de la capacidad” se utiliza cuando la
valoración es el propósito de la adjudicación de un contrato.
3.1. modelos de evaluación de proceso
Un modelo de evaluación capta lo que se reconoce como buenas prácticas.
Estas prácticas pueden referirse a las actividades técnicas de ingeniería de
software solamente, o también puede referirse a, por ejem- plo, la gestión, la
ingeniería de sistemas y actividades de gestión de re- cursos humanos
también. ISO / IEC 15504 [ISO15504-98] define un ejemplo requisitos as-
modelo sessment y la conformidad en otra
© IEEE - 2004 Versión
modelos de evaluación. modelos de evaluación específicos disponibles y en
uso son Sw-CMM (SEI95), CMMi • [ SEI01], y Bootstrap [Sti99]. Muchos otros
modelos de capacidad y madurez han sido definidos, por ejemplo, para el
diseño, docu- mentación, y los métodos formales, para nombrar unos pocos.
ISO 9001 es otro modelo de evaluación común que ha sido aplicado por las
organizaciones de software (ISO9001-00).
Un modelo de madurez para la ingeniería de sistemas también se ha
desarrollado, lo que sería útil cuando un proyecto o nización or- está
involucrado en el desarrollo y mantenimiento de sistemas, incluyendo software
(EIA / IS731-99). La aplicabilidad de los modelos de evaluación de organiza-
ciones pequeñas se aborda en [Joh99; San98].
Hay dos arquitecturas generales de un modelo de evaluación que hacen
diferentes hipótesis sobre el orden en que se deben evaluar procesos:
continua y organizaron (Pau94). Son muy diferentes, y deben ser
evaluados por la organización teniendo en cuenta que les permite
determinar cuál sería el más pertinente a sus necesidades y objetivos.
3.2. métodos de evaluación de procesos
[Gol99]
Con el fin de realizar una evaluación, un método de evaluación específico
debe ser seguido para producir una puntuación cuantitativa que
caracteriza la capacidad del proceso (o madurez de la organización).
El método de evaluación CBA-IPI, por ejemplo, se centró en la mejora de
procesos (Dun96) y el método SCE se centró en evaluar la capacidad de
los proveedores (Bar95). Ambos fueron desarrollados para el SW-CMM.
los requisitos de ambos tipos de métodos que reflejan lo que se BE-
gravada por ser buenas prácticas de evaluación se proporcionan en
[ISO15504-98], (Mas95). Los métodos SCAMPI se orientan hacia CMMi • evaluaciones
[SEI01]. Las actividades realizadas durante una evaluación, la distribución
del esfuerzo en estas actividades, así como la atmósfera durante una
evaluación son diferentes cuando están de mejora que cuando están de
adjudicación del contrato.
Ha habido críticas de los modelos y métodos de evaluación de procesos, por
ejemplo (Fay97; Gra98). La mayor parte de estas críticas se han
preocupado con la evidencia empírica que apoya el uso de modelos y
métodos de evaluación. Sin embargo, desde la publicación de estos
artículos, no ha habido alguna evidencia sistemática que apoya la eficacia
de las evaluaciones de proceso. (Cla97; Ele00; Ele00a; Kri99)
4. Proceso y medición del producto
Si bien la aplicación de la medida de ingeniería de software puede ser
compleja, sobre todo en cuanto a los métodos de análisis y modelado, hay
varios aspectos del software de en- gineering de medición que son
fundamentales y que subyacen en muchos de los procesos de medición y
análisis más avanzados. Además, el logro de proceso
© IEEE - 2004 Versión
y los esfuerzos de mejora de producto sólo se puede evaluar si se ha establecido
un conjunto de medidas de referencia. La medición se puede realizar para
apoyar el inicio de la implementación de procesos y cambiar o para evaluar las
consecuencias de la aplicación del proceso y el cambio, o puede llevarse a cabo
en el propio producto. Términos clave sobre las medidas de software y métodos
de medición se han definido en la norma ISO / IEC 15939 sobre la base del
vocabulario internacional ISO de la metrología. ISO / IEC 15359 también
proporciona un procedimiento estándar para la medición de ambas
características del proceso y del producto. [VIM93] Sin embargo, los lectores
encontrarán diferencias terminológicas en la literatura; Por ejemplo, el término
“métrica” se usa a veces en lugar de “medida”.
4.1. medición de procesos
[ISO15539-02]
El término “medición del proceso” como se usa aquí significa que la
información cuantitativa acerca del proceso se recoge, ana- lisó, e
interpretado. La medición se utiliza para identificar las fortalezas y
debilidades de los procesos, y para evaluar los procesos después de que
se han aplicado y / o cambiado.
de control de proceso puede servir para otros propósitos también. Por ejemplo, la
medición del proceso es útil para la gestión de un proyecto de ingeniería de software.
Aquí, la atención se centra en la medición del proceso con el propósito de la
implementación de procesos y el cambio.
El diagrama de ruta en la figura 2 ilustra un importante consumo como- hecho en la
mayoría de los proyectos de ingeniería de software, que es que por lo general el
proceso tiene un impacto en los resultados del proyecto. El contexto afecta a la
relación entre los resultados del proceso y del proceso. Esto significa que esta
relación de resultado de proceso a proceso depende del contexto. No todos los
procesos tendrá un impacto positivo en todo viene OUT-. Por ejemplo, la
introducción de software de inspección ciones puede reducir el esfuerzo y el costo
de pruebas, pero puede aumentar el tiempo transcurrido si cada inspección
introduce largas demoras debido a la programación de las reuniones de inspección
de gran tamaño. (Vot93) Por lo tanto, es preferible utilizar múltiples medidas de
resultado procesos que son importantes para Ness Busi- de la organización.
Mientras que un poco de esfuerzo se puede hacer para evaluar la utilización de
herramientas y hardware, el principal recurso que necesita ser gestionado en la
ingeniería de software es el personal. Como resultado, las principales medidas de
interés son los relacionados con la productividad de los equipos o procesos (por
ejemplo, usando un Ure medi- de puntos de función producidas por unidad de
esfuerzo-persona) y sus correspondientes niveles de experiencia en software de
engi - niería en general, y tal vez en tecnologías particulares. [Fen98: c3, c11;
Som05: c25]
los resultados del proceso podrían, por ejemplo, la calidad del producto (por
faltas KLOC (Kilo líneas de código) o por Función
9-5
Punto (FP)), facilidad de mantenimiento (el esfuerzo para hacer un determinado
tipo de cambio), la productividad (LOC (líneas de código) o puntos de función por
persona-mes), el tiempo de salida al mercado, o cliente central Tomer satisfacción
(medido a través de un sur- vey cliente). Esta relación depende del contexto
particular (por ejemplo, tamaño de la organización o el tamaño de la Ject pro-).
En general, estamos más preocupados por los resultados del proceso. Sin embargo,
con el fin de lograr los resultados del proceso que deseamos (por ejemplo, mejor
calidad, mejor servicio de mantenimiento, una mayor satisfacción del cliente),
tenemos que implementar el proceso adecuado.
Por supuesto, no es sólo el proceso que tiene un impacto en los resultados.
Otros factores, como la capacidad del personal y las herramientas que se usan,
juegan un papel importante. Al evaluar el impacto de un cambio de proceso, por
ejemplo, es importante tener en cuenta estas otras influencias. Por otra parte, el
grado en que se institucionaliza el proceso (es decir, el proceso de fidelidad) es
importante, ya que puede explicar por qué los procesos de “buenas” no siempre
dan los resultados deseados en una situación dada.
proceso
Proceso
Resultados
Contexto
Figura 2 diagrama de Path que muestra la relación entre el proceso y los
resultados (resultados).
4.2. medición de producto de software
[ISO9126-01]
medida del producto de software incluye, en particular,
medición de tamaño del producto, la estructura del producto, y la calidad del producto.
4.2.1. medida del tamaño
tamaño del producto de software es más a menudo evaluado por medidas de
longitud (por ejemplo, líneas de código fuente en un módulo, las páginas de un
documento de especificación de requisitos de software), o la funcionalidad (por
ejemplo, puntos de función en una especificación). Los principios de medición de
tamaño funcional se proporcionan en IEEE Std. 14143.1. Las normas internacionales
para los métodos de medición de tamaño funcional incluyen ISO / IEC
19761, 20926 y 20968 [IEEE14143.1-00; ISO19761-03; ISO20926-03;
ISO20968-02].
4.2.2. estructura de medición
Una amplia gama de medidas de estructura de producto de software puede ser
aplicada a los artefactos tanto de diseño de alto y de bajo nivel y código para
reflejar el flujo de control (por ejemplo el número ciclomática, nudos de código), el
flujo de datos (por ejemplo, las medidas de corte en rodajas), nesting (por ejemplo,
la medida de anidación polinomio, la medida BAND), estructuras de control (por
ejemplo, la medida de vector, la medida NPATH), y la estructura modular y la
interacción (por ejemplo, flujo de información, medidas basadas en el árbol, de
acoplamiento y la cohesión). [Fen98: c8; Pre04: c15]
4.2.3. medición de la calidad
Como un atributo multidimensional, medición de la calidad es menos sencillo de
definir que los de arriba. ULTERIORES más, algunas de las dimensiones de la
calidad son propensos a volver a la medición mano de papel en forma
cualitativa más que cuantitativa. Una discusión más detallada de urement medi-
calidad del software se proporciona en la calidad del software KA, tema 4.4.
modelos ISO de la calidad del producto de software y de mediciones
relacionados se describen en ISO9126, partes 1 a 4 [ISO9126-01]. [Fen98: c9,
c10; Pre04: c15; Som05: c24]
4.3. Calidad de los resultados de medición
La calidad de los resultados de la medición (precisión, reproducibilidad,
repetibilidad, la convertibilidad, los errores de medición aleatorios) es esencial
para los programas de medición para proporcionar eficaz y delimitadas
resultados. Las características clave de los resultados de medición y la calidad
relacionada de los instrumentos de medición se han definido en cabulary la ISO
Internacional vo- en metrología. [VIM93] La teoría de la medición establece la
base sobre la cual se pueden hacer mediciones significativas. La teoría de los
tipos de medición y escala se discute en [Kan02]. La medición se define en la
teoría como “la asignación de números a los objetos de una manera sistemática
para representar como propiedades del objeto.”
Una apreciación de las escalas de medición de software y las implicaciones de
el cada tipo de escala en relación con la posterior selección de los métodos de
análisis de datos es especialmente importante. [Abr96; Fen98: c2; Pfl01: c11]
escalas significativas se re lated a una clasificación de las escalas. Para
aquellos, teoría de la medición ofrece una sucesión de más y más restringidos
formas de asignar las medidas. Si los números asignados son meramente para
proporcionar etiquetas para clasificar los objetos, se les llama nominal. Si se
asignan de manera que clasifica los objetos (por ejemplo, bueno, mejor, mejor),
se les llama
ordinal. Si se ocupan de magnitudes de la propiedad tivo relación a una
unidad de medida definida, se les llama intervalo
(Y los intervalos son uniformes entre los números a menos que se especifique lo
contrario, y son por lo tanto aditiva). Las mediciones se encuentran en el proporción nivel
si tienen un punto cero absoluto, por lo que las proporciones de las distancias al punto
cero son sentido- ful.
9-6 © IEEE - 2004 Versión
4.4. modelos de información de software
A medida que se recogen los datos y el repositorio de medición está poblado, nos
volvemos capaces de construir modelos utilizando los datos y el conocimiento.
Existen Estos modelos para los propósitos de análisis, ción clasifi-, y la
predicción. Tales modelos necesitan ser evaluados para asegurarse de que sus
niveles de precisión son suficientes y que sus limitaciones son conocidos y
entendidos. El refinamiento de los modelos, que tiene lugar durante y después de
los proyectos se han completado, es otra actividad importante.
4.4.1. Construcción del modelo
La construcción de modelos incluye tanto la calibración y evaluación del modelo.
El enfoque meta-conducido hasta la cota formas in- el proceso de construcción
de modelos en la medida en que los modelos se construyen para responder a las
preguntas pertinentes y lograr los objetivos de mejora de software. Este proceso
también se influida por las limitaciones implícitas de las escalas de medición
particulares en relación con la elección del método de análisis. Los modelos se
calibran (mediante el uso de observa- ciones de especial relevancia, por ejemplo,
los proyectos recientes, proyectos usando tecnología similar) y se evalúa su
eficacia (por ejemplo, ensayando su rendimiento en muestras de reserva).
[Fen98: c4, c6, c13; Pfl01: c3, c11, c12; Som05: c25]
4.4.2. implementación del modelo
implementación del modelo incluye tanto la interpretación y el refinamiento
de los modelos de los modelos calibrados se aplican al proceso, sus
resultados se interpretan y evalúan en el contexto del proceso / proyecto y
los modelos se refina en su caso. [Fen98: C6; Pfl01: c3, c11, c12; Pre04:
c22; Som05: c25]
4.5. técnicas de medición Proceso
técnicas de medición se pueden utilizar para analizar los procesos de ingeniería
de software y para identificar las fortalezas y debilidades. Esto se puede realizar
para iniciar la implementación de procesos y el cambio, o para evaluar las
consecuencias de la aplicación del proceso y el cambio.
La calidad de los resultados de las mediciones, tales como la precisión,
peatability re-, y la reproducibilidad, son temas en la medición de los procesos
de ingeniería de software, ya que hay dos mediciones basados ​en instrumentos
y de juicio, como, por ejemplo, cuando los evaluadores asignan puntuaciones a
un proceso particular. Una discusión y método para lograr la calidad de la
medición se presentan en [Gol99].
técnicas de medición de procesos se han clasificado en dos tipos
generales: analítica y la evaluación comparativa. Los dos tipos de técnicas
se pueden utilizar juntos desde que se basan en diferentes tipos de
información. (Car91)
© IEEE - 2004 Versión
4.5.1. Técnicas analíticas
Las técnicas analíticas se caracterizan como depender de “evidencia
cuantitativa para determinar dónde se necesitan mejoras y si una iniciativa
de mejora ha sido exitoso.” El tipo de análisis se ejemplifica por el dad
Mejora Paradigm cali- (QIP) que consiste en un ciclo de la comprensión, la
evaluación de , y el embalaje [SEL96]. Las técnicas presentadas siguiente
están pensados ​como otros ejemplos de técnicas analíticas, y reflejan lo
que se hace en la práctica. [Fen98; Mus99], (Lyu96; Wei93, Zel98) Sea o
no una organización específica utiliza todas estas técnicas dependerán, al
menos parcialmente, en su madurez.
• Estudios experimentales: La experimentación implica la creación de
experimentos controlados o casi en la organización para evaluar los
procesos. (McG94) Por lo general, un nuevo proceso se compara con el
proceso actual para determinar si es o no el primero tiene mejores
resultados del proceso.
Otro tipo de estudio experimental es la simulación de procesos. Este tipo de
estudio puede ser utilizado para analizar el comportamiento del proceso,
proceso de explorar mejora
potenciales, predicen los resultados del proceso si el proceso actual se
cambia de una manera determinada, y la ejecución de los procesos de control.
Los datos iniciales sobre el rendimiento del proceso actual necesitan ser
recogidos, sin embargo, como base para la simulación.
• Revisión de Definición de procesos es un medio por el cual se
revisa una definición de proceso (ya sea un descriptivo o un ser
prescriptivo, o ambos), y las deficiencias y mejoras potenciales
proceso identificado. Ejemplos típicos de este se presentan en
(Ban95; Kel98). Una manera operativa fácil de analizar un proceso
es compararlo
a una norma vigente (nacional,
internacional o colegio profesional), tales como IEEE / EIA
12207.0 [IEEE12207.0-96]. Con esta enfoque,
datos cuantitativos no se recogen en el proceso, o, si lo son, que
desempeñan un papel de apoyo. Los individuos que realizan el análisis de
la definición del proceso utilizan sus conocimientos y capacidades para
decidir qué cambios proceso potencialmente podría conducir a los
resultados del proceso deseables. Los estudios de observación también
pueden proporcionar útil
retroalimentación para el proceso de identificación
mejoras. (Agr99)
• ortogonal Defecto do CLASIFICACIÓN es una técnica que puede ser
utilizada para enlazar los fallos encontrados con causas potenciales. Se basa
en una asignación entre los tipos de fallos y los factores desencadenantes de
falla. (Chi92; Chi96) la norma IEEE sobre la clasificación de fallas (o
anomalías) puede ser útil en este contexto ( Norma IEEE para la Clasificación
de Software de Anomalías ( IEEE1044-93).
Raíz do ausa UN nálisis es otra técnica analítica común que se utiliza
en la práctica. Esto implica que se remontan de problemas
detectados (por ejemplo, fallos) para identificar las causas de
proceso, con el objetivo de
9-7
 cambiar el proceso para evitar estos problemas en el futuro.
Ejemplos de diferentes tipos de procesos se describen en (Col93;
Ele97; Nak91).
La técnica de clasificación de defectos ortogonal se des- cribe más arriba
se puede utilizar para encontrar catagories en el que existen muchos
problemas, momento en el que se pueden analizar. Clasificación de
defectos ortogonales es, pues, una técnica utilizada para realizar una
selección cuantitativa de dónde análisis de causa raíz.
• Control del Proceso Estadístico es una manera eficaz de
identificar la estabilidad, o la falta de ella, en el proceso a través del
uso de gráficos de control y sus interpretaciones. Una buena
introducción a SPC en el contexto de la ingeniería de software se
presenta en (Flo99).
• los Personal Software Process define una serie de mejoras en
las prácticas de desarrollo de un individuo
9-8
en un orden especificado [Hum95]. Es 'abajo hacia arriba' en el sentido de
que prevé la recogida de datos personales y mejoras basadas en las
interpretaciones de datos.
4.5.2. Evaluación comparativa de las técnicas El segundo tipo de técnica, la
evaluación comparativa, “depende de la identificación de un 'excelente'
organización en un campo y docu- mentar sus prácticas y herramientas.”
Evaluación comparativa supone que si una organización menos-competente
adopta las prácticas de la excelente organización, también será excelente. La
evaluación comparativa implica la evaluación de la madurez de una or- ganización
o la capacidad de sus procesos. Se ejemplifica se ficado por el trabajo de
evaluación de procesos de software. Una introducción general a las evaluaciones
de proceso y su aplicación se proporciona en (Zah98).
© IEEE - 2004 Versión
 9-9

*
*
*

*
c12
c6

c25
c22
C3, C11
,

c12
13 6, c
c4, c

C3, C11

Implementación
c2

c11
c10

c24
c15
c8

c 11

c25

[Bas92] [Com97] [Fin94] [Fow 9 0] [Gol99] [Joh99] [McF 9 6] [Mo i9 8] [Mu s9 9] [OM G
c3,

[Pfl 0 1] [Pre04]
[Bec99] [San98]
[Boe03][SEI 0 1] [SEL96]
[Fen98] [Som05] [Sti99]
*
*

*
*
*
*
*

c2
*

c2
*
*

c2

*
*
*
*

*
*

*
*
*
*

*
*
*
*
METRO ATERIAL
 * *

* * * * *

* *

*
9-10

* * * * * * * *
© IEEE - 2004 Versión

* *

* *

9001 ISO 9000-3 ISO 9126 ISO 14764 ISO 15504 ISO 15288 ISO 15939 ISO 19761 ISO 20926 ISO 20968 ISO VIM IEEE 1044 IEE mi 1061 IEEE 1074 IE
1219 IEEE 1517 IEEE 1540 IEEE IEEE 12207 14143.1

R ECOMMENDED R EFERENCIAS
[Abr96] A. Abran y PN Robillard, "Análisis de Puntos de Función: un
estudio empírico de sus eses Medición Proc-" IEEE Transactions on
Software Engineering, vol.
22, 895-909, 1996
[Bas92] V. Basili, G. Caldiera, F. McGarry, R. Pajerski, G. y S. Página
Waligora, "El toria Software Engineering Laboratory - Una fábrica de
Software de Operación Experiencia," pre-tantes en las Actas de la
Internacional Conferencia sobre Ingeniería de Software, 1992 [Bec99] K.
Beck, Extreme Programming Explained: Em- Cambio corsé: Addison-Wesley,
1999.
[Boe03] B. Boehm y R. Turner, "Uso de riesgo para el Equilibrar ágil y
Driven-Plan Métodos," Computadora, 57-66, junio de 2003
[Com97] E. Comer, "dels Software alternativo Ciclo de Vida Mo-",
presentado en Ingeniería de Software, 1997 [ElE99] K. El-Emam y N.
Madhavji, Elementos de Soft-ware y Evaluación de Procesos de Mejora: IEEE
CS Press, 1999.
[Fen98] NE Fenton y Pfleeger SL, Las métricas de software: un enfoque
riguroso y práctico, Segunda ed: International Thomson Computer Press,
1998.
[Fin94] A. Finkelstein, J. Kramer y B. Nuseibeh, "Modelado Soft- Proceso
Ware y Tecnología," Investigación de Estudios Press Ltd., 1994
[Fow90] P. Fowler y S. Rifkin, "Guía de Grupo de Procesos de Ingeniería
de Software," Software Engineering Institute, Informe Técnico CMU /
SEI-90-TR-24, 1990, disponible en http://www.sei.cmu.edu
/pub/documents/90.reports/pdf/tr24.
90.pdf
[Gol99] D. Goldenson, K. El-Emam, J. Herbsleb y C. Deephouse, "Estudios
empíricos de métodos de evaluación de procesos de software", presentado
en elementos de la evaluación de procesos de software y mejora, 1999
[IEEE1074-97] IEEE Std 1074-1997, Norma IEEE para el desarrollo de
procesos del ciclo de vida del software: IEEE, 1997. [IEEE12207.0-96]
IEEE / EIA 12207.0-
1996 // ISO / IEC12207: 1995, Implementación de la industria Int. Std. ISO /
IEC 12207: 95, Norma de Información tecnolo- gía-Software Procesos del
ciclo de vida, vol. IEEE, 1996. [VIM93] ISO VIM, Vocabulario Internacional de
Términos Básicos y Generales de Metrología. Ginebra, Suiza: ISO,
1993.
[ISO9126-01] ISO / IEC 9126-1: 2001, Ingeniería de software, la calidad del
producto-Parte 1: Modelo de Calidad: ISO e IEC,
2001.
© IEEE - 2004 Versión
[ISO15504-98] ISO / IEC TR 15504: 1998, Tecnología de la Información -
Evaluación de Procesos de Software (partes 1-9): ISO e IEC, 1998.
[ISO15939-02] ISO / IEC 15939: 2002, Software Engineer--ing software de
proceso de medición: ISO e IEC, 2002. [Joh99] D. Johnson y J. Brodman,
"Adaptación de la CMM para las pequeñas empresas, organizaciones
pequeñas y Jects Pequeño Pro-", presentado en Elementos de Assessment
ción de Procesos de Software y Mejora ,, 1999
[McF96] B. McFeeley, "IDEAL: instrucciones de uso para la mejora de
procesos de software", tute Ingeniería de Software Ins-
CMU / SEI-96-HB-001, 1996, disponible a
http://www.sei.cmu.edu/pub/documents/96.reports/pdf/hb0
01.96.pdf
[Moi98] D. Moitra, "Gestión del cambio de iniciativas de mejora del
software Proc- ess: Un enfoque práctico basado en la experiencia," Proceso
de Software - Mejora y Práctica,
vol. 4, ISS. 4, 199-207, 1998 [Mus99] J. Musa, Software de Ingeniería de
Confiabilidad: el software más fiable, más rápido desarrollo y pruebas:
McGraw Hill, 1999.
[OMG02] Object Management Group, "Proceso de Ingeniería de Software
Metamodel Especificación", 2002, disponible en
http://www.omg.org/docs/formal/02-11-14.pdf [Pfl01] Pfleeger SL, Ingeniería
de Software: Teoría y Práctica, Segunda ed: Prentice-Hall, 2001. [] Pre04 RS
Pressman, Ingeniería de Software: Un Enfoque de Tioner prác-, ed Sexto:
McGraw-Hill, 2004. [San98] M. Sanders, "El Manual CHAPITEL: mejor, más
rápido, más barato Desarrollo de Software en Pequeñas Organizaciones"
Comisión Europea, 1998
[SEI01] Software Engineering Institute, "Capacidad madurando dad Modelo
Integración, v1.1 ", 2001, disponible en
http://www.sei.cmu.edu/cmmi/cmmi.html [SEL96] Laboratorio de
Ingeniería de Software, "Software Pro- ceso Guía de Mejora", NASA /
GSFC, Informe Técnico
SEL-95-102, Abril, 1996, disponible a
http://sel.gsfc.nasa.gov/website/documents/online-doc/95-
102.pdf [Som05] I. Sommerville, Ingeniería de software, Séptima edición:
Addison-Wesley, 2005.
[Sti99] H. Stienen, "Evaluación del Proceso de Software y mejoría: 5 años
de experiencias con Bootstrap," en
Elementos de Evaluación de Procesos de Software y la mejora, K.
El-Emam y N. Madhavji, Eds .: IEEE CS Press,
1999.
9-11

Apéndice A. Lista de lecturas recomendadas
(Agr99) W. Agresti, "El papel de Diseño y Análisis en la mejora de
procesos", presentado en Elementos de Evaluación de Procesos de
Software y mejora, 1999
(Ale91) L. Alexander y A. Davis, "Criterios de selección de modelos de
procesos de software", presentado en Proceedings de COMPSAC'91, 1991
(Ban95) S. Bandinelli, A. Fuggetta, L. Lavazza, M. Loi y
G. Picco, "Modelado y Mejora de un proceso de software industrial," IEEE
Transactions on Software Engineering, vol.
21, ISS. 5, 440-454, 1995
(Bar95) N. Barghouti, D. Rosenblum, D. Belanger y C. Alliegro, "dos
estudios de caso en el modelado real, los procesos corporativos," Proceso
de Software - Mejora y Práctica,
vol. Edición piloto, 17-32, 1995 (Boe03a) B. Boehm y R. Turner, Equilibrar
la agilidad y disciplina: una guía para los perplejos: Addison-Wesley,
2003.
(Bur99) I. Burnstein, A. Homyen, T. Suwanassart, G. y R. saxofón ena
Grom, "Un Modelo de Madurez de Pruebas de Software Test de Evaluación
y mejora de procesos" Software de calidad profesional, vol. 1, ISS. 4, 8-21,
1999 (Chi92) R. Chillarege, I. Bhandhari, J. Chaar, M. Halliday,
D. Moebus, B. Ray y M. Wong, "ortogonal Clasificación Defecto - A
Concepto para la medición en proceso,"
IEEE Transactions on Software Engineering, vol. 18, ISS.
11, 943-956, 1992
(Chi96) R. Chillarege, "ortogonal Clasificación de defectos", en Manual de
Software Ingeniería de Confiabilidad, M. Lyu, Ed .: IEEE CS Press, 1996.
(Col93) J. Collofello y B. Gosalia, "una aplicación del análisis causal con el
proceso de producción de software" Práctica soft- ware y experiencia, vol.
23, ISS. 10, 1095-1105, 1993
(Cur02) B. Curtis, W. Hefley y S. Miller, "El Modelo de Madurez de
Capacidad de Personas: directrices para mejorar la fuerza de trabajo",
Addison-Wesley, 2002.
(Dav88) A. Davis, E. Bersoff y E. Comer, "Una estrategia para comparar
alternativa de vida de desarrollo del software Modelos de Ciclo" IEEE
Transactions on ingeniería de software, vol. 14, ISS. 10, 1453-1461, 1988
(Dun96) D. Dunnaway y S. Masters, "CMM-Based Ap- praisal para la
mejora de procesos internos (CBA IPI): Me-DTO Descripción:" Ingeniería
de Software Instituto
CMU / SEI-96-TR-007, 1996, disponible
http://www.sei.cmu.edu/pub/documents/96.reports/pdf/tr00
7.96.pdf
(EIA / IS731-99) EIA, "EIA / IS 731 Capacidad de Ingeniería de Sistemas
Modelo," 1999, disponible
http://www.geia.org/eoc/G47/index.html
(Ele-97) K. El-Emam, D. Holtje y N. Madhavji, "Causal
El análisis de los requisitos de cambio de proceso para un sistema grande
"presentado en Proceedings of the ferencia Internacional sobre Con-
Mantenimiento de Software, 1997 (ELE-99a) K. El-Emam, B. Smith y P.
Fusaro," Factores de éxito y obstáculos en la mejora de proceso de
software: un estudio empírico," en Mejor Práctica de Software para
beneficio comercial: Principios y Experiencias, R. Messnarz y C. Tully, Eds .:
IEEE CS Press, 1999. (ele-00a) K. El-Emam y A. Birk, "Validación de las
ISO / IEC 15504 Medidas de desarrollo de software Proc- Capacidad ess" Diario
de sistemas y software, vol. 51, ISS. 2, 119-149, 2000
(ELE-00b) K. El-Emam y A. Birk, "Validación de las ISO / IEC 15504
Medidas de Requisitos de software Ana- lisis Proceso capacidad" IEEE
Transactions on Software Engineering, vol. 26, ISS. 6, 541-566, junio de
2000 (Fay97) M. Fayad y M. Laitinen, "Evaluación de proceso:
Considerado un desperdicio," Communications of the ACM, vol.
40, ISS. 11, noviembre de 1997 (Flo99) Florac W. y A. Carleton, La medición
del Proceso de Software: Control Estadístico de Procesos para la Mejora de
Procesos de Software: Addison Wesley, 1999. (Gar96) P. Garg y M.
Jazayeri, "centrada en procesos Cesión de Software Ingeniería Ambientes:
A Grand Tour", en Proceso de soft- ware, A. Fuggetta y A. Wolf, Eds .: John
Wiley & Sons, 1996. (Gra97) R. Grady, Proceso de Software exitosa
mejoría: Prentice Hall, 1997.
(Gra88) E. Gray y W. Smith, "Sobre las limitaciones de la evaluación de
procesos de software y el reconocimiento de un Re- quired Re-Orientación
para la Mejora del Proceso Global"
Software de calidad Diario, vol. 7, 21-34, 1998 (Har98) D. Harel y M. Politi, Modelado
de sistemas reactivos con Statecharts: El Enfoque Statemate: McGraw-Hill,
1998.
(Her98) J. Herbsleb, "Problemas duro y Ciencia duro: En los límites prácticos
de experimentación" IEEE TCSE Cesión de Software Boletín Process, vol. 11,
18-21, 1998, disponible en http://www.seg.iit.nrc.ca/SPN (Hum95) W.
Humphrey, Una disciplina para Software Inge- niería: Addison Wesley, 1995.
(Hum99) W. Humphrey, Una Introducción al Proceso de mercancías Equipo
Soft: Addison-Wesley, 1999. (Hut94) D. Hutton, Manual de Agentes de
Cambio: Una Guía para la super- vivencia de Campeones Mejora de la
Calidad: Irwin,
a 1994. (Kan02) SH Kan, Métricas y modelos de software en cali- dad de
Ingeniería, Segunda ed: Addison-Wesley, 2002. (Kel98) M. Kellner, U.
Becker-Kornstaedt, W. Riddle, J. Tomal y M. Verlage, "Proceso de guías:
Ance Guid- eficaz para el proceso de participantes", presentado en
a Proceedings de la 5ª Conferencia Internacional sobre el proceso de
software,
9-12 © IEEE - 2004 Versión
1998
(Kit98) B. Kitchenham, "Selección de Proyectos de Evaluación de
Tecnología" IEEE Software TCSE Boletín Process, ISS.
11, 3-6, 1998, disponible en http://www.seg.iit.nrc.ca/SPN (Kra99) H.
Krasner, "El beneficio para los Procesos de Software mejoría: ¿Qué es y
cómo conseguirlo ", presentado en Elementos de Evaluación de procesos
de Software y la mejora de 1999
(Kri99) MS Krishnan y M. Kellner, "Medición Proc- ess Consistencia:
Implicaciones para la Reducción de software defec- tos," IEEE
Transactions on Software Engineering, vol.
25, ISS. 6, 800-815, Noviembre / Diciembre, 1999 (Lyu96) MR Lyu, Manual
de Software Fiabilidad En- gineering: Mc Graw-Hill-/ IEEE, 1996.
(Mad94) N. Madhavji, D. Hoeltje, W. y Hong Haus T. Bruck-, "Elicit: Un método
para la obtención de modelos de procesos," pre-tantes en las Actas de la
Tercera Conferencia Internacional sobre el proceso de software, 1994
(Mas95) S. Masters y C. Bothwell, "CMM similares: Marco - Versión 1.0,"
Software Engineering Institute CMU / SEI-TR-95-001,
1995, disponible a
http://www.sei.cmu.edu/pub/documents/95.reports/pdf/tr00
1.95.pdf
(McG94) F. McGarry, R. Pajerski, G. Página, S. Waligora, V. Basili y M.
Zelkowitz, "Mejora de procesos de software en el Laboratorio de
Ingeniería NASA Software," Software Engineering Institute CMU /
SEI-94-TR- 22, 1994, disponible en
http://www.sei.cmu.edu/pub/documents/94.reports/pdf/tr22.
94.pdf
(McG01) J. McGarry, D. Card, C. Jones, B. Layman,
E.Clark, J. Dean y F. Hall, Software La medición práctica: información
objetiva para la Toma de Decisiones: Adiciones hijo-Wesley, 2001.
(Mcg93) C. McGowan y S. Bohner, "Sobre la base Modelo evaluaciones
Proc- ess", presentado en Actas de la Conferencia Interna- cional de
Ingeniería de Software, 1993 (Nak91) T. Nakajo y H. Kume, "Un Análisis
Historia del caso Software de error Relación causa-efecto" Trans- acciones
IEEE en Ingeniería de Software, vol. 17, ISS. 8, 1991 (Pau94) M. Paulk y M.
Konrad, "Proceso de medición de Ca pability Versus organizacional madurez
de los procesos," pre-tantes en las Actas de la cuarta Conferencia
Internacional sobre la Calidad del Software, 1994
(Pfl99) SL Pfleeger, "comprensión y mejora de Transferencia de
Tecnología en Ingeniería de Software" Diario de
© IEEE - 2004 Versión
Sistemas y software, vol. 47, 111-124, 1999 (Pfl01) Pfleeger SL, Ingeniería
de Software: Teoría y Práctica, Segunda ed: Prentice-Hall, Inc., 2001.
(Rad85) R. Radice, N. Roth, AOH Jr. y W. Ciarfella, "un proceso de
programación Arquitectura" IBM Systems Journal, vol. 24, ISS. 2, 79-90,
1985 (Rag89) S. Raghavan y D. Chand, "Difusión Software- Métodos de
ingeniería" IEEE Software, 81-90, Julio, 1989 (Rog83) E. Rogers, Difusión
de innovaciones: Prensa Libre,
1983. (Sch99) E. Schein, Proceso de consulta Revisited: Building Pro- la
relación de ayuda: Addison-Wesley, 1999. (SEI95) Software Engineering
Institute, El Modelo de Madurez de Capacidad: Directrices para la mejora
del proceso de software: Addison-Wesley, 1995. (SEL96) Laboratorio de
Ingeniería de Software, "Guía del software Pro- ceso de Mejora," Software
Engineering Laboratory: NASA / GSFC, Informe Técnico SEL-95-102,
Abril,
1996, disponible a
http://sel.gsfc.nasa.gov/website/documents/online-doc/95-
102.pdf
(SPC92) Productividad Software Consortium, "Proceso de defini- ción y
Modelado Guía," la productividad del software Consorcio,
SPC-92041-CMC, 1992 (Som97) I. Sommerville y P. Sawyer, Requisitos
en- gineering: Una guía de buenas prácticas: John Wiley and Sons,
1997.
(Vot93) L. Votta, "¿Cada Inspección Necesita una reunión?" ACM
Ingeniería de Software Notas, vol. 18, ISS. 5, 107-
114, 1993
(Wei93) GM Weinberg, "ment Software Quality Manage-" Medición de
primer orden (Ch. 8, medir el costo y valor), vol. 2, 1993
(Yu94) E. y J. Yu Mylopolous, "Descripción 'por qué' en el software de
modelado de procesos, análisis y diseño," pre-tantes en las Actas de la
16ª Conferencia Internacional sobre Ingeniería de Software, 1994 (Zah98)
S. Zahran, Mejora de Procesos de Software: prác- Directrices Cal para el
éxito del negocio: Addison Wesley,
1998.
(Zel98) MV Zelkowitz y DR Wallace, "Modelos experimentales para la
validación de la tecnología" Computadora, vol. 31, ISS.
5, 23-31, 1998
9-13

Apéndice B. Lista de Normas
(IEEE1044-93) IEEE Std 1044-1993 (R2002), Dard IEEE Están- para la
Clasificación de Software de Anomalías: IEEE,
1993.
(IEEE1061-98) IEEE Std 1061-1998, Norma IEEE para una metodología de
métricas de software de calidad: IEEE Computer,
1998.
(IEEE1074-97) IEEE Std 1074-1997, Norma IEEE para el desarrollo de
procesos del ciclo de vida del software: IEEE, 1997. (IEEE1219-98) IEEE
Std 1219-1998, Norma IEEE para Mantenimiento de Software: IEEE, 1998.
(IEEE1220-98) IEEE Std 1220-1998, Norma IEEE para la aplicación y
gestión del proceso de ing sistemas Engineer-: IEEE 1998.
(IEEE1517-99) IEEE Std 1517-1999, Norma IEEE sobre Tecnología de la
Información del Ciclo de Vida-Software Procesos procesos- Reutilización: IEEE
1999.
(IEEE1540-01) IEEE Std 1540-2001 // ISO / IEC16085: 2003,
Norma IEEE para procesos de riesgo del ciclo de vida del software Ma- nagement: IEEE,
2001. (IEEE12207.0-96)
IEEE / EIA 12207.0-
1996 // ISO / IEC12207: 1995, Implementación de la industria Int. Std. ISO / IEC
12207: 95, Norma de Información tecnolo- gía-Software Procesos del ciclo de
vida, vol. IEEE, 1996. (IEEE12207.1-96) IEEE / EIA 12207,1-1.996, Industria Im-
plementation de Int. Std. ISO / IEC 12207: 95, Norma para Tecnología de la
Información-Software Procesos del ciclo de vida - los datos del ciclo de vida: IEEE,
1996.
(IEEE12207.2-97) IEEE / EIA 12207,2-1.997, Industria Im- plementation de
Int. Std. ISO / IEC 12207: 95, Norma para Tecnología de la
Información-Software Procesos del ciclo de vida - Implementación.
consideraciones: IEEE 1997.
9-14
(IEEE14143.1-00) IEEE std 14143.1-
2000 // ISO / IEC14143-1: 1998, Tecnología Información-
Software de medición-funcional Medida del tamaño-Parte 1: Definiciones de
conceptos: IEEE, 2000. (ISO9001-00) ISO 9001: 2000, Gestión de la calidad
Systematic tems-Requisitos: ISO 1994. (ISO9126-01) ISO / IEC 9126-1: 2001,
Ingeniería de software, la calidad del producto-Parte 1: Modelo de Calidad: ISO
e IEC,
2001.
(ISO14674-99) ISO / IEC 14674: 1999, Información Tech- nology -
Mantenimiento de Software: ISO e IEC, 1999. (ISO15288-02) ISO / IEC
15288: 2002, Sistemas Engineer- ing-Sistema de proceso del ciclo de vida: ISO
e IEC, 2002. (ISO15504-98) ISO / IEC TR 15504: 1998, Tecnología de la
Información - Evaluación de Procesos de Software (partes 1-9): ISO e IEC,
1998. (ISO15939-02) ISO / IEC 15939: 2002, Software Engineer--ing software
de proceso de medición: ISO e IEC, 2002. (ISO19761-03) ISO / IEC 19761:
2003, Ingeniería de software-cósmico FPP-A Tamaño funcional Método de
medición:
ISO e IEC, 2003. (ISO20926-03) ISO / IEC 20926: 2003, Ingeniería de
software-IFPUG 4.1 Sin ajustar el tamaño bien funcional prácticas método
de conteo manual: ISO e IEC, 2003. (ISO20968-02) ISO / IEC 20968:
2002, Ingeniería de software MK-Función Punto Prácticas Contar
Analysis- Manual II: ISO e IEC, 2002. (ISO90003-04) ISO / IEC 90003:
2004, Software y Systematic TEMS Ingeniería-Directrices para la
aplicación de la norma ISO9001: 2000 para el software de la
computadora: ISO e IEC, 2004. (VIM93) ISO VIM, Vocabulario
Internacional de Términos Básicos y Generales de Metrología. Ginebra,
Suiza: ISO,
1993.
© IEEE - 2004 Versión
 do CAPÍTULO 10

S OFTWARE mi NGENIERÍA T Y OOLS METRO ÉTODOS

UN CRONYM Herramientas de ingeniería de software y métodos

CASO Asistida por Ordenador

Ingeniería de Software
Ingeniería de software Ingeniería de software
Herramientas métodos
yo INTRODUCCIÓN
Requisitos de Software Los métodos heurísticos
herramientas de desarrollo de software son las herramientas informáticas que están
Herramientas
Los métodos estructurados
destinados a ayudar a los procesos del ciclo de vida del software. Herramientas
métodos orientados a datos orientada
de trazabilidad
permiten repetitivas, acciones bien definidas para ser automatizados, lo que reduce la a objetos métodos
Software Herramientas de diseño de
carga cognitiva en el ingeniero de software que es libre para concentrarse en los modelado Requisitos Requisitos

aspectos creativos del proceso. Las herramientas se diseñan a menudo para apoyar software de construcción Métodos formales
Herramientas de
y lenguajes de especificación
métodos de ingeniería de software en particular, la reducción de cualquier carga notaciones Refinamiento
editores de programas compiladores y

administrativa asociada con la aplicación del método manualmente. Al igual que los generadores de código
Verificación / propiedades que demuestren
Herramientas Intérpretes
métodos de ingeniería de software, que están destinados a hacer la ingeniería de depuradores Software Testing

software más sistemática, y que varían en su alcance desde el apoyo a las tareas Los métodos de prototipado
generadores de prueba prueba
individuales que abarca el ciclo de vida completo. marcos de ejecución Las técnicas de
evaluación de la prueba de evaluación estilos objetivo de
mantenimiento análisis de
prototipos
Funcionamiento de software de gestión

de pruebas

métodos de ingeniería de software imponen estructura en la actividad de La reingeniería

ingeniería de software con el objetivo de hacer la actividad sistemática y en herramientas

Comprensión
definitiva más probable que tenga éxito. Métodos suelen proporcionar una
de análisis estático
notación y el vocabulario, los procedimientos para la realización de tareas Herramientas de gestión de

identificables, y directrices para comprobar tanto el proceso y el producto. Varían defectos, mejora, tema
y el problema de seguimiento de la
ampliamente en su alcance, desde una única fase de ciclo de vida para el ciclo versión Release gerencia y construir

de vida completo. El énfasis en este KA está en métodos de ingeniería de software de gestión de ingeniería

Herramientas de planificación y
software que abarcan múltiples fases del ciclo de vida, ya que los métodos seguimiento de proyectos

específicos de las fases estén cubiertos por otra KAs. Medición de la gestión
de riesgos

Ingeniería de software
Proceso de herramientas de
gestión de proceso de modelado de
Si bien hay manuales detallados sobre herramientas específicas y numerosos trabajos de procesos integrados entornos CASE

investigación sobre las herramientas innovadoras, escritos técnicos genéricos en

entornos de ingeniería de software
herramientas de ingeniería de software son relativamente escasos .. Una de las dificultades de proceso centrada

es la alta tasa de cambio de herramientas de software en general. Los detalles específicos software Herramientas
Revisión y auditoría de calidad de
alteran regularmente, lo que dificulta Configuración del software

para proporcionar concreto, arriba-hasta la fecha Herramientas varias

ejemplos. técnicas de integración

de herramientas temas

Las herramientas de ingeniería de software y métodos KA cubre los procesos herramientas meta

evaluación de herramientas
completos de ciclo de vida, y por lo tanto se relaciona con todos los KA en la Guía.

Figura 1 Desglose de los temas de la Ingeniería de Software

Herramientas y métodos KA

© IEEE - 2004 Versión 10-1


segundo REAKDOWN DE T OPICS PARA S OFTWARE mi NGENIERÍA
T Y OOLS METRO ÉTODOS
1. EngineeringTools Software
Los primeros cinco temas en el Herramientas de ingeniería de software subzona
corresponde a los primeros cinco KAs de la guía (Requisitos de software,
diseño de software, software de construcción,
Software Pruebas, y Software
Mantenimiento). Los siguientes cuatro temas corresponden a los restantes (KAs
de administración de software de configuración, software de gestión de
Ingeniería de Software Ingeniería de Procesos y Calidad del Software). Se
proporciona un tema adicional, Varios, frente a áreas tales como técnicas de
integración de herramientas que son aplicables a todas las clases de
herramientas potencialmente.
1.1. Requisitos de software Herramientas
[Dor97, Dor02]
Herramientas para hacer frente a los requisitos de software se han clasificado en dos
categorías: de modelado y herramientas de trazabilidad.
Requisitos herramientas de modelado. Estas herramientas se utilizan para inducir,
análisis, especificación y validación de los requisitos de software
herramientas requisito de trazabilidad. [Dor02] Estas herramientas son cada
vez más importantes como la complejidad del software crece. Ya que también
son relevantes en otros procesos del ciclo de vida, que se presentan por
separado de las herramientas de modelado de requisitos.
1.2. Herramientas de diseño de software
[Dor02]
Este tema cubre las herramientas para la creación y el control de los diseños de software.
Hay una gran variedad de este tipo de herramientas, con gran parte de esta variedad es
una consecuencia de la diversidad de las notaciones de diseño de software y métodos. A
pesar de esta variedad, no se han encontrado las divisiones de peso para este tema.
1.3. Herramientas de software de construcción
[Dor02, Rei96]
Este tema cubre las herramientas de construcción de software. Estas herramientas se
utilizan para producir y traducir representación programa (por ejemplo, código fuente)
que es suficientemente detallada y explícita para permitir la ejecución de la máquina.
editores de programas. Estas herramientas se utilizan para la creación y
modificación de los programas, y, posiblemente, los documentos asociados
a ellos. Ellos pueden ser texto propósito o documentos generales editores,
o pueden ser especializado para un idioma de destino.
Los compiladores y generadores de código. Tradicionalmente, los
compiladores han sido los traductores no interactivas de código fuente, pero no
ha habido una tendencia a integrar los compiladores y editores de programas
para proporcionar integrada
10-2
entornos de programación. En este tema también cubre pre-procesadores,
enlazador / cargadores y generadores de código. Intérpretes. Estas
herramientas proporcionan la ejecución de software a través de la emulación.
Pueden apoyar las actividades de construcción de software, proporcionando
un ambiente más controlable y observable para la ejecución del programa.
Depuradores. Estas herramientas se consideran una categoría separada, ya
que apoyan el proceso de construcción de software, pero son diferentes de
editores de programas y compiladores.
1.4. Herramientas de prueba de software
[Dor02, Pfl01, Rei96]
generadores de prueba. Estas herramientas ayudan en el desarrollo de casos de prueba.
marcos de ejecución de pruebas. Estas herramientas permiten la ejecución de
casos de prueba en un ambiente controlado donde se observa el comportamiento
del objeto bajo prueba. herramientas de evaluación de pruebas. Estas
herramientas de apoyo el
evaluación de los resultados de la ejecución de la prueba, lo que ayuda a determinar
si el comportamiento observado se ajusta al comportamiento esperado.
herramientas de gestión de pruebas. Estas herramientas proporcionan apoyo a
todos los aspectos del proceso de pruebas de software. herramientas de análisis de
rendimiento. [Rei96] se utilizan Estas herramientas
para medir y analizar el rendimiento del software, que es una
forma especializada de la prueba, donde el objetivo es evaluar el
comportamiento de rendimiento en lugar de comportamiento funcional
(corrección).
1.5. Herramientas de mantenimiento de software
[Dor02, Pfl01]
Este tema abarca herramientas que son especialmente importantes en el
mantenimiento de software en el que se va a modificar el software existente. Se
identifican dos categorías: herramientas de comprensión y herramientas de
reingeniería.
herramientas de comprensión. [Re196] Estas herramientas ayudan a la comprensión
humana de los programas. Los ejemplos incluyen herramientas de visualización tales
como animadores y máquinas de cortar el programa.
Reingeniería de herramientas. En el software de mantenimiento KA,
reingeniería se define como el examen y la alteración del software
objeto de reconstituir en una nueva forma, e incluye la posterior
aplicación de la nueva forma. herramientas de reingeniería apoyan
esa actividad.
Herramientas de ingeniería inversa ayudan al proceso trabajando hacia atrás desde
un producto existente para crear artefactos tales como especificación y diseño
descripciones, que a continuación se pueden transformar para generar un nuevo
producto de una antigua.
1.6. Las herramientas de Software
[Dor02, Rei96, Som05]
© IEEE - 2004 Versión
Herramientas para la gestión de la configuración se han dividido en tres incorporar información sobre los procesos del ciclo de vida del software,
categorías: seguimiento, gestión de versiones, y y guiar y controlar el usuario de acuerdo con el proceso definido.
herramientas de liberación.

herramientas defecto, de mejora, de emisión, y la solución de seguimiento. Estas

1.9. Herramientas de Calidad de Software
herramientas se utilizan en relación con las cuestiones de seguimiento de
problemas asociados con un producto de software en particular. [Dor02]

Herramientas de calidad se dividen en dos categorías: herramientas de inspección y

herramientas de gestión de versiones. Estas herramientas están involucrados en la análisis.
gestión de múltiples versiones de un producto. Liberar y construir herramientas.
Herramientas de revisión y auditoría. Estas herramientas se utilizan para apoyar las
Estas herramientas se utilizan para gestionar las tareas de la versión del software y
revisiones y auditorías.
de construcción. La categoría incluye herramientas de instalación que han sido
herramientas de análisis estático. [Cla96, Pfl01, Rei96] Estas herramientas se utilizan
ampliamente utilizados para la configuración de la instalación de productos de
para analizar artefactos de software, tales como analizadores sintácticos y semánticos,
software. Adicional
así como de datos, flujo de control, y analizadores de dependencia. Tales herramientas

están destinadas para el control de artefactos de software para la conformidad o para la

información se da en el Software
verificación de las propiedades deseadas.
Gestión de la Configuración KA, tema 2.3 La planificación de SMC.

1.10. Problemas de la herramienta Varios

1.7. Herramientas de Gestión de Ingeniería de Software

[Dor02] [Dor02]

Este tema abarca cuestiones aplicables a todas las clases de herramientas. Tres categorías han
herramientas de gestión de la ingeniería de software se subdividen en tres
sido identificados: técnicas de integración de herramientas, meta-herramientas, y la evaluación
categorías: Planificación de proyectos y seguimiento, gestión de riesgos y
de herramientas.
medición.

planificación de proyectos y herramientas de seguimiento. Estas herramientas se

utilizan en proyectos de software de medición de esfuerzo y estimación de costos, así
como la programación de proyectos. herramientas de gestión de riesgos. Estas
herramientas se utilizan en la identificación, estimación y seguimiento de los riesgos.
Herramientas de medición. Las herramientas de medición ayudan en la realización de
las actividades relacionadas con el programa de medición de software.
técnicas de integración de herramientas. [Pfl01, Rei96, Som01] (Bro94) la
integración de la herramienta es importante para la fabricación de herramientas
individuales cooperan. Esta categoría potencialmente se solapa con la
categoría entornos integrada de casos donde se aplican técnicas de
integración, sin embargo se consideró que es lo suficientemente distinta como
para merecer una categoría propia. Las clases típicas de la integración de
herramientas son la plataforma, la presentación, procesos, datos y control.

herramientas Meta. Los meta-herramientas generan otras herramientas;

1.8. Herramientas de Ingeniería de Software Process
compiladores compiler- son el ejemplo clásico. Evaluación de herramientas. [Pfl01]
[Dor02, Som05] (IEEE1209-92, IEEE1348-95, Mos92, Val97) Debido a la continua evolución de las

herramientas de ingeniería de software, evaluación de herramientas es un tema

herramientas de proceso de ingeniería de software se dividen en: modelización
herramientas, gestión herramientas,y el software esencial.

entornos de desarrollo.

herramientas de modelado de procesos. [Pfl01] Estas herramientas se utilizan 2. Software de Ingeniería de Métodos
para modelar e investigar los procesos de ingeniería de software.
los Métodos de ingeniería de software sub-área se divide en tres temas: métodos
heurísticos se trata de enfoques informales, métodos formales se trata de enfoques
Gestión de proceso herramientas. Estas herramientas proporcionan
de base matemática, y métodos de prototipado se trata de la ingeniería de software
apoyo a la gestión de la ingeniería de software. entornos
enfoques basados ​en diversas formas de creación de prototipos. Los tres primeros
CASE integrado. [Rei96, Som05] temas que no son disjuntos; sino que representan las preocupaciones distintas.
(ECMA55-93, ECMA69-94, IEEE1209-92, Por ejemplo, un método orientado a objetos puede incorporar técnicas formales y
IEEE1348-95, Mul96) asistido por ordenador integrado se basan en la creación de prototipos para la verificación y validación. Al igual que
herramientas o entornos que abarcan múltiples fases del ciclo de vida del las herramientas de ingeniería de software, metodologías evolucionan
software de ingeniería de software de ingeniería pertenecen en este continuamente. En consecuencia, la descripción KA evita en lo posible a
sub-tema. Tales herramientas de realizar múltiples funciones y por lo tanto metodologías particulares de denominación.

potencialmente interactúan con el proceso del ciclo de vida del software que
se ejecuta. entornos de ingeniería de software de proceso centrado. [Rei96]
(Gar96)
Estos ambientes explícitamente

© IEEE - 2004 Versión 10-3

2.1. Los métodos heurísticos
[Was96]
Este tema contiene cuatro categorías: estructurado, orientado Data-, orientado a
objetos, y de dominio específico. La categoría de dominio específico incluye métodos
clasificado como modelo orientado, orientado-propiedad, u orientado
comportamiento.
Refinamiento. [Pre04] Este tema se ocupa de cómo los refina método (o
transformadas) la especificación en una forma que está más cerca de la

especializados para los sistemas que implican en tiempo real, la seguridad o el forma final deseada de un programa ejecutable. Verificación /
desarrollo de los aspectos de seguridad. propiedades probando.
[Cla96, Pfl01,
Som05] Este tema trata sobre las propiedades de verificación que son específicos
Los métodos estructurados. [Dor02, Pfl01, Pre04, Som05] El sistema está
para el enfoque formal, incluyendo tanto la demostración de teoremas y verificación
construido a partir de un punto de vista funcional, a partir de una vista de alto
de modelos.
nivel y refinando progresivamente esto en un diseño más detallado.

2.3. métodos de prototipado

métodos orientados a datos. [Dor02, Pre04] Aquí, los puntos de partida
[Pre04, Som05, Was96]
son las estructuras de datos que un programa manipula, en lugar de la
Esta subsección abarca métodos que implican la creación de prototipos de
función que realiza. métodos orientados a objetos.
software, y se subdivide en estilos de creación de prototipos, objetivos y técnicas
[Dor02, Pfl01, Pre04,
de evaluación.
Som05] El sistema es visto como una colección de objetos en lugar
de funciones. Prototipado estilos. [Dor02, Pfl01, Pre04] (Pom96) El tema estilos de
creación de prototipos se identifican los distintos enfoques: usar y tirar,
2.2. Los métodos formales evolutiva, y la especificación ejecutable.

[Dor02, Pre04, Som05]

Prototipado objetivo. [Dor97] (Pom96) Ejemplos de los objetivos de un
En esta subsección se ocupa de métodos de ingeniería de software de base
método de creación de prototipos pueden ser requisitos, el diseño
matemática, y se subdivide según los diversos aspectos de los métodos
arquitectónico, o la interfaz de usuario. Prototipos técnicas de evaluación.
formales.
Este tema abarca las formas en que se utilizan los resultados de un ejercicio
lenguajes de especificación y notaciones. [Cla96, Pfl01, PRE01] Este de prototipo.
tema se refiere a la notación de especificación o lenguaje utilizado.
lenguajes de especificación pueden ser

10-4 © IEEE - 2004 Versión

 ejecución de

C4s1,

[Cla96]
10-5

marcos de

{}
defectos,
v2c8s4 v2c8s4 v2c8s4 v2c8s4 v2c8s4 v1c4s2 [Dor02]

{Dor97}
Prueba c112s3

C8s7, c9s7
c11s5 c11s5 [Pfl01]

{PFL98}

de prueba

[Pre04]

c112s3 herramientasc112s5 generadores editores [Rei96]

[Som05]
c29

[Was96]
 de

de ingeniería software c3 Proceso centrada

v2c8s4 de
10-6 [Cla96]
herramientas
* * *

v1c6s2,v1c5s1,
v1c6s3v1c5s1,
v1c6s3 v1c6s3

Las v1c4s4 v1c6s5 técnicas v2c8s4 herramientas Proyecto [Dor02]

{Dor97}

c4s4, c6, c8s5

c4s6, c5s7, c8s3 c2s3,
C9s10 [Pfl01]
Refinamiento c4s5 c1s8 C8s7

{PFL98}

© IEEE - 2004 Versión

[Pre04]
C7-C9 métodos
C7-C9
c28

c112s3, c112s4

c112s4 c112s5 c112s5 [Rei96]

[Som05]

c8 c12
lenguajes métodos entornos

[Was96]

* * *
 Práctica, Segunda ed: Prentice-Hall, Inc., 2001. [] Pre04 RS Pressman, Ingeniería
R ECOMMENDED R EFERENCIAS PARA S OFTWARE
de Software: Enfoque para profesionales, ed Sexto: McGraw-Hill, 2004.
mi HERRAMIENTAS Y ngineering METRO ÉTODOS
[Rei96] SP Reiss, Herramientas de software y entornos en el Manual de
[Cla96] EM Clarke, JM Wing y otros, "Métodos formales: Estado del Arte y Ingeniería Informática: CRC Press, 1996. [Som05] I. Sommerville, Ingeniería
orientaciones futuras" Las encuestas ACM Computer, vol. 28, ISS. 4,
de software, Séptima edición: Addison-Wesley, 2005.
626-643, 1996

[Dor97] M. Dorfman y RH Thayer, Eds., "Ingeniería de Software". IEEE

Computer Society Press, 1997. [Dor02] M. Dorfman y RH Thayer, Eds.,
"Ingeniería de Software, Vol. 1 y vol.2". IEEE Computer Society Press,
[Was96] AI Wasserman, "Hacia una disciplina de la ingeniería de
2002.
software" IEEE Software, vol. 13, ISS. 6, 23-
31, noviembre de 1996
[Pfl01] Pfleeger SL, Ingeniería de Software: Teoría y

© IEEE - 2004 Versión 10-7


UN PÉNDICE A. L LISTA DE F ás R EADINGS
(Ber93) EV Berard, Ensayos sobre Ingeniería de Software Orientada a Objetos: Prentice-Hall,
1993.
(Bis92) W. Bischofberger y G. Pomberger, Prototyping- desarrollo de
software orientado: Conceptos y Herramientas:
Springer-Verlag, 1992. (Bro94) AW Brown y col, Principios de integración de
la herramienta CASE: Oxford University Press, 1994.
(Car95) DJ Carney y AW Brown, "sobre las condiciones necesarias para
la composición de Integrated Engineering Software Entornos", presentado
en Avances en Informática, 1995
(Col94) D. Coleman, P. Arnold, S. Godoff, C. Dollin, H. Gilchrist, F. Hayes
y P. Jeremaes, Desarrollo Orientado a Objetos: el método de fusión: Prentice
Hall, 1994. (Cra95) D. Craigen, S. Gerhart y T. Ralston, "Formal Métodos
Reality Check:
Uso industrial" IEEE
Las transacciones en Ingeniería de Software, vol. 21, ISS. 2, 90-
98, febrero de 1995
(Fin00) A. Finkelstein, Ed., "El futuro de la Ingeniería de Software." ACM,
2000.
(Gar96) PK Garg y M. Jazayeri, Entornos de ingeniería de software
centrada en el proceso: IEEE Computer Society, 1996.
(Har00) W. Harrison, H.Ossher y P. Tarr, "Herramientas de ingeniería de
software y entornos: Una hoja de ruta", 2000 (Jar98) S. y R. Jarzabek
Huang, "El Caso de herramientas CASE User-Centered" Communications
of the ACM, vol.
41, ISS. 8, 93-99 de agosto de 1998
(Kit95) B. Kitchenham, L. Pickard y SL Pfleeger, "Estudios de casos para
Método y herramienta de evaluación" IEEE Software, vol. 12, ISS. 4, 52-62,
Julio, 1995
(Lam00) A. v Lamsweerde, "Especificación Formal: Una hoja de ruta,". En El
futuro de la Ingeniería de Software, A. Finkelstein, Ed .: ACM, 2000,
149-159. (Mey97)
B. Meyer, Orientado a objetos Software
Construcción, Segunda ed: Prentice-Hall, 1997.
10-8
(Moo98) JW Moore, Estándares de Ingeniería de Software, Plan de trabajo de
un usuario. Los Alamitos, CA: IEEE Computer Society, 1998.
(Mos92) V. Mosley, "Cómo evaluar las herramientas de manera eficiente y
cuantitativamente" IEEE Software, vol. 9, ISS. 3, 29-32, mayo, 1992
(Mül96) HA Muller, RJ Norman y J. Slonim, Eds., "Computer Aided
Software Engineering". Un número especial de software automatizado
Ingeniería, 3 (3/4), Kluwer, 1996. (Mül00) H. Müller y otros, "Ingeniería
inversa: Una hoja de ruta", en El futuro de la Ingeniería de Software, A.
Finkelstein, Ed .: ACM, 2000, 49-60. (Pom96) G. Pomberger y G.
Blaschek, Orientación a objetos y la creación de prototipos en Ingeniería
de Software:
Prentice Hall, 1996. (Pos96) RM Poston, La automatización de pruebas de Software
basada en la especificación: IEEE, 1996.
(Ric92) C. Rich y RC Waters, "herramientas de conocimiento intensivo de
ingeniería de software" IEEE Transactions on Conocimiento e información
técnica, vol. 4, ISS. 5, 424-430, octubre de 1992
(Son92) X. canción y LJ Osterweil, "hacia el objetivo, sistemático
comparaciones Diseño-Método," IEEE Software,
vol. 9, ISS. 3, 43-53, mayo, 1992 (Tuc96) AB Tucker, La Ciencia de la
Computación e Ingeniería de la reseña: CRC Press, 1996. (Val97) LA
Valaer y RCB II, "Elección de una herramienta de desarrollo de interfaz de
usuario" IEEE Software, vol. 14, ISS.
4, 29-39, 1997 (Vin90) WG Vincenti, Lo que los ingenieros saber y como
saben son - Estudios analíticos forman Aeronáutica Historia. Baltimore y
Londres: John Hopkins University Press, 1990.
(Wie98) R. Wieringa, "Una Revisión de los métodos de especificación de
software estructurado y orientado a objetos y técnicas"
ACM Computing Surveys, vol. 30, ISS. 4, 459-527, 1998
© IEEE - 2004 Versión
 Prácticas para la evaluación y selección de herramientas CASE, (ISO / IEC
UN PÉNDICE B. L LISTA DE S NORMAS
14102, 1995), 1992. (IEEE1348-95) IEEE Std 1348-1995, Práctica
(ECMA55-93) ECMA, TR / 55 Modelo de Referencia para Recomendada para la adopción de herramientas CASE,
Marcos de Ingeniería de Software de entornos, Tercera edición, 1993. (ISO / IEC
14471), 1995.
(ECMA69-94) ECMA, TR / 69 Modelo de Referencia para el Proyecto de Apoyo a los (IEEE12207.0-96) IEEE / EIA 12207.0-
entornos, 1994. 1996 // ISO / IEC12207: 1995, Implementación de la industria Int. Std.

(IEEE1175.1-02) IEEE Std 1.175,1-2002, Guía de IEEE para CASO ISO / IEC 12207: 95, Norma para Tecnología de la
Herramienta Interconexiones-Clasificación y Información-Software Procesos del ciclo de vida, vol. IEEE,
Descripción: IEEE 2002. 1996.

(IEEE1209-92) IEEE Std 1209-1992, Recomendado

© IEEE - 2004 Versión 10-9

10-10 © IEEE - 2004 Versión
 do CAPÍTULO 11 S OFTWARE
Q CALIDAD
UN CRONYMS
CMMi Capability Maturity Model Integrated
COTS Comercial Software Off-the-shelf
PDCA Planificar, Hacer, Verificar, Actuar
SQA Software de Control de Calidad
SQM Gestión de la calidad del software
TQM Total Quality Management
V&V Verificación y validación
yo INTRODUCCIÓN
¿Cuál es la calidad del software, y por qué es tan importante que sea omnipresente
en la Guía SWEBOK? Con los años, los autores y organizaciones han definido el
término “calidad” de manera diferente. Para Phil Crosby (Cro79), era “la
conformidad con los requisitos del usuario.” Watts Humphrey (Hum89) se refiere a
él como “el logro de excelentes niveles de aptitud para el uso”, mientras que IBM
acuñó la frase "la‘calidad impulsada por el mercado’, que es basan en lograr la
satisfacción total del cliente. Los criterios Baldrige para la calidad de la organización
(NIST03) utilizan una frase similar, “calidad impulsada por el cliente”, e incluyen la
satisfacción del cliente como una consideración importante. Más recientemente, la
calidad se ha definido en (ISO9001-00) como “el grado en que un conjunto de
inherente características Cumple requisitos. ”En este capítulo se ocupa de las
consideraciones de calidad de software que trascienden los procesos del ciclo de
vida. La calidad del software es una preocupación omnipresente en la ingeniería de
software, por lo que también se considera en muchos de la KAS. En resumen, la
Guía SWEBOK describe varias formas de lograr la calidad del software. En
particular, este KA cubrirá técnicas estáticas, aquellos que no requieren la ejecución
de los programas que están siendo evaluados, mientras que el técnicas dinámicas están
cubiertos en el Testing de Software KA.
segundo REAKDOWN DE S OFTWARE Q CALIDAD T OPICS
1. Fundamentos de Calidad de Software
Un acuerdo sobre los requisitos de calidad, así como una comunicación clara
con el ingeniero de software en lo que constituye la calidad, requieren que los
muchos aspectos de la calidad se definirán y discutirán formalmente.
Un ingeniero de software debe comprender los significados subyacentes de
los conceptos y características de calidad y su valor para el software en fase
de desarrollo o de mantenimiento.
© IEEE - 2004 Versión
El concepto importante es que los requisitos de software definen las
características requeridas de calidad del software, e influyen en los métodos
de medición y criterios de aceptación para la evaluación de estas
características.
1.1.Software Ingeniería de la Cultura y Ética
Se espera que los ingenieros de software para compartir un compromiso con la
calidad del software como parte de su cultura. Una cultura de ingeniería de
software sana se describe en [Wie96]. La ética puede jugar un papel significativo
en la calidad del software, la cultura, y las actitudes de los ingenieros de software.
El IEEE Computer Society y la ACM [IEEE99] han desarrollado un código de ética
y práctica profesional basada en ocho principios, para ayudar a los ingenieros de
software refuerzan actitudes relacionadas con la calidad y la independencia de su
trabajo.
1.2.Value y Costos de la Calidad
[Boe78; NIST03; Pre04; Wei93] La noción de “calidad” no es tan simple
como puede parecer. Para cualquier producto de ingeniería, hay muchas
cualidades deseadas relevantes a una perspectiva particular del producto, a ser
discutido y determinado en el momento de que los requisitos del producto se
establecen abajo. Las características de calidad pueden ser necesarios o no, o
pueden ser obligados a un mayor o menor grado, y las compensaciones se
pueden hacer entre ellos. [Pfl01] El costo de la calidad se puede diferenciar en
costo prevención, el costo de tasación, costos de fallas internas, y el costo fallo
externo. [Hou99]
Una de las motivaciones detrás de un proyecto de software es el deseo de crear
un software que tiene valor, y este valor puede o no puede ser cuantificado
como un costo. El cliente tendrá algún coste máximo en mente, a cambio de lo
que se espera que se cumplirá el objetivo básico del software. El cliente también
puede tener alguna expectativa en cuanto a la calidad del software. A veces los
clientes no pueden haber pensado a través de los problemas de calidad o sus
costos relacionados. Es la característica meramente decorativo, o es esencial
para el software? Si la respuesta se encuentra en algún punto intermedio, como
es casi siempre el caso, se trata de una cuestión de hacer al cliente una parte
del proceso de decisión y plenamente consciente de los costos y los beneficios.
Lo ideal es que la mayoría de estas decisiones se tomarán en el proceso de
requisitos de software (ver los requisitos de software KA), pero estos problemas
pueden surgir durante todo el ciclo de vida del software. No hay una regla
definida en cuanto a cómo se deben tomar estas decisiones, pero el ingeniero
de software debe ser capaz de presentar alternativas de calidad y sus costes.
Una discusión sobre el costo y el valor de los requisitos de calidad se pueden
encontrar en [Jon96: c5; Wei96: c11].
11-1
 Calidad del software

Procesos de software
Fundamentos de la calidad Consideraciones
de gestión de
del software prácticas
calidad

Software de Ingeniería de la Requisitos de calidad de las

Cultura y Ética aplicaciones

de Control de Calidad

Validación de Software

Valor y costos de la Verificación y Caracterización de

Calidad defectos

Modelos y Revisiones y
características de auditorías
calidad de Software
Medición de la Calidad
de calidad de software
Técnicas para el control
Mejora de calidad

Figura 1 Desglose de los temas de la calidad del software KA

Modelos y criterios que evalúan las capacidades de las organizaciones de

software son principalmente consideraciones de organización y de gestión de
1.3.Models y características de calidad
proyectos, y, como tales, están cubiertos en el Proceso de Gestión de
[Dac01; Kia95; Lap91; Lew92; Mus99; NIST; PRE01; Rak97; Ingeniería de Software e Ingeniería de Software de Kas.
Sei02; Wal96]

Terminología para características de calidad de software difiere de una
taxonomía (o modelo de la calidad del software) a otro, cada modelo tal vez
tener un número diferente de niveles jerárquicos y un número total diferente de
características. Varios autores han producido modelos de características de
calidad de software o atributos que pueden ser útiles para la discusión, la
planificación, y la calificación de la calidad de los productos de software.
[Boe78; McC77] ISO / IEC ha definido tres modelos relacionados de la calidad
del producto de software (calidad interna, externa de la calidad, y la calidad en
uso) (ISO9126-01) y un conjunto de partes relacionadas (ISO14598-98).
1.3.1. Software de proceso de ingeniería de software de calidad de gestión
de calidad y la calidad del proceso de ingeniería de software tienen una influencia
directa en la calidad del producto de software.
Por supuesto, no es posible distinguir por completo la calidad del
proceso de la calidad del producto. La calidad del proceso, se discutió
en la Ingeniería de Procesos de Software KA de esta guía,
influye en la calidad
características de los productos de software, que a su vez afectan a la calidad
en uso según lo percibido por el cliente. Dos estándares de calidad son
importantes TickIT [Llo03], y uno que tiene un impacto en la calidad del
software, la norma ISO9001 [ISO9001-00], junto con sus directrices para la
aplicación de software [ISO90003-04]. Otro estándar de la industria de la
calidad del software CMMi es [SEI02], también se discute en la Ingeniería de
Procesos de Software KA. CMMi tiene la intención de proporcionar una guía
para la mejora de procesos. áreas de procesos específicos relacionados con la
gestión de calidad son: a) la garantía de proceso y calidad del producto, b)
verificación de proceso, y c) proceso

11-2 © IEEE - 2004 Versión

validación. CMMi clasifica revisiones y auditorías como métodos de
verificación, y no como procesos específicos como (IEEE12207.0-96).
Hubo inicialmente cierto debate sobre si ISO9001 o CMMi deben ser
utilizados por los ingenieros de software para garantizar la calidad. Este
debate es ampliamente publicado, y, como resultado, la posición se haya
tomado los dos son
complementario, y que tener la certificación ISO9001 puede ayudar mucho en la
consecución de los más altos niveles de madurez de la CMMi. [Dac01]
1.3.2. la calidad del producto de software
Las necesidades de ingeniería de software, en primer lugar, para determinar el
verdadero propósito del software. En este sentido, es de vital importancia tener
en cuenta que los clientes
requisitos son lo primero, y que incluyen los requisitos de calidad, no sólo
los requisitos funcionales. Por lo tanto, el ingeniero de software tiene la
responsabilidad de obtener los requisitos de calidad que pueden no ser
explícita desde el principio, y discutir su importancia, así como el nivel de
dificultad en la consecución de ellos. Todos los procesos asociados a la
calidad del software (por ejemplo, la construcción, comprobación y mejora
de la calidad) serán diseñados con estos requisitos en mente, y que tienen
costos adicionales. Estándar (ISO9126-01) define, para dos de sus tres
modelos de calidad, las características de calidad relacionados y
sub-características, y las medidas que son útiles para la evaluación de la
calidad del producto de software. (Sur03)
El significado del término “producto” se amplía para incluir cualquier artefacto
que es la salida de cualquier proceso que se utiliza para construir el producto de
software final. Ejemplos de un producto incluyen, pero no se limitan a, toda una
especificación de requisitos del sistema, una especificación de requisitos de
software para un componente de software de un sistema, un módulo de diseño,
código, documentación de prueba, o informes producidos como resultado de las
tareas de análisis de calidad. Si bien se describen la mayoría de los tratamientos
de calidad en cuanto a la ejecución de software y sistema final, buenas prácticas
de ingeniería requiere que se evalúen los productos intermedios
correspondientes a la calidad durante todo el proceso de ingeniería de software.
1.4.Quality mejora
[NIST03; Pre04; Wei96]
La calidad de los productos de software se puede mejorar a través de un
proceso iterativo de mejora continua que requiere control de la gestión,
coordinación, y la retroalimentación de muchos procesos concurrentes:
(1) la vida del software
procesos del ciclo, (2) el proceso de detección de error / defecto, la eliminación,
y la prevención, y (3) el proceso de mejora de la calidad. (Kin92)
La teoría y los conceptos detrás de la mejora de la calidad, tales como edificio
en la calidad a través de la prevención y la detección temprana de errores, la
mejora continua y la orientación al cliente, son pertinentes a la ingeniería de
software. Estos conceptos se basan en el trabajo de los expertos en la calidad
© IEEE - 2004 Versión
quienes han afirmado que la calidad de un producto está directamente
relacionada con la calidad del proceso utilizado para crearlo. (Cro79, Dem86,
Jur89)
Enfoques como el proceso de gestión de calidad total (TQM) de Planificar,
Hacer, Verificar, y Ley ( PDCA) son herramientas con las que se puedan
cumplir los objetivos de calidad. patrocinio de gestión de procesos y
productos apoya las evaluaciones y las conclusiones resultantes. A
continuación, un programa de mejora se desarrolla la identificación de
acciones detalladas y proyectos de mejora que debe abordarse en un
plazo de tiempo posible. apoyo a la gestión implica que cada proyecto de
mejora tiene suficientes recursos para lograr el objetivo definido para ello.
patrocinio de gestión debe ser solicitado con frecuencia mediante la
implementación de actividades de comunicación proactivas. La
participación de grupos de trabajo, así como apoyo para el medio y los
recursos asignados a nivel de proyecto, se discuten en la Ingeniería de
Procesos de Software KA.
2. Procesos de Gestión de Calidad de Software
gestión de la calidad del software (SQM) se aplica a todos los puntos de vista
de los procesos de software, productos y recursos. Define procesos,
propietarios de los procesos, y los requisitos de dichos procesos, las
mediciones del proceso y sus resultados, y canales de retroalimentación.
procesos de gestión de la calidad (Art93) Software consisten en muchas
actividades. Algunos pueden encontrar defectos directamente, mientras que
otros indican que el examen adicional puede ser valiosa. Este último también
se hace referencia a las actividades que directa de defectos de investigación.
Muchas de las actividades a menudo sirven como ambos. La planificación de
la calidad del software consiste en: (1) definir el producto requerido en
términos de sus características de calidad (que se describe con más detalle
en, por ejemplo, la Ingeniería de Software de Gestión KA) (2) la planificación
de los procesos para alcanzar el producto requerido (descrito en, por ejemplo,
Estos aspectos son diferentes de, por ejemplo, la planificación de los propios
procesos de SQM, que evalúan las características de calidad previstas en
comparación con la aplicación real de estos planes. ¿Qué tan bien productos de
software, o hacer, satisfacer las necesidades del cliente y de los interesados,
proporcionar valor a los clientes y otras partes interesadas, y proporcionar la
calidad del software necesario para cumplir con los requisitos de software. SQM
se puede utilizar para evaluar los productos intermedios, así como el producto
final.
Algunos de los procesos SQM específicas se definen en la norma
(IEEE12207.0-96):
Proceso de auditoría proceso de
aseguramiento de la calidad del proceso de
Verificación proceso de validación de
proceso de Revisión
11-3
Estos procesos fomentan la calidad y también encuentran posibles problemas.
Pero difieren un tanto en su énfasis. SQM procesos ayudan a garantizar una
mejor calidad del software en un proyecto determinado. También proporcionan,
como un subproducto, la información general de gestión, incluyendo una
indicación de la calidad de todo el proceso de ingeniería de software. El
Proceso de Ingeniería de Software Ingeniería de Software y Gestión KAs
discuten programas de calidad para la organización el desarrollo del software.
SQM puede proporcionar información relevante para estas áreas.
SQM procesos consisten en tareas y técnicas para indicar cómo los planes de
software (Por ejemplo, la gestión,
el desarrollo, la gestión de la configuración) están llevando a cabo y qué tan
bien los productos intermedios y finales están cumpliendo con sus requisitos
especificados. Los resultados de estas tareas se montan en los informes de
gestión antes de que se tomen medidas correctivas. La gestión de un
proceso de SQM tiene la tarea de garantizar que los resultados de estos
informes son exactos.
Como se describe en este KA, procesos SQM están estrechamente
relacionados; que pueden superponerse y son a veces incluso combinados.
Ellos parecen en gran medida de carácter reactivo porque se ocupan de los
procesos como se practica y los productos tal como se produce; pero tienen un
papel importante en la etapa de planificación en ser proactivos en términos de
los procesos y procedimientos necesarios para alcanzar los niveles de calidad y
grado de calidad que exigen las partes interesadas en el software.
La gestión del riesgo también puede jugar un papel importante en la entrega de
software de calidad. La incorporación de las técnicas de análisis y gestión de
riesgos disciplinados en los procesos del ciclo de vida del software puede aumentar
el potencial de producir un producto de calidad (Cha89).
Consulte el software
Ingeniería de Gestión KA para el material relacionado en la gestión de riesgos.
2.1.Software Aseguramiento de la Calidad
[Ack02; Ebe94; Fre98; Gra92; Hor03; Pfl01; Pre04; Rak97; Sch99;
Som05; Voa99; Wal89; Wal96] SQA procesos garantizan que los
productos de software y procesos en el ciclo de vida del proyecto se
ajustan a sus requerimientos especificados por la planificación, la
promulgación, y la realización de un conjunto de actividades para
proporcionar la confianza adecuada de que la calidad se está
construyendo en el software. Esto significa asegurar que el problema es
clara y adecuadamente fijados y que los requisitos de la solución son
adecuadamente definido y expresado. SQA busca mantener la calidad
durante todo el desarrollo y mantenimiento del producto por la ejecución
de una variedad de actividades en cada etapa, que puede dar lugar a la
identificación temprana de problemas, una característica casi inevitable
de cualquier actividad compleja.
11-4
El plan SQA define los medios que se utilizarán para asegurar que el software desarrollado para
un producto específico satisface las necesidades del usuario y es de la más alta calidad posible
dentro de las limitaciones del proyecto. Con el fin de hacerlo, debe primero asegurarse de que el
objetivo de calidad está claramente definida y comprendida. Debe tenerse en cuenta de gestión,
desarrollo y mantenimiento de los planes para el software. Consulte la norma (IEEE730-98) para
más detalles. Las actividades y tareas específicas de calidad se establecen, con sus costos y
necesidades de recursos, sus objetivos generales de gestión, y su horario en relación con esos
objetivos en los planes de gestión de la ingeniería de software, desarrollo o mantenimiento. El
plan SQA debe ser coherente con el plan de gestión de configuración de software (consulte la
KA Software Configuration Management). El plan SQA identifica documentos, normas, prácticas
y convenciones que rigen el proyecto y cómo van a ser revisados ​y monitoreados para asegurar
la adecuación y cumplimiento. El plan SQA también identifica medidas, técnicas estadísticas,
procedimientos para informar de problemas y acciones correctivas, los recursos como
herramientas, técnicas y metodologías, la seguridad física de los medios de comunicación,
capacitación y generación de informes y documentación SQA. Por otra parte, el plan de SQA se
ocupa de las actividades de aseguramiento de la calidad del software de cualquier otro tipo de
actividad se describe en los planes de software, tales como la adquisición de software de
proveedor para el proyecto o software off-the-shelf comercial (COTS), instalación y servicio
después del parto del software. También puede contener los criterios de aceptación, así como
las actividades de información y de gestión que son críticos para la calidad del software. normas,
prácticas y convenciones que rigen el proyecto y cómo van a ser revisados ​y monitoreados para
asegurar la adecuación y el cumplimiento. El plan SQA también identifica medidas, técnicas
estadísticas, procedimientos para informar de problemas y acciones correctivas, los recursos
como herramientas, técnicas y metodologías, la seguridad física de los medios de comunicación,
capacitación y generación de informes y documentación SQA. Por otra parte, el plan de SQA se
ocupa de las actividades de aseguramiento de la calidad del software de cualquier otro tipo de
actividad se describe en los planes de software, tales como la adquisición de software de
proveedor para el proyecto o software off-the-shelf comercial (COTS), instalación y servicio
después del parto del software. También puede contener los criterios de aceptación, así como
las actividades de información y de gestión que son críticos para la calidad del software. normas,
prácticas y convenciones que rigen el proyecto y cómo van a ser revisados ​y monitoreados para asegurar la adecuac
2.2.Verification y Validación
[Fre98; Hor03; Pfl01; Pre04; Som05; Wal89; Wal96] Para fines de brevedad,
verificación y validación (V & V) son tratados como un solo tema en esta guía,
en vez de como dos temas separados como en la norma (IEEE12207.0-96).
“Software V & V es un enfoque disciplinado para evaluar los productos de
software en todo el ciclo de vida del producto. Un esfuerzo de V & V se
esfuerza por asegurar que la calidad está integrado en el software y que
satisface los requisitos de software de usuario”(IEEE1059-93). V & V se ocupa
de la calidad del producto software directamente, y utiliza técnicas de prueba
que puede localizar defectos para que puedan ser tratados. También evalúa
los productos intermedios, sin embargo, y, en esta capacidad, los pasos
intermedios de los procesos del ciclo de vida del software. La V& proceso V
determina si o no productos de una actividad de mantenimiento de desarrollo
determinado o se ajustan a la exigencia de que la actividad, y si es o no el
producto software final cumple su propósito previsto y cumple con los
requisitos del usuario. La verificación es un intento de asegurar que el producto
se ha construido correctamente, en el sentido de que los productos de salida
de una actividad cumplen con las especificaciones impuestas sobre ellos en
las actividades anteriores. La validación es un intento de asegurar que el
producto adecuado está construido, es decir, la
© IEEE - 2004 Versión
producto cumple con su finalidad específica. Tanto el proceso de verificación y
validación del proceso comienzan temprano en la fase de desarrollo o
mantenimiento. Proporcionan un examen de las características clave del
producto tanto en relación con el producto de
predecesor inmediato y para el
especificaciones que deben cumplir.
El propósito de la planificación de V & V es asegurar que cada recurso, el papel
y la responsabilidad está claramente asignadas. Los documentos resultantes del
plan de V & V y describe los diversos recursos y sus funciones y actividades, así
como las técnicas y herramientas que se utilizarán. La comprensión de los
diferentes efectos de cada actividad de V & V le ayudará en la planificación
cuidadosa de las técnicas y los recursos necesarios para cumplir
sus propósitos. normas (IEEE1012-98: s7,
IEEE1059-93: Apéndice A) especifica lo que normalmente entra en un plan de V &
V.
El plan también se ocupa de la gestión, la comunicación, las políticas y
procedimientos de las actividades de V & V y su interacción, así como la
presentación de informes de defectos y requisitos de documentación.
2.3.Reviews y Auditorías
Por motivos de brevedad, revisiones y auditorías son tratados como un solo
tema en esta guía, en lugar de como dos temas separados como en
(IEEE12207.0-96). El proceso de revisión y auditoría se define ampliamente
en (IEEE12207.0-96) y en más detalle en (IEEE1028-97). Cinco tipos de
exámenes o auditorías se presentan en la norma IEEE1028-97:
revisiones por la dirección
Técnica examina Inspecciones
repaso informal auditorías
2.3.1. Los comentarios de gestión
“El propósito de una revisión por la dirección es monitorear el progreso,
determinar el estado de los planes y horarios, requisitos y confirmar su
asignación del sistema o evaluar la eficacia de la gestión de los enfoques
utilizados para lograr la aptitud para el uso” [IEEE1028-97]. Apoyan
decisiones sobre los cambios y las acciones correctivas que se requieren
durante un proyecto de software. revisiones por la dirección determinan la
idoneidad de los planes, los programas y los requisitos,
y el monitor su Progreso
inconsistencias. Estas revisiones se pueden realizar en productos tales como
los informes de auditoría, informes de progreso, V & V informes y planes de
muchos tipos, incluyendo el riesgo
gestión, gestión de proyectos, gestión de configuración de software,
software de seguridad, y evaluación de riesgos, entre otros. Consulte la
Gestión de Ingeniería de Software y para el Software Configuration
Management KAs para el material relacionado.
© IEEE - 2004 Versión
2.3.2. Revisiones técnicas [Fre98; Hor03; Lew92; Pfl01; Pre04;
Som05; Voa99; Wal89; Wal96] “El propósito de una revisión técnica
es evaluar un producto de software para determinar su idoneidad para
el uso previsto. El objetivo es identificar las discrepancias de las
especificaciones y estándares aprobados. Los resultados deben
proporcionar a la dirección pruebas que confirmen (o no) que el
producto cumple con las especificaciones y se adhiere a las normas, y
que se controlan los cambios. ”(IEEE1028-97).
funciones específicas deberán estar establecidos en una revisión técnica: un tomador
de decisiones, un líder de opinión, una grabadora, y el personal técnico para apoyar las
actividades de revisión. Una revisión técnica requiere que las entradas obligatorias estar
en su lugar a fin de proceder:
La declaración de los objetivos de gestión de proyectos específicos Un
producto de software específico de su plan La lista de temas relacionados con
este producto El procedimiento de revisión técnica El equipo sigue el
procedimiento de revisión. Una persona técnicamente capacitada presenta
una descripción general del producto, y el examen se lleva a cabo durante
una o más reuniones. La revisión técnica se completa una vez que todas las
actividades enumeradas en el examen se han completado.
2.3.3. inspecciones
[Ack02; Fre98; Gil93; Rad02; Rak97] “El objetivo de la
inspección es detectar e identificar anomalías de productos de software”
(IEEE1028-97). Dos
diferenciadores importantes de las inspecciones a diferencia de las recomendaciones son:
1. Una persona que ocupe un puesto de gestión a través de cualquier
miembro del equipo de inspección no debe participar en la
inspección.
2. Una inspección es ser guiado por un facilitador imparcial que
es entrenado en inspección
o técnicas.
Las inspecciones de software siempre implican el autor de un producto intermedio
o final, mientras que otros comentarios que no. Las inspecciones también
incluyen un líder de inspección, una grabadora, un lector, y unos pocos (2 a 5)
inspectores. Los miembros de un equipo de inspección pueden poseer diferentes
conocimientos, tales como experiencia en el campo, experiencia en métodos de
diseño, o la experiencia del lenguaje. Las inspecciones se realizan normalmente
en una sección relativamente pequeña del producto a la vez. Cada miembro del
equipo debe examinar el producto de software y otros insumos de revisión antes
de la revisión
11-5
reuniones, tal vez mediante la aplicación de una técnica analítica (consulte la identificar los casos de no conformidad y producir un informe que requiere el
sección 3.3.3) a una pequeña sección del producto, o para todo el producto equipo para tomar medidas correctivas. Si bien puede haber muchos nombres
con un enfoque sólo en un aspecto, por ejemplo, interfaces. Cualquier formales para revisiones y auditorías,
anomalía encontrada se documenta y se envía al líder de inspección. Durante
tales como los identificados en el estándar (IEEE1028-97), el
la inspección, el jefe de inspección lleva a cabo la sesión y verifica que todo el
punto importante es que pueden ocurrir en casi cualquier producto en
mundo ha preparado para la inspección. Una lista de verificación, con
cualquier etapa del proceso de desarrollo o mantenimiento.
anomalías y preguntas pertinentes a los temas de interés, es una herramienta
común utilizada en las inspecciones. La lista resultante a menudo clasifica las
anomalías (se refieren a IEEE1044-93 para más detalles) y es 3. Consideraciones prácticas

revisado para 3.1.Software Requisitos de calidad

integridad y exactitud por el equipo. La decisión de inspección de salida [Hor03; Lew92; Rak97; Sch99; Wal89; Wal96]
debe corresponder a uno de los siguientes tres criterios:
3.1.1. factores de influencia

1. Aceptar sin, o como mucho menor, volver a trabajar Hay varios factores que influyen en la planificación, gestión y selección de
actividades SQM y técnicas, incluyendo:
2. Aceptar con la verificación de la reanudación
El dominio del sistema en el que residirá el software (seguridad
3. reinspeccione
crítica, de misión crítica, Business-crítico)
reuniones de inspección suelen durar unas pocas horas, mientras que las revisiones técnicas y

auditorías son por lo general más amplia en su alcance y toman más tiempo.
Sistema y del software requisitos El comerciales (externos) o
componentes estándar (internos) que se utilizan en el sistema de
2.3.4. Paseos virtuales las normas específicas de ingeniería de software de aplicación

[Fre98; Hor03; Pfl01; Pre04; Som05; Wal89;

Wal96]
Los métodos y herramientas de software para ser utilizados para el
“El propósito de un recorrido es evaluar un producto de software. Un desarrollo y mantenimiento, y para la evaluación de la calidad y mejora el
recorrido puede llevarse a cabo con el propósito de educar a una
presupuesto, el personal, la organización del proyecto, planes, y la
audiencia con respecto a un producto de software. ”(IEEE1028-97). Los
programación de todos los procesos de los usuarios previstos y uso del
principales objetivos son [IEEE1028-97]:
sistema de nivel de integridad de la información del sistema en estos
factores influye en cómo se organizan y documentan los procesos SQM,
encontrar anomalías
la forma específica se seleccionan las actividades de SQM, y qué
Mejorar el producto de software consideran
recursos son necesarios y que impondrá límites a los esfuerzos.
implementaciones alternativas

evaluar la conformidad con las normas y especificaciones

El recorrido es similar a una inspección, pero por lo general se lleva a cabo de 3.1.2. Confianza
manera menos formal. El recorrido está organizado principalmente por el ingeniero
En los casos en que un fallo del sistema puede tener consecuencias muy
de software para dar a sus compañeros de equipo la oportunidad de revisar su
graves, la fiabilidad global (hardware, software y humana) es el principal
trabajo, como una técnica de aseguramiento.
requisito de calidad más allá de la funcionalidad básica. fiabilidad software
incluye características tales como la tolerancia a fallos, seguridad, seguridad
2.3.5. auditorías y facilidad de uso. La fiabilidad es también un criterio que se puede definir en
términos de fiabilidad (ISO9126). El cuerpo de la literatura para los sistemas
[Fre98; Hor03; Pfl01; PRE01; Som05; Voa99;
debe ser altamente confiable ( “sistemas de alta integridad” “alta confianza”
o). La terminología para los sistemas mecánicos y eléctricos tradicionales
Wal89; Wal96]
que no pueden incluir software ha sido importado para la discusión de las
“El propósito de una auditoría de software es proporcionar una evaluación amenazas o riesgos, los riesgos, la integridad del sistema, y ​conceptos
independiente de la conformidad de los productos y procesos de software relacionados, y puede ser encontrado en las referencias citadas en esta
con la normativa aplicable, sección.
normas, directrices, planes y procedimientos”[IEEE1028- 97]. La auditoría es
una actividad organizada formalmente, con participantes que tienen
funciones específicas, tales como auditor principal, otro auditor, una
grabadora, o un iniciador, e incluye un representante de la organización
auditada. La auditoría

11-6 © IEEE - 2004 Versión

3.1.3. los niveles de integridad de software
El nivel de integridad se determina basándose en las posibles consecuencias de
un fallo del software y de la probabilidad de fallo. Para el software en el que la
seguridad o la seguridad es importante, técnicas como el análisis de riesgos para
el análisis de la seguridad o la amenaza para la seguridad pueden ser utilizados
para desarrollar una actividad de planificación que identificar dónde posibles
puntos débiles que se encuentran. El historial de fallos de software similar
también puede ayudar a identificar qué técnicas serán de gran utilidad en la
detección de fallos y la evaluación de la calidad. niveles de integridad (por
ejemplo, la gradación de la integridad) se proponen en (IEEE1012-98).
Caracterización 3.2.Defect
[Fri95; Hor03; Lew92; Rub94; Wak99; Wal89] procesos SQM encontrar
defectos. La caracterización de los defectos conduce a una comprensión del
producto, facilita correcciones en el proceso o el producto, e informa a la
gestión de proyectos o el cliente del estado del proceso o producto. Muchos
defectos existen (fallo) taxonomías, y, si bien se han hecho intentos de
obtener un consenso sobre una falla y el fracaso taxonomía, la literatura
indica que hay un buen número en uso. [Bei90, Chi96, Gra92],
(IEEE1044-93) Defecto (anomalía) la caracterización también se utiliza en
auditorías y revisiones, con el líder de opinión a menudo se presenta una
lista de anomalías proporcionados por los miembros del equipo para su
examen en una reunión de revisión.
A medida que nuevos métodos de diseño y las lenguas evolucionan, junto con los
avances en las tecnologías de software en general, nuevas clases de defectos
aparecen, y se requiere una gran cantidad de esfuerzo para interpretar clases
definidas anteriormente. Cuando el seguimiento de defectos, el ingeniero de software
está interesado no sólo en el número de defectos, sino también los tipos. Información
por sí sola, sin un poco de clasificación, en realidad no es de ninguna utilidad en la
identificación de las causas subyacentes de los defectos ya que determinados tipos
de problemas deben ser agrupados juntos para que las determinaciones a realizar
sobre ellos. El punto es establecer una taxonomía de defectos que sea significativo
para la organización y para el ingenieros de software.
SQM descubre información en todas las etapas de desarrollo de software y
mantenimiento. Típicamente, cuando se usa la palabra “defecto”, se refiere a
un “fallo” tal como se define a continuación. Sin embargo, diferentes culturas y
normas pueden utilizar tanto diferentes significados para estos términos, lo que
ha conducido a intentos de definir ellos. definiciones parciales tomadas de
estándar (IEEE610.12-90) son:
Error: “Una diferencia ... entre un resultado calculado y el resultado
correcto”
Fallo: “Un paso, proceso o de definición de datos incorrectos en un programa
de ordenador”
Fallo: “El [incorrecta] resultado de un fallo” error: “una acción humana
que produce un resultado incorrecto”
© IEEE - 2004 Versión
Las deficiencias detectadas en las pruebas como resultado de fallos de
software se incluyen como defectos en la discusión en esta sección. modelos
de fiabilidad se construyen a partir de datos de fallos recogidos durante las
pruebas de software o desde el software en el servicio, y por lo tanto pueden
ser utilizados para predecir futuros fallos y para ayudar en las decisiones sobre
cuándo detener la prueba. [Mus89] Una acción probable resultante de hallazgos
SQM es eliminar los defectos a partir del producto bajo examen. Otras acciones
permiten el logro de todo el valor de los resultados de las actividades de SQM.
Estas acciones incluyen analizar y resumir los resultados, y el uso de técnicas
de medición para mejorar el producto y el proceso, así como para realizar un
seguimiento de los defectos y su eliminación. La mejora de procesos se discute
principalmente en el proceso de ingeniería de software KA, con el proceso de
SQM ser una fuente de información.
Los datos sobre las insuficiencias y defectos encontrados durante la aplicación de
las técnicas de SQM pueden perderse a menos que se graban. Para algunas
técnicas (por ejemplo, revisiones técnicas, auditorías, inspecciones), grabadoras
están presentes para establecer dicha información, junto con las cuestiones y
decisiones. Cuando se utilizan herramientas automatizadas, la salida de la
herramienta puede proporcionar la información de defectos. Los datos acerca de
defectos puede ser recogida y registran en un formulario de SCR (solicitud de
cambio de software) y pueden posteriormente ser introducidos en algún tipo de
base de datos, ya sea manualmente o automáticamente, a partir de una
herramienta de análisis. Los informes sobre defectos se proporcionan a la gestión
de
el
organización.
3.3. Técnicas de gestión de calidad de software
[Bas94; Bei90; Con86; Chi96; Fen97; Fri95; Lev95; Mus89; Pen93;
Sch99; Wak99; Wei93; Zel98] técnicas SQM se pueden clasificar de
muchas formas: estática, las personas intensivos, analítica, dinámica.
3.3.1. técnicas estáticas
técnicas estáticas implican el examen de la documentación del proyecto y el
software, y otra información sobre los productos de software, sin ejecutarlas.
Estas técnicas pueden incluir las actividades de las personas intensivos (como
se define en el apartado 3.3.2) o actividades de análisis (como se define en
3.3.3) llevada a cabo por las personas, con o sin la ayuda de herramientas
automatizadas.
3.3.2. Personas con uso intensivo de las técnicas de la configuración para la
gente técnicas de uso intensivo, incluyendo revisiones y auditorías, pueden variar
de una reunión formal para una reunión informal o una situación de escritorio
cheque, pero (por lo general, al menos) dos o más personas están involucradas.
Preparación antes de tiempo puede ser necesario. Recursos distintos de los
artículos objeto de examen pueden incluir listas de comprobación y los resultados
de las técnicas de análisis y pruebas. Estas actividades se discuten en
(IEEE1028-97) en revisiones y auditorías. [Fre98, Hor03] y [Jon96, Rak97]
11-7
3.3.3. Técnicas analíticas especificación para asegurar de la salida trazabilidad,
coherencia, la integridad, la exactitud, y el rendimiento. Esta confirmación
Un ingeniero de software en general se aplica técnicas analíticas. A veces
incluye también las salidas de los procesos de desarrollo y
varios ingenieros de software utilizan la misma técnica, pero cada uno lo
mantenimiento, recogida, análisis y medición de los resultados. SQA
aplica a diferentes partes del producto. Algunas técnicas son herramienta
asegura que se han previsto los tipos adecuados de pruebas,
impulsada; otros son manuales. Algunos pueden encontrar defectos
desarrolladas e implementadas, y V & V desarrolla planes de pruebas,
directamente, pero por lo general se utilizan para apoyar otras técnicas.
estrategias, casos y procedimientos.
Algunos también incluyen varias evaluaciones como parte del análisis global
de la calidad. Ejemplos de tales técnicas incluyen el análisis de la
Las pruebas se discute en detalle en la pruebas de software KA. Dos tipos
complejidad, análisis de flujo de control, y el análisis algorítmico. Cada tipo
de pruebas pueden caer bajo los títulos de SQA y V & V, debido a su
de análisis tiene un propósito específico, y no todos los tipos se aplican a
responsabilidad por la calidad de los materiales utilizados en el proyecto:
cada proyecto. Un ejemplo de una técnica de soporte es el análisis de
complejidad, que es útil para determinar si o no
Evaluación y prueba de los instrumentos que se utilizarán en el proyecto

el diseño o (IEEE1462-98)

aplicación es demasiado complejo para desarrollar correctamente, para poner a las pruebas de conformidad (o revisión de prueba de conformidad) de
prueba, o de mantener. Los resultados de un análisis de complejidad también se componentes y productos COTS para ser utilizados en el producto; ahora
pueden utilizar en el desarrollo de casos de prueba. técnicas de defectos de existe un estándar para los paquetes de software (IEEE1465-98) A veces, una
investigación, tales como el análisis de flujo de control, también pueden ser utilizados
organización independiente de V & V puede pedir que controle el proceso de
para apoyar otra actividad. Para el software con muchos algoritmos, el análisis
prueba, ya veces para presenciar la ejecución real para asegurarse de que se
algorítmico es importante, sobre todo cuando un algoritmo incorrecto podría causar un
lleva a cabo de conformidad con procedimientos especificados. Una vez más,
resultado catastrófico. Hay demasiadas técnicas analíticas para mencionarlos todos.
V y V pueden ser llamados para evaluar la prueba en sí: adecuación de los
La lista y las referencias proporcionadas pueden ofrecer conocimientos sobre la
planes y procedimientos, y la adecuación y exactitud de los resultados.
selección de una técnica, así como sugerencias de lecturas adicionales.

Otros, más formales, los tipos de técnicas de análisis son conocidos como
Otro tipo de pruebas que pueden caer bajo el título de V & V es la organización
métodos formales. Se utilizan para verificar los requisitos de software y
de pruebas de terceros. El tercero no es el desarrollador, ni es de ninguna
diseños. Prueba de la corrección se aplica a las partes críticas de software. En
manera asociado con el desarrollo del producto. En cambio, el tercero es una
su mayoría se han utilizado en la verificación de las partes cruciales de los
instalación independiente, por lo general acreditado por algún organismo de la
sistemas críticos, como los requisitos de seguridad y protección específicas.
autoridad. Su propósito es poner a prueba un producto para la conformidad
(Nas97)
con un conjunto específico de requisitos.

3.3.4. técnicas dinámicas

Medición de la Calidad 3.4.Software
Diferentes tipos de técnicas dinámicas se realizan durante todo el [Gra92]
desarrollo y mantenimiento de software. Generalmente, estos son
Los modelos de la calidad del producto de software a menudo incluyen medidas
técnicas de prueba, pero las técnicas tales como la simulación, la
para determinar el grado de cada característica de calidad alcanzado por el
verificación de modelos, y la ejecución simbólica pueden considerarse
producto. Si se seleccionan adecuadamente, las medidas pueden apoyar la
dinámico. La lectura de códigos se considera una técnica estática, pero
calidad del software (entre otros aspectos de los procesos del ciclo de vida del
los ingenieros de software con experiencia puede ejecutar el código a
software) en múltiples formas. Ellos pueden ayudar en el proceso de toma de
medida que leen a través de él. En este sentido, la lectura de códigos
decisiones administrativas. Pueden encontrar áreas problemáticas y cuellos de
también se puede calificar como una técnica dinámica. Esta
discrepancia en la categorización indica que las personas con diferentes botella en el proceso de software; y pueden ayudar a los ingenieros de software

roles en la organización pueden considerar y aplicar estas técnicas de a evaluar la calidad de su trabajo para fines de SQA y para la mejora de la

forma diferente. Algunas pruebas pueden realizarse tanto en el proceso calidad del proceso a más largo plazo. Con la creciente sofisticación de

de desarrollo, proceso de SQA, o el proceso de V & V, dependiendo software, las cuestiones de calidad van más allá de si es o no el software
también de la organización del proyecto. Dado que SQM planea pruebas funciona a lo bien que logra los objetivos de calidad medibles. Hay unos
de dirección, esta sección incluye algunos comentarios sobre las cuantos temas donde la medición es compatible con SQM directamente. Estos
pruebas. incluyen la asistencia para decidir cuándo detener la prueba. por

3.3.5. Pruebas
esta, modelos de fiabilidad y
puntos de referencia, ambas a partir de datos de fallos y de fallos, son útiles.
Los procesos de aseguramiento descritos en SQA y V & V examinar cada
salida en relación con el requisito de software

11-8 © IEEE - 2004 Versión

El costo de los procesos SQM es un problema que casi siempre se crió en la
decisión de cómo un proyecto debe ser organizado. A menudo, se utilizan modelos
genéricos de costo, que se basan en cuando se encuentra un defecto y la cantidad
de esfuerzo que se necesita para reparar el defecto en relación con la búsqueda del
defecto más temprano en el proceso de desarrollo. Los datos del proyecto pueden
dar una mejor idea de los costos. La discusión sobre este tema se puede encontrar
en [Rak97: pp. 39-50]. información relacionada se puede encontrar en el Proceso de
Ingeniería de Software Ingeniería de Software y Gestión de Kas.
Por último, la SQM informa mismos proporcionan información valiosa no sólo
en estos procesos, sino también de cómo se pueden mejorar todos los
procesos del ciclo de vida del software. Las discusiones sobre estos temas se
encuentran en [McC04] y (IEEE1012-98).
Si bien las medidas para características de calidad y las características del
producto pueden ser útiles en sí mismos (por ejemplo, el número de
requisitos defectuosos o la proporción de los requisitos de defectuosos),
matemáticos y técnicas gráficas se pueden aplicar para ayudar en la
interpretación de las medidas. Estos sistemas se adaptan en las siguientes
categorías y se discuten en [Fen97, Jon96, Kan02, Lyu96, Mus99].
basado en la estadística (prueba de ejemplo, la prueba binomial, Chi-cuadrado) (por
ejemplo, análisis de Pareto, diagramas de correr, diagramas de dispersión, distribución
normal) Las pruebas estadísticas El análisis de tendencias
Predicción (por ejemplo, modelos de fiabilidad) Las técnicas de base
estadística y pruebas a menudo proporcionan una instantánea de las áreas más
problemáticos del producto de software bajo examen. Las tablas y gráficos
resultantes son ayudas de visualización que los tomadores de decisiones pueden
utilizar para enfocar los recursos donde aparecen más se necesitan. Los
resultados de análisis de tendencias pueden indicar que una
© IEEE - 2004 Versión
horario no se ha respetado, como en la prueba, o que ciertas clases de
fallos se hará más intensa a menos que se tomen medidas correctivas en
el desarrollo. Las técnicas de predicción ayudar en la planificación de
tiempo de la prueba y en la predicción de fracaso. Más discusión sobre la
medición en general aparece en el Proceso de Ingeniería de Software
Ingeniería de Software y Gestión de Kas. información más específica sobre
la medición de la prueba se presenta en la Prueba de Software KA.
Referencias [Fen97,
Jon96, Kan02, Pfl01] proporcionar
discusión sobre análisis de defectos, que consiste en medir las ocurrencias de
defectos y luego la aplicación de métodos estadísticos para la comprensión de los
tipos de defectos que se producen con mayor frecuencia, es decir, responder a
preguntas a fin de evaluar su densidad. También ayudan en la comprensión de las
tendencias y qué tan bien las técnicas de detección están trabajando, y qué tan
bien los procesos de desarrollo y mantenimiento están progresando. La medición
de la cobertura de la prueba ayuda a estimar la cantidad de esfuerzo de la prueba
que queda por hacer, y para predecir
posible restantes defectos. A partir de estos
métodos de medición, los perfiles de defectos pueden ser desarrollados para un
dominio de aplicación específica. Entonces, para el siguiente sistema de software
dentro de esa organización, los perfiles se pueden utilizar para guiar los procesos de
SQM, es decir, hacer el esfuerzo, donde los problemas son más probable que ocurra.
Del mismo modo, puntos de referencia, o recuentos de defectos típicos de ese
dominio, pueden servir como una ayuda en la determinación cuando el producto está
listo para la entrega.
La discusión sobre el uso de datos de SQM para mejorar los procesos
de desarrollo y mantenimiento aparece en la Gestión de Ingeniería de
Software y la Ingeniería de Procesos de Software de Kas.
11-9
METRO ATRIX DE T OPICS VS. R EFERENCIA MATERIAL

[McC77]

[Mus99]
[Lew92]
[Boe78]

[Hou99]

[NIST03]
[IEEE99]

[ISO900

[Rak97]
[Dac01]

[Wei96]
[Jon96]

[Lap91]

[Sei02]
[Pre04]

[Wal96]

[Wei93]
[Pfl01]
03-04]

[Kia95]
[ISO900

[Llo03]
1-00]
1. Calidad de Software
Fundamental

1.1 Software de Ingeniería de la

* *
Cultura y Ética

1.2 Valor y Costo de la Calidad * * * * * * * *

1.3 Modelos y características
* * * * * * * * * * * * * * *
de calidad

1.4 Mejora de la Calidad de

Software
* * *

[Som05]
[Rad02]
[Lew92]
[Ebe94]

[Voa99]
[Ack02]

[Sch99]
[Rak97]

[Wal89]

[Wal96]
[Gra92]

[Hor03]
[Fre98]

[Pre04]
[Pfl01]
[Gil93]

2. Procesos de Gestión de
Calidad de Software

2.1 Calidad de Software

* * * * * * * * * * * * *

2.2 Verificación y
validación
* * * * * * *

2.3 revisiones y auditorías * * * * * * * * * * * * *

[Mus99 ]
[McC04]

[Wak99]
[Mus89]
[Con86]

[Lew92]

[Rub94]
[Bas84]

[Kan02]

[Pen93]

[Rak97]

[Sch99]
[Fen97]

[Jon96]

[Lyu96]

[Wal89]
[Wal96]
[Wei93]
[Gra92]
[Hor03]

[Lev95]
[Chi96]
[Bei90]

[Fre98]

[Zel98]
[Fri95]

[Pfl01]

3. Consideraciones prácticas de
la calidad del software

3.1 Requisitos de calidad de

* * * * * *
software

3.2 Defecto
* * * * * * * * * *
Caracterización

3.3 Técnicas de SQM * * * * * * * * * * * * * * * * *

3.4 Medición de la Calidad de

* * * * * * * * *
Software

11-10 © IEEE - 2004 Versión


R ECOMMENDED R EFERENCIAS PARA S OFTWARE Q CALIDAD
[Ack02] FA Ackerman, "Inspecciones de software y la producción rentable
de software fiable," en
Ingeniería de Software, Volumen 2, Los procesos de apoyo; Richard H.
Thayer y Mark Christensen editores, Wiley-IEEE Computer Society Press,
2002. [Bas84] VR Basili y DMWeiss, "Una Metodología de recolección
Válido Software Engineering Data" IEEE Transactions on Software
Engineering, vol. SE-10, ISS. 6, 728-738, Noviembre, 1984 [Bei90] B.
Beizer,
Las técnicas de pruebas de software:
Internacional Thomson Press, 1990.
[Boe78] BW Boehm y otros, "Características de Calidad de Software" TRW
en serie Software Technologies, vol. 1, 1978
[Chi96] R. Chillarege, "ortogonal Clasificación de defectos", en Manual de
Software Ingeniería de Confiabilidad, M. Lyu, Ed .: IEEE CS Press, 1996.
[Con86] SD Conte, HE Dunsmore y VY Shen,
Ingeniería Software Metrics y modelos: The Benjamin / Cummings
Publishing Company, Inc., 1986.
[Dac01] G. Dache, "Empresas de TI será obtener una ventaja competitiva
mediante la integración de CMM con ISO9001," Actualización del sistema de
calidad, vol. 11, ISS. 11, noviembre de 2001 [Ebe94] RG Ebenau y S. Strauss, Software McConnell, Código completo: Manual práctico de construcción del
Proceso de inspección: McGraw-Hill, 1994.
[Fen98] NE Fenton y Pfleeger SL, Las métricas de software: un enfoque
riguroso y práctico, Segunda ed: International Thomson Computer Press,
1998.
[Fre98] DP Freedman y Weinberg GM, Manual de Tutoriales,
inspecciones y exámenes técnicos: Little, Brown and Company, 1998.
[Fri95] MA Friedman y JM Voas, Evaluación del programa: Fiabilidad,
Seguridad Capacidad de prueba: John Wiley & Sons, Inc., 1995. [Gil93] T.
Gilb, D. Graham, inspecciones de software, Addison, Reading, MA, 1993.
[Gra92] RB Grady, Software Metrics prácticas para la gestión de
proyectos y gestión de procesos: Prentice Hall, Englewood Cliffs, NJ
07632, 1992. [Hor03] JW Horch, Guía Práctica de Gestión de la Calidad
del software: Artech House Publishers, 2003. [Hou99] D. Houston,
"Calidad de Software Profesional"
ASQC, vol. 1, ISS. 2, 1999
[IEEE-CS-99] IEEE-CS-1999, "Ingeniería de software
Código de Ética y Práctica Profesional ", IEEE-CS / ACM,
1999, disponible
http://www.computer.org/certification/ethics.htm
[ISO9001-00] ISO 9001: 2000, Gestión de la calidad
© IEEE - 2004 Versión
Sistemas-Requisitos: ISO 2000.
[ISO90003-04] ISO / IEC 90003: 2004, software y
Ingeniería de Sistemas-Directrices para la aplicación de la norma
ISO9001: 2000 de Programas informáticos: ISO e IEC, 2004. [Jon96] C.
Jones y J. Capers, Aplicada de software de medición: Asegurando
productividad y calidad, Segunda ed: McGraw-Hill, 1996. [Kan02] SH Kan, Métricas
y modelos en Ingeniería de Software de Calidad, Segunda ed:
Addison-Wesley, 2002. [Kia95] D. Kiang, "Armonización de Normas
Internacionales de Software integridad y fiabilidad," en
Proc. IEEE Internacional de Normas de Ingeniería de Software Simposio, Los
Alamitos, CA, 1995 [Lap91] JC Laprie, Fiabilidad: Conceptos básicos y la
terminología en Inglés, francés, alemán, italiano y japonés, IFIP WG 10.4. Nueva
York: Springer-Verlag,
1991. [Lev95] MAL Leveson, Safeware: Seguridad y las computadoras del
sistema: Massachusetts: Addison-Wesley, 1995. [Lew92] RO Lewis, Verificación
y validación independiente: un proceso de vida Ciclo de Ingeniería de
Software de Calidad: John Wiley & Sons, Inc., 1992. [Llo03] Lloyds
Register, "Guía TickIT," ISS. 5, 2003, disponible en http://www.tickit.org
[Lyu96] MR Lyu, Manual de Ingeniería de Software Fiabilidad: Mc
Graw-Hill-/ IEEE, 1996. [Mcc77] JA McCall, "Factores de Calidad de
Software - General Electric," n77C1502, de junio de 1977 [McC04] S.
software, Microsoft Press, 2 Dakota del Norte
edición, 2004.
[Mus89] JD Musa y AF Ackerman, "Cuantificación de validación de
software: Al interrumpir las pruebas ?," IEEE Software, vol. 6, ISS. 3,
19-27, mayo, 1989 [Mus99] J. Musa, Software de Ingeniería de
Confiabilidad: el software más fiable, más rápido desarrollo y pruebas:
McGraw Hill, 1999.
[NIST03] Instituto Nacional de Estándares y Tecnología, "Programa
Nacional de Calidad Baldrige", disponible en http://www.quality.nist.gov
[Pen93] WW Peng y DR Wallace, "Análisis de errores de software",
Instituto Nacional de Normas y Tecnología, Gaithersburg, MD NIST SP
500-209 20899, de diciembre de
1993, disponible en http://hissa.nist.gov/SWERROR/ [Pfl01] Pfleeger SL, Ingeniería
de Software: Teoría y Práctica, Segunda ed: Prentice-Hall, Inc., 2001. []
Pre04 RS Pressman, Ingeniería de Software: Enfoque para profesionales, ed
a Sexto: McGraw-Hill, 2004. Software Costo baja [Rad02] R. Radice alta
calidad
11-11
Inspecciones, Paradoxicon, 2002, pp. 479. [Rak97] SR Rakitin, Verificación
y validación de software: Una Guía del practicante: Artech House, Inc.,
1997.
[Rub94] J. Rubin, Manual de pruebas de usabilidad: ¿Cómo planear, diseñar y
llevar a cabo pruebas eficaces: John Wiley & Sons, 1994.
"Hacia creíble Prueba de TI y Certificación," IEEE Software, 39-47,
julio-agosto de 1999 [Wal89] Dr. Wallace y RU Fujii, "Verificación y
validación de software: Una visión general" IEEE Software, vol. 6, ISS. 3,
10-17 de mayo de 1989 [Wal96] Dr. Wallace, L. Ippolito y B. Cuthill,
"Información de referencia para el Software de Verificación y validación
del proceso," NIST SP 500 a 234, Gaithersburg, MD 20899 NIST, abril,

[Sch99] GC Schulmeyer y JI McManus, Manual de Calidad de Software, Tercera

1996, disponible a
ed: Prentice Hall, 1999. [SEI02] Software Engineering Institute,
http://hissa.nist.gov/VV234/
"Capacidad
[Wei93] GM Weinberg, "Gestión de la Calidad del Software: Primer Orden
Madurez de Integración Modelo de Ingeniería de Software (CMMI),"
Medición", vol. 2: Dorset House, 1993, cap.
Software Engineering Institute, Universidad Carnegie Mellon CMU /
8, medir el costo y valor. [Wie96] K. Wiegers, La creación de una cultura de
SEI-2002-TR-028, TR-CES-2002-028, 2002
Ingeniería de Software: Dorset House, 1996.

[Som05] I. Sommerville, Ingeniería de software, Séptima edición:

Addison-Wesley, 2005.
[Voa99] J. Voas, "Software Certificación Para entornos de alta
Aseguramiento" IEEE Software, vol. 16, ISS. 4, 48-54, julio-agosto, 1999
[Zel98] MV Zelkowitz y DR Wallace, "Modelos experimentales para la
validación de la tecnología" Computadora, vol. 31, ISS.
5, 23-31, 1998

[Wak99] S. Wakid, DR Kuhn y DR Wallace,

11-12 © IEEE - 2004 Versión


UN PÉNDICE A. L LISTA DE F ás R EADINGS
(Abr96) A. Abran y PN Robillard, "Puntos de Función Análisis: un estudio
empírico de su medición
Procesos ", presentado en IEEE Transactions on Software Engineering,
1996 (Art93) LJ Arthur, Mejora de la calidad del software: Guía de un
iniciado de la GCT: John Wiley & Sons, 1993. (Bev97) N. Bevan, "Calidad
y Usabilidad: un nuevo marco," en El logro de la calidad del software del
producto, E. v. Veenendaal y J. McMullan, Eds. Uitgeverij Tutein
Nolthenius, Holanda, 1997. (Cha89) RN Charette, Análisis de Riesgos de
Ingeniería de Software y Gestión: McGraw-Hill, 1989. (Cro79) PB Crosby, La
calidad es libre de: McGraw-Hill, 1979. (Dem86) WE Deming, Fuera de la
crisis: MIT Press,
1986.
(Dod00) Departamento de Defensa y el Ejército de los Estados Unidos, "Practical
Software y Sistemas de Medición: Una Fundación para el objetivo de gestión de
proyectos, versión 4.0b," Octubre,
2000, disponible en http://www.psmsc.com
(Hum89) W. Humphrey, "Gestión del proceso de software", Massachusetts:
Addison Wesley, 1989, Cap. 8, 10, 16. (Hya96) LE Hyatt y L. Rosenberg, "un
modelo de calidad de software y métricas para la identificación de los riesgos
del proyecto y Evaluación de la Calidad de Software", presentado en la
Conferencia Anual octavo Software Technology, Utah, 1996 (Inc94) D. Ince , ISO
9001 y Calidad de Software.
© IEEE - 2004 Versión
London: McGraw-Hill, 1994. (Jur89) JM Juran, Juran y el liderazgo para la
calidad. Nueva- York: The Free Press, 1989.
(Kin92) MR Kindl, "Calidad de Software y Pruebas: ¿Qué DoD puede
aprender de las prácticas comerciales," Instituto de Investigación del Ejército
de EE.UU. en Gestión Información,
Comunicaciones y Ciencias de la Computación, Instituto de Tecnología de
Georgia, Atlanta, Georgia de agosto de 1992 (NAS97) de la NASA,
"Especificación formal Métodos y Análisis de la Guía de Verificación de los
programas y sistemas informáticos, Volumen
II: Un practicante de
Compañero," 1997, disponible a
http://eis.jpl.nasa.gov/quality/Formal_Methods/ (Pal97) JD
Palmer, "Trazabilidad", en Software
Ingenieria, M. Dorfman y R. Thayer, Eds., 1997, 266-
276.
(Ros98) L. Rosenberg, "Aplicación e Interpretación Objeto- métricas
orientadas", presentado en Software Tech. Conf.,
1998, disponible a
http://satc.gsfc.nasa.gov/support/index.html (Sur03) W. Suryn, A. y A.
Abran abril "ISO / IEC cuadrados. La segunda generación de estándares
para la calidad del producto de software", presentado en IASTED2003,
Marina del Rey, California, 2003 (Vin90) WG Vincenti, Lo que los
ingenieros saber y como saben son - Estudios analíticos forman
Aeronáutica Historia. Baltimore y Londres: John Hopkins University Press,
1990.
11-13
 (IEEE1462-98) IEEE Std 1462-1998 // ISO / IEC14102,
UN PÉNDICE B. L LISTA DE S NORMAS Tecnología de la Información - Guía para la evaluación y selección de
herramientas CASE.

(IEEE1465-98) IEEE Std 1465-1998 // ISO / IEC12119: 1994,

(FIPS140.1-94) FIPS 140-1, Requisitos de seguridad para módulos La adopción del estándar IEEE Estándar internacional
criptográficos, 1994. IDO / IEC12119: 1994 (E), Requisitos de información
(IEC61508-98) IEC 61508 "Seguridad funcional - Seguridad - Sistemas de piezas Tecnología-Software-paquetes de calidad y pruebas: IEEE, 1998.
relacionadas con 1,2,3," Institución de Ingenieros Eléctricos, 1998 (IEEE12207.0-96) IEEE / EIA 12207.0-
1996 // ISO / IEC12207: 1995, Implementación de la industria Int. Std.
(IEEE610.12-90) IEEE Std 610.12-1990 (R2002), Glosario IEEE Estándar ISO / IEC 12207: 95, Norma para Tecnología de la
de Ingeniería de Software Terminología: Información-Software Procesos del ciclo de vida, vol. IEEE,
IEEE, 1990. 1996.

(IEEE730-02) IEEE Std 730 a 2.002, Norma IEEE para Planes de (ISO9001-00) ISO 9001: 2000, Gestión de la calidad
Aseguramiento de Calidad de Software: IEEE, 2002. (IEEE982.1-88) IEEE Sistemas-Requisitos: ISO, 2000.
Std 982,1 a 1988, Diccionario estándar IEEE de Medidas para producir (ISO9126-01) ISO / IEC 9126-1: 2001, Software
software fiable, Ingeniería-producto Calidad-Parte 1: Modelo de Calidad: ISO e IEC, 2001.
1988.

(IEEE1008-87) IEEE Std 1008-1987 (R2003), IEEE estándar para el (ISO14598-98) ISO / IEC 14598: 1998, El software de evaluación del producto: ISO
software de pruebas unitarias: IEEE, 1987. (IEEE1012-98) IEEE Std e IEC, 1998. (ISO15026-98)
1012-1998, Verificación y validación del software: IEEE 1998. ISO / IEC 15026: 1998, Información
La tecnología - integridad del sistema y software de niveles: ISO e IEC, 1998.

(IEEE1028-97) IEEE Std 1028-1997 (R2002), Norma IEEE para software (ISO15504-98)

comentarios: IEEE, 1997. (IEEE1044-93) IEEE Std 1044-1993 (R2002), Norma ISO / IEC TR 15504-1998, Información
Tecnología - Software de evaluación de proceso (partes 1-9): ISO e IEC, 1998.
IEEE para la Clasificación de Software de Anomalías:
(ISO15939-00)

IEEE, 1993. ISO / IEC 15939: 2000, Información

Tecnología - Software Proceso de medida: ISO e IEC, 2000.
(IEEE1059-93) IEEE Std 1059-1993, Guía de IEEE para Software de
(ISO90003-04)
Verificación y Validación de Planes: IEEE, 1993. (IEEE1061-98) IEEE Std
ISO / IEC 90003: 2004, software y
1061-1998, Norma IEEE para una metodología de métricas de software de
Ingeniería de Sistemas-Directrices para la aplicación de la norma ISO9001: 2000
calidad: IEEE, 1998. (IEEE1228-94) IEEE Std 1228-1994, Los planes de
de Programas informáticos: ISO e IEC, 2004.
seguridad de software: IEEE, 1994.

11-14 © IEEE - 2004 Versión

 do CAPÍTULO 12 R EXALTADO

re ISCIPLINES DE
S OFTWARE mi NGENIERÍA

yo INTRODUCCIÓN

Con el fin de circunscribir la ingeniería de software, es necesario identificar las disciplinas con las que la ingeniería de software comparte una frontera común. En este
capítulo se identifica, en orden alfabético, estas disciplinas relacionadas. Por supuesto, las disciplinas relacionadas también comparten muchas fronteras comunes
entre ellos.

En este capítulo se identifica para cada disciplina relacionada y el uso de una fuente reconocida basada en el consenso que se encuentran:

una definición informativa (cuando sea posible); una lista de

áreas de conocimiento.

La Figura 1 da una representación gráfica de estas disciplinas relacionadas

Disciplinas relacionadas de
Ingeniería de Software

Ingeniería Ciencias de la Gestión de Gestión de la La ergonomía de Ingeniería de

administración Matemáticas
Informática Computación proyectos calidad software Sistemas

Figura 1 Disciplinas relacionadas de Ingeniería de Software

Prueba de Ingeniería de Procesamiento

L LISTA DE R EXALTADO re ISCIPLINES Y SU K ONOCIMIENTO UN REAS Digital de Señales Sistemas Distribuidos

Ingeniería Informática electrónica encajada Interacción

Persona-Ordenador Sistemas de Gestión

El proyecto de informe del volumen de la ingeniería informática del
proyecto Computing Curricula 2001 (CC2001) 1 afirma que “la ingeniería de Información Inteligente Sistemas

informática encarna la ciencia y la tecnología de diseño, construcción, Informáticos Redes sistemas operativos
implantación y mantenimiento de componentes de software y hardware de
Programación Fundamentos de
los sistemas informáticos modernos y equipos controlados por ordenador.”
Probabilidad y Estadística Social y

Asuntos Profesionales y verificación de

Este informe identifica las siguientes áreas de conocimiento (conocidas como áreas software VLSI / Diseño ASIC
en el informe) para la ingeniería informática:

Algoritmos y Complejidad

Organización de Sistemas Informáticos Ingeniería

Informática y Arquitectura Circuitos y Sistemas

Digitales estructuras lógicas discretas

1 http://www.eng.auburn.edu/ece/CCCE/Iron_Man_Draft_October_2003.pdf

© IEEE -2004 Versión 12-1

Ciencias de la Computación las siguientes áreas deben estar presentes en un plan de estudios de ingeniería
de grado:
El informe final del volumen en la informática del proyecto Computing
Álgebra lineal; Cálculo diferencial e
Curricula 2001 (CC2001) 2 identifica la siguiente lista de áreas de
conocimiento (identificado como áreas en el informe) para la informática: integral; Ecuaciones diferenciales;

Probabilidad; Estadística; Análisis

• Estructuras discretas
numérico; Matemáticas discretas.

• Fundamentos de programación

• Algoritmos y Complejidad

• Arquitectura y Organización
Una lista más precisa de temas matemáticos (llamadas unidades y temas en el
• Sistemas operativos informe) que sustentan la ingeniería de software se puede encontrar en el
proyecto de informe del volumen en la ingeniería de software del proyecto
• Net-Centric Computing
Computing Curricula 2001 (CC2001) 5.
• Lenguajes de programación

• La interacción persona-ordenador
Gestión de proyectos

• Gráficos y Computación Visual

La gestión del proyecto se define en la edición 2000 de la “Guía para la Dirección
• Sistemas inteligentes de Proyectos del Conocimiento” (PMBOK ®6 Guía) publicado por el Instituto de
Gestión de Proyectos y adoptado como norma IEEE 1490-2003, como “la
• Gestión de la información
aplicación de conocimientos, habilidades, herramientas y técnicas a las
• Cuestiones sociales y profesionales actividades del proyecto para satisfacer los requisitos del proyecto”. Las áreas de
conocimiento identificados en la Guía PMBOK para la gestión de proyectos son:
• Ingeniería de software

• Computational Ciencia y Métodos Numéricos

Gestión de las Adquisiciones del Proyecto Gestión de

administración
Proyectos Gestión de las Comunicaciones del Proyecto de

Las directrices europeas MBA definidos por la asociación europea de
organismos nacionales de acreditación (igual) 3
MBA establece que debe incluir, particularmente, la cobertura y la instrucción en:
Recursos Humanos del Proyecto Gestión de la Integración
del Alcance del Proyecto Proyecto de Gestión de Proyectos
Gestión del tiempo Gestión de los Costos del Proyecto de

- contabilidad Gestión de la Calidad del Proyecto de Gestión de Riesgos

- financiar

- marketing y ventas

- jefe de operaciones

- la gestión de los sistemas de información

Gestión de la calidad
- ley

- gestión de recursos humanos Gestión de la calidad se define en la norma ISO 9000-2000 como “actividades
coordinadas para dirigir y controlar una organización con respecto a la calidad” Los
- ciencias económicas
tres de referencia seleccionado en la gestión de la calidad son:
- análisis cuantitativo

- política de la empresa y la estrategia

- ISO 9000: 2000 Sistemas de gestión de calidad - Fundamentos

Matemáticas y vocabulario;

- ISO 9001: 2000 Sistemas de Gestión de la Calidad -

Dos fuentes se seleccionan para identificar la lista de áreas de conocimiento de
Requisitos;
las matemáticas. El informe titulado “Criterios de Acreditación y Procedimientos” 4 de
la Junta de Acreditación de Ingeniería de Canadá identifica que los elementos - ISO 9004: 2000 Sistemas de Gestión de Calidad - Directrices
apropiados de para la mejora de rendimiento;

2 http://www.computer.org/education/cc2001/final/cc2001.pdf
3 http://www.efmd.be/ 5 http://sites.computer.org/ccse/volume/FirstDraft.pdf
4 http://www.ccpe.ca/e/files/report_ceab.pdf 6 PMBOK es una marca registrada en los Estados Unidos y otras naciones.

12-2 © IEEE -2004 Versión

La Sociedad Americana para la Calidad identifica las siguientes áreas de (Meta) Modelos de HCl uso y
conocimiento (temas de descomposición de primer nivel en su contorno) en su Cuerpo
contexto de los ordenadores
de Conocimientos para la certificación como Ingeniero de Calidad 7:
Características organización social humana y

- Gestión y liderazgo en la ingeniería de calidad Trabajo Áreas de aplicación del Hombre-Máquina

- Los sistemas de calidad de desarrollo, implementación y verificación ajuste y adaptación humana

- Planificación, control, y asegurando producto y la calidad del Información de Procesamiento del Lenguaje Humano,
proceso;
Comunicación, ergonomía Interacción
- La fiabilidad y la gestión de riesgos;

- La resolución de problemas y la mejora de la calidad;

Computer System Interface y Arquitectura
- Métodos cuantitativos;
De entrada y de salida técnicas

de diálogo Diálogo de género

La ergonomía de software

Computer Graphics Diálogo

El campo de la ergonomía se define por el Comité Técnico ISO 159 en la
ergonomía como “La ergonomía o (factores humanos) es la disciplina
científica relacionada con la comprensión de las interacciones entre los
elementos humanos y otros de un sistema, y ​la profesión que aplica
teoría, principios, de datos y métodos para diseñar a fin de optimizar el
bienestar humano y en general
sistema
actuación." 8
Arquitectura de Procesos de
Desarrollo
Diseño Enfoques técnicas de implementación Técnicas de Evaluación
ejemplo, los sistemas y Estudios de Casos Una lista más precisa de los temas del
diseño de interfaz de la computadora humana (llamadas unidades y temas en el

informe) para propósitos del plan de estudios de ingeniería de software se pueden

A Areas de Conocimiento lista de ergonomía 9 tal como se aplica al software que se
encontrar en el proyecto de informe del volumen en la ingeniería de software de el
propone a continuación: Cognición
proyecto Computing Curricula 2001 (CC2001) 10.

Cognitiva AI I: Razonamiento

El aprendizaje automático y la inducción Gramática Formal Methods

en Ciencia Cognitiva del Lenguaje: Métodos formales en Ciencia

Ingeniería de Sistemas
Cognitiva: Métodos formales de razonamiento en la ciencia cognitiva:
El Consejo Internacional de Ingeniería de Sistemas (INCOSE) 11 afirma que
“Ingeniería de Sistemas es un enfoque interdisciplinar y los medios para
Arquitectura cognitiva cognitivo AI II: Aprender permitir la realización de sistemas exitosos. Se centra en la definición de
Fundamentos de la Ciencia Cognitiva extracción de las necesidades del cliente y la funcionalidad requerida al comienzo del
ciclo de desarrollo, la documentación de requisitos,
información a partir del habla y texto procesamiento léxico
entonces

de proceder a la síntesis de diseño y validación del sistema, mientras que teniendo

en cuenta el problema completo: el rendimiento de operaciones,
prueba, la fabricación, el costo y el horario,
Adquisición del Lenguaje computacional La
formación y apoyo y disposición. Ingeniería de Sistemas integra todas las
Naturaleza de IPO disciplinas y grupos de especialidad en un esfuerzo de equipo formando un
proceso de desarrollo estructurado que procede desde el concepto hasta la
producción y operación. Ingeniería de Sistemas considera tanto la las necesidades
7 http://www.asq.org/cert/types/cqe/bok.html
8 técnicas de todos los clientes con el objetivo de ofrecer un producto de calidad que
http://isotc.iso.ch/livelink/livelink.exe/fetch/2000/2122/687806/ISO_TC_159__ Ergonomics_.pdf? satisfaga las necesidades de los usuarios de negocios y.
/global/.devices/node@ = 1162319 y vernum = 0
9 Esta lista fue compilada para la edición 2001 de la Guía SWEBOK de la lista de cursos que se ofrecen
en el Departamento de Ciencias Cognitivas de la Universidad John Hopkins y de la ACM SIGCHI Los
planes de estudio para la Interacción Persona-Ordenador 9.

A continuación, la lista fue refinada por tres expertos en la materia: dos de la Universidad de Quebec en
Montreal y WW McMillan, de la Universidad de Eastern Michigan. Se les pidió que indicaran cuál de
estos temas debe ser conocido por un ingeniero de software. Los temas que fueron rechazadas por dos
10 http://sites.computer.org/ccse/volume/FirstDraft.pdf
de los tres encuestados fueron retirados de la lista original.
11 www.incose.org

© IEEE -2004 Versión 12-3

El Consejo Internacional de Ingeniería de Sistemas (INCOSE, www.incose.org) está
trabajando en una guía para la Ingeniería de Sistemas de Administración de
Conocimiento. Las versiones preliminares incluyen las siguientes áreas de
competencia de primer nivel:
Procesos 1.Business y evaluación operativa (BPOA)
2. Sistema / solución / Arquitectura prueba (ATPE)
Beneficio 3. Costo del Ciclo de Vida y costo (LCC y CBA)
4. Utilidad / Logística (S / L)
5. modelado, simulación, y análisis (MS & A)
6. Gestión: Riesgo, configuración de línea de base (MGT)

12-4 © IEEE -2004 Versión

 UN PÉNDICE UN
K ONOCIMIENTO UN REA re DESCRIPCIÓN S ESPECIFICACIONES
PARA EL yo RONMAN V ersion
DEL GRAMO NOTIFICACIONES AL S OFTWARE mi NGENIERÍA
segundo ODY DE K ONOCIMIENTO
yo INTRODUCCIÓN
En este documento se presenta la versión 1.9 de las especificaciones
proporcionadas por el equipo editorial de la Zona de conocimientos
especializados en las descripciones Área de Conocimiento de la Guía para el
Software Engineering Body of Knowledge (Ironman Version).
Este documento comienza presentando especificaciones sobre el contenido del
conocimiento Descripción del área. Criterios y requisitos se definen en caso de
avería de los temas propuestos, para la lógica subyacente en las averías y la
descripción sucinta de los temas, para la selección de materiales de referencia,
y para identificar áreas de conocimiento relevantes de disciplinas relacionadas.
También se identifican los documentos de entrada importantes y su papel
dentro del proyecto se explica. También se discuten los temas sin contenido,
como las directrices de formato de presentación y estilo.
do ONTENIDO GRAMO IRECTRICES
Las siguientes directrices se presentan en una forma esquemática en la figura
se encuentra a continuación. Mientras que todos los componentes son parte del
conocimiento Descripción del área, debe quedar muy claro que algunos
componentes son esenciales, mientras que otros no lo son. El desglose (s) de
temas, el material de referencia seleccionado y la matriz de material de
referencia frente a los temas son esenciales. Sin ellos no hay conocimiento
Descripción del área. Los otros componentes podrían ser producidos por otros
medios si, por cualquier razón, el equipo editorial no puede proporcionarles
dentro del plazo establecido y no debe ser visto como principales escollos.
do CRITERIOS Y requisitos para proponer la descomposición (S) DE
por temas en A
K ONOCIMIENTO UN REA
Los siguientes requisitos y criterios se deben utilizar al proponer un desglose
de los temas dentro de una determinada área del conocimiento:
a) Se espera que los especialistas Área de Conocimiento de proponer una o
posiblemente dos averías complementarias que son específicos de su área de
conocimiento. Los temas que se encuentran en todos los detalles dentro de una
determinada área del conocimiento deben ser idénticos.
b) Se espera que estas averías de los temas a ser “razonable”, no es
“perfecto”. La Guía para el
© IEEE - 2004 Versión
Ingeniería de Software de Administración de Conocimiento es
definitivamente vista como un esfuerzo de múltiples fases, y muchas
iteraciones dentro de cada fase, así como múltiples fases serán
necesarios para la mejora continua de estas averías.
c) El desglose propuesto de temas dentro de una
Área de conocimiento debe descomponer el subconjunto de la Ingeniería de
Software cuerpo de conocimiento que está “generalmente aceptado”. Véase la
sección 2.6 más adelante para una discusión más detallada sobre este.
d) El desglose propuesto de temas dentro de una
Área de conocimiento no debe suponer dominios de aplicación
específica, las necesidades del negocio, tamaños de
organizaciones, estructuras organizativas, filosofías de gestión,
modelos de ciclo de vida del software, tecnologías de software o
métodos de desarrollo de software.
e) La propuesta de reparto de temas debe, en lo posible, ser compatible
con las diversas escuelas de pensamiento dentro de la ingeniería de
software.
F) La propuesta de reparto de temas dentro de áreas de conocimiento debe
ser compatible con el desglose de la ingeniería de software que se
encuentra generalmente en la industria y en la literatura y las normas de
ingeniería de software.
) Se espera que el desglose propuesto de temas g ser lo más inclusivo
posible. Se considera mejor para sugerir demasiados temas y hacer
que se abandonó más tarde que a la inversa.
h) Se espera que los editores área de conocimiento asociados a adoptar la
posición de que a pesar de que los siguientes “temas” son comunes en
todas las áreas de conocimiento, también son una parte integral de
todas las áreas de conocimiento y, por tanto, deben ser incorporados
en la propuesta de reparto de temas de cada área de conocimiento.
Estos temas comunes son la calidad (en general) y la medición.
Tenga en cuenta que la cuestión de cómo manejar adecuadamente
estos “cruzada en marcha” o “temas” ortogonales y si o no deben ser
manejados de una manera diferente, no se ha resuelto por completo
todavía.
yo) Las averías propuestas deben ser a lo sumo dos o tres niveles de
profundidad. A pesar de que hay un límite superior o inferior se impone
sobre el número de temas dentro de cada área de conocimiento, se
espera Área de Conocimiento Editores Asociados proponer un razonable
y manejable
A-1
 número de temas por área de conocimiento. También énfasis debe
ser puesto en la selección de los mismos, más que en su
organización en una adecuada jerarquía temas.
j) nombres de los temas propuestos deben ser lo suficientemente importantes como para
ser significativa incluso cuando citado fuera de la Guía de la Ingeniería de Software de
Administración de Conocimiento.
k) La descripción de un área de conocimiento incluirá un gráfico (en forma de
árbol) que describe la descomposición conocimiento.
do CRITERIOS Y REQUISITOS PARA LA DESCRIPCIÓN DE TEMAS
a) Temas solo necesitan ser descrito suficientemente como para que el lector puede
seleccionar el material de referencia apropiado de acuerdo con su / sus
necesidades.
do Y CRITERIOS R EQUERIMIENTOS para la selección
R EFERENCIA METRO ATERIAL
un) material de referencia específica debe ser identificado para cada tema. Cada
material de referencia puede, por supuesto, cubrir múltiples temas.
b) Proyecto de Documentación de referencia puede ser capítulos de libros,
artículos en revistas arbitradas, arbitrado documentos de conferencias o
arbitrado informes técnicos o industriales o cualquier otro tipo de
artefacto reconocido como documentos web. Deben ser generalizada y
no deben ser de naturaleza confidencial. Referencia debe ser lo más
precisa posible identificando qué capítulo o sección específica es
relevante.
do) Material de referencia propuesto debe estar en Inglés.
d) Una cantidad razonable de material de referencia debe ser seleccionado para
cada área de conocimiento. Las siguientes pautas deben ser utilizados en
la determinación de cuánto es razonable:
Si el material de referencia fueron escritas de manera coherente que
siguió a la propuesta de reparto de temas y en un estilo uniforme (por
ejemplo, en un nuevo libro basado en la propuesta Descripción Área
de Conocimiento), un objetivo medio para el número de páginas sería
500. sin embargo, este objetivo no puede ser posible cuando se
selecciona el material de referencia existente debido a las diferencias
de estilo, y la superposición y la redundancia entre el material de
referencia seleccionado. La cantidad de
material de referencia sería
razonable si consistió en el material de estudio en esta área de conocimiento
de un examen de licencia de ingeniería de software que pasaría un graduado
después de completar cuatro años de experiencia laboral.
La Guía de la Ingeniería de Software de Administración de Conocimiento
está destinado, por definición, ser selectivo en la elección de los temas y
se asocia material de referencia La lista de material de referencia para
cada conocimiento
A-2
El área debe ser visto y se presenta como una “selección informada
y razonable” y no como una lista definitiva.
material de referencia adicional puede ser incluido en una lista de “Otras
lecturas”. Estas lecturas adicionales todavía deben estar relacionados
con los temas de la avería. También deben discutir el conocimiento
generalmente aceptado. No debería ser una matriz entre el material de
referencia que figura en Lecturas adicionales y los temas individuales.
mi) Si se considera viable y rentable por el IEEE Computer Society,
material de referencia seleccionado será publicado en la Guía para la
Ingeniería de Software de Administración de Conocimiento sitio web.
Para facilitar esta tarea, se debe dar preferencia a material de
referencia para los que los derechos de autor pertenecen ya a la IEEE
Computer Society. Sin embargo esto no debe ser visto como una
restricción o una obligación.
f) debe proporcionarse una matriz de material de referencia frente a los temas.
do Y CRITERIOS R EQUISITOS PARA IDENTIFICAR K ONOCIMIENTO
UN REAS DE LA
R EXALTADO re ISCIPLINES
a) Se espera que los Editores Asociados área de conocimiento de identificar en
una sección separada que áreas de conocimiento de las disciplinas
relacionadas son suficientemente relevantes para la Ingeniería de Software
área de conocimiento que se ha asignado a ellos el conocimiento de esperar
por un graduado más cuatro años de experiencia. Esta información será
especialmente útil para y se comprometerá mucho diálogo entre la Guía de la
Ingeniería de Software de Administración de la iniciativa del conocimiento y
nuestras iniciativas hermanas responsables de la definición de un plan de
estudios de ingeniería de software y las normas de rendimiento estándar para
los ingenieros de software.
La lista de las áreas de conocimiento de las disciplinas relacionadas se pueden
encontrar en la línea de base lista propuesta de disciplinas relacionadas. Si se
considera necesario, y si va acompañada de una justificación, Especialistas Área de
Conocimiento también pueden proponer disciplinas relacionadas adicionales que aún
no contiene o se identifican en la línea de base lista propuesta de disciplinas
relacionadas. (Tenga en cuenta que una clasificación de los temas de las disciplinas
relacionadas se ha producido, pero será publicada en el sitio web en una última fecha
en un documento de trabajo separado. Por favor, póngase en contacto con el equipo
editorial para más información).
do OMÚN T CAPAZ DE do ONTENIDOS
Área de Conocimiento descripciones deben utilizar el siguiente
Tabla de Contenidos:
Introducción
Desglose de los temas del área de conocimiento (para mayor
claridad, creemos que esta sección debería ser
© IEEE - 2004 Versión
 colocado delante y no en un apéndice al final del documento.
También, debe ir acompañada de una figura que describe la
descomposición) Matriz de temas vs. material de referencia
referencias recomendadas para el área de conocimiento que se
describe (por favor no mezclarlas con las referencias usadas para
escribir la descripción Área de Conocimiento)
Lista de lecturas recomendadas
W SOMBRERO Qué se entiende por “ CONOCIMIENTO GENERALMENTE
ACEPTADAS “?
El swebok es un término inclusivo todo- que describe la suma de
conocimientos dentro de la profesión de la ingeniería de software. Sin
embargo, la Guía para la Ingeniería de Software de Administración de
Conocimiento busca identificar y describir ese subconjunto del conjunto de
conocimientos que es generalmente aceptado o, en otras palabras, el cuerpo
de la base de conocimientos. Para ilustrar mejor lo que “el conocimiento
generalmente aceptado” es en relación con otros tipos de conocimiento, la
Figura 1 se propone un proyecto de tres categorías esquema para clasificar el
conocimiento.
El Instituto de Gestión de Proyectos en su Guía de los Fundamentos de la
Dirección de Proyectos 1 define “generalmente aceptado” conocimientos
para la gestión de proyectos de la siguiente manera:
'‘Generalmente aceptadas’ significa que el conocimiento y las prácticas descritas
son aplicables a la mayoría de los proyectos, la mayor parte del tiempo, y que
existe un amplio consenso sobre su valor y utilidad. “Generalmente aceptadas” no
significa que el conocimiento y las prácticas descritas son o deberían ser
aplicados de manera uniforme en todos los proyectos; el equipo de gestión de
proyectos es siempre responsable de determinar lo que es apropiado para
cualquier proyecto dado.'
La Guía para la Dirección de Proyectos del Conocimiento es ahora un
estándar IEEE.
En el Mont-Tremblant reunión inicial en 1998, el Consejo Asesor Industrial
define mejor “generalmente aceptado” como el conocimiento que debe
incluirse en el material de estudio de un examen de licencia de ingeniería de
software que pasaría un graduado después de completar cuatro años de
experiencia laboral. Estas dos definiciones deben ser vistos como
complementarios.
También se espera Editores Asociados Área de conocimiento a ser un
poco hacia el futuro en su interpretación teniendo en cuenta no sólo lo
que es “generalmente aceptado”, pero hoy y lo que esperan será
“generalmente aceptado” en un 3 a 5 años plazo.
Ver [1] “Una Guía para la Dirección de Proyectos del Conocimiento,” Project
1
Management Institute, Newton Square, PA 1996, 2000. Puede descargarse
desde www.pmi.org
© IEEE - 2004 Versión
Generalmente aceptado
las prácticas tradicionales establecidas
recomendados por muchas organizaciones
Prácticas utilizados sólo para ciertos tipos
Especializado
de software
Avanzada e Investigación
prácticas innovadoras probados y utilizados solamente por
algunas organizaciones y conceptos todavía siendo
desarrolladas y probadas en organizaciones de
investigación
Figura 1 Categorías de conocimiento
L ength DE K ONOCIMIENTO UN REA re DESCRIPCIÓN
Descripción Área de Conocimiento se espera actualmente que aproximadamente
en el rango de 10 páginas con el formato de la Conferencia Internacional sobre
Ingeniería de Software de formato como se define a continuación. Esto incluye
texto, referencias, apéndices y mesas, etc. Esto, por supuesto, no incluye los
materiales de referencia mismos. Este límite debe, sin embargo, no debe verse
como una restricción o una obligación.
R OLE DE mi EDITORIAL T EAM
Alain Abran y James W. Moore son los editores ejecutivos y son
responsables de mantener buenas relaciones con el IEEE CS, el Consejo
Asesor Industrial, la Junta de Control de Cambios Ejecutivo y el Grupo de
Expertos, así como para la estrategia general, el enfoque, la organización
y financiación del proyecto.
Pierre Bourque y Robert Dupuis son los editores y son responsables de la
coordinación, operación y logística de este proyecto. Más específicamente,
los editores son responsables de desarrollar el plan del proyecto, el espacio
del conocimiento de descripción de la especificación y de la coordinación de
Área de Conocimiento Editores Asociados y su contribución,
para
la contratación de los revisores y los capitanes de revisión, así como la
coordinación de los diferentes ciclos de revisión. Los editores son, por tanto,
responsable de la coherencia de toda la Guía y para la identificación y el
establecimiento de vínculos entre las áreas de conocimiento. Los editores y los
Editores Asociados Área de Conocimiento van a negociar la resolución de las
diferencias y coincidencias entre áreas de conocimiento.
yo IMPORTANTE R EXALTADO re OCUMENTOS (en orden
alfabético del primer autor)
1. P. Bourque, R. Dupuis, A. Abran, JW Moore, L. Tripp, D. Frailey,
una lista básica de Áreas de Conocimiento para el hombre de
piedra versión de la Guía de la
A-3
 Software Cuerpo de Ingeniería del Conocimiento, Universidad de
Quebec en Montreal, Montreal febrero
1999.
Sobre la base de la versión del hombre de paja, en los debates y las
expectativas expresadas en la reunión inicial del Consejo Asesor Industrial, en
otra agrupación de propuestas de conocimiento, y en criterios definidos en este
documento, este documento propone una lista básica de diez Conocimiento las
áreas de la versión de prueba de la Guía para la Ingeniería de Software cuerpo
de conocimientos. Esta línea de base puede evolucionar por supuesto que el
trabajo avance y los problemas son identificados durante el curso del proyecto.
Este documento está disponible en www.swebok.org.
2. P. Bourque, R. Dupuis, A. Abran, JW Moore, L. Tripp. Una línea de
base lista propuesta de disciplinas relacionadas para el Hombre de
Piedra versión de la Guía de la Ingeniería de Software de
Administración de Conocimiento, Universidad de Quebec en Montreal,
Montreal febrero
1999.
Sobre la base de la versión del hombre de paja, en los debates y las
expectativas expresadas en la reunión inicial fuera del Consejo Asesor
Industrial y en trabajos posteriores, este documento propone una lista básica
de las disciplinas relacionadas y áreas de conocimiento dentro de estas
disciplinas relacionadas. Este documento ha sido presentado para su
discusión con el Consejo Asesor Industrial y una lista de áreas de
conocimiento reconocido todavía tiene que ser identificado por ciertas
disciplinas relacionadas. Especialistas Área de Conocimiento serán
informados de la evolución de este documento. La versión actual está
disponible en www.swebok.org
3. P. Bourque, R. Dupuis, A. Abran, JW Moore, L. Tripp, K. Shyne, B.
Pflug, M. Maya, y G. Tremblay, Guía de la Ingeniería de Software
de Administración de Conocimiento - una versión artificial de paja,
Universidad de Quebec en Montreal, Montreal, Informe Técnico,
septiembre de 1998.
Este informe es la base de todo el proyecto. Se define la estrategia general
del proyecto, justificación y los principios subyacentes y propone una lista
inicial de áreas de conocimiento y disciplinas relacionadas.
Este informe está disponible en www.swebok.org.
4. JW Moore, Estándares de Ingeniería de Software, de un usuario
Hoja de Ruta. Los Alamitos: IEEE Computer Society Press, 1998.
Este libro describe
el alcance, papeles, usos, y
tendencias de desarrollo de las normas de ingeniería de software más ampliamente
utilizado. Se concentra en importantes
las actividades de ingeniería de software - Calidad y gestión de proyectos,
ingeniería de sistemas, confiabilidad y seguridad. El análisis y la
reagrupación de las colecciones estándar que expone a las relaciones
clave entre las normas.
A-4
A pesar de que la Guía de la Ingeniería de Software de Administración de
Conocimiento no es un proyecto de desarrollo de estándares de ingeniería de
software en sí, cuidado especial será tomada a lo largo del proyecto en
cuanto a la compatibilidad de la Guía con la corriente
IEEE e ISO Software
Normas Colección de ingeniería.
5. Glosario IEEE Estándar de Ingeniería de Software Terminología,
IEEE, Piscataway, NJ std 610.12-1990,
1990.
La jerarquía de las referencias de la terminología es Merriam nuevas
definiciones propuestas Collegiate Dictionary (10ª edición), el estándar IEEE
610.12 de Webster y si es necesario.
6. Tecnología de la Información - Procesos del ciclo de vida del software,
Norma Internacional, ISO Técnico / IEC 12207: 1995 (E), 1995.
Esta norma se considera el estándar clave en cuanto a la definición del
proceso de ciclo de vida y ha sido adoptado por los dos cuerpos principales
de normalización en la ingeniería de software: ISO / IEC JTC 1 SC7 y el
Comité de Normas de Ingeniería de Software IEEE Computer Society.
También se ha designado como la norma fundamental en torno al cual el
Comité de Normas de Ingeniería de Software (SESC) está actualmente
armonizando toda su colección de normas. Esta norma fue un insumo clave
para la versión hombre de paja. A pesar de que no tenemos la intención de
que la Guía para la Ingeniería de Software cuerpo de conocimiento sea
totalmente compatible 12207-, esta norma sigue siendo un insumo clave para
la versión de piedra hombre y cuidado especial será tomada a lo largo del
proyecto en cuanto a la compatibilidad de la guía con el 12207 estándar.
7. Collegiate Dictionary de Merriam Webster (10ª Edición). Ver nota para
IEEE 610.12 estándar.
S Y TYLE T TÉCNICA GRAMO IRECTRICES
Descripción Área de Conocimiento deben ajustarse a la Conferencia
Internacional sobre Ingeniería de Software Proceedings
formato (plantillas son disponible a
http://sunset.usc.edu/icse99/cfp /technical_papers.html). Se espera
Descripción Área de Conocimiento de seguir el IEEE Computer
Sociedad Guía de estilo. Ver
http://computer.org/author/style/cs-style.htm Microsoft Word es el formato de
presentación preferido. Por favor, póngase en contacto con el equipo editorial si esto no
es factible para usted.
O EL R re ETAILED GRAMO IRECTRICES
Al hacer referencia a la guía, se recomienda que utilice el título completo
“Guía para la SWEBOK” en lugar de solamente “SWEBOK.”
A los efectos de simplicidad, se recomienda que los editores área de
conocimiento Asociados evitar las notas al pie.
© IEEE - 2004 Versión
En cambio, deben tratar de incluir su contenido en el texto principal. edición (la gramática, puntuacion, y las mayúsculas), edición de estilo (de
conformidad con el estilo de la casa de las revistas Computer Society), y la
edición de contenidos (flujo, es decir, la claridad, la franqueza y la
Recomendamos utilizar en el texto referencias explícitas a las normas, a
organización). La edición final será un proceso de colaboración en el que el
diferencia de los números hacen referencia a artículos en la bibliografía
equipo editorial y los autores trabajan en conjunto para lograr una concisa, bien
simplemente insertando. Creemos que permitiría exponer mejor al lector a la
redactado, y útil una descripción Área de Conocimiento.
fuente y el alcance de una norma.

Las figuras y tablas que se acompañan de texto deben ser auto-explicativo o tener R Elease DE AUTOR
suficiente texto relacionado. Esto garantizaría que el lector sabe lo que las figuras
Todas las propiedades intelectuales asociados con la Guía para la Ingeniería de
y tablas significan. Asegúrese de que utiliza la información actual acerca de las
Software de Administración de Conocimiento permanecerán con la IEEE Computer
referencias (versiones, títulos, etc.)
Society. Se pidió Área de Conocimiento Editores Asociados para firmar un formulario de
autorización de derechos de autor.
Para asegurarse de que alguna información contenida en la Guía para el SWEBOK no se
convierta rápidamente obsoletas, por favor, evitar directamente las herramientas y los
También se entiende que la Guía de la Ingeniería de Software de
productos de denominación. En su lugar, tratar de nombrar sus funciones. La lista de
Administración de Conocimiento será puesto en el dominio público por el
herramientas y productos siempre se puede poner en un apéndice.
IEEE Computer Society, de forma gratuita a través de la tecnología web, o
por otros medios. Para más
Se espera que explican todas las siglas utilizadas y de utilizar todos los derechos de
información, ver http://computer.org/
autor correspondientes, marcas de servicio, etc. Las descripciones Área de copyright.htm
Conocimiento siempre deben ser escritas en tercera persona.

mi dición
El equipo editorial y los editores profesionales editarán Descripción Área
de Conocimiento. La edición incluye copia

© IEEE - 2004 Versión A-5

A-6 © IEEE - 2004 Versión
 UN PÉNDICE segundo

mi VOLUTION DE LA GRAMO NOTIFICACIONES AL S OFTWARE mi NGENIERÍA

segundo ODY DE K ONOCIMIENTO
proyecto conjunto ACM / IEEE-CS para desarrollar una
yo INTRODUCCIÓN plan de estudios de grado de ingeniería de software, es

A pesar de la Guía 2004 para la Ingeniería de Software de Administración de
Conocimiento es un hito en alcanzar un amplio acuerdo sobre el contenido de la
disciplina de la ingeniería de software, que no es el final del proceso. La Guía 2004
es simplemente la actual edición de una guía que seguir evolucionando para
satisfacer las necesidades de la comunidad de ingeniería de software. La
planificación de la evolución todavía no es completa, sino un esquema provisional
del proceso se proporciona en esta sección. Al escribir estas líneas, este proceso
ha sido aprobado por Consejo Asesor Industrial del proyecto e informó a la Junta
de Gobernadores de la IEEE Computer Society, pero aún no está bien financiado o
puesto en práctica.
en gran medida reconciliarse con el alcance de la Guía SWEBOK. los
Comité de Normas de Ingeniería de Software IEEE-CS
(SESC) ha organizado su colección por las áreas de conocimiento de
la Guía SWEBOK, y la Asociación de Estándares IEEE ya ha
publicado una edición recogida CD-ROM de normas de ingeniería de
software que refleje esa organización. ISO / IEC JTC / SC7,
el internacional normas
organización para el software e ingeniería de sistemas, se adopta la
guía SWEBOK como Informe ISO / IEC 19759 Técnica, y armonizar
su colección con la de IEEE.

S TAKEHOLDERS
El IEEE Computer Society Press, en cooperación con el SESC, está
La adopción generalizada de la Guía SWEBOK ha producido una comunidad
desarrollando una serie de libros sobre la base de las normas de
significativa de los interesados, además de la propia sociedad de
ingeniería de software y la Guía SWEBOK. Portal de Ingeniería de
computadora. Hay una serie de proyectos- tanto dentro como fuera de la
Software de la Computer Society, actualmente en la planificación, será
Compañía, que el ordenador están coordinando su contenido con el
contenido de la Guía SWEBOK. (Más sobre esto en un momento.) Varias organizado por las áreas de conocimiento de la Guía SWEBOK. El uso

empresas, entre ellos algunos de los miembros del Consejo Asesor Industrial a prueba la versión de la Guía SWEBOK fue traducido al japonés. Se
del proyecto, han adoptado la Guía para el uso en sus programas internos prevé que la versión 2004 también será traducido a los idiomas
para la educación y la formación. En un sentido más amplio, la comunidad de japonés, chino, y posiblemente otros.
ingeniería de software profesional, comunidad de desarrollo profesional,

y educación
prestar atención a la comunidad la Guía SWEBOK para ayudar a definir el alcance de sus
esfuerzos. Un grupo notable de las partes interesadas es
los titulares de de la IEEE Computer Society
certificación Certified Software Desarrollo
Profesional debido a que el alcance del examen PCSD está ampliamente
alineada con el alcance de la Guía SWEBOK. El IEEE Computer Society y
otras organizaciones están llevando a cabo una serie de proyectos que
tienen una dependencia de la evolución de la Guía SWEBOK:
El examen PCSD, inicialmente desarrollado en paralelo con la Guía
SWEBOK, evolucionará a un cierre partido a la Guía-tanto en alcance 1 y
material de referencia. plan de estudios de Educación a Distancia de la
Sociedad de Computación para los ingenieros de software tendrá el mismo
alcance que la Guía SWEBOK. Un curso panorama inicial ya está
disponible.
Aunque los objetivos de educación universitaria son algo diferentes de
las de desarrollo profesional, la
T ÉL mi VOLUTION PAG PROCESO
Obviamente, un producto con esta cantidad de absorción debe ser desarrollado
de un modo abierto, consultivo, deliberada y transparente para que otros
proyectos puedan coordinar esfuerzos con éxito. La estrategia prevista
actualmente es evolucionar la Guía SWEBOK utilizando un enfoque de
“tiempo-caja”. El enfoque de recuadros se selecciona porque permite la Guía
SWEBOK y coordinar proyectos para llevar a cabo la revisión a la espera de
una fecha fija para la convergencia. El recuadro temporal inicial está planeada
para ser cuatro años de duración. Al comienzo de la caja de tiempo, en
consulta con los proyectos de coordinación y plan general para la revisión de
cuatro años sería determinada. Durante el primer año, los cambios
estructurales en la Guía SWEBOK (por ejemplo, cambios en el número o el
alcance de las áreas de conocimiento) serían determinados. Durante el
segundo y tercer año, la selección y el tratamiento de los temas dentro de las
áreas de conocimiento serían revisados. Durante el cuarto año, el texto de las
descripciones Área de conocimiento sería revisado y se seleccionaría
referencias hasta a la fecha.

1 El PCSD añade un área de conocimiento, Prácticas de Negocios y Economía

El proyecto en su conjunto sería administrado por un comité de la Sociedad
Ingeniería, a las diez áreas de conocimiento incluidas en la Guía de
de Computación compuesta de voluntarios y
SWEBOK.

© IEEE - 2004 Versión B-1

representantes de los proyectos de coordinación. El comité sería responsable de
establecer los planes generales, coordinar con las partes interesadas, y
recomendar la aprobación de la revisión final. El comité estaría asesorado por un
Comité Asesor SWEBOK (SWAC) compuesto de adoptadores de organización
de la Guía SWEBOK. El SWAC también sería el enfoque para la obtención de
apoyo financiero corporativo para la evolución de la Guía SWEBOK. Pasado el
apoyo financiero de las empresas ha permitido que hagamos la Guía SWEBOK
disponible de forma gratuita en un sitio web. El apoyo futuro nos permitirá
continuar con la práctica para futuras ediciones.
En teoría, cada uno de los cuatro años incluiría un ciclo de talleres,
elaboración, votación y resolución de la votación. Un ciclo anual podría incluir
las siguientes actividades:
Un taller, organizado como parte de una importante conferencia,
especificaría cuestiones de tratamiento durante el año que viene, priorizar
los problemas, recomendar enfoques para tratar con ellos, y nominar
redactores para poner en práctica los enfoques.
Cada redactor escribiría o modificar una descripción área de conocimiento
mediante el método recomendado por el taller y las referencias disponibles.
En el último año del ciclo, redactores recomendarían específicas referencias
arriba-hasta la fecha para la cita en la Guía SWEBOK. Los redactores también
serían responsables de la modificación de sus corrientes de aire en respuesta
a los comentarios de balloters.
Cada ciclo anual incluiría votación en las revisiones de las descripciones
de área de conocimiento. Balloters revisarían las descripciones
redactadas Área de conocimiento y las referencias recomendadas,
proporcionar comentarios y votar la aprobación de las revisiones. La
votación estará abierta a los miembros de la sociedad de computadora y
otros participantes cualificados. (No socios tendrían que pagar una cuota
para sufragar los gastos de la votación.) Los titulares de la PCSD serían
especialmente bienvenidas como miembros del grupo de votación, o
como voluntarios en otros papeles. Un Comité Electoral Resolución sería
seleccionado por el Comité de Dirección para servir como intermediarios
entre los redactores y los balloters. Su función es determinar consenso
para los cambios solicitados por el grupo de votación y para asegurar
que
los redactores
implementar los cambios necesarios. En algunos casos, el Comité
Electoral resolución puede formular preguntas para el grupo de votación
y utilizar sus respuestas para guiar la revisión del proyecto. El objetivo
de cada año es llegar a un consenso entre el grupo de votación en las
áreas nuevas y revisadas proyecto de conocimiento y para ganar un
voto de aprobación de las balloters. Aunque la Guía SWEBOK no sería
cambiado hasta el final del tiempo asignado, se hará libremente
disponible del material aprobado del ciclo de cada año.
A la conclusión de la caja de tiempo, el producto terminado, Guía SWEBOK
2008, podría ser revisado y aprobado por la Junta de Gobernadores
Computer Society para su publicación. Si se puede obtener apoyo financiero
continuo corporativa, el producto estaría disponible libremente en un sitio
web.
B-2
UN NTICIPATED do AMBIOS
Es importante tener en cuenta que la Guía SWEBOK es de por sí un documento
conservadora por varias razones. En primer lugar, se limita a conocimientos propios
de la ingeniería de software; así se omite la información de los ingenieros de
disciplinas, incluso las disciplinas relacionadas aplicadas por software. En segundo
lugar, es desarrollado y aprobado por un proceso de consenso; por lo que sólo puede
registrar la información de la que se puede obtener un amplio acuerdo. Se excluye
En tercer lugar, el conocimiento considerado como especializado a dominios
específicos. Por último y lo más importante, la Guía registra sólo el conocimiento que
está “generalmente aceptado.” Incluso las técnicas actuales y válidos pueden
necesitar algún tiempo para ganar la aceptación general en la comunidad. Este
enfoque conservador es evidente en la actual Guía SWEBOK. Después de seis años
de trabajo, todavía tiene los mismos diez áreas de conocimiento. Uno se podría
preguntar si alguna vez se cambió que la selección de áreas de conocimiento. El plan
para la evolución incluye algunos criterios para la adición de un área de conocimiento
o modificar el alcance de un área de conocimiento. En principio, el candidato debe
ser ampliamente reconocida dentro y fuera de la comunidad de ingeniería de
software, ya que representa un área distinta del conocimiento y el conocimiento
generalmente aceptado dentro del área propuesta debe ser lo suficientemente
detallada y completa al tratamiento mérito similares a las actualmente en la Guía
SWEBOK. En términos operativos, debe ser posible desacoplar limpia el área de
conocimiento propuesta de los ya existentes y que la disociación debe añadir un
valor significativo a la taxonomía general de los conocimientos proporcionados por la
Guía. Sin embargo, ser simplemente un tema “transversal” no es justificación para el
tratamiento separado porque la separación, en muchos casos, simplemente agrava el
problema de la superposición de tema. En general, el crecimiento en el número total
de áreas de conocimiento se debe evitar cuando se complica los esfuerzos de los
lectores para encontrar la información deseada. La adición de un tema a un área de
conocimiento es más fácil. En principio, debe ser maduro (o, al menos, la madurez
rápidamente alcanzando) y se debe generalmente aceptado 2. Las pruebas de
aceptación general se puede encontrar en muchos lugares, incluyendo el software de
programas de estudios de ingeniería, estándares de ingeniería de software, y los
libros de texto utilizados. Por supuesto, los temas deben ser adecuados a punto de
diseño de la Guía SWEBOK de un título de licenciatura y cuatro años de experiencia. 3
2 Para la definición de “generalmente aceptado”, utilizamos IEEE Std 1490-1998,
Adopción de PMI Standard-Una guía para la Dirección de Proyectos del
Conocimiento: “generalmente aceptados significa que el conocimiento y las
prácticas descritas son aplicables a la mayoría de los proyectos de la mayoría de
la tiempo, y que existe un amplio consenso sobre su valor y utilidad. Esto no
significa que el conocimiento y las prácticas deben aplicarse de manera uniforme
a todos los proyectos sin considerar si son apropiadas “.
3 Por supuesto, esta especificación particular, se expresa en términos relevantes a
los EE.UU.. En otros países, podría decirse de otra manera.
© IEEE - 2004 Versión
Ese punto de diseño plantea el problema de que el volumen de material que se
encuentra en la Guía SWEBOK. La cantidad total de material debe ser
coherente con el punto de licenciatura y cuatro años de experiencia en el
diseño. Actualmente, el equipo editorial estima una cantidad adecuada para ser
5000 páginas de material de libros de texto. Durante la evolución de la Guía,
será necesario para gestionar las listas de material citado por lo que las
referencias son actualmente accesibles, proporcionar una cobertura adecuada
de las áreas de conocimiento, y total a una cantidad razonable de material.
© IEEE - 2004 Versión B-3
Un último tema es el papel que deben desempeñar los usuarios de la Guía
SWEBOK en su evolución. El equipo editorial cree que los comentarios del
público continua es el combustible que impulsará la evolución de la Guía
SWEBOK. Los comentarios del público plantear cuestiones para el tratamiento
por el taller anual, por lo tanto, establecer el programa de revisión de la Guía
SWEBOK. Esperamos proporcionar un foro público, en línea para hacer
comentarios por cualquier miembro de la comunidad de ingeniería de software y
para servir como un punto focal para las actividades de adopción.
B-4 © IEEE - 2004 Versión
 estándar es un glosario de términos de ingeniería de software.

proporciona

especifica el contenido denorma especifica

un plan el formato
de gestión y contenido del
de la configuración de los planesjunto
software de garantía de calidadpara
con los requisitos del software.
actividades específicas.

describe la forma y el contenido de un conjunto básico de documentación para la planificación, ejecución y presentación de informes de pruebas de software.
un conjunto de medidas para evaluar la fiabilidad de un producto de software y para la obtención de los pronósticos de la fiabilidad de un producto en fase de desarrollo.
recomienda el contenido y las características de una especificación de requisitos de software. se proporcionan esquemas de ejemplo.

Requisitos DE IEEE Y ISO S OFTWA

PAG X ONOCIMIENTO UN REAS
IEEE Std

UN PÉNDICE
Diseño

S X

de software
de software Software

C-1 IEEE Std IEEE Std IEEE Std Software

S S X

Pruebas

S PAG X

de construcción
Mantenimiento

del software

Gestión

PAG S X
de la
de ingeniería

Configuración de Software

Gestión

S S S X
de

Ingeniería de Software

Proceso

X de

Ingeniería de Software

Herramientas

de
X
ingeniería

de software y métodos
Calidad

PAG S P X tabla enumera producidos por IEEE e ISO / IEC JTC 1 / SC7, a

del software
 proporciona 1012a-

describe

una terminología consistente para la medición de la productividad de software y define una forma consistente para medir los elementos que intervienen en la productividad del software de computación.
norma describe el formato y contenido de un plan de gestión de proyectos de IEEE Std
software.
clasificaciones de anomalías y datos relacionados.

1045-1992 1044-1993 un enfoque de sonido a la unidad de pruebas de software

proporciona un enfoque uniforme para la clasificación de documento
las anomalías encontradas
recomienda en el software
contenido y su documentación.
y la organización Incluye
de un software listas de
de diseño de votos o
Descripción.
f

Requisitos

Diseño

S P

1012-1998 y 1998 de software Software

C-2 Software

S S

Pruebas

S PAG

de construcción
Mantenimiento

IEEE Std IEEE Std

del software

Gestión

S
de la

IEEE Std
Configuración de Software

Gestión

PAG PAG S S
de

Ingeniería de Software

© IEEE - 2004 Versión Proceso

S S S de

Ingeniería de Software

Herramientas

de

ingeniería

de software y métodos
Calidad

P P PAG S

del software
 orientación

describe una serie

norma describe un proceso para el mantenimiento del software y su gestión.

sobre el un conjunto

planificada de las normas sobre la integración de las herramientas CASE en un entorno de ingeniería de software productivo. Esta parte describe los concep
norma describe un método para la definición de los procesos del ciclo de vida del software.
proporciona
desarrollo de una especificación de requisitos del sistema, que abarca la identificación, organización, presentación y modificación de los requisitos. También proporciona requisitos
orientación mínimos
sobre para la estructura,
las características contenido
y cualidades deylos
formato de la documentación del usuario - tanto
requisitos.
las actividades de ingeniería de sistemas y procesos necesarios durante el ciclo de vida de un sistema para desarrollar las necesidades del cliente reunión sistemas, requisitos y limitaciones.
de prácticas útiles que pueden ser seleccionados y aplicados durante la adquisición de

Requisitos

PAG S S

Diseño

de software Software

C-3 Software

PAG S

Pruebas

de construcción
Mantenimiento

PAG S

del software

Gestión

de la

Configuración de Software

Gestión

S P S
de

Ingeniería de Software

Proceso

PAG S P S de

Ingeniería de Software

Herramientas

de
PAG
ingeniería

de software y métodos
Calidad

P S P

del software
 modelado conceptual, colectivamente llamado IDEF1X97 (IDEFObject). El lenguaje de apoyar la
proporciona

norma proporciona directrices para la evaluación y selección de herramientas CASE.

orientación sobre el formato y el contenido de un Concepto de Operaciones (CONOPS), documento que describe las características de

Requisitos

PAG S S

Diseño

S S

de software Software

C-4 Software

Pruebas

de construcción
Mantenimiento

del software

Gestión

de la

Configuración de Software

Gestión

de

Ingeniería de Software

© IEEE - 2004 Versión Proceso

S de

Ingeniería de Software

Herramientas

de
PAG PAG PAG PAG
ingeniería

de software y métodos
Calidad

del software
 un IEEE Dirección de Proyectos del Conocimiento definido por el Project Management Institute. Se identifica y se describe generalmente aceptado conocimiento con re

proporciona un proceso de ciclo deproporciona

vida para laprocesos
gestión del
delriesgo devida
ciclo de software.
para laElreutilización
procedimientodel es adecuado
software para su uso
sistemática. Los con IEEE / EIA 12.207.
procedimientos son adecuados para su uso con IEEE / EIA 12.207.

recomienda un marco conceptual y el contenido de la descripción arquitectónica de los sistemas intensivos en software.

Requisitos

S S

Diseño

de software Software

C-5 Software

Pruebas

de construcción
Mantenimiento

del software

Gestión

de la

Configuración de Software

Gestión

S PAG
de

Ingeniería de Software

Proceso

PAG PAG de

Ingeniería de Software

Herramientas

de
PAG
ingeniería

de software y métodos
Calidad

PAG

del software
 un modelo

especifica los requisitos para un sistema de gestiónrecomienda

de calidad de la organización
prácticas con elWeb
para páginas objetivo
Widede ofrece
World in

1: 2001
para la calidad del producto de software que cubre la calidad interna, externa de la calidad, y la calidad en uso. El modelo es en forma

Requisitos

X X PAG

Diseño

X X S

de software Software

C-6 Software

X X S

Pruebas

X X S

de construcción
Mantenimiento

X X

ISO / IEC 9126-

del software

Gestión

X X
de la

Configuración de Software

Gestión

X X
de

Ingeniería de Software

© IEEE - 2004 Versión Proceso

PAG PAG S de

Ingeniería de Software

Herramientas

de
X X
ingeniería

de software y métodos
Calidad

X X P PAG

del software
 proporciona describe los conceptos fundamentales de una clase de medidas conocidas colectivamente como el tamaño funcional.

una visión
dirección

general de los procesos de evaluación de productos de software y proporciona orientación y requisitos para la evaluación a nivel de organización o proyecto. Las normas proporcionan métodos para la medición, análisis y evalu

establecimiento de los procesos y actividades que se pueden aplicar en la adopción de la tecnología CASE.
el
en

Requisitos

PAG X

Diseño

de software Software

C-7 Software

Pruebas

de construcción
Mantenimiento

PAG S X

del software

Gestión

X
de la

Configuración de Software

Gestión

S X
de

Ingeniería de Software

Proceso

PAG de

Ingeniería de Software

Herramientas

de
PAG X
ingeniería

de software y métodos
Calidad

PAG S X

del software
 niveles de

proporciona un proceso de ciclo de vida para la medición del software. El procedimiento es adecuado para su uso con IEEE
integridad / EIA 12.207.
de software y los requisitos de integridad de software.

IFPUG 4,1 sin ajustar Counting Función Point, un método de medición del tamaño funcional conforme a los requisitos de la norma ISO / IEC 14143-1.

Requisitos

PAG PAG S

15504 (5 partes)

Diseño

de software Software

C-8 Software

Pruebas
partes) y borrador es

de construcción
Mantenimiento

S S

del software

Gestión

ISO / IEC TR 15504 (9

de la

Configuración de Software

Gestión

S S S
de

Ingeniería de Software

© IEEE - 2004 Versión Proceso

PAG P P P de

Ingeniería de Software

Herramientas

de

ingeniería

de software y métodos
Calidad

S S S PAG

del software
 Requisitos

PAG

Diseño

de software Software

C-9 Software

Pruebas

de construcción
Mantenimiento

del software

Gestión

de la

Configuración de Software

Gestión

S
de

Ingeniería de Software

Proceso

S de

Ingeniería de Software

Herramientas

de

ingeniería

de software y métodos
Calidad

PAG S

del software
C-10

© IEEE - 2004 Versión

 UN PÉNDICE re

do CLASIFICACIÓN DEL T OPICS UN egún segundo TELAR ' S T AXONOMY

yo INTRODUCCIÓN
Por lo que las evaluaciones se pueden adaptar a los ingenieros de
taxonomía de la flora 1 Es una clasificación muy conocido y ampliamente utilizado de los software o ingenieros de software especializados en ciertas áreas de
objetivos educativos cognitivas. Con el fin de ayudar al público que deseen utilizar la conocimiento más alto, ningún tema se da un nivel más alto que la
Guía como una herramienta en la definición material del curso, los programas taxonomía de análisis. Esto es
universitarios, los criterios de acreditación de programas universitarios, en consonancia con el enfoque adoptado en el Cuerpo Enseñanza de la
descripciones de trabajo, el papel Ingeniería de Software del Conocimiento (SEEK), donde ningún tema se le
descripciones dentro de una definición de proceso de ingeniería de software, asigna un nivel más alto que la taxonomía de aplicaciones 2. El propósito de
profesional desarrollo caminos y SEEK es definir un cuerpo de enseñanza de la ingeniería de software de
los programas de formación profesional y otras necesidades, se proponen los conocimientos apropiado
niveles de la taxonomía de Bloom para temas Guía SWEBOK en este apéndice para guiar el desarrollo de
para un graduado de ingeniería de software con cuatro años de experiencia. Un de licenciatura software Ingenieria planes de estudio.
graduado de ingeniería de software con cuatro años de experiencia es, en esencia, Aunque distintas en particular en términos de alcance, buscamos y la Guía SWEBOK
el “objetivo” de la Guía de SWEBOK según la definición de lo que se entiende por el están estrechamente relacionados 3.
conocimiento generalmente aceptado (véase la introducción de la Guía SWEBOK).
Taxonomía del dominio cognitivo propuesto en 1956 de Bloom contiene seis
niveles. tabla 1 4 presenta estos niveles y palabras clave asociadas a menudo
con cada nivel.
Desde este apéndice se refiere únicamente a lo que puede considerarse
como conocimiento “generalmente aceptado”, es muy importante recordar
que un ingeniero de software debe saber mucho más que esta “categoría”
del conocimiento. Además del conocimiento “generalmente aceptado”, un
graduado de ingeniería de software con cuatro años de conocimiento debe
poseer algunos elementos de las disciplinas relacionadas, así como ciertos
elementos de conocimiento especializado, conocimientos avanzados y
posiblemente incluso el conocimiento de investigación (véase la Introducción
de la Guía SWEBOK) . Los siguientes supuestos se hicieron al especificar
los niveles taxonomía propuesta:

Se proponen las evaluaciones para un ingeniero de software

“generalista” y no un ingeniero de software que trabaja en un grupo
especializado, tales como la gestión de configuración de software
equipo, para ejemplo.
Obviamente, un ingeniero de software tales requeriría o alcanzaría
niveles taxonómicos más altos en el área de especialidad de su
grupo;
Un ingeniero de software con cuatro años de experiencia no se encuentra
todavía en el comienzo de su carrera y se le asignaría relativamente pocas
funciones de gestión, o por lo menos para los grandes esfuerzos. 2 Ver Fuerza de Tarea Conjunta de Computación Los planes de estudio -
“Gestión relacionada Asociación IEEE Computer Society for Computing Machinery, Computing Curricula
temas”, por tanto, no se les da prioridad en las evaluaciones propuestas. Por la - Ingeniería de Software de volumen - Publid Proyecto 1 - Informática Plan de
misma razón, los niveles de la taxonomía tienden a ser más bajos para los “temas
estudios de Ingeniería de Software, 2003. http://sites.computer.org/ccse/
del ciclo de vida temprana”, tales como los relacionados con los requisitos de
software que para los temas más orientación técnica, tales como los que están 3 Ver P Bourque, F. Robert, J.-M. Lavoie, A. Lee, S. Trudel, T. Lethbridge,
dentro de diseño de software, la construcción de software o las pruebas de
“Guía para la Ingeniería de Software de Administración de Conocimiento
software.
(SWEBOK) y la Educación swebok (SEEK) - Un mapeo preliminar”, en Proc.
Décimo Intern. Taller de Tecnología de Software

y prácticas de ingeniería
Conferencia (STEP 2002), pp. 8-35, 2002)
1 B. Bloom (Eds), taxonomía de objetivos educativos: La Clasificación 4 Tabla tomada de

de las metas educativas, Mackay, 1956. http://www.nwlink.com/~donclark/hrd/bloom.html

© IEEE - 2004 Versión D-1

 tabla 1 Taxonomía de la flora

Nivel de la taxonomía de Bloom Palabras clave asociadas

Conocimiento: El recuerdo de los datos. Define, describe, identifica, sabe, etiquetas, listas de los partidos, nombres, esquemas, recuerda,
reconoce, reproduce, selecciona, estados.

Comprensión: Comprender el significado, la traducción, la interpolación, y Comprende, convertidos, defiende, distingue, estimaciones, explica, se extiende,
la interpretación de las instrucciones y problemas. Estado un problema en generaliza, da ejemplos, infiere, interpreta, parafrasea, predice, reescribe, resume,
sus propias palabras. se traduce.

Solicitud: Utilizar un concepto en una nueva situación o el uso de una Se aplica, cambios, calcula, construye, demuestra, descubre, manipula, modifica,
abstracción espontánea. Se aplica lo aprendido en el aula en opera, predice, se prepara, produce, se refiere, espectáculos, resuelve, usos.
situaciones novedosas en el lugar de trabajo.

Análisis: Separa los materiales o conceptos dentro Los análisis, descansos abajo, compara, contrastes, diagramas,
partes componentes de modo que su estructura organizativa puede deconstruye, diferencia, discrimina, distingue, identifica, ilustra, infiere, esquemas, se
ser entendido. Distingue entre hechos e inferencias. refiere, selecciona, separa.

Síntesis: Construye una estructura o patrón de diversos elementos. Poner las Categoriza, cosechadoras, compila, compone, crea, elabora, diseños, explica,
piezas juntas para formar un todo, con énfasis en la creación de un nuevo genera, modifica, organiza, planifica, reorganiza, reconstruye, se relaciona,
significado o estructura reorganiza, revisa, reescribe, resume, dice, escribe.

Evaluación: Hacer juicios sobre el valor de las ideas o materiales. Evalúa, compara, concluye, contrastes, critica, criticas, defiende, describe,
discrimina, evalúa, explica, interpreta, justifica, se relaciona, resume, apoya.

El desglose de los temas en las tablas no coincide perfectamente desglose Por último, por favor, tenga en cuenta que las evaluaciones de este apéndice sólo
del tha en las áreas de conocimiento. La evaluación de este apéndice se deben definitivamente ser vistos como una propuesta para ser desarrollado y validado
preparó mientras que algunos comentarios todavía estaban llegando. aún más.

RE- 2 © IEEE - 2004 Versión

S REQUISITOS DEL SOFTWARE 5 S OFTWARE re DISEÑO

Taxonom y

taxonomía
Nivel
Desglose de los temas Desglose de los temas

Nivel
1. Requisitos de software fundamentos
1. Fundamentos del Diseño de Software
Definición de requisito de software do
conceptos generales de diseño do
los requisitos del producto y de proceso do
Contexto de diseño de software do
Los requisitos funcionales y no funcionales do
proceso de diseño de software do
Propiedades emergentes do
técnicas que permite UN
requisitos cuantificables do
2. Las cuestiones clave en el diseño de software
requisitos del sistema y los requisitos de software do
concurrencia AP
2. Requisitos proceso
Control y manejo de eventos AP
Los modelos de proceso do
Distribución de los componentes AP
actores del proceso do
Error y manejo de excepciones y tolerancia a fallos AP
apoyo y gestión de procesos do
Interacción y presentación AP
la calidad y mejora de procesos do
la persistencia de datos AP
3. Requisitos elicitación
3. Estructura del software y la arquitectura
requisitos fuentes do
estructuras arquitectónicas y puntos de vista AP
técnicas de obtención AP
Los estilos arquitectónicos (patrones) macroarchictural UN
análisis 4. Requisitos
Los patrones de diseño (patrones) microarquitectónicas UN
requisitos de clasificación AP
Las familias de los programas y marcos do
modelado conceptual UN
4. Software de análisis de calidad de diseño y evaluat ion
requisitos de diseño y arquitectura de asignación
UN Atributos de calidad do

requisitos de negociación AP Análisis de calidad y técnicas de evaluación UN

5. Requisitos de especificación medidas do

documento de definición del sistema do

5. Software notaciones de diseño

especificación de requisitos del sistema do

descripciones estructurales (estático) AP

descripciones del comportamiento (dinámico ) AP

Especificación de Requerimientos de Software AP
6. Estrategias de diseño de software y métodos
6. Requisitos de validación
Las estrategias generales UN
requisitos críticas AP
orientados a funciones específicas (estructurado) de diseño AP
prototipado AP
diseño orientado a objetos UN
Modelo de validación do
Datos de diseño-estructura centrada do
Prueba de aceptacion AP
diseño basado en componentes (CDB) do
7. Consideraciones prácticas
Otros metodos do
naturaleza iterativa del proceso de requisitos do

Gestión del cambio AP

requisitos atributos do

requisitos de rastreo AP

La medición de los requisitos AP

5 K: Conocimiento, C: Comprensión, AP: Application, AN: Análisis, E:

Evaluación, S: Síntesis

© IEEE - 2004 Versión D-3

S OFTWARE do ONSTRUCCIÓN S OFTWARE T PRUEB

taxonomía
taxonomía

Nivel
Desglose de los temas

Nivel
Desglose de los temas

1. Software fundamentos de prueba

1. Fundamentos de construcción de software
terminología relacionados con las pruebas do
minimizando la complejidad UN
Cuestiones clave AP
anticipar el cambio UN
Las relaciones de las pruebas a otras actividades do
La construcción de la verificación UN
2. Los niveles de prueba
Los estándares en la construcción AP
El objetivo de las pruebas AP
2. Gestión de la construcción
Objetivos de las pruebas AP
métodos de construcción do
3. Las técnicas de prueba
planificación de la construcción AP
Sobre la base de la intuición y la experiencia del probador AP
medición de la construcción AP
basada en la especificación AP
3. Consideraciones prácticas
Código de base AP
diseño de la construcción UN
basada en la culpa AP
lenguas de construcción AP
basada en el uso AP
Codificación UN
Basado en la naturaleza de la solicitud AP
las pruebas de la construcción AP
Seleccionando y combinando técnicas AP
calidad de la construcción UN
4. Medidas relacionadas con la prueba
Integración AP
La evaluación del programa que se está probando UN

La evaluación de las pruebas realizadas UN

5. Proceso de Prueba

problemas de gestión do

actividades de prueba AP

RE- 4 © IEEE - 2004 Versión

S OFTWARE METRO ANTENIMIENTO S OFTWARE do ONFIGURACIÓN METRO ANAGEMEN T

taxonomía

taxonomía
Nivel

Nivel
Desglose de los temas

1. Fundamentos de mantenimiento de software 1. Gestión del Proceso de SMC

contexto de la organización de SMC do

Definiciones y terminología do

Limitaciones y orientaciones para SMC do

Naturaleza de mantenimiento do

La necesidad de mantenimiento do La planificación de SMC

La mayoría de los costos de mantenimiento do organización y responsabilidades SMC AP

Evolución del software do SCM recursos y horarios AP

Categorías de mantenimiento AP Selección de herramienta e implementación AP

2. Las cuestiones clave en el mantenimiento del software Proveedor de control / Subcontratista do

control de la interfaz do
Técnico
plan de gestión de configuración de software do
La comprensión limitada do

Pruebas AP La vigilancia de la gestión de configuración de software

Análisis de impacto UN medidas SCM y medición AP

mantenibilidad UN En-Proceso de auditorías de SMC do

Asuntos Gerenciales Identificación 2. Configuración del software

La alineación con las cuestiones de organización do La identificación de los elementos que se desea controlar

dotación de personal do configuración del software AP

los problemas del proceso do los elementos de configuración de software AP
Organizativo do relaciones entre los elementos de configuración de software AP
la estimación de los costes de mantenimiento Las versiones de software AP
Estimación de costos AP Base AP
Los modelos paramétricos do La adquisición de los elementos de configuración de software AP
Experiencia AP biblioteca de software do

medición de mantenimiento de software AP 3. Control de Configuración de Software

3. Proceso de Mantenimiento Solicitar, evaluar y aprobar los cambios de software

modelos de procesos de mantenimiento do

tablero de control de configuración de software AP
Actividades de mantenimiento
proceso de solicitud de cambio de software AP
Actividades únicas AP
La implementación de los cambios de software AP
Las actividades que apoyen AP
Desviaciones y exenciones do

4. Técnicas para el mantenimiento 4. Configuración de software de contabilidad Estado

comprensión del programa UN información sobre el estado de configuración de software do

Reingeniería do informes de estado de configuración de software AP

Ingeniería inversa do Auditoría 5. Configuración del software

Software de auditoría configuración funcional do

Software de auditoría configuración física do

En-Proceso de auditorías de una línea de base de software do

6. El software de administración de lanzamientos y Entrega

la construcción de software AP

gestión de versiones de software do

© IEEE - 2004 Versión D-5

S INGENIERÍA DE SOFTWARE METRO ANAG mi MENT S PROCESO DE INGENIERÍA DEL SOFTWARE

taxonomía

taxonomía
Nivel

Nivel
1. Iniciación y definición del alcance 1. Implementación del proceso y el cambio

La determinación y la negociación de los infraestructura de procesos

AP
requisitos
grupo de procesos de ingeniería de software do
Análisis de viabilidad AP
La experiencia de la fábrica do
Proceso para requisitos opinión
do Ocupaciones AP
/ revisión
Modelos para la implementación de procesos y el cambio
2. Software de planificación de proyectos K

Planificación de procesos do Consideraciones prácticas do

determinar entregables AP 2. Proceso de definición

Esfuerzo, el horario y la estimación de costos AP

modelos de ciclo de vida AP
Asignación de recursos AP
los procesos del ciclo de vida del software do
Gestión de riesgos AP
Notaciones para las definiciones de procesos do
Gestión de la calidad AP
proceso de adaptación do
plan de gestión do
Automatización do

3. promulgación del proyecto de software

3. Proceso de evaluación
Implementación de planes AP
modelos de evaluación de proceso do
la gestión de contratos con proveedor do
métodos de evaluación de procesos do
Aplicación del proceso de medición AP
4. Producto y medición de procesos
Process monitor UN

Proceso de control AP la medición de procesos de software AP

informes AP medición de producto de software AP

medida del tamaño AP

4. Revisión y evaluación
estructura de medición AP
La determinación de la satisfacción de las
AP medición de la calidad AP
necesidades

Revisar y evaluar el desempeño AP Calidad de los resultados de medición UN

modelos de información de software

5. Cierre
Construcción del modelo AP
La determinación de cierre AP
implementación del modelo AP
Las actividades de cierre AP
técnicas de medición
6. Software de Ingeniería de medición técnicas analíticas AP

Establecer y mantener el compromiso de técnicas de benchmarking do

do
medición
Planificar el proceso de medición do

Realizar el proceso de medición do

evaluar la medición do

RE- 6 © IEEE - 2004 Versión

S OFTWARE herramientas de ingeniería Un norte D ME thods S CALIDAD DEL SOFTWARE

taxonomía
taxonomía

Nivel
Nivel
Desglose de los temas

1. Fundamentos de calidad de software

1. Herramientas de software
cultura de ingeniería de software y la ética
UN
herramientas de requisitos de software AP

Las herramientas de diseño de software AP Valor y costos de calidad UN

herramientas para la construcción de software AP Los modelos de calidad y características

herramientas de pruebas de software AP la calidad del proceso de software UN

la calidad del producto de software UN

herramientas de mantenimiento de software AP
Mejora de calidad AP
herramientas de proceso de ingeniería de software AP

herramientas de calidad de software AP 2. Software de gestión de calidad proc eses

Software de herramientas de gestión de configuración del AP aseguramiento de la calidad del software AP

herramientas de gestión de la ingeniería de software AP Verificación y validación AP

Revisiones y auditorías
Problemas de la herramienta Varios AP
inspecciones AP
2. Los métodos de la ingeniería del software
Revisiones hechas por colegas AP
Los métodos heurísticos AP Tutoriales AP
Los métodos formales y notaciones do Pruebas AP
métodos de prototipado AP auditorías do

Varios problemas de método do

3. Consideraciones prácticas

los requisitos de calidad de aplicaciones

Criticidad de los sistemas do

Confianza do

los niveles de integridad de software do

caracterización de defectos AP
técnicas de gestión de la calidad del
software

técnicas estáticas AP

Las personas con uso intensivo de técnicas AP

técnicas analíticas AP

técnicas dinámicas AP

medición de la calidad del software AP

© IEEE - 2004 Versión D-7

RE- 8 © IEEE - 2004 Versión