Instituto Universitario Politcnico

Santiago Mario
Extensin Maturn
Escuela de Ingeniera en Sistemas

DESARROLLO DE SOFTWARE
Y
SUS MODELOS TRADICIONALES

Autor: Sarai Tom

Csar Rodriguez
Profesor: Fabiola Idrogo

Maturn, Octubre de 2014

SOFTWARE
Bsicamente se refiere al conjunto de programas o aplicaciones que se ejecutan en
el computador. Los programas son conjuntos de instrucciones relacionadas lgicamente,
escritas en un lenguaje de programacin formal (Pascal, C, C++, Visual Basic, Fortran,
Cobol, Java, otros). Quizs, lo que no se percata de manera obvia es que los programas
controlan la computadora (el hardware) para que realice las tareas que se requieren. Otro
aspecto que a veces no se percata de manera obvia, es que los lenguajes de programacin
tambin son software. Programas que permitan escribir otros programas.

Software es un trmino general para referirse a las distintas clases de programas

utilizados para operar los computadores y sus dispositivos. Se puede definir como el
conjunto de tres componentes:

Programas (Instrucciones): este componente proporciona la funcionalidad deseada y

el rendimiento cuando se ejecute.

Datos: este componente incluye los datos necesarios para manejar y probar los
programas y las estructuras requeridas para mantener y manipular estos datos.

Documentos: este componente describe la operacin y uso del programa.

CLASIFICACIN Y TIPOS DE SOFTWARE.

Hoy en da nos encontramos con una amplia oferta disponible de programas
desarrollados para un fin especfico, el nmero de programas se incrementan
exponencialmente ao tras ao, podemos identificarlos y clasificarlos por diferentes
conceptos como:

Ubicacin donde se encuentra instalado:

Software en la red- Son aquellos programas y aplicaciones que se encuentran

alojados en Internet o en un servidor propio y proveen el servicio al cliente mediante una

conexin a la red, siendo su principal caracterstica la no necesidad de instalarlo,

configurarlo ni mantenerlo en el propio terminal donde se utiliza, programas como Office
365, Dropbox o Google Docs son ejemplos entre otros.

Software local - Tambin denominados como software de escritorio son aquellos

que necesitan ser instalados y almacenados en el ordenador donde se ejecuta a diferencia de
los anteriores, la suite ofimtica Office, el programa de diseo grfico Photoshop o el
sistema operativo Windows son ejemplos de este tipo de software.

Grado de libertad de uso:

Software libre - Representan al conjunto de programas en el que los usuarios

disponen de plena libertad para copiarlo, compartirlo y modificarlo, para ello generalmente
se tiene acceso al cdigo fuente del propio programa. El sistema operativo Linux, el editor
de imgenes Gimp o la suite ofimtica Openoffice son ejemplos de este tipo de programas.

Software propietario o privado - Representan al conjunto de programas en los que

los usuarios tienen limitaciones para modificarlos, compartirlos o copiarlos salvo permiso
expreso del titular del software como por ejemplo el sistema operativo Windows, el editor
de imgenes Photoshop o la suite ofimtica Microsoft Office.

Tipo de funcionalidad:
Software de sistemas - Tambin denominados como sistemas operativos este tipo de
software gestiona y administra el hardware del dispositivo electrnico as como la
ejecucin de otros programas. Windows, iOS, Linux o Solaris son ejemplos entre otros.

Software de programacin - Representan al conjunto de programas que nos

permiten desarrollar, crear y modificar otros programas, mediante este tipo de software se
escribe el conjunto de instrucciones en un lenguaje determinado el cual se le conoce como
cdigo del programa, ejemplos como Xcode de Apple, Visual Studio de Microsoft o
Android Studio de Google.

Software de aplicacin - Son el resto de programas que son utilizados para un fn

especfico, es tipo de software es el ms amplio que encontramos en el mercado, a su vez
podemos clasificarlo en software:

Ofimtico - Son todos los programas que facilitan las tareas de las labores de oficina
como por ejemplo hojas de clculo, editores de textos, diseo grfico, gestin de facturas,
puntos de venta, etc.

Empresarial - Son todos aquellos que estn enfocadas a su aplicacin en el rea

empresarial, programas como SAP que gestiona y administra la totalidad de una empresa,
Solidworks que permite el diseo y clculo de estructuras y mquinas complejas o Scada
desarrollado para hacer funcionar los autmatas industriales.

Comunicacin - Representan al conjunto de programas destinados a establecer y

facilitar la comunicacin y la informacin entre personas, los navegadores webs, los
gestores de correos electrnicos, aplicaciones de la web social como twitter o facebook as
como facetime, whatsapp o Skype son ejemplos de este tipo de software.

Seguridad - Representan al conjunto de antivirus que detectan y eliminan programas

que pueden alterar el funcionamiento de nuestro dispositivo electrnico. Norton,
Karspersky o Panda son ejemplos entre otros.

Malicioso - En contra a los anteriores este tipo de programas alteran y manipulan la

informacin y el funcionamiento de la computadora sin permiso del usuario.

Ocio - Son todos los programas destinados al entretenimiento como los videojuegos,
reproductores de msica y vdeo, lectores de libros digitales, etc.

Educativo - Destinado a la enseanza y aprendizaje podemos citar como ejemplos la

enciclopedia digital Encarta o el programa matemtico Matlab entre otros.

DESARROLLO DE SOFTWARE

Cuando se va desarrollar un software intervienen muchas personas como lo es el

cliente quien es el que tiene el problema en su empresa y desea que sea solucionado, para
esto existe el analista de sistema quien es el encargado de hacerle llegar todos los
requerimientos y necesidades que tiene el cliente a los programadores quienes son las
personas encargadas de realizar la codificacin y diseo del sistema as como tambin las
pruebas y la instalacin del sistema. Es as como intervienen varias personas ya que una
sola persona no podra determinar todo lo necesario.

Proceso del desarrollo de software

El primer paso del proceso es el anlisis, es aqu donde el analista se pone en

contacto con la empresa para ver cmo est conformada, a que se dedica, saber todas las
actividades que realiza en s, conocer la empresa de manera general para posteriormente ver
cules son sus necesidades o requerimientos que la empresa tiene en ese momento para
poder realizar un anlisis de la misma.

Es importante saber cules son los requerimientos que la empresa tiene porque
muchas veces los sistemas se desarrollan pero no pensando en el cliente y es ah donde el
sistema no cumple o no satisface las necesidades que existen en la empresa, segn los
requerimientos se empieza a realizar el diagrama relacional todo debe de llevar una
secuencia lgica de las actividades, todo esto se realiza de manera manual para ver cmo

ser su diseo lgico y diseo de pantallas es en este paso donde se plasma todo y queda
perfectamente bien definido como va hacer la funcionalidad del sistema.

El segundo paso es el de diseo aqu entran todo el diseo del sistema es decir las
pantallas, base de datos, todo esto debe de cumplir con ciertos estndares los cuales se
toman en cuenta para poder desarrollar el diseo con calidad y as poder ofrecer un diseo
amigable en cuestin de colores, tamaos de botones, cajas de texto, etc.

El tercer paso es la codificacin es aqu donde se desarrolla todo el cdigo del

sistema esto se hace ya dependiendo de cada programador ya que cada uno tiene sus bases
o formas para realizarlo pero en si deben todos llegar al mismo objetivo de ofrecerle
funcionalidad al sistema siempre y cuando apegando se a las especificaciones del cliente.

El cuarto paso son las pruebas, es donde al sistema se pone a prueba como su
palabra lo dice para as poder saber cules son los posibles errores que se estn generando
del sistema y con ello mejorarlo para eliminar dichos errores.

El quinto y ltimo paso es la instalacin una vez realizado las pruebas

correspondientes al sistema y haberlo corregido totalmente se procede a la instalacin del
mismo ya en la empresa para su uso correspondiente, todo con la finalidad de que los
procesos se realicen de una manera ms eficiente disminuyendo costos, tiempo y esfuerzo
dentro de la organizacin.

UML

Lenguaje Unificado de Modelado (UML, por sus siglas en ingls, Unified Modeling
Language) es el lenguaje de modelado de sistemas de software ms conocido y utilizado en
la actualidad. Es un lenguaje grfico para visualizar, especificar, construir y documentar un
sistema. Ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo
aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos

concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y

compuestos reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o

para describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los
artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en
el que est descrito el modelo. Se puede aplicar en el desarrollo de software gran variedad
de formas para dar soporte a una metodologa de desarrollo de software (tal como el
Proceso Unificado Racional o RUP), pero no especfica en s mismo qu metodologa o
proceso usar. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes
aspectos de las entidades representadas.

UML no puede compararse con la programacin estructurada, pues no es programacin,

solo se diagrama la realidad de una utilizacin en un requerimiento. Mientras que,
programacin estructurada, es una forma de programar como lo es la orientacin a objetos,
la programacin orientada a objetos viene siendo un complemento perfecto de UML, pero
no por eso se toma slo para lenguajes orientados a objetos.

ORIGEN DE UML

El lenguaje UML comenz a gestarse en octubre de 1994, cuando

Rumbaugh se uni a la compaa Rational fundada por Booch (dos reputados
investigadores en el rea de metodologa del software).

El objetivo de ambos era unificar dos mtodos que haban desarrollado: el

mtodo Booch y el OMT (Object Modelling Tool ). El primer borrador apareci en octubre
de 1995. En esa misma poca otro reputado investigador, Jacobson, se uni a Rational y se
incluyeron ideas suyas. Estas tres personas son conocidas como los tres amigos. Adems,
este lenguaje se abri a la colaboracin de otras empresas para que aportaran sus ideas.
Todas estas colaboraciones condujeron a la definicin de la primera versin de UML.

El desarrollo de UML comenz a finales de 1994 cuando Grady Booch y Jim

Rumbaugh de Rational Software Corporation empezaron a unificar sus mtodos. A finales
de 1995, Ivar Jacob son y su compaa Objectory se incorporaron a Rational en su
unificacin, aportando el mtodo OOSE.

En 1997 UML 1.1 fue aprobada por la OMG convirtindose en la notacin

estndar

de

facto

para

el

anlisis

el

diseo

orientado

objetos.

UML es el primer mtodo en publicar un meta-modelo en su propia notacin, incluyendo la

notacin para la mayora de la informacin de requisitos, anlisis y diseo. Se trata pues de
una meta-modelo auto-referencial (cualquier lenguaje de modelado de propsito general
debera ser capaz de modelarse a s mismo).

EVOLUCIN UML
Grady Booch y Jim Rumbaugh comenzaron a unificar sus
mtodos (Octubre, 1994).
Borrador de UML (versin 0.8) (Octubre, 1995)
Ivar Jacobson se une al proyecto (Noviembre, 1995).
UML 0.9 y se crea un consorcio (Junio, 1996)
OMG lanza una peticin para un lenguaje unificado (1996)
UML 1.0 es ofrecido al OMG (Enero, 1997)
Se extiende el consorcio (EneroJulio, 1997)
UML 1.1 es ofrecido al OMG (Julio, 1997)
OMG adopta UML 1.1 (Noviembre, 1997)
Se crea el UML RTF (1998)
Aparece UML 1.3 (Mayo 1999)
UML 2.0 en 2001 (se est revisando)

MODELOS TRADICIONALES DE DESARROLLO DE SOFTWARE

Los modelos de desarrollo de software son una representacin abstracta de una

manera en particular. Realmente no representa cmo se debe desarrollar el software, sino
de un enfoque comn. Puede ser modificado y adaptado de acuerdo a las necesidades del
software en proceso de desarrollo. Hay varios modelos para perfilar el proceso de
desarrollo, cada uno de las cuales cuenta con pros y contras. El proyecto debera escoger el
ms apropiado para sus necesidades. En ocasiones puede que una combinacin de varios
modelos sea apropiado.

Un modelo de ciclo de vida del software describe las fases principales de desarrollo
de software, define las fases primarias esperadas de ser ejecutadas durante esas fases, ayuda
a administrar el progreso del desarrollo y provee un espacio de trabajo para la definicin de
un proceso detallado de desarrollo de software. En cada una de las etapas de un modelo de
desarrollo de software, se pueden establecer una serie de objetivos, tareas y actividades que
lo caracterizan. A continuacin se muestran algunos de los modelos tradicionales y ms
utilizados.

Modelo en cascada

Es el enfoque metodolgico que ordena rigurosamente las etapas del ciclo de vida
del software, de forma que el inicio de cada etapa debe esperar a la finalizacin de la
inmediatamente anterior. El modelo en cascada es un proceso de desarrollo secuencial, en
el que el desarrollo se ve fluyendo hacia abajo (como una cascada) sobre las fases que
componen el ciclo de vida.

En el modelo original de Royce, existan las siguientes fases:

1. Especificacin de requisitos
2. Diseo
3. Construccin (Implementacin o codificacin)

4. Integracin
5. Pruebas
6. Instalacin
7. Mantenimiento
Para seguir el modelo en cascada, se avanza de una fase a la siguiente en una forma
puramente secuencial.

Modelo de desarrollo en cascada

Ventajas

Funciona bien para proyectos pequeos donde los requisitos estn bien entendidos.

Es simple y fcil de usar.

Las fases son procesadas y completadas de una vez.

Desventajas

Es muy restrictivo y no permite movilizarse entre fases, lo que puede llevar a una
mala implementacin del modelo.

Los resultados y/o mejoras no son visibles progresivamente, el producto se ve

cuando ya est finalizado, lo cual provoca una gran inseguridad por parte del
cliente.

Genera altas cantidades de riesgos e incertidumbres.

Modelo en V

El modelo en v se desarroll para terminar con algunos de los problemas que se

vieron utilizando el enfoque de cascada tradicional. Los defectos estaban siendo
encontrados demasiado tarde en el ciclo de vida, ya que las pruebas no se introducan hasta
el final del proyecto. El modelo en v dice que las pruebas necesitan empezarse lo ms
pronto posible en el ciclo de vida. Tambin muestra que las pruebas no son slo una
actividad basada en la ejecucin.

Existe una variedad de actividades que se han de realizar antes del fin de la fase de
codificacin. Estas actividades deberan ser llevadas a cabo en paralelo con las actividades
de desarrollo, y los tcnicos de pruebas necesitan trabajar con los desarrolladores y
analistas de negocio de tal forma que puedan realizar estas actividades y tareas y producir
una serie de entregables de pruebas. Los productos de trabajo generados por los
desarrolladores y analistas de negocio durante el desarrollo son las bases de las pruebas en
uno o ms niveles. El modelo en v es un modelo que ilustra cmo las actividades de prueba
(verificacin y validacin) se pueden integrar en cada fase del ciclo de vida. Dentro del
modelo en v, las pruebas de validacin tienen lugar especialmente durante las etapas
tempranas, por ejemplo, revisando los requisitos de usuario y despus por ejemplo, durante
las pruebas de aceptacin de usuario.

El modelo en v es un proceso que representa la secuencia de pasos en el desarrollo

del ciclo de vida de un proyecto. Describe las actividades y resultados que han de ser
producidos durante el desarrollo del producto. La parte izquierda de la v representa la
descomposicin de los requisitos y la creacin de las especificaciones del sistema. El lado
derecho de la v representa la integracin de partes y su verificacin. V significa
Validacin y Verificacin.

Modelo de desarrollo en V

Realmente las etapas individuales del proceso pueden ser casi las mismas que las
del modelo en cascada. Sin embargo hay una gran diferencia. En vez de ir para abajo de
una forma lineal las fases del proceso vuelven hacia arriba tras la fase de codificacin,
formando una v. La razn de esto es que para cada una de las fases de diseo se ha
encontrado que hay un homlogo en las fases de pruebas que se correlacionan.

Ventajas

Es un modelo simple y fcil de utilizar.

En cada una de las fases hay entregables especficos.

Tiene una alta oportunidad de xito sobre el modelo en cascada debido al desarrollo
de planes de prueba en etapas tempranas del ciclo de vida.

Es un modelo que suele funcionar bien para proyectos pequeos donde los
requisitos son entendidos fcilmente.

Desventajas

Es un modelo muy rgido, como el modelo en cascada.

Tiene poca flexibilidad y ajustar el alcance es difcil y caro.

El software se desarrolla durante la fase de implementacin, por lo que no se

producen prototipos del software.

Modelo iterativo

Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el
riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos
durante la etapa de recogida de requisitos. Consiste en la iteracin de varios ciclos de vida
en cascada. Al final de cada iteracin se le entrega al cliente una versin mejorada o con
mayores funcionalidades del producto. El cliente es quien despus de cada iteracin evala
el producto y lo corrige o propone mejoras. Estas iteraciones se repetirn hasta obtener un
producto que satisfaga las necesidades del cliente.

Modelo de desarrollo iterativo

Este modelo se suele utilizar en proyectos en los que los requisitos no estn claros por parte
del usuario, por lo que se hace necesaria la creacin de distintos prototipos para
presentarlos y conseguir la conformidad del cliente.

Ventajas

No hace falta que los requisitos estn totalmente definidos al inicio del desarrollo,
sino que se pueden ir refinando en cada una de las iteraciones.

Puede realizar el desarrollo en pequeos ciclos, lo que permite gestionar mejor los
riesgos, gestionar mejor las entregas.

Desventajas

La primera de las ventajas que ofrece este modelo, es el no ser necesario tener los
requisitos definidos desde el principio, pero puede verse tambin como un
inconveniente ya que pueden surgir problemas relacionados con la arquitectura.

Modelo de desarrollo incremental

El modelo incremental combina elementos del modelo en cascada con la filosofa

interactiva de construccin de prototipos. Se basa en la filosofa de construir incrementando
las funcionalidades del programa. Este modelo aplica secuencias lineales de forma
escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un
incremento del software.

Modelo de desarrollo incremental

Ventajas

Mediante este modelo se genera software operativo de forma rpida y en etapas

tempranas del ciclo de vida del software.

Es un modelo ms flexible, por lo que se reduce el coste en el cambio de alcance y

requisitos.

Es ms fcil probar y depurar en una iteracin ms pequea.

Es ms fcil gestionar riesgos.

Cada iteracin es un hito gestionado fcilmente.

Desventajas

Para el uso de este modelo se requiere una experiencia importante para definir los
incrementos y distribuir en ellos las tareas de forma proporcionada.

Cada fase de una iteracin es rgida y no se superponen con otras.

Pueden surgir problemas referidos a la arquitectura del sistema porque no todos los
requisitos se han reunido, ya que se supone que todos ellos se han definido al inicio.

Modelo en espiral

La principal caractersticas del modelo en espiral es la gestin de riesgos de forma

peridica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm,
combinando algunos aspectos clave de las metodologas del modelo de cascada y del
desarrollo rpido de aplicaciones, pero dando nfasis en un rea que para muchos no jug el
papel que requiere en otros modelos: un anlisis iterativo y concienzudo de los riesgos,
especialmente en el caso de sistema complejos de gran escala.

La espiral se visualiza como un proceso que pasa a travs de algunas iteraciones con el
diagrama de los cuatro cuadrantes representativos de las siguientes actividades:

Crear planes con el propsito de identificar los objetivos del software, seleccionados
para implementar el programa y clarificar las restricciones en el desarrollo del
software.

Anlisis de riesgos: una evaluacin analtica de programas seleccionados, para

evaluar cmo identificar y eliminar el riesgo.

La implementacin del proyecto: implementacin del desarrollo del software y su

pertinente verificacin;

Modelo de espiral con nfasis en los riesgos, haciendo hincapi en las condiciones de
las opciones y limitaciones para facilitar la reutilizacin de software, la calidad del software
puede ayudar como una meta propia en la integracin en el desarrollo del producto. Sin
embargo, el modelo en espiral tiene algunas limitaciones, entre las que destacan:

El nfasis se sita en el anlisis de riesgo, y por lo tanto requiere de clientes que

acepten este anlisis y acten en consecuencia. Para ello es necesaria confianza en
los desarrolladores as como la predisposicin a gastar ms para solventar los temas,
por lo cual este modelo se utiliza frecuentemente en desarrollo interno de software a
gran escala.

Si la implementacin del riesgo de anlisis afectar de forma esencial los beneficios

del proyecto, no debera utilizarse este modelo.

Los desarrolladores de software han de buscar de forma explcita riesgos y

analizarlos de forma exhaustiva para que este modelo funcione.

La primera fase es la bsqueda de un plan para conseguir los objetivos con las limitaciones
del proyecto para as buscar y eliminar todos los riesgos potenciales por medio de un
cuidadoso anlisis, y si fuera necesario incluyendo la fabricacin de un prototipo. Si es
imposible descartar algunos riesgos, el cliente ha de decidir si es conveniente terminar el

proyecto o seguir adelante ignorando los riesgos. Por ltimo, se evalan los resultados y se
inicia el diseo de la siguiente fase.

Modelo de desarrollo en espiral

Las cuatro regiones del grfico son:

La tarea de planificacin: para definir recursos, responsabilidades, hitos y

planificaciones.

La tarea de determinacin de objetivos: para definir los requisitos y las restricciones

para el producto y definir las posibles alternativas.

La tarea de anlisis de riesgos: para evaluar riesgos tanto tcnicos como de gestin.

La tarea de ingeniera: para disear e implementar uno o ms prototipos o ejemplos

de la aplicacin.

Modelo de Prototipos

Un cliente, a menudo, define un conjunto de objetivos generales para el software,

pero no identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el
responsable del desarrollo del software puede no estar seguro de la eficiencia de un
algoritmo, de la calidad de adaptacin de un sistema operativo, o de la forma en que debera

tomarse la interaccin hombre-mquina. En estas y en otras muchas situaciones, un

paradigma de construccin de prototipos puede ofrecer el mejor enfoque.

El paradigma de construccin de prototipos comienza con la recoleccin de

requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el
software, identifican los requisitos conocidos y las reas del esquema en donde es
obligatoria ms definicin. Entonces aparece un diseo rpido. El diseo rpido se centra
en una representacin de esos aspectos del software que sern visibles para el
usuario/cliente. El diseo rpido lleva a la construccin de un prototipo. El prototipo lo
evala el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La
iteracin ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del
cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se
necesita hacer.

Modelo de desarrollo de prototipos

Ventajas

Ofrece visibilidad del producto desde el inicio del ciclo de vida con el primer
prototipo. Esto puede ayudar al cliente a definir mejor los requisitos y a ver las
necesidades reales del producto.

Permite introducir cambios en las iteraciones siguientes del ciclo.

Permite la realimentacin continua del cliente.

El prototipo es un documento vivo de buen funcionamiento del producto final. El

cliente reacciona mucho mejor ante el prototipo, sobre el que puede experimentar,
que no sobre una especificacin escrita.

Este modelo reduce el riesgo de construir productos que no satisfagan las

necesidades de los usuarios.

Desventajas

Puede ser un desarrollo lento.

Se hacen fuertes inversiones en un producto desechable ya que los prototipos se

descartan. Esto puede hacer que aumente el coste de desarrollo del producto.

Con este modelo pueden surgir problemas con el cliente que ve funcionando
versiones del prototipo pero puede desilusionarse porque el producto final an no ha
sido construido. El desarrollador puede caer en la tentacin de ampliar el prototipo
para construir el sistema final sin tener en cuenta los compromisos de calidad y de
mantenimiento que tiene con el cliente.