Planificació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.

Necesario
Conciso
Completo
No ambiguo
Verificable
Definición: Condición o necesidad de un usuario para resolver
un problema o alcanzar un objetivo.
•Es necesario si su omisión provoca una deficiencia en el sistema a construir.
•Si es fácil de leer y entender
•Si no necesita ampliar detalles en su redacción, esto es si proporciona la información
suficiente para su comprensión.
•El lenguaje usado en su definición, no debe causar confusiones.
•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.

Definir 10 requerimientos necesarios para el
desarrollo del problema planteado.

Los roles pueden clasificarse de la siguiente manera:
Administradores
de proyectos,
diseñadores de
base de datos,
etc
Personal de
pruebas
Analistas y
programadores
Usuario Líder
Personal de
mantenimiento
Usuario final



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.


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.

Mostrar una tabla con la cantidad de personal
requerido para el desarrollo y solución del problema
planteado.
Tipo de personal
Cantidad
Justificación
Evolución
Validación
Especificación
Evaluación y
negociación
Análisis
del
problema


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

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.
Las principales actividades son:

Descubrir problemas potenciales.
◦ Mandatorio (prioritario)
◦ Deseable (se necesitan pero no son indispensables)
◦ Innecesario
◦ Un requerimiento es mandatorio si afecta una operación crítica
del negocio. Si existe algún 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.
Las principales actividades son:

Evaluar factibilidades y riesgos
◦ Factibilidades técnicas
◦ Factibilidades operacionales
◦ Factibilidades económicas
Factibilidades
técnicas
(¿pueden
implementarse
los
requerimientos con la tecnología actual?); factibilidades
operacionales (¿puede ser el sistema utilizado sin alterar el
organigrama actual?); factibilidades económicas (¿ha sido
aprobado por los clientes el presupuesto?).

Incremento en la comunicación entre el equipo de
desarrollo y el cliente




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
dependencias
relaciones
entre
requerimientos
que
indiquen

Negociar con flexibilidad para que exista un beneficio mutuo

Enfocarse en intereses no en posiciones


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)


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.


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

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.



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.
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 recurso 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
Etapas de un plan de desarrollo
A 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





Programación del tiempo


Costo de Nómina
Materiales
Equipo
Costos operacionales.
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
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
Proyecto
Producto
Habrá más cambios en los requerimientos
de lo esperado
Retrasos en la
especificación
Proyecto
Producto
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.
Ejercicio

Realizar 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 riesgos
Análisis de
riesgos
Planeación de
riesgos
Listado de riesgos
potenciales
Listado de
priorización de
riesgos
Anulación de
riesgos y planes
de contingencia
Supervisión
de riesgos
Valoración de
riesgos
Identificación de riesgos
Comprende el descubrimiento de los posibles riesgos del proyecto.
 Tipos de riesgos:
Riesgos de
Tecnología.
Riesgos de
personal
Riesgos
organizacionales
Riesgos de
herramientas
Riesgos de
requerimientos
Riesgos de
estimación
•Se derivan de las
tecnologías de sw o
hw utilizadas en el
sistema
•Asociado con las
personas del
equipo de
desarrollo
•Se derivan del
entorno
organizacional
donde el software
se está
desarrollando
•Se derivan de
herramientas CASE
y de otro sw de
apoyo utilizado
para desarrollar el
sistema
•Se derivan de los
cambios de los
requerimientos del
cliente y el proceso
de gestionar dicho
cambio
•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
Elaborar la Identificación de los riesgos organizados por su tipo
Tipo de Riesgo
Descripción
Análisis 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 valoración utilizando intervalos:
Catastrófico
Muy bajo
<10%
Muy Alto
>75%
Bajo
10-25%
Probabilidad
del riesgo
Alto
50-75%
Moderado
25-50%
Insignificante
Efectos del
riesgo
Tolerable
Serio
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
probabilidad de que el riesgo aparezca se reduce.
estrategias,
la
◦ 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
requerimientos
Tiempo de
subestimado
los Rastrear la información para valorar el impacto de los
requerimiento, maximizar la información oculta en ellos.
desarrollo 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.
Riesgos de
personal
Riesgos
organizacionales
Riesgos de
herramientas
Riesgos de
requerimientos
Riesgos de
estimación
•Entrega retrasada
del hardware o de
la ayuda al software
•Muchos problemas
tecnológicos
reportados.
•Baja moral del
personal,
•Malas relaciones
entre los miembros
del equipo
•Disponibilidad de
empleo.
•Chismorreo
organizacional
•Falta de acciones
por el gestor
principal.
•Rechazo de los
miembros del
equipo para utilizar
herramientas,
•Quejas acerca de
las herramientas
CASE,
•Peticiones de
estaciones de
trabajo más
potentes.
•Peticiones de
muchos cambios en
los requerimientos,
•Quejas del cliente.
•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.

Planificación y Modelado
Proceso Unificado
• 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:
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
Actor principal.
Tiene objetivos
de usuario que se
satisfacen,
mediante el uso
de los servicios
Actores
Actor Pasivo. Está
interesado en el
comportamiento
del caso de uso,
pero no es
principal ni de
apoyo
Actor de apoyo.
Proporciona un
servicio.
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
Límite del sistema
Gestionar
devoluciones
Actor
Cajero
“actor”
Sistema de Actividad
de Ventas
Abrir
Caja
“actor”
Sistema de
Contabilidad
Analizar
Actividad
Comunicación
Gestionar
seguridad
Administrador
del sistema
Gestionar
usuarios
Caso de Uso
Diseño de Interfaz de Usuario
• Reglas en el Diseño.
http://www.elwebmaster.com/articulos/usabilidad12-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
Descargar

Documentación Planificación y Modelado