Então, o que fazer?

A solução estaria então em adotar um Processo de Software bem definido. Muitos são os tipos de processos e muitas são as necessidades de equipes e das empresas em ter e utilizar um bom Processo de Software a fim de adquirir organização e qualidade em seus produtos, respeitando prazos de cronograma, administrando esforços de equipe, obtendo mais produtividade e padronização de desenvolvimento.

Porém, não acredito que exista um único processo perfeito para o desenvolvimento de software, ou seja, para adquirir um bom processo, deve ser levado em consideração fatores como:

• Tipo de software que está desenvolvendo;
• Tamanho de equipe (desenvolvedor único, dois desenvolvedores, equipe pequena, equipe com mais de 100 membros);
• Infraestrutura;
• Capital investido;
• Entre outros.

Entre diversos tipos de Processos de Softwares, destacam-se os modelos em Cascata (CMMI), Espiral, Iterativos (PU – Processo Unificado) e os modelos Ágeis (XP, Scrum).

Mas por que utilizar um Processo de Software?

Dentre alguns fatores, podemos definir que o Processo de Software visa à qualidade do produto como um todo, onde é estabelecida a lógica do domínio da aplicação para o projeto decidindo seu scopo e comprometimento do Patrocinador, levantamento dos requisitos, riscos de projeto, padronização de desenvolvimento, construção do modelo e prototipagem, implementação sistemática de testes, feedback do cliente, revisões técnicas, gerência de configuração, etc. Porém, todo este conjunto (o Processo) não basta apenas ser implementado, ou seja, deve-se ter o gerenciamento do processo como um todo a fim de garantir que ele esteja sendo executado corretamente por seus envolvidos.

Em outras palavras, o Processo de Software não é uma tarefa simples de implementar numa organização. Ele “afeta” diretamente seus envolvidos, no qual em alguns casos, são obrigados a saírem de suas zonas de conforto. O processo também confronta a cultura de uma empresa, e todo este conjunto gera uma certa resistência dos envolvidos em colaborar para o sucesso do mesmo.

Meu artigo não é de forma alguma induzir o leitor a optar para um processo X ou Y, mas sim avaliar o nível caótico de não se utilizar um processo e os benefícios conquistados com sua aplicação.

Particularmente, um dos modelos que mais me apego são os modelos Ágeis, devido a suas práticas, valores e por serem iterativos.

Os modelos iterativo e evolutivo envolvem a imediata programação e teste de um sistema e considera que o desenvolvimento começa antes que os requisitos tenham sido definidos em detalhes. Evitando assim grandes desgastes e desmotivação na fase inicial.

Nesta abordagem de ciclo de vida, o desenvolvimento é organizado em uma série de mini projetos curtos, de duração fixa chamadas de iterações. O produto de cada um é um sistema parcial, executável, testável e integrável. Cada iteração inclui suas próprias atividades de análise de requisitos, projeto, implementação e teste. No modelo Ágil, os detalhes de requisitos são acrescentados no decorrer do processo, utilizando assim, a modelagem na perspectiva de principalmente entender o que foi pedido e não documentar.

Ao contrário, nos modelos em cascatas (ou sequencial), há uma tentativa de definir em detalhes todos ou a maioria dos requisitos antes da programação e também de criar um projeto abrangente, antes da programação. Igualmente, há uma tentativa de definir um plano ou cronograma confiável logo no início. Outro ponto a ser avaliado, é que neste modelo, modificações tardias de requisitos não são bem vindas. Deve levar-se em conta que custos de operações aqui são bem mais altos e é um modelo muito burocrático.

Apesar do meu apego ao modelo Ágil, o ideal é que as equipes criem seu próprio Processo de Software, olhando na perspectiva de não diminuir o valor de outros métodos e sim, agregando as boas práticas mais comuns que atendam as suas necessidades dentro da sua realidade, não se esquecendo de manter um contínuo amadurecimento do processo como um todo.

Fonte: Blog Rafael Amaral
Twitter: @rafaelamaralll

Um assunto sempre polêmico, mesmo ainda iniciante nesta área, tenho visto algumas definições diversificadas de profissionais (especialistas ou não) sobre o tema.

Alguns definem Casos de Uso apenas em sua notação gráfica (os diagramas), porém, Casos de Uso vão muito além. Casos de Uso são elementos primários no desenvolvimento e planejamento do projeto. Ele facilita o entendimento e a comunicação com o stakeholder, pois Casos de Uso representam uma visão externa do sistema e aplicando uma boa técnica na sua utilização, eles são com certeza uma melhor maneira de levantar bons requisitos de sistema. Em outras palavras, Casos de Uso descrevem o comportamento do sistema sob diversas condições conforme o sistema responde a uma requisição de um ator primário, no qual este (ator primário) inicia uma interação com o sistema para atingir algum objetivo.

Um formato simples para captura de um Caso de Uso consiste na descrição de seu cenário primário como uma sequência de passos numerados e as alternativas como variações naquela sequência.

Existe muita variação no modo como você pode descrever os conteúdos de um Caso de Uso, porém, a UML não especifica padrão algum. Mas, acrescente informações sempre que julgar necessárias, principalmente, vendo isto pela perspectiva do risco, ou seja, acrescente detalhes de acordo com o grau de risco, quanto maior o risco, mais detalhes você precisa. Mas, não se desespere em detalhes, ou seja, entre neles aos poucos durante sua elaboração e durante as iterações, vá acrescentando mais detalhes à medida do necessário. Porém, chamo sua atenção para a simplicidade, pois um Caso de Uso bem escrito é fácil de ler, porém, aprender a escrever um bom caso de uso é difícil.

Mas, o que é realmente, um Caso de Uso?

Um Caso de Uso captura um contrato entre os stakeholders de um sistema sobre o seu comportamento. Um Caso de Uso descreve o comportamento do sistema sob diversas condições conforme o sistema responde a uma requisição de um ator primário.

Alistair Cockburn

Uma outra definição mais compreensiva, explico primeiro o que é um cenário.
Cenário: é uma sequência de passos que descreve uma interação entre um usuário e um sistema.

Caso de Uso, então, é um conjunto de cenários amarrados por um objetivo comum de um usuário.

Martin Folwer

Finalizando, Casos de Uso têm uma grande importância na construção de projeto e é um assunto para mais de “Gigas”. Sobre diversos aspectos, eles são essenciais em uma infinidade de coisas desde o início ao fim das iterações do projeto. Para iniciantes na área, dedicar-se na leitura de bons livros sobre o assunto irá fazer toda a diferença na hora de analisar e/ou dirigir um projeto.

Fonte: Blog Rafael Amaral
Twitter: @rafaelamaralll

Mesmo que de certa forma tenhamos que trabalhar esses conflitos, é importante ter outra equipe que teste o que foi desenvolvido. Como já disseram por aí, “não existe filho feio para a mãe”, e o programador tem um tendência natural a achar que tudo que desenvolveu está perfeito.

Contudo trabalhar com somente com uma equipe pode não resolver todos os problemas. Ainda que essa seja boa o suficiente para cumprir o seu papel, o usuário é o verdadeiro tester, já que é quem usará o programa no dia-a-dia. Com a ideia do usuário como tester surgem dois conceitos, chamados de Teste Alfa e Teste Beta.

O Teste Alfa  é aquele realizado no ambiente do desenvolvedor, mas pelo usuário final do programa. Já o Teste Beta é realizado no ambiente do cliente, sem a presença do desenvolvedor, aonde o próprio cliente relata quais são erros observados que serão posteriormente corrigidos.

Os testes de software podem ainda ser classificados quanto a  técnica utilizada. Dentre eles os principais são:

• Teste Caixa Branca: São os testes estruturais, baseando-se na estrutura e procedimentos utilizados no programa, analisando os laços, condições de if/else. Através do código (ou algoritmo) são analisados casos a busca de erros.
  
• Teste Caixa Preta: O teste caixa preta baseia na especificação de interface do programa, observando-se entradas e saídas, ou seja, se a saída produzida realmente condiz com a saída esperada, em relação ao que foi inserido como dado de entrada.

Existe ainda a Técnica Baseada em Erros, que se baseiam na inclusão de erros propositais (artificiais) como forma de revelar erros existentes previamente (naturais).

Por fim, lembre-se: bons testes de software são aqueles que apresentam maior probabilidade de revelar erros ainda não descobertos!

Acredito que todo bom programador já deve ter tido sua fase de modo “REC”, no qual já inicia o desenvolvimento do código enquanto o cliente “expõe” suas ideias.

No final, os resultados são sempre os mesmos. Frustrações! Produto gerado sem conformidades com o que realmente o cliente precisa, gastos excessivos com manutenções e correções, etc. Contudo, isso não quer dizer que o programador é ruim. Apenas faltou o emprego de um Processo de Software.

Mas o que é afinal, um Processo de Software?

Um Processo Software é um conjunto de atividades, parcialmente ordenadas com a finalidade de obter um produto de software e é considerado um dos principais mecanismos para se obter um software de qualidade. (Wikipédia)

Então, tudo que precisamos para gerar um produto de software de qualidade é um bom Processo de Software que se adapte a realidade de uma empresa. Porém, não basta “apenas” implementá-lo, ou seja, deve-se ter o gerenciamento do processo como um todo a fim de garantir que ele seja executado corretamente entre os envolvidos, ou caso contrário, o caos tomará conta de tudo trazendo o resultado inverso do que se esperava.

Ao implementar o processo, você poderá encontrar algumas pedras pelo caminho. Implementar um processo confronta diretamente a cultura da empresa, resistência e falta de cooperação dos envolvidos, falta de estrutura, de pessoal qualificado, etc. Porém, é como a maioria das coisas, que no início, é muito complicado e trabalhoso.

Como vimos na definição, o Processo de Software visa à qualidade do produto de software. Mas como podemos definir esta qualidade?

Este conceito pode ser considerado como um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos especificados, prevenindo e eliminando defeitos.

Em outras palavras, a qualidade de software é estar em conformidade com requisitos funcionais e de desempenho explicitamente declarados de desenvolvimento, que devem ser claramente documentados e as características implícitas que são esperadas de todo o software desenvolvido.

Para que isso seja possível, as fases do processo devem ser bem elaboradas e trabalhadas, efetuando devidas revisões para uma contínua melhoria e amadurecimento do processo e de seus artefatos. Um exemplo de modelo, podemos citar como fases: Concepção, Elaboração, Construção e Transição, no qual é feito um estudo de viabilidade, coletas de casos de uso, análise de requisitos, modelagem, desenvolvimento, revisões, etc.

Outra característica importante de um Processo de Software é que ele visa à diminuição de falhas, ou seja, elaborar de forma sistemática Casos de Teste a fim de identificar e corrigir erros já na fase inicial do projeto. Corrigir erros no início do projeto é bem mais barato do que depois de entregue. Em outras palavras, entregar um produto de software sem falhas garante a confiabilidade, eficiência e integridade do produto.

Mas, por que utilizar um Processo de Software?

Dentre os fatos acima e muitos outros, posso citar também que:

• Mais de 30% dos projetos são cancelados antes de serem finalizados.
• Mais de 70% dos projetos falham nas entregas das funcionalidades.
• Os custos extrapolam em mais de 180% do orçamento inicial.
• Os prazos excedem em mais de 200% os cronogramas originais.

Existem alguns modelos de Processos de Software, como os modelos em Cascata (CMMI), Espiral, Ciclo de Vida, Ágeis (SCRUM, XP), etc.

Para escolher o modelo ideal, é preciso conhecer um pouco sobre cada um deles e ver qual se adapta melhor à realidade da empresa, levando em consideração fatores como: investimento, tamanho de equipe, pessoal qualificado, entre outros.

Sem dúvidas, podemos definir que o Processo de Software amadurece a equipe e a visão sobre o desenvolvimento como um todo, garantindo um produto de software com qualidade e de consequência, a satisfação do cliente.

Fonte: Blog Rafael Amaral
Twitter: @rafaelamaralll

• Visão do Produtor: a qualidade do produto está totalmente relacionada com os requisitos estabelecidos.
• Visão do Cliente: a qualidade está relacionada a “adequação ao uso” ou as necessidades do usuário.

Os times destinados a trabalhar neste meio devem encurtar o gap existente nestas duas visões. Para tal objetivo trabalha-se na Garantia da Qualidade e o Controle da Qualidade.

A Garantia da Qualidade são todas as atividades com o intuito de prover uma confiança adequada para os produtos e serviços de acordo com os requisitos especificados. O time da Garantia da Qualidade deve definir políticas e seguir modelos para desenvolver de forma contínua melhorias no processo de desenvolvimento. Metodologias de desenvolvimento, estimativa do processo, processos de manutenção, processos de definição de requisitos, processos de teste, padrões de desenvolvimento, treinamentos, documentação são exemplos de ações que um time de garantia pode realizar. Lembre-se que a qualidade do produto está relacionada a qualidade do processo.

Todo o trabalho e/ou ações que são produzidos na Garantia da Qualidade devem ser controlados. Com este objetivo definimos atividades para o processo de Controle da Qualidade. O foco do Controle da Qualidade é identificar defeitos nos produtos ou artefatos produzidos. Teste de software é uma atividade do Controle da Qualidade. A atividade de teste pode ser incluída em todas as fases do desenvolvimento de software, através de inspeções, revisões e execução de casos de teste.

Todas estas atividades têm um custo associado, sendo que, para que possamos calcular o custo da qualidade devemos considerar três elementos: o custo da falha, o custo da prevenção e o custo da avaliação, sendo cada um deles apresentados abaixo:

• Custo da falha: custos associados com produtos defeituosos entregues ao cliente. Podemos associar a este custo os reparos, a utilização da equipe de help desk, bem como, os danos causados por um defeito.
• Custos da prevenção: são todos os custos associados com atividades que objetivam evitar defeitos. Podemos citar treinamentos, definição de métodos e procedimentos e aquisição de ferramentas. Observe que praticamente todas as atividades do time de Garantia da Qualidade estão associadas a este custo.
• Custo da avaliação: por fim, são todos os custos associados com a detecção de defeitos. Neste elemento podemos citar as atividades de teste de software, tempo gasto na automação de scripts de teste, revisões e inspeções.

Obviamente que o custo irá variar de uma organização para outra considerando a atividade que cada uma delas está disposta a fazer. A equipe de Garantia da Qualidade deve ser a responsável por identificar os custos destes três elementos, bem como, prover ações para minimizar o custo da falha.

Normalmente as organizações focam no custo de avaliação, porém, se o investimento for maior na prevenção ao longo do tempo o custo da falha e da avaliação tende a diminuir.

O que alguns profissionais não entendem é que nem sempre o cliente sabe o que quer ou nem sempre consegue expressar o que pensa. E em muitos casos, expressam totalmente o contrário do que realmente queriam passar. É fácil entender isso, levando em consideração pontos tais como: falta de conhecimento de tendências, falta de sensibilidade, falta de conhecimento técnico, entre outros fatores que podemos enumerar. E, consequentemente, há um gasto excessivo de investimento e mão de obra e frustrações dos dois lados são inevitáveis.

É provável que você já deve ter se deparado com vários casos parecidos. Na prática, é bem comum no início do projeto uma conversa informal com o cliente e depois de quase tudo pronto ele dizer que não era bem aquilo que se esperava. Outro caso, é a mudança contínua das iterações do projeto para atender ao nível “alto” de satisfação do cliente (que nunca está satisfeito).

A verdade sobre esses fatores são muitas. A começar pelo preço de custo/benefício, “tempo” e a pressão dos gestores em sua equipe para construírem softwares com tempo cada vez menor, e, contudo, a falta de planejamento sério e de chegar a um nível maduro de entendimento do que realmente o cliente espera do produto final.

Conseguir bons requisitos não é tarefa fácil, e, nem tão pouco, empresas estão interessadas em investir neste tipo de profissional. Investir neste processo, gasta-se um tempo de planejamento, mas algo necessário, ou seja, levando-se pelo ponto de vista maduro, é algo que se ganha lá na frente da iteração do projeto.

Estudos indicam que requisitos detectados depois do software implementado ou erros em sua análise são até 20 vezes mais caros de se corrigir que qualquer outro tipo de erro. A ilustração abaixo mostra a realidade na construção de softwares e podemos até dizer (desconsiderando alguns passos) que em determinados tipos de serviços mais informais, isso também acontece.

Essa é uma realidade não apenas no desenvolvimento de softwares, mas é algo corriqueiro e que acontece em nosso cotidiano. Para isso, basta precisarmos de um serviço específico de uma determinada área que desconhecemos, um tipo de conserto de um aparelho, etc. Nestas situações, recebemos muitas opiniões e “conselhos” do que realmente não  se deve fazer. Mas, em alguns casos, encontramos algum bom profissional que realmente está atento a nossa necessidade e provê uma solução ao problema.

“Um bom profissional sabe comunicar o seu jargão técnico com o jargão informal do seu cliente.”

Outro ponto que alguns profissionais (mesmo os melhores) não entendem, é o fato que o cliente não é obrigado a saber/entender de um determinado assunto ou uma necessidade. Isso eu chamo de visão, ou seja, alguns profissionais têm (e conquistam o cliente), outros não.  Saliento a importância em dar à atenção ao cliente e se dedicar em ouvir sua história de forma a entender o que ele quer e para que ele quer.

Especificamente falando de softwares, a análise é fundamental, pois em sua construção, um dos maiores desafios no desenvolvimento é o da construção do sistema certo, que preencha as necessidades dos usuários a um preço razoável. E para que isso aconteça, é preciso atingir boa comunicação e boa compreensão do mundo dos usuários (é onde entra a Análise de Sistemas). Este artigo é uma abordagem bem superficial de uma análise de softwares, onde há várias iterações, bem como sua documentação, no qual a documentação dos requisitos e de casos de uso é uma forma “contratual” entre a equipe de desenvolvimento e o cliente a respeito do software que será desenvolvido. Mas, o artigo aborda um ponto de vista que se deve ter na hora de construir software de qualidade.

Por outro lado, posso afirmar que o grande desafio do analista não se limita apenas em implementar melhores soluções tecnológicas, mas sim em mudar a cultura de uma empresa. Estudar, se dedicar e se especializar no que faz é parte da vida do profissional, mas, saber lidar com essas situações divergentes é o que faz o grande diferencial do profissional e o sucesso no que se faz.

Fonte: Blog Rafael Amaral

O Scrum foi desenvolvido pela primeira vez a mais ou menos 15 anos atrás, e vem evoluindo e sofrendo adaptações desde então. Suas regras, artefatos e eventos estão descritas no Guia Scrum.

O anúncio marca uma nova era na evolução Scrum, tornando disponível um mecanismo para que o público possa  fornecer feedback sobre o Guia Scrum, além de fornecer um modelo para propor extensões para a sua estrutura básica.

O processo formal para propor alterações que possam vir a integrar o Guia Scrum está disponível online no site scrum.org.

Para saber mais sobre Scrum, ou propor a sua própria contribuição, você pode usar os seguintes links:

Ler – http://www.scrum.org/scrumguides/
Alterar – http://www.scrum.org/scrum-guide-proposal/
Estendê-lo – http://www.scrum.org/scrum-extensions /

Esta é uma tradução livre do post original, disponível em http://agiletips.blogspot.com/2011/10/scrum-is-open-for-extension-and.html

Essa forma de trabalho, no entanto, obriga o projetista a estabelecer relações entre certas classes que possuem pouco ou nada em comum, resultando em modelagens por vezes confusas e complicadas de se dar manutenção. Para ilustrar essa questão, imagine que você está modelando um sistema com operações que serão tratadas como transações no banco de dados.

Neste sistema, haverá operações para movimentação de estoque (com saída de quantidade de um depósito e a respectiva entrada no depósito destino), para registrar contabilizações (envolvendo uma ou mais contas contábeis para débito e crédito) e para efetuar pagamentos a fornecedores. Distingue-se neste cenário a necessidade de modelagem de diversas classes de objetos: item de estoque, conta contábil, movimento de estoque, contabilização, fornecedor, entre outros. Há ainda claramente uma entidade que deve controlar as transações no banco de dados para garantir que as alterações comandadas numa operação sejam tratadas como um bloco único. Embora nada tenham em comum, tanto movimentos de estoque quanto pagamentos a fornecedores devem ser contabilizados. Um diagrama de classes que ilustre essas relações ficará confuso por misturar conceitos de movimentação de itens e de pagamentos. A situação tende a piorar se surgirem outras operações que precisem ser contabilizadas. E do ponto de vista da programação, modificações na classe de contabilização afetarão todas as outras classes, exigindo que estas também sejam revisadas.

Recursos que permeiam várias classes de um sistema, vinculando mesmo aquelas que implementam regras conceitualmente distantes, são chamados de cross-cutting. Outros exemplos de recursos assim: criação de logs de operações, auditoria em alteração de dados, níveis de permissão de acesso a dados, autorização para executar operações, tratamento de exceções, etc. Melhorar a solução para esse tipo de recurso é a proposta da Programação Orientada a Aspectos (POA), onde o código que implementa os recursos cross-cutting são retirados das classes de negócio e inseridos em módulos próprios – os Aspectos. O código das regras de negócio fica mais limpo e alterações no funcionamento dos recursos cross-cutting passam a ser centralizadas no Aspecto.

A POA depende ainda de um mecanismo que permita vincular a execução dos códigos do Aspecto à execução das regras de negócio. A solução proposta pela POA é centrado no modelo de pontos de ligação (Join Points). Tal modelo é definido por 3 características: o momento em que o código poderá ser executado – chamado de join point -, uma forma de especificar esses momentos e uma forma de especificar o código que deve ser executado em cada momento.

Um ponto de ligação pode ser encarado como um evento que ocorre no código da regra de negócio – marcado pela execução de um determinado método ou pela alteração no valor de uma propriedade, por exemplo. Criar pontos de ligação significa, portanto, indicar quais desses eventos devem ser monitorados pelo Aspecto, usando para isso estruturas chamadas de pointcuts. Os pointcuts se valem de uma sintaxe especial para possibilitar a indicação de quais métodos e propriedades dispararão a execução do código relativo a um ponto de ligação. Ao código que será executado pelo Aspecto quando um ponto de ligação é encontrado dá-se o nome de Advice.

Assim como as Classes, Aspectos também podem conter variáveis internas (membros) e ter heranças para especializar seu comportamento, adequando-o a uma função mais específica. Voltando ao exemplo das operações dado no início deste post, uma solução usando Aspectos seria criar um Aspecto base para tratar transações com o banco de dados. Isso implica a criação de um ponto de ligação para apontar o início da função que realiza a operação, momento em que o advice desse ponto de ligação deve tomar providências para garantir a existência de uma transação no banco de dados. Outro ponto, ao final da operação, deve encerrar a transação. Para cuidar das transações que precisem ser contabilizadas faríamos uma herança desse Aspecto e introduziríamos o código necessário num dos pontos de ligação já estabelecidos. Nesta herança, indicaríamos como pointcuts apenas as classes expressando regras passíveis de serem contabilizadas.

A experiência mais bem sucedida para popularização da POA por enquanto é uma extensão da linguagem Java criada pelo Centro de Pesquisas da Xerox que tem o nome de AspectJ. Trata-se de um projeto open source disponível na Fundação Eclipse. Há ainda algumas bibliotecas voltadas para C#, disponíveis na forma de frameworks. O Delphi Prism – IDE para programação na plataforma .NET usando a linguagem Delphi – incorporou uma implementação para uso de POA em sua versão 2010 usando para isso recursos do próprio .NET. Veja aqui um exemplo de uso com a sintaxe do Delphi.

Tudo o que foi apresentado aqui não poderia ser resolvido apenas com uso de classes? Sim, poderia. Poderíamos até mesmo implementar tudo em uma solução exclusivamente procedural, se desejássemos. O ponto aqui é que as ferramentas até então existentes podem ser melhoradas para resolverem de forma mais eficiente determinados problemas. Uma nova filosofia está sendo amadurecida no campo da análise de sistemas e da programação e, mais cedo ou mais tarde, as linguagens também terão que evoluir para acompanhá-la consistentemente.

Fonte: Balaio Tecnológico

Na fase de análise os envolvidos devem obter uma idéia clara do que o sistema deverá fazer, sem se preocupar com detalhes relacionados à maneira como ele irá implementar as funcionalidades levantadas nos requisitos do projeto.

Para buscar este entendimento, podemos utilizar interessantes propostas de mercado, baseado no levantamento e análise dos requisitos do projeto através de Casos de Uso da UML (Unified Modeling Language).

Após entrevistar os envolvidos no projeto da área de negócios do cliente, podemos analisar os Cenários de Caso de Uso identificados, elaborando e refinando diagramas de Caso de uso e de Atividades. Todas as informações levantadas devem ser registradas em algum documento formal baseado em propostas de mercado, veja propostas de Especificação de Caso de Uso e Relatório Sintético de Caso de Uso na referência bibliográfica deste artigo. Estes documentos devem ser validados pelos envolvidos no projeto e divulgados para toda a equipe do mesmo.

Veja abaixo, representação UML do Caso de Uso de um sistema no cenário responsável pela emissão de conta de restaurante.

Este digrama UML mostra claramente um usuário (Ator) e uma funcionalidade do sistema (Caso de Uso) que estaremos implementado em nosso sistema e deve ser elaborado na fase de análise de nosso projeto, vindo a incorporar a documentação técnica a ser aprovada e enviada para os desenvolvedores da aplicação.

A Especificação de Caso de Uso deve conter uma série de informações adicionais. Neste exemplo, poderíamos citar as informações e processamento abaixo para ser possível encerrar a conta:

• Em qual mesa se deseja encerrar a conta.
• Quais itens foram consumidos na mesa e qual o valor de cada um.
• Realizar processamento e emitir a conta.
• Registrar que o consumo da respectiva mesa está encerrado.

Como parte da análise, torna-se extremamente interessante termos o Diagrama de Atividades relacionado ao Caso de Uso. Este diagrama deve ser validado com os donos do requisito, para aprovação e corroboração de nosso entendimento do que deve ser efetivamente desenvolvido, mostrando inclusive regras de negócio envolvidas, quando possível.

Observe no diagrama abaixo como este diagrama torna muito claro o funcionamento, sequencia de eventos e regras de negócio envolvidos no mesmo.

Na fase de análise, podemos definir sem detalhamento as classes envolvidas no Caso de Uso, sendo que na fase de design teremos que detalhar as mesmas. Neste momento, algumas classes sugeridas na fase de análise podem deixar de ser consideradas enquanto muitas outras provavelmente irão aparecer, conforme evoluímos em nosso trabalho.

Veja abaixo, diagrama de classes inicial de nosso processo de modelagem.

Já na fase de design, temos que ter as classes muito bem definidas para termos um desenvolvimento correto, documentado, com facilidades de manutenção corretiva e evolutiva como a modelagem sugerida abaixo.

Na verdade, considero todo este processo muito empolgante e ainda existe muitos detalhes bem interessantes a se considerar na modelagem, tais como patterns, arquitetura, persistência de dados, …

Luck favors the prepared mind!

Veja exemplo completo juntamente com templates em Engenharia de Software na Prática: Editora Novatec, 2010. ISBN 978-85-7522-217-1

Quando iniciamos um projeto de software, vários aspectos precisam ser resolvidos: As tecnologias envolvidas, o processo que será utilizado, como o projeto será organizado, etc. Uma decisão errada em qualquer um desses aspectos pode causar danos irreversíveis no projeto e reduzir sua vida útil consideravelmente. Muitas vezes, decisões “simples” de design/arquitetura voltam para nos assombrar quando o sistema precisa ser adaptado para uma nova situação que não havia sido pensada originalmente (Já viram essa história?).

Quando organizamos um projeto de software, o termo “Separação de responsabilidades” deve ser nosso mantra. Não criar dependências desnecessárias e usar indiretamente as tecnologias envolvidas são atitudes simples que auxiliam na manutenção do projeto e na substituição dos componentes quando necessário. Indo um pouco mais fundo no aspecto responsabilidade, cada coisa em um projeto tem o seu lugar, e esse lugar deve fazer sentido. Uma consulta SQL não pode estar na camada de apresentação, assim como regras de apresentação não podem estar no domínio, assim como regras de negócio não podem estar no banco de dados, etc. O próximo programador que trabalhar no projeto não deve ter que adivinhar onde escolhemos guardar as coisas, elas simplesmente devem fazer sentido de acordo com as camadas do projeto.

Preservar ao máximo a camada de domínio também deve ser considerada uma missão crítica, afinal de contas, o domínio é o coração do software. Quando desenvolvemos um SI para qualquer área, investimos tempo aprendo sobre o domínio. Esse investimento deve ser preservado ao máximo, mas para isso, o domínio não pode ser infectado com as tecnologias envolvidas no projeto. Vincular o domínio de um projeto a uma tecnologia é fazer com que o domínio do projeto não possa ser resolvido sem ela. Já ouviu falar de algum software que funciona em uma tecnologia muito antiga e a empresa não quer substituí-lo por que investiu um bom dinheiro naquele sistema? Agora, já pensou se esse domínio estivesse isolado e as demais camadas do software pudessem ser substituídas?

Não dominar as tecnologias escolhidas para o projeto também é um pecado grave. Nunca fazemos o melhor que pode ser feito, fazemos o melhor que o nosso conhecimento permite, e mesmo com muito conhecimento, corremos o risco de não fazer “o melhor”, imagine então quando somos iniciantes no que estamos nos propondo a utilizar. Algumas lições poderão ser aprendidas tarde demais. As tecnologias são criadas para facilitar o nosso trabalho, mas não podemos ser dependentes dela. Muitos fornecedores prometem produtividade extrema com suas ferramentas, mas na minha experiência, produtividade amarrada ao fornecedor é extremamente prejudicial no longo prazo.

Concluindo, um software pode nascer legado simplesmente por não o organizarmos de forma decente ou usarmos as tecnologias de forma errada. A fase inicial de um projeto é onde precisamos de toda a nossa atenção e de toda ajuda necessária para fazer com que o investimento feito no projeto seja duradouro.

Artigo originalmente publicado em heroisdati.