Coincidencia de negocios
Utilice procesos reales para verificar cuánto núcleo necesita el sistema de código abierto, no sólo la lista de funcionalidad y la página de presentación.
Home / Orientación de la decisión del proyecto / Desarrollo de la personalización y adaptación de código abierto
PROJECT DECISION GUIDEDesarrollar desde la adaptación basada en sistemas de código abierto o personalizado
Las modificaciones de código abierto pueden no ser más baratas o más manejables desde cero. La clave es juzgar el partido entre las capacidades de código abierto existentes y las operaciones de destino, así como las mejoras futuras y los costos de mantenimiento.
Responde a la pregunta.
Desarrollo personalizado y adaptación de código abierto
Cuando los procesos básicos son comunes, los proyectos de código abierto son maduros y las licencias son compatibles con los modelos de negocio, las adaptaciones basadas en sistemas de código abierto pueden acortar el primer ciclo; cuando las reglas de negocio constituyen una competitividad básica, las limitaciones de la estructura son claras o la profundidad de las adaptaciones pueden prolongarse lejos de las versiones comunitarias, es generalmente más apropiado personalizarse desde cero.
DECISION FACTORS
Los elementos clave que se deben revisar para la adopción de decisiones
En primer lugar, se determinan los límites de la moderación y la responsabilidad, y se comparan las rutas técnicas y las modalidades de cooperación.
Licencias y modelo de negocio
Evaluar los límites permisibles de uso, modificación, distribución, servicios SaaS, marcas comerciales y componentes de confianza, sujetos a revisión por profesionales legales, según sea necesario.
Modificar la profundidad
Las interfaces, las marcas y un pequeño número de extensiones de proceso son generalmente menos riesgosas; los cambios importantes en los modelos de datos básicos y las estructuras inferiores pueden debilitar las ventajas del programa de código abierto.
Sendero de actualización
Es necesario aclarar quién es responsable de actualizaciones de la versión comunitaria, parches de seguridad, consolidación de ramas personalizadas y pruebas de regresión automatizadas.
Competencias y ascensos del equipo
Cualquier ruta debe ser seleccionada, y se deben obtener códigos fuente, instrucciones de despliegue, migración de datos, interfaces y documentos de transporte.
Costo total de propiedad
Compare el desarrollo, la concesión de licencias, los recursos en la nube, las mejoras, la movilidad, la seguridad y los gastos de personal durante al menos tres años, en lugar de depender de la primera oferta.
Preparación de recomendaciones antes de la comunicación o evaluación
Procesos empresariales y funciones diferencialesActividad del proyecto de candidatos de código abiertoLicencias y componentes de confianzaEstructura y cierre de anclaje técnicoNecesidades de seguridad y mecanismos de actualizaciónPuntos de extensión de desarrollo secundarioActualización de la versión y política de sucursalesCosto total de tres años de propiedad
Sendero sugerido para la aplicación
Se recomienda que se lleve a cabo una serie de análisis de las diferencias y selección, con la demanda de productos que abarcan la matriz, el riesgo de licencia, la lista de adaptación, la estrategia de mejora y la comparación de costos de las dos rutas, antes de adoptar una decisión sobre el establecimiento de un proyecto.
DECISION WORKSHEET
Desarrollo de la personalización y adaptación de código abierto a la adopción de decisiones
Las siguientes hojas de trabajo ayudan a las empresas a organizar consejos vagos en insumos basados en proveedores, de aprobación interna y de receptividad de proyectos.
Coincidencia de negocios
Utilice procesos reales para verificar cuánto núcleo necesita el sistema de código abierto, no sólo la lista de funcionalidad y la página de presentación.
Si el factor sigue siendo incierto, se debe organizar una validación de diagnóstico o en pequeña escala y no es apropiado incluir directamente el rango de precios fijos no variable.
Licencias y modelo de negocio
Evaluar los límites permisibles de uso, modificación, distribución, servicios SaaS, marcas comerciales y componentes de confianza, sujetos a revisión por profesionales legales, según sea necesario.
Si el factor sigue siendo incierto, se debe organizar una validación de diagnóstico o en pequeña escala y no es apropiado incluir directamente el rango de precios fijos no variable.
Modificar la profundidad
Las interfaces, las marcas y un pequeño número de extensiones de proceso son generalmente menos riesgosas; los cambios importantes en los modelos de datos básicos y las estructuras inferiores pueden debilitar las ventajas del programa de código abierto.
Si el factor sigue siendo incierto, se debe organizar una validación de diagnóstico o en pequeña escala y no es apropiado incluir directamente el rango de precios fijos no variable.
¿Qué debería contener un resumen comparable de las evaluaciones?
Como mínimo, los procesos comerciales y las funciones de discrepancia, la actividad de proyectos de código abierto candidatos, licencias y dependencia de componentes, la arquitectura y la tecnología coinciden con el anclaje, y describen el volumen de negocio actual, el tiempo de procesamiento medio, las anomalías mayores, los sistemas existentes, los privilegios de datos, la dependencia de terceros y las ventanas de acceso. La misma versión de la información se proporciona a diferentes proveedores y descripciones separadas de supuestos, exclusiones, entregas, la cooperación con el cliente, la falta de datos
Por ejemplo, la empresa espera que el proyecto ahorre 160 horas de trabajo al mes, pero esta cifra debe desglosarse en el número de tareas, ahorros de tiempo único, tasas de adopción y tasas de revisión manual. Si sólo el 40% de los usuarios utilizan el primer período, o si el nuevo proceso aumenta el proceso de examen, los beneficios reales serán significativamente inferiores a la estimación aparente.
Cuatro tipos de pruebas recomendadas para el interrogatorio durante la comunicación de proveedores
The first is scope evidence: consistency of demand versions, business processes, prototypes, interfaces and exclusions; the second is engineering evidence: whether similar technologies have accessible structures, code management, testing, deployment and trouble management methods; the third is personnel evidence: whether actual participants, input stages, responsibilities and replacement mechanisms are clear; and the fourth is delivery evidence: how source codes, data, account numbers, documents, training, quality assurance and transport are handed over. It is normal for suppliers to be unable to provide customer confidentiality at the bidding stage, but should be able to explain their own methods and the evidence that can be developed under this project.
Se recomienda que se fije por separado la claridad de alcance, la dependencia crítica, la capacidad de equipo, la aplicabilidad de la aceptación y la toma a largo plazo y que se registre la base de cada puntuación. Si un programa es más barato, se excluye la interfaz, la migración, las pruebas o la responsabilidad en línea, entonces debe convertirse al mismo calibre de entrega antes de la comparación.
El principio de la sentencia
Esta página proporciona un marco de toma de decisiones que no constituye una oferta fija o compromiso de rendimiento.
FAQ
FAQs
Las cuestiones más comunes antes de la cooperación se señalan claramente con antelación.
¿Es un sistema de código abierto igual a libre?+
No es igual. Los costos de licencia de código pueden ser cero, pero se requieren insumos de ingeniería para la selección, el despliegue, la adaptación, la migración de datos, la seguridad, la actualización y el transporte.
¿Los sistemas de código abierto cambian, mejor?+
No. La capacidad de lograr diferencias a través de plugins, configuraciones y extensiones debe reducirse reduciendo las intrusiones en códigos básicos para reducir el costo de las actualizaciones posteriores.
¿Puedes rehacerlo primero, luego reescribirlo?+
Sí, pero desde el principio, es necesario planificar datos, interfaces y límites operacionales para evitar que se les deje específicamente apuntar a la migración futura.
DECISION FAQ
Echa un vistazo a las 265 preguntas.Cuestiones comunes relacionadas con proyectos en curso
Manzanas, APP, SaaS y sistemas antiguos
¿Deberían desarrollarse sistemas institucionales desde cero o desde sistemas de código abierto en fase secundaria?
Los procesos son comunes, los productos de código abierto maduran y las licencias permiten el desarrollo secundario. Cuando las diferencias de negocio, las limitaciones de la arquitectura básica o los costos de actualización a largo plazo son altos, puede ser más apropiado desarrollarse a partir de cero.
Ver respuesta completaInicio del proyecto de software y selección del programa¿Cómo se seleccionan los sistemas de código bajo, código abierto y desarrollo personalizado?
El código bajo es adecuado para procesos que son claros, cambiantes y de plataforma capaces de cubrir aplicaciones internas superiores; los sistemas de código abierto son adecuados para productos de área madura, que pueden satisfacer la demanda a través de la configuración y desarrollo secundario; personalizar el desarrollo de proyectos que son adecuados para procesos diferenciados, integración compleja, rendimiento o requisitos de control de productos más altos. La selección se realiza con una comparación de la capacidad total de coste y salida de tres a cinco años, en lugar de la combinación de los límites adecuados.
Ver respuesta completaDesarrollo de programas y contratación externa de proyectos¿Cuánto cuesta el desarrollo de software personalizado?
El software personalizado no tiene un precio uniforme basado en el tamaño de la página, y los costos se determinan principalmente por alcance, interfaz, datos, autoridad, desempeño y rendición de cuentas para la entrega. El sistema de gestión con el mismo nombre puede ser un instrumento de un solo sector o una conexión a órdenes, inventario, finanzas y autoridad multiorganización. Se recomienda que el primer negocio cierre el bucle y los límites de recepción e inspección, y que el producto, diseño, desarrollo, pruebas, volumen de referencia total y el precio estimado sea considerado preciso
Ver respuesta completaInicio del proyecto de software y selección del programaLos requisitos de software son incompletos, así que ¿podemos tener una empresa externa para evaluarlos?
Es posible, y si la demanda es incompleta, hacer un diagnóstico de necesidades limitadas primero, en lugar de exigir directamente un precio total fijo. Una empresa simplemente necesita indicar su entorno empresarial, usuarios objetivo, problemas actuales, tiempo para ir en línea y presupuestos disponibles.
Ver respuesta completaRELATED
Presentación de la evaluación de proyectosMantenga su conocimiento de los servicios
Relevant
Comercialización de sistemas de código abierto
Comprensión de la selección, el despliegue privado, el desarrollo secundario y la mejora a largo plazo
Para más información.RelevantDesarrollo de software empresarial
Comprender los procesos institucionales a la entrega de fuentes completas
Para más información.RelevantPresentación de información de evaluación seleccionada
Cotejar objetivos, proyectos de status y candidatos de código abierto
Para más información.