QS 2 Processos Software

(1)

Processos de Desenvolvimento de Software

Prof. Davi Viana dos Santos

Gestão da Qualidade de Software

Baseado em:

(1) Material cedido pela Profa. Tayana Conte (2) Notas de aula/mini-cursos do Prof. Rafael Prikladnicki

• Processos de Software

– Processos Tradicionais (Breve revisão)

– Processos Ágeis

• Métodos Ágeis

– Definições

– 5 motivos para não usar métodos ágeis

(2)

Erro comum: olhar para software como apenas um desses itens

e ignorar os demais

(Gabriel)

Arte

(Knuth)

Artesanato

(Cockburn)

Poesia

(Humphreys)

Disciplina

(Meyer)

Engenharia

(Jacobson)

Modelagem

Por Alistair Cockburn:

O que é Desenvolvimento de Software?

Cukier, D. Prikladnicki , R. “Introdução a Métodos Ágeis de Desenvolvimento de Software” Mini-Curso: I Congresso Brasileiro de Software: Teoria e Prática (CBSoft 2010). 2010

• Conceito

– “Conjunto de atividades, métodos e práticas utilizadas

na produção e desenvolvimento de Software”

[HUMPHREY et al., 1989]

Processo de Software

Requisitos

do Usuário _Software

(3)

Atividades Problema Solução

Analogia:

Construção de um Prédio

Construção de Software

Atividades Problema Solução dados relatórios restrições procedimentos

Software

(4)

• Outro Conceito

– “Conjunto de passos de processos parcialmente

ordenados, relacionados com conjunto de artefatos,

pessoas, recursos, estruturas organizacionais e

restrições e tem como objetivo produzir e manter

software”

[LIMA, 1997]

Processo de Software

1 2 3 5 4 6 7

Componentes do Processo de Software

• Atividades: o que é feito

– Formam o conjunto dos passos ordenados

– Podem ser compostas por sub-atividades e conter tarefas

– Para cada atividade:

• Recursos

• Artefatos

• Restrições

(5)

Componentes do Processo de Software

• Artefatos: Consumidos e produzidos pelas

atividades

– Produtos de Entrada

– Produtos de Saída

• Recursos: Alocados para a realização da atividade

– Cargo/papel: Responsável pela atividade

– Ferramentas: Utilizados durante a atividade

Componentes do Processo de Software

• Restrições: Condição que uma atividade deve

satisfazer antes ou depois de ser executada

– Podem atingir atividades, recursos, artefatos e seus

relacionamentos

• Projeto: Instância de um processo, com objetivos e

restrições específicos

(6)

Processo de Software

• Definições (Sommerville)

– Processo de Software

• Conjuntos de atividades para especificação, projeto,

implementação e teste de sistemas de software

– Modelo de Processo de Software

• Um modelo de processo de software é uma

representação abstrata de um processo. Apresenta a

descrição de um processo a partir de uma perspectiva

particular.

Processo de Software

• Modelo e Processo de Software

Processo de Software:

o que acontece na realidade

Modelo de Processo de

Software:

representação abstrata de como proceder ou do que ocorreu em um processo

(7)

Modelo de Processo de SW

Atividade

recursos produtos de entrada produtos de saída restrições

Exemplo de Atividade de um Modelo de

Processo

Nome:“1.1 - Coleta de Requisitos”

Descrição: “Levantamento de informações com Usuários”

Artefatos:

Entrada: {documento de solicitação } Saída: {atas de entrevistas, documentos

Relacionados, registros de ações} Recursos:

Cargos: {Analistas}

Ferramentas: {editor, sala de reunião, Estação X}

Atividades Anteriores: {} Restrições:

Pré-Condição: {Disponibilidade dos usuários} PósCondição:

(8)

-Projeto executando um Processo de SW

Atividade

prazos agentes e cargos ferramentas recursos produtos de entrada produtos de saída restrições

Exemplo de Projeto

Nome:“1.1 - Coleta de Requisitos” Descrição: “Levantamento de informações com Usuários”

Artefatos:

Entrada: {documento de solicitação } Saída: {atas de entrevistas, documentos

Relacionados, registros de ações} Recursos:

Cargos: {Analistas}

Agentes: (Carlos, Mônica)

Ferramentas: {editor, sala de reunião, Estação X}

Atividades Anteriores: {} Restrições:

Pré-Condição: {Disponibilidade dos usuários} PósCondição:

-Cronograma:

Previsão: (05/02 a 17/02/2012) Andamento: (-)

(9)

1

2

3

4

5

1.1 1.2 1.3 1.4 1.5 2.1 2.3 2.2 2.4 3.1 3.3 3.2 4.1 4.2 4.3 4.4 5.1 5.2 doc_análise

doc_projetocódigo doc_confiab.

Repositório

Descrição do processo de desenvolvimento de software

Exemplo de Execução de um Projeto

Gerenciador de objetos cooperativos Agenda: 1.1 Coleta de requisitos -terminada 1.2 Estudo de viabilidade -ativa ... Agenda: 1.1 Coleta de requisitos -terminada 1.2 Estudo de viabilidade -pausa ... Gerenciador de execução do processo Gerente de projetos terminada ativa esperando

• Gerência dos projetos integrada com

desenvolvimento - Resposta às questões:

– Qual o estado atual do projeto?

– Quais atividades foram atribuídas a quem?

– Quais documentos existem?

– Quais versões existem?

– O projeto ainda está no cronograma?

• Suporte à melhoria do processo

• Facilidade de comunicação entre desenvolvedores

Benefícios da Gerência de Processos de

Software

(10)

Processo de Software

• Paradoxo:

– Para todos os programas construídos há a necessidade de

se entender os requisitos e o processo de negócio do

contratante

– Na grande maioria das situações não há documentação de

como a organização de desenvolvimento de software vai

agir para atender a requisição

– Se a organização não sabe nem como trabalha, como

vai descrever soluções para terceiros?

(11)

Exemplo de Atividade em Processo SW

Nome Identificar/Entender Requisitos do Cliente e Requisitos do

Software

Descrição Identificar/entender os requisitos do cliente e requisitos

funcionais e não-funcionais do software. A

identificação/entendimento dos requisitos deve ser realizada através de reuniões com o cliente.

Os requisitos funcionais do software devem ser identificados considerando que cada requisito será especificado através de um caso de uso. O diagrama de casos de uso também deve ser elaborado nesta atividade e documentado no documento de Levantamento de Requisitos e Modelo de Análise e Projeto. As atas de reunião de identificação/entendimento dos requisitos devem ser registradas.

Caso a identificação dos requisitos tenha sido realizado previamente, um aprofundamento dos requisitos que fazem parte do escopo do projeto deve ser realizado nesta atividade.

Critérios de Entrada Sempre que houver necessidade de se executar um ou mais ciclos de desenvolvimento para geração de um produto.

Critérios de Saída Levantamento de Requisitos elaborado.

Exemplo de Atividade em Processo SW

Nome Identificar/Entender Requisitos do Cliente e Requisitos do

Software

Descrição Identificar/entender os requisitos do cliente e requisitos funcionais e não-funcionais do software...

Critérios de Entrada

Sempre que houver necessidade de se executar um ou mais ciclos de desenvolvimento para geração de um produto.

Critérios de Saída

Levantamento de Requisitos elaborado. Responsáveis Analista de Sistemas

Participantes Cliente Pré-atividade -Artefatos Requeridos

Solicitação de Serviço; Levantamento Requisitos; Proposta de Desenvolvimento; Proposta Técnica e Comercial;

Artefatos Gerados

Levantamento de Requisitos; Modelo de Análise e Projeto; Ata de reunião;

(12)

Exercício: completando a Atividade 

Nome Planejar Processo

Descrição Definir o plano do processo para o novo projeto a partir do processo padrão da organização, identificando todas as atividades a serem executadas e definindo o ciclo-de-vida do projeto, de acordo com as características do projeto, seu escopo e requisitos do cliente e do software. Para cada requisito funcional do software identificado devem ser planejadas atividades relacionadas à especificação de requisitos do software, especificação de testes dos requisitos do software, elaboração do modelo de análise e projeto, especificação dos testes de integração, implementação e execução dos testes dos requisitos do software, integração e testes do software, de forma a contemplar todas as atividades e sub-atividades previstas no processo de desenvolvimento. Se pertinente, o plano do processo deve também conter sub-atividades para os requisitos não-funcionais.

A Estrutura Analítica do Projeto (EAP) deve ser gerada contendo o agrupamento dos componentes do projeto orientados a resultados práticos de forma a organizar e definir o escopo total do projeto. O trabalho não incluído na EAP está fora do escopo do projeto. A EAP é a base para estimar o prazo e esforço do projeto.

Escopo e requisitos do cliente e do software identificados. Critérios de Saída Plano do processo planejado.

Exercício: completando a Atividade 

Descrição Definir o plano do processo para o novo projeto a partir do processo padrão da organização, identificando todas as atividades a serem executadas e definindo o ciclo-de-vida do projeto, de acordo com as características do projeto, seu escopo e requisitos do cliente e do software...

Escopo e requisitos do cliente e do software identificados. Critérios de

Saída

Plano do processo planejado.

Responsáveis ??? Participantes ??? Pré-atividade ??? Artefatos Requeridos ??? Artefatos Gerados ??? Ferramentas ???

(13)

Exercício: completando a Atividade 

Descrição Definir o plano do processo para o novo projeto a partir do processo padrão da organização, identificando todas as atividades a serem executadas e definindo o ciclo-de-vida do projeto, de acordo com as características do projeto, seu escopo e requisitos do cliente e do software...

Escopo e requisitos do cliente e do software identificados. Critérios de

Saída

Plano do processo planejado. Responsáveis Gerente do Projeto

Participantes

-Pré-atividade Identificar/Entender Requisitos do Cliente e Requisitos do Software

Artefatos Requeridos

Escopo do Projeto; Levantamento de Requisitos Artefatos

Gerados

Plano do Processo; Estrutura Analítica do Projeto; Justificativas das Alterações no Processo Padrão

Ferramentas AdaptPro; MS Word

• Diversas

metodologias

foram

criadas

para

sistematizar o processo de desenvolvimento de

software

– Tradicionais: focam na documentação de cada passo do

processo de desenvolvimento

– Ágeis: novo paradigma e prometem melhorar a

produção e qualidade

(14)

• Muitas organizações desenvolvem software sem

usar nenhum processo

– Processos tradicionais não são adequados às suas

realidades

• PME podem não ter recursos suficientes para adotar

o uso de metodologias grandes

• Desvantagens:

– Pode gerar produtos de baixa qualidade

– Dificulta a entrega do software nos prazos e custos

predefinidos

– Inviabiliza futuras evoluções

Processos de Software

27 Processos de Sofware

• Metodologias tradicionais

– Orientadas a documentação

– Ciclos de vida tradicionais

– Surgiram em um contexto de desenvolvimento muito

diferente do atual

• O custo era muito alto

• Acesso a computadores era limitado

• Não

existiam

ferramentas

de

apoio

ao

desenvolvimento

– Por isso era o software era todo planejado e

documentado antes de ser implementado

Processos de Software

(15)

• Relembrando...

• Modelos de ciclo de vida

– Modelo Cascata ou Sequencial

– Modelo V

– Prototipagem

– Incremental

– Ciclo de Vida em Espiral

Processos de Software

• Exemplos

– Modelo Cascata

Processos de Software

Análise de requisitos Projeto Testes Codificação Engenharia de sistemas Implantação/ Manutenção

(16)

• Exemplos

– Modelo V

Processos de Software

31 Processos de Sofware Análise de Requisitos Projeto do Sistema

Projeto dos Programas

Codificação

Teste de Unidade e Integração Teste de Sistema Teste de Aceitação Entrega e Manutenção Verifica código Verifica projeto Valida requisitos

• Exemplos

– Ciclo Protótipo Descartável

Processos de Software

Obtenção de requisitos e refinamento Projeto rápido Cons trução do protótipo Avaliação do Cliente Refinamento do protótipo Cons trução do Software

(17)

• Exemplos

– Ciclo Incremental

Processos de Software

Análise Projeto Codific Testes Incremento 1

Entrega do Primeiro Incremento

Análise Projeto Codific Testes Incremento 3

Análise Projeto Codific Testes

Incremento 2 Entrega do_Segundo Incremento

Sociedade demanda

grande quantidade de sistemas/aplicações

software complexo, sistemas distribuídos,

heterogêneos

requisitos mutantes

(todo ano, todo mês, todo

dia)

Mas, infelizmente,

não há gente suficiente para desenvolver tanto

software com qualidade

(18)

Resultado dos projetos em 2004

Relatório do Chaos (Chaos Report)

1994 2004

Projetos

não concluídos

---

31%

Proj

etos bem sucedidos

---

16%

Estouro médio de custo

--->

180%

Estouro médio de prazo

--->

164%

Proje

tos não concluídos

---

18%

Projetos

bem sucedidos

---

29%

Estouro méd

io de custo

---

56%

Estouro médio de

prazo

(19)

Evitar desperdício

 Estudo do The Standish Group conclui (Chaos Report):

Pesquisa sobre a utilização das funcionalidades do software ...

Mais de 64% de um sistema de software

quase nunca não é utilizado!

Com métodos tradicionais/clássicos de desenvolvimento

Supõem que é possível prever o futuro

Pouca interação com os clientes

Ênfase em burocracias

(documentos, formulários, processos, controles rígidos, etc.)

Avaliação do progresso baseado na evolução da

burocracia e não do código

Com software

Grande quantidade de erros

Falta de flexibilidade

Problemas

(20)

• O modelo incremental é recomendado por diversas

pesquisas

[Koscianski e Soares, 2007]

– Esse modelo tenta evitar falhas reportadas pelos projetos,

uma vez que se faz por incrementos

Processos de Software

• O modelo incremental é recomendado por diversas

pesquisas

[Koscianski e Soares, 2007]

– Esse modelo tenta evitar falhas reportadas pelos projetos,

uma vez que se faz por incrementos

Processos de Software

Mas os meus requisitos continuam variando

demais, e agora?

(21)

Melhores Tecnologias

Padrões de Projeto (reutilização de idéias)

Componentes (reutilização de código)

Middleware/frameworks (aumenta a bstração)

Outras Metodologias

Métodos Ágeis

outras... (abordados em outros cursos de ES)

Como resolver o impasse?

Processos de Software

• Metodologias ágeis!

– Também não são balas de prata...

– Podem auxiliar no tratamento rápido à mudanças de

requisitos

• Foi estabelecida a Aliança Ágil e o manifesto Ágil

– O termo metodologia Ágil se tornou popular por volta de

2001

– Ex.: XP, Scrum, DSDM, Crystal

(22)

• Metodologias ágeis!

– Também não são balas de prata...

– Podem auxiliar no tratamento rápido à mudanças de

requisitos

• Foi estabelecida a Aliança Ágil e o manifesto Ágil

– O termo metodologia Ágil se tornou popular por volta de

2001

– Ex.: XP, Scrum, DSDM, Crystal

Processos de Software

As metodologias variam em termos de práticas e ênfases, porém

compartilham algumas características como desenvolvimento iterativo

e incremental, comunicação. Procuram reduzir produtos

intermediários, como documentação extensiva

(23)

Como ganhar dinheiro

resolvendo problemas que

voce não conhece, com

pessoas desconhecidas,

em um tempo curto e com

poucos recursos (e se

divertindo)?

Motivação

(24)

Tenho como produzir 100 aviões em 10 minutos?

Quantos aviões 10 pessoas produzem em 10 minutos?

Tenho, mas:

- Vou verificar tudo ao final

- Posso ter baixa qualidade

- Posso ter retrabalho

- Posso não ter entendido o escopo

Então por que deixar tudo para o final?

Tenho como produzir 100 aviões em 10 minutos?

E se produzirmos um pouco a cada 2 minutos?

E se melhorarmos a cada ciclo?

E se o cliente fornecer feedback a cada ciclo?

E se a equipe encontrar a melhor forma de trabalhar?

Quantos aviões 10 pessoas produzem em 10 minutos?

(25)

Agile is not a set of practices, but a core set

of beliefs and principles

Jim Highsmith

Processos de Software

Métodos Ágeis

Processos e ferramentas Documentação abrangente Negociação de contrato Plano pré-estabelecido mais importante que

Indivíduos e interações

Software funcionando

Colaboração do cliente

Resposta às mudanças

(26)

• O gerente de projeto concorda em prosseguir sem que

todos os requisitos estejam bem definidos

• Os desenvolvedores concordam em prosseguir sem

ter todos os requisitos documentados

• Os membros da equipe sabem que alguém vai ajudar

quando ocorrerem problemas

Métodos Ágeis

• Os gerentes percebem que não precisam dizer à

equipe o que fazer, ou garantir o que vai ser feito

• A equipe percebe que ninguém vai dizer o que fazer,

isto faz parte do trabalho da equipe

• Não existem mais a impressão de divisão (testers and

programmers), todos são desenvolvedores

Em um projeto ágil ideal...

(27)

Cross-funcional Auto-organização Mudança de Postura Equipe Equipe Equipe Equipe GP Equipe Equipe Equipe Equipe GP Tradicional Ágil

Métodos Ágeis

Mudança de Postura

O que muda? Custo da mudança Intensidade e stress Tempo Tempo _Tempo Entrega de valor Transparência Envolvimento do cliente Tempo

Ref: Henrik Kniberg Tradicional

Ágil

Métodos Ágeis

O que muda?

(28)

Ref: Henrik Kniberg

• Visão tradicional

– “Tudo é importante, vamos fazer tudo ao mesmo tempo!”

• Visão ágil

– “Prioriza e foca naquilo que é mais importante!”

Jan Feb Mar Abr Mai Jun Jul

A

₃

A

₂

A

₁

B

₁

C

₁

B

₂

C

₂

B

₃

C

₃

Jan Feb Mar Abr Mai Jun Jul

A

B

C

O paradoxo da Multi-tarefa

Cinco aspectos importantes da adoção de

metodologias ágeis no desenvolvimento de

Software Web

(29)

1º. Aspecto

Eu sei e defino todos os requisitos no início do

projeto

Prikladnicki , R. “Cinco motivos para não adotar metodologias ágeis no desenvolvimento de Software” Palestra sobre metodologias ágeis apresentada em diversas universidades.