Conceptos Clave y Mejores Prácticas en Ingeniería de Software

¿Qué es el Software?

El software se define como un conjunto de programas de cómputo y su documentación asociada. Esta documentación puede incluir requerimientos, arquitectura, modelos de diseño y manuales de usuario.

Tipos de Productos de Software

• Genéricos: Desarrollados para un mercado amplio y vendidos a cualquier cliente que pueda comprarlos.
• Hechos a medida: Desarrollados para un cliente específico de acuerdo con sus necesidades.

¿Qué es la Ingeniería de Software?

La Ingeniería de Software es una disciplina que abarca todos los aspectos relacionados con la producción de software, desde las etapas iniciales de especificación hasta el mantenimiento del sistema después de su puesta en producción.

Actividades Genéricas en los Procesos de Software

Todos los procesos de software involucran las siguientes actividades:

• Especificación: Definir qué debe hacer el sistema y sus restricciones de desarrollo.
• Desarrollo: Producir el sistema de software.
• Validación: Verificar que el software cumple con los requerimientos del cliente.
• Evolución: Adaptar el software a las nuevas necesidades del cliente o del mercado.

Modelos de Proceso Genéricos

• Modelo en Cascada: Enfoque secuencial donde cada etapa se completa antes de pasar a la siguiente.
• Desarrollo Iterativo: El software se desarrolla en incrementos, con retroalimentación del cliente en cada iteración.
• Ingeniería de Software Basada en Componentes: Se enfoca en la reutilización de componentes de software existentes.

Herramientas CASE (Computer-Aided Software Engineering)

Son sistemas de software que proporcionan soporte automatizado para las actividades del proceso de desarrollo de software.

Herramientas CASE Tardías o Inferiores

Estas herramientas soportan actividades posteriores como la programación, depuración, pruebas y testeo.

Herramientas CASE Tempranas o Superiores

Estas herramientas soportan las actividades iniciales de requerimientos y diseño.

Atributos de un Buen Software

• Mantenibilidad: El software debe ser fácil de modificar y adaptar a nuevas necesidades.
• Confiabilidad: El software debe funcionar correctamente y sin fallos.
• Eficiencia: El software debe utilizar los recursos del sistema de manera óptima.
• Aceptabilidad: El software debe ser fácil de usar y comprender por los usuarios.

Etapas del Proceso de Pruebas

• Pruebas de Componentes o Unidades: Verificar que cada componente del sistema funciona correctamente de forma individual.
• Pruebas del Sistema: Verificar que los componentes integrados funcionan correctamente en conjunto.
• Pruebas de Aceptación: Verificar que el sistema cumple con los requerimientos del cliente.

Fases de RUP (Rational Unified Process)

• Inicio: Establecer el alcance del proyecto y su viabilidad.
• Elaboración: Definir la arquitectura del sistema y refinar los requerimientos.
• Construcción: Desarrollar el sistema de software.
• Transición: Desplegar el sistema en el entorno del cliente.

Plan de Proyecto

Un plan de proyecto establece:

• Recursos disponibles: Recursos humanos, hardware y software necesarios para el proyecto.
• División del trabajo: Asignación de tareas a los miembros del equipo.
• Plan de trabajo: Cronograma de actividades y entregables.

Estructura de un Plan de Proyecto

1. Introducción
2. Organización del proyecto
3. Análisis de riesgo
4. Requerimientos de recursos de hardware y software
5. División del trabajo
6. Programa del proyecto
7. Mecanismos de supervisión y presentación de informes

Diferencia entre Ingeniería de Software y Computación

La computación se centra en las teorías y fundamentos de los sistemas de cómputo. La Ingeniería de Software se enfoca en los aspectos prácticos del desarrollo y la entrega de software útil.

Modelo de Proceso de Software

Un modelo de proceso de software es una representación simplificada de un proceso de software. Puede incluir diferentes perspectivas:

• Perspectiva de flujo de trabajo: Secuencia de actividades.
• Perspectiva de flujo de datos: Flujo de información.
• Perspectiva de Casos de Uso: Quién hace qué (funcionalidad).

Descripciones del Modelo

• Descripciones de modelos gráficos: Representaciones visuales del sistema.
• Reglas: Restricciones aplicadas a los modelos del sistema.
• Recomendaciones: Sugerencias para un buen diseño.
• Pasos a seguir: Actividades que deben seguirse.

Desafíos de la Ingeniería de Software

• Heterogeneidad: Desarrollar software que funcione en diferentes plataformas y dispositivos.
• Entrega: Reducir los tiempos de entrega del software.
• Confianza: Desarrollar software confiable y seguro.

Responsabilidad Profesional

• Confidencialidad: Respetar la confidencialidad de la información del cliente.
• Capacidad: Asegurarse de tener las habilidades y conocimientos necesarios para realizar el trabajo.
• Derechos de propiedad intelectual: Respetar los derechos de autor y patentes.
• Mal uso de la computadora: Evitar el uso indebido de los sistemas informáticos.

¿Qué es un Sistema?

Un sistema es una colección intencionada de componentes interrelacionados que trabajan juntos para lograr objetivos comunes.

Categorías de Sistemas

• Sistemas técnico-informáticos: Incluyen hardware y software, pero no procesos ni políticas organizacionales.
• Sistemas socio-técnicos: Incluyen sistemas técnicos, procesos, personas y la organización en su conjunto.

El Proceso de Diseño del Sistema

1. Dividir requerimientos: Organizar los requerimientos en grupos afines.
2. Identificar subsistemas: Identificar un conjunto de subsistemas que cumplan con los requerimientos.
3. Asignar requerimientos a los subsistemas: Puede causar problemas al integrar COTS (Commercial Off-The-Shelf).
4. Especificar la funcionalidad de los subsistemas.
5. Definir las interfaces del subsistema: Actividad crítica para el desarrollo paralelo de subsistemas.

Factores Humanos y Organizativos

• Cambios en el proceso: Cómo se realiza el trabajo.
• Cambios de trabajo: Habilidades y tareas de los trabajadores.
• Cambios en la organización: Estructura y jerarquía organizacional.

Componentes de Sistemas Heredados

• Hardware
• Software de apoyo
• Software de aplicación
• Datos de aplicación
• Procesos de negocio
• Políticas de negocio y reglas

Modelo de Cascada – Fases

1. Análisis de requerimientos y definición
2. Diseño del sistema y del software
3. Ejecución y unidad de pruebas
4. Implementación y pruebas del sistema
5. Operación y mantenimiento

Desarrollo Evolutivo

• Desarrollo exploratorio: Se parte de una idea general y se va refinando a través de la experimentación.
• Prototipado desechable: Se crea un prototipo para comprender mejor los requerimientos y luego se desecha.

Ingeniería de Software Basada en Componentes – Fases

1. Análisis de componentes
2. Modificación de requerimientos
3. Diseño del sistema con reutilización
4. Desarrollo e integración

Sectores del Modelo en Espiral

• Fijación de objetivos
• Evaluación de riesgos y su reducción
• Planificación

Actividades del Proceso

• Especificación de software
• Diseño e implementación de software
• Validación de software
• Evolución del software

Especificación de Software

Proceso de ingeniería de requerimientos:

1. Estudio de viabilidad
2. Obtención y análisis de requerimientos
3. Especificación de los requerimientos
4. Validación de requerimientos

Actividades del Proceso de Diseño

• Diseño arquitectónico
• Especificación abstracta
• Diseño de la interfaz
• Diseño de componentes
• Diseño de estructura de datos
• Diseño de algoritmos

Métodos Estructurados

Posibles modelos:

• Modelo de objetos
• Modelo de secuencia
• Modelo de transición de estados
• Modelo estructural
• Modelo de flujo de datos

Buenas Prácticas en RUP

• Desarrollar software iterativamente
• Gestión de requerimientos
• Uso de arquitecturas basadas en componentes
• Modelos de software visuales
• Verificar la calidad del software
• Control de cambios al software

Clasificación CASE

• Perspectiva funcional
• Perspectiva de proceso
• Perspectiva de integración

Integración de Herramientas CASE

• Herramientas
• Bancos de trabajo
• Entornos

Actividades de Gestión

• Redacción de la propuesta
• Planificación y calendarización del proyecto
• Estimación de costes del proyecto
• Supervisión y revisión del proyecto
• Selección y evaluación del personal
• Redacción y presentación de informes

Tipos de Plan de Proyecto

• Plan de Calidad
• Plan de Validación
• Plan de Mantenimiento
• Plan de Desarrollo del Personal

El Proceso de Gestión de Riesgos

1. Identificación de riesgos
2. Análisis de riesgos
3. Planificación de riesgo
4. Supervisión de riesgos

Identificación de Riesgos

• Riesgos tecnológicos
• Riesgos de personal
• Riesgos organizacionales
• Riesgos de requerimientos
• Riesgos de estimación

Costos de un Proyecto

• Costos de esfuerzo (Meses-hombre)
• Costos de hardware y software, incluido el mantenimiento
• Costos de viajes y capacitación

Factores que Afectan la Fijación del Precio del Software

• Oportunidad de mercado
• Incertidumbre de estimación de costo
• Términos contractuales
• Volatilidad de requerimientos
• Salud financiera

Técnicas de Estimación

• Técnicas basadas en la experiencia
• Modelado algorítmico de costo

Métricas Orientadas al Tamaño

• Errores por KLOC (miles de líneas de código)
• Defectos por KLOC
• $ por KLOC
• Páginas de documentación por KLOC
• Errores por persona-mes
• KLOC por persona-mes
• $ por página de documentación

• A es un factor constante que depende de las prácticas locales de la organización y el tipo de software que se desarrolla.
• B se encuentra por lo general entre 1 y 1.5.
• M es un multiplicador que se integra al combinar atributos de procesos, producto y desarrollo, tales como los requerimientos de confiabilidad para el software y la experiencia del equipo de desarrollo.

Medición del Software

• Medidas directas del proceso: Costo y esfuerzo.
• Medidas directas del producto: LOC producidas, rapidez de ejecución, tamaño de memoria y defectos reportados (t).
• Medidas indirectas del producto: Funcionalidad, calidad, complejidad, eficiencia, confiabilidad, capacidad de mantenimiento, etc.

FAE= factor de ajuste de la estimación (0.9 –1.4)

Producto

• Fiabilidad requerida
• Tamaño de la BD
• Complejidad

Hardware

• Rendimiento
• Restricción memoria
• Volatilidad de la MV
• Tiempo de espera requerido

Personal

• Capacitación de los analistas
• Experiencia en aplicaciones
• Capacitación de los programadores
• Experiencia en MV
• Experiencias en el lenguaje de programación

Proyecto

• Prácticas modernas de programación
• Uso de herramientas para el desarrollo
• Limitaciones de la planificación

• PM es la estimación del esfuerzo en meses-hombre.
• NAP es el número de puntos de aplicación en el sistema entregado.
• % reutilización es una estimación de la cantidad de código de reutilización en el desarrollo.
• PROD es la productividad del punto de aplicación.

M = PERSx RCPXx RUSEx PDIFx PREXx FCILx SCED

• Habilidad personal (PERS)
• Fiabilidad y complejidad del producto (RCPX)
• Reutilización requerida (RUSE)
• Dificultad de plataforma (PDIF)
• Experiencia personal (PREX)
• Facilidades de soporte (FCIL)
• Calendario (SCED)

Preguntas

1. ¿El sistema requiere respaldo y recuperación confiables?
2. ¿Se requieren comunicaciones de datos especializadas para transferir información hacia o desde la aplicación?
3. ¿Existen funciones de procesamiento distribuidas?
4. ¿El desempeño es crucial?
5. ¿El sistema correrá en un entorno operativo existente enormemente utilizado?
6. ¿El sistema requiere entrada de datos en línea?
7. ¿La entrada de datos en línea requiere que la transacción de entrada se construya sobre múltiples pantallas u operaciones?
8. ¿Los archivos maestros se actualizan en línea?
9. ¿Las entradas, salidas, archivos o consultas son complejos?
10. ¿El procesamiento interno es complejo?
11. ¿El código se diseña para ser reutilizable?
12. ¿La conversión y la instalación se incluyen en el diseño?
13. ¿El sistema se diseña para instalaciones múltiples en diferentes organizaciones?
14. ¿La aplicación se diseña para facilitar el cambio y su uso por parte del usuario?