Trabajo de Investigación 01. Victor Hugo Perdomo Vasquez. Elizabeth Tatiana Espinosa Sánchez. Andrés Felipe Sánchez Osorio

Transcripción

1 Trabajo de Investigación 01 Victor Hugo Perdomo Vasquez Elizabeth Tatiana Espinosa Sánchez Andrés Felipe Sánchez Osorio Universidad Distrital Francisco José de Caldas Facultad Tecnológica Tecnología en Sistematización de Datos Bogota D.C. 2015

2 2.Introducción El desarrollo de software es un complejo proceso que debe ser planificado de forma coherente y controlada con el fin de encontrar calidad y eficiencia en los proyectos de software. Para cumplir este objetivo hay una serie de mecanismos, modelos y estándares que permiten analizar, organizar, desarrollar y evaluar los proyectos de software que están en desarrollo, y así lograr gestionar de manera óptima los recursos humanos, técnicos y de costos que un proyecto de desarrollo de software puede traer. Existen varios Ítems que han aparecido con las diferentes metodologías, los cuales marcan la estructura estandarizada para realizar algunas labores. Esto no es solo en la rama informática también en otros sectores como la economía o la elaboración de proyectos entre otros. Algunas de los estándares más conocidos los trataremos en este trabajo con el fin de dar a conocer el ciclo de vida óptimo para un software o para la elaboración de un proyecto informático. Además explicaremos algunas metodologías en detalle, con el fin de darlas a conocer y entenderlas para aprender a realizar un proyecto o un software respetando los estándares.

3 3. Evolución del software Los procesos de desarrollo de software se remontan a la década del 60 cuando las grandes computadoras comenzaban a utilizarse por instituciones científicas y universidades, hoy en día el software es parte fundamental de la mayoría de procesos que tenemos en la sociedad, desde la gestión de la información en una empresa hasta la información del clima en nuestro celular Durante los primeros años el software se contemplaba como un añadido, lo más importante en esta época era el hardware, cada software era diseñado a la medida del hardware usado y no tenía ninguna portabilidad ni uso más allá del inicial. En ésta época no existía ningún planeamiento previo al desarrollo del software, no existía documentación debido a que quien hacía los programas era quien los ejecutaba y los depuraba, el desarrollo era a base de prueba y error. En ésta época también se usaba el procesamiento por lotes en el cual se asignan una serie de instrucciones y la máquina las ejecuta sin ninguna interacción con el usuario Ésta época se caracterizó por la multiprogramación, los sistemas multiusuario y los sistemas en tiempo real que podían recoger, analizar y transformar datos de múltiples fuentes en milisegundos y no en minutos como en la época anterior. Se caracterizó también por ver el software como un producto aparte del hardware, nacieron las casas de software. Comenzó una crisis del software porque como los programas habían sido creados para cada máquina en particular se hacía imposible el mantenimiento del software. Se crearon las bases de datos: jerárquicas, en red y relacionales. Se crearon los primeros lenguajes de programación: C, COBOL, Pascal, Fortran, Basic, entre otros La tercera época del software se caracterizó por el procesamiento distribuido: múltiples computadores, cada una ejecutando funciones concurrentes y comunicándose con otras. Se incrementó la complejidad de los sistemas informáticos. Las redes LAN y WAN comienzan a utilizarse y aumentan la complejidad en los desarrollos del software. También se caracterizó por la llegada del computador personal y el amplio uso de los microprocesadores. Aparece la inteligencia artificial, los sistemas operativos distribuidos y las bases de datos distribuidas Se caracterizó por el impacto colaborativo del software. Se hace un uso avanzado de las tecnologías orientadas a objetos. Las arquitecturas informáticas cambiaron de entornos centralizados de grandes computadores a entornos descentralizados cliente/servidor. El internet es lo más importante de ésta época gracias al desarrollo de tecnologías como TCP/IP, HTTP y HTML. El software libre comienza a utilizarse en todos los campos y la

4 colaboración entre muchas personas en diferentes partes del mundo se hace notable. Aparecen las redes neuronales, sistemas expertos y software de inteligencia artificial. La información y el software se comienzan a ver como el valor más importante dentro de las organizaciones. 2005? Esta época basa su existencia en la web y el software móvil. El software se comienza a adaptar a las necesidades de cada persona. Se reutiliza el software y cada persona no necesita reinventar la rueda, puede usar los desarrollos existentes gracias a la popularización del software de código abierto. El software es ubicuo, es decir, puede estar en varias partes al mismo tiempo, con el uso del celular. La web también ha tenido una evolución dentro de esta época: Web 1.0: estática, el usuario solo puede leer la información. Web 2.0: dinámica, el usuario crea y comparte información Web 3.0: semántica, el usuario interactúa mucho más con las aplicaciones web. Web 4.0: agentes inteligentes, adaptable a cada usuario, inmersiva. 4. Ciclo de vida del software 4.1. Descripción del ISO/IEC ISO/IEC Information Technology / Software Life Cycle Processes, es el estándar para los procesos de ciclo de vida del software de la organización ISO. Estructura La estructura del estándar ha sido concebida de manera que pueda ser adaptada a las necesidades de cualquiera que lo use. Para conseguirlo, el estándar se basa en dos principios fundamentales: Modularidad y responsabilidad. Con la modularidad se pretende conseguir procesos con un mínimo acoplamiento y una máxima cohesión. En cuanto a la responsabilidad, se busca establecer un responsable para cada proceso, facilitando la aplicación del estándar en proyectos en los que pueden existir distintas personas u organizaciones involucradas, no importando el uso que se le dé a este. Procesos Los procesos se clasifican en tres tipos: Procesos principales, procesos de soporte y procesos de la organización. Los procesos de soporte y de organización deben existir independientemente de la organización y del proyecto ejecutado. Los procesos principales se instancian de acuerdo con la situación particular. Procesos principales. - Adquisición. - Suministro.

5 - Desarrollo. - Operación. - Mantenimiento. Procesos de soporte. - Documentación - Gestión de la configuración. - Aseguramiento de calidad. - Verificación. - Validación. - Revisión conjunta. - Auditoría. - Resolución de problemas. Procesos de la organización. - Gestión. - Infraestructura. - Mejora. - Recursos Humanos. En la siguiente gráfica se muestra la dependencia entre Procesos, Actividades y Tareas.

6 Versiones - ISO/IEC 12207:1995. Primera publicación. - ISO/IEC 12207:1995/Amd 1:2002. Primera modificación. - ISO/IEC 12207:1995/Amd 2:2004. Segunda modificación Descripción del ISO/IEC El ISO/IEC 15504, también conocido como Software Process Improvement Capability Determination, abreviado SPICE, en español, «Determinación de la Capacidad de Mejora del Proceso de Software» es un modelo para la mejora, evaluación de los procesos de desarrollo, mantenimiento de sistemas de información y productos de software. Por tanto, el proyecto SPICE fue creado bajo los auspicios del Comité Internacional de estándares de Ingeniería de Software y Sistemas a través de su Grupo de Trabajo sobre Evaluación de proceso (WG10). En 1992, el informe del grupo de estudio dijo que:...la comunidad internacional debería poner recursos para desarrollar un estándar para la evaluación de procesos software, incorporando lo mejor de los métodos de evaluación de procesos existentes. ISO decidió entonces se hiciera el desarrollo por pasos de un estándar para la evaluación de procesos. Los pasos fueron los siguientes: 1. Publicación inicial como Informe Técnico Technical Report ( borrador de estándar ) para que después de su uso real pasase a 2. Revisión y publicación como estándar internacional IS ISO/IEC Tecnologías de la Información Evaluación de Procesos ( ISO/IEC Information Technology Process Assessment ). Las siglas SPICE significan: Software Process Improvement and Capability Determination, es decir, Determinación de la capacidad y mejora de los procesos de software. El proyecto SPICE tenía tres objetivos principales: - Desarrollar un borrador de trabajo para un estándar de evaluación de procesos de software. - Llevar a cabo los ensayos de la industria de la norma emergente. - Promover la transferencia de tecnología de la evaluación de procesos de software a la industria del software a nivel mundial. El primer objetivo del proyecto se logró en junio de 1995, con la entrega del borrador de trabajo de la norma para la evaluación de procesos de software al WG10 para su votación entre la comunidad de estandarización internacional. El Borrador de Trabajo se denominaba comúnmente como el conjunto de documentos SPICE (o SPICE Versión 1). Este primer borrador se basó en modelos existentes en aquél momento.

7 Los ensayos de estos primeros documentos SPICE han sido el foco del proyecto SPICE durante el período 1994 a Fue entonces, en 1998 cuando se publicó la primera familia de estándares ISO TR En aquel momento se comenzó a trabajar en la versión "Internacional Standard" de la norma, y desde 2006 está completamente publicado, exceptuadas las partes nuevas que se estén produciendo. En marzo de 2003, el proyecto SPICE se cerró oficialmente. La Red SPICE se estableció posteriormente con el encargo de seguir coordinando las actividades de la comunidad SPICE. La Red de SPICE está formalmente organizada por el The Spice User Grupo ( En este momento se efectúan actividades promocionales que se realizan a través de la Conferencia Internacional Anual SPICE y la publicación de artículos y libros. Con el fin de apoyar la excelencia y la coherencia de la formación de los evaluadores, el proyecto SPICE también desarrolló y lanzó un Plan de Estudios de formación de los evaluadores SPICE que es utilizado actualmente por el Esquema de Registro Internacional de Evaluadores (IntRSA) En el capítulo de Roles se desarrollan los detalles de cualificación y responsabilidades de diferentes roles que se necesitan en los procesos de evaluación y/o mejora. Características - Establece un marco y los requisitos para cualquier fase de evaluación de procesos y proporciona requisitos para los modelos de evaluación de estos. - Proporciona también requisitos para cualquier modelo de evaluación de organizaciones. - Proporciona guías para la definición de las competencias de un evaluador de procesos. - Actualmente tiene 10 partes: de la 1 a la 7 completas y de la 8 a la 10 en fase de desarrollo. - Comprende: evaluación de procesos, mejora de procesos, determinación de capacidad. - Proporciona, en su parte 5, un Modelo de evaluación de procesos para las fases de ciclo de vida del software definidos en el estándar ISO/IEC que define los procesos del ciclo de vida del desarrollo, mantenimiento y operación de los sistemas de software. - Proporciona, en su parte 6, un Modelo de evaluación de procesos para las etapas de ciclo de vida del sistema, definidos en el estándar ISO/IEC que define los procesos del ciclo de vida del desarrollo, mantenimiento y operación de sistemas. - Proporcionará, en su parte 8, un Modelo de evaluación de procesos para los procesos de servicios TIC que serán definidos en el estándar ISO/IEC que definirá los procesos contenidos en la norma ISO/IEC Equivalencia y compatibilidad con CMMI. ISO forma parte del panel elaborador del modelo CMMI y SEI mantiene la compatibilidad y equivalencia de ésta última con

8 Dimensiones Sin embargo CMMI-DEV aún no es un modelo conforme con esta norma (según lo requiere la norma ISO para todo modelo de evaluación de procesos). Tiene una arquitectura basada en dos dimensiones: de proceso y de capacidad de proceso. Define que todo modelo de evaluación de procesos debe definir: - la dimensión de procesos: el modelo de procesos de referencia (dimensión de las abscisas) - la dimensión de la capacidad: niveles de capacidad y atributos de los procesos. Los niveles de capacidad para todo modelo de evaluación de procesos pueden tener desde el 0 y al menos hasta el nivel 1 de los siguientes niveles de capacidad estándar: - Nivel 0: Incompleto - Nivel 1: Realizado - Nivel 2: Gestionado - Nivel 3: Establecido - Nivel 4: Predecible - Nivel 5: En optimización Para cada nivel existen unos atributos de procesos estándar que ayudan a evaluar los niveles de capacidad Descripción del IEEE STD 1074 Este estándar ha sido desarrollado por la IEEE para determinar el conjunto de actividades esenciales que deben ser incorporadas en el desarrollo de un producto software, sin recomendar un ciclo de vida específico. Cabe mencionar que el IEEE 1074 requiere adaptarse a cada proyecto. Las actividades que no se incluyan deben justificarse. El IEEE 1074 contempla 17 grupos de actividades y 65 actividades en total. Los grupos de actividades son: De Gestión del Proyecto (17 actividades) Iniciación (4 actividades) Planificación (8) Monitoreo y control (5) De pre-desarrollo (11) Exploración de conceptos (4) Asignación al Sistema (3) Importación al software (4) De desarrollo (10) Requisitos (3) Diseño (4) Implementación (3)

9 De post-desarrollo (12) Instalación (3) Operación y soporte (3) Mantenimiento (3) Retiro (3) Integrales (15) Evaluación (7) Gestión de configuración (3) Desarrollo de documentación (2) Capacitación (3) 5. Conceptos 5.1 Ciclo de vida del software El ciclo de vida permite describir los diferentes pasos que se deben seguir para el desarrollo de un software, partiendo desde una necesidad hasta llegar a la puesta en marcha de una solución y su apropiado mantenimiento. En este ciclo definen las distintas fases intermedias que se requieren para validar el desarrollo de un software, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo de esta forma se asegura de que los métodos utilizados son apropiados. Así mismo se pueden definir las principales características del Ciclo de Vida de un 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 detallado proceso de desarrollo de software. 5.2 Proceso de desarrollo de software Las características de un proceso de desarrollo de software se resumen a continuación: - Comprensión: Este requiere claridad y declaración de la naturaleza explícita de la definición del proceso. - Visibilidad: Se refiere a la capacidad de observar la salida de arias actividades del proceso, de manera que se mida el proceso del progreso. - Confiabilidad: Se refiere a la capacidad del proceso para evadir errores o detectar errores y manejarlos antes de que estos avancen en el producto. - Robustez: Se refiere a la capacidad del proceso de no detenerse a pesar de problemas inesperados. - Facilidad de mantenimiento: Se refiere a la cantidad de modificaciones que pueden hacerse al sistema de software sin introducir errores.

10 - Facilidad de verificación: Un proceso es verificable si sus propiedades pueden ser fácilmente verificadas. - Rapidez: Se refiere a la agilidad y rapidez del proceso para ser capaz de entregar un producto final a partir de las especificaciones. - Facilidad de soporte: Se refiere a la posibilidad de que las actividades del proceso sean soportadas por un conjunto de herramientas automatizadas. - Facilidad de aceptación: Se refiere a la capacidad del proceso a ser aceptado y usado por el equipo de ingenieros. - Facilidad de adaptación: Se refiere a la capacidad del proceso a ser modificado para satisfacer las necesidades de cambio en el ambiente de desarrollo. Etapas que debe cumplir un proceso de desarrollo: Planificación Antes de realizar la salida a un proyecto de desarrollo de un sistema de información, es necesario realizar una serie de tareas previas que influirá decisivamente en la finalización con éxito del proyecto. Las tareas iniciales que se realizará esta fase inicial del proyecto incluyen actividades tales como: - La determinación del ámbito del proyecto. - La realización de un estudio de viabilidad. - El análisis de los riesgos asociados al proyecto. - Una estimación del coste del proyecto. - Su planificación temporal. - La asignación de recursos a las distintas etapas del proyecto. Análisis La etapa de análisis corresponde al proceso mediante el cual se intenta descubrir qué es lo que realmente se necesita y se llega a una comprensión adecuada de los requerimientos del sistema (las características que el sistema debe poseer). Es importante averiguar exactamente cuáles son los requerimientos del sistema si el software es fácilmente maleable (aparentemente), porque el coste de construir correctamente un sistema de información a la primera es mucho menor que el coste de construir un sistema que habrá que modificar más adelante. Cuanto antes se detecte un error mejor. No es posible determinar de antemano todos los requerimientos de un sistema de información, en efecto una de las dos causas más comunes de fracaso en proyectos de

11 desarrollo de software es la inestabilidad de los requerimientos del sistema (la otra es una mala estimación del esfuerzo requerido por el proyecto). En el caso de una mala estimación,el problema se puede solucionar estableciendo objetivos más realistas. Un buen analista debería tener una formación adecuada en: - Técnicas de elicitación de requerimientos. - Herramientas de modelado de sistemas. - Metodologías de análisis de requerimientos. Diseño Los modelos que se utilizan en la fase de diseño representan las características del sistema que permitirán implementarlo de forma efectiva (el cómo?). Un software bien diseñado debe exhibir determinadas características. Su diseño debería ser modular en vez de monolítico. Sus módulos deberían encargarse de una tarea concreta y sólo de una y estar débilmente acoplados entre sí (para facilitar el mantenimiento del sistema. El diseño de un sistema es complejo y el proceso de diseño ha de realizarse de forma precisa. Existen auténticos catálogos de patrones de diseño que sirven para aprender de los errores que otros han cometido sin que se tenga que volver a repetir. Igual que en la etapa de análisis se crean distintos modelos en función del aspecto del sistema en que se centra atención, el diseño de un sistema de información también presenta distintas facetas: - Por un lado, es necesario abordar el diseño de la base de datos. - Por otro lado, también hay que diseñar las aplicaciones que permitirán al usuario utilizar el sistema de información. Implementación Después de saber qué funciones debe desempeñar el sistema de información(análisis) y se ha decidido cómo se organizarán sus distintos componentes(diseño), se debe pasar a la etapa de implementación. Para la fase de implementación se deben seleccionar las herramientas adecuadas, un entorno de desarrollo que facilite el trabajo y un lenguaje de programación apropiado para el tipo de sistema que se vaya a realizar. La elección de estas herramientas dependerá en gran parte de las decisiones de diseño que se hayan tomado hasta el momento y del entorno en el que el sistema deberá funcionar.

12 A la hora de programar: - Se debe procurar que el código no resulte indescifrable. - Para que el código sea legible, se debe evitar estructuras de control no estructuradas. - Elegir cuidadosamente los identificadores de nuestras variables. - Seleccionar algoritmos y estructuras de datos adecuadas para el problema. - Mantener la lógica de la aplicación lo más sencilla posible. - Comentar adecuadamente el texto de los programas. - Facilitar la interpretación visual del código mediante el uso de sangrías y líneas en blanco que separan distintos bloques de código. - En esta etapa es importante tener en cuenta la implementación del control de versiones. También es importante la adquisición de todos los recursos necesarios para que el sistema funcione (por ejemplo, las licencias de uso del sistema gestor de bases de datos que se vaya a utilizar). Pruebas La búsqueda de errores que se realiza en la etapa de pruebas puede adoptar distintas formas,en función del contexto y de la fase del proyecto en la que nos encontremos: - Las pruebas de unidad sirven para comprobar el correcto funcionamiento de un componente concreto de nuestro sistema. - Las pruebas de integración son las que se realizan cuando vamos juntando los componentes que conforman nuestro sistema y sirven para detectar errores en sus interfaces. - Una vez "finalizado" el sistema, se realizan pruebas alfa en el seno de la organización encargada del desarrollo del sistema. - Cuando el sistema no es un producto a medida, sino que se venderá como un producto en el mercado, también se suelen realizar pruebas beta. - Por último, a lo largo de todo el ciclo de vida del software, se suelen hacer revisiones de todos los productos generados a lo largo del proyecto, desde el documento de especificación de requerimientos hasta el código de los distintos módulos de una aplicación. Al realizar cualquiera de los tipos de prueba descritos, es importante recordar que el desarrollo de software es una actividad que se realiza en equipo, por lo que pueden surgir roces personales y disputas políticas entre los miembros del equipo. Las pruebas resultan particularmente delicadas en este sentido, ya que su objetivo es, al fin y al cabo, encontrar defectos.

13 Instalación / Despliegue De cara a su instalación, se debe de planificar el entorno en el que el sistema debe funcionar,tanto hardware como software: equipos necesarios y su configuración física, redes de interconexión entre los equipos y de acceso a sistemas externos, sistemas operativos(actualizados para evitar problemas de seguridad), bibliotecas y componentes suministrados por terceras partes, etcétera. Uso y mantenimiento La etapa de mantenimiento consume típicamente del 40 al 80 por ciento de los recursos de una empresa de desarrollo de software. Puede llegar a ser esta la etapa más importante en el proceso de desarrollo. - Eliminar los defectos que se detecten durante su vida útil (mantenimiento correctivo). - Adaptarlo a nuevas necesidades (mantenimiento adaptativo). - Añadir nueva funcionalidad (mantenimiento perfectivo). Se ha observado que, cuanto mejor sea el software, más tendremos que invertir en su mantenimiento, aun cuando se emplee menos esfuerzo en corregir defectos. 5.3 Metodología de desarrollo de software Una metodología de desarrollo de software se refiere al entorno que se usa para estructurar planificar y controlar el proceso de desarrollo de sistema de información. Una gran variedad de metodologías se han desarrollado a lo largo de los años, cada una de ellas con sus fortalezas y debilidades, no todas las metodología son necesariamente aplicable a todo tipo de proyecto más bien cada tipo de proyecto tiene una metodología a la que se adapta mejor. Una metodología de desarrollo de software consiste en: - Una filosofía de desarrollo de software con una base de procesos de desarrollo de software. - Múltiples herramientas, modelos y métodos, para asistir en el proceso de desarrollo de software. - Suele estar documentada y con alguna documentación formal. - Suele estar promovida por algún tipo de organización ya sea esta pública o privada que es la que se encarga de promover esta metodología.

14 5.4 Proyecto de software Es el proceso de gestión para la creación de un sistema o software que encierra un conjunto de actividades, como por ejemplo la estimación que es la base de todas las demás actividades de planificación de proyectos y sirve como guía para una buena Ingeniería de Software. Al estimar tomamos en cuenta no sólo el procedimiento técnico a utilizar en el proyecto sino que se toma en cuenta los recursos costos y planificación. El tamaño del proyecto es otro factor importante que puede afectar las estimaciones. A medida que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del software y esto debe estar debidamente controlado para generar el menor impacto posible. 6. Proceso de desarrollo de software 6.1 Proceso de desarrollo en espiral El modelo de desarrollo en espiral es actualmente uno de los más conocidos y fue propuesto por Boehm. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra. 6.2 Características El modelo en espiral está compartida en varias actividades estructurales, también llamadas regiones de tareas. Existen seis regiones de tareas que son: - Comunicación con el cliente: esta es una tarea requerida para establecer comunicación entre el desarrollador y el cliente. - Planificación: esta tarea es necesaria aplicarla para poder definir los recursos, el tiempo y otras informaciones relacionadas con el proyecto, es decir, son todos los requerimientos. - Análisis de riesgos : esta es una de las tareas principales por lo que se aplica el modelo en espiral, es requerida para evaluar los riesgos técnicos y otras informaciones relacionadas con el proyecto. - Ingeniería: esta es una tarea necesaria ya que se requiere construir una o más representaciones de la aplicación. - Construcción y adaptación: esta tarea es requerida en el modelo espiral porque se necesita construir, probar, instalar y proporcionar soporte al usuario.

15 6.3 Etapas - Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos. - Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos. - Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase. - Planificación: Se determina si continuar con otro ciclo. Se plantea la siguiente fase del proyecto. Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es una actividad importante en la administración del proyecto. 6.4 Ejemplo Explicativo 1. Análisis de riesgos Riesgo del Producto: Cambio excesivo de requerimientos origina mala funcionalidad Los componentes de software elegidos no trabajan adecuadamente El manejador de Base de Datos no soporta el volumen de transacciones Requerimientos no verificables causan rechazo en usuarios Algoritmo inadecuado no cumple restricciones de tiempo de respuesta Riesgo del Proyecto: Miembros clave del proyecto renuncian, originando un retraso significativo Cambio de la administración originando desconcierto en el equipo Hardware indispensable no está a tiempo originando retrasos Cambio excesivo de requerimientos originando retraso y mayor costo Se subestimó el tamaño,originando mayores costos Se subestima el número de defectos originando retraso 2. Comunicación con el cliente Entrevistas Identificación de la necesidad del cliente (Los CENDIS) Alcance del proyecto (Hasta qué punto nos comprometemos) Costos (Determinar y realizar cotizaciones)

16 3. Determinar o fijar objetivos Fijar el producto a obtener Requerimientos del sistema de monitoreo en línea para los CENDIS Especificaciones Manual de usuario Fijar las restricciones Realización de una análisis profundo de lo que se deba hacer según lo que se requiera respecto al desarrollo del SML para los CENDIS (Sistema de Monitoreo en línea para CENDIS) Planificar: Hay una cosa que solo se hace una vez: planificación inicial o previa. Desarrollar, verificar y validar (probar) Análisis de alternativas e identificación resolución de riesgos. 4. Desarrollo y validación Dependiendo del resultado de la evaluación de los riesgos, se comienza a desarrollar el proyecto o sistema en base a un modelo. 1. Análisis de requisitos Identificar los requisitos funcionales Identificar los requisitos no funcionales 2. Diseño del Sistema Diseño de Casos de uso del sistema Identificación de datos abstractos o necesarios. Diseño de la base de datos Diagrama de E R Diseño de la interfaz del sistema Colores, tipografía, gráficos. 3. Codificación 4. Pruebas Verificar que todo funciona correctamente y generar un hito 5. Implantación 6. Mantenimiento Planificar. Revisar todo lo hecho, evaluándolo, y con ello decidir si continuamos con las fases siguientes y planificamos la próxima actividad.

17 7. Metodología de desarrollo de software Scrum Scrum es una metodología ágil de desarrollo de proyectos que toma su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80. (V. Navegapolis: El nuevo escenario). Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software. Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macrojuegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en 2001 serían dos de los promulgadores del manifiesto ágil. En el desarrollo de software scrum está considerado como modelo ágil por la Agile Alliance.

18 7.2 Características Scrum es una metodología de desarrollo muy simple, que requiere trabajo duro porque no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto. Scrum es una metodología ágil, y como tal: Es un modo de desarrollo de carácter adaptable más que predictivo. Orientado a las personas más que a los procesos. Emplea la estructura de desarrollo ágil: incremental basada en iteraciones y revisiones. (V. Navegapolis: Gestión de proyectos ágil: conceptos básicos Estructura del desarrollo ágil). Se comienza con la visión general del producto, especificando y dando detalle a las funcionalidades o partes que tienen mayor prioridad de desarrollo y que pueden llevarse a cabo en un periodo de tiempo breve (normalmente de 30 días). Cada uno de estos periodos de desarrollo es una iteración que finaliza con la producción de un incremento operativo del producto. Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su evolución a través de reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el día anterior y el previsto para el día siguiente. Control de la evolución del proyect o Scrum controla de forma empírica y adaptable la evolución del proyecto, empleando las siguientes prácticas de la gestión ágil: Revisión de las Iteraciones Al finalizar cada iteración (normalmente 30 días) se lleva a cabo una revisión con todas las personas implicadas en el proyecto. Este es el periodo máximo que se tarda en reconducir una desviación en el proyecto o en las circunstancias del producto Desarrollo incremental Durante el proyecto, las personas implicadas no trabajan con diseños o abstracciones. El desarrollo incremental implica que al final de cada iteración se dispone de una parte del producto operativa que se puede inspeccionar y evaluar. Desarrollo evolutivo Los modelos de gestión ágil se emplean para trabajar en entornos de incertidumbre e inestabilidad de requisitos. Intentar predecir en las fases iniciales cómo será el producto final, y sobre dicha predicción desarrollar el diseño y la arquitectura del producto no es realista, porque las circunstancias obligarán a remodelarlo muchas veces. Para qué predecir los estados finales de la arquitectura o del diseño si van a estar cambiando. En Scrum se toma a la inestabilidad como una premisa, y se adoptan técnicas de trabajo para permitir esa evolución sin degradar la calidad de la arquitectura que se irá generando durante el desarrollo. El desarrollo Scrum va generando el diseño y la arquitectura final de forma evolutiva durante todo el proyecto. No los considera como productos que deban realizarse en la primera fase del proyecto. (El desarrollo ágil no es un desarrollo en fases)

19 Autoorganización Durante el desarrollo de un proyecto son muchos los factores impredecibles que surgen en todas las áreas y niveles. La gestión predictiva confía la responsabilidad de su resolución al gestor de proyectos. En Scrum los equipos son auto-organizados (no auto-dirigidos), con margen de decisión suficiente para tomar las decisiones que consideren oportunas. Colaboración Las prácticas y el entorno de trabajo ágiles facilitan la colaboración del equipo. Ésta es necesaria, porque para que funcione la autoorganización como un control eficaz cada miembro del equipo debe colaborar de forma abierta con los demás, según sus capacidades y no según su rol o su puesto. Visión general del proceso Scrum denomina sprint a cada iteración de desarrollo y recomienda realizarlas con duraciones de 30 días. El sprint es por tanto el núcleo central que proporciona la base de desarrollo iterativo e incremental. Los elementos que conforman el desarrollo Scrum son: Las reuniones Planificación de sprint: Jornada de trabajo previa al inicio de cada sprint en la que se determina cuál va a ser el trabajo y los objetivos que se deben cumplir en esa iteración. Reunión diaria: Breve revisión del equipo del trabajo realizado hasta la fecha y la previsión para el día siguiente. Revisión de sprint: Análisis y revisión del incremento generado. Los elementos Pila del producto: lista de requisitos de usuario que se origina con la visión inicial del producto y va creciendo y evolucionando durante el desarrollo. Pila del sprint: Lista de los trabajos que debe realizar el equipo durante el sprint para generar el incremento previsto. Incremento: Resultado de cada sprint Los roles Scrum clasifica a todas las personas que intervienen o tienen interés en el desarrollo del proyecto en: propietario del producto, equipo, gestor de Scrum (también Scrum Manager o Scrum Master) y otros interesados. Los tres primeros grupos (propietario, equipo y gestor) son los responsables del proyecto, los que según la comparación siguiente (y sin connotaciones peyorativas) serían los cerdos ; mientras que el resto de interesados serían las gallinas. Cerdos y gallinas. Esta metáfora ilustra de forma muy gráfica la diferencia de implicación en el proyecto entre ambos grupos: Una gallina y un cerdo paseaban por la carretera. La gallina dijo al cerdo: Quieres abrir un restaurante conmigo.

20 El cerdo consideró la propuesta y respondió: Sí, me gustaría. Y cómo lo llamaríamos?. La gallina respondió: Huevos con beicon. El cerdo se detuvo, hizo una pausa y contestó: Pensándolo mejor, creo que no voy a abrir un restaurante contigo. Yo estaría realmente comprometido, mientras que tu estarías sólo implicada. Propietario del producto: El responsable de obtener el mayor valor de producto para los clientes, usuarios y resto de implicados. Equipo de desarrollo: grupo o grupos de trabajo que desarrollan el producto. Scrum Manager: gestor de los equipos que es responsable del funcionamiento de la metodología Scrum y de la productividad del equipo de desarrollo. Valores Scrum es una carrocería para dar forma a los principios ágiles. Es una ayuda para organizar a las personas y el flujo de trabajo; como lo pueden ser otras propuestas de formas de trabajo ágil: Cristal, DSDM, etc. La carrocería sin motor, sin los valores que dan sentido al desarrollo ágil, no funciona. Delegación de atribuciones (empowerment) al equipo para que pueda auto-organizarse y tomar las decisiones sobre el desarrollo. Respeto entre las personas. Los miembros del equipo deben confiar entre ellos y respetar sus conocimientos y capacidades. Responsabilidad y autodisciplina (no disciplina impuesta). Trabajo centrado en el desarrollo de lo comprometido Información, transparencia y visibilidad del desarrollo del proyecto 7.3 Etapas 1.- Pre-juego Planificación: Definición de una nueva versión basada en la pila actual, junto con una estimación de coste y agenda. Si se trata de un nuevo sistema, esta fase abarca tanto la visión como el análisis. Si se trata de la mejora de un sistema existente comprende un análisis de alcance más limitado. Arquitectura: Diseño de la implementación de las funcionalidades de la pila. Esta fase incluye la modificación de la arquitectura y diseño generales. 2.- Juego Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versión con respeto continuo a las variables de tiempo, requisitos, costo y competencia. La interacción con estas variables define el final de esta fase. El sistema va evolucionando a través de múltiples iteraciones de desarrollo o sprints.

21 3.- Post-juego Preparación para el lanzamiento de la versión, incluyendo la documentación final y pruebas antes del lanzamiento de la versión. 7.4 Diagramas utilizados en cada etapa Diagrama de Gantt del proyecto Diagrama de Clases Diagrama de clases de control de permisos 7.5 Ejemplo explicativo 1 Primera Reunión: Visión El Dueño del Producto realiza una pequeña exposición del proyecto a desarrollar y el valor que él mismo le agregaría a la organización. El proyecto es para permitir que los clientes de la organización puedan cambiar sus planes de internet y agregar servicios en forma online, mediante una aplicación WEB. La visión del proyecto es que los clientes puedan cambiar sus planes de internet en forma positiva y que puedan agregar servicios a los ya contratados. Esto hará que la organización pueda llegar al presupuesto de ingreso del año. También se agrega que los clientes pueden consultar el estado de sus trámites y pueden cancelarlos y modificarlos si todavía no se inició actividad sobre los mismos. Se decidió cómo se integraría el equipo y el tamaño de las iteraciones (3 semanas). Al finalizar la exposición del Dueño del Producto, se discutió sobre la arquitectura del mismo entre los miembros del equipo. Se trató de una breve reunión de 45 minutos, donde se comunicó la visión del proyecto y todos comprendieron la importancia y valor del mismo para la organización. Segunda Reunión: Exposición Aquí el Dueño del Producto expone su Backlog Del Producto el cual ha surgido de la reunión de Visión y de algunas reuniones que él mismo ha mantenido con los stakeholders de la organización. A cada ítem del backlog se lo identifica en una tarjeta con: Título, Breve descripción, Forma de validación, Importancia, Estimación Velocidad Antes de asistir a la reunión de Planificación, el equipo tiene que conocer su velocidad inicial y factor de foco. Como el equipo no tiene historia, utiliza un factor de foco de 60%.

22 El equipo se conforma de 2 desarrolladores y el Scrum Master, los desarrolladores trabajarán 15 días ideales, el Scrum Master también, solo que no se lo tendrá en cuenta para la velocidad del equipo. En total suman 30 días ideales. Se reduce este número con el factor de foco: 30 x 0.60 = 18. Finalmente, la velocidad estimada del equipo para el Sprint que inicia será de 18 puntos. Exposición de Historias Y se genera el siguiente backlog de historias ordenada por importancia: Backlog del Producto Pedido cambio plan - I=70 Consulta de estado de pedidos - I=60 Pedido de Servicio - I=50 A medida que el Dueño del Producto hace un resumen de cada historia, los miembros del equipo realizan la estimación. Esta misma se realiza a través de la metodología de estimación de pocker. La estimación se hace en días ideales. Cambio de Plan Pedido de cambio de Plan. - El Dueño del Producto cuenta la historia. - El cliente entra en una pantalla donde se le pregunta el código de identificación y entonces se le muestra los datos de Apellido y Domicilio del mismo. El cliente visualiza su plan actual, y de una lista ordenada por importe elige el nuevo plan al cual desea acceder, constando la misma de la descripción del plan y del importe. Se verifica si el cliente está en condiciones de tomar este plan. Se confirma la operación por parte del sistema Se preguntan los detalles convenientes para poder estimar la historia. Cómo sería la identificación del cliente (login)? Esto crea una nueva historia (Login). Cómo se identifica al cliente? Se explican las validaciones del mismo, para que pueda operar. El pedido de cambio de plan se resuelve Online o no? Se explica que no. Se puede modificar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Modificar pedidos. Se puede cancelar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Cancelar pedidos.

23 Se divide la Historia Pedido de Cambio de Plan y queda el Backlog Del Producto de esta manera, luego identificar la importancia de cada historia: - Pedido cambio plan - I=70 - Consulta de estado de pedidos - I=60 - Pedido de Servicio - I=50 - Modificar pedidos - I=30 - Cancelar pedidos - I=20 - Login - I=10 - Identificacion del cliente - I=8 - Reset de la clave - I=5 El equipo le pregunta al Dueño del Producto de donde sacarán la identificación del cliente, al estar la historia de Login en una importancia muy lejana al Pedido de cambio de plan. Se sugieren opciones: Poner prioridad al Login Usar un usuario ficticio hasta poder realizar la historia de Login Pedir el cliente como un campo mas dentro del Pedido de cambio de plan El Dueño Del Producto decide priorizar el Login y la gestión de su clave, al darse cuenta que con esa funcionalidad podría salir antes con el producto. El backlog queda de la siguiente manera - Login - I=100 - Identificacion del cliente - I=90 - Reset de la clave - I=80 - Pedido cambio plan - I=70 - Consulta de estado de pedidos - I=60 - Pedido de Servicio - I=50 - Modificar pedidos - I=30 - Cancelar pedidos - I=20 Entonces se comienza nuevamente pidiendo al Dueño Del Producto que exponga la historia Login Login Login - El Dueño Del Producto cuenta la historia - El cliente entra al sistema, este le pide un Login que consta de usuario y pass. Si pasa correctamente el sistema le muestra el menú del sistema.

24 Si el usuario o pass son incorrectos, muestra un mensaje y sigue mostrando en la pantalla la opción de Login. Se preguntan los detalles convenientes para poder estimar la historia. No hay detalles a preguntar por parte del equipo. Cambio de Plan (2) Cambio de Plan - El Dueño Del Producto cuenta la historia - Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente. Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa. Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados) Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado. Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa. Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados) Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales. Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea. Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario. Se piden algunos datos adicionales. Aquí se comienza a hablar un poco de la arquitectura de la solución. De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas. Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería. El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado. Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos. Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.

25 Se decide no gestionar los errores en esta historia. Se preguntan los detalles convenientes para poder estimar la historia. Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos. El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente. Cuando se estima se conoce que la historia es mas grande de lo que se puede estimar (20 puntos de historia) y entonces se decide dividirla Identificación del Cliente Identificación del Cliente - El Dueño Del Producto cuenta la historia - Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente. Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa. Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados) Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado. Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa. Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados) Se preguntan los detalles convenientes para poder estimar la historia. Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos. El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente. Reset de la clave El Dueño Del Producto cuenta la historia. Desea que el sistema le permite al usuario regenerar su clave olvidada. Para esto, quiere que exista una opción que envie un mail con un link especial, donde lo redirija a algún formulario de cambio de clave. Cambio de Plan (3)

26 Cambio de Plan - El Dueño Del Producto cuenta la historia - Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales. Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea. Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario. Se piden algunos datos adicionales. Aquí se comienza a hablar un poco de la arquitectura de la solución. De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas. Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería. El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado. Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos. Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos. Se decide no gestionar los errores en esta historia. Estimación de Historias Login Entonces se procede a la estimación del Login - Miembro 1: 5 - Miembro 2: 13 - Miembro 3: 3 Al ser una diferencia importante, el Scrum Master decide preguntarle el Miembro 2 que explique que tuvo en cuenta en la estimación. El miembro 2 explica: Crear modelo de datos Hablar con el área de seguridad de la información para que defina los lineamientos de seguridad. Se tiene en cuenta una autenticación aunque todavía no se sabe como hacerla. Encriptación de pass.

27 Realizar las operaciones sobre un protocolo seguro, contando que el equipo no tiene experiencia en esto. Lo mismo hace con el Miembro 3 del equipo. El miembro 3 explica: Se usa el API de seguridad actual. El que se usa en el módulo de cobranzas y de atención al cliente. No se piensa crear nada nuevo, solo altas de opciones, objetos, usuarios, roles, etc en el esquema actual. El Dueño del Producto dice que habría que utilizar la forma en que el cliente ingresa al sistema de cobranzas, sin ningún cambio funcional al mismo. Se vuelve entonces a estimar. - Miembro 1: 5 - Miembro 2: 3 - Miembro 3: 3 El Scrum Master toma la decisión de elegir el promedio redondeado. Entonces la estimación de la historia es 4. Cambio de Plan Entonces se procede a la estimación de Cambio de Plan - Miembro 1: 20 - Miembro 2: infinito - Miembro 3: infinito Al tratarse de una historia muy grande (solo hay cartas hasta 20 días ideales) el Dueño Del Producto la divide en dos. Quedando el Backlog Del Producto: - Login - I=100 - Identificación del Cliente - I=90 - Reset de la clave - I=80 - Pedido cambio plan - I=70 - Consulta de estado de pedidos - I=60 - Pedido de Servicio - I=50 - Modificar pedidos - I=30

28 - Cancelar pedidos - I=20 Identificación del Cliente Entonces se procede a la estimación de Identificación del Cliente - Miembro 1: 8 - Miembro 2: 13 - Miembro 3:? El miembro 3 del equipo dice no entender lo que hay que estimar. El Dueño Del Producto detalla un poco mas la historia. Se vuelve entonces a estimar. - Miembro 1: 8 - Miembro 2: 13 - Miembro 3: 13 El Scrum Master decide tomar la estimación de 13 puntos de historia. Reset de la clave El equipo discute rapidamente cómo será el envio del mail, y uno de los integrantes recuerda una solución parecida en otro proyecto. El equipo estima la historia Reset de la clave - Miembro 1: 5 - Miembro 2: 3 - Miembro 3: 3 El Scrum Master decide tomar la estimación de 4 puntos de historia. Cambio de Plan (2) Entonces se procede a la estimación - Miembro 1: 8 - Miembro 2: 20 - Miembro 3: 13 Al ser una diferencia importante, el Scrum Master decide preguntarle el Miembro 1 que explique que tuvo en cuenta en la estimación.