Manual de Ingeniería de Software

Facultad de
Ingeniera

Lic. Mara Elena Chvez Barcs

2012

Manual de Ingeniera de Software

Lic. Mara Elena Chvez Barcs Pgina 2

INTRODUCCIN

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, mdicos, entretenimiento, productos de
oficina, la lista es casi interminable.
Para tener xito al disear y construir software necesitamos de una disciplina; es decir, aplicar
un enfoque ingenieril. Ingeniera 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 ms
disciplinado del software, continan debatiendo sobre la manera cmo se va a aplicar esta
disciplina. La comunidad del software trata continuamente de desarrollar tecnologas que
hagan ms sencillo, rpido y menos costosa la construccin de programas de computadora de
alta calidad. Se han cambiado las actividades y se ha progresado, pero todava 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 ingeniera de software en las currculas de las
carreras informticas de las universidades del mundo.
El contenido del presente manual de la asignatura de Ingeniera de Software (IS) incluye para
este perodo acadmico temas como: Introduccin a la ingeniera de software presentando
conceptos ms importantes; Procesos y mtodos convencionales para la ingeniera de
software, mostrando mtodos clsicos de anlisis, diseo y pruebas del software, Ingeniera de
Requisitos, procesos, tcnicas y documentacin asociados. Ingeniera de software orientada a
objeto, con los mtodos orientados a objetos a lo largo de todo el proceso de software. Diseo
de software y sus procesos, arquitectura del software, diseo orientado a objetos y diseo de
interfaz de usuario. Implementacin, reutilizacin, CBSE. Evolucin y mantenimiento.
Verificacin y validacin, pruebas del software, inspecciones. Gestin de proyectos de
software, planificando, gestionando y controlar un proyecto de desarrollo de software.
Calidad del software, gestin de la calidad, procesos de mejora. Temas avanzados en
ingeniera de software, ingeniera de software basada en componentes, ingeniera de software
cliente/servidor, ingeniera Web, reutilizacin de software y herramientas CASE.
Es decir, introduce una gran cantidad de temas, nuevas tendencias, herramientas y
metodologas que plantea la ingeniera de software actual y futura.



INDICE

INTRODUCCIN A LA INGENIERA DE SOFTWARE
1. Introduccin
2. El producto software
3. Evolucin del software
4. Principios de la Ingeniera del Software
PROCESOS DEL SOFTWARE
1. El proceso del software
2. Modelos de proceso de software genricos
3. Mtodos de desarrollo de software
4. Proceso Unificado Rational (RUP)
5. Procesos de desarrollo giles
REQUISITOS DE SOFTWARE
1. Requisitos funcionales y no funcionales
2. Ingeniera de requisitos
MODELADO DEL SISTEMA
DISEO DEL SOFTWARE
1. Conceptos y principios de diseo.
2. El proceso de diseo de software
3. Diseo arquitectnico
4. Diseo de la interfaz de usuario
5. Diseo orientado a objetos
DESARROLLO DEL SOFTWARE
1. Desarrollo rpido de software
2. Mtodos giles de desarrollo
3. Reutilizacin del software
4. Ingeniera de software basado en componentes
PRUEBAS DEL SOFTWARE
1. Fundamentos de las pruebas
2. Niveles de pruebas
3. Tcnicas de pruebas
4. Proceso de pruebas


5. Diseo de casos de prueba
6. Automatizacin de pruebas
EVOLUCION DEL SOFTWARE
1. Mantenimientos del software
2. Procesos de evolucin
GESTION DE CONFIGURACION
1. Planificacin de la gestin de configuracin
2. Gestin de cambios
3. Gestin de versiones y entregas
4. Herramientas CASE para gestin de configuracin
GESTION DE PROYECTOS DE SOFTWARE
1. Actividades de la gestin de proyectos
2. Planificacin del proyecto de software
3. Organizacin del proyecto
4. Anlisis de riesgos
CALIDAD DEL SOFTWARE
1. Calidad del producto
2. Calidad del proceso
3. Planificacin de la calidad
4. Control de la calidad
5. Mejora de procesos
6. Procesos CMMI


INTRODUCCIN A LA
INGENIERIA DEL SOFTWARE

1. INTRODUCCIN.
En los ltimos aos los cambios en el hardware han sido notables, y podra 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 construccin de software se
mezclan muchas tecnologas (J2EE, .NET, EJB, SAP, SOAP, SBSE..) desarrollndose
aplicaciones muchas ms rpidas.
Los nuevos mtodos y tcnicas de ingeniera de software han mejorado la construccin de
sistemas grandes y complejos, pero an, 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
educacin en ingeniera de software.
En los ltimos aos el desarrollo ms significativo en ingeniera de software ha sido la
aparicin del estndar UML para la descripcin de sistemas orientados a objetos, y el
desarrollo de mtodos giles.
2. EL PRODUCTO SOFTWARE.
Cuando se construye hardware, el proceso creativo humano (anlisis, diseo,
construccin, prueba) se traduce finalmente en una forma fsica (chips, tarjetas de circuitos
impresos, fuentes de potencia, etc.). El software es un elemento del sistema que es lgico, en
lugar de fsico. Por tanto el software tiene caractersticas considerablemente distintas a las del
hardware.
En ambas actividades la buena calidad se adquiere mediante un buen diseo. Ambas
actividades dependen de personas, pero la relacin entre las personas dedicadas y el trabajo
realizado es completamente diferente para el software. Ambas actividades requieren la
construccin de un producto pero los enfoques son diferentes. Esto significa que los
proyectos de software no se pueden gestionar como si fueran proyectos de fabricacin.
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 configuracin que se
utilizan para ejecutar estos programas, un sistema de documentacin que describe la
estructura del sistema y la documentacin para el usuario que explica cmo 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 perifricos, procesadores de
telecomunicaciones. El software de sistemas se caracteriza por una fuerte interaccin
con el hardware de la computadora; utilizacin por mltiples usuarios; operacin
concurrente que requiere planificacin, comparticin de recursos y una sofisticada
gestin de procesos; unas estructuras de datos complejas y mltiples interfaces
externas.
Software de tiempo real. Software que coordina, analiza, controla sucesos del mundo
real conforme ocurren. Ejemplo: un componente de anlisis que transforma la
informacin segn lo requiera la aplicacin, un componente de monitorizacin que
coordina todos los dems componentes, de forma que pueda mantenerse la respuesta
en tiempo real.
Software de gestin. Los sistemas (nminas, cuentas de haberes, dbitos, inventarios,
etc.) han evolucionado hacia el software de sistemas de informacin de gestin (SIG),
reestructuran los datos existentes para facilitar las operaciones comerciales o gestionar
la toma de decisiones.
Software de ingeniera y cientfico. Estas aplicaciones van desde la astronoma a la
vulcanologa, desde el anlisis de la presin de los automotores a la dinmica orbital
de las lanzaderas espaciales y desde la biologa molecular a la fabricacin automtica.
El diseo asistido por computadora (del ingls CAD), la simulacin de sistemas y otras
aplicaciones interactivas, han comenzado a coger caractersticas del software de
tiempo real e incluso del software de sistemas.
Software empotrado. El software empotrado reside en memoria de slo 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 funcin significativa y con
capacidad de control (por ejemplo: funciones digitales en un automvil, tales como
control de la gasolina, etc.).
Software de computadoras personales. El procesamiento de textos, las hojas de
clculo, los grficos por computadora, multimedia, entretenimientos, gestin 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 pginas 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 numricos para
resolver problemas complejos. Los sistemas expertos, tambin llamados sistemas
basados en el conocimiento, reconocimiento de patrones (imgenes y voz), redes
neuronales artificiales, prueba de teoremas, y los juegos son aplicaciones de esta
categora.


El producto software tiene un nmero de atributos asociados que reflejan su calidad. Estos
atributos no estn asociados con lo que hace el software. Ms bien, reflejan su
comportamiento durante su ejecucin, la estructura y organizacin del cdigo fuente o puede
reflejarse en la documentacin asociada.
Ejemplo: Tiempo de respuesta del software a una consulta del usuario
Comprensin del programa fuente
Los atributos que se esperan de un sistema dependen de su aplicacin. Ejemplos, un sistema
bancario se debe esperar que sea seguro, un juego interactivo debe tener capacidad de
respuesta, un interruptor de un sistema telefnico 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 crtico
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 nmero de caractersticas:
fiabilidad, proteccin y seguridad. El software confiable no debe causar daos 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, utilizacin de la memoria, etc.
Usabilidad. El software debe ser fcil de usar por el usuario para quien est diseado.
Esto significa que debe tener una interfaz de usuario apropiada y una documentacin
adecuada.
3. EVOLUCIN DEL SOFTWARE.
Etapa 1: 1950 1965
o Esfuerzo en el desarrollo de Hardware
o Carencia de mtodos de desarrollo
o Software a la medida con baja distribucin
Etapa 2: 1965 1976
o Masificacin de software en empresas
o Software de gran extensin
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 Popularizacin 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 bsqueda binaria.
En 1966, C.Bohm y G.Jacopini publicaron el documento que creaba una fundacin
para la eliminacin de go to y la creacin de la programacin estructurada.
En 1968, los programadores se debatan entre el uso de la sentencia GoTo, y la nueva
idea de programacin estructurada, ese era el caldo de cultivo en que Edsger Dijkstra
escribi su famosa carta GoTo Statement Considered Huarmful.
La primera publicacin sobre programacin estructurada no vio la luz hasta 1974,
publicada por Larry Constantine, Glenford Myers y Wayne Stevens.
En 1977, el primer libro sobre mtrica de software por Tom Gilb.
En 1979, el primer libro sobre anlisis de requisitos.
Libros publicados durante los aos 70 y 80 proporcionan una visin histrica til dentro de la
percepcin cambiante de las computadoras y del software, y de su impacto en nuestra cultura.
Enormes mejoras en rendimiento del hardware, profundos cambios de arquitecturas
informticas, grandes incrementos de memoria y capacidad de almacenamiento y una gran
variedad de opciones de entrada y salida han conducido a sistemas ms sofisticados y ms
complejos basados en computadora. El software ha sufrido cambios significativos durante un
periodo de tiempo superior a los 50 aos.
La sofisticacin y la complejidad del software pueden producir resultados deslumbrantes
cuando un sistema tiene xito, pero tambin pueden suponer grandes problemas para aquellos
que deben construir dichos sistemas.
Es decir, sin software complejo no habramos explorado el espacio, no tendramos Internet y
telecomunicaciones modernas y todas las formas de viajar seran ms peligrosas y caras. Hoy
en da, la computacin omnipresente ha producido una generacin de aplicaciones de
informacin que tienen conexin en banda ancha a la Web para proporcionar una capa de
conexin sobre nuestras casas, oficinas, y autopistas. El papel del software contina su
expansin.
CRISIS DEL SOFTWARE
En 1968, la OTAN (Organizacin del Tratado del Atlntico 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
trmino ingeniera de software para describir el conjunto de conocimientos que exista 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 ingeniera de software como una profesin. Las
races de la crisis del software son complejas y variables.
Algunos sntomas que indican que el software se encuentra en un perodo de crisis son:
Tiempo y presupuesto excedido.
El software a menudo no satisfaca los requisitos deseados.


Baja calidad del software.
Confiabilidad cuestionable.
Proyectos inmanejables, con cdigo difcil 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 crticos han
destacado ciertas caractersticas que han permitido esta postura del software respecto a otras
etapas de su corta historia. Algunos de estos factores son:
Aumento del poder computacional
Reduccin del costo del hardware.
Rpida obsolescencia de hardware y software.
Aceptacin de la computarizacin en las empresas.
Incremento en el nmero de usuarios de los sistemas de software.
Tipo de usuario no homogneo aun en sistemas hechos a medida.
Personal diferente para el desarrollo y el mantenimiento.
No existen todava herramientas que permitan estimar de una manera exacta, antes de
comenzar el proyecto, cul es el esfuerzo que se necesitar para desarrollar un programa. Este
hecho provoca que la mayora de las veces no sea posible estimar cunto tiempo llevar el
proyecto, ni cunto personal ser necesario.
CASOS DE ESTUDIO
Caso de Estudio: F-18 (1986)
En abril de 1986 un avin de combate F-18 se estrell por culpa de un giro descontrolado,
atribuido a una expresin if-then, para la cual no haba una expresin else, por
considerarse innecesaria, lo que origin una excepcin fuera de control del programa. Por
suerte el piloto pudo salir del avin a tiempo.
Caso de estudio: Therac-25
Diseado 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 mquina a un estado interno errneo y
muy peligroso generando una sobredosis masiva de radiacin al paciente. No se hacan
revisiones sobre prcticas de desarrollo de software, ni control de calidad del software en
dispositivos mdicos
Caso de Estudio: Sistema AEGIS (1988)
El 3 de julio de 1988, en el golfo prsico, el USS Vincennes derrib un jet de pasajeros iran
que confundi con una aeronave iran hostil. El capitn 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 grfico demuestra el resultado de 30,000 proyectos de desarrollo de aplicaciones en
empresas de todo tamao en Estados Unidos medido por The Standish Group desde 1994.
MITOS DEL SOFTWARE
MITOS DE GESTIN:
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 mtodos no sirven
Lo nico importante es el cdigo
El proyecto termina con el desarrollo del software (y la documentacin y el
mantenimiento qu?)

4. PRINCIPIOS DE LA INGENIERA DEL SOFTWARE.
La nocin de ingeniera 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 tenan aos de retraso, costaban ms de lo presupuestado,
irrealizables, difciles de mantener y con un pobre desempeo. El desarrollo de software
estaba en crisis. Se necesitaban nuevas tcnicas y mtodos para controlar la complejidad
inherente a los sistemas grandes. Estas tcnicas han llegado a ser parte de la ingeniera del
software y son ampliamente utilizadas. Veamos algunas definiciones:



Ingeniera del Software trata del establecimiento de los principios y
mtodos de la ingeniera a fin de obtener software de modo rentable que sea
fiable y trabaje en mquinas reales.
(Bauer, 1971).

Ingeniera del Software es la aplicacin prctica del conocimiento cientfico
en el diseo y construccin de programas de computadora y la
documentacin asociada requerida para desarrollar, operar y mantenerlos.
Se conoce tambin como desarrollo de software o produccin de software
(Bohem, 1976).

La Ingeniera de Software es la aplicacin de un enfoque sistemtico,
disciplinado y cuantificable al desarrollo, operacin y mantenimiento del
software (I EEE, 1993).
La Ingeniera de Software es una disciplina de la ingeniera que comprende todos los
aspectos de la produccin de software de calidad. Involucra actividades como gestin de
proyectos de software, procesos tcnicos de desarrollo de software, herramientas, mtodos y
teoras de apoyo; tiene un enfoque sistemtico, organizado y ms efectivo.
Ingeniera consiste en seleccionar el mtodo ms apropiado para un conjunto de
circunstancias. Ejemplo, un enfoque de desarrollo apropiado para el desarrollo de sistemas
basados en Web requerir una mezcla de tcnicas de software y de diseo grfico. 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
ingeniera de software ha mejorado considerablemente el software. Comprendemos mucho
mejor de las actividades involucradas en el desarrollo de software. Se han desarrollado
mtodos efectivos de anlisis, especificacin, diseo, desarrollo, pruebas y mantenimiento del
software. Las nuevas notaciones y herramientas reducen el esfuerzo requerido para producir
sistemas grandes y complejos.

Capas de la Ingeniera de Software



La ingeniera de sistemas es ms antigua que la ingeniera del software, se refiere a todos los
aspectos del desarrollo y de la evolucin de sistemas complejos donde el software desempea
un papel principal. La ingeniera de sistemas comprende el desarrollo de hardware, polticas y
procesos de diseo y distribucin de sistemas, as como la ingeniera de software.

Disciplinas involucradas en la Ingeniera de Sistemas

RETOS FUNDAMENTALES QUE AFRONTA LA INGENIERIA DEL SOFTWARE
En el siglo XXI, la ingeniera del software afronta tres retos fundamentales:
1. El reto de la heterogeneidad. Desarrollar tcnicas para construir software confiable,
flexible que integren software nuevo con sistemas heredados escritos en diferentes
lenguajes de programacin, 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 travs de pginas Web o de interfaces de
servicios Web. El reto de la confianza es desarrollar tcnicas que demuestren que los
usuarios pueden confiar en el software.
Estos retos no son independientes, por ejemplo, es necesario hacer rpidos cambios en
sistemas heredados para proveerlos en una interfaz de servicio Web. Para tratar estos retos
necesitaremos nuevas herramientas y tcnicas, as como formas innovadoras de combinacin
y uso de mtodos de ingeniera del software existentes.
RESPONSABILIDAD PROFESIONAL Y ETICA
La ingeniera 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 ms amplias que simplemente la aplicacin de habilidades tcnicas. Deben


comportarse de una forma tica y moral responsable si es que desean ser respetados como
profesionales.
Estndares 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 estn 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 mquina de un empleado, por
ejemplo) hasta los extremadamente serios (difusin de virus).
Organizaciones como la ACM (Association for Computing Machinery), IEEE (Instituto de
Ingenieros Elctricos y Electrnicos) y la British Computer Society han publicado un cdigo
de conducta profesional o de tica. Este cdigo de conducta generalmente se refiere al
comportamiento tico fundamental.
Los ingenieros de software deben comprometerse consigo mismos para hacer del anlisis, la
especificacin, el diseo, el desarrollo, las pruebas y el mantenimiento del software una
profesin beneficiosa y respetada. En concordancia con su compromiso con la salud, la
seguridad y el bienestar del pblico, los ingenieros de software deben adherirse a los
siguientes ocho principios:
1. PBLICO Los ingenieros debern actuar en consonancia con el inters pblico.
2. CLIENTE Y EMPLEADOR Los ingenieros de software debern actuar de forma que
respondan a los intereses de sus clientes y empleadores siendo consecuentes con el
inters pblico.
3. PRODUCTO Los ingenieros de software debern asegurar que sus productos y las
modificaciones asociadas cumplan los ms altos estndares profesionales posibles.
4. JUICIO Los ingenieros de software debern mantener la integridad e independencia en
sus juicios profesionales.
5. GESTION Los gerentes y lderes ingenieros de software debern suscribir y
promocionar un enfoque tico en la gestin del desarrollo y mantenimiento del software.
6. PROFESIN Los ingenieros de software debern mantener la integridad y reputacin
de la profesin de acuerdo con el inters pblico.
7. COLEGAS Los ingenieros de software debern ser imparciales y apoyar a sus colegas.
8. PERSONAL Durante toda su existencia, los ingenieros de software debern aprender
lo concerniente a la prctica de su profesin y promocionar un enfoque tico en la
prctica de su profesin.



PROCESOS DEL SOFTWARE

1. EL PROCESO DEL SOFTWARE.
El proceso del software incluye todas las actividades que conducen a la creacin de
un producto software. Son parte del proceso del software, las actividades de alto nivel de
especificacin del software, el desarrollo, la validacin y la evolucin. Estas actividades
pueden consistir en el desarrollo de software desde cero en un lenguaje de programacin
estndar, 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 rpidamente cambiantes probablemente sea ms 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 organizacin. La estandarizacin es un
primer paso para introducir nuevos mtodos, tcnicas y buenas prcticas de ingeniera de
software.
La tecnologa CASE se utiliza para ayudar a las actividades del proceso del software

2. MODELOS DE PROCESO DE SOFTWARE GENRICOS.
Un modelo de proceso de software es una representacin 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 informacin parcial sobre este proceso.


Puede incluir actividades que son parte del proceso, productos de software y el papel de las
personas involucradas en la ingeniera 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 especificacin de requisitos, el diseo del software, la
implementacin, las pruebas, etc. Despus de que cada etapa queda definida el
desarrollo contina con la siguiente etapa. Las principales etapas:
Definicin de requisitos. Se extrae a detalle a travs de entrevistas a los usuarios los
requisitos del sistema.
Anlisis y Diseo del software. Se establece una arquitectura completa del sistema. El
diseo del software identifica y describe las abstracciones fundamentales del sistema
software y sus relaciones. El diseo del software se lleva a cabo como un conjunto de
unidades de programas.
Implementacin y prueba de unidades. La prueba de unidades implica verificar que cada
una cumpla su especificacin.
Integracin y pruebas del sistema. Las unidades se integran y se prueban como un
sistema completo para asegurar que se cumplan los requisitos del software.
Operacin y mantenimiento. El sistema se instala y se pone en funcionamiento. Se
efectan mejoras en la implementacin 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 documentacin se produce en
cada fase. Se hace compromisos en las etapas inciales lo que es difcil 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 especificacin,
desarrollo y validacin. Se desarrolla rpidamente un sistema inicial a partir de
especificaciones muy abstractas. Este se refina basndose 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 ms 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
especificacin se puede desarrollar por incrementos. Suele trabajar mejor en sistemas
pequeos y medianos de tamao.
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 caractersticas del modelo en cascada y del desarrollo evolutivo.

Desarrollo evolutivo
3. Ingeniera de software basada en componente (CBSE). Esta tcnica supone que
existan las partes del sistema. El proceso de desarrollo del sistema consiste en la
integracin de estas partes ms que desarrollarlas desde el principio. Este enfoque
basado en la reutilizacin se compone de una gran base de componentes software


reutilizable y de algunos marcos de trabajo de integracin de estos. Las siguientes etapas
son:

Ingeniera del software basada en componentes
Anlisis de componentes. Se buscan los componentes necesarios para proporcionar parte
de la funcionalidad requerida.
Modificacin de requisitos. Se analizan los requisitos y se modifican los componentes.
Si no se pueden modificar se buscan soluciones alternativas.
Diseo del sistema con reutilizacin. Se disea o se reutiliza un marco de trabajo para el
sistema que satisfaga los requisitos, sino se tendr que disear un nuevo software.
Desarrollo e integracin. Se desarrolla el software que no se pueda adquirir y se
integran los componentes, esta no es una actividad separada.
La ingeniera 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. Tambin
permite una entrega ms rpida del software.
La ingeniera del software basado en componentes tiene mucho en comn con un
enfoque que est surgiendo para el desarrollo de sistemas que se basa en la integracin
de servicios web de una serie de proveedores.
La distribucin de costos a travs 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 validacin y pruebas extensas que los sistemas basados en Web. Cada
uno de los enfoques de desarrollo de software tiene un perfil de distribucin de costos
diferente a travs de las actividades del proceso.
En el enfoque en cascada, los costos se miden en forma separada, es decir los costos de
especificacin, diseo, implementacin e integracin (notar que integracin y pruebas del
sistema son las actividades ms caras, alrededor del 40% del costo de desarrollo total).
Si el software se desarrolla utilizando un enfoque iterativo, la especificacin, el diseo, la
implementacin, la integracin y las pruebas se llevan en paralelo dentro de una actividad de
desarrollo. Una vez que la implementacin inicial est completa se necesita una actividad
independiente de pruebas del sistema.
La ingeniera de software basada en componentes ha sido utilizada durante un corto
perodo de tiempo. Los costos de desarrollo se reducen a costos de integracin y pruebas y


estos se incrementan porque tenemos que asegurarnos de que los componentes que utilizamos
cumplen realmente su especificacin y funcionan como se espera.
Adems existen costos asociados a cambios que se le hacen al software una vez que est en
uso.
Esta distribucin 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, comnmente se desarrollan a partir de una
especificacin inicial utilizando un enfoque de desarrollo evolutivo. Sin embargo, debido que
se pretende utilizar en diferentes configuraciones, deben ser probados a fondo.
ITERACIN DE PROCESOS
Los modelos de iteracin de procesos presentan el proceso de software como un ciclo de
actividades. La ventaja de este enfoque es que evita compromisos prematuros con una
especificacin o diseo. Ejemplos de este tipo de modelos son el desarrollo incremental y el
modelo en espiral.
Para hacer ms 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
ncleo fundamental est constituido por una o ms iteraciones de las actividades principales
bsicas de cualquier proceso de desarrollo.

Desarrollo iterativo

1. La entrega incremental. La especificacin, el diseo y la implementacin 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 ms
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 inciales como prototipo.
Existe un bajo riesgo de fallo del proyecto.
Se harn ms pruebas a los servicios importantes del sistema.
Sin embargo, existen algunos problemas en el desarrollo incremental. Los incrementos
deben ser relativamente pequeos 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 ms
interno podra referirse a la viabilidad del sistema, el siguiente ciclo a la definicin de
requisitos, el siguiente ciclo al diseo del sistema y as sucesivamente.
Cada ciclo de la espiral se divide en cuatro sectores:
Definicin de objetivos especficos. Se identifican las restricciones del proceso y el
producto y se traza un plan detallado de gestin. Se identifican los riesgos del proyecto.
Evolucin y reduccin de riesgos. Un anlisis detallado de los riesgos identificados del
proyecto. Pasos para reducir dichos riesgos.
Desarrollo y validacin. Despus de la evaluacin 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 podra ser la construccin de prototipos
evolutivos. El modelo en cascada puede ser el ms apropiado para el desarrollo si el
mayor riesgo identificado es la integracin de los subsistemas.


Planificacin. El proyecto se revisa y se toma la decisin de si se debe continuar con un
ciclo posterior de la espiral.
Un ciclo de la espiral empieza con la elaboracin 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 evala contra cada
objetivo y se identifican las fuentes de riesgo del proyecto.

Modelo en espiral
La esencia del proceso iterativo es que la especificacin se desarrolla junto con el software.
En el enfoque incremental, no existe una especificacin completa del sistema hasta que se
especifica el incremento final.
3. METODOS DE DESARROLLO DE SOFTWARE.
Los mtodos son formas organizadas de producir software. Incluyen sugerencias que
se debe seguir para el proceso, la notacin que se va a utilizar, los modelos del sistema que
hay que desarrollar, las reglas que gobiernan estos modelos y las pautas de diseo.
El mtodo de desarrollo es un enfoque estructurado cuyo propsito es facilitar la produccin
de software de alta calidad de una forma costeable. El primer mtodo desarrollado en los 70s
fue el Anlisis Estructurado. Estos mtodos intentaron identificar los componentes
funcionales bsicos de un sistema, de tal forma que an se utilizan ampliamente los mtodos
orientados a funciones. En los aos 80s y 90s estos mtodos orientados a funciones fueron
complementados por Mtodos 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 mtodo ideal, y los diferentes mtodos son aplicables en distintas reas. Son
aplicados a menudo los mtodos orientados a objetos a sistemas interactivos, pero no a
sistemas con requisitos rigurosos de tiempo real.
En la actualidad todos los mtodos vienen con tecnologa CASE asociada, como los editores
para las notaciones utilizadas en el mtodo, mdulos de anlisis que verifican el modelo del
sistema segn las reglas del mtodo y generadores de informes que ayudan a crear la
documentacin del sistema. Las herramientas CASE tambin incluyen un generador de cdigo
que automticamente genera cdigo fuente a partir del modelo del sistema y de algunas guas
de procesos para los ingenieros de software.
HERRAMIENTAS CASE.
Herramienta CASE (Ingeniera 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
ingeniera de requisitos, el diseo, el desarrollo de programas y las pruebas. Se introdujeron en
los aos 80 y 90. Las herramientas CASE incluyen editores de diseo, diccionarios de datos,
compiladores, depuradores, herramientas de construccin de sistemas, proporcionando
informacin acerca del software de desarrollo, etctera. Actualmente, la tecnologa CASE est
madura y hay herramientas y bancos de trabajo de un amplio rango de proveedores estn
disponibles.
Se describen tres perspectivas de clasificacin:
Una perspectiva funcional. Se clasifica la herramienta CASE de acuerdo con su funcin
especfica.
Una perspectiva de proceso. Se clasifica de acuerdo con las actividades del proceso que
ayudan.
Una perspectiva de integracin. Se clasifica de acuerdo con la forma en que estn organizadas
en unidades integradas que proporcionan ayuda a una o ms actividades del proceso.
Tipo de herramienta Ejemplos
Herramientas de planificacin
Herramientas PERT, herramientas de estimacin,
hojas de clculo.
Herramientas de edicin
Editores de texto, editores de diagramas,
procesadores de texto.
Herramientas de gestin de cambio
Herramientas de rastreo de requisitos, sistemas de
control de cambios.
Herramientas de gestin de
configuracin
Sistema de gestin de versiones, herramientas de
construccin de sistemas.
Herramientas de construccin de
prototipos
Lenguajes de muy alto nivel, generadores de
interfaz de usuario.
Herramientas de apoyo a mtodos
Editores de diseo, diccionarios de datos,
generadores de cdigo.
Herramientas de procesamiento de
Compiladores, intrpretes.


lenguajes
Herramientas de anlisis de
programas
Generadores de referencias cruzadas, analizadores
estticos, analizadores dinmicos.
Herramientas de pruebas
Generadores de pruebas de datos, comparadores de
archivos.
Herramientas de depuracin Sistemas de depuracin interactiva.
Herramientas de documentacin
Programas de diseo de pginas, editores de
imgenes.
Herramientas de reingeniera
Sistemas de referencias cruzadas, sistemas
reestructuracin de programas.
Clasificacin funcional de las herramientas CASE

4. PROCESO UNIFICADO RATIONAL (RUP).
El Proceso Unificado de Rational (RUP) es un modelo de proceso moderno y genrico
asociado al Proceso Unificado de Desarrollo de Software (1999). Rene elementos de todos
los modelos de procesos genricos, iteraciones de apoyo e ilustra buenas prcticas en la
especificacin y el diseo.
Describe tres perspectivas:
1. Una perspectiva dinmica que muestra las fases del modelo sobre el tiempo.
2. Una perspectiva esttica que muestra las actividades del proceso.
3. Una perspectiva prctica que sugiere buenas prcticas a utilizar durante el proceso.

RUP Rational Unifield Process


PERSPECTIVA DINMICA
RUP identifica cuatro fases diferentes en el proceso de software, las fases estn mucho ms
relacionadas con asuntos de negocio ms que tcnicos.
1. I nicio. Se establece un caso de negocio del sistema. Se identifica todas las actividades
externas que interactan en el sistema y define estas interacciones. Esto se utiliza para
evaluar la aportacin que el sistema hara al negocio.
2. Elaboracin. Se desarrolla la comprensin del dominio del problema, se establece un
marco de trabajo arquitectnico, 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 descripcin arquitectnica y un plan de
desarrollo del software.
3. Construccin. Comprende el diseo del sistema, la programacin y las pruebas.
Durante esta fase se desarrollan e integran las partes del sistema. Al terminar se debe
tener un software operativo y la documentacin para el usuario.
4. Transicin. 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 diseado conjuntamente con UML (Lenguaje de Modelado Unificado)
Flujo de Trabajo Descripcin
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 interactan con el sistema.
Anlisis y Diseo
Se crea y documenta el modelo de diseo (arquitectnico,
componentes, objetos y de secuencia).
Implementacin Generacin del cdigo.
Pruebas
Las pruebas se llevan a cabo conjuntamente con la implementacin
es un proceso iterativo. Al finalizar se efectan las pruebas del
sistema y aceptacin.
Despliegue
Se crea una versin del producto, se distribuye al usuario
instalndose en su lugar de trabajo.
Configuracin y
gestin de cambios
De soporte, gestiona los cambios en el sistema.


Gestin del proyecto De soporte, gestiona el desarrollo del sistema.
Entorno
Desarrollar herramientas software disponible para los equipos de
desarrollo de software.
Flujo de trabajo esttico en el Proceso Unificado de Rational
PERSPECTIVA PRCTICA
Se describen las buenas prcticas de la ingeniera del software que son aconsejables en el
desarrollo de sistemas. Se recomiendan seis buenas prcticas fundamentales:
1. Desarrollar el software de modo iterativo. Planificar incrementos del sistema basado
en las prioridades del usuario, desarrollo y entregue las caractersticas del sistema de
ms 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 estticas y
dinmicas del software.
5. Verificar la calidad del software. Asegurar que el software cumple los estndares de
calidad organizacionales.
6. Controlar los cambios del software. Utilizar un sistema de gestin de cambios y
procedimientos y herramientas de gestin de configuracin.
RUP no es un proceso apropiado para todos los tipos de desarrollo sino que representa una
nueva generacin de procesos. Las innovaciones ms importantes son la separacin en fases y
flujos de trabajo, y el reconocimiento de que la utilizacin del software en un entorno del
usuario es parte del proceso.



Capacidad o condicin que deber ser alcanzada
por el producto software
(I EEE Computer Society)
Un requisito es una declaracin abstracta de alto nivel de un servicio que
debe proporcionar el sistema o una restriccin de ste. En el otro caso, es una
definicin detallada y formal de una funcin 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 caractersticas del diseo
del sistema.
Para obtener los requisitos de los usuarios se debe tener en consideracin:
1. Tener un formato estndar y asegurar que todos los requisitos se encuentren en l.
2. No deben haber omisiones y deben ser fciles de verificar.
3. Una referencia a la especificacin ms detallada de los requisitos del sistema.
4. Fuente del requisito.
5. Distinguir partes claves del requisito.
6. No usar jergas informticas.
7. Incluir trminos tcnicos 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 especificacin completa y consistente del sistema y son utilizados por
los ingenieros de software como punto de partida para el diseo del sistema.
Se pueden redactar los requisitos del sistema en un documento estructurado en lenguaje
natural (algunas veces denominado especificacin funcional), lenguaje que los no especialistas
puedan entender. Sin embargo se pueden redactar los requisitos del sistema en unas
notaciones ms especializadas, modelos grficos 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 estndar de redactar los requisitos del sistema.
Mantiene la mayor parte de la expresividad y comprensin y asegura que se imponga cierto
grado de uniformidad en la especificacin. Las notaciones del lenguaje estructurado limitan la
terminologa que se utilizan y emplean plantillas para especificar los requisitos del sistema.
Pueden incorporar construcciones de control derivadas de los lenguajes de programacin y
manifestaciones grficas para dividir la especificacin.
Heninger (1980) describe uno de los primeros proyectos que utiliz el lenguaje estructurado
para especificar los requisitos del sistema. Se disearon formularios de propsito especial para
describir la entrada, la salida y las funciones de un sistema software para un avin.
Se define uno o ms formularios o plantillas estndar para expresar los requisitos del sistema.
Se puede estructurar la especificacin alrededor de los objetos que manipula el sistema, las
funciones ejecutadas por el sistema o los eventos procesados por ste.
Captulo Descripcin
Prefacio
Define los posibles lectores del documento y describe la versin
de la historia, incluyendo un fundamento para la creacin de una
nueva versin y un resumen de cambios hechos en cada una.
Introduccin
Describe la necesidad del sistema, brevemente sus funciones y
explica cmo trabajar con otros sistemas. Describe la manera de
cmo se adhiere al negocio u objetivos estratgicos de la
organizacin.
Glosario
Define los trminos tcnicos utilizados en el documento. No se
deben hacer suposiciones.
Definicin 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 estndares de productos y procesos a
seguir.
Arquitectura de sistema
Visin general de alto nivel que muestra la distribucin de
funciones de los mdulos del sistema. Se resaltan los
componentes arquitectnicos reutilizados.
Especificacin 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 podran ser
modelos de objetos, modelos de flujos de datos y modelos de
datos semnticos.
Evolucin del sistema
Suposiciones fundamentales sobre las cuales se basa el sistema
y los cambios previstos debido a la evolucin del hardware,
cambios en las necesidades del usuario, etc.
Apndices
Informacin detallada y precisa relacionada con la aplicacin.
Ejemplo, descripciones del hardware, o base de datos.
ndice Un ndice alfabtico de funciones o diagramas, etc.

1. REQUISITOS FUNCIONALES Y NO FUNCIONALES.
Los requisitos pueden ser organizados en torno a un esquema de clasificacin 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 explcitamente lo que el sistema no debe hacer.
La especificacin 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 especficas 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 proteccin, la disponibilidad, y otras propiedades. Esto significa que a menudo son
ms crticos 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
funcionarn correctamente.
Los requisitos no funcionales a menudo se aplican al sistema en su totalidad.
En realidad, la distincin entre los tipos de requisitos no es tan clara como sugieren estas
definiciones. Por ejemplo, un requisito del usuario sobre seguridad podra 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
autenticacin del usuario.
Los requisitos no funcionales surgen de las necesidades del usuario, debido a las restricciones
en el presupuesto, a las polticas de la organizacin, 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 ejecucin 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. Estndares que deben utilizarse en los procesos; los
requisitos de implementacin, como los lenguajes de programacin o el mtodo de
diseo a utilizar, y los requisitos de entrega que especifican cundo se entregar el
producto y su documentacin.
3. Requisitos externos. Requisitos que se derivan de los factores externos y de su
proceso de desarrollo. Pueden incluir los requisitos de interoperabilidad, cmo el
sistema interacta con otros sistemas de otras organizaciones; el legislativo cmo el
sistema funciona dentro de la ley, y los requisitos ticos.
Un problema comn con los requisitos no funcionales es que pueden ser difciles de verificar.
Varias mediciones (mtricas) pueden usarse para especificar las propiedades no funcionales
del sistema, estas caractersticas 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 actualizacin de la pantalla.
Tamao K Bytes
Nmero de chips de RAM
Fiabilidad Tiempo medio entre fallos
Probabilidad de no disponibilidad.
Tasa de ocurrencia de fallos
Disponibilidad.
Robustez Tiempo de reinicio despus de fallos
Porcentaje de eventos que provocan fallos
Probabilidad de corrupcin de datos despus de fallos.
Portabilidad Porcentaje de declaraciones dependientes del objetivo
Nmero de sistemas objetivo.
Mtricas para especificar requisitos no funcionales.
Es de utilidad diferenciar los requisitos funcionales y no funcionales en el documento de
requisitos. En la prctica, esto es difcil. Si los requisitos no funcionales se declaran de forma
separada de los funcionales, algunas veces es difcil ver la relacin entre ellos.



2. INGENIERA DE REQUISITOS.
La ingeniera de requisitos es la disciplina para desarrollar una
especificacin completa, consistente y no ambigua, la cual servir como base
para acuerdos comunes entre todas las partes involucradas y en dnde se
describen las funciones que realizar el sistema
(Boehm, 1979)
La ingeniera de requisitos facilita el mecanismo apropiado para
comprender lo que el cliente quiere, analizar sus necesidades, confirmar la
viabilidad, negociar una solucin razonable, especificar la solucin sin
ambigedad, validar la especificacin y gestionar los requisitos a fin de
transformarlos en una solucin operacional
(Pressman, 2002)
La ingeniera de requisitos es el proceso de desarrollar la especificacin del software, de
definir los servicios que el sistema brindar y de las restricciones de funcionamiento y
desarrollo del mismo. La ingeniera de requisitos es una etapa parcialmente crtica en el
proceso de software, de sta depender el diseo e implementacin del sistema. La
documentacin de los requisitos conducir a la especificacin del sistema. Se presentan en dos
niveles de detalle: los clientes necesitan una declaracin de alto nivel de los requisitos
mientras los desarrolladores necesitan una especificacin ms detallada de ste.
PROCESOS DE INGENIERA DE REQUISITOS
El proceso de ingeniera de requisitos incluye un estudio de viabilidad, as como la obtencin,
anlisis, especificacin, validacin y gestin de requisitos.

Actividades del proceso de IR
a. Estudio de viabilidad.
Evala 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 econmico y
rpido de elaborar.


Se debe responder a las siguientes preguntas:
1. Contribuye el sistema a los objetivos generales de la organizacin?
2. Se puede implementar utilizando la tecnologa actual y dentro de las restricciones de
costo y tiempo?
3. Puede integrarse el sistema con otros sistemas existentes en la organizacin?
En el estudio de viabilidad se considera un conjunto de requisitos de negocio preliminares, la
descripcin resumida del sistema y como pretende contribuir a los procesos del negocio. Si el
sistema no contribuye con los objetivos de la organizacin, entonces no tiene un valor real en
el negocio.
b. Obtencin y anlisis de requisitos.
Obtener los requisitos del sistema por medio de la observacin 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 aplicacin, 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.

Construccin de prototipos
Obtener y comprender los requisitos es difcil por varias razones:
1. Los stakeholders a menudo no conocen lo que desean obtener del sistema informtico
excepto en trminos muy generales;
2. Los stakeholders expresan los requisitos con sus propios trminos de forma natural y
con un conocimiento implcito de su propio trabajo.
3. Pueden surgir requisitos distintos de diferentes stakeholders.
4. Pueden influir factores polticos en los requisitos del sistema.
5. Es dinmico el entorno econmico y de negocios en el que se lleva a cabo el anlisis,
pueden surgir nuevos requisitos que no haban sido considerado.
La obtencin y anlisis de requisitos es un proceso iterativo que puede ser representado como
una espiral de actividades el descubrimiento, la clasificacin y organizacin, la negociacin
y la documentacin 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 mtodos de anlisis estructurado.
2. Clasificacin y organizacin de requisitos. Los requisitos se organiza en grupos
coherentes de una manera estructurada. La forma ms comn de agrupar es utilizar un
modelo de la arquitectura del sistema para identificar los subsistemas y asociar los
requisitos en cada subsistema.
3. Ordenacin por prioridades y negociacin de requisitos. Esta actividad se refiere a
ordenar los requisitos segn las prioridades, y a encontrar y resolver los requisitos en
conflicto a travs de la negociacin.
4. Documentacin 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 fcil de manejar, cambiar y organizar.
La obtencin y anlisis de requisitos es un proceso iterativo con retroalimentacin continua de
cada actividad. Comienza con el descubrimiento de requisitos y termina con la documentacin
de los mismos. La comprensin de los requisitos por parte del analista mejora con cada
iteracin.
ENTREVISTAS
Las entrevistas sirven para obtener una comprensin general de lo que hacen los stakeholders,
cmo podran 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 descripcin
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 caractersticas:
1. Estn 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 ms fcil hablar en un contexto
definido en vez de en trminos generales.
Se documenta la informacin adquirida en las entrevistas.
ESCENARIOS
Se han desarrollado varias formas de escenarios, cada una de las cuales proporciona diferentes
tipos de informacin en diferentes niveles de detalle sobre el sistema.
Un escenario puede incluir:
Descripcin cuando el escenario comienza.
Descripcin del flujo normal de eventos.
Descripcin de lo que puede ir mal y cmo manejarlo.
Informacin de otras actividades que se podran llevar a cabo al mismo tiempo.
Descripcin del estado del sistema cuando el escenario termina.
Los escenarios se redactan como texto, complementados por diagramas, fotografas de las
pantallas, etc. Se puede adoptar un enfoque ms 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 mtodo Objetory (Jacobson, 1993)
son una tcnica que se basa en escenarios para la obtencin de requisitos. Actualmente se han
convertido en una caracterstica fundamental de la notacin UML, que se utiliza para describir
modelos de sistemas orientados a objetos. En una forma ms simple, un caso de uso identifica
el tipo de interaccin y los actores involucrados.
Actor Caso de uso

Notacin del caso de uso
Los escenarios y los casos de uso son tcnicas eficaces para obtener requisitos para los puntos
de vista de los interactuadores, donde cada tipo de interaccin se puede representar como un
caso de uso.
ETNOLOGIA
La etnologa es una tcnica de observacin 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 estn involucrados. El valor de la etnografa
es que ayuda a los analistas a descubrir los requisitos implcitos que reflejan los procesos
reales ms que los formales en los que la gente est involucrada.



c. Validacin de Requisitos.
En la validacin 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 despus 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 diseo o los de codificacin. La razn de esto es que un
cambio en los requisitos normalmente significa que el diseo y la implementacin del sistema
tambin deben cambiar y que ste debe probarse nuevamente.
Las principales tcnicas para la validacin son las revisiones de los requisitos y la
construccin de prototipos.
La revisin de requisitos es un proceso manual que involucra a personas tanto de la
organizacin como desarrolladores. Verifican el documento de requisitos en cuanto a
anomalas y omisiones. Las revisiones de requisitos pueden ser formales o informales.
Los conflictos, contradicciones, errores y omisiones en los requisitos deben ser sealados por
los revisores y registrados formalmente en el informe de revisin.
d. Gestin de Requisitos.
Los cambios en los negocios, organizaciones y tcnicos inevitablemente conducen a
cambios en los requisitos de un sistema software. La gestin de requisitos es el proceso de
gestionar y controlar estos cambios.
El proceso de gestin de requisitos incluye la gestin de la planificacin, en la cual se disean
las polticas y procedimientos para la gestin de requisitos, y la del cambio, en la que usted
analiza los cambios propuestos en los requisitos y evala su impacto.
La gestin de requisitos tiene un costo. Durante la etapa de gestin de requisitos, habr que
decidir sobre:
1. Identificar los requisitos. Se identifican los requisitos de forma nica.
2. Proceso de gestin de cambios. Se evala el impacto y costo de los cambios.
3. Polticas de rastreo. Se define las relaciones entre los requisitos y la manera en que
estos registros se deben mantener.
La gestin de requisitos comprende el procesamiento de grandes cantidades de informacin.
Las herramientas que se pueden utilizar van desde sistemas de gestin de requisitos
especializados hasta hojas de clculo 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
informacin sobre dicho sistema.
Una tcnica ampliamente usada es documentar la especificacin del sistema como un conjunto
de modelos del sistema. Estos modelos son representaciones grficas que describen los
procesos del negocio, el problema a resolver y el sistema que tiene que ser desarrollado.
Debido a las representaciones grficas usadas, los modelos son a menudo ms comprensibles
que las descripciones detalladas en lenguaje natural de los requisitos del sistema. Ellos
constituyen tambin un puente importante entre el proceso de anlisis y diseo.
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 ms importante de un modelo del sistema es que omite los detalles.
Los tipos de modelos del sistema distintos se basan en distintas aproximaciones de
abstraccin. Ejemplo de tipos de modelos del sistema que podran crearse durante el proceso
de anlisis son:
1. Modelo de flujo de datos. Muestra como se procesan los datos en el sistema en las
diferentes etapas.
2. Modelo de composicin o agregacin. Muestra cmo las entidades del sistema estn
compuestas por otras entidades.
3. Modelo arquitectnico. Muestra los principales subsistemas que componen el sistema.
4. Modelo de clasificacin. Los diagramas de clase/herencia de objetos muestran cmo
las entidades tienen caractersticas comunes.
5. Modelo de estmulo-respuesta. O diagrama de transicin de estados muestra cmo
reacciona el sistema a eventos internos y externos.
Siempre que es posible, se usan notacin del Lenguaje Unificado de Modelado (UML), que
se ha convertido en un lenguaje de modelado estndar 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 arquitectnico proporcionando una visin general de la organizacin
del sistema. En el modelo arquitectnico es ms apropiado clasificar los componentes


(subsistemas) de acuerdo con su funcionalidad. Pueden mostrarse los principales subsistemas
y su interconexin en un diagrama de bloques, esto es vlido para sistemas de cualquier
tamao. Comnmente los subsistemas se desarrollan en paralelo.
En la integracin 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 integracin creciente, uno a uno, por dos razones:
1. El desarrollo de todos los subsistemas no terminan al mismo tiempo.
2. La integracin creciente reduce el costo en la ubicacin 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 cmo 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 Gestin de Cambios

Modelo de contexto del Sistema de Gestin de Cambios
Definen los lmites del sistema. Los modelos arquitectnicos, los modelos de procesos y
modelos de flujos de datos pueden utilizarse como modelos de contexto.
Los modelos arquitectnicos 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 tambin 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
mquina de estado, que modelan cmo 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 definicin de la forma lgica de los datos
procesados por el sistema. La tcnica de modelado de datos ms importante usada es el
modelado Entidad-Relacin-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-relacin han sido ampliamente usados en el diseo 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 caracterstica deseable.
UML no incluye una notacin especfica 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 alfabticamente
incluida en los modelos del sistema, incluye el nombre del dato, una descripcin asociada de
dicha entidad, fecha de creacin, el creador y la representacin 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, deberan 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 lgicas del sistema y su clasificacin y
agregacin. Combinan un modelo de datos con un modelo de procesamiento. Posibles
modelos de objetos que pueden desarrollarse incluyen modelos de herencia, modelos de
agregacin 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 anlisis de requisitos normalmente simplifica la
transicin entre el diseo orientado a objetos y la programacin.
Una clase de objetos es una abstraccin 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 anlisis se centran en las clases de objetos
y en sus relaciones.
METODOS ESTRUCTURADOS
Los mtodos estructurados proporcionan un marco para soportar el desarrollo de modelos
del sistema. Los mtodos estructurados normalmente son soportados de forma extensiva por
herramientas CASE, incluyendo la edicin de modelos y la comprobacin y generacin de
cdigo.
Fueron desarrollados en la dcada de los 70s para soportar el anlisis y el diseo del software
y evolucionaron en la dcada de los 80s y 90s para soportar el desarrollo orientado a objetos.
Los mtodos estructurados proporcionan un marco para el modelado detallado de sistemas
como parte de la elicitacin y anlisis de requisitos. Los mtodos estructurados han sido
aplicados con xito en muchos proyectos grandes. Utilizan notaciones estndar y aseguran que
se produce una documentacin de diseo estndar. Sin embargo, tienen una serie de
inconvenientes:


1. No proporcionan un soporte efectivo para la comprensin o el modelado de requisitos
del sistema no funcionales.
2. No incluyen guas que ayuden a los usuarios a decidir si un mtodo es adecuado para
un problema concreto.
3. No incluyen consejos sobre cmo pueden adaptarse para su uso en un entorno
particular.
4. Los modelos producidos son muy detallados y los usuarios los encuentran difciles de
entender.



DISEO DEL SOFTWARE

1. CONCEPTOS Y PRINCIPIOS DE DISEO.
El diseo del software es la descripcin 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 diseo es un proceso creativo, no hay una frmula estricta para el diseo del software. Se
aprende a cmo disear observando ejemplos de diseo existentes y discutiendo su diseo con
otros. Los diseadores no llegan inmediatamente a un diseo detallado, sino que lo desarrollan
de manera iterativa a travs de diversas versiones.
La esencia del diseo del software es la toma de decisiones sobre la organizacin lgica del
software. Puede representarse esta organizacin lgica como un modelo en un lenguaje
definido de modelado tal como UML y otras veces simplemente notaciones informales y
esbozos para representar el diseo.
Los grandes sistemas siempre se descomponen en subsistemas que proporcionan algn
conjunto de servicios relacionados.
El diseo arquitectnico es la primera etapa en el proceso de diseo y representa un enlace
crtico entre los procesos de ingeniera de requisitos y diseo. El proceso de diseo
arquitectnico est relacionado con el establecimiento de un marco estructural bsico que
identifica los principales componentes de un sistema y las comunicaciones entre los
componentes. Las decisiones de diseo arquitectnico incluyen decisiones sobre el tipo de
aplicacin, la distribucin del sistema, los estilos arquitectnicos a utilizar y las formas en las
que la arquitectura debera documentarse y evaluarse. La descomposicin arquitectnica es
necesaria para estructurar y organizar la especificacin. El resultado de este proceso de diseo
es una descripcin de la arquitectura del software.
La arquitectura del software es un marco fundamental para estructurar el sistema. Puede
servir como un plan de diseo para negociar los requisitos del sistema y cmo estructurar las
discusiones con los clientes, desarrolladores y gestores. Es una herramienta esencial para la
gestin de la complejidad. La arquitectura del software oculta detalles y permite a los
diseadores centrarse en las abstracciones clave del sistema.
La arquitectura del software afecta al rendimiento, proteccin, seguridad, disponibilidad,
solidez, grado de distribucin y mantenibilidad de un sistema, puede depender de los
requisitos no funcionales del sistema.
Tres ventajas de disear explcitamente y documentar la arquitectura del software:
1. Comunicacin con los stakeholders.
2. Anlisis del sistema.
3. Reutilizacin a gran escala.
El diseo de un subsistema es una descomposicin 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 diseo 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 estn implicadas en el proceso de desarrollo de sistema.
El problema general de decidir cmo descomponer un sistema en subsistemas es difcil. Los
requisitos del sistema son un factor fundamental y debera intentarse crear un diseo 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 arquitectnicos tales como el modelo estructural, el modelo de
control y el modelo de descomposicin que pueden ser desarrollados durante el proceso de
diseo arquitectnico.
2. EL PROCESO DE DISEO DE SOFTWARE.
Los procesos de diseo e implementacin comprenden la transformacin de la
especificacin de los requisitos en un sistema software ejecutable. Los mtodos sistemticos
de diseo se pueden utilizar como parte de esta transformacin.
El proceso de diseo puede implicar el desarrollo de varios modelos del sistema con diferentes
niveles de abstraccin, las actividades del proceso de diseo se entrelazan.
Actividades del proceso de diseo:
1. Diseo arquitectnico. Se identifican y documentan los subsistemas que forman el
sistema y sus relaciones.
2. Especificacin abstracta. Cada subsistema tiene una especificacin abstracta de sus
servicios y restricciones bajo las cuales debe funcionar.
3. Diseo de la interfaz. Para cada subsistema se disea y documenta su interfaz con
otros subsistemas. Esta especificacin de la interfaz debe ser inequvoca ya que
permite que el subsistema se utilice sin conocimiento de su funcionamiento.
4. Diseo de componentes. Se asignan servicios a los componentes y se disean sus
interfaces.
5. Diseo de la estructura de datos. Se disea y especifica en detalle la estructura de
datos.
6. Diseo de algoritmos. Se disean y especifican los algoritmos para los servicios
3. DISEO ARQUITECTNICO.
El diseo arquitectnico es un proceso creativo en el que se intenta establecer una
organizacin del sistema que satisfaga los requisitos funcionales y no funcionales. Durante el
proceso de diseo arquitectnico, los arquitectos del sistema tienen que tomar varias
decisiones fundamentales que afectan al sistema y a su proceso de desarrollo.
Actualmente, la mayora de los sistemas grandes son sistemas distribuidos en los que el
software del sistema se distribuye entre computadoras diferentes. La eleccin de la
arquitectura de distribucin es una decisin clave que afecta al rendimiento y la fiabilidad del
sistema.


La arquitectura de un sistema software puede basarse en un modelo o estilo arquitectnico
particular. Un estilo arquitectnico es un patrn de organizacin de un sistema tal como una
organizacin cliente-servidor o una arquitectura por capas. Es importante un conocimiento de
estos estilos, sus aplicaciones y sus ventajas e inconvenientes.
La evaluacin de un diseo arquitectnico es difcil debido a que la verdadera prueba de una
arquitectura consiste en averiguar el grado de satisfaccin de los requisitos funcionales y no
funcionales despus de que aqul ha sido desarrollado.
El resultado del proceso de diseo arquitectnico es un documento que incluye varias
representaciones grficas del sistema junto con texto descriptivo asociado. Describe cmo se
estructura el sistema en subsistemas. Los modelos grficos del sistema presentan diferentes
perspectivas de la arquitectura. Los modelos arquitectnicos pueden incluir:
1. Un modelo estructural esttico.
2. Un modelo de proceso dinmico.
3. Un modelo de interfaz.
4. Modelos de relaciones
5. Modelo de distribucin.
El modelo arquitectnico cliente-servidor es un modelo de sistema en el que se organiza
como un conjunto de servicios y servidores asociados, ms 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 ms 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 aproximacin 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
tambin 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 aaden nuevas facilidades a una capa, solamente se ve afectada la capa
adyacente.
Un modelo arquitectnico orientado a objetos estructura el sistema en un conjunto de objetos
dbilmente acoplados y con interfaces bien definidas. Los objetos realizan llamadas a los
servicios ofrecidos por otros objetos.
Una descomposicin 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 aproximacin orientada a objetos son bien conocidas. Debido a que los
objetos estn dbilmente acoplados, la implementacin 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 fcilmente comprensible. Debido a que las entidades del mundo real


se usan en sistemas diferentes, los objetos pueden reutilizarse. Se han desarrollado lenguajes
de programacin orientados a objetos que proporcionan implementaciones directas de
componentes arquitectnicos. Si bien los objetos pueden corresponderse con entidades del
mundo real a pequea escala, algunas veces es difcil representar como objetos entidades ms
complejas.
En una descomposicin 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 funcin a otra y se transforman a medida que se mueven a travs de la secuencia de
funciones. Cada paso de procesamiento se implementa como una transformacin. Los datos de
entrada fluyen a travs de estas transformaciones hasta que se convierten en datos de salida.
Las transformaciones se pueden ejecutar secuencialmente o en paralelo.
4. DISEO DE LA INTERFAZ DE USUARIO.
El diseo del software abarca varias actividades, incluyendo el diseo de la interfaz de
usuario. Todos los sistemas interactivos tienen que proporcionar alguna forma de presentar la
informacin a los usuarios. La presentacin de la informacin puede ser simplemente una
representacin directa de la informacin de entrada o presentar la informacin grficamente.
Para encontrar la mejora representacin de la informacin, se necesita conocer a los usuarios y
saber cmo utilizarn el sistema.
Adems de presentar la informacin de la aplicacin, los sistemas tambin se comunican con
los usuarios a travs de mensajes que proporcionan informacin 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 cmo se podra corregir el
error.
Los principios que ayudan a guiar el diseo de la interfaz de usuario abarcan: familiaridad del
usuario, la uniformidad, la mnima sorpresa, la recuperabilidad, la gua al usuario.
Principio Descripcin
Familiaridad del
usuario
Debe utilizar terminologa, estilos de interaccin obtenidos de la
experiencia de personas que ms utilizan el sistema.
Uniformidad
La interfaz debe ser uniforme, las operaciones comparables deben
de activarse de la misma forma.
Mnima 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.
Gua de usuario
Cuando ocurran errores, la interfaz debe proporcionar
retroalimentacin significativa y caractersticas de ayuda sensible
al contexto.
Diversidad de usuarios
La interfaz debe proporcionar caractersticas de interaccin
apropiadas para los diferentes tipos de usuarios del sistema.
Principios de diseo de la interfaz de usuario


Los diseadores tienen que encontrar un trmino medio entre los estilos de interaccin ms
adecuados para la aplicacin, la formacin y experiencia de los usuarios del sistema y el
equipo disponible. Los estilos de interaccin incluyen la manipulacin directa, los sistemas de
mens, el rellenado de formularios, los lenguajes de comandos y el lenguaje natural.
Cada uno de los estilos de interaccin tiene ventajas y desventajas y es ms adecuada para
diferentes tipos de aplicaciones y usuarios. Estos estilos de interaccin se pueden mezclar,
utilizando varios en la misma aplicacin.
Las interfaces de usuario basadas en Web se fundan en el soporte proporcionado por HTML o
XHTML (lenguaje de descripcin de pginas) junto con lenguajes como Java, la mayora
utilizan formularios. Es posible construir interfaces de manipulacin directa en Web, pero sta
es una tarea compleja de programacin.
PROCESO DE DISEO DE LA INTERFAZ DE USUARIO
El diseo de la interfaz de usuario (UI) es un proceso iterativo donde los usuarios interactan
con los diseadores y prototipos de la interfaz para decidir las caractersticas, organizacin,
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 ingeniera del
software. En especial cuando se utiliza un desarrollo iterativo, el diseo de la interfaz de
usuario se lleva a cabo de forma incremental conforme se desarrolla el software.
Existen tres actividades esenciales en el diseo de la IU:
1. Anlisis del usuario. Da a conocer las formas de trabajar de los usuarios, a travs 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 retroalimentacin. Se desarrollan prototipos del sistema y se
exponen a los usuarios. Implicar al usuario en el proceso de diseo y desarrollo es un
aspecto fundamental del diseo centrado en el usuario, un criterio de diseo para
sistemas interactivos.
Se puede utilizar una tcnica basada en storyboards. Un storyboard es una serie de
esbozos que ilustran una secuencia de interacciones.
3. Evaluacin de la interfaz. La evaluacin 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 verificacin y validacin de los
sistemas software.
La evaluacin sistemtica del diseo de la interfaz de usuario puede ser un proceso
caro que implica a diseadores grficos y otros.
Se puede utilizar la construccin de prototipos como parte del proceso de ingeniera de
requisitos y, tiene sentido empezar el proceso de diseo de la IU en esta etapa. En los procesos
iterativos, el diseo de la IU se integra con el desarrollo del software.
5. DISEO ORIENTADO A OBJETOS.
Un sistema orientado a objetos est compuesto de objetos que interactan. El diseo
orientado a objetos es un medio para disear software de tal forma que los componentes del
diseo representen objetos con su estado y operaciones propias en lugar de funciones.


El diseo orientado a objetos es parte del desarrollo orientado a objetos:
El anlisis orientado a objetos. Desarrollo de un modelo orientado a objetos del
dominio de la aplicacin. Los objetos identificados reflejan las entidades y operaciones
que se asocian con el problema a resolver.
El diseo orientado a objetos. Comprende el desarrollo de un modelo orientado a
objetos de un sistema software para implementar los requisitos, estn relacionados con
la solucin del problema por resolver.
La programacin orientada a objetos. Se refiere a implementar el diseo de software
utilizando un lenguaje de programacin orientado a objetos como Java.
Los sistemas orientados a objetos son ms fciles de mantener, debido a que los objetos son
independientes. Cambiar la implementacin de un objeto o agregarle servicios no debe afectar
a otros objetos del sistema. Puesto que los objetos estn 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 diseos se pueden desarrollar utilizando
objetos creados en diseos previos. Esto reduce los costos de diseo, programacin y
validacin.
El Lenguaje Unificado de Modelado (UML) es un conjunto de notaciones que pueden
utilizarse para documentar un diseo 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 diseo orientado a objetos, centrndose particularmente en el diseo de la
arquitectura.
La utilizacin de casos de uso significa que el diseo 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 anlisis y diseo orientado a objetos, pero necesitan ser complementados con otras
tcnicas que nos permitan descubrir requisitos no funcionales del sistema.
OBJETOS Y CLASES
Un objeto es un encapsulamiento de informacin. 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 algn clculo.
Los objetos se crean conforme a una definicin de clases de objetos. Una definicin 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 rectngulo con nombre y dos secciones (la seccin
superior los atributos del objeto y la seccin inferior las operaciones asociadas con el
objeto). En UML operacin es la especificacin de una accin, mtodo es la
implementacin de la operacin.



Empleado
nombre: string
direccin: string
fechaNacimiento: date
nroEmpleado: integer
salario: integer
status : (current, left, retired)

une()
abandona()
jubilado()
cambiaDetalles()
Objeto Empleado
Los objetos se comunican a travs de la solicitud de servicios (llamando a los mtodos) de
otros objetos y, si es necesario, intercambiando la informacin requerida para que ese servicio
se suministre. Los resultados de la ejecucin del servicio se pasan como parmetros.
Cuando los objetos coexisten en el mismo programa, las llamadas a los mtodos se
implementan como llamadas a procedimientos o funciones en un lenguaje como C.
Las clases se pueden organizar mediante una generalizacin o jerarqua de herencia que
muestra las relaciones entre las clases generales y ms especficas. La clase ms especfica
concuerda completamente con la clase general, pero incluye informacin adicional. En la
notacin UML, la generalizacin se indica mediante una flecha que apunta a la clase padre. En
los lenguajes de programacin orientados a objetos, pero lo regular la generalizacin 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 lnea que une las clases, a la que se le puede agregar
una nota con informacin de la asociacin.
La asociacin es una relacin muy general y a menudo se utiliza en UML para indicar que un
atributo del objeto es un objeto asociado, o que la implementacin de un mtodo del objeto
depende del objeto asociado. Una de las asociaciones ms comunes es la agregacin que
muestra la manera en que los objetos estn compuestos de otros objetos.
PROCESO DE DISEO ORIENTADO A OBJETOS
El proceso de diseo orientado a objetos incluye actividades para disear la arquitectura del
sistema, identificar objetos en el sistema, describir el diseo utilizando diversos modelos de
objetos y documentar las interfaces de objetos.
El proceso general que se utiliza para el diseo orientado a objetos tiene varias etapas:
1. Comprender y definir el contexto y los modos de utilizacin del sistema.
2. Disear la arquitectura del sistema.
3. Identificar los objetos principales en el sistema.


4. Desarrollar los modelos de diseo.
5. Especificar las interfaces de los objetos.
El diseo no es un proceso sencillo y bien estructurado. En realidad, un diseo se desarrolla
proponiendo soluciones y refinando estas soluciones.
Un paquete en UML representa una coleccin de objetos y otros paquetes.
CONTEXTO DEL SISTEMA Y MODELOS DE UTILIZACIN
La primera etapa en el proceso de diseo de software es comprender las relaciones entre el
software que se est diseando y el entorno externo. Comprender eso ayuda a decidir cmo
suministrar la funcionalidad requerida al sistema y cmo 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 esttico que describe a otros sistemas de su
entorno.
2. El modelo de utilizacin del sistema es un modelo dinmico que describe cmo el
sistema interacta 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 interaccin con el sistema. En los modelos de casos de uso, cada interaccin posible se
enuncia en una elipse y la entidad externa implicada en la interaccin se representa mediante
una figura estilizada.
Cada caso de uso se describe utilizando una descripcin en lenguaje natural sencillo. Esto
ayuda a los diseadores a identificar los objetos en el sistema y les permite comprender lo que
har el sistema.
La descripcin 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 ms
sencillas posibles.
IDENTIFICACIN DE CLASES
Las clases tienden a emerger durante el proceso de diseo. Por lo general, hay que buscar y
documentar otras clases que pudieran ser relevantes. El diseo se describe en funcin de estas
clases. Se han hecho varias propuestas de cmo identificar las clases:
1. Utilizar un anlisis gramatical de la descripcin 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 solucin, las cuales podran
requerirse para apoyar a otros objetos.


3. Utilizar un enfoque de comportamiento en el cual el diseador primero comprende el
comportamiento total del sistema.
4. Utilizar un anlisis 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 anlisis debe identificar los objetos,
atributos y operaciones requeridos. Para ayudar a este enfoque basado en escenarios
existe un mtodo efectivo de anlisis denominado tarjetas CRC en el cual los analistas
y diseadores se encargan de identificar las actividades de los objetos.
La informacin adicional del conocimiento del dominio de aplicacin o del anlisis del
escenario se utiliza para refinar y extender los objetos iniciales. Esta informacin se recoge de
los documentos de requisitos, de las discusiones con los usuarios y de un anlisis de los
sistemas existentes.
MODELOS DE DISEO
Los modelos de diseo muestran los objetos o clases en un sistema y, los diferentes tipos de
relaciones entre estas entidades. Los modelos de diseo son esencialmente el diseo mismo.
Son el puente entre los requisitos y la implementacin del sistema.
Un sistema de procesamiento secuencial de datos se disea de forma diferente de un sistema
dedicado en tiempo real, por lo que utiliza distintos modelos de diseo.
Existen dos tipos de modelos de diseo para describir un diseo orientado a objetos:
1. Modelos estticos que describen la estructura esttica del sistema en trminos de las
clases del sistema y sus relaciones.
2. Modelos dinmicos que describen la estructura dinmica 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 estticos y dinmicos utilizados en el documento de diseo.
1. Los modelos de subsistemas. Muestra las agrupaciones lgicas 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 estticos.
2. Los modelos de secuencia. Muestran la secuencia de interacciones de los objetos. Se
representan utilizando una secuencia UML o un diagrama de colaboracin. Los
modelos de secuencia son dinmicos.
3. Los modelos de mquinas. 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 generalizacin y herencia. Muestran cmo las clases pueden ser
generalizaciones de otras clases.


7. Los modelos de agregacin. Muestran cmo podemos describir colecciones de
objetos.
Un modelo de subsistemas es un modelo esttico til que nos muestra cmo puede estar
organizado el diseo de forma lgica agrupando objetos.
Los modelos de secuencia son modelos dinmicos que documenta, para cada modo de
interaccin, la secuencia de interacciones que tienen lugar entre los objetos.
Cuando se documenta un diseo, se debe producir un modelo de secuencia para cada
interaccin 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 tambin 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 mquina de
estado no ayudara a los implementadotes a comprender estos objetos.
ESPECIFICACIN DE LA INTERFAZ DE LOS OBJETOS
Una parte importante de cualquier proceso de diseo es la especificacin de las interfaces
entre los diferentes componentes del sistema.
El diseo de interfaces de objetos comprende la especificacin del detalle de la interfaz para
un objeto o un grupo de objetos. Las interfaces se especifican en UML utilizando la misma
notacin que en los diagramas de clases. No existe una seccin de atributos, y el estereotipo
en UML <interfaz> se debe incluir en la parte del nombre.
EVOLUCIN DEL DISEO
Una ventaja importante de un enfoque orientado a objetos para el diseo es que simplifica el
problema de hacer cambios a dicho diseo. La razn de esto es que la representacin del
estado del objeto no influye en el diseo. Cambiar los detalles internos de un objeto no afecta
a ningn otro objeto del sistema.



DESARROLLO DEL SOFTWARE

Existen diferentes formas de desarrollar software. Entre ellas se encuentran la
programacin original en lenguajes como C o Java, la generacin de secuencias de comandos,
la programacin de bases de datos, la generacin de programas a travs de herramientas
CASE, y la ingeniera de software basada en la reutilizacin.
1. DESARROLLO RPIDO DE SOFTWARE.
Actualmente, los negocios operan en un entorno global que cambia rpidamente. El
software es parte de casi todas las operaciones de negocio, por lo que es fundamental que el
software se desarrolle rpidamente para aprovechar nuevas oportunidades y responder a la
presin competitiva. El desarrollo y entrega rpidos son a menudo los requisitos ms crticos
de los sistemas software. Muchas compaas estn dispuestas a una prdida en la calidad del
software y en el compromiso sobre los requisitos a favor de una entrega rpida del software.
Debido a que estas compaas operan en un entorno cambiante, a menudo es prcticamente
imposible obtener un conjunto completo de requisitos de software estable. Cuando los
requisitos cambian o cuando se descubren problemas con ellos, el diseo o implementacin
del sistema se tiene que volver a realizar o probar.
Los procesos de desarrollo rpido de software estn diseados para producir software til de
forma rpida. Generalmente, son procesos iterativos en los que se entrelazan la especificacin,
el diseo, el desarrollo y las pruebas. Donde en cada incremento se incluyen nuevas
funcionalidades al sistema. Se tiene las siguientes caractersticas fundamentales:
1. Los procesos de especificacin, diseo e implementacin son concurrentes. No existe
una especificacin detallada del sistema, y se minimiza la documentacin del diseo.
El documento de requisitos del usuario define solamente las caractersticas ms
importantes del sistema.
2. El sistema se desarrolla en una serie de incrementos. Los usuarios finales y otros
stakeholders del sistema participan en la especificacin y evaluacin de cada
incremento.
3. A menudo se desarrollan las interfaces de usuario del sistema utilizando un sistema de
desarrollo interactivo que permite que el diseo de la interfaz se cree rpidamente
dibujando y colando iconos en la interfaz.
El desarrollo incremental, implica producir y entregar el software en incrementos ms que en
un paquete nico. Cada iteracin 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 retroalimentacin sobre los
incrementos entregados al equipo de desarrollo.

Modelo de desarrollo rpido de aplicaciones

El desarrollo incremental del software es un enfoque mucho mejor para el desarrollo de la
mayora de los sistemas de negocio, comercio electrnico 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 rpidos 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 crticos en los que se deben analizar todos los
requisitos para verificar las interacciones que puedan comprometer la seguridad o proteccin
del sistema.
Para conseguir algunos de los beneficios del desarrollo incremental, se puede utilizar un
proceso hbrido en el que se desarrolle de forma iterativa un prototipo del sistema y se utilice
como una plataforma para experimentar con los requisitos y diseo 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 ms alta.


2. El objetivo del prototipado es validar u obtener los requisitos del sistema.
Los sistemas desarrollados incrementalmente se deben desarrollar con los mismos estndares
de calidad de la organizacin como cualquier otro software. Debe tener una estructura robusta
para que se les pueda dar mantenimiento durante muchos aos. Deben ser fiables y eficientes,
y deben estar acordes con los estndares organizacionales apropiados.
El desarrollo rpido de aplicaciones implica la utilizacin de entornos de desarrollo que
incluyan herramientas para apoyar la produccin del sistema. Estas comprenden lenguajes de
programacin de bases de datos, generadores de formularios e informes y enlaces a
aplicaciones de oficina.
2. MTODOS GILES DE DESARROLLO.
En los aos 80s y principios de los 90s, exista una opinin general de que la mejor
forma de obtener un mejor software era a travs de una planificacin cuidadosa del proyecto.
Esta opinin provena, fundamentalmente, de la comunidad de ingenieros de software
implicada en el desarrollo de grandes sistemas software de larga vida, eran a menudo sistemas
crticos y trabajaban en el software durante largos perodos de tiempo. Estos enfoques,
implican una importante sobrecarga de trabajo en cuanto a la planificacin, diseo y
documentacin del sistema.
Cuando este enfoque pesado de desarrollo basado en la planificacin, fue aplicado a
sistemas de negocios pequeos 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
aos 90s a proponer nuevos mtodos giles, que permitieron centrarse en el mismo software
en vez de en su diseo y documentacin. Los mtodos giles universalmente dependen de un
enfoque iterativo para la especificacin, desarrollo y entrega del software, y principalmente
fueron diseados para apoyar al desarrollo de aplicaciones de negocio donde los requisitos del
sistema normalmente cambiaban rpidamente durante el proceso de desarrollo.
Probablemente el mtodo gil ms conocido es la Programacin 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 Caractersticas (Palmer y Felsing, 2002). El xito de estos mtodos ha llevado a
una cierta integracin con mtodos de desarrollo ms tradicionales basados en el modelado de
sistemas, dando por resultado la nocin de modelado gil (Ambler y Jeffries, 2002) y las
instanciaciones giles del Proceso Unificado de Rational (Larman, 2002).
Aunque todos estos mtodos giles se basan en la nocin de desarrollo y entrega
incrementales, proponen procesos diferentes para alcanzarla. Comparten un conjunto de
principios y, por lo tanto, tienen mucho en comn.
Principio Descripcin
Participacin 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
disea 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 Mtodos giles
Todos los mtodos tienen lmites, y los mtodos giles son apropiados para algunos tipos de
desarrollo de sistemas. Los ms idneos para el desarrollo de sistemas de negocio pequeo 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 mtodos giles para el desarrollo de sistemas crticos en los que es
necesario un anlisis detallado de todos los requisitos del sistema para comprender sus
implicaciones de seguridad o proteccin.
PROGRAMACION EXTREMA
La Programacin Extrema (XP) es posiblemente el mtodo gil ms conocido y ampliamente
utilizado (Beck, 2000), debido a que el enfoque fue desarrollado utilizando buenas prcticas
de programacin reconocidas, como el desarrollo iterativo, pruebas sistemticas, la coninua
mejora del software y la participacin del usuario en el equipo de desarrollo.
En la programacin 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
cdigo.
La programacin extrema implica varias prcticas, que se ajustan a los principios de mtodos
giles:
1. Desarrollo incremental
2. Participacin del usuario
3. Inters en las personas, en vez en los procesos
4. El cambio se lleva a cabo a travs de las entregas regulares del sistema.
5. El mantenimiento de la simplicidad se lleva a cabo a travs de la refactorizacin
constante.
En el proceso de la XP, los usuarios estn fuertemente implicados en la especificacin 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 implementacin. El usuario establece
la prioridad de las historias a implementar.
Algo particular de la programacin 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 ingeniera de software tradicional es que se debe disear para
el cambio. Esto es, hay que prever los cambios futuros en el software y disear ste de forma
que tales cambios se puedan implementar fcilmente.
La programacin extrema aborda este problema sugiriendo que se debe refactorizar
constantemente el software. Esto significa que el equipo de programacin busca posibles
mejoras del software y las implementa inmediatamente. Por lo tanto, el software siempre debe
ser fcil de entender y cambiar cuando se implementen nuevas historias.
3. REUTILIZACIN DEL SOFTWARE.
La ingeniera de software basada en reutilizacin es una estrategia del software
comparable en la que el proceso de desarrollo es adaptado a la reutilizacin de software
existente. La tendencia hacia el desarrollo basado en reutilizacin viene dada como respuesta
a las demandas de una menor produccin de software y de menor costo de mantenimiento, de
una entrega ms rpida de los sistemas y del incremento en la calidad del software.
Las unidades de software que se reutilizan pueden ser de tamao totalmente diferentes:
1. Reutilizacin de aplicaciones. Una aplicacin puede ser reutilizada totalmente sin
ningn cambio en otros sistemas, configurando la aplicacin para diferentes clientes.
2. Reutilizacin de componentes. La reutilizacin de componentes vara en tamao,
puede ser la reutilizacin de un subsistema o la reutilizacin de un simple objeto.
3. Reutilizacin de objetos y funciones. Pueden reutilizarse componentes software que
implementan una nica funcin, como ejemplo una funcin matemtica o una clase de
objetos. Estn disponibles muchas libreras de funciones y clases para diferentes tipos
de aplicaciones y plataformas de desarrollo. Es particularmente efectiva en reas como
algoritmos matemticos y grficos, donde se necesita a un experto especfico para
desarrollar objetos y funciones.
Los sistemas y componentes software son entidades reutilizables, pero su naturaleza
especfica significa a veces, que el costo de modificarlos para una nueva situacin resulte
elevado. La reutilizacin de conceptos puede incluirse en aproximaciones tales como patrones
de diseo, productos de sistemas configurables y generadores de programas.
La ventaja obvia de la reutilizacin del software se da en los costos de desarrollo. Se necesita
menos especificar, disear, implementar y validar componentes de software.
CAMPOS DE LA REUTILIZACIN
En los ltimos aos, se han desarrollado muchas tcnicas para soportar la reutilizacin del
software. Esta reutilizacin es posible a diferentes niveles (desde funciones simples a
aplicaciones completas), y los estndares para componentes reutilizables facilitan la
reutilizacin.


Los factores claves que deberan considerarse a la hora de planificar la reutilizacin son:
1. La agenda de desarrollo del software. Si el software tiene que desarrollarse
rpidamente.
2. Vida esperada del software. Si se est desarrollando un sistema de larga vida, hara
que centrarse en la mantenibilidad del sistema.
3. Los conocimientos, habilidades y experiencia del grupo de desarrollo. Todas las
tecnologas de reutilizacin 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 difcil si no se tiene acceso al cdigo fuente del
software.
5. El dominio de las aplicaciones. Hay varios productos genricos que pueden
reutilizarse para configurarlos a una situacin particular.
6. La plataforma sobre la que el sistema se va a ejecutar.

Campos de la reutilizacin
PATRONES DE DISEO
Una forma de reutilizar diseos abstractos que no incluyen detalles de la implementacin y
que se ajusten a los requisitos particulares de la aplicacin ha sido incluida en los patrones de
diseo.
Los patrones de diseo se derivaron de las ideas introducidas por Cristopher Alexander
(1977), quien sugiri que existan ciertos patrones de diseo de edificios que eran comunes e
inherentemente, interesantes y efectivos. El patrn es una descripcin del problema y la
esencia de su solucin, de forma que la solucin se pueda reutilizar en diferentes situaciones.
El patrn no es una especificacin detallada, puede pensarse en l como una descripcin del
conocimiento y experiencia acumulados. Es una solucin adecuada a un problema comn.


Los patrones y los lenguajes de patrones son formas de describir las mejores prcticas, buenos
diseos y encapsulan la experiencia de tal forma que es posible para otros el reutilizar dicha
experiencia.
Un patrn de diseo es una plantilla para una solucin de diseo que puede instanciarse de
diferentes formas. A menudo sta se expresa grficamente y se muestra en la solucin las
relaciones entre los objetos y las clases de los objetos.
Actualmente estn disponibles un elevado nmero de patrones publicados que abarcan varios
dominios de aplicacin y lenguajes. La nocin de un patrn como un concepto reutilizable ha
sido desarrollada en varias reas adems del diseo software, que incluye gestin de
configuracin, diseo de interfaz de usuario y escenarios de interacciones.
El uso de patrones es una forma efectiva de reutilizacin. Sin embargo, se puede afirmar que
slo 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 diseo de un sistema formado por una coleccin de clases
concretas y abstractas y la interfaz entre ellas. Son implementados los detalles particulares del
subsistema de la aplicacin aadiendo 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 genrica que puede ser extendida para crear un
subsistema o aplicacin ms especfico. Es implementado como una coleccin de clases de
objetos concretas y abstractas.
Uno de los marcos de trabajo ms conocido y usado ampliamente para el diseo de GUIs es el
marco Modelo-Vista-Controlador (MVC). Fue propuesto en la dcada de los 80s como una
aproximacin de diseo GUIs. El marco MVC soporta la presentacin de los datos de
diferentes formas e interacciones independientes de cada una de estas presentaciones. Cuando
los datos se modifican a travs 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 reutilizacin a travs del concepto de lneas 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 reutilizacin de sistemas de aplicaciones implica reutilizar sistemas de aplicaciones
completos, configurndolo para un entorno especfico o integrando dos o ms sistemas para
crear una nueva aplicacin. Se analizan dos tipos de reutilizacin de aplicaciones: el


desarrollo de lneas de productos y la creacin de nuevos sistemas integrando dos o ms
aplicaciones comerciales.
Una lnea de productos es una conjunto de sistemas software basados en una arquitectura
base comn y componentes compartidos.
En la actualidad, es normal para los sistemas grandes, tener definidas Interfaces de
Programacin de Aplicaciones (APIs) que permiten programar el acceso a las funciones de
dichos sistemas. Se consideran como una opcin de diseo los sistemas como comercio
electrnico mediante la integracin de sistemas COTS.
4. INGENIERA DEL SOFTWARE BASADO EN COMPONENTES.
La Ingeniera de Software Basada en Componentes (CBSE) surgi a finales de los 90s
como una aproximacin basada en reutilizacin al desarrollo de sistemas software.
CBSE es una aproximacin basada en la reutilizacin para definir, implementar e integrar
componentes independientes debidamente acoplados para formar sistemas. Se ha convertido
en una importante aproximacin de desarrollo del software debido a que los sistemas software
son cada vez ms grandes y ms complejos y los clientes demandan software ms confiable
que sea desarrollado ms rpidamente.
Los fundamentos de la ingeniera del software basada en componentes son:
1. Componentes independientes. Debera haber una clara separacin entre la interfaz de
los componentes y su implementacin, para reemplazarse por otro sin cambiar el
sistema.
2. Estndares de componentes. En un modelo de componentes se incluyen estndares. Si
los componentes cumplen con los estndares, entonces su funcionamiento es
independiente del lenguaje de programacin. Pueden integrarse en el mismo sistema
componentes escritos en diferentes lenguajes.
3. El middleware. Proporciona soporte software para la integracin de componentes. Un
producto middleware como CORBA, maneja cuestiones de bajo nivel de forma
eficiente y permite al diseador centrarse en problemas relacionados con la aplicacin.
Un producto middleware puede proporcionar soporte para asignacin de recursos,
gestin de transacciones, seguridad y concurrencia.
4. Un proceso de desarrollo. Si se intenta aadir una aproximacin basada en
componentes a un proceso de desarrollo que est adaptado a la produccin de software
original, se puede observar que las suposiciones inherentes al proceso limitan el
potencial del CBSE.
La ingeniera de software basada en reutilizacin se est convirtiendo en la principal
aproximacin de desarrollo para sistemas comerciales y de empresas. Las entidades que son
reutilizadas varan desde funciones hasta sistemas completos. Los componentes pueden
interoperar dentro de un marco de trabajo como CORBA.
Se est adoptando cada vez ms el desarrollo basado en componentes como una aproximacin
fundamental en la ingeniera de software. CBSE est asentado sobre principios de diseo
slidos, para la construccin de software comprensible y mantenible. Son independientes los
componentes para no interferir en su funcionamiento unos con otros. Los componentes se


comunican a travs de interfaces bien definidas, las infraestructuras de componentes
proporcionan plataformas de alto nivel que reducen los costos del desarrollo de aplicaciones.
La Ingeniera 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. Certificacin de componentes. Certificar que los componentes cumplen una
especificacin formal. Sin embargo, la industria no parece dispuesta a pagar por esto.
3. Prediccin 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 especificacin y diseo del sistema.
Alcanzar este equilibrio es un proceso intuitivo. Necesitamos un mtodo de anlisis de
equilibrio sistemtico y ms estructurado para ayudar a los diseadores a seleccionar y
configurar componentes.
Hasta ahora, el principal uso de CBSE se ha dado en la construccin de sistemas de
informacin de empresas, tales como sistemas de comercio electrnico.
COMPONENTES Y MODELOS DE COMPONENTES
Un componente es una unidad de software cuya funcionalidad y dependencias estn
completamente definidas por un conjunto de interfaces pblicas. Los componentes pueden
combinarse con otros componentes sin hacer referencia a su implementacin y pueden ser
desplegados como una unidad ejecutable.
Tambin se considera un componente como un proveedor de servicios independiente.
Cuando un sistema necesita algn servicio, llama a un componente para proporcionar dicho
servicio sin tener en cuenta dnde se est ejecutando o en qu lenguaje se ha desarrollado. Se
resalta dos caractersticas crticas de un componente reutilizable:
1. El componente es una entidad ejecutable independiente.
2. Los servicios ofertados por un componente estn disponibles a travs de una interfaz, y
todas las interacciones son a travs de esa interfaz.
Caractersticas del
Componente
Descripcin
Estandarizado
Un componente tiene que ajustarse a algn modelo estandarizado.
Este modelo puede definir las interfaces de los componentes, los
metadatos de componentes, la documentacin, la composicin y
despliegue.
Independencia
Debera componerse y desplegarse sin tener que utilizar otros
componentes especficos.
Componible
Para que un componente sea componible, todas las interacciones
externas deben tener lugar a travs de interfaces definidas
pblicamente. Debe proporcionar acceso externo a la informacin


sobre s mismo, como por ejemplo a sus mtodos y atributos.
Desplegable
Un componente debe ser independiente y debe ser capaz de funcionar
como una entidad autnoma 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.
Caractersticas del Componente
La visin de un componente como un proveedor de servicios resalta dos caractersticas crticas
de un componente reutilizable:
1. El componente es una entidad ejecutable independiente.
2. Los servicios ofertados por un componente estn disponibles a travs de una interfaz, y
todas las interacciones son a travs de esa interfaz.
Un modelo de componentes define un conjunto de estndares para componentes, incluyendo
estndares de interfaz, estndares de uso y estndares de despliegue. La implementacin 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
informacin que se necesita para utilizar el componente en un programa y elementos
relacionados con el despliegue del componente.
El modelo de componentes especifica cmo deberan definirse las interfaces y los elementos,
tales como nombres de operaciones, parmetros y excepciones, que deberan incluirse en la
definicin de una interfaz.



Elementos bsicos de un modelo de componentes
Una parte importante del modelo de componentes es la definicin de cmo los componentes
deberan empaquetarse para su despliegue como entidades ejecutables independientes.
Los modelos de componentes son tambin 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 reutilizacin tanto como sea posible.
2. Son refinados y modificados los requisitos en etapas tempranas del proceso
dependiendo de la disponibilidad de los componentes.
3. Despus de que la arquitectura del sistema haya sido diseada, hay una actividad
adicional de bsqueda de componentes y refinamiento de diseo.
4. El desarrollo es un proceso de composicin en el que se integran los componentes
descubiertos.
La composicin 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 operacin sencilla la composicin, existen varios tipos de
composiciones:
1. Composicin secuencial. Los componentes constituyentes se ejecutan en secuencia.
2. Composicin jerrquica. Un componente realiza una llamada directamente a los
servicios proporcionados por otro componente.
3. Composicin aditiva. Las interfaces de dos o ms componentes se unen para crear un
nuevo componente.



PRUEBAS DEL SOFTWARE

Las pruebas de software consisten de una verificacin dinmica 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. Terminologa, 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.
Tcnicas de prueba. La primera categora incluye las pruebas basadas en la intuicin
del probador y la experiencia. En la segunda categora las tcnicas basadas en las
especificaciones, las tcnicas basadas en el cdigo, tcnicas basadas en las faltas, las
tcnicas basadas en el uso, y las tcnicas relativas a la naturaleza de la aplicacin.
Seleccionar y combinar las tcnicas de modo apropiado.
Medidas relacionadas a las pruebas. Las medidas estn agrupadas con relacin a la
evaluacin del programa bajo prueba y la evaluacin de las pruebas ejecutadas.
Proceso de prueba. Incluye las consideraciones prcticas y las actividades de prueba.

Desglose de los tpicos de pruebas de software segn SWEBOK


1. FUNDAMENTOS DE LAS PRUEBAS.
Las pruebas es una actividad ejecutada para la evaluacin 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 ms
defectos.
La visin de las pruebas de software ha evolucionado hacia algo ms constructivo. Las
pruebas ya no se consideran una actividad que se inicia slo despus que haya completado la
fase de codificacin, con el propsito 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 construccin real del producto. Es ms, la
planificacin para la realizacin de las pruebas debe comenzarse con las primeras etapas del
proceso de requisitos, y los planes y procedimientos de prueba pueden ser sistemticamente
continuadas durante el desarrollo.
Muchos trminos son utilizados en la literatura de ingeniera de software para describir un mal
funcionamiento, notablemente defecto, falla, error. Es esencial distinguir la causa, para que el
trmino 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 estn relacionadas con otras actividades como:
Pruebas vs. tcnicas de gestin de la calidad del software.
Pruebas vs. pruebas de exactitud y verificacin formal.
Pruebas vs. depuracin.
Pruebas vs. programacin.
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 porcin del software
probado separadamente. Dependiendo del contexto, sern subprogramas individuales o
un componente hecho de unidades relacionadas. Usualmente una prueba de unidad
accede al cdigo probado y soporta herramientas de depuracin, e involucra a los
programadores que hicieron el cdigo.
2. Prueba de integracin. Las pruebas de integracin es el proceso de verificar la
interaccin entre los componentes del software. Las estrategias de integracin
sistemtica modernas son impulsadas por la arquitectura, lo que implica la integracin
de los componentes de software. Las pruebas de integracin es una actividad continua,
del cual los ingenieros de software pueden concentrarse en las perspectivas del nivel
que estn integrando.
3. Prueba de sistema. La prueba de sistema es concerniente al comportamiento del
sistema completo. La mayora de las fallas funcionales son identificadas durante la


prueba de unidad e integracin. 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 tambin
evaluados en este nivel.
Pruebas por objetivo
Las pruebas son conducidas por algn objetivo especfico, el cual es ms o menos explcito, y
con diversos grados de precisin. Afirmar el objetivo con precisin y los trminos
cuantitativos permite el control que se establecer el proceso de prueba. Las pruebas pueden
ser destinadas a la verificacin de diferentes propiedades. Los casos de prueba pueden ser
diseados para chequear que las especificaciones funcionales sean implementadas
correctamente, el cual es variablemente referido en la literatura como prueba de conformidad,
pruebas de correccin, o prueba funcional. Sin embargo, otros propsitos no funcionales
diferentes pueden ser probados como performance, fiabilidad y usabilidad, entre muchas otras.
PRUEBA DE ACEPTACION
La prueba de aceptacin 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 pequeo grupo de usuarios
potenciales, interno (prueba alfa) o externo (prueba beta). Los cuales informan los problemas
a los desarrolladores del sistema. Despus de esta retroalimentacin, 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 regresin 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
repeticin de las pruebas destinadas a mostrar que el software no sea cambiado, excepto en la
medida que es requerido. La prueba de regresin 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 estn fuera de los lmites del diseo del software.
PRUEBA DE STRESS
Los ejercicios de prueba de stress del software en el diseo mximo de carga, como fuera de
ella.



PRUEBAS DE RECUPERACION
Pruebas de recuperacin es encaminadas para verificar las capacidades de reinicio despus de
un desastre.
PRUEBA DE CONFIGURACION
En los casos donde el software es construido para servir a los diferentes usuarios, la prueba de
configuracin analiza el software bajo varias configuraciones especificadas.
PRUEBAS DE USABILIDAD
Este proceso evala cun fcil es para los usuarios finales usar y aprender del software,
incluyendo la documentacin del usuario y la habilidad de los usuarios para recuperarse
despus de algn 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 tcnicas han sido desarrolladas para esto. El principio
fundamental que subyace a las tcnicas es hacer sistemtica la identificacin de un conjunto
de comportamientos del programa.
Es difcil encontrar una clasificacin homognea de tcnicas. La clasificacin est basada en
como las pruebas son generadas desde la intuicin y experiencia de los ingenieros de software,
las especificaciones, la estructura del cdigo, las fallas (real o artificial) a descubrir, el mbito
de uso, o la naturaleza de la aplicacin. Algunas veces estas tcnicas son clasificadas como
caja-blanca, si las pruebas utilizan una perspectiva interna del sistema para disear los casos
de prueba basados en la estructura interna. Requiere de habilidades de programacin
identificar todas las trayectorias a travs 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 cmo 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 categora ofrece el uso combinado de dos o ms tcnicas.
BASADO EN LA INTUICIN Y EXPERIENCIA
PRUEBA AD-HOC
La tcnica ms practicada, se obtienen apoyndose en la habilidad, intuicin y experiencia del
ingeniero de software con programas similares. La prueba ad hoc pueden usarse para
identificar las pruebas especiales, no fcilmente capturadas por tcnicas formalizadas.
PRUEBAS DE EXPLORACIN
Las pruebas de exploracin es definida como aprendizaje simultneo, diseo de la prueba, y
ejecucin de la prueba. Las pruebas no son definidas de acuerdo a un plan de prueba
establecido, son diseadas, ejecutadas y modificadas dinmicamente. 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 aplicacin, la plataforma, las fallas, el tipo de defecto posible.



TCNICAS BASADAS EN LA ESPECIFICACIN
PARTICIN EQUIVALENTE
El dominio de la entrada es subdividido en una coleccin de subconjuntos, o clases
equivalentes, el cual son considerados equivalente de acuerdo a una relacin especfica, y un
conjunto representativo de pruebas (algunas veces solo una) tomadas en cada clase.
ANLISIS DE VALOR LMITE
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
extensin de esta tcnica es la tcnica de prueba de robustez, donde los casos de prueba son
tambin elegida fuera del dominio de entrada, para probar la robustez del programa en
entradas no esperadas o errneas.
TABLA DE DECISIN
Las tablas de decisin representan las relaciones lgicas entre las condiciones (entradas) y las
acciones (salidas). Los casos de prueba son sistemticamente derivadas por consideracin
cada combinacin posible de condiciones y acciones. Tcnica relacionada son los grficos
causa-efecto.
MQUINA BASADA EN ESTADO FINITO
Modelar un programa como una mquina 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 desviacin automtica de casos de
prueba funcionales, y, al mismo tiempo, brinda una salida referencial, en oracle, para la
verificacin de los resultados de las pruebas. Existen mtodos 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 especificacin, donde al menos la entrada de dominio debe ser conocido,
y ser capaz de recoger los puntos aleatorios dentro de este.
TCNICAS BASADAS EN EL CDIGO
CRITERIO BASADO EN EL FLUJO DE CONTROL
Estas pruebas estn encaminadas a cubrir todas las sentencias o bloques de sentencias en un
programa. El criterio basado flujo de control ms 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 prctica, as como la prueba de sentencia, pruebas
branck (rama), y pruebas de condicin. La adecuacin de estas pruebas se mide en
porcentajes.


CRITERIO BASADO EN FLUJO DE DATOS
Son mtodos que generan los casos de prueba basndose 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 informacin 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 CDIGO
(FLUJOGRAMA, LLAMADO GRFICO)
Aunque no es una tcnica en s misma, la estructura de control de un programa es
representado grficamente usando diagramas de flujo en tcnicas de prueba basada en el
cdigo. Un diagrama de flujo es un grfico 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.
TCNICAS BASADAS EN LAS FALLAS
Las tcnicas basadas en fallas tienen grados diferentes de formalizacin
ADIVINANZA DE ERRORES
Los casos de prueba son especficamente diseados por los ingenieros de software tratando de
averiguar los fallos ms plausibles en un determinado programa. Una buena fuente de
informacin es la historia de las fallas descubiertas, as como la experiencia de los ingenieros
de software.
LA PRUEBA DE MUTACIN
Un mutante es una versin de programa ligeramente modificado en el cdigo, cambio
sintctico. Los casos de prueba ejecutan la versin 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 tcnica para evaluar un
conjunto de pruebas, la prueba de mutacin es tambin un criterio de prueba en s misma:
cualquiera de las pruebas son generadas al azar hasta que un nmero suficiente de mutantes
hayan sido killed, o las pruebas son especficamente diseadas para matar mutantes
sobrevivientes. En el ltimo caso, la prueba de mutacin puede tambin ser categorizada como
una tcnica basada en el cdigo. El efecto de las pruebas de mutacin, es que al hacer una
falla sistemtica, se encontrarn fallas reales ms complejas. Para que esta tcnica sea
efectiva, puede ser derivado automticamente un gran nmero de mutantes de una manera
sistemtica.
TCNICAS BASADAS EN EL USO
PERFIL OPERACIONAL
El ambiente de prueba en la prueba para la evaluacin 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
distribucin de probabilidad, o perfil, de acuerdo a la ocurrencia en la operacin actual.



PRUEBA DE LA INGENIERA DE FIABILIDAD DE SOFTWARE
La prueba de ingeniera de fiabilidad de software (SRET) consiste en un mtodo de prueba
acompaado del proceso de desarrollo, la prueba es diseada y guiada por objetivos de
fiabilidad y el uso relativo esperado y crticamente de funciones diferentes en el campo.
TCNICAS BASADAS EN LA NATURALEZA DE LA APLICACIN
Las tcnicas mencionadas se aplican a todos los tipos de software. Sin embargo, para algunos
tipos de aplicaciones, conocimiento adicional es requerido para la derivacin de la prueba. A
continuacin una lista de pruebas especializadas, basadas en la naturaleza de la aplicacin:
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
TCNICAS DE SELECCIN Y COMBINACIN
FUNCIONAL Y ESTRUCTURAL
Tcnicas basadas en la especificacin y basadas en el cdigo son contrastadas como pruebas
funcionales versus pruebas estructurales. Estos dos enfoques de seleccin de pruebas no son
vistas como alternativas complementarias; en efecto, usan diferentes fuentes de informacin y
han demostrado poner de relieve los distintos tipos de problemas. Ellos podran ser utilizados
en combinacin, dependiendo de consideraciones presupuestarias.
DETERMINSTICA VS RANDOM
Pueden ser seleccionados los casos de prueba de una manera determinstica, de acuerdo a una
de las varias tcnicas listadas, o al azar extrada de la distribucin de entradas, as como es
usualmente hecha en la prueba de fiabilidad. Han sido conducidas diversas comparaciones
analticas y empricas para analizar las condiciones que hacer un enfoque ms eficaz que la
otra.
5. PROCESO DE PRUEBAS.
Los conceptos de prueba, estrategias, tcnicas 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 gua al equipo de prueba, desde la planificacin de la prueba
a la evaluacin de las salidas, una manera de brindar una garanta justificada a los objetivos de
prueba segn el costo-efectividad.
CONSIDERACIONES PRCTICAS
ACTITUDES/PROGRAMACIN EGOLESS
Las pruebas y el aseguramiento de la calidad hay que realizarlas de modo colaborativo. Los
administradores tienen un rol clave en la recepcin favorable generalmente hacia las fallas
descubiertas durante el desarrollo y mantenimiento; por ejemplo, prevenir la mentalidad de la


propiedad del cdigo entre programadores, ellos no se sienten responsables de las fallas
reveladas por su cdigo.
GUA DE PRUEBAS
La fase de pruebas podra 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 especficos.
GESTIN DEL PROCESO DE PRUEBA
Pueden ser organizadas las actividades de prueba en niveles diferentes, junto con las personas,
herramientas, polticas y mediciones, en un proceso bien definido el cual es una parte integral
del ciclo de vida. En el estndar IEEE/EIA 12207.0, las pruebas no estn descritas como un
proceso stand-alone, pero los principios para las actividades de prueba estn 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 evaluacin como integral en el ciclo de vida completo.
DOCUMENTACIN DE LAS PRUEBAS Y LOS PRODUCTOS TRABAJO
La documentacin es una parte integral de la formalizacin del proceso de prueba. El estndar
IEEE para documentacin de prueba de software (IEEE829-98) brinda una buena descripcin
de los documentos de prueba y de su relacin con otro proceso. Los documentos de prueba
pueden incluir, entre otros, Plan de Pruebas, Especificacin de diseo de prueba,
especificacin del procedimiento de prueba, especificacin 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
documentacin de las pruebas es producida y actualizada continuamente, con el mismo nivel
de calidad como otros tipos de documentacin en ingeniera de software.
EQUIPO DE PRUEBA INTERNO VS INDEPENDIENTE
La formalizacin del proceso de prueba puede incluir tambin la formalizacin de la
organizacin del equipo de pruebas. El equipo de prueba puede estar compuesto de miembros
internos (el equipo del proyecto, involucrado o no en la construccin 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 crticamente de la
aplicacin.
ESTIMACIN 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 bsqueda eficaz de
falla de las diversas fases de prueba. Estas medidas de prueba pueden cubrir aspectos como el
nmero de casos de prueba especificados, nmero de casos de prueba ejecutadas, nmero de
casos de prueba probadas, y nmero de caso de pruebas falladas, entre otras.
La evaluacin de los reportes de pruebas pueden ser combinada con el anlisis de la causa raiz
para evaluar la efectividad del proceso de prueba tan pronto haya sido posible encontrar las
fallas. Adems, los recursos utilizados para las pruebas debern ser de acorde con el


uso/crtico de la aplicacin: las tcnicas tienen diferentes costos y diferentes niveles de
confidencia de la fiabilidad del producto.
TERMINACIN
La decisin de culminacin de las pruebas debe darse cuando es suficiente la cantidad de
pruebas ejecutadas. Minuciosas medidas, as como la cobertura del cdigo 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 decisin tambin envuelve
consideraciones sobre los costos y riesgos incurridos por el potencial de las fallas, en
contraposicin 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 sistemticamente. El repositorio de material de
pruebas puede estar bajo el control de la gestin de configuracin del software, as los
cambios en los requisitos o el diseo del software puede estar reflejado en cambios al alcance
de las pruebas conducidas.
Las soluciones adoptadas en las pruebas de algn tipo de aplicacin bajo ciertas
circunstancias, con la motivacin de las decisiones tomadas, forman un patrn de prueba que
puede ser documentado para un reuso posterior en proyectos similares.
ACTIVIDADES EN LAS PRUEBAS
Es dado una breve descripcin de actividades de prueba. La administracin de las actividades
de prueba depende del proceso de Gestin de Configuracin del Software.
PLANIFICACIN
Al igual que cualquier otro aspecto de gestin de proyectos, las actividades de pruebas pueden
ser planificadas. Los aspectos claves de la planificacin de las pruebas incluyen la
coordinacin de personal, gestin de facilidades de prueba disponibles y equipamiento (el cual
puede incluir media magntica, planes de prueba y procedimientos), y planificacin para
posibles resultados indeseables. Si se mantiene ms de una lnea base del software, entonces
una mejor consideracin planeada es el tiempo y el esfuerzo necesario para asegurar que el
ambiente de prueba sea el conjunto de su propia configuracin.
GENERACIN DE CASOS DE PRUEBA
La generacin de los casos de prueba est basada en el nivel de prueba a ser ejecutada y las
tcnicas de prueba particulares. Los casos de prueba estarn bajo el control de la gestin de
configuracin 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 ingeniera de
software. Facilitar el desarrollo y el control de los casos de prueba, as como la recuperacin
de los resultados esperados, scripts, y otros materiales de prueba.
EJECUCIN
La ejecucin de las pruebas deber consagrar un principio bsico de experimentacin
cientfica: todo lo realizado durante las pruebas debern ser documentadas con suficiente


claridad de tal modo que otra persona pudiera replicar los resultados. Por tanto, las pruebas
sern ejecutadas de acuerdo a procedimientos documentados usando una versin definida
claramente del software bajo prueba.
EVALUACIN 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 ningn resultado
inesperado. No todos los resultados inesperados son necesariamente fallas, sin embargo,
podra ser juzgado a ser simplemente ruido. Antes de que una falla pueda ser eliminada, es
necesario un anlisis y esfuerzo de depuracin 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 configuracin fue lo bsico para
las pruebas, y otra informacin de identificacin 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 depuracin y para la fijacin de los problemas que se
observaron durante la prueba. Tambin, las anomalas no clasificadas pueden ser
documentadas. Los reportes de las pruebas tambin son un insumo para el cambio de gestin
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, declaracin de variables
incorrectas, fugas de memoria, error de sintaxis de programacin), y cuando podran haber
sido observado por primera vez en el software. La informacin de seguimiento del defecto es
usado para determinar qu aspectos de la ingeniera del software necesitan mejorar y qu
anlisis previo han sido probados.
1. DISEO DE CASOS DE PRUEBA.
Los casos de prueba son especificaciones de las entradas para la prueba y la salida
esperada del sistema ms una afirmacin de lo que se est probando. Los datos de prueba a
veces pueden generarse automticamente. La generacin automtica 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. Deberan probarse todas las funciones del sistema.
2. Deberan probarse todas las funciones con datos correctos e incorrectos.
Para validar que el sistema satisface los requisitos, la mejor aproximacin 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. Deberan disearse un conjunto de pruebas que incluyan
entradas vlidas e invlidas y que generen salidas vlidas e invlidas.


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.
DISEO DE CASOS DE PRUEBA
El objetivo del proceso de diseo 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 disear un caso de prueba, se selecciona una caracterstica del sistema o componente que
se est probando. A continuacin, se selecciona un conjunto de entradas que ejecutan dicha
caracterstica, documenta las salidas esperadas o rangos de salida y, donde sea posible, se
disea una prueba automatizada que prueba que las salidas reales y esperadas son las mismas.
Existen varias aproximaciones que pueden seguirse para disear casos de prueba:
1. Pruebas basadas en requisitos.
2. Pruebas de particiones. Se identifican particiones de entrada y salida y se disean
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 ms probable
que conduzca a una prueba con xito es un valor en los lmites de una particin.
3. Pruebas estructurales. Se utiliza el conocimiento de la estructura del programa para
disear pruebas que ejecuten todas las partes del programa.
Las pruebas estructurales hacen referencia a analizar el programa para determinar
cambios a travs de l y usar este anlisis como ayuda para la seleccin de los casos de
prueba.
Cuando se disean casos de prueba, se debera comenzar con las pruebas de ms alto nivel a
partir de los requisitos y a continuacin de forma progresiva, aadir pruebas ms detalladas
utilizando pruebas estructurales y de particiones.
2. AUTOMATIZACIN DE PRUEBAS.
La automatizacin 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 aproximacin de las pruebas en las que se utiliza un marco de trabajo de pruebas tal como
JUnit para pruebas de regresin. 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. Tambin 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.


EVOLUCIN DEL SOFTWARE

Es ms realista considerar a la ingeniera del software como un proceso evolutivo en
el cual el software cambia continuamente durante su perodo de vida como respuesta a los
requisitos cambiantes y necesidades del usuario. La mayora de los cambios son una
consecuencia de cambios en el negocio, modificaciones por errores encontrados en su
funcionamiento, o adaptacin a una nueva plataforma, o para mejorar el rendimiento, entre
otros. El desarrollo del software no se detiene cuando el sistema ha sido entregado, contina
durante el tiempo de vida del sistema.
Se puede pensar en la ingeniera de software como un proceso en espiral con requisitos,
diseo, implementacin y pruebas que se realizan continuamente durante el tiempo de vida
del sistema.

Un modelo en espiral del desarrollo y evolucin
Este es un modelo idealizado de la evolucin del software que puede aplicarse en situaciones
en donde una organizacin es responsable tanto del desarrollo inicial del software como de la
evolucin del software. Utilizando esta aproximacin se desarrollan la mayora de los
productos software genricos.
DINAMICA DE EVOLUCIN DE LOS PROGRAMAS
Las leyes de Lehman, como la nocin de que el cambio es continuo, describen varias
observaciones a partir de estudios a largo plazo de la evolucin 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 evolucin 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 dinmica 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 nmero 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 mayora de los proyectos de programacin 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.
Aadir nueva funcionalidad a un sistema inevitablemente introduce nuevos defectos en
el sistema.
El desmantelamiento del sistema significa poner fuera de servicio dicho sistema despus de
que termina su perodo 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 organizacin.
Analizar el software para descubrir cmo estn 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 despus de
que ste ha sido entregado. Los cambios se implementan modificando los componentes del
sistema y aadiendo nuevos componentes cuando sean necesarios.
Existen tres tipos de mantenimiento del software: correccin de errores, modificacin del
software para trabajar en un nuevo entorno, e implementacin de nuevos requisitos o cambios
en stos.
Existen tres tipos de mantenimiento de software:
1. Mantenimiento para aadir 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
cdigo, es menor el costo de corregir los errores, pero los costos seran mayores si se
encontraran errores en el diseo o en los requisitos.
3. Mantenimiento para adaptar el software a diferentes entornos operativos. Esto surge
cuando cambia algn 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 reparacin 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 evolucin del sistema para
adaptarse a nuevos entornos y nuevos requisitos o cambios en los mismos.
Los costos de mantenimiento constituyen una proporcin de los costos de desarrollo y varan
de un dominio de aplicacin 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 diseo e implementacin de un sistema
para reducir los costos de mantenimiento.

Distribucin del esfuerzo de mantenimiento
Buenas tcnicas de ingeniera de software tales como una especificacin precisa, el uso de
desarrollo orientado a objetos y la gestin de configuracin contribuyen a la reduccin de los
costos de mantenimiento.
2. PROCESOS DE EVOLUCIN.
Los procesos de evolucin del software varan considerablemente dependiendo del tipo
de software a mantener, los procesos de desarrollo utilizados en una organizacin y el
personal implicado en el proceso.
Los procesos de evolucin incluyen las actividades fundamentales de anlisis del impacto
de los cambios, planificacin de entregas, implementacin de los cambios y entrega del
sistema a los usuarios. Se evala 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 versin del sistema.
El proceso de implementacin de los cambios, es esencialmente, una iteracin del proceso de
desarrollo en la que se disean, implementan y prueban las revisiones del sistema.


Reingeniera del software se refiere a la reestructuracin y redocumentacin del software para
hacerlo ms mantenible y ms fcil de cambiar.
Deberan 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.

Identificacin de los cambios y procesos de evolucin


GESTIN DE CONFIGURACIN

El objetivo de la gestin de configuracin es introducir un proceso de gestin del
cdigo y la documentacin de un sistema de software. La gestin de configuracin es el
desarrollo y aplicacin de estndares y procedimientos para gestionar un sistema software
evolutivo. Las actividades involucradas en esta gestin son: la planificacin de la gestin de
configuracin, la gestin de cambios, la gestin de versiones y entregas y la construccin de
sistemas.
Los procedimientos de gestin de configuracin definen cmo registrar y procesar los
cambios propuestos al sistema, cmo relacionarlos stos con los componentes del sistema y
los mtodos 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 lnea base al punto de inicio para la evolucin controlada.
En un proceso tradicional de desarrollo de software basado en el modelo en cascada, el
software se entrega al equipo de gestin de configuracin despus 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 lnea base para el desarrollo del sistema.

Administracin de la Gestin de Configuracin
La gestin de configuracin en el desarrollo gil y desarrollo rpido no pueden basarse en
rgidos procedimientos y papeleo burocrtico. Los procesos giles utilizan herramientas de
gestin de configuraciones, como un gestor de versiones y herramientas para la construccin
del sistema, que incorporarn algo de control.


Se pueden utilizar herramientas CASE como soporte a los procesos de la gestin de
configuracin, 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 definicin y uso de gestin de configuracin es esencial para la certificacin de calidad
ISO9000 y para los estndares CMMI.
1. PLANIFICACIN DE LA GESTIN DE CONFIGURACIN.
Un plan de gestin de gestin de configuracin describe un conjunto de estndares
generales adaptables a cada proyecto especfico y los procedimientos utilizados para la gestin
de la configuracin. El plan incluye:
1. Identificacin de los elementos de configuracin y el esquema formal que identifican
estas entidades.
2. La persona que toma la responsabilidad de los procedimientos y la persona que enva
las entidades controladas al equipo de gestin de configuracin.
3. Las polticas 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 definicin de la base de datos para registrar la informacin de la configuracin.
En el plan se incluye informacin adicional de la gestin del software por parte de los
proveedores externos y los procesos de auditoria.
Durante el proceso de planificacin de la gestin de configuracin se decide que clases de
elementos se van a controlar. Normalmente son elementos de la configuracin, los planes del
proyecto, las especificaciones, los diseos, los programas y los conjuntos de datos de prueba.
Deben ser controlados por el sistema de control de configuracin 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
configuracin. 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 raz comn del nombre. Esto
corresponde a un esquema de asignacin de nombres jerrquicos.
La asignacin de nombres jerrquica es simple y fcil de entender, y a veces copia la
estructura de directorios utilizada para almacenar los archivos del proyecto.



Jerarqua de la configuracin usada para
la asignacin de identificadores
La base de datos de configuraciones se utiliza para registrar toda la informacin 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 informacin del proyecto. La
base de datos registra informacin acerca de los usuarios, componentes, clientes del sistema,
plataformas de ejecucin, cambios propuestos, etc.
De forma ideal, la base de datos se integra en el sistema de gestin 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 informacin de los elementos de la
configuracin y hace referencia a sus nombres de archivos en el sistema de gestin de
versiones.
2. GESTIN 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 gestin de cambios.
Los procedimientos se ocupan del anlisis 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 gestin de cambios se lleva a cabo cuando el software o la documentacin asociada
se ponen bajo el control del equipo de gestin de configuracin.


La primera etapa del proceso de gestin 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. Tambin cmo implementar el cambio.
Una vez emitido el formulario se registra en la base de datos de configuraciones. Si el anlisis
descubre que el cambio solicitado es invlido, est duplicado o ya ha sido considerado, el
cambio se rechaza.
Para cambios vlidos se comprueba el impacto del cambio en el resto del sistema. Se lleva un
anlisis tcnico 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 estratgico y organizacional ms que desde el
punto de vista tcnico. En pequeos proyectos, existe slo un revisor del cambio que aconseja
si los cambios son justificables.
3. GESTIN DE VERSIONES Y ENTREGAS.
La gestin de versiones y entregas es el proceso de identificar y mantener los registros
de las diversas versiones y entregas de un sistema. Una versin 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 diseadas para diferentes configuraciones de
hardware y software.
Para crear una versin se tienen que especificar las versiones de cada uno de los componentes
que deben incluirse en l. Existen tres tcnicas bsicas para la identificacin de componentes:
1. Numeracin de las versiones. Se asigna un nmero de versin nico y explcito a cada
componente.
2. Identificacin basada en atributos. Cada componente tiene un nombre y un conjunto
asociado de atributos para cada versin. Por lo tanto, los componentes se identifican
por su nombre y por los valores de los atributos.
3. Identificacin orientada al cambio. Cada sistema se nombra a partir de los atributos,
pero tambin se asocia con una o ms solicitudes de cambios.
Una entrega del sistema es una versin del sistema que se distribuye a los clientes. El gestor
de entregas decide cundo se entrega el sistema, gestionar el proceso de creacin de las
entregas y de los medios de distribucin y documentacin para asegurar de recuperar la misma
forma como se distribuy.
La creacin de las entregas es el proceso de crear una coleccin de archivos y documentacin
que incluyen todos los componentes de la entrega del sistema. Esto incluye:
1. Archivos de configuracin, que define como configura el sistema para instalaciones
especficas.
2. Archivos de datos necesarios para el funcionamiento del sistema.
3. El programa de instalacin utilizado para ayudara a instalar el sistema.
4. La documentacin que describe al sistema.


5. El embalaje y la publicidad asociados diseados para esta entrega.
Las decisiones sobre cundo entregar una nueva versin del sistema estn dirigidas por varios
factores tcnicos y organizacionales.
4. HERRAMIENTAS CASE PARA GESTION DE CONFIGURACIN.
Los procesos de gestin de configuracin por lo general estn estandarizados e
involucran la aplicacin de procedimientos predefinidos. Desde los 70s se han producido un
gran nmero de diferentes herramientas que abordan diferentes reas de la gestin de
configuracin. 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 estndar. Existen muchas
herramientas comerciales y libres disponibles.
2. Entornos integrados. Estos ofrecen facilidades integradas para gestin de versiones,
construccin del sistema o seguimiento de los cambios. Ejemplo Gestin de Cambios
Unificado de Racional que incorpora ClearCase para la construccin y gestin 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.



GESTIN DE PROYECTOS DE SOFTWARE

La gestin de proyectos software es necesaria debido a que la ingeniera de software
profesional, siempre est sujeta a restricciones organizacionales de tiempo y presupuesto. Los
gestores de software son responsables de la planificacin y el desarrollo de los proyectos.
Existen diferencias entre la gestin de un proyecto cualquiera y la gestin 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 estndar. Los procesos de software varan
notablemente de una organizacin a otra. No se puede predecir con certeza cundo 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.

Interrelacin entre los elementos de un proyecto
1. ACTIVIDADES DE LA GESTIN DE PROYECTOS.
Las actividades de la gestin de proyectos difieren enormemente de organizacin en
organizacin y del producto de software a desarrollar. Sin embargo, citaremos algunas
actividades involucradas en la gestin de proyectos de software:
1. En un proyecto de software implica redactar una propuesta que describa los
objetivos del proyecto y cmo llevarlo a cabo. La redaccin de la propuesta es una
tarea crtica, no existe una gua para esta actividad, es una habilidad que se adquiere
con la experiencia.
2. La planificacin del proyecto implica identificar las actividades, los hitos y los
entregables. Realizar un plan para guiar el desarrollo hacia las metas del proyecto.


3. Estimacin de tiempos.
4. La estimacin de costos es una actividad relacionada con la estimacin de los recursos
requeridos para llevar a cabo el plan del proyecto.
5. La supervisin 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 gestin. Se
hace una revisin completa del progreso y del desarrollo tcnico del proyecto, y se
tiene en cuenta el estado del proyecto junto con los propsitos de la organizacin 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 planificacin y la estimacin 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 informacin crtica del
proyecto. Ellos debern tener la habilidad esencial de comunicarse efectivamente de forma
oral y escrita.
2. PLANIFICACIN DEL PROYECTO DE SOFTWARE.
De la completa planificacin del proyecto software depender su efectiva gestin. El
plan inicial debe ser el mejor posible de acuerdo con la informacin disponible, evolucionar
de acuerdo a cmo progrese el proyecto y sea mejor la informacin.


El proceso de planificacin se inicia con una valoracin de las restricciones que afectan al
proyecto (fecha de entrega requerida, personal disponible, presupuesto global, etc.) se lleva a
cabo en conjunto con una estimacin de los parmetros del proyecto, como su estructura,
tamao y distribucin 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 varan dependiendo del
tipo de proyecto y de la organizacin.
Muchos planes incluyen las siguientes secciones:
1. Introduccin. Describe los objetivos del proyecto y sus restricciones (presupuesto,
tiempo, etc.) que afectan a la gestin del proyecto.
2. Organizacin del proyecto. Como est organizado el equipo de desarrollo y sus roles.
3. Anlisis 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. Divisin del trabajo. Divisin del proyecto en actividades e identificacin de hitos y
productos de entrega asociados a cada actividad.
6. Calendarizacin 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 asignacin del personal.
El calendario del proyecto se representa como un conjunto de grficos que muestran la
divisin del trabajo, las dependencias de las actividades y la asignacin del personal.
La calendarizacin del tiempo para la creacin 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 informacin acerca del progreso.
Una serie de hitos (puntos finales de cada actividad bsica del proceso de desarrollo
del software con salidas asociadas) representan el fin de una etapa lgica 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 gestin.
7. Mecanismos de supervisin e informe. Supervisin del proyecto y gestin de
informes.
Microsoft Project es una herramienta de gestin de proyectos de software muy utilizada para
automatizar las actividades.
3. ORGANIZACIN DEL PROYECTO.
El personal es el activo principal en una organizacin software y representa el capital
intelectual. Una de las tareas ms importantes de los gestores de proyectos es la seleccin del
personal de un proyecto, algunos de los factores que pueden usarse son la experiencia en el


dominio de la aplicacin, la adaptabilidad y la personalidad. Es importante que el equipo
tenga el equilibrio correcto de habilidades y experiencia tcnica.
Muchas veces los proyectos de software se retrasan debido a la falta de personal calificado.
Un papel importante es el del lder del equipo, responsable de proveer la direccin tcnica y
gestin del proyecto. Los lderes 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 estndar de calidad.
2. Los miembros de un equipo trabajan juntos.
La cohesin del equipo depende de muchos factores, entre los que se encuentran la cultura
organizacional. Los miembros ms experimentados del equipo realizan el diseo de sistemas
de alto nivel, pero el diseo 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 concentrndose en su
trabajo.
4. ANALISIS DE RIESGOS.
Una tarea importante para el gestor de proyectos es anticipar los riesgos que podran
afectar a la programacin 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 organizacin.



Riesgo Descripcin
Rotacin del personal
Personal con experiencia abandona el proyecto antes de
que finalice.
Cambio de gestin
Habr un cambio de gestin organizacional con diferentes
prioridades.
Falta de disponibilidad del
hardware
El hardware esencial para el proyecto no ser entregado a
tiempo.
Cambios de requisitos Habr ms cambios en los requisitos de lo esperado.
Retrasos en la especificacin
Las especificaciones de las interfaces esenciales no
estarn a tiempo.
Subestimacin del tamao El tamao 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 tecnologa
La tecnologa fundamental sobre la que se construir el
sistema se sustituye por nueva tecnologa.

Se deben identificar y valorar los riesgos mayores del proyecto para establecer su probabilidad
y consecuencias. Estos riesgos se deben analizar de manera explcita en cada reunin. Los
resultados de la gestin de riesgos se deben documentar en un plan de gestin 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 nocin de calidad viene dada por
la similitud entre el producto desarrollado y su especificacin (Crosby, 1979).
Algunas personas piensan que la calidad puede lograrse definiendo estndares y
procedimientos organizacionales de calidad, encapsulando buenas prcticas que conlleven a
productos de alta calidad. En la prctica, ms importante es la gestin de la calidad que los
estndares.
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 gestin de la calidad del software se estructura en tres actividades principales:
1. Garanta de la calidad. Establecimiento de un marco de trabajo de procedimientos y
estndares organizacionales que conduce a software de alta calidad.
2. Planificacin de la calidad. La adaptacin de los procedimientos y estndares a un
proyecto software especfico.
3. Control de la calidad. Seguimiento de los procesos para la calidad del proyecto.
El equipo de garanta de calidad debe ser independiente del equipo de desarrollo para que
puedan tener una visin 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
Tecnologas de la Informacin. Calidad de los productos software.
Ejemplo de uso:
Validar la completitud de una definicin de requisitos;
Identificar requisitos de software;
Identificar objetivos para el diseo software;
Identificar requisitos para las pruebas del software;
Identificar requisitos para el aseguramiento de la calidad;
Identificar criterios de aceptacin para un producto software completado.
Diferentes aspectos de la calidad
INTERNA: medible a partir de las caractersticas intrnsecas, como el cdigo fuente.
EXTERNA: medible en el comportamiento del producto, como en una prueba.
EN USO: durante la utilizacin efectiva por parte del usuario.

Modelo de calidad para calidad interna y externa

FUNCIONALIDAD
Adecuacin
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 precisin.
Interoperatividad
Capacidad del producto software para interactuar con uno o ms sistemas especificados.
Seguridad de acceso
Capacidad del producto software para proteger informacin 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 recuperacin
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
cmo 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 aplicacin.
Capacidad para ser operado
Capacidad del producto software que permite al usuario operarlo y controlarlo.
Capacidad de atraccin
Capacidad del producto software para ser atractivo al usuario.
Cumplimiento de la usabilidad
Capacidad del producto software para adherirse a normas, convenciones, guas 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 modificacin 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 propsito 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 comn, compartiendo recursos comunes.
Capacidad para reemplazar
Capacidad del producto software para ser usado en lugar de otro producto software, para el
mismo propsito, 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 relacin a la efectividad alcanzada, en un contexto de uso especificado.
SEGURIDAD FISICA
Capacidad del producto software para alcanzar niveles aceptables del riesgo de hacer dao a
personas, al negocio, al software, a las propiedades o al medio ambiente en un contexto de uso
especificado.
SATISFACCIN
Capacidad del producto software para satisfacer a los usuarios en un contexto de uso
especificado.
2. CALIDAD DEL PROCESO.
Una suposicin de la gestin 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 ms creativo que mecnico, donde la experiencia y
habilidades individuales son importantes. La calidad del producto, tambin se ve afectada por
factores externos, como la presin comercial de sacar un producto rpidamente.
En el desarrollo software la relacin entre la calidad del proceso y la calidad del producto es
muy compleja, es difcil medir los atributos de calidad del software, en consecuencia, es difcil
explicar cmo influyen las caractersticas del proceso en estos atributos.
La gestin y mejora de la calidad del proceso debe minimizar los defectos en el software. La
gestin de la calidad del proceso implica:
1. Definir estndares de proceso.
2. Supervisar el proceso de desarrollo para asegurar se sigan los estndares.
3. Documentar el proceso para el gestor del proyecto.

Calidad basada en procesos


La garanta de la calidad es el proceso que define cmo lograr la calidad del software y cmo
la organizacin 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 estndares 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 estndares internacionales para cubrir la terminologa, los lenguajes de
programacin, las notaciones como smbolos en los diagramas, los procedimientos para
derivar y redactar los requisitos de software, los procedimientos de garanta de calidad y los
procesos de verificacin y validacin del software, estos estndares se aplican a una variedad
de proyectos.
Aunque por los general los ingenieros estn de acuerdo con los estndares, a menudo tienen
buenas razones que dichos estndares no sean necesarios para algn proyecto en particular.
Cada gestor de proyecto tiene la facultad de modificar los estndares de proceso de acuerdo a
circunstancias particulares.
ISO 9000-3
ISO 9001 es un estndar que se aplica en organizaciones interesadas en el proceso de calidad
de diseo, 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 estndar especfico para desarrollo de software, pero define principios
generales que pueden aplicarse al software. El estndar ISO 9001 describe varios aspectos del
proceso de calidad y define qu estndares y procedimientos deben existir en una
organizacin. Estos deben documentarse en un manual de calidad organizacional. La
definicin del proceso debe incluir una descripcin de la documentacin requerida, donde se
demuestre que los procesos definidos han sido seguidos durante el desarrollo del producto.
3. PLANIFICACIN DE LA CALIDAD.
La planificacin 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 cmo valorarlo. El plan
selecciona los estndares organizacionales para el producto y el proceso de desarrollo en
particular. Humphrey sugiere una estructura para un plan de calidad:
1. Introduccin del producto. Descripcin del producto, el mercado al que se dirige y las
expectativas de calidad.
2. Planes del producto. Fechas de terminacin del producto, responsabilidades, planes de
distribucin y el servicio.
3. Descripcin del producto. Procesos de desarrollo y administracin 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 gestin de riesgos. Riesgos que podran 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 Comprensin Portabilidad
Proteccin Experimentacin Usabilidad
Fiabilidad Adaptabilidad Reutilizacin
Flexibilidad Modularidad Eficacia
Robustez Complejidad Aprendizaje

Existe una amplia variedad de atributos de calidad del software a considerar en la
planificacin, se considerarn los ms 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 estndares de garanta de calidad en las
entregas. Existen dos enfoques:
1. Revisin de la calidad del software, de la documentacin y los procesos utilizados
en su desarrollo. Comprobacin de los estndares del proyecto y el software.
2. Valoracin automtica del software, se procesan por algn programa que comparan
los estndares, comprende una medida cuantitativa de algunos atributos del
software.
Las revisiones son el mtodo ms 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 documentacin, 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 automticas 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 mtricas 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
caractersticas de los componentes del sistema y reuniendo estas, podremos derivar
una estimacin general de algunos atributos del software y de los fallos.
2. Identificar componentes anmalos. Identificacin de los componentes fallos. Podemos
medir los componentes ms complejos.
Una mtrica de software es cualquier tipo de medida relacionada con un sistema, proceso o
documentacin de software. Una medida es calcular el tamao del producto software en lneas
de cdigo, otro sera el nmero de fallos encontrados en el producto, el nmero de personas
requeridas para el desarrollo, etc.


Las mtricas son de control o de prediccin. Las mtricas de control suelen estar asociadas
con los procesos, mientras que las mtricas de prediccin asociadas con el producto. Ejemplo
las mtricas de control o de proceso son el esfuerzo y el tiempo promedio requerido para
reparar los defectos encontrados. Ejemplo de mtricas de prediccin es el nmero de atributos
y operaciones asociadas con los objetos de un diseo.
Las mtricas de calidad del producto son de gran valor para resaltar los componentes
anmalos que tienen problemas de calidad. Estos componentes se debern analizar con ms
detalle.
Los atributos de calidad como la mantenibilidad, la comprensin y la usabilidad son
atributos externos que nos dicen cmo ven el software los desarrolladores y los usuarios. Es
necesario medir atributos internos del software (tamao) y suponer que existe una relacin
entre los atributos externos y los internos.
1. Un atributo interno debe medirse de forma precisa.
2. Debe existir una relacin entre lo que se puede medir y el atributo de comportamiento
externo.
3. Esta relacin se comprende, ha sido validad y se puede expresar en trminos de una
frmula o modelo.

Relacin entre los atributos internos y externos
Las mtricas del producto se refieren a las caractersticas del mismo software. Las mtricas
dinmicas ayudan a valorar la eficiencia y la fiabilidad de un programa. Las mtricas estticas
ayudan a valorar la complejidad, la comprensin y la mantenibilidad de un sistema de
software.
No existen mtricas de software estandarizadas y aplicables universalmente. Las
organizaciones deben seleccionar mtricas y analizar mediciones basadas en el conocimiento
y circunstancias locales.
Fiabilidad
Nmero de parmetros
del procedimiento
Complejidad ciclomtica
Tamao del programa
en lneas de cdigo
Nmero de
mensajes de error
Extensin del manual
de usuario
Mantenibilidad
Usabilidad
Portabilidad


5. MEJORA DE PROCESOS.
Muchas compaas de ingeniera 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 intrnsecamente complejos y comprenden un gran nmero de
actividades. Como los productos, los procesos tambin tienen atributos o caractersticas.

Caracterstica
del Proceso
Descripcin
Comprensin
Hasta qu punto se define completamente el proceso y cmo de
fcil es comprender su definicin?
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?
Aceptacin
El proceso definido es aceptable y utilizable por los ingenieros
responsables de producir el software?
Fiabilidad
El proceso diseado 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
Cmo de rpido se puede completar el proceso de construccin
de un sistema a partir de una especificacin dada?
Caractersticas de los procesos
No es posible hacer mejoras de procesos que optimicen todos los atributos del proceso de
forma simultnea. La mejora de proceso no significa simplemente adoptar mtodos o
herramientas particulares o utilizar algn modelo de un proceso utilizado en lugar de otro.
Aunque las organizaciones que desarrollan el mismo tipo de software claramente tienen
mucho en comn, siempre existen factores organizacionales particulares, procedimientos y
estndares que influyen en el proceso. Debe verse la mejora de procesos como una actividad
especfica de una organizacin. La mejora de procesos es una actividad cclica y tiene tres
estados principales:
1. Proceso de medicin de los atributos del proyecto actual o del producto. El objetivo es
mejorar las mediciones de acuerdo con las metas de la organizacin involucrada en el
proceso de mejora.


2. Proceso de anlisis. 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 anlisis.
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 suposicin de que la calidad del proceso de desarrollo
es crtica 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 formalizacin del proceso, igualmente de los tipos de
productos desarrollados y el tamao de la organizacin, 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 metodolgicos. Se utiliza algn mtodo de desarrollo definido. Estos
procesos se benefician de la existencia de herramientas CASE para el diseo y el
anlisis.
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 medicin
de los atributos de proceso y de producto es esencial para la mejora de procesos. Las
mediciones desempean un papel importante en la mejora de procesos de personal a pequea
escala. Las mtricas 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 Amrica. 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
compaas.
En el modelo CMMI, la mejora de procesos est basada en alcanzar un conjunto de metas
relacionadas con las buenas prcticas de la ingeniera de software y describir, analizar y
controlar las prcticas utilizadas para alcanzar estas metas. El modelo CMMI incluye prcticas
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
organizacin. CMMI tiene metas especficas asociadas a cada rea de procesos.
Tambin tiene metas genricas asociadas con la institucionalizacin de buenas
prcticas.
3. Prcticas. Son descripciones de vas para conseguir una meta. Se pueden asociar hasta
siete prcticas especficas o genricas con cada meta dentro de cada rea de procesos.

Modelo CMMI Por etapas
reas de Proceso por Niveles y Categoras


Las metas y prcticas genricas no son tcnicas, pero estn asociadas con la
institucionalizacin de las buenas prcticas, lo que significa que dependen de la madurez de la
organizacin. Por lo tanto, en una organizacin nueva que se halla en una etapa temprana del
desarrollo de la madurez; la institucionalizacin puede significar el segmento de los planes y
los procesos establecidos. Sin embargo, en una organizacin con ms madurez, procesos
avanzados, la institucionalizacin puede significar controlar los procesos utilizando tcnicas
estadsticas u otras tcnicas cuantitativas.



Controles de Lectura
LECTURA # 01
REQUISITOS: UNA INTRODUCCIN
Traduccin del artculo 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 artculo explica porqu, y
describe un acercamiento a la documentacin eficaz de
los requisitos.
La compaa Fortuna 100 emprendi un proyecto
para disear y construir un paquete de software
sofisticado que se desplegara en ltima instancia a sus oficinas a travs del mundo. Se
desarroll durante dos aos y tuvo un costo de $10 millones de dlares, ms adelante, las
oficinas del campo rechazaron utilizar el software porque no cumpla 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 compaas grandes, el 9 % de los proyectos estn a tiempo y en presupuesto.
En compaas pequeas, 16 % de proyectos estn a tiempo y en presupuesto.

Factores debilidad del Proyecto
% de
Respuesta
Carencia de informacin 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 ms grande. Si no est claro lo
que se supone construir, cmo se puede estimar el costo del edificio? Cmo puede crear un
plan del proyecto, asignar recursos, determinar los componentes del sistema en el diseo, 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 bsicos cuidadosamente
redactados proporcionan un punto de partida. Entonces, a medida que avanza el proyecto, se
puede obtener los detalles y actualizar los documentos de planificacin cuando los requisitos
evolucionan.


Qu es un requisito? Este artculo procura explicar este trmino comnmente mal entendido.
Por qu necesitamos requisitos?
Usamos los requisitos para una variedad de propsitos, incluyendo:
El alcance del proyecto
Estimar costo
Presupuesto
Planificacin del proyecto
Diseo del software
Pruebas del software
Documentacin y manuales de entrenamiento
Los individuos de una organizacin tienen un gran inters en la produccin de requisitos
slidos. Tanto si eres un cliente o ests implicado en la contratacin pblica, las finanzas y
contabilidad o de TI, usted es un actor importante en el proceso de gestin de los requisitos.
Muchos equipos de proyectos tratan los requisitos como una declaracin de propsitos para la
aplicacin y los expresan en trminos muy generales, por ejemplo: "el sistema debe tener la
capacidad de crear notificaciones de la interrupcin cuando exista un problema". Pero, es un
requisito slido? Para responder a esta pregunta, vamos a ver cmo 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
Caractersticas del software
Especificacin de requisitos de software
En mi organizacin, asociamos una media docena de atributos (por ejemplo, la prioridad,
estado, etc.) con cada requisito para ayudar con la toma de decisin, programacin, etc. La
informacin contenida en un documento nico de requisitos debe ser referenciable en los
dems. Por ejemplo, la informacin registrada en el documento de las caractersticas del
software debe apoyar y ser atribuible a uno o ms 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 declaracin: "El sistema debe ser capaz de crear notificaciones de corte de luz es
un requisito vlido. La respuesta es, "todava no". Lo que expresa esta declaracin es una
necesidad. La captura de esta necesidad es un paso hacia la formulacin de un requisito slido,
pero la declaracin no puede estar sola, primero debe traducir en una o ms caractersticas que
se captura en un documento de caracterstica del software. Estas caractersticas, a su vez, en
seguida, deber ser detallado en el documento de Especificacin de Requisitos de Software.
El uso de estos tres documentos separados ayuda a simplificar el proceso de revisin de
requisitos. Aunque un director ejecutivo podra ser un lector / aprobador de necesidades de los


interesados y los documentos Caractersticas del software, l podra delegar la responsabilidad
de lectura y aprobacin de la Especificacin de Requisitos de Software. El mantenimiento de
estos documentos especficos diferentes permite a los lectores entender las partes especficas
del sistema. Tambin promueve una mejor rendicin 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. Categora 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 despus de
cada iteracin, y si se realizan cambios en un documento debe actualizarse los dems 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 aplicacin
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 documentacin de las necesidades de los interesados implica la identificacin,
comprensin, y representan puntos de vista diferentes. A menudo, los usuarios y los
interesados no saben cmo 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 organizacin. 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. Adems, 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 tcnicas, entre
ellas reuniones, cuestionarios, guiones grficos y sesiones de Desarrollo de Aplicacin
Conjunta (JAD). Las explicaciones de estas tcnicas especficas estn fuera del alcance de este
artculo, ahora solo son aspectos importantes del proceso ser concientes de cmo hacer las
preguntas y qu formato utilizar.
Echemos un vistazo a un proyecto hipottico encaminado a simplificar la solicitud de
asistencia para una gran corporacin, el departamento de TI, vamos a usar este proyecto como
ejemplo para el resto de este artculo. 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 nmero de llamadas de apoyo a su equipo que pueda manejar un 30
por ciento, sin aumentar el nmero de empleados.
Tenga en cuenta que este requisito provee poca informacin, pero est claro que transmite lo
que quiere el cliente en un nivel alto. La ambigedad se espera que en esta etapa, se capturara
ms detalle ms adelante.
Pero no todas las necesidades que rene describirn la funcionalidad del sistema. Por ejemplo,
un interesado de finanzas pudo decir, "El presupuesto para la aplicacin inicial de la solicitud
del proyecto mesa de ayuda no pude superar los 350 mil dlares. Por supuesto, esta
necesidad perfectamente vlida podra estar en conflicto con las necesidades de otros sectores
de interesados que podran hacer que el presupuesto exceda de $350 mil dlares, la solucin
de las necesidades en conflicto es una parte normal del proceso de gestin de requisitos. Sin
embargo, en principio, usted debe centrarse en la obtencin y registro de la perspectiva de
cada uno de los interesados; la resolucin de conflictos puede venir ms adelante en el
proceso.
DOCUMENTANDO LAS CARACTERSTICAS DEL SOFTWARE
Despus de haber definido las necesidades de los interesados, debe traducir en un conjunto de
caractersticas de sistema diferentes. Cul es la diferencia entre las necesidades y las
caractersticas? Las necesidades no indican una solucin 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 caracterstica.


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 funcin. 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 caractersticas. Voy a explicar por qu en un momento. Por ahora, vamos a
definir lo que es una caracteristica.
Una caracterstica es un servicio que el sistema proporciona para satisfacer una o ms
necesidades de los interesados.
Es importante que el equipo del desarrollo entender la distincin entre las necesidades y las
caractersticas y registrarlos en documentos separados. Por qu deben separar las necesidades
de las caractersticas? Las necesidades son parte del dominio del problema, y las
caractersticas son parte del dominio de la solucin. Es de importancia crtica para
comprender plenamente el dominio del problema antes de decidirse por una solucin; a
menudo, usted encontrar oportunidades de generalizar la solucin una vez que comprender a
fondeo el problema. En otras palabras, separar las necesidades de las caractersticas, puede
encontrar un conjunto comn de caractersticas que satisfagan la necesidades mltiples. Al
igual que el documento de necesidades de los interesados, el documento Caractersticas de
software debe estar disponible para todos los miembros del equipo durante todo el proceso. Y
es importante mantener la trazabilidad de cada funcin a su necesidad correspondiente.
ID Necesidad Interesado
N1 Necesidad de notificar al administrador de
soporte cuando una peticin de soporte es
iniciado.
Administrador de Soporte
N2 Necesidad de asignar la peticin de soporte al
ingeniero de soporte apropiado
Administrador de Soporte
N3 Necesidad de mantener informado al cliente del
progreso de la peticin de soporte
Cliente (usuario)
Tabla 2. Necesidades de un Interesado

ID Caractersticas Descripcin Mapea a
F1 El sistema ser orientado al
flujo de trabajo
La peticin de soporte ir a
travs de una serie de etapas
y de asignaciones
N1, N2, N3
F2 La capacidad de notificacin
de correo electrnico
Un sistema de notificacin
de correo electrnico
centralizado que ser
utilizado por el motor de
flujo de trabajo
N1, N2, N3
Tabla 3. Caractersticas 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 ms
complejos y analticos, y otros elementos que se hacen traduciendo las necesidades en
caractersticas mucho ms difcil.
DOCUMENTANDO LOS REQUISITOS DE SOFTWARE
Despus de analizar y generalizar las necesidades y caractersticas, es el momento de
adentrarse ms en el dominio de la solucin mediante el anlisis 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, estndar, o una caracterstica
deseada.

En pocas palabras, los requisitos deben cumplir uno o ms de los siguientes criterios:
1. Las obligaciones del contrato.
2. Los estndares.
3. Las necesidades y caractersticas deseadas.
Podemos clasificar los requisitos en dos categoras: requisitos funcionales y requisitos no
funcionales.
Los requisitos funcionales presentan una descripcin completa de cmo el sistema
funcionar desde la perspectiva del usuario. Se debe permitir que todos los interesados del
negocio y los tcnicos caminen a travs del sistema y ver todos los aspectos de cmo debera
funcionar antes que sea construido.
Los requisitos no funcionales, en cambio, determinan las propiedades y estn 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 podra afirmar: "El tiempo de respuesta
de la pgina 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 Especificacin de Requisitos Software:
1. Falta de ambigedad. El equipo del desarrollo de software no ser capaz de producir
un producto que satisface las necesidades de los usuarios, si uno o ms 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 estn destinados a cambiar. Como avanza el proyecto, sin
embargo, usted debe tener su documento de la especificacin de requisitos de software
al da; cuando usted obtenga ms conocimiento sobre el sistema, el documento de la
especificacin debe ser ms completo.
3. Consistencia. No se puede construir un sistema que satisfaga todos los requisitos, si
dos requisitos estn 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 ms abstracto, o una reunin especfica con un usuario destino.
5. Ninguna informacin del diseo. Mientras que los requisitos direcciones
comportamientos externos, como vistas por usuarios o por otros sistemas de interfaz,
entonces son requisitos inmviles, sin importar su nivel del detalle. Sin embargo, si un
requisito procura especificar sub componentes particulares o sus algoritmos, estos se
convierten en informacin de diseo.
CAPTURANDO REQUISITOS FUNCIONALES
Para documentar requisitos funcionales puede capturar 3 categoras de informacin:
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 estn adoptando con rapidez los casos de uso como un medio para
comunicar los requisitos porque:
Son ms fciles de crear, leer y entender las especificaciones funcionales.
Mostrar cmo 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: Cul es el usuario que intenta llevar a
cabo mediante el sistema?
Nos obligan a definir cmo debera funcionar el sistema, paso a paso.
Proporcionan una base excelente para la creacin de casos de prueba y ayuda a
asegurar que estos estn construidos antes de que el cdigo est escrito.
Proporcionar los requisitos lenguaje comn que es fcil 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 travs de casos de uso, no dejar a los desarrolladores determinar el
comportamiento externo de la aplicacin. Especificar el formato y los detalles para la creacin
de un caso del uso va ms all del alcance de este artculo, pero es importante capturar los
casos utilizando una plantilla estndar que contiene todos los componentes de una
especificacin 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 excepcin, 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 accin especfica debe tomar el sistema en una
situacin dada. Usted puede relacionar directamente las capacidades funcionales de un caso de
uso especfico o definirlos de forma global para todo el sistema. Una capacidad funcional para
nuestro aplicacin de ejemplo podra ser: "Al crear la peticin de ayuda, llenar la" creado por
el campo con la identificacin ID de inicio de sesin del usuario".


Las reglas de negocio indican la condicin 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 estn siempre en las mentes de los interesados, y debe hacer a menudo un
esfuerzo especial de dibujarlas hacia fuera. Para hacer ms fcil capturar requisitos no
funcionales, los organizamos en cinco categoras:
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 tpico podra:
El sistema debe permitir a los usuarios novatos instalar y operar con poco o ningn
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 pgina 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 reparacin, la exactitud, y los errores aceptables. Por ejemplo:
El sistema deber cumplir los trminos 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 pginas Web deben descargarse en un plazo de tres segundos durante una
carga media, y cinco segundos durante una carga mxima.
Al ejecutar una bsqueda, el sistema debe ser capaz de mostrar 500 resultados por
pgina.
La mantenibilidad refiere a la capacidad del software de ser modificado o de ser mantenido
fcilmente para acomodar uso tpico o de escenarios de cambio. Por ejemplo, en nuestro
ejemplo, help desk, lo fcil debe ser para aadir 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
programacin adicional.
El sistema permitir que el administrador del sistema cree y llene las tablas de
impuesto para el ao 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 autentificacin del usuario se realizar a travs del inicio de sesin nico del
sistema corporativo.
Solo los administradores de la nmina autorizados se permitir acceder a la
informacin de pago de los empleados.
CONCLUSIN
En un proyecto del desarrollo del software, los requisitos conducen casi todas las actividades,
tareas, y entregables. Mediante la aplicacin 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
caractersticas y los requisitos del software y mejorar la exactitud de sus requisitos
compartiendo la responsabilidad de la revisin. Con estos documentos puede tambin
establecer trazabilidad entre las necesidades, caractersticas, y requisitos para garantizar que
su Especificacin de Requisitos Software seguir coincidiendo con los objetivos del negocio.
Es tpicamente muy costoso corregir los errores del requisito de que permanece an sin
descubrir hasta que todo el cdigo 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
ms detalladamente o para cambiar.
Recuerde: Cuando rena a los interesados, pregunte sobre las consideraciones no funcionales
as como los requisitos de la funcionalidad especfica. Y tenga siempre presente que los
requisitos slidos son lo ms importante para producir software til y de alta calidad.


LECTURA # 02
WORKFLOW DE REQUISITOS
EN RUP

Este artculo describe conceptos importantes necesarios para capturar y gestionar los
requisitos del sistema eficientemente y disear las interfaces de usuario enfocadas en las
necesidades y objetivos de los usuarios, as como de los otros stakeholders importantes. Se
incluye una descripcin breve del workflow de requisitos del RUP.
Propsito
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 cmo?
Proporcionar a los desarrolladores del sistema un mejor entendimiento de los
requisitos de sistema.
Definir los lmite del sistema (delimitar).
Proporcionar una base para planear el contenido tcnico 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 cmo definir una visin del sistema y trasladar la visin
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 cmo 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 condicin o capacidad que puede conformar un sistema.
En su esfuerzo por establecer un criterio de calidad como una base como mtricas para la
evaluacin de los sistemas de software, Robert Grady, durante su estada 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 acrnimo 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. Despus de todo, los desarrolladores tenemos
una diagonal para la accin. Expresamos estas acciones como funcin 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 tambin exhibir una variedad de atributos que no estn descritas
especficamente 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 categoras 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 documentacin 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 transaccin, velocidad, disponibilidad, tiempo
de respuesta, tiempo de recuperacin, o demora usada con el cual una accin dada puede ser
ejecutada.
Mantenibilidad
Los requisitos de mantenibilidad tratan las pruebas, el mantenimiento, y otras cualidades
requeridas para tener el sistema al da despus de un cambio de versin. 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 cdigo estndar C++ especfico.
No es importante dividir los requisitos en estas categoras, y existe un debate alrededor si un
requisito especfico es un requisito de usabilidad o mantenibilidad. El valor de estas
definiciones es que dan una plantilla, o una lista de comprobacin, para la elicitacin de los
requisitos y para determinar lo completo de tu comprensin. Es decir, si entiendes los
requisitos de todas estas categoras, tendrs un grado de certeza de haber entendido los
requisitos crticos antes de que comiencen la inversin substancial en el desarrollo. Se
encontrar a menudo, por ejemplo, que ciertos requisitos de confiabilidad estn 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 explcita.
TIPOS DE REQUISITOS
Tradicionalmente, los requisitos son vistos como especificaciones textuales detalladas que
se ajusta a una de las categoras mencionadas, expresadas en la forma El sistema tendr que
. . Gestionar efectivamente el proceso de requisitos completo, sin embargo, es provechoso
ganar una comprensin 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 tambin necesario para operar en 99.3 % de
exactitud mientras la rutina de mantenimiento general?) as como permitir compensaciones y
decisiones de diseo 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 organizacin que tiene un intereses concedido
en el resultado de un proyecto.
Un stakeholder es el usuario final, pero se consideran adems 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
econmico del sistema.
Usando esta definicin, es obvio que el grupo de desarrollo pueda entender las necesidades
especficas de los stakeholders claves del sistema. Pero cmo 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 travs 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 estn como una
necesidad. Por ejemplo:
Yo necesito la manera ms fcil 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 crtico para los requisitos del producto. Este
ingreso provee una pieza crucial del rompecabezas que permite determinar los porqus y los
qus del comportamiento del sistema.


CARACTERSTICAS DEL SISTEMA
Cuando se entrevista a los stakeholders sobre sus necesidades y requisitos , ellos tpicamente
su necesidad real (ejemplo:
Si Joe y yo no iniciamos mejor la comunicacin, nuestro trabajo estar en riesgo
Yo deseo permitir enviar un archivo RTF en un mensaje e-mail
El vehculo tienen un sistema de control por computadora dedicado a cada .
Ellos a menudo describen una abstraccin (ejemplo, Yo deseo automatizar una notificacin
por e-mail o Yo deseo un vehculo con ABS).
Llamamos a este tipo de abstraccin de alto nivel de expresin del comportamiento del
sistema- como caractersticas del sistema.
Tcnicamente, podemos pensar de una caracterstica como un servicio a ser provisto por
el sistema que directamente satisface una necesidad de usuario. A menudo estas
caractersticas no estn bien definidas, y ellas pueden entrar en conflicto. Ejemplo: Yo deseo
ABS y Yo deseo requisitos de mantenimiento ms bajos, pero no obstante ellos son una
representacin de las necesidades reales. Que es suceso en esta discusin es que el stakeholder
tiene ya trasladada la necesidad real (mejor comunicacin con Joe) en un comportamiento
del sistema (notificacin automtica e-mail). Al obrar as, all tiene ser un sutil cambio en el
pensamiento de los stakeholders desde el qu mejor comunicacin al cmo eso es, ahora
implementado (notificacin automatizada e-mail).
Discutir estas caractersticas en lenguaje natural, documentar y comunicar esto, adiciona
un contexto importante al workflow de requisitos. Adicionar a estas caractersticas 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 inversin substancial que tiene que ser hecha en caractersticas de menor prioridad.
Es adecuado comunicar a los desarrolladores exactamente qu es lo que el sistema debe hacer
Hey, manda la cuenta, ir el cdigo un sistema automtico de la notificacin del e-mail.
Necesita un nivel adicional de especificacin para traducir esta necesidad y caractersticas
a las especificaciones que puede disear, poner en ejecucin, y probar determinar la
conformidad del sistema. En este nivel de la especificacin, 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 tcnica potente que puede usarse para expresar
el comportamiento detallado del sistema va simple de interacciones usuario-sistema que los
usuarios y los desarrolladores pueden entender fcilmente.
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 interactan 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 ms detallado.

CAPTURANDO Y GESTIONANDO REQUISITOS


Para cada proyecto puede haber una estructura comn de requisitos, como se muestra en la
Figura. Primero, recoge las necesidades de los stakeholders, se traducen en caractersticas y
posteriormente en una lista de requisitos extrados de los usuarios finales, clientes,
comercializadores, y otros stakeholders del proyecto.

Tipos de requisitos y relaciones con los artefactos
El documento visin contiene el conjunto de necesidades de los usuarios y stakeholders
claves y las caractersticas de alto nivel del sistema. Estas caractersticas 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
caractersticas en el documento visin basadas en un anlisis de costos de implementacin por
cada caracterstica deseada y la determinacin del retorno en esta inversin.
Antes de iniciar la codificacin, trasladar estas caractersticas en requisitos de software
detallados en un nivel en el cual se pueda disear 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 caractersticas del sistema para medir que se interprete la visin
correctamente. Esta consideracin de caractersticas y requisitos de software implica una
relacin de trazabilidad donde los requisitos del software son derivados de uno o ms
caractersticas del sistema, los cuales satisfagan las necesidades de los stakeholders.


Los requisitos detallados se muestran en el modelo de diseo y la documentacin del usuario
final y son verificados por un modelo de prueba.
A travs del ciclo de vida de desarrollo del proyecto, puede utilizar estas caractersticas,
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 visin. As, el
workflow de requisitos se repite de una manera iterativa hasta que todos los requisitos estn
definidos, es considerado la retroalimentacin y son gestionados los cambios inevitables.
DISEANDO UNA INTERFAZ CENTRADO EN EL USUARIO
La expresin de diseo 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 diseo de una interfaz de usuario en trminos de clases de diseo (y componentes
tales como clases ActiveX y JavaBeans) que se relacione a otras clases de diseo que
trata con la lgica de negocio, persistencia, y as sucesivamente, y conducir a la
implementacin final de la interfaz de usuario.
En el workflow de requisitos, operamos sobre la primera definicin, enfocado en la
realizacin de un diseo centrado en el usuario. Los perfiles de usuario y ambientes de
usuario estn especificados en el documento visin, con la principal entrada al diseo 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 caractersticas del
usuario y las realizaciones de las partes especficas 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 regeneracin 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
Declaracin del problema que estamos intentando solucionar; identificacin de los
stakeholders; los lmites y los apremios del sistema.
Entender las necesidades de los stakeholders
Usando varias tcnicas de elicitacin 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 caractersticas 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 caractersticas son derivadas; identificando los actores y los casos de
uso necesarios para cada caracterstica clave.


Gestionar el alcance del sistema
Coleccionar la informacin importante de los stakeholders en el proyecto y administrar esto
junto con los requisitos, los atributos de los requisitos que se utilizarn en dar la prioridad y
el alcance del sistema que se puede derivar en tiempo y en presupuesto.
Refinar la definicin 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 diseo 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 sern 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 elicitacin 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.
Diseador de la interfaz usuario
El diseador 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 Diseador 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 tambin identifican los requisitos no funcionales. El analista de
sistemas puede entonces desarrollar la visin del proyecto. Esta visin, expresada como un
conjunto de caractersticas escritas desde la perspectiva de los stakeholders, bsico 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 diseador de la interfaz de usuario trabaja en paralelo con el especificador de caso de uso
para definir la interfaz del usuario del sistema. En ms casos, existe una interaccin sinrgica
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 propsitos diferentes, ellos ejecutan varias veces la revisin en el workflow
de requisitos por los revisores de requisitos con perfiles diferentes.
Los individuos actan como workers de un equipo que ejercita el workflow de requisitos
iterativamente a travs del ciclo de vida del proyecto.
ARTEFACTOS USADOS EN REQUISITOS
Al considerar los requisitos, es importante, primero que todo, entender la definicin 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 informacin en la cual cada requisito tiene que ser considerado para el proyecto.


Las necesidades y caractersticas claves estn identificadas en el documento visin, 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 informacin importante (en suma a los
requisitos del sistema).
El documento visin da una visin completa del sistema a desarrollar y soporta el contrato
entre la autoridad y la organizacin. El documento visin se escribe desde las perspectivas
de los clientes, enfocando en l las caractersticas esenciales del sistema y los niveles
aceptables de calidad. Especifica tambin las capacidades operacionales (volumen, tiempo
de respuesta, etc.), los perfiles de usuario y las interfaces interoperacionales con entidades del
otro lado del lmite del sistema, donde sea aplicable. El documento visin proporciona la
base contractual para los requisitos visible a los stakeholders.
El modelo de caso de uso sirve como un medio de comunicacin 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 interacta con los actores, y
qu har el sistema en el caso de uso. Los casos de uso funcionan uniendo a travs del ciclo de
vida del software; el modelo de caso de uso es usado en el anlisis de sistema, diseo,
implementacin 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 Especificacin de Requisitos de Software completa.
Una completa definicin de los requisitos de software, son descritas en los casos de uso y las
especificaciones suplementarias, puede ser empaquetado para definir una Especificacin de
Requisito de Software (SRS) para el producto completo, una caracterstica particular, u otro
subsistema agrupado.
Complementariamente a los artefactos mencionados, los siguientes artefactos son tambin
desarrollados:
Glosario
Storyboard de caso de uso
Prototipo de la interfaz de usuario
El glosario define una terminologa comn usada consistentemente a travs del proyecto u
organizacin.
Los usuarios actuales y potenciales del sistema estn envueltos en el modelado y definicin 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 gestin 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 automtico para los actores y casos de usos en el modelo de caso de uso (con
integracin automtica para RequisitePro para gestionar sus propiedades textuales, atributos
de requisitos y trazabilidad), con Storyboards de los casos de uso y las clases lmites.
Teniendo los artefactos de requisitos en Rose tambin permite mantener dependencias de
elementos en el modelo de diseo.
Rational SODA ayuda automticamente a la generacin de la documentacin. Esto
permite definir un plantilla inteligente que puede extraer informacin desde diferentes
fuentes. Rational SODA es particularmente usado si usa diferentes herramientas para capturar
los resultados de sus workflow, pero puede producir la documentacin final junto con esta
informacin en un lugar.
RESUMEN
La gestin 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
caractersticas de alto nivel, as como los requisitos funcionales y no funcionales con
ms 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 travs
del ciclo de vida del proyecto.
El diseo 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 gestin de
requisitos, sus atributos y la trazabilidad.


Glosario

Abstraccin
La creacin de una visin o modelo que suprime los detalles innecesarios para centrarse en un
conjunto de datos de inters.

Ada
Lenguaje de programacin que fue desarrollado por el Departamento de Defensa de los
Estados Unidos como un lenguaje estndar para el desarrollo de software militar. Est basado
en las investigaciones de los lenguajes de programacin desde los 70s e incluye
construcciones as como tipos de datos abstractos y soporte para concurrencia. Todava se
utiliza en grandes sistemas aeroespaciales militares complejos.

Anlisis
Parte del proceso de desarrollo de software cuyo objetivo principal es formular un modelo del
dominio del problema. El anlisis se centra en qu hacer, el diseo se centra en cmo hacerlo.

Anlisis esttico
Anlisis basado en herramientas del cdigo fuente de un programa para descubrir errores y
anomalas. Las anomalas como las asignaciones sucesivas a una variable sin un uso
intermedio pueden ser errores de programacin.

Anlisis & diseo
Actividades durante la cual se toman decisiones estratgicas y tcticas 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 arquitectnico 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 mltiples servidores.

Arquitectura de referencia
Arquitectura genrica del sistema que es una arquitectura ideal que incluye todas las
caractersticas que los sistemas podran incorporar. Constituye un modo de informar a los
diseadores sobre la estructura general de esa clase de sistemas.

Arquitectura de software
De acuerdo a IEEE, la arquitectura de un sistema software es la organizacin o estructura de
los componentes importantes que interactan a travs de interfaces, los componentes que se
compone de componentes ms pequeos 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 mltiples, incluyendo un modelo, un elemento del modelo, o
un documento.

Aseguramiento de la calidad (QA)
Proceso general de definir cmo lograr la calidad del software y cmo la organizacin de
desarrollo conoce el nivel de calidad requerido en el software.

C
Lenguaje de programacin que fue originalmente desarrollado para ayudar a implementar el
sistema Unix. C es un lenguaje de implementacin de sistemas de relativamente bajo nivel que
permite el acceso al hardware del sistema y que puede ser compilado a un cdigo eficiente.
Todava se utiliza ampliamente para la programacin de sistemas de bajo nivel.

C++
Lenguaje de programacin orientado a objetos. C es un subconjunto de C++.

CASE
Ingeniera de software asistido por computador. El proceso de desarrollo de software usa
soporte automatizado.

Cpsula
Patrn de diseo especfico que representa un hilo de encapsulamiento de control en el
sistema. Una cpsula es una clase de estereotipo con un conjunto especfico de necesidades y
restricciones de las asociaciones y las propiedades.

Caso de uso
Especificacin de un tipo de interaccin con un sistema.

CBSE Ingeniera de Software Basado en Componentes
Desarrollo de software para la independiente composicin, componentes desplegable.

Ciclo de vida del software
Utilizado a menudo con otro nombre para el proceso del software. Originalmente acuado
para referirse al modelo en cascada del proceso software.

Clase del anlisis
Abstraccin del rol jugado por un elemento del diseon en el sistema, tpicamente en el
contexto de la realizacin de caso de uso. Las clases del anlisis proporcionan una abstraccin
para varias funciones, lo que representa el comportamiento comn de roles. Anlisis de las
clases suelen convertirse en uno o ms elementos del diseo, por ejemplo, clases de diseo y
/o cpsulas o subsistemas de diseo.


Clase abstracta
Una clase que proporciona un comportamiento comn a travs de un conjunto de subclases
pero no es diseado 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 ejecucin mediante la instanciacin de la definicin 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 ingeniera de software.

Cdigo de tica y prctica 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 ttulos:
pblico, cliente y empleador, producto, juicio, gestin, colegas, profesin y personal.

COM+
Un modelo de componentes diseado para su uso en plataformas Microsoft.

CORBA Common Request Broker Architecture
Conjunto de estndares 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 travs 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 proteccin y otros atributos. La confiabilidad de un
sistema refleja el grado en el cual los usuarios pueden confiar en el sistema.

Construccin del sistema
Proceso de compilar los componentes o unidades que forman un sistema y enlazarlos con
otros componentes para crear un programa ejecutable. La construccin del sistema est
normalmente automatizada de modo que se minimiza la recompilacin. Esta automatizacin
puede ser incorporada a un sistema de procesamiento de lenguajes (como en Java) o puede
implicar herramientas CASE para apoyar la construccin del sistema.



COCOMO Constructive Cost modeling.
Quizs el modelo algortmico de estimacin de costos ms conocido.

Control de calidad (QC)
Proceso de asegurar que el equipo de desarrollo de software sigue los estndares 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 implementacin 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 especificacin,
diseo, programacin 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
especificacin, diseo y desarrollo.

Diagrama de secuencia
Diagrama que muestra la secuencia de interacciones necesarias para completar alguna
operacin. En UML, los diagramas de secuencia se pueden asociar con los casos de uso.

Diseo de la interfaz de usuario
Proceso de disear el modo en el que los usuarios del sistema acceden a la funcionalidad del
sistema y la forma en la que se visualiza la informacin producida por el.

Disponibilidad
Preparacin de un sistema para entregar servicios cuando se le soliciten. La disponibilidad es
normalmente expresada como un nmero 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 especfico donde son utilizados los sistemas software. Ejemplos
de dominios son el control en tiempo real, el procesamiento de datos de negocio y la
conmutacin telecomunicaciones.

Elemento de configuracin
Unidad legible por la mquina, como un documento o un archivo de cdigo fuente, que es
susceptible de cambiar y donde los cambios tienen que se controlados por un sistema de
gestin de configuracin.


EJB (Enterprise J ava Beans)
Modelo de componentes basado en Java.

Escenario
Descripcin de una forma tpica en el cual un sistema es usado o un usuarios carried out
alguna actividad.

Especificacin formal, algebraica
Mtodo de especificacin matemtica de sistemas en el que un sistema o componente se
especifica definiendo las relaciones entre las operaciones definidas en sus interfaces externas.

Especificacin formal, basada en modelos
Mtodo de especificacin matemtica 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.

Etnografa
Tcnica basada en la observacin que puede ser utilizada en la obtencin y anlisis de
requisitos. El etngrafo se sumerge en el entorno del usuario y observa sus hbitos 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 comn y una
funcionalidad genrica. stos se pueden adaptar a las necesidades especficas de los clientes
modificando componentes y parmetros 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 especificacin abstracta de alto nivel. El
generador incorpora conocimientos que es reutilizan en cada actividad de generacin.

Gestin de configuracin
Proceso de gestionar los cambios a un producto software que se desarrolla. La gestin de la
configuracin implica la planificacin de la configuracin, la gestin de versiones, la
construccin del sistema y la gestin de cambio.

Gestin de requisitos
Proceso de gestin de cambios de requisitos para asegurar que los cambios efectuados son
correctamente analizados e implementados en el sistema.



Gestin 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 diseo o un depurador de programa, utilizada
para apoyar una actividad en el proceso de desarrollo de software.

Ingeniera de sistemas
Proceso que trata de la especificacin de un sistema, la integracin de sus componentes y
pruebas de que el sistema cumple sus requisitos. La ingeniera sistemas no solo trata el
sistema software, sino el sistema socio-tcnico completo: software, hardware y procesos
operativos.

Inspeccin de programa
Proceso de verificacin en el que un grupo de revisores examina un programa, lnea por lnea,
con el objetivo de detectar errores de programa.

Interfaz
Especificacin 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 Programacin de Aplicaciones (API)
Interface, generalmente especializada como un conjunto de operaciones, definida por un
programa de aplicacin que permite acceder a la funcionalidad del programa. Esto significa
que no slo se puede acceder a esta funcionalidad a travs de la interfaz de usuario, sino que
otros programas pueden utilizarla directamente.

ISO 9000
Estndar para los procesos de gestin de calidad definido por la Organizacin Internacional de
Normalizacin (ISO).

Java
Lenguaje de programacin orientado a objetos que fue diseado por Sun con el objetivo de la
independencia de la plataforma.

Mantenimiento
Proceso de hacer cambios en un sistema despus de que est en funcionamiento.

Marco de trabajo de aplicaciones
Estructura genrica en algn dominio especfico 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
aplicacin.



Mejora de proceso
Proceso de hacer cambios a un proceso con el objetivo de hacerlo ms previsible o mejorar la
calidad de sus salidas. Por ejemplo, si su objetivo es reducir el nmero de defectos en el
software entregado, podra mejorar el proceso aadiendo nuevas actividades de validacin..

Mtodo estructurado
Mtodo de diseo 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
diseo.

Mtodos giles
Mtodos de desarrollo de software dirigidos a la entrega rpida del mismo. El software se
desarrolla y entrega en incrementos, y se minimiza el proceso de documentacin y la
burocracia.

Mtodos formales
Mtodos de desarrollo de software basados en enfoques matemticamente rigurosos que
modelan el software utilizando construcciones matemticas formales como predicados y
conjuntos.

Mtrica software
Atributo de un sistema software o proceso que puede medir o expresar numricamente. Las
mtricas de procesos son atributos del proceso como el tiempo necesario para completar uan
tarea; las mtricas de productos son atributos del software mismo como el tamao o
complejidad.

Modelo de componentes CORBA
Modelo de componentes diseado por su uso para plataformas CORBA.

Modelo de componentes
Conjunto de estndares para la implementacin, documentacin y utilizacin de componentes.
stos cubren las interfaces especficas que pueden ser proporcionadas por un componente, el
nombrado de componentes, la interoperavidad de los componentes y composicin de stos.
Los modelos de componente proporcionan la base para middleware para soportar la operacin
de componentes.

Modelo de madurez de proceso
Modelo del grado en el que un proceso incluye buenas prcticas y capacidades de medida y
reflexivas que estn 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
Representacin 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 anlisis
Modelo objeto que sirve como una abstraccin del modelo de diseo, proporciona la
definicin inicial de la realizacin de los casos de uso.

Modelo del dominio
Definicin de abstracciones del dominio como polticas, 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: especificacin, diseo,
implementacin, pruebas y mantenimiento. En principio, se debe completar una etapa antes de
que se pueda avanzar a la siguiente. En la prctica, existe iteracin 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 compaas formado para desarrollar estndares para el desarrollo orientado a
objetos. Ejemplos de estndares promovidos por OMG son CORBA, UML y MDA.

Patrn de diseo
Solucin probada a un problema comn que capta las experiencias y buenas prcticas de una
forma que puede ser reutilizada. Es una representacin 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 estndares para productos y procesos y definir los atributos de la
calidad requeridos del sistema.

Principios de diseo de interfaz de usuario
Conjunto de principios que expresan buenas prcticas para el diseo de interfaz de usuario.



Proceso de negocio
Conjunto de actividades relacionadas con el uso de recursos de la organizacin para
proporcionar resultados definidos en apoyo de los objetivos de la organizacin. 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 cmo
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 evolucin de un
sistema software.

Programacin extrema
Mtodo gil de desarrollo de software que incluye prcticas como los requisitos basados en
escenarios, el desarrollo previamente probado y la programacin 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 rpida de ste. A menudo implica el
uso de la programacin de bases de datos y herramientas de apoyo al desarrollo como los
generadores de informes y pantallas.

Regla de negocio
Declaracin de la poltica o condicin que debe cumplirse dentro de la empresa. Las reglas de
negocio pueden ser capturadas en los modelos, en los documentos o ambos.

Reingeniera
Modificacin de un sistema software para hacerlo ms fcil de comprender y cambiar. La
reingeniera a menudo implica reestructuracin y organizacin de datos y software, la
simplificacin de programas y re-documentacin.

Reingeniera, proceso de negocio
Cambio de un proceso de negocio para cumplir algn objetivo organizacional nuevo como la
reduccin de costos y la ejecucin ms rpida.

Release
Versin de un sistema software que est disponible para clientes del sistema.

Requisito funcional
Declaracin de alguna funcin o caracterstica que se debe implementar en un sistema.



Requisito no funcional
Declaracin de una restriccin o comportamiento esperado que se aplica a un sistema. Esta
restriccin 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 algn 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 genrico que presenta el desarrollo del software como una
actividad iterativa de cuatro fases que son: inicio, elaboracin, construccin y transicin. La
fase de inicio establece un caso de negocio para el sistema, la fase de elaboracin define la
arquitectura, la de construccin implementa el sistema y la de transicin utiliza el sistema en
el entorno del cliente.

Seguridad
Capacidad de un sistema para funcionar sin fallos de funcionamiento catastrficos.

Servicio Web
Componente software independiente al que se puede acceder a travs de Internet utilizando
protocolos estndares. SOAP (Simple Object Access Protocol) se utiliza para el intercambio
de informacin en servicios web. WSDL (Web Service Definition Language) se utiliza para
definir las interfaces de servicio web.

Servidor
Programa que proporciona algn servicio a otros programas (cliente).

Sistema crtico
Sistema informtico cuyo fallo de funcionamiento puede causar importantes prdidas
econmicas, 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
correccin del sistema no slo depende de lo que hace sino tambin 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 propsito 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 cdigo fuente de un programa a cdigo 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 transaccin 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-tcnico que es til o fundamental para una organizacin, pero que ha sido
desarrollado utilizando tecnologa o mtodos obsoletos. Debido a que los sistemas heredados a
menudo llevan a cabo funciones de negocio crticas, tienen que ser mantenidos.

Sistema socio-tcnico
Sistema que incluye componentes hardware y software, que ha definido los procesos
operativos seguidos por los operadores humanos y que funciona dentro de una organizacin.
Por lo tanto, est influido por las polticas, procedimientos y estructuras de la organizacin.

SQL (Structured Query Language)
Lenguaje estndar utilizado para la programacin de bases de datos relacionales.

Tipo abstracto de datos
Tipo cuya representacin se oculta y est definido por sus operaciones.

Transaccin
Unidad de interaccin con un sistema informtico. Las transacciones son independientes y
atmicos (no se pueden dividir en unidades ms pequeas) y son una unidad fundamental de
recuperacin, consistencia y concurrencia.

UML (Unified Modeling Language)
Lenguaje grfico 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 estndar de facto para el modelado orientado a objetos.

Validacin
Proceso de verificar que un sistema cumple las necesidades y expectativas del cliente.

Verificacin
El proceso de verifica que un sistema cumple su especificacin.


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 informacin 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 especificacin 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 gua 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


Procesos del Ciclo de Vida del Software. 2004.

[PRE02] PRESSMAN, Roger
INGENIERA DE SOFTWARE: UN ENFOQUE PRCTICO. Quinta Edicin,
McGrawHill Companies. 2002.
[RUP00] RUP
RATIONAL UNIFIED PROCESS.

[SEI00] SEI SOFTWARE ENGINEERING INSTITUE CARNEGIE MELLON
CAPABILITY MATURITY MODEL INTEGRATION (CMMI)
Versin 1.1 CMMI for Software Engineering.

[SCO04] SCOTT, McEWEN
REQUIREMENTS: AN INTRODUCTION. Metasys Technologies Inc. 2004.

[SOM05] SOMMERVILLE, Ian
INGENIERIA DEL SOFTWARE.
7a. Edicin. Pearson Addison Wesley. 2005.

Manual de Ingeniería de Software

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Manual de Ingeniería de Software

Încărcat de

Drepturi de autor:

Formate disponibile

Facultad de

S-ar putea să vă placă și