INGENIERÍA DE SOFTWARE

Proyecto Ingeniería de Software

[Nombre del Proyecto]
[Integrantes]
• Fecha: [dd/mm/aaa]
INGENIERÍA DE SOFTWARE

Tabla de Contenido

Información del Proyecto.......................................................................................... 3

1. Propósito ............................................................................................. 4

2. Alcance del producto / Software ............................................................ 4

3. Funcionalidades del producto ................................................................ 4

4. Clases y características de usuarios ........................................................ 5

5. Entorno operativo ................................................................................ 5

6. Requerimientos funcionales .................................................................. 5

6.1(Nombre de la funcionalidad 1) ......................................................................... 6

6.2 (Nombre de la funcionalidad 2).................................................................... 6

6.3 (Nombre de la funcionalidad N)................................................................... 6

7. Modelado de casos de uso ..................................................................... 7

7.1 Diagrama de casos de uso................................................................................. 7

7.2 Diagrama de secuencia ..................................................................................... 8

8. Modelo de dominio............................................................................... 9

8.1 Diagrama de clases ........................................................................................... 9

9.- Requerimientos no funcionales ........................................................................... 10

10.- Diseño y arquitectura de software ..................................................................... 10

11.- Diseño lógico y físico de la base de datos............................................................. 11

12.- Diseño de interfaces.......................................................................................... 12

13.- Método de Prueba ............................................................................................ 13

14.- Mantenimiento del software ............................................................................. 14

15.-Calendarización y Costos del Proyecto ................................................................. 15

16.-Conclusiones Generales del Proyecto .................................................................. 21

17.- Referencias Bibliográficas.................................................................................. 22

INGENIERÍA DE SOFTWARE

Información del Proyecto

Empresa / Organización
Proyecto
Fecha de preparación
Cliente
Patrocinador principal
Gerente / Líder de Proyecto
Gerente / Líder de Análisis de
negocio y requerimientos
INGENIERÍA DE SOFTWARE

1. Propósito

En esta sección se define el nombre o título del software que se está especificado en el
documento, incluyendo su número de versión o Release.

Luego se describe cuales componentes o partes del alcance del producto están incluidas en el
documento, estableciendo si este documento cubre la totalidad del software, sólo una parte
del sistema, subsistema o subgrupo de procesos.

2. Alcance del producto / Software

Se incluye una corta descripción del alcance del software que se está especificando,
incluyendo:

• Su propósito u objetivo general.

• Beneficios que brinda al área de negocio y organización.
• Objetivos y metas. Es recomendable establecer la relación de los objetivos del
software con los objetivos corporativos y estrategias de negocio.
• Se puede hacer referencia a otros documentos, por ejemplo, una definición de
alcance u acta de constitución del proyecto.

3. Funcionalidades del producto

Lista de las funcionalidades del software que se están especificando en el documento de

requerimientos. Cada funcionalidad puede estar compuesta por uno o varios requerimientos
funcionales de software.

Aquí solo se incluye una lista numerada de las principales funcionalidades, la información
detallada de requerimientos funcionales se documenta en la sección 7 de este documento.
INGENIERÍA DE SOFTWARE

4. Clases y características de usuarios

En esta sección se clasifican los usuarios que utilizaran el producto. La clasificación puede ser
en función a la frecuencia de uso, grupo de funcionalidades utilizadas, privilegios de
seguridad, nivel de experiencia y otros parámetros.

Se puede usar una lista para enumerar los usuarios tipo que utilizarán el software,
describiendo las características de cada uno.

Para cada tipo de usuario, se pueden mencionar las funcionalidades de producto (Sección 4)
que le sean relevantes. Igualmente se puede hacer mención de cuales usuarios utilizan una
mayor parte del sistema y con más frecuencia, para distinguirlos de usuarios ocasionales o
que acceden a pocas funcionalidades.

5. Entorno operativo

En esta sección se describe el entorno operativo en el que se desenvolverá el sistema,

software, módulo o grupo de funcionalidades, mencionando aspectos como la plataforma de
hardware, versiones de sistema operativo y otros sistemas o componentes con los que debe
coexistir.

6. Requerimientos funcionales

Los requerimientos funcionales de un sistema, son aquellos que describen cualquier actividad
que este deba realizar, en otras palabras, el comportamiento o función particular de un
sistema o software cuando se cumplen ciertas condiciones.

En esta sección de la plantilla, ilustramos como organizar los requerimientos funcionales de

software por funcionalidad de producto o sistema. Aquí se listan las funcionalidades y para
cada una a su vez se listan los requerimientos funcionales.

Los requerimientos funcionales también se pueden documentar en una matriz de trazabilidad

de requerimientos.

A continuación se muestra como documentar cada funcionalidad:

INGENIERÍA DE SOFTWARE

6.1(Nombre de la funcionalidad 1)

En el título de la funcionalidad, se recomienda utilizar nombres lo más descriptivo posible para

cada funcionalidad. No limitarse a nombrarlas “Funcionalidad 1”. Un buen ejemplo podría ser
“Autorización de pedido de compra”.

Descripción: Descripción corta de la funcionalidad.

Prioridad: Nivel bajo, medio o alto de prioridad. Esta debe ser establecida por el área
funcional.

Acciones iniciadoras y comportamiento esperado: Secuencia de acciones de usuario y

respuestas esperadas del sistema para esta funcionalidad.

Es recomendable incluir como el software debe responder a condiciones de error y entradas

de datos inválidas.

Cada requerimiento debe ser identificado unívocamente, para lo cual se recomienda usar un
número de secuencia, que tenga algún significado y de formato común a toda la organización.
Por ejemplo: REQ-1, REQ-2, REQ-3

6.2 (Nombre de la funcionalidad 2)

Seguir los mismos lineamientos de la funcionalidad 1 para tantas funcionalidades tenga el

sistema.

6.3 (Nombre de la funcionalidad N)

Seguir los mismos lineamientos de la funcionalidad 1 para tantas funcionalidades tenga el

sistema.
INGENIERÍA DE SOFTWARE

7. Modelado de casos de uso

Un caso de uso es una técnica de modelado usada para describir lo que debería hacer un
sistema nuevo o lo que hace un sistema que ya existe. ... Los casos de uso son descripciones
funcionales del sistema; describen cómo los actores pueden usar un sistema. Para el
modelado de casos de uso, se incluirán los siguientes puntos Diagrama de casos de uso y
Diagrama de secuencia.

7.1 Diagrama de casos de uso

Un diagrama de caso de uso puede incluir varios casos de uso y las relaciones entre casos de
uso y las personas, los grupos o los sistemas que interactúan para llevar a cabo el caso de uso

Ejemplo

En este apartado incluirás los diagramas de casos de usos de tus requerimientos funcionales
INGENIERÍA DE SOFTWARE

7.2 Diagrama de secuencia

Un diagrama de secuencia está estructurado de tal manera que representa una línea de
tiempo que comienza en la parte superior y desciende gradualmente para marcar
la secuencia de interacciones. Cada objeto tiene una columna y los mensajes intercambiados
entre ellos están representados por flechas

Ejemplo

En este apartado incluirás los diagramas de casos de secuencia de tus requerimientos

funcionales
INGENIERÍA DE SOFTWARE

8. Modelo de dominio

Un Modelo de Dominio es un artefacto de la disciplina de análisis, construido con las reglas

de UML durante la fase de concepción, en la tarea construcción del modelo de dominio,
presentado como uno o más diagramas de clases y que contiene, no conceptos propios de un
sistema de software sino de la propia realidad. Para el modelo de dominio se incluirá el
diagrama de clases.

8.1 Diagrama de clases

Un diagrama de clases es una representación gráfica que sirve para representar la estructura
de un sistema que será implementado utilizando un lenguaje orientado a objetos.

Ejemplo

En este apartado incluirás los diagramas de clases del proyecto

INGENIERÍA DE SOFTWARE

9.- Requerimientos no funcionales

Los requerimientos no funcionales son los que especifican criterios para evaluar la operación
de un servicio de tecnología de información, en contraste con los requerimientos
funcionales que especifican los comportamientos específicos.

10.- Diseño y arquitectura de software

Arquitectura de software. La arquitectura de software representa la estructura o las

estructuras del sistema, que consta de componentes de software, las propiedades visibles
externamente y las relaciones entre ellas. En este apartado incluirás el diagrama de
arquitectura de software del proyecto.

Los diagramas de arquitectura de software son una manera fantástica de comunicar cómo
planea construir un sistema de software (diseño inicial) o cómo funciona un sistema
de software existente (documentación retrospectiva, intercambio de conocimientos y
aprendizaje).

Ejemplo
INGENIERÍA DE SOFTWARE

11.- Diseño lógico y físico de la base de datos

El modelo lógico contiene las clases de estereotipo entity, muestra entre ellas y sus atributos.
El modelo físico contiene las tablas que se van a crear en la base de datos y su cardinalidad.

En este apartado incluirás el diseño lógico de la base de datos de tu proyecto

Ejemplo
INGENIERÍA DE SOFTWARE

12.- Diseño de interfaces

Las guías de diseño son pautas generales para el diseño de la interfaz del software que los
desarrolladores de una interfaz publican con la finalidad de que las aplicaciones que los
programadores desarrollen sean amigables con el usuario y congruentes con la interfaz de la
plataforma. En este apartado incluirás el diseño de interfaces de tu proyecto, lo puedes hacer
en Paint, Corel Draw, Java, C# o en cualquier aplicación que domines.

Ejemplo
INGENIERÍA DE SOFTWARE

13.- Método de Prueba

Las pruebas de software son las investigaciones empíricas y técnicas cuyo objetivo es
proporcionar información objetiva e independiente sobre la calidad del producto a la parte
interesada o stakeholder. Es una actividad más en el proceso de control de calidad.

Existen varios tipos de pruebas de software, pero para esta actividad, solo se solicita que
desarrolles:

• 2 casos de pruebas de caja blanca

• 2 casos de pruebas de caja negra.

Ejemplo

Pruebas de caja negra

Acceso al software de gestión de inventario mediante contraseña y usuario

(Se muestra en pantalla un formulario que cuenta con dos botones)

Caso 1 Se presiona el botón “Administrador”

Caso1.1 Nos muestra otro formulario donde se pide un usuario y contraseña

Caso1.1.1 Si la contraseña y el usuario es incorrecto muestra el siguiente mensaje “usuario y

contraseña incorrecta”

Caso1.1.2 La contraseña es correcta pero el usuario no, se muestra el siguiente mensaje

“usuario incorrecto”

Pruebas de caja blanca

Caso 1

Descripción de caso: El sistema navegará con una entrada de ruta básica con la cual entrará
y hará un recorrido hasta llegar a una salida por distintas rutas, la ruta básica se denomina
de manera independiente.

Técnica de prueba de caja blanca: Diagrama de flujo/Ruta básica.

INGENIERÍA DE SOFTWARE

En este anterior se demuestra las rutas de entrada por las cuales el programa pasa en tres
ocasiones, por ejemplo, cuando queremos ingresar con nuestro usuario al sistema, una está
diseñada de cuando este está registrado, otra para cuando no, y la última es por si salió algún
error.

14.- Mantenimiento del software

En ingeniería del software, el mantenimiento de software es la modificación de un producto

de software después de la entrega, para corregir errores, mejorar el rendimiento, u otros
atributos. El mantenimiento del software es una de las actividades más comunes en la
ingeniería de software.

Existen varios tipos de mantenimiento del software, para esta actividad requerimos que
expliques cuáles serán las estrategias que aplicarán en los siguientes tipos:

Ejemplo

Mantenimiento Preventivo

• Revisión de instalación por Setup

• Desfragmentación del Disco Duro
• Liberación de memoria Ram
• Liberación de espacio en Disco Duro
• Ejecución de Antivirus
• Copia de Seguridad
• Scandisk

Mantenimiento Correctivo

• Reinstalación de Sistema Operativo

• Reinstalación de Programas, Aplicativos y Office
INGENIERÍA DE SOFTWARE

15.-Calendarización y Costos del Proyecto

La calendarización del proyecto de software es una actividad que distribuye estimaciones de

esfuerzo a través de la duración planificada del proyecto al asignar el esfuerzo a tareas
específicas de ingeniería del software. La calendarización evoluciona a lo largo del tiempo

En este apartado incluirás la calendarización y costos del proyecto

Ejemplo.- Calendarización
INGENIERÍA DE SOFTWARE

Ejemplo.- Costos por puntos de función

Tabla de costes del producto de software por Puntos de Función

La empresa “Papas Don Francisco “requiere las siguientes funciones.

Registro de productos

Registro de clientes

Registro de proveedores

Consulta de productos

Consulta de clientes

Consulta de inventario

Consulta de ventas

Actualización de datos de productos

Actualización de datos de clientes

Actualización de datos de inventario

Actualización de datos de proveedores

Actualización de datos de ventas

Eliminar Producto

Eliminar Cliente

Eliminar Proveedor

Listado de ventas

Listado de clientes

Listado de productos

Reporte de clientes registrados por fecha

Reporte de ventas

Registro de productos (EI 4PF)

Registro de clientes (EI 4PF)

Registro de proveedores (EI 4PF)

Consulta de productos (EQ 4PF)

INGENIERÍA DE SOFTWARE

Consulta de clientes (EQ 4PF)

Consulta de inventario (EQ 4PF)

Consulta de ventas (EQ 4PF)

Actualización de datos de productos (EI 4PF)

Actualización de datos de clientes (EI 4PF)

Actualización de datos de inventario (EI 4PF)

Actualización de datos de proveedores (EI 4PF)

Actualización de datos de ventas (EI 4PF)

Eliminar Producto (EI 4PF)

Eliminar Cliente (EI 4PF)

Eliminar Proveedor (EI 4PF)

Listado de ventas (EO 5PF)

Listado de clientes (EO 5PF)

Listado de productos (EO 5PF)

Reporte de clientes registrados por fecha (EO 5PF)

Reporte de ventas (EO 5PF)

6 tablas en BD (ILF 60 PF = 6 tablas *10 PF)

Puntos de función sin ajustar (PFSA)= 145

 INGENIERÍA DE SOFTWARE

A) Tabla de costes del producto de software por Puntos de Función

Tipo de complejidad Baja Media Alta Total

Entrada externa (EI) 3PF 11* 4PF 6PF 44

Salida externa (EO) 4PF 5*5PF 7PF 25

Consulta externa (EQ) 3PF 4*4PF 6PF 16

Archivo lógico interno 7PF 6*10PF 15PF 60

(ILF)

Archivo de interfaz 5PF 0* 7PF 10PF 0

externo (EIF)

PFSA 145
INGENIERÍA DE SOFTWARE

B) Tabla de Niveles de Influencia (Factor de Ajuste)

Características generales del sistema Nivel de Influencia

1- Comunicación de datos 3

2- Procesamiento distribuido 3

3- Objetivos de Rendimiento 2

4-Configuración del equipamiento 1

5- Tasa de transacciones 4

6- Entrada de datos on-line 2

7- Interfaz con el usuario 2

8- Actualización on-line 2

9- Procesamiento complejo 2

10- Reusabilidad del código 4

11-Facilidad de implementación 2

12- Facilidad de operación 3

13- Instalaciones múltiples 1

14- Facilidad de cambios 2

Nivel de Influencia 33
INGENIERÍA DE SOFTWARE

PFA=PFSA*[0.65+(0.01*factor de ajuste)] esta fórmula ya está dada solo hay que sustituir el
PFSA y el factor de ajuste

Donde:

PFSA: Puntos de función sin ajustar

PFA: Puntos de función ajustados

PFA: 145*[0.65+0.01*33)]

PFA:145*[0.65+0.33)]

PFA=145*0.98

PFA=142.1 =142 Punto de función ajustado

H/H=PFA*Horas PF promedio

H/H= 142*8

H/H = 1136 Horas hombre

Desarrolladores= 2

Horas =1136/2 =568 horas (duración del proyecto en horas)

568/5= 113.6 días de trabajo

113.6/20=5.68 meses para desarrollar el software de lunes a viernes 5 horas diarias con 2
desarrolladores.

Sueldo mensual desarrolladores: $ 4500.000

Otros costos del proyecto: $500.000

Costo= (Desarrolladores*Duración meses *sueldos)+ Otros costos

Costo = (2* 5.68*4500.000) +500.000 = $56120.000

INGENIERÍA DE SOFTWARE

16.-Conclusiones Generales del Proyecto

En este punto deberás incluir los aspectos que aprendiste durante el desarrollo de este
proyecto y de la materia (mínimo una cuartilla).
INGENIERÍA DE SOFTWARE

17.- Referencias Bibliográficas