ANALISIS DE NECESIDADES EDUCATIVAS

La creación de ambientes enseñanza-aprendizaje apoyados con computador tiene sentido si responde a las necesidades educativas prioritarias y relevantes y no existe otra solución que las satisfaga. Pero ¿qué es una necesidad educativa?, ¿cómo se determinan las necesidades educativas?

1.1. NECESIDADES EDUCATIVAS

Se concibe una necesidad educativa como la discrepancia entre un estado educativo ideal (deber ser) y otro existente (realidad). Por consiguiente su determinación debe llegar a resolver tres interrogantes:

- ¿Qué es lo ideal?

- ¿Qué de esto se puede satisfacer con lo que existe?

- ¿Qué falta por alcanzar? (la necesidad)

1.2. Identificar y clasificar las necesidades educativas

Para ello se pueden considerar varios tipos de necesidades educativas:

1.2.1 Necesidad Normativa: se toma como "ideal" una norma o patrón existente, se determina en qué medida la población objeto del sistema educativo alcanza dicho estándar y se establece la diferencia con el patrón; por ej., el desempeño de los estudiantes es inferior al promedio nacional.

1.2.2 Necesidad Sentida: Es sinónimo de un deseo de saber algo, por lo tanto debe saberse qué quiere aprender la gente, para qué y por qué; surgen al interactuar con usuarios potenciales o con quienes conocen las necesidades de éstos.

1.2.3 Necesidad expresada o demanda: ésta es similar a la idea económica de que si la gente necesita algo, lo solicitará. Esto sucede cuando la gente solicita o se inscribe en un curso o seminario; estos datos suelen ser conocidos por los administradores de programas académicos.

1.2.4. Necesidad Comparativa: Se da cuando sirve de "ideal" otra población objeto, similar a la que es de interés, cuyos niveles de logro son más altos o trabaja en áreas novedosas. Por ej., una Institución líder en un área marca la pauta y otras la toman como referencia.

1.2.5. Necesidad Futura o Anticipada: Resulta de preveer las necesidades que se demandarán en el futuro, con base en el seguimiento a los planes de desarrollo relacionados, así como a los avances científicos y tecnológicos. En buena medida sirve para revisar y ajustar los estados "ideales" de tipo normativo con base en la proyección del entorno social, científico y tecnológico.

2.  DETERMINAR FUENTES DE INFORMACIÓN Y SOLUCIONES DE LAS NECESIDADES EDUCATIVAS

2.1. ANALISIS DE ALTERNATIVAS DE SOLUCION

Por el hecho de saber que hay problemas y a qué se deben, no se deduce necesariamente que la solución será un apoyo computarizado. Esto se recomendará cuando no haya ningún medio alterno capaz de subsanar la deficiencia.

2.2. SOLUCIONES ADMINISTRATIVAS

Algunos problemas o necesidades se pueden resolver tomando decisiones administrativas tales como conseguir o capacitar profesores, dedicar más tiempo al estudio de algo -y menos a otra cosa-, conseguir los medios y materiales que hagan posible disponer de los ambientes de aprendizaje apropiados, así como capacitar a los profesores en el uso de estos nuevos medios. Igualmente si los estudiantes no traen los conocimientos de base, pueden tomarse medidas administrativas como impedir que avancen en el currículo hasta tanto no se nivelen, u ofrecerles oportunidades para instrucción remedial. La administrativa es una primera alternativa a considerar.

2.2.1 SOLUCIONES ACADEMICAS

Algunas soluciones se podrán llevar a la práctica a partir del profesor y de su interacción con los alumnos, como cuando se trata de promover mayor trabajo individual de los estudiantes sobre los materiales para aprendizaje, cuando se trata de preparar nuevas ayudas educativas o de mejorar la calidad de las pruebas académicas.

Otras requerirán mejoras a los medios y materiales de enseñanza convencionales, como son los materiales impresos, guías de estudio, así como los materiales y las guías de trabajo o de laboratorio. Habrá otros medios no tan convencionales que sería conveniente usar, como son los que van ligados a las prácticas.

Es importante considerar la viabilidad del medio, toda vez que algunos que son ideales, pero que en la realidad no se puede disponer de ellos por efectos de costos o de riesgo, o por efectos de practicidad.

Dentro de las causas que exigen decisiones académicas habrá algunas imposibles de atender con medios no informáticos, quedando la perspectiva de utilizar este apoyo.

Problemas de motivación pueden atacarse creando micromundos que sean excitantes y significantes para los aprendices, cuya exploración conlleve adentrarse en el contenido de aquello que interesa aprender, o en los que se puede practicar una destreza hasta lograr un amplio nivel de dominio.

Pero también se pueden simular eventos o actividades que normalmente no están a disposición del aprendiz, en los que se pueden tomar decisiones y ver el efecto de ellas, sin que esto conlleve peligros, exija estarse toda una vida esperando resultados o demande costos excesivos.

Es posible, asimismo, obtener información de retorno diferencial dependiendo de lo que uno hace, explicación sobre las reglas que rigen el comportamiento del sistema o hacer seguimiento razonado a las acciones que condujeron a una situación final.

Todo esto a ritmo y secuencia propios, sin que la máquina se canse ni lo regañe a uno por avanzar más rápido o despacio que los demás, por ensayar todas las opciones, por insistir en necesidades, etc.

3. APLICAR LA METODOLOGÍA DE ANÁLISIS PARA DETERMINAR NECESIDADES EDUCATIVAS QUE REQUIEREN APOYO INFORMÁTICO

3.1. SOLUCIONES CON APOYO INFORMÁTICO

Cuando se ha determinado la conveniencia de contar con un apoyo informático para resolver un problema o un conjunto de ellos, dependiendo de las necesidades que fundamentan esta decisión, cabe optar por un tipo de apoyo informático u otro.

Habrá necesidades que se pueden resolver usando herramientas informáticas de productividad. Por ejemplo, si interesa que los alumnos desarrollen sus habilidades de expresión verbal, o de expresión gráfica y que se concentren en lo que generan antes que en la forma como lo generan, siendo editable lo que hagan, el uso del procesador de texto, o de un procesador gráfico, pueden ser la solución más inmediata y adecuada. Si de lo que se trata es de facilitar el procesamiento de datos numéricos para que de este modo pueden concentrase en el análisis de los resultados procesados, una hoja de cálculo electrónico será un magnifico apoyo. Si interesa que los alumnos puedan alimentar, consultar, cruzar y analizar datos que cumplen ciertos criterios, en un sistema manejador de bases de datos se tendrá un magnifico aliado.

Pero si las posibilidades que brindan las herramientas de propósito general no son adecuadas o suficientes, habrá que pensar en qué otro tipo de ambiente educativo informático es conveniente.

Tratándose de necesidades educativas relacionadas con el aprendizaje, según la naturaleza de éstas se podrá establecer qué tipo de MEC conviene usar.

3.1.2. Un sistema tutorial se amerita cuando, siendo conveniente brindar el conocimiento al alumno, también interesa que lo incorpore y lo afiance, todo esto dentro de un mundo amigable y ojalá entretenido.

3.1.3. Pero si sólo se trata de afianzar los conocimientos que adquirió el aprendiz por otros medios, puede pensarse en un sistema de ejercitación y práctica que conlleve un sistema de motivación apropiado a la audiencia, o en el uso de un simulador para practicar allí las destrezas y obtener información de retorno según las decisiones que tome el aprendiz.

3.1.4. Un simulador podrá usarse también para que el aprendiz llegue al conocimiento mediante trabajo exploratorio, conjetural y mediante aprendizaje por descubrimiento, dentro de un micro mundo que se acerca, en su comportamiento, razonablemente a la realidad o aquello que intenta modelar.

3.1.5. Un juego educativo será conveniente cuando, ligado al componente lúdico, interesa desarrollar algunas destrezas, habilidades o conceptos que van integrados al juego mismo.

3.1.6. Los sistemas expertos se ameritarán cuando el conocimiento que se desea aprender es el de un experto en la materia, que no siempre está bien definido o es incompleto, y combina reglas de trabajo con reglas de raciocinio. Por consiguiente, no se puede encapsular rígidamente, ni se puede transmitir en forma directa; se requiere interactuar con ambientes vivenciales que permitan desarrollar el criterio del aprendiz para la solución de situaciones en la forma como lo haría el experto.

3.1.7. Un sistema tutorial inteligente se ameritará cuando, además de desear alcanzar un nivel de experto en un área de contenido, interesa que el MEC asuma, adaptativamente, las funciones de orientación y apoyo al aprendiz, en forma semejante a como lo haría un experto en la enseñanza del tema.

3.1.8. Sistema Multimedia: es un programa de computador que utiliza diferentes medios como videos, gráficos, texto, etc. Puede ser interactivo o simplemente presentar información

4. ACTIVIDAD PRÁCTICA PARA DETERMINAR LAS NECESIDADES EDUCATIVAS QUE CONVENGA UTILIZAR CON APOYOS INFORMATICOS.

1) Especifique el alcance del análisis que va a hacer (toda la Institución, todo el Departamento, tales áreas de contenido, tales niveles de enseñanza) y para cada una de las asignaturas de interés tenga a mano las metas que desea alcanzar, los planes de estudio y recursos que guían su logro.

2) Establezca un marco teórico para el análisis de necesidades educativas considerando las teorías de aprendizaje aplicables a la población, tipo de objetivos y naturaleza del contenido a estudiar, así como los resultados de investigaciones sobre ambientes de enseñanza-aprendizaje y didácticas referentes al caso.

3) Para las asignaturas "nuevas", haga una previsión de los posibles problemas y apoyo informático aplicable, tomando como base el marco teórico.

4) Para las asignaturas que ya se han ofrecido según lo requiere el plan de estudios:

- Analice los problemas existentes a partir de la consulta a las diversas fuentes y produzca una lista priorizada de asignaturas y temas ( u Objetivos) problemáticos de aprender, anotando las fuentes consultadas y la importancia del problema.

- Determine las posibles causas de los problemas detectados, considerando tanto lo que resulta de aplicar el marco teórico al análisis de los ambientes y actividades de aprendizaje utilizadas, como lo que opinan profesores y alumnos participantes.

- Establezca soluciones alternativas de tipo administrativo y académico. Si se sugiere uso de computador, deben quedar documentadas las razones que fundamentan esto, mostrando la insuficiencia de soluciones de otra índole.

- Establezca el papel de la solución computarizada y, en consecuencia, determine si conviene usar una herramienta de productividad o más bien un MEC y de qué tipo de combinación de éstos.

5) Indague qué soluciones informáticas educativas existen para atender los problemas cuya solución conviene que sea apoyada con computador y, si existen, haga una valoración comprensiva y una evaluación por expertos de las mismas.

Dependiendo de los resultados, recomiende las acciones a seguir, y

6) Si no hay soluciones informáticas educativas que satisfagan la problemática detectada, haga un plan de trabajo para hacer desarrollo(s) que lleven a satisfacer las necesidades. Este debe considerar los recursos humanos, físicos y temporales disponibles.

5. DEFINICIÓN Y TIPOS

La metodología que se propone consiste en un proceso iterativo de varias fases las cuales deben llevarse a cabo como lo determina la figura 1. Las cinco etapas que componen esta metodología son Análisis, Diseño, Desarrollo, Evaluación y Administración.

Durante cada una de éstas, se plantean una serie de factores claves de éxito que expone Galvis en los procesos, estos factores son críticos para el éxito del sistema y no se deben descuidar con el fin de evitar que éste fracase.

Así mismo, se indicarán los roles que juega cada miembro del equipo en las diferentes etapas del proceso y además se muestra la importancia de la comunicación en estos ambientes.

6. METODOLOGIA PARA DETERMINAR NECESIDADES EDUCATIVAS QUE

CONVENGA ATENDER CON APOYOS INFORMATICOS

Etapas de la fase de análisis en la metodología para la selección o desarrollo de MECs.

6.1 ANALISIS DE PROBLEMAS EXISTENTES

Como resultado de esta etapa se debe contar con una lista priorizada de problemas en los distintos temas u objetivos de las diferentes materias que componen su área, con anotación de la fuente o evidencia de que existe cada problema y de la importancia de que tiene resolver dicho problema.

En primera instancia, los profesores y los alumnos son fuentes de información primaria para detectar y priorizar aspectos problemáticos; ellos más que nadie saben en qué puntos el contenido, el modo o los medios de enseñanza se están quedando cortos frente a las características de los estudiantes y a los requerimientos del currículo que guía la acción.

Mediante el análisis de los registros académicos frente al contenido de los programas de estudio, será posible saber, para las asignaturas problemáticas, en qué partes del plan de estudio se presentan las mayores dificultades.

También los resultados de las pruebas académicas (exámenes o tareas), cuando estas se han diseñado válidamente, pueden ofrecer una información muy valiosa.

6.2 ANALISIS DE POSIBLES CAUSAS DE LOS PROBLEMAS DETECTADOS

Para poder atender las necesidades o resolver los problemas detectados, es imprescindible saber a qué se deben y que puede contribuir a su solución. En particular interesa resolver aquellos problemas que están relacionados con el aprendizaje, en los que eventualmente un MEC podría ser de utilidad.

Un problema de rendimiento o de aprendizaje puede deberse a muchas razones:

Por una parte, los alumnos pueden no traer los conocimientos de base o carecer de motivación para estudiar el tema. Este factor puede disfrazarse como que no le dedican tiempo o no le dan importancia a la asignatura.

Los materiales, por su parte, pueden ser defectuosos cuando, por ejemplo, traen teoría muy escueta, carecen de ejemplos, tiene ejercicios que están desfasados frente a contenidos y objetivos, su redacción es oscura, las frases muy largas o la terminología es muy rebuscada, cuando no es que se encuentra en otro idioma, así como cuando el formato de presentación es difícil de leer, no traen ilustraciones o ayudas para codificar, etc.

En otros casos los materiales son inexistentes, por limitaciones de la Institución o de los participantes, siendo el profesor la fuente principal de la información y la tiza y el tablero sus únicas ayudas; en tales circunstancias los alumnos toman nota de lo que pueden, y quienes no tienen habilidad para hacerlo, fracasan. Por otra parte, aquellas habilidades que no se pueden lograr de esta forma transmisiva van a quedarse sin aprender debidamente.

El profesor también puede ser una posible causa del fracaso; sus retrasos para asistir a clases cuando no sus ausencias, sin siquiera asignar actividades a los alumnos, quitan oportunidad al estudiante de adquirir y afianzar el conocimiento.

También ocurre esto cuando la preparación del docente es inadecuada o insuficiente para dictar una asignatura que tiene a su cargo, o cuando su motivación hacerlo es mínima.

El tiempo que se le haya dedicado al estudio del tema, o la cantidad y variedad de ejercicios también pueden haber sido insuficientes. La dosificación de las asignaturas, así como la carga que cada una impone sobre el estudiante, en términos de trabajos o actividades, pueden ir en detrimento de algunas asignaturas o temas que luego identifican como problemáticos.

La metodología utilizada o los medios en que se apoya el proceso de enseñanza-aprendizaje, pueden ser inadecuados, como cuando se "dicta clase" magistral cuando lo que se pretende es enseñar destrezas específicas sin realizar la práctica correspondiente.

7. SELECCIÓN O PLANEAMIENTO DEL DESARROLLO DE MECS,

El enriquecimiento de ambientes educativos mediante apoyos informáticos no depende tanto de la disponibilidad de "paquetes", como de la existencia de un clima educacional apropiado, en el que la identificación de problemas y de posibles soluciones sea una labor permanente que competa a todos los miembros de la institución, cada uno desde el ámbito que le corresponde.

En la medida en que haya mente abierta, observación continua de la situación, recursos humanos capaces de innovar, será posible hallar soluciones novedosas, apoyadas o no con computador, a los problemas que se detecten.

La metodología que se propone trata de detectar, en primer lugar, situaciones problemáticas, sus posibles causas y alternativas de solución; una de estas puede ser con apoyo informático y dentro de éstas, un MEC (Material Educativo Computarizado); cuando se justifica esta última, se sugiere bien sea seleccionar entre MECs alternativos aquel que mejor satisfaga la necesidad o, desarrollar una solución que satisfaga plenamente la necesidad detectada.

7.1. METODOLOGIA PARA EL DESARROLLO DE MECs

Para el desarrollo de MECs se trabajarán las etapas de Análisis, Diseño, Desarrollo, Prueba y Ajuste e Implementación que se describirán más adelante; Modelo sistemático para selección o desarrollo de MECs, propuesto por Alvaro Galvis.

Se hará particular énfasis a la solidez del análisis como punto de partida; a las formas de aprendizaje y comunicación humanas como base para el diseño de los ambientes educativos computarizados; la evaluación permanente y bajo criterios predefinidos, a lo largo de todas las etapas del proceso, como medio de perfeccionamiento continuo del material y la documentación adecuada y suficiente de lo que se realiza en cada etapa, como base para el mantenimiento que requerirá el material a lo largo de su vida útil.

8. CICLOS PARA LA SELECCIÓN O EL DESARROLLO DE MECS.

8.1 CICLOS PARA SELECCIONAR O DESARROLLAR MECs

En ambos ciclos ya sea para elegir o desarrollar es necesario identificar las necesidades educativas reales que conviene atender con dicho material computarizado.

8.2 DISEÑO DE MECs

El diseño se obtendrá como resultado que arroje el análisis que previamente se efectuó. Dentro de este proceso se involucran ciertas fases que son las siguientes:

- Entorno para el diseño del MEC. Es necesario hacer explícitos los datos del entorno propio del MEC que se pretende diseñar: usuarios, contenido, necesidad educativa, limitaciones y los recursos (equipo, soporte lógico).

- Diseño educativo del MEC. Es aquí donde entra el objetivo terminar que se deberá de alcanzar, que se realizara para motivar y mantener motivado al usuario, como saber si dicho aprendizaje se está logrando.

- Diseño de comunicación. Es necesario determinar de qué manera se comunicara el usuario con el programa, estableciendo de tal manera los dispositivos de entrada; así como el programa se comunicara con el usuario, mediante que dispositivos.

- Diseño computacional. Aquí entra las funciones que se requieren que cumpla el MEC para cada uno de los tipos de usuarios. Incluyen lógicamente el modulo del profesor así como el del alumno involucrados en la estructura lógica que debe de seguir para poder formular el programa principal y cada uno de los procedimientos.

Determinando finalmente cuales estructuras de datos se requieren en la memoria principal y cuáles de ellos en la memoria secundaria para así cumplir con las funciones definidas.

- Preparación y revisión de un prototipo del MEC. Se aconseja realizar un prototipo ya sea en papel o en la computadora, verificando si realmente satisface las necesidades que se intentan atender.

9. DESARROLLO DEL MECS.

Una vez que ya se dispone del diseño debidamente documentado, es posible llevar a cabo la implementación del mismo, utilizando las herramientas de trabajo, los recursos humanos asignados, para poder cumplir en cuestión de términos de tiempo y calidad del MEC.

- Estrategias para el desarrollo de MECs. Dependiendo de los recursos humanos con los que se cuenten para el desarrollo se puede tomar en cuenta: si se cuenta con un grupo interdisciplinario (especialistas en contenido, metodología e informática), es importante saber que el desarrollo caerá sobre el especialista en informática, pero apoyándose en los demás integrantes sobre la calidad de lo que se está desarrollando y los detalles que Irán surgiendo a lo largo de la programación. Cuando no se cuenta con un especialista en programación será necesario contratar a uno o la otra seria que los integrantes del equipo se animen a usar un lenguaje para elaborar el programa.

- Desarrollo y documentación del MEC. Es necesario programar en una forma estructurada y legible, así como la documentación del trabajo.

- Revisión del MEC mediante juicio de expertos. Es necesario verificar basándose en el diseño, si lo previsto se ha llevado a la práctica. Se aconseja recurrir a especialistas con un perfil equivalente al que participaron en el diseño y desarrollo para que realicen una revisión y que resulte más objetivo.

- Revisión uno a uno con usuarios representativos. Conviene realizar al final una revisión con unos pocos usuarios para asegurar que la interfaz es la adecuada.

Este proceso arrojara tal vez algunos problemas que se tendrán que corregir.

LENGUAJE UNIFICADO DE MODELADO

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, UnifiedModeling Languaje) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

Metas de UML.

Una de las metas principales de UML es avanzar en el estado de la integración institucional proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr un intercambio exitoso de modelos de información entre herramientas, se requirió definir a UML una semántica y una notación.

Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo modelo. Bajo esta definición una herramienta que solo dibuje, no puede cumplir con la notación de UML.

El lenguaje está dotado de múltiples herramientas para lograr la especificación determinante del modelo, pero en nuestro caso se trabaja en forma simplificada sobre:

· Modelamiento de Clases

· Casos de Uso

· Diagrama de Interacción.

· Los diagramas de clases de UML forman la vista lógica.

· Los diagramas de interacción de UML constituyen la vista de proceso.

· La vista de desarrollo captura el software en su entorno de desarrollo.

· Los diagramas de despliegue integran la vista física.

· Los escenarios: el modelo de casos de uso.

Diagramas de visión

UML 2.2 tiene 14 tipos de diagramas de dividirse en dos categorías. Siete tipos de diagramas representan la información estructural, y los otros siete representan

tipos generales de comportamiento, entre ellos cuatro que representan diferentes

aspectos de las interacciones. Estos diagramas pueden clasificarse

jerárquicamente como se muestra en el siguiente diagrama de clases:

UML no limita los tipos de elemento UML a un tipo de esquema determinado. En general, todos los elementos de UML pueden aparecer en casi todos los tipos de diagramas, esta flexibilidad ha sido parcialmente restringida en UML 2.0. Perfiles UML pueden definir los tipos de diagrama adicional o extender los diagramas existentes con anotaciones adicionales.

De acuerdo con la tradición de los dibujos de ingeniería, un uso comentario o nota explicando, coacción, o la intención es permitido en un diagrama UML.

Diagramas de Estructura

Diagramas de estructura hincapié en las cosas que deben estar presentes en el sistema que se modela. Dado que los diagramas de estructura representan la estructura, se utilizan ampliamente en la documentación de la arquitectura de software de sistemas de software.

· Diagrama de clases: se describe la estructura de un sistema por el que muestra las clases del sistema, sus atributos y las relaciones entre las clases.

· Diagrama de componentes: describe cómo un sistema de software se divide en componentes y muestra las dependencias entre estos componentes.

· Diagrama de estructura de material compuesto: se describe la estructura interna de una clase y las colaboraciones que esta estructura hace posible.

· Diagrama de implementación: se describe el hardware utilizado en la implementación de sistemas y los entornos de ejecución y los artefactos desplegados en el hardware.

· Diagrama de objetos: muestra una vista total o parcial de la estructura de un sistema de ejemplo el modelo en un momento determinado.

· Diagrama de paquetes: describe cómo un sistema se divide en agrupaciones lógicas mostrando las dependencias entre estos grupos.

· Diagrama de perfil: opera en el nivel metamodelo para mostrar los estereotipos de las clases con el estereotipo <<stereotype>>, y los perfiles en forma de paquetes con el estereotipo <<perfil>>. La relación de extensión (línea sólida con cerrado, lleno de punta de flecha) indica qué elemento metamodelo un estereotipo determinado se está extendiendo.

Diagrama de clases

 Diagrama de componentes

Diagramas de estructura compuesta

Diagrama de despliegue

Diagrama de objeto

Paquetediagrama

1    UML Diagrama de Actividad

Estado de la máquina diagrama

Diagrama de casos de uso

Los diagramas de interacción

Diagramas de interacción, un subconjunto de los diagramas de comportamiento, hacen hincapié en el flujo de datos y de control de las cosas en el sistema modelado:

· Diagrama de la comunicación: muestra las interacciones entre los objetos o partes en términos de mensajes en secuencia. Que representan una combinación de información tomada de la Clase, Secuencia, y utilizar los diagramas de casos que describen tanto la estructura estática y comportamiento dinámico de un sistema.

· Diagrama de descripción de la interacción: ofrece un panorama en el cual los nodos representan los diagramas de comunicación.

· Diagrama de secuencia: muestra cómo los objetos se comunican entre sí en términos de una secuencia de mensajes. También indica la vida útil de los objetos en relación con los mensajes.

· Diagramas de tiempo: un tipo específico de diagrama de interacción, donde la atención se centra en las limitaciones de tiempo.

Comunicación diagrama

Interacción diagrama general

Diagrama de secuencia

La máquina del Protocolo de Estado es una variante de la sub-máquina de estados.

Se puede utilizar con los protocolos modelo de comunicación de red.

Modelos Meta

 Capacidades de desajuste lenguaje UML y la aplicación.

Como con cualquier sistema de notación, UML es capaz de representar algunos sistemas de forma más concisa y eficiente que otros. Así, un desarrollador gravita hacia soluciones que se encuentran en la intersección de las capacidades de UML y el lenguaje de implementación. Este problema es especialmente agudo si el lenguaje de implementación no se adhiere a la ortodoxia la doctrina orientada a objetos, como la intersección de conjuntos entre UML y el lenguaje de implementación puede ser mucho más pequeño.

Inutilidad

Los casos de uso y sus diagramas asociados, especialmente en proyectos donde estos se miden ya sea por kilos o, a veces el pie, a menudo son más comúnmente conocida como "casos inútil". Narraciones de usuario sencilla, por ejemplo "lo que hago en el trabajo" han demostrado ser mucho más simple para grabar y más inmediatamente útiles.

Exclusivo

El término "unificado" se aplica únicamente a la unificación de los muchos idiomas antes de objetos existentes y la competencia orientada. Importantes técnicas bien conocidas y populares, casi universalmente utilizado en la industria, tales como diagramas de flujo de datos y gráficos de estructura no fueron incluidos en el pliego de condiciones.

Expertos en modelización han escrito duras críticas de UML, como Bertrand Meyer,

"UML: El giro positivo", y Brian Henderson-Sellers y César González-Pérez en

"Usos y abusos del Mecanismo de estereotipo en UML 1.x y 2.0".

 PROCESO DE DESARROLLO

Aunque UML es bastante independiente del proceso de desarrollo que se siga, los mismos creadores de UML han propuesto su propia metodología de desarrollo, denominada el Proceso Unificado de Desarrollo.

El Proceso Unificado está basado en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes software interconectados a través de interfaces bien definidos. Además, el Proceso Unificado utiliza el UML para expresar gráficamente todos los esquemas de un sistema software. Pero, realmente, los aspectos que definen este Proceso

Unificado son tres: es iterativo e incremental, dirigido por casos de uso y centrado en la arquitectura]:

• Dirigido por casos de uso: Basándose en los casos de uso, los desarrolladores crean una serie de modelos de diseño e implementación que los llevan a cabo. Además, estos modelos se validan para que sean conformes a los casos de uso. Finalmente, los casos de uso también sir-ven para realizar las pruebas sobre los componentes desarrollados.

• Centrado en la arquitectura: En la arquitectura de la construcción, antes de construir un edificio éste se contempla desde varios puntos de vista: estructura, conducciones eléctricas, fontanería, etc. Cada uno de estos aspectos está representado por un gráfico con su notación correspondiente.

Siguiendo este ejemplo, el concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema.

• Iterativo e incremental: Todo sistema informático complejo supone un gran esfuerzo que puede durar desde varios meses hasta años. Por lo tanto, lo más práctico es dividir un proyecto en varias fases. Actualmente se suele hablar de ciclos de vida en los que se realizan varios recorridos por todas las fases. Cada recorrido por las fases se denomina iteración en el proyecto en la que se realizan varios tipos de trabajo (denominados flujos). Además, cada iteración parte de la anterior incrementado o revisando la funcionalidad implementada. Se suele denominar proceso.

Es fácil predecir que UML será el lenguaje de modelado de software de uso universal. Las principales razones para ello son:

· En el desarrollo han participado investigadores de reconocido prestigio.

Ha sido apoyado por prácticamente todas las empresas importantes de informática.

· Se ha aceptado como un estándar por la OMG.

· Prácticamente todas las herramientas CASE y de desarrollo la han adaptado como lenguaje de modelado.

En resumen, UML resuelve de forma bastante satisfactoria un viejo problema del desarrollo de software como es su modelado gráfico. Además, se ha llega-do a una solución unificada basada en lo mejor que había hasta el momento, lo cual lo hace todavía más excepcional.

CICLO DE VIDA DEL SOFTWARE

El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.

El ciclo de vida básico de un software consta de los siguientes procedimientos:

· Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.

· Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.

· Diseño general: requisitos generales de la arquitectura de la aplicación.

· Diseño en detalle: definición precisa de cada subconjunto de la aplicación.

· Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.

· Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.

· Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada.

· Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.

· Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.

· Implementación

· Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrolladores.

ETAPAS DEL CICLO DE VIDA DEL SOFTWARE

El ciclo de vida clásico del software siendo uno de los más utilizados tal como lo plantean diferentes autores, está conformado en su versión ampliada por siete etapas que se pueden representar mediante un modelo en cascada así:

INGENIERÍA DE SISTEMAS: En esta etapa el analista luego de un minucioso y detallado estudio de los sistemas de una organización, detecta un problema o una necesidad que para su solución y/o satisfacción es necesario realizar un desarrollo de software.

ANÁLISIS: En esta etapa se debe entender y comprender de forma detallada cual es la problemática a resolver, verificando el entorno en el cual se encuentra dicho problema, de tal manera que se obtenga la información necesaria y suficiente para afrontar su respectiva solución. Esta etapa es conocida como la del QUÉ se va a solucionar.

DISEÑO: Una vez que se tiene la suficiente información del problema a solucionar, es importante determinar la estrategia que se va a utilizar para resolver el problema. Esta etapa es conocida bajo el CÓMO se va a solucionar.

IMPLEMENTACIÓN: partiendo del análisis y diseño de la solución, en esta etapa se procede a desarrollar el correspondiente programa que solucione el problema mediante el uso de una herramienta computacional determinada.

PRUEBAS: Los errores humanos dentro de la programación de los computadores son muchos y aumentan considerablemente con la complejidad del problema.

Cuando se termina de escribir un programa de computador, es necesario realizar las debidas pruebas que garanticen el correcto funcionamiento de dicho programa bajo el mayor número de situaciones posibles a las que se pueda enfrentar.

DOCUMENTACIÓN: Es la guía o comunicación escrita en sus diferentes formas, ya sea en enunciados, procedimientos, dibujos o diagramas que se hace sobre el desarrollo de un programa. La importancia de la documentación radica en que a menudo un programa escrito por una persona, es modificado por otra. Por ello la documentación sirve para ayudar a comprender o usar un programa o para facilitar futuras modificaciones (mantenimiento).

La documentación se compone de tres partes:

a.    Documentación Interna: Son los comentarios o mensajes que se añaden al código fuente para hacer más claro el entendimiento de los procesos que lo conforman, incluyendo las precondiciones y las pos condiciones de cada función.

b. Documentación Externa: Se define en un documento escrito con los siguientes puntos:

Descripción del Problema

Datos del Autor

Algoritmo (diagrama de flujo o Pseudocódigo)

Diccionario de Datos

Código Fuente (programa)

c. Manual de Usuario: Describe paso a paso la manera cómo funciona el programa, con el fin de que el usuario lo pueda manejar para que obtenga el resultado deseado.

MANTENIMIENTO: una vez instalado un programa y puesto en marcha para realizar la solución del problema previamente planteado o satisfacer una determinada necesidad, es importante mantener una estructura de actualización, verificación y validación que permitan a dicho programa ser útil y mantenerse actualizado según las necesidades o requerimientos planteados durante su vida útil. Para realizar un adecuado mantenimiento, es necesario contar con una buena documentación del mismo.

Para terminar de entender la problemática en la cual se desarrolla este libro es importante tener unos conceptos claros y precisos de lo que es el Análisis y el Diseño de Algoritmos.

SOFTWARE EDUCATIVO

Ingeniería del Software Educativo

Se denomina software educativo al destinado a la enseñanza y el aprendizaje autónomo y que, además, permite el desarrollo de ciertas habilidades cognitivas.

Así como existen profundas diferencias entre las filosofías pedagógicas, así también existe una amplia gama de enfoques para la creación de software educativo, atendiendo a los diferentes tipos de interacción que debería existir entre los actores del proceso de enseñanza-aprendizaje: educador, aprendiz, conocimiento, computadora.

Existen muchos programas para trabajar en la computadora para afianzar el aprendizaje. El trabajo en equipo de profesionales de la informática, ha permitido crear programas para computadoras, que no solo facilitan el trabajo, sino que también sirven para entretener y educar.

Estos programas forman parte del software educativo, denominada en algunos casos como Instrucción Asistida por Computadora o Multimedia Educativa, utilizada como una herramienta instruccional o de enseñanza, que acompañada con un material adecuado que permite guiar a estudiantes a alcanzar un nivel educativo adaptado a sus necesidades.

Clasificación de los diferentes tipos de software educativo

Bajo este nombre (abreviado MEC “MATERIAL EDUCATIVO COMPUTARIZADO”) se agrupan diversos tipos de aplicaciones encaminados a apoyar el aprendizaje.

Una referencia bastante apropiada es "Ingeniería de Software Educativo" de Álvaro Galvis (Galvis, 94), de donde se ha tomado la clasificación que se presenta. Una primera clasificación de herramientas y materiales para asistir el aprendizaje los divide en algorítmicos y heurísticos. En los materiales algorítmicos predomina el aprendizaje vía transmisión de conocimiento desde quien sabe hacia quien lo desea aprender; quien diseña la herramienta planea secuencias de actividades  para conducir al estudiante; el rol de alumno es asimilar el máximo de lo que se le transmite. Por otra parte en los materiales heurísticos predomina el aprendizaje por experimentación y descubrimiento; el diseñador crea ambientes ricos en situaciones que el alumno debe explorar; el alumno debe llegar al conocimiento a partir de la experiencia, creando sus propios modelos de pensamiento, sus propias interpretaciones del mundo, las cuales puede someter a prueba con la herramienta. Tal clasificación puede refinarse aún más:

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:

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 de muestra lo aprendido, ofrece retroinformación y esfuerzo o refuerzo.

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.

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:

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.

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.

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.

· Los sistemas tutoriales pueden presentar las cuatro fases del aprendizaje, y resultan particularmente útiles cuando se requiere alta motivación, retroalimentación inmediata, ritmo propio y secuencia controlable por el usuario parcial o totalmente.

· Los sistemas de ejercitación y práctica permiten reforzar las dos fases finales del proceso de instrucción: aplicación y retroalimentación por medio de ejercicios tradicionales.

· Los simuladores pretenden apoyar el aprendizaje por medio de experimentos, de forma que el estudiante descubra conceptos en un micromundo semejante a una situación real. En este tipo de MEC, que puede emplearse en cualquier de las cuatro fases, el alumno es agente activo.

· Los juegos educativos, al igual que los simuladores apoyan el aprendizaje semejando situaciones, sin embargo, en la simulación se trata de situaciones reales mientras que esto no se da necesariamente en los juegos, además en éstos se dan situaciones excitantes o entretenidas.

Los micromundos exploratorios, emplean un lenguaje de programación sintónico, es decir no hay que aprenderlo, simplemente se está sintonizado con sus instrucciones y se emplea para interactuar en un micromundo. La diferencia básica con los simuladores es que además de exigir la solución de problemas, la exige de forma estructurada (es decir, una que conlleve división de problemas en subproblemas). Por esta razón, los lenguajes sintónicos permiten el desarrollo de estrategias para solución de problemas.

Los sistemas expertos son sistemas capaces de representar y razonar acerca de algún dominio rico en conocimientos, con el ánimo de resolver problemas y dar consejo a quienes no son expertos en la materia. Estos sistemas además de demostrar gran capacidad de desempeño en términos de velocidad, precisión y exactitud, cuentan con una base de conocimientos construida a partir de experiencia humana. Con la base de conocimientos y con reglas de alto nivel es capaz de hallar o juzgar la solución a algo, explicando o justificando lo que halla o lo que juzga, de modo que es capaz de convencer al usuario de que su razonamiento es correcto.

· Un sistema Tutorial Inteligente presenta un comportamiento "inteligentemente" adaptativo, es decir, adapta el tratamiento educativo en función de aquello que se desea aprender y de las características y desempeño del aprendiz. Además de tener los componentes típicos de un sistema experto (base de conocimiento, motor de inferencia, hechos e interfaz con usuario) hay un "modelo de estudiantes" donde se plasman sus conocimientos, habilidades y destrezas y un "módulo de interfaz" capaz de ofrecer distintos tipos de ambiente de aprendizaje a partir de las cuales se puede llegar al conocimiento buscado.

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

En esencia se conservan los grandes pasos o etapas de un proceso sistemático para desarrollo de materiales (análisis, diseño, desarrollo, prueba y ajuste, implementación). Sin embargo, en este caso se da particular énfasis a los siguientes aspectos: la solidez del análisis, como punto de partida; el dominio de teorías sustantivas sobre el aprendizaje y la comunicación humanas, como fundamento para el diseño de los ambientes educativos computarizados; la evaluación permanente y bajo criterios predefinidos, a lo largo de todas las etapas del proceso, como medio de perfeccionamiento continuo del material; la documentación adecuada y suficiente de lo que se realiza en cada etapa, como base para el mantenimiento que requerirá el material a lo largo de su vida útil.

La anterior explicación permite entender la razón de ser del doble ciclo, para selección o desarrollo de MECs, que ha propuesto Galvis como metodología básica de trabajo y que se ilustra en la siguiente Figura.

El punto de partida de ambos ciclos es la identificación de necesidades educativas reales que conviene atender con material educativo computarizado. Dependiendo del resultado final de esta etapa, se procede en el sentido contrario al avance de las manecillas del reloj, cuando se trata de seleccionar un MEC; pero en el mismo sentido del avance de las manecillas, si conviene efectuar su desarrollo.

En cualquiera de los dos ciclos, una vez que se dispone de un MEC, se requiere evaluarlo con un grupo piloto de alumnos que pertenezca a la población objeto, bajo las condiciones para las cuales está diseñado. Esta es la base para decidir si el MEC debe llevarse a la práctica en gran escala, o para echar pie atrás, rediseñarlo, ajustarlo o desecharlo. Durante su implementación también es importante que se evalúe el MEC, de modo que se pueda establecer la efectividad real del material, éste es el sentido de la prueba de campo.

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

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

3. El ciclo de vida y los procesos del software educativo.

Todo proyecto tiene asociado, por más pequeño que éste sea, pasos que se deben seguir tales como: planificación, estimación de recursos, seguimiento y control, y evaluación del proyecto. La selección de un modelo de ciclo de vida está asociada a un orden en la realización de las actividades a desarrollar. La red de actividades, es la que permitirá establecer a partir de la matriz de precedencia el camino crítico, como la secuencia de tareas más larga de principio al fin. El diagrama de Gantt, o los diagramas calendario permitirán establecer el estado del proyecto en un determinado momento a partir de su inicio, en cuanto a recursos se refiere. Para estimar el tamaño del producto o del programa a desarrollar, definido como la cantidad de código fuente, especificaciones, casos de prueba, documentación del usuario y otros productos, que han de ser desarrollados, se debe recurrir a datos estadísticos propios o no. La estimación consiste en la predicción del personal, el esfuerzo y el costo asociado para llevar a cabo todas las actividades del mismo.

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

2. La planificación de la gestión proyecto

Se la puede describir en términos de, las actividades a realizar, los documentos de salida y de las técnicas a utilizar.

Planificación de la gestión del proyecto
Actividades a realizar	Confeccionar el mapa de actividades para el modelo elegido del ciclo de vida, asignar de los recursos, definir el proyecto, planificar la gestión
Documentos de salida	Plan de gestión, plan de retiro
Técnicas a utilizar	CPM, PERT, diagrama de Gantt, estadísticas, simulación (Montecarlo), puntos funcionales, Modelos de estimación (COCOMO), Técnicas de descomposición para estimación.

La identificación de la necesidad

La identificación de una necesidad, enunciada en términos concretos, es el punto de partida para la puesta en marcha de un proyecto y la evaluación de las posibles soluciones dará la viabilidad del mismo.

Identificación de la necesidad
Actividades a realizar	Identificar necesidades, formular posibles soluciones y estudiar su viabilidad.
Documentos de salida	Informe de necesidades. Alternativas de solución. Soluciones factibles
Técnicas a utilizar	De adquisición de conocimientos, análisis costo beneficio, modelización, diagramas de flujos de datos, prototipado

.

El proceso de especificación de los requisitos

Consiste en establecer de un modo conciso, claro y preciso el conjunto de requisitos que deben ser satisfechos por el software a desarrollar. El objetivo es  determinar en forma total y consistente los requisitos de software. El análisis se realiza sobre la salida resultante, la descomposición de los datos, el procesamiento de los mismos, las bases de datos y las interfaces de usuario. (J. Juzgado, 1996). (ver Tabla 3.7). Se debe considerar que un requisito es una condición o característica que debe tener el programa para satisfacer un documento formal.

Estos requisitos pueden ser funcionales, de rendimiento o de interfaces. Los primeros especifican la función que el programa debe realizar, los segundos especifican una característica numérica y los últimos determinan las características de las interfaces, usuario-software, software-hardware y software- software. (Juzgado, 1996).

Especificación de requisito
Actividades a realizar	Definir y desarrollar los requisitos del software y de las interfaces
Documentos de salida	Especificación de los requisitos del software, requisitos de interfaces de usuario, de interfaces con otro software y con hardware. Requisitos de interfaces con el medio.
Técnicas a utilizar	Técnicas orientadas a los procesos: Análisis estructurado: diagramas de flujo de datos (DFD), diccionario de datos (DD), especificación de procesos. Diagramas de actividades. Técnicas orientadas a los datos: Diagramas entidad relación y diagramas de datos. Técnicas orientadas a los objetos. Diagramas de clases/objetos Jerarquía de clases/objetos Técnicas formales de especificación: Técnicas relacionales: ecuaciones implícitas, relaciones recurrentes, axiomas algebraicos. Técnicas orientadas al estado: tablas de decisión, de eventos, de transición, mecanismos de estado finitos, etc. Técnicas de prototipación

El proceso de diseño

El proceso de diseño es la piedra angular para la obtención de un producto coherente que satisfaga los requisitos de software. El diseño desde el punto de vista técnico comprende cuatro tipos de actividades: diseño de datos, arquitectónico, procedimental y diseño de interfaces y desde el punto de vista del proyecto evoluciona desde un diseño preliminar al diseño detallado.

El diseño de datos, modela las estructuras de datos necesarias para el desarrollo, el arquitectónico define las relaciones entre las estructuras del programa, considerando el desarrollo de módulos que se relacionan, mezcla la estructura de programas y de datos, y define las interfaces. El diseño procedimental transforma estructuras en descripción procedimental del software y por último el diseño de interface establece los mecanismos de interacción humano-computadora.

Este proceso de diseño, es la correcta traducción de los requisitos de software en un producto. (ver Tabla 3.8).

Se deben aplicar algunos principios conducentes a un software de calidad, tales como:

− Abstracción.

− Refinamiento sucesivo.

− Modularidad (consiste en la división en forma lógica de elementos en funciones y subfunciones).

− Estructura jerárquica en módulos con control entre componentes.

− Estructura de los datos.

− Procedimientos por capas funcionales.

− Ocultamiento de la información, etc., aplicación de métodos sistemáticos y una revisión constante.

Proceso de diseño
Actividades a realizar	Realizar el diseño arquitectónico, analizar el flujo de información, diseñar la base de datos, diseñar las interfaces, desarrollar los algoritmos, realizar el diseño detallado.
Documentos de salida	Descripción del diseño del software de la arquitectura del software, del flujo de información, descripción de la base de datos, de las interfaces, de los algoritmos.
Técnicas a utilizar	Descripción del diseño del software de la arquitectura del software, del flujo de información, descripción de la base de datos, de las interfaces, de los algoritmos. Técnicas orientadas a los procesos: diseño estructurado, diálogo de las interfaces, diseño lógico, HIPO (Hierarchy Input Process Output). Técnicas orientadas a los datos. Modelo lógico y físico de datos. Jackson, etc. Técnicas orientadas a los objetos: Modelo clase/objeto, diagrama de módulos. Técnicas de bajo nivel: Programación estructurada: diagramas de árbol Programación orientada a objetos: diagrama de procesos Técnicas de prototipación, Técnicas de refinamiento,

El proceso de implementación

Este proceso (ver Tabla 3.9), produce código fuente, código de la base de datos y documentación, de base de acuerdo a los estándares utilizados. La salida de este proceso  conduce a las pruebas de validación y verificación.

Proceso de implementación
Actividades a realizar	Crear los datos de prueba, crear código fuente, generar el código fuente, crear la documentación, planificar y realizar la integración de módulos.
Documentos de salida	Datos de prueba, documentación del sistema y del usuario. Plan de integración.
Técnicas a utilizar	Lenguajes de programación. Jackson

El proceso de instalación

Este proceso se centra en la verificación de la implementación adecuada del software y en la conformidad del cliente, previa prueba de aceptación (Tabla 3.10).

Proceso de instalación
Actividades a realizar	Planificar la instalación, instalar el software, cargar la base de datos, realizar las prueba de aceptación..
Documentos de salida	Plan de instalación del software e informe de instalación

Los procesos de mantenimiento y retiro

El proceso de mantenimiento se centra en el cambio asociado a los errores detectados, fallas, mejoras solicitadas y cambios. Se lo considera como una vuelta a la aplicación del ciclo de vida pero con un software existente como iteraciones de desarrollo.

Los tipos de mantenimiento pueden ser: correctivos, ante defectos encontrados, adaptativos, o sea, cambios del software de acuerdo al cambio en el entorno y de mejoras, con agregado de funciones adicionales.

Procesos de	Mantenimiento	Retiro
Actividades a realizar	Reaplicar el ciclo de vida.	Notificar al usuario, realizar las operaciones en paralelo y retirar el sistema.
Documentos de salida	Orden de mantenimiento Y recomendaciones de mantenimiento	Plan de retiro

El proceso de verificación y validación

Las tareas que abarca son las siguientes: pruebas de verificación, revisiones y auditoría e incluye las tareas de validación y pruebas de validación que se realizan durante el ciclo de vida del software para asegurar la satisfacción con los requisitos.

Para la verificación y validación del software, cuando ya exista código ejecutable, se pueden realizar las pruebas del mismo que consisten en ejecutar el software con determinados datos de entrada y producir resultados que luego serán comparados con los teóricos.

Un proceso asociado a las pruebas, es la depuración que consiste en tratar de deducir dónde están localizados los defectos en el software que hacen que este no funcione correctamente. (ver Tabla 3.12).

Procesos de verificación y de validación
Actividades a realizar	Planificar y ejecutar las tareas de verificación y validación. Recoger y analizar los datos de las métricas, planificar las pruebas, desarrollar las especificaciones de las pruebas y ejecutarlas.
Documentos de salida	Plan de verificación y validación. Informes de evaluación. Plan de pruebas. Especificación de las pruebas. Resultados de las pruebas.
Técnicas a utilizar	Técnicas de prueba de caja blanca: Técnicas de prueba de caja negra: Revisiones formales. Auditorías.

Los procesos de desarrollo de la documentación y de formación

Este proceso permite planificar, diseñar, implementar, editar, producir, distribuir y mantener los documentos para los desarrolladores y los usuarios.

Para una utilización efectiva del sistema se debe proporcionar al usuario las instrucciones y guías necesarias acerca del uso del software y de sus limitaciones.

Es un punto fundamental la formación del usuario en el sistema. También es importante la formación de los desarrolladores y soporte técnico.

Procesos de	Mantenimiento	Retiro
Actividades a realizar	Planificar e implementar La documentación, producir y distribuirla documentación	Planificar el programa de formación. Desarrollar materiales de formación. Validar e implementar el programa.
Documentos de salida	Plan de documentación	Plan de formación