Unidad 2. Planeacion PDF

Mtricas de desarrollo de software
Unidad 2. Planeacin
Ingeniera en Desarrollo de software

Cuatrimestre 07
Programa de la asignatura:
Clave: 150930728
Ejecutas el editor1
Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software
1

Unidad 2. Planeacin
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
Ejecutas el editor2
2

Unidad 2. Planeacin
Evidencia de aprendizaje. Programa PSP 1 .......................................................................... 34

Autorreflexiones .......................................................................................................................... 36
Para saber ms........................................................................................................................... 36
Fuentes de consulta ................................................................................................................... 36
Ejecutas el editor3
3

Unidad 2. Planeacin
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.
Ejecutas el editor4
4

Unidad 2. Planeacin
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.
Ejecutas el editor5
5

Unidad 2. Planeacin
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
Ejecutas el editor6
6

Unidad 2. Planeacin
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?
Ejecutas el editor7
7

Unidad 2. Planeacin
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.
Ejecutas el editor8
8

Unidad 2. Planeacin
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:
Ejecutas el editor9
9

Unidad 2. Planeacin
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
Ejecutas el editor10
Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software 10

Unidad 2. Planeacin
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.
2.
3.
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.
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.
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.

Unidad 2. Planeacin
4.
5.
6.
7.
8.
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.
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.
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.
Generacin de nuevos datos. Durante el desarrollo del proyecto, cada
actividad debe ser medida para generar datos histricos del proceso de
desarrollo.
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.

Unidad 2. Planeacin
1.
2.
3.
4.
5.
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.
El responsable del proyecto establece las fechas en que cada actividad
correspondiente al desarrollo del proyecto deber ser realizada.
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.
El responsable del proyecto comienza a planear cules personas podran
trabajar en el desarrollo del proyecto.
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.

Unidad 2. Planeacin
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.

Unidad 2. Planeacin
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

Unidad 2. Planeacin
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.

Unidad 2. Planeacin
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
Code Counter Pro

Microsoft LOC
Counter
Gratuito
No
Si
Plataformas y
lenguajes soportados
Varios
Lenguajes de la
plataforma .Net 4.0
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.
Code Line Counter
Pro
No
Pgina de la
compaa
http://www.geronesoft.
com/
http://archive.msdn.mi
crosoft.com/LOCCount
er
http://www.codelineco
unter.com/

Unidad 2. Planeacin
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):

Unidad 2. Planeacin
- 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

Unidad 2. Planeacin
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.

Unidad 2. Planeacin
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<Double> listaDatos;
/**
*
*/
Este es el mtodo principal del programa.

Unidad 2. Planeacin
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<Double>();
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()

Unidad 2. Planeacin
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 Cuenta cmo
Lnea
lnea?
S = SI / N = NO
1
2
3
4
5
6
7
8

Unidad 2. Planeacin
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

Unidad 2. Planeacin
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

Unidad 2. Planeacin
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.

Unidad 2. Planeacin
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

Unidad 2. Planeacin
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.

Unidad 2. Planeacin
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.

Unidad 2. Planeacin
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.

Unidad 2. Planeacin
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).

Unidad 2. Planeacin
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).

Unidad 2. Planeacin
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
10
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.

Unidad 2. Planeacin
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.
Lneas de
No.
Componente
Cdigo
1
Comunicacin entre la interfaz de usuario y los componentes de la
1200
capa de negocio. Las clases de este componente reciben datos
provenientes de la interfaz de usuario y realizan las acciones
correspondientes.
2
Interfaz de usuario con los controles necesarios para poder realizar
570
altas, bajas y cambios de clientes.
3
Mdulo para el acceso a la base de datos y control de sentencias
400
SQL.
4
Mdulo de reportes de la aplicacin. Este mdulo genera los
700
reportes dentro de la aplicacin.
5
Mdulo de reportes de la aplicacin en web. Este mdulo genera
850
reportes desde una interfaz que puede ser accedida a travs de
internet o una red mediante un navegador.
6
Mdulo para clculos estadsticos. Este mdulo permite realizar
1000
varios clculos estadsticos desde fuentes de datos como archivos,
bases de datos y colecciones de valores en memoria.
7
Mdulo de interfaz de usuario para control de productos: Altas,
650
bajas y cambios.
8
Mdulo de interfaz de usuario para ventas. En este mdulo se
870
manejan las interfaces de usuario para realizar ventas de productos,
cambios y devoluciones.
9
Mdulo de operaciones y reglas de negocio relacionadas con las
1500

Unidad 2. Planeacin
10
compras.
Mdulo de reglas de negocio y operaciones para control de
productos e inventarios.
2300
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. de
No.
Componente
Componente Proxy
ms parecido
Se requiere de un mdulo de interfaz de usuario una
1 interfaz para poder realizar altas, bajas y cambios de los
datos de los mdicos.
Se requiere un mdulo de interfaz de usuario con los
2 controles necesarios para poder realizar altas, bajas y
cambios de los ingresos de los pacientes al hospital.
Se requiere un mdulo para el acceso a la base de datos y
3
control de sentencias SQL.
4 Se requiere un mdulo de reportes dentro de la aplicacin.
Se requiere de un mdulo para manejar las reglas de
5 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).

Unidad 2. Planeacin
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.

Unidad 2. Planeacin
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

Unidad 2. Planeacin
Apndice de respuestas de la autoevaluacin
P
R
O
X
Y
P
R
O
B
E
P
R
O
D
U
C
T
I
V
I
D
A
D
M
E
D
I
C
I
O
N
P
L
A
L
O
C

Unidad 2. Planeacion PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad 2. Planeacion PDF

Cargado por

Copyright:

Formatos disponibles

Mtricas de desarrollo de software

Ingeniera en Desarrollo de software

Mtricas de desarrollo de software

Mtricas de desarrollo de software

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

Mtricas de desarrollo de software

Unidad 2. Planeacin: introduccin, medicin y estimacin

Mtricas de desarrollo de software

Conocers algunas tcnicas para estimar el tiempo que tomar desarrollar un

2.1. Introduccin a la planeacin

Mtricas de desarrollo de software

2.1.2. Por qu hacer planes?

Mtricas de desarrollo de software

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

Cunto tiempo tomar desarrollar el sistema?

2.1.3. Contenido del plan de un software

Mtricas de desarrollo de software

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

La planeacin debe estar basada en tareas bien definidas.

Mtricas de desarrollo de software

2.1.4. Planeando un proyecto de software

Mtricas de desarrollo de software

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

2.1.5. Producir un plan de calidad

Mtricas de desarrollo de software

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

2.1.6. Etapas de la planeacin

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

Mtricas de desarrollo de software

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

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

Actividad 1. Plan del proyecto

Mtricas de desarrollo de software

El responsable del proyecto estima el tamao del proyecto tomando cada

2.2. Medicin del tamao del software

Mtricas de desarrollo de software

2.2.1. Medicin del tamao

Mtricas de desarrollo de software

Por lo tanto, medimos para:

Entender y saber administrar los cambios

Mtricas de desarrollo de software

Nmero de archivos que tendr el programa

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

2.2.2. Establecer un conteo estndar

Mtricas de desarrollo de software

2.2.3. Contadores de LOC y tipos

Code Counter Pro

Varios. Se compra por

Mtricas de desarrollo de software

2.2.4. Consideraciones del re-uso

2.2.5. Conteo de lneas de cdigo

Mtricas de desarrollo de software

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

2.2.6. Calcular la productividad

Mtricas de desarrollo de software

2.2.7. PSP 0.1

Medir el tamao de los programas que se realizan.

Mtricas de desarrollo de software

Realizar el conteo de tamao para los programas realizados.

Actividad 2. Medicin del tamao de un software

Este es el mtodo principal del programa.

Mtricas de desarrollo de software

public static void main(String[] args)