1

I. INTRODUCCIÓN
 2

En este trabajo se pretende explicar el tema de desarrollo de software a

la medida, su definición y características, además, de observar las diferencias
entre este último y el software comercial.
Se abordaran además los temas de la metodología y de ciclo de vida,
así como las etapas que componen cada uno de los anteriores tópicos, la
necesidad de adoptarlos, cuales son los tipos que se pueden adoptar, y su
definición.
Se hablara también de las ventajas y desventajas de cada modelo que
se vaya a utilizar.
Se pretende que el usuario forme un criterio acerca del software a la
medida y pueda comprender cuando esta en frente de un caso así, o cuando
tendría la necesidad, de desarrollar o pedir el desarrollo de un sistema de este
tipo.
Se quiere que con el trabajo se aclaren dudas al respecto del tema, y en
general que todos aprendan del tema que se esta tratando.

De forma general se tiene lo siguiente:

1. Tema:
Desarrollo de software a la medida

2. Objetivos

2.1. Objetivo General

Desarrollar e investigar el tema de Desarrollo de software a la medida,

realizando una entrevista y mencionando los conceptos más importantes
referentes al tema.

2.2. Objetivos Específicos

 Efectuar un análisis sobre el tema desarrollo de software a la

medida.
 Determinar las preferencias de las empresas por este tipo de
sistemas en la actualidad
 3

3. Justificación.
El tema de desarrollo de software a la medida es un tema que se ha
presentado en la actualidad con mucha fuerza, es por esta razón que se
observan gran cantidad de empresas en este sector.
Se ha observado que los usuarios muchas veces prefieren un producto
que se adapte a sus propias necesidades, pero también existe la otra parte de
los usuarios que utilizan simplemente el software comercial.
Es por las razones anteriores que se decide realizar este trabajo con el
fin de observar y aprender las características del proceso de desarrollo de
software a la medida, además de determinar las preferencias de las empresas
sobre pedir o contratar a alguien que les desarrolle un software a la medida o
simplemente utilizar un software comercial.

4. Alcances y Limitaciones

4.1. Alcances.

El presente trabajo se considera de gran importancia ya que permite dar

a conocer información de gran importancia, además, de que permite entender
aspectos más profundos acerca del tema.
Permite a las personas formar un criterio más real de la situación con
respecto del tema, ya que poseen la información para crearlo.

4.2. Limitaciones.

El principal inconveniente que se presenta en este trabajo es el poco

conocimiento del tema, de ahí la investigación, además que si bien existen
muchas empresas que realizan este tipo de software a la medida a ellas no les
gusta revelar detalles.
 4

II. MARCO TEÓRICO.

 5

El desarrollo de software a la medida se refiere ampliamente al diseño,

fabricación y mantenimiento de sistemas de software para una situación
específica, en la cual se deben cumplir con requerimientos previamente
establecidos por un cliente. Al desarrollo de software a la medida desde un
enfoque sistemático, disciplinado y cuantificable se le conoce como la
Ingeniería del Software, la cual se define como “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“. (Bohem, 1976).

Metodología

Siguiendo una metodología en el desarrollo de software se busca de una

manera sistemática, realizar, gestionar y administrar un proyecto de forma tal
que se tengan altas probabilidades de éxito. Lo que se busca al guiarse con
una metodología es projilidad, corrección, y control en cada etapa del
desarrollo de un programa.
La ingeniería de software requiere llevar a cabo numerosas tareas,
dentro de etapas como las siguientes:
 Planificación: planeamiento detallado que guíe la gestión del proyecto,
temporal y económicamente.

 Implementación: conjunto de actividades que componen la realización

del producto.

 Puesta en producción: el proyecto entra en etapa de definición, donde es

presentado al cliente, sabiendo que cumple los requerimientos
solicitados y funciona correctamente.

En complemento a las tres etapas anteriormente citadas, existen otras dos:

• Inicio: este es el nacimiento de la idea. Aquí se definen los objetivos del

proyecto y los recursos necesarios para su implementación. El inicio
define hacia donde queremos ir, no como queremos ir.
 6

• Control en producción: control del producto, analizando como el

producto difiere o no de los requerimientos originales e iniciando de ser
necesario las correcciones respectivas.

Objetivos de cada etapa

• Expresión de necesidades: tiene como objetivo el armado de un

documento que en el cual se reflejan los requerimientos y
funcionalidades que ofrecerá el sistema al usuario.

• Especificaciones: se trata de la formalización de los requerimientos, se

toma como base el documento anterior.

• Análisis: se tiene una descripción clara del producto a construir, que

funcionalidades aportara y que comportamiento tendrá.

• Diseño: definir relaciones y entidades de las bases de datos y

seleccionar el lenguaje de programación a utilizar.

• Implementación: se empiezan a codificar algoritmos y estructuras de

datos en el lenguaje antes definido. En el caso de modelo de ciclo de
vida Code&Fix, se empieza meramente por esta etapa, saltándose las
etapas de especificaciones, análisis y diseño con la siguiente perdida de
control sobre la gestión del proyecto.

• Debugging: el objetivo de esta etapa es garantizar que el programa no

contenga errores de diseño o codificación.

• Validación: esta etapa tiene como objetivo la verificación de que el

sistema desarrollado cumple con los requerimientos expresados
inicialmente por el cliente y que han dado lugar al presente proyecto.

• Evolución: también conocida como Mantenimiento y evolución, se le

asigna el agregado de nuevas funcionalidades (evolución) y la
corrección de errores que surgen (mantenimiento).
 7

Clasificación de las metodologías

- Metodologia estructurada: la orientacion de esta metodologia se dirige
hacia los procesos que intervienen en el sistema a desarrolar, es decir,
cada funcion a realizar por el sistema se descompone en pequeños
módulos individuales; ya es más fácil resolver problemas pequeños, y
luego unir cada una de las soluciones, que abordar de inmediato un
problema grande.

- Metodología orientada a objetos: a diferencia de la metodología

mencionada anteriormente, ésta no comprende los procesos como
funciones sino que arma módulos basados en componentes, es decir,
cada componente es independiente del otro. Esto nos permite que el
código sea reutilizable. Es más fácil de mantener porque los cambios
están localizados en cada uno de estos componentes.

Modelos de Ciclo de Vida

El ciclo de vida del software describe el desarrollo de software, desde la

fase inicial hasta la fase final. Su propósito es definir las distintas fases
intermedias que se requieren para validar el desarrollo de la aplicación, es
decir, para garantizar que el software cumpla los requisitos para la aplicación y
verificación de los procedimientos de desarrollo.

Las principales diferencias entre distintos modelos de ciclo de vida están

divididas en tres grandes visiones:
- El alcance del ciclo de vida, que depende de hasta donde se desee
llegar con el proyecto.
 8

- La cualidad y cantidad de las etapas en que se dividirá el ciclo de vida.

- La estructura y la sucesión de las etapas, se existe realimentación entre

ellas y si hay libertad de iterar.

Ciclo de vida lineal.

Es el más sencillo de todos los modelos. Consiste en descomponer la

actividad global del proyecto en etapas separadas que son realizadas de
manera lineal, es decir, cada etapa se realiza una sola vez. Con un ciclo de
vida lineal es muy fácil dividir las tareas, y preveer los tiempos (sumando
linealmente los de cada etapa).
Las actividades de cada una de las etapas mencionadas deben ser
independientes entre sí, es decir, que es condición primordial que no haya
retroalimentación entre ellas, aunque sí pueden admitirse ciertos supuestos de
realimentación correctiva. Se requiere que se conozca desde el primer
momento lo que va a ocurrir en cada una de las distintas etapas antes de
comenzarla, minimizando asi las posibilidades de error durante la codificacion y
reduciendo al minimo la necesidad de requerir informacion del cliente o del
usuario.

Fig 1. Ciclo de vida en línea.

Se destaca como ventaja la sencillez de su gestion y administracion

tanto economica como temporal, ya que se acomoda perfectamente a
 9

proyectos internos de una empresa para programas muy pequeños de altas,

bajas y moficicaciones sobre un conjunto de datos. Tiene como desventaja que
es muy costoso retomar una etapa anterior al detectar una falla.
Es válido tomar este ciclo de vida cuando algún sector pequeño de una
empresa necesita llevar un registro de datos acumulativos, sin necesidad de
realizar procesos sobre ellos más que una consulta simple, es decir,
almacenamiento de datos.

Ciclo de vida en cascada puro.

Este modelo de ciclo de vida fue propuesto por Winston Royce en el año
1970. Es un ciclo de vida que admite iteraciones, contrariamente a la creencia
de que es un ciclo de vida secuencial como el lineal. Despues de cada etapa se
realiza una o varias revisiones para comprobar si se puede pasar a la siguiente.
Es un modelo rígido, poco flexible, y con muchas restricciones.

Fig 2. Ciclo de Vida en Cascada

La necesidad de conocer los requerimiento al principio del proyecto es

primordial al elegir este modelo de ciclo de vida a pesar de permitir iteraciones.
 10

Una de sus ventajas, ademas de su planificación sencilla, es la de

proveer un producto con un elevado grado de calidad sin necesidad de un
personal altamente calificado. Entre los inconvenientes se pueden considerar:
la necesidad de contar con todos los requerimietnos (o la mayoría) al comienzo
del proyecto, y, si se han cometido errores y no se detectan en la etapa
inmediata siguiente, es costoso y dificil volver atrás para realizar la corrección
anterior.
Además, los resultados no los veremos hasta que no estemos en las
etapas finales del ciclo, por lo que, cualquier error detectado nos trae retraso y
aumenta el costo del desarrollo en función del tiempo que insume la correccion
de éstos.
Es un ciclo adecuado para los proyectos en los que se dispone de todos
los requerimientos al comienzo, para el desarrollo de un producto con
funcionalidades conocidas o para proyectos, que aún siendo muy complejos, se
entienden perfectamente desde el principio.
Se evidencia que es un modelo puramente teórico, ya que el usuario
rara vez mantiene los requerimientos iniciales y existen muchas posibilidades
de que debamos retomar alguna etapa anterior.
Hoy en día, solo se le cita como ejemplo bibliográfico, pues a principios
de los 90 fue ampliamente criticado en el retardo en entregar partes del
producto, su metodología para la correción de errores, su obstinación por exigir
requerimientos previos completos, y su alta rigidez.

Ciclo de vida en V.

Este ciclo fue diseñado por Alan Davis, y contiene las mismas etapas
que el ciclo de vida en cascada puro. A diferencia de aquél, a éste se le
agregaron dos subetapas deretroalimentación entre las etapas de análisis y
mantenimiento, y entre las de diseño y debugging.
 11

Fig 3. Ciclo de vida en V

Las ventajas y desventajas de este modelo son las mismas del ciclo
anterior, con el agregado de los controles cruzados entre etapas para lograr
una mayor corrección.
Podemos utilizar este modelo de ciclo de vida en aplicaciones, que si
bien son simples, necesitan una confiabilidad muy alta. Un ejemplo claro en el
que no se pueden cometer errores es una aplicación de facturación, en la que
si bien los procedimientos vistos individualmente son de codificación e
interpretación sencilla, la aplicación en su conjunto puede tener matices
complicados.

Ciclo de Vida tipo Sashimi.

El ciclo de vida tipo Sashimi podría ser considerado como una variación
del ciclo de vida en cascada puro, en el cual las diferentes etapas pueden ser
solapadas, permitiendo así aumentar la eficiencia mediante la retroalimentación
entre las etapas.
Al utilizar este ciclo de vida se obtiene una ganancia de calidad en el
producto final, además de que no hace necesario una documentación detallada
para cada etapa, ya que por el mismo hecho de que estas se solapan,
comparten partes de la documentación. Entre los problemas que se presentan
al utilizar este modelo existe la dificultad de identificar el inicio y el fin de cada
 12

etapa, además de que en caso de presentarse problemas de comunicación

estos van a generar inconsistencias.

Fig 4. Ciclo de vida Sashimi

Ciclo de vida en cascada con subproyectos.

Similar al ciclo de vida en cascada, solo que en este las cascadas se

dividen en subetapas independientes que pueden ser desarrolladas en
paralelo.
Este modelo es ventajoso en el sentido de que permite que más gente
este trabajando en el al mismo tiempo, sin embargo, si surgen dependencias
entre distintas etapas podría tener que detenerse todo temporalmente, a menos
que sea gestionado correctamente, cuidando muy bien los tiempos.

Fig 5. Ciclo de vida en cascada con subproyectos.

 13

Ciclo de vida iterativo.

El ciclo de vida iterativo es otro más de los basados en el ciclo de vida

en cascada puro, este modelo tiene como fin evitar que debido a malos
entendidos, el producto final no sea lo que el cliente solicitó en la etapa de
requerimientos. Para alcanzar esto se realizan iteraciones de varios ciclos de
vida en cascada, entregando una versión mejorada, o ampliada, luego de cada
iteración. Una vez que el avance del producto fue entregado el cliente debe de
evaluar el producto, corregirlo, o proponer mejoras. Continuamente se sigue
iterando hasta que el producto final sea el requerido.
Este modelo de ciclo de vida es ideal para utilizar en aquellas
situaciones en las cuales el cliente no está completamente seguro de los
requerimientos, o estos no logran ser claramente explicados, por lo que el
modelo va creando distintos prototipos que vayan cada vez más siendo de la
aprobación del cliente. Esta también ideal para esas aplicaciones que pueden
ser implementadas paulatinamente.

Fig 6. Ciclo de vida iterativo.

Ciclo de vida por prototipos.

Al igual que en modelo anterior, el uso de los prototipos se utilizan para

validar los requerimientos en cualquier ciclo de vida. Cuando se presenta la
 14

situación de que los requerimientos no han sido detallados, entendidos o

clarificados con exactitud, se realiza primero un prototipo con especificaciones
iniciales, obteniendo así un producto parcial y provisional.
Se trata de lograr un producto intermedio para analizar como
responderán las funcionalidades previstas para el producto final. Cuando se
desea realizar un prototipo se debe evaluar la inversión y el esfuerzo de
hacerlo, para determinar que tan factible es. Se utiliza primordialmente en
proyectos donde se desconoce con exactitud los resultados posibles, o el
comportamiento de mismo, como cuando se están probando nuevas
tecnologías. Sin embargo, es sumamente costoso y la administración es
complicada.

Fig 7. Ciclo de vida por prototipos.

Ciclo de vida evolutivo.

Este modelo acepta que los requerimientos pueden cambiar en cualquier

momento. Obtener todos los requerimientos al comienzo del proyecto es
extremadamente difícil, no solo por la dificultad del usuario de transmitir su
idea, sino porque estos requerimientos evolucionan durante el desarrollo y de
está manera, surgen nuevos requerimientos a cumplir. El modelo de ciclo de
vida evolutivo afronta este problema mediante una iteración de ciclos
requerimientos-desarrollo-evaluación.
Resulta ser un modelo muy útil cuando desconocemos la mayoría de los
requerimientos iniciales, o estos requerimientos no están completos.
 15

Ejemplo: Sistema centralizado de stock-ventas-facturación.

Fig 8. Ciclo de vida evolutivo.

Ciclo de vida incremental.

Este modelo del ciclo de vida se basa en la filosofía de construir

incrementando las funcionalidades del programa.
Se realiza construyendo por módulos que cumplen diferentes funciones
del sistema. Esto permite ir aumentando gradualmente las capacidades del
software. Este ciclo de vida facilita la tarea del desarrollo permitiendo a cada
miembro del equipo desarrollar un modulo particular en el caso de que el
proyecto sea realizado por un equipo de programadores.
Es una repetición del ciclo de vida en cascada, aplicándose este ciclo en
cada funcionalidad del programa a construir. Al final de cada ciclo le
entregamos una versión al cliente que contiene una nueva funcionalidad. Este
ciclo de vida permite realizar una entrega al cliente antes de terminar el
proyecto.
El modelo de ciclo de vida incremental genera algunos beneficios tales
como los que se describen a continuación:
• Construir un sistema pequeño siempre es menos riesgoso que construir
un sistema más grande.
• Como se desarrollan independientemente las funcionalidades, es más
fácil relevar los requerimientos del usuario.
 16

• Si de detecta un error grave, solo se desecha la última iteración.

• No es necesario disponer de los requerimientos de todas las
funcionalidades en el comienzo del proyecto y además facilita la labor
del desarrollo con la conocida filosofía de divide & conqueror.

Este modelo de ciclo de vida no está pensado para cierto tipo de

aplicaciones, sino que está orientado a cierto tipo de usuario o cliente. Se
puede utilizar este modelo de ciclo de vida para casi cualquier proyecto, pero
será verdaderamente útil cuando el usuario necesite entregas rápidas, aunque
sean parciales.

Fig 9. Ciclo de vida incremental.

Ciclo de vida en espiral.

Este ciclo puede considerarse una variación del modelo con prototipazo,
fue diseñado por Boehm en el año 1988. El modelo se basa en una serie de
ciclos repetitivos para ir ganando madurez en el proyecto final. Toma los
beneficios de los ciclos de vida incremental y por prototipos, pero se tiene más
en cuenta el concepto de riesgo que aparece debido a las incertidumbres e
ignorancias de los requerimientos proporcionados al principio del proyecto o
que surgirán durante el desarrollo. A medida que el ciclo se cumple (el avance
de la espiral), se van obteniendo prototipos sucesivos que van ganando la
satisfacción del cliente o usuario.
 17

A menudo, la fuente de incertidumbres es el propio cliente o usuario, que

en la mayoria de las oportunidades no sabe con perfección todas las
funcionalidades que debe tener el producto.
En este modelo hay cuatro actividades que envuelven a las etapas.
• Planificación: Relevamiento de los requerimientos iniciales o luego de
una iteración.
• Análisis de riesgo: De acuerdo con el relevamiento de requerimientos se
decid si se continua con el desarrollo.
• Implementación: Se desarrolla un prototipo basado en los
requerimientos.
• El cliente evalúa el prototipo, si da de su conformidad, termina el
proyecto. En caso contrario, se incluyen los nuevos requerimientos
solicitados por el cliente en la siguiente iteración.

La ventaja más notoria de este modelo de desarrollo de software es que

puede comenzarse el proyecto con un alto grado de incertidumbre, se entiende
también como ventaja el bajo riesgo de retraso en caso de detección de
errores, ya que se puede solucionar en la próxima rama de la espiral.
Algunas de las desventajas son: el costo temporal que suma cada vuelta
de la espiral, la dificultad para evaluar los riesgos y la necesidad de la
presencia o la comunicación continúa con el cliente o usuario.
Se observa que es un modelo adecuado para grandes proyectos
internos de una empresa, en donde no es posible contar con todos los
requerimientos desde el comienzo y el usuario esta en nuestro mismo ambiente
laboral.

Ejemplo: Programa que administre reclamos, pedidos e incidentes.

 18

Fig 10. Ciclo de vida en espiral.

Ciclo de vida orientado a objetos.

Esta técnica fue presentada en la década del 90, tal vez como una de las
mejores metodologías a seguir para la creación de productos software.
Puede considerarse como un modelo pleno a seguir, como así también
una alternativa dentro de los modelos anteriores.
Al igual que la filosofía del paradigma de la programación orientada a
objetos, en esa metodología cada funcionalidad, o requerimiento solicitado por
el usuario, es considerado un objeto. Los objetos están representados por un
conjunto de propiedades, los cuales se denominan atributos, por otra parte, al
comportamiento que tendrán estos objetos se les denomina métodos.
La característica principal de este modelo es la abstracción de los
requerimientos de usuario, por lo que este modelo es mucho más flexible que
los restantes, que son rígidos en requerimientos y definición, soportando mejor
la incertidumbre que los anteriores, aunque sin garantizar la ausencia de
riesgos. La abstracción es lo que permite analizar y desarrollar las
 19

características esenciales de un objeto (requerimiento), despreocupándonos de

las menos relevantes.
Favorece la reducción de la complejidad del problema que se desea
abordar y permite el perfeccionamiento del producto.
En este modelos se utilizan las llamadas fichas CRC (clase-
responsabilidad-colaboración) como herramienta para obtener las
abstracciones y mecanismos clave de un sistema analizando los
requerimientos del usuario. En la ficha CRC se escribe el nombre de la clase u
objeto, sus responsabilidades (los métodos) y sus colaboradores (otras clases
u objetos de los cuales necesita). Estas fichas, además, ayudan a confeccionar
los casos de uso.
No es correcto suponer que este modelo sólo es útil cuando se escoge
para la implementación un lenguaje con orientación a objetos. Se puede utilizar
independientemente del lenguaje elegido. Es un modelo a seguir, una técnica, y
no obliga a utilizar ningún lenguaje en particular.
Como se menciono anteriormente, es un modelo muy versátil, y por ser
uno de los últimos en aparecer, aprendió mucho de los anteriores.

Ejemplo: Programas de monitoreo de procesos, grandes sistemas de

transacciones sobre base de datos, procesamiento por lotes.

Fig 11. Ciclo de vida orientado a objetos.

 20

III. CONCLUSIONES.
 21

- La industria ha demostrado una tendencia hacia el software comercial,

ya que conforme las opciones aumentan y los programas disponibles se
vuelven más generales, resulta más sencillo y económico que las
empresas se adapten a un sistema de información, que recurrir al
desarrollo de uno completamente nuevo.

- El desarrollo de software a la medida se convierte en una opción viable

para aquellos casos en los que el nivel de especialización del proyecto
sea suficientemente alto e indispensable, como para poder justificar los
costos y esfuerzos superiores.

- En el desarrollo de software a la medida debe escogerse

cuidadosamente el modelo de ciclo de vida que mejor se ajuste a las
necesidades del proyecto, evitando así complicaciones en cualquiera de
 22

sus etapas. No es posible determinar a un único modelo como más

apropiado para cualquier situación sino que su escogencia debe estar
basada en un análisis cuidadoso sobre las implicaciones.

- No existe un método de desarrollo establecido para cada tipo de

proyecto de software, el mismo debe elegirse de acuerdo a los
requerimientos del sistema.

- La comunicación eficiente es un elemento necesario para el éxito de un

proyecto de desarrollo de software a la medida.

- En costa Rica la mayoría de empresas que solicitan desarrollo de

software a la medida corresponden a entidades financieras.

IV. BIBLIOGRAFÍA
 23

1. Ingeniería del Software. Consultado el 8 de mayo de 2009.

http://es.wikipedia.org/wiki/Desarrollo_de_software

2. Modelos de ciclo de vida del software. Consultado el 8 de mayo de 2009.

http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node10.html

3. Herbsleb, James, Moitra, Deependra. “Global software Development”. IEEE

Software, Vol. 18, No. 2, p. 16-20, Marzo/Abril, 2001.

4. Brenes, Salomé. Desarrollo de software a la Medida (Entrevista). Empresa

 24

E-volutionSoft, San José, Mayo,2009.

 25

V. APÉNDICES.

Apéndice 1. Entrevista.

Empresa: EvolutionSoft
Persona entrevistada: Salome Brenes. Directora de Proyectos.

1. Brevemente, ¿Qué es e-volutionSoft?

EvolutionSoft es una empresa consolidada que se encarga del

desarrollo de software para: aplicaciones de manufactura, entre las que
podemos citar administración de compras, control de inventarios,
proceso productivo y trabajo en planta con costeo de estos; sistemas de
mantenimiento preventivo y correctivo de flotillas; servicio de WMS, el
cual se encarga de manejar la logística y administración de productos en
bodega, actualmente Cofasa, Pozuelo y Grupo Q son clientes de esta
aplicación; y por último, ventas móviles (evolution sales).
 26

2. ¿Hace cuantos años están al servicio de la clientela costarricense?

Se encuentran al servicio del mercado costarricense desde

aproximadamente 12 años.

3. ¿Bajo qué objetivo fue creada la empresa?

El principal objetivo de la empresa fue desarrollar software para

aplicaciones meramente enfocadas a la manufactura, si bien en
ocasiones han tomado otros rumbos por pedidos del cliente, tienen en
claro que su fuerte es la manufactura.

4. En términos generales, ¿cómo es el proceso que utilizan (ciclo de vida)

del desarrollo de software a la medida? ¿Cuál es la duración promedio
de los proyectos? ¿Cómo se establece el precio?

El ciclo de vida que utilizan a la hora de vender un servicio se

resume en los siguientes pasos:
a. Se realiza un análisis y establecimiento de requerimientos del
cliente acompañado y asesorado por uno de los ingenieros
industriales de la compañía.

b. Se efectúa una estimación del tiempo de realización del proyecto

por parte de un programador.

c. Se calcula el precio final y se consulta con el cliente.

d. Se incurre en una primera implementación y capacitación del

programa.

e. Se espera la aprobación del cliente.

f. Se da la implementación final del programa en la compañía.

La duración de un proyecto depende mucho en los requerimientos

del cliente y los recursos que este posea.
El precio del desarrollo de un servicio se obtiene con base a hora
de consultoría, la cual varía entre ingeniero industrial y programador.
 27

5. ¿Cómo describiría usted el mercado costarricense para este servicio?

¿Existen diferencias con respecto al mercado del resto de América
Latina?

Actualmente tanto en el mercado costarricense como en el

mercado en el resto de América Latina se está presentando una
tendencia a la adquisición de programas de software estándares, no
tanto al desarrollo de software a la medida, pues se busca disminuir los
contratiempos de trabajar con requerimientos de los clientes que no
saben en especifico que es lo que necesitan y el controlar cambios
presenta un gran problema; además, aseguran que los software que la
empresa ofrece al público cubren con casi todos los requerimientos de
empresas de manufactura. También se menciona como a la hora de
adquirir un software estándar se ahorran gran cantidad de costos a la
hora de renovar el software con nuevas versiones por medio del servicio
de soporte. Son muy pocas las empresas que en la actualidad prefieren
trabajar con software desarrollado a la medida, entre los casos
particulares se encuentre DHL el cual requiere un software muy
específico.

6. A la hora de adquirir el servicio, ¿el cliente adquiere solamente el

software, o también adquiere capacitación y mantenimiento del mismo?

El cliente obtiene la implementación, seguimiento y capacitación

inicial del software. Existe la opción de adquirir el servicio de soporte, la
cual se basa en el derecho de recibir las nuevas versiones del software
conforme vayan saliendo al mercado.

7. ¿De quién es la propiedad intelectual del software y el código fuente?

¿Qué otras cosas adquiere el cliente?
 28

La propiedad intelectual es de EvolutionSoft, sin embargo el

cliente recibe el código fuente. Además de esto el cliente recibe: la
documentación completa, los diagramas, las plantillas de carga de datos
y los manuales de usuario.