Concepto de Ingeniería de Sistemas Concepto de sistema,
conjunto de cosas que ordenadamente relacionadas entre sí
contribuyen a un determinado objeto. De forma recursiva, las
partes de un sistema pueden ser consideradas como nuevos sistemas
(subsistemas). Los sistemas informáticos están
compuestos por ordenadores y sus periféricos. Entre ellos
podemos distinguir dos tipos de subsistemas: Sistemas Hardware,
son los elementos materiales, los que se pueden tocar. Sistemas
Software, los programas que gobiernan el funcionamiento del
computador. El objetivo de los sistemas informáticos es el
tratamiento de la información: almacenamiento,
elaboración y presentación de datos. De esta forma
se automatizan determinadas acciones. En la concepción del
sistema informático no solo se decide el trabajo a
realizar, sino también cómo ha de ser utilizado por
los usuarios.
Concepto de Ingeniería del Software Características
del software (lo contrario para el hardware): 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 ingenieriles para el
desarrollo del software. La IS no se plantea solo una 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
manteniendo cuando el producto ya está en
explotación. (CICLO DE VIDA). Inicialmente la tarea de
desarrollo era realizada individualmente por hábiles
creativos, de forma poco disciplinada. El trabajo en equipo
supone la división y organización del trabajo
utilizando metodologías de desarrollo. En los 70 y los 80
empiezan a usarse herramientas CASE (Computer Aided Software
Engineering). En los 90 IPSE e ICASE.
La crisis del Software Se produce cuando surge la necesidad de
desarrollar aplicaciones software demasiado complejas, a mediados
de los 60. Para superar la crisis: Aparición de
metodologías concretas de desarrollo Concepción de
la Ingeniería del Software como disciplina Trabajo en
equipo y especialización (analistas, programadores, …)
No se ha llegado a una situación estable, sino a una
evolución permanente con avances continuos en la IS,
forzados por el rápido abaratamiento y aumento de
capacidad del hardware.
Mitos del Software El hardware es mucho más importante que
el software El software es fácil de desarrollar El
software consiste exclusivamente en programas ejecutables El
desarrollo del software es sólo una labor de
programación Es natural que el software contenga
errores
Formalización del proceso de desarrollo La
ingeniería supone la existencia de procesos bien
establecidos para la realización de actividades de
desarrollo, construcción, fabricación, etc. 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 MODELO EN V
Prácticamente identifican actividades similares y
sólo se diferencian en la forma de
presentación.
MODELO EN CASCADA
MODELO EN CASCADA ANÁLISIS, determinar qué debe
hacer el software -> 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.
MODELO EN CASCADA AMPLIADO
MODELO EN CASCADA 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
MODELO EN V
MODELO EN V AMPLIADO
MODELO EN V 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 elmento satisface las necesidades
del usuario identificadas durante el análisis.
PROTOTIPOS 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
PROTOTIPOS RÁPIDOS 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.
PROTOTIPOS RÁPIDOS
PROTOTIPOS EVOLUTIVOS 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.
PROTOTIPOS EVOLUTIVOS
MODELO EN ESPIRAL 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.
MODELO EN ESPIRAL
MANTENIMIENTO DEL SOFTWARE 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
GESTIÓ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.
GARANTÍ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
EFICIENCIA, reilació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
PLAN DE GARANTÍA DE CALIDAD (SQAP) Es un documento formal
para organizar el proceso de desarrollo software de manera que se
asegure la calidad del producto final. Debe contemplar:
Organización, dirección y seguimiento de los
equipos de desarrollo Modelo de ciclo de vida a seguir,
detallando fases y actividades Documentación requerida,
determinando contenido y guión de cada documento
Revisiones y auditorias, para garantizar que las actividades y
los documentos son correctos Organización de las pruebas,
a distintos niveles Organización de la etapa de
mantenimiento, determinando cómo gestionar la
realización de cambios
REVISIONES Consiste en inspeccionar el resultado de una actividad
para determinar si es aceptable o contiene defectos que han de
ser subsanados. Las revisiones deben ser formalizadas y
contempladas en el modelo de ciclo de vida: Deben ser realizadas
por un grupo de personas y no individualmente El grupo de be ser
reducido Debe ser imparcial, nada que ver con los desarrolladores
Se debe revisar el producto, pero no el productor ni el proceso
de producción Se debe establecer de antemano una lista
formal de comprobaciones Se debe levantar acta de la
reunión de revisión, recogiendo las decisiones
tomadas
PRUEBAS Consiste en hacer funcionar el producto o una parte de
él y comprobar si los resultados son correctos. No permite
garantizar la calidad del producto. En general no es posible
probar un producto de forma exhaustiva, debido a su
complejidad.
GESTIÓN DE CONFIGURACIÓN CONFIGURACIÓN,
disposición de las partes que componen una cosa y le dan
su peculiar figura. La CONFIGURACÏÓN SOFTWARE se
refiere a la manera en que diversos elementos se combinan para
construir un producto software. Se han de combinar todos los
elementos que intervienen en el desarrollo: Documentos del
desarrollo Código fuente Programas, datos y resultado de
las pruebas Manuales de usuario Documentos de mantenimiento,
informes de problemas y cambios Prototipos intermedios Normas
particulares del proyecto Dado que los elementos software van
evolucionando a lo largo del desarrollo se requiere: Control de
versiones, almacenar de forma organizada las sucesivas versiones
de cada elemento de la configuración. Control de cambios,
garantizar que las diferentes configuraciones del software se
componen de elementos compatibles entre sí (línea
base).
NORMAS Y ESTÁNDARES IEEE, Institute of Electrical and
Electronics Engineer de USA [IEEE93] DoD, Departament od Defense
de USA [DoD88] ESA, Agencia Europea del Espacio [ESA91] ISO,
organismo internacional de normalización (International
Standars Organization). En España AENOR. METRICA-2,
desarrollada por el Consejo Superior de Informática del
MAP. Se basa en la metodología de análisis y
diseño de Yourdon/DeMarco.
MODELADO DE SISTEMAS 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.
CONCEPTO DE MODELO 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 lato 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 de l 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
TÉCNICAS DE MODELADO (I) 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.
TÉCNICAS DE MODELADO (II) 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.
ANÁLISIS DE REQUISITOS DE SOFTWARE 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.
TAREAS DEL ANÁLISIS 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
NOTACIONES PARA LA ESPECIFICACIÓN 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 como PLD.
Descripción de datos, de 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
DIAGRAMAS DE FLUJO DE DATOS (DFD) 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.
DIAGRAMAS DE TRANSICIÓN DE ESTADOS 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.
DIAGRAMAS DE MODELO DE DATOS 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.
DOC. DE ESPECIFICACIÓN DE REQUISITOS 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.
MODELO DE SRD 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 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
ESTA PRESENTACIÓN CONTIENE MAS DIAPOSITIVAS DISPONIBLES EN
LA VERSIÓN DE DESCARGA