LÍNEA DE TIEMPO

Integrantes:Rebeca Contreras EspinozaAdrian Dair Ramírez AcevedoSergio Abdiel Ramirez Romayor

Fundamentos de Ingeniería de Software Unidad I

Maestra:

1969 Programación estructurada SOL (Structured Oriented Language)

En este modelo la estructura de control de un programa se define separadamente del resto de las instrucciones del lenguaje de programación, y es modelada a su vez por el comportamiento de una jerarquía de autómatas finitos.

El enunciado inicial de un problema puede concebírselo como un autómata de un solo estado. A cada estado podrá corresponderle hasta dos próximos estados acorde a la evaluación lógica de una condición (si existe) al final de su tarea.

A partir de aquí y en forma recursiva se analiza si un estado particular de un autómata puede ser sintetizado directamente por el lenguaje de programación disponible. En tal caso la descomposición se detiene, sino el comportamiento del estado particular se descompone en un nuevo autómata en un nivel inferior. Y así sucesivamente en un número finito de pasos se arribará a que todos los estados del autómata (jerarquía de autómatas) pueden ser sintetizados "razonablemente bien" por instrucciones del lenguaje de programación disponible.

1969 Programación estructurada SOL (Structured Oriented Language)

La idea de concebir programas mediante este lenguaje (o metodología) resulta de interés como medio unificado de programación, ya que la descripción de la solución de un problema puede plantearse con cierto grado.

1969 Programación estructurada SOL (Structured Oriented Language)

Un proceso es una secuencia de instrucciones que ocupan una cantidad de recursos del computador y permiten la solución de un problema, ya sea en función de un solo proceso o de varios subprocesos que al combinarse, correcta y lógicamente, generan la solución deseada.

1975 Programación estructurada Jackson

1975 Programación estructurada Jackson

SSADM divide un proyecto de desarrollo de aplicaciones en módulos, fases, pasos y tareas, y proporciona un marco para describir los proyectos de una manera adecuada a la gestión del proyecto. Objetivos de SSADM son: • Mejorar la gestión y control de proyectos • Hacer un uso más eficaz del personal de desarrollo con experiencia y sin

experiencia • Desarrollar sistemas de mejor calidad • Hacer proyectos resistentes a la pérdida de personal • Permitir que los proyectos con el apoyo de herramientas informáticas, como los

sistemas de ingeniería de software asistida por ordenador • Establecer un marco para la buena comunicación entre los participantes en un

proyecto

1980 Structured System Analysis and Design Methodology (SSADM)

SSADM cubre esos aspectos del ciclo de vida de un sistema a partir de la fase de estudio de viabilidad para la producción de un diseño físico; generalmente se utiliza en combinación con otros métodos, como PRINCE, que se ocupa de los aspectos más amplios de la gestión de proyectos. En detalle, SSADM establece una vista en cascada o una cascada de desarrollo de sistemas, en el que hay una serie de pasos, cada uno de los cuales conduce a la siguiente etapa. (Esto puede ser contrastado con el desarrollo rápido de aplicaciones - RAD -. Método, que presupone la necesidad de realizar pasos en paralelo). Pasos de SSADM o etapas son: • viabilidad • Investigación del entorno actual • Opciones de sistemas de negocio • Definición de los requisitos • Opciones del sistema técnico • diseño lógico • diseño físico

1980 Structured System Analysis and Design Methodology (SSADM)

Para cada etapa, SSADM establece una serie de técnicas y procedimientos, y las convenciones para registrar y comunicar la información relativa a estos - tanto en forma textual y esquemática. SSADM es un modelo muy completo, y una característica del método es que los proyectos pueden utilizar sólo aquellos elementos de SSADM apropiadas para el proyecto. SSADM se apoya en una serie de proveedores de herramientas CASE.

1980 Structured System Analysis and Design Methodology (SSADM)

• Notación diagramática para la construcción de un boceto para una aplicación. • Ofrece cajas para representar entidades y actividades. • Ofrece una variedad de flechas para relacionarse cajas. • Cajas y flechas haber un asociado (informal) semántica; los usuarios son

ayudados por la caja y las etiquetas de dirección, otra documentación informal.

• Ha inspirado a muchas otras herramientas comerciales. • Ha estado en uso desde mediados de los años setenta. • TDAA está disponible como una herramienta CASE comercial bajo el nombrar

IDEF0.

1980 Structured Analysis and Design Technique (SADT)

1981 Ingeniería de la Información (IE/IEM)

VFSM intenta abstraer la arquitectura real sobre la que se implementarán los programas. Para intentar aplicar métodos matemáticos genéricos que nos permitan simular su comportamiento. Y poder así diseñar con garantías de cuál va a ser su funcionamiento.

1990 Virtual Finite State Machine (VFSM)

• Control de Propiedades• Una variable en el entorno VFSM puede tener uno o más valores que son relevantes para el control

- en este caso es una variable de entrada• Acciones• Una variable en el entorno VFSM puede ser activado por acciones - en este caso es una variable

de salida. • Entorno Virtual• El entorno virtual caracteriza el entorno en el que un VFSM opera. Se define por tres conjuntos de

nombres:• ·         Introducir nombres, representados por las propiedades del control de todas las variables

disponibles• ·         Nombres de salida, representada por todas las acciones disponibles en las variables• ·         Nombres de estado, como se define para cada uno de los estados de los EFM.

1990 Virtual Finite State Machine (VFSM)

•  La programación orientada a objetos o POO (OOP según sus siglas en inglés) usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en  herencia, abstracción, polimorfismo y encapsulamiento. Se popularizó a principios de la década de los años 1990. 

• Las ventajas son las siguientes:• -Agiliza el desarrollo de software.• - Facilita el trabajo en equipo.• - Las aplicaciones son más sencillas para los usuarios debido a que los datos innecesarios

están ocultos.• - La productividad se incrementa debido a que puede reutilizar el código.• - Los sistemas son fáciles de mantener y se adaptan a las cambiantes necesidades de negocios.• -  Confiabilidad.• - Capacidad de ampliación.• - Crea sistemas mas flexibles, que en un futuro son modificables.

1990 Programacion Orientada a Objetos (OOP)

• Alguna de las características fundamentales son:• - Uniformidad: la representación de los objetos implica tanto el

análisis, diseño y la codificación.• - Comprensión: Tanto los datos que componen los objetos, como los

procedimientos que los manipulan, están agrupados en clases• - Flexibilidad: Al tener relacionados los procedimientos, cualquier

cambio que se realice sobre ellos quedará reflejado automáticamente en cualquier lugar donde estos datos aparezcan.

• - Estabilidad: Permite aislar las partes del programa que permanecen inalterables en el tiempo.

1990 Programacion Orientada a Objetos (OOP)

• El RAD es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE.

• La limitación de tiempo impuesto en un proyecto DRA demanda “ámbito en escalas”. Si una aplicación de gestión puede modularse se forma que permita completarse cada una de las funciones principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones puede ser afrontada por un equipo DRA diferente y ser integradas en un solo conjunto.

1991 Rapid Application Development (RAD)

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

• No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modulizar adecuadamente.

1991 Rapid Application Development (RAD)

Fue desarrollado en el Reino Unido en los años 90 por un consorcio DSDM un conjunto de proveedores y de expertos en la materia del desarrollo de sistemas de información (IS)

La metodológica DSDM es caracterizada por su rapidez de desarrollo previendo que transcurra mucho tiempo y la tecnología cambie.

Es ideal para proyectos de sistemas de información cuyos presupuestos y agendas son muy apretadas.

1995 Dynamic Systems Development Method desarrollado en UK

• Trabajo en equipo.

• El equipo de desarrollo puede tomar sus decisiones sin depender de autorizaciones.

• El equipo de desarrollo debe realizar entregas cortas pero frecuentemente y funcionales.

• Todos los cambios pueden ser revertibles. • La verificación de calidad debe existir a lo largo del proceso de desarrollo y no solamente en al final del proyecto.

1995 Dynamic Systems Development Method desarrollado en UK

Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los 80.• El Scrum es un proceso de la Metodología Ágil que se usa para minimizar los riesgos durante la realización de un proyecto, pero de manera colaborativa. 

• Entre las ventajas se encuentran la productividad, calidad y que se realiza un seguimiento diario de los avances del proyecto, logrando que los integrantes estén unidos, comunicados y que el cliente vaya viendo los avances.

1997 Scrum (desarrollado)

• Product Backlog: Es una “wish list” sobre las funcionalidades del producto. Las funciones están priorizadas según lo que es más y menos importante para el negocio.

• Sprint Backlog: Es un subconjunto de ítemes del Product Backlog para realizar durante el Sprint.

• Sprint Planning Meeting: Esta reunión se hace al comienzo de cada Sprint. Cada Sprint está compuesto por diferentes features.

• Daily Scrum o Stand-up Meeting: Es una reunión breve que se realiza a diario mientras dura el periodo de Sprint

• Sprint Review: Se revisa el sprint terminado, y ya debería haber un avance claro y tangible para presentárselo al cliente.

• Sprint Retrospective: El equipo revisa los objetivos cumplidos del Sprint terminado. Se anota lo bueno y lo malo.

1997 Scrum (desarrollado)

1999 Rational Unified Process (RUP)

1999 Extreme Programming (XP)

2002 Enterpise Unified Process (EUP) extensions RUP

2004 Constructionist Design Methodology (CDM)

2005 Agile Unified Process (AUP)