METODOLOGIAS DE DESARROLLO.

METODOS DEL DESARROLLO DE SISTEMA DE INFORMACION:

Mtodos de Desarrollo de Sistemas Son Pautas de desarrollo brindado
por los modelos de ciclos de vida, los cuales estn constituidos por las
siguientes etapas: Especifcacin de requerimientos: Se realizan
entrevistas con el usuario identifcando los requerimientos
necesidades del usuario! "nlisis: Modela los requerimientos del usuario!
Dise#o: Se modela la solucin del sistema, teniendo en cuenta el
ambiente de implementacin a utilizar, por e$emplo, si el sistema es
centralizado o distribuido, la base de datos a utilizar, lengua$e de
programacin, per%ormance deseada, etc! &mplementacin: Dado el
lengua$e de programacin elegido se implementa el sistema! 'esteo: En
esta etapa se verifca valida el sistema teniendo en cuenta algunos
criterios determinados por el grupo correspondiente! Mantenimiento: Es
la etapa ms di%(cil de desarrollo del sistema, actualiza modifca el
sistema si surgen nuevos requerimientos! ME')D)*)+&"S DE*
DES",,)**) DE S&S'EM"S DE &-.),M"/&)- Son mtodos que indican
cmo 0acer ms efciente el desarrollo de sistemas de in%ormacin! Para
ello suelen estructurar en %ases la vida de dic0os sistemas con el fn de
%acilitar su planifcacin, desarrollo mantenimiento! *as metodolog(as
de desarrollo de sistemas deben defnir: ob$etivos, %ases, tareas,
productos responsables, necesarios para la correcta realizacin del
proceso su seguimiento! *os principales ob$etivos de una metodolog(a
de desarrollo son: 1 "segurar la uni%ormidad calidad tanto del
desarrollo como del sistema en s(! 1 Satis%acer las necesidades de los
usuarios del sistema! 1 /onseguir un maor nivel de rendimiento
efciencia del personal asignado al desarrollo! 1 "$ustarse a los plazos
costes previstos en la planifcacin! 1 +enerar de %orma adecuada la
documentacin asociada a los sistemas! 1 .acilitar el mantenimiento
posterior de los sistemas!
ME')D) DE /"S/"D" P2," 3
En un modelo en cascada, un proecto progresa a travs de una
secuencia ordenada de pasos partiendo de la especifcacin de
requerimientos 0asta el mantenimiento del mismo! El mtodo realiza
una revisin al fnal de cada etapa para determinar si est preparado
para pasar a la siguiente etapa, por e$emplo, desde el anlisis de
requerimientos 0asta el dise#o! /uando la revisin determina que el
proecto no est listo pasar a la siguiente, permanece en la etapa actual
0asta que est preparado! El modelo en cascada est dirigido por
documentos! "uda a localizar errores en las primeras etapas del
proecto a un ba$o costo! "uda a minimizar los gastos de la
planifcacin porque permite realizarla sin planifcacin porque permite
realizarla sin problemas! .unciona especialmente bien si se dispone de
personal poco cualifcado o dispone de personal poco cualifcado o
ine4perto, porque presenta el proecto ine4perto, porque presenta el
proecto con una estructura que auda a minimizar con una estructura
el es%uerzo in5til! En resumen, los inconvenientes del venerado modelo
en cascada 0acen que sea, a menudo, un modelo poco apropiado para
un proecto de desarrollo rpido! &ncluso en los casos en los que las
venta$as del modelo en cascada pura superan los inconvenientes, los
modelos de cascada modifcada 6con retroceso7 pueden %uncionar me$or!
*as desventa$as del modelo se centran en las difcultades para
especifcar claramente los requerimientos al comienzo del proecto,
antes de que se realice ning5n traba$o de dise#o antes de escribir
ning5n cdigo! -o proporciona resultados tangibles en %orma de so%t8are
0asta el fnal del ciclo de %orma de so%t8are del ciclo de vida de "lgunas
0erramientas, mtodos actividades que abarcan varias etapas de la
cascada9 estas actividades son di%(ciles de a$ustar en las etapas
discontinuas del modelo para un proecto de desarrollo rpido, el
modelo en cascada puede suponer una cantidad e4cesiva de
documentacin! El modelo genera pocos signos visibles de progreso
0asta el fnal! Esto puede dar la impresin de un desarrollo lento, e4iste
la incertidumbre de los clientes si sus proectos sern entregados a
tiempo! ME')D) ESP&,"* Es un modelo de ciclo de vida orientado a
riesgos que divide un proecto so%t8are en mini:proectos! /ada mini
proecto se centra en uno o ms riesgos importantes 0asta que todos
estn controlados! Despus de controlar todos los riesgos ms
importantes, el modelo en espiral fnaliza del mismo modo que el ciclo
de vida en cascada! Mtodo Desarrollo en Espiral .uncionamiento: Se
parte de una escala peque#a en medio de la espiral, se localizan los
riesgos, se genera un plan para mane$ar los riesgos, a continuacin se
establece una apro4imacin a la siguiente interaccin!
;! /ada iteracin supone que el proecto pasa a una escala superior! Se
avanza un nivel en el Espiral, se comprueba que se tiene lo que se
desea, despus se comienza a traba$ar en el siguiente nivel: /on cada
iteracin a travs del espiral se construe sucesivas versiones de
so%t8are cada vez ms completas! En cada bucle alrededor del espiral, la
culminacin del anlisis de riesgo resulta una decisin de seguir o no
seguir! /ada interaccin en el mtodo espiral lleva consigo los seis pasos
que a continuacin se nombran: Determinar ob$etivos, alternativas
l(mites, &dentifcar resolver riesgos, Evaluar alternativas, +enerar las
entregas de esa iteracin, comprobar que son correctas! En el modelo
en espiral, las primeras iteraciones son las menos costosas! Supone
menos gasto desarrollar el concepto de operacin que realizar el
desarrollo de los requerimientos, tambin es menos costoso desarrollar
los requerimientos que llevar a cabo el desarrollo del dise#o, la
implementacin del producto la prueba del mismo! En cada /uadrante
del Mtodo espiral se realiza las siguientes actividades: Planifcacin:
Determinacin de ob$etivos, alternativas, restricciones, elaboracin del
plan de desarrollo para el ciclo actual! "nlisis de ,iesgos: Evaluacin de
las alternativas, identifcacin resolucin de riesgos! Se decide si se
sigue o no con el proecto &ngenier(a: Desarrollo del producto siguiendo
un modelo: del ciclo de vida o cascada, prototipo, etc! Evaluacin por el
cliente, <aloracin de resultados! ME')D) DE /)D&.&/", = /),,E+&,
6/ode:and:f47 Es un modelo poco 5til, pero sin embargo bastante
com5n Se puede tener una especifcacin %ormal, o no tenerla Si no se
0a utilizado %ormalmente un mtodo, probablemente a se est usando
el mtodo /odifcar /orregir en %orma intuitiva /uando se utiliza ste
mtodo se empieza con una idea general de lo que se necesita construir,
Se utiliza cualquier combinacin de dise#o, cdigo, depuracin
mtodos de prueba no %ormales que sirven 0asta que se tiene el
producto listo para entregarlo! <enta$as: -o conlleva ninguna gestin9 no
se pierde tiempo en la planifcacin, en la documentacin, en el control
de calidad, en el cumplimiento de los estndares, o en cualquier otra
actividad que no sea codifcacin pura! /omo se pasa directamente a
codifcar, se pueden mostrar inmediatamente indicios de progreso!
>! ,equiere poca e4periencia: cualquier persona que 0aa escrito alguna
vez un programa est %amiliarizada con ste modelo! Para proectos
peque#os que se intentan liquidar en un tiempo breve, o para modelos
como programas de demostracin o prototipos desec0ables, el modelo
codifcar corregir puede ser 5til! Desventa$as: El modelo resulta
peligroso para otro tipo de proectos que no sean peque#os! Puede que
no suponga gestin alguna, pero tampoco o%rece medios de evaluacin
del progreso! -o proporciona medios de evaluacin de la calidad o de
identifcacin de riesgos! Si al llevar tres cuartas partes de la
codifcacin descubre que el dise#o es incorrecto, no 0a otra solucin
que desec0ar el traba$o comenzar de nuevo! ME')D) P,)')'&P) Este
mtodo 0ace que el usuario participe de manera ms directa en la
e4periencia de anlisis dise#o que cualquiera de los a presentados!
*a construccin de prototipos es mu efcaz ba$o las circunstancias
correctas! Sin embargo, al igual que los otros mtodos, el mtodo es 5til
slo si se emplea en el momento adecuado en la %orma apropiada!
?@u es un prototipoA El prototipo es un sistema que %unciona, no solo
una idea en el papel, desarrollado con la fnalidad de probar ideas
suposiciones relacionadas con el nuevo sistema! "l igual que cualquier
sistema basado en computadora, est constituido por so%t8are que
acepta entradas, realiza clculos, produce in%ormacin a sea impresa o
presentada en una pantalla, o que lleva a cabo otras actividades
signifcativas! Es la primera versin, o iteracin, de un sistema de
in%ormacin! *o usuarios eval5an el dise#o la in%ormacin generada por
el sistema! *o anterior slo puede 0acerse con e%ectividad si los datos
utilizados, al igual que las situaciones, son reales! Por otra parte, deben
esperarse cambios a medida que el sistema es utilizado! ,azones para
desarrollar prototipos de sistemas: *os requerimientos de in%ormacin no
siempre estn bienB defnidos! Es probable que los usuarios conozcan
slo ciertas reas de la empresa donde se necesiten me$oras o cambios
en los procedimientos actuales! 'ambin es posible que reconozcan la
necesidad de tener me$or in%ormacin para administrar ciertas
actividades pero que no estn seguros cual de esta in%ormacin ser la
adecuada! *os requerimientos del usuario pueden ser demasiado vagos
aun al %ormular el dise#o! En otros casos, es probable que una
investigacin de sistemas bien llevada necesite del desarrollo de nueva
tecnolog(a! *os prototipos permiten evaluar situaciones e4traordinarias
donde los encargados de dise#ar e implantar sistemas no tienen
in%ormacin ni e4periencia, o tambin donde e4isten situaciones de
riesgo costo elevados, aquellas donde el dise#o propuesto es
novedoso a5n no se demuestra es la %actibilidad de que los
vendedores env(en ordenes de pedido al sistema de cmputo de la
compa#(a desde el sitio donde e%ect5an la operacin por medio de
terminales porttiles enlazadas a tel%onos p5blicos! Para probar el
concepto los administradores encargados de sistemas pueden optar
por construir una versin en peque#a escala del so%t8are, adquirir unas
cuantas terminales seleccionar un grupo de vendedores!
C! El prototipo proporcionar &n%ormacin preliminar sobre la
%uncionalidad del concepto! El prototipo es, en realidad, un modelo piloto
o de prueba, en general, los analistas de sistemas encuentran que los
prototipos tienen maor utilidad ba$o las siguientes condiciones: 1 *os
encargados de dise#ar e implantar sistemas nunca 0an desarrollado uno
con las caracter(sticas del sistema propuesto! 1 Se conoce slo una parte
de las caracter(sticas esenciales del sistema9 las dems no son
identifcables a pesar de un cuidadoso anlisis de requerimientos! 1 *a
e4periencia con el uso del sistema a#adir una lista signifcativa de
requerimientos que el sistema debe satis%acer! 1 *as di%erentes
versiones del sistema evolucionan con la e4periencia al igual que el
desarrollo adicional el refnamiento de sus caracter(sticas! 1 *os
usuarios del sistema participan en el proceso de desarrollo! *os pasos a
seguir en el proceso de desarrollo de prototipos son los siguientes: D
&dentifcar los requerimientos de in%ormacin que el usuario conoce $unto
con las caracter(sticas necesarias del sistema! Desarrollar un prototipo
que %uncione! 2tilizar el prototipo anotando las necesidades de cambios
me$oras! Esto e4pande la lista de los requerimientos de sistemas
conocidos! ,evisar el prototipo con base en la in%ormacin obtenida a
travs de la e4periencia del usuario! D ,epetir los pasos anteriores las
veces que sea necesario 0asta obtener un sistema satis%actorio! El
analista debe de reunirse con los usuarios una o dos veces con la
fnalidad de identifcar los requerimientos! El resultado de estas
reuniones %orma la base para la construccin del prototipo! El desarrollo
de un prototipo que %uncione es responsabilidad del analista de
sistemas, cuando el analista el usuario deciden que cuentan a con la
sufciente in%ormacin proveniente del proceso de construccin del
prototipo, determinan cmo satis%acer los requerimientos a
identifcados! En general se opta por una de las siguientes opciones:
<olver a desarrollar el prototipo! Esta alternativa quiz signifque volver
a programar por completo, empezando desde el principio! &mplantar el
prototipo como sistema terminado *a efciencia en el %uncionamiento
$unto con los mtodos para interactuar con el usuario es sufciente9 esto
permite utilizar el sistema tol como est! "bandonar el proecto! En
este caso el prototipo 0a proporcionado in%ormacin sufciente para
demostrar que no es posible desarrollar el sistema para satis%acer los
ob$etivos deseados dentro del marco de la tecnolog(a e4istente o de
lineamientos econmicos u operacionales! &niciar otra serie de
construccin de prototipos! *a in%ormacin ganada con la e4periencia
sugiere a sea un
F! En%oque totalmente distinto o caracter(sticas contrastantes! /ada una
de estas opciones se considera como un 4ito en el proceso de la
construccin de prototipos! Mtodos para el desarrollo de prototipos /on
los prototipos la velocidad de desarrollo es ms importante que la
efciencia en el procesamiento! 2n sistema prototipo se construe con
rapidez, los sistemas prototipo pueden desarrollarse con mtodos
lengua$es de programacin convencionales, quiz %alten los controles de
entrada procesamiento , en general, la documentacin del sistema es
un punto que suele evitarse! *o importante es ensaar ideas generar
0iptesis relacionadas con los requerimientos que la efciencia
per%eccin alcanzadas! *a industria de computadora busca
continuamente generadores de aplicaciones, programas que sirven para
generar otros programas, para apoar los es%uerzos de la construccin
de prototipos! En algunos casos, aquellos donde el sistema ser utilizado
con poca %recuencia, el prototipo puede, de 0ec0o, convertirse en el
sistema terminado! ME')D) DE "-"*&S&S = D&SEG) ES',2/'2,"D) D
Muc0os especialistas en sistemas de in%ormacin reconocen la difcultad
de comprender de manera completa sistemas grandes comple$os! El
mtodo de desarrollo del anlisis estructurado tiene como fnalidad
superar sa difcultad por medio de 37 la divisin del sistema en
componentes ;7 la construccin de un modelo del sistema! El mtodo
incorpora elementos tanto de anlisis como de dise#o! ?@u es el
anlisis estructuradoA El anlisis estructurado concentra en especifcar
lo que se requiere que 0aga el sistema o la aplicacin! -o se establece
cmo se cumplirn los requerimientos o la %orma en que implantar la
aplicacin! Ms bien permite que las personas observen los elementos
lgicos 6lo que 0ar el sistema7 separados de los componentes %(sicos
6computadoras, terminales, sistemas de almacenamiento, etc!7 Despus
de esto se puede desarrollar un dise#o %(sico efciente para la situacin
donde ser utilizado! Elementos del anlisis estructurado: *os elementos
esenciales son s(mbolos grfcos, diagramas de Hu$o de datos
diccionario centralizado de datos! Descripcin grfca 2na de las %ormas
de describir un sistema es preparar un bosque$o que se#ale sus
caracter(sticas, identifque la %uncin para la que sirve e indique cmo
ste interact5a con otros elementos, entre otras cosas! Sin embargo,
describir de esta manera un sistema grande es un proceso tedioso
propenso a errores a que es %cil omitir alg5n detalle o dar una
e4plicacin que quiz los dems no entiendan! En lugar de las palabras
el anlisis estructurado utiliza s(mbolos, o (conos, para crear un modelo
grfco del sistema! *os modelos de este tipo muestran los detalles del
sistema! Si se seleccionan los s(mbolos notacin correctos entonces
casi cualquier persona puede seguir la %orma en que los componentes se
acomodarn entre si para %ormar el sistema! El diagrama lgico de Hu$o
de datos muestra las %uentes destinos de los datos, identifca da
nombre a los procesos que se llevan a cabo, identifca da nombre a los
grupos de datos que relacionan una %uncin con otra se#ala los
almacenes de datos a los que se tiene acceso!
I! Diagrama de Hu$o de datos: El modelo del sistema recibe el nombre
de diagrama de Hu$o de datos 6D.D7! *a descripcin completa de un
sistema est %ormada por un con$unto de diagramas de Hu$o de datos!
Para desarrollar una descripcin del sistema por el mtodo de anlisis
estructurado se sigue un proceso descendente 6')P:Do8n7! El modelo
original se detalla en diagramas de ba$o nivel que muestran
caracter(sticas adicionales del sistema! /ada proceso puede desglosarse
en diagramas de Hu$o de datos cada vez ms detallados! Esta secuencia
se repite 0asta que se obtienen sufcientes detalles que permiten al
analista comprender en su totalidad la parte del sistema que se
encuentra ba$o investigacin! Diccionario de datos: 'odas las
defniciones de los elementos en el sistema 6Hu$o de datos, procesos
almacenes de datos7 estn descritos en %orma detallada en el diccionario
de datos! Si alg5n miembro del equipo encargado del proecto desea
saber alguna defnicin del nombre de un dato o el contenido particular
de un Hu$o de datos, esta in%ormacin debe encontrarse disponible en el
diccionario de datos! ?@ue es el dise#o estructurado ? Se en%oca en el
desarrollo de especifcaciones del so%t8are! *a meta del dise#o
estructurado es crear programas %ormados por mdulos independientes
unos de otros desde el punto de vista %uncional! El dise#o estructurado
es una tcnica espec(fca para el dise#o de programas no un mtodo
de dise#o de comprensin! Esta tcnica conduce a la especifcacin de
mdulos de programa que son %uncionalmente independientes! *a
0erramienta %undamental del dise#o estructurado es el diagrama
estructurado, los cuales son de naturaleza grfca evitan cualquier
re%erencia relacionada con el 0ard8are o detalles %(sicos! Su fnalidad no
es mostrar la lgica de los programas! *os diagramas estructurados
describen la interaccin entre mdulos independientes $unto con los
datos que un mdulo pasa a otro cuando interacciona con l! Estas
especifcaciones %uncionales para los mdulos se proporcionan a los
programadores antes que d comienzo la %ase de escritura de cdigo!
Empleo del "nlisis estructurado con otros mtodos de desarrollo: El
anlisis estructurado se combina, con bastante %recuencia, con el
mtodo a presentado de ciclo de vida clsico de desarrollo de sistemas!
Por e$emplo, los analistas pueden optar ms de Hu$o de datos como una
%orma para documentar las relaciones entre componentes durante la
investigacin detallada de alg5n sistema e4istente, "simismo, se puede
defnir los arc0ivos datos en un diccionario centralizado de datos de
acuerdo con las reglas de anlisis estructurado! Sin embargo muc0as
organizaciones optan por no utilizar este mtodo de desarrollo! Por
e$emplo, los analistas deciden con %recuencia que el desarrollo de
diagramas esquemas es una tarea que consume muc0o tiempo, sobre
todo si el sistema es grande comple$o! 6Es com5n que los diagramas
tengan que dibu$arse una otra vez con%orme se adquiere nueva
in%ormacin7! /omo se ver ms adelante, se 0an desarrollado
0erramientas asistidas por computadora para superar este problema!
)tros analistas se#alan que los elementos que %altan, tales como las
personas los procedimientos de control, son parte del sistema mismo
no pueden omitirse en la descripcin de ste! Ms adelante se
considerar este aspecto tan importante!