MÓDULO IV - Universidad Nacional de Loja

UNIVERSIDAD NACIONAL DE LOJA 

ÁREA DE LA EDUCACIÓN, EL ARTE Y LA COMUNICACIÓN 

DOCENTE: 

CARRERA DE INFORMÁTICA EDUCATIVA 

NIVEL DE PREGRADO 

Modalidad Presencial 

MÓDULO IV 

ANÁLISIS Y DISEÑO DE 

SISTEMAS DE INFORMACIÓN 

Ing. Laura Amparo Guachizaca Sarango 

MARZO / JULIO 2010 

LOJA – ECUADOR

UNIVERSIDAD NACIONAL DE LOJA 

Dr. Gustavo Enrique Villacís Rivas Mg. Sc. 

RECTOR 

Dr. Ernesto Rafael González Pesantes Mg. Sc. 

VICERRECTOR 

ÁREA DE LA EDUCACIÓN, EL ARTE Y LA COMUNICACIÓN 

Dr. Yovany Salazar Estrada Mg. Sc. 

DIRECTOR DEL ÁREA 

Dra. Enriqueta Andrade Maldonado Mg. Sc. 

COORDINADOR DEL NIVEL DE FORMACIÓN O PREGRADO 

CARRERA DE INFORMÁTICA EDUCATIVA 

MÓDULO IV 

Ing. Jeovanny Espinoza Rojas 

COORDINADOR DE CARRERA 

Ing. Laura Amparo Guachizaca Sarango 

DOCENTE COORDINADORA DEL MÓDULO 

Teléfono: 2545558 Ext. 112 

Contacto gmail: lalitag20@gmail.com 

Contacto correo institucional: ieducativa@unl.edu.ec

Módulo IV: Análisis y Diseño de Sistemas de Información Pág. 3 

1. TITULO DEL MÓDULO: 

ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN. 

2. PRESENTACIÓN: 

Tomando en cuenta el desarrollo del sistema educativo en la región sur de nuestro país, 

se avizora la necesidad de contar con recursos humanos capaces de analizar, los 

requerimientos que plantea la solución de necesidades educativas que demandan aplicar 

recursos informáticos. 

La evaluación de materiales educativos computarizados (MEC) ya existentes, el 

desarrollo y mantenimiento de los nuevos MEC(s), requiere de criterios y metodologías 

científicamente fundamentadas, para garantizar que no se apliquen soluciones 

inapropiadas, costosas y que al final, resulte que no resuelve la necesidad inicial, sino 

que generan una situación de mayor complejidad. 

Con el presente módulo de Análisis y Diseño de Sistemas de Información, el estudiante 

de Informática Educativa, se inicia en el estudio de la(s) Metodología(s) para la 

evaluación y el desarrollo del software educativo, a partir de un marco conceptual 

general de la ingeniería del software que le permitirá una concepción amplia, en la que 

se enmarca la ingeniería del software educativo en particular. 

Además, el estudiante aplicará de forma práctica las dos primeras fases de la 

metodología del par el desarrollo del software educativo, como es el Análisis y el Diseño, 

sentando las bases para desarrollar un MEC al cursar, en el módulo de Desarrollo de 

Software Educativo. 

UNL-Informática Educativa


3. PROBLEMÁTICA 

Uno de los problemas en lo que a la educación respecta, y más aún en la Informática 

Educativa es la poca dedicación o relación que se tiene del verdadero Software Educativo 

que se tiene que desarrollar por los “Informáticos Educativos”, ya que elaborar software 

de este índole requiere de muchos aspectos pedagógicos, didácticos, técnicos, que 

comúnmente un desarrollador de Software Común no lo puede realizar salvo en la 

presencia conjunta de un experto en cualquiera de las áreas del saber. 

No se realiza un análisis de las verdaderas necesidades educativas para la creación de los 

MEC en nuestro entorno informático-educativo. 

El escaso conocimiento en la aplicación de técnicas, métodos y procesos utilizados para 

analizar, diseñar, implementar, codificar, probar y testear y finalmente documentar 

software educativo en nuestro país y la escasa utilización de herramientas de modelado 

ha provocado que la mayoría de los sistemas en construcción no cumplan con el objetivo 

educativo para los que fueron creados, desperdiciando así recursos y tiempo y bajo estas 

directrices de formación, se ha establecido la siguiente problemática: 

• Desconocimiento y vinculación teoría-práctica para los procesos de análisis y 

diseño de Software Educativo. 

• Escaso análisis de datos para la interpretación de la información y toma de 

decisiones en los procesos investigativos para determinar necesidades y 

requerimientos del software educativo. 

• Restringido empleo de programas que permitan modelar la realidad de los 

sistemas de información. 

Consideramos la necesidad de adaptar estrategias innovadoras de aplicación práctica 

adecuadas a las condiciones, necesidades y exigencias de nuestro sistema educativo. 



Con el avance de la tecnología, la educación empieza a generalizarse y a consolidarse en 

una forma de adaptación, pero los cambios sociales, políticos, económicos, culturales y 

tecnológicos, obligan a los sistemas educativos a entrar en un proceso permanente de 

transformación. 

4. OBJETO DE TRANSFORMACIÓN 

Actualmente el Software Educativo en desarrollo tiende a fracasar, desperdiciando el 

tiempo y los recursos asignados, la falta de experiencia en los profesionales y estudiantes 

para interactuar con los usuarios finales y poder recopilar información para el análisis de 

necesidades educativas y la forma limitada al utilizar procesos de gestión para crear MEC 

y el uso restringido de Lenguajes de Modelado Unificado (UML), esto impide construir, 

documentar, visualizar y especificar un sistema de software por consiguiente se propone 

dotar al estudiante de los conceptos de análisis y diseño de sistemas que les permita 

estructurar el proceso de desarrollo de los mismos para resolver problemas de la 

realidad usando la tecnología y su creatividad, entorno a procesos que posean 

fundamentos psicopedagógicos y científicos para el logro de aprendizajes significativos 

para orientar la gestión, planeación, análisis, diseño, desarrollo e implantación de MEC. 

5. OBJETIVOS 

Académicos: 

• Conocer los conceptos básicos de la ingeniería del software. 

• Conocer las etapas de vida del software. 

• Identificar las distintas clasificaciones del software educativo. 

• Analizar necesidades educativas. 

• Elaborar cada uno de los componentes del diseño de un software educativo. 

• Utilizar estándares para el análisis y diseño de software educativos. 



Psicosociales: 

• Articular los valores morales, cívicos y éticos en el diseño de software educativo. 

• Asumir una actitud crítica, autocrítica y reflexiva en el análisis de necesidades 

educativas. 

• Desarrollar criterios para la utilización racional de la tecnología en el análisis y 

diseño del software educativo. 

• Desarrollar una conciencia crítica tendiente a superar la calidad de software 

existente a fin de responder a las necesidades de la sociedad actual. 

6. PRÁCTICAS PROFESIONALES ALTERNATIVAS PARA LAS QUE HABILITA EL MÓDULO 

El presente módulo habilita al participante para que en equipos multidisciplinarios y en el 

marco de los Fundamentos Teórico Metodológicos de la Orientación a Objetos, realice la 

programación del módulo desde una aproximación que permita abordar el OT en un 

proceso de investigación-acción formativa, lo cual implica el desempeño de las siguientes 

prácticas profesionales: 

• Conocen los conceptos básicos de la ingeniería del software. 

• Conocen las etapas de vida del software. 

• Identifican las distintas clasificaciones del software educativo. 

• Analizan necesidades educativas. 

• Elaboran cada uno de los componentes del diseño de un software educativo. 

• Utilizan estándares para el análisis y diseño de software educativos. 

• Articulan los valores morales, cívicos y éticos en el diseño de software educativo. 

• Asumen una actitud crítica, autocrítica y reflexiva en el análisis de necesidades 

educativas. 

• Desarrollan criterios para la utilización racional de la tecnología en el análisis y 

diseño del software educativo. 

• Desarrollan una conciencia crítica tendiente a superar la calidad de software 

existente a fin de responder a las necesidades de la sociedad actual. 



7. PERFIL PROFESIONAL 

Los conocimientos, habilidades y actitudes que se pretenden desarrollar en el módulo para 

una práctica académicamente solvente y socialmente comprometida es la siguiente: 

• Para lograr que apliquen métodos y técnicas propias de los procesos de análisis y 

diseño de sistemas informáticos de acuerdo a estándares internacionalmente 

aceptados, exigidos por su práctica profesional docente, se necesita: 

1. Conocimientos suficientes sobre los métodos y técnicas empleadas en el 

UNL-Informática Educativa 

proceso de análisis y diseño de MEC. 

2. Suficiente información sobre la bibliografía relacionada con análisis y diseño 

de MES. 

3. Cuentan con el software necesario para diseñar y modelar sistemas 

informáticos basados en base de datos. 

4. Tienen conocimientos sobre los procesos reales de análisis, diseño, 

implementación, testeo y validación de resultados. 

5. Orientar la búsqueda y selección de problemas derivados del objeto de 

transformación para practicarlos en la investigación y su incidencia en el 

sector educativo y la búsqueda de alternativas de solución. 

6. Fomentar la participación grupal de los educandos para formar grupos 

multidisciplinarios que les permita recolectar, ordenar e interpretar la 

información. 

• Para lograr que interpretan datos, toman decisiones, determinan necesidades y 

requerimientos del software educativo. 

1. Los profesionales en formación tendrán que interactuar con el usuario final y 

sacar la información correspondiente. 

2. Empaparse de todos los procesos manuales que hace el usuario final, para 

poder convertirlo en un sistema.


• Para lograr que empleen programas que permitan modelar la realidad de los sistemas 

de información para su desarrollo. 

1. Los profesionales en formación utilizaran la herramienta de Análisis Orientado 


a Objetos para modelar la información obtenida de los usuarios finales. 

2. Los profesionales en formación conocerán los diferentes diagramas UML 

existentes 

3. Los profesionales en formación diseñaran y desarrollaran bases de datos 

según la información obtenida. 

8. DESCRIPCIÓN DEL PROCESO DE INVESTIGACIÓN 

Como parte fundamental para el cumplimiento del O.T., se elaborará un Proyecto de 

Investigación Formativa en torno al problema abordado que servirá de base teórica, siendo 

sumamente necesario consultar otros textos de acuerdo a las necesidades que surjan en el 

desarrollo del tema a investigarse. 

El proceso investigativo debe realizarse unificando los procesos de formación científica 

técnica y práctica en torno a un quehacer de investigación-acción participativa. Es factible y 

necesario para la investigación, la organización de grupos de trabajo cooperativo. 

En el módulo se establecerán espacios de discusión y debate sobre las temáticas a fin de 

fortalecer sus habilidades y destrezas de comunicación de los profesionales en formación. 

La interrelación de los datos recolectados con los conocimientos científicos técnicos 

adquiridos permitirá que el profesional en formación pueda emitir criterios técnicos 

aproximativos para los lineamientos proposititos, para ello se deberán cubrir en los tres 

momentos: 

PRIMER MOMENTO: Los profesionales en formación investigarán y aplicarán los 

métodos y técnicas propias de los procesos de análisis y diseño 

de sistemas informáticos de acuerdo a estándares 

internacionalmente aceptados.


SEGUNDO MOMENTO: Los profesionales en formación fundamentan de los procesos 


de análisis y diseño de sistemas informáticos y herramientas, 

implementación de la aplicación e interpretan datos, toman 

decisiones, determinan necesidades y requerimientos del 

software educativo. 

TERCER MOMENTO: Los profesionales en formación diseñan y realizan el prototipo 

9. REFERENTES TEÓRICOS 

PRIMER MOMENTO: 

según la información obtenida en los momentos anteriores. 

Tema I: Conceptos generales sobre la Ingeniería de Software. 

Objetivos Específicos: 

1. Retroalimentar el concepto de software. 

2. Analizar los conceptos de ingeniería e ingeniería del software. 

3. Examinar los elementos de complejidad inherentes al software y los 

factores de calidad del mismo. 

4. Determinar la necesidad de aplicar una metodología para la valoración o 

desarrollo del software. 

5. Conocer cada una de las fases o etapas del ciclo de vida del software. 

Subtemas: 

1. Conceptos sobre: software, ingeniería, e Ingeniería de software. 

2. La complejidad inherente al software. 

3. Factores en la calidad del software. 

4. Requisitos y especificación del software 

5. Macromodelo. Metodología o El ciclo de vida del software. 

6. Fases o etapas del ciclo de vida del software. 

7. UML.


Tema II: Ingeniería del software educativo. 



1. Analizar las particularidades del software educativo con respecto al 

software en general. 

2. Estructurar la clasificación de los diferentes tipos de software educativo. 

3. Conocer la metodología para la evaluación y desarrollo del software 

educativo. 

4. Analizar cada una de las fases de la metodología para la evaluación y 

desarrollo del software educativo. 

Subtemas: 

1. El software educativo, como un tipo particular de software. 

2. Clasificación del software educativo. 

3. Metodología para la evaluación y desarrollo del software educativo. 

4. Definición de cada una de las fases o etapas del ciclo de vida del software 

educativo. 

SEGUNDO MOMENTO: 

Tema III: Análisis de necesidades educativas. 


1. Identificar y clasificar las necesidades educativas. 

2. Determinar fuentes de información y soluciones de las necesidades 

educativas. 

3. Aplicar la metodología de análisis para determinar necesidades educativas 

Subtemas: 

que requieren apoyo informático. 

1. Definición y Tipos. 

2. Fuentes de información apropiadas e identificación del problema. 

3. Análisis de posibles causas de los problemas detectados. 

4. Análisis de alternativas de solución.



5. Metodología de análisis de necesidades educativas que requieren de 

apoyo informático. 

6. Selección o planeamiento del desarrollo de MECs. 

7. Ciclos para la selección o el desarrollo de MECs. 

TERCER MOMENTO: 

Tema IV: Diseño de MECs. 


1. Delimitar los componentes del entorno para el diseño del MEC. 

2. Elaborar el componente educativo del diseño de un MEC. 

3. Elaborar el componente comunicación del diseño de un MEC. 

4. Elaborar el componente computacional del diseño de un MEC. 

Subtemas: 

1. Entorno para el diseño del MEC. Población objeto. Área de contenido. 

Necesidad educativa. Limitaciones y recursos para los usuarios. Equipo y 

soporte lógico necesario. 

2. Diseño educativo. ¿Qué aprender con el MEC? ¿En qué ambiente o 

micromundo aprenderlo? ¿Cómo saber que el aprendizaje se está 

logrando? ¿Cómo motivar y mantener motivado a los usuarios? 

3. Diseño comunicación. Interfaz hombre-máquina. Principios de 

comunicación. Dispositivos de entrada y salida. Diseño de zonas de 

comunicación. Elementos constitutivos de las zonas de comunicación. 

Verificación de las interfaces. 

4. Diseño computacional. Definición funcional del MECS. Estructuración 

lógica para la interacción, estructura de datos. Prototipo del MECs.


10. METODOLOGÍA 

Se sugiere las siguientes estrategias metodológicas para el desarrollo de este módulo. 

Tema I: Trabajar a través de lecturas comentadas, discusión en grupo y plenaria los 

conceptos generales de la ingeniería del software. Elaborar en un mapa 

conceptual que refleje las relaciones entre los conceptos trabajados. 

Tema II: En esta unidad se presenta a groso modo lo concerniente al software educativo, sin 

entrar en detalles, se puede utilizar la V de Gowin para que los alumnos y alumnas 

hagan metacognición y estructuren de manera general las fases del diseño, 

desarrollo e implementación. 

Tema III: En esta unidad los alumnos desarrollarán una investigación de necesidades 

educativas; ésta debe de cumplir todos los requerimientos del método científico 

para demostrar su existencia. Los alumnos deberán presentar un informe de la 

investigación. 

Tema IV: A medida que se vaya desarrollando la teoría se elaborará el diseño para el 

desarrollo de un software que responda a la necesidad educativa detectada. Al 

finalizar los alumnos entregarán el diseño elaborado y un prototipo. 

11. PRODUCTOS ACREDITABLES 

Los productos acreditables del módulo son el resultado del proceso académico-investigativo, 

que serán evaluados, acreditados y calificados en forma permanente, sistemática e integral, 

mediante las evidencias de aprendizaje logradas a través del conjunto de estrategias 

didácticas planificadas en el módulo: 

• Primer momento un informe que contiene la caracterización y descripción de la 

problemática 

• Segundo momento un ensayo que exprese la comprensión y explicación de los 

fundamentos teóricos y empíricos de la problemática 



• Tercer momento socialización del trabajo de investigación, y concluir con las posibles 

alternativas de solución a la problemática. 

12. EVALUACIÓN Y ACREDITACIÓN 

La evaluación estará presente durante su desarrollo en todas y cada una de las actividades 

que se lleven a cabo y durante cada momento de modo que lleguemos a comprender y 

desarrollar el análisis y diseño de sistemas. 

La acreditación requiere que en forma consciente y comprometida, los profesionales en 

formación: 

• Construyamos cada uno de los procesos empleados en el análisis y diseño de MEC. 

• Sustentemos los trabajos y los aprendizajes con pertinencia y profundidad teórica, 

técnica y operativa. 

• Participemos en forma espontánea en cada una de las fases de elaboración de un 

MEC. 

• Aportemos con nuestras experiencias, inquietudes, consultas, aprendizajes para 

compartirlos con los otros compañer@s con los que interactuemos en el grupo y 

entorno de trabajo. 

La calificación será la valoración de los productos acreditables en una escala de 1 a 10 

puntos, siendo necesario para su aprobación obtener una calificación mínima de 7 puntos. 

Consecuentemente, la calificación y la acreditación, estarán en relación con la evaluación de 

los aprendizajes; y, todo este proceso deberá permitir constatar el nivel de logro de los 

aprendizajes previstos (prácticas profesionales y perfil profesional que cubre el módulo). 

En esta perspectiva, la evaluación-calificación-acreditación de los aprendizajes se asumirá en 

referencia a dos aspectos: 

• El dominio de conocimientos teórico-prácticos: 

o Información sobre el análisis y diseño de sistemas. 



• La investigación del módulo: 

o Dominio de los conocimientos teórico-prácticos: 

o Manejo de los contenidos teórico-prácticos estudiados en las unidades o 

temáticas del módulo. 

o Participación activa: referida a la contribución individual oportuna, pertinente 


y fundamentada del estudiante a lo largo del desarrollo de la temática de 

estudio en las conferencias-foros, talleres, lecturas comentadas, entre otras 

actividades. 

o Desarrollo y sustentación de la investigación del módulo 

Para evaluar los trabajos desarrollados por el estudiante, se tomarán en cuenta los 

siguientes criterios: 

• Pertinencia con las Guías de Estudio en cada uno de los momentos de estudio. 

• Claridad en redacción, ortografía y presentación. 

• Coherencia del proceso. 

• Aporte individual crítico y fundamentado. 

• Puntualidad en la entrega. 

1. Participación en clase 3.0 

2. Desarrollo de actividades: 1.0 

3. Trabajos y ejercicios como aporte por parte del estudiante (extraclase) 3.0 

4. Pruebas escrita o prácticas 3.0 

5. Desarrollo y socialización de la Investigación Formativa 10 

6. Talleres extra apoyo al módulo 10 

TOTAL 10 

10


13. EQUIPO DOCENTE 

Luis Antonio Chamba Eras, Ingeniero en Sistemas Informáticos y Computación. 

lachamba@gmail.com, luisantonio151@hotmail.com. 

14. HERRAMIENTA COMPUTACIONAL PARA EL APOYO DEL APRENDIZAJE 

Se trabajará en un Entorno Virtual de Aprendizaje (EVA), en un campus virtual para el apoyo 

para el cuerpo docente en la comunidad EQaula: 

http://www.eqaula.org 

Dirección Web del Curso: 

http://eqaula.org/eva/course/view.php?id=826 

15. BIBLIOGRAFÍA 

• GALVIS PANQUEVA ALVARO H. Ingeniería del Software Educativo. Ediciones 

Universidad de los Andes, Santa Fe, Bogotá. Colombia. 1993. 

• SOMMERVILLE, Ian. Ingeniería del software. Séptima edición. PEARSON EDUCACIÓN. 

S.A., Madrid 2005, ISBN: 84-7829-074-5, 712 Páginas. 

• Materiales Multimedia Educativos para la enseñanza en línea. 

http://www.merlot.org/merlot/materials.htm?category=2605& 

• OCW: Ingeniería del Software. 

http://mit.ocw.universia.net/6.170/6.170/f01/index.html 

• Open Course Ware: Informática Educativa 

http://ocw.uis.edu.co/tecnologias-de-informacion-y-comunicacion-tics/informaticaeducativa/Course_listing 

• OCW: Ingeniería del Software III 

http://ocw.uc3m.es/informatica/ingenieria-de-software-iii 

• OCW: Inteligencia Artificial 

http://ocw.uc3m.es/informatica/inteligencia-artificial 



• OCW: Inteligencia Artificial 2 

http://ocw.uc3m.es/informatica/inteligencia-artificial-2 

• OCW: Técnicas multimedia 

http://ocw.ua.es/ensenanzas-tecnicas/tecnicas_multimedia/Course_listing 

• EVA (http://www.eqaula.org): Módulo 4: Análisis y Diseño de Sistemas de 

Información. En el EVA se adjuntarán los documentos para cada uno de los cuatro 

temas en que se trata el módulo así como las actividades complementarias del 

módulo. 



16. MATRIZ DEL MÓDULO 

FECHAS 

09 de marzo al 

24 de abril 2009. 

7 semanas 

laborables 


PROCESO DE 

INVESTIGACIÓN 

Seleccionar el tema de 

investigación en su zona 

de influencia 

MATRIZ DE DESARROLLO DE LA INVESTIGACIÓN DEL MÓDULO 

PRIMER MOMENTO 

ESTRATEGIAS DE 


Para realizar el I Momento 

de la investigación debemos 

considerar lo siguiente: 

• Revisión bibliográfica y 

documental. 

• Sistematización de la 

información bibliográfica 

referida al objeto de 

investigación. 

• Preparación de síntesis 

de la información 

recuperada para 

sustentar teóricamente 

la problemática del 

módulo y caracterizarla. 

REFERENTES TEÓRICO – 

PRÁCTICO 

Tema I: Conceptos 

generales sobre la 

Ingeniería de Software 

Tema II: Ingeniería del 

software educativo. 

ESTRATEGIAS 

DIDÁCTICAS 

Para abordar el 

contenido teóricopráctico 

del módulo en 

el 1 er momento, 

tenemos las siguientes 

estrategias: 

• Lectura comentada 

del material 

bibliográfico. 

• Ampliación de 

bibliografía. 

• Elaboración de 

reportes teóricos. 

• Descripción de 

observaciones. 

• Utilización de 

técnicas para el 

manejo de la 

información. 

• Consulta 

electrónica 

EVALUACIÓN, 

ACREDITACIÓN Y 

CALIFICACIÓN 

• Recepción de 

las actividades 

del momento


FECHAS 

27 de abril al 12 

de junio 2009. 

7 semanas 

laborables 


PROCESO DE 


Determinar los 

referentes teóricos. 



• Lectura de 

documentos 

• Taller interno. 

• Instalación y uso 

de programas. 

SEGUNDO MOMENTO 

REFERENTES TEÓRICO 

– PRÁCTICO 

Tema III: Análisis de 

necesidades 

educativas 

ESTRATEGIAS 

DIDÁCTICAS 

Para abordar el 

contenido teóricopráctico 

del módulo 

en el 2 do momento, 

tenemos las 

siguientes estrategias: 

• Lectura 

comentada del 

material 

bibliográfico. 

• Ampliación de 

bibliografía. 

• Elaboración de 

reportes teóricos. 

• Consulta 

electrónica 

EVALUACIÓN, 


CALIFICACIÓN 

• Recepción de las 

actividades del 

momento


FECHAS 

15 de junio al 31 de 

julio 2009. 

7 semanas 

laborables 


PROCESO DE 


Socialización de las 

investigaciones y 

propuestas 

alternativas. 



TERCER MOMENTO 

REFERENTES TEÓRICO 

– PRÁCTICO 

Tema IV: Diseño de 

MECs 

ESTRATEGIAS 

DIDÁCTICAS 

Artículos 

científicos, 

informáticos. 

Entrega de 

prototipos. 

EVALUACIÓN, 


CALIFICACIÓN 

• Recepción de las 

actividades del 

momento


1. INTRODUCCIÓN A LOS SISTEMAS DE INFORMACIÓN 

En la actualidad para muchas organizaciones, los sistemas de información basados en 

computadoras son el corazón de las actividades cotidianas y objeto de gran consideración en la 

toma de decisiones, por lo tanto hablar de tecnología es referirnos a la expansión de las 

computadoras en el uso del correo electrónico y del Internet en las rutinas laborales de una 

oficina de gobierno, Institución, etc. 

La tecnología se aplica a la vida social, económica y cultural no solo nos posibilita producir más 

en menos tiempo, tener más información o imaginar nuevas soluciones a nuevos problemas, 

modifica espacios y tiempo, esquemas de socialización nuestra relación con el entorno natural. 

Los profesionales en formación deben capacitarse en el desarrollo de cualquier proyecto, para 

ello se debe, realizar un análisis de sistemas para detectar todos los detalles de la situación 

actual en la empresa. La información reunida con este estudio sirve como base para crear varias 

estrategias de diseño. Los administradores deciden qué estrategia seguir. Los gerentes, 

empleados y otros usuarios finales que se familiarizan cada vez más con el empleo de 

computadoras, por lo tanto están teniendo un papel muy importante en el desarrollo de 

sistemas. 

1.1. ¿QUÉ ES UN SISTEMA DE INFORMACIÓN? 

"Conjunto integrado de personas y máquinas "cuyo objetivo es entregarle a una 

organización información requerida para apoyar las operaciones, la administración y la 

toma de decisiones. El sistema utiliza máquinas y equipos computacionales (hardware), 

programas (software), procedimientos manuales, bases de datos, planificación y toma de 

decisiones. “ 

Tipos: Apoyan HW, SW 

Universidades 

Colegios 

Escuelas 

Equipos de trabajo 

Ejercito 

Empresas 

Etc. 


Organización 

Sist. De información 

Fortalecen Rec. Humanos 

Conducen: Reducir tiempo, 

Márgenes de error en el logro 

de sus objetivos.


1.2. ¿QUÉ ES EL ANÁLISIS Y DISEÑO DE SISTEMAS? 

El análisis y diseño de sistemas busca analizar sistemáticamente la entrada de datos y flujo 

de los mismos, se refiere al proceso de examinar la situación de una empresa, con el propósito 

de mejorar con métodos y procedimientos más adecuados, para el flujo de información. 

El desarrollo de sistemas tiene dos componentes: 


Análisis Diseño 

• Es el proceso de clasificación e 

interpretación de hechos, 

diagnóstico de problemas y 

empleo de la información para 

recomendar mejoras al sistema. 

• Especifica que es lo que el 

sistema debe hacer. 

• La finalidad del análisis está, en 

comprender los detalles de una 

situación y decir si es factible 

una mejora a ese proceso. 

• Especifica las características del 

producto terminado. 

• Establece como alcanzar el objetivo 

final. 

1.3. ¿CUÁLES SON LOS ELEMENTOS DE LOS SISTEMAS DE INFORMACIÓN? 

Entrada Proceso Salida 

Elementos de un Modelo General de Sistema 

Sistema: 

Entorno: Medio ambiente donde está inserto el sistema. Tiene intercambio con el sistema. 

Fronteras: Son las restricciones o limitaciones que distinguen el sistema de su entorno. 

Entradas: Son los elementos que ingresan al sistema desde el entorno, necesarios para 

cumplir los objetivos los objetivos 

Salidas: Son el objetivo del sistema. lo que entrega: entorno en base a las entradas que recibió 

al entorno en base a las entradas que recibió


Proceso: Es la actividad que transforma las entradas en salidas que el sistema debe generar en 

salidas que el sistema debe generar. 

Retroalimentación: Es el producto regresado a personas o actividades apropiadas en la 

institución para evaluar y afinar el insumo. 

1.4. CATEGORÍAS DE LOS SISTEMAS DE INFORMACIÓN 

• Sistemas de Procesamiento de Transacciones, ejemplo, de un cajero automático. 

Actividad del cliente Actividad del sistema 

Ingresar tarjeta Verificar código tarjeta 

Proporcionar el número 

de cuenta 

Verificar la validez del número de cuenta 

Proporcionar 

contraseña 

la Verificar que la contraseña es correcta 

Proporcionar el monto de Verificar que el monto se encuentre dentro de 

retiro 

los límites del banco. 

Verificar si el monto es menor que el saldo. 

Registrar la transacción en los archivos. 

Entregar el dinero. 

Emitir el comprobante 

Retirar el dinero y tarjeta Prepararse para la siguiente transacción. 




Caso de uso 

• Sistemas para el apoyo a las decisiones 

Sus etapas de desarrollo son: 

• Percepción de la 

Necesidad 

• Estudio de Factibilidad 

• Diseño Lógico 

• Diseño Físico 

• Construcción 

• Prueba e Implementación 

• Operación 

• Mantenimiento


• Sistemas De Información Administrativos (SIA), ejemplo: 

Facturación 

Cobranza 

Control de inventario 

Planificación de producción 

Administración de caja. 

1.5. ¿CÓMO INTERVIENE LA INGENIERÍA DEL SOFTWARE? 

Ingeniería de software. Es una disciplina que integra métodos, herramientas y procedimientos para 

el desarrollo de programas con la intención de brindar el apoyo en la toma de decisiones. 


Objetivos 

Modelo de control básico 

Entradas Sistema Salidas 

Nota: aquí se debe utilizar una experiencia previa. 

La salida 

del sistema 

sirve como 

retroalimen 

tación que 

comprar el 

desempeño 

con los 

objetivos


2. MÉTODOS DE DESARROLLO DE SISTEMAS APLICADAS AL DISEÑO DEL 

SOFTWARE EDUCATIVO 

2.1. CARACTERÍSTICAS PEDAGÓGICAS DE UN SOFTWARE EDUCATIVO 

1. Adaptación al Ritmo de Aprendizaje del Usuario 

• Debe ser eficaz en el aprendizaje individual, donde el usuario pueda avanzar de acuerdo con 

sus propias necesidades. 

• Debe reconocer las diferencias en el estilo y ritmo de aprendizaje. 

• Debe acceder cuantas veces quiera a la información sin temor al rechazo y la crítica. 

2. Libertad de Movimiento dentro del Contenido 

• Se puede avanzar o retroceder, como profundizar, de acuerdo con los requerimientos y 

necesidades de información- motivación por parte del usuario. 

3. Administración del Tiempo 

• El Usuario toma el tiempo necesario para aprender, organiza su tiempo como mejor le 

parezca. 

4. Representación del Contenido 

• Hace referencia a la utilización de los medios (imagen, Sonido, Texto) para representar un 

contenido (teorías, reglas, escenarios), y así obtener y entender en menor tiempo la 

información. 

5. Planeación del Contenido 

• Presentar la información de una forma clara y contundente, reduce la distancia entre lo que 

el docente quiere expresar, y lo que el alumno entiende. 

• Se pueden dejar escenarios donde el alumno involucra su propia creatividad e ingenio, 

haciendo más interesantes, relevantes y útiles algunas temáticas; rescatando la fantasía, 

acertijos, juegos, etc. 

2.2. TIPOS DE SOFTWARE EDUCATIVO 

2.2.1. TIPO ALGORÍTMICO 

Predomina el aprendizaje vía transmisión de conocimiento, desde quien sabe, hacia quien lo desea 

aprender y donde el diseñador se encarga de encapsular secuencias bien diseñadas de actividades de 

aprendizaje que conducen al interesado desde donde está hasta donde se desea llegar; el papel del 

usuario es asimilar al máximo de lo que se transmite. Dentro de este tipo se encuentran: 

2.2.1.1. SISTEMAS TUTORIALES 

Incluye cuatro fases que deben formar parte de todo proceso de enseñanza-aprendizaje: La fase 

Introductoria, en la que se genera la motivación, se centra la atención y se favorece la percepción 

selectiva de lo que se desea que el usuario aprenda. La fase de orientación inicial en la que se da la 

codificación, almacenaje y retención de lo aprendido. La fase de aplicación en la que hay evocación 



y transferencia de lo aprendido. La fase de Retroalimentación en la que se demuestra lo aprendido, 

ofrece retroinformación y esfuerzo o refuerzo. 

2.2.1.2. SISTEMAS DE EJERCITACIÓN Y PRÁCTICA 

Refuerzan las dos fases finales del proceso de instrucción: aplicación y retroalimentación. Se parte de 

la base que el usuario tiene un conocimiento previo del tema relacionado con el software final. 

Donde el software le servirá para probar sus destrezas y conocimientos adquiridos previamente. 

Estos sistemas sirven como motivación y refuerzo para el usuario. 

2.2.2. TIPO HEURÍSTICO 

Predomina el aprendizaje experimental y por descubrimiento, donde el diseñador crea ambientes 

ricos en situaciones que el usuario debe explorar conjeturablemente. El usuario debe llegar al 

conocimiento a partir de experiencias, creando sus propios modelos de pensamiento, sus propias 

interpretaciones del mundo. Pertenecen a este grupo: 

2.2.2.1. SIMULADORES Y JUEGOS EDUCATIVOS 

Ambos poseen la cualidad de apoyar el aprendizaje de tipo experimental conjetural, como base para 

lograr aprendizaje por descubrimiento. La Interacción con un micromundo, en forma semejante a la 

que se tendría en una situación real, es la fuente del conocimiento; el usuario resuelve problemas, 

aprende procedimientos, llega a entender las características de los fenómenos y cómo controlarlos, o 

aprende qué acciones tomar en diferentes circunstancias. Lo esencial en ambos casos es que el 

usuario es un agente necesariamente activo que, además de participar en la situación debe 

continuamente procesar la información que el micromundo le proporciona en forma de situación 

problemática, condiciones de ejecución y resultado. 

2.2.2.2. MICROMUNDOS EXPLORATORIOS Y LENGUAJE SINTÓNICO 

Una forma particular de interactuar con micromundos es haciéndolos con ayuda de un lenguaje de 

computación, en particular si es de tipo sinfónico con sus instrucciones y que se puede usar 

naturalmente para interactuar con un micromundo en el que los comandos sean aplicables. 

2.2.2.3. SISTEMAS EXPERTOS 

Capaces de representar y razonar acerca de algún dominio rico en conocimientos, con el ánimo de 

resolver problemas y dar consejos a quienes no son expertos en la materia. Además, de demostrar 

gran capacidad de desempeño en términos de velocidad, precisión y exactitud, tiene como contenido 

un dominio de conocimientos que requiere gran cantidad de experiencia humana, no solo principios 

o reglas de alto nivel, y que es capaz de hallar o juzgar la solución de algo, explicando o justificando lo 

que haya o lo que juzgue; de modo que es capaz de convencer al usuario que su racionamiento es 

correcto. 



2.3. MÉTODOS DE DESARROLLO DE SISTEMAS (SOFTWARE EDUCATIVO) 

2.3.1. MÉTODO CASCADA 

La versión original del modelo en cascada, fue presentada por Royce en 1970, aunque son más 

conocidos los refinamientos realizados por Boehm [1981], Sommerville [1985] y Sigwart y col. 

[1990]. En este modelo, el producto evoluciona a través de una secuencia de fases ordenadas en 

forma lineal y permitiendo iteraciones al estado anterior. 

• En un modelo en cascada, un proyecto progresa, a través de una secuencia ordenada de 

pasos partiendo de la especificación de requerimientos. 

• El método realiza una revisión al final de cada etapa para determinar si está preparado para 

pasar a la siguiente etapa, por ejemplo, desde el análisis de requerimientos hasta el diseño. 

• Cuando la revisión determina que el proyecto no está listo para pasar a la siguiente, 

permanece en la etapa actual hasta que esté preparado. 

• Ayuda a localizar errores en las primeras etapas del proyecto. 

• Para un proyecto de desarrollo rápido, el modelo en cascada puede suponer una 

cantidad excesiva de documentación cantidad. 



El número de etapas suele variar, pero en general suelen ser: 

• Análisis de requisitos del sistema 

• Análisis de requisitos del software 

• Diseño preliminar 

• Diseño detallado 

• Codificación y pruebas 

• Explotación (u operación) y mantenimiento 

Las características de este modelo son: 

• Cada fase empieza cuando se ha terminado la anterior. 

• Para pasar a la fase posterior es necesario haber logrado los objetivos de la fase anterior 

• Es útil como control de fechas de entregas. 

• Al final de cada fase el personal técnico y los usuarios tienen la oportunidad de revisar el 

progreso del proyecto. 

2.3.2. MÉTODO CODIFICAR Y CORREGIR 

• El modelo Codificar y Corregir (Code- and-fix) es un modelo poco útil, pero sin embargo 

bastante común. 

• Cuando se utiliza éste método.- se empieza con una idea general de lo que se necesita 

construir. 

• Se utiliza cualquier combinación de diseño, código, depuración y métodos de prueba no 

formales que sirven hasta que se tiene el producto listo para entregarlo. 




Ventajas Desventajas 

• No conlleva ninguna 

gestión; no se pierde 

tiempo en la planificación, 

en la documentación, en el 

control de calidad, en el 

cumplimiento de los 

estándares, o en cualquier 

otra actividad que no sea 

codificación pura. 

• Requiere poca experiencia 

cualquier persona que haya 

escrito alguna vez un 

programa está 

familiarizada con éste 

modelo. 

2.3.3. MÉTODO DESARROLLO EN ESPIRAL 

• El modelo resulta peligroso 

para otro tipo de proyectos 

que no sean pequeños. 

• No proporciona medios de 

evaluación de la calidad, ni 

identificación de riesgos. 

• Si al llevar tres cuartas partes 

de la codificación descubre que 

el diseño es incorrecto, no hay 

otra, solución que desechar el 

trabajo y comenzar de nuevo. 

• Es un modelo de ciclo de vida orientado a riesgos que un proyecto software en 

miniproyectos. 

• Cada mini proyecto se centra en uno o más riesgos importantes, hasta que todos estén 

controlados. 

• Después de controlar todos los riesgos más importantes, el modelo en espiral finaliza, del 

mismo modo que el ciclo de vida en cascada.



FUNCIONAMIENTO 

En cada Cuadrante del Método Espiral se realiza las siguientes actividades: 

• Planificación: Determinación de objetivos, alternativas, restricciones, y elaboración del plan 

de desarrollo para el ciclo actual. 

• Análisis de Riesgos: Evaluación de las alternativas, identificación y resolución de riesgos. Se 

decide si se sigue o no con el proyecto. 

• Ingeniería: Desarrollo del producto siguiendo un modelo del ciclo de vida o cascada, 

prototipo, etc. 

• Evaluación por el cliente: valoración de resultados. 

2.3.4. MÉTODO PROTOTIPO DE SISTEMAS 

El uso de prototipos se centra en la idea de ayudar a comprender los requisitos que plantea el 

usuario, sobre todo si este no tiene una idea muy acabada de lo que desea. También pueden 

utilizarse cuando el ingeniero de software tiene dudas acerca de la viabilidad de la solución pensada.


Se desarrolla prototipos cuando: 

• Un prototipo en sistemas de información es un modelo operable, que tiene todas las 

características necesarias, pero que es ineficiente debido a que los programas fueron hechos 

a la carrera con el objetivo de ser funcionales, en vez de ser eficientes. 

• La elaboración de prototipos de sistemas de información es una técnica valiosa para la 

recopilación rápida de información específica acerca de los requerimientos de información 

de los usuarios. 

• La velocidad es esencial para la elaboración satisfactoria del prototipo en su sistema de 

información. El prototipo debe llevarse menos de una semana para ensamblarse y lo 

preferible son dos o tres días. 

Al usar prototipos, las etapas del ciclo de vida clásico quedan modificadas de la siguiente manera: 

• Análisis de requisitos del sistema 

• Análisis de requisitos del software 

• Diseño, desarrollo e implementación del prototipo 

• Prueba del prototipo. 

• Refinamiento iterativo del prototipo 

• Refinamiento de las especificaciones del prototipo 

• Diseño e implementación del sistema final 

• Explotación (u operación) y mantenimiento 

2.4. LA NECESIDAD DE UNA METODOLOGÍA DE DESARROLLO 

Maddison [1983] define metodología como un conjunto de filosofías, etapas, procedimientos, reglas, 

técnicas, herramientas, documentación y aspectos de formación para los desarrolladores de sistemas 

de información. 

Piattini [1996], llega a la definición de metodología de desarrollo como “un conjunto de 

procedimientos, técnicas, herramientas, y un soporte documental que ayuda a los desarrolladores a 

realizar nuevo software”. Sintetizando lo anterior el autor dice que una metodología “representa el 

camino para desarrollar software de una manera sistemática”. 

Las metodologías persiguen tres necesidades principales: 

• Mejores aplicaciones, conducentes a una mejor calidad. 

• Un proceso de desarrollo controlado. 

• Un proceso normalizado en una organización, no dependiente del personal. 

1.1.1. Los procesos se descomponen hasta el nivel de tareas o actividades elementales, 

donde cada tarea está identificada por un procedimiento que define la forma de 

llevarla a cabo. Para aplicar un procedimiento se pueden usar una o más técnicas, 

pudiendo ser gráficos con textos. 



2.5. CARACTERÍSTICAS Y CLASIFICACIÓN DE LAS METODOLOGÍAS 

Se pueden enumerar una serie de características [Piattini, 1996] que debe tener la metodología y 

que influirán en el entorno de desarrollo: 

• Reglas predefinidas 

• Determinación de los pasos del ciclo de vida 

• Verificaciones en cada etapa 

• Planificación y control 

• Comunicación efectiva entre desarrolladores y usuarios. 

• Flexibilidad: aplicación en un amplio espectro de casos 

• De fácil comprensión 

• Soporte de herramientas automatizadas. 

• Que permita definir mediciones que indiquen mejoras 

• Que permita modificaciones 

• Que soporte reusabilidad del software 

2.6. PLANIFICACIÓN DE LA GESTIÓN DE PROYECTOS USANDO EL CICLO DE VIDA CLÁSICO DE UN 

SISTEMA 

Características 

• Las fases nunca se llevan como un paso a parte. 

• Varias actividades pueden suceder simultáneamente. 

• Las actividades pueden repetirse. 



: 



2.6.1. ¿CUÁLES SON LOS ELEMENTOS QUE INTERVIENEN EN EL CICLO DE VIDA DE UN SISTEMA? 

1. Identificación del problema, 

oportunidades y objetivo. 

7. Implantación y evaluación 

del sistema. 

2.6.1.1. DEFINICIÓN DEL PROBLEMA (PLANTEAMIENTO) 

Características: 

• Cada actividad realizada siempre es parte de un entorno mayor. 

• El trabajo comienza estableciendo los requisitos de todos aquellos elementos 

importantes del sistema. 

• Es esencial cuando el SW debe interrelacionarse con otros elementos SW, HW, 

personas, base de datos, etc. 

IVOLUCRADOS 

Usuarios. 

Analista. Docente informática educativa 

Administradores de sistemas 

GEERA 

Estudio de factibilidad. 

Definición del problema. 

Sumarización de objetivos. 


2. Determinación de los 

requerimientos de 

información. 

CICLO DE 

VIDA DEL 

SISTEMA 

6. Prueba y mantenimiento. 

1ra. Fase 

Identificación de problemas 

y objetivos 

3. Análisis de las 

necesidades del 

sistema. 

4. Diseño del sistema 

(recomendado). 

5. Desarrollo y 

documentación del 

software. 

ACTIVIDADES 

Entrevista a los administradores y 

usuarios. 

Sumarización de conocimientos 

adquiridos. 

Estimación del alcance del proyecto. 

Documentación de resultados. 

RESULTADOS 

Tomar la decisión se continúa el proyecto 

propuesto. 

Si la empresa no cuenta con dinero. 

Se desea atacar problemas no relacionados. 

Problemas no automatizados. 

Recomendar una solución manual.


Planeación: 

• Seleccionar un equipo para el análisis del sistema 

• Asignar a los miembros en proyectos adecuados 

• Estimación de tiempo requerido para cada tarea 

• Calendarización del proyecto para determinar las tareas y ordenamiento 

Planeación Control Usar la retroalimentación Compara el plan con su 

Para monitorear el proyecto evolución actual 

1ra. 

decisión 

Planeación y 

control de las 

actividades 

Tomar acciones adecuadas 

para agilizar o recalendarizar 

las actividades para terminar 

a tiempo y motivas a los 

analistas 


ESTIMACIÓN DE TIEMPO REQUERIDO 

Determinar cantidad de 

detalles que se necesitan 

para la definición de 

actividades 

2.6.1.2. DETERMINACIÓN DE LOS REQUERIMIENTOS 

Aquí se debe hacer lo siguiente: 

Estimación del 

tiempo requerido 

Uso de gráficas de 

Gantt o los de 

Pert 

Ciclo menor – ciclo de vida de un 

sistema 

Ciclo alto – Cada paso detallado 

• Recopilación de información 

• El analista debe comprender las funciones del negocio. 

• Tener informe sobre personas, objetivos y procedimientos. 

• Investigar datos relevantes. 

• El Analista comprende que información necesitan los usuarios para trabajar.


Por ello intervienen: 

Herramientas: 

• Entrevista. 

• Cuestionario. 

• Comportamiento de los tomadores de decisión. 

• Prototipos. 

Involucrados: 

• Analista. 

• Usuarios. 

• Administradores de las operaciones. 

El analista necesita: 

Los detalles de las funciones actuales del sistema. 

• ¿Quién? Personas 

• ¿Qué? Actividad del negocio, etc. 

• ¿Dónde? Ambiente 

• ¿Cuándo? En qué momento 

• ¿Cómo? De qué manera se desarrollo 

2.6.1.3. ANÁLISIS DE LAS NECESIDADES DEL SISTEMA 

El Análisis, Modela los requerimientos del usuario. 

DEFIICIÓ 

Proceso que sirve para recopilar e interpretar 

los hechos. 

Diagnostica problemas y utiliza estos hechos 

para mejorar el sistema. 

QUIE LO REALIZA 

El analista. 


Análisis de las necesidades 

del sistema 

TOMA DE DECISIÓ 

Naturaleza de los programas a construir. 

Comprender ámbito o enlace o alcance de 

la información a manejar. 

Función y protocolos requeridos. 

Documentar requisitos. 

Revisar con el cliente. 

DEFIE 

Papel de cada elemento, de cada parte del 

Sistema de Información. 

Asignar a la computadora el papel a desempeñar 

y en decir en que no tendrá inherencia.


NECESIDADES BÁSICAS 

Los analistas estructuran sus investigaciones al buscar respuestas a las siguientes preguntas: 

• ¿Cuál es el proceso básico de la empresa? 

• ¿Qué datos utiliza y produce este proceso? 

• ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo? 

• ¿Qué controles de desempeño utiliza? 

Comprensión del proceso 

Los analistas hacen preguntas que, cuando reciben respuestas, proporcionan antecedentes sobre 

detalles fundamentales relacionados con el sistema y que sirve para describirlo. Las siguientes 

preguntas son de utilidad para adquirir la comprensión necesaria: 

• ¿Cuál es la finalidad de esta actividad dentro de la empresa? 

• ¿Qué paso se siguen para llevarla a cabo? 

• ¿Dónde se realizan estos pasos? 

• ¿Quiénes lo realizan? 

• ¿Cuánto tiempo tardan en efectuarlo? 

• ¿Con cuanta frecuencia lo hacen? 

• ¿Quiénes emplean la información resultante? 

ALCACES 

Analizar requisitos. 

Determinar requisitos. 

Estimar costos. 

Diferentes tareas. 

Planificar por programas. 

Actividades. 

PLATEAMIETO 

DEL PROBLEMA 

De Factibilidad: Objetivos 

Factibilidad Económica 

Es conveniente llevar a efecto el: proyecto 

Factibilidad Técnica 

Disponemos de los recursos y de las herramientas técnicas y metodológicas para desarrollar el 

proyecto. 

Factibilidad Operacional 

Disponemos de los recursos humanos y de la decisión necesaria para operar el SI, solución. 


Análisis de las necesidades 


FACTIBILIDAD 

Económica. 

Operativa. 

Técnica. 

HERRAMIETAS 

Diagrama de flujo de datos (E-PRO-S). 

Diccionario de datos. 

Análisis de las decisiones (condiciones, acciones y 

reglas). 

Estructurados. 

Semiestructurados (Árbol de decisión, tabla de 

decisión, Español estructurado). 

Criterios múltiples. 

PREPARA 

Una propuesta del sistema 

que sumará lo encontrado. 

Análisis costo beneficio 

de las alternativas.



Deben ser calificados 

Definir objetos con entrevistas 

Evaluación 

Determinación Valoración de la 

de factibilidad factibilidad 

Determinar razones: 

Factibilidad Técnica 

Factibilidad Económica 

Factibilidad Operacional 

La realizan: 

Administradores 

Encargados (usuarios) 

Analistas 

El estudio de factibilidad debe estar altamente comprendido en tiempo, comprendiendo 

varias actividades en un pequeño lapso. 

2.6.1.4. DISEÑO 

Cifrado de 

proyectos 

inconsistentes. 

Técnicamente 

imposibles. 

Económicament 

e rentables. 

Se modela la solución del sistema, teniendo en cuenta el ambiente de implementación a utilizar, por 

ejemplo, si el sistema es centralizado o distribuido, la base de datos a utilizar, lenguaje de 

programación, performance deseada, etc. 

• Usa la información recolectada anteriormente para hacer el diseño lógico de S1 (pseudo 

código, DF, etc.). 

• Diseña procedimientos precisos para la captura de datos (diseño de entradas). 

• Proporciona entrada efectiva para el sistema de información mediante el uso de técnicas 

para el diseño de formas y pantallas 

• Diseña la interfaz del usuario (teclado, menú de pantalla y ratón) 

• Diseño de salidas 

• Diseño de base de datos 

• Diseño de archivo 

• Diseño de control y respaldo, etc. 

MANEJO DEL PROCESO DE DISEÑO PARA APLICACIONES INSTITUCIONALES 

El manejo del proceso de diseño significa tomar los pasos necesarios para que el esfuerzo de 

desarrollo avance en forma apropiada y produzca los resultados esperados 

¿QUE CARACTERÍSTICAS SE DEBEN DISEÑAR? 

Los componentes de un sistema de información descritos durante el análisis de requerimientos son 

el punto focal del diseño de sistemas. 

• Flujos de datos. Movimientos de datos hacia, alrededor y desde el sistema. 

• Almacenes de datos. Conjunto temporales o permanentes de datos. 

• Procesos. Actividades para aceptar, manejar y suministrar datos e información. 

• Procedimientos. Métodos y rutinas para utilizar el sistema de información y lograr con ello 

los resultados esperados.


• Controles. Estándares y lineamientos para determinar si las actividades que están ocurriendo 

en la forma anticipada o aceptada. 

• Funciones del personal. Las responsabilidades de todas las personas que tiene que ver con el 

nuevo sistema, incluyendo los usuarios, operadores d computadora y personal de apoyo. 


DISEÑO DE SALIDAS 

Cuando diseñan la salida, los analistas deben realizar lo siguiente: 

• Determinar qué información a presentar. 

• Decidir si la información será presentada en forma visual, verbal o impresa y seleccionar el 

medio de salida. 

• Disponer la presentación en un formato aceptable. 

• Decidir cómo distribuir la salida entre los posibles destinatarios. 

DISEÑO DE ARCHIVOS 

• Los datos que deben incluirse en el formato de los registros contenidos en el archivo. 

• La longitud de cada registro, con base en las características de los datos que contiene. 

• La secuencia a disposición de los registros dentro del archivo (la estructura de 

almacenamiento que puede ser secuencia, indexada o relativa). 

• Tal vez la nueva aplicación necesite hacer referencia sólo al archivo maestro. 

DISEÑO DE INTERACCIÓN CON LA BASE DE DATOS 

• En estos casos, el analista de sistemas no afecta el diseño de la base de datos sino que 

consulta al administrador. 

• A su vez el papel del administrador de base de datos incluye las siguientes responsabilidades: 

Evaluar la conveniencia de la solicitud del analista. 

Describir los métodos para interactuar con la base de datos. 

Asegurar que la aplicación no pueda dañar la base de datos o que la afecte de 

manera adversa a las necesidades de otros sistemas de información. 

DISEÑO DE LA ENTRADA 

• Los analistas de sistemas deciden los siguientes detalles del diseño de entradas: 

1. Que datos ingresan los sistemas. 

2. Que medios utilizar. 

3. La forma en que se debe disponer o codificar los datos. 

4. El diálogo que servirá de guía a los usuarios para dar entrada a los datos. 

5. Validación necesaria de datos y transacciones para detectar errores. 

6. Métodos para llevar a cabo la validación de las entradas y los pasos a seguir cuando 

se presentan errores. 

• Las decisiones de diseño para el manejo de entradas especifican la forma en que serán 

aceptados los datos para su procesamiento por computadora.


2.6.1.5. DESARROLLO Y DOCUMENTACIÓN DEL SOFTWARE (PROGRAMACIÓN O DESARROLLO DEL 

SOFTWARE) 

Las representaciones del diseño deben ser traducidas a un lenguaje artificial, dando como resultado 

unas instrucciones ejecutadas por la computadora el paso de la codificación es el que lleva a cabo esa 

traducción, aquí el analista trabaja con los programadores para desarrollar cualquier SW original que 

se necesite. 

Identificar 

• Ambiente operativo 

• Lógica de los programas 

• Elección del lenguaje de programación 

Tipo de documentación 

• Se desarrollan a lo largo del ciclo. 

• Asegura que toda información del software este disponible. 

• Ofrece confiabilidad a usuarios. 

• Permite facilidad para dar mantenimiento al sistema y que este siga creciendo. 

Entre la documentación que se presenta con un sistema desarrollado es: 

• Manual del usuario 

• Manual de programación 

• Manual del sistema 

Incluye 

• Diagrama estructurado 

• DF ( diagramas de flujo) 

2.6.1.6. PRUEBAS Y MANTENIMIENTO 

Antes de implementar se debe tomar en cuenta: 

• Prueba. 

• Verificación y validación. 

• Certificación/ confirmación que el programa está bien hecho. 

Pruebas 

• El sistema se emplea de manera experimental para asegurarse de que el software no falle, de 

acuerdo a las especificaciones y en la forma que los usuarios esperaban. 

• Se prueban con conjuntos de datos y se examinan las salidas. 

• Las pruebas son conducidas por personal ajeno al grupo desarrollador para asegurar que 

dichas pruebas sean imparciales. 

• Los programas de computación deben ser modificados, mantenidos y actualizados. La 

cantidad promedio del tiempo y gastado en mantenimiento en una instalación del sistema de 

información gerencial (MIS) es de 40% al 60%. 

• En esta etapa se verifica y valida el sistema. 



PRUEBA 

CARACTERÍSTICAS 

Antes de usar el software 

debe probarse. 

Disminuye problemas 

antes de la entrega del 

software. 

2.6.1.7. IMPLEMENTACIÓN Y EVALUACIÓN 

• La implantación.- es el proceso de verificar e instalar el nuevo equipo, entrenar a los 

usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para 

utilizarla. 

• La evaluación se lleva a cabo mirando cuatro dimensiones 

a. Evaluación Operacional: valora la forma en que funciona el sistema incluyendo: 

facilidad de uso, nivel de utilización, tiempo de respuesta de respuesta 

b. Impacto Organizacional: identificación y medición de los beneficios para la 

organización 

c. Opinión de los administradores 

d. Rendimiento del Desarrollo: de acuerdo con los criterios como: tiempo y esfuerzo de 

desarrollo, valorización de los métodos y herramientas utilizadas. 


6ª. Fase 

Prueba y mantenimiento del 

sistema. 

TIPOS 

Prueba con datos de 

ejemplo. 

Prueba con datos reales 


RAZOES 

Corregir errores del SW para mejorar la 

capacidad del SW en respuesta a las 

necesidades de la organización. 

. 

CAPACITACIÓ 

Entrenamiento de los usuarios 

para manejar el sistema. 

Involucra a los operadores y 

usuarios. 

Una mala capacitación puede 

producir errores de usuarios. 

Séptima fase 

Implantación y evaluación 


FORMAS 

Programadores solo. 

Analistas y 

programadores. 

MATEIMIETO 

Es efectuado a lo largo de 

la vida del sistema de 

información. 

EVALUACIÓ O REVISIÓ (Después de la 

implantación) 

Determinar si el sistema cumple con las 

expectativas donde son necesarias las mejoras. 

COVERSIÓ 

Proceso de cambiar un sistema a una nuevo. 

Anticipar los problemas más comunes: 

Sistema paralelo. 

Conversión directa. 

Enfoque piloto. 

Sistema por etapas.


2.6.1.8. FASES DE DESARROLLO DE UN PROYECTO 



2.7. LA EVALUACIÓN DE SOFTWARE EDUCATIVO 

La evaluación de los programas educativos es un proceso que consiste en la determinación del grado 

de adecuación de dichos programas al contexto educativo. Cuando el programa llega al docente, es 

de suponer que ha sido analizado y evaluado tanto en sus aspectos pedagógicos y didácticos, como 

en los técnicos que hacen a la calidad del producto desarrollado según ciertas pautas de garantía de 

calidad. 

Básicamente, se realizan las evaluaciones interna y externa del software, a fin de detectar los 

problemas que generarán cambios en el producto, lo antes posible, a fin de reducir costos y 

esfuerzos posteriores. Estas evaluaciones consideran las eventuales modificaciones sugeridas por el 

equipo de desarrollo y por los usuarios finales, teniéndose en cuenta a docentes y alumnos en el 

contexto de aprendizaje. 

Cuando un producto del tipo comercial educativo, llega al docente, significa que ha superado las 

etapas de evaluaciones interna y externa. Además para obtener el grado de eficacia y de eficiencia 

del producto se deberá realizar una evaluación en el contexto de uso. 

Es preciso definir ciertos “criterios” para seleccionar un programa como “de acuerdo a las 

necesidades del docente”, y se debe considerar el uso de los vocablos evaluación y valoración que en 

muchos de los trabajos consultados se usan indistintamente para determinar si un programa dado 

cumple con los objetivos tanto técnicos como pedagógicos y didácticos para lo que fue pensado. 

2.7.1. LA EVALUACIÓN INTERNA 

De acuerdo a lo expuesto anteriormente, se deberá llevar a cabo una evaluación interna del 

software, [Marqués, 1995] que estará a cargo de los miembros del equipo de desarrollo (que se 

realiza al obtener la versión alfa) y otra evaluación externa en la que participan profesores y alumnos 

destinatarios del programa, cuando se haya terminado el mismo, o esté casi listo. 

Algunos autores como Marqués [1995] consideran que se pueden contemplar tres aspectos 

fundamentales en la evaluación en general: aspectos técnicos, pedagógicos y funcionales. 

LOS ASPECTOS TÉCNICOS.- permitirán asegurar la calidad del producto desde el punto de vista 

técnico específicamente, pudiéndose realizar un análisis estructural de elementos tales como el 

diseño de pantallas y la interface de comunicación. 

LOS ASPECTOS PEDAGÓGICOS.- son aquellos que se refieren al fin con el que el software será 

utilizado. Por ello hay que analizar elementos como: los objetivos educativos, los contenidos y los 

caminos pedagógicos, que se deben considerar en toda buena programación didáctica. 

LOS ASPECTOS FUNCIONALES.- habría que considerar cuales son las ventajas que da al profesor 

como material didáctico y cómo facilita los aprendizajes de los alumnos. 

Bork [1986], denomina a esta evaluación interna como formativa, o sea la evaluación del proceso, 

como aquella realizada generalmente por los desarrolladores. 

Para realizar las evaluaciones se utilizan listas de control o checklists, mediante planillas o plantillas 

de checklists y casillas de verificación, incluyendo no sólo preguntas cerradas, sino preguntas abiertas 

sobre diversos aspectos del programa. Estos resultados son los que necesita el equipo desarrollador 

hacer todos los cambios necesarios y convenientes. Luego de producidos los cambios, se agregarán 

los efectos faltantes (como sonido, animaciones, imágenes y gráficos) y la carga de la base de datos, 

para proceder a emitir una versión denominada beta. [Marqués, 1995] 

La documentación es un proceso que se realiza paralelamente durante todo el desarrollo del 

programa, y también deberá ser evaluada externamente, junto con el programa. 



2.7.2. LA EVALUACIÓN EXTERNA 

La evaluación externa permite obtener sugerencias de los alumnos, quiénes serán en definitiva los 

usuarios del software y de los docentes que lo utilizarán como material didáctico. Durante este tipo 

de pruebas, se encuentran errores imprevistos no detectados y se verifica el cumplimiento de los 

programas con los objetivos educativos que se han considerado en el diseño. 

Alfred Bork [1986] la denomina evaluación sumativa y es la evaluación del producto final que 

generalmente la realizan equipos distintos a los desarrolladores. La información se recoge mediante 

checklists y preguntas cerradas y abiertas a contestar luego de interactuar con el programa, durante 

un tiempo predeterminado. 

En casi todas las investigaciones consideradas se denota la falta de herramientas de evaluación 

sencillas y de documentación de los programas educativos. 

Como resultado de ambas evaluaciones, se obtendrá la primera versión del programa con su 

respectivo manual de usuario, conteniendo todos los aspectos que se consideren indispensables para 

el uso docente, con detalles técnicos, y del entorno pedagógico y didáctico en el que se desarrolló el 

programa. 

2.7.3. LOS INSTRUMENTOS DE EVALUACIÓN 

En general, los instrumentos más usados, son los cuestionarios de valoración, donde las respuestas a 

estos cuestionarios son valoradas entre 0 y 5, por ejemplo, siendo el resultado el grado de 

conformidad del usuario con las afirmaciones propuestas. 

Los instrumentos de evaluación, en forma de planillas se deben confeccionar con inclusión de 

preguntas del tipo cerradas, abiertas, y casillas de verificación, permitiendo al usuario final la 

descripción de aspectos problemáticos y particulares del programa que no hayan sido tenidos en 

cuenta durante la confección del instrumento. Se deberá tener en cuenta al redactar los 

cuestionarios la utilización de un vocabulario adecuado, sin ambigüedades y claro para los 

destinatarios previstos en cada caso en particular. En la mayor parte de los cuestionarios relevados 

se consideran algunos aspectos claves o sobresalientes: como el logro de los objetivos, los aspectos 

técnicos, el desarrollo de contenidos, actividades y la documentación. Estos aspectos se categorizan 

en ítems, según cada propuesta. 

Como cada propuesta de evaluación de software es particular, se deben analizar con cuidado las 

diferentes propuestas de evaluación de medios didácticos y en particular de software educativo, 

teniéndoselas sólo como una “guía” que luego se deberá “readaptar” a cada contexto educativo 

particular. 



2.8. LA RESPONSABILIDAD Y LA ÉTICA PROFESIONAL APLICADA A LA CARRERA 

Este es un marco de referencia para saber que el docente informática educativa al igual que el 

Ingeniero debe aplicar un código de ética profesional. 

Como otras disciplinas de la ingeniería, la ingeniería del software educativo se lleva a cabo 

dentro de un marco legal y social que limita la libertad de los ingenieros. Los ingenieros de 

software deben aceptar que su trabajo comprende responsabilidades más amplias que 

simplemente la aplicación de habilidades técnicas. Deben comportarse de una forma ética y 

moral responsable si desean ser respetados como profesionales. 

No basta con decir que usted siempre debe poseer estándares normales de honestidad e 

integridad. No debería utilizar su capacidad y sus habilidades para comportarse de forma 

deshonesta o de forma que deshonre la profesión de ingeniería de software. Sin embargo, 

existen áreas donde los estándares de comportamiento aceptable no están acotados por las 

leyes, sino por la más tenue noción de responsabilidad profesional. Algunas de estas son: 

1. Confidencialidad. Usted normalmente debe respetar la confidencialidad de sus 

empleadores o clientes independientemente de que se haya firmado un acuerdo formal de 

confidencialidad. 

2. Competencia. No debe falsificar su nivel de competencia, ni aceptar conscientemente 

trabajos que están fuera de su capacidad. 

3. Derechos de propiedad intelectual. Debe ser consciente de las leyes locales que gobiernan 

el uso de la propiedad intelectual, como las patentes y el copyright. Debe asegurarse de 

que la propiedad intelectual de los empleadores y clientes está protegida 

4. Uso inapropiado de las computadoras. No debe emplear sus habilidades técnicas para 

utilizar de forma inapropiada las computadoras de otras personas. El uso inapropiado de 

las computadoras va desde los relativamente triviales (utilizar juegos en la máquina de un 

empleado, por ejemplo) hasta los extremadamente serios (difusión de virus). 

Las sociedades e instituciones profesionales tienen que desempeñar un papel importante en el 

establecimiento de estándares éticos. Organizaciones como la ACM, el IEEE (Instituto de 

Ingenieros Eléctricos y Electrónicos) y la British Computer Society publican un código de 

conducta profesional o de ética. Los miembros de estas organizaciones se comprometen a 

cumplir ese código cuando se inscriben en ellas. Estos códigos de conducta generalmente se 

refieren al comportamiento ético fundamental. 

La ACM y el IEEE han cooperado para crear un código de ética y práctica profesional. Este 

código existe en forma reducida, como se muestra en la Figura 1.6, y en forma extendida, la 

cual agrega detalle y sustancia a la versión reducida. El fundamento sobre el que se asienta 

este código se resume en los primeros párrafos de la versión extendida: 

Las computadoras tienen un papel central y creciente en el comercio, la industria, el 

gobierno, la medicina, la educación, el entretenimiento y la sociedad en general. Los 

ingenieros de software son aquellos que contribuyen con su participación directa o por 

su enseñanza, al análisis, especificación, diseño, desarrollo, certificación, 

mantenimiento y pruebas de los sistemas de software. Debido a sus papeles en el 

desarrollo de sistemas de software, los ingenieros de software tienen significativas 

oportunidades de hacer bien o causar daño, permitir que otros hagan el bien o causen 

daño, o influir en otros para hacer el bien o causar daño. Para asegurar, tanto como 



sea posible, que sus esfuerzos serán utilizados para bien, los ingenieros de software 

deben comprometerse consigo mismos para hacer de la ingeniería del software una 

profesión de beneficio y respeto. De acuerdo con este compromiso, los ingenieros del 

software deben cumplir el siguiente Código de Ética y Práctica Profesional. 

Código de Ética y Práctica Profesional de la Ingeniería del Software 

ACM/IEEE-CS Fuerza de Tarea Conjunta sobre Ética y Práctica Profesional en la Ingeniería del 

Software 

PREÁMBULO 

La versión corta del código resume las aspiraciones en un alto nivel de abstracción. Las 

cláusulas que se incluyen en la versión completa proporcionan ejemplos y detalles de cómo 

estas aspiraciones cambian la forma en que actuamos como profesionales de la ingeniería del 

software. Sin las aspiraciones, los detalles pueden llegar a ser solo términos jurídicos tediosos; 

sin los detalles, las aspiraciones pueden llegar a ser altisonantes pero vacías; juntas, las 

aspiraciones y los detalles forman un código cohesivo. 

Los ingenieros de software deben comprometerse consigo mimos para hacer el análisis, la 

especificación, el diseño, el desarrollo, las pruebas y el mantenimiento del software una 

profesión beneficiosa y respetada. En concordancia con su compromiso con la salud, la 

seguridad y el bienestar del público, los ingenieros de software deben adherirse a los ocho 

principios: 

1. PÚBLICO.- Los Ingenieros de software deberán actuar en concordancia con el interés 

público. 

2. CLIENTE Y EMPLEADOR.- Los Ingenieros de software deberán actuar de forma que 

respondan a los intereses de sus clientes y empleadores siendo consecuentes con el 

interés público. 

3. PRODUCTO.- Los Ingenieros de software deberán asegurar que sus productos y las 

modificaciones asociadas cumplan los más altos estándares profesionales posibles. 

4. JUICIO.- Los Ingenieros de software deberán mantener la integridad e independencia de 

sus juicios profesionales. 

5. GESTIÓN.- Los gerentes y líderes ingenieros de software deberán suscribir y promocionar 

un enfoque ético en la gestión del desarrollo y mantenimiento del software. 

6. PROFESIÓN.- Los Ingenieros de software deberán mantener la integridad y reputación de 

la profesión de acuerdo con el interés público. 

7. COLEGAS.- Los Ingenieros de software deberán ser imparciales y apoyar a sus colegas. 

8. PERSONAL.- Durante toda su existencia, los Ingenieros de software deberán aprender lo 

concerniente a la práctica de su profesión y promocionar un enfoque ético en la práctica 

de su profesión. 

Código de Ética de la ACM/IEEE 

El código contiene ocho principios relacionados con el comportamiento y con las decisiones 

hechas por los ingenieros de software profesionales, incluyendo practicantes, educadores, 

administradores, supervisores y creadores de políticas, así como aprendices y estudiantes 

de la profesión. Los principios identifican las relaciones éticas en las que otros individuos, 

grupos y organizaciones participan, y las obligaciones primarias dentro de estas relaciones. 

Las cláusulas de cada principio son ilustraciones de algunas de las obligaciones incluidas en 

estas relaciones. Estas obligaciones se fundamentan en la humanidad del ingeniero de 



software, con especial cuidado en la gente afectada por el trabajo del los ingenieros de 

software, y los elementos únicos de la práctica de la ingeniería de software. El código 

prescribe estas como obligaciones de cualquiera que se llame o que aspire a ser un 

ingeniero de software. 

En cualquier situación en las que diferentes personas tienen distintos puntos de vista y 

objetivos, es posible encontrar problemas éticos. Por ejemplo, si usted está en desacuerdo, en 

principio, con las políticas de un directivo de categoría superior en la compañía, como debería 

reaccionar. Desde luego, esto depende de cada individuo y de la naturaleza de discordancia, 

Es mejor argumentar a favor de su posición dentro de la organización o renunciar de acuerdo 

con sus principios. Si piensa que existen problemas con un proyecto de software, cuantos se 

deben comunicar estos al gerente. Si estos se discuten cuando son solo una sospecha, puede 

ser una sobre la reacción a la situación, si lo deja para más tarde, puede ser imposible resolver 

las dificultades. 

Tales problemas éticos aparecen en nuestra vida profesional y, afortunadamente, en muchos 

caso son relativamente menor eso se pueden resolver sin mucho dificultad. Cuando no se 

pueden resolver los ingenieros se enfrentaran, quizás, con otro problema. La acción con base a 

sus principios podría ser renunciar a su trabajo, pero esto puede afectar a otros, por ejemplo, a 

sus colaboradores o a sus hijos. 

Una situación particularmente difícil para los ingenieros profesionales surge cuando su 

empleador actúa de una forma no ética. Por ejemplo, una compañía es responsable de 

desarrollar un sistema crítico de seguridad y, debido a las presiones de tiempo, falsita la 

validación de protección de los registros. 

Es responsabilidad del ingeniero mantener la confidencialidad o alertar al cliente o hacer 

público, de alguna forma, que el sistema entregado es inseguro. 

El problema aquí es que no existen absolutos cuando se trata de protección. Aun cuando el 

sistema no haya sido validado de acuerdo con los criterios predefinidos, éstos pueden ser 

demasiado estrictos. El sistema puede, de hecho, operar de forma segura a través de su 

tiempo de vida. Pero puede darse el caso de que, aun cuando sea validado apropiadamente, el 

sistema falle y cause un accidente. El descubrimiento temprano del problema puede resultar 

perjudicial para el empleador y otros empleados, la falta de descubrimiento de problemas 

puede resultar perjudicial para otros. 

Debe tomar su propia decisión en estos temas. La posición ética apropiada depende 

enteramente del punto de vista de los individuos que están involucrados. En este caso, el 

potencial para el daño, el grado del daño y la gente afectada por el deben influir en la decisión. 

Si la situación es muy peligrosa se justifica su publicación en la prensa nacional (por ejemplo). 

Sin embargo, se debe tratar de resolver la situación respetando los derechos del empleador. 

Otra cuestión ética es la participación en el desarrollo de sistemas militares y nucleares. 

Algunas personal tienen una opinión firme sobre estos temas y no desean participar en ningún 

desarrollo de sistemas asociados con sistemas militares. Otros trabajaran en sistema militares, 

pero no en sistemas de armamento. Algunos otros sentirán que la defensa de la nación es un 

principio fundamental y no tienes objeciones éticas para trabajar en sistemas de armamento. 

En esta situación, es importante que tanto empleadores como empleados se hagan saber con 

anticipación sus puntos de vista. Cuando una organización está relacionada con el trabajo 

militar o nuclear, le debe ser posible especificar si los empleados pueden aceptar cualquier 

tarea. De igual forma, si un empleado hace patente que no pueda trabajar en tales sistemas, 

los empleadores no deben presionarlo posteriormente. 



El área de ética y responsabilidad profesional ha recibido creciente atención en los pasados 

años. Los principios de ética se pueden considerar desde un punto de vista filosófico, y la ética 

de la ingeniería de software se debe tratar con referencia a estos principios básicos. Este es el 

enfoque considerado por Laudon (Laudon, 1995) y, de forma menos extensa, Huff y Martin 

(Huff y Martin, 1995). 

Sin embargo, este enfoque me resulta abstracto y difícil de relacionar con mi experiencia 

diaria. Prefiero un enfoque más concreto y comprendido en códigos de conducta y practica. 

Creo que la ética se analiza mejor en un contexto de ingeniería de del software y no como un 

tema por sí solo. Por lo tanto no incluiré consideraciones éticas abstractas sino que, donde sea 

apropiado, incluiré ejemplos en los ejercicios que puedan servir de punto de partida para una 

discusión ética.

MÓDULO IV - Universidad Nacional de Loja

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?