La crisis del software se refiere a la dificultad de escribir programas libres de defectos, fácilmente comprensibles y verificables. Esto se debe a la complejidad de programar y a los cambios constantes requeridos por los usuarios.
El Ciclo de Vida del Software propone algunos modelos para explicar las fases o etapas que cumple el producto de software desde los requerimientos inicial hasta su nueva entrega.
un ensayo argumentativo sobre los temas Introducción a la Ingeniería de Software : Definición, Factores de calidad y productividad y Capacidad individual
El Ciclo de Vida del Software propone algunos modelos para explicar las fases o etapas que cumple el producto de software desde los requerimientos inicial hasta su nueva entrega.
un ensayo argumentativo sobre los temas Introducción a la Ingeniería de Software : Definición, Factores de calidad y productividad y Capacidad individual
2. -LA crisis del software se fundamento en el tiempo de la creacion de software,
ya que en la creacion del mismo no se obtenian los resultados deseados,
ademas de un gran costo y poca flexibilidad.
-es un termino informatico acuñado en 1968, en la primera conferencia
organizada por la otan (organizacion de traslado del atlántico norte) sobre
desarrollo de software, de la cual nacio formalmente la rama de la ingenieria de
software.
el termino se ajudica a f. l. bauer. aunque previamente habia sido utilizado por
edsger dijkstra en su obra "the humble programmer".
-basicamente, la crisis de software se refiere a la dificultad en escribir
programas libres en defectos, facilmente comprensibles, y que sean verificables.
las causas son, entre otras, la conplejidad que supone la tarea de programar y
los cambios a los que se tiene que ver sometido un programa para ser
continuamente adaptado a las necesidades de los usuarios
3. Básicamente, la crisis del
software se refiere a la
dificultad en escribir programas
libres de defectos, fácilmente
comprensibles, y que sean
verificables. Las causas son,
entre otras, la complejidad que
supone la tarea de programar, y
los cambios a los que se tiene
que ver sometido un programa
para ser continuamente
adaptado a las necesidades de
los usuario.
4. Modelos para el desarrollo de software
El modelo en cascada. Considera las actividades fundamentales del proceso
especificación, desarrollo, validación y evolución. Los representa como fases
separadas del proceso, tales como la especificación de requerimientos, el
diseño del software, la implementación, las pruebas, etcétera.
El modelo de desarrollo evolutivo (espiral). Este enfoque entrelaza las
actividades especificación, desarrollo y validación. Es decir surge de un sistema
inicial que se desarrolla rápidamente a partir de especificaciones abstractas.
Basándose en las peticiones del cliente para producir un sistema que satisfaga
sus necesidades.
El modelo de desarrollo basado en componentes. Éste enfoque se basa en la
existencia de un número significativo de componentes reutilizables. El proceso
de desarrollo se enfoca en integrar estos componentes en el sistema más que
en desarrollarlos desde cero. Estos tres modelos se utilizan ampliamente en la
práctica actual de la ingeniería del software, no se excluyen mutuamente y a
menudo se utilizan juntos especialmente para el desarrollo de grandes
sistemas.
5. Doble naturaleza del software: producto y herramienta para desarrollar
productos.
Evolucion del software ligada al hardware.
Desarrollob de software sin planificación- proyectos sin control- costos
imprevisibles
Etapas:
Primera Fase. Los Albores ( 1945-1955) :
Programar no es una tarea diferenciada del diseño de una máquina.
Uso del Lenguaje máquina y ensamblador.
Segunda Fase. El Florecimiento ( 1955-1965 ) :
Aparecen una multitud de lenguajes.
Es posible hacer todo.
6. Tercera Fase. La Crisis ( 1965-1970 ) :
Desarrollo Inalcanzable de grandes programas.
Ineficiencia, errores, coste impredecible.
Nada es posible.
Cuarta Fase. Innovación Conceptual ( 1970-1980 ) :
Fundamentos de Programación.
Verificación de Programación.
Metodologías de Diseño.
Quinta Fase. El Diseño del Problema ( 1980-200? ) :
Entornos de programación.
Especificación Formal..
Programación Automática.
7. CARACTERISTICAS:
Claridad: ¿Es fácil de comprender?
Fiabilidad: Probabilidad de Buen Funcionamiento
Facilidad de Soporte
Aceptación: ¿Se vende? ¿Los “Usuarios” lo Consideran Viable?
Conveniencia: ¿Es el método conveniente para lo que vamos a hacer?
Visibilidad: ¿Puedo Ver lo que Ocurre en el Proceso?
Robustez: ¿Es Difícil de Perturbar?
Facilidad de Mantenimiento
Rapidez: ¿Permite Entregar Rápido el Producto?
Adaptabilidad: ¿Lo puedo cambiar según las necesidades?
9. Estructuradas.
Orientadas a procesos
La ingeniería del software se basa en el modelo básico de
entrada/proceso/salida de un sistema.
Está compuesta por:
Diagrama de flujo de datos (DFD).
Diccionario de datos.
Especificaciones de proceso.
Ejemplos: metodologías de Demarco, Gene y Sarson, Yourdon
Metodología de Yourdon /Constantina
Realizar los DFD del sistema
Realizar el diagrama de estructuras
Evaluar el diseño
Preparar el diseño para la implantación
10. METODOLOGÍAS ORIENTADAS A DATOS
Son metodologías basadas en la información. Primero se definen las
estructuras de datos y, a partir de éstos, se derivan los componentes
procedimentales.
Ejemplos: metodologías de Jackson, Warnier, Warnier
METODOLOGIA ORIENTADAS A DATOS JERARQUICOS
• La estructura de control del programa debe ser jerárquica y se debe
derivar de la estructura de datos del programa
• El proceso de diseño consiste en definir primero las estructuras de los
datos de entrada y salida, mezclarlas todas en una estructura jerárquica
de programa y después ordenar detalladamente la lógica procedimental
para que se ajuste a esta estructura
• El diseño lógico debe preceder y estar separado del diseño físico
11. Metodologías Orientadas a Datos No Jerárquicos
Metodología Ingeniería de la Información
Planificación: construir una arquitectura de la Información y una estrategia
que soporte los objetivos de la organización
Análisis: comprender las áreas del negocio y determinar los requisitos del
sistema
Diseño: establecer el comportamiento del sistema deseado por el usuario y
que sea alcanzable por la tecnología
Construcción: construir sistemas que cumplan los tres niveles anteriores
12. Metodologías no estructuradas
4.1 Metodologías orientadas a objeto
La orientación a objetos unifica procesos y datos encapsulándolos en el
concepto de objetos.
Tiene dos enfoques distintos:
•Revolucionario, puro u ortodoxo. Rompen con las metodologías tradicionales.
Ejemplos: metodologías OOD de Boch, CRC/RDD de Wirfs-Brock.
•Sintetista o evolutivo. Toman como base los sistemas estructurados y
conforman elementos de uno y otro tipo.
Ejemplos: metodología OMT de Rumbourgh.
Metodología Mixta
Manejo de interrupciones
Comunicación y sincronización entre tareas
Gestión de procesos concurrentes
Respuesta oportuna ante eventos externos
Datos continuos o discretos