Professional Documents
Culture Documents
Reviso Aula 1 e 2
Resolvendo problemas
0 A maioria dos problemas grande e, algumas vezes, difcil de se resolver. Sendo assim, devemos comear a investigao analisando o problema, isto , dividindo-o em partes que sejamos capazes de entender e manipular.
Processo de anlise
Problema
Subproblema 1
Subproblema 2 Subproblema 3
Subproblema4
O processo de sntese
Soluo 1 Soluo 2 Soluo 3 Soluo 4
SOLUO
A crise do software
0 A crise do software: assunto tratado no incio da dcada de 70, o qual deu origem engenharia de software; 0 Evoluo do hardware abria possibilidade de desenvolver softwares poderosos, porm no havia ferramental disponvel para isso; 0 Software era feito de maneira emprica e artesanal; 0 Problemas como prazos no cumpridos, gastos mal estimados e softwares que no atendiam os requisitos;
A crise do software
0 Algumas manchetes antigas - a viso do mercado:
0 Inicio da dcada de 80, revista Business week: Software: a
nova mola propulsora; 0 Mais tarde na dcada de 80, revista Fortune: Crescente defasagem no Software; 0 Ainda na dcada de 80, revista Business week: Armadilha do software: automatizar ou no?; 0 Inicio da dcada de 90, Newsweek: Podemos confiar em nossos softwares?
Crise do software se refere a um conjunto de problemas que encontramos no processo de desenvolvimento do software (Pressman);
necessidades do usurio);
0 Impossibilidade de cumprir prazos e custos; 0 Dificuldade em treinar os profissionais nas novas tecnologias;
constante de atualizao)
Mitos do Software
0 Surgiram nos primrdios do desenvolvimento de software. Ao contrrio da mitologia, que oferece lies que valem a pena serem consideradas, os mitos do desenvolvimento de software s propagam desinformao e confuso.
Concluso!
No vamos atender a demanda de software com qualidade, a preo compatvel e num contexto de globalizao e da busca de resultados, desenvolvendo-os de maneira artesanal e emprica. preciso adotar mtodos, tcnicas e ferramentas que permitam a aplicao de princpios cientficos ou, no mnimo, adequados produo eficiente de software.
Software O que ?
So programas de computador e documentao associada. Produtos de software podem ser desenvolvidos para um cliente especfico ou para o mercado em geral.
O software deve ser escrito de forma que possa evoluir para atender s necessidades dos clientes. Esse um atributo crtico, porque a mudana de software um requisito inevitvel de um ambiente de negcio em mudana.
10
11
ANALISTA PROJETISTA
Projeto do Sistema
Projeto do Programa Implementao do Programa Testes de Unidades Teste de Integrao Teste do Sistema Entrega do Sistema Manuteno
INSTRUTOR
Reviso Aula 3 e 4
12
A importncia da modelagem
0 Um modelo : 0 Uma abstrao de um objeto ou fenmeno... 0 ....sob um determinado ponto de vista e ... 0 ...um certo nvel de detalhamento.
SISTEMA
uses CASO DE USO
MODULO
COMPONENTE 1
ATOR
COMPONENTE 2
DIAGRAMA DE COMPONENTE
13
4- Um nico modelo no suficiente. Qualquer sistema no trivial melhor enfocado com um pequeno conjunto de modelos semi-independentes.
UML: User Guide - Booch, Rumbaugh, Jacobson.
14
(entendimento).
0 Representar o ambiente no qual o sistema dever se inserir. 0 Desenvolver solues para o problema (criatividade +
15
e comunicar o
projeto
para terceiros
(documentao)
modelagem a ser empregada (sua simbologia e sintaxe), dos procedimentos para sua aplicao e de ferramentas que automatizam a metodologia (se disponveis).
16
Casa: A construo ser mais eficiente (especialistas) e mais rpida se feita por equipe. Requer: Modelagem (planta baixa, eltrica, hidrulica etc.) Processo bem definido Ferramentas poderosas
17
18
19
seqncia, etc).
0 Modelo de objetos (Diagrama de classe, de associao, de generalizao, etc.) 0 Modelo de projeto (PERT/CPM, Diagrama de distribuio, etc.) 0 Modelo para testes (Diagrama Ciclomtico, etc) 0 Modelo de custo (Modelo de Putnam, Modelo ABC, etc)
20
21
chamados de Paradigmas da Engenharia de Software), alguns cobrindo apenas as fases do processo que vo da concepo ao desenvolvimento, enquanto outros cobrem concepo, desenvolvimento, implantao e manuteno.
0 So modelos prescritivos porque prescrevem um conjunto de elementos de processo num fluxo de trabalho (seqncia e comunicao entre esses elementos).
PRESCREVER ORDENAR DE MANEIRA EXPLCITA PREVIAMENTE
Processo
0 Processo de software um conjunto de atividades relacionadas que levam produo de um produto de software. 0 Existem muitos processos de software diferentes, mas todos devem incluir quatro atividades fundamentais para a engenharia de software:
0 Especificao de software: funcionalidade e restries ao
atender s especificaes.
0 Validao de software: garante que o software atenda as demandas
do cliente.
0 Evoluo de software: software deve evoluir atendendo necessidades
de mudanas.
22
23
2) No processo
3) Na documentao 4) No sistema antigo (quando existe) Tarefas:
24
Ferramentas:
No tem. Tcnicas: Psicologia Entrevistas Questionrios Mapeamento de Processos Brainstorming etc.
25
26
especificao.
Especificar: (v.t.d.) Indicar espcie de; explicar detalhadamente; Descrio rigorosa e minuciosa das caractersticas que um material, uma obra ou um servio devero apresentar.
27
3. Quando o produto for entregue, ser usado pelo usurio para validao (ESTAMOS CONSTRUINDO O PRODUTO CERTO).
28
Requisitos Funcionais: O que o produto de software deve fazer (funcionalidades). 0 Casos de Uso ou eventos 0 Atividades do Processo 0 Aquisio de informaes 0 Tratamento das informaes 0 Armazenagem das informaes 0 Distribuio das informaes 0 Acionamento de dispositivos
29
Confiabilidade Disponibilidade (misso crtica) Segurana Portabilidade Economia Compatibilidade (legados) Flexibilidade Acurcia (preciso) Adequao a Legislao Desempenho Problemas da interface homem-mquina Restries fsicas e operacionais
ignorando os detalhes. 0 Decomposio: Dividir em partes para lidar com a complexidade. 0 Generalizao: Buscar caractersticas comuns relegando as caractersticas especficas ( uma forma de abstrao). 0 No usar Formalidade e Flexibilizao.
30
Ferramentas:
0 Metodologias/tcnicas de modelagem e anlise, ferramentas
31
ou Engenharia de Requisitos:
0 Obter uma compreenso completa dos requisitos de software, atravs de:
Descoberta
Refinamento
Especificao Tcnica Modelagem
Modelos de Dados
SISTEMA
Modelos de Funcionalidade
32
conhecendo cada uma delas (tipo, tamanho, volume, consistncias, inter-relao, se disponvel em bases de dados, forma de coleta etc).
0 Tambm deve definir detalhes da funcionalidade (detalhes de
como o sistema deve se comportar, tanto em funcionalidade como em performance, segurana etc.)
33
Foco:
0 Nos dados, componentes de software e no produto final de
Ferramentas:
0 Metodologias/tcnicas de modelagem e anlise, ferramentas
MDULO PRINCIPAL
INFORMAES FUNES
MDULO 01
MDULO 02
MDULO 03
MDULO 04
MDULO 05
MDULO 06
MDULO 04
MDULO 07
MDULO 08
MDULO 10
MDULO 11
MDULO 09
MDULO 09
34
MDULO PRINCIPAL
INFORMAES FUNES
MDULO 01
MDULO 02
MDULO 03
MDULO 04
MDULO 05
MDULO 06
MDULO 04
MDULO 07
MDULO 08
MDULO 10
MDULO 11
MDULO 09
REUSABILIDADE
MDULO 09
arquiteturas candidatas.
35
produto:
0 O que cada parte deve fazer (entradas, comportamento, sadas),
gerando
uma
especificao
para
buscar
componentes
candidatos (reusabilidade).
0 Definir a relao entre os componentes.
36
37
programao (sintaxe,
Ferramentas:
0 Linguagens de programao, geradores de cdigo fonte, CASE de
38
Ferramentas:
0 Tcnicas de testagem, procedimentos da Qualidade,
39
Teste:
MDULO 01
MDULO 02
MDULO 03
MDULO 04
MDULO 05
MDULO 06
MDULO 04
MDULO 07
MDULO 08
MDULO 10
MDULO 11
MDULO 09
MDULO 09
40
Teste: 0 De Integrao do sistema (todos os componentes, a partir de uma estratgia de aglutinao progressiva).
SISTEMA
MDULO 01
MDULO 02
MDULO 03
MDULO 04
MDULO 05
MDULO 06
MDULO 04
MDULO 07
MDULO 08
MDULO 10
MDULO 11
MDULO 09
MDULO 09
41
42
0 Falha (Failure)
Resultados incorretos
0 Defeito (Fault)
Falha resultante de ao humana Uma falha pode ter como origem um defeito ou um erro.
0 Stress etc.
0 Beta teste
43
Ferramentas:
0 Linguagens de programao, ferramentas CASE etc.
44
45
0 Converso de arquivos ou
0 Gerao dos arquivos (caso Biblioteca) 0 Treinamento dos usurios 0 Integrar tecnologias
46
47
48
Reviso Aula 5 e 6
49
evolutivos) que se baseiam num desenvolvimento de um produto inicial que vai sendo submetido a avaliaes do usurio e sendo simultaneamente refinado atravs de sucessivas verses, at que alcance a funcionalidade desejada.
0 Inicialmente o modelo evolucionrio previa ciclos lineares (paradigma do desenvolvimento linear no modelo
50
Modelo Incremental (adota as etapas do modelo linear puro, porm com iteratividade e desenvolvimento/teste durante todo o processo)
Modelo Evolutivo (ou exploratrio) Modelo de Prototipao Modelo Espiral Tradicional RAD RUP
Paradigma Evolucionrio
1) Modelo Incremental
51
Modelo Incremental
uma adaptao (para melhor) do modelo de desenvolvimento linear, pois trata-se de um arranjo de vrios pequenos ciclos em cascata.
0
A diferena que cada verso do produto de software tem uma nova funcionalidade (incremento), definida no incio do ciclo.
Depois de desenvolvida, cada verso ser entregue ao usurio para testes. Cada verso implementa uma nova funcionalidade (incremento) que acrescida funcionalidade anterior.
52
53
2) Modelo Evolutivo
Tem como objetivo promover um desenvolvimento conjunto (desenvolvedor trabalhando junto com o usurio) a fim de descobrir os requisitos de maneira incremental.
Diferente do modelo incremental, esse modelo volta sempre fase de definio de requisitos, num movimento exploratrio de conceitos do produto e necessidades do usurio.
54
3) Modelo de Prototipao
55
Diferentemente do Modelo Incremental e do Modelo Evolutivo, que fazem uma explorao para a definio dos requisitos enquanto constroem o produto final, a prototipao
Como o prottipo no ser usado como produto final, pode-se (deve-se) omitir aspectos de esttica, performance, segurana etc.
Deve-se trabalhar com ferramentas adequadas rpida gerao de cdigo. O prottipo no precisa conter toda a funcionalidade do produto final; apenas os aspectos sobre os quais havia alto nvel de incerteza, como por exemplo detalhes das entradas ou sadas do sistema, a exatido de um algoritmo ou a correta aplicao de uma nova tecnologia.
0 0
56
Vendo o que o prottipo apresenta, o usurio descobre novas necessidades (vendo o que ele tem, descobre o que falta). O desenvolvimento do prottipo comea com uma verso preliminar, aps rpida interao desenvolvedor-usurio. Aps o desenvolvimento do prottipo, dado aos usurios a oportunidade de brincar com ele. Baseado nessa experincia o usurio opina sobre o que est certo, o que est errado, o que est faltando e o que est sobrando.
0 0
Aps essa interao, o prottipo modificado e novamente entregue ao usurio para validao. Esse ciclo se repete at que as incertezas sobre os requisitos estejam num nvel mnimo, permitindo assim definir o conjunto de requisitos do produto a ser
desenvolvido.
57
Existe um custo extra, pelo perodo de prototipao, que s se justifica se o nvel de incerteza dos requisitos alto.
58
59
1o quadrante 2o quadrante
3o quadrante
4o quadrante
Construir
Avaliar
pouco acentuado (o produto est em sua verso inicial; apenas um cerne do que ser o produto final).
0 Com o passar dos ciclos, o movimento fica maior em
cada quadrante, o que representa bem o fato de que, medida que a espiral cresce, o trabalho e/ou a complexidade do produto de software aumenta.
60
AVALIAR
CONSTRUIR
Anlise de Riscos:
0
O modelo espiral trouxe uma nfase Anlise de Riscos no desenvolvimento de software (gerncia segura).
Atravs da Anlise de Riscos, podemos escolher caminhos com as melhores chances de sucesso, dentro de prazos razoveis.
61
O modelo em espiral preconiza o desenvolvimento de software atravs da avaliao de riscos obtidos atravs de sucessivas prototipagens (e/ou simulaes e benchmarking).
0
0
0
Desvantagem:
Aumento de prazo custos no projeto.
Justificativa para isso:
0 0
O modelo mantm as caractersticas positivas de documento associado a fases do ciclo (cascata) com fases sobrepostas (incremental) e uso de prototipao (aproveitando o prottipo para produto final).
Parte da premissa de que a forma de desenvolvimento de software no pode ser completamente determinada de antemo (centro da espiral). Assim, atravs de fases sucessivas e algumas atividades-chave (anlise de risco, prototipao, simulao, validao etc) chegamos a um projeto detalhado de software e a construo
62
Solicitao do cliente Planejamento Anlise de risco Modelagem Construo, teste, instalao e suporte para o cliente testar Avaliao do cliente
63
FASES NOVAS
64
Disponvel imediatamente 0 Sistemas baseados em componentes COTS (Commercial Off-The-Shelf de prateleira) reusveis em larga escala ou CBS (COTS Based Systems - vide desenvolvimento baseado em COTS e Mtricas COTS)
Trata-se de uma variao do modelo de desenvolvimento em espiral atualizado, onde as fases 4 e 5 (modelagem e construo-teste-instalao-suporte para teste) tem duas
65
FASES MODIFICADAS
Identificar componentes candidatos (produtos de software que tem a funcionalidade requerida) Procurar o componente (bibliotecas, outros projetos, mercado, internet etc)
66
Caso no existam componentes prontos, a fase ser desenvolvida como no modelo espiral adaptado (neste ciclo da espiral), com a construo do componente necessrio.
Se existirem componentes, eles sero recuperados e catalogados na biblioteca do projeto. Em seguida sero aplicados na construo do produto, encerrando essa fase.
O ciclo continua na fase de avaliao do cliente.
67
O usurio quer a mxima funcionalidade O desenvolvedor deve lembr-lo sobre prazo/custo/performance decorrentes do tamanho do projeto Existem muitas outras situaes de negociao entre interesses do usurio e restries do desenvolvedor
68
A melhor negociao (para a organizao) aquela dirigida para resultados Ganha-Ganha (Win-Win):
0
O cliente ganha por obter um produto que satisfaa a maioria de suas necessidades
O modelo Espiral Win-Win (Boehm, 98) define um conjunto de atividades de negociao que se iniciam a cada ciclo da espiral. Essas atividades so assim definidas:
1. Identificar os interessados* (stakeholders) na prxima rodada de negociaes. 2. Determinar as condies favorveis (de ganho) para esses
interessados.
3. Avaliar riscos e alternativas.
(*) Interessados: pessoas da organizao que tm interesse no sucesso do sistema, ou sero criticadas se ele falhar.
69
comprometimento.
70
Segue o padro incremental, porm enfatiza um desenvolvimento rpido (geralmente 60 a 90 dias) e a base da Fbrica de Software*. Trata-se de uma adaptao do modelo linear-seqencial (cascata) no qual a velocidade obtida pela aplicao de componentes reutilizveis (COTS), mltiplas equipes especializadas de desenvolvimento (cada um faz apenas o que sabe fazer melhor).
* Fbrica de Software: ter processos claros e depender mais deles do que das pessoas, de forma a ter resultados mais previsveis. O termo software factory(fbrica de software em ingls) foi empregado pela primeira vez em 1969, pela japonesa Hitachi, mas s comeou a ficar popular no incio dos anos 90. A idia era aplicar conceitos da indstria em geral em ambientes de desenvolvimento de software, de forma a aumentar a produtividade e diminuir prazos e custos. Fonte: BRANDO, Aline. Texto: O que Fbrica de Software.. Disponvel em: http://www.timaster.com.br/revista/materias/main_materia.asp?codigo=1197. Acessado em 12 de maro de 2012.
71
Inicialmente o projeto dividido em sub-projetos. Todos os sub-projetos que podem iniciar juntos so designados para equipes diferentes. A base da formao das equipes reunir tcnicos especializados em uma atividade ou fase do desenvolvimento de software (modelagem de banco de dados, projeto de IHC, etc.).
Modelagem de Negcio: Modelar o fluxo da informao fluindo atravs da organizao (negcio). Modelagem de Dados: O fluxo definido no item 1 agora transformado num conjunto de objetos de dados.
3.
Modelagem do Processo: Analisa as transformaes nos objetos de dados, atravs de adio, modificao, excluso ou recuperao de dados, a fim de implementar uma funcionalidade de negcio.
72
Gerao da Aplicao: O modelo RAD pressupe o uso de tcnicas L4G e gerao automtica de cdigo, sempre que possvel.
L4G- Linguagens de Quarta Gerao: Linguagens no-procedurais (definem o que e no como)
5. Testar e concluir o desenvolvimento (sincronizar e estabilizar): Em seguida a equipe dissolvida para iniciar outro sub-projeto ou mesmo reintegrar-se em equipes que esto com o trabalho em desenvolvimento.
Desvantagens:
0
O produto tem que ser apto a ser modularizado (subprojetos) e permitir a aplicao de componentes reutilizveis.
73
74
Desenvolvimento de software a partir de um framework genrico, que pode ser especializado para diferentes aplicaes, organizaes, nveis de competncia e tamanho de projetos. Caractersticas:
0 0 0 0 0
Baseado em componentes reutilizveis Usa UML para modelar o produto Dirigido a casos de uso Centrado na arquitetura Iterativo e Incremental
funcionalidade do produto.
0 Um modelo de Casos de Uso formado pelo conjunto de diagramas de
Caso de Uso.
0 Vantagem: est dirigido a cada usurio (ator).
0 A arquitetura de software deve contemplar seus aspectos esttico e
dinmico.
75
RUP - Conceitos
FASES Na fase de Concepo, decide-se o que ser desenvolvido.
76
RUP - Conceitos
FASES Na Elaborao faz-se uma anlise de risco, constri-se uma arquitetura executvel, para realizar um teste de viabilidade e outras atividades para garantir o sucesso do projeto.
RUP - Conceitos
FASES Na fase de Construo o produto de software construdo, garantindo que, ao final de cada iterao, teremos um software executvel, para ser liberado aos usurios.
77
RUP - Conceitos
FASES Finalmente, na Transio o produto de software instalado na rea de produo, juntamente com a documentao, o treinamento e suporte para os usurios.
RUP - Conceitos
No desenvolvimento de cada fase, executamos diversos tipos de atividades, chamadas disciplinas.
78
RUP - Conceitos
Em cada iterao, empregamos esforo em algumas ou em todas as disciplinas que constituem o processo de software.
Reviso aulas 7 e 8
79
Modelos geis
Incio
0 Final dos anos 90 presencia o surgimento de diferentes mtodos: 0 Crystal; 0 eXtreme Programming; 0 Scrum;
Modelos geis
Princpios do Manifesto gil
0
Quatro valores 0 Indivduos e interaes so mais importantes que processos e ferramentas; 0 Entregar software funcionando em prazos curtos mais importante do que documentao completa e detalhada; 0 Adaptao a mudanas mais importante do que seguir o plano inicial; 0 Colaborao com o cliente mais importante do que negociao de contratos;
80
Modelos geis
Princpios do Manifesto gil
0 Doze princpios:
1. 2. 3. 4.
5.
6.
Maior prioridade satisfazer o cliente atravs da entrega contnua e rpida de software com valor agregado; Mudanas nos requisitos so bem-vindas, mesmo tardiamente no desenvolvimento; Entregar frequentemente o software funcionando, em prazos de poucas semanas a poucos meses; Pessoas relacionadas ao negcio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto; Construa projetos em torno de indivduos motivados. D a eles o ambiente e o suporte necessrio e confie neles para fazer o trabalho; O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma equipe de desenvolvimento atravs de conversa face a face;
Modelos geis
Princpios do Manifesto gil
0 Doze princpios (continuao):
Software funcionando a principal medida de progresso; 8. Os processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente; 9. Contnua ateno excelncia tcnica e bom design aumentam a agilidade; 10. Simplicidade essencial; 11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizveis; 12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento refina e ajusta seu comportamento de acordo
7.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento refina e ajusta seu comportamento de acordo
81
Modelos geis
Caractersticas
nfase na melhora da usabilidade atravs de incrementos curtos, os quais tem como foco as prioridades do cliente; 0 Objetivo chave melhorar a usabilidade dos produtos;
0
Modelos geis
Aplicao
0 Projetos pequenos ou mdios. Pois para projetos grandes a falta de gerncia de mudanas traz alto custo nos projetos.; 0 Equipes pequenas ou mdias; 0 Requisitos dinmicos ou em constante mudana; 0 Necessidade de desenvolver software de forma mais rpida;
82
XP Extreme Programming
Caractersticas Bsicas
0 Caractersticas:
0 Feedbacks contnuos e concretos em ciclos curtos; 0 Abordar planejamento incremental; 0 Flexibilidade na implementao de funcionalidade. 0 Confiar em programadores e clientes para monitorar o
XP Extreme Programming
Os quatro valores
0
Comunicao: Alguns problemas nos projetos de desenvolvimento Simplicidade: Em relao ao processo e codificao, XP prope o
ocorrem porque fatos importantes no so comunicados no momento certo. principio de fazer um produto simples que funcione, ao invs de fazer um produto muito complicado sem possibilidade de uso no futuro.
0
0
Coragem: preciso ter coragem para manter a simplicidade do sistema deixando para depois as decises e finalmente necessrio coragem para confiar no feedback permanente durante o processo de desenvolvimento ao invs de tentar adivinhar tudo com antecedncia.
83
Fases do processo
Resumo
Fases do processo
Explorao
0 Levantamento de requisitos e estudo de arquitetura; 0 Cliente escreve os cartes de estrias; 0 Programadores estudam e testam tecnologias para construir arquitetura do sistema;
84
Fases do processo
Planejamento do release
0 Objetivo desta fase levantar escopos e prazos para o
release; 0 Execuo do jogo de planejamento; 0 Cliente classifica estrias em nveis de prioridade; 0 Programadores indicam velocidade estimada para cada estria; 0 Escopo e prazos para release so determinados;
Fases do processo
Planejamento da iterao
0 Programadores escrevem tarefas para estrias; 0 Tarefas tambm podem incluir atividades no relacionadas diretamente a estrias; 0 Cada programador escolhe algumas tarefas; 0 Estima-se nmero de horas necessrio para tarefa; 0 Estima-se fator de carga; 0 Calcular prazos segundo estimativas anteriores;
85
Fases do processo
Desenvolvimento da iterao
0 Programador escreve testes de unidade que orientaro a codificao de sua tarefa; 0 Programador escolhe parceiro para codificao da tarefa; 0 Codificao em pares; 0 Aplicao de testes de unidade para verificao das tarefas e das estrias; 0 Aplicao de testes funcionais;
Fases do processo
Resumo
86
Fases do processo
Entrega do release
0 Execuo de testes funcionais que retratam sistema de ponta a ponta; 0 Aprovao do release; 0 Implantao do release; 0 Produo: 0 Refinamento de performance;
Fases do processo
Resumo
87
Fases do processo
Manuteno
0 Estado normal de um projeto que utiliza XP; 0 Refactorings (Refatorao); 0 Adoo de novas tecnologias; 0 Incluso de estrias; 0 Trabalhar em sistemas que j esto em produo mais lento e merece mais ateno;
Refactoring um processo de reorganizao da estrutura interna do software, sem alterar o seu comportamento externo. um modo disciplinado de reorganizar cdigo, facilitando posterior depurao, eliminando cdigo presumvel de introduzir erros.
Prticas
Resumo
88
Prticas
Jogo do planejamento
0 O jogo de planejamento enfatiza: 0 As regras de negcio (cliente) 0 Consideraes tcnicas (equipe tcnica); 0 Definio do escopo de cada iterao; 0 A nfase est em guiar o projeto; 0 Construo dos cartes de estrias e dos cartes de tarefas;
Prticas
Pequenas verses
0 Criar verses pequenas do software, contendo poucas funcionalidades novas; 0 Receber feedback rapidamente; 0 No investir demais em algo incorreto, ou pior, que se revele no necessrio e no valorizado pelos usurios.
89
Prticas
Metforas
0 O objetivo abstrair os conceitos do mundo real; 0 Estabelecer um vocabulrio apropriado para o projeto; 0 Manter todos os desenvolvedores em sintonia com o projeto; 0 Auxilia a definir nomes a objetos ou classes;
Prticas
Projeto simples
0 O objetivo criar a soluo mais simples possvel, que seja suficiente para implementar as funcionalidades de cada iterao; 0 o oposto da ideia de projetar para o futuro. O objetivo concentrar os esforos da equipe naquilo que se tem certeza absoluta de que ser necessrio hoje;
90
Prticas
Testes
0 XP tem a preocupao em criar softwares saudveis, que funcionem corretamente e permaneam assim ao longo do tempo, medida que recebem novas funcionalidades e alteraes; 0 Os programadores devem primeiramente descrever os testes de unidade e o cliente descrever os testes funcionais, de forma que a confiana na funcionalidade possa se tornar parte do programa desenvolvido;
Prticas
Testes Testes de Unidade:
0 So considerados elementos chaves em XP, pois so criados antes do cdigo e armazenados em um repositrio junto ao cdigo que ser testado. 0 Um fator importante para a utilizao dos testes de unidade a economia;
91
Prticas
Testes
Testes Funcionais: 0 Constituem a primeira indicao que as estrias dos clientes so vlidas; 0 Normalmente, so escritos pelos clientes ou usurios finais atravs dos cartes de estria com suporte de um membro do time responsvel por testar o sistema. 0 Testes funcionais tambm so usados como testes de validao, anteriores liberao de uma verso do sistema.
Prticas
Refatorao
0 o processo de melhorar o projeto de um cdigo que j est funcionando. 0 Deve-se refatorar onde for possvel e sempre que possvel. 0 Reescrever o cdigo atual, parte por parte, fazendo com que ele fique cada vez mais manutenvel. 0 Tais alteraes no mudam o comportamento das funcionalidades, apenas melhoram a estrutura do cdigo. 0 Os testes de unidade oferecem segurana para o que o que j estava funcionando continue funcionando.
92
Prticas
Programao em pares
0 Custos: H na literatura estudos mostrando que a diminuio na
produtividade acompanhada por uma diminuio na quantidade de erros e falhas, levando a uma diminuio significativa no tempo de descobrimento e correo das falhas, de forma a compensar a diminuio de produtividade na fase de codificao.
codifica uma determinada tarefa, o navegador deve estar sempre pensando em estratgias e sugestes de codificao, assim como deve estar a todo o momento acompanhando o que o que est sendo digitado, alertando para possveis erros, assim como para codificaes fora do padro.
Prticas
Programao em pares
0 Benefcios: 0 Todas as decises envolvem duas pessoas; 0 H no mnimo duas pessoas responsveis pelo cdigo; 0 Troca de conhecimento; 0 Todo o cdigo revisado; 0 Cdigos mais simples e dentro dos padres; 0 Reduo do nmero de erros;
93
Prticas
Propriedade coletiva
0 Qualquer um pode mudar qualquer parte do cdigo; 0 Prtica que causa certo impacto e resistncia; 0 Todo cdigo alterado deve ser testado; 0 Todos so responsveis pelo cdigo;
Prticas
Integrao contnua
0 Quanto maior o perodo entre as integraes mais problemas surgiro; 0 Deve-se atualizar o repositrio em curtos intervalos de tempo ou a cada nova funcionalidade significante; 0 Testes realizados de forma automtica para permitir que erros sejam detectados, isolados e corrigidos prontamente;
94
Prticas
Semana de 40 horas
0 Horas trabalhadas no so diretamente proporcionais a produtividade; 0 Horas extras eventuais ou em um determinado perodo so tolerveis; 0 Necessidade constante indica falhas no plano de projeto e na estimao dos prazos;
Prticas
Cliente presente
0 O cliente parte da equipe de desenvolvimento; 0 Fundamental para facilitar o processo de feedback; 0 Na impossibilidade do cliente deve existir um proxy dentro da equipe, ou seja, um canal de comunicao;
95
Prticas
Padres de codificao
0 Dar ao cdigo um estilo consistente independente do autor; 0 Facilitar o entendimento entre do cdigo por todos que participam do projeto; 0 Pode-se seguir padres definidos por grandes empresas, porm todos devem estar de acordo;
Papis
Programador
0 Estimar prazos para estrias; 0 Construir cartes de tarefas; 0 Construir testes de unidade; 0 Implementar cdigo; 0 Realizar refatorao (refactoring);
96
Papis
Cliente
0 Escrever cartes de estria; 0 Definir escopos; 0 Trabalhar nos testes funcionais;
Papis
Testador
0 Trabalhar com cliente nos testes funcionais;
97
Papis
Supervisor
0 Coletar mtricas do projeto de duas a trs vezes por semana; 0 Tomar atitudes para que o projeto no entre em caminhos errados;
Papis
Treinador
0 Garantir que projeto seja extremo; 0 Ajudar no que for necessrio; 0 Manter a viso do projeto;
98
Papis
Gerente
0 Agendar reunies de planejamento; 0 Garantir fluncia das reunies; 0 Fazer ata das reunies; 0 Manter supervisor informado das decises das reunies; 0 Buscar recursos;
XP
Aspectos positivos
0 Boas ideias: 0 Viso centrada no comportamento dos envolvidos; 0 nfase na participao ativa do cliente; 0 nfase na comunicao dentro da equipe; 0 Acompanhamento mais prximo alimentado pelos feedbacks; 0 Anlise e projeto so simples; 0 Testes frequentes e intensivos;
99
XP
Aspectos negativos
0 A falta de uma fase de planejamento mais profunda dificulta a definio de contratos que envolvam custos e prazos;
0 XP difcil de ser aplicado: 0 Prticas excessivamente relacionadas; 0 Ausncia de um projeto mais detalhado: 0 Necessidade de mais refactorings no futuro; 0 Ausncia de ligao mais forte entre projeto e cdigo; 0 Foco no cdigo perigoso para softwares extensos;
Scrum
Caractersticas
0 Processo gil que visa permitir a entrega de pores prontas do software com frequncia quinzenal ou mensal; 0 O cliente determina as prioridades; 0 A equipe se auto organiza para atender estas prioridades da melhor forma; 0 Foi criado como um processo de desenvolvimento de produtos, no direcionado especificamente a desenvolvimento de software; 0 O termo scrum vem do rugby. Denota a unio da equipe que se move em conjunto em direo ao objetivo;
100
Scrum
Caractersticas
0 Equipes auto organizadas; 0 Requisitos so reunidos em uma lista conhecida como backlog do produto (Um backlog uma lista de itens priorizados); 0 Scrum no prescreve prticas de engenharia de software;
Scrum
Caractersticas
24h
30 dias
Backlog do produto
Backlog do sprint
Sprint
101
Scrum
Sprints
0 O progresso dos projetos que utilizam Scrum dado por meio de sprints;
0 Cada sprint dura de 2 a 4 semanas; 0 A durao dos diferentes sprints deve ser parecida, com o objetivo de imprimir ritmo equipe; 0 Durante um sprint o produto analisado, projetado, desenvolvido e testado; 0 Durante um sprint no podem ocorrer mudanas;
Scrum
Papis
0 Scrum master 0 Representa a gerncia do projeto; 0 Responsvel por garantir que os princpios do Scrum esto sendo seguidos; 0 Remove impedimentos; 0 Garante que o time est produzindo o mximo; 0 Garante colaborao entre todos os envolvidos no projeto; 0 Protege a equipe de interferncias exteriores;
102
Scrum
Papis
0 Time: 0 De 5 a 10 pessoas; 0 Tem pessoas com diferentes perfis: programadores, testadores, etc. 0 Membros devem estar presentes full-time; 0 As equipes so auto organizadas; 0 Trocas na equipe devem ser evitadas ao mximo durante os sprints;
Scrum
Reunies
0 Planejamento do Sprint : 0 O time seleciona um grupo de itens do backlog do produto que eles acreditam ser possvel completar dentro de um sprint;
0 Lembrar que no backlog do produto os itens possuem prioridades
Lista do trabalho a ser feito no projeto
definidas;
0 Criao do sprint backlog realizada pelo time. Eles estimam a durao de cada tarefa;
103
Scrum
Reunies
0 Scrum Dirio
0 Reunies dirias)
0 So realizadas em p; 0 Duram no mximo 15 minutos; 0 Ajudam a evitar reunies desnecessrias; 0 Todo mundo bem vindo, mas apenas time,
scrum master e proprietrio do produto (product owner) podem falar; 0 Trs perguntas so respondidas e cada membro do time se compromete com os outros: 0 O que voc fez ontem? 0 O que voc vai fazer hoje? 0 Est tudo OK?
Scrum Reunies
0 Reviso do Sprint : 0 Time apresenta o que foi desenvolvido durante o sprint; 0 Trabalhos incompletos no so apresentados; 0 Normalmente envolve uma demonstrao das novas funcionalidades ou modificaes na arquitetura do sistema; 0 uma apresentao informal e no deve levar mais que duas horas para ser preparada; 0 Toda a equipe participa;
104
Scrum Reunies
0 Retrospectiva do Sprint: 0 Reunio realizada depois do Sprint; 0 Dura de 15 a 30 minutos, em mdia; 0 Analisa o que est dando certo e o que no est dando certo; 0 Todo mundo participa:
0 Time; 0 Scrum master; 0 Proprietrio do produto (product owner); 0 Outros clientes e usurios finais;
Scrum Artefatos
0 Backlog do produto: 0 Conjunto de requisitos do software; 0 mantido pelo product owner; 0 Pode ser alterado desde que o item em questo no esteja presente no sprint atual; 0 Cada item do backlog do produto tem um valor especifico (prioridade) para o cliente;
105
Scrum Artefatos
0 Sprint backlog: 0 a parte do backlog do produto que vai ser trabalhada no prximo sprint; 0 Inclui uma interpretao que traduz os itens do backlog do produto em tarefas de desenvolvimento; 0 Cada membro da equipe escolhe o seu item; 0 Atualizao diria da estimativa de trabalho restante;
106