Olá pessoal!
Neste post e nos seguintes veremos um apanhado geral sobre o e-book gratuito .NET Technology Guide for Business Applications , escrito por Cesar de La Torre e David Carmona. Como seu próprio nome já anuncia, nele é apresentado um guia de tecnologias .Net para a criação de aplicações de negócios. O seu conteúdo discorre basicamente sobre o diagrama abaixo, onde a pilha mais atual de tecnologias para desenvolvimento e infraestrutura Microsoft é apresentada.
Olá pessoal!
Quantas vezes nos deparamos com as frustrantes situações em que uma determinada solução tecnológica, aderente aos padrões corporativos e que melhor atende aos requisitos não-funcionais estabelecidos, não pode ser aplicada em um projeto, seja por não haver tempo hábil, por exemplo, levando a adoção de abordagens que nem sempre trazem bons resultados a longo prazo?
Neste post gostaria de compartilhar um trecho de um podcast publicado pelo Oracle Technology Network, em seu canal ArchBeat Pod Cast, onde Thomas Erl – best selling SOA author, explica como tais situações normalmente se originam. Segundo Thomas, existe o que ele chama de miopia na perspectiva considerada na avaliação dos resultados de projetos, onde acaba-se sendo considerado apenas prazo, orçamento e atendimento dos requisitos funcionais como critérios que definem se um projeto foi ou não bem-sucedido, deixando de lado a qualidade da arquitetura implantada, o que acaba resultando em defasagem tecnológica, projetos que geram silos de informação e aplicações que atendem apenas a um propósito, consequentemente aumentando o custo de propriedade do produto produzido pelo projeto. Confira abaixo.
“… the criteria organizations use to evaluate project team performance, I think there still a lot of tactical emphasis on determining what was and what was not a successful project and by that I mean did it come under budget, did it come on time, did it meet functional requirements and those tend to be focal points when projects are assessed and it is easy to lose sight of the importance of what you are designing and the long term implications of what you are building when you are focusing more on the timeline, the budget and meeting the functional requirements within the primitives of that budget and timeline. And it is easier to meet those goals as you are being assessed by bypassing proper technology architecture and just getting developers to build something that works as per the immediate functional requirements and if you as a project manager are not being assessed based on the quality of the technology architecture, its compatibility with the surrounding IT enterprise architecture, its compliance to predefined standards, then there is no means of assessing that or regulating that, then there is no motivation to really emphasize that or make that part of the project cycle, because it will just use up more time and resources and will go against the other points which you are being evaluated. So I think that assessment from a strategic perspective is also lacking in some IT environments and that is to their detriment in the long term, because it is not part of how they assess project, applications, delivery projects, then those projects do became very much silo based, single purpose and then, consequently, impact the subsequent governance and ownership burden that IT enterprise assumes and it is that shortsightedness that I think also leads to situations like that where IT architects are not given the level of responsibility that they should.”
A não mudança de tal cultura leva a geração de conflitos constantes entre os times de projetos e os times de arquitetura, pelos seus diferentes interesses. A convivência em projetos com tais conflitos acaba não sendo saudável para nenhum dos envolvidos, nem tão pouco para o próprio projeto. Decisões de design que deveriam ser facilmente tomadas precisam ser escaladas para a gestão, o que acaba gerando ainda mais desgaste – quando não há politicagem – atrasos e posterior pressa para implementar o design decidido.
E por esta razão, acredito que organizações hoje tenham chegado a um nível de maturidade onde já enxergam a necessidade e os benefícios da adoção das disciplinas de arquitetura, porém, ainda precisam evoluir para um próximo nível, onde estarão aptas a de fato empregar eficientemente tais áreas em seus projetos.
Olá pessoal!
Neste artigo gostaria de compartilhar um trecho do livro “The Clean Coder”, de Robert C. Martin (Uncle Bob), que trata de ética e conduta profissional para nós, profissionais de desenvolvimento de software. O trecho aborda dois tópicos de extrema relevância. O primeiro é sobre decisões políticas ou baseadas apenas em questões financeiras de curto prazo e o segundo é sobre a responsabilidade que um profissional de software responsável por decisões técnicas (seja um arquiteto de software ou qualquer outro papel correspondente) tem ao assumir tal papel.
Em um projeto, diferentes stakeholders demandam diferentes requisitos não-funcionais, muitas vezes conflitantes entre si. Gerentes de projetos, por exemplo, em geral priorizam o prazo estabelecido com as áreas de negócios (time-to-market). Áreas que manterão o sistema (que aplicação mudanças evolutivas / corretivas, por exemplo), demandam um sistema que seja modificável (modifiability). Um sistema projetado para ser modificável, em geral, leva mais tempo para ser construído. E esta aí o primeiro e mais comum conflito. A figura mais abaixo (extraída de materiais do Software Engineering Institute – SEI) representa este cenário.
Neste contexto, se por um lado um gestor tem a responsabilidade de não tomar decisões baseadas apenas em questões políticas e financeiras de curto prazo, um arquiteto de software tem o dever, a responsabilidade, de apontar de todas as formas possíveis, os possíveis riscos que uma determinada decisão de projeto (seja de design, por exemplo) pode apresentar.
A história descrita por Bob Martin fala de uma decisão política / financeira, tomada em um lançamento de uma nave aeroespacial, que não levou em consideração os riscos levantados pelos engenheiros responsáveis, culminando na perda de sete vidas. Veja a seguir.
At 11:39 AM EST on January 28, 1986, just 73.124 seconds after launch and at an altitude of 48,000 feet, the Space Shuttle Challenger was torn to smithereens by the failure of the right-hand solid rock booster (SRB). Seven brave astronauts, including high school teacher Christa McAuliffe, were lost. The expression on the face of McAuliffe’s mother as she watched the demise of her daughter nice miles overhead haunts me to this day.
The Challenger broke up because of hot exhaust gasses in the failing SRB leaked out from between the segments of its hull, splashing across the body of the external fuel tank.
… The engineers at Morton Thiokol who designed the SRB had known that there were problems with the O-rings [SRB component that was identified as the cause of the incident], and they had reported those problems to managers at Morton Thiokol and NASA seven years earlier.
… The engineers had designed a repair for the problem, but implementation of that repair had been long delayed.
… In short, the engineers knew that the risk was too high. The engineers acted on that knowledge. They wrote memos raising giant red flags. They strongly urged Thiokol and NASA managers not to launch. In an eleventh-hour meeting held just hours before the launch, those engineers presented their best data. They raged, and cajoled, and protested. But in the end, the managers ignored them.
… Despite all the protest and memos, and urgings of the engineers, the managers believed they knew better. They thought the engineers were overreacting. They didn’t trust the engineers’ data or their conclusions. They launched because they were under immense financial and political pressure. They hoped everything would be just fine.
These managers were not merely foolish, they were criminal. … They made a decision they had no right to make. They usurped the authority of people who actually knew: the engineers.
But what about the engineers? Certainly the engineers did what they were supposed to do. They informed their managers and fought hard for their position. They went through the appropriate channels and invoked all the right protocols. They did what they could, within the system – and still the managers overrode them.
E por fim, Bob Martin conclui: ”… As an engineer, you have a depth of knowledge about your systems and projects that no managers can possibly have. With that knowledge comes the responsibility to act.”
É claro que como arquitetos de software muito dificilmente estaremos envolvidos em decisões que poderão implicar em vida ou morte de pessoas. Porém, é certo que determinadas decisões mal tomadas implicarão, a médio/longo prazo, em custos de manutenção e de propriedade mais altos, tempos de entrega mais longos (time-to-market) e em requisitos não atendidos. Quando tais problemas perduram, toda uma área de TI passa a ser mais um custo necessário, ao invés de uma área estratégica para o crescimento da companhia.
Olá pessoal!
O título deste post pode ser interpretado sob duas perspectivas. Uma possível interpretação é “O que um arquiteto faz em seu dia-a-dia?”. Outra poderia ser “O que forma um arquiteto?”. Ambas as interpretações estão corretas e a resposta para ambas as questões é a mesma: Quality Attributes. Continue lendo e entenda o motivo.
Neste post inicio uma série em que abordarei um assunto de extrema importância dentro de arquitetura de software: atributos de qualidade. Sob este nome o tema pode parecer um pouco obscuro, porém, pode se tornar familiar sob outra definição: requisitos não-funcionais.
O conteúdo deste e dos demais posts desta série é baseado principalmente no livro Software Architecture in Practice – Second Edition, já mencionado em posts anteriores, no conteúdo do curso Software Architecture Principles and Practices, ministrado pelo Software Engeneering Institute (SEI), sendo complementado por outros materiais.
O que são atributos de qualidade?
É possível dizer que atributos de qualidade são considerados em praticamente todos os esforços de desenvolvimento de sistemas. Muito provavelmente você (e eu também) considera atributos de qualidade em suas demandas de forma inconsciente. E para provar esta teoria, um exemplo de um sistema que não leva em consideração atributos de qualidade, seria um sistema estruturado de forma monolítica, sem nenhuma estrutura de organização interna. Quantas vezes você considerou esta abordagem nos sistemas que projetou?
Desta forma, percebemos que um sistema não tem como requisito apenas funcionalidades que deve prover (requisitos funcionais). Time-to-market (um atributo de qualidade voltado ao negócio) e modificabilidade são frequentemente atributos de qualidade (ou requisitos não funcionais) que levam a estruturação de um sistema em módulos, de forma que ele possa ser construído em paralelo por mais de uma pessoa (time-to-market), ao mesmo tempo atribuindo responsabilidades de forma coerente (low coupling e high coesion), o que possibilita maior facilidade em modificações futuras (modificabilidade). Estes, portanto, são os motivos que nos levam a não projetar um sistema monolítico: atributos de qualidade.
O mesmo vale quando falamos da opção pela utilização de um padrão MVC, por exemplo. Essa escolha tem (ou pelo menos deveria ter) como motivação não apenas o fato de se estar seguindo uma tendência recente. O padrão MVC possibilita a que um sistema tenha atributos de qualidade como modificabilidade, já que é estruturado em camadas com responsabilidades bem definidas (separation of concerns), permitindo, por exemplo, que alterações no design da aplicação (tela) não necessariamente afetem a lógica de programação, e vice-versa. Testabilidade é outro atributo de qualidade decorrente da utilização deste padrão, já que possibilita a execução de testes unitários na camada de apresentação, por exemplo. Ambos, modificabilidade e testabilidade, trazem como beneficio para o negócio atributos como um baixo time-to-market, já que manutenções evolutivas serão implementadas mais rapidamente, e maior disponibilidade (availability), já que a aplicação de testes unitários tende a reduzir o número de bugs de um sistema, tornando-o mais estável (disponível) para o usuário final.
Podemos entender então que atributos de qualidade são requisitos não-funcionais, ou seja, que não dizem respeito ao que o sistema deve prover em termos de funcionalidade, mas sim, em termos de qualidade. Existem diversas categorias de atributos de qualidade e diversos assuntos relacionados. Availability, modifyability, performance, security, testabiliy, usability, scalability, extensibility, reliability, são exemplos de atributos de qualidade. Existem também alguns conceitos mais difundidos que levam em consideração um subconjunto de atributos de qualidade específicos. Por exemplo:
· FURPS: functionality, usability, reliability, performance, supportability;
· ACID: atomicity, consistency, isolation, durability;
· ISO/IEC 9126: functionality, reliability, usability, efficiency, maintainability;
Por que atributos de qualidade são importantes?
No livro Software Architecture in Practice – Second Edition, é dado um exelente exemplo da importância dos atributos de qualidade:
“Sistemas são frequentemente substituídos ou redesenhados não porque suas funcionalidades são deficientes – as substituições geralmente são idênticas em termos de funcionalidades – mas porque eles são difíceis de manter, portar, escalar, ou porque são muito lentos, ou porque foram comprometidos por hackers” (minha tradução).
E apesar de tal importância, muito frequentemente apenas as funcionalidades são observadas em um ciclo de desenvolvimento de software. Especificações comumente não tratam de atributos de qualidade de forma satisfatória, apesar do fato de que tal detalhamento ser de total interesse dos representantes de negócios de uma organização (veja imagem ao lado – provida pelo SEI). E é ai que o papel do arquiteto torna-se importante dentro de um projeto. É do arquiteto a responsabilidade de delinear os atributos de qualidade de um sistema, caso eles não estejam especificados, de entendê-los, especificá-los segundo o conceito SMART e, posteriormente, de endereça-los através de praticas e padrões arquiteturais (veremos este assunto em detalhes mais adiante).
Por enquanto ficaremos por aqui. Nos próximos posts veremos como analisar, registrar e endereçar atributos de qualidade através de táticas arquiteturais. Depois, partiremos para questões especificas de alguns atributos de qualidade mais relevantes, como por exemplo, availability, performance, security, modifiability e testability. Até lá!
Olá pessoal!
Neste post gostaria de compartilhar um resumo do conteúdo de um podcast que ouvi recentemente, cujo tema principal era justamente o título deste post: “Who gets to be a software architect”. Acredito que o assunto seja bastante relevante, pois tem sido tema de diversas discussões em diversas comunidades, demonstrando que ainda há pouca maturidade e falta de consenso no mercado.
O podcast foi disponibilizado pelo Oracle Technology Network, no canal ArchBeat, que trata de assuntos relacionados à arquitetura. Para quem ainda não conhece, vale a pena conferir. O canal aborda assuntos diversos relacionados à arquitetura, tecnologias e tendências, como SOA, Cloud Computing, Governança, Enterprise Architecture, Business Architecture, etc.
O podcast consistiu em uma panel discussion, composta por quatro participantes de peso, além do Bob Rhubart, host dos podcasts deste canal. São eles:
A seguir consta o link para mais detalhes do podcast, onde também pode ser baixado o áudio: https://blogs.oracle.com/archbeat/entry/show_notes_who_gets_to_be_a_so.
Separei o conteúdo da discussão em alguns temas, que podem ser conferidos a seguir. Procurei manter o conteúdo fiel ao que foi discutido no podcast, sem incluir opiniões pessoais e sem alterar o sentido ou opinião dos participantes.
O que separa o papel de um desenvolvedor do papel de um arquiteto
Arquitetos caminham na direção de uma liderança técnica, enquanto desenvolvedores estão mais focados em tarefas de codificação. Arquitetos produzem especificações técnicas, diagramas arquiteturais, mas não focam em bits e bytes o tempo todo. O arquiteto estrutura o que deve ser construído. Ao mesmo tempo, arquitetos devem saber programar seu design. Os melhores arquitetos iniciaram sua carreira como desenvolvedores e posteriormente assumiram novas responsabilidades gradualmente.
O fato de estar longe da codificação não exime do arquiteto a responsabilidade de se manter atualizado, contribuindo para o desenvolvimento, o que aumenta sua credibilidade perante o time.
Alguns soft skills diferenciam arquitetos de desenvolvedores. Arquitetos devem saber influenciar, devem ter visão, liderança, devem saber trabalhar com times diversos, comunicar decisões arquiteturais / design.
“The developers are the ones who build skyscrapers, while the architect is someone who designs the city, while enterprise architects are the city planners.“
Diferentes papeis dentro do tema “Arquitetura”
Alguns exemplos de diferentes papeis dentro do tema arquitetura foram citados, demonstrando que ao contrário do que comumente é entendido, não existe apenas o papel do Arquiteto de Aplicações / Sistemas:
O título de “Arquiteto” deve ser reservado para aqueles que possuem certificações?
Em geral, certificações mais técnicas focam em um produto ou framework especifico. Neste sentido, um profissional certificado será um excelente profissional para implementação de uma solução e-business, ou para identificar um determinado problema em uma base de dados ou aplicação java. Tais habilidades são extremamente valiosas para desenvolvedores / implementadores de solução, que em geral, procuram certificações para se distinguirem ou se destacarem.
Existem também organizações e certificações voltadas para as diversas segmentações dentro de arquitetura (infrastructure, information, business) e também voltadas à arquitetura corporativa (Enterprise Architecture). O IASA – International Association for Software Architects é uma organização que provê um mapa de carreira com cursos voltados para arquitetos e certificações relacionadas – veja imagem ao lado. O SEI – Software Engineering Institute também provê excelentes materiais e cursos relacionados à arquitetura de software. A Oracle também possui uma certificação voltada a Enterprise Architecture, chamada Oracle Enterprise Architecture Designation, além do Open Group, com o TOGAF.
Para arquitetos, além da competência técnica, habilidades de comunicação são cruciais. Normalmente, um arquiteto deverá passar sua visão para CIO, CTO, CEO, fornecedores, desenvolvedores, etc. Neste sentido, uma certificação não garante que o arquiteto seja competente o suficiente para realizar seu trabalho, já que é muito difícil certificar habilidades comunicacionais. Em geral, o que é levado em consideração na contratação de um arquiteto são suas experiências anteriores bem-sucedidas.
“The person (arquiteto) should have the ability to transcend one technology to the concept.”
Excelentes desenvolvedores podem se tornar arquitetos?
Se você é um excelente vendedor, não significa que você se tornará um excelente gerente de vendas. O mesmo vale para desenvolvedores e arquitetos. Algumas pessoas possuem profundos conhecimentos em bancos de dados, conhecem todas os truques para que o banco de dados ou o java faça exatamtente o que querem, e a forma mais rápida para resolver um problema em um sistema existente. Outras pessoas se dão muito bem quando trabalham em cima de requisitos difusos ou não claros.
É uma questão de mudança de ferramentas. Enquanto que para o desenvolvedor a principal ferramenta de comunicação é o teclado, para o arquiteto sua principal ferramenta deve ser o quadro branco e apresentações power point. Alguns desenvolvedores não gostam de se expor e não há nada de errado nisso. O mais importante é estar fazendo aquilo que se sente bem.
A discussão encerrou com o tema “hot-button issues” (más práticas), comummente cometidas por arquitetos.
Olá Pessoal!
Neste post gostaria de compartilhar um trecho do livro “The Rational Unified Process: An Introduction (3rd Edition)” de Philippe Kruchten, disponível no capítulo 5 (An Architecture-Centric Process), página 84. O texto fala sobre uma definição de Arquitetura, que é um tema bastante pertinente, diante das várias abordagens e interpretações existentes no mercado para o escopo de atuação de uma área de arquitetura ou de um arquiteto.
Basicamente o texto fala que arquitetura presa pela estrutura de um sistema, sua decomposição em elementos, subsistemas e suas interfaces, juntamente com comportamento e colaboração entre elementos. Requisitos não funcionais (ou atributos de qualidade) também fazem parte da lista de itens que a arquitetura de um sistema deve contemplar, como por exemplo, performance, reuso, escalabilidade, resiliência, etc. Outro ponto importante mencionado é que arquitetura engloba não apenas aspectos técnicos, mas também econômicos e sociológicos. Podemos entender como aspectos econômicos os recursos e limite de orçamento disponível em um projeto. Por sociológicos, as pessoas envolvidas e como a arquitetura do sistema pode os afetar, sejam eles desenvolvedores, designers, gerentes de projetos, ou mesmo usuários.
Confira o trecho a seguir.
Many definitions of architecture have been proposed. The Rational Unified Process defines architecture as follows.
Architecture encompasses significant decisions about the following:
- The organization of a software system
- The selection of structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaboration among these elements
- The composition of these elements into progressively larger subsystems
- The architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition
Software architecture is concerned with not only structure and behavior but also context: usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and trade-offs, and aesthetics.
This definition is long, but it attempts to capture the richness, the complexity, and the multiple dimensions of the concept. We can elaborate on some of the points.
Architecture is part of design: it is about making decisions about how the system will be built. But it is not all of the design. It stops at the major elements—the elements that have a pervasive and long-lasting effect on the qualities of the system, namely, its evolvability and its performance.
Architecture is about structure and about organization, but it is not limited to structure. It also deals with behavior: what happens at the joints, at the seams, and across the interfaces.
Architecture not only looks inward but also looks at the “fit” of the system in two contexts: the operational context (its end users) and the development context (the organization that develops the system). And it encompasses not only a system’s technical aspects but also its economic and sociological aspects.
Architecture also addresses “soft” issues such as style and aesthetics. Can an architecture be pleasing? Yes, to the educated eye it can be. Issues of aesthetics have their place in making a design uniform, easy to understand, and easy to evolve, with minimal surprises for the designers.
Olá pessoal!
Neste post vou falar sobre mais um tópico bastante interessante do livro Software Architecture in Practice – Second Edition, já citado em um post anterior. Desta vez o tema é “o que faz uma boa arquitetura”. Segundo o livro, diferentes arquitetos em diferentes organizações projetam diferentes arquiteturas, de forma que seja complicado definir qual é a mais correta. A ideia geral do tópico é que a arquitetura mais apropriada é aquela que melhor atende aos propósitos definidos para o sistema, sendo que não há uma fórmula única. Diferentes tipos de arquiteturas atendem a diferentes tipos de demandas. Uma arquitetura distribuída, baseada em estrutura client-server pode ser adequada para uma companhia de grande porte do setor financeiro, porém, a mesma solução pode ser completamente inapropriada para uma aplicação voltada à aviação, ou a um compilador, ou ainda a um jogo de vídeo game. E como não há uma fórmula, o tópico estabelece algumas “regras de ouro”, que podem ser usadas em todos os tipos de demandas. As recomendações são classificadas em relacionadas ao processo e ao produto (ou estrutural). Vejamos a seguir:
Recomendações relacionadas ao processo
Recomendações relacionadas ao produto / estrutura
A maioria destas recomendações são seguidas de forma intuitiva, ou mesmo são embasadas por diferentes estudos ou experiências que levam a estas conclusões. É interessante ter esta consolidação de boas práticas para utilizá-las como um guia a ser lembrado em cada novo projeto de arquitetura. Nos próximos posts devo falar mais sobre assuntos específicos tratados de forma incipiente neste. Até lá.
Olá pessoal!
Neste post finalizo uma pequena série de três posts sobre os processos de desenvolvimento de software mais populares da atualidade: o RUP e o Scrum. Caso você não tenha lido os dois posts anteriores, recomendo que o faça: RUP / Scrum. Neste post registro minha opinião / sentimento pessoal quanto a tais processos e como enxergo as discussões que têm surgido atualmente no mercado e na comunidade de desenvolvimento de software. Ressalto então que o está descrito excepcionalmente neste post não foi embasado por nenhuma literatura ou trabalho científico, tratando-se, portanto, de uma análise empírica pessoal. Com este post gostaria de abrir uma discussão, convidando-o a opinar sobre o assunto, postando seu comentário.
É fato que não é tarefa simples suportar um processo demorado por conta de levantamentos de negócios, seguido por um levantamento de requisitos e produção de documentações ostensivas. Com as cobranças constantes por entregas mais rápidas, os clientes vêm maior valor no produto entregue do que em um escopo bem fechado e documentado. Muitos profissionais de TI também não enxergam este valor ou deixam de enxergar com o passar do tempo, quando percebem que manter toda uma documentação produzida não é trivial ou mesmo quando são cobrados frequentemente por fins sem necessariamente justificar os meios. Além disso, existem também outros problemas que são enfrentados na maioria dos projetos, como por exemplo, a não aderência do produto entregue às reais necessidades do usuário, frequentes mudanças de escopo no decorrer do desenvolvimento, demora na entrega dos primeiros resultados e/ ou atraso na entrega do produto completo, o que taxa a área de TI como uma área muito demorada.
Eis que surge então a resposta para todos os problemas. Um processo que não define nenhuma documentação e/ou passo de modelagem e que vem a endossar esta prática que antes era apenas uma ideia ou fruto das pressões mencionadas. Um processo que privilegia os produtos entregues ante as documentações ostensivas, que proporciona entrega de resultados rápidos para o cliente, que não impõe a existência de muitos papéis específicos, sendo desta forma facilmente incorporado por qualquer time de desenvolvimento. Eis que surge o Scrum.
Diversas consultorias surgem então para explorar este que é vendido como a bala de prata, a bola da vez. Outras consultorias que vendiam outros tipos de treinamento passam a se adaptar à nova onda, para não perder market share. Completando o cenário, diversos Scrum Masters se formam e passam a influenciar comunidades, que passam a levar as ideias ágeis para suas empresas, como solução para seus problemas. Não que isso seja privilégio do Scrum. Acredito que o mesmo tenha acontecido com o RUP anteriormente e com diversas outras siglas e acrônimos que vão e vem no nosso mercado o tempo todo. Com toda essa catequização, o RUP passa a se consolidar então como um processo burocrático, antiquado, e que não atende às expectativas dos clientes.
O que não é lembrado por muitos, no entanto, é que o RUP também é um processo iterativo e incremental assim como o Scrum, de forma que com ele também é possível fazer entregas rápidas, coletando feedbacks logo no inicio do projeto, assim mitigando os riscos antecipadamente. Nada impede também que o RUP seja customizado para cada realidade. Existe, por exemplo, o RUP for small projects, que traz um apanhado mais enxuto com relação à sua versão original. Outra possibilidade ainda é criação do seu próprio processo, selecionando um conjunto de artefatos, papéis e conceitos do RUP que façam sentido para a sua organização.
Já outro ponto nas metodologias ágeis que muitas vezes é mal interpretado é quanto à ausência de especificações e/ou documentações. O manifesto ágil não diz que nenhuma documentação ou especificação deve ser feita. Ele diz apenas que o software funcionando é mais prioritário do que uma documentação abrangente. No livro “Utilizando UML e Padrões”, Craig Larman fala sobre uma abordagem de modelagem que ele chama de “modelagem ágil e desenho leve UML”. Nesta abordagem os diagramas UML são desenhados para proporcionar entendimento e comunicação ao invés de documentação. Além disso, os diagramas são feitos em quadros brancos ou folhas de aderência, de forma que eles sejam posteriormente digitalizados através de fotos e programas específicos.
Pessoalmente acredito que um levantamento inicial de requisitos e que diagramas de casos de uso ajudam bastante no entendimento e na concepção inicial de um projeto, bem como na visualização do seu tamanho e escopo. Além disso, diversos diagramas da UML também agregam com visões que são importantes para a maioria dos projetos, como por exemplo, as dependências entre componentes, a modularidade e separação de responsabilidades, demostradas pelo diagrama de componentes e a distribuição dos mesmos dentre os diversos nodes de uma arquitetura distribuída, demonstrada por um diagrama de implantação.
Qual é então o processo mais adequado para cada organização? Acredito que ambos os processos e suas variantes ou customizações podem atender às necessidades de diferentes tipos de organizações, dependendo da sua cultura, necessidade e porte. Empresas que optam pelo RUP, por sua customização ou por um processo baseado nele, normalmente possuem cultura séria / rígida, onde constantes auditorias exigem documentos e práticas registradas, possuindo também uma estrutura de profissionais robusta. Já as organizações que possuem cultura descontraída e que optam ou que só podem ter times pequenos que atendam responsabilidades específicas, normalmente melhor se adaptam ao Scrum e aos demais processos e conceitos ágeis.
E você, o que acha? A sua empresa adota um destes processos de forma satisfatória?
Olá pessoal!
Continuando a série rápida sobre engenharia de software, neste post falo um pouco sobre o Scrum. O objetivo desta série, como mencionado no post anterior, é traçar um paralelo entre os processos de desenvolvimento de sistemas mais populares: RUP e o Scrum. Caso você não tenha lido o post anterior, onde falei sobre o RUP, clique aqui.
Assim como o RUP, o Scrum também é um processo de desenvolvimento de sistemas iterativo e incremental, porém, é voltado ao que se chama de desenvolvimento ágil de software, que por sua vez é fundamentado pelo manifesto ágil. O manifesto ágil foi concebido por dezessete pessoas de extrema influência na área de engenharia de software, sendo que dentre eles destacam-se: Martin Fowler, Alistair Cockburne Kent Beck. Quatro valores fundamentais formam a base do manifesto ágil:
Percebe-se então uma grande diferença entre os valores que formam a base do RUP e os do Scrum, sendo que uma das principais é o fato de que as documentações permeiam o RUP de ponta a ponta enquanto que no Scrum, em sua essência, pouca ou nenhuma documentação é produzida. Além disso, outra grande diferença, como bem lembrado pelo colega Alessandro Brito em uma discussão, é que o Scrum não define o que fazer em cada situação, o que o classifica como um processo não prescribente.
Vamos então a alguns detalhes. No Scrum, todo o conjunto de requisitos do usuário é conhecido como Product Backlog. Nele há a introdução do conceito de Sprint, que se refere a uma iteração de implementação completa de um ou mais itens do Product Backlog, que são entregues e validados pelo cliente ao seu término. O conjunto de itens selecionados para implementação em uma sprint é denominado Sprint Backlog. As sprints normalmente têm duração de duas a quatro semanas, de forma que o cliente tenha contato com as primeiras funcionalidades do sistema logo no inicio do seu desenvolvimento – o que é bem característico de processos iterativos e incrementais, assim como o RUP. Veja na figura a seguir a ilustração do processo descrito.
No Scrum também é empregado o que se chama de Daily Mettings, onde todos os participantes do time de desenvolvimento do projeto participam de uma breve reunião, apontando os seus progressos e/ou seus impeditivos, de forma que os riscos possam ser mitigados logo no momento em que surgem. Além disso, são também realizadas reuniões de planejamento das próximas sprints e de retrospectivas das sprints finalizadas, onde são verificadas as lições aprendidas, de forma que eventuais problemas não se repitam ao longo do projeto.
Situados ambos os processos, surgem algumas questões, como por exemplo: qual processo é mais adequado para a minha empresa ou para o meu time de desenvolvimento e quais são as tendências atuais? Estas são questões que abordarei no próximo post, onde finalizarei esta pequena série. Até lá!
Olá pessoal!
Neste série rápida relacionada à engenharia de software vou descrever brevemente dois processos de desenvolvimento de software. Um é o RUP (que vem perdendo espaço para as novas tendências “ágeis”) e o outro é a bola da vez, o Scrum. Ao término, devo traçar uma conclusão com relação aos dois processos e às atuais tendências.
Neste post em específico começarei pelo RUP. O RUP é um processo de desenvolvimento de software concebido inicialmente por uma organização denominada Rational (que utilizou como base um processo anterior denominado UP – Unified Process) e adquirido posteriormente pela IBM, tendo seu nome alterado para IRUP (IBM Rational Unified Process).
O processo consiste em uma abordagem iterativa e incremental, onde são definidas entregas sucessivas ao longo da execução do projeto. Tal modelo se opõe a abordagem tradicional cascata (waterfall), onde a entrega ocorre apenas ao término do projeto. Seis melhores práticas formam a base deste processo:
Dentre diversas definições, o estabelecimento de papéis (funções) e artefatos (itens que são produzidos ao longo do projeto) fazem parte do RUP, definindo claramente, desta forma, as atribuições em um time e os itens que são entregues por ele. O RUP propõe uma abordagem com quatro fases e nove disciplinas, conforme pode ser observado na figura a seguir (conhecida popularmente como “Gráfico das Baleias”).
Como benefícios de uma abordagem iterativa e incremental espera-se:
– Redução de custos com retrabalho e aumento da aderência do produto entregue às necessidades do usuário: À medida que pequenas partes do produto são entregues, o cliente tem a oportunidade de avaliar e fornecer um feedback à equipe de desenvolvimento, de forma que o produto final seja mais aderente aos seus requisitos.
– Aceleração do tempo de desenvolvimento do projeto como um todo: devido ao fato de que a equipe trabalha de forma mais eficiente quando se busca resultados de escopo pequeno e claro.
O RUP é comumente utilizado em grandes organizações, pois, em sua forma original (sem customizações), implica na produção de diversas documentações – o que o faz levar a fama de “burocrático” – e na existência de conhecimentos específicos (atribuições de alguns papeis) que nem sempre são viáveis em organizações menores. Para suprir estas deficiências, ou excessos, existe uma versão simplificada do RUP denominada “RUP for Small Projects”. Existem ainda organizações que criam seu próprio processo de desenvolvimento utilizando-se de práticas, conceitos e até mesmo artefatos definidos pelo RUP. Estes processos, no entanto, são mais aderentes às suas necessidades e as suas realidades.
Ultimamente pouco se tem ouvido falar a respeito do RUP, pois, como mencionado anteriormente, a moda agora é “ser ágil”. Até o próximo post, onde falarei sobre o Scrum!
