Está en la página 1de 42

UNIVERSIDAD DE ORIENTE

VICERRECTORADO ACADÉMICO

CONSEJO DE ESTUDIOS DE POSTGRADO

POSTGRADO EN INFORMÁTICA GERENCIAL

NÚCLEO MONAGAS

Metodologías para el Desarrollo de


Software

Profesor: Maestrantes:
Dr. Juan Oliveira Ing. Francisco Antequera
Ing. Jesús Mota
Ing. José Figueroa
Ing. Ruth Reyes
Ing. Yanired Urbina

Maturín, Junio 2018


INDICE
INDICE ......................................................................................................................................................... 1
INTRODUCCION ........................................................................................................................................ 2
1. Definición de Metodología de desarrollo de software: ............................................................................. 3
2. Clasificación de las metodologías: ............................................................................................................ 5
2.1. Metodología estructurada: .................................................................................................................. 5
2.1.1. Metodologías orientadas a procesos (Flujo de datos):................................................................. 6
2.1.2. Metodologías orientadas a Estructuras de datos: ......................................................................... 6
2.2. Metodología orientada a objetos: ....................................................................................................... 8
2.3 Metodologías para sistemas en tiempo real. ...................................................................................... 12
2.4 Metodologías Ágiles.......................................................................................................................... 13
2.4.1 SCRUM ...................................................................................................................................... 13
2.4.2. Extreme Programming (XP): ..................................................................................................... 14
2.4.3. Crystal Clear:............................................................................................................................. 14
2.5. Metodología para desarrollos de aplicaciones WEB ........................................................................ 15
2.5.1 IWeb ........................................................................................................................................... 15
2.6 Metodologías para la construcción de Sistemas Multimedia ............................................................ 17
2.6.1 OOHDM ..................................................................................................................................... 18
2.7. Metodologías por autores ................................................................................................................. 20
2.7.1. Kendall & Kendall..................................................................................................................... 20
2.7.2 Roger Pressman: ......................................................................................................................... 24
2.7.3 James Senn ................................................................................................................................. 25
2.7.4 Jonas Montilva ........................................................................................................................... 28
2.7.5 Llorens Fabregas ........................................................................................................................ 31
3. Modelos o enfoques para el desarrollo de software ................................................................................ 34
3.1 Cascada.............................................................................................................................................. 34
3.2 Desarrollo Evolutivo (Espiral). ......................................................................................................... 36
3.3 Metodología de Prototipo .................................................................................................................. 38
CONLUSIONES ......................................................................................................................................... 39
REFERENCIAS WEB ................................................................................................................................ 40
REFERENICAS BIBLIOGRAFICAS ........................................................................................................ 41

1
INTRODUCCION

Una metodología puede ser definida como la utilización de un conjunto de procedimientos,


técnicas y herramientas de manera racional, ordenada y organizada a fin de lograr un objetivo en
particular, en tal sentido su utilización, contribuyen para que los investigadores puedan alcanzar
las metas que se hayan establecido, para lo cual deben seguir una secuencia de acciones definidas
por la metodología que implemente.

El desarrollo de software, no se escapa de la situación descrita anteriormente, es decir, para


el equipo que se encarga de ejecutar esta actividad es importante determinar la metodología que
utilizará para culminar exitosamente el desarrollo, desde este punto de vista, las metodologías
representan un marco de trabajo que permiten estructurar y controlar todo el proceso de desarrollo
de sistemas, desde su planificación hasta la puesta en producción.

Es importante destacar que las metodologías de desarrollo de software están basadas en el


ciclo de vida de los sistemas de información, el cual consta de varias fases, dependiendo el autor,
pero que en general abarca análisis, diseño, implementación y mantenimiento. Desde este punto de
vista se tienen distintas metodologías planteadas por autores como James Senn, Roger Preesman,
Kendall & Kendall, Llorens Fabregas, Jonas Montilva, entre otros.

Por otra parte, cada metodología utiliza su propio enfoque o modelo para el desarrollo de
software, los cuales pueden ser de tipos lineales, iterativos o mixtos. Se pueden identificar dentro
de estos modelos: cascada, estructurado, espiral, prototipo, Desarrollo Rápido de Aplicación
(RAD) y programación Extrema (XP). Adicionalmente se pueden mencionar otros enfoques como
lo son: Desarrollo Orientado a Objetos y el Proceso Unificado de Desarrollo.

De acuerdo a lo planteado anteriormente, por medio del presente trabajo de investigación


se realizará la descripción de diferentes metodologías, por autores, así como enfoques o modelos
que pueden ser utilizados para implementarlos dentro del desarrollo de software.

2
1. Definición de Metodología de desarrollo de software:

La palabra Metodología hace referencia a un conjunto de procedimientos lógicos utilizados


para alcanzar uno o varios objetivos, o bien, el estudio y elección de un método pertinente y
adecuadamente aplicable para alcanzar determinado objetivo. Estas toman como base un modelo
de desarrollo para definir toda su estructura, mientras que éstas se convierten en el elemento de
control y administración sobre un proceso determinado.

Por lo que, se puede decir que una Metodología de desarrollo de software, consiste
principalmente en hacer uso de diversas herramientas, técnicas, métodos y modelos para el
desarrollo, implementación y mantenimiento de un producto de software desde que surge la
necesidad del producto hasta que se cumple el objetivo por el cual fue creado. 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.

Lo que se busca al implementar una metodología es prolijidad, corrección y control en cada


etapa del desarrollo de un programa. Lo que permitirá una forma sistemática de obtener un
producto correcto y libre de errores.

Esto nace cuando surge la necesidad de adaptar los sistemas informáticos a las exigencias
del mercado, siendo el programador quien atendiendo estos requerimientos comenzaba la dura
tarea de codificar. Esta tarea no estaba administrada, supervisada o gestionada de ningún modo,
por lo que se iba corrigiendo a medida que surgían los errores, tantos los lógicos provenientes de
la codificación, como los de Requerimientos solicitados por el cliente o usuario final. En la década
de 1970 los programas fueron creciendo en complejidad, por lo que la antigua técnica de codificar
y corregir terminó quedando obsoleta. Esta técnica se basaba en requerimientos ambiguos y sin
especificaciones puntuales. Al no seguir normas para el proyecto, el cliente o usuario sólo impartían
especificaciones muy generales del producto final. Se programaba, se corregía, y se volvía a
programar sobre la misma marcha del proyecto. El ciclo de vida de este tipo de proyectos finalizaba
cuando se satisfacían las especificaciones, no sólo las primeras por las cuales nació la necesidad
del programa, sino también todas aquellas que fueron surgiendo sobre la marcha. No se tomaban
en cuenta cosas como la calidad, la satisfacción, la competitividad, los beneficios etc. Por esto la

3
importancia, ya que si no se desarrolla a partir de una metodología, el resultado final será
impredecible y no se podrá controlar el avance del proyecto.

Una metodología de desarrollo de software brinda un marco para construir aplicaciones de


manera eficiente y rigurosa, garantizando un producto cercano al esperado, permitiendo además
dividir un gran proyecto en módulos más pequeños llamados etapas, y las acciones que
corresponden en cada una de ellas, nos ayuda a definir entradas y salidas para cada una de las etapas
y, sobre todo, normaliza el modo en que administraremos el proyecto.

Desde un punto de vista general puede considerarse que el ciclo de vida de un software
tiene cinco etapas, las cuales son:

1. Inicio: Nace de la idea, se definen los objetivos del proyecto y los recursos necesarios para su
ejecución partiendo de un estudio preliminar y del levantamiento de la información actual.
Implica el hacia dónde se quiere llegar, definiendo el problema.
2. Planificación: Se crea un planeamiento detallado que guíe la gestión del proyecto, temporal y
económicamente; determinación de requerimientos, elaboración de prototipo del sistema.
3. Implementación: Desarrollo del software, prueba del sistema, se acuerdan el conjunto de
actividades que componen la realización del producto.
4. Puesta en producción: Etapa de definición y donde se le presenta al cliente o usuario final,
sabiendo que funciona correctamente y responde a los requerimientos solicitados en su
momento.
5. Control en producción: control del producto, analizando cómo el proceso difiere o no de los
requerimientos originales e iniciando las acciones correctivas si fuesen necesarias. Cuando se
decide que se debe corregir el producto, se hace referencia a pequeñas desviaciones de los
requerimientos originales que puedan llegar a surgir en el ambiente productivo.

Como toda disciplina, el desarrollo de software madura y con el tiempo genera nuevos
mecanismos para su propia optimización. De esos esfuerzos surgen las metodologías de desarrollo
de software: marcos de trabajo utilizados para estructurar, planificar y controlar el proceso de
desarrollo de un sistema de información.

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

2. Clasificación de las metodologías:

Tomando en cuenta la definición estudiada anteriormente donde las metodologías no son


paradigmas o modelos de programación que indican pautas de comportamiento o ideas
estructurales sencillas en el proceso de desarrollo, sino que, son la manera en la que debe realizarse
cada tarea del ciclo para un proyecto concreto; se puede, que existen dos Metodologías Generales
que tienen analogía en la práctica con los paradigmas de programación:

2.1. Metodología estructurada:

Propone la creación de modelos del sistema que representan los procesos, flujos y la
estructura de los datos de una manera descendiente (top-down) tanto en las funciones del sistema,
en la estructura de los datos o en ambos aspectos. Cada función a realizar por el sistema se
descompone en pequeños módulos individuales. Es más fácil resolver problemas pequeños, y luego
unir cada una de las soluciones, que abordar un problema grande.

La metodología estructurada identifica durante el análisis las funciones del sistema,


mientras que durante el diseño identifica los datos. Utiliza como mecanismo para el análisis el flujo
de datos y la estructura de datos, de donde nacen las tendencias: Metodologías orientadas a
procesos (Flujo de Datos) y Metodologías orientadas a Estructuras de datos.

Las herramientas asociadas a estas metodologías durante las fases de requisitos y análisis
para describir el sistema lógico son:

 Diagramas de flujo de datos. (DFD).


 Diagramas de Entidad-Relación. (Definición de almacenes de datos para el DFD).
 Diccionario de datos.
 Descripciones funcionales.
 Lenguaje natural estructurado.
 Tablas de decisión.

5
Dentro de las desventajas de las metodologías estructuradas se tienen:

 No dan respuesta fácil a cambios en el dominio del problema.


 Son inadecuadas para dominios de problemas de naturaleza concurrente y de tiempo real.
 No ofrecen medidas para garantizar el principio de ocultación de información.

2.1.1. Metodologías orientadas a procesos (Flujo de datos):

Utilizan un enfoque de descomposición descendente para evaluar los procesos del problema
y los flujos de datos con los que están conectados. La ingeniera del software está fundamentada
sobre el modelo básico de entrada/proceso/salida de un sistema por lo que los datos se introducen
en el sistema y el mismo responde ante ellos transformándolos para obtener las salidas. Como
ejemplos de éste grupo de metodologías se destacan:

 Merise
 YSM (Yourdon Systems Method)
 SSADM (Structured Systems Analysis and Design Method)
 METRICA v.2.1
 METRICA v3.0
 Yourdon / de Marco.
 Gane / Sarson.
 Yourdon / Myers /Constantine.
 Page / Jones.
 SADT (Structured Analysis and Design Technique)
 RDD (Requirement Driven Design)

2.1.2. Metodologías orientadas a Estructuras de datos:

También llamadas metodologías “dirigidas por los datos”, toman como base la idea de que
los datos, además de fluir y tener un contenido, tienen una estructura. Así, el criterio de
descomposición es la estructura de datos.

Las actividades de análisis comienzan evaluando en primer lugar los datos y sus
interrelaciones para determinar la arquitectura de datos subyacente. La orientación a

6
procesos proporciona un sistema de gestión con indicadores y facilita la toma de decisiones
basada en datos fiables. Permite la asignación equilibrada de recursos a las actividades. Las
actividades de análisis comienzan evaluando en primer lugar los datos y sus interrelaciones para
determinar la arquitectura de datos subyacente

Cuando esta arquitectura está definida, se definen las salidas a producir y los procesos y
entradas necesarios para obtenerlas. Los datos constituyen el corazón del sistema de información,
son más estables que los procesos que actúan sobre ellos. El estudio de los procesos viene derivado
de una definición inicial de los datos (modelo de datos) constituido por el conjunto de entidades de
datos básicas y las interrelaciones entre ellas.

Estas metodologías se dividen a su vez en Metodologías Orientadas a Datos Jerárquicos y


No jerárquicos.

2.1.2.1 Metodologías Orientadas a Datos Jerárquicos:

La estructura de control del programa debe ser jerárquica y debe derivarse de la estructura
de datos. El proceso de diseño consiste en definir primero las estructuras de entrada y salida, para
posteriormente combinarlas con el fin de obtener la estructura del programa. Finalmente se ordena
la lógica procedimental para que se ajuste a esta estructura. El diseño lógico debe preceder y estar
separado del diseño físico. Algunos de estos métodos son:

 JSP (Jackson Structured Programming)


 JSD (Jackson Structured Design)
 LCP (Logical Construction Program)
 DESD (Desarrollo de Sistemas Estructurados de Datos), también conocido como
metodología Warnier-Orr
 LCS (Logical Construction Systems)

2.1.2.2 Metodologías Orientadas a Datos no Jerárquicos:

7
Los datos son la parte esencial del sistema porque son más estables que los procesos que
actúan sobre ellos. Son una representación de un modelo de datos de la organización formado por
un conjunto de entidades de datos básicas y las relaciones entre ellas. Los procesos derivan de una
definición inicial de los datos. Se destaca dentro de este tipo la metodología Ingeniería de la
Información (Information Engineering - IE) de J. Martin y C. Finkelstein, para la cual, se
identifican entidades y procesos; posteriormente se presupone una estructura jerárquica en los datos;
para posteriormente representar la estructura de los datos usando la secuencia, la selección y la
repetición. Finalmente, sSe definen métodos para transformar una estructura de datos jerárquica en
una estructura de programa.

2.2. Metodología orientada a objetos:

Se fundamenta en la integración de los dos aspectos de los sistemas de información (datos


y procesos) y a diferencia de la metodología estructurada, estas no comprenden los procesos como
funciones, sino que arma módulos basados en componentes, es decir, cada componente es
independiente del otro. Esto permite que el código sea reutilizable. Es más fácil de mantener porque
los cambios están localizados en cada uno de estos componentes.

La metodología orientada a objetos guía el proceso de construcción de software al utilizar


el Proceso Unificado además de permitir a los profesionales inmiscuidos en el desarrollo del
software expresar su trabajo en términos de diagramas al utilizar el UML. Se tienen dos enfoques
en las metodologías orientadas al objeto:

 Revolucionarios o puros: que entienden la orientación al objeto como un cambio profundo


que convierten a las metodologías estructuradas en obsoletas.
 Sintetistas o evolutivos: que piensan que el análisis y diseño estructurado constituyen la
base para el desarrollo orientado al objeto, pudiéndose combinar elementos del análisis y
diseño estructurado con los de orientación al objeto.

Características de la metodología orientada a objetos:

 Engloba una actividad de planificación arquitectónica, que agrupa capas de objetos por
nivel de abstracción.

8
 Identifica situaciones relevantes.
 Crea un prototipo de diseño y valida el prototipo aplicándolo a situaciones de uso.

Ventajas de la metodología orientada a objetos:

 Reutilización. Las clases están diseñadas para que se reutilicen en muchos sistemas. Para
maximizar la reutilización, las clases se construyen de manera que se puedan adaptar a los
otros sistemas. Un objetivo fundamental de las técnicas orientadas a objetos es lograr la
reutilización masiva al construir el software.

 Estabilidad. Las clases diseñadas para una reutilización repetida se vuelven estables, de la
misma manera que los microprocesadores y otros chips se hacen estables.

 El diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo


nivel. El encapsulamiento oculta los detalles y hace que las clases complejas sean fáciles
de utilizar.

 Un diseño más rápido. Las aplicaciones se crean a partir de componentes ya existentes.


Muchos de los componentes están construidos de modo que se pueden adaptar para un
diseño particular.

 Integridad. Las estructuras de datos (los objetos) sólo se pueden utilizar con métodos
específicos. Esto tiene particular importancia en los sistemas cliente-servidor y los sistemas
distribuidos, en los que usuarios desconocidos podrían intentar el acceso al sistema.

 Mantenimiento más sencillo. El programador encargado del mantenimiento cambia un


método de clase a la vez. Cada clase efectúa sus funciones independientemente de las demás.

 Una interfaz de pantalla sugestiva para el usuario. Hay que utilizar una interfaz de usuario
gráfica de modo que el usuario apunte a iconos o elementos de un menú desplegado,
relacionados con los objetos. En determinadas ocasiones, el usuario puede ver un objeto en
la pantalla. Ver y apuntar es más fácil que recordar y escribir.

9
 Interacción. El software de varios proveedores puede funcionar como conjunto. Un
proveedor utiliza clases de otros. Existe una forma estándar de localizar clases e interactuar
con ellas. El software desarrollado de manera independiente en lugares ajenos debe poder
funcionar en forma conjunta y aparecer como una sola unidad ante el usuario.

 Computación de distribución masiva. Las redes a nivel mundial utilizarán directorios de


software de objetos accesibles. El diseño orientado a objetos es la clave para la computación
de distribución masiva. Las clases de una máquina interactúan con las de algún otro lugar
sin saber donde residen tales clases. Ellas reciben y envían mensajes orientados a objetos
en formato estándar.

 Mayor nivel de automatización de las bases de datos. Las estructuras de datos (los objetos)
en las bases de datos orientadas a objetos están ligadas a métodos que llevan a cabo acciones
automáticas. Una base de datos OO tiene integrada una inteligencia, en forma de métodos,
en tanto que una base de datos relacional básica carece de ello.

 Migración. Las aplicaciones ya existentes, sean orientadas a objetos o no, pueden


preservarse si se ajustan a un contenedor orientado a objetos, de modo que la comunicación
con ella sea a través de mensajes estándar orientados a objetos.

 Mejores herramientas CASE. Las herramientas CASE (Computer Aided Software


Engineering, Ingeniería de Software Asistida por Computadora) utilizarán las técnicas
gráficas para el diseño de las clases y de la interacción entre ellas, para el uso de los objetos
existentes adaptados a nuevas aplicaciones. Las herramientas deben facilitar el modelado
en términos de eventos, formas de activación, estados de objetos, etc. Las herramientas OO
del CASE deben generar un código tan pronto se definan las clases y permitir al diseñador
utilizar y probar los métodos recién creados. Las herramientas se deben diseñar de manera
que apoyen el máximo de creatividad y una continua afinación del diseño durante la
construcción.

Algunas metodologías orientadas a objeto son:

Metodologías dirigidas por los datos:

10
 OMT (Object Modeling Technique)
 Fusion

Metodologías dirigidas por las responsabilidades:

 RDD (Responsibility Driven Design)


 OBA (Object Behavior Analysis)

Metodologías dirigidas por los casos de uso

 Objectory
 Proceso Unificado

Metodologías dirigidas por estados:

 Metodología de Shlaer y Mellor

Metodologías que utilizan la notación UML:

 OPEN
 METRICA (que también soporta la notación estructurada)

El lenguaje UML (Unified Modeling Languaje) es un gran logro de la ingeniería. Aún con
sus carencias, y puntos criticables es un avance muy significativo, un lenguaje común para que
todos los profesionales del desarrollo de sistemas de software o no expresen sus ideas.

Diferencias entre las metodologías Estructuradas y Orientada a objetos:

Estructuradas Orientadas a Objetos

11
Para representar un modelo del mundo real, se
Correspondencia directa con los objetos del
requiere una transformación del espacio del
mundo real.
problema
El Diseño se encuentra muy influenciado por el Se tratan datos y procesos con el mismo nivel de
criterio de descomposición. abstracción.
Cada módulo modela una función o un paquete Cada módulo representa un objeto o clase de
de datos objetos.
No son útiles en problemas de naturaleza
Son aplicables a todo tipo de problemas
concurrente o de tiempo real.

2.3 Metodologías para sistemas en tiempo real.

Metodología que toma elementos de otras ya existentes y propone mecanismos propios para
solventar parcialmente problemas como el paso del modelo de objetos al modelo de proceso y la
asignación de prioridades. La metodología se divide en cuatro fases divididas en dos áreas distintas,
la de los aspectos funcionales y los no funcionales. Durante toda la metodología se usa orientación
objetivo y UML. Para aprovechar las ventajas de los métodos formales, como simulación,
validación y generación de códigos se propone una semántica formal para parte de los aspectos
dinámicos de UML, concretamente las acciones y las máquinas de estados. La semántica propuesta
se basa en metamodelado y en el lenguaje MML.

Estas metodologías son sistemas muy dependientes del tiempo que procesan información
orientada al control. Controlan y son controlados por eventos externos. Se caracterizan porque:

 Se lleva a cabo el proceso de muchas actividades de forma simultánea.


 Se asignan prioridades a determinados procesos.
 Se interrumpe una tarea antes de que concluya, para comenzar otra de mayor prioridad.
 Existe comunicación entre tareas.
 Existe acceso simultáneo a datos comunes.

Para especificar los requisitos de estos sistemas hay que incluir nuevos conceptos para:

 El manejo de interrupciones.

12
 La comunicación y sincronización entre tareas.
 Gestionar procesos concurrentes.
 Dar respuesta oportuna y a tiempo ante eventos externos.
 Datos continuos o discretos.

2.4 Metodologías Ágiles

Las metodologías ágiles son flexibles, pueden ser modificadas para que se ajusten a la
realidad de cada equipo y proyecto. Los proyectos ágiles se subdividen en proyectos más pequeños
mediante una lista ordenada de características. Cada proyecto es tratado de manera independiente
y desarrolla un subconjunto de características durante un periodo de tiempo corto, de entre dos y
seis semanas. La comunicación con el cliente es constante al punto de requerir un representante de
él durante el desarrollo. Los proyectos son altamente colaborativos y se adaptan mejor a los
cambios; de hecho, el cambio en los requerimientos es una característica esperada y deseada, al
igual que las entregas constantes al cliente y la retroalimentación por parte de él. Tanto el producto
como el proceso son mejorados frecuentemente. Algunas de las metodologías ágiles más populares
son:

2.4.1 SCRUM

Se basa en la teoría de control de procesos empírica o empirismo. El empirismo asegura


que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce.
Esta metodología emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el
control del riesgo, realiza entregas del proyecto en sí.

Existen tres pilares fundamentales que soportan el control del proceso empírico los cuales
son:

 Transparencia
 Inspección
 Adaptación

La metodología Scrum describe cuatro eventos importantes que componen cada una de las
entregas:

13
 Reunión de planificación del sprint (Sprint Planning Meeting)
 Scrum Diario (Daily Scrum)
 Revisión del Sprint (Sprint Review)
 Retrospectiva del Sprint (Spring Retrospective)

Scrum se centra en la división del trabajo completo en distintos apartados o bloques que
pueden ser abordados en periodos cortos de tiempo (1-4 semanas), los cuales son denominados
Sprint.

2.4.2. Extreme Programming (XP):

La programación extrema es una metodología que se basa en una serie de reglas y principios
que se han utilizado a lo largo de toda la historia del desarrollo de software, aplicando
conjuntamente cada una de ellas de manera que creen un proceso ágil, en el que se le dé énfasis a
las tareas que agreguen valor y quiten procedimientos que generan burocracia en el mismo.

La programación extrema se engloba en doce principios básicos, los cuales a su vez se


agrupan en cuatro categorías grandes, entre ellas se pueden mencionar:

 Retroalimentación a Escala Fina: en esta fase se encuentran diversos principios como los
de realización de pruebas, proceso de planificación, el cliente en el sitio y programación en
parejas.
 Proceso Continuo: en lugar de por lotes, permite la integración continua, refactorización
(Evaluar el diseño del sistema a lo largo de todo el proyecto y codificar si es necesario) y
entregas pequeñas.
 Entendimiento compartido: en esta categoría se definen criterios como el de crear un diseño
fácil, las tarjetas CRC (Clase, Responsabilidad y Colaboración) y la creación de la metáfora
del sistema o historia completa.
 Bienestar del programador: se rige por la filosofía que un programador cansado, exhausto
crea código de mala calidad, por eso se recomienda que los desarrolladores tengan 40 horas
de trabajo a la semana y muy pocas horas extras de trabajo.

2.4.3. Crystal Clear:

14
Crystal es una metodología en la cual se establecen códigos de color como parte de la
definición de la complejidad de la misma, si es más oscuro entonces el método es más pesado;
cuánto más crítico es el sistema más rigor se necesita. Además, Crystal sugiere que se defina un
color para cada proyecto en función de su criticidad y tamaño. No existe una metodología cristal
en general, sino existe una metodología cristal para cada tipo de proyecto.

Como las metodologías descritas anteriormente, Crystal es regida por principios que hacen
su utilización eficiente, entre los cuales se pueden mencionar:

 Cada proyecto necesita un grado diferente de compensación (Trade Off).


 Entre más pequeño sea el proyecto es mejor la forma de coordinación.
 Cada uno de los proyectos necesita diferentes medios de comunicación.
 Debe existir retroalimentación y comunicación efectiva, reduciendo así los problemas en
entregas fallidas.
 Los puntos dulces aceleran el desarrollo, se debe de contar con personas capaces y
dedicadas a su trabajo, que se preocupen por hacer las entregas a tiempo y conforme a lo
que el cliente solicita

2.5. Metodología para desarrollos de aplicaciones WEB

Las aplicaciones desarrolladas para la Web tienen características especiales que hacen que
los mecanismos de ingeniería empleados sean diferentes a las utilizadas para desarrollar sistemas
de información tradicionales.

En el año de 1998, Roger Pressman moderó una mesa redonda virtual con representantes la
ingeniería software tradicional y del desarrollo software basado exclusivamente en Internet. La
conclusión general, de esa mesa de trabajo, fue que aplicar un proceso de ingeniería nunca es una
mala idea pero que éste debería adaptarse a los requerimientos de cambio continuo y rapidez
siempre presentes en el proceso de desarrollo Web. De esta iniciativa, surge el nacimiento de una
nueva disciplina denominada Ingeniería Web (IWeb).

2.5.1 IWeb

Las Fases que conforman esta metodología son:

15
FASE 1: Formulación.

Dentro de esta fase se procede a la identificación de los requerimientos y metas de la


empresa para la construcción de la aplicación Web, lo cual se logra aplicando herramientas de
recolección de datos como las entrevistas, cuestionarios y observaciones directas.

FASE 2: Planificación.

Esta fase contempla actividades asociadas a estimar el costo global del proyecto y evaluar
los riesgos que pueden afectar el desarrollo de la aplicación. Para realizar una planificación efectiva
es necesario considerar aspectos tales como definir el ámbito y los recursos de los gestores de Iweb,
personal técnico y cliente; definir los costos y planificación temporal para la revisión de la gestión;
proporcionar un enfoque general del desarrollo de la Iweb para todo el personal relacionado con el
proyecto; y describir cómo se garantizará la seguridad de la aplicación.

FASE 3: Análisis.

Para llevar a cabo la fase de análisis se deben establecer los requisitos técnicos para la
aplicación Web, identificar los elementos del contenido y requisitos de diseño gráfico que se van
a incorporar. Durante esta etapa se deben llevar a cabo cuatro (4) tipos de análisis:

 Análisis del Contenido: Se trata de la investigación del espectro completo de contenido que
se va a proporcionar tales como: datos de texto, gráficos, imágenes, vídeo y sonido.
 Análisis de Interacción: Descripción detallada de la interacción del usuario y con la
aplicación Web.
 Análisis Funcional: Descripción detallada de todas las funciones y operaciones que llevara
a cabo el sistema.
 Análisis de Configuración: Descripción del entorno y de la infraestructura en donde reside
la aplicación Web.

FASE 4: Ingeniería.

Durante esta fase se realizan los diseños necesarios para el funcionamiento de la aplicación,
estos diseños son:

16
 Diseño Arquitectónico: Definición de la estructura global hipermedia para la aplicación
Web, y en la aplicación de las configuraciones de diseño y plantillas constructivas para
popularizar la estructura y lograr su reutilización).
 Diseño del contenido contempla la estructura y formato detallados del contenido de la
información que se presentará.
 Diseño de Navegación: Definir las rutas de navegación que permitan al usuario acceder al
contenido y a los servicios de la aplicación.
 Diseño de Interfaz de Usuario: El diseño identifica los objetos y las acciones de la interfaz
y crea entonces un formato de pantalla que formara la base del prototipo de interfaz de
usuario.
 Diseño de las Estructuras de Datos: se Diseñan las estructuras que permitirán el
almacenamiento de datos que se ingresarán o almacenarán dentro de la aplicación.

FASE 6: Generación de páginas.

Es la fase que contempla la construcción de toda(s) la(s) pagina(s) web donde se presentará
la aplicación, para tal fin se hace mucho uso de las herramientas automatizadas que permiten la
creación de estas páginas.

FASE 7: Puesta a prueba y Evaluación del cliente.

El software debe ser probado para descubrir el máximo de errores posibles antes de su
entrega al cliente, para tal fin se deben comprobar la lógica interna de los componentes del Web y
verificar los dominios de entrada y salida del programa para descubrir errores en su funcionalidad,
comportamiento y rendimiento.

Una vez que se ha validado su normal funcionamiento se procede a ponerlo disponible para
los usuarios.

2.6 Metodologías para la construcción de Sistemas Multimedia

La construcción de grandes aplicaciones hipermedia es extremadamente difícil, por otro


lado, no existe una metodología que se adapte perfectamente a este tipo de software, tentando a los

17
desarrolladores a la omisión del diseño estructural de la aplicación. Esta situación provoca como
resultado la elaboración de un software de baja calidad y susceptible de correcciones posteriores.

Habitualmente el desarrollo de Sistemas Hipermediales suele hacerse utilizando


directamente herramientas a nivel de implementación, descuidándose el importante proceso previo
de análisis y diseño de los aspectos estructurales de la navegación e interfaz. Sin embargo, en los
últimos años existe una tendencia a considerar el desarrollo hipermedial con un enfoque de proceso
de ingeniería del software, por lo que ya se han propuesto diferentes metodologías, como:

 HDM (Hypertext Design Model)


 OOHDM (Object Oriented Hypermedia Design Method)

Estas metodologías consideran un diseño previo a la construcción del sistema y ofrecen una
serie de técnicas, más o menos formales, para recoger en diferentes modelos abstractos las
especificaciones del sistema hipermedial a desarrollar. De éstas la más actualizada es la OOHDM
ya que toma como referencia muchas definiciones de la HDM, además de que está basada en el
paradigma de la orientación a objetos.

2.6.1 OOHDM

Esta metodología plantea el diseño de una aplicación de este tipo a través de cinco fases
que se desarrollan de un modo iterativo. Estas fases son:

Fase 1- Determinación de Requerimientos

La herramienta en la cual se fundamenta esta fase son los diagramas de casos de usos, los
cuales son diseñados por escenarios con la finalidad de obtener de manera clara los requerimientos
y acciones del sistema.

Fase 2- Diseño Conceptual

Se construye un modelo orientado a objetos que represente el dominio de la aplicación


usando las técnicas propias de la orientación a objetos. La finalidad principal durante esta fase es

18
capturar el dominio semántico de la aplicación en la medida de lo posible, teniendo en cuenta el
papel de los usuarios y las tareas que desarrollan. El resultado de esta fase es un modelo de clases
relacionadas

Fase 3- Diseño Navegacional

En OOHDM una aplicación se ve a través de un sistema de navegación, para lo cual se debe


diseñar la aplicación teniendo en cuenta las tareas que el usuario va a realizar sobre el sistema. Para
ello, se debe partir del esquema conceptual desarrollado en la fase anterior. Además, se debe tomar
en cuenta que sobre un mismo esquema conceptual se pueden desarrollar diferentes modelos
navegacionales (cada uno de los cuales dará origen a una aplicación diferente). Para definir este
diseño se deben considerar las siguientes clases navegacionales:

 Nodos: Los nodos son contenedores básicos de información de las aplicaciones hipermedia.
Estos contendrán atributos de tipos básicos (donde se pueden encontrar tipos como
imágenes o sonidos) y enlaces.
 Enlaces: Los enlaces reflejan la relación de navegación que puede explorar el usuario.
 Estructuras de Acceso: éstas actúan como índices o diccionarios que permiten al usuario
encontrar de forma rápida y eficiente la información deseada. Los menús, índices o guías
de ruta son ejemplos de estas estructuras
 Clase de Contexto: Es otra clase especial que sirve para complementar la definición de una
clase de navegación. Por ejemplo, sirve para indicar qué información está accesible desde
un enlace y desde dónde se puede llegar a él.

Fase 4- Diseño de Interfaz Abstracta

Una vez definida la estructura navegacional, se le tiene que preparar para que sea
perceptible por el usuario y esto es lo que se intenta en esta fase. Esto consiste en definir qué objetos
de interfaz va a percibir el usuario, y en particular el camino en el cuál aparecerán los diferentes
objetos de navegación, además de definir qué objeto de interfaz actuarán en la navegación, la forma
de sincronización de los objetos multimedia y el interfaz de transformaciones.

Fase 5- Implementación

19
Una vez obtenido el modelo conceptual, el modelo de navegación y el modelo de interfaz
abstracta, sólo queda llevar los objetos a un lenguaje concreto de programación, para obtener así la
implementación ejecutable de la aplicación.

2.7. Metodologías por autores

Muchos autores, fundamentados en el ciclo de desarrollo de sistemas (SDLC, por sus siglas
en inglés: System Develoment Life Cycle) han estructurado una serie de fases, las cuales aplicadas
de manera secuencial, contribuyen con el desarrollo de software. A continuación se presentan
algunos de ellos:

2.7.1. Kendall & Kendall

Dentro de su obra “Analisis y Diseño de Sistemas” sostiene que el SDLC “es un enfoque
por fases para el análisis y el diseño cuya premisa principal consiste en que los sistemas se
desarrollan mejor utilizando un ciclo especifico de actividades del analista y el usuario.”, para lo
cual definen un total de 8 fases, la cuales se explican brevemente a continuación

FASE I: Identificación de problemas, oportunidades y objetivos

Tal como lo indica el enunciado de esta fase, el propósito fundamental de desarrollarla


consiste en identificar los problemas, los cuales pueden ser descubiertos por el analista de sistemas
o, en algunos casos, por otros actores de la organización, esta situación problemática debe ser
examinada y detallada de la manera más precisa posible, a fin de evaluar las oportunidades o
situaciones que se pueden mejorar mediante el uso de sistemas de información, que apunten hacia
un control eficaz dentro de la organización, para finalmente describir los objetivos que la empresa
pretende alcanzar para solucionar el problema y que por supuesto contribuyan al logro de las metas
y objetivos de la empresa.

El personal involucrado activamente en el desarrollo de esta fase está representado por los
usuarios, analistas y administradores de sistemas. Las actividades que se deben desarrollar durante
esta fase, de acuerdo a sus autores son las siguientes:

 Observación directa del entorno

20
 Aplicación de entrevista para recolectar información.
 Sintetizar la información recolectada para construir objetivos
 Estimar el alcance del proyecto
 Identificar si existe una necesidad, problema u oportunidad argumentada
 Documentar resultados
 Estudiar los riesgos del proyecto
 Presentar un informe de vialidad

Una vez que el equipo presenta el informe de viabilidad queda en manos de la


administración o gerencia de la organización decidir si se procede o cancela la ejecución del
proyecto.

FASE II: Determinación de los requerimientos de información

Durante esta fase del desarrollo de sistemas, el analista de sistema, debe recopilar toda la
información asociada a los datos que requieren los usuarios para ejecutar sus actividades.
Implementando herramientas tales como entrevistas, cuestionarios, observación directa, evaluación
de datos existentes, entre otras, el equipo involucrado en el desarrollo del software, debe dar
respuestas a las siguientes preguntas claves para conocer detalladamente el sistema que está
estudiando:

 ¿Quién? Determinar personal involucrado


 ¿Qué? Cuál es la actividad que tiene la organización.
 ¿Dónde? Considerar entorno dentro del cual se desarrollan las actividades
 ¿Cuándo? Analizar el momento oportuno para la ejecución de las actividades
 ¿Cómo? Conocer cuál es la manera en la que se realizan los procedimientos actuales del
trabajo.

FASE III: Análisis de las necesidades del sistema

Durante el desarrollo de esta fase se deben evaluar todos los productos obtenidos durante
las fases anteriores, para definir las entradas, procesos y salidas de las funciones del sistema.
Apoyándose en herramientas como los Diagramas de Flujos de Datos (DFD), se pueden obtener

21
de manera gráfica y estructurada las funciones definidas. Adicionalmente sobre la bases de los
DFD, se procede a elaborar un diccionario de datos donde se describen todos los datos utilizados
en el sistema. Para finalizar el desarrollo de esta fase se debe preparar una propuesta para el sistema,
así como preparar un análisis costo/beneficio de las alternativas posibles y ofrecer las
recomendaciones al respecto.

FASE IV: Diseño del sistema recomendado

Para esta fase el equipo desarrollador debe definir mediante un diseño lógico todo el sistema,
lo cual incluye:

 Interfaces de entrada de datos por parte del usuario, para lo cual debe definir procedimientos
que garanticen una entrada correcta de datos al sistema, es decir evitar duplicaciones, datos
erróneos, etc.; así como diseñar formularios o pantallas de entrada eficientes.
 Diseño de archivos y bases de datos, dentro de los cuales se almacenará información
valiosa a la organización.
 Diseño de salidas del sistema (pantallas, informes, reportes, gráficos, etc.)
 Diseño de procedimientos que permitan realizar respaldos para proteger el sistema y la
información asociada al mismo.
 Paquetes de especificación de programas, en los cuales se incluyan los esquemas generales
para las entradas de datos y salida de información así como los detalles del procesamiento.

FASE V: Desarrollo y documentación del software

Esta es la fase que involucra directamente a los desarrolladores o programadores de


sistemas, ya que es durante ella cuando se evalúan los procedimientos que deben ser desarrollados
y se procede con su correspondiente codificación (en el lenguaje de programación seleccionado)
así como la eliminación de errores sintácticos que pudieran generarse; adicionalmente, como lo
indican Kendall & Kendall se debe elaborar la documentación necesaria “Entre las técnicas
estructuradas para diseñar y documentar software se encuentran los diagramas de estructuras, los
diagramas de Nassi-Shneiderman y el pseudocódigo. Durante esta fase el analista trabaja con los
usuarios para desarrollar documentación efectiva para el software, como manuales de

22
procedimientos, ayuda en línea y sitios web que incluyan respuestas a preguntas frecuentes en
archivos “léame” que se integrarán al nuevo software.”

FASE VI: Prueba y mantenimiento del sistema

Aunque a medida que se codifica las líneas que conforman al sistema, se realizan pruebas
respecto a su funcionamientos, los autores (Kendall & Kendall) definen esta fase como una forma
de someter el sistema a pruebas, antes de ser entregado a los usuarios, estas pruebas se realizan
inicialmente con datos ficticios y luego con datos reales para determinar cualquier problema o
deficiencia que presente el sistema.

Adicionalmente, durante esta fase se inicia el mantenimiento al sistema el cual se


prolongará durante todo el tiempo que éste se encuentre activo dentro de la organización. Algunas
de las actividades que se deben desarrollar en esta fase son:

 Definir un cronograma para realizar las pruebas del sistema.


 Elaborar algún un instrumento que permita evaluar el sistema de información.
 Elaborar un resumen con los resultados de las pruebas del sistema.
 Elaborar un plan de mantenimiento, definiendo frecuencia y duración, de las actividades
que se deben ejecutar al sistema para garantizar su funcionamiento.
 Elaborar la lista de las operaciones que pudieran sufrir modificaciones de códigos.

FASE VII: Implementación y evaluación

Con esta fase se culmina el ciclo de desarrollo de sistemas propuesto por Kendall & Kendall,
la implementación del sistema contempla la instalación de todos los equipos necesarios para
garantizar el funcionamiento del software; así como la capacitación a los usuarios para que realicen
la manipulación del sistema.

Aunque se menciona la evaluación como parte de esta fase, es necesario destacar que
durante la ejecución de todas las fases de la metodología el sistema es sometido a constante

23
evaluación de sus requerimientos, necesidades, diseños desarrollos y pruebas; sin embargo durante
esta etapa se debe evaluar la adaptabilidad de los usuarios al nuevo sistema.

2.7.2 Roger Pressman:

Este autor, establece las siguientes etapas metodológicas para desarrollar sistemas
información:

Etapa I: Análisis

Pressman establece que la tarea del análisis de requisitos es un proceso en el cual se debe
definir en detalle el ámbito del software, así como crear modelos de los requisitos de datos, flujo
de información y control, y del comportamiento operativo del sistema. Por medio del desarrollo de
esta etapa el desarrollador o desarrolladores podrán especificar la función y rendimiento del
software, así como determinar la interfaz del software con otros elementos del sistema y establecer
las restricciones que debe cumplir. Esta etapa se subdivide en cinco (5) áreas:

 Reconocimiento del problema: identificar y reconocer los elementos básicos del problema
de acuerdo a cómo lo ven los usuarios.
 Evaluación y síntesis: Definir todos los objetos de datos observables externamente, evaluar
el flujo y contenido de la información, definir y elaborar todas las funciones del software,
entender el comportamiento del software en el contexto de acontecimientos que afectan al
sistema.
 Modelado: generar modelos del sistema de tal manera que se puede entender con mayor
precisión el flujo y control de los datos, así como el comportamiento operativo del sistema
y el contenido de la información.
 Especificación: realizar un planteamiento y/o descripción formal del software.
 Revisión: consiste en realizar chequeo de manera general a todo el proceso.

Etapa II: Diseño

La fase de diseño, presentada por Pressman, tiene que ver con “el establecimiento de las
estructuras de datos, la arquitectura general del software, representaciones de interfaz y algoritmos.
El proceso de diseño traduce requisitos en una representación de software”

24
De manera general esta fase, representa la primera de actividades técnicas que se deben
realizar durante el proceso de ingeniería de software (las otras dos son codificación y pruebas), al
finalizar esta etapa se debe contar con un diseño de datos, que consiste en transformar el modelo
de dominio de la información desarrollado durante la fase de análisis; un diseño arquitectónico,
mediante el cual se deben definir las relaciones entre los diferente elementos que conforman al
programa; y un diseño de interfaz que debe describir la manera cómo el sistema se comunica
consigo mismo, con otros sistemas y con sus los usuarios y operadores.

Etapa III: Codificación

A esta fase también se le conoce como la fase de generación del código, la cual consiste en
traducir todos los diseños definidos durante la fase anterior de manera tal que puedan ser entendido
y ejecutado por las computadoras donde se implementará, para ello se utilizará el lenguaje de
programación que a juicio del equipo desarrollador sea más adecuado o en caso de que la
organización posea alguna estandarización se debe adaptar a las condiciones organizaciones.

Etapa IV: Prueba

Aunque, durante la fase de codificación, los desarrolladores realizan pruebas de


funcionamiento de los procesos generados; la fase de pruebas, debe iniciarse, formalmente, tan
pronto como se haya terminado de generar el código. De acuerdo con Pressman, “el proceso de
pruebas se centra en los procesos lógicos internos del software, asegurando que todas las sentencias
se han comprobado, y en los procesos externos funcionales, es decir, la realización de las prueba
para la detección de errores”. Durante esta fase se debe probar el sistema con datos reales así como
con la interacción con otros sistemas a fin de obtener la mayor retroalimentación posible que
permita descubrir cualquier anormalidad en su funcionamiento para poder corregir la desviación.

Etapa V: Mantenimiento

Esta etapa, es de vital importancia ya que dentro, el software implantado debe tener
modularidad necesaria para que se le puedan hacer adaptaciones, permitiendo incorporar nuevos
módulos sin que se afecte el funcionamiento del mismo.

2.7.3 James Senn


25
Este autor centra su atención en el Ciclo de vida y Desarrollo del Sistema, por lo cual plantea
la ejecución de las siguientes etapas:

Etapa 1. Investigación Preliminar

El desarrollo de esta etapa abarca las siguientes actividades:

 Aclaración de la solicitud: en este particular se debe determinar con la mayor claridad y


precisión posible cuál es la solicitud planteada por los usuarios u organización que requiere
el desarrollo de un Sistema de Información
 Estudio de Factibilidad: una vez aclarada la solicitud se procede a determinar si es factible
desarrollar el sistema, para lo cual, el autor sugiere realizar un estudio que abarque la
factibilidad técnica (determinar si el sistema puede desarrollarse con las capacidades de
personal, hardware y software existentes dentro de la organización o en caso de requerir
recursos técnicos cuales son las posibilidades de adquirirlos); factibilidad económica
(investigar si los costos en los cuales se incurrirán se justifican con respecto a los beneficios
que se obtendrán al implementar el sistema); y factibilidad operacional investigar la
utilización que se le dará al sistema para obtener beneficios.

Etapa 2. Determinación de los requerimientos del Sistema

Durante esta etapa de obtener toda la información necesarias respecto a los procesos que se
ejecutan dentro de la organización y que ver con el sistema que se pretende desarrollar, para
recolectar la información se pueden hacer entrevistas, encuestas, observaciones directas,
cuestionarios, estudio de manuales y reportes; el propósito de esta recolección de información es
conocer y comprender el proceso en sus totalidad, para poder establecer las características que debe
tener el nuevo sistema, es decir, identificar datos de entrada, procesos que deben ejecutarse e
información de salida que debe emitir el sistema.

Etapa 3. Diseño del Sistema (Diseño Lógico)

Al momento de diseñar el sistema, lo que se pretende es darle respuesta a la forma como el


sistema cumplirá con todos los requerimientos identificados durante la fase anterior. Para tal fin se
debe indicar cuáles son datos de entrada, calculados y cuáles deben ser almacenados, por lo tanto
26
deben definir las estructuras de datos así como los dispositivos donde se almacenarán; de igual
manera se debe diseñar como se procesan los datos y de qué manera se producirá la salida de
información, para tal fin se deben elaborar los diagramas necesarios (DFD, Diseños de tablas,
Pantallas de entrada, pantalla de salidas, reportes, etc. Toda la información definida dentro de esta
fase es de vital importancia para la ejecución de la etapa siguiente.

Etapa 4. Desarrollo del Sistema (Diseño Físico)

Durante esta fase se procede a la codificación de todos los programas necesarios para que
el software ejecute las funciones que fueron definidas previamente, adicionalmente se deben
elaborar la documentación necesarias de los programas, es decir explicar su codificación, haciendo
hincapié en la función que cumple cada uno de los módulos desarrollados a fin de que se facilite
las labores al momento de hacer las pruebas y mantenimientos del sistema.

Etapa 5. Prueba del Sistema (Diseño Físico)

Una vez que finaliza la etapa anterior, se procede a realizar pruebas del sistema en su
totalidad, es decir, el sistema es empleado de manera experimental para garantizar que funciona de
acuerdo a las especificaciones requeridas y que además ejecuta completamente las funciones
solicitadas por los usuarios. Los datos utilizados para las pruebas pueden ser ficticios y/o reales.
Durante la ejecución de esta fase los usuarios son invitados a utilizar el sistema a fin de observar
que lo utilicen de la forma necesaria antes de proceder a implantarlo dentro de la organización

Etapa 6. Implantación y Evaluación

Una vez finalizadas las pruebas del sistema, se procede con su implantación, la cual consiste
en instalar la aplicación dentro de la organización para que sea utilizada por todos los usuarios que
la requieran.

Adicionalmente, se debe llevar a cabo una evaluación del sistema a fin de identificar sus
puntos fuertes y débiles. Al momento de evaluar el software, se deben considerar:

 Evaluación operacional: Valorar de la forma cómo funciona el sistema (facilidad de uso,


tiempo de respuesta, formatos, confiabilidad, y nivel de utilización).

27
 Impacto organizacional, medir beneficios organizacionales (ingresos, ganancias, eficiencia,
impacto competitivo)
 Desempeño del Desarrollo: Evaluar el proceso de desarrollo (tiempo, esfuerzo, costos y
cualquier otro criterio de desarrollo de proyectos)

2.7.4 Jonas Montilva

Este autor diseñó la metodología MEDSI (Metodología Estructurada para el Desarrollo de


Sistemas de Información), la cual se encuentra estructurada por 8 fases:

Fase 1. Definición del Proyecto

Cuando dentro de una organización se identifican necesidades que se consideran que


puedan ser cubiertas por medio de la implementación de un sistema de información, entonces se
ejecuta la fase inicial de esta metodología la cual consiste en definir el proyecto, para lo cual se
debe justificar el desarrollo del sistema así como realizar el estudio de factibilidad necesario, para
que en caso de resultar factible, proceder con la planificación del proyecto.

Dentro de esta fase se llevan a cabo actividades tales como:

 Estudio Preliminar el proyecto: consiste en reconocer y formular el problema, es decir,


diagnosticar de manera general la situación actual a la cual se le pretende aplicar el uso de
un sistema de información.
 Estudio de Factibilidad: para tal fin se debe, evaluar el sistema o situación actual, para
establecer, de manera general cuales son los requerimientos del nuevo sistema;
adicionalmente se debe realizar el estudio de factibilidad técnica, económica y psicosocial.
 Planificación del proyecto: con respecto a la planificación del proyecto, es importante que
se elabore el plan general tomando en cuenta cada una de las fases que deben ser ejecutadas.
Adicionalmente en este momento se debe seleccionar el grupo desarrollador del sistema.

Fase 2. Análisis del Contexto

Luego de definir el proyecto, y evaluar el informe de factibilidad, se decide si el proyecto


es factible, en este caso se debe iniciar el análisis del contexto, es decir una evaluación del ambiente

28
dentro del cual funcionará el sistema, para ello se procede con el análisis documental del sistema
actual recopilando todos los documentos que existen al respecto, para posterior proceder a
organizarlos y estudiarlos con la finalidad de familiarizarse con el sistema antes de realizar un
análisis formal del sistema actual.

Adicionalmente al realizar el análisis del contexto se deben construir, en caso de que no


exista, el modelo del sistema actual así como identificar cualquier situación problemática que
influya en su funcionamiento.

Fase 3. Definición de Requerimientos

Durante esta fase se debe determinar, en conjunto con los usuarios del sistema, todos los
requerimientos que debe satisfacer el nuevo sistema, de igual manera se deben establecen las
funciones, restricciones y atributos de calidad del sistema.

Los requerimientos que debe satisfacer el nuevo sistema deben estar enfocados en
requerimientos de información, funcionales, restricciones para el desarrollo y operación, así como
atributos del sistema.

Fase 4. Diseño Preliminar

La finalidad de desarrollar esta fase tal como lo indica Montilva es “Elaborar un diseño
preliminar del sistema de información que satisfaga los requerimientos, restricciones y atributos
establecidos en la fase 3. El diseño preliminar consta de un prototipo o modelo físico general que
delinea la interacción hombre-máquina del sistema de información y describe, en forma general,
sus procesos automatizados.”

Para tal fin es necesario definir prototipos que puedan satisfacer las especificaciones
funcionales del nuevo sistema, para posteriormente realizar la sección del prototipo en función a
un análisis costo beneficio

Fase 5. Diseño Detallado

29
Partiendo del prototipo seleccionado durante la fase anterior, se procede a realizar un diseño
detallado del nuevo sistema, para lo cual es necesario diseñar las interfaces Hombre-Máquina, es
decir las interacciones que tendrán los usuarios con el sistema a través de pantallas de entrada/salida,
así como reportes e informes. Adicionalmente se debe realizar el diseño de datos, lo cual contempla
tanto el diseño lógico como físico de la base de dato.

Por otra parte, también deben ser diseñados todos los programas y procedimientos que
deben ser ejecutados por el nuevo sistema, para lo cual se debe definir la estructura que éste tendrá,
para diseñar cada uno de los módulos de la estructura. Además, se deben diseñar la documentación
del sistema así como cualquier procedimiento manual que debe ejecutarse.

Dentro de esta fase, se plantea la elaboración de un plan de pruebas, dentro del cual se deben
establecer las diferentes pruebas que deben realizarse; los responsables de diseñarlas, construirlas
y ejecutarlas; identificación de tiempos, costos y recursos necesarios para llevarlas a cabo; las
herramientas, métodos, técnicas y procedimientos que se deben emplear; los criterios para declarar
como exitosa cada prueba.

Fase 6. Construcción del sistema

Durante esta fase se procede con la construcción del sistema, en base a todas las
especificaciones declaradas durante la fase de diseño, para lo cual se debe codificar todos los
programas que conformaran a los módulos estructurados durante la fase anterior; además se
construye toda la base de datos y se realizan las validaciones y pruebas necesarias para cada uno
de los módulos o subsistemas que conforman al nuevo sistema.

Fase 7. Pruebas del Sistema

Esta fase se realiza inmediatamente después de las pruebas de subsistemas. Durante ésta, el
grupo prueba todo el sistema de información a fin de determinar discrepancias o anomalías entre

30
el sistema de información recientemente construido, y los objetivos y requerimientos inicialmente
establecidos con los usuarios del sistema.

Adicionalmente durante esta fase se realiza la preparación para la implantación, para lo cual
se elabora un plan con todas las actividades y tareas que debe llevar a cabo el grupo de desarrollo
durante la implantación del sistema dentro de la organización.

Fase 8. Implantación del sistema

La última fase de la metodología MEDSI, consiste en la implantación del sistema, para lo


cual se deben realizar la conversión del sistema actual al nuevo sistema desarrollado, es decir la
puesta en operación del mismo. Además, se deben brindar los adiestramientos necesarios a los
usuarios, de manera tal que puedan interactuar con el sistema de la manera más eficiente posible.
Finalmente, se entrega sistema a los usuarios y al grupo que se encargará del mantenimiento junto
con el Informe Final del proyecto.

2.7.5 Llorens Fabregas

Fabregas, se basa en el Ciclo de Desarrollo de Sistemas de Información para definir las


etapas que conforman a esta metodología, la cual consta de 5 fases.

Fase I. Requerimientos

Durante esta fase se desarrolla un modelo del área estudiada, dentro del cual se debe
representar cada uno de los procesos que se llevan a cabo, así como la información utilizada por
éstos y las reglas políticas de la organización relacionada con estos procesos. Este modelo permitirá
visualizar las interrelaciones entre los procesos y los datos dentro de la organización, esto con la
finalidad de desarrollar un plan para el sistema de información capaz de guiar el desarrollo del
mismo un sistema y que permita dar soporte al área en estudio para el cumplimiento de sus
objetivos. Este plan de sistema debe contener:

31
 Los sistemas que requiere el área del negocio, así como sus bases de datos y la información
que intercambiaran o compartieran.
 Descripción detallada de cada sistema y aplicación incluyendo sus objetivos funcionales y
sus bases de diseño.
 Todo hardware y software que serán utilizados para el funcionamiento requeridos por el
área de negocio (incluyendo las redes)
 Métodos de desarrollo para cada sistema como lo es adquisición de paquetes, nuevo
desarrollo o actualizaciones
 Esquema de los problemas actuales del área de negocio y de las posibles mejoras que se
puedan realizar en cada sistema
 Análisis de los beneficios que se espera derivar de los sistemas que conforman la
arquitectura

Fase II. Análisis / Diseño

Una vez que ha sido identificados todos los requerimientos durante la fase anterior, se
procede con el diseño arquitectónico del sistema, este diseño arquitectónico contempla dos
elementos: los datos y los procesos, los cuales deben ser analizados partiendo de una visión
conceptual hasta llegar a una visión física de los mismos. Las actividades que contempla esta fase
son:

 Analizar y Diseñar Proceso: Las operaciones del negocio y los requerimientos de


funcionamiento definidos en la primera fase, se toman en cuenta con el propósito de
determinar la forma en que debe funcionar el sistema.
 Analizar y Diseñar los Datos: Con los requerimientos de información definidos en la fase I
se debe organizar los distintos modelos de datos que contribuyan a diseñar las bases de
datos que hagan falta para que el sistema opere de acuerdo al modelo de funcionamiento.
 Diseñar y Organizar los Componentes Físicos: Todo componente físico como (pantallas,
base de datos) que hagan posible el funcionamiento del sistema de acuerdo al modelo de
funcionamiento.

32
 Planificar el Desarrollo de los Componentes Físicos: actividad en la cual se planifica la
forma en que pueden ser construidos e implementados los componentes físicos de una
forma rápida y productiva.

Fase III. Construcción

Para la construcción del sistema se deben llevar a cabo las siguientes actividades:

 Desarrollo de Infraestructura: Desarrollar y organizar la infraestructura que permita cumplir


las tareas de construcción del software en la forma más productiva posible.
 Desarrollo de Unidades de Diseño Interactivas: Las unidades de diseño interactivas, son
procedimientos que se cumple o se ejecutan a través de un dialogo del usuario con el sistema,
por lo tanto se deben especificar en detalle las tareas que debe cumplir la unidad de diseño,
así como desarrollar sus componentes y realizar las pruebas unitarias y las pruebas de
integración a nivel de la unidad de diseño.
 Desarrollo de Unidades de Diseño Batch: Las unidades de diseño Batch, son aquellos
procedimientos que se cumplen en forma automatizada, pero en la que no se entabla un
dialogo entre usuario y el analista, sino que involucra grupos de transacciones que se
alimentan al computador de una sola vez. En tal sentido se deben preparar las
especificaciones utilizando técnicas como flujogramas, diagramas de estructuras, tablas de
decisiones, etc., con la intención de que la especificación se lo mas clara posible a fin de
que se logre que el programador la comprenda y por lo tanto pueda programarla.
 Desarrollo de Unidades de Diseño Manuales: Esta actividad incluye las tareas que se
ejecutan de manera manual, con la finalidad de desarrollar todos los procedimientos
administrativos que rodearán y gobernarán la utilización de los componentes
computarizados desarrollados en la fase de diseño y construcción.

Fase IV. Pruebas

Luego que todas las unidades de diseño han sido desarrolladas y probadas de manera
independiente, se procede con la realización de las pruebas globales del sistema, para asegurarse
que el software no falla y que cumple con todas la funciones especificadas. En tal sentido se
establecen varios niveles de prueba:

33
 Funcional: Prueba desde el punto de vista de los requerimientos funcionales.
 De Sistema: Prueba desde el punto de vista de los niveles de calidad del sistema y de
desempeño.
 De Integración: Prueba de interfaces.
 De Aceptación Técnica: Prueba de manejo de condiciones extremas.

Si todas las pruebas realizadas en los niveles establecidos en la fase anterior son
satisfactorias, entonces se procede con la carga de los archivos, base de datos y tablas del nuevo
sistema, para de esta forma dar inicio al proceso de aceptación, el cual se mantendrá en
funcionamiento durante un periodo denominado “Periodo de Aceptación”, una vez finalizado este
período el sistema pasa a ser oficial dentro de la organización.

Fase V. Producción y Mantenimiento.

En la etapa de producción se asegura que el sistema funcione correctamente, para esto se


realizan nuevas pruebas, se reevalúan los resultados y se hacen refinamientos del sistema, los
cambios necesarios deberán ser introducidos sin afectar a los usuarios, y deberá conseguirse la
máxima confianza de los usuarios.

Por otra parte según Fabregas, “Durante la fase de mantenimiento, se ponen en práctica
todas las políticas y los procedimientos destinados a garantizar la operación continúa de los de los
sistemas y a asegurar su uso efectivo, con el fin, de que éstos se constituyan en una verdadera
herramienta de apoyo al logro de los objetivos estratégicos de la empresa”

3. Modelos o enfoques para el desarrollo de software

3.1 Cascada.

En este modelo cada etapa representa una unidad de desarrollo, por lo tanto, la siguiente
etapa inicia tan pronto como la anterior haya terminado. Este es considerado el método tradicional
más de explicar el proceso de desarrollo de software dentro de la ingeniería de software. Es
aplicado a proyectos con metas claras y requisitos que demandan hasta un máximo de 100 horas
de desarrollo. Por lo tanto, es una gran opción para proyectos pequeños donde todos los aspectos

34
del proceso de desarrollo de software se conocen de antemano, pero representa una mala solución
para proyectos complicados, ya que se trata de un modelo bastante inflexible. Las etapas que lo
conforman se pueden apreciar en la figura 1. Donde se puede apreciar que al finalizar el proceso
(Funcionamiento y mantenimiento del software) dependiendo de sus resultados se puede regresar
a la ejecución de alguna de sus fases para solventar cualquier irregularidad detectada durante el
funcionamiento del sistema.

Figura 1. El modelo en cascada

Fuente: Ian Sommerville (Ingeniería de Software. 2005)

Análisis y definición de requerimientos: Todos los servicios, restricciones, objetivos y metas


asociadas al sistema se definen a partir de las interacciones con los usuarios. Entonces, se definen
en detalle todas las necesidades del software que será desarrollado.

Diseño del sistema y del software: Durante el proceso de llevan a cabo dos tipos de diseños: uno
de alto nivel, mediante el cual se describe la solución, identificando los grandes módulos que
conforman al sistema y las relaciones entre ellos; y otro detallado, en el cual se definen los
algoritmos y la organización del código para posteriormente realizar su implementación.

Implementación y prueba de unidades: Durante esta etapa el diseño del software se lleva a cabo,
es decir, se implementa el código fuente, haciendo uso de prototipos así como de pruebas y ensayos

35
para corregir errores. Se crean librerías y componentes reutilizables dentro del mismo proyecto
para hacer que la programación sea un proceso mucho más rápido.

Integración y prueba del sistema; Una vez que se han desarrollado y probado todas las unidades o
módulos del sistema, entonces se procede con la integración de todos estos subsistemas en uno solo
para realizar las pruebas como un sistema completo para así asegurar que se cumplan los
requerimientos del software, para posteriormente realizar la entrega al cliente.

Funcionamiento y mantenimiento: En esta fase el sistema se instala y se pone en funcionamiento


práctico. El mantenimiento implica corregir errores no descubiertos en las etapas anteriores, así
como, mejorar la implementación de los módulos del sistema.

3.2 Desarrollo Evolutivo (Espiral).

Este modelo es una adaptación del modelo en cascada para cuando no se tiene
completamente claros los requisitos. La estrategia a seguir con el modelo incremental es establecer
varias entregas del producto, cada una con mayor funcionalidad que la anterior. Por lo tanto, al
acabar el primer incremento, se empieza a desarrollar el siguiente, y así sucesivamente hasta tener
el producto finalizado. Esto permite dividir el resultado en distintos paquetes y poder ver
evolucionar el resultado con cada entrega.

Este modelo se basa en la idea de desarrollar una implementación inicial, exponiéndola a


los comentarios del usuario y refinándola a través de las diferentes versiones que se generan hasta
que se desarrolle un sistema adecuado, tal como se aprecia en la figura 2.

36
Figura 2. Modelo en Espiral

Fuente: Roger Pressman (Ingeniería de Software. Un enfoque práctico, 2005)

El desarrollo inicia una etapa de Comunicación, mediante la cual se estable contacto con
los usuarios a fin de determinar los requerimientos del sistema. Seguidamente, se realiza la
Planeación, para lo cual se realiza la programación de actividades a ejecutar tomando en
consideración un análisis del riesgo al respecto. Posteriormente, se lleva a cabo una fase de
Modelado, durante la cual se realiza un análisis y diseño de los componentes que conformarán al
sistema. La etapa de Construcción conlleva las actividades de generación del código fuente del
software, así como, la realización de las pruebas pertinentes. Finalmente, durante la fase de
Despliegue, se hace la entrega del producto al usuario, para recibir la retroalimentación asociada
al mismo. De acuerdo a lo planteado por Pressman “El primer circuito alrededor de la espiral da
como resultado el desarrollo de una especificación del producto; las vueltas sucesivas se usan para
desarrollar un prototipo y, luego, versiones cada vez más sofisticadas del software. Cada paso por
la región de planeación da como resultado ajustes en el plan del proyecto. El costo y la
programación de actividades se ajustan con base en la retroalimentación obtenida del cliente
después de la entrega. Además, el gerente del proyecto ajusta el número planeado de iteraciones
que se requieren para terminar el software.”

37
3.3 Metodología de Prototipo

Es un procedimiento de desarrollo especializado que permite a los desarrolladores la


posibilidad de poder solo hacer la muestra de la resolución para poder validar su esencia funcional
ante los clientes, y hacer los cambios que sean fundamentales antes de crear la solución final
auténtica.

Además de esto, la gran ventaja de optar por este enfoque es que da una idea clara sobre el
proceso funcional del software, reduce el riesgo de falla en una funcionalidad de software y asiste
bien en la recolección de requisitos y en el análisis general.

38
CONLUSIONES

 Una metodología de desarrollo de software, consiste en hacer uso de diversas herramientas,


técnicas, métodos y modelos para el desarrollo, implementación y mantenimiento de un
producto desde que surge la necesidad hasta que se cumple el objetivo por el cual fue creado.

 Las metodologías de desarrollo de software pueden enfocarse desde dos grandes puntos de
vistas, las estructuradas y las orientadas a objetos, siendo estas últimas, las que pueden ser
aplicadas a cualquier tipo de problemas ya que realiza una correspondencia directa con los
objetos del mundo real, los datos y procesos son tratados con el mismo nivel de abstracción y
cada módulo se representa y es tratado como un objeto o clase de objeto.

 Existe una gran variedad de metodologías para el desarrollo de software, algunas pueden ser
aplicadas para el desarrollo de sistemas en general, sin embargo, existen otras que surgieron
como alternativas para ser aplicadas a sistemas particulares tal es el caso de la metodología
IWEB (Ingeniería Web), para el desarrollo de sistemas basados en la web; la OOHDM (Object
Oriented Hypermedia Design Method), que se enfoca al desarrollo de sistemas multimedia. En
tal sentido, para la utilización de una metodología, se debe evaluar previamente la naturaleza
del sistema a desarrollar, para posteriormente, seleccionar la que más se ajusta al mismo.

 Aunque existe es gran variedad de metodologías generales y particulares, todas en la


descripción de sus fases abarcan las cuatro etapas principales que constituyen al ciclo de Vida
de Desarrollo de Sistemas, las cuales no son otras que Análisis, Diseño, Desarrollo e
Implementación del sistema.

39
REFERENCIAS WEB

https://sisteminformacii.wikispaces.com/METODOLOG%C3%8DA+DE+KENDALL+%26+KE
NDALL

https://sistemasdeinformacion2.wikispaces.com/Metodologia%20de%20Roger%20Pressman

https://sistemasdeinformacion2.wikispaces.com/METODOLOG%C3%8CA%20DE%20JAMES
%20A.SENN

http://www.monografias.com/trabajos14/medsi/medsi.shtml

https://vdocuments.site/documents/fases-de-medsi.html

https://www.freelancer.es/community/articles/proceso-del-desarrollo-software

https://sites.google.com/site/adai6jfm/home/clasificacin-de-las-metodologas

https://analistadesistema5.blogspot.com/2013/12/metodologias-para-desarrollo-de-software.html

https://prezi.com/wnm5gshccab9/clasificacion-de-las-metodologias-de-desarrollo/

https://hablemosdesoftware.wordpress.com/2014/10/03/metodologias-de-desarrollo-de-software/

https://okhosting.com/blog/metodologias-del-desarrollo-de-software/

https://sites.google.com/site/adai6jfm/home/clasificacin-de-las-metodologas

https://ingenieriadesoftware1elvisacuna.blogspot.com/2015/12/clasificacion-de-las-
metodologias-de.html

http://www.eumed.net/libros-
gratis/2009c/587/Metodologias%20y%20Tecnologias%20Actuales%20para%20la%20construcci
on%20de%20Sistemas%20Multimedia.htm

https://metodologiaiweb.blogspot.com/

40
REFERENICAS BIBLIOGRAFICAS

Kendall & Kendall: Análisis y Diseño de Sistemas. Tercera Edición

Someerville, Ian. Ingeniería del software. Séptima Edición.

Pressman, Roger. Ingeniería de Software. Un enfoque práctico. Séptima Edición

Seen, James. Análisis y Diseño de Sistemas de Información. Segunda Edición.

41

También podría gustarte