ingeniería & metodologías

Universidad del Valle Facultad de Ingeniería | Escuela de Ingeniería de Sistemas y Computación

Pável Franco Marín, Ing. [email protected]

Metodologías

Desarrollo de Software II



Agenda

• Definición

• Proyecto. Proyecto de software

• Ingeniería del software

• Modelos de desarrollo

• Metodologías para la ejecución de proyectos de software

• Familias metodológicas

• Algunas metodologías

• Bibliografía



AGENDA

• Definición • Proyecto. Proyecto de software • Ingeniería del software • Modelos de desarrollo • Metodologías para la ejecución de proyectos de software • Familias metodológicas • Algunas metodologías • Bibliografía



Definición

Metodología, viene del griego μετη metá "más allá", οδως odós "camino" y λογος logos "estudio“. Metodología hace referencia a un conjunto de procedimientos basados en principios lógicos, utilizados para alcanzar objetivos. En este orden de ideas, las metodologías se convierten en pieza fundamental para la implementación de proyectos de cualquier índole.



AGENDA




Proyecto. Proyecto de software

Proyecto se puede definir como el conjunto de actividades que se deben realizar para crear un producto, bien, servicio o resultado, con recursos finitos y bajo unas condiciones iniciales claramente definidas (Blackstone, Cox y Schleier, 2009). Con el ánimo de comprender la magnitud de un proyecto, se debe tener en cuenta que todos éstos tienen una finalidad particular que es la producción gradual de algo, que siempre se ejecutan limitados por recursos finitos, bien sea humanos, económicos y/u otros y que sólo bajo unos parámetros iniciales claramente definidos, producto de una necesidad, permiten dar inicio a los mismos.




Claramente se puede apreciar que los proyectos no sólo obedecen a sus propias condiciones, sino que existen variables externas a éstos que se deben tener en cuenta para su ejecución, dependiendo por ejemplo del proyecto, de la organización o del recurso humano. En este sentido, pueden llegar a existir diversas clasificaciones para los proyectos dependiendo del presupuesto, de su intención, del mercado, del sector industrial e incluso, de la organización que lo ejecute, así lo que establece la principal diferencia entre un proyecto y otro, son los productos, bienes, servicios o resultados que producen, tal es el caso de los proyectos de software, donde el resultado de éstos se da acorde a las necesidades de la industria del software donde se generan las necesidades y parámetros iniciales para dar inicio a los proyectos como ya se indicó anteriormente.




En este orden de ideas y de acuerdo a lo definido por Pressman (2005), es

posible aplicar un marco de

trabajo para la gran mayoría de

proyectos de software que se puede constituir como las fases del proyecto,

como se indica a continuación:

“Comunicación. Esta actividad del marco de trabajo implica una intensa colaboración con los clientes; además, abarca la investigación de requisitos y otras actividades relacionadas.

Planeación. Esta actividad establece un plan para el trabajo de la ingeniería del software. Describe las tareas y técnicas que deben realizarse, los riesgos probables, los recursos que serán requeridos, los productos del trabajo que han de producirse y un programa de trabajo.

Modelado. Esta actividad abarca la creación de los modelos que permiten al desarrollador y al cliente entender mejor los requisitos del software y el diseño que logrará satisfacerlos.

Construcción. Esta actividad combina la generación del código (ya sea manual o automatizado) y la realización de pruebas necesarias para descubrir errores en el código.

Despliegue. El software (como entidad completa o un incremento completado de manera parcial) se entrega al cliente, quien evalúa el producto recibido y proporciona información basada en su evaluación.” p. 26



AGENDA




Ingeniería del software

Aunque existen varias definiciones para entender el concepto de ingeniería del software de acuerdo a cada autor, a continuación se cita la definición dada por Fritz Bauer, seguido por Pressman (2005), en una conferencia fundamental sobre la materia:

“[La ingeniería del software es] el establecimiento y uso de principios sólidos de la ingeniería para obtener económicamente un software confiable y que funcione de modo eficiente en máquinas reales” p. 23

En este sentido, la ingeniería del software se puede ver como una disciplina que tiene en cuenta elementos administrativos y tecnológicos, dado que es necesario administrar una serie de recursos y porque hace uso de la tecnología y ciencias de la computación inherentes a la fabricación de software, respectivamente.



AGENDA




Modelos de desarrollo

Según Pressman (2005), una organización perteneciente a la industria del software debería describir un conjunto único de actividades para un marco de trabajo definido para los procesos de software adoptados. Esto se podría definir cómo modelo de desarrollo, pues cada organización debe adaptar la definición de su modelo, a la naturaleza específica de cada proyecto. Siendo consecuentes con lo mencionado, se han definido a lo largo del proceso evolutivo de la industria del software, una serie de modelos de desarrollo “genéricos” que algunas organizaciones, eventualmente podrían adoptar, bien sea en su forma pura o con ciertas modificaciones de acuerdo a sus necesidades. Sin embargo, es importante tener en cuenta que sin importar el modelo seleccionado, la industria del software ha elegido un marco de trabajo estándar que se define bajo el contexto de las actividades de comunicación, planeación, modelado, construcción y desarrollo.




MODELO EN CASCADA

Pressman (2005), define que el modelo en cascada –también llamado el ciclo de vida clásico– sugiere un enfoque sistemático y secuencial hacia el desarrollo de software que indica ciertas etapas y actividades como se muestra en la siguiente gráfica.




El modelo en cascada es el paradigma más antiguo para la ingeniería del software, sin embargo en décadas pasadas, las críticas al mismo han ocasionado que incluso sus más fieles seguidores hayan puesto en duda su eficiencia, Pressman (2005), pues para trabajar con un modelo en cascada, es necesario tener en cuenta algunos aspectos que de alguna forma se constituyen en sus desventajas; a continuación se enlistan: • El modelo propone un flujo de trabajo secuencial y pocas veces un proyecto se

ejecuta de esta forma, y aunque el modelo incluye interacciones, lo hace de forma indirecta generando cambios que confunden mientras el proyecto sigue su ejecución.

• En ocasiones es complicado establecer todos los requerimientos de forma explícita, y la metodología exige que éstos sean definidos en las etapas iniciales, pues de lo contrario, los costos de reproceso sería demasiado alto en términos económicos y de tiempo.

• El cliente debe ser paciente, pues los resultados no se evidencian rápidamente dado que la ejecución de cada una de las etapas, generalmente toma demasiado tiempo, y normalmente, lo clientes sienten bajo esta situación que están perdiendo tiempo y dinero.




MODELOS DE PROCESO INCREMENTALES

Pressman (2005), define que:

“En muchas situaciones los requisitos iniciales del software están bien definidos en forma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un proceso puramente lineal. Además, quizá haya una necesidad imperiosa de proporcionar de manera rápida un conjunto limitado de funcionalidades para el usuario y después refinarla y expandirla en las entregas posteriores del software. En estos casos se elige un modelo de proceso diseñado para producir el software en forma incremental” p. 51

A continuación se definen las principales características de algunos modelos incrementales:




Modelo incremental

El modelo incremental toma el modelo en cascada y lo aplica de forma iterativa como se muestra en la siguiente gráfica.

Básicamente se aplican secuencias lineales de forma escalonada de acuerdo al avance del proyecto, donde cada

secuencia genera incrementos del software,

Pressman (2005).




Además, Pressman (2005) planeta que el modelo incremental al igual que el modelo de prototipos y otros enfoques evolutivos, es iterativo por naturaleza, sin embargo el modelo incremental se enfoca en la entrega de un producto operacional en cada incremento que eventualmente se convierten en versiones parciales del software, lo que no necesariamente ocurre con el modelo de prototipos, pues cada una de sus entregas, no necesariamente es una versión funcional del software. Esta ejecución permite tener una variación en el número de personas involucradas en el equipo de trabajo, pues en algunas etapas es posible que no sea necesario un número tan alto, mientras que en otras sí.




Modelo DRA El modelo de Desarrollo Rápido de Aplicaciones (DRA), resalta un ciclo de desarrollo corto, siendo en sí mismo una adaptación a alta velocidad del modelo en cascada, donde se logra un rápido desarrollo a través de la construcción de un software basado en componentes, Pressman (2005). Con base en lo anterior, y teniendo en cuenta lo descrito por Pressman (2005), en la siguiente gráfica se evidencia que se deben establecer ciertas restricciones en términos del alcance del proyecto y tomando como base los requerimientos, lo que es necesario para cumplir con los tiempos establecidos por el modelo.




MODELOS DE PROCESO EVOLUTIVOS

Siguiendo a Pressman (2005), al igual que todos los sistemas complejos, el software, evolucionan con el tiempo y los requerimientos del negocio a los cuales obedece dicho software, cambian de acuerdo a las necesidades del mercado, por ello no existe un esquema lineal que genere como resultado un producto de software. Pressman (2005), indica:

“Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez más completas del software” p. 55

A continuación se definen las principales características de algunos modelos incrementales:




Modelo de prototipos Un modelo de prototipos puede ofrecer mejores resultados si en dentro de la ejecución del proyecto no se tiene claridad sobre las necesidades del cliente o seguridad sobre un desarrollo realizado, pues éste modelo es empleado como proceso independiente que toma la forma de una técnica susceptible de implementarse dentro del contexto o como complemento de cualquier otro modelo, Pressman (2005). Así, el modelo permite sortear diferentes situaciones confusas en términos de definiciones, por ejemplo, buscado poco a poco generar las definiciones necesarias y clarificar los elementos que lo requieran.




Como se muestra en la gráfica, el modelo en prototipos describe una ejecución en ciclos donde las actividades se repiten una y otra vez, pero resultados diferentes. Sin embargo es necesario que el equipo de trabajo esté atento a no caer en ciclos infinitos y haciendo una y otra vez lo mismo, o buscando la satisfacción del cliente.




Modelo en espiral El modelo en espiral, es un modelo evolutivo que fusiona la naturaleza iterativa del modelo de prototipos con los aspectos lineales, rígidos y de control del modelo en cascada, entregando así bases para desarrollar rápidamente versiones incrementales del producto de software, Pressman (2005). Con este modelo es posible hacer entregas parciales al cliente de forma rápida, sin embargo en cualquier momento se puede salir de control por su naturaleza por su naturaleza evolutiva, donde además, la cantidad de riesgos que pueden aparecer por el mismo fenómeno, es alta y se requiere de mucha experticia por parte del equipo de trabajo, para controlar adecuadamente dichos riesgos en términos de su mitigación y sus planes de acción.




La gráfica describe la estructura del modelo en

espiral, donde seguramente en las

primeras iteraciones la producción se enmarque en la documentación o

prototipos no necesariamente

funcionales, y sólo hasta las últimas iteraciones la producción se enmarcará

en versiones más robustas del producto de software.




Modelo de desarrollo concurrente

Pressman (2005) define:

“El modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, se representa de forma esquemática como una serie de actividades del marco de trabajo, acciones y tareas de la ingeniería del software y sus estados asociados. Por ejemplo, la actividad modelado, definida para el modelo en espiral, se lleva a cabo al invocar las acciones siguientes: construcción de prototipos o modelado y especificación del análisis y el diseño” p. 60




La gráfica muestra un esquema de trabajo para la actividad de modelado, donde éste puede estar en cualquiera de los estados. Los esquemas de trabajo para las demás actividades, donde todas éstas existen de forma concurrente pero en diferentes estados, mientras que al mismo tiempo, se generan interacciones y dependencias entre cada una de las actividades mismas.




MODELOS ESPECIALIZADOS DE PROCESO

Pressman (2005) define:

“Los modelos especializados de proceso adoptan muchas de las características de uno o más modelos convencionales presentados en sesiones anteriores. Sin embargo, los modelos especializados tienden a aplicarse cuando se ha elegido un enfoque de ingeniería del software definido de una manera muy estrecha” p. 63

En este sentido, se han definido algunos modelos con este enfoque como el basado en componentes(1), en métodos formales(2) y en desarrollo de software orientado a aspectos(3). ---

(1) Este modelo incorpora muchas características del modelo en espiral, sin embargo en éste se configura el software a partir de componentes empaquetados de forma previa, Pressman (2005). (2) Este modelo se centra en la aplicación de conceptos y especificaciones matemáticas en cada uno de los procesos de la ingeniería del software, y por ende en la producción de software, Pressman (2005). (3) Este modelo le otorga al software una serie de aspectos y con base en éstos, enfoca las definiciones, las especificaciones, el diseño y la construcción del mismo. Con frecuencia es referenciado como programación orientada a aspectos, Pressman (2005).



AGENDA




Metodologías para la ejecución de proyectos de software

Existe gran número de metodologías para el desarrollo de proyectos de software, pero antes de hablar al respecto, es importante tener claro lo que es una metodología. Según la Real Academia Española, una metodología es un “conjunto de métodos que se siguen en una investigación científica o en una exposición doctrinal” (Diccionario de la Lengua Española, RAE (2011)). Ampliando un poco más el concepto de metodología, se podría decir que ésta hace alusión a procedimientos lógicos que sirven para alcanzar uno o varios objetivos dentro de un trabajo determinado; es decir, las metodologías toman como base un modelo de desarrollo para definir toda su estructura, mientras que éstas se convierten en el elementos de control y administración sobre el proceso de ingeniería de software.



Metodologías para la ejecución de proyectos de software

Ahora bien, en cuanto a metodologías para el desarrollo de proyectos de software, existe gran número de éstas que se han formado, estructurado y consolidando a lo largo de la historia. A continuación se indican cuáles son las principales metodologías, que se describirán más adelante: • Cascada. • RationalUnifedProcess (RUP). • Microsoft Solutions Framework (MSF). • Scrum. • Extreme Programming.



AGENDA




Familias metodológicas

METODOLOGÍAS GRUESAS

Son metodologías complejas y estructuradas, donde la documentación es parte fundamental de sus procesos y la evaluación de cada una de sus fases permite ciertos cambios a nivel de los objetivos conforme las necesidades así lo requieran, y por ende, el seguimiento basado en planes de trabajo cobra relevancia.

Ahora bien, dado que normalmente son adoptadas para proyectos largos y grandes, la aparición de los riesgos es inminente y por ello se hace una tarea compleja.




Desde esta perspectiva, el cliente debe estar en capacidad de describir claramente el problema y entender eficientemente la solución propuesta, pues éste no tiene gran participación en todas las etapas y su interacción con el equipo de trabajo, es principalmente a través de reuniones de seguimiento. Normalmente las definiciones dadas para las metodologías gruesas son provenientes de estándares formales de desarrollo, que hacen de estas, elementos costosos por ejemplo al momento de asumir un cambio en las definiciones del proyecto, pues no existe mucha flexibilidad ante los cambios. En síntesis, con las metodologías gruesas existen muchos artefactos, grupos definidos dentro del equipo de trabajo y por ende un número importante de roles, y un contrato definido desde etapas tempranas del proyecto.




METODOLOGÍAS LIGERAS Son metodologías sencillas y rápidas en su ejecución, donde la documentación no tiene mucha relevancia y la entrega de resultados al cliente, es continua. Se pone mucha atención a la excelencia técnica, donde los planes de trabajo pierden relevancia y por ende el seguimiento también. Teniendo en cuenta que normalmente son adoptadas para proyectos cortos y pequeños, la aparición de los riesgos aunque inevitable, se puede mitigar relativamente fácil dado que se da importancia a la simplicidad y a la eliminación del trabajo innecesario eliminando procesos complejos.




Desde esta perspectiva, el cliente hace parte integral del equipo de trabajo, lo que le brinda cierta flexibilidad en términos de la claridad que debe tener frente a sus necesidades, pues en a medida que el proyecto avanza, y seguramente con la ayuda de los demás integrantes del equipo de trabajo, puede ir dando claridad a sus dudas. Es común que las definiciones dadas para estas metodologías estén basadas en aspectos empíricos y heurísticas provenientes de la producción de artefactos tangibles, lo que las convierte en elementos relativamente económicos y muy flexibles ante los cambios. En síntesis, con las metodologías ágiles existen pocos artefactos, pequeños equipos de trabajo y por ende un número reducido de roles, y un contrato no tradicional que permite flexibilidad en términos de costos, tiempos y compromisos.



AGENDA




Algunas metodologías CASCADA

La metodología en cascada parte de los principios definidos para el modelo de desarrollo de software en cascada, también conocido como ciclo de vida clásico o modelo convencional, donde según Pressman (2005), dicho modelo sugiere un enfoque sistemático y secuencial hacia el desarrollo de software que indica ciertas etapas como se indicó anteriormente.

En este sentido, el modelo mismo se ha constituido en una metodología que ordena rigurosamente todas las etapas del ciclo de vida del software, implicando en sí misma un desarrollo de proyecto rígido y lineal.

Esta es la metodología clásica dentro del contexto del desarrollo de software, que busca producir un software robusto y estrictamente documentado en cada una de sus etapas, donde a la finalización de cada una permite el inicio de la siguiente, tomando como parte del insumo los datos producidos en la anterior.

Así, según Sommerville (2005), las etapas definidas para el modelo se transforman en actividades fundamentales de desarrollo, como se muestra en la siguiente figura.



Algunas metodologías CASCADA

“Análisis y definición de requerimientos. Los servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Entonces se definen en detalle y sirven como una especificación del sistema.

Diseño del sistema y del software. El proceso de diseño del sistema divide los requerimientos en sistemas hardware y software. Establece una arquitectura completa del sistema. El diseño del software identifica y describe las abstracciones fundamentales del sistema software y sus relaciones.

Implementación y prueba de unidades. Durante esta etapa, el diseño del software se lleva a cabo como un conjunto o unidades de programas. La prueba de unidades implica verificar que cada una cumpla con su especificación.

Integración y prueba del sistema. Los programas o las unidades individuales de programas se integran y prueban como un sistema completo para asegurar que se cumplan los requerimientos del software. Después de las pruebas, el sistema software se entrega al cliente.

Funcionamiento y mantenimiento. Por lo general (aunque no necesariamente), ésta es la fase más larga del ciclo de vida. El sistema se instala y se pone en funcionamiento práctico. El mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema y resaltar los servicios del sistema una vez que se descubren nuevos requerimientos.” p. 62



Algunas metodologías RATIONAL UNIFIED PROCESS (RUP)

IBM (2011) define a RUP como:

“IBM Rational Unified Process® (RUP®) is a comprehensive process framework that provides industry-tested practices for software and systems delivery and implementation and for effective project management.”

Además, IBM (2011) plantea que:

“RUP promotes iterative development and organizes the development of software and systems into four phases, each consisting of one or more executable iterations of the software at that stage of development.”

RUP es una metodología que busca la producción de software de alta calidad, cumpliendo con los requisitos de los usuarios dentro de una planificación y presupuesto establecidos que contempla dentro de sus procesos el uso del Unified Modeling Language (UML).




RUP se ejecuta en dos dimensiones, vertical y horizontalmente, pues a medida que los flujos de trabajo del proceso y de soporte, respectivamente, se van ejecutando de forma vertical, también se van ejecutando las respectivas fases de iniciación, elaboración, construcción y transición, de forma horizontal, completando así cuando terminan las respectivas ejecuciones, ciclos que generan entregables internos o externos. Es importante tener en cuenta que dentro de cada una de las ejecuciones de las respectivas fases, es posible que se generen iteraciones internas de acuerdo a las necesidades que el equipo de trabajo pueda tener en un momento dado. Los entregables internos son aquellos que servirán de apoyo a insumo al equipo de trabajo para realizar la ejecución de ciclos posteriores, por ejemplo un documento. Mientras que los entregables externos, son aquellos que se presentan directamente al cliente, por ejemplo un módulo operacionalmente funcional.

Además, RUP involucra los siguientes modelos de desarrollo de software: Modelo en cascada: A medida que las fases y los flujos de trabajo se ejecutan, claramente se evidencia un comportamiento en cascada. Modelo en espiral: Dado que en cada una de las fases se pueden ejecutar varias iteraciones, es posible ver allí un comportamiento en espiral. Modelo de prototipos: Sabiendo que cada ciclo genera un entregable, bien podrían definirse algunos de estos como módulos funcionales que evidencian un comportamiento en prototipos.




La gráfica muestra el

esfuerzo que se debe realizar en cada una de las actividades del proyecto, de

acuerdo a la fase y al flujo de

trabajo que se encuentren en ejecución en un

momento determinado.



Algunas metodologías MICROSOFT SOLUTIONS FRAMEWORK (MSF)

Microsoft (2011) define a MSF como:

“Microsoft® Solutions Framework es un marco de trabajo de referencia para construir e implantar sistemas empresariales distribuidos basados en herramientas y tecnologías de Microsoft. MSF comprende un conjunto de modelos, conceptos y guías que contribuyen a alinear los objetivos de negocio y tecnológicos, reducir los costos de la utilización de nuevas tecnologías, y asegurar el éxito en la implantación de las tecnologías Microsoft. MSF es el resultado de las experiencias de diferentes áreas de Microsoft con proyectos exitosos.”

MSF es una metodología flexible e interrelacionada con una serie de conceptos, modelos y prácticas de uso, que controlan la planificación, el desarrollo y la gestión de proyectos tecnológicos. Además, se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnológicas.



Algunas metodologías MICROSOFT SOLUTIONS FRAMEWORK (MSF)

En la gráfica se pueden apreciar

los hitos que define MSF durante su

ejecución, donde claramente se evidencian las fases bajo las

cuales el equipo de trabajo debe orquestar las

actividades del proyecto.



Algunas metodologías SCRUM

Scrum (2011) define a Scrum como:

“Scrum, que se basa en la teoría del control empírico del procesos, emplea un enfoque iterativo e incremental para optimizar la previsibilidad y controlar los riesgos. Existen tres pilares que sostienen toda implementación del control empírico de procesos.”

Scrum es una metodología de desarrollo muy simple que requiere esfuerzo porque no se basa en el seguimiento de un plan de trabajo, sino en la adaptación continua a las circunstancias de la evolución del proyecto. Siendo consecuentes con lo indicado, en la siguiente gráfica se puede apreciar la simpleza de la ejecución de Scrum, además de los componentes y los roles que la articulan, así como las actividades principales.

Vale la pena destacar que la simpleza que describe Scrum y la necesidad de adaptación constante por parte del equipo de trabajo por la ausencia de un plan de trabajo, pueden generar ciclos infinitos en su ejecución, ocasionando retrasos.




Además, en la esta gráfica es posible apreciar de una

forma más simple los ciclos de

desarrollo que se pueden llegar a

generar en Scrum, donde se evidencian

diferentes esquemas de ejecución, que

seguramente se adoptarán partiendo de las necesidades y de la experticia del equipo de trabajo.



Algunas metodologías XTREME PROGRAMMING (XP)

XP (2011) define a XP como:

“Extreme Programming is successful because it stresses customer satisfaction. Instead of delivering everything you could possibly want on some date far in the future this process delivers the software you need as you need it. Extreme Programming empowers your developers to confidently respond to changing customer requirements, even late in the life cycle.

Extreme Programming emphasizes teamwork. Managers, customers, and developers are all equal partners in a collaborative team. Extreme Programming implements a simple, yet effective environment enabling teams to become highly productive. The team self-organizes around the problem to solve it as efficiently as possible.

Extreme Programming improves a software project in five essential ways; communication, simplicity, feedback, respect, and courage. Extreme Programmers constantly communicate with their customers and fellow programmers.”

XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores y propiciando un buen clima laboral.



Algunas metodologías XTREME PROGRAMMING (XP)

La gráfica describe el proceso ágil sobre el

cual se fundamenta la Metodología XP,

proceso que describe simpleza en su

ejecución y practicidad al momento de abordar

las actividades, sin embargo, se requiere

que el equipo de trabajo tenga un alto

grado de adaptación al cambio, grandes habilidades de

programación y trabajo bajo presión.



AGENDA




Bibliografía

• Blackstone, J., Cox, J. and Schleier, I. (2009). A tutorial on project management from a theory of constraints perspective. International Journal of Production Research, Vol. 47, No. 24, p. 7029.

• Pressman, R. (2005). Ingeniería del software. Un enfoque práctico (6 ed.). México: Mc Graw Hill.

• Real academia española, RAE (2011). Diccionario de la lengua española. Recuperado el 26 de agosto de 2011, de http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=metodolog%EDa

• Sommerville (2005). Ingeniería del Software (7 ed.). Madrid, España: Pearson Educación, S.A.

• IBM (2011). IBM Rational Unified Process, RUP. Recuperado el 31 de agosto de 2011, de http://www-01.ibm.com/software/awdtools/rup/

• Microsoft (2011). Microsoft Solutions Framework, MSF. Recuperado el 31 de agosto de 2011, de http://www.microsoft.com/colombia/portafolio/msf.htm

• Scrum (2011). Scrum. Recuperado el 31 de agosto de 2011, de http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%20ES.pdf#view=fit

• XP (2011). Extreme Programming: A gente introduction. Recuperado el 31 de agosto de 2011, de http://www.extremeprogramming.org/

http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=metodolog%EDa












http://www-01.ibm.com/software/awdtools/rup/










http://www.microsoft.com/colombia/portafolio/msf.htm










http://www.scrum.org/storage/scrumguides/Scrum Guide - ES.pdf


















http://www.extremeprogramming.org/










Gracias

¿…?

ingeniería & metodologías

Documents