P. 1
Analisis y Diseño de Sistemas

Analisis y Diseño de Sistemas

|Views: 6.954|Likes:
Publicado porvirgimontilla
En esta presentación encontrarás datos concernientes a lo que es un Sistema de Información, sus componentes y clasificación, los modelos de ciclo de vida del Software.
También hallarás información sobre el Proceso Unificado, sus fases y los diagramas que se hacen en esta área tales como DFD, Casos de Uso y Diagrama de Clases.
En esta presentación encontrarás datos concernientes a lo que es un Sistema de Información, sus componentes y clasificación, los modelos de ciclo de vida del Software.
También hallarás información sobre el Proceso Unificado, sus fases y los diagramas que se hacen en esta área tales como DFD, Casos de Uso y Diagrama de Clases.

More info:

Published by: virgimontilla on Sep 20, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPT, PDF, TXT or read online from Scribd
See more
See less

08/06/2013

pdf

text

original

ANÁLISIS Y DISEÑO DE SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS

Virginia Montilla

Objetivo General
Análisis y Diseño de Sistemas

• Entender los procedimientos que preceden a la fase de codificación en el proceso de desarrollo de software. Se busca que el alumno tenga la capacidad de levantar información de manera adecuada sobre la necesidad de software que presenta una empresa, para posterior a un análisis proceder a diseñar los planos del software que posteriormente será codificado y probado bajo rigurosos estándares.

Objetivos Específicos
Análisis y Diseño de Sistemas

– Fomentar el razonamiento crítico en los estudiantes. – Fortalecer la capacidad de manejar entidades abstractas. – Comprender las técnicas más utilizadas en la industria para levantar información y ser capaz de escoger la técnica más apropiada en cada caso. – Crear la capacidad de crear diseños de sistema posterior a la fase de análisis – Comprender el modelo unificado

Sistemas de Información
Tecnologías de Información

Análisis y Diseño de Sistemas

Información

Recursos Humanos

Sistemas

Componentes de un Sistema de Información
os en an stas m li Hu cia
Control del desempeño del sistema

Análisis y Diseño de Sistemas

Ba s

es

Re
de

cu r

Re
u Us SI
Pro gra ma sy pro ced

s pe so es r y cu es
s a fin l

da tos

o ari

sd eD yd ato ec s o
no cim ien to

so

Entrada de recursos de datos

Salida de productos de información

Almacenamiento de recursos de datos

Medios de comunicación y soporte de redes

Recursos de Redes

med Rec ios urs os de Har dw are

Procesamiento de datos en información

Máq u

inas

y

u Rec s rso

imie s nto

twa Sof de re

Componentes de un Sistema de Información
• Recursos Humanos
– Usuarios o clientes Finales: Son personas que utilizan un sistema de información o la información que éste genera – Especialistas de Sistemas de Información (SI): son las personas que desarrollan y operan los sistemas de información

Análisis y Diseño de Sistemas

• Recursos de Hardware
– Sistemas de computador: Unidad de Procesamiento Central (CPU), quien contienen los microprocesadores, entre otros dispositivos. – Periféricos del computador: Dispositivos como el teclado, mouse, pantalla, impresora

Componentes de un Sistema de Información
• Recursos de Software
– Software de Sistemas: controla

Análisis y Diseño de Sistemas

las

operaciones de un sistema computacional, como el sistema operativo – Software de aplicación: por parte son dirigen de el procesamiento para un uso particular de computadores finales. – Procedimientos: información instrucciones operacionales para utilizar un sistema de usuarios

Componentes de un Sistema de Información
• Recursos de Datos
– Bases de datos: contienen los datos procesados y organizados

Análisis y Diseño de Sistemas

– Bases de conocimiento: incluyen conocimiento sobre una variedad de formas como hechos, reglas y ejemplos de casos sobre prácticas empresariales exitosas

• Recursos de Redes:
– Medios de Redes: El medio en que se transmite la información de un lugar a otro – Soporte de redes: Los recursos que respaldan las operaciones y el uso de una red de comunicación

Clasificaciones de Sistemas de Información
Sistemas de Información

Análisis y Diseño de Sistemas

Sistemas de Apoyo a las Operaciones

Sistemas de Apoyo Gerencial

Sistemas de Sistemas de Proc. de Control de Transacciones Procesos

Sistemas de Colaboración Empresarial

Sistemas de Información Gerencial

Sistemas de Apoyo a las Decisiones

Sistemas de Información Ejecutiva

Clasificaciones de Sistemas de Información
Sistemas de Apoyo a las Operaciones • Sistemas de Procesamiento de Transacciones: Procesan datos resultantes de
Procesan datos generados por operaciones empresariales

Análisis y Diseño de Sistemas

transacciones empresariales, actualizan bases de datos operacionales y generan documentos empresariales
– Dolencias:
• Información repetida o faltante • Necesidad de procesos alternos para validar el flujo • Errores de procedimiento • Pocos datos almacenados sobre el flujo de la información en los procesos • Se requiere de tiempo extra de los usuarios para presentar reportes rutinarios y de toma de decisiones • Los procesos que utilizan en papel son ineficaces o propensos a errores

Clasificaciones de Sistemas de Información

Análisis y Diseño de Sistemas

• Sistemas de control de procesos: Supervisan y Sistemas de Apoyo controlan procesos industriales – Dolencias: a las Operaciones • Dificultad para medir y controlar la producción
• Necesidad de mucho personal en supervisión de procesos • Mucho tiempo invertido en recolectar datos para analizar calidad y rendimiento de la producción o del proceso

Procesan datos generados por operaciones empresariales

• Sistema de Colaboración Empresarial:
respaldan el equipo, el trabajo de grupo, la colaboración y las comunicaciones empresariales
– Dolencias
• Falta de control sobre la información electrónica • Creación de documentos por múltiples miembros del equipo es ineficiente debido a la falta de administración de documentos • Los empleados no pueden obtener la información que necesitan para realizar sus trabajos y servir a sus clientes • Falta de control en la comunicación interdepartamental o con los clientes

Clasificaciones de Sistemas de Información
Sistemas de Apoyo Gerencial • Sistema de Información Gerencial:

Análisis y Diseño de Sistemas

Proporcionan a los gerentes información en forma de informes y presentaciones especificadas previamente
Proporcionan la información y el respaldo necesarios para que los gerentes tomen decisiones efectivas

• Sistemas de Apoyo a las Decisiones:
Suministran apoyo ad hoc interactivo para el proceso de toma de decisiones de los gerentes

• Sistemas de Información Ejecutiva: Brindan
información crítica adaptada a las necesidades de información de los ejecutivos

Modelo de Ciclo de Vida del Software
Análisis y Diseño de Sistemas

Modelo de ciclo de vida Lineal
Consiste en descomponer la actividad global del proyecto en etapas separadas que son realizadas de manera lineal, es decir, cada etapa se realiza una sola vez, a continuación de la etapa anterior y antes de la etapa siguiente

Modelo de Ciclo de Vida del Software
Análisis y Diseño de Sistemas

Modelo de ciclo de en Cascada
Admite iteraciones, después de cada etapa se realiza una o varias revisiones para comprobar si se puede pasar a la siguiente. Es un modelo poco flexible y con muchas restricciones

Modelo de Ciclo de Vida del Software
Análisis y Diseño de Sistemas

Modelo de ciclo de en V
Contiene las mismas etapas que el ciclo de vida cascada, con la diferencia de que posee dos subetapas de retroalimentación entre las etapas de análisis y mantenimiento y entre las de diseño y debugging

Modelo de Ciclo de Vida del Software
Análisis y Diseño de Sistemas

Modelo de ciclo de vida tipo Sashimi
Contiene las mismas etapas que el ciclo de vida cascada, con la diferencia de que se pueden solapar las etapas.

Modelo de Ciclo de Vida del Software
Análisis y Diseño de Sistemas

Modelo de ciclo de vida en Cascada con Subproyectos
Cada una de las cascadas se divide en subetapas independientes que se pueden desarrollar en paralelo

Modelo de Ciclo de Vida del Software
Análisis y Diseño de Sistemas

Modelo de ciclo de vida Iterativo
Es la iteración de varios ciclos de vida en cascada. Al final de cada iteración se le entrega al cliente una versión mejorada o con mayores funcionalidades del producto. El cliente es quien luego de cada iteración evalúa el producto y lo corrige o propone mejoras. Estas iteraciones se repetirán hasta obtener un producto que satisfaga al cliente.

Modelo de Ciclo de Vida del Software
Análisis y Diseño de Sistemas

Modelo de ciclo de vida por Prototipo
No es exclusivo del ciclo de vida iterativo, se utilizan para validar los requerimientos de los usuarios en cualquier ciclo de vida. Si no se conoce exactamente como desarrollar determinado producto o cuales son las especificaciones de forma precisa, suele recurrirse a definir especificaciones para hacer un prototipo; o sea, un producto parcial o provisional.

Modelo de Ciclo de Vida del Software
Análisis y Diseño de Sistemas

Modelo de ciclo de vida Evolutivo
Los requerimientos del usuario pueden cambiar en cualquier momento. Este modelo afronta este problema mediante la iteración de los ciclos requerimientosdesarrollo-evaluación.

Modelo de Ciclo de Vida del Software
Análisis y Diseño de Sistemas

Modelo de ciclo de vida Incremental
Se basa en la filosofía de construir incrementando las funcionalidades del programa. Se realiza construyendo por módulos que cumplen funciones del sistema, esto permite ir aumentando gradualmente las capacidades del software. Es una repetición del ciclo de vida en cascada, aplicándose este ciclo en cada funcionalidad del programa a construir.

Modelo de Ciclo de Vida del Software
Análisis y Diseño de Sistemas

Modelo de ciclo de vida en Espiral
Se basa en una serie de ciclos repetitivos para ir ganando madurez en el producto final. Toma los beneficios de los ciclos de vida incremental y por prototipos, pero se tiene mas en cuenta el concepto de riesgo que aparece debido a las incertidumbres e ignorancias de los requerimientos proporcionados al principio del proyecto o que surgirán durante el desarrollo. A medida que el ciclo se cumple (el avance del espiral), se van obteniendo prototipos sucesivos que van ganando la satisfacción del cliente o usuario.

Modelo de Ciclo de Vida del Software
Análisis y Diseño de Sistemas

Modelo de ciclo de vida en Espiral
Hay cuatro actividades que envuelven a las etapas: Planificación: Levantamiento de requerimientos iniciales y luego de una iteración Análisis de riesgo: Deacuerdo con el relevantamiento de requerimientos decidimos si continuamos con el desarrollo Implementación: desarrollamos un prototipo basado en los requerimientos Evaluación: El cliente evalúa el prototipo, si da su conformidad, termina el proyecto, de lo contrario, incluimos los nuevos requerimientos solicitados en la siguiente iteración

Modelo de Ciclo de Vida del Software
Análisis y Diseño de Sistemas

Modelo de ciclo de vida Orientado a Objetos
Cada funcionalidad o requerimiento solicitado por el usuario, es considerado un objeto. Los objetos están representados por un conjunto de propiedades, a los cuales denominamos atributos, por otra parte, al comportamiento que tendrán los objetos los denominamos métodos.

Modelo de Ciclo de Vida del Software
Análisis y Diseño de Sistemas

Modelo de ciclo de vida Orientado a Objetos
La característica principal de este modelo es la abstracción de los requerimientos de usuario, por lo que este modelo es mucho mas flexible que los restantes, que son rígidos en requerimientos y definición. La abstracción es lo que nos permite analizar y desarrollar las características esenciales de un objeto, despreocupándonos por los menos relevantes. Utilizan las fichas CRC (Clase-responsabilidades-colaboración) como herramienta para obtener las abstracciones y mecanismos clave de un sistema analizando los requerimientos del usuario. En la ficha CRC se escribe el nombre de la clase y objeto, sus responsabilidades (métodos) y sus colaboradores (otras clases u objetos de los cuales necesita). Estas fichas, además, nos ayudan a confeccionar los casos de uso.

Proceso Unificado
Análisis y Diseño de Sistemas

USDP (Proceso Unificado de Desarrollo de Software, Unified Software Development Process )
Es una metodología completa para el desarrollo de software. Es una metodología adaptable, es decir, puede modificarse para el producto software específico que se va a desarrollar No es una serie especifica de pasos que si se siguen darán como resultado la construcción de un producto de software.

UML (Lenguaje Unificado de Modelado, Unified Modeling Language)
Es un estándar internacional para representar los productos de software orientados a objetos Es la herramienta que utilizamos para representar (modelar) el producto de software elegido Permiten a los profesionales de software comunicarse entre si con mayo rapidez y exactitud que si nada mas utilizaran descripciones verbales

Proceso Unificado
Análisis y Diseño de Sistemas

Modelo
Es una serie de diagramas UML que representan uno o mas aspectos del producto software que se va a desarrollar

Paradigma Orientado a Objetos
Es una metodología iterativa e incremental. Cada flujo de trabajo consiste en diversos pasos, y para llevar a cabo ese flujo de trabajo, los pasos de este se realizan en repetidas ocasiones hasta que los miembros del equipo de desarrollo estén convencidos de que tienen un modelo de UML exacto del producto de software que se desea desarrollar.

Proceso Unificado
Flujo de trabajo centrales del proceso unificado
Flujo de trabajo: • De los requerimientos • Del análisis • Del diseño • De la implementación • De las pruebas

Análisis y Diseño de Sistemas

Proceso Unificado
Flujo de trabajo de los requerimientos:
Flujo de trabajo • centrales del proceso unificado
Flujo de trabajo: • • De los requerimientos • Del análisis • Del diseño • • De la implementación • De las pruebas

Análisis y Diseño de Sistemas

Su objetivo es que la empresa de desarrollo determine las necesidades del cliente La primera tarea es adquirir buena comprensión del dominio de la aplicación, es decir, el entorno en el que operara. En una reunión inicial entre el cliente y desarrolladores, el cliente delinea el producto como lo conceptualiza. Debe determinarse con exactitud lo que el cliente necesita, y cuales son las restricciones que existen. Algunas restricciones pueden ser: Limite de tiempo, Confiabilidad y Costo.

Proceso Unificado
Flujo de trabajo de los requerimientos:
Flujo de trabajo • centrales del proceso unificado
Flujo de trabajo: • • De los requerimientos • Del análisis • Del diseño • De la implementación• • De las pruebas

Análisis y Diseño de Sistemas

A la investigación preliminar del cliente muchas veces se le conoce como exploración del concepto. En reuniones ulteriores entre los miembros del equipo de desarrollo y el del cliente se afina y analiza, en sucesión, la funcionalidad del producto propuesto en cuanto a la posibilidad técnica y la justificación financiera Un aspecto fundamental en el desarrollo de software es el modelo de negocio, un documento que demuestra la relación costo-eficacia del producto solicitado.

Proceso Unificado
Flujo de trabajo del análisis:
Flujo de trabajo • centrales del proceso unificado
Flujo de trabajo: • De los requerimientos • • Del análisis • Del diseño • De la implementación• • De las pruebas

Análisis y Diseño de Sistemas

Es analizar y afinar los requerimientos, con el fin de conseguir la comprensión detallada de los requerimientos primordiales para desarrollar un producto de software correcto y de fácil mantenimiento. Los artefactos del flujo de trabajo de los requerimientos deben estar expresados en el lenguaje del cliente. El flujo de trabajo de análisis, en un lenguaje mas preciso que garantice que se efectúen correctamente los flujos de trabajo de diseño e implementación. Se añaden detalles durante el flujo de trabajo del análisis, no importante para la comprensión del cliente del producto software objetivo, pero esenciales para los profesionales de la programación que desarrollaran el producto software

Proceso Unificado
Flujo de trabajo del análisis:
Flujo de trabajo • centrales del proceso unificado •
Flujo de trabajo: • De los requerimientos • Del análisis • • Del diseño • De la implementación • De las pruebas

Análisis y Diseño de Sistemas

Las especificaciones del producto constituyen un contrato Una vez el cliente ha aprobado las especificaciones, comienza la planeación y estimación detalladas. Es requerido por el cliente conocer el tiempo y el costo del proyecto antes de aprobarlo Equivocaciones que se cometen en un análisis clásico son:
– Ambigüedad – Incompletas – Contradicciones

Los desarrolladores necesitan que se asigne el personal adecuado para los diferentes flujos de trabajo del proceso

Proceso Unificado
Flujo de trabajo del análisis:
Flujo de trabajo • centrales del proceso unificado
Flujo de trabajo: • De los requerimientos • Del análisis • Del diseño • • De la implementación • De las pruebas

Análisis y Diseño de Sistemas

Es necesario redactar un plan de administración de proyecto de software (SPMP, Software Project Management Plan) que muestre los flujos de trabajo independientes del proceso de desarrollo y muestre que miembros de la organización están involucrados en cada tarea, así como los limites de tiempo para determinar cada una Una vez el cliente haya aprobado las especificaciones, iniciara la preparación del plan de administración de proyecto de software Los principales componentes son: Los disponibles (que va a conseguir el cliente), los hitos (cuando los consigue el cliente) y el presupuesto (cuanto va a costar)

Proceso Unificado
Flujo de trabajo del análisis:
Flujo de trabajo • centrales del proceso unificado
Flujo de trabajo: • De los requerimientos • Del análisis • Del diseño • De la implementación • De las pruebas

Análisis y Diseño de Sistemas

El plan describe el proceso del software con todo detalle. Incluye aspectos como el modelo del ciclo de vida que se va a utilizar, la estructura organizacional de la empresa de desarrollo, las responsabilidades del proyecto, los objetivos y prioridades gerenciales, las técnicas y herramientas CASE que se van a utilizar y los calendarios, presupuestos y asignaciones de recursos detallados. Sustentando todo el plan están los estimados de duración y costo.

Proceso Unificado
Flujo de trabajo de Diseño:
Flujo de trabajo • centrales del proceso unificado •
Flujo de trabajo: • De los requerimientos • Del análisis • Del diseño • • De la implementación • De las pruebas

Análisis y Diseño de Sistemas

Las especificaciones muestran qué va a hacer el producto; el diseño muestra cómo lo hará El objetivo del flujo de trabajo de diseño es afinar los artefactos del flujo de trabajo del análisis hasta que el material se encuentre en tal forma que pueda ser implementado por los programadores Durante la fase de diseño clásica, el equipo de diseño determina la estructura interna del producto. Los diseñadores descomponen en módulos, piezas de código independientes, con interfaces bien definidas para el resto del producto. Debe especificarse con detalle la interface de cada modulo (argumentos que pasan al módulo y los que regresa al módulo)

Proceso Unificado
Flujo de trabajo de Diseño:
Flujo de trabajo • centrales del proceso unificado
Flujo de trabajo: • De los • requerimientos • Del análisis • Del diseño • De la implementación • De las pruebas •

Análisis y Diseño de Sistemas

Una vez el equipo haya terminado la descomposición del módulo (diseño arquitectónico), se lleva a cabo el diseño detallado; se seleccionan los algoritmos y se eligen las estructuras de datos de cada módulo En el Paradigma Orientado a Objetos la base de ese paradigma es la clase, un tipo de módulo específico. Las clases se extraen durante el flujo de trabajo del análisis y se diseñan durante el flujo de trabajo del diseño Razones por la que el equipo de diseño debe tener un registro meticuloso de las decisiones de diseño que se tomen:

Proceso Unificado
Flujo de trabajo de Diseño:
Flujo de trabajo • centrales del proceso unificado
Flujo de trabajo: • • De los requerimientos • Del análisis • Del diseño • De la implementación • De las pruebas

Análisis y Diseño de Sistemas

Cuando se está diseñando el producto, en ocasiones se llega a un punto muerto, y el equipo de diseño deberá regresar sobre sus pasos y rediseñar algunas piezas En teoría, el diseño del producto debe ser abierto, lo que significa que se podrán hacer mejoramientos futuros (mantenimiento postentrega) añadiendo nuevas clases y sustituyendo las existentes sin afectar todo el diseño

Proceso Unificado
Flujo de trabajo de Implementación
Flujo de trabajo • centrales del proceso unificado •
Flujo de trabajo: • De los requerimientos • • Del análisis • Del diseño • De la implementación • De las pruebas

Análisis y Diseño de Sistemas

Su objetivo es implementar el producto software objetivo en él o los lenguajes de programación elegido Un producto de software pequeño puede ser implementado por el diseñador Un producto de software grande se reparte en subsistemas pequeños (componentes o artefactos de código implementados por un solo programador), los cuales son implementados en paralelo por equipos de codificación La única documentación que se les proporciona al programador es el artefacto de diseño pertinente

Proceso Unificado
Flujo de trabajo de las pruebas
Flujo de trabajo • centrales del proceso unificado •
Flujo de trabajo: • De los requerimientos • Del análisis • • Del diseño • De la implementación • De las pruebas

Análisis y Diseño de Sistemas

Toda persona de desarrollo es responsable de garantizar que si trabajo sea correcto Una vez el profesional de software esta convencido de que un artefacto esta correcto, será manejado por el grupo de garantía de calidad de software para pruebas independientes Artefactos de los requerimientos
– Si se tienen que probar durante el ciclo de vida del producto de software, entonces una propiedad que deben tener es la posibilidad de seguimiento – Si los requerimientos han sido presentados en forma metódica, se han numerado adecuadamente, tienen las referencias y los índices adecuados, entonces los desarrolladores tendrán poca dificultad en rastrear a través de los artefactos ulteriores y garantizar que estos en realidad son un reflejo real de los requerimientos del cliente

Proceso Unificado
Flujo de trabajo de las pruebas
Flujo de trabajo • centrales del proceso unificado
Flujo de trabajo: • De los requerimientos • Del análisis • Del diseño • De la • implementación • De las pruebas

Análisis y Diseño de Sistemas

Artefactos del análisis
– Para comprobarlo se realiza una revisión por los representantes del equipo de análisis y del cliente, dirigido por un representante del grupo SQA (Garantía de Calidad de Software, Software Quality Assurance) – Cuando inicia la planificación detallada puede revisarse las estimaciones de costo y duración

Artefactos del diseño
– Cada parte del diseño puede estar vinculada a un artefacto de análisis – Entre los tipos de fallas que se buscan están las fallas de la lógica, de interfase, falta de manejo de excepciones (el procesamiento de las condiciones de error) y la no conformidad con las especificaciones

Proceso Unificado
Flujo de trabajo de las pruebas
Flujo de trabajo centrales del proceso unificado • Artefactos de la implementación

Análisis y Diseño de Sistemas

Flujo de trabajo: • De los requerimientos • Del análisis • Del diseño • De la implementación • De las pruebas

– Cada componente debe ser probado durante su implementación (comprobación de escritorio) y después que se ha implementado, se corre contra pasos de prueba. Estas son realizadas por el programador – Pruebas Unitarias: El grupo de garantía de calidad prueba el componente de forma metódica – Pruebas de integración: comprueban que los componentes se combinan correctamente para obtener un producto que satisfaga sus especificaciones – Pruebas al producto: se verifica la funcionalidad de todo el producto contra las especificaciones, en particular deben probarse las restricciones listadas en las especificaciones – Pruebas de aceptación: se entrega al cliente, quien lo prueba en el hardware real y con datos reales – Versión alfa: luego de realizado las pruebas se entrega los posibles clientes futuros seleccionados – Versión beta: es la versión alfa corregida

Proceso Unificado
Mantenimiento Posentrega
• •

Análisis y Diseño de Sistemas

Es una parte integral del proceso de programación que debe ser planificada desde el principio Todo el esfuerzo de desarrollo del software ha de llevarse a cabo en tal forma para llevar al mínimo el efecto del mantenimiento posentrega futuro Probar cambios realizados el producto:
– Verificar que los cambios requeridos hayan sido implementados correctamente – Garantizar que no se hizo ningún otro cambio inadvertido. Esto se realiza haciendo pruebas al producto contra casos anteriores para cerciorarse que no se haya comprometido la funcionalidad del resto del producto (pruebas de regresión)

Debe crearse un registro de todos los cambios hechos, junto con el motivo para cada cambio.

Proceso Unificado
Retiro

Análisis y Diseño de Sistemas

• Es la etapa final del ciclo de vida del software • Etapa en que ya no se consigue una buena relación de costo eficacia para mantenimiento posentrega:
– Cuando los cambio sugeridos son tan exhaustivos que tendría que cambiarse todo el diseño – Tal vez se hicieron tantos cambios al diseño original que se construyeron interdependencias inadvertidas del producto – Tal vez se realizo un mantenimiento inadecuado de la documentación, aumentando así el riesgo de una falla de regresión a hasta le grado que seria mas seguro recodificar que mantener – El hardware (y el sistema operativo) en el que corre el producto va a ser sustituido; puede ser mas económico volver a escribir desde cero que modificar

Proceso Unificado
Las fases del proceso unificado
• • • • Fase de comienzo Fase de elaboración Fase de construcción Fase de transición

Análisis y Diseño de Sistemas

Proceso Unificado
Fase de Comienzo
Las fases del proceso unificado • • Fase de • comienzo • • Fase de elaboración •
• • Fase de construcción Fase de transición

Análisis y Diseño de Sistemas

Su objetivo es determinar si vale la pena desarrollar el producto objetivo Debemos comprender el propio dominio Como opera la organización cliente de este dominio Delimitar el alcance del proyecto Identificar riesgos:
– Riegos técnicos – No obtener los requerimientos correctos – No obtener arquitectura correcta

El objetivo del flujo de trabajo de prueba en esta fase es garantizar que se determinen con exactitud los requerimientos La planificación es una parte esencial en cada fase. Los desarrolladores en esta fase tienen suficiente información al principio de la fase para planificar todo el desarrollo

Proceso Unificado
Fase de Comienzo
Las fases del proceso unificado
• • • • Fase de comienzo Fase de elaboración Fase de construcción Fase de transición

Análisis y Diseño de Sistemas

Entregables:
– – – – – – – – – Versión inicial del modelo del dominio Versión inicial del modelo de negocio Versión inicial de los artefactos para los requerimientos Una versión preliminar de los artefactos para el análisis Una versión preliminar de la arquitectura La lista inicial de los riesgos Los casos de uso iniciales El plan para la fase de elaboración La versión inicial del caso de negocios (incluye descripción del alcance del producto y los detalles financieros)

Proceso Unificado
Fase de Comienzo
Las fases del proceso unificado
• • • • Fase de comienzo Fase de elaboración Fase de construcción Fase de transición

Análisis y Diseño de Sistemas

Proceso Unificado
Fase de Elaboración
Las fases del proceso unificado
• • • • Fase de comienzo Fase de elaboración Fase de construcción Fase de transición

Análisis y Diseño de Sistemas

• •

Su objetivo es afinar los requerimientos iniciales, afinar la arquitectura, vigilar los riesgos y afinar sus prioridades, afinar el caso de negocio y producir el plan de administración de proyecto. Las principales actividades son las depuraciones y elaboraciones de la fase anterior Entregables:
– – – – – – – El modelo del dominio terminado El modelo de negocio terminado Artefactos de requerimientos terminado Los artefactos del análisis terminado Una versión actualizada de la arquitectura La lista actualizada de los riesgos El plan de administración de proyecto de software (para el resto del proyecto) – Caso de negocios terminado

Proceso Unificado
Fase de Elaboración

Análisis y Diseño de Sistemas

Proceso Unificado
Fase de Construcción
Las fases del proceso unificado
• • • • Fase de comienzo Fase de elaboración Fase de construcción Fase de transición

Análisis y Diseño de Sistemas

• • •

Su objetivo es producir la primera versión con calidad operativa del producto de software, denominada versión beta Se codifican los diversos componentes y se prueba la unidad Se compilan y vinculan (integran) para formar subsistemas, los cuales se prueban para su integración Se combinan los subsistemas en el sistema general, el cual se prueba como producto

Proceso Unificado
Fase de Construcción
Las fases del proceso unificado
• • • • Fase de comienzo Fase de elaboración Fase de construcción Fase de transición

Análisis y Diseño de Sistemas

Entregables:
– Manual de usuario inicial y otros manuales, según sea adecuado – Todos los artefactos (las versiones de emisión beta) – Arquitectura completa – La lista de riesgos actualizada – El plan de administración de proyecto de software (para el resto del proyecto) – Si es necesario, Caso de negocios actualizado

Proceso Unificado
Fase de Construcción

Análisis y Diseño de Sistemas

Proceso Unificado
Fase de Transición
Las fases del proceso unificado •
• • • • Fase de comienzo Fase de elaboración Fase de construcción Fase de transición

Análisis y Diseño de Sistemas

• • • •

Su objetivo es garantizar que en realidad se hayan cumplido los requerimientos del cliente Es accionada por la retroalimentación desde los lugares donde se ha instalado la versión beta Se corrigen las fallas del producto software Se terminan todos los manuales Se intenta descubrir todos los riesgos que no se habían identificado antes Entregables:
– Todos los artefactos (versiones finales) – Los manuales terminados

Tarea

Análisis y Diseño de Sistemas

Mejoramientos del proceso de Software

Mejoramiento del Proceso del software
CMMI
• Nivel de Madurez. Nivel inicial

Análisis y Diseño de Sistemas

– Es el mas bajo – Todo se hace sobre la marcha y para un propósito – Patrón común exceso de tiempo y costo causado por una falta de gestión en general y participación en particular – La mayor parte de las actividades reaccionan a las crisis y no a las tareas preplanificadas

Madurez nivel 2. Nivel repetible
– Se realizarán prácticas básicas de la gestión del proyecto del software – Las técnicas de gestión y planificación se basan en a experiencia con productos semejantes – Se toman mediciones, un primer paso primordial en la consecución de un proceso adecuado – Las mediciones comunes incluyen el seguimiento meticuloso de los costos y calendarios – Los gerentes identifican los problemas cuando surgen y toman acción correctiva inmediata para evitar que se conviertan en crisis

Mejoramiento del Proceso del software
CMMI
• Madurez nivel 3. Nivel definido

Análisis y Diseño de Sistemas

– El proceso para la producción de software se documenta por completo – Los aspectos gerenciales y técnicos del proceso están muy bien definidos y se hacen esfuerzos continuos para mejorar el proceso cuando es posible – Se utilizan revisiones para conseguir objetivos de calidad de software – Tiene sentido introducir nuevas tecnologías, como los ambientes CASE, para aumentar la calidad y productividad

Madurez nivel 4. Nivel estabilizado
– Determina los objetivos de calidad y productividad para cada proyecto – Estas dos cantidades se miden de forma continua y se toma la acción correctiva cuando hay una desviación inaceptable del objetivo – Se utilizan controles estadísticos de calidad para habilitar a la gerencia para distinguir una desviación aleatoria de una falta significativa de las normas de productividad y calidad

Mejoramiento del Proceso del software
ISO 9001 (Organización Internacional para la Normalización)
• • • •

Análisis y Diseño de Sistemas

Esta normativa es la que mas puede aplicarse al desarrollo de software Exige que se documente el proceso tanto con dibujos como con palabras, para garantizar conformidad y detalle Indica que la adhesión a las normas no garantiza un producto de buena calidad, pero reduce el riesgo de un producto de baja calidad Es necesaria la gestión del compromiso de calidad, capacitación intensa de los trabajadores, y el establecimiento y consecución de metas para el mejoramiento de la calidad

Diagramas
DFD
• Diagrama de Flujo de procesos Entidad Responsable Proceso

Análisis y Diseño de Sistemas

Proceso Secuencia o Nivel Flujo Entidad Almacen

UML
Use Case (Casos de Uso)
• •

Análisis y Diseño de Sistemas

Un caso de uso es un modelo de la iteración entre los usuarios externos de un producto de software y el producto de software en si Un diagrama de casos de uso es un conjunto de casos de uso Notación Actores: es un usuario que desempeña una función especifica Proceso: Actividad
Nombre sistema

Estereotipos: es una forma de extender el UML, es decir, si necesitamos definir una construcción que no este en el UML. <<Include>> Representa una funcionalidad común

Representa el sistema

<<Extend>> Representa una variación de un caso de uso estándar

UML
Diagrama de Clases
• • • • • • Definición: Agregación: Multiplicidad Composición Generalización

Análisis y Diseño de Sistemas

Asociación: se refiere a una relación de algún tipo entre dos clases aparentemente no relacionadas. un comentario en un diagrama UML, lo • Nota: Para incluir colocamos dentro de una nota (un rectángulo con la esquina superior derecha doblada)

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->