MODELO DE PROCESOS

MODELO DE PROCESOS

1. UNIDAD 1

   • CICLO DE VIDA DE DESARROLLO DE SISTEMAS
     • El Periodo de Vida del Desarrollo de Sistemas rastrea el historial (ciclo de vida) de un sistema de información. Quizá de mayor relevancia para el diseñador del sistema, el SDLC otorga la “gran imagen” en la cual el diseño de la base de datos y el desarrollo de la aplicación tienen la posibilidad de ser proyectados y valorados. Las bases de datos dependen de un periodo de vida semejante al de los sistemas de información de los cuales son parte. Como el Periodo de Vida de Bases de Datos (DBLC) encaja y se parece al Periodo de Vida del Desarrollo de Sistemas (SDLC), se obliga una breve explicación del SDLC.
   • Modelo de Análisis
     • Una vez que ya se ha desarrollado y aceptado el modelo de requisitos, se inicia el desarrollo del modelo de estudio siguiendo el modelo de casos de uno,1 cuyo objetivo es entender y crear una arquitectura de objetos para el sistema basado en lo detallado en el modelo de requisitos. Tarde o temprano el sistema deberá ajustarse a las condiciones de utilización deseadas, lo cual se va a hacer a lo largo de el modelo de diseño. Es fundamental enfatizar que el modelo de estudio es una representación conceptual, que corresponde al problema y modelo de requisitos, en término de clase de objetos. Una cualidad fundamental de la metodología es la rastreabilidad (traceability) de los modelos, que posibilita evaluar el efecto de cambios a lo largo de el desarrollo.
   • Modelo de Proceso
     • Un modelo de proceso de programa define cómo resolver la problemática del desarrollo de sistemas de programa. Para desarrollar el programa hace falta solucionar ciertas etapas de su proceso, las cuales se conocen en su grupo como el periodo de vida1 del desarrollo de programa.
       • Primer proyecto de su tipo
         • Por ser la primera ocasión que se crea esta clase de plan, es necesario más tiempo para especificarlo y analizarlo. En un primer plan, la incertidumbre crea peligros extras.
       • Segundo proyecto de su tipo
         • Generalmente, el creador tiende a excederse añadiendo demasiada funcionalidad comparativamente con el plan anterior (esto se sabe como featuritis). El sistema se vuelve muchísimo más enorme que el original ocasionando retrasos en el sistema, como en la actualidad pasa con varios proyectos.
       • Variación de un proyecto.
         • Se alarga un sistema ya que existe, lo que implica meter elementos de programa reutilizables como un marco de trabajo (framework), producir nuevos elementos o sencillamente prolongar la aplicación que existe por medio de nueva funcionalidad. En la mayoría de los casos, el peligro en esta clase de proyectos es mucho menor que en los primeros proyectos de su tipo.
       • Proyecto de reescritura de legado (legacy)
         • Se busca cambiar o hacer una “reingeniería” de un sistema ya que existe, desarrollado bajo tecnologías anteriores, a un sistema desarrollado bajo novedosas tecnologías, como por ejemplo las orientadas a objetos. El plan de reescritura de legado tiene algunas propiedades en común con otros tipos de proyectos, en medio de las que permanecen la alteración de un plan, por ya existir un plan anterior con funcionalidad semejante, y un primer plan de su tipo, debido a que se debería producir una totalmente nueva arquitectura sin disponer de programa reutilizable del plan anterior. Además, hay los peligros involucrados con un primer plan, debido a que hace falta la utilización de tecnología nueva.
       • Proyecto de creación de software reutilizable
         • Esta clase de plan es muy semejante a otros proyectos de desarrollo de programa, donde se necesita integrar los requisitos y desarrollar el diseño completo del elemento. No obstante, es distinto de otro tipo de sistemas, donde se tienen que tener en cuenta las necesidades de diversas proyectos, de forma que se asegure que el diseño sea lo suficientemente general para servir en otras situaciones desconocidas.
       • Proyecto de mejora de sistema o mantenimiento
         • Se busca cambiar los elementos básicos de un sistema para ayudar una totalmente nueva funcionalidad. Se debería entender bien qué elementos se deben mejorar y cómo afectan dichos cambios al resto del sistema.

2. UNIDAD 2

   • METODO Y METODOLIGIA
     • “Un Método es un proceso disciplinado para crear un grupo de modelos que describen diversos puntos de un sistema de programa en desarrollo, usando alguna notación bien definida”
     • Una metodología es una colección de métodos aplicados a lo largo del ciclo de vida del desarrollo de software y unificados por alguna aproximación general o filosófica
   • Análisis Orientado a Objetos
     • No hay recetas simples para la investigación de programa• Los escenarios son una potente herramienta para la exploración orientado a objetos, y tienen la posibilidad de utilizarse para dirigir los procesos de estudio tradicional, estudio del comportamiento y estudio de dominios. • Las abstracciones clave reflejan el vocabulario del dominio del problema y tienen la posibilidad de ser descubiertas en el dominio del problema, o bien ser inventadas como parte del diseño. • El exclusivo aparato que tiene UML a grado de estudio son los Diagramas de Casos de Uso.
   • Modelo de Casos de uso
     • El modelo de casos de uso explica un sistema en términos de sus diversas maneras de implementación, todas las cuales se sabe como un caso de uso. Ya que los casos de uso describen el sistema a realizarse, los cambios en los requisitos significarán cambios en los casos de uso. Ejemplificando, un caso de uso para manejar un coche podría ser la sucesión de eventos a partir de que el conductor entra en el automóvil y enciende el motor hasta llegar a su destino final. Por consiguiente, para entender los casos de uso de un sistema primero se necesita saber quiénes son sus usuarios; ejemplificando, conducir un coche es diferente de arreglarlo, puesto que los usuarios además son diferentes: el propietario del carro y el mecánico, respectivamente.
   • EL MODELO DE ENTIDAD-RELACION
     • Ejemplificando, los elementos básicos de entidades e interrelaciones y sus representaciones en la actualidad resultan muy conocidos. La diferencia con lo cual se discute en este capítulo es el nivel de la ilustración gráfica de las interrelaciones entre entidades y el desarrollo de la función de resumir la riqueza de los datos requeridos para realizar un diseño popular. Debemos rememorar del capítulo 2 que el modelo E-R constituye la base de un diagrama E-R o ERD. Dichos ERD ilustran los 3 elementos primordiales del modelo E-R: entidades, atributos e interrelaciones. De esta forma puesto que, las entidades (objeto) del diseño de la base de datos para la universidad, que se desarrollará en este capítulo, incluirá alumnos, clases, docentes, salones de clase, etc.

3. UNIDAD 3

   • Escenarios y sub-escenarios
     • Cada caso de uso da sitio diversos escenarios • Se codifican siguiendo la codificación de los casos de uso • Se estudia cada escenario usando guiones como los que se aplican en la pantalla grande • Cada equipo que pasa por un escenario identifica los objetos y sus responsabilidades, así como los mecanismos que relacionan los objetos • De los escenarios iniciales se puede pasar a otros escenarios secundarios • Los escenarios además tienen la posibilidad de usar para probar el sistema en la etapa de pruebas • El análisis de los escenarios con detalle dejará enriquecer el Diccionario de clases • No se necesita hacer todos los escenarios y sub-escenarios probables si se observa que no enriquecen el diccionario de clases Numeración: 1.1. Titulo: Hacer pedido Precondiciones: Recomendaciones de compra, caducidad de licencias, bajas persistente hardware, … Quien Lo Empieza: Responsable de Informática. Quien Lo Termina: Responsable de Informática.
   • Casos de uso Para el Sistema de Reservación de Vuelos
     • Desde las secuencias analizadas previamente, se puede producir una especificación completa de los casos de uso del sistema de reservaciones de vuelo. Estas secuencias se insertan en los flujos o subflujos de los casos de uso respectivos. Ya que las secuencias no dicen todos los probables eventos, sino los primordiales, se necesita completarlos, en especial a clases borde y entidad que no aparecen en los diagramas de secuencias. Se debería comprobar que no existan discontinuidades en medio de las secuencias, manteniendo constantemente consistencia entre los casos de uso y las secuencias anteriores.