Recentemente, um amigo meu reclamou do domínio da gíria inglesa em algumas comunidades profissionais. Eu respondi que era ruim, mas forçado. Assim, ocorre o processo natural de empréstimo, onde o necessário é adaptado e o desnecessário é eliminado. E na própria língua inglesa há muito mais latinismos do que nos anglicismos russos. Afinal, uma vez aqueles que estavam engajados na ciência se comunicavam exclusivamente em latim.
No idioma russo, ainda existe uma pequena área onde é necessário trazê-lo para as realidades modernas. Isso se aplica às práticas ocidentais no campo de gerenciamento de pessoas e equipes. Eles foram pouco estudados pela ciência soviética, enquanto nos anos 90 sua introdução acelerada começou por pessoas que recentemente os consideravam ideologicamente incorretas. O mesmo aconteceu com a economia e em áreas mais específicas, como as relacionadas à produção de software.
Sempre soubemos escrever um excelente código de programa. Mas o negócio de software é mais amplo que a simples programação contratada - é a troca de conhecimento. E, nesse caso, a produção e sua organização são necessárias. Aqui, um papel fundamental é desempenhado pelos sistemas de gerenciamento de coleta de requisitos, nos quais o processo de produção deve ser construído com base na experiência ocidental.
Além disso, os erros típicos de empréstimo são analisados usando exemplos da tradução do livro de Karl I. Wigers, “Software Requirements Development”. No final, o material discutido é resumido usando o modelo V do ciclo de vida dos requisitos de projeto de software.
Sem dúvida, um livro curioso de Karl I. Wigers “Desenvolvimento de requisitos de software” (doravante denominado RTkPO) está se tornando um certo padrão na comunidade da informação russa. Mas o uso das disposições deste livro (emprestadas, originais, traduzidas) fora do conceito do autor levanta questões que eu gostaria de entender.
Esta é uma ilustração do desenvolvimento de requisitos à medida que o projeto avança de cima para baixo, através de três documentos: “
Documento sobre a imagem e os limites do projeto ”, “
Documento sobre casos de uso ”, “
Especificação de requisitos de software ”. Na 3ª edição, os dois primeiros documentos são apresentados como "
Documento de conceito e limites " e "
Documento de requisitos do usuário "
Para criar o documento certo, você deve primeiro entender sua essência. Parece que a chave é desvendar a misteriosa “
imagem e limites do projeto ”: resolvi-o e você pode usar a prática pronta, sem restrições e com grande benefício. Infelizmente, isso funciona apenas com tecnologias simples adquiridas de terceiros. Aspectos
do gerenciamento de equipes estão diretamente relacionados às características de uma cultura estrangeira, e tudo não é fácil lá. As diferenças culturais são a parte visível do iceberg de todo o sistema de estereótipos étnicos
subconscientes de comportamento. Mas não controlamos o domínio do inconsciente, ou apenas o controlamos parcialmente.
No entanto, nem tudo é tão desesperador. Precisamos encontrar associações de sua terminologia com a nossa prática. Analisaremos o "
Documento sobre a imagem e os limites do projeto ". Os limites de um projeto são o
escopo do projeto . Isso deve ser traduzido como "
carga de trabalho ". Não está no dicionário? Infelizmente. Você pode dar uma olhada no manual em inglês:
escopo do projeto - parte do planejamento do projeto, incluindo o processo de determinação e documentação dos objetivos específicos do projeto, resultados, tarefas, custos e prazos . Existe um procedimento específico, por que não chamá-lo de "
limites do projeto "? Nesse caso, surgirão problemas com a integração de nossa própria experiência passada: afinal, planejamos e, em particular, determinamos o escopo do trabalho antes.
Quando a tradução do dicionário falha, é necessário procurar um modelo conceitual simples que ilustra o uso do termo controverso em uma área de assunto relacionada. Uma transferência posterior de um modelo tão simples de divulgação para o solo nativo nos permite encontrar correspondências linguísticas. O modelo de restrições triplas é uma introdução ao gerenciamento de projetos.
Este modelo revela a relação entre os termos “
tempo de execução ”, “
custo ”, “
quantidade de trabalho ” (tempo, custo, escopo), que são colocados na forma de um triângulo equilátero, implicando que a mudança de um lado deste triângulo leva a uma mudança no total.
Às vezes, o
Project Vision não é traduzido como uma "
imagem do projeto ", mas como um "
conceito do projeto ", mas isso não adiciona clareza.
A declaração de visão do projeto no manual é definida como "uma
visão idealista dos resultados comerciais desejados que serão obtidos após a conclusão bem-sucedida do projeto ". Geralmente usamos o termo “
objetivos do projeto ” e formulamos essas tarefas com uma parte do pessimismo doméstico. Se o chamarmos de “a
imagem do projeto ”, é improvável que isso ajude a manifestar o otimismo ocidental em seu próprio solo. No total, o primeiro documento pode ser chamado de "
Objetivos do projeto e escopo do trabalho ". E nada misterioso.
Acredita-se que tais termos não devam ser traduzidos, mas use o idioma inglês no projeto. Isso funciona apenas em parte, limitando bastante o círculo de pessoas que são especialistas em assuntos. As habilidades linguísticas básicas não são suficientes quando questões tecnológicas se relacionam com diferenças étnico-culturais.
Aqui está um exemplo típico do RTkPO: "Os
requisitos devem ser declarados sequencialmente, por exemplo," o sistema será ... "ou" o usuário será ... ", o verbo ativo e o resultado observado ... Você pode usar" should "como sinônimo de" will ", mas evite “deveria”, “talvez”, “poderia” e palavras semelhantes, das quais não está claro se a ação é necessária . ”
Você pode pensar que este é um guia pronto para ação. De fato, esta tradução não ajuda a descobrir, mas confunde tudo ainda mais. Além disso, o original em inglês não é a verdade suprema, mas a expressão de uma certa perspectiva sobre a modalidade da língua inglesa. A visão está consagrada no padrão RFC2119 **, que esclarece as regras para o uso de palavras-chave em inglês no campo de gerenciamento de requisitos (
por exemplo, deve, deve, deve, pode ). Por exemplo, nesta norma,
deve significar "
que a definição é um requisito absoluto da especificação ". No entanto, o autor conheceu modelos de documentos com uma proibição direta do uso de
mosto (uma explicação dessa posição está disponível na Internet ***).
O próximo nível de detalhe dos requisitos é o "
Documento de Caso de Uso ". No RTkPO, é indicado que define casos de uso, cenários e tabelas de
resposta a eventos . A tradução de "
casos de uso " como "
casos de uso " simplifica desnecessariamente a visão das coisas (portanto, na prática, o anglicismo de casos de usuários tornou-se mais firmemente estabelecido). O software moderno deve ter proteção contra hackers e proteção contra um tolo, mas considere isso uma opção de uso - a violência contra o idioma russo. Para tradução, são propostos "cenários de interação".
De fato, o modelo de
resposta a
eventos é conhecido por nós. No ensino médio, é estudado como "
impacto - flutuação -> resposta ". Sob as mesmas influências, a resposta do sistema pode variar devido a flutuações aleatórias. No software do usuário, essas geralmente são várias situações de erro. Além disso, no nível conceitual, os efeitos ambientais devem ser diferenciados dos efeitos do usuário. Um nome mais ou menos adequado para esse nível de requisitos é "
Requisitos do sistema " ou já "
Requisitos do produto de software ", embora a terminologia não tenha sido estabelecida e sejam encontradas opções muito diferentes (por exemplo, na edição mais recente, o nome "
Documento de requisitos do usuário " é usado, que automaticamente exclui sistemas embarcados da consideração).
A essência do desenvolvimento dos requisitos desse nível é a criação de um modelo especulativo detalhado de software que funciona em um mundo externo idealizado. Portanto, um ponto importante é estabelecer limites e fazer suposições. “A
cor do carro pode ser qualquer, desde que seja preta ” - então Henry Ford redesenhou o requisito comercial da cor do carro em uma suposição. No entanto, outra vez, para atender aos requisitos comerciais de limpeza de automóveis, tornou-se necessário fabricar vidro aerodinâmico não plano. Os engenheiros da Ford disseram que era tecnicamente impossível. Ford encontrou os jovens inventores do lado.
O nível inferior é representado pela "
Especificação de Requisitos de Software ", que inclui "
restrições ", "
interface externa ", "
atributos de qualidade " e, na verdade, "
requisitos funcionais ". Este é o último documento da figura, infelizmente, as questões dos testes subsequentes não são abordadas. Portanto, para formular a definição, o RTkPO é forçado a usar o conceito de requisitos de negócios: “
requisitos funcionais determinam a funcionalidade do software que os desenvolvedores devem criar para que os usuários possam concluir suas tarefas dentro da estrutura de requisitos de negócios ”
No lado do teste, a definição é mais simples de construir: "
Requisitos funcionais são requisitos que estão sendo testados ". Isso deve ser entendido como a capacidade de testar cada requisito funcional com um teste no sentido clássico (com o veredicto - aprovado ou reprovado). O contrário, a rigor, não é verdade: alguns testes podem existir por conta própria. Mas a presença de tais testes é um indicador de omissões no trabalho sobre requisitos. Afinal, o teste verifica qualquer seção do código que não apareceu sozinha, mas como resultado da execução de um determinado requisito funcional.
Os processos modernos de desenvolvimento de software maduros estão tentando levar o componente de medição aos estágios iniciais da fabricação de produtos de software. Sem entrar em detalhes - na maioria das vezes, esses são todos os tipos de métricas de cobertura. Um dos indicadores da qualidade do produto futuro é o percentual de cobertura com testes de requisitos funcionais, que é calculado usando uma tabela (matriz) de cobertura (matriz de rastreabilidade). É possível incluir um requisito não-funcional na matriz, mas no trabalho futuro ele será marcado como não testável e, o mais importante, os testadores o avaliarão como inútil. Parece que uma "
especificação completa
de requisitos de software " com uma lista de requisitos não funcionais é muito útil para programadores. E talvez isso acontecesse se, após a compilação, eles olhassem para lá, pelo menos de tempos em tempos.
A grande maioria dos requisitos não funcionais pode ser escrita de maneira funcional. Parafraseando, quase todos os requisitos não funcionais de um sistema ou produto de software podem ser processados em um ou mais requisitos funcionais.
Os atributos de qualidade no RTkPO se enquadram parcialmente nos requisitos funcionais, o que é absolutamente verdadeiro. No entanto, as limitações e a interface externa do RTkPO são definidas da seguinte forma: “
outros requisitos não funcionais descrevem as interações externas entre o sistema e o mundo externo, restrições de design e implementação. "Restrições (restrições) estão relacionadas à escolha da possibilidade de desenvolver a aparência e a estrutura do produto ". Os subsistemas de comunicação com o mundo externo sempre têm uma interface funcional e sujeita a testes.
As restrições podem ser requisitos funcionais? Definitivamente sim, se você as escrever de forma invertida como oportunidade. Por exemplo, o produto deve ser mais rápido que o dos concorrentes (caso contrário, não é necessário - uma restrição muito severa). Antes de mais nada, estamos falando sobre a novidade das decisões tomadas, documentadas, inclusive na forma de requisitos. Mas é claro que o sistema deve ter um módulo para medir os parâmetros detectados dessa velocidade e em um estágio inicial.
Portanto, “
Especificações Funcionais ” é um nome estabelecido para especificações de nível inferior na forma de um documento formatado ou como um banco de dados sob o controle de software especializado.
O que acontece com os requisitos a seguir? Além dos desenvolvedores (programadores), os engenheiros de teste e os engenheiros de QA (Quality Assurance) trabalharão com os requisitos. "Teste" pode ser traduzido como "verificação", mas aparentemente o "teste" de empréstimo ocorreu. Traduzir o controle de qualidade novamente requer um modelo de divulgação - aqui, quais princípios o sustentam. Primeiro, “Adequado para o
propósito ” (o produto deve ser adequado ao objetivo), segundo, “
primeira vez certa ” (e os erros devem ser eliminados) e, terceiro, independência do projeto. Isso é "
aceitação ", os princípios subjacentes à conhecida aceitação militar e à lendária aceitação do estado.
As especificações dos requisitos formarão a base de outros documentos de projeto. No mínimo, os requisitos serão usados no desenvolvimento da
documentação do
usuário . É geralmente aceito que o teste começa com
um plano de teste e termina com um
relatório de teste - documentos diretamente relacionados às especificações. Pode-se ver a figura no RTkPO de maneira diferente - como um modelo generalizado do processo de desenvolvimento de software (ou um modelo de ciclo de vida de software). Nesse modelo, os documentos finalizados são os pontos de entrada / saída entre as fases do processo.
Em ordem cronológica, os documentos serão apresentados da seguinte forma: requisitos de negócios (como parte do escopo do projeto), requisitos de sistema (PO), requisitos funcionais, plano de teste, relatório de teste, documentação do usuário. A linha entre os dois documentos é a fase do processo. Os modelos são frequentemente desenhados na forma de ciclos repetidos ou espirais; no entanto, um simples eixo cronológico é mais visível. Então, a primeira e a última fase do processo são indicadas não por um segmento, mas por um raio. Nas apresentações modernas, o eixo do tempo é dobrado no meio da fase de codificação na forma da letra “
V ”, obtendo o chamado
modelo-V .
As linhas tracejadas mostram conexões ignorando o eixo cronológico, mostrando a capacidade de iniciar alguns trabalhos com antecedência. Por exemplo, com os requisitos de negócios formulados, você já pode dizer algo sobre a documentação do usuário do produto, e os requisitos formados para o sistema fornecerão um modelo de software futuro, cuja qualidade já pode ser avaliada.
Mas a principal função dessas linhas é mostrar a escalabilidade (simplificação) do modelo em V.
O suporte a todas as fases e documentos é sempre um prazer caro e um motivo muito comum para perder para mais concorrentes móveis . Por exemplo, um indivíduo trabalha assim: requisitos de negócios -> desenvolvimento (codificação) -> documentação do usuário. Esta é a linha superior quebrada do corte. As empresas de terceirização, em regra, pulam as fases inferiores sem gastar dinheiro com especificações funcionais e são limitadas por um ou outro tipo de requisitos de sistema (por exemplo,
cenários de interação ). Para produtos do mesmo tipo, geralmente existe um padrão corporativo e, a partir da fase de codificação, é emitido um determinado relatório de teste interno dos desenvolvedores para iniciar a fase de controle de qualidade / aceitação.
O modelo V fundamental ajuda a esclarecer áreas de responsabilidade. Por exemplo, um funcionário desempenha o papel de Engenheiro de aceitação (QA) ou Engenheiro de teste, dependendo da fase em que trabalha. Não importa se ele está atribuído a um projeto ou departamento específico. O mesmo se aplica ao analista, designer, desenvolvedor - a capacidade de desempenhar todas essas funções por uma pessoa não refuta o modelo V. Para o Engenheiro de Aceitação (QA) e o analista, a base é "Requisitos do Sistema", eles trabalham com o software desenvolvido como uma caixa preta. Para os envolvidos nas fases, design, desenvolvimento e teste são uma caixa branca, embora em uma extensão diferente.
Em conclusão, vale ressaltar que o modelo V ainda é uma apresentação (neste caso, ilustrando a evolução do design dos requisitos). Este não é um guia direto para a ação; os processos reais de desenvolvimento de software são mais complicados. Mas é difícil subestimar seu potencial revelador.
Karl I. Wigers "Desenvolvimento de Requisitos de Software".
** Palavras-chave para uso em RFCs para indicar o nível de exigência (https://tools.ietf.org/html/rfc2119)
*** Deve - não use a obrigação, porque ninguém definiu como a obrigação é diferente da obrigação. Além disso, deve ter realizado em tribunal, não deve. Concedido, deve soa mais forte, certo? Quero dizer, se o seu chefe lhe disser que você "deve" fazer alguma coisa, bem, você fará. Mas, ao escrever requisitos, mantenha as coisas simples e apenas use (http://www.reqexperts.com/blog/2012/10/using-the-correct-terms-shall-will-should)