Gerência de Requisitos 07/11/2006. Objetivo Conscientizar os participantes da importância dos requisitos no processo de desenvolvimento de sistemas, em.

Apresentação em tema: "Gerência de Requisitos 07/11/2006. Objetivo Conscientizar os participantes da importância dos requisitos no processo de desenvolvimento de sistemas, em."— Transcrição da apresentação:

1 Gerência de Requisitos 07/11/2006

2 Objetivo Conscientizar os participantes da importância dos requisitos no processo de desenvolvimento de sistemas, em conformidade com as normas de qualidade de software

3 Parte I: Introdução a Requisitos

4 Sumário Introdução a Engenharia de Sistemas Problemas do Processo de Desenvolvimento A Importância dos Requisitos no Processo de Desenvolvimento Motivação Conceitos –Regras de Negócio –Requisitos Funcionais e Não Funcionais –ISO/IEC 9126

5 Introdução a Engenharia de Sistemas

6 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

7 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

8 Ciclo de vida clássico (em cascata) Engenharia de Sistemas Análise Projeto Codificação Teste Manutenção

9 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

10 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

11 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.

12 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)

13 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?

14 Como modelar? o que será modelado é função da relevância dos aspectos a serem inseridos no modelo em função do seu objetivo não existe receita "pronta", envolve a intuição, criatividade e julgamento crítico do modelador manutenção de consistência interna dos aspectos representados no modelo validação experimental (correspondência de comportamento previsto a partir do modelo com o comportamento real do sistema)

15 Problemas do Processo de Desenvolvimento

16 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

17 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

18 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

19 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 é fraca Falta de testes sistemáticos e completos

20 Causas menos óbvias Gerentes sem background em desenvolvimento de software Profissionais recebem pouco treinamento formal Falta investimento (em ES) Faltam métodos e automação Falta acompanhamento do processo de desenvolvimento

21 Mitos do Software - Administrativos Um manual oferece tudo que se precisa saber Computadores de última geração solucionam problemas de desenvolvimento Se estamos atrasados, basta adicionarmos programadores e tirar o atraso (chamadoconceito de hordas de mongóis)

22 Mitos do Software - do Cliente Uma declaração geral é suficiente para começar a escrever programas Mudanças podem ser facilmente acomodadas em um projeto

23 Mitos do Software - do Profissional Um programa está terminado ao funcionar Quanto mais cedo escrever o código, mais rápido terminarei o programa Só posso avaliar a qualidade de um programa em funcionamento A única coisa a ser entregue em um projeto é o programa funcionando

24 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.

25 Recursos Humanos – Grau de participação em projetos Análise de requisitos participação baixo alto Grau de no projeto PlanejamentoProjeto preliminar Pessoal técnico senior Pessoal técnico junior Administrador Projeto detalhado Codificação Teste de unidade

26 As 10 Áreas da Engenharia de Software Gerência de Configuração de Software Gerência de Engenharia de Software Processo de Engenharia de Software Ferramentas e Métodos Qualidade de Software Requisitos de software Design de software Construção de Software Teste de Software Manutenção de Software (SWEBOK, 2004)

27 Motivação

28 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)

29 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)

30 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)

31 Pesquisa realizada com 365 gerentes executivos de TI dos EUA Três principais critérios de sucesso 1. Envolvimento do Usuário 2. Apoio da Gerência Executiva 3. Indicação Clara dos Requisitos Projetos falham ou são prejudicados 1. Requisitos Incompletos 2. Falta de Envolvimento do Usuário 3. Falta de Recursos Motivação (Chaos, 1994)

32 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

33 Motivação Mudanças são inevitáveis Razõ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

34 Motivação é preciso gerenciar as mudanças! mudanças em requisitos ao longo do desenvolvimento de software fazem parte do processo alterações em requisitos podem implicar em mudanças em artefatos de design, de código, casos de testes, etc Requisitos que tendem a mudar devem ser tratados isoladamente Isolar regras de negócio para reuso

35 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)

36 A Importância dos Requisitos no Processo de Desenvolvimento

37 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)

38 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

39 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

40 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)

41 Requisitos servem como especificação do que deve ser implementado Requisitos são descrições de como o sistema deve se comportar, de uma propriedade ou atributo do sistema Um 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

42 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

43 Requisitos: diretrizes para elaboração 1/2 Definir um formato padrão e usá-lo para todos os requisitos Utilizar o idioma de forma consistente. Usar deve para requisitos obrigatórios, deveria (ou é recomendável) para requisitos desejáveis Evitar o uso de jargões de computação Empregar termos característicos do problema

44 Requisitos: diretrizes para elaboração 2/2 Use sentenças diretas e objetivas Use vocabulário limitado Defina requisitos verificáveis Evite ambigüidades Evite sentenças muito longas Evite uso de conjunções como ou, e, com, também Evite termos vagos ou indefinidos

45 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

46 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

47 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

48 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

49 Conceitos Regra de Negócio Requisitos Funcionais e Não Funcionais ISO/IEC 9126

50 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

51 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

52 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

53 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

54 Requisitos não funcionais: relacionados a aspectos de qualidade que o software deverá apresentar, ou a restrições a serem atendidas Exemplo: Norma de Qualidade da ISO/IEC 9126 –Dependente da solução Requisitos inversos: representam funcionalidades que estão fora do escopo da solução

55 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

56

57 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