Postagens

Mostrando postagens de 2017

Arquitetura em projetos de aplicações em nuvem - noções iniciais

Hoje o foco é arquitetura para uma aplicação que será implantada na nuvem. Em primeiro lugar, o que motiva colocar uma aplicação na famosa nuvem? Se você pensou algo do tipo "deve ser melhor, porque todo mundo está fazendo", quero que você reflita mais sobre suas decisões.

Existem motivações para se colocar uma aplicação em nuvem. Cito algumas: necessidade de começar com pouco investimento em infraestrutura e crescer sob demanda; possibilidade de escalar a aplicação horizontalmente em resposta rápida a uma quantidade de acessos maior que o normal; de forma análoga, a capacidade de diminuir a escala da aplicação e evitar servidores ociosos (e seus custos) em momentos de calmaria; menor preocupação com infraestrutura e sua gestão; alta disponibilidade; facilidade de criar ambientes de homologação e fazer o chaveamento entre estes e produção. Bem, existem outros fatores, certamente, mas vamos focar nesses.

Para se conseguir obter os benefícios de uma aplicação em nuvem é precis…

Validação arquitetural

Continuando o papo sobre arquitetura, hoje o foco é sobre a sua validação. A ideia é responder se a proposta arquitetural feita irá honrar todos os requisitos, especialmente os não funcionais.

Como eu posso saber se o site que eu planeje suportaria dez mil usuários simultâneos? Ou quantas conexões eu tenho que colocar no meu pool para dar conta de atender aos meus clientes, na minha aplicação multi-tenant? Esse tipo de pergunta é melhor respondida se você colocar a prova o sistema.

O ideal é fazer uma carga e observar, colhendo alguns indicadores. Ora, como qualquer bom trabalho, o primeiro passo é planejar: o que precisa ser medido / testado? Quais serial bons valores obtidos? Para esta última pergunta, vale buscar referências de mercado, sua base histórica (você tem uma, não?), informações com parceiros e quaisquer outras fontes que puder levantar. Então, é preciso se munir de instrumentos para colher indicadores. Busque ferramentas que possam medir uso de memória, processador, disc…

Documento de arquitetura

Hoje, o assunto é a documentação arquitetural. Entendo que documentar a arquitetura tem duas grandes funções: comunicar formalmente as decisões tomadas, para nortear o desenvolvimento do software, e registrar para consultas futuras, resgatando o racional empregado.

A forma de documentar pode variar bastante, mas me agrada mais os formatos publicáveis em portais de documentação, exportando o conteúdo em HTML puro ou na modalidade WIKI, com marcações - que não deixa de ser uma variação do hipertexto tradicional. Essas formas são fáceis de se consultar e indexáveis.

O que colocar em um documento de arquitetura?

1- Eu gosto de começar com uma visão geral do problema e um diagrama, com o que é chamado de Big Picture, que mostra um panorama da solução técnica, comentando as principais características da arquitetura proposta. Normalmente se mostra um desenho com as camadas lógicas da aplicação, incluindo as ortogonais (cross cutting concerns), que tipicamente são resolvidas por injeção de có…

Um pouco mais sobre arquitetura

Vamos discutir um pouco mais sobre arquitetura? Bem, logo depois de ter entendido o problema e traduzido as necessidades do cliente em requisitos (vide posts anteriores sobre esses assuntos), é hora de definir a solução técnica.
Importante: pode existir solução técnica preliminar, normalmente feita antes de vender o projeto, ainda em fase de negociação com o cliente, com o objetivo de fazer estimativas de prazo e custo. Para o escopo deste post, focaremos na solução técnica da fase de projeto mesmo, quando o negócio já foi fechado. 
Primeiro ponto importante: normalmente há mais de uma solução técnica candidata. Por isso, é preciso decidir qual dessas opções será a implementada. Para isso recomendo montar uma tabela de decisão, em que são colocados critérios objetivos, com uma escala numérica e pesos para os critérios. A solução que obtiver mais pontos, segundo esses critérios ponderados será a escolhida. Não há uma receita para os critérios, mas posso dar exemplos: conhecimento do ti…

Levantamento de requisitos

Hoje o papo é sobre o começo do processo de engenharia de software: os requisitos.

Vou começar com uma analogia que gosto de fazer. Imagine que você não se sentiu bem e foi a um pronto-socorro. Agora, imagine que o médico que o atendeu não examinou direito e já receitou um remédio, mas não era exatamente para o problema que você tinha. Você não melhora, vai a outro médico, que o analisa corretamente, pede exames complementares e dá um diagnóstico mais preciso, encaminhando ao tratamento adequado.

Bem, se você quiser sair fazendo o software, sem fazer o levantamento e a análise dos requisitos, você estará receitando um remédio para um problema que você nem sabe qual é. Não parece nada bom, não é mesmo?

Os requisitos servem para formalizar o domínio do problema. Não que software ou o negócio do seu cliente sejam problemas. É que se chama de problema o desafio que se tem ao preparar um software para apoiar um determinado objetivo, normalmente de algum negócio.

A arquitetura e a codificaç…

Requisitos conflitantes e dilemas no projeto de software

Ah, os trade-offs... Todo projeto nós os encaramos. E temos que tomar decisões. Daquelas importantes, que podem gerar desconforto para algum envolvido.

Antes de mais nada, afinal, o que é esse tal de trade-off? Este termo é utilizado para indicar uma situação que é necessária uma escolha, para resolver um certo conflito. Um exemplo que sempre cito é: um stakeholder solicita que o sistema seja extremamente seguro e quer que seja aplicada uma complexa criptografia em tudo o que se possa imaginar. Legal. Mas outro stakeholder solicita que o software entregue as resposta com o máximo de desempenho possível. Hummm... Aquela criptografia, solicitada pelo primeiro, degrada a performance do sistema. E agora? Eis o tal do trade-off.

Bom, sei que é clichê, mas aqui não tem muito certo ou errado. A dica para lidar com os trade-offs é avaliar cada requisito sob vários aspectos. Julgo que o mais importante é quanto de valor aquele requisito incorpora ao sistema e a quem o solicitou. Quão important…

Rastreabilidade: da necessidade do cliente ao produto pronto

Você já se perguntou de onde veio alguma fórmula mágica que está escrita no código? Ou já se deparou com o desafio de avaliar qual seria o impacto de um requisito que mudou? Para deixar sua vida mais fácil, o que é necessário é que seu projeto tenha rastreabilidade.

E o que é rastreabilidade? É tornar evidente o vínculo entre as etapas e entre os artefatos gerados durante o processo, para saber qual a sua origem ou motivação.

O ideal é que uma necessidade do cliente seja mapeada em um ou mais requisitos. Não basta apenas evoluir o texto da necessidade de forma a gerar os requisitos, tornando-o objetivo e passível de testes. É preciso documentar que a primeira está associada a esses requisitos. A forma de fazer isso pode variar. Há quem crie matrizes de rastreabilidade, que funcionam bem. Também é possível identificar necessidades e requisitos com códigos inteligentes, de modo que uma parte do código dos requisitos seja justamente o da necessidade que o motivou - o que funciona para a …

Afinal, o que é qualidade?

Esse blog é sobre qualidade, mas sabe de uma coisa? Não conceituamos qualidade até agora. Bem, há diversas definições, de vários autores diferentes, e a que mais gosto é:

"Qualidade é a conformidade do produto às suas especificações" - Philip Bayard Crosby.
Adaptando para nosso contexto, qualidade é a conformidade com os requisitos. Então, para atingi-la, eu preciso compreender profundamente a necessidade do cliente, para a atendê-lo plenamente.
No entanto, esse é apenas um ponto de vista do conceito. Nesse caso, o produto final tem qualidade, o que já é uma grande coisa. Porém, a que custo chegamos a esse ponto, do estado da arte no atendimento aos requisitos? Então cabe uma reflexão, que é a respeito de como fazemos. Ora, o produto é o que vamos entregar. O modo de fazer diz muito também sobre a qualidade. Será que o cliente estaria disposto a pagar qualquer valor para obter um produto de alta qualidade? E o tempo? O fato de entregar com qualidade nos permite gastar quanto …

Cada tarefa deve ter um e somente um dono

Esse blog já introduziu o conceito de processos. Hoje quero dar ênfase na importância de cada tarefa de um processo ter um dono. E somente um.

Vou aproveitar o post anterior, em que são mencionadas as práticas arquiteturais e sobre o papel do arquiteto. É possível dizer que a arquitetura, no contexto da engenharia de software, é um processo. Neste, são recebidos os requisitos, que são analisados e discutidos, de forma a criar ou transformar a proposta arquitetural para o software. Como produtos de trabalho, podemos ter um documento de arquitetura e/ou modelos diversos, sugestões de aplicações de patterns, algum código de referência ou scaffolds (códigos comuns, baseados em modelos para resolver problemas simples e recorrentes), entre outros.

Dado que a arquitetura pode ser vista como um processo, a mesma é dividida em tarefas. Cada tarefa é de responsabilidade de uma única pessoa. Por que isso? Ora, se ninguém responder para uma tarefa, a mesma simplesmente não sai. É despriorizada ou…

Arquitetura de software e o papel do arquiteto

Quando falamos em grupos a respeito engenharia de software, acabamos nos deparando com experiências bem diversificadas, tanto de sucesso quanto de grandes falhas. Dentre esse indivíduos, há várias posturas sobre o assunto arquitetura e o papel do arquiteto, os quais podemos citar aqueles que:desconhecem e/ou ignoram o papel do arquiteto ou as práticas arquiteturaisconhecem, mas não percebem valor em ter um arquiteto no timeconseguem ver valor, mas não compreendam plenamente o seu escopo de atuaçãoadotam as práticas de arquitetura e valorizam o papel do arquiteto na medida certa Para fugir um pouco dos conceitos acadêmicos, vou falar como entendo a arquitetura: 
Trata-se de um conjunto de atividades e práticas, com o objetivo de descrever o domínio da solução, com base numa visão geral do domínio do problema e uma boa compreensão dos requisitos, de modo a viabilizar a entrega do software com qualidade, atendendo à expectativa do cliente.
O arquiteto de software, por sua vez, é o profiss…

Testes de comportamento

No último post, comentei sobre a importância da boa comunicação para a correta interpretação dos requisitos. Também escrevi sobre o gap de comunicação. Para continuar nessa linha, gostaria de introduzir um assunto que vai auxiliar bastante no processo de elicitação dos requisitos e, de brinde, vai gerar um ativo importante na automação dos testes. Trata-se do emprego das ferramentas de testes de comportamento.

Quando algum stakeholder solicita algo para o sistema, o faz num linguajar próprio, não técnico, muitas vezes vago ou ambíguo. Dizemos que se trata de uma necessidade. Esta não é passível de teste, por ser subjetiva. Então, precisamos transformar uma necessidade em um requisito. Este, por sua vez, é objetivo, claro e passível de verificação. Uma necessidade pode ser evoluída para um ou mais requisitos, que podem ser funcionais ou não funcionais.

As ferramentas de testes de comportamento permitem registrar os textos dos requisitos de uma maneira mais formal, mas de uma forma simp…

Dica de comunicação

Hoje resolvi falar sobre comunicação. Há inúmeras estatísticas que citam a comunicação como uma das principais vilãs nos fracassos de projetos diversos, inclusive os de engenharia de software.
É evidente que comunicação é um tema amplo e, por isso, vou focar num ponto, que vou chamar de gap de comunicação.

O gap de comunicação, nesse contexto, é a diferença entre o que o emissor da mensagem quis dizer e o que o receptor efetivamente entendeu.

Imagine a fase de elicitação (levantamento) de requisitos. Independente do processo adotado ou técnica empregada, todo software precisa partir de requisitos (ou histórias de usuário, ou use cases, ou o que quer que seja). Cada stakeholder (envolvido ou afetado) que participar dessa etapa irá se comunicar com o time técnico e poderão acontecer várias coisas, a saber:

A pessoa pode pensar alguma coisa, mas ter dificuldade de se expressar e comunicar algo diferente;Haver um pensamento complexo, mas transmitir uma explicação simplista, insuficiente;Se…

Software profissional tem teste, incondicionalmente

Já se foi o tempo em que um desenvolvedor só programava. E esse tempo não deixou muita saudade. O fato é que é impossível, hoje, desvincular da atividade de desenvolvimento, a etapa de construção dos testes automatizados. Afinal, como eu sei se eu terminei de codificar, que meu objetivo foi atingido? Os teste ajudam a saber isso. E muito mais!

É muito comum adotar a prática conhecida por TDD, brilhantemente descrita pelo ilustre Kent Beck. Segundo essa proposta de abordagem, primeiro é pensado no teste, para depois fazer o código propriamente dito. Não é meu objetivo explicar TDD aqui, pelo menos não nesse post. Recomendo fortemente a técnica. Se não conhece, vá atrás. Agora.

Os testes ajudam a definir o critério de pronto (done), indicando que o código está apto a ser entregue. Além disso, a bateria de testes roda de forma automática, a um custo muito baixo. Isso ajuda a evitar o que é conhecido como regressão do software. Em um cenário em que a cobertura de testes está boa, se há al…

Documentação de processos - por onde eu começo?

Que tal discutir um pouco sobre como documentar os processos? Em primeiro lugar, para documentar, o processo já deve ter sido discutido com o time, os especialistas, os consultores (se aplicável), enfim, todos os envolvidos. É comum ter um esboço de um fluxo que representa o processo. Particularmente, gosto do diagrama de atividades UML para isso, que é simples, permite representar desvios, paralelismo e atende bem. Mas o mais importante é escolher alguma forma de diagrama que o time compreenda. Se for um padrão de mercado, ótimo. No entanto, é essencial que as pessoas que precisem entender do processo saibam compreender perfeitamente o desenho.

Critérios para escolher uma ferramenta:

Facilidade de uso, inclusive de dar manutenção no que já foi gerado - essa particularidade é especialmente importante, já que o processo é vivo e sempre, sempre evoluiCusto Qualidade da exportação do conteúdo - eu prefiro as que exportam em HTML e eu possa gerar um portal, acessível a todosPossibilidade d…

Processos formais na sua empresa - primeiros passos

Olá pessoal! Hoje eu gostaria de falar um pouco sobre o pilar de processos e citar uma ferramenta. Já sabemos que as pessoas formam a peça mais importante para a produção de software com sucesso. Mas os processos ajudam muito em pontos como previsibilidade, produtividade e padronização, enquanto que as ferramentas agilizam e conferem maior precisão.

Não vou explorar um processo específico hoje, mas o conceito, de uma forma mais geral. Em primeiro lugar, o que é e para que serve um processo? Bem, processo está relacionado a algum tipo de transformação: há entrada, processamento, saída. Os processos são registrados para formalizar e garantir que as boas práticas sejam empregadas. A inteligência corporativa acumulada tende a ser incorporada nos processos, fazendo com o que foi feito de bom seja repetido, enquanto o que não agregava, ou gerava desperdício, fosse descontinuado.

Muita gente associa processo a burocracia. Não gosto muito de polemizar, mas vou ter que dizer que essas pessoas …

Brilho nos olhos

No último post, eu sugeri que há uma relação entre a qualidade do software e o alinhamento dos colaboradores em relação aos valores da empresa.

Só para contextualizar quem começou por esse post e pulou o último:

O funcionário que concorda com os valores da empresa e acredita neles vai trabalhar mais motivado/feliz/interessado/engajado que outro colega que não está tão sintonizado assim nesses mesmos valores.
As pessoas formam o principal pilar para o sucesso, seguidas pelos processos e ferramentas, necessariamente nessa ordem.
Ora, isso não é garantia da qualidade, certo? Trata-se apenas de uma condição mais favorável para conseguir o nível de qualidade esperado.

Bem, quero continuar nessa linha e mencionar que a questão motivacional influencia brutalmente nos resultados. No entanto, motivação não vem apenas de um alinhamento com a missão, a visão e os valores. Há outros fatores que aumentam o engajamento da pessoa e potencializa seus resultados.

O principal deles é o que muitos chamam …

Um breve olhar do que já foi escrito

Já faz algum tempo, eu tive a oportunidade de escrever um artigo relacionado à proposta desse blog, cujo objetivo é discutir como melhorar a qualidade do software produzido pela nossa comunidade. O texto, de título Definição de papéis no processo de Engenharia de Software, foi publicado na Engenharia de Software Magazine, edição 53. O conteúdo, disponível para assinantes MVP, pode ser encontrado nesse link.

Bem, gostaria de enfatizar que ainda acredito nos três pilares, citados em ordem decrescente de importância: as pessoas, os processos e as ferramentas.

Sim, as pessoas são os elementos mais importantes do sucesso de sua empreitada no mundo do software. E hoje decidi falar um pouco sobre como essas pessoas se tornam a peça chave do sucesso, começando por como trazer um talento para time. Aqui tem uma tonelada de clichês e, inevitavelmente, vou acabar citando um ou outro, nesse ou em algum post futuro, quando complementar o assunto.

Espero que minha primeira dica não seja tão batida:…

Sobre esse blog

Sobre o blog Olá pessoal! Sejam todos bem vindos!

Meu nome é Murilo Saggion Beriam e esse é o meu blog sobre qualidade de software.

O foco aqui é abordar boas práticas no desenvolvimento de software, de modo a construir um produto ou serviço de qualidade. Isso inclui a discussão de todos os aspectos envolvidos, com destaque para pessoas, processos e ferramentas, que eu considero os três grandes pilares para o sucesso.

É importante comentar que a abordagem empregada tem apelo mais prático, embora eu acredite que o conteúdo aqui discutido possa ser usado também em contextos acadêmicos e de cunho científico.

Seu comentário é bem vindo para contribuir, desenvolver e, claro, corrigir.


Sobre mim Bacharel em ciência da computação pela UFSCar, especialista em TI aplicada à gestão estratégica de negócios pela FGV, na área de desenvolvimento de software desde 1999.

Arquiteto de software, atualmente com ênfase em solução em nuvem para gestão de RH.

Mais de oito anos de experiência como professo…