UML

UML:

El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.

Que es el diagrama que utiliza UML :
Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. También ilustran qué eventos pueden cambiar el estado de los objetos de la clase

Que es el diagrama de secuencia UML:
Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que eldiagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos.

Que es un diagrama de colaboraciones UML:
Un diagrama de colaboración en las versiones de UML  es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de colaboración, también llamados diagramas de comunicación, muestran explícitamente las relaciones de los roles.

Diagrama de actividades UML:
En el Lenguaje de Modelado Unificado, un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general.

En SysML el diagrama de Actividades ha sido extendido para indicar flujos entre pasos que mueven elementos físicos (e.g., gasolina) o energía (e.g., presión). Los cambios adicionales permiten al diagrama soportar mejor flujos de comportamiento y datos continuos.

Diagrama de componentes UML:
Un componente de software es una parte física de un sistema, y se encuentra en la computadora, no en la mente del analista. Ejemplos de componentes son tablas, archivos de datos, ejecutables, bibliotecas de vínculos dinámicos, documentos y cosas por el estilo.

Lo que contiene un diagrama de componentes es lógicamente componentes, interfaces y relaciones, aunque también pueden aparecer otros tipos de símbolos vistos anteriormente.

Diagrama de distribución UML :
Dentro del cubo se puede introducir información sobre el nodo, que puede ser simplemente texto o inclusive componentes, usando los diagramas de componentes anteriormente ejemplificados. En el ejemplo que se muestra a continuación, puede verse un nodo que tiene componentes de software (Windows, Office e Internet Explorer). Aunque como ya se dijo, los diagramas de distribución se enfocan en la parte de hardware, cada uno de los nodos puede contener otros componentes, incluyendo software

Diagrama de clases UML:
un rectángulo es el símbolo que representa a la clase, y se divide en tres áreas. El área superior contiene el nombre de la clase, el área central contiene los atributos o propiedades, y el área inferior, las acciones, procedimientos, métodos o funciones. Un diagrama de clases está formado por varios rectángulos de este tipo conectados por líneas que muestran la manera en que las clases se relacionan entre sí.

Diagrama de objetos UML:
Partiendo del hecho que un objeto es una instancia de clase, tal como se define en la conceptualización básica de la programación orientada a objetos, en UML la representación de un diagrama de objetos se hace de tal forma que teniendo ya una clase, el símbolo del objeto es un rectángulo, pero con el nombre subrayado. El nombre de la instancia específica se encuentra a la izquierda de los dos puntos (:), y el nombre de la clase a la derecha

Diagrama de clase de usos UML:

La mejor forma de desarrollar un buen diagrama de caso de uso es mediante entrevista directa con los usuarios o posibles futuros usuarios del sistema, poniendo atención a cada una de las actividades o pasos que se van a ir desarrollando desde un primer momento hasta un momento final.

La elaboración de diagramas de uso ayuda poderosamente a un analista a comprender la forma en que un sistema deberá comportarse, obteniendo los requerimientos desde el punto de vista del usuario.

Actividad 4

Autoevaluacion:  

1. ¿Cuales son las características del paradigma ciclo de vida clásico?


Análisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa. Para comprender la naturaleza de los programas que hay que construir. El ingeniero de software debe comprender el dominio de la información del software, así como la función, rendimiento e interfaces requeridas. En esta etapa los requerimientos del sistema se documentan y se analizan con el cliente.
Diseño. El diseño del software es realmente un proceso multipaso que se enfoca sobre 3 atributos del programa.
• estructura de datos
• arquitectura de software
• detalle procedimental
El diseño traduce los requerimientos en una representación del software que pueda ser establecida de forma que obtenga la calidad requerida antes que comience la codificación. Como los requerimientos y el diseño que se documentan forman parte de la configuración del software.
Codificación. El diseño debe traducirse en una forma legible. El paso de la codificación ejecuta la tarea de establecer la etapa de diseño legible para la maquina, si el diseño se ejecuta de una manera detallada la codificación puede realizarse mecánicamente.
Prueba. Una vez que se ha generado el código, comienza la prueba del programa, la prueba se enfoca sobre la lógica interna del software asegurando que todas las sentencias se han probado y sobre las funciones externas estoy realizando pruebas para asegurar que la entrada definida producirá los resultados que realmente se requieren.
Mantenimiento. El software sufrirá indudablemente cambios después que se le entregue al cliente los cambios ocurrirán debido a que se han encontrado errores, causados por cambios del entorno externo por ejemplo un cambio solicitado debido al cambio del Sistema Operativo o dispositivos periféricos, o debido que el cliente requiere aumentos en las funciones del sistema. El mantenimiento del software se aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en lugar de uno nuevo.

2. ¿En que consiste el paradigma de construcción de prototipos?


Normalmente un cliente definirá un conjunto de objetivos generales para el software pero no identificara los requerimientos detallados de entrada, procesamiento de salida.
En otros casos el programador puede no estar seguro de la eficiencia de un algoritmo, la adaptabilidad de un sistema operativo o la forma en que debe realizarse la interacción hombre-maquina. En estas y muchas otras situaciones puede ser mejor método de ingeniería de software realizar un prototipo. La construcción de prototipo es un proceso que facilita al programador la creación de un método de software a conseguir. El método tomara una de las 3 formas siguientes:
Un prototipo en papel que describa la interrelacion hombre-maquina de forma que facilita el usuario la comprensión como producirá tal interrelacion; un prototipo que funcione que implementa algunos subconjuntos de la función requerida al software deseado o un programa existente que ejecute parte o toda la función deseada pero que tenga otras características que deban ser mejoradas en el nuevo trabajo de desarrollo.

3. ¿Cuales son los pasos a seguir en el paradigma espiral?

El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.

4. ¿Cuáles son las desventajas del modelo DRA?

• Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?
• Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.
• Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.
• Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.
• Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfases a fondo.

5. ¿Cuál es el parádigma de técnicas de cuarta generación?

El termino de técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software ha especificar algunas características de alto nivel. Luego la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Existe cierto debate sobre cuanto ha de elevarse el nivel en el que se especifique el software para una maquina. El paradigma de T4G para la ingeniería de software se orienta hacia la habilidad de especificar software a un nivel que sea más próximo al lenguaje natural o a una notación que proporcione funciones significativas.
Actualmente un entorno para el desarrollo del software que soporte el paradigma de T4G incluye algunas o todas las siguientes herramientas: lenguajes no procedimentales para consulta a base de datos, generación de informes, manipulación de datos, interacción y definición de pantallas y generación de códigos, capacidades gráficas de alto nivel y capacidad de hojas de cálculo. Cada una de estas herramientas existe, pero solo son para dominios de aplicación muy específicos. No existe hoy disponible un entorno deT4G que pueda aplicarse con igual facilidad a todas las categorías de aplicaciones de software.

Sugeridas:

Proporcione cinco ejemplos de desarrollo del software que sean adecuados para construir prototipos. Nombre dos o tres aplicaciones que fueran más difíciles para construir prototipos.

• adecuados para construir prototipos, 
1. Sistema para un negocio de venta por internet, como mercado libre.
2. Sistema para administración de una refaccionaria.
3. Sistema de almacenes.
4. Sistemas para tiendas de autoservicio.
5. Sistemas para consultar citas medicas como ISSSTENET.

• Difíciles para construir prototipos
1. Sistemas para dispositivos médicos.
2. Sistemas para aviónica

Explique como el paradigma ciclo de vida clásico y el de construcción de prototipos pueden acomodarse en el modelo espiral. 

Es también al igual que el anterior un modelo evolutivo
El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación. 

Que es el analista de sistemas?

El analista tiene como cometido analizar un problema y describirlo con el propósito de ser solucionado mediante un sistema informático.
El diseñador realiza, con base en el análisis, el diseño de la solución
El analista tiene que delimitar el análisis para ver lo que se quiere hacer inicialmente y después darle al usuario nuevas opciones de uso.
Hoy en día, estas funciones han quedado claramente obsoletas a pesar de que la categoría profesional sigue existiendo como tal. Los avances de la ingeniería del software en su corta vida han puesto de manifiesto que estas funciones no son suficientes para lograr un mínimo éxito en el desarrollo de software.
Las funciones más relevantes que faltan son:
Dirección (de proyectos), para dirigir los recursos hacia el resultado deseado.
Educción de requisitos, para determinar el comportamiento que se espera del software.
Garantía de calidad, para garantizar las expectativas del cliente.
Diseño, para que exista una mínima certeza de que el software es viable y eficaz con la tecnología existente.
Gestión de configuración, para controlar el caos a medida que el software crece.
Estas funciones han sido adoptadas en muchos casos por analistas, pero no son materia específica de esta profesión. En algunas organizaciones (y en algunos países) la profesión ya no existe, siendo sustituida por otras figuras tales como el ingeniero de software, el jefe de proyecto, el modelador de software, o el analista-programador. Esta última figura es muy popular ya que resuelve los típicos problemas de comunicación que existían entre analistas y programadores. Estos problemas se deben a la extrema idealización de la especialización de funciones.
Es deseable también que el analista de sistemas tenga conocimientos -al menos básicos- de usabilidad. Ya que cualquier sistema que no esté al servicio de los usuarios o diseñado pensando en el usuario, no tiene mucho sentido.

Que es el analista-programador?

El Analista Programador es la persona que realiza las funciones de un analista técnico y de un programador; es decir, parte de una información previa recibida del analista funcional, en función de la cual desarrolla las aplicaciones y organiza los datos. Es el perfil más buscado en la actualidad.


En base a sus conocimientos en el o los lenguajes de programación necesarios en cada caso, sintetiza, organiza y lo lleva a la práctica mediante la codificación de la silución. Requiere características de personalidad similares a las de un programador, con mayor visión global y capacidad de análisis y síntesis.

Que es un programador?

Un programador es aquella persona que escribe, depura y mantiene el código fuente de un programa informático, es decir, del conjunto de instrucciones que ejecuta el hardware de una computadora para realizar una tarea determinada. La programación es una de las principales disciplinas dentro de la informática. En la mayoría de los países, programador es también una categoría profesional reconocida.
Los programadores también reciben el nombre de desarrolladores de software, aunque estrictamente forman parte de un equipo de personas de distintas especialidades (mayormente informáticas), y siendo que el equipo es propiamente el desarrollador.
El programador se encarga de la implementación de prototipos mediante un lenguaje de programación, que compilados pueda entender la computadora.
Inicialmente, la profesión se formalizó desde el enfoque Tayloriano de la especialización de funciones en la empresa. Así, el proceso de producción de software se concibe como un conjunto de tareas altamente especializadas donde está claramente definido el papel de cada categoría profesional:
El analista, tiene como cometido analizar un problema y describirlo con el propósito de ser solucionado mediante un sistema de información.
El programador cuya única función consistía en trasladar las especificaciones del analista en código ejecutable para la computadora. Dichas especificaciones se recogen en un documento denominado cuaderno de carga, medio de comunicación entre ambos. Esto se consideraba un trabajo mecánico y de baja cualificación.
Hoy día se reconoce que este enfoque no es válido para organizar tareas de tipo intelectual, como es el desarrollo de software. De manera que la profesión de programador ha ido evolucionando. Las dificultades de comunicación entre analistas y programadores (un mero documento no basta para describir lo que se quiere hacer) dio origen a una categoría de profesional intermedia, denominada analista-programador. La concepción original del programador ha desaparecido siendo sustituida por la de un profesional mucho más formado y con unas funciones menos "mecánicas".
La profesión de analista también ha evolucionado, surgiendo el concepto diseñador (de software). Esto se debe a los avances de la ingeniería del software donde se reconoce que el análisis es una actividad compleja y distinta del diseño. Escuetamente, el análisis describe el problema (es decir qué hacer) mientras que el diseño describe la solución (cómo hacerlo).
En la mayoría de países industrializados esto ha dado lugar a la categoría profesional del diseñador o arquitecto del software.


Obligatorias:


¿Cual de los paradigmas de la ingeniería de software sería más útil para las aplicaciones del software?¿Porque?
PARADIGMA DEL MODELO ESPIRAL
Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones. La versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez mas completas de ingeniería del sistema.
CARACTERISTICAS: Es también al igual que el anterior un modelo evolutivo que combina el modelo clásico con el diseño de prototipos. Incluye la etapa de análisis de riesgos, no incluida anteriormente. Es ideal para crear productos con diferentes versiones mejoradas como se hace con los software modernos de microcomputadoras. La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos. Este es el enfoque más realista actualmente. 
El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.

Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación. 

Proporcione tres ejemplos de técnicas de 4ª generación. 

1. Con muy pocas excepciones el dominio de aplicación actual de las T4G esta limitada a las aplicaciones de sistema de información comerciales, específicamente del análisis de información comerciales, específicamente del análisis de información y de la obtención de informes en las grandes bases de datos. Hasta la fecha T4G se han usado muy poco en productos de ingeniería y áreas de aplicación de sistemas. 
2. La recolección de datos preliminares que acompañan al uso de T4G parece indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas de trabajo medio así como también la cantidad e análisis y diseño. 
3. Sin embargo el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o más tiempo de análisis, diseño y prueba perdiéndose así un tiempo sustancial que se ahorra mediante la eliminación de la codificación.

Describa el modelo concurrente 

Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo
Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente. Por ejemplo,...el personal esta escribiendo requisitos diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). Los modelos de proceso de ingeniería del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo más reciente de Kellner utiliza diagramas de estado para representar la relación concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestión del software en mi proyecto. La mayoría de los modelos de procesos de desarrollo del software son dirigido por el tiempo; cuanto más tarde sea, mas atrás se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) esta dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.
El modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.

A medida que vaya hacia afuera del modelo espiral ¿qué puede decir del software que se esta desarrollando? 

Cuando empieza el proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones mas sofisticadas del software. Cada paso de la región de planificación produce ajustes en el plan del proyecto. El coste y la planificación se ajustan según la reacción ante la evolución del cliente.
VENTAJAS:
• El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no terminal cuando se entrega el software. 
• Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. 
• Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. 
• Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto. 
• Reduce los riesgos antes de que se conviertan en problemáticos. 
Pero al igual que otros paradigmas puede resultar difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas. El modelo en sí mismo es relativamente nuevo y no se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos. Todavía tendrán que pasar muchos años antes de que se determine con absoluta certeza la eficacia de este nuevo e importante paradigma.
La siguiente figura define un eje de punto de entrada en el proyecto. Cada uno de los cubos situados a lo largo del eje representan el punto de arranque para un tipo diferente de proyecto. Un proyecto de desarrollo de conceptos comienza en el centro de la espiral y continuara hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro de un producto real, el proceso procede a través del cubo siguiente y se inicia un nuevo proyecto de desarrollo.

Explique los pasos tradicionales de cualquier modelo

Ingeniería y análisis del sistema. Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo todos los requerimientos o elementos del sistema y luego asignando algún subconjunto de estos requerimientos al software; esta versión del sistema es esencial cuando el software debe interrelacionarse con otros elementos tales como hardware, personas y bases de datos.
La ingeniería y análisis del sistema abarcan los requerimientos globales a un nivel de sistema con una pequeña cantidad de análisis y diseño a nivel superior. Además de un análisis costo beneficio del sistema es decir si toda la inversión que se hará para el sistema conviene a los beneficios que traerá el mismo.
Análisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa. Para comprender la naturaleza de los programas que hay que construir. El ingeniero de software debe comprender el dominio de la información del software, así como la función, rendimiento e interfaces requeridas. En esta etapa los requerimientos del sistema se documentan y se analizan con el cliente.
Diseño. El diseño del software es realmente un proceso multipaso que se enfoca sobre 3 atributos del programa.
• estructura de datos 
• arquitectura de software 
• detalle procedimental 
El diseño traduce los requerimientos en una representación del software que pueda ser establecida de forma que obtenga la calidad requerida antes que comience la codificación. Como los requerimientos y el diseño que se documentan forman parte de la configuración del software.
Codificación. El diseño debe traducirse en una forma legible. El paso de la codificación ejecuta la tarea de establecer la etapa de diseño legible para la maquina, si el diseño se ejecuta de una manera detallada la codificación puede realizarse mecánicamente.
Prueba. Una vez que se ha generado el código, comienza la prueba del programa, la prueba se enfoca sobre la lógica interna del software asegurando que todas las sentencias se han probado y sobre las funciones externas estoy realizando pruebas para asegurar que la entrada definida producirá los resultados que realmente se requieren.
Mantenimiento. El software sufrirá indudablemente cambios después que se le entregue al cliente los cambios ocurrirán debido a que se han encontrado errores, causados por cambios del entorno externo por ejemplo un cambio solicitado debido al cambio del Sistema Operativo o dispositivos periféricos, o debido que el cliente requiere aumentos en las funciones del sistema. El mantenimiento del software se aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en lugar de uno nuevo.
Este fue el modelo inicial planteado para organizar el proceso de desarrollo, aunque antiguo tiene vigencia en algunos proyectos o como parte de otros modelos, da la medida de los pasos tradicionales de cualquier modelo: análisis, entrevista, diseño, codificación, prueba y mantenimiento.

Tarea 2

                           Diagrama de Gantt


El diagrama de Gantt, gráfica de Gantt o carta Gantt es una popular herramienta gráfica cuyo objetivo es mostrar el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado. A pesar de que, en principio, el diagrama de Gantt no indica las relaciones existentes entre actividades, la posición de cada tarea a lo largo del tiempo hace que se puedan identificar dichas relaciones e interdependencias


En gestión de proyectos, el diagrama de Gantt muestra el origen y el final de las diferentes unidades mínimas de trabajo y los grupos de tareas  o las dependencias entre unidades mínimas de trabajo 


Se puede producir un diagrama de Gantt con una hoja de cálculo de una manera muy sencilla, marcando determinadas celdas para formar la representación de cada tarea. Existen macros que automatizan esta elaboración en MS Excel y Libre/OpenOffice Calc. Sin embargo, existen herramientas de gestión de proyectos dedicadas a la planificación y seguimiento de tareas, que utilizan el diagrama de Gantt como pantalla principal.

Actividad 3

Análisis: 
El análisis de sistemas es la ciencia encargada del análisis de sistemas grandes y complejos y la interacción entre esos sistemas. Esta área se encuentra muy relacionada con la Investigación de operaciones. También se denomina análisis de sistemas a una de las etapas de construcción de un sistema informático, que consiste en relevar la información actual y proponer los rasgos generales de la solución futura.


Entrevista Estructurada:
Llamada también formal o estandarizada. Se caracteriza por estar rígidamente estandarizada, se plantean idénticas preguntas y en el mismo orden a cada uno de los participantes, quienes deben escoger la respuesta entre dos, tres o más alternativas que se les ofrecen.

Entre las ventajas que tiene este tipo de Entrevista, se mencionan:

• La información es más fácil de procesar, simplificando el análisis comparativo.

• El entrevistador no necesita esta entrenado arduamente en la técnica.

• Hay uniformidad en la información obtenida.

Entre las desventajas se tienen:

• Es difícil obtener información confidencial.

• Se limita la posibilidad se profundizar en un tema que emerja durante la Entrevista.
  Entrevista no estructurada
  Es más flexible y abierta, aunque los objetivos de la investigación rigen a las preguntas, su contenido, orden, profundidad y formulación se encuentran por entero en manos del entrevistador. Si bien el investigador, sobre la base del problema, los objetivos y las variables, elabora las preguntas antes de realizar la entrevista, modifica el orden, la forma de encauzar las preguntas o su formulación para adaptarlas a las diversas situaciones y características particulares de los sujetos de estudio.
  Entre las ventajas de este tipo de Entrevista se tienen:
  • Es adaptable y susceptible de aplicarse a toda clase de sujetos en situaciones diversas.
  • Permite profundizar en temas de interés.
  • Orienta posibles hipótesis y variables cuando se exploran áreas nuevas.
  Entre sus desventajas se mencionan:
  • Se requiere de mayor tiempo.
  • Es más costoso por la inversión de tiempo de los entrevistadores.
  • Se dificulta la tabulación de los datos.
  • Se requiere mucha habilidad técnica para obtener la información y mayor conocimiento del tema.
    Cuestionario:
    Esto determinó que uno de nuestros trabajos debería estar enfocado a cuestionarios. Por lo tanto, desde hace dos años nos hemos dedicado a analizar un total de 15 cuestionarios utilizados en investigaciones de ingeniería, administración ,enfermería , medicina  y educación . Entrevistamos a los autores de estos 15 y adicionalmente revisamos 128 en diversas áreas que nos han permitido llegar a conclusiones adicionales a las obtenidas de los 15 analizados a través de los métodos de análisis de contenido e interpretativo. Nos hubiese gustado revisar más cuestionarios antes de escribir el presente artículo, sin embargo, debido a la gran necesidad que tienen los alumnos de programas de postgrado, que no han tenido experiencia en el desarrollo de cuestionarios, hemos decidido publicar un primer resumen de nuestras conclusiones a la fecha. Este resumen presenta los resultados de la investigación que consideramos útiles y que hemos podido convertir en consejos prácticos para apoyar a los alumnos en el desarrollo de sus cuestionarios. Este es, pues, el objetivo de este artículo: ayudar a diseñar un cuestionario.
    Observación:
    Revise sus observaciones e identifique si realizó interpretaciones. Contabilice las observaciones hechas durante este ejercicio. Reflexione sobre lo realizado y piense que una vela encendida, a pesar de ser un hecho tan simple, se convierte en un fenómeno fascinante cuando se somete a la observación cientifica y cuidadosa.
    Con base en los resultados obtenidos de la anterior actividad, podemos destacar que:
    • Observar no solo es "ver".
    • Para lograr una buena observación es necesario utilizar la mayoría de los órganos de los sentidos.
    • Al observar un fenómeno, es conveniente interactuar con él, efectuando algunas. manipulaciones simples.
    • Una descripción se enriquece mucho si se hacen observaciones cuantitativas.
    • Se deben describir los cambios que experimentan los objetos y seres.
    • Es necesario distinguir entre observaciones, e interpretaciones de las observaciones.
    
    

Tarea 1

Paradigmas Orientado Objetos

La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe variedad de lenguajes de programación que soportan la orientación a objetos

Conceptos Funtamentales:

La programación orientada a objetos es una forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:

§  Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.

§  Herencia: (por ejemplo, herencia de la clase C a la clase D) Es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos métodos y variables publicas declaradas en C. Los componentes registrados como "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de OOP.

§  Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.

§  Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.

§  Evento: Es un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera.

§  Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.

§  Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.

§  Estado interno: es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase.

§  Componentes de un objeto: atributos, identidad, relaciones y métodos.

§  Identificación de un objeto: un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes.

Caracteristicas de la POO

Abstracción: denota las características esenciales de un objeto, donde se capturan sus comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características.

Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción

Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes.

Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone unainterfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase.

Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando

Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación.

Recolección de basura: la recolección de basura o garbage collector es la técnica por la cual el entorno de objetos se encarga de destruir automáticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos.

Actividad 2

PARADIGMA CICLO DE VIDA DEL SOFTWARE

Ingeniería y análisis del sistema. Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo todos los requerimientos o elementos del sistema y luego asignando algún subconjunto de estos requerimientos al software

Análisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa.

Codificación. El diseño debe traducirse en una forma legible. El paso de la codificación ejecuta la tarea de establecer la etapa de diseño legible para la maquina,

Prueba. Una vez que se ha generado el código, comienza la prueba del programa, la prueba se enfoca sobre la lógica interna del software asegurando que todas las sentencias se han probado

Mantenimiento. El software sufrirá indudablemente cambios después que se le entregue al cliente los cambios ocurrirán debido a que se han encontrado errores

                                      PARADIGMA DE CONSTRUCCIÓN DE PROTOTIPOS

PARADIGMA DEL MODELO ESPIRAL

Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.

Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.

Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto

Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.

Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.

Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.

EL MODELO DRA

Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa

Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión

Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existenteso a crear componentes reutilizables

 Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas

PARADIGMA DE TÉCNICAS DE CUARTA GENERACION

 1. Con muy pocas excepciones el dominio de aplicación actual de las T4G esta limitada a las aplicaciones de sistema de información comerciales, específicamente del análisis de información comerciales, específicamente del análisis de información y de la obtención de informes en las grandes bases de datos.

2. La recolección de datos preliminares que acompañan al uso de T4G parece indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas de trabajo medio así como también la cantidad e análisis y diseño.

3. Sin embargo el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o más tiempo de análisis, diseño y prueba perdiéndose así un tiempo sustancial que se ahorra mediante la eliminación de la codificación.

EL MODELO DE DESARROLLO CONCURRENTE

Todas las actividades existen concurrentemente, pero residen en estados diferentes. Por ejemplo: al principio del proyecto, la actividad de comunicación con el cliente (no mostrada en la figura) ha finalizado su primera interacción y existe en el estado de cambios en espera. La actividad de análisis (que existía en el estado ninguno mientras que comenzaba la comunicación inicial con el cliente) ahora hace una transición al estado bajo desarrollo. Sin embargo, si el cliente indica que se deben hacer cambios en requisitos, la actividad análisis cambia del estado bajo desarrollo al estado cambios en espera.

                                                 COMBINACIÓN DE PARADIGMAS

Frecuentemente se describe a los paradigmas de la ingeniería de software tratados en las secciones anteriores como métodos alternativos, para la ingeniería de software en vez de los métodos complementarios.

Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?

• Este paradigma ayuda al cliente a brindar requisitos paso a paso.
• También facilita al programador ir probando algoritmos no explotados con anterioridad, de los que no tiene seguridad de su eficiencia.
• Consiste en la creación de prototipos