P. 1
Marco Teorico

Marco Teorico

4.5

|Views: 8.601|Likes:
Publicado porlolo

More info:

Published by: lolo on Jun 16, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

07/17/2013

pdf

text

original

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 solicitados y funciona correctamente. requerimientos

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: 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. Se desarrolla un prototipo basado en los

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 (claseresponsabilidad-colaboración) abstracciones y mecanismos como clave herramienta de un para obtener analizando las los sistema

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.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->