Desarrollo sistemas información alternativas adquisición

UNIDAD IV- ALTERNATIVAS DE
ADQUISICIÓN DE SISTEMAS DE
INFORMACION

EL CICLO DE VIDA DEL
DESARROLLO DE SISTEMAS.

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.

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.

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.
•

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.
•

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.
•

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.
•

4.2 PROTOTIPOS:
PROTOTIPOS INFORMÁTICOS.

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.

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.

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.

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).
•

• 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.
• 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.

• Vertical
• Desarrolla completamente alguna de las funciones.
• Horizontal
• Desarrolla parcialmente todas las funciones.
• 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?

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.

generador de intertaces
Lenguaje de
programacion
Hoja de calculo
Generador de
informaes
SISTEMAS DE ADMINISTRACION DE BBDD
SAUL GERARDO

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.

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.
•

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.

• 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.

• 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. 

• 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.
•

• 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.
•

•
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.

Definición del Problema:
• Las universidades necesitan desarrollar procesos de evaluación institucional de
desempeño, que conllevan a la revisión de sus estructuras funcionales y al
conocimiento diagnóstico de la situación actual con el fin de incrementar los
niveles de eficacia, eficiencia y efectividad de la gestión universitaria.
• Es necesario fomentar procesos de evaluación en función de optimizar el uso de
los recursos humanos, tecnológicos y financieros disponibles en la institución a
objeto de lograr un desarrollo más armónico y planificado, en atención a una
estricta observación de su misión. Bajo esta perspectiva se ofrece una propuesta
de Prototipo Informático para la Evaluación de la Calidad de la Educación
Superior, cuyos objetivos, entre otros, son: fomentar e incentivar la cultura de
evaluación de la calidad universitaria; diseñar indicadores de gestión
universitaria para dicho sistema de información, para cada uno de los ámbitos:
académico, investigación, extensión y administrativo. Para el desarrollo, se
aplicarán las herramientas 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, accesibilidad a indicadores de gestión de calidad
universitaria a través de módulos interdependientes; esto es, 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
relacional.

• El prototipo está diseñado bajo una interfaz gráfica para
interactuar con el usuario a través de botones programables y
la navegación del sistema se realizará a través de pantallas
tipo ventanas
• 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:
•

ENTRADA O
INSUMOS
PROCESOS SALIDA DEL
PRODUCTO
-ESTUDIANTES
-PROFESORES
-LABORATORIO
-BIBLIOTECA
-ACADEMICOS
-INVESTIGACION
-EXTENSION
-
ADMINISTRATIVOS
-EGRESADOS
-PATENTES
-ASESORIAS
-SERVICIOS
SAUL GERARDO

•
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.

DIMENSIONES PROBLEMA DE
CALIDAD A
RESOLVER
PROPUESTA DE
SOLUCION
SUGERENCIA
ESTRATEGICA
RELEVANCIA
EFECTIVIDAD
RECURSOS
EFICIENCIA
EFICACIA
PROCESOS
SAUL GERARDO

• 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”.

• Enfoque modular para el desarrollo de sistemas
• Una vez que ha sido tomado el enfoque de diseño de arriba
hacia abajo, el enfoque modular es útil en la programación.
Este enfoque involucra la división de la programación en
partes o módulos lógicos y manejables. Este enfoque de
programación se ajusta bien con el diseño de arriba hacia
abajo, debido a que enfatiza las interfaces entre módulos. En
el prototipo se aplica la metodología modular de sistemas
para desarrollar los módulos: Función Docente, Función
Investigación, Aspectos Generales Académicos, Función
Extensión, Gestión Administrativo-académica.

• Diseño de base de datos relacional
• Se selecciona el modelo relacional de base de datos, por ser el
óptimo en comparación con los modelos de base de datos
jerárquicos y el de redes. Otra ventaja de este modelo es la
portabilidad, ya que la mayoría de los paquetes de manejo de
base de datos para computadores personales usan el enfoque
“relacional”. En este modelo los datos se organizan en “tablas”
en las cuales una fila equivale a un registro. Conceptualmente
la tabla de la base de datos es lo mismo que un archivo. Una o
más tablas constituyen una base de datos relacional. La base
de datos relacional se refiere a una serie de tablas y a las
relaciones entre ellas. El sistema tendrá capacidad, entre otras
cosas, para:

•
Crear y mantener la base de datos: esto es agregar, eliminar y
modificar tablas.Extraer y presentar información que cumpla
ciertas condiciones.Hacer consultas (por ejemplo: “¿Cuál es el
promedio de notas de los alumnos por carrera y por
universidad? ¿Cuál es la matricula por área de conocimiento?
¿Cuál es la rotación matricular?”, etc.).Ordenar los registros
(tablas), según el campo clave.Generar informes adecuados
para el usuario. (Por ejemplo: una universidad generará el
reporte de gestión periódicamente, según sea el caso o el
“Reporte financiero” puede ser semestral o anual, etc.).

• Modelo entidad relación
• Se generarán una serie de entidades y relaciones “uno a muchos”, a
las cuales se le aplicará la técnica de normalización de tablas, incluso
la tercera forma normal 3FN y 4FN, de ser necesario. Entre las
entidades tenemos: Universidad, Alumnos, Profesor, Organismos
reguladores, Proveedores, Productos, Oferta académica laboral,
Egresados, etc.
• Diseño de la interfaz gráfica del prototipo
• Para el desarrollo del prototipo informático para la evaluación de la
calidad de la educación superior, se deben aplicar 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; esto es, cada
nivel con su vista de usuario en la base de datos.
• El prototipo está diseñado bajo una interfaz gráfica para interactuar
con el usuario a través de botones programables y la navegación del
sistema se realizará a través de pantallas tipo ventanas.

4.3 Adquisicion de sistemas
de informacion.
• El origen del estándar MoProSoft es la necesidad de cumplir con la
estrategia número 6 del Programa de Software (ProSoft) de la
Secretaría de Economía (establecida desde el sexenio 2000-2006),
relativa a "alcanzar niveles internacionales de capacidad de
procesos" por parte de las pequeñas y medianas empresas
mexicanas desarrolladoras de software. El esquema MoProSoft
permite a las PyMES que desarrollan software, demostrar la
capacidad de sus procesos y con esto hacerlas más competitivas, a
fin de que tengan mayores probabilidades de permanecer en el
mercado.
• En el ámbito de TI, NYCE contribuyó a la elaboración y posterior
evaluación del estándar o norma NMX-I-059/02-NYCE-2011
"Tecnología de la información - Ingeniería de Software - Calidad de
producto"(MoProSoft). La creación de este estándar no fue casual,
ya que con esto se logró dar legitimidad y certeza jurídica al modelo
de evaluación de madurez de la capacidad de procesos, para así
elevarlo a la categoría de norma, hoy estándar MoProSoft.

Desarrollo sistemas información alternativas adquisición

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Desarrollo sistemas información alternativas adquisición

Semelhante a Desarrollo sistemas información alternativas adquisición (20)

Último

Último (20)

Desarrollo sistemas información alternativas adquisición