informacion

1. Alternativas de adquisición de
sistemas de información
Unidad 4

2. Identificación
de problemas,
oportunidades
y objetivos
Determinación de
los requerimientos
de la información
Prueba y
mantenimiento
de sistemas
Ciclos de la vida
del desarrollo de
sistemas
Desarrollo y
documentación
de software
Diseño del
sistemas
recomendado
Análisis de las
necesidades
del sistema

3. Identificación de problemas,
oportunidades y objetivos.
• En la primera fase del ciclo de vida del desarrollo de sistemas el analista
tiene que ver con la identificación de problemas, oportunidades y objetivos.
Esta etapa es crítica para el éxito del resto de proyecto, debido a que nadie
quiere desperdiciar el tiempo subsecuente resolviendo el problema
equivocado. La primera fase requiere que el analista observe honestamente
lo que está sucediendo en un negocio. Luego, junto con los demás miembros
de la organización, el analista hace resaltar los problemas. Frecuentemente
estos ya han sido vistos por los demás, y son la razón por la cual el analista
fue llamado inicialmente. Las personas involucradas en la primera fase son
los usuarios, analistas y administradores de sistemas que coordinan el
proyecto. Las actividades de esta fase consisten en entrevistas a los
administradores de los usuarios, sumarización del conocimiento obtenido,
estimación del alcance del proyecto y documentación de los resultados. La
salida de esta fase es un estudio de factibilidad que contiene una definición
del problema y la sumarización de los objetivos. Luego los administradores
deben tomar una decisión para ver si continúan con el proyecto propuesto.

4. Determinación de los
requerimientos de
información.
• Entre las herramientas utilizadas para definir los
requerimientos de información en el negocio se
encuentran: muestreo e investigación de los datos
relevantes, entrevistas, cuestionarios, el
comportamiento de los tomadores de decisiones y
su ambiente de oficina y hasta la elaboración de
prototipos. En esta fase el analista está
esforzándose por comprender qué información
necesitan los usuarios para realizar su trabajo. Las
personas involucradas en esta fase son los
analistas y los usuarios, típica mente los
administradores de las operaciones y los
trabajadores de las operaciones.

5. Análisis de las necesidades del
sistema.
• La siguiente fase que realiza el analista de sistemas involucro el
análisis de las necesidades del sistema. Nuevamente, herramientas y
técnicas especiales ayudan para que el analista haga las
determinaciones de los requerimientos. Una herramienta de éstas es
el uso de diagramas de flujo de datos para diagramar la entrada,
proceso y salida de las funciones del negocio en forma gráfica
estructurado. A partir de los diagramas de flujo de datos se
desarrolla un diccionario de datos, que lista todos los conceptos de
datos usados en el sistema, así como sus especificaciones, si son
alfanuméricos y qué tanto espacio ocupan cuando se imprimen.
Durante esta fase el analista de sistemas también analiza las
decisiones estructuradas que se hacen. Las decisiones estructuradas
son aquellas para las que pueden ser determinadas las condiciones
como alternativas de condición, acciones y reglas de acción. Hay tres
métodos principales para el análisis de decisiones estructurales:
lenguaje estructurado, tablas de decisión y árboles de decisión.

6. Diseño del sistema
recomendado.
• En esta fase del ciclo de vida del desarrollo de
sistemas, el analista usa la información
recolectada anteriormente para realizar el
diseño lógico del sistema de información. El
analista diseña procedimientos precisos para
la captura de datos, a fin de que los datos que
van a entrar al sistema de información sean
correctos. Además, el analista también
proporciona entrada efectiva para el sistema
de información mediante el uso de técnicas
para el buen diseño de formas y pantallas.

7. Desarrollo y documentación del
software.
• En la quinta fase del ciclo de vida del
desarrollo de sistemas el analista trabaja con
los programadores para desarrollar cualquier
software original que se necesite. Durante
esta fase, el analista también trabaja con los
usuarios para desarrollar documentación
efectiva para el software, incluyendo
manuales de procedimientos. La
documentación le dice al usuario la manera
de usar el software y también qué hacer si se
suceden problemas con el software.

8. Pruebas y mantenimiento del
sistema.
• Antes de que pueda ser usado, el sistema de
información debe ser probado. Es mucho menos
costoso encontrar problemas antes de que el
sistema sea entregado a los usuarios. Algunas de
las pruebas son realizadas por los programadores
solos, y otras por los analistas de sistemas junto
con los programadores. Primero se ejecuta una
serie de pruebas para que destaquen los problemas
con datos de ejemplo y eventualmente con datos
reales del sistema actual. El mantenimiento del
sistema y de su documentación comienza en esta
fase y es efectuado rutinariamente a lo largo de la
vida del sistema de información.

9. 4.2 PROTOTIPOS
• PROTOTIPOS INFORMÁTICOS

10. El desarrollo orientado a prototipos
• Definición de un prototipo en software: “…es un
modelo del comportamiento del sistema que puede ser
usado para entenderlo completamente o ciertos
aspectos de él y así clarificar los requerimientos… Un
prototipo es una representación de un sistema, aunque
no es un sistema completo, posee las características
del sistema final o parte de ellas”
Modelo o maqueta del sistema que se construye para
comprender mejor el problema y sus posibles soluciones:
• Evaluar mejor los requisitos.
• Probar opciones de diseño.

11. Características de los prototipos
• Funcionalidad limitada.
• Poca fiabilidad.
• Características de funcionalidad pobres.
• Alto grado de participación del usuario el cual evalúa
los prototipos, propone mejoras y detalla requisitos.
• Alto grado de participación del analista de sistemas, ya
que en muchos casos los usuarios no pueden indicar
los requisitos sin tener experiencia con el sistema.
• El prototipo da mayor conocimiento al usuario y
analistas ayudando a que el usuario aprenda a utilizar
el sistema

12. Uso de prototipo
• Se presenta al cliente un prototipo para su
experimentación.
• Ayuda al cliente a establecer claramente los
requisitos.
• Ayuda a los desarrolladores a:
• Validar corrección de la especificación.
• Aprender sobre problemas que se presentarán
durante el diseño e implementación del sistema.
• Mejorar el producto.
• Examinar viabilidad y utilidad de la aplicación.

13. Tipos de prototipos.
• Prototipado de interfaz de usuario:
modelos de pantallas.
• Prototipado funcional (operacional):
implementa algunas funciones, y a medida
que se comprueba que son las apropiadas,
se corrigen, refinan, y se añaden otras.
• Modelos de rendimiento: evalúan el
rendimiento de una aplicación crítica (no
sirven al análisis de requisitos).

14. Rápido o desechable:
• Sirve al análisis y validación de los
requisitos.
• Después se redacta la especificación del
sistema y se desecha el prototipo.
• La aplicación se desarrolla siguiendo un
paradigma diferente.
• Problema: cuando el prototipo no se
desecha, y termina convirtiéndose en el
sistema final.

15. Evolutivos:
• Comienza con un sistema relativamente
simple que implementa los requisitos más
importantes o mejor conocidos.
• El prototipo se aumenta o cambia en cuanto
se descubren nuevos requisitos.
• Finalmente, se convierte en el sistema
requerido.
• Actualmente se usa en el desarrollo de sitios
Webs y en aplicaciones de comercio
electrónico.

16. Vertical
• Desarrolla completamente alguna de las
funciones.
Horizontal
• Desarrolla parcialmente todas las
funciones.

17. Herramientas de prototipado.
• Lenguajes dinámicos de alto nivel.
• Lenguajes de cuarta generación (4GLs) (programación de BBDD).
• Ensamblaje de componentes y aplicaciones.
Lenguajes Dinámicos de alto nivel.
Muy usados:
• Smalltalk (basado en objetos, sistemas interactivos)
• Java (basado en objetos, sistemas interactivos)
• Prolog (lógico, procesamiento simbólico)
• LISP (basado en listas, procesamiento simbólico)
Elección del lenguaje:
• ¿Cuál es el dominio de aplicación?
• ¿Cuál es la interacción de usuario requerida?
• (Java, Smalltalk se integran bien con las interfaces Web.)
• ¿Cuál es el entorno proporcionado para el lenguaje?

18. Lenguajes de 4ª Generación.
• La mayoría de aplicaciones de gestión son interactivas e implican la
manipulación de una BD y la producción de salidas que involucran
organizar y dar formato a esos datos.
• 4GL: lenguaje de programación de BBDD (y su entorno de
desarrollo), que contiene conocimiento de la BD y operaciones para
manipulación de la misma.
• 4GL: lenguaje no Procedimental.
• Reducen claramente los costos del desarrollo.
• Muy usados en prototipado evolutivo.
• Muchos 4GLs permiten el desarrollo de interfaces de
• BBDD basadas en navegadores Web.
• Generan SQL.
• Menos eficientes que los lenguajes de programación convencionales.
• Reducen claramente los costos del desarrollo.

19. GENERADOR
DE
INTERFACES
LENGUAJE DE
PROGRAMACI
ON
HOJA DE
CALCULO
GENERADOR
DE INFORMES
SISTEMA DE
ADMINISTRAC
ION DE BBDD

20. Ensamblaje de componentes y aplicaciones.
El desarrollo de prototipos con reutilización comprende dos niveles:
El nivel de aplicación, en el que una aplicación completa se integra con el
prototipo
• P.ej., si el prototipo requiere procesamiento de textos, se puede integrar un
sistema estándar de procesamiento de textos (MS Office).
B. El nivel de componente, en el que los componentes se integran en un marco
de trabajo estándar.
• Visual Basic, TCL/TK, Python, Perl…
- Lenguajes de alto nivel sin tipos, con kits de herramientas gráficas.
- Desarrollo rápido de aplicaciones pequeñas y relativamente sencillas,
construidas por una persona o conjunto de personas.
- No existe una arquitectura explícita del sistema.
• CORBA, DCOM, JavaBeans
- Junto con un marco arquitectónico, es más apropiado para sistemas
grandes.

21. Prototipos de Interface de
Usuario.
Las descripciones textuales y los diagramas
no son suficientemente buenos para
expresar los requisitos de la interfaz.
La construcción de prototipos evolutivos con
la participación del usuario final es la
forma más sensata de desarrollar una
interfaz.
Los usuarios deben estar implicados en la
evaluación y evolución del prototipo.

22. Herramientas:
• Generadores de interfaz (4GLs, Visual Basic, etc.).
• Editores de páginas Web.
• Herramientas CASE.
- Formularios, pantallas, generación de código…
• Bocetos en papel.
• Aplicaciones de dibujo
- Harward Graphics, etc.
• MS PowerPoint.
• Etc.
FASES
Las fases que comprende el método de desarrollo orientado a prototipos serían:
• Investigación preliminar. Las metas principales de esta fase son: determinar el
problema y su ámbito, la importancia y sus efectos potenciales sobre la organización por
una parte y, por otro lado, identificar una idea general de la solución para realizar un
estudio de factibilidad que determine la factibilidad de una solución software.
• Definición de los requerimientos del sistema. El objetivo de esta etapa es registrar
todos los requerimientos y deseos que los usuarios tienen en relación al proyecto bajo
desarrollo. Esta etapa es la más importante de todo el ciclo de vida, es aquí donde el
desarrollador determina los requisitos mediante la construcción, demostración y
retroalimentaciones del prototipo. Por lo mismo esta etapa será revisada con más detalle
luego de esta descripción.

23. • Diseño técnico. Durante la construcción del prototipo, el desarrollador ha obviado el
diseño detallado. El sistema debe ser entonces rediseñado y documentado según los
estándares de la organización y para ayudar a las mantenciones futuras. Esta fase de diseño
técnico tiene dos etapas: por un lado, la producción de una documentación de diseño que
especifica y describe la estructura del software, el control de flujo, las interfaces de usuario y
las funciones y, como segunda etapa, la producción de todo lo requerido para promover
cualquier mantención futura del software.
• Programación y prueba. Es donde los cambios identificados en el diseño técnico son
implementados y probados para asegurar la corrección y completitud de los mismos con
respecto a los requerimientos.
• Operación y mantención. La instalación del sistema en ambiente de explotación, en
este caso, resulta de menor complejidad, ya que se supone que los usuarios han trabajado
con el sistema al hacer las pruebas de prototipos. Además, la mantención también debería
ser una fase menos importante, ya que se supone que el refinamiento del prototipo
permitiría una mejor claridad en los requerimientos, por lo cual las mantenciones
perfectivas se reducirían. Si eventualmente se requiriese una mantención entonces el
proceso de prototipado es repetido y se definirá un nuevo conjunto de requerimientos.
• La fase más importante corresponde a la definición de requerimientos, la cual
correspondería a un proceso que busca aproximar las visiones del usuario y del
desarrollador mediante sucesivas iteraciones. La definición de requerimientos consiste de
cinco etapas entre dos de las cuales se establece un ciclo iterativo:
• Análisis grueso y especificación. El propósito de esta subfase es desarrollar un diseño
básico para el prototipo inicial.
• Diseño y construcción. El objetivo de esta subfase es obtener un prototipo inicial. El
desarrollador debe concentrarse en construir un sistema con la máxima funcionalidad,
poniendo énfasis en la interface del usuario.

24. • Evaluación. Esta etapa tiene dos propósitos: extraer a los usuarios la
especificación de los requerimientos adicionales del sistema y verificar que
el prototipo desarrollado lo haya sido en concordancia con la definición de
requerimientos del sistema. Si los usuarios identifican fallas en el prototipo,
entonces el desarrollador simplemente corrige el prototipo antes de la
siguiente evaluación. El prototipo es repetidamente modificado y evaluado
hasta que todos los requerimientos del sistema han sido satisfechos. El
proceso de evaluación puede ser dividido en cuatro pasos separados:
preparación, demostración, uso del prototipo y discusión de comentarios.
En esta fase se decide si el prototipo es aceptado o modificado.
• Modificación. Esto ocurre cuando la definición de requerimientos del
sistema es alterada en la sub−fase de evaluación. El desarrollador entonces
debe modificar el prototipo de acuerdo a los comentarios hechos por los
usuarios.
• Término. Una vez que se ha desarrollado un prototipo estable y completo,
es necesario ponerse de acuerdo en relación a aspectos de calidad y de
representación del sistema.
• En la siguiente figura se puede ver un esquema en que estas etapas se
realizan, note que la especificación de requerimientos está claramente
diferenciada de las demás. Es en ella donde se utiliza el prototipado, ya que
permite entregar al usuario lo que sería una visión la solución final en
etapas tempranas del desarrollo, reduciendo tempranamente los costos de
especificaciones erróneas.

25. ANALISIS Y
ESPECIFICACION
DISEñO Y
CONSTRUCCION
EVALUACION
MODIFICACION
DISEñO TECNICO
PROGRANAS Y
PRUEBAS
OPERACION Y
MANTENCION
INVESTIGACION
PRELIMINAR

26. Las ventajas de un enfoque de desarrollo
orientado a prototipos están dadas por:
• Reducción de la incertidumbre y del riesgo
• Reducción de tiempo y de costos, incrementos en la aceptación del nuevo sistema,
• Mejoras en la administración de proyectos
• Mejoras en la comunicación entre desarrolladores y clientes, etc.
Si bien, el desarrollo orientado a prototipos tiene considerables ventajas, también
presenta desventajas como:
• La dependencia de las herramientas de software para el éxito ya que la necesidad de
disminución de incertidumbre depende de las iteraciones del prototipo, entre más
iteraciones exista mejor y esto último se logra mediante el uso de mejores herramientas lo
que hace a este proceso dependiente de las mismas.
• También, no es posible aplicar la metodología a todos los proyectos de software y,
finalmente, la mala interpretación que pueden hacer los usuarios del prototipo, al cual
pueden confundir con el sistema terminado.
• No se puede desconocer que la fase de definición de requerimientos se ha perfeccionado en
dos aspectos importantes: primero se ha aproximado las visiones del usuario y el
desarrollador, lo cual representa el beneficio de establecer una base común de
comunicación; también, el hacer explícita la posibilidad de iterar sobre estos dominios
permitiría que la convergencia de los mismos sea una posibilidad cierta.

27. Un escenario para la construcción
de prototipos
• Todos los proyectos de ingeniería de software comienzan con una petición del cliente. La petición
puede estar en la forma de una memoria que describe un problema, un informe que define un
conjunto de objetivos comerciales o del producto, una petición de propuesta formal de una
agencia o compañía exterior, o una especificación del sistema que ha asignado una función y
comportamiento al software, como un elemento de un sistema mayor basado en computadora.
Suponiendo que existe una petición para un programa de una de las formas dichas
anteriormente, para construir un prototipo del software se aplican los siguientes pasos:
• PASO 1. Evaluar la petición del software y determinar si el programa a desarrollar es un buen
candidato para construir un prototipo. Debido a que el cliente debe interaccionar con el
prototipo en los últimos pasos, es esencial que:
• 1) el cliente participe en la evaluación y refinamiento del prototipo, y
• 2) el cliente sea capaz de tomar decisiones de requerimientos de una forma oportuna.
Finalmente, la naturaleza del proyecto de desarrollo tendrá una fuerte influencia en la eficacia
del prototipo.
• PASO 2. Dado un proyecto candidato aceptable, el analista desarrolla una representación
abreviada de los requerimientos. Antes de que pueda comenzar la construcción de un prototipo,
el analista debe representar los dominios funcionales y de información del programa y
desarrollar un método razonable de partición. La aplicación de estos principios de análisis
fundamentales, pueden realizarse mediante los métodos de análisis de requerimientos.
• PASO 3. Después de que se haya revisado la representación de los requerimientos, se crea un
conjunto de especificaciones de diseño abreviadas para el prototipo. El diseño debe ocurrir antes
de que comience la construcción del prototipo. Sin embargo, el diseño de un prototipo se enfoca
normalmente hacia la arquitectura a nivel superior y a los aspectos de diseño de datos, en vez de
hacia el diseño procedimental detallado.

28. • PASO 4. El software del prototipo se crea, prueba y refina Idealmente, los bloques de construcción de software
preexisten se utilizan para crear el prototipo de una forma rápida. Desafortunadamente, tales bloques
construidos raramente existen. Incluso si la implementación de un prototipo que funcione es impracticable, es
escenario de construcción de prototipos puede aun aplicarse. Para las aplicaciones interactivas con el hombre,
es posible frecuentemente crear un prototipo en papel que describa la interacción hombre-maquina usando una
serie de hojas de historia.
• PASO 5. Una vez que el prototipo ha sido probado, se presenta al cliente, el cual “conduce la prueba” de la
aplicación y sugiere modificaciones. Este paso es el núcleo del método de construcción de prototipo. Es aquí
donde el cliente puede examinar una representación implementada de los requerimientos del programa, sugerir
modificaciones que harán al programa cumplir mejor las necesidades reales.
• PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos estén formalizados o hasta
que el prototipo haya evolucionado hacia un sistema de producción. El paradigma de construcción del prototipo
puede ser conducido con uno o dos objetivos en mente:
1) El propósito del prototipado es establecer un conjunto de requerimientos formales que pueden luego ser
traducidos en la producción de programas mediante el uso de métodos y técnicas de ingeniería de
programación, o
2) El propósito de la construcción del prototipo es suministrar un continuo que pueda conducir al desarrollo
evolutivo de la producción del software. Ambos métodos tienen sus meritos y amos crean problemas.
Para poder realizar el prototipado debemos aplicar una técnica de captura de requerimientos que es una
herramienta que ayuda al proceso de abstracción de las características de un sistema. La captura de
requerimientos se hace a través de un proceso específicamente mental, el cual es el analista quien tiene la
capacidad para discernir sobre los detalles que interesan en realidad al sistema, valiéndose generalmente de
experiencias pasadas.
La identificación de actores y use case en un sistema se hace para:
• Delimitar el sistema de su ambiente externo.
• De qué y quién actuará con el sistema y que funcionalidad es la que se espera de él.
• Capturar y definir un glosario de términos.
• Además es necesario que nosotros como analistas utilicemos una herramienta propia para realizar cada uno de
los pasos antes mencionados.

29. Modelo sistémico para la elaboración del prototipo
informático de evaluación de la calidad en
educación superior
• El modelo sistémico, se basa en las fórmulas
más convencionales de la teoría de sistemas,
considerando entradas, transferencias y
salidas.
• Será el utilizado para el prototipo informático
propuesto, ya que ofrece todas las bondades
de la metodología de sistemas.
• En el modelo de evaluación propuesto para el
prototipo de evaluación de la calidad
universitaria, se perfilan tres bloques, como
lo muestra la gráfica siguiente:

30. ENTRADA O
INSUMOS
SALIDA O
PRODUCTOS
PROCESOS
• ESTUDIANTES
• PROFESOR
• LABORATORIO
• BIBLIOTECA
• ACADEMICOS
• INVESTIGACION
• EXTENCION
• ADMINISTRATIV
OS
• EGRESADOS
• PATENTES
• ASESORIA
• SERVICIOS

31. • Entrada: estaría constituida por las inversiones, tanto en recursos materiales como
humanos. En otras palabras: salas, talleres, bibliotecas, laboratorios con todos sus
implementos; además de estudiantes, profesores y personal administrativo.
• Procesos: estarían compuestos justamente por todas las interacciones que tienen
lugar en la institución y que permiten que ésta pueda cumplir los compromisos
adquiridos con la sociedad, en cuanto a conocimiento creados, profesionales
formados y servicios entregados a la comunidad. Esto incluye todos los
procedimientos de administración universitaria y gestión financiera de la
organización.
• Salida o productos: corresponde a los logros organizacionales en docencia,
investigación y extensión. Serían aspectos del resultado, la cantidad de graduados por
cohorte, los proyectos de investigación realizados, las publicaciones de los mismos y
el número de académicos perfeccionados en un periodo determinado.
• En síntesis, el modelo sistémico presenta para estos propósitos una gran ventaja,
pues ayuda a agrupar de manera ordenada los componentes institucionales y facilita
la comprensión de la relación que existe entre los mismos.
• Propuesta para sistematizar la información en el prototipo de evaluación de la calidad
de las instituciones de educación superior
• Para sistematizar la información se utilizarán las seis dimensiones del modelo de
CINDA que, como se ha dicho, permite hacer una revisión bastante completa y
coherente en los siguientes aspectos: académicos en general, en la función docente,
de investigación y creación, de extensión y servicios, y de gestión administrativa.
• De acuerdo con ello, se ha planteado la matriz modelo CINDA de información para
cada uno de los tres aspectos, que incluye los problemas de calidad a resolver, las
propuestas de solución y las sugerencias estratégicas.

32. DIMENSIONE
S
PROBLEMA
DE CALIDAD
A RESOLVER
PROPUESTA
DE SOLUCION
SUGERENCIA
ESTRATEGIC
A
RELEVANCIA
EFECTIVIDAD
RECURSOS
EFICIENCIA
EFICACIA
PROCESOS

33. Dicha matriz se aplicará para cada uno de los aspectos a evaluar respecto a la calidad
universitaria, entre los que tenemos:
• Función Docente
• Aspectos Generales Académicos
• Función Investigación
• Función Extensión
• Gestión Administrativo-académica
• Metodología para el desarrollo del prototipo de evaluación de la calidad
universitaria
Para el desarrollo del prototipo informático para la evaluación de la calidad de la educación
superior, se aplicarán los instrumentos y técnicas para levantar los requerimientos de
usuario, y producir las salidas que satisfagan las necesidades de información y el acceso en
forma integrada a la misma, respecto a los diferentes niveles de la pirámide organizacional;
esto es, nivel estratégico, nivel táctico y nivel operativo, accesibilidad a indicadores de
gestión de calidad universitaria a través de módulos interdependientes, es decir, cada nivel
con su vista de usuario en la base de datos.
Se aplica la metodología modular de sistemas, el enfoque de arriba hacia abajo y el diseño de
base de datos Diseño de arriba hacia abajo (top-down)
Se selecciona el diseño de arriba hacia abajo, “por la facilidad de visualizar una gran imagen del
sistema y luego explotarla en partes o subsistemas más pequeños. El diseño de arriba hacia
abajo permite que el analista de sistemas piense acerca de las interrelaciones e
interdependencias de los subsistemas. Este enfoque también proporciona el énfasis
deseado sobre la sinergia o las interfaces que requieren los sistemas y subsistemas. Las
ventajas de usar este enfoque para el diseño de sistemas incluyen el evitar el caos de diseñar
un sistema todo a la vez. El tratar de tener todos los subsistemas en su lugar y funcionando
a la vez es aceptar que se va a fallar”.