Este documento presenta los requerimientos para un proyecto de ingeniería de software para la obtención de requerimientos. Se describen las fases e involucrados en el proceso, así como técnicas como entrevistas y diagramas para obtener información del cliente. Finalmente, se especifican detalles del proyecto y tipos de contratos para la relación con proveedores.

1. Dirección General de Educación Superior Tecnológica
Instituto Tecnológico de San Juan del Río
INGENIERÍA DE REQUERIMIENTOS
MATERIA: ADMINISTRACIÓN DE PROYECTOS.
Maestra: Uribe RodrÍguez Ma. Patricia.
Presentan:
Gama Gómez Jonathan Alejandro.
Fuentes Cruz Laura Josefina.
09590408.
González Arredondo Rosa Giovana.
Hernández Aguilar Gisela.
Ledesma Benítez Lidia.
09590409.
095904011.
09490413.
09590417.
Zamorano Hernández Diego Jonathan.
09590447.
San Juan del Río, Qro. Septiembre 2011

2. INGENIERÍA DE REQUERIMIENTOS.
 Es
el proceso de recopilar, analizar y
verificar las necesidades del cliente
para un sistema de software
 La
meta de la ingeniería de
requerimientos
es
entregar
una
especificación de requerimientos de
software correcta y completa

3. FASES DE IMPLEMENTACIÓN PARA LA
OBTENCIÓN DE REQUISITOS
1.
Obtener requisitos
2.
Analizar requisitos
3.
Documentar requisitos
4.
Verificar los requisitos
5.
Validar los requisitos

4. ERRORES COMUNES AL OBTENER
REQUERIMIENTOS PUEDEN SER:
 Requerimientos
incompletos
 Que el desarrollador/analista no esté
involucrado lo suficiente en el proceso
inicial
 Mal uso de recursos
 Disfrazar o exagerar los alcances del
proyecto
 Estimaciones erróneas y engañosas

5. OBJETIVO

6. 4.1.1 OBJETIVO.
Emplear un sistema, basado en reglas,
que coadyuve al desarrollador de
software reduciendo el tiempo y
costos en la documentación de
requerimientos de software.

7. 4.1.1.1 OBJETIVOS SECUNDARIOS.
 Adquirir
los conocimientos de los expertos en
desarrollo de software para tener una concordancia
y clara obtención de los requerimientos de software
 Contribuir a incrementar el conocimiento sobre el
dominio de aplicación en el que actúa un software.
 Descomponer un dominio de aplicación complejo,
para permitir solucionarlos por módulos.

8. 4.1.2 METAS.

9. 4.1.2 METAS.
 Permitir
gestionar
las
necesidades del proyecto en
forma estructurada.
 Mejorar
la capacidad de
predecir
cronogramas
de
proyectos, así como sus
resultados.
 Disminuir los costos y retrasos
del proyecto.

10. 4.1.2 METAS.
 Mejorar
la calidad del software.
 Mejorar
la
comunicación
entre
equipos.
 Evitar rechazos de usuarios finales.

11. 4.1.3 ALCANCES Y LIMITACIONES.

12.  Objetivo:
Un breve análisis del proyecto en todas sus
dimensiones
(Técnicas,
Financieras,
Institucionales, etc.) y una evaluación
general de sus efectos en su área de
influencia.
 Es
donde se inicia el plan del proyecto
 ¿Qué pretendemos lograr?
 ¿Cómo?
 Aplicar herramientas y técnicas para definir y
gestionar el alcance del proyecto.

13. 4.1.3 ALCANCES Y LIMITACIONES.
Alcances
Alcance:
Definir límites del
trabajo y partes del proyecto.
“Hacer lo que hay que hacer y
no hacer lo que no hay que
hacer”.
Definición de lo que incluye y
no incluye el proyecto.

14. 4.1.3 ALCANCES Y LIMITACIONES.
Administración
del
alcance (planeación)
 Asegurar que el proyecto
incluya todo el trabajo
requerido y sólo el trabajo
requerido para terminar el
proyecto exitosamente.
 Herramientas:
 Declaración del alcance
 WBS
(Work Breakdown
Structure) Desglose
de
actividades
por
capas
descendiendo en nivel y
detalle.


15. 4.1.3 ALCANCES Y LIMITACIONES.
Declaración del alcance
El alcance del proyecto sirve para asegurar que el
cliente, patrocinador y el equipo confirmen cómo
serán los entregables del proyecto.
 Entregables SMART:
 Específico
 Medible
 Acordado
 Realista
 tiempo establecido.


16. 4.1.3 ALCANCES Y LIMITACIONES.
Herramientas declaración alcance.

17. 4.1.3 ALCANCES Y LIMITACIONES.

Entregables por fases (WBS)
Muchos proyectos los podemos dividir en fases, a continuación
presentamos un mapa mental con los entregables por fases, en
el que cada una de ellas incluye sub entregables y criterios de
aceptación.
Mapa mental de sub entregables finales.

18. 4.1.3 ALCANCES Y LIMITACIONES.
 Limitaciones
 Qué
está incluido en el proyecto.
 Representación de flujo de datos.
 Representación de funcionalidades.
 Qué está fuera del alcance del proyecto.
 Identificar necesidades que no tenemos
que realizar nosotros y deben existir.
 Evitar
invertir tiempo y recursos en
actividades que no producen beneficios.

19. 4.1.3 ALCANCES Y LIMITACIONES.

Ejemplo:

20. 4.1.4 JUSTIFICACIÓN

21. 4.1.4 JUSTIFICACIÓN

Impacto, el beneficio en el medio, el impacto en el
contexto o en el medio.

Solución de problemas.

Razones por las cuales se realiza la investigación.

Posibles aportes desde el punto de vista teórico o
práctico.

22. 4.1.4 JUSTIFICACIÓN

¿Por qué se hace la investigación?
 ¿Cuáles
 ¿A
serán sus aportes?
quiénes pudiera beneficiar?

23. 4.2 TÉCNICAS PARA OBTENER
INFORMACIÓN SOBRE EL PROYECTO

24. 4.2 TÉCNICAS PARA OBTENER INFORMACIÓN
SOBRE EL PROYECTO
Entrevistas:
 Las entrevistas permite al analista tomar conocimiento del
problema y comprender los objetivos de la solución
buscada.
 Básicamente, la estructura de la entrevista abarca tres
pasos: identificación de los entrevistados, preparación de
la entrevista, realización de la entrevista y documentación
de los resultados


25. 4.2 TÉCNICAS PARA OBTENER INFORMACIÓN
SOBRE EL PROYECTO
JAD.
 Es una práctica de grupo que
se desarrolla durante varios
días y en la que participan
analistas, usuarios,
administradores del sistema y
clientes (IBM, 1997).

Durante la sesión se discute en grupo sobre estos
temas, llegándose a una serie de conclusiones que se
documentan. En cada sesión se van concretando más
las necesidades del sistema

26. 4.2 TÉCNICAS PARA OBTENER INFORMACIÓN
SOBRE EL PROYECTO



Brainstorming (Tormenta de ideas).
Es también una técnica de reuniones en grupo cuyo objetivo
es que los participantes muestren sus ideas de forma libre.
Consiste en la mera acumulación de ideas y/o información sin
evaluar las mismas. El grupo de personas que participa en
estas reuniones no debe ser muy numeroso (máximo 10
personas), una de ellas debe asumir el rol de moderador de la
sesión, pero sin carácter

27. 4.2 TÉCNICAS PARA OBTENER INFORMACIÓN
SOBRE EL PROYECTO
Concept Mapping.
 son grafos en los que los vértices representan
conceptos y las aristas representan posibles
relaciones entre dichos conceptos.


28. 4.2 TÉCNICAS PARA OBTENER INFORMACIÓN
SOBRE EL PROYECTO


Sketches y Storyboards.
Está técnica es frecuentemente usada
por los diseñadores gráficos de
aplicaciones en el entorno web.


Casos de Uso.
Los casos de uso permiten mostrar el
contorno (actores) y el alcance 8
(requisitos funcionales expresados como
casos de uso) de un sistema.

29. 4.2 TÉCNICAS PARA OBTENER INFORMACIÓN
SOBRE EL PROYECTO
Cuestionario y Checklist.
 Consiste en redactar un documento con preguntas
cuyas respuestas sean cortas y concretas, o
incluso cerradas por unas cuantas opciones en el
propio cuestionario (Checklist).


30. 4.2 TÉCNICAS PARA OBTENER INFORMACIÓN
SOBRE EL PROYECTO
Comparación de terminología:
 Esta técnica es utilizada en forma complementaria
a otras técnicas para obtener consenso respecto
de la terminología a ser usada en el proyecto de
desarrollo. Para ello es necesario identificar el uso
de términos diferentes para los mismos conceptos
(correspondencia), misma terminología para
diferentes conceptos (conflictos) o cuando no hay
concordancia exacta ni en el vocabulario ni en los
conceptos (contraste).


31. 4.3 ESPECIFICACIONES DEL
PROYECTO Y CONTRATO

32. 4.3 ESPECIFICACIONES DEL PROYECTO Y CONTRATO
PROVEEDOR GENERAL (PG).
CONTRATO A PRECIO ALZADO.

33. 4.3 ESPECIFICACIONES DEL PROYECTO Y CONTRATO
PROVEEDOR GENERAL (PG). CONTRATO POR
ADMINISTRACION.

34. 4.3 ESPECIFICACIONES DEL PROYECTO Y CONTRATO
DISEÑO - IMPLEMENTACION “LLAVE
EN MANO” - PRECIO ALZADO.

35. 4.3 ESPECIFICACIONES DEL PROYECTO Y CONTRATO
ADMINISTRACIÓN DIRECTA DE VARIOS
PROVEEDORES.
Cliente
Gte. Proy. Y
Staff
Diseñador.
Staff (adicional)
Proveedores.

36. TIPO DE RELACIÓN
CONTRACTUAL.
AGENTE
VENDEDOR
DESCRIPCIÓN.
SUGERENCIAS PARA
CONTRATAR.
Es una relación contractual
el agente o consejero de
confianza es el que provee
un servicio especializado y
representa
al
cliente,
manteniéndose fuera de
conflictos de intereses. Su
rol es guiar y asesorar.
Los agentes pueden ser: el
abogado, el doctor, el
gerente de proyectos.
Recomendamos contratar
a los agentes en función a
su
capacidad
y
confiabilidad.
El vendedor es la persona
o empresa que provee un
producto
o
servicio
definido y a cierto precio, si
el contrato se amplía el
gana más y el cliente paga
un costo adicional.
Recomendamos contratar
a los vendedores en
función a precio, servicio y
soporte después de la
venta.

37. Gracias por su
atención.