El artículo analiza el método de utilizar 1C DSS (Sistema de diseño de aplicaciones) para evaluar la duración y el costo de los proyectos que utilizan el método COCOMOII.
¿Cómo justificar al cliente que su evaluación del momento del proyecto es objetiva?
¿Cómo medir el margen de un proyecto antes de que comience, en la etapa de preventa?
¿Cómo evaluar el rango de negociación al precio del proyecto para evitar pérdidas?
¿Cómo calcular objetivamente la necesidad de un proyecto para los miembros del equipo que no son desarrolladores (analistas de negocios, metodólogos, escritores técnicos, etc.), cómo formalizar el resultado de su trabajo de la manera más simple y asequible?Tabla de contenidos
- Entrada.
- El principal problema de usar 1C DSS en la actualidad.
- ¿Por qué COCOMOII?
- ¿Por qué 1C DSS?
- Curso más corto de COCOMOII
- Transición de la evaluación laboral de los desarrolladores a la evaluación laboral de analistas y metodólogos.
- Pseudocódigo
- 1 DSS y pseudocódigo.
- Resumen
Entrada
1C Application Design System se lanzó al mercado hace 6 años y en julio de 2019 pasó a ser la versión 2. Basado en tecnologías SADT y un modelo de desarrollo en cascada. Sin embargo, le permite liderar el desarrollo Scrum / Agile en etapas individuales.
Diseñado para proyectos complejos y largos ejecutados por un equipo de múltiples componentes con reemplazo frecuente de personal. Incluye la funcionalidad de gestión de proyectos, descripciones de procesos comerciales, diseño de la arquitectura y funcionalidad de sistemas de información, desarrollo de software y mantenimiento de IP, así como pruebas automáticas basadas en Vanessa / Gherkin.
En primer lugar, es útil para los integradores de sistemas y franquiciados, y en segundo lugar para todas las organizaciones que realizan el desarrollo y mantenimiento independientes de sus propias IP con la participación de artistas externos.
El principal problema de usar 1C DSS en la actualidad
El principal problema de usar 1C DSSR en la actualidad (la versión 1 se usa principalmente) es el uso extremadamente incorrecto de 1C DSSR como tecnología.
1C DSS se usa con mayor frecuencia en el nivel de funcionalidad destinado a desarrolladores, en el mejor de los casos para arquitectos. Su papel a menudo se reduce a la descripción y el desarrollo de las "Funciones" del sistema y la formación de tareas para los programadores. Este es el error del enfoque para trabajar con DSS.
Los sistemas existentes en el mercado (JIRA, etc.) están haciendo un gran trabajo al establecer tareas para programadores y procesar tickets de usuario. Con este uso, los desarrolladores de DSS tienen otro complemento burocrático que lleva mucho tiempo, que toma tiempo de la codificación "pura".
El desarrollador se ve obligado a describir la funcionalidad del sistema implementado / finalizado para garantizar el establecimiento de tareas para los programadores con enlaces a objetos de metadatos ("lenguaje común" en términos de Eric Evans en su trabajo "Diseño orientado a objetos (DDD). Estructuración de sistemas de software complejos").
Al mismo tiempo, las tareas de la otra mitad del equipo del proyecto: gerentes de proyecto, analistas de negocios, metodólogos son ignoradas casi por completo. Desafortunadamente, podemos decir que incluso el propio 1C en la versión 2.0 del DSS redujo en gran medida la funcionalidad para esta categoría de participantes, cambiando significativamente el modelo DSS en comparación con la versión 1.0 hacia desarrolladores y probadores (por ejemplo: los requisitos y los objetos de datos se eliminaron explícitamente).
Sin embargo, el problema del uso completo y completo de DSS es grave. En este artículo, en particular, consideraremos cómo la tecnología para estimar los términos y el costo de los proyectos que utilizan el método COCOMOII se puede usar en 1C DSS.
Todos quieren saber por cuánto tiempo se puede completar un proyecto, sobre el cual el cliente mismo no puede decir lo que finalmente quiere, y ¿hasta qué punto es razonable negociar con el cliente?
¿Y cómo convencer al cliente de que el tiempo y el costo propuestos están justificados? Sin embargo, esto último no es dañino de saber por nosotros mismos.
Y lo más importante, ¿cómo calcular objetivamente la necesidad de un proyecto para los miembros del equipo que no son desarrolladores (analistas de negocios, metodólogos, escritores técnicos, etc.), cómo formalizar el resultado de su trabajo de la manera más simple y asequible?
¿Por qué COCOMOII?
Los clientes en cualquier industria prefieren tener una evaluación objetiva, razonable y generalmente aceptada del costo y el momento del proyecto. Les gustaría ver la conexión de su proyecto con la experiencia de un integrador de sistemas en proyectos anteriores. Al mismo tiempo, un cliente raro tiene una idea clara del resultado final del proyecto, pero en proyectos con el desarrollo de un modelo conceptual definitivamente no lo tiene. Y el integrador del sistema no tiene.
¿Cómo evaluar el tiempo y el costo en la etapa de preventa en ausencia de información? ¿Y en el curso del proyecto, teniendo en cuenta los cambios (el flagelo de todos los proyectos)?
El método COCOMOII le permite realizar una evaluación de este tipo, teniendo en cuenta la experiencia acumulada del integrador del sistema, y de la manera más simple, mientras puntualmente, durante el transcurso del proyecto, hace especificaciones de precios / plazos y los justifica para el acuerdo con el cliente.
¿Por qué 1C DSS?
El caso es que 1C DSS se basa en SADT y las tecnologías de "lenguaje común" (esto se describe con más detalle en mi artículo separado). Es SADT que integra el proceso de modelado con el proceso de desarrollo basado en el "lenguaje común". Un "lenguaje común" le permite tener una base para calcular los indicadores estimados de los términos.
Curso más corto de COCOMOII
La metodología COCOMO surgió en 1963 en respuesta a la necesidad de una evaluación rápida y sin complicaciones de la complejidad y el momento del desarrollo del software en los próximos proyectos. La base del modelo COCOMO y su siguiente etapa, COCOMOII, es el número de líneas de código de programa (KSLOC es mil líneas de código lógico, es decir, líneas de código que expresan una operación). Esta base es el resultado de cualquier proyecto de desarrollo de software, es una especie de quintaesencia del proyecto.
(Tendremos en cuenta que COCOMO difiere de COCOMOII en que los parámetros escalares de la fórmula COCOMO se reemplazan con la tabla de parámetros COCOMOII, pero la esencia del método sigue siendo la misma).
Por lo tanto, al tener el equipaje acumulado de los proyectos, cualquier desarrollador puede tener una evaluación básica del marco de cada próximo proyecto. Por supuesto, esta es una estimación muy aproximada, pero en la etapa de preventa, dicha estimación es mejor que nada. Para aclararlo, la base KSLOC se ajusta de acuerdo con una determinada fórmula a los coeficientes de refinamiento. No daremos la fórmula, es simple y está disponible en Internet. La conclusión es que cada desarrollador puede desarrollar los coeficientes de esta fórmula sobre la base de estadísticas de proyectos anteriores y compararlos con los parámetros canónicos de la fórmula, o ... no comparar y usar solo su propia fórmula.
La presencia de una fórmula con parámetros indica que todos los proyectos del integrador del sistema (o todos los proyectos internos de la organización) deben codificarse y clasificarse de acuerdo con todos estos parámetros. Cuantos más proyectos estén en el equipaje de los desarrolladores, más proyectos del mismo tipo para un nuevo proyecto que se pueden abrir para la evaluación (filtrar proyectos no básicos), más precisa será la evaluación.
Al conocer el tiempo dedicado a un proyecto completado por unidad KSLOC (línea de código), puede evaluar la laboriosa potencial de un proyecto futuro. Si los parámetros almacenan datos sobre las calificaciones (calificaciones) de los empleados empleados, puede obtener una estimación del costo del proyecto.
Los detalles de los parámetros del proyecto se pueden hacer a su discreción y capacidades. Cuanto más detalle, más exactamente se estima el tiempo y el costo del proyecto futuro.
¿Qué KSLOG se configura en la etapa de preventa con una descripción inexacta del resultado? Solo empírico de la base de datos de proyectos del integrador (ejecutor). En este caso, se puede usar un conjunto de parámetros del proyecto. Si hay una descripción precisa del resultado deseado del proyecto (producto de software), se puede utilizar un conjunto extendido de parámetros del proyecto.
Ese es el objetivo del método COCOMO.
Transición de la evaluación laboral de los desarrolladores a la evaluación laboral de analistas y metodólogos.
Los lectores atentos y experimentados exclamarán:
"Bueno, entonces! Con todos los pros y los contras del método COCOMO, está diseñado para evaluar proyectos de software. El trabajo de los desarrolladores y programadores se puede digitalizar en KSLOC condicional. ¿Pero qué pasa con los analistas y metodólogos, gerentes de proyecto y gerentes? ¿Y qué tiene que ver 1C DSS con él?
Derecho!
Por lo tanto, la tarea es seleccionar una base similar para los miembros del equipo enumerados que le permitirá utilizar la técnica COCOMOII. Aquí él sube al escenario.
Pseudocódigo
Uno de los tipos de resultados de salida de todos los proyectos complejos para el diseño, creación y desarrollo de sistemas de información son los documentos del proyecto. Estas son tareas técnicas, documentos conceptuales, descripciones, instrucciones, registros de objetos de datos, listas de analistas, etc. La tabla de contenido de estos documentos, textos de contenido, tablas, figuras, requisitos recopilados, listas son pseudocódigo.
Y es este pseudocódigo el que mide los resultados del trabajo de los miembros "no programadores" del equipo del proyecto: analistas, metodólogos, escritores técnicos, gestión de proyectos, arquitectos, diseñadores y participantes similares.
Si el proyecto se presenta de acuerdo con los requisitos de GOST, la estructura de los documentos del proyecto está definida por estas normas; de lo contrario, se crea a discreción del contratista o de acuerdo con los requisitos del contrato con el cliente.
Un punto interesante es si el equipo del proyecto y el cliente deciden mantenerse al día con los tiempos y elaborarán los resultados del proyecto utilizando exclusivamente tecnología sin papel, ¿cómo se conectará 1C DSS con esto?
La respuesta, de la manera más directa, DSS y el contenido de sus directorios completados por el proyecto será un objeto de datos estructurados y el resultado del trabajo. Lo cual es muy conveniente para transferir al cliente. Todos los documentos creados durante el proyecto se adjuntarán a los objetos de configuración DSS.
Los documentos de proyecto de salida simplificados se dividen en los siguientes grupos de pseudocódigo:
- La estructura (tabla de contenido) del documento;
- Prueba de documentos;
- Fila de tabla de documentos (tabla);
- Dibujo (objeto gráfico).
En los casos más simples, para COCOMO, la estructura de los documentos de salida es suficiente. Su complejidad (el número de niveles de anidación), el número de líneas de tabla de contenido puede servir como base para aplicar las fórmulas del método para estimar los términos y el costo de un proyecto a través de estadísticas similares de proyectos anteriores y la estructura de los participantes en los equipos del proyecto (no los programadores). Por supuesto, la inclusión de todos los tipos de pseudocódigo en la base aumentará la precisión de la estimación.
Por lo tanto, el análogo de KSLOC en el COCOMO estándar aquí se convierte en la tabla de contenido del documento de proyecto de salida y / o la línea de texto de este documento (cada línea de cada tabla en este documento, cada objeto gráfico). La base no debe incluir elementos de diseño y diseño del documento.
1 DSS y pseudocódigo
Surge la pregunta de cómo colocar un pseudocódigo en 1C DSS.
Esto se puede hacer a través del directorio "Objetos de datos". Se crea un grupo separado "DOCUMENTOS DE SALIDA", dentro de los subgrupos para cada tipo de documento, luego otro subgrupo para cada documento separado, y dentro de estos subgrupos como elementos de una tabla de contenido de referencia para el documento del proyecto.
Si se toma la decisión de incluir contenido de texto, tablas, objetos gráficos de los documentos de proyecto de salida en la base COCOMOII, entonces la tabla de contenido del documento de proyecto también debe hacerse en los grupos del directorio "Objetos de datos", y dentro de ellos se deben colocar los nombres de tablas, objetos gráficos y párrafos de texto.
El texto del documento del proyecto en sí puede escribirse en párrafos como el campo de texto del elemento de directorio "Objetos de datos".
¿Por qué debería esforzarse uno al describir la estructura de los documentos del proyecto de salida en el libro de referencia "Objetos de datos"?
Es necesario esforzarse por garantizar que cada elemento del directorio "Objetos de datos" pueda tener un enlace a un objeto de metadatos y / o un objeto de datos (de otros grupos del directorio "Objetos de datos" que describen no otras estructuras de los documentos de salida, sino otros tipos creados en proyecto de datos, por ejemplo: listas de analistas).
Dicho diseño permitirá crear documentos de proyecto de salida automáticamente, directamente desde 1C DSS. Esto ayudará a reducir significativamente el tiempo dedicado al trabajo en equipo en el proyecto, especialmente en condiciones de cambios constantes en los requisitos del cliente, modificaciones del sistema de información, incluyendo otros equipos e intérpretes cuando sea necesario recrear nuevamente los documentos de salida, pero al mismo tiempo mantener la coherencia de los objetos y sus descripciones.
Al vincular cada elemento o grupo del directorio "Objetos de datos" con los Requisitos (ambos formulados por el cliente y los miembros del equipo del proyecto, detallados en los metadatos), finalmente puede obtener un enlace de extremo a extremo Requisitos - Objetos de metadatos - Documentos del proyecto de salida. En DSS 2.0, "Ideas" son el equivalente de "Requisitos".
Con la acumulación de experiencia en la implementación de proyectos en 1C DSS, tal estructura de directorio se cristalizará y será igual en todos los proyectos similares. Por lo tanto, para un nuevo proyecto, es suficiente simplemente copiarlo. Y para proyectos idénticos en resultados de salida, puede copiar el texto (tabla).
Resumen
Los integradores y las organizaciones con una base de datos bien desarrollada de proyectos, que han auditado los materiales de proyectos anteriores, pueden tener a su disposición una evaluación objetiva de la oportunidad y el costo de los proyectos planificados y en curso.
Esto debería facilitar en gran medida A) la negociación con el cliente B) la evaluación de los beneficios esperados.