Presentacion de sistemas


EL CICLO DE VIDA
DEL DESARROLLO
DE SISTEMAS.
Ciclos de la vida
real y desarrollo de
sistemas
Prueba y
mantenimiento de
sistemas
Identificacion del
problema
oportunidades y
objetivos
Determinacion de
requerimiento de
informacion /
Analisis de las
nececidades de
sistemas
Diseño del sistema
recomendado
Desarrollo y
documentacion del
sotfware


 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.
Identificación de problemas, oportunidades y
objetivos.


 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.
Determinación de los
requerimientos de información.


 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.

Análisis de las necesidades del
sistema.


 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.

Diseño del sistema
recomendado.


 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.

Desarrollo y documentación del
software.


 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.

Pruebas y mantenimiento del
sistema.


 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.
El desarrollo orientado
a 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.
Características de los
prototipos


 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.
Uso de prototipo


 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).

Tipos de prototipos.


 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?


 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.
Lenguajes de 4ª
Generación.


generador de intertaces
Lenguaje de
programacion
Hoja de
calculo
Generador de
informaes
SISTEMAS DE ADMINISTRACION DE
BBDD
Carlos chavez


 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.
Ensamblaje de componentes y
aplicaciones.


 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.

Prototipos de Interface
de Usuario.


 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.
Herramientas:


 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.
FASES:


 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.

 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.
Definición del
Problema:


 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
-
INVESTIGACIO
N
-EXTENSION
-
ADMINISTRATI
VOS
-EGRESADOS
-PATENTES
-ASESORIAS
-SERVICIOS
Carlos chavez



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.


DIMENSION
ES
PROBLEMA
DE CALIDAD
A RESOLVER
PROPUESTA
DE
SOLUCION
SUGERENCI
A
ESTRATEGIC
A
RELEVANCIA
EFECTIVIDA
D
RECURSOS
EFICIENCIA
EFICACIA
PROCESOS
Carlos chavez


 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.


 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.
4.3 Adquisicion de sistemas de
informacion.

Presentacion de sistemas

Más contenido relacionado

La actualidad más candente

Similar a Presentacion de sistemas

Presentacion de sistemas