You are on page 1of 33

Análisis y diseño de Sistemas

‡ Programa : Listo para correr por su autor, en el sistema en que fue desarrollado ‡ Producto de Programación: Puede ser ejecutado, testeado, reparado y extendido por ³cualquiera´ ‡ Sistema de programación: Colección de programas interactivos, interfases y recursos necesarios definidos
Análisis y Diseño de Sistemas - JML 1

Sistema como producto
Diseño general Compuesto por productos de programación Definición y testeo de interfases Definición de recursos necesarios para su funcionamiento ‡ Portabilidad ‡ ‡ ‡ ‡

Análisis y Diseño de Sistemas - JML

2

Qué es el Software?
‡ Cerebro de una computadora ‡ El conocimiento capturado de un área de aplicación ‡ Colección de programas y datos necesarios en una computadora ,para una aplicación particular ‡ Toda la documentación producida durante el desarrollo de un sistema
Análisis y Diseño de Sistemas - JML 3

pero todas son simplemente aspectos de información Análisis y Diseño de Sistemas .Software ‡ El Software provee la porción activa del Sistema.JML 4 . lo que hace que el sistema se vea ³vivo´ ‡ El Software puede ser distintas cosas.

JML 5 .Representaciones de Software ‡ Programas ‡ Diseño escrito en algún lenguaje de programación ‡ Diseño arquitectónico representado como diagramas de estructura ‡ Especificaciones escritas en un lenguaje formal ‡ Requerimientos Análisis y Diseño de Sistemas .

JML 6 .Conocimiento de la Ingeniería del Software ‡ Toda la información que describe el desarrollo en general (el como se usa un método de diseño) ‡ Información: del proyecto . identificación y solución a problemas técnicos Análisis y Diseño de Sistemas . la tecnología del Software.

JML 7 .Conocimiento del dominio específico ‡ Entender como un proceso físico es controlado ‡ Procedimientos inherentes al dominio ‡ Saber el comportamiento .cómo funciona ³la cosa´ Análisis y Diseño de Sistemas .

JML 8 .Información ‡ Es la esencia del Software ‡ Si no se maneja correctamente perjudica al Software Análisis y Diseño de Sistemas .

Ciclo de Vida ‡ ‡ ‡ ‡ Definición Desarrollo Operación Evolución Análisis y Diseño de Sistemas .JML 9 .

Definición ‡ ‡ ‡ ‡ ‡ ‡ Instrucciones necesarias Análisis de necesidades Instrucciones de requerimientos Análisis de requerimientos Definición de elementos de datos Especificaciones funcionales Análisis y Diseño de Sistemas .JML 10 .

Descripción técnica del sistema ‡ ‡ ‡ ‡ ‡ ‡ Especificaciones Técnicas Diseños arquitectónicos Diseños detallados Estructura de Base de Datos Descripción de datos Programas ejecutables Análisis y Diseño de Sistemas .JML 11 .Desarrollo .

JML 12 .Agregaciones del sistema ‡ ‡ ‡ ‡ Colección de programas Definición de interfases Integración de hardware y software Integración hombre. hardware y software Análisis y Diseño de Sistemas .Desarrollo .

JML 13 .Operación .Sistema instalado ‡ ‡ ‡ ‡ ‡ ‡ Instalación Control de versiones Producción Medidas de eficiencia Reportes de error Medición de la efectividad Análisis y Diseño de Sistemas .

JML 14 .El Software no es fácil de cambiar ‡ ‡ ‡ ‡ ‡ No debe cambiarse sólo el código El cambio debe hacerse desde ³arriba´ Se debe prever el impacto de los cambios Debe actualizarse la documentación Control de versiones Análisis y Diseño de Sistemas .

El ³viejo código´ nunca muere ‡ Uso productivo ‡ Los usuarios lo aceptan. Cuando el software se vuelve parte de sus vidas (competencia subconsciente) ‡ Los usuarios no quieren tomarse el trabajo de cambiarlo.JML 15 . si hay que extenderlo. con todo lo que ello implica ‡ Razones económicas Análisis y Diseño de Sistemas . sin importar si es lento.

CICLO DE VIDA Requerimientos de softtware Planeamiento testeo sistema de software Testeo sistema de software Diseño preliminar Planeamiento testeo integración Testeo integración Diseño detallado Planeamiento testeo unitario Testeo unitario Codificación Análisis y Diseño de Sistemas .JML 16 Fuente: Davis .

Diseño detallado.Diseño preliminar 3.JML 17 .Costos por etapa ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ Tamaño del programa bajo desarrollo (en k-líneas de código) Etapas 2 1.Integración y testeo del problema TOTAL (%) 6 15 64 15 100 6 15 61 18 100 8 6 15 58 21 100 32 120 6 15 56 23 100 Análisis y Diseño de Sistemas . codificación 4.Requerimientos 2.

ó .JML 18 D1020 .Se reconoce un problema y que requiere solución.Acompaña a la fase de requerimientos de hardware Finalización ‡Se describe el comportamiento externo del problema ‡Se documentan las interfases sistema-ambiente ‡La SRS describe que hará el sistema sin decir cómo Análisis y Diseño de Sistemas .Sigue al diseño del sistema .Surge una nueva idea de software (invención) ‡Sistema de hardware y software .Fase de requerimientos Comienzo ‡Sistema de software .

JML 19 D1030 .Dilema ³qué vs cómo´ Todas las metodologías pretenden presentar qué hace el software sin aludir a cómo lo hace. pero en realidad hablan de distintos requerimientos Necesidades del usuario qué/cómo Espacio de productos (los comportamientos legales) qué/cómo Comportamiento real del producto qué/cómo Arquitectura/flujo de datos qué/cómo Especificación de módulo qué/cómo Algoritmos qué/cómo Código Análisis y Diseño de Sistemas .

JML 20 .Diferentes nomenclaturas Actividad Análisis de problemas Freema Análisis Ross Análisis de contexto specificac funcional Diseño Davis Análisis de problemas scribir la S S Diseño preliminar Yo r o Modelo esencial Modelo de implement del usuario Diseño Definición del comportam. externo specificac Definición de funcional las componentes del producto Análisis y Diseño de Sistemas .

JML 21 D1180 .Tipos de requerimientos ‡ Que definen funciones ‡ ³El sistema exhibirá la ubicación actual del barco´ ‡ Que limitan funciones ‡ "El sistema debe generar un tono de dial dentro de los 5 segundos´ ‡ Limita el tiempo de la función ‡ Que especifican relaciones ‡ "El sistema permite especificar en el set-up el color de las naves exhibidas en la consola´ ‡ Establece una relación de control entre el set-up y la función de selección de color Análisis y Diseño de Sistemas .

Los errores de requerimientos son típicamente: hechos. Se están cometiendo demasiado errores ‡ 4. más cuesta repararlo ‡ 2.JML 22 D1220 . Cuanto más tarde en el ciclo de vida se detecta un error.Importancia de los requerimientos ‡ Axioma: ‡ Hacer un mejor trabajo definiendo y especificando software no sólo vale la pena sino que también es posible y ventajoso en costo ‡ Soporte: ‡ 1. Muchos errores permanecen latentes y no son detectados hasta bastante despues de la etapa en que se cometieron ‡ 3. inconsistencias y ambigüedades ‡ 5. omisiones. incorrectos. Los errores en los requerimientos pueden detectarse Análisis y Diseño de Sistemas .

1 .5 1 2 5 20 23 D1230 Análisis y Diseño de Sistemas .0.2 0. más cuesta repararlo ‡ Evidencia ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ETAPA REQUERIMIENTOS DISEÑO CODIFICACION TEST DE UNIDADES TEST DE ACEPTACION MANTENIMIENTO COSTO RELATIVO DE REPARACION 0.JML . Cuanto más tarde en el ciclo de vida se detecta un error.Hipótesis 1 ‡ 1.

entonces detectar y reparar errores en la etapa N+1 es inherentemente más costoso que en la N ‡ B) Puede ser que el incremento de los costos derive de la necesidad de corregir: ‡ .los que se generan en etapas posteriores ‡ El crecimiento de los costos de reparación es producto de la catarata de errores que se producen ‡ La explicación A es antintuitiva. consideramos la B Análisis y Diseño de Sistemas .JML 24 D1240 .los errores originales y ‡ .Hipótesis 1 Posibles explicaciones ‡ A) Si la mayoría de los errores se detectan a tiempo.

Catarata de errores Modelo de Mizuno Análisis y Diseño de Sistemas .JML 25 D1245 .

JML .P OBLEMA EAL especificación correcta especificación incorrecta Especificación de requerimientos diseño correcto diseño incorrecto diseño basado en especificación incorrecta iseño programas basados en diseño incorrecto programas basados especificación incorrecta programas correctos errores de programación Implementación funciones correctas errores corregibles errores no corregibles errores ocultos 26 Testing Análisis y Diseño de Sistemas .

JML .P OBLEMA EAL especificación correcta especificación incorrecta Especificación de requerimientos diseño correcto diseño incorrecto diseño basado en especificación incorrecta iseño programas basados en diseño incorrecto programas basados especificación incorrecta programas correctos errores de programación Implementación funciones correctas errores corregibles errores no corregibles errores ocultos 27 Testing Análisis y Diseño de Sistemas .

Hipótesis 2 ‡ 2. Muchos errores permanecen latentes y no son detectados hasta bastante despues de la etapa en que se cometieron ‡ Evidencia (TRW) ‡ 54% de los errores se detectan después de las fases de ‡ codificación y prueba de unidades (45% de la fase de ‡ requerimientos y 9% de codificación) Análisis y Diseño de Sistemas .JML 28 D1250 .

Se están cometiendo demasiado errores ‡ Evidencia ( De Marco) ‡ 56% de los errores tienen su origen en la etapa de requerimientos Análisis y Diseño de Sistemas .Hipótesis 3 ‡ 3.JML 29 D1250 .

incorrectos. inconsistencias y ambigüedades ‡ Evidencia (Basili.Hechos incorrectos: 49% ‡ ‡ ‡ ‡ .Ambigüedades: 5% .Requerimientos mal ubicados: 2% Análisis y Diseño de Sistemas .Inconsistencias: 13% . A-7E) ‡ .Omisiones: 31% . Los errores de requerimientos son típicamente: hechos.Errores administrativos: 77% ‡ .Hipótesis 4 ‡ 4. omisiones.JML 30 D1260 .

Los errores en los requerimientos pueden detectarse ‡ Evidencia (Basili. A-7E) ‡ Errores detectados manualmente: 33% ‡ Inpección: 65% ‡ Testeo de unidades: 10% ‡ Integración: 5% ‡ Evaluación: 10% ‡ Otros: 10% ‡ Las inspecciones han resultado de muy alta efectividad Análisis y Diseño de Sistemas .JML 31 D1260 .Hipótesis 5 ‡ 5.

JML 32 D1270 .Conclusión ‡ Se cometen muchos errores de requerimientos (Hip 3 y 4) ‡ Muchos de esos errores se detectan tardíamente (Hip 2) ‡ Sin embargo muchos pueden detectarse tempranamente (Hip 5) ‡ No detectar los errores contribuye al incremento de costos en el software (Hip 1) Análisis y Diseño de Sistemas .

Impacto de los errores en la etapa de requerimientos ‡ El software resultante puede no satisfacer a los usuarios ‡ Las interpretaciones múltiples de los requerimientos pueden causar desacuerdos entre clientes y desarrolladores ‡ Es imposible que a través del testeo el software satisfaga sus requerimientos ‡ Puede gastarse tiempo y dinero construyendo el sistema erróneo Análisis y Diseño de Sistemas .JML 33 D1280 .