Recientemente, un amigo mío se quejó del dominio de la jerga inglesa en algunas comunidades profesionales. Le respondí que era malo, pero forzado. Así, el proceso de préstamo natural se lleva a cabo, donde lo necesario se adapta y lo innecesario se elimina. Y en el idioma inglés en sí hay muchos más latinismos que en los anglicismos rusos. Después de todo, una vez que los que se dedicaban a la ciencia se comunicaban exclusivamente en latín.
En el idioma ruso, queda un área pequeña donde se requiere llevarlo a las realidades modernas. Esto se aplica a las prácticas occidentales en el campo de la gestión de personas y equipos. Fueron poco estudiados por la ciencia soviética, mientras que en la década de los 90 su introducción acelerada comenzó por personas que recientemente los consideraron ideológicamente incorrectos. Así sucedió con la economía y en áreas más específicas, como las relacionadas con la producción de software.
Siempre supimos cómo escribir un excelente código de programa. Pero el negocio del software es más amplio que la simple programación contratada: es el intercambio de conocimientos. Y si es así, se requiere producción y organización. Aquí, los sistemas de gestión de recopilación de requisitos juegan un papel clave, donde el proceso de producción debe basarse en la experiencia occidental.
Más adelante en el artículo, los errores típicos de endeudamiento se analizan utilizando ejemplos de la traducción del libro de Karl I. Wigers "Desarrollo de requisitos de software". Al final, el material discutido se resume utilizando el modelo V del ciclo de vida de los requisitos de diseño para el software.
Sin lugar a dudas, un curioso libro de Karl I. Wigers "Desarrollo de requisitos de software" (en lo sucesivo, RTkPO) se está convirtiendo en un cierto estándar en la comunidad de información rusa. Pero el uso de las disposiciones de este libro (prestado, original, traducido) fuera del concepto del autor plantea preguntas que me gustaría entender.
Esta es una ilustración del desarrollo de requisitos a medida que el proyecto avanza de arriba a abajo, a través de tres documentos: "
Documento sobre la imagen y los límites del proyecto ", "
Documento sobre casos de uso ", "
Especificación de requisitos de software ". En la 3ª edición, los dos primeros documentos se presentan como "
Documento de concepto y límites " y "
Documento de requisitos del usuario "
Para crear el documento correcto, primero debe comprender su esencia. Parece que la clave es desentrañar la misteriosa "
imagen y límites del proyecto ": resuelta, y puede usar la práctica ya hecha sin restricciones y con gran beneficio. Desafortunadamente, esto solo funciona con tecnologías simples compradas a terceros. Los aspectos
de la gestión del equipo están directamente relacionados con las características de una cultura extranjera, y no todo es fácil allí. Las diferencias culturales son la parte visible del iceberg de todo el sistema de estereotipos étnicos
subconscientes de comportamiento. Pero no controlamos el reino del inconsciente en absoluto, o solo lo controlamos parcialmente.
Sin embargo, no todo es tan desesperado. Necesitamos encontrar asociaciones de su terminología con nuestra práctica. Analizaremos el "
Documento sobre la imagen y los límites del proyecto ". Los límites de un proyecto son el
alcance del proyecto . Esto debería traducirse como "
carga de trabajo ". No en el diccionario? Por desgracia Puede echar un vistazo al manual en inglés:
alcance del proyecto: parte de la planificación del proyecto, incluido el proceso de determinación y documentación de los objetivos específicos del proyecto, resultados, tareas, costos y plazos . Hay un procedimiento específico, ¿por qué no llamarlo "
límites del proyecto "? En este caso, surgirán problemas con la integración de nuestra propia experiencia pasada: después de todo, hemos estado planificando y, en particular, determinando el alcance del trabajo antes.
Cuando falla la traducción del diccionario, debe buscar un modelo conceptual simple que ilustre el uso del término controvertido en un área temática relacionada. La transferencia adicional de un modelo de divulgación tan simple al suelo nativo nos permite encontrar coincidencias de idiomas. El modelo de triple restricción es una introducción a la gestión de proyectos.
Este modelo revela la relación entre los términos "
tiempo de ejecución ", "
costo ", "
cantidad de trabajo " (tiempo, costo, alcance), que se colocan en forma de un triángulo equilátero, lo que implica que cambiar un lado de este triángulo conduce a un cambio en todos.
La visión del proyecto a veces se traduce no como una "
imagen de proyecto ", sino como un "
concepto de proyecto ", pero esto no agrega claridad.
La Declaración de visión del proyecto en el manual se define como "una
visión idealista de los resultados comerciales deseados que se obtendrán al completar con éxito el proyecto ". Usualmente usamos el término "
objetivos del proyecto " y formulamos estas tareas con una parte de pesimismo interno. Si lo llamamos "la
imagen del proyecto ", es poco probable que esto ayude a manifestar el optimismo occidental en su propio territorio. En total, el primer documento puede llamarse "
Objetivos del proyecto y alcance del trabajo ". Y nada misterioso.
Se cree que dichos términos no deberían traducirse, sino utilizar el idioma inglés en el proyecto. Esto solo funciona en parte, limitando en gran medida el círculo de personas que son expertas en los asuntos. Las habilidades básicas del lenguaje no son suficientes cuando los problemas tecnológicos se relacionan con las diferencias etnoculturales.
Aquí hay un ejemplo típico de RTkPO: "Los
requisitos deben establecerse secuencialmente, por ejemplo," el sistema será ... "o" el usuario será ... ", luego el verbo activo, y luego el resultado observado ... Puede usar" debería "como sinónimo de" voluntad ", pero evitar "debería", "tal vez", "podría" y palabras similares, de las cuales no está claro si la acción es necesaria ".
Puede pensar que esta es una guía de acción preparada. De hecho, esta traducción no ayuda a resolverlo, pero confunde todo aún más. Además, el original en inglés no es la verdad última, sino la expresión de una cierta perspectiva sobre la modalidad del idioma inglés. La vista está consagrada en el estándar RFC2119 **, que aclara las reglas para usar palabras clave en inglés en el campo de la gestión de requisitos (
por ejemplo, must, must, should, may ). Por ejemplo, en este estándar,
debe significar "
que la definición es un requisito absoluto de la especificación ". Sin embargo, el autor cumplió con las plantillas de documentos con una prohibición directa sobre el uso del
mosto (una explicación de esta posición está disponible en Internet ***).
El siguiente nivel de detalle para los requisitos es el "
Documento de caso de uso ". En RTkPO, se indica que define casos de uso, escenarios y tablas de
respuesta a eventos . La traducción de "
casos de uso " como "
casos de uso " simplifica innecesariamente la visión de las cosas (por lo tanto, en la práctica, el anglicismo de los casos de usuarios se ha establecido más firmemente). El software moderno debería tener protección contra la piratería y la protección de un tonto, pero considere esta una opción de uso: la violencia contra el idioma ruso. Para la traducción, se proponen "escenarios de interacción".
De hecho, el modelo de
respuesta a eventos es conocido por nosotros. En la escuela secundaria, se estudia como "
impacto - fluctuación -> respuesta ". Bajo las mismas influencias, la respuesta del sistema puede variar debido a fluctuaciones aleatorias. En el software del usuario, estas suelen ser varias situaciones de error. Además, a nivel conceptual, los efectos ambientales deben distinguirse de los efectos del usuario. Un nombre más o menos adecuado para este nivel de requisitos es "
Requisitos del sistema " o ya "
Requisitos del producto de software ", aunque no se ha establecido la terminología y se encuentran opciones muy diferentes (por ejemplo, en la última edición se usa el nombre "
Documento de requisitos del usuario ", que automáticamente excluye los sistemas integrados de la consideración).
La esencia del desarrollo de los requisitos de este nivel es la creación de un modelo de software especulativo detallado que funcione en un mundo externo idealizado. Por lo tanto, un punto importante es establecer límites y hacer suposiciones. "El
color del automóvil puede ser cualquiera, siempre que sea negro ", por lo que Henry Ford rediseñó el requisito comercial para el color del automóvil en una suposición. Sin embargo, en otra ocasión, para cumplir con los requisitos comerciales para la limpieza del automóvil, resultó ser necesario hacer vidrio aerodinámico no plano. Los ingenieros de Ford dijeron que era técnicamente imposible. Ford encontró a los jóvenes inventores a un lado.
El nivel inferior está representado por la "
Especificación de requisitos de software ", que incluye "
restricciones ", "
interfaz externa ", "
atributos de calidad " y en realidad "
requisitos funcionales ". Este es el último documento en la figura, desafortunadamente, las preguntas de las pruebas posteriores no se abordan. Por lo tanto, para formular la definición, RTkPO se ve obligado a utilizar el concepto de requisitos comerciales: "los
requisitos funcionales determinan la funcionalidad del software que los desarrolladores deben construir para que los usuarios puedan completar sus tareas dentro del marco de los requisitos comerciales "
En el lado de las pruebas, la definición es más simple de construir: "
Los requisitos funcionales son requisitos que se están probando ". Esto debe entenderse como la capacidad de probar cada requisito funcional con una prueba en el sentido clásico (con el veredicto: aprobado o reprobado). Lo contrario, estrictamente hablando, no es cierto: algunas pruebas pueden existir por sí mismas. Pero la presencia de tales pruebas es un indicador de omisiones en el trabajo sobre los requisitos. Después de todo, la prueba verifica cualquier sección de código que no apareció por sí sola, sino como resultado de la ejecución de un determinado requisito funcional.
Los procesos modernos de desarrollo de software maduro están tratando de llevar el componente de medición a las primeras etapas de la fabricación de productos de software. Sin entrar en detalles, en su mayor parte se trata de todo tipo de métricas de cobertura. Uno de los indicadores de la calidad del producto futuro es el porcentaje de cobertura con pruebas de requisitos funcionales, que se calcula utilizando una tabla (matriz) de cobertura (matriz de trazabilidad). Es posible incluir un requisito no funcional en la matriz, pero en trabajos futuros se marcará como no comprobable y, lo más importante, los evaluadores lo evaluarán como inútil. Parece que una "
especificación completa
de requisitos de software " con una lista de requisitos no funcionales es muy útil para los programadores. Y esto, tal vez, sería así si, después de la compilación, miraran allí, al menos de vez en cuando.
La gran mayoría de los requisitos no funcionales se pueden escribir de manera funcional. Parafraseando, casi cualquier requisito no funcional para un sistema o producto de software puede procesarse en uno o más requisitos funcionales.
Los atributos de calidad en RTkPO caen parcialmente en requisitos funcionales, lo cual es absolutamente cierto. Sin embargo, las limitaciones y la interfaz externa de RTkPO se definen de la siguiente manera: “
otros requisitos no funcionales describen las interacciones externas entre el sistema y el mundo exterior, las restricciones de diseño e implementación. "Las restricciones (restricciones) se relacionan con la elección de la posibilidad de desarrollar el aspecto y la estructura del producto ". Los subsistemas de comunicación con el mundo exterior siempre tienen una interfaz que es funcional y está sujeta a pruebas.
¿Pueden las restricciones ser requisitos funcionales? Definitivamente sí, si los escribe en forma invertida como oportunidades. Por ejemplo, el producto debería ser más rápido que el de la competencia (de lo contrario, no es necesario, una restricción muy severa). En primer lugar, estamos hablando de la novedad de las decisiones tomadas, documentadas, incluso en forma de requisitos. Pero está claro que el sistema debe tener un módulo para medir los parámetros detectados de esta velocidad, y en una etapa temprana.
Por lo tanto, "
Especificaciones funcionales " es un nombre establecido para especificaciones de nivel inferior en forma de documento formateado o como una base de datos bajo el control de un software especializado.
¿Qué pasa con los requisitos siguientes? Además de los desarrolladores (programadores), los ingenieros de prueba y los ingenieros de control de calidad (QA) trabajarán con los requisitos. "Prueba" se puede traducir como "verificación", pero la "prueba" de préstamo aparentemente tuvo lugar. La traducción de QA nuevamente requiere un modelo de divulgación, aquí, qué principios lo sustentan. En primer lugar, "apto para el
propósito " (el producto debe ser adecuado para el propósito previsto), en segundo lugar, "
correcto la primera vez " ("la primera vez" - se deben eliminar los errores) y en tercer lugar, la independencia del proyecto. Esta es la "
aceptación ", los principios que subyacen a la conocida aceptación militar y la legendaria aceptación del estado.
Las especificaciones de requisitos formarán la base de otros documentos de diseño. Como mínimo, los requisitos se utilizarán en el desarrollo de
la documentación del
usuario . En general, se acepta que la prueba comienza con
un plan de prueba y termina con un
informe de prueba , documentos directamente relacionados con las especificaciones. Uno puede ver la figura en RTkPO de manera diferente, como un modelo generalizado del proceso de desarrollo de software (o un modelo de ciclo de vida del software). En este modelo, los documentos terminados son los puntos de entrada / salida entre las fases del proceso.
En orden cronológico, los documentos se presentarán de la siguiente manera: requisitos comerciales (como parte del alcance del proyecto), requisitos del sistema (PO), requisitos funcionales, plan de prueba, informe de prueba, documentación del usuario. La línea entre los dos documentos es la fase del proceso. Los modelos a menudo se dibujan en forma de ciclos repetitivos o espirales, sin embargo, un eje cronológico simple es más visible. Luego, la primera y la última fase del proceso están indicadas no por un segmento, sino por un rayo. En las presentaciones modernas, el eje de tiempo se dobla en el medio de la fase de codificación en forma de la letra "
V ", obteniendo el llamado
modelo V.
Las líneas discontinuas muestran conexiones que pasan por alto el eje cronológico, lo que muestra la capacidad de comenzar un trabajo por adelantado. Por ejemplo, con los requisitos comerciales formulados, ya puede decir algo sobre la documentación del usuario del producto, y los requisitos formados para el sistema proporcionarán un modelo de software futuro, cuya calidad ya se puede evaluar.
Pero la función principal de estas líneas es mostrar la escalabilidad (simplificación) del modelo V.
Apoyar todas las fases y documentos es siempre un placer costoso y una razón muy común para perder ante más competidores móviles . Por ejemplo, un individuo trabaja así: requisitos comerciales -> desarrollo (codificación) -> documentación del usuario. Esta es la línea discontinua superior del corte. Las empresas de outsourcing, por regla general, omiten las fases inferiores sin gastar dinero en especificaciones funcionales y están limitadas por uno u otro tipo de requisitos del sistema (por ejemplo,
escenarios de interacción ). Para productos del mismo tipo, generalmente hay un estándar empresarial, y desde la fase de codificación se emite un cierto informe de pruebas internas de los desarrolladores para comenzar la fase de QA / aceptación.
El modelo V fundamental ayuda a aclarar áreas de responsabilidad. Por ejemplo, un empleado desempeña el papel de ingeniero de aceptación (QA) o ingeniero de pruebas, dependiendo de la fase en la que trabaja. No importa si está asignado a un proyecto o departamento específico. Lo mismo se aplica al analista, diseñador, desarrollador: la capacidad de cumplir todos estos roles por una sola persona no refuta el modelo V. Para el ingeniero de aceptación (QA) y el analista, la base es "Requisitos del sistema", trabajan con el software desarrollado como una caja negra. Para aquellos involucrados en las fases, el diseño, el desarrollo y las pruebas son una caja blanca, aunque en diferente medida.
En conclusión, vale la pena señalar que el modelo V aún se presenta (en este caso, ilustra la evolución del diseño de los requisitos). Esta no es una guía directa de acción; los procesos reales de desarrollo de software son más complicados. Pero su potencial revelador es difícil de subestimar.
* Karl I. Wigers "Desarrollo de requisitos de software".
** Palabras clave para usar en RFC para indicar el nivel de requisito (https://tools.ietf.org/html/rfc2119)
*** Debe - No use must porque nadie ha definido cómo debe es diferente de must. Además, deberá haber retenido en la corte, no debe. Por supuesto, ¿suena más fuerte, verdad? Quiero decir, si tu jefe te dice que "debes" hacer algo, bueno, lo harás. Pero, al escribir los requisitos, mantenga las cosas simples y solo use (http://www.reqexperts.com/blog/2012/10/using-the-correct-terms-shall-will-should)