MODELOS PRESCRIPTIVOS DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN INGENIERÍA INFORMÁTICA Fundamentos de sistemas de información Unidad 3 Equipo #2 Integrantes: José Luis Baltazar Anaya Crhistian Iván Madrueño Aguilar Profesor: Jorge Aragón Hope Trabajo: Cuadro comparativo 20 de octubre de 2020 OBJETIVO En términos generales el objetivo de este trabajo es comparar los diferentes modelos y metodologías prescriptivas del desarrollo de sistemas de información, se tratará de resaltar la definición, características, etapas, ventajas y desventajas de cada uno de los modelos que se vieron en la unidad 3, con el fin de notar las diferencias entre estas metodologías y comprender que para cada tipo de proyecto se puede buscar y aplicar el modelo que más le convenga y no solamente escoger uno al azar, ya que para eso fueron desarrollados, para agilizar, mejorar, reducir riegos, reducir costos, reducir tiempos, analizar riesgos, mejorar calidad, etc. Todo ello aplicado al desarrollo de software. El ingeniero de software debe conocer y comprender de que va cada uno de estos modelos y metodologías para poder aplicarlos en proyectos que se le presenten, ya que es indispensable para desarrollar sistemas de información de cualquier tipo. MODELO CASCADA DEFINICIÓN ¿Qué es? También conocido como modelo clásico, modelo tradicional o modelo lineal sec uencial. Él método de la cascada es considerado como el enfoque clásico para el ciclo de vida del desarrollo de sistemas. CARACTERÍSTICAS / RIESGOS • • El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo de software se concibe como un conjunto de etapas que se ejecutan una tras otra. Se le denomina así por las posiciones que ocupan las diferentes fases que componen el proyecto, colocadas una encima de otra, y siguiendo un flujo de ejecución de arriba hacia abajo, como una cascada. • • Es adecuada para los proyectos donde se desarrollan componentes software paralelamente y los miembros del equipo trabajan en varios trabajos. Es vital para los proyectos en los cuales se tienen bien definidos cuales son los objetivos y requisitos e ir paso a paso siguiendo cada una de las etapas del proyecto. El modelo Cascada posee un alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseño. La aplicación del modelo en cascada se orienta mejor al desarrollo de proyectos de corto plazo, de poca innovación, como proyectos definitivos bien detallados Es un procedimiento lineal que se caracteriza por dividir los procesos de desarrollo en sucesivas fases de proyecto. Al contrario que en los modelos iterativos, cada una de estas fases se ejecuta tan solo una vez, donde no se puede avanzar a la siguiente si la anterior no se encuentra totalmente terminada ETAPAS / grafico VENTAJAS ● ● ● ● Requisitos: En esta fase se hace un análisis (que incluye un estudio de viabilidad) de las necesidades del cliente para determinar las características del software a desarrollar, y se especifica todo lo que debe hacer el sistema sin entrar en detalles técnicos. Diseño: En esta etapa se describe la estructura interna del software, y las relaciones entre las entidades que lo componen. Implementación: En esta fase se programan los requisitos especificados haciendo uso de las estructuras de datos diseñadas en la fase anterior. Verificación: Una vez se termina la fase de implementación se verifica que todos los componentes del sistema funcionen correctamente y cumplen con los requisitos. Mantenimiento: A partir de ahora hay que asegurarse de que el software funcione y hay que destinar recursos a mantenerlo. Después de cada etapa importante las pruebas se realizan para comprobar el correcto funcionamiento del código. La documentación se produce en cada etapa del desarrollo del modelo de cascada. La cantidad de recursos necesarios para implementar este modelo es mínima. Es un modelo lineal (más simples a ser implementadas). DESVENTAJAS • • • • No se puede volver atrás. Poco margen para realizar ajustes a lo largo del proyecto debido a un cambio en las exigencias. En ocasiones, los fallos solo se detectan una vez finalizado el proceso de desarrollo. El usuario final no se integra en el proceso de producción hasta que no termina la programación. INCREME NTAL En este modelo se desarrolla el sistema para satisfacer un subconjunto de los requisitos especificados y en posteriores versiones se incrementa el programa con nuevas funcionalidades que satisfagan más requisitos. • • • • • • • • El modelo incremental entrega el software en partes pequeñas, pero utilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya ha sido entregado. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado núcleo. • • Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia. El usuario se involucre más. Difícil de evaluar el costo total. Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. Requiere gestores experimentados. Los errores en los requisitos se detectan tarde. El resultado puede ser muy positivo. se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. Por otro lado los incrementos se pueden planear para gestionar riesgos más fácilmente. • • • • • Las etapas de ingeniería de software que cubre el modelo incremental son Definición y Desarrollo. • • Definición: Análisis Desarrollo: Diseño Código Pruebas • • • Mediante este modelo se genera software operativo de forma rápida y en etapas tempranas del ciclo de vida del software. También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software. El modelo proporciona todas las ventajas del modelo en cascada realimentado. Permite entregar al cliente un producto más rápido en comparación del modelo de cascada. Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos. Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico. Es un modelo más flexible, por lo que se reduce el coste en el cambio de alcance y requisitos. Es más fácil gestionar riesgos. • • • • • Para el uso de este modelo se requiere una experiencia importante para definir los incrementos y distribuir en ellos las tareas de forma proporcionada. El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos. Requiere de mucha planeación, tanto administrativa como técnica. Requiere de metas claras para conocer el estado del proyecto. Cada fase de una iteración es rígida y no se superponen con otras. EVOLUTIV O consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevas necesidades por parte del cliente o del usuario final. • existen dos tipos de desarrollo evolutivo: • • Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos • • • • Otras características: • • • • • • • Gestionan bien la naturaleza evolutiva del software. Son iterativos: construyen versiones de software cada vez más completas. Se adaptan bien Los cambios de requisitos del producto Especificaciones parciales del producto Se puede aplicar en todos los sistemas, pero es más recomendado para sistemas pequeños y medianos Estos modelos se aplican cuando se reconoce la naturaleza evolutiva del proyecto de ingeniería de software. el desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. las fases de especificación, desarrollo y validación se entrelazan en vez de separarse. • • • • • Especificación inicial Desarrollo del producto Implementación y evaluación Versiones del software Re-especificacion Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios. Reduce costo y aumenta la probabilidad de éxito. Exige disponer de las herramientas adecuadas. Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humanomáquina. • • El cliente considera la mayoría de veces al prototipo como el producto final. La calidad del software o la factibilidad de mantenimiento puede que no se tome en cuenta. ESPIRAL es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software. • • • • • El modelo de desarrollo en espiral se utiliza a menudo para proyectos más grandes que están sujetos a riesgos Es un modelo que puede combinarse con otros modelos de procesos de desarrollo (cascada y evolutivo). Es el mejor modelo que se utiliza para desarrollar grandes sistemas. El análisis de riesgo requiere la participación de personal con experiencia. Toma de Riesgos: • El Espiral utiliza el MCP para reducir riesgos y permite aplicarlo en cualquier etapa de la evolución. Mantiene el enfoque clásico (cascada) pero incorpora un marco de trabajo iterativo que refleja mejor la realidad. • Este modelo requiere considerar riesgos técnicos en todas las etapas del proyecto; aplicado adecuadamente debe reducirlos antes de que sean un verdadero problema. • • • Objetivo y determinación alternativa: Los objetivos se determinan conjuntamente con el cliente. Al mismo tiempo, se discuten posibles alternativas y se especifican las condiciones marco (por ejemplo, sistemas operativos, entornos y lenguajes de programación). Análisis y evaluación de riesgos: Se identifican y evalúan los riesgos potenciales. También se evalúan las alternativas existentes. Los riesgos son registrados, evaluados y luego reducidos utilizando prototipos, simulaciones y softwares de análisis. En este ciclo, existen varios prototipos como plantillas de diseño o componentes funcionales Desarrollo y prueba: Los prototipos se amplían y se añaden funcionalidades. El código real es escrito, probado y migrado a un entorno de prueba varias veces hasta que el software pueda ser implementado en un entorno productivo. Planificación del siguiente ciclo: El siguiente ciclo se planifica al final de cada etapa. Si se producen errores, se buscan soluciones, y si una alternativa es una mejor solución, se prefiere en el siguiente ciclo. • • Puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Es un enfoque realista del desarrollo de sistemas y de software a gran escala. Como el software evoluciona, a medida que progresa el proceso el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. Utiliza la construcción de prototipos como mecanismo de reducción de riesgos. Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. Mantiene el enfoque sistemático de los pasos sugeridos por el ciclo de vida clásico, pero lo incorpora al marco de trabajo iterativo que refleja de forma más realista el mundo real. • • • • • • • Puede resultar difícil convencer a grandes clientes (particularmente en situaciones bajo contrato) de que el enfoque evolutivo es controlable. Requiere una considerable habilidad para la evaluación del riesgo. No se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos. Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas. Genera mucho tiempo en el desarrollo del sistema. Modelo costoso. RAD El método comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución. se suele utilizar para referirnos al desarrollo rápido de interfaces gráficas de usuario tales como Glade, o entornos de desarrollo integrado complet os. Algunas de las plataformas más conocidas son Visual Studio, Lazarus, Gambas. • • • • • • • • • El software no se desarrolla y utiliza en su totalidad, sino en una serie de incrementos, donde en cada incremento se incluyen nuevas funcionalidades al sistema. A menudo se desarrollan las interfaces de usuario del sistema utilizando un sistema de desarrollo interactivo que permite que el diseño de la interfaz se cree rápidamente dibujando y colando iconos en la interfaz. Para su desarrollo se utilizan herramientas de desarrollo visual para agilizar el proceso. La aplicación funcionará de manera independiente. Se pueden usar mayormente bibliotecas existentes. Desempeño no crítico. Distribución limitada, interna o vertical. Alcance del proyecto limitado. Confiabilidad no crítica. Es adecuada para los proyectos de bajo presupuesto o con un desarrollo rápido y con un desempeño no tan crítico. • • • • • • • Modelado de gestión: Este modelo se basa en dar respuesta a las siguientes preguntas: – ¿Qué información conduce el proceso de gestión? – ¿Qué información genera? Modelado de datos: En este modelo se definen los almacenes de datos y cómo se relacionan los almacenes entre si. Modelado del proceso: Se utiliza para añadir, modificar, suprimir o recuperar un objeto de datos. Generación de aplicaciones: Para esto se utiliza una herramienta de cuarta(o quinta) generación que permite crear el software y facilitar la construcción del programa. Pruebas y entrega: El proceso de desarrollo finaliza realizando pruebas de calidad del software diseñado con la herramienta RAD. • • • • Comprar puede ahorrar dinero en comparación con construir. Los entregables pueden ser fácilmente trasladados a otra plataforma. El desarrollo se realiza a un nivel de abstracción mayor. Visibilidad temprana. Mayor flexibilidad. Menor codificación manual. Mayor involucramiento de los usuarios. Posiblemente menos fallas. Posiblemente menor costo. Ciclos de desarrollo más pequeños. Interfaz gráfica estándar. • • • • • • • • • • Comprar puede ser más caro que construir. Costo de herramientas integradas y equipo necesario. Progreso más difícil de medir. Menos eficiente. Menor precisión científica. Riesgo de revertirse a las prácticas sin control de antaño. Más fallas (por síndrome de “codificar a lo bestia”). Prototipos pueden no escalar, un problema mayúsculo. Funciones reducidas (por “timeboxing”). Dependencia en componentes de terceros: funcionalidad de más o de menos, problemas legales. WIN-WIN El modelo win-win es una variante del modelo en espiral. En el modelo espiral el software se construye en una serie de versiones incrementales • Se define como aquellas tácticas negociadoras cuya finalidad reside en el hecho en que las dos partes, compradorproveedor, salgan ganando con unas condiciones muy favorables para ambos. • • • • • • • • Trata de mejorar los ciclos de vida clásicos y prototipos. Puede combinarse con otros modelos de proceso de desarrollo En cada giro se construye un nuevo modelo del sistema completo. Incorpora objetivos de calidad y gestión de riesgos Elimina errores y alternativas no atractivas al comienzo Permite iteraciones, vuelta atrás y finalizaciones rápidas Cada ciclo se completa con una revisión que incluye todo el ciclo anterior y el plan para el siguiente Análisis del riesgo: Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daños y consecuencias que éstas puedan producir. Habitualmente tiene sentido aplicar este método en proyectos grandes, largos, caros y complejos 1.- Identificación del sistema o subsistemas clave de los directivos. 2. Determinación de las «condiciones de victoria de ambas partes. 3. Negociación de las condiciones de victoria. 4.- Evaluar las alternativas del producto y del proceso y resolución de riesgos. 5.- Definir el siguiente nivel del producto y del proceso, incluyendo particiones. 6.- Validar las definiciones del producto y del proceso. 7.- Revisión y comentarios. • El análisis del riesgo se hace de forma explícita y clara. • Une los mejores elementos de los modelos restantes. • No es recomendable para sistemas pequeños, debido a su complejidad • Resulta difícil convencer a grandes clientes. • Reduce proyecto. del • Resulta como un modelo muy costoso. • 4.- Incorpora objetivos de calidad. • Genera mucho tiempo en el desarrollo del sistema. • Integra el desarrollo con el mantenimiento. • • Añade la posibilidad de tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático. Requiere experiencia en la identificación de riesgos. • Fallos en el análisis de riesgos podría influir negativamente a todo el proyecto. riesgos PROGRA MACIÓN EXTREMA La programación extrema es una metodología de desarrollo ágil que tiene como principal objetivo aumentar la productividad a la hora de desarrollar un proyecto software. Da prioridad a los trabajos que dan un resultado directo y en los cuales se reduce la burocracia que pueda existir en el entorno de trabajo. • • • • • • • • La programación extrema (XP), cuenta con los valores de la comunicación, la retroalimentación, el coraje y el respeto, entre los elementos que conforman a todo este proceso. • Un desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras. Programación en parejas: Tareas de desarrollo que se lleven a cabo por dos personas en un mismo puesto. Frecuente integración del equipo de programación con el cliente o usuario. Refactorización del código, rescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad, sin modificar su comportamiento. Simplicidad, la programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo. Es recomendable emplearlo solo en proyectos a corto plazo. se realizan pequeños programas de prueba (“spikes”), para reducir riesgos. • • • • • Este tipo de metodología tiene un proceso continuo, es decir, que tendremos que repetir continuamente todos los pasos para obtener un resultado complaciente para el desarrollador y el cliente. Cada uno de los pasos llevaran a un pequeño producto, sin embargo, se tienen previstos que los errores en ellos sean naturales. Las entregas de cada producto suelen ser rápidas, teniendo como tiempo estimado de 2-3 semanas. • • • • Planificación Diseño Codificación pruebas • • • • Relación estrecha con el cliente Facilita los cambios. Ausencia de trabajos de programación innecesarios. Permite ahorrar mucho tiempo. Menos errores gracias a la programación en pareja. Cuenta con una tasa de errores muy pequeña. Puede ser aplicada a cualquier lenguaje de programación. Da lugar a una programación sumamente organizada. El cliente tiene el control sobre las prioridades. Se hacen pruebas continuas durante el proyecto. • • • • • • Es recomendable emplearla solo en proyectos a corto plazo. Fuerte dependencia de las personas. Dificultad para documentar. Puede no siempre ser más fácil que el desarrollo tradicional. Requiere control de versiones. Posibles “roces” con el cliente. MADUREZ DE CAPACID ADES El Modelo de Madurez de Capacidades es un modelo para determinar la madurez de los procesos de software y de la organización, y la identificación de las practicas claves requeridas para el mejoramiento e incremento de la madurez de los procesos y de mejora de calidad en el desarrollo y mantenimiento de software. Características comunes: • Compromiso de la realización: Describe las acciones que la organización debe realizar para asegurar que el proceso sea establecido y pueda perdurar. • La capacidad de realización: Describe las precondiciones que deben existir en el proyecto u organización para implementar el proceso de software en forma competente. ➢ Recursos y financiamiento. ➢ Capacitación. ➢ Orientación. • • • • • • • • • Otras características: • • • Aplica estudio y capacitación para la realización de este proceso específico. Tiene un plan sistemático secuencial, con un orden determinado y único para el desarrollo del proceso. Define procesos, documentados y definidos, integrando disciplinas, sistemas, software bajo la premisa de mejorar el proceso en su conjunto. Nivel 1. Inicial: Se definen cuáles son los lineamientos generales del proyecto y cuáles son los posibles recursos disponibles para concretarlo. Nivel 2. Repetible: Se describen las actividades y prácticas usadas por el equipo de desarrollo. Nivel 3. Definido: Se definen los procesos según las actividades requeridas, la disponibilidad de recursos, se establecen los puntos de control, los instrumentos de control que se utilizaran para llevarlos a cabo, las herramientas y los métodos requeridos. Nivel 4. Administrado: En esta etapa la organización del proyecto ya cuenta con la estabilidad necesaria para poder incorporar Mejora la visibilidad sobre proyectos. Mejora la comunicación. Mejora la planificación. Mejora la calidad del producto. Conocimiento de la organización. Mejor ambiente de trabajo. Se genera una base de conocimiento. Un cliente más informado. Reducción del número de defectos. • • • El proceso de evaluación es muy costoso en cuestión de tiempo y esfuerzo. Puede ser excesivamente detallado para algunas organizaciones. Puede ser difícil de entender. herramientas de control productividad más precisas. de calidad y Nivel 5. Optimizado: La evaluación emanada de las etapas anteriores permite seleccionar aquellos procesos exitosos para poder replicarlos, y también identificar las brechas en aquellos que necesitan mejoras. PSP Es un conjunto de prácticas disciplinadas, para la gestión del tiempo y mejora de la productividad personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para emplearse en organizaciones con modelos de procesos CMMI o ISO 15504. • • • • • • • • • Con PSP los ingenieros de software pueden adquirir las habilidades necesarias para trabajar en un proceso de software en equipo TSP. Se puede considerar como la guía de trabajo personal para ingenieros de software en organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad de procesos que implica la medición cualitativa y mejora de procesos. Mejora del funcionamiento. Establecer metas personales. identificar métodos a utilizar. Medir el trabajo. Analizar resultados. Toma en cuenta riesgos. PSP pretende formar ingenieros de software con métodos disciplinados para mejorar su desarrollo personal de software. • • • • Disciplina de procesos y mediciones: (psp0, psp0.1). Estimación y planeación: (psp1, psp1.1). Administración de la calidad y diseño: (psp2, psp2.1). TSP (desarrollo cíclico, administración de riesgos, equipo de construcción). • Entre las ventajas a destacar de este modelo podemos mencionar la mejora la productividad de las personas. mejora en los hábitos de programación. se puede lograr una detección temprana de defectos y riesgos lo que deriva en una disminución de los defectos. una mejora en la calidad, y por lo tanto, una reducción en el ciclo de vida. Se trabaja con un plan con una base de estimación más certera al ser realizada por el equipo; se logra una buena comunicación entre los integrantes. • • • • Las desventajas de este modelo es que es necesario que cada uno de los miembros tiene que tener el compromiso y la disciplina de seguir el plan. Debe de llenar toda la documentación requerida que incluye sus registros, planificación, las plantillas o formularios. Se debe de contar con un buen conjunto de métricas y parámetros de calidad, lo cual, para algunas organizaciones, puede ser difícil de definir. Cada miembro debe de estar entrenado en el PSP, si algún miembro se va, es necesario entrenar a los nuevos miembros. RUP Es una metodología de desarrollo de software que está basado en componentes e interfaces bien definidas, y junto con el Lenguaje Unificado de Modelado (UML), constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. • • • • • • • • • • Su función es hacer una propuesta orientada por disciplinas que deben seguir los miembros del equipo de desarrollo de software con el fin de aumentar su productividad en el proceso de desarrollo. Su meta principal es asegurar la producción de software de alta calidad que cumpla con las necesidades de los usuarios, con una planeación y presupuesto predecible. desarrollo iterativo. Administración de requisitos. Uso de arquitectura basada en componentes. Control de cambios. Modelado visual del software. Verificación de la calidad del software. Pretende implementar las mejores prácticas en Ingeniería de Software, de forma que se adapte a cualquier proyecto. Toma en cuenta riesgos. • • Fase de inicio: Consiste en especificar y delimitar los objetivos del proyecto y su alcance con las partes interesadas. fase de elaboración: Se establece la arquitectura base del sistema para brindar una plataforma segura, se definen los casos de uso escogidos para ello. fase construcción: El producto se desarrolla a través de iteraciones donde cada iteración involucra tareas de análisis, diseño e implementación. fase transición: Se libera el producto y se entrega al usuario para un uso real. Se incluyen tareas de marketing, empaquetado atractivo, instalación, configuración, entrenamiento, soporte, mantenimiento. Etc. Los manuales de usuario se completan y refinan con la información anterior. Estas tareas se realizan también en iteraciones. • Es el proceso de desarrollo más general de los existentes actualmente. Es decir, este proceso es de los más utilizados para el desarrollo del software por la mayoría de las empresas, pues su enfoque es bastante optimo y tiende a ser una metodología viable para la mayoría de estas. Es una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo, pues lo roles están muy bien definidos, y dictan quien realiza cada actividad, dependiendo del área en el que se desarrollara, de esta manera es bastante útil para definir roles en los proyectos. Los roles pueden ser reutilizados en proyectos futuros, dando como resultado una mejor organización al proyecto y menos utilización de recursos o tiempo, aspectos que se pueden emplear directamente en el proyecto. • • • Por el grado de complejidad puede ser no muy adecuado. Debido a que es un proceso bastante grande y complejo es muy común que no sea el adecuado para cualquier proyecto pequeño (cosa que se explicara en la siguiente desventaja), es por eso que a veces no puede ser el adecuado. En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo de profesionales necesarios. Al ser una metodología bastante cara y con bastantes requerimientos en cuanto a roles (personales), a veces los costos son muy elevados, dando como resultado una imposibilidad por costear el proyecto. Método pesado. En muchos aspectos tiende a ser muy pesado, pues como se explicaba en los puntos anteriores, la complejidad es alta. KANBAN Este método se basa en el desarrollo incremental, es decir, en la división del trabajo en diferentes partes. Por lo tanto, no se habla de una tarea en sí, sino que se agiliza el proceso de producción al dividir el trabajo en distintos pasos. • • • • • • Mover tarjetas dentro de una lista o trasladar de una lista a otra. En cada tarjeta viene definida una tarea. Asignar personas a tarjetas. Las aplicaciones de Kanban son herramientas colaborativas en las que se invita a distintos miembros e, incluso, a clientes. Añadir notas y comentarios en las tarjetas. Las aplicaciones de Kanban para la gestión de proyectos cuentan con espacio ilimitado para añadir notas en cada tarjeta. Incluir listas de control. Cada tarjeta puede tener una o más listas de verificación. Establecer límites para el avance del proyecto. Algunas aplicaciones de Kanban permiten restringir la cantidad de tareas que se pueden incluir en una lista. Ver las tarjetas como un calendario. Muchas aplicaciones de Kanban ofrecen la posibilidad de activar una vista de calendario. • • Fases: Informar al personal: formar a todo el personal en los principios de Kanban y sus beneficios. • Identificación e implementación en las zonas con problemas: implementar Kanban en aquellos componentes con más problemas para facilitar su proceso. Implementar en el resto de zonas. Revisión del sistema: esta fase consiste en la revisión del sistema, teniendo en cuenta las siguientes recomendaciones para el funcionamiento: ningún trabajo debe ser hecho fuera de secuencia y si se encuentra algún problema notificarlo al supervisor de manera inmediata. • Transparencia: Los tiempos de entrega son más cortos y hay una mayor fiabilidad en los mismos. Todo el mundo sabe cuál es su tarea y en qué momento está de su ciclo. Evita tareas ineficientes: Se evita la sobreproducción y la limitación de los recursos, lo que supone una mayor disponibilidad de materiales. Control de las tareas: El tiempo de producción es más rápido, por tanto, se reduce el control del esfuerzo y se mejora la planificación. Flexibilidad: Como todo el equipo sabe perfectamente cuál es su tarea y la realiza con eficacia, si surge alguna imprevista existe una capacidad de respuesta que permite atenderla. • • • • • no es posible implantar el método Kanban cuando el proveedor tarda mucho en suministrar el producto. Se trata de un sistema que no permite anticiparse a grandes aumentos de la demanda. En el caso de recibir muchos pedidos de golpe la empresa podría encontrarse desbordada. En grandes proyectos es posible que no se cumplan los plazos de entrega Muchos proveedores no aceptan trabajar bajo estas condiciones. Prefieren suministrar los productos bajo el método convencional. Cuando se trabaja con muchas referencias puede resultar un sistema poco eficiente. UML 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. • Características de un UML : • • • • visualizar. Especificar. Construir. documentar y/o ser base de documentación. Lo fundamental herramienta UML: • • • • • de • una La capacidad de diagramación, y los diferentes tipos de diagramas que soporta la herramienta Documentación Construcción Implantación de sistema Flexibilidad para admitir cambios no previstos durante el diseño o el rediseño. • • • • • • • • • • Diagramas de clases Diagramas de objetos Diagramas de casos de uso Diagramas de componentes Diagramas de distribucion Diagramas de actividad Diagramas de estados Diagramas de colaboracion Diagramas de secuencia • • El objetivo de la realización del proyecto podría a ser más alcanzable ya que ayuda a analistas a simplificar el diseño del software. Al utilizar UML será más intuitivo y ayudará a crear sentido sobre los requerimientos y/o procesos del software. Con respecto al diagrama de Clases UML dará una mayor ilustración y visión general del sistema porque se podrán representar los atributos del objeto, tipos de datos, los comportamiento y tipos de retorno UML ayudará a pensar con mayor claridad la fase de codificación. UML colaborará a optimizar el uso del tiempo. • • • • UML solo está orientado a objetos Al parecer no se pueden resolver todos los problemas surgidos con los diagramas UML UML tiene énfasis en el diseño lo que puede ser problemático para algunos desarrolladores. Los diagramas UML pueden ser abrumadores visualmente. Si se intenta ubicar en estos diagramas y trazar todos los escenarios para el sistema de información puede volverse desordenado. De acuerdo a Borini, S. (Desarrollador UML) recomienda incluir hechos básicos, puntuales, e información de alto nivel en los diagramas UML. CONCLUSIONES José Luis Baltazar Anaya Hoy en día el desarrollo de software es un proceso muy complejo, es por eso que se crearon los modelos y metodologías para el desarrollo de sistemas de información, las metodologías de ingeniera de software consisten en el uso de métodos, técnicas, herramientas y modelos para el desarrollo. Actualmente existen muchas metodologías y la selección de cada una de ellas dependerá del tipo de proyecto que se quiera realizar, existen metodologías antiguas y modernas como en todo, ya que, con el paso del tiempo el proceso de desarrollo de software ha ido evolucionando y con ello su nivel de complejidad aumentando, es así que las metodologías modernas contemplan características como el desarrollo de software de manera iterativa, manejo de requerimientos, modelado de software visual, control de cambios, control de riesgos, estos se centran en ser flexibles y adaptables de acuerdo al tipo de proyecto. Existen metodologías que no solo se centran en el software si no que hay algunas que se caracterizan por ayudar al desarrollador a mejorar su nivel de productividad, su nivel de organización, a superar sus propias metas y ser mejor programador, para que, el proyecto se desarrolle de mejor manera y tenga calidad, que es lo que siempre se busca con la ingeniera de software. Es por eso que un ingeniero de software debe conocer, estudiar e identificar cada tipo de modelo y metodología, para siempre estar preparado. Crhistian Ivan Madrueño Aguilar En la actualidad la rapidez y el dinamismo en la industria del software han hecho replantear los cimientos sobre los que se sustenta el desarrollo de software tradicional. Estudios recientes y el mismo mercado actual está marcando la tendencia en la ingeniería del software teniendo como características principales atender a las necesidades de rapidez, flexibilidad y variantes externas que hacen de nuestro entorno una ventaja más competitiva al aumentar la productividad y satisfacer las necesidades del cliente en el menor tiempo posible para proporcionar mayor valor al negocio. Ante esta situación, el grado de adaptación de las metodologías tradicionales a estos entornos de trabajo no eran del todo eficientes y no cubrían las necesidades del mercado actual. En la actualidad existen una gran cantidad de metodologías para el desarrollo de software, separadas en dos grandes grupos; las metodologías tradicionales o pesadas y las metodologías agiles. Las metodologías tradicionales se basan en las buenas prácticas dentro de la ingeniería del software, siguiendo un marco de disciplina estricto y un riguroso proceso de aplicación. Las metodologías agiles, en cambio, representan una solución a los problemas que requieren una respuesta rápida en un ambiente flexible y con cambios constantes, haciendo caso omiso de la documentación rigurosa y los métodos formales. BIBLIOGRAFÍA Hope, J. A. (s.f.). UNIDAD 3- presentacion power point. http://avellano.usal.es. (s.f.). Obtenido de http://avellano.usal.es/~mmoreno/ASTema2.pdf https://moodle2.unid.edu.mx. (s.f.). Obtenido de https://moodle2.unid.edu.mx/dts_cursos_mdl/lic/IEL/SI/AM/06/Modelos.pdf https://repositorio.uca.edu.ar. (s.f.). Obtenido de https://repositorio.uca.edu.ar/bitstream/123456789/522/1/metodologias-desarrollosoftware.pdf https://www.ecured.cu. (s.f.). Obtenido de https://www.ecured.cu/Desarrollo_de_software https://www.elconspirador.com. (s.f.). Obtenido de https://www.elconspirador.com/2013/08/19/modelos-de-desarrollo-de-software/ informatica, g. 3. (s.f.). presentaciones power point unidad 3.