Software e ingeniería del software Programas de computadora que cuando se ejecutan proporcionan la función y el rendimiento esperado.

Presentación del tema: "Software e ingeniería del software Programas de computadora que cuando se ejecutan proporcionan la función y el rendimiento esperado."— Transcripción de la presentación:

1

2 Software e ingeniería del software

3 Programas de computadora que cuando se ejecutan proporcionan la función y el rendimiento esperado

4 Características del Software  Se desarrolla y no se fabrica  La mayoría del software es hecho a medida

5 Primera Era Años 50 Programas con ensamblador Crisis del software

6 Años 70 Aparición de computadoras más potentes Software de uso general fuerte mantenimiento

7 Anos 80 Marcada por PCs Programación estructurada Reducción del mantenimiento

8 Lenguajes orientados a objetos Lenguajes de cuarta generación Situación Actual Recorte de revisiones, pruebas y verificaciones del software

9 El proceso de desarrollo

10 Los cálculos de coste asociados con el desarrollo de software excesivamente elevados Ciclo de vida del Software Marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software Modelos de desarrollo Los modelos de desarrollo de Software son estrategias de desarrollo para organizar las diversas etapas y actividades del ciclo de vida del software. Describe las transiciones entre las etapas

11 Fase de Mantenimiento Fase centrada en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software. Cuatro tipos de cambio Corrección Adaptación Mejora Prevención

12 Identificación del sistema y definición de requerimientos Análisis Diseño Desarrollo e implementación Integración y prueba del software Documentación Entrenamiento y uso Mantenimiento del software

13 Modelo o ciclo de vida en espiral Transformaciones formales Ciclo de vida en cascada

14 Metodologías Es un conjunto coherente de métodos y técnica que cubren mas de una etapa del ciclo de vida

15 Estado de desarrollo Prevenir la evolución Analizar posibilidades de formación Tener en cuenta la construcción de prototipos Estar enfocada al desarrollo orientado a objetos

16 Partimos del supuesto de que ya hemos evaluado múltiples Metodologías y ya hemos escogido la que vamos a implantar Plan de normalización y adaptación al entorno Plan de formación a todos los miembros de la organización Plan de proyectos Plan de seguimiento

17 Procedimientos Responsabilidades Documentos a generar Formato de los documentos Entorno de desarrollo de la documentación

18 Plan de proyectos Seleccionar un proyecto piloto, no crítico i de complejidad normal. Aprovechar este proyecto para evaluar y modificar la normalización, adaptación y formación ya realizadas Plan de seguimiento Definir objetivos, cuantificar objetivos, controlar el cumplimiento de los objetivos,aparece la tarea del mantener la metodología

19 Metodología métrica

20 Escasa o nula documentación Dificultad de desarrollo, implantación y especialmente mantenimiento Falta de comunicación con los usuarios Productos no entregados a tiempo, no responden a las necesidades

21

22 En los DFD no se deberá modelizar: Procedimientos, puntos de inicio y de terminación del DFD condiciones, tratamientos de errores poco relevantes

23 ENTIDAD EXTERNAENTIDAD EXTERNA Representa entes ajenos a la aplicación. Los que aportan o reciben informaciónRepresenta entes ajenos a la aplicación. Los que aportan o reciben información

24 Representa personas, organizaciones, o sistemas que no pertenecen al sistema En el caso de que las entidades externas se comunicasen entre sí, esto no se contemplaría en el diagrama, por estar fuera del ámbito de nuestro sistema Puede aparecer en los distintos niveles de DFD para mejorar su comprensión, aunque normalmente sólo aparecerá en el diagrama de contexto

25 Reglas de Construcción: Representa la información en reposo puede crear, destruir ni transformar datos No puede estar comunicado directamente con otro almacén o Entidad externa El flujo de datos (Entrada y Salida) no lleva nombre cuando incide sobre su contenido completo No debe estar referido al entorno físico, y por tanto, no se diferencian los ficheros convencionales de las bases de datos No se representa la clave de acceso a este almacén sino sólo la operación que se realiza

26 Establecen la comunicación entre procesos, almacenes y entidades externas, llevan la información necesaria para esos objetosEstablecen la comunicación entre procesos, almacenes y entidades externas, llevan la información necesaria para esos objetos Reglas de Construcción:Reglas de Construcción: El concepto de flujo de datos es similar al concepto de tubería a través del cual fluye información de estructura conocidaEl concepto de flujo de datos es similar al concepto de tubería a través del cual fluye información de estructura conocida Los datos no pueden ser creados ni destruidos por un flujo de datos Los datos no pueden ser creados ni destruidos por un flujo de datos Sirve para conectar el resto de los componentes de un DFDSirve para conectar el resto de los componentes de un DFD No es un activador de procesosNo es un activador de procesos Cuando un proceso almacena datos, la flecha de flujo de datos se indica en la dirección del almacén de datos y a la inversa si es el proceso el que lee datos en el almacénCuando un proceso almacena datos, la flecha de flujo de datos se indica en la dirección del almacén de datos y a la inversa si es el proceso el que lee datos en el almacén

27 Los DFD se han de representar de la forma más clara posible, por ello se basan en el principio de descomposición o explosión por niveles en distintos niveles de detalle.Los DFD se han de representar de la forma más clara posible, por ello se basan en el principio de descomposición o explosión por niveles en distintos niveles de detalle. La descomposición por niveles permite analizar el sistema desdes el ámbito general al detalle, pasando por sucesivos niveles intermedios (Filosofía “top-down”) La descomposición por niveles permite analizar el sistema desdes el ámbito general al detalle, pasando por sucesivos niveles intermedios (Filosofía “top-down”) La utilización de esta implica la descomposición o explosión de cada proceso en otro DFD.

28 El objetivo es realizar una declaración formal del dominio Un solo proceso representará el área que se está estudiando Un solo proceso representará el área que se está estudiando El contexto queda definido por los flujos de entrada y salida y las entidades externas El contexto queda definido por los flujos de entrada y salida y las entidades externas Las entidades externas han de aparecer en este nivel y no en ningún otroLas entidades externas han de aparecer en este nivel y no en ningún otro Gráfico que va a proporcionar el ámbito del proyecto objeto de estudio. En él aparecerá todo aquello que necesite o envié datos del o hacia el sistema a desarrollarGráfico que va a proporcionar el ámbito del proyecto objeto de estudio. En él aparecerá todo aquello que necesite o envié datos del o hacia el sistema a desarrollar

29 Base de datosBase de datos Conjunto, colección o depósito de datos almacenados en un soporte informático. Los datos deben estar interrelacionados y estructurados de acuerdo con un modelo capaz de recoger el máximo contenido semántico.Conjunto, colección o depósito de datos almacenados en un soporte informático. Los datos deben estar interrelacionados y estructurados de acuerdo con un modelo capaz de recoger el máximo contenido semántico. Los sistemas de bases de datos, al ser un repositorio, poseen componente estática, dinámica y funcional, y cada una de estas componentes puede ser vista desde los niveles de abstracción conceptual, lógico o físico.Los sistemas de bases de datos, al ser un repositorio, poseen componente estática, dinámica y funcional, y cada una de estas componentes puede ser vista desde los niveles de abstracción conceptual, lógico o físico.

30 Es el conjunto de conceptos, reglas y convenciones que permiten describir y manipular los datos del mundo real que constituye nuestra visión del mundo real relevante para nuestro sistemaEs el conjunto de conceptos, reglas y convenciones que permiten describir y manipular los datos del mundo real que constituye nuestra visión del mundo real relevante para nuestro sistema El modelo de datos es un “dispositivo de abstracción” para la interpretación de la realidad con el objetivo de captar su semántica. Al aplicar el modelo de datos se obtiene una estructura de datos llamada EsquemaEl modelo de datos es un “dispositivo de abstracción” para la interpretación de la realidad con el objetivo de captar su semántica. Al aplicar el modelo de datos se obtiene una estructura de datos llamada Esquema

31 Sirve para establecer una visión global de los datos de una organización o de un sistema de información, en un nivel de abstracción próxima al usuario e independiente de las características físicas del equipo donde se vaya a instrumentar el sistema. Constituye el Nivel Conceptual de la arquitectura ANSI Consiste en describir la información de la organización mediante la definición de Entidades y asociaciones o interrelaciones entre ellas

32 Años sesenta Codd introdujo la teoría de las relaciones en el campo de las bases de datos. El modelo Relacional correspondería al nivel lógico/externo de la arquitectura ANSI

33 Las interrelaciones entre entidades serán siempre de grado dos. En el caso de que sean de grado mayor que dos, habrá que descomponerlas en relaciones binarias En caso M:N se creará una entidad auxiliar que sirva de nexo de unión entre las dos entidades iniciales obteniendose dos relaciones tipo 1:N. La clave primaria de esta nueva entidad estará formada por la concatenación de las claves primarias de cada una de las entidades originales.

34 Las interrelaciones N:M se transforman en una tabla cuya clave primaria será la concatenación de los atributos principales de las entidades que asocia; estos atributos serán claves ajenas que referencian a las respectivas tablas donde son claves primarias. Los atributos de la interrelación serán columnas de la tabla

35 El diccionario de datos es una lista organizada de todos los datos pertinentes al sistema, con un conjunto de definiciones precisas y rigurosas para que tanto el analista como el usuario se entiendan. En el DD se : Describe el significado de los flujos y almacenes que muestran los DFD’s Describe la composición de los paquetes de datos que se mueven a través de los flujos de datos Describe la composición de los paquetes de datos en los almacenes

36 Se describe el significado, objetos que forman la interrelación, cardinalidad de la interrelación (límites inferior y superior) Ejemplo: compra=* asociación entre un cliente y uno o más artículos *

37 Historia de la Vida de las Entidades

38 Entidades de datos:Entidades de datos: Cualquier objeto sobre el que el sistema guarda información. Las entidades de datos están caracterizadas por sus atributos.Cualquier objeto sobre el que el sistema guarda información. Las entidades de datos están caracterizadas por sus atributos. Eventos:Eventos: Cualquier suceso que activa un proceso que actualiza datos en el sistema. Se pueden considerar tres tipos de eventos:Cualquier suceso que activa un proceso que actualiza datos en el sistema. Se pueden considerar tres tipos de eventos: Se utilizan nodos como medio para agrupar un conjunto de eventos que afectan a una entidad en la representación gráficaSe utilizan nodos como medio para agrupar un conjunto de eventos que afectan a una entidad en la representación gráfica Cajas vacías:Cajas vacías: Representan el caso en que ningún evento afecta a la entidadRepresentan el caso en que ningún evento afecta a la entidad

39 Cada flujo y almacén de datos han de estar definidos en el DD. Cada flujo y almacén de datos definidos en el DD deben aparecer en alguna parte del DFD. Cada proceso del DFD ha de estar asociado a un DFD de un nivel más bajo o relacionado con una especificación de proceso (EP).

40 Su objetivo principal es la obtención de un conjunto de especificaciones formales del sistema a desarrollar, que describan en detalle: Las necesidades de información que debe satisfacer el nuevo sistema La Arquitectura lógica del nuevo sistema, de forma independiente del entorno técnico

41  Ámbito y alcance del Proyecto  Lista de usuarios participantes  Descripción del sistema actual  Modelo Físico  Lista de problemas y necesidades  Modelo lógico actual de procesos  Esquema lógico actual de datos

42  Especificación del Sistema propuesto  Especificación de subsistemas  Esquema Lógico de Datos del Sistema  Modelo de eventos del sistema  Interfaces de usuario

43 Diseñar la arquitectura física del sistema Diseñar el esquema externo de datos Especificar el entorno tecnológico del sistema Completar el plan de pruebas del sistema Completar especificaciones de diseño