INSTITUTO TECNOLÓGICO SUPERIOR DE ÁLAMO TEMAPACHE

Carrera: Ingeniería en Sistemas Computacionales Unidad: __2____ Materia: Calidad del Software
Docente: Ing. Nicolasa Hernández Sosa______________________Calificación:__________________________________
Practica 2. Plan del proyecto software
Alumno(a):_Ricardo Romero Martínez_________________________________________________________________________
Ciclo Escolar: Febrero-Julio 2019 Semestre: 801 Grupo: A Fecha: 25/Marzo/2019

Competencia
 Reconocer y ubicar la importancia de la definición formal de los requerimientos.
 Reconocer los paradigmas(los métodos y los modelos) existentes para el análisis de los requerimientos.
 Identificar la estrecha relación existente entre el nivel de definición de los requerimientos y los modelos
de ciclo de vida.
 Definir y analizar los requerimientos de un proyecto de software.
Introducción
Cuando el Cliente solicita que se desarrolle un sistema tiene algunas nociones de lo que debe
hacer. Por esta razón cada sistema basado en software tiene un propósito, usualmente
expresado con algo que el sistema debe hacer. Un Requerimiento “es una característica del
sistema o una descripción de algo que el sistema es capaz de hacer con el objeto de satisfacer
el propósito del sistema”. Es decir, los requerimientos son lo que los clientes/usuarios esperan
que haga el sistema. Los analistas, por lo tanto, deben entender el problema de los usuarios
en su cultura y con su lenguaje y construir el sistema que resuelve sus necesidades. En si el
objetivo del análisis de requerimientos es resolver el problema. Los requerimientos definen el
Qué (el problema) del sistema. El Diseño define el Cómo (la solución). Los requerimientos, por
lo tanto deben centrarse en el cliente/usuario y el problema. Existen dos documentos que
emanan del análisis de requerimientos:
Definición de requerimientos
Es un documento que debe escribirse en términos que el cliente pueda entender. Es decir, este
documento es un listado completo de todas las cosas que el cliente espera que haga el sistema
propuesto. Este documento es escrito en forma conjunta por el cliente y el desarrollador.
Especificación de requerimientos
Documento que reitera la definición de los requerimientos en los términos técnicos apropiados para el
desarrollador del diseño de un sistema.
Es la contrapartida técnica al documento de definición de requerimientos y es escrito por los analistas
de requerimientos. A veces un único documento puede servir para ambos propósitos, lo que lleva a un
entendimiento común entre clientes, analistas de requerimientos y diseñadores. Pero a menudo se
necesitan ambos documentos. Es muy importante, que al usar ambos documentos exista un
correspondencia directa entre cada requerimiento del documento de definición y aquellos documentos
en la especificación.
Esto para que la visión del cliente este unida a la de los desarrolladores (esto se logra gracias a la gestión
de configuración). Según el Tipo los requerimientos se clasifican en:
 Requerimientos funcionales.
 Requerimientos no funcionales.
 Requerimientos del Dominio.

Según a quien van dirigidos se clasifican en:

 Requerimientos del Usuario.
 Requerimientos del Sistema.

Material y Equipo Necesario

 Computadora Personal

Metodología
Para el uso apropiado de esta práctica se recomienda realizarlas, siguiendo las instrucciones que se
indican para cada una de ellas utilizando la computadora como instrumento de apoyo.
Paso 1: Recolectar requerimientos iniciales del proyecto.
Solicitar, proporcionar y documentar los requerimientos de la administración del proyecto y
los funcionales y no funcionales de alto nivel de la aplicación.
Paso 1.1: Leer los requerimientos iniciales de la aplicación.

En los requerimientos se contemplan los siguientes puntos

Registrar boletas de infracción
Registrar infractor
Guardar información
Consultar información
Realizar reportes
Paso 1.2: Seleccionar una técnica de recopilación de requerimientos.
 Existen diversos métodos de recopilación de datos. Utilizamos la entrevista acudiendo
con el cliente para saber los requerimientos que requieren en el sistema además de
contar con un cuestionario como apoyo.

Con respecto a los usuarios

1 ¿Cuáles son diferentes tipos de usuario?

2 ¿Cuál es la Información que desea registrar de los usuarios del Sistema?

3 ¿Ésta información podrá ser visualizada por todos los usuarios o será visualizada por algún
otro usuario superior con privilegios?

4 ¿Cuáles son los permisos y/o limitaciones que tendrá cada uno de los Usuarios?

Con respecto a la funcionalidad

5 ¿Que desea que realice el sistema? “Es decir: solo ingresar los datos de las boletas, y
visualizar la información introducida, y realizar reportes”
O debe de tener algún otro modulo como ejemplo: módulo de pagos.

6 ¿Cuáles son las operaciones que debe realizar el Sistema con los datos que se ingresen?
“registrar, editar, actualizar, eliminar, enviar a alguna dirección de correo”

7 ¿Se debe ingresar solo la información especificada en las boletas o existe otro tipo de
información que se debe ingresar? “En caso de existir otro tipo de información nómbrelas y
descríbalas.”

8 Con respecto a los tipos de infracciones existentes ¿Prefiere que estos estén definidos en el
Sistema o deben ser ingresados cada vez que se registren los datos de una nueva boleta?
9 Después de haber sido registrados los datos de las boletas, que se desea realizar con la
información, ¿que se almacenara en el sistema?
” almacenar, respaldar en alguna unidad de almacenamiento, mantenerla fija en el sistema”

10 ¿Los datos registrados deben ser almacenados o agrupados con base a algún dato en
especial?, se debe de tomar alguna fecha o turno en especial, para poder agrupar los datos.
Por ejemplo que si se les olvida registrar una boleta del día 20 y la quieren registrar en el día
25

Con respecto al ambiente

11 ¿En qué ambiente se usará el producto? “Windows, procesador, memoria RAM”

12 ¿Qué obstáculos piensa usted que podrían afectan la eficiencia del sistema? “equipo no
adecuado, mala utilización”

Con respecto a los reportes

13 ¿Cuáles son los reportes que Usted quiere que genere el sistema?

14 ¿Qué información desea que aparezca en el reporte?

15 ¿Qué formato digital prefiere para generarlos? “Especificar plantilla de presentación de

resultados”

16 ¿Los reportes deben ser visualizados por pantalla o solo impresos, o ambos?
Si desea generar los reportes para visualizarlos en pantalla ¿que formato desea manejar?
(pdf, doc)

Paso 1.3: Solicitar requerimientos funcionales de la aplicación.

 Registro de tipos de infracciones
 Registro o Introducción en el sistema de datos de las boletas expedidas
  Presentación y Control de la información almacenada
 Reportes
Paso 1.4: Solicitar reglas del negocio.
 No se puede editar los datos excepto por el administrador y capturista
Paso 1.5: Solicitar requerimientos no funcionales de la aplicación.

 Implementación en sistema Windows

 Usuarios (administrador y capturista)
 Dos equipos de trabajo
 Base de datos

Paso 1.6: Determinar qué requerimientos se cumplirán con qué componentes.

Es importante ir relacionando los componentes de la aplicación identificados con

los requerimientos que se recolectaron, de tal manera que pueda validarse que no
esté faltando algún componente o requerimiento por identificar.

Paso 1.7: Almacenar los requerimientos de la aplicación.

Consiste en almacenar (comúnmente haciendo Check-in) toda la documentación
relacionada con los requerimientos de la aplicación.
Paso 2: Calendarizar el proyecto.
Identificar y registrar las actividades que se van a ejecutar durante el proyecto para crear o modificar
cada paquete de trabajo o entregable del proyecto.

Paso 2.1: Definir las Actividades del Proyecto.

 Planeación
 Análisis
 Diseño
 Construcción
 Pruebas
 Corrección
 Instalación
Paso 2.2: Distribuir el esfuerzo estimado del proyecto.
El esfuerzo estimado, el que se obtuvo al realizar la estimación, debe
distribuirse entre las actividades definidas.
Paso 2.3: Calendarizar las actividades del proyecto.
Asignar fecha de inicio y fin a cada actividad, indicar qué actividades
son predecesoras de otras actividades, registrar los retrasos (lags)
identificados, si es que hubiera alguno, así como cualquier otro valor
que sea necesario.
Paso 2.4: Acordar tareas con el equipo del proyecto.
Con base en los recursos humanos disponibles, se deben asignar tareas
a cada persona, además se deben revisar y modificar, si es necesario,
 las fechas y esfuerzo de cada actividad con base en los recursos
asignados.
Gerente del proyecto
 Planeación del proyecto
 Asigna roles
 Control estructurado
 Tiempo
 Recopila información

Analista de sistemas
 Analiza información recabada
 Interpretación de información
 Requerimientos

Diseñador
 Diseña el sistema
 Diseño de la arquitectura

Ingeniero de software
 Construcción del programa
 Base de datos
 Interfaces

Responsable de la calidad
 Aseguramiento de la calidad
 Buena estructura
 Capacidad de respuesta

Responsable de las pruebas

 Confiabilidad
 Detección de errores
 Pruebas unitarias

Paso 2.5: Calendarizar los procesos del proyecto.

Aunque en las herramientas modernas para generar cronogramas de
proyectos esta actividad típicamente se realiza de manera automática
una vez que se definieron y asociaron actividades, es importante
validar las fechas, esfuerzo, costo y cualquier otro valor, por si fuera
necesario realizar alguna modificación.

Paso 2.6: Calendarizar los paquetes de trabajo y entregables del proyecto.

Aunque en las herramientas modernas para generar cronogramas de
proyectos esta actividad típicamente se realiza de manera automática
una vez que se definieron y asociaron actividades, es importante
 validar las fechas, esfuerzo, costo y cualquier otro valor, por si fuera
necesario realizar alguna modificación.

Paso 2.7: Calendarizar las iteraciones del proyecto.

Aunque en las herramientas modernas para generar cronogramas de
proyectos esta actividad típicamente se realiza de manera automática
una vez que se definieron y asociaron actividades, es importante
validar las fechas, esfuerzo, costo y cualquier otro valor, por si fuera
necesario realizar alguna modificación.
Paso 2.8: Calendarizar las fases del proyecto.

Aunque en las herramientas modernas para generar cronogramas de

proyectos esta actividad típicamente se realiza de manera automática
una vez que se definieron y asociaron actividades, es importante
validar las fechas, esfuerzo, costo y cualquier otro valor, por si fuera
necesario realizar alguna modificación.

Paso 2.9: Balancear la carga de trabajo de los recursos del proyecto.

Revisar que las cargas de trabajo asignadas a cada recurso estén
acordes a su disponibilidad de tiempo, en caso de que haya sobre carga
o subutilización, realizar las modificaciones que sean necesarias.
Tomando en consideración los siguientes entregables:
 1) Especificación del sistema
2) Plan del proyecto software
3)
a) Especificación de requerimientos del software
b) Maquetación
4) Manual de usuario preliminar
5) Especificación de diseño:
a) Diseño preliminar
b) Diseño detallado
6) Listados del código fuente
7)
a) Planificación y procedimiento de prueba
b) Casos de prueba y resultados registrados
8) Manuales de operación y de instalación
9) Programas ejecutables
10) Manual de usuario
11) Documentos de mantenimiento
a) Informes de problemas del software
b) Peticiones de mantenimiento
c) Órdenes de cambios de ingeniería
12) Estándares y procedimientos de ingeniería del software.
Paso 3: Maquetación del Proyecto.
Estrictamente el proceso de maquetar, sólo se refiere al acto de estructurar el proyecto,
distribuir y organizar los elementos y los espacios de este. La maquetación, nos permite
justamente tener en cuenta todos esos detalles, y corregirlos a tiempo, para tener como
resultado un proyecto limpio, que cumpla con los requerimientos y que sobre todo, sea
funcional.

Las siguientes imágenes muestran las ventanas preliminares para acceder al sistema
1.- Acceso (define el tipo de usuario)
Las siguientes imágenes muestran las ventanas preliminares dentro del sistema
1.- Ventana principal

2.- Menú de infracciones

3.- Menú de reportes

4.- Menú de usuarios

Bibliografía utilizada
 Pressman, S. Roger, Ingeniería de software un enfoque práctico, Cuarta edición, MC Graw-Hill
 Sanders Joc, Calidad de software, Springer
 Modelo de capacidad de madurez, Series CMU-SEI, Addisson Wesley
Conclusiones
La calidad de un producto ya no está centrada en la satisfacción plena del cliente, ahora podemos exigir
tener un producto de calidad conforme a un proceso de calidad y este a su vez guiado por una gestión
de calidad. La calidad debe estar implícita en cada área y proceso de y no así solo en el producto final.

Para lograr que se produzcan productos de calidad deben regirse a normas, estándares de calidad a
nivel mundial, para ello hay organizaciones dedicadas a elaborar, modelos, parámetros para lograr la
calidad de nuestra empresa. Una de ella son las normas ISO reconocidas internacionalmente y están
siempre en un proceso de mejora continua para garantizar que las empresas certificadas por dichas
normas ofrezcan al usuario final un producto o servicio de calidad.

Según MacCall el modelo que se puede implementar es ISO 9126 ya que es un estándar internacional
para la medición de la calidad de software y evaluación de la calidad de sistemas de información por
los usuarios. Otro estándar importante es el ISO 25000 el cual guía al desarrollo de los productos de
software con la especificación y evaluación de requisitos de calidad

Firma, fecha y observaciones del profesor ______________________