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 PARADESARROLLO DE SOFTWARE ...........................................1
Ciclo de vida del software ..............................................................................................6
Modelos de ciclo de vida...................................................................................................7
Modelo en cascada......................................................................................................7
Modelo V....................................................................................................................... 8
METODOLOGÍARUP...................................................................................................... 9
Fases de desarrollo del software…………………………………………………………9
TIPOS………………………………………………………………………………………….10

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

2
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)

3
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.

4
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

5
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

6
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.

7
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

8
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.

9
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.

10
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.

11
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á

12
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 TECNOLOGICOSPENCER W.KIMBALL PROFESOR: ALVARO MARTINEZ
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
sabiendocómo hayque realizar cualquiertipo 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

Metodologías para desarrollo de software

Más contenido relacionado

La actualidad más candente (20)

Destacado (20)

Similar a Metodologías para desarrollo de software (20)

Más de Abner Garcia (6)

Último (20)

Metodologías para desarrollo de software