Desarrollo de Software

Metodologías de desarrollo de software

Introducción
El desarrollo del software puede ser un tema bastante complejo si así lo queremos, este día
vamos a tratar de reducir esta complejidad a algo comprensible en unas líneas.

Al momento de definir software podríamos verlo como una herramienta que nos sirve para
agilizar nuestro trabajo, en los juegos que usamos en Facebook, las aplicaciones de nuestro
Smartphone, todo lo que usamos en la computadora fue creado por un equipo de desarrollo,
pequeño, grande, distribuido o local, pero la pregunta que nos plantearemos es: Que hay
detrás de este herramienta, como se construyó esta aplicación Es claro que hay un gran
trabajo detrás de cada botón, detrás de cada información que mandamos a guardar.

Como todo proyecto el software tiene un ciclo para desarrollarse y consta de una serie de
pasos que se van completando en diferentes tiempo; este ciclo de desarrollo de software
depende directamente de la metodología que utilizamos para este desarrollo, y no es más que
una serie de pasos/tareas que tenemos que seguir como en cualquier otro proyecto, no hay
nada escondido, nada mágico excepto la gran mente del equipo de desarrollo y las creaciones
para tener una experiencia única al utilizar la aplicación o el paquete de software.

Antes de entrar en más detalle, debemos mencionar que las metodologías para el desarrollo
del software son independiente de la tecnología que usemos para el desarrollo del mismo.

Dentro de los ciclos más conocidos se utilizan: waterfall, test driven development, agile
methodologies, el día de hoy describiremos scrum que pertenece a las metodologías agiles.

Marco teórico

Desde el punto de vista algorítmico el desarrollo de software está centrado en los

procedimientos y funciones, por tanto en cuestiones de control y descomposición de
procesos.

Se define como “un conjunto de etapas parcialmente ordenadas con la intención de lograr
un objetivo, en este caso, la obtención de un producto de software de calidad”. El proceso
de desarrollo de software “es aquel en que las necesidades del usuario son traducidas en
requerimientos de software, estos requerimientos transformados en diseño y el diseño
implementado en código, el código es probado, documentado y certificado para su uso
operativo”. Concretamente “define quién está haciendo qué, cuándo hacerlo y cómo alcanzar
un cierto objetivo” [Jacobson 1998].

Desde sus inicios en la década de 1940, escribir software ha evolucionado hasta convertirse
en una profesión que se ocupa de cómo crear software y maximizar su calidad. La calidad
puede referirse a cuán mantenble es el software, su estabilidad, velocidad, usabilidad,
comprobabilidad, legibilidad, tamaño, costo, seguridad y número de fallas o "bugs", así como,
entre muchos otros atributos, a cualidades menos medibles como elegancia, concisión y
satisfacción del cliente. La mejor manera de crear software de alta calidad es un problema
separado y controvertido cubriendo el diseño de software, principios para escribir código,
llamados "mejores prácticas", así como cuestiones más amplias de gestión como tamaño
óptimo del equipo de trabajo, el proceso, la mejor manera de entregar el software a tiempo
y tan rápidamente como sea posible, la "cultura" del lugar de trabajo, prácticas de
contratación y así sucesivamente. Todo esto cae bajo la rúbrica general de ingeniería de
software.

El término ingeniería del software apareció por primera vez en la década de 1950 y principios
de los años 1960. Los programadores siempre habían sabido sobre ingenieros civiles,
eléctricos y de computadores y debatían qué podría significar la ingeniería para el software.

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

Las metodologías de desarrollo de software tienen como objetivo presentar un conjunto de

técnicas tradicionales y modernas de modelado de sistemas que permitan desarrollar software
de calidad, incluyendo heurísticas de construcción y criterios de comparación de modelos de
sistemas.

Para tal fin se describen, fundamentalmente, herramientas de Análisis y Diseño Orientado a

Objetos (UML), sus diagramas, especificación, y criterios de aplicación de las mismas. Como
complemento se describirán las metodologías de desarrollo de software que utilizan dichas
herramientas, ciclos de vida asociados y discusión sobre el proceso de desarrollo de software
más adecuado para las diferentes aplicaciones ejemplos que se presentarán. Principalmente,
se presentará el Proceso Unificado el cual utiliza un ciclo de vida iterativo e incremental.

Kendall y Kendall
I. Identificación del problema, oportunidades y objetivos. II. Determinación de los
requerimientos de información. III. Análisis de las necesidades del sistema. IV. Diseño del
sistema recomendado. V. Desarrollo y documentación del software. VI. Pruebas y
mantenimiento del sistema. VII. Implantación y evaluación del sistema.

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

Llorens Fabregas
I. Requerimientos. II. Análisis/Diseño. III. Construcción. IV. Pruebas. V. Producción y
mantenimiento.

Jonas Montilva
I. Definir el proyecto. II. Análisis del contexto. III. Definición de los requerimientos. IV.
Diseño preliminar. V. Diseño detallado.

Roger Pressman
I. Análisis de los requerimientos del Software. II. Diseño. III. Generación de código. IV.
Pruebas. V. Mantenimiento;
EVOLUCIÓN DE LA INGENIERÍA DEL SOFTWARE
Con el transcurso de los años se han desarrollado recursos que conforman la ingeniería del
software, es decir, herramientas y técnicas de especificación, diseño e implementación del
software: la programación estructurada, la programación orientada a objetos, las
herramientas CASE, la documentación, los estándares, CORBA, los servicios web, el
lenguaje UML, etc.

En combinación con las herramientas, también se han hecho esfuerzos por incorporar los
métodos formales al desarrollo de software, argumentando que si se probaba formalmente
que los productos software hacían lo que se les requería, la industria del software sería tan
predecible como lo son otras ramas de la ingeniería.

La utilización de determinados recursos depende de la magnitud del proyecto, de la empresa

a cargo, la experiencia de los desarrolladores, el presupuesto con el que se cuenta, etc.

La ingeniería del software comprende:

 Proceso de desarrollo de software (especificación, implementación y diseño, etc…).
 Metodologías para el desarrollo de software (RUP, patrones, framework…).
 Herramientas de desarrollo de software.

Metodologías de desarrollo de software

1970
Programación estructurada sol 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

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
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. Thórisson
Agile Unified Process (AUP) desde 2005 por Scott Ambler
Programación al tiro desde 2018

¿En qué consisten las Metodologías de Desarrollo de Software?

Una Metodología de desarrollo de software, consiste principalmente en hacer uso de diversas
herramientas, técnicas, métodos y modelos para el desarrollo. Regularmente este tipo de
metodología, tienen la necesidad de venir documentadas, para que los programadores que
estarán dentro de la planeación del proyecto, comprendan perfectamente la metodología y
en algunos casos el ciclo de vida del software que se pretende seguir.

Aunque actualmente existen mucha variedad en metodologías de programación. La realidad

es que todas están basadas en ciertos enfoques generalistas que se crearon hace muchos años,
algunos tipos de metodologías de desarrollo de software que se utilizaron e inventaron al
principio de nuestra era tecnológica y son las que veremos a continuación.

¿Cuáles son modelos del Ciclo de vida del Software tradicionales?

Como les mencioné hace un momento, regularmente, cada metodología de desarrollo de
software, tiene un enfoque bien marcado, estos enfoques no son para nada nuevos y se siguen
utilizando para la planeación y desarrollo de software aún en nuestros tiempos, así que vamos
a ver cuáles son cada uno de ellos y aprenderemos cómo funcionan.

Metodologías pesadas populares

Entre las metodologías tradicionales más populares se encuentran el mencionado Rational
Unified Process (RUP) o también Microsoft Solutions Framework (MSF), que centran su
atención en mantener una documentación exhaustiva del proyecto y cumplir con el plan
previsto y definido con precisión en la fase inicial del desarrollo del proyecto. Digamos que
las metodologías tradicionales suelen enfatizar la documentación, la planificación y
seguimiento riguroso de múltiples actividades (mediante plantillas, técnicas de
administración, revisiones formales, etc.).

Aunque los modelos generalmente son realistas y están pensado para avanzar en la
construcción del software de una manera iterativa e incremental, algunas de las características
negativas dentro de estos enfoques son los altos costos de implementar cualquier cambio y
el no ofrecer una buena solución para proyectos que operan en un entorno extremadamente
incierto.

Line del tiempo

1948
Desarrollo de Kanban
El ingeniero Taiichi Ohno comienza a desarrollar Kanban en Japón dentro de Toyota.
1951
Desarrollo del primer método incremental e interativo: IIDD
Desarrollo del método Desarrollo y Diseño Interativo e Incremental (Iterative and
Incremental Design and Development, IIDD). Éste método se puede considerar como el
primero en el que se define el desarrollo incremental e iterativo y precursor de los que
vendrían después.
Entre los primeros en adoptarlo se encuentra el Departamento de Defensa de los EEUU.
William Deming el difusor del concepto de la Calidad Total, contribuyó a su expansión a
través de la divulgación del "Planificar, Hacer, Analizar y Actuar"

1955
Aplicación del IIDD al desarrollo de Software
Se comienza a utilizar el método Integrativo e incremental en la industria del software con
éxito consiguiendo aumentar la satisfacción del usuario y eliminando problemas en la gestión.

1970
Primera definición del modelo de desarrollo en cascada
Winston Royce publica el artículo "Administrando el desarrollo de sistemas de software
grandes", artículo al que se le suele atribuir la primera descripción del modelo de desarrollo
en cascada. Todavía no tenía definido su nombre ni todas las fases por las cuales lo
conocemos.

1976
Primera definición del modelo de desarrollo en cascada
Thomas Bell y T.A. Thayer utilizan por primera vez la palabra Cascada (waterfall) para el
Modelo de Desarrollo definido para proyectos grandes.

1978
Primera publicación del libro"The Toyota Production System"
Primera publicación del libro en "The Toyota Production System" de Taiichi Ohno donde
se describe el método Lean Manufacturing, revolución de Toyota en la cadena de producción

1986
Primer uso del término SCRUM en sistemas de producción
El primer registro del uso del término SCRUM como analogía del Rugby en el desarrollo. Se
realizó en el artículo “The New Product Development Game.” de la Harvard Business
Review.
Los autores, Hirotaka Takeuchi y Ikujiro Nonaka, aplicaron estas metodologías en empresas
como Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, and Hewlett-Packard.

1995
Programación por parejas (Pair Programming)
Jim Coplien y Larry Constantine introducen la idea de Programación por Parejas (Pair
Programming) de forma independiente.

1995
Creación del Método de Desarrollo de Sistemas Dinámicos (DSDM)
Método de desarrollo de sistemas dinámicos (en inglés Dynamic Systems Development
Method o DSDM, 1995).

Actualmente el método se acuerda dentro del DSDM Consortium

1995
Publicación del "The SCRUM Development Process"
Jeff Sutherland y Ken Schwaber popularizan Scrum con su artículo "The SCRUM
Development
Process" en la conferencia OOPSLA de Texas.

2002
Scrum alliance
Ken Schwaber, Mike Cohn y Esther Derby fundan la Scrum Alliance.

2002
Creación del Planning Poker
James Grenning inventa el Planning Poker.

2003
Lean Software Development
Mary and Tom Poppendieck publican el libro Lean Software Development adaptación de las
técnicas Lean Manufacturing al desarrollo de software.

2005
Agile Unified Process
Propuesto por Scott Ambler es una versión simplificada del Rational Unified Process (RUP).
El Agile Unified Process describe de forma sencilla como desarrollar sistemas de negocio
utilizando técnicas ágiles u conceptos de RUP que todavía son válidos.

De 1990 a 1999: Prominencia de Internet

El auge de la Internet condujo a un rápido crecimiento en la demanda de sistemas
internacionales de despliegue de información y correo electrónico en la World Wide Web.
Los programadores debían manejar ilustraciones, mapas, fotografías y otras imágenes, más
animación sencilla, a un ritmo nunca antes visto, con pocos métodos conocidos para
optimizar la visualización/almacenamiento de imágenes (como el uso de imágenes en
miniatura).

El crecimiento del uso del navegador, corriendo en el lenguaje HTML, cambió la manera en
que estaba organizada la visualización y la recuperación de la información. Las amplias
conexiones de red condujeron al crecimiento y la prevención de virus informáticos
internacionales en computadores con MS Windows, y la gran proliferación de correo basura
se convirtió en una cuestión de diseño importante en sistemas de correo electrónico,
inundando canales de comunicación y requiriendo de precalificación semiautomatizada.
Sistemas de búsqueda de palabra clave evolucionaron en buscadores web, y muchos sistemas
de software tuvieron que ser rediseñados, para la búsqueda internacional, dependiendo de las
técnicas de posicionamiento en buscadores (SEO). Fueron necesarios sistemas de traducción
de lenguaje natural humano para intentar traducir el flujo de información en múltiples
idiomas extranjeros, con muchos sistemas de software siendo diseñados para uso
multilenguaje, basado en conceptos de diseño de traductores humanos. Típicas bases de
usuarios de computadora con frecuencia pasaron de cientos o miles de usuarios a muchos
millones de usuarios internacionales.

De 2000 al presente: Metodologías ligeras

Artículo principal: Metodologías ligeras
Con la creciente demanda de software en muchas organizaciones pequeñas, la necesidad de
soluciones de software de bajo costo llevó al crecimiento de metodologías más simples y
rápidas que desarrollaran software funcional, de los requisitos de implementación, más
rápidos y más fáciles. El uso de prototipos rápidos evolucionó a metodologías ligeras
completas como la programación extrema (XP), que intentó simplificar muchas las áreas de
la ingeniería de software, incluyendo la recopilación de requerimientos y las pruebas de
confiabilidad para el creciente y gran número de pequeños sistemas de software. Sistemas de
software muy grandes todavía utilizan metodologías muy documentadas, con muchos
volúmenes en el conjunto de documentación; Sin embargo, sistemas más pequeños tenían
un enfoque alternativo más simple y rápido para administrar el desarrollo y mantenimiento
de cálculos y algoritmos de software, almacenamiento y recuperación de información y
visualización.

Enfoques de desarrollo de software

Cada metodología de desarrollo de software tiene más o menos su propio enfoque para el
desarrollo de software. Estos son los enfoques más generales, que se desarrollan en varias
metodologías específicas. Estos enfoques son los siguientes:

 Modelo en cascada: Framework lineal.

 Prototipado: Framework iterativo.
 Incremental: Combinación de framework lineal e iterativo.
 Espiral: Combinación de framework lineal e iterativo.
 RAD: Rapid Application Development, framework iterativo.

MÉTODOS
Un método de ingeniería de software es un enfoque estructurado para desarrollar software
cuyo objetivo es facilitar la producción de productos software de alta calidad a un coste
razonable. Indican cómo construir técnicamente el software. Los métodos abarcan un amplio
espectro de tareas que incluyen: planificación y estimación de proyectos, análisis de los
requerimientos del sistema y del software, diseño de procedimientos algorítmicos,
codificación, prueba y mantenimiento.

Los métodos de la ingeniería de software introducen frecuentemente una notación especial

orientada al lenguaje o gráfica y a un conjunto de criterios para la calidad del software.

A lo largo de los años se han ido desarrollando una gran cantidad de metodologías para
desarrollar software, a menudo vinculadas a algún tipo de organización, que además
desarrolla, apoya el uso y promueve la metodología. La metodología es a menudo
documentada en algún tipo de documentación formal.

Algunas de las metodologías más conocidas se explican a continuación.

Programación estructurada
Técnica en la cual la estructura de un programa tan solo emplea tres estructuras lógicas de
control: secuencia, selección e iteración. La programación estructurada se basa en el teorema
del programa estructurado demostrado por Böhm-Jacopini, el cual establece que cualquier
programa con una entrada y una salida exclusivamente es equivalente a un programa que
contiene solamente las estructuras lógicas mencionadas anteriormente.

Esta nueva forma de programar que dio lugar a programas fiables y eficientes, que además
estaban escritos de manera que facilitaba su comprensión posterior.

Programación orientada a objetos o POO

Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un
lenguaje diseñado en 1967 para hacer simulaciones de eventos discretos, creado por Ole-
Johan Dahl y Kristen Nygaard del Centro de Cómputo Noruego en Oslo. Simula introdujo
la noción de clases e instancias como parte de un paradigma de programación explícito. Las
ideas de Simula 67 influenciaron muchos lenguajes posteriores, incluyendo Smalltalk, CLOS,
Object Pascal, C++…

Smalltalk fue desarrollado en Xerox PARC por Alan Kay, entre otros, en la década de los 70.
Smalltalk introdujo el término POO para representar el uso de objetos y mensajes como la
base de la computación. Smalltalk fue diseñado para ser un sistema completamente dinámico
en el cual las clases se podrían crear y modificar en tiempo de ejecución en lugar de
estáticamente.

La programación orientada a objetos fue el estilo de programación dominante a principio y

mediados de los años noventa, en gran parte debido a la influencia de lenguajes como C++.
Su predominio fue consolidado gracias al auge de las interfaces gráficas de usuario, para las
cuales la programación orientada a objetos está particularmente bien adaptada. En este caso,
se habla también de programación dirigida por eventos.

Las características de orientación a objetos han sido agregadas a muchos lenguajes a lo largo
de los años, incluyendo Ada, BASIC, Fortran, Pascal, entre otros. La adición de estas
características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a
menudo a problemas de compatibilidad y en la capacidad de mantenimiento del código.

Así como la programación procedural introdujo técnicas de mejora como la programación

estructurada, los métodos modernos de diseño de software orientados a objetos incluyen
mejoras como el uso de patrones de diseño o lenguajes de modelado como UML.

Extreme Programming
Enfoque formulado por Kent Beck en 1999, que se diferencia de las metodologías
tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la
previsibilidad. Sus defensores consideran que ser capaz de adaptarse a los cambios de
requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista
que definir todos los requisitos al comienzo e invertir esfuerzos después en controlar los
cambios.

Modelos del Proceso de Desarrollo Software

No existe consenso sobre cuál es el mejor modelo del proceso software. Distintos equipos
de desarrollo pueden utilizar diferentes modelos de proceso software para producir el mismo
tipo de sistema software. Sin embargo, algunos modelos son más apropiados para producir
ciertos tipos de sistemas, de forma que si no se utiliza un modelo adecuado puede ocurrir
que el sistema software resultante sea de menor calidad.

El reparto de costes entre las distintas fases del proceso de desarrollo es difícil de determinar
dado los distintos modelos de proceso existentes. Sin embargo, en dependencia del modelo
que se adopte, al menos el 60% del coste total se emplea en la actividad de evolución del
sistema. La estimación de este porcentaje es pesimista, ya que la tasa de crecimiento de
nuevos productos software es mucho mayor que la tasa de productos software que quedan
en desuso (no tienen que ser mantenidos), por lo que el número de operaciones de
mantenimiento que se realizan sigue aumentando. El proceso de diseño software debería,
por tanto, tener en cuenta la posterior evolución del sistema.
Las características deseables de un proceso de desarrollo software son:
 Claridad: El proceso de desarrollo es claro cuando se entiende con facilidad.
 Visibilidad: Un proceso de desarrollo es visible cuando sus actividades producen
resultados claros identificables externamente.
 Facilidad de soporte: Exige disponer de herramientas CASE (Computer-Aided
Software Engineering) que den soporte a todas o alguna de las actividades del
proceso de desarrollo.
 Fiabilidad: Un proceso de desarrollo es fiable cuando es capaz de detectar posibles
errores.
 Facilidad de mantenimiento: Requiere capacidad para incorporar nuevos requisitos o
modificar alguno o algunos de los existentes.
 Rapidez: Un proceso software es rápido cuando se puede obtener, a partir de la
especificación, una implementación del sistema en un tiempo reducido.

Modelo en cascada o convencional

Tomado de otras ingenierías es el primer modelo de desarrollo software propuesto.
Ampliamente usado en la industria por su facilidad de gestión y visibilidad. En la figura 1 se
representa el secuencia miento de las actividades de este modelo de desarrollo.

Sin embargo, su principal problema reside en su poca flexibilidad al separar el proceso de

desarrollo en etapas totalmente distintas. En la práctica estas etapas no tienen fronteras tan
bien definidas, lo que hace que, en no pocas ocasiones, se solapen y compartan información.
Los principales problemas de este modelo son: dificultad para realizar prototipos, reutilizar
software y realizar pruebas sin disponer de una implementación del sistema.

Modelo evolutivo
En este modelo se entrelazan las actividades de especificación, desarrollo y validación.
Inicialmente, se desarrolla rápidamente un sistema inicial a partir de una especificación muy
abstracta. El sistema se va refinando con la información que van suministrando los clientes
y/o usuarios hasta que se obtiene un sistema final que satisfaga todas las necesidades
previstas. El sistema final obtenido puede rediseñarse para producir otro más robusto y más
fácil de mantener. En la figura 9 se esquematiza este modelo.
Existen dos tipos de procesos de desarrollo evolutivos:

Exploratorio: Su objetivo es trabajar con el cliente para identificar y construir el sistema

final a partir de una especificación informal. El resultado del proceso es el sistema final.

Prototipado desechable: Su objetivo es entender los requisitos del cliente. El resultado del
proceso es la especificación del sistema (el prototipo se deshecha).

Los principales problemas de este modelo son: escasa visibilidad; los continuos cambios que
hacen que los sistemas desarrollados estén deficientemente estructurados; y la necesidad de
disponer, en muchos casos, de un equipo de desarrollo altamente calificado. Estos problemas
hacen que la aplicación de este modelo se suela limitar a sistemas interactivos de tamaño
pequeño o mediano. La deficiente estructura dificulta las tareas de mantenimiento de ahí que
se suela aplicar a sistemas con una vida corta y a partes de grandes sistemas, especialmente a
sistemas de inteligencia artificial y a interfaces de usuario.

Modelo transformacional
Se basa en disponer de una especificación formal del sistema y en transformar, con métodos
matemáticos, esta especificación en una implementación. Si las transformaciones que se
aplican son correctas es posible asegurar que el sistema construido satisface la especificación,
es decir, es posible obtener programas correctos por construcción.

Otra de sus ventajas es la posibilidad de realizar el mantenimiento a nivel de especificación.

Por lo que es necesario disponer de una especificación inicial correcta y de diseñadores
altamente calificados. Además no existe apenas experiencia en la aplicación de este modelo
a grandes proyectos.
Modelo basado en reutilización: En este modelo se supone que alguno de los
componentes del sistema final ya existe. El proceso de desarrollo se centra en integrar las
partes ya existentes más que en construir todo el sistema desde el principio.

Las ventajas que desde un punto de vista económico puede producir este modelo
actualmente empiezan a ser estudiadas en profundidad. Prácticamente no existe experiencia
sobre el empleo de este modelo, si bien, se están haciendo numerosos estudios e
investigaciones para posibilitar su uso.

Modelo en espiral
Desarrollado por Boehm en el año 1988 con el objetivo de reunir las ventajas de los modelos
de proceso software en cascada y de prototipado. Se incluye el análisis de riesgo como una
parte importante del proceso de desarrollo software.

El modelo tiene la forma de una espiral en la que cada vuelta representa cada una de las fases
en las que se estructura el proceso software y está organizada en cuatro sectores:

1. Definición de objetivos, alternativas y restricciones de cada fase del proyecto.

2. Evaluación de alternativas y análisis de riesgos.
3. Desarrollo y validación. Se elige el modelo de proceso de desarrollo que se considere más
adecuado.
4. Planificación de las siguientes fases del proyecto.

MODELO CARACTERISTICAS VENTAJAS DESVENTAJAS

CASCADA
Metodología del proceso:
Todo desarrollo de software es riesgoso y difícil de controlar, pero si no llevamos una
metodología de por medio, se obtiene clientes insatisfechos con el resultado y desarrolladores
aún más.
Sin embargo muchas veces no se toma en cuenta el utilizar una metodología adecuada, sobre
todo cuando se trata de proyectos pequeños de dos o tres meses.

Con relación a los proyectos que se desarrollan con mayor envergadura, hay si se toma el
sentido de basarse en una metodología de desarrollo y se empieza a buscar cual sería la más
apropiada para dicho caso. A fin de cuenta no encontramos muchas veces la meas adecuada
y se termina por hacer un diseño propio de metodología, por supuesto no está mal siempre
y cuando sirva para alcanzar el objetivo.

Muchas veces se realiza el diseño del software de manera rígida, tal cual como el cliente lo
solicito, de esa manera cuando el cliente en la "etapa de prueba" solicita un cambio se hace
muy difícil de realizarlo, pues si se hace altera las cosas que no se habían previsto, y este es
uno de los factores que atrasan el proyecto y crea incomodidad al desarrollador y en muchas
oportunidades no llegan a cumplir con el cambio solicitado, esto conlleva malestar en el
cliente puesto que no se sido tomado en cuenta su pedido; para evitar estos incidentes se
debe llegar a un acuerdo formal con el cliente al inicio del proyecto de manera que no
perjudique el desarrollo del mismo.

Muchas veces los usuarios finales se dan cuenta que dejaron de mencionar algunas cosas y lo
manifiestan en la etapa inicial del proyecto cuando se le muestra el prototipo del mismo.

ALGUNAS Metodologías conocidas:

• La metodología RUP es la más adaptable para proyectos de largo plazo.
• La metodología XP en cambio, se recomienda para proyectos de corto plazo.
• La metodología MSF se adapta a proyectos de cualquier dimensión y de cualquier
tecnología.
• Se puede decir además que lo más importante antes de elegir la metodología que se
debe usar para implementar el software, es determinar el alcance que tendrá y luego
de allí ver cuál es la que más se acomoda a la aplicación.

Fases
RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en número
variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas
actividades.

• Inicio
Esta fase tiene como propósito definir y acordar el alcance del proyecto con los
patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general
de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.

 Revisión de información del cliente y los objetivos del proyecto

La primera tarea en la creación de una aplicación de software consiste en captar información
y generar el diseño de alto nivel según los requisitos del cliente. A medida que el diseño de
alto nivel se traduce en documentación más específica y más centrada técnicamente, se
requiere información de implementación técnica para proporcionar comentarios sobre las
capacidades del hardware y la implementación práctica del diseño. Esto puede ayudar a evitar
sorpresas posteriores, y garantiza que el diseño final del software pueda implementarse en un
tiempo razonable y en el hardware y la infraestructura disponibles.

• Elaboración
En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura
base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso
seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.

 Escribir código para componentes

Esta es la actividad central del desarrollo y la actividad que impulsa todo el proceso de
creación de software. La persona que crea el código usará una especificación o lista de
requisitos que describen lo que debe realizar un componente o sección de la aplicación, los
resultados que debe generar y la forma en que se comunicará con otras partes de la aplicación.
Esta especificación puede ser en una de muchas formas diferentes, como modelos escritos
en un lenguaje de modelado estándar, descripciones de la funcionalidad o simplemente
diagramas en una pizarra.

Durante el desarrollo, se usan las funciones del lenguaje de programación elegido para crear
archivos de código fuente que contienen la serie requerida de instrucciones que ejecutará el
equipo.

Básicamente, este código asimilará un conjunto de valores de entrada, realizará algún

procesamiento con estos valores y generará los resultados. Para lograr esto puede hacer uso
de otros componentes y funciones dentro del software, y también puede hacer uso de
bibliotecas de códigos y funciones que fueron escritos por el equipo u obtenidos de
proveedores externos. Las herramientas y entornos de desarrollo que se usen, como
Microsoft Visual Studio (en la figura 2), ayudan a facilitar la escritura de código al sugerir los
nombres de objetos y variantes, al comprobar la sintaxis para garantizar que se compilará
correctamente y al indicar errores.

• Construcción
El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben
clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones
realizados por los usuarios y se realizan las mejoras para el proyecto.

 Revisión de códigos con miembros del equipo

Para cualquier sección de código que los desarrolladores escriban, rara vez hay sólo una
solución correcta única. Las habilidades de un desarrollador radican en utilizar las
características y capacidades de los lenguajes de código para construir código que realice la
tarea requerida, y puede haber muchas maneras distintas de lograrlo. Distintos
desarrolladores pueden utilizar hábilmente diferentes enfoques y diferentes combinaciones
de instrucciones de código.

Con una revisión del código por parte de pares y gerentes se realizan dos tareas vitales. En
primer lugar, reúne los puntos de vista y las opiniones de varios desarrolladores que pueden
ofrecer enfoques alternativos, señalar errores desapercibidos o sugerir mejoras al código.
Esto ayuda a optimizar la eficiencia y el rendimiento de los códigos. En segundo lugar, ayuda
a ampliar el conocimiento de todos los miembros del equipo al compartir experiencia, lo cual
mejora el desempeño de todo el equipo con el tiempo.

 Compilación y prueba del código

Según el lenguaje de código que se use, el desarrollo implica la compilación del código fuente
para convertirlo en una forma que el equipo informático pueda ejecutar. Generalmente las
herramientas y entornos de desarrollo realizarán esta tarea. Un miembro del equipo
(habitualmente el creador inicial, luego los evaluadores) ejecuta después el código para
garantizar que funcione como debería. Si el equipo utiliza un enfoque Test Driven Design
(TDD), un miembro del equipo habrá escrito anteriormente pruebas unitarias que pueden
ejecutarse para garantizar que el código se ejecuta correctamente y genera los resultados
requeridos.

La compilación, ejecución y prueba del código es un proceso iterativo que se produce

mientras el código se crea. Habitualmente, se crea primero el código mínimo básico para
probar el concepto, asegurando que se compila y ejecuta, y luego se agrega o actualiza código
progresivamente para maximizar el rendimiento y la eficiencia y, a la vez, confirmar que
genera los resultados correctos.

 Registro y actualización del repositorio de códigos

En la mayoría de los proyectos medianos y grandes se usa un sistema de información de
equipo y repositorio de códigos como Team Foundation Server (TFS) para almacenar
códigos, documentos e información sobre el proyecto. El desarrollador registra el código que
creó para que forme parte del proyecto general y pueda compilarse en la solución completa
durante las compilaciones regulares.

Habitualmente estas compilaciones se realizan a diario, y el equipo de prueba trabaja con la

nueva compilación cada día para confirmar que los errores informados existentes se hayan
resuelto y para ubicar cualquier defecto nuevo.

El repositorio por lo general incluirá elementos de trabajo e informes. El desarrollador

actualiza elementos de trabajo relevantes para el código creado, marca los elementos de
trabajo para errores que se hayan resuelto y agrega otra información relevante para la tarea
que resultará útil a otros miembros del equipo, incluidos el equipo de prueba y el equipo de
documentación. El equipo puede ejecutar informes basados en estos elementos de trabajo
para supervisar el progreso del proyecto y descubrir cualquier problema en curso. En la figura
4 se muestra Microsoft Visual Studio Team Foundation Server.
• Transición
El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales,
ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los
usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla
con las especificaciones entregadas por las personas involucradas en el proyecto.

 Implementación de cambios y depuración y corrección de errores

Si las pruebas dan como resultado errores que se informan en el código, el desarrollador debe
volver atrás, encontrar la causa de esos errores y luego cambiar el código para resolverlos. La
depuración es la tarea de localizar el origen de los errores, que se puede producir en cualquier
parte del código y que sólo puede surgir en el punto descubierto durante las pruebas. La
depuración a veces se considera como un “arte secreto” porque requiere experiencia y
también un enfoque lógico, especialmente si el error sólo aparece intermitentemente o es
difícil de reproducir.

Sin embargo, las herramientas y entornos de desarrollo modernos como Visual Studio
incluyen características que permiten a los miembros del equipo recorrer el código mirando
los valores de las variables y observando cómo cambian. Esto hace que la localización de
errores sea un proceso mucho más fácil y más lógico. Otras características y herramientas
que proporcionan una lista de los procedimientos de código que se ejecutan y la forma en
que el procesador del equipo informático los maneja, ayudan al equipo a localizar errores.
Además, el equipo puede agregar instrumentación (como código para escribir eventos en
archivos de registro) que supervisará el código mientras se ejecuta y ayudará a localizar
errores.
También es común que durante las pruebas de aceptación el cliente solicite cambios en
características de la aplicación a fin de ajustar el software exactamente a sus requisitos. El
desarrollador implementará estos cambios, generalmente según una revisión de los requisitos
y un estudio detallado del impacto que los cambios pueden tener sobre el resto del software.
Un buen diseño original que separe correctamente las responsabilidades de cada componente
facilitará la implementación de cambios sin afectar otras partes de la aplicación.

El ciclo de vida de desarrollo de software es un proceso iterativo, y muchas de las tareas

descritas se repiten a medida que el desarrollo continúa. Por ejemplo, durante el desarrollo
el equipo puede crear varias versiones completadas por partes del software o los
componentes y luego mejorarlas o cambiarlas según los resultados de las pruebas y los
comentarios del cliente.

 Trabajar como parte de un equipo

Algunos desarrolladores trabajan solos o en grupos pequeños, mientras que otros trabajan
en equipos organizados grandes. Como individuo o en un equipo pequeño, el desarrollador
puede ser responsable de todas las tareas del ciclo de vida de desarrollo, incluidos diseño,
pruebas, implementación y mantenimiento. En los equipos grandes normalmente hay grupos
separados responsables del diseño, pruebas, implementación y mantenimiento, y así el
desarrollador se centrará más en la tarea central de escribir código.

Los equipos más grandes por lo general operan de forma estructurada para poder administrar
y supervisar el ciclo de vida de desarrollo y el proceso de desarrollo. Existen muchos
enfoques distintos para administrar el desarrollo de software en un equipo, incluido el ciclo
tradicional orientado al diseño que se basa en tareas planeadas previamente que se siguen una
a otra (el enfoque de “cascada”) y el enfoque más orientado a comentarios donde la
planeación se ejecuta en paralelo con tareas de desarrollo según la información regular del
cliente (el enfoque “ágil”). En la figura 6 se muestran estos dos enfoques principales para el
desarrollo de software.

Independientemente del enfoque de desarrollo que se use, es esencial la buena comunicación

entre los miembros del equipo y los administradores de proyectos. Aunque muchos equipos
se ubican en un solo lugar, cada vez es más común que estos incluyan miembros ubicados
geográficamente en otro lugar y que en las reuniones se utilicen instalaciones para teléfono y
videoconferencia. Las reuniones programadas en forma regular a las que asisten todos los
miembros del equipo, incluidos desarrolladores, diseñadores de software (arquitectos),
evaluadores y administración de proyectos, se usan para analizar el progreso, para planear
actividades y para recibir comentarios de otros miembros del equipo y clientes. Esto garantiza
que los desarrolladores estén bien informados sobre la evolución inevitable del diseño de
software y que puedan actuar según los comentarios regulares que pueden afectar la
implementación del software.

Fases del proceso de desarrollo de software

Análisis de requisitos
Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras
que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de
habilidad y experiencia en la ingeniería de software para reconocer requisitos incompletos,
ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en
el documento ERS,

Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por
varios estándares, tales como CMM-I. Asimismo, se define un diagrama de
Entidad/Relación, en el que se plasman las principales entidades que participarán en el
desarrollo del software. La captura, análisis y especificación de requisitos (incluso pruebas de
ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos
finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún
no está formalizada, ya se habla de la Ingeniería de Requisitos. La IEEE Std. 830-1998
normaliza la creación de las Especificaciones de Requisitos Software (Software Requirements
Specification).

Diseño y arquitectura
Se refiere a determinar cómo funcionará de forma general sin entrar en detalles. Consiste en
incorporar consideraciones de la implementación tecnológica, como el hardware, la red, etc.
Se definen los casos de uso para cubrir las funciones que realizará el sistema, y se transforman
las entidades definidas en el análisis de requisitos en clases de diseño, obteniendo un modelo
cercano a la programación orientada a objetos.

Programación
Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software,
pero no es necesariamente la porción más larga. La complejidad y la duración de esta etapa
está íntimamente ligada al o a los lenguajes de programación utilizados.

Pruebas
Consiste en comprobar que el software realice correctamente las tareas indicadas en la
especificación. Una técnica de prueba es probar por separado cada módulo del software, y
luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica
el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó,
idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus
propias pruebas. En general hay dos grandes formas de organizar un área de pruebas, la
primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas,
de esta forma se evalúa que la documentación] entregada sea de calidad, que los procesos
descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y
como están descritas. El segundo enfoque es tener un área de pruebas conformada por
programadores con experiencia, personas que saben sin mayores indicaciones en qué
condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal
inexperto no consideraría.

Documentación
Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión
del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario,
manuales técnicos, etc.; todo con el propósito de eventuales correcciones, usabilidad,
mantenimiento futuro y ampliaciones al sistema.

Mantenimiento
Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto
puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de
toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de
este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el
sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la Ingeniería
civil, Arquitectura y trabajo de construcción es dar mantenimiento.

Se puede decir que con la mejora continua garantiza la calidad del producto, ya que el estarla
aplicando día con día es la mejor decisión que puede llegar a tener cualquier empresa, porque
de esta manera evita grandes problemas en la elaboración o desarrollo de los productos. Esto
es fundamental para todas las empresas ya que se vuelven competitivas, con mayor
productividad y eficiencia. No hay que olvidar que la mejora se da porque el cliente es el rey
y hay que satisfacer todas y cada una de sus necesidades siempre garantizando la calidad.

Importancia
Actualmente la transición que estamos viviendo hacia una sociedad del conocimiento ha
cambiado profundamente las relaciones entre las personas, empresas y gobiernos: las
empresas usan la red para comunicarse con los clientes, utilizan también herramientas de
gestión del conocimiento para hacer más eficientes, los gobiernos mejoran su presencia en
Internet y los servicios a los ciudadanos a través de la red, los usuarios usan las herramientas
para sus relaciones personales, etc. Se va de forma imparable hacia una sociedad altamente
interconectada donde el eje fundamental es la información.

El software es el intermediario cada vez más grande entre la información y la inteligencia

humana. De la misma manera que preocupa para poder acceder a la información, si existe la
censura, es tema de preocupación de quien controla este intermediario y las garantías de su
transparencia y confiabilidad.
En principio, el software es un programa informático o conjunto de ellos que tiene un fin
determinado, es el de procesar los textos que usamos, el controlador de grabación de nuestros
espacios favoritos o las aplicaciones que permiten operar un teléfono móvil.

Está compuesto por un conjunto de instrucciones que el usuario realiza para ejecutar una
función específica. Normalmente los programadores escriben en un lenguaje en el que todos
pueden entender y que después es traducido al lenguaje binario el único que las máquinas
entienden. El conjunto de órdenes en el lenguaje que todos trabajan se llaman código fuente.

Si no se accede al código solo se puede usar el programa, no se puede ver cómo está hecho
o introducir comentarios. Un ejemplo muy utilizado es el de la receta de cocina, en el que el
código fuente son las instrucciones que permite confeccionar un plato. Sin la receta solo se
pude degustar el plato, pero no se sabe si se le añade algo vaya en contra de algunos de esos
ingredientes ya que se desconocen su composición y proporción. En este sentido, el código
fuente juega un papel fundamental en la manera como se debe entender el software.

Se podrían poner varios ejemplos para entender dicha importancia. A finales de los 90 se
pudo ver en todo el mundo la preocupación por parte de empresa y gobiernos por las
consecuencias que podían tener el llamado efecto 2000. El famoso error informático era
debido al hecho de que muchos programas almacenaban la parte de la fecha correspondiente
al año utilizando únicamente dos dígitos, de tal manera, que después del año 99 (el 1999)
podíamos pasar al año 00 (¿año 2000 o año 1900?)
Causando todo tipo de errores en el cálculo de período de tiempo.

Los ordenadores de las empresas eléctricas, centrales nucleares, sistema de control de

aviación, bancos y en general, todo el software de uso cotidiano, tuvieron que ser revisados.
Finalmente algunas aplicaciones fueron corregidas, otras ya funcionaban correctamente y no
hubo que lamentar ninguna catástrofe, pero hubo miles de predicciones apocalípticas sobre
las consecuencias que se podría llegar a obtener este error, así podría haber sido si no se
hubiera reparado a tiempo.

Es por eso, el software tiene un papel muy importante en la sociedad sobre manera garantizar
métodos trasparentes en sus diferentes fases de producción y explotación.

HERRAMIENTAS
Suministran un soporte automático o semiautomático para los métodos. Cuando se integran
las herramientas de forma que la información creada por una herramienta pueda ser usada
por otra, se establece un sistema para el soporte del desarrollo del software llamado ingeniería
de software asistido por computadora (Computer Aided Software Engineering o CASE).

Ya en los años 70 un proyecto llamado ISDOS (Information System Design and

Optimization System) diseñó un lenguaje, y por lo tanto un producto, que analizaba la
relación existente entre los requisitos de un problema y las necesidades que éstos generaban,
el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la aplicación
que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer).
PSL se empleaba para expresar requisitos de un sistema mediante un lenguaje formal. El
lenguaje se expresaba empleando objetos y relaciones entre ellos. Una vez compilado y sin
errores, el fichero generado era recibido por la aplicación PSA, que generaba una base de
datos con la información obtenida y permitía manipular el contenido y generar informes,
entre otras cosas.

Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos
proyectos informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el
año 1984 y trabajaba bajo una plataforma PC.

Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la
que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar
con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban
todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos
utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el
mercado de diversas herramientas más específicas para cada fase del ciclo de vida del
software. Por ejemplo, algunas herramientas CASE son MagicDraw (diseño), ArchE
(arquitectura) o MetaEdit (desarrollo).

Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas CASE se
pueden clasificar teniendo en cuenta los siguientes parámetros:

1. Las plataformas que soportan.

2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.
3. La arquitectura de las aplicaciones que producen.
4. Su funcionalidad.
5. La siguiente clasificación es la más habitual basada en las fases del ciclo de desarrollo
que cubren:

 Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación,

análisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML.
 Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño
de la aplicación.
 Lower CASE (L-CASE), herramientas que semi-automatizan la generación de
código, crean programas de detección de errores, soportan la depuración de
programas y pruebas. Además automatizan la documentación completa de la
aplicación.

Conclusiones
Así que ahora ya sabes muy bien cómo funciona cada una de las metodologías básicas y de
los procesos o fases que conlleva cada una de ellas, así como las metodologías ágiles y las
ventajas de utilizarlas, por supuesto que hoy en día son las más usadas. Sin embargo algunas
metodologías existentes actualmente que no son tan famosas, están basadas en estas
principalmente, razón por la cual no se les hace mucha mención. De cualquier forma, al final
del día, tanto tu, como tu equipo de desarrollo de sistema, deberán hacer el análisis inicial y
determinar bajo que esquema quieren empezar a desarrollar. Si formas parte de una agencia
de desarrollo de software, todo dependerá del tipo y tamaño de software que el cliente
requiera, si no es así, entonces solamente deberás elegir uno para establecer cierto orden en
tus procesos o tomar fases de varios procesos como el de cascada y prototipos y crear tu
propia metodología, pues esto es precisamente lo que muchos hacen.

Fuentes bibliográficas
https://comunidad.iebschool.com/rnemtz/2013/05/16/introduccion-al-desarrollo-del-
software/
file:///D:/Descargas/art%C3%ADculo_redalyc_475748670010.pdf
https://es.wikipedia.org/wiki/Historia_de_la_ingenier%C3%ADa_del_software
https://histinf.blogs.upv.es/2010/12/28/ingenieria-del-software/
https://es.wikiversity.org/wiki/Metodolog%C3%ADas_pesadas_de_desarrollo_software
http://www.laboratorioti.com/2014/02/17/historia-de-las-metodologias-agiles/
https://es.wikiversity.org/wiki/Metodolog%C3%ADas_pesadas_de_desarrollo_software
https://okhosting.com/blog/metodologias-del-desarrollo-de-
software/#En_que_consisten_las_Metodologias_de_Desarrollo_de_Software
https://www.monografias.com/trabajos39/desarrollo-del-software/desarrollo-del-
software2.shtml#metodol
https://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software
https://es.slideshare.net/juanpabloov18/desarrollo-de-software-orienta-a-objetos
https://www.academia.edu/5130339/MODELO_CARACTERISTICAS_VENTAJAS_DESVENTAJAS_
CASCADA
http://www.eumed.net/tesis-doctorales/2014/jlcv/software.htm