UNIDAD II

GESTION DE UN PROYECTO DE SOFTWARE: MTRICAS, ESTIMACIN Y

PLANIFICACIN.

No es suficiente avanzar a travs de las etapas tradicionales del proceso de

construccin de software y esperar un producto satisfactorio al final del mismo. El
proceso de produccin de Software tiene que ser gestionado (administrado) y
dirigido de una manera extremadamente rigurosa y cuantitativa. De este modo se
podr verificar que el trabajo correspondiente a cada fase se ha realizado
completamente dentro de los plazos de tiempo y costo establecido y de acuerdo
con estndares especficos de calidad.
Por lo tanto, las claves del xito en la gestin de desarrollo se Software son: una
adecuada gestin del proyecto de desarrollo de Software y una adecuada gestin
del proceso de software.
2.1- Gestin de un proyecto
Qu entendemos por gestin del proyecto de desarrollo de Software?
La gestin del proyecto consiste en la utilizacin de las tcnicas y actividades de
gestin requeridas para conseguir un producto Software de alta calidad, de
acuerdo con las necesidades de los usuarios, dentro de un presupuesto y con una
planificacin de tiempos establecidos previamente.
Tareas Crticas en la Gestin de un Proyecto
El nmero de tareas identificables a realizar por un director de proyectos, dentro
del rea de gestin de proyectos excede de cien, Sin embargo, hay tres que son
crticas y que deben estar desarrolladas correctamente si se desea que el
proyecto termine bien.
Estas tareas son:
a) Estimacin de duracin, costo, y esfuerzo; necesario para construir el
producto.
b) Planificacin de tareas a realizar, asignacin de personas, tiempos, etc,
para construir el producto.
c) Seguimiento, durante la realizacin del trabajo, para asegurar el
cumplimiento de lo planificado en cuanto a costos, fechas, etc. En caso de
desviaciones del plan, se debe tomar las medidas pertinentes.

Estimacin

planificacin

Seguimiento

Desarrollo

Relacin entre las tareas de estimacin planificacin y seguimiento.

Gestin Eficaz
La gestin eficaz de un proyecto de Software se encuentra en tres pes :
personal, problema y proceso. El orden no es arbitrario.
Personal: La necesidad de contar con personal para el desarrollo del Software
altamente preparado y motivado con esencial para cualquier organizacin.
El problema: Antes de poder planificar un proyecto, se deberan establecer sus
objetivos, su mbito, se deberan considerar soluciones alternativas e identificar
las dificultades tcnicas y de gestin.
Si esta informacin, es imposible definir una estimacin razonable (y exactas ) del
costo, una valoracin efectiva del riesgo, una subdivisin realista de las tareas del
proyecto o una planificacin del proyecto asequible que proporcione una
indicacin fiable del progreso.
El proceso: Un proceso de Software proporciona la estructura desde la que se
puede establecer un detallado plan para el desarrollo del software.
Un pequeo nmero de actividades esenciales se pueden aplicar a todos los
proyectos de Software, sin tener en cuenta su tamao o complejidad.

A continuacin describiremos mas en fondo cada uno de estos componentes.

PERSONAL
Los participantes
El proceso del Software (y todos los proyectos de Software) lo componen
participantes que pueden clasificarse en una de cinco categoras:
1. Gestiones Superiores, que definen los aspectos de negocios que a
menudo tienen una significativa influencia en el proyecto.
2. Gestores (tcnicos)del proyecto que deben planificar, motivar, organizar, y
controlar a los profesionales que realizan el trabajo de Software.
3. Profesionales, que proporcionan las capacidades tcnicas necesarias para
la ingeniera de un producto o aplicacin.
4. Clientes, que especifiquen los requisitos para la ingeniera del software.
5. Usuarios finales, que interaccionan con el Software una vez que se ha
entregado para la produccin.
Todos los proyectos de Software est compuestos por los participantes apuntados
anteriormente. Para ser eficaz, el equipo del proyecto debe organizarse de manera
que maximice las habilidades y capacidades de cada persona. se es el trabajo
del jefe de equipo.
Los jefes de equipo
La gestin de un proyecto es una actividad intensamente humana, y por esta
razn, los componentes profesionales del Software a menudo no son buenos jefes
de equipo.
Qu es lo que buscamos cuando seleccionamos a alguien para dirigir un
proyecto de Software?
Motivacin.- Las habilidades para motivar (con un tira y arroja-) al personal
tcnico para que produzca conforme a sus mejores capacidades.
Organizacin.- Las habilidades para moldear procesos existentes ( o inventar
unos nuevos) que permita al concepto inicial transformarse en un proyecto final.
Ideas o innovacin.- La habilidad para motivar al personal para crear y sentirse
creativos incluso cuando deban de trabajar dentro de los lmites.
El xito de los gestores de proyectos se basa en aplicar un estilo de gestin en la
resolucin de problemas. Es decir, un gestor de proyectos de Software debera de
concentrarse en entender el problema que hay que resolver, gestionando el flujo
de ideas y, al mismo tiempo, haciendo saber a todos los miembros del equipo
3

(mediante palabras y mucho ms importante, con hechos) que la calidad es

importante y que no debe verse comprometida.
El equipo de Software
Existen casi tantas estructuras de organizacin de personal para el desarrollo de
Software como organizaciones que se dedican a ello. Para bien o para mal, el
organigrama no puede cambiarse fcilmente. Las consecuencias prcticas y
polticas de un cambio de organizacin no estn dentro del alcance de las
responsabilidades del gestor de un proyecto de Software. Sin embargo, la
organizacin del personal directamente involucrado en un nuevo proyecto de
Software est dentro del mbito del gestor del proyecto.
La mejor estructura de equipo depende del estilo de gestin de una organizacin,
el nmero de personas que compondr el equipo, sus niveles de preparacin y la
dificultad general del problema. Mantei [MAN81] sugiere tres organigramas de
equipo genricos:
Descentralizado democrtico (DD). Este equipo de ingeniera de Software no
tiene un jefe permanente. Ms bien, - se nombran coordinadores de tareas a corto
plazo y se sustituyen por otros para diferentes tareas- . Las decisiones sobre
problemas y los enfoques se hacen por consenso del grupo. La comunicacin
entre los miembros del equipo es horizontal.
Descentralizado controlado (DC). Este equipo de ingeniera de Software tiene
un jefe definido que coordina tareas especficas y jefes secundarios que tienen
responsabilidades sobre subtareas. La resolucin de problemas sigue siendo una
actividad del grupo, pero la implementacin de soluciones se reparte entre
subgrupos por el jefe del equipo. La comunicacin entre subgrupos e individuos es
horizontal. Tambin hay comunicacin vertical a lo largo de la jerarqua de control.
Centralizado Controlado (CC). El jefe del equipo se encarga de la resolucin de
problemas a alto nivel y la coordinacin interna del equipo. La comunicacin entre
el jefe y los miembros del equipo es vertical.
Mante describe siete factores de un proyecto que deberan considerarse cuando
se planifica el organigrama de equipos de ingeniera del Software:

La dificultad del problema que hay que resolver.

El tamao del programa resultante en lneas de cdigo o puntos de funcin
El tiempo en que el equipo estar junto (tiempo de vida del equipo)
El grado en que el problema puede ser modularizado.
La calidad requerida y fiabilidad del sistema que se va a construir
La rigidez de la fecha de entrega
El grado de comunicacin requerido para el proyecto.
4

EL PROBLEMA
El gestor de un proyecto de Software se enfrenta a un dilema al inicio de un
proyecto de ingeniera de Software. Se requieren estimaciones cuantitativas y un
plan organizado, pero no se dispone de informacin slida. Un anlisis detallado
de los requisitos del Software proporcionara la informacin necesaria para las
estimaciones, pero el anlisis a menudo lleva semanas o meses. An peor, los
requisitos pueden ser fluidos, cambiando regularmente a medida que progresa el
proyecto.
mbito de Software
La primera actividad de gestin de un proyecto de4 Software es determinar el
mbito del Software. El mbito se define respondiendo a las siguientes
cuestiones:
Contexto. Cmo encaja el software a construir en un sistema, producto o
contexto de negocios mayor y qu limitaciones se imponen como resultado del
contexto?
Objetivos de informacin. Qu objetos de datos visibles al cliente (Capitulo 11)
se obtienen del software?Qu objetos de datos son requeridos de entrada?
Funcin y rendimiento. Que funcin realiza el software para y transformar la
informacin de entrada en una salida? Hay caractersticas de rendimiento
especiales que abordar?
El mbito de un proyecto de Software debe ser univoca y entendible a niveles de
gestin y tcnico. Los enunciados del mbito del Software deben estar
delimitados.
Descomposicin del problema
La descomposicin del problema, denominado a veces particionado, es una
actividad que se asienta en el corazn del anlisis de requisitos del Software.
Durante la actividad de exposicin del mbito no se intenta descomponer el
problema totalmente. Ms bien, la descomposicin se aplica en dos reas
principales : (1) la funcionalidad que debe entregarse y (2) el proceso que se
emplear para entregarlo.

El PROCESO
Las fases genricas que caracterizan el proceso de Software definicin,
desarrollo, y mantenimiento- son aplicables a todo Software. El problema es
5

seleccionar el modelo de proceso apropiado para la ingeniera del Software que

debe aplicar el equipo del proyecto.
Maduracin del problema y el proceso
La planificacin de un proyecto empieza con la maduracin del problema y del
proceso, basndose en unos criterios de adaptacin. Todas las funciones que se
deben tratar de tratar dentro de un proceso de ingeniera por el equipo de
Software deben pasar por el conjunto de actividades estructurales que se han
definido para una organizacin de Software.
Descomposicin del proceso
Un equipo de Software debera tener un grado significativo de flexibilidad en la
eleccin del paradigma de ingeniera del Software que resulte mejor para el
proyecto y de las tareas de ingeniera del Software que conforman el modelo de
proceso una vez elegido.
La descomposicin del proceso comienza cuando el gestor del proyecto pregunta:
Cmo vamos a realizar esta actividad ECP?. Por ejemplo, un pequeo proyecto,
relativamente simple, requiere las siguientes tareas para la actividad de
comunicacin con el cliente:
1. Desarrollar una lista de aspectos que se han de clarificar
2. Reunirse con el cliente para resolver los aspectos que se han de
clarificar.
3. Desarrollar conjuntamente una exposicin del mbito del proyecto
4. Revisar el alcance del proyecto cuando se requiera
EL PROYECTO
Los veteranos profesionales de la industria a menudo se refieren a la regla 90-90
cuando estudian proyectos de Software particularmente difciles: El primer
noventa por ciento de un sistema absorbe el noventa por ciento del esfuerzo y
tiempo invertido. El ltimo diez por ciento se lleva el otro noventa por ciento del
esfuerzo y del tiempo asignado [ZAH94].
2.2 Estimacin
Problemtica del Proceso de Estimacin del Software
Para hablar de las posibilidades actuales de la estimacin, primero debemos
revisar su estado actual y explorar las necesidades de la comunidad de desarrollo
de Software.
Qu es la estimacin?
6

Vista desde el punto de vista de un diccionario, una estimacin es un conjunto

aproximado de valores para algo que ha de ser hecho. En el mundo de desarrollo
de Software, Larry Putnam ha apuntado que la gestin de desarrollo de Software
considera la estimacin como una actividad que permite obtener, principalmente,
respuestas aproximadas a las siguientes preguntas:
Cunto costar?
Cunto tiempo llevar hacerlo?
La respuesta a estas dos preguntas constituye el ncleo del tema que aqu se
contempla, sin embargo, y como se puede prever sta no es tan sencilla. Qu
hace que la estimacin no sea tan difcil de realizar.
Las razones para esta complejidad son las siguientes:
1. No existe un modelo de estimacin universal o una formula que pueda
ser usada para todas las organizaciones. El hecho en que se puedan
definir unos principios generales, pero cada interpretacin es particular y
diferente al resto. Cada organizacin tiene sus propios recursos,
procedimientos e historia; y es necesario ajustar los procesos de
estimacin a esos parmetros nicos. Adems, a medida que estos
parmetros cambien, deben cambiar los procesos de estimacin.
2. Hay muchas personas implicadas en los proyectos que precisan de
estimaciones. La alta direccin de la empresa necesita las estimaciones
para tomar decisiones de negocio sobre la viabilidad del proyecto y su
continuidad a lo largo del desarrollo. La direccin del proyecto necesita las
estimaciones para ser sugerencias a la alta direccin, para obtener los
resultados necesarios para el desarrollo del proyecto y, para hacer una
planificacin detallada y controlar el proyecto.
3. La utilidad de una estimacin tambin depender de la etapa de
desarrollo en ala que nos encontremos. Al comienzo de un proyecto,
normalmente slo se necesita estimaciones de costo y duracin
aproximadas. A medida que el proyecto madura las estimaciones que se
necesitan sern ms exactas. Con lo que una estimacin til al comienzo
del proyecto puede no serlo ms tarde.
4. La estimacin a menudo se hace superficialmente, sin apreciar el
esfuerzo requerido para hacer un trabajo. Adems tambin se suele dar el
caso de que la estimacin sea necesaria antes de obtener las
especificaciones de requisitos del sistema. Por esta razn, una situacin
tpica en que se presiona a los estimadores para que se apresuren en
escribir una estimacin anticipada del sistema que no comprenden an.
5. Las estimaciones claras, completas y precisas son difciles de
formular. Especialmente al inicio del proyecto. Los cambios, adaptaciones
y ampliaciones son ms la regla que la excepcin: como consecuencia de
ello, deben adaptarse tambin las planificaciones y los objetivos.

6. Las caractersticas de Software y de un desarrollo hacen difcil la

estimacin, por ejemplo, el nivel de abstraccin, la complejidad, el grado
de medicin del producto y del proceso, los aspectos innovadores....
7. La rapidez con la que cambia la tecnologa de la informacin y las
metodologas de desarrollo de Software son problema para la
estabilizacin del proceso de estimacin. Por ejemplo, son difciles de
predecir la influencia de nuevos bancos de pruebas, lenguajes de cuarta y
quinta generacin, estrategias de prototipado, y de tcnicas y herramientas
novedosas en general.
8. Un estimador no puede tener mucha experiencia de estimar desarrollos,
especialmente de proyectos largos. Cuntos proyectos largos puede
alguien dirigir en, por ejemplo, 10 aos?
9. Existe una tendencia aparentemente de los desarrolladores hacia la
subestimacin. Un estimador suele elegir una porcin de Software
debera tomar para luego extrapolarlo al resto del sistema, normalmente se
ignoran los aspectos no lineales del desarrollo de Software, por ejemplo, la
coordinacin y la gestin.
10. El estimador estima el tiempo que le llevara ejecutar personalmente una
tarea, ignorando el hecho de que, a menudo, una parte del trabajo la
realiza personal menos experimentado, con un ndice de productividad
menor.
11. Existen malas interpretaciones en las relaciones lineales entre la
capacidad requerida por unidad de tiempo y el tiempo disponible. Esto
significa que el Software desarrollado por 25 personas en dos aos podr
ser llevado acabo por 50 personas en un ao. Esta interpretacin es
errnea.
12. El estimador tiende a reducir en algn grado las estimaciones para
hacer ms aceptable la oferta.
13. Influyen un gran nmero de factores en el esfuerzo y duracin de un
desarrollo de Software. Estos factores se llaman drivers de costo o
disparadores de costo. Ejemplos de estos disparadores son el tamao y
complejidad del Software, el compromiso y participacin del usuario, la
experiencia del equipo de desarrollo. En general estos disparadores de
costo son difciles de determinar.
Al desarrollar sistemas se estiman con base a las siguientes consideraciones.

El producto Software que se tiene que desarrollar. QU

El significado de la produccin. CON QU
El personal de produccin. QUIN
La organizacin de produccin. CMO
Usuario/ organizacin del usuario. PARA QUIN

DIAGRAMA

#2

Requisitos que debe Cumplir un Buen Estimador

Quin debe realizar el proceso de estimacin de un proyecto de Software?
El estimador debe ser un profesional, que no tenga ningn inters, directo o
indirecto, en los resultados del proceso de estimacin y que est nicamente
guiado por su profesionalidad
El principal objetivo de un estimador es obtener unas estimaciones de calidad, las
cuales no siempre tienen por qu coincidir con las expectativas de la direccin en
trminos de costo y tiempo. Un buen estimador debera cumplir los siguientes
requisitos:
1. debe poseer una importante formacin y experiencia profesional que le
ayuden a entender y solucionar los problemas de la gestin de proyectos.
2. Debe tener una posicin en la organizacin que le permita adoptar un juicio
independiente.
3. Debe basarse en un mtodo que pueda ser explicado, cuestionado,
discutido y auditado por otros expertos.
4. Siempre que use una herramienta de estimacin, sta debe ajustarse a su
propsito de estimacin y debe soportar el mtodo. La herramienta tambin
debe estar documentada y controlada.
5. Debe ser capaz de describir su experiencia en cada estimacin. Es decir,
describir los problemas a los que ha tenido que enfrentarse, las soluciones,
etc.
6. Debe ser capaz de documentar su estimacin, incluyendo los resultados
obtenidos u cualquier informacin necesaria para hacer el proceso de
estimacin repetible y verificable.
Qu es lo que debemos estimar?
9

Cuando se hablo de la definicin de estimacin, se vieron dos preguntas a las que

este proceso deba dar respuesta. Estas preguntas eran:
Cunto costar?
Cunto tiempo llevar hacerlo?
Esta informacin constituye informacin bsica de todo proceso de estimacin.
Los distintos mtodos existentes para realizar este proceso proporcionan
informacin adicional para dar respuestas, en funcin del mtodo, a algunas de las
siguientes preguntas:
Cunta gente se necesita y que perfil debe de tener?
Cules son los riesgos?
Cmo afectan las restricciones impuestas a las estimaciones?
Cunto tiempo se necesita para realizar cada fase del ciclo de vida?
Cmo impacta este proceso en el resto de los proyectos de la empresa?
Cul ser el esfuerzo para mantener este proyecto?
Cul ser el tamao del sistema? (lneas de cdigo)
Cuntos defectos tendr el producto?
Cunta documentacin ser generada?
Cul ser el esfuerzo para confeccionar dicha documentacin?
2.3 Mtricas de Software
La medicin es fundamental para cualquier disciplina de ingeniera, y la ingeniera
del Software no es una excepcin.
Las mtricas del Software se refieren a un amplio elenco de medidas para el
Software de computadora. La medicin se puede aplicar al proceso de Software
con el intento de mejorarlo sobre una base continua.
Podemos definir las Mtricas de Software o Medidas de Software como:
La aplicacin continua de tcnicas basadas en las medidas de los procesos de
desarrollo de Software y sus productos, para producir una informacin de gestin
significativa y a tiempo. Esta informacin se utilizar para mejorar esos procesos y
los productos que se obtienen de ellos.
Las Mtricas de Software implican medir: medir involucra nmeros; el uso de
nmeros para hacer cosas mejor. Las Mtricas de Software pretenden mejorar los
procesos de desarrollo de Software y mejorar, por tanto, todos los aspectos de la
gestin de aquellos procesos.
Estas medidas son aplicables a todo el ciclo de vida del desarrollo, desde la
iniciacin, cuando debemos estimar los costos, al seguimiento y control de la

10

fiabilidad de los productos finales, y a la forma en que los productos cambian a

travs del tiempo debido a la aplicacin de mejoras.
Las medidas del Software y los modelos de medida son entonces tiles para
estimar y predecir costos y para medir la productividad y la calidad del producto.
Un ingeniero del Software recopila medidas y desarrolla mtricas para obtener
indicadores.
reas de Aplicacin
Algunas de las reas donde se aplican las mtricas de Software son:
El control de proyectos de desarrollo de Software a travs de medidas en
rea que esta generando un gran inters. Este es un tema que ha alcanzado
inters relevante con el incremento de contratos a precio fijo para desarrollar
producto Software y la utilizacin de clusulas de penalizacin en los mismos
caso de retrasos, sobrecostos, etc.

un
un
un
en

La prediccin de los niveles de calidad del Software, a menudo en trminos de

fiabilidad, es otra rea en que las Mtricas de Software tiene un importante papel
que jugar.
El uso de las Mtricas de Software es proporcionar una verificacin cuantitativa
del diseo de software es otra rea bien definida. Estas Mtricas no se van a
estudiar en esta Unidad si no en la Unidad de Diseo.
Recientemente se ha estudiado el efecto de los factores del entorno en la
eficacia de los procesos de desarrollo. Esta opcin no esta abierta para todas las
organizaciones, pero existe una gran preocupacin sobre como incrementar la
productividad de los procesos de desarrollo introduciendo cambios en el entorno
en el cual aquellos tienen lugar. Las medidas pueden ser utilizadas para identificar
donde deberan concentrarse los cambios.
La utilizacin de las Mtricas para comprar unas organizaciones con otras es
un rea de aplicacin muy importante. CSC- Index en Europa y el Software
Engineering Institute en E.E.U.U. ofrecen este tipo de servicios a la industria y
muchas organizaciones los utilizan. Un resultado de esta aplicacin es que se
puede identificar que se esta haciendo mal y quin lo esta haciendo bien y
aprender de esas empresas.
Finalmente, el uso ms comn de las medidas de Software es la provisin de
informacin de gestin, que incluye datos acerca de la productividad, calidad y
eficacia de los procesos.
El valor de esta informacin est en analizar los datos de las tendencias, da a
da. Est mejorando o empeorando la calidad de un equipo de desarrollo?. Si es
as, por qu ocurre? qu puede hacer la direccin para mejorar la situacin?

11

Caractersticas de las Mtricas de Software

La calidad de las medidas deberan facilitar el desarrollo de modelos que sean
capaces de predecir el comportamiento de determinados parmetros que afectan
al desarrollo de productos o procesos.
Una medida ideal debera ser :

Objetiva
Sencilla, definible con precisin para que puede ser evaluada
Fcilmente obtenible ( a costo razonable)
Valida, la mtrica debera medir exactamente lo que se quiere medir y no
otra cosa.
Robusta. Debera de ser relativamente insensible a cambios poco
insignificativos en el proceso o en el producto .

Adems, para una mejor utilizacin de estas medidas, a la hora de realizar

estudios analticos o anlisis estadsticos deberan de tener unos valores que se
ajusten a una cierta escala de medida.
Clasificacin de las Mtricas de Software
Las Mtricas de Software se pueden clasificar, de una manera general. En
Mtricas de producto y Mtricas de proceso.
Las Mtricas se Producto son medidas de producto Software durante cualquier
fase de su desarrollo desde los requisitos hasta la instalacin.
Las Mtricas de Producto pueden medir la complejidad del diseo, el tamao del
producto final (fuente u objeto) o el nmero de pginas de documentacin
producida.
Las Mtricas de Proceso son medidas del proceso de desarrollo del Software
tales como tiempo de desarrollo total, esfuerzo en das/ hombre o mes / hombre
de desarrollo del producto, tipo de metodologa utilizada o nivel medio de
experiencia de los programadores.

Mtricas de Productos
Muchos de los trabajos iniciales realizados sobre las mtricas de producto estn
relacionados con las caractersticas del cdigo fuente. Conforme se ha ido
ganando experiencias con las mtricas y los modelos se ha puesto de manifiesto
que la informacin disponible durante los primeros momentos del ciclo de
desarrollo puede ser de gran valor para controlar el proceso y los resultados.
12

Vamos a analizar, de todos los tipos de medidas utilizadas en la medicin del

producto Software, nicamente aquellas que nos interesen para realizar el proceso
de estimacin del Software, que sern las mtricas del tamao, y en cierto grado
las de calidad.
Mtricas del tamao
Las Mtricas del Software orientadas al tamao provienen de la normalizacin de
las medidas de `calidad y/o productividad considerando -el tamao - del Software
que se haya producido.
Existen un cierto numero de Mtricas que intentan cuantificar el tamao del
Software. La Mtrica ms utilizada, lneas de cdigo, tiene el inconveniente obvio
de que sus valores no pueden ser medidos hasta que el proceso de codificacin
ha finalizado. Los puntos de funcin, y los Bang de De Marco tienen las ventajas
de ser medibles durante los primeros pasos de desarrollo.
El estado actual en el estudio de las medidas del tamao es:

Existe un cierto consenso en cuanto a las medidas de longitud, pero no

en cuanto a las medidas de las especificaciones o diseo.
Existen algunos trabajos de medicin de las funcionalidades de las
especificaciones ( que se aplican igualmente al diseo y a los programas)
Existen muy pocos trabajos en cuanto a la medida de la complejidad del
problema a resolver . Ntese que este concepto es distinto que el de
complejidad computacional, por tanto el trabajo hecho en esa rea no sirve.

A continuacin, vamos a analizar las medidas mas utilizadas en la

determinacin del tamao del Software.
A) Lneas de Cdigo: La medida mas utilizada de la longitud del
cdigo fuente de un programa es el Numero de Lneas de Cdigo
( Lines of Code en Ingls, abreviado LOC).
Sin embargo esta mtrica puede calcularse de muchas maneras. Estas
diferencias afectan ala tratamiento de la lneas en blanco y las lneas de
comentarios, las sentencias no ejecutables, las instrucciones mltiples
por lnea y las mltiples lneas por instruccin.
Adems, deberan contarse las lneas reusables del cdigo
Cuando se intenta utilizar esta medida (lneas de cdigo) en trminos
de productividad surgen dos problemas.
A) No se tiene en cuenta el concepto de reutilizacin.

13

B) No se tiene en cuenta el concepto de costos fijos ni tareas que se

desarrolla que no produce instrucciones
b) Especificacin del Diseo La definicin de medidas anlogas a la longitud
para las especificaciones y los documentos de diseo no es fcil. Al comienzo del
ciclo de vida, tales documentos consisten en una infinidad de texto, grafos,
diagramas matemticos, y smbolos. La naturaleza de aquellos depender en
particular del estilo el mtodo o la notacin utilizada. Unas especificaciones o un
diseo, estn compuestos por textos o diagramas, los cuales parecen inmedibles
con relacin a la longitud.
Una medida que se ha utilizado para permitir las comparaciones es la del Numero
de Paginas. Sin embargo, la unidad pgina no puede ser formalmente definida si
se desea incluir textos y diagramas.
c) Prediccin de la longitud: Existen una serie de modelos que veremos
mas adelante para la prediccin del costo que dependen de la habilidad
para predecir la longitud ( NLOC) con exactitud con la fase de definicin de
especificaciones del sistema a implantar.
Un modo intuitivo de predecir la longitud es obteniendo una relacin entre la
longitud de diferentes productos obtenidos durante el ciclo de vida. En particular,
una prediccin de longitud, se puede obtener considerando la relacin ratio de
expansin entre la longitud de las especificaciones o del diseo y la longitud del
Cdigo en proyectos similares en los que se mantienen datos.
Ha habido algunos intentos para establecer relaciones empricas entre la longitud
del cdigo de programas y la longitud de la documentacin.
d) Funcionalidad: El concepto de funcionalidad de un producto se origina a
partir de una nocin intuitiva de cantidad de funciones que proporciona.
Ha habido dos intentos serios para medir la funcionalidad de un producto de
Software. Uno de ellos se debe a Albrecht y corresponde a los Puntos de Funcin
(FPA, del ingls Function Point Anlisis) y otro debido a de De Marco, los Bang,
que no ha tenido una gran difusin.
El objetivo ms importante es identificar una medida del tamao de Software que
pueda ser la variable predominante en los sistemas de prediccin de costos y
esfuerzo, as como en la evaluacin de la productividad. Este es un objetivo
encomiable, ya que una medida de la funcionalidad sera claramente preferible a
la medida del tamao exclusivamente de la longitud. En ambos casos, los
productos cuya funcionalidad est siendo medida con documentos de
especificacin, pero que podran aplicarse posteriormente a otros productos del
ciclo de vida. La funcionalidad, a pesar de los problemas existentes, es un atributo
muy importante del producto y es la mejor aproximacin existente hasta la fecha.

14

Mtricas de Calidad
El objeto primordial de la ingeniera del Software es producir un sistema,
aplicacin o producto de alta calidad. Para lograr este objetivo, los ingenieros del
software deben aplicar mtodos efectivos con herramientas modernas dentro del
contexto de un proceso maduro de desarrollo del Software.
Se puede generar una larga lista de caractersticas de la calidad de Software:
correccin,
eficacia,
portabilidad,
mantenibilidad,
fiabilidad,
etc.
Desafortunadamente, las caractersticas a veces se solapan y entran en conflicto
unas con otras. Por ejemplo, incrementar la portabilidad, que es muy deseable,
puede dar lugar a una eficacia menor.
Aunque se han realizado una gran cantidad de trabajos en est rea, presenta una
gran variedad en los caminos seguidos frente a otras reas de investigacin de las
mtricas, tales como el tamao del Software o la complejidad, cuyo estudio ha
sido ms uniforme.
Han tenido considerable atencin tres reas:

Correccin de los programas, medida como el nmero de efectos. Un

programa debe operar correctamente o proporcionar poco valor a sus
usuarios. La correccin es el grado en el que el Software lleva a cabo su
funcin requerida.
Fiabilidad del Software, calculada partir del dato anterior. En est poca
de intrusos informticos y de virus, la integridad del software ha llegado ha
tener mucha importancia. Este atributo mide la habilidad de un sistema para
resistir ataques ( tanto accidentales como intencionales ) contra su
seguridad. El ataque se puede realizar en cualquiera de los tres
componentes del Software, programas, datos, y documentos.
Mantenibilidad del Software, que se mide a partir de otro conjunto de
mtricas, incluidas las de complejidad: La facilidad de mantenimiento es la
facilidad con la que se puede corregir un programa si se encuentra un error,
se puede adaptar si su entorno cambia, o mejorar si su cliente desea un
cambio de requisitos.

La calidad del software es una caracterstica que, tericamente al menos, puede

ser medida en cada fase del ciclo de desarrollo del Software.

Mtricas de Procesos
Estas mtricas evalan el proceso en s de fabricacin del producto
correspondiente. Ejemplos de este tipo de mtricas son el tiempo de desarrollo del
producto, el esfuerzo que conlleva dicho desarrollo, el nmero y tipo de recursos
empleados (personas, mquinas, etc) el costo del proceso. La obtencin de este

15

tipo de mtricas esta asociada generalmente a alguna tcnica de estimacin. En

el siguiente tema describiremos las tcnicas bsicas de estimacin, y los mtodos
que se pueden aplicar.
Integracin de las Mtricas dentro del Proceso de Software
La mayora de los desarrolladores de Software todava no miden, y por desgracia,
la mayora no desean ni comenzar.
Por qu es tan importante medir el proceso de ingeniera de Software y el
producto (Software) que produce?. La respuesta es relativamente obvia. Si no se
mide, no hay una forma real de determinar s se est mejorando. Y si no se est
mejorando, se est perdido.
Mediante el uso de la medicin para establecer una lnea base del proyecto, cada
uno de estos asuntos se hace ms fcil de manejar. Ya hemos apuntado que la
lnea base sirve como base de la estimacin. Adems, la recopilacin de mtricas
de calidad permite a una organizacin sintonizar- su proceso de ingeniera del
Software para eliminar las causas poco vitales- de los defectos que tienen el
mayor impacto en el desarrollo del Software.
2.4 Tcnicas de Estimacin
Una vez definidas las mtricas de Software podemos entender las diferentes
tcnicas existentes para la estimacin, existen principalmente cuatro tcnicas de
estimacin.
1. La opinin de los expertos. Esta tcnica se basa en la experiencia
profesional de los participantes en el proyecto de estimacin.
2. La analoga. Es una aproximacin ms formal que la experiencia de los
expertos y se basa en la comparacin directa de uno o ms proyectos
pasados. La estimacin inicial se ajusta dependiendo de las diferencias
entre el proyecto pasado y el nuevo.
3. La descomposicin. Consiste en la descomposicin de un producto en
componentes ms pequeos, o descomponer un proyecto en tareas de
nivel inferior. La estimacin se hace partir del esfuerzo requerido para
producir los componentes ms pequeos o para realizar las tareas de nivel
inferior. La estimacin global de un proyecto resultar de sumar las
estimaciones de los componentes.
4. Las ecuaciones de estimacin. Son frmulas matemticas que establecen
la relacin de algunas medidas de entrada (que normalmente es la medida
del tamao del producto) y determinan el esfuerzo que se requerir.
Requisitos de un Buen Mtodo de Estimacin
Un mtodo de estimacin tendr xito s:

16

La estimacin inicial est dentro de un 30 % de desviacin del costo final

real.
El mtodo permite el refinamiento de la estimacin durante el ciclo de vida
del producto Software.
El mtodo es fcil de usar por el estimador. Esto permite una rpida reestimacin cuando sea necesario; por ejemplo para evaluar distintas
alternativas.
Las reglas de la estimacin son entendidas por todas las personas a las
que afectan los resultados de la misma. Los directivos se sienten ms
seguros cuando el proceso de estimacin es fcilmente comprensible.
El mtodo es soportado por herramientas y est documentado. La
disponibilidad de herramientas aumenta la eficacia de cualquier mtodo.
Esto es debido, principalmente, a que los resultados pueden ser obtenidos
ms rpidamente y de una forma estndar.

Mtodos de Estimacin
Un mtodo de estimacin eficaz permitir ignorar aspectos sin inters y
concentrase en los aspectos esenciales. Un buen modelo debera poseer
capacidades predicitivas, mejor que ser meramente descriptivo o explicativo.
La validez de las mtricas de Software y de los modelos de estimacin debe ser
establecida mostrando la coincidencia entre los datos empricos y experimentales.
Esto requiere una cuidadosa atencin en la toma de medidas y en el anlisis de
los datos.
Los modelos de estimacin existentes se pueden clasificar como Modelos de
Estadsticos, Modelos basados en Teoras y Modelos Compuestos. A continuacin
describiremos cada uno de ellos.
Modelos Estadsticos
C.E Walson y P.C. Felix, de IBM utilizaron datos de 60 proyectos terminados
completamente para desarrollar un modelo simple de calculo del esfuerzo de
desarrollo de Software.
El principal determinante del esfuerzo de desarrollo fue la mtrica LOC.
Se asumi una relacin de la forma : E = aLb, donde L es el nmero de lneas de
cdigo, en miles y E es el esfuerzo total requerido en meses/ personas.
Mediante una anlisis de regresin se encontraron los valores apropiados para a y
b. La ecuacin resultante fue:
E = 5,2 L 0,91

17

La productividad nominal de programacin en LOC por persona / mes, puede ser

calculada como L/E. Walston y Felix tambin intentaron desarrollar un ndice de
productividad, I, que podra hacer incrementar o disminuir la productividad
dependiendo de la naturaleza del proyecto.
Modelos basados en Teoras: Modelo de Putnam.
El modelo ms importante es el de Putnam. Este modelo asume una distribucin
especfica del esfuerzo a lo largo de la vida de un proyecto de desarrollo de
Software. El modelo se ha obtenido partir de distribuciones de mano de obra de
grandes proyectos. Sin embargo, se puede extrapolar a proyectos ms pequeos.
Putnam desarroll la siguiente relacin entre el tamao del producto Software y el
tiempo de desarrollo.
E = L3 / (C3T4)

Donde:
L = el nmero de instrucciones fuente producidas
E = el esfuerzo durante todo el ciclo de vida en aos / personas.
C = una constante dependiente de la tecnologa
T = el tiempo de desarrollo en aos.
Los varios tipos C pueden ser: C = 2.000 para un entorno pobre de desarrollo de
software ( sin metodologa, con una documentacin y unas revisiones pobres); C =
8.000 para un buen entorno de desarrollo de Software ( con una buena tecnologa
adecuada, documentacin y revisiones); C = 1.100 para un entorno excelente
( con herramientas y tcnicas automticas). Se puede obtener la constante C
correspondiente al entorno propio a partir de datos histricos recopilados sobre los
anteriores esfuerzos de desarrollo.
Mtodos Compuestos
Son modelos que utilizan una combinacin de intuicin anlisis estadstico y juicio
de expertos. A continuacin se describen los ms importantes.
a) Modelos COCOMO de Boehm. Es probablemente el ms conocido y
slidamente documentado de todos los modelos de estimacin de costos.
Mas adelante se estudiara en profundidad este modelo, con aplicaciones
prcticas.
b) SOFTCOST. Tausworthe: Trausworthe, de Jet Propulsin Laboratory,
intent desarrollar una estimacin de costo del Software utilizando
elementos de los modelos con ms xito disponibles. Este modelo requiere

18

68 parmetros de entrada, cuyos valores se deducen a partir de las

respuestas del usuario a 47 preguntas acerca del proyecto.
c) SPQR- Capers Jones: Capers Jones ha desarrollado un modelo de
estimacin de costos llamado Software Productivity, Quality and Reliability
(SPQR).
El enfoque del problema es similar al de Boehm en su modelo COCOMO. Est
basado en 20 factores que influyen razonablemente en el costo y productividad del
desarrollo del software y que estn bien definidos y otros 25 factores que no estn
tan bien definidos.
SPQR es un producto comercial, pero no esta tan bien documentados como otros
modelos. Requiere responder a ms de 100 preguntas relacionadas con el
proyecto para formular los parmetros de entrada necesarios en el calculo de los
costos y los planes. Jones seala que con este modelo es posible proporcionar
estimaciones de costo que estarn el 90% de las veces dentro del valor real con
una desviacin del 15%.
d) COPMO- Thebaut: Thebaut propone un modelo de desarrollo de Software
que intenta contabilizar el esfuerzo requerido cuando los equipos de
programacin estn involucrados en grandes proyectos. La ecuacin
general de calculo de esfuerzo es:
E = a + bS + cPd

Donde:
A,b,c,d, son constantes para ser determinadas a partir de datos empricos
mediante anlisis de regresin
S = es el tamao del programa en miles de LOC
P = es el medio de personal durante el ciclo de vida del proyecto
Desafortunadamente, este modelo no requiere uno si no dos parmetros cuyos
valores no son conocidos hasta la terminacin del proyecto. Adems, las
constantes b y c dependientes de la complejidad del Software no son
fcilmente determinables.
Este modelo presenta una frmula interesante, pero necesita un mayor
desarrollo y ajuste par que sea de inters general.
Herramientas Automticas de Estimacin
Las tcnicas de descomposicin y los modelos empricos de estimacin
descritos en las secciones anteriores se pueden implementar con Software.
Las herramientas automticas de estimacin permiten al planificador estimar
19

costos y esfuerzos, as como llevar a cabo anlisis del tipo qu pasa s con
importantes variables del proyecto, tales como la fecha de entrega o la
seleccin de personal. Aunque existen muchas herramientas automticas de
estimacin, todas exhiben las mismas caractersticas generales y todas
requieren una o ms clases de datos como los mostrados a continuacin:
1. Una estimacin cuantitativa del tamao del proyecto ( por ejemplo, en
LDC) o de la funcionalidad ( datos sobre los puntos de funcin)
2. Caractersticas cualitativas del proyecto, tales como la complejidad,
fiabilidad requerida o el grado de criticidad del negocio.
3. Alguna descripcin del personal de desarrollo y/o del entorno de
desarrollo.
A partir de estos datos, el modelo implementado por la herramienta automtica de
estimacin proporciona estimaciones del esfuerzo requerido para llevar acabo el
proyecto, los costos, la carga del personal, la duracin y en algunos casos, la
planificacin temporal del desarrollo y el riesgo asociado.
2.5 Planificacin de Proyectos.
El objetivo de planificacin del proyecto de Software es proporcionar un marco de
trabajo que permita al gestor hacer estimaciones razonables de recursos, costo y
planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo
limitado al comienzo de un proyecto de Software, y deberan actualizarse a
medida que progresa el proyecto. Adems, las estimaciones deberan definir los
escenarios del mejor caso y peor caso de forma que los resultados del
proyecto puedan limitarse .
El objetivo de la planificacin se logra mediante un proceso de descubrimiento de
la informacin que lleve a estimaciones razonables.
mbito del Software.
La primera actividad de la planificacin del proyecto de Software es determinar el
mbito del Software . Se deben evaluar la funcin y el rendimiento que se
asignaron al Software durante la ingeniera del sistema. El mbito del Software
describe la funcin, el rendimiento, las restricciones, las interfases y la fiabilidad.
Se evalan las funciones descritas en el enunciado del mbito, y en algunos
casos se refinan para dar ms detalles antes del comienzo de la estimacin.
La tcnica ms utilizada con frecuencia para acercar al cliente y al desarrollador, y
para hacer que comienza el proceso de comunicacin es establecer una
entrevista preliminar.
La comunicacin con el cliente lleva a una definicin de datos , funciones, y
comportamientos a implementarse, y de informacin sobre el rendimiento y
imitaciones que delimitan el sistema.
Recursos

20

La segunda tarea de la planificacin del desarrollo de Software es la estimacin de

los recursos requeridos para acometer el esfuerzo de desarrollo de Software.

Personas

Componentes del Software

Reutilizables

Herramientas Hard / Soft

En base a la pirmide de recursos se encuentra el entorno de desarrolloHardware y Software- que proporciona la infraestructura de soporte al esfuerzo de
desarrollo. En un nivel ms alto se encuentra los componentes del Software
Reutilizables, los bloques de Software que pueden reducir drsticamente los
costos de desarrollo y acelerar la entrega. En la parte ms alta esta el recurso
primario- las personas.
Recursos Humanos
El encargado de la planificacin comienza elevando el mbito y seleccionando las
habilidades tcnicas que se requieren para llevar acabo el desarrollo. El nmero
de personas requeridas para un proyecto de Software slo puede ser determinado
despus de hacer una estimacin del esfuerzo de desarrollo ( por ejemplo,
personas mes o personas aos.)
Recursos de Software Reutilizables.
Cualquier estudio sobre recurso de Software estara incompleto sin estudiar la
reutilizacin, esto es, la creacin y la reutilizacin de bloques de construccin de
software [H0091]. Tales bloques deben establecerse en catlogos para una
consulta ms fcil, estandarizarse para una fcil aplicacin y validarse para
tambin la fcil integracin.
Bernnatan [BEN92] sugiere cuatro categoras de recursos de Software que se
deberan tener en cuenta a medida que se avanza con la planificacin.

21

Componentes ya desarrollados. El Software existente se puede adquirir de una

tercera parte o provenir de uno desarrollado internamente para un proyecto
anterior. Estos componentes estn listos para utilizarse en el proyecto actual y se
han validado totalmente.
Componentes ya experimentados. Las especificaciones, diseos, cdigos, o
datos de pruebas ya existentes y desarrollados para proyectos anteriores que son
similares al Software que se va a construir para el proyecto actual. Los miembros
del equipo del Software actual ya han tenido la experiencia completa en el rea de
la aplicacin representada para estos componentes, Las modificaciones, por tanto,
requeridas para componentes de total experiencia, tendr un riesgo relativamente
bajo.
Componentes con experiencia parcial. Las especificaciones, los diseos,
cdigos o los datos de prueba existentes ya desarrollados para proyectos
anteriores que se relacionan con el Software que se va a construir para el
proyecto actual, pero que requerirn una modificacin sustancial. Los miembros
del equipo del Software actual han limitado su experiencia slo al rea de
aplicacin representada por estos componentes. Las modificaciones, por tanto,
requeridas para componentes de experiencia parcial tendrn bastante grado de
riesgo.
Componentes nuevos. Los componentes de Software que el equipo de Software
debe construir son especficamente para las necesidades del proyecto actual.
Recursos de entorno
El entorno es donde se apoya el proyecto de Software, llamado a menudo
entorno de Ingeniera de Software (EIS) 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 prctica de la
ingeniera de Software.

UNIDAD III
Conceptos Bsicos del desarrollo de un Sistema de Informacin
Al finalizar el siglo, hemos descubierto que somos parte de un inmenso sistemao conjunto de sistemas- que va de las plantas y los animales a las clulas, las
22

molculas, los tomos y las estrellas. Somos un eslabn de la cadena del ser
como llamaban los antiguos filsofos al universo
OCTAVIO PAZ. Discurso al recibir el premio Nbel de Literatura.
Para Newton, dentro de su concepcin mecanicista, un sistema era un
mecanismo que opera segn leyes inmutables. No as dentro de una visin
sistmica. Conforme lo expone Bertalanffy, un sistema puede definirse como un
conjunto de elementos f1, f2, ... fn en interaccin, definicin a la cual, segn
Rodrguez Delgado convendra aadirle la caracterstica de poseer una frontera o
lmite- ms o menos borroso- que separa al sistema de su entorno.
Sistema es un todo que tiene una funcin en un todo ms grande de lo cual es una
parte... todo sistema es parte de un sistema ms grande.
Sistema de Informacin: Es un conjunto de procesos formales integrados a la
empresa, que almacena datos en base de datos; para su posterior anlisis y tiene
como funcin posterior a la toma de decisiones Gerenciales.
Los sistemas de informacin son desarrollados con propsitos diferentes
dependiendo de las necesidades del negocio.
La necesidad del anlisis y diseo de sistemas
El anlisis y diseo de sistemas, tanto como es ejecutado por los analistas de
sistemas, busca analizar sistemticamente la entrada de datos o el flujo de datos,
el proceso o transformacin de datos, el almacenamiento de datos y la salida de
informacin dentro del contexto de un negocio particular. Adems, el diseo y
anlisis de sistemas es usado para analizar, disear e implementar mejoras en el
funcionamiento de los negocios que pueden ser logradas por medio del uso de
sistemas de informacin computarizados.
La instalacin de un sistema sin planeacin adecuada lleva a grandes
frustraciones, y frecuentemente causa que el sistema deje ser usado.
El anlisis y diseo de sistemas lleva estructura al anlisis y diseo de sistemas
de informacin, un costoso esfuerzo que de otra forma podra haber sido hecho de
modo casual. Puede ser visto como una serie de procesos llevados acabo
sistemticamente para mejorar un negocio por medio del uso de sistemas de
informacin computarizados. Gran parte del anlisis y diseo de sistemas
involucr el trabajo con los usuarios actuales y eventuales de los sistemas de
informacin.
Analistas de Sistemas: Los analistas de sistemas generalmente valoran la
manera en que funcionan los negocios examinando la entrada, el procesamiento
de datos y la salida de informacin con el propsito de mejorar los procesos
organizacionales.
Muchas mejoras involucran mejor apoyo para las funciones de los negocios por
medio del uso de sistemas de informacin computarizados. Esta definicin
23

enfatiza un enfoque sistemtico y metdico para analizar, y posiblemente mejorar,

lo que esta sucediendo en el contexto especfico creado por un negocio.
Nuestra definicin de un analista de sistemas es necesariamente amplia. El
analista debe ser capaz de trabajar con gente de todas las descripciones y debe
tener experiencia en el trabajo con computadoras. El analista desempea muchos
papeles, balanceando varios al mismo tiempo. Los tres papeles principales del
analista de sistemas son: consultor, experto de soporte y agente de cambio.
El analistas de Sistemas como Consultor
El analista de sistemas frecuentemente acta como consultor y, por lo tanto,
puede ser contratado especficamente para que se encargue de los asuntos de los
sistemas de informacin dentro de un negocio. Esto puede ser una ventaja, debido
a que los consultores externos pueden llevar con ellos una perspectiva fresca que
no poseen otros miembros de la organizacin. Pero tambin puede decirse que los
analistas externos estn en desventaja, debido a que la verdadera cultura
organizacional nunca puede ser conocida por un extrao.
El analista de sistemas como Experto de Soporte
Otro papel que tal vez requiera desarrollar es el de experto de soporte en un
negocio donde se esta empleado regularmente en alguna actividad de sistemas.
En este papel el analista se apoya en su experiencia profesional relacionada con
el Hardware y Software de computadora y sus uso en el negocio. Este trabajo
frecuentemente no es un proyecto de sistema completo, si no solamente
pequeas modificaciones o decisiones que afectan un solo departamento.
Como experto de soporte no est administrando el proyecto, o simplemente estn
sirviendo como un recurso para aquellos que lo manejan. Si se es una analista de
sistemas empleado por una organizacin de fabricacin o servicios, muchas de las
actividades diarias pueden ser desarrolladas en este papel.
El analista de sistemas como Agente de Cambio
El papel ms compresivo y responsable que toma un analista de sistemas es el
de agente de cambio, ya sea externo o interno al negocio. Como analista se es un
agente de cambio cada vez que se ejecuta cualquiera de las actividades del ciclo
de vida del desarrollo de sistemas ( tratado en la siguiente seccin ) y se est
presente en el negocio por un periodo extendido ( de dos semanas hasta ms de
un ao ). Un agente de cambio puede ser definido como una persona que sirve de
catalizador para el cambio, desarrolla un plan para el cambio y trabaja junto con
otras para facilitar ese cambio.
Cualidades del analista de sistemas

24

A partir de la descripcin anterior de los papeles que desempea el analista de

sistemas, es fcil ver que el analista de sistemas exitoso debe poseer una alto
grado de cualidades. Muchos tipos de agentes diferentes son analistas de
sistemas, por lo que cualquier descripcin quedar corta en alguna forma. Sin
embrago, hay algunas cualidades que parecen mostrar la mayora de los analistas
de sistemas.
Antes que nada, el analista es un solucionador de problemas. Es una persona que
ve el anlisis de los problemas como un reto y que disfruta al encontrar soluciones
funcionales. Cuando es necesario, el analista debe ser capaz de atacar
sistemticamente la situacin al mano por medio de la aplicacin hbil de
herramientas, tcnicas y experiencia. El analista tambin debe ser un comunicador
capaz de relacionarse en forma significativa con la dems gente a travs de
periodos extensos. Los analistas de sistemas necesitan la suficiente experiencia
en computacin para programar, comprender las capacidades de las
computadoras, para recoger los requerimientos de informacin de los usuarios y
para comunicar lo que se necesita a los programadores.
El analista de sistemas debe ser un individuo auto disciplinado y auto motivado,
capaz de manejar y coordinar innumerables recursos del proyecto incluyendo a
otras gentes. El anlisis de sistemas es una carrera que demanda mucho, pero en
compensacin es cambiante y siempre retadora.
EL CICLO DE VIDA DEL DESARROLLO DE SITEMAS
Hemos hecho referencia al enfoque sistemtico que toma el analista para el
anlisis y diseo de sistemas de informacin. Mucho de esto esta comprendido en
lo que es llamado el ciclo de vida del desarrollo de sistemas ( SDLC por sus siglas
en ingls). El SDLC es un enfoque por fases del anlisis y diseo que sostiene
que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo
especfico de actividades del analista y del usuario.
Los analistas no estn de acuerdo con qu tantas fases exactas hay en el ciclo de
vida del desarrollo de sistemas, pero, por lo general, alaban su enfoque
organizado. Aqu hemos dividido el ciclo en siete fases.
Aunque cada fase es presentada en forma discreta, nunca se lleva acabo como un
paso aparte. En vez de ello, varias actividades pueden suceder simultneamente,
y las actividades pueden ser repetidas. Esta es la razn por lo cual es ms til
pensar que el SDLC se logra en fases ( Con actividades traslapndose y luego
disminuyendo) y no en pasos separados.

25

26