quinta-feira, outubro 16, 2008

O Zen da Gestão Ágil: Curso com David Anderson no Brasil

O evento Zen of Agile Management está se aproximando! Será um evento fundamental e contará com a importante presença de David Anderson, autor do livro "Agile Management for Software Engineering" e um dos principais criadores do MSF 4.0 (Processo de desenvolvimento criado pela Microsoft). O curso acontece nos dias 21 e 22 de outubro de 2008.

Alguns dos tópicos do workshop:

- Como criar ou destruir confiança
- Minha receita para o sucesso
- Métricas, medição, rastreamento e indicadores para a Gestão Ágil
- Identificação de gargalos e Gestão por Restrições (TOC)
- Identificação de perdas
- Gestão de problemas e riscos
- Planejamento simples de iterações
- Planejamento avançado e previsível de iterações, baseado em processos de baixa variação
- Sistemas puxados e "Kanban"
- Seleção do mix de produtos e priorização
- Teoria das Opções Reais e o suporte à decisão
- Combinação de Agile e CMMI
- Como alcançar uma organização ágil de alta maturidade (cultura "Kaizen")

quarta-feira, outubro 15, 2008

Blog Action Day 2008: A luta contra a pobreza e a Tecnologia da Informacao

Hoje, dia 15 de outubro, é o Blog Action Day 2008. O tema deste ano é a luta contra a pobreza.

O que a área de Tecnologia da Informação pode fazer para ajudar nesse quesito? Basicamente, temos hoje a ferramenta por exclência para nos apoiar na luita contra a pobreza e a desigualdade social: a Internet. É empiricamente provado por diversos estudos de economistas que o nível educacional de um país está relacionado ao nível de pobreza deste. Um país com uma grande massa de pessoas despreparadas e com baixa escolaridade é mais pobre que países com alto nível educacional.

O acesso universal à Internet e a busca de um laptop por criança, portanto, deveriam ser políticas públicas que devemos buscar em nosso país. É claro que só o computador e o acesso à Internet não vão resolver. As pessoas precisam aprender a ler e escrever corretamente, não só o português como o inglês (grande parte útil do conteúdo disponível na Internet está na língua inglesa). Devem também ser ensinadas a operar corretamente o computador e seus diversos aplicativos.

Portanto, nesse Blog Action Day, vamos nos lembrar de fazer nossa parte e apoiar ONGs (como o Comitê pela Democratização da Informática) e políticas públicas voltadas para a universalização do acesso à maior biblioteca e fonte de informação da face da Terra: a Internet.

sexta-feira, outubro 10, 2008

Arquitetura de Software: O que é e como documentar

Resolvi escrever esse aartigo explicando brevemente o que é arquitetura de software depois de uma dúvida na lista de discussões UML Brasil. A dúvida acabava por confundir um pouco arquitetura de software APENAS como sendo o diagrama de classes de design. Antes fosse só isso... os arquitetos de software teriam muito mais tranquilidade... rs.

Vamos começar pela definição teórica clássica do IEEE no seu guia de recomendações IEEE 1471 (e que também se encontra no livro "Software Architecture in Practice, 2nd Edition"): "A arquitetura de um sistema de software é a estrutura ou estruturas do sistema, que contempla elementos de software, as propriedades visíveis externamente desses elementos e o relacionamento entre eles".

É claro que essa definição precisa ser detalhada, pois senão ficamos na mesma :-) .

Quando se fala de estruturas estamos falando de estruturas estáticas e dinâmicas. As estruturas dinâmicas definem como o sistema atua em tempo de execução, portanto apenas um diagrama de classes não resolveria esse ponto.

Quando falamos em propriedades externamente visíveis estamos falando das interações de um elemento ou um sistema com o seu ambiente externo. Pode ser os fluxos de informação de entrada e saída, a forma como o elemento responde aos estímulos externos e o contrato (a interface) desse elemento.

Outra definição importante, que encontramos no excelente livro "Software Systems Architecture: Working with stakeholders using viewpoints and perspectives", é a de que a arquitetura de software deve ser dirigida pelas necessidades dos envolvidos do projeto: clientes, usuários, departamento de TI, suporte, produção, operação, etc. A arquitetura de software não pode ser pensada sem o contexto dos stakeholders. Isso pode parecer óbvio, mas muitos sistemas por aí são feitos sem a devida atenção às necessidades dos envolvidos. Já vi muita gente escolhendo uma determinada arquitetura por ser a onda do momento, sem se perguntar profundamente se aquilo atenderia as necessidades do negócio. Resumindo: Arquiteturas devem ser criadas apenas para atender às necessidades dos stakeholders. Uma boa arquitetura é aquela que atende com sucesso os objetivos e necessidades de seus stakeholders.

Outra definição interessante, vinda do RUP, é a de que a arquitetura de software é um conjunto de decisões cruciais que restringem considerações de design e programação e que possuem um alto impacto para serem revertidas. Por exemplo, se for definido que o sistema será feito em JEE usando um framework Struts 2 então os desenvolvedores não poderão simplesmente desenvolver parte do sistema usando o Spring MVC. Além disso, mudar de Struts 2 para o Spring MVC, por exemplo, traria um alto impacto para a camada web da aplicação.

Além disso, é papel do arquiteto esclarecer as motivações por trás da escolha de determinados elementos arquiteturais em detrimento de outros. Também realizar análises "buy vc. build", isto é, comprar ou utilizar um componente open source ao invés de construí-lo do zero. Ou construir algo do zero considerando que no mercado existe já algo pronto para uso.

O arquiteto também deve enfatizar e focar nos atributos de qualidade do sistema, os chamados requisitos não-funcionais. Deve verificar necessidades vindas dos stakeholders relacionadas a performance, escalabilidade, manutenibilidade, segurança, internacionalização entre outras.

Para se ter uma idéia das várias "áreas" às quais um arquiteto deve endereçar, podemos recorrer novamente ao livro "Software Systems Architecture". O princípio inicial definido pelos autores é que "não é possível capturas as necessidades funcionais e as propriedades de qualidade de um sistema complexo em um único modelo compreensível". A partir daí é que surge a necessidade do que eles chamam de Visões e Perspectivas. O RUP possui o 4+1 View Model. O IEEE define até mais alguns. Algumas dessas Visões: Informacional, Concorrência, Desenvolvimento, Implantação, Operacional e Funcional. Já algumas das perspectivas importantes são: Segurança, Performance e Escalabilidade, Disponibilidade e Resiliência, Evolução, Acessibilidade, Internacionalização, Localização, Regulamentação e Usabilidade.

Agora pode surgir uma dúvida que é comum: devemos documentar essas coisas? Onde as documentamos?

É claro que não existe uma resposta genérica. Como tudo na Engenharia de Software... depende! Um sistema super simples não terá necessidade de documentação alguma. Um sistema super complexo (como o de um satélite ou de um Boeing) terá necessidade de uma documentação mais extensa.

Porém, para os casos em que estamos mais acostumados a trabalhar (sistemas e aplicações empresariais e corporativas) é recomendável ter, no mínimo, um "documento de arquitetura de software". Ele nem precisa ser um documento Word propriamente dito. Pode ser uma página de Wiki, uma folha A4, uma cartolina, etc.

Eu recomendo que esse documento seja sucinto e que tenha somente informações essenciais como:

- Elementos e componentes principais do sistema.
- Camadas do sistema.
- Mecanismos arquiteturais necessários ao sistema.
- Tecnologias escolhidas para resolver cada camada e mecanismo e a motivação por trás dessas escolhas.
- Componentes comprados ou open source que serão usados e como essa decisão foi realizada.
- Descrição dos principais design patterns utilizados e o porquê da escolha.
- Definição de como será feito o acesso a sistemas externos e/ou legados.

Além disso, algumas equipes podem sentir a necessidade de elaborar diagramas UML. Esses diagramas relacionados à arquitetura e ao design estarão no modelo de design (caso se use o RUP como processo de desenvolvimento). A equipe poderá usar diagramas de classe, de atividade, de sequencia, de estados, de componentes e de implantação para facilitar o entendimento visual dos elementos e de seus relacionamentos (conforme a definição de arquitetura de software feita pelo IEEE).

Reforçando e lembrando sempre que as atividades relacionadas à arquitetura são feitas de modo iterativo e incremental. Portanto, cuidado para não cair no modelo cascata e ficar durante longos períodos de tempo só escrevendo o documento de arquitetura. O bom e verdadeiro arquiteto é aquele que põe a mão na massa e prova com código e com testes que sua arquitetura realmente vai atender às necessidades de todos os stakeholders!!! Além disso, o arquiteto deve ser uma pessoa sociável e ir atrás dos stakeholders para validar suas decisões arquiteturais mais importantes.

Bom, essa é apenas uma pontinha introdutória sobre o assunto. Se alguém tiver mais dúvidas pode deixar um comentário nesse artigo!


Veja as Estatísticas