segunda-feira, 1 de junho de 2009
quarta-feira, 1 de abril de 2009
Designer não é Piloto de UML
Mais uma das "inovações" que vieram com o Java, o Designer é mais um dos camaradas incompreendidos no processo de software convencional. Este é mais um dos cacoetes da Análise Estruturada Moderna mal aplicada (pior, antes fosse só isso) que ainda vicejam no mercado.
Nós, profissionais de TI, desenvolvemos sistemas para resolver problemas com o emprego de TI. No entanto a resolução de problemas é um ramo muito maior que o imaginado por nós. Para resolver um problema temos um algoritmo básico composto das atividades:
Fazendo um breve exercício mental agora... A grosso modo, a tarefa do enunciado do problema é delegada à Engenharia de Requisitos. A implementação do modelo de análise e a análise podem ser executadas por um analista de sistemas / OO. Daí podemos partir para a implementação da solução. Até aí nenhuma novidade.
E a implementação fica a cargo de quem? Ora, do desenvolvedor. Quem é o desenvolvedor? Ora, é um programador sênior. O que um programador sênior faz? O mesmo serviço do júnior, só que mais rápido com maior qualidade, afinal ele tem anos de experiência E CONHECE UML o suficiente para especificar um software e delegar a implementação para o desenvolvedor júnior. Certo...
Volto a seguir a este assunto...
No desenvolvimento de software temos dois grandes domínios: o espaço do problema, isto é, o mundo "real", e o espaço da solução, o mundo do computador.
Na OOAD (Object Oriented Analysis & Design) o analista é encarregado de modelar o problema independentemente de tecnologia de modo a descobrir insights sobre o sistema em desenvolvimento. É vantajoso trabalhar de uma forma mais conceitual simplesmente para "evitar as tentações" do detalhamento inerente à tecnologia usada na implementação do sistema.
Em UML o analista utiliza os estereótipos Entity, Workflow e Boundary (não sei se o método é do Booch ou do Jacobson) para identificar objetos e representar respectivamente entidades, lógica de controle e interface externa (gráfica ou de serviços). Para concluir seu trabalho o analista pode criar um diagrama de robustês para verificação de consistência entre casos de uso e elementos do modelo de análise. Antes que vestais agilistas e desenvolvedores molestados por consultores CMMI gritem "CASCATA", Bittner, um engenheiro do processo unificado resume elegantemente esta questão em uma pergunta : "Artifact or not artifact?".
Qual o trabalho do Designer? O trabalho do designer é transpor as definições do espaço do problema para o espaço da solução, isto é definir as linhas gerais da solução para o problema levantado durante as atividades de requisitos e análise restrita pelas estruturas arquiteturais pré-definidas ou construídas concomitantemente.
Isto quer dizer uso UML? Uso de UML é uma prerrogativa que a equipe do projeto deve decidir, portanto a resposta pode ser talvez. Não vou falar do "bom-senso", se tudo se resumisse a bom-senso certamente não teríamos a menos expectativa de melhora. Acho este termo tão overused quanto "agile" ou "web 2.0". Alguns critérios podem ser utilizados para definir quando e como usá-la.
Larman no livro do "barquinho" propôs 3 usos para a UML: elucidação do problema, documentação e UML executável. UML não é linguagem de programação, contém estruturas insuficientes para sua transformação em uma linguagem compilável, portanto já descarto de cara a última alternativa (sorry, MDA).
Em relação a documentação o uso da UML já começa a ficar interessante. Neste sentido o balanço adequado entre texto e diagramas pode prover documentos ricos e de grande valor principalmente para a manutenção de um sistema.
A UML conduzida pela Modelagem Ágil pode servir como veículo para a elucidação de um problema E da solução. Solução? Este é o interesse do designer.
Voltando às atividades do designer na OOAD... O nosso "programador sênior que conhece UML" constrói a solução a partir do modelo de análise. Na forma mais simples ele faz a "tradução" dos modelos de análise para o modelo de solução. Neste sentido ele criaria uma classe de entidade decorada com atributos JPA (ou Entity Beans 2.x), uma classe service decorada com atributos de transação do Spring (ou Session Beans 2.x) e alguns controllers (Struts 1.1, alguém??) em conjunto com alguma view JSP, JSF, ou Freemarker.
Mas o que não está nos livros? Melhor, o que está apenas subentendido nos livros?
Há todo um trabalho de coaching conduzido pelo designer, agora chamado de líder técnico. O designer conversa com o arquiteto e elabora a estrutura de um módulo. Pode fazer uma especificação temporária no quadro branco usando, quem sabe?, UML.
Depois conversa com o desenvolvedor e o ajuda a implementar a infra-estrutura do módulo: teremos um façade, um mediator, as responsabilidades destas estruturas são proteger o negócio e coordenar o workflow de diversos objetos da interface. De olho na arquitetura o designer prepara a infra-estrutura de artefatos seguindo as especificações do arquiteto e do gerente de configuração.
Durante a implementação do módulo, o Designer será solicitado pelo desenvolvedor para resolver problemas de queries, problemas de APIs de terceiros e quem sabe elucidar requisitos com os analistas frente a problemas que só podem ser encontrados durante o desenvolvimento.
Concomitantemente o Designer pode fazer a documentação de um módulo, especificando as responsabilidades de cada componente e, quem sabe?, usando UML.
Concluindo
O meu ponto foi: o Designer tem um papel importantíssimo na condução de um projeto, é a pessoa responsável por elaborar solução e viabilizar a implementação. Uma das falhas do pessoal de processos é ignorar a interação humana necessária para a resolução do problema. Uma das falhas dos agilistas é negar a priori todo um apanhado de técnicas OOAD que podem servir para a resolução de um problema. Onde falo OOAD não excluo abordagens para enriquecer o design como DDD ou ficando no básico dos Design Patterns ou GRASP Patterns.
Outro termo overused como "agile" e "bom-senso" é "a virtude está no meio". Este é mais um paliativo que solapa a execução de uma reflexão honesta sobre nossas atividades de TI. Cada tópico de um processo de software deve ser bem pensado e experimentado. E isso só se dá com estudo, aplicação e reflexão constantes.
segunda-feira, 30 de março de 2009
Soft-shaman agora com Twitter
Como paliativo ao meu problema de atualizações, vou tentar adotar uma estratégia mais imediatista. Estou usando o twitter para registrar progressos intermediários nas minhas pesquisas, experimentando uma abordagem de micro-blogging.
Inclui um gadget "Twitter" aí ao lado que trás os últimos posts no twitter (o howto peguei daqui).
Como beta inclui algumas impressões do livro do Ragsdale sobre o tópico de Multi Objective Linear Programming.
T++
quarta-feira, 25 de março de 2009
No meio da enrascada, respire fundo e siga adiante!
Pois é, ando meio sumido. Tive problemas de ordem técnico-acadêmica.
Bom, primeiro, a lâmpada da tela do meu note foi desta pra melhor. Até o técnico descobrir, encomendar a peça e executar o conserto se vao uns dez dias.
Como desgraças nunca vêm sozinhas (me lembro de uma citação do Corvo mais ou menos parecida), meu orientador finalmente decidiu a data de entrega da minha dissertação. Está perto. Bem no momento onde tive que me render ao apelo das lan-houses.
Fico agradecido a vocês que mantiveram meu contador do Motigo acima do zero. Na verdade este post é uma "prestação de contas" ao leitor Rogério sobre o post Padrões de Gerência de Configuração com Subversion 1.5 - Parte I: Conceitos. Ele pergunta sobre a continuidade da série de padrões de gerência de configuração.
Pretendo postar alguma coisa no meio da semana que vem, depois de entregar uma versão para revisão da minha dissertação para o meu orientador (segunda), talvez próxima quarta ou quinta (01/04 ou 02/04). Certamente a segunda parte da série de padrões de configuração está na frente.
Não gosto muito de prometer, afinal gerenciamento de expectativas é um problema a ser enfrentado. Mas lá vai um road map para os próximos assuntos que pretendo tratar no blog:
Até o momento estou focado na parte mais Corporativa da Arquitetura de Software. Então tem um assunto fantástico que descobri na administração para tentar avaliar uma série de possíveis arquiteturas de software. Aí vai então:
Espero com o tempo pôr alguns temas mais próximos da arquitetura de sistemas, como SOA, ESB, e de outras disciplinas da Engenharia de Software.
Então tá. Já estão me chutando da Lan House.
Até mais.
sábado, 7 de março de 2009
Sobre Prudência, Métodos Ágeis, Honestidade Intelectual e Caça as Bruxas
Não acredito que o tempo seja a verdadeira escala de medida do progresso. Apenas porquê temos hoje uma profusão de novas informações, novos métodos e novas promessas, não acredito que sejamos melhores do que os que nos precederam.
Não acredito num futuro brilhante como resultado unicamente baseado nas nossas ações do presente. Acredito no máximo num futuro razoável a enormes expensas de muito trabalho físico e cognitivo baseado na experiência pessoal de cada indivíduo. Compreendo que a estabilidade e a mudança devem ser reconhecidas e reconciliadas.
O que já é um ganho em si.
Apenas para mantermos nossos ganhos devemos nos esforçar para resistir à esmagadora força da entropia (no sentido de dispersão de energia). Sendo assim, o feedback é um mecanismo importante para a manutenção da concentração de energia do sistema para que este consiga sustentar um nível de trabalho aceitável, possibilitando o reconhecimento de uma cadeias de causa e efeito passíveis de uso na manutenção de ciclos virtuosos.
Isto foi o que me atraiu mais no advento do Scrum. Uma prática calcada na revisão constante de nossas ações passadas. Mas o Scrum não é nada mais que isso, é uma descrição de um mecanismo de feedback em um sistema.
Atualmente está ocorrendo uma caça às bruxas onde o Scrum é o bode expiatório da vez (Adopting the Whole Enchilada, Flacid Scrum e outras asneiras vindas a reboque do Decline and Fall of Agile).
Retrospectivas não são apenas pontos de replanejamentos per se. Tampouco são reuniões de terapia de grupo. São pontos ativos onde o feedback é usado para correção de rumo do método. É o ponto onde o relacionamento causal de nossos atos pode ser analisado e corrigido. É o reconhecimento do pensamento sistêmico como modo de se usar a dinâmica de sistemas em nosso proveito.
A despeito de toda uma indústria de consultorias e certificações criadas a seu redor, este é o valor de Scrum: sua simplicidade. Seu respeito a uma regra básica da física o torna um método elegante. Ponto.
Obviamente Scrum não é o suficiente. Para tirarmos proveito disto temos que ser criteriosos durante a retrospectiva. Isto não significa usar o bom senso, ou senso comum. O que quer que isso signifique acredito que não seja o ponto. Falo de honestidade intelectual. Não existe bala de prata.
Ser intelectualmente honesto não é uma tarefa fácil, reconfortante, ou que traga felicidade ou paz. Não foram nem uma nem duas vezes que idéias minhas foram refutadas (tanto justa como injustamente). O conhecimento da verdade, e principalmente de sua extensão, não é uma tarefa para fracos. Scrum não é o suficiente.
O que falta aos praticantes, agilistas convictos ou não, é pensamento crítico. Aproveitar os momentos de retrospectiva para REALMENTE fazer um ponto de inflexão. Onde podemos adotar uma série de técnicas fartamente documentadas na literatura de ciência da computação sistemas de informação e administração, submetê-las ao duro teste da prática e avaliá-las sem dogmatismo.
Durante a retrospectiva devemos entender que não há nada o que fizemos, absolutamente NADA, que seja realmente novo (não sou um fã de Nietzche). No decorrer de 40 anos de engenharia de software e de 10000 anos de outras engenharias, o que temos a fazer é olhar os que nos precederam, e isto não se restringe aos agilistas, nem tampouco ao RUP ou outra metodologia.
Não é uma questão de adoção do "bolo inteiro" é uma questão de adoção do que realmente podemos adaptar e empregar em um sistema sócio-técnico altamente dinâmico para que possamos retardar o avanço da entropia.
domingo, 1 de março de 2009
Sobre Arquitetos de Software, Life Planners, Consultoras Natura e Jequiti e Rebranding
Atenção! Este post deve ser lido com a tecla SAP ativada. Caso não seja muito dado a sarcasmo ou ironia, por favor, nem tente.
Rebranding é o processo pelo qual um produto ou serviço desenvolvido sob uma marca, empresa ou linha de produtos é comercializada ou distribuída com uma nova identidade. Geralmente isto decorre de um reposicionamento de uma marca na tentativa de se descolar de conotações negativas da marca anterior.
Corretagem de seguros é uma profissão cheia de inconvenientes para o próprio e para o cliente. Corretores te ligam, marcam encontros em horários de estudo ou trabalho, insistem e ainda por cima pedem indicações suas. O cliente se faz de louco, não atende ou simplesmente manda o corretor longe.
Certa feita, fui chamado para uma entrevista numa multinacional em expansão agressiva no país (corporativês é o máximo). Ao chegar lá o recrutador foi falando sobre a empresa, foi falando sobre o produto, seguros, sobre a abrangência e tudo mais. Eu já imaginando "nossa, imagina a TI desses caras".
Com andamento, fiquei sabendo que não me chamaram para arquitetar algum sistema deles, mas para ser um life planner a um soldo de milhares de reais mais benefícios e comissões. Bom ainda estava interessado, pelo soldo, aí me veio a prescrição da vaga, era um corretor de seguros. Declinei e agradeci, não tenho perfil para trabalhar com humanos estranhos 100% do tempo (apesar de viver em reuniões, workshops e entrevistas).
Isso foi o rebranding em ação.
Há tempos a indústria de cosméticos vaseada em distribuição direta contava com Vendedoras Avon, Natura e Jequiti. O tempo transformou estas vendedoras em Representantes Avon, Natura e Jequiti. Por fim estas representantes se tornaram Consultoras Avon, Natura e Jequiti.
Mais um exemplo de rebranding.
Bom, a maior parte da minha carreira fui um consultor trabalhando em algumas empresas de consultoria de TI em Porto Alegre. Talvez se minha carreira tivesse tomado outro rumo não teria tido a variedade de experiências que adquiri. Já trabalhei em áreas diversas como DBA e administrador de servidores Linux, programador e arquiteto de software e como analista de sistemas e engenheiro de processos. Sempre tive sucesso em todas as áreas. Claro, fracassos se somam ao resultado final, mas o balanço até o momento é bem positivo.
Isso ocorre devido ao rebranding nas empresas de consultoria. Não é conduzido pelo departamento de marketing, e sim pelo departamento comercial. Um consultor se torna um profissional alocado via rebranding logo após o comercial questioná-lo: "Tem idéia de como se faz?". Temos aí um rebranding à la carte no ramo de outsourcing.
Antes que se perguntem, respondo: Não, nunca fui consultor Avon, Natura ou Jequiti.
O Reverse Rebranding e o Arquiteto de Software
Como falei anteriormente aqui, o mercado local de TI passou por um tempo de dificuldades na assimilação das tendências de mercado externas. Um dos problemas de assimilação foi justamente a posição de Arquiteto de Software. Outro foi justamente a vinculação da complexidade da TI atual à plataforma java, que em si, é apenas um reflexo da própria complexidade da indústria de tecnologia atual. Isso mesmo, Java é muito mais que uma linguagem.
Ouso dizer que são poucos os verdadeiros arquitetos de software que conheço. Não vou tratar o meu entendimento sobre arquitetura de software neste post. Isto dá muito pano pra manga. Vou resumir o meu ponto: Arquitetura de Software diz respeito à mitigação de riscos em sistemas sócio-técnicos.
Isto demanda uma abordagem amplamente interdisciplinar para resolução de problemas. Dêem uma olhada na lista de livros ao lado, acredito que sejam parte integrante do corpo de conhecimento técnico do arquiteto de software.
Na área de arquitetura de software ocorreu justamente o reverse rebranding. Haviam demandas novas (gerenciamento complexidade de TI) que deveriam ser solucionadas, no entanto ao invés da adaptação estrutural necessária, foi feito um rebranding do desenvolvedor sênior em arquiteto de software sem que os skills adequados sejam desenvolvidos para o atendimento de novas demandas. Afinal faz todo sentido descolar os aspectos deficientes de uma marca antiga e esperar que todos estes sejam atendidos apenas pelo que se imagina das conotações positivas da nova marca.
Um arquiteto de software não trabalha apenas com a integração do Spring e do Hibernate. Não é um piloto de API. Deve sobretudo entender o mecanismo interno desses e o mais importante deve desdobrar o funcionamento destes mecanismos sob as condições demandadas pelo sponsor como, por exemplo, escala, tempo de vida, manutenibilidade, integração e atendimento ao negócio que em si demanda grande conhecimento do domínio.
O arquiteto deve ter conhecimento em profundidade e amplitude sobre vários aspectos da TI, do protocolo de rede, ao funcionamento de frameworks, processos de desenvolvimento até o alinhamento estratégico da organização. Isto subsidia talvez o principal skill, na minha humilde opinião, do arquiteto de software: Pensamento Sistêmico. Ver as árvores e a floresta de acordo com a necessidade.
Como resultado do reverse rebranding, já vi vários erros cometidos por "arquitetos de software". Não erros decorrentes de deficiências em conhecimentos organizacionais, conhecimentos em soft-skills, como engenharia de requisitos ou relacionamento interpessoal (por si a maior reclamação do pessoal das organizações em relação a "arquitetos" intratáveis), mas conhecimentos em tecnologia, o famoso "baixo-nível":
Concluindo
O contratante deve tomar muito cuidado quando alguém oferecer um "arquiteto de software" ou um "arquiteto corporativo". Não digo que esta situação seja generalizada, apenas que já presenciei mais de uma vez a ocorrência de fenômenos semelhantes. Volto ao assunto de definição dos skills de um arquiteto no futuro.
Um breve Contexto sobre a Tecnologia nos Últimos anos aqui no Brasil
O nosso país sempre esteve atrás das maiores tendências em TI. Talvez este gap esteja diminuindo agora com a internet. Mesmo assim temos nossos problemas ainda.
A ciência da computação passou por revoluções tão avalassadoras nos últimos 40 anos que faz com que as organizações tenham dificuldades em acompanhar não apenas a tecnologia mas o próprio mercado de TI (Quem não falou com o velho gerente de CPD que falava dos tempos do DATAFLEX, ADABAS, COBOL, ZIM e mesmo do Digitador).
Com um ciclo de mudanças nas subfunções da TI inferior a 5 anos novas carreiras e novas especializações surgem como Arquiteto de Informação, Analista IHC entre outros, como o Arquiteto de Software.
No desenvolvimento do nosso mercado local (Brasil e mais especificamente região sul), várias inovações da TI chegaram num determinado momento, mais ou menos a partir de 1996 - 1998. Entre elas a linguagem java em ambiente comercial, a adoção da arquitetura 3 camadas, o emprego da tecnologia TCP/IP e o uso deinterface Web.
Antes disso haviam plataformas proprietárias de diversos vendors, como a Oracle, a Borland, a Microsoft, e outras jabuticabas como o ZIM. Todas essencialmente duas camadas.
A gestão deste mix Tecnológico pelos departamentos de TI foi complicada. Um dos mitos que recorrentemente ouço é que toda essa complexidade é inerente à plataforma Java.
Durante a reserva de mercado na década de 80 ocorriam as guerras por padrões de plataformas corporativas, como CORBA, COM e DCOM, bem como as guerras de consolidação dos protocolos Internet. Coisas que o mercado local acompanhara apenas marginalmente. A grande maioria das empresas médias não têm acesso ao desenrolar das brigas por padrões (não é sua obrigação e nem seria de seu interesse) chegando a adotar padrões relativamente consolidados pelo mercado.
A encarnação atual de plataformas pode ser vista nos entreveros pela definição do padrão de HDTV no Brasil e nos padrões de discos óticos que substituirão o DVD, como o blu-ray.
sábado, 28 de fevereiro de 2009
Um Guia para Especifi cação de Requisitos em Manutenção
Estou concluindo meu mestrado em ciência da computação na PUC-RS. Escrevi alguns textos no decorrer do curso que não foram inteiramente aproveitados na dissertação. Apresento aqui um desses textos onde eu faço uma relação entre grau de formalidade do processo de software e a necessidade de especificação com objetivo de se chegar a um balanceamento mais adequado entre os dois fatores.
Resumidamente o meu ponto é o seguinte: dependendo do contexto podemos ter um grau maior ou menor de formalismo em relação à especificação de requisitos. Baseado em minha experiência, acredito que a especificação de requisitos é necessária para QUALQUER PROJETO INDEPENDENTE DO TAMANHO. Para isso devemos adequá-la às exigências contratuais ou características do projeto tais como tamanho, lifespan do sistema, importância e risco do negócio. ISTO NÃO SIGNIFICA ESCREVER REQUISITOS EM PAPEL DE PÃO.
O problema é que a insegurança leva as pessoas à busca de subterfúgios como a incontinência verbal. Este é o ponto em que nascem documentos extensos e ilegíveis, portanto, inúteis. Cockburn fala muito bem ao dizer que o que dá valor a uma especificação não é sua extensão e sim sua acurácia. Isto exige um bom trabalho cognitivo que pode ser otimizado com uma certa dose de experiência. Por isso gosto desta citação do Pascal:
O texto é bem "academiquês" mas acho que a leitura pode ser proveitosa. Segue.
Um Guia para Especi ficação de Requisitos em Manutenção
Souza et al. [Souza:2005] reafirma o problema histórico de documentação de requisitos e software regidos tanto pelo modelo da Análise Estruturada como pelo modelo de Análise e Projeto Orientados a Objetos. Nesta seção será abordada a forma de especificação do Processo Unificado. O objetivo das próximas seções é descrever uma estrutura lógica fundamental de especificação de requisitos para reconstrução e na seqüência expor alguns critérios para seleção e balanceamento entre a abordagem do Processo Unificado e alguns métodos tradicionais.
A Especificação de Requisitos de Software no Processo Unificado RUP
Em sistemas legados, onde a documentação de projeto, requisitos e design possa estar comprometida, pode ser difícil a especificação de um ponto de partida para a redocumentação de um sistema. O estabelecimento de uma estrutura básica pode ser de grande valia para a dimuição da ansiedade da equipe durante a adoção de um processo novo[Kroll:2006] e, consequentemente, do tempo necessário para o início do projeto.
Neste sentido o RUP pode prover uma estrutura principal, orientada a casos de uso, que pode servir como base não somente para os esforços de restauração de requisitos como eventuais esforços na redocumentação de elementos de design e processamento. Para tanto o RUP provê um formato moderno de SRS [Leffingwell:1999, Kroll:2006].
Ao invés de se valer de um formato convencional de documento SRS, essa abordagem provê uma estrutura lógica de especificação no formato de um pacote de artefatos construídos a partir da visão do produto, conforme mostrado na figura a seguir.
O ponto de partida é o documento de visão contendo:
- necessidades;
- metas;
- objetivos;
- mercados alvo;
- características do sistema.
Com a visão formada pode-se prosseguir com a especificação o pacote SRS. Este é formado através do balanço adequado entre modelagem orientada a casos de uso e técnicas tradicionais de especificação de requisitos. Apesar do foco do PU em casos de uso, há o espaço para abordagens tradicionais de especificação contempladas pelo artefato de Requisitos Suplementares[Kroll:2006].
Os Requisitos Suplementares são identificados seguindo-se o esquema FURPS+ de classificação de requisitos. O nome do esquema é um acrônimo para:
- Functionality (Funcionalidade): requisitos funcionais;
- Usability (Usabilidade): fatores humanos como facilidade de uso do sistema;
- Reliability (Confiabilidade): a habilidade de conservação das funções do sistema sob condições normais de operação;
- Performance (Desempenho): quantidade de trabalho realizado pelo sistema em relação ao tempo e recursos consumidos;
- Supportability (Sustentabilidade): habilidade da equipe técnica em instalar, configurar e monitorar produtos de software;
- + (símbolo “mais"): demais requisitos não funcionais como restrições de design, restrições de implementação, restrições de interface e restrições físicas.
A orientação a casos de uso do RUP faz parte de um conceito maior de especificação de arquitetura de software[Kruchten:1995, Kruchten:2001, Kruchten:2003]. Dadas as necessidades de diferentes perfis de stakeholders que o projeto de software deve atender, usa uma abordagem de pontos de vista para separar aspectos do software de acordo com o interesse do stakeholder. Esse é o modelo 4+1 de arquitetura de software, visto na figura a seguir.
As visões do modelo 4+1 são a lógica, processos, implementação e implantação, cada qual com objetivo e público específicos. No entanto a visão que une as demais perspectivas é a visão de caso de uso, cujo objetvo é capturar os requisitos mais significativos na forma de casos de uso ou partes de casos de uso que têm grande impacto na arquitetura do software, bem como os demais requisitos não funcionais.
Equilíbrio entre abordagens orientadas a caso de uso e abordagens tradicionais de requisitos
Há divergências na comunidade de requisitos a respeito da abrangencia da modelagem de requisitos em casos de uso. Segundo autores como Wiegers e Davis [Davis:2005, Wiegers:2003, Wiegers:2006], casos de uso não substituem requisitos funcionais especificados em um modelo de SRS convencional. Wiegers ainda aponta que há uma impedância na acomodação de requisitos não funcionais entre casos de uso do PU e na documentação de Requisitos Suplementares.
Neste sentido estes autores afirmam preferir o uso de casos de uso como um meio para se chegar a especificação de requisitos baseada em listas semi-estruturadas.
No entanto há esforços para a adoção de abordagens híbridas de especificação e modelagem[Kroll:2006, Ambler:Primer:2004]. Wiegers afirma ainda que casos de uso sofrem limitações quanto a natureza do projeto, principalmente quando a complexidade do sistema não se estabelece nas interações entre sistema e usuário e sim em camadas mais profundas de sistemas tais como:
- data warehouses;
- processamento em lote (batch);
- hardware com software de controle embarcado;
- aplicações de computação intensiva.
Leffingwell propõe a adoção de casos de uso ou especificações tradicionais seguindo critérios baseados nas características da equipe e do projeto. Estes critérios são mostrados na tabela abaixo (clique para expandir).
Cerimônia de um Processo de Software
Cada processo de software como o PU e derivações bem como processos ágeis como Extremme Programing (XP) e Scrum podem ser comparados em um mapa de processos [Kroll:2006, Kruchten:2003, Larman:2003]. Este mapa é um plano composto das dimensões:
- Pouca Cerimônia (Low Cerimony)/Muita Cerimônia (High Cerimony): no eixo horizontal. A Pouca Cerimônia produz documentação mínima e possui pouco formalismo; Muita Cerimônia produz documentação abrangente e alta rastreabilidade entre artefatos, também conhecido como peso do método.
- Cascata (Waterfal)/Iterativo(Iterative): no eixo vertical. Cascata é uma abordagem linear do Processo de Software com integração e testes tardios; Iterativo é uma abordagem orientada a riscos com adoção de uma arquitetura e testes antecipados.
A Figura acima mostra três possíveis configurações do RUP no mapa de processos de Kroll, onde a iteratividade é o fator pervasivo. O grau de formalismo de cada processo é evidenciado pelo deslocamento lateral de cada configuração. O OpenUP/Basic pode ser considerado uma configuração análoga à Light RUP Configuration da figura. A localização de uma configuração no mapa pode ajudar na sua adequação do PS frente às características e necessidades de um SI ou organização. Na próxima seção serão abordados alguns aspectos para a o balanceamento adequado da especificação de requisitos.
Abordagens "Suficientemente Boas" para Especificação e Modelagem de Requisitos e a Redocumentação
Frente aos problemas de domínios dinâmicos e requisitos voláteis, movimentos baseados em metodologias ágeis têm-se firmado nos últimos anos. De movimentos mais contundentes, como o Extreme Programming, onde o peso do processo foi preterido em favor da informalidade veio a necessidade de se estabelecer um maior balanço entre o peso do processo, a carga de produção dos subprodutos de um software (como documentação, de requisitos ou técnica) e a entrega do sistema em si [Rosenberg:2003, Kroll:2006].
Neste sentido um tema recorrente a literatura é o balanceamento entre a agilidade e a disciplina de um determinado método. Estas abordagens podem ser referidas como “suficientemente boas" (good enough) e têm como valor a adequação e dimensionamento das práticas do processo de software frente às características específicas do software em desenvolvimento.
Neste sentido, Davis[Davis:2005] afirma que o cronograma do projeto deve ser considerado um fator importante para a definição do tempo gasto em requisitos. Um fator que pode servir como contrapeso em relação ao cronograma é o risco, mudando assim o nível de formalismo necessário para o desenvolvimento do produto.
Ambler [Ambler:Primer:2004] propõe a metodologia Modelagem Ágil (Agile Modeling) com o objetivo de oferecer um guia para viabilização da modelagem de um sistema guiada por valores, princípios e práticas que susbsidiem o uso de modelos com pouco grau de cerimônia. Estas práticas contemplam a modelagem e especificação de requisitos na forma de modelagem de utilização, prototipação de interface do usuário e especificação de requisitos suplementares. Ambler compara sua abordagem sobre documentação a “viajar com pouco peso" (traveling light), onde modelos e documentos são criados de forma “suficientemente boa" para prosseguir o desenvolvimento.
O trabalho de Ambler é corroborado por [Rüping:2003], que afirma que pouca documentação, mas "suficiente", é mais acessível e portanto mais útil para uma equipe do que muita documentação. Rüping preconiza que o valor da documentação está associado à concisão e sua acessibilidade frente aos leitores e propõe que a utilidade da documentação, a partir de certa quantidade, tende a diminuir, como mostrado na figura abaixo. Um fator importante para manter a documentação útil é seu nível de abstração (princípio adotado tanto pelo OpenUP [Kroll:2006] como pelo método de gerência de [Bittner:2006]): detalhes tendem a mudar mais rapidamente que a documentação portanto são melhor comunicados informalmente.
Um fator que serve de “contrapeso" para a decisão sobre a forma de documentação em relação ao princípio traveling light são as informações necessárias para os esforços de manutenção do sistema[Larman:2003, Highsmith:2002]. Larman recomenda que a necessidade seja utilizada como critério para balanço ao invés de especular-se a respeito da documentação, assim uma equipe mantenedora pode tornar-se fonte de informações valiosas a respeito das necessidades de documentação.
O esforço despendido no balanço da documentação torna-se especialmente relevante no contexto de redocumentação[Yang:2003] de um produto de software num processo de Engenharia Reversa. Deve-se levar em conta que à medida do avanço na recuperação de artefatos de requisitos, o sistema legado está sendo submetido à mesma carga de requisições de mudanças característica do domínio dinâmico. Neste sentido a acurácia da documentação [Cockburn:2001] é um quesito imperativo.
Casos de Uso como Ponto de Partida para Modelagem e Especificação de Requisitos
O ponto de partida para o balanço dos requisitos tomado neste trabalho são os Casos de Uso. Apesar das críticas às limitaçõesde Casos de Uso como modelos efetivos para documentação dos requisitos de um sistema [Fortuna:2005, Wiegers:2006, Davis:2005], no contexto de sistemas legados onde a documentação, sobretudo a de requisitos, é precária.
A estratégia para início da reconstrução dos requisitos de um sistema nestas condições é valer-se do comportamento externo do sistema para a descrição do sistema. Assim, a perspectiva do usuário torna-se mais valiosa para a formação de um referencial comum entre a equipe mantenedora e o usuário formando a estrutura de ligação do projeto [Cockburn:2001]. A abordagem de cenários e a modelagem da utilização do sistema[Ambler:Primer:2004, Kroll:2006] têm sua importância aumentada uma vez que a documentação pertinente aos demais aspectos do software como design e requisitos funcionais pode encontrar-se completamente perdida[Souza:2005].
Apesar dos debates entre defensores de abordagens orientadas a objetivos e cenários[Fortuna:2005], alternativas para composição de objetivos, cenários e casos de uso podem ser encontrada com o emprego de abordagens de Cockburn e Ambler. Cockburn propões a estratificação do conjunto de casos de uso em níveis: sumário, objetivos e subfunções em um esquema de padrão de caso de uso chamado EverUnfoldingStory, ou desdobramento contínuo da história[Cockburn:2002]. Ambler utiliza a abordagem de Casos de Usos Essenciais onde estes têm por função capturar os objetivos do usuário e declará-los de forma mais suscinta que um caso de uso convencional, ou como Ambler chama “de Sistema"[Ambler:Primer:2004]. Em ambas a orientação para a estruturação dos cenários em torno de um objetivo de negócio maior é continuamente enfatizada.
Enriquecimento de Requisitos no Contexto de Redocumentação
A questão de balanço entre utilidade e tamanho da documentação recuperado pode ser atingida através da adoção dos Casos de Uso como estrutura de ligação do projeto [Cockburn:2001]. Para o posterior enriquecimento dinâmico dos requisitos recuperados via Casos de Uso mantendo a qualidade e utilidade da documentação pode-se observar do princípio “Múltiplos Modelos" da Modelagem Ágil[Ambler:Primer:2004] e o emprego do Padrão de Caso de Uso “Adornos" (Adornments) [Cockburn:2002].
Casos de Uso, a medida de sua evolução podem se tornar pesados, portanto menos úteis, caso sejam complementados com requisitos não-funcionais, assim o uso de requisitos suplementares torna-se relevante para manter o valor do Caso de Uso quanto a concisão e acesso. Um esquema do padrão Adornos de Cockburn pode ser visto na figura abaixo, onde pode-se observar a ligação entre especificações de interfaces de usuário, requisitos de performance, dicionário de dados, regras de negócio e restrições e o Caso de Uso.
Sistemas legados podem encontrar-se desenvolvidos em tecnologias ou paradigmas que são anteriores as propostas de métodos como a família do PU ou Modelagem Ágil. Neste cenário determinados modelos, como os propostos pela UML, podem não ser adequados para o esforço de documentação do sistema. Ambler faz um discernimento entre os conceitos de modelagem e modelagem visual, considerando importante também o emprego de modelos textuais e afirma que cada modelo tem um propósito específico daí a necessidade do princípio "Múltiplos Modelos": utilizar uma técnica adequada a cada situação. Sendo assim a estruturação dos modelos de requisitos para um projeto de manutenção torna-se uma atividade importante para adequação da estrutura de artefatos utilizada para recuperação dos requisitos.
Afora a importância da se utilização do modelo correto, ressalta-se a importância do uso de artefatos (podendo estes ser decorrentes de modelos) como registro do trabalho da equipe e como veículo de transmissão de conhecimento sobre o projeto[Bittner:2006]. Artefatos devem ser produzidos para mitigar riscos do projeto ou para satisfazer alguma abordagem de desenvolvimento, bem como o grau de formalismo demandado, de um quadro branco, como na Modelagem Ágil, como pelo uso de ferramentas de software específicas. Deve-se observar os riscos da produção de artefatos sem o devido entendimento do porquê este está sendo trabalhado. O uso de um artefato apenas por este ser definido no processo sem o entendimento de seu propósito pode levar a uma explosão de artefatos. O autor sugere o emprego de uma Matriz de Artefatos contendo os artefatos produzidos pelo projeto e seu uso em fases e iterações no PU.
Referências
[Ambler:Primer:2004] Scott Ambler. The Object Primer. Cambridge University Press, 3rd edition, 2004.
[Bittner:2006] Kurt Bittner and Ian Spence. Managing Iterative Software Development
Projects. Addison Wesley Professional, 2006.
[Cockburn:2001] Alistair Cockburn. Writing Effective Use Cases. Addison-Wesley, 2001.
[Cockburn:2002] Steve Adolph, Paul Bramble, Alistair Cockburn, and Andy Pols. Patterns for
Effective Use Cases. Addison-Wesley, 2002.
[Davis:2005] Alan M. Davis. Just Enough Requirements Management. Dorset House, 2005.
[Fortuna:2005] Michel Heluey Fortuna and Marcos R. S. Borges. Modelagem informacional
de requisitos. In WER, pages 269280, 2005.
[Highsmith:2002] Jim Highsmith. Agile software development ecosystems. Addison-Wesley
Longman Publishing Co., Inc., Boston, MA, USA, 2002.
[Kroll:2006] Per Kroll and Bruce MacIsaac. Agility and Discipline Made Easy: Practices
from OpenUP and RUP. Addison Wesley, 2006.
[Kruchen:1995] Philippe Kruchten. The 4+1 view model of architecture. IEEE Software,
12(6):42-50, 1995.
[Kruchten:2001] Philippe Kruchten. The Rational Uni ed Process An Introduction. Addison
Wesley, second edition edition, 2001.
[Kruchen:2003] Per Kroll and Philippe Kruchten. The Rational Uni ed Process Made Easy:
A Practitioner's Guide to the RUP. Addison Wesley, 2003.
[Larman:2003] Craig Larman. Agile and Iterative Development: A Manager's Guide. Addison
Wesley, 2003.
[Leffingwell:1999] Dean Le fingwell and Don Widrig. Managing Software Requirements - An
Uni ed Approach. Addison Wesley, 1999.
[Rosenberg:2003] Matt Stephens and Doug Rosenberg. Extreme Programming Refactored: The
Case Against XP. Apress, 2003.
[Rüping:2003] Andreas Rüping. Agile documentation : a pattern guide to producing
lightweight documents for software projects. John Wiley & Sons, 2003.
[Souza:2005] Souza, Nicolas Anquetil, and Kathia M. de Oliveira. A study of the
documentation essential to software maintenance. In SIGDOC '05: Proceedings
of the 23rd annual international conference on Design of communication ,
pages 68-75, New York, NY, USA, 2005. ACM Press.
[Wiegers:2003] Karl E. Wiegers. Software Requirements. Microsoft Press, 2nd edition, 2003.
[Wiegers:2006] Karl E. Wiegers. More About Software Requirements: Thorny Issues and
[Yang:2003] Hongji Yang and Martin Ward. Successful Evolution of Software Systems.
sexta-feira, 27 de fevereiro de 2009
Padrões de Gerência de Configuração com Subversion 1.5 - Parte I: Conceitos
Padrões são uma constante em Engenharia de Software há pelo menos 14 anos. Não digo nenhuma novidade agora ao afirmar que o trabalho seminal sobre padrões foi o GoF. E que este foi inspirado no trabalho do arquiteto Christopher Alexander na década de 70. Já faz parte do evangelho.
Talvez o que escape ao "senso comum" seja a explosão de patterns através das disciplinas da Engenharia de Software. Alguns exemplos são Análise, Implementação, Modelagem de Dados, Desenvolvimento de Aplicações Corporativas, Integração de Aplicações Corporativas, Arquitetura de Software, Requisitos, Casos de Uso, Modelagem de Negócio, e Documentação.
Quando me vi às voltas da gerência de configuração pela primeira vez, decidi adotar uma abordagem mais pragmática. Ao invés de me inteirar e cair de cabeça na disciplina de gerência de configuracão como um li lateralmente (skimming) alguns livros de SCM. Depois resolvi me guiar por dois livros específicos, primeiramente o livro de Padrões de Configuração Software Configuration Patterns e depois para implantação do Subversion como servidor SCM me guiei pelo livro Pragmatic Configuration Management with Subversion, 2nd. ed. Hoje as soluções implementadas de acordo com estes dois guias estão rodando com sucesso.
Pretendo escrever um arco de 3 posts. Aqui vou explorar Padrões de Gerência de Configuração. No segundo, pretendo escolher determinados cenários e mostrar quais são os patterns adequados para resolução dos problemas. Por fim mostrarei como implementá-los em um sistema de controle de versão, mais especificamente o Subversion 1.5.
Software Configuration Management - Gerência de Configuração de Software em uma Casca de Noz
Gerência de Configuração diz respeito à configuração, identificação, controle de configuração, prestação de contas, revisão, gerenciamento de build, gerenciamento de processo e trabalho em grupo. Estas práticas definem como uma organização contrói e lança produtos bem como identifica e rastreia mudanças.
Em termos mais simples SCM é a função de rastrear e controlar mudanças em um software. Podemos exemplificar o objetivo da SCM com a seguinte pergunta: "Alguém fez alguma coisa, como posso reproduzi-la?".
A SCM atende esta pergunta através do estabelecimento de práticas como, por exemplo, controle de revisões e baselines.
Controle de revisão trata do gerenciamento de múltiplas revisões de um determinado artefato, como documento ou arquivo de fonte. A intenção é fazer com que as mudanças em um determinado arquivo sob controle de versão (chamado de item de configuração) sejam armazenadas a medida que o usuário for atualizando o arquivo possibilitando a reprodução gradativa das mudanças.
Uma baseline é uma marcação que identifica um certo estado significativo dentro de um conjunto de mudanças realizadas em um histórico de revisões. Um estado significativo em desenvolvimento de software é a aprovação de um conjunto de revisões de um determinado grupo de itens de configuração.
Alguns conceitos importantes para a SCM são workspaces e codelines.
Uma workspace (não confundir com a workspace do IDE como o Eclipse) é um local, como um diretório na estação de trabalho, onde o desenvolvedor mantém todos artefatos necessários para a conclusão de uma tarefa. A workspace é uma cópia associada a uma versão específica dos artefatos.
Uma codeline é a progressão de um conjunto de arquivos referente às mudanças atribuídas ao software no decorrer do tempo. Cada mudança cria uma nova revisão de um determinado artefato.
Em um determinado ponto do tempo, uma codeline pode conter um conjunto de várias revisões de cada componente gerenciado como item de configuração.
Quando determinadas tarefas divergem do propósito original de uma codeline, pode haver a necessidade de se bifurcar um codeline produzindo duas concorrentes. Isto permite a evolução indepente de um determinado item de configuração. Esta operação é chamada de branch (ou ramificação, não sei como os teóricos traduzem nestes dias...). Uma mudança d
e propósito pode ser a aproximação da release 2 do software, enquanto o trabalho para a release 3 não pode ser retardado por questões de cronograma.
Supondo que a release foi efetuada, ocorre a necessidade de incorporar as mudanças da release 2.1 e 2.2 na release 3. Isto pode ser feito através de uma operação de merge (ou mescla) das modificações do branch da release 2 de volta à codeline principal do produto.
SCM Patterns
Padrões de Gerência de Configuração foram organizados originalmente por Stephen P. Berczuk e Brad Appleton no livro Software Configuration Management Patterns: Effective Teamwork, Practical Integration (também são catalogados no site SCM Patterns for Agility).
Patterns são boas soluções para problemas recorrentes dentro de um determinado contexto (no caso SCM). É uma espécie de reuso de idéias, a grosso modo, uma receita de bolo. Um pattern é o empacotamento de um conhecimento útil para a resolução de problemas num contexto.
Um pattern pode ser organizado dentro de um contexto mairo através de uma pattern language. Uma pattern language é a forma de disposição das soluções (isto é, os patterns individuais) em um contexto onde já há outras soluções implementadas.
Um pattern é especificado sob a forma de um template específico para o contexto de sua aplicação. Em SCM temos os seguintes componentes no template:
Classificação de SCM Patterns
Um SCM Pattern é classificado como um padrão de Codeline ou padrão de Workspace, indicando sua aplicabilidade mais adequada. No mapa da SCM Pattern Language podemos identificar o relacionamento dos Patterns em relação a outros para compor uma solução mais abrangente. Em destaque vermelho podemos ver os patterns referentes à codeline. Em verde, os patterns cabíveis ao contexto de workspace.
Segue uma breve descrição dos SCM Patterns e sua aplicabilidade por categoria.
Padrões de Codeline
Padrões de Workspace
Um cartão de referência dos SCM patterns pode ser encontrado (inclusive com o mapa da pattern language) aqui.
Conclusão
Aqui fiz uma breve revisão sobre alguns conceitos de SCM Patterns. Iniciei com alguns conceitos básicos sobre SCM e descorri sobre os padrões definidos pelo Appleton e pelo Berczuk. Estes padrões já apliquei com sucesso em dois grandes sistemas, um legado onde não havia política de gerência de configuração e outro grande conjunto de sistemas federados iniciado do zero. Em ambos os casos os padrões se demonstraram muito eficientes para atender tanto na manutenção de um sistema como no desenvolvimento de outro.
Requisitos: A Disciplina "Ágil" Esquecida II
Após um "breve" hiato de 5 meses, cá estou. Não gosto de falar sobre futurologia do passado principalmente no que se refere ao meu trabalho, mas estou continuando um post que estava em rascunho de 17/09/2008. Vou concluir este trabalho abaixo e depois tentar dar continuidade frente a alguns fatos novos ocorridos nas últimas semanas.
Segue o "original".
No contexto de Engenharia de Processos em Software acredito que estejamos vivendo em um movimento pendular entre níveis de formalismo e agilidade. De um lado temos o que foi confortavelmente rotulado de "tradicional" pela liderança da comunidade ágil (um mix dos estratagemas de Schopenhauer números 12 e 19), do outro lado temos tudo que é bom, belo, justo e providencial regido sob os auspícios do manifesto ágil.
Qual o problema? O problema é justamente o seguinte: praticamente tudo o que é passível de adoção pela comunidade ágil é uma aceitação a priori da verdade de temas sem que uma avaliação crítica honesta seja feita por seus membros. Estes temas (ou variações menores sobre o mesmo tema) são propagados como rastilho de pólvora e aceitos (take for granted) sem contestação. Na velocidade do blogosfera é praticamente impossível avaliar criteriosamente o que blogueiros postam, fazendo com que o valor potencial da informação de fontes primárias seja prejudicado.
Um exemplo do prejuízo causado pela falta de contextualização histórica e análise crítica é justamente a presunção de achar que todos os benefícios do desenvolvimento de sistemas moderno é derivado das práticas ágeis. Trocando em miúdos, o mundo começou com o manifesto ágil, com o Scrum e com o XP.
Várias práticas efetivas dos "métodos ágeis" não foram uma invenção originária dos luminares dos métodos ágeis. Bem da verdade várias práticas "ágeis" já eram adotadas até dez anos (ou mais) antes do manifesto ágil (olhem McConnell). As práticas se tornaram cool apenas pelo rebranding.
Neste cenário quem é diretamente prejudicado? Esta é a deixa do nosso desenvolvedor Joe Six-pack. O Joe é um cara ocupado. Entrou para informática para desenvolver jogos, mas acabou se tornando um programador comercial.
Joe trabalha numa empresa onde a TI está em sua adolescência ainda. A TI não trabalha mais com sistemas meio e sim na própria atividade fim da empresa. A atividade fim, ao contrário de uma folha de pagamento ou sistema de manutenção, deve se adaptar ao mercado. Se os sistemas não se adaptam, a empresa simplesmente é engolida pelo mercado.
Com o peso de sistemas "fim" sob seus ombros, Joe não tem benefício da reflexão devido às pressões do ambiente. Joe tem que entregar. Joe já tentou uma série de metodologias para tentar se adaptar melhor ao ambiente, mas falhou em todas, por diversas razões: falta de buy-in da gerência, falta de priorização da diretoria e, principalmente, a falta de um plano de melhoria contínua, o que na administração é chamado de PDCA.
Joe, já desistindo completamente do processo de software (afinal o que não tem solução, solucionado está) houve falar de uma nova tendência de mercado, um tal de movimento ágil. Nele simplificamos as coisas (afinal é o que os blogueiros dizem) : não desenvolvemos documentação, aliás podemos até queimar a documentação, afinal o usuário sempre estará por perto para dar uma dica; não nos preocupamos em refletir sobre o que construir, afinal tudo muda tão rápido que é mais fácil construir primeiro e perguntar para o usuário depois, afinal já temos um lembrete na parede sobre o que devemos construir, qualquer dúvida, o usuário está lá.
A maior baixa neste fogo cruzado foi justamente a Engenharia de Requisitos, alvo do atrelamento infundado de grandes mitificações. Requisitos não são software em funcionamento, requisitos são um calhamaço de documentos do Word que podem ser jogados fora assim que o software estiver rodando, afinal para que requisitos escritos enquanto testes de software são "requisitos vivos".
Finalmente Joe achou alguma coisa valiosa. Tentou gerenciar a complexidade de desenvolvimento com processos prescritivos e não conseguiu, agora está mais tranquilo. Afinal ele já sabe nada o que foi feito antes chegou a funcionar algum dia.
Voltei
É claro que isto é apenas uma alegoria. Super simplificação? Com certeza, não tenho aspirações a fazer uma tese neste blog. Muito menos tenho a pretensão de expor A VERDADE em poucas linhas.
Agora retomo o assunto nos próximos posts.
Assinar:
Postagens (Atom)
