ads ii - 1. ciclo de vida si.pptx
TRANSCRIPT
Ciclo de Vida del desarrollo de SI
“Secuencia de eventos en el desarrollo de un sistema de información (aplicación), lo cual requiere del esfuerzo mutuo, tanto de parte del usuario como del equipo técnico”. (Freedman, 1993)
“Una actividad grupal, conducida con recursos limitados, que conducen a un producto intangible (software)”. (Topper et al., 1994)
“Una actividad social, altamente creativa por naturaleza, que es conducida en un ambiente de recursos limitados y produce una serie de representaciones (o salidas) de un producto intangible, el software”. (Topper et al., 1994)
Ciclo de Vida del desarrollo de SI
“Un proceso lógico con el cual los analistas, ingenieros de software, programadores y usuarios finales, construyen Sistemas de Información y aplicaciones del computador para satisfacer necesidades y resolver problemas del negocio”. (Whitten y Bentley, 1998)
“El proceso de desarrollo (las actividades involucradas en el desarrollo y mantenimiento de software) es un proceso complejo y variable que no puede ser fácilmente descrito usando un solo modelo”. (Sommerville, 1998)
Ciclo de Vida del desarrollo de SI
El ciclo de vida de desarrollo de SI no es un modelo. Mientras un ciclo de vida de desarrollo de SI es una “secuencia de eventos en el desarrollo de un sistema de información (aplicación)” (Freedman, 1993), “... un modelo describe la estructura de cómo se desarrollará el proyecto”. (Raccoon, 1995)
Fases Genéricas del Ciclo de Vida del desarrollo de SI
DEFINICIÓN se centra en el qué. Normalmente, a esta fase se le denomina análisis.
DESARROLLO se centra en el cómo. Para muchos autores, los procesos que se hacen en esta fase de desarrollo, se dividen en las fases que comúnmente se denominan diseño e implementación.
MANTENIMIENTO se centra en el cambio. En esta fase se vuelven a aplicar los pasos de las fases de definición y desarrollo, pero ahora en el contexto del software ya existente.
Visión Tradicional del Ciclo de Vida de SI
Algunos modelos de desarrollo de SI
Modelo Cascada o Clásico
Algunos modelos de desarrollo de SI Modelo de Construcción de Prototipos
Algunos modelos de desarrollo de SI
Modelo en Espiral o Evolutivo
Los requerimientos del sistema
¿Qué es un requerimiento?
Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar.
Una capacidad del software que debe ser reunida o poseída por un sistema o componente del sistema para satisfacer un contrato, especificación, estándar u otra documentación formal.
Los requerimientos del sistema
Se intenta descubrir qué es lo que realmente se necesita en el sistema y se llega a una comprensión adecuada de los requerimientos (las características que el sistema debe poseer).
Si no sabemos con precisión qué es lo que se necesita, ningún proceso de desarrollo nos permitirá obtenerlo. El problema es que, de primeras, puede que ni nuestro cliente sepa de primeras qué es exactamente lo que necesita. Por tanto, deberemos ayudarle a averiguarlo con ayuda de distintas técnicas.
¿Cómo se obtienen los requerimientos?
Los Requerimientos toman vida desde que realizamos nuestro primer encuentro de interlocución con usuarios o clientes.
Este puede desarrollarse utilizando cualquiera de una variedad de técnicas como entrevistas para intercambiar opiniones, brainstorming, prototipeo, cuestionarios, muestreo, observación, etc.
Cuando los requerimientos se logran redactar a un significativo nivel de detalle, tendremos listo el documento denominado “Especificación de Requerimientos”.
¿Qué es UML?
(Unified Modeling Language - Lenguaje Unificado de Modelado). UML es un popular lenguaje de modelado de sistemas de software. Se trata de un lenguaje gráfico para construir, documentar, visualizar y especificar un sistema de software. Entre otras palabras, UML se utiliza para definir un sistema de software.
Posee la riqueza suficiente como para crear un modelo del sistema, pudiendo modelar los procesos de negocios, funciones, esquemas de bases de datos, expresiones de lenguajes de programación, etc.
¿Qué es UML?
Para ello utiliza varios tipos diferentes de diagramas, por ejemplo, en UML hay 13 tipos de diagramas. Estos diagramas se pueden diferenciar en tres categorías:
Diagramas de Estructura
Diagramas de Comportamiento
Diagramas de interacción
Diagrama de clasesDiagrama de componentesDiagrama de objetosDiagrama de estructura compuesta (UML 2.0)Diagrama de despliegueDiagrama de paquetes
Diagrama de actividadesDiagrama de casos de usoDiagrama de estados
Diagrama de secuenciaDiagrama de comunicaciónDiagrama de tiempos (UML 2.0)Diagrama de vista de interacción (UML 2.0)
¿Qué es RUP?
RUP es un proceso para el desarrollo de un proyecto de un software que define claramente quien, cómo, cuándo y qué debe hacerse en el proyecto
RUP como proceso de desarrollo. RUP es explícito en la definición de software y su trazabilidad, es decir, contempla en relación causal de los programas creados desde los requerimientos hasta la implementación y pruebas.
RUP identifica claramente a los profesionales (actores) involucrados en el desarrollo del software y sus responsabilidades en cada una de las actividades.
Fase Inicial
Finalidad: Alcanzar un acuerdo entre todos los interesados respecto
a los objetivos del ciclo vital para el proyecto.
Objetivos: Establecer el ámbito de software y las condiciones de los
límites del proyecto. Discriminar los casos de uso más importantes del
sistema. Estimar el costo global y la planificación de todo el
proyecto. Estimar los riesgos potenciales. Preparar el entorno de soporte para el proyecto.
Fase de Elaboración
Finalidad: El establecimiento de una línea base para la arquitectura
del sistema.
Objetivos: Garantizar que la arquitectura, los requisitos y los planes
son lo bastante estables, y que los riesgos están suficientemente mitigados.
Tratar todos los riesgos arquitectónicamente significativos del proyecto.
Producir un prototipo de componentes de calidad de producción.
Establecer un entorno de soporte.
Fase de ConstrucciónFinalidad:
Completar el desarrollo del sistema basado en la arquitectura de línea base.
Objetivos: Minimizar los costos de desarrollo optimizando los
recursos y evitando las reconstrucciones y los fragmentos innecesarios.
Conseguir la calidad adecuada de forma rápida y práctica.
Conseguir versiones útiles (alfa, beta y otros releases de prueba) de forma rápida y práctica.
Completar el análisis, diseño, desarrollo y prueba de toda la funcionalidad necesaria.
Desarrollar de forma iterativa e incremental un producto.
Fase de TransiciónFinalidad:
Garantizar que el software está listo para entregarlo a los usuarios.
Objetivos: Ejecutar el despliegue. Prueba de versión beta para validar el nuevo sistema
contra las expectativas del usuario. Convertir bases de datos operativas. Formación de usuarios y mantenedores. Despliegue de la fuerza de marketing, distribución y
ventas. Alcanzar la capacidad de soporte propio del usuario.
Iteración
En una iteración participan todas las disciplinas.
Iteración: Una secuencia de actividades con un plan de línea base y criterios de evaluación resultando en una entrega.
RESUMEN EJECUTIVO: CASO FERREYCORP
1.Reseña
La empresa Ferreycorp tiene sus inicios en 1922, donde Enrique FerreyrosAyulo y un pequeño grupo de socios fundaron la empresa Enrique Ferreyros y Cía Sociedad en Comandita, la cual en sus inicios se dedicó a la comercialización de productos de consumo masivo.
Veinte años más tarde, la empresa realizó un giro trascendental, puesto que decidió asumir la representación de Caterpillar Tractor Co. en el Perú. A partir de entonces, la compañía incursiona en nuevos negocios.
En la década de los 60, otras líneas de máquinas y equipos como MasseyFergusson le encomiendan su representación. Asimismo, fue en 1962 que la compañía concretó su inscripción en la Bolsa de Valores de Lima.
Posteriormente en 1981, la empresa se transformó en Sociedad Anónima, como parte de un proceso de modernización en 1998 llega a convertirse en Sociedad Anónima Abierta (Ferreyros S.A.A).
Ahora último en 2012, como consecuencia del crecimiento experimentado por Ferreyros y por las otras compañías subsidiarias del grupo, se procedió a realizar una reorganización corporativa, la cual derivó a transformarse en Ferreycorp S.A.A.
RESUMEN EJECUTIVO: CASO FERREYCORP
2. Problemática
En la empresa, los Procesos de Solicitud de Servicio y Solicitud de Presupuesto están automatizados bajo la plataforma Lotus (Cliente/Servidor). Estos procesos tienen problemas en cuanto a tiempo, puesto que el tiempo de respuesta para realizar dichas transacciones toman un tiempo alto, este problema ha originado que los usuarios tengan quejas permanentes en cuanto a su trabajo bajo este sistema, ya que ha causado demora en que una solicitud de Servicio o Presupuesto no sea atendida en el tiempo planificado. A consecuencia de estos problemas existen pérdidas considerables, la insatisfacción de los usuarios y por último y más importantes la insatisfacción de los clientes, ya que no se le entrega el presupuesto en el tiempo acordado, ni se atiende su solicitud de servicio en el tiempo indicado.
Otro de los problemas es que cada usuario debe tener instalado en su computador el sistema, lo que no les permite acceder al sistema de manera remota.
El problema del tiempo se da porque no hay una buena comunicación entre los servidores de datos del sistema, que está en las instalaciones de IBM, y cada cliente que usa el sistema.
RESUMEN EJECUTIVO: CASO FERREYCORP
3. AlcanceLa implementación del Sistema bajo la plataforma Web integrado al Sistema BPM Ultimus permitirá que el proceso de Solicitud de Servicio y Solicitud de Presupuesto se realicen bajo el tiempo indicado y de manera eficiente.
Alcance funcional del SistemaMódulo de Solicitud de Servicio: Consultar Oficina Asignar Oficina Consultar Centro de Costo Asignar Centro Costo Consultar Datos de Máquina Asignar Máquina Registrar Datos complementarios de Máquina Consultar Cliente de Servicio Asignar Cliente de Servicio Consultar Contactos de Cliente de Servicio Asignar Contactos Consultar Sedes de Cliente de Servicio Asignar Sede Registrar Datos complementarios de Cliente de Servicio Registrar Datos del Servicio Consultar Clientes de Facturación Asignar Cliente de Facturación Registrar Datos complementarios de Cliente de Facturación Consultar Actividad Consultar Componente Registrar Segmentos
Consultar Segmentos Registrar Comentarios Registrar Observaciones Crear Presupuesto desde Solicitud Crear Solicitud de Servicio Hija Listar Solicitudes Hija Listar Presupuestos Validar Autorización de Crédito Consultar Personal Asignar Personal
Módulo de Solicitud de Presupuesto: Consultar Datos de Solicitud de Servicio Registrar Datos de Presupuesto Consultar Segmentos Registrar Tarifas de los Segmentos Consultar Cotizaciones de Repuestos Asignar Cotizaciones a Segmento
RESUMEN EJECUTIVO: CASO FERREYCORP4. Solución
Se cambiará a una plataforma web para que los usuarios puedan hacer uso desde cualquier computador que tenga acceso a la red de Ferreyros, de esta manera acceder a sus tareas de manera remota.
La información de estos procesos se guardará en la misma central de Ferreyros, lo que actualmente está en las instalaciones de IBM, por lo que permitirá que se controle mejor la información.
Se desarrollará el sistema bajo un estándar de costo beneficio, primando el tiempo de respuesta para acceder a la información, así como facilitar las transacciones realizadas en los procesos de Solicitud de Servicio y Solicitud de Presupuesto. Por lo tanto, el tiempo para realizar dichos procesos se realizará en el tiempo estimado.
RESUMEN EJECUTIVO: CASO FERREYCORP5. Anexo: Grafico del proceso
Proceso de Solicitud de Servicio
RESUMEN EJECUTIVO: CASO FERREYCORP5. Anexo: Grafico del proceso
Proceso de Solicitud de Presupuesto
Reglas
Reglas
Reglas
Cliente solicita presupuestoal Área de Presupuesto Usuario iniciador de
Solicitud de PresupuestoAdministrador TallerJefe de Taller
- Registra la información del Presupuesto, lo guarda y va al “Jefe de Taller”.
- Si “aprueba” el Presupuesto y si el cargo es “Reclamo” o “Cliente” o “Interdepartamental” va a “Administrador Taller”.- Si “aprueba” el Presupuesto y si el Cargo es diferente de los antes mencionados termina el Proceso.- Si “rechaza” el Presupuesto termina el Proceso.- Si “devuelve” el Presupuesto se asigna a la persona que le envió.
- Si “aprueba” el Presupuesto termina el Proceso.- Si “rechaza” el Presupuesto termina el Proceso.- Si “devuelve” el Presupuesto se asigna a la persona que le envió.
RUPUML RESUMEN
Fase Actividad Entregable
InicioModelamiento del
Negocio
Documento de Visión Extensión para Modelado del Negocio
Documento de visiónPlan de desarrollo del software
Modelado de caso de uso del negocioEntorno de trabajo
Plan de desarrollo del software
Modelo de caso de uso del negocio
Entorno de trabajo
Elaboración
Requerimientos Modelo de caso de uso Diagrama de caso de uso Diagrama de caso de uso
Análisis y Diseño
Modelo del análisis Diagrama de colaboraciones Diagrama de colaboraciones
Diseño de interfaces Diagrama de secuencia Diagrama de secuencias
Diseño de clases Diagrama de clasesDiagrama de clasesDiagrama de Vistas
Plantilla de Clases Plantilla de clases
Diseño de la base de datos Diseño de la base de datos
Modelo de despliegue Modelo de Despliegue Modelo de despliegue
Prototipo arquitectónico Prototipo arquitectónico
Construcción
Implementación Modelo de componentes Diagrama de componentesDiagrama de componentes
Vistas de componentes
PruebaModelo de caja negra Modelo de caja negra
Prototipo del software Prototipo del software
Transición Despliegue Prueba de aceptaciónDocumento de aceptación del producto
software
IEEE Es una asociación mundial de técnicos e ingenieros
dedicada a la estandarización y el desarrollo en áreas técnicas.
PMBOK PMBOK es el estándar para la Administración de Proyectos y
cuyas siglas significan en inglés Project Management Body of Knowledge (el Compendio del Saber de la Gestión de Proyectos en español). Éste a su vez puede ser entendido como una colección de sistemas, procesos y áreas de conocimiento que son universalmente aceptados y reconocidos como los mejores dentro de la gestión de proyectos.