MTOPS: Miles de millones de operaciones por segundo.
Ley de Moore: avance de comunicaciones entre sistemas. II) Introducir más componentes electrónicos a los dispositivos para mejorar y optimizar procesos.
Crisis de Software: (1962: primer algoritmo de busquedas binarios).
Disjktra:
Primer libro de métricas de Softare en 1977.
Primer libro de análisis de requisitos en 1979.
Definición de Ingeniería de Software (1968): Establecimiento y uso de principios de ingeniería para obtener software económico, que trabaje de forma eficiente en máquinas reales.
Se originó la disciplina de Ingeniería de Software en 1968.
Ingeniería de sistemas surgió en 1956, universidad de pensilvania. (Garantizar que el sistema satisface los requisitos durante todo el ciclo de vida. Todas las demás consideraciones se alinean sobre esta función).
FUNCIONES: Indentificación y formulación del problema, análisis de la solución, planificación de procesos, control de los procesos, evaluzación del producto.
Definición de Ingeniería de Software (1990): Disciplina para desarrollar software de calidad sobre agendas y costes previstos y satisfaciendo los requisitos.
El marco del ciclo de vida del software cubre desde la conceptuación de las ideas iniciales del producto hasta el fin de su uso (retirada). -ISO/IEC 12207 1995
Incremental: El modelo incremebtal mitiga la rigidez del modelo en cascada, descrompimiento el desarrollo de un sistema en partes.
Evolutivo: El modelo está compuesto por varios ciclos de desarrollo. Cada uno de ellos produce un sistema completo con el que se operará en el entorno de operación.
Modelo de desarrollo secuencial: Es incremental o evolutivo. Este modelo refleja un desarrollo marcado por la sucesión escalonada (Década de los 50's).
Requisitos.
Diseño.
Codificación (Construcción / Implementación).
Pruebas.
Integración.
Operación y mantenimiento.
Modelo de desarrollo en cascada (o variante secuencial): La primera versión tiene un retroalimentación de los procesos anterior y siguiente, en la segunda versión tiene retroalimentación entre todos los procesos (década de los 70's).
Requisitos.
Diseño.
Codificación.
Pruebas.
Integración.
Operación y mantenimiento.
Modelo de desarrollo en espiral: Desarrollado en 1988, definido por Boehm, presenta un desarrollo evolutivo, en contraste a la lineal.
Planeación, riesgos, ingeniería y evaluación.
Protipado: Costrucción de modelos de prueba, que simulen el funcionamiento que se pretende conseguir en el sistema. pueden ser ligeros (Información de muestra) y operativos (Utiliza información real).
Concurrencia: Consiste en el solapamiento de un proceso sobre otro proceso. Resulta bastante frecuente que aunque se haya planteado en desarrollo en cascada, se comience con una fase sin haber terminado por completo al anterior; y así por ejemplo quizá el equipo que ha llevado a cabo el diseño detallado de determinados módulos, quizá comienza ya su codificación, mientras otros equipos aún tienen en su planificación tareas de diseño pendientes. La concurrencia puede aportar beneficios sobre la planificación de un proyecto de software.
Componentes comerciales y reutilización: Resulta muy habitual integrar en el desarrollo de un sistema partes "pre-construídas": que pueden ser componentes comerciales, o la reutilización de componentes o marcos ya desarrollados para otros sistemas. Esta tendencia surge de tres situaciones: Presión competitiva para reducir agendas y costes, incremento de la complejidad y estandarización de los entornos de operación, Aparición de las líneas de producción.
Al iniciar un proyecto, el responsable de la arquitectura de procesos bede realizar los siguientes pasos:
Análisis de las circustancias ambientales del proyecto.
Diseño del modelo específico de ciclo de vida para el proyecto (sobre las bases de los diseños más apropiados, para el desarrollo y la evolución del sistema de software).
Mapeo de las actividades sobre el modelo.
Desarrollo del plan para la gestión del ciclo de vida del proyecto.
Debe considerar aspectos como:
Posibilidad de composición del sistema en subsistemas de sofwtare, con agendas y entregas diferencidas.
Estabilidad esperada de los requisitos.
Novedad del proceso o procesos gestionados por el sistema en el entorno del cliente.
Criticidad de las agendas y presupuestos.
Grado de complegidad de la interfaz de operación, criticidad de la usabilidad.
grado de conocimiento y familiaridad con el entorno de desarollo, componentes externos empleados, etc.
Modelo: es una simplicación de la realidad. Proporciona los planos de un sistema, incluyedo aquellos elementos que tienen gran influencia y omite aquellos que no son relevantes para el nivel de abstracción dado.
Tipos de modelo:
Modelo estructural: Destaca la organización del sistema de software
Modelo de comportamiento: Resalta la dinámica del software.
En el diseño de un sistema de software hay dos formas de enfocar un modelo.
Perspectiva algorítmica: El bloque de construcción es el procedimiento o función. Los desarolladores se centran en cuestiones de control y descomposición de algoritmos grandes en otros más pequeños.
Perspectiva orientada a objetos: El bloque principal de construcción es la Clase o el Objeto. El diseño orientado a objetos propone una estratégia de diseño basada en la ocultación de información, que ve el sistema software como un conjunto de objectos que interaccionan entre sí con su propio estado privado, en vez de un conjunto de funciones que comparten un estado global.
Modelado Orientado a Objectos con UML: Visualizar, Especificar, Construir, Documentar.
