ProcessosDesenvolvimentoCicloDeVida

Processo de Desenvolvimento e Ciclo de Vida de Software

Sabrina de Figueirêdo Souto

Centro de Ciências e Tecnologia Departamento de Computação

Agenda

•  Processo •  Processo x Ciclo de Vida •  A2vidades Fundamentais •  Modelos de Processo de So:ware •  Descrição de Processos de So:ware •  Categorias Gerais de Processos de So:ware •  Considerações Finais

2

Processo

•  Definições

– Sucessão de estados ou de mudanças. Modo por que se realiza ou executa uma coisa; método; técnica [Dicionário Aurélio]

– Uma ação regular e conInua (ou sucessão de ações) realizada de forma bem definida, levando a um resultado [Oxford English Dic7onary]

– Define quem está fazendo o que, quando e como para a2ngir um certo obje2vo [Jacobson, Booch, Rumbaugh]

3

Processo de So:ware

•  Um processo de so:ware é um conjunto de a2vidades relacionadas que levam à produção de um produto de so:ware [Sommerville]

•  Conjunto de a0vidades, métodos, prá0cas e tecnologias que as pessoas u2lizam para desenvolver e manter so:ware e produtos relacionados

4

Processo x Ciclo de Vida IEEE Std 610.12

5

Processo x Ciclo de Vida

•  Na prá2ca – O termo CICLO evoluiu para PROCESSO – São usados como sinônimos

•  Com uma diferença – Atualmente, o processo não se encerra com a entrega do produto de so:ware

•  Evolução/Manutenção

6

Processo de So:ware

•  Melhores pessoas •  Inves2mento em tecnologia •  Sem processos claros e eficientes, uma empresa não é escalável

7

Processo de So:ware

•  O interesse no processo de so:ware está baseado em duas premissas:

–  A qualidade de um produto de so:ware é fortemente dependente da qualidade do processo pelo qual ele é construído e man2do

–  O processo de so:ware pode ser definido, gerenciado, medido e melhorado

Um processo definido deve estar descrito em detalhes de forma a poder ser usado de forma consistente!

8

Processos de So:ware •  O número de bugs presentes no so:ware quando entregue para testes é função direta da qualidade do processo usado para a construção do so:ware

Um bom processo pode evitar a presença de bugs no produto! 9

A2vidades Fundamentais •  Especificação de requisitos

•  Projeto e implementação

•  Verificação e validação

•  Evolução 10

Especificação de So:ware

11

Especificação de So:ware •  Define quais serviços são necessários •  Iden2fica as restrições de operação e de desenvolvimento

•  Processo de Engenharia de Requisitos

12

Projeto e Implementação de So:ware

13

Verificação e Validação

•  Verificação e validação (V & V) têm a intenção de mostrar que um sistema está em conformidade com a sua especificação e que atende aos requisitos do cliente –  Verificação: “construímos o sistema corretamente?”

•  Exemplos: inspeções e revisões de código, análise está2ca, testes

–  Validação: “construímos o sistema correto?” •  Exemplos: testes, proto2pagem dos requisitos

14

Verificação e Validação •  Os defeitos normalmente são introduzidos na transformação

de informações entre as diferentes fases do ciclo de desenvolvimento de um so:ware

•  Necessidade de realizar testes em diferentes níveis –  visando avaliar o so:ware em diferentes perspec2vas de acordo com

o produto gerado em cada fase do ciclo de vida de desenvolvimento de um so:ware.

15

Evolução de So:ware

•  O so:ware é inerentemente flexível e pode mudar •  Requisitos mudam devido a diversos fatores e o so:ware deve acompanhar essas mudanças

•  A evolução se deve a diversas razões:

16

Evolução de So:ware

•  Processo:

17

Modelos de Processo de So:ware

•  Representação simplificada de um processo de so:ware

•  Representa uma perspec2va par2cular de um processo à informações parciais

•  Abstrações que podem ser usadas para explicar diferentes abordagens de desenvolvimento

•  Podem ser ampliados e adaptados para criar processos mais específicos

18

Modelos de Processo de So:ware

•  Modelos abordados: – Cascata – Engenharia de Sofware orientada a reúso – Modelos Evolucionários

•  Proto2pação •  Processos itera2vos

–  Entrega/Desenvolvimento Incremental – Modelo Espiral de Boehm

19

Constrói e Conserta •  O produto é construído sem qualquer especificação ou projeto

•  O produto é retrabalhado quantas vezes for necessário para sa2sfazer o cliente

•  Este modelo pode funcionar razoavelmente para micro projetos –  Inadequado para projetos maiores

20

Cascata

Requisitos

Projeto

Implementação

Testes

Implantação

Documentação

Documentação

Documentação

Documentação

21

Engenharia de So:ware Orientada a Reúso

•  Reúso acidental x Reúso planejado •  Baseado em reuso sistemá2co onde sistemas são integrados a

par2r de componentes existentes ou de sistemas completos COTS (Commercial-‐of-‐the-‐shelf)

•  Depende de uma base de componentes reusáveis e de um framework de integração para a composição desses componentes

•  Processo geral:

22

Modelos Evolucionários

•  Requisitos mudam •  Mudanças podem implicar em

– Aumento dos custos de desenvolvimento – Retrabalho

•  O processo precisa acomodar mudanças: – Proto2pação – Processos Itera2vos

•  Entrega/Desenvolvimento Incremental •  Modelo Espiral

23

Proto2pação

•  Protó2po – Versão inicial de um sistema, usado para demonstrar conceitos, experimentar opções de projeto e descobrir mais sobre o problema e suas possíveis soluções

•  Processo

24

Processos Itera2vos

•  Requisitos de sistema SEMPRE evoluem no curso de um projeto

•  Algum retrabalho é necessário •  Desenvolvimento em ciclos •  A abordagem itera0va pode ser aplicada a qualquer um dos modelos genéricos de processo

•  Duas abordagens (relacionadas) –  Entrega incremental –  Desenvolvimento espiral

•  Essência: especificação desenvolvida em conjunto com o so:ware

25

Entrega/Desenvolvimento Incremental

•  Desenvolver uma implementação inicial •  Expôr aos comentários dos usuários •  Con2nuar por meio da criação de várias versões até que um

sistema adequado seja desenvolvido •  A2vidades de especificação, desenvolvimento e validação são

intercaladas, com rápido feedback entre todas as a2vidades

26


•  O sistema é entregue ao cliente em incrementos •  Os requisitos são priorizados •  Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são congelados –  Os requisitos para os incrementos posteriores podem con2nuar evoluindo (e incluir requisitos já implementados!)

27


•  Vantagens – Custo de acomodar mudanças nos requisitos do cliente é reduzido

– Rápido feedback dos clientes – Entrega e implementação rápida

•  Desvantagens – O processo não é visível – A estrutura do sistema tende a se degradar com a adição de novos incrementos

28

Modelo Espiral de Boehm

•  O processo é representado como uma espiral –  Cada loop na espiral representa uma fase no processo –  Sem fases definidas, tais como especificação ou projeto –  Os riscos são explicitamente avaliados e resolvidos ao longo do processo

29

Descrição de Processo

•  As descrições de processo podem incluir: – Produtos à resultados das a2vidades – Papéis à responsabilidades dos envolvidos – Pré e Pós condições à declarações verdadeiras antes e depois de a2vidades

•  Os processos são complexos •  Os processos dependem de pessoas •  Não existe um processo ideal!!!

30

Categorias Gerais de Processos

•  Os processos costumam ser categorizados como: –  Tradicionais (Dirigidos à Planos)

•  Ra2onal Unified Process (RUP) –  Ágeis

•  Extreme Programming (XP), SCRUM, KANBAM, etc.

31

Processos Tradicionais

•  Meados da década de 80 –  Consenso: processo tradicional

– Rigoroso e controlado – Comunidade de engenharia de so:ware – Sistemas grandes e duradouros (aeroespaciais e do governo)

–  Sistema de controle de aeronave à 10 anos – Grandes equipes, dispersas geograficamente – Processos pesados à grande quan2dade de documentação – Pouca ou nenhuma interação com o cliente durante o desenvolvimento à dificultando mudanças nos requisitos

•  Exemplo: Ra2onal Unified Process (RUP)

32

Ra2onal Unified Process (RUP)

•  Procura disciplinar atribuições de tarefas e responsabilidades dentro de uma estrutura de desenvolvimento de so:ware

•  Meta principal –  garan2r a produção de so:ware com alta qualidade sa2sfazendo as necessidades dos seus usuários, dentro de um cronograma e orçamento previsível

33


•  Processo híbrido •  Caracterís2cas de modelos de processo genéricos:

–  Boas prá2cas na especificação e no projeto –  Apoia a proto2pação e entrega incremental

•  Modelo moderno baseado em UML –  Tenta cobrir todos os aspectos do desenvolvimento de so:ware

•  Fortemente focado na documentação do sistema

34

Ra2onal Unified Process (RUP) •  Descrito em 3 perspec2vas

–  Dinâmica à fases ao longo do tempo –  Está0ca à a2vidades realizadas no processo –  Prá0ca à boas prá2cas

•  Visão geral

35


PERSPECTIVA DINÂMICA •  As fases cons2tuem os ciclos de vida do so:ware, sendo cada ciclo responsável por uma versão nova do produto –  Concepção (Incep2on)

•  Estabelecer o business case para o sistema

–  Elaboração (Elabora2on) •  Desenvolver um entendimento do domínio do problema, arquitetura do sistema e iden2ficar riscos

–  Construção (Construc2on) •  Projeto, programação, teste de sistema e documentação

–  Transição (Transi2on) •  Implantar o sistema no seu ambiente operacional

36

Ra2onal Unified Process (RUP) PERSPECTIVA ESTÁTICA •  Papéis/Equipe (quem está fazendo o que) •  Artefatos (o que é produzido) •  A2vidades (como o trabalho é conduzido) •  Workflow (quando à prioriza a2vidades)

37


PERSPECTIVA PRÁTICA •  Descreve boas prá2cas recomendadas •  Desenvolver o so:ware itera2vamente •  Gerenciar requisitos •  Usar arquiteturas baseadas em componentes •  Modelar o so:ware visualmente •  Verificar a qualidade de so:ware •  Controlar as mudanças do so:ware

38

Referências

•  [1] Sommerville, I. So:ware Engineering (9th ed.). Addison-‐Wesley, 2010.

•  [2] Pressman, R. So:ware Engineering: A Prac22oner’s Approach (7th ed.). McGraw-‐Hill Science/Engineering/Math, 2009.

•  [3] IEEE Standard Glossary of So:ware Engineering Terminology, Standard 610.12.

•  [4] Sbrocco, J. H. T. C., Macedo, P. C. Metodologias Ágeis -‐ Engenharia de So:ware sob Medida. Editora Érica, 2012.

39

Processo de Desenvolvimento e Ciclo de Vida de Software

Candidato(a): Sabrina de Figueirêdo Souto

Centro de Ciências e Tecnologia Departamento de Computação

ProcessosDesenvolvimentoCicloDeVida

Documents

Transcript of ProcessosDesenvolvimentoCicloDeVida