Una fuente
Marco de Investigación
, .
.
Dado que en este momento hay más de dos docenas de tipos de vacantes de “analista” en el mercado laboral de TI , de inmediato haré una reserva de que hablaré sobre el trabajo analítico en proyectos estatales para crear software personalizado. Como muestra mi experiencia, un analista de negocios que no comprende los mecanismos para automatizar los procesos comerciales no puede preparar una declaración adecuada del problema. Del mismo modo que un analista de sistemas que no comprende los objetivos comerciales de la automatización no puede ser adecuado. Por lo tanto, desde mi punto de vista, un analista que trabaja en proyectos de software personalizados debe combinar las competencias de un analista de negocios, un analista de sistemas y un diseñador de UX. Además, por regla general, el analista principal de dicho proyecto debe realizar las funciones del propietario del producto.(si el cliente lo permite). Se trata de la organización de las actividades de tales "soldados universales" que se discutirán más adelante.
Al crear software en interés de las organizaciones gubernamentales, la actividad principal de los analistas está asociada con la resolución de problemas tales como:
- gestión de requerimientos;
- formación de declaraciones de tareas para programadores, planificación de la implementación y control sobre la implementación de estas tareas;
- preparación de la documentación del proyecto.
Los detalles de la gestión de los requisitos para el software personalizado, el procedimiento para su refinamiento inicial y el papel clave del analista responsable de su implementación se discutieron en detalle en el artículo anterior .
Sin embargo, la especificidad de los deseos del cliente no es garantía de que le gustará el resultado final. En el transcurso de mis proyectos , se "identificó" el siguiente patrón: todos los comentarios funcionales del cliente, registrados durante todo tipo de pruebas (¡no confundir con los errores identificados!), Relacionados con requisitos para los cuales la solución de diseño no fue acordada proactivamente con el cliente. En este sentido, las estadísticas dadas por Natalya Rukol son indicativas.cuando, al analizar los resultados de uno de los proyectos, resultó que casi el 70% de los "errores" revelados en la etapa de entrega fueron causados por una falta de comprensión de los requisitos iniciales por parte de los desarrolladores.
Parecería que después de que se hayan aclarado los requisitos para el producto de software, es necesario formar un paquete de documentación de diseño de acuerdo con GOST RD 50-34.698 , coordinarlo con el cliente y luego desarrollar el software en total conformidad con el proyecto aprobado. A menudo se trata de esta secuencia de acciones que uno escucha de los excelentes estudiantes de ayer (los estudiantes de grado C, por regla general, no saben en absoluto acerca de la existencia de tales documentos) y muchos altos funcionarios "experimentados" que nunca han sido personalmente responsables del resultado final del desarrollo de software.
Como sugiere mi experiencia, la formación de la documentación del proyecto es solo la parte final del trabajo del analista. Como analogía, se puede citar un trabajo de investigación, como resultado del cual se debe generar un informe de acuerdo con GOST 7.32 o se debe escribir una disertación. Sin embargo, estos documentos son solo una forma de formalizar los resultados científicos obtenidos. La realización de experimentos infructuosos, el procesamiento estadístico del "ruido blanco", la búsqueda de granos de la información requerida en toneladas de papel de desecho pseudocientífico: todas estas partes integrales del trabajo científico siempre quedan entre bastidores. Lo mismo ocurre con la documentación del proyecto. Por un lado, es una parte integral del producto de software.... Por otro lado, contiene solo los resultados finales del trabajo analítico.
Fuente
En mi opinión, este aspecto es una de las razones por las que, de acuerdo con los requisitos de los contratos gubernamentales para proyectos de software, los clientes "estúpidos" planean acordar la documentación del diseño en la etapa de prueba preliminar, es decir. en el momento de la finalización real del desarrollo del software.
Es por ello que, en nuestros proyectos de software en JIRA, se configuran dos tipos diferentes de tareas, que nos permiten separar el trabajo analítico directamente de la actividad de elaboración de la documentación del proyecto. Y lo que es gratificante, no fui el único que llegó a tales conclusiones.... Entonces, ¿qué deben hacer exactamente los analistas en un proyecto de software después de especificar los requisitos y antes de redactar la documentación del proyecto?
¿Soluciones de diseño VS documentación de diseño?
Qué hermoso es el papel,
qué fácil es seguir las palabras.
Qué fácil es hacerte infalible.
B. Grebenshchikov
A pesar de que la definición del concepto de "solución de diseño" se da en GOST 34.003-90 , en mi caso, el significado de este concepto fue "descubierto" en el curso de intentos dolorosos e infructuosos de acordar con los representantes del cliente varios requisitos interrelacionados, pero ambiguos, cuando los clientes simplemente ignoraron la propuesta. describimos el establecimiento de objetivos ( TMP ), conformado en estricto cumplimiento del RD 50-34.698-90. Después de darse cuenta de que la decisión por parte del cliente no se tomaría hasta el inicio de las pruebas, se llevó a cabo la siguiente maniobra: se envió nuestra solución de diseño al cliente (es decir, una decisión que no estaba obligado a acordar formalmente).
Los atributos rituales se conservaron en la solución de diseño, pero se realizaron ajustes significativos en este documento en comparación con el HMO alojado. La solución de diseño se complementó con un diagrama de un proceso de negocio automatizado con una breve descripción, diseños de interfaz de usuario, formularios de informes recibidos para impresión, propuestas para la distribución del acceso, así como un breve escenario para la entrega de esta solución de diseño. En términos de requisitos ambiguos y contradictorios, se realizó una descripción detallada e inequívoca. Sin embargo, el resto del texto se redujo al mínimo de todas las formas posibles. Los algoritmos triviales no se describieron en absoluto, al igual que los campos de los formularios de pantalla no se describieron, cuyo propósito y reglas de validación estaban claros en los diseños de IU dados.
El cóctel resultante fue al mismo tiempo similar en forma a un documento redactado de acuerdo con los requisitos del RD 50-34.698-90, pero en realidad no correspondía a ninguno de los formatos dados en este GOST. Al mismo tiempo, lo que estaba escrito en él fue entendido por un representante ordinario y no preparado del cliente. Los requisitos especificados en este documento eran perfectamente claros tanto para el cliente como para el contratista. Se determinaron los límites de los requisitos, la cantidad requerida de trabajo planificado y cómo deberían haberse completado estos trabajos.
La carta de presentación contenía algo como esto:
“Presentamos una variante de una solución de diseño para cumplir con los requisitos enumerados. Le informamos sobre el inicio del trabajo sobre la implementación de la opción presentada. Si no está de acuerdo con la solución de diseño propuesta, infórmenos al respecto ".
En caso de que se discutieran más los requisitos, la ausencia de una respuesta a dicha carta se interpretó como un acuerdo formal del cliente con la solución de diseño propuesta. Si el cliente enviaba objeciones, en este caso se le informaba que el trabajo de implementación de esta solución de diseño estaba
Lo curioso es que en un principio en las cartas de respuesta si el cliente no enviaba las aclaraciones necesarias, usábamos la frase "el trabajo está suspendido". Después de varias cartas de este tipo, uno de los representantes del cliente inició un escándalo en relación con el hecho de que "según el contrato firmado, no podemos suspender el trabajo y la falta de aclaración sobre los requisitos no es una razón para terminar el desarrollo". Sin embargo, no tenía objeciones a la redacción de que “el trabajo no podía continuar”.
Como resultó más tarde, a pesar de que la estructura formada de la solución de diseño no cumplía con los requisitos de GOST, el enfoque propuesto facilitó en gran medida los movimientos corporales rituales para la formación y aprobación de la documentación del diseño. El contenido de la documentación de diseño, que se requería para la entrega del proyecto, se formó mediante la copia selectiva de las secciones relevantes de las soluciones de diseño. Al mismo tiempo, en relación con las secciones de la documentación que se formaron sobre la base de decisiones de diseño "acordadas" preventivamente, el cliente no realizó comentarios durante la aceptación.
Descripción del elefante no según GOST.
La verdad es que los clientes no saben lo que quieren. Por lo general, no saben qué preguntas deben responderse y casi nunca pensaron en el problema con el detalle que debería indicarse en la especificación.
Frederick Brooks
En mi opinión, el criterio principal para una buena descripción del enunciado del problema (solución de diseño) no es el cumplimiento de los requisitos formales de GOST, sino una descripción inequívoca de las condiciones para la finalización exitosa del trabajo para cumplir con los requisitos del cliente. Desde este punto de vista, la descripción de los elementos de prueba para verificar los requisitos es en realidad una parte integral de cualquier solución de diseño.
Cabe señalar que cuando se trabaja con un cliente del gobierno, todas las ambigüedades y ambigüedades en sus decisiones de diseño siempre se interpretarán a favor del gobierno. Para evitar estos puntos ciegos, mediante prueba y error en los requisitos de registro, se desarrolló una lista de verificación de evaluación de la calidad del diseño, que enumeraba las secciones principales que debían reflejarse en la solución de diseño según fuera necesario . Por tanto, cualquier solución de diseño debe comprobarse desde las siguientes posiciones.
- Lista de requisitos del cliente (que se implementará como parte de la solución de diseño).
- Lista de definiciones y abreviaturas.
- La lista de documentos normativos que regulan el proceso automatizado.
- (use case), :
- ( , BPMN – , : , ) ;
- ;
- ( ) — ;
- ( , ).
- :
- , ;
- (UI) ( , , );
- () .
- :
- API;
- () «» ( );
- () «» .
, « » ( 2011 ., 1). - , (). - :
- , () , ;
- , () .
- () , , . ( ) . ( ), , () , . «» .
Repito: esta no es una estructura fija para una solución de diseño, es una lista formal de preguntas ( lista de verificación), cuyas respuestas deberían, si es necesario, reflejarse de una forma u otra en la solución de diseño. Como muestra la práctica, si no se espera un desarrollo en relación con uno de los elementos descritos anteriormente, será mejor si lo indica explícitamente en la solución de diseño. O casi explícitamente (no asustes al cliente). El criterio principal es una interpretación inequívoca. Es importante no exagerar para que en lugar de resolver el requisito planteado, no nazcan cinco nuevos como consecuencia de su aprobación. Por ejemplo, la frase "La referencia de tipos de objeto debe contener solo valores reales" y la frase "La referencia de tipos no permite almacenar el historial de cambios" significan lo mismo, pero la segunda frase probablemente conducirá al hecho de que debe describir e implementar mecanismos de control de versiones. este mismo manual.Al tomar decisiones de diseño, es importante comprender que su propósito es fijar las reglas mediante las cuales se le garantiza que entregará los requisitos asociados con estas decisiones.
, , , .
Gran parte (si no todo) del proyecto depende de cómo los representantes del cliente imaginan el resultado final. Por lo tanto, ya en las etapas iniciales, diseñar diseños de interfaz de usuario es clave para el éxito del proyecto. Aclare y especifique los requisitos del cliente en términos de una descripción externa del producto de software que él comprende. El diálogo con los representantes del cliente, basado en la discusión de los diseños de pantalla, demostró ser mucho más efectivo que el diálogo sobre la discusión de los formatos de datos de entrada y salida y sus algoritmos de transformación (las secciones principales en el IPR, creado de acuerdo con GOST).
Trabajar en el marco de las asignaciones de diseño todos los elementos de la interfaz de usuario, además de la transparencia de comprender los límites de implementación, también proporciona una solución a una serie de problemas:
- . , , UI, , .
: . . ISBN: 978-5-91180-090-1
- UX- . , , ( ).
- «» . UI , , – , ( « » ).
- , «» . UX- . , 80% . , . ( ) : « ?». , , ( ) , , . , « ». «» . , , « ».
Me gustaría decir algunas palabras sobre los principios del diseño de interfaces de usuario para sistemas de control automatizados. A pesar del crecimiento similar a una avalancha en el uso de dispositivos móviles, las computadoras de escritorio y portátiles siguen estando fuera de la competencia por los sistemas de control automatizados utilizados en las agencias gubernamentales (así como para resolver problemas de programación y administración de sistemas). Actualmente, ha aparecido una variedad de herramientas para la creación de prototipos de interfaces . Sin embargo, explicar los detalles del uso de Figma o Axure en interés de los dispositivos móviles pierde el 10% de las formas primitivas que le permiten diseñar el 90% de las interfaces de usuario.ACS .
En mi experiencia, para reducir significativamente los problemas de desarrollo de software, debe seguir algunas reglas simples al diseñar interfaces de usuario.
En primer lugar, debe decidir un esquema de navegación general, en el que, como un árbol de Año Nuevo, puede colgar sin dolor cada vez más elementos de interfaz nuevos. En este sentido, para los sistemas de control automatizados en mi práctica, se ha demostrado el esquema más efectivo, que se usa ampliamente en varios IDE .
No daré un ejemplo de IntelliJ IDEA o interfaz PhpStorm aquísin embargo, intentaré diseccionar los componentes principales de dicha interfaz de usuario en partes componentes, desde el punto de vista de un analista de un sistema de control automatizado.
La interfaz, construida de acuerdo con este esquema, contiene un panel vertical plegable a la izquierda, que proporciona navegación por todo el sistema. La presencia de un panel vertical con secciones que contienen menús jerárquicos en realidad asegura la implementación de la regla de los " tres clics ".
Cada una de las opciones del menú de la barra de navegación principal proporciona acceso a formularios-listas de objetos. Las listas de objetos (catálogos) y formularios (tarjetas) que muestran estos objetos forman la mayor parte de la interfaz de usuario. La unificación de estos dos tipos de formularios en el marco del proyecto y la formación de una estructura de navegación sobre su base puede reducir significativamente el número de solicitudes de los usuarios asociadas con las deficiencias en la documentación del usuario.
En el marco de la descripción de cualquier formulario de lista, el diseño debe determinar:
- lista de campos de atributos mostrados;
- Requisitos para los modos de visualización de lista (visualización predeterminada, agrupación, clasificación);
- requisitos para la forma subordinada asociada con el elemento de la lista (tarjeta de vista rápida (tabla));
- requisitos para el panel de filtro (selección de registros de acuerdo con una lista dada de atributos);
- descripción de las operaciones del grupo (acciones simultáneas en varios elementos de la lista, por ejemplo: comparar elementos de la lista, cambiar atributos para varios elementos de la lista, cambiar los derechos de acceso para varios elementos de la lista);
- descripción de formularios (paneles) de informes estadísticos operativos (seguimiento) basados en los resultados de la selección de la lista;
- una descripción de los requisitos para la impresión de informes y un algoritmo para su generación;
- requisitos para notificar a los usuarios (sistemas externos) cuando los objetos cambian.
Al diseñar formularios de lista, las siguientes reglas han funcionado bien:
:
- ;
- , (CRUD, , ..) ;
- /;
- lista de posibles mensajes de información;
- formas de ver el historial de cambios de objetos.
Algunas palabras sobre la caja de herramientas. Como resultado de prueba y error durante la implementación de varios proyectos gubernamentales, los siguientes tres enfoques para el diseño de interfaces han demostrado ser los más efectivos.
- En caso de que, durante el desarrollo, se requieran cambios en las interfaces existentes, no debe reinventar la rueda. Aquí Paint.NET se mostró lo mejor de todo (con la ayuda de la cual, por cierto, se prepararon imágenes para este artículo). No tiene sentido volver a dibujar los formularios, es más fácil cambiar la captura de pantalla terminada.
- , — « », MS Visio . , , , , MS Visio, , , Windows.
- , - , . , , . DHTMLX. XML-, , . (view), , . , , MS Visio. , , , « ».
Repetidamente, dando todos estos argumentos a desarrolladores avanzados, lejos de los problemas del cliente, vi su mirada desvanecida y escuché su evaluación experta de la miseria y la sobrecarga de la interfaz de usuario propuesta. Sin embargo, con el tiempo, después de analizar la experiencia de varios proyectos, noté un patrón sorprendente: si un programador critica con celo el atraso y la complejidad de las interfaces de usuario desarrolladas, esta es una señal segura de que el cliente aceptará una interfaz de este tipo con una explosión.
Andamios y encofrados
Normalmente la gente piensa mucho. Pero el problema es que piensan en problemas, no en soluciones a estos problemas.
David Allen
En la construcción de casas, se utilizan muchas estructuras auxiliares que, una vez finalizada la construcción, son completamente innecesarias. Se trata de andamios y encofrados . Sorprendentemente, incluso los no profesionales no intentan discutir la necesidad de comprar y mantener estas estructuras. En la industria de TI, por el contrario, a menudo se ve a un analista "experimentado" luchando por crear inmediatamente la documentación del proyecto que cumpla con todos los requisitos.
Sin embargo, en mi opinión, sin el registro preventivo y la aprobación de las soluciones de diseño, la documentación de diseño creada es adecuada solo para el cierre formal del contrato y en el futuro perjudica la operación más de lo que ayuda. Sin embargo, las soluciones de diseño y los prototipos descritos anteriormente no son las únicas "estructuras auxiliares" en el trabajo analítico.
A primera vista, parece que todo depende de la experiencia del analista, y es imposible regular el uso de estos trabajos auxiliares. Por ejemplo, ¿cómo tener en cuenta y regular el trabajo de un analista que se pasó todo el día visitando a un cliente y al día siguiente traía tres gigabytes de todo tipo de documentos? ¿O que el analista pasó una semana estudiando estos documentos? ¿Esto es bueno o malo? Y realmente no puede responder esa pregunta si no conoce los resultados que tienen sentido a la luz de la implementación del proyecto.
Por eso, en el marco de nuestro proyecto, se realizó una clasificación del trabajo analítico realizado en función de los resultados obtenidos. Además de la solución de diseño,La mayoría de los proyectos de software en los que tuve que participar requerían que el analista desarrollara materiales analíticos de los siguientes tipos.
- Análisis de documentos : un informe basado en los resultados del análisis de los documentos reglamentarios del cliente o la documentación del proyecto.
- Revisión analítica : un informe sobre los resultados del análisis de soluciones al problema que ha surgido (como regla, un análisis comparativo de nuevas tecnologías o tendencias del mercado).
- Encuesta de información : un informe sobre los resultados de un estudio de los procesos comerciales existentes del cliente (formación del modelo tal como está - " tal cual ").
- — , (use case). legacy-.
- — , ( ).
- — , .
El segundo paso hacia un diseño predecible fue definir requisitos específicos para el trabajo analítico previsto. Con base en estos requisitos, se definió una plantilla de descripción del problema JIRA para cada tipo de material analítico que se está desarrollando.
| Plantillas de descripción de tareas de análisis | |
|---|---|
| Tipo de material | Descripción típica del establecimiento de un problema en JIRA (resultados requeridos del trabajo analítico) |
| 1. Análisis de documentos | 1.1. Identificar la lista de cambios en relación a la versión anterior del documento. |
| 1.2. Revelar los términos que introduce el documento | |
| 1.3. Identificar y describir los clasificadores de dominio normativos e informales que se identifican en este documento. | |
| 1.4. Identificar secciones de documentos que regulan procesos automatizados. | |
| 1.5. Identificar ambigüedades y contradicciones. | |
| 1.6. | |
| 1.7. | |
| 2. | 2.1.
|
| 2.2. (, , , ) | |
| 2.3. | |
| 2.4. | |
| 3. | 3.1. , .
|
| 3.2. () , | |
| 3.3. ( ) | |
| 3.4. ( , , ) | |
| 3.5. | |
| 3.6. ( ) | |
| 3.7. ( ) | |
| 4. | 4.1. |
| 4.2. . | |
| 4.3. | |
| 4.4. | |
| 4.5. | |
| 4.6. | |
| 4.7. | |
| 4.8. | |
| 4.9. | |
| 4.10. | |
| 4.11. | |
| 4.12. | |
| 4.13. | |
| 5. | 5.1. () |
| 5.2. () | |
| 5.3. () | |
| 5.4. ( ) | |
| 5.5. ( ) | |
| 5.6. | |
| 6. | 6.1. , ( , ) |
| 6.2. ( , ) | |
| 6.3. ( , , , — data mining) | |
| 6.4. | |
| 7. | 7.1. |
| 7.2. Desarrollar un plan de estudios funcional | |
| 7.3. Preparar una presentación | |
| 7.4. Prepare una lista de conceptos básicos y sus definiciones. | |
| 7.5. Prepare una lista de verificación (tarea de prueba para determinar el nivel de capacitación) | |
| 7.6. Prepare una grabación de video de la lección | |
El enunciado de la tarea para el desarrollo de materiales analíticos implica una breve descripción de los resultados requeridos y no una descripción de los procesos de análisis. Entonces, por ejemplo, se recomienda evitar frases como "realizar un análisis de dominio ..." o "estudiar el documento".
Un plan para el maestro
Todo debe expresarse de la manera más simple posible, pero no más simple.
Albert Einstein
A menudo, cuando se trata de programar el trabajo de análisis y programación, existe mucha controversia acerca de cómo estimar el momento de los resultados en este caso. Sin embargo, el análisis anterior de esta actividad creativa nos permite suponer que todavía es posible en el marco de un proyecto de software. El primer paso hacia esto es dividir el trabajo de diseño del sistema en partes que se pueden verificar con una frecuencia de al menos una vez a la semana. Es necesario esforzarse para garantizar que los costos laborales del analista para la formación de una solución de diseño no excedan los 5 días hábiles (en términos de volumen, dicha solución de diseño debe constar de aproximadamente 20-30 páginas, de acuerdo con GOST R ISO / IEC 15910-2002). En consecuencia, de acuerdo con los mismos estándares, un programador debería tomar un máximo de 3 horas para revisar la misma solución de diseño.
Es importante entender que no es necesario realizar un proyecto técnico a partir de una solución de diseño . La solución de diseño debe cubrir solo un pequeño grupo de requisitos interrelacionados, cuyo resultado se puede presentar al cliente.
También es importante evitar caer en la trampa de la que advierten Mary y Tom Poppendieck al dar forma a una decisión de diseño., es decir, no convertirse en rehén del mito de que una especificación detallada creada de antemano está garantizada para reducir las pérdidas. Como regla general, al acordar una solución de diseño, el cliente intenta meter todo lo que puede recordar en este documento. Por lo tanto, al acordarlo, es importante asegurarse de contar con el mínimo necesario que garantizará el paso exitoso de las pruebas preliminares. Al mismo tiempo, la clave del éxito no es solo una combinación de calidad, tiempo y costo, sino también la satisfacción de los participantes del proyecto con sus resultados.
Como regla general, para obtener los plazos para la realización de las tareas de análisis, es suficiente una evaluación experta del propio contratista, pero en caso de disputas, se puede aplicar un enfoque pragmático .... Para aumentar la objetividad de la evaluación de la intensidad laboral de las tareas para el análisis, se puede utilizar una calculadora en línea , que le permite planificar y estimar los costos laborales para realizar el trabajo analítico. Con esta herramienta, puede crear una lista de trabajos planificados, aclarar su redacción, según las particularidades del proyecto. Para cada una de las obras previstas se tiene en cuenta la estimación mínima, máxima y más probable de los costes laborales. Como resultado del cálculo, se forma la complejidad esperada de la tarea y se calcula la reserva de tiempo óptima, que debe dejarse para el seguro. La descripción generada de la configuración del problema para el análisis se puede copiar directamente en el campo de descripción del problema de JIRA.
Además de los atributos generales descritos en el artículo " JIRA: Límites del proyecto", Para cada problema del tipo" análisis "en JIRA, se determinó empíricamente el siguiente conjunto de atributos adicionales (personalizados).
| Atributos adicionales de la tarea de "análisis" | |
|---|---|
| Nombre del Atributo | Descripción |
| Información general | |
| Tipo de material | Tipo de materiales analíticos:
|
| Resultado de la solución | |
| Versión actual | El analista responsable cambia manualmente el número de la versión actual del material analítico cada vez que se carga el material analítico correspondiente en el repositorio de documentación. El número consta de dos partes, separadas por un punto: [A]. [B].
|
| , | |
| () | |
Teniendo en cuenta lo anterior, aclaremos la secuencia de acciones del analista dada anteriormente sobre la implementación de tareas del tipo "análisis" en interés del desarrollo de software.
1. Si es necesario, el analista responsable debe programar tareas en JIRA para realizar encuestas de información con los representantes de los clientes (estas tareas están vinculadas a los requisitos relevantes).
Es aconsejable, antes de la reunión, como primera aproximación, crear diseños de interfaz de usuario que se puedan discutir con el cliente. Al realizar una encuesta de información, es necesario discutir con el cliente el proceso principal del negocio, desde su punto de vista (historia de usuario - historia de usuario), formas alternativas en las que el cliente ve el resultado final.
A menudo me encontré con la opinión de que la base de una encuesta de información es entrevistar a un empleado competente que contará en detalle sobre las características del proceso automatizado. Sin embargo, lo que es bueno para el desarrollo en interés de un cliente comercial puede tener las consecuencias más inesperadas para un gobierno. En repetidas ocasiones me he encontrado con una situación en la que resultó que la descripción del proceso, formada sobre la base de las historias de los veteranos canosos, contradice los requisitos clave de los documentos reglamentarios actuales. Y esto se explica no por el hecho de que el analista malinterpretó algo, sino por el hecho de que el veterano "hizo esto toda su vida".
Por tanto, antes de reunirse con expertos en la materia, es necesario analizar los documentos normativos desde el punto de vista de la regulación del proceso destinado a la automatización. Al mismo tiempo, es importante entender que los documentos regulatorios tampoco son la verdad última. A menudo, en un análisis imparcial, los documentos regulatorios siempre contienen ambigüedades y contradicciones (la excepción, por regla general, son los documentos “escritos con sangre”). Estos son algunos de los desacuerdos más comunes a los que debe prestar atención:
- violación de los principios básicos de clasificación , por ejemplo, cuando se mezclan diferentes signos dentro del mismo grupo (rojo, verde, cálido);
- construcción de documentos de informes basados en atributos, que no están previstos;
- ;
- - ;
- — - , .
La resolución de estos conflictos regulatorios es una de las cuestiones clave al reunirse con los representantes de los clientes. Para dejar constancia de esta decisión, como resultado de la encuesta de información se debe elaborar un protocolo con indicación de los participantes, lugar y hora. El protocolo se presenta al cliente para su aclaración (se adjunta un correo electrónico a la tarea correspondiente). Después de eso, la tarea para la encuesta de información se puede transferir al estado "completado". Esta tarea JIRA se transfiere al estado "cerrado" después de recibir la confirmación del cliente sobre la aprobación del protocolo.
2. Sobre la base de los requisitos especificados y los resultados de las encuestas de información, se forma una solución de diseño. El analista responsable debe coordinarlo con el director del proyecto y los programadores (para cada uno de ellos se crean las subtareas adecuadas). Si la solución de diseño no ha pasado la aprobación interna durante la jornada laboral, la tarea se transfiere al estado "pendiente" (una señal para el director del proyecto). Una vez aprobada la aprobación interna, la solución de diseño se envía al cliente para su revisión (si es necesario, aprobación). Todos los detalles del envío se registran en los comentarios de la tarea. Mientras que la solución de diseño está del lado del cliente, la tarea se transfiere al estado "pendiente".
3.Si se acuerda la solución del proyecto (o si está claro que la aprobación se está retrasando y los plazos se están agotando), entonces, sobre esta base, el analista responsable formula tareas de desarrollo, prueba y documentación. En este caso, es necesario realizar una evaluación preliminar de los costos laborales para la implementación de la solución de diseño (como la suma de los costos laborales de las tareas de desarrollo asociadas a esta solución de diseño). Con base en esta evaluación, es necesario aclarar el momento de implementación de los requisitos relacionados.
4. Después de un acuerdo con el cliente (una carta que confirma este hecho se guarda en JIRA), la tarea de preparar una solución de diseño se puede transferir al estado "completado".
Continuará
Actualmente, el diseño de software para clientes gubernamentales se organiza con mayor frecuencia de acuerdo con los requisitos de la serie GOST 34. Al mismo tiempo, abogando por el cumplimiento exacto de la documentación de diseño final con este GOST, la mayoría de los representantes del cliente a menudo "olvidan" que, además de la documentación que se proporciona para probar el software desarrollado, el cliente debe aprobar las soluciones de diseño en el marco de la aprobación del borrador y los diseños técnicos. E incluso en el caso de que se acuerde el borrador y los diseños técnicos, no es infrecuente que se ignore el contenido en aras de plazos poco realistas en total conformidad con el formulario. Esto es especialmente cierto para el diseño de sistemas que no están directamente relacionados con la seguridad humana. Entonces, en uno de los proyectos, un subdirector "enseñó la vida"hablando de cómo construyó un proyecto técnico de 500 páginas usando Wikipedia en una noche. Como regla, personas completamente diferentes tienen que desenredar los resultados de tales "decisiones de diseño".
En estas difíciles condiciones, los enfoques descritos aquí le permiten organizar una construcción iterativa de la funcionalidad del software mientras se mantiene la consistencia de las soluciones implementadas, lo que corresponde a los principios del desarrollo de software ajustado . Por otro lado, la configuración de destino de las soluciones de diseño descritas permite, con un costo mínimo, compilar sobre su base documentos que cumplan con los requisitos de "Procusto" del cliente.
La división del trabajo analítico en acciones elementales también permitió coordinar las acciones de varios empleados con diferentes niveles de formación y, como resultado, formar de forma natural una matriz de competencias para los analistas de nuestro proyecto en LANIT , que pienso comentar en el próximo artículo.
PDEste artículo es parte de una serie de artículos llamados " Reglas para la preparación oportuna de software delicioso " que utilizo como una regulación informal del equipo en proyectos de software personalizados en interés de las organizaciones gubernamentales. Esta serie incluye los siguientes artículos:
- " JIRA como remedio para el insomnio y las crisis nerviosas " - la idea principal para organizar el trabajo en un proyecto utilizando JIRA;
- " JIRA: límites del proyecto ": las principales disposiciones para la unificación del proyecto y los requisitos generales para todos los tipos de tareas de JIRA;
- " JIRA: gestión de requisitos ": las características clave de registro, aclaración y control de la implementación de los requisitos del cliente dentro del modelo propuesto;
- "Soluciones de diseño: jugando según sus reglas ”: los aspectos principales de la gestión del trabajo analítico y la formación de enunciados de problemas para los desarrolladores;
En el marco de este ciclo, se está preparando para su publicación:
- " Matriz de competencias del analista " - Criterios para evaluar el nivel de madurez de los analistas en proyectos de software personalizados;
- " Dónde se esconden los problemas en el proyecto " - los criterios (métricas) de la evaluación operativa del estado actual del proyecto de software.
La etiqueta principal de esta serie de artículos es proporcionar una mejora evolutiva en la calidad de los proyectos de software basada en una mayor eficiencia de gestión. En otras palabras, formar métodos de crecimiento aplicados a los niveles del modelo CMMI .
Si ha descubierto cómo usar JIRA de manera más eficiente en su proyecto de software, comparta sus ideas. Solo al describir estas ideas, evite la frase "de alguna manera" y "de alguna manera". Los invito a todos a discutir. Estoy esperando comentarios / sugerencias / dudas / deseos en los comentarios.