Ingenieria del software

ContenidoCronograma de Evaluaciones

Bibliografía

Unidad I: Introducción a Ingeniería de Software. Breve Introducción:

Concepto de Ingeniería de Sistemas, Características del software, Concepto de Ingeniería de Software, Formalización del proceso de desarrollo, Uso de prototipos, El modelo en espiral, Combinación de modelos, Mantenimiento del Software, Garantía de calidad de software.

Introducción a la gestión de proyectos de desarrollo de software:

Métricas de Software, Métodos tradicionales de estimación y planificación, Gestión de la calidad del software, Gestión y control de riesgo, Herramientas de ayuda a la gestión

25/04/23Prof. Marisela Zabala Parada PAR 2011 III 2

Unidad II : Diseño y Especificación del Software.

Especificación del Software: Modelado de sistemas, Análisis de requisitos de software, Notaciones para la

especificación, Documento de especificación de requisitos, Ejemplos de especificaciones.

Fundamentos y técnicas generales para el diseño de software: Introducción y conceptos básicos, Notaciones para el diseño, Documentos

del diseño, Descomposición modular, Técnicas de diseño funcional descendente, Técnicas de diseño basado en abstracciones, Técnicas de diseño orientadas a objetos, Técnicas de diseño de datos, Diseño de bases de datos relacionales, Diseño de bases de datos de objetos.

Codificación y Pruebas: Codificación del diseño, Lenguajes de programación, Desarrollo histórico,

Criterios de selección, Aspectos metodológicos, Técnicas de pruebas, Estrategias de integración, Pruebas de sistema.


Unidad III : Análisis de Sistemas.

Investigación Preliminar: Factibilidad Técnica, Factibilidad Operacional y Factibilidad Económica.

Determinación de requerimientos: Determinación de requerimientos de procesos y datos.

Análisis del flujo de los datos: Anticipación de requerimientos, Investigación de requerimientos,

Especificación de requerimientos, Diagramas de Flujo de datos, Diccionario de Datos

407/09/2011Prof. Marisela Zabala Parada PAR 2011 III

Unidad IV : Auditoria de Sistemas y Prueba de Software.

Introducción a la Auditoria de Sistemas: Conceptos de Auditoria de Sistemas, Tipos de Auditoria, Objetivos

Generales de una Auditoria de Sistemas, Justificativos para efectuar una Auditoria de Sistemas.

Controles: Clasificación general de los controles, Controles Preventivos y Controles

detectivos, Controles Correctivos.

Pruebas de Sistemas mediante el estudio de casos prácticos.

5Prof. Marisela Zabala Parada PAR 2011 III 25/04/23

Fecha Contenido Tipo Peso Corte

27/09 Unidad I Taller Pareja+Asistencia 20% I

04/10 Unidad I Plan de Proyecto 10% I25/10 Unidad II Diseño del Proyecto+Asistencia 15% II01/11 Unidad III Análisis del Proyecto 15% II22/11 Unidad IV Escrita Individual+Asistencia 20% III06/12 Unidad IV Auditoria del Sistema 20% III



1. Software de sistemas : Introduccion a la programación de sistemas / Leland L. Beck ; traducido por Luis Fernando Castro Careaga.

2. Software orietado a objetos. / Ann L. Winblad, D Edwards, D. Samuel; Traducido por: Ramon Ruiz Ayuso.

3. Ingenieria de software / D.C. Ince, ; traducido por Ernesto Morales Peake.

4. Ingeniería del software: Un enfoque práctico. / Roger S. Pressman ; Traducción de José María Troya, Luis Hernández Yañez ; revisión técnica Antonio Vaquero Sánchez.

5. Desarrollo de Software con C++ / Russel Winder; Traducido por: Rafael Garcia Bermejo Giner.

6. Análisis y diseño de sistemas / Kenneth E. Kendall, Julie E. Kendall ; traducción Héctor López Hernández ; revisión técnica Humberto Cárdenas Anaya, Jorge Rodríguez R.

7. Análisis y diseño de sistemas de información / James A. Senn ; Traducido por José Lara Portal, Revisión técnica de Gerardo Quiroz Vieyra.

8. Análisis y diseño orientado a objetos con aplicaciones. / Grady Booch; Traducido por: Juan Cueva.

Introducción a Ingeniería de Software

Conjunto de actividades y resultados asociados que producen un producto de software, las cuales son ejecutados por los ingenieros de software.

Disciplina de la ingeniería que comprende todos los aspectos de la producción del software, que se diferencia de la ingeniería del software en que esta se enfoca en el desarrollo de sistemas informáticos, incluyendo hardware, software e ingeniería de procesos, estando la ingeniería del software inmerso en esta.

Las organizaciones dedicadas al desarrollo de sistemas se centran en la regla de las 4 “C”

Disciplina de la ingeniería que comprende todos los aspectos de la producción del software desde las etapas iniciales de la especificación del sistema hasta el mantenimiento de esta después que se utiliza.

En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver los problemas, la informática aporta herramientas y procedimientos sobre los que se apoya la ingeniería de software.

Mejorar la calidad de los productos de software. Aumentar la productividad y trabajo de los ingenieros del software. Facilitar el control del proceso de desarrollo de software. Suministrar a los desarrolladores las bases para construir software de

alta calidad en una forma eficiente. Definir una disciplina que garantice la producción y el mantenimiento

de los productos software desarrollados en el plazo fijado y dentro del costo estimado.

A diferencia del hardware el software se caracteriza por:• No se desgasta ni envejece, y por este motivo no requiere

reparaciones ocasionales.• Su duplicación es poco costosa, lo caro es el desarrollo• Puede ser modificado fácilmente, tanto que es necesario un

control de versiones

La Ingeniería del Software comprende las técnicas y procedimientos de la ingeniería para el desarrollo del software.

Esta solo se plantea la actividad de programación, previamente son necesarias las fases de análisis y diseño y posteriormente la integración y la verificación, incluso el mantenimiento cuando el producto ya está en explotación.

•Mantenimiento: Se refiere a los cambios asociados a la corrección de errores, adaptaciones y requisitos cambiantes. Estos pueden darse en:

•Corrección: Corrige los errores (bugs) que se hayan pasado en el proceso de desarrollo.

•Adaptación: Modifica el software para adaptarlo a los cambios de su medio ambiente.

•Mejora: Modifica el software agregándole nuevas funciones no especificadas en los requisitos originales.

•Prevención (Reingeniería): Hace cambios en el programa para que se pueda corregir, adaptar y mejorar más fácilmente.

La ingeniería supone la existencia de procesos bien establecidos para la realización de actividades de desarrollo, construcción, fabricación, entre otros.

El ciclo de vida es el proceso de desarrollo y mantenimiento del software. Según el modelo elegido se describen un conjunto de actividades para llevar a cabo el ciclo de vida.

Los modelos clásicos: MODELO EN CASCADA y MODELO EN V.

Prácticamente identifican actividades similares y sólo se diferencian en la forma de presentación.

25/04/23Prof. Marisela Zabala Parada

PAR 2011 III


PAR 2011 III

ANÁLISIS, determinar qué debe hacer el software en base a su especificación.

DISEÑO, descomponer y organizar el sistema para que los módulos puedan ser desarrollados por separado.

CODIFICACIÓN, escribir el código fuente de cada módulo y realizar sobre ellos las pruebas necesarias.

INTEGRACIÓN, combinar todos los módulos y probar el sistema completo antes de pasar a su explotación.

MANTENIMIENTO, durante la explotación es necesario realizar cambios ocasionales bien para corregir errores o para introducir mejoras, se trata de aislar cada fase de las otras, lo que facilita la especialización de los desarrolladores.

Al final de cada fase se requiere un proceso de revisión para evitar que los errores se propaguen a fases posteriores provocando la vuelta atrás.

Cada fase debe generar una información de salida precisa y suficiente:◦ DOCUMENTOS DE REQUISITOS DEL SOFTWARE (SRD), es una

especificación precisa y completa a partir de los requisitos establecidos por el cliente.

◦ DOCUMENTO DE DISEÑO DEL SOFTWARE (SDD),descripción de la estructura global del sistema, especificación de qué debe hacer cada uno de los módulos y de cómo se combinan.

◦ CÓDIGO FUENTE, el programa debidamente comentado (documentación interna).

◦ SISTEMA SOFTWARE, el ejecutable producto dela fase de integración y la documentación de las pruebas realizadas.

◦ DOCUMENTOS DE CAMBIOS, después de cada modificación realizada en la fase de mantenimiento: problema detectado y solución adoptada

Incluye fases similares a las del modelo en cascada pero de forma jerárquica. En horizontal se representa el avance en el desarrollo y en vertical el nivel de detalle.

VERIFICACIÓN, comprobación de que una parte del sistema cumple con sus especificaciones.

VALIDACIÓN, comprobación de que un elemento satisface las necesidades del usuario identificadas durante el análisis.

En los modelos clásicos se insiste en las actividades de revisión de resultados al final de cada fase para evitar la vuelta atrás, que no se contempla de una forma organizada y resulta muy costosa. Están orientados a una forma de desarrollo lineal.

PROTOTIPO, es un sistema auxiliar que permite probar experimentalmente soluciones parciales a los requisitos del sistema

Para que el coste de desarrollo del prototipo sea bajo en relación al del sistema final podemos:◦ Limitar las funciones◦ Limitar su capacidad◦ Limitar su eficiencia◦ Evitar limitaciones de diseño, utilizando un hardware más

potente que el que ejecutará el sistema final◦ Reducir la parte a desarrollar

Su finalidad es solo adquirir experiencia, no se aprovechan como producto (usar y tirar). Se denominan maquetas cuando su funcionalidad o capacidad es muy limitada.

El sistema final se codifica totalmente partiendo de cero, no se aprovecha el código del prototipo.

Lo importante de estos prototipos es que se desarrollen en poco tiempo.

En este caso se intenta aprovechar al máximo el código del prototipo, y para ello se emplea el mismo hardware/software del sistema final.

Se realizan fases de análisis y diseño parcial, que se van ampliando hasta construir el sistema final mediante adiciones sucesivas.

Se puede considerar un modelo en cascada en bucle, de manera que en cada iteración se va avanzando en el desarrollo.

HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS, se emplean lenguajes de 4ª generación, que son de alto nivel y de tipo declarativo. También se emplean lenguajes de especificación, como VDM y Z. Si disponemos del compilador correspondiente podemos obtener automáticamente el código del prototipo.

En el desarrollo de prototipos es clave la reutilización de software.

Puede considerarse como un refinamiento del modelo evolutivo general que introduce el análisis de riesgo como elemento fundamental para guiar la evolución del proceso de desarrollo.

En la dimensión radial se representa el esfuerzo realizado en el desarrollo (siempre creciente).

En cada iteración 4 fases:◦ PLANIFICACIÓN, determina que parte del desarrollo se

abordará en ese ciclo.◦ ANALISIS DE RIESGO, evaluar diferentes alternativas para

esa parte del desarrollo seleccionando la más ventajosa y tomando precauciones para evitar los posibles inconvenientes.

◦ INGENIERÍA, las actividades de los modelos clásicos◦ EVALUACIÓN, se analizan los resultados de la fase de

ingeniería.


PAR 2011 III 39

El mantenimiento no representa una actividad específica, sino que consiste en rehacer parte de las actividades correspondientes a las otras fases del desarrollo para introducir cambios sobre una aplicación ya en fase de explotación.

MANTENIMIENTO CORRECTIVO, su finalidad es corregir errores que no fueron detectados en el desarrollo del producto.

MANTENIMIENTO ADAPTATIVO, modificar una aplicación para adaptarla a las nuevas necesidades del entorno.

MANTENIMIENTO PERFECTIVO, se trata de ir obteniendo versiones mejoradas del producto


PAR 2011 III 40

Breve IntroducciónBreve Introducción

Gestión de CambiosGestión de Cambios El mantenimiento supone la realización de una serie de cambios

sucesivos.

Si afectan a la mayor parte del sistema se puede plantear como un nuevo desarrollo.

Cada cambio debe ser documentado con:◦ INFORME DEL PROBLEMA, que ocasiona el cambio. Suele ser

propuesto por el cliente.◦ INFORME DE CAMBIO, describe la solución dada al problema y el

cambio realizado.

REINGENIERÍA, es necesaria cuando el desarrollo de una aplicación no está documentado y se dispone solamente del código. Se llama también ingeniería inversa porque supone reconstruir y documentar las fases de análisis y diseño llegando a la estructura modular de la aplicación y las dependencias entre módulos y funciones. Estas actividades organizan y documentan un sistema deficiente.


PAR 2011 III 41


Garantía de calidadGarantía de calidad Para evaluar la calidad son necesarias técnicas de aplicación de métricas

precisas tanto sobre los productos software como a sus procesos de desarrollo.

McCall propone un esquema basado en valoraciones a 3 niveles:◦ FACTORES, valoración significativa de la calidad en base a los criterios

establecidos.◦ CRITERIOS, aspectos de nivel intermedio que influyen en los factores de

calidad.◦ MÉTRICAS, mediciones puntuales de determinadas características del

producto.

Entre los factores de calidad tenemos:◦ CORRECCIÓN, grado en que cumple con las especificaciones.◦ FIABILIDAD, grado de ausencia de fallos.


PAR 2011 III 42


Garantía de calidadGarantía de calidad◦ EFICIENCIA, relación entre la cantidad de resultados y los recursos

requeridos.◦ SEGURIDAD, dificultad para el acceso a datos por personas no

autorizadas.◦ FACILIDAD DE USO, esfuerzo requerido para el aprendizaje de la

aplicación.◦ MANTENIBILIDAD. facilidad para corregir el producto en caso

necesario.◦ FLEXIBILIDAD, facilidad para modificar el producto.◦ FACILIDAD DE PRUEBA, depende del esfuerzo requerido para

comprobar su corrección o fiabilidad.◦ TRANSPORTABILIDAD, facilidad para adaptar el producto a otra

plataforma.◦ REUSABILIDAD, facilidad para usar partes del producto en otros

desarrollos.◦ INTEROPERATIVIDAD, facilidad del producto para trabajar con otros.

Especificación del Software:Modelado de sistemas, Análisis de requisitos de software, Notaciones para la especificación, Documento de especificación de requisitos, Ejemplos de especificaciones.


PAR 2011 III 43

44

El análisis y la definición de los requisitos debe dar lugar a la especificación software, en la que se concretan las necesidades que se desean cubrir y se fijan las restricciones con las que debe trabajar el software.

El modelado de los sistemas tiene como objetivo entender mejor el comportamiento requerido y facilitar la comprensión de los problemas planteados. Se trata de establecer modelos conceptuales que reflejen la organización de la información y las diversas transformaciones que se deben llevar a cabo con dicha información.

Las metodologías de análisis de requisitos tratan de facilitara obtención de uno o varios modelos que detallen el comportamiento deseado del sistema.

45

Un modelo conceptual es una abstracción lógico-matemática del mundo real que facilita la comprensión del problema a resolver. Se trata de ofrecer una visión de alto nivel, sin descender a explicar detalles concretos del mismo. Indica QUÉ hace el sistema y no CÓMO lo debe hacer.

Los OBJETIVOS a cubrir con los modelos son:◦ Facilitar la comprensión del problema◦ Establecer un marco para la discusión que simplifique y

sistematice el análisis◦ Fijar las base para el diseño◦ Facilitar la verificación del cumplimiento de los objetivos del

sistema

46

DESCOMPOSICIÓN. MODELO JERARQUIZADO, aplica el “divide y vencerás”, y así el problema queda dividido en un subconjunto de subproblemas. Se trata de una descomposición funcional que se denomina horizontal o bien se descompone tratando de detallar la estructura, de forma vertical. Para completar el modelado es necesario establecer los interfaces entre las partes del sistema para posibilitar el funcionamiento del sistema global.

APROXIMACIONES SUCESIVAS, podemos tomar como partida el modelo de un sistema similar, y luego mediante la experiencia del analista y el conocimiento del problema que proporciona el experto se irán proponiendo modelos intermedios, discutiendo sus ventajas e inconvenientes.

EMPLEO DE DIVERSAS ANOTACIONES, el lenguaje natural introduce imprecisiones, repeticiones e incluso incorrecciones en el modelo. Es recomendable emplear notaciones gráficas que sean entendibles por todos los que participan en el proyecto. Se suele recurrir a notaciones precisas que combinan texto, tablas, diagramas y gráficos.

47

CONSIDERAR DISITNTOS PUNTOS DE VISTA, en la elaboración del modelo es necesario adoptar un determinado punto de vista. Si así la descripción es insuficiente conviene adoptar más de uno.

REALIZAR UN ANÁLISIS DEL DOMINIO, es decir en campo de aplicación en que se enmarca el sistema a desarrollar. Hay que considerar:◦ Normativa que afecta al sistema◦ Otros sistemas semejantes◦ Estudios recientes en el campo de la aplicación, bibliografía, etc.

Las ventajas de realizar un modelos más general son:◦ Facilitar la comunicación entre el analista y el usuario del sistema, p.e.

usando la misma terminología.◦ Creación de elementos realmente significativos del sistema, si se ajusta

a la normativa específica establecida.◦ Reutilización posterior del software desarrollado.

48

El análisis es la fase de definición del futuro sistema y tiene una importancia decisiva en el desarrollo de todas las etapas posteriores.

Con el análisis de requisitos se trata de caracterizar el problema a resolver. El “cliente” trabaja con el analista para elaborar las especificaciones y posteriormente se encargarán de verificar el cumplimiento de las mismas (contrato).

El análisis debe producir un modelo válido necesario y suficiente para recoger todas las necesidades y exigencias del sistema, así como las restricciones que los limiten. Para una especificación correcta se requiere:◦ Completo y sin omisiones◦ Conciso y sin trivialidades◦ Sin ambigüedades◦ Sin detalles de diseño o implementación◦ Fácilmente entendible por el cliente◦ Separando requisitos funcionales u no funcionales (capacidades mínimas y

máximas, interfaces estándares, recursos necesarios, seguridad, fiabilidad, mantenimiento, etc.

◦ División y jerarquía del modelo global, con el fin de simplificar su comprensión◦ Incluyendo los criterios de validación del sistema, para comprobar si se ajusta al

contrato inicial.

49

Dependiendo de las características y complejidad del sistema se podrán seguir los siguientes pasos:

◦ ESTUDIO DEL SISTEMA EN SU CONTEXTO, análisis del dominio en un contexto globalizador

◦ IDENTIFICACIÓN DE NECESIDADES, detectar necesidades de medios dentro de plazos y presupuestos

◦ ANÁLISIS DE ALTERNATIVAS Y ESTUDIO DE VIABILIDAD, tanto técnica como económica

◦ ESTABLECIMIENTO DEL MODELO DEL SISTEMA, para lo que podemos usar técnicas gráficas, texto, herramientas CASE, etc.

◦ ELABORACIÓN DEL DOCUMENTO DE ESPECIFICACIÓN DE REQUISITOS, dónde se recogen las conclusiones del análisis y sirve de punto de partida para el diseñador.

◦ REVISIÓN CONTINUADA DEL ANÁLISIS, a menudo en las etapas de diseño e implementación se hace necesaria la revisión de alguno de los requisitos, o bien por cambios de criterio del cliente

50

La especificación es una descripción del modelo del sistema a desarrollar.

Se debe usar una notación fácil de entender por el cliente:◦ Lenguaje natural, utilizando explicaciones más o menos

precisas y exhaustivas. Es posible limitar precisiones y ambigüedades si se establecen reglas de uso del lenguaje.

◦ Diagramas de flujo de datos◦ Diagramas de transición de estados◦ Descripciones funcionales. Pseudocódigo. Se emplea un

preciso lenguaje natural estructurado. No se debe detallar demasiado el cómo, pues esto corresponde a la fase de diseño, donde se usan lenguajes estructurados.

◦ Descripción de datos, se trata de detallar la estructura interna de los datos que maneja el sistema. En la metodología Yourdon se conoce como diccionario de datos, incluyendo nombre de cada dato, utilización y estructura.

◦ Diagramas de modelos de datos

51

Se trata de realizar un modelo gráfico para representar el flujo de datos que entra en el sistema, las transformaciones que debe realizar y la salida producida. También se representan las entidades externas la sistema que producen o consumen datos. El DFD inicial es el de contexto, posteriormente y de forma jerárquica se van desarrollando otros DFD’s que detallan las transformaciones, las entradas y salidas del diagrama detallado deben coincidir con el proceso correspondiente.

Recoge de forma estática los procesos, dónde en el último nivel de refinamiento se especifican en lenguaje natural estructurado, y su interrelación.

52

Describe el comportamiento dinámico del sistema basándose en sus estados más importantes.

Al igual que en los autómatas de estados finitos, los eventos motiva el cambio de estado del sistema.

53

Se trata de organizar e interrelacionar los datos que utiliza el sistema.

El MODELO ENTIDAD-RELACIÓN permite definir todos los datos y establecer las relaciones que deben existir entre ellos.

54

El documento o la especificación de requisitos (SRD o SRS) recoge de forma integral los resultados del análisis.

Puede haber documentos previos al SRD, como estudios de viabilidad o de alternativas posibles.

El SRD debe ser revisado con cierta frecuencia durante el desarrollo y debe facilitar la varificación de las especificaciones (contrato).

Diversos organismos de estandarización hacen propuestas sobre la estructura del SRD: IEEE, DoD, etc. Vemos el modelo de SRD de la Agencia Espacial Europea. Dependiendo de las características y complejidad del proceso tal vez no sea necesario cubrir todos los apartados.

55

1. Introducción Objetivo: objetivos, participantes, calendario,... Ámbito, identificará y dará nombre al producto Definiciones, siglas y abreviaturas Referencias, la descripción bibliográfica de los documentos referenciados. Panorámica del documento

2. Descripción general Relación con otros proyectos, similares o complementarios Relación con proyectos anteriores o posteriores Objetivo y funciones Consideraciones de entorno Relaciones con otros sistemas, que utilicen entradas o salidas

indirectas de información Restricciones generales: metodologías, lenguajes, de hardware,... Descripción del modelo, es el apartado más extenso y más

importante. Se utilizan todas las notaciones y herramientas disponibles

56

3. Requisitos específicos, lista detallada y completa de los requisitos del sistema, indicando su grado de cumplimiento (obligatorio, recomendable, opcional. No incluir aspectos de diseño o desarrollo, ni tampoco soluciones particulares que no sean obligadas Requisitos específicos, QUÉ debe hacer el sistema

especificando el tratamiento de la información. Requisitos de interfase, conexión con otros sistemas con

los que interactúa (bases de datos, ficheros, SSOO,...). Requisitos de operación, es decir, del interfaz de usuario Requisitos de capacidad, volumen procesador, tiempo

respuesta, tamaño ficheros. Se debe cuantificar para el peor, el mejor y el caso más habitual.

Requisitos de verificación, que debe cumplir el sistema para que se posible verificar su corrección

57

Requisitos de pruebas de aceptación Requisitos de recursos, instalaciones y elementos

necesarios para el funcionamiento del sistema Requisitos de documentación Requisitos de transportabilidad, para adaptalo a otras

plataformas Requisitos de calidad, que no hayan sido recogidos en

otros apartados Requisitos de fiabilidad, imponiendo un límite aceptable de

fallos Requisitos de mantenibilidad Requisitos de seguridad, contra utilización indebida Requisitos de salvaguarda, para evitar consecuencias

graves en equipos o en personas◦ APENDICES, para complementar el contenido del documento

64

Descripción o bosquejo de alguna cosa hecho por palabras. En un sistema software la realización del diseño parte del

SRD y no es nada trivial. Cuando no se tiene experiencia en el desarrollo concreto se hace de forma iterativa mediante ensayo y error, en caso contrario se aprovecha el “know-how” (saber hacer).

Las técnicas para realizar diseños nuevos son empíricas y no están suficientemente formalizadas, mientras que para proyectos ya conocidos, como los de gestión, existen herramientas tales como lenguajes de 4ª generación.

En el diseño se establece el CÓMO debe funcionar el sistema, determinando la organización y la estructura del software.

65

DISEÑO ARQUITECTÓNICO, se abordan los aspectos estructurales y de organización del sistema, y su posible división en subsistemas

DISEÑO DETALLADO, organización y estructura de los módulos DISEÑO PROCEDIMENTAL, organización de las operaciones o

servicios que ofrecerá cada módulo. Se suele realizar en pseudocódigo o PDL, pero desarrollando sólo los aspectos más relevantes del algoritmo

DISEÑO DE DATOS, organización de la base d edatos del sistema. Se parte de los diagramas E-R.

DISEÑO DE LA INTERFAZ DE USUARIO, organizar y facilitar la utilización del sistema por parte del usuario

El resultado de estas actividades debe plasmarse en el Documento de Diseño Software (SDD)

66

ABSTACCIÓN, identificar los elementos significativos del sistema y abstraer la utilidad específica de cada uno◦ ABSTRACCIONES FUNCIONALES, sirven para crear expresiones parametrizadas

usando funciones o procedimientos◦ TIPOS ABSTRACTOS, junto con el tipo de datos se deben crear los métodos que

manejan estos datos◦ MÁQUINAS ABSTRACTAS, definición formal del comportamiento de una máquina

MODULARIDAD, el diseño modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. Sus ventajas: claridad, reducción de costos y reutilización

REFINAMIENTO, a partir de una idea no muy concreta se va refinando mediante aproximaciones hasta el detalle

ESTRUCTURAS DE DATOS, para organizar la información que maneja el sistema: registros, conjuntos, listas, pilas, colas, árboles, grafos, tablas, ficheros, ...

OCULTACIÓN, de la organización de los datos internos y de los detalles del algoritmo, se muestra en el interfaz sólo aquello que resultará invariable ante cambios. Ventajas: depuración, mantenimiento, ...

67

Debe resultar precisa, clara y fácil de interpretar. Se emplean notaciones formales cuasimatemáticas

NOTACIONES ESTRUCTURALES, se desglosa y estructura el sistema en sus partes◦ DIAGRAMAS DE BLOQUES

◦ CAJAS ADOSADAS

68

Describen la estructura de los sistemas software como una jerarquía de módulos, reflejando sólo su organización estática

RECTÁNGULO, módulo

LÍNEA, relación entre módulos, el superior utiliza el módulo inferior

ROMBO, opcional

ARCO, repetitiva

CIRCULO CON FLECHA, envio de datos o información de control (correcto, repetir, desconectar, etc)

69

Se muestra primero la jerarquía entre los módulos del sistema

Y en los diagramas HIPO de detalle hay 3 zonas: Entrada, Proceso y Salida

70

El proceso de diseño es sistemático y se lleva a cabo en tres pasos:

•Especificación de la estructura de datos de entrada y de salida

•Obtención de la estructura del programa

•Expansión de la estructura del programa para lograr el diseño detallado

71

Describen las características estáticas del sistema, tales como la organización de la información, sin tener en cuenta su evolución durante el funcionamiento del sistema.

Las notaciones son las mismas que se emplean en la especificación:◦ DICCIONARIO DE DATOS, dónde se detalla la estructura

interna de los datos que maneja el sistema. En el diseño se amplía y se completa el diccionario de la especificación hasta el nivel de detalle necesario para iniciar la codificación.

◦ DIAGRAMAS ENTIDAD-RELACIÓN, definiendo las relaciones entre datos y la organización de la información. Se amplia y detalla el diagrama de la especificación con las nuevas entidades y relaciones.

72

Permiten describir el funcionamiento del sistema durante su funcionamiento.

Las notaciones son las misma utilizadas en la especificación:◦ DIAGRAMAS DE FLUJO DE DATOS, serán mucho más

exhaustivos que los de la especificación.◦ DIAGRAMAS DE TRANSICIÓN DE ESTADOS, más

detallados que reflejen las transiciones entre estados internos.

◦ LENGUAJE DE DESCRIPCIÓN DE PROGRAMAS (PLD), permite realizar la especificación funcional del sistema.

73

Permiten un enfoque globalizado del diseño atendiendo a aspectos estáticos (datos), dinámicos (operaciones) y de estructura del sistema.DIAGRAMAS DE ABSTRACCIONES, se contemplan dos tipos de abstracciones: las funciones y los tipos abstractos de datos.

En una abstracción se distinguen 3 partes:

NOMBRE, es su identificador

CONTENIDO, dónde se define la organización de los datos

OPERACIONES, para manejar el contenido de la abstracción

Las abstracciones funcionales (funciones o procedimientos), sólo tiene la parte de operación.

El dato encapsulado tiene como el tipo abstracto contenido y operaciones, pero no permite declarar otras variables de su mismo tipo.

En los diagramas se muestra la relación jerárquica entre abstracciones, de manera que la abstracción superior utiliza la inferior.

74

Se emplea una terminología distinta, pero las similitudes con los diagramas de abstracciones es muy grande, excepto que:

1. No existe nada equivalente a los datos encapsulados ni a las abstracciones funcionales en el modelo de objetos

2. En los diagramas de objetos hay relaciones de herencia

De acuerdo con las propiedades de los objetos podemos tener relaciones especiales entre ellos:•CLASIFICACIÓN, ESPECIALIZACIÓN O HERENCIA

•COMPOSICIÓN, permite describir un objeto mediante los elementos que lo forman

75

1. INTRODUCCIÓN – Para dar una visión general de todo el documento. Los contenidos de los apartados como en el SRD◦ 1.1 Objetivo ... ◦ 1.2 Ámbito ◦ 1.3 Definiciones, siglas y abreviaturas ◦ 1.4 Referencias

2. PANORÁMICA DEL SISTEMA, visión general de los requisitos funcionales y de otro tipo del sistema a diseñar 3. CONTEXTO DEL SISTEMA, si posee conexiones con otros

◦ 3.n Definición de interfaz externa 4. DISEÑO DEL SISTEMA, se describe el nivel superior del diseño del sistema

◦ 4.1 Metodología de diseño de alto nivel ◦ 4.2 Descomposición del sistema , primer nivel de descomposición del sistema en sus componentes principales

5. DISEÑO DE LOS COMPONENTES, se procede a la decripción detallada de l,os componentes mencionados en 4.2◦ 5.n Identificador del componente ◦ 5.n.l Tipo (subprograma, módulo, procedimiento, proceso, datos◦ 5.n.2 Objetivo, o necesidad de que exista el componente◦ 5.n.3 Función , lo que hace el componente◦ 5.n.4 Subordinados, se enumeran todos los componentes que utiliza◦ 5.n.5 Dependencias y su naturaleza: invocación de operación, datos compartidos, inicialización, creación, etc.◦ 5.n.6 Interfases, de cómo otros componentes interactúan con éste◦ 5.n.7 Recursos , elementos usados por el componente◦ 5.n.8 Referencias, que se han utilizado en el texto◦ 5.n.9 Proceso, algoritmos o reglas que utiliza el componente para realizar su función ◦ 5.n.l0 Datos, descripción de los datos, su tipo, sus valores iniciales, se puede realizar con un diccionario de datos

6. VIABILIDAD y RECURSOS ESTIMADOS 7. MATRIZ REQUISITOS/COMPONENTES, se pone en las filas los requisitos y en las columnas los componentes

76

Parte 1. DESCRIPCIÓN GENERAL1. INTRODUCCIÓN1.1 Objetivo1.2 Ámbito1.3 Definiciones, siglas y abreviaturas1.4 Referencias1.5 Panorámica

2. NORMAS, CONVENIOS y PROCEDIMIENTOS2.1 Normas de diseño de bajo nivel2.2 Normas y convenios de documentación2.3 Convenios de nombres (ficheros, programas, módulos, etc.)2.4 Normas de programación2.5 Herramientas de desarrollo de software

Parte 2. ESPECIFICACIONES DE DISEÑO DETALLADOn. Identificador del componenten.l Identificadorn.2 Tipon.3 Objetivon.4 Funciónn.5 Subordinadosn.6 Dependenciasn.7 Interfasesn.8 Recursosn.9 Referenciasn.l0 Proceson.ll Datos

APÉNDICE A. LISTADOS FUENTEAPÉNDICE E. MATRIZ REQUISITOS/COMPONENTES

Ingenieria del software

Documents

Transcript of Ingenieria del software