INSTITUTO TECNOLOGICO SUPERIOR DE

HUETAMO
Fundamentos de Desarrollo de Sistemas

Análisis y Diseño de Sistemas

Prof. Ing. Mariela Yanin Magaña Gutiérrez

Alumnos:
Freddy Días González
Aurora Méndez Martínez
Jorge luís Baltasar Santibáñez
Felix Basilio Gomez
Daniel Ayala Ramírez
Fecha de entrega: 04/02/2011
 Ciclo de vida

Un modelo de ciclo de vida del software representa todas las actividades y

productos de trabajo necesarios para desarrollar un sistema de software. Los
modelos de ciclo de vida permiten que los gerentes y desarrolladores manejen la
complejidad del proceso de desarrollo de software en la misma forma que un
modelo de análisis o un modelo de diseño de sistema permite que los
desarrolladores manejen la complejidad de un sistema de software.

En el caso de los sistemas de software la realidad que está modelando

incluye fenómenos como relojes, los accidentes, los trenes, los sensores y los
edificios. en el caso del desarrollo del software, la realidad incluye fenómenos
como los participantes, las actividades, los productos de trabajo bx.
 1.- Descripción del Diseño

El diseño es una representación significativa de ingeniería de algo que se

va a construir. Se puede hacer el seguimiento basándose en los requerimientos
del cliente, y al mismo tiempo la calidad se puede evaluar y cotejar con el conjunto
de criterios predefinidos para obtener un diseño bueno. En el contexto de la
ingeniería de software, el diseño se centra en cuatro aéreas importantes de
interés: datos, arquitectura, interfaces y componentes.

Diseño de Datos

El diseño de datos transforma el modelo del dominio de información que se

crea durante el análisis en las estructuras de datos que se necesitaran para
implementar el software. Los objetos de datos y las relaciones definidas en el
diagrama relación entidad el contenido de datos detallado que se representa en el
diccionario de datos proporcionan la base de la actividad del diseño de datos.

Diseño Arquitectónico

El diseño arquitectónico define la relación entre los elementos estructurales

principales del software, los patrones de diseño que se pueden utilizar para lograr
los requisitos que se han definido para el sistema, y las restricciones que afectan a
la manera en la que se pueden aplicar los patrones de diseño arquitectónicos. La
representación del diseño arquitectónico el marco de trabajo de un sistema
basado en computadora puede derivarse de la especificación del sistema, del
modelo de análisis y de la interacción del subsistema definido dentro del modelo
de análisis.
Diseño De Interfaz

El diseño de interfaz describe la manera de comunicarse el software dentro

de sí mismo, con sistemas que interactúan dentro de el y con las personas que lo
utilizan. Una interfaz implica un flujo de información y un tipo especifico de
comportamiento. Por tanto, los diagramas de flujo de control y de datos
proporcionan gran parte de la información que se requiere para el diseño de la
interfaz.

Diseño A Nivel De Componentes

El diseño a nivel de componentes transforma los elementos estructurales de

la arquitectura del software en una descripción procedimental de los componentes
del software.

2.-El proceso dentro del Diseño

En cualquier proceso de diseño existen dos fases importantes: la

diversificación y la convergencia.

La diversificación es la adquisición de un repertorio de alternativas, de un

material primitivo de diseño: componentes, soluciones de componentes y
conocimiento, todo dentro de catálogos, de libros de texto y en la mente.

La convergencia, en esta el diseñador elige y combina los elementos

adecuados y extraídos de este repertorio para satisfacer los objetivos del diseño,
de la misma manera a como se establece en el documento de los requisitos, y de
manera que acordó con el cliente. Otra fase es la eliminación gradual de cualquier
configuración de componentes excepto de una en particular, y de aquí la creación
del producto final.

El diseño del software es un proceso iterativo mediante el cual los requisitos se

traducen en un plano para construir el software. A lo largo de todo el proceso de
diseño, la calidad de la evolución del diseño se evalúa con una serie de revisiones
técnicas formales o con las revisiones de diseño que sugiere tres características
que sirven como guía para la evaluación de un buen diseño:

 El diseño deberá implementar todos los requisitos explícitos del modelo de

análisis, y deberá ajustarse a todos los requisitos implícitos que desea el
cliente.
  El diseño deberá ser una guía legible y comprensible para aquellos que
generan código y para aquellos que comprueban y consecuentemente, dan
soporte al software.
 El diseño deberá proporcionar una imagen completa del software,
enfrentándose a los dominios de comportamiento, funcionales y de datos
desde una perspectiva de implementación.

Con el fin de evaluar la calidad de una representación de diseño, deberán

establecerse los criterios técnicos para un buen diseño.

1. Un diseño deberá presentar una arquitectura arquitectónica que:

 Se haya creado mediante patrones de diseño reconocibles.
 Este formada por componentes que exhiban características de buen
diseño.
 Que se puedan implementar de manera evolutiva, facilitando así la
implementación y la comprobación.
2. Un diseño deberá ser modular; esto es, el software deberá dividirse
lógicamente en elementos que realicen funciones y subfunciones
específicas.
3. Un diseño deberá contener distintas representaciones de datos,
arquitectura, interfaces y componentes.
4. Un diseño deberá conducir a estructuras de datos adecuadas para los
objetos que se van a implementar y que procedan de patrones de datos
reconocibles.
5. Un diseño deberá conducir a componentes que representen características
funcionales independientes.
6. Un diseño deberá conducir a interfaces que reduzcan la complejidad de las
conexiones entre los módulos y con el entorno externo.
7. Un diseño deberá derivarse mediante u método repetitivo y controlado por
la información obtenida durante el análisis de los requisitos del software.

El proceso del diseño del software fomenta el buen diseño atraves de la

aplicación de principios de diseño fundamentales, de metodología sistemática y de
una revisión cuidadosa.

3.- Documentación que se genera en el Diseño

El diseño comienza con el modelo de requerimientos. Se trabaja para

transformar este modelo y obtener cuatro niveles de detalles de diseño: la
estructura de datos, la arquitectura del sistema, la representación de la interfaz y
los detalles a nivel de componentes. Durante cada una de las actividades del
diseño, se aplican los conceptos y principios básicos que llevan a tener una alta
calidad.

En cada etapa se revisan los productos del diseño del software en cuanto a
claridad, corrección, finalización y consistencia, y se comparan con los requisitos y
unos con otros.

El diseño del software se encuentra en el núcleo técnico de la ingeniería del

software y se aplica independientemente del modelo de diseño de software que se
utilice. Una vez que se analizan y especifican los requerimientos del software, el
diseño del software es la primera de las tres actividades técnicas diseño,
generación de códigos y pruebas que se requieren para construir y verificar el
software. Cada actividad transforma la información de manera que dé lugar por
ultimo a un software de computadora valido.

La tarea de diseño produce un diseño de datos, un diseño arquitectónico,

un diseño de interfaz y un diseño de componentes.

4.-Errores dentro del Diseño

Dentro del diseño existen 4 personajes o pilares muy importantes, sobre los
cuales se deben de cuidar los errores en la fase de diseño:

Personas.- Tienen un efecto muy importante sobre la productividad y la

calidad. Es fundamental, por ello, mejorar el potencial humano.

Proceso.- Un buen proceso evita tener que rehacer trabajo por no haber
realizado anteriores tareas correctamente (ejemplo: rediseñar un producto por no
haber captado correctamente los requisitos). Asegura, además, la calidad desde
dos frentes: por uno garantiza la entrega de un producto satisfactorio para el
cliente; por otro permite detectar problemas y errores lo antes posible.

Producto.- El tamaño y las características pueden reducir

considerablemente el tiempo de entrega, si puedes elegir qué funcionalidad
entregar antes.

Tecnología.- Utilizar tecnologías más cómodas y avanzadas, teniendo en

cuenta los riesgos que estas mismas conllevan.

Cuando se atienden debidamente las 4 dimensiones en su justa medida, podemos

alcanzar sinergia.

Los errores del diseño dependen de estos cuatro elementos, si uno falla lo
demás no estará correcto.
 Factor Humano

- Baja motivación
- Personal escasamente calificado
- Problemas entre miembros del equipo
- Heroicidades
- Añadir gente a un proyecto ya comenzado
- Oficinas ruidosas y abarrotadas
- Tenciones entre clientes y programadores
- Expectativas irreales
- Falta de apoyo efectivo al proyecto
- Falta de implicación en los stakeholders (clientes/usuarios)
- Políticas antes del objetivo
- Pensamientos pretenciosos

Factor Productivo

- Estimaciones excesivamente optimistas

- Gestión de riesgos insuficientes
- Fallo de subcontratación (Tratos con terceros)
- Planificación insuficiente
- Abandono del plan en situaciones de presión
- Tiempo perdido en fases de anteproyecto
- Actividades fundamentales acortadas
- Diseño inadecuado
- Acortar tareas de calidad
- Controles de gestión insuficientes
- Convergencia prematura (reportes, documentación)
- Omitir tareas necesarias dentro del proceso
- Planear ponerse al día mas adelante
- Programar a lo loco

5.- Personajes que Intervienen en el Diseño

El objetivo de los diseñadores es producir un modelo o representación de

una entidad que será construida a posteriori.

El ingeniero del software es quien diseña los sistemas basados en

computadora, pero los conocimientos que se requieren en cada nivel de diseño
funcionan de diferentes maneras:

En el nivel de datos y de arquitectura, el diseño se centra en los

patrones de la misma manera a como se aplica en la aplicación que
se va a construir.
 En el nivel de interfaz, es la ergonómica humana la que dicta
nuestro enfoque de diseño. Y en el nivel de componentes, un
enfoque de programación conduce a diseños de datos y
procedimentales eficaces.

Descripción del Análisis

El análisis da como resultado un modelo del sistema que pretende ser correcto,
completo, consistente y verificable. Los desarrolladores formalizan la
especificación del sistema producida durante la obtención de requerimientos y
examinan con mayor detalle las condiciones de fronteras y los casos
excepcionales también corrigen y aclaran la especificación del sistema si es que
encuentran errores o ambigüedades. El cliente y el usuario están involucrados en
esta actividad, y en especial cuando se necesita cambiar las especificaciones del
sistema y cuando se necesita recopilar información adicional.

El modelo de análisis, realmente un conjunto

De modelos, es la primera representación técnica de un sistema. Con los años se
han propuesto muchos métodos para el modelado del análisis. Sin embargo,
ahora dos tendencias dominan el Panorama del modelado del análisis.

El modelo de análisis está compuesto por tres modelos individuales:

Modelo funcional, representado por casos de uso y escenarios

Modelos de objetos de análisis, representado por diagramas de clase y objeto
Modelo dinámico, representado por graficas de estado y diagramas de secuencia.
Herramientas de análisis y diseño
Las herramientas de análisis y diseño hacen posible que el ingeniero del software
cree modelos del sistema que vaya a construir. Los modelos contienen una
representación de los datos, función y comportamiento (en el nivel de análisis), así
como caracterizaciones del diseño de datos, de arquitectura, a nivel de
componentes e interfaz'. Al efectuar una comprobación de consistencia y validez
de los modelos, las herramientas de análisis y diseño proporcionan al ingeniero
del software un cierto grado de visión en lo tocante a la representación del
análisis, y le ayudan a eliminar errores antes de que se propaguen al diseño, o lo
que es peor, a la propia implementación.

Actividades a realizar En el análisis

Los requisitos de datos, funciones y comportamientos son modelados utilizando
diferentes diagramas. El modelado de datos define objetos de datos, atributos y
relaciones. El modelado de funciones indica como los datos son transformados
dentro del sistema. El modelado de comportamiento representa el impacto de los
sucesos. Se crean unos modelos preliminares que son analizados y refinados para
valorar su claridad, completitud y consistencia. Una especificación incorporada en
el modelado es creada y luego validada, tanto por el ingeniero del software, como
por los clientes/usuarios.

Los elementos del modelo de análisis

El modelo de análisis debe lograr tres objetivos primarios:

(1) Describir lo que requiere el cliente,

(2) establecer una base para la creación de un diseño de software, y
(3) definir un conjunto de requisitos que se pueda validar una vez que se
construye el software.
Documentación que genera en el proceso de análisis

Las descripciones de los objetos de datos, los diagramas entidad-relación, los

diagramas de flujo de datos, los diagramas de transición de estados, las
especificaciones del proceso y las especificaciones del control son creadas como
resultado de las actividades del análisis.

En el centro del modelo se encuentra el diccionario de datos -un almacén que

contiene definiciones
De todos los objetos de datos consumidos y producidos por el software-. Tres
diagramas diferentes rodean el núcleo. El diagrama de entidad-relación (DER)
representa las relaciones entre los objetos de
Datos. El DER es la notación que se usa para realizar la actividad de modelado de
datos. Los atributos de cada objeto de datos señalados en el DER se pueden
describir mediante una descripción de objetos de datos. El diagrama de flujo de
datos (DFD) sirve Para dos propósitos: proporcionar una indicación de La
estructura del modelo de análisis.

Cómo se transforman los datos a medida que se avanza en el sistema, y (2)

representar las funciones y
(subfunciones) que transforman el flujo de datos. El DFD proporciona información
adicional que se usar durante el análisis del dominio de información y sirve como
base para el modelado de función. En una especificación de proceso (EP) se
encuentra una descripción.
De cada función presentada en el DFD. El diagrama de transición de estados
(DTE) indica
Cómo se comporta el sistema como consecuencia de sucesos externos. Para
lograr esto, el DTE representa los diferentes modos de comportamiento (llamados
estados) del sistema y la manera en que se hacen las transiciones de estado a
estado. El DTE sirve como la base del modelado de comportamiento. Dentro de la
especificación de control (EC) se encuentra más información sobre los aspectos
de control del software.

Errores que puede producir el modelado del análisis

El resultado del modelado de análisis debe ser revisado para verificar su conexión,
completitud y consistencia.

Aunque ha habido amplios debates sobre la definición adecuada para riesgo de

software, hay acuerdo común en que el riesgo siempre implica dos características
Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no puede
ocurrir; por ejemplo, no hay riesgos de un 100 por 100 de probabilidad'. Pérdida: si
el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o
pérdidas. Cuando se analizan los riesgos es importante cuantificar el nivel de
incertidumbre y el grado de pérdidas asociado con cada riesgo. Para hacerlo, se
consideran diferentes categorías de riesgos.

¿Qué tipo de riesgos es probable que nos encontremos en el software que

se construye?
Los riesgos del proyecto amenazan al plan del proyecto; es decir, si los riesgos del
proyecto se hacen realidad, es probable que la planificación temporal del proyecto
se retrase y que los costos aumenten. Los riesgos del proyecto identifican los
problemas potenciales de presupuesto, planificación temporal, personal
(asignación y organización), recursos, cliente y requisitos y su impacto en un
proyecto de software.

Los riesgos técnicos amenazan la calidad y la planificación temporal del software

que hay que producir. Si un riesgo técnico se convierte en realidad, la
implementación puede llegar a ser difícil o imposible. Los
Riesgos técnicos identifican problemas potenciales de diseño, implementación, de
interfaz, verificación y de mantenimiento. Además, las ambigüedades de
especificaciones, incertidumbre técnica, técnicas anticuadas y las «tecnologías
punta» son también factores de riesgo. Los riesgos técnicos ocurren porque el
problema es más difícil de resolver de lo que pensábamos. Los riesgos del
negocio amenazan la viabilidad del software a construir. Los riesgos del negocio a
menudo ponen en peligro el proyecto o el producto. Los candidatos para los cinco
principales riesgos del negocio son:
(1) construir un producto o sistema excelente que no quiere nadie en realidad
(riesgo de mercado).
(2) construir un producto que no encaja en la estrategia comercial general de la
compañía (riesgo estratégico).
(3) construir un producto que el departamento de ventas no.

Personajes (Desarrolladores) que participan en el Análisis

 El análisis requiere un amplio rango de individuos, el usuario destino
proporciona conocimientos sobre el dominio de aplicación. El cliente proporciona
los fondos para el proyecto y coordina el esfuerzo del lado del usuario. El analista
obtiene conocimientos del dominio de aplicación y lo formaliza. Los
desarrolladores proporcionan retroalimentación sobre factibilidad y costo. El
gerente del proyecto coordina el esfuerzo del lado del desarrollo. En grandes
sistemas pueden estar involucrados muchos usuarios, analistas y desarrolladores,
introduciendo retos adicionales para los requerimientos de integración y
comunicación del proyecto. Estos retos pueden satisfacerse asignando papeles y
alcances bien definidos a los individuos. Hay tres tipos principales de papeles:
generación de información, integración y revisión.
Referencias Bibliográficas

Bruegge Bernd y Dutoit, Allen H.

Ingeniería de software orientado a objetos
Editorial Pearson Educación, México,2002
Pag.consultadas 131-133,457
Páginas: 576

Pressman, Roger S. Ingeniera del software un enfoque practico

Editorial Mc Graw Hill
España 2002
Pág. Consultadas 98-100,199-200,219-223
Páginas: 601

http://es.debugmodeon.com/articulo/errores-comunes-en-desarrollo-software-iii