Este é o nosso quarto FAQ (Perguntas e Respostas) sobre Engenharia de Software.
Mensalmente os membros da nossa lista VIP poderão enviar Perguntas que eu mesmo responderei, sobre quaisquer assuntos no campo da Engenharia de Software.
A seguir, as perguntas dos leitores, com as respectivas respostas.
Leitor: Débora Ribeiro
A minha questão é super complexa para mim!!!!
Vamos lá…
Imagine um usuário que na reunião de levantamento descreve sua questão assim: Eu preciso preencher um formulário na hora do plantão e não posso demorar com isso. Rapidamente a analista de requisitos escreve no seu caderninho “preenchimento automático”. Após mais conversas com o usuário, surge o comportamento de tela onde o campo Data é preenchido automaticamente com a data corrente e fim da reunião. Como posso documentar essa informação?
É um Requisito Não Funcional de Usabilidade, considerando que facilita o preenchimento para o usuário?
É uma regra de tela? Se for… Essa regra vai ser associada ao protótipo?
Se usarmos casos de uso… Essa regra fica no passo ou é regra de campo?
Se usarmos histórias de usuários… Essa regra é um critério de aceitação?
E para fechar com chave de ouro… Existe regra de tela ou isso foi uma invenção pois não se sabe o que fazer com a informação?
/* Abaixo meus comentários. */
Olá Débora!
Sutilezas interessantes, não? Mas observe que, antes de classificar o tipo do requisito, não fica dúvidas que é uma necessidade de negócio.
O usuário precisa agilizar seu trabalho, está claro este desejo. Isso é um Requisito Não Funcional de Usabilidade? Entendo que sim. É um Requisito Funcional (uma função) da funcionalidade “Formulário XYZ”.
Entendo que sim.
E como classificar então?
Se isso for uma necessidade aplicável apenas à funcionalidade “Formulário XYZ”, eu definiria como um RF (Requisito Funcional) que seria realizado pela respectiva. Se for uma necessidade aplicável a outras funcionalidades, eu definiria como um RNF (Requisito Não Funcional), e associaria às funcionalidades que o realizariam.
Sobre “Existe regra de tela ou isso foi uma invenção pois não se sabe o que fazer com a informação?”. Na prática existem premissas e restrições que ficam apenas no domínio da “tela”, da interface gráfica. E esta informação não pode ficar no limbo. Se ficar, vai gerar bug.
Você escreveu ainda:
“É uma regra de tela? Se for… Essa regra vai ser associada ao protótipo?
Se usarmos casos de uso… Essa regra fica no passo ou é regra de campo?
Se usarmos histórias de usuários… Essa regra é um critério de aceitação? “
Abaixo minhas respostas:
“É uma regra de tela? Se for… Essa regra vai ser associada ao protótipo?” – Se não for de negócio, é de tela. Se for de tela, escreva em algum lugar, que seja no protótipo (se tiver artefato para isso), no .docx de especificação etc. Mas escreva!
“Se usarmos casos de uso… Essa regra fica no passo ou é regra de campo?” – Não conheço os conceitos de “regra de passo ou de campo”. Se for algo que altera o comportamento da funcionalidade de maneira significativa, vale apena tratar isso como um passo num fluxo, e descrever o fluxo conforme o efeito colateral de tal evento. No exemplo que citou, penso que não se aplica.
“Se usarmos histórias de usuários… Essa regra é um critério de aceitação?” – Tratando-se de estórias de usuário, sendo um item de negócio (no seu caso é) entendo que pode sim ser tratado como critério de aceitação, afinal, se foi solicitado e documentado, se não for feito o PO (Product Owner) ou equivalente não pode dar “ok” na entrega.
Lembrando apenas que, mesmo que não seja um item de negócio pode ser considerado critério de aceitação, desde que esteja claro na lista de critérios de aceitação amarrada à estória pertinente.
Qualquer dúvida adicional sinta-se à vontade! Deixe nos comentários que responderemos! 🙂
Leitor: Ilmar Gabriel
1 – As especificações de caso de uso na minha empresa não são versionadas, com isso não temos o controle da versão relacionada ao sistema. Utilizamos o GIT para versionamento do nosso código fonte em java. Quais seriam os procedimentos para realizar o versionamento para as especificações de caso de uso? Ou seja, é interessante criar uma pasta a parte no repositório para a documentação? Qual as principais vantagens de se versionar as especificações? O acesso para visualizar pode ser pelo próprio GIT ou interessante criar uma interface a parte?
/* Abaixo meus comentários. */
Oi Ilmar, vamos lá!
É imperativo que controlar versão de artefato de projeto (seja artefato de modelagem ou construção) é pré-requisito básico para ter algum controle. Sem isso, problemas sérios vão ocorrer.
O que você deve verificar é se o GIT é uma ferramenta adequada para isso (na sua visão), ou se alguma outra lhe atende melhor.
Importante lembrar no fim tudo são “arquivos”. Um .java e um .docx são apenas “arquivos”, para um sistema de controle de versão.
E se o GIT lhe atender, eu preferiria utilizá-lo, pois centraliza todo o seu repositório, tanto de artefatos de construção quanto de modelagem, num único local/ferramenta. Isso faz muita diferença na produtividade da equipe.
2 – Na minha empresa trabalhamos com um ferramenta própria no controle das tarefas (erros, aprimoramentos). Atualmente, colocamos o que deve ser corrigido ou aprimorado nessas tarefas e em consequência disso o desenvolvedor não olhas as especificações de caso de uso. Se deixarmos de colocar as mudanças na tarefa e enviar somente a especificação de caso de uso para o desenvolvedor, como destacar o que deve ser alterado?
Você pode/deve ter algum checklist para atendimento de chamados. A “grosso modo”, é uma lista de coisas que tem que ser atendidas para que o chamado pode ser dado como “atendido”. Uma delas seria: “Alterações refletidas nos Casos de Uso assocaidos à Funcionalidade”.
Mas é importante lembrar que no seu contexto o problema maior talvez seja de disciplina/cultura do time. Talvez uma solução técnica, mesmo que em nível de processo, não resolva muito. Isso é um dos maiores desafios quando o assunto é melhoria de processos.
3 – Em processo de desenvolvimento ágil é vantajoso trabalhar com as especificações de caso de uso? Se sim quais as vantagens?
Isso vai depender do objetivo da equipe. Muita gente se questiona sobre usar Casos de Uso ou Estórias de Usuário.
A resposta sempre é “depende”. Em empresas em que a cultura é agil mesmo, onde o escopo é produzido “em equipe”, com participação ativa dos usuários, POs, desenvolvedores etc. e “errar é mais humano”, estórias tendem a ser melhor, pois são mais enxutas e mais objetivas.
Já em empresas sem cultura ágil, mas que usam Scrum por exemplo, Caso de Uso pode ser melhor, pois documenta “mais e com maior rigor”, diminuindo a incidência de conflitos sobre lapsos de escopo e erros funcionais.
4 – As especificações de caso de uso onde trabalho não são lidas pelo desenvolvedor, pois são mal escritas tornando cansativa a leitura e entendimento. A partir disso estou criando um modelo que será descrito como deve ser. Coloquei as seguintes partes: Descrição, pré-condição, dependências, pós-condição, fluxo básico, fluxo alternativo, tipo de dados (tabelas com os campos), principais regras de negocio e anexos Qual o modelo ideal para especificação ou cada um cria seu modelo de acordo com sua realidade?
Eu acho que não deve fazer isso. Customizar um padrão é algo muito arriscado, e salvo em casos muito específicos, pelo que já na vi na prática, não costuma funcionar. Lembrando ainda que regras de negócio são artefatos separados dos Casos de Uso.
Penso que o modelo ideal sempre será o que atende melhor às necessidades de cada organização, entretanto, quando o assunto é casos de uso, o modelo “padrão de mercado”, na minha visão, aplica-se em 80% das empresas que usam Casos de Uso na produção de software.
Dê uma olhada aqui em nosso curso Casos de Uso na real, imagino que pode lhe ser muito útil.
5 – Precisamos colocar todas as especificações no novo modelo e os analistas de requisitos não tem tempo hábil, pois realizam diversas atividades empresa. Qual seria uma solução resolver esse problema? Realizar a mudança por demanda? Isto é, a cada customização fazer a mudança e versionar.
Aplico o mesmo raciocínio da questão 2.
6 – Os diagramas de atividades, sequencia e maquina de estados deve ficar qual documento? Pode ser um documento para cada um deles tendo o titulo que processo pertence?
A resposta também é “depende”. Se você usa os três diagramas citados em seu processo de desenvolvimento, lhe sugiro que reavalie se realmente é necessário ter todos os três. A depender da finalidade de cada um, pode ter um problema de redundância, que vai gerar fatalmente ineficiência.
O ideal é não ter documentos separados, e sim fazer os diagramas em alguma ferramenta case que centralize isso. Se usar documentos word por exemplo (faz o diagrama na ferramenta e gera documentos word), no pior caso, coloque-os em algum repositório (como GIT por exemplo), para evitar que fique maluco com versões.
Mas ter os três tipos para todos os seus projetos, colocando-os em documentos separados, controlando versão “na mão”, é fria na certa.
Leitor: Gabriela Souza
Aqui na empresa estamos pensando em rodar sprints com timebox de seis semanas. Rodamos hoje sprints de quatro semanas apenas. Pergunto se isso é possível pois o scrum define sprints entre duas e quatro semanas. Qual o problema em ter sprints maiores que quatro semanas? Obrigada!
/* Abaixo meus comentários. */
Oi Gabriela!
O timebox de um Sprint sempre tem que ter fundamento pertinente. O Scrum prega de duas a quatro semanas, pois entende-se, “via de regra”, que em menos de duas semanas não é possível produzir um MVP, e acima de quatro semanas, o prazo fica longo demais para se entregar valor em curto prazo.
Porém, aplica-se aqui o bom senso.
Ás vezes na sua empresa quatro semanas não é um prazo confortável para a equipe produzir um MVP de qualidade. Pode ser assim pelo processo ser mais moroso, porque a empresa é muito grande e com cultura mais tradicional, por equipes estarem descentralizadas mas a TI rodando Scrum, dentre outras coisas.
Ou seja, se quatro semanas é um tempo muito curto para se produzir um MVP na sua empresa (supondo que essa seja a justificativa, visto que não ficou claro na sua pergunta qual é), então seis semanas pode ser viável sem problemas, na minha visão.
Leitor: Rafael Bruno
Dos padrões de projeto criacionais Factory, Simple Factory e Abstract Factory, qual dos três é o melhor para uma arquitetura de um ERP?
/* Abaixo meus comentários. */
Olá Rafael!
A pergunta é muito ampla, portanto, não tenho uma resposta pronta! ;(
Um ERP é um mundo à parte, e conforme o segmento de negócio ao qual o sistema se aplica, a complexidade pode variar muito.
Então, não consigo lhe sugerir qual padrão seguir para um ERP, por desconhecer o “tipo de ERP” ao qual se referiu.
Mesmo assim, segue abaixo algumas recomendações/comentários sobre os três design patterns citados.
Lembrando que todos os três possuem uma finalidade “maior” que é a mesma: de maneira eficiente criar objetos em tempo de execução do software favorecendo o desacoplamento da solução.
Simple Factory
É a versão mais simples do padrão. Eu acho que ela se aplica em 80% dos casos.
Além de ser simples de entender, é simples de manter, e atende o principal objetivo, que é delegar a outrem a criação do objeto desejado, favorecendo o desacoplamento.
Factory (ou Factory Method)
É uma solução relativamente simples também, porém, já envolve um polimorfismo na sua estrutura, pois demanda uma classe mãe, que as classe filhas devem herdar, para que possam ser “criadas pela mãe”.
Se precisar de algo um pouco mais moderno (se por exemplo, tiver muitos domínios dentro da arquitetura do seu sistema, tiver um barramento de serviços ou qualquer “caixa” que agrupe por alguma classificação muitas classes que precisam ser frequentemente instanciadas) pode ser uma boa opção para organizar melhor os pontos onde as instâncias dos objetos são feitas (ganhando coesão), e também, ganhar com o desacoplamento gerado por este padrão.
Abstract Factory
É a versão mais complexa do padrão, diria eu que aplicável em talvez uns 5% dos cenários que demandam fábricas de objetos, e que demanda muito cuidado no seu projeto e construção, pois em sistemas grandes (como um ERP) isso pode virar bad smell facilmente, e nem go horse salva depois na manutenção.
Esta versão do Factory é para criar objetos mais complexos, como famílias de objetos – alguns profissionais usam para criar “fábricas de fábricas de objetos”, algo altamente periculoso. =(
Também demanda ainda maior complexidade em termos de polimorfismo e orientação a objetos, pois é necessário usar interfaces e/ou classes abstratas (não há rigor sobre qual dos dois tipos de interface usar [se “interface” da OOP ou “Abstract Class”], muitos acham obrigatório o uso de Interface, mas o mais relevante é manter um “contrato” entre as classes envolvidas e entre elas, desacoplamento que permita dar manutenção dentro da fábrica abstrata.
Para entender mais sobre diagrama de classes, veja este post.
Bom, minha sugestão é: pense muito bem antes de definir o que usar pois depois que implementar é quase inviável refatorar, dependendo da complexidade da arquitetura, mesmo que a finalidade seja desacoplar a estrutura do sistema. Mas considere que, na maioria das vezes, o Simple Factory resolverá o problema. E ainda, não ignore a possibilidade do bom e velho new()!
Finalizando
Agradecimentos sinceros aos leitores que enviaram suas perguntas! 🙂
Lembrando que não é possível esgotar muitas das questões aqui, pela amplitude destas. E que, ainda, trata-se da minha opinião, que pode ser revista à medida que vou me tornando menos ignorante.
Em breve o próximo FAQ, e faça parte da nossa lista VIP para enviar suas perguntas que estamos à disposição!
Grande abraço!