Problemas Produção. Requisitos. Prof. Ana Paula A. de Castro. Prazos e custos

(1)

ENGENHARIA DE

SOFTWARE

SOFTWARE -- II

FAPI – Engenharia de Software – Profa_{. Ana Paula A. de Castro}

Prof. Ana Paula A. de Castro

[email protected] PRODUTOS PRODUTOS Problemas Produção • Ciclos de vida • Projetos Requisitos

Requisitos

• Características

• Especificação dos requisitos

• Engenharia dos requisitos

• Gestão dos requisitos

PRODUTOS PRODUTOS

Prazos e custos

• Realismos de prazos e custos

• Planejamento de projetos

• Controle de projetos

Qualidade Qualidade

• Conformidade com os requisitos

• Garantia da qualidade • Gestão de configurações • Gestão de contratos • Desenho Projetos Projetos

O desenvolvimento de um software é feito dentro de um projeto.

Todo projeto tem:

• Data de início

• Data de fim;

• Uma equipe;

• E outros recursos.

(2)

Projetos Projetos

Quando um projeto é bem definido, terá fases que permitam avaliar o progresso de um projeto e corrigir seus rumos quando ocorrerem problemas.

As fases devem ser terminadas por marcos, ou seja, pontos que representam estados significativos do projeto.

• Marco de conclusão do projeto – resultado;

Enunciar os problemas Enunciar os problemas

Por que os sistemas informatizados...

• …não fazem o que deveriam fazer?

• porque os problemas têm que ser enunciados;

• antes de serem resolvidos.

Problemas têm que ser enunciados antes de serem resolvidos.

• O que é necessário fazer é uma coisa.

Problemas tem que ser enunciados antes de serem resolvidos.

(3)

• O que os clientes pedem é ainda outra coisa.

• O que os engenheiros de software entendem é mais outra coisa.

mais outra coisa.

• O que acaba sendo feito...

Requisitos Requisitos

O valor de um produto vem de suas

características, se tratando de software pode ser dividida em:

• funcionais – que representam os comportamentos

que um programa ou sistema deve aprender diante de certas ações de seus usuários;

• não-funcionais – que quantificam determinados

(4)

que um programa ou sistema deve aprender diante de certas ações de seus usuários;

Ex. Em um terminal de caixa automático, os tipos de

transações bancárias suportadas são características funcionais.

aspectos do comportamento.

Ex. A facilidade de uso, o tempo de resposta e o tempo

médio entre falhas são características não funcionais.

Os requisitos são as características que definem os critérios de aceitação de um produto, podendo ser:

• Explícitos – são aqueles descritos em um documento

que específica os requisitos de um produto, ou seja, um documento de especificação de requisitos.

um documento de especificação de requisitos.

• Normativos – são aqueles que decorrem de leis,

regulamentos, padrões e outros tipos de normas a que tipo de produto deve obedecer.

• Implícitos – são expectativas dos clientes e usuários,

que são cobradas por esses, embora não

Princípios da Engenharia de Requisitos:

• boas especificações de requisitos são indispensáveis;

• não representam custos supérfluos; mas investimentos necessários;

• a participação dos usuários é fundamental; para que as suas necessidades sejam atendidas;

(5)

Princípios da Engenharia de Requisitos:

• uma boa especificação de requisitos custa: tempo e dinheiro;

• a ausência de uma boa especificação de requisitos custa:

requisitos custa:

muito mais tempo e dinheiro.

Instabilidade dos requisitos, ocorre quando clientes e usuários trazem novos requisitos, ou alterações dos requisitos, quando o desenvolvimento já esta em fase adiantada:

• perda de tempo e dinheiro;

• às vezes é inevitável;

• que fazer?

Na Engenharia de Software, a instabilidade é tão danosa quanto nas outras engenharias. Ex. Na construção civil

- Mudar a planta de um edifício - Mudar a planta de um edifício

durante a construção, geralmente é preciso desfazer parte do que já foi construído

- Será que o remendo é satisfatório?

A boa engenharia de requisitos reduz a instabilidade desses, ajudando a obter os requisitos corretos em um estágio anterior ao desenvolvimento.

As vezes alterações de requisitos são

(6)

A engenharia de requisitos está sujeita a limitações humanas;

Mesmo que o levantamento seja perfeito, podem ocorrer alterações de requisitos por

podem ocorrer alterações de requisitos por causas externas aos projetos.

Ex.

A engenharia de requisitos está sujeita a limitações humanas;

Mesmo que o levantamento seja perfeito, podem ocorrer alterações de requisitos por

podem ocorrer alterações de requisitos por causas externas aos projetos.

Ex. A legislação pode mudar no meio do projeto, requerendo alterações nos relatórios que o produto deve emitir.

Gestão dos requisitos é a disciplina da engenharia de software que:

• procura manter sob controle os requisitos de um produto;

• mesmo diante de alterações inevitáveis.

Prazos e Custos

(7)

Realismo de Prazos e Custos Realismo de Prazos e Custos

Estourar cronogramas e orçamentos é parte da rotina da maioria dos profissionais de software.

Clientes e gerentes se desesperam com os atrasos dos projetos de software e sofrem prejuízos.

No próximo contrato que oferta irão

escolher?

No próximo contrato que oferta irão

escolher?

O que prometer melhor prazo e/ou

Prazos e Custos Prazos e Custos

O que prometer melhor prazo e/ou menor custo.

Se for um projeto interno da organização, farão todo tipo de pressão para conseguir que os desenvolvedores prometam prazos

que os desenvolvedores prometam prazos politicamente agradáveis, embora irreais.

(8)

Estimar prazos e custos faz parte da rotina de qualquer ramo da engenharia.

Para um produto ser viável, não basta

Para um produto ser viável, não basta atender aos requisitos desejados, tem de ser produzido dentro de certos parâmetros de prazo e custo.

Por que os sistemas informatizados...

• são entregues com atraso?

• custam mais caro do que o previsto?

Por que os sistemas informatizados...

• são entregues com atraso?

• custam mais caro do que o previsto?

Porque faltam:

• gestão do escopo; • planejamento do projeto; • controle do projeto.

Gestão do escopo

O escopo descreve todos os produtos de um projeto, serviços necessários para realizá-los e resultados finais esperados.

Descreve também como o projeto será realizado para que alcance seus objetivos com os recursos e funções especificados.

(9)

Exemplo: Gestão do escopo

Escopo do produto de um sistema online de pagamento de contas:

• Descreve seus objetivos comerciais, como este vai funcionar, suas características, as tecnologias

vai funcionar, suas características, as tecnologias necessárias.

O escopo do projeto:

• Descreve as etapas, os recursos disponíveis, como o produto será desenvolvido.

Um triângulo crítico da Engenharia de Software:

Requisitos

Prazos Custos

Requisitos _{Aumentos de requisitos levam}

a aumentos de prazos ou custos, ou de ambos Prazos e Custos Prazos e Custos Prazos Custos custos, ou de ambos

(10)

Requisitos _Reduções _de _requisitos

podem levar a reduções de prazos ou custos, mas nem

Prazos Custos

prazos ou custos, mas nem sempre satisfaz.

Requisitos

Não existe fórmula mágica para melhoria de processos (requisitos) sem alterarmos prazos e/ou custos.

Prazos Custos

A cultura do prazo artificial:

• os sistemas só são propostos quando a necessidade deles é para ontem;

• os prazos são fixados de forma comercial ou política, e não técnica:

política, e não técnica: o sistema já foi vendido… o ministro vem inaugurar…

Não me interessa como você vai fazer,

desde que entregue no prazo!

• Pressionados o suficiente, programadores

prometem qualquer prazo.

(11)

Conseqüências da cultura do prazo

ruim:

• Produtos de má qualidade e mais caros do

que deveriam (clientes);

• Perda de credibilidade e prejuízos

(gerentes)

• Estresse e má qualidade de vida

(desenvolvedores)

Dado um prazo, sempre se consegue fazer alguma coisa.

• Resta ver se é a coisa que deveria ser feita.

Para cumprir compromissos de prazos e

custos, esses compromissos têm de ser

assumidos com base em requisitos bem levantados, analisados e documentados.

E os planos dos projetos têm de ser feitos com boas técnicas de estimativa e análise de tamanho, esforços, prazos e riscos.

Planejamento de Projetos Planejamento de Projetos

O desenvolvimento de software é feito dentro de um projeto. • data de início; • data de fim; • equipe; Prazos e Custos Prazos e Custos • gerente do projeto; • outros recursos.

Um projeto representa a execução de um processo.

(12)

Processo bem definido:

• é documentado;

• subdivisões permitem avaliar o progresso;

e corrigir rumos;

• subdivisões terminadas por marcos:

estados significativos do projeto;

Processo bem definido:

• marcos associados a resultados

concretos; verificáveis; • o produto é um resultado; Prazos e Custos Prazos e Custos • o produto é um resultado;

associado ao marco de conclusão do projeto.

Os processos de desenvolvimento de

software são intensivos em mão de

obra.

• Métodos resolvem:

apenas uma parte dos problemas.

• Ferramentas resolvem:

uma parte ainda menor dos problemas.

• Ferramentas e métodos avançados:

(13)

Receitas para reduzir custos.

• Fazer uma boa especificação:

para não ter que mudá-la durante o

desenvolvimento.

nada é mais caro que resolver os problemas

errados.

• Se for preciso modificar requisitos:

controlar as mudanças;

por meio da gestão dos requisitos.

Receitas para reduzir custos.

• Identificar e resolver problemas o mais

cedo possível.

O custo de correção dos defeitos cresce muito

ao longo do tempo.

Executar projetos é mais do que fazer

planos.

• Fazer orçamentos e cronogramas é fácil. • Cumpri-los é muito mais difícil.

• Sem controle, compromissos não se

cumprem.

Controle de Projetos Controle de Projetos

O controle dos projetos compreende:

• acompanhamento dos projetos;

comparando-se o planejado com o realizado;

• busca de alternativas para contornar

problemas;

(14)

Controle de Projetos Controle de Projetos

O controle dos projetos compreende:

• replanejamento dos projetos;

quando não é possível manter os planos

anteriores;

dentro de um grau razoável de variação;

• renegociação dos compromissos

assumidos;

envolvendo todas as partes interessadas.

Conformidade com Requisitos Conformidade com Requisitos

A qualidade de um produto está ligado

com os respectivos requisitos.

Qualidade Qualidade

A qualidade de um produto está ligado

com os respectivos requisitos.

Ex. Um carro popular pode ser de boa

qualidade, e um carro de luxo pode ser

de má qualidade.

Ex. Um carro popular pode ser de boa

qualidade, e um carro de luxo pode ser

de má qualidade.

(15)

Ex. Um carro popular pode ser de boa qualidade, e um carro de luxo pode ser de má qualidade.

O que decide a qualidade é comparação com

O que decide a qualidade é comparação com os respectivos requisitos:

• O confronto entre a promessa

• A realização de cada produto

Garantir a qualidade Garantir a qualidade

Por que os sistemas informatizados...

• ...são de baixa qualidade?

• Porque a qualidade não é planejada... • ...portanto, não é garantida!

• ...portanto, não é garantida!

A qualidade dos produtos depende da

qualidade dos processos.

• O que é mal especificado:

é mal desenhado.

• O que é mal desenhado:

é mal implementado.

• O que é mal implementado:

é muito difícil de consertar.

(16)

Exemplo: Construção de um carro

Todos os produtos intermediários devem ser conferidos.

• O que não passar na verificação não está pronto.

• Verificar custa tempo e dinheiro.

• Não verificar custa muito mais.

A garantia da qualidade não existe se não for obsessiva.

• Todos conferem melhor o trabalho alheio.

• Quem confere não pode ser quem desenvolve.

(17)

Qualidade é produzida por:

• técnicas corretas;

• nas mãos de pessoas capacitadas.

Conferir não cria qualidade:

• apenas descobre problemas.

Qualidade não é luxo, é a necessidade mais básica.

• Prazos e custos só podem ser definidos a partir de objetivos de qualidade.

objetivos de qualidade.

• Com qualidade zero, pode-se fazer qualquer coisa dentro do prazo.

A curva prazo ×qualidade: Tempo de desenvolvimento Real Qualidade Qualidade Qualidade do processo (medida em % de Ilusório

Um produto de software é composto por muitos artefatos: • códigos executáveis; • Códigos-fonte; Gestão de Configurações Gestão de Configurações Qualidade Qualidade • modelos; • relatórios; • outros documentos.

(18)

Exemplos de artefatos

• Artefatos oficiais:

A aprovação dos resultados assinala que um marco do

projeto foi cumprido;

Gestão de Configurações Gestão de Configurações

FAPI – Engenharia de Software – Profa_{. Ana Paula A. de Castro} projeto foi cumprido;

• Artefatos informais:

Documentos e modelos temporários de trabalho dos

desenvolvedores

A maioria dos artefatos evolui ao longo do projeto e até ao longo de toda vida de um produto.

Importante que os resultados sejam

guardados e controlados.

• Necessidade de atualizar em caso de

manutenção;

Organizar e controlar os artefatos é o objetivo da gestão de configurações.

• Sem ela, é impossível atingir sequer níveis razoáveis de qualidade.

• Versões corrigidas são perdidas;

• Versões corrigidas são perdidas; versões defeituosas reaparecem.

• O número de itens diferentes produzidos em projetos de software:

ultrapassa os limites da memória e da atenção humanas; mesmo em pequenos projetos.

Gestão de Contratos Gestão de Contratos

Empresas de software preferem terceirizar o desenvolvimento de software

• Contratam profissionais liberais;

(19)

Gestão de Contratos Gestão de Contratos

Subcontratação - elo fraco da qualidade.

• A mesma qualidade que se oferece ao cliente deve ser exigida dos

ao cliente deve ser exigida dos fornecedores.

• Falha dos fornecedores nunca é desculpa!

A gestão de contratos determina como:

• especificar o produto a ser desenvolvido; correta e completamente;

• fazer uma boa seleção entre os candidatos a subcontratado;

subcontratado;

avaliando o realismo das propostas;

A gestão de contratos determina como:

• acompanhar o desempenho do subcontratado; detectando precocemente problemas;

• planejar e executar os procedimentos de aceitação do produto. Qualidade Qualidade aceitação do produto. Desenhar os produtos Desenhar os produtos

Problemas de desenho (design):

• Existe sempre um desenho: entre os requisitos e o código.

• Os defeitos de desenho geralmente são graves:

(20)

Desenhar os produtos Desenhar os produtos

Problemas de desenho (design):

• Os defeitos de desenho são freqüentes:

quase tão freqüentes quanto os defeitos de

implementação;

quando os desenvolvedores não são competentes em

desenho.

• Muitos programadores nunca tiveram formação em técnicas de desenho:

mesmo quando têm excelente domínio de uma

linguagem de programação.

Ex.: Na construção erros de desenhos

podem levar a quais problemas???

Ex.: Na construção erros de desenhos

podem levar a quais problemas??? Vazamentos Perigo de incêndios Qualidade Qualidade Perigo de incêndios Rachaduras Desabamentos Desenhar os produtos Desenhar os produtos

Vazamento é novamente de hidrogênio líquido. Voo foi adiado para julho.

• A NASA adiou o lançamento do ônibus espacial Endeavour, que estava previsto para esta quarta-feira (17/06/2009), depois de descobrir um vazamento potencialmente perigoso durante o reabastecimento da nave. Um representante da agência afirmou que o ônibus espacial será lançado apenas no dia 11 de julho. A nave estava pronta para o lançamento no Centro Espacial Kennedy, na Flórida.

• A declaração divulgada pela NASA informou que, por volta das 01h55 (horário local), os

• A declaração divulgada pela NASA informou que, por volta das 01h55 (horário local), os responsáveis pelo ônibus espacial "cancelaram o lançamento do ônibus espacial Endeavour em sua missão STS-127". "Apesar dos esforços para descobrir quais eram os problemas, os engenheiros não conseguiram diminuir o vazamento de hidrogênio líquido."

• Este é o segundo adiamento do lançamento da Endeavour. O ônibus espacial decolaria no último sábado, dia 13 de junho, mas as autoridades detectaram o vazamento de hidrogênio, muito inflamável. Apesar de a nave ter sido consertada o problema voltou a aparecer e a NASA decidiu adiar o lançamento até o mês de julho.

(21)

Resultados típicos de defeitos de desenho:

• dificuldade de uso;

• lentidão;

• problemas imprevisíveis e irreprodutíveis;

• perda de dados;

• dificuldade de manutenção;

• dificuldade de adaptação e de expansão.

Amadurecer os processos Amadurecer os processos

A maturidade de uma organização em

engenharia de software mede o grau de:

• competência

• técnica

• gerencial

Que essa organização possui para produzir software de boa qualidade, dentro de prazos e custos razoáveis de previsíveis.

Empresas com baixa maturidade em

software:

• Os processos são informais;

• Ou seja, existem apenas na cabeça dos praticantes. Amadurecer os processos Amadurecer os processos Comparação Qualidade Qualidade

ORGANIZAÇÕES MADURAS ORGANIZAÇÕES IMATURAS

Papéis e responsabilidades bem definidas

Processo improvisado

Existe base histórica Não Existe base histórica

É possível julgar a qualidade do produto Não há maneira objetiva de julgar a qualidade do produto

A qualidade dos produtos e processos é monitorada

Qualidade e funcionalidade do produto sacrificados

O processo pode ser atualizado Não há rigor no processo a ser seguido

(22)

Para tornar uma empresa mais madura e capacitada, é realmente preciso melhorar a qualidade dos seus processos.

Êxito dos processos:

• Medida de quanto os processos contribuem para que os produtos sejam entregues aos clientes e usuários com melhor qualidade, por menor custo e em prazo mais curto.

Onde o retorno do investimento em

capacitação é maior?

• Formar pessoas é difícil, caro e demorado. Recrutar pessoas capacitadas também.

• Tecnologia tem seu próprio ritmo de evolução. Tecnologia demais é problema e não solução.

• Mudanças de processo podem trazer melhorias a prazo mais curto.

(23)

Problema:

• Ferramentas não fazem milagres.

• Metodologias não fazem milagres.

• Métodos gerenciais não fazem milagres.

• Os processos também não fazem milagres!

A capacitação em processos é, ela própria, um processo.

• O objetivo do processo de capacitação é o amadurecimento de uma cultura da qualidade.

O amadurecimento dos

processos se faz passo a passo. • Existem níveis de maturidade. Qualidade Qualidade maturidade. • O SW-CMM* é o paradigma mais difundido de níveis de maturidade.

••SWSW--CMMCMM –– CapabilityCapability MaturityMaturity ModelModel

O CMM focaliza os processos, que considera o fator de produção com maior potencial de melhoria a prazo mais curto.

Fatores como tecnologias e pessoas, só são tratados pelo CMM na medida em que interagem os processos.

(24)

SW-CMM classifica as organizações em cinco níveis distintos, cada um com suas características próprias.

O processo de desenvolvimento é desorganizado e

O processo de desenvolvimento é desorganizado e até caótico. Poucos processos são definidos e o sucesso depende de esforços individuais e heróicos.

Os processos básicos de gerenciamento de projeto estão estabelecidos e permitem acompanhar custo,

estão estabelecidos e permitem acompanhar custo, cronograma e funcionalidade.

É possível repetir o sucesso de um processo utilizado anteriormente em outros projetos similares.

Tanto as atividades de gerenciamento quanto de engenharia do processo de desenvolvimento de

software estão documentadas, padronizadas e integradas em um padrão de desenvolvimento da organização

Todos os projetos utilizam uma versão aprovada e adaptada do processo de desenvolvimento de

(25)

São coletadas medidas detalhadas da qualidade do produto e processo de desenvolvimento de

produto e processo de desenvolvimento de software.

Tanto o produto quanto o processo de

desenvolvimento de software são entendidos e controlados quantitativamente.

O melhoramento contínuo do processo é

conseguido através de um feedback quantitativo

conseguido através de um feedback quantitativo dos processos e pelo uso pioneiro de idéias e tecnologias inovadoras. Amadurecer os processos Amadurecer os processos Qualidade Qualidade Amadurecer os processos Amadurecer os processos Qualidade Qualidade