RESUMEN ANÁLISIS DE SISTEMAS

SOMMERVILLE:
CAPITULO 1
¿Qué es el Software? Programas de ordenador y la documentación asociada. Los
productos de software se pueden desarrollar para algún cliente en particular o para un
mercado general.
¿Qué es la ingeniería del software? Es una disciplina de la ingeniería que comprende
todos los aspectos de la producción de software. La ciencia de la computación
comprende la teoría y los fundamentos; la ingeniería de software comprende las
formas prácticas para desarrollar y entregar un software útil. La ingeniería de sistemas
se refiere a todos los aspectos del desarrollo de sistemas informáticos, incluyendo
hardware, software e ingeniería de procesos.
¿Qué es un modelo de procesos de software? Una representación simplificada de un
proceso de software, presentada desde una perspectiva especifica.
¿Cuáles son los costos de la ingeniería del software? A grandes rasgos, el 60% de los
costos son de desarrollo, el 40% restante son de pruebas en el caso de software
personalizado, los costos de evolución a menudo excedes los de desarrollo.
¿Qué son los métodos de la ingeniería de software? Enfoques estructurados para el
desarrollo de software que incluyendo modelos de sistemas, notación, reglas,
sugerencias de diseño y guías de procesos.
Descripciones del modelo del sistema: Y la notación utilizada para definir estos
modelos. Modelos de objetos, de flujo de datos, de máquina de estado, etc.
Reglas: Restricciones que siempre aplican a los modelos de sistemas. Cada entidad
de un modelo de sistema debe tener un nombre único.
Recomendaciones: Heurística que caracteriza una buena práctica de diseño en este
método. Seguir estas recomendaciones debe dar como resultado un modelo de
sistema bien organizado. Ningún objeto debe tener más de siete subobjétos asociados
a él.
¿Qué es CASE? Sistemas de software que intentan proporcionar ayuda automatizada
a las actividades del proceso de software. Los sistemas CASE a menudo se utilizan
como apoyo al método.
¿Cuáles son los atributos de un buen software? El software debe tener la
funcionalidad y el rendimiento requeridos por el usuario, además de ser mantenible,
confiable y fácil de usar.
Mantenibilidad: El software debe escribirse de tal forma que pueda evolucionar para
cumplir las necesidades de cambio de los clientes. Éste es un atributo crítico debido a
que el cambio en el software es una consecuencia inevitable en el entorno de
negocios.
Confiabilidad: La confiabilidad del software tiene un gran número de características,
incluyendo la fiabilidad de protección y seguridad. El software confiable no debe
causar daños físicos o económicos en el caso de una falla del sistema.
Eficiencia: El software no debe hacer que se malgasten los recursos del sistema, como
la memoria y los ciclos de procesamiento. Por lo tanto, la eficiencia incluye tiempos de
respuesta y de procesamiento utilizado en la memoria, etcétera.
Usabilidad: el software debe ser fácil de utilizar sin esfuerzo adicional por el usuario
para quien está destinado. Esto significa que debe tener una interfaz de usuario
apropiada y una documentación adecuada.
¿Cuáles son los retos fundamentales a los que se enfrenta la ingeniería de software?
Enfrentarse con la creciente diversidad, las demandas para reducir los tiempos de
entrega y el desarrollo de software fiable.
El reto de la heterogeneidad: es desarrollar software flexible que opere en sistemas
distribuidos e integrar software nuevo que opere con sistemas heredados más viejos.
El reto de la entrega: Reducir los tiempos de entrega para sistemas grandes y
complejos sin comprometer la calidad del sistema.

CAPITULO 2
Un sistema es una colección de componentes interrelacionados que trabajan
conjuntamente para cumplir algún objetivo.
Sistemas técnicos informáticos: Son sistemas que incluyen hardware y software, pero
no procedimientos y procesos, se utilizan para algún fin, pero este fin no es parte del
sistema. Televisiones, teléfonos móviles y PC personales.
Sistemas socio.-técnicos: comprenden uno o más sistemas técnicos, incluyen
conocimiento de cómo debe usarse para alcanzar un objetivo más amplio.
_Tienen propiedades emergentes que son propiedades del sistema como un todo más
que asociadas con partes individuales del sistema.
_Son a menudo no deterministas. Significa que cuando se presentan con una entrada
específica no siempre producen la misma salida.
_El grado en que apoya a los objetivos organizacionales no solo depende del sistema
mismo, sino también de la estabilidad de estos objetivos, de las relaciones y conflictos
organizacionales.
Propiedades emergentes funcionales: aparecen cuando todas las partes de un sistema
trabajan de forma conjunta para cumplir algún objetivo.
Propiedades emergentes no funcionales: se refiere al comportamiento de los sistemas
en su entorno operativo.
Ingeniería de sistemas: es la actividad de especificar, diseñar, implementar, validar,
utilizar y mantener los sistemas socio-técnicos.
Diferencia con la ingeniería de desarrollo de software:
_Alcance limitado para rehacer el trabajo durante el desarrollo de sistemas. Una vez
que se han tomado decisiones en la ingeniera del sistema cuesta mucho trabajo
cambiarlas. En cambio el software permite cambios que se hace durante el desarrollo
del sistema como respuesta a nuevos requerimientos.
_implicación interdisciplinaria: Muchas disciplinas de la ingeniería se conjuntan e la
ingeniería de sistemas.
*Definición de requerimientos del sistema: Especifican que es lo que el sistema debe
hacer y sus propiedades esenciales y deseables:
__Requerimientos funcionales abstractos: Las funciones básicas que el sistema debe
proporcionar se definen en un nivel abstracto. Tiene lugar en el nivel de subsistemas.
__Propiedades del sistema: Son propiedades emergentes no funcionales del sistema,
como disponibilidad, el rendimiento y la seguridad.
__Características que no debe mostrar el sistema: Es importante especificar lo que el
sistema no debe hacer.
*Diseño del sistema: Se centra en proporcionar la funcionalidad del sistema a través
de sus diferentes componentes.
__Dividir requerimientos: Analice los requerimientos y organícelos en grupos afines.
__identificar subsistemas: Que pueden individual o colectivamente cumplir los
requerimientos.
__Asignar requerimientos a los subsistemas: Esto debe ser sencillo si la división de
requerimientos se utiliza para la identificación de subsistemas.
___Especificar funcionalidad de los subsistemas: Enumerar las funciones específicas
asignadas a cada subsistema. Especificar relaciones.
__Definir las interfaces del subsistema: Defina las interfaces necesarias y requeridas
por cada subsistema.
*Desarrollo de los subsistemas: Se implementan los que se hayan identificado durante
el diseño del sistema. Implica otro proceso de la ingeniería de sistemas para los
subsistemas individuales. Es común que los subsistemas se desarrollen en paralelo. A
menudo se deben realizar revisiones de trabajo con el fin de detectar los problemas.
*integración del sistema: Se toman los subsistemas desarrollados de forma
independiente y se conjuntan para crear el sistema completo. Puede hacerse
utilizando el enfoque big bang, que consiste en integrar todos los subsistemas al
mismo tiempo. Por otro lado se tiene un enfoque de integración creciente:
__Es imposible confeccionar una agenda para el desarrollo de todos los subsistemas
de tal forma que todos terminen al mismo tiempo.
__Reduce el costo en la localización de errores. Si varios subsistemas se integran
simultáneamente, un error que surja durante las pruebas puede estar en cualquiera de
estos subsistemas.
*Evolución del sistema: Los sistemas y complejos tienen un periodo de vida largo,
durante su vida se realizan distintos tipos de cambios para adaptar al sistema o para
mejorarlo:
__Los cambios propuestos tienen que analizarse cuidadosamente desde perspectivas
técnicas y de negocio.
__Los cambios en un subsistema pueden afectar de forma adversa al funcionamiento
o comportamiento de otro.
__A menudo no se registran las razones del diseño original. Los responsables de la
evolución del sistema tienen que resolver por que se tomaron decisiones particulares.
__Al tiempo su estructura se corrompe por el cambio de tal forma que se incrementan
los costos de cambio adicionales.
*Desmantelamiento del sistema: Significa poner fuera de servicio a dicho sistema
después de que termina su periodo de utilidad operativa. Hardware desmontaje y
reciclaje, algún software se puede incorporar en un sistema para ayudar al proceso de
desmantelamiento.
Procesos Organizacionales: El proceso de desarrollo no es el único proceso implicado
en la ingeniería de sistemas, este se relaciona con el proceso de adquisición del
sistema y con el proceso de uso y operaciones del sistema. El proceso de adquisición
normalmente esta contenido dentro de la organización que comprar y usara el sistema:
_Comúnmente los componentes comerciales no cumplen de forma exacta los
requerimientos, a menos que estos se hayan escrito teniendo en cuenta dichos
componentes.
_Cuando el sistema se construye de forma especial, la especificación de
requerimientos actúa como la base de un contrato para la adquisición del sistema.
_una vez que se ha seleccionado un contratista para construir el sistema existe un
periodo de negociación del contrato en el cual puede tener que negociar nuevos
cambios en los requerimientos.
Sistemas heredados: Son sistemas informáticos socio-técnicos que han sido
desarrollado en el pasado, a menudo usando una tecnología antigua y obsoleta.
También incluyen procesos y procedimientos antiguos

CAPITULO 4
Un proceso de software es un conjunto de actividades que conducen a la creación de
un producto software. Los procesos del software son complejos. Algunas actividades
fundamentales son comunes:
_Especificación del software: Se debe definir la funcionalidad del software y las
restricciones en su operación.
Es una etapa crítica en el proceso del software ya que los errores en esta etapa
originan problemas posteriores en el diseño e implementación.
___Estudio de viabilidad: Se estima si las necesidades del usuario se pueden
satisfacer con las tecnologías actuales de software y hardware. Se analiza si el
sistema propuesto será rentable desde un punto de vista de negocios y si se puede
desarrollar dentro de las restricciones de presupuesto existente.
___Obtención de análisis de requerimientos: Es el proceso de obtener los
requerimientos del sistema por medio de la observación de los sistemas existentes,
discusiones con los usuarios potenciales y proveedores, etc. Esto puede implicar el
desarrollo de uno o más modelos y prototipos del sistema que ayudan al analista a
comprender el sistema a especificar.
___Especificación de requerimientos: Es la actividad de traducir la información
recopilada durante la actividad de análisis en un documento que define un conjunto de
requerimientos. Los requerimientos del usuario, que son declaraciones abstractas de
los requerimientos de los clientes y el usuario final del sistema. Los requerimientos del
sistema que son una descripción más detallada de la funcionalidad a proporcionar.
___Validación de requerimientos: Se comprueba la veracidad, consistencia
completitud de los requerimientos. Se descubren errores en los requerimientos, se
debe modificar entonces para corregir estos problemas.

_Diseño e implementación del software: se debe producir software que cumpla su

especificación. Es construir una especificación de software en un sistema ejecutable.
Diseño de software es una descripción de la estructura del software que se va a
implementar, los datos que son parte del sistema, las interfaces entre los componentes
del sistema, algoritmos usados. El proceso de diseño puede implicar el desarrollo de
varios modelos del sistema con diferentes niveles de abstracción:
___Diseño arquitectónico: Los subsistemas que forman el sistema y sus relaciones se
identifican y documentan.
___Especificación abstracta: Para cada subsistema de sus servicios y las restricciones
bajo las cuales debe funcionar.
___Diseño de la interfaz: Para cada subsistema se diseña y documenta su interfaz con
otros subsistemas. Debe ser inequívoca ya que permite que el subsistema se utilice
sin conocimiento de su funcionamiento.
___Diseño de componentes: Se asignan servicios a los componentes y se diseñan sus
interfaces.
___Diseño de la estructura de datos: Se diseñan en detalle y especifica la estructura
de datos utilizada en la implementación del sistema.
___Diseño de algoritmos: Se diseñan en detalle y especifican los algoritmos utilizados
para proporcionar los servicios.
_Validación del software: Se debe validar el software para asegurar que hace lo que el
cliente desea. Implica procesos de comprobación, como las inspecciones y revisiones
en cada etapa del proceso del software.
___Prueba de componentes(o unidades): individuales para asegurarse de que
funcionan correctamente. Cada uno se prueba de forma independiente. Los
componentes pueden ser entidades simples como funciones o clases de objetos.
___Prueba del sistema: Los componentes se integran para formar el sistema. Este
proceso comprende encontrar errores que son el resultado de interacciones no
previstas entre los componentes y su interfaz. También comprende validar que el
sistema cumpla sus requerimientos funcionales y no funcionales, y probar las
propiedades emergentes del sistema.
___Prueba de aceptación: Es la etapa final en el proceso de pruebas antes de que se
acepte que el sistema se ponga en funcionamiento. Se prueba con los datos
proporcionados por el cliente más que con los datos de pruebas simulados. También
puede revelar problemas en los requerimientos donde los recursos del sistema no
cumplen las necesidades del usuario o donde el desempeño del sistema es
inaceptable.

_Evolución del software: El software debe evolucionar para cubrir las necesidades
cambiantes del cliente. Los costos de mantenimiento son a menudo los costos iniciales
de desarrollo.
Modelo de proceso de software: es una representación abstracta de un proceso de
software. Cada modelo representa desde una perspectiva en particular.
*El modelo en cascada: Considera las actividades fundamentales del proceso de
especificación, desarrollo, validación y evolución, y los representa como fases
separadas del proceso.
__Análisis y definición de requerimientos. Los servicios, restricciones y metas del
sistema se definen a partir de las consultas con los usuarios. Sirven como una
especificación del sistema.
__Diseño del sistema y del software: Divide los requerimientos en sistema hardware o
software. El diseño del software identifica y describe las abstracciones fundamentales
del sistema software y sus relaciones.
__Implementación y prueba de unidades: El diseño de software se lleva a cabo como
un conjunto o unidades de programas. Las pruebas de unidades implican que cada
una cumpla su especificación.
__Integración y prueba del sistema: Los programas o las unidades individuales de
programa se integran y prueban como un sistema completo para asegurar que se
cumplan los requerimientos del software.
__Funcionamiento y mantenimiento: Esta es la fase más larga del ciclo de vida. El
sistema se instala y se pone en funcionamiento. El mantenimiento implica corregir
errores no descubiertos en las etapas anteriores al ciclo de vida.
Desarrollo evolutivo: se basa en la idea de desarrollar una implementación inicial,
refinándola a través de los comentarios del mismo hasta que se desarrolla un sistema
adecuado. Las actividades de especificación, desarrollo y validación se entrelazan en
vez de separarse, con una rápida retroalimentación.
_Desarrollo exploratorio: el objetivo del proceso es trabar con el cliente para explorar
sus requerimientos y entregar un sistema final.
_Prototipos desechables: el objetivo del proceso de desarrollo evolutivo es
comprender los requerimientos del cliente y entonces desarrollar una definición
mejorada de los requerimientos para el sistema.
Desde la perspectiva de ingeniería y gestión el enfoque tiene dos problemas:
_El proceso no es visible: Los administradores tiene que hacer entregas regulares
para medir el progreso. No es rentable producir documentos que reflejen cada versión
del sistema.
_A menudo los sistemas tienen una estructura deficiente: Los cambios continuos
tienden a corromper la estructura del software.
Ingeniería del software basada en componentes: Existe algo llamado reutilización del
software. Esto sucede informalmente cuando las personas que trabajan en el proyecto
conocen diseños o códigos similares al requerido. CSBE se basa en la reutilización.
Las etapas de especificación de requerimientos y la de validación son comparables
con otros procesos, las etapas intermedias en el proceso orientado a la reutilización
son diferentes:
_Análisis de componentes: Se busca los componentes para implementar esta
especificación. No existe una concordancia exacta.
_Modificación de requerimientos: Los requerimientos se analizan utilizando
información acerca de los componentes que se han descubierto. Estos componentes
se modifican para reflejar los componentes disponibles.
_Diseño del sistema con reutilización: Se diseña o reutiliza un marco de trabajo para el
sistema. Los diseñadores tienen en cuenta los componentes que se reutilizan y
organizan el marco de trabajo para que los satisfaga.
_Desarrollo e integración: El software que no se puede adquirir externamente se
desarrolla y los componentes y los sistemas COTS se integran.
Iteración de procesos: Los requerimientos del sistema cambian cuando el negocio que
procura el sistema responde a las presiones exteriores. Introducción a la iteración de
procesos:
*Entrega incremental: La especificación, y el diseño y la implementación del software
se dividen en una serie de incrementos, los cuales se desarrollan por turnos. La
entrega incremental es un enfoque intermedio que combina las ventajas del modelo en
cascada y el modelo evolutivo. Los clientes identifican que servicios son más
importantes y cuales menos, entonces se definen varios incrementos en donde cada
uno proporciona un subconjunto de la funcionalidad del sistema. Un incremento se
completa y entrega, los clientes pueden ponerlo en servicio, esto significa que tienen
una entrega temprana de parte de la funcionalidad del sistema, pueden experimentar
con el sistema lo cual le ayuda a clarificar sus requerimientos.
__Los clientes no tienen que esperar que el sistema completo se entregue para sacar
provecho de él. El primer incremento satisface los requerimientos más críticos de tal
forma que pueden utilizar el software inmediatamente.
__los clientes pueden utilizar los incrementos iniciales como prototipos y obtener
experiencia sobre los requerimientos de los incrementos posteriores del sistema.
__Existe un bajo riesgo de un fallo total del proyecto, aunque se pueden encontrar
problemas en el algunos incrementos.
__Es inevitable que los servicios más importantes del sistema sean los que se les
haga más pruebas. Es menos probable que los clientes encuentren fallos de
funcionamiento del software en las partes más importantes del sistema.
*Desarrollo en espiral: El desarrollo del sistema gira en espiral hacia afuera
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, se divide en
cuatro sectores:
__Definición de objetivos: Se definen los objetivos específicos. Se identifican las
restricciones del proceso y el producto y se traza un plan detallado de gestión. Se
identifican los riesgos del proyecto. Entendiendo estos riesgos se planean estrategias
alternativas.
__Evaluación y reducción de riesgos: Se lleva a cabo un análisis detallado para cada
uno de los riesgos del proyecto. Se definen pasos para reducir dichos riesgos.
__Desarrollo y validación: Se elige un modelo para el desarrollo del sistema.
__Planificación: El proyecto se revisa y se toma la decisión de si debe continuar con
un ciclo posterior a la espiral.
El proceso unificado de rational
RUP es un ejemplo de un modelo de proceso moderno que proviene del trabajo en
UML y el asociado proceso unificado de desarrollo de software:
_Una perspectiva dinámica que muestra las fases del modelo sobre el tiempo.
_una perspectiva estática que muestra las actividades del proceso que se representan.
_Una perspectiva práctica que sugiere buenas practicas a utilizar durante el proceso.
La mayor parte de las descripciones del RUP intentan combinar las perspectivas
estática y dinámica en un único diagrama. Es un modelo en fases que identifica cuatro
fases diferentes en el proceso del software:
__Inicio: El objetivo de la fase de inicio es el de establecer un caso de negocio para el
sistema. Se deben identificar todas las entidades externas que interactuaran con el
sistema y definir estas interacciones.
__Elaboración: Los objetivos de la fase de elaboración son desarrollar una
comprensión del dominio del problema, establecer un marco de trabajo arquitectónico
para el sistema, desarrollar el plan del proyecto e identificar los riesgos clave del
proyecto. Al terminar esta fase se debe tener un modelo de los requerimientos del
sistema, una descripción arquitectónica y un plan de desarrollo de software.
__Construcción: La fase de construcción fundamentalmente comprende el diseño del
sistema, la programación y las pruebas. Durante esta fase se desarrollan e integran
las partes del sistema. Al terminar esta fase, debe tener un sistema software operativo
y la documentación correspondiente para entregarla a los usuarios.
__Transición: La fase final del RUP se ocupada de mover el sistema desde la
comunidad de desarrollo a la comunidad del usuario y hacerlo trabajar en un entorno
real. Al terminar esta fase se debe tener un sistema software documentado que
funciona correctamente en su entorno operativo.
La vista estática del RUP 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 en el proceso y tres principales flujos de trabajo de
soporte.
__Modelado del negocio: Los procesos del negocio se modelan utilizando casos de
uso de negocio.
__Requerimientos: Se definen los actores que interactúan con el sistema y se
desarrollan casos de uso para modelar los requerimientos del sistema.
Análisis y diseño: Se crea y documenta un modelo del diseño utilizando modelos
arquitectónicos, modelos de componentes, modelos de objetos y modelo de
secuencias.
__Implementación: Se implementan y estructuran en subsistemas los componentes
del sistema. La generación automática de código de los modelos del diseño ayuda a
acelerar este proceso.
__Pruebas: Las pruebas son un proceso iterativo que se llevan a cabo conjuntamente
con la implementación. A la finalización de la implementación tienen lugar las pruebas
del sistema.
__Despliegue: Se crea una reléase del producto, se distribuye a los usuarios y se
instala en su lugar de trabajo.
__Configuración y cambios de gestión: Este flujo de trabajo de soporte gestiona los
cambios del sistema.
__Gestión del proyecto: Este flujo de trabajo de soporte gestiona el desarrollo del
sistema.
__Entorno: Este flujo de trabajo se refiere a hacer herramientas software apropiadas
disponibles para los equipos de desarrollo.
RUP recomienda seis buenas prácticas:
_Desarrolle el software de forma iterativa: Planifique incrementos del sistema basado
en las prioridades del usuario y desarrollo y entregue las características del sistema de
más alta prioridad.
_Gestione los requerimientos: Documente explícitamente los requerimientos del cliente
y manténgase al tanto de los cambios de estos requerimientos.
_Utilice arquitecturas basadas en componentes: Estructure la arquitectura del sistema
en componentes.
_Modele el software visualmente: Utilice modelos gráficos UML para representar vistas
estáticas y dinámicas del software.
_Verifique la calidad del software: Asegure que el software cumple los estándares de
calidad organizacionales.
_Controle los cambios del software: Gestione los cambios del software usando un
sistema de gestión de cambios y procedimientos y herramientas de gestión de
configuraciones.
CASE
Ingeniería del software asistida por computadora es el nombre que se le da al software
que utiliza para ayudar a las actividades del proceso del software como la ingeniería
de requerimientos, el diseño, el diseño de programas y las pruebas. Proporcionan
ayuda al proceso del software automatizado algunas de sus actividades. La tecnología
está disponible para la mayoría de las actividades rutinarias en el proceso del
software. Esto permite algunas mejoras en la calidad y productividad del software.
Limitación:
_La ingeniería del software es una actividad de diseño que se basa en la creatividad.
Los sistemas “case” automatizan las actividades rutinarias.
_La ingeniería de software es una actividad de equipo, y los ingenieros invierten
mucho tiempo interactuando con los miembros del equipo, “case” no proporciona
mucha ayuda para esto.
Clasificación:
__Una perspectiva funcional en la que las herramientas se clasifican de acuerdo con
su función específica.
__Una perspectiva de proceso en la que las herramientas se clasifican de acuerdo con
las actividades del proceso que ayudan
__Una perspectiva de integración en la que las herramientas se clasifican de acuerdo
con la forma en que están organizadas en unidades integradas que proporcionan
ayuda a una o más actividades del proceso.

Gestión de proyectos
Es una parte esencial de la ingeniería de software. La mala gestión lleva al fracaso del
proyecto. Los gestores de software son responsables de la planificación y
temporalización del desarrollo de los proyectos. La administración de proyectos de
software es necesaria debido la ingeniería de software profesional siempre está sujeta
a restricciones organizacionales de tiempo y presupuesto. Los gestores de software
hacen este trabajo sin embargo la ingeniería de software es diferente en varios
aspectos:
_El producto es intangible: El software es intangible, no se puede ver ni tocar, los
gestores de proyecto de software no pueden ver el progreso. Confían en otros para
elaborar la documentación necesaria para revisar el progreso.
_No existen procesos del software estándar: A pesar de que la comprensión del
proceso de software se ha desarrollado de forma significativa en los últimos años, aun
no se puede predecir con certeza cuando un proceso particular tiende a desarrollar
problemas.
_A menudo los proyectos grandes son únicos: Los gestores aun cuando cuenten con
una amplia experiencia esta no es suficiente para anticipar los problemas. Los
cambios rápidos tecnológicos en las computadoras y las comunicaciones hacen
parecer obsoleta la experiencia previa.
Actividades de gestión
_Redacción de la propuesta: redactar una propuesta para realizar ese proyecto.
Describe los objetivos del proyecto y como se llevaría a cabo. No existen guías para
esta tarea.
_Planificación y calendarización del proyecto: Identificación de actividades, hitos y
entregas de un proyecto. Se debe bosquejar un plan para guiar el desarrollo hacia las
metas de un proyecto.
_Estimación de costes del proyecto: Es una actividad relacionada con la estimación de
los recursos requeridos para llevar a cabo el plan del proyecto.
_Supervisión y revisión del proyecto: La supervisión es una actividad continua. El
gestor debe tener conocimiento del progreso del proyecto comparar el progreso con
los costes actuales y los planificados. La supervisión informal predice problemas
importantes del proyecto, y revela dificultades que pueden aparecer.
_Selección y evaluación del personal: los gestores tienen que seleccionar a las
personas para trabajar en su proyecto. Tienen que establecer un equipo ideal mínimo
para el proyecto:
___El presupuesto del proyecto no cubre la contratación de personal con sueldos
altos. Se tiene que contratar personal con menos experiencia y menor sueldo.
___El personal con experiencia apropiada no está disponible dentro o fuera de la
organización. Es imposible reclutar nuevo personal para el proyecto.
___La organización desea desarrollar las habilidades de sus empleados. El persona
inexperto puede ser asignado al proyecto para aprender y adquirir experiencia.
_Redacción y presentación de informes: los gestores son responsables de informar a
los clientes y contratistas sobre el proyecto. Tienen que redactar documentos concisos
y coherentes que resuman la información crítica de los informes detallados del
proyecto.
Planificación del proyecto
La gestión efectiva de un proyecto de software depende de planificar completamente
el progreso del proyecto. Debe anticiparse a los problemas que puedan surgir así
como preparar soluciones a esos problemas.
_Plan de calidad: Describe los procedimientos y los estándares de calidad que se
utilizaran en un proyecto.
_Plan de validación: Describe el enfoque, los recursos y la programación utilizados
para la validación del sistema.
_Plan de gestión de configuraciones: Describe los procedimientos para la gestión de
configuraciones y las estructuras a utilizar.
_Plan de mantenimiento: Predice los requerimientos del mantenimiento del sistema,
los costes del mantenimiento y el esfuerzo requerido.
_Plan de desarrollo del personal: Describe cómo se desarrollan las habilidades y
experiencia de los miembros del equipo del proyecto.
El proceso de planificación se inicia con una valoración de las restricciones que
afectan al proyecto. Esta se lleva a cabo en conjunto con una estimación de los
parámetros del proyecto, como su estructura tamaño y distribución de funciones.
Entonces se definen los hitos del progreso y productos a entregar. El proceso entra en
un ciclo. Debido a que las estimaciones iniciales de los parámetros del proyecto son
aproximaciones, el plan deberá actualizarse.
___El plan del proyecto fija los recursos disponibles, divide el trabajo y crea un
calendario de trabajo:
***Introducción: Describe brevemente los objetivos del proyecto y expone las
restricciones que afectan a la gestión del proyecto.
***Organización del proyecto: Describe la forma en que el equipo de desarrollo de esta
organizado, la gente involucrada y sus roles en el equipo.
***Análisis de riesgo: Describe los posibles riesgos del proyecto, la probabilidad de que
surjan estos riesgos y las estrategias de reducción de riesgos propuestas.
***Requerimientos de recursos de hardware y software: Describe el hardware y el
software de ayuda requeridos para llevar a cabo el desarrollo.
***División del trabajo: Describe la división del proyecto en actividades e identifica los
hitos y productos a entregar asociados con cada actividad.
***Programa del proyecto: Describe las dependencias entre actividades, el tiempo
estimado requerido para alcanzar cada hito y la asignación de la gente a las
actividades.
***Mecanismo de supervisión e informe: Describe la gestión de informes y cuando
debe producirse, así como los mecanismos de supervisión del proyecto a utilizar.
Hitos y entregas
Cuando se planifica un proyecto se debe establecer una serie de hitos (puntos finales
de una actividad del proceso del software). Debe existir una salida formal, como un
informe que se debe presentar al gestor. No deben ser documentos amplios. Deben
ser informes cortos de los logros en una actividad del proyecto. Deben representar el
fin de una etapa lógica en el proyecto.
Una entrega es el resultado del proyecto que se entrega al cliente. Se entrega al final
de una fase principal del proyecto como la especificación, el diseño, etc. Las entregas
son hitos, pero estos no son necesariamente entregas. Para establecer los hitos, el
proceso del software debe dividirse en actividades básicas con sus salidas asociadas.
Calendarización del proyecto
Los gestores estiman el tiempo y los recursos requeridos para completar las
actividades y organizarlas en una sucesión coherente. Las estimaciones previas son
una base incierta para la calendarización del nuevo proyecto. Si el proyecto es
técnicamente complejo, las estimaciones iniciales casi siempre son optimistas aun
cuando los gestores traten de considerar las eventualidades. Implica separar todo el
trabajo de un proyecto en actividades complementarias y considerar el tiempo
requerido para completar dichas actividades. Algunas de estas se llevan a cabo en
paralelo. Debemos coordinar estas actividades paralelas y organizar el trabajo para
que la mano de obra se utilice de forma óptima. Las actividades deben durar por lo
menos una semana. Hacer subdivisiones más finas significa invertir una cantidad
desproporcionada de tiempo en la estimación y revisión de tablas. Al estimar la
calendarización, los gestores no deben suponer que cada etapa del proyecto estará
libre de problemas. Los gestores deben estimar los recursos necesarios para
completar cada tarea. Una buena práctica es estimar como si nada fuera a salir mal, y
entonces incrementar la estimación para abarcar los problemas previstos.
Gráficos de barras y redes de actividades
Son notaciones graficas que se utilizan para ilustrar la calendarización del proyecto.
Los gráficos de barras muestran quien es responsable de cada actividad y cuando
debe comenzar y finalizar esta. Las redes de actividades muestran las dependencias
entre las diferentes actividades que conforman un proyecto. Los gráficos de barras y
las redes de actividades se generan automáticamente utilizando una herramienta de
gestión de proyectos. A demás de considerar la calendarización, los gestores e
proyectos también deben tener en cuenta la asignación de recursos y en particular la
asignación de personal a las actividades del proyecto.
Gestión de riesgos
Una tarea importante del gestor de proyectos es anticipar los riesgos que podrían
afectar a la programación del proyecto o la calidad del software a desarrollar y
emprender acciones para evitar esos riesgos. Los resultados de este análisis de
riesgos se deben documentar a lo largo del plan del proyecto junto con el análisis de
consecuencias cuando el riesgo ocurra.
_Riesgos del proyecto: Estos afectan la calendarización o los recursos del proyecto.
_Riesgos del producto: Estos afectan a la calidad o al rendimiento del software que se
está desarrollando.
_Riesgos del negocio: Estos afectan a la organización que desarrolla o suministra el
software.
Riesgos universales:
__Rotación de personal: Personal con experiencia abandona el proyecto antes de que
finalice.
__Cambio de gestión: Habrá un cambio de gestión organizacional con diferentes
prioridades.
__No disponibilidad del hardware: El hardware esencial para el proyecto no será
entregado a tiempo.
__Cambio de requerimientos: Habrá más cambios en los requerimientos de lo
esperado.
__Retraso en la especificación: Las especificaciones de las interfaces esenciales no
estarán a tiempo.
__Subestimación del tamaño: El tamaño del sistema se ha subestimado.
__Bajo rendimiento de la herramienta CASE: Las herramientas que ayudan al proyecto
no tienen el rendimiento esperado.
__Cambio de tecnología: Un producto competitivo se pone en venta antes de que el
sistema se complete.
__Competencia del producto: La tecnología fundamental sobre la que se construirá el
sistema se sustituye por nueva tecnología.
Se debe crear un plan de contingencias para que sea posible aplicar acciones de
recuperación:
*Identificación de riesgos: Identificar los posibles riesgos para el proyecto, el producto
y los negocios. Comprende el descubrimiento de los posibles riesgos del proyecto. Se
puede llevar a cabo a través de un proceso de grupo utilizando un enfoque de
tormenta de ideas o simplemente puede basarse en la experiencia:
___Riesgo de tecnología: Se derivan de las tecnologías de software o hardware
utilizadas en el sistema que se está desarrollando.
___Riesgo de personal: Riesgos asociados con las personas del equipo de desarrollo.
___Riesgos organizacionales: Se derivan del entorno organizacional donde el software
se está desarrollando.
___Riesgos de herramientas: Se derivan de herramientas CASE y de otro software de
apoyo utilizado para desarrollar el sistema.
___Riesgos de requerimientos: Se derivan de los cambios de los requerimientos del
cliente y el proceso de gestionar dicho cambio.
___Riesgos de estimación: Se derivan de los estimados administrativos de las
características del sistema y los recursos requeridos para construir dicho sistema.
Ejemplos de riesgos posibles en cada una de estas categorías.
___Tecnología: La base de datos que se utiliza en el sistema no puede procesar
muchas transacciones por segundo como se esperaba. Los componentes de software
que deben reutilizarse contienen defectos que limitan su funcionalidad.
___Personal: Es imposible reclutar personal con las habilidades requeridas para el
proyecto. El personal clave está enfermo y no disponible en momentos críticos. La
capacitación solicitada para el personal no está disponible.
___Organizacional: La organización se reestructura de tal forma que una gestión
diferente se responsabiliza del proyecto. Los problemas financieros de la organización
fuerzan a reducciones en el presupuesto del proyecto.
___Herramientas: Es ineficiente el código generado por las herramientas CASE. Las
herramientas CASE no se pueden integrar.
___Se proponen cambios en los requerimientos que quieren rehacer el diseño. Los
clientes no comprenden el impacto de los cambios en los requerimientos.
___Estimación: El tiempo requerido para desarrollar el software esta subestimado. La
tasa de reparación de defectos esta subestimada. El tamaño del software esta
subestimado.
*Análisis de riesgos: Valorar las probabilidades y consecuencias de estos riesgos. Se
consideran por separado cada riesgos identificado y se decide acerca de la
probabilidad y la seriedad del mismo. No se hace valoraciones con números sino
intervalos. El resultado de este proceso de análisis se debe colocar en una tabla, la
cual debe estar ordenada según la seriedad del riesgo. Una vez que los riesgos se
hayan analizado y clasificado, se debe discernir cuáles son los más importantes que
se deben considerar durante el proyecto. Este discernimiento debe depender de una
combinación de la probabilidad de aparición del riesgo y de los efectos del mismo.
*Planificación de riesgos: Crear planes para abordar los riesgos, ya sea para evitarlos
o para minimizar sus efectos en el proyecto. Considera cada uno de los riesgos clave
que han sido identificados, así como las estrategias para gestionarlos:
___Estrategias de prevención: La probabilidad de que el riesgo aparezca se reduce.
___Estrategia de minimización: Se reducirá el impacto del riesgo.
___Planes de contingencia: Es estar preparado para lo peor y tener una estrategia
para cada caso.
*Supervisión de riesgos: valorar los riesgos de forma constante y revisar los planes
para mitigación de riesgos tan pronto como la información de los riesgos esté
disponible. Valora cada uno de los riesgos identificados para decidir si éste es más o
menos probable y si han cambiado sus efectos. Debe ser un proceso continuo y en
cada revisión del progreso de gestión cada uno de los riesgos clave debe ser
considerado y analizado por separado.
Requerimientos del software
Son la descripción de los servicios proporcionados por el sistema y sus restricciones
operativas. Reflejan las necesidades de los clientes de un sistema que ayude a
resolver algún problema. El proceso de analizar, documentar y verificar estos servicios
y restricciones se denomina ingeniería de requerimientos. Se distinguen utilizando la
denominación requerimientos del usuario para designar los requerimientos abstractos
de alto nivel, y requerimientos del sistema para designar la descripción detallada de lo
que el sistema debe hacer:
*Los requerimientos del usuario: son declaraciones en lenguaje natural y en diagramas
de los servicios que se espera que el sistema proporcione y de las restricciones bajo
las cuales debe funcionar. Para un sistema deben describir los requerimientos
funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del
sistema sin conocimiento técnico detallado. Problemas:
___Falta de claridad: Algunas veces es difícil utilizar el lenguaje de forma precisa y no
ambigua sin hacer el documento poco conciso y difícil de leer.
___Confusión de requerimientos: No se distinguen claramente los requerimientos
funcionales y no funcionales, las metas del sistema y la información para el diseño.
___Conjunción de requerimientos: Diversos requerimientos diferentes se pueden
expresar de forma conjunta como un único requerimiento.
Pautas para redactar requerimientos del usuario:
___Inventar un formato estándar y asegurar que todos los requerimientos se adhieren
al formato. Estandarizar el formato hace que las omisiones sean menos probables y
los requerimientos más fáciles de verificar.
___Utilizar el lenguaje de forma consistente. Siempre debe distinguir entre los
requerimientos deseables y los obligatorios. Los requerimientos obligatorios son los
requerimientos a los que el sistema debe dar soporte y normalmente se redactan en
futuro simple. Los requerimientos deseables no son fundamentales y se redactan en
futuro condicional.
___Resaltar el texto para distinguir partes clave del requerimiento.
___Evitar el uso de jerga informática.
*Los requerimientos del sistema: establecen con detalle las funciones, servicios y
restricciones operativas del sistema. Debe ser precisa la especificación funcional.
Puede ser parte del contrato entre el comprador del sistema y los desarrolladores del
software. Son versiones extendidas de los requerimientos del usuario que son
utilizados por los ingenieros de software como punto de partida para el diseño del
sistema. Se pueden redactar los requerimientos del sistema en unas notaciones más
especializadas.
*Especificaciones en lenguaje estructurado:
El lenguaje natural estructurado es una forma de redactar los requerimientos del
sistema donde la libertad del redactor de los requerimientos ésta limitada y donde
todos los requerimientos se redactan de una forma estándar. Se mantiene la mayor
parte de la expresividad y comprensión del lenguaje natural, pero asegura que se
imponga cierto grado de uniformidad en la especificación. Para utilizar un enfoque
basado en formularios para especificar los requerimientos del sistema, se deben
definir una o más formularios o plantillas estándares para expresar estos
requerimientos:
___Descripción de la función o entidad a especificar.
___Descripción de sus entradas y de donde provienen.
___Descripción de sus salidas y hacia dónde van.
___Indicación de que otras entidades se utilizan.
___Si se utiliza un enfoque funcional, una precondición que indique lo que se debe
cumplir y una pos condición que especifique lo que será verdad una vez invocada
dicha función.
___Descripción de los efectos colaterales de la operación.
Requerimientos funcionales y no funcionales
Los requerimientos del sistema software se clasifican en funcionales y no funcionales:
_Requerimientos funcionales: Son declaraciones de los servicios que debe
proporcionar el sistema, de la manera en que este debe reaccionar a entradas
particulares y de cómo se debe comportar en situaciones particulares. En algunos
casos se debe explicitar lo que el sistema no debe hacer. Puede mostrar documentos
en diferentes formatos. La especificación de requerimientos funcionales de un sistema
debe estar completa y ser consistente. La completitud signifique que todos los
servicios solicitados por el usuario deben estar definidos. La consistencia significa que
los requerimientos no deben tener definiciones contradictorias.
_Requerimientos no funcionales: Son restricciones de los servicios o funciones
ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de
desarrollo y estándares. No se refieren directamente a las funciones específicas que
proporciona el sistema, sino a las propiedades emergentes de éste como la fiabilidad,
el tiempo de respuesta y la capacidad de almacenamiento. No solo se refiere al
sistema software a desarrollar, algunos de estos requerimientos pueden restringir el
proceso que se debe utilizar para desarrollar el sistema. Surgen de las necesidades
del usuario, debido a las restricciones en el presupuesto a las políticas de la
organización, a las necesidades de interoperabilidad con otros sistemas software o
hardware.
___Requerimientos del producto: Especifican el comportamiento del producto.
___Requerimientos organizacionales: Se derivan de políticas y procedimientos
existentes en la organización del cliente y en la del desarrollador.
___Requerimientos externos: incluye todos los requerimientos que se derivan de los
factores externos al sistema y de su proceso de desarrollo.
_Requerimientos del dominio: Provienen del dominio de aplicación del sistema y que
reflejan las características y restricciones de ese dominio. Pueden ser funcionales o no
funcionales. Incluyen terminología especializada del dominio o referencias a conceptos
del dominio. Pueden ser requerimientos funcionales nuevos, restringir los existentes o
establecer como se deben ejecutar cálculos particulares.
Especificación de la interfaz
Casi todos los sistemas de software deben funcionar con otros sistemas que ya están
implementados e instalados en el entorno:
_Interfaces de procedimiento: En las cuales los programas o subsistemas existentes
ofrecen una variedad de servicios a los que se accede invocando a los procedimientos
de la interfaz.
_Estructuras de datos: Pasan de un sistema a otro. Los modelos gráficos de datos son
las mejores notaciones para este tipo de descripción.
_Representaciones de datos: Establecidas para un subsistema existente. Estas
interfaces son muy comunes en sistema de tiempo real embebido.
El documento de requerimientos del software
Es la declaración oficial de qué deben implementar los desarrolladores del sistema.
Debe incluir tanto los requerimientos del usuario para el sistema como una
especificación detallada de los requerimientos del sistema. El documento de
requerimientos tiene un conjunto de diversos usuarios que va desde los altos cargos
de la organización que pagan por el sistema, hasta los ingenieros responsables de
desarrollar el software. El nivel de detalle que se debe incluir en un documento de
requerimientos depende del tipo de sistema que se desarrolle y del proceso de
desarrollo utilizado. El estándar más amplio conocido es IEEE/ANSI 830-1998:
_Introducción
__Propósitos del documento de requerimientos.
__Alcance del producto.
__Definiciones, acrónicos y abreviaturas.
__Referencias.
__Descripción del resto del documento.
_Descripción general.
__Perspectiva del producto.
__Funciones del producto.
__Características del usuario.
__Restricciones generales.
__Suposiciones y dependencias.
_Requerimientos específicos
_Apéndices.
_Indicé.
___Prefacio: Debe definir los posibles lectores del documento y describir su versión de
la historia, incluyendo un fundamento para la creación de una nueva versión y un
resumen de los cambios hechos en cada una.
___Introducción: Debe escribir la necesidad del sistema. Debe describir brevemente
sus funciones y explicar cómo trabajara con otros sistemas. Debe describir la manera
en que éste se adhiere al negocio total u objetivos estratégicos de la organización que
solicita el software.
___Glosario: Debe definir los términos técnicos utilizados en el documento no se
deben hacer suposiciones de la experiencia o pericia del lector.
___Definición de requerimientos del usuario: en esta sección se deben describir los
servicios que proporcionan al usuario y los requerimientos no funcionales del sistema.
Esta descripción puede utilizar lenguaje natural, diagramas u otras notaciones que
sean comprensibles para los clientes. Se deben especificar los estándares de
productos y procesos a seguir.
___Arquitectura del sistema: Este capítulo debe presentar una visión general de alto
nivel en la arquitectura prevista del sistema que muestre la distribución de funciones
en los módulos del sistema. Se deben resaltar los componentes arquitectónicos
reutilizados.
___Especificación de requerimientos del sistema: Debe describir con mayor detalle los
requerimientos funcionales y no funcionales. Si es necesario, se pueden enfatizar los
no funcionales.
___Modelos del sistema: Se deben exponer uno o más modelos del sistema que
muestren las relaciones entre los componentes del sistema y el sistema y su entorno.
Estos podrían ser modelos de objetos, modelos d flujos de datos y modelo de datos
semánticos.
___Evolución del sistema: Debe describir las suposiciones fundamentales sobre las
cuales se basa el sistema y los cambios previstos debido a la evolución del hardware,
cambios en las necesidades del usuario, etc.
___Apéndices: Debe proporcionar información detallada y precisa relacionada con la
aplicación que se desarrolla. Algunos ejemplos de apéndices que pueden incluirse son
las descripciones del hardware y de la base de datos.
___Indicé: Se puede incluir varios índices en el documento. Además de un índice
alfabético, puede haber un índice de diagramas, un índice de funciones, etc.
Proceso de la ingeniería de requerimientos
La meta es crear y mantener un documento de requerimientos del sistema. El proceso
general corresponde cuatro subprocesos de alto nivel de la ingeniería de
requerimientos. En todos los sistemas los requerimientos cambian. El proceso de
gestionar estos cambios en los requerimientos se denomina gestión de
requerimientos. La obtención de requerimientos es una actividad centrada en las
personas.
Estudio de la viabilidad
La entrada es un conjunto de requerimientos de negocio preliminares, una descripción
resumida del sistema y de cómo este pretende contribuir a los procesos de negocio. Si
no contribuye a los objetivos de negocio entonces no tiene un valor real en el negocio.
La viabilidad comprende llevar a cabo un estudio que comprende la evaluación y
recopilación de la información y redacción de informes. En un estudio de viabilidad se
pueden consultar las fuentes de información, como los jefes de departamentos, donde
se utilizara el sistema, los ingenieros de software que están familiarizados con el tipo
de sistema propuesto, los expertos en tecnología y los usuarios finales del sistema.
Dura de dos a tres semanas.
Obtención y análisis de requerimientos
En esta actividad los ingenieros de software trabajan con los clientes y los usuarios
finales del sistema para determinar el dominio de la aplicación, que servicios debe
proporcionar el sistema, el rendimiento requerido del sistema, las restricciones
hardware, etc. Stakeholder se utiliza para referirse a cualquier persona o grupo que se
verá afectado por el sistema directa o indirectamente, entre los mismos se encuentran
los usuarios finales que interactuaran con el sistema y todos aquellos en la
organización que se pueden ver afectados por su instalación. Dificultades:
_A menudo no conocen lo que desean obtener del sistema informático excepto en
términos muy generales.
_Expresan los requerimientos con sus propios términos de forma natural y con un
conocimiento implícito de su propio trabajo.
_Tienen requerimientos distintos que se pueden expresar de varias formas.
_Los factores políticos pueden influir en los requerimientos del sistema.
_El entorno económico y de negocios en el que se lleva a cabo el análisis es dinámico.
Cambia durante el proceso de análisis.
*Descubrimiento de requerimientos
Es el proceso de recoger información sobre el sistema propuesto y los existentes y
extraer los requerimientos del usuario y del sistema de esta información. Las fuentes
de información incluyen stakeholders del sistema, la documentación y la especificación
de sistemas similares.
_Puntos de vista
Un punto clave del análisis es que reconoce varias perspectivas y proporciona un
marco de trabajo para descubrir conflictos en los requerimientos propuestos por
diferentes stakeholders:
___Punto de vista de los interactuadores: Representan a las personas u otros
sistemas que interactúan directamente con el sistema.
___Punto de vista indirectos: Representan a los stakeholders que no utilizan el
sistema ellos mismos pero que influyen en los requerimientos de algún modo.
___Puntos de vista del dominio: Representan las características y restricciones del
dominio que influyen en los requerimientos del sistema.
Los ingenieros que desarrollan el sistema pueden tener experiencia con sistemas
similares y sugerir requerimientos a partir de esa experiencia. El personal técnico que
tiene que administrar y mantener el sistema puede tener requerimientos que ayuden a
simplificar el soporte del sistema. Los puntos de vista que proporcionan requerimientos
pueden venir de los departamentos de marketing y asuntos externos en una
organización.
_Entrevistas
Las entrevistas formales o informales con los stakeholders del sistema son parte de la
mayoría de los procesos de la ingeniería de requerimientos.
___Entrevistas cerradas: Donde los stakeholders responden a un conjunto predefinido
de preguntas.
___Entrevistas abiertas: Donde no hay un programa definido. El equipo de la
ingeniería de requerimientos examina una serie de cuestiones con los stakeholders del
sistema y desarrolla una mejor comprensión de sus necesidades.
Las entrevistas con los stakeholders son una mezcla de estos. Sirven para obtener
una comprensión general de lo que hacen los stakeholders, como podrían interactuar
con el sistema y las dificultades a las que se enfrentan con los sistemas actuales.
Dificultades:
___Todos los especialistas de la aplicación utilizan terminología y jerga especifica de
un dominio.
___Cierto conocimiento del dominio no es tan familiar para los stakeholders que o lo
encuentran difícil de explicar o piensan que es tan básico que no merece la pena
mencionarlo.
Los entrevistadores eficaces tienen dos características:
___No tienen prejuicios, evitan ideas preconcebidas sobre los requerimientos y están
dispuestos a escuchar a los stakeholders.
___Instan al entrevistado a empezar las discusiones con una pregunta, una propuesta
de requerimientos o sugiriendo trabar juntos en un prototipo del sistema.
_Escenarios
Las personas encuentran más fácil dar ejemplos de la vida real que descripciones
abstractas. Pueden comprender y criticar un escenario de cómo podrían interactuar
con un sistema software. Pueden ser útiles para agregar detalle a un esbozo de la
descripción de requerimientos. Cada escenario abarca una o más posibles
interacciones. El escenario comienza con un esbozo de la interacción y se agregan
detalles para crear una descripción completa de esa interacción:
___Una descripción de lo que esperan el sistema y los usuarios cuando el escenario
comienza.
___Una descripción del flujo normal de eventos en el escenario.
___una descripción de lo que puede ir mal y cómo manejarlo.
___Información de otras actividades que se podrían llevar a cabo al mismo tiempo.
___Una descripción del estado del sistema cuando el escenario termina.
_Casos de uso
Son una técnica que se basa en escenarios para la obtención de requerimientos. Un
caso de uso identifica el tipo de interacciones y los actores involucrados. El conjunto
de casos de uso representa todas las posibles interacciones a representar en los
requerimientos del sistema. Pueden ser documentadas con texto o vinculadas a
modelo UML que desarrollan el escenario en más detalle.
_Etnografía
Es una técnica de observación que se puede utilizar para entender los requerimientos
sociales y organizacionales. Un analista se sumerge por si solo en el entorno laboral
donde se utilizara el sistema, observa el trabajo diario y anota las tareas erales en las
que los participantes están involucrados. Ayuda a los analistas a descubrir los
requerimientos implícitos que reflejan los procesos reales más que los formales en los
que la gente está involucrada. Tipos de requerimientos:
___Los requerimientos que se derivan de la forma en la que la gente trabaja
realmente: Más que de la forma en la que las definiciones de los procesos establecen
que debería trabajar.
___Los requerimientos que se derivan de la cooperación y conocimiento de las
actividades de la gente.
Los estudios etnográficos pueden revelar los detalles de los procesos críticos que
otras técnicas de obtención de requerimientos a menudo olvidan. Este enfoque no es
apropiado para descubrir los requerimientos organizacionales o del dominio.
Validación de requerimientos
Trata de mostrar que éstos realmente definen el sistema que el cliente desea. Es
importante debido a que los errores en el documento de requerimiento pueden
conducir a importantes costes al repetir el trabajo cuando son descubiertos durante el
desarrollo o después de que el sistema ésta en uso.
_Verificaciones de validez: El razonamiento y el análisis pueden identificar que se
requieren funciones adicionales o diferentes.
_Verificaciones de consistencia: Los requerimientos en el documento no deben
contradecirse.
_Verificaciones de completitud: El documento de requerimientos debe incluir
requerimientos que definan todas las funciones y restricciones propuestas por el
usuario del sistema.
_Verificaciones de realismo: Los requerimientos deben verificarse para asegurar que
se pueden implementar.
_Verificabilidad: Los requerimientos del sistema siempre deben redactarse de tal forma
que sean verificables.
Técnicas de validación de requerimientos:
_Revisión de requerimientos: Los requerimientos son analizados sistemáticamente por
un equipo de revisores. Involucra a personas tanto de la organización del cliente como
al del contratista. Verifican el documento de requerimientos en cuanto a anomalías y
omisiones. Pueden ser informales o formales.
___Verificabilidad.
___Comprensibilidad.
___Rastreabilidad.
___Adaptabilidad.
Los conflictos, contradicciones, errores y omisiones en los requerimientos deben ser
señalados por los revisores y registrase formalmente en el informe de revisión.
_Construcción de prototipos: Se muestra un modelo ejecutable del sistema a los
usuarios finales y a los clientes.
_Generación de casos de prueba: Los requerimientos deben poder probarse. Si una
prueba es difícil o imposible de diseñar, significa que los requerimientos serán difíciles
de implementar y deberían ser considerados nuevamente.
Gestión de requerimientos
Debido a que el problema no puede definirse completamente, es muy poco probable
que los requerimientos del software sean incompletos. Una vez que un sistema se ha
instalado, inevitablemente surgen nuevos requerimientos. Cuando los usuarios finales
tienen experiencia con un sistema, descubren nuevas necesidades y prioridades:
_Los sistemas grandes tienen una comunidad de usuarios diversa donde los usuarios
tiene diferentes requerimientos y prioridades. Estos pueden contradecirse o estar en
conflicto.
_Las personas que pagan por el sistema y los usuarios de este raramente son la
misma persona. Los clientes del sistema imponen requerimientos debido a las
restricciones organizacionales y de presupuesto. Estos pueden estar en conflicto con
los requerimientos de los usuarios finales y pueden tener que añadirse nuevas
características de apoyo al usuario si el sistema tiene que cumplir sus objetivos.
_El entorno de negocios y técnico del sistema cambia después de la instalación, y
estos cambios se deben reflejar en el sistema.
La gestión de requerimientos es el proceso de comprender y controlar los cambios en
los requerimientos del sistema. Hay que establecer un proceso formal para
implementar las propuestas de cambios y vincular estos a los requerimientos del
sistema.
*Requerimientos duraderos y volátiles
Los requerimientos se dividen en dos clases:
_Requerimientos duraderos: Son relativamente estables que se derivan de la actividad
principal de la organización y que están relacionados directamente con el dominio del
sistema.
_Requerimientos volátiles: Probablemente cambian durante el proceso de desarrollo
del sistema o después que este se haya puesto en funcionamiento.
*Planificación de la gestión de requerimientos
Es una etapa esencial del proceso de gestión de requerimientos. Decisiones:
_La identificación de requerimientos: Cada requerimiento debe identificar de forma
única de tal forma que puedan ser remitidos por otros requerimientos de manera que
pueda utilizarse evaluaciones de rastreo.
_Un proceso de gestión del cambio: Es el conjunto de actividades que evalúan el
impacto y coste de los cambios.
_Políticas de rastreo: Definen las relaciones entre los requerimientos, y entre estos y el
diseño del sistema que se debe registrar y la manera en que estos registros se deben
mantener.
_Ayuda de herramientas CASE: La gestión de requerimientos comprende el
procesamiento de grandes cantidades de información sobre los requerimientos. Las
herramientas que se pueden van desde sistemas de gestión de requerimientos
especializados hasta hojas de cálculo y sistemas sencillos de bases de datos.
Tipos de información de rastreo que pueden ser mantenidos:
_La información de rastreo de la fuente: Vincula los requerimientos con los
stakeholders que propusieron los requerimientos y la razón de estos.
_La información de rastreo de los requerimientos: Esta información se utiliza para
evaluar como es probable que muchos requerimientos se vean afectados por un
cambio propuesto y la magnitud de los cambios consecuentes en los requerimientos.
_La información de rastreo del diseño: Vincula los requerimientos a los módulos del
diseño en los cuales son implementados. Esta información se utiliza para evaluar el
impacto de los cambios de los requerimientos propuestos en el diseño e
implementación del sistema.
La gestión de requerimientos necesita ayuda automatizada: las herramientas CASE
para esto deben elegirse durante la fase de planificación:
_Almacenar requerimientos: Los requerimientos deben mantenerse en un almacén de
datos seguro y administrado que sea accesible.
_Gestionar el cambio: Este proceso se simplifica si está disponible una herramienta de
ayuda.
_Gestionar el rastreo: Algunas herramientas utilizan técnicas de procesamiento del
lenguaje natural para ayudarle a descubrir posibles relaciones entre los
requerimientos.
Gestión del cambio de los requerimientos
Se debe aplicar a todos los cambios propuestos en los requerimientos. La ventaja de
utilizar u proceso formal para gestionar el cambio es que todos los cambios propuestos
son tratados de forma consistente y que los cambios en el documento de
requerimientos se hacen de forma controlada.
_Análisis del problema y especificación del cambio: El proceso empieza con la
identificación de un problema en los requerimientos, o con una propuesta de cambio
especifica.
_Análisis del cambio y cálculo de costes: El efecto de un cambio propuesto se valora
utilizando la información de rastreo y el conocimiento general de los requerimientos del
sistema. El coste de hacer un cambio se estima en términos de modificaciones al
documento de requerimientos y al diseño e implementación.
_Implementación del cambio: Se modifica el documento de requerimientos y el diseño
e implementación del sistema. Debe organizar el documento de requerimientos de
modo que pueda hacer cambios en el sin tener que hacer grandes reorganizaciones o
redactar nuevamente en gran cantidad del mismo.
Si se requiere de forma urgente un cambio en los requerimientos del sistema, existe
siempre la tentación de hacer ese cambio al sistema y entonces modificar de forma
retrospectiva el documento de requerimientos.

Modelos del sistema

los requerimientos del usuario deberían redactarse en lenguaje natural debido a que
tienen ser comprendidos por personas que no son técnicos expertos. Una técnica
ampliamente usada es documentar la especificación del sistema como un conjunto de
modelos del sistema. Perspectivas:
_Externa, se modela el contexto o entorno del sistema.
_De comportamiento, se modela el comportamiento del sistema.
_Estructural, se modela la arquitectura del sistema o la estructura de los datos
procesados por el sistema.
El modelado de objetos combina el modelado del comportamiento y de la estructura.
Un modelo del sistema omite los detalles, es una abstracción del sistema que se está
estudiando en lugar de una representación alternativa de ese sistema. Una
abstracción simplifica y resalta de forma deliberada las características más relevantes.
Ejemplos de modelos:
_Un modelo de flujo de datos: Muestran cómo se procesan los datos en el sistema en
diferentes etapas.
_Un modelo de composición: O agregación muestra como las entidades del sistema
están compuestas por otras entidades.
_Un modelo arquitectónico: muestran los principales subsistemas que componen un
sistema.
_Un modelo de clasificación: Los diagramas de clases/herencia de objetos muestran
como las entidades tienen características comunes.
_Un diagrama de estímulo-respuesta: O diagrama de transición de estados muestra
cómo reacciona el sistema a eventos internos y externos.
Modelos de contexto
Se deben definir los límites del sistema. Esto comprende trabajar con los stakeholders
del sistema para distinguir lo que es el sistema y lo que es el entorno del sistema.
Aspectos sociales y organizacionales pueden implicar que la situación de los límites de
un sistema puedan ser determinados por factores no técnicos. La producción de un
modelo arquitectónico sencillo es el primer paso en esta actividad. Los de alto nivel se
expresan normalmente como sencillos diagramas de boques en donde cada
subsistema se representa por un rectángulo con nombre, y las líneas indican las
asociaciones entre los subsistemas.
Modelos de comportamiento
Se utilizan para describir el comportamiento del sistema en su totalidad. Modelos de
flujo de datos, que modelan el procesamiento de los datos en el sistema, y modelos de
máquinas de estado, que modelan cómo el sistema reacciona a los eventos.
*Modelo de flujo de datos: Son una forma intuitiva de mostrar como los datos son
procesados por un sistema. Deberían usarse para modelar la forma en la que los
datos son procesados en el sistema existente. Son valiosos debido a que realizan un
seguimiento y documentan como los datos asociados con un proceso particular fluyen
a través del sistema. La notación usada representa el procesamiento funcional
(rectángulos redondeados), los almacenes de datos (rectángulos) y el flujo de datos
entre funciones (flechas etiquetadas).
*Modelo de máquina de estado: Describe cómo responde un sistema a eventos
internos o externos. Muestra los estados del sistema y los eventos que provocan las
transiciones de un estado a otro. Este tipo de sistema se utiliza para modelar sistemas
de tiempo real. El modelo supone que en cualquier momento el sistema está en uno
de varios estados posibles. Los rectángulos redondeados en un modelo representan
los estados del sistema. Incluyen una breve descripción de las acciones realizadas en
ese estado.
Modelos de datos
Una parte importante del modelado de sistemas es la definición de la forma lógica de
los datos procesados por el sistema. Se denomina a menudo modelos semánticos de
datos. Modelo entidad relación atributo que muestra las entidades de datos, sus
atributos asociados y las relaciones entre estas entidades. UML no incluye una
notación específica para este modelado de base de datos, ya que asume un proceso
de desarrollo orientado a objetos y modela los datos utilizando objetos y sus
relaciones.
Modelos de objetos
Para el proceso de desarrollo del software en su totalidad se usa actualmente de
forma generalizada. Los modelos de objetos que se desarrollan durante el análisis de
requerimientos pueden utilizarse para representar tanto los datos del sistema como su
procesamiento. Dichos modelos combinan algunos de los usos de los modelos de flujo
de datos y los modelos semánticos de datos. También son útiles para mostrar cómo se
clasifican las entidades en el sistema y se componen de otras entidades. El modelo de
objetos durante el análisis de requerimientos simplifica la transición entre el diseño
orientado a objetos y la programación. Una clase de objetos es una abstracción sobre
un conjunto de objetos que identifica atributos comunes y los servicios u 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 instanciaciones de la
clase de objetos, y pueden parecerse a una clase de objeto.
_El nombre de la clase de objetos está en la sección superior.
_Los atributos de la clase están en la sección intermedia.
_Las operaciones asociadas con la clase de objetos están en la sección inferior del
rectángulo.
*Modelos de herencia
Una taxonomía es un esquema de clasificación que muestra como una clase de
objetos está relacionada con otras clases a través de atributos y servicios comunes.
Las clases se organizan en una jerarquía de herencia con las clases de objetos más
generales al principio de la jerarquía. Los objetos más especializados heredan sus
atributos y servicios. Estos pueden tener sus propios atributos.
*Agregación de objetos
Algunos objetos son agrupaciones de otros objetos. Un objeto es un agregado de un
conjunto de otros objetos. La notación UML para la agregación consiste en representar
la composición incluyendo una figura de diamante colocada sobre el elemento fuente
del enlace.
*Modelado de comportamiento de objetos
Se tiene que mostrar cómo se utilizan las operaciones proporcionadas por los objetos.
Una forma de modelar comportamiento es utilizar diagramas de secuencia que
muestran la secuencia de acciones implicadas en un caso de uso. A demás también
incluye diagramas de colaboración que muestran la secuencia de mensajes
intercambiados por los objetos. Los objetos y los actores se alinean en la parte
superior del diagrama. Las flechas etiquetadas indican las operaciones.
Métodos estructurados
Es una forma sistemática de elaborar modelos existentes o de un sistema que tiene
que ser construido. Proporcionan un marco para el modelado detallado de sistemas
como parte de la elicitación y análisis de requerimientos. Definen un proceso que
puede utilizarse para derivar estos modelos y un conjunto de reglas y guías de
aplicación a dichos modelos. Se genera una documentación estándar para el sistema.
Inconvenientes:
_No proporcionan un soporte efectivo para la comprensión o el modelado de
requerimientos del sistema no funcionales.
_No discriminan en tanto que normalmente incluyen guías que ayuden a los usuarios a
decidir si un método es adecuado para un problema en concreto.
_A menudo generan demasiada documentación.
_los modelos producidos son muy detallados, y los usuarios los encuentran difíciles de
entender.
Herramientas que soportan métodos completos:
_Editores de diagramas: Utilizados para crear modelos de objetos, modelos de datos,
modelos de comportamiento, etc.
_Herramientas de análisis y comprobación de diseños: procesan el diseño e informan
sobre errores y anomalías.
_Lenguajes de consulta del repositorio: Permiten al diseñador encontrar diseños e
información asociada a los diseños en el repositorio.
_Un diccionario de datos: Mantiene información sobre las entidades utilizadas en el
diseño de un sistema.
_Herramientas de generación y definición de informes: Obtienen información del
almacén central y generan automáticamente la documentación del sistema.
_Herramientas de definición de formularios: Permiten especificar los formatos de
pantallas y de documentos.
_Facilidades para importar/exportar: Permiten el intercambio de información desde el
repositorio central con otras herramientas de desarrollo.
_Generadores de código: Generan código o esqueletos de código de forma automática
a partir del diseño capturado en el almacén central