Conceptos
 Producto Software = programas + documentación +
configuración de datos asociados.
 Ingeniería SW = disciplina de ingeniería (uso
apropiado de todas las herramientas, métodos y
teorías) encargada de todos los aspectos relacionados
con la producción de software
Conceptos
 Proceso SW = conjunto de actividades y resultados
para producir un producto SW

Especificación + Desarrollo + Validación + Evolución software
 Modelo de proceso SW = descripción simplificada de
un proceso software (Modelo en
incremental, prototipos, en espiral…)
cascada,
Conceptos
 Ciclo de vida
 Tarea: Acción que transforma E en S
 Actividades: Conjunto de tareas
 Procesos: Conjunto de actividades para la producción de
software
 Ciclo de desarrollo
 Análisis <-> Entrega
Conceptos
 Modelo de ciclo de vida
 Marco de referencia que contiene los procesos, actividades y
las tareas del desarrollo, la explotación y el mantenimiento del
software, desde la definición hasta el fin de su uso.
Conceptos
 Procesos del ciclo de vida:
 procesos principales Desarrollo (Análisis, diseño, codificación,
integración, pruebas, instalación y soporte)
 procesos de soporte  gestión de la configuración
 procesos de organizaciónGestión y planificación del proyecto
Ingeniería de Sistemas
 Se centra en SW + otros elementos
 Integrar SW en un sistema: producto, servicio o
tecnología de transformación o control de
información
 Producto obtenido: una correcta representación del
sistema
Ingeniería de Sistemas
 Ing. de la información (procesos de negocio)
 Marco de trabajo se centra en la empresa
 Ingeniería de producto
 Para la construcción de un producto
 Jerarquía de ingeniería de sistemas



Modelado del sistema
Ingeniería de la información
Ingeniería de producto
Jerarquía de la Ing. Sistemas
Jerarquía - Modelado del sistema
 Ingeniería de sistemas es un proceso de modelado
 Se crean modelos que:
 Definan los procesos que satisfagan necesidades
 Representen comportamiento de los procesos y los Supuestos
 Representen todas las uniones (incluidas las salidas)
Jerarquía - Modelado del sistema
 Restricciones del modelo de sistema:
 Supuestos
 Simplificaciones – Generalizar
 Limitaciones - Tamaño BBDD
 Restricciones
 Preferencias
Jerarquía - Ingeniería de la información
 Objetivo
 Definir arquitecturas que permitan emplear eficazmente la
información
Arquitectura de datos y aplicaciones
 Infraestructura de la tecnología

Jerarquía - Ingeniería de la información
 Arquitectura de datos
 Estructura para las necesidades de información
 Arquitectura de aplicaciones
 Elementos del sistema que transforma los datos
 Infraestructura de la tecnología
 Fundamento para las arquitecturas anteriores
Jerarquía - Ingeniería de la información
Jerarquía - Ingeniería de productos
 Objetivo
 Definir
arquitectura e infraestructuras que
transformar el deseo de un cliente en un producto
Arquitectura: Componentes sw, hw, datos y personas
 Infraestructura de soporte

permitan
Jerarquía - Ingeniería de productos
Ingeniería de la información
 Dónde debe comenzar
 Análisis de objetivos y metas de negocio
 Definición de necesidades de información de cada área de
negocio y también global
 Dónde seguir
 En el proceso -> Análisis, diseño y construcción
Ingeniería de la información
 Modelado de la empresa
 Modelado de datos al nivel de negocio
 Modelado del proceso
 Modelado del flujo de información
Ingeniería de productos
 Análisis del sistema
 Identificación de necesidades
 Estudio de la viabilidad y análisis de riesgos
 Análisis económico y técnico
Modelado de la arquitectura
 Arquitectura básica: ENT/PRO/SAL
 Ampliada
 Entrada, proceso, salida + Interfaz de usuario y proceso de
mantenimiento
 Asignar elementos a cada una de las cinco regiones
 Crear un jerarquía en detalle: Diagrama de contexto
más alto nivel
Modelado y simulación
 Modelo para simular el comportamiento y
rendimiento -> Especificar el sistema
 Herramientas CASE son de gran ayuda
Especificación del sistema
 Documento base
 Describe la función, rendimiento y restricciones
 Información (datos y control) de E/S del sistema
Planificación de Proyectos
 Objetivo: estimación tiempo, costo y riesgo
 Valores más importantes a tener en cuenta: tiempo, esfuerzo,
personas, recursos HW y SW y riesgo.
 Difícil pero no Imposible.
 Puede hacerse bien, aunque no es una ciencia exacta.
Planificación de Proyectos
 ¿Cómo se hace? Pasos:
 1. Definir ámbito.
 2. Descomponer el problema en subproblemas más pequeños.
 3. Hacer la estimación para cada subproblema a partir de:



Datos históricos.
Experiencia.
4. Revisar estimación considerando:


Complejidad del problema.
Riesgos.
Planificación de Proyectos
 Observaciones para la estimación
 Complejidad del proyecto: Experiencia en proyectos
semejantes.
 Tamaño: Crece la interdependencia.
 Incertidumbre estructural: Grado definición requisitos,
compartimentar funciones, información a procesar.
 Disponibilidad información histórica.
Planificación de Proyectos
 Puntos clave en la planificación
 a) Ámbito
 Funcionamiento habitual
 Funciones importantes
 Rendimiento y restricciones
 Fiabilidad
 Interfaz con otros sistemas.
Planificación de Proyectos
 Puntos clave en la planificación
 b) Estimación de los Recursos
Planificación de Proyectos
 Puntos clave en la planificación
 Especificación de los recursos
Descripción del recurso
 Informe de disponibilidad
 Fecha cronológica en la que se requiere
 Tiempo de aplicación del recurso.

Planificación de Proyectos
 Puntos clave en la planificación
 Recursos humanos
Posición en la organización
 Experto, senior, junior.
 Especialidad
 Bases de datos, telecomunicaciones

Planificación de Proyectos
 Puntos clave en la planificación
 Recursos de SW reutilizables




Componentes ya desarrollados
Componentes ya experimentados
Componentes con experiencia parcial
 NO RECOMENDABLE
Componentes nuevos
Planificación de Proyectos
 Puntos clave en la planificación
 Recursos de entorno
Entorno de desarrollo - ¿Compartir con otros proyectos?
 Hw y SW donde se va a desarrollar
 Entorno de destino
 Hw y SW donde se va a ejecutar

Conceptos de análisis
 Análisis de Requisitos
 Especificación de la función, datos y rendimiento del SW
 Interfaz con otros elementos
 Restricciones que debe cumplir el SW
 Proporciona modelos para:
Diseño de datos
 Diseño de la arquitectura
 Diseño de la interfaz
 Diseño procedimental
 o VALORAR LA CALIDAD

Conceptos de análisis
 Áreas de esfuerzo:
 Reconocimiento del problema
 Evaluación y síntesis
 Modelado
 Especificación del SW
 Revisión
Conceptos de análisis
 Técnicas de comunicación
 Comunicación <> Entendimiento
 Empezar con una entrevista:



¿Quién utilizará el sistema?
Objetivos del sistema
Beneficios de esta solución
Conceptos de análisis
 Técnicas de comunicación
 Centrarse en entender el problema
Conocer el entorno donde se va a utilizar
 Restricciones o mejoras sobre la situación actual


Conocer totalmente el problema



¿Hay más personas que darían información?
¿Existen dudas por parte del cliente?
¿Se debe preguntar más?
Conceptos de análisis
 Técnicas de comunicación
 Técnicas para facilitar la especificación




Objetivo: identificar el problema
 ÚNICO EQUIPO DE TRABAJO (Cliente y empresa)
Redactar solicitud de producto
Listas de datos, funciones, relaciones con otros sistemas
Lista de restricciones y rendimiento
Conceptos de análisis
 Función de la calidad
 Traducir las necesidades del cliente en requisitos
Requisitos normales
 Requisitos esperados (implícitos)
 Requisitos innovadores

Principios del Análisis
 Principios operativos:
1.
Entender dominio de información
2.
Definición de funciones
3.
Representar el comportamiento (eventos externos)
4.
Modelos para la información, función y comportamiento.
Descomposición jerárquica.
5.
Desde la información esencial hasta el detalle de
implementación.
Principios del Análisis
 Otros principios:
 Entender el problema antes de empezar con el modelo
 Desarrollar prototipos
 Registrar origen y razón de cada Requisito
 Modelos de datos, funcionales y de comportamiento
(diferentes puntos de vista)
 Dar prioridad a los requisitos
 Trabajar para eliminar la ambigüedad (RTF)
Principios de la especificación
 Separar funcionalidad e implementación
 Desarrollar modelo de comportamiento (datos y




respuestas funcionales)
Establecer contexto (interacción con otros sistemas
externos)
Especificación
Crear un modelo intuitivo, no diseño ni modelo de
implementación
Establecer contenido y estructura de especificación
que acepte cambios
Especificación de requisitos del SW
 CULMINACIÓN DEL ANÁLISIS
 Estructura del documento:
 Introducción - Metas y objetivos del SW; contexto
 Descripción de la información – Descripción del problema a
resolver: Información y sus relaciones, flujo y estructura.
Interfaces HW, SW y humanas
 Descripción funcional - Descripción del proceso de cada
función requerida para resolver el problema
 Descripción del comportamiento – Cómo reacciona el SW
ante acontecimientos externos
 Criterios de validación - Revisión de todos los requisitos
Descargar

Diapositiva 1 - Jose Luis Bravo