Ingeniería de Software (2º Parcial) Gustavo Perdomo INET 2015



Ingeniería de Software  (2º Parcial)
Gustavo Perdomo INET 2015

CALIDAD

1. Definición: Es el grado con el cual el cliente percibe que el software cumple con sus funcionalidades. Si no hay calidad: Los proyectos son abandonados por sus costos (no hay productividad), el programa no hace lo que se espera (no cumple correctitud) o porque es difícil de operar (no cumple con la cualidad de usabilidad).

2. Aspectos medibles en la calidad del software:

a. Calidad intena: Medible a través de las cualidades internas del software.

b. Calidad externa: Medible en el comportamiento del producto. Por ejemplo en una prueba.

c. Calidad en uso: Medible a través del uso efectivo del software por parte del usuario.

3. Visiones de la calidad del software:

Interviene en la calidad del producto de software: Cliente (o usuario), empresario (o empresa desarrolladora), equipo técnico de desarrolladores.

a) Usuario: Satisfacer necesidades y expectativas en los tiempos de respuesta. Esfuerzo mínimo (que sea fácil de aprender). Ejecución sin problemas (baja frecuencia de fallas).

b) Empresario : Lograr un producto que sea fácil de colocar en el mercado. Maximizar los beneficios con respecto a los recursos invertidos (económico, humano y logístico) para producir el software.

c) Equipos técnicos: Tipo de falla y frecuencia de las mismas que sean simples. Fácil de entender (a nivel del código fuente). Tipo de cambio y frecuencia de los mismo que tengan un bajo impacto.

La disparidad de visiones nos lleva a un problema que se resuelve aplicando metodologías basadas en estándares y adoptando modelos para evaluar y métricas para medir.

4. Medición de la calidad de software:

Para medir la calidad de un proceso de software se emplean modelos que especifican la calidad de un producto de software definiendo un conjunto de atributos o características. Se basan para ello en la descomposición de la calidad en características y estas en criterios, que se pueden medir mediante métricas, un ejemplo de esto es la estándar internacional para la evolución de la calidad del software ISO 9126.

5. Conclusión: La calidad es algo subjetivo, por que depende de la perspectiva del observador. Esta subjetividad requiere de la utilización de metodologías, métricas y optimizar para minimizar la subjetividad en la evaluación de calidad. La planificación de la calidad de producto, permite planificar estrategias de desarrollo.

METODOLOGÍAS

1. Definición: La RAE define metodología como: “el conjunto de métodos utilizados en una investigación científica”. Se define método como “la forma de obrar o proceder”.Las metodologías definen el cómo, el cuándo y el que hacer, además proporcionan los recursos necesarios para la consecución (conseguir, obtener, lograr) de objetivos. Las metodologías resuelven la mayor parte de las necesidades de los integrantes de un proyecto de software.

2. Metodología de desarrollo:

Define un marco de trabajo que permitirá estructurar, planificar y controlar el proceso de desarrollo de un sistema de información:

- (1) Estimación y planificación de un proyecto.

- (2) Análisis de requerimientos.

- (3) Diseño, (4) codificación, (5) pruebas, (6) instalación y (7) mantenimiento.

Las metodologías responden a las grandes preguntas qué son: ¿Qué hacer? ¿Quién debe hacerlo? ¿Cómo hacerlo? y ¿Cuándo hacerlo?. Proporcionan los mecanismos necesarios para la consecución de objetivos. Resuelven la mayoría de los problemas de los involucrados en el desarrollo del software.

3. Emplear metodologías de desarrollo permite:

Seleccionar el ciclo de vida que más se ajuste a las condiciones y características del desarrollo. Establecer las fases y el orden de las mismas dentro del ciclo de vida, así como los resultados finales e intermedios, permitiendo resultados parciales. Proporcionar un conjunto de herramientas, técnicas y procedimientos que facilitan la labor de los ingenieros de software aumentado de este modo la productividad.

Técnica:

Es un conjunto de recursos y procedimientos que tiene como objetivo un resultado bien definido.

Herramientas:

Las herramientas proporcionan el soporte automático para la aplicación de metodologías.

Procedimientos:

Son el punto de unión entre las herramientas y las metodologías. Define la secuencia en que se aplica las metodologías, como usar las herramientas, las entregas necesarias y el control y seguimiento de calidad. Son la guía que facilita la labor del gestor y los desarrolladores.



CICLO DE VIDA

1. Introducción: Cuando un cliente piensa en automatizar la gestión de su empresa surge entonces la necesidad de construir un software, a este punto se le considera el nacimiento del software. Es seguido luego por una serie de actividades para su construcción, liberación y mantenimiento. El software muere cuando es dejado de usar o es reemplazado por otro.

2. Definición: El ciclo de vida (o proceso) es el conjunto de fases o etapas por el que pasa el producto de software desde que nace hasta que muere. Las Fase o etapas son el conjunto de actividades que comparten un objetivo en común. Por ejemplo si nuestro objetivo es determinar la funcionalidad de nuestro sistema las actividades pueden ser por ejemplo entre otras establecer entrevistas, diagramas de casos de uso, etc.

3. El ciclo de vida determina:

  • Orden de las fases

  • Establecer los criterios de transición de una fase a la siguiente.

  • Definir la entrada y salida de cada fase.

  • Describir los estados por los que pasa el producto.

  • Definir un esquema que sirve como base para planificar, organizar y coordinar.



Entregable: Es un estado del producto de software, puede ser un código de programación o un documento, en el ejemplo anterior la fase de especificación culmina con la construcción de un documento de requerimientos y ese puede ser el entregable. Los entregables mejoran la relación con el cliente, dado que baja la ansiedad del mismo al ver que se está trabajando.

Artefacto: En Ingeniería de Software se denomina artefacto a una pieza de información producida o utilizada en el proceso, puede ser un documento y/o parte del código.

Hito: La RAE define hito como un hecho clave y fundamental dentro del ámbito o contexto, en Ingeniería de Software representa un acontecimiento muy importante y significativo en el desarrollo de un proceso. Marca un estado del desarrollo del software y en general se utiliza en la planificación del proyecto.


Rol: La RAE define rol como la función que alguien o algo cumplen. Un rol en Ingeniería de Software se desempeña por una o varias personas que tienen asignado un conjunto de tareas o actividades. Que al ser realizadas producirán un artefacto o parte de él. Ejemplo: Una de las tareas que tiene asignado el analista es la creación del modelo de casos de uso como artefacto.

Figura: elementos del proceso de desarrollo y sus relaciones

En un proceso se encuentran actividades, roles, artefactos, herramientas y personas. Estos elementos del proceso se relacionan entre sí respondiendo a las pregunta: ¿Quien debe hacer?, ¿Qué hacer? ¿Cuando hacer? ¿Cómo hacer? Para alcanzar una meta. Las personas que participan en la construcción de una producto de software desempeñando un rol. Los roles tienen asignado un conjunto de actividades que al ser realizadas producen uno u más artefactos. Las personas desempeñando un rol, son la respuesta a quién debe hacer. Los artefactos que producen los roles realizando actividades responden a que hacer. (*) Por último, a través de las actividades que están planificadas para realizarse en un determinado tiempo se responde a las preguntas de cuando y cómo.

MODELO CODE & FIX

1.Introducción: Cuando surgió la necesidad de construir un producto de software, el programador realizaba un relevamiento de las solicitudes. Las actividades que ser realizaban para la construcción del software consistían en nuclear los requisitos del software sin seguir ninguna metodología, se realizaba más o menos lo que el cliente quería o pretendía del programa.

Luego con los requerimientos bajo el brazo comenzaba a codificar. Esta tarea carecía de todo tipo de administración y supervisión; se iba corrigiendo a medida que surgían los errores tanto lógicos, como de código y de requerimiento.

2. Definición: Este modelo consistía en escribir código (code) y resolver los problemas de código (fix), se lo llamo CODE & FIX. Este modelo al no seguir normas, el cliente realizaba especificaciones muy generales del producto; esto llevaba a que se programara y se corrigiera sobre la marcha del proyecto. Las sucesivas correcciones hacen que el programa se torne incomprensible. Debemos tener en cuenta que este producto carecía de todo tipo de documentación, siendo por lo tanto muy difícil seguirlo y entenderlo.

El ciclo de vida de este tipo de proyecto finaliza cuando se satisfacen las especificaciones, no sólo las primeras, por las cuales nació la necesidad del programa, sino todas aquellas que fueron surgiendo sobre la marcha.

3. Ventajas:

  • Programación impulsiva, se comienza a codificar sin realizar ningún tipo de análisis y diseño. Por lo tanto, no gasta recursos en análisis, planificación, gestión de recursos y documentación.

  • Sólo es aplicable a desarrollos muy pequeños. No se puede aplicar a proyectos.

  • El proceso determina quién debe hacer, que hay que hacer, como y cuando hacerlo.

4. Desventajas:

Si es aplicado a problemas complejos, surgen los siguientes inconvenientes:

  • Al carecer de planificación que guíe al proyecto, el más mínimo cambio o error hace que los costos de los recursos sean mayores a los previstos.

  • Al no contar con un análisis de requerimientos y planificación se produce un aumento del tiempo de desarrollo.

  • La carencia de la gestión de seguimiento de la calidad hace que el resultado sea un producto de software de calidad dudosa.

ACTIVIDADES DEL PROCESO

Todos los ciclos de vida o procesos, no importando a que metodología pertenezcan, deben realizar cuatro actividades básicas que son: Especificación, desarrollo, validación y evolución.

1. Especificación del software:

Esta actividad permite establecer de forma clara lo que hará y no hará el software, es decir, se deben especificar las funcionalidades y sus restricciones operacionales. Debemos aclarar que los requerimientos hacen a la especificación del software. En esta actividad se aplica ingeniería de requerimientos, la razón es que se trata de una etapa critica porque un error en la definición de requerimientos impacta directamente en el diseño y luego sobre la implementación. En esta actividad se crea como artefacto el documento de requerimientos.

2. Desarrollo del software:

Aquí se encuentra todo lo que tiene que ver con la construcción del software que cumpla con los requerimientos definidos en la especificación del software (diseño y implementación).

3. Validación del software:

En este punto encontramos todo lo relacionado con asegurar que el software efectivamente cumpla con lo que el cliente quiere, dicho de otra forma, el software debe cumplir con la cualidad de correctitud.

4. Evolución del software:

El software debe evolucionar para cumplir con los cambios requeridos por el cliente.

MODELO EN CASCADA

1. Introducción: En el desarrollo de software se pueden utilizar metodologías tradicionales (conocidas también como pesadas) o metodologías ágiles. Dentro de cada metodología se encuentra un conjunto de modelos o ciclos de vida para el desarrollo del software.

En los años 80 y a principios de los 90 existía una opinión generalizada de que para crear un producto de calidad se tenia que hacer un fuerte hincapié en documentación, planificación y control del proceso de desarrollo. Esta opinión estaba fuertemente instaurada en la comunidad de Ingenieros de Software y se basaba en la construcción de software de gran porte, compuesto a su vez por varios programas. Estos sistemas se caracterizan por ser críticos, por ejemplo el sistema de control de tráfico aéreo.

Existía un gran equipo de desarrollo que por lo regular trabajaba en distintas compañías y se encuentra disperso en diferentes regiones. Otra característica es la larga duración del proyecto, en el orden de años.

Este enfoque está pensado para priorizar la documentación, exige un orden riguroso de las fases lo cual dificulta los cambios, por esta razón lo requerimientos deben ser estáticos. Las metodológicas pesadas no consideran la participación del cliente en el equipo de desarrollo, dan mayor valor al proceso que a las personas.

2. Modelo en cascada: Fue presentado en los '70, toma las actividades fundamentales y las plantea en 5 fases.

Figura: primer modelo en cascada

Este esquema representa un enfoque secuencial y sistemático donde no es tomado en cuenta volver a una fase anterior. Aquí vemos que no se admiten cambios en los requerimientos. En caso de presentarse un cambio, no queda otra alternativa que repetir el ciclo de vida. Al modelo clásico se le agrego la posibilidad de la vuelta atrás con el fin de contemplar la necesidad de repetir fases.

















Figura: segundo modelo en cascada

De todas maneras no se contempla la posibilidad de volver a la fase anterior, por ejemplo, si nos encontramos en la fase de implementación y tenemos que volver a la fase de diseño, nos vemos obligados a tener que seguir hasta el final. Este modelo no toma en cuenta cambios sobre la marcha, esto obliga al cliente que plantee todos los requerimientos al comienzo.

Los requerimientos detectados en forma tardía son de un costo muy elevado, al ser un modelo secuencial, es decir que primero debe terminar una fase para comenzar la fase posterior, hace que un retraso en una fase impacte sobre todas las demás. Este modelo no maneja la ansiedad del cliente, que no ve nada terminado hasta estar cerca del final.

2.1. Análisis y definición de requerimientos:

El objetivo es dejar definido de forma definitiva los requerimientos funcionales y no funcionales. En este punto se debe lograr una comprensión profunda del problema, por parte de los analistas involucrados. En este punto quedan definidas las cualidades de la aplicación requerida por parte del cliente. (por ejemplo que la aplicación necesitamos que sea eficiente, entonces esa cualidad va a ser un requerimiento, la solución debe ser extremadamente eficiente). Acá van a quedar bien definidas las cualidades requeridas por el cliente.

Una técnica muy utilizada para el relevamiento de los requerimientos son los casos de uso, dicha técnica mejora la comunicación con el usuario, por ser fáciles de interpretar, esta fase termina con la producción como artefacto del documento de requerimiento.

2.2. Diseño de sistema y de software:

Aquí se define la solución del problema, por eso es importante haber adquirido en la etapa anterior una comprensión clara y profunda del problema. En esta fase se construye como artefacto un documento de diseño donde se explica claramente el diseño, es decir la solución del problema, este documento debe contener la arquitectura del sistema, la descripción de los módulos y sus relaciones. Dependiendo del paradigma de programación utilizado se pueden hacer uso de herramientas de diseño como son por ejemplo UML, MER, etc. Es importante en esta fase aplicar el principio de modularidad.

2.3 Implementación y pruebas de unidad:

En esta fase se realiza la implementación y las pruebas de cada componente de software. Luego de implementar cada pieza se debe realizar de forma exhaustiva las pruebas de cada componente, si se trabajo con el paradigma orientado a objetos se debe probar cada clase y modulo por separado. Tener presente que cuanto más rigurosos seamos en la implementación y pruebas de unidad minimizaremos la posibilidad de errores en la integración y etapas posteriores. Los casos de prueba son técnicas interesantes a realizar en este punto. Debemos tener presente la gráfica del esfuerzo que toma el desarrollo de un producto de software y sobre todo el esfuerzo de las pruebas que es de un 16% con respecto del 8% que implica la implementación.

Para realizar las pruebas de unidad debemos tomar cada clase y probar cada uno de sus métodos, esto es conveniente realizarlo de 2 formas, que son: colocando a cada clase un método principal, donde se pueda instanciar la clase y ejecutar los métodos de la misma, la otra forma es crear una clase externa que instancie y ejecute los métodos de las clases a probar.

2.4 Integración y pruebas del sistema:

En esta fase se prueba la integración y ademas el sistema funcionando como un todo. Para realizar la pruebas de integración hay que tener claro las dependencias funcionales y arquitectónicas del sistema. Si estamos integrando un modulo de la capa de negocio con un modulo de la capa de cliente solo debemos probar aquellos métodos que refieran a dichos módulos y que no requieran de la instancia de clases que correspondan a otros módulos.

2.5 Operación y mantenimiento:

Es la fase más critica y la más larga, dado que se prolonga hasta que el software muere (se disparan riesgo que deben haber sido contemplados). El mantenimiento puede ser de 3 tipos:

  • Correctivo: Corrige errores que surgen de la utilización efectiva por parte del usuario.

  • Adaptativo: Realiza modificaciones para adaptarlo a cambios que surgen en el negocio.

  • Perfectivo: Mejorar funcionalidades o agregar nuevas.

3. Conclusiones:

  • Es un modelo secuencial y sistemático que exige terminar con una fase para terminar con la siguiente.

  • Se prioriza la documentación, no se contempla al cliente como parte del equipo de desarrollo. Los requerimientos deben ser estáticos luego que fueron definidos.

  • No se puede volver a una fase anterior, por lo tanto cualquier modificación o cambio es de alto costo.

4. Iteración de procesos:

Al vivir en un mundo cambiante es necesario contar con métodos que enfrenten mejor el cambio. La razón es que al cambiar las reglas del negocio, se provoca que cambien las funcionalidades del software, para enfrentar estos cambios es necesario contar con un modelo que permita repetir fases. De esta forma se puede reconstruir el software para dar respuesta a los cambios.

Los modelos que se han desarrollado para repetir fases durante la construcción del software, es decir contemplar iteraciones en el proceso son: modelo incremental y modelo espiral.

MODELO INCREMENTAL

Este modelo fue propuesto por Harlan Mills en 1980, fue profesor de ciencias de la computación del Instituto de Tecnología de Florida. Es un modelo iterativo que permite repetir fases de diseño, construcción y prueba para cada incremento. Además cada incremento es validado e integrado, por último se válida el sistema. Estas sucesivas validaciones minimizan el riesgo de posibles fallas. Este modelo se puede emplear cuando se tiene claro el problema y por ende los requerimientos, es decir no existe incertidumbre en cuanto a las funcionalidades del producto a construir.

Al tener claro el problema, podemos dividirlo en incrementos que contienen las funcionalidades del software. Cada incremento agrega una nueva funcionalidad al sistema dando al cliente una nueva visión del producto y su funcionalidad (en este modelo existen los entregables).

Después de asignar los requerimientos a los incrementos se diseña la arquitectura del sistema, compuesta por módulos que contendrán los incrementos y dentro de estos uno o más requerimientos, luego se desarrolla el incremento, realizando las fases de diseño detallado, construcción y pruebas.

Es importante destacar que en el desarrollo del incremento se puede hacer uso de otro modelo de proceso, como puede ser el modelo evolutivo en caso de existir incertidumbre en los requerimientos.

Al tener el incremento desarrollado, se válida, integra y por último se válida el sistema completo. Este modelo se considera un mega modelo, porque puede contener a otros en el desarrollo de cada incremento. Los incrementos no pueden superar las 20.000 lineas de código.



Podemos decir del modelo incremental que:

  • Evoluciono en el modelo ágil, programación extrema XP.

  • Presenta como inconveniente la extensión en lineas de código de los incrementos, haciendo difícil asignación de los requerimientos al incremento.

  • Lo utilizamos unicamente cuando se tiene claro el problema.

  • Baja el riesgo o lo enfrenta, dado que los requerimientos más críticos se desarrollan en los primeros incrementos, los cuales serán probados más veces.



MODELO EVOLUTIVO

1. Definición: Este modelo surge para mitigar la incertidumbre en los requerimientos, es decir surge para dar respuesta cuando no se tienen claros los requerimientos por parte incluso del cliente o el usuario. Se tiene una comunicación fluida con el cliente o el usuario, permitiendo la retroalimentación necesaria para el develado de los requerimientos. El ciclo de vida plantea dos tipos de desarrollo, exploratorio y por prototipos desechables.



Tipos de desarrollo:

  • Desarrollo exploratorio: este tipo de desarrollo permite explorar junto con el cliente los requerimientos comenzando con las partes del sistema que se tienen más claro, y va evolucionando agregando nuevas funcionalidades aportada por el cliente o el usuario.

  • Desarrollo por prototipo desechable: permite lograr una comprensión de los requerimientos por parte de los involucrados, es decir cliente o usuario y analistas. Este desarrollo tiene como objetivo lograr una definición clara de los requerimientos, se usa en los requerimientos que no se comprenden o no están suficientemente claros. El prototipo en este caso se desecha, solo es un medio para lograr definir los requerimientos. Se puede utilizar un esquema como prototipo desechable.



MODELO EN ESPIRAL



Este modelo surge históricamente en 1946 a través de Kurt Lewin, un psicólogo Alemán nacionalizado estadounidense. Es el autor del termino investigación acción, y desarrollo un modelo en espiral de ciclos para la investigación. En la década del 80 Barry Boehm profesor de la Universidad de California propuso en Ingeniería de Software el modelo de desarrollo en espiral.



Determinar objetivos, alternativas y restricciones:

Es un modelo que evoluciona en cada ciclo y gestiona el riesgo. En cada fase hay que definir los objetivos específicos, como se establecen las restricciones del proceso y del producto. Por último se traza un plan detallado de la gestión.

Evaluar alternativas, identificar y resolver riesgos:

Este sector está comprendido por 2 partes que son: el análisis de riesgo y la elaboración de prototipos. Con respecto a los riesgos, se hace un análisis que implica identificarlos y elaborar un plan de contingencia. La elaboración de prototipos, permita facilitar el relevamiento de los requerimientos o validar la solución.

Desarrollar y validar producto:

Aquí se puede elegir un modelo de desarrollo del sistema, por ejemplo si hay riesgo en la interpretación de los requerimientos se podría pensar en un modelo evolutivo, en este sector dependiendo de la fase se establecen y validan los requerimientos, se diseña la solución y se valida, se codifica y se realizan prueba de unidad, integración y aceptación.

Planificar siguiente fase:

Se revisa el proyecto y se toma la decisión de continuar con un ciclo posterior en la espiral. Este modelo comienza con un grado alto de incertidumbre que va gestionando. Las actividades no están establecidas a priori, sino que se eligen dependiendo del análisis de riesgo.

PREGUNTAS DE PARCIAL

  1. ¿Que entiende por calidad?.

  2. ¿Que entiende por metodología de desarrollo?.

  3. ¿Qué determina el ciclo de vida?.

  4. Realizar gráfica de esfuerzo / actividad.

  5. ¿Qué entiende por hito?

  6. Nombrar y definir los cinco elementos del proceso de desarrollo y sus relaciones.

  7. ¿En que situación es aplicable el modelo Code & Fix?.

  8. Nombrar y explicar las cuatro actividades fundamentales del proceso desarrollo.

  9. Modelo en cascada. Explique su variante, fases, desventajas, y en qué caso es seguro aplicarlo.

  10. ¿Qué entiende por iteración?

  11. Modelo incremental. Desarrollar cada fase. Explicar lo más significativo. Ventajas. desventajas y cuando aplicarlo.

  12. Explicar el modelo evolutivo. Los dos tipos de desarrollo. 







Comments