Desarrollo Del Modulo (1 Unidad)

ANALISIS Y DISEÑO DE SISTEMAS
CORPORACIÓN IBEROAMERICANA
DE CIENCIA Y TECNOLOGIA CIBERCTEC
MÓDULO
PRIMERA UNIDAD
CICLO DE VIDA DE SOFTWARE
AUTOR:
Leyder Hernán López Díaz
Ingeniero de Sistemas
VILLAVICENCIO 2012
1
C o r p o r a c i o n I b e r o a m e r i c a d e C i e n c i a y Te c n o l o g i a C I B E R C T E C S A S
REGISTRO DEL ESTUDIANTE
NOMBRE DEL ESTUDIANTE : ______________________
____________________________________________________
PROGRAMA: ________________________________________
JORNADA: __________________________________________
NOMBRE DEL DOCENTE : ____________________________
FECHA : DEL __________ AL ___________
CALIFICACION: _______________________________________
_____________________
FIRMA DEL DOCENTE
2
TABLA DE CONTENIDO
PAG
1. PRIMERA UNIDAD: CICLO DE VIDA DE SOFTWARE ......................................3

2. OBJETIVO GENERAL..........................................................................................4
2.1 Objetivos Específicos....................................................................................4
3. PRUEBA INICIAL..................................................................................................5
3.1 Tema 1: Ciclo de vida de Software................................................................6
3.1.1 Ciclos de vida en cascada ..................................................................7
3.1.2 Ciclo de vida en V ................................................................................9
3.1.3 Ciclo de vida sashimi .......................................................................10
3.1.4 Ciclo de vida en cascada con subproyectos ..................................10
3.1.5 Ciclo de vida en cascada incremental .............................................11
3.1.6 Ciclo de vida en cascada con reducción de riesgos .....................11
3.1.7 Modelo de ciclo de vida en espiral ..................................................12
3.1.8 Ciclos de vida orientados a objetos ................................................14
3.1.9 EJERCICIOS DEL TEMA....................................................................15
3.1.10 EJERCICIOS PARA DESARROLLAR..............................................16
3.2 Tema 2: Los requerimientos .......................................................................17
3.2.1 Procesos de Ingeniería Software .....................................................19
3.2.2 Métricas para especificar requerimientos no funcionales ............22
3.2.3 Cadena de responsabilidades...........................................................24
3.2.4 Casos de Uso de Negocio..................................................................27
3.2.5 EJERCICIOS DEL TEMA.....................................................................29
3.2.6 EJERCICIOS PARA DESARROLLAR................................................30
3.3 PRUEBA FINAL.............................................................................................31
4. PISTAS DE APRENDIZAJE................................................................................32
5. GLOSARIO..........................................................................................................33
6. BIBLIOGRAFÍA...................................................................................................34
3
MODULO: ANALISIS Y DISEÑO DE SISTEMAS
ESTÁNDAR DE COMPETENCIAS DEL MODULO
COMPONENTE TELEINFORMATICA
220501007 Construir el sistema que cumpla con
COMPETENCIA los requisitos de la solución informática.
220501007 1 Diseñar el software de acuerdo con el
concepto. OB
220501007 2 Desarrollar la lógica y mecánica del
software de acuerdo con el diseño establecido.
220501007 3 Desarrollar la lógica y mecánica del
ELEMENTO videojuego de acuerdo con el diseño establecido. OB
220501007 4 Implementar el arte y audio en el
videojuego de acuerdo con el diseño. OB
220501007 5 Depurar el videojuego de acuerdo con
las pruebas realizadas.
1. Diseñar modelos de prueba de
aplicaciones informáticas.
CAMPO DE ACCION 2. Implementación de lenguajes de
(Capacidad) programación para realizar pruebas.
INTENSIDAD HORARIA
NUMERO DE SEMANAS 1
INTENSIDAD HORARIA 12
PRACTICA 8
TEORICA 4
4
1. CICLO DE VIDA DEL SOFTWARE
Se conoce como software al equipamiento lógico o soporte lógico de un sistema

informático, comprende el conjunto de los componentes lógicos necesarios que
hacen posible la realización de tareas específicas, en contraposición a los
componentes físicos, que son llamados hardware. Los componentes lógicos
incluyen, entre muchos otros, las aplicaciones informáticas; tales como
el procesador de texto, que permite al usuario realizar todas las tareas
concernientes a la edición de textos; el software de sistema, tal como el sistema
operativo, que, básicamente, permite al resto de los programas funcionar
adecuadamente, facilitando también la interacción entre los componentes físicos y
el resto de las aplicaciones, y proporcionando una interfaz con el usuario.
El anglicismo "software" es el más ampliamente difundido, especialmente en

la jerga técnica, el término sinónimo "logical", derivado del término
francés "logiciel", es utilizado en países y zonas de habla francesa. Existen varias
definiciones similares aceptadas para software, pero probablemente la más formal
sea la siguiente:
Es el conjunto de los programas de cómputo, procedimientos, reglas,

documentación y datos asociados que forman parte de las operaciones de un
sistema de computación. Considerando esta definición, el concepto de software va
más allá de los programas de computación en sus distintos estados: código
fuente, binario o ejecutable; también su documentación, los datos a procesar e
incluso la información de usuario forman parte del software: es decir, abarca todo
lo intangible, todo lo «no físico» relacionado. El término «software» fue usado por
primera vez en este sentido por John W. Tukey en 1957. En la ingeniería de
software y las ciencias de la computación, el software es toda
la información procesada por los sistemas informáticos: programas y datos.
5
2. OBJETIVO GENERAL
Desarrollar habilidades de modelado con miras al desarrollo de soluciones

informáticas a problemas prácticos, empleando para ello un enfoque
metodológico.
2.1 Objetivos Específicos
 Caracterizar los diferentes diagramas de UML (Unified Modeling Languaje)

y otros artefactos necesarios para la definición, análisis y diseño orientados
a objetos de soluciones informáticas.
 Emplear los lineamientos teóricos del objetivo anterior en la solución de

ejercicios de modelado.
 Garantizar el desarrollo de habilidades para la elaboración de modelos en

diferentes métodos de desarrollo.
6
3 PRUEBA INICIAL
Un personaje X le solicita a un experto la construcción de un columpio. De

acuerdo a la siguiente imagen, analizar cada uno de los procesos y concluir al
final:
7
3.1 Tema 1 Ciclo de vida de Software
Al igual que en otros sistemas de ingeniería, los sistemas de software requieren un

tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por
un periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que se
detecta la necesidad de construir un sistema de software hasta que este es
retirado, se identifican varias etapas que en conjunto se denominan el ciclo de vida
del software y en cada caso, en función de cuales sean las características del
proyecto, se configurará el ciclo de vida de forma diferente.
Usualmente se consideran las etapas: especificación y análisis

de requisitos, diseño del sistema, implementación del software, aplicación
y pruebas, entrega y mantenimiento. Un aspecto esencial dentro de las tareas del
desarrollo del software es la documentación de todos los elementos y
especificaciones en cada fase.
Dado que esta tarea siempre estará influida por la fase del desarrollo en curso, se
explicará de forma distribuida a lo largo de las diferentes fases como un apartado
especial para recalcar su importancia en el conjunto del desarrollo del software.
Tal como ya hemos mencionado, las etapas principales a realizar en cualquier

ciclo de vida son:
1. Análisis: Construye un modelo de los requisitos
2. Diseño: A partir del modelo de análisis se deducen las estructuras de

datos, la estructura en la que descompone el sistema y la interfaz de
usuario.
3. Codificación: Construye el sistema. La salida de esta fase es código

ejecutable.
4. Pruebas: Se comprueba que se cumplen criterios de corrección y calidad.
5. Mantenimiento: En esta fase, que tiene lugar después de la entrega se

asegura que el sistema siga funcionando y adaptándose a nuevos
requisitos.
Las etapas constan de tareas. La documentación es una tarea importante que se

realiza en todas las etapas. Cada etapa tiene como entrada uno o varios
documentos procedentes de las etapas anteriores y produce otros documentos de
salida
8
Algunos autores dividen la fase del diseño en dos partes: Diseño global o
arquitectónico y diseño detallado. En el primero se transforman los requisitos en
una arquitectura de alto nivel, se definen las pruebas que debe satisfacer el
sistema en su conjunto, se esboza la documentación y se planifica la integración.
En el detallado para cada módulo se refina el diseño, se definen los requisitos del
módulo y su documentación.
Las formas de organizar y estructurar la secuencia de ejecución de las tareas en

las diferentes fases de cada uno de los métodos pueden dar lugar a un tipo de
ciclo de vida diferente. Los principales ciclos de vida que se van a presentar a
continuación realizan estas tareas. Cada uno de ellos tiene sus ventajas e
inconvenientes.
1.1.1 Ciclos de vida en cascada

El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el
software a partir de ciclos de vida de otras ramas de la ingeniería. Es el primero de
los propuestos y el más ampliamente seguido por las organizaciones (se estima
que el 90% de los sistemas han sido desarrollados así)
9
Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las

modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la
necesidad de cambiar algo en el diseño, lo cual significa que se harán los cambios
necesarios en la codificación y se tendrán que realizar de nuevo las pruebas, es
decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay
que recorrer de nuevo el resto de las etapas.
Después de cada etapa se realiza una revisión para comprobar si se puede pasar
a la siguiente. Trabaja en base a documentos, es decir, la entrada y la salida de
cada fase es un tipo de documento específico. Idealmente, cada fase podría
hacerla un equipo diferente gracias a la documentación generada entre las fases.
Los documentos son:
 Análisis: Toma como entrada una descripción en lenguaje natural de lo que

quiere el cliente. Produce el S.R.D. (Software Requirements Document).
 Diseño: Su entrada es el S.R.D. Produce el S.D.D. (Software Design

Document)
 Codificación: A partir del S.D.D. produce módulos. En esta fase se hacen

también pruebas de unidad.
 Pruebas: A partir de los módulos probados se realiza la integración y

pruebas de todo el sistema. El resultado de las pruebas es el producto final
listo para entregar.
Ventajas
 La planificación es sencilla.
 La calidad del producto resultante es alta.
 Permite trabajar con personal poco cualificado.
Inconvenientes
 Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal

es que el cliente no tenga perfectamente definidas las especificaciones del
sistema, o puede ser que surjan necesidades imprevistas.
 Si se han cometido errores en una fase es difícil volver atrás.
10
 No se tiene el producto hasta el final, esto quiere decir que:
o Si se comete un error en la fase de análisis no lo descubrimos hasta

la entrega, con el consiguiente gasto inútil de recursos.
o El cliente no verá resultados hasta el final, con lo que puede
impacientarse.
 No se tienen indicadores fiables del progreso del trabajo (síndrome del

90%).
 Es comparativamente más lento que los demás y el coste es mayor

también.
Tipos de proyectos para los que es adecuado
 Aquellos para los que se dispone de todas las especificaciones desde el

principio, por ejemplo, los de reingeniería.
 Se está desarrollando un tipo de producto que no es novedoso.
 Proyectos complejos que se entienden bien desde el principio.
1.1.2 Ciclo de vida en V
Propuesto por Alan Davis, tiene las mismas fases que el anterior pero se
considera el nivel de abstracción de cada una. Una fase además de utilizarse
como entrada para la siguiente, sirve para validar o verificar otras fases
posteriores
11
1.1.3 Ciclo de vida tipo sashimi
Según el modelo en cascada puro una fase solo puede empezar cuando ha
terminado la anterior. En este caso sin embargo, se permite un solapamiento entre
fases. Por ejemplo, sin tener terminado del todo el diseño se comienza a
implementar.
El nombre ``sashimi'' deriva del modo del estilo de presentación de rodajas de

pescado crudo en Japón. Una ventaja de este modelo es que no necesita generar
tanta documentación como el ciclo de vida en cascada puro debido a la
continuidad del mismo personal entre fases. Los problemas planteados son:
 Es aún más difícil controlar el progreso del proyecto debido a que los finales
de fase ya no son un punto de referencia claro.
 Al hacer cosas en paralelo si hay problemas de comunicación pueden surgir

inconsistencias.
La fase de ``concepto'' consiste en definir los objetivos del proyecto, beneficios,

tipo de tecnología y el tipo de ciclo de vida. El diseño arquitectónico es el de alto
nivel, el detallado el de bajo nivel.
1.1.4 Ciclo de vida en cascada con subproyectos
Si una vez que se ha llegado al diseño arquitectónico, se comprueba que el

sistema se divide en varios subsistemas independientes entre sí, sería razonable
suponer que a partir de ese punto cada uno se puede desarrollar por separado y
12
en consecuencia en paralelo con los demás. Cada uno tendrá seguramente fechas
de terminación distintas. Una vez que han terminado todos se integran y se prueba
el sistema en su conjunto. La ventaja es que se puede tener a más gente
trabajando en paralelo de forma eficiente. El riesgo es que existan
interdependencias entre los subproyectos.
1.1.5 Ciclo de vida en cascada incremental
En este caso se va creando el sistema añadiendo pequeñas funcionalidades.

Cada uno de los pequeños incrementos es parecido a lo que ocurre dentro de la
fase de mantenimiento. La ventaja de este método es que no es necesario tener
todos los requisitos en un principio. El inconveniente es que los errores en la
detección de requisitos se encuentran tarde.
Hay dos partes en el ciclo de vida, similares al anterior. Por un lado está el análisis
y el diseño global. Por otra parte están los pequeños incrementos, con las fases
de diseño detallado, codificación y mantenimiento.
1.1.6 Ciclo de vida en cascada con reducción de riesgos
Como se ha comentado anteriormente, uno de los problemas del ciclo de vida en

cascada es que si se entienden mal los requisitos esto sólo se descubrirá cuando
se entregue el producto. Para evitar este problema se puede hacer un desarrollo
iterativo durante las fases de análisis y diseño global.
13
Esto consistiría en:
1. Preguntar al usuario.
2. Hacer el diseño global que se desprende del punto 1.
3. Hacer un prototipo de interfaz de usuario, entrevistas con los usuarios, etc y

volver con ello al punto 1 para identificar más requisitos o corregir
malentendidos.
El resto es igual al ciclo de vida en cascada.
1.1.7 Modelo de ciclo de vida en espiral
Propuesto inicialmente por Boehm en 1988. Consiste en una serie de ciclos que
se repiten. Cada uno tiene las mismas fases y cuando termina da un producto
ampliado con respecto al ciclo anterior. En este sentido es parecido al modelo
incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo.
Un riesgo puede ser muchas cosas: requisitos no comprendidos, mal diseño,
errores en la implementación, etc.
14
En cada iteración Boehm recomienda recopilar la siguiente lista de informaciones:
 Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar

cuestionarios, etc.
 Alternativas: Son las diferentes formas posibles de conseguir los objetivos.

Se consideran desde dos puntos de vista
o Características del producto.

o Formas de gestionar el proyecto.
 Restricciones:

o Desde el punto de vista del producto: Interfaces de tal o cual manera,
rendimiento, etc.
oDesde el punto de vista organizativo: Coste, tiempo, personal, etc.

 Riesgos: Lista de riesgos identificados.
 Resolución de riesgos: La técnica más usada es la construcción de

prototipos.
 Resultados: Son lo que realmente ha ocurrido después de la resolución de

riesgos.
 Planes: Lo que se va a hacer en la siguiente fase.
 Compromiso: Decisiones de gestión sobre como continuar.
Al terminar una iteración se comprueba que lo que se ha hecho efectivamente

cumple con los requisitos establecidos, también se verifica que funciona
correctamente. El propio cliente evalúa el producto.
No existe una diferencia muy clara entre cuando termina el proyecto y cuando
empieza la fase de mantenimiento. Cuando hay que hacer un cambio, este puede
consistir en un nuevo ciclo.
Ventajas
 No necesita una definición completa de los requisitos para empezar a

funcionar.
 Al entregar productos desde el final de la primera iteración es más fácil

validar los requisitos.
15
 El riesgo en general es menor, porque si todo se hace mal, solo se ha

perdido el tiempo y recursos invertidos en una iteración (las anteriores
iteraciones están bien).
 El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en

etapas tempranas hay tiempo de subsanarlos.
Inconvenientes
 Es difícil evaluar los riesgos.
 Necesita de la participación continua por parte del cliente.
 Cuando se subcontrata hay que producir previamente una especificación

completa de lo que se necesita, y esto lleva tiempo.
Dónde es adecuado
 Sistemas de gran tamaño.
 Proyectos donde sea importante el factor riesgo.
 Cuando no sea posible definir al principio todos los requisitos.
3.1.8 Ciclos de vida orientados a objetos
Los tipos de ciclos de vida que se han visto hasta ahora son relativos al análisis y
diseño estructurados, pero los objetos tienen una particularidad, y es que están
basados en componentes que se relacionan entre ellos a través de interfaces, o lo
que es lo mismo, son mas modulares y por lo tanto el trabajo se puede dividir en
un conjunto de miniproyectos. Además, hoy en día la tendencia es a reducir los
riesgos, y en este sentido, el ciclo de vida en cascada no proporciona muchas
facilidades. Debido a todo esto, el ciclo de vida típico en una metodología de
diseño orientado a objetos es iterativo e incremental.
Modelo fuente
Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida

pensado para la orientación a objetos y posiblemente el más seguido. Un proyecto
se divide en las fases:
1. Planificación del negocio
2. Construcción: Es la más importante y se divide a su vez en otras cinco

actividades
16
o Planificación
o Investigación
o Especificación
o Implementación
o Revisión
3. Entrega
La primera y la tercera fase son independientes de la metodología de desarrollo

orientado a objetos. Además de las tres fases, existen dos periodos:
1. Crecimiento: Es el tiempo durante el cual se construye el sistema
2. Madurez: Es el periodo de mantenimiento del producto. Cada mejora se

planifica igual que el periodo anterior, es decir, con las fases de
Planificación del negocio, Construcción y Entrega.
Cada clase puede tener un ciclo de vida sólo para ella debido a que cada una
puede estar en una fase diferente en un momento cualquiera. La ventaja es que
permite un desarrollo solapado e iterativo.
3.1.9 EJERCICIO DEL TEMA
Se supone que se va desarrollar una aplicación relativa a la gestión de pedidos de

una empresa. En este caso el cliente no tiene todavía muy claro qué es lo que
quiere. Además, el personal informático va a utilizar una tecnología que le resulta
completamente nueva. Discútase qué tipo de ciclo de vida es más apropiado y qué
procesos se deberían utilizar para desarrollar esta aplicación .
Se utilizaría el modelo en espiral, con este modelo se ataca plenamente el

problema de que el cliente no tenga claridad en su requerimiento, ya que al dividir
17
el proyecto en ciclos o iteraciones se permite dar vuelta atrás fácilmente,

reduciendo en gran medida riegos (gestión de riesgos) como el alargamiento del
tiempo y comenzar de nuevo, se adoptan planes para cada iteración garantizando
así calidad, además se cuenta con una comunicación paralela entre el proyecto y
el usuario, Aplicaría los siguientes procesos:
 Adquisición
 Suministro
 Desarrollo (Planificación (Plan de Requisitos y Plan del Ciclo de Vida),
Análisis de riesgos, Requisitos y arquitectura del sistema y software,
Prototipos, evaluaciones del cliente, sistema de ingeniería, implementación)
 Mantenimiento
 Soporte (documentación, revisión conjunta, verificación, resolución de
problemas)
* Infraestructura
* Mejora
* Formación
3.1.10 EJERCICIOS PARA DESARROLLAR
 Describa brevemente qué significan los siguientes términos:
a) Metodología de desarrollo de software.

b) Modelo de Ciclo de Vida para el desarrollo de software.
c) Etapa dentro de un ciclo de vida.
d) Rol que puede cumplir una persona en el desarrollo de software.
e) Modelo/diagrama de las características de un sistema de software y
sus partes componentes.
 Describa brevemente en qué situaciones es imprescindible seguir una

metodología, para el desarrollo de software, y en cuáles situaciones no lo
sería tanto.
 Enumere las categorías más comunes de metodologías existentes, para el

desarrollo de software, junto con sus características principales.
 Enumere los modelos de ciclo de vida más comunes, para el desarrollo de

software, junto con sus características principales.
18
3.2 Tema 2 Los requerimientos
Situación de la Industria de Software
• Más del 30% de todos los proyectos de software son cancelados antes de su
finalización.
• Mas del 70% de los proyectos restantes fallan al entregar y evaluar las
características esperadas.
• Un proyecto promedio ejecuta 189% sobre el presupuesto aprobado y extiende
sus actividades sobre el 222%.
Porqué los Proyectos de Software son exitosos?
• Involucra a Usuarios 15.9%

• Soporte Administración 13.9%
• Clara definición de Requerimientos 13.0%
• Apropiado Planeamiento 9.6%
• Expectativas Realistas 8.2%
• Hitos no Extensos 7.7%
• Staff Competente de profesionales 7.2%
• Propietario 5.3%
Porqué los Proyectos de Software fallan?
• Requerimientos Incompletos 13.1%

• Falta de Requerimientos 12.4%
• Falta de Recursos 10.6%
• Expectativas no Realistas 9.9%
• Cambio Requerimientos/Especificaciones 8.7%
• Falta de Planeamiento 8.1%
• No se especifico el tiempo adecuado 7.5%
Qué es un Requerimiento?
• Un requerimiento es una condición o capacidad a la que el sistema (siendo

construido) debe conformar.
• Un requerimiento de software puede ser definido como:
– Una capacidad del software necesaria por el usuario para resolver un problema
o alcanzar un objetivo.
19
– Una capacidad del software que debe ser reunida o poseída por un sistema o
componente del sistema para satisfacer un contrato, especificación, estándar, u
otra documentación formal.
Qué son Requerimientos?
• Los requerimientos de usuario representan el conjunto completo de resultados a

ser obtenidos utilizando el sistema.
• Los requerimientos de sistemas deben mostrar todo lo que el sistema debe hacer
más todas las restricciones sobre la funcionalidad.
• Los requerimientos forman un modelo completo, representando el sistema total a
algún nivel de abstracción.
Rol de Requerimientos
• Si un producto no es lo que el cliente o los usuarios quieren, entonces la calidad

de la construcción es irrelevante.
• El rol clave de los requerimientos es mostrar a los desarrolladores y usuarios que
se necesita de un sistema. Proveer los requerimientos forma parte de un lenguaje
que todos comprenden, ya que todos están involucrados, incluyendo los clientes.
• El primer y básico rol de los requerimientos es por lo tanto la comunicación.
Cómo identificamos los Requerimientos?
• Los Requerimientos toman vida desde que realizamos nuestro primer encuentro
de interlocución con usuarios o clientes.
• Este puede desarrollarse utilizando cualquiera de una variedad de técnicas como
entrevistas para intercambiar opiniones, brainstorming, prototipeo, cuestionarios,
etc.
• Cuando los requerimientos se logran redactar a un significativo nivel de detalle,
tendremos listo el documento denominado “Especificación de Requerimientos”.
Buena Especificación de Requerimientos
• Un resultado primario de esta administración es la Especificación de

Requerimientos, la cual define y documenta en forma completa el comportamiento
externo del sistema a ser construido. Caracterizándose por:
– Definidos sin ambiguedad

– Son completos
– Tienen consistencia
– Especifica el origen
– Evita detalles de diseño
– Están enumerados
20
Beneficios de una Buena Administración de Requerimientos
• Mejor control de proyectos complejos.

• Mejora en la calidad del software y en la satisfacción del cliente.
• Reducción en los retrasos y en los costos del proyecto.
• Mejora en la comunicación del equipo.
• Facilita la conformidad con estándares y regulaciones.
Los Problemas de la Administración de Requerimientos
• No son siempre obvios y tienen muchas fuentes.

• No son siempre fáciles de expresar en palabras.
• Hay muchos tipos diferentes a distintos niveles de detalle.
• El número puede llegar a ser inmanejable.
• Están relacionados a otros en una variedad de formas.
• Hay muchos interesados y partes responsables.
• Cambian.
• Pueden ser sensibles al tiempo.
El Alto Costo de Errores en los Requerimientos
• Hay fuertes evidencias que una efectiva administración de requerimientos

conducen los ahorros del proyecto integral.
• Las tres razones primarias para esto son:
– Costos de reparar errores en los requerimientos superan en más de 10 veces a

otros errores.
– Errores de requerimientos comprenden encima del 40% de todos los errores de
un proyecto de software.
– Pequeños reducciones en el número de errores de requerimientos rinden
grandes dividendos al evitar costos de re-trabajo y días de retraso.
3.2.1 Procesos de Ingeniería Software
“Un Proceso es el conjunto total de actividades de ingeniería necesarias para

transformar dentro de software los requerimientos de usuarios”.
21
Requerimientos del Dominio
• Se derivan del dominio del sistema más que de las necesidades específicas de
los usuarios. Pueden ser requerimientos funcionales nuevos, restringir los
existentes o establecer cómo se deben ejecutar cálculos particulares.
• Los requerimientos del dominio son importantes debido a que a menudo reflejan
los fundamentos del dominio de aplicación.
• Si estos requerimientos no se satisfacen, es imposible hacer que el sistema
trabaje de forma satisfactoria.
Ejemplo.
Definición de Requerimientos de Usuario
1. El software debe proveer un medio para representar y acceder a archivos

externos creados por otras herramientas.
Especificación de Requerimientos del sistema
1.1 Al usuario se le proveerá con los recursos para definir el tipo de archivos
externos.
1.2 Cada tipo de archivo externo tendrá una herramienta asociada que será
aplicada al archivo.
1.3 Cada tipo de archivo externo se representará como un icono especifico sobre
la pantalla del usuario.
1.4 Se proveerán recursos para que el usuario defina el icono que representa un
tipo de archivo externo.
1.5 Cuando un usuario selecciona un icono que representa un archivo externo, el

efecto de esa selección es aplicar la herramienta asociada con este tipo de archivo
al archivo representado por el icono seleccionado.
Requerimientos Funcionales
• Describen la funcionalidad o los servicios que se espera proveerá el sistema.
• Estos dependen del tipo de software y del sistema que se desarrolle y de los
posibles usuarios del software.
• Cuando se expresan como requerimientos del usuario, habitualmente se

describen de forma general mientras que los requerimientos funcionales del
22
sistema describen con detalle la función de éste, sus entradas y salidas,

excepciones, etc.
Sistema de Biblioteca
1. El usuario deberá tener la posibilidad de buscar referencias bibliográficas en el

conjunto inicial de la base de datos o seleccionar un subconjunto de ella.
2. El sistema deberá proveer visores adecuados para que el usuario lea

documentos en el almacén de documentos.
3. A cada pedido se le deberá asignar un identificador único que el usuario podrá

copiar al área de almacenamiento permanente de la cuenta.
Análisis de la especificación de Requerimientos
• El sistema de biblioteca puede almacenar documentos en diferentes formatos y

la intención de este requerimiento es que los visores para todos estos formatos
estén disponibles.
• Sin embargo, el requerimiento es ambiguo puesto que no clarifica que los visores
para cada formato deban ser provistos.
• Un desarrollador bajo la presión del tiempo sencillamente podría proporcionar un

visor de texto y afirmar que se ha cumplido el requerimiento.
Requerimientos No Funcionales
• Son aquellos requerimientos que no se refieren directamente a las funciones

específicas que entrega el sistema, sino a las propiedades emergentes de éste
como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento.
• De forma alternativa, definen las restricciones del sistema, como la capacidad de

los dispositivos de entrada/salida y la representación de datos que se utiliza en las
interfaces del sistema.
• Sin embargo, estos requerimientos no siempre se refieren al sistema de software

a desarrollar.
23
3.2.2 Métricas para especificar requerimientos no funcionales
PROPIEDAD MEDIDA
Rapidez • Transacciones procesadas por segundo
• Tiempo de respuesta al usuario y a eventos
• Tiempo de actualización de la pantalla
Tamaño • KB’s
• Tamaño de RAM
Facilidad de uso • Tiempo de capacitación
• Número de ventanas de ayuda
Fiabilidad • Tiempo promedio entre fallas
• Probabilidad de no disponibilidad
• Tasa de ocurrencia de las fallas
• Disponibilidad
Robustez • Tiempo de reinicio después de fallas
• Porcentaje de eventos que provocan las fallas
• Probabilidad de corrupción de los datos después de las
fallas
Portabilidad • Porcentaje de declaraciones dependientes del objetivo
• Número de sistemas objetivo
24
Identificación de Requerimientos y Reglas del Negocio
• Para identificar los requerimientos correctos del negocio primero debemos de

comprender como funciona, es decir cuales son las reglas del negocio.
• Mientras más complejo es el sistema una mayor cantidad de vistas del mismo
son necesarias para comprender su funcionamiento.
• Las distintas vistas del negocio pueden conseguirse a través de un mapeo de la
situación actual (AS-IS) utilizando a un alto nivel:
– El Diagrama de descomposición funcional o mapeo de procesos.

– Las cadenas de responsabilidad para la atención de los requerimientos
– Los Diagramas de Actividad
– Los Diagramas de Colaboración
– Los Diagramas de Interacción de Roles
– Casos de Uso del Negocio
25
Cadena de Responsabilidades
• Es la cadena funcional que se establece para la atención de un requerimiento.
• Una cadena involucra las interacciones producto de los requerimientos de un

actor externo al negocio (cliente o proveedor) con las responsabilidades de un
trabajador de negocio.
3.2.3 Cadena de responsabilidades
26
• La cadena eslabona a las unidades organizacionales de los trabajadores de

negocio, que intervienen como consecuencia de las responsabilidades de cada
uno y a través de la interacción entre ellos (cumpliendo un rol) y de estos con el
actor de negocio externo (cliente o proveedor).
Diagrama de Interacción de Roles
• Un diagrama que muestra las actividades de cada actor interno o externo como
consecuencia de su interacción para la atención de un requerimiento.
• Los roles de usuario son definidos en los rectángulos de la parte superior de
cada línea de rol vertical.
• Modela la interacción entre diferentes actores, incluyendo al cliente, dentro de un
proceso de negocios.
• Este ilustra el flujo de trabajo (líneas verticales gruesas) hechas por diferentes
roles (líneas verticales delgadas) vía los eventos que causan la interacción
(flechas horizontales).
Diagrama de Interacción de Roles
• Los puntos de inicio y término son círculos, y las actividades son las líneas
gruesas asignadas a cada rol de usuario.
• Las flechas definen las condiciones para la transición entre estas entidades.
27
Diagrama de colaboración
• Es un diagrama que permite representar la forma en la que colaboran los

trabajadores de negocio para satisfacer un requerimiento de un actor de negocio,
así como representar las entidades relacionadas.
• Documentan como interactúan los trabajadores de negocio y las entidades del

negocio para ejecutar una función de negocio, mostrando los mensajes
intercambiados entre ellos.
• Una entidad es alguna cosa manejada o utilizada por los trabajadores de

negocio.
Diagrama de Colaboración
Diagrama de Actividades
• Es un diagrama que presenta una vista alternativa a las actividades que realiza
cada actor externo o interno para la atención de un requerimiento, y que puede
utilizarse como complemento a la vista mostrada a través de una cadena de
responsabilidades.
• En el diagrama se muestran un nodo de inicio, actividades, decisiones, barras de

bifurcación y/o de sincronización, y un nodo final.
28
3.2.4 Casos de Uso de Negocio
• Un caso de uso es la cadena de interacciones entre un actor de negocio (cliente,

proveedor o trabajador) y el sistema (la empresa, una unidad organizacional o un
proceso del negocio) con la finalidad de satisfacer un requerimiento o alcanzar un
objetivo.
• Una secuencia de acciones que produce un resultado de valor para un particular

actor de negocio.
Negocio vs. Sistema
• Cada trabajador de negocio identificado en el modelo del negocio es un potencial

actor del sistema.
• Cada actor del negocio también es un potencial actor del sistema, si este actor
de negocio interactúa directamente con el sistema bajo desarrollo.
• Cada caso de uso de negocio es un candidato a caso de uso del sistema.
29
Ejemplo de un Diagrama de Casos de Uso de Negocio
3.2.5 EJERCICIO DEL TEMA
Analizar y desarrollar el caso de uso del famoso juego Buscaminas
¿Qué casos de uso identificamos?
 Iniciar una nueva partida.

 Descubrir una casilla.
 Marcar una casilla.
30
¿Quién realiza estos casos de uso?
 El jugador.
31
3.2.6 EJERCICIOS PARA DESARROLLAR
Para cada una de las siguientes afirmaciones indicar si es Verdadera o Falsa:
Verdadera / Falsa
Los actores de un sistema representan, en particular,
personas (mas precisamente roles que interpretan
personas), dispositivos u otros sistemas, y en general,
cualquier cosa que interactúa con dicho sistema.
Los casos de uso, sus especificaciones y el diagrama de
casos de uso de un sistema permiten acordar, entre el
equipo de desarrollo y el cliente, los límites y los requisitos
funcionales de dicho sistema.
La especificación de un caso de uso describe cómo se
implementa el comportamiento requerido para el sistema en
dicho caso de uso.
Un escenario representa una instancia de un caso de uso.
El diagrama de casos de uso de un sistema puede
organizarse por medio de relaciones que se pueden dar
entre los diferentes casos de uso. Estas relaciones son las
de: generalización/especialización, inclusión, y extensión.
Debería utilizarse una relación de extensión, entre casos de
32
uso, cuando es necesario factorizar el comportamiento

común a varios casos de uso en otro caso de uso.
Un caso de uso incluido en otros, es un caso de uso que es
“usado” por esos otros casos de uso. El caso de uso “usado”
se “activa” toda vez que el caso de uso que lo usa se
“activa”.
33
3.3 PRUEBA FINAL
Realice el caso de uso para los siguientes casos:
1) Creación de un grupo o comunidad virtual en yahoo.com

2) Compra del ticket del metro, tanto por taquilla como por la máquina
3) Comprar café en una máquina expendedora
4) Ingresar al comedor de la UBV
34
4. PISTAS DE APRENDIZAJE
Tener en cuenta: La ingeniería del software permite al diseñador de programas,

realizar su tarea de construcción de software como un problema de ingeniería
haciendo uso de guías, principios y normas que le permitirán el correcto desarrollo
de su labor. Adicionalmente, dispondrá de un conjunto de herramientas que le
permitirán la evaluación, validación, depuración y corrección del software
desarrollado.
Tener presente: El ciclo de vida del software es la forma mediante la cual se

describen los diferentes pasos que se deben seguir para el desarrollo de un
software, partiendo desde una necesidad hasta llegar a la puesta en marcha de
una solución y su apropiado mantenimiento. El ciclo de vida para un software
comienza cuando se tiene la necesidad de resolver un problema, y termina cuando
el programa que se desarrolló para cumplir con los requerimientos, deja de ser
utilizado.
Traer a la memoria: Un caso de uso es una descripción de los pasos o las

actividades que deberán realizarse para llevar a cabo algún proceso. Los
personajes o entidades que participarán en un caso de uso se denominan actores.
En el contexto de ingeniería del software, un caso de uso es una secuencia de
interacciones que se desarrollarán entre un sistema y sus actores en respuesta a
un evento que inicia un actor principal sobre el propio sistema. Los diagramas de
casos de uso sirven para especificar la comunicación y el comportamiento de un
sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es
igual, un diagrama que muestra la relación entre los actores y los casos de uso en
un sistema. Una relación es una conexión entre los elementos del modelo, por
ejemplo la especialización y la generalización son relaciones. Los diagramas de
casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar
cómo reacciona a eventos que se producen en su ámbito o en él mismo.
35
5. GLOSARIO
Análisis de requisitos. Proceso de estudio de las necesidades del usuario para

conseguir una definición de los requisitos del sistema o del software. Proceso de
estudiar y desarrollar los requisitos del sistema o del software.
Ciclo de vida. Periodo de tiempo que comienza con la concepción del producto de
software y termina cuando el producto esta disponible para su uso. Normalmente,
el ciclo de vida del software incluye las fases de concepto, requisitos, diseño,
implementación, prueba, instalación, verificación, validación, operación y
mantenimiento, y, en ocasiones, retirada. Nota: Esta fases pueden superponerse o
realizarse iterativamente.
Especificación de requisitos de software. Documentación de requisitos

fundamentales (necesarios, esenciales e indispensables) de funcionalidades,
rendimiento, restricciones y atributos del software, y sus interfaces externas.
Flexibilidad. Facilidad con la que un sistema o un componente pueden

modificarse para ser empleado con aplicaciones o en entornos distintos para los
que fue construido.
Gestión de configuración. Disciplina que aplica la dirección y supervisión técnica

y administrativa para: identificar y documentar las características funcionales y
físicas de un elemento de configuración, controlar cambios, registrar cambios
procesados, registrar el estado de la implementación, informar y verificar la
conformidad con los requisitos especificados.
Gestión de procesos. Dirección, control y coordinación del trabajo realizado para

desarrollar o producir un servicio.
36
6. BIBLIOGRAFÍA
 JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James (2000) (en

Español). El Proceso Unificado de Desarrollo de Software. Pearson Addisson-
Wesley.
 Pressman, Roger S. (2003) (en Español). Ingeniería del Software, un

enfoque Práctico (Quinta edición edición). Mc Graw Hill. ISBN84-481-3214-9.
 JACOBSON; BOOCH; RUMBAUGH (1999) (en Español). UML - El

Lenguaje Unificado de Modelado. Pearson Addisson-Wesley. Rational Software
Corporation, Addison Wesley Iberoamericana. ISBN 84-7829-028-1.
 Haeberer, A. M.; P. A. S. Veloso, G. Baum (1988) (en

Español). Formalización del proceso de desarrollo de software (Ed. preliminar
edición). Buenos Aires: Kapelusz. ISBN 950-13-9880-3.
 Fowler, Martin; Kendall Sccott (1999) (en Español). UML Gota a Gota.
Addison Wesley. ISBN 9789684443648.
 Loucopoulos, Pericles; Karakostas, V. (1995) (en inglés). System

Requirements Engineering. London: McGraw-Hill Companies. pp. 160
p.. ISBN 978-0077078430.
 Sommerville, Ian; P. Sawyer (1997) (en inglés). Requirements Engineering:

A Good Practice Guide (1ra. edition edición). Wiley & Sons. pp. 404
p.. ISBN 978-0471974444.
 Gottesdiener, Ellen; P. Sawyer (2002) (en inglés). Requirements by

Collaboration: Workshops for Defining Needs. Addison-Wesley Professional.
pp. 368 p.. ISBN 978-0201786064.
 Sommerville, Ian (2005) (en Español). Ingeniería del software (7ma.

edición). Madrid: Pearson Educacion S.A.. ISBN 84-7829-074-5.
37

Desarrollo Del Modulo (1 Unidad)

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Desarrollo Del Modulo (1 Unidad)

Diunggah oleh

Hak Cipta:

Format Tersedia

ANALISIS Y DISEÑO DE SISTEMAS

REGISTRO DEL ESTUDIANTE

NOMBRE DEL ESTUDIANTE : ______________________

NOMBRE DEL DOCENTE : ____________________________

FECHA : DEL __________ AL ___________

1. PRIMERA UNIDAD: CICLO DE VIDA DE SOFTWARE ......................................3

MODULO: ANALISIS Y DISEÑO DE SISTEMAS

ESTÁNDAR DE COMPETENCIAS DEL MODULO

1. CICLO DE VIDA DEL SOFTWARE

Se conoce como software al equipamiento lógico o soporte lógico de un sistema

El anglicismo "software" es el más ampliamente difundido, especialmente en

Es el conjunto de los programas de cómputo, procedimientos, reglas,

Desarrollar habilidades de modelado con miras al desarrollo de soluciones

2.1 Objetivos Específicos

 Caracterizar los diferentes diagramas de UML (Unified Modeling Languaje)

 Emplear los lineamientos teóricos del objetivo anterior en la solución de

 Garantizar el desarrollo de habilidades para la elaboración de modelos en

Un personaje X le solicita a un experto la construcción de un columpio. De

3.1 Tema 1 Ciclo de vida de Software

Al igual que en otros sistemas de ingeniería, los sistemas de software requieren un

Usualmente se consideran las etapas: especificación y análisis

Tal como ya hemos mencionado, las etapas principales a realizar en cualquier

1. Análisis: Construye un modelo de los requisitos

2. Diseño: A partir del modelo de análisis se deducen las estructuras de

3. Codificación: Construye el sistema. La salida de esta fase es código

4. Pruebas: Se comprueba que se cumplen criterios de corrección y calidad.

5. Mantenimiento: En esta fase, que tiene lugar después de la entrega se

Las etapas constan de tareas. La documentación es una tarea importante que se

Las formas de organizar y estructurar la secuencia de ejecución de las tareas en

1.1.1 Ciclos de vida en cascada

Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las

 Análisis: Toma como entrada una descripción en lenguaje natural de lo que

 Diseño: Su entrada es el S.R.D. Produce el S.D.D. (Software Design

 Codificación: A partir del S.D.D. produce módulos. En esta fase se hacen

 Pruebas: A partir de los módulos probados se realiza la integración y

 La calidad del producto resultante es alta.

 Permite trabajar con personal poco cualificado.

 Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal

 Si se han cometido errores en una fase es difícil volver atrás.

 No se tiene el producto hasta el final, esto quiere decir que:

o Si se comete un error en la fase de análisis no lo descubrimos hasta

 No se tienen indicadores fiables del progreso del trabajo (síndrome del

 Es comparativamente más lento que los demás y el coste es mayor

Tipos de proyectos para los que es adecuado

 Aquellos para los que se dispone de todas las especificaciones desde el

 Se está desarrollando un tipo de producto que no es novedoso.

 Proyectos complejos que se entienden bien desde el principio.

1.1.2 Ciclo de vida en V

1.1.3 Ciclo de vida tipo sashimi

El nombre ``sashimi'' deriva del modo del estilo de presentación de rodajas de

 Al hacer cosas en paralelo si hay problemas de comunicación pueden surgir

La fase de ``concepto'' consiste en definir los objetivos del proyecto, beneficios,

1.1.4 Ciclo de vida en cascada con subproyectos

Si una vez que se ha llegado al diseño arquitectónico, se comprueba que el

1.1.5 Ciclo de vida en cascada incremental

En este caso se va creando el sistema añadiendo pequeñas funcionalidades.

1.1.6 Ciclo de vida en cascada con reducción de riesgos

Como se ha comentado anteriormente, uno de los problemas del ciclo de vida en

Esto consistiría en:

2. Hacer el diseño global que se desprende del punto 1.

3. Hacer un prototipo de interfaz de usuario, entrevistas con los usuarios, etc y

El resto es igual al ciclo de vida en cascada.

1.1.7 Modelo de ciclo de vida en espiral

En cada iteración Boehm recomienda recopilar la siguiente lista de informaciones:

FECHA : DEL AL _