Está en la página 1de 14

2.

- Tcnicas de Descomposicin
Las estimaciones se hacen sobre cada componente en que se descompone el software
o sobre tareas de bajo nivel en que se descomponen las tareas.
Las estimaciones de bajo nivel se combinan para producir una estimacin del proyecto
completo. Es decir, el coste total del proyecto es el resultado de sumar las
estimaciones de todos los componentes en los que se ha dividido el proyecto.
Cuando se trata con problemas de gran tamao que no pueden ser resueltos en los
equipos informticos disponibles, suele recurrirse a tcnicas de descomposicin, que
permiten fragmentar el problema y coordinar la resolucin de los subproblemas para
alcanzar la solucin del problema completo. En este sentido, las tcnicas de

descomposicin se pueden ver como estrategias de particin del grafo que representa
el rbol de escenarios y de resolucin coordinada de los fragmentos del grafo. Este
proceso de resolucin es de naturaleza iterativa y ampla el tiempo de solucin total,
por lo que debe ser evitado siempre que sea posible la resolucin directa. En el caso de
los problemas de optimizacin estocstica, el empleo de tcnicas de descomposicin
permite la consideracin de gran cantidad de escenarios o de problemas con un mayor
nivel de detalle en el modelado.
La estimacin del proyecto completo se calcula mediante la suma de las cantidades
parciales (enfoque abajo-arriba/bottom-up).

- En la estimacin intervienen los responsables de cada componente y/o fase del


proyecto.
- Lo ms adecuado es utilizar las tcnicas de descomposicin estructurada (EDT/WBS,
DFT/WFD).
Tcnicas de descomposicin:
Del proyecto (o por fases)
Del producto (o por mdulos)
Del proyecto y del producto (por fases y por mdulos). Es una combinacin de las
anteriores.
Entre las ventajas se encuentran:
La posibilidad de que el responsable del componente a estimar participe en dicha
estimacin.
Ayuda a analizar con detalle cada componente.
Entre los inconvenientes se encuentran:
La dificultad para contemplar los costes de actividades relacionadas con el proyecto
como lectura de cdigo, revisin, reuniones, y actividades no relacionadas con el
proyecto relacionado con los hbitos de trabajo.
Estimacin basada en el problema.
Puede usarse LOC o PF para hacer estimaciones.
Si se utiliza LOC, la descomposicin es esencial y a menudo debe ser a detalle.

3.- Las estimaciones de tiempo y costo


deberan ser exactas, naturalmente. Pero si

ellas difieren de los

resultados reales, es ms seguro ser ligeramente


conservador que ser optimista. Una de las principales quejas sobre los proyectos de software se refiere
a su tendencia alarmante de exceder gastos y calendarios planificados. Desafortunadamente, tanto
clientes como ejecutivos superiores tienden a ejercer presiones considerables en los administradores de
proyectos y en el personal encargado de realizar las estimaciones. Por consiguiente un colorario oculto
de estimacin acertada es aquel en donde stas deben ser defendibles. La mejor defensa es una buena
coleccin de datos histricos de proyectos similares.
Debido a que el crecimiento de la estimacin de costos es una actividad compleja, existe un crecimiento
industrial de compaas dedicadas a ofrecer diferentes marcas comerciales de herramientas de
estimacin de costos en el mercado. A partir del 2005, algunas de esas herramientas de estimacin son:
COCOMO II, CoStar, CostModeler, CostXpert, KnowledgePlan, PRICE S, SEER, SLIM y SoftCost.
Algunas de las herramientas de estimacin de costos ms antiguas, no estn activamente en el
mercado pero todava son utilizadas, tales como: CheckPoint, COCOMO, ESTIMACS, REVIC y
SPQR/20, ya que su uso no es apoyado por los vendedores, por lo que su utilizacin est en declive.
Mientras estos instrumentos de estimacin fueron desarrollados por empresas diferentes y no son
idnticos, ellos realmente tienden a proporcionar un ncleo de funciones comunes. Los rasgos
principales de instrumentos de estimacin de software comerciales en incluyen estos atributos:
Lgica de dimensionamiento para especificaciones, cdigo fuente y casos de evaluacin

Nivel
de
fase,
nivel
de
actividad,
y
estimacin
de
nivel
de
tarea
Ajustes para perodos de trabajo especficos, vacaciones y horas extraordinarias

Ajustes
para
salarios
locales
e
ndices
de
carga
Ajustes para varios proyectos de software como militares, sistemas, comerciales, etc.
Apoyo para mtricas de puntos de funcin, mtricas de lneas de cdigos o ambas
Apoyo para backfiring, es decir, convertir lneas de cdigos a puntos de funcin
Apoyo tanto para nuevos proyectos como a proyectos de mejora y mantenimiento

4.- (requirements en ingls). En ingeniera del software y el


desarrollo de sistemas, un requerimiento es una necesidad
documentada sobre el contenido, forma o funcionalidad de un producto o servicio.
Los requerimientos son declaraciones que identifican atributos, capacidades, caractersticas y/o cualidades
que necesita cumplir un sistema (o un sistema de software) para que tenga valor y utilidad para el usuario. En
otras palabras, los requerimientos muestran qu elementos y funciones son necesarias para un proyecto.
En el modelo clsico de desarrollo de sistemas o desarrollo software, la etapa de los requerimientos viene
antecedida de la etapa de factibilidad del sistema/software y precedida por la etapa de diseo del
sistema/software.
Etapas de la fase de requerimientos
* Obtencin de requerimientos: bsqueda y obtencin de los requerimientos desde los grupos de inters.
* Anlisis: comprobacin de la consistencia y completitud de los requerimientos.
* Verificacin: constatacin de que los requerimientos especificados son correctos.

5.- Tareas de anlisis

El anlisis de requisitos del software se puede subdividir en cinco reas


de esfuerzo:
1.

Reconocimiento del problema

2.

Evaluacin y sntesis

3.

Modelado

4.

Especificacin

5.

Revisin

Todos los mtodos de anlisis se relacionan por un conjunto de principios


operativos:

1.

2.

Debe representarse y entenderse el dominio de la informacin de


un problema.
Deben definirse las funciones que debe realizar el software.

3.

Debe representarse el comportamiento del software (como


consecuencia de acontecimientos externos),

4.

Deben dividirse los modelos que representan informacin,


funcin y comportamiento de manera que se descubran los
detalles por capas (o jerrquicamente).

5.

El proceso de anlisis debera ir desde la informacin esencial


hasta el detalle de la implementacin.

Adems de los principios operativos mencionados anteriormente, se


sugiere un conjunto de principios directrices para la ingeniera de
requerimientos:

1.

Entender el problema antes de empezar a crear el modelo de


anlisis.

2.

Desarrollar prototipos que permitan al usuario entender como


ser la interaccin hombre-mquina.

3.

Registrar el orden y la razn de cada requerimiento,

4.

Usar mltiples planteamientos de requerimientos.

5.

Priorizar los requerimientos.

6.

Trabajar para eliminar la ambigedad.

6.- Existen mltiples definiciones para arquitectura de


sistemas:
* Es la organizacin fundamental de un sistema, que incluye sus componentes, las relaciones entre s y el
ambiente, y los principios que gobiernan su diseo y evolucin. (del From ANSI/IEEE 1471-2000).
* Es una descripcin del diseo y contenido de un sistema de computadora. Puede incluir informacin como el
hardware y software que contiene, y la capacidad de la red.
* Descripcin formal de un sistema o un plan detallado del sistema a nivel componente como gua para su
implementacin.
La arquitectura de un sistema es una representacin de un sistema existente o a crear y el proceso y
disciplina para efectivamente implementar el diseo como un sistema.
Es una representacin porque la arquitectura es usada para transportar informacin abstracta sobre el
sistema, las relaciones entre sus elementos y las reglas que gobiernan esas relaciones.
Es un proceso porque es una secuencia de pasos para producir un sistema o cambiar la arquitectura del
sistema o disear el sistema.

7.- Diseo de sistemas


l Diseo de sistemas es el arte de definir la arquitectura de hardware y software,
componentes, mdulos y datos de un sistema de cmputo para satisfacer ciertos
requerimientos. Es la etapa posterior al anlisis de sistemas.
El diseo de sistemas tiene un rol ms respetado y crucial en la industria de procesamiento
de datos. La importancia del software multiplataforma ha incrementado la ingeniera de
software a costa de los diseos de sistemas.
Los mtodos de Anlisis y diseo orientado a objetos se estn volviendo en los mtodos
ms ampliamente utilizados para el diseo de sistemas. El UML se ha vuelto un estandard

en el Anlisis y diseo orientado a objetos. Es ampliamente utilizado para el modelado de


sistemas de software y se ha incrementado su uso para el diseo de sistemas que no son
software as como organizaciones.

Construccin del Sistema de


informacin (CSI)
8.-

DESCRIPCIN Y OBJETIVOS
En este proceso se genera el cdigo de los componentes del Sistema de Informacin,
se desarrollan todos los procedimientos de operacin y seguridad y se elaboran todos
los manuales de usuario final y de explotacin con el objetivo de asegurar el correcto
funcionamiento del Sistema para su posterior implantacin.
Para conseguir dicho objetivo, en este proceso se realizan las pruebas unitarias, las
pruebas de integracin de los subsistemas y componentes y las pruebas del sistema,
de acuerdo al plan de pruebas establecido.
Asimismo, se define la formacin de usuario final y, si procede, se construyen los
procedimientos de migracin y carga inicial de datos.
Al ser MTRICA Versin 3 una metodologa que cubre tanto desarrollos estructurados
como orientados a objetos, las actividades de ambas aproximaciones estn
integradas en una estructura comn.
El producto Especificaciones de Construccin del Sistema de Informacin, obtenido
en la actividad de Generacin de Especificaciones de Construccin (DSI 8), es la
base para la construccin del sistema de informacin. En dicho producto se recoge la
informacin relativa al entorno de construccin del sistema de informacin, la
especificacin detallada de los componentes y la descripcin de la estructura fsica de
datos, tanto bases de datos como sistemas de ficheros. Opcionalmente, incluye un
plan de integracin del sistema de informacin, en el que se especifica la secuencia y
organizacin de la construccin de los distintos componentes.

También podría gustarte