97319688-Botta-Analisis-de-Sistemas

Vista previa del material en texto

Página 1 de 142 Autor: Adrián Botta 
 
 
Resumen de Teoría de: 
 
Análisis de 
Sistemas 
 
 
Autor: Adrián Botta 
 
Año: 2008 
 
Fuentes: 
Análisis Esencial Estructurado – Yourdon y Pressman 
Sistemas de Información Administrativa – Murdick y Munson 
Ing. Del Software: Un enfoque práctico – Pressman 
UML: proceso unificado y Manual de referencia – Rumbaugh, Jacobson, Booch 
UML y patrones – Larman 
Ing. Del Software Orientado a objetos con UML, Java e Internet - Weitzenfeld 
Análisis y Diseño Orientado a objetos con aplicaciones – Booch 
Análisis y Diseño de Sistemas – Kendall y Kendall 
Análisis y Diseño de Sistemas de Información - Senn 
Análisis Estructurado Moderno - Yourdon 
Página 2 de 142 Autor: Adrián Botta 
 
Página 3 de 142 Autor: Adrián Botta 
 
 
 
 
UNIDAD 1 
 
 
 
 
 
 
 
 
 
Autor: Adrián Botta - Año 2008 
Página 4 de 142 Autor: Adrián Botta 
 
 
 
De Definición 
 
 
 
De Desarrollo 
 
 
 
De Mantenimiento 
 
 
 
 
 
Lineal, Secuencial, 
Ciclo de vida Básico 
o Cascada 
 
 
 
DRA 
 
 
 
 
 
Incremental 
 
Espiral 
 
Ciclo de Vida 
Estructurado 
 
T4G 
 
 
 
 
Prototipos 
 
 
 
Reutilización de 
Componentes 
 
Definición 
 
 
 
 
 
Fases 
 
 
 
 
 
 
 
 
 
 
 
 
 
Modelos 
 
 
 
 
 
 
 
 
 
 
Modelos 
Evolutivos 
 
 
 
 
 
 
 
 
 
Estrategias 
 
 
 
 
 
 
 
 
Características 
 
 
 
 
Ciclo 
Ing. Sistemas / Información 
Planificación del Proyecto de Software 
Análisis de Requisitos 
 
Diseño de Software 
Generación de Código 
Prueba de Software 
 
M. Correctivo 
M. Adaptativo 
M. Perfectivo 
M. Preventivo 
 
1- Ing. Sistemas / Información 
2- Análisis de los requisitos del Software 
3- Diseño 
4- Generación de Código 
5- Pruebas 
6- Mantenimiento 
1- Modelado de Gestión 
2- Modelado de Datos 
3- Modelado de Proceso 
4- Generación de Aplicaciones 
5- Prueba y Entrega 
 
 
1- Encuesta 
2- Análisis de Sistemas 
3- Diseño 
4- Implantación 
5- Generación de Pruebas de Aceptación 
6- Prueba final de Aceptación 
7- Descripción del Procedimiento 
8- Conversión de Bases de Datos 
9- Instalación 
 
De Requisitos 
De Análisis 
De Diseño 
De Factibilidad 
Verticales 
 
Producción 
Consumo 
 Dirigido Por Casos de Uso 
 Centrado en la Arquitectura 
 Iterativo e Incremental 
1- Fase de Inicio 
2- Fase de Elaboración 
3- Fase de Construcción 
4- Fase de Transición 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Ing. Del 
Software 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Proceso 
Unificado 
Página 5 de 142 Autor: Adrián Botta 
 
UNIDAD 1: INGENIERÍA DEL SOFTWARE (IDS) 
 
Es la aplicación (y estudio) de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, 
operación y mantenimiento del software. 
La IDS es una tecnología multicapa. Cualquier enfoque de la ingeniería debe 
apoyarse sobre un compromiso de organización de calidad. 
El fundamento de la IDS es la capa de proceso, que permite un desarrollo 
racional y oportuno de la IDS. El proceso define un marco de trabajo para un 
conjunto de Áreas clave de proceso (ACPs), que forman la base de control de 
gestión de proyectos del software y establecen el contexto en el que se 
aplican los métodos técnicos, se obtienen productos de trabajo, se establecen 
hitos, se asegura la calidad y el cambio se gestiona adecuadamente. 
Los métodos indican cómo construir técnicamente el software. Abarcan una gran gama de tareas que 
incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. 
Las herramientas proporcionan un enfoque automático o semi-automático para el proceso y para los 
métodos. Cuando se integran herramientas para que la información creada por una herramienta la pueda 
utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado ingeniería del 
software asistida por computadora (CASE). 
 
Para construir la IS adecuadamente, se debe definir un proceso de desarrollo de software. El trabajo que 
se asocia a la IS se puede dividir en 3 fases genéricas, con independencia del área de aplicación, tamaño o 
complejidad del proyecto: 
 Fase de Definición: Se centra sobre el qué (que inf. ha de ser procesada, que interfaces se 
colocarán, etc.). Han de definirse los requisitos clave del sistema y del software. Tendrán lugar aquí 
3 tareas principales: 
- Ing. De sistemas o de Información 
- Planificación del proyecto del software 
- Análisis de los requisitos 
 Fase de Desarrollo: Se centra en el cómo (como han de diseñarse las BD, como ha de 
implementarse una función, etc.). Tendrán lugar aquí 3 técnicas principales: 
- Diseño de software 
- Generación de código 
- Prueba del software 
 Fase de Mantenimiento: Se centra en el cambio. Hay 4 tipos de cambio: 
- Corrección (Mantenimiento Correctivo): Se cambia el software para corregir los defectos 
- Adaptación (M. Adaptativo): Produce modificación en el software para acomodarlo a los cambios 
de su entorno externo 
- Mejora (M. Perfectivo): Lleva al software más allá de sus requisitos funcionales originales 
- Prevención (M. Preventivo o Reingeniería del Software): Hace cambios en programas a fin de que 
se puedan corregir, adaptar y mejorar más fácilmente. 
Además de estas actividades, los usuarios requieren de un mantenimiento continuo 
 
El proceso del Software 
Se establece un marco común de proceso definiendo un pequeño nº de actividades del marco de trabajo 
que son aplicables a todos los proyectos del software. Un nº de conjuntos de 
tareas que permiten que las actividades del marco de trabajo se adapten a 
las características del proyecto del software y a los requisitos del equipo del 
proyecto. Finalmente, las actividades de protección abarcan el modelo de 
procesos. 
Últimamente se hace énfasis en la madurez del proceso. El Instituto de IS 
ha desarrollado un modelo completo que se basa en un conjunto de 
Página 6 de 142 Autor: Adrián Botta 
 
funciones de IS que deberían estar presentes conforme organizaciones alcanzan diferentes niveles de 
madurez del proceso. El estado actual se categoriza en un nivel según un cuestionario. 
El esquema de grados determina la conformidad con un modelo de capacidad de madurez que define las 
actividades clave que se requieren en los diferentes niveles de madurez del proceso. 
 
MODELOS DE PROCESO DEL SOFTWARE 
 
A fin de resolver problemas reales, se selecciona un modelo de proceso para la IS según la naturaleza del 
proyecto y de la aplicación, los métodos y las herramientas a utilizarse, y los controles y entregas que se 
requieren. 
Todo el desarrollo del software se puede caracterizar como bucle de 
resolución de problemas (ver imagen). 
Raccoon sugiere un “Modelo del caos”, que describe el desarrollo de software 
como una extensión desde el usuario hasta el desarrollador y la tecnología. 
Conforme progresa el trabajo hacia un sistema completo, las etapas descritas 
anteriormente se aplican recursivamente a las necesidades del usuario y a la 
especificación técnica del desarrollador del software. 
 
Modelo Lineal Secuencial, Ciclo de vida Básico o Cascada 
 
1- Ing. de Sistemas / Información: El trabajo comienza estableciendo requisitos de todos los 
elementos del sistema y asignando al software algún subgrupo de estos requisitos. La Ing. de 
información abarca los requisitos que se recogen a nivel de empresa estratégico y en el nivel del 
área de negocio 
2- Análisis de los requisitos del software: Referido a la función requerida, comportamiento, 
rendimiento e interconexión. 
3- Diseño: Estructura de datos, arquitectura de software, representaciones de interfaz y algoritmo 
4- Generación de código 
5- Pruebas 
6- Mantenimiento: Algunos problemas son 
 Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo 
 A menudo es difícil que el cliente exponga explícitamente todos los requisitos 
 El cliente debe tener paciencia: una versión de trabajo del programa no estará disponible hasta 
que el proyecto esté muy avanzado. Un grave error puede ser desastrososi no se detecta hasta 
que se revisa el programa 
 
Modelo DRA (Diseño Rápido de Aplicaciones) 
Es un proceso de desarrollo lineal secuencial que enfatiza un ciclo de 
desarrollo extremadamente corto. Es una adaptación a alta velocidad del 
modelo lineal secuencial en el que se logra el desarrollo rápido. Utiliza 
una construcción basada en componentes. El proceso DRA permite al 
equipo de desarrollo crear un sistema completamente funcional dentro de 
periodos cortos de tiempo. Sus fases son: 
 
1- Modelado de Gestión: ¿Qué inf. circula, a dónde va, quién la 
genera, etc..? 
2- Modelado de Datos: Se definen las características de cada uno de 
Análisis Diseño Prueba Código 
Ing. de sistemas / Inf. 
Página 7 de 142 Autor: Adrián Botta 
 
los objetos y las relaciones entre estos objetos 
3- Modelado del proceso: Los objetos de datos definidos en la fase de modelado de datos quedan 
transformados para lograr el flujo de información necesario para implementar una función de 
gestión 
4- Generación de Aplicaciones: El DRA trabaja para volver a utilizar componentes de programas ya 
existentes y/o crear componentes reutilizables. Utiliza técnicas de 4º generación 
5- Prueba y entrega: La reutilización reduce tiempos de pruebas, sin embargo se deben probar todos 
los componentes nuevos y ejecutar todas las interfaces a fondo 
 
Cada una de las funciones puede ser afrontada por un equipo DRA separado y ser integradas en un solo 
conjunto. 
 
Inconvenientes del modelo DRA: 
 Para proyectos grandes requiere muchos recursos humanos 
 DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades 
 No todos los tipos de aplicaciones son apropiadas para DRA (componentes) 
 DRA no es adecuado cuando los riesgos técnicos son altos (Ej: nuevas tecnologías) 
 
 
MODELOS EVOLUTIVOS DE PROCESO DEL SOFTWARE 
 
En ninguno de los paradigmas de la IS se tiene en cuenta la naturaleza evolutiva del software. Los 
modelos evolutivos son iterativos; se caracterizan por la forma en que permiten a los ingenieros del 
software desarrollar versiones cada vez más completas del software 
 
Modelo Incremental 
Combina elementos del modelo lineal 
secuencial (aplicados repetidamente) con la 
filosofía iterativa de construcción de 
prototipos. Este modelo aplica secuencias 
lineales de forma escalonada mientras 
progresa en el tiempo en el calendario. Cada 
secuencia lineal produce un “incremento” del 
software. Cuando se utiliza un modelo 
incremental, el 1º incremento a menudo es un 
producto esencial, es decir, se afrontan 
requisitos básicos, pero muchas funciones 
suplementarias quedan sin extraer. El cliente 
utiliza el producto central, y como resultado de su utilización, se desarrolla un plan para el incremento 
siguiente. El plan afronta la modificación del producto central a fin de cumplir mejor las necesidades del 
cliente y la entrega de funciones y características adicionales. Este proceso se repite siguiendo la entrega 
de cada incremento, hasta que se elabore el producto completo. 
Este modelo se centra en la entrega de un producto operacional con cada incremento. Los primeros 
incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad 
que precisa y también una plataforma para la evaluación. 
Este tipo de desarrollo es útil cuando la dotación de personal no estará disponible para una 
implementación completa en la fecha límite que se haya establecido para el proyecto. 
 
El modelo Espiral 
Conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos 
del modelo lineal secuencial. Proporciona el potencial para el desarrollo rápido de versiones 
incrementales del software. En el modelo espiral, el software se desarrolla en una serie de versiones 
Página 8 de 142 Autor: Adrián Botta 
 
incrementales. Durante las primeras interacciones, la versión incremental podría ser un modelo en papel o 
un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema 
diseñado. El modelo en espiral se divide en un número de actividades de marco de trabajo, también 
llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas (ver imagen) 
Cada una de las regiones está compuesta por un conjunto 
de tareas del trabajo, llamado conjunto de tareas, que se 
adaptan a las características del proyecto que va a 
emprenderse. 
Este modelo puede adaptarse y aplicarse a lo largo de la 
vida del software de computadora. 
La espiral, cuando se caracteriza de esta forma, 
permanece operativa hasta que el software se retira. El 
modelo utiliza la construcción de prototipos como mecanismo de reducción de riesgos. 
El modelo espiral es un enfoque realista del desarrollo de sistemas y de software a gran escala. 
 
Técnicas de Cuarta Generación (T4G) 
Abarca un amplio espectro de herramientas de software que tienen algo en común: todas facilitan al 
ingeniero del software la especificación de algunas características del software a alto nivel. Luego, la 
herramienta genera el código fuente basándose en la especificación del técnico. Cuanto mayor sea el nivel 
en el que se especifique el software, más rápido se podrá construir el programa. 
T4G comienza con el paso de reunión de requisitos, que se traducen en un prototipo operativo. Sin 
embargo, en la práctica no siempre se puede hacer esto, ya que el cliente puede ser ambiguo en sus 
especificaciones, o puede que no esté dispuesto a especificar la información en la forma que puede 
aceptar una herramienta T4G. Por eso el contacto desarrollador-cliente es esencial. 
 
T4G tiene ventajas e inconvenientes. 
1- T4G ofrece una solución fiable a muchos problemas del software 
2- El tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas y medias. 
3- El uso de T4G para grandes trabajos exige el mismo o más tiempo de análisis diseño y prueba, 
para lograr un ahorro sustancial de tiempo que puede conseguirse mediante la eliminación de la 
codificación 
 
Ciclo de Vida Estructurado 
(S) Está involucrado el analista;(N) No está involucrado;(S/N) Puede o no estar 
1- La Encuesta (S/N): Empieza cuando el usuario solicita que una o más partes de su sistema se 
automaticen. Tiene como objetivos: 
 Identificar a los usuarios responsables y crear un campo de actividad inicial del sistema 
 Identificar las deficiencias actuales en el ambiente del usuario 
 Establecer metas y objetivos para el nuevo sistema 
 Determinar si es factible automatizar el sistema, y de ser así, sugerir escenarios aceptables. Esto 
implicará estimaciones de costo (Margen error + 50 %) 
 Preparar el esquema que se utilizará para guiar el resto del proyecto 
2- Análisis de Sistemas (S): Su propósito es transformar las políticas del usuario y el esquema del 
proyecto en una especificación estructurada. Implica el desarrollo de un modelo ambiental y uno de 
comportamiento, que se combinan para formar el modelo esencial, que representará una descripción 
formal del lo que el nuevo sistema debe hacer. 
3- El Diseño (S): Asigna porciones del modelo esencial a procesadores adecuados y a labores 
apropiadas. Dentro de cada labor se define una jerarquía de módulos de programas y de interfaces 
entre ellos para implantar la especificación creada en el análisis. Se diseñan las Bases de Datos. Se 
desarrolla el modelo de implantación del usuario, que describe las interfaces y fronteras hombre-
máquina. 
Página 9 de 142 Autor: Adrián Botta 
 
4- Implantación (N): Incluye la codificación y la integración de módulos en un esqueleto 
progresivamente más completo del sistema final 
5- Generación de pruebas de Aceptación (S/N) 
6- Garantía de Calidad o Prueba final de aceptación (S/N) 
7- Descripción del procedimiento (S): Aquí se desarrolla el manual del usuario 
8- Conversión de bases de datos (Participación variable): Convierte o adapta la vieja base de datos a 
una nueva que se adapte al nuevo sistema9- Instalación (N): Puede ser total o gradual 
 
ESTRATEGIAS 
 
Una estrategia es un plan para lograr un objetivo. Las estrategias de desarrollo incluyen la selección de 
una tecnología y lenguaje de programación particular. Otras estrategias son los prototipos y la 
reutilización de componentes. 
 
Prototipos 
Un prototipo es una versión preliminar, incompleta o reducida de un sistema. Su propósito es obtener 
rápidamente la información necesaria para ayudar en la toma de decisiones. Los tipos de prototipos son: 
 Prototipos de requisitos (o de Relevamiento): Permite que los usuarios perciban la funcionalidad del 
producto final a través del diseño de interfaces o pantallas del sistema 
 Prototipos de Análisis: Hacen posible generar rápidamente una arquitectura general de acuerdo a la 
especificación de requisitos 
 Prototipos de Diseño: Permiten explorar y comprender la arquitectura particular del sistema 
 Prototipos verticales: Ayudan a comprender parte de un problema y desarrollar su solución 
completa 
 Prototipos de factibilidad: Demuestra si es posible lograr ciertos objetivos del proyecto 
Un prototipo no es un producto de calidad que deba mantenerse a largo plazo, sino que son creados y 
probados rápidamente para luego desecharlos. 
Los prototipos tienen éxito cuando: 
- Se tiene claro el propósito del prototipo y se usa adecuadamente 
- Se comprende la tecnología a usar y su relación con el proceso de prototipos 
- Se integra un grupo de técnicos apropiado para hacer el prototipo 
- Se evalúa al grupo y las entregas finales 
- Se involucra a tiempo en el proceso a los usuarios finales 
Los prototipos fallan cuando: 
- No se entiende qué es un prototipo y cómo debe usarse 
- No se comprende bien como organizar al grupo de trabajo 
- Los prototipos nunca terminan 
- Se cree que un prototipo es un producto aceptable 
 
Reutilización de Componentes 
Es la explotación de componentes desarrollados anteriormente dentro de un mismo proyecto o entre 
proyectos. Se clasifican en: 
 
Dentro de la reutilización, existen 2 partes: 
 Consumo de componentes reutilizables: Requiere identificar si ya existe una solución disponible, 
parcial o completa. La ventaja es que el componente ya está testeado. 
Según el Nivel 
Bajo nivel  Mismo Proyecto  Herencia, Procedimientos 
 
Alto Nivel  Distintos proyectos  Paquetes, Bibliotecas 
Página 10 de 142 Autor: Adrián Botta 
 
 Producción de componentes reutilizables: Significa tener una perspectiva de múltiples proyectos. 
El esfuerzo para producir componentes reutilizables es mayor al esfuerzo para producir 
componentes normales. 
La Reutilización es valiosa cuando: 
- Se desea estandarizar 
- Se desea reducir costos 
- Se desea mejorar la calidad del producto y el tiempo de entrega 
La Reutilización no es valiosa cuando: 
- No se reducen los tiempos de prueba 
- Se deben ajustar los componentes 
- No se comprenden las interfaces de los componentes 
 
HERRAMIENTAS 
 
Son aplicaciones que apoyan la administración del proceso de software. El conjunto de estas herramientas 
se conoce como Ing. de Software asistida por computadora (CASE), cuyo objetivo es asistir al 
desarrollador durante las diferentes actividades del ciclo de vida del proceso del software. Las 
herramientas incluyen editores de texto, generadores de diagramas, verificadores, depuradores, etc. 
 
EL PROCESO UNIFICADO 
 
El proceso unificado (PU) es un proceso de desarrollo de software. Un proceso de desarrollo de software 
es un conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema 
software. El proceso unificado es un marco de trabajo genérico que puede especializarse para una gran 
variedad de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, 
diferentes niveles de aptitud y diferentes tamaños de proyecto. Este proceso está basado en componentes 
interconectados a través de interfaces bien definidas. 
El Proceso unificado utiliza el Lenguaje de Modelado Unificado (UML) para preparar todos los esquemas 
de un sistema de software. Los aspectos definitorios del PU son: 
 
- Dirigido por casos de usos: Un sistema software dará servicio a sus usuarios, por tanto, debemos 
conocer lo que sus futuros usuarios necesitan y desean, ya que el usuario interactuará con el sistema. Una 
interacción de este tipo es un caso de uso. Un caso de uso es un fragmento de funcionalidad del sistema 
que proporciona al usuario un resultado importante. Los casos de uso representan los requisitos 
funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso, el cual describe la 
funcionalidad total del sistema. Debemos preguntarnos ¿Qué debe hacer el sistema….para cada usuario?, 
por eso los casos de uso guían el proceso de desarrollo, proporcionan un hilo conductor para el proceso. 
Aunque los casos de uso guían el proceso, se desarrollan conjuntamente con la arquitectura del sistema, y 
ambos maduran según avanza el ciclo de desarrollo. 
 
- Centrado en la arquitectura: El concepto de arquitectura incluye los aspectos estáticos y dinámicos 
más significativos del sistema. La arquitectura surge de las necesidades de la empresa, como la perciben 
los usuarios y los inversores, y se refleja en los casos de uso. Sin embargo, también se ve influida por 
muchos otros factores, como la plataforma en la que tiene que funcionar el software, los bloques de 
construcción reutilizables que se disponen, un marco de trabajo, consideraciones de implantación, 
sistemas heredados y requisitos no funcionales. La arquitectura es una vista del diseño completo con las 
características más importantes resaltadas, dejando los detalles de lado. 
Los casos de uso deben encajar en la arquitectura cuando se llevan a cabo, y la arquitectura debe permitir 
el desarrollo de todos los casos de uso requeridos, ahora y en el futuro. 
Los arquitectos modelan el sistema para darle una forma. La arquitectura debe diseñarse para permitir que 
el sistema evolucione en su desarrollo inicial y a lo largo de las futuras generaciones. Para encontrar esa 
forma, los arquitectos deben trabajar sobre la comprensión general de las funciones clave, es decir, sobre 
los casos de uso claves del sistema. 
Página 11 de 142 Autor: Adrián Botta 
 
 
- Iterativo e Incremental: Los desarrolladores basan la selección de lo que se implementará en una 
iteración en dos factores. En 1º lugar, la iteración trata un grupo de casos de uso que juntos amplían la 
utilidad del producto desarrollado hasta ahora. En 2º lugar, la iteración trata los riesgos más importantes. 
Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como quedaron al final de la 
última iteración. En cada iteración, los desarrolladores identifican y especifican los casos de uso 
relevantes, crean un diseño utilizando la arquitectura seleccionada como guía, implementan el diseño 
mediante componentes, y verifican que los componentes satisfacen los casos de uso. Si una iteración 
cumple con sus objetivos, el desarrollo continúa con la siguiente iteración. Sino, se prueba con un nuevo 
enfoque. Los beneficios de un proceso iterativo controlado son: 
- Reducción del coste de riesgo a los costes de un solo incremento 
- Reducción del riesgo de no sacar al mercado el producto en el calendario previsto 
- Acelera el ritmo del esfuerzo de desarrollo en su totalidad, ya que se obtienen resultados claros a corto 
plazo 
- Reconoce la realidad de que las necesidades del usuario y los requisitos no pueden definirse 
completamente al principio, sino que se refinan en iteraciones sucesivas. 
 
La vida del proceso unificado 
El Proceso unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. 
Cada ciclo consta de 4 fases: inicio, elaboración, construcción y transición (c/fase se subdivide en 
iteraciones). Cada ciclo produce una nueva versión del sistema, y cada versión es un producto preparadopara su entrega. El producto terminado incluye los requisitos, casos de uso, especificaciones no 
funcionales y casos de prueba. Incluye el modelo de la arquitectura y el modelo visual. 
Para llevar a cabo el siguiente ciclo de manera eficiente, los desarrolladores necesitan todas las 
representaciones del producto software. 
 
Todos estos modelos están relacionados. Juntos representan el sistema como un todo. Los elementos de 
un modelo poseen dependencias de traza hacia atrás y hacia delante, mediante enlaces hacia otros 
modelos. 
 
Fases dentro de un ciclo 
1- Fase de inicio: Se desarrolla una descripción del producto final a partir de una buena idea y se 
presenta el análisis de negocio para el producto 
2- Fase de Elaboración: Se especifican en detalle la mayoría de los casos de uso del producto y se 
diseña la arquitectura del sistema. El resultado de esta fase es una línea base de la arquitectura, y 
la disposición del director de planificar las actividades y estimar los recursos necesarios para 
terminar el proyecto 
3- Fase de Construcción: Se crea el producto. Aquí la línea base de la arquitectura crece hasta 
convertirse en el sistema completo. Al final de esta fase, el producto tiene todos los casos de uso 
que la dirección y el cliente han acordado para el desarrollo de esta versión. Sin embargo, puede 
tener defectos 
4- Fase de Transición: Cubre el periodo comprendido durante el cual el producto se convierte en 
versión beta. Esta fase corrige errores antes de la entrega. El equipo de mantenimiento divide los 
errores en 2 categorías: los que tienen suficiente impacto en la operación para justificar una 
versión incrementada y los que pueden corregirse en la siguiente versión normal. 
Modelo de casos de uso 
Especificado por Realizado por Distribuido por Implementado por Verificado por 
Modelo de 
Análisis 
Modelo de 
Diseño 
Modelo de 
Despliegue 
Modelo de 
Implementación 
Modelo de 
Prueba 
Página 12 de 142 Autor: Adrián Botta 
 
Página 13 de 142 Autor: Adrián Botta 
 
 
 
 
 
UNIDAD 2 
 
 
 
 
 
 
 
 
 
Autor: Adrián Botta - Año 2008 
Página 14 de 142 Autor: Adrián Botta 
 
 
Auditores, Control de Calidad y Departamento de normas o Estándares 
 
Analista de Sistemas 
 
Diseñadores de Sistemas 
 
Programadores 
 
Personal de Operaciones 
 
Usuarios 
 
 
 
 
 
Administradores 
Según Categoría de Trabajo 
o nivel de Supervisión 
 
 
 
Según nivel de Experiencia 
 
 Administradores Usuarios 
 Administradores de Informática 
 Administradores Generales 
 U. Operacionales 
 U. Supervisores 
 U. Ejecutivos 
 
 U. Amateur 
 U. Novato Presuntuoso 
 U. Experto 
 
 
 
 
 
 
 
 
 
 
 
 
1- Planificación 
 
 
 
 
 
 
 
 
 
 
 
2- Estimación de Costes y Plazos 
3- Seguimiento y 
Supervisión del 
Proyecto Software 
 
 
 
 
4- Gestión de 
Riesgos del Soft 
 
A) Definición del 
Ámbito del Software 
 
 
 
B) Plan de Proyecto 
 
 
 
Calendario 
 
 
 
 
 
 
Técnicas para 
Realizar 
Calendario 
 
C) Gestión de Compromisos 
 
 
 
 
 
1- Comparar los resultados actuales con planes previstos 
2- Tomar acciones correctivas cuando hayan desviaciones 
 
 
 Riesgos Estratégicos 
 Riesgos Comerciales 
 Riesgos Contractuales y financieros 
 Riesgos de Gestión 
 Riesgos de Proyecto 
 Riesgos de Explotación 
 Riesgos de Mantenimiento 
1- Obtención de la Inf. Necesaria 
2- Recursos (Humanos, de Software 
Reutilizable y de Entorno) 
3- La decisión Desarrollar-Comprar 
 
 
 
1- Def. de objetivos del proyecto 
2- Descomposición de las actividades 
3- Relación entre las actividades 
4- Estimación de los tiempos y costos de 
las actividades 
5- Reajuste del programa de tiempos a 
las restricciones del proyecto 
6- Asignación de recursos y definición de 
la organización del equipo 
7- Revisión del calendario 
 
 Diagrama de Hitos 
 Diagrama de Gantt 
 Full-Wall 
 Redes de Precedencia 
 
 
 
 
 
 
 
 
 
Participantes 
del Juego de 
los Sistemas 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Gestión de 
Proyectos de 
Software 
Página 15 de 142 Autor: Adrián Botta 
 
UNIDAD 2: 
PARTICIPANTES DEL JUEGO DE LOS SISTEMAS 
 
Usuarios: 
Es el participante más importante. El usuario es aquel (o aquellos) para quien se construye el sistema. Es 
la persona a la que tendrá que entrevistar, a fin de conocer las características que deberá tener el nuevo 
sistema para tener éxito. Se identifica al usuario también con el término “cliente”. Debemos recordar que 
el cliente siempre tiene la razón, y que es el cliente el que a fin de cuentas paga el sistema y usualmente 
tiene el derecho de rehusarse a pagar si no está conforme con el producto. 
En la mayoría de los casos es fácil identificar al usuario: es aquel que formalmente solicita un sistema. 
Pero hay un gran nº de situaciones en las que no se conoce la identidad del verdadero usuario o bien en 
las que hay poca oportunidad en que éste interactúe con el analista. El “verdadero” usuario pudiera 
nombrar a un representante para trabajar con el analista por estar demasiado ocupado personalmente con 
otros asuntos. Obviamente, en situaciones de este tipo, hay una gran posibilidad de malos entendidos: lo 
que el usuario quiere que el sistema haga, pudiera no serle comunicado de manera correcta al analista, y 
lo que éste crea que está construyendo para el usuario pudiera no serle comunicado tampoco de manera 
correcta, hasta que ya estuviera todo terminado, cuando ya sería demasiado tarde. 
Por lo tanto, como conclusiones, podemos decir que el analista debe en lo posible tratar de establecer 
contacto directo con el usuario; y de no ser posible, la documentación generada por el analista se vuelve 
aún más importante, para evitar reclamos futuros. 
 
Uno de los errores más comunes, es el de suponer que todos los usuarios son iguales. Se tiene la 
tendencia a pensar que son un grupo de humanos amorfo y homogéneo. 
Se clasifican en: 
 
 Clasificación de usuarios por categoría de trabajo o nivel de supervisión 
- Usuarios Operacionales: Son oficinistas, administradores y operadores que son los que más 
probablemente tendrán contacto diario con el nuevo sistema. Por eso, en una organización grande, 
se deberá entrevistar a secretarias, oficinistas, ayudantes, etc. En caso de un sistema de tiempo real, 
pudiera tener que hablar con usuarios operacionales como ingenieros, físicos, etc. Hay que tener en 
cuenta: 
1- Estos usuarios se preocupan mucho por la interfaz, y en menor medida, por las funciones que 
tendrá el sistema 
2- Estos usuarios tienden a poseer un panorama “local” del sistema, es decir, a menudo no están 
familiarizados en como encaja su trabajo en la organización global 
3- El analista puede tener que hablar con terminología familiar para estos usuarios 
- Usuarios Supervisores: Usualmente administran a un grupo de usuarios operacionales y son 
responsables de sus logros. Hay que tener en cuenta: 
1- Muchos son usuarios operacionales que han sido promovidos, por lo que se puede suponer que 
están de acuerdo con las necesidades, preocupaciones y perspectivas de los usuarios 
operacionales 
2- Se interesan en el nuevo sistema por la posibilidad de incrementar el volumen de trabajo 
realizado disminuyendo a la vez el costo de procesar las transacciones, y reduciendo también 
los errores en el trabajo 
3- El usuario supervisor ve al nuevo sistema como una forma de reducir el nº de usuarios 
operacionales. Esto es punto focal de batallas políticas en las que el analista suele quedar en 
medio. 
4- El U. Supervisor a veces actúa de intermediario entre el analista y el U. Operacional, 
aduciendo que estos últimos están muy ocupados 
5- El U. Supervisor a veces también tiene un panorama “local” 
Página 16 de 142 Autor: Adrián Botta 
 
6- El U. Supervisor será el que nos brindará el contacto cotidiano primario, y definirá los 
requerimientos y las políticas de la empresa que su sistema debiera realizar. 
- Usuarios Ejecutivos: Engeneral no se involucran directamente con el proyecto de desarrollo del 
sistema. Este usuario suele estar 2 o 3 niveles arriba de la acción asociada con el proyecto. 
1- Pueden proporcionar la iniciativa para el proyecto 
2- No se encuentran en posición que los permita definir los requerimientos del sistema para 
aquellos que lo están manejando cotidianamente. Como excepción tenemos un sistema de 
apoyo a las decisiones 
3- Los U. Ejecutivos se preocupan más por los detalles estratégicos y las ganancias/pérdidas a 
largo plazo. 
4- Los U. Ejecutivos se interesan más en el panorama global del sistema 
 
Se encuentra que algunos usuarios se resisten a la idea de tener un nuevo sistema, ya que les preocupa la 
pérdida de su empleo, o porque temen estar encadenados a una terminal todo el día, sin contacto con 
otros humanos 
 
 Clasificación de los usuarios por nivel de experiencia 
- Usuario Amateur: Jamás ha visto una computadora y exclama que no entiende todo este asunto de 
las computadoras. El problema con este usuario es que puede que encuentre difícil entender el 
lenguaje que el analista usa para describir las características, funciones y opciones que ofrece el 
nuevo sistema. 
- Usuario Novato Presuntuoso: Alega conocer exactamente lo que quiere que el sistema haga y 
suele señalar los errores que se cometieron en el sistema anterior. Cree que sabe por haber estado 
en un par de proyectos anteriormente. 
- Usuarios Expertos 
 
 Administración: 
La principal interacción entre el analista y todos los administradores tiene que ver con los recursos que se 
asignarán al proyecto. De aquí que finalmente el analista hará un documento que diga: “El nuevo sistema 
deberá llevar a cabo las funciones X, Y y Z, deberá desarrollarse en K meses, con no más de J 
programadores y con un costo máximo de R pesos”. Existen 3 tipos de administradores 
 Administradores Usuarios: Son administradores que están a cargo de varias personas en el área 
operacional donde se va a implantar el nuevo sistema. Desean sistemas que produzcan una variedad 
de informes internos y de análisis a corto plazo. 
 Administradores de informática: Son las personas encargadas del proyecto en sí de sistemas, y los 
administradores de nivel superior encargados de la administración global y distribución de los 
recursos de todo el personal técnico de la organización de creación o desarrollo de sistemas 
 Administración General: Pudiera ser el presidente de la organización o el jefe de finanzas. 
Generalmente se interesan por los sistemas de planeación estratégica y de apoyo a decisiones. 
Se debe tener en mente con los administradores: 
1- Cuanto más alto nivel ocupen, menos probable es que sepan de la tecnología de las computadoras, 
por lo que como analista, debe concentrarse en tratar de las características esenciales del sistema 
cuando esté hablando con ellos 
2- Las metas y prioridades de la administración pudieran entrar en conflicto con las de los usuarios, 
principalmente operacionales y supervisores 
3- A veces la administración no presta suficiente tiempo y/o recursos para que el sistema sea efectivo 
4- Dentro de la administración pueden haber distintos puntos de vista acerca de un nuevo sistema 
5- La administración a veces quiere apurar el proyecto 
 
 
 
Página 17 de 142 Autor: Adrián Botta 
 
 Auditores, Control de Calidad y Dpto. de Normas o Estándares: 
Se ha agrupado a estas personas en una sola categoría ya que su objetivo y perspectiva se parecen en 
general. El objetivo de este equipo es asegurar que su sistema se desarrolle de acuerdo con diversos 
estándares o normas externas (estándares de contabilidad, estándares de un dpto. de la organización, 
estándares del gobierno, etc.). 
Se debe prever: 
1- A menudo no se involucran sino hasta el final en el proyecto. A estas alturas es difícil hacer 
cambios importantes en el sistema 
2- A menudo están familiarizados con alguna notación o formato antiguos para documentación de 
requerimientos de sistemas (diagramas de flujo). Por eso es importante que los modelos que 
desarrolle sean comprensibles 
3- Los miembros de este grupo a menudo se interesan más en la forma de presentación que por el 
contenido: pueden llegar a rechazar un documento si no está como ellos quieren. 

 Analista de Sistemas: 
Este es usted. Los papeles que desempeña son: 
1- Arqueólogo y escribano: Descubrir detalles y documentar la política de un negocio que pudieran 
existir sólo como “tradiciones tribales”, transmitidas de generación en generación 
2- Innovador 
3- Mediador: Entre usuarios, administradores y otros participantes, los cuales a menudo están en 
desacuerdo entre sí sobre el nuevo sistema. Aquí el analista puede imponer su punto de vista con 
el arte de la diplomacia y negociación 
4- Jefe de Proyecto: Debido a la experiencia y a la tendencia natural. 
 
El analista, además, debe tener facilidad en el manejo de personas, tener conocimientos de aplicación, 
habilidad en computación, y obviamente, necesita una mente lógica y organizada. 
 
 Diseñadores de Sistemas: 
Es quien percibe los resultados del trabajo de análisis. La labor de él es transformar la petición, libre de 
consideraciones de tecnología, emanada de los requerimientos del usuario, en un diseño arquitectónico de 
alto nivel que servirá de base para el trabajo de los programadores. En muchos casos, el analista y 
diseñador son la misma persona, o el mismo grupo unificado de personas. Aún cuando son personas 
distintas, se deben mantener en contacto directo, provocando retroalimentación continua, ya que el 
analista tiene que ofrecer información detallada suficiente como para que el diseñador pueda elaborar un 
diseño tecnológicamente superior y el diseñador debe proveer suficiente información para que el analista 
pueda darse cuenta de si los requerimientos que el usuario está documentando son tecnológicamente 
posibles. Basándose en la inf. recibida, el analista posiblemente tendrá que negociar con el usuario para 
modificar otros requerimientos. 

 Programadores: 
Se puede argumentar que no habría contacto entre un analista y un programador, debido a que la labor del 
analista se hace primero y se termina por completo antes de que comience la programación. Esto significa 
que muy probablemente el analista estará incluso asignado a otro proyecto cuando el programador 
intervenga en el actual. 
Sin embargo, es posible que haya un contacto entre programadores y analistas: 
1- En los proyectos pequeños, analista, diseñador y programador suelen ser una sola persona 
2- El analista a veces sirve de administrador de proyecto 
3- El programador puede llegar a descubrir errores/ambigüedades en la propuesta de requerimientos 
entregada por el analista 
4- A veces se necesita mantenimiento de un sistema y nadie en la organización conoce los 
requerimientos del sistema debido a que no son las mismas personas que definieron los 
Página 18 de 142 Autor: Adrián Botta 
 
requerimientos del sistema anterior. Puede que el analista sea otro, y los que quedan del sistema 
anterior son los programadores. 

 Personal de Operaciones: 
Este personal va a definir las restricciones para el nuevo sistema: restricciones del tipo hardware, físicas, 
etc. Sin la aprobación del nuevo sistema por el personal de operaciones sólo se podrá construir un sistema 
independiente. Estos asuntos operacionales se documentan como parte de la tarea del análisis conocida 
como modelo de puesta en práctica o implantación del usuario. 
 
GESTIÓN DE PROYECTOS DE SOFTWARE 
 
El trabajo a través de proyectos es la forma habitual de actuación en el desarrollo de software. Un 
proyecto es un conjunto de etapas, actividades y tareas para alcanzar un objetivo que implica un trabajo 
no inmediato a un plazo relativamente largo. Precisamente es la división en trabajos más sencillos lo que 
permite al personal de proyecto dominar la complejidad del software que debe desarrollarse. 
Desarrollaremos a continuación la gestiónde proyectos a través de sus distintos procesos: planificación, 
dirección, organización y control. 
 
 PLANIFICACIÓN 
 
El objetivo es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de 
recursos, coste y planificación temporal. Estas estimaciones se hacen dentro de un tiempo limitado y 
debería actualizarse a medida que progresa el proyecto. 
 
A) Ámbito del Software 
La primera actividad de la planificación del proyecto de software es determinar el ámbito del software. Se 
deben evaluar la función y el rendimiento que se asignarán al software. El ámbito del software describe el 
control y los datos a procesar, la función, el rendimiento, las restricciones, las interfaces y la fiabilidad. 
Las consideraciones de rendimiento abarcan los requisitos de tiempo de respuesta y de procesamiento. 
Las restricciones identifican los límites del software originados por el hardware externo, por la memoria 
disponible y por otros sistemas existentes. 
1- Obtención de la información necesaria para el ámbito: La técnica utilizada es establecer una 
reunión o una entrevista preliminar. En la primera reunión entre un ingeniero de software y el 
cliente, ninguna persona sabe que decir o preguntar: ambos están preocupados por si lo que dicen es 
malinterpretado. Los 2 tienen expectativas diferentes: ambos quieren quitarse al otro de encima, 
pero quieren que todo salga bien. Sin embargo, se debe iniciar la comunicación. Se sugiere que el 
analista comience haciendo una serie de preguntas de contexto libre, es decir, que lleven a un 
entendimiento básico del problema. 
 El primer conjunto de cuestiones de contexto libre se centran en el cliente, en los objetivos globales 
y en los beneficios. Las preguntas siguientes permiten que el analista comprenda mejor el problema 
y que el cliente exprese sus percepciones sobre una solución. La última serie de preguntas se centra 
en la efectividad de la reunión. Estas preguntas (y otras) ayudarán a “romper el hielo” y a iniciar la 
comunicación esencial para establecer el ámbito del proyecto. Sin embargo, una reunión basada en 
preguntas y respuestas sólo se debería utilizar para el primer encuentro, reemplazándose 
posteriormente por un tipo de reunión que combine elementos de resolución de problemas, 
negociación y especificación. 
 Un grupo de investigadores independientes ha desarrollado un enfoque que alienta a la creación de 
un equipo compuesto de clientes y de desarrolladores que trabajen juntos para identificar el 
problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto 
preliminar de requisitos. 
Página 19 de 142 Autor: Adrián Botta 
 
2- Recursos: La segunda tarea de la planificación del desarrollo de software es la estimación de los 
recursos requeridos para acometer el esfuerzo de desarrollo de software. Hay 3 tipos de recursos que 
se debe verificar que estén disponibles: 
 Recursos Humanos 
 Recursos de software reutilizables: Hay 4 tipos. Componentes ya desarrollados, ya 
experimentados, con experiencia parcial (requerirán una modificación sustancial) y componentes 
nuevos. A la hora de reutilizar se debe evaluar: 
a) Si los componentes ya desarrollados cumplen los requisitos del proyecto, adquiéralos. El 
coste de la adquisición y de la integración serán casi siempre menores que el coste para 
desarrollar el software equivalente. Además, el riesgo es relativamente bajo. 
b) Si se dispone de componentes ya experimentados, los riesgos asociados a la modificación e 
integración, se aceptan. 
c) Si se dispone de componentes de experiencia parcial para el proyecto, su uso de debe 
analizar con detalle. 
 Recursos de Entorno: El entorno incorpora hardware y software. El hardware proporciona una 
plataforma con las herramientas software requeridas para producir los productos que son el 
resultado de una buena práctica de la ingeniería del software. 
3- La Decisión Desarrollar-comprar: Se debe evaluar en un árbol de decisiones, especificando 
riesgos y costos. Dentro de esto, se debe destacar el outsourcing o subcontratación. Aquí, las 
actividades de ingeniería de software se contratan con un tercero quien hace el trabajo a bajo coste, 
asegurando una alta calidad. El trabajo de software llevado dentro de la compañía se reduce a una 
actividad de gestión de contratos. La decisión de contratar fuentes externas puede ser estratégica o 
táctica, aunque a menudo es financiera. En el lado positivo, están los ahorros de costos que se 
pueden lograr al reducir el nº de personas e instalaciones. En el lado negativo, una compañía puede 
perder el control sobre el software que necesita, es decir, se corre el riesgo de poner el destino de la 
compañía en manos de un tercero. 
 
B) Plan de Proyecto 
Dentro del área de planificación de proyectos se deben cubrir 2 aspectos importantes: la realización de un 
plan de proyecto por parte del jefe de proyecto, y la gestión de compromisos. 
El director de proyecto es una persona que tiene la responsabilidad de planificar, controlar y dirigir las 
actividades del proyecto. Su primer cometido es el de realizar el plan de proyecto, un documento que 
describe los trabajos que se van a realizar y la forma en la que el director de proyecto va a dirigir su 
desarrollo. Independientemente del tamaño del proyecto, éste debe contener un plan que especifique 
aquello que hay que hacer, dónde y quién lo realizará. 
El plan de proyecto debe proporcionar un resumen del proyecto, ser orientado al cliente, actualizable, y 
permitir al director del proyecto y a los clientes supervisar el progreso del proyecto. El plan de proyecto 
debe incluir: resumen del proyecto, lista de hitos alcanzables, procedimientos y estándares que se van a 
aplicar, una especificación del proceso de revisión, un diagrama de descomposición del trabajo (WBS), 
una lista del personal del proyecto, una red de actividades, y presupuestos y calendarios para todas las 
actividades 
 
Director de Proyecto  Plan de proyecto  Plan de Desarrollo  Calendario 
 
 
Una de las partes del plan de proyecto es la determinación del plan de desarrollo. Éste es una 
representación gráfica de todas las actividades del proyecto necesarias para producir el resultado final que 
permite al director de proyecto coordinar de una forma efectiva al equipo de desarrollo durante el 
transcurso del mismo. El calendario es dinámico, y sin él, el control del proyecto se hace casi imposible. 
El control de proyecto se basa en la supervisión periódica y en la comparación de los resultados con los 
previstos en el calendario. Para que un programa de tiempos sea efectivo, debe ser comprensible, 
suficientemente detallado, capaz de señalar las actividades críticas, ser flexible, fácilmente modificable, 
Página 20 de 142 Autor: Adrián Botta 
 
basado en estimaciones de tiempos fidedignas, y compatible con los planes de otros proyectos que 
comparten los mismos recursos. 
 
Para desarrollar un calendario, es necesario realizar los siguientes pasos: 
 
1- Definición de objetivos del proyecto: Consiste en especificar los objetivos en términos 
cuantificables. Un objetivo de proyecto es un enunciado que especifica los resultados que se deben 
conseguir. Estas declaraciones forman el fundamento de todo el proceso de planificación, 
incluyendo el desarrollo del calendario. Para que un objetivo de proyecto quede bien definido, debe 
ser: 
 Asequible: El objetivo identifica una meta que puede conseguirse con unos tiempos y unas 
restricciones dadas 
 Definitivo: Especifica concretamente qué es lo que se debe lograr y en qué grado de detalle 
 Cuantificable: Especifica un criterio de finalización 
 De duración específica 
 
2- Descomposición de las actividades: Una 
vez que se han determinado los objetivos, el 
director de proyecto puede producir un 
diagrama de descomposición del trabajo 
(WBS). Es una técnica que permite 
representar las actividades que hay que 
realizar a distinto nivel de detallepor medio 
de un diagrama de estructuras. Para ello, en 
la parte superior se representa la actividad 
más general y, a continuación, se subdivide 
en actividades más sencillas. 
Inicialmente se identifican los paquetes de 
trabajo. Luego, las tareas necesarias para 
producir esos paquetes. Estas tareas, a su vez, pueden descomponerse en subtareas. Además de 
mostrar las tareas, se indican las personas responsables de su finalización (no figura en la imagen). 
Con este diagrama, el director de proyecto aumenta su capacidad de supervisión. 
 
3- Relación entre las actividades: Las actividades tienen que estar relacionadas, por lo que hay que 
determinar sus secuencias y dependencias. Para esto, se utilizan técnicas basadas en las redes de 
precedencia (como PERT), que permiten visualizar actividades críticas. 
 
4- Estimación de los tiempos y costos de las actividades: Es necesario realizar una estimación del 
tiempo que debe transcurrir entre el comienzo y el final de la actividad. Estas estimaciones se basan 
en el tiempo requerido para finalizar una actividad, y deben incluir los retrasos normales 
 
5- Reajuste del programa de tiempos a las restricciones del proyecto: Tiene como objetivos 
determinar la duración total del proyecto, identificar las actividades críticas y calcular las holguras 
de las actividades no-críticas. 
 
6- Asignación de los recursos/Definición de la organización del equipo: Consiste en ajustar el 
calendario respecto a los recursos disponibles. Para suavizar la posible carga de trabajo, el director 
de proyecto debe fijarse en todas las actividades que tengan holguras, y ajustar las fechas. Si no se 
puede hacer esto, se deberá aumentar la duración de las actividades críticas. 
 
7- Revisión del calendario: Para determinar si es o no realista. Se deben considerar los efectos de las 
revisiones técnicas y de gestión, los periodos vacacionales, los conflictos o las restricciones de 
recursos, etc. Debe asegurar que el calendario sea lo suficientemente flexible para acomodarse a 
retrasos no previstos 
 
Página 21 de 142 Autor: Adrián Botta 
 
Técnicas a utilizar en la realización del calendario 
 Diagrama de hitos: Es una tabla formada por 2 columnas: una en la que se señalan las 
actividades, y otra donde se indican sus fechas de finalización. Tiene como ventaja la facilidad de 
uso y el mínimo coste de preparación. Sus desventajas son la incertidumbre sobre las fechas de 
comienzo de las actividades y la imposibilidad de reflejar las interacciones entre ellas 
 Diagramas de Gantt: Es un diagrama de barras en forma de tabla, donde se hace una referencia 
cruzada entre las tareas (filas) y los tiempos de duración de las mismas (Columnas). Se utiliza en 
proyectos pequeños. No permiten representar las dependencias entre las actividades. 
 Programa de tiempos full-wall: En una sala de reunión se forma un cuadro en una pared en el 
que las líneas verticales representan semanas de trabajo, y las horizontales representan las 
actividades que debe hacer el equipo de proyecto. Cada actividad se escribe en 2 tarjetas, una de 
<inicio> y la otra de <final>. A cada miembro del equipo se le dan las tarjetas apropiadas y las 
clava en la pared en la semana de su elección. La disposición de tarjetas se modificará 
reiteradamente hasta que se hayan tratado todas las interacciones y restricciones de las 
actividades, y el calendario sea asequible. 
 Redes de precedencia (PERT y CPM): La red es un modelo gráfico que señala las relaciones 
secuenciales entre los sucesos clave en un proyecto. Pueden mostrar el camino crítico, que es la 
base para la planificación y el control. 
 
C) Gestión de compromisos 
Es importante que los directivos tomen las decisiones y adopten compromisos después de que el grupo de 
software haya emitido sus opiniones sobre si los compromisos se consideran o no factibles. Si los 
directivos se deciden a adoptar un compromiso poco factible, deben estar preparados para un posible 
aumento de los costes o un retraso en la fecha de entrega. 

 ESTIMACIÓN DE COSTES Y PLAZOS 
 
Ya que el software es un producto sin existencia física ni propia y cuyo coste principal reside en su 
desarrollo o diseño, es lógico que se asuma que el coste de su producción está dominado por los gastos de 
personal. Por eso, la principal unidad de medición de costo del proyecto suele ser el nº de salarios 
mensuales o anuales que deben pagarse. Los salarios suelen especificarse en personas-mes o personas-
año. 
La estimación en los proyectos de software tiene dificultades particulares (es inexacta), ya que es habitual 
desarrollar un nuevo producto cada vez, empleando distintas técnicas y herramientas. Además, algunas 
razones como las presiones políticas en la empresa, dificultan la estimación. 
Para una buena previsión de costos, es necesario invertir en la implantación de mecanismos para la 
recogida de datos que sirvan para mejorar las predicciones futuras, así como el desarrollo de métodos 
apropiados de estimación. 
En cualquier caso, se pretende responder a: ¿Cuánto costará? y ¿Qué plazo de tiempo requerirá su 
desarrollo? Todos los métodos actuales dependen de la cantidad de información disponible. A medida que 
se avanza en el proyecto, se dispone de más información, lo cual precisa más la estimación. Por ello, la 
estimación siempre debe ser un proceso continuo, con constantes refinamientos y mejoras. 
 
 SEGUIMIENTO Y SUPERVISIÓN DEL PROYECTO SOFTWARE 
 
Los objetivos que se pretenden conseguir con el seguimiento y supervisión son: 
1- Comparar los resultados actuales con los planes previstos 
Se han de desarrollar estándares que establezcan las condiciones o medidas que deben cumplirse cuando 
se realicen correctamente las diferentes tareas del proyecto; establecer sistemas de supervisión y de 
informes; y medir los resultados. 
Página 22 de 142 Autor: Adrián Botta 
 
El reto es utilizar las herramientas y las técnicas disponibles en forma efectiva, es decir, gestionar el 
esfuerzo de tal forma que el personal acepte los objetivos que debe cumplir dentro de unos tiempos y 
recursos dados. 
Algunos criterios a tener en cuenta para controlar los proyectos son: 
- Planificación detallada del proyecto 
- Descomponer el proyecto global en actividades y tareas (con WBS) 
- Definir los resultados entregables 
- Definir los hitos a realizar 
- Compromiso del personal 
- Seguimiento del proyecto 
- Medición de resultados 
- Revisiones regulares 
 
2- Tomar acciones correctivas cuando existan desviaciones significativas, y Acordar 
compromisos con el personal afectado por las acciones correctivas 
Las acciones correctivas se realizan y gestionan cuando los resultados reales se desvían 
significativamente de los planes. Aquí, los grupos y los individuos afectados llegan al acuerdo de los 
cambios en los compromisos. En general, las acciones correctivas pueden ser: añadir personal, reducir 
el alcance o el contenido de una entrega, y alargar/retrasar el calendario. 
 

 GESTIÓN DE RIESGOS DEL SOFTWARE 

Podríamos definir riesgo como cualquier elemento potencial que provoca resultados insatisfactorios en un 
proyecto. 
Debido al gran porcentaje de proyectos cancelados, entregados fuera de plazo, presupuestos excedidos, 
problemas operativos, conflictos con usuarios, etc., surge el tratamiento de los riesgos software como un 
factor importante en la realización de un proyecto. 
Las áreas típicas de riesgo que debe tratar un director de proyecto son las siguientes: 
 Riesgos estratégicos: Relacionados con la estrategia de la organización, pérdidas, beneficios, 
inversiones, etc. Ej: Pérdida de mercado, déficit 
 Riesgos comerciales: Problemas relacionados con la venta del proyecto, el seguimiento del 
cliente, el precio y las posibles actualizaciones. Ej: esfuerzo de venta desperdiciado, pérdida del 
cliente, vender por debajo del precio real 
 Riesgos contractuales y financieros: Relacionados con los términos contractuales negociadosantes de la firma del contrato, como penalizaciones, niveles de calidad, calendarios de pagos, etc. 
Ej: Pago de daños e intereses 
 Riesgos de Gestión: Relacionados con la organización de los proyectos, recursos, equipos, 
calendarios, subcontratistas, estimaciones, etc. 
 Riesgos de Proyecto: Causados por los aspectos técnicos del software: especificación, diseño, 
realización, integración y validación. 
 Riesgos de Explotación: Se refieren a fallos ocurridos durante el uso del software, los cuales 
pueden causar daños significativos, y eventualmente pueden ser peligrosos para la vida de las 
personas. Ej: Fallo del sistema que provoca accidente 
 Riesgos de Mantenimiento: Causados principalmente por sobrecostos en mantenimiento 
correctivo, preventivo y soporte 
 
Una vez identificados los riesgos que son significativos en el proyecto es necesario realizar un 
seguimiento y un control de éstos, y así dichos riesgos se reducen hasta niveles aceptables para el director 
del proyecto. 
Página 23 de 142 Autor: Adrián Botta 
 
 
 
 
 
 
UNIDAD 3 
 
 
 
 
 
 
 
 
 
Autor: Adrián Botta - Año 2008 
Página 24 de 142 Autor: Adrián Botta 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Formas de 
Captura de 
Requisitos 
 
 
 
 
 
 
 
 
 
 
 
 
 
Planeación 
 
 
 
 
 
 
Tipos 
 
 
Registro 
 
 
 
 
Participantes 
 
 
 
 
 
 
 
 
Usa Escalas 
 
 
 
 
 
 
 
 
Administración 
 
 
 
 
 
 
 
1- Entrevistas 
 
 
 
 
 
 
 
 
 
 
2- JAD 
 
 
 
 
 
 
 
 
 
 
3- Cuestionarios 
 
 
 
 
 
 
 
 
 
 
 
 
4- Observación 
Del tomador de 
Decisiones 
 
 
 
 
 
 
 
 
 
5- Muestreo 
 
1- Leer el material a fondo 
2- Establecer objetivos de la entrevista 
3- Decidir a quién entrevistar 
4- Preparar al entrevistado 
5- Decidir sobre 
 5.1- Tipos de Preguntas (Abiertas, Cerradas, 
 Averiguaciones) 
 5.2- Tipos de Estructuras (Pirámide, Embudo, Rombo) 
 
 Estructurada 
 No Estructurada 
 
 Grabador 
 Notas 
 
 Patrocinador Ejecutivo (Líder) 
 8 a 12 Usuarios 
 Analista en Sistemas 
 1 o 2 Observadores 
 1 escribano 
 
Tipos 
 
 
 
 
Evaluación 
 
 
 
Problemas 
1- Nominal 
2- Ordinal 
3- De intervalo 
4- De relación 
 Validez 
 Confiabilidad 
 Consistencia 
 Lenidad 
 Tendencia central 
 Efecto de Halo 
 
1- Reunir a todos los interlocutores involucrados 
2- Manejar cuestionarios personalmente 
3- Interlocutores manejan los cuestionarios 
4- Cuestionarios por correo 
 
Comportamiento 
 
 
 
Lenguaje Corporal 
 
 
Ambiente físico 
 
 
 
 
Diseño 
 
 
 
 
 
Inf. Buscada 
 
 Muestreo de tiempos 
 Muestreo de eventos 
 
 Pares de adjetivos y categorías 
 Guión del analista 
 
 
STROBE Elementos (7) 
 Estrategias (4) 
1- Det. Los datos a ser recolectados 
2- Det. La población a ser muestrada 
3- Seleccionar tipo de muestra (De conveniencia, 
Intencionadas, Aleatorias Simples/Complejas) 
4- Determinar tamaño de muestra 
Datos Impresos Cuantitativa 
 Cualitativa 
Datos Archivados 
Página 25 de 142 Autor: Adrián Botta 
 
 
 
 
 
 
 
 
 
 
 
 
Captura de 
Requisitos 
como Casos 
de uso 
 
 
 
 
 
 
 
 
 
1- Artefactos 
2- Trabajadores y responsabilidades 
3- Flujo de trabajo 
 Modelo de C.U (Actores y C.U) 
 Descripción de Arquitectura 
 Glosario 
 Prototipo de Interfaz con el Usuario 
 Modelo C.U 
 A. Sistemas Actor 
 Glosario 
 
 Especificador de C.U C.U 
 
 Diseñador de Prototipo de 
Interfaz de Usuario Interfaz 
 
 Arquitecto Descripción de 
 Arquitectura 
 
1- Encontrar actores y Casos de Uso 
 (En la unidad siguiente se desarrolla) 
2- Priorizar Casos de uso 
3- Detallar Casos de Uso 
4- Prototipar la interfaz de Usuario 
Página 26 de 142 Autor: Adrián Botta 
 
UNIDAD 3: 
 
ENTREVISTAS 
 
Antes de que entreviste a alguien, primero debe entrevistarse usted mismo. Necesita pensar a fondo la 
entrevista antes de ir a ella. Visualizar por qué está yendo, qué preguntará y qué es lo que constituirá una 
entrevista satisfactoria ante sus ojos. La otra mitad de esto es el individuo al que entrevistará. Debe 
anticipar cómo hacer que la entrevista sea satisfactoria también para él. 
 
Tipo de Información Buscada 
Una entrevista para la recolección de información es una conversación dirigida con un propósito 
específico que usa un formato de preguntas y respuestas. En la entrevista se quiere obtener la opinión del 
entrevistado y sus sentimientos acerca del estado actual del sistema, los objetivos de la organización, los 
personales y los procedimientos informales. Las opiniones del entrevistado pueden ser más importantes y 
más reveladoras que los hechos. Además, se debe tratar de capturar los sentimientos del entrevistado. 
Recuerde que el entrevistado conoce la organización mejor que usted. Usted puede comprender la cultura 
de la organización más a fondo escuchando los sentimientos de quienes responden. También se puede 
determinar el grado de optimismo existente. 
Los objetivos son información importante que puede ser recogida de las entrevistas. Los objetivos 
proyectan el futuro de la organización. Trate de encontrar tantos objetivos como sea posible a partir de las 
entrevistas. Tal vez no sea capaz de determinar los objetivos por medio de ningún otro método de 
recopilación de datos. 
En la entrevista, se necesita dar confianza y comprensión rápidamente, pero al mismo tiempo, se debe 
mantener el control de la entrevista. 
 
Planeación de la entrevista 
1- Leer el material a fondo acerca del entrevistado y su organización. Se debe prestar mucha 
atención en el lenguaje que usan los miembros de la organización. El objetivo es no perder el 
tiempo en la entrevista 
2- Establecer los objetivos de la entrevista: Consiste en determinar las áreas de la empresa que se 
van a relevar, y en que profundidad cada una. Estas áreas incluyen fuentes de información, 
formatos de información, frecuencia de toma de decisiones, cualidades de la información y estilo 
en la toma de decisiones 
3- Decidir a quién entrevistar: Se deben incluir personas clave de todos los niveles que serán 
afectados por el sistema en alguna forma 
4- Preparar al entrevistado: Avisándole con anticipación y permitiendo que el entrevistado tenga 
tiempo de pensar acerca de la entrevista. Las entrevistas deben durar entre 45 minutos y una hora, 
a lo sumo. 
5- Decidir sobre: 
5.1- Tipos de preguntas: 
 Preguntas Abiertas: Las opciones de respuesta del entrevistado pueden ser de 2 palabras o 2 
párrafos: están abiertas. Los beneficios, entre otros: pone confortable al entrevistado, permite 
al entrevistador conocer el lenguaje del entrevistado, permite más espontaneidad e interés. Las 
desventajas: mucho detalle relevante, pérdida de control en la entrevista. 
 Preguntas Cerradas: Las respuestas posibles son un nº finito. Los beneficios: se ahorra tiempo, 
se facilita la comparación de entrevistas, se mantiene el control, los datos son relevantes. Las 
desventajas: aburridas, pocos detalles, se pierde la relación armoniosa. 
 Averiguaciones: ¿Por qué? ¿Puede darme un ejemplo? Explique, etc. El objetivo es ir más allá 
de la respuesta inicial para aclarar, expandir un punto de vista. Las averiguaciones pueden ser 
de preguntas abiertas o cerradas. 
 
 
Página 27 de 142 Autor: Adrián Botta 
 
 Fallas en las preguntas: 
o Elusión de preguntas conducentes o conductoras (preguntas con respuesta predeterminada) 
o Elusión de preguntas dobles (2 preguntas en una) 
 
5.2- Tipos de Estructura 
 Pirámide: El entrevistador comienza con preguntas muy detalladas, cerradas, y va 
expandiendo luego los temas, permitiendo preguntas abiertas y respuestas más generalizadas. 
Se utiliza cuando el entrevistador necesita ambientarse en el tema, o cuando el entrevistado se 
resiste a entrar en tema 
 Embudo: Tiene un enfoque deductivo. Va de lo más general (abiertas) a lo más particular 
(cerradas). Es útil cuando el entrevistado se siente interesado acerca del tema y necesita 
libertadpara expresar sus emociones 
 Rombo: Es una combinación de las anteriores. Empieza de forma muy específica, luego 
examina temas generales, y por último se llega a una conclusión muy específica. Tiene como 
ventaja que conserva el interés y la atención del entrevistado. La desventaja es que lleva más 
tiempo. 
 
 Estructurada No estructurada Estructurada No estructurada 
Evaluación Fácil Difícil Flexibilidad Pequeño Grande 
Tiempo 
requerido 
Bajo Alto Control del 
entrevistador 
Alto Bajo 
Entrenamiento 
requerido 
Limitado Muy necesario Precisión Alto Bajo 
Permite 
espontaneidad 
Pequeño Mucha Confiabilidad Alto Bajo 
Perspicacia del 
entrevistado 
Muy Pequeño Mucha oportunidad Amplitud y 
profundidad 
Bajo Alto 
 
Registro de la entrevista 
Se realiza sobre los aspectos más importantes de la entrevista. El que se tomen notas o se use una 
grabadora de cinta depende, en parte, de a quién se está entrevistando y de lo que se hará con la 
información una vez que haya pasado la entrevista. 
 Grabadora de cinta: Tiene como ventajas que el registro es exacto, libera al entrevistador para 
escuchar y responder más rápidamente, permite mejor contacto visual, y permite una reproducción 
exacta de la entrevista para otros miembros del equipo. Tiene como desventajas que hace 
posiblemente inquietante la entrevista, la dificultad de buscar diálogos determinados en la cinta, y 
el relevamiento de datos. 
 Toma de Notas: Se utiliza cuando el entrevistado se rehúsa a la petición de la grabación en cinta. 
Tiene como ventajas que mantiene alerta al entrevistador, ayuda a recordar preguntas importantes, 
demuestra preparación e interés del entrevistador. Como desventajas, tenemos la pérdida de 
contacto visual y del hilo de la conversación, y un exceso de atención sobre los hechos. 
 
Antes y durante la entrevista 
Se debe vestir adecuadamente, ya que las respuestas del entrevistado están orientadas por su percepción 
inicial. Debe llegar temprano a la entrevista. Salude de mano y con firmeza al entrevistado, para 
establecer credibilidad y confianza. Recuérdele al entrevistado su nombre, y describa una vez más 
brevemente el motivo por el cual está ahí y el por qué escogió entrevistarlo. 
En cuanto se siente, tome inmediatamente la grabadora y/o su cuaderno de notas. Dígale al entrevistado lo 
que hará con los datos que recolecte y vuelva a afirmarle la confidencialidad. 
Al comenzar la entrevista, trate de captar el vocabulario y jerga. Mencione el tipo de detalle que le 
gustaría recibir en las respuestas. De vez en cuando, regrese algunas de las respuestas del entrevistado por 
Página 28 de 142 Autor: Adrián Botta 
 
medio de parafraseo o sumarización, para volver a confirmar que se comprendió lo que quería decir. Si en 
cualquier otro momento no está seguro, inmediatamente pida definiciones o aclaraciones. 
Al final de la entrevista, pregunte “¿Hay algo de lo que no hayamos hablado y que usted siente que es 
importante que yo sepa?”. Resuma y haga saber sus impresiones generales. Infórmele al entrevistado 
acerca de los pasos siguientes a tomar y qué es lo que harán a continuación con usted y otros miembros 
del equipo. Fije citas futuras para entrevistas de seguimiento, déle las gracias al entrevistado por haberle 
dado su tiempo y despídase con un apretón de mano. 
Tan pronto como sea posible se debe realizar la escritura del reporte de la entrevista. 
 
Diseño conjunto de aplicaciones (JAD) 
 
Inevitablemente experimentará situaciones donde las entrevistas persona a persona no parecen ser tan 
útiles como uno quisiera. Un enfoque alternativo a la entrevista de usuarios uno en uno, es el llamado 
Diseño conjunto de Aplicaciones (JAD). La motivación para el uso del JAD es reducir el tiempo (y por lo 
tanto el costo) requerido por las entrevistas personales, mejorar la calidad de los resultados de la 
valoración de requerimientos de información y la creación de más identificación del usuario con el nuevo 
sistema de información a consecuencia del proceso participativo. Además, con el JAD, se logran los 
requerimientos de análisis y diseño de la interfaz de usuario conjuntamente con los usuarios en un grupo. 
 
Condiciones que dan soporte al uso de JAD 
1- Los grupos de usuarios están impacientes y quieren algo nuevo, y no una solución estándar a un 
problema típico 
2- La cultura organizacional da soporte a los comportamientos de la solución de problemas en 
conjunto entre varios niveles de empleados 
3- Los analistas predicen que la cantidad de ideas generadas por medio de entrevistas persona a 
persona no será tan abundante con la cantidad de ideas posibles del ejercicio de un grupo amplio 
4- El flujo de trabajo organizacional permite la ausencia de personas importantes durante un bloque 
de tiempo de 2 a 4 días 
 
Quienes están involucrados 
Las sesiones de JAD incluyen una gran variedad de participantes, analistas, ejecutivos, etc. Que 
contribuirán con sus diferentes experiencias y aptitudes a las sesiones. 
 Un patrocinador ejecutivo: una persona de alto nivel que abra y cierre las sesiones de JAD. De 
preferencia, seleccione a un ejecutivo del grupo de usuarios que tenga algún tipo de autoridad sobre 
las gentes del sistema de información que están trabajando en el proyecto. Esta persona será un 
símbolo visible e importante de la disposición organizacional al proyecto de sistema. 
 8 a 12 usuarios de cualquier rango. 
 Al menos un analista de sistemas de información, pero tomando un papel pasivo, escuchando lo que 
dicen los usuarios y lo que requieren. Adicionalmente, se querrá dar una opinión de experto acerca 
de cualquier costo desproporcionado o soluciones propuestas durante la sesión. 
 El líder de la sesión debe ser alguien que tenga habilidades excelentes de comunicación para 
facilitar las interacciones adecuadas. 
 1 o 2 observadores que sean analistas o expertos técnicos de otras áreas funcionales para 
proporcionar explicaciones técnicas y consejos al grupo. 
 Un escribano para escribir formalmente todo lo que se hace. Asegúrese que el escribano publique el 
registro de los resultados de JAD rápidamente. 
 
Planificación de la sesión de JAD 
Se deben definir el alcance del proyecto, seleccionar los participantes, y el líder. 
Página 29 de 142 Autor: Adrián Botta 
 
Se recomienda que las sesiones se realicen de 2 a 4 días en un lugar aparte, fuera de la organización, en 
ambientes agradables. La idea es minimizar las distracciones y responsabilidades diarias del trabajo 
regular de los participantes. 
Dé la importancia adecuada a la creación de confort para los participantes. Disponga de suficiente comida 
y bebidas durante los cortes planeados. 
Calendarice las sesiones de JAD cuando todos los participantes puedan estar dispuestos a asistir. Esto es 
crítico para el éxito de las sesiones. 
Considere la realización de una reunión de orientación, con duración de medio día, una semana antes 
aproximadamente, para que los que estén involucrados sepan lo que se espera de ellos. Esto permite que 
usted se mueva rápidamente y actúe con confianza una vez que ha sido convenida la reunión actual. 
 
Logro de un análisis estructurado de las actividades del Proyecto 
Siendo el analista involucrado con las sesiones JAD, usted debe recibir las notas del escribano y preparar 
un documento de las especificaciones, basado en lo que sucedió en la reunión. Presente los objetivos de 
administración, así como el alcance y las fronteras del proyecto. 
 
Beneficios potenciales del uso de JAD en vez de entrevistas tradicionales 
1. Ahorro de tiempo sobre las entrevistas uno a uno 
2. Posibilidad de una propiedad mejorada de sistema de información, ya que el JAD involucra a los 
usuarios desde el principio en el proyecto de sistema, con lo cual tratan la retroalimentación 
seriamente 
3. Desarrollo creativo de los diseños: hay una “lluvia de ideas” 
 
Desventajas potenciales del uso de JAD 
1. Requiere la dedicación de un gran bloque de tiempopor parte de los 18/20 participantes 
2. Cuando la preparación de las sesiones JAD es inadecuada o cuando el reporte de seguimiento y la 
documentación es incompleta 
3. Las habilidades organizacionales necesarias y la cultura organizacional pueden no estar 
desarrolladas lo suficiente para el esfuerzo concertado que se requiere para ser productivo en un 
ambiente JAD 
 
CUESTIONARIOS 
 
Los cuestionarios permiten que los analistas estudien actitudes, creencias, comportamientos y 
características de varias personas principales en la organización que pueden ser afectadas por los sistemas 
actual y propuesto. Las actitudes son lo que la gente de la organización dice que quiere, las creencias son 
lo que la gente piensa que es, el comportamiento es lo que hacen los miembros de la organización y las 
características son propiedades de las personas o cosas. 
Mediante el uso de cuestionarios el analista puede estar buscando cuantificar lo que ha encontrado en las 
entrevistas. En forma inversa, los cuestionarios pueden ser usados para investigar a una gran muestra de 
usuarios de sistemas, para tratar de encontrar problemas o recoger cosas importantes antes de que las 
entrevistas sean realizadas. 
El desarrollo de un cuestionario útil requiere gran tiempo de planeación. Algunos lineamientos que 
ayudarán a decidir si es adecuado el uso de cuestionarios son: 
1- Las personas a preguntarles están dispersas 
2- En el proyecto de sistema está involucrada gran cantidad de personas y tiene sentido saber qué 
proporción de un grupo dado aprueba o desaprueba una característica particular del sistema 
propuesto 
3- Se está haciendo un estudio exploratorio y se quiere medir la opinión general antes de darle al 
proyecto de sistema una dirección específica 
Página 30 de 142 Autor: Adrián Botta 
 
4- Se desea asegurar que cualquier problema con el sistema actual esté identificado y atacado en las 
entrevistas de averiguación 
Una vez decidido a utilizar cuestionario, se puede comenzar a formular preguntas. En los cuestionarios, a 
diferencia de las entrevistas, es muy difícil refinar o aclarar preguntas dudosas. Lo que significa que las 
preguntas deben ser muy claras, el flujo de preguntas coherente, las preguntas del interlocutor anticipadas 
y la administración del cuestionario planeada a detalle. Recordemos que había 2 tipos de preguntas: 
 Preguntas Abiertas: En un cuestionario, se deben anticipar el tipo de respuesta que se va a 
obtener. Es importante que las respuestas que reciba sean capaces de una interpretación correcta. 
Este tipo de preguntas es adecuado para situaciones en las cuales se quiere obtener la opinión de 
los miembros de la organización acerca de algún aspecto del sistema. También se utilizan en 
situaciones exploratorias 
 Preguntas Cerradas: Deben ser usadas cuando el analista de sistemas sea capaz de listar 
efectivamente todas las respuestas posibles a la pregunta y cuando todas las respuestas listadas 
sean mutuamente excluyentes, para que la selección de una impida la selección de cualquier otra. 
Se deben usar para investigar a una gran muestra de personas, debido a la cantidad de datos que se 
obtendrán. 
Cabe desatacar que es muy importante la selección de palabras, ya que los interlocutores aprecian los 
esfuerzos de alguien que se preocupa por escribir un cuestionario que refleje su propio uso del lenguaje. 
Para confirmar si el lenguaje usado es el adecuado, puede probarlo sobre un grupo piloto. 
 
Uso de Escalas 
El escalamiento es el proceso de asignar números u otros símbolos a un atributo o característica con 
objeto de medir ese atributo o característica. Las escalas son frecuentemente arbitrarias y pueden no ser 
únicas. Se utilizan escalas para: 
 Medir las actitudes o características de quienes responden el cuestionario 
 Hacer que los interlocutores juzguen los temas del cuestionario 
Las escalas son medibles, y hay 4 formas diferentes para la medición: 
1- Escala Nominal: Son la forma más débil de medición. Sólo se pueden obtener totales. Ej: ¿Qué 
programa usa más? 1=Proc. Texto; 2=P. Cálculos; 3=BD 
2- Escala Ordinal: Permiten clasificación, implica ordenamiento de rango. Son útiles debido a que 
una clase es mayor o menor que otra. Ej: El personal de secretaría es: 1. Extremadamente útil; 2. 
Muy útil; 3.No muy útil; 4.Inútil 
3- Escala de Intervalo: Los intervalos entre c/u de los nº son iguales. Debido a esto, se pueden 
realizar operaciones matemáticas sobre los datos. 
Ej: ¿Qué tan útil es el soporte dado por el personal de Laboratorio? 
Inútil Extremadamente útil 
1 2 3 4 5 
4- Escala de Relación: No permite jerarquización, aunque dan una idea general. 
Ej: ¿Qué tantas horas usa la computadora? 0 2 4 6 8 
 
Validez y Confiabilidad: Hay dos mediciones de desempeño en la construcción de escalas: validez y 
confiabilidad. Validez es el grado con el cual la pregunta mide lo que el analista trata de medir. Ej: Si el 
objetivo del cuestionario es determinar si la org. se encuentra lista para un cambio, ¿mide eso las 
preguntas? 
 
 
Confiabilidad mide consistencia: Si el cuestionario fue administrado una vez, y luego nuevamente bajo 
las mismas condiciones se obtuvieron los mismos resultados, se dice que el instrumento tiene consistencia 
externa. Si el cuestionario contiene subpartes y estas tienen resultados equivalentes, se dice que tiene 
consistencia interna. Tanto la consistencia interna como la externa son importantes. 
 
Página 31 de 142 Autor: Adrián Botta 
 
Construcción de escalas 
Se presentan 3 problemas cuando se construyen escalas: 
1- Lenidad: Es cuando los interlocutores califican a la ligera. Se puede evitar moviendo la categoría 
“promedio” a la izquierda o derecha del centro 
2- Tendencia Central: Los interlocutores califican todo como promedio. Se puede arreglar creando 
escalas con más puntos, achicando diferencias, etc. 
3- Efecto de halo: Cuando la impresión formada en una pregunta se transporta a la siguiente pregunta 
 
Diseño y Administración del cuestionario 
Se debe poner mucha atención a esto para evitar que los interlocutores lo contesten a desgano o 
simplemente no lo contesten. 
Un cuestionario relevante y bien diseñado puede ayudar a superar algo de esta resistencia a responder. 
Algunas consideraciones: 
 Dejar bastante espacio en blanco 
 Dejar suficiente espacio para las respuestas 
 Pedir al interlocutor que encierre con un círculo las respuestas 
 Usar objetivos que ayuden a determinar el formato 
 Ser consistente en estilo 
 Guardar un orden en las preguntas 
 Colocar las preguntas importantes para los interlocutores al principio 
 Agrupar conceptos de contenido similar 
 Emplear las tendencias asociativas de los interlocutores 
 Poner primero los conceptos menos controvertidos 
Una vez diseñado el cuestionario, se deben determinar a los interlocutores. Hay que asegurarse de que 
haya suficientes interlocutores para permitir una muestra razonable en caso de que se pierdan 
cuestionarios o que sean llenados incorrectamente, y deban ser desechados. 
Existen 4 formas de administrar el cuestionario: 
1- Reunir a todos los interlocutores involucrados a la vez: No hay tiempo de espera y no se 
pierden cuestionarios. Sin embargo, tiene como desventaja la presión del grupo 
2- Manejar personalmente cuestionarios en blanco y recoger los llenos: Requiere mucho tiempo 
y suele haber escepticismo en las respuestas. 
3- Permitir a los interlocutores que administren el cuestionario por sí mismos y los depositen 
en una caja: Tiene como ventaja que las personas se sienten en el anonimato, pero sin embargo 
pueden perderse cuestionarios 
4- Enviar por correo los cuestionarios, con instrucciones para el retorno: Tiene muy baja tasa de 
respuesta 
 
 
OBSERVACIÓN DEL COMPORTAMIENTO DE LOS TOMADORES DE DECISIONES Y EL 
AMBIENTE DE OFICINA 
 
El analista examina los elementos físicos del espacio de trabajo del tomador para ver su influencia sobre 
el comportamiento del