Mtodo

Mtodo (del griego odos, significa "camino o va") es el procedimiento utilizado para
llegar a un fin. Su significado original seala el camino que conduce a un lugar.
Las investigaciones cientficas se rigen por el llamado mtodo cientfico, basado en
la observacin y la experimentacin, la recopilacin de datos, la comprobacin de
lashiptesis de partida.
La idea de mtodo puede hacer referencia a diversos conceptos de varios campos:

Metodologa

La metodologa (del griego de met 'ms all, despus, con',

ods 'camino' y logos 'razn, estudio'),1 hace referencia al conjunto de
procedimientos racionales utilizados para alcanzar una gama de objetivos que rigen
una investigacin cientfica, unaexposicin doctrinal2 o tareas que requieran habilidades,
conocimientos o cuidados especficos. Alternativamente puede definirse lametodologa como
el estudio o eleccin de un mtodo pertinente para un determinado objetivo. 3
No debe llamarse metodologa a cualquier procedimiento, ya que es un concepto que en la
gran mayora de los casos resulta demasiado amplio, siendo preferible usar el
vocablo mtodo.

Proceso
Un proceso es un conjunto de actividades mutuamente relacionadas o que al interactuar
transforman elementos de entrada y los convierten en resultados.1

En ciencias naturales, de la vida y de la salud[editar]

En medicina[editar]

en anatoma, el nombre alternativo de la apfisis;

un proceso de atencin son las intervenciones o procedimientos realizados;

En biologa[editar]

Proceso evolutivo;

En fsica[editar]

un proceso termodinmico;

los procesos nucleares;

En ciencias sociales[editar]

un proceso histrico;

en Argentina, el Proceso de Reorganizacin Nacional;

un proceso geogrfico;

En derecho[editar]

un proceso judicial;

En economa y empresa[editar]

un proceso productivo;

un proceso de negocio;

un componente o elemento del modelo de negocio;

En informtica[editar]

un proceso;

Publicaciones[editar]

Proceso, un semanario mexicano;

En manufactura e industria[editar]

un proceso de fabricacin;

el proceso de produccin del acero Bessemer;

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:
Especificacin de requerimientos:

Se realizan entrevistas con el usuario identificando los requerimientos y necesidades del

usuario.
Anlisis:
Modela los requerimientos del usuario.
Diseo:
Se modela la solucin del sistema, teniendo en cuenta el ambiente de implementacin a
utilizar, por ejemplo, si el sistema es centralizado o distribuido, la base de datos a utilizar,
lenguaje de programacin, performance deseada, etc.
Implementacin:
Dado el lenguaje de programacin elegido se implementa el sistema.
Testeo: En esta etapa se verifica y valida el sistema teniendo en cuenta algunos criterios
determinados por el grupo correspondiente.
Mantenimiento: Es la etapa ms difcil de desarrollo del sistema, actualiza y modifica el
sistema si surgen nuevos requerimientos.
METODOLOGIAS DEL DESARROLLO DE SISTEMAS DE INFORMACION
Son mtodos que indican cmo hacer ms eficiente el desarrollo de sistemas de informacin.
Para ello suelen estructurar en fases la vida de dichos sistemas con el fin de facilitar su
planificacin, desarrollo y mantenimiento.
Las metodologas de desarrollo de sistemas deben definir: objetivos, fases, tareas, productos
y responsables, necesarios para la correcta realizacin del proceso y su seguimiento.
Los principales objetivos de una metodologa de desarrollo son:

Asegurar la uniformidad y calidad tanto del desarrollo como del sistema en s.

Satisfacer las necesidades de los usuarios del sistema.

Conseguir un mayor nivel de rendimiento y eficiencia del personal asignado al

desarrollo.

Ajustarse a los plazos y costes previstos en la planificacin.

Generar de forma adecuada la documentacin asociada a los sistemas.

Facilitar el mantenimiento posterior de los sistemas.

METODO DE CASCADA PURA

En un modelo en cascada, un proyecto progresa a travs de una secuencia ordenada de
pasos partiendo de la especificacin de requerimientos hasta el mantenimiento del mismo.
El mtodo realiza una revisin al final de cada etapa para determinar si est preparado para
pasar a la siguiente etapa, por ejemplo, desde el anlisis de requerimientos hasta el diseo.
Cuando la revisin determina que el proyecto no est listo pasar a la siguiente, permanece en
la etapa actual hasta que est preparado.
El modelo en cascada est dirigido por documentos.
Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo.
Ayuda a minimizar los gastos de la planificacin porque permite realizarla sin planificacin
porque permite realizarla sin problemas.
Funciona especialmente bien si se dispone de personal poco cualificado o dispone de
personal poco cualificado o inexperto, porque presenta el proyecto inexperto, porque presenta
el proyecto con una estructura que ayuda a minimizar con una estructura el esfuerzo intil.
En resumen, los inconvenientes del venerado modelo en cascada hacen que sea, a menudo,
un modelo poco apropiado para un proyecto de desarrollo rpido. Incluso en los casos en los
que las ventajas del modelo en cascada pura superan los inconvenientes, los modelos de
cascada modificada (con retroceso) pueden funcionar mejor.
Las desventajas del modelo se centran en las dificultades para especificar claramente los
requerimientos al comienzo del proyecto, antes de que se realice ningn trabajo de diseo y
antes de escribir ningn cdigo.
No proporciona resultados tangibles en forma de software hasta el final del ciclo de forma de
software del ciclo de vida de Algunas herramientas, mtodos y actividades que abarcan varias
etapas de la cascada; estas actividades son difciles de ajustar en las etapas discontinuas del
modelo para un proyecto de desarrollo rpido, el modelo en cascada puede suponer una
cantidad excesiva de documentacin.
El modelo genera pocos signos visibles de progreso hasta el final. Esto puede dar la impresin
de un desarrollo lento, existe la incertidumbre de los clientes si sus proyectos sern
entregados a tiempo.
METODO ESPIRAL
Es un modelo de ciclo de vida orientado a riesgos que divide un proyecto software en miniproyectos.

Cada mini proyecto se centra en uno o ms riesgos importantes hasta que todos estn
controlados.
Despus de controlar todos los riesgos ms importantes, el modelo en espiral finaliza del
mismo modo que el ciclo de vida en cascada.
Mtodo Desarrollo en Espiral
Funcionamiento:
Se parte de una escala pequea en medio de la espiral, se localizan los riesgos, se genera un
plan para manejar los riesgos, y a continuacin se establece una aproximacin a la siguiente
interaccin.
Cada iteracin supone que el proyecto pasa a una escala superior. Se avanza un nivel en el
Espiral, se comprueba que se tiene lo que se desea, y despus se comienza a trabajar en el
siguiente nivel:
Con cada iteracin a travs del espiral se construye sucesivas versiones de software cada vez
ms completas. En cada bucle alrededor del espiral, la culminacin del anlisis de riesgo
resulta una decisin de seguir o no seguir.
Cada interaccin en el mtodo espiral lleva consigo los seis pasos que a continuacin se
nombran: Determinar objetivos, alternativas y lmites, Identificar y resolver riesgos, Evaluar
alternativas,
Generar las entregas de esa iteracin, y 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, y tambin es menos costoso desarrollar los requerimientos que llevar a cabo
el desarrollo del diseo, la implementacin del producto y la prueba del mismo.
En cada Cuadrante del Mtodo espiral se realiza las siguientes actividades:
Planificacin:
Determinacin de objetivos, alternativas, restricciones, y elaboracin del plan de desarrollo
para el ciclo actual.
Anlisis de Riesgos:
Evaluacin de las alternativas, identificacin y resolucin de riesgos. Se decide si se sigue o
no con el proyecto

Ingeniera:
Desarrollo del producto siguiendo un modelo: del ciclo de vida o cascada, prototipo, etc.
Evaluacin por el cliente, Valoracin de resultados.
METODO DE CODIFICAR Y CORREGIR
(Code-and-fix)
Es un modelo poco til, pero sin embargo bastante comn Se puede tener una especificacin
formal, o no tenerla Si no se ha utilizado formalmente un mtodo, probablemente ya se est
usando el mtodo Codificar y Corregir en forma intuitiva Cuando se utiliza ste mtodo se
empieza con una idea general de lo que se necesita construir, Se utiliza cualquier combinacin
de diseo, cdigo, depuracin y mtodos de prueba no formales que sirven hasta que se tiene
el producto listo para entregarlo.
Ventajas:
No conlleva ninguna gestin; no se pierde tiempo en la planificacin, en la documentacin, en
el control de calidad, en el cumplimiento de los estndares, o en cualquier otra actividad que
no sea codificacin pura.
Como se pasa directamente a codificar, se pueden mostrar inmediatamente indicios de
progreso.
Requiere poca experiencia: cualquier persona que haya escrito alguna vez un programa est
familiarizada con ste modelo.
Para proyectos pequeos que se intentan liquidar en un tiempo breve, o para modelos como
programas de demostracin o prototipos desechables, el modelo codificar y corregir puede ser
til.
Desventajas:
El modelo resulta peligroso para otro tipo de proyectos que no sean pequeos.
Puede que no suponga gestin alguna, pero tampoco ofrece medios de evaluacin del
progreso.
No proporciona medios de evaluacin de la calidad o de identificacin de riesgos.
Si al llevar tres cuartas partes de la codificacin descubre que el diseo es incorrecto, no hay
otra solucin que desechar el trabajo y comenzar de nuevo.
METODO PROTOTIPO

Este mtodo hace que el usuario participe de manera ms directa en la experiencia de anlisis
y diseo que cualquiera de los ya presentados. La construccin de prototipos es muy eficaz
bajo las circunstancias correctas. Sin embargo, al igual que los otros mtodos, el mtodo es
til slo si se emplea en el momento adecuado y en la forma apropiada.
Qu es un prototipo?
El prototipo es un sistema que funciona, no solo una idea en el papel, desarrollado con la
finalidad de probar ideas y suposiciones relacionadas con el nuevo sistema. Al igual que
cualquier sistema basado en computadora, est constituido por software que acepta entradas,
realiza clculos, produce informacin ya sea impresa o presentada en una pantalla, o que
lleva a cabo otras actividades significativas. Es la primera versin, o iteracin, de un sistema
de informacin.
Lo usuarios evalan el diseo y la informacin generada por el sistema. Lo anterior slo puede
hacerse con efectividad si los datos utilizados, al igual que las situaciones, son reales. Por otra
parte, deben esperarse cambios a medida que el sistema es utilizado.
Razones para desarrollar prototipos de sistemas:
Los requerimientos de informacin no siempre estn bien definidos. Es probable que los
usuarios conozcan slo ciertas reas de la empresa donde se necesiten mejoras o cambios
en los procedimientos actuales. Tambin es posible que reconozcan la necesidad de tener
mejor informacin para administrar ciertas actividades pero que no estn seguros cual de esta
informacin ser la adecuada. Los requerimientos del usuario pueden ser demasiado vagos
aun al formular el diseo. En otros casos, es probable que una investigacin de sistemas bien
llevada necesite del desarrollo de nueva tecnologa.
Los prototipos permiten evaluar situaciones extraordinarias donde los encargados de disear
e implantar sistemas no tienen informacin ni experiencia, o tambin donde existen
situaciones de riesgo y costo elevados, y aquellas donde el diseo propuesto es novedoso y
an no se demuestra es la factibilidad de que los vendedores enven ordenes de pedido al
sistema de cmputo de la compaa desde el sitio donde efectan la operacin por medio de
terminales porttiles enlazadas a telfonos pblicos. Para probar el concepto los
administradores y encargados de sistemas pueden optar por construir una versin en pequea
escala del software, adquirir unas cuantas terminales y seleccionar un grupo de vendedores.
El prototipo proporcionar informacin preliminar sobre la funcionalidad del concepto.
El prototipo es, en realidad, un modelo piloto o de prueba, en general, los analistas de
sistemas encuentran que los prototipos tienen mayor utilidad bajo las siguientes condiciones:

Los encargados de disear e implantar sistemas nunca han desarrollado uno con
las caractersticas del sistema propuesto.

Se conoce slo una parte de las caractersticas esenciales del sistema; las dems
no son identificables a pesar de un cuidadoso anlisis de requerimientos.

La experiencia con el uso del sistema aadir una lista significativa de

requerimientos que el sistema debe satisfacer.

Las diferentes versiones del sistema evolucionan con la experiencia al igual que el
desarrollo adicional y el refinamiento de sus caractersticas.

Los usuarios del sistema participan en el proceso de desarrollo.

Los pasos a seguir en el proceso de desarrollo de prototipos son los siguientes:
Identificar los requerimientos de informacin que el usuario conoce junto con las
caractersticas necesarias del sistema.
Desarrollar un prototipo que funcione.
Utilizar el prototipo anotando las necesidades de cambios y mejoras. Esto expande la lista
de los requerimientos de sistemas conocidos.
Revisar el prototipo con base en la informacin obtenida a travs de la experiencia del
usuario.
Repetir los pasos anteriores las veces que sea necesario hasta obtener5 un sistema
satisfactorio.
l analista debe de reunirse con los usuarios una o dos veces con la finalidad de identificar los
requerimientos. El resultado de estas reuniones forma la base para la construccin del
prototipo.
El desarrollo de un prototipo que funcione es responsabilidad del analista de sistemas, cuando
el analista y el usuario deciden que cuentan ya con la suficiente informacin proveniente del
proceso de construccin del prototipo, determinan cmo satisfacer los requerimientos ya
identificados. En general se opta por una de las siguientes opciones:
Volver a desarrollar el prototipo. Esta alternativa quiz signifique volver a programar por
completo, empezando desde el principio.
Implantar el prototipo como sistema terminado La eficiencia en el funcionamiento junto con
los mtodos para interactuar con el usuario son suficientes; esto permite utilizar el sistema tol
como est.
Abandonar el proyecto. En este caso el prototipo ha proporcionado informacin suficiente
para demostrar que no es posible desarrollar el sistema para satisfacer los objetivos deseados
dentro del marco de la tecnologa existente o de lineamientos econmicos u operacionales.
Iniciar otra serie de construccin de prototipos. La informacin ganada con la experiencia
sugiere ya sea un enfoque totalmente distinto o caractersticas contrastantes.

Cada una de estas opciones se considera como un xito en el proceso de la construccin de

prototipos.
Mtodos para el desarrollo de prototipos
Con los prototipos la velocidad de desarrollo es ms importante que la eficiencia en el
procesamiento. Un sistema prototipo se construye con rapidez, los sistemas prototipo pueden
desarrollarse con mtodos y lenguajes de programacin convencionales, quiz falten los
controles de entrada y procesamiento y, en general, la documentacin del sistema es un punto
que suele evitarse. Lo importante es ensayar ideas y generar hiptesis relacionadas con los
requerimientos y que la eficiencia y perfeccin alcanzadas.
La industria de computadora busca continuamente generadores de aplicaciones, programas
que sirven para generar otros programas, para apoyar los esfuerzos de la construccin de
prototipos. En algunos casos, aquellos donde el sistema ser utilizado con poca frecuencia, el
prototipo puede, de hecho, convertirse en el sistema terminado.
METODO DE ANALISIS Y DISEO ESTRUCTURADO
Muchos especialistas en sistemas de informacin reconocen la dificultad de comprender de
manera completa sistemas grandes y complejos. El mtodo de desarrollo del anlisis
estructurado tiene como finalidad superar sa dificultad por medio de 1) la divisin del sistema
en componentes y 2) la construccin de un modelo del sistema. El mtodo incorpora
elementos tanto de anlisis como de diseo.
Qu es el anlisis estructurado?
El anlisis estructurado concentra en especificar lo que se requiere que haga el sistema o la
aplicacin. No se establece cmo se cumplirn los requerimientos o la forma en que
implantar la aplicacin. Ms bien permite que las personas observen los elementos lgicos
(lo que har el sistema) separados de los componentes fsicos (computadoras, terminales,
sistemas de almacenamiento, etc.) Despus de esto se puede desarrollar un diseo fsico
eficiente para la situacin donde ser utilizado.
Elementos del anlisis estructurado:
Los elementos esenciales son smbolos grficos, diagramas de flujo de datos y diccionario
centralizado de datos.
Descripcin grfica
Una de las formas de describir un sistema es preparar un bosquejo que seale sus
caractersticas, identifique la funcin para la que sirve e indique cmo ste interacta con
otros elementos, entre otras cosas. Sin embargo, describir de esta manera un sistema grande
es un proceso tedioso y propenso a errores ya que es fcil omitir algn detalle o dar una
explicacin que quiz los dems no entiendan.

En lugar de las palabras el anlisis estructurado utiliza smbolos, o conos, para crear un
modelo grfico del sistema. Los modelos de este tipo muestran los detalles del sistema. Si se
seleccionan los smbolos y notacin correctos entonces casi cualquier persona puede seguir
la forma en que los componentes se acomodarn entre si para formar el sistema.
El diagrama lgico de flujo de datos muestra las fuentes y destinos de los datos, identifica y da
nombre a los procesos que se llevan a cabo, identifica y da nombre a los grupos de datos que
relacionan una funcin con otra y seala los almacenes de datos a los que se tiene acceso.
Diagrama de flujo de datos: El modelo del sistema recibe el nombre de diagrama de flujo de
datos (DFD). La descripcin completa de un sistema est formada por un conjunto de
diagramas de flujo de datos.
Para desarrollar una descripcin del sistema por el mtodo de anlisis estructurado se sigue
un proceso descendente (TOP-down). El modelo original se detalla en diagramas de bajo nivel
que muestran caractersticas adicionales del sistema. Cada proceso puede desglosarse en
diagramas de flujo de datos cada vez ms detallados. Esta secuencia se repite hasta que se
obtienen suficientes detalles que permiten al analista comprender en su totalidad la parte del
sistema que se encuentra bajo investigacin.
Diccionario de datos:
Todas las definiciones de los elementos en el sistema (flujo de datos, procesos y almacenes
de datos) estn descritos en forma detallada en el diccionario de datos. Si algn miembro del
equipo encargado del proyecto desea saber alguna definicin del nombre de un dato o el
contenido particular de un flujo de datos, esta informacin debe encontrarse disponible en el
diccionario de datos.
Que es el diseo estructurado
Se enfoca en el desarrollo de especificaciones del software. La meta del diseo estructurado
es crear programas formados por mdulos independientes unos de otros desde el punto de
vista funcional.
El diseo estructurado es una tcnica especfica para el diseo de programas y no un mtodo
de diseo de comprensin. Esta tcnica conduce a la especificacin de mdulos de programa
que son funcionalmente independientes. La herramienta fundamental del diseo estructurado
es el diagrama estructurado, los cuales son de naturaleza grfica y evitan cualquier referencia
relacionada con el hardware o detalles fsicos. Su finalidad no es mostrar la lgica de los
programas. Los diagramas estructurados describen la interaccin entre mdulos
independientes junto con los datos que un mdulo pasa a otro cuando interacciona con l.
Estas especificaciones funcionales para los mdulos se proporcionan a los programadores
antes que d comienzo la fase de escritura de cdigo.
Empleo del Anlisis estructurado con otros mtodos de desarrollo:

10

El anlisis estructurado se combina, con bastante frecuencia, con el mtodo ya presentado de

ciclo de vida clsico de desarrollo de sistemas. Por ejemplo, los analistas pueden optar ms
de flujo de datos como una forma para documentar las relaciones entre componentes durante
la investigacin detallada de algn sistema existente, Asimismo, se puede definir los archivos
y datos en un diccionario centralizado de datos de acuerdo con las reglas de anlisis
estructurado.
Sin embargo muchas organizaciones optan por no utilizar este mtodo de desarrollo. Por
ejemplo, los analistas deciden con frecuencia que el desarrollo de diagramas y esquemas es
una tarea que consume mucho tiempo, sobre todo si el sistema es grande y complejo. (Es
comn que los diagramas tengan que dibujarse una y otra vez conforme se adquiere nueva
informacin). Como se ver ms adelante, se han desarrollado herramientas asistidas por
computadora para superar este problema.
Otros analistas sealan que los elementos que faltan, tales como las personas y los
procedimientos de control, son parte del sistema mismo y no pueden omitirse en la
descripcin de ste. Ms adelante se considerar este aspecto tan importante.

11

12