Martes15_ Ing. Sw II

UNIVERSIDAD SAN PEDRO

UNIVERSIDAD SAN PEDROFACULTAD DE INGENIERIA

ESCUELA DE INGENIERIA

INFORMATICA

INTEGRANTES: CASTREJON TERAN Eduardo

HUAMAN VARGAS, Deyvis

VERA CABELLOS, Milagros

INGENIERIA DE SOFTWARE II


CURSO: INGENIERIA DE SOFTWARE II

DOCENTE: ING. FRANKLIN PEREZ URTEAGA

TEMA: METODODOLOGIA DE DESARROLLO DE SOFTWARE

2014

INTRODUCCIÓN

Una metodología es un conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar un nuevo software. Puede seguir uno o varios modelos de ciclo de vida, es decir, el ciclo de vida indica qué es lo que hay que obtener a lo largo del desarrollo del proyecto pero no cómo hacerlo.

La metodología indica cómo hay que obtener los distintos productos parciales y finales.

Finalmente dependerá de la metodología utilizada los productos del proyecto, por esta razón es necesario, conoces a fondo cada una de ellas y poder diferenciar entre una y otra, para de este modo saber elegir la correcta en el momento de desarrollar un nuevo software, de otra manera el producto no será el mejor e incluso puede ser inútil.

Un sistema informático está compuesto por hardware y software. En cuanto al hardware, su producción se realiza sistemáticamente y la base de conocimiento para el desarrollo de dicha actividad está claramente definida. La fiabilidad del hardware es, en principio, equiparable a la de cualquier otra máquina construida por el hombre. Sin embargo, respecto del software, su construcción y resultados han sido históricamente cuestionados debido a los problemas asociados, entre ellos podemos destacar los siguientes:

• Los sistemas no responden a las expectativas de los usuarios.

• Los programas “fallan” con cierta frecuencia.

• Los costes del software son difíciles de prever y normalmente superan las estimaciones.



• La modificación del software es una tarea difícil y costosa.

• El software se suele presentar fuera del plazo establecido y con menos prestaciones de las consideradas inicialmente.

• Normalmente, es difícil cambiar de entorno hardware usando el mismo software.

• El aprovechamiento óptimo de los recursos (personas, tiempo, dinero, herramientas, etc.) no suele cumplirse.



CAPITULO I

MARCO TEORICO

METODOLOGIA DE DESARROLLO DE SOFTWARE

Una metodología de desarrollo de software es un proceso organizado para la producción de un software. Especifica el ciclo de vida a utilizar indicando además que personas deben desempeñar cada rol en el desarrollo de la actividad.

Es una serie de pasos sistemáticos para que los diferentes grupos que participan en un desarrollo poseen una buena comunicación.

La metodología de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos



esencialmente a la naturaleza del producto obtenido. A continuación se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construcción.

Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución que se puedan presentar (entradas, valores de variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.).

Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similar. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son inevitables, no sólo después de entregado en producto sino también durante el proceso de desarrollo.

Además, de las dos anteriores, siempre puede señalarse la inmadurez de la ingeniería del software como disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniería. Sin embargo, esto no es más que un inútil consuelo.

MODELOS DE PROCESO SOFTWARE

1. METODOLOGÍA EN CASCADA.

Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseño, lo cual significa que se harán los cambios necesarios en la codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas. Después de cada etapa se realiza una revisión para comprobar si se puede pasar la siguiente.

El modelo en cascada también conocido como ciclo de vida clásico es el modelo más conocido y ofrece una velocidad de desarrollo aceptable en algunas circunstancias. Este es el predecesor de todos los modelos de ciclo de vida es el modelo en cascada. La visión del modelo cascada del desarrollo de software es muy simple Este modelo en cascada se utiliza correctamente para los ciclos de productos en los que se conoce muy bien el producto, y también cuando se esta trabajando con metodologías técnicas conocidas. En estos casos el modelo en cascada ayuda a localizar errores en las primeras etapas de la realización del proyecto a un bajo coste. El modelo cascada pura ayuda a minimizar los gastos de la planificación del proyecto porque permite realizarla sin problemas. No da resultados tangibles en forma de software hasta el final del ciclo del modelo, pero los que ya trabajan con el modelo cascada la documentación que este genera entrega indicaciones significativas de progreso



a lo largo del ciclo de vida del proyecto. Como es un modelo lineal secuencial este no puede ser corregido con gran facilidad pues no puede dar retrocesos así que esa es su gran desventaja además que no se puede dar una vista de los avances del proceso. Su ventaja es que es fácil de explicarlo. Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy Definido por Winston Royce a fines de los 70 desde entonces muchos usuarios utilizan este modelo como base para los modelos actuales de desarrollo de software. Y se trata principalmente de que se debe completar un paso correctamente sin ningún error para pasar al siguiente. Este modelo desde 10 a 15 años atrás, ha sido sujeto de numerosas criticas debido a que es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software moderno. En su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software más rápidamente, o más incrementalmente o de una forma más evolutiva, o precediendo el desarrollo a escala total con algún conjunto de prototipos rápidos. El modelo cascada mantiene que uno debe moverse a una fase solamente en que se termina y se perfecciona su fase precedente. Sin embargo, hoy en día hay varios modelos modificados de la cascada que puede incluir leves variaciones o importantes sobre este proceso. El modelo de cascada significa que primero haces una especificación de requisitos del sistema, luego haces un análisis de los requisitos para especificar la metodología de desarrollo que usarás, luego realizas el diseño de lo analizado anteriormente, luego la compilación, la prueba y el mantenimiento. Esa metodología tiene el problema de que solo le enseñas el producto al cliente cuando ya has terminado todo, y es difícil de modificarlas cosas.

2. METODOLOGÍA EN ESPIRAL

La metodología de desarrollo en espiral es una evolución de método clásico en cascada (Waterfall, top-down) y se considera un método de desarrollo incremental. Este tipo de metodología equivale al de cascada, pero en él se permite el solapamiento de varias etapas con el objetivo de flexibilizar y compensar el tiempo de desarrollo total y alcanzar resultados funcionales en etapas tempranas. Está considerada como un método de desarrollo rápido y eficiente.

Es adecuada para proyectos en los que se tienen claros los objetivos finales pero no todos los detalles de implementación están elucidados.

La metodología de desarrollo en espiral permite construir aplicaciones de tamaño medio manteniendo los recursos constantes.

3. METODOLOGÍA XP (PROGRAMACIÓN EXTREMA)

De todas las metodologías ágiles, ésta es la que ha recibido más atención. Esto se debe en parte a la notable habilidad de los líderes XP, en particular



Kent Beck, para llamar la atención. También se debe a la habilidad de Kent Beck de atraer a las personas a este acercamiento, y tomar un papel principal en él. De algunas maneras, sin embargo, la popularidad de XP se ha vuelto un problema, pues ha acaparado la atención fuera de las otras metodologías y sus valiosas ideas.

La XP empieza con cuatro valores: Comunicación, Retroalimentación, Simplicidad y Coraje. Construye sobre ellos una docena de prácticas que los proyectos XP deben seguir. Muchas de estas prácticas son técnicas antiguas, tratadas y probadas, aunque a menudo olvidadas por muchos, incluyendo la mayoría de los procesos planeados. Además de resucitar estas técnicas, la XP las teje en un todo sinérgico dónde cada una refuerza a las demás.

Una de las más llamativas, así como inicialmente atractiva para mí, es su fuerte énfasis en las pruebas. Mientras todos los procesos mencionan la comprobación, la mayoría lo hace con muy poco énfasis. Sin embargo la XP pone la comprobación como el fundamento del desarrollo, con cada programador escribiendo pruebas cuando escriben su código de producción. Las pruebas se integran en el proceso de integración continua y construcción lo que rinde una plataforma altamente estable para el desarrollo futuro.

En esta plataforma XP construye un proceso de diseño evolutivo que se basa en refactorar un sistema simple en cada iteración. Todo el diseño se centra en la iteración actual y no se hace nada anticipadamente para necesidades futuras. El resultado es un proceso de diseño disciplinado, lo que es más, combina la disciplina con la adaptabilidad de una manera que indiscutiblemente la hace la más desarrollada entre todas las metodologías adaptables.



Capitulo II

MARCO CONCEPTUAL

METODOLOGIA DE DESARROLLO DE SOFTWARE

a. DEFINICION.

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, etc.). 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 peyorativamente denominada 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.

b. LÍNEA DEL TIEMPO METODOLOGÍAS DE DESARROLLO DE SOFTWARE.

El desarrollo de los sistemas tradicionales de ciclo de vida se originó en la década de 1960 para desarrollar a gran escala funcional de sistemas de negocio en una época de grandes conglomerados empresariales. La idea principal era continuar el desarrollo de los sistemas de información en una muy deliberada, estructurada y metódica, reiterando cada una de las etapas del ciclo de vida. Los sistemas de información en torno a las actividades resueltas pesadas para el procesamiento de datos y rutinas de cálculo.

1970 Programación estructurada desde 1969

Programación estructurada Jackson desde 1975

1980 Structured Systems Analysis and Design Methodology (SSADM) desde 1980 Structured Analysis and Design Technique (SADT) desde 1980

Ingeniería de la información (IE/IEM) desde 1981

ITSA METODOLOGÍAS DE DESARROLLO DE SOFTWARE

1990 Rapid application development (RAD) desde 1991.

Programación orientada a objetos (OOP) a lo largo de la década de los 90's

Virtual finite state machine (VFSM) desde 1990s

Dynamic Systems Development Method desarrollado en UK desde 1995.

Scrum (desarrollo), en la última parte de los 90's

Nuevo milenio Programación extrema desde 1999

Enterprise Unified Process (EUP) extensiones RUP desde 2002



Rational Unified Process (RUP) desde 2003.

Constructionist design methodology (CDM) desde 2004 por Kristinn R. Thórisson

Agile Unified Process (AUP) desde 2005 por Scott Ambler

c. ¿CUÁL ES EL MODELO DE PROCESO MÁS ADECUADO?

Cada proyecto de software requiere de una forma de particular de abordar el problema. Las propuestas comerciales y académicas actuales promueven procesos iterativos, donde en cada iteración puede utilizarse uno u otro modelo de proceso, considerando un conjunto de criterios (Por ejemplo: grado de definición de requisitos, tamaño del proyecto, riesgos identificados, entre otros).

En la Tabla 1 se expone un cuadro comparativo de acuerdo con algunos criterios básicos para la selección de un modelo de proceso, la medida utilizada indica el nivel de efectividad del modelo de proceso de acuerdo al criterio (Por ejemplo: El modelo Cascada responde con un nivel de efectividad Bajo cuando los Requisitos y arquitectura no están predefinidos):

2. MODELOS DE PROCESO SOFTWARE

2.1 METODOLOGÍA EN CASCADA.

2.1.1 DEFINICION.

Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseño, lo cual significa que se harán los cambios necesarios en la codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas. Después de cada etapa se realiza una revisión para comprobar si se puede pasar la siguiente.

El modelo en cascada también conocido como ciclo de vida clásico es el modelo más conocido y ofrece una velocidad de desarrollo aceptable en algunas circunstancias. Este es el predecesor de todos los modelos de ciclo de vida es el modelo en cascada. La visión del modelo cascada del desarrollo de software es muy simple Este modelo en cascada se utiliza correctamente para los ciclos de productos en los que se conoce muy bien el producto, y también cuando se esta trabajando con metodologías técnicas conocidas. En estos casos el modelo en cascada ayuda a localizar errores en las primeras etapas de la realización del proyecto a un bajo coste. El modelo cascada pura ayuda a minimizar los gastos de la planificación del proyecto porque permite realizarla sin problemas. No da resultados tangibles en forma de software hasta el final del ciclo del modelo, pero los que ya trabajan con el modelo cascada la



documentación que este genera entrega indicaciones significativas de progreso a lo largo del ciclo de vida del proyecto. Como es un modelo lineal secuencial este no puede ser corregido con gran facilidad pues no puede dar retrocesos así que esa es su gran desventaja además que no se puede dar una vista de los avances del proceso. Su ventaja es que es fácil de explicarlo. Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy Definido por Winston Royce a fines de los 70 desde entonces muchos usuarios utilizan este modelo como base para los modelos actuales de desarrollo de software. Y se trata principalmente de que se debe completar un paso correctamente sin ningún error para pasar al siguiente. Este modelo desde 10 a 15 años atrás, ha sido sujeto de numerosas criticas debido a que es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software moderno. En su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software más rápidamente, o más incrementalmente o de una forma más evolutiva, o precediendo el desarrollo a escala total con algún conjunto de prototipos rápidos. El modelo cascada mantiene que uno debe moverse a una fase solamente en que se termina y se perfecciona su fase precedente. Sin embargo, hoy en día hay varios modelos modificados de la cascada que puede incluir leves variaciones o importantes sobre este proceso. El modelo de cascada significa que primero haces una especificación de requisitos del sistema, luego haces un análisis de los requisitos para especificar la metodología de desarrollo que usarás, luego realizas el diseño de lo analizado anteriormente, luego la compilación, la prueba y el mantenimiento. Esa metodología tiene el problema de que solo le enseñas el producto al cliente cuando ya has terminado todo, y es difícil de modificarlas cosas.

2.1.1.2 EL MODELO ORIGINAL DE LA CASCADA DE WINSTON ROYCEE especificación de requisitos

Diseño

Construcción (AKA puesta en práctica o codificación)

Integración

Prueba y el eliminar errores (Verificación de AKA)

Instalación

Mantenimiento Los que utilizan tales métodos no distinguen siempre formalmente entre el modelo puro de la cascada y los varios modelos modificados de la cascada, así que puede ser difícil discernir exactamente que los modelos se están utilizando y en qué medida

2.1.1.3 EL MODELO CASCADA, TIENE ALGUNOS PRINCIPIOS BÁSICOS LOS CUALES SELOS NOMBRA A CONTINUACIÓN:

Planear un proyecto antes de comenzar con él.INGENIERIA DE SOFTWARE II


Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna.

Documentar los resultados de cada actividad.

Diseñar un sistema antes de codificarlo.

Testear un sistema después de construirlo.

2.1.1.4 ESTRUCTURA MODELO EN CASCADA (BENNINGTON 1956)

El más conocido, está basado en el ciclo convencional de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades:

El mantenimiento se realiza en el código fuente

Las revisiones de proyectos de gran complejidad son muy difíciles

Impone una estructura de gestión de proyectos

Un error importante no detectado hasta que el programa esté funcionando puede ser desastroso

El proceso de creación del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no esté completo no se opera. Esto es la base para que funcione bien.

Cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. El modelo de cascada significa que primero haces una especificación de requisitos del sistema, luego haces un análisis de los requisitos para especificar la metodología de desarrollo que usarás, luego realizas el diseño de lo analizado anteriormente, luego la compilación, la prueba y el mantenimiento. Esa metodología tiene el problema de que solo le enseñas el producto al cliente cuando ya has terminado todo, y es difícil de modificarlas cosas



INGENIERÍA Y ANÁLISIS DEL SISTEMA:

Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software.

ANÁLISIS DE LOS REQUISITOS DEL SOFTWARE:



El proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas.

DISEÑO:

El diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz

CODIFICACIÓN

El diseño debe traducirse en una forma legible para la máquina. El paso de codificación realiza esta tarea.

PRUEBA:

La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.

MANTENIMIENTO:

El software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliación funcional eso del rendimiento

CARACTERÍSTICAS

Es el más utilizado.

Es una visión del proceso de desarrollo de software como una sucesión de etapas que producen productos intermedios.

Para que el proyecto tenga éxito deben desarrollarse todas las fases.

Las fases continúan hasta que los objetivos se han cumplido.

Si se cambia el orden de las fases, el producto final será de inferior calidad.

VENTAJAS

El modelo cascada por su sencillez solo utiliza los pasos intuitivos necesarios a la hora de desarrollar el software, además es muy entendible para cliente.

La planificación es sencilla.



La calidad del producto resultante es alta.

Permite trabajar con personal poco cualificado

DESVENTAJAS

La planificación es sencilla.

La calidad del producto resultante es alta.

Permite trabajar con personal poco cualificado.

No refleja realmente el proceso de desarrollo del software

Se tarda mucho tiempo en pasar por todo el ciclo

Perpetúa el fracaso de la industria del software en su comunicación con el usuario final

El mantenimiento se realiza en el código fuente

Las revisiones de proyectos de gran complejidad son muy difíciles

Impone una estructura de gestión de proyectos

Los proyectos raramente siguen el flujo secuencial que propone el modelo cascada, hay iteraciones

El cliente no puede establecer al principio todos los requisitos.

El cliente deber tener paciencia pues la versión operativa del producto solo estará disponible en las últimas etapas del proyecto.



2.2. METOLOGÍA ESPIRAL.

2.2.1 DEFINICIÓN. La metodología de desarrollo en espiral es una evolución de método clásico en cascada (Waterfall, top-down) y se considera un método de desarrollo incremental. Este tipo de metodología equivale al de cascada, pero en él se permite el solapamiento de varias etapas con el objetivo de flexibilizar y compensar el tiempo de desarrollo total y alcanzar resultados funcionales en etapas tempranas. Está considerada como un método de desarrollo rápido y eficiente.Es adecuada para proyectos en los que se tienen claros los objetivos finales pero no todos los detalles de implementación están elucidados.

La metodología de desarrollo en espiral permite construir aplicaciones de tamaño medio

manteniendo los recursos constantes.

Normalmente el proyecto se divide en módulos más pequeños y a cada uno de ellos se le aplica el siguiente proceso:

Análisis de requerimientos: Durante esta etapa de estudia detalladamente los requerimientos que cada objetivo con lleva. Aquí establecen todos los detalles funcionales deseados.



Diseño del sistema: Con los datos de la etapa anterior, se diseña el sistema.

Etapas de construcción: La etapa de construcción comprende básicamente la codificación y test de unidades. Esta etapa es un trabajo de programación pura.

Test y evaluación: En esta etapa se realiza un test del módulo completo así como su evaluación frente al estudio de requerimientos. En muchos casos en es esta etapa los usuarios finales participan de manera activa aportando información decisiva para la usabilidad del sistema.

Puntos fuertes:

Permite el desarrollo de proyectos en donde los objetivos finales están perfectamente definidos pero todos los detalles no pueden ser completamente establecidos al principio.

Es adaptable: algunos de los requerimientos (que no los objetivos) pueden cambiar durante el ciclo de desarrollo.

Permite la especialización de los equipos de trabajo. Apela a una gestión de proyecto ordenada. Facilita la distribución de recursos de desarrollo. Economía: es posible mantener constantes los recursos de desarrollo. Permite conseguir funcionalidad en etapas tempranas.

MODELO ESPIRAL El modelo espiral en el desarrollo del software es un modelo meta del ciclo de vida del software donde el esfuerzo del desarrollo es iterativo, tan pronto culmina un esfuerzo del desarrollo por ahí mismo comienza otro; además en cada ejecución del desarrollo se sigue cuatro pasos principales:

1. Determinar o fijar los objetivos.

En este paso se definen los objetivos específicos para posteriormente identifica las limitaciones del proceso y del sistema de software, además se diseña una planificación detallada de gestión y se identifican los riesgos.

2. Análisis del riesgo.

En este paso se efectúa un análisis detallado para cada uno de los riesgos identificados del proyecto, se definen los pasos a seguir para reducir los riesgos y luego del análisis de estos riesgos se planean estrategias alternativas.



3. Desarrollar, verificar y validar.

En este tercer paso, después del análisis de riesgo, se eligen un paradigma para el desarrollo del sistema de software y se lo desarrolla.

4. Planificar.

En este último paso es donde el proyecto se revisa y se toma la decisión si se debe continuar con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto.

CARACTERÍSTICAS DEL MODELO EN ESPIRAL PARA EL DESARROLLO DE SOFTWARE

El modelo en espiral esta compartida en varias actividades estructurales, también llamadas regiones de tareas. Existen seis regiones de tareas que son:

Comunicación con el cliente: esta es una tarea requerida para establecer comunicación entre el desarrollador y el cliente.

Planificación: esta tarea es necesaria aplicarla para poder definir los recursos, el tiempo y otras informaciones relacionadas con el proyecto, es decir, son todos los requerimientos.

Análisis de riesgos: esta es una de las tareas principales por lo que se aplica el modelo en espiral, es requerida para evaluar los riesgos técnicos y otras informaciones relacionadas con el proyecto.

Ingeniería: esta es una tarea necesaria ya que se requiere construir una o más representaciones de la aplicación.

Construcción y adaptación: esta tarea es requerida en el modelo espiral porque se necesita construir, probar, instalar y proporcionar soporte al usuario.


http://www.google.es/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&docid=olVl3M9AlnmfsM&tbnid=2yt0CZgcYApWNM:&ved=0CAUQjRw&url=http://es.wikipedia.org/wiki/Desarrollo_en_espiral&ei=qDRHU5f0H-e70gG3ooGgAQ&psig=AFQjCNF3p6a92ob5dlqEvM4ItcwkAo1BCg&ust=1397261165370815


Evaluación el cliente: esta también es una tarea principal, necesaria para adquirir la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería y la de implementación creada durante la etapa de instalación.

VENTAJAS DEL MODELO ESPIRAL No requiere una definición completa de los requerimientos del software a desarrollar para comenzar su funcionalidad. En la terminación de un producto desde el final de la primera iteración es muy factible aprobar los requisitos.


http://www.google.es/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&docid=Xt1kTxqp_fzcxM&tbnid=EZJ4H0nfFnw3LM:&ved=0CAUQjRw&url=http://sisteminformacii.wikispaces.com/METODOLOG%C3%8DA+DE+ROGER+PRESSMAN&ei=QjZHU__8JvGS0gHEtYDYAw&psig=AFQjCNF3p6a92ob5dlqEvM4ItcwkAo1BCg&ust=1397261165370815


Sufrir retrasos corre un riesgo menor, porque se comprueban los conflictos presentados tempranamente y existe la forma de poder corregirlos a tiempo.

DESVENTAJAS DEL MODELO ESPIRAL Existe complicación cuando se evalúa los riesgos. Se requiere la participación continua por parte del cliente. Se pierde tiempo al volver producir inicialmente una especificación completa de los requerimientos cuando se modifica o mejora el software.

¿POR QUÉ LA NUEMARCIÓN?

1.3.2 PROGRAMACIÓN EXTREMA O XP (EXTREME PROGRAMMING).a primera metodología ya ha sido comentada y es la que le dio conciencia al movimiento actual de metodologías ágiles. De la mano de Kent Beck, XP ha conformado un extenso grupo de seguidores en todo el mundo, disparando una gran cantidad de libros a los que dio comienzo el mismo Beck en [Beck, 2000]. InclusiveAddison-Wesley ha creado una serie de libros denominada The XP Series. Fue la misma gente del proyecto C3 la que produjo también otro de los libros importantes de XP [Jeffries, 2001] en el que se bajaban los conceptos de Beck a la puesta en práctica en un proyecto.La imagen mental de Beck al crear XP [Beck, 2000] era la de perillas en un tablero de control. Cada perilla representaba una práctica que de su experiencia sabía que trabajaba bien. Entonces, Beck decidió girar todas las perillas al máximo para ver que ocurría. Así fue como dio inicio a XP.Los principios de XP citados verbatim de Beck:• El juego de Planeamiento: Rápidamente determinar el alcance del próximo release mediante la combinación de prioridades del negocio y estimaciones técnicas. A medida que la realidad va cambiando el plan, actualizar el mismo.• Pequeños Releases: Poner un sistema simple en producción rápidamente, luego liberar nuevas versiones en ciclos muy cortos.• Metáfora: Guiar todo el desarrollo con una historia simple y compartida de cómo funciona todo el sistema.• Diseño Simple: El sistema deberá ser diseñado tan simple como sea posible en cada momento. Complejidad extra es removida apenas es descubierta.• Testing: Los programadores continuamente escriben pruebas unitarias, las cuales deben correr sin problemas para que el desarrollo continúe. Los clientes escriben pruebas demostrando que las funcionalidades están terminadas.• Refactoring: Los programadores reestructuran el sistema sin cambiar su comportamiento para remover duplicación, mejorar la comunicación, simplificar, o añadir flexibilidad.



• Programación de a Pares: Todo el código de producción es escrito por dos programadores en una máquina.• Propiedad Colectiva del Código: Cualquiera puede cambiar código en cualquier parte del sistema en cualquier momento.• Integración Continua: Integrar y hacer builds del sistema varias veces por día, cada vez que una tarea se completa.• Semana de 40-horas: Trabajar no más de 40 horas semanales como regla.Nunca trabajar horas extras durante dos semanas consecutivas.• Cliente en el lugar de Desarrollo: Incluir un cliente real en el equipo,

disponible de forma full-time para responder preguntas.• Estándares de Codificación: Los programadores escriben todo el código de acuerdo con reglas que enfatizan la comunicación a través del mismo.Como se observan, muchas de las prácticas propuestas contribuyen a maximizar la comunicación entre las personas, permitiendo de esa forma una mayor transferencia de conocimiento entre los desarrolladores y con el cliente, quien también es parte del equipo. Esto es logrado en la práctica gracias a la disposición física del lugar de trabajo.La idea es reunir a todas las personas en una misma oficina manteniendo una se observan escritorios dispuestos en el centro con varias computadoras, cada una con dos sillas dispuestas de forma de permitir la programación de a pares. En las paredes se observan pequeños boxes o escritorios con sillas, los cuales pueden ser usados por los programadores en forma privada, para realizar llamados, consultar mail, o simplemente descansar la mente. Consecuentemente se logra el objetivo mencionado al inicio del párrafo de maximizar la comunicación y la transferencia de información en el área común, mientras que se mantiene la individualidad de las personas en las mencionadas cavernas.Asimismo, XP impone un alto nivel de disciplina entre los programadores. El mismo permite mantener un mínimo nivel de documentación, lo cual a su vez se traduce en una gran velocidad en el desarrollo. Sin embargo, una desventaja que deviene de esta falta de documentación es la incapacidad de persistir la arquitectura y demás cuestiones de análisis, diseño e implementación, aún después de que el proyecto haya concluido.El énfasis que pone en XP en las personas se manifiesta en las diversas prácticas que indican que se deben dar más responsabilidades a los programadores para que estimen su trabajo, puedan entender el diseño de todo el código producido, y mantengan una metáfora mediante la cual se nombra las clases y métodos de forma consistente. La práctica denominada Semana de 40 horas indica la necesidad de mantener un horario fijo, sin horas extras ya que esto conlleva al desgaste del equipo y a la posible deserción de sus miembros. Beck afirma que como máximo se podría llegar a trabajar durante una semana con horas extras, pero si pasando ese tiempo las cosas no han mejorado entonces se deberá hacer un análisis de las estimaciones de cada iteración para que estén acordes a la capacidad de desarrollo del equipo.Si bien XP es la metodología ágil de más renombre en la actualidad, se diferencia de las demás metodologías que forman este grupo en un aspecto en particular: el alto nivel de disciplina de las personas que participan en el



proyecto. XP será tratada en detalle más adelante en relación a algunas prácticas que comparte con AgEnD.

Es una metodología para el desarrollo de software y consiste básicamente en ajustarse estrictamente a una serie de reglas que se centran en las necesidades del cliente para lograr un producto de buena calidad en poco tiempo.La Programación Extrema es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en el desarrollo de software.Promueve el trabajo en equipo, preocupándose en todo momento del aprendizaje de los desarrolladores y estableciendo un buen clima de trabajo.Este tipo de método se basa en una realimentación continuada entre el cliente y el equipo de desarrollo con una comunicación fluida entre todos los participantes, también busca simplificar las soluciones implementadas y coraje para los múltiples cambios.Este tipo de programación es la adecuada para los proyectos con requisitos imprecisos, muy cambiantes y con un riesgo técnico excesivo.

1.3.3 ROLES DE LA PROGRAMACIÓN EXTREMA (XP).Según la propuesta de Beck los roles que nos podemos encontrar son los siguientes:

Programador: El programador escribe las pruebas unitarias y produce el código del sistema.

Cliente: Escribe las historias de los usuarios y las pruebas funcionales para validar su implementación. El cliente da una gran prioridad a las historias de usuarios y decide cual implementar en cada iteración centrándose en aportar mayor valor al negocio.

Encargado de Pruebas (Tester): Ayuda al cliente a escribir las pruebas funcionales. Se encarga de ejecutar las pruebas con regularidad, difunde los resultados obtenidos al equipo y es el responsable de las herramientas que dan soporte a las pruebas.

Encargado de Seguimiento (Tracker) : Es el que proporciona la realimentación al equipo. Realiza el seguimiento del proceso de cada iteración y verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado en ello para la mejora de futuras estimaciones.

Entrenador (Coach): Es el responsable del proceso global. Se encarga de proveer guías al equipo de forma que se apliquen las practicas XP y se vaya siguiendo el proceso correctamente.

Consultor: Es un miembro externo del equipo con un conocimiento específico en algún tema que es necesario para el proyecto, en el que surgen problemas.

Gestor (Big boss): Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es la de coordinación.



CAPITULO III

EJEMPLOS DE APLICACIÓN



CAPITULO IV

CONCLUSIONES Y SUGERENCIAS

CONCLUSIONES

Después de realizar el presente trabajo grupal se obtuvieron las siguientes conclusiones:

Las metodologías de desarrollo de Software se basan en diversas pruebas, y cada una tiene proceso divididos en fases.

Cada metodología está diseñada para cumplir una necesidad especifica es decir, no todas tienen la misma funcionalidad, por ejemplo si el objetivo es la fácil y rápida creación de un programa sencillo se pude utilizar el modelo en



espiral o el de cascada; pero si por el contrario se requiere el diseño de un programa tecnificado arquitectónico más complicado.

Por otro lado cabe mencionar que es necesario conocer todas y cada una de estas metodologías de desarrollo, para poder ser acertados en la elección de la adecuada según nuestro objetivo.

El prototipo del modelo en espiral para la ingeniería de software es en la actualidad el enfoque más realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniería de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel del modelo en espiral.



CAPITULO V

BIBLIOGRAFIA

1. http://es.wikipedia.org/wiki/Desarrollo_en_espiral 2. http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf 3. http://es.wikipedia.org/wiki/Software#Proceso_de_creaci.C3.B3n_del_software 4.


http://es.wikipedia.org/wiki/Software#Proceso_de_creaci.C3.B3n_del_software

http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf

http://es.wikipedia.org/wiki/Desarrollo_en_espiral

Martes15_ Ing. Sw II

Documents

Transcript of Martes15_ Ing. Sw II