Metodologa de desarrollo de software

Metodologa de desarrollo de software en ingeniera de software es un marco de trabajo

usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de
informacin.1

Tres patrones bsicos en las metodologas de desarrollo de software.

ndice
[ocultar]

1Introduccin

2Historia

3Metodologas de desarrollo de software

4Enfoques de desarrollo de software

o 4.1Modelo en cascada

o 4.2Prototipado

o 4.3Incremental

o 4.4Espiral

o 4.5Rapid Application Development (RAD)

o 4.6Otros enfoques de desarrollo de software

5Referencia

Introduccin[editar]
Una metodologa de desarrollo de software se refiere a un framework que es usado para
estructurar, planear y controlar el proceso de desarrollo en sistemas de informacin.
A lo largo del tiempo, una gran cantidad de mtodos han sido desarrollados diferencindose por
su fortaleza y debilidad.
El framework para metodologa de desarrollo de software consiste en:

Una filosofa de desarrollo de programas de computacin con el enfoque del

proceso de desarrollo de software

Herramientas, modelos y mtodos para asistir al proceso de desarrollo de software

Estos frameworks son a menudo vinculados a algn tipo de organizacin, que adems
desarrolla, apoya el uso y promueve la metodologa.

Historia[editar]
El desarrollo de los sistemas tradicionales de ciclo de vida se origin en la dcada 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
informacin en una muy deliberada, estructurada y metdica, reiterando cada una de las etapas
del ciclo de vida. Los sistemas de informacin en torno a las actividades resueltas pesadas para
el procesamiento de datos y rutinas de clculo.
Metodologas de Desarrollo de Software tiene como objetivo presentar un conjunto de tcnicas
tradicionales y modernas de modelado de sistemas que permitan desarrollar software de
calidad, incluyendo heursticas de construccin y criterios de comparacin de modelos de
sistemas.
Para tal fin se describen, fundamentalmente, herramientas de Anlisis y Diseo Orientado a
Objetos (UML), sus diagramas, especificacin, y criterios de aplicacin de las mismas. Como
complemento se describirn las metodologas de desarrollo de software que utilizan dichas
herramientas, ciclos de vida asociados y discusin sobre el proceso de desarrollo de software
ms adecuado para las diferentes aplicaciones ejemplos que se presentarn. Principalmente, se
presentar el Proceso Unificado el cual utiliza un ciclo de vida iterativo e incremental.

Kendall y Kendall
I. Identificacin del problema, oportunidades y objetivos. II. Determinacin de los requerimientos
de informacin. III. Anlisis de las necesidades del sistema. IV. Diseo del sistema
recomendado. V. Desarrollo y documentacin del software. VI. Pruebas y mantenimiento del
sistema. VII. Implantacin y evaluacin del sistema.

James Senn
I. Ciclo de vida y desarrollo del sistema. II. Desarrollo por anlisis estructurado III. Prototipo del
sistema.

Llorens Fabregas
I. Requerimientos. II. Anlisis/Diseo. III. Construccin. IV. Pruebas. V. Produccin y
mantenimiento.

Jonas Montilva
I. Definir el proyecto. II. Anlisis del contexto. III. Definicin de los requerimientos. IV. Diseo
preliminar. V. Diseo detallado.

Roger Pressman
I. Anlisis de los requerimientos del Software. II. Diseo. III. Generacin de cdigo. IV. Pruebas.
V. Mantenimiento;
Metodologas de desarrollo de software[editar]
1970

Programacin estructurada sol desde 1969

Programacin estructurada Jackson desde 1975

1980

Structured Systems Analysis and Design Methodology (SSADM) desde 1980

Structured Analysis and Design Technique (SADT) desde 1980

Ingeniera de la informacin (IE/IEM) desde 1981

1990

Rapid application development (RAD) desde 1991.

Programacin orientada a objetos (OOP) a lo largo de la dcada 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

Rational Unified Process (RUP) desde 1999.

Extreme Programming(XP) desde 1999

Nuevo milenio

Enterprise Unified Process (EUP) extensiones RUP desde 2002

Constructionist design methodology (CDM) desde 2004 por Kristinn R. Thrisson

Agile Unified Process (AUP) desde 2005 por Scott Ambler

Enfoques de desarrollo de software[editar]

Cada metodologa de desarrollo de software tiene ms o menos su propio enfoque para
el desarrollo de software. Estos son los enfoques ms generales, que se desarrollan en varias
metodologas especficas. Estos enfoques son los siguientes:1

Modelo en cascada: Framework lineal.

Prototipado: Framework iterativo.

Incremental: Combinacin de framework lineal e iterativo.

Espiral: Combinacin de framework lineal e iterativo.

 RAD: Rapid Application Development, framework iterativo.
Modelo en cascada[editar]
Es un proceso secuencial, fcil de desarrollo en el que los pasos de desarrollo son vistos hacia
abajo (como en una cascada de agua) a travs de las fases de anlisis de las necesidades, el
diseo, implantacin, pruebas (validacin), la integracin, y mantenimiento. La primera
descripcin formal del modelo de cascada se cita a menudo a un artculo publicado por Winston
Royce W.2 en 1970, aunque Royce no utiliza el trmino "cascada" de este artculo.
Los principios bsicos del modelo de cascada son los siguientes:1

El proyecto est dividido en fases secuenciales, con cierta superposicin y splashback

aceptable entre fases.

Se hace hincapi en la planificacin, los horarios, fechas, presupuestos y ejecucin de

todo un sistema de una sola vez.

Un estricto control se mantiene durante la vida del proyecto a travs de la utilizacin de

una amplia documentacin escrita, as como a travs de comentarios y aprobacin / signoff
por el usuario y la tecnologa de la informacin de gestin al final de la mayora de las fases
antes de comenzar la prxima fase.
Prototipado[editar]
El prototipado permite desarrollar modelos de aplicaciones de software que permiten ver la
funcionalidad bsica de la misma, sin necesariamente incluir toda la lgica o caractersticas del
modelo terminado. El prototipado permite al cliente evaluar en forma temprana el producto, e
interactuar con los diseadores y desarrolladores para saber si se est cumpliendo con las
expectativas y las funcionalidades acordadas. Los Prototipos no poseen la funcionalidad total
del sistema pero si condensa la idea principal del mismo, Paso a Paso crece su funcionalidad, y
maneja un alto grado de participacin del usuario.
Incremental[editar]
Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del
producto software reservando el resto de aspectos para el futuro.
Los principios bsicos son:

Una serie de mini-Cascadas se llevan a cabo, donde todas las fases de la cascada
modelo de desarrollo se han completado para una pequea parte de los sistemas, antes de
proceder a la prxima incremental.

Se definen los requisitos antes de proceder con lo evolutivo, se realiza un mini-Cascada

de desarrollo de cada uno de los incrementos del sistema.

El concepto inicial de software, anlisis de las necesidades, y el diseo de la arquitectura

y colectiva bsicas se definen utilizando el enfoque de cascada, seguida por iterativo de
prototipos, que culmina en la instalacin del prototipo final.
Espiral[editar]
Los principios bsicos son:

La atencin se centra en la evaluacin y reduccin del riesgo del proyecto dividiendo el

proyecto en segmentos ms pequeos y proporcionar ms facilidad de cambio durante el
proceso de desarrollo, as como ofrecer la oportunidad de evaluar los riesgos y con un peso
de la consideracin de la continuacin del proyecto durante todo el ciclo de vida.
 Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes bsicos: (1) determinar
objetivos, alternativas, y desencadenantes de la iteracin; (2) Evaluar alternativas; Identificar
y resolver los riesgos; (3) desarrollar y verificar los resultados de la iteracin, y (4) plan de la
prxima iteracin.3

Cada ciclo comienza con la identificacin de los interesados y sus condiciones de

ganancia, y termina con la revisin y examinacin.3
Rapid Application Development (RAD)[editar]
El desarrollo rpido de aplicaciones (RAD) es una metodologa de desarrollo de software, que
implica el desarrollo iterativo y la construccin de prototipos. El desarrollo rpido de aplicaciones
es un trmino originalmente utilizado para describir un proceso de desarrollo de
software introducido por James Martin en 1991.
Principios bsicos:

Objetivo clave es para un rpido desarrollo y entrega de una alta calidad en un sistema
de relativamente bajo coste de inversin.

Intenta reducir el riesgos inherente del proyecto partindolo en segmentos ms

pequeos y proporcionar ms facilidad de cambio durante el proceso de desarrollo.

Orientacin dedicada a producir sistemas de alta calidad con rapidez, principalmente

mediante el uso de iteracin por prototipos (en cualquier etapa de desarrollo), promueve la
participacin de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas
herramientas pueden incluir constructores de Interfaz grfica de usuario (GUI), Computer
Aided Software Engineering (CASE) las herramientas, los sistemas de gestin de bases de
datos (DBMS), lenguajes de programacin de cuarta generacin, generadores de cdigo, y
tcnicas orientada a objetos.

Hace especial hincapi en el cumplimiento de la necesidad comercial, mientras que la

ingeniera tecnolgica o la excelencia es de menor importancia.

Control de proyecto implica el desarrollo de prioridades y la definicin de los plazos de

entrega. Si el proyecto empieza a aplazarse, se hace hincapi en la reduccin de requisitos
para el ajuste, no en el aumento de la fecha lmite.

En general incluye Joint application development (JAD), donde los usuarios estn
intensamente participando en el diseo del sistema, ya sea a travs de la creacin de
consenso estructurado en talleres, o por va electrnica.

La participacin activa de los usuarios es imprescindible.

Iterativamente realiza la produccin de software, en lugar de enfocarse en un prototipo.

Produce la documentacin necesaria para facilitar el futuro desarrollo y mantenimiento.

Otros enfoques de desarrollo de software[editar]

Metodologas de desarrollo Orientado a objetos, Diseo orientado a objetos (OOD)

de Grady Booch, tambin conocido como Anlisis y Diseo Orientado a Objetos (OOAD). El
modelo incluye seis diagramas: de clase, objeto, estado de transicin, la interaccin,
mdulo, y el proceso.
 Top-down programming, evolucionado en la dcada de 1970 por el investigador
de IBM Harlan Mills (y Niklaus Wirth) en Desarrollo Estructurado.

Proceso Unificado, es una metodologa de desarrollo de software, basado en UML.

Organiza el desarrollo de software en cuatro fases, cada una de ellas con la ejecucin de
una o ms iteraciones de desarrollo de software: creacin, elaboracin, construccin, y las
directrices. Hay una serie de herramientas y productos diseados para facilitar la aplicacin.
Una de las versiones ms populares es la de Rational Unified Process.

Diagrama de flujo

Diagrama de flujo sencillo con los pasos a seguir si una lmpara no funciona.
 Diagrama de actividades para un loop (bucle

El diagrama de flujo o diagrama de actividades es la representacin grfica del algoritmo o

proceso. Se utiliza en disciplinas como programacin, economa, procesos
industriales y psicologa cognitiva.
En Lenguaje Unificado de Modelado (UML), un diagrama de actividades representa los flujos de
trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un
diagrama de actividades muestra el flujo de control general.
En SysML el diagrama ha sido extendido para indicar flujos entre pasos que mueven elementos
fsicos (p. ej., gasolina) o energa (p. ej., presin). Los cambios adicionales permiten al diagrama
soportar mejor flujos de comportamiento y datos continuos.
Estos diagramas utilizan smbolos con significados definidos que representan los pasos del
algoritmo, y representan el flujo de ejecucin mediante flechas que conectan los puntos de inicio
y de fin del proceso.

ndice

1Normas de trabajo

2Descripcin

3Tipos de diagramas de flujo

4Simbologa y significado
 5Cursograma

o 5.1Simbologa y normas del diagrama

6Historia

7Ventajas de los diagramas de flujo

8Software para diseo de diagramas de flujo

9Vase tambin

10Referencias

11Enlaces externos

Normas de trabajo[editar]
Un diagrama de flujo presenta generalmente un nico punto de inicio y un nico punto de cierre,
aunque puede tener ms, siempre que cumpla con la lgica requerida.
Las siguientes son acciones previas a la realizacin del diagrama de flujo:

Identificar las ideas principales al ser incluidas en el diagrama de flujo. Deben estar
presentes el autor o responsable del proceso, los autores o responsables del proceso
anterior y posterior y de otros procesos interrelacionados, as como las terceras partes
interesadas.

Definir qu se espera obtener del diagrama de flujo.

Identificar quin lo emplear y cmo.

Establecer el nivel de detalle requerido.

Determinar los lmites del proceso a describir.

Los pasos a seguir para construir el diagrama de flujo son:

Establecer el alcance del proceso a describir. De esta manera quedar fijado el

comienzo y el final del diagrama. Frecuentemente el comienzo es la salida del proceso
previo y el final la entrada al proceso siguiente.

Identificar y listar las principales actividades/subprocesos que estn incluidos en el

proceso a describir y su orden cronolgico.

Si el nivel de detalle definido incluye actividades menores, listarlas tambin.

Identificar y listar los puntos de decisin.

Construir el diagrama respetando la secuencia cronolgica y asignando los

correspondientes smbolos.
 Asignar un ttulo al diagrama y verificar que est completo y describa con exactitud el
proceso elegido.

Descripcin[editar]
En UML 1.x, un diagrama de actividades es una variacin del diagrama de estado UNL donde
los "estados" representan operaciones, y las transiciones representan las actividades que
ocurren cuando la operacin se termina.
El diagrama de mensajes de UML 2.0, mientras que es similar en aspecto al diagrama de
actividades UML 1.x, ahora tiene semnticas basadas en redes de Petri. En UML 2.0, el
diagrama general de interaccin est basado en el diagrama de actividades. El diagrama de
actividad es una forma especial de diagrama de estado usado para modelar una secuencia de
acciones y condiciones tomadas dentro de un proceso.
La especificacin del Lenguaje de Notificacin Unificado (UNL) define un diagrama de actividad
como:
una variacin de los estados de una mquina, los cuales representan el rendimiento de las
acciones o subactividades y las transiciones se provocan por la realizacin de las acciones o
subactividades.1
El propsito del diagrama de actividad es modelar un proceso de flujo de trabajo (workflow) y/o
modelar operaciones.
Una Operacin es un servicio proporcionado por un objeto, que est disponible a travs de una
interfaz.
Una Interfaz es un grupo de operaciones relacionadas con la semntica. Caractersticas de los
Flujogramas Segn Gmez Cejas, Guillermo. Ao 1.997: Sinttica: La representacin que se
haga de un sistema o un proceso deber quedar resumido en pocas hojas, de preferencia en
una sola. Los diagramas extensivos dificultan su comprensin y asimilacin, por tanto dejan de
ser prcticos. Simbolizada: La aplicacin de la simbologa adecuada a los diagramas de
sistemas y procedimientos evita a los analistas anotaciones excesivas, repetitivas y confusas en
su interpretacin. De forma visible a un sistema o un proceso: Los diagramas nos permiten
observar todos los pasos de un sistema o proceso sin necesidad de leer notas extensas. Un
diagrama es comparable, en cierta forma, con una fotografa area que contiene los rasgos
principales de una regin, y que a su vez permite observar estos rasgos o detalles principales.
Segn Chiavenato, Idalberto. Ao 1.993: Permitir al analista asegurarse que ha desarrollado
todos los aspectos del procedimiento. Dar las bases para escribir un informe claro y lgico. Es
un medio para establecer un enlace con el personal que eventualmente operar el nuevo
procedimiento. Segn Gmez Rondn, Francisco. Ao 1.995: De uso, permite facilitar su
empleo. De destino, permite la correcta identificacin de actividades. De comprensin e
interpretacin, permite simplificar su comprensin. De interaccin, permite el acercamiento y
coordinacin. De simbologa, disminuye la complejidad y accesibilidad. De diagramacin, se
elabora con rapidez y no requiere de recursos sofisticados.

Leer
ms: http://www.monografias.com/trabajos14/flujograma/flujograma.shtml#CARA#ixzz4D0WSrW
IH

Tipos de diagramas de flujo[editar]

Formato vertical: En l, el flujo y la secuencia de las operaciones, va de arriba hacia
abajo. Es una lista ordenada de las operaciones de un proceso con toda la informacin que
se considere necesaria, segn su propsito.
 Formato horizontal: En l, el flujo o la secuencia de las operaciones, va de izquierda a
derecha.

Formato panormico: El proceso entero est representado en una sola carta y puede
apreciarse de una sola mirada mucho ms rpido que leyendo el texto, lo que facilita su
comprensin, aun para personas no familiarizadas. Registra no solo en lnea vertical, sino
tambin horizontal, distintas acciones simultneas y la participacin de ms de un puesto o
departamento que el formato vertical no registra.

Formato Arquitectnico: Describe el itinerario de ruta de una forma o persona sobre el

plano arquitectnico del rea de trabajo. El primero de los flujogramas es eminentemente
descriptivo, mientras que los utilizados son fundamentalmente representativos.

Simbologa y significado[editar]
valo o Elipse: Inicio y Final (Abre y cierra el diagrama).

Rectngulo: Actividad (Representa la ejecucin de una o ms actividades o

procedimientos).

Rombo: Decisin (Formula una pregunta o cuestin).

Crculo: Conector (Representa el enlace de actividades con otra dentro de un

procedimiento).

Tringulo boca abajo: Archivo definitivo (Guarda un documento en forma permanente).

Tringulo boca arriba: Archivo temporal (Proporciona un tiempo para el

almacenamiento del documento).

Cursograma[editar]
Se trata de la ms comn y prctica entre todas las clases de diagramas de flujo. Describe el
flujo de informacin en un ente u organizacin, sus procesos, sistemas administrativos y de
control. Permite la impresin visual de los procedimientos y una clara y lgica interpretacin.
Simbologa y normas del diagrama[editar]

Crculo: Indica Inicio del Diagrama y Final del Diagrama

Cuadrado: Proceso de control.

Lnea continua: Flujo de informacin va formulario o documentacin en soporte de

papel escrito.

Lnea interrumpida: Flujo de informacin va formulario digital.

Rectngulo: Formulario o documentacin. Se grafca con el doble de ancho que su

altura.

Rectngulo Pequeo: Valor o medio de pago (cheque, pagar, etc.). Se grafca con el
cudruple de ancho que su altura, siendo su ancho igual al de los formularios.
 Tringulo (base inferior): Archivo definitivo.

Tringulo Invertido (base superior): Archivo Transitorio.

Semivalo: Demora.

Rombo: Divisin entre opciones.

Trapezoide: Carga de datos al sistema.

Elipsoide: Acceso por pantalla.

Hexgono: Proceso no representado.

Pentgono: Conector.

Cruz de Diagonales: Destruccin de Formularios.

Segn la normativa, el flujo presupuesto es de izquierda a derecha y de arriba hacia abajo,
siendo optativo el uso de flechas. Cuando el sentido es invertido (de derecha a izquierda o de
abajo hacia arriba), es obligatorio el uso de la flecha.2

Historia[editar]
La paternidad del diagrama de flujo es en principio algo difusa. El mtodo estructurado para
documentar grficamente un proceso como un flujo de pasos sucesivo y alternativos, el
"proceso de diagrama de flujo", fue expuesto por Frank Gilbreth, en la Sociedad Americana de
Ingenieros Mecnicos (ASME), en 1921, bajo el enunciado de "Proceso de Grficas-Primeros
pasos para encontrar el mejor modo". Estas herramientas de Gilbreth rpidamente encontraron
sitio en los programas de ingeniera industrial.
Al principio de los 30, un ingeniero industrial, Allan H. Mogensen comenz la formacin de
personas de negocios en Lake Placid, Nueva York, incluyendo el uso del diagrama de flujo. Art
Spinanger, asistente a las clases de Mogesen, utiliz las herramientas en su trabajo en Procter
& Gamble, donde desarroll su Programa Metdico de Cambios por Etapas. Otro asistente al
grupo de graduados en 1944, Ben S. Graham, director de ingeniera de Formcraft Standard
Register Corporation, adapt la grfica de flujo de procesos al tratamiento de la informacin en
su empresa. Y desarroll la grfica del proceso de mltiples flujos en mltiples pantallas,
documentos, y sus relaciones. En 1947, ASME adopt un conjunto de smbolos derivados de la
obra original de Gilbreth como Norma ASME para los grficos de procesos (preparada Mishad,
Ramsan y Raiaan).
Sin embargo, segn explica Douglas Hartree fueron originalmente Herman Goldstine y John von
Neumann quienes desarrollaron el diagrama de flujo (inicialmente llamado "diagrama") para
planificar los programas de ordenador. Las tablas de programacin original de flujo de Goldstine
y von Neumann, aparecen en un informe no publicado, "Planificacin y codificacin de los
problemas de un instrumento de computacin electrnica, la Parte II, Volumen 1 "(1947),
reproducido en las obras completas de von Neumann.
Inicialmente los diagramas de flujo resultaron un medio popular para describir algoritmos de
computadora, y an se utilizan con este fin. Herramientas como los diagramas de actividad
UML, pueden ser considerados como evoluciones del diagrama de flujo.
En la dcada de 1970 la popularidad de los diagramas de flujo como mtodo propio de la
informtica disminuy, con el nuevo hardware y los nuevos lenguajes de programacin de
tercera generacin. Y por otra parte se convirtieron en instrumentos comunes en el mundo
empresarial. Son una expresin concisa, legible y prctica de algoritmos. Actualmente se aplican
en muchos campos del conocimiento, especialmente como simplificacin y expresin lgica de
procesos, etc.

Ventajas de los diagramas de flujo[editar]

Ayudan a ilustrar modelos y a conectar ideas para aumentar nuestra productividad en el
entorno profesional e incentivar nuestra creatividad. 3

Favorecen la comprensin del proceso al mostrarlo como un dibujo. El cerebro humano

reconoce muy fcilmente los dibujos. Un buen diagrama de flujo reemplaza varias pginas
de texto.

Permiten identificar los problemas y las oportunidades de mejora del proceso. Se

identifican los pasos, los flujos de los reprocesos, los conflictos de autoridad, las
responsabilidades, los cuellos de botella, y los puntos de decisin.

Muestran las interfaces cliente-proveedor y las transacciones que en ellas se realizan,

facilitando a los empleados el anlisis de las mismas.

Son una excelente herramienta para capacitar a los nuevos empleados y tambin a los
que desarrollan la tarea, cuando se realizan mejoras en el proceso.

Al igual que el pseudocdigo, el diagrama de flujo con fines de anlisis

de algoritmos de programacin puede ser ejecutado en un ordenador, con un IDE como
Free DFD.

Software para diseo de diagramas de flujo[editar]

Actualmente existe una gran cantidad de software para la elaboracin de diagramas de flujo. A
continuacin se listan los programas ms comunes para elaborar diagramas de flujo.

Microsoft Office ofrece 3 herramientas tiles para la elaboracin de diagramas. Uno de

ellos es Microsoft Office Word, que nos permite crear diagramas de flujo bsicos a travs de
la opcin "Formas" que tiene un apartado especial para diagramas de flujo. De igual manera
Microsoft Office Power Point ofrece las mismas opciones para crear los diseos de
diagramas de flujo. Otra herramienta un poco ms sofisticada es Microsoft Office Visio, que
adems de la simbologa bsica de los diagramas de flujo cuenta con una variedad de
herramientas para elaborar otros tipos de diagramas como es el caso diagramas UML entre
otros tipos de diagramas de flujo.

Otro programa eficiente y muy fcil de usar es el programa "Dia" que brinda una solucin
rpida para la creacin de diagramas de flujo adems de otro tipo de diagramas usados en
el ambiente informtico. Es considerado la versin no comercial de Microsoft Visio.