plande accion dl aula de innovación pedagogica 2024.pdf
Importancia de la Ingeniería de Requerimientos
1. Gpe. Heriberto Rangel RoblesGpe. Heriberto Rangel Robles
Ingeniero en Sistemas ComputacionalesIngeniero en Sistemas Computacionales
Importancia de laImportancia de la
Ingeniería deIngeniería de
RequerimientosRequerimientos
Universidad Interactiva y a Distancia del Estado de Guanajuato
(UNIDEG)
2. Razones frecuentes para iniciar unRazones frecuentes para iniciar un
proyecto de desarrollo de un SIproyecto de desarrollo de un SI
Interés en hacer un
empleo más eficaz de
la información
Problemas con el
SI existente
Interés en aprovechar
nuevas oportunidades
Competencia creciente
Crecimiento de
la organización
Fusiones o
adquisiciones
Cambio en el mercado
o en el entorno
del negocio
$
3. Análisis de FactibilidadAnálisis de Factibilidad
ObjetivoObjetivo ResultadosResultados
Es asegurarnos que elEs asegurarnos que el
proyecto va traerproyecto va traer
beneficios y es posiblebeneficios y es posible
realizarlo con losrealizarlo con los
recursos materiales,recursos materiales,
tecnológicos ytecnológicos y
humanoshumanos
•Seguir adelante con elSeguir adelante con el
proyectoproyecto
•Recomendar retrasar por unRecomendar retrasar por un
tiempotiempo
•No continuar con el proyectoNo continuar con el proyecto
•Continuar con el proyectoContinuar con el proyecto
modificadomodificado
4. ConsideracionesConsideraciones
– Factibilidad económicaFactibilidad económica
(administrador de la empresa):(administrador de la empresa):
Beneficios $ Vs. Costos $Beneficios $ Vs. Costos $
– Factibilidad técnicaFactibilidad técnica
(desarrollador/administrador)(desarrollador/administrador)
– Factibilidad OperativaFactibilidad Operativa
(Desarrollador)(Desarrollador)
– Factibilidad legal (desarrollador)Factibilidad legal (desarrollador)
6. ¿Qué es un requerimiento?¿Qué es un requerimiento?
• Un servicio que el sistema debeUn servicio que el sistema debe
proveerproveer
• Una característica o restricción queUna característica o restricción que
debe cumplir.debe cumplir.
7. ¿Qué describe un Ing. En¿Qué describe un Ing. En
Requerimientos?Requerimientos?
• Lo que el SW debe de HacerLo que el SW debe de Hacer
• Lo que el SW debe de SerLo que el SW debe de Ser
• Las limitantes en la construcciónLas limitantes en la construcción
8. Importancia del análisis de requisitosImportancia del análisis de requisitos
Causas de los defectos
• Los problemas con los requisitos constituyenLos problemas con los requisitos constituyen
la principal fuente de problemas (56%)la principal fuente de problemas (56%)
9. La realidad de los proyectos softwareLa realidad de los proyectos software
• En 2004, el Chaos Report de Standish GroupEn 2004, el Chaos Report de Standish Group
vaticinaba una mejora continuada en el número devaticinaba una mejora continuada en el número de
proyectos software que terminaban con éxito.proyectos software que terminaban con éxito.
14. Actividades Análisis deActividades Análisis de
RequerimientosRequerimientos
• Extracción oExtracción o elicitaciónelicitación de requisitosde requisitos
(técnicas de recogida de información)(técnicas de recogida de información)
• Análisis de requisitosAnálisis de requisitos
• Especificación de requisitosEspecificación de requisitos
• Validación de los requisitosValidación de los requisitos
– por parte de los usuariospor parte de los usuarios
– se comprueba que son válidos, consistentes yse comprueba que son válidos, consistentes y
completoscompletos
17. Elicitación (Sonsacar)Elicitación (Sonsacar)
Investigar sin que se Sienta InvestigadoInvestigar sin que se Sienta Investigado
Los Usuarios no saben lo que quieren
y si lo saben no saben como
expresarlo
Los Ing. En Requerimientos creen
que entienden mejor los problemas
que los usuarios
18. Técnicas de elicitaciónTécnicas de elicitación
• EntrevistaEntrevista
• CuestionarioCuestionario
• Análisis de TareasAnálisis de Tareas
• Análisis de DominioAnálisis de Dominio
(Investigación(Investigación
Documental)Documental)
• Repertory GirdsRepertory Girds
• Grupos de TrabajoGrupos de Trabajo
• Lluvia de IdeasLluvia de Ideas
• AprendizajeAprendizaje
• ObservaciónObservación
• PrototipoPrototipo
19. Análisis de RequerimientosAnálisis de Requerimientos
• ClasificarClasificar
• DiscriminarDiscriminar
• PriorizarPriorizar
• Considerar FactibilidadConsiderar Factibilidad
23. Ejemplo de RequerimientoEjemplo de Requerimiento
• 1. Sensores Colocados en los semáforos1. Sensores Colocados en los semáforos
• 1.1. Los sensores colocados en los semáforos deberán detectar1.1. Los sensores colocados en los semáforos deberán detectar
las infracciones de cruce de semáforo en rojo. Información alas infracciones de cruce de semáforo en rojo. Información a
recolectar: lugar (calle, intersección), día y hora, patente delrecolectar: lugar (calle, intersección), día y hora, patente del
automotor, infracción cometida.automotor, infracción cometida.
• 1.2. Los sensores colocados en los semáforos deberán detectar1.2. Los sensores colocados en los semáforos deberán detectar
las infracciones de exceso de velocidad. Información a recolectar:las infracciones de exceso de velocidad. Información a recolectar:
lugar (calle, intersección), día y hora, patente del automotor,lugar (calle, intersección), día y hora, patente del automotor,
velocidad, infracción cometida.velocidad, infracción cometida.
• 2. Lectores manuales2. Lectores manuales
• 2.1. Los lectores manuales permitirán realizar multas por falta de2.1. Los lectores manuales permitirán realizar multas por falta de
licencia. Información a recolectar: lugar (calle, altura), día y hora,licencia. Información a recolectar: lugar (calle, altura), día y hora,
patente del automotor, infracción cometida.patente del automotor, infracción cometida.
• 2.2. Los lectores manuales permitirán realizar multas por licencia2.2. Los lectores manuales permitirán realizar multas por licencia
vencida. Información a recolectar: lugar (calle, altura), día y hora,vencida. Información a recolectar: lugar (calle, altura), día y hora,
25. Especificación de RequerimientosEspecificación de Requerimientos
del Software (SRS)del Software (SRS)
El presente documento tiene como propósitoEl presente documento tiene como propósito
definir las especificaciones funcionales, nodefinir las especificaciones funcionales, no
funcionales y del sistemafuncionales y del sistema
26. Documento de VisiónDocumento de Visión
• El propósito de éste documento es recoger,El propósito de éste documento es recoger,
analizar y definir las necesidades de altoanalizar y definir las necesidades de alto
nivel y las características del sistema denivel y las características del sistema de
gestión de una empresa de distribución degestión de una empresa de distribución de
artículos deportivosartículos deportivos