Manual de Ingeniería de Software

Facultad de Ingeniería

Lic. María Elena Chávez Barcés 2012

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.



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



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



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.



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.



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:



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.



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.



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:



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



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



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.



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.



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.



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



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



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.



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.



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).



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.



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



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.



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.




“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



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



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



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.



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.



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.



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.



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.



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.



El software no satisface los requisitos establecidos



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



(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



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



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:



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.



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



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.



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



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



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.



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.



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.



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.



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.



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.



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.



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.



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



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.



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.



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.



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



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



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



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.



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.



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



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



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.



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.

http://es.wikipedia.org/wiki/Interfaz



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.



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.



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



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



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



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.



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



una cantidad significativa de esfuerzo y tiempo para crear un banco de trabajo de pruebas

adecuado.



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.



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.



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.



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



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.



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.



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.



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.



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.



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.



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.



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



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.



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.



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



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.



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.



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



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



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.



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.



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



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.



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).



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



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.



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.



¿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



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



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.



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



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.



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".



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.



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.



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.



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



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.



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.


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



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.



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:



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.



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



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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

http://www.agilemodeling.com/



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.

Manual de Ingeniería de Software

Documents

Transcript of Manual de Ingeniería de Software