INGENIARITZA GOI ESKOLA TEKNIKOA

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA

BILBAO

[ANTE]PROYECTO
DE

Proyectos de Ingeniería del Software

[Documento nº # - DOCUMENTO]

Alumno Apellido1 Apellido2, Nombre

Fecha Mes de 20##
Firma

Profesor Cátedra Profesor Ponente Referencia Curso Académico

Sr. Apellido(s) Sr. Apellido(s) I[I,A,O,...].O.0#.##.C[.C] 20##/20##
 ii

ÍNDICE

pág.

1. CONCEPTOS GENERALES.......................................................................1

2. DESGLOSE DEL TRABAJO.......................................................................2

3. FASES DE UN PROYECTO........................................................................3
3.1 Las fases del ciclo de Desarrollo del Software.....................6
3.1.1 Fase de Concepto...................................................6
3.1.2 Fase de Especificación y Diseño del sistema........6
3.1.3 Fase de Especificación de Requisitos del software
...........................................................................7
3.1.4 Fase de Diseño de la Arquitectura del software.....7
3.1.5 Fase de Diseño Detallado del software..................7
3.1.6 Fase de Codificación del software..........................7
3.1.7 Fase de Pruebas Unitarias del software.................8
3.1.8 Fase de Integración del software............................8
3.1.9 Fase de Validación del software.............................8
3.1.10 Fase de Integración del sistema...........................9
3.1.11 Fase de Validación y Aceptación del sistema......9
3.1.12 Fase de Mantenimiento........................................9

4. DOCUMENTOS DE UN PROYECTO: CONTENIDOS.............................10

4.1 Documento nº 1: MEMORIA...............................................10
4.2 Documento nº 2: CÁLCULOS.............................................12
4.3 Documento nº 3: DISEÑO..................................................12
4.4 Documento nº 4: PRESUPUESTO.....................................14
4.5 Documento nº 5: PLIEGO DE CONDICIONES..................14
4.6 ANEXO #: MANUAL DE USUARIO....................................16

5. DIAGRAMA DE GANTT............................................................................17

6. TABLA DE PRESUPUESTO (Anteproyecto)..........................................18

 1

1. CONCEPTOS GENERALES

Un proyecto de realización de un producto de software no difiere, ni debe

diferir, en sus partes de un proyecto cualquiera de ingeniería.

Un proyecto siempre pasa por las fases de:

• Análisis
• Diseño
• Ejecución (implementación)
• Pruebas
• Entrega
• Mantenimiento

En un proyecto de Software la duración de las fases en el total del desarrollo

del proyecto, desde su inicio, pasando por su ejecución, pruebas y entrega
al cliente (excluyendo el mantenimiento), puede estimarse en:

• 40% Análisis y Diseño

• 20% Implementación
• 40% Pruebas
 2

2. DESGLOSE DEL TRABAJO

• Cada actividad ha de ser descompuesta en tareas.

La tarea es la unidad elemental de control y produce resultados
concretos.
• Se ha de procurar que la duración de una tarea no sea superior a 10 días
laborables (preferiblemente 5 días laborables), excepto en casos de
imposibilidad manifiesta por la complejidad de la misma.
• Un miembro del equipo de trabajo no debe tener en curso más de 2
tareas simultáneamente.
• Cada tarea se asignará normalmente a un miembro del equipo. Sin
embargo, ciertas tareas pueden ser asignadas a varios miembros del
equipo.
• No olvidar las tareas de supervisión, formación, reuniones, redacción de
informes y documentación, dejando un "colchón" para posibles desfases.

Especial atención a las tareas "cuello de botella":

• Aprobación de etapas y puntos de control.

• Instalación de equipos.
• Reuniones decisorias.
• Formación.
 3

3. FASES DE UN PROYECTO

Las fases y subfases de un proyecto de software son las siguientes:

1. Análisis.

1.1 Planificación.

Entender el problema del cliente, realizar un estudio de viabilidad,

recomendar una solución, determinar los criterios de aceptación y planificar
el desarrollo.

1.2 Especificación de los requisitos/necesidades del software.

Consiste en identificar las funciones básicas del software en el sistema

hardware/software/usuario. Se hace énfasis en qué funciones se esperan
que el software haga y bajo que restricciones las realizará. En la fase de
diseño se decidirá como se implementa e software.

2. Diseño.

2.1 Diseño de la arquitectura.

2.2 Diseño detallado.

3. Implementación.
3.1 Codificación.
3.2 Depuración (“debugging”).
3.3 Pruebas de módulos.

4. Pruebas del sistema.

4.1 Integración de módulos.

4.2 Pruebas de aceptación.

5. Mantenimiento.

5.1 Mejoras.
5.2 Adaptación.
5.3 Corrección de errores.
 4

El orden de desarrollo cronológico de estas fases y subfases es el que

aparece en la tabla siguiente:

Documentos Revisiones Firma

1. Definición del Viabilidad del producto
sistema
Plan del proyecto
2. Manual de usuario
(inicial)
3. Especificación de
necesidades del
software
4. Plan inicial de
validación del
software
5. Requisitos del software Cliente y nosotros
6. Especificación del
diseño del software
Arquitectura
Detalle
7. Diseño inicial Director proyecto
8. Diseño Director proyecto
9. Plan de verificación
completo
10. Plan de aceptación Verificación del
inicial software
11. Implementación
12. Código fuente
13. Inspecciones de
resultados de trabajo
14. Manual de usuario
Plan de instalación
Plan de formación
Plan de
mantenimiento
15. Resumen de Aceptación Cliente y nosotros
verificación de
software
16. Memoria del
proyecto
 5

FASES PRELIMINARES FASES POSTERIORES

CICLO DE
ESPECIFICACION
DESARROLLO VALIDACION

SOFTWARE
DISEÑO DE
INTEGRACION
ARQUITECTURA

DISEÑO PRUEBAS
DETALLADO UNITARIAS

CODIFICACION

Fig. 1.1: Fases del Ciclo de Desarrollo del Software

Fases DESARROLLO Fases

Preliminares Posteriores

CICLO DE
Especificación DESARROLLO Validación
SOFTWARE
GESTIÓN DEL Diseño de GESTIÓN DE LA
Integración
PROYECTO Arquitectura CONFIGURACIÓN
Diseño Pruebas
Detallado Unitarias

Codificación

ASEGURAMIENTO Y CONTROL
DE LA CALIDAD

Fig. 2.2: Interrelación entre las actividades que intervienen en un proyecto

de software.
 6

3.1 Las fases del ciclo de Desarrollo del Software

Este capítulo pretende describir brevemente las diferentes fases que

componen el ciclo de Desarrollo del Software, que son comunes tanto para
un proyecto con sólo componente software como para un proyecto con otros
componentes además del software (sistema).

A pesar de que el objetivo principal es la definición de las fases del ciclo de

Desarrollo del Software, se ha decidido añadir las fases que completan el
ciclo de vida del sistema porque se considera que esto contribuye a entender
mejor y a encuadrar las fases del ciclo de Desarrollo del Software en el caso
más general.

3.1.1 Fase de Concepto

La fase de Concepto es una etapa preliminar que precede a la de

Especificación y Diseño del Sistema (en el caso que el software forme parte
de un sistema) o a la fase de Especificación de Requisitos del software (en
el caso de un Proyecto sólo de software), siempre que no exista un
documento que describa el trabajo técnico a realizar.

El objetivo de esta fase es realizar un Estudio de Viabilidad (Project

Feasibility Study, PFS) que permita tomar la decisión correcta respecto al
lanzamiento de un proyecto.

3.1.2 Fase de Especificación y Diseño del sistema

Se inicia al decidir el desarrollo de un sistema, tras concluir la descripción

del trabajo a realizar definido en la fase de Concepto.

El objetivo de esta fase es analizar y definir los requisitos que debe cumplir
el sistema, realizar una descomposición del sistema en los componentes
que lo integran, planificar los tiempos estimados para cada uno de esos
componentes y planificar la integración total del sistema.

Esta fase no existe si el proyecto sólo está constituido por software.

 7

3.1.3 Fase de Especificación de Requisitos del software

La fase de Especificación de Requisitos del software es fundamental para el

flujo apropiado de las siguientes fases de desarrollo. Dichas fases se
llevarán a cabo de acuerdo con la organización y planificación decididas
durante esta fase.

El objetivo de esta fase es analizar y especificar los requisitos que debe

cumplir el software, de modo que cubra todas las especificaciones
expresadas por el cliente. Todas las especificaciones se recogen en el
Documento de Especificación de Requisitos (Requirements Specification
Document, RSD).

3.1.4 Fase de Diseño de la Arquitectura del software

Esta fase sucede a la de Especificación de Requisitos del software. Una vez

realizada la especificación de los requisitos que debe cumplir el software se
debe diseñar una arquitectura preliminar del software que se adapte a esos
requisitos. Se definirán las funciones que debe realizar el software, su
descomposición en módulos funcionales, la descripción de los interfaces
entre módulos, etc. Esta descripción se recoge en el Documento de Diseño
de Arquitectura (Architectural Design Document, ADD).

3.1.5 Fase de Diseño Detallado del software

En esta fase se profundiza o detalla el diseño que se comenzó en la fase

anterior. Se detalla cada uno de los módulos que se definió en la fase
anterior a un nivel suficiente que permita su codificación sin ningún
problema, es decir, sin ninguna ambigüedad. El diseño detallado del
software se recoge en el Documento de Diseño Detallado (Detailed Design
Document, DDD).

3.1.6 Fase de Codificación del software

En esta fase se traducen los diseños detallados que se crearon en la fase

anterior al lenguaje de programación elegido para el proyecto. El resultado
 8

de esta fase debe ser el código fuente que constituye el software del
proyecto.

3.1.7 Fase de Pruebas Unitarias del software

Durante esta fase se ejecutan las pruebas unitarias de los componentes

software de más bajo nivel (funciones) para comprobar que responden a su
definición, especificada en la fase de Diseño Detallado. Se recogerán y
archivarán los resultados de estas pruebas y se corregirán aquellos
componentes no correctos.

3.1.8 Fase de Integración del software

Una vez probados los elementos individuales que constituyen el software se

trata de ensamblar esos elementos y probar ese conjunto ensamblado. El
software se ensambla o integra progresivamente de acuerdo a un plan de
pruebas establecido de forma que el objetivo final es probar los módulos (su
funcionalidad y la interrelación entre ellos) de forma que se verifiquen las
especificaciones definidas en el Documento de Diseño de la Arquitectura
(ADD).

3.1.9 Fase de Validación del software

Una vez realizada la integración de todo el software se somete a todo el

conjunto a una serie de pruebas con el propósito de verificar que el software
desarrollado realmente cumple con los requisitos especificados en el
Documento de Especificación de Requisitos (RSD) del software, es decir, no
es suficiente saber que el software funciona sino que además hay que
verificar que lo que hace es lo que el cliente esperaba del software. Para
obtener la Validación se ejecutarán las pruebas descritas en el Plan de
Pruebas de Validación (Validation Test Plan, VTP).

La elaboración del Plan de Pruebas de Validación (VTP) del software

comienza en la fase de Especificación de Requisitos del software con la
escritura de un primer borrador, y se va completando en las siguientes fases
 9

del ciclo de Desarrollo hasta llegar al comienzo de esta fase. Al comienzo de

esta fase el Plan debe estar completamente terminado.

En el caso de ser ésta la última fase del proyecto (el software no forma parte
de un sistema) habría que realizar también las pruebas externamente, es
decir, con el cliente enfrente para que realice su aceptación (la fase de
Validación del software se transformaría en fase de Validación y Aceptación
del software).

3.1.10 Fase de Integración del sistema

La fase de integración del sistema pretende ensamblar los subsistemas

"hardware" y "software" que constituyen todo el sistema, y demostrar que
este sistema cumple las especificaciones que se recogen en el Documento
de Especificación y Diseño del sistema. La integración se produce de forma
gradual de acuerdo al plan de integración del sistema.

3.1.11 Fase de Validación y Aceptación del sistema

La fase de Validación y Aceptación del sistema es la última fase de

producción del sistema y su objetivo es verificar que el sistema desarrollado
está conforme respecto a los requisitos que se recogen en el Documento de
Especificación y Diseño del sistema. Para obtener la Validación y
Aceptación del sistema se ejecutarán un conjunto de pruebas que se
describen en el Plan de Pruebas de Validación y Aceptación del sistema.

3.1.12 Fase de Mantenimiento

La fase de Mantenimiento empieza tras la aceptación del sistema por parte

del cliente y coincide con el inicio de la garantía. Durante esta fase de
Mantenimiento se realizarán las correcciones necesarias para lograr el
funcionamiento deseado del sistema/software de acuerdo a las
especificaciones. El mantenimiento del sistema/software requiere la firma de
un plan de mantenimiento por parte del cliente.
 10

4. DOCUMENTOS DE UN PROYECTO:
CONTENIDOS

Los documentos a presentar en el proyecto son los siguientes:

Documento nº 1: MEMORIA
Documento nº 2: CÁLCULOS (cuando los haya)
Documento nº 3: DISEÑO
Documento nº 4: PRESUPUESTO
Documento nº 5: PLIEGO DE CONDICIONES
ANEXO 1: CASOS DE PRUEBA
…
ANEXO #: MANUAL DE USUARIO
…
Los números de los documentos serán consecutivos, empezando por el
número 1, de forma que si un documento no existe no se mantendrá el
número indicado.

4.1 Documento nº 1: MEMORIA

Resumen
1. INTRODUCCIÓN
Estado actual.
Situar el problema.
Suscitar la necesidad.
2. OBJETIVOS
El objetivo es “título” (si éste está bien puesto).
Funciones/Funcionalidades
Características
Entorno (Situación, Hardware/Software, …)
Usuario
3. BENEFICIOS TÉCNICOS Y ECONÓMICOS
3.1 Beneficios Técnicos
3.2 Beneficios Económicos
Cuantificándolo en números (€, EUR).
 11

4. SELECCIÓN DE LA SOLUCIÓN
4.1 Generalidades
4.2 Alternativas
4.3 Criterios de selección
4.4 Solución de la solución
4.5 Descripción general
5. ESPECIFICACIÓN DE NECESIDADES DEL SISTEMA (p.e.
SOFTWARE)
5.1 Visión general
5.2 Especificaciones funcionales.
5.2.1 Proceso de Información
5.2.2 Interfaz de usuario
5.2.3 Datos
5.3 Otras especificaciones.
De rendimiento, de calidad, de robustez, etc.
Condiciones de excepción/manejo de excepciones.
6. RESUMEN DEL DISEÑO
Hacer referencia al Documento de Diseño y extractar algo de su
contenido, sobretodo figuras.
7. PLAN DEL PROYECTO
7.1 Fases del proyecto
7.2 Duración total
7.3 Hitos
7.4 Diagrama de Gantt.
8. RECURSOS HUMANOS Y MATERIALES
8.1 Recursos humanos
8.2 Recursos Materiales
9. RESUMEN DEL PRESUPUESTO
Presupuesto en forma de tabla (en el PROYECTO es igual al capítulo 4
del Documento de PRESUPUESTO)
10. RIESGOS DEL PROYECTO

REFERENCIAS
AUTOR##. AUTOR, I.
Título
Editorial. Ciudad, Año 20##.

Deben estar referidas en el texto mediante [AUTOR##].

 12

4.2 Documento nº 2: CÁLCULOS

Si los hay, la estructuración será particular en cada caso.

4.3 Documento nº 3: DISEÑO

Parte 1: Diseño de la arquitectura. Contenidos (no es el índice):

• Nombre y descripción funcional de cada módulo
• La interfaz de usuario
• Datos o bases de datos.
• Interconexión entre módulos y estructuras de datos.
Parte 2: Diseño de detalle. Contenidos (no es el índice):
• Algoritmos detallados para cada nuevo módulo a escribir.
• Adaptaciones necesarias para el código existente que se aprovecha.
• Técnicas específicas de programación.
• Estructura física de las estructuras de datos.
• Especificación del diccionario de datos.
• Procedimientos de inicialización.
• Chequeos y manejo de excepciones.
• Montaje de los módulos en la implementación física.

DISEÑO DE LA ARQUITECTURA
Resumen (no es obligatorio)
1. INTRODUCCIÓ
N
Descripción de la organización del documento
2. ARQUITECTU
RA GENERAL
3. ARQUITECTU
RA MÓDULO Nombre_del_Módulo1
4. ARQUITECTU
RA MÓDULO Nombre_del_Módulo2
5. …
6. ARQUITECTU
RA MÓDULO Nombre_del_MóduloN
 13

7. MATRIZ
MÓDULOS/FUNCIONES
8. ARQUITECTU
RA DE LA INTERFAZ DE USUARIO
9. ARQUITECTU
RA DE DATOS
REFERENCIAS
AUTOR##. AUTOR, I.
Título
Editorial. Ciudad, Año 20##.

Deben estar referidas en el texto mediante [AUTOR##].

DISEÑO COMPLETO

Resumen (no es obligatorio)

1. INTRODUCCIÓ
N
Descripción de la organización del documento
2. ARQUITECTU
RA GENERAL
3. ARQUITECTU
RA MÓDULO Nombre_del_Módulo1
4. ARQUITECTU
RA MÓDULO Nombre_del_Módulo2

5. …
6. ARQUITECTU
RA MÓDULO Nombre_del_MóduloN
7. ARQUITECTU
RA DE LA INTERFAZ DE USUARIO
8. ARQUITECTU
RA DE DATOS (o BASE DE DATOS)
9. MATRIZ
MÓDULOS/FUNCIONES
10. DISEÑO
DETALLADO MÓDULO Nombre_del_Módulo1
 14

11. DISEÑO
DETALLADO MÓDULO Nombre_del_Módulo2

12. …
13. DISEÑO
DETALLADO MÓDULO Nombre_del_MóduloN
14. DISEÑO
DETALLADO DE LA INTERFAZ DE USUARIO
15. DISEÑO
DETALLADO DE DATOS (o BASE DE DATOS)
REFERENCIAS
AUTOR##. AUTOR, I.
Título
Editorial. Ciudad, Año 20##.

Deben estar referidas en el texto mediante [AUTOR##].

4.4 Documento nº 4: PRESUPUESTO

1. MEDICIONES
2. PRECIOS UNITARIOS
3. PRESUPUESTO
4. RESUMEN DEL PRESUPUESTO

4.5 Documento nº 5: PLIEGO DE CONDICIONES

Resumen (no es obligatorio)

1. INTRODUCCIÓ
N
2. CONDICIONES
TÉCNICAS
Referir que están en los documentos de MEMORIA y DISEÑO,
Además:
• Recordar aquí elementos importantes para el desarrollo del
proyecto
 15

• Equipos y herramientas, documentos, normas

• Etc.
3. CONDICIONES
DE CALIDAD
Ej. Seguir ISO 9001, Tener un sistema de calidad documentado,
realizar y documentar las pruebas, ...
4. CONDICIONES DE ACEPTACIÓN
(Pruebas de aceptación)
4.1 Caso1: Prueba de ....
Propósito
Escenario
Datos de partida
Procedimiento
Resultado
4.2 Caso 2: ...
4.3 …
5. CONDICIONES DEL CONTRATISTA.
6. CONDICIONES DE SEGUIMIENTO Y CONTROL
7. CONDICIONES DE GARANTÍA Y MANTENIMIENTO
8. CONDICIONES LEGALES Y CONTRACTUALES
REFERENCIAS
AUTOR##. AUTOR, I.
Título
Editorial. Ciudad, Año 20##.

Deben estar referidas en el texto mediante [AUTOR##].

 16

4.6 ANEXO #: MANUAL DE USUARIO

(No es obligatorio. Incluir sólo si se ha tenido que hacer, ya que

propiamente no es del proyecto, sino fruto de la ejecución del mismo)

Resumen (no es obligatorio)

1. INTRODUCCIÓN
1.1 Visión general del producto.
1.2 Terminología y características básicas.
1.3 Resumen de formatos de pantallas e informes.
1.4 Estructura del manual.
2. COMENZANDO
2.1 Entrar al sistema.
2.2 Modos de ayuda.
2.3 Ejemplo de ejecución.
3. MODOS DE OPERACIÓN
3.1 Opciones/diálogos/informes
4. FUNCIONES AVANZADAS
5. MENÚS (o SINTAXIS DE COMANDOS) Y OPCIONES DEL
SISTEMA
REFERENCIAS
AUTOR##. AUTOR, I.
Título
Editorial. Ciudad, Año 20##.
 17

5. DIAGRAMA DE GANTT
 18

6. TABLA DE PRESUPUESTO (Anteproyecto)

Cant.
Nº Ref.
(Ud.)

1.
1.1 1
El presupuesto para la ejecución del Proyecto “Título” asciende a la cantidad
de (en letra) euros con (en letra) Céntimos.

1.2 1
En Bilbao, mes de 20##

1.3 1
Fdo.: Nombre Apellido1 Apellido2

1.4 1