DIFERENTES METODOS DE DESARROLLO DE SOFTWARE
En las dos últimas décadas las notaciones de modelado y posteriormente las herramientas pretendieron ser las "balas de plata" para el éxito en el desarrollo de software, sin embargo, las expectativas no fueron satisfechas. Esto se debe en gran parte a que otro importante elemento, la metodología de desarrollo, había sido postergado. De nada sirven buenas notaciones y herramientas si no se proveen directivas para su aplicación. Así, esta década ha comenzado con un creciente interés en metodologías de desarrollo. Hasta hace poco el proceso de desarrollo llevaba asociada un marcado énfasis en el control del proceso mediante una rigurosa definición de roles, actividades y artefactos, incluyendo modelado y documentación detallada. Este esquema "tradicional" para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamaño ( respecto a tiempo y recursos ) , donde por lo general se exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el más adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Ante las dificultades para utilizar metodologías tradicionales con estas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan a prescindir del “ b uen hacer ” de la ingeniería del software, asumiendo el riesgo que ello conlleva. En este escenario, las metodologías ágiles emergen como una posible respuesta para llenar ese vacío metodológico. Por estar especialmente orientadas para proyectos pequeños, las metodologías ágiles constituyen una solución a medida para ese entorno, aportando una elevada simplificación que a pesar de ello no renuncia a las prácticas esenciales para asegurar la calidad del producto. En las secciones siguientes se verán estas diferencias más en detalle, para discernir lo que es un proceso adaptable y centrado en la gente, sus beneficios y desventajas, y qué se debería usar: sea como desarrollador o como cliente de software.
METODO EN CASCADA METODO EN ESPPIRAL METODO DE CODIFICAR Y CORREGIR METODO DE PROTOIPO
Todo lo referente con los diferentes tipos de metodologías, su características , ventajas y funcionamiento
Definición de Software: Según el Webster ’ s New Collegiate Dictionary ( 1 975 ) , “ software es un conjunto de programas, procedimientos y documentación relacionada asociados con un sistema, especialmente un sistema informático ” .
Ingeniería del Software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar ( funcionar ) y mantenerlos. Se conoce también como desarrollo de software o producción de software ( Bohem, 1976 )
Desarrollo “ t radicional ” de software La forma tradicional de desarrollar software se basa en procesos predefinidos con documentación muy precisa, y una detallada planificación inicial que debe seguirse estrictamente. Esta forma de trabajar surgió naturalmente hace unos cincuenta años como una adaptación del manejo de proyectos de ingeniería, que era lo más parecido a desarrollar programas que se conocía en ese momento, y funcionó razonablemente bien en un comienzo. También es necesario tener en cuenta que los ordenadores era enormemente caros, la mayor parte de la inversión informática se la llevaban los equipos y por esta razón los programas se hacían a medida para unas máquinas que se adquirían, no lo olvidemos, para realizar unas tareas muy concretas. Pero los proyectos de desarrollo de software en la actualidad incluyen desafíos muy diferentes a los que se presentan al construir puentes y casas, por lo que no sorprende que los métodos tradicionales de desarrollo de software estén en crisis. ( C olusso Ricardo Gabardini Juan )
¿Qué es metodología? Una metodología es aquella guía que se sigue a fin realizar las acciones propias de una investigación.
Las metodologías han evolucionado de manera significativa en las últimas décadas como se puede observar. Permitiendo así el éxito o el fracaso de muchos de los sistemas desarrollados para distintas áreas.
METODOS DEL DESARROLLO DE SISTEMA DE INFORMACIÓN Métodos de Desarrollo de Sistemas: Son Pautas de desarrollo brindado por los modelos de ciclos de vida, los cuales están constituidos por las siguientes etapas: Especificación de requerimientos: Se realizan entrevistas con el usuario identificando los requerimientos y necesidades del usuario. Análisis: Modela los requerimientos del usuario. Diseño: Se modela la solución del sistema, teniendo en cuenta el ambiente de implementación a utilizar, por ejemplo, si el sistema es centralizado o distribuido, la base de datos a utilizar, lenguaje de programación, performance deseada, etc. Implementación: Dado el lenguaje de programación elegido se implementa el sistema. Testeo: En esta etapa se verifica y valida el sistema teniendo en cuenta algunos criterios determinados por el grupo correspondiente. Mantenimiento: Es la etapa más difícil de desarrollo del sistema, actualiza y modifica
METODOLOGIAS DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN Son métodos que indican cómo hacer más eficiente el desarrollo de sistemas de información. Para ello suelen estructurar en fases la vida de dichos sistemas con el fin de facilitar su planificación, desarrollo y mantenimiento. Las metodologías de desarrollo de sistemas deben definir: objetivos, fases, tareas, productos y responsables, necesarios para la correcta realización del proceso y su seguimiento. Los principales objetivos de una metodología de desarrollo son:
Asegurar la uniformidad y calidad tanto del desarrollo como del sistema en sí.
Satisfacer las necesidades de los usuarios del sistema.
Conseguir un mayor nivel de rendimiento y eficiencia del personal asignado al desarrollo.
Ajustarse a los plazos y costes previstos en la planificación.
Generar de forma adecuada la documentación asociada a los sistemas.
Facilitar el mantenimiento posterior de los sistemas.
METODO EN CASCADA En un modelo en cascada, un proyecto progresa a través de una secuencia ordenada de pasos partiendo de la especificación de requerimientos hasta el mantenimiento del mismo. Realiza una revisión al final de cada etapa para determinar si está preparado para pasar a la siguiente etapa, por ejemplo, desde el análisis de requerimientos hasta el diseño. Cuando la revisión determina que el proyecto no está listo pasar a la siguiente, permanece en la etapa actual hasta que esté preparado. Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo. Ayuda a minimizar los gastos de la planificación porque permite realizarla sin planificación porque permite realizarla sin problemas. Funciona especialmente bien si se dispone de personal poco cualificado o dispone de personal poco cualificado o inexperto, porque presenta el proyecto inexperto, porque presenta el proyecto con una estructura que ayuda a minimizar con una estructura el esfuerzo in-
útil. En resumen, los inconvenientes del venerado modelo en cascada hacen que sea, a menudo, un modelo poco apropiado para un proyecto de desarrollo rápido. Incluso en los casos en los que las ventajas del modelo en cascada pura superan los inconvenientes, los modelos de cascada modificada (con retroceso) pueden funcionar mejor. Las desventajas del modelo se centran en las dificultades para especificar claramente los requerimientos al comienzo del proyecto, antes de que se realice ningún trabajo de diseño y antes de escribir ningún código. No proporciona resultados tangibles en forma de software hasta el final del ciclo de forma de software del ciclo de vida de Algunas herramientas, métodos y actividades que abarcan varias etapas de la cascada; estas actividades son difíciles de ajustar en las etapas discontinuas del modelo para un proyecto de desarrollo rápido, el modelo en cascada puede suponer una cantidad excesiva de documentación.
METODO EN ESPIRAL Es un modelo de ciclo de vida orientado a riesgos que divide un proyecto software en mini -proyectos. Cada mini proyecto se centra en uno o más riesgos importantes hasta que todos estén controlados. Después de controlar todos los riesgos más importantes, el modelo en espiral finaliza del mismo modo que el ciclo de vida en cascada. Método Desarrollo en Espiral Funcionamiento: Se parte de una escala pequeña en medio de la espiral, se localizan los riesgos, se genera un plan para manejar los riesgos, y a continuación se establece una aproximación a la siguiente interacción. Cada iteración supone que el proyecto pasa a una escala superior. Se avanza un nivel en el Espiral, se comprueba que se tiene lo que se desea, y después se comienza a trabajar en el siguiente nivel: Con cada iteración a través del espiral se construye sucesivas versiones de software cada vez más completas. En cada bucle alrededor del espiral, la culminación del análisis de riesgo resulta una decisión de “seguir” o “no seguir”. Cada interacción en el método espiral lleva consigo los seis pasos que a continuación se nombran: Determinar objetivos, alternativas y límites, Identificar y resolver riesgos, Evaluar alternativas, Generar las entregas de esa iteración, y comprobar que son correctas. En el modelo en espiral, las primeras iteraciones son las menos costosas. Supone menos gasto desarrollar el concepto de operación que realizar el desarrollo de los requerimientos, y también es menos costoso desarrollar los requerimientos que llevar a cabo el desarrollo del diseño, la implementación del producto y la prueba del mismo. En cada Cuadrante del Método espiral se realiza las siguientes actividades: Planificación: Determinación de objetivos, alternativas, restricciones, y elaboración del plan de desarrollo para el ciclo actual. Análisis de Riesgos: Evaluación de las alternativas, identificación y resolución de riesgos. Se decide si se sigue o no con el proyecto Ingeniería: Desarrollo del producto siguiendo un modelo: del ciclo de vida o cascada, prototipo, etc. Desarrollo y pruebas: Evaluación por el cliente, Valoración de resultados.
METODO DE CODIFICAR Y CORREGIR Es un modelo poco útil, pero sin embargo bastante común Se puede tener una especificación formal, o no tenerla Si no se ha utilizado formalmente un método, probablemente ya se esté usando el método Codificar y Corregir en forma intuitiva Cuando se utiliza éste método se empieza con una idea general de lo que se necesita construir, Se utiliza cualquier combinación de diseño, código, depuración y métodos de prueba no formales que sirven hasta que se tiene el producto listo para entregarlo. Ventajas: No conlleva ninguna gestión; no se pierde tiempo en la planificación, en la documentación, en el control de calidad, en el cumplimiento de los estándares, o en cualquier otra actividad que no sea codificación pura. Como se pasa directamente a codificar, se pueden mostrar inmediatamente indi-
cios de progreso. Requiere poca experiencia: cualquier persona que haya escrito alguna vez un programa está familiarizada con éste modelo. Para proyectos pequeños que se intentan liquidar en un tiempo breve, o para modelos como programas de demostración o prototipos desechables, el modelo codificar y corregir puede ser útil. Desventajas: El modelo resulta peligroso para otro tipo de proyectos que no sean pequeños. Puede que no suponga gestión alguna, pero tampoco ofrece medios de evaluación del progreso. No proporciona medios de evaluación de la calidad o de identificación de riesgos. Si al llevar tres cuartas partes de la codificación descubre que el diseño es incorrecto, no hay otra solución que desechar el trabajo y comenzar de nuevo.
METODO PROTOTIPO Este método hace que el usuario participe de manera más directa en la experiencia de análisis y diseño que cualquiera de los ya presentados. La construcción de prototipos es muy eficaz bajo las circunstancias correctas. Sin embargo, al igual que los otros métodos, el método es útil sólo si se emplea en el momento adecuado y en la forma apropiada. ¿Qué es un prototipo? El prototipo es un sistema que funciona, no solo una idea en el papel, desarrollado con la finalidad de probar ideas y suposiciones relacionadas con el nuevo sistema. Al igual que cualquier sistema basado en computadora, está constituido por software que acepta entradas, realiza cálculos, produce información ya sea impresa o presentada en una pantalla, o que lleva a cabo otras actividades significativas. Es la primera versión, o iteración, de un sistema de información. Lo usuarios evalúan el diseño y la información generada por el sistema. Lo anterior sólo puede hacerse con efectividad si los datos utilizados, al igual que las situaciones, son reales. Por otra parte, deben esperarse cambios a medida que el sistema es utilizado. Razones para desarrollar prototipos de sistemas: Los requerimientos de información no siempre están bien definidos. Es probable que los usuarios conozcan sólo ciertas áreas de la empresa donde se necesiten mejoras o cambios en los procedimientos actuales. También es posible que reconozcan la necesidad de tener mejor información para administrar ciertas actividades pero que no estén seguros cual de esta información será la adecuada. Los requerimientos del usuario pueden ser demasiado vagos aun al formular el diseño. En otros casos, es probable que una investigación de sistemas bien llevada necesite del desarrollo de nueva tecnología.
Los prototipos permiten evaluar situaciones extraordinarias donde los encargados de diseñar e implantar sistemas no tienen información ni experiencia, o también donde existen situaciones de riesgo y costo elevados, y aquellas donde el diseño propuesto es novedoso y aún no se demuestra es la factibilidad de que los vendedores envíen ordenes de pedido al sistema de cómputo de la compañía desde el sitio donde efectúan la operación por medio de terminales portátiles enlazadas a teléfonos públicos. El prototipo es, en realidad, un modelo piloto o de prueba, en general, los analistas de sistemas encuentran que los prototipos tienen mayor utilidad bajo las siguientes condiciones: Los encargados de diseñar e implantar sistemas nunca han desarrollado uno con las características del sistema propuesto. Se conoce sólo una parte de las características esenciales del sistema; las demás no son identificables a pesar de un cuidadoso análisis de requerimientos. La experiencia con el uso del sistema añadirá una lista significativa de requerimientos que el sistema debe satisfacer. Las diferentes versiones del sistema evolucionan con la experiencia al igual que el desarrollo adicional y el refinamiento de sus características. Los usuarios del sistema participan en el proceso de desarrollo. Los pasos a seguir en el proceso de desarrollo de prototipos son los siguientes: Identificar los requerimientos de información que el usuario conoce junto con las características necesarias del sistema. Desarrollar un prototipo que funcione. Utilizar el prototipo anotando las necesidades de cambios y mejoras. Esto expande la lista de los requerimientos de sistemas conocidos. Revisar el prototipo con base en la información obtenida a través de la experiencia del usuario. Repetir los pasos anteriores las veces que sea necesario hasta obtener5 un sistema satisfactorio. Él analista debe de reunirse con los usuarios una o dos veces con la finalidad de identificar los requerimientos. El resultado de estas reuniones forma la base para la construcción del prototipo. El desarrollo de un prototipo que funcione es responsabilidad del analista de sistemas, cuando el analista y el usuario deciden que cuentan ya con la suficiente información proveniente del proceso de construcción del prototipo, determinan cómo satisfacer los requerimientos ya identificados. En general se opta por una de las siguientes opciones: Volver a desarrollar el prototipo. Esta alternativa quizá signifique volver a programar por completo, empezando desde el principio. Implantar el prototipo como sistema terminado La eficiencia en el funcionamiento junto con los métodos para interactuar con el usuario son suficientes; esto permite utilizar el sistema tol como está. Abandonar el proyecto. En este caso el prototipo ha proporcionado información suficiente para demostrar que no es posible desarrollar el sistema para satisfacer los objetivos deseados dentro del marco de la tecnología existente o de lineamientos económicos u operacionales. Iniciar otra serie de construcción de prototipos. La información ganada con la experiencia sugiere ya sea un enfoque totalmente distinto o características contrastantes. Cada una de estas opciones se considera como un éxito en el proceso de la construcción de prototipos. Métodos para el desarrollo de prototipos Con los prototipos la velocidad de desarrollo es más importante que la eficiencia en el procesamiento. Un sistema prototipo se construye con rapidez, los sistemas prototipo pueden desarrollarse con métodos y lenguajes de programación convencionales, quizá falten los controles de entrada y procesamiento y, en general, la documentación del sistema es un punto que suele evitarse. Lo importante es ensayar ideas y generar hipótesis relacionadas con los requerimientos y que la eficiencia y perfección alcanzadas. La industria de computadora busca continuamente generadores de aplicaciones, programas que sirven para generar otros programas, para apoyar los esfuerzos de la construcción de prototipos. En algunos casos, aquellos donde el sistema será utilizado con poca frecuencia, el prototipo puede, de hecho, convertirse en el sistema terminado.
Las metodologías han evolucionado de manera significativa en las últimas décadas como se puede observar en la tabla 2.7 Permitiendo así el éxito o el fracaso de muchos de los sistemas desarrollados para distintas áreas. Algunas de las metodologías tradicionales más utilizadas para el desarrollo de software han sido, la denominada “proceso personal de software (PSP)” y la “proceso en equipo para el software TSP”. El TSP toma sus fundamentos en que los ingenieros deben de dar a conocer bien su trabajo y que puedan implementar un plan para poderlo realizar mejor, cuando el plan se implementa, pueden ahorrarse tiempo en realizar el trabajo y por ende generar productos de calidad. El TSP contempla dos componentes principales: 1)Creación de equipo 2) Trabajo en equipo o componente de gestión. El TSP es una metodología para dirigir el desarrollo de software además de establecer un entorno donde el trabajo efectivo de equipo sea normal y natural. En donde involucra a los ingenieros a desarrollar un trabajo en equipo. El desarrollo del (TSP) toma sus bases en la estrategia de calidad que propuso W. Edwards Deming (1982), con las etapas de planear, hacer, verificar y actuar. Y J.M. Juran (1988). El TSP ofrece un contexto disciplinado para el trabajo de la ingeniería del software. La motivación principal es que los ingenieros siguiendo esta metodología pueden hacer un excelente trabajo. Los ingenieros deben estar bien capacitados, bien entrenados y deben ser bien dirigidos por un miembro calificado que entienda bien la metodología del TSP.
El objetivo principal del TSP es guiar debidamente a sus equipos de ingenieros. El TSP proporciona un proceso operacional definido para guiar a los ingenieros y administradores a través de diferentes pasos para la formación de equipos de trabajo. Antes de que los miembros del equipo de trabajo participen en el equipo de TSP, deben saber cómo organizar bien su trabajo. Se requiere que el equipo o el personal se encuentre entrenado primero con el Personal Software Process (PSP). Esto le permite a los ingenieros obtener el conocimiento en saber cómo crear un plan detallado, reuniendo y usando procesos de datos, usando valores obtenidos para seguir un proyecto en donde puedan medir y dirigir la calidad del producto. El objetivo del PSP es poner a los profesionales de software a cargo de su trabajo y para que se sientan personalmente responsables de la calidad de los productos que producen. PSP puede trabajar a la par con los objetivos de la metodología (TSP) son: 1) Proporcionar un entorno de equipo que apoya el trabajo de la PSP 2) Construir y mantener un equipo auto -dirigido. PSP y TSP son potentes herramientas que proporcionan los conocimientos necesarios, la disciplina y el compromiso necesarios para los proyectos de software exitoso. Se sabe que en nuestro país para que se pueda producir software con calidad se debe de adoptar un nivel de madurez de procesos alto, es decir, que sea equiparable a los niveles internacionales, esto es a través del CMMI (Capability Maturity Model Integration), pero es difícil implementarlo en organizaciones pequeñas.
Con PSP, los desarrolladores utilizan procesos bien definidos y medibles. Se toma información de tamaño, tiempo y defectos al momento de realizar el trabajo. Se utilizan los datos para: planear y monitorear el trabajo, así como administrar la calidad de los productos que se producen y medir el desempeño. TSP ha permitido resolver problemas típicos de negocio: como predecir el costo y tiempo, mejorar la productividad y establecer ciclos de desarrollo para generar la mejora en la calidad de los productos. PSP/TSP mejoran el desempeño tanto de equipos como de individuos; es disciplinado y dirigida en todo su desarrollo a la planeación; provee beneficios inmediatos y medibles; acelera las iniciativas de mejora de los procesos organizacionales. Con TSP, los equipos encuentran y reparan defectos en etapas tempranas del proceso de desarrollo. Esto reduce de manera importante el tiempo de pruebas.
¿Qué es una Metodología Ágil? Las Metodologías Ágiles o “ l igeras ” constituyen un nuevo enfoque en el desarrollo de software, mejor aceptado por los desarrolladores de e-projects que las metodologías convencionales ( ISO-9000, CMM, etc.) debido a la simplicidad de sus reglas y prácticas, su orientación a equipos de desarrollo de pequeño tamaño, su flexibilidad ante los cambios y su ideología de colaboración
En una reunión celebrada en febrero de 2001 en Utah-EEUU, nace el término "ágil" aplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan
surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas. Varias de las denominadas metodologías ágiles ya estaban siendo utilizadas con éxito en proyectos reales, pero les faltaba una mayor difusión y reconocimiento.
Actualmente los negocios operan en un entorno global que cambia rápidamente. Tienen que responder a nuevas oportunidades y mercados, condiciones económicas cambiantes y la aparición de productos y servicios competidores. El software es parte de casi todas las operaciones de negocio, por lo que es fundamental que el software nuevo se desarrolle rápidamente para aprovechar nuevas oportunidades y responder a la presión competitiva. Actualmente el desarrollo y entrega de manera rápida son los requerimientos más críticos de los sistemas. De hecho, muchas organizaciones están dispuestas a obtener una pérdida en la calidad del software y en el compromiso sobre los requerimientos en favor de una entrega rápida del software. Los procesos de desarrollo del software basados en una completa especificación de los requerimientos, diseño, construcción y pruebas del sistema no se ajustan al desarrollo rápido de aplicaciones. Cuando los requerimientos cambian o se descubren problemas con ellos, el diseño o implementación del sistema se tiene que volver a realizar o probar. Como consecuencia, normalmente se prolonga en el tiempo un proceso en cascada convencional y el software definitivo se entrega mucho tiempo después al cliente con el que inicialmente se pactó. En un entorno de negocios tan cambiante, esto puede causar verdaderos problemas. Para cuando esté disponible el software, la razón original de su adquisición puede ser que haya cambiado de forma radical que en realidad éste sea inútil. Dicha metodología combina una filosofía y un conjunto de directrices de desarrollo. La filosofía busca la satisfacción del cliente y la entrega temprana de software incremental, equipos pequeños con alta motivación, métodos informales y una simplicidad general del desarrollo. Los procesos de desarrollo rápido de software están diseñados para producir software útil de forma rápida. Generalmente, son procesos interactivos en los que se entrelazan la especificación, el diseño, el desarrollo y las pruebas. En los años 80 y principios de los 90, existía una opinión general de que la mejor forma de obtener un software de calidad era a través de una planificación cuidadosa del proyecto y de la utilización de métodos de análisis y diseño soportados por herramientas CASE ( Computer Aided Software Engineering ) . Esta opinión venía fundamentalmente de la comunidad de ingenieros de software implicado en el desarrollo de grandes sistemas y que normalmente se componían de un gran número de programas individuales. Este software era desarrollado por grandes equipos que trabajaban para compañías diferentes y que a menudo estaban dispersos geográficamente y trabajaban durante largos periodos de tiempo. Sin embargo, cuando este enfoque era aplicado a sistemas de negocios pequeños y de tamaño medio, el esfuerzo invertido era tan grande que algunas veces dominaba el proceso de desarrollo del software, es decir, se pasaba más tiempo pensando en cómo se debía desarrollar el sistema que en cómo programar el desarrollo y cómo hacer las pruebas pertinentes.
Vamos a enumerar las principales diferencias de una Metodología Ágil respecto de las Metodologías Tradicionales (llamadas peyorativamente “no ágiles” o “pesadas”). La Tabla recoge estas diferencias que no se refieren sólo al proceso en sí, sino también al contexto de equipo y organización que es más favorable a cada uno de estas filosofías de procesos de desarrollo de software.
Metodología Ágil
Metodología Tradicional
Pocos Artefactos. El modelado es pres- Más Artefactos. El modelado es esencindible, modelos desechables. cial, mantenimiento de modelos Pocos Roles, más genéricos y flexibles
Más Roles, más específicos
No existe un contrato tradicional, debe Existe un contrato prefijado ser bastante flexible Cliente es parte del equipo de desarrollo El cliente interactúa con el equipo de (además in-situ) desarrollo mediante reuniones Orientada a proyectos pequeños. Corta Aplicables a proyectos de cualquier taduración (o entregas frecuentes), equi- maño, pero suelen ser especialmente pos pequeños (< 10 integrantes) y traba- efectivas/usadas en proyectos grandes y con equipos posiblemente disjando en el mismo sitio persos La arquitectura se va definiendo y mejo- Se promueve que la arquitectura se rando a lo largo del proyecto defina tempranamente en el proyecto Énfasis en los aspectos humanos: el in- Énfasis en la definición del proceso: dividuo y el trabajo en equipo roles, actividades y artefactos Basadas en heurísticas provenientes de Basadas en normas provenientes de estándares seguidos por el entorno de prácticas de producción de código desarrollo Se esperan cambios durante el proyecto Se espera que no ocurran cambios de gran impacto durante el proyecto
Referencias: MARIO, T. ( 9 9 ) . MODELO LINEAL SECUENCIAL. Pressman, R. ( 2 007 ) . INGENIERIA DEL SOFTWARE. Mac Graw Hill. Sommerville, I. ( s.f. ) . INGENIERIA DEL SOFTWARE. Prentice Hall.
Nuevas Tendencias en sistemas de Información ( b ajo el enfoque de la ingeniería del software) . Metodologías de Desarrollo de software ( metodologías tradicionales, agiles y las comunes ) Modelos y metodologías para el desarrollo de software ( Relación, comparación, ) Métodos de Desarrollo de Software
REALIZADO POR: JHON SARMIENTO ESCUELA DE SISTEMAS CURSO SISTEMAS DE INFORMACIÃ&#x201C;N