Metodolog a de Sistemas

Tema 13
Metodologías en el desarrollo de Sistemas de
Software
Prof. Oscar Adolfo Vallejos
Desarrollo de Sistemas de Software
Objetivo
Conceptos en el contexto más amplio de
Software e Ingeniería de Software

Ubicación del Proceso del Análisis y
expresión de Algortimso dentro de lo que
se llama ciclo de vida del software en el
desarrollo de sistemas.

Metodologia del Análisis y Diseño del
Software

Prof. Oscar Adolfo Vallejos
Ingeniría del Software
Definición
La Ingeniería del Software es el área de la ciencia Informática que trata
el
análisis, diseño e implementación de Sistemas de Software.
Un conjunto de programas relacionados, orientados a resolver un
problema del mundo real que, por su complejidad y tamaño,
requieren para su solución un equipo de especialistas.
Programación de una Aplicación  Tarea individual
Ingeniería del Software
 Desarrollo en equipo
Un Sistema de Software se concibe su aplicación durante un tiempo
prolongado, con lo que posteriores modificaciones, correcciones o
ampliaciones al sistema pueden ser realizadas por un equipo de
especialistas diferente del original.
Ingeniería del Software se asocia con la existencia de una metodología
de producción.
Evolución del Software
Década de los 50
Orientación por lotes; Distribución limitada; Software a
medida.
Desde 1960 hasta mediado de los años 70.
Multiprogramación, Multiusuario; Tiempo real; Bases de
datos; Producción software.
Desde mitad de los 70 hasta mitad de los 80.
Sistemas distribuidos; Inteligencia empotrada; Hardware
de bajo coste; Impacto en el consumidor.
Desde mitad de los años 80 hasta nuestros días.
Sistemas expertos; Máquinas de I.A; Arquitecturas
paralelas.
Crisis del Software
La crisis del software es una serie de problemas que hacen que el software no alcance
las expectativas u objetivos esperados por desarrolladores, gestores, clientes, etc.
􀂉 Problemas fundamentales.
􀂉 La sofisticación del hardware no esta acompañada de la del
software.
􀂉 Demanda creciente.
􀂉 Mantenimiento difícil.
􀂉 Problemas de los expertos.
􀂉 Planificación y precios imprecisos.
􀂉 La productividad de la gente del software no se corresponde
con la demanda.
􀂉 La calidad muchas veces no es la adecuada.
􀂉 Motivos de estos problemas
􀂉 No hay tiempo para recoger los datos para el proceso de
desarrollo.
􀂉 Falta comunicación con el cliente.
􀂉 Calidad cuestionable.
􀂉 Dificultad en el mantenimiento.
Fases Genéricas de la IS
Ciclo de Vida clásico de un Sistema de Software
Ciclo de Vida clásico de un Sistema de Software
Análisis y Especificación de requerimientos
Objetivo: relevar, documentar y especificar
los requerimientos del sistema de
software, teniendo especialmente en cuenta
el contexto y el enfoque del
usuario.
Incluye los estudios de factibilidad, riesgo
del proyecto y análisis de costo del
Sistema.
Ciclo de Vida clásico de un Sistema de Software
Diseño y Especificación de Sistema
Dos niveles de diseño del SS.
 La concepción de la arquitectura del
sistema (definición del soporte físico de
contexto y la subdivisión funcional del
sistema en módulos.
 El diseño detallado que refina la
especificación de cada uno de los módlos
y su interfaz de comunicación intra –
módulos y con el usuario.
Ciclo de Vida clásico de un Sistema de Software
Codificación y verificación de los módulos
La producción efectiva del código da cada
uno de los módulos y la prueba
funcional de los mismos con datos que
representen la operatoria normal del
sistema constituyen el núcleo de esta etapa.
Ciclo de Vida clásico de un Sistema de Software
Integración y prueba global del Sistema
Los módulos desarrollados y probados
independientemente deben acoplarse
en un sistema único y realizar un prueba
funcional con el sistema en su
ambiente real, a fin de llegar a la entrega
definitiva del sistema al usuario.
Relación de la prueba global con el
documento de requerimientos inicial.
Ciclo de Vida clásico de un Sistema de Software
Mantenimiento del Sistema
Un concepto de calidad lleva a suponer que una vez
desarrollado, el sistema debería ser estable y libre de
errores. (El producto que se ha entregado es un
producto definitivo y que su tarea ha concluido).
Una vez entregado el SS comienza la etapa tal vez más
compleja.
Los sistemas fallan, se modifican y crecen.
Tres aspectos :
 Errores de la concepción y/o desarrollo del sistema
 Modificaciones a pedido del usuario
 Crecimientos de especificaciones iniciales
Ciclo de Vida clásico de un Sistema de Software
Ciclo de Vida clásico de un Sistema de Software
Tiempos y costos requeridos por las etapas del ciclo de vida
Los costos dependen del tipo de sistema.
 Los errores y modificaciones se hacen mas costosos a medida que
estamos mas avanzados en el desarrollo de sistema.
 En la etapa tradicional de programación y prueba, difícilmente se invierta
mas
del 15% del tiempo y costo de desarrollo.
 La actividad creativa es el diseño. (25 %).
 Es imprescindible contar con equipos multidisciplinarios y con gran
capacidad
de comprensión del ambiente y actividad del usuario en la etapa del
análisis de requerimientos.
 El usuario debe participar efectivamente tanto de la especificación de
requerimientos como de pruebas parciales y finales del sistema.
 La etapa de mantenimiento de los sistemas de software es costosa y de
costo
creciente en el tiempo (35 %).
Ciclo de Vida clásico de un Sistema de Software
Especificación, codificación y prueba de algoritmos
El costo y el tiempo de la actividad de codificación es
relativamente pequeño,
dentro de sistemas complejos.
Objetivo: desarrollar programas eficientes y verificables.
Verificar la corrección controlando el cumplimiento de las
especificaciones
realizadas.
Actualmente se esta haciendo un gran esfuerzo por lograr
la automatización en
la generación del código.
Ciclo de Vida clásico de un Sistema de Software
Método de refinamiento sucesivos
Primero se modeliza el problema del mundo real.
Se analizan las estructura global del sistema y los datos
que representan el
problema.
Se descompone la solución en partes (modularización).
Se desarrolla cada uno de los módulos básicos y se los
prueba.
Si es necesario se sigue refinando cada módulo en sus
partes elementales.
Desde el punto de vista formativo, el criterio de abstraer lo
general y derivar lo particular es muy útil.
En la concepción de software de alta productividad muchas
veces se utilizan módulos previamente desarrollados
(reusabilidad).
Ciclo de Vida clásico de un Sistema de Software
Noción de paradigma de programación
Paradigma procedural (imperativo)
Paradigma de Lógica y Funcional
Paradigma Orientados a Objetos (?)
Paradigmas Orientados a Eventos.
Ciclo de Vida clásico de un Sistema de Software
El rol del especialista en software
 Analizar el problema del mundo real, abstrayendo sus
requerimientos
 Diseñar la posible solución de los mismos (c/htas informáticas).
 Establecer métodos de verificación y prueba de los sistemas de
software
desarrollados.
 Mantener los sistemas asimilando las modificaciones y
ampliaciones
solicitadas por el usuario.
 Tener capacidad de elección entre los recursos que ofrece la
tecnología que sean las mejores para resolver el problema.
Ciclo de Vida clásico de un Sistema de Software
Aspectos importantes de los Sistemas de Software
Cualidades de software que son deseables. Algunas de éstas se aplican tanto
al producto como al proceso usado para producir el producto.
El usuario quiere que el producto de software sea confiable, eficiente y fácil de
usar.
El productor del software quiere que sea verificable, mantenible, portable y
extensible.
El director del proyecto de software quiere que el proceso de desarrollo del
software sea productivo y fácil de controlar.
Cualidades Externas Versus Internas
Las externas son visibles a los usuarios del sistema
Las cualidades internas son aquellas que incumben a los que desarrollan el
sistema.
Cualidades de Producto y de Proceso
Cualidades al proceso
Requiere una planificación cuidadosa de los datos de prueba del programa
antes de comenzar cualquier diseño y desarrollo del sistema, la
confiabilidad del producto aumentará.
Algunas cualidades, tales como la eficiencia, se aplican a ambos (al producto y
al proceso).
Un producto se refiere a lo que es entregado al cliente. (perspectiva del
cliente).
Un Producto no solo es código y manuales, sino, requerimientos, diseño,
arquitectura, configuración, etc. (perspectiva del developer)
La gestión de configuración es la parte del proceso de producción del software
que se ocupa de mantener y controlar la relación entre todas las piezas
relacionadas de las diferentes, diversas versiones de un producto.
Corrección
Un programa es funcionalmente correcto si se comporta de acuerdo a la
especificación de las funciones que debería proveer (especificaciones
de requerimientos funcionales).
La definición de corrección asume que una especificación del sistema
está disponible y que es posible determinar sin ambigüedad si el
programa satisface o no las especificaciones.
Claramente, la corrección es una propiedad conveniente, aconsejable
para los sistemas de software.
La corrección es una propiedad matemática que establece la equivalencia
entre el software y su especificación.
La corrección se puede evaluar a través de una variedad de métodos.
La corrección también puede ser aumentada usando herramientas
adecuadas.
Puede ser mejorada usando algoritmos estándar o usando bibliotecas de
módulos estándar, en lugar de inventar otros nuevos.
Confiabilidad
Informalmente, el software es confiable si el usuario puede contar con él.
Formalmente, confiabilidad del software es la probabilidad de que el software
va a funcionar como debe en un intervalo de tiempo especificado.
La corrección es una cualidad absoluta: cualquier desviación de los
requerimientos hace que el sistema sea incorrecto, sin tener en cuenta
cuan menor o grave sea la consecuencia de la desviación.
La noción de confiabilidad es, por otro lado, relativa: si la consecuencia de un
error del software no es grave, el software incorrecto puede aún ser
confiable.
Se espera de los productos de ingeniería que sean confiables. Este es uno de
los síntomas más sorprendentes de la inmadurez del campo de la
ingeniería de software como una disciplina de ingeniería. [Dijkstra, 1989, “el
término ”bug” que a menudo usan los ingenieros de software, es falta de
profesionalismo].
Los errores de diseño de software son tratados como inevitables. (Se espera
que ocurran).
La ingeniería de software será una disciplina de la ingeniería sólo cuando
podamos lograr confiabilidad del software.
Robustez
Un producto es robusto si se comporta “razonablemente”, aún en
circunstancias que no fueron previstas en las especificaciones de
requerimientos.
La robustez es una cualidad difícil de definir; si pudiéramos establecer con
precisión lo que deberíamos hacer para conseguir que una aplicación
sea robusta, seríamos capaces de especificar su comportamiento
“razonable” completamente. Así, la robustez se convertiría en
equivalente a corrección (o confiabilidad, en el sentido de la Figura).
La cantidad de código dedicado a robustez depende del área de
aplicación.
La robustez y la corrección, están plenamente relacionadas, sin una línea
divisoria definida entre ellas. Si colocamos un requerimiento en la
especificación, su logro se convierte en una cuestión de corrección; si
lo dejamos fuera de la especificación, puede convertirse en una
cuestión de robustez.
Por último, la confiabilidad interviene porque no todos los
comportamientos incorrectos indican problemas igualmente graves;
algunos comportamientos incorrectos pueden, de hecho, ser tolerados.
La corrección, la robustez y la confiabilidad se aplican también al proceso
de producción del software.
Amigabilidad [User Friendliness]
La interfaz con el usuario es un componente importante de la amigabilidad.
Por Ej.: un sistema de software embebido [embedded] no tiene una interacción
con un usuario humano. En lugar de eso, interactúa con el hardware y
quizás otros sistemas de software. En este caso la amigabilidad se refleja
en la facilidad con la cual el sistema puede ser configurado y adaptado al
ambiente del hardware.
En general, la amigabilidad de un sistema depende de la consistencia de las
interacciones de su usuario y operador. La corrección y performance,
afectan a la amigabilidad.
La amigabilidad también es tratada bajo el tema “factores humanos.”
La importante actividad actual de investigación y desarrollo en el área de
interacción estándar con el usuario para sistemas de software llevará al
desarrollo de sistemas más amigables en el futuro.
Verificabilidad
Un sistema de software es verificable si sus propiedades pueden ser
verificables fácilmente.
Por ejemplo, la corrección o la perfomance de un sistema de software, son
propiedades que son interesantes de ser verificadas.
Diseño modular, práctica de codificación disciplinado y el uso de un apropiado
lenguaje de programación, todo esto contribuye a la verificabilidad.
La verificabilidad es usualmente una cualidad interna, aunque algunas veces
se vuelve una cualidad externa.
El alto nivel del estándar de seguridad para un “sistema de computadora
creíble”, requiere de la verificabilidad del kernel del sistema operativo.
Maintainability
Mantenimiento de software: se referirse a las modificaciones que se hacen a
un sistema de software después de su versión inicial.
El mantenimiento ha sido usado “bug fixing” y fue afligente descubrir cuanto
esfuerzo se ha gastado en corregir los defectos.
Mantenimiento: No es apropiado usarlo con el sofware.
1ro. En esencia es, modificaciones por la “evolución del software”.
2do. El usar el término “mantenimiento” con software da una connotación
errónea debido a que el software no se desgasta.
El costo de mantenimiento excede el 60% del total del costo del software.
Para analizar los factores que afectan dichos costos, es necesario dividir el
mantenimiento del software en tres categorías: mantenimiento correctivo,
adaptativo y perfectivo.
Maintainability
Mantenimiento correctivo: tiene que hacer en todo aquello que se hace para
remover los errores residuales presentes en el producto cuando se liberó,
como también los errores introducidos dentro del software durante su
mantenimiento.
Mantenimientos adaptativo y perfectivo son las fuentes reales de cambio en el
software; ellos motivan la introducción de la evolucionabilidad como una
calidad fundamental del software y la anticipación del cambio como un
principio general que deberá guiar al ingeniero de software.
Los costos de mantenimiento adaptativo son cercanas a otro 20% de los
costos de mantenimiento mientras que más del 50% es absorbido por el
mantenimiento perfectivo.
El mantenimiento adaptativo involucra ajustes en la aplicación de cambios en
el medio ambiente.
Finalmente, el mantenimiento perfectivo involucra cambios en el software para
mejorar algunas de estas cualidades.
Reusabilidad
La reusabilidad está emparentado con la evolucionabilidad. En la evolución del
producto, modificamos un producto para construir una nueva versión del
mismo producto: en el reuso de un producto, nosotros lo usamos al
producto para producir otro producto.
La reusabilidad aparece como más aplicable a los componentes de software
que a un producto completo pero ciertamente parece posible construir
productos que son reusables.
Las bibliotecas científicas son los más conocidos componentes reusables.
La reusabilidad es difícil de lograr a posteriori, sin embargo, uno debería
esforzarse por la reusabilidad cuando los componentes del software son
desarrollados. (ADOO, POO).
La reusabilidad aplicada en el proceso de software es buena.
Los distintos modelos de ciclo de vida hacen también el intento del reuso de los
procesos de alto nivel
La reusabilidad es el factor clave que caracteriza la madurez del campo industrial.
El bajo grado de reusabilidad en el software es un claro indicador que el campo debe
evolucionar para conseguir el status de una bien establecida disciplina ingenieril.
Portabilidad.
El software es portable si puede correr en diferentes ambientes. (plataforma de
hardware o un ambiente de software así como un sistema operativo
particular).
Una forma de conseguir portabilidad dentro de una arquitectura de una
máquina es tener un sistema de software que asuma una configuración
mínima tan lejos como la capacidad de memoria que es involucrada y use
un subconjunto de las facilidades de la máquina que son garantizadas para
que estén disponibles sobre todos los modelos de la arquitectura.
Necesitamos usar técnicas que permitan que el software determine las
capacidades del hardware y que se adapte a ellas.
La portabilidad se refiere a la habilidad de correr un sistema sobre diferentes
plataformas de hardware.
En tanto crezca la relación de dinero gastado sobre las ganancias de software
versus hardware, la portabilidad gana más importancia.
Para muchas aplicaciones, es importante ser portable a través de los sistemas
operativos. O, mirándolo de otra forma, el sistema operativo provee la
portabilidad a través de las plataformas de hardware.
El ciclo de vida clásico de un Sistema de Software