Anzeige
Anzeige

Más contenido relacionado

Anzeige

Clase_iso12207.pptx

  1. ISO 12207 – Modelos de Ciclos de Vida del Software. INGENIERO JUAN CAMILO VANEGAS GONZÁLEZ COTECNOVA 2022
  2. CICLO DE VIDA DEL SOFTWARE Es una secuencia estructurada y bien definida de las etapas por las que pasa el software en su desarrollo, desde que se concibe la idea hasta que el software deja de utilizarse (obsolescencia) Cada etapa va acompañada de una serie de actividades y tareas, y una documentación de salida de cada una de estas fases y que servirá de entrada a la fase siguiente
  3. Procesos del Ciclo de vida del Software 1 Procesos de acuerdo Proceso de adquisición  Satisfacer las necesidades del cliente  Identificar necesidades del cliente  Aceptación del producto o servicio Proceso de suministro  Comprar productos y/o servicios acordes a requisitos establecidos
  4. 2 Procesos Organizacionales del proyecto Proceso de gestión del modelo de ciclo de vida  Políticas procesos y procedimientos para el ciclo de vida  Requisitos para su gestión (definición, objetivos, mejora continua etc.) Proceso de gestión de infraestructuras  Recursos de soporte de procesos durante el ciclo de vida (instalaciones, herramientas, tecnologías etc.) Proceso de gestión de la cartera de proyectos  Requisitos para justificar la asignación continua de recursos a proyectos para garantizar los objetivos de una organización Proceso de gestión de recursos humanos  Requisitos para asegurar la cualificación del personal asignado a los procesos del ciclo de vida Proceso de gestión de la calidad  Requisitos para alcanzar los objetivos de calidad
  5. 3 Procesos del proyecto Proceso de planificación del proyecto  Identificar alcance del proyecto  Identificar tareas y salidas de los procesos  Establecimiento de planes y recursos Proceso de evaluación y control del proyecto  Requisitos para control del proyecto  Planificación  Costos  Objetivos técnicos  Desviaciones
  6. Proceso de gestión de la decisión  Requisitos de soporte para la toma de decisiones Proceso de gestión de riesgos.  Requisitos para control y monitorización continua de riesgos Proceso de gestión de la configuración  Requisitos para la integridad y disponibilidad de las salidas de un proyecto Proceso de gestión de la información  Requisitos para mantener toda la información relevante acerca de los procesos y garantizar su disponibilidad y confidencialidad Proceso de medición  Requisitos para recoger y analizar los datos que soportan objetivamente la calidad los productos y la gestión efectiva de los procesos
  7. 4 Procesos Técnicos Proceso de definición de requisitos de las partes interesadas (stakeholders)  Requisitos para identificar y satisfacer los intereses y de las partes interesadas Proceso del análisis de requisitos del sistema  Requisitos para definir los requisitos técnicos del sistema Proceso de implementación o puesta en funcionamiento  Proceso de integración del sistema  Requisitos para integración de los elementos de un sistema:  Elementos Software  Hardware  Manuales  Etc.
  8. Proceso de comprobación de los requisitos del sistema  Requisitos para realizar la comprobación de la conformidad Proceso de instalación del software  Requisitos para instalar el producto software en un entorno objetivo Proceso de apoyo a la aceptación del software  Requisitos para establecer procesos de asistencia que garanticen la satisfacción y confianza del comprador Proceso de operación del software  Requisitos para establecer procesos de ayuda a la operación del Proceso de mantenimiento del software  Requisitos para proveer soporte a coste efectivo del producto software
  9. MODELOS DEL CICLO DE VIDA DEL SOFTWARE.  Los modelos de ciclo de vida del software describen las fases del ciclo de software y el orden en que se ejecutan las fases.  Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociados entre estas etapas.
  10. Un modelo de ciclo de vida del software  Describe las fases principales de desarrollo de software.  Define las fases primarias esperadas de ser ejecutadas durante esas fases.  Ayuda a administrar el progreso del desarrollo.  Provee un espacio de trabajo para la definición de un proceso detallado de desarrollo de software.
  11. Modelo en cascada.  El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo se ve fluyendo hacia abajo (como una cascada) sobre las fases que componen el ciclo de vida.
  12. Modelo V.  El modelo en v es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de vida de un proyecto. Describe las actividades y resultados que han de ser producidos durante el desarrollo del producto.
  13. Modelo iterativo.  Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de recogida de requisitos.
  14. Modelo de desarrollo incremental.  El modelo incremental combina elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos. Se basa en la filosofía de construir incrementando las funcionalidades del programa.
  15. Modelo de prototipos.  El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un diseño rápido.
  16. Metodología  Es un conjunto integrado de técnicas y métodos que permite abordar de forma homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. Es un proceso de software detallado y completo. Van un paso más allá de los ciclos de vida, especificando métodos, técnicas, prácticas, artefactos, etc. Define qué hacer, cómo y cuándo durante todo el desarrollo y mantenimiento de un proyecto.  Un marco de trabajo de una metodología de desarrollo software consiste en una filosofía de desarrollo de software, con el enfoque o enfoques del proceso de desarrollo de software y múltiples herramientas, modelos y métodos para ayudar en el proceso de desarrollo de software.
  17. Ágiles Es en realidad un grupo de estrategias de desarrollo software basadas en:  Desarrollo Iterativo  Desarrollo Incremental Divide las tareas en pequeños incrementos con mínimas planificaciones, y no implican directamente planificación a largo plazo. Las iteraciones son marcos pequeños de tiempo (timeboxes) que normalmente duran de una a cuatro semanas. De cada iteración se hace cargo un equipo realizando un ciclo de desarrollo completo, incluyendo planificación, análisis de requisitos, diseño, codificación, pruebas unitarias y pruebas de aceptación. El objetivo es tener una versión disponible (con errores mínimos) al final de cada iteración. No importa qué disciplinas de desarrollo se requieran, cada equipo ágil contendrá un representante del cliente.
  18. RAD  La metodología RAD o DRA (por sus siglas en inglés Rapid Application Development y en castellano Desarrollo Rápido de Aplicaciones), se trata de un modelo de desarrollo de aplicaciones ágil. Es decir, hablamos del proceso de desarrollo de software.  Este método abarca el desarrollo interactivo, la creación de prototipos y el empleo de utilidades CASE (Computer Aided Software Engineering). Además, la metodología RAD suele englobar también la usabilidad, utilidad y la rapidez de ejecución.
  19. RUP  Es una metodología que tiene como objetivo ordenar y estructurar el desarrollo de software, en la cual se tienen un conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema. RUP es un proceso basado en los modelos en Cascada y por Componentes, el cual presenta las siguientes características: Es dirigido por los casos de uso, es centrado en la arquitectura, iterativo e incremental, lo cual es fundamental para el proceso de desarrollo de software.  posee un poco de controversia, ya que cuenta con características esenciales de los procesos de desarrollo ágil como es el crecimiento iterativo o que se encuentra centrado en la arquitectura, pero a la vez tiende a caer en la rigidez de los métodos convencionales.  El proceso del RUP se ejecuta en tres perspectivas: “La perspectiva dinámica, la cual contiene las fases del modelo sobre el tiempo; la estática que muestra las actividades del proceso y la práctica, que muestra las buenas prácticas durante el proceso del RUP
  20. Scrum Scrum es un marco que permite el trabajo colaborativo entre equipos. Al igual que un equipo de rugby (de donde proviene su nombre) cuando entrena para un gran partido, scrum anima a los equipos a aprender a través de las experiencias, a autoorganizarse mientras aborda un problema y a reflexionar sobre sus victorias y derrotas para mejorar continuamente. Aunque son los equipos de desarrollo de software los que utilizan con mayor frecuencia este tipo de scrum, sus principios y lecciones se pueden aplicar a todo tipo de trabajo en equipo. Esta es una de las razones por las que es tan popular. Aunque se considera a menudo un marco de gestión de proyectos ágil, scrum incluye un conjunto de reuniones, herramientas y funciones que, de forma coordinada, ayudan a los equipos a estructurar y gestionar el trabajo.
  21. XP  La Metodología XP “Extreme Programming” o “Programación Extrema” es una de las llamadas metodologías Ágiles de desarrollo de software más exitosas. Es habitual relacionarla con scrum, y la combinación de ambas asegura un mayor control sobre el proyecto, y una implementación más efectiva y eficiente.  La metodología XP define cuatro variables para cualquier proyecto de software: costo, tiempo, calidad y alcance. El método especifica que de estas cuatro variables, tres de ellas podrán ser fijadas arbitrariamente por actores externos al grupo de desarrolladores (clientes y jefes de proyecto), y el valor de la restante deberá será establecida por el equipo de desarrollo, quien establecerá su valor en función de las otras tres.
  22. Taller  De acuerdo a los casos que se presentarán a continuación cada equipo de trabajo debe:  Seleccionar un método y/o metodología (para cada caso propuesto) que consideren más optima para la construcción de un software.  Cada selección debe estar acompañada de un bosquejo básico (de acuerdo al método o metodología seleccionada), es decir, deben realizar una proyección de tiempos y entregas por cada fase.  Presentar argumentos teóricos solidos para justificar la elección de cada método y/o metodología seleccionada.  Sustentar sus elecciones y debatir por qué su elección es la mejor.
  23. Casos de estudio La empresa de telecomunicaciones TELECONOVA requiere realizar un software para la trazabilidad de la fidelización de los clientes (CRM) en tiempo real. El software que necesitan debe ser a la medida y no puede ser una aplicación ya existente. La empresa informa que el software debe ser entregado en un tiempo máximo de 3 meses. El presupuesto para el mismo es de 10.000.000$ como máximo y en este mismo deben estar incluidos todos los gastos requeridos. El equipo de desarrollo está contemplado por los integrantes del grupo. La empresa además informa que por cuestiones de tiempo no es posible reunirse frecuentemente con el equipo de desarrollo para mirar avances. Es posible realizar máximo 1 o 2 reuniones máximo hasta la entrega del proyecto.
  24. Caso de estudio La empresa INNOVA S.A.S es una empresa dedicada a la venta de artículos de tecnología. La empresa requiere un software para realizar ventas por internet ya que hasta la fecha solo se realizan de forma presencial en sus locales distribuidos en las principales ciudades del país. La empresa manifiesta que tiene un tiempo máximo de 6 meses para iniciar con el uso del software. El gerente de la misma comenta que tiene a dos personas encargadas de hacer el seguimiento de los avances y que ellos cuentan con el tiempo suficiente para mirar los avances del desarrollo, por lo que no es un problema planificar reuniones. El presupuesto de la empresa es amplio si bien no hay un estimado máximo se debe realizar sin preocupaciones por el dinero. La empresa también manifiesta que normalmente las necesidades o requerimientos cambian, por lo cual el desarrollo debe ser flexible y adaptarse fácilmente a los cambios.
  25. Caso de estudio El señor Héctor Blandón dueño de la tienda de barrio “la esquina” manifiesta que quiere tener un software que le permita tener un inventario de sus productos y llevar un control de sus ventas. Para el señor Héctor es de carácter urgente la puesta en marcha de este software ya que cada día que pasa se pierde más la trazabilidad de sus ventas ya que por la cantidad de ventas diarias no puede tener un control manual. El señor cuenta con un hijo que conoce los procesos que se manejan y la forma en que se quiere sistematizar por lo cuál está a disposición de 2 a 3 veces por semana para mirar el avance funcional del software. El presupuesto es reducido ya que al ser una pequeña tienda no cuentan con recursos suficientes para este proyecto.
Anzeige