unidad 2 planeacion

22/4/2015 2.1. Introducción a la planeación

http://aulauno.unadmexico.mx/av20151/pluginfile.php/32134/mod_scorm/content/7/01_MDS_U2_2_1/U2_MDS_2_1_p1.html 1/1

En esta segunda unidad analizarás la importancia de planear un proyecto de software antes derealizar cualquier actividad relacionada con el desarrollo del mismo. Asimismo, analizarás de formadetallada, cómo realizar la planeación de un nuevo proyecto de software y cómo, un plan bienrealizado, brinda una mayor confiabilidad para el éxito en la realización de un nuevo proyecto desoftware.

Por naturaleza, los seres humanos, al emprender nuevos proyectos necesitantener una guía o conocer los procesos, acciones o medidas que deben serseguidas para lograr realizar ese proyecto hasta su finalización. A lo largo detoda su vida, el ser humano emprende proyectos: aprobar una materia de laescuela, construir un prototipo que ayuda a resolver un problema, concursar yganar una competencia de deportes, etc.

Comúnmente, aquellos proyectos en los que mejores resultados se obtienenson aquellos para los cuáles se tiene una mejor guía de cómo realizarlos. Enotras palabras, se tenía un plan lo suficientemente sustentado para lograrresultados efectivos al término del proyecto.

En la ingeniería de software, la planeación de los proyectos enfocados en eldesarrollo de nuevas tecnologías de información es una de las etapas másimportantes para el éxito de dicho proceso, pues como revisarás más adelante,la calidad del producto final está dada por la calidad en cada uno de losprocesos llevados a cabo.

En este sentido, la planeación es el primer proceso llevado a cabo aldesarrollar un nuevo producto de software.

Una vez que se ha brindado un panorama general sobre la planeación de proyectos incluyendoproyectos de software, es necesario conocer ampliamente que es un plan, lo cual será explicadoen el siguiente tópico.

+AAa

Unidad 2. Planeación Imprimir

Da clic en el subtema 2.1.1. ¿Qué es un plan? 1 / 1

2.1. Introducción a la planeación

22/4/2015 Presentación de la Unidad

http://aulauno.unadmexico.mx/av20151/pluginfile.php/32134/mod_scorm/content/7/00_MDS_U2_Pres/U2_MDS_Pres_p1.html 1/2

Bienvenido (a) a lasegunda unidad de laasignatura Métricas dedesarrollo de software.

En esta unidadrevisarás los temasrelacionados con lamedición del tamaño deun proyecto desoftware los temas teproporcionará una baseinicial para estimar eltamaño de nuevos proyectos, con la finalidad de poder realizar planes lo más cercano a larealidad.

En la mayoría de los proyectos, existen recursos limitados (dinero, personas, equipos, tecnología).Estos factores conllevan a que los proyectos tengan que planearse y gestionarse de la forma másefectiva y asertiva posible, con la finalidad de que el costo total del proyecto no exceda la cantidadde recursos planeados que son destinados al proyecto. Sin embargo, para poder planear algo,primero se debe ser capaz de estimar cuánto tiempo, costo y personal que se requiere dentro delproyecto.

Para poder estimar, se requiere medir el proyecto. La medición es una tarea fundamental en lamayoría de las disciplinas donde se emprenden proyectos. Dependiendo del contexto, se utilizauna métrica o forma de medir. Por ejemplo, para la construcción, es común medir en áreas lo quese va a construir utilizando alguna unidad como: m2. De igual forma, para estimar el tamaño unnuevo proyecto de software primero se debe tener una forma o métrica de medición enfocada enla medición de un programa.

Además en esta unidad conocerás lo importante que es realizar una planeación previa al desarrollode un nuevo proyecto de software. De igual forma aprenderás por qué es necesario realizarplanes, así como el contenido de una planeación. Entenderás por qué mientras más detalladossean tus planes, más precisas serán tus estimaciones de tiempo y costos antes de comenzar eldesarrollo de un nuevo proyecto. Asimismo, tendrás elementos y bases para gestionar cambios enlos requerimientos planeados, para un nuevo proyecto de software y cómo deben ser manejadosdichos cambios antes de su implementación en el proyecto. Finalmente, conocerás algunastécnicas para estimar el tamaño de un proyecto de software y como este, está relacionado con eltiempo que tomará desarrollarlo.

+AAa


Da clic en la flecha para continuar. 1 / 2

Presentación de la Unidad

http://aulauno.unadmexico.mx/av20151/pluginfile.php/32134/mod_scorm/content/7/00_MDS_U2_Pres/U2_MDS_Pres_p2.html



Propósitos

En esta unidad:

Comprenderás lo que es un plan para un proyecto de softwarey lo que debe contener.Conocerás algunas técnicas para estimar el tamaño de unproyecto de software.Conocerás algunas técnicas para estimar el tiempo quetomará desarrollar un nuevo proyecto de software.

Competencia específica

Aplicar la medición y estimación para planear un programa,tomando en cuenta el plan, sus etapas, criterios y estándaresde medición, así como diferentes métodos de estimación.

+AAa


Da clic en el Tema 2.1. Introducción a la planeación. 2 / 2

Presentación de la Unidad

http://aulauno.unadmexico.mx/av20151/pluginfile.php/32134/mod_scorm/content/7/00_MDS_U2_Pres/U2_MDS_Pres_p1.html

22/4/2015 2.1.1. ¿Qué es un plan?

http://aulauno.unadmexico.mx/av20151/pluginfile.php/32134/mod_scorm/content/7/02_MDS_U2_2_1_1/U2_MDS_2_1_1_p1.html 1/1

En este tópico se te explicará lo que es unplan y como está estrechamente relacionadocon la culminación exitosa de un nuevoproyecto.

Un plan es una guía que muestra los pasos,procedimientos o medidas a seguir paralograr un objetivo o meta determinada.

La mayoría de las veces, el éxito que setiene en un proyecto está en función de lacalidad del plan que se realiza antes decomenzar el desarrollo de ese proyecto. A su vez, la calidad de un plan está dada por el sustento yvalidez de las bases sobre cuáles se apoya dicho plan.

Da clic en el botón para revisar el ejemplo que complementa la información. Ejemplo

Después de que revisaste el concepto de plan, así como su utilización en el desarrollo de nuevosproyectos, analiza algunas situaciones que remarcan la necesidad de realizar planes previos aldesarrollo de nuevos proyectos.

+AAa


Da clic en el subtema 2.1.2. ¿Por qué hacer planes? 1 / 1

2.1.1. ¿Qué es un plan?

22/4/2015 2.1.2. ¿Por qué hacer planes?


La planeación es una etapa quetiene como finalidad aumentar lasposibilidades de éxito que tendrá unproyecto. Existen factoressubyacentes al éxito del proyecto loscuáles se describirán en este tópico yque sustentan la importancia quetiene el realizar planes al emprendernuevos proyectos que involucran eldesarrollo de productos de software.

Al proponer una solución a unproblema relativo a la falta deinformación vigente y confiable,generalmente se involucra en dicha solución, un sistema de información el cual, la mayoría de lasveces, no existe a la medida de la persona o empresa que tiene el problema descritoanteriormente.

Esto conlleva a desarrollar un software que satisfaga las necesidades de información de laempresa o persona en particular.

+AAa



2.1.2. ¿Por qué hacer planes?

http://aulauno.unadmexico.mx/av20151/pluginfile.php/32134/mod_scorm/content/7/03_MDS_U2_2_1_2/U2_MDS_2_1_2_p2.html



Al desarrollar productos de software para un cliente que puede ser algún directivo para laempresa para la cual se trabaja o bien un cliente externo, es común que se realicen doscuestionamientos:

¿Cuánto tiempo tomará desarrollar el sistema?¿Cuánto va a costar?

Si el cliente cuenta con varias opciones para el desarrollo de su programa, quizás se opte por elproyecto que consuma menos tiempo en realizarse y que sea más barato. Sin embargo, estaelección no siempre es la más adecuada.

Cuando se responde a un cliente las preguntas que surgen, aparece el siguiente cuestionamiento:

¿Sobre qué bases es respondido el tiempo que tomará desarrollar el sistema?

Cuando no se lleva una metodología que involucre una sólida planeación en el desarrollo denuevos 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 se planea menos tiempo del que realmente se requierepara desarrollar el proyecto.

Un factor adicional frecuente, que lleva a realizar una mala estimación, es la competencia para serelegidos por el cliente para el desarrollo de dicho proyecto. Esto conlleva a subestimar el esfuerzoreal que requiere el proyecto y se propone un tiempo relativamente corto para la realización delmismo. Al final, el proyecto podría tardarse dos o tres veces más el tiempo estimado. Por eso, semencionó anteriormente que la elección del tiempo más corto no siempre es la más adecuada. Sindejar de lado, que el costo de un proyecto también está relacionado con el tiempo en que sedesarrolla.

Para Zapata et al. (2001), es importante realizar una planeación de los nuevos

+AAa


2.1.2. ¿Por qué hacer planes?



proyectos de desarrollo de software para lograr las mayores posibilidades deéxito. (Zapata, J., García, J., Cerrada, J. 2001. Pág. 4355).Da clic en el subtema 2.1.3. Contenido del plan de un software. 2 / 2


25/4/2015 2.1.3. Contenido del plan de un software


Para que un plan, previo al desarrollo de un nuevo proyecto de software, sea efectivo, debecontener elementos relativos a las tareas que deberán realizarse: el tamaño del proyecto, la formade medir el estatus del proyecto en cualquier momento, etc. Todo esto será analizado y discutidoen este tópico.

El contenido de un plan depende de las necesidades de las personas que utilizarán dicho plan y delo que requieran hacer con él. En PSP la planeación involucra a dos tipos de persona: eldesarrollador y sus clientes.

Una planeación en PSP involucra definir y conocer los siguientes cuatro factores:

1.Tamaño del producto.¿Qué tan grande es elproyecto?

2. Definición de las tareasque tienen que realizarsey como se realizarán.

3. Estatus del trabajo quese está realizando. Estosignifica saber en quéetapa se encuentra, quéfalta por hacer. Estopermite responder unapregunta crítica muyimportante: ¿Se terminaráel producto en el tiempoestimado con los costosplaneados?

4. Evaluación. Este factorse refiere a la evaluaciónde la planeación realizaday responde a laspreguntas: ¿Qué tanefectiva fue la planeación?¿Se cometieron erroresobvios de detectar? ¿Quéerrores se pueden evitaren el futuro? ¿Qué serequiere ajustar omodificar para realizar unamejor planeación?

De lo anteriormente expuesto, Humphrey, W. (1995), menciona que el factor cuatro es de vitalimportancia pues es la clave para mejorar la efectividad de las planeaciones que se realizaránposteriormente para nuevos proyectos.

+AAa



2.1.3. Contenido del plan de un software




Al utilizar PSP, todo lo que se realiza es un trabajo completamente individual. En este contexto,el contenido de las planeaciones debe permitir saber:

¿Qué se tiene que entregar?,¿Cuándo?, ¿Cuánto costará?

¿Existe algúnmecanismo quepermita medir,monitorear oconocer el avancedel proyecto encualquiermomento?

El proyecto que seplanea desarrollar,¿es realmente loque el clientequiere?

En proyectos pequeños, la administración y control de los aspectos anteriores probablemente nosean complejos; sin embargo, se debe ser consciente de lo siguiente:

Laplaneacióndebe estarbasada entareasbiendefinidas.

Cada tareadebe estarclaramentedefinida ydebe serposiblemedirla.

El clientedebe conocerel plan y estarde acuerdocon él antesde comenzarcualquiertarea.

Se debe reportar el avance delproyecto cada determinado tiempo.Este reporte generalmente se debepresentar a los administradores yclientes, para que conozcan cómova evolucionando el desarrollo delmismo.

Se debe considerar que, cuando se planea el trabajo personal, el objetivo escalcular el tiempo que tardará en desarrollarse un determinado proyecto, elcosto que tendrá y qué fechas se tienen planeadas para terminar cada unade las tareas a realizar (Humphrey, W. 1995. pp. 5768).

En el siguiente tópico se comprenderá como comenzar la planeación de un nuevo proyecto así

+AAa


Da clic en el subtema 2.1.4. Planeando un proyecto de software. 2 / 2

2.1.3. Contenido del plan de un software




como los pasos necesarios para poder obtener un plan lo más acertado posible conforme a larealidad.

25/4/2015 2.1.4. Planeando un proyecto de software


En este tópico analizarás los pasos necesarios para realizar el plan de desarrollo de nuevos proyecto de software. Examinarás enprimera instancia la secuencia ordenada de actividades a realizar, para obtener un plan de calidad previo al desarrollo de unproyecto de software.

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

Se debe tenerclaramentedefinido lo que hade realizarse asícomo entenderperfectamente loque se buscahacer. Durante eldesarrollo delproyecto esfrecuente queexistan cambiosen losrequerimientos.Sin embargo, esnecesario planeary definir el mayornúmero de dichosrequerimientos

Dividir las tareasde desarrollo delproyecto quetomarán variosdías en variastareas máspequeñas quese puedan mediry estimar deforma separada.Es importantemencionar que:a mayor detalleen laespecificaciónde las tareasque han dedesarrollarse, laplaneación será

Cuando serealiza laestimación detareas, sedebencomparar conotras tareassimilares quese hayanrealizado enel pasadopara conocerel tiempo quese dedicó aesas tareaspasadas yestimar eltiempo quetomará

Se debe documentarla estimación y altérmino del proyecto,se deben compararlos datos de laestimación contra losdatos reales. Estopermite conocer deforma clara yconsciente el por quéhubo diferenciasentre el tiempoplaneado y el real.Este nuevoconocimientoadquirido tendrá unavital importancia alestimar y planearnuevos proyectos de

Si existen cambios enlos requerimientos, sedebe reajustar laplaneación y antes decomenzar laimplementación decualquier cambio en losrequerimientos, se debeinformar a los jefesinmediatos así como alcliente paraconcientizarlos de lo queimplica en tiempos ycostos laimplementación dedichos cambios derequerimientos y enbase a ello, se tome ladecisión de implementar

+AAa


2.1.4. Planeando un proyecto de software



tanto como seaposible.

más precisa. realizar latareaplaneada.

software. o no dichos cambios.Da clic en la flecha para continuar. 1 / 2




En la figura secuencia de pasos a seguir para elaborar un plande desarrollo de un nuevo proyecto de software, (Humphrey, W.1995. Pág. 65), se muestran los pasos que tienen que realizarsepara obtener un plan eficiente para el desarrollo de un nuevoproyecto.

Da clic en la figura para ampliarla.

Figura. Secuencia de pasos a seguir para elaborar un plan dedesarrollo de un nuevo proyecto de software. (Humphrey, W. 1995.

Pág. 65).

Una vez que conoces los pasos necesarios para realizar la planeación de un proyecto de software, esnecesario conocer aquellos aspectos que dotan de la calidad necesaria a una planeación. Mientras más altasea la calidad de un plan, mayores son las posibilidades de éxito al término del desarrollo del proyecto.(Humphrey, W. 1995. Pág. 5768).

+AAa


Da clic en el subtema 2.1.5. Producir un plan de calidad. 2 / 2

2.1.4. Planeando un proyecto de software


http://aulauno.unadmexico.mx/av20151/pluginfile.php/32134/mod_scorm/content/7/05_MDS_U2_2_1_4/html/HTML_DMDS_U2_01.html

25/4/2015 2.1.5. Producir un plan de calidad


En este tópico discutirás de forma general cómo producir un plan con la calidad adecuada paraobtener éxito en los proyectos planeados. Eso es importante de considerar pues el éxito de unproyecto está dado en gran parte por la calidad del plan que se tiene para su desarrollo.

El objetivo de planear el trabajo, espara obtener un plan preciso queindica qué actividades han derealizarse y en qué tiempo. Sinembargo, para poder obtener estainformación se requiere un estudioprofundo que permita conocercómo medir, predecir y mejorar lasplaneaciones que se realizan.

Cuando se planean nuevosproyectos de software, se hace dedos formas: imparcial obalanceado.

Se considera que una planeaciónestá balanceada si por ejemplo, de diez proyectos, cinco fueron sobreestimados y cinco fueronsubestimados.

Un proyecto sobreestimado es aquel en el cual se planeó más tiempo para su realización que eltiempo 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 planeación imparcial se da cuando no es balanceada, es decir, el número de proyectossobreestimados no es igual al número de proyectos subestimados.

De acuerdo a la experiencia de Watts Humphrey, el autor del PSP, una planeación balanceadapermite realizar un mejor ajuste de la estimación de tiempos para nuevos proyectos, pues al haberun equilibrio entre los proyectos sobreestimados y los subestimados, se puede fácilmente obtenerun tiempo promedio a través del método PROBE, el cual revisarás posteriormente.Para terminar decomprender el proceso de la planeación de un proyecto de software, se analizarán las etapasinvolucradas en la planeación. (Humphrey, W. 2005. Pág. 65).

+AAa


Da clic en el subtema 2.1.6. Etapas de la planeación. 1 / 1

2.1.5. Producir un plan de calidad

25/4/2015 2.1.6. Etapas de la planeación


El proceso de planear un proyecto de software está conformado por varias etapas que serándescritas en este tópico. Es importante que sigas cada una de estas etapas sin omitir ninguna conla finalidad de que la planeación final del proyecto sea lo más real posible.

Planear un proyecto de software implica las siguientes etapas:

Da clic en los números para revisar la información.

Conocer lasnecesidades del

cliente

Definición derequerimientos

Realizar undiseño

conceptual

Estimar eltamaño delproyecto

Planeación delos recursos

Desarrollo delproyecto

Generaciónde nuevosdatos

Análisis delos datos

Ya que has revisado las etapas que involucran la planeación de un proyecto de software, debescomprender el aspecto principal: medir el tamaño del proyecto. Esta es quizás la tarea más difícil ycrítica en la planeación de un proyecto.

El siguiente tema estará completamente enfocado en describir el proceso de medición del tamañode un nuevo proyecto de software.

+AAa


Da clic en la Actividad 1. Plan del proyecto. 1 / 1

2.1.6. Etapas de la planeación

25/4/2015 Actividad 1. Plan del proyecto

http://aulauno.unadmexico.mx/av20151/pluginfile.php/32134/mod_scorm/content/7/08_MDS_U2_Act_1/U2_MDS_Act_1_p1.html 1/1

Esta actividad tiene como finalidad que demuestres lo que has comprendido respecto a lo que esun plan de un proyecto de software y que compartas tus soluciones en el foro con tus compañeros.La actividad tiene como propósito comprender lo qué es un plan, su contenido, etapas y cómo seplanea un proyecto de software.

1. Descarga el archivo, lee y resuelve la problemática planteada.

Da clic en el icono para descargar el archivo.

2. Ingresa al foro y comparte al menos con tres compañeros las soluciones de la actividad.

3. Atiende a las indicaciones de tu Facilitador(a), pues, en el foro tendrás que argumentar elporqué de tus respuestas.

4. No olvides consultar la Rúbrica general de participación en foros.


La planeación es un elemento clave en el desarrollo de cualquier proyecto de software, ya que sino se planean las actividades que se necesitan en el proyecto, hay una alta probabilidad de que nose realicen. Si no se registran las actividades que se realizan, no se podrá identificar cuánto tiempose tardan en realizarlas, es por ello que realizar planes es una buena práctica en el desarrollo desoftware.

+AAa


Da clic en el Tema 2.2. Medición del tamaño del software. 1 / 1

Actividad 1. Plan del proyecto

http://aulauno.unadmexico.mx/av20151/pluginfile.php/32134/mod_scorm/content/7/08_MDS_U2_Act_1/docs/Rubrica%20general%20de%20participacion%20en%20foros.pdf

http://aulauno.unadmexico.mx/av20151/pluginfile.php/32134/mod_scorm/content/7/08_MDS_U2_Act_1/docs/Actividad%201.docx

25/4/2015 2.2. Medición del tamaño del software


Cuando se planean nuevosproyectos de software,inevitablemente se tiene queestimar o tener un conocimientopreliminar sobre el tiempo quetomará realizar dicho proyecto.

Esta etapa cobra una vitalimportancia, pues de los datos quese generen depende en granmedida el costo que tendrá elproyecto para el cliente.

Sin embargo, para poder estimar opredecir cuánto tiempo se requierepara desarrollar el proyecto, esnecesario conocer o tener unamedida del mismo, para este propósito surgen un par de preguntas:

¿Cómo se mide un proyecto de software?¿Qué medida es la más precisa?

En este tema analizarás algunas técnicas para medir y estimar el tamaño de nuevos proyectos desoftware, pues a través de los años, el estudio e investigación sobre PSP, por parte de WattsHumphrey, ha recopilado una serie de datos y buenas prácticas que ahorrarán en gran medida lainvestigación y aprendizaje en este tema. (Zapata, J., García, J., Cerrada, J. 2001. Pág. 5871).

+AAa


Da clic en el subtema 2.2.1. Medición del tamaño. 1 / 1

2.2. Medición del tamaño del software

25/4/2015 2.2.1. Medición del tamaño


Para comprender las métricas para el tamaño de un producto de software conviene responder lasiguiente pregunta:

¿Por qué medir el tamaño?

Como se mencionó en la introducción a este capítulo, conocer el tamaño de algo, en este caso, deun proyecto de software, es fundamental para poder estimar cuánto tiempo tomará desarrollardicho proyecto.Una vez que se conoce la importancia de medir el tamaño, la siguiente preguntaque surge es:

¿Cómo se puede medir el tamaño de unproyecto de software?

Responder a la pregunta anterior ha sido uno de losretos más controversiales que ha tenido la ingeniería desoftware desde que los proyectos tuvieron la necesidadde planearse, en la década de 1970.

A lo largo de ese tiempo, los lenguajes y paradigmas dela programación han estado en constante cambio. Estefactor ha sido determinante para hacer aún máscomplejo el obtener una métrica o forma de medir el tamaño de un proyecto de software de formaprecisa en un cien por ciento.

Por lo tanto, no existe una métrica que sea exacta por completo, sino por el contrario, todas lasmétricas que se han utilizado hasta ahora son aproximaciones, sin embargo, si existen diferenciasconsiderables en la exactitud y eficacia de cada una de ellas.

+AAa



2.2.1. Medición del tamaño




Para que una métrica, en cualquier contexto y escenario, sea útil, debe cumplir con lo siguientesegún (Humphrey, W. 1995.):

Da clic en cada uno de los rectángulos para ampliar la información.

Debeservir paraunpropósitoespecífico.

Debeestarbiendefinida.

Debe seradecuadamenteadministrada.

Debe seradecuadamenteutilizada.

Se mide para:

Entender y saber administrar los cambiosPlanear el futuroComparar un producto, organización o proceso con otroDeterminar si se estánapegados a estándaresContar con bases para controlar

+AAa


Da clic en las flechas para avanzar o retroceder. 2 / 3






Se tiene que ser consciente qué las medidas solo producen números. Para que una medida sea deutilidad, debe:

Estar relacionada con losobjetivos que se planteanalcanzar. Si lo que se mide no estárelacionado con losobjetivos que se deseanlograr, no hay razón parainvertir esfuerzos en mediraquello.

Ser adecuadamenteinterpretada. Una vez que se obtieneuna medida, se debeentender lo que esamedida significa y lo queno. Por ejemplo, conocerel número de tablas quetendrá la base de datos nosignifica conocer cuántasde esas tablas seráncatálogos que impliquen supropia interface para altas,bajas y cambios.

Permitir tomar accionesapropiadas. El conocer la medida dealgo, debe ser utilidad paratomar acciones apropiadasya sean de carácterpreventivo, correctivo o lasacciones de curso normalpara lograr los objetivosplanteados al inicio deldesarrollo del proyecto asícomo para efectuar unamejor planeación denuevos proyectos.

A lo largo del tiempo, se han propuesto varias técnicas para medir el tamaño de un proyecto desoftware. A continuación se mencionan algunas de ellas:

Número de archivos que tendrá el programaNúmero de módulos que tendrá el programaNúmero de tablas en la base de datosNúmero de pantallas que tendrá la aplicaciónPuntos de funciónLíneas de código

De las técnicas mencionadas anteriormente, la que más efectiva ha sido en elPSP es la métrica por líneas de código. Como su nombre lo indica, estatécnica se basa en contar las líneas de código que tiene o tendrá el proyectode software. Esto será tratado con mayor detalle en los siguientes tópicos.(Humphrey, W. 1995. Pág. 6990).

+AAa


Da clic en el subtema 2.2.2. Establecer un conteo estándar. 3 / 3



25/4/2015 2.2.2. Establecer un conteo estándar


Al elegir una métrica para calcular el tamaño 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 laprecisión de la métrica que se está aplicando para medir algo. Si cada ocasión que se mide elmismo objeto, en las mismas condiciones, se obtienen resultados distintos, inevitablemente sedebe tomar algún otro criterio o métrica más estable que nos permita obtener confiabilidad en lasmedidas que arroja.

Para poder homogenizar una métrica y aumentar su confiabilidad, es necesario realizar unestándar de conteo.

Un estándar de conteo es undocumento que expresa deforma clara y sin ambigüedadqué es algo contable y qué no loes, de acuerdo con una métricadeterminada. En el caso de lamétrica de líneas de código, endicho estándar se debe definir loque sí debe ser contado comouna línea de código y lo que no.

Por ejemplo, los comentarios enel código, ¿deben serconsiderados como líneas decódigo o no?

Decidir si las líneas de un comentario en el código fuente de un programa o módulo seráncontadas depende de quien realiza el estándar de conteo de líneas de código y del criterio queaplique para tomar esta decisión.

+AAa


Da clic en el subtema 2.2.3. Contadores de LOC y tipos. 1 / 1

2.2.2. Establecer un conteo estándar

25/4/2015 2.2.3. Contadores de LOC y tipos


Llevar un conteo de líneas de código de forma manual es muy difícil e impreciso. Por tal motivo,existen distintas herramientas que ayudan a los ingenieros de software con esta tarea. Sinembargo, se tiene que considerar que los contadores de líneas de código automatizadossolamente trabajarán para las características que se han definido en dicho contador.

Al elegir un programa contadorde líneas de código, se debeasegurar que dicho programa seapega al estándar de conteodefinido con anterioridad. Deotra forma, sería impreciso ypoco útil el utilizar esa métrica sino se apega al estándar deconteo definido previamente.

Una práctica común parasalvaguardar este escenario esel de tomar con estándar deconteo de líneas el propioestándar que ya trae por definición el programa contador de líneas de código elegido (Humphrey,W. 2005. Pág. 3555).

+AAa



2.2.3. Contadores de LOC y tipos


25/4/2015 2.2.3. Contadores de LOC y tipos


De las diversas soluciones que existen, algunas son de pago y otras gratuitas. La diferencia entreunos y otros son básicamente las prestaciones que brindan así como los lenguajes y plataformasque soportan.

A continuación se mencionan algunos contadores de líneas de código y sus características:

Programa Gratuito Página de la compañíaPlataformasy lenguajessoportados

CodeCounterPro

No http://www.geronesoft.com/ Varios

MicrosoftLOCCounter

Si http://archive.msdn.microsoft.com/LOCCounter

Lenguajesde laplataforma.Net 4.0

CodeLineCounterPro

No http://www.codelinecounter.com/

Varios. Secompra porseparadopara cadalenguajedistinto.

Tabla. Software para contar líneas de código.

No importa cuál sea la herramienta que utilices, si tu equipo no tiene correctamente definidos losestándares de conteo habrá discrepancia en la forma de contar de cada programador. Por ejemploel código de reúso no debería contarse a menos que hagas mejoras. En el siguiente tema seexplica en que consiste este tipo de código y su utilidad para las empresas de desarrollo.

+AAa


Da clic en el subtema 2.2.4. Consideraciones del reuso. 2 / 2

2.2.3. Contadores de LOC y tipos

http://archive.msdn.microsoft.com/LOCCounter


http://www.codelinecounter.com/

http://www.geronesoft.com/

25/4/2015 2.2.4. Consideraciones del reuso


Al desarrollar nuevos proyectos, se intenta reducir el esfuerzo requerido en el desarrollo.

Una de las prácticas comunes es buscar código existente de proyectosprevios para reutilizarlo en los nuevos evitando invertir esfuerzos para obtenerun código que hace la misma función de uno que previamente ya se habíadesarrollado.

También, es común en pensar en modificar un código existente ysimplemente adaptarlo antes que crear uno completamente. Sin embargo,debe evaluarse si el esfuerzo requerido para modificar un código existenterealmente es menor que el necesario para crear ese código fuente desde elprincipio.

En el mejor de los casos, lo más conveniente es utilizar librerías y módulos completos previamentedesarrollados evitando de esta forma el mayor esfuerzo posible. Sin embargo, poder llegar a estetipo de buenas prácticas implica que para cada proyecto desarrollado deben crearse módulosgenéricos con la menor dependencia posible del proyecto. Lo cual, es una tarea que se da por laexperiencia obtenida con el progresivo desarrollo de proyectos. (Humphrey, W. 1995. Pág. 84).

+AAa


Da clic en el subtema 2.2.5. Conteo de líneas de código. 1 / 1

2.2.4. Consideraciones del reuso

25/4/2015 2.2.5. Conteo de líneas de código


En el subtema 2.2.3, analizaste de forma introductoria lo que significa el conteo de líneas de códigode un programa y cómo esta métrica puede ser utilizada en PSP para obtener el tamaño de unproyecto de software basado en el número de líneas de código del mismo.

A continuación analizarás de forma detallada cómo se realiza un conteo de líneas de código deacuerdo al PSP. Aun cuando la métrica basada en líneas de código, en adelante denominadasLOC’s, pareciera ser sencilla, en la práctica resulta difícil llevar un rastreo de las mismas si no espropiamente definido y utilizado el concepto de línea de código.

De acuerdo con la metodologíade PSP, si al iniciar la realizaciónde un nuevo proyecto desoftware, se inicia con 5000líneas de código que se tomande otro programa, en la queposteriormente se escriben 500líneas de código adicionales, elresultado debería ser 5500líneas de código. Por lo tanto, sisólo escribes 500 líneas decódigo el resultado debería serun programa de 500 líneas decódigo.

Aun cuando este ejemplo parece obvio, en la realidad, al crecer y haber cambios en los proyectosde software, se obtiene un resultado diferente. A esto se debe la necesidad de entender y utilizarapropiadamente el tamaño de un programa basado en sus líneas de código.

Cuando se desarrolla un nuevo programa, generalmente intervienen 4 tipos distintos de líneas decódigo (Humphrey, W. 2005. Pág.4047).

La razón por la cual es necesario llevar un rastreo de las líneas base, agregadas, modificadas yborradas se debe a que por ejemplo, si se comienza el desarrollo del programa en la versión 0, secuentan con 400 líneas de código base y después se agregan 200, se esperaría tener una primerversión con 600 líneas de código. Sin embargo, al contar las líneas de código de la versión 1 eltamaño total es de 550 líneas de código, entonces ¿Qué sucedió con las 50 líneas de códigofaltantes?

+AAa


Da clic en el subtema 2.2.6. Calcular la productividad. 1 / 1

2.2.5. Conteo de líneas de código


25/4/2015 2.2.6. Calcular la productividad


La productividad es un factor que relaciona el tiempo requerido para una tarea determinada y elproducto derivado de realizar dicha tarea.

Este factor es utilizado en muchas de las áreas productivas dentro de las actividades humanas y esun factor clave para determinar el tiempo total que requerirá concluir una tarea específica por unapersona en particular, de la cual se conoce su productividad.

En este subtema, revisarás elconcepto de la productividadrelacionada con el desarrollo deproductos de software y cómo secalcula la productividad.

El desarrollo de un producto desoftware involucra unaplaneación previa al desarrollodel proyecto.

Planear el desarrollo de dichoproyecto involucra conocer eltamaño del proyecto.

Conocer el tamaño del proyecto es un dato vital para poder estimar y planear el tiempo en que hade ser desarrollado. Sin embargo, para calcular el tiempo requerido para el desarrollo del proyecto,es necesario conocer un dato adicional: ¿con qué rapidez se desarrollan las tareas por parte decada integrante del equipo de desarrollo contemplado para dicho proyecto?

+AAa



2.2.6. Calcular la productividad




Calcular la productividad en eldesarrollo de software no es unatarea sencilla y a lo largo del tiempose han propuesto varias métricaspara poder lograr este objetivo.

Por ejemplo:

Se ha propuesto medir laproductividad de undesarrollador basado en lashoras promedio que le tomaconstruir un archivo de texto.Otras variantes involucran eltiempo que toma producir unarchivo de código en algúnlenguaje de script, unapantalla de usuario, etc.

Para el caso de PSP, el autorpropone una métrica deproductividad basada en las líneas de código nuevas que un desarrollador realiza en una hora.

Si bien, esta métrica pudiera no ser la mejor, ha demostrado ser la más efectiva para medir laproductividad de un ingeniero de software.

Si la medición del tamaño de un producto de software está basada en sus líneas de código y, laproductividad de un desarrollador está basada en las líneas de código que produce en una hora, laestimación del tiempo requerido para desarrollar el producto se puede calcular fácilmentedividiendo el tamaño estimado del producto entre la productividad del desarrollador:

Para concluir con este subtema, solo resta mencionar que la productividad de un desarrollador noes constante. A lo largo del tiempo y después de la experiencia en el desarrollo de variosproyectos, los desarrolladores van aumentando su productividad a la vez que haciendo máseficientemente sus tareas.

Por eso es importante ir recolectando datos de la productividad en cada proyecto. Esto permitirá asu vez, obtener información sobre la productividad de los equipos de desarrollo así comoinformación que servirá de base para poder estimar el tiempo de desarrollo de futuros proyectos.(Humphrey, W. 1995. Pág. 88).

+AAa


Da clic en el subtema 2.2.7. PSP 0.1. 2 / 2

2.2.6. Calcular la productividad


25/4/2015 2.2.7. PSP 0.1


En PSP 0.1 tiene los siguientes objetivos:

Medir el tamaño de losprogramas que se

realizan.

Realizar el conteo de tamañopara los programas

realizados.

Desarrollar métricas detamaño 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 inglés,ProcessImprovementProposal), significa

Propuesta de Mejora del Proceso.

Formato para elconteo del tamañodel programa.

Estándar decodificación.

Como resultado de esto, el formato del resumen del plan del proyecto tambiéndeberá mostrar los datos referentes al tamaño del programa tomando encuenta que a partir de este nivel, el desarrollo del programa debe serplaneado por cada fase del ciclo de desarrollo. (Echeverría, C.M., Echeverría,C.D. Mera, J.L. 2006. Pág 2326).

+AAa


Da clic en la Actividad 2. Medición del tamaño de un software. 1 / 1

2.2.7. PSP 0.1

25/4/2015 Actividad 2. Medición del tamaño de un software


Esta actividad tiene la finalidad de que comprendas la medición del tamaño de un producto desoftware, a través de conteo de las líneas de código que lo componen, mediante la aplicación deun estándar de codificación y compararlo con tus compañeros en la Base de datos del grupo. Elpropósito es analizar en un programa la medición del tamaño del software a través del estándar deconteo de líneas de código, reuso y productividad.

1. Descarga y analiza el siguiente código correspondiente a un producto de software,atiendelas instrucciones del documento.


2. Guarda la actividad con el nombre DMDS_U2_A2_XXYZ.

3. Ingresa al apartado de Base de datos y sube tu archivo.

4. Revisa los trabajos de tus demás compañeros en la base de datos para que puedascomparar tus resultados con los del resto del grupo.

5. Comenta por lo menos tres líneas que identifiques incorrectas argumentando el porqué delerror.

6. Atiende a los comentarios que emita tu Facilitador(a).

Establecer estándares para definir la manera de contar las líneas de código es una buena prácticaque necesitarás para evitar errores en la forma en que se mide la productividad y la de otrosmiembros del equipo. Esto permitirá realizar mediciones más precisas para la toma de decisionesoportunas.

Consideraciones para la actividad:

Se espera que los(as) alumnos(as) socialicen sus diferencias en torno a las respuestas, esdecir, argumentarán el porqué de su comentarios.Los(as) alumnos(as) deberán comentar por lo menos tres errores en las bases de datos desus compañeros.Para ser considerada como actividad aprobada, el alumno deberá cumplir con por lo menos65 líneas correctas.

+AAa


Da clic en el Tema 2.3. Estimación del tamaño del software. 1 / 1

Actividad 2. Medición del tamaño de un software


25/4/2015 2.3. Estimación del tamaño del software


Una vez que se tiene una métrica para medir el tamaño de un producto de software, se tienetambién una base para poder estimar que tan grande será un nuevo proyecto basado en los datoshistóricos previos de otros proyectos.

En principio, las estimacionesson realizadas comparando eltrabajo planeado con el trabajorealizado en proyectosanteriores.

Si se divide el proyecto actual enpartes más pequeñas y secomparan con partes máspequeñas de proyectosanteriores, se puede obteneruna mejor estimación del tamañototal del proyecto. Estaestrategia funciona bien para lamayoría de los proyectos que se realizan en distintas áreas.

El proceso de estimación del tamaño de un producto de software a través de la división de tareastiene la ventaja de que es fácilmente escalable. Si se es capaz de estimar proyectos pequeños, sepuede ser capaz de estimar proyectos grandes a través de esta técnica.

+AAa


Da clic en el subtema 2.3.1. Contexto. 1 / 1

2.3. Estimación del tamaño del software

25/4/2015 2.3.1. Contexto


Generalmente, cuando se planea el desarrollo de un nuevo proyecto, tan solo se conocenlos requerimientos del cliente.

La dificultad de estimar el tamaño del proyecto es precisamente el poder predecir eltamaño 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 enrealizarse, la estimación seré siempre un proceso con un cierto grado de incertidumbre.Por lo tanto, siempre será una ventaja el contar con una mejor definición así como elmayor número de requerimientos por parte del cliente. (Humphrey, W. 1995. Pág. 97).

+AAa


Da clic en el subtema 2.3.2. Métodos de estimación. 1 / 1

2.3.1. Contexto

25/4/2015 2.3.2. Métodos de estimación


Existen varios métodos que ayudan a estimar el tamaño de un nuevo producto de software, asícomo establecer su costo. Algunos de estos métodos son herramientas comerciales, otras son deimplementación personalizada, automatizadas o manuales. Dentro de las comerciales existe unaamplia variedad que ayudan a las organizaciones de desarrollo de software a generarestimaciones más precisas y controlables.

Algunos ejemplos son:

COCOMO

II CoStar CostModeler CostXpert KnowledgePlan®

PRICE

S SEER SLIM SoftCost

Las herramientas comerciales están principalmente enfocadas a la estimacióndel costo del software y muchas de ellas comparten algunas característicascomo:

Especificación de requerimientos.Niveles de fase, actividad, tarea, etc.Definición del período laboral y vacacional.Manejo de salarios.Uso de diferentes tipos de proyectos.Métricas de puntos de función, líneas de código, etc.

Sin embargo, ningún método de estimación es lo suficientemente preciso para indicar con exactitudlos tiempos que cada tarea te llevará. Una buena práctica de la estimación es que la herramientaque se utilice, ya sea la comercial o propia, se vaya mejorando con cada proyecto y cada vez tepueda ir dando valores más cercanos a la realidad. En el siguiente tema revisaras los dos métodosque se recomiendan en PSP los cuáles son el Proxy y el PROBE. Y en la unidad 3 verás métodosbasados en juicio experto y estadísticos. (Jones, C. 2010. Pág. 1).

+AAa


Da clic en el subtema 2.3.3. Proxy. 1 / 1

2.3.2. Métodos de estimación

25/4/2015 2.3.3. Proxy


El método Proxyes un métodopropuesto porWatts Humphrey,creador de PSP,se utiliza paramedir el tamañoque tendrá unproducto desoftware basadoen la división máselemental de loscomponentesque integrarán elproducto que sepiensadesarrollar.

A estos elementos se les llama “partes proxy” cuya característica principal es que pueden sercomparados con otros elementos proxy correspondientes a proyectos desarrollados previamentede los cuales ya se tienen datos históricos.

El siguiente ejemplo muestra en primera instancia las bases de un método de estimación basadoen un proxy:

Si se piensa por ejemplo, en la construcción de una casa tomando en cuenta lacantidad de metros cuadrados que se van a construir, se podría tener unabase para estimar el costo de construcción. Sin embargo, algunas personas,pueden pensar en términos de metros cuadrados basados en el número decuartos y baños que tendrá la casa para realizar la estimación del costo deconstrucción. La estimación del software es un problema similar. Si se pudierasaber el número de tablas y relaciones entre ellas, que tendría la base dedatos o, el número de líneas de código que tendrá el programa, se formularíauna base para poder estimar su tamaño.

+AAa



2.3.3. Proxy


25/4/2015 2.3.3. Proxy


Es muy difícil realizar la estimación del tamaño de un programa basado únicamente en losrequerimientos del cliente. Se requiere de algún proxy que permita relacionar el tamaño delproducto con las funciones que se desean incorporar en el programa. Un proxy no es más que unsustituto del cual conoces su tamaño. Ejemplos de proxies son tablas, clases, campos opantallas.

Existen algunos criterios para seleccionar un proxy adecuadamente:

La medidadel proxydebe estaraltamenterelacionadacon elesfuerzorequeridoparadesarrollarelproducto.

El contenidoproxy de unproducto debeserautomáticamentecontable.

El proxydebe serfácil devisualizaral iniciodelproyecto.

El proxy debeserpersonalizablea lasnecesidadesde cadaproyecto ydesarrollador.

El proxy debeser sensible alas variacionesdeimplementaciónque afectan loscostos dedesarrollo oesfuerzo.

+AAa


Da clic en las flechas para avanzar o retroceder. 2 / 3

2.3.3. Proxy



25/4/2015 2.3.3. Proxy


Da clic en la figura para ampliarla.

Figura. Diagrama del proceso para estimar proyectos de softwareutilizando el método Proxy. (Humphrey, W. 1995. Pág. 110).

El siguiente diagrama muestrael proceso para seleccionar unproxy adecuado en eldesarrollo de un proyecto.

Una vez que comprendiste elmétodo de estimación porproxy podrás analizar unmétodo más complejodenominado PROBE. Elmétodo PROBE está basadoen el método Proxy, peroademás, permite estimar eltiempo requerido para eldesarrollo de cada parte delproyecto. (Humphrey, W. 1995.Pág. 109).

+AAa


Da clic en el subtema 2.3.4. Probe. 3 / 3

2.3.3. Proxy



25/4/2015 2.3.4. Probe


El método PROBE permite obtener una estimación del tamaño de cada parte del proyecto (basadoen la metodología Proxy) y posteriormente, con estos datos, permite estimar el tiempo requeridopara el desarrollo de cada una de las partes del proyecto.

El método PROBE utiliza datos históricos para realizar las estimaciones. Porejemplo, si se estima el trabajo para desarrollar un sistema de consultas enuna base de datos, se podría producir inicialmente un diseño conceptual ydespués dividirlo en partes. Posteriormente, se podrían estimar el número deelementos en cada parte. Por ejemplo, si se estiman un total de 95 elementosy se sabe que cada elemento se lleva en producirse en promedio, 1.5 horas,el tiempo estimado total de desarrollo serían 142.5 horas.

Para hacer más precisas las estimaciones se requiere además de una basepara calcular el tiempo promedio requerido para desarrollar un determinadocomponente del programa.

Una vez que se han comprendido los conceptos de estimación de tamaño y tiempo de desarrollo,es necesario comprender como son utilizados dentro del proceso PSP, en específico, en el niveluno (también conocido como PSP1), el cual, será descrito más adelante. (Humphrey, W. 2005.Pág.105).

+AAa


Da clic en el subtema 2.3.5. PSP 1. 1 / 1

2.3.4. Probe

25/4/2015 2.3.5. PSP 1


Durante la unidad 1, analizaste el PSP 0, el cual es el nivel inicial del proceso personal de software.Como recordarás, el objetivo en PSP 0 era estimar el tiempo total que tomaría desarrollar undeterminado 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 empírica, basado en la experiencia deldesarrollador, el tiempo de desarrollo por cada fase y se estima además, las líneas de código quepodría tener el nuevo programa a desarrollar.

En PSP 1, el objetivo es el mismo que en PSP 0.1, solo que, la estimación de las líneas de códigose realiza utilizando el método Proxy y adicionalmente, utilizando el método PROBE y los datoshistóricos de PSP 0 y PSP 0.1, se estima de forma automática el tiempo de desarrollo por cadafase.

El objetivo en PSP1 es establecer un procedimiento ordenado y repetiblepara realizar estimaciones de tamaño y tiempo de desarrollo por cada fasepara un nuevo producto de software. Este nivel toma en cuenta dos nuevosaspectos:

Estimación de tamaño y tiempo basado en el método PROBEReporte de pruebas

La hoja del resumen del plan del proyecto se expande para mostrar además de los datos dePSP0.1, datos de productividad (medida en líneas de código por hora), tamaño planeado paratodos los tipos de líneas de código. (Zapata, J., García, J., Cerrada, J. 2001. Pág. 6061).

+AAa


Da clic en la Actividad 3. Estimación del tamaño de un software. 1 / 1

2.3.5. PSP 1

25/4/2015 Actividad 3. Estimación del tamaño de un software


Esta actividad tiene la finalidad de que reflexiones sobre la estimación del tamaño de un productode software y determinar la factibilidad de utilizar métodos de estimación como Proxy o PROBE deacuerdo a los escenarios propuestos. El propósito es reforzar la comprensión acerca de laestimación del tamaño de un producto de software.

1. Descarga el archivo y analiza los dos escenarios que se muestran en el documento.


2. Guarda la actividad con el nombre DMDS_U2_A3_XXYZ.

3. Ingresa al apartado de Tareas y sube tu archivo.

4. Espera retroalimentación por parte de tu Facilitador(a).

5. Atiende los comentarios y, en caso de ser necesario, modifica tu actividad y envíala denuevo.

Considera que una buena estimación es la que proporciona una visión clara de la realidad de unproyecto, permite al líder controlar adecuadamente el proyecto y lograr los objetivos.

+AAa


Da clic en Autoevaluación. 1 / 1

Actividad 3. Estimación del tamaño de un software


25/4/2015 Evidencia de aprendizaje. PSP 1

http://aulauno.unadmexico.mx/av20151/pluginfile.php/32134/mod_scorm/content/7/26_MDS_U2_Evi/U2_MDS_Evi_p1.html 1/1

Cuando se generan programas con PSP1, se debe estimar basado en los datos históricos. En estaactividad aprenderás a utilizar el método PROBE basado en los proxies de un proyecto. Elpropósito es utilizar el método de estimación PROBE en un programa a través de la definición delcontexto, identificación de proxies e identificación de otros métodos de estimación.

1. Descarga el archivo con la actividad y atiende las indicaciones del documento.


2. Guarda la actividad con el nombre DMDS_U2_EA_XXYZ. Envía a tu archivo a tuFacilitador(a) por medio de la herramienta Portafolio de evidencias.

3. Espera retroalimentación por parte de tu Facilitador(a) y en caso de ser necesario, modificay reenvía tu evidencia.

La estimación de líneas de código es un elemento importante para poder hacer planes de nuestrosprogramas o proyectos de software. Es por ello que llevar un adecuado estándar de conteo delíneas de código es importante para tener un registro histórico confiable y cada vez más preciso.

Además de enviar tu trabajo de la Evidencia de aprendizaje, es importante que ingreses al foroPreguntas de Autorreflexión y consultes las preguntas que tu Facilitador(a) presente, a partir deellas, debes elaborar tu Autorreflexión en un archivo de texto llamado DMDS_U2_ATR_XXYZ.Posteriormente envía tu archivo mediante la herramienta Autorreflexiones.

+AAa


Da clic en Cierre de la Unidad. 1 / 1

Evidencia de aprendizaje. PSP 1

http://aulauno.unadmexico.mx/av20151/pluginfile.php/32134/mod_scorm/content/7/26_MDS_U2_Evi/docs/DSC_DMDS_U2_05.docx

25/4/2015 Cierre de la Unidad

http://aulauno.unadmexico.mx/av20151/pluginfile.php/32134/mod_scorm/content/7/27_MDS_U2_Cierre/U2_MDS_Cierre_p1.html 1/1

Has concluido la unidad 2, durante esta unidad realizaste una planeación para un proyecto desoftware, además pudiste darte cuenta de acuerdo a los temas vistos y actividades realizadas laimportancia de elaborar el contenido de una planeación. Por consiguiente pudiste determinar loimportante que es precisar en los tiempos y costos de cada proyecto que se proponga realizarespecíficamente en un proyecto de software.

Tuviste la oportunidad de estudiar varios temas que estos llevarán aporte para darle continuidaden la siguiente unidad. En la siguiente unidad podrás poner en práctica los conocimientos de estaunidad más los nuevos que tienen que ver con los proyectos de software.

+AAa


Da clic en Para saber más. 1 / 1

Cierre de la Unidad

25/4/2015 Para saber más

http://aulauno.unadmexico.mx/av20151/pluginfile.php/32134/mod_scorm/content/7/28_MDS_U2_Para/U2_MDS_Para_p1.html 1/1

Si deseas saber acerca de PSP, TSP o CMMI puedesconsultar la siguiente dirección electrónica, disponible dandoclic en la imagen, la información que se muestra, es de unaenciclopedia virtual, colaborativa y en español que fuecreada para difundir el conocimiento de tecnologías de lainformación, sus fuentes son confiables. Puedes participaren sus foros y acceder a este sitio por medio de las redessociales más importantes de la actualidad.

+AAa


Da clic en Fuentes de consulta. 1 / 1

Para saber más

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

25/4/2015 Fuentes de consulta

http://aulauno.unadmexico.mx/av20151/pluginfile.php/32134/mod_scorm/content/7/29_MDS_U2_Fuentes/U2_MDS_Fuentes_p1.html 1/1

Bibliografía básica

Humphrey, W. (1995). A discipline for software engineering (The complete PSP Book) UnitedStates of America: Addison Wesley.Humphrey, W. (2005). PSP a Selfimprovement process for software engineers. UnitedStates of America: Addison Wesley.Zapata, J., et al. (2001). Introducción al proceso software personalSM. Madrid, España:Addison Wesley.

Bibliografía complementaria

Echeverría, C.M. et al.(2006). “Implementación de un sistema integrado de control de costosde producción, órdenes de trabajo, presupuesto de obras, bodega y control de inventarioutilizando PSP y TSP”. Guayaquil, Ecuador. Escuela superior politécnica del litoral.Recuperado de http://www.dspace.espol.edu.ec/handle/123456789/5006Jones, C. (2010). “Métodos de estimación de costos de software para grandes proyectos”.Recuperado dehttp://www.liderdeproyecto.com/articulos/estimacion_costos_de_software.html

+AAa


Ahora revisa la Unidad 3. Planeación, recursos y calendario. 1 / 1

Fuentes de consulta

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

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

unidad 2 planeacion

Documents