Unidad I.Ingeniería de
RequerimientosPlanificación y Modelado
La I.R. cumple un papel primordial en el proceso de producción de software, que se enfoca a un área fundamental:
la definición de lo que se desea producir
Su tarea principal consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema, de esta forma, se pretende minimizar los problemas relacionados al desarrollo de sistemas.
Introducción
Definición: Condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.
Requerimiento
Necesario
•Es necesario si su omisión provoca una deficiencia en el sistema a construir.
Conciso
•Si es fácil de leer y entender
Completo
•Si no necesita ampliar detalles en su redacción, esto es si proporciona la información suficiente para su comprensión.
No ambiguo
•El lenguaje usado en su definición, no debe causar confusiones.
Verificabl
e
•Cuando puede ser cuantificable, de manera que permita hacer uso de métodos como la inspección, análisis, demostración o pruebas
Definición: Disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en donde se describen las funciones que realizará el sistema.
Beneficios:◦ Permite gestionar las necesidades del proyecto en forma estructurada.◦ Mejora la capacidad de predecir cronogramas de proyectos así como sus
resultados.◦ Disminuye los costos y retrasos del proyecto.◦ Mejora la calidad del software◦ Mejora la comunicación entre equipos◦ Evita rechazos de usuarios finales.
Ingeniería de Requerimientos
Definir 10 requerimientos necesarios para el desarrollo del problema planteado.
Ejercicio
Los roles pueden clasificarse de la siguiente manera:
Personal involucrado
Usuario Líder
Personal de mantenimiento
Usuario finalAnalistas y programadores
Personal de pruebas
Administradores de proyectos,
diseñadores de base de datos,
etc
Usuario Final. Es la persona que usará el sistema desarrollado. Será quien utilice, disponga y se encuentre familiarizado con los procesos que debe realizar el software; así también, es el que utiliza las interfaces y los manuales de usuario.
Usuario Líder. Es el individuo que comprende el ambiente del sistema o el dominio del problema en donde será empleado el software desarrollado.
Personal de Mantenimiento. Para proyectos que requieran un mantenimiento eventual, éstas personas son las responsables de la administración de cambios, de la implementación y resolución de anomalías. Su trabajo consiste en revisar y mejorar los procesos del producto finalizado.
Personal Involucrado
Analistas y programadores. Son los responsables del desarrollo del producto, en sí ellos interactúan directamente con el cliente.
Personal de pruebas. Se encarga de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes validan si los requerimientos satisfacen las necesidades del cliente.
Personal Involucrado
Mostrar una tabla con la cantidad de personal requerido para el desarrollo y solución del problema planteado.
Ejercicio
Tipo de personal
Cantidad Justificación
Actividades de la Ingeniería de Requerimientos
Análisis del problema
Evaluación y negociación
Especificación
Validación
Evolución
El objetivo de esta actividad es entender las verdaderas necesidades del negocio para el cual se hará el proyecto.
Durante el análisis del problema, se realiza una serie de pasos para garantizar un acuerdo entre los involucrados, basados en los problemas reales del negocio, los pasos serian los siguientes:◦ Comprender el problema que se está resolviendo◦ Construir un vocabulario común◦ Identificar a los afectados del sistema◦ Definir los límites y restricciones del sistema
Análisis del problema
Redactar en media cuartilla el problema planteado.
Elaborar el vocabulario común.
Identificar los afectados del sistema.
Definir los límites y restricciones del problema a solucionar.
Ejercicios
Las principales actividades son:
Descubrir problemas potenciales.◦ Mandatorio (prioritario)◦ Deseable (se necesitan pero no son indispensables)◦ Innecesario
Evaluar factibilidades y riesgos◦ Factibilidades técnicas◦ Factibilidades operacionales◦ Factibilidades económicas
Incremento en la comunicación entre el equipo de desarrollo y el cliente
Evaluación y Negociación de Requerimientos
Documentar todos los requerimientos a un nivel de detalle apropiado
Mostrar todos los requerimientos a los involucrados del sistema
Analizar el impacto que tengan los cambios o requerimientos antes de aceptarlos
Establecer las relaciones entre requerimientos que indiquen dependencias
Negociar con flexibilidad para que exista un beneficio mutuo
Enfocarse en intereses no en posiciones
Evaluación y Negociación de Requerimientos
Entregar documento en donde se enlisten los requerimientos del sistema planteando los puntos vistos anteriormente, dicho documento será la carta de presentación de los equipos.
Exponer ante los compañeros los requerimientos fundamentales para llevar a buen término la solución del problema a plantear. (tiempo de exposición 5 minutos)
Ejercicio.
Es la actividad en que se genera el documento y contiene una descripción completa de las necesidades y funcionalidades del sistema, que será desarrollado; describe el alcance del sistema y la forma como hará sus funciones, definiendo los requerimientos.
En la especificación se definen: ◦ Todos los requerimientos de hardware◦ Todos los requerimientos de software◦ Diagramas◦ Modelos de sistemas y cualquier otra cosa que sirva de soporte
y guía para fases posteriores.
Especificación de Requerimientos de software.
Permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente, además revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes.
La validación de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollado
Validación de los requisitos
Los requerimientos cambian por diferentes razones:◦ Porque al analizar el problema, no se hacen las preguntas
correctas a las personas correctas.◦ Porque cambió el problema que se estaba resolviendo.◦ Porque los usuarios cambiaron su forma de pensar o sus
percepciones.◦ Porque cambió el ambiente del negocio.
Evolución de los requerimientos
Elaborar el Documento que describa completamente las necesidades y funcionalidades del sistema, es necesario realizar un bosquejo del diseño de interfaz del sistema en donde se pueda observar el resultado que se pretende obtener. Así mismo es necesario incluir un formato en donde se enlisten los acuerdos finales.
Exponer ante los clientes los requerimientos (incluidos en el sistema), réplica por parte del cliente y finalmente la toma de decisiones y compromisos que se adquirirán.
Tiempo del ejercicio: 30 minutos.
Ejercicio
Unidad II. Planificación del Software
Planificación del Software
La planificación es fundamental en el proceso de desarrollo de un producto de software, en el cual se establece, entre otras cosas, que tareas y cuando se van a realizar y los recursos que utilizarán las mismas.
Objetivos: Proporcionar un marco de trabajo que permita al gestor hacer
estimaciones razonables de recursos, costos y planificación temporal
Realización de estimación de tiempo dentro del tiempo limitado que se tiene al comienzo de un proyecto de software
Actividades asociadas al proyecto de planificación del software
Ámbito del software. En esta etapa se debe evaluar la función y el rendimiento que se asignaron al software durante el proceso de análisis. Para establecer un ámbito de proyectos se debe contar con las especificaciones no ambiguas e incompresibles, tener clara la función, el rendimiento, restricciones, interfaces y la fiabilidad.
Recursos. Estimación de los recursos requeridos para acometer el esfuerzo del desarrollo del software.
Recursos Humanos
Componentes reutilizables
Herramientas Hardware-Software
Actividades asociadas al proyecto de planificación del software
Cada recursos queda especificado mediante cuatro características Descripción del recurso Informe de disponibilidad Fecha cronológica en la que se requiere el recurso Tiempo en el que será aplicado el recurso
Recursos Humanos
Componentes reutilizables
Herramientas Hardware-Software
Realizar ejercicio
Etapas de un plan de desarrolloA continuación se describen los componentes principales
que debe tener un plan de desarrollo para un proyecto de software.
Estimación de Costos. El plan de desarrollo requiere de un estimado de costos desglosado y detallado de los costos. Se deben indicar los costos específicos para cada etapa de desarrollo y para cada uno de los componentes. Costo de Nómina Materiales Equipo Costos operacionales.
Programación del tiempo. Se indicará cuando comienza y termina cada una de las etapas de desarrollo. Esto es necesario para poder determinar en todo momento si el proyecto se encuentra adelantado, atrasado o en tiempo.
Etapas de un plan de desarrollo
Planificación del personal. Se debe establecer cuantas personas se necesitan para cada etapa del proyecto y que tiempo dedicarán a trabajar en el mismo. (hrs/dia, hrs/semana, etc.). Cada etapa puede requerir mayor o menor cantidad de personas que otras etapas y no todas las personas trabajan en todas las etapas.
Estructuración del equipo de trabajo (personal). El plan debe establecer la composición de cada grupo de trabajo. En este componente es muy importante tomar una consideración, qué tipo de personas se incluirán ya que se necesita un grupo de trabajo que se acople bien. Se podría dar el caso de que se haga un grupo con individuos que trabajen muy bien solos o con algunas personas pero no con el grupo en el que se incluyan.
Verificación y control de la calidad. Para poder generar un producto de calidad es necesario que constantemente se verifique si los componentes del proyecto se están cumpliendo con los requisitos establecidos para el mismo. El plan de trabajo indicará de forma específica los mecanismos de verificación y control de la calidad que se utilizarán en cada una de las etapas.
Etapas de un plan de desarrollo
Gerencia de Configuración. El plan debe indicar de forma específica los mecanismos que se utilizarán para atender la necesidad y solicitudes de cambio en el proyecto.
Monitoreo del proyecto. El plan debe indicar como la gerencia monitoreará las actividades del proyecto y se encargará de que se cumpla (hasta donde sea posible) el plan de trabajo.
Manejo de Riesgos. Todo proyecto tiene sus riesgos. El plan debe establecer que se hará en caso de retraso o qué ocurrirá si se pierde uno o varios miembros del personal. Otro aspecto que debe considerar el plan es bajo qué circunstancias se decidirá no continuar con el proyecto ya que siempre existe la posibilidad de que el desarrollo se salga de control y resulte más caro continuar con el mismo que detenerlo y perder el trabajo hecho.
Ejercicios de Planificación
Estimación de costos Costo de Nómina Materiales Equipo Costos operacionales.
Programación del tiempo Inicio y Fin de cada etapa de desarrollo
Planificación del personal Establecer las personas necesarias para cada etapa y el
tiempo a trabajar (hrs/dia, hrs/semana, etc.).
Ejercicios de Planificación
Estructuración del equipo de trabajo Organigrama
Verificación y Control de Calidad Indicar de forma específica los mecanismos de verificación y
control de la calidad que se utilizarán en cada una de las etapas.
Gerencia de Comunicación Indicar de forma específica los mecanismos que se utilizarán
para atender la necesidad y solicitudes de cambio en el proyecto.
Monitoreo del proyecto Formato donde se mostrará la forma en que el líder se
encargará de que se cumpla el plan de trabajo.
PLANIFICACIÓN Y MODELADO
Unidad III Análisis del Proyecto
Análisis de Riesgos
•Una tarea importante de la gestión de proyectos es anticipar los riesgos que podrían afectar a la planeación del proyecto o a la calidad del software a desarrollar y emprender acciones para evitar esos riesgos.
•Los resultados de este análisis de riesgos se deben documentar a lo largo del plan del proyecto junto con el análisis de consecuencias cuando el riesgo ocurra.
Es la probabilidad de que una circunstancia adversa ocurra
Riesgo
Categorización de los riesgos
Riesgos del Proyecto•Afectan la calendarización o los recursos del proyecto.•Ej. Pérdida de un diseñador experimentado.
Riesgos del Producto•Afectan a la calidad o al rendimiento de l software que se está desarrollando.•Ej. El rendimiento de un componente que se adquirió no cumple con lo esperado.
Riesgos del Negocio•Estos afectan a la organización que desarrolla o suministra el software.•Ej. Un competidor introduzca al mercado el software que se pretende desarrollar.
Ejemplos
Riesgo Tipo Descripción
No disponibilidad del hardware
Proyecto El hardware esencial para el proyecto no será entregado a tiempo.
Cambio de requerimientos ProyectoProducto
Habrá más cambios en los requerimientos de lo esperado
Retrasos en la especificación
ProyectoProducto
Las especificaciones de las interfaces esenciales no estarán a tiempo
Competencia del producto Negocio Un producto competitivo se pone en venta antes de que el sistema se complete
Cambio de tecnología Negocio La tecnología fundamental sobre la que se construirá el sistema se sustituye por nueva tecnología.
EjercicioRealizar una tabla en donde se muestren los
riesgos potenciales existentes en el proyecto, clasificándolos adecuadamente.
Riesgo Tipo Descripción
Proceso de gestión de riesgos
Es preciso anticiparse a los riesgos: comprender el impacto de éstos en el proyecto, en el producto y en el negocio, considerando los pasos para evitarlos.
Identificación de riesg
os
Análisis de
riesgos
Planeación
de riesg
os
Supervisión de riesg
os
Listado de riesgos
potenciales
Listado de priorización de riesgos
Anulación de riesgos y planes de
contingencia
Valoración de riesgos
Identificación de riesgosComprende el descubrimiento de los posibles riesgos del proyecto. Tipos de riesgos:
Riesgos de Tecnología.• Se
derivan de las tecnologías de sw o hw utilizadas en el sistema
Riesgos de personal• Asociad
o con las personas del equipo de desarrollo
Riesgos organizacionales• Se derivan
del entorno organizacional donde el software se está desarrollando
Riesgos de herramientas• Se derivan
de herramientas CASE y de otro sw de apoyo utilizado para desarrollar el sistema
Riesgos de requerimientos• Se derivan
de los cambios de los requerimientos del cliente y el proceso de gestionar dicho cambio
Riesgos de estimación• Se derivan
de los estimados administrativos de las características del sistema y los recursos requeridos para construir dicho sistema
Ejemplos Tecnología. La base de datos que se utiliza en el sistema no puede procesar
muchas transacciones por segundo como se esperaba.
Personal. El personal clave está enfermo y no disponible en momentos críticos.
Organizacional. La organización se reestructura de tal forma que una gestión diferente se responsabiliza del proyecto.
Herramientas. Es ineficiente el código generado por las herramientas CASE
Requerimientos. Se proponen cambios en los requerimientos que requieren hacer rediseño
Estimación. El tiempo requerido para desarrollar el software está subestimado.
Ejercicio
Tipo de Riesgo Descripción
Elaborar la Identificación de los riesgos organizados por su tipo
Análisis de riesgosDurante este proceso, se considera por separado cada riesgo
identificado y se decide acerca de la probabilidad y la seriedad del mismo.
Para ello se realizará una valoración utilizando intervalos:
Probabilidad del riesgo
Muy bajo <10%
Bajo10-25%
Moderado
25-50%
Alto50-75%
Muy Alto
>75%
Efectos del
riesgo
Catastrófico
Serio
Tolerable
Insignificante
Ejercicio
Elaborar la tabla correspondiente al análisis de riesgos
Riesgo Probabilidad Efecto
Planeación de riesgos El proceso de planificación de riesgos considera
cada uno de los riesgos clave que han sido identificados, así como las estrategias para gestionarlos.
Estas estrategias pueden dividirse en tres categorías:◦ Estrategias de prevención. Siguiendo estas estrategias, la
probabilidad de que el riesgo aparezca se reduce.
◦ Estrategias de minimización. Siguiendo estas estrategias se reducirá el impacto del riesgo.
◦ Estrategias de contingencia. Seguir estas estrategias es estar preparado para lo peor y tener una estrategia para cada caso.
Ejemplo:Riesgo Estrategia
Problemas Financieros Preparar un documento breve para el gestor principal que muestre que el proyecto hace contribuciones muy importantes a las metas del negocio
Enfermedad del personal Reorganizar el equipo de tal forma que haya solapamiento en el trabajo y las personas comprendan el de los demás.
Cambios de los requerimientos
Rastrear la información para valorar el impacto de los requerimiento, maximizar la información oculta en ellos.
Tiempo de desarrollo subestimado
Investigar los componentes comprados y la utilización de un generador de programas
Supervisión de riesgos
La supervisión de riesgos normalmente valora cada uno de los riesgos identificados para decidir si éste es más o menos probable y si han cambiado sus efectos.
Debe ser un proceso continuo y en cada revisión del progreso de gestión, cada uno de los riesgos clave debe ser considerado y analizado por separado.
Riesgos de Tecnología.•Entrega retrasada del hardware o de la ayuda al software
•Muchos problemas tecnológicos reportados.
Riesgos de personal•Baja moral del personal,
•Malas relaciones entre los miembros del equipo
•Disponibilidad de empleo.
Riesgos organizacionales•Chismorreo organizacional
•Falta de acciones por el gestor principal.
Riesgos de herramientas•Rechazo de los miembros del equipo para utilizar herramientas,
•Quejas acerca de las herramientas CASE,
•Peticiones de estaciones de trabajo más potentes.
Riesgos de requerimientos•Peticiones de muchos cambios en los requerimientos,
•Quejas del cliente.
Riesgos de estimación•Fracaso en el cumplimiento de los riesgos acordados
•En la eliminación de defectos reportados.
Ejercicios: Por equipo, en la tabla de riesgos agregar la
planificación de los riesgos colocando una opción en las estrategias de prevención, minimización y contingencia.
Ejemplificar de manera clara cual sería la estrategia de supervisión a realizar para los siguientes tipos de riesgos.
Pla
nific
ació
n y
Mod
ela
do
Unidad IV. Análisis de los Requerimientos
• El PU define el Modelo de Casos de Uso en la disciplina de requerimientos, básicamente, es el conjunto de todos los casos de uso; es un modelo de la funcionalidad y el entorno del sistema.
• Los casos de uso son un mecanismo para ejemplificar de manera simple y entendible el uso de un sistema.
• Definiciones importantes:
Proceso Unificado
Actor. Es algo con comportamiento como una persona (identificada por un rol), sistema informatizado u organización.
Escenario. Es una secuencia específica de acciones e interacciones entre los actores y el sistema objeto de estudio.
Casos de Uso
Actores
Actor principal. Tiene objetivos de usuario que se satisfacen, mediante el uso de
los servicios
Actor de apoyo. Proporciona un
servicio.
Actor Pasivo. Está interesado en el
comportamiento del caso de uso, pero no
es principal ni de apoyo
Diagrama de Casos de Uso
UML proporciona notación para los diagramas de casos de uso con el fin de ilustrar los nombres de los casos de uso y los actores y las relaciones entre ellos.Grupo Financiero
Procesar venta
Gestionar devolucion
es
Abrir Caja
Analizar Actividad
Gestionar seguridad
Gestionar usuarios
“actor” Sistema de
Actividad de Ventas
“actor” Sistema de
Contabilidad
Límite del sistema
Caso de Uso
Comunicación
Actor
Cajero
Administrador del sistema
Diseño de Interfaz de Usuario
•Reglas en el Diseño.http://www.elwebmaster.com/articulos/
usabilidad-12-tecnicas-para-un-buen-diseno-de-interfaces
Diseño de Interfaz de Usuario integrado a los Casos de Uso
Realizar el Diseño de Interfaz
Top Related