UNIVERSIDAD AUTONOMA DE SINALOA

UNIDAD ACADEMICA FACULTAD DE INFORMATICA

CULIACAN

MATERIA

MODELOS DE CALIDAD DE SOFTWARE

DOCENTE

ALFREDO ROJO GARCIA

INTEGRANTES

CEBALLOS ARREDONDO JORGE

LOPEZ OCHOA SHECCID GABRIELA

RASURA FRAGOZA HECTOR MANUEL

SANCHEZ LEDEZMA BRITHANY ALEJANDRA

GRADO Y GRUPO

4-3
 BLOQUEO 1: INTRODUCCION A CONCEPTOS GENERALES
1.1. CONCEPTOS GENERALES DE SOFTWARE:.......................................................................................3
SOFTWARE.................................................................................................................................................3
TIPOS DE SOFTWARE....................................................................................................................................4
Software de  Sistema............................................................................................................................4
Software de  Programación..................................................................................................................4
Software de  Aplicación........................................................................................................................5
CARACTERÍSTICAS DE UN SOFTWARE:...............................................................................................................6
ETAPAS DEL CICLO DE DESARROLLO DE SOFTWARE..............................................................................................7
EN UN PROYECTO DE SOFTWARE SUELE:.............................................................................................8
1.2 COSTO DEL SOFTWARE.................................................................................................................. 8
1.2.1 DIRECTO..................................................................................................................................... 8
1.2.2 INDIRECTO.........................................................................................................................................9
1.2.3 OCULTO............................................................................................................................................9
1.3 FALLAS DEL SOFTWARE .............................................................................................................. 10
1.4 RETRASOS Y CANCELACIONES..................................................................................................... 11
1.5 COMPLEJIDAD DEL SOFTWARE..................................................................................................... 12
LA COMPLEJIDAD DEL SOFTWARE ES UNA PROPIEDAD ESENCIAL, NO ACCIDENTA.....................................................12
1.5.1 DEL PROBLEMA............................................................................................................................13
1.5.2 DE LA SOLUCION.........................................................................................................................13
Funcionalidad.....................................................................................................................................13
Entregables.........................................................................................................................................13
Clientes y actores del proyecto...........................................................................................................14
Duración.............................................................................................................................................14
Tamaño...............................................................................................................................................14
1.6 ASPECTOS PARA EL ÉXITO DE UN SISTEMA...................................................................................15
#1 ELEGIR UNA TECNOLOGÍA DE DESARROLLO CON ÉXITO..................................................................................15
#2 SER UN BUEN ANALISTA-PROGRAMADOR...................................................................................................15
#3 Gestionar las necesidades de tus clientes si desarrollas software estándar.................................16
#4 Vender software de gestión empresarial.......................................................................................16
#5 Mantener el software de tus clientes de forma rentable..............................................................17
1.7. DIAGRAMA RIQUEZA FUNCIONAL VS CALIDAD VS TIEMPO/COSTO..............................................17
¿QUÉ IMPACTO TIENE EL COSTO DEL SOFTWARE PERSONALIZADO?......................................................................19
1.8. BALA DE PLATA........................................................................................................................... 20
1.9. CICLO DE VIDA DE SOFTWARE..................................................................................................... 22
Planificación........................................................................................................................................22
Análisis................................................................................................................................................22
Diseño.................................................................................................................................................23
Implementación..................................................................................................................................23
Pruebas...............................................................................................................................................24
Instalación o despliegue.....................................................................................................................24
Uso y mantenimiento.........................................................................................................................24
1.10. MITOS DEL SOFTWARE.............................................................................................................. 25
EL DESARROLLO DE SOFTWARE A MEDIDA CONSUME MUCHO TIEMPO EN COMPARACIÓN CON LAS APLICACIONES
DISPONIBLES EN EL MERCADO.......................................................................................................................25
..............................................................................................................................................................25
MUCHOS PROGRAMAS CONTIENEN VIRUS INFORMÁTICOS OCULTOS.....................................................................25
LA MAYORÍA DEL SOFTWARE CONTIENE FUNCIONES OCULTAS QUE PERMITEN EL PHISHING O EL ESPIONAJE..................25
EL SOFTWARE SE PUEDE DESARROLLAR INCLUSO SIN UN EQUIPO DE GESTIÓN DE PROYECTOS....................................26
LA MAYORÍA DEL SOFTWARE SE VUELVE FÁCILMENTE OBSOLETO..........................................................................26
BLOQUE 1: INTRODUCCION A CONCEPTOS GENERALES
1.1. CONCEPTOS GENERALES DE SOFTWARE:
Software

El Software es el soporte lógico e inmaterial que permite que la computadora pueda

desempeñar tareas inteligentes, dirigiendo a los componentes físicos o hardware con
instrucciones y datos a través de diferentes tipos de programas.

Tipos de software
Software de  Sistema

Conjunto de programas que sirven para interactuar con el sistema, confiriendo control
sobre el hardware, además de dar soporte a otros programas. Ejemplos: Sistema
operativo, controladores de dispositivos y programas utilitarios
Software de  Programación

Conjunto de herramientas que permiten al desarrollador informático escribir

programas usando diferentes alternativas y lenguajes de programación.

 Editores de texto.
 Compiladores.
 Interpretes.
 Enlazadores.
 Depuradores.

Software de  Aplicación

Programas que realizan tareas específicas. En cualquier campo de actividad susceptible

de ser automatizado o asistido.

Ejemplos:

 Aplicaciones específicas.
 Ofimática
 Software Educativo.
 Software Empresarial.
 Base de datos.
  Videojuegos.
 Telecomunicaciones

Características de un software:

El software se desarrolla, no se fabrica en el sentido clásico de la palabra. Ambas

actividades se dirigen a la construcción de un "producto", pero los métodos son
diferentes. Los costes del software se encuentran en la ingeniería, esto implica que los
proyectos no se pueden gestionar como si lo fueran de fabricación.

La juventud de la ingeniería del software con respecto a otras ingenierías, la mayoría

del software se construye a medida, en vez de ensamblar componentes previamente
creados. Aunque ya se están dando importantes pasos en esta dirección, que facilitaría
en gran medida el desarrollo de aplicaciones informáticas.

En el software, el recurso principal son las personas. No es siempre posible acelerar la

construcción de software añadiendo personas porque la construcción de software
requiere un esfuerzo en equipo. El equipo tiene que trabajar de forma coordinada y
compartir un objetivo de proyecto común. Se necesita comunicación efectiva dentro
del equipo.

El software no se estropea, pero se deteriora. Durante su vida, el software sufre

cambios (mantenimiento). Conforme se hacen los cambios, es bastante probable que
se introduzcan nuevos defectos, lo que hace que el software se vaya deteriorando
debido a estos cambios.

Etapas del ciclo de desarrollo de software

Las etapas principales a realizar en cualquier ciclo de vida son:

Análisis: Construye un modelo a partir de la toma de los requisitos

Diseño: A partir del modelo de análisis se deducen las estructuras de datos, la

estructura en la que descompone el sistema y la interfaz de usuario.

Codificación: Construye el sistema. La salida de esta fase es código ejecutable.

Pruebas: Se comprueba que se cumplen criterios de corrección y calidad.

Mantenimiento: En esta fase, que tiene lugar después de la entrega se asegura que el
sistema siga funcionando y adaptándose a nuevos requisitos.

En un proyecto de software suelen participar los siguientes

perfiles:
1.2 COSTO DEL SOFTWARE

1.2.1 Directo
Para adquirir el software, el cual incluye el software empacado, se puede adquirir en un
negocio de computación o por internet: y el software a la medida, que requiere un desarrollo
especializado y adaptado a las necesidades particulares de una empresa

1.2.2 Indirecto
Para utilizar el software incluye aspectos como capacitación, instalación, soporte técnico, así
como otros costos que por lo general se pueden conocer de antemano.

1.2.3 Oculto
Ocasionado principalmente por las fallas del software. A diferencia de los costos directos e
indirectos, los cuales son previsibles, los costos ocultos por definición son difíciles de prever.
Vale la pena destacar que el tema de costos ocultos afecta principalmente a los sistemas
conocidos como de misión crítica aquellos sistemas críticos para la operación correcta de una
empresa

1.3 FALLAS DEL SOFTWARE.

La pc enciende pero no tiene imagen.

El monitor se ve a 16 colores.

El puntero no quiere avanzar.

No se configura la impresora.

El modem no logra conectarse a internet.

Al encender manda un mensaje que Windows se cerró inesperadamente .

Presencia de virus.

Tarda mucho en iniciar y cerrar.

La computadora se ha vuelto lenta

La PC se reinicia o apaga sola

1.4 RETRASOS Y CANCELACIONES
Los proyectos de software son proyectos que tienen características muy particulares: sus
entregables son digitales (programas de cómputo, archivos fuente, diagramas, modelos,
manuales, etc. digitales), requieren mucha creatividad en la mayoría de sus fases, Los proyectos
representan el modelado parcial de la organización, son de gran complejidad, son muy costosos,
son manejados con poca experiencia administrativa y son de gran importancia para las
organizaciones en la sociedad postindustrial. Posteriormente, se hace un análisis de los factores
que determinan el éxito o fracaso de los proyectos de software. Finalmente se analizan las causas
de la falla de proyectos desde la perspectiva de los estudios organizacionales y se propone un
enfoque para reducir esa tasa de fracaso mediante la administración de proyectos, la ingeniería de
software y el aprendizaje organizacional.

A continuación le mostraremos unos ejemplos de sobrecostos, retrasos o cancelaciones:

 Sobrecosto y retraso en sistema de Allstate Insurance (1982). En 1982, Allstate Insurance

comenzó a construir un sistema para automatizar su negocio por $8 millones. El supuesto
esfuerzo de 5 años continuó hasta al menos 1993 cuando terminó costando cerca de $100
millones.

 Sobrecosto, retraso y cancelación en sistema de London Stock Exchange (1983-1988). El

proyecto Taurus de la Bolsa de Valores de Londres estaba originalmente cotizado en 6
millones de libras. Varios años más tarde y más de 100 veces (13,200%) sobre presupuesto el
proyecto fue cancelado, costando a la ciudad de Londres al momento de ser abandonado,
800 millones de libras.

 Sobrecosto y retraso en sistema del bombardero B-1 (1985). El bombardero B-1 en servicio
desde 1985 requirió US $1 billón adicional para mejorar su software de defensa aérea que era
inefectivo, aunque problemas de software imposibilitaron alcanzar los objetivos originales.

 Sobrecosto, retraso y cancelación en sistema de Bank of America (1988). En 1988, Bank of

America gastó US $23 millones en una plan inicial de 5 años para desarrollar MasterNet, un
sistema computarizado para contabilidad y reportes de “trust”. Luego de abandonar el
sistema viejo, gastaron $60 millones adicionales para lograr que el nuevo sistema funcionara
y finalmente terminaron desistiendo. Las cuentas de los clientes  perdidos pudieron haber
excedido los billones de dólares.

 Sobrecosto y retraso en sistema de control de rastreo por satélite (1989). El software para la
modernización de la Facilidad de Control de Rastreo por Satélite tomó 7 años más de lo
previsto y costó $300 millones adicionales ofreciendo menor capacidad de la requerida.
  Sobrecosto y retraso en sistema Airborne Self-Protection Jammer (1989). El sistema ASJP
(Airborne Self-Protection Jammer), un sistema electrónico de defensa aérea instalado en
alrededor de 2,000 aviones de combate y ataque de la Marina Americana, costó US $1 billón
adicional, tomó 4 años adicionales, y sólo fue “efectivo operacionalmente marginalmente y
apropiado operacionalmente marginalmente”.

 Sobrecosto en sistema del avión de carga C-17 (1989). El avión de carga C-17 construido por
Douglas Aircraft costó $500 millones adicionales por problemas del software aeronáutico. Un
reporte de GAO notó que existieron 19 computadoras a bordo, 80 microprocesadores, y 6
lenguajes diferentes de programación.

1.5 COMPLEJIDAD DEL SOFTWARE

La complejidad lógica significa más tiempo de codificación y prueba. Si su aplicación
de software personalizado realiza muchos análisis pesados, puntuación o cálculos
numéricos, o si su “código secreto” tiene muchos matices y permutaciones, su
aplicación probablemente tenga cierta complejidad que requiera atención especial.

1.5.1 DEL PROBLEMA

1.5.2 DE LA SOLUCION
Para reducir la complejidad de tu proyecto de desarrollo de software, mencionare algunas
soluciones que
Funcionalidad
Ya sea que se busque mejorar una versión existente de un programa o aplicación, o
que se trate de desarrollar una nueva, la recomendación es “menos es mejor”. Entre
mayor funcionalidad se incluya en el producto final, el proyecto será más complejo,
habrá que tener en el radar mayor número de requerimientos, las pruebas y los casos
de prueba crecerán de manera proporcional a las funciones incluidas

Entregables
Nuevamente, cuando hablamos de los distintos productos que componen el proyecto,
debemos tratar de reducir su número para poder contener la complejidad del
proyecto. Normalmente, si el número de entregables es mayor, se requerirán múltiples
procesos técnicos para producirlos, lo que sin lugar a dudas implica una mayor
complejidad. Así que trata de reducir al máximo los entregables de tu proyecto,
evidentemente este punto está de alguna forma relacionado con el anterior.

Clientes y actores del proyecto

La dificultad de poner de acuerdo, administrar las expectativas y comunicar a un grupo de
personas respecto a lo que el proyecto (y el producto del proyecto) pretende lograr, crece de
manera exponencial;

Duración
Nadie, al menos hasta donde yo sé, tiene una bola de cristal que le diga lo que va a
pasar en el futuro. Entre más lejana esté la fecha de término de tu proyecto, más
compleja será su administración. Esto es particularmente cierto para la administración
de riesgos, pues será más difícil cumplir con las fechas esperadas, y habrá mayor
tiempo para que las expectativas crezcan o para que al cliente o a nosotros se nos
ocurran mayor funcionalidad. Es así que establecer la duración de tu proyecto en
periodos de 4 a 6 meses es una buena idea. Por supuesto que cumplir con los puntos
anteriores, sobre todo el 1 y 2 contribuirá a facilitar este punto de manera directa.
Tamaño
En términos generales, entre más grande el proyecto, típicamente serán necesarias
más interfaces, mayor coordinación, más integrantes en el equipo, y muy
probablemente el número de incidentes con los que tendremos que lidiar irán en
incremento, tomando más tiempo en la resolución de conflictos. Por ello, en la medida
de lo posible será necesario establecer y acotar el alcance del proyecto de manera que
cada versión del producto a generar involucre un número reducido de participantes,
funciones y entregables.

1.6 ASPECTOS PARA EL ÉXITO DE UN SISTEMA

#1 Elegir una tecnología de desarrollo con éxito

Una problemática recurrente en casi cualquier empresa, por lo que hablo con amigos y
conocidos, es encontrar una forma eficaz de avanzar en proyectos que se consideren
estratégicos.

Las frases típicas que escuchamos cuando le preguntamos a alguien el motivo por el
que un proyecto no avanza y que yo mismo he pronunciado en multitud de ocasiones
son:

o Es que el día a día me come

o No tengo tiempo

o Tengo mucho trabajo

o Afecta a varios departamentos y no nos ponemos de acuerdo

o Eso puede esperar

Y muchas otras varias… No te pierdas este artículo si quieres saber cómo escoger una
plataforma de programación con éxito. Si lo que buscas es una tecnología de
programación low-code, también te recomendamos esta guía para elegir un
framework de desarrollo low-code.

#2 Ser un buen analista-programador

Después de casi 40 años de profesión todavía no he encontrado a ningún compañero

que me haya dicho que comenzó en la informática con el rol de analista. Sin embargo,
el 100% entre los que me incluyo comenzamos disfrutando de largas sesiones de
programación en uno u otro lenguaje y sistema operativo.

Llevo mucho tiempo comentando con otros programadores de mi edad que cada vez
que hablo con programadores jóvenes tengo la sensación de que solo quieren trabajar
en desarrollo de la interfaz, el frontend, y es rarísimo que a alguno le guste el diseño
de la base de datos.

Para ser justos tengo que decir que si miro hacia atrás esto siempre ha sido así.
Cuando yo empecé a dar mis primeros pasos en 1980 ya existía el rol de analista y de
analista-programador, sin embargo ¡a mí lo que me gustaba era “programar”, picar
código! Seguir leyendo Guía indispensable para ser un buen analista-programador.

#3 Gestionar las necesidades de tus clientes si desarrollas software estándar

Si trabajas en una empresa que desarrolla software estándar seguro que una de las
mayores dificultades que habrás vivido es la de gestionar las expectativas de los
clientes sobre la gestión de sus necesidades en las próximas versiones.

Cuando un usuario de una aplicación detecta una incidencia o mejora, si es una

aplicación desarrollada a medida se puede gestionar de forma individual, ya que cada
cliente paga un servicio de mantenimiento correctivo o evolutivo para atender esas
necesidades de forma específica.

Aquí podrás ver varios consejos sobre cómo gestionar las necesidades de tus clientes si
desarrollas software estándar.
#4 Vender software de gestión empresarial

Lejos de lo que se podría pensar, la venta telefónica (Inside Sales), crece día a día
incluyendo productos de valor añadido como es el software, en este artículo veremos
los pros de este tipo de venta y lo que debemos tener en cuenta, tanto desde el punto
de vista de la empresa que quiere montar este sistema (utilizando Inbound Marketing),
como el propio vendedor. Demostraremos que la rentabilidad y productividad es
mucho mayor, con menos esfuerzo conseguiremos llegar a más cuota de mercado y en
menos tiempo.

Nuestros clientes desarrollan aplicaciones de software de gestión empresarial con la

plataforma de desarrollo Velneo y muchas veces nos piden consejo sobre cómo vender
su software por teléfono. Este artículo les puede ayudar a empezar con esta forma de
vender sus aplicaciones de gestión.

Pero si aún no programas aplicaciones empresariales en Velneo y tienes una empresa

de desarrollo de software, estas pautas te sirven igualmente, te pueden resultar útiles,
esto no es más que una guía para vender software por teléfono y no morir en el
intento. También te recomiendo ver el artículo sobre la venta de software a puerta fría
(venta Outbound de software).

#5 Mantener el software de tus clientes de forma rentable

Voy a compartir contigo un montón de ideas que espero te sirvan para mejorar la
rentabilidad de tu negocio, y sobre todo evitar cometer errores que siempre suponen
fuertes dolores de cabeza para ti y para tus clientes.

Muchos de esos errores los conozco bien porque los he cometido y vivido en primera
persona.

No te voy a aburrir contándote un montón de teoría sobre los tipos de mantenimiento

que existen y cuya definición puedes encontrar en decenas de artículos por internet.
Pero sí necesito enumerarlos y acompañarlos de ejemplos prácticos y comentarios de
interés en esta guía para mantener el software de tus clientes de forma rentable.
1.7. Diagrama riqueza funcional vs calidad vs
tiempo/costo
Diagrama riqueza funcional

Representa el volumen ocupado por la comunidad

en el espacio de los rasgos. Este índice, al igual que
el Convex Hull identifica las especies con valores
extremos de los rasgos y luego estima el volumen
del cuerpo en el hiperespacio. El algoritmo usado
identifica el tipo de variables produciendo una
estandarización que evita los efectos de escala y
cuando el número de rasgos considerados es igual o superior al número de especies
realiza una transformación previa por coordenadas principales para reducir la
dimensionalidad, ya que para el cálculo del Convex hull es necesario que el rango de la
matriz sea la menos igual al rango columna. El valor máximo posible de FRic en un
espacio de los rasgos de T dimensiones con 2T especies se obtiene con la combinación
de los valores extremos (mínimo, máximo) de todos los rasgos.

Calidad

La calidad del software es una preocupación a la que se

dedican muchos esfuerzos. Sin embargo, el software casi
nunca es perfecto. Todo proyecto tiene como objetivo
producir software de la mejor calidad posible, que cumpla, y
si puede supere las expectativas de los usuarios.

 Es la aptitud de un producto o servicio para satisfacer las

necesidades del usuario.
 Es la cualidad de todos los productos, no solamente de equipos sino también
de programas.

En el desarrollo de software, la calidad de diseño acompaña a la calidad de los

requisitos, especificaciones y diseño del sistema. La calidad de concordancia es un
aspecto centrado principalmente en la implementación; Si la implementación sigue al
diseño, y el sistema resultante cumple con los objetivos de requisitos y de
rendimiento, la calidad de concordancia es alta.

Son características propias del software, aquellas que tú quieres controlar y asegurar.
El software es un producto inmaterial que no se fabrica, tampoco se degrada
físicamente, pero sí se desarrolla. El software puede tener errores e incidencias, pero
no son similares a las de cualquier equipo de carácter físico.

La calidad del software se encuentra casi a la par de la calidad tradicional, ligeramente

detrás, debido a que la calidad tradicional tiene varias décadas de historia, mientras
que la calidad de software tiene entre 50 y 30 años de haber surgido.

El software necesita ser actualizado.

Tiempo/costo

Normalmente, el costo del desarrollo de software personalizado varía de $ 40,000 a $

50,000. Sin embargo, este rango es muy
amplio; esto se debe a que hay
numerosos aspectos que contribuyen a
los costos del desarrollo de software
personalizado.

¿Qué impacto tiene el costo del software personalizado?

1. Tamaño del software

Cuantas más pantallas/páginas tenga, más trabajo deberá realizar para crear su
aplicación y más costoso será al momento de la entrega. Las aplicaciones pequeñas
van desde 10 a 25 pantallas, el tamaño medio está en el orden de 25-40 y un tamaño
grande es algo más que 40.

2. Complejidad del software

La complejidad lógica significa más tiempo de codificación y prueba. Si su aplicación

de software personalizado realiza muchos análisis pesados, puntuación o cálculos
numéricos, o si su “código secreto” tiene muchos matices y permutaciones, su
aplicación probablemente tenga cierta complejidad que requiera atención especial.

3. Diseño creativo

El diseño creativo en el desarrollo de software personalizado es donde puede elegir

diferentes fuentes y paletas de colores, entre otras. Al igual que cuando diseñas y
decoras una casa, cuantos más extravagantes sean tus necesidades y deseos de
diseño, más caros serán tus costos.

4. Integración con otros sistemas

La integración con software externo introduce muchas variables desconocidas en la

ecuación. Simplemente no sabe qué tanto el otro sistema permite que la información
entre o salga, y qué obstáculos tiene para saltar en el proceso.

A veces las integraciones no requieren esfuerzo y otras son extremadamente difíciles.

Las integraciones típicas como proveedores de pago como PayPal o Authorize.Net son
extremadamente fáciles de hacer. Lo mismo ocurre con los servicios de verificación de
crédito de Equifax o Experian.

Los sistemas más antiguos o menos conocidos pueden plantear un desafío y aumentar
el costo del proyecto.

5. Migración de datos existentes.

Si tiene datos en un sistema existente que necesita integrarse en su nueva aplicación,

suponiendo que es más de lo que puede escribir manualmente, entonces necesitará la
migración. La migración no es más que secuencias de comandos personalizados que
eliminan los datos de su sistema anterior, los depuran y los modifican para que puedan
adaptarse a su nuevo sistema.
1.8. Bala de plata
Brooks argumenta que «no hay un simple
desarrollo en tecnología o técnica de
gestión, que por sí solo prometa incluso
una mejora en la productividad,
fiabilidad, simplicidad, en un orden de
magnitud [por diez] dentro de una
década». También afirma que, en el
desarrollo de software, (no podemos esperar siquiera ver una ganancia del doble cada
dos años), como la que hay en el desarrollo del hardware.

Brooks hace una distinción entre la complejidad accidental y la complejidad esencial y

afirma que la mayoría de lo que ahora hacen los ingenieros de software está dedicado
a lo esencial, así que reducir todas las actividades accidentales a cero no dará una
mejora de un orden de magnitud. Brooks aboga por abordar las partes esenciales del
proceso de software. Mientras insiste que no hay ninguna bala de plata, él cree una
serie de innovaciones atacando la complejidad esencial podría conducir a importantes
mejoras (tal vez mayor que diez veces en un período de diez años).

El corazón del argumento es la distinción entre la complejidad accidental y

la complejidad esencial. La complejidad accidental se refiere a los problemas que
creamos nosotros mismos y que pueden corregirse; por ejemplo, los detalles de
escribir y optimizar de código en lenguaje ensamblador o los retrasos causados por el
procesamiento por lotes. La complejidad esencial es causada por el problema a
resolver, y nada puede eliminarla; Si el usuario desea un programa para hacer 30 cosas
diferentes, entonces esas 30 cosas son esenciales y el programa debe hacer esas 30
cosas diferentes.

Brooks afirma que hemos limpiado gran parte de la complejidad accidental, y los
programadores de hoy pasan la mayor parte de su tiempo abordando la complejidad
esencial. Una tecnología, que había hecho una mejora significativa en el área de
complejidad accidental fue la invención de lenguajes de programación de alto nivel,
como Fortran en ese tiempo. Lenguajes de hoy, como C, C++, C# y Java, son
considerados como mejoras, pero no del mismo orden de magnitud

Brooks aboga por el "crecimiento" orgánico del software a través del desarrollo

incremental. Sugiere la elaboración y la implementación del programa principal y los
subprogramas justo al principio, llenando las subsecciones de trabajo más tarde.
Brooks cree que esta forma de programación apasiona a los ingenieros y proporciona
un sistema de trabajo en cada etapa de desarrollo.

Brooks prosigue en argumentar que hay una diferencia entre diseñadores "buenos" y
"magníficos". Postula que, como la programación es un proceso creativo, algunos
diseñadores son intrínsecamente mejores que otros. Sugiere que hay tanto como una
diferencia de diez veces entre un diseñador común y uno magnífico. Entonces Brooks
sugiere tratar a los diseñadores estrellas igual de bien como a los gerentes estrellas,
proporcionándoles no sólo igualdad de remuneración, sino también todos los
privilegios del estatus mayor: despacho grande, personal, fondos para viajes, etc.

1.9. Ciclo de vida de software

La metodología para el desarrollo de software
es un modo sistemático de realizar, gestionar y
administrar un proyecto para llevarlo a cabo
con grandes posibilidades de éxito. Esta
sistematización indica cómo se divide un
proyecto en módulos más pequeños para
normalizar cómo se administra el mismo.

Así, una metodología para el desarrollo de software son los procesos a seguir
sistemáticamente para idear, implementar y mantener un producto de software desde
que surge la necesidad del producto hasta que se cumple el objetivo por el cual fue
creado.

De esta forma, las etapas del desarrollo de software son las siguientes:
Planificación

Antes de empezar un proyecto de desarrollo de un sistema de información, es

necesario hacer ciertas tareas que influirán decisivamente en el éxito del mismo.
Dichas tareas son conocidas como el fuzzy front-end del proyecto, puesto que no están
sujetas a plazos.
Algunas de las tareas de esta fase incluyen actividades como la determinación del
ámbito del proyecto, la realización de un estudio de viabilidad, el análisis de los riesgos
asociados, la estimación del coste del proyecto, su planificación temporal y la
asignación de recursos a las diferentes etapas del proyecto.

Análisis

Por supuesto, hay que averiguar qué es exactamente lo que tiene que hacer el
software. Por eso, la etapa de análisis en el ciclo de vida del software corresponde al
proceso a través del cual se intenta descubrir qué es lo que realmente se necesita y se
llega a una comprensión adecuada de los requerimientos del sistema (las
características que el sistema debe poseer).

Diseño

En esta fase se estudian posibles opciones de implementación para el software que

hay que construir, así como decidir la estructura general del mismo. El diseño es una
etapa compleja y su proceso debe realizarse de manera iterativa.

Es posible que la solución inicial no sea la más adecuada, por lo que en tal caso hay
que refinarla. No obstante, hay catálogos de patrones de diseño muy útiles que
recogen errores que otros han cometido para no caer en la misma trampa.

Implementación

En esta fase hay que elegir las herramientas adecuadas, un entorno de desarrollo que
facilite el trabajo y un lenguaje de programación apropiado para el tipo de software a
construir. Esta elección dependerá tanto de las decisiones de diseño tomadas como del
entorno en el que el software deba funcionar.

Al programar, hay que intentar que el código no sea indescifrable siguiendo distintas
pautas como las siguientes:

 Evitar bloques de control no estructurados.

 Identificar correctamente las variables y su alcance.
 Elegir algoritmos y estructuras de datos adecuadas para el problema.
 Mantener la lógica de la aplicación lo más sencilla posible.
 Documentar y comentar adecuadamente el código de los programas.
 Facilitar la interpretación visual del código utilizando reglas de formato de código
previamente consensuadas en el equipo de desarrollo.
También hay que tener en cuenta la adquisición de recursos necesarios para que el
software funcione, además de desarrollar casos de prueba para comprobar el
funcionamiento del mismo según se vaya programando.

Pruebas

Como errar es humano, la fase de pruebas del ciclo de vida del software busca detectar
los fallos cometidos en las etapas anteriores para corregirlos. Por supuesto, lo ideal es
hacerlo antes de que el usuario final se los encuentre. Se dice que una prueba es un
éxito si se detecta algún error.

Instalación o despliegue

La siguiente fase es poner el software en funcionamiento, por lo que hay que planificar
el entorno teniendo en cuenta las dependencias existentes entre los diferentes
componentes del mismo.

Es posible que haya componentes que funcionen correctamente por separado, pero
que al combinarlos provoquen problemas. Por ello, hay que usar combinaciones
conocidas que no causen problemas de compatibilidad.
Uso y mantenimiento

Esta es una de las fases más importantes del ciclo de vida de desarrollo del software.
Puesto que el software ni se rompe ni se desgasta con el uso, su mantenimiento
incluye tres puntos diferenciados:

 Eliminar los defectos detectados durante su vida útil (mantenimiento correctivo).

 Adaptarlo a nuevas necesidades (mantenimiento adaptativo).
 Añadirle nuevas funcionalidades (mantenimiento perfectivo).
1.11. Modelo SEI de 5 grados

Un nivel de madurez bien definida con una meseta evolutiva hacia la consecución de
un proceso software maduro. Cada nivel de madurez proporciona una capa en la base
para una mejora continua del proceso.
Los modelos CMMI con representación por etapas, tienen cinco niveles de madurez
designado por los números del 1 al 5. Estos son:

 Inicial
 Gestionado
 Definido
 Cuantitativamente gestionado
 Optimizar
Nivel de madurez

Los niveles de madurez consisten en un conjunto predefinido de áreas de proceso. Los

niveles de madurez se miden por el logro de los objetivos genéricos y específicos que
se aplican a cada conjunto predefinido de áreas de proceso.
Nivel de madurez inicial 1

En el nivel de madurez 1, los procesos suelen ser de desarrollo caótico. La

organización normalmente no proporciona un entorno estable. El éxito de estas
organizaciones depende de la competencia y de la disposición de las personas de la
organización y no en el uso de procesos probados.
Las organizaciones con un nivel de madurez 1 a menudo se producen los productos y
servicios que funcionan; sin embargo, frecuentemente exceden el presupuesto y el
calendario de sus proyectos.
Las organizaciones con un nivel de madurez 1 se caracterizan por una tendencia a
cometer, abandonar los procesos en el momento de la crisis, y no ser capaz de repetir
sus éxitos pasados.
Nivel de madurez 2: administrado
En el nivel de madurez 2, la organización ha logrado todos los
objetivos genéricos y específicos del nivel de madurez 2 áreas de proceso. En otras
palabras, los proyectos de la organización han asegurado que los requisitos son
gestionados y de que los procesos se planifican, realizan, medido y controlado.
La disciplina de los procesos reflejados por nivel de madurez 2 ayuda a garantizar que
se conserven las prácticas existentes en los momentos de estrés. Cuando estas
prácticas están en su lugar, los proyectos se realizan y administran conforme a sus
planes documentados correspondientes.
En el nivel de madurez 2, los requisitos, los procesos, los productos de trabajo, y los
servicios son administrados. El estado de los productos de trabajo y la prestación de
servicios son visibles a la gestión en puntos definidos.
Los compromisos establecidos entre las partes interesadas y son revisados en la
medida necesaria. Productos de Trabajo son objeto de examen con las partes
interesadas y están controlados.
Los productos de trabajo y servicios satisfacen sus requisitos especificados, las
normas y objetivos.
Nivel de madurez 3: definida

En el nivel de madurez 3, la organización ha alcanzado todos los objetivos específicos

y de las áreas de proceso asignadas a los niveles de madurez 2 y 3.
En el nivel de madurez 3, los procesos están bien caracterizados y entendidos, y se
describen en las normas, procedimientos, herramientas y métodos.
Una diferencia fundamental entre el nivel de madurez 2 y el nivel de madurez 3 es el
ámbito de los estándares, las descripciones de los procesos y procedimientos. En el
nivel de madurez 2, los estándares, las descripciones de los procesos y los
procedimientos pueden ser bastante diferentes en cada una de las instancias
específicas del proceso (por ejemplo, en un proyecto en particular).
En el nivel de madurez 3, los estándares, las descripciones de los procesos y
procedimientos de un proyecto se diseñan a partir del conjunto de procesos estándar
de la organización para adaptarse a un determinado proyecto o unidad organizativa.
El conjunto de procesos estándar de la organización incluye los procesos abordados
en el nivel de madurez 2 y el nivel de madurez 3. Como resultado de ello, los procesos
que se llevan a cabo en toda la organización son compatibles excepto por las
diferencias de la sastrería.
Otra diferencia fundamental es que en el nivel de madurez 3, los procesos son
normalmente se describe con más detalle y más rigurosa que en el nivel de madurez
2. En el nivel de madurez 3, los procesos son gestionados de manera más proactiva,
usando la comprensión de las relaciones de las actividades del proceso y las medidas
detalladas del proceso, sus productos de trabajo y sus servicios.

Nivel de madurez 4: administrado cuantitativamente

En el nivel de madurez 4, una organización ha logrado todos los objetivos
específicos de las áreas de proceso asignadas a los niveles de madurez 2, 3 y 4 y
los objetivos genéricos asignados a los niveles de madurez 2 y 3.
En el nivel de madurez 4, se seleccionan los que contribuyen de forma significativa al
rendimiento del proceso en general. Estos sub-procesos están controlados mediante
técnicas estadísticas y otras técnicas cuantitativas.
Objetivos cuantitativos de calidad y rendimiento de los procesos se establecen y se
utilizan como criterios para la gestión de procesos. Los objetivos cuantitativos se
basan en las necesidades del cliente, los usuarios finales, la organización, y los
responsables de la implementación de los procesos. Calidad y rendimiento de los
procesos se entienden en términos estadísticos y se administran a lo largo de la vida
de los procesos.
Para estos procesos, las medidas detalladas del rendimiento de los procesos son
recogidos y analizados estadísticamente. Causas Especiales de variación de procesos
se identifican y, en su caso, las fuentes de causas especiales están corregidos para
evitar que se repita en el futuro.
Calidad y rendimiento de los procesos se hayan incorporado las medidas en la
organización del repositorio a medida soporte de toma de decisiones basadas en el
futuro.
Una diferencia fundamental entre el nivel de madurez 3 y el nivel de madurez 4 es el
grado de previsibilidad del rendimiento de los procesos. En el nivel de madurez 4, el
rendimiento de los procesos se controla mediante técnicas estadísticas y otras
técnicas cuantitativas, por lo que es previsible cuantitativamente hablando. En el nivel
de madurez 3, los procesos son sólo cualitativamente predecibles.

Nivel de madurez 5: Optimización

En el nivel de madurez 5, una organización ha logrado todas las metas del proceso

zonas asignadas a los niveles de madurez 2, 3, 4 y 5, y los objetivos
genéricos asignados a los niveles de madurez 2 y 3.
Mejorar continuamente los procesos se basa en una comprensión cuantitativa de las
causas comunes de variación inherentes a los procesos.
Este nivel se centra en mejora continua del rendimiento de los procesos a través de
los aumentos y mejoras tecnológicas innovadoras.
Los objetivos cuantitativos de mejora de procesos para la organización se establecen y
se revisan de forma continua a fin de reflejar los cambios objetivos de negocio, y se
utilizan como criterios para la administración de la mejora de procesos.
Los efectos de las mejoras implementadas en los procesos se miden y evalúan en
relación con los objetivos cuantitativos de mejora de procesos. Tanto los procesos
definidos como el conjunto de procesos estándar de la organización son objetivos
para las actividades de mejora considerables.
Optimización de los procesos ágiles e innovadores, depende de la participación de un
personal capacitado y alineado con los valores y objetivos empresariales de la
organización. La capacidad de la organización para responder con rapidez a los
cambios y oportunidades se mejora mediante la búsqueda de formas para compartir
y fomentar el aprendizaje. Mejora de los procesos es, inherentemente, un papel que
todo el mundo tiene que jugar, lo que se traduce en un ciclo de mejora continua.
1.12. Métricas del proceso y mejoras de proceso del software

Métricas del proceso

• Se recopilan en el transcurso de todos los proyectos y durante largos períodos.

• Su objetivo es proporcionar un conjunto de indicadores que conduzcan a la mejora

del proceso.

Medición del proceso de software

- Enfocar el proceso de generación de productos y servicios.

- Asegurar que los procesos están apropiadamente apoyados.

- Administrar procesos inmaduros enfocando el proceso y no culpando las personas.

- Reconocer la existencia de variaciones como oportunidad de mejora.

- Considerar las variaciones en la evaluación del proceso de tomada de decisión.

Medir el proceso

Objetivos Recoger datos que midan el desempeño de cada proceso

Analizar el desempeño

Guardar y utilizar los datos - para evaluar la estabilidad y la capacidad del proceso -
para interpretar los resultados de observaciones y análisis - para estimar coste y
desempeño futuros - para proveer baselines y benchmarks - para establecer
tendencias - para identificar oportunidades de mejora

Definición de medidas para el proceso

Comunicación - ¿Los métodos utilizados para definir las medidas y para

describir valores medidos permiten que otros conozcan lo que está siendo medido? -
¿Todos los usuarios conocen cómo los datos son recogidos de manera a interpretar los
resultados correctamente?

Repetibilidad - ¿Otra persona podría ser capaz de repetir las medidas y obtener los
mismos resultados?

Rastreabilidad - ¿Hay un origen de los datos recogidos? (contexto y circunstancias de la

medición)
Ejemplo de métricas del desarrollo de software:

Tiempo de entrega (lead time). El tiempo de entrega es el tiempo que tarda algo de
principio a fin. En el desarrollo de software, por ejemplo, el tiempo de entrega de un
proyecto comienza con la propuesta y termina con la entrega.

Cantidad de código. Los equipos de desarrollo pueden mirar esta métrica de software,

también llamada miles de líneas de código (KLOC), para determinar el tamaño de una
aplicación. Si este KPI es alto, podría indicar que los desarrolladores fueron productivos
en sus esfuerzos de programación. Sin embargo, esta métrica no es útil cuando un
equipo de desarrollo intenta comparar dos proyectos escritos en diferentes lenguajes
de programación. Además, tenga en cuenta que más código no siempre hace que el
código sea eficiente o efectivo, lo que puede significar más trabajo de refactorización
más adelante.

Trabajo en curso (WIP). En un contexto de ingeniería de software, WIP es un trabajo

de desarrollo en el que el equipo ha comenzado a trabajar y que ya no está en
el backlog. Un equipo puede expresar WIP en un gráfico de quemado. Una
herramienta común para los sprints ágiles y Scrum, estos gráficos muestran cuánto
trabajo ha terminado el equipo y la cantidad de trabajo que queda por hacer.

Velocidad ágil. Para calcular la velocidad, un equipo de desarrollo de software

ágil analiza los sprints anteriores y cuenta el número de historias de usuario o puntos
de historia completados a lo largo del tiempo. La velocidad ágil es una estimación de
qué tan productivo será el equipo en un solo sprint.

Tasa de éxito de la meta del sprint. Esta métrica de software calcula el porcentaje de

elementos que completó el equipo de desarrollo en el backlog del sprint. Es posible
que un equipo no termine el 100 % del trabajo durante un sprint determinado. Sin
embargo, el progreso del equipo aún podría cumplir con su definición de terminado: el
umbral que debe alcanzar un proyecto para que una organización lo considere
terminado. Si la iteración cumple con la definición de hecho, es un éxito.

1.13. Análisis y gestión de riesgos

Para la gestión eficiente de los riesgos es necesario seguir un proceso específico que
incluye:

 Planear
 Organizar
 Dirigir y
 Controlar
Esto se refiere a los recursos de la organización, divididos en recursos humanos y
materiales, que deben cumplir el objetivo de minimizar el riesgo, o, por el contrario,
hallar cierta manera de aprovecharlos en beneficio de la empresa.

Una vez identificados los riesgos, se determinan los procesos de control para asegurar

que se prevenga o suprima su ocurrencia.

Pero la mera identificación no es suficiente para un buen análisis y gestión de riesgos.

Es necesario poner a prueba la eficacia de las medidas mencionadas por los analistas
de procesos, a intervalos determinados. Una vez verificado si cada uno de los riesgos
realmente no ocurre mediante la aplicación de los controles adecuados, se deben
registrar los resultados y determinar la fecha de la próxima verificación y evaluación
del proceso.

Pero si ocurre lo contrario, es decir, si se percibe que las medidas de control de riesgos
no son eficaces, todo el proceso debe ser revisado y se deben establecer nuevas
medidas de control para que la gestión de riesgos se vuelva efectiva una vez más.

Conceptos importantes sobre el análisis y la gestión de riesgos

Si existe la posibilidad de que el logro de un objetivo se vea obstaculizado, impedido de

que ocurra, o sufra influencias negativas debido a la ocurrencia de eventos inciertos, lo
consideramos un riesgo.

Estos eventos inciertos pueden tener origen en diferentes factores. Un

eficiente análisis y gestión de riesgos debe ser capaz de atender a cada uno de ellos
para poder identificarlos rápidamente en cada uno de los casos que se enumeran:

Riesgos de personal

Causado por la falta de personal cualificado y profesionales capacitados para ejercer

sus funciones. Existe la posibilidad de que los errores sean intencionales, esto es el
resultado de una conducta dudosa. Los principales riesgos del personal son:

 No intencionales, resultado de omisión o negligencia

 De calificación, es decir, el profesional no puede ejercer sus funciones
correctamente por falta de capacidad o habilidad
 Fraude, cuando la conducta no cumple intencionalmente las normas de la
empresa, y se caracteriza por desviaciones de material o valores, la divulgación
de mentiras, etc.
Los riesgos de procesos

Resultado de la deficiencia de los procesos internos ya utilizados por la organización,

como indicadores de desempeño inadecuados, controles
ineficaces, modelado inexacto e incluso violación de la ley.
Riesgos de los sistemas

Provenientes de los sistemas informáticos inadecuados o mal estructurados, o de

defectos que puedan ocurrir. Algunos ejemplos:

 El funcionamiento intermitente de las redes

 Caída de los servidores
 Daños físicos en los componentes de almacenamiento de datos
 Sistemas obsoletos
 Mantenimiento inadecuado
 Corte de energía por causas internas
 Lentitud en los sistemas
 Fallas de seguridad

1.14. Análisis de Requisitos.

En la ingeniería de software, un Análisis de Requerimientos es una tarea que cubre el

hueco entre la definición del software a nivel sistema y el diseño del mismo. Tanto el
desarrollador como el cliente tienen un papel activo, pues juntos definen en detalle los
requisitos del sistema a desarrollar y los pasos a seguir.

El Análisis de Requisitos es:

1. Es un estudio profundo de una necesidad tecnológica que tiene una empresa,
organización o negocio.
2. Especifica las características operacionales que tendrá el software a desarrollar.
3. Se realiza a través de entrevistas, observación, indagación y demás técnicas
específicas.
4. Describe el plan del proyecto a seguir.
5. Es fundamental entregar el proyecto dentro del tiempo y presupuesto
acordados y de los objetivos de negocio.

1.10. Mitos del software

El desarrollo de software a medida consume mucho tiempo en comparación con las
aplicaciones disponibles en el mercado

Si bien es cierto que las aplicaciones

disponibles están listas para su uso, es posible
que no estén hechas a la medida de las
necesidades exactas de un grupo, un individuo o una organización. Configurar el
software, capacitar al personal y contratar a una persona capacitada para compensar
las carencias del software disponible requiere tiempo y dinero. Sin embargo, con un
software desarrollado a medida, una organización puede obtener el software que se
adapte exactamente a sus necesidades.

Muchos programas contienen virus informáticos ocultos

Es cierto que los archivos ejecutables pueden causar estragos en el equipo, es decir,
después de que mágicamente hace que los archivos desaparezcan después de acceder
a una unidad USB. Si bien eso puede suceder, vale la pena descargar software que
provenga de fuentes acreditadas y que no zombifique una PC. Para asegurarse de que
los usuarios están obteniendo un software de buena reputación, deben descargar de
sitios web con buena reputación, evitar sitios de terceros no verificados o descargar
software pirata.

La mayoría del software contiene funciones ocultas que permiten el phishing o el

espionaje

Debido al aumento de la sofisticación técnica, siempre hay rumores de que la mayoría

de software crea algún tipo de funciones ocultas que pueden robar información
personal como nombres o ubicaciones. A menos que el software provenga de hackers
poco éticos que intentan espiar en el PC para obtener cuentas bancarias o propagar el
virus para el control de la computadora, no hay nada de qué preocuparse cuando se
instala software confiable de fuentes con buena reputación y certificadas.

El software se puede desarrollar incluso sin un equipo de gestión de proyectos

El desarrollo de software complejo requiere tiempo y enorme energía por parte de los
equipos involucrados. Sin un método, el desarrollo de software es imposible. El
resultado de un equipo de producción que no sigue un sistema eficiente o que sigue un
método de defectuoso resultará en un software defectuoso – y eventualmente, caos.
Una metodología de gestión de proyectos como el método Ágil asegura que el proceso
de desarrollo de software se desarrolle en un ambiente que minimiza la aparición de
problemas. Este método evita la repetición cuando se producen errores, ya que estos
casos pueden rectificarse incluso a mitad del proceso de producción del software.
También permite cambios en los códigos, diseño y programación en cualquier fase del
proceso de desarrollo.

La mayoría del software se vuelve fácilmente obsoleto

Mientras que las compañías de software hacen actualizaciones de software con el
propósito de mejorar el diseño y sus ganancias, las compañías éticas no hacen
software para la obsolescencia fácil de tal manera que de repente empiezan a producir
nuevas versiones de software o reemplazos de software completos en sólo unos pocos
meses o un año. Del mismo modo, los ingenieros de software éticos no harán que el
software se ejecute lentamente con el tiempo, sólo para forzar a la gente a comprar
uno nuevo.

Fuentes bibliográficas:

La ficha bibliográfica es :
Sergio Martinez. (2012). ERP: Costes ocultos de implantación y puesta en
marcha. marzo del 2021, de ERP Sitio web:
https://www.mundoerp.com/blog/erp-los-costes-ocultos-de-la-implantacion-y-
puesta-en-marcha/

Juan Pablo Canales Hernandez. (2014). conceptos basicos del software. Marzo
2021, de UNIVO Sitio web:
https://sites.google.com/site/portafolio15univo/unidad-1/-conceptos-basicos-
de-software

DEPARTAMENTO DE ORGANIZACIÓN INDUSTRIAL Y GESTIÓN DE

EMPRESAS ESCUELA SUPERIOR DE INGENIEROS DE LA
UNIVERSIDAD DE SEVILLA. (2016). problematica de los proyectos de
software. Marzo 2021, de DEPARTAMENTO DE ORGANIZACIÓN
INDUSTRIAL Y GESTIÓN DE EMPRESAS ESCUELA SUPERIOR DE
INGENIEROS DE LA UNIVERSIDAD DE SEVILLA Sitio web:
http://bibing.us.es/proyectos/abreproy/70193/fichero/5.+PROBLEM
%C3%81TICA+DE+LOS+PROYECTOS+SOFTWARE.pdf

https://onerp.es/exito-implantacion-software-empresarial/

https://velneo.es/5-aspectos-clave-para-triunfar-desarrollando-software-de-gestion/

INTELEQUIA. (2020). CICLO DE VIDA SOFTWARE. 2021, de INTELEQUIA Sitio

web: https://intelequia.com/blog/post/2083/ciclo-de-vida-del-software-
todo-lo-que-necesitas-saber
DAMORELOS. (2019). MITOS ACERCA DEL DESARROLLO DE SOFTWARE. 2021,
de SCIO Sitio web:
https://www.scio.com.mx/wp-content/uploads/sites/3/2018/04/x10-Mitos-
acerca-del-desarrollo-de-software-
1000x675.jpg.pagespeed.ic.z00dgeh7gZ.jpg
SEI CMMI - Niveles de Madurez - Tutorialspoint. (s. f.). Tutorial Points.
Recuperado 6 de marzo de 2021, de
https://www.tutorialspoint.com/es/cmmi/cmmi_maturity_levels.htm
Romero, G. (2019, 4 julio). ¿Qué es un Análisis de Requerimientos? Espacios
Business Media. https://www.espacios.media/que-es-un-analisis-de-
requerimientos/
EcuRed. (2011, 27 noviembre). Métricas de software - EcuRed.
https://www.ecured.cu/M%C3%A9tricas_de_software
Pacheco, J. (2017, 11 septiembre). Análisis y gestión de riesgos: Los cuatro
riesgos principales. HEFLO ES. https://www.heflo.com/es/blog/gestion-de-
riesgos/analisis-y-gestion-de-riesgos/
Black, R. (2020, 7 septiembre). 23 métricas de desarrollo de software que
monitorear hoy. SearchDataCenter.
https://searchdatacenter.techtarget.com/es/consejo/23-metricas-de-
desarrollo-de-software-que-monitorear-hoy
Alto nivel. (04 DE ENERO DEL 2011). ¿Costos ocultos en tu empresa?. MARZO
DEL 2021, de ALTO NIVEL Sitio web:
https://www.altonivel.com.mx/empresas/negocios/8048-costos-ocultos-en-
tu-empresa/#:~:text=Los%20costos%20ocultos%2C%20son%20gastos,un
%20proceso%20que%20consideramos%20eficiente
debitoor. (enero 2014). Costes indirectos. marzo del 2021, de debitoor Sitio
web: https://debitoor.es/glosario/costes-indirectos