Administracin de Sistemas de Software

UNICAH

Software E Ingeniera del Software

Es comn darse cuenta que la invencin de una tecnologa puede tener efectos profundos e inesperados en otras tecnologas con las que en apariencia no tiene ninguna relacin. A este fenmeno se le consecuencias Imprevistas denomina Ley de las

Software E Ingeniera del Software

A medida que la importancia del software ha crecido, la comunidad del software ha intentado de manera continua desarrollar tecnologas que hagan mas fcil, mas rpida y menos cara la construccin y mantenimiento de programas de alta calidad.

Software E Ingeniera del Software

Que es?
Es el producto que los ingenieros de software construyen y despus mantienen en el largo plazo Por qu es importante? Por que afecta de forma muy cercana todos los aspectos de nuestra vida y se han vuelto omnipresentes en el comercio, la cultura y las actividades cotidianas.

El Papel Evolutivo del Software

En la actualidad el software tiene un papel dual. Es a la ves, un producto y un vehculo mediante el cual se entrega el producto
El software entrega el producto mas importante de nuestro tiempo: La Informacin El papel de software de computadora ha experimentado un cambo significativo en un periodo un poco mayor de 50 aos.

El Papel Evolutivo del Software

Puntos de Vista
Nueva Revolucin Industrial El surgimiento de la microelectrnica es la tercer la de cambio en la historia de la humanidad. La transformacin de una sociedad industrial en una sociedad de la informacin La informacin y el conocimiento controlados por computadoras sern el punto de enfoque para el poder en el siglo XXI

El Papel Evolutivo del Software

Al finalizar el siglo XX el enfoque cambio nuevamente, esta vez con el impacto del Y2K, Bomba de Tiempo
El impacto continuo del terrorismo en la comunidad informtica.

En la actualidad una enorme industria del software se ha convertido en un factor dominante en la economa del mundo industrializado. El programador solitario de la era inicial ha sido sustituido por equipos de especialistas en software, en los que cada uno se enfoca en una parte de la tecnologa requerida para desarrollar una aplicacin compleja.

Preguntas que se hace el programador solitario

Por qu se tarda tanto la obtencin del software terminado?
Por que son tan altos los costos del desarrollo de software?

Por que es imposible encontrar todos los errores en el software antes de entregarlo a los clientes?
Por qu se gastan tanto tiempo y esfuerzo en el mantenimiento de los programas existentes? Por qu es difcil medir el progreso al desarrollar y darle mantenimiento al software?

El Software
El software se forma con
1. Las instrucciones(Programa de Computadora) que al ejecutar se proporcionan las caractersticas, funciones y el grado de desempeo deseados

2. Las estructuras de datos que permiten que los programas manipulen informacin de manera adecuada
3. Los documentos que describen la operacin y el uso de los programas.

Caractersticas del Software

El software se desarrolla o construye; no se manifactura en el sentido clsico.
El software no se desgasta A pesar de que la industria tiene una tendencia hacia la construccin por componentes, la mayora del software aun se construye a la medida

La naturaleza cambiante del Software

Software de sistemas
Software de aplicacin Software cientfico y de ingeniera

Software emportado
Software de lnea de producto Aplicaciones basadas en web

La Naturaleza Cambiante del Software

Software de I. A.
Computacin Ubicua Alimentacin de la red Fuente abierta La nueva economa

Evolucin del Software

Los sistemas de software heredado fueron desarrollados hace dcadas y han sido modificados en forma continua para cumplir los requerimientos de los cambios de los negocios y en las plataformas de computo. Razones de la evolucin del software heredado 1. El software debe adaptarse para satisfacer las necesidades de los nuevos ambientes o las nuevas tecnologas. 2. El software debe mejorarse requerimientos de negocios para implementar los nuevos

3. El software debe extenderse para hacerlo operable con sistemas y base de datos mas modernas 4. El software debe redisearse para hacerlos viable dentro de un ambiente de red

Mitos del Software

Son creencias acerca del software y de los procesos empleados para construirlo.
Los mitos parecen una relacin de hechos razonables (algunas veces contienen elementos verdaderos), se observan de manera intuitiva y con frecuencia los promulgan practicantes experimentados, quienes conocen el terreno

Mitos de la Administracin
Los administradores con responsabilidades sobre el software , al igual que sus pares en las mayoras disciplinas, a menudo esta bajo presin por mantener los presupuestos, evitar que los itinerarios se extiendan y mejorar la calidad. De la misma forma que una persona se aferra a un tronco, con frecuencia el administrador del software se aferra a un mito si siente que esta creencia reducir la presin.

Mitos de la Administracin
Ya se tiene un libro lleno de estndares y procedimientos para construccin de software Esto proporcionara a mi gente todo el conocimiento necesario?
Si se esta atrasado en el itinerario es posible contratar a mas programadores para as terminar tiempo. Si decido subcontratar el proyecto de software a un tercero, puedo relajarme y dejar que esa compaa la construya

Mitos del cliente

El cliente que solicita software de computadora puede ser la persona del escritorio de al lado, un grupo tcnico, el departamento de ventas o de mercadotecnia, una compaaa externa.
En muchos clientes el cliente cree en mitos acerca del software por que los profesionales y administradores del software hacen muy poco para corregir la desinformacin. Estos conducen a expectativas falsas del clientes y en definitiva a insatisfacciones con el desarrollador.

Mitos del Cliente

Un enunciado general de los objetivos es suficiente para empezar a escribir programas; los detalles se pueden afinar despus
Los requerimientos del proyecto cambian de manera continua, pero el cambio puede ajustarse con facilidad por que el software es flexible

Mitos del Desarrollador

Los mitos que aun subsisten entre los desarrolladores del software han permanecido a travs de 50 aos de cultura de programacin. Durante los primeros aos del software, la programacin era vista como una forma de arte; por ello, las viejas formas y actitudes difciles de eliminar

Mitos del Desarrollador

Una ves que el programa ha sido escrito y puesto a funcionar, el trabajo esta terminado.
Mientras el programa no se este ejecutando, no existe forma de evaluar su calidad

El nico producto del trabajo que puede entregarse para tener un proyecto exitoso es el programa en funcionamiento.
La ingeniera del software obligara a emprender la creacin de una documentacin voluminosa innecesaria y de manera invariable tornara mas lento el proceso

El Proceso del Software

Cuando se trabaja para construir un producto o sistema es importante seguir una serie de pasos predecibles: una especie de mapa de carreteras que ayude a crear un resultado de alta calidad y a tiempo. Esto es importante por que ofrece estabilidad, control y organizacin a una actividad que puede volverse catica si no se contrala. Es importante que la ingeniera del software la realicen personas creativas y con conocimiento que deben trabajar en proceso de software maduro que sea apropiado para el producto que construyen y para las demandas de sus mercados.

Ingeniera del Software

Concepto Es el establecimiento y uso de principios solidos de ingeniera para obtener econmicamente un software confiable y que funcione de modo eficiente. La ingeniera del software es una tecnologa estratificada.

Estratos de la ingeniera del Software

Cualquiera que sea el enfoque de ingeniera debe estar sustentado en un compromiso de calidad para fomentar la mejora continua del proceso. La base de la ingeniera del software es el proceso. Este define el marco de trabajo, los mtodos tcnicos, los productos (modelos, documentos, datos, reportes, formatos, etc.)

Los mtodos abarcan un amplio espectro de tareas que incluyen la comunicacin, el anlisis de requisitos, el modelo de diseo, la construccin, las pruebas y el soporte.
Las herramientas de la ingeniera del software proporcionan el soporte automatizado para el proceso y los mtodos.

Marco de Trabajo

Actividades del Marco de Trabajo

Comunicacin: implica una intensa colaboracin con los clientes, adems abarca la investigacin de requisitos y otras actividades relacionadas. Planeacin: Establece un plan para el trabajo de la ingeniera de software. Describe las tareas tcnicas que deben realizarse, los riesgos probables, los recursos que sern requeridos. Modelado: abarca la creacin de modelos que permiten al desarrollador y al cliente entender mejor los requisitos del software y el diseo que logra satisfacerlos

Actividades del Marco de Trabajo

Construccin: Esta actividad combina la generacin del cdigo y la realizacin de pruebas necesarias para descubrir errores en el cdigo.

Despliegue: el software completo o ya sea un incremento completado de manera parcial se debe entregar al cliente, quien evala el producto recibido y proporcin informacin basada en su evaluacin

Actividades Sombrilla
Seguimiento y control del proyecto de software: permite que el equipo de software evalu el progreso comparndolo con el plan del proyecto y as tomar las acciones necesarias para mantener el programa. Gestin de riesgo: Evala los riesgos que pudieran afectar los resultados del proyecto o la calidad del producto. Aseguramiento de la calidad del software: define las actividades requeridas para asegurar la calidad del software Revisiones tcnicas formales: Evala los productos del trabajo de la ingeniera de software en un esfuerzo encaminado a descubrir y eliminar los errores antes de que estos se propaguen hacia la siguiente accin o actividad.

Actividades Sombrilla
Medicin: Define y recolecta mediciones del proceso, el proyecto y el producto para ayudar al equipo a entregar software que satisfaga la necesidades del cliente. Gestin de la configuracin del software: Maneja los efectos del cambio a travs del proceso del software. Gestin de la reutilizacin: Define los criterios para la reutilizacin de productos del trabajo. Preparacin y produccin del producto de trabajo: Abarca las actividades requeridas para crear productos del trabajo como modelos, documentos, registros, formatos y listas.

Integracin del Modelo de Capacidad y Madurez (IMCM)

El Instituto de Ingeniera de Software ha desarrollado un modelo completo de amplio proceso basado en un conjunto de capacidades de software y de sistemas que deben estar presentes conforme las organizaciones alcanzan diferentes grados de capacidad y madurez del proceso.
La IMCM representa un modelo completo de proceso en dos formas diferentes:

1. El modelo continuo
2. El modelo discreto

Modelo Continuo
Cada rea del proceso se evala de manera formal contra las metas y practicas especificas y se clasifican de acuerdo con los siguientes niveles de capacidad:
Nivel 0: Incompleto

Nivel 1: Realizado
Nivel 2: Administrado Nivel 3: Definido

Nivel 4: Administrado en forma cuantitativa

Nivel 5: Mejorado

Metas que define la IMCM

Metas Especificas: Establecen las actividades que deben existir para que las actividades implicadas por un rea del proceso sean efectivas. Las practicas especificas convierten una meta en un conjunto de actividades relacionadas con el proceso. Metas Genricas: Cada una de las metas genricas corresponden a uno de los niveles de capacidad. Por lo tanto para lograr un nivel de capacidad particular se debe alcanzar la meta genrica para ese nivel y las practicas genricas que corresponden a esa meta

Metas Especificas y Metas Genricas

ME 1 Establecer estimaciones ME 2 Desarrollar un plan de proyecto ME 3 Comprometerse con la planeacin

MG 1 Alcanzar las metas especificas

MG 2 Institucionalizar un proceso de gestin

MG3 Institucionalizar un proceso definido MG4 Institucionalizar un proceso manejado en forma cuantitativa MG 5 Institucionalizar un proceso de mejoramiento

Prueba # 1
En el tema El Papel evolutivo del Software Explique lo concerniente a El Papel que tiene el Software en la Actualidad
Del tema El Software Describa los elementos con los que se forma el Software Cual es la realidad del mito del cliente Los requerimientos del proyecto cambian de manera continua, pero el cambio puede ajustarse con facilidad por que el software es flexible

Patrones del Proceso

El proceso del software se puede definir como una coleccin de patrones que definen un conjunto de actividades, acciones, tareas de trabajo o comportamientos relacionados que requiere el desarrollo de un software de computadora.
En trminos generales, un patrn de proceso ofrece una plantilla: un mtodo consistente para describir una caracterstica importante del proceso de software.

Ejemplo de Plantilla para el patrn de procesos

Nombre del Patrn: se le asigna un nombre significativo que describa su funcin dentro del software
Propsito: se describe con brevedad el objetivo del patrn.

Tipo: se especifica el tipo de patrn

1. Patrones de Tareas 2. Los patrones del escenario 3. Los Patrones de fase

Ejemplo de Plantilla para el patrn de procesos

Contexto Inicial: se describen las condiciones en las cuales se aplica el patrn.
Problema: se describe el problema que debe resolver el patrn. Por ejemplo, el problema que debe resolver la comunicacin con el cliente. Solucin: se describe la implementacin del patrn. En esta seccin se discute como el estado inicial del proceso se modifica como consecuencia del inicio del patrn

Ejemplo de Plantilla para el patrn de procesos

Contexto resultante: se describen las condiciones que habr una ves que el patrn haya sido implementado con xito.
Patrones relacionado: proporciona un lista de todos los patrones de proceso directamente relacionados con este, en forma jerrquica o de alguna otra forma. Usos conocido/ejemplos: se indican los ejemplos especficos en los cuales el patrn es aplicable.

Evaluacin del Proceso

La existencia de un proceso de software no es garanta de que este ser entregado a tiempo, de que satisfar las necesidades del cliente, o de que mostrara las caractersticas tcnicas que conducirn a caractersticas de calidad a largo plazo. Enfoques para la evaluacin del proceso de software 1. Mtodo de evaluacin de la IMCM estndar para el mejoramiento del proceso (MEIEMP) 2. La apreciacin basada en el CMM para el mejoramiento del proceso interno (ABC MPI) 3. El estndar SPICE (ISO/IEC15504) 4. ISO 9001:2000 para software

Modelos de Proceso Personales y En Equipo

Proceso de Software Personal: Cada desarrollador utiliza algn proceso para construir un software de computadora. El proceso puede ser fortuito o ad hoc, puede cambiar a diario, puede no ser eficiente, efectivo o hasta exitoso, pero existe un proceso. El PSP resalta la medida personal del producto de trabajo que se produce y la calidad resultante del producto de trabajo

Actividades del Marco de Trabajo de PSP

1. Planeacin 2. Diseo de alto nivel 3. Revisin del diseo de alto nivel

4. Desarrollo
5. Anlisis del resultado

El PSP destaca la necesidad que tiene cada ingeniero de identificar los errores desde el principio y la importancia de entender los tipos de errores que suele cometer.

Proceso de Software en Equipo PSE

Debido a que muchos proyectos de software en el mbito industrial los dirige un equipo de profesionales.
Es una propuesta para el proceso de software en equipo tomada de las lecciones del proceso de software personal

Objetivos del PSE

Construir equipos autodirigidos que planeen y tengan un seguimiento de su trabajo, establezcan metas y posean sus procesos y planes. Mostrar a los jefes como preparar y motivar a sus equipos y como ayudarlos a sostener un alto desempeo.

Acelerar el mejoramiento del proceso de software al realizar, con el comportamiento normal esperado, el nivel 5 del MCM
Ofrecer una gua de mejoramiento a organizaciones de alta madurez. Facilitar la enseanza universitaria de habilidades de equipo industrial de calidad.

Actividades de Trabajo del PSE

El PSE define las siguientes actividades del marco de trabajo: lanzamiento, diseo de alto nivel, implementacin y prueba, anlisis de resultados. Al igual que su contrapartes en el PSP, estas actividades permiten al equipo planear, disear y construir un software de una manera disciplinada al mismo tiempo que miden de modo cuantitativo el proceso y el producto.
La PSE utiliza una amplia variedad de escritos, formas y estndares que sirven mara guiar a los miembros del equipo en su trabajo

Escrito de Lanzamiento
Revisar los objetivos del proyecto con la gestin y acordar documentar las metas del equipo
Establecer las funciones del equipo Definir el proceso del desarrollo del equipo Elaborar un plan de calidad y los objetivos de calidad Preparar un plan para las necesidades de soporte necesarias Producir una estrategia de desarrollo general

Escrito de Lanzamiento
Elaborar un plan de desarrollo para el proyecto en su totalidad
Hacer planes detallados para cada ingeniero en la siguiente fase

Adaptar los planes individuales a un plan de equipo

Hacer un balance de la calidad de trabajo del equipo para obtener un programa mnimo en trminos generales Valorar los riesgos del proyecto y asignar responsabilidad de rastreo para cada riesgo clave

Tecnologa del Software

Para lograr que un equipo de proyecto de software logre alcanzar los procesos de los modelos se han desarrollado herramientas de tecnologa del proceso destinadas a ayudar a las organizaciones de software a analizar sus procesos actuales, organizar sus tareas, controlar monitorear su proceso y administrar su calidad tcnica.
Las herramientas de tecnologa del proceso permiten que una organizacin de software construya un modelo automatizado del marco de trabajo comn del proceso

Producto y Proceso
Si el proceso es dbil, sin duda el producto final sufrir las consecuencias. Asimismo una confianza excesiva en el proceso es peligrosa.
Sin duda, el sistema ideal, si se pudiera obtener, seria un cdigo tan flexible y diminuto como para proveer por anticipado en cada situacin concebible una regla exacta. Pero la vida es demasiado compleja para obtener esta idea incluso con todo el poder humano

Producto y Proceso
El trabajo que realiza la gente de software cambiara en los aos que siguen. La dualidad del producto y el proceso es un elemento importante para mantener a la gente creativa comprometida mientras finaliza la transicin desde la programacin hasta la ingeniera del software.

MODELOS PRESCRIPTIVOS DE PROCESO

Los modelos prescriptivos de proceso se propusieron originalmente para drenar el caos del desarrollo de software, estos son adaptados por los ingenieros de software y sus generantes de acuerdo a sus necesidades y despus lo siguen. Los modelos prescriptivos de procesos definen un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de trabajo que se requieren para desarrollar software de alta calidad

MODELOS PRESCRIPTIVOS
Cualquier organizacin de ingeniera del software debe describir un conjunto nico de actividades dentro del maco de trabajo para los procesos de software que adopten. Cada accin de ingeniera debe definirse como un conjunto de tares que definen el trabajo y el producto de trabajo que se necesitan para alcanzar las metas de desarrollo.

Prueba # 2
Explique los Estratos de la ingeniera del Software

Del tema Actividades Sombrilla de el concepto de Revisiones Tcnicas Formales

Cuales son las metas del IMCM Explique 1 de ellas

Objetivos del Proceso de software en equipo (PSE)

Estimacin para proyectos de software

La gestin de proyectos de software comienza con un conjunto de actividades que en grupo se denominan Planificacin del Proyecto.
Antes de que el proyecto comience el gestor del proyecto y el equipo deben estimar el trabajo que habr de realizarse, los recursos que se requerirn y el tiempo que transcurrir desde el inicio hasta el final.

Puesto que ninguna parte de quiere hacer la planificacin, con frecuencia no se realiza.
Las fallas para planificar es uno de los mayores errores que un proyecto pueda cometer. Se necesita la planificacin eficaz para resolver problemas a bajo costo. Un proyecto en promedio gasta 80% de su tiempo en reelaboracin; corrigiendo errores que se cometieron ene etapas tempranas del proyecto

Que Es?
Cuando ya se ha establecido una necesidad real para el software; cuando ya estn listos todos los participantes; los ingenieros ya estn listos para comenzar y el proyecto ya esta a punto de comenzar Como Proceder?
Estimacin Programa de trabajo Anlisis de riesgos Planificacin de la gestin de la calidad Planificacin de la gestin del cambio

Por que es importante?

Construira una casa sin saber cuanto dinero esta a punto de gastar, las tareas que se deben realizar y el tiempo para realizar todo el trabajo?

Quien lo hace?
Los gestores de proyecto de software, con base a la informacin solicitada de los participantes e ingenieros de software y los datos de las mtricas recopiladas en proyectos anteriores

Observaciones acerca de la estimacin

Aunque la estimacin es tanto un arte como una ciencia, esta importante actividad no necesita realizarse en una forma improvisada. Existen tcnicas tiles para la estimacin del tiempo y el esfuerzo
Puesto que la estimacin coloca los cimientos para las dems actividades de planificacin de proyecto y proporciona la ruta para la ingeniera del software exitosa, se estara mala aconsejado si se embarcara sin ella.

 El grado de la estimacin se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas para recursos, costos y programa de trabajo.
En los enfoques modernos de la ingeniera del software como el modelo incremental se asume una visin iterativa del desarrollo.

El Proceso de Planificacin
El objetivo de planificacin del proyecto de software es proporcionar un marco de trabajo que permita la gestor estimar razonablemente recursos, costos y programa de trabajo.
El plan se debe adaptar y actualizar conforme avance el proyecto

El Proceso de Planificacin

mbito del Software

El mbito del software describe las funciones y caractersticas que se entregaran a los usuarios finales, los datos de entrada y salida, el contenido que se presenta a los usuarios como consecuencia de emplear el software, as como el desempeo, las restricciones, las interfaces y la confiabilidad que delimitan el sistema
El mbito se define al usar una de las dos tcnicas siguientes: 1. Despus de una comunicacin con todos los participantes se desarrolla una descripcin narrativa del mbito del software 2. Los usuarios finales desarrollan un conjunto de caos de uso

Consejo
La factibilidad del proyecto es importante, pero una consideracin de las necesidades del negocio es incluso mas importante. No es bueno construir un sistema o producto de alta tecnologa que nadie quiere

Recursos
La segunda tarea de la planificacin es la estimacin de los recursos necesarios para completar el esfuerzo de desarrollo de software:
Personal

Componentes de software reutilizable

Entorno de desarrollo (hardware y herramientas de software)

Recursos Humanos
El planificador comienza evaluando el mbito del software y seleccionando las habilidades requeridas para completar el desarrollo.
Se especifican la posicin organizacional (gestor, ingeniero de software ejecutivo), la especialidad (telecomunicaciones, BD) El numero de personas que requiere un proyecto de software solo se determina despus de que se ha hecho la estimacin del esfuerzo por ejemplo: Personas - Mes

Recursos de Software Reutilizable

La ingeniera del software basada en componentes enfatiza la reutilizacin; es decir la creacin y reutilizacin de bloques de construccin de software. Tales bloques, usualmente llamados componentes, deben catalogarse para consultarlos con facilidad, estandarizarse para facilitar su aplicacin y validarse para integrarlos fcilmente.

Categoras de Recursos de Software

Componentes ya desarrollados El software existe se puede adquirir de un tercero o se desarrollo internamente para un proyecto previo. Componentes experimentados Especificaciones, diseos, cdigo o datos de prueba que se desarrollaron para proyectos previos

Categoras de Recursos de Software

Componentes de experiencia parcial - Especificaciones, diseos, cdigo o datos de prueba existentes que se desarrollaron para proyectos previos pero requieren modificaciones sustanciales
Componentes nuevos El equipo de software debe construir los componentes de software especficamente para las necesidades del proyecto actual

Recursos del Entorno

El entorno de ingeniera del software (EIS), incorpora hardware y software. El hardware proporciona una plataforma que soporta las herramientas (software) con que se producen los productos de trabajo.

Estimacin de Proyectos de Software

El software es el elemento mas caro; En sistemas complejos, personalizados un gran error en la estimacin del costo puede hacer la diferencia entre beneficio y perdida.
La estimacin del costo y esfuerzo nunca ser una ciencia exacta. Demasiadas variables pueden afectar el costo final del software y el esfuerzo aplicado al desarrollo.

Para lograr una estimacin confiable de costo y esfuerzo se deben considerar estas opciones:
1. Demorar la estimacin hasta mas tarde en el proyecto 2. Basar las estimaciones en proyectos similares que hayan sido completados 3. Emplear tcnicas de descomposicin relativamente simples para generar estimaciones de costo y esfuerzo del proyecto 4. Utilizar uno o mas modelos empricos en la estimacin de costo y esfuerzo

Tcnicas de Descomposicin
Tamao del Software

La precisin de la estimacin de un proyecto de software se manifiesta en varios factores.

1. El grado con el cual el planificador ha estimado adecuadamente el tamao del producto que se construir 2. La habilidad para traducir la estimacin del tamao en esfuerzo humano, programa de trabajo y dinero 3. El grado en el cual el plan de proyecto refleja las habilidades del equipo de software 4. La estabilidad de los requisitos del producto y en el entorno que soporta el esfuerzo de ingeniera del software

Puesto que la estimacin de un proyecto solo es tan buena como la estimacin del tamao del trabajo para realizarlo, el tamao representa el primer gran desafo del planificador del proyecto. Como se mide el tamao del software que se planea construir? Tamao de lgica difusa Tamao de punto de funcin Tamao de componentes estndar

Tamao del cambio

Estimacin Basada en el Problema

Se pueden utilizar los datos de las LDC y PF se utilizan en dos formas al estimar el proyecto del software
1. Como una variable para de la estimacin del tamao de cada elemento del software.

2. Como mtricas de lnea base de recolectadas de proyectos previos y utilizarlos para desarrollar proyecciones de costo y esfuerzo.

Al estimar los datos de LDC y PF se podrn aplicar las mtricas de la lnea base de productividad a la variable de estimacin por ejemplo LDC/pm o PF/pm. Las estimaciones de funcin se combinan para producir una estimacin global de proyecto completo. Sin embargo, es importante notar que con frecuencia existe una dispersin sustancial en las mtricas de productividad de una organizacin, lo que hace sospechoso el uso de una sola mtrica de lnea base de productividad

Prueba
Explique la Tarea de Definir los Recursos Requeridos

Explique El Proceso de Planificacin y enumere sus pasos

Para lograr una estimacin confiable de costo y esfuerzo se deben considerar estas opciones:

Explique la Estimacin Basada en el Problema

Estimacin con Casos de Uso

Los casos de uso permiten que un equipo de software comprenda el mbito del software y los requisitos.
Sin embargo, desarrollar en un enfoque de estimacin de casos de uso es problemtico por las siguientes razones:

Los casos de uso se describen empleando muchos formatos y estilos diferentes; no existe un formato estndar
Los casos de uso representan una visin externa del software y con frecuencia estn escritos con diferentes grados de abstraccin

 Los casos de uso no abordan la complejidad de las funciones ni de las caractersticas que se describen
Los casos de uso no describen el comportamiento complejo que involucran muchas funciones y caractersticas

A diferencia de las LDC y PF, el caso de uso de una persona tal vez requiera meses de esfuerzo mientras que el de otra quiz se implemente en un da o dos por lo que al da de hoy no existe un mtodo de estimacin probado

Reconciliacin de Estimaciones
Cuando la concordancia entre las estimaciones es insuficiente se requiere reevaluar la informacin con que se hicieron las estimaciones.
Causas

El planificador no ha comprendido adecuadamente o ha malinterpretado el mbito del proyecto.

Los datos de productividad que utilizan las tcnicas de estimacin basadas en el problema son inapropiados para la aplicacin, obsoletos o se han aplicado mal

Modelos Empricos de Estimacin

Un modelo de estimacin refleja la poblacin de proyectos desde la que se ha derivado. Por lo tanto , el modelo es sensible al dominio.
Por esta razn, ningn modelo de estimacin es apropiado para todas las clases de software ni en todos los entornos de desarrollo. En consecuencia, los resultados obtenidos a partir de tales modelos se deben emplear juiciosamente

La Estructura de los Modelos de Estimacin

LDC Modelo Walston-Felix Modelo Bailey-Brasili Modelo simple de Boehm Modelo Doty para KLDC > 9
Un rpido examen de estos modelos indica que c/u producira un resultado diferente para los mismo valores de LDC y PF por lo que los modelos de estimacin deben calibrarse cuidadosamente a su entorno.

PF Modelo de Albrecht y Gaffney Modelo de Kemerer Modelo de regresin para proyecto pequeo

Modelo COCOMO II
COnstructive COst MOdel (Modelo Constructivo de Costos)
El Modelo COCOMO original se volvi uno de los mas ampliamente utilizados y estudiados de modelos de estimacin de costo de software en la industria.

COCOMO II es en realidad una jerarqua de modelo de estimacin que aborda las reas siguientes:
Modelo de Composicin de la Aplicacin: se emplea durante las primeras etapas de la ingeniera de software

Modelo de Etapa de Diseo Temprano: se utiliza una vez que se han establecido los requisitos y la arquitectura bsica del software.
Modelo de Etapa Posterior a la Arquitectura: se emplea durante la construccin del software

Al igual que los modelos de estimacin de software, los modelos COCOMO II requieren informacin del tamao. (Puntos objeto, PF y LDC)
El punto de objeto es una medida indirecta de software que se calcula mediante conteos de numero de:
Pantallas (Interfaz de Usuario) Reportes Componentes que probablemente se requieran para construir una aplicacin Cada instancia de objeto se clasifica en uno de tres niveles (Simple, Medio o Dificil

Estimacin Para Proyectos Orientados a Objetos

1. Desarrollar estimaciones aplicando la descomposicin de esfuerzo 2. Aplicar el modelado de anlisis orientado a objetos 3. A partir del modelo de anlisis, determinar el numero de clases clave 4. Categorizar el tipo de interfaz para la aplicacin y desarrollar un multiplicador para las clases de soporte

5. Multiplicar el numero total de clases por el promedio de unidades de trabajo por clase (sugerencia de 15 a 20 personas)
6. Comprobar de manera cruzada la estimacin basada en clase al multiplicar el numero promedio de unidades de trabajo por caso de uso

Tcnicas de Estimacin Especializadas

Las tcnicas de estimacin estudiadas en las secciones anteriores se pueden aplicar en cualquier proyecto de software. Sin embargo, cuando un equipo de software encuentra una duracin extremadamente corta y que probablemente tenga una continua corriente de cambios llevara a que la planeacin del proyecto y la estimacin en particular se deban abreviar

Estimacin Para Desarrollo gil

Puesto que los requerimientos para un proyecto agil se definen como un conjunto de escenarios de usuario (Historias Programacin Extrema) es posible desarrollar un enfoque de estimacin informal, aunque razonablemente disciplinado y significativo dentro de la planificacin del proyecto para cada incremento de software

Descomposicin en Pasos para la estimacin de Proyectos Agiles

1. Cada escenario de usuario se considera por separado

2. El escenario se descompone en el conjunto de funciones y tareas de ingeniera del software que se requieran para desarrollarlo
3. A. Cada tarea se estima por separado (Datos histricos, modelo emprico o experiencia) B. Alternativamente el tamao del escenario se puede estimar en LDC, PF y PO 4. A. La estimacin de cada tarea se suman para tener la estimacin del escenario

B. Alternativamente, el volumen estimado para el escenario se traduce en esfuerzo 5. Las estimaciones de esfuerzo acerca de todos los escenarios se suman para tenerla estimacin de esfuerzo por incremento