Metodologías para desarrollo de software

Instituto Privado Tecnológico Spencer W. Kimball

Bachiller Industrial y Perito en Computación

Quinto Grado

Curso: Análisis de Sistemas.

Cat: Álvaro Martínez

Tema: Metodologías para el desarrollo de software

Nombre: Delvin Estuardo Félix Torres

Sección: Única

Clave: 4

Carnet: 21CP

Fecha: 20/05/2015

Introducción.

En el siguiente trabajo veremos la utilidad de las metodologías las cuales se

basan en una combinación de los modelos de proceso genéricos (cascada,

evolutivo, incremental, espiral entre otros).los cuales no son de mucha utilidad

para la precisión los artefactos, roles y actividades involucrados en el desarrollo

de software.

Contenido METODOLOGÍAS PARA DESARROLLO DE SOFTWARE ...........................................1

Ciclo de vida del software ..............................................................................................6

Modelos de ciclo de vida ...................................................................................................7

Modelo en cascada ......................................................................................................7

Modelo V ....................................................................................................................... 8

METODOLOGÍA RUP ...................................................................................................... 9

Fases de desarrollo del software…………………………………………………………9

TIPOS………………………………………………………………………………………….10

http://modeloespiral.blogspot.com/2009/08/tipos.html

INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ

1 DELVIN ESTUARDO FELIX TORRES

METODOLOGÍAS PARA DESARROLLO DE SOFTWARE

Un proceso de software detallado y completo suele denominarse “Metodología”. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, espiral entre otros).

Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas,

guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o

algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño.

La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, información disponible y alcance de cada una de ellas. A grandes rasgos, si

tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de análisis y diseño, podemos clasificar las

metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del

proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales (o también denominadas

Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños,

hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso.

A continuación se revisan brevemente cada una de estas categorías de metodologías: METODOLOGÍAS ESTRUCTURADAS

Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación Estructurada, luego a mediados de los 70’s aparecieron

técnicas para el Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente apropiadas en proyectos que utilizan

para la implementación lenguajes de 3ra y 4ta generación. Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE

(Francia), MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito académico: Gane & Sarson, Ward & Mellor, Yourdon & Demarco e Information Engineering.

METODOLOGÍAS ORIENTADAS A OBJETOS Su historia va unida a la evolución de los lenguajes de programación orientada

a objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y



actualmente Java o C# de Microsoft. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto.

En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una unificación de sus métodos y notaciones, que

posteriormente se reorienta a un objetivo más modesto, para dar lugar al Unified Modeling Language (UML), la notación Orientada a Objetos más popular en la actualidad.

Algunas metodologías orientadas a objetos que utilizan la notación UML son:

Rational Unified Process (RUP),

OPEN,

MÉTRICA (que también soporta la notación estructurada).

METODOLOGÍAS TRADICIONALES Las metodologías no ágiles son aquellas que están guiadas por una fuerte

planificación durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción del sistema.

Todas las propuestas metodológicas antes indicadas pueden considerarse como metodologías tradicionales. Aunque en el caso particular de RUP, por el

especial énfasis que presenta en cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse), realizando una configuración adecuada, podría considerarse Ágil.

METODOLOGÍAS ÁGILES Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de software, con ciclos rápidos), cooperativo (cliente y

desarrolladores trabajan juntos constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de aprender y

modificar, bien documentado), y adaptable (permite realizar cambios de último momento). Entre las metodologías ágiles identificadas son:

Extreme Programming

Scrum

Familia de Metodologías Crystal

Feature Driven Development

Proceso Unificado Rational, una configuración ágil

Dynamic Systems Development Method

Adaptive Software Development

Open Source Software Development

SEGUIDAMENTE DETALLAREMOS LAS SIGUIENTES METODOLOGÍAS PARA DESARROLLO DE SOFTWARE:

Rational Unified Process (RUP)

Extreme Programming (XP)



SCRUM

Como se explicó en el concepto anterior, un modelo para el desarrollo de

software es una representación abstracta de un proceso. Cada modelo representa un proceso desde una perspectiva particular y así proporcione

información parcial sobre el proceso. Éstos modelos generales no son descripciones definitivas de los procesos del software más bien son

abstracciones de los procesos que se pueden utilizar para el desarrollo del software. Puede pensarse en ellos como marcos de trabajo del proceso y que pueden ser adaptados para crear procesos más específicos. Los modelos que

mencionaremos en este punto son: 1) El modelo en cascada. Considera las actividades fundamentales del proceso

especificación, desarrollo, validación y evolución. Los representa como fases separadas del proceso, tales como la especificación de requerimientos, el diseño del software, la implementación, las pruebas, etcétera.

2) El modelo de desarrollo evolutivo (espiral). Este enfoque entrelaza las

actividades especificación, desarrollo y validación. Es decir surge de un sistema inicial que se desarrolla rápidamente a partir de especificaciones abstractas. Basándose en las peticiones del cliente para producir un sistema

que satisfaga sus necesidades.

3) El modelo de desarrollo basado en componentes. Éste enfoque se basa en la existencia de un número significativo de componentes reutilizables. El proceso de desarrollo se enfoca en integrar estos componentes en el sistema

más que en desarrollarlos desde cero. Estos tres modelos se utilizan ampliamente en la práctica actual de la ingeniería del software, no se excluyen

mutuamente y a menudo se utilizan juntos especialmente para el desarrollo de grandes sistemas.



A. El modelo en cascada Según Royce (1970), el modelo de cascada se derivó de procesos de sistemas

más generales. Éste modelo se muestra en la figura 2.22 y sus principales etapas se transforman en actividades fundamentales del desarrollo:

1) 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 de manera específica al sistema.

2) Diseño del sistema y del software. El proceso de diseño del sistema divide

los requerimientos en sistemas ya sea hardware Soto. Establece una arquitectura completa del sistema, el diseño del software identifique describe los elementos abstractos que son fundamentales para el software y sus

relaciones.

3) Implementaciones prueba de unidades. Durante esta etapa el diseño del software se lleva a cabo como un conjunto de unidades de programas, la prueba de unidades implica verificar que cada una cumpla con su función

específica.

4) Integración y prueba del sistema. Los programas o las unidades individuales de programas se integran y se prueban como un sistema completo para así asegurar que se cumplan los requerimientos del software, después se entrega

al cliente. 5) Funcionamiento y mantenimiento. En esta fase 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 en nuevos requerimientos.

B. El modelo de desarrollo evolutivo (espiral)

El modelo en espiral que Boehm propuso es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos del modelo en cascada. Cuando se

aplica este modelo en espiral, el software se desarrolla en una serie de entregas evolutivas. Cada una de las actividades del marco de trabajo

representa un segmento de la ruta en espiral. Este modelo se basa en la idea de desarrollar una implementación inicial,

exponiéndola a los comentarios del usuario y refinándola a través de las diferentes versiones que se generan hasta que se desarrolle un sistema

adecuado.

Las actividades de especificación, desarrollo y validación se entrelazan en vez de separarse, con una rápida retroalimentación entre estas. Existen dos tipos de desarrollo evolutivo:

1) Desarrollo exploratorio, en este caso el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El



desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.

2) Prototipos desechables, el objetivo de este proceso de desarrollo evolutivo

es comprender los requerimientos del cliente para así desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar los requerimientos del cliente que no se comprenden del todo.

Haciendo referencia a la producción del software, un enfoque evolutivo suele

ser más efectivo que el enfoque en cascada, ya que satisface las necesidades inmediatas de los clientes. La ventaja de un software que se basa en un

enfoque evolutivo es que las especificaciones se pueden desarrollar de forma creciente. Tan pronto como los usuarios desarrollen un mejor entendimiento de su problema, esto se puede reflejar en el software. Sin embargo, desde la

perspectiva de ingeniería y de gestión, el enfoque evolutivo tiene dos problemas:

1) El proceso no es visible. Esto significa que los administradores tienen que hacer entregas regulares para medir el progreso del producto. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen

cada versión del sistema.

2) A menudo los sistemas tienen una estructura deficiente. Esto hace referencia que los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en una tarea

difícil y costosa.

Para sistemas pequeños y de tamaño medio (hasta 500,000 líneas de código), el enfoque evolutivo de desarrollo es el mejor. Los problemas del desarrollo

evolutivo se hacen particularmente agudos para sistemas grandes y complejos con un período de vida largo, donde diferentes equipos desarrollan distintas partes del sistema. Es difícil establecer una arquitectura del sistema usando

este enfoque, ya que hace difícil integrar las contribuciones de los equipos. Para sistemas grandes se recomienda un proceso mixto es decir que incorpore

las mejores características del modelo en cascada y del desarrollo evolutivo. Esto implica desarrollar un prototipo desechable, utilizando un enfoque evolutivo para resolver incertidumbres en la especificación del sistema. Puede

entonces no implementarse utilizando un enfoque más estructurado.

C. El modelo de desarrollo basado en componentes En la mayoría de los proyectos de desarrollo de software existe la reutilización.

Por lo general esto sucede informalmente cuando las personas conocen diseños o códigos similares al requerido. Los buscan, los modifican según lo creen necesario y los incorporan en un nuevo sistema. El enfoque evolutivo, la

reutilización es indispensable para el desarrollo más ágil de un sistema. Esta reutilización es independiente del proceso de desarrollo que se utilice. Sin

embargo, en los últimos años ha surgido un enfoque de desarrollo de software denominado " ingeniería de software basada en componentes", el cual se basa



en la reutilización. Este enfoque se basa en la reutilización y se compone de una gran base de componentes de software que son reutilizables.

Aunque la etapa de especificación de requerimientos y la revalidación son

comparables con otros procesos, las etapas intermedias en el proceso orientado a la reutilización son diferentes. Estas etapas son:

1) Análisis de componentes. En esta se buscan los componentes para implementar los con base en su especificación. Por lo general, no existe una concordancia exacta y los componentes que se utilizan sólo proporcionan parte

de la funcionalidad requerida.

2) Modificación de requerimientos. En esta etapa los requerimientos se analizan utilizando información acerca de los componentes que se han descubierto. Entonces dichos componentes se modifican para reflejar los

componentes disponibles, la actividad de análisis de componentes se puede llevar a cabo para buscar soluciones alternativas.

3) Diseño del sistema con reutilización. En esta fase los diseñadores tienen en cuenta los componentes que se reutiliza y que se organizan el marco de trabajo

para que los satisfaga. Si dichos componentes no están disponibles se puede diseñar nuevos software.

4) Desarrollo e integración. El software que no se puede adquirir externamente se desarrolla y se integra a los componentes. En este modelo, la integración

del sistema es parte del proceso de desarrollo, más que una actividad separada.

El modelo de desarrollo de software basado en componentes creado por

Boehm (1988), tiene la ventaja de reducir la cantidad de software que se debe desarrollar y por ende reduce los costos y los riesgos. También permite una entrega más rápida del software. Sin embargo, los compromisos a los

requerimientos son inevitables y esto da lugar a un sistema que no cumpla con las necesidades reales de los usuarios. Pressman (2006), detecto que:

“El software de computadoras moderno se caracteriza por el cambio con tiempos de entrega son muy reducidos y una necesidad intensa de satisfacer al cliente/usuario. En muchos casos, el tiempo de llegada al mercado es el

requisito de gestión más importante. Si se pierde una ventana del mercado, el mismo proyecto de software puede perder su significado”.

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, es decir, para

garantizar que el software cumpla los requisitos para la aplicación y verificación de los

procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.



Estos programas se originan en el hecho de que es muy costoso rectificar los errores que

se detectan tarde dentro de la fase de implementación. El ciclo de vida permite que los

errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores

concentrarse en la calidad del software, en los plazos de implementación y en los costos

asociados.

El ciclo de vida básico de un software consta de los siguientes procedimientos:

Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia

global.

Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los

requisitos del cliente y examinar cualquier restricción que se pueda aplicar.

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 (mantenimiento correctivo) y

las actualizaciones secundarias del software (mantenimiento continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una

aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el

equipo de desarrolladores.

Modelos de ciclo de vida

Para facilitar una metodología común entre el cliente y la compañía de software, los

modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo

involucradas y la documentación requerida, de manera que cada etapa se valide antes de

continuar con la siguiente etapa. Al final de cada etapa se arreglan las revisiones de

manera que (texto faltante).

Modelo en cascada

Se define como una secuencia de fases en la que al final de cada una de ellas se reúne la

documentación para garantizar que cumple las especificaciones y los requisitos antes de

pasar a la fase siguiente: En Ingeniería de software el desarrollo en cascada, también



llamado modelo en cascada (denominado así por la posición de las fases en el desarrollo de

esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), es el enfoque

metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software,

de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior Al

final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se

encarga de determinar si el proyecto está listo para avanzar a la siguiente fase. Este modelo

fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida.

Modelo V

El modelo de ciclo de vida V proviene del principio que establece que los

procedimientos utilizados para probar si la aplicación cumple las

especificaciones ya deben haberse creado en la fase de diseño.



METODOLOGÍA RUP

El Proceso Unificado Racional, Rational Unified Process en inglés, y sus siglas

RUP, es un proceso de desarrollo de software 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. El RUP no es un sistema con pasos firmemente establecidos, sino que

trata de un conjunto de metodologías adaptables al contexto y necesidades de

cada organización, donde el software es organizado como una colección de

unidades atómicas llamados objetos, constituidos por datos y funciones, que

interactúan entre sí.

RUP es un proceso para el desarrollo de un proyecto de un software que define

claramente quien, cómo, cuándo y qué debe hacerse en el proyecto

RUP como proceso de desarrollo

• RUP es explícito en la definición de software y su trazabilidad, es decir,

contempla en relación causal de los programas creados desde los

requerimientos hasta la implementación y pruebas.

• RUP identifica claramente a los profesionales (actores) involucrados en el

desarrollo del software y sus responsabilidades en cada una de las actividades.



Fases de desarrollo del software

· Inicio

· Elaboración

· Construcción

· Transición

El MODELO en espiral, propuesto originalmente por BOEHM en 1976, es un

modelo de proceso de software evolutivo donde se conjuga la naturaleza de

construcción de prototipos con los aspectos controlados y sistemáticos del

MODELO LINEAL y SECUENCIAL. Proporciona el potencial para el desarrollo

rápido de versiones incrementales del software que no se basa en fases

claramente definidas y separadas para crear un sistema.

En el modelo espiral, el software se desarrolla en una serie de versiones

incrementales. Durante las primeras iteraciones la versión incremental podría

ser un modelo en papel o un prototipo, durante las últimas iteraciones se

producen versiones cada vez más completas del sistema diseñado.

EL modelo en espiral se divide en un número de actividades de marco de

trabajo, también llamadas REGIONES DE TAREAS , Cada una de las regiones

están compuestas por un conjunto de tareas del trabajo llamado CONJUNTO

DE TAREAS que se adaptan a las características del proyecto que va a

emprenderse en todos los casos se aplican actividades de protección.

http://1.bp.blogspot.com/_blCQnhNGnao/SnRynLCa9ZI/AAAAAAAAAAM/8bWpBVfKPGQ/s1600-h/1.png





TIPOS

El modelo espiral tuvo varias modificaciones que son:

Modelo Original de Boehm.

Modelo Típico de Seis Regiones.

Modelo WINWIN.

Publicado por Grupo Espiral Php en 9:27 No hay comentarios:

MODELO ORIGINAL DE BOEHM

No hay un número definido de iteraciones. Las iteraciones debe decidirlas el

equipo de gestión de proyecto

Cada vuelta se divide en 4 sectores:

Planeación: determinación de los objetivos, alternativas y restricciones

Análisis de riesgo: análisis de alternativas e identificación/resolución de

riesgos

Ingeniería: desarrollo del producto hasta "el siguiente nivel".

Evaluación: valoración por parte del cliente de los resultados obtenidos.

El movimiento de la espiral, ampliando con cada iteración su amplitud radial,

indica que cada vez se van construyendo versiones sucesivas del software,

cada vez más completas.

Uno de los puntos más interesantes del modelo, es la introducción al proceso

de desarrollo a las actividades de análisis de los riesgos asociados al desarrollo

y a la evaluación por parte del cliente de los resultados del software.

El modelo de la cascada es uno de los primeros modelos empleados en el

desarrollo de software, se popularizo en 1970 por Winston Royce y aún está


http://www.blogger.com/profile/18229484001697642528


http://modeloespiral.blogspot.com/2009/08/tipos.html#comment-form

http://modeloespiral.blogspot.com/2009/08/modelo-original-de-boehm.html



vigente en algunos desarrollos. Éste modelo se define como una secuencia de

actividades a ser seguidas en orden, donde la estrategia principal es definir

y seguir el progreso del desarrollo de software hacia puntos de revisión bien

definidos, es decir, se codifica y reparan los errores; es un proceso continuo de

codificación y reparación. Sus características principales son:

-Es lineal

-Las actividades están relacionadas secuencialmente

-Cada etapa tiene una entrada y una salida

-Es rígido y sistemático: La entrada de una actividad es la salida de la etapa -

anterior, por lo cual no se puede dar inicio a la siguiente fase.

-Es monolítico: Existe una única fecha de entrega.

-La implementación se pospone hasta que no se comprendan los objetivos.

-Los documentos a entregar rigen el proceso de software

INSTITUTO TECNOLOGICO SPENCER W.KIMBALL PROFESOR: ALVARO MARTINEZ

DELVIN ESTUARDO FELIX TORRES

Conclusión.

El desarrollo del software y la programación es uno de los pilares fundamentales de la

informática y al cual se dedican muchas horas de esfuerzos en empresas, colegios,

academias y universidades.

Conforme a la tecnología va avanzando, van apareciendo nuevas soluciones, nuevas

formas de programación, nuevos lenguajes y un sin fin de herramientas que intentan

realizar el trabajo del desarrollador un poco más fácil.



Recomendación.

Lo único que puedo recomendar es que se nos sigan implementando nuevas técnicas de

aprendizaje ya bien darnos a conocer más sobre estos temas ya que para nosotros como

estudiantes de la carrera de computación se nos tienen que dar a conocer estos

conocimientos para aplicarlos en el campo de estudio o en la vida diaria para salir adelante

sabiendo cómo hay que realizar cualquier tipo de problema que se nos presenta en cuanto a

computación.



E- GRAFIAS.

http://www.academia.edu/6362716/METODO_EN_CASCADA

http://modeloespiral.blogspot.com/

http://ingenieriadesoftwarerigo.blogspot.com/2012/09/software-libre-para-generar-uml-

y.html

http://es.kioskea.net/contents/223-ciclo-de-vida-del-software

http://procesosdesoftware.wikispaces.com/METODOLOGIAS+PARA+DESARROLLO+DE+SOFTW

ARE

http://www.eumed.net/tesis-doctorales/2014/jlcv/software.htm

http://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software

http://www.academia.edu/6362716/METODO_EN_CASCADA

http://modeloespiral.blogspot.com/

http://ingenieriadesoftwarerigo.blogspot.com/2012/09/software-libre-para-generar-uml-y.html

http://ingenieriadesoftwarerigo.blogspot.com/2012/09/software-libre-para-generar-uml-y.html

http://es.kioskea.net/contents/223-ciclo-de-vida-del-software

http://procesosdesoftware.wikispaces.com/METODOLOGIAS+PARA+DESARROLLO+DE+SOFTWARE

http://procesosdesoftware.wikispaces.com/METODOLOGIAS+PARA+DESARROLLO+DE+SOFTWARE

http://www.eumed.net/tesis-doctorales/2014/jlcv/software.htm

http://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software

Metodologías para desarrollo de software

Education

Transcript of Metodologías para desarrollo de software