Professional Documents
Culture Documents
COMPUTACIN E INFORMTICA
III SEMESTRE
ISEPA
COMPUTACIN E INFORMTICA
III SEMESTRE
1.4 RECURSOS:
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, esto simula a
una pirmide donde las Herramientas (hardware y Software), son la base proporciona la
infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirmide se
encuentran los Componentes reutilizables.
Y en la parte mas alta de la pirmide se encuentra el recurso primario, las personas (el
recurso humano).
Cada recurso queda especificado mediante cuatro caractersticas:
Descripcin del Recurso.
Informes de disponibilidad.
Fecha cronolgica en la que se requiere el recurso.
Tiempo durante el que ser aplicado el recurso.
1.4.1 Recursos Humanos.
La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo
puede ser determinado despus de hacer una estimacin del esfuerzo de desarrollo (por
ejemplo personas mes o personas aos),
y seleccionar la posicin dentro de la
organizacin y la especialidad que desempeara cada profesional.
1.4.2 Recursos o componentes de software reutilizables.
Cualquier estudio sobre recursos de software estara incompleto sin estudiar la
reutilizacion, esto es la creacin y la reutilizacion de bloques de construccin de Software.
Tales bloques se deben establecer en catlogos para una consulta ms fcil,
estandarizarse para una fcil aplicacin y validarse para la tambin fcil integracin.
El Autor Bennatan sugiere cuatro categoras de recursos de software que se deberan
tener en cuenta a medida que se avanza con la planificacin:
Componentes ya desarrollados.
Componentes ya experimentados.
Componentes con experiencia Parcial.
Componentes nuevos.
1.4.3 Recursos de entorno.
El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de
Ingeniera de Software, incorpora Hardware y Software.
El Hardware proporciona una plataforma con las herramientas (Software) requeridas para
producir los productos que son el resultado de la buena practica de la Ingeniera del
Software, un planificador de proyectos debe determinar la ventana temporal requerida
para el Hardware y el Software, y verificar que estos recursos estn disponibles. Muchas
veces el desarrollo de las pruebas de validacin de un proyecto de software para la
composicin automatizada puede necesitar un compositor de fotografas en algn punto
durante el desarrollo. Cada elemento de hardware debe ser especificado por el
planificador del Proyecto de Software.
1.5.
ISEPA
COMPUTACIN E INFORMTICA
III SEMESTRE
En el principio el costo del Software constitua un pequeo porcentaje del costo total de los
sistemas basados en Computadoras. Hoy en da el Software es el elemento mas caro de la
mayora de los sistemas informticos.
Un gran error en la estimacin del costo puede ser lo que marque la diferencia entre
beneficios y perdidas, la estimacin del costo y del esfuerzo del software nunca ser una
ciencia exacta, son demasiadas las variables: humanas, tcnicas, de entorno, polticas,
que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo.
Para realizar estimaciones seguras de costos y esfuerzos tienen varias opciones posibles:
Deje la estimacin para ms adelante (obviamente podemos realizar una estimacin al
cien por cien fiable despus de haber terminado el proyecto.
Base las estimaciones en proyectos similares ya terminados.
Utilice tcnicas de descomposicin relativamente sencillas para generar las
estimaciones de costos y esfuerzo del proyecto.
Desarrolle un modelo emprico para l clculo de costos y esfuerzos del Software.
Desdichadamente la primera opcin, aunque atractiva no es prctica.
La Segunda opcin puede funcionar razonablemente bien si el proyecto actual es bastante
similar a los esfuerzos pasados y si otras influencias del proyecto son similares. Las
opciones restantes son mtodos viables para la estimacin del proyecto de software.
Desde el punto de vista ideal, se deben aplicar conjuntamente las tcnicas indicadas
usando cada una de ellas como comprobacin de las otras.
Antes de hacer una estimacin, el planificador del proyecto debe comprender el mbito
del software a construir y generar una estimacin de su tamao.
1.5.1 Estimacin basada en el Proceso.
Es la tcnica ms comn para estimar un proyecto es basar la estimacin en el proceso
que se va a utilizar, es decir, el proceso se descompone en un conjunto relativamente
pequeo de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la
estimacin de cada tarea.
Al igual que las tcnicas basadas en problemas, la estimacin basada en el proceso
comienza en una delineacin de las funciones del software obtenidas a partir del mbito
del proyecto. Se mezclan las funciones del problema y las actividades del proceso. Como
ultimo paso se calculan los costos y el esfuerzo de cada funcin y la actividad del proceso
de software.
1.6. DIFERENTES MODELOS DE ESTIMACION.
Existen diferentes modelos de estimacin como son:
1.6.1 Los Modelos Empricos:
Donde los datos que soportan la mayora de los modelos de estimacin obtienen una
muestra limitada de proyectos. Por est razn, el modelo de estimacin no es adecuado
para todas las clases de software y en todos los entornos de desarrollo. Por lo tanto los
resultados obtenidos de dichos modelos se deben utilizar con prudencia.
1.6.2 El Modelo COCOMO.
Barry Boehm, en su libro clsico sobre economa de la Ingeniera del Software, introduce
una jerarqua de modelos de estimacin de Software con el nombre de COCOMO, por su
nombre en Ingles (Constructive Cost Model) modelo constructivo de costos. La jerarqua de
modelos de Boehm esta constituida por los siguientes:
3
ISEPA
COMPUTACIN E INFORMTICA
III SEMESTRE
ISEPA
COMPUTACIN E INFORMTICA
III SEMESTRE
ISEPA
COMPUTACIN E INFORMTICA
III SEMESTRE
Revisin.
Antes de su reunin con el analista, el cliente prepara un documento conceptual del
proyecto, aunque es recomendable que este se elabore durante la comunicacin Cliente
analista, ya que de hacerlo el cliente solo de todas maneras tendra que ser modificado,
durante la identificacin de las necesidades.
2.2.2 Estudio de Viabilidad.
Muchas veces cuando se emprende el desarrollo de un proyecto de Sistemas los recursos
y el tiempo no son realistas para su materializacin sin tener prdidas econmicas y
frustracin profesional. La viabilidad y el anlisis de riesgos estn relacionados de muchas
maneras, si el riesgo del proyecto es alto, la viabilidad de producir software de calidad se
reduce, sin embargo se deben tomar en cuenta cuatro reas principales de inters:
2.2.2.1 Viabilidad econmica.
Una evaluacin de los costos de desarrollo, comparados con los ingresos netos o
beneficios obtenidos del producto o Sistema desarrollado.
2.2.2.2 Viabilidad Tcnica.
Un estudio de funciones, rendimiento y restricciones que puedan afectar la realizacin de
un sistema aceptable.
2.2.2.3 Viabilidad Legal.
Es determinar cualquier posibilidad de infraccin, violacin o responsabilidad legal en que
se podra incurrir al desarrollar el Sistema.
2.2.2.4
Alternativas. Una evaluacin de los enfoques alternativos del desarrollo del
producto o Sistema.
El estudio de la viabilidad puede documentarse como un informe aparte para la alta
gerencia.
2.2.3 Anlisis Econmico y Tcnico.
El anlisis econmico incluye lo que llamamos, el anlisis de costos beneficios, significa
una valoracin de la inversin econmica comparado con los beneficios que se obtendrn
en la comercializacin y utilidad del producto o sistema.
Muchas veces en el desarrollo de Sistemas de Computacin estos son intangibles y resulta
un poco dificultoso evaluarlo, esto vara de acuerdo a las caractersticas del Sistema. El
anlisis de costos beneficios es una fase muy importante de ella depende la posibilidad
de desarrollo del Proyecto.
En el Anlisis Tcnico, el Analista evala los principios tcnicos del Sistema y al mismo
tiempo recoge informacin adicional sobre el rendimiento, fiabilidad, caractersticas de
mantenimiento y productividad.
Los resultados obtenidos del anlisis tcnico son la base para determinar sobre si
continuar o abandonar el proyecto, si hay riesgos de que no funcione, no tenga el
rendimiento deseado, o si las piezas no encajan perfectamente unas con otras.
2.2.4 Modelado de la arquitectura del Sistema.
Cuando queremos dar a entender mejor lo que vamos a construir en el caso de edificios,
Herramientas, Aviones, Maquinas, se crea un modelo idntico, pero en menor escala (mas
pequeo).
Sin embargo cuando aquello que construiremos es un Software, nuestro modelo debe
6
ISEPA
COMPUTACIN E INFORMTICA
III SEMESTRE
tomar una forma diferente, deben representar todas las funciones y subfunciones de un
Sistema. Los modelos se concentran en lo que debe hacer el sistema no en como lo hace,
estos modelos pueden incluir notacin grfica, informacin y comportamiento del Sistema.
Todos los Sistemas basados en computadoras pueden modelarse como transformacin de
la informacin empleando una arquitectura del tipo entrada y salida.
2.2.5 Especificaciones del Sistema.
Es un Documento que sirve como fundamento para la Ingeniera Hardware, software, Base
de datos, e ingeniera Humana. Describe la funcin y rendimiento de un Sistema basado
en computadoras y las dificultades que estarn presentes durante su desarrollo. Las
Especificaciones de los requisitos del software se producen en la terminacin de la tarea
del anlisis.
En Conclusin un proyecto de desarrollo de un Sistema de Informacin comprende varios
componentes o pasos llevados a cabo durante la etapa del anlisis, el cual ayuda a
traducir las necesidades del cliente en un modelo de Sistema que utiliza uno ms de los
componentes: Software, hardware, personas, base de datos, documentacin y
procedimientos.
III.
ISEPA
COMPUTACIN E INFORMTICA
III SEMESTRE
ISEPA
COMPUTACIN E INFORMTICA
III SEMESTRE
ISEPA
COMPUTACIN E INFORMTICA
III SEMESTRE
ISEPA
COMPUTACIN E INFORMTICA
III SEMESTRE
11