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

Transcrição

1 PRODUTOS ENGENHARIA DE SOFTWARE - I Prof. Ana Paula A. de Castro anapaula.rna@gmail.com Problemas Produção Ciclos de vida Projetos Requisitos Características Especificação dos requisitos Engenharia dos requisitos Gestão dos requisitos Prazos e custos PRODUTOS Realismos de prazos e custos Planejamento de projetos Controle de projetos Conformidade com os requisitos Garantia da qualidade Gestão de configurações Gestão de contratos Desenho Modelos de Maturidade 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. Um projeto representa a execução de um processo.

2 Projetos Enunciar os problemas Quando um projeto é bem definido, terá fases que permitam avaliar o progresso de um projeto e corrigir seus rumos quando ocorrerem 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. 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 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. O que os clientes querem é outra coisa.

3 Enunciar os problemas Enunciar os problemas Problemas tem que ser enunciados antes de serem resolvidos. O que os clientes pedem é ainda outra coisa. Problemas tem que ser enunciados antes de serem resolvidos. O que os engenheiros de software entendem é mais outra coisa. Enunciar os problemas Requisitos Problemas tem que ser enunciados antes de serem resolvidos. O que acaba sendo feito... 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 aspectos do comportamento.

4 Requisitos Requisitos O valor de um produto vem de suas características, se tratando de software pode ser dividida em: 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; Ex. Em um terminal de caixa automático, os tipos de transações bancárias suportadas são características funcionais. não-funcionais que quantificam determinados 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. Requisitos 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. 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 documentadas Enunciar os problemas 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 Enunciar os problemas Enunciar os problemas 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: 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? Enunciar os problemas 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 durante a construção, geralmente é preciso desfazer parte do que já foi construído - Será que o remendo é satisfatório? Enunciar os problemas 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 inevitáveis.

6 Enunciar os problemas Enunciar os problemas A engenharia de requisitos está sujeita a limitações humanas; A engenharia de requisitos está sujeita a limitações humanas; Mesmo que o levantamento seja perfeito, podem ocorrer alterações de requisitos por causas externas aos projetos. Mesmo que o levantamento seja perfeito, podem ocorrer alterações de requisitos por causas externas aos projetos. Ex. Ex. A legislação pode mudar no meio do projeto, requerendo alterações nos relatórios que o produto deve emitir. Enunciar os problemas 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.

7 Realismo de Realismo de Estourar cronogramas e orçamentos é parte da rotina da maioria dos profissionais de software. No próximo contrato que oferta irão escolher? Clientes e gerentes se desesperam com os atrasos dos projetos de software e sofrem prejuízos. Realismo de Realismo de No próximo contrato que oferta irão escolher? 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 politicamente agradáveis, embora irreais.

8 Realismo de Realismo de Estimar prazos e custos faz parte da rotina de qualquer ramo da engenharia. 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? Realismo de 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. Realismo de 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 Realismo de 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 necessárias. O escopo do projeto: Descreve as etapas, os recursos disponíveis, como o produto será desenvolvido. Realismo de Realismo de Um triângulo crítico da Engenharia de Software: Um triângulo crítico da Engenharia de Software: Requisitos Requisitos Aumentos de requisitos levam a aumentos de prazos ou custos, ou de ambos Prazos Custos Prazos Custos

10 Realismo de Um triângulo crítico da Engenharia de Software: Realismo de Requisitos Requisitos Reduções de requisitos podem levar a reduções de prazos ou custos, mas nem sempre satisfaz. Prazos Custos Prazos Custos Não existe fórmula mágica para melhoria de processos (requisitos) sem alterarmos prazos e/ou custos. Realismo de Realismo de 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: 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 Realismo de 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) Realismo de Dado um prazo, sempre se consegue fazer alguma coisa. Resta ver se é a coisa que deveria ser feita. Realismo de Planejamento de Projetos 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. O desenvolvimento de software é feito dentro de um projeto. data de início; data de fim; equipe; gerente do projeto; outros recursos. Um projeto representa a execução de um processo.

12 Planejamento de Projetos Processo bem definido: é documentado; subdivisões permitem avaliar o progresso; e corrigir rumos; subdivisões terminadas por marcos: estados significativos do projeto; Planejamento de Projetos Planejamento de Projetos Processo bem definido: marcos associados a resultados concretos; verificáveis; 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: só têm utilidade nas mãos de pessoas capacitadas.

13 Planejamento de Projetos Planejamento de Projetos 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. Planejamento de Projetos Controle de Projetos 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. O controle dos projetos compreende: acompanhamento dos projetos; comparando-se o planejado com o realizado; busca de alternativas para contornar problemas; surgidos na execução;

14 Controle de Projetos Conformidade com Requisitos 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. A qualidade de um produto está ligado com os respectivos requisitos. Conformidade com Requisitos Conformidade com Requisitos 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. Por que?

15 Conformidade com Requisitos Garantir a qualidade 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 os respectivos requisitos: O confronto entre a promessa A realização de cada produto Por que os sistemas informatizados......são de baixa qualidade? Porque a qualidade não é planejada......portanto, não é garantida! Garantir a qualidade Garantir a qualidade 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. Exemplo: Construção de um carro

16 Garantir a qualidade Garantir a qualidade Exemplo: Construção de um carro Exemplo: Construção de um carro Garantir a qualidade Garantir a qualidade 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 Garantir a qualidade Garantir a qualidade é produzida por: técnicas corretas; nas mãos de pessoas capacitadas. Conferir não cria qualidade: apenas descobre problemas. não é luxo, é a necessidade mais básica. Prazos e custos só podem ser definidos a partir de objetivos de qualidade. Com qualidade zero, pode-se fazer qualquer coisa dentro do prazo. Garantir a qualidade Gestão de Configurações Tempo de desenvolvimento A curva prazo qualidade: Real Um produto de software é composto por muitos artefatos: códigos executáveis; Códigos-fonte; modelos; relatórios; outros documentos. Ilusório 100% do processo (medida em % de defeitos removidos)

18 Gestão de Configurações Gestão de Configurações Exemplos de artefatos Artefatos oficiais: A aprovação dos resultados assinala que um marco do 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; Gestão de Configurações Gestão de Contratos 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 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. Empresas de software preferem terceirizar o desenvolvimento de software Contratam profissionais liberais;

19 Gestão de Contratos Garantir a qualidade Subcontratação - elo fraco da qualidade. A mesma qualidade que se oferece 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; avaliando o realismo das propostas; Garantir a qualidade Desenhar os produtos 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. Problemas de desenho (design): Existe sempre um desenho: entre os requisitos e o código. Os defeitos de desenho geralmente são graves: quase tão graves quanto os de requisitos.

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??? Desenhar os produtos Desenhar os produtos Ex.: Na construção erros de desenhos podem levar a quais problemas??? Vazamentos Perigo de incêndios Rachaduras Desabamentos 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 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 Desenhar os produtos 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. 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. ORGANIZAÇÕES MADURAS Papéis e responsabilidades bem definidas Existe base histórica É possível julgar a qualidade do produto A qualidade dos produtos e processos é monitorada O processo pode ser atualizado Comparação ORGANIZAÇÕES IMATURAS Processo improvisado Não Existe base histórica Não há maneira objetiva de julgar a qualidade do produto e funcionalidade do produto sacrificados Não há rigor no processo a ser seguido Existe comunicação entre o gerente e seu grupo Resolução de crises imediatas

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. Onde o retorno do investimento em capacitação é maior? Tecnologia tem seu próprio ritmo de evolução. Tecnologia demais é problema e não solução. Onde o retorno do investimento em capacitação é maior? 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. O SW-CMM * é o paradigma mais difundido de níveis de maturidade. 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. SW-CMM Capability Maturity Model Desenvolvido pelo departamento defesa americana. de

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 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, 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 software.

25 São coletadas medidas detalhadas da qualidade do 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 dos processos e pelo uso pioneiro de idéias e tecnologias inovadoras.