Metodología de Desarrollo de Software

March 20, 2018 | Author: Arcangel2701 | Category: Software Engineering, Software Development Process, Software, Computer Programming, Systems Theory


Comments



Description

Metodología de desarrollo de software TRES DEFINICIONE 1. son un conjunto de procedimientos, técnicas y ayudas para el desarrollo de productos software.En si pasos naturales o logicos para la construccion de software 2. se definen como un con junto de pasos como analicis diseño desarollo implementacion pruevas y implantacion llamados ciclo de vida como una definicion general 3. Es conjunto ordenado de pasos a seguir para llegar a la solución de un problema u obtención de un producto osea el software, son tambien los pasos generales que sigue el proceso de desarrollo de un producto software Las metodologías de desarrollo de software son un conjunto de procedimientos, técnicas y ayudas a la documentación para el desarrollo de productos software En esta ocasión me gustaría hacer énfasis en la importancia que tiene el uso de metodologías de desarrollo de software a un nivel de introducción básica. Tenemos a continuacion el clásico chiste acerca de la implementación de soluciones de cómputo: Pero la contra al chiste clásico de la implementación de soluciones de cómputo puede lograrse utilizando metodologías de ingeniería y arquitectura de software, logrando que los proyectos lleguen finalmente a ser exitosos desde los puntos de vista de objetivos de negocio, costos, funcionalidad, sencillez y capacidad de soporte. En general las metodologías llevan a cabo una serie de procesos comunes que son buenas prácticas para lograr los objetivos antes mencionados independientemente de cómo hayan sido diseñadas. Las fases que agrupan estos procesos son las siguientes: Análisis Especificación Diseño Programación Prueba Documentación Mantenimiento Reingeniería Así mismo las diferentes metodologías tienen diversos ciclos de vida del desarrollo de software, los modelos más comúnmente utilizados son los siguientes: Modelo en cascada Modelo en espiral Modelo de prototipos Método en V Desarrollo por etapas Escribiré más adelante acerca de cada una de las metodologías mencionadas a continuación de forma más extensa posteriormente, por lo pronto dejaré abierta la investigación a los lectores acerca de los diferentes marcos de trabajo y metodologías formales de desarrollo de software. Las metodologías a tratar desde el punto de vista de la arquitectura de software y la administración de proyectos serán las siguientes: PROCESOS DE PRODUCCION COMERCIAL Metodologías tradicionales Capability Maturity Model (SW-CMM) Capability Maturity Model Integration for Development (CMMI-DEV) Big Design Up Front (BDUF) Cleanroom Software Engineering Rational Unified Process (RUP) Su objetivo es garantizar la producción de alta calidad • software que satisfaga las necesidades de sus usuarios finales, dentro de un calendario y el presupuesto previsible. software que satisfaga las necesidades de sus usuarios finales, dentro de un calendario y el presupuesto previsible Essential Unified Process for Software Development (EssUP) Fusebox Lifecycle Process (FLiP) Software Process Improvement and Capability dEtermination (SPICE) Introducción a Microsoft Solutions Framework El Microsoft Solutions Framework proporciona un sistema de modelos, principios, y pautas para dar soluciones a empresas que diseñan y desarrollan de una manera que se asegure de que todos los elementos de un proyecto, tales como gente, procesos, y herramientas, puedan ser manejados con éxito. Modelo de Proceso MSF El modelo de proceso MSF combina los mejores principios del modelo en cascada y del modelo en espiral. Combina la claridad que planea el modelo en cascada y las ventajas de los puntos de transición del modelo en espiral. El Modelo de proceso MSF consta de cinco fases distintas: Previsión Planeamiento Desarrollo Estabilización Implementación Métrica 3: es una Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de Información. Puede ser utilizada libremente con la única restricción de citar la fuente de su propiedad intelectual: el Ministerio de Administraciones Públicas. Este Ministerio, desde el Consejo Superior de Informática, ofrece así un instrumento para la sistematización de las actividades que dan soporte al ciclo de vida del software en el desarrollo de Sistemas de Información. Su aplicación pretende los siguientes objetivos: Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de la Organización mediante la definición de un marco estratégico para el desarrollo de los mismos. - Dotar a la Organización de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de requisitos. - Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la Información y las Comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible. - Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos. - Facilitar la operación, mantenimiento y uso de los productos software obtenidos. Jackson System Development (JSD) Joint Application Development (JAD) Open Unified Process (OpenUP) http://elbotondereset.blogspot.com/2008/09/modelo-de-reutilizacion-de-software.html http://elbotondereset.blogspot.com /trabajos51/programacion-extrema/programacion-extrema.shtml Metodologías ágiles Extreme Programming (XP) PROGRAMACIÓN EXTREMA XP (eXtreme Programming) Metodología ágil basada en cuatro principios: simplicidad, comunicación, retroalimentación y valor. Además, orientada por pruebas y refactorización, se diseña e implementan las pruebas antes de programar la funcionalidad, el programador crea sus propios tests de unidad. Este método es típicamente atribuido a Kent Beck, Ron Jeffries y Ward Cinningham. El objetivo de Xp son grupos pequeños y medianos de construcción de software en donde los requisitos aún son muy ambiguos, cambian rápidamente o son de alto riesgo. Xp busca la satisfacción del cliente tratando de mantener durante todo el tiempo su confianza en el producto. Además, sugiere que el lugar de trabajo sea una sala amplia, si es posible sin divisiones (en el centro los programadores, en la periferia los equipos individuales). Una ventaja del espacio abierto es el incremento en la comunicación y el proporcionar una agenda dinámica en el entorno de cada proyecto. Actividades de Xp Codificar Es necesario codificar y plasmar nuestras ideas a través del código. En programación, el código expresa la interpretación del problema, así podemos utilizar el código para comunicar, para hacer comunes las ideas, y por tanto para aprender y mejorar. Hacer pruebas Las características del software que no pueden ser demostradas mediante pruebas simplemente no existen. Las pruebas dan la oportunidad de saber si lo implementado es lo que en realidad se tenía en mente. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema, entonces habremos acabado por completo. Diseñar El diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, lo apropiado es dividirla en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes. Resumiendo las actividades de Xp: Tenemos que codificar porque sin código no hay programas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos que codificar ni probar, y tenemos que diseñar para poder codificar, probar y escuchar indefinidamente. Scrum Agile Modeling Adaptive Software Development (ASD) Crystal Clear Dynamic Systems Development Method (DSDM) Feature Driven Development (FDD) Lean Software Development (LSD) Agile Unified Process (AUP) Software Development Rhythms Agile Documentation ICONIX Process Microsoft Solutions Framework (MSF) Modelo de Reutilizacion de Software Descripción Surge formalmente en 1968 (Dough McIlroy). La idea principal era producir componentes de software como si de componentes electrónicos se tratara. La Reutilización de Software aparece como una alternativa para desarrollar aplicaciones y sistemas SW de una manera más eficiente, productiva y rápida. La idea es reutilizar elementos y componentes de Software en lugar de tener que desarrollarlos desde el principio. Inicialmente, se basaba en la simple combinación de componentes de código almacenados en una biblioteca pero con el tiempo se fueron utilizando código de programas enteros. Características Funcionalidad Es más probable que se reutilice un componente de software que exhiba unas prestaciones que se puedan aplicar en muchos contextos, es decir que realice tareas comunes a muchas aplicaciones. Independencia Un componente sólo será reutilizable si es suficientemente independiente de cualquier aplicación particular. Robustez Su incorporación a muchos entornos diferentes no debe comprometer su corrección ni su eficiencia. El diseñador del componente debe controlar completamente su conexión con las otras unidades externas. Seguridad frente a fallos Agile Data Method Database Refactoring LeanCMMI Metodologías de desarrollo de software Definición Una metodología de desarrollo de software es un conjunto de pasos y procedimientos que deben seguirse para desarrollar software. Una metodología está compuesta por: Cómo dividir un proyecto en etapas. Qué tareas se llevan a cabo en cada etapa. Qué restricciones deben aplicarse. Qué técnicas y herramientas se emplean. Cómo se controla y gestiona un proyecto. 2 Clasificación de las metodologías Las metodologías se clasifican de la siguiente forma: Estructuradas. Orientadas a procesos Orientadas a datos Mixtas No estructuradas. Orientadas a objetos Sistemas de tiempo real Metodologías estructuradas Se basan en la forma top-down Metodologías orientadas a procesos La ingeniería del software se basa en el modelo básico de entrada/proceso/salida de un sistema. Está compuesta por: Diagrama de flujo de datos (DFD). Diccionario de datos. Especificaciones de proceso. Ejemplos: metodologías de DeMarco, Gene y Sarson, Yourdon. Metodologías orientadas a datos Son metodologías basadas en la información. Primero se definen las estructuras de datos y, a partir de éstos, se derivan los componentes procedimentales. Ejemplos: metodologías de Jackson, Warnier, Warnier-Orr. Metodologías no estructuradas Metodologías orientadas a objeto La orientación a objetos unifica procesos y datos encapsulándolos en el concepto de objetos. Tiene dos enfoques distintos: Revolucionario, puro u ortodoxo. Rompen con las metodologías tradicionales. Ejemplos: metodologías OOD de Booch, CRC/RDD de Wirfs-Brock. Sintetista o evolutivo. Toman como base los sistemas estructurados y conforman elementos de uno y otro tipo. Ejemplos: metodología OMT de Rumbourgh. 4.2 Sistemas de tiempo real Procesan información orientada al control más que a los datos. Se caracterizan por concurrencia, priorización de procesos, comunicación entre tareas y acceso simultáneo a datos comunes. Definición TGS La teoría general de sistemas (TGS) o teoría de sistemas o enfoque sistemico es un esfuerzo de estudio interdisciplinario que trata de encontrar las propiedades comunes a entidades, los sistemas, que se presentan en todos los niveles de la realidad, pero que son objeto tradicionalmente de disciplinas académicas diferentes La meta de la Teoría General de los Sistemas no es buscar analogías entre las ciencias, sino tratar de evitar la superficialidad científica que ha estancado a las ciencias. La TGS no busca solucionar problemas o intentar soluciones prácticas, pero sí producir teorías y formulaciones conceptuales que pueden crear condiciones de aplicación en la realidad empírica ciclo de vida del software El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación Diseño general: requisitos generales de la arquitectura de la aplicación. Diseño en detalle: definición precisa de cada subconjunto de la aplicación. Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño. Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones. Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada. Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales. Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros. Implementación Mantenimiento: para todos los procedimientos correctivos MODELO: EL MODELO LINEAL (O MODELO EN CASCADA) : Es el más antiguo de todos los modelos de Ingeniería del Software. El modelo lineal presenta una estructura secuencial (de ahí el nombre de Modelo en cascada) formada por seis fases o etapas: − Análisis del Sistema − Análisis de Requisitos de Software − Diseño en cascada: Se denomina modelo en cascada porque su característica principal es que no se comienza con un paso hasta que no se ha terminado el anterior. Prototipos: Consiste en iterar en la fase de análisis tantas veces como sea necesario, mostrando prototipos al usuario para que pueda indicarnos de forma mas eficiente los requisitos del sistema evolutivo En el modelo evolutivo se asume que los requisitos pueden cambiar en cualquier momento del ciclo de vida y no solo en la etapa de análisis. Incremental: Es una aproximación muy parecida a la evolutiva. 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 mas requisitos. En espiral: Toma las ventajas del modelo de desarrollo en cascada y el de prototipos añadiéndole el concepto de análisis de riesgo http://elbotondereset.blogspot.com/2008/09/modelo-de-reutilizacion-de-software.html http://elbotondereset.blogspot.com /trabajos51/programacion-extrema/programacion-extrema.shtml Contenido ¿Qué son los Modelos de Proceso? Modelo en Cascada. Modelo en Espiral ¿Como funciona el modelo del MSF? Modelo de Proceso MSF ¿Qué son los Modelos de Proceso? Para maximizar el éxito de los proyectos de una empresa. Microsoft ha puesto a disposición una guía para un efectivo diseño, desarrollo y funcionamiento de soluciones, incluyendo las tecnologías de Microsoft. Este conocimiento se deriva de la experiencia ganada dentro de Microsoft con sus clientes y vendedores en proyectos de grande desarrollo de software y de prestación de servicios, la experiencia de los grandes consultores de Microsoft y el mejor conocimiento de la industria mundial de Tecnologías de Información. Un modelo de proceso así pues, dirige el orden de las actividades del proyecto y representa el ciclo de vida de dicho proyecto. Históricamente, algunos modelos de proceso eran estáticos y otros no permitían puntos de comprobación. Dos de estos modelos de proceso son el modelo de cascada y el modelo espiral. Estos modelos proporcionan diversas aproximaciones al ciclo de vida de un proyecto. Modelo en Cascada. Este modelo utiliza tramos como puntos de transición y de carga. Al usar el modelo de cascada, se necesitaría completar un conjunto de tareas en forma de fase para después continuar con la fase próxima. El modelo en cascada trabaja perfectamente para los proyectos en los cuales los requisitos del proyecto se encuentran definidos claramente y no son obligados a futuras modificaciones. Ya que este modelo esta compuesto por puntos de transición entre fases, se puede monitorear fácilmente ya que asigna responsabilidades definidas. Modelo en Espiral Este modelo se basa en la necesidad continua de refinar los requerimientos para un determinado proyecto. El modelo espiral es eficaz cuando se utiliza para el rápido desarrollo de proyectos muy pequeños. Esta logra consigo el acercamiento entre el equipo de desarrollo y el cliente porque el cliente es implicado en todas las etapas proporcionando la regeneración de proyecto y la aprobación del mismo. De cualquier forma, el modelo en espiral no incorpora puntos de comprobación claros. Por lo tanto, el proceso de desarrollo puede llegar a ser caótico. ¿Como funciona el modelo del MSF? El modelo de proceso MSF, propone una secuencia generalizada de actividades para la construcción de soluciones empresariales. Este proceso es flexible y se puede adaptar al diseño y desarrollo de una amplia gama de proyectos de una empresa. El modelo MSF esta basado también basado en fases, puntos de transición y de carga de forma iterativa que se puede aplicar en el desarrollo de aplicaciones tradicionales, soluciones empresariales para comercio electrónico así como aplicaciones Web distribuidas. Metodología de desarrollo de software Las metodologías de desarrollo de software son un conjunto de procedimientos, técnicas y ayudas a la documentación para el desarrollo de productos software TRES DEFINICIONE 1. son un conjunto de procedimientos, técnicas y ayudas para el desarrollo de productos software. En si pasos naturales o logicos para la construccion de software 2. se definen como un con junto de pasos como analicis diseño desarollo implementacion pruevas y implantacion llamados ciclo de vida como una definicion general 3. Es conjunto ordenado de pasos a seguir para llegar a la solución de un problema u obtención de un producto osea el software, son tambien los pasos generales que sigue el proceso de desarrollo de un producto software Las metodologías de desarrollo de software son un conjunto de procedimientos, técnicas y ayudas a la documentación para el desarrollo de productos software En esta ocasión me gustaría hacer énfasis en la importancia que tiene el uso de metodologías de desarrollo de software a un nivel de introducción básica. Tenemos a continuacion el clásico chiste acerca de la implementación de soluciones de cómputo: En general las metodologías llevan a cabo una serie de procesos comunes que son buenas prácticas para lograr los objetivos antes mencionados independientemente de cómo hayan sido diseñadas. Las fases que agrupan estos procesos son las siguientes: • • • • • • • • Análisis Especificación Diseño Programación Prueba Documentación Mantenimiento Reingeniería Así mismo las diferentes metodologías tienen diversos ciclos de vida del desarrollo de software, los modelos más comúnmente utilizados son los siguientes: • • • • • Modelo en cascada Modelo en espiral Modelo de prototipos Método en V Desarrollo por etapas Escribiré más adelante acerca de cada una de las metodologías mencionadas a continuación de forma más extensa posteriormente, por lo pronto dejaré abierta la investigación a los lectores acerca de los diferentes marcos de trabajo y metodologías formales de desarrollo de software. Las metodologías a tratar desde el punto de vista de la arquitectura de software y la administración de proyectos serán las siguientes: Metodologías tradicionales • • • • • • • • • Capability Maturity Model (SW-CMM) Capability Maturity Model Integration for Development (CMMI-DEV) Big Design Up Front (BDUF) Cleanroom Software Engineering Rational Unified Process (RUP) Essential Unified Process for Software Development (EssUP) Fusebox Lifecycle Process (FLiP) Software Process Improvement and Capability dEtermination (SPICE) Métrica • • • Jackson System Development (JSD) Joint Application Development (JAD) Open Unified Process (OpenUP) Metodologías ágiles • • • • • • • • • • • • • • • Extreme Programming (XP) Scrum Agile Modeling Adaptive Software Development (ASD) Crystal Clear Dynamic Systems Development Method (DSDM) Feature Driven Development (FDD) Lean Software Development (LSD) Agile Unified Process (AUP) Software Development Rhythms Agile Documentation ICONIX Process Microsoft Solutions Framework (MSF) Agile Data Method Database Refactoring LeanCMMI Metodologías de desarrollo de software Definición Una metodología de desarrollo de software es un conjunto de pasos y procedimientos que deben seguirse para desarrollar software. Una metodología está compuesta por: • • • • • Cómo dividir un proyecto en etapas. Qué tareas se llevan a cabo en cada etapa. Qué restricciones deben aplicarse. Qué técnicas y herramientas se emplean. Cómo se controla y gestiona un proyecto. Clasificación de las metodologías Las metodologías se clasifican de la siguiente forma: • • Estructuradas. o Orientadas a procesos o Orientadas a datos o Mixtas No estructuradas. o Orientadas a objetos o Sistemas de tiempo real Metodologías estructuradas Se basan en la forma top-down Metodologías orientadas a procesos La ingeniería del software se basa en el modelo básico de entrada/proceso/salida de un sistema. Está compuesta por: • • • Diagrama de flujo de datos (DFD). Diccionario de datos. Especificaciones de proceso. Ejemplos: metodologías de DeMarco, Gene y Sarson, Yourdon. Metodologías orientadas a datos Son metodologías basadas en la información. Primero se definen las estructuras de datos y, a partir de éstos, se derivan los componentes procedimentales. Ejemplos: metodologías de Jackson, Warnier, Warnier-Orr. Metodologías no estructuradas Metodologías orientadas a objeto La orientación a objetos unifica procesos y datos encapsulándolos en el concepto de objetos. Tiene dos enfoques distintos: • Revolucionario, puro u ortodoxo. Rompen con las metodologías tradicionales. Ejemplos: metodologías OOD de Booch, CRC/RDD de Wirfs-Brock. • Sintetista o evolutivo. Toman como base los sistemas estructurados y conforman elementos de uno y otro tipo. Ejemplos: metodología OMT de Rumbourgh. Sistemas de tiempo real Procesan información orientada al control más que a los datos. Se caracterizan por concurrencia, priorización de procesos, comunicación entre tareas y acceso simultáneo a datos comunes. Definición • TGS • • La teoría general de sistemas (TGS) o teoría de sistemas o enfoque sistemico es un esfuerzo de estudio interdisciplinario que trata de encontrar las propiedades comunes a entidades, los sistemas, que se presentan en todos los niveles de la realidad, pero que son objeto tradicionalmente de disciplinas académicas diferentes La meta de la Teoría General de los Sistemas no es buscar analogías entre las ciencias, sino tratar de evitar la superficialidad científica que ha estancado a las ciencias. La TGS no busca solucionar problemas o intentar soluciones prácticas, pero sí condiciones de producir teorías y formulaciones conceptuales que pueden crear aplicación en la realidad empírica ciclo de vida del software El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación · · · Diseño general: requisitos generales de la arquitectura de la aplicación. Diseño en detalle: definición precisa de cada subconjunto de la aplicación. Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño. · Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones. · Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada. · · · · Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales. Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros. Implementación Mantenimiento: para todos los procedimientos correctivos os modelos en cascada: Se denomina modelo en cascada porque su característica principal es que no se comienza con un paso hasta que no se ha terminado el anterior. Prototipos: Consiste en iterar en la fase de análisis tantas veces como sea necesario, mostrando prototipos al usuario para que pueda indicarnos de forma mas eficiente los requisitos del sistema evolutivo En el modelo evolutivo se asume que los requisitos pueden cambiar en cualquier momento del ciclo de vida y no solo en la etapa de análisis. Incremental: Es una aproximación muy parecida a la evolutiva. 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 mas requisitos. En espiral: Toma las ventajas del modelo de desarrollo en cascada y el de prototipos añadiéndole el concepto de análisis de riesgo EL MODELO LINEAL (O MODELO EN CASCADA) : Es el más antiguo de todos los modelos de Ingeniería del Software. El modelo lineal presenta una estructura secuencial (de ahí el nombre de Modelo en cascada) formada por seis fases o etapas: − Análisis del Sistema − Análisis de Requisitos de Software − Diseño Surge formalmente en 1968 (Dough McIlroy). La idea principal era producir componentes de software como si de componentes electrónicos se tratara. La Reutilización de Software aparece como una alternativa para desarrollar aplicaciones y sistemas SW de una manera más eficiente, productiva y rápida. La idea es reutilizar elementos y componentes de Software en lugar de tener que desarrollarlos desde el principio. Inicialmente, se basaba en la simple combinación de componentes de código almacenados en una biblioteca pero con el tiempo se fueron utilizando código de programas enteros. Características Funcionalidad Es más probable que se reutilice un componente de software que exhiba unas prestaciones que se puedan aplicar en muchos contextos, es decir que realice tareas comunes a muchas aplicaciones. Independencia Un componente sólo será reutilizable si es suficientemente independiente de cualquier aplicación particular. Robustez • Su incorporación a muchos entornos diferentes no debe comprometer su corrección ni su eficiencia. • El diseñador del componente debe controlar completamente su conexión con las otras unidades externas. Seguridad frente a fallos Modelo de Reutilizacion de software
Copyright © 2024 DOKUMEN.SITE Inc.