UNIVERSIDAD AUTONOMA “GABRIEL RENE MORENO”

FACULTAD DE CONTADURIA PUBLICA Y AUDITORIA FINANCIERA

CARRERA: INFORMACION Y CONTROL DE GESTION

INTRODUCCION A LA INGENIERIA DE SOFTWARE

MATERIA: INGENIERIA DE SOFTWARE
DOCENTE: JULIO VARGAS HERBAS
INTEGRANTES:
DARLIN LEYLA JUSTINIANO PEREIRA 217170102
ADRIANA FLORES SEJAS 218148666
CARLA FABIANA VACA SANSUSTE 213127520
HAYELY NOELIA LAZARTE LOZADA 218027737
WILLY HEREDIA QUISPE 218024241
SEMESTRE: 1- 2022
INTRODUCCION
La Ingenieria de Software es una de las ramas de las ciencias de la
computación que estudia la creación de software confiable y de calidad,
basándose en métodos y técnicas de ingeniería, y brindando soporte
operacional y de mantenimiento. El campo de estudio de la ingeniería de
software integra ciencias de la computación, ciencias aplicadas y las ciencias
básicas en las cuales se encuentra apoyada la ingeniería.

Autor: Bohem
Ingeniería de software es la aplicación práctica del conocimiento científico al
diseño y construcción de programas de computadora y a la documentación
asociada requerida para desarrollar, operar y mantenerlos. Se conoce también
como desarrollo de software o producción de software.

OBJETIVO GENERAL

La ingeniería de software tiene como objetivo diseñar aplicaciones informáticas

que se ajusten a las necesidades de las organizaciones para así poder dirigir y
coordinar el desarrollo de aplicaciones complejas.

OBJETIVO ESPECIFICO

• Conocer la importancia que tiene el software al interior de las

organizaciones.
• Ser capaz de identificar problemas y entregar las soluciones más
óptimas para estos.
• Identificar cuando es necesario una solución informática (software) y
cuando no es necesaria
• Ser capaz de planificar un software, identificando claramente sus ciclos
de vida.
MARCO TEÓRICO

¿Qué es el software?
Según Pressman, 2010
“El software de computadora es el producto que construyen los programadores
profesionales y al que después le dan mantenimiento durante un largo
tiempo. Incluye programas que se ejecutan en una computadora de
cualquier tamaño y arquitectura, contenido que se presenta a medida que
se ejecutan los programas de cómputo e información descriptiva tanto en
una copia dura como en formatos virtuales que engloban virtualmente a
cualesquiera medios electrónicos.
La ingeniería de software está formada por un proceso, un conjunto de
métodos (prácticas) y un arreglo de herramientas que permite a los
profesionales elaborar software de cómputo de alta calidad.”

Ciclo de vida del software

El término ciclo de vida del software describe el desarrollo de software, desde
la fase inicial hasta la fase final.
El ciclo de vida básico de un software consta de los siguientes procedimientos:

Figura 1: Ciclo de vida del software

La naturaleza del software

En la actualidad, el software tiene un papel dual. Es un producto y al mismo

tiempo es el vehículo para entregar un producto. El software produce,
administra, adquiere, modifica, despliega o transmite información que puede
ser tan simple como un solo bit o tan compleja como una presentación con
multimedios generada a partir de datos obtenidos de decenas de fuentes
independientes.

Figura 2: Características del software

INGENIERÍA DE SOFTWARE
Para entender un poco mas de lo que es la ingeniería de software vamos a citar
definiciones de varios autores:

1) “La ingeniería de software es el establecimiento y uso de principios

fundamentales de la ingeniería con objeto de desarrollar en forma
económica un software que sea confiable y que trabaje con eficiencia en
máquinas reales.” (Fritz Bauer)

2) Es una disciplina o área de la informática o ciencias de la computación,

que ofrece métodos y técnicas para desarrollar y mantener software de
calidad que resuelvan problemas de todo tipo (pressman 1998)
La ingeniería de software no es una disciplina que solo deba aplicarse a
proyectos de ciertas áreas, sino que también trata con áreas diversas
dentro de las ciencias computacionales, tales como: construcción de
compiladores, sistemas operativos o desarrollos empresariales. La
ingeniería de software abarca todas las fases del ciclo de vida en el
desarrollo de cualquier sistema de información aplicables a áreas tales
como investigación científica, medicina, logística y también para particular-
negocios.

Figura 4: Capas de la ingeniería de software

EL PROCESO DEL SOFTWARE

Un proceso es un conjunto de actividades, acciones y tareas que se ejecutan
cuando va a crearse algún producto del trabajo, a continuación, se definen
cada uno de estos términos.
 Una actividad busca lograr un objetivo amplio (por ejemplo, comunicación
con los participantes) y se desarrolla sin importar el dominio de la
aplicación, tamaño del proyecto, complejidad del esfuerzo o grado de rigor
con el que se usará la ingeniería de software.
 Una acción (diseño de la arquitectura) es un conjunto de tareas que
producen un producto importante del trabajo (por ejemplo, un modelo del
diseño de la arquitectura).
 Una tarea se centra en un objetivo pequeño, pero bien definido (por
ejemplo, realizar una prueba unitaria) que produce un resultado tangible.
Una estructura de proceso general para la ingeniería de software consta de
cinco actividades:

Fi
gura 5: Actividades Estructurales para el desarrollo del software

DESARROLLO DE LAS ACTIVIDADES

Proceso De Desarrollo Del Software

Un proceso de desarrollo de software tiene como propósito la producción eficaz
y eficiente de un producto software que reúna los requisitos del cliente.
Un producto software es intangible y por lo general muy abstracto, esto dificulta
la definición del producto y sus requisitos, sobre todo cuando no se tiene
precedentes en productos software similares.

Figura 2: proceso de desarrollo de software.

El proceso de desarrollo de software no es único. No existe un proceso de
software universal que sea efectivo para todos los contextos de proyectos
de desarrollo. Debido a esta diversidad, es difícil automatizar todo un
proceso de desarrollo de software.
A pesar de la variedad de propuestas de proceso de software, existe un
conjunto de actividades fundamentales que se encuentran presentes en
todos ellos:
 Especificación de software: Se debe definir la funcionalidad y
restricciones operacionales que debe cumplir el software.
 Diseño e Implementación: Se diseña y construye el software de acuerdo a
la especificación.
 Validación: El software debe validarse, para asegurar que cumpla con lo
que quiere el cliente.
 Evolución: El software debe evolucionar, para adaptarse a las necesidades
del cliente.

Además de estas actividades fundamentales, Pressman menciona un conjunto

de "actividades protectoras", que se aplican a lo largo de todo el proceso del
software. Ellas se señalan a continuación:
 Seguimiento y control de proyecto de software.
 Revisiones técnicas formales.
 Garantía de calidad del software.
 Gestión de configuración del software.
 Preparación y producción de documentos.
 Gestión de reutilización.
 Mediciones.
 Gestión de riesgos.

Pressman caracteriza un proceso de desarrollo de software como se muestra

en la Figura 3.
Los elementos involucrados se describen a continuación:
 Un marco común del proceso, definiendo un pequeño número de
actividades del marco de trabajo que son aplicables a todos los proyectos
de software, con independencia del tamaño o complejidad.
 Un conjunto de tareas, cada uno es una colección de tareas de ingeniería
del software, hitos de proyectos, entregas y productos de trabajo del
software, y puntos de garantía de calidad, que permiten que las actividades
del marco de trabajo se adapten a las características del proyecto de
software y los requisitos del equipo del proyecto.
 Las actividades de protección, tales como garantía de calidad del software,
gestión de configuración del software y medición, abarcan el modelo del
proceso. Las actividades de protección son independientes de cualquier
actividad del marco de trabajo y aparecen durante todo el proceso.

Figura 3: Elementos del proceso del software

Otra perspectiva utilizada para determinar los elementos del proceso de

desarrollo de software es establecer las relaciones entre elementos que
permitan responder Quién debe hacer Qué, Cuándo y Cómo debe hacerlo.
Figura 4: Relación entre elementos del proceso del software

En la Figura 4 se muestran los elementos de un proceso de desarrollo de

software y sus relaciones. Así las interrogantes se responden de la
siguiente forma:
 Quién: Las Personas participantes en el proyecto de desarrollo
desempeñando uno o más Roles específicos.
 Qué: Un Artefacto es producido por un Rol en una de sus Actividades. Los
Artefactos se especifican utilizando Notaciones específicas. Las
Herramientas apoyan la elaboración de Artefactos soportando ciertas
Notaciones.
 Cómo y Cuándo: Las Actividades son una serie de pasos que lleva a cabo
un Rol durante el proceso de desarrollo. El avance del proyecto está
controlado mediante hitos que establecen un determinado estado de
terminación de ciertos Artefactos. La composición y sincronía de las
actividades está basada en un conjunto de Principios y Prácticas. Las
Prácticas y Principios enfatizan ciertas actividades y/o la forma como deben
realizarse, por ejemplo: desarrollar iterativamente, gestionar requisitos,
desarrollo basado en componentes, modelar visualmente, verificar
continuamente la calidad, gestionar los cambios, etc.
MODELOS DE PROCESO SOFTWARE
1.-Modelo en cascada El más conocido, está basado en el ciclo convencional
de una ingeniería, el paradigma del ciclo de vida abarca las siguientes
actividades:

Figura 5: Grafico de representación del modelo en cascada

Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte

de un sistema mayor el trabajo comienza estableciendo los requisitos de
todos los elementos del sistema y luego asignando algún subconjunto de
estos requisitos al software.
Análisis de los requisitos del software: El proceso de recopilación de los
requisitos se centra e intensifica especialmente en el software. El ingeniero
de software (Analistas) debe comprender el ámbito de la información del
software, así como la función, el rendimiento y las interfaces requeridas.
Diseño: El diseño del software se enfoca en cuatro atributos distintos del
programa: la estructura de los datos, la arquitectura del software, el detalle
procedimental y la caracterización de la interfaz. El proceso de diseño
traduce los requisitos en una representación del software con la calidad
requerida antes de que comience la codificación.
Codificación: El diseño debe traducirse en una forma legible para la maquina.
El paso de codificación realiza esta tarea. Si el diseño se realiza de una
manera detallada la codificación puede realizarse mecánicamente.
Prueba: Una vez que se ha generado el código comienza la prueba del
programa. La prueba se centra en la lógica interna del software, y en las
funciones externas, realizando pruebas que aseguren que la entrada
definida produce los resultados que realmente se requieren.
Mantenimiento: El software sufrirá cambios después de que se entrega al
cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a
que el software deba adaptarse a cambios del entorno externo (sistema
operativo o dispositivos periféricos), o debido a que el cliente requiera
ampliaciones funcionales o del rendimiento.
Desventajas:
 Los proyectos reales raramente siguen el flujo secuencial que propone el
modelo, siempre hay iteraciones y se crean problemas en la aplicación del
paradigma.
 Normalmente, es difícil para el cliente establecer explícitamente al principio
todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades
en acomodar posibles incertidumbres que pueden existir al comienzo de
muchos productos.
 El cliente debe tener paciencia. Hasta llegar a las etapas finales del
proyecto, no estará disponible una versión operativa del programa. Un error
importante no detectado hasta que el programa esté funcionando puede ser
desastroso.

Ventajas
 radica en su sencillez ya que sigue los pasos intuitivos necesarios a la
hora de desarrollar el software.
 obtiene una rápida realimentación del usuario, ya que las actividades de
especificación, desarrollo y pruebas se ejecutan en cada iteración.
Figura 6: Modelo de desarrollo evolutivo. Existen dos tipos de desarrollo
evolutivo:

Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el

usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza
con las partes que se tiene más claras. El sistema evoluciona conforme se
añaden nuevas características propuestas por el usuario.
Enfoque utilizando prototipos: El objetivo es entender los requisitos del
usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del
desarrollo exploratorio, se comienza por definir los requisitos que no están
claros para el usuario y se utiliza un prototipo para experimentar con ellos.
El prototipo ayuda a terminar de definir estos requisitos.
Entre los puntos favorables de este modelo están:
 La especificación puede desarrollarse de forma creciente.
 Los usuarios y desarrolladores logran un mejor entendimiento del sistema.
Esto se refleja en una mejora de la calidad del software.
 Es más efectivo que el modelo de cascada, ya que cumple con las
necesidades inmediatas del cliente.

Desde una perspectiva de ingeniería y administración se identifican los

siguientes problemas:
 Proceso no Visible: Los administradores necesitan entregas para medir el
progreso. Si el sistema se necesita desarrollar rápido, no es efectivo
producir documentos que reflejen cada versión del sistema.
 Sistemas pobremente estructurados: Los cambios continuos pueden ser
perjudiciales para la estructura del software haciendo costoso el
mantenimiento.
 Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan
herramientas que pueden ser incompatibles con otras o que poca gente
sabe utilizar.

Este modelo es efectivo en proyectos pequeños (menos de 100.000 líneas de

código) o medianos (hasta 500.000 líneas de código) con poco tiempo para
su desarrollo y sin generar documentación para cada versión.

MODELO INCREMENTAL
El enfoque incremental de desarrollo se ve como una forma de reducir la
repetición del trabajo en el proceso de desarrollo y dar oportunidad de
retrasar la toma de decisiones en los requisitos hasta adquirir experiencia
con el sistema (ver Figura 10). Es una combinación del Modelo de Cascada
y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad
para retrasar las decisiones hasta tener experiencia en el sistema. Durante
el desarrollo de cada incremento se puede utilizar el modelo de cascada o
evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a
implementar. Si se tiene un buen conocimiento, se puede optar por
cascada, si es dudoso, evolutivo.

Figura 7: Modelo de desarrollo iterativo incremental.

Entre las ventajas del modelo incremental se encuentran:
 Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema.
Pueden empezar a usarlo desde el primer incremento.
 Los clientes pueden aclarar los requisitos que no tengan claros conforme
ven las entregas del sistema.
 Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede
distribuir en cada incremento.
 Las partes más importantes del sistema son entregadas primero, por lo cual
se realizan más pruebas en estos módulos y se disminuye el riesgo de
fallos.

Algunas de las desventajas identificadas para este modelo son:

 Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000
líneas).
 Cada incremento debe aumentar la funcionalidad.
 Es difícil establecer las correspondencias de los requisitos contra los
incrementos.
 Es difícil detectar las unidades o servicios genéricos para todo el sistema.

MODELO EN ESPIRAL
El modelo espiral para la ingeniería de software ha sido desarrollado para cubrir
las mejores características tanto del ciclo de vida clásico, como de la
creación de prototipos, añadiendo al mismo tiempo un nuevo elemento: el
análisis de riesgo. El modelo representado mediante la espiral de la figura
2.4, define cuatro actividades principales:
 Planificación: determinación de objetivos, alternativas y restricciones.
 Análisis de riesgo: análisis de alternativas e identificación/resolución de
riesgos.
 Ingeniería: desarrollo del producto del "siguiente nivel",
 Evaluación del cliente: Valorización de los resultados de la ingeniería.
Figura 8: Modelo Espiral

Durante la primera vuelta alrededor de la espiral se definen los objetivos, las

alternativas y las restricciones, y se analizan e identifican los riesgos. Si el
análisis de riesgo indica que hay una incertidumbre en los requisitos, se
puede usar la creación de prototipos en el cuadrante de ingeniería para dar
asistencia tanto al encargado de desarrollo como al cliente.
El cliente evalúa el trabajo de ingeniería (cuadrante de evaluación de cliente) y
sugiere modificaciones. Sobre la base de los comentarios del cliente se
produce la siguiente fase de planificación y de análisis de riesgo. En cada
bucle alrededor de la espiral, la culminación del análisis de riesgo resulta en
una decisión de "seguir o no seguir".
Con cada iteración alrededor de la espiral (comenzando en el centro y
siguiendo hacia el exterior), se construyen sucesivas versiones del software,
cada vez más completa y, al final, al propio sistema operacional.
El paradigma del modelo en espiral para la ingeniería de software es
actualmente el enfoque más realista para el desarrollo de software y de
sistemas a gran escala.
EVOLUCION DEL MODELO ESPIRAL "PRESSMAN 2002"
 IWEB (Ingeniería Web)
 Para aplicaciones basadas en Web

¿Cuál es el modelo de proceso más adecuado?

Cada proyecto de software requiere de una forma particular de abordar el
problema. Las propuestas comerciales y académicas actuales promueven
procesos iterativos, donde en cada iteración puede utilizarse uno u otro
modelo de proceso, considerando un conjunto de criterios (Por ejemplo:
grado de definición de requisitos, tamaño del proyecto, riesgos identificados,
entre otros).

 En la Tabla 1 se expone un cuadro comparativo de acuerdo con algunos

criterios básicos para la selección de un modelo de proceso, la medida
utilizada indica el nivel de efectividad del modelo de proceso de acuerdo
al criterio (Por ejemplo: El modelo Cascada responde con un nivel de
efectividad Bajo cuando los Requisitos y arquitectura no están
predefinidos):
 Modelo de Funciona Produce Gestión Permite Visión del
proceso con softwar de correccio progre
requisito e riesg nes so por
sy altame os sobre la el
arquitect nte marcha Client
ura no fiable e y el
predefini Jefe
dos del
proye
cto

Cascada Bajo Alto Bajo Bajo Bajo

Evolutivo Medio o Alto Medio o Medio Medio o Alto Medio o
explorat Alto Alto
orio
Evolutivo Alto Medio Medio Alto Alto
prototipa
do
Incremental Bajo Alto Medio Bajo Bajo
Espiral Alto Alto Alto Medio Medio

Tabla 1: Comparación entre modelos de proceso de software.

METODOLOGÍAS PARA DESARROLLO DE SOFTWARE

Un proceso de software detallado y completo suele denominarse
"Metodología". Las metodologías se basan en una combinación de los
modelos de proceso genéricos (cascada, evolutivo, incremental, etc.).

METODOLOGÍA XP (Programación Extrema)

De todas las metodologías ágiles, ésta es la que ha recibido más atención.
La XP empieza con cuatro valores: Comunicación, Retroalimentación,
Simplicidad y Coraje. Construye sobre ellos una docena de prácticas que
los proyectos XP deben seguir. Muchas de estas prácticas son técnicas
 antiguas, tratadas y probadas, aunque a menudo olvidadas por muchos,
incluyendo la mayoría de los procesos planeados.
características
 la XP pone la comprobación como el fundamento del desarrollo, con
cada programador escribiendo pruebas cuando escriben su código de
producción.
 Las pruebas se integran en el proceso de integración continua y
construcción lo que rinde una plataforma altamente estable para el
desarrollo futuro.
 construye un proceso de diseño evolutivo que se basa en refactorar un
sistema simple en cada iteración.
 Todo el diseño se centra en la iteración actual y no se hace nada
anticipadamente para necesidades futuras.
 El resultado es un proceso de diseño disciplinado, lo que, es más,
combina la disciplina con la adaptabilidad de una manera que
indiscutiblemente la hace la más desarrollada entre todas las
metodologías adaptables.

METODOLOGÍA SCRUM
Scrum es una metodología ágil y flexible para gestionar el desarrollo de
software, cuyo principal objetivo es maximizar el retorno de la inversión para
su empresa (ROI). Se basa en construir primero la funcionalidad de mayor
valor para el cliente y en los principios de inspección continua, adaptación,
auto-gestión e innovación.

¿Cuándo se utiliza?
Con Scrum el cliente se entusiasma y se compromete con el proyecto dado que
lo ve crecer iteración a iteración. Asimismo, le permite en cualquier
 momento realinear el software con los objetivos de negocio de su empresa,
ya que puede introducir cambios funcionales o de prioridad en el inicio de
cada nueva iteración. Esta metódica de trabajo promueve la innovación,
motivación y compromiso del equipo que forma parte del proyecto, por lo
que los profesionales encuentran un ámbito propicio para desarrollar sus
capacidades.

BENEFICIOS

Cumplimento de expectativas: El cliente establece sus expectativas

indicando el valor que le aporta cada requisito / historia del proyecto, el
equipo los estima y con esta información el Product Owner establece su
prioridad.
Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de
requerimientos generados por necesidades del cliente o evoluciones del
mercado. La metodología está diseñada para adaptarse a los cambios de
requerimientos que conllevan los proyectos complejos.
 Reducción del Time to Market: El cliente puede empezar a utilizar las
funcionalidades más importantes del proyecto antes de que esté finalizado
por completo
 Mayor calidad del software: La metódica de trabajo y la necesidad de
obtener una versión funcional después de cada iteración, ayuda a la
obtención de un software de calidad superior.
 Mayor productividad: Se consigue entre otras razones, gracias a la
eliminación de la burocracia y a la motivación del equipo que proporciona el
hecho de que sean autónomos para organizarse.
 Maximiza el retorno de la inversión (ROI): Producción de software
únicamente con las prestaciones que aportan mayor valor de negocio
gracias a la priorización por retorno de inversión.
 Predicciones de tiempos: Mediante esta metodología se conoce la
velocidad media del equipo por sprint (los llamados puntos historia), con lo
que consecuentemente, es posible estimar fácilmente para cuando se
 dispondrá de una determinada funcionalidad que todavía está en el
Backlog.
 Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de
más valor en primer lugar y de conocer la velocidad con que el equipo
avanza en el proyecto, permite despejar riesgos eficazmente de manera
anticipada.

METODOLOGÍA RUP

El RUP es un armazón de proceso y como tal puede acomodar una gran

variedad de procesos. el RUP puede usarse en un estilo muy tradicional de
cascada o de una manera ágil. Como resultado usted puede usar el RUP
como un proceso ágil, o como un proceso pesado – todo depende de cómo
lo adapte a su ambiente.
El proceso de ciclo de vida de RUP se divide en cuatro fases bien conocidas
llamadas Incepción, Elaboración, Construcción y Transición. Esas fases se
dividen en iteraciones, cada una de las cuales produce una pieza de
software demostrable. La duración de cada iteración puede extenderse
desde dos semanas hasta seis meses. Las fases son:
1. Incepción. - Significa "comienzo",Se especifican los objetivos del ciclo de
vida del proyecto y las necesidades de cada participante. Esto entraña
 establecer el alcance y las condiciones de límite y los criterios de
aceptabilidad. Se identifican los casos de uso que orientarán la
funcionalidad.
2. Elaboración. - Se analiza el dominio del problema y se define el plan del
proyecto. RUP presupone que la fase de elaboración brinda una
arquitectura suficientemente sólida junto con requerimientos y planes
bastante estables.
3. Construcción. - Se desarrollan, integran y verifican todos los componentes y
rasgos de la aplicación. RUP considera que esta fase es un proceso de
manufactura, en el que se debe poner énfasis en la administración de los
recursos y el control de costos, agenda y calidad
4. Transición. - Comienza cuando el producto está suficientemente maduro
para ser entregado. Se corrigen los últimos errores y se agregan los rasgos
pospuestos.
RUP define algunas prácticas comunes:
 Desarrollo iterativo de software. Las iteraciones deben ser breves y
proceder por incrementos pequeños. Esto permite identificar riesgos y
problemas tempranamente y reaccionar frente a ellos en consecuencia.
 Administración de requerimientos. Identifica requerimientos cambiantes y
postula una estrategia disciplinada para administrarlos.
 Uso de arquitecturas basadas en componentes. La reutilización de
componentes permite asimismo ahorros sustanciales en tiempo, recursos y
esfuerzo.
 Modelado visual del software. Se deben construir modelos visuales,
porque los sistemas complejos no podrían comprenderse de otra manera.
Utilizando una herramienta como UML, la arquitectura y el diseño se pueden
especificar sin ambigüedad y comunicar a todas las partes involucradas.
 Prueba de calidad del software. RUP pone bastante énfasis en la calidad
del producto entregado.
 Control de cambios y trazabilidad. La madurez del software se puede
medir por la frecuencia y tipos de cambios realizados.
CÁLCULO DE RESULTADOS DE COSTOS DE DESARROLLO DEL
SOFTWARE
La estimación de los costos de desarrollo de software es un factor muy
importante en el análisis de los proyectos informáticos, constituye un tema
estratégico contar con indicadores para medir el costo de los mismos,
garantizando la eficiencia, excelencia, calidad y la competitividad. El análisis
de costo es el proceso de identificación de los recursos necesarios para
llevar a cabo el trabajo o proyecto eficientemente.
La evaluación del costo determina la calidad y cantidad de los recursos
necesarios en términos de dinero, esfuerzo, capacidad, conocimientos y
tiempo incidiendo en la gestión empresarial. En la actualidad existen un
conjunto de métricas que no se utilizan, y que pueden ser aplicables a
cualquier tipo de proyecto de software para calcular el costo de los mismos.
Esta investigación propone el diseño de un conjunto de métricas para calcular
el costo en el proceso de desarrollo de software. Las métricas son lo más
general posible y no están vinculadas a una metodología de software en
específico, sino a evaluar el software como un producto comercial.
Para seleccionar las métricas se tuvo en cuenta la influencia que tienen las
mismas para la toma de decisiones aportando elementos claves para el
análisis de los proyectos como son aptitud adecuada del jefe del proyecto
en relación con la comprensión de la tecnología, destreza administrativa,
destreza personal para comunicarse. Capacidad para tomar decisiones,
relaciones positivas con beneficiarios, participación del equipo de proyecto
en el análisis, recursos adecuados. Valoración de los ingresos y costos,
apoyo administrativo y gerencial y el compromiso que debe existir entre los
integrantes del proyecto.

CÁLCULO DE LOS COSTOS EN EL DESARROLLO DE SOFTWARE

Cuando la necesidad de utilizar el software aumenta en cualquier actividad
humana, mayor es también la complejidad y dificultad de implementación
que este adquiere. Aunque cada vez existan más técnicas que facilitan el
diseño y desarrollo de los sistemas, las nuevas exigencias de los usuarios y
los nuevos dominios de aplicación generan nuevos problemas. Creando la
 necesidad de prestar cada vez más atención a los procesos de
planificación, medición y estimación de diversos parámetros software, antes
de comenzar con el desarrollo de la aplicación.
Esta necesidad convierte a la gestión de proyecto de software en una tarea de
vital importancia, siendo la estimación del esfuerzo uno de sus puntos
claves, el tiempo y costos monetarios, necesarios para la finalización de
estos productos. Sin unas buenas estimaciones de estos parámetros,
comienzan a surgir imprevistos y problemas durante el desarrollo que
imposibilitan la entrega del producto final en el plazo acordado, con sus
consiguientes aumentos en los gastos y pérdidas económicas.

El proceso de estimación del costo de un producto software está formado por

un conjunto de técnicas y procedimientos que se usan en la organización
para poder llegar a una predicción fiable. Este es un proceso continuo, que
debe ser usado y consultado a lo largo de todo el ciclo de vida del proyecto.
Se divide en los siguientes pasos.
Estimación del tamaño, estimación del costo y del esfuerzo, estimación de la
programación temporal, estimación de la cantidad de recursos
computacionales, ausencias de riesgos, inspección y aprobación, redacción
de informes de estimación, medición y perfeccionamiento del proceso.
A continuación, se muestra la interacción entre las diferentes etapas del
proceso de estimación del software.
Actividades de la estimación de proyectos software

Estas estimaciones están basadas en probabilidades debido a la influencia de

factores externos de difícil control. Además de estas probabilidades, es
necesario recurrir a información histórica, que debe ser fácilmente accesible
y disponible para la organización en cualquier momento. Es importante
resaltar la importancia de una buena determinación de los requisitos, un
proyecto no puede ser exitoso sin una especificación correcta y exhaustiva
de los requerimientos.
La cantidad de esfuerzo y tiempo dedicada a la estimación depende del tamaño
del proyecto, del equipo de desarrollo y del objetivo a cumplir. La naturaleza
del proyecto y el entorno en el que se desarrolla son factores determinantes
en esta tarea, y afectan en gran medida al método de estimación que se
utilice.
Existen dos maneras diferentes de estimar el presupuesto y el tiempo para un
proyecto software: usando modelos de costo y usando razonamiento
basado en similitud. En ambas opciones es necesario recurrir a información
histórica y de proyectos anteriores previamente almacenados en bases de
datos. Existen cuatro puntos fundamentales sobre los que se apoya la
estimación:

 Las consideraciones y opiniones de los profesionales de la materia, basada

en la experiencia y la madurez de los gestores de proyecto, los cuales
tendrán que adivinar y predecir el tiempo de realización del proyecto o su
costo.
 La participación de expertos, cuyas opiniones no deben ser consideradas y
abordadas como las de los profesionales y gestores de proyecto, ya que los
expertos no pertenecen a la organización y pueden estar o no familiarizados
con las prácticas propias de la organización.
 Por último, el empleo de fórmulas y funciones, que implica la existencia de
datos cuantitativos que representen una buena aproximación a la
estimación.
 La utilización de factores estándar de tiempos, calculados y establecidos a
partir de proyectos anteriores.
Las técnicas de estimación son una forma de resolución de problemas donde
en la mayoría de los casos, el problema a resolver es demasiado complejo
 para considerarlo como una sola parte. Por esta razón, se propone
descomponer el problema, planteándolo como un conjunto de pequeños
problemas, lo cuales se estiman individualmente, en cada fase del proceso
de desarrollo de software.
La estimación debe tener en cuenta cada requerimiento del software, los cuales
conformaran la estimación total del sistema. Se deben analizar varias
técnicas de estimación, así como la utilización de algunas de las métricas
del software, la estimación debe ser refinada a medida que se conozca más
del proyecto el objetivo final es realizar una estimación lo más cercana
posible a la realidad. A continuación, se muestran las etapas a estimar en el
proceso de desarrollo de software.

PROCESO DE DESARROLLO DE SOFTWARE

La idea de los modelos de estimación es la de proporcionar sistemas y

métodos para proceder a realizar el cálculo de los costos en la construcción
de software de aplicación, la mayor parte del costo del software se
encuentra hoy en el costo de las horas de análisis, diseño, programación y
prueba que se deben utilizar para obtenerlo. Por ello, cuando aquí se habla
de estimación de costos se hace referencia, mayormente, al esfuerzo
humano que ha sido necesario, es decir, a las horas de trabajo requeridas
para construir el software, aunque cada etapa sea de vital importancia,
incluso desde el inicio se debe tener una idea preliminar que luego se va
refinando.
Cabe resaltar que durante la etapa de análisis de requerimientos la meta
primaria es identificar y documentar lo que en realidad se necesita, en una
forma que claramente se lo comunique al cliente y a los miembros del
equipo de desarrollo.
La estimación de costos en el desarrollo de software solo es factible haciendo
uso de un conjunto de métricas destinadas a conocer o estimar el tamaño,
tiempo, recursos, personas necesarias para desarrollar a continuación se
describen algunas de ellas.

MÉTRICAS DE DESARROLLO DE SOFTWARE

En el campo de la ingeniería de software, se suele hablar indistintamente de
“métricas” y de “medidas”, pero sin embargo existen diferencias entre estos
términos. Una medida indica cuantitativamente algún atributo de proceso o
de producto (extensión, cantidad, dimensiones, capacidad, tamaño, etc.).
Una métrica es definida por el glosario de estándares del IEEE (Institute of
Electrical and Electronics Engineers) (IEEE Standard Glossary of Software
Engineering Terminology, 1993) como una “medida cuantitativa del grado
en que un sistema, componente o proceso posee un atributo determinado”.
Si se recopila un solo tipo de datos, como por ejemplo el número de errores
dentro de un componente, se ha establecido una medida.
Una métrica de software relaciona de alguna manera las medidas individuales,
podría tratarse del número de errores encontrados en cada revisión o
prueba (Pressman, 1998).
Los ingenieros de software, a partir de las medidas, elaboran métricas que les
proporcionan información para poder controlar el proceso o el proyecto de
software. Aquí radica la diferencia entre estos términos.
La medición es muy común en el mundo de la ingeniería. Se mide potencia de
consumo, pesos, dimensiones físicas, temperaturas, voltajes, señales de
ruidos por mencionar algunos aspectos. La medición se aleja de lo común
en el mundo de la ingeniería del software, siendo más compleja,
encontrando dificultades a la hora de medir y cómo se van a evaluar las
medidas, hay varias razones para medir un producto, para indicar la calidad
del producto, para evaluar la productividad de los desarrolladores, para
 evaluar los beneficios en términos de calidad, derivados del uso de nuevos
métodos y herramientas de la ingeniería de software, para establecer una
línea de base para la estimación, para medir el costo del proyecto entre
otras.
Las mediciones del mundo físico pueden englobarse en dos categorías:
medidas directas y medidas indirectas.
 Medidas Directas. En el proceso de ingeniería se encuentran el costo, y el
esfuerzo aplicado, las líneas de código producidas, velocidad de ejecución,
el tamaño de memoria y los defectos observados en un determinado
período de tiempo.
 Medidas Indirectas. Se encuentra la funcionalidad, calidad, complejidad,
eficiencia, fiabilidad, facilidad de mantenimiento, etc.
En esta investigación se estudian un conjunto de métricas para lograr el cálculo
de las medidas lo más exacto posible se muestran a continuación.
 Métricas del software: Son las que están relacionadas con el desarrollo del
software como funcionalidad, complejidad, eficiencia.
 Métricas técnicas: Se centran en las características del software por
ejemplo: la complejidad lógica, el grado de modularidad. Mide la estructura
del sistema, el cómo está hecho.
 Métricas de productividad. Se centran en el rendimiento del proceso de la
ingeniería del software. Es decir que tan productivo va a ser el software que
voy a diseñar.
 Métricas orientadas a la persona. Proporcionan medidas e información
sobre la forma que la gente desarrolla el software de computadoras y sobre
todo el punto de vista humano de la efectividad de las herramientas y
métodos. Son las medidas que voy a hacer de mi personal que va a realizar
el sistema.
 Métricas orientadas al tamaño. Es para saber en qué tiempo voy a terminar
el software y cuántas personas voy a necesitar. Son medidas directas al
software y el proceso por el cual se desarrolla, si una organización de
software mantiene registros sencillos.
Estas métricas se unen para conformar las técnicas de estimación las cuales
constituyen una herramienta de trabajo. Son necesarias para unificar
criterios de medición de tamaño, tanto para poder planificar y controlar
proyectos, como para realizar estudios y análisis entre proyectos en pro de
la mejora de procesos (Park, 1992). A continuación, se muestran las
técnicas más utilizadas.
TÉCNICAS DE ESTIMACIÓN DE COSTOS EN EL DESARROLLO DE SOFTWARE
Se han desarrollado varias técnicas de estimación para el desarrollo de
software estableciendo de antemano el ámbito del proyecto, usar las
métricas del software sirven de base para la realización de estimaciones y
desglosar el proyecto en partes más pequeñas que se estiman
individualmente (Angelis L & Stamelo, 2000).
Debido al crecimiento en la industria del software y siendo una actividad
compleja la estimación de costos, las compañías dedicadas a ofrecer
diferentes herramientas de estimación de costos en el mercado han
aumentado. A partir del 2005, algunas de esas herramientas de estimación
son: COCOMO II, CoCots, CoStar, CostModeler, CostXpert, SoftCost.
Mientras estos instrumentos de estimación fueron desarrollados por empresas
diferentes y no son idénticos, ellos realmente tienden a proporcionar un
núcleo de funciones comunes. Los rasgos principales de instrumentos de
estimación de software comerciales incluyen estos atributos estimación de
fiabilidad y calidad, análisis de valor y riesgo, retorno de inversión,
posibilidad de compartir datos con herramientas de administración de
proyectos, medios de medición para reunir datos históricos, costo y tiempo
para completar estimaciones que combinan datos históricos con datos
proyectados, apoyo para evaluaciones de procesos de software, análisis
estadístico de múltiples proyectos.
Cuando se planifica un proyecto se tienen que obtener estimaciones del
esfuerzo humano requerido, de la duración cronológica del proyecto y del
costo. En la mayoría de los casos las estimaciones se hacen valiéndose de
la experiencia pasada como única guía. Contar con buenas métricas
asegura una correcta correlación con el esfuerzo del proyecto, y facilita la
estimación del mismo.
Aunque cabe resaltar que “No hay modelos de costo transportables. Si esperas
que alguien en otro lugar desarrolle un conjunto de fórmulas que puedas
utilizar para prever el coste en tu propia instalación, probablemente tendrás
que esperar para siempre.” (Marco, 1982)
Los objetivos de la estimación de proyectos son reducir los costos e
incrementar los niveles de servicio y de calidad. Midiendo determinados
aspectos del proceso de software se puede tener una visión de alto nivel de
lo que sucederá durante el desarrollo. Las mediciones de procesos
anteriores permiten realizar predicciones sobre los actuales. Las mediciones
de atributos de proceso en fases iniciales del desarrollo permiten realizar
predicciones sobre fases posteriores.
La evaluación del proceso conduce a la toma de decisiones antes del comienzo
del desarrollo, durante el proceso de desarrollo, durante la transición del
producto al cliente y a lo largo de la fase de mantenimiento.
La estimación de costos implica la realización de predicciones sobre la cantidad
más probable de esfuerzo, tiempo y niveles de personal que se requieren
para construir un sistema de software. Estas se realizan a lo largo de todo el
ciclo de vida del software.
Las estimaciones preliminares se requieren para hacer una oferta o determinar
la viabilidad de un proyecto, son las más difíciles de hacer y las menos
exactas.

EXISTEN FORMAS DE REALIZAR LA ESTIMACIÓN DE LOS COSTOS

ÉSTAS PUEDEN SER MEDIANTE:
La opinión de expertos: Un desarrollador o gestor describe los parámetros del
proyecto y los expertos hacen estimaciones basadas en su experiencia.
Técnica Delphi: Permite sistematizar y mejorar la opinión de los expertos
consultados.
Analogía: Enfoque más formal que el de la opinión de expertos. Los expertos
comparan el proyecto propuesto con uno o más proyectos anteriores
intentando encontrar similitudes y diferencias particulares.
Base Histórica de proyectos.
Técnicas de descomposición: Las estimaciones se hacen sobre cada
componente en que se descompone el software o sobre tareas de bajo nivel
en que se descomponen las tareas. Las estimaciones de bajo nivel se
combinan para producir una estimación del proyecto completo. Es decir, el
costo total del proyecto es el resultado de sumar las estimaciones de todos
 los componentes en los que se ha dividido el proyecto. A continuación, se
exponen algunas de las técnicas más utilizadas en el mundo.

1. COCOMO
El Modelo COCOMO Creado por Barry Boehm en 1981. Su nombre significa
COnstructiveCOst MOdel (Modelo constructivo de costo) constituye una
jerarquía de modelos de estimación para el software. La jerarquía está
constituida por los siguientes modelos (COCOMO Model definition manual.,
1990).
 COCOMO básico. Calcula el esfuerzo y el costo del desarrollo en función
del tamaño del programa estimado en LOC.
 COCOMO intermedio. Calcula el esfuerzo del desarrollo en función del
tamaño del programa y un conjunto de conductores de costo que incluyen la
evaluación subjetiva del producto, del hardware, del personal y de los
atributos del proyecto.
 COCOMO detallado. Incorpora las características de la versión intermedia y
lleva a cabo una evaluación del impacto de los conductores de costo en
cada fase (análisis, desarrollo, etc.) del proceso.
COCOMO es una herramienta basada en las líneas de código la cual le hace
muy poderoso para la estimación de costos y no como otros que solamente
miden el esfuerzo en base al tamaño. Es necesario para un administrador
de proyectos una herramienta de estimación de costos; y esta herramienta
puede estar relacionada con COCOMO ya que esta técnica representa uno
de los más completos modelos empíricos para la estimación de software
(Bumett, 1998).
Una de las deficiencias detectadas en el modelo COCOMO es que para el
análisis del costo del proyecto solo analizan el salario del desarrollador sin
tener en cuenta otros elementos de gastos que inciden en los costos del
proyecto de software.

2. COCOMO II
COCOMO II es un modelo que permite estimar el costo, el esfuerzo y el tiempo
cuando se planifica una nueva actividad de desarrollo software, y está
asociado a los ciclos de vida modernos. Fue desarrollado a partir de
COCOMO, incluyendo actualizaciones y nuevas extensiones más
 adecuadas a los requerimientos de los ingenieros software (Heemstra,
1992).

Está construido para satisfacer aquellas necesidades expresadas por los

estimadores de software, como por ejemplo el apoyo a la planificación de
proyectos, la previsión de personal del proyecto, replanificación,
seguimiento, negociaciones de contrato y la evaluación del diseño.
Los factores de costo describen aspectos relacionados con la naturaleza del
producto, hardware utilizado, personal involucrado, y características propias
del proyecto. El conjunto de factores de escala explica los ahorros y
pérdidas producidos a medida que un proyecto de software incrementa su
tamaño. El usar un modelo u otro depende del nivel de detalle del proyecto,
de la fidelidad requerida de las estimaciones, de la definición de los
requerimientos y de los detalles de la arquitectura (Gause & Weinberg,
1989).
3. LÍNEAS DE CÓDIGO Y PUNTOS DE FUNCIÓN
Las métricas para puntos de función están basadas en las guías
proporcionadas por el International Function Point User Group (IEPUG,
1994). Los puntos de función procuran cuantificar la funcionalidad de un
sistema de software. La meta es obtener un número que caracterice
completamente al sistema. Son útiles estimadores ya que están basados en
información que está disponible en las etapas tempranas del ciclo de vida
del desarrollo de software.
Los datos de líneas de código (LDC) y los puntos de función (PF) se emplean
de dos formas durante la estimación del proyecto de software:
 Variables de estimación, utilizadas para calibrar cada elemento del software.
 Métricas de base, recogidas de anteriores proyectos utilizadas junto con las
variables de estimación para desarrollar proyecciones de costo y esfuerzo.
Estas técnicas son diferentes, pero tienen características comunes. El
planificador del proyecto comienza con una declaración restringida del
ámbito del software y, a partir de esa declaración, intenta descomponer el
software en pequeñas subfunciones que pueden ser estimadas
individualmente. Entonces, estima las LDC o PF (la variable de estimación)
 para cada subfunción. Luego, aplica las métricas básicas de productividad a
la variable de estimación apropiada y deriva el costo y el esfuerzo para la
subfunción. Combinando las estimaciones de las subfunciones se produce
la estimación total para el proyecto entero.
Difieren en el nivel de detalle que requiere la descomposición, cuando se utiliza
LDC como variable de estimación, la descomposición funcional es
absolutamente esencial y, a menudo, se lleva hasta considerables niveles
de detalle. Actualmente esta técnica no refleja el costo real de un proyecto
por el análisis de sus líneas de código, puede existir un proyecto con pocas
líneas de código y que el esfuerzo, tiempo, recursos humanos y materiales
dedicados al mismo sea superior a otro proyecto que fuese desarrollado con
anterioridad y cuente con más líneas de código.
4. Técnicas Delphi
Creada en los años cuarenta en EE.UU. Se comienza a utilizar en el campo del
software a partir de 1981 por Barry Boehm. Los pasos a seguir son:
Un coordinador proporciona a cada experto una especificación del proyecto
propuesto y un impreso para expresar su opinión. Los expertos rellenan el
impreso de manera anónima. Pueden hacer preguntas al coordinador, pero
no entre ellos. El coordinador ofrece a cada experto el valor medio de las
opiniones recogidas. Se pide una nueva estimación anónima indicando las
razones de las posibles modificaciones (Boehm, 1981).
Se repite el proceso de recogida de opiniones hasta llegar a un consenso. No
se realizan reuniones en grupo en ningún momento.

Delphi de banda ancha: Refinamiento de la técnica Delphi propuesta por

Barry Boehm. Los pasos a seguir son:
1) El coordinador proporciona a cada experto una especificación del proyecto
propuesto y un impreso para expresar su opinión.
2) El coordinador reúne a los expertos para que intercambien puntos de vista
sobre el proyecto.
3) Los expertos rellenan el impreso de manera anónima.
4) El coordinador ofrece a cada experto el valor medio de las opiniones
recogidas. Se pide una nueva estimación anónima, sin indicar las razones
de las posibles modificaciones.
5) El coordinador convoca una reunión para que los expertos discutan las
razones de las diferencias entre sus estimaciones.
6) Se rellenan anónimamente los impresos y se repite los puntos 4, 5 y 6 hasta
llegar a un consenso.
La ventaja principal de esta técnica es que recoge la opinión experta sobre el
proyecto actual basada en experiencias anteriores difíciles de evaluar por
otros medios (características especiales del personal, peculiaridades del
proyecto).
El principal inconveniente se encuentra en la subjetividad o inexperiencia de las
personas elegidas en la consulta.

CONCLUSIONES
El cálculo de los costos en el desarrollo de software constituye una herramienta
necesaria para garantizar el éxito en la gestión del producto informático
aportándole calidad al servicio desde su planificación hasta la entrega final.
Las métricas propuestas instituyen un novedoso instrumento para calcular el
precio de venta del producto de software, partiendo de costos que miden, lo
intangible, el conocimiento, la comunicación del equipo de especialistas, el
ambiente de trabajo, aportándole valor agregado al producto final.

RECOMENDACIONES
Se recomienda implementar las métricas propuestas para mejorar el cálculo del
costo en la actividad de desarrollo.
Continuar el estudio del tema, para profundizar en nuevas técnicas de
estimación de software.
Aplicar las métricas desde la planificación del proyecto y mantener el proceso
de mejora continua durante todas las etapas del desarrollo de software.
BIBLIOGRAFIA
 Aparicio A. 2012. Ingeniería en Software. (En línea). Consultado el
15 de abr. 2015. Formato PDF. Disponible en:
http://datateca.unad.edu.co/contenidos/301404/301404.pdf
 Presman, R. 2010. Ingeniería en Software Un Enfoque Práctico:
introducción a la introducción de ingeniería en software. México.
McGraw-Hill Companies. 7ed. p 1:13.
 Sommerville, I. 2005. Ingeniería del software. Pearson Educación.
Madrid.
 https://www.monografias.com/trabajos102/gestion-proyectos-
software/gestion-proyectos-software
 https://www.monografias.com/trabajos108/modelos-del-proceso-
del-software/modelos-del-proceso-del-software
 http://avellano.usal.es/~mmoreno/APITema2.pdf
 https://www.fing.edu.uy/tecnoinf/mvd/cursos/ingsoft/material/
teorico/is03b-GestProy.pdf
 https://www.gestiopolis.com/estimacion-de-costos-de-desarrollo-
de-software/