1

UNIVERSIDAD NACIONAL AUTNOMA DE MXICO

FACULTAD DE CONTADURA Y ADMINISTRACIN
Autor: JOS SERGIO PAZ LUCAS
Ingeniera del software Clave: 1764
Plan: 2005 Crditos: 8
Licenciatura: Informtica Semestre: 7
rea: Informtica (Gestin de la informacin) Hrs. Asesora: 4
Requisitos: Ninguno Hrs. Por semana: 4
Tipo de asignatura: Obligatoria (x) Optativa ( )
Objetivo general de la asignatura
Al finalizar el curso, el alumno integrar los conocimientos previos de anlisis y
diseo de sistemas para el desarrollo de software de calidad, adems de
obtener las metodologas, tcnicas y herramientas para desarrollar sistemas
informticos en el tiempo y costos establecidos.
Temario oficial (64 horas sugeridas)
1. Fundamentos de la ingeniera de software (6 horas)
2. Software (6 horas)
3. Administracin de proyectos (8 horas)
4. Administracin de requerimientos (6 horas)
5. Anlisis de software (12 horas)
6. Diseo de software (10 horas)
7. Verificacin y validacin del software (4 horas)
8. Mantenimiento del software (4 horas)
9. Administracin de la configuracin y de cambios (4 horas)
10. Administracin de la calidad (4 horas)
2
Introduccin
No podemos negar la participacin que tiene actualmente el software en
muchos de los aspectos de nuestra vida y dada esta importancia resulta
necesario llevar a cabo prcticas que contribuyan al desarrollo de buen
software. En esta materia se mostrar al alumno la importancia de la ingeniera
de software como parte de su labor profesional dentro de la informtica. Al
alumno se le presentarn los caminos que pueden dar solucin a problemas
inherentes al desarrollo de software utilizando los conocimientos generados por
la industria de software. La materia se encuentra dividida en diez temas:
En el tema uno (Fundamentos de la ingeniera de software) se realizar una
presentacin al alumno del origen y caractersticas que tiene la ingeniera del
software, de manera de que l sea capaz de reconocer su importancia dentro
de la informtica. En su conjunto ser un marco de referencia que le permitir
diferenciarla de otras disciplinas relacionadas a la computacin.
El tema dos (Software) abarca un anlisis relacionado con las diferentes
clasificaciones que se pueden hacer al software y a las caractersticas que
podran o no ser inherentes al software. Tambin se abordarn los principios de
la ingeniera de software y las herramientas CASE de las que se puede hacer
uso.
El enfoque del tema tres (Administracin de proyectos) partir del valor de esta
disciplina en el desarrollo de sistemas informticos, los elementos que la
integran y se har mencin de las mejores prcticas.
En el tema cuatro (Administracin de requerimientos) se har nfasis en la
importancia que tiene el manejo de los requerimientos para que un proyecto de
desarrollo de software se construya de manera correcta. Internamente se
presentarn las diferentes opciones que permitan la captura, manejo,
actualizacin y clasificacin de los diferentes tipos de requerimientos que se
presentan dentro de un proyecto.
3
Para el tema cinco (Anlisis de software) se realizar un recorrido por esta
fase del desarrollo de software, la cual se realiza desde sus diferentes
perspectivas.
Dentro del tema seis (Diseo de software) se presentarn los diferentes
recursos que pueden emplearse en el modelado de sistemas informticos, de
manera que permitan una representacin clara del sistema en esta fase del
desarrollo.
En el tema siete (Verificacin y validacin de software) se ensear la
diferenciacin de estos dos conceptos y su lugar dentro del ciclo de desarrollo.
Por otra parte se presentarn los diferentes recursos que pueden aplicarse
para llevar a cabo dichas actividades.
Todas las cuestiones relacionadas posteriores a la puesta en operacin del
sistema se vern dentro del tema ocho (Mantenimiento del software).
La posibilidad de cambios durante todo el desarrollo y mantenimiento del
sistema es algo comn, por lo que es recomendable llevar un registro y
seguimiento de los componentes que integran el sistema. Estas cuestiones se
desarrollarn en el tema nueve (Administracin de la configuracin y de
cambios).
Como punto final en el tema diez (Administracin de la calidad) se desarrollar
el problema de la calidad en el desarrollo de software y se presentarn algunas
de las propuestas que han realizado.
4
TEMA 1. FUNDAMENTOS DE LA INGENIERA DE SOFTWARE
Objetivo particular
Al finalizar este tema el alumno ser capaz de reconocer el origen y la
importancia de la ingeniera del software para diferenciarla de otras disciplinas
e identificar los elementos que la integran.
Temario detallado
1.1 Historia
1.2 Crisis del software
1.3 Qu es la IS, ciencia, arte, disciplina o proceso?
1.4 Objetivo de IS
1.5 Las cuatro P de la IS
1.6 Proceso de IS
1.7 Relacin de la IS con las dems asignaturas de la Licenciatura en
Informtica
1.8 Sistema y sistema informtico
1.9 Metodologa, tcnicas y herramientas
1.10 Cdigo de tica ACM/IEEE
1.11 Ciclo de vida de Sistemas y Modelos
Introduccin
La ingeniera de software surge como una necesidad de responder a
problemas relacionados al desarrollo de software. Con la finalidad de solventar
los problemas detectados se han instrumentado varias propuestas que en su
conjunto ayudan a reducir de manera considerable los problemas planteados.
Emplear y desarrollar las mejores prcticas propuestas por la ingeniera de
software nos posibilita una mejor comprensin hacia a la construccin de buen
software.
5
1.1. Historia
La historia de la ingeniera de software se encuentra ligada a la evolucin y
madurez de la programacin de software. Al inicio el problema radicaba en
colocar una secuencia de instrucciones dentro de una computadora para que
hicieran algo til. Con la aparicin de lenguajes de alto nivel y la reduccin de
costos de las computadoras se ampli el acceso a la programacin, lo que
posibilit la construccin gradual de la profesin. No existan grandes
desarrollos de software sino hasta mediados de 1960, de los cuales se puede
mencionar el sistema operativo OS 360 para las computadoras IBM 360. Una
vez que el software se emplea para resolver problemas ms complejos es
entonces cuando se hacen evidentes las dificultades para emplear las tcnicas
de desarrollos pequeos a desarrollos ms grandes y complejos. Los
problemas que se presentaban no eran los mismos que se presentaban en los
inicios de la programacin. Con la finalidad de resolver los problemas del
desarrollo de software se opt por adquirir la perspectiva con la que las
ingenieras construyen otros sistemas complejos. Si bien es cierto que el
nacimiento de la ingeniera de software se da con la programacin, es
importante considerar otros factores que han influido tambin de manera
importante en su crecimiento como: la disminucin de los costos en el
hardware y el aumento de los costos en el software, el cambio de perspectiva
del software como un ciclo de vida y no solamente como cdigo, la presencia
del software en nuestra sociedad.
Claramente se puede observar que conforme el desarrollo de software se fue
haciendo ms complejo los problemas se hicieron ms evidentes. A
continuacin se presenta un cuadro que ilustra la historia de la ingeniera del
software por fases.
6
Fase Descripcin
Primera Fase. Los albores
(1945-1955)
Programar no es una tarea
diferenciada del diseo de una
mquina
Uso de lenguaje mquina y
ensamblador
Segunda Fase. El florecimiento
(1955-1965)
Aparecen multitud de lenguajes
Se pensaba que era posible hacer
casi todo
Tercera Fase. La crisis (1965-1970) Desarrollo inacabable de grandes
programas
Ineficiencia, errores, coste
impredecible
Nada es posible
Cuarta Fase. Innovacin conceptual
(1970-1980)
Fundamentos de programacin
Verificacin de programas
Metodologas de diseo
Quinta Fase. El diseo es el problema
(1980-?)
Entornos de programacin
Especificacin formal
Programacin automtica
Cuadro 1.1. Historia del desarrollo de software
1.2 Crisis del software
El trmino Ingeniera del Software fue utilizado por Fritz Bauer en la primera
conferencia sobre desarrollo de software patrocinada por el Comit de Ciencia
de la OTAN celebrada en Garmisch (Alemania), en octubre de 1968.
El trmino crisis del software identifica la precaria situacin en la que se
encontraba el desarrollo de software a comparacin de otras disciplinas ante la
demanda de nuevos sistemas.
7
Entre los problemas que acompaan al desarrollo de software podemos
encontrar:
Retrasos considerables en la planificacin
Poca productividad
Elevadas cargas de mantenimiento
Demandas cada vez ms desfasadas con las ofertas
Baja calidad y fiabilidad del producto
Dependencia de los realizadores
1.3 Qu es la IS, ciencia, arte, disciplina o proceso?
Es un campo de la computacin que tiene que ver con la construccin de
sistemas de software los cuales son grandes y complejos, son construidos por
grupos de ingenieros. Resulta difcil determinarla en slo una clasificacin
debido a que se cuenta con varias perspectivas de lo que es la ingeniera de
software por los varios contextos en los que ha participado.
Existen dos perspectivas dentro de la ingeniera de software: una que tiene
como objeto de estudio a los problemas tericos propios de la computacin,
mientras que la otra perspectiva se encarga de la construccin de software.
Un programador escribe un programa de software, mientras un ingeniero de
software escribe componentes de software e integra otros elementos que sern
combinados, bajo una perspectiva de calidad, para solucionar un problema. La
primera actividad se puede considerar como individual, mientras que la ltima
es esencialmente una actividad de equipo. La programacin es slo una
actividad dentro de la ingeniera de software.
El ingeniero del software emplea sus conocimientos multidisciplinarios para
solucionar problemas y a diferencia de otras disciplinas de las ciencias de la
computacin emplea los conocimientos tericos que desarrollan las otras
8
disciplinas para solucionar problemas que pueden no pertenecer por naturaleza
a un problema de la computacin. El desarrollo de software implica
responsabilidades profesionales y sociales.
La ingeniera de software implica requiere disciplina para llevar a cabo las
actividades inherentes al trabajo diario que le permitirn mejorar de manera
constante el trabajo que realiza a nivel individual. Este esfuerzo representa un
aspecto importante con miras a realizar un producto de calidad como resultado
de participacin de muchas personas.
La ingeniera de software emplea recursos tericos y notaciones cientficas
para el desarrollo de aplicaciones, pero tambin utiliza modelos con la finalidad
de representar aspectos de la realidad de manera sistemtica. En este aspecto
la ingeniera de software es una ciencia que estudia de manera sistemtica los
problemas del software. Como resultado de esta perspectiva son los mtodos,
tcnicas, metodologas y herramientas que pueden utilizarse.
La ingeniera de software es un proceso si se considera que para el desarrollo
de software se requieren entradas, pasos establecidos y salidas. Este esquema
de trabajo facilita el entendimiento de la forma en la opera la construccin de
software para solucionar un problema.
La ingeniera de software es un arte en cuanto a la identificacin de elementos
a utilizar dependiendo del contexto, el manejo de las relaciones humanas,
establecimiento de criterios de calidad, solucin a problemas ticos,
interpretacin y solucin de problemas basados en software, etc. Todos estos
problemas se caracterizan por sobrepasar las dificultades tcnicas y es por eso
que se emplean recursos adicionales, como la creatividad y el buen juicio, para
dar una solucin oportuna.
La ingeniera de software emplea recursos de diferentes reas del
conocimiento dada la complejidad que implica la construccin de software. No
9
es posible determinar a la ingeniera de software en una sola perspectiva por la
naturaleza de su objeto de estudio a comparacin de las otras ingenieras. Esto
demuestra que es posible verla como ciencia, arte, disciplina o proceso, todo
depender del punto de vista que se tome y lo cual no las hace excluyentes
una de otra sino complementarias.
La ingeniera de software es:
Es la aplicacin de un planteamiento sistemtico, disciplinado y cuantificable al
desarrollo, operacin y mantenimiento de software.
1
1.4 Objetivos de la IS
El objetivo de la IS es desarrollar software de alta calidad. Esto implica que el
software que se est desarrollando cuente con ciertas caractersticas entre las
que podemos encontrar: robustez, fcil de entender, fcil de mantener, etc.
Para lograr este objetivo se pueden emplear los modelos de referencia de los
procesos de desarrollo de software con calidad.
Para entender lo que se refiere a software de calidad es importante revisar las
diferentes perspectivas que se tienen en cuanto a la calidad.
2
McCall
CMM
ISO 9000
ISO/IEC 9126
1
IEEE Standard Glossary of Software Engineering Terminology, IEEE, Piscataway, Nueva
Jersey, Std. 610.12-1990.
2
Algunos de estos modelos sern desarrollados en el tema diez.
10
1.5 Las cuatro P de la IS
Resulta importante reconocer que la ingeniera de software es posible por el
esfuerzo humano, definir los objetivos y alcances de lo que se va a desarrollar,
poner atencin en la forma en la que se colocan los mtodos y herramientas y,
finalmente, en elaborar un plan slido para desarrollar el producto. Una
administracin efectiva de un proyecto de software se enfoca en las cuatro Ps:
Personas. Se refiere a las personas que participan dentro de un
proyecto de software y sus interacciones.
Producto. Se refiere a los elementos que se entregan y que van ms all
de la aplicacin de software.
Proceso. Proporciona un marco sobre el cual se puede establecer un
plan claro para desarrollar software. Mediante l los proyectos producen
productos de manera efectiva debido a que las actividades propuestas
se pueden ajustar a las caractersticas del proyecto.
Proyecto. Su objetivo es realizar un producto de software.
El resultado final de un proyecto de software es un producto, donde intervienen
personas a travs de un proceso de desarrollo de software que gua los
esfuerzos de las personas implicadas en el proyecto.
1.6. Proceso de IS
Es un conjunto de actividades tcnicas y administrativas realizadas durante la
adquisicin, desarrollo, mantenimiento y retiro de software
3
.
Existe un acercamiento al proceso de ingeniera del software desde dos puntos
de vista. El primer nivel tiene que ver con las cuestiones tcnicas y
administrativas dentro de los procesos del ciclo de vida durante la adquisicin,
desarrollo, mantenimiento y retiro del software. La segunda parte es un meta-
3
IEEE. Guide to the Software Engineering Body of Knowledge. IEEE Computer Society
SWEBOK, 2004, p. 9-1.
11
nivel que comprende las definiciones, implementacin, evaluacin, medicin,
administracin, cambio y mejora de los procesos mismos del ciclo de vida de
software.
El trmino proceso de ingeniera del software se puede interpretar de varias
formas que pueden llegar a confundir:
La adicin del artculo El a procesos de ingeniera del software puede
dar a entender que slo existe una forma para realizar las actividades,
cuando en realidad existen varios procesos involucrados.
Otro significado tiene que ver con la discusin general de los procesos
relacionados a la ingeniera del software.
El tercer significado tiene que ver con el conjunto actual de actividades
desempaadas dentro de una organizacin, las cuales pueden ser vistas
como un proceso dentro de una organizacin.
El proceso de ingeniera de software es importante no slo para organizaciones
grandes ya que todas las actividades han sido desempeadas exitosamente
por organizaciones pequeas o individuales.
1.7. Relacin de la IS con las dems asignaturas de la Licenciatura en
Informtica
Existe una relacin entre las materias de la licenciatura en Informtica y la
ingeniera de software es que ambas se interesan por la solucin de problemas
a travs del empleo de software. El complemento que realiza la ingeniera de
software es la adicin de recursos (modelos, tcnicas y herramientas) para
construir una solucin de software con calidad.
La perspectiva de calidad es compatible con las materias abordadas por la
informtica y debe de verse como una adicin que aade valor y permite
ampliar la visin de slo automatizar informacin.
12
1.8. Sistema y sistema informtico
Por una parte: Un sistema puede ser definido como un complejo de elementos
interactuantes.
4
Sistema. Coleccin de componentes organizados para cumplir una funcin
especfica o un conjunto de funciones.
5
Un sistema informtico es un conjunto de aplicaciones de software que se
ejecutan para proporcionar un resultado. Es un conjunto de software, hardware
y personas.
Los sistemas de informacin tienen muchas cosas en comn, la mayora de
ellos estn formados por:
- Personas: es el componente esencial en cualquier sistema de informacin,
producen y utilizan la informacin de sus actividades diarias para decidir lo
que se debe hacer. Las decisiones pueden ser rutinarias o complejas.
- Procedimientos, los sistemas de informacin deben soportar diversas clases
de actividades del usuario, por eso han de establecerse procedimientos que
aseguren que los datos correctos llegan a las personas adecuadas en su
momento justo.
- Equipo, es decir, los ordenadores con sus programas y todos los dispositivos
necesarios.
1.9. Metodologa, tcnicas y herramientas
Para solucionar un problema en la ingeniera de software es posible recurrir a
metodologas, tcnicas y herramientas. La relacin estrecha entre estos tres
elementos hace posible mejorar la calidad del software.
4
Bertalanffy, Ludwig von. Teora general de los sistemas. p. 56.
5
IEEE 610.12-1990.
13
Metodologa
Propone un acercamiento para resolver una problemtica empleando recursos
organizados de manera particular. Es una perspectiva que contiene fases,
procedimientos, reglas, tcnicas, herramientas, documentacin y aspectos de
formacin para los desarrolladores de sistemas de informacin.
Tcnica
Mtodo o procedimiento (con referencia a detalles prcticos o formales), o
forma de usar habilidades bsicas, en la representacin de un trabajo artstico
o realizando una operacin mecnica o cientfica.
6
Es el proceso que permite asegurar que algn aspecto de la aplicacin o
unidad funciona apropiadamente.
7
Puede verse tambin como un procedimiento formal que produce algn
resultado. Especializacin en un tema en una perspectiva terico-prctica.
Describe la manera general la forma en la que pueden hacerse las cosas.
Herramienta
Es un instrumento que permite realizar las cosas de mejor forma. Es el medio
sobre el cual se apoyarn las tareas con el fin de realizar una mejora en alguno
de sus aspectos. Suelen ser los elementos ms abundantes y puede existir
ms de uno que sirva de apoyo a una misma tarea. La seleccin de una
herramienta deber de ser el resultado de una estrategia que apuntale la
direccin y los elementos necesarios para lograr los objetivos.
Es el vehculo para desempear un proceso de pruebas.
8
6
Hutcheson, Marnie L. Software Testing Fundamentals: Methods and Metrics. Indianapolis,
Wiley, 2003.
7
PERRY, William E. Effective methods for software testing. New York, Wiley, 1995. P. 361.
8
PERRY, William E. Effective methods for software testing. New York, Wiley, 1995. P. 361.
14
1.10. Cdigo de tica ACM/IEEE
9
La ACM (Association for Computing Machinery) aprob el cdigo en noviembre
de 1998 y la IEEE (Institute of Electrical and Electronics Engineers) Computer
Society, en diciembre del mismo ao.
Cdigo de tica y Prctica Profesional 5.2
PREMBULO
La versin corta del cdigo resume las aspiraciones a un alto nivel de
abstraccin; las clusulas que se incluyen en la versin completa
proporcionan ejemplos y detalles acerca de cmo estas aspiraciones
modifican nuestra manera de actuar como profesionales de la ingeniera
de software. Sin las aspiraciones los detalles pueden convertirse en
tediosos y legalistas; sin los detalles las aspiraciones pueden convertirse
en altisonantes pero vacas; juntas, las aspiraciones y los detalles
forman un cdigo cohesivo.
Los ingenieros de software debern comprometerse a convertir el
anlisis, especificacin, diseo, implementacin, pruebas y
mantenimiento de software en una profesin respetada y benfica. De
acuerdo a su compromiso con la salud, seguridad y bienestar social, los
ingenieros de software debern sujetarse a los ocho principios
siguientes:
Sociedad. Los ingenieros de software actuarn en forma congruente con
el inters social.
Cliente y empresario. Los ingenieros de software actuarn de manera
que se concilien los mejores intereses de sus clientes y empresarios,
congruentemente con el inters social.
Producto. Los ingenieros de software asegurarn que sus productos y
modificaciones correspondientes cumplen los estndares profesionales
ms altos posibles.
9
Esta es una versin corta del cdigo de tica. La versin completa se puede encontrar en:
http://www.acm.org/about/se-code#full, consultado el 18/05/09.
15
Juicio. Los ingenieros de software mantendrn integridad e
independencia en su juicio profesional.
Administracin. Los ingenieros de software gerentes y lderes
promovern y se suscribirn a un enfoque tico en la administracin del
desarrollo y mantenimiento de software.
Profesin. Los ingenieros de software incrementarn la integridad y
reputacin de la profesin congruentemente con el inters social.
Colegas. Los ingenieros de software apoyarn y sern justos con sus
colegas.
Personal. Los ingenieros de software participarn toda su vida en el
aprendizaje relacionado con la prctica de su profesin y promovern un
enfoque tico en la prctica de la profesin.
1.11. Ciclo de vida de Sistemas y Modelos
Ciclo de vida. Evolucin de un sistema, producto, servicio, proyecto u otra
entidad realizada por el hombre desde su concepcin hasta el retiro.
Modelo de ciclo de vida. Marco de referencia de procesos y actividades
relacionados al ciclo de vida que puede estar organizado en fases, el cual
acta como una referencia comn para la comunicacin y entendimiento.
Procesos del ciclo de vida del software. Marco de referencia que contiene
procesos, actividades y tareas que sern aplicadas durante la adquisicin de
un producto de software o servicio y durante el abastecimiento, desarrollo,
operacin, mantenimiento y disposicin de productos de software.
Estas son tres definiciones extradas del estndar ISO/IEC 12207
10
son
planteamientos generales, de manera especfica se encuentran varios modelos
que presentan las diferentes formas en las que es posible llevar a cabo la
10
ISO/IEC. Systems and software engineering Software Life Cycle Processes. IEEE std
12207:2008, 2008.
16
creacin de un producto de software, tambin son conocidos como modelos de
proceso de software. A continuacin se presentan algunos de ellos.
Modelo de cascada. Contiene las actividades bsicas que se pueden encontrar
en la mayora de los modelos y se encuentra dividido generalmente en fases:
especificacin de requerimientos, diseo de software, implementacin, pruebas
y mantenimiento.
Modelo basados en componentes. Su inters es en componentes reutilizables
que ya existen y se enfoca principalmente a integrarlos y no tanto a un
desarrollo completamente nuevo.
Modelo evolutivo. Son modelos que se adaptan a la evolucin que sufren los
requisitos del sistema en funcin del tiempo. Algunas actividades se entrelazan
de manera que manera que se realice un desarrollo rpido que constantemente
que se refina en varias versiones con las peticiones del cliente.
Modelos de mtodos formales. Permiten especificar, desarrollar y verificar un
sistema generando un modelo formal matemtico.
Proceso unificado
11
. Es considerado un modelo hbrido porque integra varios
de los elementos de los procesos genricos. Integra una perspectiva dinmica
con las fases iterativas, una perspectiva esttica con los workflows y una
perspectiva prctica con las buenas prcticas.
Mtodos giles. Son modelos enfocados a desarrollos iterativos e
incrementales. Requieren de la participacin constante del usuario durante el
proceso de desarrollo. Eliminan cualquier sobrecarga de trabajo en el
desarrollo con la finalidad de hacer desarrollos ms rpidos.
11
Este modelo tambin conocido como RUP, es desarrollado ms adelante en el tema cuatro.
17
Bibliografa del tema 1
Bertalanffy, Ludwig von. Teora general de los sistemas. Mxico, Fondo de
cultura econmica, 2003, 311 pp.
Hutcheson, Marnie L. Software Testing Fundamentals: Methods and Metrics.
Indianapolis, Wiley, 2003. 408 pp.
Perry, William E. Effective methods for software testing. New York, Wiley, 1995,
1008 pp.
PFLEEGER, Shari Lawrence. Ingeniera de software, Teora y prctica. Mxico,
Prentice Hall, 2002, 759 pp.
IEEE. IEEE Software Engineering Standards Collection 1999 Edition. Volume
2: Process Standards. IEEE Computer Society Press, 1999.
IEEE. Standard Glossary of Software Engineering Terminology. IEEE std
610.12-1990, 1990.
ISO/IEC. Systems and software engineering Software Life Cycle Processes.
IEEE std 12207:2008, 2008.
Pginas de referencia
http://www.acm.org/about/se-code/
http://www.swebok.org/
18
Actividades de aprendizaje
A.1.1. Leer la versin completa del cdigo de tica de la ACM/IEEE. La liga se
encuentra en las referencias de este tema. Redactar un reporte de
lectura con la opinin sobre las dificultades para la aplicacin del cdigo
de tica de la ACM/IEEE en el ejercicio profesional.
A.1.2. Realizar un cuadro comparativo en la que se identifiquen las ventajas y
desventajas de los modelos de ciclo de vida.
A.1.3. Investigar y elaborar un cuadro comparativo que permita identificar las
caractersticas de las diferentes disciplinas computacionales: ciencias de
la computacin, ingeniera en computacin, informtica, ingeniera de
software.
A.1.4. Realizar el anlisis sobre los retos de la ingeniera de software con
respecto a las dems ingenieras.
Cuestionario de autoevaluacin
1. Qu es la ingeniera de software?
2. Cundo y en qu contexto surge el trmino crisis del software?
3. Cul es el objetivo de la ingeniera de software?
4. Cul es la relacin de la ingeniera de software y la informtica?
5. Cmo se diferencia un sistema de un sistema informtico?
6. Sobre qu elementos se puede apoyar la ingeniera de software para
mejorar la calidad del software?
7. Cules son los temas que trata el cdigo de tica de la ACM/IEEE?
8. Cul fue el motivo para crear la ingeniera de software?
9. Mencione cuatro modelos de ciclo de vida de software.
10. Qu es el ciclo de vida de software?
19
Examen de autoevaluacin
I. Instrucciones. Responda cada una de las preguntas seleccionando una
de las opciones que se presentan.
1. En qu conferencia se dio a conocer el trmino de ingeniera de software?
a) OTAN
b) ONU
c) GNU
d) TLC
2. En qu fase, dentro de la historia de la IS, aparece el trmino crisis de
software
a) Tercera
b) Primera
c) Novena
d) Ninguna de las anteriores
3. Segn la definicin de crisis de software, cul no sera una causa del
origen de dicho trmino?
a) Poca productividad
b) Retrasos
c) Facilidad de uso
d) Baja calidad
4. Es uno de los principios del cdigo de tica ACM/IEEE
a) Lealtad
b) Honor
c) Juicio
d) Amistad
5. Son los elementos comunes dentro de un sistema de informacin
a) Personas, procedimientos y equipos
b) Cdigo de tica, software y manuales
c) Software y documentacin
d) Personas y software
20
II. Instrucciones. Relacione las dos columnas colocando la letra de la
columna derecha dentro de los parntesis de la columna izquierda.
6. ( ) Se refiere a los elementos que
se entregan y que van ms all de la
aplicacin de software.
a) Objetivo de la ingeniera de
software
7. ( ) Aproximacin lgica a la
adquisicin, el suministro, el
desarrollo, la explotacin y el
mantenimiento del software
b) Metodologa
8. ( ) Conjunto de filosofas, fases,
procedimientos, reglas, tcnicas,
herramientas, documentacin y
aspectos de formacin para los
desarrolladores de sistemas de
informacin.
c) Producto
9. ( ) Formados por un conjunto de
fases o actividades en las que no
tienen en cuenta la naturaleza
evolutiva del software.
d) Ciclo de vida del software
10. ( ) Es desarrollar software de alta
calidad.
e) Modelos tradicionales
21
TEMA 2. SOFTWARE
Objetivo particular
Al finalizar el tema el alumno obtendr los conceptos que identifican y clasifican
al software. Tambin conocer los principios que propone la ingeniera del
software para desarrollar software de calidad y finalmente identificar las
herramientas CASE (Computer-Aided Software Engineering) de las cuales
puede hacer uso.
Temario detallado
2.1 Concepto
2.2 Clasificacin
2.3 Caractersticas
2.4 Principios de la IS
2.5 Herramientas CASE
Introduccin
El software es resultado final del esfuerzo que se realiza durante el proceso de
desarrollo. Es importante reconocer la naturaleza del producto, de ello
depende, en gran parte, para que se identifiquen los alcances y oportunidades
que se pueden realizar con y en l. El desarrollo de software no es una
actividad trivial; por eso existen esfuerzos que sirven de gua para el desarrollo
de software de calidad. La versatilidad del software le permite que sea aplicado
como apoyo en diferentes mbitos dentro de la actividad humana.
2.1 Concepto
Software es un programa de computadora que desempea un conjunto de
funciones.
22
Son los programas de ordenador, los procedimientos y, posiblemente, la
documentacin asociada y los datos relativos a la operacin del sistema
informtico.
El software es un conjunto de algoritmos ejecutados en una computadora. Un
algoritmo es una secuencia de instrucciones lgicas y matemticas con un
objetivo especfico.
Software es concebido tambin como:
Las instrucciones (programas de computadora) que cuando son ejecutas
proporcionan las funciones y desempeo deseados.
Estructuras de datos que posibilitan manipular adecuadamente la
informacin.
Documentos que describen la operacin y uso de los programas.
2.2 Clasificacin
La evolucin de la tecnologa ha posibilitado que se desarrolle software cada
vez ms acorde con las actividades del ser humano. Dada la diversidad de
escenarios en los que se lleva a cabo la aplicacin del software una
clasificacin del software nos permite hacer una distincin de acuerdo a las
diferentes perspectivas en las que se emplean:
Software por funcin o de aplicacin. Es el que se emplean de manera
tal que la computadora llegue a ser una herramienta til para el usuario
final en alguna de las actividades que realiza.
Software de utilera. Permite dar mantenimiento al equipo de cmputo.
Software de entretenimiento. Es aquel que hace posible utiliza al equipo
de cmputo como medio de entretenimiento.
Software integrado. Reside slo en la memoria y es utilizado para
controlar productos y sistemas. Puede realizar funciones limitadas.
23
Software para lenguaje de programacin. Es el software enfocado a un
lenguaje de programacin generando todo un ambiente de desarrollo
que facilite la generacin y ejecucin de cdigo.
Por sistema operativo. Se refiere a todo aquel software que se encarga
de la administracin de los recursos de un equipo de cmputo.
Software personalizado. Permite personalizar las funciones segn los
gustos o tipo de actividades que realiza con en el equipo de cmputo.
Software de negocios. Son todas aquellas que se utilizan para soportar
las operaciones ms importantes de un negocio en funciones como
almacenamiento, anlisis y procesamiento.
2.3 Caractersticas
En el software podemos identificar un conjunto de caractersticas que permiten
identificarlo.
No tiene existencia fsica.
Se desarrolla, no es manufacturado.
Es una herramienta, un medio.
La existencia del software slo se da con la ayuda del hardware o
computadora.
Su entorno cambia constantemente.
Depende de los requerimientos.
Por lo general se construye a la medida.
El desarrollo de software es un trabajo intelectual.
Algunas partes se pueden utilizar en varios proyectos.
El software no se estropea, ni desgasta, slo se hace obsoleto.
En desarrollos grandes se dificulta su control.
Es maleable.
24
Por otra parte, desde la perspectiva de los modelos de calidad, el software
debe de tener ciertas caractersticas que permitan determinar su calidad, de
ellas las ms comunes se pueden encontrar las siguientes:
Correcto. Grado con el cual un sistema o componente se encuentra libre de
defectos en sus especificaciones, diseo e implementacin. Grado en el cual el
software, documentacin u otros elementos cumplen con los requerimientos
especificados.
Confiabilidad. Capacidad de un sistema o componente para desempear sus
funciones requeridas bajo condiciones establecidas durante un periodo de
tiempo especfico.
Flexibilidad. Es la facilidad con la cual un sistema o componente puede ser
modificado para ser utilizado en aplicaciones o ambientes diferentes a los que
inicialmente diseados.
Reusabilidad. Es el grado con el cual un mdulo de software u otro producto
pueden utilizarse en ms de un programa de computadora o sistema de
software.
Portabilidad. La facilidad con la cual un sistema o componente puede
transferirse entre varios ambientes de hardware o software.
Comparabilidad. Capacidad de dos o ms sistemas o componentes para
desempear sus funciones especificadas mientras comparten el mismo
ambiente de hardware o software. Capacidad de dos o ms sistemas o
componentes para intercambiar informacin.
Integridad. Grado con el cual un sistema un sistema o componente previene
accesos no autorizados o modificaciones a programas de computadora o
datos.
25
Funcionalidad. Capacidad del software de contener las funciones acordadas y
las necesidades implicadas cuando el software es utilizado bajo condiciones
especficas.
Fiabilidad. Capacidad del software para mantener un nivel especfico de
desempeo cuando es utilizado en condiciones especficas.
Facilidad de uso. Capacidad del software para ser entendido, enseable, usado
y atractivo al usuario cuando es utilizado en condiciones especficas.
Eficiencia. La capacidad del software para proporcionar un desempeo
adecuado, relacionado a la cantidad de recursos utilizados en ciertas
condiciones.
Facilidad de mantenimiento. La capacidad del software para ser modificado.
Las modificaciones pueden incluir las correcciones, mejoras o adaptaciones a
los cambio del entorno y en los requerimientos y especificaciones funcionales.
Portabilidad. Capacidad del software para ser transferido de un ambiente a
otro.
Robustez. El software es robusto cuando se comporta razonablemente en
circunstancias que no fueron anticipadas en los requerimientos.
Desempeo. El software es eficiente si utiliza los recursos de la computadora
de manera econmica.
Verificabilidad. El software es verificable cuando sus propiedades pueden ser
verificadas fcilmente.
Reparable. El software tiene esta cualidad cuando permite reparar sus defectos
con una limitada cantidad de trabajo.
26
Adaptabilidad. El software evoluciona cuando es modificado en el tiempo para
proveer nuevas funciones o para modificar las que tiene.
Interoperabilidad. Es la habilidad del software para coexistir con otros sistemas.
Estas ltimas caractersticas permiten evaluar al software y algunas de ellas
(dependiendo del modelo) se llegan a dividir en sub-caractersticas y atributos.
Los cuales pueden interactuar entre ellos. Con el tiempo, estas caractersticas
han sido incorporadas por los modelos de calidad, lo cual no quiere decir que
sean todas o que deban de utilizarse por completo cada vez que se realiza un
desarrollo de software, ya que en algunos casos se dar preferencia a unas
caractersticas sobre otras. Cada desarrollo tiene sus propias funciones y
caractersticas e identificarlas es una habilidad que debe formarse por quienes
se encargan de desarrollar software.
2.4 Principios de la IS
Los principios en la IS son aquellos que actan como puntos de referencia para
el desarrollo de software exitoso. Por una parte se encuentra el proceso de
desarrollo y por la otra se hace referencia al producto, haciendo notar que
ambos se encuentran relacionados y tienen la misma importancia.
Los principios son planteados de manera general con la finalidad de que
puedan ser empleados, pero no al grado de guiar el desarrollo de software.
Para que sean aplicados es necesario apoyarse de mtodos y tcnicas que
permitan adoptar los principios al proceso o al producto.
Los principios son la base sobre la cual se posicionan las tcnicas,
herramientas, metodologas y mtodos. La seleccin de principios y tcnicas se
encuentra determinada por las metas de calidad.
Los principios que se presentan a continuacin no son los nicos y se aplican
principalmente al proceso de desarrollo de software.
27
Rigor y formalidad. El rigor es lo que permite que se puedan construir
productos confiables, controlar costos y aumentar la confianza en su
confiabilidad. Pese a lo que se propone el rigor es un aspecto intuitivo que no
puede ser definido de forma rigurosa. Dentro de los grados que existen en
rigor, el ms alto es la formalidad, este requiere que sea dirigido y evaluado por
leyes matemticas. La formalidad implica rigor, pero no necesariamente a la
inversa. La formalidad es la base de la mecanizacin del proceso.
Separacin de intereses. Posibilita la interaccin con diferentes aspectos
individuales de un problema, logrando la atencin de cada una por separado.
Algunas de las decisiones relacionadas a un proyecto de software debern de
tomarse por separado evitando relacionarlas una con otra.
Modularidad. Un sistema complejo de software que puede ser dividido en
piezas o mdulos permite separar los diferentes intereses cuando se abordan
cuestiones que tienen que ver con los detalles de cada; adems, se pueden
estudiar todos los mdulos en relacin para conformar un sistema. La cohesin
permite que exista una fuerte relacin en cada uno de los mdulos y la
integracin se encarga de la relacin entre mdulos.
Abstraccin. Es el proceso en el que se identifican los aspectos importantes de
un fenmeno. En cada abstraccin se eliminan los detalles y se genera una
vista del mundo enfocada a un propsito especfico. Un ejemplo de abstraccin
es cuando se busca representar el funcionamiento de algunos fenmenos a
travs de modelos.
Anticipacin al cambio. El software cambia constantemente por diferentes
circunstancias, la habilidad del software de anticiparse a los cambios tiene que
ver con el cmo y cundo se realizarn los cambios y una vez que son
identificados se deber proceder de manera que los cambios sean realizados
28
fcilmente. La anticipacin a los cambios requiere de un control sobre todos los
elementos del desarrollo.
Generalidad. La generalidad es un principio fundamental si se tiene como
objetivo el desarrollo de herramientas generales o paquetes para el mercado,
ya que para ser exitosas debern cubrir las necesidades de distintas personas.
Estos productos de propsito general, off-the-shelf, por ejemplo los
procesadores de texto, representan una tendencia general en el software; para
cada rea especfica de aplicacin existen paquetes generales que proveen
soluciones estndares a problemas comunes que evitan de esta forma una
solucin especializada.
Acrecentamiento. Caracteriza un proceso en el que se procede de manera
gradual o incremental. Las metas se alcanzan mediante aproximaciones
sucesivas en el que cada aproximacin es un incremento de la anterior. Una
manera de aplicar este principio es identificando elementos tiles de una
aplicacin para desarrollarlos y entregarlos al cliente para obtener una
retroalimentacin ms rpida. Este principio se fundamenta diciendo que en la
prctica es poco probable que se cuenten con todos los requerimientos antes
de que se inicie el desarrollo de la aplicacin y que estos van surgiendo
conforme se van presentando los avances de la aplicacin, por esto entre ms
se vayan presentando partes de la aplicacin y al obtener la retroalimentacin
del cliente ser ms fcil incorporar los cambios al proyecto.
2.5 Herramientas CASE
Un CASE (Computer-Aided Software Engineering) es una herramienta que
permite organizar y controlar el desarrollo de software. Se utiliza especialmente
en desarrollos de software largos que implican una mayor complejidad por la
cantidad de componentes y personas involucradas. Este tipo de herramientas
soporta los mtodos y conceptos de programacin.
29
Entre las ventajas que se pueden encontrar al utilizar las herramientas CASE
podemos encontrar:
Generacin de una vista comn entre todos los integrantes para cada
una de las fases del desarrollo de software.
Repositorio de los entregables en cada una de las fases.
Organizacin
Reduccin de costos
Aseguramiento de la calidad.
Registro y presentacin el avance del proyecto.
Reduccin del tiempo de procesamiento para el anlisis.
Automatizacin de algunas actividades dentro del proceso de desarrollo.
Incremento de la productividad y la confiabilidad en el proceso de
produccin.
A continuacin se presenta una clasificacin de las herramientas.
Medio de interaccin. La interaccin del usuario con las herramientas ha
evolucionado de manera que stas sean ms intuitivas y fciles de usar para
reducir de esta forma los errores. Un aspecto importante a considerar en la
interaccin con las computadoras es la sintaxis en los lenguajes de
programacin, ya que permite la adopcin del lenguaje y reduciendo los errores
en su uso.
Nivel de formalidad. En el desarrollo de software se ven involucrados varios
tipos de documentos. En cada uno de ellos se puede definir en algn grado la
sintaxis y la semntica. Mientras un compilador se encuentra definido de
principio con una sintaxis y semntica formalmente definidas, el editor puede
emplearse para cualquier lenguaje.
Dependencia en la fase del ciclo de vida. Existen herramientas de software que
se encuentran ligadas a actividades especficas dentro del ciclo de vida del
30
software. La adopcin de herramientas permite una transicin entre las fases
segn sea el modelo que se haya seleccionado.
Dependencia en la aplicacin o mtodo. La seleccin de tcnicas, mtodos,
modelo de ciclo de vida y cualidades, pueden verse influidas por las
aplicaciones. Muchos mtodos pueden ser ms efectivos empleando una
adecuada herramienta de soporte. Las herramientas pueden mejorar el mtodo
pero no pueden sustituirlo. De igual forma la calidad en el software no se puede
mejorar slo utilizando herramientas sin comprender su significado dentro de la
metodologa.
Grado de estandarizacin. Por una parte la estandarizacin mejora su
aplicabilidad pero por otra parte detiene su evolucin. Sin embargo, la
estabilizacin de un mtodo o lenguaje garantiza el soporte que se le da y
tambin posibilita la opcin de seguir utilizndolo en varios proyectos a la
gente que lo utiliza.
Dependencia del lenguaje. Existen herramientas que se encuentran ligadas a
un lenguaje y existen otras que soportan varios. Dentro de las primeras se
encuentran los compiladores, que son especializados en un lenguaje de
programacin. Mientras que un procesador de palabras puede ser utilizado
para editar cualquier lenguaje de programacin.
Herramientas estticas contra herramientas dinmicas. Hay herramientas que
no requieren de la ejecucin del objeto que emplea. Son utilizadas para crear,
modificar, verificar la consistencia con respecto a una regla, medir ciertas
propiedades estticas o para detectar algunas restricciones. A estas
herramientas se les denominan estticas. Las herramientas dinmicas son las
que requieren de la ejecucin del objeto.
Herramientas de desarrollo contra componentes de producto final. Algunas
herramientas se emplean para el desarrollo del producto final sin llegar a ser
31
parte de l. Mientras que otras herramientas de componentes de software
pueden ser incluidas y llegar a ser parte del producto final.
Bibliografa del tema 2
Ghezzi, Carlo. Fundamentals of Software Engineering. Englewood Cliffs,
Prentice-Hall, 2003.
ISO/IEC. Information Technology Software Product Quality. International
Standard 9126:2000(E), 2000.
32
Actividades de aprendizaje
A.2.1. Elabora un cuadro en el que se presenten las caractersticas comunes
en cada una de las clasificaciones del software.
A.2.2. Investiga dos modelos de calidad y registra las caractersticas de calidad
que propone cada una.
A.2.3. Realiza una lista en la que se detalle los beneficios de las herramientas
CASE en desarrollos pequeos.
A.2.4. Realiza una investigacin y encuentra otro de los principios de IS
diferente a los expuestos en este tema. Registra la justificacin y fuente
de la informacin.
A.2.5. Realiza una investigacin y registra dos ejemplos de herramienta CASE
con sus respectivas caractersticas.
Cuestionario de autoevaluacin
1. Cul es la definicin de software que consideras ms adecuada?, justifica
tu respuesta.
2. Por qu resulta difcil obtener una definicin de software?
3. Cul es la finalidad de los principios de IS?
4. Menciona tres caractersticas del software?
5. Cul es el significado de la palabra CASE?
6. Menciona los principios de IS que se vieron en este tema?
7. Cul es la finalidad de las herramientas CASE?
8. En qu clasificacin de software entraran las herramientas CASE?
9. A qu nivel se encuentran planteados los principios de IS?
10. En qu tipo de desarrollos de software son comnmente utilizadas las
herramientas CASE?
33
Examen de autoevaluacin
Instrucciones. Relaciona las dos columnas colocando la letra de la columna
derecha dentro de los parntesis de la columna izquierda.
1. ( ) Son puntos de referencia
generales para desarrollar software
de calidad.
a) Nivel de formalidad
2. ( ) Es una herramienta que se
puede utilizar durante el proceso de
desarrollo de software.
b) Eficiencia
3. ( ) Es software que define el grado
de sintaxis o semntica.
c) Definicin de software
4. ( ) No requiere de la ejecucin del
objeto para realizar sus funciones.
d) Principios IS
5. ( ) Automatiza algunas actividades
dentro del proceso de desarrollo.
e) CASE
6. ( ) Capacidad de proporcionar
desempeo adecuado con respecto
a los recursos utilizados en un
momento determinado.
f) Herramientas estticas
7. ( ) Conjunto de algoritmos
ejecutados en una computadora.
g) Ventaja CASE
8. ( ) Software que tiene la finalidad de
que la computadora se convierta en
una herramienta para algunas de las
actividades que realiza el usuario
final.
h) Software por funcin o de
aplicacin
9. ( ) Software ligado a uno o varios
lenguajes.
i) Funcionalidad
10. ( ) Capacidad para desempear las
funciones acordadas en condiciones
especficas
j) Dependencia del lenguaje
34
TEMA 3. ADMINISTRACIN DE PROYECTOS
Objetivo particular
Al finalizar este tema el alumno conocer la importancia y caractersticas de un
proyecto dentro del desarrollo de software y tambin conocer una de las
propuestas existentes para mejorar el trabajo de manera individual.
Temario detallado
3.1 Qu es un proyecto?
3.2 Ciclo de vida del proyecto
3.3 Oficina de proyectos
3.4 PSP
Introduccin
La forma de trabajo dentro del desarrollo se identifica con un proyecto, por eso
resulta importante conocer las caractersticas de un proyecto junto con los
diferentes recursos que se encuentran disponibles para que un proyecto
alcance los objetivos establecidos.
3.1 Qu es un proyecto?
Un proyecto es un esfuerzo temporal emprendido para crear un producto,
servicio o resultado nico. Esta estructura de trabajo es ampliamente utilizada y
no es de uso exclusivo del desarrollo de software. Sus caractersticas nos
permiten identificarlo y es por eso que se presentan a continuacin.
Temporal. Se refiere a que cada proyecto tiene un inicio y un final definidos. El
final se alcanza una vez que se cumplen los objetivos. La duracin del tiempo
proyecto es finito.
35
La naturaleza temporal de los proyectos se relaciona tambin con cuestiones
como:
La oportunidad o ventana del mercado tiene un lapso de duracin determinado.
El equipo trabaja como unidad durante el periodo que dura el proyecto para
posteriormente reasignar a los recursos una vez que el proyecto ha finalizado.
Productos, servicios o resultados nicos. Un proyecto genera entregables
nicos.
Un producto o artefacto realizado es cuantificable y puede ser l mismo un
elemento final o parte de otro elemento. El hecho de que los elementos se
encuentren de manera repetida no cambia que el trabajo de un proyecto sea
nico.
Confeccin progresiva. Significa que el desarrollo se realiza por pasos y en su
continuacin se realiza por incrementos. La elaboracin progresiva del proyecto
necesita ser coordinada con el alcance.
Un proyecto se diferencia del trabajo operativo en que este ltimo se mantiene
funcionando de manera repetida, mientras que un proyecto se opera de
manera temporal y nica. Otra diferencia se encuentra en que los objetivos, los
proyectos estn sujetos a los objetivos planteados y una vez alcanzado dichos
objetivos el proyecto finaliza, mientras que en la operacin los objetivos se
encuentran en relacin con el sostn del negocio, los cuales pueden cambiar o
definir nuevos, pero el trabajo contina.
Los proyectos son empleados principalmente como medio para alcanzar un
plan estratgico de una organizacin.
36
Un proyecto puede ser el resultado de alguno de los siguientes escenarios:
Demanda del mercado
Necesidad organizacional
Solicitud de un cliente
Ventaja tecnolgica
Disposicin legal
La administracin de proyectos es la aplicacin de conocimientos,
herramientas, habilidades y tcnicas a las actividades del proyecto para cumplir
con los requerimientos del mismo. Los procesos de la administracin de
proyectos comprenden cinco grupos: inicio, planificacin, ejecucin, monitoreo
y control y cierre. Estos grupos no representan las fases de un proyecto, sino
que es una forma de agrupar las reas de conocimiento que se pueden utilizar.
En un proyecto se debe de realizar el balanceo entre la calidad, el alcance, el
tiempo y el costo. En este esquema comnmente se dice que de los cuatro
elementos mencionados anteriormente la calidad se ve influenciada por los
otros tres.
Dentro de algunas de las causas por las cuales fracasan los proyectos se
encuentran:
1. El usuario no sabe lo que quiere (o nosotros no lo entendemos?).
2. Requerimientos y especificaciones incompletos.
3. Cambio en los requerimientos y especificaciones.
4. Carencia de participacin por parte del usuario.
5. No existe documentacin.
6. Falta de una metodologa para la gestin de requisitos.
37
3.2 Ciclo de vida del proyecto
Se puede dividir los proyectos en fases con la finalidad de tener un mejor
control con las apropiadas conexiones a las operaciones que realiza la
organizacin. El conjunto de fases es conocido como ciclo de vida del proyecto.
Las organizaciones identifican los ciclos de vida que aplican a todos sus
proyectos.
Un ciclo de vida define las fases que se emplearn desde el inicio hasta el final
del proyecto. La definicin del ciclo de vida del proyecto le permite al
administrador de proyecto en dnde colocar cada una de las fases. La
transicin entre fases involucra generalmente una transferencia tcnica. Los
productos de una fase son revisados antes de comenzar con las actividades de
la fase que contina. Aunque no es extrao que una fase inicie sus actividades
sin haber aprobado previamente los entregables de la fase anterior cuando los
riesgos involucrados son aceptables.
Cada organizacin puede establecer slo un ciclo de vida para todos los
proyectos o puede dar la libertad al administrador de proyecto que elija el ciclo
de vida.
En los ciclos de vida de proyectos generalmente se define:
Las actividades tcnicas que se llevarn a cabo en cada una de las
fases.
La fecha de entrega de los productos de cada fase y la manera en la
que sern revisados, verificados y validados.
Los involucrados en cada fase.
El control y mejora de cada fase.
A un nivel muy detallado del ciclo de vida se incluyen los formatos, polticas,
listas de verificacin, etc.
38
Algunas caractersticas que se pueden encontrar en los ciclos de vida de
proyectos son:
Las fases comnmente son secuenciales y son definidas por la
transferencia de informacin o por algn componente.
El costo y el personal involucrado son bajos al inicio, en las fases
intermedias aumentan para disminuir al final.
El nivel de incertidumbre se encuentra en la fase inicial; va
desapareciendo conforme se avanza en el proyecto.
La influencia de los clientes en las caractersticas y costos del proyecto
se presentan al principio para disminuir durante el desarrollo. Mientras
que los costos asociados a los cambios y las correcciones aumentan
conforme se avanza en el proyecto.
La realizacin y aprobacin de productos es lo que identifica a una fase. Un
producto es algo que puede ser medido y verificado. Los productos pueden ser
tanto propios del mismo proceso de administracin del proyecto como un
elemento del producto final. Los productos y las fases son parte de un proceso
secuencial diseado para asegurar el control del proyecto para logar el
producto o servicio.
Una fase generalmente finaliza cuando el trabajo y los productos son revisados
para determinar su aceptacin. Completar una fase no incluye la autorizacin a
la siguiente fase. Existe una dependencia entre cada fase que indica los
resultados que son permitidos y esperados de uno a otro. Con una revisin final
de la fase se obtiene la autorizacin para cerrar una fase y abrir la siguiente.
3.3 Oficina de proyectos
Tambin se conoce como PMO (Project Management Office), es una unidad
organizacional que centraliza y organiza la administracin de proyectos bajo su
dominio. Supervisa la administracin de proyectos, programas o la combinacin
39
de ambos. Algunos PMO coordinan y administran proyectos relacionados. En
muchas organizaciones esos proyectos se encuentran realmente agrupados u
organizados de manera que el PMO pueda administrar y coordinar esos
proyectos.
El PMO se enfoca en la planificacin coordinada, priorizacin y ejecucin de
proyectos y subproyectos que se encuentran ligados a los objetivos de negocio
de la organizacin o clientes.
Algunas de las actividades que realiza el PMO son:
Coordinar todos los recursos de los proyectos que tiene a su cargo.
Identificar y desarrollar la metodologa para la administracin de
proyectos, y con ello todas las tcnicas, estndares, polticas, etc.
Centralizar la administracin de la configuracin de todos los proyectos.
Centralizar el repositorio y la administracin de todos los riesgos, tanto
especficos como compartidos entre los proyectos.
Centralizar la administracin y operacin de las herramientas utilizadas
para los proyectos.
Coordinar de manera centralizada la comunicacin entre los proyectos.
Coordinar todos los estndares de calidad entre los estndares internos
y los organismos de estandarizacin.
Alinear los objetivos de los proyectos a los de la organizacin.
3.4 PSP
PSP (Personal Software Process)
La calidad del software comienza por los individuos. El propsito es mejorar al
ingeniero de software. Los elementos se presentan de manera que se pueda
hacer uso de ellos segn sean requeridos, es por ellos que se plantean las
tcnicas que posteriormente pueden ser aplicadas a mtodos y herramientas.
Los recursos son para quien disea, desarrolla, documenta o realiza
40
mantenimiento de software. Es una sugerencia sobre lo que se tiene que
mejorar y cmo hacerlo.
Este proceso incluye una administracin efectiva de defectos y mtodos de
planificacin, seguimiento y anlisis. Todo esto para ser aplicado a desarrollos
de programas pequeos y grandes. Los datos histricos permiten hacer
desarrollos ms predecibles y eficientes.
En los desarrollos de gran tamao se requiere un manejo exitoso de los
equipos de trabajo. El proceso de software es un conjunto de pasos para
realizar el desarrollo y mantenimiento de software, estableciendo lineamientos
que le indican al ingeniero de software la manera en la que se debe trabajar.
De esta manera se puede coordinar los trabajos de cada uno de los integrantes
y dar seguimiento a su desarrollo.
El establecimiento de un proceso no es solamente la definicin de tcnicas y
prcticas, sino que debe de estar fundamentado en la necesidad de cambio.
Los desarrollos a gran escala se vuelven complejos, es por ello que el marco
de madurez de procesos de software fue desarrollado. De esta forma se
organiza para determinar las capacidades del proceso actual y establecer
prioridades de mejora. A travs de cinco niveles se representa progresivamente
la madurez del proceso.
1. Inicial
2. Repetible
3. Definido
4. Administrado
5. Optimizado
El progreso en PSP cuenta con las siguientes fases de procesos de mejora:
PSP0: proceso base
41
PSP1: proceso de planificacin personal
PSP2: proceso de administracin personal de calidad
PSP3: proceso personal cclico
PSP es diseado para ser un CMM
12
(Capability Maturity Model) a nivel
individual.
PSP ensea a los ingenieros a:
Administrar la calidad de sus proyectos.
Hacer compromisos que se puedan cumplir.
Mejorar estimaciones y planificaciones.
Reducir los defectos en sus productos.
El personal constituye gran parte de los costos del desarrollo de software, las
habilidades de los ingenieros determinan considerablemente los resultados del
proceso de desarrollo de software. PSP puede ser usado por ingenieros como
gua o como un disciplinado y estructurado acercamiento al desarrollo de
software. PSP es un prerrequisito para una organizacin que pretende
introducir TSP (Team Software Process).
PSP puede ser incluida en muchas partes del proceso de desarrollo de
software, incluyendo:
Desarrollo de pequeos programas.
Definicin de requerimientos.
Elaboracin de documentos.
Pruebas de sistemas.
Mantenimiento de sistemas.
Mejora de grandes sistemas de software.
12
Este modelo se aborda en el tema diez.
42
Aunque las prcticas de PSP eran posibles y daban resultados, era casi
imposible mantener la disciplina de las prcticas si el ambiente circundante no
los animaba y exiga. Por esto Humphrey present TSP para unidades
pequeas de desarrollo.
Bibliografa del tema 3
Humphrey, Watts S. A discipline for software engineering. Mexico City,
Addison-Wesley, 1995.
PROJECT MANAGEMENT INSTITUTE. Project Management Body of
Knowledge. Pennsylvania, PMI, 2004.
43
Actividades de aprendizaje
A.3.1. Realizar una investigacin que identifique las causas por las cuales
fracasan los proyectos de desarrollo de software y realizar un informe.
A.3.2. Realizar un esquema en el que se identifiquen las fases ms comunes
de un proyecto y las actividades asociadas a cada una.
A.3.3. Realizar un reporte con tres ejemplos de herramientas de software que
se puedan emplear en alguna parte del ciclo de vida de proyectos.
A.3.4. Elaborar un cuadro comparativo de los problemas ms comunes entre
desarrollos pequeos y los de gran escala.
A.3.5. Realizar una propuesta con los elementos expuestos en este tema para
un rea de desarrollo con cuatro personas.
Cuestionario de autoevaluacin
1. Cul sera la funcin principal de una oficina de proyectos?
2. Qu significa PSP?
3. Qu es el ciclo de vida de proyectos?
4. Qu es un proyecto?
5. A qu nivel puede ser empleado el PSP dentro del proceso de desarrollo?
6. Qu elementos puede definir un ciclo de vida de proyectos?
7. Quin define las fases que debern de llevarse a cabo del inicio al final de
un proyecto?
8. En qu difiere un proyecto al trabajo operativo?
9. Cul es la finalidad de dividir el proyecto en fases?
10. A qu tipo de proyectos se puede emplear el PSP?
44
Examen de autoevaluacin
Instrucciones. Escribe en la columna de la derecha la letra V (verdadero) o F
(falso) segn corresponda al enunciado
No. Enunciado V o F
1. Un proyecto es un esfuerzo temporal emprendido para crear un
producto, servicio o resultado nico.
2. Los procesos de administracin de proyectos son los mismos que
las fases de un proyecto.
3. La oficina de proyectos define los productos a entregar en cada
fase.
4. La oficina de proyectos se encarga de alinear los proyectos a los
objetivos del cliente o de la organizacin.
5. El ciclo de vida de proyectos coordina la comunicacin entre
proyectos.
6. Una de las funciones de la oficina de proyectos es establecer la
metodologa de la administracin de proyectos.
7. Una disposicin legal es una fuente para generar un proyecto.
8. PSP slo es para desarrollo a gran escala.
9. PSP es una propuesta para grupos de desarrollo.
10. PSP slo puede utilizarse en una parte dentro del proceso de
desarrollo de software.
45
TEMA 4. ADMINISTRACIN DE REQUERIMIENTOS
Objetivo particular
Al finalizar este tema el alumno conocer la importancia de los requerimientos
para un proyecto de software, la forma en la que se clasifican y las tcnicas
para recolectarlos dentro del proceso de requerimientos.
Temario detallado
4.1 Qu es un requerimiento?
4.2 Clasificacin de requerimientos
4.3 FURPS y FURPS+
4.4 Buenos y malos requerimientos
4.5 Tcnicas de recopilacin de requerimientos
4.6 Modelo general
4.7 El modelo de RUP
Introduccin
La definicin de requerimientos es la primera actividad realizada dentro del
proceso de desarrollo y los proyectos se encuentran vulnerables cuando estas
actividades estn poco desarrolladas. Su relacin con las dems fases del
desarrollo de software es muy cercana porque con base en los requerimientos
se definirn las actividades a desarrollar.
4.1 Qu es un requerimiento?
Un requerimiento describe una condicin o capacidad que un sistema debe de
cumplir, derivados de las necesidades del usuario, por contrato, estndares,
especificaciones o cualquier otro documento formalmente establecido.
46
Un requerimiento es definido como una propiedad que debe de ser exhibida
con la finalidad de resolver algn problema del mundo real.
Los requerimientos de software expresan las necesidades y restricciones
colocadas a un producto de software que contribuye a la solucin de un
problema del mundo real. Una propiedad esencial de un requerimiento es que
se pueda verificar.
Por lo general los requerimientos para un software en particular es una
compleja combinacin de requerimientos de diferentes personas con diferentes
niveles dentro de una organizacin y con un ambiente diferente en el cual se
operar.
Existen otros requerimientos que representan propiedades emergentes, las
cuales no pueden ser consideradas como slo un elemento sino que depende
del buen funcionamiento entre los otros elementos.
Requerimiento: Condicin o capacidad que el sistema debe cumplir.
Necesidad que se debe cubrir.
Constituyen la definicin del sistema que se va a construir o mejorar
Para que algo sea un requerimiento:
Debe ser solicitado formalmente
Debe ser documentado
Debe ser analizado formalmente para verificar el impacto en el proyecto
Debe ser aprobado
La palabra requerimientos significa diferentes cosas para diferentes personas
47
Para un ejecutivo puede ser un concepto de producto de alto nivel desde
el punto de vista del negocio.
Para un cliente puede ser una lista de ideas o soluciones propuestas.
Para un desarrollador puede ser una interfaz grfica.
Los requerimientos son descripciones de cmo debera comportarse el sistema
o una propiedad o atributo de un sistema. Tambin deben delimitar el proceso
de desarrollo y al sistema.
La redaccin de los requerimientos se debe de realizar de tal manera de que
sea fcil de entender para los lectores y sobre todo cuando se trata de
personas que no tienen relacin con los sistemas informticos. Tambin se
tiene que tener en cuenta el ambiente en el cual operar y su adecuacin a los
estndares y de ms lineamientos establecidos, lo que significa que existen
otras fuentes para los requerimientos.
4.2 Clasificacin de requerimientos
De manera tradicional, existe la clasificacin que se hace de requerimientos de
dos tipos:
Requerimientos funcionales los cuales especifican funciones que el sistema
debe ser capaz de realizar, sin tomar restricciones fsicas a considerar.
Requerimientos no funcionales los cuales describen atributos del sistema o
atributos del ambiente del sistema. Tambin son conocidos como de
delimitacin o de calidad.
QFD (Quality Function Deployment) es una tcnica de administracin de
calidad que traslada las necesidades del cliente en requerimientos tcnicos de
software. Desarrollada y utilizada por primera vez en Japn por Mitsubishi
Heavy Industries a principio de la de la dcada de 1970. QFD enfatiza lo que es
48
realmente valioso para el cliente y lo pone en el proceso de ingeniera. Se
identifican tres tipos de requerimientos:
Requerimientos normales. Las metas y objetivos son establecidos
durante las reuniones con el cliente. Si los requerimientos se presentan
entonces el cliente se encuentra satisfecho.
Requerimientos esperados. Estos requerimientos son implcitos del
producto y es posible que el cliente no los establezca. Su ausencia
puede ser la causa de insatisfaccin en el cliente.
Requerimientos extra. Son caractersticas que van ms all de las
expectativas del cliente provocando una mayor satisfaccin cuando se
presentan.
4.3 FURPS y FURPS+
Son factores de calidad de software generado por Hewlett-Packard bajo el
acrnimo formado de las palabras en ingls (Functionality, Usability, Reliability,
Performance, Supportability). Slo describen que pueden ser utilizados para
establecer mtricas de calidad dentro del proceso de ingeniera del software.
Funcionalidad. Evala el conjunto de caractersticas y capacidades del
programa, la generalidad de las funciones que han sido entregadas y la
seguridad de todo el sistema.
Facilidad de uso. Considera factores humanos, estticos, consistencia y
documentacin.
Confiabilidad. Mide la frecuencia y severidad de las fallas, la exactitud de los
resultados, la capacidad de recuperacin de fallas y pronstico del programa.
Desempeo. Mide la velocidad de procesamiento, tiempo de respuesta,
consumo de recursos, rendimiento y eficiencia.
49
Soporte. Combina la capacidad del programa en expansin, adaptacin,
mantenimiento, servicio, pruebas, compatibilidad, configuracin, facilidad de
instalacin y la facilidad para localizar los problemas.
El modelo FURPS+ es una extensin a la que se le adicionan los siguientes
elementos:
Diseo. Especifica o restringe el diseo de un sistema.
Implementacin. Especifica la construccin o codificacin de un sistema con
estndares, lenguajes, polticas de integracin de base de datos, lmites de
recursos y ambientes de operacin.
Interfaz. Elementos de interaccin con el sistema, restricciones de tiempo y
formato.
Fsicos. Establece la caracterstica material, forma, peso y tamao.
4.4 Buenos y malos requerimientos
Una manera de realizar una buena obtencin de requerimientos implica la
utilizacin de tcnicas repetibles y sistemticas para asegurar que los
requerimientos del sistema sean completos, consistentes, relevantes, etc.
Tambin implica cubrir las actividades relacionadas con el descubrimiento,
documentacin y mantenimiento de los requerimientos.
Los atributos individuales a considerar para un buen requerimiento seran:
Correcto. Cualidad que slo puede ser asegurado por el cliente o
usuario.
50
Posible (factible). Cualidad que requiere conocimiento de parte del rea
de desarrollo, herramientas disponibles, tcnicas, gente y presupuesto
que posibilite la satisfaccin final del requerimiento.
Necesario. Cualidad que puede ser determinada entre el cliente y el
desarrollador en la obtencin de requerimientos, con la finalidad de
establecer los requerimientos a entregarse para esa versin.
Priorizado. Cualidad determinada entre usuario y desarrollador para
establecer en cada requerimiento un nivel de prioridad como: muy
importante, absolutamente necesario, importante para la siguiente
liberacin y opcional.
Claro. Cualidad que se refiere a que slo puede tener un significado;
fcil para leer y entender.
Conciso. Que contenga la informacin necesaria para continuar con el
desarrollo. Asociando historia, costos, programacin, tareas, productos,
etc.
Verificable (probado, medido). Cualidad que significa que una persona o
mquina puede revisar si el software cubri los requerimientos.
Como conjunto, la especificacin de requerimientos de software debera de
contar con las siguientes caractersticas:
Completo. Cualidad que puede ser asegurada por el cliente revisando
que todos los requerimientos significativos se encuentran incluidos
(funcionales, desempeo, externos, etc).
Consistente. Cualidad que el desarrollador asegura entre los
documentos internos.
Modificable. El cambio en los requerimientos es algo normal.
Rastreable. Cualidad compartida entre cliente y desarrollador en la que
el requerimiento establecido puede seguirse desde su establecimiento
hasta su entregable como software.
Los problemas que se presentan al momento de obtener requerimientos:
51
Afectados que saben lo que quieren pero no pueden expresarlo.
Afectados que pueden no saber lo que quieren.
Afectados que saben lo que quieren hasta que usted les da lo que ellos
decan que queran.
Analistas que piensan que entienden los problemas de los usuarios
mejor que los usuarios.
Un requerimiento no es:
Una solicitud informal de alguien en una reunin, un pasillo o un
elevador o una llamada telefnica
Solicitudes de clientes por medio de encuestas, correos electrnicos o
buzones de sugerencias
Observaciones o comentarios durante reuniones de ventas o mercadeo
Un requerimiento documentado nos permite
Llegar a un acuerdo con el cliente de lo que el sistema debe hacer.
Identificar quin interactuar con el sistema.
Identificar la interfaz que el sistema debe tener.
Ayudar a verificar que no faltan requerimientos.
Verificar que los desarrolladores entienden los requerimientos.
Facilitar el acuerdo con el cliente de los requerimientos del sistema.
Utilizar terminologa que el usuario entiende.
Verificar el entendimiento del desarrollador del sistema.
Identificar el rol de los usuarios del sistema.
Identificar la interfaz del sistema.
Ayudar a verificar que todos los requerimientos sean capturados.
52
4.5 Tcnicas de recopilacin de requerimientos
Existen diferentes formas de obtener los requerimientos. Cada una de las
tcnicas nos permite obtener los requerimientos desde un punto de vista en
particular. Es posible que las personas involucradas les sea ms fcil expresar
de manera ms clara sus requerimientos con alguna tcnica ms que con otra.
Es responsabilidad del analista de requerimientos establecer la tcnica que
utilizar. No hay nada que pueda restringir el uso de ms de una tcnica, todo
eso quedar a juicio del analista de requerimientos.
Entrevistas. Es la tcnica que comnmente se emplea para obtener los
requerimientos. El ingeniero de requerimientos o el analista discuten el sistema
con los clientes y construyen los requerimientos. Existen bsicamente dos tipos
de entrevistas:
Las entrevistas cerradas en donde el ingeniero de requerimientos busca
las respuestas de conjunto de preguntas predefinidas.
Las entrevistas abiertas en estas no existe una agenda predefinida y el
ingeniero de requerimientos discute de manera abierta con los
involucrados acerca del sistema.
No existe realmente una limitante para emplear alguna de las dos entrevistas e
incuso se pueden llegar a combinar en un momento determinado. Esta tcnica
puede facilitar a los involucrados a que expresen sus problemas y dificultades
en su trabajo. Pero tambin puede generar en el usuario una expectativa poco
realista sobre el sistema. Por otra parte puede quedar inconclusa la
identificacin del dominio del sistema y las cuestiones organizacionales que
afectan los requerimientos.
Hay dos puntos esenciales para una entrevista efectiva:
El entrevistador debe de ser de mente abierta y de buena disposicin
para escuchar a los involucrados.
53
Los involucrados deben de proporcionar algn punto de partida para la
discusin.
El conocimiento de las aplicaciones es difcil de obtener durante las entrevistas
porque:
Muchas aplicaciones cuentan con su propia terminologa y a muchos de
los involucrados les resulta difcil discutir sobre ella si no utilizan esa
terminologa.
Existen conocimientos sobre la aplicacin en los cuales al involucrado le
resulta difcil explicar o le resulta familiar que nunca se lleg a pensar en
explicarlo.
Mtodos ligeros de sistemas. Son modelos flexibles enfocados a producir
modelos menos formales del conjunto tcnico-social de un sistema. Consideran
la automatizacin del sistema, la gente y la organizacin.
Varios de esos mtodos han sido incluidos en SSM (Soft Systems
Methodology), ETHICS y Easons User-Centred Design.
SSM y otros mtodos no son tcnicas como tal para obtener requerimientos de
manera detallada. Su aporte radica principalmente en hacer mucho ms
entendible el problema, la situacin organizacional en donde existe el problema
y las restricciones para la solucin del problema.
Observacin y anlisis social. El trabajo es una actividad social que involucra
grupos de gente que cooperan realizando diferentes tareas. La naturaleza de la
cooperacin es compleja y variada dependiendo de la gente involucrada, el
ambiente y la organizacin en la que se realiza el trabajo. A los individuos y
equipos les resulta difcil explicar la forma en la que trabajan y cooperan. El
trabajo y sus mejoras muchas veces se realizan de manera intuitiva.
54
En ocasiones la observacin es la mejor forma de entender una tarea que el
cuestionamiento directo. Cientficos sociales y antroplogos han utilizado la
tcnica de observacin pasiva por largos periodos de tiempo para desarrollar
un completo y detallado entendimiento de varias culturas.
Aplicando esta tcnica a la obtencin de requerimientos se presentan las
siguientes guas:
Asumir que la gente que se est estudiando es buena realizando su
trabajo.
Invertir tiempo conociendo a la gente involucrada y estableciendo una
relacin.
Realizar notas detalladas del trabajo durante las observaciones.
Entrevistas abiertas en donde la gente pueda hablar de su trabajo.
Mantener la utilizacin de registro de video y audio al mnimo.
Sesiones cortas para hablar del trabajo con la gente fuera del proceso
puede identificar elementos crticos en el trabajo.
Esta tcnica deber ser utilizada como apoyo a la obtencin de requerimientos.
Escenarios. A los usuarios finales les resulta ms fcil realizar ejemplos en la
vida real que realizar descripciones abstractas de un sistema. Por eso, que
resulta conveniente utilizar escenarios de interaccin entre el usuario y el
sistema. De esta manera al momento de que el usuario simula la interaccin es
posible describir las tareas o funciones que desea.
Incluso el desarrollo de escenarios sin la interaccin del usuario proporciona
informacin para los requerimientos. Descubrir los escenarios expone las
posibles interacciones que puede tener el sistema. En algunos mtodos de
anlisis orientado a objetos los escenarios son una parte bsica. Los
escenarios pueden ser pensados como un relato de la manera en que un
sistema es utilizado. Proporcionan informacin adicional a los requerimientos.
55
Se pueden elaborar escenarios de diferente forma pero como mnimo debern
contener la siguiente informacin:
Una descripcin del estado del sistema antes de iniciar el escenario
Un flujo normal de eventos en el escenario
Excepciones al flujo normal de eventos
Informacin de otras actividades que pueden realizarse en paralelo
Una descripcin del estado del sistema al finalizar el escenario
La aplicacin de escenarios involucra el trabajo en conjunto del ingeniero de
requerimientos y el usuario final. De esta interaccin surgen comentarios,
problemas, sugerencias, maneras de realizar las actividades, involucrados,
alternativas ante acciones inesperadas, etc.
Reutilizacin de requerimientos. Es una buena prctica para sistemas e
ingeniera de software la reutilizacin del conocimiento para un nuevo sistema.
A pesar de que existen diferentes requerimientos para cada sistema, existen
situaciones en las cuales es posible realizar la reutilizacin de los
requerimientos.
Requerimientos relacionados que proporcionan informacin acerca de la
aplicacin: son requerimientos que ms que ver con la funcionalidad,
tiene que ver con las restricciones u operaciones que se derivan de la
aplicacin.
Requerimientos relacionados con la presentacin de la informacin: es
posible tener una interfaz consistente para todos los sistemas para las
organizaciones.
Requerimientos relacionados con las polticas de una organizacin.
56
FAST (Facilitated Application Specification Techniques). Su intencin es
conformar un grupo de trabajo con clientes y desarrolladores que trabajan
juntos para identificar el problema, proponer elementos de solucin, negociar
diferentes acercamientos y especificar un conjunto preliminar de
requerimientos.
Tambin podemos encontrar otro tipo de tcnicas para la obtencin de
requerimientos.
Cuestionarios
JAD (Joint Application Development)
Mapas mentales
Casos de uso
Lluvia de ideas
Prototipos
Talleres de requerimientos
Bosquejos
Actuacin de roles
4.6 Modelo general
Para comprender el proceso de requerimientos se debe tomar en cuenta que:
No es una actividad discreta en el ciclo de vida del software. Comienza
junto con el proyecto y contina refinndose durante el ciclo de vida.
Identifica los requerimientos de software como elementos de
configuracin y se administran con las mismas prcticas de
administracin de la configuracin al igual que otros productos de los
procesos del ciclo de vida.
Necesita adaptarse a la organizacin y al contexto del proyecto.
57
Una manera de llevar a cabo un manejo adecuado de los requerimientos es a
travs de un proceso de requerimientos. Un proceso de este tipo debe de
incluir las siguientes actividades:
Obtencin de requerimientos. Los requerimientos son descubiertos a
travs de los usuarios, clientes, documentos del sistema, experiencia y
estudios de mercado.
Negociacin y anlisis de requerimientos. Los requerimientos son
analizados en detalle a travs de un proceso formal de negociacin en el
que participen diferentes involucrados para decidir la aceptacin de los
requerimientos.
Validacin de requerimientos. Se debe realizar una revisin cuidadosa
de los requerimientos para que se encuentren completos y consistentes.
4.7 El modelo de RUP
IBM RUP (Rational Unified Process), es un proceso de desarrollo de
software que provee las mejores prcticas que pueden aplicarse dentro de esta
rea. Es uno de los muchos procesos dentro del Rational Process Library. Su
objetivo es asegurase de producir software de alta calidad.
El UP (Unified Process) es el resultado de varias dcadas de desarrollo. De ella
se pueden encontrar los siguientes puntos importantes en su historia:
Sus inicios datan de 1967 cuando Ericsson model un sistema completo
con un conjunto interconectado de bloques. Ensamblando los niveles
ms bajos dentro de los ms altos para tener una mejor administracin
del sistema. En esta fase se identificaron los casos de uso y una primera
representacin de lo que seran los diagramas de colaboracin y de
transicin de estados.
En 1987 Ivar Jacobson deja Ericsson y se establece en Objectory AB en
Estocolmo. Trabaj junto con sus asociados en el proceso Objectory y
produjo las versiones 1.0 en 1988 a la 3.8 en 1995. Este producto fue
58
visto como un sistema, permitiendo hacer nuevas versiones que
permitan ajustarse a las necesidades particulares.
Rational Software Corporation adquiri Objectory AB en 1995. Surgi la
necesidad de unificar los principios de los distintos procesos de
desarrollo y Rational haba desarrollado varias prcticas de desarrollo de
software. En donde las contribuciones ms notables fueron el nfasis en
la arquitectura y el desarrollo iterativo. UML (Unified Modeling Language)
fue desarrollado y utilizado como lenguaje de modelado del ROP 4.1
(Rational Objectory Process).
Rational adquiri ms compaas de software y con ello ms experiencia
en los procesos de software para ser aplicados en el ROP. Se ingres
un flujo de trabajo para el modelado de negocios. Se expandi el diseo
de las interfaces del usuario empleando casos de uso. Para 1998 el
ROP poda ser aplicado para todo el ciclo de vida de desarrollo de
software. Con las diversas contribuciones realizadas Rational liber el
RUP 5.0 (Rational Unified Process). Su nombre refleja la unificacin en
el desarrollo, el uso de UML y la unificacin del trabajo de muchas
metodologas.
En el 2002 se anuncia la adquisicin de Rational por IBM.
UP se encuentra basado en componentes, lo que significa que el software
comienza a ser construido a partir de componentes de software que son
interconectados a travs de interfaces bien definidas.
UP utiliza UML para realizar los planos del sistema. Constituye una parte
integral y ambos fueron desarrollados a la par.
Las partes esenciales que distinguen al RUP son:
Manejo de casos de uso. Para construir un software exitoso se tiene que
conocer las perspectivas del usuario de lo que quiere y necesita. Los
usuarios no abarcan slo a personas sino tambin a otros sistemas. Un
caso de uso es una pieza de funcionalidad en un sistema que
59
proporciona al usuario un resultado. Los casos de uso capturan los
requerimientos. El conjunto de casos de uso forma un modelo de casos
de uso que describe la funcionalidad del sistema. Existe una influencia
recproca entre los casos de uso y la arquitectura de manera que van
madurando durante el ciclo de vida.
Centrado en la arquitectura. Involucra aspectos estticos y dinmicos del
sistema. La arquitectura va creciendo con las necesidades de la
organizacin, de los usuarios y clientes. Tambin influyen otros factores
como la plataforma de software, los componentes reutilizables,
consideraciones de desarrollo, sistemas heredados y requerimientos no
funcionales. La arquitectura es vista como un diseo completo de las
caractersticas ms importantes. Una funcin corresponde a un caso de
uso y forma la arquitectura, estos dos ltimos deben elaborarse en
paralelo. El arquitecto trabaja con un conjunto de casos de uso. Cada
caso de uso es especificado y realizado en subsistemas, clases y
componentes. Los casos de uso son especificados y madurados con los
descubrimientos de la arquitectura.
Iterativo e incremental. En desarrollos largos resulta prctico realizar
divisiones en el trabajo, en mini proyectos. Cada mini proyecto es una
iteracin que resulta en un incremento. Las iteraciones hacen referencia
a los flujos de trabajo (workflow) y los incrementos al crecimiento del
producto. Para ser ms efectivos, las iteraciones deben ser controladas.
El desarrollador basa su seleccin de lo que se implementar en una
iteracin con los casos de uso asignados y los riesgos implicados en
cada iteracin. Cada mini proyecto incluye su trabajo de desarrollo:
anlisis, diseo, implementacin y pruebas. En cada iteracin los
desarrolladores identifican y especifican los casos de uso relevantes,
crean un diseo utilizando la arquitectura seleccionada como gua,
implementan el diseo en componentes y verifican que los casos de uso
satisfagan los casos de uso. Si la iteracin alcanza las metas entonces
se contina a la siguiente iteracin.
60
UP repite una serie de ciclos que se realizan en la vida de un sistema. Cada
ciclo entrega un producto liberado al cliente. Cada ciclo consiste en cuatro
fases: principio, elaboracin, construccin y transicin. Cada fase se encuentra
dividida en iteraciones.
Cada ciclo produce una nueva liberacin del sistema y cada liberacin es un
producto listo para ser entregado. Consiste en un conjunto de cdigo fuente
que puede ser compilado y ejecutado, ms los manuales y entregables
asociados. El producto final va ms all del cdigo ejecutable, pues incluye los
requerimientos, casos de uso, requerimientos no funcionales y casos de
prueba. Esto facilitar el aumento o modificacin de funcionalidades del
sistema ya que a sus elementos se les puede dar un seguimiento.
Cada ciclo es dividido en cuatro fases. Dentro de cada fase se divide el trabajo
en iteraciones y resultado de incrementos. Cada fase termina en un hito. Se
define cada hito por la disponibilidad de un conjunto de artefactos, los cuales
pueden ser modelos o documentos.
Existen cinco flujos de trabajo principales: requerimientos, anlisis, diseo,
implementacin y pruebas. Una iteracin tpica cruza los cinco flujos de trabajo
que se encuentran presentes en cada fase.
En la fase de principio se desarrolla una visin del producto final y el caso del
negocio (business case) es presentado. Un modelo de caso de uso simplificado
contiene los casos de uso ms importantes. En esta parte la arquitectura es
tentativa. Los riesgos ms importantes son identificados y priorizados, se
planifica la fase de elaboracin a detalle y el proyecto es estimado
tentativamente.
En la fase de elaboracin los casos de uso son especificados a detalle y la
arquitectura es diseada. Los casos de uso ms crticos que fueron
encontrados en esta fase son desarrollados. El resultado de esta fase es la
61
arquitectura base. Se planifican las actividades y se estiman los recursos
requeridos para completar el proyecto.
En la fase de construccin el producto es construido y colocado en la
infraestructura. Los recursos solicitados son utilizados. Al final de esta fase el
producto contiene todos los casos de uso que fueron agregados para la
liberacin.
Finalmente la fase de transicin es el periodo de movimiento del producto a
una liberacin beta. En esta liberacin los usuarios interactan con el producto
y se reportan defectos y deficiencia. Tambin se involucran en esta fase las
actividades de manufactura, entrenamiento al personal, soporte, correccin de
defectos posteriores a la liberacin. El mantenimiento se realiza dividiendo los
defectos en aquellos que su afectacin justifica inmediatamente una nueva
liberacin y aquellos que pueden esperar y ser incluidos en la prxima
liberacin ordinaria.
Bibliografa del tema 4
Jacobson, Ivar. The Unified Software Development Process. Mexico City,
Addison-Wesley, 1999.
Kontoya, Gerald. Requirements Engineering: Processes and Techniques.
Chichester, Wiley, 1997.
Sommerville, Ian. Requirements Engineering: A good practice guide. New York,
Wiley, 1998.
Pginas de referencia
http://www.qfdi.org
62
Actividades de aprendizaje
A.4.1. Elaborar un cuadro con las clasificaciones de los requerimientos y llenar
cada una de las clasificaciones con ejemplos.
A.4.2. Elabore una lista de verificacin con los elementos que se tomaran en
cuenta para revisar un requerimiento.
A.4.3. Elaborar la agenda de una entrevista cerrada en la que se incluyan las
tcnicas que se emplearn, los temas a tratar y el desarrollo de la
entrevista.
A.4.4. Elaborar un cuestionario con preguntas que se aplicaran al usuario en la
primera entrevista cerrada.
A.4.5. Investigar y realizar un reporte de dos herramientas de software que se
puedan emplear para la obtencin de requerimientos.
Cuestionario de autoevaluacin
1. Qu es un requerimiento?
2. Cul es la clasificacin tradicional de los requerimientos?
3. Qu significa RUP?
4. Qu significa FURPS?
5. Qu actividades debera de realizar el proceso de requerimientos?
6. Describe las tcnicas que existen para obtener requerimientos.
7. A qu otros elementos hace referencia el modelo FURPS+?
8. Cul es la relacin que tienen los requerimientos con las dems fases
dentro del desarrollo de software?
9. Cules son los problemas ms comunes que se relacionan con la
obtencin de requerimientos?
10. Cules son los elementos principales del RUP?
63
Examen de autoevaluacin
Instrucciones. Seleccione una de las opciones y escriba la letra
correspondiente en el parntesis de la derecha de cada pregunta.
1. RUP es? ( )
a) Una tcnica para obtener requerimientos
b) Una clasificacin de requerimientos
c) Un proceso de requerimientos
d) Un proceso de desarrollo de software
2. Los cuestionarios son? ( )
a) Una herramienta de anlisis
b) Una tcnica para la obtencin de requerimientos
c) Una metodologa de requerimientos
d) Ninguna de las anteriores
3. De qu modelo son parte los requerimientos fsicos? ( )
a) ETHICS
b) FURPS+
c) UML
d) FURPS
4. Es uno de los tipos de entrevistas ( )
a) Entrevistas de campo
b) Entrevistas de definicin
c) Entrevistas abiertas
d) Todas las anteriores
5. Es uno de los elementos del modelo FURPS ( )
a) Facilidad
b) Utilidad
c) Productividad
d) Ninguno de los anteriores
6. Son las actividades sugeridas para un proceso de requerimientos ( )
a) Obtencin de requerimientos
b) Negociacin y anlisis de requerimientos
c) Validacin de requerimientos
d) Todas las anteriores
64
7. Forma parte de los mtodos ligeros de sistemas ( )
a) SSM
b) FAST
c) QFD
d) UML
8. Son requerimientos que dependen del buen funcionamiento de otros
elementos. ( )
a) Requerimientos fsicos
b) Requerimientos de propiedades emergentes
c) Requerimientos operativos
d) Ninguna de las anteriores
9. Es una de las caractersticas que hace nico al RUP ( )
a) Desarrollo iterativo e incremental
b) Funcionalidad
c) Fcil de usar
d) Rapidez
10. Es uno de los elementos que es necesario para que algo sea un
requerimiento ( )
a) Solicitud formal
b) Estar documentado
c) Requiere aprobacin
d) Todas las anteriores
65
TEMA 5. ANLISIS DE SOFTWARE
Objetivo particular
Al finalizar este tema el alumno ser capaz de identificar la importancia del
anlisis de software y las actividades para llevarlo acabo dentro del ciclo de
desarrollo de software.
Temario detallado
5.1 Estudios de factibilidad
5.2 Estructurado
5.3 Orientado a objetos
5.4 UML
Introduccin
El anlisis de software es un paso intermedio entre la obtencin de
requerimientos y el diseo. En esta fase se aplican los mtodos y tcnicas a
partir de los requerimientos y objetivos establecidos para obtener una mejor
comprensin del proyecto de software que se pretende realizar.
El anlisis de requerimientos genera una representacin de la informacin,
funciones y comportamiento que puede ser trasladado a datos, arquitectura,
interfaces y diseos a nivel componentes.
5.1 Estudios de factibilidad
Este tipo de estudios proporcionan los elementos para decidir la conveniencia
de realizar un proyecto considerando elementos internos y externos. De esta
forma se pueden incluir a los estudios de factibilidad: factibilidad tcnica,
factibilidad econmica y anlisis de sensibilidad.
66
Es importante destacar que para realizar estos pasos es necesario que ya se
tengan establecidos los objetivos del proyecto.
Factibilidad tcnica. Se refiere a los estudios de concrecin tcnica del
proyecto, teniendo en cuenta los objetivos del proyecto y los recursos que
seran necesarios. Para ello se evala:
Las probabilidades reales de realizar el proyecto
Tipo de riesgos tcnicos implicados
Medidas para prevenir y disminuir los riesgos
Una herramienta de anlisis que se puede utilizar es la generacin de
escenarios, en l se puede representar un proyecto tanto en las mejores
condiciones como en el peor de los casos. De esta forma es posible identificar
los riesgos, entradas y salidas.
Al momento de realizar la programacin de las actividades es recomendable
que se verifique la disponibilidad de los recursos para el momento en el cual se
van a utilizar as como la cantidad, todo esto con la finalidad de obtener cierta
seguridad. Otro aspecto a considerar por parte de los recursos que se
emplearn es el priorizacin por importancia o costo de cada uno.
Analizar la estructura de la organizacin permitir identificar las condiciones
con las que cuenta para llevar a cabo el proyecto. De esta manera se realizar
la comparacin entre la propuesta terica y la real para encontrar la manera
ms adecuada de aplicar el proyecto dentro de la organizacin.
En el marco legar se analizan todas las leyes, cdigos y normas que pueden
afectar a un proyecto al momento de su realizacin. Los reglamentos tcnicos
son de carcter obligatorio. Mientas que las normas son de carcter voluntario.
Son determinaciones convencionales que son dadas por un organismo que se
encarga de proporcionarlas y certificar su cumplimiento.
67
En cuanto al impacto ambiental se realiza una evaluacin del impacto que
puede llegar a tener el proyecto en la flora, fauna, salud humana, etc. La
importancia radica en reducir al mnimo las alteraciones que pudieran
presentarse.
Factibilidad econmica. Es el estudio de las posibilidades de concrecin
econmica del proyecto.
A partir de los objetivos establecidos del proyecto y con el anlisis previo de los
recursos que se necesitan, es posible evaluar el tipo de riesgos financieros, los
ingresos y egresos del proyecto, alternativas de financiamiento, puntos dbiles
de la economa del proyecto y las medidas para contrarrestarlos.
El anlisis de mercado es otro de los aspectos que se deben de considerar
para determinar la viabilidad de un proyecto. Se realizan evaluaciones del
mercado.
En la oferta se observa a los competidores dentro del mercado y cada una de
sus caractersticas que la hacen diferenciarse de los dems.
En la demanda se evala a los clientes o consumidores. Con la formacin de
segmentos en el mercado se determinar su estructura de la demanda.
A partir de la oferta y del precio que existe en el mercado, se establece una
base sobre la cual puede trabajar el proyecto.
El aspecto comercial tiene que ver con las alternativas de comercializacin
existente y aquellas que pueden ser desarrolladas.
En el anlisis impositivo se toman en cuenta todos los elementos impositivos
que afectan al proyecto como: precios, carga social, impuestos, etc.
68
El anlisis econmico financiero permite la comprensin de los efectos
positivos y negativos, la magnitud del esfuerzo realizado y la conveniencia de la
realizacin. Para lo cual es necesario identificar la situacin anterior a la
realizacin del proyecto. Este estudio muestra el manejo de ingresos y egresos
en el tiempo.
Factibilidad operativa. Es el impacto del proyecto sobre la organizacin. Con
este anlisis se obtiene el dimensionamiento de los cambios que se tendrn en
la organizacin. Se tomar en cuenta las funciones y estructura que tiene la
organizacin, se elaborarn nuevas funciones, roles y flujos de trabajo. Se
identifican los posibles riesgos que conllevan las modificaciones. Se establece
un plan de capacitacin para las partes involucradas y se genera el anlisis
costo-beneficio operativo.
Factibilidad legal. Es este paso se analiza las posibles infracciones, violaciones
o responsabilidades legales que puede llevar el desarrollo de un sistema de
software. Esto incluye licencias de hardware, software, bandas de frecuencia,
leyes ambientales, etc.
Anlisis de sensibilidad. Permite calcular la importancia de una hiptesis en
particular. Esto genera un enfoque sobre la precisin de los factores crticos.
En este punto se toma en cuenta el estudio de los factores internos y externos
que pueden influir en el resultado del proyecto. A cada proyecto en particular se
puede ver afectado por diferentes factores, al inicio se deben de establecer
datos base para cada una de las variables. Para observar el comportamiento
de cada variable se puede hacer uso de mtodos estadsticos que permitan
entender los ciclos y tendencias. La afectacin de una o varias variables puede
ser tanto a los costos como a los beneficios del proyecto.
El comportamiento de las variables ms significativas pueden hacerse sobre
tres escenarios principales: el ms probable, el optimista y el pesimista. Para
estos escenarios es importante realizar la identificacin de las variables ms
69
confiables y de aquellas que son poco confiables en su comportamiento y a
partir de ellas generar cada uno de los escenarios.
5.2 Estructurado
Con el nombre de estructurado se hace referencia a los recursos disponibles
para la perspectiva de programacin estructurada y diferenciarla de este modo
de los recursos disponibles para la perspectiva orientada a objetos. El anlisis
de requerimientos para la programacin estructurada se divide en cinco reas:
Reconocimiento del problema
Evaluacin y sntesis
Modelado
Especificaciones
Revisiones
Los mtodos de anlisis se encuentran basados en un conjunto de principios:
La informacin de un problema debe de ser representado y entendido
Las funciones del software debern de ser definidas
El comportamiento del software debe de ser representado
Los modelos que representan informacin, funciones y comportamiento
debern de ser divididos de manera de que sean abarcados a detalle.
El proceso de anlisis deber de mover la informacin esencial hacia
una implementacin detallada
Con la finalidad de realizar una mejor representacin del sistema de software
se presentan algunos modelos.
Existe un conjunto de modelos (datos, funcin y comportamiento) que pueden
utilizarse con la finalidad de hacer una representacin grfica que ayude a la
comprensin y anlisis de los requerimientos.
70
ERD (Entity Relationship Diagrams). Estos modelos permiten identificar los
objetos de datos y sus relaciones a travs de una notacin grfica. Se definen
los datos que ingresan, se almacenan, transforman y genera la aplicacin. En
la representacin los datos se organizan en grupos y se muestra la relacin
entre grupos.
Los atributos de cada entidad dentro del ERD son descritos en el diccionario de
datos. Los atributos para un objeto de datos son determinados con el
entendimiento del contexto del problema. Los atributos se asocian a
identificadores y llaves de las bases de datos.
Un diagrama ERD se compone de cajas que representan a las entidades y
lneas que indican las relaciones entre ellos. Una entidad es algo en el mundo
del que necesitamos almacenar datos. Las entidades se identifican dentro de
un sistema con nombres de sustantivos (archivos, repositorio de datos,
elementos que son manufacturados, roles funcionales, etc.). Los eventos y
actividades tambin pueden considerarse como entidades. Una entidad es slo
una representacin de datos.
Un atributo es una caracterstica nica de una entidad. Las relaciones son las
conexiones entre las entidades. Cada una de las relaciones representa una
asociacin entre dos entidades. La cardinalidad se refiere al nmero de
relaciones entre instancias de dos entidades (uno a uno, uno a muchos,
muchos a muchos). La normalizacin reestructura datos para reducir
redundancia y dependencias inconsistentes y para incrementar la flexibilidad
del modelo. La redundancia aumenta el tamao en disco y hace ms difcil el
mantenimiento. Existen cinco niveles de normalizacin llamados formas
normales.
Primera forma normal.
Segunda forma normal.
Tercera forma norma.
71
Cuarta forma normal.
Quinta forma normal.
DCD (Data Context Diagram). Es un diagrama de alto nivel que captura al
sistema y sus interfaces externas a diferentes entidades o sistemas. Se
identifica el lmite entre el sistema y su ambiente con sus entradas y salidas.
Con un solo proceso se muestra la transformacin realizadas por el sistema. La
notacin de DCD incluye cajas que representan a las entidades externas al
sistema, el flujo de datos se representa con flechas y crculos que representan
los procesos del sistema que transforman los datos.
DFD (Data Flow Diagrams). Es una representacin del sistema como una red
de procesos funcionales conectados entre ellos por flujos de datos y repositorio
de datos. Los procesos transforman los datos. Para abarcar todo el sistema se
divide en componentes. Empleando la descomposicin funcional es posible ir
de una representacin de alto nivel a uno de menor nivel o ms detallado.
DFD utiliza crculos para representar a los procesos, flechas para los flujos de
datos y dos lneas paralelas para los repositorios de datos. En este tipo de
diagrama slo representa los repositorios externos pero no las entidades.
PSPEC (Process Specifications). Es una descripcin de un proceso o funcin a
un nivel de descomposicin detallado. Captura los pasos que son necesarios
para realizar cada proceso, en los que se manejan las entradas y las salidas.
Para ello se puede realizar seudocdigo, tablas de decisin, ecuaciones u otras
grficas.
CCD (Control Context Diagram). Cuenta con slo un proceso, muestra las
entradas y salidas que se realizan con las entidades externas, detallndose
hasta finalizar en especificaciones. La diferencia con respecto a otros
diagramas es el cambio de estado del sistema que activa y desactiva las
transformaciones. Los smbolos que emplea el CCD son los mismos a un DCD,
72
con la excepcin del control de datos que se representa de flechas de lnea no
continua para distinguirla de otros datos.
CFD (Control Flow Diagrams). Es un diagrama semejante al DFD, con la
variacin de que se modela el flujo de control de datos y no flujo de datos.
Comparte las mismas propiedades del DFD, as como tambin los procesos y
repositorio de datos. La diferencia radica en la presentacin del flujo de control
a travs de lneas no continuas y el smbolo de una barra que indica la
especificacin de control (CSPEC) que puede cambiar el estado del sistema.
CFD no muestra las entidades externas.
CSPEC (Control Specifications). Contiene la informacin adicional relacionada
a los aspectos de control. El propsito primario es modificar la respuesta del
procesamiento de datos de acuerdo a las condiciones pasadas y presentes
tanto dentro y fuera del sistema. Es importante identificar todos los posibles
estados del sistema para representarlos por modelos finitos de estados que
describen el comportamiento del sistema. STD (State Transition Diagram)
representa el comportamiento de un sistema para que sean observables los
eventos y los estados que causan el cambio de estado de un sistema. STD
representa a los CSPEC en donde las condiciones son representadas por
entradas de control de flujo y las acciones son representadas por flujos de
control de salida.
5.3 Orientado a objetos
Los modelos orientados a objetos se encuentran enfocados como soporte a la
programacin orientada a objetos. Llevan a cabo la representacin del sistema
de software con sus elementos y sus relaciones.
Un modelo de anlisis orientado a objetos se basa en los siguientes principios:
La informacin dominio es modelada
73
Las funciones son descritas
El comportamiento es representado
Los modelos de datos, funciones y comportamiento son divididos para
presentar los detalles
Los modelos anteriores representan la esencia del problema y los
modelos posteriores proporcionan el detalle de la implementacin
En el anlisis se definen todas las clases que son relevantes para solucionar el
problema junto con las operaciones y atributos asociados, sus relaciones y el
comportamiento. Para lograr lo anterior es importante realizar las siguientes
tareas:
1. Los requerimientos bsicos del usuario deben de ser comunicados entre
el cliente y el ingeniero de software.
2. Las clases deben de ser identificadas (atributos y mtodos)
3. Una jerarqua de clase debe de ser especificada
4. Las relaciones entre objetos debern de ser representadas
5. El comportamiento del objeto deber de ser modelado
6. Las tareas del 1 al 5 se aplican de manera iterativa hasta que el modelo
es completado
Grady Booch, James Rumbaugh e Ivar Jacobson colaboraron para generar un
mtodo unificado para el anlisis y diseo orientado a objetos (UML). Este
conjunto de diagramas permiten ver a un sistema desde diferentes
perspectivas.
El anlisis orientado a objetos en un nivel de abstraccin de aplicacin el
modelo de objetos se enfoca en los requerimientos especficos del cliente. El
proceso comienza con definir la manera en la que se representa el sistema
orientado a objetos. Se documentan las clases con sus atributos y operaciones.
Se proporciona una vista inicial de la colaboracin entre objetos.
Posteriormente se clasifican los objetos y se genera una jerarqua de clase. Se
74
pueden emplear subsistemas o paquetes para encapsular objetos
relacionados. El modelo de relacin de objetos muestra la conexin que existe
entre objetos. El modelo de comportamiento de objetos proporciona el
comportamiento de un objeto en particular y el de todos los objetos. Para
realizar las representaciones mencionadas anteriormente el analista puede
hacer uso de varios de los diagramas de UML (Unified Modeling Language).
5.4 UML
UML (Unified Modeling Language) es un lenguaje grfico para visualizar,
especificar, construir y documentar los artefactos de un sistema de software.
UML proporciona una forma estandarizada de representar los planos de un
sistema, incluyendo los procesos del negocio y funciones del sistema, as como
cuestiones concretas del lenguaje de programacin, estructura de base de
datos y componentes reutilizables de software.
UML no se encuentra sujeto a una metodologa en especfico, por lo que es
posible adoptarla de acuerdo a las especificaciones de la metodologa que se
vaya a emplear.
UML 2 define trece diagramas, los cuales se encuentran agrupados de la
siguiente manera:
Diagramas de estructura
Diagrama de clase. Clases, interfases, tipos y otras relaciones entre
ellos.
Diagrama de objetos. Instancias de objetos de las clases definidas en
los diagramas de clase en configuraciones importantes del sistema.
Diagrama de componentes. Componentes importantes del sistema y las
interfases que utilizan para comunicarse con los otros.
75
Diagrama de estructura compuesta. Los elementos de una clase o
componentes y la descripcin de relaciones de clases dentro de un
contexto.
Diagrama de paquetes. Organizacin jerrquica de grupos de clases y
componentes.
Diagrama de despliegue. Como se despliega el sistema finalmente en
una situacin real.
Diagramas de comportamiento
Diagrama de casos de uso. Interaccin entre el sistema y el usuario u
otros sistemas externos.
Diagrama de actividades. Actividades secuenciales o paralelas dentro
del sistema.
Diagrama de estados. Estado de un objeto durante su tiempo de vida y
los eventos que pueden cambiar su estado.
Diagramas de interaccin
Diagrama de secuencias. Interaccin entre objetos en donde el orden de
las interacciones es importante.
Diagrama de comunicacin. Las formas en las cuales los objetos
interactan y las conexiones necesarias para esas interacciones.
Diagrama de tiempos. Interacciones entre objetos en donde el tiempo es
importante.
Diagrama de descripcin de interaccin. Se emplea para conjuntar los
diagramas de secuencia, comunicacin y tiempo para capturar una
importante interaccin dentro del sistema.
76
Bibliografa del tema 5
Futrell, Robert T., Quality software project management. Nueva Jersey,
Prentice Hall, c2002.
Miles, Russell, Learning UML 2.0. California, O'Reilly, 2006.
Pressman, Roger, Software Engineering: A practitioners approach. Nueva
York, McGraw-Hill, 2001.
Salvarredy, Julin Ral. Gestin econmica y financiera de proyectos. Buenos
Aires, Omicron System, c2003.
Pginas electrnicas de referencia
http://www.uml.org/
77
Actividades de aprendizaje
A.5.1. Elaborar una lista con cinco riesgos tcnicos comunes en un proyecto de
desarrollo de software con las actividades para contrarrestar cada uno
de ellos.
A.5.2. Investigar dos modelos de anlisis adicionales que pueden utilizarse en
el esquema estructurado.
A.5.3. Investigar dos modelos de anlisis adicionales que puede utilizarse en el
esquema orientado a objetos.
A.5.4. Investigar dos herramientas de software que pueden utilizarse para el
anlisis de software.
A.5.5. Elaborar un cuadro de referencia con la simbologa de cada uno de los
modelos presentados en el tema.
Cuestionario de autoevaluacin
1. Entre qu fases del desarrollo de software se encuentra el anlisis de
software?
2. Qu es un estudio de factibilidad?
3. Cules son los elementos a considerar en un estudio de factibilidad?
4. En qu consiste el anlisis de software?
5. Cul es la importancia del anlisis de software?
6. Qu actividades son importantes de realizar en un anlisis de software?
7. Qu tan compatibles son las tcnicas de anlisis entre la perspectiva
estructurada y la orientada a objetos?
8. De qu forma se puede aplicar UML al anlisis de software?
9. Cmo se encuentran divididos los diagramas de UML?
10. Viendo al anlisis de software como un proceso Cules seran las
entradas y las salidas?
78
Examen de autoevaluacin
Instrucciones. Relacione las dos columnas colocando la letra de la columna
derecha dentro de los parntesis de la columna izquierda
1. ( ) Interaccin entre el sistema y el usuario u
otros sistemas externos.
a) ERD
2. ( ) Lenguaje grfico para visualizar,
especificar, construir y documentar los
artefactos de software.
b) Diagramas de
clases
3. ( ) Actividades secuenciales o paralelas
dentro del sistema.
c) Escenarios
4. ( ) Proporcionan los elementos para decidir
la conveniencia de realizar un proyecto
considerando elementos internos y externos.
d) DFD
5. ( ) Este modelo permite identificar los
objetos de datos y sus relaciones a travs de
una notacin grfica.
e) Casos de uso
6. ( ) Es un diagrama semejante al DFD, con la
variacin de que se modela el flujo de control
de datos y no flujo de datos.
f) CFD
7. ( ) Es un diagrama de alto nivel que captura
al sistema y sus interfaces externas a
diferentes entidades o sistemas.
g) UML
8. ( ) Clases, interfaces, tipos y otras
relaciones entre ellos.
h) Factibilidad
9. ( ) Es una representacin del sistema como
una red de procesos funcionales conectados
entre ellos por flujos de datos y repositorio de
datos.
i) DCD
10. ( ) Herramienta de anlisis que puede
presentar las mejores condiciones como en
el peor de los casos.
j) Diagrama de
actividades
79
TEMA 6. DISEO DE SOFTWARE
Objetivo particular
Con este tema el estudiante reconocer las diferentes tcnicas en el diseo de
software.
Temario detallado
6.1 Estudios de factibilidad
6.2 Estructurado
6.3 Orientado a objetos
6.4 UML
Introduccin
En el diseo de software se genera una representacin del software que se va
a desarrollar. Las diferentes tcnicas de diseo responden a la necesidad de
personificar al software en cada una de sus perspectivas. Dicha representacin
ayuda a clarificar los elementos del software para diferentes niveles y roles que
intervienen.
6.1 Estudios de factibilidad
Este punto ya fue desarrollado anteriormente en el subtema 5.1.
6.2 Estructurado
El diseo se enfoca principalmente en las siguientes reas: datos, arquitectura,
interfaces y componentes. Estos niveles de diseo parten del modelo de
requerimientos. Debido a la complejidad que implica desarrollar software es
80
importante contar con el diseo que permita construir adecuadamente los
componentes necesarios.
El modelo de anlisis proporciona los elementos necesarios para crear los
cuatro modelos necesarios para realizar una especificacin de diseo.
Diseo de datos. Transforma el modelo de informacin en estructuras de datos
que sern requeridas en para implementar el software. Parte del diseo de
datos se realiza en paralelo con el diseo de arquitectura de software. El
diseo ms a detalle de los datos se realiza a nivel componente.
Diseo de arquitectura. Define las relaciones entre elementos estructurales
mayores del software.
Diseo de interfaces. Describe la manera en la que el software se comunica
consigo mismo, con otros sistemas y con los humanos. Esto implica flujo de
informacin y los tipos de comportamiento.
Diseo de componentes. Transforma los elementos estructurales en
descripcin de procedimientos de componentes de software.
En el proceso de diseo se realiza la transformacin de los requerimientos en
un plano de construccin del software. Es una secuencia de pasos que
posibilitan al diseador describir todos los aspectos del software que se
pretende construir.
El modelo de diseo es una representacin de alto nivel que se va depurando
gradualmente hasta proveer una gua de construccin detallada.
Existen principios de diseo que pueden emplearse durante el proceso:
El proceso de diseo no debe de tener una visin cerrada
El diseo debe de ser rastreable para el modelo de anlisis
81
El diseo no debe de ser una reinvencin de las cosas
El diseo debe de minimizar la distancia intelectual entre el software y el
problema
El diseo debe de mostrar uniformidad e integracin
El diseo debe de estar estructurado para ajustarse a los cambios
El diseo debe de estar estructurado para adecuarse a situaciones
inusuales
Diseo no es generar cdigo, generar cdigo no es disear
El diseo debe de ser evaluado en calidad cuando se est generando y
no al final
El diseo debe de ser revisado para minimizar los errores de significado
A continuacin se presentan algunos diagramas que permiten la asimilacin de
los requerimientos a un nivel de construccin de software. Muchos de ellos
utilizan diagramas que previamente fueron elaborados en el anlisis de
requerimientos.
ACD (Architecture Context Diagrams). Establece la informacin lmite entre el
sistema y su entorno. Muestra la asignacin fsica de los requerimientos del
modelo de datos (DFD) y control de procesamiento (CFD). Establece procesos
del modelo de requerimientos a mdulos fsicos del sistema y establece la
relacin entre ellos. Es un diagrama de representacin de alto nivel. Los
elementos que intervienen generan un mdulo de arquitectura.
AFD (Architecture Flow Diagram). Los procesos del DFD son reorganizados de
acuerdo a propiedades fsicas. Es una representacin en red de la
configuracin fsica de un sistema. Muestra la asignacin de los requerimientos
del modelo de datos y de procesamiento de control, as como del flujo entre
entidades fsicas. Que realizarn actividades asignadas. Esto significa una
divisin fsica del sistema en piezas y flujos entre ellas. La definicin de
mdulos fsicos agrega ms perspectivas a las perspectivas funcionales y de
control de procesamiento.
82
Structure Charts. Organiza los sistemas divididos en cajas negras
jerarquizadas. Las cajas negras: indican que el usuario conoce las funciones
pero no las operaciones internas, reducen la complejidad porque ocultan todo
aquello que no se necesita saber, reciben entradas y proporcionan salidas.
Esto facilita su construccin, prueba, correccin, entendimiento y modificacin.
La distribucin es una secuencia vertical temporal. Se encuentra constituido por
mdulos, cada mdulo es un conjunto de problemas establecidos con entradas,
salidas, funciones y datos internos. Los mdulos superiores son los que se
ejecutan antes que aquellos que se encuentran ms abajo.
Chapin Charts. Es un modelo de diseo a nivel detallado. Tambin conocido
como diagramas Nassi-Schneiderman, describe los procedimientos para
recibir, procesar y transmitir informacin. Proveen la lgica necesaria para que
los programadores inmediatamente escriban programas estructurados. Se
utilizan cinco estructuras bsicas (secuencia, if-then-else, do-while, do-until y
do-case) que permiten su traduccin en cdigo de computadora. Su funcin es
igual a la de los dems diagramas. Su lectura se realiza como al igual que una
pgina impresa. Tiene un flujo jerrquico de instrucciones y opciones que
mantiene la lgica en los procedimientos.
Architecture Interconnect Diagrams. Representa los canales de comunicacin
que existen entre los mdulos de arquitectura. Muestra el medio fsico por el
cual los mdulos se comunican. Captura las caractersticas de los canales por
los cuales fluir la informacin entre los mdulos. Esta parte debe de ir
fuertemente ligada con el modelo de anlisis.
6.3 Orientado a objetos
El diseo orientado a objetos requiere de una definicin multicapa de la
arquitectura del software, especificacin de subsistemas, una descripcin de
objetos y la descripcin de los mecanismos de comunicacin que permiten el
flujo de datos entre capas, subsistemas y objetos.
83
El diseo orientado a objetos se rige bajo cuatro importantes principios:
abstraccin, ocultamiento, independencia funcional y modularidad.
Existen cuatro capas en el diseo:
Capa de subsistema. Se encarga de cada uno de los subsistemas que
permiten alcanzar los requerimientos establecidos e implementar la
infraestructura tcnica que los soporta.
Capa de objetos y clases. Contiene la jerarqua de clases que son
utilizadas empleando generalizaciones y estableciendo objetivos
especficos. Se genera la representacin de cada objeto.
Capa de mensajes. Tiene los detalles que hacen que cada objeto se
comunique. Aqu se establecen las interfaces internas y externas del
sistema.
Capa de responsabilidades. Contiene la estructura de datos y diseo de
algoritmos para todos los atributos y operaciones de cada objeto.
Independientemente del modelo de diseo que se utilice se puede observar
que se encuentran presentes los siguientes pasos:
1. Describe cada subsistema para localizar procesos y tareas
2. Selecciona una estrategia de diseo para administrar la implementacin
de datos, soporte de interfaces y administracin de tareas
3. Disea un mecanismo de control apropiado para el sistema
4. Realiza el diseo de objetos para crear una representacin de
procedimientos de cada operacin y estructura de datos para los atributos
de las clases
5. Desarrolla el diseo de mensajes empleando colaboraciones entre
objetos y relaciones de objetos
6. Crea el modelo de mensajes
7. Revisar el modelo de diseo
84
Se puede hacer uso de algunos diagramas para realizar la representacin del
diseo de software, algunos de ellos se pueden encontrar en la propuesta que
hace UML. A continuacin se presentan algunas opciones.
Interaction DiagramsCollaboration Diagrams. Grficas con nfasis en objetos
y ligas de objetos. Muestra como un caso de uso es realizado en trminos de
cooperacin de objetos, definido por clases dentro de la entidad, puede ser
especificado con una colaboracin. El caso de uso de una entidad puede ser
refinado a un conjunto de casos de uso de elementos contenidos en la entidad.
La interaccin de esos casos de uso subordinados puede ser expresada en
una colaboracin.
Interaction DiagramsSequence Diagrams. La grfica muestra una secuencia
temporal, con especial inters en el orden de los mensajes.
State Transition Diagrams. Representa los estados de una clase y los estados
que pasa la instancia de una clase.
6.4 UML
Este punto ya fue desarrollado en el subtema 5.4.
Bibliografa del tema 6
Futrell, Robert T., Quality software project management. Nueva Jersey,
Prentice Hall, c2002.
Pressman, Roger. Software Engineering: A practitioners approach. Nueva
York, McGraw-Hill, 2001.
85
Actividades de aprendizaje
A.6.1. Realizar un cuadro de correspondencia entre los modelos vistos de
anlisis y diseo de software.
A.6.2. Investigar dos modelos adicionales que puedan utilizarse en el esquema
estructurado.
A.6.3. Investigar dos modelos adicionales que puedan utilizarse en el esquema
estructurado.
A.6.4. Investigar dos opciones de herramientas de software que puedan
emplearse en el diseo.
A.6.5. Elaborar cuadro de referencia con la simbologa de cada uno de los
modelos presentados en el tema.
Cuestionario de autoevaluacin
1. Qu es el diseo de software?
2. Cul es la importancia de realiza el diseo de software?
3. De qu forma se mejora la comprensin del software con el diseo?
4. Por qu existen diferentes tcnicas de diagramacin?
5. Cules son los principios de la programacin orientada a objetos?
6. Es necesario aplicar todas las tcnicas de diseo para asegurar la calidad
del software?
7. Qu diagramas de UML pueden aplicarse al diseo de software?
8. Cules son los principios de diseo de la perspectiva estructurada?
9. Cules son cuatro capas del diseo de la perspectiva orientada a objetos?
10. Bajo qu condiciones sera recomendable realizar el diseo del software?
86
Examen de autoevaluacin
Instrucciones. Relacione las dos columnas colocando la letra de la columna
derecha dentro de los parntesis de la columna izquierda
1. ( ) Es un modelo de diseo a nivel
detallado. Tambin conocido como
diagramas Nassi-Schneiderman.
a) AFD
2. ( ) Organiza los sistemas que han
sido divididos en cajas negras
jerarquizadas.
b) Chapin Charts
3. ( ) Tienen un nfasis en objetos y
ligas de objetos.
c) Architecture Interconnect
Diagrams
4. ( ) Nivel de diseo estructurado d) Interaction Diagrams
5. ( ) Establece la informacin lmite
entre el sistema y su entorno.
e) State Transition Diagrams
6. ( ) Nivel de diseo orientado a
objetos.
f) Structure Charts
7. ( ) Muestra una secuencia temporal,
con especial inters en el orden de
los mensajes.
g) Datos
8. ( ) Representa los estados de una
clase y los estados que pasa la
instancia de una clase.
h) Subsistema
9. ( ) Representa los canales de
comunicacin que existen entre los
mdulos de arquitectura.
i) Collaboration Diagrams
10. ( ) Los procesos del DFD son
reorganizados de acuerdo a
propiedades fsicas
j) ACD
87
TEMA 7. VERIFICACIN Y VALIDACIN
Objetivo particular
En este tema el alumno conocer las actividades que le permitirn asegurar la
calidad del software durante el proceso de desarrollo.
Temario detallado
7.1 Pruebas
7.2 Puntos por funcin
Introduccin
Durante el proceso de desarrollo de software es necesario llevar a cabo
actividades que permitan asegurarnos que los productos que se estn
generando se estn realizando bien y correctamente. Cada desarrollo deber
de identificar los elementos que considere ms importantes para que sean
sometidos por estas actividades.
7.1 Pruebas
Probar es una operacin o accin tcnica que consiste en la determinacin de
una o ms caractersticas de un producto, proceso o servicio, de acuerdo a un
conjunto de especificaciones dadas.
El ciclo de vida de las pruebas de software involucra pruebas durante todo el
proceso de desarrollo. Para poder emplear este ciclo de vida es necesario que
se cuente con un proceso de desarrollo definido, pues ste definir las fases y
los entregables que sern sometidos a prueba.
88
De manera general se presentan algunas de las actividades que se realizan en
cada fase del ciclo de vida.
Fase del ciclo de vida Actividades
Requerimientos Determinar la verificacin
Determinar la adecuacin de
los requerimientos
Generar pruebas funcionales
de datos
Determinar la consistencia del
diseo con los requerimientos
Diseo Determinar la adecuacin del
diseo
Generar pruebas funcionales y
estructurales de datos
Determinar la consistencia con
el diseo
Desarrollo/Construccin Determinar la adecuacin de la
implementacin
Generar pruebas estructurales
y funcionales de datos para los
programas
Pruebas Pruebas de sistema
Instalacin Colocar las pruebas de sistema
en produccin
Mantenimiento Modificar y volver a probar
A continuacin se presentan las definiciones ms comunes que se emplean
dentro del rea de pruebas de software. Durante el ciclo de vida se aplican
varios tipos de pruebas.
89
Categoras de las pruebas:
Unitarias. Pruebas aplicadas a un mdulo aislado o unidad de cdigo.
Integracin. Pruebas desarrolladas a un grupo de mdulos para
asegurar que los datos y el control sean intercambiados adecuadamente
entre mdulos.
Sistema. Una combinacin predeterminada de pruebas para asegurarse
de que el sistema alcanza los requerimientos.
Aceptacin. Prueba que asegura que el sistema alcanza las
necesidades de la organizacin y los del usuario o cliente final.
Regresin. Son pruebas realizadas despus de que se han realizados
las modificaciones para asegurar de que no se hayan ingresado cambios
indeseados.
Error. La gente comete errores o equivocaciones. Los errores tienden a
propagarse; un error en la etapa de requerimientos puede acrecentarse durante
el diseo y aumentar an ms durante la codificacin.
Defecto. El defecto es el resultado de un error. De forma ms precisa podra
decirse que un defecto es la representacin de un error, representacin que
queda expresado en forma de texto, diagrama de flujo, cdigo fuente, etc. Los
sinnimos utilizados son bug y falta. Los defectos pueden ser difciles de
detectar. Cuando se tiene una omisin el defecto consiste en que algo que
debera estar presente no lo est. Por lo que podra decirse que existen dos
tipos de defectos: por omisin y por comisin. El defecto por comisin tiene que
ver con una representacin incorrecta de lo solicitado. El defecto por comisin
ocurre al momento de ingresar informacin. De estas dos el defecto por
omisin es ms difcil de detectar y resolver.
Falla. La falla aparece al momento en que se ejecuta un defecto. Este por lo
tanto slo se da para una representacin ejecutable y en defectos por
comisin. Entonces, qu hacer con los defectos que nunca se ejecutan o no
90
se ejecutan por mucho tiempo? Una opcin aceptable es realizar buenas
revisiones, que pueden prevenir fallas y encontrar defectos por omisin.
Casos de prueba. Estructura que permita probar todos los procesos posibles
del sistema para encontrar sus inadecuaciones con los requerimientos y
normas establecidas, con el menor esfuerzo y tiempo posibles. Es un conjunto
de entradas, condiciones de ejecucin y resultados esperados desarrollados
para un objetivo particular como, por ejemplo, ejercitar un camino concreto de
un programa o verificar el cumplimiento de un determinado requisito.
Verificacin. Son todas las actividades a travs del ciclo de vida que aseguran
que los productos internos en el proceso cumplan con sus especificaciones.
Validacin. Asegura que el producto final cumple con las especificaciones
establecidas.
Pruebas estticas. Son las realizadas sin la ejecucin del cdigo.
Pruebas dinmicas. Son realizadas con la ejecucin del cdigo.
Pruebas funcionales. Pruebas a partir de los requerimientos (qu es lo que se
supone que hace). Se asegura de que los requerimientos sean cumplidos
adecuadamente por el software.
Pruebas estructurales. Pruebas sobre la estructura del sistema (cmo el
sistema fue implementado). Se asegura de que el producto diseado es
estructuralmente lgico.
Pruebas manuales. Son pruebas realizadas por personas.
Pruebas automatizadas. Son pruebas realizadas por la computadora.
91
Pruebas de caja negra. Pruebas basadas en especificaciones externas sin el
conocimiento previo de cmo se encuentra construido.
Pruebas de caja blanca. Pruebas basadas en el conocimiento de la estructura
interna y lgica.
Dentro de las pruebas existen tcnicas que hacen posible reducir los riesgos
inherentes a los sistemas. Una tcnica de pruebas es un proceso para
asegurar que algn aspecto del software o unidad funcione adecuadamente. A
partir de las tcnicas se definen las herramientas, el cual es el vehculo para
llevar a cabo el proceso de pruebas. Algunas tcnicas de pruebas son:
Pruebas de estrs
Pruebas de ejecucin
Pruebas de restauracin
Pruebas de operaciones
Pruebas de conformidad
Pruebas de seguridad
Pruebas de requerimientos
Pruebas de regresin
Pruebas de manejo de errores
Pruebas de soporte manual
Pruebas entre sistemas
Pruebas de control
Pruebas en paralelo
Pruebas unitarias
A continuacin se presentan un listado de herramientas que pueden emplearse
en conjunto con alguna de las tcnicas de pruebas mencionadas
anteriormente.
92
1. Criterios de aceptacin. Consiste en proporcionar estndares que deben
de ser alcanzados por el sistema para que sean aceptables para el
usuario.
2. Anlisis de valor lmite. Divide al sistema de arriba hacia abajo en
segmentos lgicos y con ello limita las pruebas con lmites en cada
segmento.
3. Grfica causa efecto. Intenta mostrar los efectos de cada evento
procesado con el fin de categorizar eventos por el efecto que ocurrir
como resultado del procesamiento.
4. Checklist. Una serie de preguntas diseadas para ser utilizadas en la
revisin en una determinada rea o funcin.
5. Comparacin de cdigo. Identifica la diferencia entre dos versiones del
mismo programa.
6. Anlisis basado en compilador. Detecta errores de un programa durante
el proceso de compilacin.
7. Mtrica basada en complejidad. Utiliza relaciones para identificar el grado
de complejidad de procesamiento del programa.
8. Confirmacin / Examinacin. Verifica que las condiciones han o no han
ocurrido.
9. Anlisis de control de flujo. Identifica inconsistencias de procesamiento
para identificar problemas lgicos dentro de los programas.
10. Correctness Proof. Involucra un conjunto de sentencias o hiptesis que
definen lo correcto del procesamiento. Esas hiptesis son probadas para
determinar si las aplicaciones desempean el procesamiento de acuerdo
con las sentencias.
11. Mtricas basadas en cobertura. Utiliza relaciones matemticas para
mostrar qu porcentaje de las aplicaciones han sido cubiertas por el
proceso de pruebas. La mtrica resultante puede ser utilizada para
predecir la efectividad del proceso de pruebas.
12. Diccionario de datos. Genera datos de prueba para verificar la validacin
de los programas de validacin de programas basados en los datos
contenidos en el diccionario.
93
13. Anlisis de flujo de datos. Un mtodo para asegurar que los datos usados
por el programa han sido definidos adecuadamente y los datos definidos
sean utilizados adecuadamente.
14. Pruebas funcionales basadas en diseo. Reconoce qu funciones dentro
de una aplicacin son necesarias para los requerimientos. Este proceso
identifica las funciones basadas en diseo para propsitos de pruebas.
15. Revisiones del diseo. Revisiones conducidas durante el proceso de
desarrollo normalmente en concordancia con la metodologa de
desarrollo. El objetivo primario es asegurar la conformidad con la
metodologa de desarrollo.
16. Revisiones de escritorio. Proporcionan una evaluacin realizada por el
programador o analista al elemento de programa lgico antes de ser
codificado o diseado.
17. Prueba de desastre. Son simulaciones de fallas para determinar si el
sistema puede ser correctamente recuperado despus de la falla.
18. Conjeturas de error. Utiliza la experiencia o el juicio de la gente para
determinar a travs de conjeturas los errores que muy probablemente
puedan ocurrir y a partir de ellos probar para asegurarnos si el sistema
puede manejar esas condiciones.
19. Especificaciones ejecutables. Requiere de una interpretacin del sistema
de alto nivel para escribir las especificaciones. Las especificaciones
compiladas tienen menos detalles y precisin a comparacin de los
programas finales implementados, pero son suficientes para evaluar que
las especificaciones se encuentran completas y con el adecuado
funcionamiento.
20. Pruebas exhaustivas. Se intenta crear suficientes pruebas para evaluar
cada camino y condicin de la aplicacin.
21. Indagacin de hechos. Desempea los pasos necesarios para obtener
hechos de apoyo al proceso de pruebas.
22. Diagrama de flujo. Representacin grfica de la lgica y el flujo de datos
de una aplicacin.
94
23. Inspecciones. Revisin paso por paso del producto en el que cada paso
es revisado contra una lista con criterios predeterminados.
24. Instrumentacin. Mide la funcin de la estructura de un sistema utilizando
contadores u otro instrumento de monitoreo.
25. Facilidad integrada. Permite la introduccin de datos de prueba en el
ambiente de produccin, de forma que las aplicaciones pueden ser
probadas al mismo tiempo que se encuentran ejecutndose en
produccin.
26. Mapeo. Identifica qu partes de un programa son ejecutadas durante una
prueba y su frecuencia.
27. Modelado. Mtodo de simulacin de las funciones de la aplicacin y/o
ambiente para determinar si las especificaciones de diseo alcanzan los
objetivos del sistema.
28. Operacin en paralelo. Se corre la vieja y la nueva versin a la vez para
identificar las diferencias entre los dos procesos.
29. Simulacin en paralelo. Aproxima los resultados esperados de
procesamiento para simular el proceso y determinar si los resultados son
razonables.
30. Revisin en pares. Provee una evaluacin en pares de la eficiencia, estilo,
seguimiento de los estndares. Del producto diseado para mejorar la
calidad del producto.
31. Matriz de riesgos. Se produce una matriz que muestra las relaciones
entre los riesgos del sistema, el segmento en el sistema en donde ocurre
el riesgo y la ausencia o ausencia de controles para reducir ese riesgo.
32. SCARF (por sus siglas en ingls) Sistema de control de auditora y
revisin de archivos. Construye un historial de los errores potenciales
con la finalidad de comparar problemas en una unidad en un periodo de
tiempo y/o compararlo contra otras unidades.
33. Marcador. Identifica reas en la aplicacin que requieren pruebas, a
travs de un criterio para relacionarlas a problemas.
34. Foto. Muestra el contenido almacenado de una computadora en puntos
especficos durante el proceso.
95
35. Ejecucin simblica. Identifica caminos de procesamiento para probar
programas con smbolos y no con datos de prueba.
36. Registros del sistema. Proporciona un rastro y monitorea eventos en un
ambiente controlado por un software.
37. Datos de prueba. Crea transacciones para que se utilicen en
determinadas funciones de un sistema de computadora.
38. Generados de datos de prueba. Proporciona pruebas de transacciones
basadas en parmetros que necesitan probarse.
39. Seguimiento. Sigue y enlista el flujo de procesamiento y datos basados en
bsquedas.
40. Programa utilitario. Analiza e imprime el resultado de una prueba a travs
del uso de un programa de propsito general.
41. Prueba de volumen. Identifica las restricciones del sistema y crea grandes
volmenes de transacciones diseados para exceder esos lmites.
42. Walk-throughs. Lleva al equipo de pruebas a realizar una simulacin
manual del producto utilizando pruebas de transaccin. Se cuestiona al
autor del elemento de software y se le solicita que explique su
funcionamiento.
7.2 Puntos por funcin
En 1979 fue publicada la mtrica Function Point por A. J. Albrecht de IBM. Son
el resultado de la utilizacin de la relacin emprica basada en las mediciones
contables directas del software y la evaluacin de la de complejidad del
software.
Los puntos por funcin son computados para completar una tabla que contiene
cinco caractersticas que son determinadas y contadas para posteriormente
colocarlas en su lugar correspondiente dentro de la tabla. Los valores de cada
caracterstica se definidos de la siguiente forma:
96
Nmero de entradas del usuario. Se cuenta cada pantalla o ventana que
provee una entrada al sistema. Si una ventana tiene varios campos,
cada campo es calculada como una entrada. Si la ventana provee varias
fuentes que no son enviadas al mismo tiempo, cada fuente es calculada
como una entrada.
Nmero de salidas del usuario. Se cuenta cada salida que provee
informacin al usuario. Se incluyen reportes, mensajes de error,
ventanas, etc. Los campos no son calculados de manera individual.
Nmero de consultas del usuario. Una consulta de usuario es una
entrada directa de un usuario que obtiene una respuesta directa.
Nmero de archivos. Un grupo lgico de datos permanentes es
considerado un archivo. Se incluyen tablas de bases de datos, archivos
de configuracin, archivos de ayuda, etc.
Nmero de interfaces externas. Se incluyen todas las interfaces a otros
sistemas. Las interfaces deben de ser mquina a mquina. Si interviene
el factor humano entonces se considera una entrada o consulta de
usuario.
Una vez que se han contabilizado todas caractersticas entonces se agrega un
valor de complejidad a cada uno. Cada organizacin determina un criterio para
determinar si es simple, promedio o complejo.
Para computar los puntos por funcin se emplea la siguiente relacin:
FP = Conteo total x [0.65 + 0.01 x (F
i
)]
En donde:
FP es la suma total de todas las caractersticas despus de aplicarse el
estimado de dificultad.
F
i
(i = 1 a 14) es la suma de los valores de ajuste de complejidad. Se
basa en catorce preguntas. Cada pregunta tiene una escala del 0 al 5.
97
0.65 y 0.01 son nmeros basados en evidencia emprica.
Las preguntas que se aplican para generar el ajuste de complejidad son:
1. El sistema requiere una restauracin y respaldo confiable?
2. Las comunicaciones de datos son requeridos?
3. Existen funciones de procesamiento distribuido?
4. El desempeo es crtico?
5. El sistema correr dentro de un ambiente existente y de procesamiento
pesado?
6. El sistema requiere de entrada de datos en lnea?
7. Los datos ingresados en lnea requieren la transaccin de entradas para
realizar mltiples pantallas u operaciones?
8. Los archivos maestros se actualizan en lnea?
9. Las entradas, salidas, archivos, o consultas son complejos?
10. El procesamiento interno es complejo?
11. El diseo de cdigo es reutilizable?
12. Las conversiones y la instalacin son incluidas en el diseo?
13. El sistema es diseado para mltiples instalaciones en diferentes
organizaciones?
14. La aplicacin es diseada para facilitar el cambio y facilidad de uso para
el usuario?
La escala establecida para responder cada una de las preguntas anteriores es:
0: sin influencia
1: secundario
2: moderado
3: promedio
4: significante
5: esencial
98
Una vez que se ha realizado los clculos se pueden emplear de manera que se
puede medir la productividad, calidad y otros atributos como:
Errores por FP
Defectos por FP
Costo por FP
FP por persona al mes
Pginas de documentacin por FP
Parmetro de
medicin
Conteo Simple Promedio Complejo Resultado
Entradas de
usuario
X 3 4 6 =
Salidas de
usuario
X 4 5 7 =
Consultas de
usuario
X 3 4 6 =
Archivos X 7 10 15 =
Interfaces
externas
X 5 7 10 =
Conteo total
Bibliografa del tema 7
Pressman, Roger. Software Engineering: A practitioners approach. Nueva
York, McGraw Hill, 2001.
Perry, William E. Effective methods for software testing. Nueva York, Wiley,
1995.
99
Jorgensen, Paul C. Software Testing: A Craftsman's Approach. Boca Raton,
CRC, 2002.
Beizer, Boris. Software Testing Techniques. Nueva York, Van Nostrand
Reinhold, 1983.
Pginas de referencia
http://www.spr.com/
http://www.ifpug.org/
Actividades de aprendizaje
A.7.1. Investigar una herramienta de software que pueda utilizarse para realizar
pruebas funcionales.
A.7.2. Conseguir el estndar IEEE 829 y realizar un diseo de formatos
basados en el estndar.
A.7.3. Elaborar un checklist que contenga los elementos a revisar en una
prueba de conformidad.
A.7.4. Elaborar una matriz con las pruebas de software en cada una de las
fases de desarrollo de software.
A.7.5. Elaborar los formatos necesarios para aplicar los puntos por funcin.
Cuestionario de autoevaluacin
1. Cul es la diferencia entre verificar y validar?
2. Cul es la importancia de verificar y validar dentro del desarrollo de
software?
3. Es posible probar todo en el software?
4. Cules seran las limitantes para utilizar los puntos por funcin?
5. Con qu finalidad realizamos las pruebas de software?
100
6. En qu momento se deben de realizar las pruebas de software?
7. Los puntos por funcin se entran en la categora de verificacin o de
validacin?
8. Qu otras actividades se pueden realizar para verificar o validar?
9. Cundo es recomendable dejar de realizar las pruebas de software?
10. Cul es la relacin entre los puntos por funcin y las pruebas de
software?
Examen de autoevaluacin
I. Escribe en el parntesis A si la descripcin corresponde a una herramienta o
B si corresponde a una tcnica de pruebas de software
Descripcin Tipo de recurso
1. ( ) Checklist
a. Herramienta
b. Tcnica
2. ( ) Revisin en pares
3. ( ) Unitarias
4. ( ) Valor lmite
5. ( ) Stress
II. Seleccione una de las opciones y escriba la letra correspondiente en el
parntesis de la derecha de cada pregunta
6. Son las pruebas basadas en especificaciones externas sin el conocimiento
previo de cmo se encuentra construido ( )
a) Pruebas de convivencia
b) Pruebas de caja blanca
c) Pruebas de caja negra
d) Pruebas de compatibilidad
7. Cul es la definicin de Defecto? ( )
a) Es una omisin de algo que debera de estar y no est o la
representacin incorrecta de lo que se ha solicitado.
b) Aparece slo al momento en que se ejecuta.
c) Es el originado por una actividad humana.
d) Es una inconsistencia lgica.
101
8. Cul es la definicin de Verificacin? ( )
a) Asegura que el producto final cumple con las especificaciones
establecidas.
b) Se asegura de que el producto diseado es estructuralmente lgico.
c) Son todas las actividades a travs del ciclo de vida que aseguran que
los productos internos en el proceso cumplan con sus especificaciones.
d) Es la actividad realizada con la ejecucin del programa.
9. Cuntas preguntas comprende el ajuste de complejidad en los puntos por
funcin? ( )
a) 5
b) 6
c) 16
d) 14
10. Es un uso que se le puede dar a los resultados de los puntos por
funcin? ( )
a) Costo por FP
b) Defectos por FP
c) Errores por FP
d) Todas las anteriores
102
TEMA 8. MANTENIMIENTO DE SOFTWARE
Objetivo particular
Al finalizar el tema el alumno habr identificado la importancia del
mantenimiento de software, as como las actividades involucradas alrededor de
esta fase del ciclo de vida de software.
Temario detallado
8.1 De correccin
8.2 De prevencin
8.3 De adaptacin
8.4 De mejora
Introduccin
El mantenimiento de software es una parte dentro del ciclo de vida del
software. En esta fase se realizan actualizaciones, mejoras o correcciones que
no fueron detectadas en las fases anteriores. Se realizan las actividades
necesarias para proporcionar un soporte rentable al software. Segn la norma
ISO/IEC 14764 son cuatro los tipos de mantenimiento: correctivo, adaptacin,
mejora y preventivo.
8.1 De correccin
Mantenimiento correctivo. Son las modificaciones necesarias que se realizan al
software despus de su liberacin para corregir problemas encontrados.
Tambin se emplea cuando el software no satisface los requerimientos
establecidos.
103
8.2 De prevencin
Mantenimiento preventivo. Modificaciones realizadas al software despus de su
liberacin para detectar y corregir defectos potenciales en el software antes de
que se conviertan en fallas.
8.3 De adaptacin
Mantenimiento de adaptacin. Son modificaciones realizadas al software
despus de su liberacin para mantener la utilidad del software ante los
cambios del ambiente. Estas modificaciones no se encuentran en el diseo de
especificaciones. Se incluyen los nuevos requerimientos que incluyen
modificaciones para incluir una nueva interface, sistema o hardware.
8.4 De mejora
Mantenimiento de mejora. Modificaciones realizadas al software despus de su
liberacin para perfeccionar su desempeo y mantenimiento. En l se puede
incluir nuevas funcionalidades para el usuario o una ingeniera inversa para
crear la documentacin faltante o modificar la existente.
Proceso de mantenimiento
El proceso de mantenimiento contiene actividades y tareas especficas que
permiten realizar modificaciones al software sin afectar su integridad. El
proceso abarca la migracin a un nuevo ambiente hasta el retiro del software.
Al proceso se le relacionan seis actividades:
Proceso de implementacin. Se establece el plan y procedimientos que
sern utilizados en el proceso de mantenimiento. El plan de
mantenimiento debe de ser elaborado al mismo tiempo que se realiza el
plan de desarrollo.
104
Anlisis de problemas y modificaciones. Esta actividad se inicia despus
de la transicin del software y es llamado cada vez que se levantan una
necesidad de modificacin.
Implementacin de modificaciones. El encargado del mantenimiento
desarrolla y prueba las modificaciones realizadas al software.
Revisin/aceptacin. Se asegura que las modificaciones sean correctas
conforme a los estndares establecidos y con la metodologa correcta.
Migracin. El encargado deber de establecer las acciones necesarias
para llevar a cabo la migracin hacia un nuevo ambiente y
posteriormente desarrollar y documentar los pasos requeridos para la
migracin.
Retiro. Se emplea cuando el software ha alcanzado el final de su vida
til. Se realiza un anlisis que permita tomar la decisin de retirar el
software. El anlisis puede estar basado en una perspectiva econmica
y puede ser incluida en el plan de retiro. El encargado deber de
determinar las acciones necesarias para realizar el retiro.
Cada una de las actividades cuenta con entradas definidas que son
transformadas por las tareas para producir salidas. Tambin se encuentran
controles y procesos de soporte identificados.
Es importante establecer el proceso de mantenimiento ya que es muy probable
que durante la operacin del sistema se encuentren errores que debern de
corregiste y se presentarn nuevas necesidades que requerirn la modificacin
del software. El objetivo del proceso de mantenimiento es modificar un software
ya existente preservando su integridad. Realizando las actividades
mencionadas se podr reducir de manera significativa los riesgos que conlleva
las modificaciones al software.
Una estrategia de mantenimiento debera de contener los siguientes
elementos:
105
Concepto de mantenimiento. Alcance, vista general del proceso, costos,
responsables.
Plan de mantenimiento. Necesidad, roles, recursos, controles,
capacitacin, actividades y tareas.
Anlisis de recursos. Personal, ambiente y financiero.
Bibliografa del tema 8
ISO/IEEE. Software Engineering - Software Life Cycle Processes -
Maintenance. IEEE std 14764-2006, 2006.
106
Actividades de aprendizaje
A.8.1. Diagramar una de las actividades del proceso de mantenimiento de
software utilizando UML.
A.8.2. Investigar una herramienta de software que pueda utilizarse en el
mantenimiento de software.
A.8.3. Elaborar el formato para el plan de mantenimiento.
A.8.4. Generar un listado con los recursos necesarios en un proceso de
mantenimiento de software.
A,8.5. Conseguir el estndar ISO/IEC 9126 y extraer las mtricas relacionadas
con el mantenimiento de software.
Cuestionario de autoevaluacin
1. Por qu el mantenimiento es considerada una actividad que forma parte
del desarrollo de software?
2. Las modificaciones producidas durante el desarrollo de software son
consideradas como parte del mantenimiento de software?
3. Cul es la importancia del mantenimiento de software?
4. Es posible realizar actividades de mantenimiento sin los antecedentes
previos del proyecto de software?
5. Cul es la diferencia entre el mantenimiento de software y un nuevo ciclo
de desarrollo de software?
6. En qu momento se establece el proceso de mantenimiento de
software?
7. Qu eventos pueden dar inicio a las actividades de mantenimiento de
software?
8. Quin es el encargado de llevar el registro de los cambios realizados por
las actividades de mantenimiento?
9. En todos los proyectos de desarrollo de software se encuentran
presentes las actividades de mantenimiento?
10. En qu momento se finaliza el proceso de mantenimiento de software?
107
Examen de autoevaluacin
I. Seleccione una de las opciones y escriba la letra correspondiente en el
parntesis de la derecha de cada pregunta
1. Es uno de los cuatro tipos de mantenimiento ( )
a) Restauracin
b) Preventivo
c) Desastres
d) Integral
2. Es la definicin del mantenimiento de mejora ( )
a) Son las modificaciones realizadas sobre las funciones del software.
b) Son las modificaciones realizadas en la apariencia del software.
c) Modificaciones realizadas al software despus de su liberacin para
perfeccionar su desempeo y mantenimiento.
d) Son modificaciones realizadas al software despus de su liberacin
para mantener la utilidad del software ante los cambios del ambiente.
3. Cul es el estndar que contiene el proceso de mantenimiento de
software? ( )
a) IEEE14764
b) IEEE 12207
c) ISO/IEC 9126
d) IEEE 610
4. Es una de las actividades del proceso de implementacin ( )
a) Elaborar plan de retiro
b) Capacitacin
c) Realizar pruebas a las modificaciones del software
d) Documentar los pasos para la migracin
5. Es un elemento de la estrategia de mantenimiento ( )
a) Capacitacin
b) Anlisis de recursos
c) Compra de equipo
d) Acondicionamiento de rea de trabajo
108
II. Instrucciones. Escribir en la columna de la derecha la letra V (verdadero) o F
(falso) segn corresponda al enunciado.
No. Enunciado V o F
6. La planificacin del proceso de mantenimiento comienza una vez
que se ha liberado el software.
7. El proceso de mantenimiento de software finaliza con el retiro del
software.
8. Un error del software detectado en el ambiente de produccin es
motivo para iniciar las actividades de mantenimiento.
9. El mantenimiento de software realiza las actividades necesarias
para proporcionar un soporte rentable al software.
10. El mantenimiento de software lleva a cabo las actividades de
registro de todas las modificaciones que se van realizando a cada
una de las liberaciones de software.
109
TEMA 9. ADMINISTRACIN DE LA CONFIGURACIN
Objetivo particular
Al finalizar el tema el alumno podr identificar el papel que realizar la
administracin dentro del desarrollo de software. Conocer las actividades que
podr llevar a cabo con la finalidad de controlar los cambios que se realizan
sobre todos los elementos de un proyecto de software.
Temario detallado
9.1. Proceso de administracin de la configuracin
Introduccin
El cambio es algo normal y en el desarrollo de software esto no es una
excepcin. Pero cada cambio puede conllevar una serie de resultados
indeseables, adems de genera una confusin dentro de las personas
involucradas si no se realiza de manera adecuada, lo que puede derivar en un
caos dentro un proyecto.
9.1. Proceso de administracin de la configuracin
La administracin de la configuracin es una disciplina que aplica las
direcciones tcnicas y administrativas y vigilancia para: identificar y documentar
las caractersticas fsicas y funcionales de un elemento de configuracin,
controlar los cambios de esas caractersticas, registrar y procesar el proceso de
cambios y el estatus de implementacin y verificar el cumplimiento con los
requerimientos especificados.
13
13
IEEE 610.12
110
La configuracin de un sistema son las caractersticas fsicas y/o funcionales
del software o hardware o su combinacin, como un conjunto en
documentacin tcnica y enfocada al producto. Es una coleccin de versiones
especficas de elementos de hardware o software combinado conforma a
especficos procedimientos de construccin para propsitos particulares.
La administracin de la configuracin es la disciplina que identifica la
configuracin de un sistema en distintos puntos en el tiempo con el propsito
de controlar sistemticamente los cambios de configuracin, manteniendo de
esta forma la integridad y el rastreo de la configuracin durante el ciclo de vida.
Administracin de la configuracin de software es un proceso de soporte del
ciclo de vida que beneficia la administracin de proyectos, las actividades de
desarrollo y mantenimiento, las actividades de aseguramiento y a los productos
finales de los usuarios y clientes.
Los elementos de la administracin de la configuracin con todos aquellos que
se generan durante el proceso de software como: cdigo fuente, ejecutables,
documentacin y datos.
Un indicador que puede ayudar a reconocer que las cosas van bien es cuando
cada elemento es registrado para su seguimiento y control, cada cambio
puede ser rastreado y analizado y cuando aquellos que necesitan ser
informados de un cambio se les ha informado.
La administracin de la configuracin se relaciona con las dems reas desde
el momento en que el proceso registra cada artefacto que se produce y se
utiliza a travs del proceso de software.
El estndar ISO/IEC 12207 indica que el proceso de administracin de la
configuracin de software se encarga de establecer y mantener la integridad de
111
los elementos de software de un proceso o un proyecto y hacerlos disponibles.
Para realizarlo se apoya de las siguientes actividades:
Implementacin del proceso. Se desarrolla el plan que describe las
actividades, procedimientos y la programacin para realizar las
actividades, se establecen los responsables y la relacin del proceso
con otras organizaciones. El plan se documenta e implementa.
Identificacin de la configuracin. Se establecen los elementos que
sern controlados. A cada versin y su elemento correspondiente se le
coloca un identificador y se establece una lnea base.
Control de la configuracin. Se encarga de llevar a cabo el seguimiento
al identificar y registrar las solicitudes de cambio, evaluar los cambios,
aprobacin o desaprobacin de los requerimientos, implementaciones,
verificaciones y liberaciones. Seguimiento a las modificaciones, razones
de modificacin y su autorizacin.
Estatus de la configuracin. Es la administracin de reportes de registro
y estados que muestran un histrico controlado de los elementos de
software.
Evaluacin de la configuracin. Se asegura de que exista una relacin
entre el elemento funcional del software contra los requerimientos y los
elementos fsicos.
Administracin de liberacin y entrega. La liberacin y la entrega de los
productos de software deben de encontrarse controlados. Mantener las
copias maestras de cdigo y documentacin. Los elementos crticos son
manejados, almacenados, empacados y entregados conforme a las
polticas establecidas por la organizacin.
En SWEBOK se pueden encontrar actividades asociadas a la administracin de
la configuracin. De las cuales se mencionan las siguientes:
Administracin del proceso de administracin de la configuracin. En ella
se ven involucradas la planificacin y administracin del proceso. Lo que
112
implica una comprensin del contexto de la organizacin, la
identificacin de restricciones y el diseo e implementacin del proceso.
Identificacin de la configuracin de software. En ella se identifican todos
los elementos que debern de ser controlados para establecer una
estructura de identificacin por elemento y versin. Se establecer las
tcnicas y herramientas que se utilizarn para administrar los elementos.
Control de la configuracin de software. Se establece la administracin
de los cambios durante el ciclo de vida del software. Se incluye los tipos
de cambio, autoridades para realizar los cambios, soporte a la
implementacin de cambios.
Registro del estado de la configuracin de software. Es el registro y
reporte de informacin necesaria para una efectiva administracin de la
configuracin de software.
Auditora de la configuracin de software. Es una evaluacin
independiente de la conformidad de los productos de software y el
proceso a regulaciones, estndares, lineamientos, planes y
procedimientos. La auditora determina el grado en el que los elementos
satisfacen los requerimientos funcionales y caractersticas fsicas.
Administracin de liberacin y entrega. Liberar se refiere a la distribucin
de un elemento de configuracin de software fuera de las actividades de
desarrollo. Esto incluye las distribuciones internas y hacia los clientes.
Cuando las diferentes versiones de un mismo elemento se encuentran
disponibles para ser entregadas es necesario generar paquetes de esa
versin con el material correcto. La librera de software es un elemento
importante que acompaa a las tareas de entrega y liberacin.
Mientras para el estndar IEEE 1042 se pueden mencionar las siguientes
actividades a manera de resumen:
Identificacin de la configuracin. Identifica la estructura del producto.
Los niveles de identificacin es la organizacin sobre la que se pueden
identificar los elementos de la configuracin. Posteriormente se
113
establece el identificador o etiqueta con el que se dar seguimiento a los
elementos. Se establece una lnea base de que se tomar como
referencia a todos los elementos.
Control de la configuracin. Se identifica los procedimientos para los
cambios a partir de una lnea base. Se generan niveles de autoridad
para controlar cambios y se asignan las responsabilidades.
Registro del estado de la configuracin. Identifica la informacin
necesaria, su obtencin y reporte.
Auditorias y revisiones. Involucra los procedimientos empleados para
verificar que los productos de software contra la descripcin de los
elementos de configuracin que se encuentra en las especificaciones y
documentos. Las auditorias se orientan hacia las funciones de cambio,
operacin de las libreras y otras actividades relacionadas a la
administracin de la configuracin de software.
Liberacin. Las liberaciones de software deben de estar descritas de
manera de quien lo reciba entienda lo que le ha sido entregado. Esta
actividad se encarga de verificar que el paquete de liberacin se
encuentre completo y listo para el usuario.
Bibliografa del tema 9
IEEE. IEEE Standard Glossary of Software Engineering Terminology. IEEE
Std 610.12-1990, 1990.
ANSI/IEEE. IEEE Guide to Software Configuration Management. Std 1042-
1987, 1987.
ISO/IEC. System and Software Engineering Software Life Cycle Processes.
Std 12207-2008, 2008.
IEEE. Guide to the Software Engineering Body of Knowledge. IEEE Computer
Society SWEBOK, 2004.
114
Actividades de aprendizaje
A.9.1. Conseguir el estndar IEEE 829 y basado en l elaborar el formato de
plan de administracin de la configuracin de software.
A.9.2. Elaborar resumen de los tipos de revisiones descritos por el estndar
IEEE 1028.
A.9.3. Elaborara catlogo de identificadores para elementos de la configuracin
de software.
A.9.4. Diagramar una de las actividades de la administracin de la
configuracin utilizando UML.
A.9.5. Investigar una herramienta de software que pueda utilizarse en la
administracin de la configuracin de software.
Cuestionario de autoevaluacin
1. Qu es la administracin de la configuracin?
2. En qu momento se recomienda utilizar la configuracin de software?
3. A la administracin de la configuracin slo le concierne llevar el cdigo
de software?
4. Qu elementos debe de contener una lnea base?
5. Cundo se establece el proceso de configuracin de software?
6. Qu tipo de modificaciones que requieren llevar un registro?
7. Cul es la importancia de llevar un control de configuracin durante el
proceso de desarrollo de software?
8. De qu manera la configuracin de software garantiza la calidad del
desarrollo de software?
9. Qu tan riguroso debe de ser el registro de los cambios a la
configuracin de software?
10. En qu momento finaliza la configuracin de software?
115
Examen de autoevaluacin
Instrucciones. Seleccione una de las opciones y escriba la letra
correspondiente en el parntesis de la derecha de cada pregunta
1. Qu es la administracin de la configuracin? ( )
a) Es la disciplina que identifica la configuracin de un sistema en
distintos puntos en el tiempo.
b) Es la disciplina que se encarga de aplicar las configuraciones tanto a
equipos clientes como a servidores.
c) Se encarga de elaborar manuales y capacitar al personal que se
encargar de instalar una nueva aplicacin.
d) Se encarga de supervisar que cualquier actualizacin no modifique las
configuraciones del software instalado.
2. Es una de las actividades establecidas por el estndar ISO/IEC 12207 para
la administracin de la configuracin ( )
a) Identificacin de la configuracin
b) Establecer mtricas
c) Generar modelo de negocio
d) Realizar respaldo
3. Es una de las actividades establecidas en SWEBOK para la administracin
de la configuracin ( )
a) Establecer proceso de recuperacin
b) Auditoria de la configuracin de software
c) Inventario de equipos
d) Actualizaciones de software
4. Es una de las actividades establecidas por el estndar IEEE 1042 para la
administracin de la configuracin ( )
a) Documentacin
b) Mantenimiento
c) Capacitacin
d) Liberacin
5. En qu actividad del proceso de configuracin se establece la lnea
base? ( )
a) Liberacin
b) Implantacin del proceso
c) Identificacin de la configuracin
d) Control de la configuracin
116
6. Es la actividad encargada de administrar los reportes de configuracin y de
llevar un histrico. ( )
a) Auditoria
b) Estatus de la configuracin
c) Control de la configuracin
d) Implantacin del proceso
7. De qu elementos se encarga la administracin de la configuracin de
software? ( )
a) Cdigo fuente
b) Documentacin
c) Datos
d) Todas las anteriores
8. En qu actividad del proceso de configuracin de software se establecen
los roles y actividades? ( )
a) Implementacin del proceso
b) Auditoria y revisiones
c) Liberacin
d) Control de la configuracin
9. En qu actividad se lleva a cabo el seguimiento a las modificaciones en el
software? ( )
a) Revisin y auditoria
b) Control de la configuracin
c) Implantacin del proceso
d) Liberacin
10. Es un producto del proceso de configuracin de software ( )
a) Libreras
b) Material de capacitacin
c) Plan de mantenimiento
d) Plan de pruebas
117
TEMA 10 ADMINISTRACIN DE LA CALIDAD
Objetivo particular
Al concluir este tema el alumno entender el papel de la calidad en la
ingeniera del software, as como los modelos ms importantes que los que se
puede apoyarse.
Temario detallado
10.1 Qu es la calidad?
10.2 CMM
10.3 ISO 9000
Introduccin
En la actualidad es posible encontrar modelos de calidad generalmente
aceptados por la industria del software que pueden ser de utilidad. La calidad
puede verse desde diferentes ngulos y cada modelo adoptar alguna de ellas
para desarrollarla.
10.1 Qu es la calidad?
Cada persona puede identificar de alguna forma lo que es la calidad. La calidad
se convierte en un reto al momento de definirla de manera general debido a
que puede ser vista desde muchos puntos de vista. Una vez establecida la
perspectiva de calidad se presenta la tarea de concretarla, lo cual tampoco
resulta fcil, las limitantes y la resistencia al cambio pueden hacerla difcil de
establecerla.
En las siguientes definiciones es posible observar algunos puntos de vista que
se tienen de la calidad:
118
La calidad es cumplir especificaciones. Cero defectos (P. Crosby).
La calidad es el cumplimiento de los propsitos. Adecuacin para el uso
satisfaciendo las necesidades del cliente (J. M. Juran).
La calidad es un grado predecible de uniformidad y fiabilidad a bajo
costo, adecuado a las necesidades del mercado (E. W. Deming).
La calidad es el costo que un producto impone a la sociedad desde el
momento de su concepcin (G. Tagushi).
Por otra parte existen otros cinco tipos de definiciones de calidad:
Definicin trascendental. La calidad es absoluta y universalmente
reconocible sin que pueda definirse por completo.
Definicin basada en el usuario. Se basa en las necesidades de cada
usuario y un producto o servicio es de mayor calidad entre ms cumpla
con las necesidades. Es un punto de vista subjetivo.
Definicin basada en el producto. Es una variable precisa y medible. La
calidad es inherente a las caractersticas del objeto, lo que lo hace
medible.
Definicin basada en la manufactura. La calidad es la conformidad con
las especificaciones. Si el objeto cumple con lo establecido es cuando se
cuenta con un nivel aceptable de calidad. La calidad se adquiere
gradualmente conforme las caractersticas son completadas.
Definicin basada en el valor. La calidad est en relacin con los costos.
Un objeto de calidad ofrece buena ejecucin a un precio aceptable.
Un sistema de aseguramiento de la calidad es una estructura organizacional
con responsabilidades, procedimientos, procesos y recursos para implementar
la administracin de la calidad. Estos sistemas posibilitan a las organizaciones
para que sus productos o servicios satisfagan las expectativas de los clientes
mediante el logro de sus especificaciones.
119
10.2 CMM
Modelo de capacidad de madurez CMM (Capability Maturity Model). Es un
modelo para mejorar el proceso de desarrollo de software.
En 1984, el departamento de defensa de los Estados Unidos de Amrica
establece el SEI (Software Engineering Institute) en la Universidad de Carnegie
Mellon, con la finalidad de encontrar una valoracin de sus contratistas. CMM
signific para el departamento de defensa una mejora en cuanto a los
productos y servicios que empleaba.
Mark Paulk y otros en el SEI crearon el primer modelo de madurez de
capacidad, diseado para organizaciones de desarrollo software. SW CMM
haba sido el principal producto del SEI, liberado en 1991. Este modelo permiti
a las organizaciones a mejorar la eficiencia en el desarrollo de la calidad de los
productos de software.
El modelo de madurez de las capacidades es un modelo de referencia de
prcticas maduras en una disciplina especfica, utilizada para evaluar la
capacidad de los grupos para desempear esa disciplina.
La capacidad del proceso de software describe el rango de resultados
esperados que se obtienen siguiendo un proceso de software.
La madurez del proceso de software es cuando un proceso en especfico es
definido explcitamente, administrado, medido, controlado y es efectivo.
El objetivo de un proceso de software maduro es producir productos de calidad
que cumplan con las especificaciones.
CMM dirige su enfoque a la mejora de procesos en una organizacin, estudia
los procesos de desarrollo y produce una evaluacin de la madurez de la
organizacin segn una escala de cinco niveles:
120
1. Inicial. El proceso de software es un proceso improvisado y catico.
2. Repetible. Se establecen procedimientos de administracin del proceso
que son bsicos para determinar costos, calendarios y funcionalidad.
3. Definido. El proceso de software para las actividades administrativas y
tcnicas se encuentra documentado, estandarizado e integrado dentro de
la organizacin.
4. Administrado. Se recolectan medidas detalladas del proceso de software
y de la calidad del producto. Son cuantitativamente entendidos y
controlados.
5. Optimizado. El mejoramiento continuo del proceso es garantizado por la
retroalimentacin cuantitativa desde el proceso y las pruebas de tcnicas
y herramientas innovadoras.
Los modelos contienen los elementos esenciales de procesos efectivos para
una o ms disciplinas y describen el camino para evolucionar y mejorar desde
procesos inmaduros a procesos disciplinados, maduros con calidad y eficiencia
mejorada y probada.
Debido al xito de SW CMM y a la demanda de modelos en otras reas, el SEI
desarroll otros modelos de CMM, conformados de la siguiente manera:
Systems engineering SE CMM
Integrated product development IPD CMM
Software Acquisition SA CMM
Human resources People CMM
Software SW - CMM
Aunque los modelos haban sido tiles para muchas organizaciones, el uso de
mltiples modelos se haba vuelto problemtico. Muchas organizaciones
queran enfocar sus esfuerzos a travs de diferentes disciplinas. Pero la
diferencia entre cada uno de los modelos, arquitectura, contenido y
acercamiento, limitaban la habilidad de las organizaciones para enfocar sus
121
mejoras de manera exitosa. Aplicar mltiples modelos que no se encontraban
integrados se volva costoso en trminos de capacitacin, valoracin y
actividades de mejora.
CMMI fue elaborado para solucionar el problema de mltiples CMMs. El
objetivo consista en combinar tres modelos:
SW CMM
System engineering capability model (EIA 731)
IPD - CMM
Estos tres modelos fueron seleccionados por su amplia aceptacin y los
diferentes accesos para mejorar procesos en una organizacin. CMMI fue
liberado por el SEI en el 2002.
10.3 ISO 9000
ISO (Internacional Standard Organization) en 1987 a travs de su TC 176 crea
ISO 9000. Describe los elementos de aseguramiento de la calidad de manera
genrica.
ISO 9000 es un conjunto de normas utilizadas como marco para disear,
implantar y certificar sistemas de gestin de calidad. Trata a una organizacin
como a una red de procesos interconectados. Los procesos debern de
encontrarse dirigidas a reas identificadas l y debern de estar documentadas
y practicadas como se menciona.
Se describen de manera general los elementos que conforman al sistema de
aseguramiento de la calidad como: estructura organizacional, procesos,
procedimientos y recursos necesarios. Los modelos muestran el qu pero no
el cmo de cada uno de los elementos.
122
Conjunto de estndares que establecen los requerimientos para la gestin de
los sistemas de calidad. Se realizan revisiones peridicas cada cinco aos.
La ISO es una organizacin mundial no gubernamental, compuesta por
representantes de los organismos de normalizacin nacional, con sede en
Ginebra. Dicha organizacin se articula en comits tcnicos que se encargan
de la elaboracin de las normas internacionales, y dichos comits estn
integrados por miembros de los organismos federados interesados en el objeto
de trabajo de la comisin. Una vez elaborado el proyecto de norma, ste es
enviado a los organismos miembros para su aprobacin, la cual requiere el
voto favorable de al menos dos terceras partes de los organismos miembros
del comit. Tras su aprobacin las normas son difundidas internacionalmente a
travs de los organismos nacionales federados.
Los estndares se aplican para demostrar que se cuenta con un nivel de
experiencia en el diseo y construccin de un producto. Son usadas para
regular la calidad interna y asegurar la calidad de los proveedores.
La familia de normas ISO 9000 fue publicado por primera vez en 1987,
revisado en 1994 y actualizado nuevamente en el ao 2000 (con un
compromiso de ser revisado cada 5 aos).
Dentro de la familia de estndares del ISO 9000 podemos encontrar:
ISO 9000, Fundamentos y vocabulario.
ISO 9001, Requisitos para aseguramiento de la calidad.
ISO 9004, Directrices para la mejora del rendimiento.
ISO 9011, Directrices para la auditora de los sistemas de gestin de la
calidad y/o ambiental.
De los estndares del ISO 9000, el ISO 9001 tambin puede ser aplicado a las
actividades relacionadas con el software. La presentacin del ISO 9001:2000
es general, pero existe una interpretacin se encuentra en el ISO 9000-3, que
123
es una gua para las organizaciones en la aplicacin del ISO 9001:2000 para
adquisicin, abastecimiento, desarrollo, operacin y mantenimiento de software
y servicios de soporte relacionados.
La norma ISO 9001:2000 puede utilizarse para cualquier tipo de industria por
su carcter genrico. Es un enfoque de gestin de calidad basada en
procesos. Este enfoque facilita la ejecucin y gestin de actividades, as como
ciclos de mejora continua siguiendo el principio planificar-ejecutar-verificar-
actuar (PDCA por sus siglas en ingls). El flujo de la informacin generada por
las mediciones son proporcionadas a los responsables de tomar decisiones y
corregir planes. ISO 9001 se centra en la eficacia del sistema de gestin de la
calidad para dar cumplimiento a los requisitos del cliente.
ISO 9001: 2000 Sistema de gestin de calidad requisitos est estructurado
en ocho secciones:
1. Objetivo y campo de aplicacin
1.1 Generalidades
1.2 Aplicacin
2. Referencias normativas
3. Trminos y definiciones
4. Sistema de gestin de calidad
4.1 Requisitos generales
4.2 Requisitos de documentacin
4.2.1 Generalidades
4.2.2 Manual de calidad
4.2.3 Control de registros de la calidad
5. Responsabilidad de la direccin
5.1 Compromiso de la direccin
5.2 Enfoque al cliente
5.3 Poltica de calidad
5.4 Planificacin
124
5.4.1 Objetivos de la calidad
5.4.2 Planificacin del sistema de gestin de calidad
5.5 Responsabilidad, autoridad y comunicacin
5.5.1Responsabilidad y autoridad
5.5.2 Representante de la direccin
5.5.3 Comunicacin interna
5.6 Revisin por la direccin
5.6.1 Generalidades
5.6.2 Informacin para la revisin
5.6.3 Resultados de la revisin
6. Gestin de recursos
6.1 Provisin de recursos
6.2 Recursos humanos
6.2.1Generalidades
6.2.2 Competencia, toma de conciencia y formacin
6.3 Infraestructura
6.4 Ambiente de trabajo
7. Realizacin del producto
7.1 Planificacin de la realizacin del producto
7.2 Procesos relacionados con el cliente
7.2.1 Determinacin de los requisitos relacionados con el producto
7.2.2 Revisin de los requisitos relacionados con el producto
7.2.3 Comunicacin con el cliente
7.3 Diseo y desarrollo
7.3.1 Planificacin del diseo y desarrollo
7.3.2 Elementos de entrada para el diseo y desarrollo
7.3.3 Resultados del diseo y desarrollo
7.3.4 Revisin del diseo y desarrollo
7.3.5 Verificacin del diseo y desarrollo
7.3.6 Validacin del diseo y desarrollo
7.3.7 Control de cambios del diseo y desarrollo
7.4 Compras
125
7.4.1 Proceso de compras
7.4.2 Informacin de las compras
7.4.3 Verificacin de los productos comprados
7.5 Produccin y presentacin del servicio
7.5.1 Control de la produccin y presentacin del servicio
7.5.2 Validacin de los procesos
7.5.3 Identificacin y trazabilidad
7.5.4 Propiedad del cliente
7.5.5 Preservacin del producto
7.6 Control de los dispositivos de seguimiento y medicin
8. Medicin, anlisis y mejora
8.1 Generalidades
8.2 Seguimiento y medicin
8.2.1 Satisfaccin del cliente
8.2.2 Auditora interna
8.2.3 Seguimiento y medicin de los procesos
8.2.4 Seguimiento y medicin del producto
8.3 Control del producto no conforme
8.4 Anlisis de datos
8.5 Mejora
8.5.1 Mejora continua
8.5.2 Accin correctiva
8.5.3 Accin preventiva
Bibliografa del tema 10
Pressman, Roger. Software Engineering: A practitioners approach. New York,
McGraw-Hill, 2001.
Chrissis, Mary Beth. CMM Guidelines for process integration and product
improvement. Mxico, Addison-Wesley, 2003.
126
Actividades de aprendizaje
A.10.1. Generar un listado con diez problemas relacionados a la calidad.
A.10.2. Elaborar un resumen de las caractersticas de calidad presentadas en
el estndar ISO/IEC 9126.
A.10.3. Investigar las diferencias entre el modelo CMM y CMMi.
A.10.4. Investigar y hacer un resumen de un modelo de calidad distinto a los
mencionados por el tema.
A.10.5. Investigar una herramienta de software que se pueda utilizar en la
administracin de la calidad.
Cuestionario de autoevaluacin
1. Qu es la calidad?
2. Cules son las dificultades para definir a la calidad?
3. Qu es el software de calidad?
4. Cules son los principales obstculos para construir software de calidad?
5. Quin establece los criterios de calidad?
6. Es posible abarcar todos los criterios de calidad?
7. Cules son los medios para asegurar la calidad en el software?
8. Por qu es importante construir software de calidad?
9. Cul es el primer paso para adoptar una perspectiva de calidad de
software?
10. Cul es la relacin de la calidad y la ingeniera del software?
127
Examen de autoevaluacin
Instrucciones. Seleccione una de las opciones y escriba la letra
correspondiente en el parntesis de la derecha de cada pregunta
1. Quin menciona que son cinco los tipos de definicin que existen para la
calidad? ( )
a) J. M. Juran
b) Van Genuchten
c) G. Tagushi
d) Roger Pressman
2. De quin es la definicin La calidad es cumplir especificaciones? ( )
a) P. Crosby
b) E. W. Deming
c) Van Genuchten
d) J. M. Juran
3. Es la definicin de calidad basada en el valor ( )
a) Se basa en las necesidades de cada usuario y un producto o servicio
es de mayor calidad entre ms cumpla con las necesidades
b) La calidad es absoluta y universalmente reconocible sin que pueda
definirse por completo
c) La calidad est en relacin con los costos.
d) La calidad es inherente a las caractersticas del objeto, lo que lo hace
medible
4. Qu es la capacidad del proceso de software? ( )
a) Un proceso en especfico es definido explcitamente, administrado,
medido, controlado y es efectivo.
b) Que un proceso se encuentre automatizado
c) Describe el rango de resultados esperados que se obtienen siguiendo
un proceso de software
d) Que un proceso se encuentre alineado a los objetivos de una
organizacin
5. Qu es madurez del proceso de software? ( )
a) Un proceso en especfico es definido explcitamente, administrado,
medido, controlado y es efectivo.
b) Que un proceso se encuentre automatizado
c) Describe el rango de resultados esperados que se obtienen siguiendo
un proceso de software
d) Que un proceso se encuentre alineado a los objetivos de una
organizacin
128
6. De los modelos de CMM cul es el que aplica para el desarrollo de
software? ( )
a) SW - CMM
b) SE - CMM
c) SA CMM
d) IPD CMM
7. CMM es un modelo para ( )
a) Mejorar el desempeo del software
b) Mejorar el proceso de desarrollo de software
c) Dimensionar el tamao de proyectos de software
d) Desarrollar software
8. Es una gua de interpretacin del ISO 9001 para organizaciones con
actividades relacionadas al software? ( )
a) ISO 9004
b) ISO 9000-3
c) ISO 9011
d) ISO 9000
9. Cuntos son los niveles de madurez segn CMM? ( )
a) 5
b) 10
c) 8
d) 4
10. Cuntas secciones tiene el estndar ISO 9001:2000? ( )
a) 5
b) 10
c) 8
d) 4
129
Respuestas de los exmenes de autoevaluacin
INGENIERA DEL SOFTWARE
Tema
1
Tema
2
Tema
3
Tema
4
Tema
5
Tema
6
Tema
7
Tema
8
Tema
9
Tema
10
I. 1. a 1. d 1. v 1. d 1. e 1. b I. 1. a I. 1. b 1. a 1. b
2. a 2. e 2. f 2. b 2. g 2. f 2. a 2. c 2. a 2. a
3. c 3. a 3. f 3. b 3. j 3. i 3. b 3. a 3. b 3. c
4. c 4. f 4. v 4. c 4. h 4. g 4. a 4. c 4. d 4. c
5. a 5. g 5. f 5. d 5. a 5. j 5. b 5. b 5. c 5. a
II.
6. c
6. b 6. v 6. d 6. f 6. h II.
6. c
II.
6. f
6. b 6. a
7. d 7. c 7. v 7. a 7. i 7. d 7. a 7. v 7. d 7. b
8. b 8. h 8. f 8. b 8. b 8. e 8. c 8. v 8. a 8. b
9. e 9. j 9. f 9. a 9. d 9. c 9. d 9. v 9. b 9. a
10. a 10. i 10. f 10. d 10. c 10. a 10. d 10. f 10. a 10. c
.