SlidesEduardoBezerra-Cap02

Princ

Princ

í

í

pios de An

pios de An

á

á

lise

lise

e Projeto de Sistemas

e Projeto de Sistemas

com UML

com UML

2

2

ª

ª

edi

edi

ç

ç

ão

ão

Eduardo Bezerra

Capítulo 2

Processo de Desenvolvimento de Software

“Quanto mais livros você leu (ou escreveu), mais as aulas você assistiu (ou lecionou), mais linguagens de programação você aprendeu (ou projetou), mais software OO você examinou (ou produziu), mais documentos de requisitos você tentou decifrar (ou tornou decifrável), mais padrões de

projeto você aprendeu (ou catalogou), mais reuniões você assistiu (ou conduziu), mais colegas de trabalho talentosos você teve (ou contratou), mais projetos você ajudou (ou gerenciou), tanto mais você estará equipado para lidar com um novo desenvolvimento.” - Bertrand Meyer

“Software is hard…”

• Porcentagem de projetos que terminam dentro do prazo

estimado: 10%

• Porcentagem de projetos que são descontinuados antes de

chegarem ao fim: 25%

• Porcentagem de projetos acima do custo esperado: 60%

• Atraso médio nos projetos: um ano.

Fonte: Chaos Report (1994)

Processo de desenvolvimento

• Tentativas de lidar com a complexidade e de minimizar os

problemas envolvidos no desenvolvimento de software

envolvem a definição de processos de desenvolvimento de

software.

• Um processo de desenvolvimento de software (PDS)

compreende todas as atividades necessárias para definir,

Processo de desenvolvimento

• Exemplos de processos de desenvolvimento existentes:

– ICONIX (Rastreabilidade dos Requisitos) – RUP (Rational Unified Process)

– EUP (Enterprise Unified Process)

• Extensão do RUP

– Manifesto Ágil (2001)

– Indivíduos e interações entre eles mais que processos e ferramentas; – Software em funcionamento mais que documentação abrangente; – Colaboração com o cliente mais que negociação de contratos; – Responder a mudanças mais que seguir um plano.

• XP (eXtreme Programming) • SCRUM

Processo de desenvolvimento

• Alguns objetivos de um processo de desenvolvimento são:

– Definir quais as atividades a serem executadas ao longo do projeto; – Definir quando, como e por quem tais atividades serão executadas; – Prover pontos de controle para verificar o andamento do

desenvolvimento;

– Padronizar a forma de desenvolver software em uma organização.

• Cuidado!

– NÃO EXISTE O MELHOR PROCESSO DE

DESENVOLVIMENTO, AQUELE QUE SE APLICA A TODAS AS SITUAÇÕES DE DESENVOLVIMENTO.

2.1 Atividades típicas de um PDS

Foco do livro

Atividades típicas de um PDS

• Levantamento de requisitos

• Análise de requisitos

• Projeto

• Implementação

• Testes

• Implantação

Atividades típicas de um PDS

• Levantamento de requisitos

– Compreensão do problema

– Entender o domínio que deve ser automatizado

• Objetivos

– Usuários e desenvolvedores tenham a mesma visão do problema a ser resolvido

• Requisito

– É uma condição ou capacidade que deve ser alcançada ou possuída por um sistema ou componente deste para satisfazer um contrato, padrão, especificação ou outros documentos formamente impostos (Maciaszek, 2000)

Atividades típicas de um PDS

• Requisitos Funcionais

– Definem as funcionalidades do sistema

– “São as declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações.”(Sommerville, 2007)

• “O Sistema deve permitir que um aluno realize a sua matrícula nas disciplinas oferecidas em um semestre letivo.”

• Requisitos não-funcionais

– Declaram as características de qualidade que o sistema deve possuir e que estão relacionadas às suas funcionalidades

– São restrições sobre os serviços ou as funções oferecidos pelo sistema

Atividades típicas de um PDS

• Análise

– “Quebrar” um sistema em seus componentes e estudar como tais

componentes interagem com o objetivo de entender como esse sistema funciona.

– Estudo detalhado dos requisitos elicitados e a construção de modelos

• É necessário saber o que o sistema proposto deve fazer para definir como esse sistema irá fazê-lo.

Atividades típicas de um PDS

• Projeto

– Como o sistema funcionará para atender os requisitos, de

acordo com os recursos tecnológicos existentes.

– Considera os aspectos físicos e dependentes de

implementação

• Arquitetura do sistema, padrão de interface gráfica, a linguagem de programação, o gerenciador de banco de dados, dentre outros

Atividades típicas de um PDS

– Projeto de Arquitetura

• Distribuir as classes de objetos relacionadas do sistema em subsistemas e seus componentes

– Diagrama de Implementação

– Projeto Detalhado

• São modeladas as colaborações entre os objetos de cada módulo com o objetivo de realizar as funcionalidades do módulo

• Projeto de Interface

• Projeto de Banco de Dados

• Diagramas de Classe, Diagramas de Casos de Uso, Diagrama de Interação, Diagrama de Estados e Diagrama de Atividades

Atividades típicas de um PDS

• Implementação

– O sistema é codificado

– Em um processo OO, a implementação envolve a criação do código-fonte correspondente às classes de objetos do sistema utilizando a linguagem de programação OO escolhida.

– Reuso: componentes, bibliotecas, padrões de software, frameworks, dentre outros.

Atividades típicas de um PDS

• Testes

– O processo de executar um programa com o objetivo de encontrar erros [Myers 2004];

– O processo de avaliar um sistema ou um componente de um sistema por meios manuais ou automáticos para verificar se ele satisfaz os requisitos especificados ou identificar diferenças entres resultados esperados e obtidos [Koscianski e Soares 2007];

– Uma atividade desempenhada para avaliar a qualidade do produto e melhorá-lo uma vez que identifica defeitos e problemas [IEEE 2004]; – O teste é uma técnica dinâmica de verificação e validação (V&V) que

envolve executar um programa com um conjunto de entrada de dados e verificar se está de acordo com o esperado

Atividades típicas de um PDS

– Verificação

• Verifica se o software está de acordo com suas especificações. – Estamos construindo o produto corretamente?

– Validação

• Checa se o software atende às expectativas do cliente – Estamos construindo o produto correto?

– Objetivos

• Demonstrar ao desenvolvedor e ao cliente que o software atende aos requisitos

• Descobrir falhas ou defeitos no software que apresenta

comportamento incorreto, não desejável ou em não conformidade com a sua especificação

– Os testes podem somente mostrar a presença de erros, não sua ausência.” (Dijkstra et al., 1972)

Atividades típicas de um PDS

• Implantação

– Sistema é empacotado, distribuído e instalado no ambiente do usuário – Manuais são escritos

– Dados são importados para o sistema – Treinamento de usuários

Participantes do processo

• Gerentes de projeto

• Analistas

• Projetistas

• Arquitetos de software

• Programadores

• Clientes

• Avaliadores de qualidade

Participação do usuário

• A participação do usuário durante o desenvolvimento de

um sistema extremamente é importante.

Modelo de ciclo de vida

• Um ciclo de vida corresponde a um encadeamento específico

das fases para construção de um sistema.

• Dois modelos de ciclo de vida:

– modelo em cascata

– modelo iterativo e incremental

• Desenvolvimento evolucionário

– Especificação e desenvolvimento são entrelaçados

• Desenvolvimento Formal de sistemas

– Um modelo de sistema matemático é formalmente transformado para uma implementação

Modelo em cascata

• Esse modelo apresenta uma tendência para a progressão

seqüencial entre uma fase e a seguinte.

Modelo em cascata

• Projetos reais raramente seguem um fluxo seqüencial.

• Assume que é possível declarar detalhadamente todos os

requisitos antes do início das demais fases do

desenvolvimento.

– propagação de erros pelas as fases do processo.

– isto faz com que seja difícil responder aos requisitos mutáveis

dos clientes

• Portanto, este modelo só é apropriado quando os requisitos

são bem compreendidos, e quando as mudanças forem

bastante limitadas durante o desenvolvimento do sistema.

• Uma versão de produção do sistema não estará pronta até

Modelo de iterativo e incremental

• Divide o desenvolvimento de um produto de software em ciclos.

– Ao invés de entregar o sistema de uma única vez, o desenvolvimento e a entrega é dividida em incrementos com cada incremento

entregando parte da funcionalidade requerida.

• Cada ciclo considera um subconjunto de requisitos

– Os requisitos dos usuários são priorizados e os requisitos de maior prioridade são incluídos em incrementos iniciais.

– Esta característica contrasta com a abordagem clássica, na qual as fases são realizadas uma única vez.

– Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são congelados embora requisitos para incrementos posteriores possam continuar a evoluir

– Podem ser identificadas as fases de análise, projeto, implementação e testes.

Modelo iterativo e incremental

Modelo iterativo e incremental

• Iterativo: o sistema de software é desenvolvido em vários

passos similares.

• Incremental: Em cada passo, o sistema é estendido com

mais funcionalidades.

Modelo iterativo e incremental – vantagens

e desvantagens

O valor agregado ao Cliente está na entrega em cada incremento

de modo que a funcionalidade do sistema estará disponível mais

cedo

Incentiva a participação do usuário.

Riscos do desenvolvimento podem ser mais bem gerenciados.

– Um risco de projeto é a possibilidade de ocorrência de algum

evento que cause prejuízo ao processo de desenvolvimento,

juntamente com as conseqüências desse prejuízo.

– Influências: custos do projeto,cronograma, qualidade do

produto, satisfação do cliente, etc.

Ataque os riscos

• “Se você não atacar os riscos [do projeto] ativamente, então

estes irão ativamente atacar você.” (Tom Gilb).

– A maioria dos PDS que seguem o modelo iterativo e incremental aconselha que as partes mais arriscadas sejam consideradas inicialmente.

Riscos não gerenciados

Desenvolvimento evolucionário

• Desenvolvimento exploratório

– O objetivo é trabalhar com clientes e evoluir o sistema final de um esboço de especificação inicial. Deve começar com os requisitos que estão bem entendidos

• Preparação de protótipos descartáveis (throwaway)

– Prototipagem

• Objetivo é entender os requisitos do sistema. Deve começar com requisitos pobremente entendidos

Desenvolvimento evolucionário

Desenvolvimento evolucionário

• Problemas

– Falta de visibilidade do processo

– Sistemas são, em geral, pobremente estruturados

– Habilidades especiais (ex. em línguas para rápida preparação de protótipos ) podem ser requeridas

• Aplicabilidade

– Para sistemas interativos pequenos ou médios

– Para partes de sistemas grandes (ex. a interface de usuário) – Para sistemas de curto-prazo

Prototipagem

• A prototipagem é uma técnica aplicada quando:

– há dificuldades no entendimento dos requisitos do sistema – há requisitos que precisam ser mais bem entendidos.

• A construção de protótipos utiliza ambientes com facilidades

para a construção da interface gráfica.

• Procedimento geral da prototipagem:

– Após o LR, um protótipo é construído para ser usado na validação. – Usuários fazem críticas...

– O protótipo é então corrigido ou refinado

– O processo de revisão e refinamento continua até que o protótipo seja aceito.

– Após a aceitação, o protótipo é descartado ou utilizado como uma versão inicial do sistema.

Prototipagem

• Note que a prototipagem NÃO é um substituto à construção

de modelos do sistema.

– A prototipagem é uma técnica complementar à construção dos

modelos do sistema.

– Mesmo com o uso de protótipos, os modelos do sistema devem

ser construídos.

– Os erros detectados na validação do protótipo devem ser

utilizados para modificar e refinar os modelos do sistema.

Incremental x Prototipagem

• Desenvolvimento Incremental

– Entregar um sistema de trabalho aos usuários finais

– Requisitos mais bem compreendidos e com prioridade alta

– Requisitos vagos e com baixa prioridade serão implementados quando e se os usuários solicitarem

• Prototipagem throwaway

– Validar ou derivar os requisitos do sistema – Requisitos que não são bem compreendidos

Desenvolvimento espiral

• Processo é representado como uma espiral ao invés de uma seqüência de atividades com retorno

• Cada volta na espiral representa uma fase no processo.

• Não existem fases fixas como especificação ou projeto – as voltas na espiral são escolhidas de acordo com o que é requerido

Modelo espiral do processo de software

Prototype 3 Opera-_tional protoype

Concept of Operation

Simulations, models, benchmarks S/W requirements Requirement validation Design V&V Product design Detailed design Code Unit test Integration test Acceptance Evaluate alternatives identify, resolve risks Determine objectives

alternatives and constraints

Plan next phase

Integration and test plan Development

plan Requirements plan

Life-cycle plan REVIEW

Setores do modelo espiral

• Estabelecimento de objetivos

– Objetivos específicos para a fase são identificados

• Avaliação e redução de riscos

– Os riscos são avaliados e atividades postas em prática para reduzir os riscos principias

• Desenvolvimento e validação

– Um modelo de desenvolvimento para o sistema é escolhido, podendo ser qualquer um dos modelos genéricos

• Planejamento

Desenvolvimento de sistemas formais

• Baseado na transformação de uma especificação matemática

através de diferentes representações para um programa

executável

• Transformações são ‘preservadoras de exatidão’, portanto, são

diretas para mostrar que o programa está de acordo com sua

especificação

• Contido na abordagem ‘Cleanroom’ para desenvolvimento de

software

Desenvolvimento de sistemas formais

Requirements

definition _{specification}Formal

Formal transformation

Integration and system testing

Transformações Formais

Proofs of transformation correctness Formal transformations

R1

Desenvolvimento de sistemas formais

• Problemas

– Necessidade de habilidades especializadas e treinamento para aplicar a técnica

– Difícil de especificar formalmente alguns aspectos do sistema como a interface de usuário

• Aplicabilidade

– Sistemas críticos, especialmente aqueles no qual um case de segurança deve ser feito antes do sistema ser posto em operação

Desenvolvimento orientado ao reuso

• Baseado no reuso sistemático, onde os sistemas são integrados de componentes existentes ou sistemas padronizados

• Estágios do Processo

– Análise do componente – Modificação dos requisitos – Projeto do sistema com reuso – Desenvolvimento e integração

• Esta abordagem está se tornando mais importante, mas a experiência ainda é limitada com ela

Desenvolvimento orientado ao reuso

Programação extrema - eXtreme

Programming (XP)

• Nova abordagem para o desenvolvimento de software baseado

no desenvolvimento e entrega de incrementos de

funcionalidade bem pequenos

• Conta com melhoramento constante do código, envolvimento

do usuário no time de desenvolvimento e programação em

pares

Bibliografia Complementar

• Ian Sommerville. Engenharia de Software. 8ª edição, 2007.

– Capítulo 4: Processos de Software

– Capítulo 17: Desenvolvimento Rápido de Software

• Métodos Ágeis

• Extreme Programming • Prototipação de Software