Aula03 1-Arquiteturaprocessodedesenv

Instituto de Educao Superior de Braslia
Ps-Graduao em Engenharia de Software
A arquitetura no processo de desenvolvimento de software

Arquitetura de Software
http://nelson.junior.br.googlepages.com/as-20091 Nelson Alves da Nbrega Jnior
nelson.junior.br@gmail.com
Agenda
y Como e quando a arquitetura acontece em RUP e XP y O papel do Arquiteto de Software y Relao entre os Stakeholders e a arquitetura de um
sistema
y Consideraes finais
Como e quando a arquitetura acontece em RUP e XP
Introduo
| Sucesso do Projeto = planejamento + escolha metodologia adequada; | Planejamento - escolha do processo de acordo com recursos disponveis; | Metodologias
y Tradicional (Cascata):
y Etapas seqncias; y Grande esforo em especificar e definir arquitetura;
y Iterativas (RUP):
y A cada iterao uma parte do sistema desenvolvida; y Incremental;
y geis (XP):
y Comunicao face-a-face preferida a documentao compreensiva; y Pequenas releases.
4 Arquitetura de Software 4
Modelo Cascata - Arquitetura

| Etapa ou fase de design; | O software dividido em unidades, implementado, testado e integrado.
| Qual o problema deste modelo?

5 5 Arquitetura de Software
Modelo Cascata Exemplo (locadora)

|
Requisitos
y y y
Apenas um usurio operando o sistema; Aplicao desktop (centralizada); Dar suporte a locao de filmes; Modelagem dos requisitos: diagramas
Design
y
| | | |
Implementao e testes de unidade Integrao Manuteno O que acontece se eu chegar a fase de implementao e perceber que algum requisito/funcionalidade no foi modelado de forma correta ou consistente? E se algum requisito/funcionalidade mudar? Se o sistema tiver que dar suporte a pagamento tambm?
6 Arquitetura de Software
| |
Modelo Cascata - Problemas

y Se for detectado falhas na fase final do projeto? y Se houver mudana de requisitos ou funcionalidade? y O projeto pode sofrer enormes e dispendiosas alteraes! y O todo desenvolvido em apenas uma etapa! y Segundo Fred Brooks [8], impossvel especificar totalmente um software antes da sua implementao, o que dificulta alteraes, fator comum no desenvolvimento de um projeto; y O modelo Clssico ainda perdurou at a dcada de 90 como forma de desenvolvimento e foi utilizado com sucesso quando os requisitos estavam bem compreendidos.
IBM Rational Unified Process - RUP

| O Rational Unified Process um processo de engenharia de software, que procura disciplinar atribuies de tarefas e responsabilidades dentro de uma estrutura de desenvolvimento de software. Sua meta principal garantir a produo de software com alta qualidade satisfazendo as necessidades dos seus usurios, dentro de um cronograma e oramento previsvel. (Rational Unified Process, 2008 [7]); | O RUP um processo configurvel, ajustando-se tanto para pequenas equipes de desenvolvimento quanto para grandes.

|Rene muitas das melhores prticas em desenvolvimento de software:
y y y y y y Desenvolvimento iterativo de software; Gerenciamento de requisitos; Arquitetura baseada em componentes; Modelagem visual do software (prottipo); Verificao da qualidade do software (testes); Controle de mudanas no software.

| As fases constituem os ciclos de vida do software, sendo cada ciclo responsvel por uma verso nova do produto:
y y y y Concepo (Inception); Elaborao (Elaboration); Construo (Construction); Transio (Transition).
| O RUP representado usando quatro elementos para modelagem:

y y y y
11
Papis/Equipe (quem est fazendo o que); Artefatos (o que produzido); Atividades (como o trabalho conduzido); Workflows (quando uma tarefa conduzida).
Arquitetura no RUP
| Modelos so representaes consistentes de um sistema; | Os modelos de sistemas complexos podem ser bastante grandes; | Suponha uma tarefa de descrever um sistema em que os designers, programadores, usurios e gerente estejam aptos para:
y y y y y Entender o que o sistema faz; Entender como o sistema funciona; Estar pronto para trabalhar em alguma parte do sistema; Estender o sistema; Reusar parte do sistema para construir outro.
| Agora assuma que liberado um espao limitado para essa tarefa (p. ex. O mximo de 60 pginas). O que voc faria para descrever a arquitetura do sistema? | A arquitetura o que resta quando voc no pode tirar mais nada e ainda entender o sistema e explicar como funciona. 12
Arquitetura no RUP
| Prope um processo centrado na arquitetura; | Anlise e design para a arquitetura so atividades conjuntas; | Uso de UML e vises 4+1, Kruchten[3].
Arquitetura no RUP
| A arquitetura desenvolvida em iteraes durante a fase de elaborao seguindo uma abordagem incremental (builds), resultando assim em uma arquitetura estvel;
| O papel da descrio da arquitetura guiar toda a equipe de desenvolvimento durante ciclos de vida do sistema.
Arquitetura no RUP - Exemplo (locadora)

|
Concepo
y
Requisitos: Modelagem do negcio e do domnio; Vises; Use cases do sistema; Diagramas preliminares de classes; Diagramas Sequncia e/ou colaborao; Diagrama final de classes; Prottipo da arquitetura; Prottipo GUI; Planejamento da construo; Reviso dos use cases; Reviso dos diagramas de classes
Elaborao
y y y y y y y y
Construo
y y 15
15
Extreme Programming - XP
| A Extreme Programming - XP - uma metodologia gil voltada s equipes pequenas e mdias que desenvolvem software baseado em requisitos vagos e que se alteram com rapidez, Beck [16]; | O objetivo de XP tornar o projeto flexvel, diminuindo o custo a possveis mudanas; | Por que o termo extreme no nome?
Extreme Programming XP Prticas

|
XP leva ao extremo seus princpios e prticas:

y y y y y y y
Se revisar o cdigo bom, ento vamos revisar o cdigo durante todo o tempo (programao em par); Se testar bom, ento todo mundo vai testar durante todo o tempo (teste de unidade), at os clientes (teste funcional); Se design bom, ento vamos fazer com que isso seja parte do dia-adia da equipe (refatorao de cdigo); Se ter simplicidade bom, ento vamos deixar o sistema com o design o mais simples possvel; Se arquitetura importante, todo mundo ir defin-la e refinla durante todo o tempo (metfora); Se teste de integrao importante, ento vamos integrar e testar vrias vezes ao dia (integrao contnua); Se ter iteraes pequenas legal, ento vamos fazer iteraes muito pequenas segundos/minutos/hora (Planning Game). 17
17
Extreme Programming XP Prticas

| As prticas promovidas por XP se forem examinadas individualmente apresentaro falhas, mas uma das foras da XP que as praticas se combinam de um modo mtuo apoiando-se; | Fases de XP:
| Explorao; | Planejamento; | Iteraes para release; | Validao para produto; | Manuteno; | Morte.
Extreme Programming XP Fases
Arquitetura em XP
| comparada ao algoritmo hill-climbing: primeiro voc faz um design simples, depois um pouco mais complexo, em seguida um mais simples, depois um mais complexo. | Aplicar esse algoritmo para projetar a arquitetura do sistema da locadora:
y Primeiro desenvolve-se uma arquitetura que dar suporte apenas para as funcionalidades especificadas: Utilizar plataforma J2SE 1.4; Persistncia com XML; y Depois tenta-se uma mais complexa; Utilizar plataforma J2SE 1.4; Persistncia com MySQL; y Se tivermos que mudar para a J2SE 1.6?
Arquitetura em XP
| Se alguma funcionalidade/requisito mudar?
Agora a aplicao deve ser capaz de suportar plugins; E agora? Esse requisito tem impacto sobre o que j foi feito? SIM!!!
| Qual o problema desse algoritmo?

Quando atinge um estgio timo local, onde nenhuma mudana pequena pode resolver. Apenas uma grande mudana resolve!
Arquitetura em XP
| Durante a fase de Explorao a equipe possibilidades de arquitetura para o sistema: experimenta as
y A equipe se divide em pares, onde cada para ir tentar construir o sistema de forma diferente, durante uma ou duas semanas; y Depois as solues so comparadas e se escolhe a mais vivel (metfora de XP); y Caso acabe o tempo e no tenha resposta, sinal de que existe riscos, tecnolgicos p. ex., e deve-se procurar alternativas.
| Espera-se que a arquitetura para todo o sistema esteja definida ao final da primeira iterao, ainda que seja s o esqueleto.
Arquitetura em XP - Exemplo (locadora)

|
Uma equipe de 4 desenvolvedores se divide em pares para tentar construir o sistema de forma diferente, durante uma ou duas semanas , ento temos 2 pares;
y
Primeiro par: | Implementar o sistema utilizando a plataforma J2SE 1.5; | Fazer persistncia com XML; Segundo par: | Implementar o sistema utilizando Delphi; | Fazer persistncia com XML; Comparam-se as solues e escolhe a mais vivel; Resultado: Metfora definida!
23
y y
23
Comparao entre RUP e XP

Qual atende melhor?
Estudo de Caso: Desenvolvimento de um componente utilizando RUP e XP

| Esta experincia foi feita em uma empresa do Paran composta de 8 desenvolvedores, [9]; | A equipe foi dividida em 2 grupos, o primeiro com a responsabilidade de desenvolver um componente de software utilizando XP e outro de desenvolver o mesmo componente utilizando RUP; | O componente ter a finalidade de permitir o usurio lanar valores de comisso para os vendedores cadastrados em um sistema j existente; | O ciclo completo de desenvolvimento ficou dividido em 2 iteraes; | No primeiro ciclo foram implementados desenvolvedores e efetuados os testes; os requisitos pelos
| No segundo ciclo foram implementadas as correes pelos desenvolvedores dos erros detectados pela equipe de testes no primeiro ciclo, assim como os re-testes aps as correes terem sido efetuadas.

| As atividades do grupo de XP foram orientadas de acordo com as prticas recomendadas pela metodologia; | O grupo de RUP trabalhou paralelamente ao grupo XP no ciclo de vida do software, seguindo as fases de cada processo; | Durante o desenvolvimento das atividades dos dois grupos, uma pessoa do apoio efetuava os registros de erros conforme aconteciam (documentao, sintaxe, configurao, lgica, excees...).

| No 1 ciclo:
y Comparativo de quantidade de erros e tempo de desenvolvimento para as duas metodologias:
Metodologia RUP XP Metodologia RUP XP Quantidade de Erros 12 21 Linhas de cdigo 1433 1695 Quantidade de Erros 4 9 Tempo em horas 35.25 36 Quantidade de erros 5 22 Tempo em horas 4.67 3.9 Erros/hora 0.34 0.61 Erros/LOC 0,349% 1.30% Erros/hora 1.93 1.03 27
y Quantidade de erros por linha de cdigo (LOC)
| No 2 ciclo:
Medodologia RUP XP 27 Arquitetura de Software

| Em relao ao tempo total necessrio para o desenvolvimento, testes e entrega do produto de software, RUP e XP apresentaram resultados praticamente equivalentes;
y Justificativa: mesmo dedicando um tempo considervel na metodologia RUP para a documentao, atividades que no se aplicam ao XP, a atividade de criao de scripts de testes em XP fizeram com que o resultado final fosse praticamente idntico;
| Em relao ocorrncia de erros, verificou-se no 1 ciclo, que o grupo de XP apresentou 42% a mais que o grupo de RUP;
y Hiptese: devido aos scripts de testes feitos pelos desenvolvedores XP antes da implementao definitiva a quantidade de erros detectados nesta etapa seria maior que a do RUP; y Tal hiptese no se confirmou devido estas propores de erros terem se mantido na etapa dos testes de aceitao realizados pela equipe de testes, no 2 ciclo.

|O que podemos concluir a partir do estudo de caso? |Comparando-se a aplicao das duas metodologias:
y XP obteve um menor custo/benefcio, tendo como base que os esforos de tempo necessrio para o desenvolvimento e teste foram praticamente os mesmos e produziram um resultado final de menor qualidade, devido aos erros serem em maior quantidade que no RUP, uma prova disso a quantidade de erros por linhas de cdigo; y A equipe RUP conseguiu um cdigo mais enxuto, com menor nmero de linhas, o ndice de erros por linha obtido por eles foi aproximadamente trs vezes menor se comparado ao da equipe de XP;
|No prudente e nem possvel efetuar uma concluso genrica, e sim, afirmar que neste caso, sob estas condies de parmetros, variveis e escopo apresentados, obteve-se melhor resultado com a aplicao das tcnicas e prticas sugeridas pelo RUP.
O papel do Arquiteto de Software
30
Analogia entre o Arquiteto Software e o de Construes

| Algumas caractersticas das Arquiteturas de Construo:
y y y y y Aplicao de fundamentos cientficos; Processo sistemtico de produo; Gerenciamento de equipe de especialistas; Viabilidade econmica, manuteno de custos e prazos; Qualidade do processo e do produto.
Isso o que ocorre tambm na engenharia de software!
Analogia entre o Arquiteto Software e o de Construes: O Papel do Arquiteto

| O trabalho de um arquiteto pode ser resumido em termos de:
y Materiais e componentes; y Espaos; y Experincias;
| Dessa forma, o arquiteto tem preocupaes, p.ex. com:

y Paredes, pisos, janelas, tetos, escadarias, etc; y Ambientes: tamanho, iluminao, ventilao, etc; y As sensaes de estar ou passar pelos diversos ambientes.
O Arquiteto de Software teria o mesmo papel?

32
Analogia entre o Arquiteto Software e o de Construes: Limitao

| A natureza do software no fsica, conceitual; | O software uma mquina abstrata que processa informaes e toma decises com base em instrues; | Indstria de software ainda imatura e no est completamente estabelecida; | A forma como um software entregue (configurao e instalao) diferente dos outros produtos; | Como arquitetar algo com essas caractersticas???
Quem o Arquiteto de Software?

| Mesmo sendo indispensveis no processo de desenvolvimento de grandes aplicaes, por que os arquitetos de software ainda so pouco conhecidos?
y Isto se deve ao fato de que uma empresa ao iniciar o desenvolvimento de uma nova soluo, primeiramente pensa em contratar um analista de sistemas e alguns desenvolvedores para a implementao da soluo; y Porm, durante o desenvolvimento do software, algumas questes referentes infra-estrutura do mesmo so levantadas:
|A soluo ser Windows ou Linux? |Se for Windows? Como ser distribuda? |Se a soluo for Web?
Quem o Arquiteto de Software?

| As respostas para as questes anteriores sero definitivas para a construo de uma boa soluo; | A tarefa de fornecer respostas para estas questes deve ser realizada por um profissional especfico com caractersticas tcnicas que o capacite a faz-la, profissional este conhecido como o arquiteto de software.
O Papel do Arquiteto de Software (RUP)

| Segundo as definies obtidas no guia navegao do RUP [7], o papel de um arquiteto de software liderar e coordenar as atividades e os artefatos tcnicos no decorrer do projeto; | O arquiteto de software estabelece a estrutura geral de cada viso de arquitetura: a decomposio da viso, o agrupamento dos elementos e as interfaces entre esses principais agrupamentos. Portanto, comparado aos outros papis, a viso do arquiteto de software ampla, e no detalhada; | Em resumo, o arquiteto de software deve ter grande conhecimento geral, possuir maturidade, viso e profunda experincia que permita identificar problemas rapidamente e dar opinies sensatas e criteriosas na falta de informaes completas.
O Papel do Arquiteto de Software (RUP)
O Papel do Arquiteto de Software

| Segundo Fowler[2], o arquiteto possui o papel de tomar todas as decises importantes, as quais devem ser seguidas, alm de trabalhar em colaborao com a equipe; | Em XP, o papel do arquiteto est dissolvido entre todos os programadores. | Resumindo o que vimos, o papel do arquiteto tem sido o de organizar a estrutura e o comportamento do software; | A arquitetura funciona como ponte entre os requisitos e o cdigo;
Objetivos do Arquiteto de Software

| De acordo com Kruchten[3], os objetivos do arquiteto (ou de um time de arquitetos, dependendo do processo e do tamanho do projeto) so:
y y y y y y Definir a arquitetura do software; Manter integridade arquitetural; Considerar os riscos tcnicos relacionados ao design; Ajudar no planejamento da construo do sistema; Servir de consultor e coach; Ajudar na evoluo do software.
Caractersticas do Arquiteto de Software

| Existem algumas caractersticas desejveis para que se consiga uma arquitetura satisfatria e de qualidade:
y Experincia; y Facilidade de Comunicao; y Liderana; y Proatividade; y Ser orientado a objetivos.
Como as Caractersticas do Arquiteto Influenciam na Arquitetura

| Ao mostrar qual a posio do arquiteto na hierarquia de uma organizao, observa-se que este no fica isolado dos outros na equipe, o que pode levar ao fracasso do projeto; | Existem outros fatores em relao ao arquiteto que podem comprometer o projeto segundo Kruchten[3]:
y Inexperincia; y Falta de autoridade; y Falta de objetivo; y Procrastinao, etc.
Opinies prticas e atuais: Revista MundoJava [10]

| muito comum que arquitetos inexperientes dirijam a arquitetura baseada em opes pessoais, frameworks que esto na moda, alguma coisa que ele leu em algum lugar ou motivado por uma forte rigidez conceitual ou acadmica. Tambm comum que pseudo-arquitetos coloquem na arquitetura alguma idia mirabolante que ele teve simplesmente porque ele achou isso legal. Nesse aspecto, a PROVA arquitetural pode filtrar aquilo que voc realmente precisa daquilo que no passa de megalomania. Se o arquiteto est sugerindo a adoo da soluo X ou do framework Y, dele deve ter razes muito lgicas, e principalmente, um grande embasamento nos requisitos ou nas caractersticas da rea de negcios que prove os porqus dessas decises. Rodrigo Yoshima

| Ter experincia crtico para o seu sucesso, mas infelizmente, jovens profissionais de informtica aparentam ter dificuldade com este conceito. crucial ter uma vasta experincia construindo sistemas variados, e no somente ter muita experincia construindo a mesma coisa vrias vezes. Voc precisa compreender que existem muitas estratgias para construir sistemas, e ter diversos pontos de vista importante para o seu sucesso. Scott Ambler

| Trabalhando em inmeras reas, problemas e linguagens diferentes voc ganha muitas experincias valorosas aplicveis em qualquer projeto de software. Um habilidoso e experiente arquiteto de software reconhecer solues genricas que comumente so aplicveis, no importando a rea de aplicao ou a linguagem de implementao. Alm disso, um arquiteto hbil deve compreender o suficiente sobre modelagem de banco de dados, o suficiente sobre aplicaes em tempo real, o suficiente sobre princpios slidos de orientao a objetos e o mundo dos padres de software, dos princpios de uma boa interface com o usurio, das arquiteturas distribudas e do tratamento de erros para conseguir direcionar a equipe. Jon Kern
y Jon Kern e Scott Ambler so dois renomados arquitetos que juntos somam dcadas de experincia em desenvolvimento de software.
Certificaes de Arquiteto de Software

| Existe um mercado que visa certificar profissionais como arquitetos de software; | Que certificaes so essas?
y Sun Certified Enterprise Architect for the Java 2 Platform Enterprise Edition SCEA (CX-310-052):
|Esta certificao compe-se de trs etapas: |Um exame objetivo; |Um projeto; |Um exame dissertativo sobre o projeto.

y Microsoft Certified Architect
| Ele um programa e no uma prova; | Esta certificao um processo com um tutor do ncleo de arquitetura da Microsoft que culmina na defesa de um projeto do mundo real perante uma banca para a avaliao das habilidades, conhecimentos e atitudes do candidato; | As principais competncias exigidas e avaliadas so:
| Forte conhecimento do negcio; | Pensamento Inovador e Estratgico; | Capacidade de Investigar Novas Tecnologias; | Conhecimento de Frameworks Arquitetnicos e Melhores Prticas; | Capacidade de Usar e Criticar Frameworks; | Capacidade de Atingir Rpida Proficincia em Qualquer Tecnologia; | Capacidade de Trabalhar com Informaes Incompletas.

|
Outras Certifies: IBM, BEA, SEI... O que elas certificam ?

y
Uma certificao do mercado, no atesta que alguem ou no determinada coisa; Ter uma certificao SCEA no prova que voc efetivamente um arquiteto de software; A certificao simplesmente garante que voc foi testado em todos os aspectos que um arquiteto deve possuir de conhecimento;
47
47
Arquiteto de Software - Mitos

|
Vistos os pontos relacionados ao perfil do arquiteto de software, alguns mitos foram quebrados:
y
1 Mito: arquiteto = desenvolvedor snior evoludo; 2 Mito: o arquiteto trabalha em um ambiente isolado da realidade do processo de desenvolvimento; 3 Mito: para ser um arquiteto basta conhecer as tcnicas de arquitetura de software; 4 Mito: um analista de sistemas ou um programador mais experiente pode fazer o mesmo trabalho que um arquiteto de software faz.
48
48
Arquiteto de Software
|
Muitas pessoas pensam no arquiteto como aquele superprogramador que conhece vrias tecnologias e o cara mais inteligente da equipe; Esta uma viso errada, normalmente, estes super-programadores so pessoas difceis de lidar, que pouco conversam (a no ser sobre tecnologia) e que no gostam de serem pressionadas. Totalmente em desacordo com o perfil do arquiteto de software;
Relao entre os Stakeholders e a Arquitetura de um sistema
50
Introduo
CONTEXTUALIZAO
y Desenvolvimento de software tradicional

Necessidade do software entregue atender aos requisitos dos usurios.
Introduo
CONTEXTUALIZAO
y As pessoas afetadas pelo sistema de software no esto
limitadas quelas que o usam. y Sistemas de software no so apenas usados, eles so:
y y y y y
Construdos e testados; Operados; Possivelmente reparados; Geralmente melhorados; e Pagos por.
y Stakeholders!
Cada atividade envolve um nmero de pessoas com requisitos, interesses e necessidades prprios a serem satisfeitos pelo software
Introduo
CONTEXTUALIZAO
Impossvel pensar em arquitetura de software sem considerar os stakeholders
Processo de Definio Arquitetural
Segue
Elementos Arquiteturais
Compreende
Relaciona-se 2..n 1..n Compreende
Relacionamento entre Elementos

1..n
1..n
Guia a definio 1..n da Projeta
Arquitetura
Tem
Sistema
Enderea as necessidades de 1..n
Pode ser documentada pela 0..n
Arquiteto
Cria e Detm
Descrio Arquitetural
Documenta a arquitetura para 1..n
Stakeholder
1..n
Captura os interesses de
Stakeholders
DEFINIO
Um stakeholder em uma arquitetura de software uma pessoa, grupo ou entidade com um interesse em ou preocupaes sobre a realizao da arquitetura.
[IEEE Standard 1471, 2000]
Stakeholders
DEFINIO
y Aqueles com um interesse na arquitetura muito mais amplo do que
apenas seus desenvolvedores, ou at mesmo seus desenvolvedores e usurios. y Podem ser:

y y
Indivduos
y Ex: o arquiteto e o gerente de projetos.
Classes de pessoas
y Ex: usurios, desenvolvedores e testadores.
55
Stakeholders
DEFINIO
y Qualquer requisito, objetivo, inteno, ou aspirao sobre a
arquitetura. y Relacionado aos atributos de qualidade:

y y y y y y y
Desempenho; Disponibilidade; Modificabilidade; Segurana; Testabilidade; Usabilidade; Tringulo de qualidade.
Stakeholders
DEFINIO
Stakeholders
IMPORTNCIA DOS STAKEHOLDERS y Stakeholders dirigem a forma e sentido da arquitetura: y Decises arquiteturais refletem as suas necessidades. y Sem eles, no haveria nenhum ponto no desenvolvimento da
arquitetura:
y No haveria ningum para constru-lo, implant-lo, execut-lo, ou pagar
por ele. y Um sistema que no satisfaz as necessidades dos seus stakeholders
no pode ser considerado de sucesso

y No importa quo bem est em conformidade com boas prticas
arquiteturais.
Stakeholders
PROBLEMAS E TRADEOFFS
y Uma comunidade ampla de stakeholders aumenta a chance de
sucesso. y No entanto,
y y
Os interesses dos stakeholders muitas vezes no so claros. Quando o stakeholder no um indivduo, pode no ser possvel capturar as necessidades de todos os membros y Dificuldade na identificao dos stakeholders
y Ex: quando um novo produto est sendo desenvolvido.
Interesses entre stakeholders podem ser conflitantes ou contraditrios.

59
59
Stakeholders
OS STAKEHOLDERS E O ARQUITETO
|
Identificar os stakeholders e conciliar os seus interesses papel do arquiteto de software.
Stakeholders
IDENTIFICANDO STAKEHOLDERS
y No h critrios puramente objetivos para determinar se os
stakeholders foram corretamente identificados. y A seleo depende de um conjunto de fatores, incluindo:

Objetivos do sistema; y Consideraes polticas e organizacionais; y Disponibilidade de recursos; e y Restries de custos e prazos de execuo.
y
Stakeholders
CRITRIOS PARA UM BOM STAKEHOLDER
|
Um bom stakeholder em uma arquitetura

Critrio Informado Comprometido Descrio Seus stakeholders tm informao, experincia, e entendimento necessrios para tomar as decises corretas? Seus stakeholders esto dispostos e aptos a participar do processo? Eles esto preparados para tomar algumas decises difceis? Voc pode garantir que decises tomadas agora pelos seus stakeholders no sero revertidas depois? Se um stakeholder um grupo e no uma pessoa, foram escolhidos representantes adequados para o grupo? Estes representantes acima satisfazem os critrios de cada indivduo?
62
Autorizado Representativo
62
Stakeholders
CLASSES DE STAKEHOLDERS
E muitos Outros!
Stakeholders
Cliente y Aquele que paga pelo sistema. y Interessado em:

y Objetivos do negcio; y Estimativas de custos e prazos; y Acompanhamento do progresso; y Satisfao da qualidade e requisitos comportamentais.
Stakeholders
Gerente de Projeto y Responsvel pelo gerenciamento do progresso do sistema atravs das variveis: qualidade, custo, prazo e escopo. y Interessado em:
y Todos os propsitos e restries do sistema; y Suas interaes com outros sistemas; y Saber se a arquitetura permitir que as equipes trabalhem
independentemente, interagindo de forma disciplinada e controlada.
Stakeholders
Arquiteto y Responsvel por descrever, documentar e conduzir a construo do sistema satisfazendo todas as necessidades dos stakeholders. y Preocupado com:
y Identificar e engajar os stakeholders; y Entender e capturar os interesses dos stakeholders; y Definir uma arquitetura que enderea estes interesses; y Conduzir a realizao da arquitetura do sistema fsico.
Stakeholders
Desenvolvedor y Responsvel pela construo do sistema a partir das especificaes. y Interessado em:
y Idia geral por trs do sistema; y Funcionalidades que devero ser implementadas; y Recursos que podem ser usados (plataforma, linguagem, ferramentas, etc.); y Questes como manutenabilidade, flexibilidade e compreensibilidade; y Restries (atributos de qualidade, oramento, etc.) que devem ser satisfeitas.
Stakeholders
Testador y Responsvel por testar o sistema para garantir que ele funciona corretamente. y Interessado em:
y Mesmas informaes dos desenvolvedores, porm com nfase na
especificao do comportamento; y Documentao de desenvolvimento; y Guias de utilizao.
Stakeholders
Mantenedor y Responsvel pelo gerenciamento da evoluo do sistema uma vez que ele seja operacional. y Interessado em:
y Documentao de desenvolvimento; y Instrumentao (facilidades para monitoramento operacional); y Ambientes de depurao; y Interoperabilidade com sistemas existentes.
Stakeholders
y y y y y y
Outros Stakeholders Engenheiro de requisitos Analistas Projetistas de outros sistemas Gerentes de linha de produto Usurios finais Arquitetos futuros
Stakeholders
STAKEHOLDERS E VISES y Algumas dificuldades podem existir ao responder questes como: y Quais so os elementos funcionais principais da arquitetura? y Como estes elementos iro interagir entre si e com o meio? y Que informao ser gerenciada, armazenada e apresentada? y Que elementos fsicos de hardware e software sero necessrios para dar suporte a estes elementos funcionais? y Que caractersticas operacionais e capacidades devero ser providas? y Quais ambientes de desenvolvimento, teste, suporte e treinamento sero providos? y Modelo nico?
Stakeholders
STAKEHOLDERS E VISES
y Impossvel capturar as caractersticas funcionais e propriedades de
qualidade de um sistema complexo com um simples modelo. y preciso representar sistemas complexos de uma forma que seja gerencivel e compreensvel por uma faixa de stakeholders tcnicos e de negcio. y Vises!
Uma viso uma representao de um ou mais aspectos estruturais de uma arquitetura que ilustra como a arquitetura enderea um ou mais interesses de um ou mais stakeholders.
[Woods, 2005] 72 72 Arquitetura de Software
Stakeholders
STAKEHOLDERS E VISES
Legenda: d = informao detalhada, s = alguns detalhes, o = informao sintetizada, x = qualquer
73
73
Stakeholders
CONFLITOS DE INTERESSES y Exemplos y Desempenho x Proteo
y Usurio: Uma pgina no deve demorar mais de 1 segundo para carregar. y Cliente: O sistema deve ser seguro (controle de acesso, autenticao, ...).
y Modificabilidade x Baixo Custo

y Mantenedor: sistemas devem ser fceis de manter. y Arquiteto: arquitetura em camadas (modularizao). y Cliente: baixos custos!
y Confiabilidade x Desempenho
y Cliente: persistncia com arquivos XML y Desenvolvedor: persistncia com BDs
Consideraes finais
75
Consideraes finais
y
Qual o melhor processo: RUP ou XP?

y Deve-se avaliar o contexto e complexidade do projeto
y Em relao aos Stakeholders,cabe ao arquiteto claramente:

y Identificar seus stakeholders; y Trabalhar com eles e entender suas preocupaes; y Balancear suas prioridades conflitantes inevitveis; y Negociar com eles; e y Projetar uma arquitetura que enderea seus requisitos o mais efetivamente possvel.
Em suma o papel do arquiteto agregar, gerenciar e possibilitar a realizao das necessidades!
76
Referncias
y [1] P. B. Kruchten, "The 4+1 view model of architecture," Software, IEEE, vol. 12, y y
y y y
no. 6, pp. 42-50, 1995. [2] Fowler, M. Design - who needs an architect? Software, IEEE 20, 5 (2003), 1113. [3] Kruchten, P. The software architect-and the software architecture team. Software Architecture; TC2 First Working IFIP Conference on Software Architecture (WICSA1) 2 , 565583. [4] P. Kruchten, The Rational Unified Process: An Introduction, Third Edition. Addison-Wesley Professional, December 2003. [5] K. Beck and C. Andres, Extreme Programming Explained: Embrace Change (2nd Edition). Addison-Wesley Professional, November 2004. [6] M. R. Mcbride, "The software architect: essence, intuition, and guiding principles," in OOPSLA '04: Companion to the 19th annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications. ACM Press, 2004, pp. 230-235.
77
Referncias
y [7] Rational Unified Process: http://www.wthreex.com/rup. y [8] BROOKS, F. No Silver Bullet: Essence and Accidents of Software Engineering.
y y y y
Proc. IFIP, IEEE CS Press, pp. 1069-1076; reprinted in IEEE Computer, pp. 10-19, Apr, 1987. [9] RUP e XP: http://xp.edugraf.ufsc.br/bin/view/XP/RUPeXP. [10] Resvista Mundo Java, edio 25. [11] Utilizando UML e Padres: Uma Introduo Anlise e ao Projeto Orientados a Objetos, 2 Edio, Craig Larman, BOOKMAN, 2004 [12] N. Rozanski and E. Woods, Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Addison-Wesley Professional, April 2005.
78

Aula03 1-Arquiteturaprocessodedesenv

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula03 1-Arquiteturaprocessodedesenv

Enviado por

Direitos autorais:

Formatos disponíveis

Instituto de Educao Superior de Braslia

Ps-Graduao em Engenharia de Software

A arquitetura no processo de desenvolvimento de software

Como e quando a arquitetura acontece em RUP e XP

Modelo Cascata - Arquitetura

| Qual o problema deste modelo?

Modelo Cascata Exemplo (locadora)

Modelo Cascata - Problemas

IBM Rational Unified Process - RUP

IBM Rational Unified Process - RUP

IBM Rational Unified Process - RUP

IBM Rational Unified Process - RUP

| O RUP representado usando quatro elementos para modelagem:

Arquitetura no RUP - Exemplo (locadora)

Extreme Programming XP Prticas

XP leva ao extremo seus princpios e prticas:

Extreme Programming XP Prticas

Extreme Programming XP Fases

| Qual o problema desse algoritmo?

Arquitetura em XP - Exemplo (locadora)

Comparao entre RUP e XP

Estudo de Caso: Desenvolvimento de um componente utilizando RUP e XP

Estudo de Caso: Desenvolvimento de um componente utilizando RUP e XP

Estudo de Caso: Desenvolvimento de um componente utilizando RUP e XP

y Quantidade de erros por linha de cdigo (LOC)

Estudo de Caso: Desenvolvimento de um componente utilizando RUP e XP

Estudo de Caso: Desenvolvimento de um componente utilizando RUP e XP

O papel do Arquiteto de Software

Analogia entre o Arquiteto Software e o de Construes

Isso o que ocorre tambm na engenharia de software!

Analogia entre o Arquiteto Software e o de Construes: O Papel do Arquiteto

| Dessa forma, o arquiteto tem preocupaes, p.ex. com:

O Arquiteto de Software teria o mesmo papel?

Analogia entre o Arquiteto Software e o de Construes: Limitao

Quem o Arquiteto de Software?

Quem o Arquiteto de Software?

O Papel do Arquiteto de Software (RUP)

O Papel do Arquiteto de Software (RUP)

O Papel do Arquiteto de Software

Objetivos do Arquiteto de Software

Caractersticas do Arquiteto de Software

Como as Caractersticas do Arquiteto Influenciam na Arquitetura

Opinies prticas e atuais: Revista MundoJava [10]

Opinies prticas e atuais: Revista MundoJava [10]

Opinies prticas e atuais: Revista MundoJava [10]

Certificaes de Arquiteto de Software

Certificaes de Arquiteto de Software

Certificaes de Arquiteto de Software

Outras Certifies: IBM, BEA, SEI... O que elas certificam ?

Arquiteto de Software - Mitos

Relao entre os Stakeholders e a Arquitetura de um sistema

y Desenvolvimento de software tradicional

y As pessoas afetadas pelo sistema de software no esto

Construdos e testados; Operados; Possivelmente reparados; Geralmente melhorados; e Pagos por.

Relaciona-se 2..n 1..n Compreende

Relacionamento entre Elementos

Guia a definio 1..n da Projeta

Pode ser documentada pela 0..n

Documenta a arquitetura para 1..n

y Aqueles com um interesse na arquitetura muito mais amplo do que

apenas seus desenvolvedores, ou at mesmo seus desenvolvedores e usurios. y Podem ser:

y Qualquer requisito, objetivo, inteno, ou aspirao sobre a

[IEEE Standard 1471, 2000]