jueves, 31 de mayo de 2012

Actividad 6


Actividades obligatorias:
    • Describa cuales son las habilidades del analista de sistemas.
sistemas generalmente valora la manera que funcionan los negocios examinando la entrada, el procesamiento de datos y la salida de información con el propósito de mejorar los procesos organizacionales.
    • Mencione las siete fases secuenciales.
  1. Identificación de problemas.
  2. Oportunidades y objetivos
  3. Determinación de los requerimientos de información
  4. Análisis de las necesidades de sistemas
  5. Diseño del sistema recomendado
  6. Desarrollo y documentación del software
  7. Prueba y mantenimiento del sistema e implementación del mismo
    • Explique cada una de los tres puntos fundamentales de las organizaciones a considerar cuando se analizan y diseñan sistemas de información.

  1. el analista soluciona problemas, le gusta el reto de analizar un problema y encontrar una respuesta funcional





Actividades sugeridas:
    • ¿Cuáles son las cuatro razones para la adopción de las herramientas CASE?
  1. El incremento de la productividad del analista
  2. La mejora de la comunicación entre analistas y usuarios
  3. La integración de actividades del ciclo de vida y el análisis.
  4. La valoración del impacto de los cambios por mantenimiento
    • Explique en que consiste la técnica PERT.
El PERT ayuda a que el analista determine la ruta critica y el tiempo de holgura, que es la información requerida para el control efectivo del proyecto. Cuando es necesario terminar un proyecto en menor tiempo, el analista puede reducir la duración total del proyecto identificación y agilizando las actividades principales.
    • ¿Cómo se determina la factibilidad del proyecto?
 proyecto identificación y agilizando las actividades principales.
Autoevaluación
  1. ¿Quién es el analista de sistemas?
analista de sistemas generalmente valora la manera que funcionan los negocios examinando la entrada, el procesamiento de datos 
  1. ¿Cuáles son algunos de los papeles del analista de sistemas?
  1. Consultores externos para negocios.
  2. Experto de soporte dentro de un negocio.
  3. Agente de cambio en situaciones tanto internas como externas.
  1. Explique cual es la principal habilidad del analista de sistemas
el analista soluciona problemas, le gusta el reto de analizar un problema y encontrar una respuesta funcional

martes, 29 de mayo de 2012

UML



  •      Que es UML?
UML es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad.
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) - 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
 UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.


  •    Que  son los diagramas que utiliza UML
Diagramas de comportamiento
Diagramas de Interacción
Diagramas de estructur
Diagrama de Clases



  •       Que es el diagrama de estado
Estimulos como:
   Se crea el objeto
   El objeto recibe un mensaje de escucha
   El objeto recibe un mensaje de detención
   Un cliente solicita una conexión a través de la  red
   Un cliente finaliza una solicitud
   
La solicitud se ejecuta y ser termina




4.        












  • Que es el diagrama de secuencia
El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"


  •   Que es el diagrama colaboraciones
Un diagrama de colaboración en las versiones de UML 1.x 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. Por otra parte, un diagrama de comunicación no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes.
  Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común.
  Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementación es llamada "enlace".



  • Que es el diagrama de actividades

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.





  •       Que es el diagrama de componentes

 Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado.
Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.
Debido a que los diagramas de componentes son más parecidos a los diagramas de casos de usos, éstos son utilizados para modelar la vista estática y dinamica de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.
En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema.
Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.


  •       Que es el diagrama de clases

 Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.
Representación de: - Requerimientos en entidades y actuaciones. - La arquitectura conceptual de un dominio - Soluciones de diseño en una arquitectura - Componentes de software orientados a objetos


  •      Que es el diagrama de objetos
Los diagramas de objetos son utilizados durante el proceso de Análisis y Diseño de los sistemas informáticos en la metodologíaUML.
Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias específicas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase.



  •    Que es el diagrama de entidad relación

Un diagrama o modelo entidad-relación (a veces denominado por sus siglas del inglés, E-R "Entity relationship", o del español DER "Diagrama de Entidad Relación") es una herramienta para el modelado de datos que permite representar las entidades relevantes de un sistema de información así como sus interrelaciones y propiedades.





















  •  Que es el diagrama de caso de uso

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.





























URL
http://www.slideshare.net/e1da4/diagramas-uml/
http://es.wikipedia.org/wiki/Diagrama_de_secuencia
  http://es.wikipedia.org/wiki/Diagrama_de_componentes
http://es.wikipedia.org/wiki/Modelo_entidad-relaci%C3%B3n

jueves, 24 de mayo de 2012

Actividad 3


¿Que es un analisis?


Existen tantos tipos de análisis que centrarse en una única definición aplicable en todos los ámbitos resulta muy complicado. A nivel general, puede decirse que un análisis consiste en identificar los componentes de un todo, separarlos y examinarlos para lograr acceder a sus principios más elementales.


El objetivo de el analisis es analizar, diseñar y representar bajo el enfoque orientado a objeto, un sistema eficiente y eficaz.



-Cuestionario


Los cuestionarios en el proceso de investigación son un práctica común socorrida por los investigadores. Muchos cuestionarios se realizan sin una fundamentación teórica que los respalde y su formulación es en muchas ocasiones deficiente. Sin embargo, el cuestionario es muy utilizado en por investigadores así como por estudiantes que desean obtener algún título a través de un trabajo de investigación.

El uso de cuestionarios en investigación dice que:
1. El investigador debe partir de objetivos de estudio perfectamente definidos
2. Cada pregunta es de utilidad para el objetivo planteado por el trabajo.
3. El investigador debe estructurar las preguntas teniendo en mente siempre los objetivos del trabajo.
4. El que contesta está dispuesto y es capaz de proporcionar respuestas fidedignas.


-Entrevista


La recolección de datos se refiere al uso de una gran diversidad de técnicas y herramientas que pueden ser utilizadas por el analista para desarrollar los sistemas de información, los cuales pueden ser la entrevistas, la encuesta, el cuestionario, la observación, el diagrama de flujo y el diccionario de datos.
Todas estos instrumentos se aplicará en un momento en particular, con la finalidad de buscar información que será útil a una investigación en común. 


TÉCNICAS PARA HALLAR DATOS
Los analistas utilizan una variedad de métodos a fin de recopilar los datos sobre una situación existente, como entrevistas, cuestionarios, inspección de registros y observación. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigación completa.


LA ENTREVISTA
Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarán datos o serán afectados por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos algunos analistas prefieren este método a las otras técnicas que se estudiarán más adelante. Sin embargo, las entrevistas no siempre son la mejor fuente de datos de aplicación.
Dentro de una organización, la entrevistas es la técnica más significativa y productiva de que dispone el analista para recabar datos. Por otra parte, la entrevista ofrece al analista una excelente oportunidad para establecer una corriente de simpatía con el personal usuario, lo cual es fundamental en transcurso del estudio.


Preparación de la Entrevista
  1. Determinar la posición que ocupa de la organización el futuro entrevistado, sus responsabilidades básicas, actividades, etc.
  2. Preparar las preguntas que van a plantearse, y los documentos necesarios.
  3. Fijar un límite de tiempo y preparar la agenda para la entrevista.
  4. Elegir un lugar donde se puede conducir la entrevista con la mayor comodidad.
  5. Hacer la cita con la debida anticipación.
Conducción de la Entrevista
  1. Explicar con toda amplitud el propósito y alcance del estudio (Honestidad).
  2. Explicar la función propietaria como analista y la función que se espera conferir al entrevistado. (Imparcialidad).
  3. Hacer preguntas específicas para obtener respuestas cuantitativas (Hechos).
  4. Evitar las preguntas que exijan opiniones interesadas, subjetividad y actitudes similares (habilidad).
  5. Evitar el cuchicheo y las frases carentes de sentido (Claridad).
  6. Ser cortés y comedio, absteniéndose de emitir juicios de valores. (Objetividad).
  7. Conservar el control de la entrevista, evitando las divagaciones y los comentarios al margen de la cuestión.
  8. Escuchar atentamente lo que se dice, guardándose de anticiparse a las respuestas (Comunicación).
Secuela de la Entrevista
  1. Escribir los resultados.
  2. Entregar una copia al entrevistado, solicitando su conformación, correcciones o adiciones. (Profesionalismo).
  3. Archivar los resultados de la entrevista para referencia y análisis posteriores (Documentación).
-Entrevista Estructurada y No Estructurada


La estructura de la entrevista varia. Si el objetivo de la entrevista radica en adquirir información general, es conveniente elaborar una serie de pregunta sin estructura, con una sesión de preguntas y respuesta libres
Las entrevistas estructuradas utilizan pregunta estandarizada. El formato de respuestas para las preguntas pueden ser abierto o cerrado; las preguntas para respuestas abierta permiten a los entrevistados dar cualquier respuesta que parezca apropiado. Pueden contestar por completo con sus propias palabras. Con las preguntas para respuesta cerradas se proporcionan al usuario un conjunto de respuesta que se pueda seleccionar. Todas las personas que respondes se basan en un mismo conjunto de posible respuestas.
Los analistas también deben dividir el tiempo entre desarrollar preguntas para entrevistas y analizar respuesta. La entrevista no estructurada no requiere menos tiempos de preparación, porque no necesita tener por anticipado las palabras precisas de las preguntas. Analizar las respuestas después de la entrevista lleva más tiempo que con la entrevista estructuradas. El mayor costo radica en la preparación, administración y análisis de las entrevistas estructuradas para pregunta cerradas.


-Observacion


Observar es aplicar atentamente los sentidos a un objeto o a un fenómeno, para estudiarlos tal como se presentan en realidad. Observar no es "mirar".
La observacion puede darse en el analis de un objeto o una accion o un programas y su funcionamiento.

Actividad 5

Actividades obligatorias:
    • Explique porque es importante la información.
La información se ha colocado en un lugar adecuado como recurso principal. Los tomadores de decisiones están comenzando a comprender que la información no es solo un subproducto de la conducción, si no que a la vez alimenta a los negocios y puede ser el factor crítico para la determinación del éxito o fracaso de estos.
    • Mencione y explique los objetivos generales de la planeación estratégica de la información.
El primer paso de la ingeniería de información es la planificación de la estrategia de la información (PEI). Los objetivos generales del PEI son:
* Definir los objetivos y metas del negocio que sean estratégico.
* Aislar los factores de éxito critico.
* Analizar el impacto de la tecnología y automatización en las metas y objetivos.
* Analizar la información existente para determinar su papel en la consecución de las metas y objetivos.

    • Ha decidido empezar un negocio con envío de ordenes por correo electrónico. Como quiere llevar su negocio con eficacia, decide hacer algo de ingeniería de información. Empiece por el PEI. Construya un sencillo modelo de empresa que incluya un organigrama, esquemas de funciones y de los procesos de negocio y un modelo de datos en el ámbito del negocio.
    • Asumamos que una de las áreas del negocio que ha identificado para el negocio de software por correo (actividad anterior) es el proceso de pedidos por teléfono. Haga un AAN para desarrollar un modelo de datos y diagrama de flujo del proceso detallado para esta área del negocio.
Actividades sugeridas:
    • Explique que realiza la ingeniería de la información.
    • Explique que se hace durante el análisis del área del negocio.

    • La planeación de la estrategia de la información empieza por la definición de objetivos y metas. Ponga ejemplos de cada uno de los dominios del negocio.
Autoevaluación
      1. ¿Cuál es el objetivo de la ingeniería de la información?
La evolución tecnológica conlleva a modificar roles profesionales en el sector de la información, a fin de que los profesionales se encuentren plenamente capacitados para desenvolverse en el nuevo contexto denominado Sociedad de la Información. Bajo este marco global y situándonos en el contexto empresarial, la participación de los profesionales de la información cobra especial importancia y su integración en el proceso de toma de decisiones se hace cada vez más necesaria y vital.
      1. ¿Cuál es factor critico para la determinación del éxito o fracaso de los negocios?
      2. ¿Qué es un objetivo?
      3. ¿Qué es una meta?

martes, 22 de mayo de 2012

Actividad 4


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

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

    traducen automáticamente en código fuente 
    lenguajes no procedimentales para consulta a base de datos
    eneración de códigos, capacidades gráficas de alto nivel
    capacidad de hojas de cálculo 
      • Describa el modelo concurrente
    Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.

      • A medida que vaya hacia afuera del modelo espiral ¿qué puede decir del software que se esta desarrollando?
    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.
      • Explique los pasos tradicionales de cualquier modelo.
    Comunicación con el cliente : 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.


    Actividades 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.
    Web HTML, Dreamweaver, NVu, Publisher  Bases de datos tenemos el SQL Development, Postgres, Mysql 

      • ¿Cómo seleccionar el modelo adecuado?.
      • Explique como el paradigma ciclo de vida clásico y el de construcción de prototipos pueden acomodarse en el modelo espiral.
      • Que es el analista de sistemas?
    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. 

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

      • 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 profesionalreconocida.
    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.
    Autoevaluación
    1.      ¿Cuales son las características del paradigma ciclo de vida clásico?
    2.      ¿En que consiste el paradigma de construcción de prototipos?
    3.      ¿Cuales son los pasos a seguir en el paradigma espiral?
    4.      ¿Cuáles son las desventajas del modelo DRA?
    5.      ¿Cuál es el parádigma de técnicas de cuarta generación?

    Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.

    miércoles, 16 de mayo de 2012

    Tarea 1 Programación orientado a objetos


    Programación  Orientado a Objetos 
    1. Introducción a POO Néstor Traña Obando
    2. Paradigma Orientado a 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 de computadoras. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento. Un paradigma de programación representa un enfoque particular o filosofía para la construcción del software. No es mejor uno que otro sino que cada uno tiene ventajas y desventajas. Néstor Traña Obando
    3. Paradigma Orientado a Objetos En la POO las entidades centrales son los objetos, que son tipos de datos que encapsulan con el mismo nombre estructuras de datos, operaciones o algoritmos que manipulan esos datos. 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. Néstor Traña Obando
    4. Propiedades de un Modelo ABSTRACCIÓN Es la propiedad que permite representar las características esenciales de un objeto sin preocuparse de las restantes características. Se centra en la vista externa de un objeto de modo que sirve para separar el comportamiento esencial de un objeto, de su implementación. ENCAPSULAMIENTO Es la propiedad que permite asegurar que el contenido de la información de un objeto esta oculta al mundo exterior, es decir el objeto A no conoce lo que hace el objeto B y viceversa. La encapsulación permite la división de un programa en módulos, esos módulos se implementan mediante clases, de forma que una clase representa la encapsulación de una abstracción. Néstor Traña Obando
    5. Propiedades de un Modelo MODULARIDAD Es 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 si y de las partes restantes. JERARQUIA Es la propiedad que permite una ordenación de las abstracciones, las dos jerarquías más importantes de un sistema complejo son: Estructuras de clases (jerarquía Es-Un: Generalización/Especificación) Estructuras de objetos (jerarquía Parte-De: Agregación)Néstor Traña Obando


    jueves, 10 de mayo de 2012

    Actividad 2 "Paradigmas"


    PARADIGMA CICLO DE VIDA DEL SOFTWARE
    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


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

    • experiencia para valorar el riesgo y saber cuando detener la evolución
    EL MODELO DRA
    El Desarrollo Rápido de Aplicaciones (DRA) (rapid application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de tiempo.

    PARADIGMA DE TÉCNICAS DE CUARTA GENERACION
    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.
    EL MODELO DE DESARROLLO CONCURRENTE
    Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.
    Davis Sitaram ha descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, de la siguiente forma:
    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.

    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.
    En muchos casos los paradigmas pueden y deben combinarse en forma que puedan utilizarse las ventajas de cada uno en un único proyecto.
    La siguiente figura muestra como pueden combinarse los 3 paradigmas mencionados durante un trabajo de desarrollo del software, en todos los casos el trabajo comienza con la recolección de requerimientos. El método puede seguir el ciclo de vida clásico (ingeniería de sistemas análisis de requerimiento de software) o puede ser la definición menos formal del problema usada en la construcción de un prototipo, independientemente debe producirse la comunicación cliente-realizador del software.