Actividad Paranormal 4. & Autoevaluación.By Nashua

Actividades Paranormales Obligatorias.

1.    ¿Cual de los paradigmas de la ingeniería de software sería más útil para las aplicaciones del software?¿Porque?

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

3.    Describa el modelo concurrente

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

5.    Explique los pasos tradicionales de cualquier modelo.

1.

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.
¿Por qué?

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

2.

·         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

 3.

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.

4.

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 más 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.

5.

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.

Actividades Sugeridas.

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

El Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos.
El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

1. Sistemas para dispositivos médicos.
2. Sistemas para aviónica.

2. ¿Cómo seleccionar el modelo adecuado?

En todo proyecto de software existe la necesidad de tener una adecuada gestión de los proyectos, para esto se debe contar con el personal capacitado, seleccionar el mejor proceso de acuerdo al problema que se vaya a tratar, y por supuesto una excelente planificación, con el fin de obtener un producto a tiempo y de calidad.
Cuando se desea realizar una gestión adecuada, eficaz y eficiente en la gestión de proyectos de software, es necesario que se ponga en funcionamiento cuatro características muy importantes en esta gestión, las cuatro P: personal, producto, proceso y proyecto. El gestor de proyectos muchas de las veces se olvida que el éxito o fracaso de los proyectos depende fundamentalmente del equipo humano con el que trabaje. El gestor debe basarse en procesos válidos y que verdaderamente le sirvan a su proyecto, no construir soluciones elegantes para problemas equivocados. Todo proyecto debe tener consigo una planificación previa, no se debe aventurar al éxito sin antes conocer los beneficios, contras y coste de cada uno de los proyectos. La ejecución de las cuatro características marcará el rumbo del éxito del gestor y de sus proyectos.

3. ¿Qué es el analista de sistemas?

Las funciones más relevantes del analista de sistemas 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.

4. ¿Qué es el analista-programador?

El desarrollador (también conocido como analista/programador) debe diseñar y desarrollar una aplicación para ordenadores, es decir, debe transcribir una necesidad en una solución informática escrita en lenguaje informático. Históricamente, el desarrollo de ordenadores ha estado a cargo de un gerente de proyectos quien describía las necesidades, siendo el analista el que se encargaba del modelado y el programador, de la codificación. El analista es para el programador lo que el diseño es para la producción. Es una profesión de diseño que implica la traducción de las necesidades de un cliente en instrucciones y la creación de un modelo informático. Las dos funciones de programador y diseñador se han fusionado gradualmente. Por esta razón, se le da el nombre de analista/programador que es sinónimo de "desarrollador".
El trabajo de un desarrollador consiste en crear sobre aplicaciones existentes y modelar otras nuevas. 

5. ¿Qué es un programador?

(Programmer) Un programador o programador de computadora, es un individuo que hace la programación, o sea, escribe programas para computadoras.

Un programador se encarga de implementar algoritmos mediante un lenguaje de programación. El término programador también puede asociarse al ingeniero de software, al científico de la computación, al desarrollador de software y al analista, aunque estas personas tienen otras habilidades y propósitos.

http://www.alegsa.com.ar/Dic/programador.php

http://es.kioskea.net/contents/metiers-informatique/analyste-programmeur-developpeur.php3

Autoevaluación.

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

·         Ingeniería y análisis del sistema.

·         Análisis de los requerimientos del software.

·         Diseño.

§  Estructura de datos.

§  Arquitectura de software.

§  Detalle procedimental.

·         Codificación.

·         Prueba.

·         Mantenimiento. 

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

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

3. ¿Cuáles son los pasos a seguir en el paradigma espiral? 

El modelo en espiral se divide en un número 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? 

Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes: 

·         Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA. 

·         DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasaran. 

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

El término de técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software a 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 cuánto 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.