Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
SOFTWARE
VERSIÓN 2004
SWEBOK
r
do
UN PROYECTO DEL COMITÉ DE LA PRÁCTICA PROFESIONAL DEL
IEEE COMPUTER SOCIETY
BORRADOR - ESPAÑOL
rra
Bo
GUÍA AL CUERPO DE CONOCIMIENTO DE LA INGENIERÍA DEL
SOFTWARE
VERSIÓN 2004
SWEBOK
r
do Directores ejecutivos
Alain Abran, École de Technologie Superieure
James W. Moore, The Mitre Corp.
Directores
Pierre Bourque, École De Technologie Superieure
Robert Dupuis, Universite Du Quebec A Montreal
rra
Jefe de proyecto
Leonard L. Tripp, Chair, Professional Practices Committee,
IEEE Computer Society (2001-2003)
Bo
Copyright © 2004 por The Institute of Electrical and Electronics Engineers, Inc. Todos los derechos reservados.
Copyright y permisos de impresión: Este documento puede ser copiado, completo o parcialmente, de cualquier forma o
para cualquier propósito, y con alteraciones, siempre que (1) dichas alteraciones son claramente indicadas como
alteraciones y (2) que esta nota de copyright esté incluida sin modificación en cualquier copia. Cualquier uso o distribución
de este documento está prohibido sin el consentimiento expreso de la IEEE.
Use este documento bajo la condición de que asegure y mantenga fuera de toda ofensa a IEEE de cualquier y toda
responsabilidad o daño a usted o su hardware o software, o terceras partes, incluyendo las cuotas de abogados, costes del
juicio, y otros costes y gastos relacionados que surjan del uso de este documento independientemente de la causa de dicha
responsabilidad.
IEEE PONE ESTE DOCUMENTO A DISPOSICIÓN TAL CUAL ESTÁ, SIN GARANTÍA ALGUNA, EXPRESADA O
IMPLICADA, COMO LA EXACTITUD, CAPACIDAD, EFICIENCIA COMERCIAL, O FUNCIONALIDAD DE ESTE
DOCUMENTO IEEE NO SERÁ RESPONSABLE DE CUALQUIER CONSECUENCIA, INDIRECTA, FORTUITA,
r
EJEMPLAR, O DE PELIGROS ESPECIALES, AÚN SI IEEE HA ADVERTIDO DE LA POSIBILIDAD DE DICHOS
PELIGROS.
r
CAPÍTULO 4. CONSTRUCCIÓN DE SOFTWARE ....................................................................................... 4-1
do
CAPÍTULO 6. MANTENIMIENTO DEL SOFTWARE ................................................................................... 6-1
CAPÍTULO 12. DISCIPLINAS RELACIONADAS CON LA INGENIERÍA DEL SOFTWARE ............................. 12-1
APÉNDICE C. IEEE E ISO ESTÁNDARES A LAS ÁREAS DE CONOCIMIENTO DEL SWEBOK ...................C-1
Nótese que la Guía no pretende definir el cuerpo de conocimiento, sino servir como un compendio y guía al cuerpo de
conocimiento que se ha desarrollado y evolucionado durante 4 décadas. Es más, este cuerpo de conocimiento no es
estático. La Guía debe necesariamente desarrollarse y evolucionar según madura la ingeniería del software. Sin embargo,
constituye un valioso elemento a la infraestructura de la ingeniería del software.
En 1958, el renombrado matemático estadístico John Tukey, acuño el término software. El término Ingeniería del
r
Software se utilizó por primera vez en el título de una conferencia de la OTAN celebrada en Alemania en 1968. La IEEE
Computer Society publicó las primeras Transacciones en Ingeniería del Software (Transactions on Software Engineering)
en 1972. El comité creado por la IEEE Computer Society para el desarrollo de estándares de ingeniería del software se
fundó en 1976.
do
La primera vista global de la ingeniería del software emerge del trabajo del equipo liderado por Fletcher Buckley para
desarrollar el estándar IEEE Std 730 para la calidad del software finalizado en 1979. El objetivo de dicho estándar fue el de
proporcionar un mínimo de requerimientos aceptables y uniformes para el aseguramiento de la calidad. Este estándar
influyó en el desarrollo de otros estándares posteriores relacionados con la gestión de la configuración, pruebas de
software, requerimientos del software, diseño del software y verificación y validación del software.
Durante los años 1981-1985, la IEEE Computer Society organizó una serie de talleres de trabajo sobre la aplicación
de los estándares de ingeniería del software en donde los profesionales que participaron compartieron sus experiencias con
los estándares existentes y planificaron futuros estándares incluyendo uno sobre medición y métricas para procesos y
rra
productos de la ingeniería del software. El resultado fue el IEEE Std 1002, Taxonomía de estándares de ingeniería del
software (1986), el cual proporciono una visión global de la ingeniería del software. El estándar describe la forma y
contenido de una taxonomía de estándares de ingeniería del software. Explica los diferentes tipos de estándares de
ingeniería del software, sus relaciones externas y funcionales, y el rol de las distintas funciones en el ciclo de vida del
software.
En 1990 comenzó una planificación para un estándar internacional con una visión general. La planificación se centró
en reconciliar las vistas de los procesos del software del estándar IEEE Std 1074 y el estándar 2167A del departamento de
defensa (DoD, en sus siglas en inglés) de los EE.UU. La revisión del estándar se publicó como DoD Std 498. El estándar
fue completado en 1995 como ISO/IEC 12207, Estándar para los procesos del ciclo de vida del software. Este estándar
proporciono un importante punto de arranque para el cuerpo de conocimiento contenido en este libro.
Bo
La aprobación de la moción por parte de la junta de gobierno del IEEE Computer Society supuso el arranque por
parte de Fletcher Buckley para la escritura de este libro. El consejo de la ACM (Association for Computing Machinery)
aprobó la moción en agosto de 1993. Las dos mociones llevaron a la creación de un comité conjunto dirigido por Mario
Barbacci y Stuart Zweben. La misión del comité conjunto fue: ―establecer un conjunto apropiado de criterios y normas
para la práctica profesional de la ingeniería del software sobre las que puedan basarse decisiones industriales,
certificaciones profesionales y planes de estudios. El comité directivo organizó el trabajo en las siguientes áreas:
Este libro proporciona el primer punto, el cuerpo de conocimiento necesario y prácticas recomendadas.
El código ético y conducta profesional para la Ingeniería del software fue terminado en 1998 y aprobado por la juntas
de gobierno de la ACM e IEEE Computer Society. Ha sido adoptado por numerosas empresas y organizaciones y se
incluye en libros de texto recientes.
Se espera que los lectores encuentren este libro útil como guía para el conocimiento y recursos necesarios en el
desarrollo de su profesión como profesionales de la ingeniería del software.
Este libro está dedicado a Fletcher Buckley en reconocimiento a su empeño en el promover la ingeniería del software
como una disciplina profesional y su excelente profesionalidad como ingeniero de software para radares.
r
Leonard L. Tripp, IEEE Fellow 2003
Chair, Professional Practices Committee, IEEE Computer Society (2001-2003)
Chair, Joint IEEE Computer Society and ACM Steering Committee
do
for the Establishment of Software Engineering as a Profession (1998-1999)
Chair, Software Engineering Standards Committee, IEEE Computer Society (1992-1998)
rra
Bo
EDITORES ASOCIADOS
Las siguientes personas trabajaron como directores asociados bien para la versión de prueba 2001 o bien la versión 2004.
r
Terry Bollinger, the MITRE Corporation, EEUU, terry@mitre.org
Philippe Gabrini, Département d‘informatique, UQAM, Canadá, gabrini.philippe@uqam.ca
Louis Martin, Département d‘informatique, UQAM, Canadá, martin.louis@uqam.ca
do
Pruebas del software
Antonia Bertolino y Eda Marchetti, ISTI-CNR, Italia, {antonia.bertolino}{eda.marchetti}@isti.cnr.it
Coordinador de referencias
Marc Bouisset, Département d‘informatique, UQAM, Bouisset.Marc@uqam.ca
COMITÉ EJECUTIVO PROFESIONAL
A fecha de publicación, las personas nombradas a continuación formaron el comité ejecutivo profesional:
François Coallier, École de technologie supérieure, como director de ISO/IEC JTC 1/SC7
r
Philippe Kruchten, University of British Columbia, como representante de Rational Software
do
Steve McConnell, Construx Software
Larry Reeker, National Institute of Standards and Technology, Department of Commerce, EEUU
rra
Las siguientes personas trabajaron con este comité en el control de cambios de la edición del 2004:
Donald Bagert, Rose-Hulman Institute of Technology, representing the IEEE Computer Society Professional Practices
Committee
Ann Sobel, Miami University, representado a la junta ejecutiva del Computing Curricula Software Engineering
Bo
PANEL DE EXPERTOS
Las siguientes personas trabajaron como panel de expertos en la preparación de la versión de prueba (Trial) de la
Guía:
r
do
rra
Bo
REVISORES
Las siguientes personas trabajaron como directores asociados en la versión de prueba (Trial) 2001 y/o la versión 2004.
r
Alleman, Glen, EEUU Booch, Grady, EEUU Cleavenger, Darrell, EEUU
Allen, Bob, Canadá Booker, Glenn, EEUU Cloos, Romain, Luxembourg
Allen, David, EEUU Börstler, Jürgen, Suecia Coallier, François, Canadá
Amorosa, Franciasco, Italia Borzovs, Juris, Latvia Coblentz, Brenda, EEUU
do
Amyot, Daniel, Canadá Botting, Richard, EEUU Cohen, Phil, Australia
Andrade, Daniel, Brasil Bourque, Pierre, Canadá Collard, Ross, Nueva Zelanda
April, Alain, Canadá Bowen, Thomas, EEUU Collignon, Stephane, Australia
Arroyo-Figueror, Javier, EEUU Boyd, Milt, EEUU Connors, Kathy Jo, EEUU
Ashford, Sonny, EEUU Boyer, Ken, EEUU Cooper, Daniel, EEUU
Atsushi, Sawada, Japón Brashear, Phil, EEUU Councill, Bill, EEUU
Backitis Jr., Frank, EEUU Briggs, Steve, EEUU Cox, Margery, EEUU
Bagert, Donald, EEUU Bright, Daniela, EEUU Cunin, Pierre-Yves, Francia
Baker, Jr., David, EEUU Brosseau, Jim, Canadá DaLuz, Joseph, EEUU
Baker, Theodore, EEUU Brotbeck, George, EEUU Dampier, David, EEUU
rra
Baldwin, Mark, EEUU Brown, Normand, Canadá Daneva, Maya, Canadá
Bales, David, Reino Unido Bruhn, Anna, EEUU Daneva, Maya, Canadá
Bamberger, Judy, EEUU Brune, Kevin, EEUU Daughtry, Taz, EEUU
Banerjee, Bakul, EEUU Bryant, Jeanne, EEUU Davis, Ruth, EEUU
Barber, Scott, EEUU Buglione, Luigi, Italia De Cesare, Sergio, Reino Unido
Barker, Harry, Reino Unido Bullock, James, EEUU Dekleva, Sasa, EEUU
Barnes, Julie, EEUU Burns, Robert, EEUU Del Castillo, Federico, Perú
Barney, David, Australia Burnstein, Ilene, EEUU Del Dago, Gustavo, Argentina
Barros, Rafael, Colombia Byrne, Edward, EEUU DeWeese, Perry, EEUU
Bastarache, Louis, Canadá Calizaya, Percy, Perú Di Nunno, Donn, EEUU
Bayer, Steven, EEUU Carreon, Juan, EEUU Diaz-Herrera, Jorge, EEUU
Beaulac, Adeline, Canadá Carroll, Sue, EEUU Dieste, Oscar, España
Bo
r
Fernandez-Sanchez, Jose Luis, Hankewitz, Lutz, Alemania Kasser, Joe, EEUU
España Harker, Rob, EEUU Kasser, Joseph, Australia
Filgueiras, Lucia, Brasil Hart, Hal, EEUU Katz, Alf, Australia
do
Finkelstein, Anthony, Reino Unido Hart, Ronald, EEUU Kececi, Nihal, Canadá
Flinchbaugh, Scott, EEUU Hartner, Clinton, EEUU Kell, Penelope, EEUU
Forrey, Arden, EEUU Hayeck, Elie, EEUU Kelly, Diane, Canadá
Fortenberry, Kirby, EEUU He, Zhonglin, Reino Unido Kelly, Frank, EEUU
Foster, Henrietta, EEUU Hedger, Dick, EEUU Kenett, Ron, Israel
Fowler, Martin, EEUU Hefner, Rick, EEUU Kenney, Mary L., EEUU
Fowler, John Jr., EEUU Heinrich, Mark, EEUU Kerievsky, Joshua, EEUU
Fox, Christopher, EEUU Heinze, Sherry, Canadá Kerr, John, EEUU
Frankl, Phyllis, EEUU Hensel, Alan, EEUU Kierzyk, Robert, EEUU
Freibergs, Imants, Latvia Herrmann, Debra, EEUU Kinsner, W., Canadá
Frezza, Stephen, EEUU Hesse, Wolfgang, Alemania Kirkpatrick, Harry, EEUU
rra
Fruehauf, Karol, Suiza Hilburn, Thomas, EEUU Kittiel, Linda, EEUU
Fuggetta, Alphonso, Italia Hill, Michael, EEUU Klappholz, David, EEUU
Fujii, Roger, EEUU Ho, Vinh, Canadá Klein, Joshua, Israel
FUSCHI, David Luigi, Italia Hodgen, Bruce, Australia Knight, Claire, Reino Unido
Fuschi, David Luigi, Italia Hodges, Brett, Canadá Knoke, Peter, EEUU
Gabrini, Philippe, Canadá Hoffman, Douglas, Canadá Ko, Roy, Hong Kong
Gagnon, Eric, Canadá Hoffman, Michael, EEUU Kolewe, Ralph, Canadá
Ganor, Eitan, Israel Hoganson, Tammy, EEUU Komal, Surinder Singh, Canadá
Garbajosa, Juan, España Hollocker, Chuck, EEUU Kovalovsky, Stefan, Austria
Garceau, Benoît, Canadá Horch, John, EEUU Krauth, Péter, Hungría
Garcia-Palencia, Omar, Howard, Adrian, Reino Unido Krishnan, Nirmala, EEUU
Bo
r
Low, Graham, Australia Müllerburg, Monika, Alemania Price, Margaretha, EEUU
Lutz, Michael, EEUU Murali, Nagarajan, Australia Pullum, Laura, EEUU
Lynch, Gary, EEUU Murphy, Mike, EEUU Purser, Keith, EEUU
do
Machado, Cristina, Brasil Napier, John, EEUU Purssey, John, Australia
MacKay, Stephen, Canadá Narasimhadevara, Sudha, Pustaver, John, EEUU
MacKenzie, Garth, EEUU Canadá Quinn, Anne, EEUU
MacNeil, Paul, EEUU Narawane, Ranjana, India Radnell, David, Australia
Magel, Kenneth, EEUU Narayanan, Ramanathan, India Rae, Andrew, Reino Unido
Mains, Harold, EEUU Navarro Ramirez, Daniel, Rafea, Ahmed, Ejipto
Malak, Renee, EEUU México Ramsden, Patrick, Australia
Maldonado, José Carlos, Brasil Navas Plano, Francisco, España Rao, N.Vyaghrewara, India
Marcos, Esperanza, España Navrat, Pavol, Eslovaquia Rawsthorne, Dan, EEUU
Marinescu, Radu, Rumanía Neumann, Dolly, EEUU Reader, Katherine, EEUU
Marm, Waldo, Perú Nguyen-Kim, Hong, Canadá Reddy, Vijay,EEUU
rra
Marusca, Ioan, Canadá Nikandros, George, Australia Redwine, Samuel, EEUU
Matlen, Duane, EEUU Nishiyama, Tetsuto, Japón Reed, Karl, Australia
Matsumoto, Yoshihiro, Japón Nunn, David, EEUU Reedy, Ann, EEUU
McBride, Tom, Australia O'Donoghue, David, Irlanda Reeker, Larry, EEUU
McCarthy, Glenn, EEUU Oliver, David John, Australia Rethard, Tom, EEUU
McChesney, Ian, Reino Unido Olson, Keith, EEUU Reussner, Ralf, Alemania
McCormick, Thomas, Canadá Oskarsson, Östen, Suecia Rios, Joaquin, España
McCown, Christian, EEUU Ostrom, Donald, EEUU Risbec, Philippe, Francia
McDonald, Jim, EEUU Oudshoorn, Michael, Australia Roach, Steve, EEUU
McGrath Carroll, Sue, EEUU Owen, Cherry, EEUU Robillard, Pierre, Canadá
McHutchison, Diane, EEUU Pai, Hsueh-Ieng, Canadá Rocha, Zalkind, Brasil
Bo
McKinnell, Brian, Canadá Parrish, Lee, EEUU Rodeiro Iglesias, Javier, España
McMichael, Robert, EEUU Parsons, Samuel, EEUU Rodriguez-Dapena, Patricia,
McMillan, William, EEUU Patel, Dilip, Reino Unido España
McQuaid, Patricia, EEUU Paulk, Mark, EEUU Rogoway, Paul, Israel
Mead, Nancy, EEUU Paella, Jan, República Checa Rontondi, Guido, Italia
Meeuse, Jaap, Países Bajos Pavlov, Vladimir, Ucrania Roose, Philippe, Francia
Meier, Michael, EEUU Pawlyszyn, Blanche, EEUU Rosca, Daniela, EEUU
Meisenzahl, Christopher, EEUU Pecceu, Didier, Francia Rosenberg, Linda, EEUU
Melhart, Bonnie, EEUU Perisic, Branko, Yugoslavia Rourke, Michael, Australia
Mengel, Susan, EEUU Perry, Dale, EEUU Rout, Terry, Australia
Meredith, Denis, EEUU Peters, Dennis, Canadá Rufer, Russ, EEUU
Meyerhoff, Dirk, Alemania Petersen, Erik, Australia Ruiz, Francisco, España
Mili, Hafedh, Canadá Pfahl, Dietmar, Alemania Ruocco, Anthony, EEUU
Miller, Chris, Países Bajos Pfeiffer, Martin, Alemania Rutherfoord, Rebecca, EEUU
Miller, Keith, EEUU Phillips, Dwayne, EEUU Ryan, Michael, Irlanda
Miller, Mark, EEUU Phipps, Robert, EEUU Salustri, Filippo, Canadá
Salustri, Filippo, Canadá Soundarajan, Neelam, EEUU Urbanowicz, Theodore, EEUU
Salwin, Arthur, EEUU Sousa Santos, Frederico, Van Duine, Dan, EEUU
Sanden, Bo, EEUU Portugal Van Ekris, Jaap, Países Bajos
Sandmayr, Helmut, Suiza Spillers, Mark, EEUU Van Oosterhout, Bram, Australia
Santana Filho, Ozeas Vieira, Spinellis, Diomidis, Grecia Vander Plaats, Jim, EEUU
Brasil Splaine, Steve, EEUU Vegas, Sira, España
Sato, Tomonobu, Japón Springer, Donald, EEUU Verner, June, EEUU
satyadas, antony, EEUU Staiger, John, EEUU Villas-Boas, André, Brasil
Satyadas, Antony, EEUU Starai, Thomas, EEUU Vollman, Thomas, EEUU
Schaaf, Robert, EEUU Steurs, Stefan, Belgium Walker, Richard, Australia
Scheper, Charlotte, EEUU St-Pierre, Denis, Canadá Walsh, Bucky, EEUU
Schiffel, Jeffrey, EEUU Stroulia, Eleni, Canadá Wang, Yingxu, Suecia
Schlicht, Bill, EEUU Subramanian, K.S., India Wear, Larry, EEUU
Schrott, William, EEUU Sundaram, Sai, Reino Unido Weigel, richard, EEUU
Schwarm, Stephen, EEUU Swanek, James, EEUU Weinstock, Charles, EEUU
r
Schweppe, Edmund, EEUU Swearingen, Sandra, EEUU Wenyin, Liu, China
Sebern, Mark, EEUU Szymkowiak, Paul, Canadá Werner, Linda, EEUU
Seffah, Ahmed, Canadá Tamai, Tetsuo, Japón Wheeler, David, EEUU
do
Selby, Nancy, EEUU Tasker, Dan, Nueva Zelanda White, Nathan, EEUU
Selph, William, EEUU Taylor, Stanford, EEUU White, Stephanie, EEUU
Sen, Dhruba, EEUU Terekhov, Andrey A., Russian Whitmire, Scott, EEUU
Senechal, Raymond, EEUU Federation Wijbrans, Klaas, The
Sepulveda, Christian, EEUU Terski, Matt, EEUU Países Bajos
Setlur, Atul, EEUU Thayer, Richard, EEUU Wijbrans-Roodbergen, Margot,
Sharp, David, EEUU Thomas, Michael, EEUU Países Bajos
Shepard, Terry, Canadá Thompson, A. Allan, Australia Wilkie, Frederick, Reino Unido
Shepherd, Alan, Alemania Thompson, John Barrie, Reino Unido Wille, Cornelius, Alemania
Shillato, Rrobert W, EEUU Titus, Jason, EEUU Wilson, Charles, EEUU
Shintani, Katsutoshi, Japón Tockey, Steve, EEUU Wilson, Leon, EEUU
rra
Silva, Andres, España Tovar, Edmundo, España Wilson, Russell, EEUU
Silva, Andres, España Towhidnejad, Massood, EEUU Woechan, Kenneth, EEUU
Singer, Carl, EEUU Trellue, Patricia, EEUU Woit, Denise, Canadá
Sinnett, Paul, Reino Unido Trèves, Nicolas, Francia Yadin, Aharon, Israel
Sintzoff, André, Francia Troy, Elliot, EEUU Yih, Swu, Taiwan
Sitte, Renate, Australia Tsui, Frank, EEUU Young, Michal, EEUU
Sky, Richard, EEUU Tsuneo, Furuyama, Japón Yrivarren, Jorge, Perú
Smilie, Kevin, EEUU Tuohy, Kenney, EEUU Znotka, Juergen, Alemania
Smith, David, EEUU Tuohy, Marsha P., EEUU Zuser, Wolfgang, Austria
Sophatsathit, Peraphon, Tailandia Turczyn, Stephen, EEUU Zvegintzov, Nicholas, EEUU
Sorensen, Reed, EEUU Upchurch, Richard, EEUU Zweben, Stu, EEUU
Bo
La siguiente moción fue unánimemente aprobada por el comité ejecutivo profesional el 6 de
febrero de 2004.
El comité ejecutivo profesional afirma que el cuerpo de conocimiento de la ingeniería del software iniciado en 1998 se ha
completado satisfactoriamente y endorsa la versión 2004 de la guía al SWEBOK y lo recomienda su aprobación a junta de
gobierno de IEEE Computer Society.
La siguiente moción fue unánimemente aprobada por el junta de gobierno del IEEE Computer
Society en febrero del 2004.
La junta de gobierno de IEEE Computer Society aprueba la edición del 2004 de la Guía al cuerpo de conocimiento de la
ingeniería del software y autoriza al director del comité de prácticas profesionales a proceder con su impresión.
r
do
rra
Bo
PREFACIO
r
En los EE.UU., la comisión de acreditación de de las AC. Las descripciones de las AC están diseñadas
ingenierías de ABET (Accreditation Board for para discernir entre los varios conceptos importantes,
Engineering and Technology) es el responsable permitiendo al lector encontrar rápidamente los temas de
do
de la acreditación de planes de estudios de grado interés. Una vez encontrado el tema de interés, el lector es
de ingeniería del software. referido a artículos clave o capítulos de libro
La Canadian Information Processing Society ha seleccionados por presentar el conocimiento de manera
publicado los criterios para acreditar programas sucinta.
universitarios de grado de ingeniería del software.
El CMM (Capability Maturiry Model) y el Con una ojeada a la guía, los lectores notarán que el
CMMI (Capability Maturiry Model Integration) contenido es sustancialmente diferente de la ―ciencia de la
del SEI (Software Enginering Institute) se informática‖. Al igual que el ingeniero electrónico se basa
emplean para evaluar la capacidad/madurez de la en física, el ingeniero del software se debería basar, entre
ingeniería del software en las empresas. Los otras cosas, en la informática. En estos dos casos, el
rra
estándares de gestión de calidad ISO 9000 han énfasis es necesariamente diferente. Los científicos
sido aplicados a la ingeniería del software en el (físicos, informáticos) incrementan nuestro conocimiento
estándar ISO/IEC 90003. de las leyes de la naturaleza, sin embargo, los ingenieros
La Junta de Ingenieros Profesionales de Texas ha aplican esas leyes para construir artefactos útiles bajo
comenzado a emitir licencias a los profesionales ciertas condiciones. Por tanto, el énfasis de esta guía se
de la ingeniería del software. centra en la construcción de artefactos de software útiles
La APEGBC (Association of Professional bajo ciertas restricciones.
Engineers and Geoscientists of British Columbia)
inscribe a ingenieros del software y la PEO Los lectores también notarán en muchos aspectos
(Professional Engineers of Ontario) ha anunciado importantes de la tecnología de la información pueden
los requerimientos para las licencias. constituir conocimientos importantes en la ingeniería del
La ACM (Association for Computing Machinery) software aún no cubiertos en esta guía, por ejemplo,
Bo
r
cuerpo de conocimiento que cae dentro del ámbito de la participación sugirieron la necesidad de una gestión a
ingeniería de software y proporciona referencias a otros tiempo completo en lugar de esfuerzos voluntarios y
conocimientos relevantes en otras disciplinas. Un capítulo altruistas. Con este fin, el IEEE Computer Society contrato
do
de la guía proporciona una visión global taxonómica de con el laboratorio de investigación de ingeniería de
disciplinas relacionadas derivadas de importantes fuentes. software de la Universidad de Québec en Montreal
(Université du Québec à Montréal -UQAM) para gestionar
El énfasis en la práctica de la ingeniería lleva a la guía a el proyecto. En los últimos años, UQAM se ha unido a la
tener una fuerte relación con literatura normativa. La Escuela de Tecnología Superior de Montréal, Quebec
mayoría de la literatura en la informática, tecnologías de la (ÉTS – École technologie supérieure).
información e ingeniería de software proporciona
información útil a los ingenieros del software, pero sólo El proyecto se dividió en tres fases: Hombre de Paja,
una pequeña parte de ella es normativa. Una referencia Hombre de Piedra y Hombre de Hierro. Un prototipo
normativa prescribe que debería hacer un ingeniero en una inicial, Hombre de Paja, demostró como el proyecto
situación específica en vez de proporcionar información podría ser organizado. La publicación de la ampliamente
rra
que podría ser útil. La literatura normativa está validada circulada versión de prueba de la guía en el 2001 (Trial
por consenso entre los profesionales, y se concentra en Version) marcó fin de la fase Hombre de Piedra e inicio
estándares y documentos relacionados. Desde la un periodo de prueba en uso. La guía actual marca el fin
concepción del SWEBOK, éste fue concebido con una de del periodo Hombre de Hierro proporcionando una
fuerte relación a la literatura normativa en la ingeniería del guía que ha alcanzado un consenso mediante revisiones y
software. Las dos entidades más importantes en la pruebas.
creación de estándares de ingeniería de software IEEE
Computer Society e ISO/IEC JCT1/SC7 están siendo El equipo que desarrolló el proyecto se basó en dos
representadas en el proyecto. En última instancia, principios fundamentales para el desarrollo de la guía:
esperamos que los estándares en la práctica de la transparencia y consenso. Por transparencia, se quiere
ingeniería del software contengan los principios decir que el proceso de desarrollo en sí mismo está
Bo
r
comentarios, los cuales están todos disponibles en El volumen de literatura publicado sobre la
http://www.swebok.org/. Para producir la versión ingeniería del software es abundante y las
actual, la versión de prueba (Trial Version) se utilizo referencias incluidas en esta guía no deberían ser
do
ampliablemente durante un periodo durante el cual se consideradas como la selección definitiva sino
generaron 17 artículos describiendo los beneficios como una selección razonable. Obviamente, hay
aspectos de la guía al igual que otros aspectos en los que excelentes autores y excelentes referencias que
se debía mejorar. Una encuesta a través de la Web, no están incluidos en esta guía. En este trabajo, la
recopilo información adicional: 573 personas de 55 países referencias seleccionadas lo fueron por estar en
se registraron para la encuesta; 124 revisores de 51 países inglés, fácilmente accesibles, recientes, fáciles de
proporcionaron 1.020 comentarios. Se sugirieron otras leer y por cubrir los temas de las AC.
mejoras a través de otros proyectos relacionados: IEEE-
CS/ACM Computing Curricula, le proyecto IEEE CS Hay referencias importantes y relevantes que no
Certified Software Development Professional, ISO/IEC han sido escritas en inglés que han sido omitidas
JTC1/SC7 (estándares de ingeniería del software y del material seleccionado.
rra
sistemas); el comité de estándares de ingeniería del
software del IEEE, la división de software de la ASQS Además uno debe considerar que:
(American Society for Quality), y una sociedad de
ingenieros profesionales, la CCPE (Canadian Council of La ingeniería del software es una disciplina
Professional Engineers). emergente, esto es especialmente cierto si se
compara con otras disciplinas más maduras. Por
tanto, las fronteras entre las AC de la ingeniería
CAMBIOS DESDE LA VERSIÓN DE PRUEBA del software y entre la ingeniería del software y
otras disciplinas relacionadas continúan
El objetivo general de la versión actual fue mejorar la evolucionando.
legibilidad, consistencia y usabilidad de la guía. Esto
Bo
implicó una reescritura todo el texto para hacer el estilo Los contenidos de esta guía deben ser vistos como una
más consistente a lo largo de todo el documento. En varias informada y razonable caracterización del cuerpo de
ocasiones la descomposición de las áreas de conocimiento conocimiento de la ingeniería de software, y base de su
(AC) fue reordenada para hacerla más usable, pero siendo futura evolución. Además, nótese que la guía no es un
cuidadoso en que incluyese la información aprobada por intento, ni intenta reemplazar o corregir ninguna de las
consenso. Se actualizó la lista de referencias de manera leyes, normas o procedimientos definidos por organismos
que fuesen más fáciles de conseguir. oficiales con respecto a la práctica y definición de la
ingeniería, y de la ingeniería del sobre el particular.
Tras el período de prueba se recomendó la reescritura de 3
AC. Se destacó que el AC de la construcción del software
era difícil de aplicar en un contexto práctico. El AC de
gestión fue percibido como próximo al concepto de
gestión en general y no lo suficientemente específico a la
ingeniería del software. Del AC de calidad se percibió que
mezclaba la calidad en el proceso y calidad en el producto,
y por tanto, también fue revisada.
Diciembre 2004
La Web del proyecto SWEBOK es: http://www.swebok.org/
r
RECONOCIMIENTOS
do
El equipo de coordinación del SWEBOK reconoce la El equipo de coordinación también quiere agradecer por su
gratitud por la ayuda por parte de los miembros del comité contribución al proyecto a las siguientes personas: Mark
ejecutivo profesional. La financiación de este proyecto se Ardis, Yussef Belkebir, Michel Boivin, Julie Bonneau,
ha debido a las siguientes organizaciones: ACM, Boing, Simon Bouchard, François Cossette, Vinh Duong, Gilles
CCPE (Canadian Council of Professional Engineers), Gauthier, Michèle Hébert, Paula Hawthorn, Richard W.
Construx Software, IEEE Computer Society, the MITRE Heiman, Julie Hudon, Idrissa Konkobo, Rene Köppel,
Corporation, NIST (National Institute of Standards and Lucette Lapointe, Claude Laporte, Luis Molinié, Hamdan
Technology), NRC Canadá (National Research Council of Msheik, Iphigénie N‘Diyae, Serge Oligny, Suzanne
Canadá), Rational Software, Raytheon Company, y SAP Paquette, Keith Paton, Dave Rayford, Normand Séguin,
Labs (Canadá). El equipo también agradece a los Paul Sinnett, Denis St-Pierre, Dale Strok, Pascale Tardif,
rra
miembros del panel de expertos. También queremos Louise Thibaudeau, Dolores Wallace, Évariste Valery
expresar nuestro agradecimiento por el trabajo inicial en la Bevo Wandji, y Michal Young.
descripción de las áreas de conocimiento completadas por
Imants Freibergs, Stephen Frezza, Andrew Gray, Vinh T. Finalmente, estamos seguros que hay otras personas que
Ho, Michael Lutz, Larry Reeker, Guy Tremblay, Chris han contribuido a esta guía directa o indirectamente, cuyos
Verhoef, y Sybille Wolff. El equipo de coordinación nombres han sido omitidos inadvertidamente. A estas
también agradece a los cientos de revisores su valiosa personas, ofrecemos nuestro agradecimiento tácito y
contribución. disculpas por haber omitido un reconocimiento explicito.
Bo
Bo
rra
do
r
CAPITULO 1
INTRODUCCIÓN A LA GUÍA
A pesar de los millones de profesionales del software en el Concluyeron que la profesión de la ingeniería está
mundo y de la presencia ubicua del software en nuestra caracterizada por varios componentes:
sociedad, sólo recientemente la ingeniería del software ha Una educación profesional inicial en un
alcanzado el estado de disciplina ingenieril y reconocida currículum validado por una sociedad de
profesión. acreditación.
Registro de la correcta práctica por medio de una
Alcázar un consenso por la profesión en un núcleo del certificación voluntaria o licencia obligatoria.
cuerpo de conocimiento es un hito clave en todas las Habilidad espacial de desarrollo y una continua
disciplinas y ha sido identificado por el IEEE Computer educación profesional.
r
Society como crucial para la evolución hacia un status Soporte comunitario por medio de una sociedad
profesional. Esta guía, escrita bajo los auspicios del comité profesional.
del ejercicio profesional, es parte de un proyecto multi- Un compromiso con las normas de conducta a
do
anual para alcanzar tal consenso. menudo prescritas en un código de ética.
¿QUÉ ES LA INGENIERÍA DEL SOFTWARE? Esta Guía contribuye a los primeros tres de estos
componentes. La articulación del Cuerpo del
El IEEE Computer Society define la ingeniería del Conocimiento es un paso esencial hacia el desarrollar una
software como: profesión porque representa un amplio consenso en lo que
―(1) Aplicación de un enfoque sistemático, disciplinado y respecta a qué debería conocer un profesional de la
cuantificable al desarrollo, operación y mantenimiento del ingeniería del software. Sin tal consenso, ningún examen
software, es decir, la aplicación de la ingeniería al de licenciatura puede ser validado, ningún plan de estudios
software. puede preparar a una persona para un examen, y no se
(2) El estudio de los métodos en (1)‖. 2
rra
puede formular unos criterios para la acreditación de dicho
plan de estudios. El desarrollo de un consenso es también
¿QUÉ ES UNA PROFESIÓN RECONOCIDA? un prerrequisito para la adopción de unas habilidades
coherentes de desarrollo y de un programa de educación
Para que la ingeniería del software sea una legítima continua para los profesionales de una organización.
disciplina y reconocida profesión, es imperativo un
consenso sobre el cuerpo de conocimiento. Este hecho es
bien ilustrado por Starr cuando define que puede ¿CUÁLES SON LOS OBJETIVOS DEL PROYECTO
considerarse como legítima disciplina reconocida SWEBOK?
profesión. En su libro, ganador del premio Pulitzer, sobre
la historia de la profesión médica de los EE.UU, indica: La guía no debería ser confundida con el cuerpo de
conocimiento en sí mismo, el cual en la literatura
Bo
―La legitimización de una autoridad profesional envuelve publicada. El propósito de la guía es describir que parte
tres afirmaciones distintivas: primero, todo conocimiento y del cuerpo de conocimiento es generalmente aceptada,
competencias de un profesional han sido validadas por organizar esa parte y proporcionar acceso a los temas de
una comunidad de compañeros de profesión; segundo, el interés. Información adicional de que se entiende por
conocimiento validado consensuadamente se basa en ―generalmente aceptado‖ se describe a continuación y en
fundamentos científicos racionales; y tercero, las el Apéndice A.
opiniones profesionales y consejos están orientadas hacia
valores fundamentales como la salud. Estos aspectos de La guía al cuerpo de conocimiento de ingeniería del
legitimidad corresponden con los tipos de atributos - - software se estableció con los siguientes 5 objetivos:
generalmente cubiertos en el término ‗profesión‘ ‖3.
1. Promover una visión consistente de la ingeniería
¿CUÁLES SON LAS CARACTERÍSTICAS DE UNA del software en el mundo.
PROFESIÓN? 2. Clarificar la situación – y definir fronteras – de la
Gary Ford y Norman Gibbs estudió varias profesiones, ingeniería del software con respecto a otras
incluyendo medicina, derecho, ingeniería y contabilidad. disciplinas como la informática, gestión de
proyectos, ingeniería informática y matemáticas.
2 3. caracterizar los contenidos de la disciplina de la
―IEEE Standard Glossary of Software Engineering
ingeniería del software
Terminology,‖ IEEE std 610.12-1990, 1990.
3 4. Proporcionar al cuerpo de conocimiento de la
P. Starr, The Social Transformation of American
ingeniería del software con los temas de interés
Medicine, Basic Books, 1982, p. 15.
5. Proporcionar una base para el desarrollo planes Tabla 2 Disciplinas relacionadas
de estudio, certificaciones individuales y Ingeniería informática
materiales para licencias.
Informática
El primero de estos objetivos una visión consistente de la Gestión
ingeniería del software fue proporcionada por el proceso
de desarrollo consistente en aproximadamente 500 Matemáticas
revisores de 42 países en la fase Hombre de Piedra, (1998- Gestión de proyectos
2001), la cual condujo a la versión de prueba; 120
revisores de 21 países en la fase Hombre de Hierro (2003, Gestión de calidad
la cual genero la versión 2004. Información adicional Ergonomía del software
sobre el proceso, se encuentra disponible en Prefacio y en
la Web (http://www.swebok.org/). Se contactaron Ingeniería de sistemas
sociedades profesionales y agencias públicas involucradas
con la ingeniería del software para que fueran conscientes ORGANIZACIÓN JERÁRQUICA
r
del proyecto y se les invitó a participar en el proceso de La organización de las AC en los capítulos proporciona el
desarrollo. Se reclutaron coordinadores asociados en tercer objetivo del proyecto – una caracterización de los
América del Norte, los países del pacífico y Europa. Se contenidos de la ingeniería del software. Especificaciones
do
hicieron presentaciones del proyecto en acontecimientos detalladas por el equipo de coordinadores editoriales a los
internacionales y se planificaron otros para el año coordinadores asociados en encuentra en el Apéndice A.
posterior.
La guía utiliza una organización jerárquica para
El segundo de los objetivos, el deseo de definir fronteras descomponer cada área de conocimiento en un conjunto de
para la ingeniería del software, motiva la organización temas catalogados. Una descomposición en 2 o 3 niveles
fundamental de esta guía. El material reconocido como proporciona una manera razonable de encontrar los temas.
perteneciente a la Ingeniería del software está organizado La guía trata los temas seleccionados de una manera
en las 10 áreas de conocimiento (AC) enumeradas en la compatible con las escuelas de pensamiento mayoritarias y
Tabla 1. Cada una de estas AC es tratada como un capítulo con las descomposiciones encontradas en las
de la guía.
rra
organizaciones, literatura y estándares. La descomposición
no presupone ningún dominio de aplicación particular,
forma de negocio, filosofía de gestión, métodos de
Tabla 1 Áreas de conocimiento del SWEBOK desarrollo, etc. La extensión de cada tema es la justa para
Requerimientos del software entender la naturaleza de los temas y para que el lector
Diseño del software pueda referirse a la literatura de forma satisfactoria.
Después de todo, el cuerpo de conocimiento se encuentra
Construcción del software en el material referenciado y no en la guía en sí misma.
Pruebas del software
MATERIALES DE REFERENCIA Y MATRICES
Mantenimiento del software
Gestión de la configuración del software Para proporcionar el acceso a los temas de interés de la
Bo
r
se aplica a la mayoría de los proyectos la mayoría del
tiempo, y su amplio consenso valida su valor y LAS ÁREAS DE CONOCIMIENTO (AC)
efectividad‖4.
do
La Figura 1 describe los 11 capítulos y los temas
Generalmente aceptado importantes de cada uno de ellos. Las 5 primeras áreas de
Prácticas utilizadas solamente en
son recomendadas por muchas la guía adopta o fomenta el ciclo de vida en cascada o
Especializado
LIMITACIONES RELACIONADAS CON EL FORMATO DEL La última parte de la descripción de las AC es una lista de
LIBRO referencias recomendadas. El apéndice A de cada AC
incluye sugerencias para los lectores que quieran
El formato en el cual este libro ha sido concebido tiene sus profundizar en un tema particular. Los apéndices B
limitaciones. La naturaleza de los contenidos podría presentan la lista de estándares más relevantes para cada
mostrarse mejor en formato de hipertexto, donde cada área de conocimiento. Nótese que las citas entre corchetes
tema podría ser unido a otros temas que no sean el anterior ―[…]‖ en el texto indican las referencias recomendadas,
y posterior a una lista. mientras que las que están en paréntesis ―(…)‖ identifican
las referencias usuales usadas al escribir o argumentar el
texto. Las primeras se encuentran en la sección
4
A Guide to the Project Management Body of correspondiente del AC y las ultimas en el Apéndice A de
Knowledge, 2000 ed., Project Management Institute, cada AC.
http://www.pmi.org/
La sexta subárea es la Validación de Requerimientos, cuyo
A continuación se resumen las áreas de conocimiento y objetivo, es descubrir problemas antes de asignar recursos
apéndices. a abordar los requerimientos. La validación de
requerimientos concierne proceso de examinar los
REQUERIMIENTOS DEL SOFTWARE (FIGURA 2, documentos de requerimientos y asegurarse de que definen
COLUMNA A) el sistema correcto, es decir, el sistema que los usuarios
esperan. Esta subdividido en las descripciones para llevar
Un requerimiento se define como una propiedad que debe a cabo revisiones de requerimientos, prototipos y
exhibir el software para resolver algún problema del validación y aceptación de pruebas.
mundo real.
La séptima subárea son las Consideraciones Practicas, la
La primera subárea de conocimiento es Fundamentos de cual describe los temas que necesitan ser entendidos en la
los Requerimientos del Software. Incluye las definiciones práctica. El primer tema es la naturaleza del proceso
de requerimientos del software y sus principales tipos: iterativo de los requerimientos. Los tres temas siguientes
producto vs. proceso, funcional vs. no funcional, son sobre la gestión del cambio, el mantenimiento de los
r
propiedades emergentes. La subárea además describe la requerimientos que reflejen el sistema a construir o ya
importancia de que los requerimientos cuantificables y construido. Incluye gestión de cambios, atributos de los
distingue entre sistemas y requerimientos software. requerimientos y trazas de los requerimientos. El último
do
tema es la medición de los requerimientos.
La segunda subárea de conocimiento son los
requerimientos del proceso, el cual introduce el proceso y DISEÑO DEL SOFTWARE (FIGURA 2, COLUMNA B)
orienta las 5 subáreas restantes y cómo la ingeniería de
requerimientos encaja en otras con otros procesos de la Según la definición de IEEE [IEEE 610.12-90], el diseño
ingeniería del software. Describe los modelos de proceso, es ―el proceso de definir la arquitectura, componentes,
actores del proceso, procesos de soporte y gestión, y la interfaces y otras características de un sistema o
calidad mejora del proceso. componente‖ y ―el resultado de [ese] proceso‖. El AC está
dividido en 6 subáreas.
La tercera subárea, es la Captura de requisitos, la cual se
centra en de dónde vienen los requerimientos y cómo el La primera subárea presenta los Fundamentos del Diseño
rra
ingeniero de software puede obtenerlos. Incluye las del Software, el cual forma la base para entender el rol y
fuentes de los requerimientos y las técnicas de captura. ámbito del diseño del software. Estos son conceptos
generales del software, el contexto del diseño del software,
La cuarta subárea, Análisis de requerimientos, se centra en el proceso del diseño del software, las técnicas que
los procesos de análisis de requerimientos para: permiten el diseño del software.
CONSTRUCCIÓN DEL SOFTWARE (FIGURA 2, COLUMNA MANTENIMIENTO DEL SOFTWARE (FIGURA 2, COLUMNA
C) E)
La construcción del software se refiere la creación de Una vez en producción, se descubren anomalías, los
software mediante una combinación de codificación, entornos de trabajo cambian y aparecen nuevos
verificación, pruebas unitarias, pruebas de integración, y requerimientos de trabajo. La fase del ciclo de vida
depuración. Está dividida en tres subáreas. mantenimiento comienza una vez entregado el sistema, sin
embargo, las actividades de mantenimiento ocurren mucho
La primera subárea son los Fundamentos de la antes. El AC de mantenimiento del software está dividido
Construcción del Software. Los tres primeros temas son en 4 subáreas.
los principios básicos de la construcción: minimización de
r
la complejidad, anticipación al cambio, y la construcción y La primera presenta los Fundamentos del Mantenimiento
verificación. del Software: definiciones y terminología, la naturaleza del
mantenimiento, la necesidad del mantenimiento, los
do
La segunda subárea describe la Gestión de la costes, la evolución del software, y las categorías de
Construcción. Los temas son la construcción de modelos, mantenimiento.
planificación de la construcción y la medición de la
construcción. La segunda subárea agrupa los Temas Clave del
Mantenimiento del Software. Estos comprenden temas
La tercera subárea cubre las Consideraciones Practicas. técnicos, de gestión, estimación del coste de
Los temas son el diseño de la construcción, lenguajes de mantenimiento y la medición del mantenimiento.
construcción, codificación, pruebas de construcción,
reutilización, calidad de construcción e integración. La tercera subárea describe el Proceso de Mantenimiento.
Los temas aquí presentados son el proceso de
PRUEBAS DEL SOFTWARE (FIGURA 2, COLUMNA D) mantenimiento y las actividades de mantenimiento.
rra
Las pruebas de software se componen de la verificación Las Técnicas para el Mantenimiento constituye la cuarta
dinámica del comportamiento de un programa con un subárea. Estas incluyen la compresión del software, la
conjunto finito de casos de pruebas, adecuadamente reingeniería y la ingeniería inversa.
seleccionados del un infinito número de posibles
ejecuciones del dominio. GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE
(FIGURA 3, COLUMNA F)
Comienza con una descripción de los Fundamentos de las
Pruebas del Software. Primero, se presenta la terminología La Gestión de la Configuración del Software (GCS) es la
relacionada con las pruebas, después se presentan los disciplina de la identificación del software en distintos
aspectos fundamentales de las pruebas, y finalmente, la puntos en el tiempo con el propósito de controlar los
Bo
relación de las pruebas con otras actividades. cambios sistemáticamente, y del mantenimiento de la
integridad y trazabilidad de la configuración durante todo
La segunda subárea son los Niveles de Pruebas. Estos el ciclo de vida. Esta AC incluye 6 subáreas.
están divididos entre el objeto de la prueba y los objetivos
de las pruebas. La primera subárea es la Gestión del proceso de la GCS.
Cubre los temas del contexto organizacional para la GSC,
La tercera subárea son las Técnicas para Pruebas. La restricciones y guías para la GCS, el plan de SGC, y el
primera categoría incluye las pruebas basadas en la control del GCS.
intuición del probador/a y experiencia. El segundo grupo
comprende las técnicas basadas en la especificación, La segunda subárea es la Identificación en la
seguido de las técnicas basadas en el código, y las técnicas Configuración del Software, la cual establece los ítems a
relativas a la naturaleza de la aplicación. También se ser controlados, establece la identificación de esquemas,
presenta cómo seleccionar y combinar las técnicas más para los ítems y sus versiones, y establece las herramientas
apropiadas. y técnicas usadas en la adquisición y gestión de los ítems
controlados. Los primeros temas en esta subárea son la
La cuarta subárea cubre las Medidas relacionadas con las identificación de los ítems a ser controlados y las
Pruebas. Las medidas se agrupan en aquellas relacionadas bibliotecas de software.
con la evaluación del programa que se está probando y la
evaluación de las pruebas realizadas. La tercera subárea es el Control de Configuración del
Software, trata la gestiona de cambios durante el ciclo de
vida del software. Las áreas son: primero, solicitud, PROCESO DE LA INGENIERÍA DEL SOFTWARE (FIGURA 2,
evaluación y aprobación de cambios; segundo, COLUMNA H)
implementación de cambios de software; tercero,
desviaciones y remisiones. El AC de proceso de la ingeniería del software se centra en
la definición, implementación, evaluación, gestión, cambio
La cuarta área es Registro del Estado de la Configuración. y mejora del proceso de ingeniería del software. Está
Sus temas son la información sobre el estado de la dividido en cuatro subáreas.
configuración e informes sobre el estado de la
configuración. La primera subárea presenta el Proceso de
Implementación y Cambios. Aquí los temas son
La quita área es Auditoria de Configuración Software. Se infraestructura del proceso, ciclo de gestión del proceso
compone de auditoría de la configuración funcional, software, modelos para el proceso de implementación y
auditoría de la configuración física y auditorías de una cambios y consideraciones practicas.
Línea Base de software.
La segunda subárea trata la Definición del Procesos
r
GESTIÓN DE LA INGENIERÍA DEL SOFTWARE (FIGURA 2, Incluye los modelos del ciclo de vida del software,
COLUMNA G) procesos del ciclo de vida del software, notaciones para la
definición de procesos, adaptación de procesos y
do
El AC de de la Gestión de la Ingeniería del Software trata automatización.
la gestión y medición de la ingeniería del software.
Mientras la medición es aspecto importante en todas las La tercera subárea es la Evolución del Proceso. Los temas
AC, es aquí donde se presenta el tema de programas de incluyen modelos de evaluación del proceso y los métodos
medición. Hay seis subáreas en la gestión de ingeniería del de evaluación del proceso.
software. Las 5 primeras cubren la gestión de proyectos
software y la última describe los programas de medición La cuarta subárea describe las Mediciones de Proceso y de
software. Producto. El proceso de ingeniería del software cubre
genéricamente la medición de producto y proceso.
La primera subárea es Iniciación y Definición del Alcance, Mediciones específicas a cada AC se describen en las
la cual comprende la determinación y negociación de los respectivas AC. Los temas son la medición del proceso, la
rra
requisitos, estudios de viabilidad, y consideración y medición de productos software, calidad de los resultados
revisión de requisitos. de las medición, modelos de información software y
técnicas de medición de procesos.
La segunda subárea es la Planificación de Proyectos
Software e incluye la planificación del proceso, HERRAMIENTAS Y MÉTODOS EN LA INGENIERÍA DEL
determinación de los entregables, esfuerzo, plazos y SOFTWARE (FIGURA 2, COLUMNA I)
estimación de costes, asignación de recursos, gestión de
riesgos, gestión de la calidad y gestión de planes. El AC de Herramientas y Métodos de la ingeniería del
software incluye ambas, herramientas de la ingeniería del
La tercera subárea es la Promulgación del Proyecto software y métodos de la ingeniería del software.
Software. Los temas son los planes de implementación,
Bo
gestión de contratos con proveedores, implementación de Las subárea de Herramientas de la Ingeniería del
procesos de medición, monitorización del proceso, control Software utiliza la misma estructura que la guía en sí
del proceso e informes. misma, con un tema por cada una de las otras nueve AC de
la ingeniería del software. Se añade un tema adicional:
La cuarta subárea es Revisión y Evolución, la cual incluye cuestiones varias sobre herramientas como técnicas de
los temas de determinación de la satisfacción de requisitos, integración de herramientas que son potencialmente
y revisión y evaluación de la ejecución. aplicables a todo tipo de herramientas.
La quita subárea describe el Cierre: determinación del La subárea de Métodos de Ingeniería del Software se
cierre y actividades del cierre. divide en cuatro subsecciones: métodos heurísticos que
tratan aproximaciones informales, métodos formales
Finalmente, la sexta subárea describe la Medición de la basados en aproximaciones matemáticas, métodos de
Ingeniería del Software, más concretamente, los prototipado tratando varias formas de prototipados.
programas de medición. Las mediciones de procesos y
productos se describen en el AC de los procesos de la CALIDAD DEL SOFTWARE (FIGURA 2, COLUMNA J)
Ingeniería del Software. Muchas de las otras AC también
describen mediciones específicas a sus AC. Los temas de El AC de la calidad del software se ocupa de las
esta subárea incluyen el establecimiento y mantenimiento consideraciones sobre la calidad del software las cuales
de la medición, realización del proceso de medición y transcienden los procesos del ciclo de vida del software.
evaluación de las mediciones. Al ser la calidad del software un tema ubicuo a toda la
ingeniería del software, también es considerada en
muchas otras AC, por lo que el lector notará referencias a APÉNDICE A. DESCRIPCIÓN DE LAS ESPECIFICACIONES
otras AC en toda esta AC. EN LAS AC
La primera subárea describe los Fundamentos de la El apéndice describe las especificaciones proporcionadas
Calidad del Software como la ética y cultura de la por el equipo editorial a los editores asociados para el
ingeniería del software, valor y coste de la calidad, contenido, referencias recomendadas, formato, y estilo de
modelos y características de la calidad y la mejora de la las descripciones de las AC.
calidad.
APÉNDICE B. EVOLUCIÓN DE LA GUÍA
La segunda subárea cubre los Procesos de Gestión de la
Calidad del Software. Aquí los temas son el El segundo apéndice describe la propuesta de la evolución
aseguramiento de la calidad, verificación y validación, y de la Guía. La Guía del 2004 es la edición actual, la cual
revisión y auditorias. continuara evolucionando para alcanzar las necesidades de
la comunidad de la ingeniería del software. La
r
La tercera y última subárea describe las consideraciones planificación de la evolución no está todavía completada,
prácticas relacionadas con la calidad del software. Los pero un esquema provisional se proporciona en el
temas son requerimientos de calidad del software, apéndice. En el momento de esta escritura, este proceso ha
do
caracterización de defectos, técnicas de gestión de la sido aprobado por el Comité Ejecutivo Profesional y
calidad del software, y medición de la calidad del comunicado a la junta de gobierno del IEEE Computer
software. Society; sin embargo no ha sido ni financiada ni
implementada.
DISCIPLINAS RELACIONADAS DE LA INGENIERÍA DEL
SOFTWARE (FIGURA 2, COLUMNA K) APÉNDICE C. ASIGNACIÓN DE ESTÁNDARES A AC
El último capítulo se titula Disciplinas relacionadas de la El tercer apéndice es una tabla comentada de los
Ingeniería del Software. Para circunscribir la ingeniería estándares más relevantes, principalmente de IEEE e ISO,
del software, es necesario identificar las disciplinas con las asignados a las AC de la Guía del SWEBOK.
que la ingeniería del software comparte una frontera
rra
común. Este capítulo identifica en orden alfabético, estas APÉNDICE D. ÍNDICES DE BLOOM
disciplinas relacionadas. Para cada disciplina relacionada,
y mediante consenso, se identifica: Como ayuda, principalmente a los creadores de planes de
estudio (y otros usuarios), para alcanzar el quito objetivo,
Una definición informativa (donde sea posible) el cuarto apéndice clasifica cada tema con una de las
Una lista de Áreas de Conocimiento categorías pedagógicas atribuidas a Benjamin Bloom. El
concepto es que los objetivos educacionales pueden ser
Las disciplinas relacionadas son clasificados en seis categorías incrementando la
profundidad: conocimiento, comprensión, aplicación,
Ingeniería de ordenadores Gestión de proyectos análisis, síntesis y evaluación. Los resultados de este
Informática Gestión de la Calidad ejercicio para todas las AC se encuentran en el Apéndice
Bo
Gestión Ergonomía D. Este apéndice no debe ser visto como una clasificación
Matemáticas Ingeniería de sistemas definitiva, sino como un punto de partida.
APÉNDICES
Guía del Cuerpo del Conocimiento de la Ingeniería del Software
Versión 2004
Fundamentos del
Fundamentos de diseño del Fundamentos Fundamentos de
Fundamentos
los requisitos del software de pruebas mantenimiento
de la
software software del software
Construcción
Cuestiones claves del Software
en diseño del Niveles de Problemas clave
Proceso de los
software prueba en mantenimiento
requisitos
Gestión de la de software
Construcción
r
Captura de los Estructura y
Técnicas de Proceso de
requisitos arquitectura del
pruebas mantenimiento
software
Consideraciones
Análisis y evaluación Prácticas
do
Análisis de
requisitos de la calidad del Medidas de Técnicas de
diseño del software las pruebas mantenimiento
Especificación de
requisitos Notaciones del Proceso de
diseño del software pruebas
Validación de los
Estrategias y
requisitos
métodos del diseño
de software
Consideraciones
prácticas
rra
Figura 2: Las 5 primeras áreas de conocimiento
Bo
Guía del Cuerpo del Conocimiento de la Ingeniería del Software
Versión 2004
r
software de Diseño SW Gestión
software Gestión de
Registro del Valoración del
Calidad del
estado de la Revisión y proceso Herramientas
de Software
configuración evaluación Construcción Matemáticas
do
Medidas de SW
Auditoría de productos y
configuración procesos Herramientas
software Cierre de Pruebas de
SW Gestión de
Gestión de Herramientas proyectos
Medidas de la
lanzamiento y de
ingeniería del Mantenimiento
entrega Gestión de
software de SW
Las calidad
Herramientas
de Dirección de
Configuración Software a
de SW
medida
Herramientas
de Dirección en
rra
la Ingeniería de
Software
Ingeniería
de sistemas
Las
Herramientas
de Proceso de
Ingeniería de
Software
Herramientas
de Calidad de
Software
Cuestiones de
Herramientas
Compuestas
Métodos de
Ingeniería del
Bo
software
Métodos
heurísticos
Métodos
formales
Métodos de
prototipado
r
de Diseño
UML Lenguaje de Modelado Unificado desarrollo de software.
do
con el Diseño del software, pruebas, mantenimiento del
El área del conocimiento de los requisitos del software software, gerencia de la configuración del software,
(KA) se refiere al análisis, a la especificación, y a la tecnología de dotación lógica, proceso de la tecnología de
validación de los requisitos del software. Está dotación lógica, y KAs de Calidad de software.
extensamente reconocido dentro de la industria del
software que los proyectos de la ingeniería de software son
críticamente vulnerables cuando estas actividades se INTERRUPCIÓN DE LOS ASUNTOS PARA LOS REQUISITOS
realizan mal. DEL SOFTWARE
Los requisitos del software expresan las necesidades y los 1. Fundamentos de los requisitos del software
apremios colocados en un producto de software que
rra
contribuye a la solución de un cierto problema del mundo 1.1. Definición de un requisito del software
real. [Kot00] El término ―ingeniería de requisitos‖ es
ampliamente utilizado en el campo para denotar la Básicamente, un requisito del software es una
dirección sistemática de requisitos. Aunque por razones característica que se debe exhibir para solucionar un cierto
de consistencia, este término no será utilizado en la guía, problema en el del mundo real. La guía se refiere a
pues se ha decidido que el uso del término ―ingeniería‖ requisitos de ―software‖ porque se refiere a los problemas
para las actividades con excepción de la tecnología de que se tratarán por el software. Por lo tanto, un requisito
dotación lógica debe ser evitado en esta edición de la guía. del software es una característica que se debe exhibir por
el software desarrollado o adaptado para solucionar un
Por la misma razón, tampoco se utilizará ―ingeniero de los problema particular. El problema puede ser automatizar la
requisitos,‖ un término que aparece en algo de la literatura. parte de una tarea de alguien que utilizará el software, para
En su lugar se utilizará el término ―Ingeniero de Software‖
Bo
r
resuelva todos los requisitos previos antes de que él o ella
se coloque para un curso.‖).
do
rra
Bo
1.3. Requisitos funcionales y no funcionales Pueden ser clasificados más a fondo según si son
Los requisitos funcionales describen las funciones que el requisitos de funcionamiento, requisitos de capacidad de
software va a ejecutar; por ejemplo, ajustarse a un mantenimiento, requisitos de seguridad, requisitos de
formato de texto o modular una señal. Se conocen confiabilidad, o uno de muchos otros tipos de requisitos
también como capacidades. del software. Estos asuntos también se discuten en KA
de la calidad del software. [Kot00; Som97]
Los requisitos no funcionales son los que actúan para
obligar la solución. Los requisitos no funcionales se
conocen a veces como apremios o requisitos de calidad.
1.4. Características inesperadas con el proceso de ingeniería del software. [Dav93;
Algunos requisitos representan características Som05]
inesperadas del software- esto es, los requisitos que no
pueden ser tratados por un solo componente, pero que su 2.1. Modelos de proceso
satisfacción va a depender de cómo todos los El objetivo de este asunto es proporcionar una
componentes de software ínter operan. El requisito del comprensión de que el proceso de los requisitos
rendimiento de procesamiento para un centro de
llamadas, por ejemplo, dependería de cómo el sistema de No es una actividad anticipada discreta del ciclo
teléfono, el sistema de información, y los operadores vital del software, sino un proceso iniciado en
obraron recíprocamente bajo condiciones de principio de un proyecto y a continuación refinado a
funcionamiento reales. Las características inesperadas través del ciclo vital
son crucialmente dependientes en la arquitectura del
sistema. [Som05] Identifica los requisitos del software como
elementos de configuración, y los maneja usando las
1.5. Requisitos cuantificables mismas prácticas de gerencia de la configuración del
r
Los requisitos del software se deben indicar tan clara e software como otros productos de los procesos del
inequívocamente como sea posible, y cuantitativamente. ciclo vital del software
Es importante evitar requisitos vagos e inverificables que
do
dependen para su interpretación del juicio subjetivo (―el Necesita ser adaptado a la organización y al
software será confiable‖; ―el software será de uso fácil‖). contexto del proyecto
Esto es particularmente importante para los requisitos no
funcionales. Dos ejemplos de requisitos cuantificados Particularmente, el asunto se refiere a cómo las
son los siguientes: el software para un centro de llamadas actividades de análisis, especificación, y la validación se
debe aumentar el rendimiento del procesamiento del configuran para diversos tipos de proyectos y apremios.
centro un 20%; y un sistema tendrá una probabilidad de El asunto también incluye las actividades que
generar un error fatal durante cualquier hora de proporcionan la entrada en el proceso de los requisitos,
operación menos de 1 * 10−8. El requisito de por ejemplo estudios de la comercialización y de
rendimiento de procesamiento está a un alto nivel y viabilidad. [Kot00; Rob99; Som97; Som05]
necesitará ser derivado en un número de requisitos
rra
detallados. El requisito de la confiabilidad determinará 2.2. Agentes de proceso
firmemente la arquitectura del sistema. [Dav93; Som05] Este asunto introduce los papeles de la gente que
participa en el proceso de los requisitos. Este proceso es
1.6. Requisitos del sistema y requisitos del software fundamental interdisciplinario, y el especialista de los
En este asunto, el sistema significa ―una combinación requisitos necesita mediar entre el dominio del tenedor
recíproca de los elementos para lograr un objetivo de apuestas y el de la tecnología de dotación lógica. Hay
definido. Éstos incluyen el hardware, software, soporte mucha gente implicada además del especialista de los
lógico inalterable, gente, información, técnicas, requisitos, cada uno de ellos tiene una función en el
instalaciones, servicios, y otros elementos de apoyo,‖ software. Los tenedores de apuestas variarán según los
según lo definido por el consejo internacional sobre la proyectos, pero incluyen siempre usuarios/operadores y
ingeniería de sistemas (INCOSE00). clientes (quiénes no necesitan ser iguales). [Gog93]
Bo
Los requisitos del sistema son los requisitos para el Los ejemplos típicos de los tenedores de apuestas del
sistema en su totalidad. En un sistema que contiene software incluyen (pero no restringen)
componentes de software, los requisitos del software se
derivan de los requisitos del sistema. Usuarios: Este grupo abarca a los que utilizan el
software. Es a menudo un grupo heterogéneo
La literatura sobre requisitos llama a veces a los que abarca a gente con diversos papeles y
requisitos del sistema ―exigencias del consumidor.‖ La requisitos.
guía define ―exigencias del consumidor‖ de una manera Clientes: Este grupo abarca a los que han
restricta como requisitos de los clientes o de los usuarios comisionado el software o quién representa el
finales del sistema. Los requisitos del sistema, por el blanco de mercado del software.
contrario, abarcan los requisitos del usuario, requisitos Analistas de mercado: Un producto del mass-
de otros tenedores de apuestas (por ejemplo autoridades market no tendrá un cliente que comisiona, de
reguladoras), y requisitos sin un origen identificable. modo que la gente de comercialización a
menudo necesita establecer lo que el mercado
necesita y actuar como clientes.
2. Proceso de los requisitos Reguladores: Muchos dominios de aplicación
Esta sección introduce el proceso de los requisitos del como por ejemplo el transporte público o la
software, orientando las cinco subzonas restantes y
banca son regulados. El software en estos
demostrando cómo el proceso de los requisitos encaja
dominios debe conformarse con los requisitos La captura de los requisitos se refiere a de donde vienen
de las autoridades reguladoras. los requisitos del software y cómo el ingeniero de
Ingenieros de software: Estos individuos tienen software puede recogerlos. Es la primera etapa en la
un interés legítimo en beneficiarse del construcción de una comprensión del problema que el
desarrollo del software, por ejemplo, software requiere solucionar. Es fundamental una
reutilizando componentes en otros productos. actividad humana, y es donde identifican a los
Si, en este escenario, un cliente de un producto stakeholders y las relaciones se establecen entre el
particular tiene requisitos específicos que equipo del desarrollo y el cliente. También se conoce
comprometen el potencial para la reutilización como ―descubrimiento de los requisitos,‖ y ―adquisición
de componentes, los ingenieros de software de los requisitos.‖
deben pesar cuidadosamente sus propios
intereses contra los del cliente. Uno de los aspectos fundamentales de la buena
ingeniería de software es que haya buena comunicación
No será posible satisfacer perfectamente los requisitos de entre los usuarios del software y los ingenieros. Antes de
cada stakeholder, y es el trabajo de los ingenieros de que comience el desarrollo, los especialistas de
r
software negociar las compensaciones que son requisitos pueden formar el conducto para esta
aceptables a los stakeholder principales y dentro de comunicación. Deben mediar entre el dominio de los
presupuestario, técnico, regulador, y otros apremios. Un usuarios del software (y otros stakeholders) y el mundo
do
requisito previo para esto es que identifiquen a todos los técnico del ingeniero de software.
stakeholder, la naturaleza de su ―interés‖ analizada, y sus
requisitos sacados. [Dav93; Kot00; Rob99; Som97;
You01]
Los requisitos tienen muchas fuentes en software típico, Una vez que se hayan identificado las fuentes de los
y es esencial que todas las fuentes potenciales estén requisitos, ingenieros de software pueden comenzar a
identificadas y evaluadas para su impacto en él. Este sacar requisitos de ellos. Este asunto se concentra en las
asunto se diseña para promover el conocimiento de las técnicas para conseguir que los stakeholders articulen sus
varias fuentes de los requisitos del software y de los requisitos. Es un área muy difícil e ingenieros de
armazones para manejarlos. Los puntos principales software necesitan sensibilizarse al hecho que (por
cubiertos son ejemplo) los usuarios pueden tener dificultad para
describir sus tareas, puede dejar la información
Metas: El término meta (a veces llamada importante sin especificar, o pueden estar poco
―preocupación de negocio‖ o ―factor crítico del dispuestos o cooperar. Es particularmente importante
éxito‖) se refiere a los objetivos totales, de alto entender que la captura no es una actividad pasiva, y
nivel del software. Las metas proporcionan la que, ingenieros de software tienen que trabajar
r
motivación para el software, pero a menudo son difícilmente para sacar la información adecuada. Existe
formuladas vagamente. Es necesidad que los un número de técnicas para hacer esto, las principales
ingenieros de software presten atención son [Gog93]
do
particular a determinar el valor (concerniente a
prioridad) y coste de metas. Un estudio de Entrevistas, medios ―tradicionales‖ de sacar
viabilidad es una manera relativamente barata requisitos. Es importante entender las ventajas y
de hacer esto. [Lou95]. limitaciones de las entrevistas y cómo deben
Conocimiento del dominio: Los ingenieros de ser conducidas.
software necesitan adquirir, o tener disponible, Escenarios, valiosos medios para proporcionar
conocimiento sobre el uso del dominio. Esto contexto a las exigencias del consumidor.
permite deducir el conocimiento que los Proporcionan un marco para preguntas sobre
stakeholders no articulan, determinar las tareas del usuario permitiendo preguntas ―y si‖
compensaciones que serán necesarias en y ―cómo se hace esto‖. El tipo más común de
requisitos que están en conflicto, y, a veces, escenario es el caso del uso.
rra
para actuar como campeón del ―usuario‖. Prototipos, una herramienta valiosa para
Stakeholders (véase a agentes de proceso del clarificar requisitos confusos. Pueden actuar de
asunto 2.2). Mucho software se ha probado una manera similar a los escenarios,
insatisfactorio porque había tensionado los proveyendo a los usuarios un contexto dentro
requisitos de un grupo de stakeholders a del cual pueden entender mejor qué información
expensas de los de otros. Por lo tanto, se necesitan proporcionar. Hay una amplia gama
entrega el software que es difícil de utilizar o de técnicas de prototipado, maquetas de
que derriba las estructuras culturales o políticas versiones de pruebas beta de los diseños de la
de la organización del cliente. Los ingenieros de pantalla del software, y un traslado fuerte de su
software necesitan identificar, representar, y uso para captura de los requisitos y el uso de
manejar ―puntos de vista‖ de muchos diversos prototipos para la validación de los requisitos
Bo
r
4. Análisis de requisitos alcance global puede afectar fuertemente a la
[Som05] arquitectura del software y el diseño de muchos
componentes, mientras que uno puede con un
do
Este asunto se refiere al proceso de analizar requisitos alcance estrecho ofrecer un número de opciones del
para diseño y no afectar demasiado a la satisfacción de
otros requisitos.
Detectar y resolver los conflictos entre los requisitos Volatilidad/estabilidad. Algunos requisitos
Descubrir los límites del software y cómo debe obrar cambiarán durante el ciclo de vida del software, y se
recíprocamente con su ambiente igualarán durante el proceso de desarrollo. Es útil
Elaborar los requisitos del sistema para derivar hacer estimaciones de la probabilidad de que se
requisitos software puedan hacer cambios. Por ejemplo, en actividades
bancarias, los requisitos para las funciones para
La vista tradicional del análisis de requisitos ha sido que calcular y para acreditar los intereses en las cuentas
son probablemente más estables que un requisito
rra
esté reducida a modelado conceptual utilizando uno de
varios métodos de análisis tales como Análisis para mantener un tipo particular de cuenta exenta de
Estructurados y Técnicas de Diseño (SADT). Mientras impuestos. Lo anterior refleja una característica
que el modelado conceptual es importante, nosotros fundamental del dominio de las actividades
incluimos la clasificación de requisitos para ayudar a bancarias (esas cuentas pueden ganar intereses),
informar a compensaciones entre los requisitos mientras que el último se puede dejar obsoleto por
(clasificación de los requisitos) y el proceso de un cambio de gobierno. Señalar requisitos
establecer estas compensaciones (negociación de los potencialmente volátiles puede ayudar al ingeniero
requisitos). [Dav93] del software a establecer un diseño que sea más
tolerante al cambio.
El cuidado se debe tomar para describir requisitos con
exactitud, suficientemente como para permitir que los Otras clasificaciones pueden ser apropiadas,
Bo
requisitos sean validados, su implementación sea dependiendo de la práctica normal y del uso que se le dé.
verificada, y sus costes estimados.
Hay un desfase fuerte entre la clasificación de los
4.1 Clasificación de los requisitos requisitos y las cualidades de los requisitos (véase las
[Dav93; Kot00; Som05] cualidades de los requisitos del punto 7.3).
Si el requisito es funcional o no funcional (véase el El desarrollo de modelos de un problema del mundo real
asunto 1.3 funcional y requisitos no funcionales). es clave para el análisis de requisitos del software. Su
Si el requisito está derivado de uno o más requisitos propósito es ayudar a entender el problema, más que
de alto nivel o una propiedad emergente (véase las iniciar el diseño de la solución. Por lo tanto, modelos
características inesperadas del asunto 1.4) o está conceptuales abarcan modelos de entidades del dominio
impuesto directamente ante el software por un del problema, configurados para reflejar sus relaciones y
tenedor de apuestas u otra fuente. dependencias con el mundo real.
Si el requisito está en el producto o proceso. Los
requisitos en el proceso pueden obligarnos a la Varias clases de modelos pueden ser desarrollados. Éstos
opción del contratista, a adaptar el proceso de la incluyen datos y controlan flujos, modelos de estado,
rastros de evento, interacciones de usuario, modelos de
objeto, modelos de datos y muchos otros. Los factores funcional; e IEEE Std 1320.2, IDEF1X97 (IDEFObject)
que influencian la opción del modelo incluyen para modelado de la información.
La naturaleza del problema. Algunos tipos de 4.3. Asignación arquitectónica del diseño y de los
software exigen que ciertos aspectos estén requisitos
analizados rigurosamente. Por ejemplo, controlar el [Dav93; Som05]
flujo y los modelos de estado son probablemente
más importantes para el software en tiempo real que En un cierto punto, la arquitectura de la solución debe
para el software de gerencia de información, ser derivada. El diseño arquitectónico es el punto en el
mientras que es generalmente lo contrario para los cual el proceso de los requisitos se junta con software o
modelos de datos. diseño de sistemas e ilustra cómo de imposible es
La maestría del ingeniero del software. Es a menudo desemparejar ambas tareas. [Som01] Este asunto está de
más productivo adoptar una notación que modele o cerca relacionado con el capítulo de la estructura y de la
método con el cual el ingeniero del software tiene arquitectura del software en KA del diseño del software.
una experiencia. En muchos casos, el ingeniero del software actúa como
r
Los requisitos de proceso del cliente. Los clientes arquitecto del software porque el proceso de analizar y
pueden imponer su notación o método favorecido, o de elaborar los requisitos exige que los componentes que
prohibir cualquiera que le sea desconocido. Este serán responsables de satisfacer los requisitos estén
do
factor puede estar en conflicto con el factor anterior. identificados. Esto es localización de requisitos-la
La disponibilidad de métodos y de herramientas. asignación, a los componentes, de la responsabilidad de
Notaciones o métodos que son mal apoyados por el satisfacer requisitos.
entrenamiento y las herramientas pueden no
alcanzar la aceptación esperada aunque se satisfagan La asignación es importante para permitir análisis
tipos particulares de problemas. detallado de requisitos. Por lo tanto, por ejemplo, una
vez un sistema de requisitos se han asignado a un
Observar que, en casi todos los casos, es útil comenzar componente, los requisitos individuales se pueden
construyendo un modelo del contexto del software. El analizar más a fondo para descubrir otros requisitos de
contexto del software proporciona una conexión entre el cómo el componente necesita obrar recíprocamente con
otros componentes para satisfacer los requisitos
rra
software previsto y su ambiente externo. Esto es crucial
para entender el contexto del software en su ambiente asignados. En proyectos grandes, la asignación estimula
operacional e identificar sus interfaces con el ambiente. un nuevo análisis para cada subsistema. Como ejemplo,
requisitos para el funcionamiento de los frenos de un
La aplicación de modelar se junta firmemente con la de coche (distancia que frena, seguridad en condiciones que
los métodos. Para los propósitos prácticos, un método es conducen, suavidad del uso, la presión del pedal
una notación (o sistema de notaciones) apoyado por un requerida, y así sucesivamente) se puede asignar un
proceso que dirige el uso de las notaciones. Hay escasa hardware que frena (montajes mecánicos e hidráulicos)
evidencia empírica para apoyar las demandas de y un sistema de frenos antibloqueo (ABS). Solamente
superioridad de una notación sobre otra. Sin embargo, la cuando un requisito para un sistema de frenos
extensa aceptación de un método o de una notación antibloqueo ha sido identificado, y los requisitos
particular puede conducir a nivel industrial al beneficio asignados a él, pueden usarse las capacidades del ABS,
Bo
r
esas razones contractuales que tales decisiones sean por ejemplo, separa a menudo la descripción de los
detectables de nuevo al cliente. Hemos clasificado esto requisitos del sistema de la descripción de los requisitos
como asunto del análisis de requisitos del software del software. En esto se especifica la visión, requisitos
do
porque los problemas emergen como resultado el del sistema, los requisitos software se derivan de los
análisis. Sin embargo, un caso fuerte se puede también requisitos del sistema, y entonces los requisitos para los
hacer para considerar los requisitos como asunto de la componentes de software se especifican. En sentido
validación. estricto, la especificación de requisitos del sistema es una
actividad de la ingeniería de sistemas y esta fuera del
5. Especificación de requisitos alcance de esta guía. IEEE Std 1233 es una guía para los
requisitos del sistema que se convierten. (IEEE1233-98)
Para la mayoría de las profesiones de la ingeniería, el
término ―especificación‖ se refiere a la asignación de 5.3. Especificación de requisitos del software
valores o límites numéricos para metas del diseño del [Kot00; Rob99]
producto. (Vin90) Los sistemas físicos típicos tienen un
rra
número relativamente pequeño de tales valores. La especificación de requisitos del software establece la
Típicamente el software tiene una gran cantidad de base para el acuerdo entre los clientes y los contratistas o
requisitos, y el énfasis se comparte entre la ejecución de los proveedores (en proyectos del mercado, estos papeles
la cuantificación numérica y el manejo de la complejidad se pueden desempeñar por las divisiones de
de la interacción entre el gran número de requisitos. Así comercialización y desarrollo) en los que hay que hacer
pues, en software el término, ―especificación de el producto de software, así como lo que no se espera
requisitos del software se refiere típicamente a la que haga. Para los lectores no técnicos, el documento de
producción de un documento, o a su equivalente la especificación de los requisitos es acompañado a
electrónico, que puede estar sistemáticamente repasado, menudo por un documento de la definición de los
evaluado, y aprobado. Para los sistemas complejos, requisitos del software.
particularmente ésos que implican componentes no-
Bo
software, se elaboran tres tipos de documentos: La especificación de requisitos del software permite un
definición de sistema, sistema requisitos, y requisitos riguroso gravamen de requisitos antes de que el diseño
del software. Para sistemas simples, solamente el tercero pueda comenzar y reducir un reajuste final. Debe
de éstos es requerido. Los tres documentos se describen también proporcionar una base realista para estimar
aquí, entendiendo que combinados pueden ser costes, riesgos, y horario del producto.
apropiados. Una descripción de la ingeniería de sistemas
se puede encontrar en el Capítulo 12, disciplinas Las organizaciones pueden también utilizar un
relacionadas de la tecnología de dotación lógica. documento de especificación de requisitos software para
desarrollar su propia validación y que la verificación sea
5.1. El documento de la definición de sistema más productiva.
Este documento (conocido a veces como documento de
exigencias del o concepto de operaciones) registra el La especificación de requisitos software proporciona una
sistema requisitos. Define los requisitos del sistema de base informada para transferir un producto de software a
alto nivel desde la perspectiva del dominio. Su número los nuevos usuarios o a las máquinas nuevas.
total de lectores incluye los representantes de los Finalmente, puede proporcionar una base para el realce
usuarios del sistema/de los clientes (la comercialización de software.
puede desempeñar estos papeles del mercado software),
así que su contenido debe estar en términos de dominio. Los requisitos del software se escriben a menudo en
El documento enumera los requisitos del sistema junto lenguaje natural, pero, en la especificación de requisitos
con información de fondo sobre los objetivos totales del software, ésta se puede suplir por formal o semi-
formal. La selección de notaciones apropiadas permite de que este define el software correctamente (es decir, el
requisitos y los aspectos particulares de la arquitectura software que los usuarios esperan). [Kot00]
del software que se describirá más ajustadamente que en
lengua natural. La regla general es que las notaciones 6.1 Revisiones de los requisitos
deben ser utilizadas para que permitan a los requisitos [Kot00; Som05; Tha97]
ser descritos tan exactamente como sea posible. Esto es
particularmente crucial para otros tipos seguridad-crítica Quizás los medios más comunes de la validación están
y casos de software confiable. Sin embargo, la opción de cerca de inspección o revisiones de los documentos de
la notación es obligada a menudo por el entrenamiento, los requisitos. Asignan un grupo de revisores en un
las habilidades y las preferencias de los autores y de los escrito para buscar errores, asunciones confundidas, la
lectores del documento. carencia de la claridad, y la desviación de la costumbre.
La composición del grupo que conduce la revisión es
Se han desarrollado un número de indicadores de la importante (por lo menos un representante del cliente
calidad para relacionar la calidad de la especificación de debe ser incluido para un proyecto cliente-conducido,
requisitos del software a otras variables del proyecto por por ejemplo), y puede ayudar a proporcionar la dirección
r
ejemplo coste, aceptación, funcionamiento, horario, en qué buscar bajo listas de comprobación.
reproducibilidad, indicadores de la calidad etc. para el
individuo las declaraciones de la especificación de Las revisiones se pueden constituir en el final del
do
requisitos del software incluyen imperativos, documento de definición del sistema, el documento de la
directorios, frases débiles, opciones, y continuaciones. especificación de sistema, el documento de la
Indicadores para el documento de especificación de especificación de requisitos del software, especificación
requisitos software incluye tamaño, legibilidad, de la línea de fondo para un nuevo lanzamiento, o en
especificación, profundidad, y estructura del texto. cualquier otro paso en el proceso. IEEE Std 1028
[Dav93; Tha97] (Ros98) proporciona la dirección para conducir tales revisiones.
(IEEE1028-97) Las revisiones son también cubiertas en
IEEE tiene un estándar, IEEE Std 830 [IEEE830-98], KA de la calidad del software, punto 2.3 Revisiones e
para producción y contenido de la especificación de los intervenciones.
requisitos del software. También, IEEE 1465 (similar a
ISO/IEC 12119) es un estándar que trata requisitos de 6.2. Prototipado
rra
calidad en paquetes de software. (IEEE1465-98) [Dav93; Kot00; Som05; Tha97]
documento de requisitos se conforma con la compañía de incorrectas. Por ejemplo, el comportamiento dinámico de
los estándares, y éste es comprensible, constante, y un interfaz utilizador se puede entender mejor a través de
finito. Las notaciones formales ofrecen la ventaja un prototipo animado que a través de la descripción
importante de permitir que las dos características pasadas textual o de modelos gráficos. Hay también desventajas,
sean probadas (en un sentido estricto, por lo menos). sin embargo. Éstos incluyen el peligro de la atención de
Diversos stakeholders, incluyendo los representantes del los usuarios que es distraída de la base de la
cliente y del revelador, deben también repasar los funcionalidad subyacente por las ediciones o los
documentos. Los documentos de los requisitos son problemas cosméticos de la calidad con el prototipo. Por
conformes a las mismas prácticas de gerencia de la esta razón, algunas personas dicen que los prototipos que
configuración del software como los otros puntos evitan. Los prototipos pueden ser costosos. Sin embargo,
relevantes de los procesos del ciclo de vida del software. si evitan el despilfarro de los recursos causados
(Bry94, Ros98) intentando satisfacer requisitos erróneos, su coste puede
ser más fácilmente justificado.
Es normal programar explícitamente unos o más puntos
en el proceso de los requisitos donde están los requisitos 6.3. Validación modelo
validados. La puntería es tomar cualquier problema antes [Dav93; Kot00; Tha97]
de que los recursos se destinen a tratar los requisitos. La
validación de los requisitos se refiere al proceso de Es típicamente necesario validar la calidad de los
examinar el documento de los requisitos para asegurarse modelos desarrollados durante el análisis. Por ejemplo,
en modelos de objeto, es útil para realizar un análisis
estático para verificar que las trayectorias de Hay presión general en la industria del software para
comunicación existen entre los objetos que, en dominio ciclos de desarrollo más cortos, y esto está
de los stakeholders, intercambian datos. Si las notaciones particularmente pronunciado en sectores del mercado
de especificación formal se utilizan, es posible utilizar el altamente competitivos. Por otra parte, la mayoría de los
razonamiento formal para probar características de la proyectos son obligados de cierta manera por su
especificación. ambiente, y muchas son mejoras, o revisiones, del
software existente donde está la arquitectura dada. En la
6.4. Pruebas de aceptación práctica, por lo tanto, es casi siempre impráctico poner el
[Dav93] proceso de los requisitos en ejecución como proceso
lineal, determinista en el cual los requisitos del software
Una característica esencial de un requisito del software se saquen de los stakeholders, asignado, y entregado al
es que debe ser posible validar que el producto final lo equipo de desarrollo del software. Es ciertamente un
satisface. Los requisitos que no pueden ser validados son mito que los requisitos para los proyectos grandes del
―deseos realmente justos.‖ Una tarea importante es por lo software siempre están entendidos perfectamente o
tanto planear cómo verificar cada requisito. En la especificados perfectamente. [Som97]
r
mayoría de los casos, el diseño de pruebas de aceptación
hace esto. Identificar y diseñar pruebas de aceptación En su lugar, los requisitos iteran típicamente hacia un
pueden ser difícil para los requisitos no funcionales nivel de calidad y detallan que es suficiente permitir las
do
(véase el asunto los requisitos funcionales y no decisiones del diseño y de la consecución que se harán.
funcionales de 1.3). Para ser validados, deben primero En algunos proyectos, esto puede dar lugar a requisitos
ser analizados al punto donde pueden ser expresados antes de que todas sus características se entiendan
cuantitativamente. completamente. Esto arriesga a una reanudación costosa
La información adicional se puede encontrar en el si los problemas emergen tarde en el proceso de la
software KA de prueba, conformidad de la prueba en el ingeniería del software. Sin embargo, los ingenieros del
punto 2.2.4. software son obligados necesariamente por planes de la
gerencia de proyecto y deben por lo tanto tomar medidas
para asegurarse de que la ―calidad‖ de los requisitos es
7. Consideraciones prácticas tan alta como sea posible dado los recursos disponibles.
El primer nivel de la descomposición de los puntos Deben, por ejemplo, hacer explícita cualquier asunción
rra
presentados en este KA puede parecer que describe una que sostengan los requisitos, así como cualesquiera
secuencia lineal de actividades. Ésta es una vista problemas sabidos.
simplificada del proceso.
[Dav93] En casi todos los casos, el entendimiento de los
requisitos continúa desarrollándose mientras que procede
Los requisitos procesan palmos de todo el ciclo de vida el diseño y el desarrollo. Esto conduce a menudo a la
del software. Cambiar la gerencia y el mantenimiento de revisión de requisitos tarde en el ciclo de vida. Quizás el
los requisitos en un estado que refleja exactamente el punto más crucial de entender la ingeniería de requisitos
software que se construirá, o se ha construido, es clave es que una proporción significativa de los requisitos
para el éxito del proceso ingeniería del software cambiará. Esto es a veces debido a los errores en el
[Kot00; Lou95] análisis, pero es con frecuencia una consecuencia
inevitable del cambio en el ―ambiente‖: por ejemplo, la
Bo
No toda organización tiene una cultura de funcionalidad del cliente o el ambiente del negocio, o el
documentación y manejo de requisitos. Es frecuente en mercado en el cual software se va a vender. Cualquiera
las compañías de start-up dinámicas, conducidas por una que sea la causa, es importante reconocer la
―visión fuerte del producto‖ y recursos limitados, para inevitabilidad del cambio para atenuar sus efectos. El
ver la documentación de los requisitos como gastos cambio tiene que ser manejado asegurando esos cambios
indirectos innecesarios. Más a menudo, sin embargo, propuestos mediante una revisión definida y un análisis
según estas compañías crecen, mientras que su base de del proceso de aprobación, y, aplicando los requisitos
cliente crece, y como su producto comienza a cuidadosos que remontan, del impacto, y la
desarrollarse, estas descubren que necesitan recuperar los configuración del software (véase la configuración del
requisitos que las características de producto motivadas software KA de la gerencia). Por lo tanto, el proceso de
para determinar el impacto de cambios propuestos. Por los requisitos no es simplemente una tarea anticipada en
lo tanto, la documentación de los requisitos y la gerencia el desarrollo del software, pero atraviesa por completo
del cambio son llave al éxito de cualquier proceso de los el ciclo de vida del software. En un proyecto típico, las
requisitos. actividades de los requisitos del software se desarrollan
en un cierto.
7.1. Naturaleza iterativa del proceso de los
requisitos 7.2. Cambiar a gestión
[Kot00; You01] [Kot00]
La gestión del cambio es central en el análisis de requisitos y los stakeholders que lo motivaron (de un
requisitos. Este asunto describe el papel de la gestión del requisito del software de nuevo a los requisitos del
cambio, los procedimientos que necesitan estar sistema que ayudan a satisfacer, por ejemplo).
preparados, y el análisis que se debe aplicar a los Inversamente, un requisito debe ser detectable entidades
cambios propuestos. Tiene acoplamientos fuertes a la del diseño que lo satisfacen (por ejemplo, de un requisito
configuración del software KA de la gestión. del sistema en el software requisitos que se han
elaborado a partir de él, y encendido en los módulos del
7.3. Cualidades de los requisitos código que lo ponen en ejecución).
[Kot00]
Los requisitos que remontan para un proyecto típico
Los requisitos deben consistir no sólo una especificación formarán un gráfico acíclico dirigido complejo (DAG)
de qué se requiere, sino también de la información de requisitos.
ancilar que las ayudas manejan e interpretan los
requisitos. Esto debe incluir varias dimensiones de la 7.5 Requisitos que miden
clasificación del requisito (véase la clasificación de los Como cuestión práctica, es típicamente útil tener cierto
r
requisitos del asunto 4.1) y el método de la verificación o concepto del ―volumen‖ de los requisitos para un
el plan de prueba de aceptación. Puede también incluir la producto de software particular. Este punto es útil
información adicional tal como un resumen-análisis evaluando el ―tamaño‖ de un cambio en requisitos, en
do
razonado para cada requisito, la fuente de cada requisito, estimar el coste de una tarea del desarrollo o del
y una historia del cambio. Los requisitos más mantenimiento, o simplemente para el uso como el
importantes atribuyen, sin embargo, un identificador que denominador en otra medida. La medida funcional del
permite requisitos identificados inequívocamente. tamaño (FSM) es una técnica para evaluar el tamaño de
un cuerpo de requisitos funcionales. IEEE Std 14143.1
7.4 El remontar de los requisitos define el concepto de FSM. [IEEE14143.1-00]
[Kot00] Estándares de ISO/IEC y otras fuentes describen
métodos particulares del FSM.
El remontar de los requisitos se refiere a la fuente
recuperación de requisitos y de predecir los efectos de Información adicional sobre la medida del tamaño y los
esos requisitos. El trazado es fundamental para el análisis estándares se encuentran en el proceso de la ingeniería
rra
de la ejecución del impacto cuando los requisitos del software.
cambian. Un requisito debe ser detectable al revés a
Bo
Bo
rra
do
r
REFERENCIAS RECOMENDADAS PARA REQUSITOS SW
r
Sons, 2000.
[Lou95] P. Loucopulos and V. Karakostas, Systems
Requirements Engineering, McGraw-Hill, 1995. [Pfl01]
do
S.L. Pfleeger, ―Software Engineering: Theory and
Practice,‖ second ed., Prentice Hall, 2001, Chap. 4.
[Rob99] S. Robertson and J. Robertson, Mastering the
Requirements Process, Addison-Wesley, 1999.
[Som97] I. Sommerville and P. Sawyer, Requirements
Engineering: A Good Practice Guide, John Wiley & Sons,
1997, Chap. 1-2.
[Som05] I. Sommerville, Software Engineering, seventhed.,
Addison-Wesley, 2005.
[Tha97] R.H. Thayer and M. Dorfman, eds., Software
Requirements Engineering, IEEE Computer Society Press,
rra
1997, pp. 176-205, 389-404.
[You01] R.R. You, Effective Requirements Practices,
Addison-Wesley, 2001.
Bo
APÉNDICE A. LISTA DE LECTURAS COMPLEMENTARIAS (Def94) J. DeFoe, ―Requirements Engineering Technology
in Industrial Education,‖ presented at IEEE International
(Ale02) I. Alexander and R. Stevens, Writing Better Conference on Requirements Engineering,1994.
Requirements, Addison-Wesley, 2002. (Dem97) E. Demirors, ―A Blackboard Framework for
(Ard97) M. Ardis, ―Formal Methods for Supporting Teams in Software Development,‖ presented at
Telecommunication System Requirements: A Survey of Ninth IEEE International Conference on Software
Standardized Languages,‖ Annals of Software Engineering, Engineering and Knowledge Engineering, Knowledge
vol. 3, 1997. Systems Institute, 1997.
(Ber97) V. Berzins et al., ―A Requirements Evolution (Die95) M. Diepstraten, ―Command and Control System
Model for Computer Aided Prototyping,‖ presented at Requirements Analysis and System Requirements
Ninth IEEE International Conference on Software Specification for a Tactical System,‖ presented at First
Engineering and Knowledge Engineering, Knowledge IEEE International Conference on Engineering of complex
Systems Institute, 1997. Computer Systems, 1995.
(Bey95) H. Beyer and K. Holtzblatt, ―Apprenticing with the (Dob94) J. Dobson and R. Strens, ―Organizational
Customer,‖ Communications of the ACM, vol. 38, iss. 5, Requirements Definition for Information Technology,‖
May 1995, pp. 45-52. presented at IEEE International Conference on
r
(Bru95) G. Bruno and R. Agarwal, ―Validating Software Requirements Engineering, 1994.
Requirements Using Operational Models,‖ presented at (Duf95) D. Duffy et al., ―A Framework for Requirements
Second Symposium on Software Quality Techniques and Analysis Using Automated Reasoning,‖ presented at
do
Acquisition Criteria, 1995. Seventh International Conference on Advanced Information
(Bry94) E. Bryne, ―IEEE Standard 830: Recommended Systems Engineering, 1995.
Practice for Software Requirements Specification,‖ (Eas95) S. Easterbrook and B. Nuseibeh, ―Managing
presented at IEEE International Conference on Inconsistencies in an Evolving Specification,‖ presented at
Requirements Engineering, 1994. Second International Symposium on Requirements
(Buc94) G. Bucci et al., ―An Object-Oriented Dual Engineering, 1995.
Language for Specifying Reactive Systems,‖ presented at (Edw95) M. Edwards et al., ―RECAP: A Requirements
IEEE International Conference on Requirements Elicitation, Capture, and Analysis Process Prototype Tool
Engineering, 1994. for Large Complex Systems,‖ presented at First IEEE
(Bus95) D. Bustard and P. Lundy, ―Enhancing Soft Systems International Conference on Engineering of Complex
Analysis with Formal Modeling,‖ presented at Second Computer Systems, 1995.
rra
International Symposium on Requirements Engineering, (ElE95) K. El-Emam and N. Madhavji, ―Requirements
1995. Engineering Practices in Information Systems
(Che94) M. Chechik and J. Gannon, ―Automated Development: A Multiple Case Study,‖ presented at Second
Verification of Requirements Implementation,‖ presented at International Symposium on Requirements Engineering,
Proceedings of the International Symposium on Software 1995.
Testing and Analysis, special issue, 1994. (Fai97) R. Fairley and R. Thayer, ―The Concept of
(Chu95) L. Chung and B. Nixon, ―Dealing with Non- Operations: The Bridge from Operational Requirements to
Functional Requirements: Three Experimental Studies of a Technical Specifications,‖ Annals of Software Engineering,
Process-Oriented Approach,‖ presented at Seventeenth vol. 3, 1997.
IEEE International Conference on Software Engineering, (Fic95) S. Fickas and M. Feather, ―Requirements
1995. Monitoring in Dynamic Environments,‖ presented at
(Cia97) P. Ciancarini et al., ―Engineering Formal Second International Symposium on Requirements
Bo
r
Indirect Knowledge Elicitation Techniques: Comparison of Analysis Using Forward and Backward Search,‖ Annals of
Three Methods,‖ presented at Second IEEE International Software Engineering, vol. 3, 1997.
Conference on Requirements Engineering, 1996. (Mac96) L. Macaulay, Requirements Engineering,
do
(Hug94) K. Hughes et al., ―A Taxonomy for Requirements Springer-Verlag, 1996.
Analysis Techniques,‖ presented at IEEE International (Mai95) N. Maiden et al., ―Computational Mechanisms for
Conference on Requirements Engineering, 1994. Distributed Requirements Engineering,‖ presented at
(Hug95) J. Hughes et al., ―Presenting Ethnography in the Seventh International Conference on Software Engineering
Requirements Process,‖ presented at Second IEEE and Knowledge Engineering, Knowledge Systems Institute,
International Symposium on Requirements Engineering, 1995.
1995. (Mar94) B. Mar, ―Requirements for Development of
(Hut94) A.T.F. Hutt, ed., Object Analysis and Design - Software Requirements,‖ presented at Fourth International
Comparison of Methods. Object Analysis and Design - Symposium on Systems Engineering, 1994.
Description of Methods, John Wiley & Sons, (Mas97) P. Massonet and A. v. Lamsweerde, ―Analogical
1994.(INCOSE00) INCOSE, How To: Guide for all Reuse of Requirements Frameworks,‖ presented at IEEE
rra
Engineers, Version 2, International Council on Systems International Symposium on Requirements Engineering,
Engineering, 2000. 1997.
(Jac95) M. Jackson, Software Requirements and (McF95) I. McFarland and I. Reilly, ―Requirements
Specifications, Addison-Wesley, 1995. Traceability in an Integrated Development Environment,‖
(Jac97) M. Jackson, ―The Meaning of Requirements,‖ presented at Second International Symposium on
Annals of Software Engineering, vol. 3, 1997. Requirements Engineering, 1995.
(Jon96) S. Jones and C. Britton, ―Early Elicitation and (Mea94) N. Mead, ―The Role of Software Architecture in
Definition of Requirements for an Interactive Multimedia Requirements Engineering,‖ presented at IEEE
Information System,‖ presented at Second IEEE International Conference on Requirements Engineering,
International Conference on Requirements Engineering, 1994.
1996. (Mos95) D. Mostert and S. v. Solms, ―A Technique to
(Kir96) T. Kirner and A. Davis, ―Nonfunctional Include Computer Security, Safety, and Resilience
Requirements for Real-Time Systems,‖ Advances in Requirements as Part of the Requirements Specification,‖
Bo
Computers, 1996. Journal of Systems and Software, vol. 31, iss. 1, October
(Kle97) M. Klein, ―Handling Exceptions in Collaborative 1995, pp. 45-53.
Requirements Acquisition,‖ presented at IEEE International (Myl95) J. Mylopoulos et al., ―Multiple Viewpoints
Symposium on Requirements Engineering, Analysis of Software Specification Process,‖ IEEE
1997. Transactions on Software Engineering, 1995.
(Kos97) R. Kosman, ―A Two-Step Methodology to Reduce (Nis92) K. Nishimura and S. Honiden, ―Representing and
Requirements Defects,‖ Annals of Software Engineering, Using Non-Functional Requirements: A Process-Oriented
vol. 3, 1997. Approach,‖ IEEE Transactions on Software Engineering,
(Kro95) J. Krogstie et al., ―Towards a Deeper December 1992.
Understanding of Quality in Requirements Engineering,‖ (Nis97) H. Nissen et al., ―View-Directed Requirements
presented at Seventh International Conference on Advanced Engineering: A Framework and Metamodel,‖ presented at
Information Systems Engineering (CAiSE ‘95), 1995. Ninth IEEE International Conference on Software
(Lal95) V. Lalioti and B. Theodoulidis, ―Visual Scenarios Engineering and Knowledge Engineering, Knowledge
for Validation of Requirements Specification,‖ presented at Systems Institute, 1997.
Seventh International Conference on Software Engineering (OBr96) L. O‘Brien, ―From Use Case to Database:
and Knowledge Engineering, Knowledge Systems Institute, Implementing a Requirements Tracking System,‖ Software
1995. Development, vol. 4, iss. 2, February 1996, pp. 43-47.
(Lam95) A. v. Lamsweerde et al., ―Goal-Directed (UML04) Object Management Group, Unified Modeling
Elaboration of Requirements for a Meeting Scheduler: Language, www.uml.org, 2004. (Opd94) A. Opdahl,
Problems and Lessons Learnt,‖ presented at Second ―Requirements Engineering for Software Performance,‖
presented at International Workshop on Requirements (Span97) G. Spanoudakis and A. Finkelstein, ―Reconciling
Engineering: Foundations of Software Quality, 1994. Requirements: A Method for Managing Interference,
(Pin96) F. Pinheiro and J. Goguen, ―An Object-Oriented Inconsistency, and Conflict,‖ Annals of Software
Tool for Tracing Requirements,‖ IEEE Software, vol. 13, Engineering, vol. 3, 1997.
iss. 2, March 1996, pp. 52-64. (Ste94) R. Stevens, ―Structured Requirements,‖ presented at
(Pla96) G. Playle and C. Schroeder, ―Software Fourth International Symposium on Systems Engineering,
Requirements Elicitation: Problems, Tools, and 1994.
Techniques,‖ Crosstalk: The Journal of Defense Software (Vin90) W.G. Vincenti, What Engineers Know and How
Engineering, vol. 9, iss. 12, December 1996, pp. 19-24. They Know It - Analytical Studies form Aeronautical
(Poh94) K. Pohl et al., ―Applying AI Techniques to History, John Hopkins University Press, 1990.
Requirements Engineering: The NATURE Prototype,‖ (Wei03) K. Weigers, Software Requirements, second ed.,
presented at IEEE Workshop on Research Issues in the Microsoft Press, 2003.
Intersection Between Software Engineering and Artificial (Whi95) S. White and M. Edwards, ―A Requirements
Intelligence, 1994. Taxonomy for Specifying Complex Systems,‖ presented at
(Por95) A. Porter et al., ―Comparing Detection Methods for First IEEE International Conference on Engineering of
Software Requirements Inspections: A Replicated Complex Computer Systems, 1995.
r
Experiment,‖ IEEE Transactions on Software Engineering, (Wil99) B. Wiley, Essential System Requirements: A
vol. 21, iss. 6, June 1995, pp. 563-575. Practical Guide to Event-Driven Methods, Addison-
(Pot95) C. Potts et al., ―An Evaluation of Inquiry-Based Wesley, 1999.
do
Requirements Analysis for an Internet Server,‖ presented at (Wyd96) T. Wyder, ―Capturing Requirements With Use
Second International Symposium on Requirements Cases,‖ Software Development, vol. 4, iss. 2, February
Engineering, 1995. 1996, pp. 36-40.
(Pot97) C. Potts and I. Hsi, ―Abstraction and Context in (Yen97) J. Yen and W. Tiao, ―A Systematic Tradeoff
Requirements Engineering: Toward a Synthesis,‖ Annals of Analysis for Conflicting Imprecise Requirements,‖
Software Engineering, vol. 3, 1997. presented at IEEE International Symposium on
(Pot97a) C. Potts and W. Newstetter, ―Naturalistic Inquiry Requirements Engineering, 1997.
and Requirements Engineering: Reconciling Their (Yu97) E. Yu, ―Towards Modeling and Reasoning Support
Theoretical Foundations,‖ presented at IEEE International for Early-Phase Requirements Engineering,‖ presented at
Symposium on Requirements Engineering, 1997. IEEE International Symposium on Requirements
(Ram95) B. Ramesh et al., ―Implementing Requirements Engineering, 1997.
rra
Traceability: A Case Study,‖ presented at Second (Zav96) P. Zave and M. Jackson, ―Where Do Operations
International Symposium on Requirements Engineering, Come From? A Multiparadigm Specification Technique,‖
1995. IEEE Transactions on Software Engineering,, vol. 22, iss.
(Reg95) B. Regnell et al., ―Improving the Use Case Driven 7, July 1996, pp. 508-528.
Approach to Requirements Engineering,‖ presented at
Second IEEE International Symposium on Requirements
Engineering, 1995.
(Reu94) H. Reubenstein, ―The Role of Software
Architecture in Software Requirements Engineering,‖
presented at IEEE International Conference on
Requirements Engineering, 1994.
(Rob94) J. Robertson and S. Robertson, Complete Systems
Bo
r
Information Technology-System Definition-Concept of Definitions of Concepts, IEEE, 2000.
Operations (ConOps) Document, IEEE, 1998.
do
rra
Bo
Bo
rra
do
r
CAPÍTULO 3
DISEÑO DE SOFTWARE
r
PDL Pseudo-código y lenguaje de Diseño de Programa componentes). Sin embargo, debido a su importancia en
CBD Diseño Basado en Componentes el campo cada vez mayor de la arquitectura del software,
también trataremos el diseño desde el punto de
do
INTRODUCCIÓN congelación (el diseño del patrón de familia, cual meta
El diseño se define en [IEEE610.12-90] como ―el es establecer concordancias explotables en una familia
proceso para definir la arquitectura, los componentes, los del software). Por el contrario, el KA del diseño del
interfaces, y otras características de un sistema o un software no trata el I-Diseño (el diseño de la Innovación,
componente‖ y ―el resultado de este proceso.‖ Visto realizado generalmente durante el proceso de los
como proceso, el diseño del software es la actividad del requisitos del software con el objetivo de conceptuar y
ciclo de vida de la cual los requisitos del software se de especificar el software para satisfacer las necesidades
analizan para producir una descripción de la estructura y los requisitos), puesto que este asunto se debe
interna del software que servirá como la base para su considerar parte del análisis y la especificación de
construcción. requisitos la descripción de KA del diseño del software
Más exacto, un diseño del software (el resultado) debe se relaciona específicamente con los requisitos del
rra
describir la arquitectura del software, en cómo la software, la construcción del software, la gerencia de la
descomposición del software, la organización de los ingeniería del software, la calidad del software, y las
componentes, y los interfaces entre los mismos disciplinas relacionadas con la ingeniería del software
componentes. Debe también describir los componentes
en un nivel de detalle que permita su construcción. INTERRUPCIÓN DE LOS ASUNTOS PARA EL DISEÑO DEL
El diseño del software desempeña un papel importante SOFTWARE
en el desarrollo de software: permite que la Ingeniería 1. Fundamentos del diseño del software
del software produzca los diversos modelos para la
solución que se pondrá en desarrollo. Podemos analizar Los conceptos, las nociones, y la terminología
y evaluar estos modelos para determinar si o no introducida aquí forman una base subyacente para
permitirán que se satisfaga los requisitos. entender el papel y el alcance del diseño del software.
Bo
r
1.3.2. Diseño detallado relaciones entre los módulos, mientras que la
El diseño detallado describe el comportamiento cohesión es definida por cómo los elementos
específico de estos componentes. que componen un módulo son relacionados.
do
La salida de este proceso es un sistema de modelos y los [Bas98: c6; Jal97: c5; Pfl01: c5; Pre04: c9]
artefactos que registran las decisiones principales que se 1.4.3. Descomposición y modularización
han tomado. [Bud04: c2; IEE1016-98; Lis01: c13;
Pre04: c9] Descomposición y modularización del software
en partes más pequeñas e independientes,
1.4. Permitir técnicas generalmente con la meta de poner diversas
funcionalidades o responsabilidades en diversos
Según el diccionario del inglés de Oxford, un principio componentes. [Bas98: c6; Bus96: c6; Jal97: c5;
es ―una verdad básica o una ley general… que se utiliza Pfl01: c5; Pre04: c9]
como una base del razonamiento o guía de la acción.‖
Los principios del diseño del software, también llamados 1.4.4. Encapsulación/el ocultar de la
rra
técnicas permisibles [Bus96], son nociones dominantes información
que consideran fundamental a los diversos Medios que ocultan de la encapsulación/de la
acercamientos y conceptos del diseño del software. Las información que agrupan y que empaquetan los
técnicas que lo permiten son las siguientes: [Bas98: c6; elementos y los detalles internos de una
Bus96: c6; IEEE1016-98; Jal97: c5, c6; Lis01: c1, c3; abstracción y que hacen esos detalles
Pfl01: c5; Pre04: c9] inaccesibles. [Bas98: c6; Bus96: c6; Jal97: c5;
Pfl01: c5; Pre04: c9]
Bo
r
[Bus96: c6; Lis01: c5].
Cómo estructurar y organizar las interacciones con los
usuarios y la presentación de la información (por
2. Cuestiones claves en diseño del software
ejemplo, separación de la presentación y de la lógica del
do
Se tiene que tener en cuenta a la hora de diseñar negocio usando el acercamiento del Modelo-Vista-
software una serie de principios claves. Algunos son Regulador). [Bas98: c6; Bos00: c5; Bus96: c2; Lis01:
preocupaciones que todo el software debe tratar -por c13; Mey97: c32] Debe ser observado que este asunto
ejemplo, funcionamiento de la calidad. Otra edición no está sobre especificar los detalles del interfaz
importante es cómo se descomponer, se organiza, y utilizador, que es la tarea del diseño del interfaz
constituyen los paquetes de software. Esto es tan utilizador (una parte de ergonómica del software); ver
fundamental que todos los acercamientos del diseño las disciplinas relacionadas de la tecnología de dotación
deben tratarlo de un modo u otro (véase las técnicas del lógica.
asunto 1.4 y la subárea 6, los métodos que permiten el
diseño del software). En cambio, otras ediciones ―se 2.1. Persistencia de los datos
ocupan de un cierto aspecto del comportamiento del
rra
Cómo los datos duraderos deben ser dirigidos. [Bos00:
software que no está en el dominio del uso, pero que
trata algunos de los dominios de soporte.‖ *Bos00+ c5; Mey97: c31];
Tales ediciones, que interseccionaron a menudo la
funcionalidad del sistema, se han referido como 3. Estructura y arquitectura del software
aspectos: ―*aspectos+ tender para no ser unidades de la En su sentido terminante, una arquitectura del software
descomposición funcional del software, sino algo para es ―una descripción de los subsistemas y de los
ser las características que afectan el funcionamiento o la componentes de un sistema de software y de las
semántica de los componentes de manera sistemáticas‖ relaciones entre ellas.‖ (Bus96: c6) La arquitectura
(Kic97). Un número de estas claves, ediciones de la procura así definir la estructura interna - según el
cruz-corte son los siguientes (presentado en orden diccionario del inglés de Oxford, ―la manera de la cual
alfabético): se construye o se organiza algo‖ - del software que
Bo
r
puesta en práctica). Otros autores utilizan diversas reutilizables y adaptables entre miembros de la familia.
terminologías, como del comportamiento contra [Bos00: c7, c10; Bas98: c15; Pre04: c30] En
funcional contra estructural contra los datos que programación orientada a objetos, una clave relacionada
modelan opiniones. Resumiendo, un diseño del software
do
es la del marco: un subsistema parcialmente completo
es un artefacto múltiple producido por el proceso del del software que puede ser ampliado apropiadamente
diseño e integrado generalmente por visiones instalando los plug-ins específicos (también conocidos
relativamente independientes y ortogonal. [Bas03: c2; como puntos calientes). [Bos00: c11; Boo99: c28;
Boo99: c31; Bud04: c5; Bus96: c6; IEEE1016-98; Bus96: c6]
IEEE1471-00] Estilos arquitectónicos (patrones
arquitectónicos macro) 4. Análisis y evaluación de la calidad del diseño del
Un estilo arquitectónico es ―un sistema de apremios en software
una arquitectura *que+ define un sistema o una familia
de arquitecturas que las satisfagan‖ *Bas03: c2+. Un Esta sección incluye generalidades de la calidad y
estilo arquitectónico se puede considerar así mientras evaluación que se relacionen específicamente con el
rra
que un meta-modelo que pueda proporcionar la diseño del software. La mayoría se cubren de una
organización de alto nivel del software (su arquitectura manera general en Software Quality KA
macro). Los varios autores han identificado un número
de estilos arquitectónicos importantes. [Bas03: c5; 4.1. Cualidades de los atributos
Boo99: c28; Bos00: c6; Bus96: c1, c6; Pfl01: c5] Varias atributos son generalmente importantes para
obtener un diseño del software de buenos calidad -
Estructura general (por ejemplo, capas, pipas, y varios ―ilities‖ (capacidad de mantenimiento,
filtros, pizarra) portabilidad, testeo, trazabilidad), los varios ―nesses‖
Sistemas distribuidos (por ejemplo, servidor de (corrección, robustez), incluyendo la ―aptitud del
cliente, tres gradas, corredor) propósito.‖ *Bos00: c5; Bud04: c4; Bus96: c6;
Sistemas interactivos (por ejemplo, regulador de la ISO9126.1-01; ISO15026-98; Mar de 94: D; Mey97:
Modelo-Vista, Presentación-Abstracción-Control) c3; Pfl01: c5] Una distinción interesante es la que está
Bo
Sistemas adaptables (por ejemplo, micro-núcleo, entre las cualidades de la calidad discernible en el
reflexión) tiempo de ejecución (funcionamiento, seguridad,
Oros (por ejemplo, hornada, intérpretes, control, disponibilidad, funcionalidad, utilidad), ésas no
basados en las reglas de proceso). discernibles en el tiempo de ejecución (modificabilidad,
portabilidad, reutilidad, integridad, y testeabilidad), y
3.2. Patrones del diseño (patrones arquitectónicos ésas relacionadas con las calidades intrínsecas de la
micro). arquitectura (integridad, corrección, y lo completo,
capacidad conceptuales de la estructura). [Bas03: c4]
Resumido brevemente, un patrón es ―una solución
común a un problema común en un contexto dado.‖ 4.2 Técnicas de evaluación y calidad del análisis.
(Jac99) Mientras que los estilos arquitectónicos se
pueden ver como patrones que describen la Varias técnicas pueden ayudar a asegurar la calidad de
organización de un nivel alto del software (su un diseño del software:
arquitectura macro); otros patrones del diseño se pueden Revisiones de diseño del software: informal o
utilizar para describir los detalles en un nivel más bajo, semiformal, a menudo basado en grupo, las
más local (su arquitectura micro). [Bas98: c13; Boo99: técnicas para verificar y para asegurar la calidad de
c28; Bus96: c1; 2 Mar: DP] los artefactos del diseño (por ejemplo, revisiones de
Patrones de creación (por ejemplo, builder, factory, la arquitectura [Bas03: c11], revisiones de diseño, e
prototipo, y singleton) inspecciones [Bud04: c4; Fre83: VIII; IEEE1028-
97; Jal97: c5, c7; Lis01: c14; Pfl01: c5], técnicas
basadas en panorama [Bas98: c9; Bos00: c5], y la Lenguajes descriptivos de la arquitectura:
toma de los requisitos [Dor02: v1c4s2; Pfl01: ]) textuales, a menudo formal, los lenguajes
Análisis estático: análisis estático formal o describían una arquitectura del software en
semiformal (ningún ejecutable) que se puede términos de componentes y conectadores
utilizar para evaluar un diseño (por ejemplo, el [Bas03: c12]
análisis o el cross-checking automatizado) Diagramas de la clase y objeto: usados para
[Jal97 del fault-tree: c5; Pfl01: ] representar un sistema de clases (y de objetos)
Simulación y prototipado: técnicas dinámicas y de sus correlaciones [Boo99: c8, c14; Jal97: ]
para evaluar un diseño (por ejemplo, Diagramas de componentes: usados para
simulación o prototipo de la viabilidad [Bas98 representar un sistema de componentes (―parte
del funcionamiento: c10; Bos00: c5; Bud04: física y reemplazable de un sistema al cual
c4; Pfl01: c5]) conforma y proporciona la realización de un
sistema de interfaces‖ *Boo99+) y de sus
4.3 Medidas. correlaciones *Boo99: +
Tarjetas del colaborador de la responsabilidad
r
Las medidas se pueden utilizar para determinar o para
de la clase (CRCs): denotan los nombres de los
estimar cuantitativamente varios aspectos del tamaño,
componentes (clases), de sus
de la estructura, o de la calidad de un diseño del
responsabilidades, y nombres de sus
do
software. La mayoría de las medidas se han propuesto
componentes de colaboración‘ [Boo99: c4; ]
que dependen generalmente del acercamiento usado
para producir el diseño. Estas medidas se clasifican en Diagramas de despliegue: representar un
dos amplias categorías: sistema de nodos (físico) y de sus
correlaciones, y, así, modelaban los aspectos
Diseño de medidas orientada a función
físicos de un sistema [Boo99: ]
(estructuradas): Estructura del diseño, obtenida
sobre todo con la descomposición funcional; Diagramas de la Entidad-relación (ERDs):
representado generalmente como una carta de representan modelos conceptuales de los datos
estructura (a veces llamada un diagrama almacenados en los sistemas de información
jerárquico) en la cual varias medidas pueden [Bud04: c6; Dor02: v1c5; 2]
ser computadas [Jal97: c5, c7, Pre04: ] Lenguaje descriptivo de la interfaz (IDLS):
rra
Diseño de medidas orientada a objetos: La programación como lenguajes usados para
estructura total del diseño se representa a definir los interfaces (nombres y tipos de
menudo como diagrama de la clase, en el cual operaciones exportadas) de los componentes
varias medidas pueden ser computadas. Las de software [Bas98: c8; Boo99: ]
medidas en las características del contenido Diagramas de la estructura de Jackson: Usados
interno de cada clase pueden también ser para describir las estructuras de datos en
computadas [Jal97: c6, c7; Pre04: c15] términos de secuencia, selección, e iteración
[Bud04: c6; 2 Mar:
5 Notaciones del diseño del software Estructura de cartas: Usados para describir la
estructura que llamaba de los programas (el
Muchas notaciones e idiomas existen para representar módulo llama, y es llamado por otro módulo)
los artefactos del diseño del software. Algunos se [Bud04: c6; Jal97: c5; 2 Mar: Dr; Pre04: c10]
Bo
r
efecto contra el alcance del control) para transformar un
estado: demostraban el control de flujo de DFD en una arquitectura del software representada
estado a estado en una máquina de generalmente como carta de estructura.
estados[Boo99: c24; Bud04: c6; 2 Mar: Dr;
do
Jal97: ] 6.3 Diseño orientado a objeto
Lenguajes formales de especificación:
Lenguajes textuales que utilizan nociones [Bud0: c16; Dor02: v1: c6s2, s3; Fre83: VI; Jal97: c6; 2
básicas de matemáticas (por ejemplo, lógica, Mar: D; Pre04: c9]
sistema, secuencia), para obtener de forma Numerosos métodos de diseño de software basados en
rigurosa y abstracta, definir interfaces y objetos han sido propuestos. El campo se ha
comportamientos del componente de software, desarrollado basado en el diseño objeto de los mediados
a menudo en términos de pre y post- de los años ochenta (sustantivo = objeto; verbo =
condiciones [Bud04: c18; Dor02: v1c6s5; método; adjetivo = cualidad) con el diseño orientado a
Mey97: ] objetos, donde la herencia y el polimorfismo
desempeñan un papel importante, el campo del diseño
rra
Lenguajes del diseño de pseudo código del
programa (PDLs): Programa estructurado del componente-basado, donde la meta información
como los lenguajes usados para describir, puede ser definida y ser alcanzada (con la reflexión, por
generalmente en la etapa detallada del diseño, ejemplo). Aunque las raíces del diseño Orientado a
el comportamiento de un procedimiento o el Objetos provienen del concepto de la abstracción de los
método [Bud04: c6; Fre83: VII; Jal97: c7; datos, el diseño responsabilidad-conducido también se
Pre04: c8, c11] ha propuesto como alternativo al diseño Orientado a
Objetos.
6 Estrategias y métodos del diseño de software
6.4 Diseño Dato-Estructura-Centrado
Existen varias estrategias generales para ayudar a dirigir
el proceso de diseño. [Bud04: c9, 2 Mar: D] Al [Bud04: c15; Fre83: III, VII; 2 Mar02:D]
El diseño Dato-estructura-centrado (por ejemplo,
Bo
r
do
rra
Bo
MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA
[IEEE1016-98]
[IEEE1471-00]
[IEEE12207.0-
[iEEE1028-97]
[ISO15026-98]
[ISO9126-01]
[Mar02]*
{Mar94}
[Mey97]
[Bud03]
{Bas98}
[Boo99]
[Dor02]
[Smi93]
[Bus96]
[Li s01]
[Bas03]
[Bos00]
[Jal 97]
[Fre83]
[Pre04]
[Pfl01]
r
96]
1.Fundamentos del
c11s1
Diseño de Software
do
1.1Conceptos Generales c13s1,
c1
de Diseño c13s2
c1s1, c13s2,
1.2El contexto de Diseño c3s1-
Software * c3s3,c125- D c2s2 c2
128, c9s1-
c9s3
c5s1,
c5s2,
1.4 Técnicas Permitidas {c6s1} c10s3 c6s3 * c5s2, c9
c5s5
rra
c6s2
c32s4,
2.2 Control y manejo de eventos {c5s2} {DD} c5s3
c32s5
c16s3,
2.3 Distribución de componentes c5s4.1 c2s3 c30 c30
c16s4
Bo
2.4 Manejo de errores y
excepciones y c4s3-c4s5 c12 c5s5
tolerancia a fallos
[IEEE1471-
[iEEE1028-
[ISO15026-
[ISO9126-
[Mar02]*
{Mar94}
[Mey97]
[Bud03]
r
{Bas98}
[Boo99]
[Dor02]
[Smi93]
[Bus96]
[Li s01]
[Bas03]
[Bos00]
[Jal 97]
[Fre83]
[Pre04]
[Pfl01]
0-96]
98]
97]
00]
01]
98]
do
3. Estructura y Arquitectura
c31
Software
c2s
3.1 Estructuras de la Arquitectura c28 c5 c6s1 * *
5
c1s1-
c5s
3.2 Estilos de Arquitectura c28 c6s3.1 c1s3, c2s3
9
c6s2
{c1
c1s1-
3s3 c28 DP
3.3 Patrones de Diseño c1s3
}
c7s1,
{c1 c7s2,
3.4 Familias de programas y 5s1, c10s2-
c6s2 c30
Marcos de Trabajo c15 c10s4,
rra
s3} c11s2
–c11s4
4. Análisis de la Calidad y
Evaluación del Diseño de
Software
[IEEE1471-
[iEEE1028-
[ISO15026-
[ISO9126-
[Mar02]*
{Mar94}
[Mey97]
[Bud03]
r
{Bas98}
[Boo99]
[Dor02]
[Smi93]
[Bus96]
[Li s01]
[Bas03]
[Bos00]
[Jal 97]
[Fre83]
[Pre04]
[Pfl01]
0-96]
98]
97]
00]
01]
98]
do
5. Notaciones de Diseño de
Software
{c8s c4, c8
4} c11,
5.1 Descripciones estructurales c12s c12, c5s3,
c6 429 DR
(Vista Estática 1, c14, c6s3
c12s c30,
2 c31
485-
5.2 Descripciones del c6, 490,
v1c5 c7s2 DR c10
Comportamiento (Vista Dinámica) c18 506-
513
6. Métodos y Estrategias en
c11 c8,c11
rra
Diseño de Software
304-
c8,
c5s1- 320,
6.1 Estrategias generales c10, c5s1.4 c13s13
c5s4 533-
c12
539
6.2 Diseño Orientado a Funciones
328-
(Estructurado) c5s4 c2s2
352
6.3 Diseño Orientado a Objetos 420-
c6s4 D c9,c10
436
201-
6.4 Diseño centrado en Estructuras
120,
de Datos D c9
514-
532
Bo
6.5 Diseño Basado en
Componentes (CBD)
r
[Bud04] D. Budgen, Software Design, second ed., Design, Addison-Wesley, 2001.
Addison-Wesley, 2004.
[Mar94] J.J. Marciniak, Encyclopedia of Software
do
[Bus96] F. Buschmann et al., Pattern-Oriented Software Engineering, J. Wiley & Sons, 1994. The references to the
Architecture: A System of Patterns, John Wiley & Sons, Encyclopedia are as follows:
1996.
CBD = Component-Based Design
[Dor02] M. Dorfman and R.H. Thayer, eds., Software D = Design
Engineering (Vol. 1 & Vol. 2), IEEE Computer Society DD = Design of the Distributed System
Press, 2002. DR = Design Representation
[Fre83] P. Freeman and A.I. Wasserman, Tutorial on [Mar02] J.J. Marciniak, Encyclopedia of Software
Software Design Techniques, fourth ed., IEEE Computer Engineering, second ed., J. Wiley & Sons, 2002.
Society Press, 1983.
[Mey97] B. Meyer, Object-Oriented Software
[IEEE610.12-90] IEEE Std 610.12-1990 (R2002), IEEE
rra
Construction, second ed., Prentice-Hall, 1997.
Standard Glossary of Software Engineering Terminology,
IEEE, 1990. [Pfl01] S.L. Pfleeger, Software Engineering: Theory and
Practice, second ed., Prentice-Hall, 2001.
[IEEE1016-98] IEEE Std 1016-1998, IEEE Recommended
Practice for Software Design Descriptions, IEEE, 1998. [Pre04] R.S. Pressman, Software Engineering: A
Practitioner‘s Approach, sixth ed., McGraw-Hill, 2004.
[IEEE1028-97] IEEE Std 1028-1997 (R2002), IEEE
Standard for Software Reviews, IEEE, 1997. [Smi93] G. Smith and G. Browne, ―Conceptual
Foundations of Design Problem-Solving,‖ IEEE
[IEEE1471-00] IEEE Std 1471-2000, IEEE Recommended Transactions on Systems, Man and Cybernetics, vol. 23,
Practice for Architectural Description of Software iss. 5, 1209-1219, Sep.-Oct. 1993.
Intensive Systems, Architecture Working Group of the
Software Engineering Standards Committee, 2000.
Bo
APÉNDICE A. LISTA DE LECTURAS (Kic97) G. Kiczales et al., ―Aspect-Oriented
COMPLEMENTARIAS Programming,‖ presented at ECOOP ‘97 — Object-
Oriented Programming, 1997.
(Boo94a) G. Booch, Object Oriented Analysis and Design (Kru95) P. B. Kruchten, ―The 4+1 View Model of
with Applications, second ed., The Benjamin/Cummings Architecture,‖ IEEE Software, vol. 12, iss. 6, 42-50, 1995
Publishing Company, 1994. (Lar98) C. Larman, Applying UML and Patterns: An
(Coa91) P. Coad and E. Yourdon, Object-Oriented Design, Introduction to Object-Oriented Analysis and Design,
Yourdon Press, 1991. Prentice-Hall, 1998.
(Cro84) N. Cross, Developments in Design Methodology, (McC93) S. McConnell, Code Complete: A Practical
John Wiley & Sons, 1984. Handbook of Software Construction, Microsoft Press,
1993.
(DSo99) D.F. D‘Souza and A.C. Wills, Objects,
Components, and Frameworks with UML — The Catálisis (Pag00) M. Page-Jones, Fundamentals of Object-Oriented
Approach, Addison-Wesley, 1999. Design in UML, Addison-Wesley, 2000.
r
(Dem99) T. DeMarco, ―The Paradox of Software (Pet92) H. Petroski, To Engineer Is Human: The Role of
Architecture and Design,‖ Stevens Prize Lecture, Aug. Failure in Successful Design, Vintage Books, 1992.
1999. (Pre95) W. Pree, Design Patterns for Object-Oriented
do
(Fen98) N.E. Fenton and S.L. Pfleeger, Software Metrics: Software Development, Addison-Wesley and ACM Press,
A Rigorous & Practical Approach, second ed., 1995.
Internacional Thomson Computer Press, 1998. (Rie96) A.J. Riel, Object-Oriented Design Heuristics,
(Fow99) M. Fowler, Refactoring: Improving the Design of Addison-Wesley, 1996.
Existing Code, Addison-Wesley, 1999. (Rum91) J. Rumbaugh et al., Object-Oriented Modeling
(Fow03) M. Fowler, Patterns of Enterprise Application and Design, Prentice-Hall, 1991.
Architecture, Addison-Wesley, 2003. (Sha96) M. Shaw and D. Garlan, Software Architecture:
(Gam95) E. Gamma et al., Design Patterns: Elements of Perspectives on an Emerging Discipline, Prentice-Hall,
Reusable Object-Oriented Software, Addison-Wesley, 1996.
rra
1995. (Som05) I. Sommerville, Software Engineering, seventh
(Hut94) A.T.F. Hutt, Object Analysis and Design — ed., Addison-Wesley, 2005.
Comparison of Methods. Object Analysis and Design — (Wie98) R. Wieringa, ―A Survey of Structured and Object-
Description of Methods, John Wiley & Sons, 1994. Oriented Software Specification Methods and
(Jac99) I. Jacobson, G. Booch, and J. Rumbaugh, The Techniques,‖ ACM Computing Surveys, vol. 30, iss. 4,
Unified Software Development Process, Addison-Wesley, 1998, pp. 459-527.
1999. (Wir90) R. Wirfs-Brock, B. Wilkerson, and L. Wiener,
Designing Object-Oriented Software, Prentice-Hall, 1990.
Bo
APÉNDICE B. LISTA DE ESTÁNDARES
r
(IEEE12207.0-96) IEEE/EIA 12207.0-
1996//ISO/IEC12207:1995, Industry Implementation of
do
Int. Std. ISO/IEC 12207:95, Standard for Information
Technology-Software Life Cycle Processes, vol. IEEE,
1996.
(ISO9126-01) ISO/IEC 9126-1:2001, Software
Engineering-Product Quality-Part 1: Quality Model, ISO
and IEC, 2001.
(ISO15026-98) ISO/IEC 15026-1998 Information
Technology — System and Software Integrity Levels, ISO
and IEC, 1998.
rra
Bo
Bo
rra
do
r
CAPÍTULO 4
CONSTRUCCIÓN DEL SOFTWARE
r
INTRODUCCIÓN
frecuencia, como pertenecientes al dominio de la
El término construcción del software hace referencia a ciencia informática. También está relacionada con la
la creación detallada de software operativo y gestión del proyecto en la medida en que la gestión de
do
significativo, por medio de una combinación de la construcción pueda presentar retos considerables.
codificación, verificación, pruebas unitarias, pruebas de
integración y depuración. DESCOMPOSICIÓN DE LOS TEMAS DE
El Área de Conocimiento de la Construcción del CONSTRUCCIÓN DEL SOFTWARE
Software está vinculada a todas las otras KAs (Áreas de
Conocimiento), más fuertemente al Diseño del Software A continuación se presenta la descomposición del KA
y a las Pruebas del Software. Esto se debe a que el de la Construcción del Software junto con breves
proceso mismo de construcción del software cubre tanto descripciones de los temas más importantes asociados a
el diseño significativo de software como las actividades este. La figura 1 ofrece una representación gráfica de la
de pruebas. También utiliza las salidas del diseño y descomposición de alto nivel de las divisiones de este
KA.
rra
proporciona una de las entradas para las pruebas,
consistiendo estas actividades en el diseño y en las
pruebas, y en este caso no en las KAs. Las fronteras 1. Fundamentos de la Construcción del Software
detalladas entre el diseño, la construcción y las pruebas Los fundamentos de la construcción del software
(si es que existen) varían dependiendo de los procesos incluyen:
de ciclo de vida del software utilizados en un proyecto. Minimizar la complejidad
A pesar de que se pueda realizar parte del diseño Anticiparse a los cambios
detallado antes de la construcción, mucho del trabajo Construir para verificar
del diseño se lleva a cabo durante la actividad misma de Estándares en la construcción
la construcción. Por lo que el KA de Construcción del
Software está vinculado muy de cerca al KA de Diseño Los tres primeros conceptos se aplican tanto al diseño
del Software.
Bo
r
la construcción del software. El software es Herramientas (por ejemplo, estándares
inevitablemente parte de los ambientes externos que diagramáticos para notaciones como UML
cambian continuamente, y los cambios en esos (Lenguaje Unificado de Modelado))
ambientes externos afectan al software de diversos
do
modos. Uso de estándares externos. Construir depende del uso
El anticiparse a los cambios se apoya en muchas de estándares externos para los lenguajes de
técnicas específicas resumidas en el apartado 3.3 construcción, las herramientas de construcción, las
Codificación. interfaces técnicas, y las interacciones entre la
Construcción del Software y las otras KAs. Los
1.3 Construir para verificar estándares provienen de numerosas fuentes, incluyendo
[Ben00; Hun00; Ker99; Mag93; McC04] las especificaciones de interfaz del hardware y del
Construir para verificar significa construir software de software, tales como el Grupo de Gestión de Objetos
tal manera que los ingenieros del software puedan sacar (OMG) y las organizaciones internacionales tales como
a relucir los fallos con facilidad al estar escribiendo el la IEEE o ISO.
rra
código, además de cuando realizan pruebas Uso de estándares internos. Los estándares también
independientes y actividades operacionales. Las pueden crearse partiendo de una base organizacional a
técnicas específicas que sirven de base para construir un nivel corporativo o para su uso en proyectos
con vistas a verificar incluyen el seguimiento de específicos. Estos estándares permiten la coordinación
estándares de codificación que permitan las revisiones de actividades de grupo, el minimizar la complejidad, el
del código, las pruebas unitarias, la organización del anticipar los cambios y el construir para verificar.
código que permita pruebas automáticas, y el uso
restringido de estructuras de lenguaje que sean
complejas o difíciles de entender, entre otras.
Bo
r
3. Consideraciones Prácticas
una planificación detallada. Los enfoques más lineales
tienden a poner el énfasis en las actividades que La construcción es una actividad en la cual el software
preceden a la construcción (requisitos y diseño), y se las tiene que ver con restricciones arbitrarias y
do
tienden a crear separaciones más marcadas entre las caóticas del mundo real, y hacer exactamente lo que
actividades. En estos modelos, la codificación sería el piden. Gracias a su proximidad a las restricciones del
punto de mayor énfasis de la construcción. mundo real, la construcción está guiada por
Otros modelos son más iterativos, tales como el consideraciones prácticas más que otras KAs, y la
prototipado evolucionista, Programación Extrema y ingeniería del software es quizás el área de construcción
―Scrum‖. Estos enfoques tienden a tratar la más artesanal.
construcción como una actividad que ocurre en estos
momentos con otras actividades de desarrollo del 3.1 Diseño de la Construcción
software incluyendo los requisitos, el diseño y la
planificación, o que se traslapa con ellas. Estos [Bec99; Ben00; Hun00; IEEE12207-95; Mag93;
McC04]
enfoques tienden a mezclar el diseño, la codificación y
rra
las actividades de pruebas, y con frecuencia tratan la Algunos proyectos asignan una mayor actividad de
combinación de actividades como una construcción. diseño a la construcción; otros a una fase que se centra
explícitamente en el diseño. Independientemente de su
Por consiguiente, lo que está considerado como
―construcción‖ depende hasta cierto grado del modelo asignación exacta, en el nivel de construcción también
de ciclo de vida utilizado. se trabaja algo el diseño detallado y ese trabajo de
diseño tiende a estar dictaminado por restricciones
inamovibles impuestas por un problema del mundo real
2.2 Planificación de la Construcción
que está siendo afrontado por el software.
[Bec99; McC04] Así como los obreros de una construcción que
La elección de un método de construcción es un aspecto construyen una estructura física tienen que realizar
clave de la planificación de la actividad de modificaciones a pequeña escala para cubrir huecos no
construcción. La elección de un método de construcción previstos en los planes del constructor, los obreros de la
Bo
afecta hasta dónde se realizan los prerrequisitos de construcción del software tendrán que hacer
construcción, el orden en el que se realizan, y el grado modificaciones en una mayor o menor escala para
hasta el que se espera que se completen antes de que revelar los detalles del diseño de software durante la
comience el trabajo de construcción. construcción.
El modo como se afronta la construcción afecta a la Los detalles de la actividad de diseño a nivel de la
habilidad del proyecto para reducir la complejidad, construcción son esencialmente los mismos que se
anticipar cambios y construir para verificar. Cada uno describen en el KA del Diseño del Software, pero se
de estos objetivos puede también afrontarse en los aplican en una escala inferior.
niveles de proceso, requisitos y diseño –pero también
estarán influenciados por la elección de un método de 3.2 Lenguajes de Construcción
construcción.
La planificación de la construcción también define el [Hun00; McC04]
Los lenguajes de construcción incluyen todos los tipos
orden en el que se crean e integran, según el método
elegido, los componentes, los procesos de gestión de la de comunicación mediante los cuales un humano puede
calidad del software, la asignación de tareas a especificar una solución ejecutable para un problema de
ingenieros del software específicos y el resto de las un ordenador.
tareas. El tipo más simple de lenguaje de construcción es un
lenguaje de configuración en el que los ingenieros del
software eligen de entre un conjunto limitado de
opciones predefinidas para crear nuevas o típicas
instalaciones del software. Los archivos de la principal tarea de programación es simplemente
configuración basados en texto utilizados tanto en los construir y ―ajustar‖ una interfaz visual a un programa,
sistemas operativos de Windows como de Unix son cuyo comportamiento detallado ha sido definido
ejemplos de esto, y otro ejemplo son las listas de anteriormente.
selección en forma de menú de algunos generadores de
programas. 3.3 Codificación
Los lenguajes de herramientas se utilizan para construir
aplicaciones partiendo de las herramientas (conjuntos [Ben00; IEEE12207-95; McC04]
integrados de partes reutilizables específicas de las Las consideraciones siguientes se aplican a la actividad
de construcción del código del software:
aplicaciones), y son más complejos que los lenguajes de
configuración. Los lenguajes de herramientas pueden Técnicas para crear código fuente comprensible,
definirse explícitamente como lenguajes de que incluye la asignación de nombres y el esquema
programación de aplicaciones (por ejemplo, scripts), o del código fuente
pueden simplemente estar implícitos en el conjunto de Utilización de clases, tipos enumerados, variables,
interfaces de las herramientas. constantes predefinidas, y otras entidades similares
Utilización de estructuras de control
r
Los lenguajes de programación son el tipo más flexible
de lenguaje de construcción. También son los que Tratamiento de las condiciones de error –tanto lo
menos información contienen acerca de las áreas errores planeados como las excepciones (la entrada
do
específicas de la aplicación y los procesos de desarrollo, de datos malos, por ejemplo)
y por tanto requieren el mayor entrenamiento y destreza Prevención de brechas en la seguridad a nivel de
posibles para utilizarlo con eficacia. código (el búfer o el índice de la matriz se
Existen tres tipos generales de notación utilizados para desborda, por ejemplo)
los lenguajes de programación, a saber: Utilización de recursos por medio del uso de
Lingüísticos mecanismos de exclusión y disciplina en el acceso
Formales serial a recursos reutilizables (incluyendo threads o
Visuales bloqueos de bases de datos)
Las notaciones lingüísticas se distinguen en particular Organización del código fuente (en declaraciones,
por la utilización de cadenas de texto del tipo palabra rutinas, clases, paquetes u otras estructuras)
para representar construcciones complejas de software, Documentación del código
rra
y por la combinación en patrones de tales cadenas del Puesta a punto del código
tipo palabra que tienen una sintaxis del tipo sentencia.
Utilizadas adecuadamente, cada una de estas cadenas 3.4 Pruebas de Construcción
debería tener una fuerte connotación ofreciendo un
[Bec99; Hun00; Mag93; McC04]
entendimiento intuitivo inmediato de lo que sucedería
Construir implica dos tipos de pruebas, que por lo
cuando se ejecutara la construcción del software
general las realiza el mismo ingeniero del software que
subyacente.
escribió el código:
Las notaciones formales se apoyan menos en los
significados de las palabras y cadenas de texto Pruebas unitarias
intuitivos y de todos los días, y más en las definiciones Pruebas de integración
respaldadas por definiciones precisas, sin ambigüedad, El propósito de las pruebas de construcción es reducir la
brecha entre el tiempo en el que se introducen fallos en
Bo
r
un tema.
Las tareas relacionadas con la reutilización en la distinguen de las otras actividades de calidad por su
construcción del software durante su codificación y enfoque. Las actividades de calidad de la construcción
pruebas son: se centran en el código y en los artefactos que están
do
estrechamente relacionados con el código: diseños en
La selección de unidades, bases de datos, pequeña escala –en oposición a otros artefactos que
procedimientos de pruebas o datos de pruebas están menos directamente ligados al código, tales como
reutilizables. requisitos, diseños de alto nivel y planes.
La evaluación de la posibilidad de reutilización del
código o de las pruebas. 3.7 Integración
Comunicar la información sobre reutilización [Bec99; IEEE12207-95; McC04]
realizada en el código nuevo, los procedimientos de Una actividad clave durante la construcción es la
pruebas o los datos de pruebas. integración de rutinas, clases, componentes y
subsistemas construidos por separado. Además, un
rra
3.6 Calidad de la Construcción sistema particular del software podría necesitar ser
integrado con otros sistemas de software o de hardware.
[Bec99; Hun00; IEEE12207-95; Mag93; McC04]
Los intereses relacionados con la integración de la
Existen numerosas técnicas para garantizar la calidad
construcción incluyen planificar la secuencia en la que
del código mientras está siendo elaborado. Las técnicas
se integrarán los componentes, crear andamiajes que
más importantes utilizadas para la construcción
soporten versiones provisionales del software,
incluyen:
determinar el grado de pruebas y la calidad del trabajo
realizado sobre los componentes antes de que sean
Las pruebas unitarias y las pruebas de integración
integrados, y determinar los puntos en el proyecto en
(tal y como se describen en el punto 3.4 Pruebas de
los que se prueban las versiones provisionales del
Construcción)
software.
El desarrollo de primero-haz-pruebas (ver también
Bo
[Mag93]
12207.0]
[Hun00]
[Som05]
[Mcc04]
[Ben00]
[Ker99]
[Bec99]
[IEEE
[IEEE
1517]
1. Fundamentos de
Construcción de
Software
c2, c3,
c7-c9,
c24,
1.1 Minimizar la
r
c17 c2, c3 c7,c8 c2, c3 c6 c27,
Complejidad
c28,
c31,
do
c32-c34
c3-c5,
1.2 Anticipación a c11,c13- c24,
c2, c9
Cambios c14 c31,
c32, c34
c21,
c8, c20-
1.3 Construir para c23, c2,c3,
c4 c1, c5, c6 c23,
verificar c34, c5,c7
c31-c34
c43
rra
1.4 Estándares de
X c4
Construcción
2. Gestión de la
Construcción
2.1 Modelos de c2, c3,
c10
Construcción c27, c29
c12, c3,
2.2 Plan de
c15, c4,c21,
Construcción
c21 c27-c29
2.3 Métricas de la
c25, c28
construcción
Bo
3. Consideraciones
Prácticas
3.1 Diseño de la c18-c10, c3, c5,
c17 c33 X c6
Construcción p175-6 c24
3.2 Lenguajes de c12,
C4
Construcción c14-c20
c5-c19,
3.3 Codificación c6-c10 X
c25-c26
3.4 Pruebas de c34,
c18 X c4 c22, c23
Construcción c43
3.5 Reusabilidad X c14
3.6 Calidad de c4, c8, c20-
c18 c18 X
Construcción c6, c7 c25
3.7 Integración c16 X c29
REFERENCIAS RECOMENDADAS PARA LA [IEEE12207.0-96] IEEE/EIA 12207.0-
1996//ISO/IEC12207:1995, Industry Implementation of
CONSTRUCCIÓN DE SOFTWARE
Int. Std.ISO/IEC 12207:95, Standard for Information
Technology-Software Life Cycle Processes, IEEE, 1996.
[Bec99] K. Beck, Extreme Programming Explained: [Ker99a] B.W. Kernighan and R. Pike, The Practice of
Embrace Change, Addison-Wesley, 1999, Chap. 10, 12, Programming, Addison-Wesley, 1999, Chap. 2, 3, 5, 6, 9.
15, 16-18, 21. [Mag93] S. Maguire, Writing Solid Code: Microsoft’s
[Ben00a] J. Bentley, Programming Pearls, second ed., Techniques for Developing Bug-Free C Software,
Addison-Wesley, 2000, Chap. 2-4, 6-11, 13, 14, pp. 175- Microsoft Press, 1993, Chap. 2-7.
176. [McC04] S. McConnell, Code Complete: A
[Hun00] A. Hunt and D. Thomas, The Pragmatic PracticalHandbook of Software Construction, Microsoft
Programmer, Addison-Wesley, 2000, Chap. 7, 8 12, 14- Press, second ed., 2004.
21, 23, 33, 34, 36-40, 42, 43. [Som05] I. Sommerville, Software Engineering, seventh
[IEEE1517-99] IEEE Std 1517-1999, IEEE Standard for ed., Addison-Wesley, 2005.
Information Technology-Software Life Cycle Processes-
Reuse Processes, IEEE, 1999.
r
do
rra
Bo
APÉNDICE A. LISTA DE LECTURAS ADICIONALES. (How02) M. Howard and D.C. Leblanc, Writing Secure
Code, Microsoft Press, 2002.
(Bar98) T.T. Barker, Writing Software Documentation: A (Hum97b) W.S. Humphrey, Introduction to the Personal
Task-Oriented Approach, Allyn & Bacon, 1998. Software Process, Addison-Wesley, 1997.
(Bec02) K. Beck, Test-Driven Development: By Example, (Mey97) B. Meyer, Object-Oriented Software
Addison-Wesley, 2002. Construction, second ed., Prentice Hall, 1997, Chap. 6, 10,
(Fow99) M. Fowler and al., Refactoring: Improving the 11.
Design of Existing Code, Addison-Wesley, 1999. (Set96) R. Sethi, Programming Languages: Concepts &
Constructs, second ed., Addison-Wesley, 1996, Parts II-V.
r
do
rra
Bo
APÉNDICE B. LISTA DE ESTÁNDARES
r
do
rra
Bo
Bo
rra
do
r
CAPÍTULO 5
PRUEBAS DEL SOFTWARE
r
ejecución de un programa es aceptable o no, porque
Hacer pruebas es una actividad que tiene el objetivo de si no el esfuerzo de realizar las pruebas sería inútil.
evaluar y mejorar la calidad del producto, identificando El comportamiento observado se puede comprobar
do
defectos y problemas. con los resultados esperados por el usuario
Las pruebas del software consisten en verificar el (normalmente conocido como pruebas de
comportamiento de un programa dinámicamente a través validación), con las especificaciones (pruebas de
de un grupo finito de casos de prueba, debidamente verificación), o, finalmente, con el comportamiento
seleccionados del, típicamente, ámbito de ejecuciones anticipado de requerimientos implícitos o
infinito, en relación al comportamiento esperado. En la expectativas razonables. Vea más detalles en el KA
definición anterior las palabras en itálica se corresponden de Requerimientos del Software, punto 6.4 Pruebas
con aspectos esenciales en la identificación del ―Área de de Aceptación.
Conocimiento de las Pruebas del Software‖. En La apreciación de las pruebas del software ha
particular: evolucionado hacia una forma más constructiva. Ya no
rra
Dinámicamente: Este término significa que hacer se asume que realizar pruebas es una tarea que empieza
pruebas siempre supone ejecutar el programa con solamente cuando la fase de programación se ha
entrada de datos (valorados). Para precisar, es completado, y que tiene el único propósito de detectar
preciso afirmar que la entrada de valores no es errores. Las pruebas del software se ven ahora como una
siempre suficiente para definir una prueba, dado que actividad que debería estar presente durante todo el
un sistema complejo y no determinista podría tener proceso de desarrollo y mantenimiento y es en sí misma
diferentes comportamientos con las misma entrada una parte importante de la construcción del producto. Es
de datos, dependiendo del estado en el que se más, la planificación de las pruebas debería empezar en
encuentre. En cualquier caso, en este KA, las primeras etapas del proceso de requisitos, mientras
mantendremos el término de ―entrada de datos‖, que los planes y procedimientos de pruebas deberían
asumiendo la convención de que el término incluye desarrollare y posiblemente refinarse sistemáticamente
un estado del sistema específico, en los casos en que según avanza el desarrollo. La planificación de las
Bo
sea necesario. Existen otras técnicas pruebas y las propias actividades de diseño constituyen
complementarias a las pruebas, aunque diferentes, una información muy útil que ayuda a los diseñadores de
descritas en el KA sobre la Calidad del Software. software a identificar debilidades potenciales (tales como
Finito: Incluso en programas sencillos, teóricamente elementos del diseño que han pasado desapercibidos,
podría haber tantas pruebas que realizar, que hacer contradicciones de diseño, u omisiones o ambigüedades
pruebas exhaustivas podría llevar meses o años. Esta en la documentación).
es la razón por la que en la práctica el grupo En la actualidad se considera que la prevención es la
completo de pruebas se podría considerar infinito. actitud adecuada en lo que respecta a la calidad:
Hacer pruebas siempre supone un compromiso entre obviamente es mejor evitar problemas que solucionarlos.
recursos y calendarios de trabajo limitados, por un Realizar pruebas debe verse como un medio para
lado, y necesidades inherentes de pruebas ilimitadas, verificar, no sólo si la prevención ha sido efectiva, si no
por otro. para identificar fallos en aquellos casos en los que, por
Seleccionados: La diferencia esencial entre las alguna razón, no lo ha sido. Aunque quizás sea obvio,
distintas técnicas de pruebas propuestas se encuentra vale la pena reconocer que, incluso después de una
en cómo se escoge el conjunto de pruebas. Los campaña de pruebas extensiva, el software aún podría
ingenieros informáticos deben ser conscientes de contener errores. Las acciones de mantenimiento
que criterios de selección distintos pueden producir correctivas proporcionan la solución a errores en el
grados de efectividad muy diferentes. La forma de software después de que éste ha sido entregado. El KA
identificar el criterio de selección de pruebas más
del Mantenimiento del Software aborda los temas pruebas para software grande, mientras que el segundo
relacionados con el mantenimiento del software. (2.2) considera las pruebas para situaciones o
propiedades específicas y se conoce como objetivos de
En el KA del Mantenimiento del Software (véase punto
las pruebas. No todos los tipos de pruebas se pueden
3.3 Técnicas de Gestión de Calidad del Software), las
aplicar a todos los productos de software, tampoco se
técnicas de gestión de la calidad del software se dividen
han enumerado todos los tipos posibles.
entre técnicas estáticas (sin ejecución de código) y
técnicas dinámicas (con ejecución de código). Ambas El objeto y los objetivos de las pruebas determinan la
categorías son útiles. Este KA se centra en técnicas forma en que un grupo de pruebas se identifica, en lo que
dinámicas. se refiere a su consistencia – cuántas pruebas son
suficientes para conseguir el objetivo especificado – y su
Las pruebas del software también están relacionadas con
composición – qué casos de prueba se deberían
la construcción del software (véase la sección 3.4
seleccionar para conseguir el objetivo especificado
Construcción de Pruebas). Las pruebas de unidad y de
(aunque normalmente la parte ―para conseguir el
integración están íntimamente relacionadas con la
objetivo especificado‖ es implícita y sólo se usa la
construcción del software, si no son parte de la misma.
r
primera parte de las dos frases anteriores). Los criterios
para responder a la primera cuestión se denominan
DIVISIÓN DE TEMAS
criterios de idoneidad las pruebas, mientras que los que
La descomposición de temas en el KA de las Pruebas del se refieren a la segunda cuestión se denominan criterios
do
Software se muestra en la Figura 1. de selección de las pruebas.
La primera subárea describe los Fundamentos de las En las últimas décadas se han desarrollado varias
Pruebas del Software. Cubre las definiciones básicas del Técnicas de Pruebas y aún se están proponiendo nuevas
área de pruebas del software, la terminología básica y los técnicas. El conjunto de pruebas comúnmente aceptadas
términos clave, así como las relaciones con otras están enumeradas en la subárea 3.
actividades. Las Mediciones de Pruebas se enumeran en la subárea 4.
Finalmente, los aspectos relacionados con el Proceso de
La segunda subárea, Niveles de Pruebas, está formada las Pruebas están enumeradas en la subárea 5
por dos puntos ortogonales: el primero (2.1) enumera los
niveles en que tradicionalmente se subdividen las
rra
Bo
r
En la bibliografía sobre Ingeniería del Software se usan satisfactoria es aquella en la que no se observan errores
diversos términos para describir un funcionamiento (al menos significativos).
incorrecto, particularmente falta, error, fallo y otros
1.2.4 El problema del oráculo
do
términos. Esta terminología se define detalladamente en
el estándar IEEE 610.12-1990, Standard Glossary of [Bei90:c1] (Ber96, Wey83)
Software Engineering Terminology (IEEE610-90) y Un oráculo es cualquier agente (humano o mecánico)
también se discute en el KA de la Calidad del Software. que decide si un programa se comporta correctamente
Es esencial distinguir claramente entre la causa de un durante una prueba y consecuentemente produce un
funcionamiento incorrecto, en cuyo caso se usan veredicto de ―superada‖ o ―fallada‖. Hay varios tipos
términos como error y defecto, y los efectos no diferentes de oráculos, y la automatización de oráculos
deseados observados en los servicios proporcionados puede ser muy difícil y cara.
por un sistema, que se llamarán fallos. Hacer pruebas
puede descubrir fallos, pero es el error el que se puede, 1.2.5 Limitaciones teóricas y prácticas de las
y se debe, eliminar. pruebas [Kan99:c2] (How76)
rra
En cualquier caso, debería aceptarse que no es siempre La teoría de pruebas advierte en contra de un nivel
posible identificar unívocamente las causas de un fallo. injustificado de confianza en una serie de pruebas
No existe ningún criterio teórico que pueda usarse para superadas. Desafortunadamente, la mayor parte de los
determinar qué error produce el fallo observado. Podría resultados establecidos en la teoría de pruebas son
decirse que hay que arreglar el error para eliminar el negativos, en el sentido de que establecen aquello que
problema, pero otros cambios también podrían la prueba no puede conseguir, en vez de lo que
funcionar. Para evitar ambigüedades, algunos autores consiguió. La más famosa cita a este respecto es el
prefieren hablar de entradas que causan fallos (Fra98) aforismo de Dijkstra que dice ―las pruebas de un
en vez de errores – o lo que es lo mismo, aquellos programa se pueden usar para mostrar las presencia de
grupos de entradas de datos que hacen que el fallo errores, pero nunca para demostrar su ausencia‖. La
aparezca. razón obvia es que realizar un grupo completo de
Bo
1.2.2 Efectividad de las pruebas/Objetivos para las El término ―posibilidad de hacer pruebas‖ tiene dos
pruebas significados relacionados pero diferentes: por un lado,
[Bei90:c1s1.4; Per95:c21] (Fra98) se refiere al grado de facilidad del software para
satisfacer un determinado criterio de cobertura de
pruebas, como se describe en (Bac90); por otro, se soporte de herramientas de depuración, pudiendo
define como la probabilidad, posiblemente cualificada implicar a los programadores que escribieron el código
estadísticamente, de que los errores del software queden
2.1.2 Pruebas de Integración
expuestos durante las pruebas, si es erróneo, tal y como
[Jor02:c13, 14; Pfl01:c8s7.4]
se describe en (Voa95, Ber96a). Ambos significados
son importantes. Una prueba de integración es el proceso de verificar la
interacción entre componentes de software. Estrategias
1.3 Relación de las pruebas con otras actividades
clásicas de integración, como arriba-abajo o abajo-
Las pruebas del software, aunque diferentes, están arriba, se usan, tradicionalmente, con software
relacionadas con las técnicas de gestión de la calidad estructurado jerárquicamente.
del software estático, las pruebas de validez del
Las estrategias modernas de integración están dirigidas
software, la depuración y la programación. Sin
por la arquitectura, lo que supone integrar los
embargo, es útil considerar las pruebas desde el punto
componentes de software o subsistemas basándose en
de vista del analista de calidad del software o
caminos de funcionalidad identificada. Las pruebas de
certificador.
r
integración son una actividad continua, que sucede en
Pruebas vs. técnicas de Gestión de Calidad del cada fase en que los ingenieros de software tienen que
Software Estático. Véase también el KA de la hacer abstracciones de las perspectivas de bajo nivel y
Calidad del Software, punto 2. Proceso de Gestión concentrarse en las perspectivas del nivel que están
do
de la Calidad del Software. [Bei90:c1; Per95:c17] integrando. Con la excepción de software sencillo y
(IEEE1008-87) pequeño, las estrategias de pruebas de integración
Pruebas vs. Pruebas de Validez y Verificación sistemáticas e incrementales son preferibles a probar
Formal [Bei90:c1s5; Pfl01:c8]. todos los componentes juntos al final, lo que se conoce
Pruebas vs. Depuración. Véase también el KA de la (de forma gráfica), como pruebas en ―big bang‖.
Construcción del Software, punto 3.4 Pruebas de 2.1.3 Pruebas del sistema
la construcción [Bei90:c1s2.1] (IEEE1008-87). [Jor02:c15; Pfl01:c9]
Pruebas vs. Programación. Véase también el KA de
la Construcción del Software, punto 3.4 Pruebas de Las pruebas del sistema se ocupan del comportamiento
la construcción [Bei90:c1s2.1] (IEEE1008-87). de un sistema completo. La mayoría de los fallos
rra
Pruebas y Certificación (Wak99). funcionales deberían haber sido identificados antes,
durante las fases de pruebas de unidad y pruebas de
2 Niveles de Pruebas integración. Las pruebas del sistema se consideran
2.1 El objeto de la prueba normalmente como las apropiadas para comparar el
sistema con los requisitos no funcionales del sistema,
Las pruebas del software se realizan normalmente a como seguridad, velocidad, exactitud y confiabilidad.
diferentes niveles durante los procesos de desarrollo y Las interconexiones externas con otras aplicaciones,
mantenimiento. Esto significa que el objeto de las utilidades, dispositivos hardware o con el sistema
pruebas puede cambiar: un módulo, un grupo de dichos operativo, también se evalúan en este nivel. Véase el
módulos (relacionados por propósito, uso, KA de Requisitos del Software para más información
comportamiento, o estructura), o un sistema completo. acerca de requisitos funcionales y no funcionales.
[Bei90:c1; Jor02:c12;Pfl01:c8] Conceptualmente se
Bo
pueden distinguir tres grandes niveles de pruebas, 2.2 Objetivos de las pruebas
llamadas de Unidad, de Integración y del Sistema. No [Per95:c8; Pfl01:c9s8.3]
hay un modelo de proceso implícito, ni se asume que Las pruebas se realizan en relación a conseguir un
ninguno de estos tres niveles tiene mayor importancia determinado objetivo, que se ha definido más o menos
que los otros dos. explícitamente y con diversos niveles de precisión.
2.1.1 Pruebas de Unidad Definir el objetivo, en términos precisos y cuantitativos,
[Bei90:c1; Per95:c17; Pfl01:c8s7.3] permite establecer controles en el proceso de las
(IEEE1008-87) pruebas.
Las pruebas de unidad verifican el funcionamiento Las pruebas se pueden realizar para verificar
aislado de partes del software que se pueden probar propiedades distintas. Se pueden asignar casos de
independientemente. Dependiendo del contexto, estas prueba para comprobar que las especificaciones
partes podrían ser subprogramas individuales o un funcionales se han implementado correctamente, a lo
componente más grande formado por unidades muy que la literatura se refiere como pruebas de
relacionadas. Hay una definición más precisa de prueba conformidad, pruebas de corrección o pruebas de
de unidad en el estándar IEEE de pruebas de unidad del funcionalidad. Sin embargo, también se pueden hacer
software (IEEE1008-87), que también describe un pruebas a otras muchas propiedades no funcionales,
método integrado para realizar y documentar pruebas de como rendimiento, confiabilidad y facilidad de uso,
unidad sistemáticamente. Normalmente, las pruebas de entre otras muchas.
unidad se realizan con acceso al código fuente y con el
Otros objetivos importantes de las pruebas incluyen Las pruebas, al ayudar a identificar errores, son un
(aunque no se limitan a) mediciones de confiabilidad, medio para mejorar la confiabilidad. Por contraste,
evaluación de la facilidad de uso y aceptación, para los generando casos de prueba aleatorios siguiendo el perfil
cuales se utilizarían métodos diferentes. Se debe tener de operaciones, se pueden derivar aproximaciones
en cuenta que los objetivos de las pruebas varían con el estadísticas de confiabilidad. Cuando se usan modelos
objeto de las pruebas; en general, propósitos diferentes que potencian la confiabilidad, ambos objetivos se
son tratados con diferentes niveles de pruebas. pueden alcanzar al mismo tiempo (véase también el
punto 4.1.4 Pruebas de ejecución, evaluación de la
Las referencias recomendadas para este punto describen
confiabilidad)
el conjunto de objetivos de pruebas potenciales. Los
puntos enumerados seguidamente son los que se citan 2.2.6 Pruebas de regresión
más frecuentemente en la literatura. Téngase en cuenta [Kan99:c7; Per95:c11, c12; Pfl01:c9s8.1]
que algunos tipos de pruebas son más apropiados para (Rot96)
paquetes de software hechos a medida, pruebas de
Según (IEEE610.12-90), las pruebas de regresión son
instalación, por ejemplo; mientras otros son más
―pruebas selectivas que se repiten en un componente
r
apropiados para productos más genéricos, como
para verificar que los cambios no han producido efectos
pruebas beta.
indeseados...‖ En la práctica, la idea es demostrar que
2.2.1 Pruebas de aceptación/calificación cierto software que previamente pasó un conjunto de
do
[Per95:c10; Pfl01:c9s8.5] (IEEE12207.0- pruebas, aún las pasa. Beizer (Bei90) las define como
96:s5.3.9) cualquier repetición de pruebas que tiene como objetivo
demostrar que el comportamiento del software no ha
Las pruebas de aceptación comparan el comportamiento
cambiado, excepto en aquellos aspectos en que se haya
del sistema con los requisitos del cliente, sea cual sea la
requerido así. Por supuesto se tiene que llegar a un
forma en que éstos se hayan expresado. El cliente
compromiso entre realizar pruebas de regresión cada
realiza, o especifica, tareas típicas para comprobar que
vez que se hace un cambio y los medios de que se
se satisfacen sus requisitos o que la organización los ha
dispone para realizar las pruebas.
identificado para el mercado al que se destina el
software. Esta actividad de pruebas puede incluir o no a Las pruebas de regresión se pueden realizar en cada uno
los desarrolladores del sistema. de los niveles de pruebas descritos en el punto 2.1 El
rra
objeto de la prueba y son válidas tanto para pruebas
2.2.2 Pruebas de instalación
funcionales como no funcionales.
[Per95:c9; Pfl01:c9s8.6]
2.2.7 Pruebas de rendimiento
Normalmente, cuando las pruebas de aceptación han
[Per95:c17; Pfl01:c9s8.3] (Wak99)
terminado, el software se puede comprobar una vez
instalado en el entorno final. Las pruebas de instalación Estas pruebas tienen el objetivo de verificar que el
se pueden ver como pruebas del sistema realizadas en software alcanza los requerimientos de rendimiento
relación con los requisitos de la configuración de especificados, particularmente los de capacidad y
hardware. Los procedimientos para la instalación tiempo de respuesta. Un tipo particular de pruebas de
también se podrían verificar. rendimiento son las pruebas de volumen (Per95:p185,
p487; Pfl01:p401), en los que las limitaciones internas
2.2.3 Pruebas alfa y beta
del programa o sistema se ponen a prueba.
Bo
[Kan99:c13]
2.2.8 Pruebas de desgaste
A veces, antes de poner el software en distribución, éste
[Per95:c17; Pfl01:c9s8.3]
se proporciona a un grupo representativo de usuarios
potenciales para que puedan usarlo en pruebas en las Las pruebas de desgaste hacen funcionar el software a
instalaciones del desarrollador (pruebas alpha) o la máxima capacidad para la que fue diseñado, y por
externamente (pruebas beta). Dichos usuarios notifican encima de ella.
problemas con el producto. Normalmente, el uso de
2.2.9 Pruebas de continuidad.
versiones alfa y beta sucede en entornos no controlados
y no siempre se le hace referencia en los planes de Un grupo de pruebas se ejecuta en dos versiones
pruebas. diferentes de un producto software y los resultados se
comparan.
2.2.4 Pruebas de conformidad/pruebas
funcionales/pruebas de corrección 2.2.10 Pruebas de recuperación
[Kan99:c7; Per95:c8] (Wak99) [Per95:c17; Pfl01:c9s8.3]
Las pruebas de conformidad tienen el objetivo de El objetivo de las pruebas de recuperación es verificar
verificar si el comportamiento del software se la capacidad del software para reiniciarse después de un
corresponde con las especificaciones. ―desastre‖.
2.2.5 Materialización de la confiabilidad y 2.2.11 Pruebas de configuración
evaluación [Lyu96:c7; Pfl01:c9s.8.4] (Pos96) [Kan99:c8; Pfl01:c9s8.3]
En los casos en los que el software se construye para [Kan99:c1]
dar servicio a distintos usuarios, las pruebas de
Quizás la técnica usada más globalmente continúan
configuración analizan el software en las diferentes
siendo las pruebas ad hoc: las pruebas se generan a
configuraciones especificadas.
partir la habilidad, intuición y experiencia en programas
similares del ingeniero de software. Las pruebas ad hoc
2.2.12 Pruebas de facilidad de uso pueden ser útiles para identificar casos de prueba
[Per95:c8; Pfl01:c9s8.3] especiales, aquellos que no se pueden extraer
fácilmente mediante técnicas formales.
Este proceso evalúa lo fácil que le resulta usar y
aprender a usar el software al usuario, incluyendo la 3.1.2 Pruebas por exploración
documentación del usuario, la efectividad de las
Las pruebas por exploración se definen como
funciones del software para soportar las tareas de
aprendizaje, diseño de pruebas y ejecución de pruebas
usuario y, finalmente, la habilidad de recuperarse de
al mismo tiempo. Esto significa que las pruebas no se
errores provocados por el usuario.
definen primero como parte de un plan de pruebas
r
2.2.13 Desarrollo dirigido por pruebas establecido, si no que se diseñan, ejecutan y se
[Bec02] modifican dinámicamente. La efectividad de las
pruebas por exploración se basa en el conocimiento del
El desarrollo dirigido por pruebas no es una técnica en ingeniero de software, que se puede derivar de varias
do
sí misma, pero promociona el uso de pruebas como una
fuentes: el comportamiento observado del producto
parte subordinada al documento de especificación de durante las pruebas, su familiaridad con la aplicación, la
requisitos en vez de una comprobación independiente plataforma o el proceso de fallos, los posibles tipos de
de que el software implementa dichos requerimientos
errores y fallos, el riesgo asociado con un producto en
correctamente. particular, etc. [Kan01:c3]
3 Técnicas de pruebas 3.2 Técnicas basadas en la especificación
Uno de los objetivos de las pruebas es revelar el
3.2.1 Particiones de equivalencia
máximo número posible de fallos potenciales y muchas [Jor02:c7; Kan99:c7]
técnicas se han desarrollado con este objetivo,
intentando ―romper‖ el programa ejecutando una o más El dominio de la entrada de datos se subdivide en
rra
pruebas seleccionadas de un cierto grupo de ejecuciones colecciones de subconjuntos, o clases de equivalencia,
considerado equivalente. El principio subyacente de las cuales se consideran equivalentes de acuerdo con la
estas técnicas es tratar de ser lo más sistemático posible relación especificada. Un grupo representativo de
identificando un conjunto representativo de pruebas (a veces solo uno) se toma de cada clase.
comportamientos del programa; por ejemplo,
3.2.2 Análisis de los valores límite
identificando subclases del dominio de entrada de
[Jor02:c6; Kan99:c7]
datos, de los escenarios, de los estados y del flujo de
datos. Casos de prueba se seleccionan en y cerca de los límites
del dominio de las variables de la entrada de datos,
Es difícil encontrar una base homogénea para clasificar
basándose en la idea de que una gran parte de los
todas las técnicas, por lo que la aquí utilizada debe
errores se concentran cerca de los valores extremos de
entenderse como un compromiso. La clasificación se
Bo
r
3.2.6 Pruebas aleatorias 3.4 Técnicas basadas en errores
[Bei90:c13; Kan99:c7] (Mor90)
do
En este caso las pruebas se generan de una manera Con diferentes niveles de formalización, las técnicas
completamente aleatoria, lo que no debe confundirse basadas en errores idean casos de prueba que están
con las pruebas estadísticas basadas en el perfil especialmente orientados a descubrir categorías de
operativo descritas en el punto 3.5.1 Perfil Operativo. errores probables o predefinidos.
Esta forma de realizar pruebas se incluye en la categoría
3.4.1 Conjeturar errores
de entradas basadas en la especificación, ya que el
[Kan99:c7]
domino de las entradas de datos se debe conocer para
ser capaces de seleccionar elementos aleatorios del En la conjetura de errores, los casos de pruebas se han
mismo. diseñado específicamente por ingenieros de software
intentando imaginar los errores más probables en un
3.3 Técnicas basadas en el código
programa determinado. La historia de errores
rra
3.3.1 Criterio basado en el flujo de control descubiertos en proyectos anteriores es una buena
[Bei90:c3; Jor02:c10] (Zhu97) fuente de información, como lo es también la
experiencia del ingeniero.
Los criterios de cobertura están basados en el flujo de
control se usan para cubrir todos los bloques de código 3.4.2 Pruebas por mutación
o líneas de código individuales o una combinación [Per95:c17; Zhu97:s3.2-s3.3]
especifica de los mismos. Hay varios criterios de
Un mutante es una versión ligeramente modificada de
cobertura propuestos, como cobertura de
un programa al que se le está haciendo pruebas,
condición/decisión. El criterio basado en el flujo de
diferenciándose tan solo en un pequeño cambio
control más efectivo son las pruebas de caminos, cuyo
sintáctico. Cada caso de prueba se aplica al original y a
objetivo es verificar todos los caminos de control de
los mutantes generados: si una prueba consigue
tipo entrada-salida del gráfico de flujos. Como, en
Bo
r
objetivos de las pruebas. Por ejemplo, la cobertura de
3.6 Técnicas basadas en la naturaleza de la aplicación
condiciones es una técnica de pruebas muy popular.
Las técnicas anteriores se pueden aplicar a cualquier tipo Conseguir el valor de la cobertura de condiciones no
do
de software. Sin embargo, para algunos tipos de debería ser un objetivo de las pruebas en sí mismo: es
aplicaciones, es necesario conocimientos específicos solo un medio para mejorar las posibilidades de
adicionales para derivar las pruebas. La siguiente lista encontrar fallos realizando pruebas sistemáticas en cada
proporciona unas cuantas áreas de pruebas condición del programa para un punto de decisiones.
especializadas, basándose en la naturaleza de la Para prevenir dichas interpretaciones erróneas, debería
aplicación que se está comprobando: hacerse una distinción muy clara entre las medidas de las
pruebas, que proporcionan una evaluación del programa
Pruebas Orientadas a Objetos [Jor02:c17; que se está comprobando, basada en los resultados
Pfl01:c8s7.5] (Bin00) observados de las pruebas y aquellas que evalúan la
Pruebas basadas en componentes completitud del conjunto de pruebas. Se proporciona
más información acerca de medidas para programas en el
rra
Pruebas para Internet KA de la Gestión del la Ingeniería del Software, punto 6,
Pruebas para GUI [Jor20] Medidas en la ingeniería del software. Se puede
encontrar más información en el KA de la Gestión del la
Pruebas para programas concurrentes (Car91) Ingeniería del Software, punto 4, Proceso y medidas del
producto.
Pruebas de conformidad de protocolos (Pos96;
Boc94) Las medidas se consideran, normalmente, como
esenciales en los análisis de calidad. Las medidas
Pruebas para sistemas de tiempo real (Sch94) también se pueden utilizar para optimizar la
Pruebas para sistemas de seguridad crítica planificación y ejecuciones de las pruebas. La gestión de
(IEEE1228-94) pruebas puede utilizar varios procesos para medir o
vigilar el progreso realizado. Las medidas relacionadas
Bo
r
cualquier extrapolación. Algunos incluso afirman que
Un programa que se está comprobando se puede valorar
esta técnica debería usarse con sumo cuidado, ya que
contando y clasificando los errores descubiertos por su
introducir errores en el software acarrea el riesgo obvio
tipo. Parra cada tipo de error, la densidad de errores se
de olvidarlos allí.
do
mide como la razón entre el número de errores
encontrados y el tamaño del programa. 4.2.3 Puntuación de la mutación
[Zhu97:s3.2-s3.3]
4.1.4 Vida de las pruebas, evaluación de
confiabilidad En las pruebas por mutación (véase el punto 3.4.2), la
[Pfl01:c9] (Pos96:p146-154) razón de mutantes matados por número total de mutantes
generados puede ser una medida de la efectividad del
Una estimación estadística de la confiabilidad del
conjunto de pruebas realizadas.
software, que se puede conseguir mediante la realización
y evaluación de la confiabilidad (véase punto 2.2.5), se 4.2.4 Comparación y efectividad relativa de las
puede usar para evaluar un producto y decidir si las diferentes técnicas
pruebas se pueden detener o no. [Jor02:c9, c12; Per95:c17; Zhu97:s5] (Fra93;
rra
Fra98; Pos96: p64-72)
4.1.5 Modelos de crecimiento de la confiabilidad
[Lyu96:c7; Pfl01:c9] (Lyu96:c3, c4) Se han llevado a cabo varios estudios para comparar la
efectividad relativa de las diferentes técnicas de pruebas.
Los modelos de crecimiento de la confiabilidad
Es importante ser preciso acerca de la propiedad contra
proporcionan una predicción de confiabilidad basada en
la cual las técnicas se han calificado; ¿cual, por ejemplo,
los fallos observados durante la realización y evaluación
es el significado exacto dado al término ―efectividad‖?
de la confiabilidad (véase punto 2.2.5). Estos modelos
Las interpretaciones posibles son: el número de pruebas
asumen, en general, que los errores que causan los fallos
necesarias para encontrar el primer fallo, la razón entre
observados se han arreglado (aunque algunos modelos
el número de errores encontrados durante las pruebas y
también aceptan arreglos imperfectos), y por tanto, el
todos los errores encontrados durante y después de las
producto muestra una confiabilidad incremental de
pruebas, o cual fue la mejora de la confiabilidad. Se han
Bo
r
riego, que usa los riesgos en el producto para asignar proceso
prioridad y centrar la atención de las estrategias de [Per95:c4, c21] (Per95: Appendix B;
pruebas; o en las pruebas basadas en situaciones, en las Pos96:p139-145; IEEE982.1-88)
do
que los casos de pruebas se definen y basan en
Los jefes de proyectos pueden usar varias medidas,
escenarios de software especificados.
acerca de los recursos invertidos en las pruebas y de la
5.1.3 Gestión del proceso de las pruebas efectividad de las varias fases de pruebas en encontrar
[Bec02: III; Per95:c1-c4; Pfl01:c9] (IEEE1074- fallos, para controlar y mejorar el proceso de las pruebas.
97; IEEE12207.0-96:s5.3.9, s5.4.2, s6.4, s6.5) Estas medidas de las pruebas pueden cubrir, entre otros,
aspectos como el número de casos de pruebas
Las actividades de pruebas realizadas a diferentes niveles
especificados, el número de casos de pruebas ejecutados,
(véase punto 2, Niveles de pruebas) se deben organizar,
el número de casos de pruebas superados y el número de
junto con las personas, herramientas, normas y medidas,
casos de pruebas no superados.
en un proceso bien definido que será una parte integral
del ciclo de vida del software. En el estándar IEEE/EIA La evaluación de los informes de las fases de pruebas se
rra
12207.0, las pruebas no se describen como un proceso puede combinar con análisis de las raíces de las causas
independiente, si no que los principios de las actividades para evaluar la efectividad del proceso de las pruebas en
de las pruebas se encuentran incluidos con los cinco encontrar errores tan pronto como sea posible. Dicha
procesos primarios del ciclo de vida y con los procesos evaluación se puede asociar con el análisis de riesgos. Lo
de soporte. En el estándar IEEE 1074, las pruebas se que es más, los recursos que merece la pena invertir en
agrupan con otras actividades de evaluación como una las pruebas deberían ser proporcionales al
parte integral del ciclo de vida completo. uso/importancia de la aplicación: diferentes técnicas
tienen distinto coste y proporcionan diferentes niveles de
5.1.4 Documentación y productos de las pruebas
seguridad en la confiabilidad del producto.
[Bei90:c13s5; Kan99:c12; Per95:c19;
Pfl01:c9s8.8] (IEEE829-98) 5.1.7 Finalización
[Bei90:c2s2.4; Per95:c2]
Bo
r
En este punto, se verá una pequeña introducción a las
los resultados inesperados son necesariamente errores, ya
actividades del software; gestionar con éxito las
que se podría considerar que algunos son simple ruido.
actividades relacionada con las pruebas, como la
Antes de que se pueda arreglar un error, se necesita
siguiente descripción da a entender, depende en gran
do
realizar un análisis y algún trabajo de depuración para
medida del proceso de Gestión de Configuración del
identificarlo, aislarlo y describirlo. Cuando los resultados
Software.
de las pruebas son particularmente importantes, puede
5.2.1 Planificación que se convoque una revisión formal para evaluarlas.
[Kan99:c12; Per95:c19; Pfl01:c8s7.6]
5.2.6 Notificación de problemas/Diario de pruebas
(IEEE829-98:s4; IEEE1008-87:s1-s3)
[Kan99:c5; Per95:c20] (IEEE829-98:s9-s10)
Como cualquier otro aspecto de la gestión de proyectos,
Las actividades de las pruebas se pueden añadir a un
las actividades de las pruebas se deben planificar.
diario de pruebas para identificar cuando una prueba se
Algunos aspectos clave de la planificación de las pruebas
ha ejecutado, quien la ha realizado, que configuración
incluyen la coordinación de personal, la gestión de
del software se ha utilizado y cualquier otra información
rra
instalaciones y equipos disponibles (que pueden incluir
relevante de identificación. Resultados inesperados o
soportes magnéticos, planes de pruebas y
incorrectos se pueden añadir a un sistema de notificación
procedimientos) y planificar en caso de posibles
de problemas, cuyos datos serán la base para procesos de
situaciones no deseables. Si se mantiene más de una
depuración posteriormente y para arreglar los errores que
línea base del software al mismo tiempo, una importante
causaron problemas durante las pruebas. Las anomalías
consideración de planificación es el tiempo y esfuerzo
no clasificadas como errores también se podrían
necesario para asegurarse de que se ha usado la
documentar, en caso de que más tarde resulte que
configuración correcta para establecer el entorno de
producen problemas más serios de lo que se pensó
pruebas.
originalmente. Los informes de pruebas también son una
5.2.2 Generación de casos de pruebas entrada para los procesos de requerimientos de cambió
[Kan99:c7] (Pos96:c2; IEEE1008-87:s4, s5) de gestión (véase el KA de la Gestión de la
Bo
r
Efectividad de las Pruebas/
Objetivos de las Pruebas c1s1.4 c21
Realizar pruebas para la
c1 c1
do
identificación de defectos
El problema del oráculo c1
Limitaciones teóricas y prácticas
de las pruebas c2
El problema de los caminos no
alcanzables c3
Posibilidad de hacer pruebas c3, c13
1.3 Relación de las pruebas con
otras actividades
2. Niveles de Pruebas
rra
2.1El objeto de la prueba c1 c13 c8
Pruebas de Unidad c1 c17 c8s7.3
Materialización de la confiabilidad
y evaluación
c7 c9s8.4
r
Estado Finito c11 c8
Basadas en las
especificaciones formales s2.2
do
Pruebas aleatorias c13 c7
3.3 Basadas en el código
Criterio basado en el Flujo de
Control c3 c10 c8
Criterio basado en el Flujo de
Datos c5
Modelos de referencia para
pruebas basadas en código c3 c5
Pruebas Orientadas a la
Confiabilidad del Software
c6
r
la Confiabilidad c7 c9
do
Medidas de la
cobertura/completitud c9 c8
Introducción de errores c8
Finalización c2s2.4 c2
Reutilización de pruebas y
patrones de pruebas c13s5
r
do
rra
Bo
APÉNDICE A. LISTA DE LECTURAS (Kan99) C. Kaner, J. Falk, and H.Q. Nguyen, ―Testing
ADICIONALES Computer Software,‖ second ed., John Wiley & Sons,
1999.
(Bac90) R. Bache and M. Müllerburg, ―Measures of
Testability as a Basis for Quality Assurance,‖ Software (Lyu96) M.R. Lyu, Handbook of Software Reliability
Engineering Journal, vol. 5, March 1990, pp. 86-92. Engineering, Mc-Graw-Hill/IEEE, 1996.
(Bei90) B. Beizer, Software Testing Techniques, (Mor90) L.J. Morell, ―A Theory of Fault-Based
International Thomson Press, second ed., 1990. Testing,‖ IEEE Transactions on Software Engineering,
vol. 16, iss. 8, August 1990, pp. 844-857.
(Ber91) G. Bernot, M.C. Gaudel and B. Marre,
―Software Testing Based On Formal Specifications: a (Ost88) T.J. Ostrand and M.J. Balcer, ―The Category-
Theory and a Tool,‖ Software Engineering Journal, Partition Method for Specifying and Generating
Nov. 1991, pp.387-405. Functional Tests,‖ Communications of the ACM, vol. 31,
iss. 3, June 1988, pp. 676-686.
(Ber96) A. Bertolino and M. Marrè, ―How Many Paths
Are Needed for Branch Testing?‖ Journal of Systems (Ost98) T. Ostrand, A. Anodide, H. Foster, and T.
Goradia, ―A Visual Test Development Environment for
r
and Software, vol. 35, iss. 2, 1996, pp. 95-106.
GUI Systems,‖ presented at ACM Proc. Int’l Symp. On
(Ber96a) A. Bertolino and L. Strigini, ―On the Use of Software Testing and Analysis (ISSTA ‘98), Clearwater
Testability Measures for Dependability Assessment,‖ Beach, Florida, 1998.
do
IEEE Transactions on Software Engineering, vol. 22,
iss.2, Feb. 1996, pp. 97-108. (Per95) W. Perry, Effective Methods for Software
Testing, John Wiley & Sons, 1995.
(Bin00) R.V. Binder, Testing Object-Oriented Systems
Models, Patterns, and Tools, Addison-Wesley, 2000. (Pfl01) S.L. Pfleeger, Software Engineering: Theory and
Practice, second ed., Prentice-Hall, 2001, Chap. 8, 9.
(Boc94) G.V. Bochmann and A. Petrenko, ―Protocol
Testing: Review of Methods and Relevance for Software (Pos96) R.M. Poston, Automating Specification-Based
Testing,‖ presented at ACM Proc. Int’l Symp. on Software Testing, IEEE, 1996.
Software Testing and Analysis (ISSTA ‘94), Seattle, (Rot96) G. Rothermel and M.J. Harrold, ―Analyzing
Wash., 1994. Regression Test Selection Techniques,‖ IEEE
(Car91) R.H. Carver and K.C. Tai, ―Replay and Testing Transactions on Software Engineering, vol. 22, iss. 8,
rra
for Concurrent Programs,‖ IEEE Software, March 1991, Aug. 1996, p. 529.
pp. 66-74. (Sch94) W. Schütz, ―Fundamental Issues in Testing
(Dic93) J. Dick and A. Faivre, ―Automating the Distributed Real-Time Systems,‖ Real-Time Systems
Generation and Sequencing of Test Cases from Model- Journal, vol. 7, iss. 2, Sept. 1994, pp. 129-157.
Based Specifications,‖ presented at FME ’93: (Voa95) J.M. Voas and K.W. Miller, ―Software
Industrial-Strength Formal Methods, LNCS 670, Testability: The New Verification,‖ IEEE Software, May
Springer-Verlag, 1993. 1995, pp. 17-28.
(Fran93) P. Frankl and E. Weyuker, ―A Formal Análisis (Wak99) S. Wakid, D.R. Kuhn, and D.R. Wallace,
of the Fault Detecting Ability of Testing Methods,‖ ―Toward Credible IT Testing and Certification,‖ IEEE
IEEE Transactions on Software Engineering, vol. 19, Software, July-Aug. 1999, pp. 39-47.
iss. 3, March 1993, p. 202.
Bo
r
IEEE, 1993.
(IEEE1228-94) IEEE Std 1228-1994, Standard for
Software Safety Plans, IEEE, 1994.
do
(IEEE12207.0-96) IEEE/EIA 12207.0-1996 //
ISO/IEC12207:1995, Industry Implementation of Int.
Std. ISO/IEC 12207:95, Standard for Information
Technology-Software Life Cycle Processes, IEEE, 1996.
rra
Bo
Bo
rra
do
r
CAPITULO 6
MANTENIMIENTO DEL SOFTWARE
ACRÓNIMOS logística para actividades de transición. Las
actividades de postentrega incluyen la
modificación de software, el entrenamiento, y el
CMMI Capability Maturity Model Integration
funcionamiento del help desk.
ICSM International Conference on Software
El Mantenimiento de Software KA está
Maintenance
relacionado con otros aspectos de ingeniería de
SCM Software Configuration Management
software. Por lo tanto, esta descripción KA está
SQA Software Quality Assurance
vinculada a otros capítulos de la Guía.
V&V Verification and Validation
Y2K Year 2000
r
DESGLOSE DE PUNTOS DEL
MANTENIMIENTO DEL SOFTWARE
do
INTRODUCCIÓN:
El desglose de los puntos del Mantenimiento de
Los esfuerzos de desarrollo de software dan Software KA se muestra en la Figura 1.
como resultado la entrega de un producto de
software que satisfaga las exigencias del 1. Fundamentos de mantenimiento de
usuario. software
Como consecuencia el producto de software
debe cambiarse o desarrollarse. Una vez en la Esta primera sección presenta los conceptos y la
operación, los defectos son destapados y terminología que forman una base subyacente a
emergen las nuevas exigencias del usuario. la comprensión de la función y el alcance de
La fase de mantenimiento del ciclo de vida mantenimiento de software. Los puntos
rra
comienza después de un período de garantía proporcionan definiciones y enfatizan por qué
pero las actividades de mantenimiento ocurren existe la necesidad de mantenimiento. Las
mucho antes. categorías del mantenimiento de software son
críticas a la comprensión de su significado
El mantenimiento de software es una parte del subyacente.
ciclo de vida de software. Sin embargo,
históricamente, no ha recibido el mismo grado 1.1. Definiciones y Terminología.
de atención que otras fases del ciclo de vida. [IEEE1219-98:s3.1.12; IEEE12207.0-
Históricamente, el desarrollo de software ha 96:s3.1,s5.5;ISO14764-99:s6.1]
tenido un perfil mucho más alto que el
mantenimiento de software en la mayor parte de El Mantenimiento de Software se define en el
organizaciones. estándar IEEE para Mantenimiento de Software,
Bo
r
el código y otros artefactos de software son Actividades de Mantenimiento.
modificados, las pruebas son conducidas, y una
nueva versión del producto de software es Los mantenedores pueden aprender del
do
liberada. Proporcionan también, entrenamiento conocimiento del desarrollo del software.
y el apoyo a los usuarios. Pfleeger [Pfl01] Ponerse en contacto con los desarrolladores y la
declara que " el mantenimiento tiene un más temprana participación por el mantenedor ayuda
amplio alcance para rastrear y controlar que el a reducir el esfuerzo de mantenimiento.
desarrollo‖. Un mantenedor es definido por el
Mantenimiento del
Software
rra
Fundamentos de Problemas clave en Técnicas de
Proceso de Mantenimiento
Mantenimiento del Mantenimiento de
Mantenimiento
Software Software
Mantenimiento
Actividades de
Mantenimiento
Necesidad de Distribución de
Ingeniería
Mantenimiento los
Inversa
componentes
Categorías de
Mantenimiento
r
El mantenimiento es aplicable al software desarrollado Características de Hardware
usando cualquier modelo de ciclo de vida de software La Calidad de diseño del software,
(por ejemplo, en espiral). El sistema se cambia debido a construcción, documentación y pruebas
do
acciones de software correctivas y no correctivas.
El mantenimiento debe ser realizado para:
Corregir defectos 1.5. Evolución de Software
Mejorar el diseño [Art88:c1s1.0, s1.1, s1.2, c11s1.1, s1.2; Leh97:108-
Llevar a la práctica las mejoras 124], (Bel72)
El interfaz con otros sistemas
Adapta programas con diferente hardware Lehman abordó por primera vez el mantenimiento
diferente, software, características del sistema, e del software y
instalaciones de telecomunicaciones para que la evolución de los sistemas en 1969. Durante un período
puedan ser usados de veinte años, sus investigaciones condujeron a la
Emigra software
rra
formulación de ocho "Leyes de
Retira el software Evolución‖. [Leh97] Las principales conclusiones
incluyen el hecho de que
Las actividades del mantenedor comprenden cuatro el mantenimiento es una novedad evolutiva y que ayuda
características claves, según Pfleeger [Pfl01]: a decisiones de mantenimiento entendiendo lo que le
Mantenimiento de control de las funciones pasa a los sistemas (y el software) con el tiempo. Otros
cotidianas del software declaran que el mantenimiento es un desarrollo
Mantenimiento de control de modificación de continuado, pero hay una entrada extra- la existencia de
software software grande que nunca se completa y sigue
Perfeccionando funciones existentes desarrollándose. Como esto se desarrolla, se hace más
Impedir la degradación del funcionamiento de complejo a no ser que alguna acción sea tomada para
software a niveles inaceptables reducir esta complejidad.
Bo
r
para detectar y corregir fallos latentes en el son documentados y cuando los desarrolladores no están
producto de software antes de que se conviertan disponibles para explicarlo, que es a menudo el caso.
en fallos reales.
do
2.1.2. Pruebas
ISO/IEC 14764 clasifica el mantenimiento adaptativo y [Art88:c9; Pfl01:c11s11.3]
perfectivo como mejoras. Agrupa el mantenimiento
correctivo y preventivo en una categoría de corrección, El coste de repetir pruebas sobre un pedazo principal de
como se muestra en la tabla 1. El mantenimiento software puede ser significativo en términos de tiempo y
preventivo, la categoría más reciente, a menudo es dinero.
realizado sobre productos de software donde la Las pruebas de regresión, las nuevas pruebas selectivas
seguridad es crítica. de un software o el componente para verificar que las
modificaciones no han causado efectos no planeados,
Correction Enhancement son importantes para el mantenimiento. Existe también
Corrección Mejoras el desafío de coordinar pruebas cuando los miembros del
rra
Proactiva Preventivo Perfectivo equipo de mantenimiento trabajan sobre problemas
Reactiva Correctivo Adaptativo diferentes al mismo tiempo. [Plf01] Cuando el software
realiza funciones críticas, puede ser imposible llevarlo
fuera de línea para probar.
Tabla 1: Categorías del Mantenimiento del Software Las pruebas de software KA proporciona la información
adicional y se refiere a dicha materia en su punto 2.2.6
2. Los Problemas claves en el Mantenimiento de pruebas de Regresión.
Software
2.1.3. Análisis de impacto
Un número de problemas claves deben ser tratados para [Art88:c3; Dor02:v1c9s1.10; Pfl01: C11s11.5]
asegurar el mantenimiento eficaz de software. Es
Bo
importante que entienda que el mantenimiento del El análisis de Impacto describe como conducir,
software provee desafíos de dirección para los ingenieros con rentabilidad, un análisis completo del impacto de un
del software. La tentativa de encontrar un defecto en las cambio del software existente. Los mantenedores deben
500K líneas de código del software que el ingeniero de poseer un conocimiento íntimo de la estructura del
software no desarrolló es un buen ejemplo. Asimismo software y el contenido [Pfl01]. Usan aquel
competir con los desarrolladores del software por los conocimiento para realizar el análisis de impacto, que
recursos es una batalla constante. identifica todos los sistemas y los productos de software
La planificación para una futura liberación, cifrando la afectados por un cambio de software solicitado y se
siguiente liberación y enviando parches de la emergencia desarrolla una estimación de los recursos para llevar a
para la liberación corriente, también crea un desafío. La cabo el cambio. [Art88] Además, el riesgo de hacer el
sección siguiente presenta técnicas y cuestiones de cambio es determinado.
dirección relacionadas con el mantenimiento del La petición de cambio, a veces llama a una petición de
software. Han sido agrupadas bajo los títulos siguientes: modificación (MR) y a menudo llama un informe del
Cuestiones Técnicas problema (PR), primero debe ser analizada y traducida
Cuestiones de Dirección en términos de software. Es realizado después de que
Coste estimado y una petición de cambio entra en el proceso de dirección
Medidas de configuración de software. Arthur [Art88] declara que
los objetivos de análisis de impacto son:
2.1. Cuestiones Técnicas La determinación del alcance de un cambio para
planificar y poner en práctica el trabajo
El desarrollo de las estimaciones exactas de El énfasis principal debe entregar a tiempo y
recursos que tuvo que realizar el trabajo dentro del presupuesto para encontrar necesidades de
El análisis del perdidas/beneficio del cambio usuario. Al contrario el mantenimiento de software a
solicitado menudo tiene el objetivo de ampliar la vida de software
La comunicación de la complejidad de un tanto como sea posible. Además, pueden conducirlo la
cambio dado necesidad de encontrar la demanda de usuario de
actualizaciones de software y mejoras.
La severidad de un problema a menudo se usa para En ambos casos, el rendimiento de la inversión
decidir cómo y cuando un problema será fijado. El es mucho menos claro, de modo que la opinión en el
ingeniero del software entonces identifica los nivel de dirección sea a menudo de una actividad
componentes afectados. Proporcionando varias principal que consume recursos significativos sin la
soluciones potenciales y luego una recomendación ventaja clara cuantificable para la organización. "
hecha en cuanto al mejor curso de acción. 2.2.2. Proveer de personal
El software diseñado con la capacidad de mantenimiento [Dek92:10-17; Dor02:v1c9s1.6; Par86: C4s8-
en mente facilita enormemente el análisis de impacto. c4s11] (Lie81)
r
Para más información en la Dirección de Configuración
de Software KA. El proveer de personal se refiere a como atraer y
mantener el personal de mantenimiento de software. El
do
2.1.4. Capacidad de mantenimiento [ISO14764- mantenimiento no es visto a menudo como un trabajo
99:s6.8s6.8.1; Pfl01: C9s9.4; ¿Pig97:c16] encantador. Deklava proporciona una lista de problemas
relacionados con el personal, basados en datos de
¿Cómo uno promueve y lleva a cabo cuestiones de revisión. [Dek92] Por consiguiente, el personal de
capacidad de mantenimiento durante el desarrollo? El mantenimiento de software con frecuencia es visto como
IEEE [IEEE610.12-90] define la capacidad de " ciudadanos de segunda clase " (Lie81) y la moral por lo
mantenimiento como la facilidad por la cual el software tanto se ve afectada. [Dor02]
puede ser mantenido, mejorado, adaptado, o corregido
para satisfacer exigencias especificadas. ISO/IEC define
la capacidad de mantenimiento como una de las 2.2.3. Proceso
características de calidad (ISO9126-01). [Pau93; Ben00:c6sb; Dor02:v1c9s1.3]
rra
Las subcaracterísticas de capacidad de El proceso de Software es un juego de
mantenimiento deben ser especificadas, repasadas, y actividades, métodos, prácticas, y las transformaciones
controladas durante las actividades de desarrollo de que pueblan el empleo para desarrollar y mantener el
software para reducir costes de mantenimiento. Si esto se software y los productos asociados. [Pau93] En el nivel
hace satisfactoriamente, la capacidad de mantenimiento de proceso, las actividades de mantenimiento de
del software se mejorará. Esto es a menudo difícil de software comparten mucho en común con el desarrollo
alcanzar porque las subcaracterísticas de capacidad de de software (por ejemplo, la dirección de configuración
mantenimiento no son un foco importante durante el de software es una actividad crucial en ambos). [Ben00]
proceso de desarrollo de software. Los desarrolladores el Mantenimiento también requiere varias actividades
están preocupados por muchas otras cosas y a menudo que no son encontradas en el desarrollo de software
Bo
desatienden las exigencias del mantenedor. Esto a su (mirar la sección 3.2 sobre actividades únicas para
modo, y a menudo hace que pueda causar una carencia detalles). Estas actividades presentan desafíos a la
de documentación de sistema, que es una causa principal dirección. [Dor02]
de dificultades en la comprensión de programa y el
análisis de impacto. También se observa que la presencia
de los procesos, técnicas, e instrumentos ayudan a 2.2.4. Los aspectos de organización de mantenimiento
mejorar la capacidad de mantenimiento de un sistema. [Pfl01:c12s12.1-c12s12.3; Par86:c4s7;
Pig97:c2s2.5; Tak97:c8]
r
Las grandes corporaciones externalizan las carteras mantenimiento es el de combinar datos empíricos y
enteras de sistemas de software, incluyendo el experiencia. Deberían proporcionar estos datos como
mantenimiento de software. Más a menudo, la opción de consecuencia del uso de un programa de medida.
do
externalización es elegida para software menos crítico,
como las empresas no están dispuestas a perder el
control del software usado en su negocio esencial. Carey
(Car94) relata que unos externalizarán sólo si ellos 2.4. Medidas de Mantenimiento del Software
pueden encontrar los modos de mantener el control [IEEE1061-98:A.2; Pig97:c14s14.6; Gra87;
estratégico. Sin embargo, las medidas de control son Tak97:C6s6.1-c6s6.3]
difíciles de encontrar. [Dor02] Otro desafío identificado Grady y Caswell [Gra87] hablan del establecimiento de
es la transición del software al subcontratado. [Pig97] un programa de medida de software extensamente
corporativo, en el cual son descritas las formas de
medida de mantenimiento de software y la colección de
2.3 Estimación del coste del mantenimiento. datos. El Software Práctico y la Medida de Sistemas
rra
(PSM) describen un proceso de medida que es usado por
Los ingenieros de Software deben entender las muchas organizaciones y es bastante práctico. [McG01].
diferentes categorías de mantenimiento de software, para
dirigir la pregunta de estimar el coste de mantenimiento Hay medidas de software que son comunes a
de software. Para planificar objetivos, estimar gastos es todos los esfuerzos, las categorías siguientes se han
un aspecto importante de mantenimiento de software. identificado por el Instituto de Ingeniería de Software
(SEI): tamaño; esfuerzo; programa; y calidad. [Pig97]
2.3.1. Valoración de coste Estas medidas constituyen un buen punto de partida para
[Art88:c3; Boe81:c30; Jon98:c27; el mantenedor. La discusión de proceso y la medida de
Pfl01:c11s11.3;Pig97:c8] producto están presentes en el Proceso de Ingeniería de
Software KA. El programa de medida de software está
Bo
Este punto fue mencionado en el subasunto 2.1.3, el descrito en la Dirección de Ingeniería del Software KA.
Análisis de Impacto, aquel análisis de impacto identifica
todos los sistemas y los productos de software afectados
por la solicitud de un cambio de software y por tanto se 2.4.1. Medidas Específicas
desarrolla una estimación de los recursos que tuvo que [Car90:s2-s3; IEEE1219-98:Table3;
utilizar para lograr aquel cambio. sta94:p239-249] Abran [Abr93]
[Art88] las estimaciones de Coste de mantenimiento Presentan técnicas de prueba de referencia internas para
están afectadas por muchos factores técnicos y no comparar diferentes organizaciones de mantenimiento
técnicos. ISO/IEC14764 declara que " los dos accesos internas.
más populares a la estimación de recursos para el El mantenedor debe determinar qué medidas son
mantenimiento de software son el empleo de modelos apropiadas por la organización en cuestión. [Ieee1219-
paramétricos y el empleo de experiencia " [ISO14764- 98; ISO9126-01; Sta94] sugiere que medidas son más
99:s7.4.1]. Lo q más a menudo se usa es una específicas a programas de medida de mantenimiento de
combinación de ambas. software.
2.3.2. Modelos paramétricos La lista incluye un número de medidas para cada una de
[Ben00:s7; Boe81:c30; Jon98:c27; las cuatro subcaracterísticas de capacidad de
Pfl01:c11s11.3] mantenimiento:
Algunos trabajos se han emprendido en la aplicación del Analizar: Las medidas del esfuerzo del
coste paramétrico que modela al mantenimiento de mantenedor o recursos gastados en tentativa de
diagnosticar carencias o causas de fracaso, o en Figura 2 las Actividades de Proceso de Mantenimiento
identificación de partes para ser modificadas IEEE1219-98
Variabilidad: Las medidas del esfuerzo del
mantenedor asociado con realización de una ISO/IEC 14764 [ISO14764-99] es una elaboración del
modificación especificada proceso de mantenimiento IEEE/EIA 12207.0-96. Las
Estabilidad: Las medidas del comportamiento actividades del proceso de mantenimiento ISO/IEC son
inesperado de software, incluyendo lo similares a aquellas del IEEE, pero están agregadas de
encontrado durante las pruebas manera diferente. Las actividades de proceso de
Testeabilidad: Las medidas del esfuerzo del mantenimiento desarrolladas por ISO/IEC se muestran
mantenedor y usuarios en la tentativa de probar en la Figura 3.
el software modificado.
Ciertas medidas de la capacidad de mantenimiento de Proceso de
Implementación
software pueden obtenerse usando instrumentos
comerciales disponibles. (Lag96; Apr00)
r
3. El Proceso de Mantenimiento
Revisión de
Problema y Análisis Mantenimiento/
de Modificación Aceptación
La subárea Proceso de Mantenimiento proporciona
do
referencias y normas para poner en práctica el proceso de
mantenimiento de software. El punto de Actividades de Modificación
14764. La Migración
El modelo de proceso de mantenimiento descrito en el
El Retiro de Software
Estándar para el Mantenimiento de Software (IEEE1219)
comienza con el esfuerzo de mantenimiento de software
Takang y Grubb [Tak97] proporcionan una historia de
durante la etapa de postentrega y habla de artículos como
modelos de proceso de mantenimiento que conducen
la planificación para el mantenimiento. Aquel proceso es
hasta el desarrollo del IEEE y modelos de proceso de
representado en la Figura(el Número) 2.
ISO/IEC. Parikh [Par86] también da una descripción
buena de un proceso de mantenimiento genérico.
Identificación Análisis Recientemente, han surgido metodologías ágiles que
y Clasificación promueven procesos ligeros. Esta exigencia surge de la
Petición de
modificación Diseño demanda cada vez mayor de la vuelta rápida de servicios
de mantenimiento. Algunos experimentos con el
Entrega
mantenimiento Extremo son presentados en (Poo01).
r
Hay un número de procesos, actividades, y prácticas que subasunto 2.1.3 Análisis de Impacto para detalles). La
son únicas al mantenimiento de software, por ejemplo: liberación/versión que planifica la actividad requiere que
Transición: una secuencia controlada y el mantenedor [ITI01]:
do
coordinada de actividades durante las cuales el Reúna las fechas de disponibilidad de las
software es transferido cada vez más del solicitudes de los individuos.
desarrollador al mantenedor [Dek92, Pig97] Esté de acuerdo con usuarios sobre el contenido
La Aceptación/Rechazo de Petición de de liberaciones/versiones subsecuentes
Modificación: el trabajo de petición de Identifique conflictos potenciales y desarrolle
modificación sobre un cierto alternativas
tamaño/esfuerzo/complejidad puede ser Evalúe el riesgo de una liberación dada y
rechazado por mantenedores y desviado a un desarrolle un plan echarse atrás en caso de los
desarrollador [Dor02], (Apr01) problemas deberían surgir
La petición de Modificación y el Escritorio de Informe a todos los tenedores de apuestas
Ayuda de Informe de Problema: una función de
rra
apoyo de usuario final que provoca la Mientras que los proyectos de desarrollo de software
evaluación, la ordenación, y de presupuesto de típicamente pueden durar a partir de algunos meses a
solicitud de modificación [Ben00] algunos años, la fase de mantenimiento por lo general
El Análisis de Impacto (mirar la sección 2.1.3 dura muchos años. La fabricación de las estimaciones de
para detalles) recursos es un elemento clave de planificación de
El Apoyo de Software: ayuda y aconseja a mantenimiento. Los recursos deberían ser incluidos en
usuarios que solicitan información (por los presupuestos de proyecto que planifican los
ejemplo, reglas de gestión, validación, datos desarrolladores. La planificación de mantenimiento de
que quieren decir y ad hoc solicita/hace un software debería comenzar con la decisión de desarrollar
informe) un nuevo sistema y debería considerar objetivos de
Los Acuerdos de Nivel de Servicio (SLAs) y calidad (IEEE1061-98). Un documento de concepto
Bo
los contratos de mantenimiento especializados debería ser desarrollado, seguido por un plan de
(específicos de dominio) que son mantenimiento.
responsabilidad de los mantenedores (Apr01) El documento de concepto para el mantenimiento
[iso14764-99:s7.2] debe dirigirse a:
3.2.2. Apoyando actividades el alcance del mantenimiento de software.
[IEEE1219-98:A.7, 11 un ; IEEE12207.0-96:c6, la adaptación del mantenimiento de software
c7;ITI01; Pig97:c10s10.2, c18]; (Kaj01) la identificación de la organización de
mantenimiento de software
Los mantenedores también puede realizar actividades de una estimación de costes de mantenimiento de
apoyo, como la planificación de mantenimiento de
software
software, la dirección de configuración de software, la
verificación y la validación, la garantía de calidad de El siguiente paso debe desarrollar el correspondiente
software, revisiones, revisiones de cuentas, y el
plan de mantenimiento de software. Este plan debería
entrenamiento de usuario.
estar preparado durante el desarrollo de software, y
Otra actividad de apoyo, entrenamiento del mantenedor, debería especificar como los usuarios solicitarán
también es necesaria. [Pig97; IEEE12207.0-96] (Kaj01)
modificaciones de software o relatarán problemas.
El plan de mantenimiento de software [Pig97] es dirigido
3.2.3. Actividad de planificación de mantenimiento. en IEEE 1219 [IEEE1219-98] Y ISO/IEC 14764.
[IEEE1219-98:A.3; ISO14764-99:s7;
[ISO14764-99] ISO/IEC14764 proporciona directrices
ITI01;Pig97:c7, c8]
para un plan de mantenimiento.
Finalmente, en el nivel más alto, la organización de [ISO14764-99] Más detalles pueden ser
mantenimiento tendrá que conducir actividades de encontrados en la Calidad de Software KA.
planificación de business (recursos presupuestarios,
financieros, y humanos) justo como todas las otras 4. Las técnicas para el Mantenimiento
divisiones de la organización. El conocimiento de Este subárea introduce algunas técnicas
dirección requerido para hacer esto se puede encontrar generalmente aceptadas usadas en el mantenimiento de
en el capítulo de Disciplinas Relacionadas de Ingeniería software.
del Software.
4.1. Comprensión de Programa
3.2.4. Dirección de configuración de software [Arn92:c14; Dor02:v1c9s1.11.4; Tak97:c3]
[Art88:c2, c10; IEEE1219-98:A.11;
ieee12207.0-96:s6.2; Pfl01:c11s11.5; Tak97:c7] Los Programadores gastan un tiempo
considerable en la lectura y el entendimiento de
El Estándar IEEE para el Mantenimiento de programas para poner en práctica los cambios.
Software, IEEE 1219 [IEEE1219-98], describe la Los navegadores de código son instrumentos claves para
r
dirección de configuración de software como un la comprensión de programa.
elemento crítico del proceso de mantenimiento. Los La documentación clara y concisa puede ayudar en la
procedimientos de dirección de configuración de comprensión de programa
do
software deberían asegurar la verificación, la validación,
y la revisión de cuentas de cada paso requerido para 4.2. Reingeniería
identificar, autorizar, poner en práctica, y liberar el [Arn92:c1, c3-c6; Dor02:v1c9s1.11.4;
producto de software. IEEE1219-98:La b 2], (Fow99)
Configuración para determinar el contenido de la sus relaciones mutuas y crear las representaciones del
siguiente liberación/versión. software en otra forma o en los niveles más altos de
abstracción. La ingeniería de revés es pasiva; esto no
3.2.5. Calidad de software cambia el software, o causa el nuevo software. Los
[Art98:c7s4; IEEE12207.0-96:s6.3; ieee1219- esfuerzos de la ingeniería del revés producen gráficos de
98:A.7; ISO14764-99:s5.5.3.2] llamada y gráficos de flujo de control del código
No es suficiente, tampoco, simplemente esperar lo que original. Un tipo de ingeniería de revés es la nueva
aumentó la calidad sea resultado del mantenimiento de documentación. Otro tipo es la recuperación de diseño
software. Debe ser planificado y procesos puestos en [Dor02]. La nueva factorización es la transformación de
práctica para apoyar el proceso de mantenimiento. Las programa que reorganiza un programa sin cambiar su
actividades y técnicas para la Garantía de calidad de comportamiento, y es una forma de revés que procura
Software (SQA), V*V, revisiones, y revisiones de mejorar la estructura de programa. (Fow99).
cuentas deben ser seleccionadas de común acuerdo con
todos los otros procesos para alcanzar el nivel deseado Finalmente, la ingeniería de revés de datos ha
de calidad. También le recomiendan que el mantenedor ganado en importancia durante estos últimos años donde
adapte los procesos de desarrollos de software, técnicos los esquemas lógicos son recuperados de bases de datos
y entregables, por ejemplo probando la documentación, físicas. (Hen01)
y pruebe resultados.
de
de
del
del
Prueba
Impacto
Personal
Limitada
Técnicos
Software
Elementos
Análisis de
Clave en el
del Software
2.Elementos
los Costes de
del Software
Comprensión
Alineamiento
1.5 Evolución
con Objetivos
1.3 Necesidad
2.1 Elementos
2.2 Gestión de
1.6 Categorías
1.2 Naturaleza
Mantenimiento
Mantenimiento
Mantenimiento
Mantenimiento
Mantenibilidad
1.4 Mayoría de
y Terminología
Mantenimiento
Mantenimiento
1.1 Definiciones
1.Fundamentos
organizacionales
63-90 63-90 63-90 [Abr 93]
s3 [Arn 92]
[Art88]
s4 [Ben 00]
c1s1.0-
c3 C9 c1s1.2 c1s1.2,c11s1.1 [Boe 81]
,c11s1.2
s5, s9.3, s10.1, s11.
s6a s11.4 s10.2,s10.3
s6c s5 [Car 90]
4
Bo
[Dek 92]
[Dor 97]
c1 [Tak 97]
r
de
de
costes
únicas
Inversa
soporte
para el
software
Medidas
Procesos
Aspectos
específicas
Calidad del
Modelos de
4. Técnicas
Actividades
Experiencia
del software
2.4 Medidas
de Costes de
Actividad de
Gestión de la
Comprensión
configuración
4.3 Ingeniería
3. Proceso de
Estimación de
Actividades de
mantenimiento
mantenimiento
2.3 Estimación
Mantenimiento
Mantenimiento
Mantenimiento
3.1 Procesos de
3.2 Actividades
parametrización
Subcontratación
Mantenimiento
Mantenimiento
4.1 Programa de
4.2 Reingeniería
planificación del
organizacionales
63-90 63-90 63-90 63-90
A.2
c7s4 c2,c10 c3 c3
s9.2, s9.2, s7, s8, s9.1,
s2, s6b,s9.2,
s10.3,s11.2, s11.4, s11.4 s9.2,s9.3, s6b s9.1 s8 s9.2 s9.2, s7 s7
s10.1,s11.4
s11.3,s11.5 s11.5 s11.4,s11.5 s10.1
Bo
c30 c30 s7 s6a, s7 s6b
s2-s3
c7s1 c4s7
c12s12.1
c11s11.5 c11s11.2 c11s11.3 c11s11.3 -
c12s12.3
c10s10.2 c9s9.1-
c7,c8 c5 c14s14.6 c8 c8 c8 c2s2.5
, c18 c9s9.2
239-249
do
c6s6.1-
C4 c3 c7 c2 c8
c6s6.3
r
RECOMMENDED REFERENCES FOR [Par86] G. Parikh, Handbook of Software Maintenance,
SOFTWARE John Wiley & Sons, 1986.
MAINTENANCE [Pfl01] S.L. Pfleeger, Software Engineering: Theory and
[Abr93] A. Abran and H. Nguyenkim, ―Measurement of Practice, second ed., Prentice Hall, 2001.
the Maintenance Process from a Demand-Based [Pig97] T.M. Pigoski, Practical Software Maintenance:
Perspective,‖ Journal of Software Maintenance: Best Practices for Managing your Software Investment,
Research and Practice, vol. 5, iss. 2, 1993, pp. 63-90. first ed., John Wiley & Sons, 1997.
[Arn93] R.S. Arnold, Software Reengineering: IEEE [Pre04] R.S. Pressman, Software Engineering: A
Computer Society Press, 1993. Practitioner’s Approach, sixth ed., McGraw-Hill, 2004.
[Art98] L.J. Arthur, Software Evolution: The Software [SEI01] Software Engineering Institute, ―Capability
Maintenance Challenge, John Wiley & Sons, 1988. Maturity Model Integration, v1.1,‖ CMU/SEI-2002-TR-
[Ben00] K.H. Bennett, ―Software Maintenance: A 002, ESC-TR-2002-002, December 2001.
Tutorial,‖ in Software Engineering, M. Dorfman and R. [Sta94] G.E. Stark, L.C. Kern, and C.V. Vowell, ―A
Thayer, eds., IEEE Computer Society Press, 2000. Software Metric Set for Program Maintenance
[Boe81] B.W. Boehm, Software Engineering Economics, Management,‖ Journal of Systems and Software, vol. 24,
r
Prentice Hall, 1981. iss. 3, March 1994.
[Car90] D.N. Card and R.L. Glass, Measuring Software [Tak97] A. Takang and P. Grubb, Software Maintenance
Design Quality, Prentice Hall, 1990. Concepts and Practice, International Thomson
do
[Dek92] S. Dekleva, ―Delphi Study of Software Computer Press, 1997.
Maintenance Problems,‖ presented at the International
Conference on Software Maintenance, 1992.
[Dor02] M. Dorfman and R.H. Thayer, eds., Software
Engineering (Vol. 1 & Vol. 2), IEEE Computer Society
Press, 2002.
[Gra87] R.B. Grady and D.L. Caswell, Software Metrics:
Establishing a Company-Wide Program, Prentice Hall,
1987.
[Hen01] J. Henrard and J.-L. Hainaut, ―Data
Dependency Elicitation in Database Reverse
rra
Engineering,‖ Proc. of the 5th European Conference on
Software Maintenance and
Reengineering (CSMR 2001), IEEE Computer Society
Press, 2001.
[IEEE610.12-90] IEEE Std 610.12-1990 (R2002), IEEE
Standard Glossary of Software Engineering
Terminology, IEEE, 1990.
[IEEE1061-98] IEEE Std 1061-1998, IEEE Standard for
a Software Quality Metrics Methodology, IEEE, 1998.
[IEEE1219-98] IEEE Std 1219-1998, IEEE Standard for
Software Maintenance, IEEE, 1998.
Bo
r
(Apr03) A. April, A. Abran, and R. Dumke, ―Software Olsson,
Maintenance Capability Maturity Model (SM-CMM): ―Corrective Maintenance Maturity Model: Maintainer‘s
Process Performance Measurement,‖ presented at 13th Education and Training,‖ presented at International
do
International Workshop on Software Measurement Conference on Software Engineering, 2001.
(IWSM (Kho95) T.M. Khoshgoftaar, R.M. Szabo, and J.M.
2003), 2003. Voas,
(Bas85) V.R. Basili, ―Quantitative Evaluation of ―Detecting Program Module with Low Testability,‖
Software presented at the International Conference on Software
Methodology,‖ presented at First Pan-Pacific Computer Maintenance-1995, 1995.
Conference, 1985. (Lag96) B. Laguë and A. April, ―Mapping for the
(Bel72) L. Belady and M.M. Lehman, ―An Introduction ISO9126
to Maintainability Internal Metrics to an Industrial
Growth Dynamics,‖ Statistical Computer Performance Research
Evaluation, W. Freiberger, ed., Academic Press, 1972. Tool,‖ presented at SESS, 1996.
rra
(Ben00) K.H. Bennett and V.T. Rajlich, ―Software (Leh85) M.M. Lehman and L.A. Belady, Program
Maintenance and Evolution: A Roadmap,‖ The Future of Evolution: Processes of Software Change, Academic
Software Engineering, A. Finklestein, ed., ACM Press, Press,
2000. 1985.
(Bol95) C. Boldyreff, E. Burd, R. Hather, R. Mortimer, (Leh97) M.M. Lehman, ―Laws of Software Evolution
M. Revisited,‖ presented at EWSPT96, 1997.
Munro, and E. Younger, ―The AMES Approach to (Lie81) B.P. Lientz and E.B. Swanson, ―Problems in
Application Understanding: A Case Study,‖ presented at Application Software Mainteanance,‖ Communications
the International Conference on Software Maintenance, of
1995. the ACM, vol. 24, iss. 11, 1981, pp. 763-769.
(Boo94) G. Booch and D. Bryan, Software Engineering (McC02) B. McCracken, ―Taking Control of IT
Performance,‖ presented at InfoServer LLC, 2002.
Bo
r
Programming in a Maintenance Environment,‖ IEEE
Software, vol. 18, iss. 6, November/December 2001, pp.
42-50.
do
(Put97) L.H. Putman and W. Myers, ―Industrial Strength
Software - Effective Management Using Measurement,‖
1997.
(Sch99) S.R. Schach, Classical and Object-Oriented
Software Engineering with UML and C++, McGraw-
Hill,
1999.
(Sch97) S.L. Schneberger, Client/Server Software
Maintenance, McGraw-Hill, 1997.
(Sch87) N.F. Schneidewind, ―The State of Software
Maintenance,‖ Proceedings of the IEEE, 1987.
rra
(Som96) I. Sommerville, Software Engineering, fifth ed.,
Addison-Wesley, 1996.
(Val94) J.D. Vallett, S.E. Condon, L. Briand, Y.M. Kim,
and V.R. Basili, ―Building on Experience Factory for
Maintenance,‖ presented at the Software Engineering
Workshop, Software Engineering Laboratory,
1994.
Bo
APPENDIX A. LIST OF STANDARDS (IEEE14143.1-00) IEEE Std 14143.1-2000//
(IEEE610.12-90) IEEE Std 610.12-1990 (R2002), IEEE ISO/IEC14143-1:1998, Information Technology -
Standard Glossary of Software Engineering Software
Terminology, Measurement-Functional Size Measurement - Part 1:
IEEE, 1990. Definitions of Concepts, IEEE, 2000.
(IEEE1061-98) IEEE Std 1061-1998, IEEE Standard for (ISO9126-01) ISO/IEC 9126-1:2001, Software
a Engineering-Product Quality - Part 1: Quality Model,
Software Quality Metrics Methodology, IEEE, 1998. ISO
(IEEE1219-98) IEEE Std 1219-1998, IEEE Standard for and IEC, 2001.
Software Maintenance, IEEE, 1998. (ISO14764-99) ISO/IEC 14764-1999, Software
(IEEE12207.0-96) IEEE/EIA 12207.0-1996//ISO/ Engineering - Software Maintenance, ISO and IEC,
IEC12207:1995, Industry Implementation of Int. Std. 1999.
ISO/IEC 12207:95, Standard for Information (ISO15271-98) ISO/IEC TR 15271:1998, Information
Technology - Technology - Guide for ISO/IEC 12207, (Software Life
Software Life Cycle Processes, IEEE, 1996. Cycle Process), ISO and IEC, 1998. [Abr93]
r
do
rra
Bo
Bo
rra
do
r
CAPÍTULO 7
GESTIÓN DE CONFIGURACIÓN DEL SOFTWARE
r
Software conjunto de actividades que proporcionan la confidencia
SCI Elemento de configuración de software necesaria de que se está teniendo en cuenta la calidad al
SCM Gestión de la configuración del software construir el software. Las actividades de la SCM ayudan
SCMP Plan de gestión de la configuración del a conseguir estos objetivos de la SQA. En el contexto de
do
software algunos proyectos (véase, por ejemplo, IEEE730-02),
SCR Petición de cambios del software requerimientos específicos de las SQA requieren ciertas
SCSA Contabilidad del Estado de la Configuración actividades de la SCM.
del Software Las actividades de la SCM son: gestión y planificación de
SEI/CMMI los procesos de la SCM, identificación de la
Instituto de Ingenieros Software/ Modelo de la configuración del software, control de la configuración
Capacidad de Madurez Integrado del software, responsabilidad del estado de la
SQA Garantía de calidad del software. configuración del software, auditoría de la configuración
SRS Especificación de Requisitos Software del software y gestión del lanzamiento y entrega del
USNRC Comisión Reguladora de Energía Nuclear de software.
los Estados Unidos
rra
INTRODUCCIÓN:
Un sistema se puede definir como una colección de
componentes que se organizan con el objetivo de
proporcionar una función o conjunto de funciones
determinadas (IEEE 610.12-90). La configuración de un
sistema son las características funcionales y/o físicas del
hardware, firmware, software o una combinación de las
mismas, según lo dispuesto en la documentación técnica
y el resultado obtenido en un producto. (Buc96) También
se puede considerar como una colección de versiones
específicas de elementos de hardware, firmware o
software que se combinan de acuerdo con un proceso de
construcción específico para un satisfacer un propósito La figura 1 muestra una representación estilizada de estas
Bo
r
organización como por ejemplo la organización de diseño e implementación de los procesos de la SCM en
desarrollo, normalmente es un elemento definido de la un determinado proyecto. Además, el contrato entre el
organización o un individuo especialmente designado proveedor y el cliente podría contener estipulaciones que
quien tiene la responsabilidad general de la SCM. afecten los procesos de la SCM. Por ejemplo, podría ser
do
El software se desarrolla frecuentemente como una parte necesaria una auditoría de configuración o podría ser
de un sistema mayor que contiene elementos de hardware necesario poner ciertos elementos bajo el control de la
y firmware. En ese caso, las actividades de la SCM CM. Cuerpos de regulación externos podrían imponer
suceden en paralelo con las actividades de CM del restricciones a productos de software que se vayan a
hardware y firmware y debe ser consistente con la CM desarrollar cuando estos puedan afectar potencialmente a
del sistema. Buckley [Buc96:c2] describe la SCM en este la seguridad pública (véase, por ejemplo, USNRC1.169-
contexto. Tenga en cuenta que el firmware contiene 97). Finalmente, el proceso del ciclo de vida del software
hardware y software, así que son aplicables los conceptos elegido para un proyecto de software en particular y las
de CM de ambos, hardware y software. herramientas elegidas para la implementación de dicho
La SCM puede interactuar con la actividad de la garantía software, afectan el diseño e implementación de los
de la calidad de la organización en lo que se refiere a procesos de la SCM. [Ber92]
temas como la gestión de registros y de elementos no Las ―mejores prácticas‖, como se reflejan en los
rra
válidos. Respecto a gestión de registros, algunos estándares de la ingeniería del software publicados por
elementos bajo el control de la SCM podrían ser también varias organizaciones de estándares, se pueden usar como
registros del proyecto, dependiendo del programa de consejo para el diseño e implementación de un proceso
garantía de calidad de la organización. Normalmente la de la SCM. Moore [Moo98] proporciona una guía para
gestión de elementos no válidos es responsabilidad de la dichas organizaciones y sus estándares. Las mejores
actividad de garantía de la calidad; sin embargo, la SCM prácticas se reflejan también en modelos de mejora del
pude ayudar mediante el seguimiento e informes de Gestión de la Configuración del Software
Bo
r
Construcción del software
Configuración del Software, Responsabilidad del Estado
de la Configuración del Software, Auditoría de la Gestión y seguimiento de los lanzamientos del
Configuración del Software y la Gestión de Lanzamiento software y su distribución
do
y Entrega del Software. Además, se suelen considerar Las herramientas utilizadas en estas áreas, también
puntos como organización y responsabilidades, recursos pueden proporcionar medidas para mejorar el proceso.
y calendarios, selección de herramientas e Royce [Roy98] describe siete medidas centrales útiles
implementación, control de proveedores y subcontratas y para gestionar procesos de la ingeniería del software. La
control de la interacción. Los resultados de la información disponible de las varias herramientas de la
planificación de actividades se registran en un Plan de SCM es afín al indicador de Trabajo y Progreso de Royce
SCM, que normalmente está sujeto a revisión y auditoría y a sus indicadores de calidad de Cambio de Tráfico y
de la SQA. Estabilidad, Ruptura y Modularidad, Repetición del
Trabajo y Adaptabilidad y TMEF (Tiempo medio entre
1.3.1 Organización y responsabilidades de la SCM fallos) y Madurez. Los informes para estos indicadores se
[Ber92:c7; Buc96:c3; IEEE828-98:c4s2] pueden organizar de varias maneras, como por elemento
Para prevenir confusión acerca de quién debe realizar de configuración del software o por tipo del cambio
tareas de la SCM determinadas, se deben identificar requerido.
rra
claramente las organizaciones involucradas en el proceso La figura 3 muestra una asignación representativa entre
de la SCM. Responsabilidades específicas para una las habilidades de las herramientas y procedimiento a
actividad o tarea de la SCM también deben ser asignadas Actividades de la SCM.
a organizaciones, bien por título o por elemento de la
organización. Se debe identificar también la autoridad
general y las vías de información de la SCM, aunque se
podría realizar como parte de la fase de planificación de
la garantía de la calidad o al nivel de la gestión de
proyectos.
1.3.2 Recursos y planificación de la SCM [Ber92:c7;
Buc96:c3; IEEE828-98:c4s4; c4s5]
Planificar para la SCM ayuda identifica las necesidades
Bo
r
aplicables, directivas y procedimientos)
1.3.4 Control Proveedores/Subcontratas Actividades de la SCM (identificación de la
[Ber92:c13; Buc96:c11; IEEE828-98:c4s3.6] configuración, control de la configuración, etc.)
do
Un proyecto de software podría hacer uso o adquirir Planificación de la SCM (coordinación con otras
productos software que se hayan comprado, como actividades del proyecto)
compiladores u otras herramientas. La planificación de la Recursos de la SCM (herramientas, recursos
SCM considera si y como se pondrán estos elementos físicos y recursos humanos)
bajo control de configuración (por ejemplo, integrados en
bibliotecas de proyecto) y como se evaluarán y Mantenimiento del SCMP
gestionarán los cambios y actualizaciones.
Consideraciones similares son aplicables al software 1.5 Seguimiento de la Gestión del la Configuración
subcontratado. En este caso, también se deben establecer del Software [Pau93:L2-87]
los requerimientos de la SCM a ser impuestos a los Después de que el proceso de la SCM de ha
procesos de la SCM del subcontratista como parte del implementado, puede ser necesario un cierto nivel de
subcontrato y los medios para monitorizar que se cumple seguimiento para asegurarse de que las previsiones de la
con ellos. El último incluye consideraciones acerca de
rra
SCM se llevan a cabo adecuadamente (véase, por
que información de la SCM ha de estar disponible para ejemplo [Buc96]). Probablemente habrá requerimientos
poder monitorizar, de una manera eficiente, que se específicos de la SQA para asegurarse de que se cumplen
cumplen los requerimientos. los procesos y procedimientos específicos de la SCM.
Esto podría requerir que una autoridad de la SCM se
1.3.5 Control de Interacción [IEEE828-98:c4s3.5] asegure de que aquellos que tengan responsabilidades
Cuando un elemento de software interacciona con otro asignadas realizan las tareas de la SCM definidas de una
elemento de software o hardware, un cambio a cualquiera manera correcta. Este seguimiento podría ser realizado,
de los dos elementos puede afectar al otro. La como parte de una actividad de cumplimiento de
planificación para los procesos de la SCM considera auditoría, por la autoridad de la garantía de la calidad del
como se identificarán los elementos que interaccionan y software.
como se gestionarán y comunicarán los cambios a dichos El uso de herramientas integradas de la SCM con
elementos. El papel de la SCM puede ser parte de posibilidades de control de procesos puede hacer la tarea
de seguimiento más fácil. Algunas herramientas facilitan
Bo
r
producto y de los procesos. El programa de medidas del proporcionar un número manejable de elementos a
software se describe en el KA de la Gestión del controlar. Se puede encontrar una lista con criterios para
Ingeniería del Software. la selección de SCIs en [Ber92].
do
1.5.2 Auditorías durante el proceso de la SCM 2.1.3 Relaciones entre elementos de la configuración
[Buc96:c15] del software [Con98:c2; Pre04:c27]
Se pueden llevar a cabo auditorías durante el proceso de La relación estructural entre los SCIs seleccionados y sus
ingeniería del software para investigar el estado actual de partes constituyentes, afectan a otras actividades o tareas
elementos específicos de la configuración o para evaluar de la SCM, como la construcción del software o el
la implementación del proceso de la SCM. Las auditorías análisis del impacto de los cambios propuestos. El
durante el proceso de la SCM proporcionan un seguimiento adecuado de estas relaciones es también
mecanismo más formal para monitorizar aspectos importante como soporte a las operaciones de
seleccionados del proceso y se podría coordinar con la seguimiento. La necesidad de asignar los elementos
función del SQA. Véase también el punto 5 Auditando la identificados a la estructura del software y la necesidad
Configuración del Software. de soportar la evolución de los elementos de software y
rra
sus relaciones, se debería considerar durante el diseño de
3. Identificación de la Configuración del los métodos de identificación para los SCIs.
Software
[IEEE12207.0-96:c6s2.2] 2.1.4 Versiones del software [Bab86:c2]
La actividad de la identificación de la configuración del Los elementos de software evolucionan al mismo tiempo
software identifica elementos que se han de controlar, que el proyecto de software avanza. Una versión de un
establece métodos de identificación para los elementos y elemento de software es un elemento identificado y
sus versiones y establece las herramientas y técnicas que especificado particularmente. Se puede pensar en ella
se usarán para adquirir y gestionar los elementos como el estado de un elemento que evoluciona.
controlados. Estas actividades proporcionan la base para [Con98:c3-c5] Una revisión es una nueva versión de un
las otras actividades de la SCM. elemento que reemplazará la versión anterior. Una
variante es una nueva versión de un elemento que se
2.1 Identificando los Elementos a Controlar [Ber92:c8; añadirá la configuración sin reemplazar la versión
Bo
r
interacciones entre software. La línea base de desarrollo es más restringido y el principal usuario en la SCM.
representa la configuración evolutiva del software en Estas bibliotecas son también una fuente importante de
momentos determinados durante el ciclo de vida del información para mediciones del trabajo realizado y del
proyecto. La autoridad de cambios para dicha línea base progreso.
do
es normalmente la responsabilidad de la organización de
desarrollo, pero se podría compartir con otras 4. Control de la Configuración del Software
organizaciones (por ejemplo la de SCM o la de Pruebas). [IEEE12207.0-96:c6s2.3; Pau93:L2-84]
La línea base de un producto se corresponde con el
producto de software completo, entregado para
integración de sistemas. Las líneas base a usar en un Al control de la configuración del software le concierne
proyecto determinado, junto con los niveles de autoridad la gestión de cambios durante el ciclo de vida del
asociados necesarios para la aprobación de cambios, se software. Cubre los procesos que determinan los cambios
identifican normalmente en el SCMP. que se realizarán, la autoridad requerida para aprobar
ciertos cambios, el soporte para la implementación de
dichos cambios y el concepto de desviación formal de los
2.1.6 Adquisición de elementos de configuración del requerimientos del proyecto, además de las cancelaciones
software [Buc96:c4]
rra
de requerimientos. La información derivada de estas
Diferentes elementos de configuración del software se actividades es útil para medir el tráfico de cambios y
ponen bajo el control de la SCM en momentos distintos; ruptura y aspectos por rehacer.
lo que significa que se añaden a una línea base en
particular en momentos específicos del ciclo de vida del
software. El evento que da comienzo al proceso es la 3.1 Petición, Evaluación y Aprobación de Cambios del
terminación de alguna forma de tarea formal de Software [IEEE828-98:c4s3.2;
aceptación, como una revisión formal. La figura 2 Pre04:c27;Som05:c29]
caracteriza el crecimiento de elementos en una línea base El primer paso para gestionar cambios en elementos
durante el ciclo de vida. Esta figura se basa en el modelo controlados es determinar los cambios a realizar. El
de cascada solamente por motivos ilustrativos; los proceso de petición de cambio del software (véase la
subscripts usados en la figura indican la versión de los Figura 5) proporciona procedimientos formales para
elementos durante su evolución. La petición de cambios recoger y registrar peticiones de cambios, evaluando el
del software (SCR) se describe en el punto 3.1 Petición, coste e impacto potencial de un cambio propuesto y
Bo
Evaluación y Aprobación de Cambios del Software. aceptar, modificar o rechazar el cambio propuesto. Las
Seguidamente de la adquisición de un SCI, los cambios a peticiones de cambios de elementos de la configuración
dicho elemento se deben aprobar formalmente de la del software los puede originar cualquiera durante
manera apropiada para el elemento y la línea base cualquier momento del ciclo de vida del software y puede
involucrados, como se define en el SCMP. Después de la incluir una solución propuesta y una prioridad. Una
aprobación, el elemento se incorpora en la línea base del fuente de petición de cambios es la iniciación de acciones
software siguiendo el procedimiento apropiado.
r
propuesto. desarrollo en paralelo y entornos geográficamente
distribuidos. Estas herramientas podrían aparecer como
aplicaciones especializadas separadas, bajo el control de
3.1.1 Consejo de Control de la Configuración del un grupo independiente de la SCM. También podrían
do
Software [Ber92:c9; Buc96:c9,c11; Pre04:c27] aparecer integradas como parte del entorno de la
ingeniería del software. Finalmente, podrían ser tan
La autoridad para aceptar o rechazar los cambios elementales como un sistema de control de cambios
propuestos, es normalmente la responsabilidad de una
entidad conocida como Consejo de Control de la rudimentario proporcionado por el sistema operativo.
Configuración (CCB). En proyectos pequeños, dicha
autoridad normalmente reside en el Jefe de Proyecto o 3.3 Desviaciones y Remisiones [Ber92:c9;
algún otro individuo elegido, en vez de en un consejo de Buc96:c12]
varias personas. Puede haber múltiples niveles de
autoridad de cambios, dependiendo de una variedad de Las limitaciones impuestas al esfuerzo de la ingeniería
criterios, como cuan crítico sea el elemento involucrado, del software o las especificaciones producidas durante las
la naturaleza del cambio (por ejemplo, el impacto en el actividades de desarrollo podrían contener necesidades
presupuesto y planificación), o el momento actual en el que no pueden ser satisfechas en el punto designado del
rra
ciclo de vida. La composición de CCBs que se utilice ciclo de vida. Una remisión es la autorización para
para un sistema determinado varia en relación a estos abandonar una necesidad antes del desarrollo del
criterios (siempre atendería un representante de la SCM). elemento. Un rechazo es la autorización para utilizar un
Cuando el alcance de la autoridad de un CCB es está elemento, después de su desarrollo, que se aleja de la
limitado solamente al software, se le conoce como necesidad de alguna manera. En estos casos se usa un
Consejo de Control de Configuración del Software procedimiento formal para ganar la aprobación para la
(CCBS). Las actividades del CCB están sujetas desviación o remisión de las necesidades.
normalmente a auditorías de la calidad de software o
revisiones. 5. Registro del Estado de la Configuración del
Software
3.1.2 Proceso de petición de cambios del software
[Buc96:c9,c11; Pre04:c27] [IEEE12207.0-96:c6s2.4; Pau93:L2-85;
Pre04:c27;Som05:c29]
Bo
4.2 Informes del Estado de la Configuración del 5.2 Auditoría de la Configuración Física del Software
Software [Ber92:c10; Buc96:c13] El propósito de la auditoría de la configuración física del
Los informes generados pueden ser usados por varios software (PCA) es asegurarse de que el diseño y la
elementos de la organización o del proyecto, incluyendo documentación de referencia son consistentes con el
el equipo de desarrollo, el equipo de mantenimiento, la producto de software tal y como se ha construido.
gestión del proyecto y las actividades de calidad de
software. Los informes pueden tener la forma de 5.3 Auditorías durante el proceso de una Línea Base de
r
respuestas inmediatas a preguntas específicas o ser Software
informes prediseñados producidos periódicamente.
Alguna de la información producida por las actividades Tal y como se menciona anteriormente, las auditorías se
de contabilidad del estado durante el curso del ciclo de pueden llevar a cabo durante el proceso de desarrollo
do
vida podría acabar siendo registros de la garantía de la para investigar el estado actual de un elemento de la
calidad. configuración específico. En dicho caso, se podría aplicar
Además de informar del estado actual de la una auditoría a elementos seleccionados de la línea base
configuración, la información obtenida por la SCSA para asegurarse de que el rendimiento es consistente con
puede usarse como base para varias mediciones útiles las especificaciones o para asegurarse de que la
para la gestión, desarrollo y SCM. Un ejemplo podría ser documentación continua siendo consistente con el
el número de cambios pedidos por ECS y el tiempo elemento de la línea base que se está desarrollando.
medio necesario para implementar una petición de
cambio. 6. Gestión del Lanzamiento y Distribución del
Software [IEEE12207.0-96:c6s2.6]
5. Auditoría de la Configuración del Software
[IEEE828-98:c4s3.4; IEEE12207.0- El término ―lanzamiento‖ se usa en este contexto para
rra
96:c6s2.5;Pau93:L2-86; Pre04:c26c27] referirse a la distribución un elemento de la configuración
del software fuera de la actividad de desarrollo. Esto
La auditoría de software es una actividad que se realiza incluye tanto lanzamientos internos como la distribución
para evaluar independientemente la conformidad de a clientes. Cuando una versión diferente de un elemento
productos de software y procesos con las regulaciones, de software está disponible para ser entregada, como las
estándares, guías, planes y procedimientos (IEEE1028- versiones para diferentes plataformas o versiones con
97). Las auditorías se llevan a cabo de acuerdo con un diferentes capacidades, es normalmente necesario
proceso bien definido que consiste en varias preparar una versión específica y empaquetar los
responsabilidades y papeles de auditoría. En materiales adecuados para distribuirla. La biblioteca de
consecuencia, cada auditoría se debe planear con software es un elemento clave para realizar las tareas de
cuidado. Una auditoría requiere un número de personas lanzamiento y distribución.
que realizarán una variedad de tareas en un periodo de
tiempo bastante reducido. Herramientas que den soporte 6.1 Construcción del Software [Bab86:c6; Som05:c29]
a la planificación y ejecución de la auditoría pueden
Bo
facilitar el proceso enormemente. Se pueden encontrar La construcción del software es la actividad de combinar
consejos para realizar auditorías de software en varias la versión correcta de los elementos de configuración del
referencias, como [Ber92:c11, Buc96:c15] y (IEEE1028- software, usando la configuración de datos apropiada, en
97). un programa ejecutable para su distribución a los clientes
La actividad de auditoría de la configuración del software u otros receptores, como la actividad de pruebas. Las
determina el grado en que un elemento satisface las instrucciones de construcción se aseguran de que se
características funcionales y físicas. Se pueden realizar toman los pasos de construcción adecuados y en la
auditorías informales de este tipo en momentos clave del secuencia correcta. Además de construir software para un
ciclo de vida. Hay dos tipos de auditorías que podrían ser nuevo lanzamiento, la SCM normalmente necesita ser
requeridas por el contrato (por ejemplo, en contratos para capaz de reproducir lanzamientos previos para
software crítico): la Auditoría de la Configuración recuperación, pruebas, mantenimiento u otros propósitos
Funcional (FCA) y la Auditoría de la Configuración de lanzamiento adicionales.
Física (PCA). El completar con éxito estas auditorías El software se construye usando versiones particulares de
puede ser un prerrequisito para establecer la línea base la herramientas de soporte, como compiladores. Podría
del producto. Buckley [Buc96:c15] contrasta los ser necesario reconstruir una copia exacta de un elemento
objetivos de las FCA y PCA en los contextos de software de configuración que se haya construido previamente. En
y hardware y recomienda que se evalúe cuidadosamente ese caso, las herramientas de soporte y las instrucciones
la necesidad de una FCA y PCA de software antes de de construcción asociadas deben de estar bajo el control
realizarlas. de la SCM para asegurarse de la disponibilidad de la las
versiones correctas de las herramientas.
Las habilidades de una herramienta son útiles para
seleccionar la versión correcta de elementos de software
para un entorno destino determinado y para el proceso de
construir el software automáticamente con las versiones las variantes correctas de dichos elementos, dada la
seleccionadas y los datos de configuración apropiados. aplicación que se le quiere dar al producto. La
En proyectos grandes con desarrollo en paralelo o en información que documenta el contenido físico del
entornos de desarrollo distribuido, estas habilidades de lanzamiento se conoce como documento de descripción
las herramientas son necesarias. La mayoría de los de la versión. Las notas del lanzamiento normalmente
entornos de ingeniería del software proporcionan esta describen nuevas habilidades, problemas conocidos y
habilidad. Estas herramientas varían en complejidad, requisitos necesarios de la plataforma para la operación
desde las que requieren que el ingeniero de software adecuada del producto. El paquete que se distribuirá
aprenda un lenguaje de guiones específico a soluciones también contiene instrucciones de instalación o
gráficas que ocultan la mayor parte de la complejidad en actualización. El último se puede complicar porque
una solución de construcción ―inteligente‖. algunos usuarios podrían tener productos que son
El proceso y los productos de la construcción están antiguos por varias versiones. Finalmente, en algunos
sujetos, normalmente, a verificación de la calidad del casos, se podrían requerir la actividad de gestión de
software. Los resultados de un proceso de construcción se lanzamientos para el seguimiento de la distribución del
podrían necesitar para futuras referencias y podrían producto a varios clientes o sistemas objetivo. Un
convertirse en registros de la garantía del software. ejemplo sería el caso en el que se requiriese que un
proveedor tiene que notificar a un cliente de nuevos
r
6.2 Gestión del Lanzamiento del Software [Som05:c29] problemas.
Las habilidades de una herramienta son necesarias para
La gestión de lanzamiento del software conlleva la dar soporte a estas funciones de gestión de los
identificación, empaquetamiento y distribución de los lanzamientos. Es útil tener una conexión con las
do
elementos de un producto, por ejemplo, programas habilidades de la herramienta para dar soporte a los
ejecutables, documentación, notas de lanzamiento y datos procesos de peticiones de cambios, de tal forma que se
de configuración. Dado que los cambios pueden ocurrir puedan relacionar los contenidos de un lanzamiento con
constantemente, una de las preocupaciones en la gestión los SCR que se han recibido. Esta habilidad de las
de lanzamientos es determinar cuándo realizar un herramientas también podría mantener información en
lanzamiento. La severidad de los problemas solucionados varias plataformas destino y de varios entornos de
por el lanzamiento afecta a esta decisión (Som01). La clientes.
tarea de empaquetamiento debe identificar que elementos
del producto se deben distribuir y por tanto seleccionar
rra
Bo
MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA
[IEEE1220
[IEEE828-
[Moo98]
[Som05]
[Con98]
[Mid97]
[Bab86]
[Roy98]
[Buc96]
[Dar90]
[Pau93]
[Ber92]
[Pre04]
7.0-96]
98]
1.Gestión del proceso SCM
1.1Contexto de Organización para SCM c4 c2 c2 c4s2.1
c4s1,
1.2Restricciones y Consejos para SCM c5 6.2.1 *
c4s2.3
1.3Planificación de SCM c2 c29
Organización y responsabilidades c7 c3 c4s2
c4s4,
Recursos y planificación c7 c3
c4s5
c3,
Selección de herramientas e
c15 c6 App * *
implementación
r
A
Control Proveedores/Subcontratas c13 c11 c4s3.6
Control de Interacción c12 c4s3.5
L2-
do
1.4Plan de SCM c7 c3 c4
81
L2-
1.5Seguimiento de la SCM * c4
87
188-202,
Métricas y mediciones c3
283-298
Auditorias durante el proceso de SCM c15
2. Identificación de la Configuración
c6s2.2
Sw
2.1Identificando los elementos a L2-
c8 c4s3.1 c29
controlar 83
c4,
Configuración software c27
c6
rra
c4,
Elementos de configuración software * c2 c27
c6
Relaciones entre elementos de
c2 c27
Configuración Sw
Versiones Software c2 c27
Línea Base c5 * c4 c27
Adquisición de elementos de
c4
Configuración Sw
c2, L2-
2.2Biblioteca Software c14 c4 c4s3.1 c29
c5 82
L2-
3. Control de la Configuración Sw c6s2.3
84
3.1 Petición, Evaluación y Aprobación
c4s3.2 c27 c29
de Cambios
Bo
c9,
Control de la Configuración del Sw c9 c27
c11
c9,
Proceso de Petición de Cambios Sw c9 c27
c11
c9,
3.2 Implementando Cambios del Sw c6 c9 c4s3.2.4 c27 c29
c11
3.3 Desviaciones y Remisiones c9 c12
4. Registro del Estado de la L2-
c6s2.4 c27 c29
Configuración Sw 85
4.1 Información del Estado de la
c10 c13 c4s3.3
Configuración Sw
4.2 Informes del Estado de la
c10 c13
Configuración Software
L2- c27,
5. Auditoría de la Configuración Sw c11 c15 c4s3.4 c6s2.5
86 c26
5.1 Auditoría de la Configuración
Funcional
5.2 Auditoría de la Configuración Física
5.3 Auditoría de una Línea Base de Sw
6. Gestión del Lanzamiento y
c6s2.6
Distribución Sw
6.1 Construcción Software c6 c29
6.2 Gestión del Lanzamiento Sw c29
REFERENCIAS RECOMENDADAS PARA SCM [IEEE12207.0-96] IEEE/EIA 12207.0-1996//ISO/
IEC12207:1995, Industry Implementation of Int. Std.
[Bab86] W.A. Babich, Software Configuration ISO/IEC 12207:95, Standard for Information Technology-
Management, Coordination for Team Productivity, Addison- Software Life Cycle Processes, IEEE, 1996.
Wesley, 1986.
[Mid97] A.K. Midha, ―Software Configuration Management
[Ber92] H.R. Berlack, Software Configuration Management, for the 21st Century,‖ Bell Labs Technical Journal, vol. 2,
John Wiley & Sons, 1992. iss. 1, Winter 1997, pp. 154-165.
[Buc96] F.J. Buckley, Implementing Configuration [Moo98] J.W. Moore, Software Engineering Standards: A
Management: Hardware, Software, and Firmware, second User’s Roadmap, IEEE Computer Society, 1998.
ed., IEEE Computer Society Press, 1996.
[Pau93] M.C. Paulk et al., ―Key Practices of the Capability
[Con98] R. Conradi and B. Westfechtel, ―Version Models Maturity Model, Version 1.1,‖ technical report CMU/SEI-
for Software Configuration Management,‖ ACM Computing 93-TR-025, Software Engineering Institute, Carnegie
Mellon University, 1993.
r
Surveys, vol. 30, iss. 2, June 1998.
[Dar90] S.A. Dart, Spectrum of Functionality in [Pre04] R.S. Pressman, Software Engineering: A
Configuration Management Systems, Software Engineering Practitioner’s Approach, Sixth ed, McGraw-Hill, 2004.
do
Institute, Carnegie Mellon University, 1990.
[Roy98] W. Royce, Software Project Management, A United
[IEEE828-98] IEEE Std 828-1998, IEEE Standard for Framework, Addison-Wesley, 1998.
Software Configuration Management Plans, IEEE, 1998.
[Som05] I. Sommerville, Software Engineering, seventh ed.,
Addison-Wesley, 2005.
rra
Bo
APÉNDICE A. LISTA DE LECTURAS ADICIONALES
(Hoe02) A. v. d. Hoek, ―Configuration Management
Yellow Pages,‖ 2002, available at
(Bab86) W.A. Babich, Software Configuration http://www.cmtoday.com/yp/configuration_management.ht
Management, Coordination for Team Productivity, Addison- ml.(Hum89) W. Humphrey, Managing the Software
Wesley, 1986. Process,Addison-Wesley, 1989.
(Ber92) H.R. Berlack, Software Configuration Management, (Pau95) M.C. Paulk et al., The Capability Maturity Model,
John Wiley & Sons, 1992. Guidelines for Improving the Software Process, Addison-
Wesley, 1995.
(Ber97) E.H. Bersoff, ―Elements of Software Configuration
Management,‖ in Software Engineering, M. Dorfman and (Som01a) I. Sommerville, ―Software Configuration
R.H. Thayer, eds., IEEE Computer Society Press, 1997. Management,‖ presented at ICSE SCM-6 Workshop, Berlin,
2001.
(Buc96) F.J. Buckley, Implementing Configuration
Management: Hardware, Software, and Firmware, second
(USNRC1.169-97) USNRC Regulatory Guide 1.169,
r
ed., IEEE Computer Society Press, 1996.
―Configuration Management Plans for Digital Computer
Software Used in Safety Systems of Nuclear Power Plants,‖
(ElE98) K. El-Emam et al., ―SPICE, The Theory and
presented at U.S. Nuclear Regulatory Commission,
Practice of Software Process Improvement and Capability
do
Washington, D.C., 1997.
Determination,‖ presented at IEEE Computer Society, 1998.
(Vin88) J. Vincent, A. Waters, and J. Sinclair, Software
(Est95) J. Estublier, ―Software Configuration
Quality Assurance: Practice and Implementation, Prentice
Management,‖ presented at ICSE SCM-4 and SCM-5
Hall, 1988.
Workshops, Berlin, 1995.
(Whi91) D. Whitgift, Methods and Tools for Software
(Gra92) R.B. Grady, Practical Software Metrics for Project
Configuration Management, John Wiley & Sons, 1991.
Management and Process Management, Prentice Hall, 1992.
.
rra
Bo
APÉNDICE B. LISTA DE ESTÁNDARES
r
(IEEE12207.1-96) IEEE/EIA 12207.1-1996, Industry
Implementation of Int. Std. ISO/IEC 12207:95, Standard for
do
Information Technology-Software Life Cycle Processes -
Life Cycle Data, IEEE, 1996.
r
INTRODUCCIÓN aspectos de gestión organizacional son importantes en
La Gestión de la Ingeniería del Software puede definirse términos de su impacto sobre la ingeniería del software –
como la aplicación para actividades de gestión – en gestión de políticas, por ejemplo: políticas
do
planificación, coordinación, mediciones, monitoreo, organizativas y estándares que proporcionan el marco en
control e informes – que asegure un desarrollo y el que se desenvuelve la ingeniería del software. Puede
mantenimiento del software sistemático, disciplinado y que se necesite que estas políticas se vean afectadas por
cuantificado (IEEE610.12-90). los requisitos de un software de desarrollo y
mantenimiento efectivo, y puede que se necesite
El KA de Gestión de la Ingeniería del Software, por establecer un número de políticas específicas de
tanto, se encarga de la gestión y medición de la ingeniería del software para una gestión eficaz de la
ingeniería del software. A pesar de que medir es un ingeniería del software a nivel organizacional. Por
aspecto importante en todas las KAs, no es hasta aquí ejemplo, normalmente se necesitan políticas para
que se presenta el tema de programas de medición. establecer procesos específicos a nivel organizacional o
rra
Aunque por una parte sea verdad afirmar que, en cierto procedimientos para tareas de ingeniería del software
sentido, debiera ser posible gestionar la ingeniería del tales como el diseño, la implementación, la estimación,
software de la misma manera que cualquier otro proceso el seguimiento y los informes. Tales políticas son
(complejo) existen aspectos específicos de los productos esenciales, por ejemplo, para una gestión de la ingeniería
software y de los procesos del ciclo de vida del software del software eficaz a largo plazo, ya que establecen una
que complican una gestión efectiva –sólo algunos de los base consistente sobre la que analizar actuaciones
cuales se apuntan a continuación: anteriores e implementar mejoras.
La percepción de los clientes es tal que con Otro aspecto importante de la gestión es la gestión del
frecuencia existe una falta de aprecio de la personal: las políticas y procedimientos para contratar,
complejidad inherente a la ingeniería del software, entrenar y motivar al personal y actuar como mentor del
particularmente en relación al impacto que produce desarrollo de una carrera son importantes no sólo a nivel
de proyecto sino también para el éxito a largo plazo de
Bo
r
encontramos un amplio respaldo en la Guía al Proyecto con otras en la Guía del SWEBOK, y sería de particular
de Gestión del Cuerpo de Conocimientos (PMBOK) utilidad leer las siguientes descripciones del KA junto
(PMI00), que en sí misma incluye las siguientes KAs de con ésta.
do
gestión de proyectos: gestión de integración del
proyecto, gestión de objetivos del proyecto, gestión del Los Requisitos del Software, en donde se describen
tiempo del proyecto, gestión del coste del proyecto, algunas de las actividades que tendrán que realizarse
gestión de la calidad del proyecto, gestión de los durante la fase de definición de Iniciación y Alcance
recursos humanos del proyecto y gestión de las del proyecto.
comunicaciones del proyecto. Está claro que todos estos La Gestión de Configuración del Software, ya que
temas tienen una relación directa con el KA de Gestión trata de la identificación, control, consideraciones de
de la Ingeniería del Software. Sería imposible e estado, y auditoría de la configuración del software,
inadecuado intentar duplicar aquí el contenido de la Guía junto con la gestión de entregas y repartos del
de la PMBOK. En su lugar, sugerimos que el lector que software
esté interesado en la gestión de proyectos más allá de lo El Proceso de Ingeniería del Software, porque los
rra
que es específico a los proyectos de ingeniería del procesos y los proyectos están estrechamente
software consulte la propia PMBOK. La gestión de relacionados (esta KA también describe la medición
proyectos también se encuentra en el capítulo sobre las de procesos y productos).
Disciplinas Señaladas de la Ingeniería del Software. La Calidad del Software, ya que la calidad es un
El KA de Gestión de la Ingeniería del Software consiste objetivo constante de la gestión y es una meta con
tanto en el proceso de gestión del proyecto de software muchas actividades que tiene que gestionarse.
en sus primeras cinco subáreas, como en la medición de
la ingeniería del software en su última subárea. Aunque DESCOMPOSICIÓN DE LOS TEMAS DE GESTIÓN
estos dos temas se suelen considerar como distintos, y de DE LA INGENIERÍA DEL SOFTWARE
hecho poseen muchos aspectos únicos en sí mismos, su
gran cercanía ha llevado a que se les trate de manera Hemos creado una descomposición basada tanto en
temas como en ciclos de vida, ya que el KA de Gestión
Bo
r
do
rra
Bo
1. Iniciación y Alcance cambios. También resultará útil un acercamiento que
gestione los cambios cuando llegue el momento de
El enfoque de este conjunto de actividades se centra en
repasar los resultados del proyecto, ya que el alcance y
la determinación eficaz de los requisitos del software
los requisitos tendrán que ser la base para evaluar el
por medio de varios métodos de inducción y la
éxito. [Som05: el c6] Ver también la subárea de control
valoración de la viabilidad del proyecto desde distintos
de la configuración del software del KA de Gestión de
puntos de vista. Una vez que se ha establecido la
la Configuración del Software.
viabilidad, la tarea pendiente dentro de este proceso es
la especificación de la validación de requisitos y del
2. Planificación de un Proyecto de Software
cambio de procedimientos (ver también el KA de
Requisitos del Software). El proceso de planificación iterativa está regulado por
el alcance y requisitos, y por el establecimiento de la
1.1. Determinación y Negociación de los Requisitos viabilidad. A estas alturas, se evalúan los procesos del
ciclo de vida del software y se selecciona el más
[Dor02: v2c4; Pf101: c4; Pre04: c7; Som05: c5]
apropiado (considerando la naturaleza del proyecto, su
r
Los métodos de requisitos del software para la grado de novedad, su complejidad funcional y técnica,
inducción de los requisitos (por ejemplo, observación), sus requisitos de calidad, etc.).
análisis (por ejemplo, modelado de datos, modelado de
Si la situación lo aconseja, se planea entonces el propio
casos de uso), especificación y validación (por ejemplo,
do
proyecto en la forma de una descomposición jerárquica
prototipado) deben seleccionarse y aplicarse, tomando
de tareas, se especifican y caracterizan los entregables
en cuenta las distintas perspectivas del contratista. Esto
asociados de cada tarea en términos de calidad y de
lleva a la determinación del alcance del proyecto, de los
otros atributos en la línea de los requisitos declarados, y
objetivos, y de las restricciones. Ésta siempre es una
se emprende la descripción detallada del esfuerzo de
actividad importante, ya que fija las fronteras visibles
realización, el calendario y la estimación de costes.
para el conjunto de tareas que se emprenden, y sucede
así especialmente donde la tarea es de gran novedad. Más adelante se asignan los recursos a las tareas para
Puede encontrarse información adicional en el KA de optimizar la productividad del personal (a nivel de
los Requisitos del Software. individuo, de equipo y organizacional), el uso de
equipos y materiales, y la adhesión a los horarios. Se
rra
Viabilidad, Análisis (Técnico, emprende una gestión de riesgos detallada y se discute
Operacional, Financiero, el ―perfil de riesgo‖ entre todos los contratistas de
Social/Político) relieve, llegando a un acuerdo. Se determinan los
procesos comprehensivos de gestión de la calidad del
[Pre04: c6; Som05: c6] software como parte del proceso en términos de
Se debe asegurar a los ingenieros del software que hay procedimientos y responsabilidades para asegurar la
disponibles capacidad y recursos adecuados en forma calidad del software, la verificación y la validación, las
de personas, pericia, medios, infraestructura y apoyo revisiones y las auditorías (ver el KA de la Calidad del
(sea interna o externamente) para cerciorarse de que el Software). Ya que es un proceso iterativo, resulta de
proyecto pueda completarse con éxito de un modo vital importancia que se declaren y pacten con claridad
oportuno y rentable (utilizando, por ejemplo, una matriz los procesos y responsabilidades para la gestión, repaso
de requisitos y capacidades). A menudo esto requiere y revisión del plan en ejecución.
Bo
r
[Dor02: v1c8,v2c3-c5; Pre04: c26; Rei02: c10;
que se requiere para cada tarea, utilizando un modelo de
Som05: c24,c25; Tha97: c9,c10]
estimación calibrado basado en datos históricos sobre el
esfuerzo empleado, cuando estén disponibles y sean La calidad se define en términos de atributos
do
pertinentes, u otros métodos como el juicio de un pertinentes al proyecto específico y en los de cualquier
especialista. Se establecen las dependencias de las producto o productos asociados a ella, probablemente
tareas y se identifican los cuellos de botella potenciales tanto en términos cuantitativos como cualitativos. Estas
utilizando los métodos convenientes (por ejemplo, el características de la calidad habrán sido determinadas
análisis del camino crítico). Cuando sea posible se en la especificación de requisitos detallados del
solucionan los cuellos de botella, y se elabora el software. Ver también el KA de los Requisitos del
esperado cuadro de tareas con los horarios de inicio, Software.
duraciones y horarios de finalización bien planificados
Los límites de adhesión a la calidad para cada indicador
(por ejemplo, el diagrama PERT). Los requisitos de
se colocan de acuerdo a las expectativas que tenga el
recursos (personas, herramientas) se traducen en
contratista sobre el software en cuestión. Los
estimaciones de costo. [Dor02: el v2c7; Fen98: el c12;
rra
procedimientos que hacen referencia a lo largo del
Pfl01: el c3; Pre04: el c23, el c24,; Rei02: el c5,c6;
proceso a la SQA en curso a lo largo del proceso y a la
Som05: el c4,c23; Tha97: el c5] Ésta es una actividad
verificación y validación del producto (entregable)
muy iterativa que debe ser negociada y revisada hasta
también se especifican en esta fase (por ejemplo, las
que se alcance un acuerdo general entre los contratistas
revisiones técnicas e inspecciones) (ver también el KA
afectados (principalmente de ingeniería y gestión).
de la Calidad del Software).
2.4 Reparto de Recursos
2.7 Gestión de Planes
[Pf101: c3; Pre04: c24; Rei02: c8,c9; Som05: c4;
[Som05: c4; Tha97: c4]
Tha97: c6,c7]
También se ha de planificar cómo se gestionará el
Los equipos, medios y personas se asocian a las tareas
proyecto y cómo se gestionará la planificación. Los
Bo
r
ejemplo, la decisión de utilizar prototipados para ayudar
3.2 Gestión de Contratos con Proveedores en la validación de los requisitos del software), y/o
puede implicar la revisión de los distintos planes y de
do
[Som05: c4] otros documentos del proyecto (por ejemplo, la
Preparar y ejecutar acuerdos con los proveedores, especificación de requisitos) para corregir los resultados
supervisar la actuación del proveedor, y aceptar sus inesperados y sus implicaciones.
productos, incorporándolos cuando sean adecuados. En algunos casos, puede llevar al abandono del
proyecto. En todos los casos, se adhiere al control de
3.3 Implementación de Procesos para Medir cambios y a los procedimientos de gestión de
[Fen98: c13,c14; Pre04: c22; Rei02: c10,c12; configuración del software (ver también el KA de la
Tha97: c3,c10] Gestión de Configuración del Software) se documentan
y comunican decisiones a todos los implicados
Se promulga el proceso de medición junto con el importantes, se repasan los planes y si es necesario se
rra
proyecto del software, asegurándose de que se recogen revisan, y todos los datos importantes se graban en la
datos relevantes y útiles (ver también los apartados 6.2 base de datos central (ver también el apartado 6.3
Planificar el Proceso de Medición y 6.3 Realizar el Llevar a cabo el Proceso de Revisión).
Proceso de Medición).
3.6 Informes
3.4 Proceso de Supervisión
[Rei02: c10; Tha97: c3,c10]
[Dor02: v1c8, v2c2-c5,c7; Rei02: c10; Som05:
c25; Tha97: c3;c9] En períodos específicos y concertados, se informa de la
adhesión a los planes dentro de la organización (por
Se evalúa continuamente y a intervalos ejemplo al comité de dirección de cartera del proyecto)
predeterminados la adhesión a los diferentes planes. Se y a los contratistas externos (por ejemplo, clientes,
analizan los resultados y las condiciones de acabado de usuarios). Informes de esta naturaleza deben orientarse
Bo
cada tarea. Se evalúan los entregables en términos de hacia una adhesión global en oposición a los informes
las características que ellos requieren (por ejemplo, por detallados que se requieren frecuentemente dentro del
medio de revisiones y auditorías). Se investiga el equipo de proyecto.
consumo de fuerzas, la adhesión a horarios, y los costes
a día de hoy, y se examina el uso de recursos. Se revisa 4. Revisión y Evaluación
de nuevo el perfil de riesgo del proyecto y se evalúa la
adhesión a los requisitos de calidad. En puntos críticos del proyecto, se evalúan el progreso
global hacia el logro de los objetivos prefijados y la
Se modelan y analizan los datos de medición. Se satisfacción de los requisitos del contratista. De igual
emprende el análisis de variación basado en la modo, en hitos particulares se llevan a cabo
desviación actual de los resultados y valores esperados. valoraciones sobre la efectividad del proceso global
Esto puede darse en forma de desbordamiento de hasta la fecha, del personal involucrado, y de las
costes, equivocaciones en el horario y similares. Se herramientas y métodos utilizados.
lleva a cabo la identificación de la desviación y el
análisis de calidad y otros datos de medición (por 4.1 Determinar la Satisfacción de los Requisitos
ejemplo, el análisis de la densidad de los defectos). Se
recalculan la exposición a riesgos y sus influencias y se [Rei02: c10; Tha97: c3,c10]
ejecutan de nuevo los árboles de decisiones, las Ya que uno de nuestros objetivos principales consiste
simulaciones, etc., a la luz de los nuevos datos. Estas en lograr la satisfacción del contratista (usuario o
actividades permiten la detección de problemas y la cliente), es importante que el progreso hacia este
identificación de excepciones basada en la superación
objetivo sea evaluado formal y periódicamente. Esto 5.2 Actividades de Cierre
ocurre al lograr los principales hitos del proyecto (por
[Pf101: c12; Som05: c4]
ejemplo, la confirmación de la arquitectura del diseño
de software, la revisión técnica de la integración del Tras haberse confirmado el cierre, se archivan los
software). Se identifican variaciones a las expectativas materiales del proyecto de acuerdo a los métodos,
y se llevan a cabo acciones adecuadas. Al igual que en localización y duración pactados con los contratistas.
la actividad de control del proceso arriba indicada (ver La base de datos de medición de la organización se
el apartado 3.5 Proceso de Control), en todos los casos, pone al día con los datos finales del proyecto y se
se adhiere al control de cambios y a los procedimientos emprenden análisis post-proyecto. Se inicia un proyecto
de gestión de configuración del software (ver también post mortem con el fin de analizar los temas, problemas
el KA de la Gestión de Configuración del Software) se y oportunidades encontrados durante el proceso
documentan y comunican decisiones a todos los (particularmente por medio de revisiones y
implicados importantes, se repasan los planes y si es evaluaciones, ver el subárea 4 Revisión y Evaluación) y
necesario se revisan, y todos los datos importantes se se sacan lecciones del proceso que luego alimentan los
graban en la base de datos central (ver también el conocimientos de la organización y los intentos de
r
apartado 6.3 Llevar a cabo el Proceso de Revisión). Se mejora (ver también el KA del Proceso de Ingeniería
puede encontrar más información en el KA de las del Software).
Pruebas del Software, en el apartado 2.2 Objetivos de
do
las Pruebas y en el KA de la Calidad del Software, en 6. Medidas de la Ingeniería del Software
el apartado 2.3 Revisiones y Auditorías.
[ISO 15939-02]
4.2 Revisar y Evaluar la Ejecución La importancia de la medición y su papel en las buenas
[Dor02: v1c8,v2c3,c5; Pfl01: c8,c9; Rei02: c10; prácticas de gestión está ampliamente reconocido, y es
Tha97: c3,c10] tal que su importancia sólo puede aumentar en los
próximos años. Medir con eficacia se ha convertido en
Las revisiones periódicas de lo realizado, dirigidas al una de las piedras angulares de la madurez de una
personal del proyecto, proporcionan detalles sobre la organización. Las palabras claves para la medición del
probabilidad de ser fiel a los planes así como sobre las software y para los métodos de medición fueron
posibles áreas de dificultad (por ejemplo, conflictos definidas en [ISO15939-02] basadas en el vocabulario
rra
entre miembros del equipo). Se evalúan los distintos internacional de metrología ISO [ISO93]. No obstante,
métodos, herramientas y técnicas empleadas para ver su los lectores encontrarán en la literatura existente
eficacia y adecuación, y se valora sistemática y diferencias en la terminología; por ejemplo, el término
periódicamente el propio proceso para conocer su "métrica" a veces se usa en lugar de "medición".
relevancia, utilidad y eficacia en el contexto del
proyecto. Cuando se juzga necesario, se llevan a cabo y Este apartado sigue el estándar internacional ISO/IEC
se gestionan los cambios. 15939, que describe el proceso que define las
actividades y tareas necesarias para implementar un
proceso de medición e incluye, asimismo, un modelo de
5. Cierre
medición de la información.
El proyecto llega a su fin cuando todos los planes y
procesos implicados se han promulgado y completado. 6.1 Establecer y Sostener el Compromiso de Medir
Bo
r
proceso de medición (tales como usuario, analista y El plan de medición debe ser revisado y
bibliotecario) y el proporcionar una financiación, aprobado por los contratistas adecuados. Esto
entrenamiento, herramientas, y apoyo adecuados incluye todos los procedimientos de
do
para dirigir el proceso de un modo perdurable. recolección de datos y los procedimientos de
almacenamiento, análisis e informes; los
criterios de evaluación; horarios y
6.2 Planificar el Proceso de Medición
responsabilidades. Los criterios para revisar
Caracterizar la unidad organizacional. La unidad estos artefactos tendrían que haberse
organizacional proporciona el contexto para la establecido a un nivel de unidad
medición así que es importante hacer explícito este organizacional o superior y debieran usarse
contexto y articular las presunciones que éste como base para estas revisiones. Tales criterios
incluye y las restricciones que va imponiendo. La deben tomar en cuenta experiencias anteriores,
caracterización puede darse en términos de disponibilidad de recursos, y trastornos
procesos organizacionales, dominios de potenciales del proceso cuando se proponen
rra
aplicaciones, tecnología e interfaces cambios a las prácticas actuales. La aprobación
organizacionales. Un modelo de proceso demuestra que existe un compromiso con el
organizacional también es por lo general un proceso de medición [ISO15939-02: 5.2.6.1 y
elemento de una caracterización de la unidad Apéndice F].
organizacional [ISO15939-02: 5.2.1].
- Hay que hacer que los recursos estén
Identificar las necesidades de información. Las disponibles para implementar las tareas de
necesidades de información se basan en las metas, medición planeadas y aprobadas. La
restricciones, riesgos y problemas de la unidad disponibilidad de los recursos puede
organizacional. Éstas pueden proceder de objetivos organizarse en aquellos casos en donde los
comerciales, organizacionales, reguladores y/o del cambios han de pilotarse antes de un amplio
producto. Deben ser identificadas y deben despliegue. Se debe prestar atención a los
Bo
r
almacenar datos [ISO 1539-02: 5.3.2]. Apéndice D].
Analizar datos y desarrollar productos de Evaluar el proceso de medición. Evaluar el proceso
información. Se pueden agregar, transformar o de medición contrastándolo con los criterios de
do
recodificar datos como parte del proceso de evaluación específicos y determinar las fuerzas y
análisis, utilizando un grado de rigor adecuado a la debilidades de los procesos. Esto puede realizarlo
naturaleza de los datos y las necesidades de un proceso interno o una auditoría externa y debe
información. Los resultados de este análisis son incluir una retroalimentación de los usuarios de las
indicadores típicos, tales como gráficas, números u mediciones. Grabar las lecciones aprendidas en una
otras indicaciones que han de ser interpretadas, base de datos adecuada [ISO 15939-02: 5.4.1 y
dando lugar a conclusiones iniciales que han de Apéndice D].
presentar los contratistas. Los resultados y
conclusiones han de consultarse, utilizando un Identificar las mejoras potenciales. Tales mejoras
proceso definido por la organización (que puede pueden consistir en cambios en el formato de los
ser formal o informal). Los proveedores de datos y indicadores, cambios en las unidades medidas, o en
rra
los usuarios de las mediciones deben participar en la reclasificación de las categorías. Determinar los
revisar los datos para asegurar que son costes y beneficios de las mejoras potenciales y
significativos y precisos, y que puede llevar a seleccionar las acciones de mejora adecuadas.
acciones razonables [ISO 15939-02: 5.3.3 y Comunicar las mejoras propuestas al dueño del
Apéndice G]. proceso de medición y a los contratistas para su
revisión y aprobación. Comunicar también la falta
de mejoras potenciales si el análisis no identifica
ninguna mejora [ISO 15939-02: 5.4.2].
Bo
MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA
[ISO15239-
[Dor02] [Fen98] [Pfl01] [Pre04] [Rei02] [Som05] [Tha97]
02]
1.Iniciación y Alcance
1.1 Determinación y
v2c4 c4 c7 c5
Negociación de Requisitos
1.2 Viabilidad, Análisis c6 c6
1.3 Construir para Verificar c6
2. Planificación de un
Proyecto Software
2.1 Planificación de un v1c6, v2c7, c1, c3, c3, c4,
c2, c3 c2, c21 c3, c4
Proceso v2c8 c5 c6
r
2.2 Determinar los
c3 c24 c4
entregables
2.3 Esfuerzo, Horario y c23,
v2c7 c12 c3 c5, c6 c4, c23 c5
do
Cálculo del Coste c24
2.4 Reparto de Recursos c3 c24 c8, c9 c4 c6, c7
2.5 Gestión de Riesgos v2c7 c3 c25 c11 c4 c4
2.6 Gestión de Calidad v1c8, c24,
c26 c10 c9, c10
v2c3-c5 c25
2.7 Gestión de Planes c4 c4
3. Promulgación del
Proyecto Software
3.1 Implementación de
c3 c4
Planes
3.2 Gestión de Contratos con
rra
c4
Proveedores
3.3 Implementación de c13, c10,
c22 c3, c10
Procesos para medir c14 c12
3.4 Proceso de Supervisión v1c8,
v2c2-c5, c10 c25 c3, c10
c7
3.5 Proceso de Control v2c7 c10 c3, c9
3.6 Informes c10 c3, c10
4. Revisión y Evaluación
4.1 Determinar la
c10 c3, c10
satisfacción de los Requisitos
Bo
r
and IEC, 2002. [Tha97] R.H. Thayer, ed., Software Engineering Project
Management, IEEE Computer Society Press, 1997,
Chap. 1-10.
do
rra
Bo
APÉNDICE A. LISTA DE LECTURAS ADICIONALES Intensive Projects,‖ IEEE Software, May/June 1997, pp.
83-89.
(Adl99) T.R. Adler, J.G. Leonard, and R.K. Nordgren,
―Improving Risk Management: Moving from Risk (Dav98) A.M. Davis, ―Predictions and Farewells,‖
Elimination to Risk Avoidance,” Information and IEEE Software, July/August 1998, pp. 6-9.
Software Technology, vol. 41, 1999, pp. 29-34.
(Dem87) T. DeMarco and T. Lister, Peopleware:
(Bai98) R. Baines, ―Across Disciplines: Risk, Design, Productive Projects and Teams, Dorset House
Method, Process, and Tools,‖ IEEE Software, Publishing, 1987.
July/August 1998, pp. 61-64.
(Dem96) T. DeMarco and A. Miller, ―Managing Large
(Bin97) R.V. Binder, ―Can a Manufacturing Quality Software Projects,‖ IEEE Software, July 1996, pp. 24-
Model Work for Software?‖ IEEE Software, 27.
September/October 1997, pp. 101-102,105.
(Fav98) J. Favaro and S.L. Pfleeger, ―Making Software
r
(Boe97) B.W. Boehm and T. DeMarco, ―Software Risk Development Investment Decisions,‖ ACM SIGSoft
Management,‖ IEEE Software, May/June 1997, pp. 17- Software Engineering Notes, vol. 23, iss. 5, 1998, pp.
19. 69-74.
do
(Bri96) L.C. Briand, S. Morasca, and V.R. Basili, (Fay96) M.E. Fayad and M. Cline, ―Managing Object-
―Property-Based Software Engineering Measurement,‖ Oriented Software Development,‖ Computer,
IEEE Transactions on Software Engineering, vol. 22, September 1996, pp. 26-31.
iss. 1, 1996, pp. 68-86.
(Fen98) N.E. Fenton and S.L. Pfleeger, Software
(Bri96a) L. Briand, K.E. Emam, and S. Morasca, ―On Metrics: A Rigorous & Practical Approach, second ed.,
the Application of Measurement Theory in Software International Thomson Computer Press, 1998.
Engineering,‖ Empirical Software Engineering, vol. 1,
1996, pp. 61-88. (Fle99) R. Fleming, ―A Fresh Perspective on Old
Problems,‖ IEEE Software, January/February 1999, pp.
rra
(Bri97) L.C. Briand, S. Morasca, and V.R. Basili, 106-113.
―Response to: Comments on ‗Property-based Software
Engineering Measurement: Refining the Addivity (Fug98) A. Fuggetta et al., ―Applying GQM in an
Properties,‘‖ IEEE Transactions on Software Industrial Software Factory,‖ ACM Transactions on
Engineering, vol. 23, iss. 3, 1997, pp. 196-197. Software Engineering and Methodology, vol. 7, iss. 4,
1998, pp. 411-448.
(Bro87) F.P.J. Brooks, ―No Silver Bullet: Essence and
Accidents of Software Engineering,‖ Computer, Apr. (Gar97) P.R. Garvey, D.J. Phair, and J.A. Wilson, ―An
1987, pp. 10-19. Information Architecture for Risk Assessment and
Management,‖ IEEE Software, May/June 1997, pp. 25-
(Cap96) J. Capers, Applied Software Measurement: 34.
Bo
(Gra87) R.B. Grady and D.L. Caswell, Software (Lat98) F. v. Latum et al., ―Adopting GQM-Based
Metrics: Establishing A Company-Wide Program. Measurement in an Industrial Environment,‖ IEEE
Prentice Hall, 1987. Software, January-February 1998, pp. 78-86.
(Hal97) T. Hall and N. Fenton, ―Implementing (Leu96) H.K.N. Leung, ―A Risk Index for Software
Effective Software Metrics Programs,‖ IEEE Software, Producers,‖ Software Maintenance: Research and
March/April 1997, pp. 55-64. Practice, vol. 8, 1996, pp. 281-294.
(Hen99) S.M. Henry and K.T. Stevens, ―Using Belbin‘s (Lis97) T. Lister, ―Risk Management Is Project
Leadership Role to Improve Team Effectiveness: An Management for Adults,‖ IEEE Software, May/June
Empirical Investigation,‖ Journal of Systems and 1997, pp. 20-22.
r
Software, vol. 44, 1999, pp. 241-250.
(Mac96) K. Mackey, ―Why Bad Things Happen to
(Hoh99) L. Hohmann, ―Coaching the Rookie Good Projects,‖ IEEE Software, May 1996, pp. 27-32.
do
Manager,‖ IEEE Software, January/February 1999, pp.
16-19. (Mac98) K. Mackey, ―Beyond Dilbert: Creating
Cultures that Work,‖ IEEE Software, January/February
(Hsi96) P. Hsia, ―Making Software Development 1998, pp. 48-49.
Visible,‖ IEEE Software, March 1996, pp. 23-26.
(Mad97) R.J. Madachy, ―Heuristic Risk Assessment
(Hum97) W.S. Humphrey, Managing Technical Using Cost Factors,‖ IEEE Software, May/June 1997,
People: Innovation, Teamwork, and the Software pp. 51-59.
Process: Addison-Wesley, 1997.
(McC96) S.C. McConnell, Rapid Development: Taming
(IEEE12207.0-96) IEEE/EIA 12207.0- Wild Software Schedules, Microsoft Press, 1996.
rra
1996//ISO/IEC12207:1995, Industry Implementation of
Int. Std. ISO/IEC 12207:95, Standard for Information (McC97) S.C. McConnell, Software Project Survival
Technology-Software Life Cycle Processes, IEEE, Guide, Microsoft Press, 1997.
1996.
(McC99) S.C. McConnell, ―Software Engineering
(Jac98) M. Jackman, ―Homeopathic Remedies for Principles,‖ IEEE Software, March/April 1999, pp. 6-8.
Team Toxicity,‖ IEEE Software, July/August 1998, pp.
43-45. (Moy97) T. Moynihan, ―How Experienced Project
Managers Assess Risk,‖ IEEE Software, May/June
(Kan97) K. Kansala, ―Integrating Risk Assessment with 1997, pp. 35-41.
Cost 8–12 © IEEE – 2004 Version Estimation,‖ IEEE
(Ncs98) P. Ncsi, ―Managing OO Projects Better,‖ IEEE
Bo
(Kar96) D.W. Karolak, Software Engineering Risk (Off97) R.J. Offen and R. Jeffery, ―Establishing
Management, IEEE Computer Society Press, 1996. Software Measurement Programs,‖ IEEE Software,
March/April 1997, pp. 45-53.
(Kau99) K. Kautz, ―Making Sense of Measurement for
Small Organizations,‖ IEEE Software, March/April (Par96) K.V.C. Parris, ―Implementing Accountability,‖
1999, pp. 14-20. IEEE Software, July/August 1996, pp. 83-93.
(Kei98) M. Keil et al., ―A Framework for Identifying (Pfl97) S.L. Pfleeger, ―Assessing Measurement (Guest
Software Project Risks,‖ Communications of the ACM, Editor‘s Introduction),‖ IEEE Software, March/April
vol. 41, iss. 11, 1998, pp. 76-83. 1997, pp. 25-26.
(Ker99) B. Kernighan and R. Pike, ―Finding (Pfl97a) S.L. Pfleeger et al., ―Status Report on Software
Performance Improvements,‖ IEEE Software, Measurement,‖ IEEE Software, March/April 1997, pp.
March/April 1999, pp. 61-65. 33-43.
(Put97) L.H. Putman and W. Myers, Industrial Strength (Sco92) R.L. v. Scoy, ―Software Development Risk:
Software — Effective Management Using Measurement, Opportunity, Not Problem,‖ Software Engineering
IEEE Computer Society Press, 1997. Institute, Carnegie Mellon University CMU/SEI-92-
TR-30, 1992.
(Rob99) P.N. Robillard, ―The Role of Knowledge in
Software Development,‖ Communications of the ACM, (Sla98) S.A. Slaughter, D.E. Harter, and M.S. Krishnan,
vol. 42, iss. 1, 1999, pp. 87-92. ―Evaluating the Cost of Software Quality,‖
Communications of the ACM, vol. 41, iss. 8, 1998, pp.
(Rod97) A.G. Rodrigues and T.M. Williams, ―System 67-73.
Dynamics in Software Project Management: Towards
the Development of a Formal Integrated Framework,‖ (Sol98) R. v. Solingen, R. Berghout, and F. v. Latum,
European Journal of Information Systems, vol. 6, 1997, ―Interrupts: Just a Minute Never Is,‖ IEEE Software,
pp. 51-66. September/October 1998, pp. 97-103.
(Rop97) J. Ropponen and K. Lyytinen, ―Can Software (Whi95) N. Whitten, Managing Software Development
r
Risk Management Improve System Development: An Projects: Formulas for Success, Wiley, 1995.
Exploratory Study,‖ European Journal of Information
Systems, vol. 6, 1997, pp. 41-50. (Wil99) B. Wiley, Essential System Requirements: A
do
Practical Guide to Event-Driven Methods, Addison-
(Sch99) C. Schmidt et al., ―Disincentives for Wesley, 1999.
Communicating Risk: A Risk Paradox,‖ Information
and Software Technology, vol. 41, 1999, pp. 403-411. (Zel98) M.V. Zelkowitz and D.R. Wallace,
―Experimental Models for Validating Technology,‖
Computer, vol. 31, iss. 5, 1998, pp. 23-31.
rra
Bo
APÉNDICE B. LISTA DE ESTÁNDARES
r
(PMI00) Project Management Institute Standards
Committee, A Guide to the Project Management Body
do
of Knowledge (PMBOK), Project Management
Institute, 2000.
rra
Bo
Bo
rra
do
r
CAPÍTULO 9
PROCESO DE INGENIERÍA DEL SOFTWARE
ACRÓNIMOS ingeniería del software. Este es el significado que
se pretende con el título de esta KA y el que se usa
CMMI Modelo de Capacidad de Madurez Integrado con más frecuencia en la descripción del KA.
EF Creadora de Experiencia
FP Punto Función Finalmente, un tercer significado podría referirse al
HRM Gestión de Recursos Humanos conjunto actual de actividades realizadas dentro de
IDEAL (Modelo de) Iniciación-Diagnóstico- una organización, que podría verse como un solo
r
Establecimiento-Actuación-Apoyo proceso, especialmente desde dentro de la
OMG Grupo de Gestión de Objetos organización. Se utiliza este significado en el KA
QIP Paradigma de Mejoras de la Calidad en muy pocos casos.
do
SCAMPI Evaluación Basada en el MCM para Mejoras Esta KA se aplica a cualquier parte de la gestión de los
de los Procesos utilizando la CMMI procesos del ciclo de vida del software en la que se
SCE Evaluación de la Capacidad del Software introduzcan cambios de procedimiento o tecnológicos
SEPG Grupo de Proceso de la Ingeniería del para la mejora de procesos o productos.
Software
Los procesos de ingeniería del software tienen
INTRODUCCIÓN importancia no sólo para las grandes organizaciones.
El KA del Proceso de Ingeniería del Software puede Más aún, las actividades relacionadas con los procesos
examinarse en dos niveles. El primer nivel engloba las pueden ser, y han sido, realizadas con éxito por
actividades técnicas y de gestión dentro de los procesos pequeñas organizaciones, equipos e individuos.
rra
del ciclo de vida del software realizadas durante la El objetivo de gestionar los procesos del ciclo de vida
adquisición, desarrollo, mantenimiento y retirada del del software es implementar nuevos o mejores procesos
software. El segundo es un meta-nivel, que se refiere a en las prácticas actuales, sean éstos individuales,
la definición, implementación, valoración, medición, proyectos u organizacionales.
gestión, cambios y mejoras de los procesos mismos del
ciclo de vida del software. El primer nivel lo cubren las Esta KA no aborda explícitamente la Gestión de
otras KAs en la Guía. Este KA se ocupa del segundo Recursos Humanos (HRM), por ejemplo, como lo
nivel. recoge el MCM de la Gente (Cur02) y procesos de
ingeniería de sistemas [ISO1528-028; IEEE 1220-98].
El término ―proceso de ingeniería del software‖ puede
interpretarse de diversas maneras, y esto puede llevar a También debería reconocerse que muchos temas de
confusiones. procesos de ingeniería del software están relacionados
Bo
Aquí se describe la situación en la que los procesos se del esfuerzo del proceso de ingeniería del software.
despliegan por primera vez (por ejemplo, introduciendo Puede que haya que establecer diversos comités, tales
un proceso de inspección en un proyecto o un método como un comité de dirección que supervise el esfuerzo
Bo
que cubra todo el ciclo de vida), y donde se cambian los del proceso de ingeniería del software.
procesos actuales (por ejemplo, introduciendo una
En [McF96] se ofrece una descripción de la
herramienta u optimizando un procedimiento). A esto
infraestructura de la mejora de los procesos en general.
también se le puede denominar proceso de evolución.
En la práctica se utilizan dos tipos principales de
En ambos casos hay que modificar las prácticas
infraestructura: el Grupo de Proceso de Ingeniería del
actuales. Si resulta que se extienden las modificaciones,
Software y la Creadora de Experiencia.
puede que también sean necesarios cambios en la
cultura organizacional. 1.1.1 Grupo de Proceso de la Ingeniería del
Software (SEPG)
1.2. Infraestructura del Proceso
[IEEE12207.0-96; ISO15504; SEL96] Se pretende que el SEPG sea el foco central del proceso
de mejoras de la ingeniería del software y tiene cierto
Este tópico incluye el conocimiento relacionado con la
número de responsabilidades en términos de
infraestructura del proceso de ingeniería del software.
inicialización y mantenimiento. Éstos se describen en
Para establecer procesos de ciclo de vida del software, [Fow90].
es necesario que la adecuada infraestructura esté en su
1.1.2 Creadora de Experiencia (EF)
lugar, es decir que los recursos estén al alcance de la
mano (personal competente, herramientas y El concepto de EF separa la organización del proyecto
financiación) y que se hayan asignado (la organización del desarrollo del software, por
responsabilidades. El que se hayan completado estas ejemplo) de la organización de las mejoras. La
tareas, indica el compromiso con la gestión y propiedad organización del proyecto se centra en el desarrollo y en
el mantenimiento del software, mientras que la EF se Consideraciones Prácticas
ocupa del proceso de mejoras de la ingeniería del
El proceso de implementación y cambios constituye una
software.
instancia del cambio organizacional. Los esfuerzos de
Se trata de que la EF institucionalice el aprendizaje más éxito en los cambios organizacionales tratan del
colectivo de una organización, desarrollando, cambio como un proyecto en toda regla, con planes
actualizando, y entregando a la organización del adecuados, monitoreo y revisiones.
proyecto los paquetes de experiencia (por ejemplo,
En [Moi98; San98; Sti99] se encuentran las directrices
guías, modelos y cursos de entrenamiento), también
sobre el proceso de implementación y cambios dentro
conocidos como validaciones de procesos. La
de las organizaciones de ingeniería del software,
organización del proceso ofrece a la EF sus productos,
incluyendo la planificación de las acciones,
los planes utilizados en su desarrollo, y los datos
entrenamientos, gestión de patrocinadores,
reunidos durante su desarrollo y operación. En [Bas92]
compromisos, y la selección de proyectos piloto, y
se presentan ejemplos de paquetes de experiencia.
abarcan tanto los procesos como las herramientas. En
Ciclo de Gestión del Proceso del [EIE99a] se señalan los estudios empíricos sobre
r
Software factores de éxito para los cambios en los procesos.
[Bas92; Fow90; IEEE12207.0-96; ISO15504-98;
El papel de los agentes de cambio en esta actividad se
McF96; SEL96]
discute en (Hut94). El proceso de implementación y
do
La gestión de los procesos del software consiste en cambios puede verse asimismo como una instancia de
cuatro actividades secuenciadas en un ciclo iterativo consultoría (sea interna o externa).
permitiendo una retroalimentación continua y mejoras
Uno también puede ver cambios organizacionales desde
del proceso del software:
la perspectiva de la transferencia de tecnología (Rog83).
La actividad del Establecimiento de la Los archivos de ingeniería del software que se ocupan
Infraestructura de un Proceso consiste en establecer de la transferencia de tecnología y de las características
un acuerdo con el proceso de implementación y de los recipientes de nuevas tecnologías (que podrían
cambios (que incluya la obtención de la gestión de incluir tecnologías relacionadas con los procesos) son
compra buy-in) y levantar una adecuada (Pfl99; Rag89).
infraestructura (recursos y responsabilidades) para
rra
Hay dos formas de acercarse la evaluación de un
que tenga lugar.
proceso de implementación y cambios, sea en términos
El propósito de la actividad de Planificación es de cambios al proceso mismo o en términos de cambios
comprender los objetivos de las empresas actuales en las salidas de los procesos (por ejemplo, midiendo lo
y las necesidades del proceso del individuo, que te devuelve una inversión tras realizar un cambio).
proyecto u organización, para identificar sus Una visión pragmática de lo que se puede lograr con
fuerzas y flaquezas, y elaborar un plan para el estas evaluaciones se nos da en (Her98).
proceso de implementación y cambios.
El propósito del Proceso de Implementación y Las investigaciones sobre cómo evaluar el proceso de
Cambios consiste en llevar a cabo el plan, implementación y cambios, y los ejemplos de estudios
desplegar nuevos procesos (que pueden implicar, dedicados a ello, se encuentran en [Gol99], (Kit98;
por ejemplo, el desarrollo de herramientas y el Kra99; McG94).
Bo
r
se encuentran en [Como97], (Dav88), y hay un método Se pueden describir los procesos en diferentes niveles
para seleccionar entre muchos de ellos en (Ale91). de abstracción (por ejemplo, definiciones genéricas
contrapuestas a definiciones adaptadas, descriptivas
Procesos del Ciclo de Vida del
contrapuestas a prescriptivas contrapuestas a
do
Software
proscriptivas [Pf101].
Las definiciones de los procesos de ciclo de vida del
Varios elementos de un proceso pueden definirse, por
software tienden a ser más detalladas que los modelos
ejemplo, actividades, productos (artefactos), y recursos.
de ciclo de vida del software. Sin embargo, los procesos
Los marcos detallados que estructuran los tipos de
del ciclo de vida del software no pretenden ordenar sus
información requeridos para definir los procesos están
procesos en el tiempo. Esto significa que, en línea de
descritos en (Mad94).
principio, los procesos del ciclo de vida del software
pueden ordenarse para tener cabida en cualquiera de los Existen algunas notaciones que se utilizan para definir
modelos del ciclo de vida del software. La principal procesos (SPC92). Una diferencia clave entre ellas
referencia sobre esta área se encuentra en IEEE/EIA reside en el tipo de información que definen, capturan y
rra
12207.0: Información Tecnológica – Procesos del Ciclo utilizan los marcos mencionados anteriormente. El
de Vida del Software [IEEE 12207.0-96]. ingeniero del software debería ser consciente de las
siguientes aproximaciones al asunto: diagramas de flujo
El estándar IEEE 1074:1997 para desarrollar procesos
de datos, en términos de la finalidad del proceso y de
de ciclo de vida ofrece también una lista de procesos y
las salidas [ISO15504-98], como una lista de procesos
actividades para el desarrollo y el mantenimiento del
descompuestos en actividades constituyentes y tareas
software [IEEE1074-97], además de ofrecer una lista de
definidas en lenguaje natural [IEEE12207.0-96],
actividades del ciclo de vida que pueden mapearse hacia
Gráficos de Estados (Har98), EVTX (Rad85), modelado
procesos y organizarse del mismo modo que cualquiera
de Dependencia del Actor (Yu94), notación SADT
de los modelos de ciclo de vida del software. Además,
(Mcg93), redes Petri (Ban95); IDEF0 (IEEE 1320.1-
identifica y une a estas actividades otros estándares de
98), y los basados en reglas (Bar95). Más
software IEEE. En línea de principio, el estándar IEEE
recientemente, un estándar de modelado del proceso ha
Bo
r
cómo aplicar Internet al suministro de una guía de un
torno a las valoraciones CMMI [SEI01]. Las
proceso en tiempo real está descrita en (Kel98).
actividades realizadas durante una valoración, la
9. Valoración del Proceso distribución de esfuerzos en estas actividades, así como
do
la atmósfera durante una valoración son muy diferentes
La valoración del proceso se lleva a cabo utilizando
dependiendo de que sean para una mejora o para la
tanto un modelo de valoración como un método de
adjudicación de un contrato.
valoración. En algunas instancias, el término
―apreciación‖ se utiliza en vez de valoración, y el Se han criticado los modelos y métodos de las
término ―evaluación de la capabilidad‖ se utiliza valoraciones de los procesos, por ejemplo (Fay97;
cuando la apreciación tiene como propósito la Gra98). La mayoría de estas críticas se refieren a la
adjudicación de un contrato. evidencia empírica que apoya el uso de modelos y
métodos de valoración. Sin embargo, desde la
Modelos de Valoración del Proceso
publicación de estos artículos, ha existido alguna
Un modelo de valoración recoge lo que se reconoce evidencia sistemática que apoyaba la eficacia de las
rra
como buenas prácticas. Estas prácticas pueden referirse valoraciones de los procesos (Cla97; Ele00; Ele00a;
sólo a las actividades técnicas de ingeniería del Kri99).
software, o puede que se refieran también, por ejemplo,
10. Medición de los Procesos y Productos
a actividades de gestión, de ingeniería de sistemas, y
también de gestión de recursos humanos. Mientras que la aplicación de mediciones a la ingeniería
del software puede resultar compleja, particularmente
La ISO/IEC 15504 [ISO155‘04-98] define un modelo
en términos de métodos de modelado y análisis, existen
ejemplar de valoración y de requisitos de conformidad
varios aspectos de las mediciones en la ingeniería del
con otros modelos de valoración. Los modelos de
software que resultan fundamentales y que están a la
valoración específicos disponibles y en uso son SW-
base de muchos de los procesos de medición y análisis
CMM (SEI95), CMMI [SEI01], y Bootstrap [Sti99]. Se
más avanzados. Más aún, los esfuerzos para mejorar el
han definido muchos otros modelos de capacidad y
logro de procesos y productos sólo pueden valorarse si
Bo
r
es útil para gestionar un proyecto de ingeniería del
software. Aquí, el enfoque está en la medición del
proceso con el propósito de la implementación y
cambio del proceso.
do
El diagrama de caminos de la Figura 2 ilustra algo que
se dar por supuesto en la mayoría de los proyectos de
ingeniería del software, que indica que normalmente el
proceso tiene un impacto en los resultados de un
proyecto.
No todo proceso va a tener un impacto positivo en todas
sus salidas. Por ejemplo, la introducción de Figura 2 Diagrama que muestra la relación entre un
inspecciones del software puede reducir esfuerzos y proceso y los resultados obtenidos
costes de las pruebas, pero puede incrementar el tiempo
Medida del Producto Software
rra
de espera si cada inspección introduce largas esperas a
causa de haber calendarizado reuniones de larga [ISO9126-01]
inspección (Vot93). Por tanto, es preferible utilizar
medidas para salidas de múltiples procesos que resultan La medición de un producto software incluye,
importantes para la organización de la empresa. principalmente, la medición del tamaño del producto, la
estructura del producto y la calidad del producto.
Mientras que se pueden hacer algunos esfuerzos para
valorar la utilización de herramientas y de hardware, el 4.1.1 Medición del Tamaño
recurso principal que necesita ser gestionado en la
ingeniería del software es el personal. Como resultado El tamaño de un producto software es evaluado a
de esto, las principales mediciones del interés son menudo mediante medidas de longitud (por ejemplo,
aquéllas relacionadas con la productividad de los líneas de código fuente en un módulo, páginas en
documento de especificación de los requisitos del
Bo
r
descritos en la ISO 9126, de la parte 1 a la parte 4 4.3.1 Creación de Modelos
[ISO9126-01]. [Fen98: c9,c10; Pre04: c15; Som05: La creación de modelos incluye la calibración y la
c24] evaluación del modelo. El objetivo aproximado al que
do
nos dirigimos son informes de medidas del proceso de
construcción de un modelo hasta que los modelos son
4.2. Calidad de los Resultados de Medición construidos para así resolver las cuestiones importantes
Los resultados de la medición de la calidad (precisión, y conseguir las mejoras del software propuestas. Este
reproducibilidad, repitibilidad, convertibilidad, proceso es está también influenciado por las
medición aleatoria de errores) son primordiales para la limitaciones de unas escalas particulares de medición en
medida de los programas para proveer resultados relación con el método de análisis seleccionado. Los
efectivos y estables. Las características clave de los modelos son calibrados (mediante el uso de ciertas
resultados de la medición y la calidad relacionada con observaciones relevantes, como por ejemplo, proyectos
los instrumentos de medición definidos en vocabulario recientes, proyectos en los cuales se han utilizado
rra
internacional de metrología [VIM93] de la ISO. tecnologías similares) y su efectividad es evaluada (por
ejemplo, mediante pruebas de su rendimiento en
La teoría de la medición establece la base en qué algunas muestras). [Fen98: c4,c6,c13;Pfl01:
medidas significativas pueden ser creadas. La teoría de c3,c11,c12;Som05: c25]
la medición y los tipos de escalas son discutidas en
[Kan02]. La medición es definida en la teoría como ―la
asignación de números a los objetos de una forma 4.3.2 Implementación de Modelos
sistemática para presentar las propiedades de los
objetos.‖ La implementación de modelos incluye interpretación y
refinamiento de modelos- los modelos calibrados son
Una apreciación de las escalas para la medición del usados en los procesos, sus resultados son interpretados
software y la implicación de cada tipo de escala en y evaluados en el contexto del proceso/proyecto, y los
relación a la posterior selección de métodos de análisis modelos son luego redefinidos donde sea apropiado.
Bo
de información es especialmente importante. [Fen98: c6; Pfl01: c3,c11, c12; Pre04: c22; Som05:
[Abr96; Fen98: c2; Pfl01: c11] Las escalas c25]
significativas son mencionadas en una clasificación de
escalas. Para aquellas, la teoría de medición ofrece una
sucesión de más y más caminos obligatorios de 4.4 Técnicas de Medición del Proceso
asignación de medidas. Si los números asignados son Las técnicas de medición deben ser usadas para analizar
simplemente para ofrecer etiquetas para clasificar los los procesos de ingeniería del software y para la
objetos, entonces son llamados nominales. Si son identificación de las fortalezas y debilidades. Esto
asignados de tal forma que clasifique los objetos (por puede ser desempeñado para iniciar la implementación
ejemplo, bueno, mejor, el mejor), son llamados y cambio del proceso, o para evaluar las consecuencias
ordinales. Si son tratados con magnitudes de la de la implementación y el cambio en el proceso.
propiedad relativa a la unidad de medición definida, son
llamados intervalos (y los intervalos son uniformes La calidad de los resultados medidos, como la
entre los números; si no, entonces serán aditivos). Las exactitud, repetitividad, y la reproductibilidad, son
medidas están el nivel del ratio si tienen un punto de asuntos de medición en el proceso de ingeniería del
cero absoluto, por lo que las distancias de los ratios al software, ya que están basados en instrumentos y
punto cero son significativas. mediciones críticas, como por ejemplo, cuando un
asesor asigna una puntuación a un proceso en particular.
Un método y una forma de conseguir calidad en las resultados deseables. Estudios observacionales
mediciones se puede encontrar en [Gol99]. pueden también proveer una útil retroalimentación
para identificar las mejoras de los procesos.
Las técnicas de medición de procesos han sido
(Agr99)
clasificadas dentro de dos tipos generales: analíticas y
puntos de referencia. Los dos tipos de técnicas puedes
ser usados conjuntamente ya que están basados en
distinto tipo de información. (Car91) La Clasificación del Defecto Ortogonal es una
técnica que puede ser usada para enlazar los errores
encontrados con causas potenciales. Depende de las
vinculaciones entre tipos y disparadores de errores.
4.4.1 Técnicas Analíticas
(Chi92; Chi96) En la clasificación de errores (o
Las técnicas analíticas se caracterizan por depender de anomalías), el Estándar IEEE puede ser útil en este
―la evidencia cuantitativa para determinar dónde son contexto (Estándar IEEE para la Clasificación de
necesarias unas mejoras y si una iniciativa de mejora ha Anomalías del Software (IEEE1044-93).
tenido éxito‖. El tipo analítico es ejemplificado por el
r
Paradigma de la Mejora de la Calidad (QIP), que
consiste en un círculo de entendimiento, evaluación y El Análisis de Causas desde la Raíz es otra técnica
empaquetado [SEL96]. Las técnicas presentadas a analítica común que se utiliza en la práctica. Ésta
do
continuación son pretendidas como otros ejemplos de tiene su origen desde los problemas detectados (por
técnicas analíticas, y reflejan que está hecho en la ejemplo, errores) para detectar las causas del
práctica. [Fen98; Mus99], (Lyu96; Wei93; Zel98) Si proceso, con el propósito de cambiar el proceso
una organización específica usa o no todas estas para evitar estos problemas en el futuro. Se pueden
técnicas dependerá, al menos parcialmente, en su encontrar ejemplos para distintos tipos de procesos
madurez. en (Col93; Ele97; Nak91).
inicial sobre el rendimiento del proceso actual en el contexto de la ingeniería del software es
necesita ser recogida como base a la simulación. presentada en (Flo99).
El Informe de Definición del Proceso es un medio El Proceso Personal de Software define una serie
por el cual la definición de un proceso (si es de mejoras a una práctica de desarrollo
descriptivo, o preceptivo, o ambos) es revisado, e individualizada en un orden específico [Hum95].
identificadas las deficiencias y las mejoras Es un proceso que va desde abajo arriba en el
potenciales del proceso. Ejemplos típicos de esto sentido que estipula una colección de información
son presentados en (Ban95; Kel98). Un camino personal y las mejoras basadas en la interpretación
operacional sencillo para analizar el proceso es de la información.
compararlo con un estándar existente (nacional,
internacional, o entidad profesional), como
IEEE/EIA 12207.0 [IEEE12207.0-96]. Con esta 4.4.2 Técnicas de Bancos de Pruebas
aproximación, la información cuantitativa no es La segunda técnica, bancos de prueba, ―depende de la
recogida del proceso, o, si hay, juegan un rol de identificar una organización ‗excelente‘ en un campo y
apoyo. La definición de los análisis de en la documentación de sus prácticas y herramientas.‖
rendimiento individual de los procesos utilizan su El banco de pruebas asume que si una organización
conocimiento y capacidades para decidir qué menos competente adopta las prácticas de la
cambios en los procesos deberían conducir a
organización excelente, ella también llegará a ser
excelente. Los bancos de pruebas engloban la
evaluación de la madurez de una organización o de la
capacidad de sus procesos. Eso se simplifica por el
trabajo de evaluación del proceso software. Se puede
ver una introducción general de evaluaciones de
procesos y su aplicación en (Zah98).
r
do
rra
Bo
MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA
[OMG02]
[Com97]
[McF96]
[Som05]
[Mus99]
[SEL96]
[Fow90]
[Moi98]
[Abr96]
[Fen98]
[Boe03]
[San98]
[SEI01]
[Bec99]
[Bas92]
[Joh99]
[Pre04]
[Fin94]
Gol99]
[Pfl01]
[Sti99]
r
1.Proceso de Implementación y Cambios
do
1.1Infraestructura del Proceso * *
1.2 Ciclo de Gestión del Proceso Software * * * *
1.3 Modelos para el Proceso de Implementación y
* * *
Cambios
1.4 Consideraciones Prácticas * * *
2.Definición de Procesos * *
2.1Modelos de Ciclo de Vida del Software *
rra
2.2Procesos del Ciclo de Vida del Software * * c2
2.3Notaciones para la Definición de Procesos
2.4 Adaptación del Proceso * c2
2.5Automatización *
IEEE12207
IEEE14143
IEEE 1044
IEEE 1061
IEEE 1074
IEEE 1219
IEEE 1517
IEEE 1540
ISO9000-3
ISO14764
ISO15504
ISO15288
ISO15939
ISO19761
ISO20926
ISO20969
ISO VIM
ISO9001
ISO9126
r
.1
1.Proceso de Implementación y Cambios
do
1.1Infraestructura del Proceso * *
1.2 Ciclo de Gestión del Proceso Software * *
1.3 Modelos para el Proceso de Implementación y Cambios
1.4 Consideraciones Prácticas
2.Definición de Procesos
2.1Modelos de Ciclo de Vida del Software
2.2Procesos del Ciclo de Vida del Software * * * * * * * * *
rra
2.3Notaciones para la Definición de Procesos *
2.4 Adaptación del Proceso *
2.5Automatización
r
pp. 57-66. [Moi98] D. Moitra, ―Managing Change for Software
[Com97] E. Comer, ―Alternative Software Life Cycle Process Improvement Initiatives: A Practical Experience
Models,‖ presented at International Conference on Based Approach,‖ Software Process — Improvement and
do
Software Engineering, 1997. Practice, vol. 4, iss. 4, 1998, pp. 199-207.
[ElE99] K. El-Emam and N. Madhavji, Elements of [Mus99] J. Musa, Software Reliability Engineering: More
Software Process Assessment and Improvement, IEEE Reliable Software, Faster Development and Testing,
Computer Society Press, 1999. McGraw-Hill, 1999.
[Fen98] N.E. Fenton and S.L. Pfleeger, Software Metrics: [OMG02] Object Management Group, ―Software Process
A Rigorous & Practical Approach, second ed., Engineering Metamodel Specification,‖ 2002, available at
International Thomson Computer Press, 1998. http://www.omg.org/docs/formal/02-11-14.pdf.
[Fin94] A. Finkelstein, J. Kramer, and B. Nuseibeh, [Pfl01] S.L. Pfleeger, Software Engineering: Theory and
―Software Process Modeling and Technology,‖ Research Practice, second ed., Prentice Hall, 2001.
Studies Press Ltd., 1994.
rra
[Pre04] R.S. Pressman, Software Engineering: A
[Fow90] P. Fowler and S. Rifkin, Software Engineering Practitioner’s Approach, sixth ed., McGraw-Hill, 2004.
Process Group Guide, Software Engineering Institute, [San98] M. Sanders, ―The SPIRE Handbook: Better,
Technical Report CMU/SEI-90-TR-24, 1990, available at Faster, Cheaper Software Development in Small
http://www.sei.cmu.edu/pub/documents/90.reports/pdf/tr2 Organisations,‖ European Commission, 1998.
4.90.pdf.
[SEI01] Software Engineering Institute, ―Capability
[Gol99] D. Goldenson et al., ―Empirical Studies of Maturity Model Integration, v1.1,‖ 2001, available at
Software Process Assessment Methods,‖ presented at http://www.sei.cmu.edu/cmmi/cmmi.html.
Elements of Software Process Assessment and
Improvement, 1999. [SEL96] Software Engineering Laboratory, Software
Process Improvement Guidebook, NASA/GSFC,
[IEEE1074-97] IEEE Std 1074-1997, IEEE Standard for Technical Report SEL-95-102, April 1996, available at
Bo
r
(Boe03a) B. Boehm and R. Turner, Balancing Agility and
(Flo99) W. Florac and A. Carleton, Measuring the
Discipline: A Guide for the Perplexed, Addison-Wesley,
Software Process: Statistical Process Control for Software
2003.
Process Improvement, Addison-Wesley, 1999.
do
(Bur99) I. Burnstein et al., ―A Testing Maturity Model for
(Gar96) P. Garg and M. Jazayeri, ―Process-Centered
Software Test Process Assessment and Improvement,‖
Software Engineering Environments: A Grand Tour,‖
Software Quality Professional, vol. 1, iss. 4, 1999, pp. 8-
Software Process, A. Fuggetta and A. Wolf, eds., John
21.
Wiley & Sons, 1996.
(Chi92) R. Chillarege et al., ―Orthogonal Defect
(Gra97) R. Grady, Successful Software Process
Classification - A Concept for In-Process Measurement,‖
Improvement, Prentice Hall, 1997.
IEEE Transactions on Software Engineering, vol. 18, iss.
11, 1992, pp. 943-956. (Gra88) E. Gray and W. Smith, ―On the Limitations of
Software Process Assessment and the Recognition of a
(Chi96) R. Chillarege, ―Orthogonal Defect Classification,‖
Required Re-Orientation for Global Process
Handbook of Software Reliability Engineering, M. Lyu,
Improvement,‖ Software Quality Journal, vol. 7, 1998, pp.
rra
ed., IEEE Computer Society Press, 1996.
21-34.
(Col93) J. Collofello and B. Gosalia, ―An Application of
(Har98) D. Harel and M. Politi, Modeling Reactive
Causal Analysis to the Software Production Process,‖
Systems with Statecharts: The Statemate Approach,
Software Practice and Experience, vol. 23, iss. 10, 1993,
McGraw-Hill, 1998.
pp. 1095-1105.
(Her98) J. Herbsleb, ―Hard Problems and Hard Science:
(Cur02) B. Curtis, W. Hefley, and S. Miller, The People
On the Practical Limits of Experimentation,‖ IEEE TCSE
Capability Maturity Model: Guidelines for Improving the
Software Process Newsletter, vol. 11, 1998, pp. 18-21,
Workforce, Addison-Wesley, 2002.
available at http://www.seg.iit.nrc.ca/SPN.
(Dav88) A. Davis, E. Bersoff, and E. Comer, ―A Strategy
(Hum95) W. Humphrey, A Discipline for Software
for Comparing Alternative Software Development Life
Engineering, Addison-Wesley, 1995.
Cycle Models,‖ IEEE Transactions on Software
Bo
Engineering, vol. 14, iss. 10, 1988, pp. 1453-1461. (Hum99) W. Humphrey, An Introduction to the Team
Software Process, Addison-Wesley, 1999.
(Dun96) D. Dunnaway and S. Masters, ―CMM-Based
Appraisal for Internal Process Improvement (Hut94) D. Hutton, The Change Agent’s Handbook: A
Survival Guide for Quality Improvement Champions,
(CBA IPI): Method Description,‖ Software Engineering
Irwin, 1994.
Institute CMU/SEI-96-TR-007, 1996, available at
http://www.sei.cmu.edu/pub/documents/96.reports/pdf/tr0 (Kan02) S.H. Kan, Metrics and Models in Software
07. 96.pdf. Quality Engineering, second ed., Addison-Wesley, 2002.
(EIA/IS731-99) EIA, ―EIA/IS 731 Systems Engineering (Kel98) M. Kellner et al., ―Process Guides: Effective
Capability Model,‖ 1999, available at Guidance for Process Participants,‖ presented at the 5th
http://www.geia.org/eoc/G47/index.html. International Conference on the Software Process, 1998.
(ElE-97) K. El-Emam, D. Holtje, and N. Madhavji, (Kit98) B. Kitchenham, ―Selecting Projects for
―Causal Analysis of the Requirements Change Process for Technology Evaluation,‖ IEEE TCSE Software Process
a Large System,‖ presented at Proceedings of the Newsletter, iss. 11, 1998, pp. 3-6, available at
International Conference on Software Maintenance, 1997. http://www.seg.iit.nrc.ca/SPN.
(ElE-99a) K. El-Emam, B. Smith, and P. Fusaro, ―Success (Kra99) H. Krasner, ―The Payoff for Software Process
Factors and Barriers in Software Process Improvement: An Improvement: What It Is and How to Get It,‖ presented at
Empirical Study,‖ Better Software Practice for Business Elements of Software Process Assessment and
Improvement, 1999.
(Kri99) M.S. Krishnan and M. Kellner, ―Measuring (Rad85) R. Radice et al., ―A Programming Process
Process Consistency: Implications for Reducing Software Architecture,‖ IBM Systems Journal, vol. 24, iss. 2, 1985,
Defects,‖ IEEE Transactions on Software Engineering, pp. 79-90.
vol. 25, iss. 6, November/December 1999, pp. 800-815.
(Rag89) S. Raghavan and D. Chand, ―Diffusing Software-
(Lyu96) M.R. Lyu, Handbook of Software Reliability Engineering Methods,‖ IEEE Software, July 1989, pp. 81-
Engineering, Mc-Graw-Hill/IEEE, 1996. 90.
(Mad94) N. Madhavji et al., ―Elicit: A Method for (Rog83) E. Rogers, Diffusion of Innovations, Free Press,
Eliciting Process Models,‖ presented at Proceedings of the 1983.
Third International Conference on the Software Process,
(Sch99) E. Schein, Process Consultation Revisited:
1994.
Building the Helping Relationship, Addison-Wesley, 1999.
(Mas95) S. Masters and C. Bothwell, ―CMM Appraisal
(SEI95) Software Engineering Institute, The Capability
Framework - Version 1.0,‖ Software Engineering Institute
Maturity Model: Guidelines for Improving the Software
CMU/SEI-TR-95-001, 1995, available at
Process, Addison-Wesley, 1995.
http://www.sei.cmu.edu/pub/documents/95.reports/pdf/tr0
r
01.95.pdf. (SEL96) Software Engineering Laboratory, Software
Process Improvement Guidebook, Software Engineering
(McG94) F. McGarry et al., ―Software Process
Laboratory, NASA/GSFC, Technical Report SEL-95-102,
Improvement in the NASA Software Engineering
do
April 1996, available at
Laboratory,‖ Software Engineering Institute CMU/SEI-94-
http://sel.gsfc.nasa.gov/website/documents/online-doc/95-
R-22, 1994, available at
102.pdf
http://www.sei.cmu.edu/pub/documents/94.reports/pdf/tr2
2.94.pdf. (SPC92) Software Productivity Consortium, Process
Definition and Modeling Guidebook, Software
(McG01) J. McGarry et al., Practical Software
Productivity Consortium, SPC-92041-CMC, 1992.
Measurement: Objective Information for Decision Makers,
ddison-Wesley, 2001. (Som97) I. Sommerville and P. Sawyer, Requirements
Engineering: A Good Practice Guide, John Wiley & Sons,
(Mcg93) C. McGowan and S. Bohner, ―Model Based
1997.
rocess Assessments,‖ presented at International
Conference on Software Engineering, 1993. (Vot93) L. Votta, ―Does Every Inspection Need a
rra
Meeting?‖ ACM Software Engineering Notes, vol. 18, iss.
(Nak91) T. Nakajo and H. Kume, ―A Case History
5, 1993, pp. 107-114.
Analysis of Software Error Cause-Effect Relationship,‖
IEEE Transactions on Software Engineering, vol. 17, iss. (Wei93) G.M. Weinberg, ―Quality Software
8, 1991. Management,‖ First-Order Measurement (Ch. 8,
Measuring Cost and Value), vol. 2, 1993.
(Pau94) M. Paulk and M. Konrad, ―Measuring Process
Capability Versus Organizational Process Maturity,‖ (Yu94) E. Yu and J. Mylopolous, ―Understanding ‗Why‘
presented at 4th International Conference on Software in Software Process Modeling, Analysis, and Design,‖
Quality, 1994. presented at 16th International Conference on Software
Engineering, 1994
(Pfl99) S.L. Pfleeger, ―Understanding and Improving
Technology Transfer in Software Engineering,‖ Journal of (Zah98) S. Zahran, Software Process Improvement:
Systems and Software, vol. 47, 1999, pp. 111-124.
Bo
r
Engineering Process, IEEE, 1998.
ISO and IEC, 1998.
(IEEE1517-99) IEEE Std 1517-1999, IEEE Standard for
(ISO15939-02) ISO/IEC 15939:2002, Software
Information Technology-Software Life Cycle Processes-
Engineering-Software Measurement Process, ISO and
do
Reuse Processes, IEEE, 1999.
IEC, 2002.
(IEEE1540-01) IEEE Std 1540-
(ISO19761-03) ISO/IEC 19761:2003, Software
2001//ISO/IEC16085:2003,IEEE Standard for Software
Engineering-Cosmic FPP-A Functional Size Measurement
Life Cycle Processes-Risk Management, IEEE, 2001.
Method, ISO and IEC, 2003.
(IEEE12207.0-96) IEEE/EIA 12207.0-1996//ISO/
(ISO20926-03) ISO/IEC 20926:2003, Software
IEC12207:1995, Industry Implementation of Int. Std
Engineering-IFPUG 4.1 Unadjusted Functional Size
ISO/IEC 12207:95, Standard for Information Technology-
Measurement Method-Counting Practices Manual, ISO
Software Life Cycle Processes, IEEE, 1996.
and IEC, 2003.
(IEEE12207.1-96) IEEE/EIA 12207.1-1996, Industry
(ISO20968-02) ISO/IEC 20968:2002, Software
Implementation of Int. Std ISO/IEC 12207:95, Standard
rra
Engineering-MK II Function Point Analysis – Counting
forInformation Technology-Software Life Cycle Processes
Practices Manual, ISO and IEC, 2002.
-Life Cycle Data, IEEE, 1996.
(ISO90003-04) ISO/IEC 90003:2004, Software and
(IEEE12207.2-97) IEEE/EIA 12207.2-1997, Industry
Systems Engineering - Guidelines for the Application of
Implementation of Int. Std ISO/IEC 12207:95, Standard
ISO9001:2000 to Computer Software, ISO and IEC, 2004.
for Information Technology-Software Life Cycle Processes
-Implementation Considerations, IEEE, 1997. (VIM93) ISO VIM, International Vocabulary of Basic and
General Terms in Metrology, ISO, 1993.
(IEEE14143.1-00) IEEE Std 14143.1-2000//ISO/
IEC14143-1:1998, Information Technology-Software
Measurement-Functional Size Measurement-Part 1:
Definitions of Concepts, IEEE, 2000.
Bo
Bo
rra
do
r
CAPÍTULO 10
INSTRUMENTOS Y MÉTODOS DE LA INGENIERÍA DE SOFTWARE
ACRÓNIMOS
Herramientas y Métodos de Ingeniería del software
r
Herramientas de Diseño SW
Los instrumentos de desarrollo de software son los Especificación del lenguaje y
Herramientas de Construcción notaciones
instrumentos asistidos por ordenador que son requeridos SW Refinamiento
para ayudar a los procesos de ciclo de vida de software. Redactores del Programa Propiedades de Verificación/
do
Los instrumentos permiten a acciones repetidas, bien Compiladores y generadores de confirmación
código
definidas para ser automatizadas, reduciendo la carga Intérpretes Métodos de prototipado
Depuradores Estilos de prototipado
cognoscitiva sobre el ingeniero de software que es Objetivo del prototipado
entonces libre de concentrarse en los aspectos creativos Herramientas de Pruebas de Técnicas de evaluación del
SW prototipado
del proceso. Los instrumentos a menudo son diseñados Generadores de pruebas
para apoyar el software particular métodos de la Marcos de ejecución de prueba
ingeniería, reduciendo cualquier carga administrativa Evaluación de prueba
Dirección de prueba
asociada con la aplicación del método a mano. Como los Análisis de Funcionamiento
métodos de la ingeniería de software, ellos son queridos Herramientas de
para hacer el software que trama más sistemático, varían Mantenimiento de SW
en el alcance de apoyar tareas individuales que abarcan Herramientas de Comprensión
rra
el ciclo de vida completo. Las Herramientas de Dirección
de Configuración de SW
Herramientas de defecto, mejora,
Los métodos de la ingeniería de software imponen la cuestión y rastreo del problema
Herramientas de dirección de
estructura a la actividad de la ingeniería de software con Versión
el objetivo de hacer la actividad sistemática y en última Herramientas de Liberación y
instancia más probablemente de ser acertado. Los construcción
métodos por lo general proporcionan la notación y el Herramientas de Dirección en
vocabulario, procedimientos para realizar tareas la Ingeniería de Software
identificables, y directrices para comprobar tanto el Herramientas que planifican y
rastrean proyectos
proceso como el producto. Ellos varían extensamente en Herramientas de Manejo arriesgado
el alcance, de una fase única del ciclo de vida al ciclo de Herramientas de Medida
Bo
r
Proporcionan un asunto adicional, dirigiendo áreas como Depuradores. Estos instrumentos son considerados
las técnicas de integración de instrumento que son en una categoría separada ya que ellos apoyan el
potencialmente aplicables a todas las clases de proceso de construcción de software, pero son
do
instrumentos diferentes de redactores de programa y
recopiladores.
1.1 Las herramientas de Exigencias de Software
[Dor97, Dor02]
1.4. Herramientas de Pruebas de Software
Los instrumentos para tratar con exigencias de software [Dor02, Pfl01, Rei96]
han sido clasificados en dos categorías: modelado e
instrumentos de capacidad de rastreo. Generadores de pruebas. Estos instrumentos ayudan
Exigencias de los Instrumentos de modelado. Estos en el desarrollo de casos de prueba.
instrumentos son usados para la obtención, el Marcos de ejecución de prueba. Estos instrumentos
rra
análisis, la especificación, y validez de las permiten la ejecución de casos de prueba en un
exigencias de software. ambiente controlado donde el comportamiento del
Exigencias de los Instrumentos de capacidad de objeto bajo prueba es observado.
rastreo. [Dor02] Estos instrumentos se hacen cada Herramientas de evaluación de prueba. Estos
vez más importante debido a que la complejidad de instrumentos apoyan la evaluación de los resultados
software crece. Ya que ellos son también relevantes de ejecución de prueba, ayudando a determinar si
en otros procesos de ciclo de vida, son presentados realmente el comportamiento observado se
separadamente de los instrumentos de modelado. conforma al comportamiento esperado.
Herramientas de dirección de prueba. Estos
1.2. Las herramientas Diseño de Software instrumentos proporcionan el apoyo a todos los
[Dor02] aspectos del proceso de pruebas de software.
Herramientas de análisis de Funcionamiento.
Bo
Este asunto cubre instrumentos para crear y comprobar [Rei96] Estos instrumentos son usado para medir y
diseños de software. Hay una variedad de tales analizar el funcionamiento de software, que es una
instrumentos, con la mayor parte de esta variedad siendo forma especializada de pruebas donde el objetivo es
una consecuencia de la diversidad de notaciones de de evaluar el comportamiento de funcionamiento
diseño de software y métodos. A pesar de esta variedad, más bien que el comportamiento funcional (la
ninguna división convincente para este asunto ha sido corrección).
encontrada.
1.5. Herramientas de Mantenimiento de Software
1.3. Las Herramientas de Construcción de Software [Dor02, Pfl01]
[Dor02, Rei96]
Este asunto abarca los instrumentos que son en particular
Este asunto cubre instrumentos de construcción de importantes en el mantenimiento de software donde el
software. Estos instrumentos son usados para producir y software existente está siendo modificado. Dos
traducir la representación de programa (por ejemplo, el categorías son identificadas: instrumentos de
código original) que suficientemente es detallado y comprensión e instrumentos de reingeniería.
explícito para permitir la ejecución de máquina. Herramientas de Comprensión. [Re196] Estos
Redactores del Programa. Estos instrumentos son instrumentos ayudan en la comprensión humana de
usados para la creación y la modificación de programas. Los ejemplos incluyen instrumentos de
programas, y posiblemente los documentos visualización como rebanadores de programa y
asociados con ellos. Pueden ser el texto de uso animadores.
Herramientas de reingeniería. En el Mantenimiento 1.8. Las Herramientas de Proceso de Ingeniería de
de las áreas de conocimiento de Software, Software
reingeniería es definido como el examen y la [Dor02, Som05]
alteración del software sustancial para reconstituirlo
en una nueva forma, e incluye la puesta en práctica Las herramientas de proceso de ingeniería de Software
subsiguiente de la nueva forma. Los instrumentos de están divididos en instrumentos que modelan,
reingeniería apoyan aquella actividad. instrumentos de dirección, y ambientes de desarrollo de
Al revés herramientas de la ingeniería ayudan al proceso software.
trabajando hacia atrás de un producto existente a crear Herramientas de modelado del Proceso. [Pfl01]
artefactos como la especificación y descripciones de Estos instrumentos son usados para modelar e
diseño, que entonces pueden ser transformadas para investigar los procesos de la ingeniería de software.
generar un nuevo producto de uno anterior. Herramientas de dirección de Proceso. Estos
instrumentos proporcionan el apoyo a la dirección
1.6. Las herramientas de Dirección de de la ingeniería de software.
Entornos CASE Integrados. [Rei96, Som05]
r
(ECMA55-93, ECMA69-94, IEEE1209-92,
Configuración de Software
IEEE1348-95, Mul96) el software Integrado
automatiza instrumentos de la ingeniería o
do
[Dor02, Rei96, Som05] ambientes que cubren múltiples fases del software el
ciclo de vida de la ingeniería pertenece a este
Las herramientas para la dirección de configuración han subtema. Tales instrumentos realizan múltiples
sido divididos en tres categorías: rastreo, dirección de funciones y de ahí potencialmente actúan
versión, e instrumentos de liberación. recíprocamente con el proceso de ciclo de vida de
Defecto, mejora, cuestión, e instrumentos que software siendo ejecutado.
rastrean problema. Estos instrumentos son usados en Entornos de Ingeniería del SW centrada en proceso.
la conexión con las cuestiones que rastrean [Rei96] (Gar96) Estos ambientes explícitamente
problema asociadas con un producto de software incorporan la información sobre los procesos de
particular. ciclo de vida de software y dirigen y supervisan al
Herramientas de dirección de Versión. Estos
rra
usuario según el proceso definido.
instrumentos están implicados en la dirección de
múltiples versiones de un producto. 1.9. Las Herramientas de Calidad de Software
Herramientas de liberación y construcción. Estos [Dor02]
instrumentos son usados para las tareas de liberación
y construcción de software. La categoría incluye los Las herramientas de Calidad son divididas en dos
instrumentos de instalación que se han hecho categorías: inspección e instrumentos de análisis.
extensamente usados para configurar la instalación Herramientas de revisión de auditoría. Estos
de productos de software. instrumentos son usados para apoyar revisiones y
Más información adicional en Software Configuration revisiones de cuentas.
Management KA, topic 1.3 Planning for SCM. Herramientas de análisis estáticos. [Cla96, Pfl01,
Rei96] Estos instrumentos son usados para analizar
Bo
r
especificación o la lengua usada. Las lenguas de
Los Métodos de la Ingeniería de Software están dividido especificación pueden ser clasificadas como
en tres temas: métodos heurísticos que tratan con accesos orientado por modelo, orientado por característica, u
do
informales, métodos formales que tratan con accesos orientado por comportamiento.
matemáticamente basados, y métodos de prototipado que Refinamiento. [Pre04] Este tema trata como el
tratan con software que trama accesos basados en varias método refina (o transforma) la especificación en
formas de prototipado. Estos tres temas no son una forma que es más cercana a la forma deseada
inconexos; más bien representan preocupaciones final de un programa ejecutable.
distintas. Por ejemplo, un método orientado por objeto Propiedades de Verificación/confirmación. [Cla96,
puede incorporar técnicas formales y confiar en Pfl01, Som05] Este tema cubre las propiedades de
prototipado para la verificación y la validación. Como verificación que son específicas al acercamiento
los instrumentos de la Ingeniería de Software, las formal, incluyendo tanto confirmación de teorema
metodologías continuamente se desarrollan. Por como la comprobación del modelo.
consiguiente, la descripción del área de conocimiento
rra
evita en la medida de lo posible llamar metodologías 2.3. Métodos de prototipado
particulares. [Pre04, Som05, Was96]
[Dor02] [Pfl01]
[Cla96] [Pre04] [Rei96] [Som05] [Was96]
{Dor97} {PFL98}
1.Las Herramientas de Ingeniería de Software
1.1Las Herramientas de Exigencias de Software {c4s1} ,v2c8s4
r
Exigencias de los Herramientas de modelado
Exigencias de los Herramientas de capacidad de rastreo. v1c4s2
do
1.2 Los Herramientas de Diseño de Software v2c8s4
1.3. Los Herramientas de Construcción de Software v2c8s4 c112s2
Redactores del Programa
Compiladores y generadores de código
Intérpretes.
Depuradores
1.4. Herramientas de Pruebas de Software v2c8s4 C8s7,c9s7 c112s3
Generadores de pruebas
Marcos de ejecución de prueba
rra
Herramientas de evaluación de prueba
Herramientas de dirección de prueba.
Herramientas de análisis de Funcionamiento c112s5
1.5. Herramientas de Mantenimiento de Software v2c8s4 c11s5
Herramientas de Comprensión c112s5
Herramientas de reingeniería
1.6.Las Herramientas de Dirección de Configuración de Software v2c8s4 c11s5 c112s3 c29
Herramientas de defecto, mejora, cuestión y rastreo del problema
Herramientas de dirección de Versión
Bo
Herramientas de Liberación y construcción
[Cla96] [Dor02]{Dor97} [Pfl01]{PFL98} [Pre04] [Rei96] [Som05] [Was96]
1.7. Herramientas de Dirección en la Ingeniería de Software v2c8s4
Herramientas que planifican y rastrean proyectos
Herramientas de Manejo arriesgado
r
Herramientas de Medida
1.8. Las Herramientas de Proceso de Ingeniería de Software v2c8s4
do
Herramientas de modelado del Proceso c2s3, 2s4
Herramientas de dirección de Proceso
Entornos CASE Integrados c112s3, c112s4 c3
Entornos de Ingeniería del SW centrada en proceso c112s5
1.9. Las Herramientas de Calidad de Software v2c8s4
Herramientas de revisión de auditoria
Herramientas de análisis estáticos * C8s7 c112s5
1.10. Cuestiones de Herramientas Compuestas v2c8s4
Herramientas de integración de técnicas c1s8 c112s4 *
rra
Meta-herramientas
Herramientas de evaluación C9s10
2. Los Métodos de la Ingeniería de Software
2.1. Métodos heurísticos *
Métodos Estructurados v1c5s1, v1c6s3 c4s5 c7-c9 c15
Métodos Orientados a datos v1c5s1, v1c6s3 c7-c9
Métodos Orientados a objetos v1c6s2, v1c6s3 c4s4, c6, c8s5 c7-c9 c12
2.2. Métodos Formales v1c6s5 c28 c9
Especificación del lenguaje y notaciones * c4s5
Bo
Refinamiento
Propiedades de Verificación/ confirmación * c5s7, c8s3
2.3. Métodos de prototipado c8 *
Estilos de prototipado v1c4s4 c4s6, c5s6
Objetivo del prototipado v1c4s4
Técnicas de evaluación del prototipado
REFERENCIAS RECOMENDADAS PARA HERRAMIENTAS [Pfl01] S.L. Pfleeger, Software Engineering: Theory and
Y MÉTODOS DE INGENIERÍA DEL SOFTWARE Practice, second ed., Prentice Hall, 2001.
[Pre04] R.S. Pressman, Software Engineering: A
[Cla96] E.M. Clarke et al., ―Formal Methods: State of the Practitioner's Approach, sixth ed., McGraw-Hill, 2004.
Art and Future Directions,‖ ACM Computer Surveys, vol. [Rei96] S.P. Reiss, Software Tools and Environments in The
28, iss. 4, 1996, pp. 626-643. Computer Science and Engineering Handbook, CRC Press,
[Dor97] M. Christensen, M. Dorfman and R.H. Thayer, 1996.
eds., Software Engineering, IEEE Computer Society Press, [Som05] I. Sommerville, Software Engineering, seventh
1997. ed., Addison-Wesley, 2005.
[Dor02] M. Christensen, M. Dorfman and R.H. Thayer, [Was96] A.I. Wasserman, ―Toward a Discipline of
eds., Software Engineering, Vol. 1 & Vol. 2, IEEE Software Engineering,‖ IEEE Software, vol. 13, iss. 6,
Computer Society Press, 2002. November 1996, pp. 23-31.
r
do
rra
Bo
APÉNDICE A. LISTA DE LECTURAS (Moo98) J.W. Moore, Software Engineering Standards, A
COMPLEMENTARIAS User's Roadmap, IEEE Computer Society Press, 1998.
(Ber93) E.V. Berard, Essays on Object-Oriented Software (Mos92) V. Mosley, ―How to Assess Tools Efficiently and
Engineering, Prentice Hall, 1993. Quantitatively,‖ IEEE Software, vol. 9, iss. 3, May 1992,
(Bis92) W. Bischofberger and G. Pomberger, Prototyping- pp. 29-32.
Oriented Software Development: Concepts and Tools, (Mül96) H.A. Muller, R.J. Norman, and J. Slonim, eds.,
Springer-Verlag, 1992. ―Computer Aided Software Engineering,‖ special issue of
(Bro94) A.W. Brown et al., Principles of CASE Tool Automated Software Engineering, vol. 3, iss. 3/4, Kluwer,
Integration, Oxford University Press, 1994. 1996.
(Car95) D.J. Carney and A.W. Brown, ―On the Necessary (Mül00) H. Müller et al., ―Reverse Engineering: A
Conditions for the Composition of Integrated Software Roadmap,‖ The Future of Software Engineering, A.
Engineering Environments,‖ presented at Advances in Finkelstein, ed., ACM, 2000, pp. 49-60.
Computers, 1995. (Pom96) G. Pomberger and G. Blaschek, Object-
(Col94) D. Coleman et al., Object-Oriented Development: Orientation and Prototyping in Software Engineering:
The Fusion Method, Prentice Hall, 1994. Prentice Hall, 1996.
(Cra95) D. Craigen, S. Gerhart, and T. Ralston, ―Formal (Pos96) R.M. Poston, Automating Specification-based
r
Methods Reality Check: Industrial Usage,‖ IEEE Software Testing, IEEE Press, 1996.
Transactions on Software Engineering, vol. 21, iss. 2, (Ric92) C. Rich and R.C. Waters, ―Knowledge Intensive
February 1995, pp. 90-98. Software Engineering Tools,‖ IEEE Transactions on
do
(Fin00) A. Finkelstein, ed., The Future of Software Knowledge and Data Engineering, vol. 4, iss. 5, October
Engineering, ACM, 2000. 1992, pp. 424-430.
(Gar96) P.K. Garg and M. Jazayeri, Process-Centered (Son92) X. Song and L.J. Osterweil, ―Towards Objective,
Software Engineering Environments, IEEE Computer Systematic Design-Method Comparisons,‖ IEEE Software,
Society Press, 1996. vol. 9, iss. 3, May 1992, pp. 43-53.
(Har00) W. Harrison, H. Ossher, and P. Tarr, ―Software (Tuc96) A.B. Tucker, The Computer Science and
Engineering Tools and Environments: A Roadmap,‖ 2000. Engineering Handbook, CRC Press, 1996.
(Jar98) S. Jarzabek and R. Huang, ―The Case for User- (Val97) L.A. Valaer and R.C.B. II, ―Choosing a User
Centered CASE Tools,‖ Communications of the ACM, vol. Interface Development Tool,‖ IEEE Software, vol. 14, iss.
41, iss. 8, August 1998, pp. 93-99. 4, 1997, pp. 29-39.
(Kit95) B. Kitchenham, L. Pickard, and S.L. Pfleeger, (Vin90) W.G. Vincenti, What Engineers Know and How
rra
―Case Studies for Method and Tool Evaluation,‖ IEEE They Know It — Analytical Studies from Aeronautical
Software, vol. 12, iss. 4, July 1995, pp. 52-62. History, John Hopkins University Press, 1990.
(Lam00) A. v. Lamsweerde, ―Formal Specification: A (Wie98) R. Wieringa, ―A Survey of Structured and Object-
Roadmap,‖ The Future of Software Engineering, A. Oriented Software Specification Methods and Techniques,‖
Finkelstein, ed., ACM, 2000, pp. 149-159. ACM Computing Surveys, vol. 30, iss. 4, 1998, pp. 459-527.
(Mey97) B. Meyer, Object-Oriented Software Construction,
second ed., Prentice Hall, 1997.
Bo
APÉNDICE B. LISTA DE ESTÁNDARES (IEEE1209-92) IEEE Std 1209-1992,
Recommended Practice for the Evaluation and
(ECMA55-93) ECMA, TR/55 Reference Model for Selection of CASE Tools, (ISO/IEC 14102, 1995),
Frameworks of Software Engineering IEEE Press, 1992.
Environments, third ed., 1993. (IEEE1348-95) IEEE Std 1348-1995,
(ECMA69-94) ECMA, TR/69 Reference Model for Recommended Practice for the Adoption of CASE
Project Support Environments, 1994. Tools, (ISO/IEC 14471), IEEE Press, 1995.
(IEEE1175.1-02) IEEE Std 1175.1-2002, IEEE (IEEE12207.0-96) IEEE/EIA 12207.0-1996//ISO/
Guide for CASE Tool Interconnections— IEC12207:1995, Industry Implementation of Int.
Classification and Description, IEEE Press, 2002. Std. ISO/IEC 12207:95, Standard for Information
Technology— Software Life Cycle Processes,
IEEE Press, 1996.
r
do
rra
Bo
Bo
rra
do
r
CAPÍTULO 11
CALIDAD DEL SOFTWARE
Un ingeniero de software debería entender los
ACRÓNIMOS significados subyacentes en los conceptos y
características de calidad y su relevancia en el desarrollo
CMMI Capability Maturity Model Integrated
o mantenimiento de software.
COTS Commercial Off-the-Shelf Software
PDCA Plan, Do, Check, Act El concepto relevante es que los requerimientos del
SQA Software Quality Assurance software definen las características de calidad requeridas
SQM Software Quality Management de ese software e influyen en los métodos de medición y
TQM Total Quality Management criterios de aceptación para evaluar estas características.
V&V Verificación y Validación
1.1. Ingeniería del Software Cultura y Ética.
r
INTRODUCCIÓN
Los ingenieros de software esperan compartir un
¿Que es la calidad de software, y por qué es tan compromiso sobre calidad de software como una parte
de su cultura. Una cultura sana sobre ingeniería del
do
importante como para estar omnipresente en la Guía
SWEBOK? Durante años, los autores y organizaciones software se describe en [Wie96].
han definido el término "calidad" de manera diferente.
Para A Phil Crosby (Cro79), fue " la conformidad a las La ética puede jugar un papel significativo en la calidad
exigencias de usuario. " Watts Humphrey (Hum89) se de software, la cultura, y las actitudes de ingenieros de
refiere a calidad como " el alcanzar los niveles software. La IEEE Computer society y el ACM
excelentes de salud para el empleo" mientras IBM acuñó [IEEE99] han desarrollado un código de ética y práctica
la frase " la calidad conducida por el mercado, " frase profesional basada en ocho principios con el objetivo de
basada en el objetivo de alcanzar la satisfacción de ayudar a los ingenieros de software a reforzar actitudes
cliente total. relacionadas con la calidad y con la independencia de su
trabajo.
rra
Los criterios Bladridge para la calidad organizacional 1.2. Valor y coste de la calidad.
utilizan una frase similar ―calidad conducida por el El concepto de calidad no es tan simple como parece,
cliente,‖ e incluye la satisfacción del cliente como una para un ingeniero de productos hay muchas calidades
consideración mayor. Más recientemente, la calidad se deseadas relevantes para una perspectiva determinada de
ha definido en (ISO9001-00) como ―el grado en que un un producto, para que esto pueda ser tratado y
conjunto de características inherentes cumple determinado en el tiempo las exigencias de producto son
requisitos.‖ puestas por escrito. Las características de calidad pueden
requerirse o no, o se pueden requerir en un mayor o
Este capítulo estudia los aspectos relativos a la calidad menor grado, y pueden hacerse compensaciones entre
de software los cuales transcienden a los procesos del ellas. [Pfl01] El coste de calidad puede segmentarse en el
ciclo de vida. La calidad de software es un aspecto coste de prevención, el coste de apreciación, el coste de
ubicuo en la ingeniería de software, y por lo tanto
Bo
r
Calidad de Software Prácticas de Calidad del
Software
do
Ingeniería del Aseguramiento de Requerimientos de
Software Cultura y la Calidad del calidad del software
Ética. Software
Caracterización de
Valor y coste de la Verifications & defectos
calidad Validación
Técnicas de Gestión
Modelos y Revisiones y de Calidad del
Características de Auditorias Software
Calidad
rra
Técnicas Dinámicas
Mejora de Calidad.
1.3 .Modelos y Características de Calidad. Los modelos y los criterios que evalúan las capacidades
[ Dac01; Kia95; Lap91; Lew92; Mus99; NIST; organizacionales en software son esencialmente la
Pre01; Rak97; Sei02; Wal96]. organización de proyecto y consideraciones de gestión,
Bo
r
altos del CMMI. [Dac01].
(TQM) process of Plan, Do, Check, and Act (PDCA) son
1.3.2. Calidad de producto software. Instrumentos mediante los cuales conocer los objetivos
El ingeniero de software, ante todo, necesita determinar de calidad. El apoyo a la gestión sustenta el proceso y la
do
el Objetivo verdadero del software. En cuanto a esto, es evaluación del producto así como las conclusiones
de capital importancia tener presente los requerimientos resultantes. Entonces se desarrolla un programa de
del cliente y aquellos que estos incluyen como mejora identificando acciones detalladas y proyectos de
requerimientos de calidad, no únicamente los mejora para ser gestionados en un plazo de tiempo
requerimientos funcionales. Así, el ingeniero de software factible. El apoyo a la gestión implica que cada proyecto
tiene como responsabilidad obtener los requerimientos de mejora tiene suficientes recursos para alcanzar el
de calidad, que pueden no estar explícitos en un objetivo definido. El apoyo a la gestión ha ser solicitado
principio, tratar su importancia así como el nivel con frecuencia mediante la implementación proactiva de
dificultad para alcanzarlos. Todos los procesos asociados actividades de comunicación. La participación de los
a la Calidad de software (como por ejemplo, equipos de trabajo, así como el apoyo a la gerencia
rra
construcción, pruebas, mejora de la calidad) serán media y los recursos asignados en el nivel de proyecto,
diseñados con estas exigencias en mente, y ello conlleva son tratados en el KA Proceso de Ingeniería de Software.
gastos adicionales.
2. Procesos de Gestión de Calidad del Software
El estándar (ISO9126-01) define, para dos de sus tres La gestión de calidad de software (SQM) resulta de
modelos de calidad, las características de calidad aplicación a todas las perspectivas de procesos de
mencionadas, las Sub-características, y las medidas que software, productos, y recursos. Esto define procesos,
son útiles para Evaluación de calidad de producto de propietarios de proceso, y requerimientos para aquellos
software. (Sur03) procesos, medidas del Proceso y sus correspondientes
salidas, y canales de retroalimentación. (Art93) Los
El significado del término "producto" es ampliado para procesos de gestión de calidad del software consisten en
incluir cualquier artefacto que es la salida de cualquier numerosas actividades. Algunos de ellos pueden
Bo
proceso empleado para construir el producto de software encontrar defectos directamente, mientras otros indican
final. Como ejemplos de un producto cabe incluir, donde pueden resultar valiosas más revisiones. Estos
aunque no con carácter limitativo, una completa últimos también son conocidos como actividades de
especificación del sistema, una especificación de "direct-defect-finding". Muchas actividades a menudo
requerimientos de software para un componente de sirven para ambos propósitos.
software de un sistema, un módulo de diseño, código,
documentación de prueba, o los informes producidos La planificación para la calidad de software implica:
como consecuencia de tareas de análisis de calidad.
Mientras la mayor parte del tratamiento de la calidad es (1) Definición del producto requerido en términos de sus
descrito en términos del software final y funcionamiento características calidad (descrito más detalladamente en,
del sistema, una ingeniería práctica responsable requiere por ejemplo, El KA Gestión en Ingeniería del Software).
que los productos intermedios relevantes para la calidad (2) Planificación de los procesos para alcanzar el
sean evaluados a lo largo de todo el proceso de producto requerido (Descrito, por ejemplo, en los Kas,
ingeniería de software. Diseño de Software y Construcción de Software).
1.4. Mejora de Calidad. Estos aspectos difieren de, por ejemplo, los procesos
[ NIST03; Pre04; Wei96] mismos de planificación SQM, que evalúan las
características de calidad planificadas versus la
La calidad de los productos software puede ser mejorada implementación actual de esa planificación. Los
mediante un proceso iterativo de mejora continua que procesos de gestión de calidad de software deben
dirigirse a como los buenos productos software van 2.1. Aseguramiento de la Calidad del Software
a satisfacer o satisfacen al cliente y las exigencias del [Ack02; Ebe94; Fre98; Gra92; Hor03; Pfl01; Pre04;
personal implicado, a como proporcionan valor a los Rak97; Sch99; Som05; Voa99; Wal89; Wal96]
clientes y demás personal implicado, y proveen la Los procesos SQA proporcionan la garantía de que los
calidad de software precisa para conocer los productos software y los procesos en el ciclo de vida de
requerimientos del software. proyecto son conformes a los requerimientos
El SQM puede ser utilizado para evaluar productos especificados por medio de la planificación, emitiendo, y
intermedios así como el producto final. realizando un conjunto de actividades para generar la
Algunos de los procesos específicos SQM están confianza adecuada en que se está construyendo calidad
definidos en el estándar (IEEE12207.0-96): dentro del software.
Ello significa asegurar que el problema está clara y
Procesos de aseguramiento de calidad
suficientemente identificado y que los requerimientos de
Procesos de verificación
la solución están correctamente definidos y expresados.
Procesos de validación El SQA procura mantener la calidad a lo largo de todo el
Procesos de revisión
r
desarrollo y mantenimiento del producto mediante la
Procesos de auditoría ejecución de una variedad de actividades en cada etapa
Estos procesos incentivan la calidad y también permiten que pueden permitir identificación temprana de
do
encontrar posibles problemas. Sin embargo presentan problemas, un rasgo casi inevitable de cualquier
diferencias en cuanto a su énfasis. actividad compleja. El papel del SQA en lo que
concierne al proceso es asegurar que procesos
Los procesos SQM ayudan a asegurar una calidad de
planificados son apropiados y posteriormente
software óptima en un proyecto dado. Además proveen,
implementados de acuerdo con la planificación, y se
como un subproducto, información general sobre
proveen procesos de medición relevantes para una
gestión, incluyendo directrices de calidad para todo el
adecuada organización.
proceso de ingeniería del software. Las Kas Proceso de
la Ingeniería del Software y Gestión en Ingeniería del El plan SQA define el medio que será usado para
Software tratan sobre la calidad de los programas para la asegurar que el software desarrollado para un producto
organización que desarrolla el software. El SQM puede específico satisface las exigencias del usuario y es de la
máxima calidad posible dentro de las restricciones del
rra
proporcionar retroalimentación relevante para estas
áreas. proyecto. Con el objetivo de llevar esto acabo, primero
debe asegurarse que el objetivo de calidad es claramente
Los procesos SQM consisten en tareas y técnicas para
definido y entendido. En ello deben considerarse los
indicar como los proyectos de software (por ejemplo, la
planes de gestión, desarrollo, y mantenimiento para el
gestión, el desarrollo, la gestión de configuración) están
software. Ver el estándar (IEEE730-98) para detalles.
siendo puestos en práctica y la mejor manera para que
los productos intermedios y los finales encuentren sus Las actividades y tareas específicas de calidad se
requerimientos especificados. Los resultados de estas elaboran, con sus gastos y exigencias de recursos, sus
tareas son recopilados en informes para la dirección objetivos totales de gestión, y su programa en relación
antes de que sea tomada la acción correctiva. La gestión con aquellos objetivos de gestión en la ingeniería, el
de un proceso SQM se desarrolla con la certeza de que desarrollo, o planes de mantenimiento. El plan SQA
los resultados de estos informes son exactos. debería ser compatible con el plan de gestión de
Bo
r
localizar defectos de tal manera que estos puedan ser o evaluar la efectividad de los enfoques de gestión
tratados. También evalúa los productos intermedios, empleados para lograr la idoneidad del objetivo.
como, y, en esta capacidad, los pasos intermedios de los [IEEE1028-97]. Ello apoya decisiones sobre cambios y
do
procesos de ciclo de vida de software. las acciones correctivas precisas durante un proyecto de
software. Las revisiones de gestión determinan la
El proceso V&V determina si productos de una actividad
idoneidad de los proyectos, programas, y requerimientos
dada de desarrollo o mantenimiento se adecuan o no al
y supervisan su progreso o inconsistencias. Estas
correspondiente requisito de esa actividad, y si el
revisiones pueden ser realizadas sobre productos tales
producto final de software cumple o no cumple con su
como informes de auditoría, informes de progreso,
propósito fijado y converge o no con los requisitos del
informes V&V, y proyectos de muchos tipos, incluyendo
usuario. La Verificación es un intento para asegurar que
la gestión de riesgo, gestión del proyecto, gestión de
el producto se construya correctamente, en el sentido que
configuración del software, seguridad del software, y la
los productos resultantes de una actividad converjan con
evaluación de riesgo, entre otros. Refiérase para el
las especificaciones fijadas para los mismos en
material relacionado a los Kas Gestión en Ingeniería del
rra
actividades previas. La validación es un intento por
Software y Gestión de Configuración de Software.
asegurar que se construye el producto correcto, es decir,
que el producto satisface su propósito específico fijado. 2.3.2. Revisiones técnicas
Tanto el proceso de comprobación como el proceso de [Fre98; Hor03; Lew92; Pfl01; Pre04; Som05;
validación empiezan temprano en la fase de desarrollo o Voa99; Wal89; Wal96]
mantenimiento. Proporcionan un examen de ―El propósito de una revisión técnica es evaluar el
características claves del producto en relación con el producto software para determinar si es idóneo para su
producto inmediato predecesor y a las especificaciones correspondiente uso. El objetivo es identificar
con las que debe converger. discrepancias con especificaciones aprobadas y
El propósito de la planificación V&V es asegurar que estándares. El resultado debería proporcionar gestión con
cada recurso, papel y responsabilidad está claramente evidencias (o no) de que el producto converge con sus
Bo
asignada. Los documentos del proyecto V&V resultantes especificaciones y se adhiere a los estándares, y que los
describen varios recursos y sus papeles y actividades, así cambios están controlados. (IEEE1028- 97).
como técnicas y herramientas para ser usados. La En una revisión técnica deben estar establecidos los roles
comprensión de los objetivos diferentes de cada específicos: el que adopta las decisiones, un líder revisor,
actividad V&V ayudará en la planificación cuidadosa de un registrador, y un personal técnico para apoyar las
las técnicas y los recursos precisos para alcanzar sus actividades de revisión. Una revisión técnica requiere
respectivos objetivos. Estándares específicos que las entradas obligatorias estén en su lugar con el
(IEEE1012-98:s7 y IEEE1059-93: El apéndice A) que objeto de proceder a:
generalmente incluye un plan de V&V.
El plan también considera la gestión, la comunicación, la Exposición de objetivos
política, y los procedimientos de las actividades V&V y Un producto software específico
su interacción, así como el reporte de defectos y El plan específico de gestión del proyecto
exigencias de documentación. La lista de cuestiones claves asociadas al producto
El procedimiento de revisión técnica
r
con formación en inspecciones técnicas El Walk-throughs es similar a una inspección, sin
embargo, su desarrollo, por lo general, es menos formal.
Las inspecciones de software siempre implican al autor
do
El Walk-throughs es organizado fundamentalmente por
de un producto intermedio o final, mientras otras el ingeniero de software para dar a sus compañeros de
revisiones puede que no. Las inspecciones también equipo la oportunidad de repasar su trabajo, como una
incluyen a un líder de inspección, un registrador, un técnica de aseguramiento.
lector, y un grupo (2 a 5) de inspectores. Los miembros
de un equipo de inspección pueden poseer diferentes 2.3.5. Auditorias
especializaciones, como especialización en el dominio, [Fre98; Hor03; Pfl01; Pre01; Som05;Voa99;
especialización en el método de diseño, o especialización Wal89; Wal96]
en el lenguaje. Las inspecciones por lo general son ―El objetivo de una auditoría de software es proporcionar
llevadas a cabo sobre una relativamente pequeña sección una evaluación independiente de la conformidad de
del producto a la vez. Cada miembro del equipo debe productos software y procesos a regulaciones aplicables,
rra
examinar el producto software así como practicar otras estándares, directrices, planes, y procedimientos "
revisiones de imputs con anterioridad a la reunión de [IEEE1028-97]. La auditoría es una actividad
revisión, quizás aplicando una técnica analítica (referida formalmente organizada, con participantes que tienen
en la sección 3.3.3) en una pequeña porción del papeles específicos, como el auditor jefe, otro auditor, un
producto, o en todo el producto enfocando solo un registrador, o un iniciador, e incluye a un representante
aspecto, por ejemplo, interfaces. Cualquier anomalía de la organización auditada.
encontrada se documenta y se envía al responsable de la
inspección. Durante la inspección, el responsable de la La auditoría identificará los casos de no conformidad y
inspección conduce la sesión y verifica que todos están producirá un informe requiriendo al equipo que adopte la
preparados para la misma. acción correctiva correspondiente.
Un herramienta comúnmente usada en las inspecciones Mientras puede haber muchos nombres formales para
Bo
es una lista de comprobación, con anomalías y preguntas revisiones y auditorias como los identificados en el
pertinentes sobre las cuestiones de interés. La lista estándar (IEEE1028-97), La clave es qué revisiones y
resultante a menudo clasifica las anomalías (refiérase a auditorias pueden practicarse sobre casi cualquier
IEEE1044-93 para detalles) y se revisa por parte del producto en cualquier etapa del proceso de
equipo su exactitud e integridad. La decisión sobre el mantenimiento o el desarrollo.
final de la inspección se corresponde con uno de los tres
criterios siguientes: 3. Consideraciones Prácticas
3.1. Requerimientos de calidad del software
1. No aceptar re-trabajo o como mucho un re-
[Hor03; Lew92; Rak97; Sch99; Wal89; Wal96]
trabajo menor
2. Aceptar con verificación del re-trabajo 3.1.1. Factores de influencia
3. Re-inspección Varios factores influyen en la planificación, gestión, y
selección de actividades de SQM y técnicas, incluyendo:
Típicamente las reuniones de inspección duran por lo
general algunas horas mientras que las revisiones El dominio del sistema en el cual el software residirá
técnicas y auditorias son por lo general de mayor alcance (seguridad crítica, misión crítica, negocio crítico)
y requieren más tiempo. Requerimientos del Sistema y del software
Los componentes comerciales (externos) o estándar
(internos) que serán usados por el sistema
Los estándares específicos de ingeniería del hay bastantes en uso [Bei90, Chi96, Gra92], IEEE1044-
software específico aplicables 93). La caracterización del Defecto (la anomalía)
Los métodos y herramientas de software para ser también es usada en auditorias y revisiones, el
usados en el desarrollo y el mantenimiento así como responsable de revisión a menudo presenta una lista de
para la evaluación de calidad y mejora anomalías proporcionadas por miembros de equipo para
El presupuesto, el personal, planes de organización, su consideración en una reunión de revisión.
proyectos, y la planificación de todos los procesos
Los usuarios implicados y el empleo del sistema Nuevos métodos de diseño y lenguajes se desarrollan,
El nivel de integridad del sistema junto con avances en todas las tecnologías de software,
las nuevas clases de defectos aparecen, y requieren
La Información sobre estos factores de influencia como mucho esfuerzo para interpretar clases previamente
los procesos SQM son organizados y documentados, son definidas. Rastreando defectos, el ingeniero de software
seleccionadas como actividades SQM específicas, que está interesado tanto en el número como en el tipo de
recursos son necesarios, y que impondrá límites a los defectos. La Información sola, sin ninguna clasificación,
esfuerzos. no es realmente de ninguna utilidad en la identificación
r
de las causas subyacentes de los defectos, pues los tipos
3.1.2. Confiabilidad específicos de problemas tienen que ser agrupados juntos
En casos en los que el fracaso del sistema puede tener para determinar como se gestionan. El asunto es
do
consecuencias sumamente severas, la confiabilidad total establecer una taxonomía de defectos que sea
(en hardware, el software, y humanos) son la exigencia significativa para la organización y los ingenieros de
de calidad principal además de la funcionalidad básica. software.
La confiabilidad del software incluye características tales
como tolerancia al defecto, fiabilidad, seguridad, y SQM descubre la información en todas las etapas de
usabilidad. La fiabilidad es también un criterio que desarrollo de software y mantenimiento. Típicamente
puede ser definido en términos de confiabilidad donde se usa la palabra "defecto" se refiere "a un fallo"
(ISO9126). tal y como se detalla más abajo.
El cuerpo de conocimiento para sistemas debe ser Sin embargo, diferentes culturas y normas pueden usar
sumamente confiable (" alta confianza " " o alta significados algo diferentes para estos términos, lo cual
rra
integridad en sistemas"). La terminología para los ha llevado a tentativas para definirlos. Definiciones
sistemas tradicionales mecánicos y eléctricos que no parciales tomadas del estándar (IEEE610.12-90) son:
incluyen software ha sido importada para tratar
amenazas o peligros, riesgos, integridad del sistema, y Error: ―Una diferencia entre un resultado calculado
conceptos relacionados, y puede ser encontrada en las y un resultado concreto‖
referencias citadas para esta sección. Faultt: ―Un paso, proceso, o definición de datos
3.1.3. Niveles de integridad del software incorrecto en programa de computadora.‖
Failure: ―El resultado [incorrecto] de un fault‖
El nivel de integridad se determina en base a las Mistake: ―Un error humano que produce un
consecuencias posibles del fracaso del software y a la resultado incorrecto‖ fallo falla
probabilidad de fracaso. Para el software en el que la
Bo
seguridad o la fiabilidad son importantes, técnicas como Los fracasos encontrados en pruebas como consecuencia
el análisis de riesgo para la seguridad o el análisis de de fallos de software están incluidos como defectos en
amenazas para la fiabilidad pueden ser usadas para esta sección.
desarrollar una actividad de planificación que se
identificaría en donde se encuentren conflictos Los modelos de fiabilidad son construidos en base a los
potenciales. Históricos de fracaso de software similar fallos recogidos durante pruebas de software o
también puede ayudar en la identificación de qué procedentes de software en servicio, y de esta manera
técnicas serán las más útiles en el descubrimiento de pueden ser usados para predecir futuros fracasos y asistir
defectos y evaluación de calidad. Se proponen niveles de en decisiones sobre cuando detener las pruebas. [Mus89]
integridad (por ejemplo, la gradación de integridad) en
(IEEE1012-98). Una probable acción resultante de las conclusiones
3.2. Caracterización de defectos SQM es eliminar los defectos del producto durante su
[Fri95; Hor03; Lew92; Rub94; Wak99; Wal89] inspección. Otras acciones permiten alcanzar el valor
completo de las conclusiones SQM. Estas acciones
Los procesos SQM encuentran defectos. Caracterizar
incluyen el análisis y el resumen de las conclusiones, y
estos defectos conduce a un entendimiento del producto,
técnicas de medida de utilización para mejorar el
facilita correcciones al proceso o al producto, e informa
producto y el proceso así como para rastrear los defectos
al gestor del proyecto o al cliente del estado del proceso
y su eliminación. La mejora de proceso principalmente
o el producto. Existes muchas taxonomías defectuosas,
es tratada en el KA Proceso de Ingeniería de Software,
y, mientras se ha intentado obtener un consenso en una
taxonomía de defectos o fallos, la literatura indica que
junto con el proceso SQM como una fuente de tales técnicas incluyen el análisis de complejidad,
información. controlan el análisis de flujo, y el análisis algorítmico.
Los datos sobre las insuficiencias y defectos encontrados Cada tipo de análisis tiene un objetivo específico, y no se
durante la implementación de técnicas SQM pueden ser aplican todos ellos a cada proyecto. Un ejemplo de una
perdidos a no ser que sean registrados. Para algunas técnica de apoyo es el análisis de complejidad, que es
técnicas (por ejemplo, revisiones técnicas, auditorias, útil para determinar si realmente el diseño o la
inspecciones), los registradores están presentes para implementación resultan demasiado complejos para
poner por escrito tal información, incluyendo cuestiones desarrollar correctamente, realizar las pruebas, o el
y decisiones. Cuando se utilizan herramientas mantenimiento. Los resultados de un análisis de
automatizadas, las salidas de la herramienta pueden complejidad también pueden ser usados en test de
proporcionar la información sobre defectos. Los datos desarrollo. Las técnicas para encontrar defectos como el
sobre defectos pueden ser recogidos y registrados sobre análisis de flujo de control, también pueden utilizarse
un formulario SCR (software change request) y para apoyar otra actividad.
posteriormente puede ser trasladado a algún tipo de base
r
de datos, a mano o automáticamente, desde una Para software con muchos algoritmos, el análisis
herramienta de análisis. Proporcionan informes sobre algorítmico es importante, especialmente cuando un
defectos a la dirección de la organización. algoritmo incorrecto podría causar un resultado
do
3.3. Técnicas de Gestión de Calidad del Software catastrófico. Hay demasiadas técnicas analíticas para
[Bas94; Bei90; Con86; Chi96; Fen97; Fri95; listarlas todas aquí. La lista y referencias proporcionadas
Lev95; Mus89; Pen93; Sch99; Wak99; Wei93; pueden ofrecer ideas en la selección de una técnica, así
Zel98] como sugerencias para posteriores lecturas.
Las técnicas SQM pueden categorizarse de diferentes Otros tipos, más formales, de técnicas analíticas se
formas: estáticas, conocen como métodos formales. Son usados para
Personal-intensivas, analíticas, dinámicas. verificar requerimiento de software y diseños. Las
3.3.1. Técnicas Estáticas pruebas de corrección corresponden a las partes críticas
de software. Han sido usadas, sobre todo, en la
Las técnicas estáticas implican el examen de la verificación de las partes cruciales de sistemas críticos,
rra
documentación del proyecto y el software, y otra tales como la seguridad y exigencias de fiabilidad.
información sobre los productos de software, sin (Nas97)
ejecutarlos. Estas técnicas pueden incluir actividades
intensivas de personal (como se define en 3.3.2) o 3.3.4. Técnicas Dinámicas
actividades analíticas (como se define en 3.3.3) Las diferentes clases de técnicas dinámicas son
conducidas por individuos, con o sin la ayuda de ejecutadas durante todo el desarrollo y el mantenimiento
herramientas automatizadas. de software.
3.3.2. Técnicas intensivas de personal.
Generalmente, son técnicas de testeo, pero técnicas tales
La puesta en marcha de técnicas intensivas de personal, como la simulación, la comprobación de modelo, y la
incluyendo revisiones y auditorias, puede variar de una ejecución simbólica pueden ser consideradas dinámicas.
reunión formal a una reunión informal o una situación de La lectura de código es considerada una técnica estática,
Bo
comprobación de escritorio, pero (por lo general, al pero ingenieros de software experimentados puede
menos) dos o más personas están implicadas. Puede ejecutar el código tal y como lo leen. En este sentido, la
resultar necesaria una preparación anticipada. Tanto los lectura de código también puede considerarse una
recursos como los ítems bajo examen pueden incluir técnica dinámica. Esta discrepancia en la categoría indica
listas de comprobación y son resultado de técnicas que personal con papeles diferentes en la organización
analíticas y pruebas. Estas actividades son tratadas en puede considerar y aplicar estas técnicas de manera
(IEEE1028-97) sobre revisiones y auditorias. [Fre98, diferente.
Hor03] [y Jon96, Rak97]
3.3.3. Técnicas Analíticas Algunas pruebas, así mismo, pueden ejecutarse en el
Un ingeniero de software generalmente aplica técnicas proceso de desarrollo, el proceso SQA, o el proceso de
analíticas. A veces varios ingenieros de software usan la V&V, de nuevo dependen de la organización de
misma técnica, pero cada uno lo aplica a partes proyecto. Debido a que la planificación SQM incluye
diferentes del producto. Algunas técnicas son llevadas a testeo, esta sección incluye algunos comentarios sobre
cabo por herramientas; las otras son manuales. Algunas pruebas.
pueden encontrar defectos directamente, pero El KA Pruebas de Software proporciona el tratamiento y
generalmente son usadas para apoyar otras técnicas. referencias técnicas a la teoría, técnicas para pruebas, y
Algunas técnicas también incluyen varias evaluaciones automatización.
como la parte de análisis de calidad total. Ejemplos de
3.3.5. Pruebas
Los procesos de aseguramiento descritos en SQA y Con el incremento de la complejidad del software las
V&V examinan todos los output de la especificación de cuestiones sobre calidad van más allá de si el software es
requerimientos del software con el objeto de asegurar su capaz de alcanzar objetivos de calidad mensurables.
trazabilidad, consistencia, completitud, corrección y Existen algunas áreas en las que las métricas soportan
ejecución. Esta comprobación también incluye los output SQM directamente. Esto incluye asistencias en la
de los procesos de desarrollo y mantenimiento, decisión de cuando detener las pruebas. Para ello los
recopilando, analizando y midiendo los resultados. SQA modelos de fiabilidad y pruebas, resultan útiles usando
asegura la planificación, desarrollo e implementación de datos de fallos y fracasos.
determinados tipos de pruebas, y V&V desarrolla planes
de prueba, estrategias, casos y procedimientos. El coste de los procesos SQM es una cuestión que casi
siempre se suscita cuando se adopta la decisión de cómo
Las pruebas son tratadas detalladamente en el KA. testeo debería organizarse un proyecto. A menudo, los modelos
de Software. Dos tipos de pruebas pueden incluirse en el genéricos de coste usados, están basados en cuando se
ámbito de SQA y V*V, por razón de su responsabilidad encuentra y cuanto esfuerzo se precisa para fijar el
r
por la calidad de los materiales usados en el proyecto: defecto en relación con el hallazgo del defecto temprano
en el proceso de desarrollo. Los datos de proyecto
pueden ofrecer una mejor idea del coste. El tratamiento
Evaluación y prueba de herramientas que serán
do
de este tema puede ser encontrada en [Rak97: pp. 39-50].
usadas en el proyecto (IEEE1462-98).
La información relacionada puede ser encontrada en los
Prueba de Conformidad (o revisión de prueba de
KAs el Proceso de Ingeniería de Software y Gestión en
conformidad) de componentes y productos COTS
Ingeniería del Software.
que se usaran en el producto; allí ahora existe un
estándar para paquetes de software (IEEE1465-98).
Finalmente los informes SQM en sí mismos proveen
información valiosa no sólo sobre estos procesos, sino
En ocasiones una organización independiente V&V
también sobre como pueden perfeccionarse todos los
puede ser requerida para monitorear el proceso de
procesos de ciclo de vida. El tratamiento de estos asuntos
pruebas y a veces para atestiguar la ejecución actual con
puede encontrarse en [McC04] (y IEEE1012-98).
el objeto de asegurar que este es llevado a cabo conforme
rra
a los procedimientos especificados. También se puede
Mientras las métricas para características de calidad y
apelar a V&V para evaluar las pruebas en sí mismas:
rasgos de producto pueden resultar útiles en sí mismas
adecuación a los proyectos y procedimientos, y
(por ejemplo, el número de requerimientos defectuosos o
suficiencia y exactitud de resultados
la proporción de requerimientos defectuosos), pueden
aplicarse técnicas matemáticas y gráficas para ayudar en
Otro tipo de pruebas que puede incluirse en el ámbito de
la interpretación de esa métricas. Ello se encuentra en las
la organización V&V es el de pruebas de terceros.
categorías siguientes y son tratados en [Fen97, Jon96,
Kan02, Lyu96, Mus99].
Este tercero no es el desarrollador, tampoco está
relacionado en modo alguno con el desarrollo del
Basadas estadísticamente basado (por ejemplo,
producto. En cambio, el tercero es un ―Facility‖
Pareto analysis, run charts, scatter plots, normal
independiente, por lo general acreditado por alguna
Bo
distribution.
autoridad. Su objetivo es el de probar un producto
respecto de su conformidad con un conjunto específico Pruebas Estadísticas (por ejemplo, binomial test,
de exigencias. chisquared test ).
El análisis de Tendencia.
3.4. Medición de calidad del software Predicción (por ejemplo, modelos de fiabilidad).
Los modelos de calidad del software a menudo incluyen
métricas para determinar el grado de calidad de cada Las técnicas basadas en estadísticas y las pruebas a
característica alcanzada por el producto. menudo proporcionan una imagen de las áreas más
problemáticas del producto software examinado. Los
Si estos modelos se seleccionan correctamente, las cuadros y gráficos resultantes resultan ayudas de
métricas pueden apoyar la calidad del software de visualización que los gestores con poder de decisión
muchas maneras (entre otros aspectos de los procesos de pueden utilizar para concentrar recursos donde resulten
ciclo de vida de software). más necesarios. Los resultados del análisis de tendencia
pueden indicar que una programación no ha sido
Pueden ayudar en procesos de toma de decisiones de respetada, tales como las pruebas, o que ciertas clases de
gestión. Pueden encontrar áreas problemáticas y cuellos fallos se intensificarán a no ser que se adopte alguna
de botella en procesos de software y pueden ayudar a los acción correctiva en el desarrollo. Las técnicas de
ingenieros de software a evaluar la calidad de su trabajo predicción asisten en la planificación del periodo de
respecto de objetivos SQA y respecto de procesos a largo prueba y en la predicción del fracaso. Más información
plazo de mejora de calidad. sobre medición en general pude encontrarse en los Kas
Proceso de Ingeniería de Software y Gestión en Así, para el siguiente sistema de software dentro de esa
Ingeniería del Software. Información más específica organización, los perfiles podrán utilizarse para guiar los
sobre medición en pruebas se presenta en el Ka Testeo procesos SQM, es decir, para focalizar esfuerzo allí
de Software. donde sea más probable que puedan surgir problemas.
Semejantemente, los puntos de referencia, o los defectos
Las referencias [ Fen97, Jon96, Kan02, Pfl01 ] típicos de ese dominio, pueden servir como ayuda en la
proporcionan un tratamiento del análisis del defecto, determinación de cuándo estará el producto listo para su
consistente en medir la aparición del defecto y entrega.
posteriormente aplicar métodos estadísticos para
entender los tipos de defectos que aparecen más El estudio de como usar datos de SQM para mejorar
frecuentemente, es decir, determinar su densidad. procesos de desarrollo y mantenimiento puede
También ayudan a comprender las tendencias en cómo encontrarse en los Kas Gestión en Ingeniería del
están trabajando las técnicas de detección, y cómo están Software y Procesos en Ingeniería del Software.
progresando los procesos de desarrollo y mantenimiento.
La medición de la cobertura de la prueba ayuda a estimar
r
cuanto esfuerzo en términos de prueba queda por hacer,
y predecir los posibles defectos restantes. De estos
métodos de medición, pueden desarrollarse los perfiles
do
del defecto para un dominio específico de la aplicación.
rra
Bo
ISO9001-00]
[Hou99]
[Lew92]
[Jon96]
[Lap91]
[Llo03]
[Mus99]
[IEEE99]
03-04]
[NIST03]
[Pfl01]
[Rak97]
[Sei02]
[Wal96]
[Boe78]
[Dac01]
[Kia95]
[McC77]
[Wei93]
[Wei96]
[Pre04]
[ISO900
r
1. Fundamentos de Calidad de Software
1.1. Ingeniería del Software Cultura y Ética. * *
do
1.2. Valor y coste de la calidad. * * * * * * * *
1.3 .Modelos y Características de Calidad. * * * * * * * * * * * * * * *
1.4. Mejora de Calidad. * * *
MATRIZ DE TEMAS VS REFERENCIAS
[Som05]
[Lew92]
[Rad02]
[Ack02]
[Ebe94]
[Rak97]
[Sch99]
[Voa99]
[Wal89]
[Wal96]
[Gra92]
[Hor03]
[Pre04]
[Fre98]
[Gil93]
[Pfl01]
2.
*
* *
*
* *
* *
*
* *
*
*
*
*
*
* *
*
*
* *
*
*
*
*
*
*
*
*
*
*
[McC04]
[Wak99]
[Mus89]
[Mus99]
[Con86]
[Lew92]
[Rub94]
[Kan02]
[Bas84]
[Pen93]
[Rak97]
[Sch99]
[Fen97]
[Jon96]
[Lyu96]
[Wal89]
[Wal96]
[Wei93]
[Lev95]
[Gra92]
[Hor03]
[Chi96]
[Fre98]
[Bei90]
[Zel98]
[Fri95]
[Pfl01]
Bo
3. Consideraciones Prácticas
3.1. Requerimientos de calidad del
software
* * * * * *
3.2. Caracterización de defectos * * * * * * * * * *
3.3. Técnicas de Gestión de Calidad
del Software
* * * * * * * * * * * * * * * * *
3.4. Medición de calidad SW * * * * * * * * *
REFERENCIAS RECOMENDADAS PARA [Lap91] J.C. Laprie, Dependability: Basic Concepts and
Terminology in English, French, German, Italian and
CALIDAD SW
Japanese, IFIP WG 10.4, Springer-Verlag, 1991.
[Lev95] N.G. Leveson, Safeware: System Safety and
[Ack02] F.A. Ackerman, ―Software Inspections and the Computers, Addison-Wesley, 1995.
Cost Effective Production of Reliable Software,‖ Software [Lew92] R.O. Lewis, Independent Verification and
Engineering, Volume 2: The Supporting Processes, Richard Validation: A Life Cycle Engineering Process for Quality
H. Thayer and Mark Christensen, eds., Wiley-IEEE Software, John Wiley & Sons, 1992.
Computer Society Press, 2002. [Llo03] Lloyd's Register, ―TickIT Guide,‖ iss. 5, 2003,
[Bas84] V.R. Basili and D.M. Weiss, ―A Methodology for available at http://www.tickit.org.
Collecting Valid Software Engineering Data,‖ IEEE [Lyu96] M.R. Lyu, Handbook of Software Reliability
Transactions on Software Engineering, vol. SE-10, iss. 6, Engineering: McGraw-Hill/IEEE, 1996.
November 1984, pp. 728-738. [Mcc77] J.A. McCall, ―Factors in Software Quality —
[Bei90] B. Beizer, Software Testing Techniques, General Electric,‖ n77C1502, June 1977.
International Thomson Press, 1990. [Boe78] B.W. Boehm [McC04] S. McConnell, Code Complete: A Practical
et al., ―Characteristics of Software Quality,‖ TRW Series on Handbook of Software Construction, Microsoft Press,
r
Software Technologies, vol. 1, 1978. second ed., 2004.
[Chi96] R. Chillarege, ―Orthogonal Defect Classification,‖ [Mus89] J.D. Musa and A.F. Ackerman, ―Quantifying
Handbook of Software Reliability Engineering, M. Lyu, ed., Software Validation: When to Stop Testing?‖ IEEE
IEEE Computer Society Press, 1996.
do
Software, vol. 6, iss. 3, May 1989, pp. 19-27.
[Con86] S.D. Conte, H.E. Dunsmore, and V.Y. Shen, [Mus99] J. Musa, Software Reliability Engineering: More
Software Engineering Metrics and Models: The Benjamin Reliable Software, Faster Development and Testing:
Cummings Publishing Company, 1986. McGraw Hill, 1999.
[Dac01] G. Dache, ―IT Companies will gain competitive [NIST03] National Institute of Standards and Technology,
advantage by integrating CMM with ISO9001,‖ Quality ―Baldrige National Quality Program,‖ available at
System Update, vol. 11, iss. 11, November 2001. http://www.quality.nist.gov.
[Ebe94] R.G. Ebenau and S. Strauss, Software Inspection [Pen93] W.W. Peng and D.R. Wallace, ―Software Error
Process, McGraw-Hill, 1994. Analysis,‖ National Institute of Standards and Technology,
[Fen98] N.E. Fenton and S.L. Pfleeger, Software Metrics: A Gaithersburg, NIST SP 500-209, December 1993, available
Rigorous & Practical Approach, second ed., International at http://hissa.nist.gov/SWERROR/.
Thomson Computer Press, 1998.
rra
[Pfl01] S.L. Pfleeger, Software Engineering: Theory and
[Fre98] D.P. Freedman and G.M. Weinberg, Handbook of Practice, second ed., Prentice Hall, 2001.
Walkthroughs, Inspections, and Technical Reviews, Little, [Pre04] R.S. Pressman, Software Engineering: A
Brown and Company, 1998. Practitioner’s Approach, sixth ed., McGraw-Hill, 2004.
[Fri95] M.A. Friedman and J.M. Voas, Software [Rad02] R. Radice, High Quality Low Cost Software
Assessment: Reliability, Safety Testability, John Wiley & Inspections, Paradoxicon, 2002, p. 479.
Sons, 1995. [Rak97] S.R. Rakitin, Software Verification and Validation:
[Gil93] T. Gilb and D. Graham, Software Inspections, A Practitioner’s Guide, Artech House, 1997.
Addison-Wesley, 1993. [Rub94] J. Rubin, Handbook of Usability Testing: How to
[Gra92] R.B. Grady, Practical Software Metrics for Project Plan, Design, and Conduct Effective Tests, John Wiley &
Management and Process Management, Prentice Hall, Sons, 1994.
1992. [Sch99] G.C. Schulmeyer and J.I. McManus, Handbook of
[Hor03] J. W. Horch, Practical Guide to Software Quality
Bo
r
do
rra
Bo
APÉNDICE A. LISTA DE LECTURAS (Inc94) D. Ince, ISO 9001 and Software Quality Assurance,
McGraw-Hill, 1994.
COMPLEMENTARIAS
(Jur89) J.M. Juran, Juran on Leadership for Quality, The
(Abr96) A. Abran and P.N. Robillard, ―Function Points
Free Press, 1989.
Analysis: An Empirical Study of Its Measurement
(Kin92) M.R. Kindl, ―Software Quality and Testing: What
Processes,‖ presented at IEEE Transactions on Software
DoD Can Learn from Commercial Practices,‖ U.S. Army
Engineering, 1996. //journal or conference?//
Institute for Research in Management Information,
(Art93) L.J. Arthur, Improving Software Quality: An
Communications and Computer Sciences, Georgia Institute
Insider’s Guide to TQM, John Wiley & Sons, 1993.
of Technology, August 1992.
(Bev97) N. Bevan, ―Quality and Usability: A New
(NAS97) NASA, ―Formal Methods Specification and
Framework,‖ Achieving Software Product Quality, E. v.
Analysis Guidebook for the Verification of Software and
Veenendaal and J. McMullan, eds., Uitgeverij Tutein
Computer Systems, Volume II: A Practitioner‘s
Nolthenius, 1997.
Companion,‖ 1997, available at http://eis.jpl.nasa.gov/
(Cha89) R.N. Charette, Software Engineering Risk Analysis
quality/Formal_Methods/.
and Management, McGraw-Hill, 1989.
(Pal97) J.D. Palmer, ―Traceability,‖ Software Engineering,
(Cro79) P.B. Crosby, Quality Is Free, McGraw-Hill, 1979.
M. Dorfman and R. Thayer, eds., 1997, pp. 266-276.
r
(Dem86) W.E. Deming, Out of the Crisis: MIT Press, 1986.
(Ros98) L. Rosenberg, ―Applying and Interpreting Object-
(Dod00) Department of Defense and US Army, ―Practical
Oriented Metrics,‖ presented at Software Technology
Software and Systems Measurement: A Foundation for
Conference, 1998, available at http://satc.gsfc.nasa.gov/
Objective Project Management, Version 4.0b,‖ October
do
support/index. html.
2000, available at http://www.psmsc.com.
(Sur03) W. Suryn, A. Abran, and A. April, ―ISO/IEC
(Hum89) W. Humphrey, ―Managing the Software Process,‖
SQuaRE. The Second Generation of Standards for Software
Chap. 8, 10, 16, Addison-Wesley, 1989.
Product Quality,‖ presented at IASTED 2003, 2003.
(Hya96) L.E. Hyatt and L. Rosenberg, ―A Software Quality
(Vin90) W.G. Vincenti, What Engineers Know and How
Model and Metrics for Identifying Project Risks and
They Know It — Analytical Studies from Aeronautical
Assessing Software Quality,‖ presented at 8th Annual
History, John Hopkins University Press, 1990.
Software Technology Conference, 1996.
rra
Bo
APÉNDICE B. LISTA DE ESTÁNDARES
(FIPS140.1-94) FIPS 140-1, Security Requirements for
Cryptographic Modules, 1994.
(IEC61508-98) IEC 61508, Functional Safety — Safety-
Related Systems Parts 1, 2, 3, IEEE, 1998.
(IEEE610.12-90) IEEE Std 610.12-1990 (R2002), IEEE
Standard Glossary of Software Engineering Terminology,
IEEE, 1990.
(IEEE730-02) IEEE Std 730-2002, IEEE Standard for
Software Quality Assurance Plans, IEEE, 2002.
(IEEE982.1-88) IEEE Std 982.1-1988, IEEE Standard
Dictionary of Measures to Produce Reliable Software,
1988.
(IEEE1008-87) IEEE Std 1008-1987 (R2003), IEEE
Standard for Software Unit Testing, IEEE, 1987.
r
(IEEE1012-98) IEEE Std 1012-1998, Software Verification
and Validation, IEEE, 1998.
(IEEE1028-97) IEEE Std 1028-1997 (R2002), IEEE
Standard for Software Reviews, IEEE, 1997.
do
(IEEE1044-93) IEEE Std 1044-1993 (R2002), IEEE
Standard for the Classification of Software Anomalies,
IEEE, 1993.
(IEEE1059-93) IEEE Std 1059-1993, IEEE Guide for
Software Verification and Validation Plans, IEEE, 1993.
(IEEE1061-98) IEEE Std 1061-1998, IEEE Standard for a
Software Quality Metrics Methodology, IEEE, 1998.
(IEEE1228-94) IEEE Std 1228-1994, Software Safety
Plans, IEEE, 1994.
(IEEE1462-98) IEEE Std 1462-1998//ISO/IEC14102,
Information Technology — Guideline for the Evaluation
rra
and Selection of CASE Tools.
Usado como fuente reconocida y consensuada, este capítulo identifica para cada Disciplina Relacionada:
r
Una definición informativa (cuando sea factible).
Un listado de áreas de conocimiento.
do
La figura 1 da una representación gráfica de estas disciplinas relacionadas.
Redes
diseño, construcción, implementación y mantenimiento de
los componentes software y hardware de los sistemas de Sistemas operativos
cálculo moderno y del equipo controlado por ordenador.‖ Fundamentos de la programación
Probabilidad y Estadística
Este informe identifica las siguientes Áreas de
Conocimiento (conocidas como áreas en el informe) para Problemas sociales y profesionales
la ingeniería de la computación: Ingeniería del Software
Algoritmos y Complejidad Verificación y Prueba
Arquitectura de ordenadores y Organización Diseño VLSI/ASIC
Ingeniería de Sistemas Informáticos
Circuitos y Sistemas
Lógica Digital Ciencia de la computación
Estructuras discretas
El informe final del volumen en Ciencia de la
Procesamiento de señales digitales computación de Computing Curricula 2001 project
(CC2001)2 identifica la siguiente lista de áreas de
1
hhtp://www.eng.auburn.edu/ece/CCCE/Iron_Man_Draft_October_ conocimiento (identificadas como áreas en el informe)
2003.pdf para la Ciencia de la computación:
Estadística
Estructuras discretas Análisis numérico
Fundamentos de la programación Matemática discreta
Algoritmos y Complejidad
Arquitectura y Organización Un listado más enfocado en asuntos matemáticos
Sistemas operativos (llamados unidades y asuntos en el informe) que sostiene
la ingeniería del software puede ser encontrado en el
Sistemas centralizados
informe borrador del volumen en Ingeniería del Software
Lenguajes de programación en el Computing Curricula 2001 project (CC2001)5.
Interacción Hombre-Máquina
Gráficos y computación visual Gestión de Proyectos
Sistemas inteligentes
La gestión de proyectos es definida en la edición del 2000
Gestión de la información
de A Guide to the Project Management Body of
r
Problemas sociales y profesionales Knowledge (PMBOK® Guide 6) publicado por el Project
Ingeniería del Software Management Institute y adoptado como IEEE Std 1490-
Ciencia computacional y Cálculo numérico 2003, como ―el uso del conocimiento, de las habilidades,
do
de las herramientas, y de las técnicas para planificar
Gestión actividades para satisfacer los requisitos del proyecto.‖
Las áreas de conocimiento identificadas en la guía de
La European MBA Guidelines definida por la asociación PMBOK para la Gestión de Proyectos son
europea de cuerpos de acreditación nacional (EQUAL)3 Gestión de Integración del proyecto
establece que el título Master en Administración de Gestión de Alcance del proyecto
negocios debe incluir cobertura e instrucción en
Gestión del tiempo del proyecto
1) Contabilidad Gestión del coste del proyecto
Finanzas Gestión de la calidad del proyecto
Gestión de los recursos humanos del proyecto
rra
Marketing y ventas
Gestión de operaciones Gestión de comunicaciones del proyecto
Gestión de Sistemas de Información Gestión de riesgos del proyecto
Derecho Gestión de consecución del proyecto
Gestión de Recursos Humanos
Gestión de calidad
Economía
Analisis cuantitativo La gestión de la calidad es definida en el ISO 9000-2000
Política y estrategia de negocio como ―actividades coordinadas para dirigir y controlar una
organización con respecto a la calidad.‖ Las tres
referencias seleccionadas en gestión de calidad son
Matemáticas
Bo
Dos fuentes son seleccionadas para identificar la lista de ISO 9000:2000 Sistemas de gestión de calidad –
áreas de conocimiento para matemáticas. El informe Fundamentos y vocabulario
titulado "Criterios de acreditación y procedimientos"4 de la ISO 9001:2000 Sistemas de gestión de calidad –
Canadian Engineering Accreditation Board identifica que Requerimientos
los elementos apropiados de las áreas siguientes deben ISO 9004:2000 Sistemas de gestión de calidad -
estar presentes en un plan de estudios de la ingeniería del Pautas para la mejora del funcionamiento
estudiante:
Algebra lineal
Cálculo Integral y Diferencial
Ecuaciones diferenciales
Probabilidad 5 http://sites.computer.org/ccse/volume/FirstDraft.pdf
6 PMBOK es una marca registrada de los Estados Unidos y otras
naciones.
La Sociedad Americana para la Calidad identifica las
2 siguientes áreas de conocimiento en su Cuerpo de
ttp://www.computer.org/education/cc2001/final/cc2001.pdf
3
http://www.efmd.be/
Conocimiento para la certificación como Ingeniero de
4
Calidad7:
http://www.ccpe.ca/e/files/report_ceab.pdf
2) Gestión y liderazgo en ingeniería de calidad Universidad de Québec en Montréal y por W. W. McMillan, de
la Eastern Michigan University.
Sistemas de calidad de desarrollo,
Fundaciones de la ciencia cognoscitiva
implementación y verificación
Extracción de la información del habla y del
Planificación, control y fiabilidad en la calidad
texto
del producto y del proceso
Procesado léxico
Gestión de la fiabilidad y el riesgo
Adquisición de cómputo de la lengua
Solución de problemas y mejora de la calidad
Naturaleza del HCI
Métodos cuantitativos
- (Meta-) Modelos de HCI
Uso y contexto de computadoras
Ergonomía del software
- Organización y trabajo sociales humanos
El campo de la ergonomía está definido por la ISO
- Áreas de aplicación
r
Technical Committee 159 sobre la ergonomía y dice:
Ergonomía o (factores humanos) es la disciplina científica Ajuste y adaptación Hombre-Máquina
referida a comprensión de las interacciones entre un ser
Características humanas
do
humano y otros elementos de un sistema, y la profesión
- Tratamiento de la información humana
que conlleva teoría, principios, datos y métodos para
diseñar con objeto de optimizar el bienestar humano y el - Lengua, comunicación, interacción
funcionamiento del sistema global.8‖ - Ergonómica
Sistema informático y arquitectura del interfaz
Una lista de las áreas del conocimiento para la ergonomía - Dispositivos de la entrada y de salida
n relación con el software se detalla a continuación9: - Técnicas del diálogo
Cognición - Género del diálogo
- Gráficos de computadora
I.A. cognoscitiva I: Razonamiento
Arquitectura del diálogo
Aprendizaje de las máquinas e inducción de la
rra
Proceso del desarrollo
gramática
- Borradores del diseño
Métodos formales en ciencia cognoscitiva: - Técnicas de implementación
Lenguaje - Técnicas de la evaluación
- Sistemas de ejemplo y casos de estudio
Ellos debían indicar cuáles de estos tópicos
debían ser conocidos como Ingeniería del Se puede encontrar una lista más detallada de asuntos de
Software. Los que fueron rechazados por dos de interfaz hombre-computadora diseñada (llamado unidades
y asuntos en el informe) para la ingeniería del software, en
los tres integrantes fue eliminados de la lista el borrador del informe del volumen en la ingeniería del
original. software Computing Curricula 2001 project (CC2001)10.
Bo
r
do
rra
Bo
APÉNDICE A
ESPECIFICACIONES DE LA DESCRIPCIÓN DE ÁREAS DE
CONOCIMIENTO PARA LA GUÍA HOMBRE DE HIERRO DE LA GUÍA
DEL CUERPO DE CONOCIMIENTO DE LA INGENIERÍA DEL
SOFTWARE
r
especificaciones proporcionadas al equipo editorial a los d) La descomposición de temas propuesta dentro de
expertos de las AC en relación a las Descripciones de las un Área de Conocimiento no debe asumir
Áreas de Conocimiento de la Guía del Cuerpo de dominios de aplicaciones específicos,
do
Conocimiento de la Ingeniería del software (Versión necesidades de negocio, tamaños de
Hombre de Hierro). organizaciones, filosofías de gestión, ciclos de
vida del software, tecnologías software o métodos
Este documento comienza presentando especificaciones de desarrollo del software.
sobre los contenidos de las áreas de las Descripciones de
las Áreas de Conocimiento. Los criterios y requerimientos e) La descomposición de temas propuesta debe, en
son definidos: para las descripciones de los temas todo lo posible, ser compatible con las varias
propuestos, las bases para dichas descomposiciones y una escuelas de pensamiento dentro de la ingeniería
breve descripción de los temas, para la selección de las del software.
referencias, y para la identificación de las Áreas de
Conocimiento de las Disciplinas Relacionadas. Se f) La descomposición de temas propuesta dentro de
rra
explican documentos y sus roles de dentro de los las Áreas de Conocimiento, debe ser compatible
proyectos software. Además se tratan asuntos no con la descomposición de la ingeniería del
relacionados con el contenido como formatos de entrega y software encontrada en la industria y en los
guías de estilo. estándares y literatura de la ingeniería del
software.
CRITERIOS Y REQUERIMIENTOS PARA LA
DESCOMPOSICIÓN DE TÓPICOS INTERRUPCIÓN DE LOS g) La descomposición de temas propuesta debe ser
ASUNTOS PARA LOS REQUISITOS DEL SOFTWARE tan extensa como sea posible. Es mejor sugerir
muchos temas y que luego algunos sean
Los siguientes requerimientos y criterios que deberían abandonados que lo contrario.
utilizarse para proponer una descomposición de temas en
un Área de Conocimiento: h) Se espera de los editores asociados del Área de
Bo
r
nivel apropiado para que el lector pueda Complementarias‖. Estas lecturas
seleccionar el material referenciado acorde a sus complementarias deben relacionarse con
necesidades. los temas en la descomposición. Además
do
deben comentarse en el conocimiento
CRITERIOS Y REQUERIMIENTOS PARA LA SELECCIÓN DE globalmente aceptado. No debería de
MATERIAL DE REFERENCIA haber una matriz entre el material de
referencia contenido en las Lecturas
a) Debe identificarse material de referencia Complementarias y los temas
específico a cada tema. Los materiales de individuales.
referencia pueden cubrir múltiples temas.
e) Si se considera posible y rentable por el IEEE
b) El material de referencia propuesto pueden ser Computer Society, el material de referencia
capítulos de libro, artículos de revista revisados, seleccionado será publicado en la Web de la Guía
artículos de referencia revisados, reportes al Cuerpo de Conocimiento de la Ingeniería del
rra
técnicos o de empresa revisados, o cualquier otro Software. Para facilitar esta tarea, se debería
tipo de artefactos como documentos Web. Deben referenciar materiales cuyo copyright ya
de estar disponibles y no ser confidenciales por pertenecen al IEEE Computer Society. Sin
naturaleza. Las referencias deberían de ser lo más embargo, esto no debería considerarse como una
precisas posibles especificando los capítulos o restricción o una obligación.
secciones relevantes.
f) Debe proporcionarse una matriz con los
c) El material de referencia propuesto debe de estar materiales de referencia versus temas
en Ingles.
r
Introducción de Conocimiento miren al futuro en su interpretación de lo
Descomposición de temas del Área de Conocimiento que es ―generalmente aceptado‖ a día de hoy, pero lo que
(por claridad, creemos que esta sección debería de se espera que sea ―generalmente aceptado‖ en 5 años.
do
estar situarse al principio y no en un apéndice al final
del documento. Además, debería de una figura
describiendo la descomposición). Generalmente aceptado
r
and D. Frailey, ―A Baseline List of Knowledge Areas for del software – calidad y gestión de proyectos, ingeniería
the Stone Man Version of the Guide to the Software de sistemas, fiabilidad y seguridad (prevención de
Engineering Body of Knowledge,‖ Université du Québec à riesgos). El análisis y reagrupamiento de colecciones de
do
Montréal, Montréal, February 1999. estándares le muestran al lector relaciones clave entre
estándares.
Basado en la versión ―Hombre de Paja‖, en las discusiones
y en las expectativas marcadas en la reunión inicial del Aunque la Guía al Cuerpo de Conocimiento de la
Comité Ejecutivo Profesional, en otros cuerpos del Ingeniería del Software no se trata del desarrollo de
conocimiento, y en los criterios definidos en este estándares en sí mismo, debe considerarse muy
documento, propone una línea base de 10 Áreas de especialmente en todo el proyecto la compatibilidad de
Conocimiento para la versión de prueba de la Guía al Guía con el conjunto de estándares de IEEE e ISO.
Cuerpo de Conocimiento de la Ingeniería del Software.
Por supuesto, esta línea base puede evolucionar al tratarse IEEE Standard Glossary of Software Engineering
de un trabajo en progreso y según se van identificando Terminology, Std 610.12-1990, IEEE, 1990.
rra
temas durante el transcurso del proyecto.
La lista de referencias para la terminología es Merriam
Este documento está disponible en Webster‘s Collegiate Dictionary (10th ed.), IEEE Std
http://www.swebok.org/ 610.12, y nuevas propuestas de definiciones si son
necesarias.
P. Bourque, R. Dupuis, A. Abran, J. W. Moore, y L. Tripp,
―A Proposed Baseline List of Related Disciplines for the Information Technology – Software Life Cycle Processes,
Stone Man Version of the Guide to the Software International std ISO/IEC 12207:1995(E), 1995.
Engineering Body of Knowledge,‖ Université du Québec à
Montréal, Montréal, February 1999 Este estándar es considerado clave en relación a la
definición de los procesos del ciclo de vida y ha sido
Basado en la versión ―Hombre de Paja‖, en las discusiones
Bo
r
El Equipo Editorial y ESTILO Y GUÍAS TÉCNICAS
El formato preferido para la presentación del trabajo es
Microsoft Word. Por favor, contáctese al equipo editorial editores profesionales editaran las Descripciones de las
do
si esto no es posible. Áreas de Conocimiento. La edición incluye corrección
(gramática, puntuación y capitalización), estilo
OTRAS GUÍAS DETALLADAS (adaptación al estilo de las revistas de la Computer
Society), y edición de contenido (flujo, significado,
Cuando se referencie la guía, recomendamos que se use el claridad, lenguaje directo y organización). La edición final
título completo ―Guía al SWEBOK‖ en lugar de será un proceso colaborativo entre el Equipo Editorial y
―SWEBOK‖. los autores de los trabajos para alcanzar unas
Descripciones de las Áreas de Conocimientos concisas,
Por simplicidad, recomendamos a los editores asociados bien escritas y útiles.
de las Áreas de Conocimiento que no se usen pies de
página. Deberían de intentar incluir su contenido en el PUBLICACIÓN DEL COPYRIGHT
rra
cuerpo principal del documento.
Toda propiedad intelectual asociada a la Guía al Cuerpo de
Recomendamos usar en el texto referencias explicitas a Conocimiento de la Ingeniería del Software pertenecerá al
estándares en lugar de insertar los números que IEEE Computer Society. Los Editores Asociados a las
referencian a la bibliografía. Creemos que permiten al Áreas de Conocimiento firmaran un formulario sobre la
lector una mejor exposición a la fuente y ámbito del publicación del copyright.
estándar.
Además, la Guía al Cuerpo de Conocimiento de la
El texto acompañando las figuras y tablas debería de ser Ingeniería del Software estará gratuitamente a disposición
autocontenido o tener suficiente texto. Esto permite al del público por parte del IEEE Computer Society en un
lector saber lo que significan las lecturas y tablas. sitio Web u otros medios.
Bo
Asegúrese de usar información correcta (actual) en las Para más información, consúltese:
referencias (versiones, títulos, etc.) http://www.computer.org/copyright.htm
Bo
rra
do
r
APÉNDICE B
EVOLUCIÓN DE LA GUÍA DEL CUERPO DE CONOCIMIENTO DE LA
INGENIERÍA DEL SOFTWARE
r
del 2004, es simplemente la presente edición de la Guía estudio de grado son bastante consistes con el alcance
que continuara evolucionando para alcanzar las de la Guía del SWEBOK.
necesidades de la comunidad de la ingeniería del software.
do
La planificación de su evolución no se ha completado El IEEE-CS Software Engineering Standards
todavía, pero en esta sección se proporciona un borrador. Committee (SESC) ha organizado su colección de
A la hora de escribir esto, el proceso ha sido endorsado estándares siguiendo las Áreas de Conocimiento del
por el Comité Ejecutivo Profesional y comunicado a la SWEBOK, y el IEEE Standards Association ha
Junta de Gobierno del IEEE Computer Society, pero ha publicado un CD-ROM que ya refleja esta
sido ni financiado ni implementado. organización.
r
que han adoptado la Guía del SWEBOK. En el pasado, la conservador por varias razones. Primero, se limita a
financiación por parte de la empresa nos ha permitido que conocimiento característico de la ingeniería del software;
el Guía del SWEBOK esté disponible gratuitamente en la por lo tanto, la información de las disciplinas relacionadas
do
Web. Futura financiación nos permitirá continuar esta (incluso aquellas que aquellas que se les aplica la
práctica. ingeniería del software) son descartadas. Segundo, está
desarrollada y aprobada por un proceso consensuado, por
Cada uno de los cuatro años incluirá un ciclo de lo que no se almacena la información que no haya recibido
workshops, borrador, votación y resolución de la votación. una aceptación general. Tercero, el conocimiento
Un ciclo anual puede contener las siguientes actividades: contemplado como especializado en dominios específicos
es excluido. Finalmente y muy importante, la Guía
Un workshop, que organizado asociado a un congreso, contiene sólo el conocimiento que es ―generalmente
especificara temas a tratar para el siguiente año, aceptado‖. A veces es necesario en la actualidad el uso de
priorizar asuntos a tratar, recomendar como abordar técnicas de validación para obtener una aceptación general
los asuntos a tratar y nominar a quienes llevarán a dentro de la comunidad.
rra
cabo dicha tarea. Este enfoque conservador es evidente en la actual Guía
Cada grupo haciendo borradores escribirá y SWEBOK. Después de 6 años de trabajo, aún contiene las
modificará la descripción de un Área de 10 Áreas de Conocimiento. Una posible pregunta es si la
Conocimiento utilizando las recomendaciones de los selección de las Áreas de Conocimiento será algún día
workshops y referencias disponibles. En el último año alterada. El plan de evolución contempla algunos criterios
disponible las personas encargadas de los borradores para añadir un Área de Conocimiento nuevo o para
recomendarán referencias actualizadas para su cita en modificar el alcance de éstas. En principio, el candidato
la guía del SWEBOK. También se encargarán de debe ser ampliamente reconocido dentro y fuera de la
modificar los borradores de acuerdo a las comunidad de ingeniería del software como representación
recomendaciones recibidas. de un área distintiva de conocimiento y el conocimiento
Cada ciclo anual incluirá votaciones en las revisiones. generalmente aceptado dentro del área propuesta debe de
Bo
Los votantes revisarán los borradores de las estar suficientemente detallada y completa para ser tratada
descripciones de las áreas de conocimiento y con el mismo mérito que aquellas que están ya presentes
referencias recomendadas. La votación será abierta a en la Guía SWEBOK. En término operacionales, debe de
los miembros de la Computer Society y otros estar lo menos posible acoplado el Área de Conocimiento
participantes cualificados (los que no sean miembros propuesto de las áreas ya existentes, y ese
tendrán que pagar para sufragar los gastos de la desacoplamiento debe de añadir un valor significante
votación). Los que tengan el certificado CSDP serán sobre la taxonomía del conocimiento provisto por la Guía.
particularmente bienvenidos como miembros de las No obstante, simplemente por ser un área transversal no
votaciones o como voluntarios en otros roles. tiene justificación de ser tratada separadamente por
Un Comité de Resolución de las Votaciones será separar, en muchos casos, simplemente genera un
seleccionado por el comité de gestión para servir problema de solapamiento. En general, el crecimiento del
como intermediarios entre los encargados de los número total de Áreas de Conocimiento tiende a ser
borradores y los votantes. Su trabajo es determinar el evitado cuando hace que aumenten los esfuerzos de los
consenso para los cambios pedidos por el grupo de lectores por encontrar la información deseada.
votantes y asegurar que se implementan los cambios Añadiendo un tópico a Área de Conocimiento es más fácil.
necesarios. En algunos casos, Comité de Resolución En principio, debe de estar madura (o, por lo menos,
de las Votaciones puede proponer preguntas a los alcanzando la madurez rápidamente) y generalmente
votantes y usar sus respuestas para guiar las revisiones aceptada2. Los indicios para una aceptación general
de los borradores. El objetivo de cada año es alcanzar pueden ser encontrados en muchos sitios, incluyendo
consenso entre el grupo de votantes en las Áreas de currículos y estándares de ingeniería del software, y
ampliamente usado en libros de texto. Por supuesto, los incrementarán los temas a ser tratados por el taller anual,
temas se deben de ajustar a un nivel de licenciado con estableciendo el escenario para la revisión de la Guía
cuatro años de experiencia3. SWEBOK. Nosotros esperamos proveer un foro público
Ese diseño incrementa el volumen de material en línea para comentar por cualquier miembro de la
referenciado en la Guía SWEBOK. La cantidad total de comunidad de ingeniería del software y que sirva como un
material debería estar diseñado para un nivel de licenciado punto para realizar actividades.
con cuatro años de experiencia. Actualmente, el equipo
editorial considera apropiado la cantidad de 5000 páginas
como material de texto. Durante la evolución de la Guía,
deberá ser necesario el administrar las listas de del 2. Para la definición de ―generalmente aceptado‖, usamos el que
material citado, por lo que las referencias son actualmente utiliza IEEE, en la Adopción de un Estándar PMI (Una Guía del
accesibles, abasteciendo una cobertura apropiada de las Proyecto de la Administración del Cuerpo del Conocimiento):
Áreas de Conocimiento, por medio de una considerada ―Generalmente aceptado significa que el conocimiento y las
prácticas descritas son aplicables a la mayoría de los proyectos la
cantidad grande de material. mayor parte del tiempo, y hay un extendido consenso sobre su
valor y utilidad. Esto no significa que el conocimiento y las
r
Un último tema es el rol que debe ser tomado por los prácticas deban de ser aplicadas de forma uniforme en todos los
usuarios de la Guía SWEBOK en su evolución. El equipo proyectos sin considerar si son apropiados.‖
editorial cree que la continuada publicación de 3. Por supuesto, esta especificación particular está indicada en
do
comentarios es el ―combustible‖ para dirigir la evolución términos relevantes en US. En otros países, puede ser indicada de
de la Guía SWEBOK. Los comentarios publicados forma diferente.
rra
Bo
Bo
rra
do
r
APÉNDICE C
ASIGNACIÓN DE IEEE E ISO ESTÁNDARES A LAS ÁREAS DE CONOCIMIENTO DEL SWEBOK
r
La siguiente tabla lista los estándares producidos por IEEE e ISO/IEC JTC1/SC7, al igual que otros estándares seleccionados de otras fuentes. Para cada estándar, se muestra
su número y título. Además, la columna de descripción se proporciona un resumen sacado del propio estándar o de otros materiales introductorios. Cada uno de los estándares
se mapea a las áreas de conocimiento del SWEBOK. En unos pocos casos – como estándares de terminología – el estándar es aplicable a todas las áreas de conocimiento; en
estos casos aparece una ―X‖ en cada columna. En la mayoría de los casos, cada estándar se fuerza un área primaria de conocimiento marcada con una ―P‖ y otras secundarias
do
marcadas con ―S‖. La lista está ordenada por el número de estándar sin tener en cuenta su categoría (IEEE, ISO, etc.)
rra
Software
IEEE Std Estándar IEEE Este estándar especifica el
730-2002 para los Planes formato y el contenido de
de los planes de
S S P
Aseguramiento aseguramiento de la
de la Calidad del calidad del software.
Software
IEEE Std Estándar IEEE Este estándar especifica el
828-1998 para los Planes contenido de un plan de
de Gestión de la gestión de la
Configuración configuración de un P S
del Software software junto con los
requisitos que especifican
las actividades.
IEEE Std Estándar IEEE Este estándar describe la
829-1998 de la forma y el contenido de un
Bo
Documentación conjunto básico de
de Prueba del documentación para la S P S
Software. planificación, ejecución, y
la presentación de las
pruebas del software.
IEEE Std Recomendación Este documento
830-1998 IEEE para la recomienda el contenido y
Práctica de la características de una
Especificación especificación de P
de Requisitos del requisitos del software.
Software. Esquemas de ejemplo son
provistos.
Gestión en Procesos de Herramientas
Número Requisitos Diseño Gestión de la la la y Métodos en
Nombre del Construcción Pruebas del Mantenimiento
de Descripción del del configuración Ingeniería Ingeniería la Ingeniería Calidad
estándar del Software Software del Software
estándar Software Software del Software del del del Software
Software Software
IEEE Std Estándar IEEE Este estándar provee un
r
982.1- de Diccionario conjunto de medidas para
1988 de Medidas para evaluar la fiabilidad de un
S S S S P
Producir producto software y para
Software Fiable. obtener fiabilidad de un
producto en desarrollo.
do
Este estándar describe con
cierta aproximación las
IEEE Std Estándar IEEE pruebas unitarias del
1008- para las Pruebas software, así como los
S P S S
1987 Unitarias del conceptos y supuestos en
(R2003) Software los cuales están basadas.
También provee Fuentes
de información y una guía.
Este estándar describe los
procesos de verificación y
validación que son
utilizados para determinar
si un producto software de
rra
IEEE Std una actividad tiene en P
Estándar IEEE
1012- cuenta todos los requisitos
para la
1998 deseados y para
Validación y
and determinar si el software
Verificación del
1012a- satisface las necesidades
Software
1998 del cliente. El ámbito
incluye análisis,
evaluación, revisión,
inspección, evaluación de
los resultados y prueba de
los productos y procesos.
Práctica IEEE
Este documento
Recomendada
IEEE Std recomienda el contenido y
para las
1016- la organización de una P
Descripciones
1998 descripción del diseño de
Bo
del Diseño del
un software.
Software
r
aproximación uniforme de
Estándar IEEE la clasificación de las
IEEE Std para la anomalías encontradas en
1044- Clasificación de el software y su
S S S P
1993 Anomalías del documentación. Incluye
do
(R2002) Software. listas de ayuda para la
clasificación de las
anomalías de de la
información relacionada.
Este estándar provee una
terminología consistente
Estándar IEEE para medir la
IEEE Std
para las Métricas productividad del software
1045-
de Productividad y define la forma correcta P S
1992
del Software. de medir los elementos
(R2002)
que involucrados en la
productividad del
software.
rra
Estándar IEEE
para la Este estándar describe el
IEEE Std
Planificación de formato y el contenido de
1058- P
la Gestión de un un plan de gestión de un
1998
Proyecto proyecto software.
Software
Este estándar describe la
Estándar IEEE
metodología (abarcando
para la
IEEE Std todo el ciclo de vida) para
Metodología de
1061- establecer los requisitos de S S S S P
las Métricas de
1998 calidad, y para identificar,
Calidad del
implementar y validar las
Software
medidas correspondientes.
Este documento
recomienda un conjunto
de útiles prácticas que
Bo
Práctica IEEE pueden ser seleccionadas y
IEEE Std
recomendada aplicadas durante la
1062,
para la adquisición del software. S P
Edición
Adquisición del Esto se ajusta a la
1998
Software adquisición que incluye
desarrollo o modificación
más que a la propia
compra en sí.
Gestión en Procesos de Herramientas
Número Requisitos Diseño Gestión de la la la y Métodos en
Nombre del Construcción Pruebas del Mantenimiento
de Descripción del del configuración Ingeniería Ingeniería la Ingeniería Calidad
estándar del Software Software del Software
estándar Software Software del Software del del del Software
Software Software
IEEE Std Estándar IEEE Este estándar provee el
r
1063- para la mínimo de requisitos para
2001 Documentación la estructura, contenido, y
de Usuario del formato de la P S
Software documentación de usuario
(ambos impresos y de
do
forma electrónica).
IEEE Std Estándar IEEE Este estándar describe una
1074- para el Proceso aproximación para
1997 del Ciclo de definición del proceso del P
Vida del ciclo de vida del software.
Desarrollo.
IEEE Std Guía IEEE para Este estándar es el primero
1175.1- la Interconexión de las series planeadas de
2002 de Herramientas los estándares de
CASE. integración de herramientas
— CASE dentro del entorno
Clasificación y de producción de ingeniería P
Descripción. del software. Esta parte
rra
describe conceptos
fundamentales e introduce
el resto de las partes.
IEEE Std Estándar IEEE Este estándar describe un
1219- para el proceso para el
P S
1998 Mantenimiento mantenimiento del software
del Software. y su gestión.
IEEE Std Estándar IEEE Este estándar describe las
1220- para la actividades de ingeniería de
1998 Aplicación y sistemas y el proceso
Gestión de requerido en todo el ciclo
Procesos de de vida del sistema para el P
Ingeniería de desarrollo de sistemas que
Sistemas. permitan conocer las
necesidades, requisitos de
Bo
los clientes, y sus límites.
IEEE Std Estándar IEEE Este estándar describe el
1228- para Planes mínimo contenido de un
1994 Seguros del plan para aspectos del S S S P
Software. software tales como el
desarrollo, obtención,
mantenimiento, y la
retirada de un sistema
crítico-seguro.
Gestión en Procesos de Herramientas
Número Requisitos Diseño Gestión de la la la y Métodos en
Nombre del Construcción Pruebas del Mantenimiento
de Descripción del del configuración Ingeniería Ingeniería la Ingeniería Calidad
estándar del Software Software del Software
estándar Software Software del Software del del del Software
Software Software
IEEE Std Guía IEEE para Este documento provee
r
1233, el Desarrollo de una guía en el desarrollo
Edición los Requisitos de una especificación de
1998 del Software. requisitos del software,
cubriendo la
identificación,
do
organización,
P
presentación, y la
modificación de requisitos.
También provee una guía
de las cualidades y
características de los
requisitos.
rra
S S S P
IDEF0. sistema.
IDEF0 puede ser usado
para definir los requisitos
en términos de funciones
para ser presentadas en el
sistema deseado
IEEE Std Estándar IEEE Este estándar define dos
1320.2- para el lenguajes de modelado
1998 Modelado conceptual, llamado
Conceptual generalmente IDEF1X97
— (IDEFObject). El lenguaje
S S P
Sintaxis y soporta la implementación
Semántica del de bases de datos
Lenguaje para relacionales, de objetos, y
IDEF1X 97 modelos de objetos.
Bo
(IDEFobject)
IEEE Std Guía IEEE para Este documento provee la
1362- Información guía del formato y
1998 Tecnológica contenido de un
— documento de Concepto de
Definición del Operaciones (ConOps),
Sistema describiendo las P
— características de un
Documento de sistema propuesto desde
Concepto de un punto de vista del
Operaciones usuario.
(ConOps)
Gestión en Procesos de Herramientas
Número Requisitos Diseño Gestión de la la la y Métodos en
Nombre del Construcción Pruebas del Mantenimiento
de Descripción del del configuración Ingeniería Ingeniería la Ingeniería Calidad
estándar del Software Software del Software
estándar Software Software del Software del del del Software
Software Software
IEEE Std Estándar IEEE Este estándar y sus
r
1420.1- para Información suplementos describen
1995, Tecnológica información que las
1420.1a- — librerías de reutilización
1996, y Reutilización del del software deben ser
1420.1b- Software capaces de cambiar según
do
P
1999 — activos de intercambio.
(R2002) Modelo de Datos
para la
Interoperabilidad
de las Librerías
de Reutilización
IEEE Std Estándar IEEE Este estándar provee los
1462- — pasos para la evaluación y
1998 // Adopción del selección de las
ISO/IEC Estándar herramientas CASE.
14102:19 Internacional
95 ISO/IEC
14102:1995
—
rra
P
Información
Tecnológica
—
Guía para la
Evaluación y la
Selección de
Herramientas
CASE.
IEEE Std Estándar IEEE, Este estándar describe la
1465- Adopción del calidad de los requisitos
1998 Estándar que se ajustan
// Internacional específicamente a los
ISO/IEC ISO/IEC paquetes software y a la
12119 12119:1994(E), guía de pruebas de los
Información paquetes contra los
Bo
Tecnológica requisitos. S P
—
Paquete
Software
—
Requisitos de
Calidad y de
prueba.
Gestión en Procesos de Herramientas
Número Requisitos Diseño Gestión de la la la y Métodos en
Nombre del Construcción Pruebas del Mantenimiento
de Descripción del del configuración Ingeniería Ingeniería la Ingeniería Calidad
estándar del Software Software del Software
estándar Software Software del Software del del del Software
Software Software
IEEE Std Recomendación Este documento P
r
1471- Práctica IEEE recomienda un marco
2000 para la conceptual y contenido
Descripción para la descripción
S S
Arquitectónica arquitectónica de sistemas
de Sistemas intensivos de software.
do
Intensivos de
Software.
IEEE Std Guía IEEE Este documento es la
1490- — adopción IEEE del Cuerpo
1998 Adopción del de la Gestión del Proyecto
Estándar PMI de Conocimiento definido
— por el Instituto de Gestión
Una Guía para el del Proyecto. Identifica y P
Cuerpo de la describe al conocimiento
Gestión del generalmente aceptado con
Proyecto del lo que concierne a la
Conocimiento. gestión del proyecto.
rra
IEEE Std Estándar IEEE Este estándar provee el
1517- para la ciclo de vida de los
1999 Información procesos para la
Tecnológica reutilización sistemática
— del software. Los procesos
Procesos del son idóneos para ser S P
Ciclo de Vida utilizados con IEEE/EIA
del Software 12207.
—
Reutilización de
Procesos
IEEE Std Estándar IEEE Este estándar provee un
1540- para los Procesos proceso de ciclo de vida
2001 del Ciclo de para gestionar problemas
// Vida del del software. El proceso es
ISO/IEC Software idóneo para ser usado con S P
Bo
16085:20 — IEEE/EIA 12207.
03 Gestión de
problemas
Gestión en Procesos de Herramientas
Número Requisitos Diseño Gestión de la la la y Métodos en
Nombre del Construcción Pruebas del Mantenimiento
de Descripción del del configuración Ingeniería Ingeniería la Ingeniería Calidad
estándar del Software Software del Software
estándar Software Software del Software del del del Software
Software Software
IEEE Std Práctica IEEE Este documento
r
2001- Recomendada recomienda prácticas para
2002 para Internet la ingeniería de las páginas
— WWW para usar entornos
P
Ingeniería, de redes internas y
gestión y ciclo externas.
do
de vida del Sitio
Web
ISO Sistemas de Este estándar especifica
9001: Gestión de los requisitos para un
2000 Calidad sistema de gestión de
— calidad organizacional,
Requisitos consiguiendo proveer
S P
requisitos de los
productos y mejorar la
satisfacción del usuario.
rra
9126- Software modelo para la calidad del
1:2001 — producto software
Calidad del cubriendo la calidad
Producto interna, externa y la
— calidad en uso. El modelo P S S S
Parte 1: tiene una taxonomía de las
Modelo de características definidas
calidad que el software debe
exhibir.
r
A Industrial del una guía para registrar
12207.1 - Estándar información resultante de
1996 Internacional los procesos del ciclo de
ISO/IEC vida de IEEE/EIA
12207:1995, 12207.0.
do
Estándar para la
Información
Tecnológica X X X X X X X P X X
—
Procesos del
Ciclo de Vida
del Software
— Ciclo de vida
de la
Información
rra
1997 Internacional de vida de los procesos de
ISO/IEC IEEE/EIA 12207.0.
12207:1995,
Estándar para la
Información
Tecnológica X X X X X X X P X X
—
Procesos del
Ciclo de Vida
del Software
—
Consideraciones
en la
Implementación
IEEE Std Adopción IEEE Este estándar describe los
Bo
14143.1- de ISO/IEC conceptos fundamentales
2000 // 14143-1:1998 de una clase de medida
ISO/IEC — colectiva conocida como
14143- Información tamaño funcional.
1:1998 Tecnológica
—
Medida del
Software P S S S
—
Medida del
Tamaño
Funcional
—
Parte 1:
Definición de
Conceptos
Gestión en Procesos de Herramientas
Número Requisitos Diseño Gestión de la la la y Métodos en
Nombre del Construcción Pruebas del Mantenimiento
de Descripción del del configuración Ingeniería Ingeniería la Ingeniería Calidad
estándar del Software Software del Software
estándar Software Software del Software del del del Software
Software Software
ISO/IEC Información Este documento provee
r
TR Tecnológica una guía que establece los
14471:19 — procesos y actividades que
99 Ingeniería del pueden ser utilizadas en la
Software adopción de la tecnología
P
— CASE.
do
Guías para la
Adopción de
herramientas
CASE
ISO/IEC Información La serie ISO/IEC 14598 da
14598 Tecnológica una visión de los procesos
(Seis — de evaluación del producto
partes) Evaluación del software y nos ofrece una
producto guía y los requisitos
Software necesarios para la P
evaluación organizacional
o del nivel del proyecto.
Los estándares nos ofrecen
métodos de medida,
rra
valoración y evaluación.
ISO/IEC Información Este estándar da más
14764:19 Tecnológica detalle del proceso de
99 — mantenimiento ofrecido
Mantenimiento por ISO/IEC 12207.
del Software Provee una guía de P
implementación de los
requisitos de ese proceso.
r
Tecnológica
ISO/IEC — Este documento es una
TR Guía para guía para el uso de
P
15271:19 ISO/IEC 12207 ISO/IEC
98 (Procesos del 12207.
do
Ciclo de Vida
del Software)
Ingeniería de
Este estándar nos ofrece en
Sistemas
ISO/IEC marco de procesos usados
—
15288:20 a lo largo del ciclo de vida P
Procesos del
02 de los sistemas hechos por
Ciclo de Vida
el hombre.
del Sistema
ISO/IEC
Este documento técnico
TR
(ahora está siendo revisado
15504
Ingeniería del como un estándar) nos
(9 partes)
Software ofrece los requisitos para
y la
— los métodos que nos P
rra
Preparaci
Proceso de permiten valorar los
ón de
Valoración procesos para mejorar los
IS 15504
procesos o la capacidad de
(5
determinación.
partes)
Ingeniería del Este estándar nos ofrece
Software un proceso de ciclo de vida
ISO/IEC
— para la medición de
15939:20 S P S
Proceso de software. El proceso se
02
Medida del ajusta para ser usado con
Software IEEE/EIA 12207.
Ingeniería del Este estándar describe el
Software Método de Medición de
— Tamaño Funcional
ISO/IEC
COSMIC-FFP COSMIC-FFP, un método
19761:20 P S S S
— Método de de medición de tamaño
Bo
03
medición del funcional conforme a los
tamaño requisitos de ISO/IEC
funcional. 14143-1.
Ingeniería del
Software
—
Este estándar describe el
IFPUG 4.1
Cómputo de Puntos de
Método de
ISO/IEC Función Desajustado de
medida del
20926:20 IFPUG 4.1, un método que P S S S
tamaño funcional
03 mide el tamaño funcional
desajustado
conforme a los requisitos
—
de ISO/IEC 14143-1.
Manual de
Prácticas de
Cómputo
Gestión en Procesos de Herramientas
Número Requisitos Diseño Gestión de la la la y Métodos en
Nombre del Construcción Pruebas del Mantenimiento
de Descripción del del configuración Ingeniería Ingeniería la Ingeniería Calidad
estándar del Software Software del Software
estándar Software Software del Software del del del Software
Software Software
ISO/IEC Ingeniería del Este estándar describe el
r
20968:20 Software Análisis de Puntos de
02 — Función Mk II, un método
Análisis de de medición del tamaño
Puntos de funcional conforme a los P S S S
Función Mk II requisitos de ISO/IEC
do
— Manual de 14143-1.
Prácticas de
Cómputo
ISO/IEC Ingeniería del Este estándar provee una
90003 Software y serie de pasos para la
Sistemas organización en la
— aplicación de ISO
Pasos para la 9001:2000 para la
S S
Aplicación de adquisición, suministro,
ISO desarrollo, operación, y
9001:2000 al mantenimiento del
Software del software del ordenador.
Ordenador
rra
Bo
Bo
rra
do
r
APÉNDICE D
CLASIFICACIÓN DE CONTENIDOS ACORDE A LA TAXONOMÍA DE
BLOOM
r
herramienta en la definición del material usado específica de su grupo.
en el curso, currículo universitario, criterios de
acreditación en el programa universitario, Un ingeniero del software con cuatro años
do
descripción de trabajos, como rol descriptivo de experiencia está aún en el principio de su
dentro un proceso de definición de ingeniería del carrera y le puede ser asignado la gestión de
software, programa de prueba profesional y vía una seria de deberes, o por lo menos, unos
de desarrollo profesional, y otras necesidades, mayores esfuerzos. Los tópicos relacionados
que los niveles de la taxonomía de Bloom para con la Gestión no se les asigna prioridad en
los tópicos de la Guía SWEBOK son propuestos las evaluaciones propuestas. Por la misma
en este apéndice para graduados en ingeniería razón, los niveles de la taxonomía tienden a
del software con unos cuatro años de ser menores para un temprano ciclo de vida
experiencia. Un graduado en ingeniería del de contenidos tales como los relacionados
rra
software con al menos cuatro años de con los requisitos del software, más que los
experiencia es en esencia el objetivo fijado en la contenidos de índole técnico dentro del
Guía SWEBOK por el cual es aceptable el diseño, construcción o prueba del software.
conocimiento contenido en dicha guía (Lea la
Introducción de la Guía SWEBOK). Por lo tanto, las evaluaciones pueden ser
adaptadas por más ingenieros del software
Desde este Apéndice sólo se hace referencia a lo sénior o por ingenieros del software
que puede ser considerado como conocimiento especializados en ciertas áreas de
―generalmente aceptado‖. Es muy importante conocimiento, en el que no hay ningún
Bo
recordar que la ingeniería del software debe ser contenido que dé un mayor nivel de
aprendida de una manera más sustancial que esta taxonomía que el Análisis. Éste es
―categoría‖ de conocimiento. Además del consistente con la aproximación dada en la
conocimiento ―generalmente aceptado‖, un SEEK (Software Engineering Education
graduado de ingeniería del software con cuatro Bosy of Knowledge), donde no hay ningún
años de experiencia debe de poseer algunos contenido asignado de mayor nivel de
elementos de Disciplinas Relacionadas, como taxonomía que Aplicación2. El propósito de
también algunos elementos de ciertos SEEK es definir un cuerpo de educación de
conocimientos específicos, avanzados, hasta la ingeniería del software de conocimiento
posibilidad de estudiar e investigar algunas apropiado para guiar el desarrollo del
materias (Mire la Introducción de la Guía currículum de un estudiante universitario de
SWEBOK). Los siguientes supuestos son ingeniería del software. Aunque
creados cuando se especificaron los niveles notablemente distinto en términos de
propuestos de la taxonomía. alcance, SEEK y la Guía SWEBOK son
muy parecidos.3
Las evaluaciones son propuestas por una
ingeniería del software ―generalista‖ y no
La taxonomía de Bloom del Dominio Cognitivo 2. Mire la Fuerza de la Tarea Conjunta en el Currículum de
Cómputo – Sociedad Computacional IEEE / Asociación para la
propuesto en 1956 tiene seis niveles. La tabla 1 4 Maquinaria Computacional, Currículum de Cómputo – Volumen
presenta estos niveles y las palabras claves de Ingeniería del Software – Borrador público 1 – Ingeniería del
asociadas con cada nivel. Software de Currículum Computacional, 2003:
http://sites.computer.org/ccse/.
3. Mire P.Bourque, F. Robert, J. –M. Lavoie, A. Lee, S. Trudel,
T. Lethbridge, ―Guía para el Conocimiento del Cuerpo de la
Educación de la Ingeniería del Software (SEEK) – Un Mapeo
Preliminar‖. Taller de Tecnología del Software y Conferencia de
la Práctica de la Ingeniería (STEP 2002), 2002, pp. 8-35.
1. B. Bloom (ed.), Taxonomía de los Objetivos Educativos: La 4. Tabla adaptada de
Clasificación de las Metas Educativas, Mackay, 1956. http://www.nwlink.com/~donclark/hrd/bloom.html.
r
Tabla 1 Taxonomía de Bloom
Nivel de Taxonomía de Bloom Palabras claves asociadas
Conocimiento: Almacenamiento de la información Define, describe, identifica, conoce, etiqueta, listas,
do
ajustes, nombres, esquemas, memorias,
reconocimiento, reproduce, selecciona, estados
Comprensión: Entender el significado, traducción, Comprende, convierte, defiende, distingue, estima,
interpolación e interpretación de las instrucciones y explica, prolonga, generaliza, da ejemplos, deduce,
problemas; plantea un problema en una de las propias interpreta, ilustra, predice, reescribe, resume, traduce.
palabras.
Aplicación: Utiliza un concepto en una nueva situación Aplica, cambia, computa, construye, demuestra,
o usa una abstracción espontánea; aplica lo que fue descubre, manipula, modifica, opera, predice, prepara,
aprendido en la clase en situaciones novedosas en el muestra, resuelve y usa.
lugar del trabajo.
rra
Análisis: Separa material o conceptos en partes que su Analiza, descompone, compara, contrasta, diagramas,
estructura organizacional puede ser comprendida; destruye, diferencia, discrimina, distingue, identifica,
distingue entre hechos e interferencias. ilustra, infiere, esquematiza, relata, selecciona, separa.
Síntesis: Crea una estructura o prototipo de una serie Categoriza, combina, compila, compone, crea, idea,
de diversos elementos; une partes para crear un diseña, explica, genera, modifica, organiza, planifica,
conjunto, con énfasis en la creación de una nueva cambia de lugar, reestructura, relata, reorganiza, revisa,
estructura o significado. reescribe, resume, cuenta, escribe.
Evaluación: Hace un juicio sobre el valor de las ideas o Tasa, compa, concluye, contrasta, critica, defiende,
materiales. describe, discrimina, evalúa, explica, interpreta, justifica,
relata, resume, acepta.
Bo
La separación de contenidos en las tablas no coincide
perfectamente con la separación de las Áreas de
Conocimiento. La evaluación para este Apéndice fue
preparado mientras algunos comentarios aún llegaban.
r
do
rra
Bo
REQUISITOS DEL SOFTWARE5 DISEÑO SOFTWARE
taxonomía
taxonomía
Nivel de
Nivel de
Separación
Desglose dedecontenidos
contenidos Desglose de contenidos
r
Requisitos cuantificables C 2. Temas clave en el diseño software
Requisitos del software y del sistema C Concurrencia AP
Manejo y control de eventos AP
do
2. Requisitos del proceso
Modelos del proceso C Distribución de componentes AP
Actores del proceso C Manejo de errores y excepciones y falta AP
Gestión y soporte del proceso C de tolerancia
Calidad y mejora del proceso C Interacción y presentación AP
3. Obtención de requisitos Persistencia de los datos AP
Fuentes de los requisitos C 3. Estructura y arquitectura del software
Técnicas de obtención AP Estructuras y puntos de vistas de la AP
arquitectura
4. Requisitos de análisis
rra
Estilos de arquitectura (Patrones de AN
Clasificación de los requisitos AP
arquitectura)
Modelo conceptual AN
Patrones de diseño (Patrones de AN
Diseño arquitectónico y requisitos de AN
arquitectura)
cuota
Familias de programas y de marcos de C
Requisitos de negociación AP
trabajo
5. Especificación de requisitos
4. Análisis y evaluación de la calidad del
Documento de definición del sistema C
diseño software
Especificación de los requisitos del C
Atributos de calidad C
sistema
Técnicas de análisis y evaluación de la AN
Bo
taxonomía
taxonomía
Nivel de
Nivel de
Desglose de contenidos Desglose de contenidos
r
Anticipación al cambio AN
Construyendo para verificar AN Relación de las pruebas con otras C
Estándares en la construcción AP actividades
do
2. Gestión de la construcción 2. Niveles de pruebas
Métodos de construcción C El objetivo de las pruebas AP
Plan de construcción AP Los fines de probar AP
Medidas de construcción AP 3. Técnicas de pruebas
3. Consideraciones prácticas Basado en la intuición y experiencia del AP
Fuentes de los requisitos C probador
Técnicas de obtención AP Basados en la especificación AP
4. Requisitos de análisis Basados en el código AP
Basados en los fallos AP
rra
Diseño de la construcción AN
Lenguajes de la construcción AP Basados en el uso AP
Codificación AN Basados en la naturaleza de la AP
Pruebas de la construcción AP aplicación
Calidad de la construcción AN Seleccionando y combinando técnicas AP
Integración AP 4. Medidas relacionadas con las pruebas
Evaluación de un programa bajo AN
pruebas
Evaluación de las pruebas desarrolladas AN
5. Proceso de prueba
Bo
taxonomía
taxonomía
Nivel de
Nivel de
Desglose de contenidos Desglose de contenidos
r
Definiciones y terminología C Restricciones y guía para SCM C
Naturaleza del mantenimiento C Planificación para SCM
Necesidad del mantenimiento C Organización y responsabilidades AP
do
Mayoría de los costes del C SCM
Esquemas y recursos SCM AP
mantenimiento
Selección de herramientas e AP
Evolución del software C implementación
Categorías del mantenimiento AP Control del C
2. Contenidos claves en el mantenimiento del vendedor/subcontratista
software Control de la interface C
Técnico Plan de gestión de la configuración del C
Comprensión limitada C software
rra
Pruebas AP Gestión de la configuración de la vigilancia
Análisis de impacto AN del software
Mantenibilidad AN Medición y medidas SCM AP
Auditorías de SCM C
Temas de gestión
2. Identificación de la configuración del
Alineación con asuntos C
software
organizacionales
Identificación de los elementos a ser
Personas C controlados
Asuntos de procesos C Configuración del software AP
Organizacional C Elementos de la configuración del AP
Estimación del coste de mantenimiento software
Bo
r
Construcción del software AP
Gestión de la venta al mercado del
software
do
rra
Bo
GESTIÓN DE LA INGENIERÍA PROCESO DE INGENIERÍA DEL
DEL SOFTWARE SOFTWARE
taxonomía
taxonomía
Nivel de
Nivel de
Desglose de contenidos Desglose de contenidos
r
Análisis de viabilidad AP ingeniería del software
Proceso para el análisis y revisión del C Factoría de experiencia C
software Actividades AP
do
2. Planificación del proyecto software Modelos para el proceso de K
Proceso de planificación C implementación y cambio
Determinación de las entregas AP Consideraciones prácticas C
Esfuerzo, programa y estimación de AP 2. Definición del proceso
coste Modelos de ciclo de vida AP
Asignación de recursos AP Procesos de ciclo de vida del software C
Gestión de problemas AP Notaciones para las definiciones del C
Gestión de la calidad AP proceso
Proceso de adaptación C
rra
Plan de gestión C
3. Difusión del proyecto software Automatización C
Implementación de planes AP 3. Valoración del proceso
Gestión del contrato de proveedores C Modelos de valoración del proceso C
Implementación de procesos de AP Métodos de valoración del proceso C
medición 4. Medición del proceso y del producto
Proceso de monitoreo AN Medición del proceso software AP
Proceso de control AP Medición del producto software AP
Informando AP Medición del tamaño AP
4. Revisión y evaluación Medición de la estructura AP
Bo
taxonomía
taxonomía
Nivel de
Nivel de
Desglose de contenidos Desglose de contenidos
r
Herramientas de construcción del AP Valor y coste de la calidad AN
software Características y modelos de la calidad
Herramientas de pruebas del software AP Calidad del proceso software AN
do
Herramientas de mantenimiento del AP Calidad del producto software AN
software Mejora de la calidad AP
Herramientas del proceso de ingeniería AP 2. Procesos de gestión de la calidad del
del software software
Herramientas de calidad del software AP Aseguramiento de la calidad del AP
Herramientas de gestión de la AP software
configuración del software Verificación y validación AP
Herramientas de gestión de la AP Revisión y auditoría
ingeniería del software Inspecciones AP
rra
Herramientas para otros diversos AP Revisiones minuciosas AP
asuntos Revisión de la funcionalidad, AP
2. Métodos de ingeniería del software entradas y salidas del software
Métodos heurísticos AP Pruebas AP
Notaciones y métodos formales C Auditorías C
Métodos de prototipado AP 3. Consideraciones prácticas
Métodos para otros diversos asuntos C Aplicación de los requisitos de la
calidad
Nivel de criticidad de los C
Bo
sistemas
Dependencia C
Integridad de los niveles del C
software
Caracterización imperfecta AP
Técnicas de gestión de la calidad del
software
Técnicas estáticas AP
Técnicas intensivas de personas AP
Técnicas analíticas AP
Técnicas dinámicas AP
Medición de la calidad del software AP
Bo
rra
do
r