Introducción a la Ingeniería del Software

1. El Informe CHAOS

El informe CHAOS, realizado por la consultora Standish Group, intenta identificar los principales problemas del desarrollo de software. Clasifica miles de proyectos reales como:

• Éxito: finalizado dentro del plazo y presupuesto, y cumpliendo todos los requisitos.
• Con problemas: finalizado, pero fuera de plazo, fuera de presupuesto y sin cumplir todos los requisitos.
• Fracaso: cancelado durante el desarrollo.

2. Factores de Éxito según los Informes CHAOS

Según los resultados de los informes CHAOS, los principales factores de éxito de los proyectos de ingeniería del software están relacionados con la implicación de usuarios y directivos. Los proyectos que tienen éxito lo hacen porque los usuarios y los directivos están implicados y apoyan al proyecto.

3. Causas de Problemas según los Informes CHAOS

Según los resultados de los informes CHAOS, las principales causas de problemas de los proyectos de ingeniería del software están relacionadas con:

• Falta de información por parte de los usuarios.
• Especificaciones y requisitos incompletos o cambiantes.
• Falta de apoyo de los directivos o falta de recursos.
• Incompetencia tecnológica.
• Expectativas no realistas u objetivos poco claros.
• Plazos temporales no realistas o nueva tecnología.

4. Factores de Fracaso según los Informes CHAOS

Según los resultados de los informes CHAOS, los principales factores de fracaso de los proyectos de ingeniería del software están relacionados con requisitos incompletos. Muchos proyectos fracasan porque no se desarrollan ni gestionan correctamente los requisitos.

5. El Término «Ingeniería del Software»

Se usó por primera vez en una conferencia sobre desarrollo de software de la OTAN en 1968 en Garmisch, Alemania. El término se atribuye a Fritz Bauer.

6. El Término «Crisis del Software»

Hace referencia a los problemas de sobrecostes, retrasos, baja calidad, mantenimiento difícil, etc., que afectaron al desarrollo del software en sus inicios por falta de un enfoque de ingeniería.

7. Roles en un Proyecto de Software

Los roles en un proyecto de software son:

• Jefe del proyecto.
• Ingeniero de requisitos.
• Equipo de desarrollo.
• Equipo de calidad.
• Cliente.
• Usuario.

8. La Norma ISO/IEC 12207

Distingue dos tipos de procesos: específicos del software y del contexto del sistema.

9. CMMI-DEV (Capability Maturity Model Integration for Development)

Es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software.

10. ¿Qué son los Entregables?

El conjunto de productos que deben desarrollarse y entregarse al cliente durante un proyecto.

11. Entregables Habituales de un Proyecto

Los entregables habituales de un proyecto son:

• Plan de proyecto.
• Informes de seguimiento.
• Especificación de requisitos.
• Documento de diseño.
• Plan de pruebas.
• Código fuente.
• Software ejecutable.
• Manuales de usuario.

12. El Mantenimiento del Software

Es la fase con un coste más alto de todo el ciclo de vida.

13. Tipos de Mantenimiento

• Evolutivo.
• Correctivo.
• Adaptativo.
• Perfectivo.

14. ¿Qué se entiende por Calidad del Software?

Cumplir los requisitos establecidos explícitamente, con los estándares de desarrollo necesarios y tener las características implícitas que se espera de todo software desarrollado profesionalmente.

15. El Coste del Desarrollo de Software

Es cada vez menor debido a las mejores herramientas de desarrollo disponibles.

16. El Grupo de SQA (Software Quality Assurance)

El grupo de SQA es responsable de:

• Establecer el plan de SQA del proyecto.
• Participar en la definición del plan del proyecto.
• Auditar los productos del desarrollo.
• Documentar e informar de las desviaciones o no conformidades que se vayan detectando en las revisiones técnicas formales (RTF).

17. ¿Qué es una Baseline?

Es una versión cerrada de algún elemento de configuración que no se puede cambiar sin seguir la política de control de cambios del proyecto.

El Ciclo de Vida del Software

1. ¿Qué es el Ciclo de Vida del Software?

Es un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software.

2. El Ciclo de Vida de un Proyecto

Especifica el enfoque general del desarrollo, indicando los procesos, actividades y tareas que se van a realizar y en qué orden, y los productos que se van a generar, los que se van a entregar al cliente y en qué orden se van a entregar.

3. Orden de las Fases en el Ciclo de Vida en Cascada del Software

Análisis, diseño, implementación, pruebas, mantenimiento.

4. Ciclos de Vida del Software: Afirmación Correcta

La planificación de los desarrollos con ciclos de vida evolutivos es más compleja que la de los que siguen un ciclo de vida en cascada.

5. Procesos y Actividades en un Ciclo de Vida

Todos los procesos y actividades desde la definición de requisitos hasta que el software deja de usarse.

6. Valores del Manifiesto Ágil

Ciclos de vida evolutivos con iteraciones de corta duración para favorecer la comunicación con el cliente y el usuario.

7. ¿Qué son los Ciclos de Vida Ágiles?

Son ciclos de vida evolutivos con iteraciones de corta duración para favorecer la comunicación con clientes y usuarios.

8. Elección de un Ciclo de Vida para Requisitos Iniciales Desconocidos

Se utilizaría un ciclo de vida evolutivo, ya que permite adaptarse a los cambios en los requisitos a lo largo del proyecto. El ciclo de vida en cascada clásico es el menos apropiado en este caso.

9. Características de los Ciclos de Vida del Software

La planificación de los desarrollos con ciclo de vida evolutivo es más compleja que los que siguen un ciclo de vida en cascada.

11. El Modelo en V

Asocia un tipo de pruebas a cada producto de cada fase según su nivel de abstracción.

12. La Ingeniería Inversa

Consiste en analizar el resultado de una fase del desarrollo de software para obtener el resultado de la anterior, normalmente analizar el código para obtener el diseño.

13. La Reingeniería

Utiliza la información obtenida por la ingeniería inversa para aplicar cualquier tipo de mantenimiento.

Introducción a los Sistemas de Información

1. ¿Qué es un Sistema?

Un sistema es un conjunto de componentes que interactúan entre sí para lograr unos objetivos comunes.

2. Sistemas de Información: Definición

Un sistema de información está diseñado para recoger, almacenar, procesar y distribuir información sobre el estado de su entorno o soportar las operaciones, la gestión y la toma de decisiones de la organización de la que forma parte.

3. Clasificación de un Sistema de Información

Se puede clasificar en estratégico, táctico y operacional.

4. ¿Qué es un Sistema Informático?

Sistema compuesto por hardware, software, por las personas encargadas de su gestión y por sus procedimientos de operación y mantenimiento.

5. Relación entre Sistema Informático y Sistema de Información

Un sistema de información suele incluir entre sus componentes un sistema informático, pero podría ser completamente manual y no hacerlo, y un sistema informático no tiene por qué ser parte de un sistema de información de una organización.

6. Funciones de un Sistema de Información

Memoria, informativa y activa.

7. Realización de las Funciones de un Sistema de Información

Bajo demanda y/o autónomamente.

8. Componentes de un Sistema de Información

Está compuesto por los recursos de personas, software y hardware, comunicaciones, datos y actividades del sistema.

9. Clasificación de los Sistemas de Información según el Servicio que Ofrecen

Sistemas de apoyo a la gestión y sistemas de apoyo a la operación.

10. DSS (Decision Support Systems)

Sistemas de soporte de decisiones.

11. MIS (Management Information System)

Información de gestión.

12. TPS (Transactional Processing System)

Sistema de proceso transaccional.

13. Transacciones en Sistemas de Información

Las transacciones son hechos o actividades que se llevan a cabo en una organización y que aportan nueva información.

14. Objetivo de los TPS

El objetivo de los TPS es capturar y procesar datos sobre las transacciones que se realizan diariamente en la organización.

15. Características de las Transacciones

Suelen tener procedimientos definidos y rutinarios, lo que permite informatizarlos con facilidad y trabajar con grandes cantidades de información. Recogen la mayoría de los datos para los otros sistemas de información de la organización.

16. Fallo Grave en un TPS

Puede llegar a paralizar la organización y provocar un desastre, son esenciales para la operativa diaria.

Introducción al Modelado de Procesos de Negocio

1. ¿Por qué Modelar los Procesos de Negocio?

Porque tenemos que evitar plantear un sistema de información sin conocer la operativa de la organización del cliente (sus procesos de negocio, ya que es una receta segura para el fracaso) y podemos desarrollar un producto técnicamente correcto, pero que no tendrá éxito por no ser útil para los usuarios.

2. ¿Cómo Modelar Procesos de Negocio?

Textualmente (descripción en lenguaje natural similar a los casos de uso) y diagramáticamente (descripción mediante un diagrama EPC, de actividad UML o diagramas BPMN). Lo más recomendable es combinar ambos tipos de descripciones, complementando los diagramas con descripciones textuales.

3. Elementos Esenciales de BPMN

• Tarea: cualquier actividad que se realiza durante un proceso de negocio.
• Flujo: indican el orden en el que se deben realizar las tareas.
• Compuerta (Gateway): permiten bifurcaciones en el flujo de tareas.
• Eventos: indican el inicio de un proceso, su finalización y otro tipo de sucesos.
• Pools y Swimlanes: indican la organización del proceso y los roles que realizan las tareas.

4. Tipos de Compuertas en BPMN

• Compuerta Exclusiva: el flujo de realización de tareas solo puede tomar un camino de varios posibles.
• Compuerta Paralela: el flujo de realización de tareas toma todos los caminos posibles.

Introducción al Modelado Conceptual

1. ¿Qué es el Modelado Conceptual?

El modelado conceptual es una técnica de análisis de requisitos y de diseño de bases de datos.

2. Modelado Conceptual como Técnica de Análisis de Requisitos

Ayuda a identificar problemas en los requisitos antes de comenzar el desarrollo, evitando gastos innecesarios.

3. Modelado Conceptual como Técnica de Diseño de Bases de Datos

Permite representar de forma abstracta los conceptos y hechos relevantes del dominio del problema y transformarlos posteriormente en un esquema de una base de datos concreta.

4. ¿Qué es el Dominio del Problema?

Área de experiencia o aplicación que necesita conocerse para resolver un problema.

5. Dominio del Problema en Sistemas de Información

El conjunto de conceptos interrelacionados que es necesario conocer para entender el negocio del cliente y, por lo tanto, para poder entender sus necesidades y proponer una solución adecuada.

6. ¿Cuándo se usa el Modelado Conceptual?

Independientemente del ciclo de vida, se utiliza durante el análisis.

7. Trazabilidad de los Elementos del Modelo Conceptual

Todo elemento de un modelo conceptual debe estar trazado hacia aquellos requisitos que lo justifican, normalmente requisitos de información y reglas de negocio.

8. Conceptos Básicos del Modelado Conceptual

Clase, entidad (atributo), asociación, objeto (instancia de una clase), enlace (instancia de una asociación), generalización/especialización y composición.

9. Estereotipo «Entidad»

Indica que la clase representa una entidad y no una clase de un lenguaje de programación orientado a objetos.

10. Clasificación {Completa}

Las instancias de la superclase deben ser instancias de al menos una subclase, la superclase es abstracta.

11. Clasificación {Incompleta}

Puede haber instancias de la superclase que no lo sean de ninguna subclase.

12. Clasificación {Disjunta}

Las instancias de la superclase pueden ser instancias de una sola subclase.

13. Clasificación {Solapada}

Las instancias de la superclase pueden ser instancias de una o más subclases.