UNIDAD 4

LA GESTION DE LOS SISTEMAS DE

INFORMACION

Ing. Iveth Robles Catari

Objetivo:

• Analizar críticamente el proceso de gestión de los sistemas de

información desde la, planificación, estrategias de desarrollo y
métodos específicos.

Contenido:
• Equipo de desarrollo
• Componentes de proyectos de software
• La visión orientada a objetos
• Desarrollo basado en Casos de uso, Iterativo e incremental
• Extensiones a UML especificas del Proceso Unificado
• Componentes y artefactos que se utilizan en los modelos
El equipo de desarrollo
de software
• Un error frecuente en empresas de
programación es tener a todo el mundo haciendo
de todo.
• En uno u otro escenario puede funcionar bien,
puede causar que esas personas no puedan
emitir estimados de calidad.
• Una de las primeras recomendaciones es buscar
que el equipo sea interdisciplinario.

• El debate y los diferentes puntos de vista

enriquecerán el proceso de desarrollo y
ayudarán a generar mayor valor al negocio.

• Un equipo interdisciplinario supone que no

todos los perfiles serán técnicos.
• Aunque por muchos años se pensó que ser de perfil técnico
era más que suficiente para incorporarse a un equipo de
desarrollo de software; hoy se le da más peso a que los
integrantes tengan:

▫ Una personalidad que pueda influenciar positivamente al

equipo de trabajo
▫ Habilidades de comunicación sobresalientes • Visión de
negocio y liderazgo
▫ La capacidad de apoyar en la definición de la estrategia del
proyecto
▫ Habilidad para proponer mejoras o cambios
▫ La capacidad de aceptar retroalimentación
▫ La apertura para entender que los logros del equipo se basan
en los entregables de todo el equipo.

• “No se vale concluir que el equipo no entregó valor al negocio

porque X o Y integrante no lograron terminar sus
Tamaño del equipo de desarrollo de
software
• El equipo de desarrollo de software puede ser
tan pequeño o tan grande como se requiera. En
su estructura más básica, el equipo deberá de
contar con mínimo 2 dos integrantes los cuales
realizarán actividades correspondientes a
diferentes roles.
• El siguiente diagrama muestra los roles más
típicos que un equipo de desarrollo debería de
incluir:
¿Cuánto tiempo tomará armar un equipo de
desarrollo?
• Esta realmente es la pregunta del millón.
• No existe una “regla de oro”.
• Dependiendo de qué tan cerrado y complejo sea
el proceso de selección, se tendrá diferentes
resultados.
• Es importante resaltar que vale la pena tomar tu tiempo para
armar al equipo.

• Se debe apoyar en la gente de confianza que se tenga y aceptar

retroalimentación sobre los candidatos con entrevistas de
diversos tipos y enfoques arrojarán el mejor resultado.

• Una excelente herramienta para filtrar candidatos es solicitando

que hagan un entregable que refleje el potencial de su trabajo.

• En aplicaciones móviles por ejemplo, se pide que hagan una

aplicación sencilla para entender su lógica y calidad de código
ROLES PROPUESTOS EN RUP
• Cada fase en RUP puede descomponerse en iteraciones.

• Una iteración es un ciclo de desarrollo completo dando

como resultado una entrega de producto ejecutable
(interna o externa).

• El proceso define una serie de roles. Los roles se

distribuyen entre los miembros del proyecto y que
definen las tareas de cada uno y el resultado.
Algunos de esos roles son:

• Analistas:
▫ Analista de procesos de negocio.
▫ Diseñador del negocio.
▫ Analista de sistema.
▫ Especificador de requisitos.
• Desarrolladores:
▫ Arquitecto de software.
▫ Diseñador
▫ Diseñador de interfaz de usuario
▫ Diseñador de cápsulas.
▫ Diseñador de base de datos.
▫ Implementador.
▫ Integrador.
• Gestores:
▫ Jefe de proyecto
▫ Jefe de control de cambios.
▫ Jefe de configuración.
▫ Jefe de pruebas
▫ Jefe de despliegue
▫ Ingeniero de procesos
▫ Revisor de gestión del proyecto
▫ Gestor de pruebas.
• Apoyo:
▫ Documentador técnico
▫ Administrador de sistema
▫ Especialista en herramientas
▫ Desarrollador de cursos
▫ Artista gráfico

• Especialista en pruebas:
▫ Especialista en Pruebas (tester)
▫ Analista de pruebas
▫ Diseñador de pruebas
• Otros roles:
▫ Stakeholders.
▫ Revisor
▫ Coordinación de revisiones
▫ Revisor técnico
▫ Cualquier rol
ROLES PROPUESTOS EN TSP
• De manera general TSP está diseñado para
ayudar en la:
▫ Formación de equipos (definición de objetivos,
asignación de roles, definir/ajustar el proceso del
equipo, planeación detallada y balanceada).
▫ Administración del equipo (comunicación,
coordinación, control del proyecto, análisis de
riesgos). El equipo debe mostrarles a los gerentes
y al cliente que se autoadministra.
• Las responsabilidades de autoadministración
se distribuyen entre los miembros del equipo a
través de ocho roles definidos que se muestran
a la izquierda de la figura, los roles definidos a la
derecha son especialistas que aportan los
departamentos de calidad, procesos,
administración de configuración y
herramientas.
Componentes de proyectos de software

• Elementos que componen la planificación de los

proyectos:
•  1. Planificación del objetivo y alcance del
proyecto
• 2. Estimación del tiempo del proyecto
• 3. Estimación de recursos
• 4. Estimación de costos
Para el desarrollo de un Proyecto …UML no
es suficiente
El proceso unificado de desarrollo
• El Proceso Unificado no es simplemente un proceso, sino un
marco de trabajo extensible que puede ser adaptado a
organizaciones o proyectos específicos.

• De la misma forma, el Proceso Unificado de Rational,

también es un marco de trabajo extensible, por lo que
muchas veces resulta imposible decir si un refinamiento
particular del proceso ha sido derivado del Proceso
Unificado o del RUP. Por dicho motivo, los dos nombres
suelen utilizarse para referirse a un mismo
concepto.
El proceso unificado de desarrollo
• El nombre Proceso Unificado se usa para
describir el proceso genérico que incluye
aquellos elementos que son comunes a la
mayoría de los refinamientos existentes.
También permite evitar problemas legales ya
que Proceso Unificado de Rational o RUP son
marcas registradas por IBM (desde su compra
de Rational Software Corporation en 2003)
El Proceso Unificado de Desarrollo de
Software PUDS

• Ligado en su origen histórico a los trabajos de

IvarJacobson en Ericsson (1967),
Objectory(1987) y Rational(1997).
PUDS:Flujos de Trabajo
• En cada iteración existen cinco flujos de trabajo (workflows):

▫ Requisitos: capturar lo que el sistema debe hacer.

▫ Análisis: refinar y estructurar los requisitos.

▫ Diseño: realizar los requisitos en la arquitectura del

sistema.

▫ Implementación: construir el software.

▫ Pruebas: verificar que la implementación funciona como se

desea.
PUDS: Fases
• El ciclo de vida del proyecto se divide en cuatro fases, cada
una de las cuales termina con un hito (milestone):

▫ Inicio: objetivos del proyecto.

▫ Elaboración: arquitectura del sistema.
▫ Construcción: capacidad operativa inicial.
▫ Transición: entrega del producto.

• En cada fase puede haber una o más iteraciones.

• En cada iteración se ejecutan los cinco flujos de trabajo

principales y los otros que sean necesarios.
Vida del Proceso Unificado
Características del PUDS
• El proceso Unificado es:
PUDS:Dirigido por Casos de Uso
PUDS:Centrado en la Arquitectura

• “La arquitectura de un sistema describe la

estrategia de división del sistema en componentes,
cómo estos componentes interaccionan, y cómo
son desplegados en el hardware.”

• Una arquitectura de calidad garantiza un

sistema de calidad, no una mera colección de
piezas mal conectadas.
PUDS:Iterativo e Incremental

• Proceso dividido en sucesivas iteraciones.

• La diferencia entre dos iteraciones es un

incremento
 II. Breve Tour por32
UML

... Modelos y Diagramas

Diagramas
UML

Modelos

Realidad
Flujo de trabajos y modelos
Flujo de trabajos y modelos
Modelos de Casos de Uso
Modelo de Análisis y Diseño
Modelo de Pruebas
• Gracias…