Unidad 2. Planeacion

Mtricas de desarrollo de software Unidad 2. Planeacin

Ejecutas el editor1 Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software 1

Ingeniera en Desarrollo de software

Cuatrimestre 07

Programa de la asignatura:

Mtricas de desarrollo de software

Clave: 150930728



ndice

UNIDAD 2. PLANEACIN: INTRODUCCIN, MEDICIN Y ESTIMACIN. ..................... 4 Presentacin de la unidad ........................................................................................................... 4

Propsito ........................................................................................................................................ 4

Competencia especfica .............................................................................................................. 5

2.1. Introduccin a la planeacin ............................................................................................... 5

2.1.1. Qu es un plan? .............................................................................................................. 5

2.1.2. Por qu hacer planes? ................................................................................................... 6

2.1.3. Contenido del plan de un software ................................................................................. 7

2.1.4. Planeando un proyecto de software ............................................................................... 9

2.1.5. Producir un plan de calidad ........................................................................................... 10

2.1.6. Etapas de la planeacin ................................................................................................. 11

Actividad 1. Plan del proyecto .................................................................................................. 12

2.2. Medicin del tamao del software .................................................................................... 13

2.2.1. Medicin del tamao ....................................................................................................... 14

2.2.2. Establecer un conteo estndar ...................................................................................... 16

2.2.3. Contadores de LOC y tipos............................................................................................ 17

2.2.4. Consideraciones del re-uso ........................................................................................... 18

2.2.5. Conteo de lneas de cdigo ........................................................................................... 18

2.2.6. Calcular la productividad ................................................................................................ 19

2.2.7. PSP 0.1 ............................................................................................................................. 20

Actividad 2. Medicin del tamao de un software ................................................................ 21

2.3. Estimacin del tamao del software ................................................................................ 27

2.3.1. Contexto ............................................................................................................................ 27

2.3.2. Mtodos de estimacin................................................................................................... 28

2.3.3. Proxy ................................................................................................................................. 28

2.3.4. Probe ................................................................................................................................. 30

2.3.5. PSP 1 ................................................................................................................................ 31

Actividad 3. Estimacin del tamao de un software ............................................................ 32

Autoevaluacin ........................................................................................................................... 33



Evidencia de aprendizaje. Programa PSP 1 .......................................................................... 34

Autorreflexiones .......................................................................................................................... 36

Para saber ms ........................................................................................................................... 36

Fuentes de consulta ................................................................................................................... 36



Unidad 2. Planeacin: introduccin, medicin y estimacin

En esta unidad se tratarn los temas relacionados con la medicin del tamao de un

proyecto de software. A su vez, esta medicin proporcionar una base inicial para poder

estimar el tamao nuevos proyectos con la finalidad de poder realizar planes lo ms

cercano a la realidad.

En la mayora de los proyectos, existen recursos limitados (dinero, personas, equipos,

tecnologa). Este factor conlleva a que los proyectos tengan que planearse y gestionarse

de la forma ms efectiva y asertiva posible, con la finalidad de que el costo total del

proyecto no exceda la cantidad de recursos planeados que son destinados a ese

proyecto. Sin embargo, para poder planear algo, primero se debe ser capaz de estimar

cunto tiempo, costo y personal que se requiere dentro del proyecto. Para poder estimar,

se requiere medir el proyecto, la medicin es una tarea fundamental en la mayora de las

disciplinas donde se emprenden proyectos. Dependiendo del contexto, se utiliza una

mtrica o forma de medir. Por ejemplo, para la construccin, es comn medir en reas lo

que se va a construir utilizando alguna unidad como: m2. De igual forma, para estimar el

tamao un nuevo proyecto de software primero se debe tener una forma o mtrica de

medicin enfocada en la medicin de un programa.

Presentacin de la unidad

En esta unidad conocers lo importante que es realizar una planeacin previa al

desarrollo de un nuevo proyecto de software.

Aprenders por qu es necesario realizar planes, as como el contenido de una

planeacin. Entenders por qu mientras ms detallados sean tus planes, ms precisas

sern tus estimaciones de tiempo y costos antes de comenzar el desarrollo de un nuevo

proyecto. As mismo, tendrs elementos y bases para gestionar cambios en los

requerimientos planeados, para un nuevo proyecto de software y cmo deben ser

manejados dichos cambios antes de su implementacin en el proyecto.

Finalmente, conocers algunas tcnicas para estimar el tamao de un proyecto de

software y como ste, est relacionado con el tiempo que tomar desarrollarlo.

Propsito

En esta unidad logrars:

- Comprender lo que es un plan para un proyecto de software y lo que debe

contener.

- Conocers algunas tcnicas para estimar el tamao de un proyecto de software.



- Conocers algunas tcnicas para estimar el tiempo que tomar desarrollar un

nuevo proyecto de software.

Competencia especfica

Aplicar la medicin y estimacin para planear un programa, tomando en cuenta el plan,

sus etapas, criterios y estndares de medicin, as como diferentes mtodos de

estimacin.

2.1. Introduccin a la planeacin

En esta unidad se analizar la importancia de planear un proyecto de software antes de

realizar cualquier actividad relacionada con el desarrollo del mismo. As mismo, se

analizar de forma detallada, cmo realizar la planeacin de un nuevo proyecto de

software y como, un plan bien realizado, brinda una mayor confiabilidad para el xito en la

realizacin de un nuevo proyecto de software.

Por naturaleza, los seres humanos, al emprender nuevos proyectos necesitamos tener

una gua o conocer los procesos, acciones o medidas que deben ser seguidas para lograr

realizar ese proyecto hasta su finalizacin. A lo largo de toda su vida, el ser humano

emprende proyectos: aprobar una materia de la escuela, construir un prototipo que ayuda

a resolver un problema, concursar y ganar una competencia de deportes, etc.

Comnmente, aquellos proyectos en los que mejores resultados se obtienen son aquellos

para los cules tenamos una mejor gua de cmo realizarlos. En otras palabras, tenamos

un plan lo suficientemente sustentado para lograr resultados efectivos al trmino del

proyecto.

En la ingeniera de software, la planeacin de los proyectos enfocados en el desarrollo de

nuevas tecnologas de informacin es una de las etapas ms importantes para el xito de

dicho proceso, pues como veremos ms adelante, la calidad del producto final est dada

por la calidad en cada uno de los procesos llevados a cabo. En este sentido, la planeacin

es el primer proceso llevado a cabo al desarrollar un nuevo producto de software.

Una vez que se ha brindado un panorama general sobre la planeacin de proyectos

incluyendo proyectos de software, es necesario conocer que es realmente un plan. Esto

ser explicado en el siguiente tpico.

2.1.1. Qu es un plan?

En este tpico se explicar y comprender lo que es un plan y como est estrechamente

relacionado con la culminacin exitosa de un nuevo proyecto.



Un plan no es ms que una gua que nos muestra los pasos, procedimientos o medidas a

seguir para lograr un objetivo o meta determinada. La mayora de las veces, el xito que

se tiene en un proyecto est en funcin de la calidad del plan que se realiza antes de

comenzar el desarrollo de ese proyecto. A su vez, la calidad de un plan est dada por el

sustento y validez de las bases sobre cules se apoya dicho plan.

Para comprender lo anterior, veamos el siguiente ejemplo:

Pedro se entera, a mitad de su periodo escolar, que existe un concurso de proyectos

finales para la materia de desarrollo de aplicaciones. Al equipo o desarrollador del

proyecto ganador se le otorgar un premio que consiste en un par de equipos de cmputo

porttiles y dispositivos de cmputo mviles de ltima generacin.

Al pensar Pedro en su proyecto, se da cuenta que anda un poco retrasado en el avance

del mismo. Sin embargo, cree que no puede dejar pasar esa oportunidad ya que con

algunos ajustes, su proyecto tendra altas posibilidades de ser el mejor.

Qu podra hacer Pedro para poder tener las mayores posibilidades de ganar el

concurso?

Sin otro conocimiento acerca del problema, lo primero que podramos pensar en realizar

es el conocer el estado actual del proyecto de Pedro, analizar y delimitar un conjunto de

mejoras de acuerdo al conocimiento general que se tiene de los otros proyectos. Despus

habra que definir un conjunto de actividades por realizar as como un tiempo estimado

para concluir cada actividad con la finalidad de lograr obtener un proyecto con altas

posibilidades de ser exitoso.

Una vez que se ha entendido y comprendido lo que es un plan as como su utilizacin en

el desarrollo de nuevos proyectos, se analizarn algunas situaciones que remarcan la

necesidad de realizar planes previos al desarrollo de nuevos proyectos.

2.1.2. Por qu hacer planes?

Como se vio anteriormente, la planeacin es una etapa que tiene como finalidad aumentar

las posibilidades de xito que tendr un proyecto. Sin embargo, existen factores

subyacentes al xito del proyecto los cules describiremos en este tpico y que sustentan

la importancia que tiene el realizar planes al emprender nuevos proyectos que involucran

el desarrollo de productos de software.

Al proponer una solucin a un problema relativo a la falta de informacin vigente y

confiable, generalmente se involucra en dicha solucin, un sistema de informacin el cual,

la mayora de las veces, no existe a la medida de la persona o empresa que tiene el

problema descrito anteriormente. Esto conlleva a desarrollar un software que satisfaga las

necesidades de informacin de la empresa o persona en particular.

Al desarrollar productos de software para un cliente -que puede ser algn directivo para la

empresa para la cual se trabaja o bien un cliente externo-; en el caso de tener una



empresa que se dedica al desarrollo de proyectos de software, es comn que se realicen

dos cuestionamientos:

- Cunto tiempo tomar desarrollar el sistema?

- Cunto va a costar?

Si el cliente cuenta con varias opciones para el desarrollo de su programa, quizs opte

por el proyecto que consuma menos tiempo en realizarse y que sea ms barato. Sin

embargo, esta eleccin no siempre es la ms adecuada como veremos en seguida.

Cuando se responde a un cliente las dos preguntas anteriores, sobre qu bases es

respondido el tiempo que tomar desarrollar el sistema?

Cuando no se lleva una metodologa que involucre una slida planeacin en el desarrollo

de nuevos proyectos, se suele responder en base a la experiencia propia. Sin embargo,

qu tan acertada es una respuesta de este tipo? Generalmente, existe poca asertividad

y generalmente se planea menos tiempo del que realmente se requiere para desarrollar el

proyecto. Un factor adicional frecuente, que lleva a realizar una mala estimacin, es la

competencia para ser elegidos por el cliente para el desarrollo de dicho proyecto. Esto

conlleva a subestimar el esfuerzo real que requiere el proyecto y se propone un tiempo

relativamente corto para la realizacin del mismo. Al final, el proyecto podra tardarse 2

3 veces ms el tiempo estimado. Por eso, se mencion anteriormente que la eleccin del

tiempo ms corto no siempre es la ms adecuada. Sin dejar de lado, que el costo de un

proyecto tambin est relacionado con el tiempo en que se desarrolla.

Con base en la informacin anterior, podemos deducir lo importante que es el realizar una

planeacin de los nuevos proyectos de desarrollo de software para lograr las mayores

posibilidades de xito. (Zapata, J., Garca, J., Cerrada, J. 2001. Pg. 43-55).

2.1.3. Contenido del plan de un software

Para que un plan, previo al desarrollo de un nuevo proyecto de software, sea efectivo,

debe contener ciertos elementos relativos a las tareas que debern realizarse, el tamao

del proyecto, la forma de medir el status del proyecto en cualquier momento, etc. Todo

esto ser analizado y discutido en este tpico.

El contenido de un plan depende de las necesidades de las personas que utilizarn dicho

plan y de lo que requieran hacer con l. En PSP la planeacin involucra a dos tipos de

persona: el desarrollador y sus clientes.

Una planeacin en PSP involucra definir y conocer los siguientes 4 factores:

1. Tamao del producto. Qu tan grande es el proyecto?



2. Definicin de las tareas que tienen que realizarse y como se realizarn.

3. Estatus del trabajo que se est realizando. Esto significa saber en qu etapa

estamos, qu falta por hacer. Esto nos permite responder una pregunta crtica muy

importante: Se terminar el producto en el tiempo estimado con los costos

planeados?

4. Evaluacin. Este factor se refiere a la evaluacin de la planeacin realizada y

responde a las preguntas: Qu tan efectiva fue la planeacin? Se cometieron

errores obvios de detectar? Qu errores se pueden evitar en el futuro? Qu se

requiere ajustar o modificar para realizar una mejor planeacin?

De lo anteriormente expuesto, Humphrey, W. (1995), menciona que el factor 4 es de

vital importancia pues es la clave para mejorar la efectividad de las planeaciones que

se realizarn posteriormente para nuevos proyectos.

Es necesario mencionar que al utilizar PSP, todo lo que realizamos es un trabajo

completamente individual. En este contexto, el contenido de las planeaciones debe

permitir saber:

1. Qu se tiene que entregar?, Cundo?, Cunto costar?

2. El proyecto que se planea desarrollar, es realmente lo que el cliente quiere?

3. Existe algn mecanismo que permita medir, monitorear o conocer el avance del

proyecto en cualquier momento?

En proyectos pequeos, la administracin y control de los aspectos anteriores

probablemente no sean complejos; sin embargo, se debe ser consciente de lo siguiente:

- La planeacin debe estar basada en tareas bien definidas.

- Cada tarea debe estar claramente definida y debe ser posible medirla.

- El cliente debe conocer el plan y estar de acuerdo con l antes de comenzar

cualquier tarea.

- Se debe reportar el avance del proyecto cada determinado tiempo. Este reporte

generalmente se debe presentar a los administradores y clientes para que

conozcan cmo va evolucionando el desarrollo del mismo.

Siempre hay que tener en cuenta que: cuando se planea el trabajo personal, el objetivo es

calcular el tiempo que tardar en desarrollarse un determinado proyecto, el costo que

tendr y qu fechas se tienen planeadas para terminar cada una de las tareas a realizar

(Humphrey, W. 1995. pp. 57-68).

En el siguiente tpico se comprender como comenzar la planeacin de un nuevo

proyecto as como los pasos necesarios para poder obtener un plan lo ms acertado

posible conforme a la realidad.



2.1.4. Planeando un proyecto de software

En este tpico se analizarn los pasos necesarios para realizar el plan de desarrollo de

nuevos proyecto de software. Se aprender en primera instancia la secuencia ordenada

de actividades a realizar, para poder obtener un plan de calidad previo al desarrollo de un

proyecto de software.

Al planear un proyecto de software, se debe tomar en cuenta lo siguiente:

1. Se debe tener claramente definido lo que ha de realizarse as como entender

perfectamente lo que se busca hacer. Durante el desarrollo del proyecto es

frecuente que existan cambios en los requerimientos. Sin embargo, es necesario

planear y definir el mayor nmero de dichos requerimientos tanto como sea

posible.

2. Dividir las tareas de desarrollo del proyecto que tomarn varios das en varias

tareas ms pequeas que podamos medir y estimar de forma separada. Es

importante mencionar que: a mayor detalle en la especificacin de las tareas que

han de desarrollarse, la planeacin ser ms precisa.

3. Cuando se realiza la estimacin de tareas, se deben comparar con otras tareas

similares que se hayan realizado en el pasado para conocer el tiempo que se

dedic a esas tareas pasadas y estimar el tiempo que tomar realizar la tarea

planeada.

4. Se debe documentar la estimacin y al trmino del proyecto, se deben comparar

los datos de la estimacin contra los datos reales. Esto nos permite conocer de

forma clara y consciente el por qu hubo diferencias entre el tiempo planeado y el

real. Este nuevo conocimiento adquirido tendr una vital importancia al estimar y

planear nuevos proyectos de software.

5. Si existen cambios en los requerimientos, se debe reajustar la planeacin y antes

de comenzar la implementacin de cualquier cambio en los requerimientos, se

debe informar a los jefes inmediatos as como al cliente para concientizarlos de lo

que implica en tiempos y costos la implementacin de dichos cambios de

requerimientos y en base a ello, se tome la decisin de implementar o no dichos

cambios.

La Figura. Secuencia de pasos a seguir para elaborar un plan de desarrollo de un nuevo

proyecto de software (Humphrey, W. 1995. Pg. 65) muestra los pasos que tienen que

realizarse para obtener un plan eficiente para el desarrollo de un nuevo proyecto:



Figura. Secuencia de pasos a seguir para elaborar un plan de desarrollo de un nuevo

proyecto de software. (Humphrey, W. 1995. Pg. 65).

Una vez que se conocen los pasos necesarios para realizar la planeacin de un proyecto

de software, es necesario conocer aquellos aspectos que dotan de la calidad necesaria a

una planeacin. Mientras ms alta sea la calidad de un plan, mayores son las

posibilidades de xito al trmino del desarrollo del proyecto. (Humphrey, W. 1995. Pg.

57-68).

2.1.5. Producir un plan de calidad

En este tpico se discutir de forma general como producir un plan con la calidad

adecuada para obtener xito en los proyectos planeados. Eso es importante de considerar

pues el xito de un proyecto est dado en gran parte por la calidad del plan que se tiene

para su desarrollo.

El objetivo de planear el trabajo es para obtener un plan preciso que indica qu

actividades han de realizarse y en qu tiempo. Sin embargo, para poder obtener esta

informacin se requiere un estudio profundo que nos permita conocer cmo medir,

predecir y mejorar las planeaciones que realizamos.

Cuando planeamos nuevos proyectos de software lo hacemos de dos formas: imparcial o

balanceado. Se considera que una planeacin est balanceada si por ejemplo, de diez



proyectos, cinco fueron sobreestimados y cinco fueron subestimados. Un proyecto

sobreestimado es aquel en el cual se plane ms tiempo para su realizacin que el

tiempo real. En otras palabras, se tard menos tiempo de lo planeado en realizar el

proyecto. Un proyecto subestimado, al contrario de uno sobreestimado, es aquel en el

que se plane menos tiempo del que realmente se necesit para llevarlo a cabo. Una

planeacin imparcial se da cuando no es balanceada, es decir, el nmero de proyectos

sobreestimados no es igual al nmero de proyectos subestimados. De acuerdo a la

experiencia de Watts Humphrey, el autor del PSP, una planeacin balanceada permite

realizar un mejor ajuste de la estimacin de tiempos para nuevos proyectos, pues al haber

un equilibrio entre los proyectos sobreestimados y los subestimados, se puede fcilmente

obtener un tiempo promedio a travs del mtodo PROBE, el cual veremos ms adelante.

Para terminar de comprender el proceso de la planeacin de un proyecto de software, se

analizarn las etapas involucradas en la planeacin. (Humphrey, W. 2005. Pg. 65).

2.1.6. Etapas de la planeacin

El proceso de planear un proyecto de software est conformado por varias etapas que

sern descritas en este tpico. Es importante que se sigan cada una de estas etapas sin

omitir ninguna con la finalidad de que la planeacin final del proyecto sea lo ms real

posible.

Planear un proyecto de software implica las siguientes etapas:

1. Conocer las necesidades del cliente. Este punto inicial es el ms importante,

pues de este, se deriva prcticamente todo el contenido y alcance del

proyecto a desarrollar. En esta etapa se debe decidir si las necesidades del

cliente realmente involucran el desarrollo de un proyecto de software o por el

contrario, existen otras herramientas previamente desarrolladas que pueden

ayudar a resolver dichas necesidades.

2. Definicin de Requerimientos. En esta etapa, una vez que se ha identificado

que las necesidades del cliente realmente involucran el desarrollo de un

proyecto, se deben identificar dichas necesidades de forma muy particular. Al

trmino de esta etapa lo que se obtiene es un documento con toda la

especificacin de requerimientos y funcionalidades con las que deber contar

el producto final. Tener claros los requerimientos del proyecto ayuda a

proyectar una primera aproximacin sobre qu tan grande puede ser el

proyecto.

3. Realizar un Diseo Conceptual. En esta etapa se debe producir un diseo

preliminar del proyecto a desarrollar. En esta etapa, se suelen identificar y

planear los mdulos que conformarn el producto final as como la interaccin

que tendrn dichos mdulos.



4. Estimar el tamao del proyecto. En esta etapa, se toman datos histricos de

otros proyectos, se busca informacin de mdulos previamente desarrollados

que tengan el mayor parecido con las especificaciones del nuevo proyecto

para poder tener una aproximacin lo ms certera posible del tamao del

proyecto.

5. Planeacin de los recursos. Una vez que se tiene una estimacin del tamao

del proyecto, se deben planear los recursos que intervendrn en el desarrollo

del proyecto.

6. Desarrollo del Proyecto. Una vez que se tiene un plan claro que indica las

fechas de avance y el personal asignado a cada actividad del desarrollo del

proyecto, se puede pasar a la etapa de desarrollo. En esta etapa se llevan a

cabo todas las actividades involucradas en el desarrollo del proyecto. Por

ejemplo: diseo de interfaces, diseo de la arquitectura, diseo e

implementacin de la base de datos, etc.

7. Generacin de nuevos datos. Durante el desarrollo del proyecto, cada

actividad debe ser medida para generar datos histricos del proceso de

desarrollo.

8. Anlisis de Datos. Cuando se concluye el desarrollo del proyecto, es

importante analizar los datos generados, pues estos datos jugarn un papel

esencial al planear nuevos proyectos y estimar su tamao.

Ya que se han comprendido las etapas que involucran la planeacin de un

proyecto de software, se debe comprender el aspecto principal: medir el tamao

del proyecto. Esta es quizs la tarea ms difcil y crtica en la planeacin de un

proyecto. Por lo tanto, el siguiente tema estar completamente enfocado en

describir el proceso de medicin del tamao de un nuevo proyecto de software.

Pero, primero realiza la siguiente actividad.

Actividad 1. Plan del proyecto

Esta actividad tiene como finalidad que demuestres lo que has comprendido respecto a lo

que es un plan de un proyecto de software y que compartas tus soluciones en el Foro con

tus compaeros.

Propsito: Comprender lo que es un plan, su contenido, etapas y como se planea un

proyecto de software

Instrucciones:

1. Lee la problemtica planteada.

Existe un cliente cuya problemtica involucra el desarrollo de un nuevo proyecto de

software. A continuacin se enlistan varias actividades y sucesos previos al desarrollo del

proyecto.



1. El responsable del proyecto estima el tamao del proyecto tomando cada

mdulo pensado para el proyecto y comparndolo contra otros mdulos de

proyectos anteriores para identificar el ms parecido y estimar su tamao.

( )

2. El responsable del proyecto establece las fechas en que cada actividad

correspondiente al desarrollo del proyecto deber ser realizada.

( )

3. El responsable del proyecto, junto con un analista se rene con el cliente para

identificar de forma especfica lo que se espera del proyecto a desarrollar.

( )

4. El responsable del proyecto comienza a planear cules personas podran

trabajar en el desarrollo del proyecto.

( )

5. El responsable del proyecto se auxilia con un arquitecto de software para

realizar un diseo general de los mdulos que debera contener el proyecto.

( )

2. Analiza los casos anteriores, e identifica las etapas que conlleva la planeacin de ese

proyecto de software.

3. Indica a qu etapa de la planeacin corresponde cada una de las actividades

mencionadas en el punto 1:

(a) Definicin de Requerimientos

(b) Realizar un diseo conceptual

(c) Estimar el tamao del proyecto

(d) Estimar los recursos necesarios

(e) Calendarizar las actividades

4. Ingresa al Foro y comparte al menos con tres compaeros las soluciones de la

actividad.

5. Atiende a las indicaciones que te d tu facilitador(a), pues, en el foro tendrs que

argumentar el porqu de tus respuestas.

6. No olvides consultar la rbrica general de participacin en foros.

Como pudiste darte cuenta, la planeacin es un elemento clave en el desarrollo de

cualquier proyecto de software, ya que si no planeas las actividades que necesitas de tu

proyecto hay una gran probabilidad de que no las realices. Y si no registras las

actividades que realices, no podrs identificar cunto tardas en realizarlas. Es por ello

que realizar planes es una buena prctica en el desarrollo de software.

2.2. Medicin del tamao del software

Cuando planeamos nuevos proyectos de software, inevitablemente tenemos que estimar

o tener un conocimiento preliminar sobre el tiempo que nos tomar realizar dicho

proyecto. Esta etapa cobra una vital importancia, pues de los datos que se generen

depende en gran medida el costo que tendr el proyecto para el cliente.



Sin embargo, para poder estimar o predecir cunto tiempo se requiere para desarrollar el

proyecto, es necesario conocer o tener una medida del mismo. Y un par de preguntas que

surgen son: cmo medimos un proyecto de software? qu medida es la ms precisa?

En este captulo se analizarn algunas tcnicas para medir y estimar el tamao de nuevos

proyectos de software, pues a travs de los aos, el estudio e investigacin sobre PSP,

por parte de Watts Humphrey, ha recopilado una serie de datos y buenas prcticas que

ahorrarn en gran medida la investigacin y aprendizaje en este tema. (Zapata, J., Garca,

J., Cerrada, J. 2001. Pg. 58-71).

2.2.1. Medicin del tamao

Para comprender las mtricas para el tamao de un producto de software conviene

responder la siguiente pregunta: por qu medir el tamao?

Como se mencion en la introduccin a este captulo, conocer el tamao de algo, en este

caso, de un proyecto de software, es fundamental para poder estimar cunto tiempo

tomar desarrollar dicho proyecto. Una vez que se conoce la importancia de medir el

tamao, la siguiente pregunta que se hace es: cmo se puede medir el tamao de un

proyecto de software?

Responder a la pregunta anterior ha sido uno de los retos ms controversiales que ha

tenido la ingeniera de software desde que los proyectos tuvieron la necesidad de

planearse, en la dcada de 1970. A lo largo de ese tiempo, los lenguajes y paradigmas de

la programacin han estado en constante cambio. Este factor ha sido determinante para

hacer an ms complejo el obtener una mtrica o forma de medir el tamao de un

proyecto de software de forma precisa en un cien por ciento. Por lo tanto, no existe una

mtrica que sea exacta por completo, sino por el contrario, todas las mtricas que se han

utilizado hasta ahora son aproximaciones, sin embargo, si existen diferencias

considerables en la exactitud y eficacia de cada una de ellas.

Para que una mtrica, en cualquier contexto y escenario, sea til, debe cumplir lo

siguiente (Humphrey, W. 1995.):

- Debe servir para un propsito especfico. Por ejemplo, la unidad de medida litro

sirve especficamente para medir volmenes. Querer medir el peso con una

mtrica o instrumento que mide volumen sera muy difcil a la vez que los

resultados seran inadecuados y poco tiles. En el contexto de la ingeniera de

software, medir el tamao de un producto debe servir a un propsito muy

especfico: conocer de forma puntual que tan grande es un proyecto de software.

- Debe estar bien definida. Esto significa que las unidades que se utilicen para medir

deben estar claramente definidas de tal forma que no presenten ambigedades.



Por ejemplo, la unidad de medida metro est bien definida y cualquier cinta

mtrica o regla que utilicemos para medir por ejemplo, el largo de una mesa, nos

dar la misma medida para esa misma mesa. Aplicando este ejemplo en la

ingeniera de software, se requiere de una unidad de medida lo ms exacta posible

y que no tenga ambigedades cada vez que se aplique en la medicin de

proyectos de software.

- Debe ser adecuadamente administrada. Generalmente, conocer la medida de algo

tiene implicaciones para tomar una decisin o hacer algo con esa medida

conocida. Por ejemplo, conocer el rea que ocupa una mesa es podra ser de

utilidad para escoger el mantel que mejor la cubra. De igual forma, las mtricas de

desarrollo de software deben aportar utilidad para administrar y controlar el

proyecto.

- Debe ser adecuadamente utilizada. Los datos obtenidos con una mtrica

determinada deben ser adecuadamente utilizados. Por ejemplo, medir el rea de

un cuarto sera poco til si buscamos elegir el color de piso que mejor combine

con el diseo de dicho cuarto. En todo caso, es mejor utilizar otra unidad de

medida, como por ejemplo, el color ms representativo o la luminosidad del cuarto.

En el contexto de la ingeniera de software, las mtricas para medir el tamao de

un proyecto de software deben utilizarse para tal fin. Sera ilgico utilizar una

mtrica de tamao de software para elegir el tamao del monitor ideal para la

computadora donde se instalar el sistema a desarrollar en ese proyecto.

Por lo tanto, medimos para:

- Entender y saber administrar los cambios

- Planear el futuro

- Comparar un producto, organizacin o proceso con otro

- Determinar si estamos apegados a estndares

- Contar con bases para controlar

Se tiene que ser consciente qu las medidas solo producen nmeros. Para que una

medida sea de utilidad, debe:

- Estar relacionada con los objetivos que se plantean alcanzar. Si lo que medimos

no est relacionado con los objetivos que deseamos lograr, no hay razn para

invertir esfuerzos en medir aquello.

- Ser adecuadamente interpretada. Una vez que obtenemos una medida, debemos

entender lo que esa medida significa y lo que no. Por ejemplo, conocer el nmero

de tablas que tendr la base de datos no significa conocer cuntas de esas tablas

sern catlogos que impliquen su propia interface para altas, bajas y cambios.

- Permitir tomar acciones apropiadas. El conocer la medida de algo, nos debe ser

utilidad para tomar acciones apropiadas ya sean de carcter preventivo, correctivo



o las acciones de curso normal para lograr los objetivos planteados al inicio del

desarrollo del proyecto as como para efectuar una mejor planeacin de nuevos

proyectos.

A lo largo del tiempo, se han propuesto varias tcnicas para medir el tamao de un

proyecto de software. A continuacin se mencionan algunas de ellas:

- Nmero de archivos que tendr el programa

- Nmero de mdulos que tendr el programa

- Nmero de tablas en la base de datos

- Nmero de pantallas que tendr la aplicacin

- Puntos de funcin

- Lneas de cdigo

De las tcnicas mencionadas anteriormente, la que ms efectiva ha sido en el PSP es la

mtrica por lneas de cdigo. Como su nombre lo indica, esta tcnica se basa en contar

las lneas de cdigo que tiene o tendr el proyecto de software. Esto ser tratado con

mayor detalle en los siguientes tpicos. (Humphrey, W. 1995. Pg. 69-90).

2.2.2. Establecer un conteo estndar

Al elegir una mtrica para calcular el tamao o la medida de algo, se debe responder lo

siguiente: si dos personas miden la misma cosa, obtienen el mismo resultado?

Responder a la pregunta anterior es fundamental, pues de ello depende la confiabilidad

en la precisin de la mtrica que estamos aplicando para medir algo. Si cada vez que

medimos la misma cosa en las mismas condiciones obtenemos resultados distintos,

inevitablemente deberemos tomar algn otro criterio o mtrica ms estable que nos

permita obtener confiabilidad en las medidas que nos arroja.

Para poder homogenizar una mtrica y aumentar su confiabilidad, es necesario realizar un

estndar de conteo.

Un estndar de conteo es un documento que expresa de forma clara y sin ambigedad

qu es algo contable y qu no lo es, de acuerdo con una mtrica determinada. En el caso

de la mtrica de lneas de cdigo, en dicho estndar se debe definir lo que s debe ser

contado como una lnea de cdigo y lo que no. Por ejemplo, los comentarios en el cdigo,

deben ser considerados como lneas de cdigo o no? Decidir si las lneas de un

comentario en el cdigo fuente de un programa o mdulo sern contadas depende de

quien realiza el estndar de conteo de lneas de cdigo y del criterio que aplique para

tomar esta decisin.



2.2.3. Contadores de LOC y tipos

Llevar un conteo de lneas de cdigo de forma manual es muy difcil e impreciso. Por tal

motivo, existen distintas herramientas que ayudan a los ingenieros de software con esta

tarea. Sin embargo, se tiene que considerar que los contadores de lneas de cdigo

automatizados solamente trabajarn para las caractersticas que se han definido en dicho

contador. En otras palabras, al elegir un programa contador de lneas de cdigo, debemos

asegurarnos que dicho programa se apega al estndar de conteo definido con

anterioridad. De otra forma, sera impreciso y poco til el utilizar esa mtrica si no se

apega al estndar de conteo definido previamente. Una prctica comn para salvaguardar

este escenario es el de tomar con estndar de conteo de lneas el propio estndar que ya

trae por definicin el programa contador de lneas de cdigo elegido (Humphrey, W. 2005.

Pg. 35-55).

De las diversas soluciones que existen, algunas son de pago y otras gratuitas. La

diferencia entre unos y otros son bsicamente las prestaciones que brindan as como los

lenguajes y plataformas que soportan.

A continuacin se mencionan algunos contadores de lneas de cdigo y sus

caractersticas:

Programa Gratuito Pgina de la

compaa

Plataformas y

lenguajes soportados

Code Counter Pro No http://www.geronesoft.

com/

Varios

Microsoft LOC

Counter

Si http://archive.msdn.mi

crosoft.com/LOCCount

er

Lenguajes de la

plataforma .Net 4.0

Code Line Counter

Pro

No http://www.codelineco

unter.com/

Varios. Se compra por

separado para cada

lenguaje distinto.

Tabla. Software para contar lneas de cdigo.

No importa cul sea la herramienta que utilices, si tu equipo no tiene correctamente

definidos los estndares de conteo habr discrepancia en la forma de contar de cada

programador. Por ejemplo el cdigo de re-uso no debera contarse a menos que hagas

mejoras. En el siguiente tema se explica en que consiste este tipo de cdigo y su utilidad

para las empresas de desarrollo.



2.2.4. Consideraciones del re-uso

Generalmente, al desarrollar nuevos proyectos, se intenta reducir el esfuerzo requerido en

el desarrollo. Una de las prcticas comunes es buscar cdigo existente de proyectos

previos para reutilizarlo en los nuevos evitando invertir esfuerzos para obtener un cdigo

que hace la misma funcin de uno que previamente ya se haba desarrollado. Tambin,

es comn en pensar en modificar un cdigo existente y simplemente adaptarlo antes que

crear uno completamente. Sin embargo, debe evaluarse si el esfuerzo requerido para

modificar un cdigo existente realmente es menor que el necesario para crear ese cdigo

fuente desde el principio.

En el mejor de los casos, lo ms conveniente es utilizar libreras y mdulos completos

previamente desarrollados evitando de esta forma el mayor esfuerzo posible. Sin

embargo, poder llegar a este tipo de buenas prcticas implica que para cada proyecto

desarrollado deben crearse mdulos genricos con la menor dependencia posible del

proyecto. Lo cual, es una tarea que se da por la experiencia obtenida con el progresivo

desarrollo de proyectos. (Humphrey, W. 1995. Pg. 84).

2.2.5. Conteo de lneas de cdigo

En el captulo 2.2.3. se analiz de forma introductoria lo que significa el conteo de lneas

de cdigo de un programa y cmo esta mtrica puede ser utilizada en PSP para obtener

el tamao de un proyecto de software basado en el nmero de lneas de cdigo del

mismo.

En este apartado analizaremos de forma detallada cmo se realiza un conteo de lneas de

cdigo de acuerdo al PSP. Aun cuando la mtrica basada en lneas de cdigo, en

adelante denominadas LOCs, pareciera ser sencilla, en la prctica resulta difcil llevar un

rastreo de las mismas si no es propiamente definido y utilizado el concepto de lnea de

cdigo. De acuerdo con la metodologa de PSP, si al iniciar la realizacin de un nuevo

proyecto de software iniciamos con 5000 lneas de cdigo que tomamos de otro programa

y nosotros escribimos 500 lneas de cdigo adicionales, el resultado debera ser 5500

lneas de cdigo. Por lo tanto, si nosotros slo escribimos 500 lneas de cdigo el

resultado debera ser un programa de 500 lneas de cdigo. Aun cuando este ejemplo

parece obvio, en la realidad, al crecer y haber cambios en los proyectos de software,

obtenemos un resultado diferente. A esto se debe la necesidad de entender y utilizar

apropiadamente el tamao de un programa basado en sus lneas de cdigo.

Cuando desarrollamos un nuevo programa, generalmente intervienen 4 tipos distintos de

lneas de cdigo (Humphrey, W. 2005. Pg.40-47):



- Lneas Base. Corresponden a las lneas que se piensan reutilizar en la

construccin de un nuevo programa. En otras palabras, son lneas de cdigo de

otro programa que se creen que pueden ser tiles en alguna parte del nuevo

programa.

- Lneas Agregadas. Corresponden a las lneas nuevas que el desarrollador

escribe en su programa.

- Lneas Modificadas. Corresponden a aquellas lneas base que requieren ser

modificadas para el buen funcionamiento del nuevo programa.

- Lneas Borradas. Corresponden a aquellas lneas base que no son de utilidad

alguna en el nuevo programa y requieren ser eliminadas.

- Lneas Reutilizadas. Corresponden a las lneas base que no fueron modificadas

ni eliminadas, es decir, a aquellas lneas que no requieren modificacin alguna

para el buen funcionamiento del nuevo programa.

- Lneas Agregadas y Modificadas. En muchos proyectos de software, el esfuerzo

requerido para modificar una lnea de cdigo ya existente y el de crear una nueva

es muy similar. Por lo tanto, suelen sumarse y obtener una medida de esfuerzo

considerando ambos tipos de lnea pero sin dejar de identificar cada una de ellas.

- Lneas Nuevas Reutilizables. Los nuevos paradigmas de programacin, tales

como la programacin orientada a objetos, permiten construir las aplicaciones

basadas en mdulos y libreras con funcionalidades muy especficas. De tal forma

que se piensa en que un determinado mdulo o librera pueda servir sin ser

modificado, en el mejor de los casos, en nuevos proyectos. A las lneas de cdigo

pertenecientes a estas libreras o mdulos se les conoce como lneas nuevas

reutilizables. Cabe mencionar que no necesariamente tienen que ser lneas

pertenecientes a una librera o mdulo, pudiendo ser tambin lneas

correspondientes a una clase, un mtodo o procedimiento dependiendo del

lenguaje y plataforma de programacin en el cual se est desarrollando el

proyecto.

- Lneas Totales. Se refiere al nmero total de lneas que tiene el programa al final

de su desarrollo.

La razn por la cual es necesario llevar un rastreo de las lneas base, agregadas,

modificadas y borradas se debe a que por ejemplo, si comenzamos el desarrollo del

programa en la versin 0, contamos 400 lneas de cdigo base y despus agregamos

200, esperaramos tener una primer versin con 600 lneas de cdigo. Sin embargo, al

contar las lneas de cdigo de la versin 1 el tamao total es de 550 lneas de cdigo.

Qu sucedi con las 50 lneas de cdigo faltantes?

2.2.6. Calcular la productividad

La productividad es un factor que relaciona el tiempo requerido para una tarea

determinada y el producto derivado de realizar dicha tarea. Este factor es utilizado en



muchas de las reas productivas dentro de las actividades humanas y es un factor clave

para determinar el tiempo total que requerir concluir una tarea especfica por una

persona en particular, de la cual se conoce su productividad. En este apartado se

comprender el concepto de la productividad relacionada con el desarrollo de productos

de software y como se calcula dicha productividad.

Como se ha visto anteriormente, el desarrollo de un producto de software involucra una

planeacin previa al desarrollo del proyecto. Por otra parte, planear el desarrollo de dicho

proyecto involucra conocer el tamao del proyecto. A su vez, conocer el tamao del

proyecto es un dato vital para poder estimar y planear el tiempo en que ha de ser

desarrollado. Sin embargo, para calcular el tiempo requerido para el desarrollo del

proyecto, es necesario un dato adicional: con qu rapidez se desarrollan las tareas por

parte de cada integrante del equipo de desarrollo contemplado para dicho proyecto?

Calcular la productividad en el desarrollo de software no es una tarea sencilla y a lo largo

del tiempo se han propuesto varias mtricas para poder lograr este objetivo. Por ejemplo,

se ha propuesto medir la productividad de un desarrollador basado en las horas promedio

que le toma construir un archivo de texto. Otras variantes involucran el tiempo que toma

producir un archivo de cdigo en algn lenguaje de script, una pantalla de usuario, etc.

Para el caso de PSP, el autor propone una mtrica de productividad basada en las lneas

de cdigo nuevas que un desarrollador realiza en una hora. Si bien, esta mtrica pudiera

no ser la mejor, ha demostrado ser la ms asertiva para medir la productividad de un

ingeniero de software. Por lo tanto, si la medicin del tamao de un producto de software

est basada en sus lneas de cdigo y, la productividad de un desarrollador est basada

en las lneas de cdigo que produce en una hora, la estimacin del tiempo requerido para

desarrollar el producto se puede calcular fcilmente dividiendo el tamao estimado del

producto entre la productividad del desarrollador:

Para concluir con este apartado, slo resta mencionar que la productividad de un

desarrollador no es constante. A lo largo del tiempo y despus de la experiencia en el

desarrollo de varios proyectos, los desarrolladores van aumentando su productividad a la

vez que haciendo ms eficientemente sus tareas. Por eso es importante ir recolectando

datos de la productividad en cada proyecto. Esto permitir a su vez, obtener informacin

sobre la productividad de los equipos de desarrollo as como informacin que servir de

base para poder estimar el tiempo de desarrollo de futuros proyectos. (Humphrey, W.

1995. Pg. 88).

2.2.7. PSP 0.1

En PSP 0.1 se tienen los siguientes objetivos:

Medir el tamao de los programas que se realizan.



Realizar el conteo de tamao para los programas realizados.

Desarrollar mtricas de tamao asertivas y precisas.

En PSP 0.1 se utilizan todos los documentos vistos en PSP0 y se agregan los siguientes

tres:

PIP, (por sus siglas en ingls, Process Improvement Proposal), significa Propuesta

de Mejora del Proceso. Este formato es un documento libre donde el ingeniero de

software, por cada programa que realice a partir del nivel 0.1 de PSP, deber

emitir una propuesta de mejora al PSP mediante este documento. Es importante

mencionar que en una PIP no basta con describir alguna problemtica que se

tenga con el PSP, sino que adems se tiene que proponer alguna alternativa que

ayude a mejorar o erradicar dicha problemtica.

Formato para el conteo del tamao del programa.

Estndar de codificacin.

Como resultado de esto, el formato del resumen del plan del proyecto tambin deber

mostrar los datos referentes al tamao del programa tomando en cuenta que a partir

de este nivel, el desarrollo del programa debe ser planeado por cada fase del ciclo de

desarrollo. (Echeverra, C.M., Echeverra, C.D. Mera, J.L. 2006. Pg 23-26).

Actividad 2. Medicin del tamao de un software

Esta actividad tiene la finalidad de que comprendas la medicin del tamao de un

producto de software, a travs de conteo de las lneas de cdigo que lo componen,

mediante la aplicacin de un estndar de codificacin y compararlo con tus compaeros

en la Base de Datos del grupo.

Propsito

Analizar en un programa la medicin del tamao del software a travs del estndar de

conteo de Lneas de cdigo, re-uso y productividad.

Instrucciones

1. Analiza el siguiente cdigo correspondiente a un producto de software. 1

2

3

4

5

6

7

8

9

10

11

import java.util.List;

import java.util.ArrayList;

import java.util.Scanner;

public class ProgramaDesviacionEstandar

{

private static List listaDatos;

/**

* Este es el mtodo principal del programa.

*/



12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

public static void main(String[] args)

{

double prom = 0;

double stdev = 0;

listaDatos = new ArrayList();

leerDatos();

prom = calcularPromedio();

stdev = calcularDesviacionEstandar();

System.out.println("El Promedio de los valores es: " + prom);

System.out.println("La Desviacin Estndar es: " + stdev);

}

/**

* Este mtodo sirve para pedir un indeterminado

* nmero de datos al usuario.

* Cada dato es almacenado en una lista dinmica.

*/

private static void leerDatos()

{

Scanner teclado = new Scanner(System.in);

String texto = "S";

double valor = 0;

while(texto.equals("S") || texto.equals("s"))

{

System.out.print("Introduce el valor no. " +

(listaDatos.size() + 1) + ": ");

texto = teclado.next();

// En este try-catch evaluamos que el valor que introdujo

// el usuario pueda ser convertido a un valor double.

try

{

valor = Double.valueOf(texto);

listaDatos.add(valor);

}

catch (Exception ex) // Si no se pudo convertir el valor,

// se lanza un mensaje al usuario

// indicndole el error.

{

System.out.println("No se introdujo un nmero.\n");

}

System.out.print("Desea capturar otro valor? [S/N]: ");

texto = teclado.next();

}

teclado.close();

}

/**

* Este mtodo calcula el promedio de los datos

* almacenados en una lista dinmica.

*

* Al final el mtodo devuelve el promedio calculado.

*/

private static double calcularPromedio()



71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

{

double promedio = 0;

//Si la lista est vaca, el mtodo devolver 0.

if (listaDatos.size() == 0)

return promedio;

for (Double d : listaDatos)

promedio += d;

promedio = promedio / (double) listaDatos.size();

return promedio;

}

/**

* Este mtodo realiza el clculo de la desviacin estndar

* y la devuelve.

*/

private static double calcularDesviacionEstandar()

{

double stdev = 0; // En esta variable se guardan clculos

// temporales

// y al final la desviacin estndar.

double prom = calcularPromedio();

if (prom == 0)

return stdev;

for (Double d : listaDatos)

stdev += Math.pow(d - prom, 2);

stdev = stdev / (double) listaDatos.size();

return stdev;

}

}

2. Llena la siguiente tabla, indicando en cada nmero de lnea, si esa lnea contar como

lnea de cdigo o no. Cada nmero de lnea corresponde a cada lnea del programa

anterior. Para decidir si cada lnea deber ser contada o no, debers basarte en el

estndar de conteo de lneas de cdigo que se encuentra despus de esta tabla.

No. de

Lnea

Cuenta cmo

lnea?

S = SI / N = NO

1

2

3

4

5

6

7

8



9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48



49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88



89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

Estndar de codificacin.

Versin: 1.0

El siguiente documento es una gua para realizar el conteo de lneas de cdigo.

a) Toda declaracin o directiva que hace referencia a la importacin de otras clases

cuenta como una lnea de cdigo. Por ejemplo, las instrucciones que comienzan con

la palabra reservada import.

b) Toda declaracin de un mtodo cuenta como una lnea de cdigo. Por ejemplo, la

sentencia public static void main(String[] args) contar como una lnea de cdigo.

c) Toda declaracin de variable (atributo o variable) dentro de un mtodo contar como

una lnea de cdigo.

d) Cuando una instruccin sea demasiado larga y ocupe varias lneas, slo se contar

como una nica lnea de cdigo.

e) Toda lnea en blanco no ser contada como lnea de cdigo.

f) Toda lnea que contenga solo un corchete de apertura o cierre sin ninguna otra

instruccin, no ser contada como lnea de cdigo.

g) Toda lnea que contenga solo comentarios no ser contada como una lnea de cdigo.

3. Guarda la actividad con el nombre DMDS_U2_A2_XXYZ. Sustituye las XX por las dos

primeras letras del primer nombre, la Y por la inicial del apellido paterno y la Z por la

inicial del apellido materno.

4. Ingresa al apartado de Base de datos del aula virtual y sube tu archivo.



5. Revisa los trabajos de tus dems compaeros en la Base de datos para que puedas

comparar tus resultados con los del resto del grupo.

6. Comenta por lo menos 3 lneas que identifiques incorrectas argumentando el porqu

del error.

7. Atiende a los comentarios que emita tu facilitador(a).

Establecer estndares para definir la manera de contar las lneas de cdigo es una buena

prctica que necesitars para evitar errores en la forma en que medimos nuestra

productividad y la de otros miembros del equipo. Esto nos permitir realizar mediciones

ms precisas para la toma de decisiones oportunas.

Nota al facilitador(a) y alumnos(as):

Se espera que los alumnos(as) socialicen sus diferencias en torno a las

respuestas, es decir, argumentarn el porqu de su comentarios.

Los alumnos(as) debern comentar por lo menos 3 errores en las bases de datos

de sus compaeros.

Para ser considerada como actividad aprobada, el alumno deber cumplir con por

lo menos 65 lneas correctas.

2.3. Estimacin del tamao del software

Una vez que se tiene una mtrica para medir el tamao de un producto de software, se

tiene tambin una base para poder estimar que tan grande ser un nuevo proyecto

basado en los datos histricos previos de otros proyectos.

En principio, las estimaciones son realizadas comparando el trabajo planeado con el

trabajo realizado en proyectos anteriores. Si se divide el proyecto actual en partes ms

pequeas y se comparan con partes ms pequeas de proyectos anteriores, se puede

obtener una mejor estimacin del tamao total del proyecto. Esta estrategia funciona bien

para la mayora de los proyectos que se realizan en distintas reas.

El proceso de estimacin del tamao de un producto de software a travs de la divisin de

tareas tiene la ventaja de que es fcilmente escalable. Si se es capaz de estimar

proyectos pequeos, se puede ser capaz de estimar proyectos grandes a travs de esta

tcnica.

2.3.1. Contexto

Generalmente, cuando se planea el desarrollo de un nuevo proyecto, tan solo se conocen

los requerimientos del cliente. La dificultad de estimar el tamao del proyecto es

precisamente el poder predecir el tamao del producto final conociendo tan solo los

requerimientos iniciales del cliente. Y, dado que nadie conoce en realidad que tan grande

o cuanto se tardar realmente en realizarse, la estimacin ser siempre un proceso con

un cierto grado de incertidumbre. Por lo tanto, siempre ser una ventaja el contar con una



mejor definicin as como el mayor nmero de requerimientos por parte del cliente.

(Humphrey, W. 1995. Pg. 97).

2.3.2. Mtodos de estimacin

Existen varios mtodos que ayudan a estimar el tamao de un nuevo producto de

software, as como establecer su costo. Algunos de estos mtodos son herramientas

comerciales, otras son de implementacin personalizada, automatizadas o manuales.

Dentro de las comerciales existe una amplia variedad que ayudan a las organizaciones de

desarrollo de software a generar estimaciones ms precisas y controlables. Algunos

ejemplos son: COCOMO II, CoStar, CostModeler, CostXpert, KnowledgePlan, PRICE S,

SEER, SLIM y SoftCost.

Las herramientas comerciales estn principalmente enfocadas a la estimacin del costo

del software y muchas de ellas comparten algunas caractersticas como:

- Especificacin de requerimientos.

- Niveles de fase, actividad, tarea, etc.

- Definicin del perodo laboral y vacacional.

- Manejo de salarios.

- Uso de diferentes tipos de proyectos.

- Mtricas de puntos de funcin, lneas de cdigo, etc.

Sin embargo, ningn mtodo de estimacin es lo suficientemente preciso para indicar con

exactitud los tiempos que cada tarea nos llevar. Una buena prctica de la estimacin es

que la herramienta que se utilice, ya sea la comercial o propia, se vaya mejorando con

cada proyecto y cada vez nos pueda ir dando valores ms cercanos a la realidad. En el

siguiente tema veremos los dos mtodos que se recomiendan en PSP los cules son el

Proxy y el PROBE. Y en la unidad 3 vers mtodos basados en juicio experto y

estadsticos. (Jones, C. 2010. Pg. 1).

2.3.3. Proxy

En este tpico se analizar el mtodo Proxy. El mtodo Proxy es un mtodo propuesto

por Watts Humphrey, creador de PSP y, se ver ms adelante, sirve para medir el tamao

que tendr un producto de software basado en la divisin ms elemental de los

componentes que integrarn el producto que se piensa desarrollar. A estos elementos se

les llama partes proxy cuya caracterstica principal es que pueden ser comparados con

otros elementos proxy correspondientes a proyectos desarrollados previamente de los

cuales ya se tienen datos histricos.



El siguiente ejemplo muestra en primera instancia las bases de un mtodo de estimacin

basado en un proxy. Si se piensa por ejemplo, en la construccin de una casa tomando

en cuenta la cantidad de metros cuadrados que se van a construir, se podra tener una

base para estimar el costo de construccin. Sin embargo, algunas personas, pueden

pensar en trminos de metros cuadrados basados en el nmero de cuartos y baos que

tendr la casa para realizar la estimacin del costo de construccin. La estimacin del

software es un problema similar. Si se pudiera saber el nmero de tablas y relaciones

entre ellas, que tendra la base de datos o, el nmero de lneas de cdigo que tendr el

programa, se formulara una base para poder estimar su tamao.

Es muy difcil realizar la estimacin del tamao de un programa basado nicamente en los

requerimientos del cliente. Se requiere de algn proxy que permita relacionar el tamao

del producto con las funciones que se desean incorporar en el programa. Un proxy no es

ms que un sustituto del cual conocemos su tamao. Ejemplos de proxies son tablas,

clases, campos o pantallas.

Existen algunos criterios para seleccionar un proxy adecuadamente:

- La medida del proxy debe estar altamente relacionada con el esfuerzo requerido

para desarrollar el producto.

- El contenido proxy de un producto debe ser automticamente contable.

- El proxy debe ser fcil de visualizar al inicio del proyecto.

- El proxy debe ser personalizable a las necesidades de cada proyecto y

desarrollador.

- El proxy debe ser sensible a las variaciones de implementacin que afectan los

costos de desarrollo o esfuerzo.

El siguiente diagrama muestra el proceso para seleccionar un proxy adecuado en el

desarrollo de un proyecto.



Figura. Diagrama del proceso para estimar proyectos de software utilizando el mtodo

Proxy. (Humphrey, W. 1995. Pg. 110).

Una vez que se comprendido el mtodo de estimacin por proxy se podr analizar un

mtodo ms complejo denominado PROBE, el cual ser descrito en la siguiente seccin.

El mtodo PROBE est basado en el mtodo Proxy, pero adems, permite estimar el

tiempo requerido para el desarrollo de cada parte del proyecto. (Humphrey, W. 1995.

Pg. 109).

2.3.4. Probe

En esta seccin se analizar el mtodo PROBE. Este mtodo permite obtener una

estimacin del tamao de cada parte del proyecto (basado en la metodologa Proxy) y

posteriormente, con estos datos, permite estimar el tiempo requerido para el desarrollo de

cada una de las partes del proyecto.



El mtodo PROBE utiliza datos histricos para realizar las estimaciones. Por ejemplo, si

se estima el trabajo para desarrollar un sistema de consultas en una base de datos, se

podra producir inicialmente un diseo conceptual y despus dividirlo en partes.

Posteriormente, se podran estimar el nmero de elementos en cada parte. Por ejemplo,

si se estiman un total de 95 elementos y se sabe que cada elemento se lleva en

producirse en promedio, 1.5 horas, el tiempo estimado total de desarrollo seran 142.5

horas.

Para hacer ms precisas las estimaciones se requiere adems de una base para calcular

el tiempo promedio requerido para desarrollar un determinado componente del programa.

Una vez que se han comprendido los conceptos de estimacin de tamao y tiempo de

desarrollo, es necesario comprender como son utilizados dentro del proceso PSP, en

especfico, en el nivel 1 o (tambin conocido como PSP1), el cual, ser descrito en la

siguiente seccin. (Humphrey, W. 2005. Pg.105).

2.3.5. PSP 1

Durante la Unidad 1, se analiz el PSP 0 el cual es el nivel inicial del proceso personal de

software. Como se recordar, el objetivo en PSP 0 era estimar el tiempo total que tomara

desarrollar un determinado programa. Una vez que se tiene completado el nivel PSP 0 se

pasa al nivel PSP 0.1. En este segundo nivel el objetivo es estimar de forma emprica,

basado en la experiencia del desarrollador, el tiempo de desarrollo por cada fase y se

estima adems, las lneas de cdigo que podra tener el nuevo programa a desarrollar.

Finalmente, en PSP 1, el objetivo es el mismo que en PSP 0.1, slo que, la estimacin de

las lneas de cdigo se realiza utilizando el mtodo Proxy y adicionalmente, utilizando el

mtodo PROBE y los datos histricos de PSP 0 y PSP 0.1, se estima de forma automtica

el tiempo de desarrollo por cada fase.

El objetivo en PSP1 es establecer un procedimiento ordenado y repetible para realizar

estimaciones de tamao y tiempo de desarrollo por cada fase para un nuevo producto de

software. Este nivel toma en cuenta dos nuevos aspectos:

Estimacin de tamao y tiempo basado en el mtodo PROBE.

Reporte de pruebas.

La hoja del resumen del plan del proyecto se expande para mostrar adems de los datos

de PSP0.1, datos de productividad (medida en lneas de cdigo por hora), tamao

planeado para todos los tipos de lneas de cdigo. (Zapata, J., Garca, J., Cerrada, J.

2001. Pg. 60-61).



Actividad 3. Estimacin del tamao de un software

Esta actividad tiene la finalidad de que reflexiones sobre la estimacin del tamao de un

producto de software y determinar la factibilidad de utilizar mtodos de estimacin como

Proxy o PROBE de acuerdo a los escenarios propuestos.

Por lo tanto, Ingresa al aula virtual para realizar la actividad.

Propsito

Reforzar la comprensin acerca de la estimacin del tamao de un producto de software.

Instrucciones

1. Analiza Los siguientes dos escenarios.

Escenario 1:

Una empresa de software va a realizar su primer proyecto para un cliente

determinado. Sin embargo, la empresa no cuenta con datos histricos de proyectos

anteriores.

Escenario 2:

Una empresa de software va a realizar un nuevo proyecto de software. La

empresa ha desarrollado varios proyectos con anterioridad y cuenta con los datos

histricos de tamao y tiempos de desarrollo de dichos proyectos. Sin embargo, para este

nuevo proyecto, se ha visto en la necesidad de contratar un nuevo equipo de

desarrolladores para las tareas de codificacin y pruebas unitarias.

2. Contesta las siguientes preguntas sobre los escenarios anteriormente descritos.

a) En el escenario 1, la empresa debera utilizar el mtodo PROBE para estimar y

planear el trabajo? por qu? qu recomendacin le proporcionaras?

b) La empresa podra realizar la estimacin del proyecto utilizando el mtodo PROXY?

por qu? En el caso de la estimacin de tiempos a travs del mtodo PROBE, qu

recomendacin le daras y por qu?, por ejemplo, tomar la productividad de desarrollo

ms baja y con esa base estimar los tiempos.

3. Guarda la actividad con el nombre DMDS_U2_A3_XXYZ. Sustituye las XX por las dos

primeras letras del primer nombre, la Y por la inicial del apellido paterno y la Z por la

inicial del apellido materno.

4. Ingresa al apartado de actividades del aula virtual y sube tu archivo.

5. Espera retroalimentacin por parte de tu facilitador(a).



6. Atiende los comentarios y, en caso de ser necesario, modifica tu actividad y envala

de nuevo.

Considera que una buena estimacin es la que proporciona una visin clara de la realidad

de un proyecto, permite al lder controlar adecuadamente el proyecto y lograr los

objetivos.

Autoevaluacin

Para reforzar los conocimientos relacionados con los temas que se abordaron en esta

segunda unidad del curso, es necesario que resuelvas el siguiente crucigrama que

contiene los conceptos ms sobresalientes de la unidad.

6 2 4 10

1

7

9 5

8

3

1. Funcionalidades con las que deber contar el producto final.

2. Factor que relaciona el tiempo requerido para una tarea y el producto derivado de

realizar dicha tarea.

3. Se llevan a cabo todas las actividades involucradas en el proyecto.

4. Necesaria para conocer el tamao del proyecto.

5. Tiempos promedios con la planeacin balanceada.

6. Mtodo para medir el tamao que tendr un producto de software basado en la divisin

ms elemental de los componentes que lo integrarn.

7. Aplicar cdigo, libreras o mdulos previamente desarrollados.

8. Gua que nos muestra los pasos, procedimientos o medidas a seguir para lograr un

objetivo o meta determinada.

9. Formato para emitir una propuesta de mejora al PSP.

10. Lneas de cdigo.



Evidencia de aprendizaje. Programa PSP 1

Cuando generamos programas con PSP1 debemos estimar basados en los datos

histricos, en esta actividad aprenders a utilizar el mtodo PROBE basado en los proxies

de un proyecto.

Propsito: Utilizar el mtodo de estimacin PROBE en un programa a travs de la

definicin del contexto, identificacin de proxies e identificacin de otros mtodos de

estimacin.

Instrucciones: desarrolla las 4 partes de la actividad.

Parte 1:

Analiza la siguiente tabla con datos histricos de un proyecto desarrollado. La tabla

muestra una serie de componentes numerados del 1 al 10. Cada componente cuenta con

una descripcin de su funcin dentro del sistema desarrollado. La tercera columna

muestra las lneas de cdigo totales que tuvo cada componente una vez concluido el

proyecto.

No. Componente Lneas de

Cdigo

1 Comunicacin entre la interfaz de usuario y los componentes de la

capa de negocio. Las clases de este componente reciben datos

provenientes de la interfaz de usuario y realizan las acciones

correspondientes.

1200

2 Interfaz de usuario con los controles necesarios para poder realizar

altas, bajas y cambios de clientes.

570

3 Mdulo para el acceso a la base de datos y control de sentencias

SQL.

400

4 Mdulo de reportes de la aplicacin. Este mdulo genera los

reportes dentro de la aplicacin.

700

5 Mdulo de reportes de la aplicacin en web. Este mdulo genera

reportes desde una interfaz que puede ser accedida a travs de

internet o una red mediante un navegador.

850

6 Mdulo para clculos estadsticos. Este mdulo permite realizar

varios clculos estadsticos desde fuentes de datos como archivos,

bases de datos y colecciones de valores en memoria.

1000

7 Mdulo de interfaz de usuario para control de productos: Altas,

bajas y cambios.

650

8 Mdulo de interfaz de usuario para ventas. En este mdulo se

manejan las interfaces de usuario para realizar ventas de productos,

cambios y devoluciones.

870

9 Mdulo de operaciones y reglas de negocio relacionadas con las 1500



Parte 2:

Con base en la tabla anterior, determina los proxies ms adecuados para los mdulos del

siguiente proyecto que se desea desarrollar.

Se desea desarrollar un sistema en un hospital que permita llevar el control de pacientes,

mdicos e ingresos de pacientes al hospital. La siguiente tabla determina los mdulos que

los analistas de sistemas proponen desarrollar para satisfacer las necesidades del cliente

despus de varias sesiones de plticas y entendimiento de la problemtica a solucionar.

Coloca en la tercera columna de la siguiente tabla, el nmero de proxy ms adecuado

tomando como base los componentes de la tabla de la parte 1.

No. Componente

No. de

Componente Proxy

ms parecido

1

Se requiere de un mdulo de interfaz de usuario una

interfaz para poder realizar altas, bajas y cambios de los

datos de los mdicos.

2

Se requiere un mdulo de interfaz de usuario con los

controles necesarios para poder realizar altas, bajas y

cambios de los ingresos de los pacientes al hospital.

3 Se requiere un mdulo para el acceso a la base de datos y

control de sentencias SQL.

4 Se requiere un mdulo de reportes dentro de la aplicacin.

5

Se requiere de un mdulo para manejar las reglas de

negocio de los ingresos. Considerar las reglas de negocio

de tamao grande.

Parte 3:

Contesta la siguiente pregunta:

Cul sera el tamao estimado en lneas de cdigo que tendra el proyecto, sumando las

lneas de cdigo de todos proxies de la tabla 2?

Parte 4:

Una vez que has estimado los proxies ms adecuados para cada componente, determina

el tiempo, en horas, que tardara un slo desarrollador en realizar el proyecto. Utiliza

como medida de productividad 22 lneas de cdigo por hora, dividiendo las lneas de

cdigo totales (Parte 3) entre la productividad (22).

compras.

10 Mdulo de reglas de negocio y operaciones para control de

productos e inventarios.

2300



1. Ahora, en un documento de texto, Guarda la actividad con el nombre

DMDS_U2_EA_XXYZ. Sustituye las XX por las dos primeras letras del primer

nombre, la Y por la inicial del apellido paterno y la Z por la inicial del apellido materno.

2. Enva a tu archivo a tu facilitador(a) por medio de la herramienta Evidencia de

aprendizaje de la unidad.

3. Espera retroalimentacin por parte de tu facilitador(a) y en caso de ser necesario,

modifica y renva tu evidencia.

La estimacin de lneas de cdigo es un elemento importante para poder hacer planes de

nuestros programas o proyectos de software. Es por ello que llevar un adecuado estndar

de conteo de Lneas de cdigo es importante para tener un registro histrico confiable y

cada vez ms preciso.

Autorreflexiones

Adems de enviar tu trabajo de la Evidencia de aprendizaje, es importante que ingreses

al foro Preguntas de Autorreflexin y consultes las preguntas que tu Facilitador(a)

presente, a partir de ellas, debes elaborar tu Autorreflexin en un archivo de texto

llamado DMDS_U2_ATR_XXYZ. Posteriormente enva tu archivo mediante la herramienta

Autorreflexiones.

Para saber ms

Si deseas saber acerca de PSP, TSP o CMMI puedes consultar la siguiente direccin

electrnica:

http://www.ecured.cu/index.php/Proceso_de_Software_Personal

Es una enciclopedia virtual, colaborativa y en espaol que fue creada para difundir el

conocimiento de tecnologas de la informacin, sus fuentes son confiables. Puedes

participar en sus foros y acceder a este sitio por medio de las redes sociales ms

importantes de la actualidad.

Fuentes de consulta

Bibliografa bsica

Humphrey, W. (1995) A discipline for software engineering (The complete PSP Book)

United States of America: Addison Wesley.

Humphrey, W. (2005) PSP a Self-improvement process for software engineers. United

States of America: Addison Wesley.



Zapata, J., Garca, J., Cerrada, J. (2001) Introduccin al proceso software personalSM.

Madrid, Espaa: Addison Wesley.

Bibliografa complementaria

Echeverra, C.M., Echeverra, C.D. Mera, J.L. (2006). Implementacin de un Sistema

integrado de Control de Costos de Produccin, rdenes de Trabajo, Presupuesto de

Obras, Bodega y Control de Inventario utilizando PSP y TSP. Guayaquil, Ecuador.

Escuela superior politcnica del litoral. Recuperado de

http://www.dspace.espol.edu.ec/handle/123456789/5006

Jones, C. (2010). Mtodos de Estimacin de Costos de Software para Grandes

Proyectos. Recuperado de

http://www.liderdeproyecto.com/articulos/estimacion_costos_de_software.html



Apndice de respuestas de la autoevaluacin

P P M L

R E Q U E R I M I E N T O S

O O D C

X D I

Y R E U S O C

C I

T O

P I P I N

R V

O I

B D P

D E S A R R O L L O

D A

N

Unidad 2. Planeacion

Documents

Transcript of Unidad 2. Planeacion