METODOLOGAS DE INGENIERA DEL SOFTWARE

La rama de la metodologa, dentro de la ingeniera de software, se encarga de

elaborar estrategias, tcnicas y formas de trabajo de desarrollo de software que
promuevan prcticas adaptativas en vez de predictivas; centradas en las personas
o los equipos, orientadas hacia la funcionalidad y la entrega, de comunicacin
intensiva y que requieren implicacin directa del cliente.
Una metodologa 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.

METODOLOGAS DEL DESARROLLO DEL SOFTWARE

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

Qu hay que saber para construir o elegir una metodologa?

En el momento de adoptar un estndar o construir una metodologa, se han de
considerar unos requisitos deseables, por lo que seguidamente se proponen una
serie de criterios de evaluacin de dichos requisitos.

1. La metodologa debe ajustarse a los objetivos.

Cada aproximacin al desarrollo de software est basada en unos objetivos. Por

ello la metodologa que se elija debe recoger el aspecto filosfico de la
aproximacin deseada, es decir que los objetivos generales del desarrollo deben
estar implementados en la metodologa de desarrollo.

2. La metodologa debe cubrir el ciclo entero de desarrollo de software

Para ello la metodologa ha de realizar unas etapas:

o Investigacin

o Anlisis de requisitos

o Diseo

3. La metodologa debe integrar las distintas fases del ciclo de desarrollo

Rastreabilidad. Es importante poder referirse a otras fases de un proyecto y

fusionarlo con las fases previas. Es importante poder moverse no slo hacia
adelante en el ciclo de vida, sino hacia atrs de forma que se pueda comprobar el
trabajo realizado y se puedan efectuar correcciones.

Fcil interaccin entre etapas del ciclo de desarrollo. Es necesaria una

validacin formal de cada fase antes de pasar a la siguiente. La informacin que
se pierde en una fase determinada queda perdida para siempre, con un impacto
en el sistema resultante.

4. La metodologa debe incluir la realizacin de validaciones.

La metodologa debe detectar y corregir los errores cuanto antes. Uno de los
problemas ms frecuentes y costosos es el aplazamiento de la deteccin y
correccin de problemas en las etapas finales del proyecto. Cuanto ms tarde sea
detectado el error ms caro ser corregirlo. Por lo tanto cada fase del proceso de
desarrollo de software deber incluir una actividad de validacin explcita.

5. La metodologa debe soportar la determinacin de la exactitud del sistema a

travs del ciclo de desarrollo.

La exactitud del sistema implica muchos asuntos, incluyendo la correspondencia

entre el sistema y sus especificaciones, as como que el sistema cumple con las
necesidades del usuario. Por ejemplo, los mtodos usados para anlisis y
especificacin del sistema deberan colaborar a terminar con el problema del
entendimiento entre los informticos, los usuarios, y otras partes implicadas.
Esto implica una comunicacin entre usuario y tcnico amigable y sencillo, exento
de consideraciones tcnicas.

6. La metodologa debe ser la base de una comunicacin efectiva.

Debe ser posible gestionar a los informticos, y stos deben ser capaces de
trabajar conjuntamente. Ha de haber una comunicacin efectiva entre analistas,
programadores, usuarios y gestores, con pasos bien definidos para realizar
progresos visibles durante la actividad del desarrollo.

7. La metodologa debe funcionar en un entorno dinmico orientado al usuario.

A lo largo de todo el ciclo de vida del desarrollo se debe producir una transferencia
de conocimientos hacia el usuario. La clave del xito es que todas las partes
implicadas han de intercambiar informacin libremente. La participacin del
usuario es de importancia vital debido a que sus necesidades evolucionan
constantemente. Por otra parte la adquisicin de conocimientos del usuario la
permitir la toma de decisiones correctas.Para involucrar al usuario en el anlisis,
diseo y administracin de datos, es aconsejable el empleo de tcnicas
estructuradas lo ms sencillas posible. Para esto, es esencial contar una buena
tcnica de diagramacin.

8. La metodologa debe especificar claramente los responsables de resultados.

Debe especificar claramente quienes son los participantes de cada tarea a

desarrollar, debe detallar de una manera clara los resultados de los que sern
responsables.

9. La metodologa debe poder emplearse en un entorno amplio de proyectos

software:

Variedad. Una empresa deber adoptar una metodologa que sea til para un
gran nmero de sistemas que vaya a construir. Por esta razn no es prctico
adoptar varias metodologas en una misma empresa.

Tamao, vida. Las metodologas debern ser capaces de abordar sistemas de

distintos tamaos y rangos de vida.

Complejidad. La metodologa debe servir para sistemas de distinta complejidad,

es decir puede abarcar un departamento, varios de departamentos o varias
empresas.

Entorno. La metodologa debe servir con independencia de la tecnologa

disponible en la empresa.
10. La metodologa se debe de poder ensear

Incluso en una organizacin sencilla, sern muchas las personas que la van a
utilizar, incluso los que se incorporen posteriormente a la empresa. Cada persona
debe entender las tcnicas especficas de la metodologa, los procedimientos
organizativos y de gestin que la hacen efectiva, las herramientas automatizadas
que soportan la metodologa y las motivaciones que subyacen en ella.

11. La metodologa debe estar soportada por herramientas CASE.

La metodologa debe estar soportada por herramientas automatizadas que

mejoren la productividad, tanto del ingeniero de software en particular, como la del
desarrollo en general.
El uso de estas herramientas reduce el nmero de personas requeridas y la
sobrecarga de comunicacin, adems de ayudar a producir especificaciones y
diseos con menos errores, ms fciles de probar, modificar y usar.

12. La metodologa debe soportar la eventual evolucin del sistema.

Normalmente durante su tiempo de vida los sistemas tienen muchas versiones,

pudiendo durar incluso ms de 10 aos. Existen herramientas CASE para la
gestin de la configuracin y otras denominadas "Ingeniera inversa" para ayudar
en el mantenimiento de los sistemas no estructurados, permitiendo estructurar los
componentes de stos facilitando as su mantenimiento.

13. La metodologa debe contener actividades conducentes a mejorar el proceso

de desarrollo de software.

Para mejorar el proceso es bsico disponer de datos numricos que evidencian la

efectividad de la aplicacin del proceso con respecto a cualquier producto software
resultante del proceso. Para disponer de estos datos, la metodologa debe
contener un conjunto de mediciones de proceso para identificar la calidad y coste
asociado a cada etapa del proceso. Sera ideal el uso de herramientas CASE.

QU CRITERIOS SON MS IMPORTANTES?

Se han realizado pocos estudios para determinar qu factores son los ms
importantes en el momento de seleccionar una metodologa de desarrollo de
software. Uno es el de Sachidanandam Sakthivec, donde la conclusin obtenida,
es que no todos los requisitos son iguales de importantes para los profesionales
de desarrollo de software.

Esta investigacin se bas en requisitos de la metodologa. Seguidamente se

muestra un cuestionario para clasificar la importancia de los nmeros relevantes

Cuestionarios Nmeros

Enviados 400

Contestados 54 (13.5%)

No vlidos 27

Vlidos 27

Posteriormente mediante un programa que utiliza algoritmos computacionales

AHP (Analityc Hierarchy Process), identific la importancia relativa de los
requisitos de la metodologa para cada participante en la encuesta. Las
conclusiones de la investigacin dieron el siguiente resultado:

La capacidad de una metodologa para desarrollar sistemas con la calidad

requerida es el requisito ms importante para los profesionales del
desarrollo.

Coincidencia con los investigadores en la importancia que tiene el criterio

de satisfaccin del usuario en la calidad del nuevo sistema

La capacidad para desarrollar gran variedad de sistemas tiene mayor

importancia que los aspectos relacionados con la productividad.
 Los profesionales prefieren como segundo requisito que la metodologa
soporte todas las etapas del desarrollo.

QU METODOLOGA DEBO UTILIZAR?

Hay una serie de metodologas que solemos llamar tradicionales, propuestas casi
todas ellas con anterioridad a los aos 90 del siglo XX, y que pretendan ayudar a
los profesionales indicando pautas para realizar y documentar cada una de las
tareas del desarrollo del software. Sin embargo, tienen casi todas ellas un gran
lastre: asumen que un proyecto informtico es casi una extensin de un proyecto
burocrtico tradicional. As pues, los pasos que sugieren para llevar a cabo cada
tarea, aunque bienintencionados, estn cargados de burocracia, reiteraciones,
ambigedades... No suelen tener en cuenta cosas como la calidad, la satisfaccin,
la competitividad, los beneficios. Fueron metodologas creadas en los aos 70-80
pensando en los negocios de los aos 50.

El mundo va ahora mucho ms rpido: slo los negocios inteligentes sobreviven...

slo los proyectos de software inteligentemente construidos lo hacen tambin.
Ahora las comunicaciones son instantneas... mundiales. La informacin fluye en
tiempo real. Las empresas compiten al segundo.

El software ya tiene una cierta historia. Hemos aprendido mucho. Utilizamos

conceptos abstractos para construir sistemas que van mucho ms all de los
datos y los algoritmos.

La mayor parte de las metodologas tradicionales ya no funcionan. Estn

obsoletas desde casi todos los puntos de vista. Slo algunas metodologas
tradicionales han sido revisadas y adaptadas... y su funcionalidad suele estar
limitada a proyectos poco innovadores.

Las metodologas surgidas desde los 90 hasta aqu suelen tener otra mentalidad...
una cierta agilidad. Siendo conscientes de lo cambiante y amplio que es el mundo
del software, una metodologa debe ser lo suficientemente precisa como para que
todo el mundo la pueda seguir y sea de utilidad como pauta comn, pero tambin
debe ser lo suficientemente adaptable como para poder aplicarse en distintos
proyectos, y lo suficientemente sencilla como para que no resulte muy gravosa su
utilizacin, pero lo suficientemente completa y compleja como para que la
utilizacin por parte del equipo sea provechosa... En una palabra: agilidad.

Aunque el trmino de agilidad es muy discutible, es indudable que las

metodologas "modernas" responden a otra mentalidad completamente distinta.

As a la pregunta de "Qu metodologa utilizar?"... pues podemos dar una

orientacin dependiendo de tu situacin:
 Si formas parte de un equipo de desarrollo en un proyecto grande y te toca
decidir qu metodologa hay que utilizar significa que tienes un puesto de
responsabilidad. Escoge una metodologa moderna, bien definida, que d
respuesta a las necesidades del proyecto.

Si ocupas un puesto de decisin en un proyecto grande pero institucional, quiz de

una administracin pblica, o un proyecto estructural de una gran empresa, es
decir, uno de esos proyectos 'pesados' cuyo punto clave es el tratamiento masivo
de datos, quiz la metodologa est previamente escogida. En ese caso, hay que
limitarse a seguirla. Esto suele ocurrir en proyectos de este tipo porque involucran
a muchos actores con un perfil no tcnico, y una enorme cantidad de burocracia.
Son proyectos poco competitivos, y la inercia corporativa tiende a fijar una
metodologa para ellos -siempre la misma dentro de la misma institucin- con el fin
de uniformizar el desarrollo.
Si formas parte de un equipo de desarrollo en un proyecto grande y no
ocupas un puesto de responsabilidad, no deberas decidir qu metodologa utilizar:
alguien lo decidir por t. Si nadie toma esa decisin y en el proyecto no se escoge
una metodologa, o al menos, se fijan algunas pautas metodolgicas generales,
entonces... Mucho nimo!... el proyecto en el que ests involucrado est
destinado al fracaso. Intenta vivirlo de la mejor manera posible y trata de aprender
de la experiencia.
Si formas parte de un equipo pequeo en un proyecto pequeo, lo mejor es
consensuar la metodologa a utilizar. Incluso, combinar buenas ideas de ms de
una.

Y QU METODOLOGAS HAY?

Entre las metodologas tradicionales podemos citar:

Desarrollo de sistemas de Jackson (JSD). De los aos 80.

Ingeniera de la informacin. De los 80 tambin
Structured System Analysis and Design Method (SSADM). Tambin de los
80. Muy popular en Europa, ya que tiene su origen el Reino Unido.
Nuestra querida metodologa METRICA, promovida por el Ministerio de las
Administraciones Pblicas. Algunas, como las dos primeras (Jackson, Ingeniera
de la informacin), tienen un inters principalmente histrico. Otras, como SSADM
 o MTRICA, tienen cierta vigencia, en especial en lo que concierne a proyectos
pblicos.

Entre las metodologas modernas -unas ms, otras menos- se puede destacar:

Rapid Application Development (Desarrollo rpido de aplicaciones - RAD).

Scrum
Extreme programming. (Programacin extrema - XP)
Rational Unified Process. (Proceso Racional Unificado - RUP)
Agile Unified Process. (Proceso gil Unificado - AUP)

http://www.inen.sld.pe/portal/documentos/pdf/educacion/140715_Aula%20Historia
%20Natural%20del%20Cancer-1.pdf