Qualidade no levantamento de requisitos

Transcrição

1 Qualidade no levantamento de Trecho do Pequeno Príncipe: Antoine Saint-Exupéry, E ele repetiu-me então, brandamente, como uma coisa muito séria: - Por favor... desenha-me um carneiro... Quando o mistério é muito impressionante, a gente não ousa desobedecer. Por mais absurdo que aquilo me parecesse a mil milhas de todos os lugares habitados e em perigo de morte, tirei do bolso uma folha de papel e uma caneta. Mas lembrei-me, então, que eu havia estudado de preferência geografia, história, cálculo e gramática, e disse ao garoto (com um pouco de mau humor) que eu não sabia desenhar. Respondeu-me: -Não tem importância. Desenha-me um carneiro. Como jamais houvesse desenhado um carneiro, refiz para ele um dos dois únicos desenhos que sabia. O da jibóia fechada. E fiquei estupefato de ouvir o garoto replicar: Qualidade no levantamento de Requisitos - Não! Não! Eu não quero um elefante numa jibóia. A jibóia é perigosa e o elefante toma muito espaço. Tudo é pequeno onde eu moro. Preciso é dum carneiro. Desenha-me um carneiro. Então eu desenhei. Olhou atentamente, e disse: - Não! Esse já está muito doente. Desenha outro. Desenhei de novo. -Bem vês que isto não é um carneiro. É um bode... Olha os chifres... -Fiz mais uma vez o desenho. Mas ele foi recusado como os precedentes: - Este aí é muito velho. Quero um carneiro que viva muito. -Então, perdendo a paciência, como tinha pressa de desmontar o motor, rabisquei o desenho ao lado. E arrisquei: -Esta é a caixa. O carneiro está dentro. Mas fiquei surpreso de ver iluminar-se a face do meu pequeno juiz: -- Era assim mesmo que eu queria! Será preciso muito capim para esse carneiro? Consistem em uma série de sentenças que descrevem de maneira clara, concisa, consistente e não ambígua todos os aspectos significativos do sistema a ser desenvolvido 1

2 Por que qualidade no Gerenciamento de? Alto custo dos erros dos Qualidade no levantamento de Fonte : G.T.E. Developments é uma companhia de software fundada em 1989, a qual se especializou no desenvolvimento de aplicações de software específicas para pinturas industriais. IBM desenvolve e manufatura diversas tecnologias da informação, dentre as quais sistemas operacionais, softwares, sistemas de armazenamentode dados e microeletrônicos. DAVIS, Alan M. Software requirements objects, functions and states. Englewood Cliffs : Prentice Hall, Fontes de erros em um projeto da US Air Force Qualidade no levantamento de Principais problemas Problemas de escopo limite é mal definido Problemas de entendimento Usuários não estâo completamente certos do domínio do problema ou mesmo tem pouca compreensão das capacidades e limitações do ambiente computacional Problemas de volatilidade mudam ao longo do tempo Qualidade no levantamento de O modelo de avaliação de maturidade do processo de desenvolvimento CMM-SW (Capability Maturity Model-SW) considera o gerenciamento de como sendo uma das primeiras etapas para alcançar a maturidade organizacional, e para haver o gerenciamento é preciso que o processo de desenvolvimento de esteja implantado na empresa. 2

3 Qualidade no levantamento de Qualidade no levantamento de Os não ficam somente com a equipe de desenvolvimento: eles se propagam por toda a área de Tecnologia da Informação (TI). homologação telecomunicações outras produção métrica Classificação dos Requisitos Requisitos não Qualidade no levantamento de Qualidade no levantamento de Requistos Descrevem as diversas funções que os clientes e usuários querem ou precisam que o software execute. Compreendem : - funções; - interação com usuário e outros sistemas; - dados, relatórios/consultas; e - inversos: o que não deve fazer. Requistos não São as qualidades globais de um software Compreendem não : - características de funcionalidade, usabilidade, confiabilidade, desempenho e suportabilidade - e outras... Ex. "o sistema deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal". "o sistema deve emitir relatórios de compras a cada quinze dias". 3

4 São exemplos de não-: "a base de dados deve ser protegida para acesso apenas de usuários autorizados"; - "o tempo de resposta do sistema não deve ultrapassar 30 segundos"; - "o software deve ser operacionalizado no sistema Linux"; - "o tempo de desenvolvimento não deve ultrapassar seis meses". Engenharia de Requisitos - Uma sub área da Engenharia de Software - Engenharia de é um conjunto estruturado de atividades para extrair, validar e manter um conjunto de documentos de. Engenharia de Requisitos Macro atividades: 1. Elicitação; 2. Definição; 3. Análise; 4. Especificação; 5. Gerência dos Requisitos 6. Gerência de mudanças Elicitação dos - Nesta fase o engenheiro de procura captar os do software, buscando obter conhecimento do domínio do problema. -Para alcançar tal objetivo, esta fase utiliza três atividades principais: identificação das fontes de informação, coleta de fatos e comunicação, além de ferramentas, pessoal e métodos. 4

5 Elicitação dos Obter informação sobre domínio do problema e sistema atual (Antes de manter as reuniões com os clientes e usuários e identificar os, é fundamental conhecer o domínio do problema e os contextos organizacional e operacional (situação atual). A equipe responsável pelo levantamento deve se familiarizar com o vocabulário próprio do domínio a ser considerado. Preparar e realizar reuniões de levantamento /negociações (Utilizar técnicas específicas para o levantamento de e técnicas de negociação). Identificar e revisar os objetivos do sistema (Identificar e revisar quais informações relevantes para o cliente que o sistema deverá gerir e armazenar.) Identificar e revisar os Identificar e revisar os não pobre elicitação dos Poucos desenvolvedores fazem uso de técnicas no momento de elicitar os de um sistema Falhamos por não termos método e não utilizarmos técnicas para elicitar os. Definição dos -É uma descrição abstrata dos serviços que o sistema deve oferecer e das restrições sob as quais ele deve operar ( e não ) -Tem por função modelar o sistema a ser desenvolvido e apresentar esse modelo ao cliente e usuários. Portanto, esse documento deve ser escrito utilizando-se modelos bastante inteligíveis como a linguagem natural e diagramas de fácil compreensão pobre definição dos Uma pobre definição dos, que devem ser escritos em linguagem natural para serem lidos e entendidos por clientes, gerentes, usuários finais do sistema, gerentes contratantes e arquitetos de sistemas, acarreta em uma má definição do sistema Falhamos por não termos uma clara visão do problema que estamos tentando resolver. 5

6 Análise dos -O projetista (engenheiro de ) especifica as funções e desempenho do software, indica a interface do software com outros sistemas e estabelece as restrições de projeto do software. - O objetivo é avaliar e revisar o escopo do software. Por meio de um processo de descoberta, refinamento, modelagem e especificação, o objetivo é obter uma especificação de completa e consistente. pobre análise dos Somente a partir de um minucioso levantamento de pessoas e atividades poderemos identificar os elementos do domínio informações e processos que serão automatizados pelo sistema computacional. Falhamos por não aprofundarmos a descoberta do domínio da aplicação e desconsiderarmos informações importantes para o sucesso da aplicação. Especificação dos -Traz informações adicionais à definição de, podendo ser desenvolvida em uma linguagem mais estruturada e acompanhada de modelos do sistema. - Linguagem natural estruturada, linguagem de descrição de projetos, linguagens de especificação de, notações gráficas, especificação matemática. pobre especificação dos Quando deixamos de produzir a especificação dos, que é a descrição sistemática e abstrata do quê o software deve fazer a partir daquilo que foi analisado e quais os critérios de validação serão utilizados para avaliar se o sistema cumpre o que foi definido, privamo-nos de um valioso instrumento de comunicação sistemática entre analistas e projetistas do software. Falhamos por não aprofundarmos a descoberta do domínio da aplicação e desconsiderarmos informações importantes para o sucesso da aplicação. 6

7 Gerência de -Estabelece um entendimento comum entre o cliente e os do cliente que serão tratados pelo projeto do software. -A Gerência de Requisitos envolve o estabelecimento e manutenção de um acordo com o cliente relativo aos do software. -Este acordo cobre tanto os técnicos () como os não técnicos (não ) e será a base para estimativa, planejamento, execução e acompanhamento das atividades do projeto de desenvolvimento do software durante seu ciclo de vida. Falhamos quando realizamos uma pobre gerência dos É uma atividade crucial no processo de engenharia de, ou seja, é necessário não somente escrever os de forma compreensível mas também permitir que eles possam ser rastreados e gerenciados ao longo da evolução do sistema Realizando-se uma Gerência de Requisitos eficaz, é possível responder a questões como: Quantos há neste projeto? Quantos são de prioridade alta? Que percentagem dos está incorporada na linha de base do projeto? perdemos o controle do processo, permitindo que cliente e gerentes interfiram diretamente na equipe e no processo de desenvolvimento do sistema. Gerência de mudanças - O impacto das mudanças é avaliado sobre os compromissos assumidos e as mudanças são negociadas. Mudanças nos compromissos assumidos com pessoas ou grupos externos à organização são revisados com a gerência superior. - Mudanças nos compromissos assumidos dentro da organização são negociadas com os grupos afetados. - Mudanças que forem necessárias nos planos do software, produtos e atividades resultantes de mudanças nos alocados são: -o Identificadas; -o Estimadas; -o Avaliados os riscos; -o Documentadas; -o Planejadas; -o Comunicadas aos grupos e pessoas afetados; e -o Acompanhadas até a conclusão. Falhamos quando realizamos uma pobre gerência dos mudanças Raramente nos preparamos para acompanhar essas mudanças. Sem falar que, pouquíssimos projetos realizam algum processo formal para analisar o impacto e custo dessas mudanças. Mudanças sempre implicam em retrabalho. Mudanças sem planejamento, sem critério de avaliação e comunicação à equipe aumentam esse retrabalho. Falhamos porque desconsideramos as solicitações de mudanças que ocorrerão, não nos preparando para recebê-las, avaliá-las e implementá-las com o menor impacto para o projeto. 7