Introducción a la Ingeniería del Software

Definición de Software

Es todo aquel componente intangible existente en un equipo informático, incluyendo programas y datos, así como la documentación pertinente para comprenderlos.

Definición de Hardware

Son todos aquellos componentes tangibles o físicos en un equipo informático.

Definición de Desarrollo de Software

Es el acto de producir o crear software. Este término se usa en un sentido amplio que abarca no solo la programación de un código fuente, sino además otras actividades como:

• Programación
• Compilación
• Estudio de las necesidades del usuario
• Mantenimiento del software
• Coordinación del trabajo en equipo de desarrollo
• Redacción de manuales
• Testeo y pruebas

Al crecer la complejidad de un proyecto de software, se aplican las técnicas de ingeniería al desarrollo. El software presenta unas peculiaridades en comparación con otros productos:

• El software es algo conceptual.
• No tiene propiedades físicas, así que no está sujeto a leyes físicas o eléctricas.
• Como concepto, crea una distancia conceptual entre el problema a resolver y el software.
• Es complejo para una persona que entiende el problema, entender el software que lo soluciona.
• Para hacer pruebas se requiere de un sistema físico.
• El mantenimiento no consiste en reemplazo de componentes.

Actualmente se debate si el desarrollo de software es una artesanía o una disciplina de ingeniería. Asumiendo lo segundo, podemos asegurar que desarrollar software de calidad con mínimo coste es una actividad muy compleja.

Ámbito de la Ingeniería del Software

A grandes rasgos, un software puede pertenecer a una o varias de estas categorías:

• Software de Sistemas: Dan servicio a otros programas, pero no tienen propósito concreto, como los servidores de bases de datos o FTP.
• Software de Aplicación: Programas independientes que resuelven necesidades concretas, normalmente de una organización, como un sistema de pedidos de tienda.
• Software Científico: Enfocado al cálculo y simulación, basados en cálculos complejos.
• Software Empotrado: Forma parte de algún dispositivo, como el software de una lavadora o la centralita de un coche.
• Software Web: Unifican fuentes de datos y servicios en entornos distribuidos o redes.
• Software de Inteligencia Artificial: Técnicas, algoritmos y lenguajes para programación funcional.

En general, las técnicas de ingeniería de software se enfocan en el software de aplicación, concretamente en los sistemas de información.

Sistemas de Información

Son conjuntos de elementos (personas, datos, técnicas y materiales informáticos) organizados y dedicados al tratamiento y administración de datos e información. Su función es cubrir una necesidad u objetivo. El software para sistemas de información gestiona cierta información mediante un gestor de bases de datos y soporta una serie de manipulaciones humanas en un contexto dado.

Historia de la Ingeniería del Software

Años 60-70

• Existían pocas computadoras (mainframes), escasas y caras.
• Poca variedad de software y muy específico, desarrollado por el fabricante.
• Desarrollo artesanal.
• El negocio estaba en el hardware.
• Se disponía del código fuente y los desarrolladores lo compartían con ánimo constructivo. Esto impulsó en los 80’s el movimiento de software libre.
• El desarrollo no seguía una planificación y era impredecible calcular costes y tiempos, aunque se empezaron a emplear técnicas de reutilización como la programación modular.
• Originalmente el software era gratuito, incluido en la compra de un hardware. Solo unas pocas compañías desarrollaban software a medida, aunque no se vendía el software como producto.

Contexto histórico

Algunos hitos del conocimiento del desarrollo de software en el ’68 eran:

• 1962: Primer algoritmo de búsquedas binarias.
• 1966: Fundación contra la sentencia GOTO y creación de la programación estructurada.
• 1968: Debate sentencia GOTO vs programación estructurada. Carta de Dijkstra.
• 1974: Primera publicación de programación estructurada.
• 1976: Primer libro sobre métrica de software.
• 1976: Primer libro sobre análisis de requisitos.

Crisis del software

Se refiere a la dificultad en escribir programas sin defectos, comprensibles y verificables. Surgió en la primera conferencia de la OTAN sobre ingeniería de software en 1968:

• Proyectos que no se ajustan al presupuesto.
• Proyectos inconclusos en el plazo.
• Software ineficiente.
• Software de mala calidad.
• Software que no cumplía los requisitos.
• Software inconcluso, abandono de proyectos…

Naturaleza y problemas

Causas de la crisis:

• La naturaleza lógica del software.
• Mala gestión de los proyectos (falta de datos, incomunicación).
• Falta de adiestramiento formal en nuevas técnicas (programadores contra ingenieros).
• Oposición al cambio.

Mitos del software

De los gestores:

• Uso de estándares de otras ingenierías.
• Mala planificación (añadir personal acelera el proyecto).

De los desarrolladores:

• Un programa que funciona está acabado.
• Calidad es una ejecución sin errores.
• Entregar al cliente implica que el programa funciona.

Del cliente:

• Requisitos establecidos como si fuesen los objetivos.
• El software será flexible ante los cambios.

La Ingeniería del Software

Definición en la conferencia de la OTAN

Establecimiento y uso de principios de ingeniería para la obtención de software económico y eficiente en máquinas reales.

Definición IEEE

Aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software, y el estudio de los mismos. Es la aplicación de la ingeniería al software, debido a que integra matemáticas, ciencias de la computación y otras prácticas de ingeniería.

Otras definiciones

Disciplina que comprende todos los aspectos de producción del software desde el inicio hasta el mantenimiento:

• Disciplina de ingeniería: teorías, métodos y herramientas para solucionar problemas contando con restricciones financieras y organizativas.
• Aspectos de producción: Procesos técnicos del desarrollo y actividades como administración de proyectos, desarrollo de herramientas, métodos y teorías.
• Actividad de modelado, solución de problemas, adquisición de conocimiento dirigida por una fundamentación.

Ingeniería

Desde el ’68, tanto los departamentos de informática de las universidades como los organismos de estandarización (SEI, IEEE, ISO, OMG) se han esforzado en identificar causas del problema y definir pautas estándar para la producción y mantenimiento del software:

• Identificar factores clave que determinan la calidad del software.
• Identificar procesos de producción y mantenimiento.
• Acotación, estructuración y desarrollo del conocimiento base para producción y mantenimiento.

Como resultado, se ha profesionalizado el desarrollo, mantenimiento y operación de los sistemas de software. La forma de trabajar de los programadores individuales, surgida en los primeros programas, es la principal causa de los problemas apuntados, y en la actualidad, una de las principales resistencias a la implantación de estas técnicas.

¿Qué es Ingeniería del Software?

Aplicar sentido común al desarrollo de sistemas de software.

¿Qué es el sentido común en IS?

• Planificar antes de desarrollar.
• Diseñar antes de programar (meses de programación ahorran horas de diseño).
• Reutilizar diseños (patrones de diseño).
• Uso de herramientas apropiadas.
• CASE: Computer Aided Software Engineering (ingeniería de software asistida por ordenador).
  Algunas herramientas CASE son:
  • Edición de diagramas: DIA.
  • Comprobación de consistencia de diagramas.
  • Generación de documentación: DOXYGEN.
  • Seguimiento de actividades de proyecto: GNOME PLANNER.
  • Upper-CASE: Herramientas para captura de requisitos, análisis y diseño.
  • Lower-CASE: Herramientas para programación y depuración: ECLIPSE, GIT.

La ingeniería del software es joven aún y necesita procesos de estandarización, útiles por diversos motivos:

• Agrupan buenas prácticas y usos del desarrollo de software.
• Engloban conocimiento.
• Permiten la implementación de procedimientos de calidad.
• Proporcionan continuidad y entendimiento entre el trabajo de personas y asociaciones.

Asociaciones de Estandarización

• SEI: Instituto de Ingeniería del Software.
• IEEE: Instituto de Ingenieros Eléctricos y Electrónicos.
• ISO: Organización de Estandarización Internacional.
• OMG: Object Management Group (Grupo de Administración de Objetos):
  • UML: Lenguaje de Modelado Unificado.
  • MDA: Model Driven Architecture (Arquitectura Dirigida por Modelos).

Necesidades de la IS

• Definirse a sí misma: SWEBOK.
• Definir procesos en desarrollo, mantenimiento y operación del software.
• Extraer modelos de cómo ejecutar los mejores procesos para evitar problemas.
• Definir estándares menores para dibujar criterios unificadores.

El proyecto SWEBOK (SoftWare Engineering Body Of Knowledge) comenzó sus actividades en el comité SWECC 1 en 1997. Dicho proyecto pretende establecer el cuerpo del conocimiento que deben conocer los ingenieros, y en su desarrollo se ha agrupado el conocimiento en varias áreas.

Solución de problemas

Los ingenieros de software buscan una solución en varios pasos:

1. Formular el problema.
2. Analizarlo.
3. Buscar una solución.
4. Decidir la idónea.
5. Especificarla.

Actividades:

• Obtención de requerimientos.
• Análisis.
• Diseño de sistema.
• Implementación.

Evaluación:

• Revisión de análisis.
• Revisión de diseño.
• Pruebas.

Administración (calendario y presupuesto).

Conceptos

• Papel o Rol: Conjunto de responsabilidades en el proyecto o sistema. Asociado con unas tareas y desempeñado por un participante. Un mismo participante puede cumplir varios papeles.
• Roles de IS en un sistema encargado por alguien ajeno:
  • Cliente: Encarga el sistema.
  • Desarrolladores: Construyen el sistema (analistas, diseñadores, programadores…).
  • Director de proyecto: Planifica, calcula presupuesto y coordina a los desarrolladores y al cliente.
  • Usuarios finales: Los que usarán el sistema.
• Sistema: Realidad subyacente.
• Modelo: Abstracción de la realidad.
• Entregable o Producto de trabajo: Elemento producido durante el desarrollo (documento, fragmento de software…).
• Actividad o fase: Conjunto de tareas realizada con un propósito específico.
• Tarea: Unidad elemental de trabajo que consume recursos, produce productos de trabajo y depende de otros productos de otras tareas.
• Recursos: Bienes usados para realizar el proyecto, tales como tiempo, personal…
• Objetivos: Principios para guiar el proyecto, definen los atributos importantes del sistema y generalmente hay conflictos entre ellos (seguridad vs. bajo coste).
• Requerimientos: Son características del sistema, pueden ser:
  • Funcionales: Tareas que debe soportar el sistema (proporcionar tickets).
  • No funcionales: Restricciones sobre el funcionamiento del sistema (proporcionar tickets a la velocidad de la luz).
• Otras restricciones: Utilizar un determinado lenguaje, plataforma o sistema antiguo.
• Notación: Conjunto de reglas para representar un modelo (UML).
• Método: Técnica repetible para resolver un problema específico.
• Metodología: Colección de métodos para la resolución de una clase de problemas.

Principios de la Ingeniería del Software

• La calidad es la razón de trabajar.
• Buena gestión mejor que buena tecnología.
• Personas y tiempo no son intercambiables.
• Entregar productos al usuario lo más pronto posible.
• Documentar.
• Determinar y acotar el problema antes de escribir los requisitos.
• Primero hacerlo correcto, después ganar velocidad.
• La gente es la clave del éxito.
• Usar el sentido común, no recurrir a dogmas.
• Hacer muchas pruebas.
• Que ni el jefe ni el cliente te convenzan para hacer chapuzas.
• Valorar el trabajo de los demás.

Ingeniería de Sistemas

La ISO relaciona la ingeniería del software y la ingeniería de sistemas, considerando al software como una parte de un sistema. Desde este enfoque, la ingeniería de sistemas es un fundamento de la ingeniería del software. Es la primera solución a la crisis del software.

Definiciones

• Sistema: Una colección de componentes de hardware, software, personas y herramientas organizados para cumplir una función o conjunto de ellas.
• Sistema de software: Colección de programas y documentación que conjuntamente satisfacen unos requisitos.
• Sistema intensivo: Prácticamente todo el sistema es software.
• Subsistema de software: El sistema de software es un componente de otro sistema mayor.
• Ingeniería de sistemas: Define el plan para gestionar las actividades técnicas del proyecto. Identifica el ciclo de desarrollo y los procesos necesarios a aplicar. El desarrollo de hardware y software parten desde esta línea base.

Metodologías Ágiles

Introducción

La mayoría de los conceptos se refieren al qué y no al cómo. Según el autor o el país, unas tareas son consideradas de la programación y otras de la ingeniería del software. La Ingeniería del Software dice qué hay que hacer para que el software sea fácilmente modificable, pero no dice cómo hacerlo. Este tipo de ingeniería se denomina predictiva, y trata de anticipar los máximos requisitos y delimitarlos en el tiempo. En 2001, un grupo de críticos se reunieron para acuñar el término «Métodos Ágiles», para definir las alternativas a las metodologías formales, consideradas excesivamente rígidas y pesadas debido a su carácter normativo y planificador.

Manifiesto Ágil

Son los valores sobre los que se asientan estos métodos. Hasta 2005 hubo discusiones entre radicales de modelos de procesos vs. métodos ágiles. El manifiesto ágil valora:

• Los individuos y su interacción por encima de los procesos y herramientas.
• El software que funciona, por encima de la documentación exhaustiva.
• La colaboración con el cliente por encima de la negociación contractual.
• Respuesta al cambio por encima del seguimiento de un plan.

El Proceso de Desarrollo de Software

Introducción

En la IS, el desarrollo se organiza a modo de proyectos, y estos se gestionan según el método de desarrollo a aplicar. El método de desarrollo definirá un ciclo de vida, qué procesos, actividades y tareas tendrán lugar en cada ciclo, quién las llevará a cabo y la interacción entre tareas, roles y personas.

Historia e Influencias en los Métodos

Disciplina de gestión de proyectos en los 50’s

• PMI (Project Management Institute): el modelo más popular.
• Una de las metáforas aplicadas en el desarrollo de software fue la gestión científica desarrollada por Taylor y basada en:
  • Descomponer el proceso industrial en tareas cortas y repetitivas.
  • El claro ejemplo es la cadena de producción industrial.
  • Ciclo en cascada (una operación pasa a la siguiente).
• Método Toyota lean-manufacturing con sus principios:
  • Evitar la producción de productos defectuosos, parando incluso la cadena.
  • Producir el mínimo necesario para no acumular excedente.
  La aplicación de esta filosofía se conoce como lean software development.

Clasificación de Métodos de Desarrollo

Las actividades, a grandes rasgos, son las mismas en los métodos. Las diferencias radican en cuándo y cómo se realizan las actividades.

Selección de método

El ingeniero de software elegirá el método más adecuado según la naturaleza del proyecto, basándose en:

• Riesgo.
• Valor de negocio.
• Duración.
• Complejidad.
• Tecnología.
• Número de departamentos implicados.
• Coste.

Según se conozca claramente o no el objetivo y los detalles sobre la solución, determinaremos los siguientes grupos:

	Solución Conocida	Solución Poco Conocida
Objetivo Claro	Grupo 1	Grupo 2
Objetivo Difuso	Grupo 3	Grupo 4

• Grupo 1: Elegiremos un método con poca tolerancia al cambio, pero sencillo de aplicar (ciclo de vida en cascada).
• Grupo 2: Cambian las ideas iniciales a medida que el proyecto avanza y se facilita el descubrimiento de la solución mediante ciclos de realimentación. La mayoría de proyectos son de este grupo (método iterativo e incremental, métodos ágiles).
• Grupo 3: Proyecto en el que tenemos una solución, pero no existe el problema que resuelve.
• Grupo 4: Suelen ser proyectos de investigación, tan flexibles respecto a la solución final que, en ocasiones, suele solucionarse un problema distinto al que se buscaba solución a priori.

Ciclo en Cascada

Ciclo de vida en cascada o clásico

Propuesto por Winston Royce en 1970. Se asemeja a una cadena de producción de trabajadores especializados (analistas, arquitectos de software, especialistas en pruebas). Los trabajadores producen artefactos consumidos por los trabajadores de la siguiente etapa de la cadena.

Ventajas

• Sencillo de aplicar.
• Apropiado para:
  • Desarrollar nuevas versiones de sistemas veteranos en los que el desconocimiento de las necesidades de los usuarios o el entorno no plantea riesgo.
  • Sistemas pequeños que no tiendan a evolucionar a corto plazo.

Inconvenientes

• Difíciles de aplicar por su rigidez.
• Necesario acabar una etapa para continuar la próxima.
• Poca tolerancia al cambio.
• Cambios que se arrastran y propagan de una etapa a las siguientes.
• Análisis puramente teóricos.

Etapas

1. Requisitos: Indica qué debe ser el producto. Es una etapa crítica para el proyecto.
2. Diseño: Indica cómo debe ser el producto. Analiza cómo debe ser el producto, tanto desde una visión externa como internamente, las relaciones entre componentes.
3. Codificación: Escritura del código, manuales y generación de un ejecutable.
4. Pruebas: Se verifica con usuarios finales que el producto se corresponde con los requisitos.
5. Integración: Se implanta el producto en el entorno del usuario.
6. Operación y Mantenimiento: Se pone el sistema a disposición de todos los usuarios y se corrigen los defectos encontrados.

Tipos

• En cascada lineal o secuencial: No existe comunicación con la etapa anterior, los artefactos se van propagando solo hacia adelante.
• En cascada con retroalimentación: Existe un retorno en cada etapa que afecta a la etapa anterior y consecutiva.
• En cascada con retroalimentación a cualquier fase: Una etapa puede producir un retorno que modifique cualquiera de las otras.

Ciclo Iterativo

Superación de limitaciones del ciclo en cascada

En el ciclo de vida en cascada no hay información empírica sobre el producto final hasta que no está el proyecto casi acabado. El conocimiento sobre la marcha del proyecto y el producto final es solo teórico. El coste de errores en primeras etapas es mayor que en posteriores. Se necesitan métodos que permitan cambios de ideas conforme avanza el proyecto. Los métodos iterativos permiten descubrir la solución obteniendo información empírica y resultados parciales funcionales. En cascada no se produce ningún item tangible hasta el final. En proyectos largos, supone una inversión a ciegas sin recuperación.

Bases de modelos iterativos

• El desarrollo se basa en iteraciones, que producen un subsistema que amplía el resultado de la iteración anterior.
• Cada iteración cubre todas las actividades del desarrollo (Requisitos, Diseño, Codificación…) y existe retroalimentación entre esas etapas.
• Al final de una iteración existe un artefacto utilizable que permite usar el sistema.

Modelo incremental

En cada iteración se produce un subsistema que, unidos en conjunto, conformarán el sistema final. Se van entregando con cada iteración productos funcionales cada cierto periodo de tiempo.

Modelo evolutivo

• Se compone de varios ciclos de desarrollo, en el que se producirá un sistema completo.
• La información acumulada mejora las etapas.
• Es un único ciclo, apto para sistemas que se mejoran con versiones sucesivas.

Sobre las iteraciones

• Cada iteración dura entre 1-6 semanas.
• En cada iteración se trabajan todas las fases.
• «>Conforme avanza el proyecto, se hará más o menos énfasis en cada etapa, variando de izquierda a derecha.
• En cada iteración se incrementa el volumen de funcionalidades del sistema.
• Facilita la planificación centrada en el cliente.

Métodos Ágiles o Ligeros

Consideran a las personas más importantes que los procesos. Son métodos poco estrictos en cuanto a los procesos a seguir y artefactos a generar, por tanto se denominan métodos ligeros. Este enfoque parece ir en contra del enfoque sistemático, ya que se asume que un proceso siempre dependerá de las personas y, por tanto, se limita la transferencia del conocimiento entre las ejecuciones del proceso. En la práctica, el proceso definido en métodos ágiles se centra más en las personas y sus interacciones que en los roles y tareas a asumir. Esto no quiere decir que no exista un proceso definido, sino que el proceso se ha de centrar en la interacción entre personas. La mayoría de métodos ágiles son iterativos e incrementales, dando importancia al software operativo (artefactos listos para usar, producto de cada iteración) y así facilitan la colaboración con el cliente y la respuesta al cambio.

Filosofía Lean

• Evitar producción innecesaria: solo producir lo necesario para la etapa siguiente.
• Amplificar aprendizaje: recopilando toda la información generada durante el desarrollo del producto con el fin de mejorar.
• Decidir lo más tarde posible: para ampliar los márgenes de tiempo disponibles.
• Entregar un producto cuanto antes mejor.
• Dar poder al equipo: de modo que se sientan responsables del resultado.
• Incorporar integridad: de modo que se pueda cambiar fácilmente a lo largo del tiempo.
• Visión global: adoptando una visión amplia del sistema y cuidando de no modificar métodos que impliquen a otros.

Ciclo en Espiral

Definido por Boehm en 1988. Presenta un desarrollo evolutivo. El ciclo de iteración es una espiral sobre ejes cartesianos, representando cada cuadrante una clase particular de actividad:

• Planificación: En cada vuelta se establece el contexto de desarrollo y se decide cuál será el del próximo ciclo.
• Análisis de riesgo: Se evalúan alternativas para la ejecución de la siguiente parte del desarrollo.
• Actividades de Ingeniería: Son las indicadas en modelos lineales: Análisis, Diseño, Codificación…
• Evaluación: Se hace una evaluación de los resultados para tomarlos como punto de partida en la siguiente fase.

Estos se suceden continuamente a lo largo del desarrollo, siguiendo la espiral.

Proceso Unificado de Desarrollo (PUD)

Introducción

El PUD se propuso con la intención de ser el referente en los métodos de desarrollo de software. Es un conjunto de procesos configurable que se puede adaptar a distintos contextos. Existen variantes, como OpenUP.

Mejores prácticas

• Desarrollo iterativo e incremental.
• Requisitos mediante casos de uso.
• Arquitectura basada en subsistemas.
• Utilización de modelos visuales (UML).
• Verificación de calidad en cada etapa.
• Control de cambios.

Además, PUD promueve:

• Comenzar por la construcción de las partes con más riesgos.
• Construir una arquitectura ejecutable durante las primeras etapas del proyecto.
• Descomponer en fases (tiempo) y en actividades.
• Definir roles de personas y tareas para dicho rol.

Fases de proyecto

• Inicio: Se analiza el proyecto desde la visión de la organización, se determina el ámbito, se valoran los recursos, se identifican riesgos y casos de uso.
• Elaboración: Se elabora un conjunto de requisitos estables, se eliminan los riesgos y se construye la base de la arquitectura (ejecutable).
• Construcción: Se desarrolla el resto de la funcionalidad, secuencialmente o en paralelo, y se obtiene el producto y la documentación.
• Transición: Se pone el producto a disposición de los usuarios (betas, migraciones…).

Hitos del PUD

• Objetivos: Analiza el coste y los beneficios esperados del proyecto, necesitando:
  • Explorar la funcionalidad a desarrollar, a quién afectará el nuevo sistema y quién interactuará con él.
  • Tener una idea aproximada de la solución final.
  • Estimar el coste inicial y el calendario, así como los riesgos.
• Arquitectura: Se alcanza al tener una versión estable de la arquitectura, con las funcionalidades más importantes implementadas y eliminados los principales riesgos. Esto se cumple cuando:
  • Conocemos el coste pendiente del proyecto y los problemas que encontraremos.
  • Se implementaron un número significativo de funcionalidades.
• Capacidad operacional inicial: Se comprueba si se ha implementado toda la funcionalidad.
• Entrega del producto: Se decide si se han cumplido los objetivos y los clientes deben aceptar el proyecto entregado.

Ventajas del PUD

Se pueden tomar decisiones basadas en información empírica y no en conjeturas teóricas.

Actividades

• Modelización de negocio: Se generan casos de uso de negocio, de modo que los desarrolladores y la organización que requiere el sistema comprendan los procesos.
• Requisitos: Describe qué hace el sistema y qué no hace. Se usa el modelo de casos de uso que describe los escenarios de uso del sistema.
• Análisis y diseño: Describe cómo implementar el sistema. Se detallan los componentes del sistema y sirven de guía a los implementadores a la hora de programar.
• Implementación: Define la organización del código, escribirlo y verificar que los componentes cumplen los requisitos de forma unitaria (aislada de otros componentes). Permite la reutilización de otros componentes.
• Pruebas: Verifican la interacción entre objetos y componentes (fiabilidad, rendimiento).
• Despliegue: Entrega a usuarios finales, configuración y versiones.

Roles

• Stakeholder o cliente: Interesado en el resultado del proyecto.
• Jefe de proyecto: Coordinador y planificador entre stakeholders. Responsable del equipo.
• Analista: Toma la información de los stakeholders como requisitos, los clasifica y prioriza.
• Arquitecto: Define la arquitectura del software.
• Desarrollador: Desarrolla una parte del sistema de acuerdo a la arquitectura, prototipa la interfaz gráfica, la implementa y la prueba.
• Experto en pruebas: Define e implementa pruebas trabajando sobre el sistema construido.

Scrum

Definición

Se trata de un método ligero que, siguiendo el principio lean de generar artefactos mínimos con valor importante, minimiza el conjunto de prácticas, artefactos, tareas y roles.

Roles

Se define stakeholder como parte interesada que solo están involucrados, y equipo a los que están comprometidos en el desarrollo.

• Scrum Master: Responsable de asegurar que el equipo sigue los valores y reglas de la metodología Scrum.
• Product Owner: Es el responsable de velar por los intereses de la parte interesada o stakeholder.
• Team: Resto de miembros del equipo. Ellos se organizan y no han de ser especialistas, sino que han de saber sobre todas las actividades implicadas.

Artefactos

• Product backlog: Lista de requisitos a implementar en el producto. Cada entrada es una historia de usuario.
• Sprint backlog: Descompone las historias de usuario en tareas de entre 4-16 horas. Los sprints duran como máximo 6 semanas, y se recomienda realizarlos entre 2-3 semanas.
• Release Burndown: Gráfico que muestra el progreso del equipo respecto a las historias de usuario que quedan por implementar.
• Sprint Burndown: Para una iteración concreta, el progreso se mide en tareas finalizadas, aunque no sean historias de usuario completas.

Prácticas

• Sprint planning meeting: Reunión antes de comenzar un sprint en la que se deciden qué historias de usuario se implementarán en el sprint. Aquí crean el sprint backlog.
• Daily scrum: Reunión diaria en la que los miembros del equipo reflexionan sobre lo que hicieron ayer, harán hoy e impedimentos encontrados. Es una oportunidad de sincronismo entre los miembros.
• Sprint review meeting: Al terminar un sprint se revisa el trabajo y se muestra al interesado.
• Sprint retrospective: Se usa para reflexionar sobre lo ocurrido durante un sprint e identificar oportunidades de mejora.

Análisis de Requisitos

Definición y Tipos

Los requisitos expresan las necesidades y restricciones que afectan al producto de software (el cual es la solución a un problema del mundo real), y se usan para acotar las soluciones no adecuadas. Para determinar si una solución cumple los requisitos, estos deben referenciar una o varias características observables del sistema. Para que una característica observable sea un requisito, debe expresar alguna necesidad o restricción que afecte al software. Una característica observable no puede ser un concepto difuso ni ambiguo, sino que debe estar acotado. «El sistema debe ser rápido» vs. «El sistema permitirá su uso en menos de 3 pasos».

Partes Interesadas o Stakeholders

Son personas y entidades con interés en el proyecto. Los requisitos nos dicen qué es lo que los stakeholders esperan del sistema.

Relevancia de los Requisitos

Si no están bien definidos, surgen problemas. Los requisitos ambiguos producen malinterpretaciones de usuarios y desarrolladores. Lo deseable es que los requisitos sean completos y consistentes:

• Completos: Descripción de todo lo esperado por el usuario.
• Consistentes: No hay contradicciones entre los requisitos.

En la práctica, es imposible recoger los requisitos de modo completo y consistente.

Diferentes interpretaciones

«El programa proporcionará un visor de documentos».

• Intención del usuario: Visor especial para cada tipo de documento.
• Intención del desarrollador: Visor de texto que muestre el contenido del documento.

Tipos de Requisitos

• Funcionales: Hacen referencia a necesidades y funcionalidades (qué ha de hacer).
• No funcionales: Expresan restricciones sobre las soluciones (cómo se ha de hacer).

Requisitos funcionales

Indican qué cálculos realiza el sistema, qué datos posee, cómo manipularlos. Indica el comportamiento del modelo ante los estímulos del controlador.

Requisitos no funcionales

Suelen ser una restricción y afectan a gran parte del sistema

No incluyen comportamiento, solo especifican criterios para evaluar calidad general del sistema (seguridad, rendimiento…)

Tipos

Del producto: Especifican el comportamiento del producto. (rapidez, fiabilidad)

Organizacionales: Derivan de politicas y procedimientos existentes en la organización del cliente y del desarrollador (estándares, métodos de diseño…)

Externos: Derivan de factores externos al sistema y sus procesos de desarrollo (legislativos, éticos)

Identificación de Requisitos

Lluvia de ideas

Se aplica cuando no hay punto de partida

Se crea un grupo de trabajo

Brainstorming inicial

Consolidación del conjunto inicial

Refinamiento

Entrevistas y cuestionarios

Elegir una muestra representativa de entrevistados

Evitar respuestas condicionadas

Evitar respuestas limitadas por el conocimiento actual

Aportar datos sobre el coste de alternativas

Observación

Consiste en observar a los usuarios mientras usan un sistema

Detecta requisitos de usabilidad

Facilita comunicación con el usuario

Explora alternativas

Listas predefinidas

Mediante checklists no pasaremos por alto ningún requisito, sobre todo, funcionales.

El estandard IEEE830 nos recuerda que se han de documentar tanto los requisitos funcionales como los no funcionales:

Rendimiento (volumen de usuarios, de datos)

Requisitos lógicos de BBDD (tipo de acceso, frecuencia, entidades)

Restricciones de diseño (limitaciones de hardware, otros estandares)

Otros atributos: fiabilidad, seguridad, portabilidad…

Gestión

Obtenida la lista de requisitos candidatos, se han de seleccionar para redactar la lista definitiva de requisitos.

Una buena gestión permite maximizar el valor obtenido por el proyecto de desarrollo. Incluye estas pautas:

Valoración de requisitos

Priorización de los mismos

Selección según riesgo

Documentación

Definición y características deseables

La especificación al artefacto es un documento de texto que documenta los requisitos seleccionados para el proeycto.

Es un contrato entre diseñadores y stakeholders.

La forma y detalle de la especificación depende de cada proyecto, así pues la documentación puede ser generada por la misma empresa desarrolladora del software, por una subcontrata…

Calidad

La IEEE define una especificación de requisitos de calidad cuando se cumple:

Corrección: Requisitos documentados son necesarios

No ambigua: Cada requisito solo puede ser interpretado de una forma

Completa: Debe incluir todos los requisitos posibles de todos los stakeholders

Consistente: Sin conflictos entre ellos

Etiquetados: Requisitos con etiquetas como importancia y coste

Verificable: Requisitos que sean medidas observables y medibles

Trazable: Requisitos enumerados e identificados, facilitando referencias entre artefactos como documentos, software, pruebas…

Logrando la calidad en la obtención

Identificadores de requisitos

Punto de vista global

Granularidad

No suponer interfaz grafica

Condiciones de aceptación

Uso de plantillas

Historias de usuario

La pila de producto (conjunto de historias de usuario) son el corazón de Scrum.

Son una lista priorizada de requisitos, historias o funcionalidades que el cliente desea para su producto software.

Se describen usando un lenguaje comprensible por el cliente.

Nº de Historia 1	INSERTAR CONTACTO
Cómo administrativo quiero insertar contactos teniendo todos sus datos siempre y cuando el contacto no esté registrado con anterioridad.
Estimación: 330
Prioridad: 1		Dependiente de: X
PRUEBAS DE ACEPTACIÓN
Comprobar que los datos introducidos no tengan valores erróneos. Comprobar que se ha insertado bien el contacto comprobando el listado o buscando. Comprobar que el contacto insertado no existe ya.

Casos de uso

Es una técnica de documentación de requisitos muy extendida apoyada por UML.

Describe mediante secuencias y bifurcaciones de acciones una ejecución de un sistema y los posibles resultados que produce.

No todos los actores tienen por que estar implicados en un caso de uso, puede existir un actor principal y actores secundarios.

CASO DE USO: CopiaDeSeguridad

ID: 3

DESCRIPCIÓN: Realizar manualmente una copia de seguridad de la información almacenada sobre los contactos en la agenda, volcándola en un fichero local.

ACTORES PRINCIPALES Administrativo

ACTORES SECUNDARIOS

PRECONDICIÓN 1. Tener contactos ya almacenados en el sistema

FLUJO 1. El administrativo decide guardar una copia de seguridad y ejecuta la orden por consola de comandos 2. El sistema pide una ruta y nombre de fichero para esta copia de seguridad 3. El administrativo facilita al sistema dicho nombre para el fichero 4. La copia de seguridad queda almacenada con éxito

POSTCONDICIONES 1. Existirá un fichero copia de seguridad almacenado en la ruta facilitada al sistema

FLUJOS ALTERNATIVOS 2.B. La agenda aun está vacía y el sistema nos indica que no es necesario guardar copia 4.B. El usuario del S.O. no tiene permisos de escritura para la ruta especificada y no se puede guardar el fichero. 4.B.1. El sistema vuelve al paso 3 solicitando de nuevo una ruta y nombre de fichero

TEMA 5

Lenguaje Unificado de Modelado

Definición

El UML es un lenguaje de propósito general estandarizado, pensado para visualizar la parte de la especificación y diseño de un sistema software.

Modelar es la actividad de diseñar aplicaciones software antes de programarlas

El UML está estandarizado por la Object Management Group (OMG)

Uso

UML ayuda a especificar, visualizar y documentar modelos de sistemas software, incluyendo su estructura y diseño para que estas cumplan todos los requisitos. UML modela:

• Cualquier actividad

Componentes individuales del sistema

Como se ejecutará el sistema

Interacción entre entidades

Interfaces externas

Como bien define la OMG, UML ayuda a todo esto, pero los modelos visuales siempre se acompañarán de texto, citas y recursos para tener precisión en el documento.

Por tanto se puede decir que UML sirve para:

Visualizar

Especificar

Construir

Documentar

Artefactos de un sistema con gran cantidad de software

Objetivos

Modelar sistemas desde los requisitos hasta los artefactos ejecutables usando orientación a objetos

Cubrir cuestiones de tamaño de sistemas complejos

Usar un lenguaje utilizable por máquinas y personas

Equilibrio entre expresividad y simplicidad

UML es una notación (NO es un proceso y NO es una metodología)

La principal utilidad es permitir la comunicación.

Comenzar con UML

Requiere de unas pautas sin orden estricto:

Formarse en UML

Elegir una metodología que se ajuste bien al ámbito de nuestro sistema

Elegir una herramienta de desarrollo UML acorde con la metodología

Tipos de diagrama

Diagrama de Clases

Definen la estructura estática de un sistema.

Las entidades se agrupan en categorías llamadas clases, las cuales albergan atributos y acciones.

Un rectángulo representa la clase, y se divide en 3 áreas.

Nombre de clase / Atributos / Metodos

Las clases se

Diagrama de Objetos

Diagrama de Casos de Uso

Diagrama de Estados

Diagrama de Secuencias

Diagrama de Actividades

Diagrama de Colaboraciones

Diagrama de Distribución