08 Ingenieria de Software PDF

INGENIERÍA DE SOFTWARE
SEMANA 8
Etapa VI:
gestión de calidad y
administración de
proyectos de software
Todos los derechos de autor son de la exclusiva propiedad de IACC o de los otorgantes de sus licencias. No está
permitido copiar, reproducir, reeditar, descargar, publicar, emitir, difundir, poner a disposición del público ni 1
ESTE
utilizarDOCUMENTO
los contenidos paraCONTIENE LAdeSEMANA
fines comerciales 8
ninguna clase.
2
ESTE DOCUMENTO CONTIENE LA SEMANA 8
ÍNDICE
ETAPA VI: GESTIÓN DE CALIDAD Y ADMINISTRACIÓN DE PROYECTOS DE SOFTWARE ...................... 4

OBJETIVOS ESPECÍFICOS ........................................................................................................................... 4
INTRODUCCIÓN ...................................................................................................................................... 4
1. GESTIÓN DE CALIDAD EN PROYECTOS DE SOFTWARE ........................................................................... 5
1.1. CALIDAD DE PROCESO Y PRODUCTO .......................................................................................... 6
1.2. GARANTÍA DE CALIDAD Y ESTÁNDARES....................................................................................... 7
1.3. CONTROL DE CALIDAD ............................................................................................................. 8
1.4. MEDIACIONES Y MÉTRICAS DEL SOFTWARE ................................................................................ 9
2. ADMINISTRACIÓN DE PROYECTOS DE SOFTWARE .............................................................................. 10
2.1. CONCEPTOS ......................................................................................................................... 11
2.2. COSTOS Y TIEMPO EN PROYECTOS DE DESARROLLO DE SOFTWARE .............................................. 13
2.3. CALENDARIZACIÓN DE PROYECTOS.......................................................................................... 24
2.4. SELECCIÓN DE PERSONAL ....................................................................................................... 27
2.5. ORGANIZACIÓN DEL PERSONAL............................................................................................... 29
COMENTARIO FINAL.......................................................................................................................... 31
REFERENCIAS........................................................................................................................................ 32
3
ETAPA VI: GESTIÓN DE CALIDAD Y ADMINISTRACIÓN DE
PROYECTOS DE SOFTWARE
OBJETIVOS ESPECÍFICOS
 Analizar el conjunto de cualidades que caracterizan a un software de calidad de acuerdo a
la gestión de un proyecto.
 Gestionar los elementos básicos que se consideran en la administración de proyectos de

software.|
INTRODUCCIÓN
Bienvenidos a la Semana 8 del Curso de Ingeniería de Software, semana en la cual se estudiará
gestión de calidad y administración de proyectos de software.
En esta semana se tratarán temas referentes a la gestión de calidad en proyectos de software,

señalando actividades de la gestión de la calidad de manera de comprender y comprobar el
desarrollo de un software.
Se presentará una visión general de la administración de proyectos de software, explicando

detalladamente cómo medir los costos y tiempos, cómo realizar las calendarizaciones y se
explicará cómo se realiza la selección y organización del personal en un proyecto de software.
4
1. GESTIÓN DE CALIDAD EN PROYECTOS DE SOFTWARE
Los primeros sistemas del software tenían bastantes problemas de calidad, por lo que desde ese
momento empezó a mejorar y evolucionar la ingeniería del software, logrando entregar cada vez
mejores y más eficaces sistemas.
En la gestión de calidad del software existen dos intereses fundamentales (Sommerville, 2012):
 A nivel de organización, la gestión de calidad del software se enfoca en establecer los

procesos y estándares de organización, los cuales ayudan a la obtención de un software de
buena calidad. El equipo encargado de la gestión de calidad es el que determina el
proceso de desarrollo del software que se utilizará, los estándares de calidad con los que
deberá cumplir, el diseño y código de sistema.
 A nivel del proyecto, son establecidos procesos específicos de calidad y por supuesto se
verifica que dichos procesos sean llevados a cabo, se fijan metas para el proyecto en
conjunto con establecer los procesos y estándares que serán utilizados. Por otra parte,
también se encarga de garantizar que los resultados del proyecto cumplan con las
expectativas que fueron establecidas.
Ian Sommerville (óp. cit.) menciona que en la industria manufacturera son utilizados
constantemente los términos aseguramiento de calidad y control de la calidad. El aseguramiento
de calidad es el conjunto de procesos y estándares que conducen a la obtención de productos de
óptima calidad y el control de calidad es la aplicación de los procesos antes mencionados, esto con
el fin de eliminar los productos que no cuentan con la calidad requerida.
Por parte de las distintas compañías y sectores industriales existe una distinta interpretación del
aseguramiento de calidad y el control de calidad. Por ejemplo, en algunos casos el aseguramiento
de calidad se contextualiza solo como los procedimientos, procesos y estándares enfocados en la
obtención de la calidad del software, pero en otros el aseguramiento de calidad también incluye y
se enfoca en las actividades de gestión de configuración, la verificación y validación, las cuales son
aplicadas una vez finalizada la entrega del producto. Cabe destacar que en la industria del
software no es muy utilizado el término “control de calidad” (óp. cit.).
En varias compañías el equipo de aseguramiento de calidad (QA, por las siglas de Quality
Assurance) es el encargado de administrar el proceso de las pruebas de liberación. Esto quiere
decir que las pruebas del software son aplicadas antes de que el producto llegue a los clientes. El
equipo QA es responsable de corroborar que las pruebas hayan cumplido con los estándares
establecidos y realizar registros de las pruebas desarrolladas.
5
1.1. CALIDAD DE PROCESO Y PRODUCTO
Existe una suposición sobre la gestión de calidad, y esta es que la calidad del proceso de desarrollo
influye de forma directa en la calidad de los productos derivados. La suposición antes mencionada
proviene desde los sistemas manufactureros, en los cuales la calidad del producto está bastante
ligada al proceso de producción. Ahora, en los sistemas automatizados de producción, el proceso
conlleva configurar y operar la maquinaria asociada al proceso. Al ser la maquinaria utilizada de
manera óptima y eficiente, la calidad del producto continúa. La calidad es medida a través del
producto y esta se cambia o modifica hasta que se obtiene el nivel de calidad requerido.
En el esquema siguiente se muestra una aproximación basada en el proceso para obtener la

calidad del producto.
Calidad basada en procesos

(Sommerville, 2012, p. 657)
Existe un claro lazo entre la calidad del proceso y la calidad del producto, considerando que el
proceso es bastante sencillo de estandarizar y supervisar.
Los sistemas de producción son calibrados y deben producir reiteradas veces productos de óptima
calidad. Cabe mencionar que el software es diseñado y no manufacturado y el proceso de
desarrollo del software es más creativo que mecánico, en donde la experiencia y habilidades
individuales son de suma importancia.
La calidad del producto se ve afectada por factores externos, como la presión comercial de sacar el
producto rápidamente al mercado o la novedad de una aplicación.
El desarrollo del software posee una compleja relación entre la calidad del proceso y la calidad del
producto. Es bastante difícil determinar los atributos de calidad del software como la
6
mantenibilidad del sistema, incluso después de haber sido utilizado el software por un largo
tiempo, por lo que se vuelve complejo explicar la influencia de las características del proceso en
los atributos. Considerando el papel que cumple el diseño y la creatividad en el proceso software,
no se puede predecir la influencia de los cambios en el proceso y en la calidad del producto.
A pesar de esto, la experiencia ha demostrado que la calidad del proceso influye de forma
significativa en la calidad del software. La gestión y mejora en la calidad del proceso minimiza las
deficiencias en el software entregado.
La gestión de la calidad del proceso incluye (óp. cit.):
 Definir estándares del proceso, como lo son las revisiones a realizar, cuándo realizarlas,
etc.
 La supervisión del proceso de desarrollo del software, para que este siga los estándares
establecidos.
 Realizar informes del proceso para el gestor del proyecto y para el comprador del
software.
Los estándares de calidad para los sistemas críticos necesitan una especificación completa y
aprobada antes de comenzar con la implementación. Aun así, algunos sistemas críticos pueden
requerir de un prototipo, el cual implica implementar sin especificación completa. Pueden surgir
situaciones en las cuales el equipo de gestión de calidad considere que el prototipo no puede ser
llevado a cabo, ya que su calidad no se puede supervisar. En estas situaciones el gestor interviene
con el fin de asegurar que el proceso de calidad ayude al desarrollo del producto y no lo impida.
1.2. GARANTÍA DE CALIDAD Y ESTÁNDARES

Proceso en el que se establece cómo obtener la calidad del software y cómo la organización de
desarrollo comprende el nivel de calidad requerido en el software. Como antes se mencionó, el
proceso QA es utilizado antes de definir o seleccionar los estándares que serán aplicados en el
proceso de desarrollo del software o al producto software. Dentro del proceso QA, pueden ser
seleccionadas herramientas y métodos que complementen estos estándares.
Como parte del proceso de garantía de calidad, se pueden definir dos tipos de estándares (óp.
cit.):
 Estándares de producto: son aplicados en el software que se comienza a desarrollar.

Incorporando estándares de documentación y estándares de codificación, entre otros.
 Estándares de proceso: establecen los procesos que se deben seguir durante el desarrollo
del software. Se pueden integrar definiciones de especificación, diseño y validación, como
también una descripción de los documentos que deben escribirse en el curso de estos
procesos.
7
Hay una relación directa entre los estándares de producto y proceso. Por una parte los estándares
de producto son aplicados en las salidas del proceso software y los estándares de proceso en
varios casos incorporan actividades de proceso específicas que garantizan que se sigan los
estándares de producto.
La importancia de los estándares del software radica en que (óp. cit.):
 Están basados en el óptimo conocimiento de la práctica de la empresa. Por lo general

estos conocimientos son adquiridos después de continuar un proceso de prueba de fallas.
Los estándares captan el conocimiento de valor para la organización.
 Otorgan un marco de trabajo en el cual se lleva a cabo el proceso de garantía de la calidad.
Dado que los estándares captan las mejores prácticas, el control de la calidad se encarga
de que los estándares se sigan de forma correcta.
 Los estándares aseguran que los ingenieros de la organización tengan las mismas
prácticas. Por consiguiente, se minimiza el esfuerzo de aprendizaje, al comenzar un nuevo
trabajo.
Los estándares de proyectos son procesos difíciles y largos. Las organizaciones nacionales e
internacionales como el Departamento de Defensa de Estados Unidos, ANSI, BSI, entre otros, se
encuentran activas en la producción de estándares, los cuales casi siempre son aplicados a una
variedad de proyectos. Organizaciones como la OTAN y otras de defensa exigen que se continúe
con sus propios estándares en los contratos de software.
Han sido desarrollados estándares nacionales e internacionales con el fin de abarcar la

terminología, los lenguajes de programación como Java y C++, las notaciones, los procedimientos
para derivar y redactar requerimientos de software, procedimientos que garanticen la calidad, y
por último procesos de verificación y validación del software.
El equipo que establece los estándares de calidad se apoya en estándares organizacionales

nacionales e internacionales. Tomando estos como comienzo, el equipo de garantía de la calidad
debe proceder a elaborar un manual de estándares, el cual definirá los estándares apropiados
para la organización.
1.3. CONTROL DE CALIDAD

El control de calidad se encarga de supervisar el desarrollo del software, con el fin de asegurar que
se siguieron los procedimientos y estándares de calidad. En este proceso del proyecto se
corrobora que las entregas cumplan con los estándares ya establecidos.
Sommerville (óp. cit.) plantea que existen dos enfoques, utilizados para determinar la calidad de
las entregas de un proyecto:
1. Las revisiones que realizadas por un grupo de personas se enfocan en: la calidad del
software, su documentación y los procesos seguidos durante su desarrollo. La idea de esto
8
es corroborar que los estándares establecidos hayan sido cumplidos. También se toma
nota de cualquier desviación de estándares y se le da a conocer al gestor de proyecto.
2. La valoración automática del software consiste en que el software y los documentos

producidos son procesados por algún programa y comparados con los estándares
aplicados a ese proyecto. Esta valoración automática es una medida cuantitativa de
algunas características del software.
1.4. MEDIACIONES Y MÉTRICAS DEL SOFTWARE

Las revisiones de calidad son costosas y consumen tiempo, por lo que retrasan la entrega del
software. Se podría acelerar el proceso de revisión mediante herramientas que procesen el diseño
del software o programa y realicen una valoración automática de la calidad de este. Las
validaciones permiten establecer si el software cumple con los estándares de calidad establecidos
y destacar las partes que no alcanzan dichos estándares.
La medición del software realiza un valor numérico desde algún atributo del software o del
proceso de software. Creando una comparación entre estos valores y los estándares aplicados en
la organización, se puede sacar una conclusión de la calidad del software o de los procesos para
desarrollarlo. Un ejemplo de lo antes mencionado sería: una organización realiza planes para
incluir una nueva herramienta de prueba de software. Antes de que sea incorporada dicha
herramienta, se debe registrar el número de defectos que han sido detectados en el software en
un tiempo determinado. Luego de introducir las herramientas, se debe repetir este proceso. Ahora
bien, si son detectados los mismos defectos una vez incorporada la nueva herramienta, entonces
se podría decir que otorga información útil para el proceso de validación del software.
Las mediciones del software pueden ser utilizadas para (óp. cit.):
 Hacer predicciones generales acerca del sistema: realizando mediciones de las

características de los componentes del sistema, se puede dar una estimación general de
algunos atributos del sistema, como el número de errores.
 Identificar componentes anómalos: por medio de las mediaciones pueden ser detectados
componentes que salgan de lo normal. Por ejemplo, pueden ser medidos componentes
que identifiquen los de alta complejidad, los que se supone poseen más errores, y así
enfocarse en estos en el proceso de revisión.
Cuando se habla de una métrica de software se hace referencia a todo tipo de medidas que
tengan relación con un sistema, proceso o documentación de software. Algunos ejemplos de esto
son las medidas usadas para calcular el tamaño de un producto en líneas de código; el índice de
9
Fog (Gunning, 1962), que mide la claridad de un párrafo en un texto; el número de errores
detectados en un producto software entregado; y el número de personas/día requeridos para el
desarrollo de un componente del sistema.
Métricas de predicción y de control

Las métricas pueden ser de control o predicción, considerando que ambas pueden influenciar la
toma de decisiones de gestión, como bien se muestra en la figura. Por una parte las métricas de
control están ligadas a los procesos, en cambio las métricas de predicción lo están a los productos.
Por ejemplo, las métricas de control son el esfuerzo y tiempo que se requieren para reparar las
fallas detectadas. Y las métricas de predicción son la complejidad ciclomática de un módulo, la
longitud media de los indicadores de un programa, y el número de atributos y operaciones
asociadas con los objetos de un diseño.
2. ADMINISTRACIÓN DE PROYECTOS DE SOFTWARE

Conlleva un gran costo monetario el crear y conservar un buen equipo de trabajo, con personal
calificado y con experiencia. Siempre dependerá de los administradores del software sacar el
mayor provecho a la inversión que se realiza al conformar estos equipos de trabajo. Las grandes y
exitosas compañías logran lo antes mencionado manteniendo un respeto con el personal de
trabajo y realizando la asignación de trabajo en base a las habilidades y experiencia de cada
persona.
10
Los ingenieros de software, la gran mayoría de las veces, poseen grandes habilidades técnicas,
pero en algunos casos les falta liderazgo para motivar y dirigir a un equipo de desarrollo de
proyectos. Cuando se es administrador de proyecto, se debe tener noción de los potenciales
problemas de administrar personal y por consiguiente se deben desarrollar habilidades de gestión
de recursos humanos.
Existen cuatro puntos críticos en la gestión de personal, los cuales son (óp. cit.):
 Consistencia: los integrantes del equipo deben recibir un trato similar, con esto se intenta
evitar que algún miembro del grupo sienta que sus opiniones y/o ideas se menosprecian.
 Respeto: todos los integrantes del grupo poseen habilidades y capacidades distintas, por
lo que los administradores deben mantener un respeto frente a esto y brindarles la
oportunidad de realizar aportes a todos por igual. Ahora bien, en algunos casos algún
componente del equipo no logra encajar dentro del grupo y no puede continuar en este,
pero siempre es importante tomar este tipo de decisiones con calma y analizando la
situación.
 Inclusión: cuando las personas sienten que sus propuestas e ideas son tomadas en cuenta,
toman un rol más participativo y activo frente al trabajo. Es clave crear un ambiente de
trabajo en el cual sean consideradas todas las opiniones incluyendo las del personal más
joven.
 Honestidad: el administrador debe mantener una honestidad intachable dentro del

equipo. Sobre todo debe ser claro con los conocimientos técnicos que posee, ya que si
intenta encubrir su ignorancia o problemas que surjan cuando las personas se den cuenta
de dichas situaciones perderá el respeto de su equipo.
La gestión del personal debe estar basada en la experiencia adquirida y no solo ser sacada de
libros. La idea de este punto es dar una noción de cómo enfrentar la situación de estar a cargo de
equipos de trabajo bien conformados.
2.1. CONCEPTOS
La administración de proyectos de software es sumamente necesaria dentro de la ingeniería del
software profesional, debido a que esta área se encarga de que se cumpla con fechas de entrega y
adecuación a las restricciones organizacionales de presupuesto. El administrador del proyecto
debe velar por que el software posea una óptima calidad y además cumpla con los objetivos
establecidos. Ahora bien, una buena gestión jamás garantizará el éxito total del proyecto, pero sí
disminuye las probabilidades de fracasar. En cambio, una mala administración por lo general
termina con un proyecto fracasado o con falencias.
11
Por lo general las metas son una parte fundamental de un proyecto y algunas de estas son (óp.
cit.):
 La entrega del software dentro del plazo establecido.

 Ajustarse al presupuesto establecido.
 Que el software cumpla con las expectativas y requerimientos del cliente.
 Que el equipo de trabajo se complemente y cumpla con los objetivos del proyecto.
Si bien las metas antes mencionadas no son las únicas que se utilizan, son en definitiva las metas
que se emplean en todos los proyectos de ingeniería del software.
En los proyectos de ingeniería del software suelen ocurrir algunos retrasos y excesos en el
presupuesto. Considerando que en la mayoría de los casos los sistemas del software son
técnicamente nuevos e innovadores. Los proyectos de ingeniería que son reformadores, por lo
general, presentan retrasos en la entrega.
Es prácticamente imposible crear una descripción laboral estándar para un administrador de

proyecto. La labor depende directamente de la función de la organización y el software que se va a
desarrollar. Sommerville (óp. cit.) plantea sin embargo que los administradores del software
asumen la responsabilidad de algunas o todas las actividades que se mencionan:
 Planeación del proyecto: el administrador de proyecto debe hacerse cargo de planear,

calendarizar y monitorear el desarrollo del proyecto de modo que este se desarrolle en el
tiempo estimado. El administrador también debe asignar las tareas al personal y por
supuesto supervisar el trabajo que se realiza, todo esto con el fin de que este cumpla con
los estándares establecidos.
 Informes: por lo general, los administradores del proyecto deben realizar informes que
describan los avances del proyecto de software a los clientes y administradores de la
compañía para la cual están trabajando. Los informes deben ser documentos claros y
detallados, los cuales deben ser presentados después de cada revisión de avance.
 Gestión del riesgo: se debe hacer un análisis de los posibles riesgos que puedan afectar al
proyecto, monitoreando dichos riesgos, y actuar cuando las fallas surjan.
 Gestión de personal: el administrador de proyecto debe elegir a las personas que
conformarán su grupo de trabajo, organizando y guiando al equipo de modo que su
desempeño sea el más favorable posible.
 Redactar propuestas: por lo general, para la obtención de un contrato se debe realizar
una propuesta de proyecto, la cual debe describir las metas del proyecto, cómo este se
realizará, los costos aproximados y por supuesto una calendarización. Cabe mencionar que
esta es una tarea fundamental para las compañías de software, debido a que es necesario
que la empresa cuente con la mayor cantidad de proyectos aprobados y concesiones de
contratos, para la subsistencia de la empresa.
12
2.2. COSTOS Y TIEMPO EN PROYECTOS DE DESARROLLO DE
SOFTWARE
Mediante estudios se ha determinado que el mantenimiento del software ocupa una gran parte
del presupuesto de TI. También se estableció que una buena parte del presupuesto es destinado a
la implementación de nuevos requerimientos, y no a la reparación de bugs.
Distribución del esfuerzo de mantenimiento

El gráfico Distribución del esfuerzo de mantenimiento muestra una aproximación de los costos de
mantenimiento. Este tipo de gráficos varía dependiendo de la organización. La reparación de fallas
del desarrollo del sistema no es la actividad de mantenimiento más cara, sino más bien el
actualizar el sistema para que logre enfrentarse a nuevos o cambiantes entornos y
requerimientos, lo que suele requerir más esfuerzos del área de mantenimiento.
Los costos aproximados de mantenimiento y del nuevo desarrollo dependerán del dominio de
aplicación.
Los costos de mantención de sistemas de aplicación empresarial son comparables con los costos
de desarrollo de sistema. Las necesidades de fiabilidad y rendimiento de los sistemas antes
mencionados establecen que los módulos deben estar estrechamente ligados, lo cual los vuelve
difíciles de cambiar. Considerando que estas estimaciones tienen aproximadamente 25 años de
13
antigüedad, resulta prácticamente imposible que las distribuciones de costos para los distintos
tipos de sistemas hayan variado de manera significativa.
En general, suele ser más conveniente en costos invertir esfuerzo en diseño e implementación del
sistema, con el fin de reducir costos en cambios futuros. Cuando es agregada una nueva
funcionalidad posterior a la entrega, esta se vuelve costosa, debido a que consume tiempo para
aprender y comprender el funcionamiento del sistema y el análisis del impacto en los cambios de
presupuesto.
Es posible que el trabajo que se realiza en el desarrollo del software sea fácil de entender y
cambiar, lo cual reduce los costos de evolución. Las óptimas técnicas de ingeniería del software,
como lo son las especificaciones precisas, el uso de desarrollo orientado a objetos y la
administración de la configuración ayudan a reducir costos de mantención.
Cocomo (COnstructive COst MOdel) es un modelo matemático utilizado para estimación de costos
de software. Utiliza una familia de modelos algorítmicos de estimación de costos. Cocomo se
planteó iniciados los años 80 y a medida que pasan los años este modelo se va modificando y
actualizando de manera de mostrar de mejor forma las nuevas tecnologías y las cambiantes
prácticas en la ingeniería de software.
Con el tiempo se han ido planteando similares modelos de manera de contribuir a estimar el
esfuerzo, el calendario y los costos de un proyecto de software, tales como Cocomo II, que es un
modelo muy práctico que provino de compilar datos de un gran número de proyectos de software,
donde los datos compilados se estudiaron, descubriendo las fórmulas que mejor convenían a las
observaciones realizadas, las que se relacionan con el tamaño del sistema y los factores del
producto, proyecto y equipo, y con el esfuerzo para desarrollar el sistema.
Cocomo II es un modelo de estimación bien documentado y no registrado, este modelo se fija en

considerar las direcciones modernas para el desarrollo de software.
El modelo espiral de desarrollo es el modelo que mejor sobrelleva a Cocomo II e incrusta sub-
modelos que producen estimaciones cada vez más detalladas, tales como:
14
Modelos de estimación Cocomo
 Un modelo de composición de aplicación: este modela el esfuerzo requerido para

desarrollar sistemas que se crean a partir de componentes de reutilización, escritura de
guiones o programación de base de datos. Las estimaciones del tamaño de software se
basan en puntos de aplicación ponderados (en ocasiones llamados puntos de objeto), y
para estimar el esfuerzo requerido se usa una simple fórmula tamaño/productividad. El
número de puntos de aplicación en un programa es una estimación ponderada del
número de pantallas separadas que se despliegan, el número de informes que se
producen, el número de módulos en lenguajes de programación imperativa (como Java) y
el número de líneas de lenguaje de escritura de guiones (scripting) o código de
programación de base de datos.
La figura muestra los niveles de productividad de punto de aplicación.
15
Productividad de punto de aplicación
Fórmula para calcular el esfuerzo del prototipo de sistema es:
PM = (NAP * (1 - % reutilización /100)) / PROD
 PM: es la estimación del esfuerzo en meses-hombre.

 NAP: es el número de puntos de aplicación en el sistema entregado.
 % reutilización: es una estimación de la cantidad de código de reutilización en el
desarrollo.
 PROD: es la productividad del punto de aplicación.
El modelo produce una estimación aproximada, pues no toma en cuenta el esfuerzo adicional
incluido en la reutilización.
 Un modelo de diseño temprano: este modelo se usa durante etapas tempranas del diseño
del sistema después de establecer los requerimientos.
La estimación se basa en la fórmula de estimación estándar, con un conjunto simplificado
de siete multiplicadores. Las estimaciones se basan en puntos de función, que luego se
convierten a número de líneas de código fuente.
Los puntos de función son una forma independiente de lenguaje para cuantificar la
funcionalidad del programa. El número total de puntos de función en un programa se
calcula al medir o estimar el número de entradas y salidas externas, las interacciones de
usuario, las interfaces externas y las tablas de archivos o bases de datos que usa el
sistema.
Esfuerzo (PM) = A * 𝒕𝒂𝒎𝒂ñ𝒐𝑩 * M
16
 Coeficiente A: se propuso que el coeficiente A debe ser 2,94.
 El tamaño: se expresa en KSLOC (número de miles de líneas de código fuente). Las

KSLOC se calculan al estimar el número de puntos de función en el software.
Entonces se usan tablas estándar que relacionan el tamaño del software con
puntos de función para diferentes lenguajes de programación, con la finalidad de
hacer una estimación inicial del tamaño del sistema en KSLOC.
 El exponente B: refleja el esfuerzo creciente requerido conforme aumenta el

tamaño del proyecto. Esto puede variar de 1,1 a 1,24, dependiendo de la novedad
del proyecto, flexibilidad del desarrollo, procesos de resolución de riesgos
utilizados, cohesión del equipo de desarrollo y nivel de madurez del proceso de la
organización. En la descripción del modelo posarquitectónico Cocomo II se estudia
cómo calcular el valor de este exponente usando dichos parámetros.
PM = 2,94 * 𝒕𝒂𝒎𝒂ñ𝒐(𝟏,𝟏 − 𝟏,𝟐𝟒) * M
 El multiplicador M: se basa en siete atributos de proyecto y proceso que

aumentan o disminuyen la estimación. Los atributos que se usan en el modelo de
diseño temprano son fiabilidad y complejidad del producto.
M = PERS * RCPX * RUSE * PDIF * PREX * FCIL * SCED
 PERS: habilidad personal.

 RCPX: Los atributos que se usan en el modelo de diseño temprano son fiabilidad
y complejidad del producto.
 RUSE: reutilización requerida.
 PDIF: dificultad de plataforma.
 PREX: experiencia personal.
 FCIL: facilidades de soporte.
 SCED: calendario.
Los valores para dichos atributos se estiman mediante una escala de seis puntos, donde 1
corresponde a “muy bajo” y 6 corresponde a “muy alto”.
 Un modelo de reutilización: este modelo se emplea para calcular el esfuerzo requerido al

integrar los componentes de reutilización y/o código de programa generado
automáticamente. Muchas veces se utiliza en conjunto con el modelo posarquitectónico.
El modelo de reutilización se emplea para estimar el esfuerzo requerido al integrar código
de reutilización o generado. Cocomo II considera dos tipos de código de reutilización:
17
 El código “caja negra” es un código que puede reutilizarse sin comprender el
código o hacerle cambios. Se considera que el esfuerzo de desarrollo para el
código caja negra es cero.
 El código “caja blanca” tiene que adaptarse para integrarlo en un código nuevo u
otros componentes de reutilización. Para la reutilización se requiere esfuerzo de
desarrollo, pues el código tiene que entenderse y modificarse antes de que pueda
trabajar correctamente en el sistema.
El modelo de reutilización Cocomo II incluye una fórmula para estimar el esfuerzo requerido al
integrar este código generado:
(𝑨𝑺𝑳𝑶𝑪 ∗ 𝑨𝑻 / 𝟏𝟎𝟎)
𝑷𝑴𝒂𝒖𝒕𝒐 = 𝐀𝐓𝐏𝐑𝐎𝐃
 PM: estimación para código generado

 ASLOC: número total de líneas de código de reutilización, incluido el código que se
genera automáticamente.
 AT: porcentaje de código de reutilización que se genera automáticamente.
 ATPROD: productividad de los ingenieros para integrar tal código, que está
medido en aprox. 2.400 enunciados fuente por mes.
Por ejemplo, si existe un total de 20.000 líneas de código fuente de reutilización en un sistema y el
30% de este se genera automáticamente, entonces el esfuerzo que se requiere para integrar el
código generado es:
(𝟐𝟎.𝟎𝟎𝟎 ∗ 𝟑𝟎/ 𝟏𝟎𝟎)

𝑷𝑴𝒂𝒖𝒕𝒐 = 𝟐.𝟒𝟎𝟎
𝑷𝑴𝒂𝒖𝒕𝒐 = 2,5 meses- hombre
Para estimar el esfuerzo requerido al integrar el código de reutilización de otros sistemas se realiza
un cálculo de esfuerzo separado.
El modelo de reutilización no calcula directamente el esfuerzo a partir de una estimación del

número de componentes de reutilización. En vez de ello, con base en el número de líneas de
código que se reutilizan, el modelo ofrece una base para calcular el número equivalente de líneas
de código nuevo (ESLOC). Este se basa en el número de líneas de código de reutilización que
deben cambiarse y un multiplicador que refleja la cantidad de trabajo que es necesario hacer para
reutilizar los componentes. La fórmula que calcula ESLOC toma en cuenta el esfuerzo requerido
para comprender el software, hacer cambios al código de reutilización y al sistema para integrar
dicho código.
18
La siguiente fórmula se usa para calcular el número de líneas equivalentes de código fuente:
ESLOC = ASLOC * AAM
 ESLOC: número equivalente de líneas de nuevo código fuente.
 ASLOC: número de líneas de código en los componentes que deben cambiarse.
 AAM: multiplicador de ajuste de adaptación. Ajusta la estimación para reflejar el

esfuerzo adicional requerido para reutilizar el código. De manera simplista, AAM
es la suma de tres componentes:
 Un componente de adaptación (conocido como AAF) que

representa los costos de hacer cambios al código de
reutilización. El componente de adaptación incluye
subcomponentes que toman en cuenta cambios al diseño,
código e integración.
 Un componente de comprensión (conocido como SU) que

representa los costos para comprender el código a
reutilizar y la familiaridad del ingeniero con el código.
SU varía de 50 para código complejo no estructurado a 10
para código orientado a objetos bien escrito.
 Un factor de valoración (conocido como AA) que

representa los costos de tomar la decisión de reutilizar.
Esto es, siempre se requiere algún análisis para decidir si el
código puede reutilizarse o no, y esto se incluye en el costo
como AA.
El factor AA varía de 0 a 8, dependiendo de la cantidad de
esfuerzo de análisis requerido.
Si alguna adaptación del código puede hacerse automáticamente, esto reduce el esfuerzo
requerido. Por lo tanto, la estimación se ajusta al evaluar el porcentaje de código adaptado
automáticamente (AT) y usar esto para ajustar ASLOC.
ESLOC = ASLOC * (1 - AT/100) * AAM
Una vez calculado ESLOC, se aplica la fórmula de estimación estándar para calcular el esfuerzo
total requerido, en que el parámetro Tamaño = ESLOC. Entonces se suma esto al esfuerzo para
19
integrar el código generado automáticamente ya calculado, lo que permite calcular el esfuerzo
total requerido.
 Un modelo posarquitectónico: una vez diseñada la arquitectura del sistema, puede

hacerse una estimación más precisa del tamaño del software. Nuevamente, este modelo
usa la fórmula estándar para estimación de costo discutida líneas arriba. Sin embargo,
incluye un conjunto más extenso de 17 multiplicadores que reflejan características de
capacidad personal, del producto y del proyecto.
El punto de partida para las estimaciones producidas en el nivel posarquitectónico es la misma

fórmula básica usada en las estimaciones de diseño temprano:
PM = A * 𝒕𝒂𝒎𝒂ñ𝒐𝑩 * M
Para esta etapa del proceso, hay que hacer una estimación más precisa del tamaño del proyecto
conforme se conoce cómo se dividirá el sistema en objetos o módulos.
Estas estimaciones del tamaño del código se hacen mediante tres parámetros:
 Una estimación del número total de líneas de código nuevo a desarrollar (SLOC).
 Una estimación de los costos de reutilización, con base en un número equivalente

de líneas de código fuente (ESLOC), calculadas mediante el modelo de
reutilización.
 Una estimación del número de líneas de código que es probable se modifiquen

debido a cambios a los requerimientos del sistema.
Los valores de estos parámetros se suman para calcular el tamaño de código total (en KSLOC) que
se emplea en la fórmula de cálculo de esfuerzo.
El componente final en la estimación, el número de líneas de código modificado, refleja el hecho

de que los requerimientos de software siempre cambian.
Esto conduce a la reelaboración y el desarrollo de código adicional, lo que debe tomarse en

cuenta. Desde luego, con frecuencia habrá incluso más incertidumbre en esta cifra que en las
estimaciones de código nuevo a desarrollar.
El término exponente (B) en la fórmula de cálculo de esfuerzo se relaciona con los niveles de
complejidad del proyecto. Conforme los proyectos se hacen más complejos, los efectos de
aumentar el tamaño del sistema se hacen más significativos.
Sin embargo, las prácticas y los procedimientos organizacionales adecuados pueden controlar la
deseconomía de escala que surge como consecuencia de aumentar la complejidad.
20
Por lo tanto, el valor del exponente B se basa en cinco factores, como se describe en el
siguiente recuadro:
Factores de escala empleados en el cálculo de exponente en el modelo posarquitectónico

Dichos factores se clasifican en una escala de seis puntos, de 0 a 5, donde 0 significa “extra alto” y
5 significa “muy bajo”.
Para calcular B, se suman las clasificaciones, se dividen entre 100 y los resultados se suman a 1,01.
Por ejemplo, imagine que una organización acepta un proyecto en un dominio en el que tiene
poca experiencia. El cliente del proyecto no tiene definido el proceso a usar ni ha asignado tiempo
en el calendario del proyecto para el análisis del riesgo significativo. Un nuevo equipo de
desarrollo debe reunirse para implementar este sistema. La organización dispuso recientemente
un programa de mejoramiento de procesos y se clasificó como una organización de nivel 2 de
acuerdo con la valoración de capacidad SEI.
Por consiguiente, los posibles valores para las clasificaciones empleadas en el cálculo del
exponente son:
 1.- Precedencia clasificada baja (4): este es un proyecto nuevo para la organización.
 2.- Flexibilidad de desarrollo clasificada muy alta (1): no hay involucramiento del
cliente en el proceso de desarrollo, de manera que hay pocos cambios impuestos
desde el exterior.
21
 3.- Resolución de arquitectura/riesgo clasificada muy baja (5): no se ha realizado el
análisis de riesgos.
 4.- Cohesión del equipo clasificada nominal (3): este es un equipo nuevo, así que no
hay información disponible acerca de la cohesión.
 5.- Madurez del proceso clasificada nominal (3): existe cierto control del proceso.
- La suma de 1+2+3+4+5 = (16)
16
- B = (100 + 0,01 ) + 1 (valor nominal) = 1,17
La estimación del esfuerzo global se perfecciona usando un conjunto extenso de 17 atributos

(controladores de costos) del producto, el proceso y la organización, en lugar de los siete atributos
usados en el modelo de diseño temprano.
Usted puede estimar los valores de estos atributos porque tiene más información acerca del
software en sí, sus requerimientos no funcionales, el equipo de desarrollo y el proceso de
desarrollo.
La figura muestra cómo los atributos del controlador de costos pueden influir en las estimaciones
del esfuerzo.
En este libro se tomó un valor de 1,17 para el exponente, como se discutió en el ejemplo anterior,
y se supone que RELY, CPLX, STOR, TOOL y SCED son los controladores de costos clave en el
proyecto.
Todos los otros controladores de costos tienen un valor nominal de 1, de modo que no afectan el
cálculo del esfuerzo.
22
Efecto de los controladores de costos sobre las estimaciones del esfuerzo
Nota: signo que separa los decimales debe ser coma. Sommerville utiliza el punto, como es propio de la tradición anglosajona.
En la figura se asignaron valores máximos y mínimos a los controladores de costos clave para
mostrar cómo influye la estimación del esfuerzo.
Los valores tomados son los del manual de referencia Cocomo II.
Como se observa, valores altos para los controladores de costos conducen a una estimación del
esfuerzo que es más de tres veces la estimación inicial, mientras que los valores bajos reducen la
estimación a aproximadamente un tercio del original.
Esto destaca las diferencias significativas entre distintos tipos de proyectos y las dificultades de
transferir la experiencia de un dominio de aplicación a otro.
23
2.3. CALENDARIZACIÓN DE PROYECTOS
En este proceso son establecidos los plazos en los que deben ser entregadas las etapas del
proyecto y en los que es organizado el trabajo. Dentro de la calendarización del proyecto, también
son considerados los recursos necesarios para completar cada tarea, el tiempo que necesita el
hardware especializado, el espacio de disco que necesitará el servidor, etc. La etapa de
calendarización del proyecto es realizada, por lo general, en la fase de arranque del proyecto, sin
perjuicio de que esta sufra algunas modificaciones en la planeación.
El calendario inicial es utilizado para planear la asignación de personal al proyecto y llevar un

control sobre los avance de este, recordar que el proyecto debe cumplir con la fecha de entrega
establecida en un principio. En los proyectos tradicionales, el calendario es establecido desde un
principio y puede sufrir modificaciones a medida que avanza el proyecto. Por otra parte, en los
proyectos ágiles se establece un calendario global, el cual establece los tiempos en que se
completarán las etapas principales del proyecto.
El proceso de calendarización del proyecto

En la calendarización de un proyecto es creado un plan, el cual realiza una división del trabajo total
en etapas, una vez hecho esto se realiza una estimación del tiempo requerido para cada etapa. En
general las tareas duran por lo menos una semana, pero deben durar menos de dos meses. Cada
tarea no puede durar más de 10 semanas, si requiere más tiempo se deberá realizar una
subdivisión de la tarea para la planeación y calendarización.
Hay tareas que son realizadas en paralelo con personas que trabajan en otros componentes del
sistema, dichas tareas deben ser realizadas de manera organizada. Es de suma importancia evitar
que el proyecto se retrase por una tarea crítica no terminada.
Ahora bien, los calendarios de proyecto pueden ser expuestos mediante hojas de cálculo o tablas,
de forma tal que se muestre la duración del proyecto, las tareas a realizar, etc. Cabe mencionar
que en la actualidad tenemos las representaciones gráficas alternativas, las cuales permiten la
comprensión de la calendarización de manera sencilla y óptima.
Los dos tipos de representación generalmente utilizados son:
24
 Gráficos de barras: estos se respaldan por el calendario y nos muestran el encargado de
cada actividad, el periodo transcurrido y la fecha establecida para el comienzo y término
de cada actividad. Los gráficos de barras fueron creadas por Henry Gantt, es por esta
razón que también se les puede llamar gráficas de Gantt.
 Redes de actividad: son diagramas de red que muestran las dependencias entre las
diversas tareas que conforman un proyecto.
Las herramientas de planeación son utilizadas para administrar la información del calendario del
proyecto, de forma tal que al obtener la información de la tabla desarrollan una base de datos con
la información del proyecto. Basados en la base de datos se crean de forma automática los
gráficos de barras y de actividad.
Las actividades de proyecto son el elemento de planeación básico. Cada actividad cuenta con:
 Una duración en días o meses-calendario.

 Una estimación del esfuerzo, la cual refleja el número de días-hombre o meses-hombre
para completar el trabajo.
 Un plazo dentro del cual debe completarse la actividad.
 Un punto final definido. Este representa el resultado tangible de completar la actividad.
También podría ser un documento, la realización de una junta de revisión, una ejecución
exitosa de todas las pruebas, etcétera.
Al realizar una planeación de un proyecto se deberán establecer hitos, los cuales deben
documentarse a través de breves informes que señalen el avance y el trabajo realizado. Los hitos
se pueden relacionar con una tarea o con un conjunto de actividades. Por ejemplo, la figura del
hito M1 se asocia con la tarea T1, mientras que el hito M3 se asocia con un par de tareas, T2 y T4.
Un entregable de proyecto es un tipo especial de hito, el cual consiste en un producto del trabajo
que es presentado al cliente. En otras palabras, este hito es una parte relevante del proyecto,
tanto como la especificación o el diseño. Comúnmente los entregables son determinados en el
contrato, y es gracias a estos que el cliente puede ir visualizando el avance del proyecto.
A modo de exponer el uso de los gráficos de barras se desarrolló un conjunto hipotético de tareas,
que se presentan en el siguiente recuadro:
25
Tareas, duraciones y dependencias
Esta tabla indica tareas, esfuerzo estimado, duración e interdependencias de tareas. En la figura se
observa que la tarea T3 depende de la tarea T1. Por lo tanto, la tarea T1 debe completarse antes
de comenzar la tarea T3.
Por ejemplo, T1 puede ser la preparación del diseño de un componente y T3 la implementación de

ese diseño. Antes de comenzar la implementación, debe completarse el diseño. Observe que la
duración estimada para algunas tareas es mayor que el esfuerzo requerido y viceversa.
Si el esfuerzo es menor que la duración, significa que las personas asignadas a dicha tarea no
trabajan en ella de tiempo completo. Si el esfuerzo supera la duración, quiere decir que muchos
miembros del equipo trabajan al mismo tiempo en la tarea.
26
Gráfica de barras de actividad
La figura aquí mostrada se basa en la información de la figura anterior y presenta el calendario del
proyecto en formato gráfico. Es una gráfica de barras que muestra un calendario de proyecto y las
fechas de inicio y término de las actividades. Al leerse de izquierda a derecha, el gráfico de barras
señala claramente cuándo comienzan y terminan las tareas. Los hitos (M1, M2, etcétera) se
muestran también en el gráfico de barras. Observe que las tareas que son independientes se
realizan paralelamente (por ejemplo, las tareas T1, T2 y T4 se inician desde el principio del
proyecto).
2.4. SELECCIÓN DE PERSONAL

La selección del personal que trabajará en un proyecto es una de las tareas más importantes que
realiza el gestor. En algunos casos el administrador del proyecto es el que decide qué personas
conformarán su equipo de trabajo, aunque en la mayoría de los casos no sea así. Debido a que se
reclutan personas que se encuentren disponibles en la organización, también el personal de
27
trabajo es reclutado con rapidez y muchas veces se tiene un presupuesto limitado, lo cual dificulta
contratar ingenieros con grandes habilidades y experiencia.
Se utilizan tres tipos de información para la designación de personal a un proyecto (óp. cit.):
 La información que se obtuvo de los candidatos acerca de sus habilidades, conocimientos

y experiencia. Claro está que se toma en cuenta el currículum vitae para esto.
 La información recolectada en la entrevista de trabajo nos otorgará una visión acerca de

las habilidades comunicacionales y sociales del candidato. Cabe mencionar que las
entrevistas no son un método del todo confiable para determinar las capacidades técnicas
del entrevistado, debido a que los entrevistadores realizan juicios rápidos y subjetivos.
 Serán consideradas las recomendaciones que tenga el candidato, siempre y cuando se

conozca a la persona que realizó las recomendaciones, de otra forma estas puedes ser
falsas.
Se pueden encontrar los siguientes elementos en la evaluación del personal:
 En algunas ocasiones las personas que poseen las habilidades que se requieren para el
proyecto ya trabajan en otros proyectos y el gestor de este puede no querer perder a
dichos trabajadores, por lo que algunas veces deberemos aceptar que estas personas
trabajen de forma parcial en nuestro proyecto.
 Por lo general, existen pocos candidatos con habilidades determinadas como el diseño de
interfaz de usuario e interfaz hardware.
 Los recién titulados poseen energía, entusiasmo y probablemente cercanía con la

tecnología más actual, pero pueden no tener las habilidades que usted necesita.
 No siempre se debe contratar a quien tenga más conocimiento técnico para un trabajo de
desarrollo técnico.
Los factores relevantes varían por el dominio de la aplicación, el tipo de proyecto y las habilidades
que poseen los miembros del equipo.
La dificultad con la que se pueden encontrar los gestores de proyecto es a menudo reclutar
personas que posean los conocimientos, habilidades y experiencia necesaria para el desarrollo del
proyecto. Algunas veces se forman grupos de trabajo con ingenieros inexperimentados, lo cual
puede conllevar problemas como el no entendimiento de la aplicación o tecnología por parte de
los miembros del equipo.
28
En los proyectos de larga duración, la comprensión de conceptos y el dominio de la aplicación son
fundamentales. Considerando esto podemos determinar que, a menos que se requieran
conocimientos específicos en un lenguaje de programación para un proyecto de corta duración, lo
óptimo será elegir a personas con capacidad de resolver problemas o con dominio de la aplicación.
Es un poco más fácil entender un nuevo lenguaje, pero es difícil desarrollar conocimientos
conceptuales necesarios para la resolución de problemas complejos.
En algunas empresas o compañías, son realizadas pruebas a los candidatos, las que suelen
consistir en: pruebas de aptitud en relación a la programación y pruebas psicotécnicas, en las
cuales los aspirantes deben completar una serie de ejercicios en un periodo de tiempo
relativamente corto. Las pruebas psicotécnicas se enfocan en obtener un perfil psicológico del
candidato, señalando cuáles son sus capacidades y habilidades para determinadas tareas.
La carencia de personal técnico suele ser debido a que en algunas organizaciones las personas que
poseen habilidades técnicas rápidamente logran metas en sus carreras. En algunos casos para
conseguir avanzar deben tomar responsabilidades de carácter administrativo. Cuando sucede el
ascenso de estas personas, se pierde el ejercicio de sus habilidades técnicas. Ahora bien, con el fin
de evitar estas pérdidas, en algunas compañías se implementaron las estructuras paralelas de
carreras técnicas y administrativas de igual valor, es decir, las personas con experiencia técnica son
consideradas al mismo nivel que los administradores. Por ejemplo, si un ingeniero desea
desarrollar su carrera, este puede especializarse en actividades técnicas o de gestión sin ver
afectado su estatus o sueldo.
2.5. ORGANIZACIÓN DEL PERSONAL

Se considera fundamental la forma en que se organiza un grupo de trabajo en torno a la toma de
decisiones de dicho grupo. También es importante la forma en la que se intercambia información y
las interacciones que tenga el grupo de trabajo con los participantes externos del proyecto.
Suele suceder en los grupos pequeños de programación que se organizan de manera informal;
tanto el líder del grupo como los demás integrantes participan en el desarrollo del software, todos
los miembros del equipo pueden analizar el trabajo que se realizará y por supuesto las tareas que
serán asignadas a cada miembro del equipo. Ahora bien, claro está que para la asignación de
trabajo se considera la habilidad y experiencia de cada integrante. Los miembros del grupo con
mayor jerarquía casi siempre se encargan del diseño arquitectónico.
Los grupos de trabajo de programación extrema son informales. Los de XP consideran que el
mantener grupos formales inhibe el intercambio fluido de información. Por lo tanto, XP determinó
que muchas de las decisiones que generalmente son tomadas por el área administrativa sean
tomadas por miembros del grupo. También los programadores trabajan a la par en los diseños de
códigos, por lo que la responsabilidad por los programas que desarrollan se asume en conjunto.
29
Sommerville (óp. cit.) menciona que, por lo general, los grupos informales suelen ser exitosos,
sobre todo cuando la mayoría de los miembros del grupo posee experiencia y habilidades. En este
tipo de grupos, las decisiones son tomadas de manera democrática, lo cual crea compromiso y
eleva el rendimiento.
Ahora bien, si un grupo informal se encuentra conformado por personas que no poseen la
experiencia ni competencias necesarias, la informalidad se volverá una desventaja debido a que en
este tipo de grupos no hay una autoridad definida que oriente la organización del trabajo, lo que
puede llevar a errores, desorganización y por supuesto a una posible falla del proyecto.
Por otra parte, en los grupos jerárquicos el líder del grupo se encuentra en la parte superior de
esta jerarquía, es decir, el líder tiene la autoridad para dirigir el trabajo, el desarrollo del proyecto
y tomar las decisiones que influirán directamente en el resto del equipo. En otras palabras, en este
tipo de grupos existe una estructura organizacional, hay poca comunicación entre los niveles más
altos de la jerarquía y los niveles más bajos (óp. cit.).
Tanto los grupos democráticos como los jerárquicos no reconocen de manera formal las
diferencias de habilidades que existen entre los miembros del equipo. Lo óptimo es sacar el mayor
provecho de las capacidades que poseen los miembros con más habilidades y experiencia del
equipo, otorgándoles todo el apoyo y respaldo posible. Dentro de los primeros modelos
organizacionales que deseaban otorgar apoyo se encuentra el denominado equipo programador
jefe.
30
COMENTARIO FINAL
Se puede concluir que la herramienta fundamental para la entrega del proyecto de software es la
gestión de calidad, que es donde se establecen y supervisan los estándares de calidad para el
software en desarrollo.
La importancia que tiene la administración de proyectos de software permite evaluar los costos y
tiempos necesarios para el desarrollo de un software, además de indicar cómo se debería realizar
la selección y organización del personal.
Los conocimientos y herramientas entregadas durante esta semana, en conjunto con lo estudiado
y aprendido durante las semanas anteriores, ayudan a comprender de mejor manera cómo
realizar y desarrollar un proyecto de software.
31
REFERENCIAS
Aparicio, C. (2012). El modelo COCOMO para estimar costes en un proyecto de software.
Consultado el 20 de junio de 2015 en: http://goo.gl/7AFRbq.
Sommerville, I. (2012). Ingeniería de Software. 9.ª edición. México: Pearson.
Pressman, R. (2005). Ingeniería de Software. 6.ª edición. México: MacGraw-Hill Interamericana.
Whitten, J. & Bentley, L. (2008). Análisis de Sistemas. 7.ª edición. México: MacGraw-Hill
Interamericana.
PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:
IACC (2015). Etapa VI: gestión de calidad y administración de proyectos de software. Ingeniería de
Software. Semana 8.
32
33

08 Ingenieria de Software 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

08 Ingenieria de Software PDF

Cargado por

Copyright:

Formatos disponibles

INGENIERÍA DE SOFTWARE

ETAPA VI: GESTIÓN DE CALIDAD Y ADMINISTRACIÓN DE PROYECTOS DE SOFTWARE ...................... 4

 Gestionar los elementos básicos que se consideran en la administración de proyectos de

En esta semana se tratarán temas referentes a la gestión de calidad en proyectos de software,

Se presentará una visión general de la administración de proyectos de software, explicando

 A nivel de organización, la gestión de calidad del software se enfoca en establecer los

En el esquema siguiente se muestra una aproximación basada en el proceso para obtener la

Calidad basada en procesos

La gestión de la calidad del proceso incluye (óp. cit.):

1.2. GARANTÍA DE CALIDAD Y ESTÁNDARES

 Estándares de producto: son aplicados en el software que se comienza a desarrollar.

La importancia de los estándares del software radica en que (óp. cit.):

 Están basados en el óptimo conocimiento de la práctica de la empresa. Por lo general

Han sido desarrollados estándares nacionales e internacionales con el fin de abarcar la

El equipo que establece los estándares de calidad se apoya en estándares organizacionales

1.3. CONTROL DE CALIDAD

2. La valoración automática del software consiste en que el software y los documentos

1.4. MEDIACIONES Y MÉTRICAS DEL SOFTWARE

 Hacer predicciones generales acerca del sistema: realizando mediciones de las

Métricas de predicción y de control

2. ADMINISTRACIÓN DE PROYECTOS DE SOFTWARE

 Honestidad: el administrador debe mantener una honestidad intachable dentro del

 La entrega del software dentro del plazo establecido.

Es prácticamente imposible crear una descripción laboral estándar para un administrador de

 Planeación del proyecto: el administrador de proyecto debe hacerse cargo de planear,

Distribución del esfuerzo de mantenimiento

Cocomo II es un modelo de estimación bien documentado y no registrado, este modelo se fija en

 Un modelo de composición de aplicación: este modela el esfuerzo requerido para

La figura muestra los niveles de productividad de punto de aplicación.

Fórmula para calcular el esfuerzo del prototipo de sistema es:

PM = (NAP * (1 - % reutilización /100)) / PROD

 PM: es la estimación del esfuerzo en meses-hombre.

Esfuerzo (PM) = A * 𝒕𝒂𝒎𝒂ñ𝒐𝑩 * M

 El tamaño: se expresa en KSLOC (número de miles de líneas de código fuente). Las

 El exponente B: refleja el esfuerzo creciente requerido conforme aumenta el

PM = 2,94 * 𝒕𝒂𝒎𝒂ñ𝒐(𝟏,𝟏 − 𝟏,𝟐𝟒) * M

 El multiplicador M: se basa en siete atributos de proyecto y proceso que

M = PERS * RCPX * RUSE * PDIF * PREX * FCIL * SCED

 PERS: habilidad personal.

 Un modelo de reutilización: este modelo se emplea para calcular el esfuerzo requerido al

 PM: estimación para código generado

(𝟐𝟎.𝟎𝟎𝟎 ∗ 𝟑𝟎/ 𝟏𝟎𝟎)

𝑷𝑴𝒂𝒖𝒕𝒐 = 2,5 meses- hombre

El modelo de reutilización no calcula directamente el esfuerzo a partir de una estimación del

ESLOC = ASLOC * AAM

 ESLOC: número equivalente de líneas de nuevo código fuente.

 ASLOC: número de líneas de código en los componentes que deben cambiarse.

 AAM: multiplicador de ajuste de adaptación. Ajusta la estimación para reflejar el

 Un componente de adaptación (conocido como AAF) que

 Un componente de comprensión (conocido como SU) que

 Un factor de valoración (conocido como AA) que

ESLOC = ASLOC * (1 - AT/100) * AAM

 Un modelo posarquitectónico: una vez diseñada la arquitectura del sistema, puede

El punto de partida para las estimaciones producidas en el nivel posarquitectónico es la misma

 Una estimación de los costos de reutilización, con base en un número equivalente

 Una estimación del número de líneas de código que es probable se modifiquen

El componente final en la estimación, el número de líneas de código modificado, refleja el hecho

Esto conduce a la reelaboración y el desarrollo de código adicional, lo que debe tomarse en

Factores de escala empleados en el cálculo de exponente en el modelo posarquitectónico

- La suma de 1+2+3+4+5 = (16)

La estimación del esfuerzo global se perfecciona usando un conjunto extenso de 17 atributos

El calendario inicial es utilizado para planear la asignación de personal al proyecto y llevar un

El proceso de calendarización del proyecto