Bibliografía

Sistemas de Información
Tema 4: Ingeniería de Sistemas de
Información
Bibliografía
Análisis y Diseño de Aplicaciones Informáticas
de Gestión: Una Perspectiva de Ingeniería del
Software. M. Piattini, J.A. Calvo-Manzano, J.
Cervera, L. Fernández. Editorial Rama, 2003.
Fundamentos de Sistemas de Información. C.
Edwards, J. Ward, A. Bytheway. Prentice Hall, 2º
Edición, 2001.
Principios de Sistemas de Información. R.M.
Stair, G.W. Reynolds. Editorial Thomson, 4º Edición,
1999.
Sistemas de Información Gerencial. K.C. Laudon,
J.P. Laudon. Ed. Prentice Hall, 8º edición, 2004.
17/03/2010
Sistemas de Información
2
Contenido
4.1.
4.2.
4.3.
4.4.
4.5.
Ciclos de Vida del Software
Metodologías de Desarrollo de Software
Gestión de Proyectos Software
Análisis de Necesidades y Estudio de Viabilidad
Introducción a la Ingeniería de Requisitos
17/03/2010
Sistemas de Información
3
4.1. Ciclos de Vida del Software
4.1. Ciclos de Vida del Software
4.1.1.
4.1.2.
4.1.3.
4.1.4.
4.1.5.
17/03/2010
Introducción
Modelo en Cascada
Modelo Incremental
Modelo en Espiral
Modelo genérico para desarrollo de sistemas
orientados a objetos
Sistemas de Información
4
4.1.1. Introducción
Tradicionalmente el desarrollo de aplicaciones
informáticas se llevaba a cabo de forma
individualizada, a base de codificar (generar líneas
de código) y probar lo realizado cuanto antes.
Ventajas: desarrollo rápido
Desventajas:
¿que sucede si se detectan errores en etapas
tardías del desarrollo?.
No se realiza actividades de planificación, de
documentación, de aseguramiento de la calidad,
etc.
17/03/2010
Sistemas de Información
5
4.1.1. Introducción
Por lo tanto, es probable que las aplicaciones
realizadas según este enfoque de codificar y
probar:
Sean poco flexibles ante posibles modificaciones.
Sean incompletas o no reflejen bien las necesidades
del cliente.
Provoquen el descontento de los clientes (retrasos en
la entrega, aparición de errores una vez que la
aplicación ha sido entregada, etc.)
“Es necesario que todo esfuerzo en el desarrollo del software
conlleve un enfoque lógico para su realización que abarque toda
la vida del sistema, comenzando con su concepción y
finalizando cuando ya no se utiliza o se retira”
[SIGWART, 1990].
17/03/2010
Sistemas de Información
6
4.1.1. Introducción
El ciclo de vida software es la descripción de las
distintas formas de desarrollo de un proyecto o
aplicación informática.
Se define como el conjunto de fases o etapas, procesos
y actividades requeridas para ofertar, desarrollar,
probar, integrar, explotar y mantener un producto
software.
“Una aproximación lógica a la adquisición, el suministro, el desarrollo, la
explotación y el mantenimiento del software”
[IEEE 1074 - IEEE Standard for Developing Software Life Cycle Processes]
“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, abarcando la vida del sistema desde la definición de los requisitos
hasta la finalización de su uso”
[ISO 12207-1 - Software Life Cycle Processes]
17/03/2010
Sistemas de Información
7
4.1.1. Introducción
Las funciones principales de un ciclo de vida
software son:
Determinar el orden de las fases y procesos
involucrados en el desarrollo del software y su
evolución.
Establecer los criterios de transición para pasar de
una fase a la siguiente (productos intermedios).
El ciclo de vida que se seleccione en un proyecto
influirá en el éxito del proyecto.
17/03/2010
Sistemas de Información
8
4.1.2. Modelo en Cascada
Análisis
Requisitos
Sistema
Análisis
Requisitos
Software
Diseño
Preliminar
Diseño
Detallado
Codificación y
Pruebas
Explotación y
Mantenimiento
17/03/2010
Sistemas de Información
9
4.1.2. Modelo en Cascada
Características:
Cada fase empieza cuando se ha terminado la fase anterior.
Para pasar de una fase a otra es necesario conseguir todos los
objetivos de la etapa previa.
Ayuda a prevenir que se sobrepasen las fechas de entrega y
los costes esperados.
Al final de cada fase el personal técnico y los usuarios tienen la
oportunidad de revisar el progreso del proyecto.
Críticas:
No refleja realmente el proceso de desarrollo del software.
Se tarda mucho tiempo en pasar por todo el ciclo.
Perpetua el fracaso de la industria del software en su
comunicación con el usuario final.
El mantenimiento se realiza en el código fuente.
Las revisiones de proyectos de gran complejidad son muy
difíciles.
Impone una estructura de gestión de proyectos.
17/03/2010
Sistemas de Información
10
4.1.3. Modelo Incremental
Análisis
Requisitos
Sistema
Análisis
Requisitos
Software
Incremento 1
Diseño
Preliminar
Diseño
Detallado
Codificación y
Pruebas
Incremento 2
Explotación y
Mantenimiento
Diseño
Detallado
Codificación y
Pruebas
Explotación y
Mantenimiento
Incremento n
17/03/2010
Sistemas de Información
11
4.1.3. Modelo Incremental
Características:
Corrige la necesidad de una secuencia no lineal de pasos de
desarrollo.
Va creando el sistema software añadiendo componentes
funcionales al sistema (llamados incrementos).
El sistema software ya no se ve como una única entidad
monolítica, sino como una integración de resultados sucesivos
obtenidos después de cada iteración.
Se evitan proyectos largos y se entrega “algo de valor” a los
usuarios con cierta frecuencia.
Se ajusta a entornos de alta incertidumbre.
Críticas:
Persiste el problema de determinar si los requisitos propuestos
son válidos (los errores en los requisitos se detectan tarde y su
corrección resulta tan costosa como en el modelo en cascada).
Difícil de evaluar el coste total.
Difícil de aplicar a sistemas transaccionales que tienden a ser
integrados y a operar como un todo.
17/03/2010
Sistemas de Información
12
4.1.4. Modelo en Espiral
Determinar
objetivos,
alternativas,
restricciones
Evaluar alternativas,
identificar y resolver
los riesgos
Análisis
de Riesgos
Análisis
de Riesgos
Análisis
de Riesgos
Prototipo 3
Análisis de
Riesgos
Prototipo 1
Simulaciones, modelos, benchmarks
Plan de Requisitos
Plan del Ciclo de Vida
Planificar las
fases siguientes
Prototipo
Operativo
Prototipo 2
Concepto de
Operación
Plan de
Desarrollo
Validación de
Requisitos
Plan de
Integración
y Pruebas
V & V del
diseño
Implementación
Requisitos
Sw
Prueba de
aceptación
Diseño
Producto
Sw
Diseño
detallado
Código
Pruebas
unitarias
Integración
y prueba
Desarrolar, Verificar el
producto del siguiente nivel
17/03/2010
Sistemas de Información
13
4.1.4. Modelo en Espiral
Ejemplo: (Identificación)
Objetivos: una empresa que desea aumentar su
productividad en el desarrollo de software.
Alternativas: en el área de tecnología se podría reutilizar
software o utilizar ciertas herramientas, determinados
métodos que condujeran al desarrollo de mejores
productos.
Alternativas “no software”: en gestión (la organización de los
proyectos, la política de la empresa, la planificación y el control
de los proyectos, etc.), en personal (la incorporación de
plantilla, la promoción de incentivos, la formación, etc.) y en
soporte (comunicaciones entre el personal, lugares de trabajo,
etc.).
Restricciones: que el aumento de productividad fuera a un
coste razonable, que no se cambiase la cultura de la
empresa, etc.
17/03/2010
Sistemas de Información
14
4.1.4. Modelo en Espiral
Evaluar las diferentes alternativas que se plantean teniendo en
cuenta los objetivos a conseguir y las restricciones impuestas.
Formulación de una estrategia efectiva en coste (utilizando
prototipos, simulación, bancos de prueba, cuestionarios para los
usuarios, modelización analítica o combinaciones de éstas y otras
técnicas de resolución de riesgos) para resolver dichos riesgos.
Ejemplo: podría recurrirse a la realización de informes y análisis.
Revisar los resultados.
Ejemplo: se encuentra que las ganancias en productividad no serán
significativas y que además dichas mejoras no fueran compatibles con
la cultura de la empresa.
Ejemplo: podrían indicar la posibilidad de conseguir ganancias
significativas de productividad a un coste razonable persiguiendo un
conjunto integrado de iniciativas en las áreas de tecnología, gestión,
personal y soporte.
Planificar la fase posterior.
Ejemplo: se incluiría la necesidad de realizar informes y análisis más
profundos y, por lo tanto, de contar con más personal.
17/03/2010
Sistemas de Información
15
4.1.4. Modelo en Espiral
Características:
Cada ciclo se completa con una revisión en la que
participan las principales personas y organizaciones que
tienen relación con el producto.
Cada revisión incluye todos los productos desarrollados en
el ciclo anterior y el plan para el siguiente.
Los planes para las fases siguientes pueden incluir una
partición del producto en incrementos o componentes
(ciclos paralelos)
Principales diferencias respecto a otros métodos:
Reconocimiento explícito de las alternativas
Identificación de riesgos asociados a las alternativas
División del proyecto en ciclos.
Se adapta a cualquier tipo de actividad.
17/03/2010
Sistemas de Información
16
4.1.5. Modelo genérico para desarrollo de
sistemas orientados a objetos
Los modelos orientados a objetos caracterizan
el desarrollo orientado al objeto por:
La eliminación de fronteras entre fases, ya que
debido a la naturaleza iterativa del desarrollo
orientado al objeto, estas fronteras se difuminan
cada vez más.
Una nueva forma de concebir los lenguajes de
programación y su uso, ya que se incorporan
bibliotecas de clases y otros componentes
reutilizables.
Un alto grado de iteración y solapamiento, lo que
lleva a una forma de trabajo muy dinámica.
17/03/2010
Sistemas de Información
17
4.1.5. Modelo genérico para desarrollo de
sistemas orientados a objetos
Los expertos en tecnología de objetos
proponen seguir un desarrollo iterativo e
incremental.
Iterativo: Existe un ciclo de desarrollo análisisdiseño-implementación-análisis que permite
hacer evolucionar al sistema.
Incremental: el sistema se divide en un conjunto
de particiones.
Las actividades de validación, verificación y
aseguramiento de la calidad se pueden realizar
de forma continuada.
17/03/2010
Sistemas de Información
18
4.1.5. Modelo genérico para desarrollo de
sistemas orientados a objetos
Se pueden combinar los modelos
tradicionales de ciclo de vida con los más
modernos:
Idea del “microproceso” y del “macroproceso”
Microproceso: seguir cualquiera de los ciclos de
vida más modernos.
Macroproceso: seguir un modelo en cascada.
17/03/2010
Sistemas de Información
19
4.1. Ciclos de Vida del Software
Ejercicio:
¿Qué factores influyen a la hora de elegir un ciclo de vida para
resolver un problema dado?
¿Qué ciclo de vida elegiría para resolver un problema que se
comprende bien desde el principio y está muy estructurado?
Una vez elegido el ciclo de vida, ¿qué procesos escogería para
dicho ciclo de vida, teniendo en cuenta que el desarrollo
informático para resolver el problema anterior lo realiza una
única persona?
Se supone que se va desarrollar una aplicación relativa a la
gestión de pedidos de una empresa. En este caso el cliente no
tiene todavía muy claro qué es lo que quiere. Además el
personal informático va a utilizar una tecnología que le es
completamente nueva. Discútase qué tipo de ciclo de vida es
más apropiado y qué procesos se deberían utilizar para
desarrollar esta aplicación.
17/03/2010
Sistemas de Información
20
4.2. Metodologías de Desarrollo
de Software
4.2. Metodologías de Desarrollo de
Software
4.2.1. Introducción
4.2.2. Características de las principales metodologías
17/03/2010
Sistemas de Información
21
4.2.1. Introducción
Conceptos generales:
Metodología
Técnica
Herramienta
Tarea
Procedimiento
Producto
17/03/2010
Sistemas de Información
22
4.2.1. Introducción
Metodología:
Conjunto de pasos y procedimientos que debe seguirse
para el desarrollo de software.
“Conjunto de filosofías, fases, procedimientos, reglas, técnicas,
herramientas, documentación y aspectos de formación para los
desarrolladores de sistemas de información” [Maddison 1983].
Un conjunto de componentes que especifican:
Cómo se debe dividir un proyecto en etapas.
Qué tareas se llevan a cabo en cada etapa.
Qué salidas se producen y cuándo se deben producir.
Qué restricciones se aplican.
Qué herramientas se van a utilizar.
Cómo se gestiona y controla un proyecto.
Una metodología, por tanto, representa el camino para desarrollar
software de una manera sistemática.
17/03/2010
Sistemas de Información
23
4.2.1. Introducción
Metodología:
Objetivos:
Registrar los requisitos de un sistema de información de una
forma acertada.
Proporcionar un método sistemático de desarrollo.
Construir un sistema de información dentro de un tiempo
apropiado y unos costes aceptables.
Construir un sistema que esté bien documentado y que sea fácil
de mantener.
Ayudar a identificar cualquier cambio que sea necesario realizar
dentro del proceso de desarrollo.
Proporcionar un sistema que satisfaga a todas las personas
afectadas por el mismo.
Técnica:
Para aplicar un procedimiento se pueden utilizar una o más
técnicas.
Suelen ser gráficas con apoyos textuales formales
Determinan el formato de los productos resultantes de cada
tarea.
17/03/2010
Sistemas de Información
24
4.2.1. Introducción
Herramientas:
Para la realización de técnicas nos apoyamos en herramientas
software que automatizan su aplicación.
Ej. Herramientas CASE.
Pueden ser específicas de una metodología o de propósito más
general.
Tarea:
La descomposición del proceso se realiza hasta el nivel de tareas
o actividades elementales.
Procedimientos:
Para cada tarea se identifica un procedimiento que define la
forma de ejecutarla y es el vehículo de comunicación entre
usuarios y desarrolladores.
Productos:
Como resultado de seguir un procedimiento, se obtienen uno o
más productos
17/03/2010
Sistemas de Información
25
4.2.1. Introducción
Ejemplo:
Supongamos una metodología en la que hay una tarea que
define un procedimiento para construir un modelo conceptual de
datos. Para ello, se puede elegir la técnica de Chen. Además se
dispone de una herramienta que permite realizar y verificar el
diagrama, así como mantener su información de forma
consistente. Como resultado, se obtiene el modelo conceptual de
datos, que será un producto intermedio y servirá de base para
realizar el modelo lógico de datos.
Confusión entre los términos metodología, método y ciclo
de vida:
Una metodología puede seguir uno o varios modelos de
ciclo de vida.
Una metodología es un concepto más amplio que el de
método.
17/03/2010
Ej.: Métodos de programación estructurada.
Sistemas de Información
26
4.2.1. Introducción
Metodologías de desarrollo de
sistemas de información: Visión
histórica
Desarrollo convencional
Desarrollo estructurado
Desarrollo orientado a objetos
…
17/03/2010
Sistemas de Información
27
4.2.1. Introducción
Desarrollo Convencional
Problema inicial:
Las primeras aplicaciones se basaban en funciones básicas de
proceso de datos (copias, recuperaciones, ordenaciones, etc.)
Las personas que desarrollaban eran programadores
(codificación)
Falta de una fase de análisis previo.
Surge la importancia del análisis y el diseño en el desarrollo
de un sistema:
Se comienza a hablar de analistas-programadores, analistas
de sistemas.
Los analistas se dividían en dos tipos:
17/03/2010
Analistas funcionales (encargados del análisis de necesidades)
Analistas técnicos (encargado del diseño)
Sistemas de Información
28
4.2.1. Introducción
Desarrollo Convencional
Los resultados finales son impredecibles.
No hay forma de controlar lo que está
sucediendo en el proyecto.
Los cambios organizativos afectan
negativamente al proceso de desarrollo.
17/03/2010
Sistemas de Información
29
4.2.1. Introducción
Desarrollo Estructurado
De la construcción de programas de forma
artesanal métodos de ingeniería.
Sienta las bases para un desarrollo automatizado.
Técnicas dirigidas a aspectos técnicos y de gestión
en la construcción de software.
Surge a partir del concepto de programación
estructurada.
17/03/2010
Sistemas de Información
30
4.2.1. Introducción
Desarrollo Estructurado
Programación estructurada
El enfoque estructurado comenzó con la programación
Normas para la aplicación de las estructuras de datos y
de control
Diseño estructurado
El enfoque estructurado se extiende posteriormente a la
fase de diseño
Aparecen las primeras publicaciones sobre el diseño
(YOURDON y CONSTANTINE, 1975)
Se refina el concepto de modularidad (módulo de
programa, medidas en la calidad de los programas)
17/03/2010
Sistemas de Información
31
4.2.1. Introducción
Desarrollo Estructurado
Análisis estructurado
Inicialmente se hacía una especificación narrativa de
los requisitos, tal y como los percibía el analista.
Los primeros autores sobre el análisis estructurado
(GANE y SARSON, 1977; WEINBERG, 1978; DE
MARCO, 1979) identificaron problemas:
Eran monolíticas
Eran redundantes
Eran ambiguas
Imposibles de mantener
17/03/2010
Sistemas de Información
32
4.2.1. Introducción
Desarrollo Estructurado
Se advierte la importancia del análisis:
Si el análisis era erróneo, se realizaría una buena
solución a un problema equivocado
Especificaciones funcionales:
Gráficas
Particionadas
Mínimamente redundantes
Este enfoque, que se conoce como análisis estructurado (o
análisis descendente o “top-down”)
17/03/2010
Sistemas de Información
33
4.2.1. Introducción
Relación histórica de las principales metodologías estructuradas
AÑO
METODOLOGÍA
1968
Conceptos sobre la programación estructurada de DIJKSTRA, WARNIER y JACKSON
1974
Técnicas de programación estructurada de WARNIER y JACKSON
1975
Primeros conceptos sobre diseño estructurado de MYERS y YOURDON
1977
Primeros conceptos sobre análisis estructurado GANE y SARSON
1978
Análisis estructurado DEMARCO y WEINBERG
1981
SSADM (versión inicial)
Information Engineering (versión inicial)
1985
Análisis y Diseño estructurado para sistemas de tiempo real de WARD y MELLOR
1986
SSADM Versión 3
1987
Análisis y Diseño estructurado para sistemas de tiempo real de HATLEY y PIRHBAY
1989
MÉTRICA (versión inicial)
1990
SSADM Versión 4
1993
MÉTRICA Versión 2
1995
MÉTRICA Versión 2.1
2001
MÉTRICA Versión 3
17/03/2010
Sistemas de Información
34
4.2.1. Introducción
Desarrollo Orientado a Objeto
El paradigma orientado a objetos trata los procesos
y los datos de forma conjunta.
Surge con los lenguajes de programación
orientados a objetos.
Se da énfasis a la abstracción de datos (objetos de
datos).
Lenguajes de programación como Smalltalk, C++,
Java, etc. produjeron un gran interés para la
expansión del análisis y diseño orientado a objetos.
17/03/2010
Sistemas de Información
35
4.2.1. Introducción
Desarrollo Orientado a Objeto
UML (Unified Modeling Language) integración de
varios de los métodos de análisis y diseño
orientado a objetos (de Booch, Rumbaugh y
Jacobson). (1996)
En 1997 el Object Management Group (OMG) lo
adopta como estándar.
Metodología del Proceso Unificado (UP, Unified
Process) (1999):
Marco de procesos que guía las actividades para el
desarrollo de sistemas OO.
RUP (Rational Unified Process) (2000)
17/03/2010
Sistemas de Información
36
4.2.1. Introducción
Métodos Ágiles
“Desarrollo ágil” (Agile Development) metodologías
que denominan “ligeras”.
Buscan un equilibrio entre: procesos de desarrollo
muy “burocrático” y la inexistencia del mismo.
Ejemplos:
Método de Programación extrema (XP) o eXtreme
Programming
Dynamic System Development Method (DSDM).
Scrum
Cristal
Metodologías que puedan adaptarse al desarrollo ágil y
adaptar las reglas o buenas prácticas de los métodos de
desarrollo ágil (ej. RUP)
Herramientas RAD
17/03/2010
Sistemas de Información
37
4.2.1. Introducción
Ejercicio de análisis:
Análisis de metodologías ágiles
17/03/2010
Sistemas de Información
38
4.2.2. Características de las
principales metodologías
Entorno de desarrollo: conjunto de componentes
que condicionan la construcción de software.
El entorno de desarrollo afecta a la productividad.
La productividad debe estar asociada a la calidad
de los productos finales.
La metodología de desarrollo influye directamente
en estos dos factores.
17/03/2010
Sistemas de Información
39
4.2.2. Características de las
principales metodologías
ENTORNO DE DESARROLLO DE SOFTWARE
ORGANIZACION DE DESARROLLO DE SOFTWARE
EQUIPO DE DESARROLLO DE SOFTWARE
Dan una
estructura visible
Seleccionan las
herramientas
PROCEDIMIENTOS
DE GESTION
Da informes
a la dirección
Coordinan
y guían
METODOLOGIA
DE
DESARROLLO
soportan
métodos
SOPORTE
AUTOMATIZADO
TECNICAS
determinan
las herramientas
necesarias
17/03/2010
Sistemas de Información
40
4.2.2. Características de las
principales metodologías
Selección de entornos de desarrollo:
Combinaciones de métodos de gestión, técnicas de
desarrollo y soporte automatizado, para crear y
desarrollar la metodología de desarrollo software más
apropiada.
Analizar y evaluar las metodologías existentes y
adoptar la que más se ajuste a sus necesidades.
Influencia del tamaño, estructura de la organización,
y el tipo de aplicaciones que va a desarrollar.
17/03/2010
Sistemas de Información
41
4.2.2. Características de las
principales metodologías
Características deseables de una metodología:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Existencia de reglas predefinidas
Cobertura total del ciclo de desarrollo
Verificaciones intermedias
Enlace con procesos de gestión
Comunicación efectiva
Utilización sobre un abanico amplio de proyectos
Fácil formación
Herramientas
La metodología debe contener actividades que mejoren el
proceso de desarrollo
10. Soporte al mantenimiento
11. Soporte de la reutilización de software
17/03/2010
Sistemas de Información
42
4.3 Gestión de Proyectos Software
4.3. Gestión de Proyectos Software
4.3.1
4.3.2
4.3.3
4.3.4
17/03/2010
Planificación
Estimación de Costes y Plazos
Seguimiento y Supervisión del Proyecto Software
Gestión del Riesgo
Sistemas de Información
43
4.3 Gestión de Proyectos Software
Trabajo a través de proyectos:
Es la forma habitual de actuación en el desarrollo
de software.
Diferentes circunstancias para emprenderlo
Depende de una gestión apropiada para alcanzar
sus objetivos
Un proyecto es un conjunto de etapas,
actividades y tareas que tiene como finalidad
alcanzar un objetivo
17/03/2010
Sistemas de Información
44
4.3 Gestión de Proyectos Software
Un proyecto:
Implica un principio y un final.
Utiliza diversos recursos finitos y cuenta con un presupuesto.
Tiene actividades únicas y esencialmente no repetitivas.
Tiene un objetivo.
Requiere un jefe de proyecto y personal de desarrollo cuyos
roles y estructura de equipo deben definirse y desarrollarse.
Tiene que planificarse.
Debe medir su progreso frente al plan.
Suele coexistir con otros proyectos y competir por los
recursos.
Posee fuerzas internas y externas, que deben identificarse y
tratarse, que influyen en él.
La división en trabajos más sencillos es lo que permite al
personal del proyecto dominar la complejidad del proceso
para desarrollar el software.
17/03/2010
Sistemas de Información
45
4.3 Gestión de Proyectos Software
Ciclo de gestión de proyectos software
17/03/2010
Sistemas de Información
46
4.3 Gestión de Proyectos Software
Planificación
Implica: la realización de un plan de proyecto por parte del
jefe de proyecto y la gestión de compromisos.
Jefe de proyecto: persona que tiene la responsabilidad de
planificar, controlar y dirigir las actividades del proyecto.
El primer cometido del jefe de proyecto es la realización del
plan de proyecto.
Plan de proyecto: documento que describe los trabajos
que se van a realizar y la forma en que el jefe de proyecto
va a dirigir su desarrollo.
Define un conjunto de tareas (tiempos y recursos) con el
propósito de satisfacer los requisitos contractuales.
Debe ser preciso.
Implica una negociación y acuerdos de los compromisos de
esfuerzo, calidad y plazo que cada persona del equipo deberá
cumplir.
17/03/2010
Sistemas de Información
47
4.3 Gestión de Proyectos Software
Planificación
Para resultar útil, el plan de proyecto debería facilitar los
siguientes objetivos:
Proporcionar un resumen del proyecto a los
directivos.
Permitir supervisar el progreso del proyecto, desde el
inicio hasta el final (jefe y clientes).
Presentarse como un documento orientado al cliente.
Constituir un documento base del proyecto con la
aprobación del cliente y actualizable.
17/03/2010
Sistemas de Información
48
4.3 Gestión de Proyectos Software
Planificación
El contenido del plan de proyecto varía en cada proyecto, pero es
recomendable incluir, al menos, los siguientes elementos:
Un resumen del proyecto.
Una lista de los hitos alcanzables.
Los procedimientos y estándares que se van a aplicar.
Una especificación del proceso de revisión (quién, cómo y cuándo se
puede revisar la planificación del proyecto y con qué objeto).
Un plan que defina la comunicación entre la organización de desarrollo y
el cliente.
Un diagrama de descomposición del trabajo.
Una lista del personal del proyecto
Una red de actividades que muestre la secuencia de tareas en el tiempo y
su relación entre ellas.
Los responsables de todas y cada una de las actividades.
Los presupuestos de esfuerzo y dinero y los calendarios y plazos para
todas las actividades.
17/03/2010
Sistemas de Información
49
4.3 Gestión de Proyectos Software
Planificación
El contenido del plan de proyecto varía en cada proyecto, pero es
recomendable incluir, al menos, los siguientes elementos:
Un resumen del proyecto.
Una lista de los hitos alcanzables.
Los procedimientos y estándares que se van a aplicar.
Una especificación del proceso de revisión (quién, cómo y cuándo se
puede revisar la planificación del proyecto y con qué objeto).
Un plan que defina la comunicación entre la organización de desarrollo y
el cliente.
Un diagrama de descomposición del trabajo.
Una lista del personal del proyecto
Una red de actividades que muestre la secuencia de tareas en el tiempo y
su relación entre ellas.
Los responsables de todas y cada una de las actividades.
Los presupuestos de esfuerzo y dinero y los calendarios y plazos para
todas las actividades.
17/03/2010
Sistemas de Información
50
4.3 Gestión de Proyectos Software
Diagrama de descomposición del trabajo
00
Proyecto de
desarrollo X
J.L. Fernández
Nivel de Proyecto
10
20
30
40
S. Alonso
J.L. Fernández
Pruebas de
integración y del
sistema
V. Pérez
Desarrollo del
Software
Ingeniería del
Sistema
Gestión del
Proyecto
J. Gómez
Nivel de paquete de trabajo
21
12
11
Gestión del
Proyecto
J.L. Fernández
Plan de Proyecto
UT. 111
Gestión de
Configuración
31
Diseño del
Sistema
32
Análisis y
Diseño
41
33
Programación
Pruebas
42
Pruebas de
Integración
Pruebas de
Aceptación
G. Alfonso
G. Fuentes
T. Diez
S. Alonso
Control de
Configuración
UT. 121
Comunicaciones
UT. 211
Diseño Funcional
UT. 311
Programación
UT. 321
Procedimientos
de Pruebas
UT. 331
Procedimientos
de Pruebas
UT. 411
Procedimientos
de Pruebas
UT. 421
Construcción de
Software
UT. 122
Análisis de Requisitos
UT. 212
Diseño de
Algoritmos
UT. 312
Documentación
UT. 322
Pruebas Unitarias
UT. 332
Satisfacción
de Requisitos
UT. 422
Gestión de la
Base de Datos
UT. 213
Diseño de la
Base de Datos
UT. 313
Soporte a las
Pruebas
UT. 323
Análisis de las
Pruebas
UT. 333
Integración del
Sistema
UT. 412
Formación
UT. 413
A. Ramirez
P. Redondo
S. Sánchez
Arquitectura
UT. 214
Nivel de Unidad de Trabajo
4.3 Gestión de Proyectos Software
Planificación
Actividades para la planificación de un proyecto
Configuración del calendario del proyecto
Deber ser dinámico (variar a medida que avanza el proyecto si surgen
cambios no previstos en su extensión, sus plazos, etc.)
El control del proyecto se basa en la supervisión periódica y en la
comparación de los resultados con los previstos en el calendario.
Características del calendario:
Comprensible por todas aquellas personas que van a utilizarlo.
Suficientemente detallado.
Capaz de señalar las actividades críticas.
Flexible, fácilmente modificable.
Basado en estimaciones de tiempos fidedignas.
Ajustable a los recursos disponibles.
Compatible con los planes de otros proyectos que compartan los mismos
recursos.
17/03/2010
Sistemas de Información
52
4.3 Gestión de Proyectos Software
Planificación
Gestión de Compromisos
Objetivo: negociar, establecer y gestionar los
compromisos adquiridos por todas las partes
implicadas en el desarrollo de un proyecto.
Técnicas
Muestran la interrelación entre las actividades.
Ejemplos: Diagrama de Gantt, Diagrama de PERT
(análisis de precedencia).
17/03/2010
Sistemas de Información
53
4.3 Gestión de Proyectos Software
Unidades de tiempo
1
2
3
4
5
6
7
8
9
10
Tarea 1.1
Tarea 1.2
Tarea 1.3
Tarea 2.1
Ejemplo de Diagrama de Gantt
Tarea 2.2
Tarea 2.3
17/03/2010
Sistemas de Información
54
4.3 Gestión de Proyectos Software
A
D
B
E
C
Ejemplo de Diagrama de PERT
17/03/2010
Sistemas de Información
55
4.3 Gestión de Proyectos Software
Estimación de costes y plazos
La principal unidad de medición de coste del proyecto suele ser
el número de salarios mensuales o anuales que deben pagarse
(personas-mes o personas-año).
Las estimaciones suelen ser valoraciones con un cierto error
(por ejemplo, ± 20%).
La estimación en los proyectos de software tiene dificultades
particulares si la comparamos con la predicción en otras
industrias.
En otras es habitual producir el mismo tipo de producto una y otra
vez, con los mismos métodos.
La estimación es un proceso continuo:
A medida que se avanza en el proyecto, se obtiene una mayor
cantidad de detalles y de información más fiable
17/03/2010
Sistemas de Información
56
4.3 Gestión de Proyectos Software
Estimación de costes y plazos
Métodos de estimación de costes
1. La opinión de expertos
2. La estimación por analogía
3. La descomposición
4. Ecuaciones o modelos de estimación
17/03/2010
Sistemas de Información
57
4.3 Gestión de Proyectos Software
Seguimiento y supervisión del proyecto
El seguimiento y la supervisión del proyecto software implica
seguir, revisar y comparar los logros y los resultados
obtenidos, frente a las estimaciones, los compromisos y los
planes del proyecto, actualizándolos en función de estos
resultados.
Objetivos:
Comparar los resultados actuales con los planes previstos.
Tomar acciones correctivas cuando existan desviaciones
significativas de los planes previstos.
Acordar compromisos con el personal afectado por las acciones
correctivas.
“si no sabes donde estás, un mapa no te ayudará”
17/03/2010
Sistemas de Información
58
4.3 Gestión de Proyectos Software
Gestión de Riesgos
Riesgo: cualquier elemento potencial que provoca
resultados insatisfactorios en un proyecto.
Las áreas de riesgo que debe tratar un jefe de proyecto:
Riesgos estratégicos: cualquier tipo de riesgo relacionado con la
estrategia de la organización.
Riesgos comerciales: relacionados con la venta del proyecto, el
seguimiento del cliente, el precio y las posibles actualizaciones.
Riesgos contractuales y financieros.
Riesgos de gestión: relacionados con la organización de los
proyectos.
Riesgos de proyecto: causados por los aspectos técnicos del
software.
Riesgos de explotación.
Riesgos de mantenimiento.
17/03/2010
Sistemas de Información
59
4.4. Análisis de Necesidades y
Estudio de Viabilidad
“todos los proyectos son realizables ¡con recursos
ilimitados y un tiempo infinito!” [PRESSMAN, 2001]
Antes de proceder con un desarrollo debe evaluarse
su viabilidad
Aspectos que abarca:
Económico: ¿Vale la pena invertir en el proyecto?
Técnico: ¿Está disponible la tecnología necesaria para
el desarrollo? ¿Se puede utilizar en la organización?
Legal: si los requisitos atentan contra alguna ley o
reglamento.
Operativa: ¿Puede coordinarse con los métodos
existentes? ¿Encaja en la filosofía de la empresa y en
la cultura del personal? ¿El personal está motivado
para aceptarlo y explotarlo con la mayor eficiencia?
Plazos y calendario: ¿el plazo propuesto es realista?
17/03/2010
Sistemas de Información
60
4.4. Análisis de Necesidades y
Estudio de Viabilidad
Normalmente el análisis de viabilidad puede incluir las siguientes fases
[MAP, 2001]:
Estudiar la solicitud de proyecto, y establecer el alcance y los límites del sistema.
Estudiar la situación actual, describiendo y valorando los actuales sistemas de
información e identificando a usuarios y personas involucradas/afectadas por el
proyecto.
Realizar una definición preliminar de requisitos, catalogando y especificando los
mismos, así como las directrices técnicas o de gestión que puedan influir en el
proyecto.
Estudiar y especificar las diferentes alternativas de solución que se pueden
concebir. Por ejemplo:
Comprar un producto software comercial.
Desarrollar el producto internamente.
Desarrollarlo de forma externa mediante un contrato.
Automatizar sólo parcialmente el sistema para no tener que afrontar demasiados
gastos.
Evaluar cada una de las alternativas, incluyendo su viabilidad económica, técnica,
legal, operativa, etc. y su valoración en cuanto a beneficios, riesgos y
planificación.
Seleccionar y aprobar la alternativa más apropiada (tras la presentación de cada
una de ellas), lo que incluye, para la misma, fechas y compromisos de trabajo por
parte de las personas y departamentos implicados, es decir, definición de un plan
inicial del proyecto.
17/03/2010
Sistemas de Información
61
4.5. Introducción a la
Ingeniería de Requisitos
17/03/2010
Sistemas de Información
62
Introducción: Definición de
Requisitos
¿Qué son los Requisitos?
Describen los servicios que debe
proporcionar el sistema y sus
restricciones operativas.
Un requisito puede ser una simple declaración
abstracta de alto nivel o bien una definición
detallada y formal de una función del sistema.
Es necesario hacer una separación entre niveles
de descripción.
17/03/2010
Sistemas de Información
63
Introducción: Tipos de
Requisitos
Tipos de Requisitos
Requisitos del Usuario (descripción de
alto nivel)
Requisitos del Sistema (descripción
detallada)
Requisitos Funcionales
Requisitos No Funcionales:
Requisitos Del Producto
Requisitos Organizacionales
Requisitos Externos
De Dominio
17/03/2010
Sistemas de Información
64
Introducción: Tipos de
Requisitos
Requisitos del Usuario: descripciones, en
lenguaje natural o diagramas, de lo que se
espera que el sistema proporcione y las
restricciones bajo las cuales debe funcionar.
Requisitos del Sistema: establecen con detalle
las funciones, servicios y restricciones
operativas del sistema.
Deben ser precisos.
Definir exactamente qué es lo que se va a
implementar.
Puede ser parte del contrato entre el comprador
y el desarrollador.
17/03/2010
Sistemas de Información
65
Introducción: Tipos de
Requisitos
Ejemplo:
17/03/2010
Sistemas de Información
66
Introducción: Tipos de
Requisitos
Requisitos Funcionales:
Son declaraciones de los servicios que debe
proporcionar el sistema.
Especifica la manera en que éste debe
reaccionar a determinadas entradas.
Especifica cómo debe comportarse el sistema
en situaciones particulares.
Pueden declarar explícitamente lo que el
sistema no debe hacer.
17/03/2010
Sistemas de Información
67
Introducción: Tipos de
Requisitos
Ejemplo:
Requisitos Funcionales
17/03/2010
Sistemas de Información
68
Introducción: Tipos de
Requisitos
Requisitos No Funcionales:
No se refieren a funciones específicas que
proporciona el sistema.
Son restricciones de los servicios o funciones
ofrecidas por el sistema (fiabilidad, tiempo de
respuestas, capacidad de almacenamiento, etc.)
Generalmente se aplican al sistema en su
totalidad.
Surgen de las necesidades del usuario debido a
restricciones de presupuesto, políticas de la
organización, necesidad de interoperatividad,
etc.
17/03/2010
Sistemas de Información
69
Introducción: Tipos de
Requisitos
Requisitos No Funcionales:
Requisitos Del Producto:
Especifican el comportamiento del producto.
Ejemplos: rapidez de la ejecución, capacidad de memoria,
fiabilidad, etc.
Requisitos Organizacionales:
Derivan de políticas y procedimientos existentes en
la organización del cliente y del desarrollador.
Ejemplos: Estándares de procesos, métodos de diseño,
lenguajes de programación, métodos de entrega, etc.
Requisitos Externos:
Se derivan de factores externos al sistema y a su
proceso de desarrollo.
17/03/2010
Ejemplos: Requisitos de interoperatividad, legislativos,
éticos, etc.
Sistemas de Información
70
Introducción: Tipos de
Requisitos
Ejemplo:
Requisitos No Funcionales
17/03/2010
Sistemas de Información
71
Introducción: Tipos de
Requisitos
Requisitos De Dominio:
Provienen del dominio de aplicación del
sistema.
Reflejan características y restricciones del
dominio de la aplicación.
Pueden ser funcionales o no funcionales.
17/03/2010
Sistemas de Información
72
Introducción: Tipos de
Requisitos
Ejemplo:
Requisitos de Dominio
17/03/2010
Sistemas de Información
73
Introducción: Tipos de
Requisitos
Ejercicio de análisis:
17/03/2010
Sistemas de Información
74
Introducción: Definición de
Ingeniería de Requisitos
¿Qué es la Ingeniería de Requisitos?
Es el proceso para descubrir, analizar, documentar y
verificar los servicios que debe proporcionar el
sistema y sus restricciones.
Define un proceso.
Facilita la comprensión de lo que quiere el cliente.
17/03/2010
Analizando sus necesidades
Confirmando su viabilidad
Negociando la solución
Especificando la solución sin ambigüedad
Validando y Gestionando requisitos para que el sistema pueda ser
operativo.
Sistemas de Información
75
Proceso de Desarrollo de
Requisitos
Objetivo: Crear y mantener un documento de
requisitos del sistema.
Define el conjunto estructurado de actividades de
cuya ejecución se obtiene y mantiene la
especificación de los requisitos.
El proceso de desarrollo (ingeniería) de
requisitos comprende (en general) 4 etapas:
1.
2.
3.
4.
17/03/2010
Identificación o captura de requisitos
Análisis (y negociación) de requisitos
Especificación o documentación de requisitos
Validación de requisitos
Sistemas de Información
76
Proceso de Desarrollo de
Requisitos
17/03/2010
Sistemas de Información
77
Proceso de Desarrollo de
Requisitos
17/03/2010
Sistemas de Información
78
Proceso de Desarrollo de
Requisitos
Actores del proceso:
Stakeholders: persona o grupo que se verá
afectado por el sistema, directa o indirectamente.
Usuarios finales del sistema
Gerentes
Ingenieros de software
Encargados de mantenimiento de sistemas
relacionados
Reguladores externos
Expertos en el dominio
Representantes de trabajadores
Etc.
17/03/2010
Sistemas de Información
79
Proceso de Desarrollo de
Requisitos
Ejemplo: Stakeholders del sistema para un cajero automático
(ATM) de un banco
17/03/2010
Sistemas de Información
80
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Captura de requisitos:
En esta etapa los ingenieros de software trabajan
con los clientes y los usuarios finales del sistema.
Determinar:
17/03/2010
el dominio de la aplicación
qué servicios debe proporcionar el sistema
rendimiento requerido del sistema
restricciones de hardware
etc.
Sistemas de Información
81
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Análisis de requisitos:
Una vez recopilados los requisitos:
Se agrupan por categorías y se organizan
Se estudia cada requisito en relación con el resto
Se examina la consistencia, completitud y ambigüedad de los
requisitos
Se clasifican en base a las necesidades de los
clientes/usuarios.
Negociación de requisitos:
17/03/2010
Los clientes, usuarios y resto de los implicados deberán
clasificar sus requisitos y discutir posibles conflictos
Priorizar requisitos
Compromiso final sobre el conjunto de requisitos a
implementar
Sistemas de Información
82
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
La captura y análisis de requisitos es un
proceso complejo y de vital importancia.
Implica:
Comprender el dominio de la aplicación
Comprender el problema en cuestión
Comprender el contexto del negocio
Comprender las necesidades y restricciones de
los usuarios finales
17/03/2010
Sistemas de Información
83
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Problemas a la hora de hacer una captura de requisitos:
Problemas de Alcance:
Límites del sistema mal definidos
Detalles técnicos innecesarios proporcionados por los
clientes/usuarios
No están claros los objetivos del Sistema
Problemas de Comprensión:
Los clientes no están seguros de lo que necesitan
Los clientes no entienden totalmente el dominio del problema
Dificultades para comunicar las necesidades
Omisión de información por considerar que es obvia
Especificación de requisitos ambiguos, poco estables o
contradictorios
Problemas de volatilidad:
Los requisitos que cambian con el tiempo
17/03/2010
Sistemas de Información
84
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Para la recopilación y análisis de requisitos se
seguirán, en general, 5 pasos:
Identificar las fuentes de información y planificar
las actividades de investigación
Realizar las preguntas apropiadas (comprender
necesidades)
Analizar la información (detectar puntos no
claros)
Confirmar con los usuarios (lo que parece
haberse comprendido)
Sintetizar los requisitos (especificación de
requisitos)
17/03/2010
Sistemas de Información
85
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Principales técnicas de captura y análisis de
requisitos:
17/03/2010
Entrevistas
Desarrollo conjunto de aplicaciones (JAD)
Prototipado
Observación
Estudio de documentación
Cuestionarios
Tormenta de ideas (Brainstorming)
ETHIC
Sistemas de Información
86
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Entrevistas:
Cada tipo de entrevista requiere un
comportamiento y una preparación
distinta.
Existen dos elementos principales:
Entrevistador y Entrevistado
17/03/2010
87
Sistemas de Información
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
EL ENTREVISTADO PUEDE PRESENTAR:
EL ENTREVISTADOR DEBE POSEER:
PASIVIDAD, INHIBICION
☺ CIERTAS CUALIDADES PERSONALES
NO ACEPTACION
☺ CONOCIMIENTO DE TECNICAS
RECHAZO
☺ ACTITUD ADECUADA
AGRESIVIDAD
☺ EXPERIENCIA PRACTICA
Es importante la
forma en que se
plantea la
conversación y la
relación que se
establece
No basta con
hacer preguntas
“relación asimétrica, dinámica y única”
17/03/2010
Sistemas de Información
88
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Problemas de Comunicación:
DISCREPANCIA DE OBJETIVOS
BARRERAS DE COMUNICACION
MANTENIMIENTO DE LA MOTIVACION
17/03/2010
Sistemas de Información
89
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Barreras de la Comunicación:
OIR LO QUE QUEREMOS
PASAR POR ALTO IDEAS CONTRARIAS
DIFERENTE SIGNIFICADO DE LAS PALABRAS
COMUNICACION NO VERBAL
EMOCIONES
RUIDO
DISTANCIA
Eliminación de Barreras:
ADAPTARSE AL MUNDO DEL RECEPTOR
UTILIZAR EL DIALOGO
SERVIRSE DE LA COMUNICACION DIRECTA
INSISTIR (VARIAS VECES)
UTILIZAR LENGUAJE SENCILLO Y DIRECTO
UTILIZAR VIAS DISTINTAS
REDUCIR LAS DISTANCIAS
17/03/2010
Sistemas de Información
90
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Factores a Considerar:
COMUNICACION NO VERBAL
PROXIMIDAD FISICA
ORIENTACION
POSTURA
ADEMANES
CABEZA
EXPRESION FACIAL
OJOS
APARIENCIA
ASPECTOS DEL LENGUAJE
ESCUCHAR Y RESPONDER
VOCABULARIO
EXPRESION VERBAL
17/03/2010
Sistemas de Información
91
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Cualidades del Entrevistador:
Saber observar y escuchar (escucha activa)
Poseer madurez
Ser objetivo e imparcial
No ser autoritario
Capacidad de “empatía”
Comprensión
Ser cordial y accesible
Respetar la intimidad
Ser sincero, paciente, sereno
Ser prudente
17/03/2010
Sistemas de Información
92
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Fases de la Entrevista:
Preparación
Realización y Conducción
Análisis
17/03/2010
Sistemas de Información
93
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Preparación de la Entrevista:
Investigar la situación
Identificar los entrevistados
Preparar el objetivo y el contenido
Planificar lugar y hora
17/03/2010
Sistemas de Información
94
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Realización de la Entrevista:
Etapas:
Apertura (establecer un ambiente confortable)
Desarrollo
Técnicas Directivas: preguntas abiertas,
preguntas directas, preguntas cerradas,
sondeo.
Técnicas No Directivas: pausa, asentir,
reflejar ideas, resumir.
Término (resumir, agradecer, establecer nuevas
citas)
17/03/2010
Sistemas de Información
95
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Análisis de la Entrevista:
Es la fase más descuidada
Requiere:
Pasar notas a limpio
Reorganizar la información
Contrastar la información con otras
entrevistas o fuentes
Evaluar cómo ha ido la entrevista.
17/03/2010
Sistemas de Información
96
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Desarrollo Conjunto de Aplicaciones (JAD):
Es una técnica para promover la cooperación y el
trabajo en equipo entre usuarios y analistas.
Razones para realizar:
17/03/2010
Dinero gastado en preparación y realización de
entrevistas.
Todo el grupo puede actuar como revisor y
detectar defectos.
Propugna una participación más profunda de los
usuarios en el proyecto.
Sistemas de Información
97
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Fases de un JAD:
Adaptación o preparación:
Selección de los participantes
Recabar una cierta información
Organizar la reunión
Sesión JAD
Documentación
17/03/2010
Sistemas de Información
98
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Prototipado:
Consiste en la elaboración de un modelo o
maqueta del sistema.
Se construye para evaluar mejor los
requisitos que desea que cumpla.
Es útil cuando:
17/03/2010
El área de aplicación no está bien definida.
El coste de rechazo de la aplicación es muy
alto.
Es necesario evaluar previamente el impacto
del sistema en los usuarios y en la
organización.
Sistemas de Información
99
Proceso de Desarrollo de Requisitos:
Captura, Análisis y Negociación de requisitos
Tipos principales de prototipos:
Prototipado de la interfaz de usuario
Modelos de Rendimiento
Prototipado funcional
17/03/2010
Sistemas de Información
100
Sistemas de Información
Tema 4: Ingeniería de Sistemas de
Información