MAESTRÍA EN TECNOLOGÍAS DE LA INFORMACIÓN Y

LA COMUNICACIÓN

METODOLOGÍAS DE DESARROLLO DE SOFTWARE

ALUMNO:

MATERIA: ANÁLISIS Y DISEÑO DE SISTEMAS

DOCENTE:

ENERO 2016

Metodologías de desarrollo de software

Asimismo le permite en cualquier momento realinear el software con los objetivos de negocio de su empresa. obteniendo como resultado una versión del software con nuevas prestaciones listas para ser usadas. auto-gestión e innovación. En cada nuevo Sprint. por lo que los profesionales encuentran un ámbito propicio para desarrollar sus capacidades. Cada iteración. Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspección continua. cuyo principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). tiene una duración preestablecida de entre 2 y 4 semanas. denominada Sprint. adaptación. . Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve crecer iteración a iteración. Esta metódica de trabajo promueve la innovación. ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteración sin ningún problema. motivación y compromiso del equipo que forma parte del proyecto. se va ajustando la funcionalidad ya construida y se añaden nuevas prestaciones priorizándose siempre aquellas que aporten mayor valor de negocio. El proceso El desarrollo se realiza de forma iterativa e incremental.Metodología Scrum Scrum es una metodología ágil y flexible para gestionar el desarrollo de software.

qué no y en qué orden) y en vencer cualquier obstáculo que pudiera entorpecer la tarea del equipo de desarrollo. por retorno de inversión considerando su beneficio y coste. Se focaliza en la parte de negocio y él es responsable . para en una segunda parte de la reunión. Sprint Planning: Reunión durante la cual el Product Owner presenta las historias del backlog por orden de prioridad. Demo y retrospectiva: Reunión que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas mediante una demonstración del producto. En la que el equipo se sincroniza para trabajar de forma coordinada. el equipo se focaliza en construir software de calidad. decidir y organizar cómo lo va a conseguir. El equipo determina la cantidad de historias que puede comprometerse a completar en ese sprint. en una nueva versión del software totalmente operativo. Cada miembro comenta que hizo el día anterior. Roles En Scrum. en la retrospectiva. El equipo Scrum está formado por los siguientes roles: Scrum master: Persona que lidera al equipo guiándolo para que cumpla las reglas y procesos de la metodología. Daily sprint meeting: Reunión diaria de cómo máximo 15 min. el equipo analiza qué se hizo bien. que hará hoy y si hay impedimentos. La gestión de un proyecto Scrum se centra en definir cuáles son las características que debe tener el producto a construir (qué construir. qué procesos serían mejorables y discute acerca de cómo perfeccionarlos. Posteriormente. Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del sprint. o lo que es lo mismo.Product Backlog: Conjunto de requisitos demoninados historias descritos en un lenguaje no técnico y priorizados por valor de negocio. Gestiona la reducción de impedimentos del proyecto y trabaja con el Product Owner para maximizar el ROI. Sprint: Iteración de duración prefijada durante la cual el equipo trabaja para convertir las historias del Product Backlog a las que se ha comprometido. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares. Product owner (PO): Representante de lso accionistas y clientes que usan el software.

formaliza las prestaciones en historias a incorporar en el Product Backlog y las reprioriza de forma regular. los ingenieros deben sentirse personalmente comprometidos con la calidad de sus productos. Con PSP los ingenieros de software pueden adquirir las habilidades necesarias para trabajar en un proceso de software en equipo TSP. • Para desarrollar productos de calidad. 95] • Cada ingeniero es esencialmente diferente. Team: Grupo de profesionales con los conocimientos técnicos necesarios y que desarrollan el proyecto de manera conjunta llevando a cabo las historias a las que se comprometen al inicio de cada sprint. • La manera correcta de hacer las cosas es siempre la manera más rápida y más barata de hacer un trabajo. los ingenieros deben planear su trabajo y basar sus planes en sus propios datos personales. para ser más precisos. es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la productividad personal de los programadores o ingenieros de software. . Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. • Para mejorar constantemente su funcionamiento. mediante el seguimiento del desempeño predicho frente al desempeño real. los ingenieros deben utilizar personalmente procesos bien definidos y medidos. A partir de 1997 con el lanzamiento del libro "An introduction to the Personal Software Process" se dirige ahora a ingenieros juniors. Metodología PSP El proceso personal de software. • Cuesta menos encontrar y arreglar errores en la etapa inicial del proyecto que encontrarlos en las etapas subsecuentes. en tareas de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para emplearse en organizaciones con modelos de procesos CMMI o ISO 15504. • Es más eficiente prevenir defectos que encontrarlos y arreglarlos. Traslada la visión del proyecto al equipo.del ROI del proyecto (entregar un valor superior al dinero invertido). PSP. Principios de psp El diseño de PSP se basa en los siguientes principios de planeación y de calidad [HUMPHREY.

Cada nivel tiene guiones detallados. motiva a los ingenieros experimentados a personalizarlos para que puedan aumentar el entendimiento de sus fortalezas y debilidades. Humphrey. "Evolución del proceso personal de software".Niveles El entrenamiento de PSP sigue una metodología evolutiva de mejora: quien empieza a integrar PSP en su proceso comienza en el nivel PSP0 y progresa hasta alcanzar el nivel PSP2.1 que es el nivel máximo de madurez. 97] de . creador de la metodología. [HUMPHREY. Proceso La entrada de PSP son los requerimientos. el documento requerimientos es completado y entregado al ingeniero. listas de chequeo y plantillas.

PSP2. codificación. En un post mortem el ingeniero asegura que todos los datos del proyecto hayan sido registrados y analizados correctamente.1 : . Se enfoca en la prevención de defectos y su remoción. PSP2. PSP 0.1 (Introduce la disciplina y la medición al proceso) PSP0 tiene 3 fases: planeación. Esta información es usada para tareas de agendamiento.  Registro de tiempos. PSP0.  Registro de defectos. En el PIP el ingeniero registra ideas para mejorar su propio proceso. PSP1. el ingeniero estima el tamaño que tendrá el nuevo programa y prepara un reporte de pruebas (PSP1).1.1 (Introduce manejo de calidad y diseño) PSP2 agrega dos fases nuevas: revisión de diseño y de código.PSP0. Los ingenieros aprenden a evaluar y mejorar su proceso midiendo la extensión de sus tareas y la cantidad de defectos inyectados y removidos en cada fase de desarrollo. fallos inyectados/removidos. PSP0. desarrollo (diseño.1). Los datos recolectados para proyectos previos se usan para estimar el tiempo total.) Los niveles son:   PSP 0:  Proceso actual.1 (Introduce estimación y planeación) Teniendo como base los datos recolectados en PSP0 y PSP0. Se establece una base del proceso normal de medición: tiempo tomado programando. PSP2. (PSP3 es un legado de PSP que ha sido sustituido por TSP.1 agrega un estándar de código. planeación y estimación (PSP1. Cada proyecto nuevo registrará el tiempo gastado actualmente. pruebas) y un post mortem. una medida de tamaño y el desarrollo de un plan de mejora personal PIP.1 introduce especificaciones de diseño y técnicas de análisis. tamaño de un programa. Los ingenieros construyen y usan listas de chequeo para diseño y revisión de código. PSP1.

PSP 2. para traducir datos en información útil para mejorar la estimación. defectos. y desviación estándar.1:   Plantillas de Diseño. PSP 2 . y tamaños es fundamental para planear y realizar seguimientos a los proyectos de PSP. tales como correlación. Planeación y seguimiento El registro de tiempos. (TSP).  Reporte de pruebas.Repetible:   Revisión de diseño y código. planeación y calidad.  PSP 1 .  Medición de tamaño. .1:   Calendario de planeación de tareas. Para hacer el seguimiento del proyecto PSP usa el método del valor ganado (EV).Inicial:  Estimación de tamaño. PSP usa el método PROBE para mejorar las habilidades de estimación de los desarrolladores para obtener más planeaciones más precisas. Estándares de código. Las fórmulas estadísticas son calculadas por las herramientas para PSP. regresión lineal. PSP también usa técnicas estadísticas. los datos históricos son usados para mejorar la precisión estimación.  PSP 1.

.

Establece una arquitectura completa del sistema. Con esta información se produce el documento de “Especificación del Sistema”.  Diseño del sistema y del software. presenta una visión muy clara de cómo se suceden las etapas durante el desarrollo. 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. El proceso de diseño del sistema divide los requerimientos en software o hardware. Se definen los servicios. el sistema de software se entrega al cliente. El diseño de software identifica y describe las abstracciones fundamentales del sistema software y sus relaciones.  Integración y validación del sistema. El sistema se instala y se pone en funcionamiento práctico. La prueba de unidades implica verificar que cada una cumpla su especificación. Después de las pruebas.  Implementación y validación de unidades. El mantenimiento implica corregir errores no descubiertos en las . Durante esta etapa.Modelo en cascada.  Funcionamiento y mantenimiento. También conocido como ciclo de vida del software. y sugiere a los desarrolladores cuál es la secuencia de eventos que podrán encontrar. El modelo en cascada. Por lo general (aunque no necesariamente). el diseño del software se lleva a cabo como un conjunto de unidades de programas. que son las actividades fundamentales en cualquier desarrollo de software:  Análisis y definición de requerimientos. metas y restricciones del sistema a partir de consultas con los clientes y usuarios. ésta es la fase más larga del ciclo de vida. Consta de 5 etapas.

2005) El resultado de cada fase es uno o más documentos aprobados (firmados). Según [Pfleeger. Curtis. Se deben hacer compromisos en las etapas iniciales. Modelo en cascada (Sommerville. lo que hace difícil responder a los cambios en los requerimientos del cliente. Por lo tanto. Shen e Iscoe (1987) hacen notar que la limitación principal del modelo en cascada reside en que no trata al software como un proceso de resolución de problemas. el modelo en cascada solo se debe utilizar cuando los requerimientos se comprenden bien y sea improbable que cambien radicalmente durante el desarrollo del sistema. estas etapas se superponen y proporcionan información a las otras. durante el diseño de código se encuentran problemas y así sucesivamente. Durante el diseño se identifican problemas con los requerimientos. Krasner. 2005]. La siguiente fase no debe empezar hasta que la fase previa haya finalizado. Pero la manufactura produce un artículo en particular y lo reproduce muchas veces. El principal problema de este modelo es su inflexibilidad al dividir el proyecto en distintas etapas. El . En la práctica. El modelo en cascada deriva del mundo del hardware y presenta una visión de manufactura sobre el desarrollo del software.etapas anteriores del ciclo de vida y mejorar la implantación de las unidades del sistema. Sin embargo este modelo este modelo es muy importante porque define las etapas que se siguen en los procesos de software.

en cambio. Aunque es posible hacer prototipos como un modelo de proceso aislado. es más común usarlo como una técnica que puede implementarse en el contexto de cualquiera de los modelos de proceso descritos en este capítulo. los plazos apretados del mercado hacen que sea imposible la terminación de un software perfecto. Así el software es un proceso de creación. Prototipado evolutivo El prototipo debe convertirse. establecer una solución satisfactoria del problema en cuestión. como todos los sistemas complejos. Es frecuente que los requerimientos del negocio y del producto cambien conforme avanza el desarrollo. En estas situaciones y otras parecidas se necesita un modelo de proceso diseñado explícitamente para adaptarse a un producto que evoluciona con el tiempo. el paradigma de hacer prototipos le ayudará a usted y a otros participantes a mejorar la comprensión de lo que hay que elaborar cuando los requerimientos no están claros. evoluciona a medida que el problema se comprende y se evalúan las alternativas. en el sistema final usado (alternativa al ciclo de vida). aprender a partir de los errores. evoluciona en el tiempo. se comprende bien el conjunto de requerimientos o el producto básico. La creación implica intentar un poco de esto y de aquello.software no se desarrolla de la misma manera. como desarrollar y evaluar prototipos. Sin importar la manera en la que se aplique. eventualmente. valorar la factibilidad de los requerimientos. no de fabricación. Se caracterizan por la manera en la que permiten desarrollar versiones cada vez más completas del software. eventualmente. pero los detalles del producto o extensiones del sistema aún están por definirse. comparar varios diseños. El software. pero debe lanzarse una versión limitada a fin de aliviar la presión de la competencia o del negocio. Los modelos evolutivos son iterativos. . lo que hace que no sea realista trazar una trayectoria rectilínea hacia el producto final.

pueden utilizarse fragmentos de programas existentes o aplicar herramientas (por ejemplo. El diseño rápido lleva a la construcción de un prototipo. Éste se entrega y es evaluado por los participantes. Usted se reúne con otros participantes para definir los objetivos generales del software. La iteración ocurre a medida de que el prototipo es afinado para satisfacer las necesidades de distintos participantes. Si va a construirse un prototipo.El paradigma de hacer prototipos comienza con comunicación. . y al mismo tiempo le permite a usted entender mejor lo que se necesita hacer. El ideal es que el prototipo sirva como mecanismo para identificar los requerimientos del software. Paradigma de hacer prototipos. Se planea rápidamente una iteración para hacer el prototipo. y se lleva a cabo el modelado (en forma de un “diseño rápido”). generadores de reportes y administradores de ventanas) que permitan generar rápidamente programas que funcionen. disposición de la interfaz humana o formatos de la pantalla de salida). que dan retroalimentación para mejorar los requerimientos. Éste se centra en la representación de aquellos aspectos del software que serán visibles para los usuarios finales (por ejemplo. identifica cualesquiera requerimientos que conozca y detecta las áreas en las que es imprescindible una mayor definición.

Metodología SOFTENG Agile Con el objetivo de minimizar riesgos. modelo conceptual y lógico de la BD. timing y costes. Trabajamos para comprender el valor que quiere obtener y/o proporcionar a sus clientes. y definición de procesos. plantear la estrategia más adecuada para el desarrollo del mismo. Etapas:  Análisis funcional: Definición de los objetivos a alcanzar.  Análisis tecnológico: Selección de la tecnología a aplicar. Diseño y arquitectura Consiste en clarificar los objetivos del proyecto. por lo que su ejecución se realiza según los plazos y costos previstos. arquitectura. conseguimos alinear a todos los partícipes del proyecto hacia un objetivo común y claramente definido. diagrama de objetos. SOFTENG utiliza un probado marco metodológico orientado a procesos.  Maqueta: Definición de la línea gráfica de interfaz. Las fases son las siguientes: Estudio estratégico Se establece las bases y el alcance del proyecto. gestionar cambios de forma eficaz. y ofrecer un servicio de calidad que cumpla con las expectativas de nuestros clientes. así como los recursos necesarios. Mediante el mismo. y descripción modular detallada de los requerimientos del proyecto. y le ayudamos a descubrir nuevas oportunidades para incrementarlo. . así como describir la funcionalidad a implementar definiendo su alcance.

 Instalación del software: Se instalará y configurará el software y. Producción Consiste en el desarrollo del proyecto organizado en hitos y entregables y así facilitar a los clientes la posibilidad de revisar la aplicación a medida que se va construyendo. los requerimientos necesarios en servidor para el funcionamiento correcto de la aplicación. Diseño de interfaz. se lleva a cabo la fase de despliegue y puesta en marcha. . simulando conexiones de usuarios que la usan). el software finalizado se entrega al equipo interno de calidad para un profundo testeo.  Migración de datos: En caso necesario. se migrará la información desde el antiguo gestor de base de datos de la organización al nuevo servidor. en general. De esta forma. asignación de recursos y definición de entregables. Puesta en marcha Finalizado el control de calidad y con la aceptación del cliente. se realizará la instalación del servidor o clúster de servidores. creación de la Base de datos. tanto funcional (comparándolo con la documentación de requerimientos). Planificación: Plan detallado del proyecto. que a su vez se divide en cinco etapas cuyo orden y ámbito dependerá del proyecto en cuestión:  Instalación del hardware: En caso de que sea necesario. Control de calidad Una vez la aplicación ha sido desarrollada y testeada con éxito. Etapas: Prototipo. como técnico (especialmente de carga y stress. Implementación. Se trata de un proceso que se lleva a cabo mediante ciclos iterativos hasta que el cliente nos da su conformidad. Integración y pruebastesteo.  Instalación de la aplicación: Migración desde el servidor de pruebas al servidor definitivo. pasará por una etapa final de control de calidad previa a la aceptación del cliente.

Durante este periodo se pueden analizar ampliaciones funcionales que aporten más valor añadido al proyecto. Estas actividades las lleva a cabo el jefe de proyecto asignado. y consiste en todas la actividades de gestión necesarias para llevar a buen término el proyecto y lograr los objetivos marcados. Gestión del proyecto Esta fase se realiza en paralelo junto a las demás. Al finalizar la garantía. . entregables y calidad.  Fase de cierre. y consisten principalmente en el control y coordinación de recursos. y entra en vigor la garantía. tiempos. Formación: El responsable del proyecto prepara la documentación necesaria. entrará en vigor el periodo de soporte y mejora continua. y se encarga de formar a los futuros usuarios para el uso de la aplicación o para la gestión de contenidos en el caso de proyectos Web. o nuevas oportunidades de negocio que desemboquen en futuras colaboraciones. inicio de la mejora continua y soporte: Se da por finalizado el proyecto al haberse alcanzado los objetivos consensuados con el cliente. costes. planificación.

los programadores realizan una estimación del esfuerzo necesario de cada una de ellas. y correspondientemente. Fase II: Planificación de la Entrega En esta fase el cliente establece la prioridad de cada historia de usuario. tecnologías y prácticas que se utilizarán en el proyecto. El programador estima el esfuerzo necesario para su implementación. Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar basado en la habilidad del equipo para medir la funcionalidad que puede entregar a través del tiempo. Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología.Metodología eXtreme Programming (XP) XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software. preocupándose por el aprendizaje de los desarrolladores. 4. Iteraciones. promoviendo el trabajo en equipo. El cliente define el valor de negocio a implementar. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas. simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. El programador construye ese valor de negocio. 2. ya que se perderá calidad en el software o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación de manejar el ámbito de entrega del producto. Fase I: Exploración En esta fase. Planificación de la Entrega (Release). Mantenimiento y Muerte del Proyecto. Vuelve al paso 1. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo. de acuerdo con sus prioridades y las restricciones de tiempo. 3. El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos: 1. Las historias de usuario son la técnica utilizada en XP para especificar los requisitos del software. y donde existe un alto riesgo técnico. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes. comunicación fluida entre todos los participantes. La fase de exploración toma de pocas semanas a pocos meses. El cliente selecciona qué construir. No se debe presionar al programador a realizar más trabajo que el estimado. En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. y propiciando un buen clima de trabajo. El ciclo de vida ideal de XP consiste de seis fases: Exploración. Producción. para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración. Se toman acuerdos sobre el contenido de la . 5.

Un punto. determinándose cuántos puntos se pueden completar. De . Las historias generalmente valen de 1 a 3 puntos. Fase V: Mantenimiento Mientras la primera versión se encuentra en producción. El Plan de Entrega está compuesto por iteraciones de no más de tres semanas. Fase III: Iteraciones Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado.primera entrega y se determina un cronograma en conjunto con el cliente. Al final de la última iteración el sistema estará listo para entrar en producción. Esto se logra escogiendo las historias que fuercen la creación de esta arquitectura. establecida en puntos por iteración. el equipo de desarrollo mantiene un registro de la "velocidad" de desarrollo. Al planificar por tiempo. cada una de ellas es asignada a un programador como responsable. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementación (por ejemplo. Fase IV: Producción La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Wake proporciona algunas guías útiles para realizar la planificación de la entrega y de cada iteración. debido a cambios durante esta fase. sin embargo. En la primera iteración se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. pero llevadas a cabo por parejas de programadores. velocidad del proyecto. La velocidad del proyecto es utilizada para establecer cuántas historias se pueden implementar antes de una fecha determinada o cuánto tiempo tomará implementar un conjunto de historias. Es posible que se rebaje el tiempo que toma cada iteración. Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la Iteración son: historias de usuario no abordadas. pruebas de aceptación no superadas en la iteración anterior y tareas no terminadas en la iteración anterior. Al planificar según alcance del sistema. Para realizar esto se requiere de tareas de soporte para el cliente. obteniendo el número de iteraciones necesarias para su implementación. se multiplica el número de iteraciones por la velocidad del proyecto. Una entrega debería obtenerse en no más de tres meses. Por otra parte. basándose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la última iteración. La planificación se puede realizar basándose en el tiempo o el alcance. se deben tomar decisiones sobre la inclusión de nuevas características a la versión actual. equivale a una semana ideal de programación. se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto. Al mismo tiempo. Todo el trabajo de la iteración es expresado en tareas de programación. Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen los programadores utilizando como medida el punto. durante la fase de mantenimiento). Esta fase dura unos pocos días. de tres a una semana. esto no siempre es posible ya que es el cliente quien decide qué historias se implementarán en cada iteración (para maximizar el valor de negocio). el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones.

Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema.esta forma. La muerte del proyecto también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo. la velocidad de desarrollo puede bajar después de la puesta del sistema en producción. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura. Se genera la documentación final del sistema y no se realizan más cambios en la arquitectura. . Fase VI: Muerte del Proyecto Es cuando el cliente no tiene más historias para ser incluidas en el sistema.

Alejandro Peña Ayala. Mª Carmen Penadés. México: INSTITUTO POLITÉCNICO NACIONAL.https://es.V. New York: McGraw-Hill.María del Carmen Gómez Fuentes.Ian Sommerville. (2006).htm 6.https://www..Patricio Letelier. Ingeniería de Software: Una Guía para Crear Sistemas de Información. Pressman. Madrid: PEARSON EDUCACIÓN S. 4.. A..Roger S. de C. 2. Enero/2016. (2005).. NOTAS DEL CURSO: ANÁLISIS DE REQUERIMIENTOS. 5. UN ENFOQUE PRÁCTICO Séptima edición. de Universidad Politécnica de Valencia (UPV) Sitio web: http://www.. (2001).. México: Publidisa Mexicana S.cyta.org/wiki/Personal_Software_Process . Métodologías ágiles para el desarrollo de software: eXtreme Programming (XP).D. INGENIERÍA DEL SOFTWARE.ar/ta0502/v5n2a1. A.. 3.es/es-es/empresa/metodologias-de-trabajo/ 7. (2010).wikipedia. (2006). INGENIERÍA DEL SOFTWARE.REFERENCIAS 1.softeng.com. . Ph.