Por que se preocupar com especificações detalhadas?

8

Ao escrever um software, qual é o objetivo de escrever uma especificação formal e detalhada de árvore morta? Para esclarecer, uma especificação informal e de alto nível para pessoas que não querem ler o código faz sentido para mim. Porém, uma implementação de referência em código-fonte legível e bem comentado é a especificação mais inequívoca de tudo o que você obterá, já que um computador precisa executá-lo. As especificações formais costumam ser tão difíceis de ler e quase tão difíceis de escrever quanto o código.

Quais benefícios uma especificação formal oferece sobre uma implementação de referência, além de um pouco de documentação sobre qual comportamento é indefinido / definido pela implementação, independentemente de como ele funciona na implementação de referência.

Edit: Como alternativa, o que há de errado com os testes sendo a especificação formal?

dsimcha
fonte
7
Por que tem que ser "árvore morta"? Por que não um wiki ou PDF?
Philip Regan
@ Philip: Não há razão em princípio. É que documentos muito formais tendem a ser escritos em árvores mortas, especialmente em grandes organizações burocráticas como as que estou imaginando.
dsimcha
As especificações de software são ótimas para os programadores usarem por conta própria, mas ainda melhor para os clientes, de modo que definam concretamente suas expectativas em relação ao produto final ... antes de você começar a trabalhar sua mágica.
ToTheBeach 23/03
2
Sou a favor de especificações de alto nível. Apenas detalhes suficientes para que o cliente entenda o que está recebendo e os desenvolvedores entendam o que o cliente deseja. Mais detalhes do que isso e você acabará mantendo documentos em vez de código.
Berin Loritsch 24/03
@Berin: Certo, é isso que eu quis dizer com especificação informal de alto nível. Quando escrevi essa pergunta, estava pensando mais em padrões (por exemplo, compiladores C ++) do que em software comercial.
dsimcha

Respostas:

37

Como você pode saber que terminou, se não sabe como deve ser quando terminar?

O recurso creep irá pegá-lo. Você estará tentando entregar para um cliente e, à medida que o tempo de conclusão chegar, eles descobrirão 10.000 pequenas coisas que absolutamente precisam ter .

Para receber o pagamento, a fim de tirar seu chefe das costas quando o prazo terminar, você precisa conseguir as especificações e dizer: "Todas as minhas estimativas de tempo e custo foram para isso , não para novas coisa que todo mundo decidiu que quer ".

Satanicpuppy
fonte
13
Meu único arrependimento é que tenho apenas um voto a favor por essa sabedoria.
Dan Ray
3
+1. Sabedoria. Dito isso, a última loja em que trabalhei foi um modelo de negócios baseado em assinatura, no qual os clientes continuam pagando pelas licenças existentes enquanto gritam sobre outros recursos que eles apenas precisam ter (por exemplo, você corre o risco de perdê-las se não implementar suas oscilação do escopo - mas eles estão pagando ao mesmo tempo para que você os faça felizes). Mas, normalmente, você não está sendo pago ao implementar a fluência do escopo. Além disso: esse modelo de negócios pode realmente fazer com que os desenvolvedores se sintam como chaves de código sem saída.
Bobby Tables
1
+1 Eu vim para a programação via sistemas de controle de HVAC de engenharia - uma especificação típica para um edifício seria várias centenas de páginas. Os projetos foram aceitos pelo consultor / cliente quando todos os pontos foram marcados - as variações incorriam em custo e prazo estendido. O problema é que, por alguma razão, parece que no desenvolvimento geral de software a especificação deve ser escrita pelo implementador - acho que isso está errado - no HVAC, a especificação veio através de um consultor de construção (embora o implementador possa consultar e desafiar as especificações a qualquer momento).
21411 HorusKol
1
"à medida que o tempo de conclusão chegar, eles descobrirão 10.000 pequenas coisas que eles absolutamente precisam ter" Mas isso só acontece com softwares personalizados. Se você desenvolver um software com encolhimento ou um software interno, isso é feito quando você diz que é feito. Sempre haverá solicitações de recursos adicionais. Alguns deles serão incluídos em uma versão futura, outros não. Não vejo o benefício de especificações detalhadas aqui.
Nikie 24/03
2
@nikie: Conte para a equipe de design da Duke Nukem. Você tem que lidar com controle de qualidade, marketing, phbs que lêem muitas revistas ... Isso ainda importa.
23611 Satanicpuppy
8

As especificações permitem que você pondere sobre as coisas sem ter escrito muito código antecipadamente, que precisaria ser alterado, se a especificação mudar. Considere entre o quadro-negro e a codificação real

É também uma muito boa idéia fazer quando se tem várias partes independentes escrevendo componentes que necessitam para ir junto.


fonte
8

Além de outras boas razões já mencionadas, ter uma especificação formal permite CYA - Cover Your Ass! Se os gerentes / analistas / testadores disserem que você não criou algo corretamente, você pode apontar para as especificações e dizer "Eu criei exatamente como você queria!". Isso inclui itens de baixo nível, como "Todos os dados persistidos na tabela AXX_RGV devem estar em MAIÚSCULAS", "Formulários da Web com menos de 3 campos de entrada devem ter o botão Enviar no canto inferior esquerdo", etc ...

Também para quando as pessoas esquecem coisas em um projeto muito longo e grande, ter uma especificação detalhada para se referir pode ser muito útil. Lembre-se de que a especificação deve ser um Documento Vivo, e se os requisitos mudarem (através do que se espera que seja um processo formal e documentado), o mesmo deve acontecer com a especificação. Sim, isso pode levar mais tempo. Na minha experiência, vale a pena (se for bem feito).

FrustratedWithFormsDesigner
fonte
1
+1 para manter as especificações ao longo da vida útil do projeto.
Chuck Stephanski
6

Uma especificação formal dos requisitos de um programa é necessária porque o engenheiro de software precisa saber o que implementar; o engenheiro de controle de qualidade precisa saber o que testar e o cliente precisa saber o que esperar.

Ter uma especificação permite saber quando você termina de programar.

Adam Crossland
fonte
1
Acredito que o OP estava perguntando sobre a utilidade das especificações detalhadas do projeto. Todo mundo sabe que um documento de requisitos bem escrito é fundamental para o sucesso de um projeto. Não tenho tanta certeza de que as especificações detalhadas do projeto sejam tão úteis hoje quanto eram quando estávamos usando linguagens de programação de nível inferior. Naquela época, uma especificação de projeto de detalhes era apresentada no pseudocódigo do que precisava ser codificado. O código implementado foi verificado no psuedocode durante uma revisão de código para garantir a correção. Essa orientação também teve o efeito colateral de produzir uma subclasse de codificadores que codificaram a partir das especificações.
bit-twiddler
3

Um dos principais benefícios pode ser a segurança. Eu não gostaria de voar em um avião de passageiros em que a especificação dos sistemas de controle fosse uma implementação de referência. Eu realmente quero que alguém especifique o que os sistemas precisam fazer de uma forma que alguém que não esteja intimamente familiarizado com o software possa entender. Eu esperaria que cada requisito fosse totalmente verificado por testes.

Para sistemas menos críticos para a segurança, as especificações são ferramentas de comunicação. Eles devem detalhar o que o sistema precisa fazer com detalhes suficientes para construir e testar o sistema. Como o sistema faz isso é de responsabilidade do código. Os detalhes necessários variarão de acordo com a experiência no domínio da equipe de desenvolvimento e o acesso aos especialistas no domínio.

As especificações devem sempre corresponder aos sistemas implementados. Se forem encontrados erros na especificação, a especificação deverá ser atualizada.

As causas de erro estimadas que eu vi indicam que as falhas de teste são divididas de forma relativamente uniforme entre erros nas especificações, código e testes.

BillThor
fonte
3

Penso que esta questão é o cerne da questão do ciclo de vida ágil versus cascata.

Se você está agilizando, uma premissa básica é que o código associado à interação estreita com o desenvolvedor é melhor e mais rápido que a especificação detalhada. A equipe prioriza o lançamento de novos recursos e alta qualidade sobre outras coisas - como mecanismos formais de comunicação, como especificações detalhadas do projeto. Mas há um comércio aqui - você precisa ter canais de comunicação entre os membros da equipe que permitam que eles perguntem sobre nuances e intenção detalhada do projeto quando necessário.

Se você está fazendo cascata, está trabalhando com a suposição de que o trabalho de preencher o código sob o design detalhado e testá-lo é significativo. E você deseja fornecer às partes interessadas informações precoces sobre como esse trabalho continuará e como será quando terminar. Isso pode estar avaliando o design com o cliente para garantir que você tenha escolhido os recursos que fazem sentido. Pode ser também consultá-lo com especialistas em outras áreas - como análises de segurança, análises de segurança e análises de membros da equipe que precisam se integrar ao seu código. A suposição é de que essas revisões economizarão tempo a longo prazo, pois evitarão que você investigue uma grande quantidade de tempo no desenvolvimento da coisa errada.

Ultimamente, tenho visto uma fusão realmente excelente entre projetos detalhados e ferramentas de comentários de código - JavaDoc, por exemplo. Como os designs mais detalhados são pegadas do código e explicações curtas sobre o que ele fará - isso é mais ou menos a mesma coisa que você esperaria dos comentários do código. Portanto, é ótimo ter uma ferramenta que transformará os comentários do código em uma especificação detalhada do projeto - uma maneira muito melhor de mantê-lo atualizado do que fazê-lo manualmente.

Acredito que a avaliação imprecisa de como o design deve ser detalhado para o projeto é um fator importante no aumento de custos. A pior parte é que você está condenado se fizer isso e condenado se não fizer:

  • Se o seu design é muito detalhado para o tamanho da equipe, a complexidade do trabalho e os requisitos dos portões que você deve cumprir (análises de segurança, análises de segurança etc.), você desperdiçou tempo e dinheiro preciosos em um artefato que você nunca usará.
  • Se seu projeto não for detalhado o suficiente, você desperdiçará dinheiro, pois os membros da equipe fazem suposições incorretas que levam a problemas de integração e corre o risco de retrabalhar muito quando uma auditoria final de segurança ou segurança descobre problemas que poderiam ter sido corrigidos mais cedo e mais barato se tivessem sido executados. aspectos claros do design antes da implementação.

Não acho que seja um gabinete preto e branco - pode haver muitas vezes em que alguns componentes são "bons o suficiente" se projetados em um nível alto, enquanto outros precisam de um trabalho detalhado e rigoroso. E a mudança de ambientes de equipe ou projeto pode ditar novas necessidades de design à medida que o projeto evolui.

bethlakshmi
fonte
2

Trabalhando em um grande projeto agora. Até agora, as especificações ajudaram o controle de qualidade a identificar o que testar, nos permitiram cobrar mais do cliente (significativamente em milhões) quando, no teste do usuário, eles decidiram que o que haviam concordado não era o que realmente queriam, permitia às pessoas fazer uma revisão de código para verificar se o código atendia ao requisito, permitiu que os desenvolvedores tivessem uma base para verificar se eles haviam terminado e apontar para a especificação para resolver disputas sobre o que o módulo deveria conter. Também nos permitiu identificar desenvolvedores que não estavam produzindo o que o cliente exigia antes que ele visse o produto e isso acabou como uma base para livrar-se de algumas pessoas que, de maneira sistemática, não podiam seguir as especificações. A complexidade de nossas especificações ajudou o cliente a perceber que não estávamos sendo ultrajantes em nossas estimativas de custo e tempo.

Eu queria acrescentar, trabalhei em projetos com boas especificações, com especificações ruins e sem especificações. Os que acabaram sendo os piores foram os sem especificação, porque a equipe de desenvolvimento e o cliente sempre tiveram uma visão interna diferente do resultado final. Estes são os projetos nos quais você sai por aí murmurando: "Onde posso obter um módulo de leitura da mente?" Adivinhar o que o cliente pode querer é uma experiência horrível. Especificações ruins não são muito melhores, mas pelo menos você pode refinar enquanto diz: "Não sei ao certo o que você quis dizer aqui". para obter mais informações antes de perder seu tempo criando a coisa errada. O grande projeto em que estou agora tem especificações surpreendentemente boas, tornou a vida mais fácil e muito menos estressante.

HLGEM
fonte
+1 - Às vezes você precisa entender que esse é um negócio que envolve pessoas técnicas e não técnicas, que vêem o cenário de várias maneiras.
23411 JeffO
2

Pessoalmente, acho que as especificações detalhadas superestimaram.

Na minha experiência, o que os clientes precisam e o que pensam que precisam são geralmente duas coisas diferentes. Se você congelar os requisitos desde o início, estará criando o que eles pensam que precisam, e não o que eles realmente precisam. Legalmente, você está do lado seguro e será pago, mas não terá um cliente feliz.

Por outro lado, se você aceitar que o desenvolvimento de software é, em certa medida, uma atividade exploratória, tentará manter os requisitos abertos pelo maior tempo possível. Discuta com os usuários o que você precisa saber para a iteração atual , nem mais nem menos. E saiba que, às vezes, você precisará revisar essas decisões em uma iteração posterior. Mais importante: lembre-se de que, se isso acontecer, não é culpa do cliente. A menos que seus usuários também sejam desenvolvedores de software, a coleta de requisitos não faz parte da descrição de seu trabalho. Faz parte da descrição do seu trabalho.

Então, como você evita a fluência de recursos? Idealmente, com um gerente de produtos sã responsável por aceitar ou rejeitar solicitações de recursos e que não pode ser substituído por mais ninguém.

nikie
fonte
1

O Agile tem mais de 10 anos, portanto, esse não é um fenômeno novo.

Espero que as especificações sejam muito menores do que o código, por isso não sei quantos detalhes você precisa. Deve haver o suficiente para manter os membros da equipe informados. Ler todos os códigos um do outro é prático / necessário?

Concordou, não há necessidade de documentos mortos. Prefiro abordar uma base de código desconhecida sem documentação do que documentação incorreta.

E se o computador é tão bom em executar seu código, por que você não deixa fazer as próprias alterações? Seguir a receita na parte de trás da caixa não faz de você um chef.

JeffO
fonte