Analisis de Sistemas I

FACULTAD DE CIENCIA Y TECNOLOGA
RED NACIONAL UNIVERSITARIA
SYLLABUS
Facultad de Ciencia y Tecnologa
Ingeniera de Sistemas
QUINTO SEMESTRE
Gestin Acadmica II/2013
UDABOL
UNIVERSIDAD DE AQUINO BOLIVIA
Acreditada como PLENA mediante R.M. 288/01
VISIN DE LA UNIVERSIDAD
Ser la Universidad lder en calidad educativa.
MISIN DE LA UNIVERSIDAD
Desarrollar la Educacin Superior Universitaria con calidad y
competitividad al servicio de la sociedad.

SYLLABUS
Asignatura:
Cdigo:
Requisito:
Carga Horaria:
Crditos:
I.
ANALISIS DE SISTEMAS I
CMP316
CMP228
80 Horas
6
OBJETIVOS GENERALES DE LA ASIGNATURA.
Justificar la utilizacin de los diferentes mtodos a partir de la interpretacin de los conceptos tericos y
su aplicacin a la realidad.
Definir los elementos de un sistema mediante el modelado, diseo e implementacin de diferentes
mtodos y su seleccin adecuada a un nivel aplicativo.
Evaluar proyectos relacionados al modelado y diseo a partir de la correcta interpretacin de la teora y la
prctica.
II. PROGRAMA ANALTICO DE LA ASIGNATURA.

MDULO 1: ANALISIS Y DISEO DE SISTEMAS
1.1 Enfoque de Sistemas
1.1.1 Introduccin a la Teora General de Sistemas Informacin
1.1.2 Descripcin formal de Sistemas
1.1.3 Principios, propiedades y paradoja de sistemas
1.1.4 Ciclo bsico de un sistema
1.1.5 Supervivencia de Sistemas
1.2 Introduccin
1.2.1 Qu es un Sistema?
1.2.2 Estrategia para el desarrollo de sistemas
1.2.3 Herramientas para el desarrollo de Sistemas
1.2.4 Mtodo de desarrollo por anlisis estructurado
1.2.5 Paradigma tradicional de desarrollo de sistemas
1.2.6 Mtodo del prototipo de sistemas
Paradigma Tradicional del Desarrollo de Sistemas
Visin General
Etapas del anlisis y desarrollo
Estudio de factibilidad
Determinacin de Requerimientos
Especificacin del diseo e implementacin
Especificacin de prueba
MDULO 2: DESARROLLO POR ANALISIS ESTRUCTURADO
2.1 Estrategia de desarrollo por anlisis estructurado
2.1.1 Anlisis estructurado
2.1.2. Notacin
3

2.1.3 Actividades paralelas
2.1.4 Desarrollo del diagrama de flujo de datos (DFD)
2.1.5 Proceso de desarrollo
2.1.6 Reglas generales para el dibujo de los diagrama
2.1.7 Evaluacin de DFD para verificar que es correcto
2.1.8 Descripcin de las estructuras de datos
2.1.9 Definicin de la estructura de datos
2.1.10 Descripcin de procesos
2.1.11 Diccionario de datos
MDULO 3: DESARROLLO POR PROTOTIPO DE APLICACIONES
3.1 Que es un prototipo
3.2. Razones para el empleo de prototipos
3.3 Etapas del mtodo de prototipos
3.4 Identificacin de requerimientos conocidos
3.5 Desarrollo de un modelo de trabajo
3.6 Uso de prototipos
3.7 Abandono de la aplicacin
3.8 Herramientas para el desarrollo de prototipos
3. 9 Bibliotecas de cdigo reutilizable.
MDULO 4: HERRAMIENTAS PARA EL DESARROLLO DE SISTEMAS
4.1
4.2
4.3
4.4
4.5
III.
Importancia de las herramientas para el desarrollo

Beneficios del empleo de herramientas
Clasificacin de herramientas
Aplicacin de herramientas
Implementacin del proyecto en la herramienta seleccionada
BIBLIOGRAFIA
Senn James Anlisis de Sistemas de Informacin (McGraw Hill, 1999).

Kendall & Kendall Anlisis y Diseo de Sistemas (Prentice Hall, 1997).
Pressman S. Roger Ingeniera de Software (McGraw Hill. 1997).
Laudon, Laudon "Administracin de Sistemas de Informacin" (Prentice Hall. 1996).
APUNTES: Adicionalmente el estudiante dispondr de los Work papers y DIFs entregados por el docente,
los que forman parte del texto de la asignatura.
IV. CONTROL DE EVALUACIONES

1 evaluacin parcial
Fecha:
Nota:
2 evaluacin parcial
Fecha:
Nota:
Examen final
Fecha:
Nota:
APUNTES
WORK PAPER # 1
PROGRAMA DE CONTROL DE CALIDAD

Nro DE PROCEDIMIENTO:
APRO 012
ELABORO:
Nro. DE HOJAS: 6
CDIGO:
TITULO WORK PAPER: Teora General de Sistemas

DPTO:
UDABOL LA PAZ
DESTINADO A:
DOCENTE
ALUMNOS
ADMINISTRATIVOS
OTROS
OBSERVACIONES:
FECHA DE DIFUSIN:
FECHA DE ENTREGA:
TEORIA GENERAL DE SISTEMAS

WORK PAPER 1
La mayor fuente de entropa
el hombre es la ignorancia
Pablo Suazo
Para poder empezar a hablar de anlisis y diseo de sistemas, inicialmente debemos entender la Teora General de
Sistemas, que sus partes ms relevantes referencia a que la integracin de las diversas ciencias se orienta al rumbo
de los sistemas.
1. INTRODUCCIN A LA TEORA GENERAL DE SISTEMAS
La teora general de sistemas se presenta como una forma sistemtica y cientfica de aproximacin y representacin de la
realidad y al mismo tiempo como una orientacin hacia una prctica de trabajo interdisciplinaria, es un mtodo que nos
permite unir y organizar los conocimientos con la intencin de lograr una mayor eficacia de accin, la primera formulacin
conocida es atribuida al bilogo Ludwing von Bertalanffy en 1940, como un intento de obtener un modelo nico para el
tratamiento de los problemas que los enfoques analtico reduccionistas y sus principios causales no poda resolver.
Estos enfoques por ejemplo basados en los principios cartesianos aplicados al estudio de un fenmeno decan que se deba
dividir un fenmeno en elementos simples, luego analizar cada elemento simple y finalmente reunir todos los elementos
simples para reconstruir el fenmeno inicial. Pero como nadie indic las reglas de subdivisin vlidas poda en la mayora
de los casos incrementar la dificultad, por tanto naci la necesidad de una nueva teora.
1.1 Caractersticas
En 1954 la Society for General Systems Research (Sociedad para la bsqueda de Sistemas Generales), enumera las
siguientes caractersticas de la TGS:
1. Investigar el isomorfismo (misma forma cristalina y distinta composicin qumica) de conceptos, leyes y modelos en
varios campos y facilitar las transferencias entre aquellos.
2. Promocin y desarrollo de modelos tericos en campos que carecen de ellos.
3. Reducir la duplicacin de los esfuerzos tericos
4. Promover la unidad de la ciencia a travs de principios conceptuales y metodolgicos unificadores.
La TGS se caracteriza por su perspectiva holstica (holismo es la comprensin de la totalidad a partir de leyes especficas) e
integradora, donde lo importante son las relaciones y los conjuntos que a partir de ellas emergen.
1.2 Objetivos
Los objetivos de la Teora General de Sistemas son los siguientes:
1. Impulsar el desarrollo de una terminologa general que permita describir las caractersticas, funciones y
comportamientos sistmicos.
2. Desarrollar un conjunto de leyes aplicables a todos estos comportamientos y, por ltimo,

3. Promover una formalizacin (matemtica) de estas leyes.
1.3. Conceptos Bsicos de la Teora General de Sistemas.
1.3.1. Descripcin Formal de Sistemas.
El trmino sistema proviene de la palabra griega systema que significa un todo organizado, a continuacin brindamos
algunas definiciones de sistemas
Es un conjunto organizado de cosas o partes interactantes e interdependientes, que se relacionan formando un todo
unitario y complejo.
Conjunto de elementos que guardan estrecha relacin entre s y que mantienen al sistema directa o indirectamente unido
de modo ms o menos estable y cuyo comportamiento global persigue normalmente algn objetivo.
Todas estas definiciones nos permiten extraer una definicin general que dice:
Un sistema es un conjunto de elementos relacionados entre si en funcin de un objetivo comn.
Bsicamente todo se puede analizar desde la perspectiva de sistemas, por ejemplo, vivimos en un sistema social y
econmico, nos comunicamos utilizando un lenguaje que es un sistema formado por palabras y smbolos, conjunto de
smbolos, una organizacin es un sistema sus componentes mercadotecnia, manufactura, ventas, investigacin,
embarques, contabilidad y personal, trabajan juntos para crear utilidades que beneficien tanto a los empleados como a los
accionistas de las compaas.
1.3.2. Objetivos
Los objetivos del sistema son las metas o fines hacia los cuales se quiere llegar. Por ello la bsqueda del objetivo es muy
importante. Son la razn de la existencia de los mismos. En general cualquier sistema carece de razn de ser si no cuenta
con objetivos
Por ejemplo el sistema de arranque de un automvil tiene el claro propsito de quemar el combustible para crear la energa
que emplean los dems sistemas del mismo.
1.3.3. Componentes de los sistemas

Cualquier sistema se puede descomponer en los siguientes elementos componentes:
Subsistemas
Medio Ambiente
Relaciones

Frontera
1.3.3.1 Medio Ambiente

El Medio ambiente es todo aquellos que esta fuera del sistema, pero es muy importante pues nos provee los insumos
necesarios para que el sistema funcione y recibe los egresos del sistema
Los insumos o recursos pueden ser: humanos (personas), materiales (maquinas, equipos, materia prima), tecnolgicos,
administrativos (planificacin, direccin), financieros, siendo los egresos productos o servicios.
1.3.3.2 Relaciones:
Las relaciones son los enlaces que vinculan entre s a los objetos o subsistemas que componen a un sistema complejo.
Podemos clasificarlas en :
- Simbiticas: es aquella en que los sistemas conectados no pueden seguir funcionando solos. A su vez puede
subdividirse en unipolar o parasitaria, cuando un sistema no puede vivir sin el otro sistema por ejemplo una planta,
un bebe sin la madre; y bipolar o mutual, cuando ambos sistemas dependen entre si como ocurre con los
subsistemas del cuerpo humano.
- Sinrgica: es una relacin que no es necesaria para el funcionamiento pero que resulta til, ya que su presencia
mejora el desempeo del sistema. Sinergia significa "accin combinada" interpretndose como esfuerzo
cooperativo, por ejemplo el aditivo que se coloca en los motores a gasolina.
-
Superflua: Son relaciones que repiten otras relaciones, su razn es intentar garantizar que el sistema funcione
casi todo el tiempo, si se podran expresar en una sola palabra podras decir que estamos hablando de
redundancia.
1.3.3.3 Subsistemas
Al ser sistemas ms pequeos se acogen a la definicin de sistemas brindada con anterioridad.
Por ejemplo, el cuerpo humano esta compuesto por subsistemas como ser el respiratorio y circulatorio y un automvil tiene
los subsistemas elctrico, de combustin e hidrulico.
1.3.3.4 Frontera
Se puede decir que la frontera del sistema es aquella lnea imaginaria que separa al sistema de su entorno y que define lo
que le pertenece y lo que queda fuera de el, su determinacin es fundamental para determinar lo que queda dentro del
sistema y lo que esta fuera de el.
1.3.4 Operacin de un Sistema
Todos los sistemas tienen una entrada, realizan un proceso y generan un salida.
Entradas
Las entradas son los ingresos del sistema que pueden ser recursos materiales, recursos humanos o informacin,
constituyen la fuerza de arranque que suministra al sistema sus necesidades operativas.
Las entradas pueden ser:
- en serie: es el resultado o la salida de un sistema anterior con el cual el sistema en estudio est relacionado en
forma directa.
- aleatoria: es decir, al azar, donde el termino "azar" se utiliza en el sentido estadstico. Las entradas aleatorias
representan entradas potenciales para un sistema.
- retroalimentacin: es la reintroduccin de una parte de las salidas del sistema en s mismo.
Proceso:
Proceso es todo aquello que transforma una entrada en salida, como una mquina, un individuo, una computadora, un
producto qumico, una tarea realizada por un miembro de la organizacin, etc.
Si en la transformacin sabemos exactamente los pasos que se siguen para transformar una entrada en una salida, el
proceso recibe el nombre de caja blanca, por el contrario si desconocemos el proceso, pero sabemos que ante una
determinada entrada se produce una determinada salida, entonces estamos ante una caja negra.
Salidas:
Las salidas de los sistemas son los resultados que se obtienen de procesar las entradas, pueden adoptar la forma de
productos, servicios e informacin.
Clasificacin de los Sistemas
Existen varias formas de clasificar los sistemas a continuacin mencionamos alguna de ellas:
Segn su naturaleza los sistemas pueden ser agrupados:
Reales asumen una existencia independiente del observador (quien los puede descubrir). (Los animales)
Ideales son construcciones simblicas, como el caso de la lgica y las matemticas.
Modelos son abstracciones de la realidad donde se combina lo conceptual con las caractersticas de los objetos.
De acuerdo a su origen se clasifican en naturales o artificiales

De acuerdo a la relacin con el medio ambiente o el grado de aislamiento se pueden clasificar en:
Sistemas Abiertos son aquellos que constantemente estn intercambiando insumos y productos con el medio ambiente.
Un sistema es cerrado cuando ningn elemento de afuera entra y ninguno sale fuera del sistema, por ejemplo una
reaccin qumica en un frasco cerrado y aislado En realidad no existen sistemas cerrados, pero el concepto es muy
importante porque ilustra el objetivo del diseo de sistemas, construir sistemas que necesiten la menor intervencin del
medio externo para mantener un nivel de desempeo aceptable.
10

Otros tipos de clasificaciones son las siguientes:
Sistemas duros son aquellos en los cuales el aspecto humano esta en segundo plano.
Sistemas suaves son aquellos que toman en cuenta el aspecto humano.
Caractersticas de los Sistemas

Adaptabilidad:
Es la propiedad que tiene un sistema de aprender y modificar un proceso, un estado o una caracterstica de acuerdo a las
modificaciones que sufre el contexto. Esto se logra a travs de un mecanismo de adaptacin que permita responder a los
cambios internos y externos a travs del tiempo.
Por ejemplo el ser humano puede adaptarse a diversos tipos de climas
Mantenibilidad:
Es la propiedad que tiene un sistema de mantenerse constantemente en funcionamiento. Para ello utiliza un mecanismo de
mantenimiento que asegure que los distintos subsistemas estn balanceados y que el sistema total se mantiene en
equilibrio con su medio.
Ejemplo: La alimentacin humana.
Estabilidad:
Esta propiedad es resultado de la anterior y dice que un sistema es estable cuando puede mantenerse en equilibrio a travs
del flujo continuo de materiales, energa e informacin.
Homeostasis:
La homeostasis es la propiedad de un sistema que define su nivel de respuesta y de adaptacin al contexto.
Entropa:
La entropa de un sistema es el desgaste que el sistema presenta por el transcurso del tiempo o por el funcionamiento del
mismo. Los sistemas altamente entrpicos tienden a desaparecer por el desgaste generado por su proceso sistmico. Los
mismos deben tener rigurosos sistemas de control y mecanismos de revisin, reelaboracin y cambio permanente, para
evitar su desaparicin a travs del tiempo.
La Permeabilidad
La permeabilidad de un sistema mide la interaccin que este recibe del medio, se dice que a mayor o menor permeabilidad
del sistema el mismo ser mas o menos abierto.
11

Los sistemas que tienen mucha relacin con el medio en el cul se desarrollan son sistemas altamente permeables, estos y
los de permeabilidad media son los llamados sistemas abiertos.
Por el contrario los sistemas de permeabilidad casi nula o impermeables se denominan sistemas cerrados.
Sinergia: Cualidad por la cual la capacidad de actuacin del sistema es superior a las de sus componentes sumados
individualmente.
Bibliografa
1. Arnold, M. "Teora de Sistemas, Nuevos Paradigmas: Enfoque de Niklas Luhmann". 1989.
2. Bertalanffy Von, L. "The Theory of Open Systems in Physics and Biology". 1959.
3. Rodrguez, D. & M. Arnold. Sociedad y Teora de Sistemas 1991.
Cuestionario
1. Mencione algunos ejemplos de relaciones simbiticas, sinrgicas y superfluas
2. Mencione algunos ejemplos de sistemas y explique por qu los considera como tal?
3. De las caractersticas de los sistemas estudiadas, cual le parece la ms importante y por qu?
12
WORK PAPER # 2

APRO 012
Nro. DE HOJAS: 4
ELABORO:
CDIGO:
TITULO WORK PAPER: Los Sistemas de Informacin

DPTO:
UDABOL LA PAZ
DESTINADO A:
DOCENTE
ALUMNOS
ADMINISTRATIVOS
OTROS
OBSERVACIONES:
FECHA DE DIFUSIN:
FECHA DE ENTREGA:
13

LA INFORMACION Y LOS SISTEMAS
La suerte de una persona
Es dividendo de su trabajo
Ray Kroc
La Informacin tiene su origen en las palabras in y formare, es decir, "instruir hacia adentro". A partir de estas dos palabras,
y debido a la importancia que en pocas recientes han cobrado, se ha generado una enorme cantidad de variantes, cada
una con un significado muy preciso, aplicable a ciertos tipos de situaciones.
La informacin es coleccionable, almacenable o reproducible. Se utiliza para tomar decisiones, conduce tambin a
conclusiones acertadas o equivocadas, puesto que puede ser interpretada de diversas formas por distintos individuos,
dependiendo de muchos factores subjetivos y del contexto en que se encuentre la persona que la recibe e interpreta,
tambin tiene que ser Exacta, Estructurada y sobre todo a tiempo
Uno de los aspectos ms abstractos e importantes de la informacin es que su valor puede disminuir a lo largo del tiempo.
Es decir, en un momento determinado a alguien le puede interesar contar con cierta informacin, pero ese inters puede
decrecer o incluso desaparecer algn tiempo despus. Es por este motivo que el correo nocturno ya no es suficientemente
rpido, de ah el motivo que el Internet haya cobrado ltimamente tanta importancia
Ahora bien si tenemos en cuenta que para manejar correctamente la informacin se requiere de sistemas de informacin, el
desarrollo de sistemas de informacin viene jugando un papel muy importante en el progreso de esta nueva economa y de
esta nueva era, La era de la Informacin.
2.1 Qu es un Sistema de Informacin?
Habiendo estudiado la definicin de sistema en el work paper anterior, podemos decir que un Sistema de Informacin en el
sentido ms amplio es un conjunto de elementos que interactan entre s para apoyar las actividades de una empresa o
negocio.
Entrando a una definicin ms formal podemos decir que es un conjunto formal de procesos que, operando sobre una
coleccin de datos estructurada segn las necesidades de la empresa, recopilan, elaboran y distribuyen la informacin (o
parte de ella) necesaria para las operaciones de dicha empresa y para las actividades de direccin y control
correspondientes (decisiones) para desempear su actividad de acuerdo a su estrategia de negocio.
un conjunto integrado de personas y equipos que tiene por objetivo proveer a una organizacin de la informacin necesaria
para apoyar las operaciones, la administracin y la toma de decisiones.
El objetivo de un Sistema de Informacin es proporcionar informacin de calidad, es decir ayudar al desempeo de las
actividades en todos los niveles de la organizacin, mediante el suministro de la informacin adecuada, con la calidad
suficiente, a la persona apropiada, en el momento y lugar oportunos, y con el formato ms til para el receptor.
2.2 Elementos de un Sistema de Informacin
Entre los principales componentes de un sistema de informacin podemos mencionar a las personas, la informacin como
tal , el equipo de soporte para la comunicacin, el procesamiento y el almacenamiento de la informacin.
2.3 Valor de un Sistema de Informacin
14

El valor de un Sistema de Informacin depende de su eficacia, su extensin, su aceptacin por parte de los que lo utilizan,
su coste, la calidad de la informacin que trata y produce.
2.4 Clasificacin de los Sistemas de Informacin

Los sistemas de informacin no necesariamente tienen que contar con el apoyo de la computadora, en ese sentido los
sistemas de informacin pueden ser inicialmente clasificados como manuales y/o automatizados. Los primeros no cuentan
con el soporte informtico y los segundos si.
Otra forma de clasificar a los sistemas de informacin es a partir de las funciones a las cuales dan soporte dentro de una
empresa u organizacin, ya sea en el control y gestin , la comercializacin y o la fabricacin de productos o servicios. As
por ejemplo tenemos las siguientes clasificaciones:
2.4.1 Sistemas para el procesamiento de transacciones (TPS)
Los sistemas de procesamiento de transacciones tienen como finalidad mejorar las actividades rutinarias de una empresa y
de las que depende toda la organizacin. Una transaccin es cualquier suceso o actividad que afecta a toda la
organizacin. (facturacin, pago a empleados, depsitos). Cambian de una organizacin a otra.
Los sistemas de procesamiento de transacciones brindan velocidad y exactitud; adems se pueden programar para seguir
rutinas sin ninguna variacin.
2.4.2 Sistemas de Informacin Administrativa (MIS)
Ayudan a los directivos a tomar decisiones y resolver problemas, utilizan datos relacionados con las transacciones as como
cualquier informacin que sea generada dentro o fuera de la compaa. Estos sistemas estn diseados para dar soporte a
todos aquellos asuntos donde es necesario tomar decisiones y que se presentan con frecuencia.
2.4.3 Sistemas para el soporte de decisiones (DSS)
Ayudan a los directivos que deben tomar decisiones no muy estructuradas o semiestructuradas. (una decisin se considera
no estructurada si no existen procedimientos claros para tomarla y tampoco es posible identificar con anticipacin todos los
factores que deben considerarse en la decisin) de problemas nicos. Un aspecto es considerar que informacin se debe
considerar por lo que no se pueden elaborar reportes de antemano. Son sistemas flexibles capaces de adecuarse a las
necesidades de los directivos
2.4.4 Sistemas de Automatizacin de la Oficina (OAS)
Dan soporte a los trabajadores de datos, que generalmente no crean nuevo conocimiento sino que se usan para analizarla y
transformar los datos o para manejarla en alguna forma y luego compartirla o diseminarla. (Hojas electrnicas,
procesamiento de palabras, calendarizacin).
2.4.5 Otras Formas de Clasificacin
15

Los sistemas de informacin tambin se pueden clasificar en No integrados (que desarrollan aplicaciones que responden a
necesidades especficas de un departamento sin prever sistemas existentes y mucho menos venideros, aportan beneficios
a corto plazo, pero pueden generar inconsistencias o duplicidad de informacin); Integrados ( Cubren todas las actividades
desarrolladas y todos los datos que se precisan); parcialmente integrados que dividen por un lado el rea de trabajo en
elementos manejables y por otro, se define, planifica y controla los mismos)
2.5 Implementacin
Para la implementacin de un sistema de informacin se deben seguir una serie de etapas entre las cuales podemos citar la
planificacin, Diseo, Creacin de subsistemas y Aplicacin.
2.5.1 Planificacin
Esta etapa cosiste en crear un marco que recoja los objetivos de la organizacin, establece los requisitos de informacin y
de procedimientos que se necesitan para obtenerla, determina el papel de la tecnologa en el soporte de dicho Sistema de
Informacin, produce polticas y planes para el desarrollo e implementacin de los mismos.
2.5.2- Diseo
Una vez obtenido un marco real en donde se aplicar el sistema, se deben definir las entidades y los procesos (Quin
hace qu?), las tareas asignadas se evalan en forma global, se agrupan los procesos similares, se disean las bases de
datos y sus aplicaciones.
.
2.5.3- Creacin de Subsistemas
Se procede a la creacin de Procesos Mnimos: Tareas individuales o por equipos, definidas por los propsitos, congruentes
con los objetivos planteados para el sistema en la fase de diseo. Evaluacin, agrupacin, reordenamiento de las tareas
segn un orden lgico, que permita su realizacin y por ltimo, se obtiene de esta agrupacin de actividades y tareas las
aplicaciones..
2.5.4 Aplicaciones
Con los procesos mnimos ordenados en tiempo, responsables, orden lgico; se realiza una prueba de campo para verificar
si realmente estas actividades son eficaces. Es decir comprobar si el sistema es operativo o no y los cambios necesarios
para ponerlo en marcha.
2.6 Bibliografa
1.
Senn, J. "Anlisis y Diseo de Sistemas de Informacin. 1999.

2. Sommerville, I. "Ingeniera de Software ". 2002.
3. Kendall & Kendall. Anlisis y Diseo de Sistemas. 1997.
Cuestionario
1. Mencione algunos ejemplos de sistemas de informacin de acuerdo a la clasificacin brindada en lneas anteriores.
2. Cree usted que los sistemas de informacin se pueden clasificar en manuales y automatizados?. Justifique su
respuesta.
16
WORK PAPER # 3

APRO 012
ELABORO:
Nro. DE HOJAS: 5
CDIGO:
TITULO WORK PAPER: Desarrollo de Sistemas de Informacin

DPTO:
UDABOL LA PAZ
DESTINADO A:
DOCENTE
ALUMNOS
ADMINISTRATIVOS
OTROS
OBSERVACIONES:
FECHA DE DIFUSIN:
FECHA DE ENTREGA:
17

DESARROLLO DE SISTEMAS DE INFORMACION
No basta saber, se debe tambin aplicar.
No es suficiente querer, se debe tambin hacer.

Johann Wolfgang von Goethe
3.1 Qu es el Desarrollo de Sistemas?
El desarrollo de sistemas es el conjunto de procedimientos, tcnicas, herramientas, y un soporte documental que ayuda a
los desarrolladores a producir nuevo software. Es el proceso de examinar la situacin de una empresa u organizacin con el
propsito de mejorarla con mtodos y procedimientos ms adecuados, esta formado por dos grandes componentes: el
anlisis y el diseo de sistemas.
El anlisis de sistemas es el proceso de clasificar e interpretar los hechos, diagnostico de problemas y el empleo de la
informacin para recomendar mejoras al sistema.
El diseo de sistemas es el proceso de planificar, reemplazar o complementar un sistema organizacional existente, para lo
cual se debe comprender en su totalidad el viejo sistema y determinar la mejor forma de hacer la operacin ms eficiente.
3.2 Estrategias para el Desarrollo de Sistemas.

Los sistemas de informacin basados en computadora sirven para diversas finalidades que van desde el procesamiento de
las transacciones de una empresa hasta proveer de la informacin necesaria para decidir sobre asuntos que se presentan
con frecuencia y asistencia a los altos funcionarios para la toma de decisiones.
Existen varios enfoques para el desarrollo de sistemas de informacin basados en computadoras, en el presente
documento presentaremos tres de ellas: El mtodo del ciclo de vida para el desarrollo de sistemas, el mtodo del desarrollo
del anlisis estructurado y el mtodo del prototipo de sistemas.
18

3.2.1 Ciclo de vida clsico del desarrollo de sistemas
Son una serie de pasos que se siguen para desarrollar software, consta de las siguientes actividades: Investigacin
preliminar, Determinacin de los requerimientos del sistema, diseo del sistema, desarrollo del software, prueba de los
sistemas e Implantacin y evaluacin.
Toda solicitud se inicia con la peticin, esto desencadena la primera actividad.
3.2.1.1 Investigacin Preliminar.
Tiene por finalidad la aclaracin de la solicitud y la verificacin de la factibilidad de la solicitud y posteriormente la
consiguiente aprobacin de la misma
3.2.1.2 Determinacin de Requerimientos del Sistema
Se debe comprender las caractersticas de la parte de la empresa que se halla bajo estudio, estudiar los procesos y esto se
logra bsicamente respondiendo algunas preguntas que nos ayuden a entender el sistema: Qu es lo que hace?, cmo
se hace?, Con qu frecuencia se presenta?, Qu tan grande es el volumen de transacciones o decisiones?, Cul es el
grado de eficiencia con el que se realizan las tareas?, Existe algn problema?, Cul es la causa que lo origina?.
Para contestar a esta preguntas se recurre a una serie de herramientas que me permiten interactuar con los usuarios y de
esta manera obtener la informacin buscada y asi comprender como funciona el sistema, lo que finalmente derivar en la
determinacin de requerimientos (es decir las caractersticas deseables a incorporar en el nuevo sistema).
3.2.1.3 Diseo del sistema
Establece como el sistema cumplir con los requerimientos identificados durante la fase de anlisis. Se disea las salidas,
entradas y procesos.
3.2.1.4 Desarrollo de software
Se escriben los programas necesarios y para ello el responsable elige el lenguaje, eleccin que depende de varios factores
entre los cuales podemos citar: costo de cada alternativa, el tiempo disponible para escribir el software y la disponibilidad de
los mismos. Es responsabilidad de esta etapa la documentacin de los programas.
3.2.1.5 Prueba de Sistemas
19

En esta fase el sistema se emplea de manera experimental para asegurarse que no tenga fallas, es decir funciona de
acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimenta con datos de prueba
para su procesamiento y despus se analizan los resultados
3.2.1.6 Implantacin y Evaluacin.
Es el proceso de verificar e instalar el nuevo equipo, entrenar a los usuarios, instalar la aplicacin y construir todos los
archivos de datos necesarios para utilizarla.
Dependiendo del tamao y el riesgo asociado a su uso a veces se decide implementar solo en un rea (prueba piloto), otras
se deja que el viejo y el nuevo sistema trabajen juntos (paralelo) para comparar resultados o finalmente se puede decidir por
una implementacin en (vivo), es decir el sistema viejo deja de funcionar determinado da y empieza a trabajar el nuevo.
3.2.2 Mtodo de desarrollo por anlisis estructurado
Muchas veces es necesario reconocer la dificultad de comprender de manera completa sistemas grandes y complejos. Este
mtodo tiene como finalidad superar esta dificultad por medio de 1) la divisin del sistema en componentes y 2) la
construccin de un modelo del sistema.
El anlisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicacin, No establece
como se cumplirn los requerimientos o la forma en que se implantar la aplicacin. Se representa el funcionamiento
general del sistema como una nica transformacin de informacin que produce informacin de salida
3.2.2.1 Elementos del anlisis estructurado.
Los elementos bsicos del anlisis estructurado son smbolos grficos, diagramas de flujo de datos y el diccionario
centralizado de datos
20
3.2.2.1.1 Diagrama de flujo de datos.

Son una tcnica grfica conforme la informacin se mueve por el sistema, es modificada por una serie de transformaciones.
El diagrama de flujo de datos DFD es una tcnica grfica que representa el flujo de la informacin y las transformaciones
que se aplican a los datos al moverse desde la entrada hasta la salida.
En la siguiente figura se muestran la notacin bsica para los Diagramas de flujo de datos:
Almacn de datos
Unidad externa
Flujo de Informacin
Proceso
Dicha notacin debe ser ampliada como sea posible con texto descriptivo.
La forma bsica de la implementacin de un DFD se muestra a continuacin:
Informacin
de salida
Unidad
externa
Informacin
de entrada
Proceso
Unidad
externa
Informacin
de entrada
Informacin
de salida
Informacin
de salida
Unidad
externa
Unidad
externa
Unidad
externa
Podemos tener tantos DFD como nivel de detalle deseemos expresar en nuestro sistema.
3.2.2.1.2 Diccionario de Datos
El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con
definiciones precisas y rigurosas que permiten que el usuario y el analista del sistema tengan una misma comprensin de
las entradas, de las salidas, de los componentes de los almacenes y tambin de los clculos intermedios.
21
3.2.3 Mtodo del Prototipo de Sistemas

Este mtodo hace que el usuario participe de manera ms directa en el anlisis y diseo de sistemas, pero este mtodo
solo es til si se emplea en el momento adecuado y en forma adecuada.
3.2.3.1 Qu es un prototipo?
Es un sistema que funciona, no solo una idea en papel, desarrollado con la finalidad de probar ideas y suposiciones
relacionadas con el nuevo sistema, es en realidad un modelo piloto o de prueba, cuyo diseo evoluciona con el uso
3.2.3.2 Razones para desarrollar prototipos
Los requerimientos de informacin no siempre estn bien definidos, se requiere nueva informacin para ciertos sectores,
pero no se tiene claro que informacin se requiere, se tenga un conjunto amplio de requerimientos y tal vez no se satisfaga
todos ellos.
Los prototipos permiten evaluar situaciones extraordinarias donde los encargados de disear e implementar sistemas no
tienen informacin ni experiencia o existan situaciones de riesgo y costo o sea un sistema novedoso que aun no hubiese
sido probado.
3.2.3.3 Pasos para el desarrollo de Prototipos
Los pasos que se siguen en el 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, Probar el
prototipo, revisando el mismo con la informacin obtenida y finalmente repetir los pasos anteriores las veces que sea
necesario hasta obtener un sistema satisfactorio.
3.3 Bibliografa
1.
Senn, J. "Anlisis y Diseo de Sistemas de Informacin. 1999.
2. Kendall & Kendall. Anlisis y Diseo de Sistemas. 1997.

Cuestionario
1. Elabore un ideograma de los tres mtodos clsicos del desarrollo de sistemas profundizando cada uno de ellos.
22
WORK PAPER # 4

APRO 012
ELABORO:
Nro. DE HOJAS: 14
CDIGO:
TITULO WORK PAPER: Mtrica 3

DPTO:
UDABOL LA PAZ
DESTINADO A:
DOCENTE
ALUMNOS
ADMINISTRATIVOS
OTROS
OBSERVACIONES:
FECHA DE DIFUSIN:
FECHA DE ENTREGA:
23
METRICA 3
INTRODUCCIN
La metodologa MTRICA Versin 3 ofrece a las Organizaciones un instrumento til para la sistematizacin de las
actividades que dan soporte al ciclo de vida del software dentro del marco que permite alcanzar los siguientes objetivos:
- Proporcionar o definir Sistemas de Informacin que ayuden a conseguir los fines de la Organizacin mediante la
definicin de un marco estratgico para el desarrollo de los mismos.
- Dotar a la Organizacin de productos software que satisfagan las necesidades de los usuarios dando una mayor
importancia al anlisis de requisitos.
- Mejorar la productividad de los departamentos de Sistemas y Tecnologas de la Informacin y las
Comunicaciones, permitiendo una mayor capacidad de adaptacin a los cambios y teniendo en cuenta la
reutilizacin en la medida de lo posible.
- Facilitar la comunicacin y entendimiento entre los distintos participantes en la produccin de software a lo largo
del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, as como las necesidades de todos y
cada uno de ellos.
- Facilitar la operacin, mantenimiento y uso de los productos software obtenidos.
La nueva versin de MTRICA contempla el desarrollo de Sistemas de Informacin para las distintas tecnologas que
actualmente estn conviviendo y los aspectos de gestin que aseguran que un Proyecto cumple sus objetivos en trminos
de calidad, coste y plazos.
Su punto de partida es la versin anterior de MTRICA de la cual se han conservado la adaptabilidad, flexibilidad y
sencillez, as como la estructura de actividades y tareas, si bien las fases y mdulos de MTRICA versin 2.1 han dado
paso a la divisin en Procesos, ms adecuada a la entrada-transformacin-salida que se produce en cada una de las
divisiones del ciclo de vida de un proyecto. Para cada tarea se detallan los participantes que intervienen, los productos de
entrada y de salida as como las tcnicas y prcticas a emplear para su obtencin.
En la elaboracin de MTRICA Versin 3 se han tenido en cuenta los mtodos de desarrollo ms extendidos, as como los
ltimos estndares de ingeniera del software y calidad, adems de referencias especficas en cuanto a seguridad y gestin
de proyectos. Tambin se ha tenido en cuenta la experiencia de los usuarios de las versiones anteriores para solventar los
problemas o deficiencias detectados.
En una nica estructura la metodologa MTRICA Versin 3 cubre distintos tipos de desarrollo: estructurado y orientado a
objetos, facilitando a travs de interfaces la realizacin de los procesos de apoyo u organizativos: Gestin de Proyectos,
Gestin de Configuracin, Aseguramiento de Calidad y Seguridad.
PROCESOS PRINCIPALES DE MTRICA VERSIN 3
Los procesos de la estructura principal de MTRICA Versin 3 son los siguientes:
- planificacin de sistemas de informacin.
- desarrollo de sistemas de informacin.
- mantenimiento de sistemas de informacin.
24

En cuanto al Proceso de Desarrollo de Sistemas de Informacin, para facilitar la comprensin y dada su amplitud y
complejidad se ha subdividido en cinco procesos:
-
estudio de viabilidad del sistema (evs).

anlisis del sistema de informacin (asi).
diseo del sistema de informacin (dsi).
construccin del sistema de informacin (csi).
implantacin y aceptacin del sistema (ias).
La necesidad de acortar el ciclo de desarrollo de los sistemas de informacin ha orientado a muchas organizaciones a la
eleccin de productos software del mercado cuya adaptacin a sus requerimientos supona un esfuerzo bastante inferior al
de un desarrollo a medida, por no hablar de los costes de mantenimiento. Esta decisin, que es estratgica en muchas
ocasiones para una organizacin, debe tomarse con las debidas precauciones, y es una realidad que est cambiando el
escenario del desarrollo del software. Otra consecuencia de lo anterior es la prctica, cada vez ms habitual en las
organizaciones, de la contratacin de servicios externos en relacin con los sistemas y tecnologas de la informacin y las
comunicaciones, llevando a la necesidad de una buena gestin y control de dichos servicios externos y del riesgo implcito
en todo ello, para que sus resultados supongan un beneficio para la organizacin. MTRICA Versin 3 facilita la toma de
decisin y la realizacin de todas las tareas que comprende el desarrollo de un sistema de informacin.
Planificacin de Sistemas de Informacin (PSI)
El objetivo de un Plan de Sistemas de Informacin es proporcionar un marco estratgico de referencia para los Sistemas de
Informacin de un determinado mbito de la Organizacin.
El resultado del Plan de Sistemas debe, por tanto, orientar las actuaciones en materia de desarrollo de Sistemas de
Informacin con el objetivo bsico de apoyar la estrategia corporativa, elaborando una arquitectura de informacin y un plan
de proyectos informticos para dar apoyo a los objetivos estratgicos.
Por este motivo es necesario un proceso como el de Planificacin de Sistemas de Informacin, en el que participen, por un
lado los responsables de los procesos de la organizacin con una visin estratgica y por otro, los profesionales de SI
capaces de enriquecer dicha visin con la aportacin de ventajas competitivas por medio de los sistemas y tecnologas de
la informacin y comunicaciones.
Como productos finales de este proceso se obtienen los siguientes, que podrn constituir la entrada para el siguiente
proceso de Estudio de Viabilidad del Sistema:
Catlogo de requisitos de PSI que surge del estudio de la situacin actual en el caso de que sea significativo dicho
estudio, del diagnstico que se haya llevado a cabo y de las necesidades de informacin de los procesos de la organizacin
afectados por el plan de sistemas.
Arquitectura de informacin que se compone a su vez de los siguientes productos:
o Modelo de informacin.
o Modelo de sistemas de informacin.
o Arquitectura tecnolgica.
o Plan de proyectos.
o Plan de mantenimiento del PSI.
25

Un Plan de Sistemas de Informacin proporcionar un marco de referencia en materia de Sistemas de Informacin. En
ocasiones podr servir de palanca de cambio para los procesos de la Organizacin, pero su objetivo estar siempre
diferenciado del de un anlisis de dichos procesos por s mismos. Dicho en otras palabras, no se debe confundir el
resultado que se persigue con un Plan de Sistemas de Informacin, con el de una mejora o reingeniera de procesos, ya
que los objetivos en ambos casos no son los mismos, aunque el medio para conseguirlos tenga puntos en comn (estudio
de los procesos y alineamiento con los objetivos estratgicos).
Este nuevo enfoque de alineamiento de los sistemas de informacin con la estrategia de la organizacin, la implicacin
directa de la alta direccin y la propuesta de solucin presenta como ventajas:
- La implicacin de la alta direccin facilita que se pueda desarrollar con los recursos necesarios y el calendario
establecido.
- La perspectiva horizontal de los procesos dentro de la Organizacin facilita que se atienda a intereses globales y no
particulares de unidades organizativas que puedan desvirtuar los objetivos del Plan. Para mantener la visin general que
apoye los objetivos estratgicos, el enfoque de un Plan de Sistemas de Informacin debe orientarse al estudio por
procesos.
- La prioridad del desarrollo de los sistemas de informacin de la organizacin por objetivos estratgicos.
- La propuesta de Arquitectura de Informacin que se hace en el plan es ms estratgica que tecnolgica. El modelo de
sistemas de informacin de la propuesta no es terico y se
contemplan los sistemas de informacin actuales que se mantendrn.
Desarrollo de Sistemas de Informacin

El proceso de Desarrollo de MTRICA Versin 3 contiene todas las actividades y tareas que se deben llevar a cabo para
desarrollar un sistema, cubriendo desde el anlisis de requisitos hasta la instalacin del software. Adems de las tareas
relativas al anlisis, incluye dos partes en el diseo de sistemas: arquitectnico y detallado. Tambin cubre las pruebas
unitarias y de integracin del sistema, aunque siguiendo la norma ISO 12.207 no propone ninguna tcnica especfica y
destaca la importancia de la evolucin de los requisitos. Este proceso es, sin duda, el ms importante de los identificados
en el ciclo de vida de un sistema y se relaciona con todos los dems.
Las actividades y tareas propuestas por la norma se encuentran ms en la lnea de un desarrollo clsico, separando datos y
procesos, que en la de un enfoque orientado a objetos.
En MTRICA Versin 3 se han abordado los dos tipos de desarrollo: estructurado y orientado a objeto, por lo que ha sido
necesario establecer actividades especficas a realizar en alguno de los procesos cuando se utiliza la tecnologa de
orientacin a objetos. Para este ltimo caso se ha analizado alguna de las propuestas de otras metodologas orientadas a
objetos y se han tenido en cuenta la mayora de las tcnicas que contempla UML 1.2 (Unified Modeling Language).
El desarrollo en MTRICA Versin 3 lo constituyen los procesos:
-
ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS).

ANLISIS DEL SISTEMA DE INFORMACIN (ASI).
DISEO DEL SISTEMA DE INFORMACIN (DSI).
CONSTRUCCIN DEL SISTEMA DE INFORMACIN (CSI).
IMPLANTACIN Y ACEPTACIN DEL SISTEMA (IAS).
26

Estudio de Viabilidad del Sistema (EVS)
El propsito de este proceso es analizar un conjunto concreto de necesidades, con la idea de proponer una solucin a corto
plazo. Los criterios con los que se hace esta propuesta no sern estratgicos sino tcticos y relacionados con aspectos
econmicos, tcnicos, legales y operativos.
Los resultados del Estudio de Viabilidad del Sistema constituirn la base para tomar la decisin de seguir adelante o
abandonar. Si se decide seguir adelante pueden surgir uno o varios proyectos que afecten a uno o varios sistemas de
informacin. Dichos sistemas se desarrollarn segn el resultado obtenido en el estudio de viabilidad y teniendo en cuenta
la cartera de proyectos para la estrategia de implantacin del sistema global.
Se ha considerado que este proceso es obligatorio, aunque el nivel de profundidad con el que se lleve a cabo depender de
cada caso. La conveniencia de la realizacin del estudio de la situacin actual depende del valor aadido previsto para la
especificacin de requisitos y para el planteamiento de alternativas de solucin. En las alternativas se considerarn
soluciones "a medida", soluciones basadas en la adquisicin de productos software del mercado o soluciones mixtas.
Para valorar las alternativas planteadas y determinar una nica solucin, se estudiar el impacto en la organizacin de cada
una de ellas, la inversin y los riesgos asociados.
El resultado final de este proceso son los productos relacionados con la solucin que se propone para cubrir la necesidad
concreta que se plante en el proceso, y que depende de si la solucin conlleva desarrollo a medida o no:
Contexto del sistema (con la definicin de las interfaces en funcin de la solucin).
Impacto en la organizacin.
Coste/beneficio de la solucin.
Valoracin de riesgos de la solucin.
Enfoque del plan de trabajo de la solucin.
Planificacin de la solucin.
Solucin propuesta:
o Descripcin de la solucin.
o Modelo de descomposicin en subsistemas.
o Matriz de procesos/localizacin geogrfica.
o Matriz datos/localizacin geogrfica. Entorno tecnolgico y comunicaciones.
o Estrategia de implantacin global del sistema.
o Descripcin de los procesos manuales.
Si la alternativa incluye desarrollo:
o Modelo abstracto de datos/Modelo de procesos.
o Modelo de negocio/Modelo de dominio.
Si la alternativa incluye un producto software estndar de mercado:
o Descripcin del producto.
o Evolucin del producto.
o Costes ocasionados por el producto.
o Estndares del producto.
o Descripcin de adaptacin si es necesaria.
27

Si en la organizacin se ha realizado con anterioridad un Plan de Sistemas de Informacin que afecte al sistema objeto de
este estudio, se dispondr de un conjunto de productos que proporcionarn informacin a tener en cuenta en todo el
proceso.
Anlisis del Sistema de Informacin (ASI)

El propsito de este proceso es conseguir la especificacin detallada del sistema de informacin, a travs de un catlogo de
requisitos y una serie de modelos que cubran las necesidades de informacin de los usuarios para los que se desarrollar el
sistema de informacin y que sern la entrada para el proceso de Diseo del Sistema de Informacin.
Como ya se ha dicho MTRICA Versin 3 cubre tanto desarrollos estructurados como orientados a objetos, y las
actividades de ambas aproximaciones estn integradas en una estructura comn aunque presenta alguna actividad
exclusiva para cada tipo de desarrollo.
En primer lugar se describe inicialmente el sistema de informacin, a partir de los productos generados en el proceso
Estudio de Viabilidad del Sistema (EVS). Se delimita su alcance, se genera un catlogo de requisitos generales y se
describe el sistema mediante unos modelos iniciales de alto nivel.
Se recogen de forma detallada los requisitos funcionales que el sistema de informacin debe cubrir, catalogndolos, lo que
permite hacer la traza a lo largo de los procesos de desarrollo. Adems, se identifican los requisitos no funcionales del
sistema, es decir, las facilidades que ha de proporcionar el sistema, y las restricciones a que estar sometido, en cuanto a
rendimiento, frecuencia de tratamiento, seguridad, etc.
Para facilitar el anlisis del sistema se identifican los subsistemas de anlisis, y se elaboran los modelos de Casos de Uso y
de Clases, en desarrollos orientados a objetos, y de Datos y Procesos en desarrollos estructurados. Se ha incorporado una
actividad especfica para la definicin de Interfaces de Usuario al tiempo que se van obteniendo y depurando los requisitos y
los anteriores modelos. Se especificarn todas las interfaces entre el sistema y el usuario, como formatos de pantallas,
dilogos, formatos de informes y formularios de entrada.
Finalizados los modelos, se realiza un anlisis de consistencia, mediante una verificacin y validacin, lo que puede forzar
la modificacin de algunos de los modelos obtenidos.
Una vez realizado dicho anlisis de consistencia se elabora el producto Especificacin de Requisitos Software, que
constituye un punto de referencia en el desarrollo del software y la lnea base de referencia para las peticiones de cambio
sobre los requisitos inicialmente
especificados.
En este proceso se inicia tambin la especificacin del Plan de Pruebas, que se completar en el proceso Diseo del
Sistema de Informacin (DSI).
Los productos resultantes del Anlisis del Sistema de Informacin, dependen del tipo de desarrollo de que se trate y se
detallan a continuacin especificando los que son distintos, segn los dos tipos de desarrollo a los que da respuesta
MTRICA Versin 3:
Descripcin general del entorno tecnolgico.
Glosario de trminos.
Catlogo de normas.
28

Catlogo de requisitos.
Especificacin de interfaz de usuario.
Adems, en Anlisis Estructurado:
Plan de migracin y carga inicial de datos.

Contexto del sistema.
Matriz de procesos/localizacin geogrfica.
Descripcin de interfaz con otros sistemas.
Modelo de procesos.
Modelo lgico de datos normalizado.
Adems, en Anlisis Orientado a Objetos:
Descripcin de subsistemas de anlisis.

Descripcin de interfaces entre subsistemas.
Modelo de clases de anlisis.
Comportamiento de clases de anlisis.
Anlisis de la realizacin de los casos de uso.
En este proceso es muy importante la participacin de los usuarios, a travs de tcnicas interactivas, como diseo de
dilogos y prototipos, que permiten al usuario familiarizarse con el nuevo sistema y colaborar en la construccin y
perfeccionamiento del mismo.
Diseo del Sistema de Informacin (DSI)
El propsito del Diseo del Sistema de Informacin (DSI) es obtener la definicin de la arquitectura del sistema y del
entorno tecnolgico que le va a dar soporte, junto con la especificacin detallada de los componentes del sistema de
informacin. A partir de dicha informacin, se generan todas las especificaciones de construccin relativas al propio sistema,
as como la especificacin tcnica del plan de pruebas, la definicin de los requisitos de implantacin y el diseo de los
procedimientos de migracin y carga inicial, stos ltimos cuando proceda.
El diseo de la arquitectura del sistema depender en gran medida de las caractersticas de la instalacin, de modo que se
ha de tener en cuenta una participacin activa de los responsables de Sistemas y Explotacin de las Organizaciones para
las que se desarrolla el sistema de informacin.
Este proceso consta de un primer bloque de actividades, que se realizan en paralelo, y cuyo objetivo es obtener el diseo
de detalle del sistema de informacin que comprende la particin fsica del sistema de informacin, independiente de un
entorno tecnolgico concreto, la organizacin en subsistemas de diseo, la especificacin del entorno tecnolgico sobre el
que se despliegan dichos subsistemas y la definicin de los requisitos de operacin, administracin del sistema, seguridad y
control de acceso. En el caso de diseo orientado a objetos, conviene sealar que se ha contemplado que el diseo de la
persistencia se lleva a cabo sobre bases de datos relacionales.
De este primer bloque de actividades se obtienen los siguientes productos:
Catlogo de requisitos (se completa).
Catlogo de excepciones.
Catlogo de normas para el diseo y construccin.
Diseo de la arquitectura del sistema.
Entorno tecnolgico del sistema.
Procedimientos de operacin y administracin del sistema.
Procedimientos de seguridad y control de acceso.
Diseo detallado de los subsistemas de soporte.
29

Modelo fsico de datos optimizado.
Asignacin de esquemas fsicos de datos a nodos.
Adems, en Diseo Estructurado:
Diseo de la arquitectura modular.
Diseo de interfaz de usuario.
Adems, en Diseo Orientado a Objetos:
Diseo de la realizacin de casos de uso.
Modelo de clases de diseo.
Comportamiento de clases de diseo.
Diseo de interfaz de usuario.
Al igual que en el proceso de Anlisis del Sistema de Informacin (ASI), antes de proceder a la especificacin de los
componentes, se realiza una verificacin y validacin, con objeto de analizar la consistencia entre los distintos modelos y
formalizar la aceptacin del diseo de la arquitectura del sistema por parte de los usuarios de Explotacin y Sistemas.
Un segundo bloque de actividades complementa el diseo del sistema de informacin, en el que se generan todas las
especificaciones necesarias para la construccin del sistema de informacin:
Las especificaciones de construccin de los componentes del sistema (mdulos o clases, segn el caso) y de las
estructuras de datos.
Los procedimientos de migracin y sus componentes asociados.
La definicin y revisin del plan de pruebas, y el diseo de las verificaciones de los niveles de prueba
establecidos.
El catlogo de excepciones que permite establecer un conjunto de verificaciones relacionadas con el propio
diseo o con la arquitectura del sistema.
La especificacin de los requisitos de implantacin.
Construccin del Sistema de Informacin (CSI)
La construccin del Sistema de Informacin (CSI) tiene como objetivo final la construccin y prueba de los distintos
componentes del sistema de informacin, a partir del conjunto de especificaciones lgicas y fsicas del mismo, obtenido en
el Proceso de Diseo del Sistema de Informacin (DSI). Se desarrollan los procedimientos de operacin y seguridad y se
elaboran los manuales de usuario final y de explotacin, estos ltimos cuando proceda.
Para conseguir dicho objetivo, se recoge la informacin relativa al producto del diseo
Especificaciones de construccin del sistema de informacin, se prepara el entorno de construccin, se genera el cdigo de
cada uno de los componentes del sistema de informacin y se van realizando, a medida que se vaya finalizando la
construccin, las pruebas unitarias de cada uno de ellos y las de integracin entre subsistemas.
Si fuera necesario realizar una migracin de datos, es en este proceso donde se lleva a cabo la construccin de los
componentes de migracin y procedimientos de migracin y carga inicial de datos.
Como resultado de dicho proceso se obtiene:
Resultado de las pruebas unitarias.

Evaluacin del resultado de las pruebas de integracin.
Evaluacin del resultado de las pruebas del sistema.
Producto software:
30
Cdigo fuente de los componentes.

Procedimientos de operacin y administracin del sistema.
Procedimientos de seguridad y control de acceso.
Manuales de usuario.
Especificacin de la formacin a usuarios finales.
Cdigo fuente de los componentes de migracin y carga inicial de datos.
Procedimientos de migracin y carga inicial de datos.
Evaluacin del resultado de las pruebas de migracin y carga inicial de datos.
Implantacin y Aceptacin del Sistema (IAS)

Este proceso tiene como objetivo principal, la entrega y aceptacin del sistema en su totalidad, que puede comprender
varios sistemas de informacin desarrollados de manera independiente, segn se haya establecido en el proceso de
Estudio de Viabilidad del Sistema (EVS), y un segundo objetivo que es llevar a cabo las actividades oportunas para el paso
a produccin del sistema.
Se establece el plan de implantacin, una vez revisada la estrategia de implantacin y se detalla el equipo que lo realizar.
Para el inicio de este proceso se toman como punto de partida los componentes del sistema probados de forma unitaria e
integrados en el proceso Construccin del Sistema de Informacin (CSI), as como la documentacin asociada. El Sistema
se someter a las Pruebas de Implantacin con la participacin del usuario de operacin cuya responsabilidad, entre otros
aspectos, es comprobar el comportamiento del sistema bajo las condiciones ms extremas.
Tambin se someter a las Pruebas de Aceptacin cuya ejecucin es responsabilidad del usuario final. En este proceso se
elabora el plan de mantenimiento del sistema de forma que el responsable del mantenimiento conozca el sistema antes de
que ste pase a produccin.
Tambin se establece el acuerdo de nivel de servicio requerido una vez que se inicie la produccin. El acuerdo de nivel de
servicio hace referencia a servicios de gestin de operaciones, de soporte a usuarios y al nivel con el que se prestarn
dichos servicios.
Como resultado de este proceso se obtienen los siguientes productos:
Plan de implantacin del sistema en su totalidad.
Equipo de implantacin que realizar la implantacin.
Plan de formacin del equipo de implantacin (esquema, materiales, recursos
necesarios, planificacin y especificacin de la formacin de usuarios finales).
Evaluacin de las pruebas de implantacin del sistema por parte del usuario de
operacin.
Evaluacin de las pruebas de aceptacin del sistema por parte del usuario final.
Plan de mantenimiento previo al paso a produccin.
Acuerdo de nivel de servicio del sistema.
Sistema en produccin.
Mantenimiento de Sistemas de Informacin (MSI)
El objetivo de este proceso es la obtencin de una nueva versin de un sistema de informacin desarrollado con MTRICA,
a partir de las peticiones de mantenimiento que los usuarios realizan con motivo de un problema detectado en el sistema o
por la necesidad de una mejora del mismo.
31

Como consecuencia de esto, slo se considerarn en MTRICA Versin 3 los tipos de Mantenimiento Correctivo y
Evolutivo. Se excluyen los tipos de Mantenimiento Adaptativo y Perfectivo, que abarcan actividades tales como la migracin
y la retirada de software que precisaran el desarrollo de un tipo de metodologa especfica para resolver su cometido.
Ante una peticin de cambio de un sistema de informacin ya en produccin, se realiza un registro de las peticiones, se
diagnostica el tipo de mantenimiento y se decide si se le da respuesta o no, en funcin del plan de mantenimiento asociado
al sistema afectado por la peticin, y se establece con qu prioridad
La definicin de la solucin al problema o necesidad planteada por el usuario que realiza el responsable de mantenimiento,
incluye un estudio del impacto, la valoracin del esfuerzo y coste, las actividades y tareas del proceso de desarrollo a
realizar y el plan de pruebas de regresin.
Los productos que se obtienen en este proceso son los siguientes:
Catlogo de peticiones de cambio.

Resultado del estudio de la peticin.
Propuesta de solucin.
Anlisis de impacto de los cambios.
Plan de accin para la modificacin.
Plan de pruebas de regresin.
Evaluacin del cambio.
Evaluacin del resultado de las pruebas de regresin.
INTERFACES DE MTRICA VERSIN 3

La estructura de MTRICA Versin 3 incluye tambin un conjunto de interfaces que definen una serie de actividades de tipo
organizativo o de soporte al proceso de desarrollo y a los productos, que en el caso de existir en la organizacin se debern
aplicar para enriquecer o influir en la ejecucin de las actividades de los procesos principales de la metodologa y que si no
existen habr que realizar para complementar y garantizar el xito del proyecto desarrollado con MTRICA Versin 3.
La aplicacin de MTRICA Versin 3 proporciona sistemas con calidad y seguridad, no obstante puede ser necesario en
funcin de las caractersticas del sistema un refuerzo especial en estos aspectos, refuerzo que se obtendra aplicando la
interfaz.
Las interfaces descritas en la metodologa son:
-
Gestin de Proyectos (GP)

Seguridad (SEG)
Aseguramiento de la Calidad (CAL)
Gestin de la Configuracin (GC)
Gestin de Proyectos
La Gestin de Proyectos tiene como finalidad principal la planificacin, el seguimiento y control de las actividades y de los
recursos humanos y materiales que intervienen en el desarrollo de un Sistema de Informacin. Como consecuencia de este
control es posible conocer en todo momento qu problemas se producen y resolverlos o paliarlos lo ms pronto posible, lo
32

cual evitar desviaciones temporales y econmicas. La Interfaz de Gestin de Proyectos de MTRICA Versin 3 contempla
proyectos de desarrollo de Sistemas de Informacin en sentido amplio, acorde con EUROMTODO se consideran
proyectos de desarrollo de nuevos Sistemas de Informacin y tambin los proyectos de ampliacin y mejora de los ya
existentes.
Las actividades de la Interfaz de Gestin de Proyectos son de tres tipos:

- Actividades de Inicio del Proyecto (GPI), que permiten estimar el esfuerzo y establecer la planificacin del
proyecto.
- Actividades de Seguimiento y Control (GPS), supervisando la realizacin de las tareas por parte del equipo de
proyecto y gestionando las incidencias y cambios en los requisitos que puedan presentarse y afectar a la
planificacin del proyecto.
- Actividades de Finalizacin del Proyecto, cierre y registro de la documentacin de gestin.
Estas actividades pueden requerir, en funcin de la complejidad del proyecto, el soporte de herramientas comerciales de
gestin de proyectos.
Seguridad
El anlisis de los riesgos constituye una pieza fundamental en el diseo y desarrollo de sistemas de informacin seguros. Si
bien los riesgos que afectan a un sistema de informacin son de distinta ndole: naturales (inundaciones, incendios, etc.) o
lgicos (fallos propios, ataques externos, virus, etc.) son estos ltimos los contemplados en la interfaz de Seguridad de
MTRICA Versin 3.
El objetivo de la interfaz de seguridad de MTRICA Versin 3 es incorporar en los sistemas de informacin mecanismos de
seguridad adicionales a los que se proponen en la propia metodologa, asegurando el desarrollo de cualquier tipo de
sistema a lo largo de los procesos que se realicen para su obtencin.
La interfaz de Seguridad hace posible incorporar durante la fase de desarrollo las funciones y mecanismos que refuerzan la
seguridad del nuevo sistema y del propio proceso de desarrollo, asegurando su consistencia y seguridad, completando el
plan de seguridad vigente en la organizacin o desarrollndolo desde el principio, utilizando MAGERIT como metodologa
de anlisis y gestin de riesgos en el caso de que la organizacin no disponga de su propia metodologa.
En consecuencia, la interfaz contempla dos tipos de actividades diferenciadas:
- Actividades relacionadas con la seguridad intrnseca del sistema de informacin.
- Actividades que velan por la seguridad del propio proceso de desarrollo del sistema de informacin.
As mismo se hace especial hincapi en la formacin en materia de seguridad.
Las valoraciones sobre la seguridad deben realizarse en funcin de las caractersticas del sistema sin perder de vista
adems que, al ser finitos los recursos, no pueden asegurarse todos los aspectos del desarrollo de los sistemas de
informacin, por lo que habr que aceptar un determinado nivel de riesgo concentrndose en los aspectos ms
comprometidos o amenazados, que sern diferentes segn las circunstancias.
Gestin de la Configuracin
33

La interfaz de gestin de la configuracin consiste en la aplicacin de procedimientos administrativos y tcnicos durante el
desarrollo del sistema de informacin y su posterior mantenimiento. Su finalidad es identificar, definir, proporcionar
informacin y controlar los cambios en la configuracin del sistema, as como las modificaciones y versiones de los mismos.
Este proceso permitir conocer el estado de cada uno de los productos que se hayan definido como elementos de
configuracin, garantizando que no se realizan cambios incontrolados y que todos los participantes en el desarrollo del
sistema disponen de la versin adecuada de los productos que manejan.
La interfaz de gestin de configuracin de MTRICA Versin 3 permite definir las necesidades de gestin de configuracin
para cada sistema de informacin, recogindolas en un plan de gestin de configuracin, en el que se especifican
actividades de identificacin y registro de productos, que se realizan durante todas las actividades de MTRICA Versin 3
asociadas al desarrollo y mantenimiento del sistema de informacin. Asimismo, permite controlar el sistema como producto
global a lo largo de su creacin, obtener informes sobre el estado de desarrollo en que se encuentra y reducir el nmero de
errores durante el mismo, lo que se traduce en un aumento de calidad del proceso de desarrollo y de mejora de la
productividad en la organizacin. La gestin de configuracin facilita adems el mantenimiento del sistema, aportando
informacin precisa para valorar el impacto de los cambios solicitados y reduciendo el tiempo de implementacin de un
cambio, tanto evolutivo como correctivo.
Aseguramiento de la Calidad
El objetivo de la interfaz de Aseguramiento de la Calidad de MTRICA Versin 3 es proporcionar un marco comn de
referencia para la definicin y puesta en marcha de planes especficos de aseguramiento de calidad aplicables a proyectos
concretos.
Las actividades propias de la interfaz de Calidad en MTRICA Versin 3 estn orientadas a verificar la calidad de los
productos. Son actividades que evalan la calidad y que son realizadas por un grupo de Asesoramiento de la Calidad
independiente de los responsables de la obtencin de los productos. Estas actividades de interfaz de MTRICA Versin 3
no entran en contradiccin con el Plan General de Garanta de Calidad (PGGC), siendo lo suficientemente abiertas como
para soportar una nueva versin del PGGC en el futuro.
Las actividades contempladas en la interfaz de Aseguramiento de la Calidad permitirn:
- Reducir, eliminar y prevenir las deficiencias de calidad de los productos a obtener.
- Alcanzar una razonable confianza en que las prestaciones y servicios esperados por el cliente o el usuario
queden satisfechas.
Preguntas
1. Qu es metrica3?
2. Cul su opinin en lo que a contratacin de servicios externos para sistemas se refiere?
3. Qu procesos constituyen lo que es mtrica3?
34
WORK PAPER # 5

APRO 012
ELABORO:
Nro. DE HOJAS: 5
CDIGO:
TITULO WORK PAPER: Estudio de Factibilidad

DPTO:
UDABOL LA PAZ
DESTINADO A:
DOCENTE
ALUMNOS
ADMINISTRATIVOS
OTROS
OBSERVACIONES:
FECHA DE DIFUSIN:
FECHA DE ENTREGA:
35
ESTUDIO DE FACTIBILIDAD
INTRODUCCIN
Al hablar de estudio de factibilidad entran en juego una serie de requisitos que se deben estudiar cuidadosamente para
lograr el objetivo de este proceso dentro de una organizacin. Con el estudio de factibilidad se busca tratar de resolver los
problemas de la organizacin a travs de un sistema de informacin. Este proceso se apoya en tres aspectos bsicos como
lo son la factibilidad operativa, tcnico y econmica. Con este estudio se puede determinar si la solucin del problema a
estudiar es alcanzable dado los recursos y las limitaciones que presenta la empresa, tambin nos permite estudiar todas las
posibles ventajas que este representara si se llegara a implementar en la empresa u organizacin.
ANALISIS DE SISTEMAS
Es el anlisis de un problema de la organizacin que tratar de resolverse a travs de un sistema de informacin. Consiste
en definir el problema, identificar las causas, especificar la solucin e identificar los requerimientos de informacin que
deben ser cubiertos.
El secreto para la realizacin de un buen sistema de informacin es comprender a fondo la organizacin y el sistema
existente. Para lograr esto el analista de sistemas crea un mapa de la institucin y sus sistemas, identificando a los
propietarios y usuarios de los datos, ya que estos tienen un inters directo sobre la informacin afectada por el nuevo
sistema , tambin describe de manera breve el hardware y software existentes.
Una vez realizado el anlisis organizacional, el analista de sistemas identifica los problemas de los sistemas actuales.
Examinado documentos, observando las operaciones de los sistemas y entrevistando a los usuarios, se puede identificar
las reas con problemas y los objetivos a ser cubiertos por la nueva solucin. Frecuentemente la solucin implica o el
desarrollo de una nueva solucin o el mejoramiento de la ya existente.
Adems de las recomendaciones para la solucin, el anlisis de sistemas implica un estudio de factibilidad.
Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas sealados, la
factibilidad se apoya en 3 aspectos bsicos:Operativo, Tcnico,
Econmico.
El xito de un proyecto esta determinado por el grado de factibilidad que se presente en cada una de los tres aspectos
anteriores.
ESTUDIO DE FACTIBILIDAD.
Un estudio de factibilidad es una manera de determinar si una solucin es alcanzable, dados los recursos y limitaciones de
la organizacin.
Sirve para recopilar datos relevantes sobre el desarrollo de un proyecto y en base a ello tomar la mejor decisin, si procede
su estudio, desarrollo o implementacin.
36

OBJETIVO DE UN ESTUDIO DE FACTIBILIDAD.
1. Auxiliar a una organizacin a lograr sus objetivos.
2. Cubrir la metas con los recursos actuales en las siguientes reas.
Factibilidad Tcnica.
Se refiere a los recursos necesarios como herramientas, conocimientos, habilidades, experiencia, etc., que son necesarios
para efectuar las actividades o procesos que requiere el proyecto. Generalmente nos referimos a elementos tangibles
(medibles). El proyecto debe considerar si los recursos tcnicos actuales son suficientes, si la solucin propuesta puede ser
implantada con el software, el hardware y los recursos tcnicos disponibles o deben complementarse.
a.
b.
En otras palabras, revisa aspectos como:

Mejora del sistema actual.
Disponibilidad de tecnologa que satisfaga las necesidades.
Factibilidad Econmica.
Se refiere a los recursos econmicos y financieros necesarios para desarrollar o llevar a cabo las actividades o procesos,
adems debe considerarse el costo del tiempo, el costo de la realizacin y el costo de adquirir nuevos recursos.
Generalmente la factibilidad econmica es el elemento mas importante ya que a travs de el se solventan las dems
carencias de otros recursos, es lo mas difcil de conseguir y requiere de actividades adicionales cuando no se posee.
Permite ver si los beneficios de una solucin propuesta son mayores que los costos, entre las variables que revisa
encontramos:
c.
d.
e.
f.
g.
h.
Tiempo del analista.

Costo de estudio.
Costo del tiempo del personal.
Costo del tiempo.
Costo del desarrollo / adquisicin.
Factibilidad Operativa.
i.
j.
Se refiere a todos aquellos recursos donde interviene algn tipo de actividad (Procesos), depende de los recursos humanos
que participen durante la operacin del proyecto. Durante esta etapa se identifican todas aquellas actividades que son
necesarias para lograr el objetivo y se evala y determina todo lo necesario para llevarla a cabo.
Determina si una solucin propuesta es deseable dentro del marco administrativo y organizacional existente, y busca:
Operacin garantizada.
Uso garantizado.
Por lo general, el proceso de anlisis de sistemas identificar ciertas soluciones distintas que pueden ser adoptadas por la
institucin. En este caso se debe evaluar la factibilidad de cada una de ellas.
37
DEFINICIN DE OBJETIVOS
La investigacin de factibilidad en un proyecto que consiste en descubrir cuales son los objetivos de la
organizacin, luego determinar si el proyecto es til para que la empresa logre sus objetivos. La bsqueda de
estos objetivos debe contemplar los recursos disponibles o aquellos que la empresa puede proporcionar,
nunca deben definirse con recursos que la empresa no es capaz de dar.
En las empresas se cuenta con una serie de objetivos que determinan la posibilidad de factibilidad de un proyecto sin ser
limitativos. Estos objetivos son los siguientes:
Reduccin de costos mediante la optimizacin o eliminacin de recursos no necesarios.
Reduccin de errores y mayor precisin en los procesos.
Integracin de todas la reas y subsistemas de la empresa.
Actualizacin y mejoramiento de los servicios a clientes o usuarios.
Aceleracin en la recopilacin de datos.
Reduccin en el tiempo de procesamiento y ejecucin de tareas.
Automatizacin optima de procedimientos manuales.
OBJETIVOS DEL ANLISIS DE FACTIBILIDAD
La investigacin de factibilidad en un proyecto, consiste en descubrir cuales son los objetivos de la organizacin, luego
determinar si el proyecto es til para que la empresa logre sus objetivos. La bsqueda de estos objetivos debe contemplar
los recursos disponibles o aquellos que la empresa puede proporcionar, nunca deben definirse con recursos que la empresa
no es capaz de dar.
En las empresas se cuenta con una serie de objetivos que determinan la posibilidad de factibilidad de un proyecto sin ser
limitativos. Estos objetivos son los siguientes:
k.
l.
m.
n.
o.
p.
q.
Reduccin de errores y mayor precisin en los procesos.

Reduccin de costos mediante la optimizacin o eliminacin de recursos no necesarios.
Integracin de todas la reas y subsistemas de la empresa.
Actualizacin y mejoramiento de los servicios a clientes o usuarios.
Aceleracin en la recopilacin de datos.
Reduccin en el tiempo de procesamiento y ejecucin de tareas.
Automatizacin optima de procedimientos manuales.
PRESENTACIN DE UN ESTUDIO DE FACTIBILIDAD
Un estudio de factibilidad requiere ser presentado con todas la posibles ventajas para la empresa u organizacin, pero sin
descuidar ninguno de los elementos necesarios para que el proyecto funcione. Para esto dentro de los estudios de
factibilidad se complementan dos pasos en la presentacin del estudio:
r.
Requisitos ptimos.
s.
Requisitos Mnimos.
El primer paso se refiere a presentar un estudio con los requisitos ptimos que el proyecto requiera, estos elementos
debern ser los necesarios para que las actividades y resultados del proyecto sean obtenidos con la mxima eficacia.
38

El segundo paso consiste en un estudio de requisitos mnimos, el cual cubre los requisitos mnimos necesarios que el
proyecto debe ocupar para obtener las metas y objetivos, este paso trata de hacer uso de los recursos disponibles de la
empresa para minimizar cualquier gasto o adquisicin adicional.
Un estudio de factibilidad debe representar grficamente los gastos y los beneficios que acarrear la puesta en marcha del
sistema, para tal efecto se hace uso de la curva costo-beneficio.
39
WORK PAPER # 6

APRO 012
ELABORO:
Nro. DE HOJAS: 5
CDIGO:
TITULO WORK PAPER: Especificacin y manejo de los requerimientos del

Software
DPTO:
UDABOL LA PAZ
DESTINADO A:
DOCENTE
ALUMNOS
ADMINISTRATIVOS
OTROS
OBSERVACIONES:
FECHA DE DIFUSIN:
FECHA DE ENTREGA:
40

Especificacin y manejo de los requerimientos del Software
Introduccin
Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de software, ellos se basan muchos
participantes del proyecto para:
Planear el proyecto y los recursos que se usarn en l. Los lideres de proyecto usan los requerimientos como una base
para la estimacin del esfuerzo necesario en un proyecto.
Especificar el tipo de verificaciones que se habrn de realizar al sistema. Por ejemplo: cuando se esta tratando de
alinearse a cierta norma oficial o estndar.
Planear la estrategia de prueba a la que habr de ser sometido el sistema. Los requerimientos son la base sobre la
cual se decide si un caso de prueba fue ejecutado exitosamente por el sistema o no.
Son el fundamento del ciclo de vida del proyecto. Los requerimientos documentados son la base para crear la
documentacin del sistema
De ah su importancia y la importancia de que deban de ser definidos y manejados de la forma mas adecuada posible.
Qu son Requerimientos?
Normalmente, un tema de la Ingeniera de Software tiene diferentes significados. De las muchas definiciones que existen
para requerimiento, ha continuacin se presenta la definicin que aparece en el glosario de la IEEE .
(1) Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condicin o
capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar,
especificacin u otro documento formal. (3) Una representacin documentada de una condicin o capacidad como en (1) o
(2).
Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales.
Los requerimientos funcionales definen las funciones que el sistema ser capaz de realizar. Describen las transformaciones
que el sistema realiza sobre las entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con caractersticas que de una u otra forma puedan limitar el sistema,
como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estndares, etc.
Caractersticas de un requerimiento
Los requerimientos deben ser:
Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su
capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del
proceso.
Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que
vayan a consultarlo en un futuro.
Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la
informacin suficiente para su comprensin.
Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no
debe causar confusiones al lector.
41

Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de
los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas. Si un requerimiento no se
puede comprobar, entonces cmo sabemos si cumplimos con l o no?
Especificados por escrito. Como todo contrato o acuerdo entre dos partes
Lo ms abstracto y conciso posible. Para evitar malas interpretaciones.
Clasificacin de los requerimientos
El clasificar requerimientos es una forma de organizarlos, hay requerimientos que por sus caractersticas no
pueden ser tratados iguales. Por ejemplo, los requerimientos de entrenamiento de personal no son tratados de la
misma manera que los requerimientos de una conexin a Internet.
La siguiente es una recomendacin de como pueden ser clasificados los requerimientos aunque cada proyecto de
software pueda usar sus propias clasificaciones.
Requerimientos del "entorno"
El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar el entorno, existen cierto tipo de
requerimientos que se clasifican en esta categora por que:
El sistema usa el entorno y lo necesita como una fuente de los servicios necesarios para que funcione.
Ejemplos del entorno podemos mencionar: sistemas operativos, sistema de archivos, bases de datos.
El sistema debe de ser robusto y tolerar los errores que puedan ocurrir en el entorno, tales como congestin
en los dispositivos y errores de entrada de datos, por lo tanto el entorno se debe de considerar dentro de los
requerimientos.
Requerimientos "ergonmicos"
El mas conocido de los requerimientos ergonmicos es la interface con el usuario o GUI (Graphic User
Interface). En otras palabras, los requerimientos ergonmicos son la forma en que el ser humano interactua
con el ser sistema.
Requerimientos de Interface
La interface es como interactua el sistema con el ser humano o con otros sistemas (el enfoque es
prcticamente el opuesto a los requerimientos ergonmicos), La interface es la especificacin formal de los
datos que el sistema recibe o manda al exterior. Usualmente se especifica el protocolo, el tipo de informacin,
el medio para comunicarse y el formato de los datos que se van a comunicar.
Requerimientos funcionales
Estos son los que describen lo que el sistema debe de hacer. Es importante que se describa el Que? Y no el
Como?. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos,
la lgica y gran parte del cdigo del sistema.
Requerimientos de desempeo
Estos requerimientos nos informan las caractersticas de desempeo que deben de tener el sistema. Que tan
rpido?, Que tan seguido?, Cuantos recursos?, Cuantas transacciones? .
Este tipo de requerimientos es de especial importancia en los sistemas de tiempo real en donde el
desempeo de un sistema es tan crtico como su funcionamiento.
Disponibilidad (en un determinado periodo de tiempo)
Este tipo de requerimientos se refiere a la durabilidad, degradacin, potabilidad, flexibilidad, contabilidad y
capacidad de actualizacin. Este tipo de requerimientos es tambin muy importante en sistemas de tiempo
real puesto que estos sistemas manejan aplicaciones crticas que no deben de estar fuera de servicio por
periodos prolongados de tiempo.
42

Entrenamiento
Este tipo de requerimientos se enfoca a las personas que van usar el sistema. Que tipo de usuarios son?,
Que tipo de operadores?, Que manuales se entregarn y en que idioma?
Este tipo de requerimientos, aunque muchas veces no termina en un pedazo de cdigo dentro de el sistema,
son muy importantes en el proceso de diseo ya que facilitan la introduccin y aceptacin de el sistema en
donde ser implementado.
Restricciones de diseo
Muchas veces las soluciones de un sistema de software son normadas por leyes o estndares, este tipo de
normas caen como "restricciones de diseo".
Materiales
Aqu se especifica en que medio se entregara el sistema y como esta empaquetado. Es importante para definir
los costos de industrializacin del sistema.
Dificultades para definir los requerimientos
Los requerimientos no son obvios y vienen de muchas fuentes.
Son difciles de expresar en palabras (el lenguaje es ambiguo).
Existen muchos tipos de requerimientos y diferentes niveles de detalle.
La cantidad de requerimientos en un proyecto puede ser difcil de manejar.
Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros.
Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.
Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas.
Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.
Ingeniera de Requerimientos vs. Administracin de Requerimientos
El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniera de
Requerimientos. La meta de la ingeniera de requerimientos (IR) es entregar una especificacin de requisitos de software
correcta y completa.
43
WORK PAPER # 7

APRO 012
ELABORO:
Nro. DE HOJAS: 6
CDIGO:
TITULO WORK PAPER: Planificacin de un Proyecto de Sistemas

DPTO:
UDABOL LA PAZ
DESTINADO A:
DOCENTE
ALUMNOS
ADMINISTRATIVOS
OTROS
OBSERVACIONES:
FECHA DE DIFUSIN:
FECHA DE ENTREGA:
44

PLANIFICACION DE UN PROYECTO DE SISTEMAS.
Que es un proyecto de Sistema o Software. ?
Es el Proceso de gestin para la creacin de un Sistema o software, la cual encierra un conjunto de actividades, una de las
cuales es la estimacin, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre.
Aunque la estimacin, es mas un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma
descuidada. Existen tcnicas tiles para la estimacin de costes de tiempo. Y dado que la estimacin es la base de todas
las dems actividades de planificacin del proyecto y sirve como gua para una buena Ingeniera Sistemas y Software.
Al estimar tomamos en cuenta no solo del procedimiento tcnico a utilizar en el proyecto, sino que se toma en cuenta los
recursos, costos y planificacin. El Tamao del proyecto es otro factor importante que puede afectar la precisin de las
estimaciones. A medida que el tamao aumenta, crece rpidamente la interdependencia entre varios elementos del
Software.
La disponibilidad de informacin Histrica es otro elemento que determina el riesgo de la estimacin.
Objetivos de la Planificacin del Proyecto.
El objetivo de la Planificacin del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer
estimaciones razonables de recursos costos y planificacin temporal. Estas estimaciones se hacen dentro de un marco de
tiempo limitado al comienzo de un proyecto de software, y deberan actualizarse regularmente medida que progresa el
proyecto. Adems las estimaciones deberan definir los escenarios del mejor caso, y peor caso, de modo que los resultados
del proyecto pueden limitarse.
El Objetivo de la planificacin se logra mediante un proceso de descubrimiento de la informacin que lleve a estimaciones
razonables.
Actividades asociadas al proyecto de software.
mbito del Software.
Es la primera actividad de llevada a cabo durante la planificacin del proyecto de Software.
En esta etapa se deben evaluar la funcin y el rendimiento que se asignaron al Software durante la Ingeniera del Sistema
de Computadora para establecer un mbito de proyecto que no sea ambiguo, e incomprensible para directivos y tcnicos
Describe la funcin, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalan las funciones del mbito y en
algunos casos se refinan para dar mas detalles antes del comienzo de la estimacin. Las restricciones de rendimiento
abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los limites del software originados por el
hardware externo, por la memoria disponible y por otros sistemas existentes.
El mbito se define como un pre-requisito para la estimacin y existen algunos elementos que se debe tomar en cuenta
como es:
La Obtencin de la Informacin necesaria para el software. Para esto el analista y el cliente se renen sobre las
expectativas del proyecto y se ponen de acuerdo en los puntos de inters para su desarrollo.
RECURSOS:
La Segunda tarea de la planificacin del desarrollo de Software es la estimacin de los recursos requeridos para acometer
45

el esfuerzo de desarrollo de Software, esto simula a una pirmide donde las Herramientas (hardware y Software), son la
base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirmide se encuentran los
Componentes reutilizables.
Y en la parte mas alta de la pirmide se encuentra el recurso primario, las personas (el recurso humano).
Cada recurso queda especificado mediante cuatro caractersticas:
Descripcin del Recurso.
Informes de disponibilidad.
Fecha cronolgica en la que se requiere el recurso.
Tiempo durante el que ser aplicado el recurso.
Recursos Humanos.
La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser determinado despus de
hacer una estimacin del esfuerzo de desarrollo (por ejemplo personas mes o personas aos), y seleccionar la posicin
dentro de la organizacin y la especialidad que desempeara cada profesional.
Recursos o componentes de software reutilizables.
Cualquier estudio sobre recursos de software estara incompleto sin estudiar la reutilizacin, esto es la creacin y la
reutilizacin de bloques de construccin de Software.
Tales bloques se deben establecer en catlogos para una consulta ms fcil, estandarizarse para una fcil aplicacin y
validarse para la tambin fcil integracin.
El Autor Bennatan sugiere cuatro categoras de recursos de software que se deberan tener en cuenta a medida que se
avanza con la planificacin:
Componentes ya desarrollados.
Componentes ya experimentados.
Componentes con experiencia Parcial.
Componentes nuevos.
Recursos de entorno.
El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniera de Software, incorpora
Hardware y Software.
El Hardware proporciona una plataforma con las herramientas (Software) requeridas para producir los productos que son el
resultado de la buena practica de la Ingeniera del Software, un planificador de proyectos debe determinar la ventana
temporal requerida para el Hardware y el Software, y verificar que estos recursos estn disponibles. Muchas veces el
desarrollo de las pruebas de validacin de un proyecto de software para la composicin automatizada puede necesitar un
compositor de fotografas en algn punto durante el desarrollo. Cada elemento de hardware debe ser especificado por el
planificador del Proyecto de Software.
ESTIMACION DEL PROYECTO DE SOFTWARE.
En el principio el costo del Software constitua un pequeo porcentaje del costo total de los sistemas basados en
Computadoras. Hoy en da el Software es el elemento mas caro de la mayora de los sistemas informticos.
46

Un gran error en la estimacin del costo puede ser lo que marque la diferencia entre beneficios y perdidas, la estimacin del
costo y del esfuerzo del software nunca ser una ciencia exacta, son demasiadas las variables: humanas, tcnicas, de
entorno, polticas, que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo.
Para realizar estimaciones seguras de costos y esfuerzos tienen varias opciones posibles:
Deje la estimacin para mas adelante (obviamente podemos realizar una estimacin al cien por cien fiable despus de
haber terminado el proyecto.
Base las estimaciones en proyectos similares ya terminados.
Utilice tcnicas de descomposicin relativamente sencillas para generar las estimaciones de costos y esfuerzo del proyecto.
Desarrolle un modelo emprico para l calculo de costos y esfuerzos del Software.
Desdichadamente la primera opcin, aunque atractiva no es practica.
La Segunda opcin puede funcionar razonablemente bien si el proyecto actual es bastante similar a los esfuerzos pasados
y si otras influencias del proyecto son similares. Las opciones restantes son mtodos viables para la estimacin del proyecto
de software. Desde el punto de vista ideal, se deben aplicar conjuntamente las tcnicas indicadas usando cada una de ellas
como comprobacin de las otras.
Antes de hacer una estimacin, el planificador del proyecto debe comprender el mbito del software a construir y generar
una estimacin de su tamao.
Estimacin basada en el Proceso.
Es la tcnica ms comn para estimar un proyecto es basar la estimacin en el proceso que se va a utilizar, es decir, el
proceso se descompone en un conjunto relativamente pequeo de actividades o tareas, y en el esfuerzo requerido para
llevar a cabo la estimacin de cada tarea.
Al igual que las tcnicas basadas en problemas, la estimacin basada en el proceso comienza en una delineacin de las
funciones del software obtenidas a partir del mbito del proyecto. Se mezclan las funciones del problema y las actividades
del proceso. Como ultimo paso se calculan los costos y el esfuerzo de cada funcin y la actividad del proceso de software.
DIFERENTES MODELOS DE ESTIMACION.
Existen diferentes modelos de estimacin como son:
Los Modelos Empricos:
Donde los datos que soportan la mayora de los modelos de estimacin obtienen una muestra limitada de proyectos. Por
esta razn, el modelo de estimacin no es adecuado para todas las clases de software y en todos los entornos de
desarrollo. Por lo tanto los resultados obtenidos de dichos modelos se deben utilizar con prudencia.
El Modelo COCOMO.
Barry Boehm, en su libro clsico sobre economa de la Ingeniera del Software, introduce una jerarqua de modelos de
estimacin de Software con el nombre de COCOMO, por su nombre en Ingles (Constructive, Cost, Model) modelo
47

constructivo de costos. La jerarqua de modelos de Boehm esta constituida por los siguientes:
Modelo I. El Modelo COCOMO bsico calcula el esfuerzo y el costo del desarrollo de Software en funcin del tamao del
programa, expresado en las lneas estimadas.
Modelo II. El Modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en funcin del tamao del
programa y de un conjunto de conductores de costos que incluyen la evaluacin subjetiva del producto, del hardware, del
personal y de los atributos del proyecto.
Modelo III. El modelo COCOMO avanzado incorpora todas las caractersticas de la versin intermedia y lleva a cabo una
evaluacin del impacto de los conductores de costos en cada caso (anlisis, diseo, etc.) del proceso de ingeniera de
Software.
Herramientas Automticas De Estimacin.
Las herramientas automticas de estimacin permiten al planificador estimar costos y esfuerzos, as como llevar a cabo
anlisis del tipo, que pasa si, con importantes variables del proyecto, tales como la fecha de entrega o la seleccin del
personal. Aunque existen muchas herramientas automticas de estimacin, todas exhiben las mismas caractersticas
generales y todas requieren de una o ms clases de datos.
A partir de estos datos, el modelo implementado por la herramienta automtica de estimacin proporciona estimaciones del
esfuerzo requerido para llevar a cabo el proyecto, los costos, la carga de personal, la duracin, y en algunos casos la
planificacin temporal de desarrollo y riesgos asociados.
En resumen el planificador del Proyecto de Software tiene que estimar tres cosas antes de que comience el proyecto:
cuanto durara, cuanto esfuerzo requerir y cuanta gente estar implicada. Adems el planificador debe predecir los recursos
de hardware y software que va a requerir y el riesgo implicado.
Para obtener estimaciones exactas para un proyecto, generalmente se utilizan al menos dos de las tres tcnicas referidas
anteriormente. Mediante la comparacin y la conciliacin de las estimaciones obtenidas con las diferentes tcnicas, el
planificador puede obtener una estimacin ms exacta. La estimacin del proyecto de software nunca ser una ciencia
exacta, pero la combinacin de buenos datos histricos y tcnicas puede mejorar la precisin de la estimacin.
48
WORK PAPER # 8

APRO 012
Nro. DE HOJAS: 6
ELABORO:
CDIGO:
TITULO WORK PAPER: Planificacin de un Proyecto de Sistemas

DPTO:
UDABOL LA PAZ
DESTINADO A:
DOCENTE
ALUMNOS
ADMINISTRATIVOS
OTROS
OBSERVACIONES:
FECHA DE DIFUSIN:
FECHA DE ENTREGA:
DISEO
Conceptos y principios:
El Diseo de Sistemas se define el proceso de aplicar ciertas tcnicas y principios con el propsito de definir un dispositivo,
un proceso o un Sistema, con suficientes detalles como para permitir su interpretacin y realizacin fsica.
La etapa del Diseo del Sistema encierra cuatro etapas:
El diseo de los datos.
Trasforma el modelo de dominio de la informacin, creado durante el anlisis, en las estructuras de datos necesarios para
implementar el Software.
49

El Diseo Arquitectnico.
Define la relacin entre cada uno de los elementos estructurales del programa.
El Diseo de la Interfaz.
Describe como se comunica el Software consigo mismo, con los sistemas que operan junto con el y con los operadores y
usuarios que lo emplean.
El Diseo de procedimientos.
Transforma elementos estructurales de la arquitectura del programa. La importancia del Diseo del Software se puede
definir en una sola palabra Calidad, dentro del diseo es donde se fomenta la calidad del Proyecto. El Diseo es la nica
manera de materializar con precisin los requerimientos del cliente.
El Diseo del Software es un proceso y un modelado a la vez. El proceso de Diseo es un conjunto de pasos repetitivos que
permiten al diseador describir todos los aspectos del Sistema a construir. A lo largo del diseo se evala la calidad del
desarrollo del proyecto con un conjunto de revisiones tcnicas:
El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y debe acumular todos los
requisitos implcitos que desea el cliente.
Debe ser una gua que puedan leer y entender los que construyan el cdigo y los que prueban y mantienen el Software.
El Diseo debe proporcionar una completa idea de lo que es el Software, enfocando los dominios de datos, funcional y
comportamiento desde el punto de vista de la Implementacin.
Para evaluar la calidad de una presentacin del diseo, se deben establecer criterios tcnicos para un buen diseo como
son:
Un diseo debe presentar una organizacin jerrquica que haga un uso inteligente del control entre los componentes del
software.
El diseo debe ser modular, es decir, se debe hacer una particin lgica del Software en elementos que realicen funciones y
subfunciones especificas.
Un diseo debe contener abstracciones de datos y procedimientos.
Debe producir mdulos que presenten caractersticas de funcionamiento independiente.
Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los mdulos y el entorno exterior.
Debe producir un diseo usando un mtodo que pudiera repetirse segn la informacin obtenida durante el anlisis de
requisitos de Software.
Estos criterios no se consiguen por casualidad. El proceso de Diseo del Software exige buena calidad a travs de la
aplicacin de principios fundamentales de Diseo, Metodologa sistemtica y una revisin exhaustiva.
Cuando se va a disear un Sistema de Computadoras se debe tener presente que el proceso de un diseo incluye, concebir
y planear algo en la mente, as como hacer un dibujo o modelo o croquis.
Diseo de la Salida.
50

En este caso salida se refiere a los resultados e informaciones generadas por el Sistema, Para la mayora de los usuarios la
salida es la nica razn para el desarrollo de un Sistema y la base de evaluacin de su utilidad. Sin embargo cuando se
realiza un sistema, como analistas deben realizar lo siguiente:
Determine que informacin presentar. Decidir si la informacin ser presentada en forma visual, verbal o impresora y
seleccionar el medio de salida.
Disponga la presentacin de la informacin en un formato aceptable.
Decida como distribuir la salida entre los posibles destinatarios.
Diseo de Archivos.
Incluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si se fuera a emplear para guardar
detalles de las transacciones, datos histricos, o informacin de referencia. Entre las decisiones que se toman durante el
diseo de archivos, se encuentran las siguientes:
Los datos que deben incluirse en el formato de registros contenidos en el archivo.
La longitud de cada registro, con base en las caractersticas de los datos que contenga.
La secuencia a disposicin de los registros dentro del archivo (La estructura de almacenamiento que puede ser secuencial,
indexada o relativa).
No todos los sistemas requieren del diseo de todos los archivos, ya que la mayora de ellos pueden utilizar los del viejo
Sistema y solo tenga que enlazarse el nuevo Sistema al Archivo maestro donde se encuentran los registros.
Diseo de Interacciones con la Base de Datos.
La mayora de los sistemas de informacin ya sean implantado en sistemas de cmputos grandes o pequeos, utilizan una
base de datos que pueden abarcar varias aplicaciones, por esta razn estos sistemas utilizan u administrador de base de
datos, en este caso el diseador no construye la base de datos sino que consulta a su administrador para ponerse de
acuerdo en el uso de esta en el sistema.
Herramientas para el Diseo de Sistemas.
Apoyan el proceso de formular las caractersticas que el sistema debe tener para satisfacer los requerimientos detectados
durante las actividades del anlisis:
Herramientas de especificacin.
Apoyan el proceso de formular las caractersticas que debe tener una aplicacin, tales como entradas, Salidas,
procesamiento y especificaciones de control. Muchas incluyen herramientas para crear especificaciones de datos.
Herramientas para presentacin.
Se utilizan para describir la posicin de datos, mensajes y encabezados sobre las pantallas de las terminales, reportes y
otros medios de entrada y salida.
Herramientas para el desarrollo de Sistemas.
51
Estas herramientas nos ayudan como analistas a trasladar diseos en aplicaciones funcionales.
Herramientas para Ingeniera de Software.
Apoyan el Proceso de formular diseos de Software, incluyendo procedimientos y controles, as como la documentacin
correspondiente.
Generadores de cdigos.
Producen el cdigo fuente y las aplicaciones a partir de especificaciones funcionales bien articuladas.
Herramientas para pruebas.
Apoyan la fase de la evaluacin de un Sistema o de partes del mismo contra las especificaciones. Incluyen facilidades para
examinar la correcta operacin del Sistema as como el grado de perfeccin alcanzado en comparacin con las
expectativas.
La revolucin del procesamiento de datos de manera computarizada, junto con las prcticas de Diseo sofisticadas estn
cambiando de forma dramtica la manera en que se trasladan las especificaciones de Diseo de Sistemas de Informacin
funcionales.
En Conclusiones Generales. En una organizacin o Empresa, el anlisis y Diseo de Sistemas, es el proceso de estudiar
su Situacin con la finalidad de observar como trabaja y decidir si es necesario realizar una mejora; el encargado de llevar a
cabo estas tareas es el analista de sistemas.
Antes de comenzar con el desarrollo de cualquier proyecto, se conduce un estudio de Sistemas para detectar todos los
detalles de la situacin actual de la empresa. La informacin reunida con este estudio sirve como base para crear varias
estrategias de Diseo. Los administradores deciden que estrategias seguir. Los Gerentes, empleados y otros usuarios
finales que se familiarizan cada vez mas con el uso de computadoras estn teniendo un papel muy importante en el
desarrollo de sistemas.
Todas las organizaciones son Sistemas que actan de manera reciproca con su medio ambiente recibiendo entradas y
produciendo salidas. Los Sistemas que pueden estar formados por otros Sistemas de denominan Subsistemas y funcionan
para alcanzar los fines de su Implantacin.
52

DIFF - 1
Cmo se Inician los proyectos
Todas las solicitudes para el diseo de sistemas se originan debido a tres objetivos:
Resolver un problema. Actividades, procesos o funciones que no satisfacen los estndares de desempeo Ejemplo:
Disminuir el excesivo nmero de errores por la introduccin manual de datos.
Aprovechar una oportunidad. Es decir efectuar un cambio para ampliar, mejorar el rendimiento econmico de la empresa Ej.
Automatizar cierto tipo de actividades.
Dar respuesta a las directivas. Es decir proporcionar informacin en respuesta a ordenes y solicitudes. Ej. Promedio de
transacciones efectuadas en el ao.
Todas las empresas empiezan proyectos por una de cinco razones (conocidas como las cinco C) Capacidad, Control,
Comunicacin, Costo y Competitividad
Capacidad.
Las empresas estn caracterizadas por la capacidad de procesar transacciones con rapidez y eficiencia. Los sistemas de
informacin mejoran la capacidad a travs de la velocidad de procesamiento (las computadoras ayudan a eliminar la
necesidad de realizar clculos tediosos y comparaciones repetitivas, por ejemplo los cdigos de barras que ayudan a
capturar informacin sobre las ventas y recuperar de la memoria los precios de los productos), volumen creciente de las
transacciones (El constante crecimiento de las empresas hace que los procesos existentes resulten inadecuados para
satisfacer las demandas actuales, por lo que se considera un proceso computarizado si el proceso actual es manual y una
ampliacin si el proceso es computarizado) y recuperacin rpida de la informacin (Todas las organizaciones mantienen
grandes cantidades de informacin, el problema esta en donde almacenarla y como recuperarla eficientemente, ya que los
procesos manuales son largos y tediosos, un sistema computarizado asegura la capacidad para obtener con rapidez la
informacin).
Control
El control esta relacionado con el proceso de crear sistemas en 2 aspectos: Mejorar la exactitud y la consistencia
(Cualquier procedimiento que se realice en forma manual esta sujeto a errores de operacin humana por varios motivos
distraccin, cansancio, etc. por ejemplo la emisin de facturas. Un sistema computarizado permitir que cada paso se lleve
a cabo de la misma manera. Consistencia y exactitud.) y Aumentar la seguridad (El hecho de guardar todos los datos en
un solo lugar utilizando para ello una computadora, brindar la seguridad difcil de alcanzar sin la misma y los passwords
asociados).
Comunicacin
La falta de comunicacin es una dificultad comn que afecta a clientes y empleados. Los sistemas de informacin bien
desarrollados amplan la comunicacin y facilitan la integracin de funciones individuales (por ejemplo a travs de las redes
se puede acelerar el flujo de informacin a travs del correo electrnico).
53
Costo
Los sistemas de informacin juegan un papel muy importante en la vigilancia como en la reduccin de costos de operacin
Vigilancia (a travs del seguimiento de los costos de mano de obra, bienes y gastos generales para determinar si la
empresa opera en la forma esperada, de acuerdo con lo presupuestado a diferencia de los sistemas manuales que no son
tan eficientes) y reduccin de costos (porque toman las capacidades de calculo automtico y recuperacin de datos para
la produccin de informacin).
Competitividad
Los sistemas de informacin son un arma estratgica que puede cambiar la forma en la que se compite en el mercado,
porque mejoran la organizacin y ayudan a ganar una ventaja competitiva en 4 aspectos clientes, competidores,
proveedores y servicios o productos.
Clientes (son la parte ms importante de cualquier organizacin, siendo la meta o el objetivo conseguir nuevos clientes y
retener a los que tienen, ofreciendo mejores precios, proporcionando servicios exclusivos presentando productos
diferentes en base a la informacin que producen los sistemas de informacin). Competidores (intentando dejar fuera a los
competidores tomando la ventaja a travs de la informacin que se pueda producir por los sistemas de informacin),
Proveedores (Ofreciendo un mejor precio tanto a los proveedores como a los clientes), Productos (La informacin
generada por los sistemas de informacin sirven de base para el desarrollo de nuevos productos por ejemplo nuevos
servicios bancarios.
Fuentes de solicitudes de proyectos
Existen cuatro fuentes primarias de solicitudes de proyectos: Los jefes de departamento, los altos ejecutivos, los analistas
de sistemas y externas a la organizacin. De acuerdo al origen de las solicitudes los solicitantes buscan ya sea aplicaciones
totalmente nuevas o algunos cambios en las ya existentes.
Gerentes de departamento
El administrador de una clnica supervisa la preparacin de las formas de reclamo de los pacientes que se envan a las
compaas de seguros, que pagan los servicios mdicos, aunque el administrador sabe que es necesario preparar estos
formatos para que el cliente reciba la ayuda necesaria y la clnica el pago correspondiente esta preocupado por el tiempo
que los empleados toman en el llenado de estas solicitudes, debido a que se duplica la recopilacin de informacin que ya
se tienen almacenada, por lo cual solicitan al consejo directivo se apruebe un sistema basado en computadoras para
preparar los formatos y mantener actualizados los registros de pacientes (una actividad en curso necesita una mejora ya
sea para resolver la existencia de demasiados errores, costos excesivos de trabajo y aumentar de esta manera la eficiencia
del trabajo).
Altos Ejecutivos
Los altos ejecutivos como el presidente. Directores, vicepresidentes tienen informacin que no esta disponible a los
gerentes y por tanto sus solicitudes tienen un mbito mayor que las preparadas por otros departamentos. Por ejemplo una
solicitud de diseo e implementacin de un nuevo sistema presupuestal para toda la organizacin.
54
Analistas de Sistemas
Los analistas de sistemas buscan reas donde deben desarrollarse proyectos y escriben la propuesta o animan a un
gerente para que este elabore la propuesta. (por ejemplo un proceso de inscripcin lento, susceptible a error e ineficiente,
por lo cual decide proponer un nuevo sistema de inscripcin
Grupos Externos
Los acontecimientos externos a la organizacin tambin conducen a solicitudes de proyectos. Por ejemplo un nuevo
sistema implementado por la superintencia de bancos obliga a la organizacin a desarrollar nuevos sistemas.
55

DIFF 2
LA ENTREVISTA
Fuente: Centro de Investigacin y Asistencia Tcnica Barcelona.
Licenciada Silvia Royo Beberide
Definicin
La entrevista personal es una tcnica para obtener cierta informacin deseada, de un sujeto determinado de antemano, por
medio de una conversacin directa fijada en un cuestionario previo y preciso.
La entrevista, como tcnica de recopilacin, va desde la interrogacin estandarizada hasta la conversacin libre; en ambos
casos se recurre a una gua que puede ser un formulario o un bosquejo de cuestiones para orientar la conversacin.
La entrevista se emplea para medir opiniones. En el campo de la prevencin, la entrevista, junto con la observacin y el
cuestionario, es el mtodo psicosocial ms adecuado para cuantificar y medir en lo posible los problemas y conceptos que
se han seleccionado con anterioridad.
Tipos de entrevista
Podemos decir que hay dos tipos de entrevista:
Entrevista estructurada
Es un interrogatorio en el que las preguntas se plantean siempre en el mismo orden y se formulan en los mismos trminos.
El formulario est previamente preparado y estrictamente normalizado.
Entrevista no estructurada
La entrevista no estructurada deja mayor libertad a la iniciativa de la persona interrogada y del entrevistador, se trata, en
general, de preguntas abiertas respondidas dentro de una conversacin. Puede tener tres formas:
Entrevista localizada
El entrevistador dispone de una lista de cuestiones relativas al problema a investigar en torno a las cuales se localiza la
entrevista, sin una estructura formalizada. El entrevistador debe ser hbil para saber escuchar y ayudar a expresarse y
esclarecer, pero sin sugerir. La entrevista localizada se emplea para estudiar situaciones que han provocado cambios de
actitud en las personas sometidas a ellas.
Entrevista no dirigida: el entrevistador tiene completa libertad para expresar sus sentimientos y opiniones. El entrevistador
tiene que animarle a hablar de un determinado tema y orientarle, debe crear una atmsfera "facilitadora" en la que el sujeto
se halle en libertad para expresarse.
56
El entrevistador
Condiciones ideales
Fsicas: Buena salud. Apariencia agradable. Modales corteses. Facilidad de palabra.
Psicolgicas: Agilidad y flexibilidad mental. Facilidad para entrar en contacto con la gente. Buenas dotes de observador.
Sentido del detalle. Simpata. Buena memoria. Capacidad de sntesis.
Culturales: Nivel de instruccin por encima de la media. Conocimientos taquigrficos. Letra legible. Capacidad de hacer
resmenes objetivos e informes.
Morales: Honradez profesional. Sinceridad. Educacin. Constancia. Prudencia. Inters por la investigacin.
Seleccin
La seleccin de entrevistadores debe hacerse en base al fin de la investigacin. Un factor importante a tener en cuenta a la
hora de la seleccin ser la clase social y el medio econmico de los entrevistados, el origen geogrfico, el nivel cultural,
etc.
Tcnica y prctica de la entrevista

Hay 6 etapas:
Seleccin de los entrevistados

Muestra personal, por nombre y direccin.
Muestra de cuota, por caracteres personales (edad, sexo, profesin).
Muestra de rea, por zona geogrfica (barrio, manzana, piso).
Eleccin del momento
No interrumpir tareas urgentes.
El aviso previo hace perder espontaneidad.
57
Toma de contacto
Exponer la finalidad de la entrevista.
Resaltar la importancia de la opinin del entrevistado.
No utilizar la palabra investigacin, sino estudio, visin panormica, etc.
Destacar el carcter confidencial y annimo de las respuestas.
La entrevista propiamente dicha
Situar cmodamente al sujeto.
Ponerse a cubierto de indiscreciones y testigos.
Acercarse al sujeto: "recibirlo en casa".
Hacer las preguntas textualmente por orden.
Sealar el estado de nimo del entrevistado.
Si el interrogado se niega a responder a ms de cinco preguntas, terminar la entrevista, pero anularla,
sustituyndola por otra de las mismas condiciones.
Si el entrevistado solicita ver las anotaciones que hace el entrevistador, mostrrselas con toda naturalidad.
Evitar influir al entrevistado.
Preguntar directamente y sin vacilar.
No experimentar asombro ante ninguna respuesta.
Para conseguir la mxima espontaneidad hacer las preguntas con cierta rapidez, no dejando descanso
entre una y otra.
Usar el cuestionario de manera informal evitando que la entrevista parezca un interrogatorio.
Evitar todo lo que implique crtica, sorpresa, aprobacin o desaprobacin, tanto al formular las preguntas
como ante las respuestas.
Evitar al preguntar el tono de lectura, centrando la atencin en el entrevistado y no en el cuestionario.
Usar frases de transicin al cambiar de tema o de escenario.
Dejar constancia escrita de los cambios introducidos eventualmente en el cuestionario.
Hacer breves comentarios que ayuden a la comunicacin. Manifestar al entrevistado que su opinin es
muy interesante y necesaria, pero sin expresar crtica o aprobacin-desaprobacin de su opinin.
El silencio es el primero y mejor relanzamiento que podemos hacer.
Evitar las respuestas s, no, no s.
Ayudar y motivar a responder sin sugerir la respuesta.
Trmino de la entrevista
Cuando la investigacin requiera posteriores entrevistas, se ha de cortar el interrogatorio en el momento
oportuno, cuando el interrogado mantiene an deseos de seguir hablando, con lo que queda la puerta
abierta para la prxima sesin.
En todos los casos habr que terminar cada entrevista con un clima de cordialidad, despidindose con
palabras de agradecimiento.
Hay que desaparecer rpidamente, ya que el entrevistado puede desear rectificar sus opiniones.
Cmo registrar las respuestas
58

Es aconsejable prescindir de escribir durante la entrevista. Pero la anotacin posterior presenta dos
inconvenientes:
Los lmites de la memoria humana.
La distorsin por elementos subjetivos.
Para una mayor fidelidad en la recogida de datos es ms recomendable la anotacin directa, mejor an si
puede contarse con un magnetfono pidiendo consentimiento previo al interrogado.
Resumen de normas para la entrevista

Aborde gradualmente al entrevistado, creando una corriente de amistad, identificacin y cordialidad.
Ayude al interrogado para que se sienta seguro y locuaz.
Djele concluir su relato y aydele luego a completarlo contrastando fechas y hechos.
Procure formular las preguntas con frases fcilmente comprensibles, evite formulaciones embarazosas con carcter
personal o privado.
Acte con espontaneidad y franqueza, y no con astucias y rodeos.
Escuche al informante con tranquilidad, paciencia y comprensin, pero desplegando una crtica interna inteligente.
Evite la actitud de "personaje" y los alardes de autoridad.
No d consejos y no haga admoniciones morales. No rebata al informante.
Preste atencin no slo a aquello que l desea aclarar, sino tambin a lo que no quiere o no puede manifestar sin ayuda.
Evite toda discusin sobre las consecuencias de las respuestas.
No apremie al interrogado, concdale tiempo suficiente para que acabe su relato, y valorice sus contestaciones.
Ventajas de la entrevista
Puede ir ms all de la conducta y de los problemas sociales.
Puede llegar a los "verdaderos orgenes" de los hechos humanos.
Tiene flexibilidad para adaptarse a las personas y a las circunstancias, se pueden aclarar y repetir las preguntas.
Da la oportunidad de observar al entrevistado: reacciones, ambiente, etc.
Es fcil verificar la veracidad de las respuestas.
Obtiene fcil respuesta a cuestiones personales ntimas de las que es ms fcil hablar que escribir.
Da garanta de que la respuesta es individual; por escrito puede hacerse en grupo o sugerida por otra persona.
El nmero de no respuesta es menor.
Se pueden obtener respuestas espontneas.
Puede durar todo el tiempo necesario una vez que se oriente el tema.
Es una tcnica eficaz para obtener datos relevantes y significativos desde el punto de vista de las ciencias sociales.
Los datos obtenidos son susceptibles de cuantificacin y tratamiento estadstico.
El entrevistado no tiene que saber leer ni escribir.
Limitaciones e inconvenientes de la entrevista
Inherentes a la entrevista Limitaciones de la expresin verbal.
Falta de secreto de las respuestas.
59

Limitaciones del entrevistado Est dispuesto a proporcionar la informacin?
Comprende las preguntas?
Responde con sinceridad?
Se expresa adecuadamente?
Limitaciones del entrevistador Influencia del aspecto personal.
Influencia de las opiniones personales.
Limitaciones econmicas Exige ms tiempo: mayor costo.
Viajes y desplazamientos.
DIFF 3
EL CUESTIONARIO
Fuente: Centro de Investigacin y Asistencia Tcnica Barcelona.
Licenciada Silvia Royo Beberide
Definicin. El Cuestionario es el instrumento de la encuesta y es un instrumento de recogida de datos rigurosamente
estandarizado que operacionaliza las variables objeto de observacin e investigacin, por ello las preguntas de un
cuestionario son los indicadores.
Tipos de cuestionarios.
entrevista personal hacen uso de encuestadores
por correo envo por correo de un cuestionario, es + barata, pero tienen el inconveniente de un ndice de respuesta no
elevado, por lo que hay que hacer sucesivas oleadas, lo que puede hacer que nuestra muestra no sea representativa.
Cuestionarios telefnicos no controlamos a la persona que responde, son baratas.
Cuestionarios auto-adictos se realizan a una poblacin cautiva.
Tipos de preguntas:
Segn la contestacin que admitan:
abiertas (preguntas que slo formulan las pregunta, sin establecer categoras de respuesta) Se deben utilizar muy poco en
las encuestas porque despus de la encuesta hay que cerrarlas y luego estandarizarlas.
Cerradas: Dicotnicas (establecen slo 2 alternativas de respuesta, Si o No y a veces Ns/Nc).Se deben utilizar slo para
temas muy bien definidos que admiten estas 2 alternativas como respuesta.
Categorizadas (adems de la pregunta, establecen las categoras de respuesta) a su vez se subdividen en:
De respuesta espontnea. El encuestador no debe leerle la respuesta al encuestado.
De respuesta sugerida. El entrevistador lee las preguntas al encuestado.
De valoracin. El entrevistador lee una escala de intensidad creciente o decreciente de categoras de respuesta.
Segn su funcin en el cuestionario:
Filtro se utilizan mucho en los cuestionarios para eliminar aquellas personas que no les afecten determinadas preguntas, es
decir que marcan la realizacin o no de preguntas posteriores.
60

Batera todas las preguntas tratan sobre un mismo tema y que siempre deben ir juntas en el cuestionario en forma de
batera, empezando por las + sencillas y luego las + complejas. Esto se denomina embudo de preguntas.
De control se utilizan para comprobar la veracidad de las respuestas de los encuestados y normalmente lo que se hace en
estos casos es colocar la misma pregunta pero redactada de forma distinta en lugares separados una de la otra.
Amortiguadoras se refieren a que cuando estamos preguntando temas escabrosos o pensamos que sern reticentes a
contestar, hay que preguntar suavizando la pregunta y no preguntar de modo brusco y directo.
Segn su contenido:
Identificacin sitan las condiciones en la estructura social. Ej. Edad, sexo, profesin.
Accin tratan sobre las acciones de los entrevistados. Ej. Va al cine?fuma?.
Intencin indagan sobre la intenciones de los encuestados. Ej. Va a votar?
Opinin tratan sobre la opinin encuestados sobre determinados temas. Ej. Qu piensa sobre...?
Informacin analizan el grado de conocimiento de los encuestados sobre determinados temas.
Motivos tratan de saber el porqu de determinadas opiniones o actos.
Reglas para la formulacin de preguntas:

No deben ser excesivamente largo, porque en cuestionarios largos (+100 preguntas) disminuye el % de respuestas.
Tiene que ser sencillas y redactadas de tal forma que puedan comprenderse con facilidad (no utilizar trminos tcnicos).
No deben incorporar trminos morales (juicios de valor).
Nunca sugerir la respuesta, incitando a contestar ms en un sentido que en otra.
Todas deben referirse a 1 sla idea.
Todas las que estn dentro de un mismo tema deben ir juntas en el cuestionario en forma de batera.
No juntar preguntas cuya contestacin a 1 de ellas influya sobre la contestacin de la otra, denominado efecto halo.
Recomendaciones o Deformaciones al crear un cuestionario.
Deformacin conservadora las personas tienen ms tendencia a contestar si que a contestar no. Una pregunta
recibe + % de adhesiones cuando est formulada para contestar si que cuando est formulada para contestar no.
Influjo predisponente de ciertas palabras hay ciertas palabras con una gran carga ideolgica.
Evitar referencias a ciertas personalidades pblicas.
Organizacin y preparacin del cuestionario:
61
FASES
Formular hiptesis.
Establecer las variables intermedias (dimensiones que queramos analizar)
Operacionalizar las variables intermedias, dando lugar a las preguntas que seran los indicadores.
CONSTRUCCIN
Introduccin (quien nos encarg el estudio, el carcter annimo de las respuestas, etc.)
Preguntas:
Preguntas de identificacin (sexo, edad,...)
Preguntas sencillas para introducir las + complejas y terminar con sencillas.
Facilitar la transicin de un tema a otro en el cuestionario y se debe escribir en ste.
Evitar muchas preguntas abiertas.
Elaborar o decidir sobre los aspectos formales.
Preparar determinados elementos decisorios (carta de presentacin de los encuestadores)
Formar a los encuestadores y elaborar una gua de instrucciones para realizar el cuestionario.
Hacer un PRETEST (prueba del cuestionario antes de su lanzamiento definitivo) tiene por objeto ver si se entienden las
preguntas, si hay problemas en la redaccin,... y siempre tiene que hacerse. No interesan los resultados de este pretest.
150 personas son representativas de la prueba
Codificar el cuestionario
62

DIFF4
LA OBSERVACIN
Se utiliza para recolectar los datos necesarios para un estudio. La observacin es un mtodo clsico de investigacin
cientfica; adems, es la manera bsica por medio de la cual obtenemos informacin acerca del mundo que nos rodea.
Principios bsicos para realizar una observacin:
1. Debe tener un propsito especfico.
2. Debe ser planeada cuidadosa y sistemticamente.
3. Debe llevarse, por escrito, un control cuidadoso de la misma.
4. Debe especificarse su duracin y frecuencia.
5. Debe seguir los principios bsicos de confiabilidad y validez.
Entre las ventajas de la observacin, tenemos que determinada conducta se describe en el momento exacto en que est
ocurriendo.
Adems, las observaciones se pueden realizar independientemente de que las personas estn dispuestas a cooperar o no,
a diferencia de otros mtodos en los que s necesitamos de la cooperacin de las personas para obtener la informacin
deseada.
En contraposicin, tambin existen algunas desventajas, tales como la dificultad para observar un comportamiento
especfico en el momento de efectuar la observacin. Adems, las conductas que se encuentran sujetas a observacin,
generalmente son limitadas. es difcil poder observar la interaccin familiar, por ejemplo, al acostarse o levantarse.
La observacin, debido a su utilidad, es un mtodo que se puede utilizar, junto con otros, para recabar informacin. Por
ejemplo, se puede emplear la observacin en un estudio exploratorio, y para el estudio final se pueden usar otros mtodos
tales como cuestionarios, entrevistas, etc.
Observacin participante:
Este tipo de observacin est determinado por el hecho de que el observador participa de manera activa dentro del grupo
que se est estudiando; se identifica con l de tal manera que el grupo lo considera uno ms de sus miembros. es decir, el
observador tiene una participacin tanto externa, en cuanto a actividades, como interna, en cuanto a sentimientos e
inquietudes.
Con este tipo de observacin, los investigadores pueden influir en la vida del grupo.
Un problema del registro de la observacin es que el observador puede perder su objetividad. Para resolver este problema
es conveniente que ms de una persona observe el mismo fenmeno, con el fin de comparar las observaciones realizadas.
Observacin no participante:
En este tipo de observacin el investigador no participa de manera activa dentro del grupo que observa. Se limita a mirar y a
tomar notas sin relacionarse con los miembros del grupo.
Dependiendo de los objetivos que persiga la investigacin, se emplear uno u otro tipo de observacin.
La observacin participante nos puede dar una idea ms clara acerca de lo que sucede dentro de un grupo, puesto que si
los sujetos ven al observador como un miembro ms del grupo se comportarn normalmente. En cambio, aplicando la
observacin no participante, probablemente no se comportarn normalmente. Por otro lado, es probable que el investigador,
al no participar en la vida del grupo observado, pueda mantener ms facilmente su objetividad.
Observacin libre o no estructurada:
Generalmente se lleva a cabo en un estudio piloto, cuando no se conoce muy bien la muestra que se va a estudiar.
Puntos a considerar:
La poblacin que vamos a estudiar: quines son, cmo se relacionan entre s, edad, sexo, nivel socioeconmico,
etc.
Las variables que son relevantes para nuestro estudio, as como la frecuencia y duracin de las mismas.
La mejor manera de registrar esta informacin es hacindolo en el momento y situacin en que se est manifestando la
conducta, puesto que as tendremos menos prejuicios, seremos menos selectivos y, en genral, ms objetivos al registrar la
informacin tal y como se presenta en la realidad. Sin embargo, esto no siempre se puede realizar, puesto que al estar
tomando notas se puede distorsionar la conducta; adems, las personas pueden comportarse de manera poco diferente
63

cuando saben que las estn observando, y sobre todo si alguien est tomando notas en relacin con su comportamiento.
Por otro lado, es difcil tomar notas y observar al mismo tiempo.
Si se trata de guardar todo en la memoria, probablemente la observacin no pueda ser muy exacta. Lo que se puede hacer
es escribir solamente palabras claves mientras se realiza la observacin. Cuando se redacten los resultados finales, se
debe utilizar una forma organizada y sistemtica, como, por ejemplo, una tabla de frecuencias.
Observacin estructurada:
Es aquella que se lleva a cabo cuando se pretende probar una hiptesis, o cuando se quiere hacer una descripcin
sistemtica de algn fenmeno. es decir, cuando estamos realizando un estudio o investigacin en el que sabemos
exactamente lo que vamos a investigar y tenemos un diseo de investigacin. Se diferencia de la observacin no
estructurada en el sentido de que en esta ltima slo poseemos una idea vaga acerca de lo que vamos a observar, mientras
que en la estructurada ya tenemos ms claramente definidos los objetivos que nos ayudarn a clasificar y concretar el
fenmeno en cuestin. En este tipo de observacin nos basamos en tablas de frecuencias.
La observacin estructurada presenta menos problemas prcticos en cuanto a la forma de registro y utilizamos formas
estandarizadas. Existen menos probabilidades de que los observadores sean subjetivos
Fuente: http://server2.southlink.com.ar/vap/OBSERVACION.htm
64

DIFF5
MTODO Y METODOLOGA
La ciencia es un tipo particular y especfico de conocimiento. Para lograr un conocimiento de tal naturaleza, o sea, para
hacer ciencia, es preciso seguir determinados procedimientos que nos permitan alcanzar el fin que procuramos: no es
posible obtener un conocimiento racional, sistemtico y organizado actuando de cualquier modo; es necesario seguir un
mtodo, un camino que nos aproxime a esas determinada meta.
El mtodo cientfico es el procedimiento o conjunto de procedimientos que se utilizan para obtener conocimientos
cientficos, el modelo de trabajo o pauta general que orienta la investigacin. El estudio del mtodo - o de los mtodos, si se
quiere dar al concepto un alcance ms general - se denomina metodologa, y abarca la justificacin y la discusin de su
lgica interior, el anlisis de los diversos procedimientos concretos que se emplean en las investigaciones y la discusin
acerca de sus caractersticas, cualidades y debilidades. Sin embargo, se suele utilizar la palabra metodologa en sentidos
diferentes, opuestos a veces al anterior: se habla as de "metodologa de la investigacin" para hacer referencia a los pasos
y procedimientos que se han seguido en una indagacin determinada, para designar los modelos concretos de trabajo que
se aplican en una determinada disciplina o especialidad y tambin para hacer referencia al conjunto de procedimientos y
recomendaciones que se transmiten al estudiante como parte de la docencia en estudios superiores. Tambin suelen
designarse como mtodos los estilos de trabajo peculiares de cada disciplina (por ejemplo: "el mtodo antropolgico") y las
formas particulares de investigacin que se utilizan para resolver problemas especficos de indagacin, como cuando se
habla del "mtodo cualitativo", el "mtodo experimental" o el "mtodo estadstico".
El mtodo se refiere directamente a la lgica interior del proceso de descubrimiento cientfico, y a l le corresponde no
solamente orientar la seleccin de los instrumentos y tcnicas especficos de cada estudio, sino tambin,
fundamentalmente, fijar los criterios de verificacin y demostracin de lo que se afirme en la investigacin.
No existe un nico mtodo de la ciencia, ya que no investigan del mismo modo el astrnomo y el economista, el historiador
y el qumico, el antroplogo y el bioqumico. La experiencia histrica muestra, adems, que los procedimientos de la ciencia
cambian, porque son distintos los problemas que se van planteando y los instrumentos evolucionan.
La investigacin es un proceso creativo, plago de dificultades imprevistas, de prejuicios invisibles y de obstculos de todo
tipo. Por ello, la nica manera de abordar el problema del mtodo cientfico, en un sentido general, es buscar las
orientaciones epistemolgicas - los criterios comunes - que guan los trabajos de investigacin.
Uno de los elementos ms significativos en todo el pensar cientfico es el esfuerzo por la claridad en la conceptualizacin.
Adems, el mtodo de la ciencia se asienta en dos pilares fundamentales: en un constante tomar en cuenta la experiencia,
los datos de la realidad, y en una preocupacin por construir modelos tericos, abstracciones generales capaces de
expresar las conexiones entre los datos conocidos.
Toda investigacin parte de un conjunto de ideas y proposiciones que versan sobre la realidad y sus descripciones y
explicaciones; el cientfico, por ms que est persuadido de la verdad de estas proposiciones, no las podr sostener hasta
que, de algn modo, puedan ser verificadas en la prctica. Una proposicin es verificable cuando es posible encontrar un
conjunto de hechos, previamente delimitados, que sean capaces de determinar si es o no verdadera.
Otro elemento del proceder cientfico es el uso sistemtico de la inferencia, o razonamiento deductivo. Inferir significa sacar
consecuencias de un principio o supuesto. La inferencia opera durante la investigacin y, por lo general, de la siguiente
manera: una vez formulada una hiptesis se deducen de ella posibles consecuencias prcticas, que luego son sometidas, a
su vez, a verificacin.
BIBLIOGRAFA: CARLOS A. SABINO. El proceso de investigacin. Buenos Aires, Editorial Lumen - Humanitas, 1996
Fuente: http://server2.southlink.com.ar/vap/metodo%20y%20metodologia.htm
65

Analisis de Sistemas I

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Analisis de Sistemas I

Hochgeladen von

Copyright:

Verfügbare Formate

FACULTAD DE CIENCIA Y TECNOLOGA

RED NACIONAL UNIVERSITARIA

FACULTAD DE CIENCIA Y TECNOLOGA

FACULTAD DE CIENCIA Y TECNOLOGA

OBJETIVOS GENERALES DE LA ASIGNATURA.

II. PROGRAMA ANALTICO DE LA ASIGNATURA.

FACULTAD DE CIENCIA Y TECNOLOGA

Importancia de las herramientas para el desarrollo

Senn James Anlisis de Sistemas de Informacin (McGraw Hill, 1999).

IV. CONTROL DE EVALUACIONES

FACULTAD DE CIENCIA Y TECNOLOGA

FACULTAD DE CIENCIA Y TECNOLOGA

PROGRAMA DE CONTROL DE CALIDAD

TITULO WORK PAPER: Teora General de Sistemas

FACULTAD DE CIENCIA Y TECNOLOGA

TEORIA GENERAL DE SISTEMAS

FACULTAD DE CIENCIA Y TECNOLOGA

1.3.3. Componentes de los sistemas

FACULTAD DE CIENCIA Y TECNOLOGA

1.3.3.1 Medio Ambiente

FACULTAD DE CIENCIA Y TECNOLOGA

De acuerdo a su origen se clasifican en naturales o artificiales

FACULTAD DE CIENCIA Y TECNOLOGA

Sistemas suaves son aquellos que toman en cuenta el aspecto humano.

Caractersticas de los Sistemas

FACULTAD DE CIENCIA Y TECNOLOGA

FACULTAD DE CIENCIA Y TECNOLOGA

PROGRAMA DE CONTROL DE CALIDAD

TITULO WORK PAPER: Los Sistemas de Informacin

FACULTAD DE CIENCIA Y TECNOLOGA

FACULTAD DE CIENCIA Y TECNOLOGA

2.4 Clasificacin de los Sistemas de Informacin

FACULTAD DE CIENCIA Y TECNOLOGA

Senn, J. "Anlisis y Diseo de Sistemas de Informacin. 1999.

FACULTAD DE CIENCIA Y TECNOLOGA

PROGRAMA DE CONTROL DE CALIDAD

TITULO WORK PAPER: Desarrollo de Sistemas de Informacin

FACULTAD DE CIENCIA Y TECNOLOGA

No es suficiente querer, se debe tambin hacer.

3.1 Qu es el Desarrollo de Sistemas?

3.2 Estrategias para el Desarrollo de Sistemas.

FACULTAD DE CIENCIA Y TECNOLOGA

FACULTAD DE CIENCIA Y TECNOLOGA

FACULTAD DE CIENCIA Y TECNOLOGA

3.2.2.1.1 Diagrama de flujo de datos.

FACULTAD DE CIENCIA Y TECNOLOGA

3.2.3 Mtodo del Prototipo de Sistemas

Senn, J. "Anlisis y Diseo de Sistemas de Informacin. 1999.

2. Kendall & Kendall. Anlisis y Diseo de Sistemas. 1997.

FACULTAD DE CIENCIA Y TECNOLOGA

PROGRAMA DE CONTROL DE CALIDAD

TITULO WORK PAPER: Mtrica 3

FACULTAD DE CIENCIA Y TECNOLOGA

FACULTAD DE CIENCIA Y TECNOLOGA

estudio de viabilidad del sistema (evs).

FACULTAD DE CIENCIA Y TECNOLOGA

Desarrollo de Sistemas de Informacin

ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS).

FACULTAD DE CIENCIA Y TECNOLOGA

FACULTAD DE CIENCIA Y TECNOLOGA

Anlisis del Sistema de Informacin (ASI)

FACULTAD DE CIENCIA Y TECNOLOGA

Plan de migracin y carga inicial de datos.