Upload
arturo-martinez-saenz
View
79
Download
2
Embed Size (px)
Citation preview
Facultad de Ingeniería
Lic. María Elena Chávez Barcés 2012
Manual de Ingeniería de Software
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 2
INTRODUCCIÓN
Nadie duda del tremendo impacto que tiene el software en los negocios y en la
sociedad; éste está inmerso en una enorme gama de aplicaciones tales como: transporte,
telecomunicaciones, procesos industriales, militares, médicos, entretenimiento, productos de
oficina,… la lista es casi interminable.
Para tener éxito al diseñar y construir software necesitamos de una disciplina; es decir, aplicar
un enfoque ingenieril. Ingeniería de Software es considerada como una disciplina emergente,
la cual crece su importancia, se reconoce como valiosa y digna de ser investigada y de recibir
un estudio concienzudo.
Aunque gestores y profesionales reconocen igualmente la necesidad de un enfoque más
disciplinado del software, continúan debatiendo sobre la manera cómo se va a aplicar esta
disciplina. La comunidad del software trata continuamente de desarrollar tecnologías que
hagan más sencillo, rápido y menos costosa la construcción de programas de computadora de
alta calidad. Se han cambiado las actividades y se ha progresado, pero todavía queda mucho
por hacer para que esta disciplina alcance una madurez total.
Organizaciones profesionales internacionales tales como ACM (Association of Computing
Machinery) y la IEEE (Institute for Electrical and Electronics Engineers) han contribuido con
un conjunto de recomendaciones para integrar ingeniería de software en las currículas de las
carreras informáticas de las universidades del mundo.
El contenido del presente manual de la asignatura de Ingeniería de Software (IS) incluye para
este período académico temas como: Introducción a la ingeniería de software presentando
conceptos más importantes; Procesos y métodos convencionales para la ingeniería de
software, mostrando métodos clásicos de análisis, diseño y pruebas del software, Ingeniería de
Requisitos, procesos, técnicas y documentación asociados. Ingeniería de software orientada a
objeto, con los métodos orientados a objetos a lo largo de todo el proceso de software. Diseño
de software y sus procesos, arquitectura del software, diseño orientado a objetos y diseño de
interfaz de usuario. Implementación, reutilización, CBSE. Evolución y mantenimiento.
Verificación y validación, pruebas del software, inspecciones. Gestión de proyectos de
software, planificando, gestionando y controlar un proyecto de desarrollo de software.
Calidad del software, gestión de la calidad, procesos de mejora. Temas avanzados en
ingeniería de software, ingeniería de software basada en componentes, ingeniería de software
cliente/servidor, ingeniería Web, reutilización de software y herramientas CASE.
Es decir, introduce una gran cantidad de temas, nuevas tendencias, herramientas y
metodologías que plantea la ingeniería de software actual y futura.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 3
INDICE
INTRODUCCIÓN A LA INGENIERÍA DE SOFTWARE
1. Introducción
2. El producto software
3. Evolución del software
4. Principios de la Ingeniería del Software
PROCESOS DEL SOFTWARE
1. El proceso del software
2. Modelos de proceso de software genéricos
3. Métodos de desarrollo de software
4. Proceso Unificado Rational (RUP)
5. Procesos de desarrollo ágiles
REQUISITOS DE SOFTWARE
1. Requisitos funcionales y no funcionales
2. Ingeniería de requisitos
MODELADO DEL SISTEMA
DISEÑO DEL SOFTWARE
1. Conceptos y principios de diseño.
2. El proceso de diseño de software
3. Diseño arquitectónico
4. Diseño de la interfaz de usuario
5. Diseño orientado a objetos
DESARROLLO DEL SOFTWARE
1. Desarrollo rápido de software
2. Métodos ágiles de desarrollo
3. Reutilización del software
4. Ingeniería de software basado en componentes
PRUEBAS DEL SOFTWARE
1. Fundamentos de las pruebas
2. Niveles de pruebas
3. Técnicas de pruebas
4. Proceso de pruebas
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 4
5. Diseño de casos de prueba
6. Automatización de pruebas
EVOLUCION DEL SOFTWARE
1. Mantenimientos del software
2. Procesos de evolución
GESTION DE CONFIGURACION
1. Planificación de la gestión de configuración
2. Gestión de cambios
3. Gestión de versiones y entregas
4. Herramientas CASE para gestión de configuración
GESTION DE PROYECTOS DE SOFTWARE
1. Actividades de la gestión de proyectos
2. Planificación del proyecto de software
3. Organización del proyecto
4. Análisis de riesgos
CALIDAD DEL SOFTWARE
1. Calidad del producto
2. Calidad del proceso
3. Planificación de la calidad
4. Control de la calidad
5. Mejora de procesos
6. Procesos CMMI
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 5
INTRODUCCIÓN A LA
INGENIERIA DEL SOFTWARE
1. INTRODUCCIÓN.
En los últimos años los cambios en el hardware han sido notables, y podría parecer que
los cambios en el software han sido igual de significativos. Se ha mejorado notablemente la
capacidad de construir sistemas grandes y complejos y en la construcción de software se
mezclan muchas tecnologías (J2EE, .NET, EJB, SAP, SOAP, SBSE..) desarrollándose
aplicaciones muchas más rápidas.
Los nuevos métodos y técnicas de ingeniería de software han mejorado la construcción de
sistemas grandes y complejos, pero aún, no se ha superado en muchos casos el retraso de los
proyectos y por lo tanto el incremento en su presupuesto, hay una necesidad grande de
educación en ingeniería de software.
En los últimos años el desarrollo más significativo en ingeniería de software ha sido la
aparición del estándar UML para la descripción de sistemas orientados a objetos, y el
desarrollo de métodos ágiles.
2. EL PRODUCTO SOFTWARE.
Cuando se construye hardware, el proceso creativo humano (análisis, diseño,
construcción, prueba) se traduce finalmente en una forma física (chips, tarjetas de circuitos
impresos, fuentes de potencia, etc.). El software es un elemento del sistema que es lógico, en
lugar de físico. Por tanto el software tiene características considerablemente distintas a las del
hardware.
En ambas actividades la buena calidad se adquiere mediante un buen diseño. Ambas
actividades dependen de «personas», pero la relación entre las personas dedicadas y el trabajo
realizado es completamente diferente para el software. Ambas actividades requieren la
construcción de un «producto» pero los enfoques son diferentes. Esto significa que los
proyectos de software no se pueden gestionar como si fueran proyectos de fabricación.
El software se desarrolla, no se fabrica.
Durante su vida, el software sufre cambios. Conforme se hacen los cambios, es bastante
probable que se introduzcan defectos. El mantenimiento del software tiene una complejidad
considerablemente mayor que la del mantenimiento del hardware.
El producto software consiste de diversos programas, archivos de configuración que se
utilizan para ejecutar estos programas, un sistema de documentación que describe la
estructura del sistema y la documentación para el usuario que explica cómo utilizar el
sistema.
El software es abstracto e intangible y puede llegar a ser extremadamente complejo.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 6
Las siguientes áreas del software indican la amplia gama de aplicaciones existentes:
Software de sistemas. Es el conjunto de programas que sirven a otros programas.
Ejemplo: compiladores, editores, utilidades de manejo de periféricos, procesadores de
telecomunicaciones. El software de sistemas se caracteriza por una fuerte interacción
con el hardware de la computadora; utilización por múltiples usuarios; operación
concurrente que requiere planificación, compartición de recursos y una sofisticada
gestión de procesos; unas estructuras de datos complejas y múltiples interfaces
externas.
Software de tiempo real. Software que coordina, analiza, controla sucesos del mundo
real conforme ocurren. Ejemplo: un componente de análisis que transforma la
información según lo requiera la aplicación, un componente de monitorización que
coordina todos los demás componentes, de forma que pueda mantenerse la respuesta
en tiempo real.
Software de gestión. Los sistemas (nóminas, cuentas de haberes, débitos, inventarios,
etc.) han evolucionado hacia el software de sistemas de información de gestión (SIG),
reestructuran los datos existentes para facilitar las operaciones comerciales o gestionar
la toma de decisiones.
Software de ingeniería y científico. Estas aplicaciones van desde la astronomía a la
vulcanología, desde el análisis de la presión de los automotores a la dinámica orbital
de las lanzaderas espaciales y desde la biología molecular a la fabricación automática.
El diseño asistido por computadora (del inglés CAD), la simulación de sistemas y otras
aplicaciones interactivas, han comenzado a coger características del software de
tiempo real e incluso del software de sistemas.
Software empotrado. El software empotrado reside en memoria de sólo lectura y se
utiliza para controlar productos y sistemas de los mercados industriales y de consumo.
Puede ejecutar funciones muy limitadas y curiosas (por ejemplo: el control de las
teclas de un horno de microondas) o suministrar una función significativa y con
capacidad de control (por ejemplo: funciones digitales en un automóvil, tales como
control de la gasolina, etc.).
Software de computadoras personales. El procesamiento de textos, las hojas de
cálculo, los gráficos por computadora, multimedia, entretenimientos, gestión de bases
de datos, aplicaciones financieras, de negocios y personales y redes o acceso a bases
de datos externas son algunas de las aplicaciones.
Software basado en Web. Las páginas Web incorporan instrucciones ejecutables (CGI,
HTML, Perl, o Java), y datos (hipertexto y una variedad de formatos de audio y
visuales). En esencia, la red viene a ser una gran computadora que proporciona un
recurso software casi ilimitado que puede ser accedido por cualquiera.
Software de inteligencia artificial (IA). Hace uso de algoritmos no numéricos para
resolver problemas complejos. Los sistemas expertos, también llamados sistemas
basados en el conocimiento, reconocimiento de patrones (imágenes y voz), redes
neuronales artificiales, prueba de teoremas, y los juegos son aplicaciones de esta
categoría.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 7
El producto software tiene un número de atributos asociados que reflejan su calidad. Estos
atributos no están asociados con lo que hace el software. Más bien, reflejan su
comportamiento durante su ejecución, la estructura y organización del código fuente o puede
reflejarse en la documentación asociada.
Ejemplo: Tiempo de respuesta del software a una consulta del usuario
Comprensión del programa fuente
Los atributos que se esperan de un sistema dependen de su aplicación. Ejemplos, un sistema
bancario se debe esperar que sea seguro, un juego interactivo debe tener capacidad de
respuesta, un interruptor de un sistema telefónico debe ser fiable, etc.
Algunos atributos del software:
Mantenibilidad. El software debe escribirse de tal forma que pueda mantenerse para
cumplir las nuevas necesidades de cambio de los clientes. Este es un atributo crítico
debido a que el cambio en el software es una consecuencia inevitable por los cambios
en las reglas de negocio.
Confiabilidad. La confiabilidad del software tiene un gran número de características:
fiabilidad, protección y seguridad. El software confiable no debe causar daños en caso
de una falla del sistema.
Eficiencia. El software debe hacer mejor uso de los recursos del sistema. La eficiencia
incluye tiempos de respuesta y de procesamiento, utilización de la memoria, etc.
Usabilidad. El software debe ser fácil de usar por el usuario para quien está diseñado.
Esto significa que debe tener una interfaz de usuario apropiada y una documentación
adecuada.
3. EVOLUCIÓN DEL SOFTWARE.
Etapa 1: 1950 – 1965
o Esfuerzo en el desarrollo de Hardware
o Carencia de métodos de desarrollo
o Software a la medida con baja distribución
Etapa 2: 1965 – 1976
o Masificación de software en empresas
o Software de gran extensión
o Problemas de mantenimiento
o Inicio de las casas de software
o CRISIS DEL SOFTWARE
Etapa 3: 1976 – 1989
o Hardware a bajo costo.
o Popularización de los computadores personales.
o Grandes inversiones en desarrollo de software.
Etapa 4: 1989 - …
o Incremento de la demanda de software.
o Se agudiza la crisis del software: mantenimiento.
Algunas referencias útiles para comprender cuales eran los conocimientos estables para el
desarrollo de software:
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 8
En 1962 se publicó el primer algoritmo para búsqueda binaria.
En 1966, C.Bohm y G.Jacopini publicaron el documento que creaba una fundación
para la eliminación de “go to” y la creación de la programación estructurada.
En 1968, los programadores se debatían entre el uso de la sentencia GoTo, y la nueva
idea de programación estructurada, ese era el caldo de cultivo en que Edsger Dijkstra
escribió su famosa carta “GoTo Statement Considered Huarmful”.
La primera publicación sobre programación estructurada no vio la luz hasta 1974,
publicada por Larry Constantine, Glenford Myers y Wayne Stevens.
En 1977, el primer libro sobre métrica de software por Tom Gilb.
En 1979, el primer libro sobre análisis de requisitos.
Libros publicados durante los años 70 y 80 proporcionan una visión histórica útil dentro de la
percepción cambiante de las computadoras y del software, y de su impacto en nuestra cultura.
Enormes mejoras en rendimiento del hardware, profundos cambios de arquitecturas
informáticas, grandes incrementos de memoria y capacidad de almacenamiento y una gran
variedad de opciones de entrada y salida han conducido a sistemas más sofisticados y más
complejos basados en computadora. El software ha sufrido cambios significativos durante un
periodo de tiempo superior a los 50 años.
La sofisticación y la complejidad del software pueden producir resultados deslumbrantes
cuando un sistema tiene éxito, pero también pueden suponer grandes problemas para aquellos
que deben construir dichos sistemas.
Es decir, sin software complejo no habríamos explorado el espacio, no tendríamos Internet y
telecomunicaciones modernas y todas las formas de viajar serían más peligrosas y caras. Hoy
en día, «la computación omnipresente» ha producido una generación de aplicaciones de
información que tienen conexión en banda ancha a la Web para proporcionar «una capa de
conexión sobre nuestras casas, oficinas, y autopistas». El papel del software continúa su
expansión.
CRISIS DEL SOFTWARE
En 1968, la OTAN (Organización del Tratado del Atlántico Norte) realizó una conferencia
con el fin de resolver los problemas que surgieron en el desarrollo de sistemas software, el
cual denominaron “crisis del software”. En la misma conferencia se utilizó por primera vez el
término “ingeniería de software” para describir el conjunto de conocimientos que existía en
aquel estado inicial.
Hay varias razones que pueden ser propuestas como causa de la crisis. No son mutuamente
excluyentes; de hecho, es posible que la verdadera causa sea una mezcla de todas ellas. Las
causas de la crisis del software fueron vinculadas a la complejidad en general del proceso de
desarrollo y a la relativa inmadurez de la ingeniería de software como una profesión. Las
raíces de la crisis del software son complejas y variables.
Algunos síntomas que indican que el software se encuentra en un período de crisis son:
Tiempo y presupuesto excedido.
El software a menudo no satisfacía los requisitos deseados.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 9
Baja calidad del software.
Confiabilidad cuestionable.
Proyectos inmanejables, con código difícil de mantener.
Altos requisitos de personal para el desarrollo y mantenimiento.
Para poder llevar el estado del proceso de software como un estado de crisis, los críticos han
destacado ciertas características que han permitido esta postura del software respecto a otras
etapas de su corta historia. Algunos de estos factores son:
Aumento del poder computacional
Reducción del costo del hardware.
Rápida obsolescencia de hardware y software.
Aceptación de la computarización en las empresas.
Incremento en el número de usuarios de los sistemas de software.
Tipo de usuario no homogéneo aun en sistemas hechos a medida.
Personal diferente para el desarrollo y el mantenimiento.
No existen todavía herramientas que permitan estimar de una manera exacta, antes de
comenzar el proyecto, cuál es el esfuerzo que se necesitará para desarrollar un programa. Este
hecho provoca que la mayoría de las veces no sea posible estimar cuánto tiempo llevará el
proyecto, ni cuánto personal será necesario.
CASOS DE ESTUDIO
Caso de Estudio: F-18 (1986)
En abril de 1986 un avión de combate F-18 se estrelló por culpa de un giro descontrolado,
atribuido a una expresión “if-then”, para la cual no había una expresión “else”, por
considerarse innecesaria, lo que originó una excepción fuera de control del programa. Por
suerte el piloto pudo salir del avión a tiempo.
Caso de estudio: Therac-25
Diseñado para tratamiento de pacientes por medio de rayos X. Entre 1985-1987 ocasiono la
muerte de varios pacientes en hospitales de USA, por culpa de radiaciones de alto poder
aplicadas de manera incontrolada. La probable causa era que para ciertas secuencias de
comandos, los controles de la computadora llevaban la máquina a un estado interno erróneo y
muy peligroso generando una sobredosis masiva de radiación al paciente. No se hacían
revisiones sobre prácticas de desarrollo de software, ni control de calidad del software en
dispositivos médicos
Caso de Estudio: Sistema AEGIS (1988)
El 3 de julio de 1988, en el golfo pérsico, el USS Vincennes derribó un jet de pasajeros iraní
que confundió con una aeronave iraní hostil. El capitán de la nave ordenó el lanzamiento de
un misil provocando la muerte de los 290 tripulantes. Se consideró como causa del accidente
el sistema de radar AEGIS.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 10
EXPERIENCIAS
Fuente: Extreme Chaos. The Standish Group International. Inc. 2000-2004 Research Reports.
Este gráfico demuestra el resultado de 30,000 proyectos de desarrollo de aplicaciones en
empresas de todo tamaño en Estados Unidos medido por The Standish Group desde 1994.
MITOS DEL SOFTWARE
MITOS DE GESTIÓN:
Siempre lo hemos hecho así y funciona bien: resistencia al cambio
MITOS DEL CLIENTE:
El software lo hará TODO
Hay cosas que no hay que decir, el analista debe suponerlas
Los detalles se dejan para el final
MITOS DE DESARROLLADORES:
Los métodos no sirven
Lo único importante es el código
El proyecto termina con el desarrollo del software (…y la documentación y el
mantenimiento qué?)
4. PRINCIPIOS DE LA INGENIERÍA DEL SOFTWARE.
La noción de ingeniería de software fue propuesta inicialmente en 1968 en una
conferencia para discutir lo que en ese entonces se llamó la “crisis del software”. La
experiencia demostró que no era muy bueno un ENFOQUE INFORMAL para el desarrollo
del software. Los grandes proyectos tenían años de retraso, costaban más de lo presupuestado,
irrealizables, difíciles de mantener y con un pobre desempeño. El desarrollo de software
estaba en crisis. Se necesitaban nuevas técnicas y métodos para controlar la complejidad
inherente a los sistemas grandes. Estas técnicas han llegado a ser parte de la ingeniería del
software y son ampliamente utilizadas. Veamos algunas definiciones:
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 11
Ingeniería del Software trata del establecimiento de los principios y
métodos de la ingeniería a fin de obtener software de modo rentable que sea
fiable y trabaje en máquinas reales.
(Bauer, 1971).
Ingeniería del Software es la aplicación práctica del conocimiento científico
en el diseño y construcción de programas de computadora y la
documentación asociada requerida para desarrollar, operar y mantenerlos.
Se conoce también como desarrollo de software o producción de software
(Bohem, 1976).
La Ingeniería de Software es la aplicación de un enfoque sistemático,
disciplinado y cuantificable al desarrollo, operación y mantenimiento del
software (IEEE, 1993).
La Ingeniería de Software es una disciplina de la ingeniería que comprende todos los
aspectos de la producción de software de calidad. Involucra actividades como gestión de
proyectos de software, procesos técnicos de desarrollo de software, herramientas, métodos y
teorías de apoyo; tiene un enfoque sistemático, organizado y más efectivo.
Ingeniería consiste en seleccionar el método más apropiado para un conjunto de
circunstancias. Ejemplo, un enfoque de desarrollo apropiado para el desarrollo de sistemas
basados en Web requerirá una mezcla de técnicas de software y de diseño gráfico. Por tanto,
necesitaremos una diversidad de enfoques al desarrollar software debido a la amplia
diversidad de tipos de sistemas y organizaciones que requieren estos sistemas.
Se puede afirmar que se han hecho enormes progresos desde 1968 y que el desarrollo de la
ingeniería de software ha mejorado considerablemente el software. Comprendemos mucho
mejor de las actividades involucradas en el desarrollo de software. Se han desarrollado
métodos efectivos de análisis, especificación, diseño, desarrollo, pruebas y mantenimiento del
software. Las nuevas notaciones y herramientas reducen el esfuerzo requerido para producir
sistemas grandes y complejos.
Capas de la Ingeniería de Software
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 12
La ingeniería de sistemas es más antigua que la ingeniería del software, se refiere a todos los
aspectos del desarrollo y de la evolución de sistemas complejos donde el software desempeña
un papel principal. La ingeniería de sistemas comprende el desarrollo de hardware, políticas y
procesos de diseño y distribución de sistemas, así como la ingeniería de software.
Disciplinas involucradas en la Ingeniería de Sistemas
RETOS FUNDAMENTALES QUE AFRONTA LA INGENIERIA DEL SOFTWARE
En el siglo XXI, la ingeniería del software afronta tres retos fundamentales:
1. El reto de la heterogeneidad. Desarrollar técnicas para construir software confiable,
flexible que integren software nuevo con sistemas heredados escritos en diferentes
lenguajes de programación, requerido para sistemas distribuidos que incluyen
diferentes tipos de computadoras y con diferentes clases de sistemas de soporte.
2. El reto de la entrega. Es reducir los tiempos de entrega para sistemas grandes y
complejos sin comprometer la calidad del sistema.
3. El reto de la confianza. Es importante que el software sea confiable, ejemplo en
sistemas remotos a los que se accede a través de páginas Web o de interfaces de
servicios Web. El reto de la confianza es desarrollar técnicas que demuestren que los
usuarios pueden confiar en el software.
Estos retos no son independientes, por ejemplo, es necesario hacer rápidos cambios en
sistemas heredados para proveerlos en una interfaz de servicio Web. Para tratar estos retos
necesitaremos nuevas herramientas y técnicas, así como formas innovadoras de combinación
y uso de métodos de ingeniería del software existentes.
RESPONSABILIDAD PROFESIONAL Y ETICA
La ingeniería del software se lleva a cabo dentro de un marco legal y social que limita la
libertad de los ingenieros. Los ingenieros de software deben aceptar que su trabajo comprende
responsabilidades más amplias que simplemente la aplicación de habilidades técnicas. Deben
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 13
comportarse de una forma ética y moral responsable si es que desean ser respetados como
profesionales.
Estándares de comportamiento:
1. Confidencialidad. Respetar la confidencialidad de sus empleadores o clientes.
2. Competencia. No deben falsificar su nivel de competencia, ni aceptar conscientemente
trabajos que están fuera de su capacidad.
3. Desarrollo de propiedad intelectual. Se debe asegurar que la propiedad intelectual de
los empleadores y clientes está protegida.
4. Uso inapropiado de las computadoras. El uso inapropiado de las computadoras va
desde los relativamente triviales (utilizar juegos en la máquina de un empleado, por
ejemplo) hasta los extremadamente serios (difusión de virus).
Organizaciones como la ACM (Association for Computing Machinery), IEEE (Instituto de
Ingenieros Eléctricos y Electrónicos) y la British Computer Society han publicado un código
de conducta profesional o de ética. Este código de conducta generalmente se refiere al
comportamiento ético fundamental.
Los ingenieros de software deben comprometerse consigo mismos para hacer del análisis, la
especificación, el diseño, el desarrollo, las pruebas y el mantenimiento del software una
profesión beneficiosa y respetada. En concordancia con su compromiso con la salud, la
seguridad y el bienestar del público, los ingenieros de software deben adherirse a los
siguientes ocho principios:
1. PÚBLICO – Los ingenieros deberán actuar en consonancia con el interés público.
2. CLIENTE Y EMPLEADOR – Los ingenieros de software deberán actuar de forma que
respondan a los intereses de sus clientes y empleadores siendo consecuentes con el
interés público.
3. PRODUCTO – Los ingenieros de software deberán asegurar que sus productos y las
modificaciones asociadas cumplan los más altos estándares profesionales posibles.
4. JUICIO – Los ingenieros de software deberán mantener la integridad e independencia en
sus juicios profesionales.
5. GESTION – Los gerentes y líderes ingenieros de software deberán suscribir y
promocionar un enfoque ético en la gestión del desarrollo y mantenimiento del software.
6. PROFESIÓN – Los ingenieros de software deberán mantener la integridad y reputación
de la profesión de acuerdo con el interés público.
7. COLEGAS – Los ingenieros de software deberán ser imparciales y apoyar a sus colegas.
8. PERSONAL – Durante toda su existencia, los ingenieros de software deberán aprender
lo concerniente a la práctica de su profesión y promocionar un enfoque ético en la
práctica de su profesión.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 14
PROCESOS DEL SOFTWARE
1. EL PROCESO DEL SOFTWARE.
El proceso del software incluye todas las actividades que conducen a la creación de
un producto software. Son parte del proceso del software, las actividades de alto nivel de
especificación del software, el desarrollo, la validación y la evolución. Estas actividades
pueden consistir en el desarrollo de software desde cero en un lenguaje de programación
estándar, java o C.
No existe un proceso ideal, diferentes tipos de sistemas necesitan diferentes procesos de
desarrollo. Por tanto, las actividades pueden organizarse de diferentes formas y describirse en
diferentes niveles de detalle para diferentes tipos de software. Para sistemas de negocios con
requisitos rápidamente cambiantes probablemente sea más efectivo un proceso flexible y ágil.
Sin embargo, el uso de un proceso inadecuado del software puede reducir la calidad o la
utilidad del producto de software que se va a desarrollar y/o incrementar los costos de
desarrollo.
Los procesos de software pueden ser mejorados estandarizando el proceso, donde sea reducida
la diversidad de los procesos de software en una organización. La estandarización es un
primer paso para introducir nuevos métodos, técnicas y buenas prácticas de ingeniería de
software.
La tecnología CASE se utiliza para ayudar a las actividades del proceso del software
2. MODELOS DE PROCESO DE SOFTWARE GENÉRICOS.
Un modelo de proceso de software es una representación abstracta, describe en forma
simplificada pero no definitiva el proceso. Cada modelo de proceso representa un proceso
desde una perspectiva particular y así proporciona solo información parcial sobre este proceso.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 15
Puede incluir actividades que son parte del proceso, productos de software y el papel de las
personas involucradas en la ingeniería del software.
La mayor parte de los modelos de procesos del software se basan en uno de los tres modelos
generales o paradigmas de desarrollo de software:
1. El enfoque en cascada o ciclo de vida del software. Las actividades son consideradas
como etapas separadas, la especificación de requisitos, el diseño del software, la
implementación, las pruebas, etc. Después de que cada etapa queda definida el
desarrollo continúa con la siguiente etapa. Las principales etapas:
Definición de requisitos. Se extrae a detalle a través de entrevistas a los usuarios los
requisitos del sistema.
Análisis y Diseño del software. Se establece una arquitectura completa del sistema. El
diseño del software identifica y describe las abstracciones fundamentales del sistema
software y sus relaciones. El diseño del software se lleva a cabo como un conjunto de
unidades de programas.
Implementación y prueba de unidades. La prueba de unidades implica verificar que cada
una cumpla su especificación.
Integración y pruebas del sistema. Las unidades se integran y se prueban como un
sistema completo para asegurar que se cumplan los requisitos del software.
Operación y mantenimiento. El sistema se instala y se pone en funcionamiento. Se
efectúan mejoras en la implementación de las unidades del sistema y resaltan los
servicios del sistema una vez que se descubren nuevos requisitos.
El ciclo de vida del software
En el modelo en cascada no se empieza la fase siguiente hasta que la fase previa haya
finalizado. Las ventajas del modelo de cascada son que la documentación se produce en
cada fase. Se hace compromisos en las etapas iníciales lo que es difícil responder a los
cambios en los requisitos del proyecto.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 16
Por lo tanto, el modelo en cascada solo se debe utilizar cuando los requisitos se
comprendan bien y sea improbable que cambie durante el desarrollo del sistema.
2. Desarrollo evolutivo. Este enfoque entrelaza las actividades de especificación,
desarrollo y validación. Se desarrolla rápidamente un sistema inicial a partir de
especificaciones muy abstractas. Este se refina basándose en las peticiones del cliente
para producir un sistema que satisfaga las necesidades. El sistema puede entonces ser
entregado.
Un enfoque evolutivo para el desarrollo del software suele ser más efectivo que el
enfoque de cascada, ya que satisface las necesidades inmediatas de los clientes. La
ventaja de un proceso de software que se basa en un enfoque evolutivo es que la
especificación se puede desarrollar por incrementos. Suele trabajar mejor en sistemas
pequeños y medianos de tamaño.
Los problemas del desarrollo evolutivo se hacen particularmente agudos para sistemas
grandes y complejos con un periodo de vida largo, donde equipos diferentes desarrollan
partes del sistema distintas. Para sistemas grandes se recomienda un proceso mixto que
incorpore las mejores características del modelo en cascada y del desarrollo evolutivo.
Desarrollo evolutivo
3. Ingeniería de software basada en componente (CBSE). Esta técnica supone que
existan las partes del sistema. El proceso de desarrollo del sistema consiste en la
integración de estas partes más que desarrollarlas desde el principio. Este enfoque
basado en la reutilización se compone de una gran base de componentes software
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 17
reutilizable y de algunos marcos de trabajo de integración de estos. Las siguientes etapas
son:
Ingeniería del software basada en componentes
Análisis de componentes. Se buscan los componentes necesarios para proporcionar parte
de la funcionalidad requerida.
Modificación de requisitos. Se analizan los requisitos y se modifican los componentes.
Si no se pueden modificar se buscan soluciones alternativas.
Diseño del sistema con reutilización. Se diseña o se reutiliza un marco de trabajo para el
sistema que satisfaga los requisitos, sino se tendrá que diseñar un nuevo software.
Desarrollo e integración. Se desarrolla el software que no se pueda adquirir y se
integran los componentes, esta no es una actividad separada.
La ingeniería del software basado en componentes tiene la ventaja obvia de reducir la
cantidad de software a desarrollarse y así reduce los costos y los riesgos. También
permite una entrega más rápida del software.
La ingeniería del software basado en componentes tiene mucho en común con un
enfoque que está surgiendo para el desarrollo de sistemas que se basa en la integración
de servicios web de una serie de proveedores.
La distribución de costos a través de las actividades depende del proceso utilizado y del tipo
de software que se vaya a desarrollar, no existe una respuesta sencilla. Ejemplo, el software de
tiempo real requiere de validación y pruebas extensas que los sistemas basados en Web. Cada
uno de los enfoques de desarrollo de software tiene un perfil de distribución de costos
diferente a través de las actividades del proceso.
En el enfoque en cascada, los costos se miden en forma separada, es decir los costos de
especificación, diseño, implementación e integración (notar que integración y pruebas del
sistema son las actividades más caras, alrededor del 40% del costo de desarrollo total).
Si el software se desarrolla utilizando un enfoque iterativo, la especificación, el diseño, la
implementación, la integración y las pruebas se llevan en paralelo dentro de una actividad de
desarrollo. Una vez que la implementación inicial esté completa se necesita una actividad
independiente de pruebas del sistema.
La ingeniería de software basada en componentes ha sido utilizada durante un corto
período de tiempo. Los costos de desarrollo se reducen a costos de integración y pruebas y
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 18
estos se incrementan porque tenemos que asegurarnos de que los componentes que utilizamos
cumplen realmente su especificación y funcionan como se espera.
Además existen costos asociados a cambios que se le hacen al software una vez que está en
uso.
Esta distribución de costos se cumple para el software personalizado, el cual es especificado
por un cliente y desarrollado por un contratista. Para productos de software que se venden
para PCs, el perfil del costo es diferente, comúnmente se desarrollan a partir de una
especificación inicial utilizando un enfoque de desarrollo evolutivo. Sin embargo, debido que
se pretende utilizar en diferentes configuraciones, deben ser probados a fondo.
ITERACIÓN DE PROCESOS
Los modelos de iteración de procesos presentan el proceso de software como un ciclo de
actividades. La ventaja de este enfoque es que evita compromisos prematuros con una
especificación o diseño. Ejemplos de este tipo de modelos son el desarrollo incremental y el
modelo en espiral.
Para hacer más manejable un proyecto se divide en ciclos. Para cada ciclo se establecen fases
de referencia, cada una de las cuales debe ser considerada como un mini-proyecto, cuyo
núcleo fundamental está constituido por una o más iteraciones de las actividades principales
básicas de cualquier proceso de desarrollo.
Desarrollo iterativo
1. La entrega incremental. La especificación, el diseño y la implementación del software
se divide en una serie de incrementos, los cuales se desarrollan por turnos.
La entrega incremental es un enfoque intermedio que combina las ventajas de estos
modelos. En un proceso de desarrollo incremental, los clientes identifican a grandes
rasgos, los servicios que proporcionará el sistema. Identifican que servicios son las más
importantes y cuales menos. Entonces, se definen varios incrementos en donde cada uno
proporciona un subconjunto de la funcionalidad del sistema.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 19
Una vez que un incremento se completa y se entrega los clientes pueden ponerlo en
servicio. Esto significa que tienen una entrega temprana de parte de la funcionalidad del
sistema. Tan pronto como se completen los nuevos incrementos, se integran en los
existentes de tal forma que la funcionalidad del sistema mejora con cada incremento
entregado.
Este proceso de desarrollo incremental tiene varias ventajas:
Los clientes no tiene que esperar que el sistema está completo.
Los clientes pueden utilizar los incrementos iníciales como prototipo.
Existe un bajo riesgo de fallo del proyecto.
Se harán más pruebas a los servicios importantes del sistema.
Sin embargo, existen algunos problemas en el desarrollo incremental. Los incrementos
deben ser relativamente pequeños y cada uno debe entregar alguna funcionalidad del
sistema.
Modelo incremental
2. Desarrollo en espiral. El desarrollo del sistema gira en espiral hacia a fuera,
empezando con un esbozo inicial y terminando con el desarrollo final del mismo.
Cada ciclo en la espiral representa una fase del proceso del software. Así, el ciclo más
interno podría referirse a la viabilidad del sistema, el siguiente ciclo a la definición de
requisitos, el siguiente ciclo al diseño del sistema y así sucesivamente.
Cada ciclo de la espiral se divide en cuatro sectores:
Definición de objetivos específicos. Se identifican las restricciones del proceso y el
producto y se traza un plan detallado de gestión. Se identifican los riesgos del proyecto.
Evolución y reducción de riesgos. Un análisis detallado de los riesgos identificados del
proyecto. Pasos para reducir dichos riesgos.
Desarrollo y validación. Después de la evaluación de riesgos, se elige un modelo para el
desarrollo del sistema. Por ejemplo, si los riesgos en la interfaz de usuario son
dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos
evolutivos. El modelo en cascada puede ser el más apropiado para el desarrollo si el
mayor riesgo identificado es la integración de los subsistemas.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 20
Planificación. El proyecto se revisa y se toma la decisión de si se debe continuar con un
ciclo posterior de la espiral.
Un ciclo de la espiral empieza con la elaboración de objetivos, como el rendimiento y la
funcionalidad. Entonces se enumeran formas alternativas de alcanzar estos objetivos y
las restricciones impuestas en cada una de ellas. Cada alternativa se evalúa contra cada
objetivo y se identifican las fuentes de riesgo del proyecto.
Modelo en espiral
La esencia del proceso iterativo es que la especificación se desarrolla junto con el software.
En el enfoque incremental, no existe una especificación completa del sistema hasta que se
especifica el incremento final.
3. METODOS DE DESARROLLO DE SOFTWARE.
Los métodos son formas organizadas de producir software. Incluyen sugerencias que
se debe seguir para el proceso, la notación que se va a utilizar, los modelos del sistema que
hay que desarrollar, las reglas que gobiernan estos modelos y las pautas de diseño.
El método de desarrollo es un enfoque estructurado cuyo propósito es facilitar la producción
de software de alta calidad de una forma costeable. El primer método desarrollado en los 70’s
fue el Análisis Estructurado. Estos métodos intentaron identificar los componentes
funcionales básicos de un sistema, de tal forma que aún se utilizan ampliamente los métodos
orientados a funciones. En los años 80’s y 90’s estos métodos orientados a funciones fueron
complementados por Métodos orientados a objetos, como los propuestos por Booch y
Rumbaugh, estos enfoques se integraron en uno unificado basado en el Lenguaje de
Modelado Unificado (UML).
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 21
No existe un método ideal, y los diferentes métodos son aplicables en distintas áreas. Son
aplicados a menudo los métodos orientados a objetos a sistemas interactivos, pero no a
sistemas con requisitos rigurosos de tiempo real.
En la actualidad todos los métodos vienen con tecnología CASE asociada, como los editores
para las notaciones utilizadas en el método, módulos de análisis que verifican el modelo del
sistema según las reglas del método y generadores de informes que ayudan a crear la
documentación del sistema. Las herramientas CASE también incluyen un generador de código
que automáticamente genera código fuente a partir del modelo del sistema y de algunas guías
de procesos para los ingenieros de software.
HERRAMIENTAS CASE.
Herramienta CASE (Ingeniería del Software Asistida por Computadora) es el nombre que se
le da al software que se utiliza para ayudar a las actividades del proceso del software como la
ingeniería de requisitos, el diseño, el desarrollo de programas y las pruebas. Se introdujeron en
los años 80 y 90. Las herramientas CASE incluyen editores de diseño, diccionarios de datos,
compiladores, depuradores, herramientas de construcción de sistemas, proporcionando
información acerca del software de desarrollo, etcétera. Actualmente, la tecnología CASE está
madura y hay herramientas y bancos de trabajo de un amplio rango de proveedores están
disponibles.
Se describen tres perspectivas de clasificación:
Una perspectiva funcional. Se clasifica la herramienta CASE de acuerdo con su función
específica.
Una perspectiva de proceso. Se clasifica de acuerdo con las actividades del proceso que
ayudan.
Una perspectiva de integración. Se clasifica de acuerdo con la forma en que están organizadas
en unidades integradas que proporcionan ayuda a una o más actividades del proceso.
Tipo de herramienta Ejemplos
Herramientas de planificación Herramientas PERT, herramientas de estimación,
hojas de cálculo.
Herramientas de edición Editores de texto, editores de diagramas,
procesadores de texto.
Herramientas de gestión de cambio Herramientas de rastreo de requisitos, sistemas de
control de cambios.
Herramientas de gestión de
configuración
Sistema de gestión de versiones, herramientas de
construcción de sistemas.
Herramientas de construcción de
prototipos
Lenguajes de muy alto nivel, generadores de
interfaz de usuario.
Herramientas de apoyo a métodos Editores de diseño, diccionarios de datos,
generadores de código.
Herramientas de procesamiento de Compiladores, intérpretes.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 22
lenguajes
Herramientas de análisis de
programas
Generadores de referencias cruzadas, analizadores
estáticos, analizadores dinámicos.
Herramientas de pruebas Generadores de pruebas de datos, comparadores de
archivos.
Herramientas de depuración Sistemas de depuración interactiva.
Herramientas de documentación Programas de diseño de páginas, editores de
imágenes.
Herramientas de reingeniería Sistemas de referencias cruzadas, sistemas
reestructuración de programas.
Clasificación funcional de las herramientas CASE
4. PROCESO UNIFICADO RATIONAL (RUP).
El Proceso Unificado de Rational (RUP) es un modelo de proceso moderno y genérico
asociado al Proceso Unificado de Desarrollo de Software (1999). Reúne elementos de todos
los modelos de procesos genéricos, iteraciones de apoyo e ilustra buenas prácticas en la
especificación y el diseño.
Describe tres perspectivas:
1. Una perspectiva dinámica que muestra las fases del modelo sobre el tiempo.
2. Una perspectiva estática que muestra las actividades del proceso.
3. Una perspectiva práctica que sugiere buenas prácticas a utilizar durante el proceso.
RUP Rational Unifield Process
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 23
PERSPECTIVA DINÁMICA
RUP identifica cuatro fases diferentes en el proceso de software, las fases están mucho más
relacionadas con asuntos de negocio más que técnicos.
1. Inicio. Se establece un caso de negocio del sistema. Se identifica todas las actividades
externas que interactúan en el sistema y define estas interacciones. Esto se utiliza para
evaluar la aportación que el sistema haría al negocio.
2. Elaboración. Se desarrolla la comprensión del dominio del problema, se establece un
marco de trabajo arquitectónico, desarrolla el plan del proyecto e identifica los riesgos.
Al terminar esta fase, se debe tener un modelo de los requisitos del sistema (se
especifican los casos de uso UML), una descripción arquitectónica y un plan de
desarrollo del software.
3. Construcción. Comprende el diseño del sistema, la programación y las pruebas.
Durante esta fase se desarrollan e integran las partes del sistema. Al terminar se debe
tener un software operativo y la documentación para el usuario.
4. Transición. Se ocupa de mover el sistema desde la comunidad de desarrollo a la
comunidad del usuario y hacerlo trabajar en un entorno real. Se debe tener al terminar
un sistema documentado que funcione correctamente en su entorno operativo.
Cada fase se puede representar de un modo iterativo como los resultados desarrollados
incrementalmente.
PERSPECTIVA ESTATICA
Se centra en las actividades que tienen lugar durante el proceso de desarrollo. Se denominan
flujos de trabajo. Existen seis principales flujos de trabajo del proceso identificados y tres
principales flujos de trabajo de soporte.
RUP fue diseñado conjuntamente con UML (Lenguaje de Modelado Unificado)
Flujo de Trabajo Descripción
Modelado del negocio Se modelan los procesos de negocio utilizando casos de uso de
negocio.
Requisitos Para modelar los requisitos del sistema se desarrollan los casos de
uso y se definen los actores que interactúan con el sistema.
Análisis y Diseño Se crea y documenta el modelo de diseño (arquitectónico,
componentes, objetos y de secuencia).
Implementación Generación del código.
Pruebas
Las pruebas se llevan a cabo conjuntamente con la implementación
es un proceso iterativo. Al finalizar se efectúan las pruebas del
sistema y aceptación.
Despliegue Se crea una versión del producto, se distribuye al usuario
instalándose en su lugar de trabajo.
Configuración y
gestión de cambios De soporte, gestiona los cambios en el sistema.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 24
Gestión del proyecto De soporte, gestiona el desarrollo del sistema.
Entorno Desarrollar herramientas software disponible para los equipos de
desarrollo de software.
Flujo de trabajo estático en el Proceso Unificado de Rational
PERSPECTIVA PRÁCTICA
Se describen las buenas prácticas de la ingeniería del software que son aconsejables en el
desarrollo de sistemas. Se recomiendan seis buenas prácticas fundamentales:
1. Desarrollar el software de modo iterativo. Planificar incrementos del sistema basado
en las prioridades del usuario, desarrollo y entregue las características del sistema de
más alta prioridad al inicio del proceso de desarrollo.
2. Gestionar los requisitos. Los requisitos son documentados y analizados en el caso de
efectuarse cambios para medir el impacto en el sistema.
3. Utilizar arquitecturas basadas en componentes.
4. Modelar el software visualmente. UML es utilizado para presentar vistas estáticas y
dinámicas del software.
5. Verificar la calidad del software. Asegurar que el software cumple los estándares de
calidad organizacionales.
6. Controlar los cambios del software. Utilizar un sistema de gestión de cambios y
procedimientos y herramientas de gestión de configuración.
RUP no es un proceso apropiado para todos los tipos de desarrollo sino que representa una
nueva generación de procesos. Las innovaciones más importantes son la separación en fases y
flujos de trabajo, y el reconocimiento de que la utilización del software en un entorno del
usuario es parte del proceso.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 25
REQUISITOS DE SOFTWARE
“Capacidad o condición que deberá ser alcanzada
por el producto software”
(IEEE Computer Society)
Un requisito es una declaración abstracta de alto nivel de un servicio que
debe proporcionar el sistema o una restricción de éste. En el otro caso, es una
definición detallada y formal de una función del sistema.
REQUISITOS DEL USUARIO
Los requisitos del usuario son declaraciones en lenguaje natural, sencillo con formularios y
diagramas intuitivos que proporcionan los requisitos funcionales y no funcionales de forma
comprensible. Deben especificar el comportamiento externo. Designan los requisitos
abstractos de alto nivel de los servicios que se espera que el sistema proporcione y de las
restricciones bajo las cuales debe funcionar. Evitar en lo posible las características del diseño
del sistema.
Para obtener los requisitos de los usuarios se debe tener en consideración:
1. Tener un formato estándar y asegurar que todos los requisitos se encuentren en él.
2. No deben haber omisiones y deben ser fáciles de verificar.
3. Una referencia a la especificación más detallada de los requisitos del sistema.
4. Fuente del requisito.
5. Distinguir partes claves del requisito.
6. No usar jergas informáticas.
7. Incluir términos técnicos detallados en los requisitos del usuario.
8. Identificar dependencias con otros requisitos.
Requisitos de usuario y requisitos de software
REQUISITOS DEL SISTEMA
Los requisitos del sistema son versiones extendidas de los requisitos del usuario que se
utilizan para comunicar de forma precisa la funcionalidad, los servicios y las restricciones del
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 26
sistema. Debe ser una especificación completa y consistente del sistema y son utilizados por
los ingenieros de software como punto de partida para el diseño del sistema.
Se pueden redactar los requisitos del sistema en un documento estructurado en lenguaje
natural (algunas veces denominado especificación funcional), lenguaje que los no especialistas
puedan entender. Sin embargo se pueden redactar los requisitos del sistema en unas
notaciones más especializadas, modelos gráficos de los requisitos como los casos de uso.
Los requisitos del sistema simplemente describen el comportamiento externo del sistema y sus
restricciones operativas. Estos se organizan conforme a los diferentes subsistemas que
componen el sistema.
ESPECIFICACIONES EN LENGUAJE ESTRUCTURADO
El lenguaje estructurado es una forma estándar de redactar los requisitos del sistema.
Mantiene la mayor parte de la expresividad y comprensión y asegura que se imponga cierto
grado de uniformidad en la especificación. Las notaciones del lenguaje estructurado limitan la
terminología que se utilizan y emplean plantillas para especificar los requisitos del sistema.
Pueden incorporar construcciones de control derivadas de los lenguajes de programación y
manifestaciones gráficas para dividir la especificación.
Heninger (1980) describe uno de los primeros proyectos que utilizó el lenguaje estructurado
para especificar los requisitos del sistema. Se diseñaron formularios de propósito especial para
describir la entrada, la salida y las funciones de un sistema software para un avión.
Se define uno o más formularios o plantillas estándar para expresar los requisitos del sistema.
Se puede estructurar la especificación alrededor de los objetos que manipula el sistema, las
funciones ejecutadas por el sistema o los eventos procesados por éste.
Capítulo Descripción
Prefacio
Define los posibles lectores del documento y describe la versión
de la historia, incluyendo un fundamento para la creación de una
nueva versión y un resumen de cambios hechos en cada una.
Introducción
Describe la necesidad del sistema, brevemente sus funciones y
explica cómo trabajar con otros sistemas. Describe la manera de
cómo se adhiere al negocio u objetivos estratégicos de la
organización.
Glosario Define los términos técnicos utilizados en el documento. No se
deben hacer suposiciones.
Definición de requisitos
del usuario
Describe los servicios que proporcionan al usuario y los
requisitos no funcionales. Puede utilizar lenguaje natural,
diagramas u otras notaciones que sean comprensibles para los
clientes. Especificar los estándares de productos y procesos a
seguir.
Arquitectura de sistema
Visión general de alto nivel que muestra la distribución de
funciones de los módulos del sistema. Se resaltan los
componentes arquitectónicos reutilizados.
Especificación de Describir con mayor detalle los requisitos funcionales y no
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 27
requisitos del sistema funcionales.
Modelos del sistema
Los modelos del sistema muestran las relaciones entre los
componentes del sistema y su entorno. Estos podrían ser
modelos de objetos, modelos de flujos de datos y modelos de
datos semánticos.
Evolución del sistema
Suposiciones fundamentales sobre las cuales se basa el sistema
y los cambios previstos debido a la evolución del hardware,
cambios en las necesidades del usuario, etc.
Apéndices Información detallada y precisa relacionada con la aplicación.
Ejemplo, descripciones del hardware, o base de datos.
Índice Un índice alfabético de funciones o diagramas, etc.
1. REQUISITOS FUNCIONALES Y NO FUNCIONALES.
Los requisitos pueden ser organizados en torno a un esquema de clasificación donde se
tiene (1) Requisitos funcionales (Capacidades) y (2) Requisitos de Calidad o no funcionales
(Condiciones).
REQUISITOS FUNCIONALES
Los requisitos funcionales son declaraciones de los servicios que el sistema debe
proporcionar, el comportamiento en situaciones particulares, de manera cuantitativa para que
se puedan probar de un modo objetivo. Estos requisitos dependen del tipo de software que se
desarrolle. En algunos casos, se puede declarar explícitamente lo que el sistema no debe hacer.
La especificación de requisitos funcionales de un sistema debe estar completa y ser
consistente, los requisitos no deben tener definiciones contradictorias.
REQUISITOS NO FUNCIONALES
Los requisitos no funcionales son aquellos requisitos que no se refieren directamente a las
funciones específicas que proporciona el sistema, sino a las propiedades emergentes de éste
como la fiabilidad, el tiempo de respuesta, la capacidad de almacenamiento, rendimiento del
sistema, la protección, la disponibilidad, y otras propiedades. Esto significa que a menudo son
más críticos que los requisitos funcionales. Por ejemplo, si un sistema de vuelo no cumple sus
requisitos de fiabilidad, no se certificará como seguro para el funcionamiento; si un sistema de
control de tiempo real no cumple sus requisitos de rendimiento, las funciones de control no
funcionarán correctamente.
Los requisitos no funcionales a menudo se aplican al sistema en su totalidad.
En realidad, la distinción entre los tipos de requisitos no es tan clara como sugieren estas
definiciones. Por ejemplo, un requisito del usuario sobre seguridad podría parecer un requisito
no funcional. Sin embargo, cuando se desarrolla en detalle, puede generar otros requisitos que
son claramente funcionales, como la necesidad de incluir en el sistema recursos para la
autenticación del usuario.
Los requisitos no funcionales surgen de las necesidades del usuario, debido a las restricciones
en el presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 28
otros sistemas software o hardware, o a factores externos como regulaciones de seguridad o
legislaciones sobre privacidad.
Los tipos de requisitos no funcionales son:
1. Requisitos del producto. Rendimiento en la rapidez de ejecución del sistema y cuanta
memoria se requiere; los requisitos de fiabilidad que fijan la tasa de fallos para que el
sistema sea aceptable; los requisitos de portabilidad y los requisitos de usabilidad.
2. Requisitos organizacionales. Estándares que deben utilizarse en los procesos; los
requisitos de implementación, como los lenguajes de programación o el método de
diseño a utilizar, y los requisitos de entrega que especifican cuándo se entregará el
producto y su documentación.
3. Requisitos externos. Requisitos que se derivan de los factores externos y de su
proceso de desarrollo. Pueden incluir los requisitos de interoperabilidad, cómo el
sistema interactúa con otros sistemas de otras organizaciones; el legislativo cómo el
sistema funciona dentro de la ley, y los requisitos éticos.
Un problema común con los requisitos no funcionales es que pueden ser difíciles de verificar.
Varias mediciones (métricas) pueden usarse para especificar las propiedades no funcionales
del sistema, estas características se pueden medir cuando se prueba el sistema para comprobar
si cumple sus requisitos no funcionales.
Propiedad Medida
Rapidez Transacciones procesadas por segundo.
Tiempo de respuesta al usuario y a eventos.
Tiempo de actualización de la pantalla.
Tamaño K Bytes
Número de chips de RAM
Fiabilidad Tiempo medio entre fallos
Probabilidad de no disponibilidad.
Tasa de ocurrencia de fallos
Disponibilidad.
Robustez Tiempo de reinicio después de fallos
Porcentaje de eventos que provocan fallos
Probabilidad de corrupción de datos después de fallos.
Portabilidad Porcentaje de declaraciones dependientes del objetivo
Número de sistemas objetivo.
Métricas para especificar requisitos no funcionales.
Es de utilidad diferenciar los requisitos funcionales y no funcionales en el documento de
requisitos. En la práctica, esto es difícil. Si los requisitos no funcionales se declaran de forma
separada de los funcionales, algunas veces es difícil ver la relación entre ellos.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 29
2. INGENIERÍA DE REQUISITOS.
“La ingeniería de requisitos es la disciplina para desarrollar una
especificación completa, consistente y no ambigua, la cual servirá como base
para acuerdos comunes entre todas las partes involucradas y en dónde se
describen las funciones que realizará el sistema”
(Boehm, 1979)
“La ingeniería de requisitos facilita el mecanismo apropiado para
comprender lo que el cliente quiere, analizar sus necesidades, confirmar la
viabilidad, negociar una solución razonable, especificar la solución sin
ambigüedad, validar la especificación y gestionar los requisitos a fin de
transformarlos en una solución operacional”
(Pressman, 2002)
La ingeniería de requisitos es el proceso de desarrollar la especificación del software, de
definir los servicios que el sistema brindará y de las restricciones de funcionamiento y
desarrollo del mismo. La ingeniería de requisitos es una etapa parcialmente crítica en el
proceso de software, de ésta dependerá el diseño e implementación del sistema. La
documentación de los requisitos conducirá a la especificación del sistema. Se presentan en dos
niveles de detalle: los clientes necesitan una declaración de alto nivel de los requisitos
mientras los desarrolladores necesitan una especificación más detallada de éste.
PROCESOS DE INGENIERÍA DE REQUISITOS
El proceso de ingeniería de requisitos incluye un estudio de viabilidad, así como la obtención,
análisis, especificación, validación y gestión de requisitos.
Actividades del proceso de IR
a. Estudio de viabilidad.
Evalúa si el sistema es útil para el negocio, si es rentable y si se puede desarrollar
dentro de las restricciones de presupuesto existentes. Debe ser relativamente económico y
rápido de elaborar.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 30
Se debe responder a las siguientes preguntas:
1. ¿Contribuye el sistema a los objetivos generales de la organización?
2. ¿Se puede implementar utilizando la tecnología actual y dentro de las restricciones de
costo y tiempo?
3. ¿Puede integrarse el sistema con otros sistemas existentes en la organización?
En el estudio de viabilidad se considera un conjunto de requisitos de negocio preliminares, la
descripción resumida del sistema y como pretende contribuir a los procesos del negocio. Si el
sistema no contribuye con los objetivos de la organización, entonces no tiene un valor real en
el negocio.
b. Obtención y análisis de requisitos.
Obtener los requisitos del sistema por medio de la observación de los sistemas
existentes, entrevista con los stakeholders (usuarios finales, gerentes de negocio, expertos en
el dominio del sistema, desarrolladores) para determinar el dominio de la aplicación, qué
servicios debe proporcionar el sistema, el rendimiento requerido del sistema, las restricciones
de hardware, etc. Desarrollo de modelos y prototipos que sirven para comprender mejor el
sistema.
Construcción de prototipos
Obtener y comprender los requisitos es difícil por varias razones:
1. Los stakeholders a menudo no conocen lo que desean obtener del sistema informático
excepto en términos muy generales;
2. Los stakeholders expresan los requisitos con sus propios términos de forma natural y
con un conocimiento implícito de su propio trabajo.
3. Pueden surgir requisitos distintos de diferentes stakeholders.
4. Pueden influir factores políticos en los requisitos del sistema.
5. Es dinámico el entorno económico y de negocios en el que se lleva a cabo el análisis,
pueden surgir nuevos requisitos que no habían sido considerado.
La obtención y análisis de requisitos es un proceso iterativo que puede ser representado como
una espiral de actividades – el descubrimiento, la clasificación y organización, la negociación
y la documentación de requisitos.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 31
1. Descubrimiento de requisitos. Es el proceso de interactuar con los stakeholders del
sistema para recopilar sus requisitos. Pueden utilizarse entrevistas, escenarios,
prototipos del sistema y métodos de análisis estructurado.
2. Clasificación y organización de requisitos. Los requisitos se organiza en grupos
coherentes de una manera estructurada. La forma más común de agrupar es utilizar un
modelo de la arquitectura del sistema para identificar los subsistemas y asociar los
requisitos en cada subsistema.
3. Ordenación por prioridades y negociación de requisitos. Esta actividad se refiere a
ordenar los requisitos según las prioridades, y a encontrar y resolver los requisitos en
conflicto a través de la negociación.
4. Documentación de requisitos. Se documenta los requisitos de tal forma que se puede
utilizar para ayudar al descubrimiento de nuevos requisitos. Se puede documentar con
tablas en un documento o en tarjetas fácil de manejar, cambiar y organizar.
La obtención y análisis de requisitos es un proceso iterativo con retroalimentación continua de
cada actividad. Comienza con el descubrimiento de requisitos y termina con la documentación
de los mismos. La comprensión de los requisitos por parte del analista mejora con cada
iteración.
ENTREVISTAS
Las entrevistas sirven para obtener una comprensión general de lo que hacen los stakeholders,
cómo podrían interactuar con el sistema y las dificultades a las que se enfrentan con los
sistemas actuales.
Esquema de resumen de la entrevista
Nombre del entrevistado
Puesto de trabajo y breve descripción
Punto de vista que representa
Fecha, hora y lugar de la entrevista
Resumen de puntos principales
Documentos de referencia
Otros contactos
Los entrevistadores eficaces tienen dos características:
1. Están dispuestos a escuchar a los stakeholders, no tienen prejuicios, evitan ideas
preconcebidas sobre los requisitos.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 32
2. Empezar las discusiones con una pregunta, una propuesta de requisitos o sugiriendo
trabajar juntos en un prototipo del sistema. Es mucho más fácil hablar en un contexto
definido en vez de en términos generales.
Se documenta la información adquirida en las entrevistas.
ESCENARIOS
Se han desarrollado varias formas de escenarios, cada una de las cuales proporciona diferentes
tipos de información en diferentes niveles de detalle sobre el sistema.
Un escenario puede incluir:
Descripción cuando el escenario comienza.
Descripción del flujo normal de eventos.
Descripción de lo que puede ir mal y cómo manejarlo.
Información de otras actividades que se podrían llevar a cabo al mismo tiempo.
Descripción del estado del sistema cuando el escenario termina.
Los escenarios se redactan como texto, complementados por diagramas, fotografías de las
pantallas, etc. Se puede adoptar un enfoque más estructurado, como los escenarios de evento o
los casos de uso.
CASOS DE USO
Los casos de uso se introdujeron por primera vez con el método Objetory (Jacobson, 1993)
son una técnica que se basa en escenarios para la obtención de requisitos. Actualmente se han
convertido en una característica fundamental de la notación UML, que se utiliza para describir
modelos de sistemas orientados a objetos. En una forma más simple, un caso de uso identifica
el tipo de interacción y los actores involucrados.
Actor Caso de uso
Notación del caso de uso
Los escenarios y los casos de uso son técnicas eficaces para obtener requisitos para los puntos
de vista de los interactuadores, donde cada tipo de interacción se puede representar como un
caso de uso.
ETNOLOGIA
La etnología es una técnica de observación utilizada para entender los requisitos sociales y
organizacionales. Un analista se sumerge en el entorno laboral, observa el trabajo diario y
anota las tareas reales en las que los participantes están involucrados. El valor de la etnografía
es que ayuda a los analistas a descubrir los requisitos implícitos que reflejan los procesos
reales más que los formales en los que la gente está involucrada.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 33
c. Validación de Requisitos.
En la validación de requisitos se verifica la validez, consistencia, completitud, realismo
y verificabilidad de los requisitos. En este proceso se descubre errores los cuales deben
modificarse para solucionarse el problema. Los errores en el documento de requisitos pueden
conducir a importantes costos durante el desarrollo o después de que el sistema esté en uso.
El costo de arreglar un problema en los requisitos haciendo un cambio en el sistema es mucho
mayor que reparar los errores de diseño o los de codificación. La razón de esto es que un
cambio en los requisitos normalmente significa que el diseño y la implementación del sistema
también deben cambiar y que éste debe probarse nuevamente.
Las principales técnicas para la validación son las revisiones de los requisitos y la
construcción de prototipos.
La revisión de requisitos es un proceso manual que involucra a personas tanto de la
organización como desarrolladores. Verifican el documento de requisitos en cuanto a
anomalías y omisiones. Las revisiones de requisitos pueden ser formales o informales.
Los conflictos, contradicciones, errores y omisiones en los requisitos deben ser señalados por
los revisores y registrados formalmente en el informe de revisión.
d. Gestión de Requisitos.
Los cambios en los negocios, organizaciones y técnicos inevitablemente conducen a
cambios en los requisitos de un sistema software. La gestión de requisitos es el proceso de
gestionar y controlar estos cambios.
El proceso de gestión de requisitos incluye la gestión de la planificación, en la cual se diseñan
las políticas y procedimientos para la gestión de requisitos, y la del cambio, en la que usted
analiza los cambios propuestos en los requisitos y evalúa su impacto.
La gestión de requisitos tiene un costo. Durante la etapa de gestión de requisitos, habrá que
decidir sobre:
1. Identificar los requisitos. Se identifican los requisitos de forma única.
2. Proceso de gestión de cambios. Se evalúa el impacto y costo de los cambios.
3. Políticas de rastreo. Se define las relaciones entre los requisitos y la manera en que
estos registros se deben mantener.
La gestión de requisitos comprende el procesamiento de grandes cantidades de información.
Las herramientas que se pueden utilizar van desde sistemas de gestión de requisitos
especializados hasta hojas de cálculo y sistemas sencillos de bases de datos. Ejemplos:
DOORS y RequisitePro.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 34
El software no satisface los requisitos establecidos
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 35
MODELO DEL SISTEMA
Un modelo es una vista abstracta de un sistema que prescinde de algunos detalles del
mismo. Pueden desarrollarse modelos del sistema complementarios para presentar otra
información sobre dicho sistema.
Una técnica ampliamente usada es documentar la especificación del sistema como un conjunto
de modelos del sistema. Estos modelos son representaciones gráficas que describen los
procesos del negocio, el problema a resolver y el sistema que tiene que ser desarrollado.
Debido a las representaciones gráficas usadas, los modelos son a menudo más comprensibles
que las descripciones detalladas en lenguaje natural de los requisitos del sistema. Ellos
constituyen también un puente importante entre el proceso de análisis y diseño.
Pueden desarrollarse diferentes modelos para representar el sistema desde diferentes
perspectivas:
1. Una perspectiva externa, modela el contexto o entorno del sistema.
2. Una perspectiva de comportamiento, se modela el comportamiento del sistema.
3. Una perspectiva estructural, se modela la arquitectura del sistema o la estructura de los
datos procesados por el sistema.
El aspecto más importante de un modelo del sistema es que omite los detalles.
Los tipos de modelos del sistema distintos se basan en distintas aproximaciones de
abstracción. Ejemplo de tipos de modelos del sistema que podrían crearse durante el proceso
de análisis son:
1. Modelo de flujo de datos. Muestra como se procesan los datos en el sistema en las
diferentes etapas.
2. Modelo de composición o agregación. Muestra cómo las entidades del sistema están
compuestas por otras entidades.
3. Modelo arquitectónico. Muestra los principales subsistemas que componen el sistema.
4. Modelo de clasificación. Los diagramas de clase/herencia de objetos muestran cómo
las entidades tienen características comunes.
5. Modelo de estímulo-respuesta. O diagrama de transición de estados muestra cómo
reacciona el sistema a eventos internos y externos.
Siempre que es posible, se usan notación del Lenguaje Unificado de Modelado (UML), que
se ha convertido en un lenguaje de modelado estándar para el modelado orientado a objetos
(Booch, Rumbaugh, 1999).
MODELADO DE SISTEMAS
Los sistemas pueden ser modelados como un conjunto de componentes y sus
relaciones en un modelo arquitectónico proporcionando una visión general de la organización
del sistema. En el modelo arquitectónico es más apropiado clasificar los componentes
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 36
(subsistemas) de acuerdo con su funcionalidad. Pueden mostrarse los principales subsistemas
y su interconexión en un diagrama de bloques, esto es válido para sistemas de cualquier
tamaño. Comúnmente los subsistemas se desarrollan en paralelo.
En la integración se toman los subsistemas desarrollados de modo independiente y se
integran para crear el sistema completo. Se pueden integrar todos los subsistemas al mismo
tiempo, pero el mejor enfoque es la integración creciente, uno a uno, por dos razones:
1. El desarrollo de todos los subsistemas no terminan al mismo tiempo.
2. La integración creciente reduce el costo en la ubicación de errores.
Una vez integrado los componentes, hay que dar lugar a un extenso programa de pruebas del
sistema. Se prueban las interfaces entre los componentes y el comportamiento total del
sistema.
MODELO DE CONTEXTO
Los modelos de contexto muestran cómo el sistema que se está modelando se ubica en un
entorno con otros sistemas y procesos.
CCB
Gestor del proyecto
Analista
Administrador
Usuario
Sistema de Gestión de Cambios
Modelo de contexto del Sistema de Gestión de Cambios
Definen los límites del sistema. Los modelos arquitectónicos, los modelos de procesos y
modelos de flujos de datos pueden utilizarse como modelos de contexto.
Los modelos arquitectónicos sencillos normalmente se complementan con otros modelos, tales
como modelos de procesos, que muestran las actividades de los procesos soportadas por el
sistema. Los modelos de flujo de datos también pueden usarse para mostrar los datos que son
transferidos entre el sistema y otros sistemas de su entorno.
MODELO DE COMPORTAMIENTO
Se utilizan para describir el comportamiento del sistema en su totalidad. Ejemplo: modelos de
flujo de datos, que modelan el procesamiento de los datos en el sistema, y modelos de
máquina de estado, que modelan cómo el sistema reacciona a los eventos. Estos modelos
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 37
pueden usarse de forma separada o conjuntamente, dependiendo del tipo de sistema que se
esté desarrollando.
MODELO DE DATOS
Una parte importante del modelado de sistemas es la definición de la forma lógica de los datos
procesados por el sistema. La técnica de modelado de datos más importante usada es el
modelado Entidad-Relación-Atributo (modelado ERA), que muestra las entidades de datos,
sus atributos asociados y las relaciones entre estas entidades.
Modelo de datos en UML
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 38
Los modelos entidad-relación han sido ampliamente usados en el diseño de bases de datos.
Los esquemas de bases de datos relacionales derivados de estos modelos se encuentran de
manera natural en tercera forma normal, lo cual es una característica deseable.
UML no incluye una notación específica para este modelado de bases de datos, ya que asume
un proceso de desarrollo orientado a objetos y modela los datos utilizando objetos y sus
relaciones.
Un diccionario de datos es, de forma simple, una lista de nombres ordenados alfabéticamente
incluida en los modelos del sistema, incluye el nombre del dato, una descripción asociada de
dicha entidad, fecha de creación, el creador y la representación de la entidad dependiendo del
tipo de modelo que se esté desarrollando. Todos los nombres del sistema, tanto si son nombres
de entidades, relaciones, atributos o servicios, deberían introducirse en el diccionario. Hay
herramientas CASE que soportan el modelado del sistema incluyendo soporte para el
diccionario de datos e introducen los nombres en el diccionario cuando se utilizan por primera
vez en el modelo.
MODELO DE OBJETOS
Los modelos de objetos describen las entidades lógicas del sistema y su clasificación y
agregación. Combinan un modelo de datos con un modelo de procesamiento. Posibles
modelos de objetos que pueden desarrollarse incluyen modelos de herencia, modelos de
agregación y modelos de comportamiento.
Los modelos de objetos son formas naturales de reflejar las entidades del mundo real que son
manipuladas por el sistema.
El desarrollo de modelos de objetos durante el análisis de requisitos normalmente simplifica la
transición entre el diseño orientado a objetos y la programación.
Una clase de objetos es una abstracción sobre un conjunto de objetos que identifica atributos
comunes y los servicios y operaciones que son proporcionados por cada objeto. Los objetos
son entidades ejecutables que tienen atributos y servicios de la clase de objetos. Los objetos
son instancias de la clase de objetos, y pueden crearse muchos objetos a partir de una clase.
Generalmente, los modelos desarrollados utilizando análisis se centran en las clases de objetos
y en sus relaciones.
METODOS ESTRUCTURADOS
Los métodos estructurados proporcionan un marco para soportar el desarrollo de modelos
del sistema. Los métodos estructurados normalmente son soportados de forma extensiva por
herramientas CASE, incluyendo la edición de modelos y la comprobación y generación de
código.
Fueron desarrollados en la década de los 70’s para soportar el análisis y el diseño del software
y evolucionaron en la década de los 80’s y 90’s para soportar el desarrollo orientado a objetos.
Los métodos estructurados proporcionan un marco para el modelado detallado de sistemas
como parte de la elicitación y análisis de requisitos. Los métodos estructurados han sido
aplicados con éxito en muchos proyectos grandes. Utilizan notaciones estándar y aseguran que
se produce una documentación de diseño estándar. Sin embargo, tienen una serie de
inconvenientes:
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 39
1. No proporcionan un soporte efectivo para la comprensión o el modelado de requisitos
del sistema no funcionales.
2. No incluyen guías que ayuden a los usuarios a decidir si un método es adecuado para
un problema concreto.
3. No incluyen consejos sobre cómo pueden adaptarse para su uso en un entorno
particular.
4. Los modelos producidos son muy detallados y los usuarios los encuentran difíciles de
entender.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 40
DISEÑO DEL SOFTWARE
1. CONCEPTOS Y PRINCIPIOS DE DISEÑO.
El diseño del software es la descripción de la estructura del software, de los datos que
son parte del sistema, las interfaces entre los componentes, y algunas veces, los algoritmos
utilizados.
El diseño es un proceso creativo, no hay una fórmula estricta para el diseño del software. Se
aprende a cómo diseñar observando ejemplos de diseño existentes y discutiendo su diseño con
otros. Los diseñadores no llegan inmediatamente a un diseño detallado, sino que lo desarrollan
de manera iterativa a través de diversas versiones.
La esencia del diseño del software es la toma de decisiones sobre la organización lógica del
software. Puede representarse esta organización lógica como un modelo en un lenguaje
definido de modelado tal como UML y otras veces simplemente notaciones informales y
esbozos para representar el diseño.
Los grandes sistemas siempre se descomponen en subsistemas que proporcionan algún
conjunto de servicios relacionados.
El diseño arquitectónico es la primera etapa en el proceso de diseño y representa un enlace
crítico entre los procesos de ingeniería de requisitos y diseño. El proceso de diseño
arquitectónico está relacionado con el establecimiento de un marco estructural básico que
identifica los principales componentes de un sistema y las comunicaciones entre los
componentes. Las decisiones de diseño arquitectónico incluyen decisiones sobre el tipo de
aplicación, la distribución del sistema, los estilos arquitectónicos a utilizar y las formas en las
que la arquitectura debería documentarse y evaluarse. La descomposición arquitectónica es
necesaria para estructurar y organizar la especificación. El resultado de este proceso de diseño
es una descripción de la arquitectura del software.
La arquitectura del software es un marco fundamental para estructurar el sistema. Puede
servir como un plan de diseño para negociar los requisitos del sistema y cómo estructurar las
discusiones con los clientes, desarrolladores y gestores. Es una herramienta esencial para la
gestión de la complejidad. La arquitectura del software oculta detalles y permite a los
diseñadores centrarse en las abstracciones clave del sistema.
La arquitectura del software afecta al rendimiento, protección, seguridad, disponibilidad,
solidez, grado de distribución y mantenibilidad de un sistema, puede depender de los
requisitos no funcionales del sistema.
Tres ventajas de diseñar explícitamente y documentar la arquitectura del software:
1. Comunicación con los stakeholders.
2. Análisis del sistema.
3. Reutilización a gran escala.
El diseño de un subsistema es una descomposición abstracta de un sistema en componentes,
cada uno de los cuales puede ser un sistema importante por si mismo. Se usan a menudo los
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 41
diagramas de bloques para describir diseño de subsistemas en donde cada caja en el diagrama
representa un subsistema. Los diagramas de bloques presentan un dibujo de alto nivel de la
estructura del sistema, la cual puede entenderse con facilidad por personas de diferentes
disciplinas que están implicadas en el proceso de desarrollo de sistema.
El problema general de decidir cómo descomponer un sistema en subsistemas es difícil. Los
requisitos del sistema son un factor fundamental y debería intentarse crear un diseño en el que
hubiera una clara correspondencia entre los requisitos y los subsistemas. Esto significa que, si
los requisitos cambian, este cambio probablemente este localizado en un único sitio en vez de
distribuirlo en varios subsistemas.
Existen diferentes modelos arquitectónicos tales como el modelo estructural, el modelo de
control y el modelo de descomposición que pueden ser desarrollados durante el proceso de
diseño arquitectónico.
2. EL PROCESO DE DISEÑO DE SOFTWARE.
Los procesos de diseño e implementación comprenden la transformación de la
especificación de los requisitos en un sistema software ejecutable. Los métodos sistemáticos
de diseño se pueden utilizar como parte de esta transformación.
El proceso de diseño puede implicar el desarrollo de varios modelos del sistema con diferentes
niveles de abstracción, las actividades del proceso de diseño se entrelazan.
Actividades del proceso de diseño:
1. Diseño arquitectónico. Se identifican y documentan los subsistemas que forman el
sistema y sus relaciones.
2. Especificación abstracta. Cada subsistema tiene una especificación abstracta de sus
servicios y restricciones bajo las cuales debe funcionar.
3. Diseño de la interfaz. Para cada subsistema se diseña y documenta su interfaz con
otros subsistemas. Esta especificación de la interfaz debe ser inequívoca ya que
permite que el subsistema se utilice sin conocimiento de su funcionamiento.
4. Diseño de componentes. Se asignan servicios a los componentes y se diseñan sus
interfaces.
5. Diseño de la estructura de datos. Se diseña y especifica en detalle la estructura de
datos.
6. Diseño de algoritmos. Se diseñan y especifican los algoritmos para los servicios
3. DISEÑO ARQUITECTÓNICO.
El diseño arquitectónico es un proceso creativo en el que se intenta establecer una
organización del sistema que satisfaga los requisitos funcionales y no funcionales. Durante el
proceso de diseño arquitectónico, los arquitectos del sistema tienen que tomar varias
decisiones fundamentales que afectan al sistema y a su proceso de desarrollo.
Actualmente, la mayoría de los sistemas grandes son sistemas distribuidos en los que el
software del sistema se distribuye entre computadoras diferentes. La elección de la
arquitectura de distribución es una decisión clave que afecta al rendimiento y la fiabilidad del
sistema.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 42
La arquitectura de un sistema software puede basarse en un modelo o estilo arquitectónico
particular. Un estilo arquitectónico es un patrón de organización de un sistema tal como una
organización cliente-servidor o una arquitectura por capas. Es importante un conocimiento de
estos estilos, sus aplicaciones y sus ventajas e inconvenientes.
La evaluación de un diseño arquitectónico es difícil debido a que la verdadera prueba de una
arquitectura consiste en averiguar el grado de satisfacción de los requisitos funcionales y no
funcionales después de que aquél ha sido desarrollado.
El resultado del proceso de diseño arquitectónico es un documento que incluye varias
representaciones gráficas del sistema junto con texto descriptivo asociado. Describe cómo se
estructura el sistema en subsistemas. Los modelos gráficos del sistema presentan diferentes
perspectivas de la arquitectura. Los modelos arquitectónicos pueden incluir:
1. Un modelo estructural estático.
2. Un modelo de proceso dinámico.
3. Un modelo de interfaz.
4. Modelos de relaciones
5. Modelo de distribución.
El modelo arquitectónico cliente-servidor es un modelo de sistema en el que se organiza
como un conjunto de servicios y servidores asociados, más unos clientes que acceden y usan
los servicios. Los principales componentes de este modelo son:
1. Un conjunto de servidores que ofrecen servicios a otros subsistemas.
2. Un conjunto de clientes que llaman a los servicios ofrecidos por los servidores.
3. Una red que permite a los clientes acceder a los servicios.
La ventaja más importante del modelo cliente-servidor es que es una arquitectura distribuida.
El modelo de capas de un arquitectural organiza el sistema en capas, cada una de las cuales
proporciona un conjunto de servicios. La aproximación por capas soporta el desarrollo
incremental del sistema. A medida que se desarrolla una capa, algunos de los servicios
proporcionados por esa capa pueden estar disponibles para los usuarios. Esta arquitectura
también soporta bien los cambios y es portable. En la medida en la que su interfaz permanezca
sin cambios, una capa puede reemplazarse por otra capa equivalente. Cuando las interfaces de
la capa cambian o se añaden nuevas facilidades a una capa, solamente se ve afectada la capa
adyacente.
Un modelo arquitectónico orientado a objetos estructura el sistema en un conjunto de objetos
débilmente acoplados y con interfaces bien definidas. Los objetos realizan llamadas a los
servicios ofrecidos por otros objetos.
Una descomposición orientada a objetos está relacionada con las clases de objetos, sus
atributos y sus operaciones. Cuando se implementa, los objetos se crean a partir de estas clases
y se usan algunos modelos de control para coordinar las operaciones de los objetos.
Las ventajas de la aproximación orientada a objetos son bien conocidas. Debido a que los
objetos están débilmente acoplados, la implementación de los objetos puede modificarse sin
afectar a otros objetos.
Los objetos son a menudo representaciones de entidades del mundo real por lo que la
estructura del sistema es fácilmente comprensible. Debido a que las entidades del mundo real
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 43
se usan en sistemas diferentes, los objetos pueden reutilizarse. Se han desarrollado lenguajes
de programación orientados a objetos que proporcionan implementaciones directas de
componentes arquitectónicos. Si bien los objetos pueden corresponderse con entidades del
mundo real a pequeña escala, algunas veces es difícil representar como objetos entidades más
complejas.
En una descomposición orientada a flujos de funciones o modelos de flujo de datos, las
transformaciones funcionales procesan sus entradas y producen salidas. Los datos fluyen de
una función a otra y se transforman a medida que se mueven a través de la secuencia de
funciones. Cada paso de procesamiento se implementa como una transformación. Los datos de
entrada fluyen a través de estas transformaciones hasta que se convierten en datos de salida.
Las transformaciones se pueden ejecutar secuencialmente o en paralelo.
4. DISEÑO DE LA INTERFAZ DE USUARIO.
El diseño del software abarca varias actividades, incluyendo el diseño de la interfaz de
usuario. Todos los sistemas interactivos tienen que proporcionar alguna forma de presentar la
información a los usuarios. La presentación de la información puede ser simplemente una
representación directa de la información de entrada o presentar la información gráficamente.
Para encontrar la mejora representación de la información, se necesita conocer a los usuarios y
saber cómo utilizarán el sistema.
Además de presentar la información de la aplicación, los sistemas también se comunican con
los usuarios a través de mensajes que proporcionan información sobre los errores y el estado
del sistema. Los mensajes de error siempre deben ser formales, concisos, uniformes y
constructivos. En la medida de lo posible, el mensaje debe sugerir cómo se podría corregir el
error.
Los principios que ayudan a guiar el diseño de la interfaz de usuario abarcan: familiaridad del
usuario, la uniformidad, la mínima sorpresa, la recuperabilidad, la guía al usuario.
Principio Descripción
Familiaridad del
usuario
Debe utilizar terminología, estilos de interacción obtenidos de la
experiencia de personas que más utilizan el sistema.
Uniformidad La interfaz debe ser uniforme, las operaciones comparables deben
de activarse de la misma forma.
Mínima sorpresa El comportamiento del sistema no debe probar sorpresa a los
usuarios.
Recuperabilidad Debe incluirse mecanismos que permitan a los usuarios
recuperarse de los errores.
Guía de usuario
Cuando ocurran errores, la interfaz debe proporcionar
retroalimentación significativa y características de ayuda sensible
al contexto.
Diversidad de usuarios La interfaz debe proporcionar características de interacción
apropiadas para los diferentes tipos de usuarios del sistema.
Principios de diseño de la interfaz de usuario
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 44
Los diseñadores tienen que encontrar un término medio entre los estilos de interacción más
adecuados para la aplicación, la formación y experiencia de los usuarios del sistema y el
equipo disponible. Los estilos de interacción incluyen la manipulación directa, los sistemas de
menús, el rellenado de formularios, los lenguajes de comandos y el lenguaje natural.
Cada uno de los estilos de interacción tiene ventajas y desventajas y es más adecuada para
diferentes tipos de aplicaciones y usuarios. Estos estilos de interacción se pueden mezclar,
utilizando varios en la misma aplicación.
Las interfaces de usuario basadas en Web se fundan en el soporte proporcionado por HTML o
XHTML (lenguaje de descripción de páginas) junto con lenguajes como Java, la mayoría
utilizan formularios. Es posible construir interfaces de manipulación directa en Web, pero ésta
es una tarea compleja de programación.
PROCESO DE DISEÑO DE LA INTERFAZ DE USUARIO
El diseño de la interfaz de usuario (UI) es un proceso iterativo donde los usuarios interactúan
con los diseñadores y prototipos de la interfaz para decidir las características, organización,
apariencia y funcionamiento de la interfaz de usuario del sistema. A veces, se construye el
prototipo de la interfaz por separado en paralelo con otras actividades de la ingeniería del
software. En especial cuando se utiliza un desarrollo iterativo, el diseño de la interfaz de
usuario se lleva a cabo de forma incremental conforme se desarrolla el software.
Existen tres actividades esenciales en el diseño de la IU:
1. Análisis del usuario. Da a conocer las formas de trabajar de los usuarios, a través de
tareas que realiza, entrevistas, observaciones y entorno de trabajo.
2. Prototipado del sistema. El desarrollo de prototipos es un proceso en etapas, con
versiones evaluadas y retroalimentación. Se desarrollan prototipos del sistema y se
exponen a los usuarios. Implicar al usuario en el proceso de diseño y desarrollo es un
aspecto fundamental del diseño centrado en el usuario, un criterio de diseño para
sistemas interactivos.
Se puede utilizar una técnica basada en storyboards. Un storyboard es una serie de
esbozos que ilustran una secuencia de interacciones.
3. Evaluación de la interfaz. La evaluación de la interfaz es el proceso de evaluar la
forma en que se utiliza una interfaz y verificar que cumple los requisitos del usuario
(usabilidad). Por lo tanto, debe ser parte del proceso de verificación y validación de los
sistemas software.
La evaluación sistemática del diseño de la interfaz de usuario puede ser un proceso
caro que implica a diseñadores gráficos y otros.
Se puede utilizar la construcción de prototipos como parte del proceso de ingeniería de
requisitos y, tiene sentido empezar el proceso de diseño de la IU en esta etapa. En los procesos
iterativos, el diseño de la IU se integra con el desarrollo del software.
5. DISEÑO ORIENTADO A OBJETOS.
Un sistema orientado a objetos está compuesto de objetos que interactúan. El diseño
orientado a objetos es un medio para diseñar software de tal forma que los componentes del
diseño representen objetos con su estado y operaciones propias en lugar de funciones.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 45
El diseño orientado a objetos es parte del desarrollo orientado a objetos:
El análisis orientado a objetos. Desarrollo de un modelo orientado a objetos del
dominio de la aplicación. Los objetos identificados reflejan las entidades y operaciones
que se asocian con el problema a resolver.
El diseño orientado a objetos. Comprende el desarrollo de un modelo orientado a
objetos de un sistema software para implementar los requisitos, están relacionados con
la solución del problema por resolver.
La programación orientada a objetos. Se refiere a implementar el diseño de software
utilizando un lenguaje de programación orientado a objetos como Java.
Los sistemas orientados a objetos son más fáciles de mantener, debido a que los objetos son
independientes. Cambiar la implementación de un objeto o agregarle servicios no debe afectar
a otros objetos del sistema. Puesto que los objetos están asociados a cosas, existe una
correspondencia clara entre las entidades del mundo real y los objetos de control del sistema.
Los objetos son componentes potencialmente reutilizables debido a que son encapsulados de
modo independiente de su estado y operaciones. Los diseños se pueden desarrollar utilizando
objetos creados en diseños previos. Esto reduce los costos de diseño, programación y
validación.
El Lenguaje Unificado de Modelado (UML) es un conjunto de notaciones que pueden
utilizarse para documentar un diseño orientado a objetos. El Proceso Unificado de Rational
(RUP) origina el desarrollo iterativo y entregas incrementales de grandes sistemas software.
Este proceso es un proceso de desarrollo iterativo basado en casos de uso para expresar los
requisitos y el diseño orientado a objetos, centrándose particularmente en el diseño de la
arquitectura.
La utilización de casos de uso significa que el diseño está ciertamente centrado en el usuario y
basado en las interacciones del usuario con el sistema. Los casos de uso tienen ciertamente un
papel en el análisis y diseño orientado a objetos, pero necesitan ser complementados con otras
técnicas que nos permitan descubrir requisitos no funcionales del sistema.
OBJETOS Y CLASES
Un objeto es un encapsulamiento de información. Un objeto es una entidad que tiene un
estado (conjunto de atributos) y un conjunto de operaciones definidas que operan sobre ese
estado. Las operaciones asociadas al objeto proveen servicios a otros objetos cuando se
requiere llevar a cabo algún cálculo.
Los objetos se crean conforme a una definición de clases de objetos. Una definición de clases
sirve como una plantilla para crear objetos. Esta incluye las declaraciones de todos los
atributos y operaciones asociados con un objeto de esa clase.
En UML, una clase se representa como un rectángulo con nombre y dos secciones (la sección
superior los atributos del objeto y la sección inferior las operaciones asociadas con el
objeto). En UML “operación” es la especificación de una acción, “método” es la
implementación de la operación.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 46
Empleado
nombre: string
dirección: string
fechaNacimiento: date
nroEmpleado: integer
salario: integer
status : (current, left, retired)
…
une()
abandona()
jubilado()
cambiaDetalles()
Objeto Empleado
Los objetos se comunican a través de la solicitud de servicios (llamando a los métodos) de
otros objetos y, si es necesario, intercambiando la información requerida para que ese servicio
se suministre. Los resultados de la ejecución del servicio se pasan como parámetros.
Cuando los objetos coexisten en el mismo programa, las llamadas a los métodos se
implementan como llamadas a procedimientos o funciones en un lenguaje como C.
Las clases se pueden organizar mediante una generalización o jerarquía de herencia que
muestra las relaciones entre las clases generales y más específicas. La clase más específica
concuerda completamente con la clase general, pero incluye información adicional. En la
notación UML, la generalización se indica mediante una flecha que apunta a la clase padre. En
los lenguajes de programación orientados a objetos, pero lo regular la generalización se
implementa utilizando el mecanismo de herencia. La clase hija hereda los atributos y
operaciones de la clase padre.
Los objetos que son miembros de una clase participan en las relaciones como otros objetos.
Estas relaciones se modelan describiendo las asociaciones entre las clases. En UML, las
asociaciones se denotan mediante una línea que une las clases, a la que se le puede agregar
una nota con información de la asociación.
La asociación es una relación muy general y a menudo se utiliza en UML para indicar que un
atributo del objeto es un objeto asociado, o que la implementación de un método del objeto
depende del objeto asociado. Una de las asociaciones más comunes es la agregación que
muestra la manera en que los objetos están compuestos de otros objetos.
PROCESO DE DISEÑO ORIENTADO A OBJETOS
El proceso de diseño orientado a objetos incluye actividades para diseñar la arquitectura del
sistema, identificar objetos en el sistema, describir el diseño utilizando diversos modelos de
objetos y documentar las interfaces de objetos.
El proceso general que se utiliza para el diseño orientado a objetos tiene varias etapas:
1. Comprender y definir el contexto y los modos de utilización del sistema.
2. Diseñar la arquitectura del sistema.
3. Identificar los objetos principales en el sistema.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 47
4. Desarrollar los modelos de diseño.
5. Especificar las interfaces de los objetos.
El diseño no es un proceso sencillo y bien estructurado. En realidad, un diseño se desarrolla
proponiendo soluciones y refinando estas soluciones.
Un paquete en UML representa una colección de objetos y otros paquetes.
CONTEXTO DEL SISTEMA Y MODELOS DE UTILIZACIÓN
La primera etapa en el proceso de diseño de software es comprender las relaciones entre el
software que se está diseñando y el entorno externo. Comprender eso ayuda a decidir cómo
suministrar la funcionalidad requerida al sistema y cómo estructurarlo para que se comunique
efectivamente en su entorno.
Dos modelos complementarios entre un sistema y su entorno:
1. El contexto del sistema es un modelo estático que describe a otros sistemas de su
entorno.
2. El modelo de utilización del sistema es un modelo dinámico que describe cómo el
sistema interactúa con su entorno.
El modelo de contexto de un sistema se representa utilizando asociaciones donde,
esencialmente, se produce un diagrama de bloques sencillo de la arquitectura del sistema
completo.
Se propone en UML desarrollar un modelo de casos de uso donde cada caso de uso representa
una interacción con el sistema. En los modelos de casos de uso, cada interacción posible se
enuncia en una elipse y la entidad externa implicada en la interacción se representa mediante
una figura estilizada.
Cada caso de uso se describe utilizando una descripción en lenguaje natural sencillo. Esto
ayuda a los diseñadores a identificar los objetos en el sistema y les permite comprender lo que
hará el sistema.
La descripción del caso de uso ayuda a identificar los objetos y operaciones en el sistema.
ARQUITECTURA DEL SISTEMA
Se debe tratar de descomponer un sistema de tal forma que las arquitecturas sean lo más
sencillas posibles.
IDENTIFICACIÓN DE CLASES
Las clases tienden a emerger durante el proceso de diseño. Por lo general, hay que buscar y
documentar otras clases que pudieran ser relevantes. El diseño se describe en función de estas
clases. Se han hecho varias propuestas de cómo identificar las clases:
1. Utilizar un análisis gramatical de la descripción en lenguaje natural del sistema. Los
objetos y los atributos son sustantivos; las operaciones o servicios son verbos.
2. Utilizar entidades tangibles (cosas). Esto se debe complementar identificando
estructuras de almacenamiento en el dominio de la solución, las cuales podrían
requerirse para apoyar a otros objetos.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 48
3. Utilizar un enfoque de comportamiento en el cual el diseñador primero comprende el
comportamiento total del sistema.
4. Utilizar un análisis basado en escenarios en el cual se identifican y analizan en su
momento varios escenarios de la forma de utilizar el sistema. Puesto que cada
escenario se analiza, el equipo responsable del análisis debe identificar los objetos,
atributos y operaciones requeridos. Para ayudar a este enfoque basado en escenarios
existe un método efectivo de análisis denominado tarjetas CRC en el cual los analistas
y diseñadores se encargan de identificar las actividades de los objetos.
La información adicional del conocimiento del dominio de aplicación o del análisis del
escenario se utiliza para refinar y extender los objetos iniciales. Esta información se recoge de
los documentos de requisitos, de las discusiones con los usuarios y de un análisis de los
sistemas existentes.
MODELOS DE DISEÑO
Los modelos de diseño muestran los objetos o clases en un sistema y, los diferentes tipos de
relaciones entre estas entidades. Los modelos de diseño son esencialmente el diseño mismo.
Son el puente entre los requisitos y la implementación del sistema.
Un sistema de procesamiento secuencial de datos se diseña de forma diferente de un sistema
dedicado en tiempo real, por lo que utiliza distintos modelos de diseño.
Existen dos tipos de modelos de diseño para describir un diseño orientado a objetos:
1. Modelos estáticos que describen la estructura estática del sistema en términos de las
clases del sistema y sus relaciones.
2. Modelos dinámicos que describen la estructura dinámica y que muestran las
interacciones entre los objetos del sistema (no entre las clases). Las interacciones que
se documentan incluyen la secuencia de servicios solicitados por los objetos y la forma
en que el estado del sistema se relaciona con estas interacciones de objetos.
UML provee 12 modelos estáticos y dinámicos utilizados en el documento de diseño.
1. Los modelos de subsistemas. Muestra las agrupaciones lógicas de objetos en
subsistemas coherentes. Se representan utilizando una forma de los diagramas de clase
en el que cada subsistema se muestra como un paquete. Los modelos de subsistemas
son estáticos.
2. Los modelos de secuencia. Muestran la secuencia de interacciones de los objetos. Se
representan utilizando una secuencia UML o un diagrama de colaboración. Los
modelos de secuencia son dinámicos.
3. Los modelos de máquinas. de estado muestran como los objetos individuales cambian
su estado en respuesta a eventos.
4. Los modelos de casos de uso. Muestran las interacciones con el sistema.
5. Los modelos de objetos. Describen las clases.
6. Los modelos de generalización y herencia. Muestran cómo las clases pueden ser
generalizaciones de otras clases.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 49
7. Los modelos de agregación. Muestran cómo podemos describir colecciones de
objetos.
Un modelo de subsistemas es un modelo estático útil que nos muestra cómo puede estar
organizado el diseño de forma lógica agrupando objetos.
Los modelos de secuencia son modelos dinámicos que documenta, para cada modo de
interacción, la secuencia de interacciones que tienen lugar entre los objetos.
Cuando se documenta un diseño, se debe producir un modelo de secuencia para cada
interacción significativa. Si se ha desarrollado un modelo de casos de uso, entonces se deberá
tener un modelo de secuencia para cada caso de uso identificado.
Los diagramas de secuencia se utilizan para modelar el comportamiento combinado de un
grupo de objetos, pero también son útiles para resumir el comportamiento de un solo objeto
como respuesta a los diversos mensajes que puede procesar.
No es necesario elaborar un diagrama de estado para todos los objetos que se hayan definido.
Muchos de los objetos de un sistema son relativamente sencillos, y un modelo de máquina de
estado no ayudaría a los implementadotes a comprender estos objetos.
ESPECIFICACIÓN DE LA INTERFAZ DE LOS OBJETOS
Una parte importante de cualquier proceso de diseño es la especificación de las interfaces
entre los diferentes componentes del sistema.
El diseño de interfaces de objetos comprende la especificación del detalle de la interfaz para
un objeto o un grupo de objetos. Las interfaces se especifican en UML utilizando la misma
notación que en los diagramas de clases. No existe una sección de atributos, y el estereotipo
en UML <interfaz> se debe incluir en la parte del nombre.
EVOLUCIÓN DEL DISEÑO
Una ventaja importante de un enfoque orientado a objetos para el diseño es que simplifica el
problema de hacer cambios a dicho diseño. La razón de esto es que la representación del
estado del objeto no influye en el diseño. Cambiar los detalles internos de un objeto no afecta
a ningún otro objeto del sistema.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 50
DESARROLLO DEL SOFTWARE
Existen diferentes formas de desarrollar software. Entre ellas se encuentran la
programación original en lenguajes como C o Java, la generación de secuencias de comandos,
la programación de bases de datos, la generación de programas a través de herramientas
CASE, y la ingeniería de software basada en la reutilización.
1. DESARROLLO RÁPIDO DE SOFTWARE.
Actualmente, los negocios operan en un entorno global que cambia rápidamente. El
software es parte de casi todas las operaciones de negocio, por lo que es fundamental que el
software se desarrolle rápidamente para aprovechar nuevas oportunidades y responder a la
presión competitiva. El desarrollo y entrega rápidos son a menudo los requisitos más críticos
de los sistemas software. Muchas compañías están dispuestas a una pérdida en la calidad del
software y en el compromiso sobre los requisitos a favor de una entrega rápida del software.
Debido a que estas compañías operan en un entorno cambiante, a menudo es prácticamente
imposible obtener un conjunto completo de requisitos de software estable. Cuando los
requisitos cambian o cuando se descubren problemas con ellos, el diseño o implementación
del sistema se tiene que volver a realizar o probar.
Los procesos de desarrollo rápido de software están diseñados para producir software útil de
forma rápida. Generalmente, son procesos iterativos en los que se entrelazan la especificación,
el diseño, el desarrollo y las pruebas. Donde en cada incremento se incluyen nuevas
funcionalidades al sistema. Se tiene las siguientes características fundamentales:
1. Los procesos de especificación, diseño e implementación son concurrentes. No existe
una especificación detallada del sistema, y se minimiza la documentación del diseño.
El documento de requisitos del usuario define solamente las características más
importantes del sistema.
2. El sistema se desarrolla en una serie de incrementos. Los usuarios finales y otros
stakeholders del sistema participan en la especificación y evaluación de cada
incremento.
3. A menudo se desarrollan las interfaces de usuario del sistema utilizando un sistema de
desarrollo interactivo que permite que el diseño de la interfaz se cree rápidamente
dibujando y colando iconos en la interfaz.
El desarrollo incremental, implica producir y entregar el software en incrementos más que en
un paquete único. Cada iteración del proceso produce un nuevo incremento del software.
Ventajas principales:
1. Entrega acelerada de los servicios del cliente. Se pueden entregar las funcionalidades
de alta prioridad para que los usuarios puedan aprovechar el sistema desde el principio
de su desarrollo.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 51
2. Compromiso del usuario con el sistema. Los usuarios tienen que estar implicados en el
proceso de desarrollo incremental que proporcionan retroalimentación sobre los
incrementos entregados al equipo de desarrollo.
Modelo de desarrollo rápido de aplicaciones
El desarrollo incremental del software es un enfoque mucho mejor para el desarrollo de la
mayoría de los sistemas de negocio, comercio electrónico y personales porque refleja el modo
fundamental al que todos nosotros tendemos al resolver problemas.
Por supuesto, existen algunos tipos de sistemas donde el desarrollo y entrega rápidos no son el
mejor enfoque. Pueden ser sistemas muy grandes donde el desarrollo puede implicar equipos
que trabajan en diferentes lugares, algunos sistemas embebidos donde el software depende del
desarrollo del hardware y algunos sistemas críticos en los que se deben analizar todos los
requisitos para verificar las interacciones que puedan comprometer la seguridad o protección
del sistema.
Para conseguir algunos de los beneficios del desarrollo incremental, se puede utilizar un
proceso híbrido en el que se desarrolle de forma iterativa un prototipo del sistema y se utilice
como una plataforma para experimentar con los requisitos y diseño del sistema.
Se desarrolla un prototipo del sistema para ayudar a los desarrolladores de software y a los
usuarios a comprender qué se debe implementar.
El desarrollo y el prototipado incremental tienen objetivos diferentes:
1. El objetivo del desarrollo incremental es entregar a los usuarios finales un sistema
funcional. Esto significa que normalmente debe comenzar con los requisitos del
usuario que mejor se comprenda y que tengan la prioridad más alta.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 52
2. El objetivo del prototipado es validar u obtener los requisitos del sistema.
Los sistemas desarrollados incrementalmente se deben desarrollar con los mismos estándares
de calidad de la organización como cualquier otro software. Debe tener una estructura robusta
para que se les pueda dar mantenimiento durante muchos años. Deben ser fiables y eficientes,
y deben estar acordes con los estándares organizacionales apropiados.
El desarrollo rápido de aplicaciones implica la utilización de entornos de desarrollo que
incluyan herramientas para apoyar la producción del sistema. Estas comprenden lenguajes de
programación de bases de datos, generadores de formularios e informes y enlaces a
aplicaciones de oficina.
2. MÉTODOS ÁGILES DE DESARROLLO.
En los años 80’s y principios de los 90’s, existía una opinión general de que la mejor
forma de obtener un mejor software era a través de una planificación cuidadosa del proyecto.
Esta opinión provenía, fundamentalmente, de la comunidad de ingenieros de software
implicada en el desarrollo de grandes sistemas software de larga vida, eran a menudo sistemas
críticos y trabajaban en el software durante largos períodos de tiempo. Estos enfoques,
implican una importante sobrecarga de trabajo en cuanto a la planificación, diseño y
documentación del sistema.
Cuando este enfoque “pesado” de desarrollo basado en la planificación, fue aplicado a
sistemas de negocios pequeños y medianos, el esfuerzo invertido era tan grande que algunas
veces dominaba el proceso de desarrollo del software.
El descontento con estos enfoques pesados condujo a varios desarrolladores de software en los
años 90’s a proponer nuevos métodos ágiles, que permitieron centrarse en el mismo software
en vez de en su diseño y documentación. Los métodos ágiles universalmente dependen de un
enfoque iterativo para la especificación, desarrollo y entrega del software, y principalmente
fueron diseñados para apoyar al desarrollo de aplicaciones de negocio donde los requisitos del
sistema normalmente cambiaban rápidamente durante el proceso de desarrollo.
Probablemente el método ágil más conocido es la Programación Extrema (Beck, 1999-2000).
Otros enfoques ágiles son Scrum (Schwaber y Beedle 2001), Cristal (Cockbum, 2001).
Desarrollo de Software Adaptable (Highsmith 2000), DSDM (Stapleton, 1997) y Desarrollo
Dirigido por Características (Palmer y Felsing, 2002). El éxito de estos métodos ha llevado a
una cierta integración con métodos de desarrollo más tradicionales basados en el modelado de
sistemas, dando por resultado la noción de modelado ágil (Ambler y Jeffries, 2002) y las
instanciaciones ágiles del Proceso Unificado de Rational (Larman, 2002).
Aunque todos estos métodos ágiles se basan en la noción de desarrollo y entrega
incrementales, proponen procesos diferentes para alcanzarla. Comparten un conjunto de
principios y, por lo tanto, tienen mucho en común.
Principio Descripción
Participación del usuario
Los usuarios deben estar fuertemente implicados en todo el
proceso de desarrollo. Su papel es proporcionar y priorizar los
requisitos del sistema y evaluar las iteraciones del sistema.
Entrega incremental El software se desarrolla en incrementos donde el usuario
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 53
especifica los requisitos a incluir en cada incremento.
Personas, no procesos
Reconocer y explotar las habilidades del equipo de desarrollo.
Dejar desarrollar sus propias formas de trabajar, sin procesos
formales, a los miembros del equipo.
Aceptar el cambio Los requisitos del sistema cambian, por lo que el sistema se
diseña para dar cabida a estos cambios.
Mantener la simplicidad
Centrarse en la simplicidad tanto en el software a desarrollar
como en el proceso de desarrollo. Donde sea posible, se trabaja
activamente para eliminar la complejidad del sistema.
Principios de los Métodos Ágiles
Todos los métodos tienen límites, y los métodos ágiles son apropiados para algunos tipos de
desarrollo de sistemas. Los más idóneos para el desarrollo de sistemas de negocio pequeño y
mediano y para el desarrollo de productos para ordenadores personales. No son adecuados
para el desarrollo de sistemas a gran escala con equipos de desarrollo ubicados en diferentes
lugares y donde pueda haber complejas interacciones con otros sistemas hardware o software.
No se deben utilizar métodos ágiles para el desarrollo de sistemas críticos en los que es
necesario un análisis detallado de todos los requisitos del sistema para comprender sus
implicaciones de seguridad o protección.
PROGRAMACION EXTREMA
La Programación Extrema (XP) es posiblemente el método ágil más conocido y ampliamente
utilizado (Beck, 2000), debido a que el enfoque fue desarrollado utilizando buenas prácticas
de programación reconocidas, como el desarrollo iterativo, pruebas sistemáticas, la coninua
mejora del software y la participación del usuario en el equipo de desarrollo.
En la programación extrema, todos los requisitos se expresan como escenarios (llamados
historias de usuario), los cuales se implementan directamente como una serie de tareas. Los
programadores trabajan en parejas y desarrollan pruebas para cada tarea antes de escribir el
código.
La programación extrema implica varias prácticas, que se ajustan a los principios de métodos
ágiles:
1. Desarrollo incremental
2. Participación del usuario
3. Interés en las personas, en vez en los procesos
4. El cambio se lleva a cabo a través de las entregas regulares del sistema.
5. El mantenimiento de la simplicidad se lleva a cabo a través de la refactorización
constante.
En el proceso de la XP, los usuarios están fuertemente implicados en la especificación y
establecimiento de prioridades de los requisitos del sistema. Los usuarios del sistema son parte
del equipo de desarrollo. Desarrollan conjuntamente una “tarjeta de historias” (storyboard)
que recoge las necesidades de los usuarios.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 54
Una vez que se han desarrollado las tarjetas de historia, el equipo de desarrollo las divide en
tares y estima el esfuerzo y recursos requeridos para su implementación. El usuario establece
la prioridad de las historias a implementar.
Algo particular de la programación extrema es el desarrollo de pruebas automatizadas antes de
que se cree una funcionalidad en un programa. Se deben ejecutar de forma satisfactoria todas
las pruebas cuando se integra un incremento en un sistema.
Un precepto fundamental de la ingeniería de software tradicional es que se debe diseñar para
el cambio. Esto es, hay que prever los cambios futuros en el software y diseñar éste de forma
que tales cambios se puedan implementar fácilmente.
La programación extrema aborda este problema sugiriendo que se debe refactorizar
constantemente el software. Esto significa que el equipo de programación busca posibles
mejoras del software y las implementa inmediatamente. Por lo tanto, el software siempre debe
ser fácil de entender y cambiar cuando se implementen nuevas historias.
3. REUTILIZACIÓN DEL SOFTWARE.
La ingeniería de software basada en reutilización es una estrategia del software
comparable en la que el proceso de desarrollo es adaptado a la reutilización de software
existente. La tendencia hacia el desarrollo basado en reutilización viene dada como respuesta
a las demandas de una menor producción de software y de menor costo de mantenimiento, de
una entrega más rápida de los sistemas y del incremento en la calidad del software.
Las unidades de software que se reutilizan pueden ser de tamaño totalmente diferentes:
1. Reutilización de aplicaciones. Una aplicación puede ser reutilizada totalmente sin
ningún cambio en otros sistemas, configurando la aplicación para diferentes clientes.
2. Reutilización de componentes. La reutilización de componentes varía en tamaño,
puede ser la reutilización de un subsistema o la reutilización de un simple objeto.
3. Reutilización de objetos y funciones. Pueden reutilizarse componentes software que
implementan una única función, como ejemplo una función matemática o una clase de
objetos. Están disponibles muchas librerías de funciones y clases para diferentes tipos
de aplicaciones y plataformas de desarrollo. Es particularmente efectiva en áreas como
algoritmos matemáticos y gráficos, donde se necesita a un experto específico para
desarrollar objetos y funciones.
Los sistemas y componentes software son entidades reutilizables, pero su naturaleza
específica significa a veces, que el costo de modificarlos para una nueva situación resulte
elevado. La reutilización de conceptos puede incluirse en aproximaciones tales como patrones
de diseño, productos de sistemas configurables y generadores de programas.
La ventaja obvia de la reutilización del software se da en los costos de desarrollo. Se necesita
menos especificar, diseñar, implementar y validar componentes de software.
CAMPOS DE LA REUTILIZACIÓN
En los últimos años, se han desarrollado muchas técnicas para soportar la reutilización del
software. Esta reutilización es posible a diferentes niveles (desde funciones simples a
aplicaciones completas), y los estándares para componentes reutilizables facilitan la
reutilización.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 55
Los factores claves que deberían considerarse a la hora de planificar la reutilización son:
1. La agenda de desarrollo del software. Si el software tiene que desarrollarse
rápidamente.
2. Vida esperada del software. Si se está desarrollando un sistema de larga vida, haría
que centrarse en la mantenibilidad del sistema.
3. Los conocimientos, habilidades y experiencia del grupo de desarrollo. Todas las
tecnologías de reutilización son bastante complejas y se necesita bastante tiempo para
comprenderlas y usarlas de forma efectiva.
4. La criticidad del software y sus requisitos no funcionales. Se tiene que crear un caso
de confiabilidad para el sistema. Es difícil si no se tiene acceso al código fuente del
software.
5. El dominio de las aplicaciones. Hay varios productos genéricos que pueden
reutilizarse para configurarlos a una situación particular.
6. La plataforma sobre la que el sistema se va a ejecutar.
Campos de la reutilización
PATRONES DE DISEÑO
Una forma de reutilizar diseños abstractos que no incluyen detalles de la implementación y
que se ajusten a los requisitos particulares de la aplicación ha sido incluida en los patrones de
diseño.
Los patrones de diseño se derivaron de las ideas introducidas por Cristopher Alexander
(1977), quien sugirió que existían ciertos patrones de diseño de edificios que eran comunes e
inherentemente, interesantes y efectivos. El patrón es una descripción del problema y la
esencia de su solución, de forma que la solución se pueda reutilizar en diferentes situaciones.
El patrón no es una especificación detallada, puede pensarse en él como una descripción del
conocimiento y experiencia acumulados. Es una solución adecuada a un problema común.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 56
Los patrones y los lenguajes de patrones son formas de describir las mejores prácticas, buenos
diseños y encapsulan la experiencia de tal forma que es posible para otros el reutilizar dicha
experiencia.
Un patrón de diseño es una plantilla para una solución de diseño que puede instanciarse de
diferentes formas. A menudo ésta se expresa gráficamente y se muestra en la solución las
relaciones entre los objetos y las clases de los objetos.
Actualmente están disponibles un elevado número de patrones publicados que abarcan varios
dominios de aplicación y lenguajes. La noción de un patrón como un concepto reutilizable ha
sido desarrollada en varias áreas además del diseño software, que incluye gestión de
configuración, diseño de interfaz de usuario y escenarios de interacciones.
El uso de patrones es una forma efectiva de reutilización. Sin embargo, se puede afirmar que
sólo ingenieros de software experimentados que tengan un conocimiento profundo de patrones
pueden utilizarlos de forma efectiva.
MARCO DE TRABAJO (FRAMEWORK)
Un marco de trabajo es un diseño de un sistema formado por una colección de clases
concretas y abstractas y la interfaz entre ellas. Son implementados los detalles particulares del
subsistema de la aplicación añadiendo componentes y proporcionando implementaciones
concretas de las clases abstractas en el marco de trabajo. Los marcos de trabajo raramente son
aplicaciones por sí mismos. Las aplicaciones se construyen normalmente integrando varios
marcos de trabajo.
Un marco de trabajo es una estructura genérica que puede ser extendida para crear un
subsistema o aplicación más específico. Es implementado como una colección de clases de
objetos concretas y abstractas.
Uno de los marcos de trabajo más conocido y usado ampliamente para el diseño de GUIs es el
marco Modelo-Vista-Controlador (MVC). Fue propuesto en la década de los 80’s como una
aproximación de diseño GUIs. El marco MVC soporta la presentación de los datos de
diferentes formas e interacciones independientes de cada una de estas presentaciones. Cuando
los datos se modifican a través de una de las presentaciones, el resto de las presentaciones son
actualizadas.
Los marcos de trabajo son a menudo instanciaciones de varios patrones.
Las aplicaciones construidas utilizando marcos de trabajo pueden ser las bases para una
posterior reutilización a través del concepto de líneas de productos software o familias de
aplicaciones.
El problema fundamental con los marcos de trabajo es su complejidad y el tiempo que lleva
aprender a utilizarlos, algunos ingenieros de software se convierten en especialistas en marcos
de trabajo.
REUTILIZACION DE SISTEMAS DE APLICACIONES
La reutilización de sistemas de aplicaciones implica reutilizar sistemas de aplicaciones
completos, configurándolo para un entorno específico o integrando dos o más sistemas para
crear una nueva aplicación. Se analizan dos tipos de reutilización de aplicaciones: el
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 57
desarrollo de líneas de productos y la creación de nuevos sistemas integrando dos o más
aplicaciones comerciales.
Una línea de productos es una conjunto de sistemas software basados en una arquitectura
base común y componentes compartidos.
En la actualidad, es normal para los sistemas grandes, tener definidas Interfaces de
Programación de Aplicaciones (APIs) que permiten programar el acceso a las funciones de
dichos sistemas. Se consideran como una opción de diseño los sistemas como comercio
electrónico mediante la integración de sistemas COTS.
4. INGENIERÍA DEL SOFTWARE BASADO EN COMPONENTES.
La Ingeniería de Software Basada en Componentes (CBSE) surgió a finales de los 90’s
como una aproximación basada en reutilización al desarrollo de sistemas software.
CBSE es una aproximación basada en la reutilización para definir, implementar e integrar
componentes independientes debidamente acoplados para formar sistemas. Se ha convertido
en una importante aproximación de desarrollo del software debido a que los sistemas software
son cada vez más grandes y más complejos y los clientes demandan software más confiable
que sea desarrollado más rápidamente.
Los fundamentos de la ingeniería del software basada en componentes son:
1. Componentes independientes. Debería haber una clara separación entre la interfaz de
los componentes y su implementación, para reemplazarse por otro sin cambiar el
sistema.
2. Estándares de componentes. En un modelo de componentes se incluyen estándares. Si
los componentes cumplen con los estándares, entonces su funcionamiento es
independiente del lenguaje de programación. Pueden integrarse en el mismo sistema
componentes escritos en diferentes lenguajes.
3. El middleware. Proporciona soporte software para la integración de componentes. Un
producto middleware como CORBA, maneja cuestiones de bajo nivel de forma
eficiente y permite al diseñador centrarse en problemas relacionados con la aplicación.
Un producto middleware puede proporcionar soporte para asignación de recursos,
gestión de transacciones, seguridad y concurrencia.
4. Un proceso de desarrollo. Si se intenta añadir una aproximación basada en
componentes a un proceso de desarrollo que está adaptado a la producción de software
original, se puede observar que las suposiciones inherentes al proceso limitan el
potencial del CBSE.
La ingeniería de software basada en reutilización se está convirtiendo en la principal
aproximación de desarrollo para sistemas comerciales y de empresas. Las entidades que son
reutilizadas varían desde funciones hasta sistemas completos. Los componentes pueden
interoperar dentro de un marco de trabajo como CORBA.
Se está adoptando cada vez más el desarrollo basado en componentes como una aproximación
fundamental en la ingeniería de software. CBSE está asentado sobre principios de diseño
sólidos, para la construcción de software comprensible y mantenible. Son independientes los
componentes para no interferir en su funcionamiento unos con otros. Los componentes se
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 58
comunican a través de interfaces bien definidas, las infraestructuras de componentes
proporcionan plataformas de alto nivel que reducen los costos del desarrollo de aplicaciones.
La Ingeniería de Software Basada en Componentes presenta algunos problemas:
1. Confiabilidad de los componentes. Los componentes son cajas negras. Puede el
componente no tener documentado los modos de fallo. Puede su comportamiento no
funcional no ser el esperado.
2. Certificación de componentes. Certificar que los componentes cumplen una
especificación formal. Sin embargo, la industria no parece dispuesta a pagar por esto.
3. Predicción de propiedades emergentes. Todos tienen propiedades emergentes, y el
intentar predecir y controlar estas propiedades es importante en el proceso de
desarrollo del sistema.
4. Equilibrio de requisitos. Encontrar un equilibrio entre los requisitos y los
componentes disponibles en el proceso de especificación y diseño del sistema.
Alcanzar este equilibrio es un proceso intuitivo. Necesitamos un método de análisis de
equilibrio sistemático y más estructurado para ayudar a los diseñadores a seleccionar y
configurar componentes.
Hasta ahora, el principal uso de CBSE se ha dado en la construcción de sistemas de
información de empresas, tales como sistemas de comercio electrónico.
COMPONENTES Y MODELOS DE COMPONENTES
Un componente es una unidad de software cuya funcionalidad y dependencias están
completamente definidas por un conjunto de interfaces públicas. Los componentes pueden
combinarse con otros componentes sin hacer referencia a su implementación y pueden ser
desplegados como una unidad ejecutable.
También se considera un componente como un proveedor de servicios independiente.
Cuando un sistema necesita algún servicio, llama a un componente para proporcionar dicho
servicio sin tener en cuenta dónde se está ejecutando o en qué lenguaje se ha desarrollado. Se
resalta dos características críticas de un componente reutilizable:
1. El componente es una entidad ejecutable independiente.
2. Los servicios ofertados por un componente están disponibles a través de una interfaz, y
todas las interacciones son a través de esa interfaz.
Características del
Componente Descripción
Estandarizado
Un componente tiene que ajustarse a algún modelo estandarizado.
Este modelo puede definir las interfaces de los componentes, los
metadatos de componentes, la documentación, la composición y
despliegue.
Independencia Debería componerse y desplegarse sin tener que utilizar otros
componentes específicos.
Componible Para que un componente sea componible, todas las interacciones
externas deben tener lugar a través de interfaces definidas
públicamente. Debe proporcionar acceso externo a la información
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 59
sobre sí mismo, como por ejemplo a sus métodos y atributos.
Desplegable
Un componente debe ser independiente y debe ser capaz de funcionar
como una entidad autónoma o sobre una plataforma de componentes
que implemente el modelo de componentes. El componente es
binario y no tiene que compilarse antes de ser desplegado.
Documentado
Los componentes tienen que estar completamente documentados para
que los usuarios potenciales puedan decidir si los componentes
satisfacen o no sus necesidades.
Características del Componente
La visión de un componente como un proveedor de servicios resalta dos características críticas
de un componente reutilizable:
1. El componente es una entidad ejecutable independiente.
2. Los servicios ofertados por un componente están disponibles a través de una interfaz, y
todas las interacciones son a través de esa interfaz.
Un modelo de componentes define un conjunto de estándares para componentes, incluyendo
estándares de interfaz, estándares de uso y estándares de despliegue. La implementación del
modelo de componentes proporciona un conjunto de servicios horizontales que pueden ser
utilizados por todos los componentes.
Se han propuesto muchos modelos de componentes: CORBA de OMG, el modelo Enterprise
Java Beans de Sun y el modelo COM+ de Microsoft.
Los elementos en un modelo de componentes pueden clasificarse como elementos
relacionados con las interfaces de los componentes, elementos relacionados con la
información que se necesita para utilizar el componente en un programa y elementos
relacionados con el despliegue del componente.
El modelo de componentes especifica cómo deberían definirse las interfaces y los elementos,
tales como nombres de operaciones, parámetros y excepciones, que deberían incluirse en la
definición de una interfaz.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 60
Elementos básicos de un modelo de componentes
Una parte importante del modelo de componentes es la definición de cómo los componentes
deberían empaquetarse para su despliegue como entidades ejecutables independientes.
Los modelos de componentes son también la base para el middleware de sistemas que
proporciona el soporte para los componentes ejecutables.
Algunas actividades del proceso CBSE:
1. Los requisitos del usuario se desarrollan inicialmente en forma de esquema en lugar de
forma detallada. Se necesita el conjunto completo de requisitos con el fin de que se
puedan identificar los componentes para su reutilización tanto como sea posible.
2. Son refinados y modificados los requisitos en etapas tempranas del proceso
dependiendo de la disponibilidad de los componentes.
3. Después de que la arquitectura del sistema haya sido diseñada, hay una actividad
adicional de búsqueda de componentes y refinamiento de diseño.
4. El desarrollo es un proceso de composición en el que se integran los componentes
descubiertos.
La composición de componentes es el proceso de ensamblar los componentes para crear un
sistema.
La forma como los componentes se integran a la infraestructura son documentadas en cada
modelo de componentes. No es una operación sencilla la composición, existen varios tipos de
composiciones:
1. Composición secuencial. Los componentes constituyentes se ejecutan en secuencia.
2. Composición jerárquica. Un componente realiza una llamada directamente a los
servicios proporcionados por otro componente.
3. Composición aditiva. Las interfaces de dos o más componentes se unen para crear un
nuevo componente.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 61
PRUEBAS DEL SOFTWARE
Las pruebas de software consisten de una verificación dinámica del comportamiento
de un programa en un conjunto finito de casos de prueba, seleccionado adecuadamente desde
el dominio de ejecuciones usualmente infinitas, versus el comportamiento esperado. Esto
incluye cinco áreas.
Fundamentos de las pruebas de software. Terminología, aspectos claves y las
relaciones de pruebas con otras actividades.
Niveles de prueba. Con respecto a las metas de las pruebas y los objetivos de las
pruebas.
Técnicas de prueba. La primera categoría incluye las pruebas basadas en la intuición
del probador y la experiencia. En la segunda categoría las técnicas basadas en las
especificaciones, las técnicas basadas en el código, técnicas basadas en las faltas, las
técnicas basadas en el uso, y las técnicas relativas a la naturaleza de la aplicación.
Seleccionar y combinar las técnicas de modo apropiado.
Medidas relacionadas a las pruebas. Las medidas están agrupadas con relación a la
evaluación del programa bajo prueba y la evaluación de las pruebas ejecutadas.
Proceso de prueba. Incluye las consideraciones prácticas y las actividades de prueba.
Desglose de los tópicos de pruebas de software según SWEBOK
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 62
1. FUNDAMENTOS DE LAS PRUEBAS.
Las pruebas es una actividad ejecutada para la evaluación de la calidad del producto, y
para mejorar este, identificando los defectos y los problemas. Las pruebas solo pueden
demostrar la presencia de errores en un programa. No pueden demostrar que no hay más
defectos.
La visión de las pruebas de software ha evolucionado hacia algo más constructivo. Las
pruebas ya no se consideran una actividad que se inicia sólo después que haya completado la
fase de codificación, con el propósito limitado de detectar fallas. Las pruebas de software son
ahora visto como una actividad que debe abarcar todo el proceso de desarrollo y
mantenimiento y es en sí una parte importante de la construcción real del producto. Es más, la
planificación para la realización de las pruebas debe comenzarse con las primeras etapas del
proceso de requisitos, y los planes y procedimientos de prueba pueden ser sistemáticamente
continuadas durante el desarrollo.
Muchos términos son utilizados en la literatura de ingeniería de software para describir un mal
funcionamiento, notablemente defecto, falla, error. Es esencial distinguir la causa, para que el
término defecto se utilice, y el efecto observado indeseado en el servicio entregado del
sistema, que se llama un falla. Las pruebas pueden revelar las fallas y los defectos deben ser
eliminados.
Las pruebas están relacionadas con otras actividades como:
Pruebas vs. técnicas de gestión de la calidad del software.
Pruebas vs. pruebas de exactitud y verificación formal.
Pruebas vs. depuración.
Pruebas vs. programación.
Las pruebas son un proceso que intenta proporcionar confianza en el software.
2. NIVELES DE PRUEBAS.
Las pruebas del software usualmente son ejecutadas en diferentes niveles a lo largo de
los procesos de desarrollo y mantenimiento. Se pueden distinguir tres grandes niveles de
prueba:
1. Prueba de unidad. Verifica el funcionamiento aislado de una porción del software
probado separadamente. Dependiendo del contexto, serán subprogramas individuales o
un componente hecho de unidades relacionadas. Usualmente una prueba de unidad
accede al código probado y soporta herramientas de depuración, e involucra a los
programadores que hicieron el código.
2. Prueba de integración. Las pruebas de integración es el proceso de verificar la
interacción entre los componentes del software. Las estrategias de integración
sistemática modernas son impulsadas por la arquitectura, lo que implica la integración
de los componentes de software. Las pruebas de integración es una actividad continua,
del cual los ingenieros de software pueden concentrarse en las perspectivas del nivel
que están integrando.
3. Prueba de sistema. La prueba de sistema es concerniente al comportamiento del
sistema completo. La mayoría de las fallas funcionales son identificadas durante la
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 63
prueba de unidad e integración. La prueba de sistema es usualmente considerada
apropiada para comparar el sistema con los requisitos no funcional, así como la
seguridad, la velocidad, exactitud, y fiabilidad. Las interfaces externas a otras
aplicaciones, utilidades, dispositivos hardware, o el ambiente operacional son también
evaluados en este nivel.
Pruebas por objetivo
Las pruebas son conducidas por algún objetivo específico, el cual es más o menos explícito, y
con diversos grados de precisión. Afirmar el objetivo con precisión y los términos
cuantitativos permite el control que se establecerá el proceso de prueba. Las pruebas pueden
ser destinadas a la verificación de diferentes propiedades. Los casos de prueba pueden ser
diseñados para chequear que las especificaciones funcionales sean implementadas
correctamente, el cual es variablemente referido en la literatura como prueba de conformidad,
pruebas de corrección, o prueba funcional. Sin embargo, otros propósitos no funcionales
diferentes pueden ser probados como performance, fiabilidad y usabilidad, entre muchas otras.
PRUEBA DE ACEPTACION
La prueba de aceptación chequea el comportamiento del sistema con los requisitos de los
clientes, los clientes chequean que sus requisitos se hayan cumplido.
PRUEBAS ALFA Y BETA
Antes de que el software sea liberado, es a veces entregado a un pequeño grupo de usuarios
potenciales, interno (prueba alfa) o externo (prueba beta). Los cuales informan los problemas
a los desarrolladores del sistema. Después de esta retroalimentación, el sistema se modifica y
se entrega ya sea para una prueba beta adicional o para la venta. A menudo, el uso de alfa y
beta es incontrolado, y no siempre es mencionado en un plan de prueba.
PRUEBA DE REGRESION
Las pruebas de regresión es la reprueba selectiva de un sistema o componente para verificar
que las modificaciones no han causado efectos no deseados. Beizer lo define como una
repetición de las pruebas destinadas a mostrar que el software no sea cambiado, excepto en la
medida que es requerido. La prueba de regresión puede ser conducida en cada uno de los
niveles de prueba descritos antes. El objetivo de la prueba es aplicado a las pruebas
funcionales y no funcionales.
PRUEBA DE RENDIMIENTO
Una vez que un sistema se ha integrado completamente, es posible probar las propiedades
emergentes del sistema tales como rendimiento y fiabilidad. Implica planificar una serie de
pruebas en las que la carga se va incrementando regularmente hasta que el rendimiento del
sistema se hace inaceptable. Las pruebas de rendimiento implican estresar el sistema
realizando demandas que están fuera de los límites del diseño del software.
PRUEBA DE STRESS
Los ejercicios de prueba de stress del software en el diseño máximo de carga, como fuera de
ella.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 64
PRUEBAS DE RECUPERACION
Pruebas de recuperación es encaminadas para verificar las capacidades de reinicio después de
un “desastre”.
PRUEBA DE CONFIGURACION
En los casos donde el software es construido para servir a los diferentes usuarios, la prueba de
configuración analiza el software bajo varias configuraciones especificadas.
PRUEBAS DE USABILIDAD
Este proceso evalúa cuán fácil es para los usuarios finales usar y aprender del software,
incluyendo la documentación del usuario y la habilidad de los usuarios para recuperarse
después de algún error.
4. TECNICAS DE PRUEBAS.
Uno de los objetivos de las pruebas es revelar la mayor cantidad de posibilidades de
fracaso como sea posible, y muchas técnicas han sido desarrolladas para esto. El principio
fundamental que subyace a las técnicas es hacer sistemática la identificación de un conjunto
de comportamientos del programa.
Es difícil encontrar una clasificación homogénea de técnicas. La clasificación está basada en
como las pruebas son generadas desde la intuición y experiencia de los ingenieros de software,
las especificaciones, la estructura del código, las fallas (real o artificial) a descubrir, el ámbito
de uso, o la naturaleza de la aplicación. Algunas veces estas técnicas son clasificadas como
caja-blanca, si las pruebas utilizan una perspectiva interna del sistema para diseñar los casos
de prueba basados en la estructura interna. Requiere de habilidades de programación
identificar todas las trayectorias a través del software; o como caja-negra donde nos
interesará su forma de interactuar con el medio que le rodea entendiendo qué es lo que hace,
pero sin dar importancia a cómo lo hace. Por tanto, deben estar muy bien definidas sus
entradas y salidas, es decir, su interfaz; y no se precisa definir ni conocer los detalles internos
de su funcionamiento. Una última categoría ofrece el uso combinado de dos o más técnicas.
BASADO EN LA INTUICIÓN Y EXPERIENCIA
PRUEBA AD-HOC
La técnica más practicada, se obtienen apoyándose en la habilidad, intuición y experiencia del
ingeniero de software con programas similares. La prueba ad hoc pueden usarse para
identificar las pruebas especiales, no fácilmente capturadas por técnicas formalizadas.
PRUEBAS DE EXPLORACIÓN
Las pruebas de exploración es definida como aprendizaje simultáneo, diseño de la prueba, y
ejecución de la prueba. Las pruebas no son definidas de acuerdo a un plan de prueba
establecido, son diseñadas, ejecutadas y modificadas dinámicamente. La efectividad de las
pruebas exploratorias depende del conocimiento de los ingenieros de software, el cual puede
ser derivado de varias fuentes: el comportamiento del producto observado durante la prueba,
la familiaridad con la aplicación, la plataforma, las fallas, el tipo de defecto posible.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 65
TÉCNICAS BASADAS EN LA ESPECIFICACIÓN
PARTICIÓN EQUIVALENTE
El dominio de la entrada es subdividido en una colección de subconjuntos, o clases
equivalentes, el cual son considerados equivalente de acuerdo a una relación específica, y un
conjunto representativo de pruebas (algunas veces solo una) tomadas en cada clase.
ANÁLISIS DE VALOR LÍMITE
Los casos de prueba son elegidos cerca de las fronteras del dominio de entradas, con la idea de
que las fallas tienden a concentrar cerca de los valores extremos de las entradas. Una
extensión de esta técnica es la técnica de prueba de robustez, donde los casos de prueba son
también elegida fuera del dominio de entrada, para probar la robustez del programa en
entradas no esperadas o erróneas.
TABLA DE DECISIÓN
Las tablas de decisión representan las relaciones lógicas entre las condiciones (entradas) y las
acciones (salidas). Los casos de prueba son sistemáticamente derivadas por consideración
cada combinación posible de condiciones y acciones. Técnica relacionada son los gráficos
causa-efecto.
MÁQUINA BASADA EN ESTADO FINITO
Modelar un programa como una máquina de estado finito, las pruebas pueden ser
seleccionadas en orden a cubrir los estados y transiciones en esta.
PRUEBAS DESDE LAS ESPECIFICACIONES FORMALES
Las especificaciones en un lenguaje formal, permiten la desviación automática de casos de
prueba funcionales, y, al mismo tiempo, brinda una salida referencial, en oracle, para la
verificación de los resultados de las pruebas. Existen métodos para derivar los casos de prueba
desde especificaciones basado en modelos o especificaciones algebraicas.
PRUEBAS RANDOM
Las pruebas son generadas de modo aleatorio. Esta forma de prueba está entre la partida de la
entrada basada en la especificación, donde al menos la entrada de dominio debe ser conocido,
y ser capaz de recoger los puntos aleatorios dentro de este.
TÉCNICAS BASADAS EN EL CÓDIGO
CRITERIO BASADO EN EL FLUJO DE CONTROL
Estas pruebas están encaminadas a cubrir todas las sentencias o bloques de sentencias en un
programa. El criterio basado flujo de control más fuerte es la prueba de ruta, el cual ayuda a
ejecutar todas las rutas de flujo de control entrada-a-salida en el grafico de flujo. Donde el
camino de pruebas por lo general no es factible debido a los bucles, otros criterios menos
estrictos tienden a ser utilizados en la práctica, así como la prueba de sentencia, pruebas
branck (rama), y pruebas de condición. La adecuación de estas pruebas se mide en
porcentajes.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 66
CRITERIO BASADO EN FLUJO DE DATOS
Son métodos que generan los casos de prueba basándose en el conocimiento de las
operaciones que se realizan sobre las variables en el programa bajo prueba. La idea principal
es cubrir subcaminos del programa bajo prueba en los que aparezca una determinada variable
o variables. El grafo de flujo es utilizado para guardar información de las variables en sus
nodos y los criterios de cobertura se refieren a cobertura de elementos relacionados con una o
varias variables.
MODELOS REFERENCIALES PARA PRUEBA BASADA EN EL CÓDIGO
(FLUJOGRAMA, LLAMADO GRÁFICO)
Aunque no es una técnica en sí misma, la estructura de control de un programa es
representado gráficamente usando diagramas de flujo en técnicas de prueba basada en el
código. Un diagrama de flujo es un gráfico con nodos y arcos que corresponden a elementos
de programa. Por ejemplo, los nodos pueden representar las sentencias o las sentencias no
interrumpidas, y los arcos la transferencia del control entre los nodos.
TÉCNICAS BASADAS EN LAS FALLAS
Las técnicas basadas en fallas tienen grados diferentes de formalización
ADIVINANZA DE ERRORES
Los casos de prueba son específicamente diseñados por los ingenieros de software tratando de
averiguar los fallos más plausibles en un determinado programa. Una buena fuente de
información es la historia de las fallas descubiertas, así como la experiencia de los ingenieros
de software.
LA PRUEBA DE MUTACIÓN
Un mutante es una versión de programa ligeramente modificado en el código, cambio
sintáctico. Los casos de prueba ejecutan la versión original y todos los mutantes generados: si
existe diferencia en un caso de prueba entre el programa original y un mutante, este último se
dice que está “killed” muerto. Originalmente concebido como una técnica para evaluar un
conjunto de pruebas, la prueba de mutación es también un criterio de prueba en sí misma:
cualquiera de las pruebas son generadas al azar hasta que un número suficiente de mutantes
hayan sido killed, o las pruebas son específicamente diseñadas para matar mutantes
sobrevivientes. En el último caso, la prueba de mutación puede también ser categorizada como
una técnica basada en el código. El efecto de las pruebas de mutación, es que al hacer una
falla sistemática, se encontrarán fallas reales más complejas. Para que esta técnica sea
efectiva, puede ser derivado automáticamente un gran número de mutantes de una manera
sistemática.
TÉCNICAS BASADAS EN EL USO
PERFIL OPERACIONAL
El ambiente de prueba en la prueba para la evaluación de la fiabilidad puede reproducir el
ambiente operacional del software. La idea es inferir, los resultados de las pruebas observadas,
la futura fiabilidad del software. Para hacer esto, las entradas son asignadas en una
distribución de probabilidad, o perfil, de acuerdo a la ocurrencia en la operación actual.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 67
PRUEBA DE LA INGENIERÍA DE FIABILIDAD DE SOFTWARE
La prueba de ingeniería de fiabilidad de software (SRET) consiste en un método de prueba
acompañado del proceso de desarrollo, la prueba es “diseñada y guiada por objetivos de
fiabilidad y el uso relativo esperado y críticamente de funciones diferentes en el campo”.
TÉCNICAS BASADAS EN LA NATURALEZA DE LA APLICACIÓN
Las técnicas mencionadas se aplican a todos los tipos de software. Sin embargo, para algunos
tipos de aplicaciones, conocimiento adicional es requerido para la derivación de la prueba. A
continuación una lista de pruebas especializadas, basadas en la naturaleza de la aplicación:
Prueba orientada a objetos
Prueba basada en componentes
Prueba basada en web
Prueba GUI
Prueba de programas concurrentes
Protocolo de pruebas de conformidad
Prueba de sistemas de tiempo real
Prueba de sistema esenciales para la seguridad
TÉCNICAS DE SELECCIÓN Y COMBINACIÓN
FUNCIONAL Y ESTRUCTURAL
Técnicas basadas en la especificación y basadas en el código son contrastadas como pruebas
funcionales versus pruebas estructurales. Estos dos enfoques de selección de pruebas no son
vistas como alternativas complementarias; en efecto, usan diferentes fuentes de información y
han demostrado poner de relieve los distintos tipos de problemas. Ellos podrían ser utilizados
en combinación, dependiendo de consideraciones presupuestarias.
DETERMINÍSTICA VS RANDOM
Pueden ser seleccionados los casos de prueba de una manera determinística, de acuerdo a una
de las varias técnicas listadas, o al azar extraída de la distribución de entradas, así como es
usualmente hecha en la prueba de fiabilidad. Han sido conducidas diversas comparaciones
analíticas y empíricas para analizar las condiciones que hacer un enfoque más eficaz que la
otra.
5. PROCESO DE PRUEBAS.
Los conceptos de prueba, estrategias, técnicas y medidas necesitan ser integradas en un
proceso definido y controlado ejecutado por personas. El proceso de prueba soporta las
actividades de prueba y brinda la guía al equipo de prueba, desde la planificación de la prueba
a la evaluación de las salidas, una manera de brindar una garantía justificada a los objetivos de
prueba según el costo-efectividad.
CONSIDERACIONES PRÁCTICAS
ACTITUDES/PROGRAMACIÓN EGOLESS
Las pruebas y el aseguramiento de la calidad hay que realizarlas de modo colaborativo. Los
administradores tienen un rol clave en la recepción favorable generalmente hacia las fallas
descubiertas durante el desarrollo y mantenimiento; por ejemplo, prevenir la mentalidad de la
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 68
propiedad del código entre programadores, ellos no se sienten responsables de las fallas
reveladas por su código.
GUÍA DE PRUEBAS
La fase de pruebas podría guiarse por diversos objetivos, por ejemplo: en pruebas basadas en
el riesgo, el cual usa los riesgos del producto para priorizar y enfocar la estrategia de prueba; o
en pruebas basadas en escenario, en el cual los casos de prueba son definidas basados en
escenarios de software específicos.
GESTIÓN DEL PROCESO DE PRUEBA
Pueden ser organizadas las actividades de prueba en niveles diferentes, junto con las personas,
herramientas, políticas y mediciones, en un proceso bien definido el cual es una parte integral
del ciclo de vida. En el estándar IEEE/EIA 12207.0, las pruebas no están descritas como un
proceso stand-alone, pero los principios para las actividades de prueba están incluidas a lo
largo de los 5 procesos de ciclo de vida y el proceso de soporte. En IEEE Std. 1074, la prueba
es agrupada con otras actividades de evaluación como integral en el ciclo de vida completo.
DOCUMENTACIÓN DE LAS PRUEBAS Y LOS PRODUCTOS TRABAJO
La documentación es una parte integral de la formalización del proceso de prueba. El estándar
IEEE para documentación de prueba de software (IEEE829-98) brinda una buena descripción
de los documentos de prueba y de su relación con otro proceso. Los documentos de prueba
pueden incluir, entre otros, Plan de Pruebas, Especificación de diseño de prueba,
especificación del procedimiento de prueba, especificación de caso de prueba, log de pruebas
e Incidencias de prueba o Reporte de programa. El software bajo la prueba es documentado
como el campo de prueba. Es documentado el software utilizado para las pruebas. La
documentación de las pruebas es producida y actualizada continuamente, con el mismo nivel
de calidad como otros tipos de documentación en ingeniería de software.
EQUIPO DE PRUEBA INTERNO VS INDEPENDIENTE
La formalización del proceso de prueba puede incluir también la formalización de la
organización del equipo de pruebas. El equipo de prueba puede estar compuesto de miembros
internos (el equipo del proyecto, involucrado o no en la construcción del software), miembros
externos, brinden de modo imparcial una perspectiva independiente o, finalmente, de
miembros internos y externos. Puede determinarse algunas consideraciones de costos,
calendario, niveles de madurez de las organizaciones involucradas, y críticamente de la
aplicación.
ESTIMACIÓN COSTO/ESFUERZO Y OTRAS MEDIDAS DE PROCESO
Los administradores utilizan para controlar y mejorar el proceso de pruebas, diferentes
medidas relacionadas a los recursos utilizados en las pruebas, así como la búsqueda eficaz de
falla de las diversas fases de prueba. Estas medidas de prueba pueden cubrir aspectos como el
número de casos de prueba especificados, número de casos de prueba ejecutadas, número de
casos de prueba probadas, y número de caso de pruebas falladas, entre otras.
La evaluación de los reportes de pruebas pueden ser combinada con el análisis de la causa raiz
para evaluar la efectividad del proceso de prueba tan pronto haya sido posible encontrar las
fallas. Además, los recursos utilizados para las pruebas deberán ser de acorde con el
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 69
uso/crítico de la aplicación: las técnicas tienen diferentes costos y diferentes niveles de
confidencia de la fiabilidad del producto.
TERMINACIÓN
La decisión de culminación de las pruebas debe darse cuando es suficiente la cantidad de
pruebas ejecutadas. Minuciosas medidas, así como la cobertura del código logrado o la
integridad funcional, así como estimar la densidad de fallas o la fiabilidad operacional,
constituye una ayuda valiosa, pero no es suficiente en sí misma. La decisión también envuelve
consideraciones sobre los costos y riesgos incurridos por el potencial de las fallas, en
contraposición a los costos que implica continuar la prueba.
EL REUSO DE LA PRUEBA Y LOS PATRONES DE PRUEBA
Para llevar a cabo las pruebas en forma organizada y rentable, los medios utilizados para
probar cada parte del software será reusado sistemáticamente. El repositorio de material de
pruebas puede estar bajo el control de la gestión de configuración del software, así los
cambios en los requisitos o el diseño del software puede estar reflejado en cambios al alcance
de las pruebas conducidas.
Las soluciones adoptadas en las pruebas de algún tipo de aplicación bajo ciertas
circunstancias, con la motivación de las decisiones tomadas, forman un patrón de prueba que
puede ser documentado para un reuso posterior en proyectos similares.
ACTIVIDADES EN LAS PRUEBAS
Es dado una breve descripción de actividades de prueba. La administración de las actividades
de prueba depende del proceso de Gestión de Configuración del Software.
PLANIFICACIÓN
Al igual que cualquier otro aspecto de gestión de proyectos, las actividades de pruebas pueden
ser planificadas. Los aspectos claves de la planificación de las pruebas incluyen la
coordinación de personal, gestión de facilidades de prueba disponibles y equipamiento (el cual
puede incluir media magnética, planes de prueba y procedimientos), y planificación para
posibles resultados indeseables. Si se mantiene más de una línea base del software, entonces
una mejor consideración planeada es el tiempo y el esfuerzo necesario para asegurar que el
ambiente de prueba sea el conjunto de su propia configuración.
GENERACIÓN DE CASOS DE PRUEBA
La generación de los casos de prueba está basada en el nivel de prueba a ser ejecutada y las
técnicas de prueba particulares. Los casos de prueba estarán bajo el control de la gestión de
configuración del software e incluye los resultados esperados en cada prueba.
AMBIENTE DE DESARROLLO DE LA PRUEBA
El ambiente usado para las pruebas será compatible con las herramientas de ingeniería de
software. Facilitará el desarrollo y el control de los casos de prueba, así como la recuperación
de los resultados esperados, scripts, y otros materiales de prueba.
EJECUCIÓN
La ejecución de las pruebas deberá consagrar un principio básico de experimentación
científica: todo lo realizado durante las pruebas deberán ser documentadas con suficiente
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 70
claridad de tal modo que otra persona pudiera replicar los resultados. Por tanto, las pruebas
serán ejecutadas de acuerdo a procedimientos documentados usando una versión definida
claramente del software bajo prueba.
EVALUACIÓN DE LOS RESULTADOS DE LA PRUEBA
Pueden ser evaluados los resultados de las pruebas para determinar si o no la prueba ha sido
un éxito. “Exito” significa que el software ejecute lo esperado y no tenga ningún resultado
inesperado. No todos los resultados inesperados son necesariamente fallas, sin embargo,
podría ser juzgado a ser simplemente ruido. Antes de que una falla pueda ser eliminada, es
necesario un análisis y esfuerzo de depuración para aislar, identificar, y describir esta.
REPORTANDO PROBLEMAS / LOG DE PRUEBAS
Las actividades de prueba pueden ser ingresadas en un log de prueba para identificar como
una prueba fue realizada, quienes realizaron la prueba, que configuración fue lo básico para
las pruebas, y otra información de identificación relevantes. Los resultados no esperados o
incorrectos de las pruebas pueden ser registradas en un reporte de problemas, los datos
constituyen la base para su posterior depuración y para la fijación de los problemas que se
observaron durante la prueba. También, las anomalías no clasificadas pueden ser
documentadas. Los reportes de las pruebas también son un insumo para el cambio de gestión
de proceso de solicitud.
SEGUIMIENTO DEL DEFECTO
Las fallas observadas durante la prueba son debido a los defectos en el software. Tales
defectos pueden ser analizados para determinar cuando fueron introducidos en el software,
qué tipos de errores (por ejemplo: requisitos mal definidos, declaración de variables
incorrectas, fugas de memoria, error de sintaxis de programación), y cuando podrían haber
sido observado por primera vez en el software. La información de seguimiento del defecto es
usado para determinar qué aspectos de la ingeniería del software necesitan mejorar y qué
análisis previo han sido probados.
1. DISEÑO DE CASOS DE PRUEBA.
Los casos de prueba son especificaciones de las entradas para la prueba y la salida
esperada del sistema más una afirmación de lo que se está probando. Los datos de prueba a
veces pueden generarse automáticamente. La generación automática de casos de prueba es
imposible.
Las pruebas tienen que basarse en un subconjunto de posibles casos de prueba, las pruebas
exhaustivas son imposibles.
Consideraciones:
1. Deberían probarse todas las funciones del sistema.
2. Deberían probarse todas las funciones con datos correctos e incorrectos.
Para validar que el sistema satisface los requisitos, la mejor aproximación a utilizar es la
prueba basada en escenarios, en la que se idean varios escenarios y se desarrollan casos de
prueba a partir de estos escenarios. Deberían diseñarse un conjunto de pruebas que incluyan
entradas válidas e inválidas y que generen salidas válidas e inválidas.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 71
Si se han utilizado casos de uso para describir los requisitos del sistema, estos casos de uso y
los diagramas de secuencia asociados pueden ser una base para las pruebas del sistema.
DISEÑO DE CASOS DE PRUEBA
El objetivo del proceso de diseño de casos de prueba es crear un conjunto de casos de prueba
que sean efectivos descubriendo defectos en los programas y muestren que el sistema satisface
sus requisitos.
Para diseñar un caso de prueba, se selecciona una característica del sistema o componente que
se está probando. A continuación, se selecciona un conjunto de entradas que ejecutan dicha
característica, documenta las salidas esperadas o rangos de salida y, donde sea posible, se
diseña una prueba automatizada que prueba que las salidas reales y esperadas son las mismas.
Existen varias aproximaciones que pueden seguirse para diseñar casos de prueba:
1. Pruebas basadas en requisitos.
2. Pruebas de particiones. Se identifican particiones de entrada y salida y se diseñan
pruebas para que el sistema ejecute entradas de todas las particiones y genere salidas
en todas las particiones.
Las particiones de equivalencia son una forma de derivar casos de prueba. Dependen
de encontrar particiones en los conjuntos de datos de entrada y salida y ejecutar el
programa con valores de estas particiones. A menudo, el valor que sea más probable
que conduzca a una prueba con éxito es un valor en los límites de una partición.
3. Pruebas estructurales. Se utiliza el conocimiento de la estructura del programa para
diseñar pruebas que ejecuten todas las partes del programa.
Las pruebas estructurales hacen referencia a analizar el programa para determinar
cambios a través de él y usar este análisis como ayuda para la selección de los casos de
prueba.
Cuando se diseñan casos de prueba, se debería comenzar con las pruebas de más alto nivel a
partir de los requisitos y a continuación de forma progresiva, añadir pruebas más detalladas
utilizando pruebas estructurales y de particiones.
2. AUTOMATIZACIÓN DE PRUEBAS.
La automatización de pruebas reduce los costos de las pruebas apoyando al proceso de
pruebas con varias herramientas de software.
Las pruebas son una fase laboriosa y cara del proceso del software. En consecuencia, las
herramientas de pruebas estaban entre las primeras herramientas de software a desarrollar.
Actualmente, estas herramientas ofrecen una serie de facilidades y su uso puede reducir
significativamente los costos de las pruebas.
Una aproximación de las pruebas en las que se utiliza un marco de trabajo de pruebas tal como
JUnit para pruebas de regresión. JUnit es un conjunto de clases Java que el usuario extiende
para crear un entorno de pruebas automatizadas.
Un banco de pruebas del software es un conjunto integrado de herramientas para soportar el
proceso de pruebas. También puede generar datos de prueba para dicho sistema. Se necesita
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 72
una cantidad significativa de esfuerzo y tiempo para crear un banco de trabajo de pruebas
adecuado.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 73
EVOLUCIÓN DEL SOFTWARE
Es más realista considerar a la ingeniería del software como un proceso evolutivo en
el cual el software cambia continuamente durante su período de vida como respuesta a los
requisitos cambiantes y necesidades del usuario. La mayoría de los cambios son una
consecuencia de cambios en el negocio, modificaciones por errores encontrados en su
funcionamiento, o adaptación a una nueva plataforma, o para mejorar el rendimiento, entre
otros. El desarrollo del software no se detiene cuando el sistema ha sido entregado, continúa
durante el tiempo de vida del sistema.
Se puede pensar en la ingeniería de software como un proceso en espiral con requisitos,
diseño, implementación y pruebas que se realizan continuamente durante el tiempo de vida
del sistema.
Un modelo en espiral del desarrollo y evolución
Este es un modelo idealizado de la evolución del software que puede aplicarse en situaciones
en donde una organización es responsable tanto del desarrollo inicial del software como de la
evolución del software. Utilizando esta aproximación se desarrollan la mayoría de los
productos software genéricos.
DINAMICA DE EVOLUCIÓN DE LOS PROGRAMAS
Las leyes de Lehman, como la noción de que el cambio es continuo, describen varias
observaciones a partir de estudios a largo plazo de la evolución de los sistemas:
1. La primera ley establece que el mantenimiento de los sistemas es un proceso
inevitable. Surgen nuevos requisitos a medida que el entorno cambia, de forma que el
proceso de evolución se recicla.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 74
2. La segunda ley establece que a medida que se cambia un sistema, su estructura se
degrada. Se puede evitar esto haciendo mantenimiento preventivo en donde se
consume tiempo mejorando la estructura del software.
3. La tercera ley sugiere que los sistemas grandes tienen su propia dinámica que se
establece en una etapa temprana en el proceso de desarrollo. Determina las tendencias
generales del proceso de mantenimiento del sistema y limita el número de posibles
cambios en el sistema. Las organizaciones tienen que tomar decisiones sobre los
riesgos y el valor de los cambios y costos implicados.
4. La cuarta ley sugiere que la mayoría de los proyectos de programación grandes
trabajan en lo que se denomina un estado saturado. Los grandes grupos de desarrollo
de software son a menudo improductivos debido a que las sobrecargas en las
comunicaciones dominan el trabajo del grupo.
5. La quinta ley se refiere a los incrementos de los cambios en cada entrega del sistema.
Añadir nueva funcionalidad a un sistema inevitablemente introduce nuevos defectos en
el sistema.
El desmantelamiento del sistema significa poner fuera de servicio dicho sistema después de
que termina su período de utilidad operativa. Se pueden identificar y reutilizar los
componentes en buen estado para otros sistemas.
Igualmente puede utilizarse los datos del sistema si poseen valor para su organización.
Analizar el software para descubrir cómo están estructurados los datos y poder reorganizarlos
a una nueva estructura para el nuevo sistema.
1. MANTENIMIENTO DEL SOFTWARE.
El mantenimiento del software es el proceso general de cambiar un sistema después de
que éste ha sido entregado. Los cambios se implementan modificando los componentes del
sistema y añadiendo nuevos componentes cuando sean necesarios.
Existen tres tipos de mantenimiento del software: corrección de errores, modificación del
software para trabajar en un nuevo entorno, e implementación de nuevos requisitos o cambios
en éstos.
Existen tres tipos de mantenimiento de software:
1. Mantenimiento para añadir o modificar las funcionalidades del sistema. Cuando
cambian los requisitos como respuestas a cambios organizaciones o de negocio.
2. Mantenimiento para reparar defectos del software. Cuando surgen los errores en el
código, es menor el costo de corregir los errores, pero los costos serían mayores si se
encontraran errores en el diseño o en los requisitos.
3. Mantenimiento para adaptar el software a diferentes entornos operativos. Esto surge
cuando cambia algún aspecto del entorno del sistema, como por ejemplo el hardware,
la plataforma del sistema operativo u otro software de soporte.
Normalmente se reconocen estos tipos de mantenimiento, pero varias personas le dan distintos
nombres.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 75
Mantenimiento perfectivo. Perfeccionar el software implementando nuevos requisitos
o mejorando la estructura y rendimiento del sistema.
Mantenimiento correctivo. Mantenimiento por reparación de defectos.
Mantenimiento adaptativo. Adaptarse a un nuevo entorno y puede significar adaptar el
software a nuevos requisitos.
Consume la mayor parte del esfuerzo de mantenimiento la evolución del sistema para
adaptarse a nuevos entornos y nuevos requisitos o cambios en los mismos.
Los costos de mantenimiento constituyen una proporción de los costos de desarrollo y varían
de un dominio de aplicación a otro. Para sistemas de tiempo real embebidos, los costos de
mantenimiento pueden ser hasta cuatro veces mayores que los costos de desarrollo.
Normalmente resulta rentable invertir esfuerzo en el diseño e implementación de un sistema
para reducir los costos de mantenimiento.
Distribución del esfuerzo de mantenimiento
Buenas técnicas de ingeniería de software tales como una especificación precisa, el uso de
desarrollo orientado a objetos y la gestión de configuración contribuyen a la reducción de los
costos de mantenimiento.
2. PROCESOS DE EVOLUCIÓN.
Los procesos de evolución del software varían considerablemente dependiendo del tipo
de software a mantener, los procesos de desarrollo utilizados en una organización y el
personal implicado en el proceso.
Los procesos de evolución incluyen las actividades fundamentales de análisis del impacto
de los cambios, planificación de entregas, implementación de los cambios y entrega del
sistema a los usuarios. Se evalúa el impacto y el costo de los cambios. Si los cambios son
aceptados se planifica una nueva entrega, se implementan y validan los cambios y se entrega
una nueva versión del sistema.
El proceso de implementación de los cambios, es esencialmente, una iteración del proceso de
desarrollo en la que se diseñan, implementan y prueban las revisiones del sistema.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 76
Reingeniería del software se refiere a la reestructuración y redocumentación del software para
hacerlo más mantenible y más fácil de cambiar.
Deberían ser evaluados en sistemas heredados el valor de negocio y la calidad del software de
las aplicaciones y su entorno para determinar si el sistema tiene que ser mantenido,
transformado o reemplazado.
Identificación de los cambios y procesos de evolución
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 77
GESTIÓN DE CONFIGURACIÓN
El objetivo de la gestión de configuración es introducir un proceso de gestión del
código y la documentación de un sistema de software. La gestión de configuración es el
desarrollo y aplicación de estándares y procedimientos para gestionar un sistema software
evolutivo. Las actividades involucradas en esta gestión son: la planificación de la gestión de
configuración, la gestión de cambios, la gestión de versiones y entregas y la construcción de
sistemas.
Los procedimientos de gestión de configuración definen cómo registrar y procesar los
cambios propuestos al sistema, cómo relacionarlos éstos con los componentes del sistema y
los métodos utilizados para identificar las diversas versiones del sistema.
Comienza a ser un sistema controlado, lo que significa que los cambios en el sistema tienen
que ser acordados y registrados antes de ser implementados.
Se denomina línea base al punto de inicio para la evolución controlada.
En un proceso tradicional de desarrollo de software basado en el modelo en cascada, el
software se entrega al equipo de gestión de configuración después de que el desarrollo haya
sido completado y se hayan probado los componentes de software. Si la calidad es aceptable,
éste pasa a ser la nueva línea base para el desarrollo del sistema.
Administración de la Gestión de Configuración
La gestión de configuración en el desarrollo ágil y desarrollo rápido no pueden basarse en
rígidos procedimientos y papeleo burocrático. Los procesos ágiles utilizan herramientas de
gestión de configuraciones, como un gestor de versiones y herramientas para la construcción
del sistema, que incorporarán algo de control.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 78
Se pueden utilizar herramientas CASE como soporte a los procesos de la gestión de
configuración, almacenar las versiones de los componentes del sistema, construir sistemas a
partir de estos componentes y llevar el registro de entregas de las versiones del sistema a los
clientes.
La definición y uso de gestión de configuración es esencial para la certificación de calidad
ISO9000 y para los estándares CMMI.
1. PLANIFICACIÓN DE LA GESTIÓN DE CONFIGURACIÓN.
Un plan de gestión de gestión de configuración describe un conjunto de estándares
generales adaptables a cada proyecto específico y los procedimientos utilizados para la gestión
de la configuración. El plan incluye:
1. Identificación de los elementos de configuración y el esquema formal que identifican
estas entidades.
2. La persona que toma la responsabilidad de los procedimientos y la persona que envía
las entidades controladas al equipo de gestión de configuración.
3. Las políticas para gestionar el control de cambios y versiones.
4. Las herramientas a utilizar y el proceso a aplicar cuando se utilizan estas herramientas.
5. La definición de la base de datos para registrar la información de la configuración.
En el plan se incluye información adicional de la gestión del software por parte de los
proveedores externos y los procesos de auditoria.
Durante el proceso de planificación de la gestión de configuración se decide que clases de
elementos se van a controlar. Normalmente son elementos de la configuración, los planes del
proyecto, las especificaciones, los diseños, los programas y los conjuntos de datos de prueba.
Deben ser controlados por el sistema de control de configuración todos los documentos
necesarios para el mantenimiento futuro del sistema. Hay documentos que no son relevantes
como el bosquejo del plan y propuesta, minutas de las reuniones, etc.
El esquema debe asignar un nombre único a todos los documentos de control de la
configuración. Este nombre debe reflejar el tipo de elemento, la parte del sistema en la que se
utiliza y el creador del elemento, entre otros. Debe reflejarse las relaciones entre elementos
para asegurar que los documentos relacionados tengan una raíz común del nombre. Esto
corresponde a un esquema de asignación de nombres jerárquicos.
La asignación de nombres jerárquica es simple y fácil de entender, y a veces copia la
estructura de directorios utilizada para almacenar los archivos del proyecto.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 79
Jerarquía de la configuración usada para
la asignación de identificadores
La base de datos de configuraciones se utiliza para registrar toda la información relacionada
con las configuraciones y sus elementos. El esquema de la base de datos define los
formularios y los procedimientos para registrar y recuperar la información del proyecto. La
base de datos registra información acerca de los usuarios, componentes, clientes del sistema,
plataformas de ejecución, cambios propuestos, etc.
De forma ideal, la base de datos se integra en el sistema de gestión de versiones para
almacenar y gestionar los documentos formales del proyecto. Este enfoque hace posible
vincular los cambios de forma directa con los documentos y componentes afectados por el
cambio. Esta base de datos de configuraciones almacena información de los elementos de la
configuración y hace referencia a sus nombres de archivos en el sistema de gestión de
versiones.
2. GESTIÓN DE CAMBIOS.
Las necesidades organizacionales y los requisitos cambian durante el tiempo de vida de
un sistema y para esto, se necesitará un conjunto de herramientas de soporte para los
procedimientos de gestión de cambios.
Los procedimientos se ocupan del análisis de costos y beneficios aprobando aquellos cambios
que merecen la pena y registrando los componentes del sistema que se tienen que cambiar. El
proceso de gestión de cambios se lleva a cabo cuando el software o la documentación asociada
se ponen bajo el control del equipo de gestión de configuración.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 80
La primera etapa del proceso de gestión de cambio es completar un formulado de solicitud de
cambio, registrar las recomendaciones pertinentes, los costos estimados y las fechas en las que
se solicita, prueba, implementa y valida el cambio. También cómo implementar el cambio.
Una vez emitido el formulario se registra en la base de datos de configuraciones. Si el análisis
descubre que el cambio solicitado es inválido, está duplicado o ya ha sido considerado, el
cambio se rechaza.
Para cambios válidos se comprueba el impacto del cambio en el resto del sistema. Se lleva un
análisis técnico que implica identificar los componentes afectados.
El consejo de control de cambios revisa y aprueba todas las peticiones de cambios, considera
el impacto del cambio desde un punto de vista estratégico y organizacional más que desde el
punto de vista técnico. En pequeños proyectos, existe sólo un revisor del cambio que aconseja
si los cambios son justificables.
3. GESTIÓN DE VERSIONES Y ENTREGAS.
La gestión de versiones y entregas es el proceso de identificar y mantener los registros
de las diversas versiones y entregas de un sistema. Una versión de un sistema es una instancia
de un sistema que difiere, de alguna manera, de otras instancias. Las nuevas versiones tienen
diferente funcionalidad, mejor rendimiento o incorporan reparaciones de fallos. Algunas
versiones son funcionalmente equivalentes pero diseñadas para diferentes configuraciones de
hardware y software.
Para crear una versión se tienen que especificar las versiones de cada uno de los componentes
que deben incluirse en él. Existen tres técnicas básicas para la identificación de componentes:
1. Numeración de las versiones. Se asigna un número de versión único y explícito a cada
componente.
2. Identificación basada en atributos. Cada componente tiene un nombre y un conjunto
asociado de atributos para cada versión. Por lo tanto, los componentes se identifican
por su nombre y por los valores de los atributos.
3. Identificación orientada al cambio. Cada sistema se nombra a partir de los atributos,
pero también se asocia con una o más solicitudes de cambios.
Una entrega del sistema es una versión del sistema que se distribuye a los clientes. El gestor
de entregas decide cuándo se entrega el sistema, gestionar el proceso de creación de las
entregas y de los medios de distribución y documentación para asegurar de recuperar la misma
forma como se distribuyó.
La creación de las entregas es el proceso de crear una colección de archivos y documentación
que incluyen todos los componentes de la entrega del sistema. Esto incluye:
1. Archivos de configuración, que define como configura el sistema para instalaciones
específicas.
2. Archivos de datos necesarios para el funcionamiento del sistema.
3. El programa de instalación utilizado para ayudara a instalar el sistema.
4. La documentación que describe al sistema.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 81
5. El embalaje y la publicidad asociados diseñados para esta entrega.
Las decisiones sobre cuándo entregar una nueva versión del sistema están dirigidas por varios
factores técnicos y organizacionales.
4. HERRAMIENTAS CASE PARA GESTION DE CONFIGURACIÓN.
Los procesos de gestión de configuración por lo general están estandarizados e
involucran la aplicación de procedimientos predefinidos. Desde los 70’s se han producido un
gran número de diferentes herramientas que abordan diferentes áreas de la gestión de
configuración. Hay dos tipos de entornos de trabajo:
1. Entornos de trabajo abiertos. Las herramientas para cada etapa del proceso son
integradas de acuerdo con procedimientos organizacionales estándar. Existen muchas
herramientas comerciales y libres disponibles.
2. Entornos integrados. Estos ofrecen facilidades integradas para gestión de versiones,
construcción del sistema o seguimiento de los cambios. Ejemplo Gestión de Cambios
Unificado de Racional que incorpora ClearCase para la construcción y gestión de
versiones y ClearQuest para el seguimiento de los cambios, incluye una base de datos
integrada y el intercambio de datos es sencillo. Sin embargo, los entornos integrados
son complejos y costosos.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 82
GESTIÓN DE PROYECTOS DE SOFTWARE
La gestión de proyectos software es necesaria debido a que la ingeniería de software
profesional, siempre está sujeta a restricciones organizacionales de tiempo y presupuesto. Los
gestores de software son responsables de la planificación y el desarrollo de los proyectos.
Existen diferencias entre la gestión de un proyecto cualquiera y la gestión de un proyecto
software:
1. El producto es intangible. El software es intangible y no se puede ver ni tocar. Los
gestores de proyectos de software no pueden ver el progreso.
2. No existen procesos del software estándar. Los procesos de software varían
notablemente de una organización a otra. No se puede predecir con certeza cuándo un
proceso particular, tiende a desarrollar problemas.
3. A menudo los proyectos grandes son únicos. Por lo general, los proyectos grandes de
software son diferentes de los proyectos previos. Las lecciones aprendidas de esas
experiencias pueden no ser transferibles a los nuevos proyectos.
Interrelación entre los elementos de un proyecto
1. ACTIVIDADES DE LA GESTIÓN DE PROYECTOS.
Las actividades de la gestión de proyectos difieren enormemente de organización en
organización y del producto de software a desarrollar. Sin embargo, citaremos algunas
actividades involucradas en la gestión de proyectos de software:
1. En un proyecto de software implica redactar una propuesta que describa los
objetivos del proyecto y cómo llevarlo a cabo. La redacción de la propuesta es una
tarea crítica, no existe una guía para esta actividad, es una habilidad que se adquiere
con la experiencia.
2. La planificación del proyecto implica identificar las actividades, los hitos y los
entregables. Realizar un plan para guiar el desarrollo hacia las metas del proyecto.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 83
3. Estimación de tiempos.
4. La estimación de costos es una actividad relacionada con la estimación de los recursos
requeridos para llevar a cabo el plan del proyecto.
5. La supervisión del proyecto es una actividad continua. El gestor debe tener
conocimiento del progreso del proyecto y comparar el progreso con los costos actuales
y los planificados.
6. Durante un proyecto, es normal tener varias revisiones formales de su gestión. Se
hace una revisión completa del progreso y del desarrollo técnico del proyecto, y se
tiene en cuenta el estado del proyecto junto con los propósitos de la organización que
ha encargado el software.
7. Los gestores de proyectos seleccionan al personal con ciertas habilidades y
experiencia apropiadas para trabajar en el proyecto. Establecen un equipo ideal de
desarrolladores para el proyecto.
Gerencia de proyectos de software
La planificación y la estimación son procesos iterativos y tienen continuidad a lo largo del
proyecto.
Los gestores del proyecto son responsables de informar a los clientes y contratistas sobre el
proyecto. Redactan documentos concisos y coherentes que resuman la información crítica del
proyecto. Ellos deberán tener la habilidad esencial de comunicarse efectivamente de forma
oral y escrita.
2. PLANIFICACIÓN DEL PROYECTO DE SOFTWARE.
De la completa planificación del proyecto software dependerá su efectiva gestión. El
plan inicial debe ser el mejor posible de acuerdo con la información disponible, evolucionará
de acuerdo a cómo progrese el proyecto y sea mejor la información.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 84
El proceso de planificación se inicia con una valoración de las restricciones que afectan al
proyecto (fecha de entrega requerida, personal disponible, presupuesto global, etc.) se lleva a
cabo en conjunto con una estimación de los parámetros del proyecto, como su estructura,
tamaño y distribución de funciones. Entonces se definen los hitos del progreso y productos a
entregar. Se prepara un calendario para el proyecto y las actividades definidas.
El Plan del proyecto es un documento en donde se fijan los recursos disponibles, se divide el
trabajo y se crea un calendario de trabajo. Los detalles de este plan varían dependiendo del
tipo de proyecto y de la organización.
Muchos planes incluyen las siguientes secciones:
1. Introducción. Describe los objetivos del proyecto y sus restricciones (presupuesto,
tiempo, etc.) que afectan a la gestión del proyecto.
2. Organización del proyecto. Como está organizado el equipo de desarrollo y sus roles.
3. Análisis de riesgos. La posibilidad de que surjan riesgos y las estrategias para reducir
los riesgos.
4. Requisitos de hardware y software. Describe el hardware y el software de ayuda
requeridos para llevar a cabo el desarrollo.
5. División del trabajo. División del proyecto en actividades e identificación de hitos y
productos de entrega asociados a cada actividad.
6. Calendarización del proyecto. Implica separar todo el trabajo de un proyecto en
actividades que se complementan, estimar el tiempo de cada actividad para alcanzar
cada hito, y la asignación del personal.
El calendario del proyecto se representa como un conjunto de gráficos que muestran la
división del trabajo, las dependencias de las actividades y la asignación del personal.
La calendarización del tiempo para la creación del software no es diferente a la de
cualquier otro tipo de proyecto. Los calendarios se deben actualizar continuamente en
la medida que se disponga de mejor información acerca del progreso.
Una serie de hitos (puntos finales de cada actividad básica del proceso de desarrollo
del software con salidas asociadas) representan el fin de una etapa lógica en el
proyecto.
Las salidas asociadas a cada hito es denominado un entregable. Se entrega al cliente y
se informa del progreso del proyecto a la gestión.
7. Mecanismos de supervisión e informe. Supervisión del proyecto y gestión de
informes.
Microsoft Project es una herramienta de gestión de proyectos de software muy utilizada para
automatizar las actividades.
3. ORGANIZACIÓN DEL PROYECTO.
El personal es el activo principal en una organización software y representa el capital
intelectual. Una de las tareas más importantes de los gestores de proyectos es la selección del
personal de un proyecto, algunos de los factores que pueden usarse son la experiencia en el
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 85
dominio de la aplicación, la adaptabilidad y la personalidad. Es importante que el equipo
tenga el equilibrio correcto de habilidades y experiencia técnica.
Muchas veces los proyectos de software se retrasan debido a la falta de personal calificado.
Un papel importante es el del líder del equipo, responsable de proveer la dirección técnica y
gestión del proyecto. Los líderes son normalmente designados por el gestor general del
proyecto.
Las ventajas de un equipo cohesivo son las siguientes:
1. Puede crearse un equipo que utilice estándar de calidad.
2. Los miembros de un equipo trabajan juntos.
La cohesión del equipo depende de muchos factores, entre los que se encuentran la cultura
organizacional. Los miembros más experimentados del equipo realizan el diseño de sistemas
de alto nivel, pero el diseño de bajo nivel es responsabilidad de los miembros a quienes se les
asigna una tarea particular.
El entorno de trabajo debe incluir espacios donde el equipo pueda interactuar y otros donde
los miembros puedan trabajar individualmente de forma tranquila y concentrándose en su
trabajo.
4. ANALISIS DE RIESGOS.
Una tarea importante para el gestor de proyectos es anticipar los riesgos que podrían
afectar a la programación del proyecto o a la calidad del software a desarrollar y emprender
acciones para evitar estos riesgos. Los riesgos son una amenaza para el proyecto, para el
software que se está desarrollando y para la organización.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 86
Riesgo Descripción
Rotación del personal Personal con experiencia abandona el proyecto antes de
que finalice.
Cambio de gestión Habrá un cambio de gestión organizacional con diferentes
prioridades.
Falta de disponibilidad del
hardware
El hardware esencial para el proyecto no será entregado a
tiempo.
Cambios de requisitos Habrá más cambios en los requisitos de lo esperado.
Retrasos en la especificación Las especificaciones de las interfaces esenciales no
estarán a tiempo.
Subestimación del tamaño El tamaño del sistema se ha subestimado.
Bajo rendimiento de la
herramienta CASE
Las herramientas CASE que ayudan al proyecto no tienen
el rendimiento esperado
Competencia del producto Un producto competitivo se pone en venta antes de que el
sistema se complete.
Cambio de tecnología La tecnología fundamental sobre la que se construirá el
sistema se sustituye por nueva tecnología.
Se deben identificar y valorar los riesgos mayores del proyecto para establecer su probabilidad
y consecuencias. Estos riesgos se deben analizar de manera explícita en cada reunión. Los
resultados de la gestión de riesgos se deben documentar en un plan de gestión de riesgos.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 87
CALIDAD DEL SOFTWARE
Lord Kelvin, in the 1890s:
“When you can measure what you are speaking about, and express it in numbers, you know
something about it; but when you cannot measure it, when you cannot express it in numbers,
your knowledge is of a meager and unsatisfactory kind: it may be the beginning of knowledge,
but you have scarcely, in your thoughts, advanced to the stage of science.”
La calidad del software es un concepto complejo, la noción de calidad viene dada por
la similitud entre el producto desarrollado y su especificación (Crosby, 1979).
Algunas personas piensan que la calidad puede lograrse definiendo estándares y
procedimientos organizacionales de calidad, encapsulando buenas prácticas que conlleven a
productos de alta calidad. En la práctica, más importante es la gestión de la calidad que los
estándares.
Los buenos gestores aspiran desarrollar una cultura de la calidad donde todos seamos
responsables de que el desarrollo del producto sea llevado a cabo obteniendo un alto nivel de
calidad.
La gestión de la calidad del software se estructura en tres actividades principales:
1. Garantía de la calidad. Establecimiento de un marco de trabajo de procedimientos y
estándares organizacionales que conduce a software de alta calidad.
2. Planificación de la calidad. La adaptación de los procedimientos y estándares a un
proyecto software específico.
3. Control de la calidad. Seguimiento de los procesos para la calidad del proyecto.
El equipo de garantía de calidad debe ser independiente del equipo de desarrollo para que
puedan tener una visión objetiva del software. Un equipo independiente de calidad garantiza
que los objetivos organizacionales y la calidad no sean comprometidos por consideraciones de
presupuesto o agenda.
1. CALIDAD DEL PRODUCTO.
El objetivo no es necesariamente alcanzar una calidad perfecta, sino la necesaria y
suficiente para cada contexto de uso a la hora de la entrega y del uso por parte de los usuarios.
Es necesario comprender las necesidades reales de los usuarios con tanto detalle como sea
posible (requisitos).
Calidad del producto
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 88
ISO/IEC 9126
Tecnologías de la Información. Calidad de los productos software.
Ejemplo de uso:
Validar la completitud de una definición de requisitos;
Identificar requisitos de software;
Identificar objetivos para el diseño software;
Identificar requisitos para las pruebas del software;
Identificar requisitos para el aseguramiento de la calidad;
Identificar criterios de aceptación para un producto software completado.
Diferentes aspectos de la calidad
INTERNA: medible a partir de las características intrínsecas, como el código fuente.
EXTERNA: medible en el comportamiento del producto, como en una prueba.
EN USO: durante la utilización efectiva por parte del usuario.
Modelo de calidad para calidad interna y externa
FUNCIONALIDAD
Adecuación
Capacidad del producto software para proporcionar un conjunto apropiado de funciones para
tareas y objetivos de usuario especificados.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 89
Exactitud
Capacidad del producto software para proporcionar los resultados o efectos correctos o
acordados, con el grado necesario de precisión.
Interoperatividad
Capacidad del producto software para interactuar con uno o más sistemas especificados.
Seguridad de acceso
Capacidad del producto software para proteger información y datos de manera que las
personas o sistemas no autorizados no pueden leerlos o modificarlos, al tiempo que no se
niega el acceso a las personas o sistemas autorizados.
Cumplimiento funcional
Capacidad del producto software para adherirse a normas, convenciones o regulaciones en
leyes y prescripciones similares relacionadas con funcionalidad.
FIABILIDAD
Madurez
Capacidad del producto software para evitar fallar como resultado de fallos en el software.
Tolerancia a fallos
Capacidad del software para mantener un nivel especificado de prestaciones en caso de fallos
software o de infringir sus interfaces especificados.
Capacidad de recuperación
Capacidad del producto software para restablecer un nivel de prestaciones especificado y de
recuperar los datos directamente afectados en caso de fallo.
Cumplimiento de la fiabilidad
Capacidad del producto software para adherirse a normas, convenciones o regulaciones
relacionadas con la fiabilidad.
USABILIDAD
Capacidad para ser entendido
Capacidad del producto software que permite al usuario entender si el software es adecuado y
cómo puede ser usado para unas tareas o condiciones de uso particulares.
Capacidad para ser aprendido
Capacidad del producto software que permite al usuario aprender sobre su aplicación.
Capacidad para ser operado
Capacidad del producto software que permite al usuario operarlo y controlarlo.
Capacidad de atracción
Capacidad del producto software para ser atractivo al usuario.
Cumplimiento de la usabilidad
Capacidad del producto software para adherirse a normas, convenciones, guías de estilo o
regulaciones relacionadas con la usabilidad.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 90
MANTENIBILIDAD
Capacidad para ser analizado
Es la capacidad del producto software para serle diagnosticadas deficiencias o causas de los
fallos en el software, o para identificar las partes que han de ser modificadas.
Capacidad para ser cambiado
Capacidad del producto software que permite que una determinada modificación sea
implementada.
Estabilidad
Capacidad del producto software para evitar efectos inesperados debido a modificaciones del
software.
Capacidad para ser probado
Capacidad del producto software que permite que el software modificado sea validado.
Cumplimiento de la mantenibilidad
Capacidad del producto software para adherirse a normas o convenciones relacionadas con la
mantenibilidad.
PORTABILIDAD
Adaptabilidad
Capacidad del producto software para ser adaptado a diferentes entornos especificados, sin
aplicar acciones o mecanismos distintos de aquellos proporcionados para este propósito por el
propio software considerado.
Instalabilidad
Capacidad del producto software para ser instalado en un entorno especificado.
Coexistencia
Capacidad del producto software para coexistir con otro software independiente, en un
entorno común, compartiendo recursos comunes.
Capacidad para reemplazar
Capacidad del producto software para ser usado en lugar de otro producto software, para el
mismo propósito, en el mismo entorno.
Cumplimiento de la portabilidad
Capacidad del producto software para adherirse a normas o convenciones relacionadas con la
portabilidad.
Modelo de calidad para calidad en uso
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 91
EFECTIVIDAD
Capacidad del producto software para permitir a los usuarios alcanzar objetivos especificados
con exactitud y completitud, en un contexto de uso especificado.
PRODUCTIVIDAD
Capacidad del producto software para permitir a los usuarios gastar una cantidad adecuada de
recursos con relación a la efectividad alcanzada, en un contexto de uso especificado.
SEGURIDAD FISICA
Capacidad del producto software para alcanzar niveles aceptables del riesgo de hacer daño a
personas, al negocio, al software, a las propiedades o al medio ambiente en un contexto de uso
especificado.
SATISFACCIÓN
Capacidad del producto software para satisfacer a los usuarios en un contexto de uso
especificado.
2. CALIDAD DEL PROCESO.
Una suposición de la gestión de calidad es que la calidad del proceso de desarrollo
afecta directamente a la calidad de los productos derivados.
El desarrollo de software es un proceso más creativo que mecánico, donde la experiencia y
habilidades individuales son importantes. La calidad del producto, también se ve afectada por
factores externos, como la presión comercial de sacar un producto rápidamente.
En el desarrollo software la relación entre la calidad del proceso y la calidad del producto es
muy compleja, es difícil medir los atributos de calidad del software, en consecuencia, es difícil
explicar cómo influyen las características del proceso en estos atributos.
La gestión y mejora de la calidad del proceso debe minimizar los defectos en el software. La
gestión de la calidad del proceso implica:
1. Definir estándares de proceso.
2. Supervisar el proceso de desarrollo para asegurar se sigan los estándares.
3. Documentar el proceso para el gestor del proyecto.
Calidad basada en procesos
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 92
La garantía de la calidad es el proceso que define cómo lograr la calidad del software y cómo
la organización de desarrollo conoce el nivel de calidad requerido en el software. El proceso
de Aseguramiento de la Calidad (QA) se ocupa de definir o seleccionar los estándares que
deben ser aplicados al proceso de desarrollo de software o al producto software.
Organizaciones como el Departamento de Defensa de los Estados Unidos, ANSI, OTAN e
IEEE han desarrollado estándares internacionales para cubrir la terminología, los lenguajes de
programación, las notaciones como símbolos en los diagramas, los procedimientos para
derivar y redactar los requisitos de software, los procedimientos de garantía de calidad y los
procesos de verificación y validación del software, estos estándares se aplican a una variedad
de proyectos.
Aunque por los general los ingenieros están de acuerdo con los estándares, a menudo tienen
buenas razones que dichos estándares no sean necesarios para algún proyecto en particular.
Cada gestor de proyecto tiene la facultad de modificar los estándares de proceso de acuerdo a
circunstancias particulares.
ISO 9000-3
ISO 9001 es un estándar que se aplica en organizaciones interesadas en el proceso de calidad
de diseño, desarrollo y mantenimiento de productos. Un documento de ayuda (ISO 9000-3)
interpreta ISO 9001 para el desarrollo de software.
ISO 9001 no es un estándar específico para desarrollo de software, pero define principios
generales que pueden aplicarse al software. El estándar ISO 9001 describe varios aspectos del
proceso de calidad y define qué estándares y procedimientos deben existir en una
organización. Estos deben documentarse en un manual de calidad organizacional. La
definición del proceso debe incluir una descripción de la documentación requerida, donde se
demuestre que los procesos definidos han sido seguidos durante el desarrollo del producto.
3. PLANIFICACIÓN DE LA CALIDAD.
La planificación de la calidad es el proceso en el cual se desarrolla un plan de calidad
para un proyecto, en esta se define la calidad del software deseado y cómo valorarlo. El plan
selecciona los estándares organizacionales para el producto y el proceso de desarrollo en
particular. Humphrey sugiere una estructura para un plan de calidad:
1. Introducción del producto. Descripción del producto, el mercado al que se dirige y las
expectativas de calidad.
2. Planes del producto. Fechas de terminación del producto, responsabilidades, planes de
distribución y el servicio.
3. Descripción del producto. Procesos de desarrollo y administración del producto.
4. Metas de calidad. Metas y planes de calidad del producto identificando y justificando
los atributos de calidad del producto.
5. Riesgos y gestión de riesgos. Riesgos que podrían afectar a la calidad del producto y
las acciones para abordar estos riesgos.
Los planes de calidad difieren de acuerdo al producto software.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 93
Atributos de calidad del software
Seguridad Comprensión Portabilidad
Protección Experimentación Usabilidad
Fiabilidad Adaptabilidad Reutilización
Flexibilidad Modularidad Eficacia
Robustez Complejidad Aprendizaje
Existe una amplia variedad de atributos de calidad del software a considerar en la
planificación, se considerarán los más importantes.
4. CONTROL DE LA CALIDAD.
El control de la calidad implica vigilar el proceso de desarrollo de software para
asegurar que se siguen los procedimientos y los estándares de garantía de calidad en las
entregas. Existen dos enfoques:
1. Revisión de la calidad del software, de la documentación y los procesos utilizados
en su desarrollo. Comprobación de los estándares del proyecto y el software.
2. Valoración automática del software, se procesan por algún programa que comparan
los estándares, comprende una medida cuantitativa de algunos atributos del
software.
Las revisiones son el método más utilizado para validar la calidad de un proceso o de un
producto. Involucra a un grupo de personas que examinan todo o parte del proceso software, y
su documentación, se registra los problemas encontrados.
Las revisiones de la calidad consumen tiempo y por tanto retrasan la entrega del software, se
pueden utilizar herramientas para hacer valoraciones automáticas de la calidad del software
que puedan comprobar que el software tiene la calidad requerida.
Las mediciones del software se utilizan para recoger datos cuantitativos acerca del software y
sus procesos. Los valores de las métricas de software recogidas se utilizan para hacer
inferencias de la calidad del producto y del proceso.
Las mediciones del software pueden utilizarse para:
1. Hacer predicciones generales acerca del sistema. Haciendo mediciones a las
características de los componentes del sistema y reuniendo estas, podremos derivar
una estimación general de algunos atributos del software y de los fallos.
2. Identificar componentes anómalos. Identificación de los componentes fallos. Podemos
medir los componentes más complejos.
Una métrica de software es cualquier tipo de medida relacionada con un sistema, proceso o
documentación de software. Una medida es calcular el tamaño del producto software en líneas
de código, otro sería el número de fallos encontrados en el producto, el número de personas
requeridas para el desarrollo, etc.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 94
Las métricas son de control o de predicción. Las métricas de control suelen estar asociadas
con los procesos, mientras que las métricas de predicción asociadas con el producto. Ejemplo
las métricas de control o de proceso son el esfuerzo y el tiempo promedio requerido para
reparar los defectos encontrados. Ejemplo de métricas de predicción es el número de atributos
y operaciones asociadas con los objetos de un diseño.
Las métricas de calidad del producto son de gran valor para resaltar los componentes
anómalos que tienen problemas de calidad. Estos componentes se deberán analizar con más
detalle.
Los atributos de calidad como la mantenibilidad, la comprensión y la usabilidad son
atributos externos que nos dicen cómo ven el software los desarrolladores y los usuarios. Es
necesario medir atributos internos del software (tamaño) y suponer que existe una relación
entre los atributos externos y los internos.
1. Un atributo interno debe medirse de forma precisa.
2. Debe existir una relación entre lo que se puede medir y el atributo de comportamiento
externo.
3. Esta relación se comprende, ha sido validad y se puede expresar en términos de una
fórmula o modelo.
Relación entre los atributos internos y externos
Las métricas del producto se refieren a las características del mismo software. Las métricas
dinámicas ayudan a valorar la eficiencia y la fiabilidad de un programa. Las métricas estáticas
ayudan a valorar la complejidad, la comprensión y la mantenibilidad de un sistema de
software.
No existen métricas de software estandarizadas y aplicables universalmente. Las
organizaciones deben seleccionar métricas y analizar mediciones basadas en el conocimiento
y circunstancias locales.
Fiabilidad
Número de parámetros del procedimiento
Complejidad ciclomática
Tamaño del programa en líneas de código
Número de mensajes de error
Extensión del manual de usuario
Mantenibilidad
Usabilidad
Portabilidad
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 95
5. MEJORA DE PROCESOS.
Muchas compañías de ingeniería de software han tomado el camino de la mejora de los
procesos del software para mejorar su software. La mejora de los procesos significa entender
los procesos existentes y cambiarlos para mejorar la calidad del producto y reducir el costo y
el tiempo de desarrollo.
Los procesos del software son intrínsecamente complejos y comprenden un gran número de
actividades. Como los productos, los procesos también tienen atributos o características.
Característica
del Proceso Descripción
Comprensión ¿Hasta qué punto se define completamente el proceso y cómo de
fácil es comprender su definición?
Visibilidad ¿Las actividades del proceso culminan en resultados claros de
forma que el progreso del proceso es visible externamente?
Apoyo ¿Hasta qué punto las actividades del proceso pueden apoyarse en
herramientas CASE?
Aceptación ¿El proceso definido es aceptable y utilizable por los ingenieros
responsables de producir el software?
Fiabilidad
¿El proceso diseñado es de tal forma que los errores del proceso se
evitan o identifican antes de que se conviertan en errores de
producto?
Robustez ¿Puede continuar el proceso a pesar de los problemas inesperados?
Mantenibilidad
¿Puede evolucionar el proceso para reflejar los requisitos
organizacionales cambiantes o las mejoras identificadas del
proceso?
Rapidez ¿Cómo de rápido se puede completar el proceso de construcción
de un sistema a partir de una especificación dada?
Características de los procesos
No es posible hacer mejoras de procesos que optimicen todos los atributos del proceso de
forma simultánea. La mejora de proceso no significa simplemente adoptar métodos o
herramientas particulares o utilizar algún modelo de un proceso utilizado en lugar de otro.
Aunque las organizaciones que desarrollan el mismo tipo de software claramente tienen
mucho en común, siempre existen factores organizacionales particulares, procedimientos y
estándares que influyen en el proceso. Debe verse la mejora de procesos como una actividad
específica de una organización. La mejora de procesos es una actividad cíclica y tiene tres
estados principales:
1. Proceso de medición de los atributos del proyecto actual o del producto. El objetivo es
mejorar las mediciones de acuerdo con las metas de la organización involucrada en el
proceso de mejora.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 96
2. Proceso de análisis. El proceso actual es valorado, y se identifican puntos flacos y
cuellos de botella. En esta etapa se suelen desarrollar los procesos que describen los
modelos de proceso.
3. Introducir los cambios del proceso identificados en el análisis.
Cada etapa del proceso puede durar varios meses. La mejora de procesos es una actividad a
largo plazo. Es una actividad continua, en la que se introducen nuevos procesos, el entorno de
negocio cambia y los procesos por sí mismos evolucionan para tener en cuenta estos cambios.
La mejora de procesos está basada en la suposición de que la calidad del proceso de desarrollo
es crítica para la calidad del producto. Estas nociones de mejora de proceso provienen de
W.E.Deming, quien trabajó en la industria japonesa para mejorar la calidad.
Existen procesos de software en todas las organizaciones, estos procesos son de diferentes
tipos dependiendo del grado de formalización del proceso, igualmente de los tipos de
productos desarrollados y el tamaño de la organización, entre otros. Hay cuatro clases de
procesos de software:
1. Procesos informales. No existe un modelo de proceso definido. El proceso utilizado es
elegido por el equipo de desarrollo.
2. Procesos gestionados. Se utiliza un modelo de proceso para dirigir el proceso de
desarrollo. El modelo de proceso define los procedimientos, la agenda y las relaciones
entre los procedimientos.
3. Procesos metodológicos. Se utiliza algún método de desarrollo definido. Estos
procesos se benefician de la existencia de herramientas CASE para el diseño y el
análisis.
4. Procesos de mejora. Son procesos que tienen objetivos de mejora. Existe un
presupuesto para estos procesos de mejora, y de procedimientos para introducir tales
mejoras. Como parte de estas mejoras, se introducen mediciones cuantitativas del
proceso.
Las mediciones del proceso son datos cuantitativos de los procesos del software. La medición
de los atributos de proceso y de producto es esencial para la mejora de procesos. Las
mediciones desempeñan un papel importante en la mejora de procesos de personal a pequeña
escala. Las métricas de proceso se utilizan para evaluar si la eficiencia de un proceso ha
mejorado. Por ejemplo, se puede medir el esfuerzo y tiempo dedicados a las pruebas. Las
mejoras efectivas para los procesos de prueba reducen el esfuerzo, el tiempo de prueba o
ambos. Sin embargo, las mediciones de procesos, por sí mismas, no se pueden utilizar para
determinar si la calidad del producto ha mejorado.
6. PROCESOS CMMI.
El Software Engineering Institute (SEI) se estableció para mejorar las capacidades de
la industria de software de los Estados Unidos de América. A mediados de los 80, el SEI
inició un estudio de las formas de evaluar las capacidades de los proveedores de software. El
resultado de estos estudios fue el Modelo de Madurez de la Capacidad de Software de SEI
(CMMI).
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 97
El modelo de madurez de proceso CMMI es un modelo de mejora de procesos integrado que
soporta la mejora de procesos en dos versiones: etapas y continua. El modelo CMMI intenta
ser un marco de trabajo para la mejora del proceso que sea aplicable en un amplio abanico de
compañías.
En el modelo CMMI, la mejora de procesos está basada en alcanzar un conjunto de metas
relacionadas con las buenas prácticas de la ingeniería de software y describir, analizar y
controlar las prácticas utilizadas para alcanzar estas metas. El modelo CMMI incluye prácticas
recomendadas que pueden utilizarse, pero no obliga a utilizarlas.
Un resumen del modelo:
1. Áreas de proceso. CMMI identifica 24 áreas de procesos relevantes para la capacidad
y la mejora del proceso de software.
2. Metas. Son descripciones abstractas de un estado deseable alcanzado por la
organización. CMMI tiene metas específicas asociadas a cada área de procesos.
También tiene metas genéricas asociadas con la institucionalización de buenas
prácticas.
3. Prácticas. Son descripciones de vías para conseguir una meta. Se pueden asociar hasta
siete prácticas específicas o genéricas con cada meta dentro de cada área de procesos.
Modelo CMMI Por etapas
Áreas de Proceso por Niveles y Categorías
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 98
Las metas y prácticas genéricas no son técnicas, pero están asociadas con la
institucionalización de las buenas prácticas, lo que significa que dependen de la madurez de la
organización. Por lo tanto, en una organización nueva que se halla en una etapa temprana del
desarrollo de la madurez; la institucionalización puede significar el segmento de los planes y
los procesos establecidos. Sin embargo, en una organización con más madurez, procesos
avanzados, la institucionalización puede significar controlar los procesos utilizando técnicas
estadísticas u otras técnicas cuantitativas.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 99
Controles de Lectura
LECTURA # 01
REQUISITOS: UNA INTRODUCCIÓN Traducción del artículo original
Requirements: An introduction Level: Introductory
Scott McEwenMetasys Technologies, Inc.
16 Apr 2004
Los requisitos son parte esencial del éxito de un
proyecto software. Este artículo explica porqué, y
describe un acercamiento a la documentación eficaz de
los requisitos.
La compañía Fortuna 100 emprendió un proyecto
para diseñar y construir un paquete de software
sofisticado que se desplegaría en última instancia a sus oficinas a través del mundo. Se
desarrolló durante dos años y tuvo un costo de $10 millones de dólares, más adelante, las
oficinas del campo rechazaron utilizar el software porque no cumplía con los requisitos
establecidos. En vez de ayudar a dinamizar un proceso importante del negocio, el software
realmente lo obstaculizó.
En 8,000 proyectos software:
El 31 % de los proyectos fueron cancelados antes que hayan sido terminados.
El 53 % de los proyectos su costo fue 189 % de su costo original.
En compañías grandes, el 9 % de los proyectos están a tiempo y en presupuesto.
En compañías pequeñas, 16 % de proyectos están a tiempo y en presupuesto.
Factores debilidad del Proyecto % de
Respuesta
Carencia de información del usuario
Requisitos y especificaciones incompletos
Cambios en los requisitos y
especificaciones
12.8 %
12.3 %
11.8 %
Esta tabla muestra que los requisitos pobres son el problema más grande. ¿Si no está claro lo
que se supone construir, cómo se puede estimar el costo del edificio? ¿Cómo puede crear un
plan del proyecto, asignar recursos, determinar los componentes del sistema en el diseño, o
crear órdenes de trabajo?
Se necesita requisitos exactos para realizar estas actividades. Por supuesto, los requisitos se
desarrollan mientras procede un proyecto, pero los requisitos básicos cuidadosamente
redactados proporcionan un punto de partida. Entonces, a medida que avanza el proyecto, se
puede obtener los detalles y actualizar los documentos de planificación cuando los requisitos
evolucionan.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 100
¿Qué es un requisito? Este artículo procura explicar este término comúnmente mal entendido.
¿Por qué necesitamos requisitos?
Usamos los requisitos para una variedad de propósitos, incluyendo:
El alcance del proyecto
Estimar costo
Presupuesto
Planificación del proyecto
Diseño del software
Pruebas del software
Documentación y manuales de entrenamiento
Los individuos de una organización tienen un gran interés en la producción de requisitos
sólidos. Tanto si eres un cliente o estás implicado en la contratación pública, las finanzas y
contabilidad o de TI, usted es un actor importante en el proceso de gestión de los requisitos.
Muchos equipos de proyectos tratan los requisitos como una declaración de propósitos para la
aplicación y los expresan en términos muy generales, por ejemplo: "el sistema debe tener la
capacidad de crear notificaciones de la interrupción cuando exista un problema". Pero, ¿es un
requisito sólido? Para responder a esta pregunta, vamos a ver cómo las necesidades se
documentan.
CLASIFICANDO Y DOCUMENTANDO LOS REQUISITOS
Los requisitos no son requisitos a menos que se anoten. En otras palabras, ni conversaciones
de pasillo, ni “notas mentales” constituyen requisitos.
Por lo general la captura de requisitos en tres documentos separados:
Necesidades de los interesados
Características del software
Especificación de requisitos de software
En mi organización, asociamos una media docena de atributos (por ejemplo, la prioridad,
estado, etc.) con cada requisito para ayudar con la toma de decisión, programación, etc. La
información contenida en un documento único de requisitos debe ser referenciable en los
demás. Por ejemplo, la información registrada en el documento de las características del
software debe apoyar y ser atribuible a uno o más elementos que figuran en el documento de
necesidades de los interesados (stakeholders).
Para entender mejor las relaciones entre estos documentos, volvamos a la pregunta anterior
sobre si la declaración: "El sistema debe ser capaz de crear notificaciones de corte de luz” es
un requisito válido. La respuesta es, "todavía no". Lo que expresa esta declaración es una
necesidad. La captura de esta necesidad es un paso hacia la formulación de un requisito sólido,
pero la declaración no puede estar sola, primero debe traducir en una o más características que
se captura en un documento de característica del software. Estas características, a su vez, en
seguida, deberá ser detallado en el documento de Especificación de Requisitos de Software.
El uso de estos tres documentos separados ayuda a simplificar el proceso de revisión de
requisitos. Aunque un director ejecutivo podría ser un lector / aprobador de necesidades de los
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 101
interesados y los documentos Características del software, él podría delegar la responsabilidad
de lectura y aprobación de la Especificación de Requisitos de Software. El mantenimiento de
estos documentos específicos diferentes permite a los lectores entender las partes específicas
del sistema. También promueve una mejor rendición de cuentas – un elemento clave para el
éxito del proceso de desarrollo del software.
DOCUMENTANDO LAS NECESIDADES DE LOS INTERESADOS
Echemos un vistazo a lo que cada uno de estos documentos contiene (ver la Figura 1).
Empezaremos con el documento de necesidades de los interesados.
Figura 1. Categoría de Requisitos
Al describir lo que captura cada documento, tenga en cuenta que todo lo que las necesidades y
requisitos que se formule al inicio del proyecto se desarrollará como avances del proyecto. Si
está usando un enfoque de desarrollo iterativo, deberá evaluar sus necesidades después de
cada iteración, y si se realizan cambios en un documento debe actualizarse los demás para
mantenerse la coherencia.
Las necesidades de los interesados, forman parte del dominio del problema, describen lo que
requieren para un proyecto exitoso. En otras palabras, deben describir lo que la aplicación
debe hacer para ayudar a mejorar o disminuir el costo de un proceso de negocio, aumentar los
ingresos, o cumplir con las obligaciones reglamentarias o de otra índole.
La documentación de las necesidades de los interesados implica la identificación,
comprensión, y representan puntos de vista diferentes. A menudo, los usuarios y los
interesados no saben cómo resolver todo el problema, pero son expertos en explicar lo que
necesitan para hacer mejor su trabajo. Cada interesado ve el problema desde una perspectiva
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 102
diferente. Por lo tanto, usted debe entender las necesidades de todos los interesados a fin de
entender el dominio del problema entero.
El primer paso es identificar a todos los interesados. Los usuarios representan una clase de
interesados, pero de ninguna manera representan los intereses de toda la organización. Otras
clases de interesados pueden provenir de finanzas y contabilidad, compras y TI, así como de
otros departamentos u organizaciones que directa o indirectamente apoyan o se benefician del
proyecto.
Usted debe identificar (y reclutar a) al menos un representante de cada clase de las partes
interesadas que hablan de toda la clase. Además, el documento de su lista de interesados para
que todo el mundo sepa que representa cada clase.
Usted puede obtener las necesidades de las partes interesadas utilizando varias técnicas, entre
ellas reuniones, cuestionarios, guiones gráficos y sesiones de Desarrollo de Aplicación
Conjunta (JAD). Las explicaciones de estas técnicas específicas están fuera del alcance de este
artículo, ahora solo son aspectos importantes del proceso ser concientes de cómo hacer las
preguntas y qué formato utilizar.
Echemos un vistazo a un proyecto hipotético encaminado a simplificar la solicitud de
asistencia para una gran corporación, el departamento de TI, vamos a usar este proyecto como
ejemplo para el resto de este artículo. Imagine que usted, un miembro del equipo del proyecto,
se han reunido con el gerente de mesa de ayuda o formuló un requisito que dice: “Tiene que
ser capaz de aumentar el número de llamadas de apoyo a su equipo que pueda manejar un 30
por ciento, sin aumentar el número de empleados”.
Tenga en cuenta que este requisito provee poca información, pero está claro que transmite lo
que quiere el cliente en un nivel alto. La ambigüedad se espera que en esta etapa, se capturara
más detalle más adelante.
Pero no todas las necesidades que reúne describirán la funcionalidad del sistema. Por ejemplo,
un interesado de finanzas pudo decir, "El presupuesto para la aplicación inicial de la solicitud
del proyecto mesa de ayuda no pude superar los 350 mil dólares”. Por supuesto, esta
necesidad perfectamente válida podría estar en conflicto con las necesidades de otros sectores
de interesados que podrían hacer que el presupuesto exceda de $350 mil dólares, la solución
de las necesidades en conflicto es una parte normal del proceso de gestión de requisitos. Sin
embargo, en principio, usted debe centrarse en la obtención y registro de la perspectiva de
cada uno de los interesados; la resolución de conflictos puede venir más adelante en el
proceso.
DOCUMENTANDO LAS CARACTERÍSTICAS DEL SOFTWARE
Después de haber definido las necesidades de los interesados, debe traducir en un conjunto de
características de sistema diferentes. ¿Cuál es la diferencia entre las necesidades y las
características? Las necesidades no indican una solución particular; sino que simplemente
describen la necesidad del negocio. Por ejemplo, si un interesado dice, "Tenemos que
racionalizar el apoyo del servicio de asistencia de aplicaciones de proceso, porque no
podemos continuar con la llamadas” esa persona está expresando una necesidad que el equipo
de desarrollo puede traducir como una característica.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 103
Sin embargo, si el interesado dice: "Necesitamos un sistema Web para que los clientes puedan
ingresar sus solicitudes de soporte propio”, el interesado ya ha traducido en la necesidad de
una función. Es perfectamente bien para las partes interesadas expresarse en la forma que
deseen, a menudo, se le quiere hacer preguntas adicionales para comprender con claridad las
necesidades y características. Voy a explicar por qué en un momento. Por ahora, vamos a
definir lo que es una caracteristica.
Una característica es un servicio que el sistema proporciona para satisfacer una o más
necesidades de los interesados.
Es importante que el equipo del desarrollo entender la distinción entre las necesidades y las
características y registrarlos en documentos separados. ¿Por qué deben separar las necesidades
de las características? Las necesidades son parte del dominio del problema, y las
características son parte del dominio de la solución. Es de importancia crítica para
comprender plenamente el dominio del problema antes de decidirse por una solución; a
menudo, usted encontrará oportunidades de generalizar la solución una vez que comprender a
fondeo el problema. En otras palabras, separar las necesidades de las características, puede
encontrar un conjunto común de características que satisfagan la necesidades múltiples. Al
igual que el documento de necesidades de los interesados, el documento Características de
software debe estar disponible para todos los miembros del equipo durante todo el proceso. Y
es importante mantener la trazabilidad de cada función a su necesidad correspondiente.
ID Necesidad Interesado
N1 “Necesidad de notificar al administrador de
soporte cuando una “petición de soporte” es
iniciado”.
Administrador de Soporte
N2 “Necesidad de asignar la petición de soporte al
ingeniero de soporte apropiado”
Administrador de Soporte
N3 “Necesidad de mantener informado al cliente del
progreso de la petición de soporte”
Cliente (usuario)
Tabla 2. Necesidades de un Interesado
ID Características Descripción Mapea a
F1 El sistema será orientado al
flujo de trabajo
La petición de soporte irá a
través de una serie de etapas
y de asignaciones
N1, N2, N3
F2 La capacidad de notificación
de correo electrónico
Un sistema de notificación
de correo electrónico
centralizado que será
utilizado por el motor de
flujo de trabajo
N1, N2, N3
Tabla 3. Características del Sistema mapeando las necesidades de
los interesados
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 104
Tener en cuenta que este es un ejemplo muy simplificado. Los sistemas complejos pueden
incluir muchas personas involucradas, interfaces del sistema externo, flujos de trabajo más
complejos y analíticos, y otros elementos que se hacen traduciendo las necesidades en
características mucho más difícil.
DOCUMENTANDO LOS REQUISITOS DE SOFTWARE
Después de analizar y generalizar las necesidades y características, es el momento de
adentrarse más en el dominio de la solución mediante el análisis y captura de los requisitos del
sistema. Ahora tenemos el conocimiento necesario para definir un requisito:
... una capacidad de software que se debe cumplir o poseer por un sistema o un
componente del sistema para satisfacer un contrato, estándar, o una característica
deseada.
En pocas palabras, los requisitos deben cumplir uno o más de los siguientes criterios:
1. Las obligaciones del contrato.
2. Los estándares.
3. Las necesidades y características deseadas.
Podemos clasificar los requisitos en dos categorías: requisitos funcionales y requisitos no
funcionales.
Los requisitos funcionales presentan una descripción completa de cómo el sistema
funcionará desde la perspectiva del usuario. Se debe permitir que todos los interesados del
negocio y los técnicos caminen a través del sistema y ver todos los aspectos de cómo debería
funcionar antes que sea construido.
Los requisitos no funcionales, en cambio, determinan las propiedades y están sujetos a
limitaciones en el proyecto o sistema. Especificar los atributos del sistema, en lugar de lo que
hará el sistema. Por ejemplo, un requisito no funcional podría afirmar: "El tiempo de respuesta
de la página de inicio no debe exceder de cinco segundos".
Estos son algunas de las cualidades que deben caracterizar a las descripciones contenidas en el
documento de Especificación de Requisitos Software:
1. Falta de ambigüedad. El equipo del desarrollo de software no será capaz de producir
un producto que satisface las necesidades de los usuarios, si uno o más de los
requisitos se pueden interpretar de varias maneras..
2. Completo. Al inicio de su proyecto, usted no debe esperar conocer todos los requisitos
del sistema en detalle; el equipo de desarrollo no debe perder el tiempo tratando de
precisar las cosas que están destinados a cambiar. Como avanza el proyecto, sin
embargo, usted debe tener su documento de la especificación de requisitos de software
al día; cuando usted obtenga más conocimiento sobre el sistema, el documento de la
especificación debe ser más completo.
3. Consistencia. No se puede construir un sistema que satisfaga todos los requisitos, si
dos requisitos están en conflicto o si los requisitos no reflejan los cambios que ese
hicieron en el sistema durante el desarrollo iterativo y prueba de funcionalidad.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 105
4. Traceabilidad. El equipo debe rastrear la fuente de cada requisito, ya pasado de ser un
requisito más abstracto, o una reunión específica con un usuario destino.
5. Ninguna información del diseño. Mientras que los requisitos direcciones
comportamientos externos, como vistas por usuarios o por otros sistemas de interfaz,
entonces son requisitos inmóviles, sin importar su nivel del detalle. Sin embargo, si un
requisito procura especificar sub componentes particulares o sus algoritmos, estos se
convierten en información de diseño.
CAPTURANDO REQUISITOS FUNCIONALES
Para documentar requisitos funcionales puede capturar 3 categorías de información:
1. Casos de Uso
2. Capacidades funcionales
3. Reglas de negocio
Los casos de uso definen paso a paso la secuencia de acciones entre el usuario y el sistema.
Las organizaciones están adoptando con rapidez los casos de uso como un medio para
comunicar los requisitos porque:
Son más fáciles de crear, leer y entender las especificaciones funcionales.
Mostrar cómo el sistema trabajará desde la perspectiva de los usuarios en lugar de la
perspectiva del sistema.
Nos obligan a pensar sobre el final del juego: ¿Cuál es el usuario que intenta llevar a
cabo mediante el sistema?
Nos obligan a definir cómo debería funcionar el sistema, paso a paso.
Proporcionan una base excelente para la creación de casos de prueba y ayuda a
asegurar que estos están construidos antes de que el código esté escrito.
Proporcionar los requisitos “lenguaje común” que es fácil para los interesados,
usuarios, analistas, arquitectos, programadores, probadores para entender.
El resultado final de un caso del uso es un requisito completo. En otras palabras, cuando se
comunica a través de casos de uso, no dejar a los desarrolladores determinar el
comportamiento externo de la aplicación. Especificar el formato y los detalles para la creación
de un caso del uso va más allá del alcance de este artículo, pero es importante capturar los
casos utilizando una plantilla estándar que contiene todos los componentes de una
especificación completa. Éstos incluyen un diagrama de casos del uso, primario y la asistencia
de los actores, lo que provocó los acontecimientos, las descripciones de casos de uso, las
condiciones previas, las condiciones de correos, las corrientes alternativas, el error y las
condiciones de excepción, los riesgos y problemas, las capacidades funcionales y las reglas de
negocio.
Tener en cuenta que los casos de uso no se derivan en requisitos hasta que usted defina las
capacidades funcionales y las reglas de negocio que se aplican a los casos de uso.
Las capacidades funcionales definen qué acción específica debe tomar el sistema en una
situación dada. Usted puede relacionar directamente las capacidades funcionales de un caso de
uso específico o definirlos de forma global para todo el sistema. Una capacidad funcional para
nuestro aplicación de ejemplo podría ser: "Al crear la petición de ayuda, llenar la" creado por
el campo “con la identificación ID de inicio de sesión del usuario".
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 106
Las reglas de negocio indican la condición bajo la cual un caso del uso es aplicable y la regla
que se aplicará. Por ejemplo, una regla de negocio relacionada con un caso del uso pudo
indicar: "Solo el administrador del sistema puede modificar el nombre del cliente en el caso de
uso UC01". Al igual que las capacidades funcionales, las reglas de negocio pueden estar
directamente relacionadas con un caso del uso o definir de forma global para todo el sistema.
CAPTURANDO REQUISITOS NO-FUNCIONALES
Los requisitos no funcionales son cualidades que tienen el sistema o el ambiente. Tales
requisitos no están siempre en las mentes de los interesados, y debe hacer a menudo un
esfuerzo especial de dibujarlas hacia fuera. Para hacer más fácil capturar requisitos no
funcionales, los organizamos en cinco categorías:
1. Usabilidad
2. Confiabilidad
3. Rendimiento
4. Mantenibilidad
5. Seguridad
La Usabilidad describe la facilidad que tiene el sistema para poder ser usado o comprendido.
Un requisito de usabilidad típico podría:
El sistema debe permitir a los usuarios novatos instalar y operar con poco o ningún
entendimiento.
El usuario final deberá ser capaz de hacer un pedido dentro de los treinta segundos.
El usuario final deberá ser capaz de acceder a cualquier página dentro de cuatro
segundos.
La fiabilidad describe el grado en que el sistema debe funcionar para los usuarios. Las
especificaciones para la fiabilidad normalmente se refieren a la disponibilidad, tiempo medio
entre fallos, tiempo medio de reparación, la exactitud, y los errores aceptables. Por ejemplo:
El sistema deberá cumplir los términos de un Acuerdo de Nivel de Servicio.
El tiempo medio hasta el fallo será de al menos cuatro meses.
Las especificaciones de rendimiento generalmente se refieren al tiempo de respuesta,
rendimiento de las transacciones, y a la capacidad. Por ejemplo:
Todas las páginas Web deben descargarse en un plazo de tres segundos durante una
carga media, y cinco segundos durante una carga máxima.
Al ejecutar una búsqueda, el sistema debe ser capaz de mostrar 500 resultados por
página.
La mantenibilidad refiere a la capacidad del software de ser modificado o de ser mantenido
fácilmente para acomodar uso típico o de escenarios de cambio. Por ejemplo, en nuestro
ejemplo, help desk, lo fácil debe ser para añadir nuevas aplicaciones en el marco de apoyo?
Estos son algunos ejemplos de los requisitos de mantenibilidad:
El sistema permitirá a los usuarios crear nuevos flujos de trabajo sin necesidad de
programación adicional.
El sistema permitirá que el administrador del sistema cree y llene las tablas de
impuesto para el año fiscal siguiente.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 107
La seguridad se refiere a la capacidad de prevenir y/o de prohibir el acceso al sistema por
partes no autorizadas. Algunos ejemplos de los requisitos de seguridad son:
La autentificación del usuario se realizará a través del inicio de sesión único del
sistema corporativo.
Solo los administradores de la nómina autorizados se permitirá acceder a la
información de pago de los empleados.
CONCLUSIÓN
En un proyecto del desarrollo del software, los requisitos conducen casi todas las actividades,
tareas, y entregables. Mediante la aplicación de algunas habilidades claves y un enfoque de
desarrollo iterativo, se pueden evolucionar los requisitos que ayudará a garantizar el éxito de
su proyecto. Utilice los diferentes documentos para registrar las necesidades, las
características y los requisitos del software y mejorar la exactitud de sus requisitos
compartiendo la responsabilidad de la revisión. Con estos documentos puede también
establecer trazabilidad entre las necesidades, características, y requisitos para garantizar que
su Especificación de Requisitos Software seguirá coincidiendo con los objetivos del negocio.
Es típicamente muy costoso corregir los errores del requisito de que permanece aún sin
descubrir hasta que todo el código se ha escrito. Los casos de uso pueden ayudar a evitar tales
errores comunicando los requisitos a todos los interesados del proyecto; desarrollar el sistema
en iteraciones le ayudará a identificar qué requisitos puede ser que necesite para especificar
más detalladamente o para cambiar.
Recuerde: Cuando reúna a los interesados, pregunte sobre las consideraciones no funcionales
así como los requisitos de la funcionalidad específica. Y tenga siempre presente que los
requisitos sólidos son lo más importante para producir software útil y de alta calidad.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 108
LECTURA # 02
WORKFLOW DE REQUISITOS
EN RUP
Este artículo describe conceptos importantes necesarios para capturar y gestionar los
requisitos del sistema eficientemente y diseñar las interfaces de usuario enfocadas en las
necesidades y objetivos de los usuarios, así como de los otros stakeholders importantes. Se
incluye una descripción breve del workflow de requisitos del RUP.
Propósito
Los objetivos del workflow de requisitos son los siguientes:
Establecer y mantener los acuerdos con los clientes y otros stakeholders en lo qué
hará el sistema – y cómo?
Proporcionar a los desarrolladores del sistema un mejor entendimiento de los
requisitos de sistema.
Definir los límite del sistema (delimitar).
Proporcionar una base para planear el contenido técnico de iteraciones.
Proporcionar una base para estimar costos y tiempo para desarrollar el sistema.
Definir una interfaz de usuario para el sistema, enfocado en las necesidades y objetivos
de los usuarios.
El workflow de requisitos describe cómo definir una visión del sistema y trasladar la visión
en un modelo de caso de uso, con las especificaciones suplementarias, definir los requisitos
de software detallados del sistema. En suma, el workflow de requisitos describe cómo usar
los atributos de los requisitos para ayudar a manejar el alcance y los cambios en los
requisitos del sistema.
¿QUÉ ES UN REQUISITO?
Un requisito es una condición o capacidad que puede conformar un sistema.
En su esfuerzo por establecer un criterio de calidad como una base como métricas para la
evaluación de los sistemas de software, Robert Grady, durante su estadía por HP, categorizó la
necesidad de atributos de calidad para un sistema de software como:
F - Funcionalidad
U - Usabilidad
R - Confiabilidad
P - Rendimiento
S - Mantenibilidad
referido como “FURPS”. Hemos usado éste acrónimo como un recordatorio de los tipos de
requisitos que necesitamos para considerar como se define completamente un sistema de
calidad.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 109
REQUISITOS FUNCIONALES
Cuando pensamos en requisitos de un sistema, naturalmente primero tenemos que pensar qué
cosa hará el sistema en beneficio del usuario. Después de todo, los desarrolladores tenemos
una “diagonal para la acción”. Expresamos estas acciones como función o comportamiento,
requisitos, que especifican las acciones que un sistema puede ejecutar.
Los requisitos funcionales son usados para expresar el comportamiento de un sistema
especificando las condiciones de ingreso y salida que se espera como resultado.
REQUISITOS NO FUNCIONALES
Un sistema puede también exhibir una variedad de atributos que no están descritas
específicamente por los requisitos funcionales de los sistemas. Un conjunto de requisitos
adicionales impuestos para que el sistema pueda contar con estos atributos de calidad. Nos
referimos a este conjunto de requisitos como requisitos no funcionales. Son importantes
como lo son los requisitos funcionales.
Usando las categorías FURPS, la lista siguiente resume las consideraciones para definir los
atributos de calidad no funcionales de un sistema:
Usabilidad
Los requisitos de la usabilidad tratan el factor humano, la facilidad de aprender, y la
facilidad de uso y consistencia en la interfaz de usuario, la documentación de usuario y
materiales de entrenamiento.
Confiabilidad
Los requisitos de la confiabilidad tratan la frecuencia y la severidad de las fallas, de la
recuperabilidad, de la previsibilidad y de la exactitud.
Funcionalidad
Los requisitos de funcionalidad imponen las condiciones de los requisitos funcionales – por
ejemplo, un requisito que especifica la tarifa de transacción, velocidad, disponibilidad, tiempo
de respuesta, tiempo de recuperación, o demora usada con el cual una acción dada puede ser
ejecutada.
Mantenibilidad
Los requisitos de mantenibilidad tratan las pruebas, el mantenimiento, y otras cualidades
requeridas para tener el sistema al día después de un cambio de versión. Los requisitos de
mantenibilidad no son necesariamente impuestos en el sistema por si misma pero intenta
ofrecer referencia del proceso usado para crear el sistema o varios artefactos del proceso de
desarrollo del sistema. Un ejemplo es el uso de un código estándar C++ específico.
No es importante dividir los requisitos en estas categorías, y existe un debate alrededor si un
requisito específico es un requisito de usabilidad o mantenibilidad. El valor de estas
definiciones es que dan una plantilla, o una lista de comprobación, para la elicitación de los
requisitos y para determinar lo completo de tu comprensión. Es decir, si entiendes los
requisitos de todas estas categorías, tendrás un grado de certeza de haber entendido los
requisitos críticos antes de que comiencen la inversión substancial en el desarrollo. Se
encontrará a menudo, por ejemplo, que ciertos requisitos de confiabilidad están implicados
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 110
en los requisitos funcionales dados, y es igualmente importante explorar estos requisitos de
la confiabilidad. Un sistema que no puede resolver un requisito implicado con la confiabilidad
u otro requisito no funcional no puede resolver una necesidad funcional explícita.
TIPOS DE REQUISITOS
Tradicionalmente, los requisitos son vistos como especificaciones textuales detalladas que
se ajusta a una de las categorías mencionadas, expresadas en la forma “El sistema tendrá que
…. “. Gestionar efectivamente el proceso de requisitos completo, sin embargo, es provechoso
ganar una comprensión del conocimiento del usuario y las necesidades de los involucrados
que deben satisfacer el sistema desarrollado.
Este entendimiento del grupo de desarrollo con el por qué (“¿Qué necesita el sistema para
operar con un 99.3% de exactitud?”). Conociendo esto, el equipo podrá hacer un mejor trabajo
de interpretar los requisitos (“Haciendo esto también necesario para operar en 99.3 % de
exactitud mientras la rutina de mantenimiento general?”) así como permitir compensaciones y
decisiones de diseño que optimicen el proceso de desarrollo (“Si nosotros podemos atribuir 92
% de exactitud con doble esfuerzo, es razonable?”).
STAKEHOLDERS: REQUISITOS VERSUS NECESIDADES
Stakeholder persona o representativo de una organización que tiene un intereses concedido
en el resultado de un proyecto.
Un stakeholder es el usuario final, pero se consideran además stakeholder importantes, un
comprador, un contratista, un desarrollador, un administrador de proyectos, o alguno que
brinde las necesidades en el proyecto. Por ejemplo, un stakeholder no usuario puede ser un
administrador del sistema que trabaja de forma dependiente en ciertas condiciones impuestas
por el software del sistema al usuario. Otro stakeholders no usuario representa el beneficiario
económico del sistema.
Usando esta definición, es obvio que el grupo de desarrollo pueda entender las necesidades
específicas de los stakeholders claves del sistema. Pero ¿cómo nosotros identificamos estas
necesidades? Es importante que nosotros veamos todos los tipos de requisitos de los
stakeholders (datos de entrada usados que figuran como necesidades) a través del ciclo de
vida del desarrollo. En el proyecto, podemos usar entrevistas, cuestionarios y talleres; sin
embargo en un proyecto hay cambios en los requisitos, reportes defectuosos, y requisitos
nuevos. Estos requisitos pueden ser vagos y ambiguos – y a menudo están como una
necesidad. Por ejemplo:
“Yo necesito la manera más fácil de compartir mi conocimiento del estado del proyecto”
“Yo necesito incrementar mi productividad”
“Necesitamos incrementar el rendimiento del sistema”.
Los requisitos como un contexto muy importante para el entendimiento de las necesidades
reales de los stakeholders y brindar un ingreso crítico para los requisitos del producto. Este
ingreso provee una pieza crucial del rompecabezas que permite determinar los porqués y los
qués del comportamiento del sistema.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 111
CARACTERÍSTICAS DEL SISTEMA
Cuando se entrevista a los stakeholders sobre sus necesidades y requisitos , ellos típicamente
su necesidad real (ejemplo:
“Si Joe y yo no iniciamos mejor la comunicación, nuestro trabajo estará en riesgo”
“Yo deseo permitir enviar un archivo RTF en un mensaje e-mail”
“El vehículo tienen un sistema de control por computadora dedicado a cada …” .
Ellos a menudo describen una abstracción (ejemplo, “Yo deseo automatizar una notificación
por e-mail” o “Yo deseo un vehículo con ABS”).
Llamamos a este tipo de abstracción – de alto nivel de expresión del comportamiento del
sistema- como características del sistema.
Técnicamente, podemos pensar de una característica como “un servicio a ser provisto por
el sistema que directamente satisface una necesidad de usuario”. A menudo estas
características no están bien definidas, y ellas pueden entrar en conflicto. Ejemplo: “Yo deseo
ABS” y “Yo deseo requisitos de mantenimiento más bajos”, pero no obstante ellos son una
representación de las necesidades reales. Que es suceso en esta discusión es que el stakeholder
tiene ya trasladada la necesidad real (“mejor comunicación con Joe”) en un comportamiento
del sistema (“notificación automática e-mail”). Al obrar así, allí tiene ser un sutil cambio en el
pensamiento de los stakeholders desde el qué “mejor comunicación” al cómo –eso es, ahora
implementado (“notificación automatizada e-mail”).
Discutir estas características en lenguaje natural, documentar y comunicar esto, adiciona
un contexto importante al workflow de requisitos. Adicionar a estas características varios
atributos- así como riesgo, nivel de esfuerzo y prioridad del cliente- adiciona una riqueza al
entendimiento del sistema. Puede usar este conocimiento para gestionar el alcance a causa de
una inversión substancial que tiene que ser hecha en características de menor prioridad.
REQUISITOS DE SOFTWARE
Es adecuado comunicar a los desarrolladores exactamente qué es lo que el sistema debe hacer
“Hey, manda la cuenta, ir el código un sistema automático de la notificación del e-mail”.
Necesita un nivel adicional de especificación para traducir esta necesidad y características
a las especificaciones que puede diseñar, poner en ejecución, y probar determinar la
conformidad del sistema. En este nivel de la especificación, puede ocuparse de los requisitos
funcionales y no funcionales del sistema.
ESPECIFICANDO REQUISITOS DE SOFTWARE CON CASOS DE USO
Entendemos el modelado de caso de uso, una técnica potente que puede usarse para expresar
el comportamiento detallado del sistema vía simple de interacciones usuario-sistema que los
usuarios y los desarrolladores pueden entender fácilmente.
Un modelo de caso de uso es un modelo del sistema y su comportamiento. Consiste de un
conjunto de actores que representan las entidades externas que interactúan con el sistema a
lo largo con casos de uso que definen como el sistema es usado por los actores. El modelo de
caso de uso es una manera efectiva de expresar estos requisitos de software más detallado.
CAPTURANDO Y GESTIONANDO REQUISITOS
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 112
Para cada proyecto puede haber una estructura común de requisitos, como se muestra en la
Figura. Primero, recoge las necesidades de los stakeholders, se traducen en características y
posteriormente en una lista de requisitos extraídos de los usuarios finales, clientes,
comercializadores, y otros stakeholders del proyecto.
Tipos de requisitos y relaciones con los artefactos
El documento visión contiene el conjunto de necesidades de los usuarios y stakeholders
claves y las características de alto nivel del sistema. Estas características del sistema
expresan los servicios que pueden ser entregados para satisfacer las necesidades de los
stakeholdes. Llamamos a estas relaciones traceabilidad de requisitos. Decide incluir las
características en el documento visión basadas en un análisis de costos de implementación por
cada característica deseada y la determinación del retorno en esta inversión.
Antes de iniciar la codificación, trasladar estas características en requisitos de software
detallados en un nivel en el cual se pueda diseñar y construir el sistema e identificar los casos
de prueba del comportamiento del sistema. Estos requisitos detallados son capturados en el
modelo de caso de uso y otras en las especificaciones suplementarias, el cual captura estos
requisitos que no se ajustan en los casos de uso.
Como se tiene detallado los requisitos, se puede guardar en un medio las necesidades de los
stakeholders y las características del sistema para medir que se interprete la visión
correctamente. Esta consideración de características y requisitos de software implica una
relación de trazabilidad donde los requisitos del software son derivados de uno o más
características del sistema, los cuales satisfagan las necesidades de los stakeholders.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 113
Los requisitos detallados se muestran en el modelo de diseño y la documentación del usuario
final y son verificados por un modelo de prueba.
A través del ciclo de vida de desarrollo del proyecto, puede utilizar estas características,
basadas en prioridad del cliente, riesgo, y estabilidad arquitectural, para dividir el conjunto de
requisitos en “slices” y detallar estos en un modo incremental. Puede detallar estos requisitos,
encuentra defectos e inconsistencias que pueda necesitar regresar a los stakeholders para
clarificar, negociar y actualizar las necesidades de los stakeholders y la visión. Así, el
workflow de requisitos se repite de una manera iterativa hasta que todos los requisitos estén
definidos, es considerado la retroalimentación y son gestionados los cambios inevitables.
DISEÑANDO UNA INTERFAZ CENTRADO EN EL USUARIO
La expresión de diseño interfaz usuario puede significar una de las dos cosas siguientes:
La forma visual de la interfaz de usuario de modo que maneje varios requisitos de
usabilidad.
El diseño de una interfaz de usuario en términos de clases de diseño (y componentes
tales como clases ActiveX y JavaBeans) que se relacione a otras clases de diseño que
trata con la lógica de negocio, persistencia, y así sucesivamente, y conducir a la
implementación final de la interfaz de usuario.
En el workflow de requisitos, operamos sobre la primera definición, enfocado en la
realización de un diseño centrado en el usuario. Los perfiles de usuario y ambientes de
usuario están especificados en el documento visión, con la principal entrada al diseño de la
interfaz de usuario siendo el modelo de caso de uso y las especificaciones suplementarias, los
cuales son desarrollados en conjunto con los usuarios o sus representativos y otros
stakeholders claves. Los resultados son definiciones detalladas de las características del
usuario y las realizaciones de las partes específicas de la interfaz de usuario de los casos de
uso.
Se construye un prototipo de interfaz de usuario, mayormente usando una herramienta de
prototipeado. Llamamos a estos prototipeados interfaz de usuario. Proporciona un
mecanismo valioso de la regeneración para determinar los requisitos finales del sistema.
WORKFLOW DE REQUISITOS
La figura 9-2 resume las actividades en el RUP que constituyen el workflow de requisitos,
como se muestra en el diagrama:
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 114
Workflow en requisitos
Analizar el problema
Declaración del problema que estamos intentando solucionar; identificación de los
stakeholders; los límites y los apremios del sistema.
Entender las necesidades de los stakeholders
Usando varias técnicas de elicitación de requisitos de los stakeholder y obtener un
entendimiento claro de las necesidades reales de los usuarios y stakeholders del sistema.
Definir el sistema
Establecer el conjunto de características del sistema a ser considerado para la entrega;
determinar el criterio para priorizar esto e iniciar el conjunto de expectativas reales con los
stakeholders en como las características son derivadas; identificando los actores y los casos de
uso necesarios para cada característica clave.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 115
Gestionar el alcance del sistema
Coleccionar la información importante de los stakeholders en el proyecto y administrar esto
junto con los requisitos, los atributos de los requisitos que se utilizarán en dar la prioridad y
el alcance del sistema que se puede derivar en tiempo y en presupuesto.
Refinar la definición del sistema
Usando un modelo de caso de uso detallar los requisitos del software para llegar a un acuerdo
con el cliente en la funcionalidad del sistema, y capturar otros requisitos importantes, así
como los requisitos no funcionales, los apremios en el diseño y así sucesivamente.
Gestionar los cambios en los requisitos
Usar atributos de requisitos y la trazabilidad para medir el impacto de los cambios de
requisitos; usar una autoridad de control central, así como un Change Control Borrad (CCB)
Tablero de Control de Cambios, para controlar los cambios de requisitos; manteniendo el
acuerdo con el cliente y el conjunto de expectativas realistas en el que serán derivadas.
WORKERS EN REQUISITOS
La figura muestra los principales workers y artefactos en el workflow de requisitos:
Workers y artefactos en el workflow de requisitos
Analista de sistemas
El analista de sistemas conduce y coordina la elicitación de los requisitos y el modelado de
casos de uso mostrando la funcionalidad del sistema y delimitando el sistema.
Especificador de Caso de Uso
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 116
El especificador de caso de uso detalla todas las partes de la funcionalidad de los sistemas
para describir los aspectos de los requisitos de uno o varios casos de uso.
Diseñador de la interfaz usuario
El diseñador de la interfaz de usuario es responsable de seleccionar el conjunto de casos de
usuario para mostrar las interacciones esenciales de los usuarios con el sistema. Trabajando
con los usuarios, el Diseñador de la Interfaz-Usuario desarrolla los Storyboards de los casos
de uso, y un prototipo de la interfaz de usuario para ayudar a determinar los requisitos
finales del sistema.
Trabajando con los stakeholders del proyecto, el analista de sistemas analiza el problema y
trabaja con los stakeholders para entender lo que necesitan y definen qué es lo que el sistema
hará y no deberá hacer – también identifican los requisitos no funcionales. El analista de
sistemas puede entonces desarrollar la visión del proyecto. Esta visión, expresada como un
conjunto de características escritas desde la perspectiva de los stakeholders, básico para
desarrollar un contexto de un modelo de caso de uso.
El especificador de caso de uso es asignado para un conjunto de casos de usos y de requisitos
no funcionales, detalla y hace consistente con otros artefactos del workflow de requisitos. El
especificador de caso de uso no trabaja solo se comunica con los otros especificadores de caso
de uso así como con el analista de sistemas.
El diseñador de la interfaz de usuario trabaja en paralelo con el especificador de caso de uso
para definir la interfaz del usuario del sistema. En más casos, existe una interacción sinérgica
entre los dos.
Otro worker involucrado en el workflow de requisitos es el Arquitecto, que está involucrado
primariamente en las iteraciones anteriores y trabaja con el analista de sistemas y el
especificador de caso de uso para medir la integridad de los casos de uso significantes
arquitecturalmente.
El revisor de requisitos es otro rol importante, representando por alguien que verifica que los
requisitos sean percibidos e interpretados correctamente para el equipo de desarrollo. Los
revisores tienen propósitos diferentes, ellos ejecutan varias veces la revisión en el workflow
de requisitos por los revisores de requisitos con perfiles diferentes.
Los individuos actúan como workers de un equipo que ejercita el workflow de requisitos
iterativamente a través del ciclo de vida del proyecto.
ARTEFACTOS USADOS EN REQUISITOS
Al considerar los requisitos, es importante, primero que todo, entender la definición y el
alcance del problema que estamos intentando resolver con este sistema. El modelo de objeto
de negocio, desarrollado durante el modelado de negocio, servirá para evaluar la entrada de
este esfuerzo. Son identificados los stakeholders, son elicitados los requisitos de los
stakeholders, reunidos y analizado.
Las necesidades de los stakeholder son elicitados y reunidos para obtener una lista deseada
de los diferentes stakeholders del proyecto (cliente, usuarios, etc.) deciden el sistema a incluir,
junto con la información en la cual cada requisito tiene que ser considerado para el proyecto.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 117
Las necesidades y características claves están identificadas en el documento visión, el
modelo de caso de uso, casos de uso, y especificaciones suplementarias se desarrollan para
describir lo que hará el sistema – punto de vista de todos los stakeholders, incluyendo los
clientes y usuarios potenciales, como fuentes de información importante (en suma a los
requisitos del sistema).
El documento visión da una visión completa del sistema a desarrollar y soporta el contrato
entre la autoridad y la organización. El documento visión se escribe desde las perspectivas
de los clientes, enfocando en él las características esenciales del sistema y los niveles
aceptables de calidad. Especifica también las capacidades operacionales (volumen, tiempo
de respuesta, etc.), los perfiles de usuario y las interfaces interoperacionales con entidades del
otro lado del límite del sistema, donde sea aplicable. El documento visión proporciona la
base contractual para los requisitos visible a los stakeholders.
El modelo de caso de uso sirve como un medio de comunicación y sirve como un contrato
entre el cliente, los usuarios y los desarrolladores del sistema en la funcionalidad del sistema,
como sigue:
Los clientes y usuarios para validar que el sistema se convirtiera en lo esperado, y
Los desarrolladores de sistema para construir lo esperado.
El modelo de caso de uso consiste de casos de uso y actores. Cada caso de uso en el modelo
está descrito en detalle, mostrando paso a paso como el sistema interactúa con los actores, y
qué hará el sistema en el caso de uso. Los casos de uso funcionan uniendo a través del ciclo de
vida del software; el modelo de caso de uso es usado en el análisis de sistema, diseño,
implementación y pruebas.
Las especificaciones suplementarias son un complemento importante para el modelo de
caso de uso, porque junto a ello capturan todos los requisitos del software (funcional y no
funcional) que necesitan como Especificación de Requisitos de Software completa.
Una completa definición de los requisitos de software, son descritas en los casos de uso y las
especificaciones suplementarias, puede ser empaquetado para definir una Especificación de
Requisito de Software (SRS) para el producto completo, una “característica” particular, u otro
subsistema agrupado.
Complementariamente a los artefactos mencionados, los siguientes artefactos son también
desarrollados:
Glosario
Storyboard de caso de uso
Prototipo de la interfaz de usuario
El glosario define una terminología común usada consistentemente a través del proyecto u
organización.
Los usuarios actuales y potenciales del sistema están envueltos en el modelado y definición de
la interfaz de usuario del sistema en los storyboards del caso de uso y los prototipos de la
interfaz de usuario, los cuales son desarrollados en paralelo con otras actividades de
requisitos.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 118
HERRAMIENTA DE SOPORTE
Para gestionar efectivamente todos los aspectos de los requisitos del proyecto, manteniendo
los valores de sus atributos y la trazabilidad con otros ítems del proyecto, es esencial tener
el soporte de herramientas de gestión de requisitos. Rational RequisitePro proporciona
soporte en la captura de requisitos y organiza estos en los documentos y en un repositorio de
requisitos con los atributos importantes para gestionar el alcance de los requisitos y los
cambios. Por otra parte, si está usando casos de uso, RequisitePro ayuda a describir las
propiedades textuales de los casos de uso.
Para el modelado visual de los artefactos de los requisitos, Rational Rose proporciona un
soporte automático para los actores y casos de usos en el modelo de caso de uso (con
integración automática para RequisitePro para gestionar sus propiedades textuales, atributos
de requisitos y trazabilidad), con Storyboards de los casos de uso y las clases límites.
Teniendo los artefactos de requisitos en Rose también permite mantener dependencias de
elementos en el modelo de diseño.
Rational SODA ayuda automáticamente a la generación de la documentación. Esto
permite definir un “plantilla inteligente” que puede extraer información desde diferentes
fuentes. Rational SODA es particularmente usado si usa diferentes herramientas para capturar
los resultados de sus workflow, pero puede producir la documentación final junto con esta
información en un lugar.
RESUMEN
La gestión de requisitos establece y mantiene entre los stakeholders y el equipo de
desarrollo lo que el sistema hará.
En un proyecto son considerados diferentes tipos de requisitos incluyendo las
características de alto nivel, así como los requisitos funcionales y no funcionales con
más detalle y los casos de uso.
Para gestionar el alcance del proyecto efectivamente hay que mantener los atributos
de los requisitos y la trazabilidad y manejar los cambios en los requisitos a través
del ciclo de vida del proyecto.
El diseño de la interfaz usuario enfoca las necesidades y objetivos de los usuarios en
el contexto visual en orden a construir un sistema centrado en el usuario y juntar los
requisitos de usabilidad.
Las herramientas de Rational soportan la captura, modelado visual, y la gestión de
requisitos, sus atributos y la trazabilidad.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 119
Glosario
Abstracción
La creación de una visión o modelo que suprime los detalles innecesarios para centrarse en un
conjunto de datos de interés.
Ada
Lenguaje de programación que fue desarrollado por el Departamento de Defensa de los
Estados Unidos como un lenguaje estándar para el desarrollo de software militar. Está basado
en las investigaciones de los lenguajes de programación desde los 70s e incluye
construcciones así como tipos de datos abstractos y soporte para concurrencia. Todavía se
utiliza en grandes sistemas aeroespaciales militares complejos.
Análisis
Parte del proceso de desarrollo de software cuyo objetivo principal es formular un modelo del
dominio del problema. El análisis se centra en qué hacer, el diseño se centra en cómo hacerlo.
Análisis estático Análisis basado en herramientas del código fuente de un programa para descubrir errores y
anomalías. Las anomalías como las asignaciones sucesivas a una variable sin un uso
intermedio pueden ser errores de programación.
Análisis & diseño
Actividades durante la cual se toman decisiones estratégicas y tácticas necesarias para cumplir
los requisitos funcionales y de calidad de un sistema.
Analista
Miembro del equipo del proyecto que es responsable de obtener e interpretar las necesidades
de los stakeholders y comunicar esas necesidades a todo el equipo.
Arquitectura Cliente-Servidor
Modelo arquitectónico para sistemas distribuidos en el que la funcionalidad del sistema se
ofrece como un conjunto de servicios proporcionados por un servidor. Éstos son accedidos
por computadoras clientes que hacen uso de los servicios. Variantes de este enfoque, así como
arquitecturas cliente-servidor de tres capas, utilizan múltiples servidores.
Arquitectura de referencia Arquitectura genérica del sistema que es una arquitectura ideal que incluye todas las
características que los sistemas podrían incorporar. Constituye un modo de informar a los
diseñadores sobre la estructura general de esa clase de sistemas.
Arquitectura de software
De acuerdo a IEEE, la arquitectura de un sistema software es la organización o estructura de
los componentes importantes que interactúan a través de interfaces, los componentes que se
compone de componentes más pequeños e interfaces.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 120
Artefacto
Producto de trabajo formal que:
1) se produce, modificados, o utilizados por una tarea,
2) define un área de responsabilidad
3) está sujeta a control de versiones
Un artefacto puede tener formas múltiples, incluyendo un modelo, un elemento del modelo, o
un documento.
Aseguramiento de la calidad (QA) Proceso general de definir cómo lograr la calidad del software y cómo la organización de
desarrollo conoce el nivel de calidad requerido en el software.
C
Lenguaje de programación que fue originalmente desarrollado para ayudar a implementar el
sistema Unix. C es un lenguaje de implementación de sistemas de relativamente bajo nivel que
permite el acceso al hardware del sistema y que puede ser compilado a un código eficiente.
Todavía se utiliza ampliamente para la programación de sistemas de bajo nivel.
C++
Lenguaje de programación orientado a objetos. C es un subconjunto de C++.
CASE
Ingeniería de software asistido por computador. El proceso de desarrollo de software usa
soporte automatizado.
Cápsula
Patrón de diseño específico que representa un hilo de encapsulamiento de control en el
sistema. Una cápsula es una clase de estereotipo con un conjunto específico de necesidades y
restricciones de las asociaciones y las propiedades.
Caso de uso Especificación de un tipo de interacción con un sistema.
CBSE Ingeniería de Software Basado en Componentes
Desarrollo de software para la independiente composición, componentes desplegable.
Ciclo de vida del software
Utilizado a menudo con otro nombre para el proceso del software. Originalmente acuñado
para referirse al modelo en cascada del proceso software.
Clase del análisis
Abstracción del rol jugado por un elemento del diseñon en el sistema, típicamente en el
contexto de la realización de caso de uso. Las clases del análisis proporcionan una abstracción
para varias funciones, lo que representa el comportamiento común de roles. Análisis de las
clases suelen convertirse en uno o más elementos del diseño, por ejemplo, clases de diseño y
/o cápsulas o subsistemas de diseño.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 121
Clase abstracta Una clase que proporciona un comportamiento común a través de un conjunto de subclases
pero no es diseñado para tener instancias. Una clase abstracta representa un conjunto las clases
derivadas de ella representan las implementaciones del concepto.
Clase de objetos Una clase objeto define los atributos y operaciones de objetos. Los objetos se crean en tiempo
de ejecución mediante la instanciación de la definición de la clase. El nombre de la clase de
objetos puede utilizar como un nombre de tipo en algunos lenguajes orientados objetos.
CMMI
Enfoque integrado para el modelado de madurez de la capacidad del proceso. Apoya los
modelados de madurez discretos y continuos e integra sistemas y modelos de madurez de los
procesos de la ingeniería de software.
Código de ética y práctica profesional
Conjunto de pautas que exponen el comportamiento ético y profesional esperado de los
ingenieros del software. Fue definido por las sociedades profesionales principales de Estados
Unidos (la ACM y la IEEE) y define el comportamiento ético conforme a ocho títulos:
público, cliente y empleador, producto, juicio, gestión, colegas, profesión y personal.
COM+
Un modelo de componentes diseñado para su uso en plataformas Microsoft.
CORBA Common Request Broker Architecture
Conjunto de estándares propuestos por el OMG que define un modelo de objeto distribuido y
las comunicaciones entre objetos.
Componente Unidad de software independiente y desplegable que se ha definido completamente y a la que
se accede a través de un conjunto de interfaces.
Confiabilidad
La confiabilidad de un sistema es una propiedad total que tienen en cuenta la seguridad del
sistema, la fiabilidad, la disponibilidad, la protección y otros atributos. La confiabilidad de un
sistema refleja el grado en el cual los usuarios pueden confiar en el sistema.
Construcción del sistema
Proceso de compilar los componentes o unidades que forman un sistema y enlazarlos con
otros componentes para crear un programa ejecutable. La construcción del sistema está
normalmente automatizada de modo que se minimiza la recompilación. Esta automatización
puede ser incorporada a un sistema de procesamiento de lenguajes (como en Java) o puede
implicar herramientas CASE para apoyar la construcción del sistema.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 122
COCOMO Constructive Cost modeling. Quizás el modelo algorítmico de estimación de costos más conocido.
Control de calidad (QC)
Proceso de asegurar que el equipo de desarrollo de software sigue los estándares de calidad.
Desarrollo del software orientado a aspectos Enfoque para el desarrollo de software que combina el desarrollo generativo y el basado en
componentes. Se identifican los intereses compartidos en un programa y la implementación de
estos intereses se define como aspectos. Un programa se encarga entonces de entrelazar los
aspectos en los lugares apropiados en el programa.
Desarrollo incremental Enfoque para el desarrollo de software en el que éste se entrega y utiliza en incrementos.
Desarrollo iterativo
Enfoque para el desarrollo de software en el que se entrelazan los procesos de especificación,
diseño, programación y pruebas.
Desarrollo orientado a objetos (OO)
Enfoque para el desarrollo de software en el que las abstracciones fundamentales en el sistema
son objetos independientes. Se utiliza el mismo tipo de abstracciones durante la
especificación, diseño y desarrollo.
Diagrama de secuencia Diagrama que muestra la secuencia de interacciones necesarias para completar alguna
operación. En UML, los diagramas de secuencia se pueden asociar con los casos de uso.
Diseño de la interfaz de usuario Proceso de diseñar el modo en el que los usuarios del sistema acceden a la funcionalidad del
sistema y la forma en la que se visualiza la información producida por el.
Disponibilidad Preparación de un sistema para entregar servicios cuando se le soliciten. La disponibilidad es
normalmente expresada como un número decimal así una disponibilidad de 0.999 significa
que el sistema puede entregar servicios durante 999 de cada 1000 unidades tiempo.
Dominio Problema o área de negocio específico donde son utilizados los sistemas software. Ejemplos
de dominios son el control en tiempo real, el procesamiento de datos de negocio y la
conmutación telecomunicaciones.
Elemento de configuración
Unidad legible por la máquina, como un documento o un archivo de código fuente, que es
susceptible de cambiar y donde los cambios tienen que se controlados por un sistema de
gestión de configuración.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 123
EJB (Enterprise Java Beans)
Modelo de componentes basado en Java.
Escenario Descripción de una forma típica en el cual un sistema es usado o un usuarios carried out
alguna actividad.
Especificación formal, algebraica
Método de especificación matemática de sistemas en el que un sistema o componente se
especifica definiendo las relaciones entre las operaciones definidas en sus interfaces externas.
Especificación formal, basada en modelos
Método de especificación matemática de sistemas en el que un sistema o componente se
especifica definiendo las pre-condiciones, post-condiciones e invariantes que se aplican al
estado sistema.
Etnografía Técnica basada en la observación que puede ser utilizada en la obtención y análisis de
requisitos. El etnógrafo se sumerge en el entorno del usuario y observa sus hábitos de trabajo
cotidianos. A partir de estas observaciones se pueden deducir requisitos para apoyo al
software.
Familia de aplicaciones Conjunto de programas de aplicaciones software que tienen una arquitectura común y una
funcionalidad genérica. Éstos se pueden adaptar a las necesidades específicas de los clientes
modificando componentes y parámetros de los programas.
Fiabilidad Capacidad de un sistema para entregar los servicios como se especifican. La fiabilidad puede
especificar cuantitativamente como la probabilidad de que ocurra un fallo de funcionamiento
o como la tasa de ocurrencia de éstos.
Generador de programas
Programa que genera otro programa a partir de una especificación abstracta de alto nivel. El
generador incorpora conocimientos que es reutilizan en cada actividad de generación.
Gestión de configuración
Proceso de gestionar los cambios a un producto software que se desarrolla. La gestión de la
configuración implica la planificación de la configuración, la gestión de versiones, la
construcción del sistema y la gestión de cambio.
Gestión de requisitos
Proceso de gestión de cambios de requisitos para asegurar que los cambios efectuados son
correctamente analizados e implementados en el sistema.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 124
Gestión de riesgos
Proceso de identificar los riesgos, evaluar su gravedad, planificar las medidas a adoptar si se
presenta el riesgo y supervisar el software y los procesos de software para los riesgos.
Herramientas CASE
Herramienta software, así como un editor de diseño o un depurador de programa, utilizada
para apoyar una actividad en el proceso de desarrollo de software.
Ingeniería de sistemas Proceso que trata de la especificación de un sistema, la integración de sus componentes y
pruebas de que el sistema cumple sus requisitos. La ingeniería sistemas no solo trata el
sistema software, sino el sistema socio-técnico completo: software, hardware y procesos
operativos.
Inspección de programa
Proceso de verificación en el que un grupo de revisores examina un programa, línea por línea,
con el objetivo de detectar errores de programa.
Interfaz
Especificación de los atributos y operaciones asociados con un componente software. La
interfaz es utilizada como el medio de tener acceso a la funcionalidad del componente.
Interfaz de Programación de Aplicaciones (API) Interface, generalmente especializada como un conjunto de operaciones, definida por un
programa de aplicación que permite acceder a la funcionalidad del programa. Esto significa
que no sólo se puede acceder a esta funcionalidad a través de la interfaz de usuario, sino que
otros programas pueden utilizarla directamente.
ISO 9000
Estándar para los procesos de gestión de calidad definido por la Organización Internacional de
Normalización (ISO).
Java Lenguaje de programación orientado a objetos que fue diseñado por Sun con el objetivo de la
independencia de la plataforma.
Mantenimiento Proceso de hacer cambios en un sistema después de que esté en funcionamiento.
Marco de trabajo de aplicaciones
Estructura genérica en algún dominio específico que puede formar la base de una familia de
aplicaciones. Los marcos de trabajo de aplicaciones generalmente se implementan como un
conjunto de clases concretas y abstractas especializadas e instanciadas para crear una
aplicación.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 125
Mejora de proceso
Proceso de hacer cambios a un proceso con el objetivo de hacerlo más previsible o mejorar la
calidad de sus salidas. Por ejemplo, si su objetivo es reducir el número de defectos en el
software entregado, podría mejorar el proceso añadiendo nuevas actividades de validación..
Método estructurado
Método de diseño de software que define los modelos del sistema que se deben desarrollar, las
reglas y pautas que se deben aplicar a estos modelos y un proceso a seguir en el desarrollo del
diseño.
Métodos ágiles
Métodos de desarrollo de software dirigidos a la entrega rápida del mismo. El software se
desarrolla y entrega en incrementos, y se minimiza el proceso de documentación y la
burocracia.
Métodos formales Métodos de desarrollo de software basados en enfoques matemáticamente rigurosos que
modelan el software utilizando construcciones matemáticas formales como predicados y
conjuntos.
Métrica software Atributo de un sistema software o proceso que puede medir o expresar numéricamente. Las
métricas de procesos son atributos del proceso como el tiempo necesario para completar uan
tarea; las métricas de productos son atributos del software mismo como el tamaño o
complejidad.
Modelo de componentes CORBA Modelo de componentes diseñado por su uso para plataformas CORBA.
Modelo de componentes Conjunto de estándares para la implementación, documentación y utilización de componentes.
Éstos cubren las interfaces específicas que pueden ser proporcionadas por un componente, el
nombrado de componentes, la interoperavidad de los componentes y composición de éstos.
Los modelos de componente proporcionan la base para middleware para soportar la operación
de componentes.
Modelo de madurez de proceso Modelo del grado en el que un proceso incluye buenas prácticas y capacidades de medida y
reflexivas que están orientadas a la mejora de procesos.
Modelo de objetos Modelo de un sistema software que se estructura y organiza como un conjunto de clases
objetos y las relaciones entre estas clases. Pueden existir varias perspectivas diferentes en el
modelo, como una perspectiva del estado y una perspectiva de la secuencia.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 126
Modelo de procesos Representación abstracta de un proceso. Los modelos de procesos pueden ser representados
desde diferentes perspectivas y mostrar las actividades implicadas en un proceso, los objetos
utilizados en el proceso, las restricciones que se aplican al proceso y los roles de las personas
involucradas en el proceso.
Modelo del análisis
Modelo objeto que sirve como una abstracción del modelo de diseño, proporciona la
definición inicial de la realización de los casos de uso.
Modelo del dominio Definición de abstracciones del dominio como políticas, procedimientos, objetos, relaciones y
eventos. Sirve de base de conocimiento sobre alguna área del problema.
Modelo en cascada
Modelo del proceso del software en el que existen etapas de desarrollo: especificación, diseño,
implementación, pruebas y mantenimiento. En principio, se debe completar una etapa antes de
que se pueda avanzar a la siguiente. En la práctica, existe iteración entre las etapas.
Modelo espiral Modelo de un proceso de desarrollo donde el proceso se representa como una espiral en que
cada vuelta de la espiral incorpora las diferentes etapas en el proceso. Si se pasa de una vuelta
de la espiral a otra, se repiten todas las etapas del proceso.
OCL (Object Constraint Language)
Lenguaje que forma parte de UML utilizado para definir predicados que se aplican a las clases
de objetos e interacciones en un modelo UML.
OMG (The Object Management Group)
Grupo de compañías formado para desarrollar estándares para el desarrollo orientado a
objetos. Ejemplos de estándares promovidos por OMG son CORBA, UML y MDA.
Patrón de diseño Solución probada a un problema común que capta las experiencias y buenas prácticas de una
forma que puede ser reutilizada. Es una representación abstracta que se puede instanciar de
varias formas.
Plan de calidad Plan que define los procesos y procedimientos de calidad que se deben utilizar. Implica
seleccionar e instanciar estándares para productos y procesos y definir los atributos de la
calidad requeridos del sistema.
Principios de diseño de interfaz de usuario Conjunto de principios que expresan buenas prácticas para el diseño de interfaz de usuario.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 127
Proceso de negocio
Conjunto de actividades relacionadas con el uso de recursos de la organización para
proporcionar resultados definidos en apoyo de los objetivos de la organización. RUP define
proceso de negocio utilizando casos de uso de negocio que muestran el comportamiento
esperado de la empresa y las realizaciones de los casos de uso de negocio que muestra cómo
es el comportamiento de los trabajadores de las empresas y entidades empresariales.
Proceso del software
Conjunto relacionado de actividades y procesos implicados en el desarrollo y evolución de un
sistema software.
Programación extrema Método ágil de desarrollo de software que incluye prácticas como los requisitos basados en
escenarios, el desarrollo previamente probado y la programación en parejas.
Propiedad emergente Propiedad que solo se hace evidente una vez que se han integrado todos los componentes del
sistema para crearlo.
RAD (Rapid aplication development)
Enfoque para desarrollo de software dirigido a la entrega rápida de éste. A menudo implica el
uso de la programación de bases de datos y herramientas de apoyo al desarrollo como los
generadores de informes y pantallas.
Regla de negocio
Declaración de la política o condición que debe cumplirse dentro de la empresa. Las reglas de
negocio pueden ser capturadas en los modelos, en los documentos o ambos.
Reingeniería
Modificación de un sistema software para hacerlo más fácil de comprender y cambiar. La
reingeniería a menudo implica reestructuración y organización de datos y software, la
simplificación de programas y re-documentación.
Reingeniería, proceso de negocio
Cambio de un proceso de negocio para cumplir algún objetivo organizacional nuevo como la
reducción de costos y la ejecución más rápida.
Release Versión de un sistema software que está disponible para clientes del sistema.
Requisito funcional
Declaración de alguna función o característica que se debe implementar en un sistema.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 128
Requisito no funcional
Declaración de una restricción o comportamiento esperado que se aplica a un sistema. Esta
restricción puede referir a las propiedades emergentes del software que se está desarrollando o
al proceso de desarrollo.
Riesgo
Resultado indeseable que supone una amenaza para conseguir algún objetivo. Un riesgo del
proceso amenaza la agenda o costo de un proceso, un riesgo del producto es un riesgo que
puede significar que no se consigan algunos de los requisitos del sistema.
RUP (Rational Unified Process)
Modelo de proceso de software genérico que presenta el desarrollo del software como una
actividad iterativa de cuatro fases que son: inicio, elaboración, construcción y transición. La
fase de inicio establece un caso de negocio para el sistema, la fase de elaboración define la
arquitectura, la de construcción implementa el sistema y la de transición utiliza el sistema en
el entorno del cliente.
Seguridad Capacidad de un sistema para funcionar sin fallos de funcionamiento catastróficos.
Servicio Web Componente software independiente al que se puede acceder a través de Internet utilizando
protocolos estándares. SOAP (Simple Object Access Protocol) se utiliza para el intercambio
de información en servicios web. WSDL (Web Service Definition Language) se utiliza para
definir las interfaces de servicio web.
Servidor Programa que proporciona algún servicio a otros programas (cliente).
Sistema crítico
Sistema informático cuyo fallo de funcionamiento puede causar importantes pérdidas
económicas, humanas o medioambientales.
Sistema objetos distribuido Sistema distribuido en el que los componentes ejecutables son objetos.
Sistema de tiempo real
Sistema que tiene que responder a eventos externos y procesarlos en “tiempo real”. La
corrección del sistema no sólo depende de lo que hace sino también de la velocidad con que lo
hace. Los sistemas de tiempo real normalmente se organizan como un conjunto de procesos
concurrentes que cooperan entre sí.
Sistema de procesamiento de datos
Sistema cuyo propósito es procesar grandes cantidades de datos estructurados. Estos sistemas
normalmente procesan los datos por lotes y siguen un modelo de entrada-proceso-salida.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 129
Ejemplos de sistemas de procesamiento de datos son los sistemas de cuentas y facturas, y los
sistemas de pago.
Sistema de procesamiento de lenguajes Sistema que traslada un lenguaje a otro. Por ejemplo, un compilador es un sistema de
procesamiento de lenguaje que traslada código fuente de un programa a código objeto.
Sistema de procesamiento de transacciones Sistema que asegura que las transacciones se procesan de tal forma que no se interfieren entre
sí y de modo que el fallo de una transacción individual no afecte a otras transacciones o a los
dataos del sistema.
Sistema distribuido Sistema software en el que los subsistemas o componentes software se ejecutan en diferentes
procesadores.
Sistema heredado Sistema socio-técnico que es útil o fundamental para una organización, pero que ha sido
desarrollado utilizando tecnología o métodos obsoletos. Debido a que los sistemas heredados a
menudo llevan a cabo funciones de negocio críticas, tienen que ser mantenidos.
Sistema socio-técnico Sistema que incluye componentes hardware y software, que ha definido los procesos
operativos seguidos por los operadores humanos y que funciona dentro de una organización.
Por lo tanto, está influido por las políticas, procedimientos y estructuras de la organización.
SQL (Structured Query Language)
Lenguaje estándar utilizado para la programación de bases de datos relacionales.
Tipo abstracto de datos Tipo cuya representación se oculta y está definido por sus operaciones.
Transacción Unidad de interacción con un sistema informático. Las transacciones son independientes y
atómicos (no se pueden dividir en unidades más pequeñas) y son una unidad fundamental de
recuperación, consistencia y concurrencia.
UML (Unified Modeling Language)
Lenguaje gráfico utilizado en el desarrollo orientado a objetos que incluye varios tipos de
modelos del sistema que proporciona distintas vistas de un sistema. UML se ha convertido en
un estándar de facto para el modelado orientado a objetos.
Validación Proceso de verificar que un sistema cumple las necesidades y expectativas del cliente.
Verificación
El proceso de verifica que un sistema cumple su especificación.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 130
Vista arquitectural
Vista de la arquitectura del sistema desde una perspectiva determinada. Se centra
principalmente en la estructura, la modularidad, los componentes esenciales y el flujo de
control principal.
XML (Extende Markup Language)
XML es un lenguaje de marcado de texto que soporta el intercambio de datos estructurados.
Cada campo de datos se delimita por etiquetas que proporcionan información sobre ese
campo. XML se utiliza ampliamente en la actualidad y se ha convertido en la base de los
protocolos para los servicios web.
Z
Lenguaje de especificación formal basado en modelos desarrollado en la Universidad de
Oxford en Inglaterra.
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 131
Referencias
[AMB00] AMBLER, S.W. & JEFFRIES, R.
AGILE MODELING(AM) HOME PAGE EFFECTIVE PRACTICES FOR
MODELING AND DOCUMENTATION. http://www.agilemodeling.com/
[AMB02] AMBLER, S.W. & JEFFRIES, R.
AGILE MODELING.
New York. John Wiley & Sons. 2002.
[BEC00] BECK, K
EXTREME PROGRAMMING EXPLAINED.
Boston. Addison Wesley. 2000.
[BOE81] BOEHM, B.W
SOFTWARE ENGINEERING ECONOMICS
Englewood Cliffs, NJ: Prentice Hall. 1981.
[BOO99] BOOCH, G. RUMBAUGH, JACOBSON
THE UNIFIED MODELING LANGUAGE USER GUIDE.
Addison-Wesley. 1999.
[CS04] COMPUTER SOCIETY
Guide to the Software Engineering Body of Knowledge SWEBOK. 2004.
[HUM95] HUMPHREY, W.S.
A DISCIPLINE FOR SOFTWARE ENGINEERING.
Addison-Wesley. 1995.
[JAC97] JACOBSON, IVAR
OBJECT ORIENTED SOFTWARE ENGINEERING
ACM Press Addison-Wesley. 1997.
[JAC99] JACOBSON I., BOOCH G., RUMBAUGH J.
EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE.
La guía completa del Proceso Unificado escrita por sus creadores.
Addison Wesley. 1999.
[PCM04] PRESIDENCIA DEL CONSEJO DE MINISTROS (PCM)
NTP ISO/IEC 12207 TECNOLOGIA DE LA INFORMACION
Manual de Ingeniería de Software
Lic. María Elena Chávez Barcés Página 132
Procesos del Ciclo de Vida del Software. 2004.
[PRE02] PRESSMAN, Roger
INGENIERÍA DE SOFTWARE: UN ENFOQUE PRÁCTICO. Quinta Edición,
McGrawHill Companies. 2002.
[RUP00] RUP
RATIONAL UNIFIED PROCESS.
[SEI00] SEI – SOFTWARE ENGINEERING INSTITUE – CARNEGIE MELLON
CAPABILITY MATURITY MODEL INTEGRATION (CMMI)
Versión 1.1 CMMI for Software Engineering.
[SCO04] SCOTT, McEWEN
REQUIREMENTS: AN INTRODUCTION. Metasys Technologies Inc. 2004.
[SOM05] SOMMERVILLE, Ian
INGENIERIA DEL SOFTWARE.
7a. Edición. Pearson Addison Wesley. 2005.