Transcript of Planificación y Modelado. La I.R. cumple un papel primordial en el proceso de producción de...
- Diapositiva 1
- Planificacin y Modelado
- Diapositiva 2
- La I.R. cumple un papel primordial en el proceso de produccin
de software, que se enfoca a un rea fundamental: la definicin de lo
que se desea producir Su tarea principal consiste en la generacin
de especificaciones correctas que describan con claridad, sin
ambigedades, en forma consistente y compacta, el comportamiento del
sistema, de esta forma, se pretende minimizar los problemas
relacionados al desarrollo de sistemas.
- Diapositiva 3
- Definicin: Condicin o necesidad de un usuario para resolver un
problema o alcanzar un objetivo. Necesario Es necesario si su
omisin provoca una deficiencia en el sistema a construir. Conciso
Si es fcil de leer y entender Completo Si no necesita ampliar
detalles en su redaccin, esto es si proporciona la informacin
suficiente para su comprensin. No ambiguo El lenguaje usado en su
definicin, no debe causar confusiones. Verificable Cuando puede ser
cuantificable, de manera que permita hacer uso de mtodos como la
inspeccin, anlisis, demostracin o pruebas
- Diapositiva 4
- Definicin: Disciplina para desarrollar una especificacin
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 comunicacin
entre equipos Evita rechazos de usuarios finales.
- Diapositiva 5
- Definir 10 requerimientos necesarios para el desarrollo del
problema planteado.
- Diapositiva 6
- Los roles pueden clasificarse de la siguiente manera: Usuario
Lder Personal de mantenimiento Usuario final Analistas y
programadores Personal de pruebas Administradores de proyectos,
diseadores de base de datos, etc
- Diapositiva 7
- 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 tambin, es el que
utiliza las interfaces y los manuales de usuario. Usuario Lder. 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 administracin de
cambios, de la implementacin y resolucin de anomalas. Su trabajo
consiste en revisar y mejorar los procesos del producto
finalizado.
- Diapositiva 8
- Analistas y programadores. Son los responsables del desarrollo
del producto, en s ellos interactan 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.
- Diapositiva 9
- Mostrar una tabla con la cantidad de personal requerido para el
desarrollo y solucin del problema planteado.
- Diapositiva 10
- Anlisis del problema Evaluacin y negociacin Especificacin
Validacin Evolucin
- Diapositiva 11
- El objetivo de esta actividad es entender las verdaderas
necesidades del negocio para el cual se har el proyecto. Durante el
anlisis 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 comn
Identificar a los afectados del sistema Definir los lmites y
restricciones del sistema
- Diapositiva 12
- Redactar en media cuartilla el problema planteado. Elaborar el
vocabulario comn. Identificar los afectados del sistema. Definir
los lmites y restricciones del problema a solucionar.
- Diapositiva 13
- Las principales actividades son: Descubrir problemas
potenciales. Mandatorio (prioritario) Deseable (se necesitan pero
no son indispensables) Innecesario Un requerimiento es mandatorio
si afecta una operacin crtica del negocio. Si existe algn proceso
que se quiera incluir para mejorar los procesos actuales, estamos
ante un requerimiento deseable; y si se trata de un requerimiento
informativo o que puede esperar para fases posteriores, el
requerimiento es catalogado como innecesario.
- Diapositiva 14
- Las principales actividades son: Evaluar factibilidades y
riesgos Factibilidades tcnicas Factibilidades operacionales
Factibilidades econmicas Factibilidades tcnicas (pueden
implementarse los requerimientos con la tecnologa actual?);
factibilidades operacionales (puede ser el sistema utilizado sin
alterar el organigrama actual?); factibilidades econmicas (ha sido
aprobado por los clientes el presupuesto?). Incremento en la
comunicacin entre el equipo de desarrollo y el cliente
- Diapositiva 15
- 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
- Diapositiva 16
- Entregar documento en donde se enlisten los requerimientos del
sistema planteando los puntos vistos anteriormente, dicho documento
ser la carta de presentacin de los equipos. Exponer ante los
compaeros los requerimientos fundamentales para llevar a buen
trmino la solucin del problema a plantear. (tiempo de exposicin 5
minutos)
- Diapositiva 17
- Es la actividad en que se genera el documento y contiene una
descripcin 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
especificacin 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 gua para fases
posteriores.
- Diapositiva 18
- Permite demostrar que los requerimientos definidos en el
sistema son los que realmente quiere el cliente, adems revisa que
no se haya omitido ninguno, que no sean ambiguos, inconsistentes o
redundantes. La validacin de requerimientos es importante pues de
ella depende que no existan elevados costos de mantenimiento para
el software desarrollado
- Diapositiva 19
- 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.
- Diapositiva 20
- Elaborar el Documento que describa completamente las
necesidades y funcionalidades del sistema, es necesario realizar un
bosquejo del diseo 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), rplica por parte del cliente y finalmente la toma de
decisiones y compromisos que se adquirirn. Tiempo del ejercicio: 30
minutos.
- Diapositiva 21
- Unidad II. Planificacin del Software
- Diapositiva 22
- Planificacin del Software La planificacin 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 utilizarn las mismas. Objetivos: Proporcionar un
marco de trabajo que permita al gestor hacer estimaciones
razonables de recursos, costos y planificacin temporal Realizacin
de estimacin de tiempo dentro del tiempo limitado que se tiene al
comienzo de un proyecto de software
- Diapositiva 23
- Actividades asociadas al proyecto de planificacin del software
mbito del software. En esta etapa se debe evaluar la funcin y el
rendimiento que se asignaron al software durante el proceso de
anlisis. Para establecer un mbito de proyectos se debe contar con
las especificaciones no ambiguas e incompresibles, tener clara la
funcin, el rendimiento, restricciones, interfaces y la fiabilidad.
Recursos. Estimacin de los recursos requeridos para acometer el
esfuerzo del desarrollo del software. Recursos Humanos Componentes
reutilizables Herramientas Hardware- Software
- Diapositiva 24
- Actividades asociadas al proyecto de planificacin del software
Cada recurso queda especificado mediante cuatro caractersticas
Descripcin del recurso Informe de disponibilidad Fecha cronolgica
en la que se requiere el recurso Tiempo en el que ser aplicado el
recurso Recursos Humanos Componentes reutilizables Herramientas
Hardware- Software
- Diapositiva 25
- Etapas de un plan de desarrollo A continuacin se describen los
componentes principales que debe tener un plan de desarrollo para
un proyecto de software. Estimacin de Costos. El plan de desarrollo
requiere de un estimado de costos desglosado y detallado de los
costos. Se deben indicar los costos especficos para cada etapa de
desarrollo y para cada uno de los componentes. Costo de Nmina
Materiales Equipo Costos operacionales. Programacin 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.
- Diapositiva 26
- Etapas de un plan de desarrollo Planificacin del personal. Se
debe establecer cuantas personas se necesitan para cada etapa del
proyecto y que tiempo dedicarn 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. Estructuracin del equipo de trabajo (personal).
El plan debe establecer la composicin de cada grupo de trabajo. En
este componente es muy importante tomar una consideracin, qu tipo
de personas se incluirn ya que se necesita un grupo de trabajo que
se acople bien. Se podra 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. Verificacin y control de la
calidad. Para poder generar un producto de calidad es necesario que
constantemente se verifique si los componentes del proyecto se estn
cumpliendo con los requisitos establecidos para el mismo. El plan
de trabajo indicar de forma especfica los mecanismos de verificacin
y control de la calidad que se utilizarn en cada una de las
etapas.
- Diapositiva 27
- Etapas de un plan de desarrollo Gerencia de Configuracin. El
plan debe indicar de forma especfica los mecanismos que se
utilizarn 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 ms caro continuar
con el mismo que detenerlo y perder el trabajo hecho.
- Diapositiva 28
- Ejercicios de Planificacin Estimacin de costos Costo de Nmina
Materiales Equipo Costos operacionales. Programacin del tiempo
Inicio y Fin de cada etapa de desarrollo Planificacin del personal
Establecer las personas necesarias para cada etapa y el tiempo a
trabajar (hrs/dia, hrs/semana, etc.).
- Diapositiva 29
- Ejercicios de Planificacin Estructuracin del equipo de trabajo
Organigrama Verificacin y Control de Calidad Indicar de forma
especfica los mecanismos de verificacin y control de la calidad que
se utilizarn en cada una de las etapas. Gerencia de Comunicacin
Indicar de forma especfica los mecanismos que se utilizarn para
atender la necesidad y solicitudes de cambio en el proyecto.
Monitoreo del proyecto Formato donde se mostrar la forma en que el
lder se encargar de que se cumpla el plan de trabajo.
- Diapositiva 30
- PLANIFICACIN Y MODELADO
- Diapositiva 31
- Anlisis de Riesgos Una tarea importante de la gestin de
proyectos es anticipar los riesgos que podran afectar a la
planeacin del proyecto o a la calidad del software a desarrollar y
emprender acciones para evitar esos riesgos. Los resultados de este
anlisis de riesgos se deben documentar a lo largo del plan del
proyecto junto con el anlisis de consecuencias cuando el riesgo
ocurra. Es la probabilidad de que una circunstancia adversa ocurra
Riesgo
- Diapositiva 32
- Categorizacin de los riesgos Riesgos del Proyecto Afectan la
calendarizacin o los recursos del proyecto. Ej. Prdida de un
diseador 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 organizacin que
desarrolla o suministra el software. Ej. Un competidor introduzca
al mercado el software que se pretende desarrollar.
- Diapositiva 33
- Ejemplos RiesgoTipoDescripcin No disponibilidad del hardware
ProyectoEl hardware esencial para el proyecto no ser entregado a
tiempo. Cambio de requerimientosProyecto Producto Habr ms cambios
en los requerimientos de lo esperado Retrasos en la especificacin
Proyecto Producto Las especificaciones de las interfaces esenciales
no estarn a tiempo Competencia del productoNegocioUn producto
competitivo se pone en venta antes de que el sistema se complete
Cambio de tecnologaNegocioLa tecnologa fundamental sobre la que se
construir el sistema se sustituye por nueva tecnologa.
- Diapositiva 34
- Ejercicio Realizar una tabla en donde se muestren los riesgos
potenciales existentes en el proyecto, clasificndolos
adecuadamente. RiesgoTipoDescripcin
- Diapositiva 35
- Proceso de gestin 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 riesgos Anlisis de riesgos Planeacin de riesgos
Supervisin de riesgos Listado de riesgos potenciales Listado de
priorizacin de riesgos Anulacin de riesgos y planes de contingencia
Valoracin de riesgos
- Diapositiva 36
- Identificacin de riesgos Comprende el descubrimiento de los
posibles riesgos del proyecto. Tipos de riesgos: Riesgos de
Tecnologa. Se derivan de las tecnologas de sw o hw utilizadas en el
sistema Riesgos de personal Asociado con las personas del equipo de
desarrollo Riesgos organizacional es 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 requerimiento s Se
derivan de los cambios de los requerimientos del cliente y el
proceso de gestionar dicho cambio Riesgos de estimacin Se derivan
de los estimados administrativos de las caractersticas del sistema
y los recursos requeridos para construir dicho sistema
- Diapositiva 37
- Ejemplos Tecnologa. 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 crticos. Organizacional. La organizacin se reestructura
de tal forma que una gestin diferente se responsabiliza del
proyecto. Herramientas. Es ineficiente el cdigo generado por las
herramientas CASE Requerimientos. Se proponen cambios en los
requerimientos que requieren hacer rediseo Estimacin. El tiempo
requerido para desarrollar el software est subestimado.
- Diapositiva 38
- Ejercicio Tipo de RiesgoDescripcin Elaborar la Identificacin de
los riesgos organizados por su tipo
- Diapositiva 39
- Anlisis de riesgos Durante 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
valoracin utilizando intervalos: Probabilida d del riesgo Muy bajo
75% Efectos del riesgo Catastrfico SerioTolerable
Insignificante
- Diapositiva 40
- Ejercicio Elaborar la tabla correspondiente al anlisis de
riesgos RiesgoProbabilidadEfecto
- Diapositiva 41
- Planeacin de riesgos El proceso de planificacin 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 categoras: Estrategias de prevencin. Siguiendo
estas estrategias, la probabilidad de que el riesgo aparezca se
reduce. Estrategias de minimizacin. 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.
- Diapositiva 42
- Ejemplo: RiesgoEstrategia Problemas FinancierosPreparar un
documento breve para el gestor principal que muestre que el
proyecto hace contribuciones muy importantes a las metas del
negocio Enfermedad del personalReorganizar el equipo de tal forma
que haya solapamiento en el trabajo y las personas comprendan el de
los dems. Cambios de los requerimientos Rastrear la informacin para
valorar el impacto de los requerimiento, maximizar la informacin
oculta en ellos. Tiempo de desarrollo subestimado Investigar los
componentes comprados y la utilizacin de un generador de
programas
- Diapositiva 43
- Supervisin de riesgos La supervisin de riesgos normalmente
valora cada uno de los riesgos identificados para decidir si ste es
ms o menos probable y si han cambiado sus efectos. Debe ser un
proceso continuo y en cada revisin del progreso de gestin, cada uno
de los riesgos clave debe ser considerado y analizado por separado.
Riesgos de Tecnologa. Entrega retrasada del hardware o de la ayuda
al software Muchos problemas tecnolgicos reportados. Riesgos de
personal Baja moral del personal, Malas relaciones entre los
miembros del equipo Disponibilidad de empleo. Riesgos
organizacional es 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 ms
potentes. Riesgos de requerimiento s Peticiones de muchos cambios
en los requerimientos, Quejas del cliente. Riesgos de estimacin
Fracaso en el cumplimiento de los riesgos acordados En la
eliminacin de defectos reportados.
- Diapositiva 44
- Ejercicios: Por equipo, en la tabla de riesgos agregar la
planificacin de los riesgos colocando una opcin en las estrategias
de prevencin, minimizacin y contingencia. Ejemplificar de manera
clara cual sera la estrategia de supervisin a realizar para los
siguientes tipos de riesgos.
- Diapositiva 45
- Planificacin y Modelado
- Diapositiva 46
- El PU define el Modelo de Casos de Uso en la disciplina de
requerimientos, bsicamente, 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 organizacin.
Escenario. Es una secuencia especfica de acciones e interacciones
entre los actores y el sistema objeto de estudio.
- Diapositiva 47
- 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
- Diapositiva 48
- Diagrama de Casos de Uso UML proporciona notacin 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 devoluciones Abrir Caja
Analizar Actividad Gestionar seguridad Gestionar usuarios actor
Sistema de Actividad de Ventas actor Sistema de Contabilidad Lmite
del sistema Caso de Uso Comunicacin Actor Cajero Administrador del
sistema
- Diapositiva 49
- Diseo de Interfaz de Usuario Reglas en el Diseo.
http://www.elwebmaster.com/articulos/usabilidad-
12-tecnicas-para-un-buen-diseno-de-interfaces
- Diapositiva 50
- Diseo de Interfaz de Usuario integrado a los Casos de Uso
Realizar el Diseo de Interfaz