do Desenvolvedor
8 de Maio, 2020
App Dev Gerenciador de Darroll Walsh compartilha uma introdução ao CMMI para desenvolvimento de desenvolvedores.
o Capability Maturity Model Integrated (CMMI) é um programa de melhoria e avaliação de processos que se integra a outros programas de melhoria de processos, como o Project Management Body of Knowledge (PMBOK) e o Agile. Ele trabalha para agilizar e padronizar todos os processos e fornecer um meio de ter métricas de supervisão e acionáveis para Desenvolvimento, Serviços, gerenciamento de fornecedores, maturidade cibernética e outros.
o que eu quero fazer é fornecer uma visão geral do CMMI Dev da perspectiva de um desenvolvedor. Vamos pular as partes de gerenciamento de Projetos, Analista de negócios, gerenciamento de configuração e teste do CMMI DEV para nos concentrarmos no impacto do CMMI em uma equipe de desenvolvimento. Se houver interesse nas outras funções ou recursos que podem ser um bom tópico para uma entrada posterior do blog. Basta notar que há muito trabalho que acontece antes dos desenvolvedores começarem, mesmo no desenvolvimento ágil.
vamos começar:
o BRS, ou especificação de requisitos de negócios é onde tudo começa, esta é a única fonte de verdade. É aqui que os requisitos de negócios que o proprietário do produto assina. Embora os desenvolvedores possam ser consultados sobre a criação do BRS, isso é principalmente de responsabilidade da BA. No entanto, é aqui que um desenvolvedor pode realmente conhecer o aplicativo que está desenvolvendo; um lugar para obter o quadro geral.
designs de alto e baixo nível são a documentação de arquitetura que mostra como os componentes do aplicativo estão conectados. No design de alto nível, estabeleceríamos dependências externas e como os usuários e/ou sistemas irão interagir com nosso sistema. O design de baixo nível estabeleceria como os componentes internos interagem uns com os outros. Revisá-los daria a outro desenvolvedor uma compreensão muito rápida do funcionamento do aplicativo.
o SRS, ou especificação de requisitos de Software, é onde o desenvolvedor documenta como o aplicativo será construído. É aqui que os Serviços são documentados, as dependências são estabelecidas e, geralmente, como o código deve funcionar, com base no BRS criado. Isso normalmente é feito antes que o código seja escrito e seja uma tarefa padrão. Eu sei que alguns estão perguntando por que precisaríamos fazer isso. Meu código é auto-documentado. E embora eu tenha certeza de que é, o código é espalhado por centenas de arquivos e milhares de linhas de código. E às vezes a intenção não é tão clara quanto gostaríamos. O SRS nos dá um documento para olhar com um esboço claro do que podemos esperar. Ele descreve casos de uso e comportamento esperado em uma mansão consistente.
depois de definirmos o que vamos fazer e, em seguida, escrevermos o código, é hora de alguém revisar o que fizemos. Digite a revisão do Código. Esta não é apenas uma boa prática para detectar erros e garantir que estamos seguindo as melhores práticas e diretrizes, é uma ótima maneira de compartilhar o que o aplicativo está fazendo. O mero ato de revisar o código por um segundo conjunto de olhos nos dá uma segunda pessoa que está familiarizada com o funcionamento do Código. Como isso se tornou prática padrão na maioria das equipes de desenvolvimento, não vou acreditar nisso.
o teste unitário é outra estadia principal da maioria dos programas de desenvolvimento. Teste de unidade seja feito como parte do Desenvolvimento Orientado a testes ou feito após o Código ser escrito, são uma das melhores maneiras de garantir que futuras alterações não introduzam erros em nosso código. Em um pipeline de CI / CD, podemos garantir que todos os testes passem antes de permitir que o código seja verificado. Isso nos ajuda a manter o código em boas condições de funcionamento.
individualmente, há valor em cada conjunto de documentos acima, no entanto, os ganhos reais começam quando você pode amarrar todas essas informações juntas. No início do processo de coleta de requisitos, iniciamos uma matriz de rastreabilidade de requisitos que nos permite vincular requisitos de negócios, requisitos de software, código, testes de unidade, planos e casos de teste e aceitação do Usuário juntos. Imagine seis meses em um grande projeto e uma mudança faz com que um caso de teste falhe. Agora podemos voltar aos requisitos, descobrir qual é o propósito desse código, saber exatamente onde está o código para essa lógica, modificar o teste de unidade para capturar o novo caso e implementar uma correção dentro de horas, não Dias.
no curto prazo, o CMMI pode parecer um exagero, mas mesmo em pequenos projetos, o conhecimento capturado seguindo o processo encurta o ciclo quanto mais tempo você estiver longe do projeto. Sem mencionar se você nunca trabalhou no projeto antes.
Suporte Ao Desenvolvedor
App Dev Sucesso Do Cliente Um Gerente De Conta De Suporte Da Microsoft Developer
Siga