INGENIERIA DE SOFTWARE

Principios de Ingeniería de Software

 

Apuntan al proceso de ingeniería y el producto final: el proceso correcto ayudará a obtener el producto correcto. Asimismo, el producto afectará la elección de qué proceso usar.

 

Los principios son afirmaciones abstractas que describen propiedades deseables del proceso y del producto. Para aplicarlas, los ingenieros deben contar con métodos y técnicas que incorporen dichos principios.

 

Ø  Métodos: guías para la ejecución de alguna actividad, aproximaciones rigurosas, sistemáticas y disciplinadas.

Ø  Técnicas: son más mecánicas que los métodos y tienen aplicabilidad más restringida.

 

Ambos se usan como sinónimos.

 

Los métodos y técnicas se encapsulan para crear metodologías, que sirven para promover una aproximación a la solución de problemas, preseleccionando los métodos y técnicas a usar.

 

Las herramientas son desarrolladas para apoyar la aplicación de los 3 niveles anteriores.

 

 

Lo que se busca con este análisis es la confiabilidad de las aplicaciones. También se supone que las aplicaciones serán lo suficientemente grandes para descomponerlas en partes manejables.

 

Todo esto hace que la confiabilidad y la evolución sean importantes y que afirmemos que la elección de principios y técnicas son determinantes para las metas de calidad del software.

 

1. Rigor y formalidad.

El rigor es un complemento de la creatividad en la ingeniería. Con la aproximación rigurosa podremos tener productos más confiables y mejores controles (de tiempo, costos, etc.). El rigor mejora la creatividad, optimizando la confianza en los resultados creativos, una vez analizados en base a una planificación rigurosa.

 

Hay varios grados de rigurosidad. El más alto es la formalidad, que es un requerimiento más restrictivo que el rigor, que exige que el proceso de soft sea dirigido y evaluado con leyes matemáticas. La formalidad implica rigor, pero uno puede ser riguroso e informal.

 

En ingeniería, el proceso de diseño son pasos bien definidos y con bases sólidas. En cada paso el ingeniero sigue algún método o técnica basados en resultados teóricos de un modelado formal de la realidad o en ajustes empíricos de fenómenos no considerados por el modelo, o en reglas heurísticas que dependen de la experiencia. Todo está resuelto en una aplicación rigurosa y sistemática (metodología), fácilmente explicada y aplicada una y otra vez.

 

El ingeniero debe saber cómo y cuándo ser formal, además de entender el nivel de rigurosidad y formalidad a alcanzar, dependiendo de la dificultad de la tarea y su criticidad. Ej.: podemos ser muy formales para las partes críticas de un problema y para las partes estandarizadas aplicar una aproximación más simple.

 

La formalidad aventaja al rigor en el sentido de que la primera puede ser la base para mecanizar procesos. La única fase del desarrollo de software donde se usa aproximación formal es en la programación. Los programas son objetos formales, escritos en lenguajes cuya sintaxis y semántica están definidos. Estas operaciones mecánicas, posibles por usar la formalidad, pueden mejorar la confiabilidad y verificabilidad de los productos software.

 

El rigor y la formalidad benefician también la mantenibilidad, reusabilidad, portabilidad, comprensión e interoperabilidad del software. Ej.: la documentación nos permite prever la evolución del proyecto, los recursos a usar, etc., así como nos ayuda a mantener el producto, al usarla para cualquier modificación que se requiera; y por último nos permite monitorear el software en forma precisa, para garantizar el cumplimiento de los puntos de control y mejorar la productividad.

 

2. Separación de intereses.

 

Es involucrarse con distintos aspectos de un problema para concentrarse en ellos separadamente. En cada proyecto debemos separar aspectos: primero, aislar los factores relacionados más débilmente y luego considerar los factores en la medida en que impactan el análisis.

 

Ø  Separación en base al tiempo: permite planificar las actividades de manera precisa.

Ø  Separación en términos de calidades: manejar separadamente la eficiencia y la corrección de un programa, diseñando software cuidadoso y estructuradamente, tal que su corrección esté garantizada a priori y luego reestructurada para mejorar su eficiencia.

Ø  Separación por vistas: separar los datos que fluyen de una actividad a otra en el flujo de control que gobierna la sincronización de las actividades.

 

La separación implica separación de responsabilidades para tratar los distintos aspectos. Es la base para la asignación del trabajo en asignaciones específicas para distintas personas con distintas habilidades.

 

3. Modularidad.

 

División de un sistema en partes más simples (módulos). Esto nos permite separar los contextos en fases: cuando relacionamos cada módulo aislado y cuando relacionamos todos los módulos globalmente, analizando sus conexiones e integración.

 

Objetivos de la modularidad:

 

Ø  Capacidad de descomposición de un sistema complejo: división del problema original en subproblemas y luego dividir cada subproblema.

Ø  Composición de un sistema a partir de componentes existentes: partir de componentes elementales hasta llegar al sistema terminado. Cuando un componente falla, se reemplaza por uno nuevo. Podemos usar módulos de una biblioteca, que al ser reutilizables, aceleran el proceso de construcción.

Ø  Comprensión del sistema mirándolo en partes: Nos facilita la reparación y modificación, al buscar los errores en un componente en particular.

 

Para lograr los tres objetivos, los módulos deben tener:

 

Ø  Alta cohesión: sus elementos internos están muy relacionados y agrupados por razones lógicas.

Ø  Bajo acoplamiento: es la relación entre módulos y mide la interdependencia entre 2 módulos. La idea es lograr que los módulos tengan un nivel bajo.

 

Las estructuras que cumplan esto nos permiten ver los módulos como cajas negras cuando describimos la estructura total y verlos separadamente cuando analizamos la funcionalidad de cada uno.

 

4. Abstracción.

 

Es identificar los aspectos importantes de un fenómeno e ignorar los detalles. Esto depende de cada persona o de cada enfoque o propósito que se le dé a un problema.

 

Los modelos que construimos son abstracciones de la realidad, válidas también para modelos de software.

 

Los lenguajes de programación son abstracciones que nos permiten construir sin preocuparnos por los detalles de hardware.

 

Este principio es importante para aplicarlo a productos y procesos software. Cuando la documentación de un programa o procedimiento se analiza, se supone que suministra toda la información necesaria para entender las otras partes del programa que usan ese procedimiento.

 

5. Anticipación al cambio.

 

Se refiere a la mantenibilidad. Es poder predecir los cambios y trabajar para que los cambios futuros sean fáciles de aplicar.

 

Esto es importante en el software, ya que los productos están en ambientes donde permanentemente surgen nuevos requerimientos.

 

La reusabilidad también se ve afectada por esto. Un componente es reusable si se puede emplear para generar un nuevo producto o si solo requiere pequeños cambios para ello. La reusabilidad es la capacidad de evolucionar que tienen los componentes.

 

Para anticiparse al cambio debemos contar con herramientas de administración de versiones y revisiones de software. Debemos poder almacenar y recuperar información, módulos fuente y objetos, todo desde una base de datos central.

 

Asimismo se afecta al proceso de soft, al considerar el mantenimiento de una aplicación y asignando estructura y costos para apoyar la evolución del software.

 

6. Generalidad.

Poder descubrir un problema más general en la resolución de un primer problema. Este puede ser menos complejo y proveer soluciones reutilizables. Puede surgir de un paquete ya existente o lo podemos crear nosotros.

 

Sin embargo, puede ser más costoso en términos de velocidad de ejecución, requerimientos de memoria o tiempos de desarrollo.

 

Este principio es fundamental si se busca desarrollar herramientas software para uso amplio en el mercado.

 

Si el problema puntual se puede reformular como una instancia de un problema general, es conveniente adoptar el paquete en vez de una solución específica.

 

7. Incrementalidad.

Desarrollar paso a paso con incrementos, logrando aproximaciones sucesivas. Esto nos da un proceso evolutivo.

 

Debemos identificar subconjuntos primarios útiles para desarrollar y distribuir a los clientes, de manera de obtener realimentación temprana. Esto nos permite que la aplicación evolucione de manera controlada, en casos donde los requerimientos iniciales no se comprendieron bien.

 

Las etapas intermedias son prototipos del producto final, lo cual beneficia el entendimiento de los requerimientos y permite usar un modelo de desarrollo iterativo más flexible.

 

Debemos tener mucho cuidado en la manipulación de documentos, programas, datos de prueba y todo lo que usemos en las distintas versiones. Cada paso incremental significativo debe ser registrado.

 

¿Qué es el software?

 

Programas, estructuras de datos, documentación y más.

 

Características:

 

Ø  desarrollo, no manufactura.

Ø  Desgaste, no gasto.

Ø  Principalmente desarrollado a medida.

Ø  Mantenibilidad: debe poder evolucionar y seguir cumpliendo sus especificaciones.

Ø  Confiabilidad: no debe causar daños físicos ni económicos en caso de fallos.

Ø  Eficiencia: no debe desperdiciar los recursos del sistema.

Ø  Utilización adecuada: debe contar con una interfaz adecuada y documentación.

Ø  Actúa como un diferenciador en los negocios, es estratégico.

Ø  Captura información, produce información y es información en sí mismo.

 

Productos Software

 

Ø  Genéricos: son producidos por una organización para venderlos en el mercado.

Ø  A medida: desarrollados bajo pedido a un desarrollador específico.

 

La mayor parte del gasto del software es en productos genéricos, pero hay más esfuerzo en el desarrollo a medida.

 

Componentes:

 

Mitos del software:

 

Ø  Estándares y procedimientos bastan.

Ø  Tecnología de punta basta.

Ø  Más gente para ponerse al día.

Ø  Programación inmediata.

Ø  Fácil acomodo de los cambios.

Ø  Programación: fin del trabajo.

Ø  Calidad: solo del ejecutable.

Ø  El código es el único producto.

Evolución del software:

 

Software vs. Hardware:

Ingeniería de software

 

Establecer y usar principios con caracteres de ingeniería para obtener, eficientemente, software confiable, que opere eficaz y eficientemente en máquinas reales.

 

Objetivos: maximizar la calidad, maximizar productividad, minimizar riesgos.

 

Implicancias:

 

Ø  Constructores básicos más poderosos.

Ø  Mejores técnicas de control de calidad.

Ø  Mejores herramientas y métodos.

Ø  Filosofía Global ¿enfoque de procesos?

 

Principios:

 

Ø  Hacer de la calidad el primer objetivo.

Ø  El software de alta calidad es posible.

Ø  Entregar tempranamente productos a los clientes.

Ø  Determinar el problema antes de describir los requerimientos.

Ø  Evaluar alternativas de diseño.

Ø  Usar un modelo apropiado.

Ø  Usar lenguajes diferentes para fases diferentes.

Ø  Minimizar la distancia intelectual.

Ø  Decidir las técnicas antes que las herramientas.

Ø  Hacerlo correcto antes que hacerlo rápido.

Ø  Inspeccionar diseño y código.

Ø  La gestión es más importante que la tecnología.

Ø  Gente: clave del éxito.

Ø  Adoptar técnicas y metodologías con cuidado.

Ø  Asumir responsabilidad.

Ø  Comprender prioridades de los clientes.

Ø  Clientes-Usuarios: más ven, más necesitan.

Ø  Planificar para desechar parcialmente.

Ø  Diseñar para el cambio.

Ø  Diseño sin documentación no es diseño.

Ø  Usar herramientas con realismo.

Ø  Evitar trucos.

Ø  Encapsular.

Ø  Usar acoplamiento y cohesión.

Ø  Usar mediciones de complejidad.

Ø  No probar el software propio.

Ø  Analizar causas de errores.

Ø  Asumir que la entropía del software aumenta.

Ø  Gente y tiempo no son intercambiables.

Ø  Esperar y demandar excelencia.

 

Costos del software

 

Los costos del software a menudo dominan el costo del sistema y superan muchas veces el valor de una PC.

 

Cuesta más mantener el software que desarrollarlo. Para sistemas con larga vida, este costo se multiplica.

 

La ingeniería de software concierne a un desarrollo efectivo en cuanto a costos.

El proceso de Software

 

Conjunto estructurado de actividades requeridas para desarrollar un sistema de software.

 

Ø  Especificación

Ø  Diseño

Ø  Validación

Ø  Evolución

 

Las actividades varían dependiendo de la organización y del tipo de sistema a desarrollarse. Para una buena administración, el sistema debe estar explícitamente modelado.

 

Características del proceso

 

Ø  Entendible: Proceso bien definido y es entendible.

Ø  Visible: Proceso es visible al exterior.

Ø  Soportable: Proceso soportado por herramientas CASE.

Ø  Aceptable: Proceso aceptado por aquellos involucrados en él.

Ø  Confiable: Errores del proceso descubiertos antes de que se conviertan en errores del producto.

Ø  Robusto: El proceso puede continuar a pesar de problemas inesperados.

Ø  Mantenible: El proceso puede evolucionar para cumplir con los objetivos organizacionales.

Ø  Rapidez: Que tan rápido puede producirse el sistema.

 

Modelo de Ingeniería del Proceso

 

Ø  Especificación: establecer los requerimientos y restricciones del sistema

Ø  Diseño: Producir un modelo en papel del sistema

Ø  Desarrollo: construir el sistema

Ø  Prueba: verificar que el sistema cumpla con las especificaciones requeridas

Ø  Instalación: entregar el sistema al usuario y asegurar su operatividad.

Ø  Mantenimiento: reparar fallos en el sistema cundo sea descubiertos.

 

Problemas en el Modelo del Proceso

 

Ø  Normalmente, las especificaciones son incompletas o anómalas

Ø  No existe una distinción precisa entre la especificación, el diseño y el desarrollo.

Ø  Solo hasta que el sistema se ha producido se puede probar

Ø  El software no se puede remplazar siempre durante el mantenimiento

 

Manejo de Riesgos en el proceso

 

Ø  La tarea principal del administrador consiste en minimizar riesgos.

Ø  El “riesgo” inherente en una actividad es se mide en base a la incertidumbre que presenta el resultado de esa actividad.

Ø  Las actividades con alto riesgo causan sobre-costes en cuanto a planeación y costos

Ø  El riesgo es proporcional al monto de la calidad de la información disponible.  Cuanto más información, mayor el riesgo.

 

Mejoramiento de la Calidad

 

Riesgos

 

Ø  No existen mejoras en el software baratas.

Ø  Las mejoras en la calidad pueden incrementar costes excesivamente

Ø  Los nuevos métodos pueden causar bajas en el personal.

 

Solución de riesgos

 

Ø  Estudio de la literatura existente.

Ø  Proyecto piloto.

Ø  Búsqueda de todos los componentes reutilizables potenciales.

Ø  Identificación del soporte disponible de herramientas

Ø  Entrenamiento al personal y seminarios motivacionales.

 

Resultados

 

Ø  La experiencia en métodos formales es limitada - es muy difícil cuantificar las mejoras.

Ø  Limitado el soporte en herramientas para sistemas de desarrollo de la compañía.

Ø  Existencia de componentes reutilizables, pero poco soporte de herramientas de reuso.

 

Planes

 

Ø  Explorar la opción de la reutilización a más detalle.

Ø  Desarrollar herramientas prototipo para reutilización.

Ø  Explorar el esquema de certificación de componentes.

 

Visibilidad de Procesos

 

Ø  Los sistemas de software son intangibles por lo que los administradores necesitan documentación para identificar el progreso en el desarrollo.

Ø  Esto puede causar problemas…

§  El tiempo planeado para entrega de resultados puede no coincidir con el tiempo necesario para completar una actividad.

§  La necesidad de producir documentos restringe la iteración entre procesos.

§  El tiempo para revisar y aprobar documentos es significativo.

Ø  El modelo de cascada es aún el modelo basado en resultados mas utilizado.

Responsabilidad profesional

 

Los Ingenieros de software no solo deben considerar aspectos técnicos. Deben tener una visión mas amplia, en lo ético, social y profesional.

 

No existen estatutos para ninguno de estos aspectos:

 

Ø  Desarrollo de sistemas militares.

Ø  Piratería.

Ø  Qué es mejor para la profesión de Ingeniero de Software.

 

Aspectos Éticos

 

Ø  Confidencialidad.

Ø  Competencia.

Ø  Derechos de propiedad intelectual.

Ø  Mal uso de la computadora.

 

Proceso de producción de software

 

Modelo lineal (Cascada)

 

El proceso se estructura como una cascada de fases, donde la salida de una es la entrada de la siguiente. Cada fase es un conjunto de actividades que pueden ser concurrentes.

 

Ø  Estudio de factibilidad: Depende del tipo de aplicación y del desarrollador. Se produce un documento de factibilidad que evalúa costos y beneficios del proyecto.

 

Primero se analiza el problema a nivel global y tanto como sea necesario para una factibilidad bien fundada. Lo que buscamos es anticipar escenarios futuros del desarrollo de software.

 

El documento contiene la definición del problema, soluciones alternativas y beneficios esperados, recursos necesarios, costos y fechas de entrega para cada alternativa propuesta.

 

Ø  Análisis y especificación de requerimientos: identificar las cualidades requeridas de la aplicación: performance, facilidad de uso, portabilidad, etc. Se debe especificar qué cualidades debe tener y no cómo se alcanzan.

 

El documento a realizar es una especificación de requerimientos. Su propósito es doble: debe ser analizado y confirmado por el cliente para ver si responde a sus expectativas y es usado por el ingeniero para desarrollar la solución que satisfaga los requerimientos.

 

Este documento debe ser comprensible, preciso, completo, consistente, no ambiguo y fácil de modificar.

 

Otro documento es el plan de test del sistema, donde se espera que el sistema sea cotejado contra los requerimientos.

 

Contenidos:

 

§  Requerimientos funcionales: lo que hace el producto, usando notaciones formales, informales, semiformales o mixtas.

§  Requerimientos no funcionales: confiabilidad (disponibilidad, integridad, seguridad), precisión en los resultados, performance, aspectos de la interfaz hombre-máquina, restricciones operacionales y físicas, portabilidad, etc.

§  Requerimientos sobre el proceso de desarrollo y mantenimiento: procedimientos de control de calidad (de test del sistema), prioridades de las funciones requeridas, procedimientos de mantenimiento, cambios al sistema y otros requerimientos.

 

Ø  Diseño y especificación: diseñar es descomponer en módulos. El resultado es un documento de especificación de diseño con la descripción de cada módulo, lo que hace y la relación con los demás. Cada componente se puede descomponer en subcomponentes. Este proceso varía dependiendo del sistema, la organización o el detalle deseado.

 

Ø  Codificación y test de módulo: se codifican e implementan los módulos. La codificación puede responder a estándares de la organización (encabezados, nombres de variables y subprogramas, etc.).

El test también se define así (planificación y selección de criterios de test según cada caso). Podemos también realizar la depuración.

 

Ø  Integración y test del sistema: se ensambla la aplicación a partir de los módulos. Puede realizarse en conjunto con la fase anterior. Este test puede hacerse incrementalmente, en base a subsistemas. En la última parte se testea el sistema completo y si pasa, se pone en funcionamiento, para probarlo en condiciones reales (Testing Alfa).

 

Ø  Entrega y mantenimiento:

 

1.    Primera etapa: se distribuye la aplicación entre ciertos usuarios antes de la versión definitiva. Se experimenta con ellos para obtener realimentación en busca del release oficial (testing beta).

2.    Segunda etapa: mantenimiento luego de la entrega al cliente. El análisis de requerimientos es crucial, porque los requerimientos son difíciles de capturar y cambian con el tiempo. Muchos errores se corrigen recién después de entregar el sistema, lo cual los hace más costosos. Los cambios son intrínsecos al software, pero es difícil de incorporar a los productos.

 

Prototipado

Se usa cuando no están bien definidos los requisitos de entrada, proceso o salida, o cuando el desarrollador no está seguro de algún requisito o funcionamiento del sistema.

Se comienza recolectando requisitos y definiendo objetivos del software con el usuario. Esto nos permite diseñar rápidamente aspectos visibles para el usuario, que son los prototipos. Estos se evalúan para refinar requisitos de la aplicación.

El objetivo principal es mejorar la identificación de requisitos, que el desarrollador comprenda mejor la necesidad y satisfacer al cliente con los prototipos.

Cuando se logra esto, se debe crear el sistema desde cero, corrigiendo todos los errores. Esto lo debemos planificar bien para saber si es lo que conviene o es mejor entregar un sistema completo al usuario.

Como primer sistema es bueno, ya que el cliente y el desarrollador ven resultados rápidamente, pero a la vez el cliente puede ilusionarse, ya que no sabe que el sistema está incompleto y propenso a fallos. No se debe prometer lo que no se va a hacer, lo que nos puede llevar a usar herramientas inadecuadas, desviando los objetivos originales de la metodología.

Este método es clave cuando se definen al inicio las pautas para crear los prototipos como base para el reconocimiento de requisitos.

RAD: Desarrollo Rápido de Aplicaciones

Modelo en cascada que logra desarrollos rápidos usando construcción basada en componentes. Necesita requisitos bien entendidos y alcances limitados. Fases:

Ø  Modelado de gestión: modelado de flujo de información entre las funciones de gestión: qué información hay, quién la genera, a dónde va, quién la procesa, etc.

Ø  Modelado de datos: se refinan los datos anteriores como objetos de datos. Se definen sus características y relaciones.

Ø  Modelado de proceso: se transforman los objetos para lograr el flujo de información para implementar una función de gestión. Se definen las descripciones para añadir, modificar, suprimir o recuperar un objeto de datos.

Ø  Generación de aplicaciones: usa lenguajes de 4ª generación, con reutilización de componentes ya existentes o creándolos.

Ø  Pruebas y entrega: Probar los nuevos componentes y ejercitar las interfaces.

Se una aplicación puede modularizarse para que cada función se complete en menos de 3 meses, este modelo es el indicado.

Observaciones:

Ø  Requiere compromiso de parte del cliente y el desarrollador para cumplir los tiempos.

Ø  Requiere buena modularidad y no un gran enfoque en el rendimiento.

Ø  No es adecuado cuando se usan tecnologías nuevas o si se requiera un alto grado de interoperatividad entre el software y programas existentes.

 

Modelo Incremental

Combina el modelo en cascada con los prototipos, aplicados repetidamente. Cada secuencia lineal produce un incremento de software. El flujo del proceso de cualquier incremento incorpora el paradigma de prototipado.

Cada incremento es esencial y funcional, pero con menos requisitos que los posteriores. El cliente lo usa y en base a ello se planea el incremento siguiente, modificando funciones, requisitos y necesidades para mejorarlos. Todo el proceso se repute hasta elaborar el producto completo.

Este modelo es útil cuando el personal no está disponible para implementaciones completas en la fecha límite, ya que los primeros incrementos se pueden implementar con menos personas.

 

Modelo Espiral

Conjuga la iteración de los prototipos con los controles del modelo en cascada. Proporciona el potencial para el desarrollo rápido de versiones incrementales de software. En las primeras iteraciones la versión puede ser un modelo en papel o prototipo. Las últimas son más completas.

Ø  Comunicación con el cliente: tareas para establecer pautas.

Ø  Planificación: tareas para definir recursos, tiempo y otra información relativa al proyecto.

Ø  Análisis de riesgo: evaluación de riesgos técnicos y de gestión.

Ø  Ingeniería: construcción de una o más representaciones de la aplicación.

Ø  Construcción y acción: desarrollo, prueba, instalación y soporte al usuario.

Ø  Evaluación del cliente: reacción del cliente de las representaciones creadas e implementadas.

Cada una de estas regiones está formada por tareas, que dependen del tamaño y alcance del proyecto. En todos los casos se aplican actividades de protección (gestión de configuración de software y garantía de calidad, etc.).

El primer circuito puede producir una especificación de productos, los siguientes pueden desarrollar un prototipo y versiones más sofisticadas. Cada paso por la planificación ajusta el plan al proyecto. El costo y la planificación se ajustan con las evaluaciones del cliente.

Ventajas:

Ø  Es un enfoque realista del desarrollo del sistema.

Ø  El desarrollador y el cliente entienden y reaccionan mejor ante los riesgos en cada nivel.

Ø  Usa prototipos para reducir riesgos en cualquier etapa de la evolución del producto.

Ø  Al enfocar directamente los riesgos en cada etapa, estos se previenen y reducen.

Observaciones:

Ø  Hay que ser muy hábil para evaluar riesgos, lo que compromete el éxito.

Ø  No ha sido tan usado como el modelo en cascada, por lo cual su eficiencia no está bien determinada.

Desarrollo basado en componentes

Muy usado en la teoría de objetos: clases que encapsulan atributos y operaciones. Si se emplean adecuadamente, su reutilización es un claro ejemplo de este modelo. Este método incorpora características del modelo en espiral. Es evolutivo por naturaleza e iterativo, pero usa componentes preparados para el desarrollo (clases).

1. Se identifican las clases candidatas, examinando sus datos y operaciones.
2. Las clases ya existentes se almacenan en una biblioteca de clases.
3. Se comparan ambos, y si una clase candidata ya existe, se recupera. Si no, se crea.
4. Se aplica la primera iteración con ambos tipos de clases.
5. El flujo se repite hasta la iteración ensambladora de componentes.

Este modelo conduce a la reutilización de software, que beneficia a los ingenieros. UML es un lenguaje basado en este modelo, que define los componentes a usar para el sistema y las interfaces que los conectarán.

 

Modelo de métodos formales

Son actividades que llevan a la especificación matemática del software. Se puede especificar, desarrollar y verificar un sistema usando notación rigurosa y matemática.

Usando este método en el desarrollo corregimos muchos problemas de la ingeniería: ambigüedad, falta de completamiento, inconsistencia, etc. Usándolo en la fase de diseño sirve como base para verificar programas y corregir errores no descubiertos antes.

Observaciones:

 

Ø  Método costoso y largo.

Ø  Requiere estudio detallado, ya que pocos desarrolladores lo pueden aplicar.

Ø  Difícil comunicación con usuarios poco técnicos.

Es óptimo para software de gran seguridad y para ahorros de dinero en resolución de errores.

Definición de Requerimientos y Especificación

 

Son técnicas para definir y especificar requerimientos en sistemas de software.

 

Objetivos:

 

Ø  Ilustrar el método basado en formas para escribir la definición de requerimientos.

Ø  Describir formas de escribir especificaciones precisas.

Ø  Explicar la importancia de los requerimientos no funcionales.

Ø  Describir diferentes tipos de requerimientos no funcionales y la forma en que pueden ser especificados.

 

Definición y especificación

 

Definición de Requerimientos: Descripciones orientadas al cliente de las funciones del sistema y de las restricciones en su operación

 

Especificación de Requerimientos: descripciones detalladas de la funcionalidad del sistema y sus restricciones. Pretende comunicar lo que los desarrolladores del sistema requieren y sirve de base como contrato para el desarrollo del sistema.

 

Definición de Requerimientos

 

Se debe especificar el comportamiento externo del sistema de forma que los requerimientos no sean definidos usando un modelo computacional.

 

Se incluyen requerimientos funcionales y no funcionales

 

Ø  Los Requerimientos funcionales son estatutos de servicios que el sistema debe proveer.

Ø  Los Requerimientos no funcionales son restricciones son los servicios y las funciones ofrecidas por el sistema.

 

Escritura de definiciones de requerimientos

 

Se usa lenguaje natural, además de diagramas y tablas. Esta es la forma natural de escribir definiciones de requerimientos. Es universalmente entendible, pero tres tipos de problemas se pueden presentar:

 

Ø  Falta de claridad: Hace que el documento sea difícil de leer.

Ø  Confusión en los requerimientos: Los requerimientos funcionales y no funcionales tienden a estar mezclados.

Ø  Mezcla de requerimientos: Varios requerimientos pueden estar expresados en forma conjunta.

 

Racionalidad en los requerimientos

 

Es importante proveer racionalidad en los requerimientos, ya que esto ayuda al desarrollador a entender el dominio de la aplicación y el por qué los requerimientos se encuentran en su forma actual. Esto es importante para el momento en que los requerimientos tienen que ser cambiados. La disponibilidad de una racionalidad reduce el riesgo de tener efectos inesperados.

 

Especificación de requerimientos

 

La especificación añade detalles a la definición de los requerimientos, por lo que debe se consistente con estos.

 

Usualmente es presentada mediante modelos de sistema los cuales son desarrollados mediante el análisis de requerimientos. Estos modelos pueden definir parte del sistema a desarrollarse y a menudo son escritos en lenguaje natural, lo cual puede causar problemas.

 

Problemas con el lenguaje natural:

 

Ø  El lenguaje natural se basa en la especificación dada por los que lo escriben.

Ø  La especificación del lenguaje natural es demasiado flexible y sujeta a distintas interpretaciones.

Ø  Los requerimientos no son particionados por estructuras del lenguaje.

 

Alternativas al lenguaje natural:

 

Ø  Lenguaje natural estructurado.

Ø  Lenguajes de descripción del diseño.

Ø  Lenguajes de descripción de requerimientos.

Ø  Notaciones gráficas.

Ø  Especificaciones matemáticas.

 

Rastreo de requerimientos

 

El rastreo de requerimientos (traceability) significa que los requerimientos relacionados deben estar ligados de alguna manera y que quizás deben estar ligados a sus fuentes. El rastreo es una propiedad de la especificación de los requerimientos que refleja las facilidades en encontrar requerimientos relacionados. Algunas herramientas de CASE proveen soporte de rastreo. Por ejemplo, pueden ser capaces de encontrar todos los requerimientos que usen los mismos términos.

 

Técnicas de rastreo

 

Ø  Asignar un número único a todos los requerimientos

Ø  Hace un referencia cruzada (cross-reference) de los requerimientos relacionados utilizando este número único

Ø  Producir una matriz de referencias cruzadas para cada documento de requerimientos mostrando los requerimientos relacionados. Varias matrices pueden ser necesarias para diferentes tipos de relaciones

 

Especificaciones en Lenguaje estructurado

 

Ø  Una forma limitada de lenguaje natural puede utilizarse para expresar los requerimientos

Ø  Esto evita algunos problemas que resultan de la ambigüedad y la flexibilidad e impone un grado de uniformidad en la especificación

Ø  Soportada mediante en enfoque basado en formas.

Especificaciones basadas en formas

 

Ø  Definición de una función o entidad

Ø  Descripción de entradas y de donde provienen

Ø  Descripción de salidas y hacia donde van

Ø  Indicación de otras entidades requeridas

Ø  Condiciones pre y post (si es que son apropiadas)

Ø  Efectos co-laterales (si es que existen)

 

Ejemplo:

 

Especificación de requerimientos basado en PDL

 

Ø  Los requerimientos pueden estar definidos operacionalmente usando un lenguaje como los lenguajes de programación pero con más flexibilidad de expresión.

Ø  Es más apropiada en dos situaciones:

§  Donde una operación es especificada como una secuencia de acciones y el orden es importante.

§  Cuando las interfaces de hardware y software tienen que especificarse.

Ø  Las desventajas son:

§  El PDL puede no ser suficientemente expresivo para definir conceptos de dominios.

§  La especificación se tomara como diseño en vez de cómo especificación.

 

Especificación de Interfaces

 

Ø  Casi todos los sistemas de software operan en un ambiente en donde existen otros sistemas. Pueden ser interfaces a estos sistemas de muchas formas.

Ø  Tres tipos de sistemas pueden definirse en la especificación de requerimientos

§  Interfaces procedurales.

§  Interfaces de datos

§  Interfaces de representación

 

Requerimientos no-funcionales

 

Ø  Define propiedades del sistema y restricciones, por ejemplo, confiabilidad, tiempos de respuesta y requerimientos de almacenamiento. Las restricciones pueden ser capacidades de dispositivos de E/S, representaciones del sistema, etc.

Ø  Los requerimientos de procesos pueden ser especificados utilizando un sistema CASE, lenguaje de programación o método de desarrollo.

Ø  Los requerimientos no-funcionales pueden ser más críticos que los requerimientos funcionales. Si estos no se cumplen, el sistema no es útil.

 

Clasificaciones no-funcionales

 

Requerimientos del Producto

§  Requerimientos que especifican que los productos entregados deben tener un comportamiento específico, por ejemplo, Velocidad de ejecución, confiabilidad, etc.

§  Requerimientos organizacionales

§  Requerimientos que son consecuencia de políticas organizacionales y procedimientos, por ejemplo, Procesos estándares usados, requerimientos del implementación, etc.

§  Requerimientos externos

§  Requerimientos que se derivan de factores que son externos al sistema y a su proceso de desarrollo, por ejemplo, requerimientos de interoperabilidad, requerimientos legislativos, etc.

 

Tipos de requerimientos no-funcionales

 

Verificabilidad de los requerimientos

 

Ø  Los requerimientos deben estar escritos de forma que puedan ser objetivamente verificados

Ø  El problema con estos requerimientos es el uso de términos “vagos” tales como “los errores deben ser minimizados”.

Ø  Los promedios de errores deben de estar cuantificados

 

Medidas de los requerimientos

 

Separación de Requerimientos

 

Ø  Los requerimientos funcionales y no-funcionales deben en principio, ser distinguidos en la especificación de requerimientos

Ø  Este es un requisito difícil de llevar a cabo ya que los requerimientos pueden estar expresados como requerimientos del sistema en vez de cómo restricciones en funciones individuales

Ø  Es difícil a veces decidir si un requerimientos es funcional o no-funcional

 

Requerimientos a nivel del sistema

 

Ø  Algunos requerimientos ponen restricciones en todo el sistema como un todo, en vez de poner restricciones a funciones específicas del sistema

 

Ø  Ejemplo: El tiempo requerido para entrenar a un operador del sistema para que sea eficiente no debe exceder más de 2 días

Especificación de Requerimientos de Software (SRS)

 

Contiene una descripción del comportamiento externo del sistema. Puede ser escrito por el cliente o por el ingeniero. En el primer caso sirve para representar las necesidades del cliente, por ejemplo, para una licitación. En el segundo caso se escribe como primer paso para el proceso de construcción de software y debe ser un documento más específico que en el primer caso.

 

El propósito del SRS es proveer un medio de:

 

Ø  Comunicación entre clientes, usuarios, analistas y diseñadores: Si el SRS está bien escrito, el cliente no se desilusionará con el producto final. No se puede dar lugar a malinterpretaciones y si hay desacuerdo entre las partes debe detectarse en esta etapa, no después, ya que sería más costoso.

 

El SRS debe especificar cómo el sistema será visto por su entorno y por los usuarios. Puede incluir aspectos de diseño para lograr esto, pero no es parte de la etapa de diseño, en la cual se puede rehacer todo de nuevo.

 

Ø  Servir como base para actividades de prueba y verificación: se comparan las pruebas en escenarios reales con el SRS y se analiza la ambigüedad, inconsistencia o inestabilidad del SRS y del sistema. El SRS es la entrada primaria de la planeación y generación de las pruebas.

 

Ø  Ayudar a controlar la evolución del software: Debe permitir que los cambios futuros se hagan de manera simple, facilitando la búsqueda y modificación de requerimientos. El SRS es la única definición de lo que el software debe hacer. Un control formal del SRS permite que el software evolucione correctamente.

 

Atributos de un SRS bien escrito

 

1. Correcto: Un SRS es correcto si y solo si cada requerimiento representa algo requerido por el sistema. Este atributo depende de la aplicación a desarrollar.

 

2. No ambiguo: Un SRS no es ambiguo si y solo si cada requerimiento establecido tiene una única interpretación. Esto se puede verificar consultando los requerimientos con distintas personas y oyendo sus interpretaciones.

 

Los términos con múltiples significados deben aparecer en un glosario, así como también deberemos evitar, dentro de lo posible, el lenguaje natural, el cual lleva implícita la ambigüedad. Al

 

Al momento de diseñar y desarrollar, la ambigüedad puede llevar a resultados muy graves.

 

3. Completo: Un SRS es completo si posee cuatro cualidades:

 

Ø  Todo lo que el software se supone que debe hacer está en el SRS. Es lo más difícil de definir o detectar violaciones en él. Una violación es algo que no está en el SRS, por eso es difícil ubicar. Esto lo pueden resolver aquellos que tienen el problema y solicitaron el software. Los prototipos son útiles en este sentido.

Ø  Definiciones de las respuestas del software a todos los tipos realizables de datos de entrada en todas las situaciones posibles. Se deben especificar las entradas válidas e inválidas, indicando en todos los casos la salida correspondiente.

Ø  Todas las páginas están numeradas, las tablas y figuras también, con nombres y referencias, todos los términos y unidades de medida son provistos y todos los materiales y secciones mencionados están presentes.

Ø  Ninguna sección está marcada como “Pendiente de terminación”. Si se incluye, se debe indicar quién es el responsable y la fecha de terminación.

 

4. Verificable: Un SRS es verificable si y solo si cada uno de los requerimientos es verificable. Un requerimiento es verificable si y solo si existe algún proceso en el cual una persona o máquina puede chequear que el software actual satisface ese requerimiento.

 

La verificabilidad es una función de la forma en como el SRS es escrito, no solo del producto.

 

La ambigüedad puede llevarnos a la no verificabilidad. También si usamos unidades no mensurables o si tenemos algún requerimiento que sea equivalente a un problema de bloqueo.

 

5. Consistente: Un SRS es consistente si y solo si ningún subconjunto de los requerimientos individuales tiene conflictos.

 

Ø  Términos conflictivos: dos términos usados en diferentes contextos para significar lo mismo.

Ø  Características conflictivas: dos partes del SRS demandan que el producto exhiba comportamientos contradictorios.

Ø  Inconsistencia temporal: dos partes del SRS demandan que el producto presente características temporales contradictorias.

 

6. Entendible por no especialistas en computadoras: en un intento por hacer un SRS menos ambiguo, más verificable, completo y consistente, podemos usar un lenguaje muy formal, lo cual puede hacer difícil la lectura para los clientes y usuarios, que no necesariamente son especialistas en computadoras.

 

Esto lo podemos resolver usando una herramienta que traduzca el lenguaje formal a natural o creando relaciones no ambiguas y completas entre las representaciones formales e informales.

 

Ahora veremos las características del formato y estilo del SRS

 

7. Modificable: un SRS es modificable si su estructura y estilo permiten cambios de manera fácil, completa y consistente. Esto exige una tabla de contenido, un índice y referencias cruzadas en donde sea necesario. Esto permite que un requerimiento a cambiar sea fácil de localizar y revisar en la sección que corresponda.

 

Podemos usar la redundancia de requerimientos para mejorar la legibilidad del SRS. Sin embargo, esto impide una buena modificabilidad, ya que cambiar una sola ocurrencia puede conducir a un SRS inconsistente. Esto se soluciona con una tabla de referencias cruzadas para localizar las múltiples ocurrencias de los requerimientos o usando la revisión automática de alguna herramienta para crear requerimientos.

 

8. Rastreable: Un SRS es rastreable si el origen de cada uno de los requerimientos es claro y se facilita la referencia de los mismos en un futuro desarrollo o mejora de la documentación. Hay cuatro tipos de rastreabilidad:

 

Ø  Hacia atrás desde los requerimientos: podemos conocer porqué cada requerimiento existe. Cada requerimiento referencia a sus fuentes en documentos previos.

Ø  Hacia delante desde los requerimientos: podemos entender cuáles componentes de software satisfarán cada requerimiento. Cada requerimiento referencia a un componente de diseño.

Ø  Hacia atrás hasta los requerimientos: cada componente de software referencia a los requerimientos que satisface. Implica que cada uno de los requerimientos tiene un nombre único o nº de referencia.

Ø  Hacia delante hasta los requerimientos: todos los documentos que preceden al SRS pueden referenciar al SRS. Implica que cada requerimiento tiene un nombre único o nº de referencia.

 

Para implementar la relación entre los requerimientos y el diseño se usa una matriz de rastreabilidad de requerimientos (RTM). Esta matriz no se crea durante la etapa de análisis, por lo tanto lo único que se hace ahora es organizar los requerimientos de manera jerárquica o con un único identificador para facilitar la creación del RTM.

 

El RTM es una tabla bidimensional con una fila para cada requerimiento y una columna para cada componente de diseño, indicando una X en cada lugar donde se correspondan. Si una fila no tiene X, ese requerimiento no tiene componente que lo satisfaga. Si una columna no tiene X, es un componente extraño de diseño. El RTM reduce el esfuerzo de localizar fallas del producto y permite analizar los posibles efectos adversos de un cambio planeado de software, examinando las entradas en la columna correspondiente al componente cambiado.

 

9. Con anotaciones: esto nos provee una guía a la organización del desarrollo. Hay dos tipos de anotaciones:

 

Ø  Necesidad relativa: se puede indicar para cada requerimiento si es esencial (E), deseable (D) u optativo (O).  Esto le indica a los desarrolladores las prioridades de construcción de requerimientos.

Ø  Estabilidad relativa: indicación de cuán volátil es el requerimiento. Esto les da a los desarrolladores una guía en donde construir flexibilidad en su diseño.

Calidad en la producción de software

 

Aspectos de la calidad del software:

 

Ø  Errores en tiempo de explotación.

Ø  Soporte: respaldo organizacional, apoyo a la introducción y mantenimiento, capacitación, ayuda, mantenimiento permanente y rápida respuesta a emergencias.

 

Verificación

 

Son actividades que aseguran que el software describe correctamente las operaciones que realiza.

 

Son visiones críticas del proceso de desarrollo desde la perspectiva de la calidad organizacional, formando métodos y técnicas que se revisan periódicamente para corregir en base a las actividades realizadas. Ejemplo: retroalimentación posterior, controles intermedios en cada etapa o procesos de prueba en cada etapa de desarrollo que reducen la tasa interna de errores y los costos.

 

Validación

 

Son actividades que aseguran que el software se ajusta a los requerimientos.

 

Plantea formas distintas de ver la calidad en el desarrollo, relacionado con la visión del usuario. Posee aspectos más comunicacionales que técnicas y no le compete sólo a los desarrolladores, sino que es un diálogo entre ellos y los usuarios. Ejemplo: prototipos, uso en condiciones reales del software, uso de lenguajes comunes de especificación y diseño, etc.

 

Eliminación temprana de errores

 

La gestión de calidad es mejor cuando se incorpora en etapas más tempranas del ciclo de desarrollo. Un error detectado tempranamente es más fácil de corregir y su costo de corrección es menor.

 

Si uno o más errores no detectados tempranamente se arrastran a las posteriores etapas, esto potenciará los errores y hará surgir otros nuevos, así como errores potenciales.

 

Para llevar a cabo la revisión de errores, se debe invertir tiempo, esfuerzo y dinero. Sin embargo, hacerlo tempranamente ahorra recursos y problemas a futuro.

 

Revisiones técnicas formales (RTF)

 

Así como especificamos cómo el software es desarrollado, podemos especificar mecanismos de cómo va a ser probado. Esto, sumado a las pruebas tempranas nos da el mecanismo de las RTF. Son actividades que garantizan la calidad del software y son llevadas a cabo por ingenieros de software.

 

Objetivos:

 

Ø  Descubrir errores en la función, la lógica o la implementación del software.

Ø  Verificar que el software revisado cumple sus requisitos.

Ø  Garantizar que el software es representado con estándares predefinidos.

Ø  Conseguir software desarrollado uniformemente.

Ø  Hacer los proyectos más manejables.

Es una actividad colectiva que amplía la mirada sobre lo que se revisa, lo que profundiza los distintos niveles y especialidades de profesionales, que se aplican a los diferentes elementos del software. Esto facilita el entendimiento a alguien nuevo y promueve la seguridad y la continuidad, ya que muchas personas ven partes pequeñas, algo que de otro modo no hubiera podido hacerse.

 

Las RTF agrupan mecanismos de revisión y establecen un marco común para las distintas etapas de revisión en el ciclo de vida. También deben ser usadas en las pruebas y el mantenimiento. El mecanismo más común es la reunión de revisión, que debe regirse con una buena planificación, control y dedicación de los involucrados.

Testing

 

Es una de las últimas fases del ciclo de vida antes de entregar el programa. Se estima que la mitad del esfuerzo de desarrollo está en esta fase.

 

Probar: es encontrar la mayor cantidad de errores. Es ejercitar el programa con el fin de encontrarle fallos.

 

Lo ideal sería exponerlo en todas las situaciones posibles, para encontrar todos los fallos y garantizar su respuesta en cualquier caso real, pero esto es imposible humana, económica y matemáticamente.

 

Aunque el nº de factores en programación es finito, el nº de pruebas no lo es, debido a los bucles y combinaciones que puede haber en un programa.

 

Probar: también es someterlo a todas las variaciones posibles de los datos de entrada, tanto válidos como inválidos.

 

Fases de prueba

 

Ø  Prueba de unidades: se plantea a pequeña escala y se prueba uno a uno los diferentes módulos.

 

Fase informal: el codificador ejecuta el código para probar que funciona. Si falla, se depura para localizar el fallo y repararlo.

 

Fase formal: más sistemática. Se usan dos criterios:

 

1.    Caja blanca: se mira el código escrito y se busca que falle. Se prueba todo, formalizando diferentes coberturas con un % del código cubierto.

 

Cobertura de segmentos: analiza sólo las secuencias de sentencias sin puntos de decisión. El nº de sentencias es finito y debemos planear las pruebas para revisarlas lo más que se pueda. Este proceso generalmente termina antes del 100%, porque puede ser muy laborioso y costoso. Para cortar el proceso se considera además de un índice de %, el código muerto o inalcanzable que se encontró.

 

Cobertura de ramas: considera segmentos con opciones. Aquí bastaría sólo con ejecutar con éxito una vez la condición para cubrir todas las sentencias, pero también hay que considerar la opción de fallo. Para estos casos se refina la prueba para recorrer todas las salidas de los puntos de decisión. Esto permite extenderse a estructuras con una o más opciones. Si esta prueba se hace al 100%, también cubre la anterior.

 

Cobertura de condición-decisión: abarca ramas con expresiones booleanas que usamos para decidir qué rama tomar y que son más complejas. Ejemplo: if xx or yy then zz end. En este ejemplo las condiciones pueden tomar 2 valores cada una con 4 combinaciones. Solo hay dos posibles ramas y bastarían 2 pruebas para cubrirlas, pero no tomaríamos la totalidad. Para esto se crea un criterio de cobertura de condición-decisión que divide las expresiones booleanas en sus componentes e intenta cubrir los valores de cada una. No basta con cubrir cada una de las condiciones, sino que hay que cuidar sus posibles combinaciones para poder probarlas todas.

 

Cobertura de bucles: son segmentos controlados por condiciones y son fuente inagotable de errores triviales o mortales. Cada bucle debe ejecutarse un nº de veces fijo, lo que provocaría fallos si no fuese así. En un WHILE hay 3 pruebas: 0 ejecución, 1 ejecución y más de 1 ejecución. En un REPEAT hay 2 pruebas: 1 ejecución y más de 1 ejecución. Los FOR son seguros, por definir en el encabezado la duración, pero si en su interior se modifica la condición, el FOR tiene trampa, asimismo si tiene sentencias de tipo EXIT, BREAK, RETURN, etc.

 

Prácticamente se busca llegar al 100% de segmentos y una buena cobertura de ramas. No hace falta ahondar en coberturas de decisiones. Para buenas coberturas, hay que valorar el riesgo que implica un fallo descubierto durante la aplicación del programa. Para esto, coberturas del 60% u 80% son admisibles.

 

Para casos donde hay fallos y se debe redistribuir el programa en muchos lugares, se debe aprovechar la fase de pruebas para encontrar todos los errores sin pasar nada por alto.

 

El 100% se debe alcanzar en programas que involucren vidas humanas o que sean militares.

 

Las pruebas de caja blanca se realizan con un depurador o un listado del módulo y un resaltador para marcar por dónde pasamos. Hay compiladores que incrustan en el código otro código para poder dejar un archivo con el nº de veces que se ejecutó cada sentencia.

 

Las limitaciones de este método son que un programa puede ser bueno en lo que hace, pero no hacer lo que tiene que hacer. Para verificar esto se usan las pruebas de caja negra.

 

2.    Caja negra: no de los detalles del código solo lo exterior. Busca errores en los casos en que el módulo no haga lo que se espera de él.

 

Se centran en lo que se espera del módulo, intentando encontrar casos donde el mismo no se atiene a su especificación. El probador suministra datos de entrada y estudia la salida, sin fijarse en el código. Estas pruebas están muy recomendadas para módulos que son interfaz con el usuario.

 

Se apoyan en la especificación de requisitos y se debe lograr una cobertura de especificación con un % de requisitos probados.

 

El problema de estas pruebas no está en las funciones de los módulos, sino en los datos que se le pasan a las funciones, que pueden ser muy amplios. Hay 2 técnicas:

 

Clases de equivalencia: trata cada parámetro como un modelo algebraico donde unos datos son equivalentes a otros. Si podemos partir un rango grande en clases reducidas, probando un caso de cada clase debería ser suficiente. Los casos generales son:

 

§  Parámetros de entrada dentro de un rango: hay 3 clases: por debajo, en el rango y por encima.

§  La entrada es un valor concreto: hay 3 clases: por debajo, en el valor y por encima.

§  La entrada es un valor de un conjunto: hay 2 clases: en el conjunto o fuera de él.

§  Entrada booleana: hay dos clases: si o no.

§  Esto es igual para las salidas, se deben generar resultados en todas las clases.

 

Fronteras (valores límite): puntos de cambio de clases de equivalencia. Conviene probar estos valores, al menos uno justo por encima y uno justo por debajo de la clase.

 

Ø Prueba de integración: se centra en probar la semántica entre los módulos, tanto estática (importación de módulos, llamadas, etc.) como dinámica (recepción correcta de uno a otro módulo, etc.). Estas pruebas pueden empezar con pocos módulos, pero no terminan hasta no tener el sistema completo. Se puede realizar de manera descendente (top-down) o ascendente.

 

Pruebas estructurales: similares a las de caja blanca, pero con un nivel conceptual mayor. En vez de mirar sentencias, se miran las llamadas entre módulos. Se identifican los esquemas de llamadas y se los ejercita para lograr una buena cobertura de segmentos o ramas.

 

Pruebas funcionales: similares a las de caja negra. Se buscan fallos en las respuestas del módulo cuando su operación depende de servicios brindados por otros. Mientras más nos acercamos al sistema total, más se basan en la especificación de requisitos. Usa las técnicas de clases de equivalencia y fronteras.

 

Las pruebas de integración pretenden cubrir todos los requisitos y permiten crear el manual de usuario.

 

Ø  Prueba de aceptación: la plantea el usuario final, que es quien decide qué es lo que va a probar del producto antes de darlo por bueno. Buscan la cobertura total de los requisitos y el manual de usuario. Siempre surgen errores, más allá de lo exhaustivo de las pruebas anteriores, ya que el cliente sabe cómo hacerlos aparecer. Por ello surgen dos pruebas:

 

Alfa: se invita al cliente a que pruebe el sistema en el entorno de desarrollo, que está controlado. Tiene siempre un experto a mano para ayudarle.

 

Beta: son posteriores a las alfa y se realizan en el entorno del cliente, sin control ni ayuda, para que se encuentren otros fallos.

 

Estas pruebas se usan en software que va a ser vendido al mercado y que potenciales compradores prueban, tanto para capacitar a su personal como para obtener beneficios económicos.

 

Otros tipos de pruebas

 

Ø  Recorridos (walkthroughs): se sienta en una mesa a los desarrolladores y a un conjunto de críticos con un moderador. Los críticos leen el programa línea por línea y piden explicaciones de lo que no está claro. Sirve para errores locales, pero no para errores alejados entre si en el programa.

Ø  Aleatorias (Random testing): se dice que la probabilidad de descubrir errores es la misma con pruebas aleatorias que con técnicas de cobertura, y eso es cierto. Aquí se prueba aleatoriamente el programa para mostrar los errores más patentes, aunque puede dejar ocultos errores más específicos.

Ø  Solidez (robustness testing): se prueba la capacidad del sistema para evadir situaciones difíciles por errores en el suministro de datos. Se prueban: todas órdenes correctas, órdenes con errores de sintaxis, órdenes desordenadas, órdenes nulas, órdenes con datos de más, interrupciones luego de una orden, órdenes con delimitadores inapropiados o incongruentes, etc.

Ø  Aguante (stress testing): probar hasta donde aguanta el sistema, ya sea internamente (datos a procesar) o externamente (con disco o cpu al 90%).

Ø  Prestaciones (performane testing): tiempo de respuesta o consumo de recursos: cuantos datos procesará, consumo de memoria y disco, datos transferidos por un canal de comunicaciones y su evolución cuando se redimensiona el problema.

Ø  Conformidad u homologación: requisitos que responden a normas más amplias (ISO, IEEE), que los desarrolladores deben cumplir. Las pruebas de caja negra se consideran de homologación. Se realizan en centros acreditados.

Ø  Interoperabilidad: busca errores en la comunicación entre 2 PC con el programa usando normas estándares.

Ø  Regresión (regression testing): cuando hay nuevas versiones del sistema, se exige una nueva pasada de las pruebas. Si estas fueron automatizadas, se pueden volver a pasar para probar que las modificaciones no provocan nuevos errores. La documentación clara permite mejorar pruebas futuras. Estas pruebas son buenas cuando se prueba la interacción con agentes externos.

Ø  Mutación (mutation testing): se altera ligeramente el programa (errores) para ver si la batería de pruebas los detecta. Si no es así, hay que introducir nuevas pruebas. Suele ser muy laborioso.

 

Depuración (Debugging)

 

Posibilidad de ejecutar un programa paso a paso para saber dónde está el programa en cada momento y cuánto valen las variables. Permite inspeccionar el comportamiento dinámico de los sistemas. Suele ser tediosa y solo es eficaz con objetivos claros.

 

Correr un depurador puede ser lento y no siempre es fructífero a largo plazo. Por ello, debemos delimitar el error antes de depurar. Si una prueba falla, se debe identificar el dominio del fallo y averiguar qué fue lo que lo provocó.

 

Plan de pruebas

 

1. Definir el propósito de la prueba y cómo se va a medir.
2. Pasos detallados de la ejecución.
3. Resultado esperado.

 

Todos los pasos deben documentarse.

 

Orden recomendado de las pruebas:

 

1. Pruebas de caja negra con valores límite de E/S.
2. Identificar clases de equivalencia de datos de E/S y hacer más pruebas de caja negra para los valores normales.
3. Hacer pruebas de “presunción de error” en base a la experiencia y el sentido común.
4. Medir la cobertura de caja blanca alcanzada y hacer más pruebas para lograr la cobertura deseada. Se busca una buena cobertura de ramas.
   

Aspectos psicológicos y organización del trabajo

 

Ø  Probar es ejecutar un programa para encontrar fallos.

Ø  Un caso de prueba tiene éxito cuando encuentra un fallo.

Ø  Las pruebas debe diseñarlas y pasarlas una persona ajena al desarrollo.

Ø  Las pruebas deben pasarse según se escribe el código para descubrir errores tempranamente antes de que se propaguen.

Ø  Si en un módulo hay muchos fallos, debemos identificar si se debe al programador, la dificultad del código, malas especificaciones, etc. Si se parchea el código se arruina.

Ø  Si hay fallos aislados, basta con una corrección aislada. Pero si hay muchos fallos, convendría rehacer el módulo de nuevo.

Ø  Las pruebas pueden encontrar fallos, pero jamás demostrar que no hay.

Ø  Las pruebas también tienen fallos. Si una prueba falla, se debe revisar lo que se prueba y lo que lo prueba.

Procesos y métricas

 

Para comparar objetivos y estadísticas de valores históricos es necesario hacer mediciones.

 

Ø  Medida: indicación cuantitativa de extensión, cantidad, dimensiones, capacidad o tamaño de algún atributo de un proceso.

Ø  Medición: acto de determinar una medida.

Ø  Métrica: medida cuantitativa del grado en que un sistema, proceso o componente posee un atributo dado. Indica las medidas individuales sobre algún aspecto. El ingeniero recopila métricas para obtener indicadores.

Ø  Indicador: métrica o combinación de métricas que dan una visión profunda del proyecto, proceso o producto software. Permite ajustar lo que se midió para mejorarlo.

 

Variable: rasgo, atributo o propiedad de la realidad a medir. Puede tomar más de un valor y posee una única unidad de medida: números enteros, tiempo, distancia, monto de dinero, etc.

 

Ø  Relaciones: vinculan en forma de cociente 2 valores con diferente unidad de medida (diferentes variables).

Ø  Índices: vinculan un atributo en 2 dominios diferentes. Ejemplo: 50/100. El nº de arriba es la cifra que se compara con la de abajo. Es decir, que los índices miden proporciones. También miden enlaces de diferentes unidades en una misma relación o relaciones entre diferentes períodos de tiempo. Si el numerador es menor, el índice es un porcentaje. Si es al revés, el índice es el “numero de veces”.

Ø  Ambos suelen usarse indistintamente. A veces los índices son usados como variables.

 

Ejemplos de índices:

 

Ø  Procesos: índice de productividad (recursos alcanzados y consumidos), KPI: índice de rendimiento clave (rendimiento por hora de equipo o herramientas, porcentaje de costo sobre costo total, % tiempo ocioso, % tiempo productivo sobre tiempo total, cantidad de líneas de código sin errores por persona y período, etc.).

Ø  Gestión de proyectos: involucran materiales, personas, tiempo, dinero, etc. Medidas económicas (VAN, TIR, RI, PRI), nivel de riesgo, costo de cada actividad respecto al total, grado de avance y de retraso, calidad del resultado, tasa de errores, reclamos por período, revisiones por período y actividad, controles por tarea, etc.

 

Los indicadores permiten ver en profundidad la eficacia de un proceso. Las métricas recopilan proyectos durante mucho tiempo y dan indicadores para mejorar los procesos a largo plazo. Permiten evaluar el estado del proyecto, los riesgos potenciales, las áreas con problemas críticos potenciales, así como ajustar el flujo y las tareas y evaluar la habilidad del equipo para controlar la calidad de los productos.

 

Para mejorar cualquier proceso hay que medir sus atributos, crear métricas significativas y usarlas para proporcionar indicadores que lleven a mejoras.

 

Modo de uso: primero hay que determinar qué índices usar, es decir, qué es significativo. Para ello consideramos el tipo de negocio, la antigüedad, el punto del ciclo en que se encuentra y qué es lo que se busca.

 

Luego se definen las relaciones entre los índices seleccionados y la frecuencia de las mediciones.

 

Los indicadores medidos deben ser: fáciles de medir, oportunos, comprensibles creíbles y relevantes.

 

Proceso previo a la decisión:

 

1. Establecer metas y objetivos.
2. Seleccionar índices e indicadores.
3. Recolectar datos.
4. Comparar resultados.
5. Corregir si es necesario.

Medición en el software

 

Ø  Para indicar la calidad del producto.

Ø  Para evaluar la productividad de la gente.

Ø  Para evaluar beneficios (productividad y calidad) de usar nuevos métodos y herramientas.

Ø  Para establecer una línea base de estimación.

Ø  Para justificar el uso de nuevas herramientas o formación adicional.

 

Medidas directas del proceso: costo y esfuerzo.

Medidas directas del producto: líneas de código, velocidad de ejecución, defectos por período.

Medidas indirectas: calidad, funcionalidad, eficiencia, facilidad de mantenimiento, etc.

 

Clasificación de métricas

 

Ø  Orientadas a la función o al tamaño

 

Ø  Según la información entregada:

 

§  De productividad: rendimiento del proceso de ingeniería.

§  De calidad: ajuste del soft a los requisitos del cliente.

§  Técnicas: se centran en el software (modularidad, complejidad, etc.).

 

Métrica de software: función cuyas entradas son datos del software o el proceso y las salidas son valores numéricos únicos interpretados como el grado en que el software o el proceso poseen un atributo dado.

Estimación de proyectos software

 

Planificación: estimación del esfuerzo requerido para el proyecto, la duración del mismo y los costos. Esta estimación precisa muchas variables: humanas, técnicas, de entorno, políticas, etc., que afectan el costo final y el esfuerzo.

 

Opciones:

 

Ø  Estimar más adelante.

Ø  Basarse en proyectos similares terminados.

Ø  Descomponer para estimaciones más sencillas.

Ø  Desarrollar un modelo empírico para el cálculo.

 

La idea es usar todas las opciones, siendo cada una comprobación de las otras. Antes de estimar, el planificador debe comprender el ámbito del software y estimar su tamaño.

 

Técnicas y modelos de estimación

 

En software hay pocos elementos que nos ayuden a estimar con precisión, debido a la forma en que evoluciona la tecnología. Esto genera que no haya un acumulado histórico válido de información y que los proyectos actuales tarden y cuesten más de lo planeado.

 

La productividad también es algo difícil de medir y puede ser definida como: productividad = (resultados del proceso / insumos del proceso).

 

Ø  Insumos: mano de obra, suministros, equipos, etc. Se deben aclarar las fases, actividades y recursos que realmente importen.

Ø  Resultados: su expresión más popular es la de líneas de código (LOC). Es difícil estimar su nº, pero a falta de alternativas normalizadas, es la medida más difundida. También se asume que la productividad en LOC por hora hombre es constante en función del tamaño del proyecto.

 

Hay 2 tipos de modelos de estimación: los subjetivos, basados en la experiencia y los objetivos, basados en estadísticas. Estos modelos nos permiten estimar valores como:

 

Ø  Cantidad de personas para un proyecto de x instrucciones en un plazo predefinido.

Ø  Costo global del proyecto en base a sus características.

Ø  Duración del proyecto en base al tipo de personal y las características del ambiente de desarrollo.

Ø  Esfuerzo a invertir en base a las características del software.

Ø  Calidad en base a las características del software.

 

Estimación empírica: el administrador recurre a alguien que haya hecho algo similar para estimar (juicio experto). Se descompone el problema en partes más pequeñas para estimar cada una por separado. Se hacen estimaciones optimistas (EO), más probables (EMP) y pesimistas (EP) con una probabilidad para cada una.

 

E = EO * PO + EMP + PMP + EP + PP

 

Esta estimación se limita a pocos proyectos, por lo que no es adecuada para cualquier software y sus resultados deben ser usados con prudencia.

Estimación racional basada en estadísticas:

 

Ø  Cada proyecto tiene su aceleración inicial al aplicarse progresivamente y no bruscamente, los recursos.

Ø  Cada proyecto tiene también desaceleración progresiva.

Ø  Hay relación entre el plazo de desarrollo, el esfuerzo realizado y el tamaño del software.

Ø  Mientras más voluminoso es el proyecto más válidas son estas premisas.

 

Modelo de putnam (Macroscópico): supone una distribución del esfuerzo sobre la vida del proyecto en base a la ecuación de Rayleigh y con datos de proyectos software muy grandes (30 años hombre o más).

 

L = C * K^1/3 * T ^4/3

T: tiempo en años.

L: líneas de código producidas.

K: esfuerzo (años hombre).

C: constante que depende de la tecnología a aplicar:

Ø  6500: ambiente de desarrollo pobre (sin documentación, revisiones y ejecución por lotes).

Ø  10000: ambiente bueno (documentación, revisiones, modo interactivo).

Ø  12500: ambiente excelente (herramientas automatizadas).

Ø  Estos valores pueden calcularse usando datos históricos.

 

Esfuerzo:

K = L³ / (C^{3 *} T⁴)

 

Si se incluye el costo de la mano de obra, la ecuación del esfuerzo puede estimar el costo de la misma en un proyecto de software.

 

Modelo de puntos de función: es una medida indirecta del software y del proceso de desarrollo, que se centra en la funcionalidad o utilidad del software. Se cuantifica el tamaño y la complejidad del sistema en términos de las funciones de usuario que desarrolla. Por ello, la medida es independiente del lenguaje o herramienta de desarrollo. Sirve para aplicaciones de negocios, no para aplicaciones técnicas.

 

Ventajas:

 

Ø  Independencia del lenguaje y herramienta de implementación.

Ø  Pueden estimarse con la especificación de requisitos, posibilitando la estimación temprana. Cualquier cambio en la especificación, se replica sin problemas.

Ø  Como se basan en la visión del usuario, estos tienen el mejor entendimiento de lo que se está midiendo.

Ø  Resuelve inconsistencias que aparecen con el uso de LOC como métrica.

 

Puntos de característica: ampliación de los puntos de función, que incluye aplicaciones de complejidad algorítmica alta. Considera los mismos elementos que PF, añade la variable nº de algoritmos y elimina los niveles de complejidad.

 

CoCoMo (constructive cost model): Usa una jerarquía de modelos.

 

Ø  Modelo I: calcula esfuerzo y costo del desarrollo en función de las LOC estimadas.

Ø  Modelo II: I + un conjunto de conductores de costos sobre la evaluación subjetiva del producto, el hardware, el personal y atributos del proyecto.

Ø  Modelo III: II + evaluación de los conductores de costos en cada etapa del proyecto.

 

Herramientas automáticas de estimación: permiten estimar costos y esfuerzos, así como tiempos de entrega y selección de personal, entre otros. Requieren de una o más clases de datos, de los cuales se estima todo lo mencionado.

 

Para obtener una estimación temprana de tiempo, esfuerzo y personas, así como predecir recursos hardware, software y riesgos, lo recomendable es usar 2 o más de las técnicas listadas, para comparar, conciliar y obtener más exactitud.

Puntos de función

 

Evalúa:

Ø  Valor comercial del sistema para el usuario.

Ø  Tamaño del proyecto, costo y tiempos.

Ø  Calidad y productividad del programador.

Ø  Esfuerzo de adaptación, modificación y mantenimiento.

Ø  Posibilidad de desarrollo propio.

Ø  Beneficios de implementación en 4GL.

 

Punto de función: función comercial de usuario final.

 

Las funciones se dividen en: entradas, salidas, consultas, ficheros e interfaces y luego se clasifican por su complejidad: alta, media, baja.

 

Se ajusta este total acorde a las características del entorno.

 

Ø  Salidas: datos únicos o salidas de control generadas proceduralmente que salen del límite de la aplicación. Son informes o mensajes a otras aplicaciones y usuarios.

 

Es salida única si: tiene formato diferente a otra salida o si tiene el mismo formato, pero con diferente lógica de procesamiento.

 

Ejemplos: ficheros de transacción enviados a otra aplicación, facturas, cheques, fichas perforadas, transacciones automáticas, mensajes, cintas, gráficos, ficheros backup, etc.

 

No son salidas: cabeceras de columna, títulos, nº de página, mensajes individuales (información, confirmación o respuestas a errores), salida en igual formato y lógica que se cuente para otro soporte.

 

Ø  Entradas: dato único de usuario o entrada de control que entra en los límites de la aplicación y actualiza un fichero lógico interno, datos, tabla o dato independiente. Son ficheros de entrada o transacciones de otra aplicación.

 

Es entrada única si: tiene formato diferente a otra entrada o tiene el mismo formato, pero diferente lógica de procesamiento o modifica un fichero lógico distinto.

 

Ejemplos: Mouse, documento micr, transacciones de cintas, pantallas sensitivas, lectores de códigos de barra, etc.

 

Ø  Consultas: combinación de E/S, donde la entrada genera una salida, todo on-line. Pueden provenir de otra aplicación.

 

Es consulta única si: tiene formato diferente en la entrada o la salida, o tiene el mismo formato, pero diferente procesamiento en la entrada o la salida.

 

Una consulta directa en la BD o fichero maestro es aquella que usa claves simples para recuperar datos y no un rango de claves. Además requiere respuesta inmediata y no actualiza datos, aunque puede realizar cálculos.

 

Ejemplos: consulta de usuario/display sin actualización, ficheros de transacción que salen de la aplicación si está accesible al usuario on-line, pantalla de selección de menú, mensaje de información o ayuda, etc.

 

Ø  Ficheros: Grupo lógico mayor de datos de usuario o información de control que está en los límites de la aplicación. Hay dos tipos de ficheros: ficheros de transacciones temporales y ficheros con registros lógicos permanentes.

 

Cuando están dentro de la aplicación, se denominan ficheros internos lógicos. Si se comparten entre aplicaciones son además interfaces (las 2 cosas a la vez).

 

Las transacciones son sucesos que cambian los ficheros lógicos internos, no son ficheros. Transacción entrada: se lee para actualizar un fichero lógico interno. Transacción interfaz: transfiere transacciones de actualización a otra aplicación.

 

Ejemplos: base de datos (1 por vista lógica o camino de acceso), ficheros maestros (1 por cada grupo de claves), tablas mantenidas por los usuarios, fichero de procesamiento batch, índice de referencias cruzadas.

 

Ø  Interfaces: ficheros lógicos de información de control, enviados fuera de las aplicaciones, compartidos o recibidos desde otra aplicación. Los ficheros compartidos entre aplicaciones son ficheros e interfaces en cada aplicación que los usen o los mantengan, mientras que en la otra sólo serán interfaces. Es decir, un fichero interface debe ser interno lógico en esa aplicación, en otra o en ambas, o puede ser un fichero transacción generado en la propia aplicación.

 

Casos:

 

§  Datos o información de control desde A hasta B. En A es fichero e interface. En B sólo interface.

§  Datos o información de control desde B hasta A. Ídem anterior, pero al revés.

§  Datos o información de control compartidos entre A y B. En ambos es fichero e interface.

 

Involucran ficheros maestros, no transacciones:

 

§  Si las aplicaciones se relacionan por medio de transacciones, se puntúan Entrada, Salida, Consulta y quizás Interface.

§  Si se relacionan por medio de Ficheros Maestros, se puntúan Interface y quizás Fichero.

 

Un fichero transacción no es interface si el formato con el que lo recibe el otro programa es el mismo. El receptor lo toma como entrada. Es contado como salida e interface si el programa que lo envía realiza la conversión.

 

Ejemplos: ficheros lógicos internos accesibles y accedidos desde otra aplicación, BD compartida, lista de parámetros compartida, fichero de impresión exportado, fichero transacción compartido que requiere conversión, fichero de registros de otra aplicación, ficheros de registros a otra aplicación (fichero en la aplicación y en la otra interface), ficheros de registros a varias aplicaciones (afecta la complejidad), fichero compartido entre 2 o más aplicaciones, BD compartida con otras aplicaciones, BD compartida de otras aplicaciones, fichero transacción de otras aplicaciones con conversión de datos, fichero transacción enviado a otra aplicación con conversión de datos (se cuentan en 1 sola aplicación).

 

Características generales de la aplicación PF

 

Se califican de 0 a 5 según su influencia en el sistema.

 

1. Comunicación de datos: datos o información de control que la aplicación envía o recibe a través de la facilidad de comunicación. Varía entre batch, datos remotos o interactivo.
2. Función distribuida: los componentes o datos se distribuyen en varios procesadores. Varía entre ofrecer y no ofrecer esta posibilidad.
3. Rendimiento: respuesta dentro del sistema. Varía entre considerar al usuario en sus requerimientos o no.
4. Configuración masiva: restricciones de memoria o hardware. Varía entre no tener restricciones y sí tenerlas en componentes distribuidos.
5. Tasas de transacción: llegada de transacciones. Varía entre considerar transacciones estándares o altos niveles de transacción.
6. Entrada on-line de datos: cantidad de transacciones (en %) que tienen entrada interactiva.
7. Diseño para la eficiencia del usuario final: varía entre no considerar sus requerimientos y considerarlos (prototipos).
8. Actualización on-line: varía entre no actualizar los ficheros, considerar su actualización y hacerlo y cuidar que no se pierdan (backup y recuperación).
9. Complejidad del procesamiento: complejidad interna, más allá de la E/S. Varía entre tener y no tener: procesamiento lógico/matemático, procesamiento complejo de entradas y salidas, muchas excepciones de procesamiento, transacciones incompletas y reprocesamiento, procesamiento de seguridad y/o control sensitivo.
10. Reutilización: que se puedan usar los componentes en otras aplicaciones. Varía entre permitir su reutilización y usar módulos de otras aplicaciones y no hacerlo.
11. Facilidad de instalación: varía entre considerar los requerimientos del usuario de facilidades de instalación y conversión y no hacerlo.
12. Facilidad de operación: varía entre operación manual, ayuda en backups y arranque y operación desatendida.
13. Puestos múltiples: varía entre no considerar muchos puestos y hacerlo brindando documentación y apoyo.
14. Facilidad de cambio: facilidad de realizar cambios futuros. Varía entre no considerarlos y hacerlo facilitándoselo al usuario con consultas y actualizaciones de tablas on-line.

PF = PF no ajustados * (0,65 + 0,01 * (Σ influencia de factores))

 

CoCoMo

 

Ecuación de estimación de esfuerzo de desarrollo:

 

S: nº de miles de LOC.

m(X): multiplicador que depende de 15 atributos.

 

Tabla de coeficientes:

 

Modelo básico: estima rápidamente proyectos pequeños y medianos. Este modelo no considera muchas características del entorno.

 

Ø  Modo orgánico: entorno familiar. Entre miles y decenas de miles de LOC. El costo y el tiempo es proporcional al tamaño.

Km: personas/mes

Sk: LOC

 

Tiempo:

 

td: tiempo de desarrollo en meses.

 

Ø  Modo empotrado: mayores restricciones, principalmente de hardware. Problemas más específicos con más de una centena de mil en LOC. Requiere gente más idónea.

 

Costo:

 

Tiempo:

 

Ø  Modo semiempotrado: intermedio entre los dos anteriores. Se pueden incluir personas experimentadas o no.

 

Costo:

Tiempo:

 

Modelo intermedio: introduce 15 atributos del entorno de trabajo para ajustar costos y precisión en la estimación. Para cada modo, los 15 atributos multiplican el costo nominal:

 

Los exponentes son los mismos del modelo básico, lo que indica que el tamaño afecta igual.

 

Los coeficientes han cambiado para mantener el equilibrio alrededor del semiempotrado respecto al efecto multiplicador de los atributos.

 

Atributos de costo

 

Atributos de producto:

Ø  Garantía de funcionamiento requerida al software: consecuencias para el usuario de un mal funcionamiento.

Ø  Tamaño de la BD: tamaño respecto al tamaño del programa.

Ø  Complejidad: complejidad de cada módulo y del sistema. Varía de baja a alta.

 

Atributos de la computadora:

Ø  Tiempo de ejecución: restricciones al programar un sistema con mayor tiempo de ejecución. Se expresa en el % de tiempo de ejecución disponible.

Ø  Restricciones de almacenamiento: esfuerzo de programación para reducir el uso de almacenamiento principal.

Ø  Volatilidad de la máquina virtual: cambios en la máquina donde se desarrolla el programa.

Ø  Tiempo de respuesta: esfuerzo para reducir este valor.

 

Atributos del personal:

Ø  Capacidad del analista: habilidad de análisis, eficiencia y capacidad para cooperar.

Ø  Experiencia en la aplicación: experiencia en algo similar. Varía entre baja (menos de 4 meses) a alta (más de 12 años).

Ø  Capacidad del programador: capacidad del grupo de programadores.

Ø  Experiencia en máquina virtual: experiencia del grupo con el procesador. Desde baja a muy alta.

Ø  Experiencia en lenguaje de programación: a mayor experiencia, menos errores y requerimientos humanos. Varía desde muy baja a muy alta.

 

Atributos del proyecto:

Ø  Prácticas de programación modernas: Ejemplo: uso de programación estructurada y desarrollo top-down. Varía desde no usarlas a tenerlas como hábito.

Ø  Uso de herramientas software: sirven para multiplicar la productividad. Varía desde usar herramientas básicas a específicas.

Ø  Plan de desarrollo requerido: el tiempo nominal de desarrollo es el que requiere menos esfuerzo. Varía entre mucho apresuramiento y retraso.

Complejidad ciclomática

 

La complejidad ciclomática es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa. Cuando se usa en el contexto del método de prueba del camino básico, el valor calculado como complejidad ciclomática define el número de caminos independientes del conjunto básico de un programa y nos da un límite superior para el número de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez.

 

Un camino independiente es cualquier camino del programa que introduce, por lo menos, un nuevo conjunto de sentencias de proceso o una nueva condición.

 

En términos del grafo de flujo, un camino independiente está constituido por lo menos por una arista que no haya sido recorrida anteriormente a la definición del camino.

 

Por ejemplo, para el grafo de flujo de la figura inferior, un conjunto de caminos independientes sería:

 

a) Diagrama de flujo

camino 1: 1-11

camino 2: 1-2-3-4-5-10-1-11

camino 3: 1-2-3-6-8-9-10-1-11

camino 4: 1-2-3-6-7-9-10-1-11

 

Fíjese que cada nuevo camino introduce una nueva arista. El camino no se considera un camino independiente, ya que es simplemente una combinación de caminos ya especificados y no recorre ninguna nueva arista.

 

1-2-3-4-5-10-1-2-3-6-8-9-10-1-11

 

¿Cómo sabemos cuántos caminos hemos de buscar?

 

El cálculo de la complejidad ciclomática nos da la respuesta. La complejidad ciclomática está basada en la teoría de grafos y nos da una métrica del software extremadamente Útil. La complejidad se puede calcular de tres formas:

 

1. El número de regiones del grafo de flujo coincide

2. La complejidad ciclomática, V(G), de un grafo de flujo G se define como.

 

Donde A es el número de aristas del grafo de flujo y N es el número de nodos del mismo.

 

3. La complejidad ciclomática, V(G), de un grafo de flujo G también se define como V(G)=P+ 1 donde P es el número de nodos predicado contenidos en el grafo de flujo G.
   

Calendarización de las actividades de un proyecto. Método Esterling

 

Planificación temporal:

Identificación de tareas, asignación de tiempos y recursos a dichas tareas y planificación de la secuencia de ejecución de forma que el tiempo de desarrollo del proyecto sea mínimo.

 

Ø  El objetivo del gestor del proyecto es definir todas las tareas del proyecto, identificar las que son críticas y hacerles un seguimiento para detectar de inmediato posibles retrasos.

Ø  La planificación temporal distribuye el esfuerzo estimado a lo largo de la duración prevista del proyecto.

Ø  La planificación evoluciona con el tiempo.

 

Planificación: estimación inicial, monitorización y control

 

Principios de la planificación temporal:

 

Ø  Compartimentación: descomposición del proyecto en nº manejable de tareas.

Ø  Interdependencia: Se deben determinar las dependencias de cada tarea.

Ø  Asignación de tiempo: A cada tarea se le debe asignar un cierto número de unidades de trabajo, una fecha de inicio y otra de finalización.

Ø  Validación del esfuerzo: A medida que se realiza la asignación de tiempo, el gestor del proyecto se tiene que asegurar de que los técnicos necesarios estarán disponibles en cada momento.

Ø  Responsabilidades definidas: Cada tarea que se programe debe asignarse a un miembro específico del proyecto.

Ø  Resultados definidos: El resultado de cada tarea, normalmente un producto, deberá estar definido. Los productos se combinan generalmente en entregas.

Ø  Hitos definidos: Todas las tareas grupos de tareas deben asociarse con algún hito del proyecto. Se considera un hito cuando se ha revisado la calidad de uno o más productos y se han aceptado.

 

Métodos de planificación temporal

 

Ø  Red de tareas: representación mediante una estructura en red de las tareas e hitos del proyecto.

Ø  Diagrama de barras: Representación gráfica de las tareas sobre una escala de tiempos.

Ø  PERT (Program Evaluation & Review Technique): Creado para proyectos del programa de defensa del gobierno norteamericano entre 1958 y 1959. Se utiliza para controlar la ejecución de proyectos con gran número de actividades que implican investigación, desarrollo y pruebas.

Ø  CPM (Critical Path Method): Desarrollado para dos empresas americanas entre 1956 y 1958. Se utiliza en proyectos en los que hay poca incertidumbre en las estimaciones.

Ø  Método de ROY: Desarrollado en Europa entre 1958 y 1961 (B.Roy/ M. Simmonard). Similar a los métodos PERT y CPM, pero permite establecer las redes sin utilizar actividades ficticias e iniciar los cálculos sin la construcción de la red.

 

Modelo de Esterling

 

Este modelo toma en cuenta las condiciones cotidianas de desarrollo de un proyecto de software e intenta predecir los resultados globales a partir de la medición de esas condiciones. Supone que todo proyecto es efectuado por un equipo de trabajo y que el medio ambiente y las N personas actuando tienen una productividad que no es arbitraria sino que depende de la cantidad y tipo de las interacciones.

 

Las reuniones de trabajo, las interrupciones, el tiempo dedicado a faenas administrativas, inciden en la productividad.

 

Los parámetros del modelo de Esterling son:

 

Ø  A = fracción promedio del día de trabajo gastado en efectuar trabajos administrativos, incidencia directa en el avance del proyecto.

Ø  T = duración promedio de las interrupciones (minutos)

Ø  R = tiempo promedio de recuperación después de la interrupción (minutos)

Ø  K = número de interrupciones por día de trabajo de la gente que trabaja directamente en el proyecto

Ø  P = número de interrupciones por día debido a otras causas

Ø  G = número promedio de horas extra por día trabajado

Ø  N = número de gente trabajando en el proyecto

Ø  W =fracción útil del tiempo trabajado por día trabajado por persona

Ø  S = salario base ($)

Ø  I = costo indirecto (overhead) por persona, expresado como una fracción del salario base

Ø  Las ecuaciones del modelo de Esterling son las siguientes:

Ø  W = 0,125 [8 - 8A + G – (4R + P (T+R) + K (N-1) (T+R)) / 60] en donde:

Ø  W = fracción útil del tiempo trabajado

Ø  TT = 7 / (5NW)

Ø  TT = tasa tiempo calendario a días persona para completar el proyecto. Se supone 7 días por semana calendario y 5 días de trabajo normal, con N personas trabajando a una fracción útil de W.

Ø  L = NS (GD + 8(1+1))

Ø  L = costo diario de mano de obra para un salario base dado

Ø  E = (NW)/L

Ø  E= eficiencia del costo

Ø  C= L/(NW)

Ø  C = costo del proyecto por día persona

 

El modelo de Esterling puede ser difícil de aplicar en la práctica, pero es importante porque otorga una visión equilibrada sobre aspectos habitualmente dejados de lado.

 

Diseño de Datos y Procedimientos. Diseño de programas.

 

El diseño de datos (a veces llamado arquitectura de datos) crea un modelo de datos y/o información que se representa con un alto nivel de abstracción (la visión de datos del cliente/usuario).

Este modelo de datos, es entonces refinado en progresivas representaciones específicas de la implementación, que pueden ser procesadas por un sistema basado en computadora. En muchas aplicaciones de software, la arquitectura de datos tendrá una gran influencia sobre la arquitectura del software que debe procesarlo.

 

A nivel de los componentes del programa, el diseño de las estructuras de datos y de los algoritmos asociados requeridos para su manipulación, son la parte esencial en la creación de aplicaciones de alta calidad.

A nivel de aplicación, la traducción de un modelo de datos (derivado como parte de la ingeniería de requisitos) en una base de datos es el punto clave para alcanzar los objetivos de negocio del sistema.

 

A nivel de negocios, el conjunto de información almacenada en las diferentes bases de datos y reorganizada en el almacén de datos facilita la minería de datos o el descubrimiento de conocimiento que puede influir en el propio éxito del negocio.

 

Modelado de datos, estructura de datos, bases de datos y almacén de datos

 

Los objetos de datos definidos durante el análisis de requisitos del software son modelados utilizando diagramas de entidad-relación y el diccionario de datos la comunidad de empresas de TI ha desarrollado las técnicas de minería de datos, también llamadas descubrimiento de conocimiento en bases de datos (DCBC), que navegan a través de las bases de datos en un intento por extraer el nivel de información de negocio apropiado. Sin embargo, la existencia de múltiples bases de datos, sus diferentes estructuras, el grado de detalle contenido en las bases de datos, y muchos otros factores hacen difícil la minería de datos dentro de un entorno con bases de datos existentes. Una solución alternativa, llamada almacén de datos, añade una capa adicional a la arquitectura de datos.

 

Un almacén de datos es un entorno de datos separado, que no está directamente integrado con las aplicaciones del día a día, pero que abarca todos los datos utilizados por una empresa. En cierto sentido, un almacén de datos es una gran base de datos independiente, que contiene algunos, pero no todos los datos almacenados en las bases de datos que sirven al conjunto de aplicaciones requeridas en un negocio. Sin embargo, hay muchas características diferenciales entre un almacén de datos y una base de datos típica.

 

Características almacén de datos:

 

Ø  Orientación por materia.

Ø  Integración.

Ø  Restricciones de tiempo.

Ø  No volatilidad.

 

Diseño de datos a nivel de componentes

 

El diseño de datos a nivel de componentes se centra en la representación de estructuras de datos a las que se accede directamente a través de uno o más componentes del software. Wasserman ha propuesto un conjunto de principios:

Ø  Los principios del análisis sistemático aplicado a la función y al comportamiento deberían aplicarse también a los datos.

Ø  Todas las estructuras de datos y las operaciones a llevar a cabo en cada una de ellas deberían estar claramente identificadas.

Ø  Se debería establecer un diccionario de datos y usarlo para definir el diseño de los datos y del programa

Ø  Las decisiones de diseño de datos de bajo nivel deberían dejarse para el final del proceso de diseño.

Ø  La representación de las estructuras de datos deberían conocerla sólo aquellos módulos que deban hacer uso directo de los datos contenidos dentro de la estructura.

Ø  Debería desarrollarse una biblioteca de estructuras de datos útiles y de las operaciones que se les pueden aplicar.

Ø  Un diseño del software y un lenguaje de programación debería soportar la especificación y realización de los tipos abstractos de datos.

 

Lenguaje de diseño de programas

 

El lenguaje de diseño de programas (LDP), también denominado lenguaje estructurado o pseudocódigo, es «un lenguaje rudimentario en el sentido de que utiliza el vocabulario de un lenguaje (por ejemplo, el Inglés), y la sintaxis global de  otro (esto es un lenguaje estructurado de programación.

 

Radica en el empleo de texto descriptivo (por ejemplo, Inglés) insertado directamente dentro de las sentencias de LDP. Dado que se utiliza texto descriptivo insertado directamente en una estructura sintáctica, este lenguaje no se puede compilar (al menos por ahora). Sin embargo, las herramientas LDP que existen actualmente convierten LDP en un «esquema» de lenguaje de programación, y/o representación gráfica (por ejemplo, un diagrama de flujo de diseño). Estas herramientas también producen mapas anidados, un índice de operación de diseño, tablas de referencias cruzadas, y más diversidad de información.

 

Una sintaxis básica LDP deberá incluir construcciones para la definición de subprogramas, descripción de la interfaz, declaración de datos, técnicas para la estructuración de bloques, construcciones de condición, construcciones repetitivas y construcciones de E/S.

 

Diseño de Interfaces. Modelos. Estilos. Guías de acción

 

CHM: Comunicación Hombre Maquina

 

Usabilidad:

Ø  Fácil de aprender y fácil de utilizar

Ø  Facilidad de aprendizaje.

Ø  Flexibilidad

Ø  Solidez

 

Objetivos CHM:

Ø  Comprender los factores que determinan como la gente trabaja y hace uso de los ordenadores y trasladar esa compresión al sistema

Ø  Desarrollar herramientas y técnicas que ayuden a los diseñadores a que los sistemas sean idóneos para lo que la gente los va a usar

Ø  Conseguir interacción eficiente, efectiva y segura

 

Principios:

 

1. Colocar a los usuarios en el control de la interfaz

Ø  Emplear los modos adecuadamente

Ø  Permitir a los usuarios emplear el teclado y el ratón

Ø  Permitir a los usuarios cambiar la atención

Ø  Mostrar mensajes y textos descriptivos

Ø  Proporcionar a los usuarios acciones inmediatas, reversibles y realimentación

Ø  Proporcionar caminos significativos y salidas

Ø  Acomodar a los usuarios con diferentes niveles de habilidad

Ø  Hacer la interfaz de usuario transparente

Ø  Permitir al usuario personalizar la interfaz

Ø  Permitir a los usuarios manipular los objetos de la interfaz

 

2. Reducir la carga de memoria de los usuarios

Ø  Aliviar la memoria a corto plazo (deshacer, rehacer, cortar, copiar, pegar, transferir automáticamente datos)

Ø  Confiar en el reconocimiento no recordar. Es más fácil seleccionar un elemento de la lista que tener que recordarlo. Mensajes, tooltips y ayuda sensible al contexto

Ø  Proporcionar pistas visuales

Ø  Proporcionar opciones por defecto, rehacer y deshacer

Ø  Proporcionar atajos

Ø  Promover una sintaxis de objeto acción. Acciones válidas para cada objeto. Botón derecho del Mouse

Ø  Emplear metáforas del mundo real

Ø  Emplear revelación progresiva. Mostrar lo que necesitan cuando y donde lo necesitan

Ø  Promover la claridad visual

 

3. Hacer la interfaz de usuario consistente

Ø  Preservar el contexto del trabajo de los usuarios. Donde están y donde han estado

Ø  Mantener la consistencia dentro y entre productos

Ø  Conservar los resultados para las mismas interacciones.

Ø  Proporcionar estética atractiva e integridad

Ø  Animar la exploración

Modelos:

Ø  Modelo del diseñador (intermediario entre el modelo de usuario y del programador, arquitecto)

o    Modelo conceptual del usuario

o    Modelo del programador

o    Principio y guías de diseño de interfaces

 

Ø  Modelo del programador

o    Plataforma

o    Sistema operativo

o    Herramientas del desarrollador

 

Ø  Modelo del usuario

o    Experiencias del mundo real

o    Tareas

o    Procesos

o    Herramientas

 

Modelo mental del usuario (recolección de información)

Ø  Análisis de los trabajos del usuario

Ø  Encuestas y entrevistas de los usuarios potenciales

Ø  Visita a los usuarios en los lugares de trabajo

Ø  Reacciones de los usuarios

Ø  Test de usabilidad

 

Modelo mental del programador: es más fácil de ver y puede ser definido formalmente

 

Estilos de interacción

 

Ø  Interfaz de línea de comandos

Ø  Menús

Ø  Lenguaje Natural

Ø  Pregunta/Respuesta y diálogo de consulta

Ø  Formulario y hoja de cálculo

Ø  9 WIMP sistemas de ventanas

Ø  Point and click

Ø  Interfaces tridimensionales

 

Soporte al usuario

 

Ø  Guía de referencia rápida

Ø  Ayuda para una tarea específica

Ø  Manual

Ø  Tutorial

 

Requerimientos del sopote a usuario

 

Ø  Disponibilidad

Ø  Exactitud y Completitud

Ø  Consistencia

Ø  Robustez

Ø  Flexibilidad

Ø  No obstructiva

Estilos de soporte a usuarios

Ø  Asistencia de comandos

Ø  Mensajes de comandos (cuando hay error)

Ø  Ayuda sensible al contexto

Ø  Tutoriales en línea

Ø  Documentación en línea

Ø  Ayuda adaptativa

Desarrollo de un plan

Ø  La audiencia de la aplicación (tipo de información que se ha tener disponible en la aplicación y modo de presentación)

Ø  El contenido de las preguntas

Ø  La estructura de las preguntas

Ø  El uso de preguntas sensibles al contexto

Guías

Principios y reglas

Ø  Conocer la población de usuarios (diferentes tipos de usuarios)

Ø  Reducir la carga cognitiva (que el usuario no tenga que aprender grandes cantidades de detalles)

Ø  Aplicar la ingeniería para resolver la problemática del error humano

Ø  Mantener consistencia y claridad

Guías de estilo

Ø  Guías de estilo comercial (Windows, MAc, Unix, etc.).

Ø  Guías de estilo corporativo

Fases del diseño

 

Ø  Recogida de requerimientos

Ø  Diseño de la arquitectura

Ø  Diseño detallado

Ø  Codificación y test de los módulos

Integración y test generales

 

AQUI UN LIBRO ADICIONAL EN PDF SOBRE SOFTWARE LIBRE PARA UNA SOCIEDAD LIBRE ESPERO QUE LES SEA DE MUCHA UTILIDAD ( CLICK AQUI )