Upload
internet
View
105
Download
0
Embed Size (px)
Citation preview
Gerência de Requisitos
07/11/2006
Objetivo
Conscientizar os participantes da importância dos requisitos no processo de desenvolvimento de sistemas, em conformidade com as normas de qualidade de software
Parte I:
Introdução a Requisitos
Sumário
Introdução a Engenharia de SistemasProblemas do Processo de DesenvolvimentoA Importância dos Requisitos no Processo de Desenvolvimento Motivação Conceitos– Regras de Negócio– Requisitos Funcionais e Não Funcionais– ISO/IEC 9126
Introdução a Engenharia de Sistemas
O Conceito de Sistemas
Um sistema pode ser definido como:
"Um conjunto, identificável e coerente, de elementos que interagem
coesivamente, onde cada elemento pode ser um sistema."
– equivale a traçar uma fronteira conceitual separando esse conjunto de elementos do resto do universo
Desenvolvimento de Sistemas
O processo de desenvolvimento é composto de (independente de metodologia):– Especificação do Problema – Elicitação e Especificação dos Requisitos (Análise)– Planejamento da Solução (Projeto)– Implementação em uma Linguagem de
Programação
Metodologia– conjunto de conceitos, ferramentas e técnicas
que permitem a construção de um modelo do domínio do problema e da adição de detalhes de implementação durante o projeto do sistema
Ciclo de vida clássico (em cascata)
Engenhariade Sistemas
AnáliseProjeto
Codificação
Teste
Manutenção
Desenvolvimento de Sistemas
Sistemas apresentam uma complexidade– Porte– Intrínseca
Seu desenvolvimento é um processo de elaboração de modelos– A modelagem é aplicada a cada etapa do processo de
desenvolvimento– A cada etapa podem ser empregadas um conjunto
diferente de ferramentas e técnicas de modelagem
Modelagem de Sistemas
Objetivo– reconhecimento do padrão interno que permite ao
sistema responder aos estímulos do ambiente externo
– padrão Interno = comportamento + informação
Recursividade do Conceito de Sistemas
– Sistema = {subsistemas}, onde cada subsistema é também um sistema
O Conceito de Modelo
“Modelo é a representação abstrata que permite descrever e/ou prever comportamentos específicos de um Sistema através do estudo de suas
características relevantes.”
Características de um Modelo
Aplicação de critérios de:– segmentação (porte)– abstração de características irrelevantes ao modelo
(intrínseca)
Objetivo:– explicitação de entidades (objetos) e relacionamentos
relevantes ao modelo
Utiliza uma linguagem de representação rigorosa (sintaxe, semântica e formalismo)
Características de um Modelo
Possui capacidade preditiva– O modelo é capaz de responder a perguntas específicas
• O comportamento do modelo é compatível com o sistema modelado?• O modelo se adequa aos objetivos a serem atingidos pelo sistema?
Como modelar?
o que será modelado é função da relevância dos aspectos a serem inseridos no modelo em função do seu objetivonão existe receita "pronta", envolve a intuição, criatividade e julgamento crítico do modeladormanutenção de consistência interna dos aspectos representados no modelovalidação experimental (correspondência de comportamento previsto a partir do modelo com o comportamento real do sistema)
Problemas do Processo de Desenvolvimento
Software x Hardware
O software é desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico– O software é um elemento de sistema lógico e não físico– existem semelhanças entre o desenvolvimento de
software e o de hardware (manufatura)• a alta qualidade é obtida a partir de um bom projeto mas
os custos do software estão concentrados no trabalho de engenharia
Software x Hardware
O software não se desgasta (como o hardware) mas se deteriora– Durante sua vida o software enfrentará mudanças, que
podem introduzir novos defeitos
Não existem “peças de reposição” para o software– Quando o hardware se desgasta é substituído por uma
peça de reposição– A complexidade e o custo de manutenção do software é
muito maior
A maioria dos softwares é feita sob medida– Montagem por reuso de componentes – Este é um cenário que está mudando
Quais são os problemas?
A sofisticação do software ultrapassou nossa capacidade de desenvolvimento– A construção de programas não acompanha a demanda por novos
programas– A manutenção de programas é ameaçada por projetos ruins– Geralmente não há metodologia e controle de qualidade para projetos
Causas óbvias
Não dedicamos tempo para coletar dados sobre o desenvolvimento do software - resulta em estimativas “a olho”Comunicação entre o cliente e o desenvolvedor é fracaFalta de testes sistemáticos e completos
Causas menos óbvias
Gerentes sem background em desenvolvimento de softwareProfissionais recebem pouco treinamento formalFalta investimento (em ES)Faltam métodos e automaçãoFalta acompanhamento do processo de desenvolvimento
Mitos do Software - Administrativos
Um manual oferece tudo que se precisa saberComputadores de última geração solucionam problemas de desenvolvimentoSe estamos atrasados, basta adicionarmos programadores e tirar o atraso (chamado “conceito de hordas de mongóis”)
Mitos do Software - do Cliente
Uma declaração geral é suficiente para começar a escrever programasMudanças podem ser facilmente acomodadas em um projeto
Mitos do Software - do Profissional
Um programa está terminado ao funcionarQuanto mais cedo escrever o código, mais rápido terminarei o programaSó posso avaliar a qualidade de um programa em funcionamentoA única coisa a ser entregue em um projeto é o programa funcionando
Recursos Humanos - Importância
Qual a importância dos Recursos Humanos no processo de desenvolvimento de software?
Motivo: a comunicação é absolutamente essencial para o desenvolvimento do software. Todo novo caminho de comunicação exige esforço adicional e portanto, tempo adicional.
Recursos Humanos – Grau de participação em projetos
Análise derequisitos
participação
baixo
alto
Grau de
no projeto
Planejamento Projetopreliminar
Pessoaltécnico senior
Pessoaltécnico junior
Administrador
Projetodetalhado
CodificaçãoTeste deunidade
As 10 Áreas da Engenharia de Software
Gerência de Configuração de SoftwareGerência de Engenharia de SoftwareProcesso de Engenharia de SoftwareFerramentas e MétodosQualidade de SoftwareRequisitos de softwareDesign de softwareConstrução de SoftwareTeste de SoftwareManutenção de Software
(SWEBOK, 2004)
Motivação
A crise do software
Força Aérea Americana, software de comando e controle (anos 80):– custo inicial estimado: U$400.000,00– custo final: U$3.200.000,00
(Jalote, 1997)
Software de recebimento de imposto de renda (EUA):– qualidade: o sistema se mostrou inadequado para a carga esperada– custo: a Receita Federal dos EUA gastou mais U$90.000.000,00 para
corrigir o software que custou U$103.000.000,00– devido ao atraso, a RF ainda teve de pagar mais U$63.000.000,00 de
multas por atraso e juros(B.Brügge 1997, Notas de curso TUM)
A crise do software
Ônibus Espacial:– Custo: U$10.000.000.000,00 (vários milhões a mais do que o
estimado)– Prazo: 3 anos de atraso– Qualidade: primeiro lançamento do Columbia foi cancelado devido a
problemas de sincronização de seus 5 computadores de bordo• Causa: modificação feita 2 anos antes, em que o tempo de espera de um
tratador de interrupção passou de 50ms para 80ms• O erro era um evento raro, tanto que não foi detectado durante as mais de
mil horas de teste– Muitos erros ainda subsistem. Os astronautas recebem um livro
contendo os problemas de software que já são conhecidos
(B.Brügge 1997, Notas de curso TUM)
Motivação
70% dos projetos de software falham ou são gravemente prejudicados:– negligenciam os cuidados com a elicitação dos requisitos – gerenciam mal seus requisitos
Um software que não satisfaz as necessidades software inútil
(Chaos, 1994)
Pesquisa realizada com 365 gerentes executivos de TI dos EUA
Três principais critérios de sucesso1. Envolvimento do Usuário2. Apoio da Gerência Executiva3. Indicação Clara dos Requisitos
Projetos falham ou são prejudicados1. Requisitos Incompletos2. Falta de Envolvimento do Usuário3. Falta de Recursos
Motivação
(Chaos, 1994)
Motivação
O que acontece se:– o usuário mudar de idéia em relação a uma funcionalidade?– o engenheiro de requisitos (ou analista) não entendeu corretamente a
necessidade do usuário?– o ambiente mudar?– o usuário perceber novas possibilidades na automação?
Mudanças
Motivação
Mudanças são inevitáveisRazões para mudanças:– modificações no ambiente: regras de negócios, leis,
políticas internas– mudanças tecnológicas– a complexidade dos sistemas impõe mudanças à medida
que se adquire maior conhecimento sobre os mesmos– correção ou ajustes em requisitos incorretos ou mal
definidos– desenvolvedores querem adicionar funcionalidades mais
avançadas de modo a oferecer vantagem– clientes mudam de idéia
Motivação
é preciso gerenciar as mudanças!mudanças em requisitos ao longo do desenvolvimento de software fazem parte do processoalterações em requisitos podem implicar em mudanças em artefatos de design, de código, casos de testes, etcRequisitos que tendem a mudar devem ser tratados isoladamenteIsolar regras de negócio para reuso
Motivação
re-trabalho e custo associado à correção de erros
quanto mais tarde o erro é descoberto, mais custosa será a correção
(Boehm, 1981)
A Importância dos Requisitosno Processo de Desenvolvimento
Requisitos de Software
Uma compreensão completa dos Requisitos do Software é fundamental para obter um software e um processo de desenvolvimento com alta qualidade
O software deve evoluir para atender às necessidades mutáveis dos clientes
.....“a construção por múltiplas pessoas de um software de múltiplas versões” (Parnas, 1987)
Requisito – Uma condição ou capacidade que deve ser satisfeita
ou possuída por um sistema ou componente do sistema para satisfazer um contrato, um padrão ou uma especificação(IEEE, 1990)
Especificação:– Uma descrição rigorosa e minuciosa das
características que um material, uma obra, ou um serviço deverão apresentar
(Aurélio, 1999)
Requisitos
Requisitos
Requisitos do usuário– Declarações, em linguagem natural e diagramas, sobre os
serviços que o sistema oferece e as restrições para a sua operação. Escrito para os clientes
Requisitos do sistema– Estabelecem detalhadamente as funções e restrições do
sistema. O documento de requisitos, chamado de especificação funcional, pode servir como um contrato entre cliente e desenvolvedor
Especificação de software– Especificação abstrata e precisa do software, indicando o que
ele deve fazer (sem dizer como) que serve de base para o projeto e para a implementação
– Acrescenta mais detalhes à especificação funcional e é escrito para a equipe de desenvolvimento
Requisitos PETROBRAS
Requisito de Negócio– Descrevem as atividades que os usuários deverão ser
capazes de executar com a utilização do sistema, delimitando o domínio do problema
– Estão descritos no Documento de Visão– Funcionais, não funcionais e inversos
Requisito de Produto– Descrevem características associadas a implementação
da solução– Funcionais (Doc. de Caso de Uso) e não funcionais (Doc.
de Especificação Suplementar)
Requisitos servem como especificação do que deve ser implementadoRequisitos são descrições de como o sistema deve se comportar, de uma propriedade ou atributo do sistemaUm requisito pode descrever:– uma facilidade encontrada no nível do usuário– uma propriedade geral do sistema– uma restrição do sistema– uma restrição ao desenvolvimento do sistema
(Sommerville, 2003)
Requisitos
“O sistema deve rodar em microcomputadores da linha PC que possuam microprocessador Pentium ou superior”“A interface do sistema deve ser gráfica, de acordo com um padrão de interface dirigida a menu”“Alternativamente, o sistema deve possibilitar o seu uso através de linhas de comando, para usuários avançados”“O gerente da padaria deve consultar quanto vendeu em um dia”
Requisitos - Exemplos
Requisitos: diretrizes para elaboração 1/2
Definir um formato padrão e usá-lo para todos os requisitosUtilizar o idioma de forma consistente. Usar “deve” para requisitos obrigatórios, “deveria” (ou é recomendável) para requisitos desejáveisEvitar o uso de jargões de computaçãoEmpregar termos característicos do problema
Requisitos: diretrizes para elaboração 2/2
Use sentenças diretas e objetivasUse vocabulário limitadoDefina requisitos verificáveisEvite ambigüidadesEvite sentenças muito longasEvite uso de conjunções como ou, e, com, tambémEvite termos vagos ou indefinidos
Como especificar Requisitos
Linguagem natural estruturada– A abordagem estruturada emprega templates para registrar, validar e
gerenciar requisitos– Nesta abordagem é preciso definir um ou mais formulários ou
templates para expressar os requisitos.– Vantagens
• Uniformidade• Possibilidade de agrupar requisitos• Possibilidade de rastrear os requisitos
Para especificar requisitos:– Descrição da necessidade atendida pelo requisito– Descrição da função ou entidade que está sendo
especificada– Descrição de suas entradas e de onde elas se originam;– Descrição de suas saídas e para onde elas prosseguirão– Indicação de quais outras entidades são utilizadas – Pré-Condição
• Condição que deve ser verdadeira para que seja executado– Pós-Condição
• O estado resultante do sistema
Itens importantes de um template
Pré-condições:– definem o que deve ser verdadeiro na estrutura da
informação armazenada para que a operação ou consulta possa ser executada
– algum mecanismo externo deverá garantir sua validade antes de habilitar a execução da operação ou consulta ao sistema
Pós-condições:– estabelecem o que uma operação de sistema muda na
estrutura da informação armazenada – estabelece a resposta gerada pelo sistema quando a
operação é executada
Abordagem estruturada
Requisitos– um novo cliente deve ser cadastrado em uma Video
Locadora– O cadastro do cliente contém nome, endereço e telefone
Pré-condição:– Não existe nenhum cliente com o nome informado
Pós-condição:– O cliente foi adicionado ao cadastro– Os dados informados sobre o cliente são atualizados nos
atributos do cliente– O cliente é criado com o débito zerado
Abordagem estruturada - Exemplo
Conceitos
• Regra de Negócio
• Requisitos Funcionais e Não Funcionais
• ISO/IEC 9126
Regra de Negócio
O que é uma Regra de Negócio?– Define ou restringe aspectos da organização– Fontes:
• decisões estratégicas • leis e regulamentações• obrigações contratuais
Importância de identificar Regras de Negócio
As melhores práticas de engenharia de software advogam código reusável e modular
Separar regras de negócio de projetos específicos é uma forma de adaptar esta regra para a gerência de requisitos– as regras de negócio podem ser empregadas em vários projetos
Exemplo de Regra de Negócio
“Os remédios comercializados devem ter, no mínimo, 30 dias de validade”“Para ser considerado dependente, a pessoa não pode ter renda ou a renda deve ser abaixo de um salário mínimo”
requisitos funcionais, não funcionais, inversos
requisitos funcionais: – aqueles diretamente relacionados à funcionalidade do software– dependentes do problema e independentes da solução
Requisitos: Classificação
Requisitos: Classificação
Requisitos não funcionais: relacionados a aspectos de qualidade que o software deverá apresentar, ou a restrições a serem atendidasExemplo: Norma de Qualidade da ISO/IEC 9126– Dependente da solução
Requisitos inversos: representam funcionalidades que estão fora do escopo da solução
Exemplos de Requisitos
Requisito funcional“O sistema deve controlar o horário de entrada e saída dos funcionários” Requisito não funcional
“O relatório mensal dos horários, por funcionários, deve ser impresso em papel timbrado” Requisito inverso
“O sistema somente será implementado em idioma nacional”
Exercício: Fazer o levantamento de Requisitos para o problema a seguir:
A exploração e produção de petróleo em águas profundas é difícil e
custosa. Para tanto, são utilizados robôs tanto para perfuração como para instalação dos equipamentos. Estes robôs são controlados a distância e configurados de acordo com a operação que irão realizar. Atualmente, o treinamento para capacitar as pessoas a utilizarem estes robôs são feitos com os próprios robôs, causando um alto custo de manutenção. Deseja-se um sistema, simulador virtual, que possa se comportar exatamente como o robô real, com uma série de benefícios, tais como: painel gráfico de controle exatamente igual ao controlador do robô; cadastro de usuários para que seja gravado um acompanhamento e histórico do aluno e este possa ser avaliado; acesso, pelos instrutores, aos dados de cada aluno. É necessário que o ambiente do robô seja simulado graficamente, bem como os aspectos físicos: sua colisão com objetos, fricção com a água, tempo de resposta. Além disso, o simulador deve permitir uma ampla configuração de variáveis do robô.
Exemplos de Requisitos
Requisito funcional“O sistema deve controlar o horário de entrada e saída dos funcionários” Requisito não funcional
“O relatório mensal dos horários, por funcionários, deve ser impresso em papel timbrado” Requisito inverso
“O sistema somente será implementado em idioma nacional”