Capitulo_02 - Processos de Software.pptx

Apresentao do PowerPoint

Captulo 2

Processos de Software1Chapter 2 Software Processes 2011 Pearson Prentice Hall. Todos os direitos reservados.slide 1

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Tpicos apresentadosModelos de processo de software.

Atividades de processo.

Lidando com mudanas.

Rational Unified Process (RUP).

Um exemplo de um processo de desenvolvimento de software moderno. 2Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.O processo de softwareUm conjunto estruturado de atividades necessrias para desenvolver um sistema de software.

Existem vrios processos de desenvolvimento de software diferentes mas todos envolvem:

especificao definio do qu o sistema deve fazer;projeto e implementao definio da organizao do sistema e implementao do sistema;validao checagem de que o sistema faz o que o cliente deseja;evoluo evoluo em resposta a mudanas nas necessidades do cliente.

Um modelo de processo de desenvolvimento de software uma representao abstrata de um processo. Ele apresenta uma descrio do processo de uma perspectiva em particular.3Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Descries de processo de softwareQuando descrevemos e discutimos processos, geralmente falamos sobre as atividades desses processos, tais como especificao de modelo de dados, desenvolvimento de interface de usurio, etc. e organizao dessas atividades.

Descries de processos tambm podem incluir:

Produtos, que so os resultados de uma atividade do processo;

Papis, que refletem as responsabilidades das pessoas envolvidas no processo;

Pr e ps-condies, que so declaraes que so verdadeiras antes e depois de uma atividade do processo ser executada, ou um produto produzido. 4Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Processos dirigidos a planos e geisProcessos dirigidos a planos so processos em que todas as atividades do processo so planejadas com antecedncia e o progresso medido em relao a esse plano.

Nos processos geis o planejamento incremental e mais fcil modificar o processo para refletir alteraes nos requisitos do cliente.

Na realidade, os processos mais prticos incluem elementos dos processos geis e dirigidos a planos.

No existe processo de software certo ou errado.5Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Modelos de processo de softwareModelo Cascata Modelo dirigido a planos. Fases de especificao e desenvolvimento separadas e distintas.

Desenvolvimento Incremental Especificao, desenvolvimento e validao so intercaladas. Pode ser dirigido a planos ou gil.

Engenharia de software orientada a reso O sistema montado a partir de componentes j existentes. Pode ser dirigido a planos ou gil.

Na realidade a maioria dos grandes sistemas so desenvolvidos usando um processo que incorpora elementos de todos esses modelos.6Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.O modelo cascata

7Chapter 2 Software Processes

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Fases do modelo cascataExistem fases identificadas e separadas no modelo cascata:

Anlise e definio de requisitos

Projeto de sistema e software

Implementao e teste de unidade

Integrao e teste de sistema

Operao e manuteno

O principal inconveniente do modelo cascata a dificuldade de acomodao de mudanas depois que o processo j foi iniciado. Em princpio, uma fase precisa ser completada antes de se mover para a prxima fase.8Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Problemas do modelo cascata Diviso inflexvel do projeto em estgios distintos torna difcil responder s mudanas nos requisitos do cliente.

Por isso esse modelo s apropriado quando os requisitos so bem entendidos e as mudanas durante o processo de projeto sero limitadas.

Poucos sistemas de negcio possuem requisitos estveis.

O modelo cascata mais usado em projetos de engenharia de grandes sistemas onde o sistema desenvolvido em vrios locais.

Nessas circunstncias, a natureza do modelo cascata dirigida a planos ajuda a coordenar o trabalho. 9Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Desenvolvimento incremental


slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Benefcios do desenvolvimento incremental O custo para acomodar mudanas nos requisitos do cliente reduzido.

A quantidade de anlise e documentao que precisa ser feita bem menor do que o necessria no modelo cascata.

mais fcil obter feedback do cliente sobre o trabalho de desenvolvimento que tem sido feito.

Os clientes podem comentar demonstraes do software e ver quanto foi implementado.

Possibilidade de mais rapidez na entrega e implantao de software til para o cliente.

Os clientes podem usar e obter ganhos do software mais cedo do que possvel no processo cascata. 11Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Problemas do desenvolvimento incrementalO processo no visvel.

Gerentes precisam de entregas regulares para medir o progresso. Se os sistemas so desenvolvidos de forma rpida, no vivel do ponto de vista do custo produzir documentao para refletir todas as verses do sistema.

A estrutura do sistema tende a degradar conforme novos incrementos so adicionados.

A menos que tempo e dinheiro sejam gastos na reconstruo para melhorar o software, as mudanas regulares tendem a corromper a estrutura do sistema. A incorporao posterior de mudanas no software se torna progressivamente mais difcil e cara. 12Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Engenharia de software orientada a reso Baseada no reso sistemtico em que os sistemas so integrados com componentes existentes ou sistemas COTS (Commercial-off-the-shelf).

Estgios do processo:

Anlise de componentes; Modificao de requisitos;Projeto de sistema com reso;Desenvolvimento e integrao.

Atualmente, o reso a abordagem padro para a construo de vrios tipos de sistemas de negcio.

13Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.14Engenharia de software orientada a reso

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Tipos de componente de softwareWeb services que so desenvolvidos de acordo com padres de servio e ficam disponveis para chamada remota.

Colees de objetos que so desenvolvidas como um pacote para ser integrado com um framework como .NET ou J2EE.

Sistemas de software stand-alone (COTS) que so configurados para uso em ambientes especficos.


2011 Pearson Prentice Hall. Todos os direitos reservados.Atividades do processo Processos de software reais so sequncias intercaladas de atividades tcnicas, colaborativas e gerenciais com o objetivo geral de especificar, projetar, implementar e testar um sistema de software.

As quatro atividades de processo bsicas, especificao, desenvolvimento, validao e evoluo so organizadas de forma diferente em processos de desenvolvimento distintos.

No modelo cascata, elas so organizadas em sequncias, enquanto no desenvolvimento incremental so intercaladas. 16Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Especificaes de software O processo de estabelecer quais servios so necessrios e as restries na operao e desenvolvimento do sistema.

Processo de engenharia de requisitos

Estudo de viabilidade tcnica e financeiramente vivel construir o sistema?

Elicitao e anlise de requisitosO que os stakeholers do sistema precisam ou esperam do sistema?

Especificao de requisitosDefinio dos requisitos em detalhes.

Validao de requisitosVerificao da completude dos requisitos.17Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.O processo de engenharia de requisitos18Chapter 2 Software Processes

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Projeto e implementao de software O processo de converter a especificao de sistema em um sistema executvel.

Projeto de software

Design de uma estrutura de software que materialize a especificao;

Implementao

Transformar essa estrutura em um programa executvel;

As atividades de projeto e implementao so intimamente ligadas e podem ser intercaladas.19Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Modelo geral do processo de design20Chapter 2 Software Processes

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Atividades de projeto Projeto de arquitetura, em que voc identifica a estrutura geral do sistema, os componentes principais (as vezes chamados sub-sistemas ou mdulos), seus relacionamentos e como so distribudos.

Projeto de interface, em que voc define as interfaces entre os componentes do sistema.

Projeto de componente, em que voc projeta como cada componente do sistema ir operar separadamente.

Projeto de banco de dados, em que voc projeta as estruturas de dados do sistema e como essas sero representadas no banco de dados.


2011 Pearson Prentice Hall. Todos os direitos reservados.Validao de software Verificao e validao (V & V) serve para mostrar que o sistema est em conformidade com sua especificao e est de acordo com os requisitos do cliente.

Envolve processos de inspeo e reviso, e testes do sistema.

Testes do sistema envolvem executar o sistema com casos de teste. So provenientes de especificaes dos dados reais que devero ser processados pelo sistema.

O teste a atividade de V & V mais usada.22Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Estgios de teste


slide n

2011 Pearson Prentice Hall. Todos os direitos reservados. Teste de desenvolvimento ou de componente

Componentes individuais so testados independentemente; Componentes podem ser funes ou objetos , ou agrupamentos coerentes dessas entidades.

Teste de sistema

Teste do sistema como um todo. Teste de propriedades emergentes so particularmente importantes.

Teste de aceitao

Teste com dados do cliente para checar se o sistema est de acordo com as necessidades do cliente.24Chapter 2 Software ProcessesEstgios de teste

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Fases de teste em um processo de software dirigido a planos


slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Evoluo do softwareOs softwares so inerentemente flexveis e podem mudar.

Conforme os requisitos mudam, conforme mudam as circustncias do negcio, o software que d suporte ao negcio tambm deve evoluir e mudar.

Apesar de ter acontecido uma demarcao entre desenvolvimento e evoluo (manuteno) essa precisa se tornar cada vez mais irrelevante j que tem diminudo a quantidade de sistemas completamente novos.26Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.27Chapter 2 Software ProcessesEvoluo do sistema

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Pontos Importantes Os processos de software so as atividades envolvidas na produo de um sistema de software. Os modelos de processo de software so representaes abstratas desses processos.

Modelos de processo gerais descrevem a organizao dos processos de software. Exemplos desses processos gerais incluem o modelo 'cascata', desenvolvimento incremental e desenvolvimento orientado a reso.

A engenharia de requisitos o processo de desenvolver uma especificao de software.


2011 Pearson Prentice Hall. Todos os direitos reservados.Processos de projeto e implementao se preocupam em transformar uma especificao de requisitos em um sistema de software executvel.

A validao de software o processo de checar se o sistema est em conformidade com sua especificao e se esse est de acordo com as necessidades reais do usurio do sistema.

A evoluo de software ocorre quando voc altera sistemas de software existentes para adequ-los a novas necessidades. O software precisa evoluir para continuar til.

29Chapter 2 Software ProcessesPontos Importantesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Lidando com mudanas As mudanas so inevitveis em todos grandes projetos de software.

Mudanas no negcio levam a novos e diferentes requisitos de sistema.

Novas tecnologias abrem novas possibilidades para melhorar implementaes.

Mudanas de plataforma requerem mudanas na aplicao.

As mudanas geram retrabalho, o que faz com que o custo das mudanas inclua o retrabalho (p.ex. reanlise dos requisitos) assim como o custo de implementao de novas funes.30Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Reduzindo o custo de retrabalho Preveno de mudanas, quando o processo de software inclui atividades que podem antecipar possveis mudanas antes que o retrabalho se torne necessrio.

Por exemplo, um prottipo de sistema pode ser desenvolvido para mostrar algumas caractersticas fundamentais do sistema para os clientes.

Tolerncia a mudanas, quando o processo desenvolvido para que mudanas possam ser acomodadas a um custo relativamente baixo.

Geralmente envolve alguma forma de desenvolvimento incremental. As mudanas propostas podem ser implementadas em incrementos que ainda no foram desenvolvidos. Se isso impossvel, ento um incremento nico (uma pequena parte do sistema) pode ser alterada para incorporar a mudana.


2011 Pearson Prentice Hall. Todos os direitos reservados.Prototipao de software Um prottipo uma verso inicial de um sistema usada para demonstrar conceitos e testar opes de projeto.

Um prottipo pode ser usado:

No processo de engenharia de requisitos para ajudar na elicitao e validao de requisitos;

Nos processos de projeto para explorar opes e desenvolver um projeto de interface de usurio;

No processo de testes para executar testes fim-a-fim.32Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Benefcios da prototipaoMelhoria do uso do software.

Maior proximidade com as necessidades do usurio.

Melhorias na qualidade do projeto.

Maior manutenibilidade.

Reduzir esforos de desenvolvimento. 33Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.O processo de desenvolvimento de prottipo34Chapter 2 Software Processes

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Desenvolvimento de prottipos Pode ser baseado em linguagens ou ferramentas de prototipagem rpida.

Pode deixar a funcionalidade de fora do teste.

A prototipao deve focar em reas do produto que no so bem entendidas; A checagem de erros e recuperao podem no estar includas no prottipo;

O foco deve ser em requisitos funcionais ao invs de no funcionais como por exemplo, a confiabilidade e a segurana.Chapter 2 Software Processes35slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Descarte de prottiposOs prottipos devem ser descartados depois do desenvolvimento, pois no so uma boa base para um sistema em produo:

Pode ser impossvel ajustar o sistema para alcanar requisitos no funcionais;

Geralmente os prottipos no possuem documentao;

Geralmente a estrutura do prottipo degradada por mudanas rpidas;

Provavelmente o prottipo no ir alcanar os padres normais de qualidade organizacional.36Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Entrega incremental Ao invs de entregar o sistema em uma nica entrega, o desenvolvimento e a entrega so distribudos em incrementos, nos quais cada incremento entrega parte da funcionalidade necessria.

Os requisitos do usurio so priorizados e os requisitos de mais alta prioridade so includos nos primeiros incrementos.

Assim que o desenvolvimento de um incremento iniciado os requisitos so congelados, mas os requisitos dos incrementos posteriores podem continuar a evoluir.37Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Desenvolvimento e entrega incremental Desenvolvimento incremental

Desenvolve o sistema em incrementos e avalia cada incremento antes de proceder com o desenvolvimento do prximo incremento;

Abordagem normalmente usada em mtodos geis;

Avaliao feita por representantes do usurio/cliente.

Entrega incremental

Implanta um incremento para uso do usurio-final;

Avaliao mais realstica sobre o uso prtico do software;

Difcil de implementar para sistemas substitutos devido aos incrementos possurem menos funes do que o sistema que est sendo substituido.

Chapter 2 Software Processes38slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.39Chapter 2 Software ProcessesEntrega incremental

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Vantagens da entrega incrementalOs valores podem ser entregues ao cliente junto com cada incremento, e funes do sistema ficam disponveis mais rpidamente.

Primeiros incrementos agem como prottipos para ajudar a deduzir requisitos para incrementos posteriores.

Menor risco de falha geral do projeto.

Os servios mais prioritrios do sistema tendem a serem mais testados.40Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Problemas da entrega incremental A maioria dos sistemas requer um conjunto de funes bsicas que so usadas por diferentes partes do sistema.

Como os requisitos no so definidos em detalhes at que um incremento seja implementado, pode ser difcil identificar funes comuns que so necessrias a todos os incrementos.

A essncia dos processos iterativos que a especificao seja desenvolvida em conjunto com o software.

No entanto, essa pode entrar em conflito com o modelo de aquisio de muitas organizaes, nos quais a especificao completa do sistema parte do contrato de desenvolvimento do sistema.


2011 Pearson Prentice Hall. Todos os direitos reservados.Modelo espiral de BoehmO processo representado como uma espiral ao invs de uma sequncia de atividades com retornos.

Cada loop na espiral representa uma fase do processo.

No existem fases fixas como especificao ou projeto os loops na espiral so escolhidos de acordo com a necessidade.

Os riscos so avaliados explicitamente e resolvidos no decorrer do processo.42Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.O modelo de processo de software espiral de Boehm43Chapter 2 Software Processes

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Setores do modelo espiralDefinio de objetivosSo identificados os objetivos especficos para cada fase.

Avaliao e reduo de riscosOs riscos so avaliados e atividades executadas para reduzir os principais riscos.

Desenvolvimento e validaoUm modelo de desenvolvimento para o sistema escolhido, pode ser qualquer um dos modelos genricos.

PlanejamentoO projeto revisto e a prxima fase da espiral planejada.44Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Rational Unified Process (RUP) um processo genrico moderno, derivado do trabalho em UML e processos associados.

Rene aspectos dos 3 modelos genricos discutidos previamente.

Geralmente descrito por 3 perspectivas:

Uma perspectiva dinmica que mostra fases no tempo;

Uma perspectiva esttica que mostra atividades do processo;

Uma perspectiva prtica que sugere boas prticas.45Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Fases no Rational Unified Process46Chapter 2 Software Processes

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Fases do RUPConcepoEstabelece o business case para o sistema.

ElaboraoDesenvolve um entendimento da extenso do problema e da arquitetura do sistema.

ConstruoProjeta o sistema, programa e testa o sistema.

TransioImplanta o sistema no seu ambiente de operao.47Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Iterao do RUPIterao Intra-fase

Cada fase iterativa aos resultados desenvolvidos incrementalmente

Iterao Inter-fase

Como mostrado pelo loop no modelo RUP, o conjunto todo de fases pode ser executado incrementalmente.

Chapter 2 Software Processes48slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Workflows estticos no RUP49Chapter 2 Software Processes

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.50Chapter 2 Software ProcessesWorkflows estticos no RUP

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Boas prticas do RUPDesenvolver software iterativamente

Planejar incrementos baseando-se nas prioridades do cliente e entregar as de prioridade mais alta primeiro.

Gerenciar os requisitos

Documentar explicitamente os requisitos do cliente e manter registros de mudanas desses requisitos.

Usar arquiteturas baseadas em componentes

Organizar a arquitetura do sistema como um conjunto de componentes reusveis.51Chapter 2 Software Processesslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Modelar o software visualmente

Use modelos de grficos UML para representar vises dinmicas e estticas do software.

Verificar a qualidade do software

Garanta que o software atenda aos padres de qualidade organizacional.

Controlar as mudanas do software

Gerencie as mudanas no software usando um sistema de gerenciamento de mudanas e ferramentas de gerenciamento de configurao.Chapter 2 Software Processes52Boas prticas do RUPslide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Pontos Importantes Os processos devem incluir atividades para lidar com mudanas. O que pode envolver uma fase de protipao que ajuda a evitar ms escolhas nos requisitos e no projeto.

Os processos devem ser estruturados para evoluo e entrega iterativa, para que as mudanas possam ser feitas sem causar problemas ao sistema como um todo.

O Rational Unified Process um modelo de processo genrico moderno, organizado em fases (concepo, elaborao, construo e transio) mas que separa as atividades dessas fases (requisitos, anlise e projeto, etc.) .


2011 Pearson Prentice Hall. Todos os direitos reservados.

Documents

Capitulo_02 - Processos de Software.pptx