En la mayoría de los desafíos técnicos, las métricas nos ayudan a entender tanto el proceso

técnico que se utiliza para desarrollar un producto, como el propio producto. El proceso para
intentar mejorarlo, el producto se mide para intentar aumentar su calidad.

El principio, podría parecer que la necesidad de la medición e s algo evidente. Después de todo es
lo que nos permite cuantificar y por consiguiente gestionar de forma más efectiva. Pero la realidad
puede ser muy deferente. Frecuentemente la medición con lleva una gran controversia y discusión.

1. ¿Cuáles son las métricas apropiadas para el proceso y para el producto?

2. ¿Cómo se deben utilizar los datos que se recopilan?
3. ¿Es bueno usar medidas para comparar gente, procesos o productos?

Estas preguntas y otras tantas docenas de ellas siempre surgen cuando se intenta medir algo que
no se ha medido en el pasado.

La medición es muy común en el mundo de la ingeniería. Medimos potencia de consumo, pesos,

dimensiones físicas, temperaturas, voltajes, señales de ruidos por mencionar algunos aspectos.
Desgraciadamente la medición se aleja de lo común en el mundo de la ingeniería del software.
Encontramos dificultades en ponernos de acuerdo sobre que medir y como va evaluar las medidas.

Hay varias razones para medir un producto.

1. Para indicar la calidad del producto.

2. Para evaluar la productividad de la gente que desarrolla el producto.
3. Par evaluar los beneficios en términos de productividad y de calidad, derivados del uso de
nuevos métodos y herramientas de la ingeniería de software.
4. Para establecer una línea de base para la estimación
5. Para ayudar a justificar el uso de nuevas herramientas o de formación adicional.

Las mediciones del mundo físico pueden englobarse en dos categorías: medidas directas y
medidas indirectas.

Medidas Directas. En el proceso de ingeniería se encuentran el costo, y el esfuerzo aplicado, las

líneas de código producidas, velocidad de ejecución, el tamaño de memoria y los defectos
observados en un determinado periodo de tiempo.

Medidas Indirectas. Se encuentra la funcionalidad, calidad, complejidad, eficiencia, fiabilidad,

facilidad de mantenimiento, etc.

MÉTRICAS DEL SOFTWARE.

Son las que están relacionadas con el desarrollo del software como funcionalidad, complejidad,
eficiencia.

MÉTRICAS TÉCNICAS: Se centran en lasa características de software pro ejemplo: la complejidad

lógica, el grado de modularidad. Mide la estructura del sistema, el cómo esta hecho.
MÉTRICAS DE CALIDAD: proporcionan una indicación de cómo se ajusta el software a los
requisitos implícitos y explícitos del cliente. Es decir cómo voy a medir para que mi sistema se
adapte a los requisitos que me pide el cliente.

MÉTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniería del

software. Es decir que tan productivo va a ser el software que voy a diseñar.

MÉTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e información sobre la forma

que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la
efectividad de las herramientas y métodos. Son las medidas que voy a hacer de mi personal que va
hará el sistema.

MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en que tiempo voy a terminar el software
y cuantas personas voy a necesitar. Son medidas directas al software y el proceso por el cual se
desarrolla, si una organización de software mantiene registros sencillos, se puede crear una tabla
de datos orientados al tamaño como se muestra en la siguiente figura:

La tabla lista cada proyecto del desarrollo del software de los últimos años correspondientes, datos
orientados al tamaño de c/u. Refiriéndonos a la entrada de la tabla del proyecto 999-01 se
desarrollaron 12.1 KLDC (miles de líneas de código) con un esfuerzo de 24 personas mes y un
costo de 168 mil dólares. Debe tenerse en cuenta que el esfuerzo y el costo registrados en la tabla
incluyen todas las actividades de la ingeniería de software como son análisis, diseño, codificación y
prueba. Otra información del proyecto 222-01 indica que se desarrollaron 365 paginas mientras
que se encontraron 29 errores tras entregárselo al cliente, dentro del primer año de utilización
también sabemos que trabajaron 3 personas en el desarrollo del proyecto.

En los rendimientos del sistema y los rudimentarios datos contenidos en la tabla se puede
desarrollar, para cada proyecto un conjunto de métricas sencillas de productividad y calidad
orientadas al tamaño. Se obtienen las siguientes formulas:

Productividad = KLDC/persona-mes

Calidad = errores/KLDC

Documentación = pags. Doc/ KLDC

Costo = $/KLDC
 • persona-mes es el esfuerzo

MÉTRICAS ORIENTADAS A LA FUNCIÓN. Son medidas indirectas del software y del proceso por
el cual se desarrolla. En lugar de calcularlas las LDC, las métricas orientadas a la función se
centran en la funcionalidad o utilidad del programa.

Las métricas orientadas a la función fueron el principio propuestas por Albercht quien sugirió un
acercamiento a la medida de la productividad denominado método del punto de función. Los
puntos de función que obtienen utilizando una función empírica basando en medidas cuantitativas
del dominio de información del software y valoraciones subjetivos de la complejidad del software.

Los puntos de función se calculan rellenando la tabla como se muestra en la siguiente figura:

Calculo de métricas de punto de función.

Se determinan 5 características del ámbito de la información y los cálculos aparecen en la posición

apropiada de la tabla. Los valores del ámbito de información están definidos de la siguiente
manera.

1. Números de entrada de usuario: se cuenta cada entrada del usuario que proporcione al
software diferentes datos orientados a la aplicación. Las entradas deben ser distinguidas
de las peticiones que se contabilizan por separado.
2. Numero de salida del usuario: se encuentra cada salida que proporciona la usuario
información orientada ala aplicación. En este contexto las salidas se refieren a informes,
pantalla, mensajes de error. Los elementos de datos individuales dentro de un informe se
encuentran por separado.
3. Números de peticiones al usuario: una petición esta definida como una entrada interactiva
que resulta de la generación de algún tipo de respuesta en forma de salida interactiva. Se
cuenta cada petición por separado.
4. Numero de archivos: se cuenta cada archivo maestro lógico, o sea una agrupación lógica
de datos que puede ser una parte en una gran base de datos o un archivo independiente.
5. Numero de interfaces externas: se cuentan todas las interfaces legibles por la maquina por
ejemplo: archivos de datos, en cinta o discos que son utilizados para transmitir información
a otro sistema.
Cuando han sido recogidos los datos anteriores se asocian el valor de complejidad a cada cuenta.
Las organizaciones que utilizan métodos de puntos de función desarrollan criterios para determinar
si una entrada es denominada simple, media o compleja. No obstante la determinación de la
complejidad es algo subjetivo.

Para calcular los puntos de función se utiliza la siguiente relación.

PF = CUENTA_TOTAL * [0.65 + 0.01 * SUM(fi)]

Donde CUENTA_TOTAL es la suma de todas las entradas de PF obtenidas de la tabla anterior.

Fi donde i puede ser de uno hasta 14 los valores de ajuste de complejidad basados en las
respuestas a las cuestiones señaladas de la siguiente tabla.

Evaluar cada factor en escala 0 a 5.

Los valores constantes de la ecuación anterior y los factores de peso aplicados en las encuestas
de los ámbitos de información han sido determinados empíricamente.

Una vez calculado los puntos de función se usan de forma analógica a las LDC como medida de la
productividad, calidad y otros productos del software.
Productividad = PF / persona-mes

Calidad = Errores / PF

Costo = Dólares / PF

Documentación = Pags. Doc / PF

La medida de puntos de función se diseño originalmente para ser utilizadas en aplicación de

sistemas de información de gestión. Sin embargo, algunas aplicaciones se les denomina puntos de
características.

La medida del punto de característica da cabida a aplicaciones cuya complejidad algoritmica es

alta. Las aplicaciones de software de tiempo real de control de procesos y de sistemas que
encontrados tienden a tener una complejidad algoritmica alta y por tanto fácilmente tratables por
puntos de características.

Para calcular los puntos de características, nuevamente se cuentan y ponderan los valores del
ámbito de información, como se describió anteriormente. Además, las métricas de punto de
característica tienen en cuenta otra característica del software, los algoritmos.

Un algoritmo se define como un problema de complejidad computacional limitada que se incluye

dentro de un determinado programa de computadora. La inversión de una matriz, la decodificación
de una cadena de bits o el manejo de una interrupción son todo ellos ejemplos de algoritmos.

Para calcular los puntos de característica, se utiliza la siguiente tabla.

Puntos de característica

Se usa único valor de peso para cada uno de los parámetros de medida y se calcula el valor del
punto característica global mediante la ecuación.
PF = CUENTA_TOTAL * [0.65 + 0.01 * SUM(fi)]

Debe tenerse en cuenta que los puntos de característica y los puntos de función representan lo
mismo. "funcionalidad o utilidad" en forma de software.

Actividades Obligatorias

Métricas orientadas al tamaño

Proyecto Esfuerzo $ KLDC Pag. doc Errores Gente

Farmacia 30 168,500 12,100 378 29 5
Hospital 60 578,300 39,443 921 540 20

• Calcular:

a) Productividad = KLDC/esfuerzo

 Hopital = ?
 farmacia = ?

b) Calidad = Errores/KLDC

 Hospital = ?
 Farmacia = ?

c) Costo = $/KLDC

 Hospital = ?
 Farmacia = ?

d) Documentación = Pags. doc/KLDC

 Hospital=?
 Farmacia=?

Métricas orientadas a la función

 • Se tiene un sistema el cual cuenta con 3 entradas de catalogo productos, proveedores y
clientes. Una pantalla de la elaboración de facturas, 4 tipos de reportes proporcionados
tanto en pantalla como en papel. Estas representaciones son: factura, lista de inventario,
estado de cuenta de los clientes y estado de cuenta con los proveedores. Además la
entrada de factura tiene alrededor de 30 peticiones, el sistema genra alrededor de 30
archivos además de estar conectado a un lector óptico y una impresora. Calcula los puntos
de función.

Factor de peso
Parámetro de medida Cuenta
medio
Numero de entradas al
4 * 4 = 16
usuario
Numero de salidas al
8 * 5 = 40
usuario
Numero de peticiones al
30 * 4 = 120
usuario
Numero de archivos 30 * 10 = 300
Numero de interfaces
2 * 7 = 14
externas
Cuenta total = 490

Contestación de las preguntas basada en la complejidad media

1=0; 2=5; 3=3; 4=5; 5=5;

6=5; 7=1; 8=5; 9=2; 10=2;

11=4; 12=0; 13=0; 14=4

• Fi =?
• PF = ?
• Productividad = ?
• Calidad = ?
• Costo = ?
• Documentación = ?

2.2 ESTIMACIÓN

Es una pequeña planeación sobre que es lo que va a ser mi proyecto. Una de las actividades
cruciales del proceso de gestión del proyecto del software es la planificación. Cuando se planifica
un proyecto de software se tiene que obtener estimaciones de esfuerzo humano requerido, de la
duración cronológica del esfuerzo humano requerido, de la duración cronológica del proyecto y del
costo. Pero en muchos de los casos las estimaciones se hacen valiéndose de la experiencia
pasada como única guía. Si un proyecto es bastante similar en tamaño y funciona un proyecto es
bastante similar en tamaño y funciona un proyecto pasado es probable que el nuevo proyecto
requiera aproximadamente la misma cantidad de esfuerzo, que dure aproximadamente lo mismo
que el trabajo anterior. Pero que pasa si el proyecto es totalmente distinto entonces puede que la
experiencia obtenida no sea lo suficiente.
Se han desarrollado varias técnicas de estimación para el desarrollo de software, aunque cada una
tiene sus puntos fuertes y sus puntos débiles, todas tienen en común los siguientes atributos.

1. Se han de establecer de antemano el ámbito del proyecto.

2. Como bases para la realización de estimaciones se usan métricas del software de
proyectos pasados.
3. El proyecto se desgloba en partes más pequeñas que se estiman individualmente.

2.3 PLANEACIÓN DEL PROYECTO

La planeación efectiva de un proyecto de software depende de la planeación detallada de su

avance, anticipado problemas que puedan surgir y preparando con anticipación soluciones
tentativas a ellos. Se supondrá que el administrador del proyecto es responsable de la planeación
desde la definición de requisitos hasta la entrega del sistema terminado. No se analizara la
planeación que implica a la estimación de la necesidad de un sistema de software y la habilidad de
producir tal sistema, la asignación de prioridad al proceso de su producción.

Los puntos analizados posteriormente generalmente son requeridos por grandes sistemas de
programación, sine embargo estos puntos son validos también para sistemas pequeños.

Panorama. Hace una descripción general del proyecto detalle de la organización del plan y resume
el resto del documento.

Plan de fases. Se analiza el ciclo de desarrollo del proyecto como es: análisis de requisitos, fase
de diseño de alto nivel, fase de diseño de bajo nivel, etc. Asociada con cada fase debe de haber
una fecha que especifique cuando se debe terminar estas fases y una indicación de como se
pueden solapar las distintas fases del proyecto.

Plan de organización. Se definen las responsabilidades especificas de los grupos que intervienen
en el proyecto.

Plan de pruebas. Se hace un esbozo general de las pruebas y de las herramientas,

procedimientos y responsabilidades para realizar las pruebas del sistema.

Plan de control de modificaciones. Se establece un mecanismo para aplicar las modificaciones

que se requieran a medida que se desarrolle el sistema.

Plan de documentación. Su función es definir y controlar la documentación asociada con el

proyecto.

Plan de capacitación. Se describe la preparación de los programadores que participan en el

proyecto y las instrucciones a los usuarios para la utilización del sistema que se les entregue.

Plan de revisión e informes. Se analiza como se informa del estado del proyecto y se definen las
revisiones formales asociadas con el avance de proyecto.

Plan de instalación y operación. Se describe el procedimiento para instalar el sistema en la

localidad del usuario.
Plan de recursos y entregas. Se resume los detalles críticos del proyecto como fechas
programadas, marcas de logros y todos los artículos que deben entrar bajo contrato.

Indice. Se muestra en donde encontrar las cosas dentro del plan.

Plan de mantenimiento. Se establece un bosquejo de los posibles tipos de mantenimiento que se

tienen que dar para futuras versiones del sistema.

ERRORES CLASICOS EN UN PROYECTO INFORMATICO.

1. Mal análisis en los requerimientos.

2. Una mala planeación.
3. No tener una negociación (documento, contrato) con el cliente.
4. No hacer un análisis costo beneficio.
5. Desconocer el ambiente de trabajo de los usuarios.
6. Desconocer los usuarios que trabajan con el sistema.
7. Mala elección de recursos (hardware, software, humanos).

3.1 LA INFORMACIÓN COMO UN RECURSO DE LAS ORGANIZACIONES.

A primeros de los años 60, simplemente se automatizaron funciones de negocio que previamente
se hacían manualmente. A medida que paso el tiempo, los programas individuales de computadora
se combinaron para componer aplicaciones de negocio. Las aplicaciones se agruparon en
sistemas de información principales que prestaban sus servicios a áreas de negocio especificas.

La información se ha colocado en un lugar adecuado como recurso principal. Los tomadores de

decisiones están comenzando a comprender que la información no es solo un subproducto de la
conducción, si no que a la vez alimenta a los negocios y puede ser el factor critico par la
determinación del éxito o fracaso de estos.

Para maximizar la utilidad de información, un negocio la debe manejar correctamente tal como
maneja los demás recursos. Los administradores necesitan comprender que hay costos asociados
con la producción, distribución, seguridad, almacenamiento y recuperación de toda información.
Aunque la información se encuentra a nuestro alrededor esta no es gratis y su uso es estratégico
para posicionar la competitividad de un negocio.

El manejo de la información generada por computadora difiere en forma significativa del manejo de
datos producidos manualmente. Por lo general, hay mayor cantidad de información generada por
computadora a administrar.

INGENIERÍA DE LA INFORMACION.

El objetivo global de la ingeniería de la información es aplicar tecnología de información de la mejor

manera que satisfaga las necesidades generales del negocio. Para conseguirlo la ingeniería de la
información debe empezar por analizar los objetivos y metas del negocio, después debe definir las
necesidades de la información de cada área de negocio y del negocio en su totalidad. Solo
después de hacer esto la ingeniería de la información hace la transición al dominio más técnico de
la ingeniería de software; el proceso, donde los sistemas de información, aplicaciones y programas
son analizados, diseñados y construidos.

El primer paso de la ingeniería de información es la planificación de la estrategia de la información

(PEI). Los objetivos generales del PEI son:

• Definir los objetivos y metas del negocio que sean estratégico.

• Aislar los factores de éxito critico.
• Analizar el impacto de la tecnología y automatización en las metas y objetivos.
• Analizar la información existente para determinar su papel en la consecución de las metas
y objetivos.

Los términos de objetivos y metas toman un significado especifico en la PEI. Un objetivo es una
declaración general de dirección. Las metas define un curso de acción cuantitativo. Los factores
críticos de éxito (FCE) pueden estar unidos a un objetivo o a una meta individual. Si se quiere
conseguir un objetivo o una meta debe estar presente un FCE.

El análisis del impacto tecnológico examina los objetivos y las metas y proporciona una indicación
de aquellas tecnologías que tendrán un impacto directo o indirecto en el éxito de su consecución.
El ingeniero de la información pondera las siguientes cuestiones:

• ¿Cómo es de critica la tecnología para el logra de un objetivo de negocio?

• ¿Esta disponible la tecnología actualmente?
• ¿Cómo modificará la tecnología el modo de hacer negocios?
• ¿Cuáles son los costes directos e indirectos?
• ¿Cómo debería el negocio adaptar o extender o objetivos y metas para adecuarse a la
tecnología?

Después de la PEI (planificación de la estrategia de información) se hace el análisis del área de

negocio (AAN). Durante el AAN, nuestro punto de mira se desplaza de la visión global a la visión
de dominio. El ingeniero de la información deber describir como se usan y transforman los objetos
de datos o conjunto de atributos (descritos durante la PEI y refinados durante el AAN) dentro de
cada área de negocio y como las funciones de negocio y los procesos dentro de cada área de
negocio transforman estos objetos de datos.

Los objetos de datos definidos durante la PEI se refinan para el uso dentro de cada área de
negocio. Por ejemplo, el objeto de datos cliente es empleado por el departamento de ventas.
Después de evaluar las necesidades del departamento de ventas, la definición original de cliente
se refina aun más para satisfacer las necesidades de ventas.

Objeto: Cliente

Atributos:

Nombre

Nombre de la compañía à objeto: Compañía

Clasificación del empleo y autorización de compra

Dirección de negocio e información de contacto

Interés de producto(s)

Compra(s) anterior(s)

Fecha de ultimo contacto --> registro de contactos

Estado del contacto -- > estado del ultimo contacto

--> Próxima fecha de contacto

--> Naturaleza recomendada de contacto

El atributo nombre de la compañía ha sido modificado para apuntar a otro objeto denominado
Compañía. Este objeto no sólo contiene le nombre de la compañía sino también otros atributos que
completan la información necesaria de ese objeto de datos.

Actividades obligatorias:

o Explique porque es importante la información.

o Mencione y explique los objetivos generales de la planeación estratégica de la
información.
o Ha decidido empezar un negocio con envío de ordenes por correo electrónico.
Como quiere llevar su negocio con eficacia, decide hacer algo de ingeniería de
información. Empiece por el PEI. Construya un sencillo modelo de empresa que
incluya un organigrama, esquemas de funciones y de los procesos de negocio y un
modelo de datos en el ámbito del negocio.
o Asumamos que una de las áreas del negocio que ha identificado para el negocio
de software por correo (actividad anterior) es el proceso de pedidos por teléfono.
Haga un AAN para desarrollar un modelo de datos y diagrama de flujo del proceso
detallado para esta área del negocio.

3.2 EL PAPEL DEL ANALISTA DE SISTEMAS

El analista de sistemas generalmente valora la manera que funcionan los negocios examinando la
entrada, el procesamiento de datos y la salida de información con el propósito de mejorar los
procesos organizacionales.

Muchas mejoras involucran mejor apoyo para las funciones de los negocios por medio del uso de
sistemas de información computarizados. Esta definición enfatiza un enfoque sistemático y
metódico para analizar, y posiblemente mejorar, lo que esta sucediendo con el contexto especifico
creado por un negocio.

Se requiere que los analistas de sistemas desempeñen muchos paquetes en el curso de su

trabajo. Algunos de estos papeles son:

1. Consultores externos para negocios.

2. Experto de soporte dentro de un negocio.
3. Agente de cambio en situaciones tanto internas como externas.
Los analistas poseen un amplio rango de habilidades. La primera y principal es que le analista
soluciona problemas, le gusta el reto de analizar un problema y encontrar una respuesta funcional.
Los analistas de sistemas requieren habilidades de comunicación que les permitan relacionarse en
forma significativa con muchos tipos de gente diariamente, así como habilidades de computación.
Para su éxito es necesario que se involucre el usuario final.

Los analistas proceden sistemáticamente. El marco de referencia para su enfoque sistemático es

proporcionado por lo que es llamado el ciclo de vida del desarrollo de sistemas (SDLC). Este puede
ser dividido en siete fases secuenciales, aunque en realidad las fases están interrelacionadas y
frecuentemente se llevan a cabo simultáneamente. Las siete fases son:

1. Identificación de problemas.
2. Oportunidades y objetivos
3. Determinación de los requerimientos de información
4. Análisis de las necesidades de sistemas
5. Diseño del sistema recomendado
6. Desarrollo y documentación del software
7. Prueba y mantenimiento del sistema e implementación del mismo.

Los paquetes de software basados en microcomputadora automatizado para el análisis y diseño de

sistemas son llamados herramientas CASE. Las cuatro razones para la adopción de herramientas
CASE son:

1. El incremento de la productividad del analista

2. La mejora de la comunicación entre analistas y usuarios
3. La integración de actividades del ciclo de vida y el análisis.
4. La valoración del impacto de los cambios por mantenimiento.

Los analistas también usan enfoque CARE (Reingeniería Asistida por Computadora) para hacer
ingeniería inversa y reingeniería de software para extender la vida del software legado.

Un enfoque nuevo y diferente al análisis y diseño de sistemas es el análisis y diseño de sistemas

orientados a objetos (O-O). Estas técnicas están basadas en conceptos de programación orientada
a objetos en los cuales los objetos, que son creados incluyen no solamente código acerca de los
datos sino también instrucciones acerca de las operaciones que se pueden realizar con ellos.

Cuando la situación organizacional lo demanda, el analista puede apartarse del SDLC para intentar
una metodología alterna, tal como la elaboración de prototipos, ETHICS, el enfoque de campeón
de proyecto, la metodología Soft Systems o Multiview.

COMPRENSIÓN DE LOS ESTILOS, ORGANIZACINES Y SU IMPACTO SOBRE LOS SISTEMAS

DE INFORMACION

Hay tres amplios puntos fundamentales de las organizaciones a considerar cuando se analizan y
diseñan sistemas de información. Estos son el concepto de la organización. Esos son el concepto
de la organización como sistema, los diversos niveles de administración y la cultura organizacional
general.

Las organizaciones son sistemas completos compuestos de subsistemas interrelacionados e

interdependientes. Además, los sistemas y subsistemas están caracterizados por su ambiente
interno, en un continuo que va desde abiertos a cerrados. Un sistema abierto permite el paso libre
de recursos (personas, información y materiales) a través de su frontera. Los sistemas cerrados no
permiten el libre flujo de entrada o salida.
Los diagramas entidad-relación ayudan a que le analista de sistemas comprenda las entidades y
relaciones que comprende el sistema organizacional. Los cuatro tipos diferentes de relaciones en
los diagramas E-R son: relación uno a uno, relación uno a muchos, relación muchos a uno y
relación muchos a muchos.

Los tres niveles de control administrativo son: operacional, medio y estratégico. El horizonte de
tiempo para la toma de decisiones es diferente para cada nivel.

Las culturas y subculturas organizacionales son determinantemente importantes sobre la manera

en que las personas usan la información y los sistemas de información. Apoyando los sistemas de
información y los sistemas de información. Apoyando los sistemas de información en el contexto de
la organización como un sistema más grande, es posible darse cuenta que numerosos factores son
importantes y deben ser tomados en cuenta cuando se determinen los requerimientos de
información y se diseña e implementa los sistemas de información.

DETERMINACIÓN DE LA FACTIBILIDAD Y EL MANEJO DE LAS ACTIVIDADES DE ANÁLISIS

Y DISEÑO

Los cuatro puntos fundamentales del proyecto que el analista de sistemas debe manejar son:

1. Iniciación del proyecto

2. Determinación de la factibilidad del proyecto
3. Calendarizacion del proyecto
4. Administración de los miembros del equipo del análisis de sistema.

Los proyectos pueden ser solicitados por muchas personas diferentes dentro del negocio o por los
mismos analistas de sistema.

La selección de un proyecto es una decisión difícil, debido a que serán solicitados más proyectos
de los que pueden ser hechos. Cinco criterios importantes para la selección de proyectos son:

1. Que el proyecto solicitado este respaldado por la administración.

2. Que tenga el tiempo adecuado para la asignación de recursos.
3. Que mueva al negocio hacia la obtención de sus objetivos.
4. Que sea practicable.
5. Que sea lo suficientemente importante para ser considerado en vez de otros
proyectos posibles.

Si un proyecto solicitado satisface estos criterios, entonces puede ser elaborado un estudio de la
factibilidad de sus méritos operacionales, técnicos y económicos. Por medio del estudio de
factibilidad los analistas de sistemas recopilan datos que permiten a la administración decidir si
continúan con un estudio de sistema completo.

La planeación del proyecto incluye la estimación del tiempo requerido por cada una de las
actividades del analista, su calendarización y la agilización de ellas, si es necesario para asegurar
que un proyecto sea terminado a tiempo. Una técnica de que dispone el analista de sistemas para
la calendarización de tareas es la gráfica de Gantt, que despliega actividades en forma de barras
en una gráfica.

La calendarización de proyectos basada en computadora, usando microcomputadoras, es ahora

practica común, debido principalmente al uso de interfaces de usuario gráficas. Adicionalmente. Se
pueden usar los administradores de información personales (PIM) por los analistas para planear,
crear deposito de números telefónicos y de fax y hasta para ejecutar otros programas.
Una segunda técnica, llamada PERT (evaluación de programas y técnicas de revisión), despliega
las actividades como flechas en una red. El PERT ayuda a que el analista determine la ruta critica y
el tiempo de holgura, que es la información requerida para el control efectivo del proyecto. Cuando
es necesario terminar un proyecto en menor tiempo, el analista puede reducir la duración total del
proyecto identificación y agilizando las actividades principales.

Una vez que un proyecto ha sido juzgado factible, el analista de sistemas debe administrar a los
miembros del equipo, sus actividades, tiempo y recursos. La mayor parte de esto se logra mediante
la comunicación con los miembros del equipo. Los equipos están constantemente buscando un
balance entre el trabajar sobre las tareas y el mantener las relaciones con el equipo. Deben ser
solucionadas las tensiones que suceden al intentar lograr este balance. Frecuentemente emergen
dos lideres en un equipo, un líder de tarea y un líder socioemocional. Los miembros deben valorar
periódicamente las normas del equipo para asegurarse de que sean funcionales en vez de
disfuncionales para el logro de los objetivos del equipo.

Es importante que le equipo de análisis de sistemas ponga objetivos de productividad razonables

para las salidas tangibles y las actividades del proceso. Las fallas del proyecto pueden ser
evitadas, por lo general, examinando las motivaciones de los proyectos solicitados, así como los
motivos del equipo para recomendar o evitar un proyecto particular.

3.3 ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN

3.3.1 TÉCNICAS DE RECOPILACIÓN DE INFORMACIÓN

Los analistas utilizan una variable de métodos a fin de recopilar los datos sobre una situación
existente, como entrevistas, cuestionario, inspección de registros y observación. Cada uno tiene
ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada
una y ayudar a asegurar una investigación completa. A continuación se verán cada una de ellas.

ENTREVISTA

Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que
propone el analista. Quienes responde pueden ser gerentes o empleados, los cuales son usuarios
actuales del sistema, existen usuarios potenciales del sistema propuesto o aquellos que
proporcionaran datos o serán afectadas por la aplicación propuesta. El analista puede entrevistar al
personal en forma individual o en grupos.

Recabar datos mediante la entrevista.

La entrevista es una forma de conversación, ¡no interrogación! Al analizar las características de los
sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre es sistema los
analistas pueden conocerlos datos que no están disponibles en ninguna otra forma.

En las investigaciones de sistemas, las formas cualitativas y cuantitativas de la información son

importantes. La información cualitativa esta relacionada con opiniones, políticas y descripciones
cuantitativas tratan con números, frecuencia o cantidades. A menudo las entrevistas dan la mejor
fuente de información cualitativa; los otros métodos tienden a ser mas útiles en la recabación de
datos cuantitativos.

Mucha gente incapaz de expresarse por escrito puede discutir sus ideas en forma verbal. Como
resultado de esto las entrevistas pueden descubrir rápidamente malos entendidos, falsas
expectativas o incluso resistencia potencial para las aplicaciones en desarrollo; mas aun a menudo
es más fácil calendarizar una entrevista con los gerentes del alto nivel, que pedirles que llenen
cuestionarios.

Determinación del tipo de entrevista.

La estructura de las entrevistas varia. Si el objetivo de la entrevista radica en adquirir información

general, es conveniente elaborar una serie de preguntas sin estructura, con una sección de
preguntas y respuestas libres. La atmósfera abierta y de fácil flujo de esta modalidad proporciona
una mayor oportunidad para conocer las actitudes, ideas y creencias de quien responde. Sin
embargo, cuando los analistas necesitan adquirir datos más específicos sobre la aplicación o
desean asegurar una alta confiabilidad en las respuestas a las preguntas que han propuesto a sus
entrevistados, las entrevistas estructuradas son mejores.

Las entrevistas estructuradas utilizan preguntas estandarizadas. El formato de respuestas para las
preguntas puede ser abierto o cerrado; las preguntas para respuesta abierta permiten a los
entrevistados dar cualquier respuesta que parezca apropiada. Con las preguntas para respuestas
cerradas se proporciona al usuario un conjunto de respuestas que se pueda seleccionar. Todas las
personas que responden se basan en un mismo conjunto de posibles respuestas.

La confiabilidad es solo una consideración en la selección del método de entrevista. Los analistas
también deben dividir su tiempo entre desarrollar preguntas para entrevistas y analizar las
respuestas. Las entrevistas no estructuradas requieren menos tiempo de preparación, porque no
se necesita tener por anticipado las palabras precisas de las preguntas. Sin embargo, analizar las
respuestas después de las entrevistas lleva más tiempo que con las entrevistas estructuradas. De
cualquier manera, el mayor costo radica en la preparación, administración y análisis de las
entrevistas estructuradas para preguntas cerradas.
Dado que un numero de personas se seleccionara para la entrevista, los analistas deben tener
cuidado de incluir aquellas personas que tienen información que no se podrá conseguir de otra
forma. Durante las primeras etapas de un estudio de sistemas, cuando los analistas determinan
La factibilidad del proyecto, con frecuencia las entrevistas solo se aplican a la gerencia o personal
de supervisión. Sin embargo, durante la investigación detallada en donde el objetivo es descubrir
hechos específicos, opiniones y conocer como se manejan las operaciones desempeñadas
actualmente, las entrevistas se aplican en todos los niveles gerenciales y de empleados y
dependen de quien pueda proporcionar la mayor parte de la información útil para el estudio. Así,
los analistas que estudian ala administración de inventarios pueden entrevistar a los trabajadores
del embarque y de recepción, al personal del almacén y a los supervisores de los diferentes turnos,
es decir, aquellas personas que realmente trabajan en el almacén; también entrevistaran a los
agentes más importantes.

Realización de la entrevista.

La habilidad del entrevistador es vital para el éxito en la búsqueda de hechos por medio de la
entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de la preparación
del objetivo de una entrevista especifica como de las preguntas por realizar a una persona
determinada.

El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista

exitosa. La falta de estos factores puede reducir cualquier oportunidad de éxito. Por ejemplo, un
analista que trabaja en la aplicación enfocada a la reducción de errores probablemente no tendría
éxito si llegar a una oficina de gerencia de nivel medio con la presentación equivocada, por
ejemplo, si dijera, "hola, fui enviado para encontrar una forma de mojar el rendimiento y de reducir
los errores que presentan aquí. O la introducción: "Estamos aquí para resolver su problema", es
igualmente mala. Es imaginable la rapidez con la que va a responder ser irrita y se molesta con un
enfoque de este tipo.

A través de la entrevista, los analistas deben preguntarse así mismos las siguientes interrogantes:

1. ¿Qué es lo que me esta diciendo la persona?

2. ¿Por qué me lo esta diciendo a mí?
3. ¿Qué se esta olvidando?
4. ¿Qué espera esta persona que haga yo?

Si se considera cada elemento de la información contra estas preguntas, los analistas tendrán mas
conocimientos no solamente de la información adquirida sino también de su importancia.

CUESTIONARIO.

Los cuestionarios proporcionan una alternativa muy útil para las entrevistas; sin embargo, existen
ciertas características que pueden ser apropiadas en algunas situaciones e inapropiadas en otras.

Recabación de datos mediante cuestionarios

Para los analistas los cuestionarios pueden ser la única forma posible de relacionarse con un gran
numero de personas para conocer varios aspectos del sistema. Cuando se llevan a cabo largos
estudios en varios departamentos, se puede distribuir los cuestionarios a todas las personas
apropiadas para recabar hechos con relación al sistema. Por supuesto, no es posible observar las
expresiones o relaciones de quienes responden a los cuestionarios.
También las preguntas estandarizadas pueden proporcionar datos más confiables. Por otra parte,
las características anteriores también son desventajas de los cuestionarios. Aunque su aplicación
puede realizarse con un mayor numero de individuos, es muy rara una respuesta total. Puede
necesitarse algún seguimiento de los cuestionarios para motivar al personal que responda; todas
las respuestas se encontraran en una proporción entre el 25 o 35%, que es lo más común.

Selección de formas para cuestionarios.

El desarrollo y distribución de los cuestionarios es caro; por lo tanto, el tiempo invertido en esto
debe utilizarse en una forma inteligente. También es importante el formato y contenido de las
preguntas en la recopilación de hechos significativos.

Existen dos formas de cuestionarios para recabar datos; cuestionario abierto y cerrados, y se
aplican dependiendo de si los analistas conocen de antemano todas las posibles respuestas de las
preguntas y pueden incluirlos. Con frecuencia se utilizan ambas formas en los estudios de
sistemas.

Cuestionarios abiertos.

Al igual, que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren
conocer los sentimientos, opiniones y experiencias generales; también son útiles al explorar el
problema básico, por ejemplo, un analista que utiliza cuestionarios para estudiar los métodos de
verificación de crédito, en un medio ambiente de ventas al a menudeo, podría recabar mas
información provechosa de una pregunta abierta de este tipo: ¿Cómo podría simplificarse y
mejorarse el proceso de verificación de crédito para los clientes?

Cuestionarios cerrados.

El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso
estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es el mejor
método para obtener información sobre los hechos. También fuerza a los individuos para que
tomen una posición y forma de opinión sobre los aspectos importantes.

Etapas en el desarrollo de un cuestionario

Los cuestionarios bien hechos no se desarrollan rápidamente, llevan tiempo y mucho trabajo. La
primera consideración se encuentra en determinar el objetivo del cuestionario. ¿Qué datos quiere
conocer el analista a través de su uso? El analista define como utilizar los cuestionarios a fin de
obtener los hechos al considerar la estructura mas útil para el estudio y la más sencilla de entender
por parte de los interrogados.

Lleva tiempo desarrollar preguntas bien elaboradas y deben siempre probarse y modificarse, si es
necesario, antes de que imprima una forma final y se distribuya.

Selección de quienes recibirán el cuestionario

Aquellas personas que reciban el cuestionario deben seleccionarse de a cuerdo con la información
que puedan proporcionar. Escribir o imprimir un cuestionario no significa que se pueda distribuir
ampliamente sin un análisis previo. Lo pueden contestar personas no calificadas y si el cuestionario
no es anónimo, y no será posible retirar sus respuestas de la muestra. La realización de esto
también es desgastante y cara.
 OBSERVACION

¡Ver es creer! Observar las operaciones le proporciona la analista hechos que no podría obtener de
otra forma.

Recopilación de datos mediante la observación

Leer en relación con una actividad del negocio le proporciona al analista una dimensión de las
actividades del sistema. Entrevistar personal, ya sea directamente o a través de cuestionarios,
también le ayuda y le dice algo más. Ninguno de los dos métodos da una información completa;
por ejemplo, leer en relación con un viaje en jet no reproduce la experiencia de volar a unos 30 mil
pies de altura.

La observación proporciona información de primera mano en relación con la forma en que se llevan
a cabo las actividades. Las preguntas sobre el uso de documentos, la manera en la que se realizan
las tareas y si ocurren los pasos específicos como se pre-establecierón, pueden contestarse
rápidamente si se observan las operaciones.

Cuando observar

La observación es muy útil cuando el analista necesita ver de primera mano como se manejan los
documentos, como se llevan a cabo los procesos y si ocurren los pasos especificados. Saber que
buscar y como guiar su significado, también requiere de experiencia. Los observadores con
experiencia captan quien utiliza los documentos y si encuentran dificultades; también están alertas
para detectar documentos o registros que no se utilizan.

MUESTREO

Con frecuencia, en muchas empresas la información ya se encuentra disponible para que el

analista conozca las actividades u operaciones con las cuales no esta familiarizado. Muchos tipos
de registros e informes son accesibles si el analista sabe donde buscar. En la revisión de registros,
los analistas examinan datos y descripciones que ya están escritos o registrados y en relación con
el sistema y los departamentos de usuarios. Esta forma de encontrar datos puede servir como
presentación del analista, si se realiza al iniciar el estudio, o como un termino de comparación de lo
que sucede en el departamento con lo que los registros presentan como lo que debería suceder.

Recopilación de datos por medio de la inspección de registros.

El termino "registro" se refiere a los manuales escritos sobre políticas, regulaciones y

procedimientos de operaciones estándar que la mayoría de las empresas mantienen como guía
para gerentes y empleados. Los manuales que documentan o describen las operaciones para los
procesos de datos existente, o sistemas de información que entran dentro del área de
investigación, también proporcionan una visión sobre la forma en la que el negocio debería
conducirse. Normalmente muestran los requerimientos y restricciones del sistema (como cantidad
de transacciones o capacidad de almacenamiento de datos) y características de diseño (controles
y verificación del procesamiento).
Los registro permiten que los analistas se familiaricen con algunas operaciones, oficinas de la
compañía y relaciones formales a las que debe darse apoyo. No obstante, no muestran como
producen de hecho las actividades, donde se ubica el poder verdadero para las decisiones, o como
se realizan las tareas en la actualidad. Los otros métodos con objeto de encontrar datos estudiados
en esta sección son más eficaces para proporcionar al analista este tipo de información.

Selección de los registros para revisión

En la mayor parte de las empresas los manuales de estándares sobre procedimientos de operación
usualmente son obsoletos; a menudo no se mantienen al corriente lo suficiente para señalar los
procedimientos existentes. Los diagramas de organización muestran como las diferentes unidades
deberían relacionarse con otras; pero muchas no reflejan las operaciones actuales.

PROTOTIPOS

El análisis hay que hacerlo independientemente del paradigma que se aplique. En algunos casos
es posible aplicar los principios operativos del análisis y obtener un modelo del software del que se
pueda desarrollar un diseño. En otras ocasiones se realizan recopilaciones de requisitos u otras
técnicas se aplican los principios del análisis y se construye un modelo del software a fabricar
denominado prototipo para que lo valore el cliente y el desarrollador. Finalmente hay circunstancias
que requieren la construcción de un prototipo al comienzo del análisis ya que el modelo es el único
medio a través del cual se pueden obtener eficazmente los requisitos. El modelo evoluciona
después hacia la producción del software.

SELECCIONE EL ENFOQUE DE CREACIÓN DE PROTOTIPOS

El paradigma de creación de prototipos puede ser cerrado o abierto. Al enfoque cerrado se

denomina a menudo prototipo desechable. Este prototipo sirve como una basta demostración de
los requisitos. Después se desecha y se hace una ingeniería de software con un paradigma
diferente. Un enfoque abierto denominado prototipo evolutivo, emplea el prototipo como primera
evaluación del sistema terminado.

Antes de poder elegir un enfoque abierto cerrado, es necesario determinar si se puede crear un
prototipo como primera evaluación del sistema terminado.

Se pueden definir varios factores candidatos para la creación de prototipos:

• área de aplicación
• complejidad
• características del cliente
• características del proyecto

En general cualquier aplicación que cree pantallas visuales dinámicas, interactue intensamente con
el ser humano o demande algoritmos o procesamiento de combinaciones que deba de manera
progresiva, es un buen candidato para la creación de prototipos. Pero sin embargo estas áreas de
aplicación deben ponderarse con la complejidad de la aplicación. Si una aplicación candidata va a
requerir el desarrollo de docenas de miles de líneas de código antes de poder realizar cualquier
función demostrable, es probable que sea demasiado compleja para la creación de un prototipo.
Como el cliente debe interactuar con el prototipo en fases posteriores, es esencial que:

1. Se destinen recursos del cliente a la evaluación y refinamiento del prototipo.

2. El cliente pueda tomar decisiones inmediatas sobre los requisitos.

MÉTODOS Y HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS.

Técnicas de cuarta generación. Estas comprenden una amplia gama de lenguajes de consulta y de
otros lenguajes no procedimentales de muy alto nivel. Como las técnicas de cuarta generación
permiten al ingeniero del software generar código ejecutable rápidamente son ideales para la
creación rápida de prototipos.

Componente de software reutilizables. El ensamblar mas que el construir, es un prototipo mediante

software existente. Un componente de software puede ser una estructura de datos o un
componente arquitectónico. En pocas palabras un software existente que cumpla con los requisitos
del cliente.

Especificaciones formales y entornos para prototipos. Durante las pasadas dos décadas, se han
desarrollado varios lenguajes formales de especificación y herramientas como sustitutos de las
técnicas de especificación con lenguaje natural.

Hoy en día los desarrolladores de estos lenguajes formales están desarrollando entornos
interactivos que:

1. Permitan al analista crear interactivamente una especificación basada en lenguaje de un

sistema o software.
2. Invoque herramientas automáticas que traducen la especificación basada en el lenguaje de
código ejecutable.
3. Permitan al cliente usar el código ejecutable del producto para refinar los requisitos
formales.

Métodos y herramientas para el desarrollo de los prototipos, para la selección de un enfoque

apropiado de creación de prototipo.
 3.4 ANÁLISIS ORIENTADO A OBJETOS

El análisis orientado a objetos esta basado en un modelo de cinco capas:

1. Capa clase/objeto.
2. Capa de estructura.
3. Capa de atributos.
4. Capa de servicios
5. Capa de tema.

La figura ilustra como se entrelazan estas cinco capas.

 1. Capa Clase/Objeto. Esta capa indica las clase y objetos.
2. Capa de Estructura. Esta capa captura diversas estructuras de clase y objetos, tales
como las relaciones uno a muchos y la herencia.
3. Capa de Atributos. Esta capa detalla los atributos de las clases.
4. Capa de Servicios. Esta capa indica los mensajes y comportamientos del objeto (servicios
y métodos).
5. Capa de Tema. Esta capa divide el diseño en unidades de implementación o asignaciones
de equipos.

Análisis y clases de objetos.

Objeto: es una abstracción de algo en un dominio de un problema que refleja las capacidades de
un sistema para llevar información acerca de ello, interactuar con ello a ambas cosas.

Es una representación en computadora de alguna cosa o evento del mundo real. Pueden tener
tanto atributos y comportamientos.

Clase. Es una categoría de objetos similares. Los objetos se agrupan en clases. Una clase define
el conjunto de atributos y comportamientos compartidos que se encuentran a cada objeto de la
clase.

Clase y objeto. Un término que se refiere tanto a clase como a los objetos que ocurren en la clase.

Hay cinco tipos generales de objetos que pueden descubrirse durante el análisis. Los objetos a
veces representan cosas tangibles como vehículos, dispositivos y libros. Algunas veces los objetos
representan papeles actuados por personas u organizaciones. Los objetos también pueden ser
derivados de incidentes o eventos. Otros objetos pueden indicar interacciones tales como una
venta o un matrimonio. Las interacciones tienen una cualidad de transacción o contrato. Los
objetos también pueden detallar especificaciones. Las especificaciones tienen estándares o una
cualidad de definición y, por lo general, implican que otros objetos representaran ocurrencias de
cosas tangibles.

Las clases son representadas por cuadros rectangulares redondeados (bubtángulos) divididos en
tres partes. El nombre de la clase se muestra en la división superior del cuadro. Las otras dos
divisiones se usan para las capas de atributo y servicio. Cuando una clase aparece sin objetos,
puede ser solamente una clase base, debido a que la única razón para tal clase "sin objetos" es
que sea un medio para agrupar atributos y servicios que serán heredados por varias otras clases.

Los objetos que tienen ocurrencia de una clase son representados por un cuadro sombreados
rodeado por la clase. Debido a que los objetos tiene ocurrencias de una clase.

Criterios que podemos usar para que nos ayuden a determinar si se justifica una nueva clase de
objetos:

1. Hay una necesidad de recordar el objeto. Esto es, el objeto puede ser descrito en un
sentido definido y sus atributos son relevantes para el problema.
2. Hay una necesidad de determinados comportamientos del objeto. Esto es, aunque un
objeto no tenga atributos, hay servicios que debe proporcionar o estados de objeto que
deben ser llamados.
3. Usualmente un objeto tendrá varios atributos. Los objetos que tienen solamente uno o
dos atributos sugieren diseños sobreanalizados.
4. Usualmente una clase tendrá mas de una instancia de objeto, a menos de que sea una
clase base.
5. Usualmente los atributos tendrán siempre un valor significativo para cada objeto de
la clase. Los objetos que producen valor NULO para un atributo, o para los que no es
aplicable un atributo, por lo general implican una estructura generalización-especificación.
6. Usualmente los servicios siempre se comportarán en la misma forma para todos los
objetos de la clase. Los servicios que varían dramáticamente para algunos objetos de una
clase o que regresan sin realizar acción para algunos objetos también sugieren una
estructura generalización-especificación.
7. Los objetos deben implementar requerimientos que son derivados del problema y no
de la tecnología de solución. La parte de análisis del proyecto orientado a objetos no
debe llegar a ser dependiente de una tecnología de implementación particular, tal como un
sistema de computadora especifico o un lenguaje de programación especifico. Los objetos
que atienden tales detalles técnicos no deben aparecer sino hasta muy tarde en la etapa
de diseño. Los objetos dependientes de la tecnología sugieren que el proceso de análisis
tiene fallas.
8. Los objetos no deben duplicar atributos o servicios que pueden ser derivados de
otros objetos del sistema. Por ejemplo, un objeto que guarda la edad de un empleado es
superfluo cuando existe un objeto de empleado separado que conserva el atributo fecha de
nacimiento. El objeto edad puede ser eliminado por un servicio edad que es componente
del objeto empleado.