1Engenharia de Requisitos - Universidade da Madeira

Engenharia de Requisitos2 - Conceitos Básicos da Engenharia de Requisitos

Pedro CamposProfessor Auxiliar, Universidade da Madeira

http://dme.uma.pt/pcampos - pcampos@uma.pt

2Engenharia de Requisitos - Universidade da Madeira

O que é a engenharia?

• “A engenharia é o desenvolvimento de soluções para problemas práticos comcusto eficiente, através da aplicação de conhecimento científico.”

• “Custo eficiente”...– Consideração de prós e contras no design da solução, sobretudo utilização de recursos– Minimizar os impactos negativos (por exemplo custo social ou ambiental)

• “Soluções”...– Ênfase na construção de dispositivos

• “Problemas práticos”...– Resolução de problemas que realmente interessam às pessoas– Melhoria da qualidade de vida humana através do progresso tecnológico

• “Aplicação de conhecimento científico”...– Aplicação sistemática de técnicas analíticas

3Engenharia de Requisitos - Universidade da Madeira

Dispositivos versus Sistemas

• Design normal:– Velhos problemas, soluções conhecidas

• O engenheiro selecciona os métodos e técnicas adequados

– O design foca-se nos dispositivos bem compreendidos• As diferenças entre o modelo matemático e o mundo real são mínimas

• Design radical:– Nunca foram feitos, ou soluções passadas falharam

• Normalmente o design radical envolve um problema muito complexo

– Conjugar dispositivos complexos e transformá-los em novos sistemas• Soft systems: quando não há critérios objectivos para a descrição do sistema

• Exemplos:– A maior parte da engenharia de computadores envolve design normal– A engenharia de sistemas envolve design radical (por definição)– Muita da engenharia de software envolve design radical (soft systems)

4Engenharia de Requisitos - Universidade da Madeira

O Software é diferente??

• Ya, o software é diferente!– O software é invisível, intangível e abstracto

– Não há leis físicas que expliquem o comportamento do software

– Não há restrições físicas à complexidade do software• As medidas de fiabilidade tradicionais não se aplicam

– O software nunca se gasta e pode ser replicado na perfeição!• Não há variação no fabrico

• Mitos do software:– Mito: o custo do software é menor que o custo dos dispositivos físicos

– Mito: o software é fácil de mudar

– Mito: os computadores são mais fiáveis que dispositivos físicos

– Mito: pode-se profvar formalmente a correcção do software

– Mito: a reutilização do software aumenta a segurança e a fiabilidade

– Mito: os computadores reduzem o risco sobre os sistemas mecânicos?

5Engenharia de Requisitos - Universidade da Madeira

Responsabilidade profissional

• Código de ética ACM/IEEE– PÚBLICO: actuar consistentemente de acordo com o interesse público– CLIENTE E EMPREGADOR: actuar de forma a servir os interesses do seu cliente e empregador,

consistenmente de acordo com o interesse público– PRODUTO: assegurar-se o mais possível de que os produtos e modificações relacionadas vão de

encontro às normas profissionais– JUÍZO PROFISSIONAL: manter integridade e independência no seu juízo profissional– GESTÃO: subscrever e promover uma abordagem ética à gestão do desenvolvimento e

manutenção do software– PROFISSÃO: avançar a integridade e reputação da profissão de acordo com o interesse público– COLEGAS: ser justo e apoiante dos colegas– AUTO-ÉTICA: participar numa aprendizagem ao longo de toda a vida e promover uma

abordagem ética à prática da profissão

• De particular relevância para a ER:– Competência: nunca exibir erradamente o seu nível de competência– Confidencialidade: respeitar a confidencialidade de todos os stakeholders– Direitos de propriedade intelectual: respeitar os autores de ideias e designs– Protecção de dados: ter conhecimento de todas as leis sobre gestão de dados pessoais

6Engenharia de Requisitos - Universidade da Madeira

Gestão de projectos

• O gestor pode controlar 4 coisas:– Recursos (pode obter mais Euros, instalações, pessoal, ...)

– Tempo (pode aumentar o escalonamento, adiar entregas, etc.)

– Produto (pode reduzir funcionalidades, i.é, afinar os requisitos)

– Risco (pode decidir que riscos são aceitáveis)

• Para fazer isso, o gestor precisa de registar:– Esforço - quanto esforço será necessário? Quanto já foi dispendido?

– Tempo - qual o escalonamento esperado? Estamos muito afastados do planeamento?

– Dimensão - Qual o tamanho do sistema planeado? Quanto já o construímos?

– Defeitos - Quantos erros estamos a cometer? Quantos detectamos?

• Inicialmente, o gestor precisa de boas estimativas– ...e estas apenas se podem obter através de uma boa análise do problema!

Só consegue controlar aquilo que consegue medir!

7Engenharia de Requisitos - Universidade da Madeira

De onde vêm os projectos?

• Iniciacão do projecto– Guiado pelo problema

• Surgiu um problema que necessita deresposta

• Exº: um sistema falhou

– Guiado pela mudança• Os sistemas existentes tornaram-se inúteis

– Guiado pela oportunidade• Nova tecnologia abre as portas a novas

oportunidades

• Surgem novos mercados

– Guiado por herança• O projecto é criado devido a um

compromisso assumido anteriormente

• Exº: trabalho anterior foi deixado inacabado

• Fonte dos requisitos:– Específicos do cliente

• Cliente específico com problema específico• O cliente é a máxima autoridade

– Baseados no mercado• Sistema desenhado para ser vendido em

larga escala• A equipa de marketing actua como um

proxy para clientes e utilizadores

– Socialmente úteis• O sistema é visto como sendo benéfico

para a sociedade em geral• Não há cliente (a pagar)• Exºs: software open-source, software criado

em projectos de investigação

– Híbridos• Desenvolvido para um cliente específico

mas com ideia de vender envetualmente

8Engenharia de Requisitos - Universidade da Madeira

Tipos de software

• Sistemas de Informação– Software de suporte ao trabalho organizacional– Inclui ficheiros e bases de dados assim como aplicações– Mais de 70% de todo o software cai nesta categoria, escrito em linguagens como

COBOL, 4GLs, etc.• Exemplos: transacções financeira, pessoal, base de dados de clientes (CRMs), ERPs, ...

• Sistemas de Controlo– Software que controla parte de um processo de hardware

• Exemplos: controlo de voos, fábrica industrial, sistema de elevadores, ...

• Serviços genéricos– Sistemas que fornecem serviços a outros sistemas

• Exemplos: motores de busca, serviços de acções da bolsa, processamento de cartões decrédito, etc. ...

– Tais sistemas são desenvolvidos usando uma variedade de linguagens e middleware,incluindo Java, C++, Corba, HTML/XML, ...

9Engenharia de Requisitos - Universidade da Madeira

O Contexto de um projecto

• Sistema existente– Quase sempre já existe um sistema

• Pode ser apenas uma série de atalhos ad hoc para resolver o problema

– Estudá-lo é importante!• Temos de evitar as fraquezas do sistema anterior, e preservar o que os stakeholders gostam

• Componentes pré-existentes– Benefícios

• Podem reduzir dramaticamente o custo de desenvolvimento• Mais fácil decompor o problema se alguns dos sub-problemas já estiverem resolvidos

– Tensão• Resolver o problema real vs. resolver o problema conhecido (com uma solução pronta)

• Famílias de produtos– Famílias verticais: exº versão Básica, Deluxe e Pro de um produto– Famílias horizontais: sistemas semelhantes usados em domínios parecidos

• Necessidade de definir uma arquitectura comum que suporta a variação antecipada

10Engenharia de Requisitos - Universidade da Madeira

O ciclo de vida de um projecto de engenharia

• Modelos de ciclo de vida– Úteis para comparar projectos em termos gerais

– Sem detalhe suficiente para planear o projecto

• Exemplos– Modelos sequenciais: Cascata, Modelo V

– Prototipagem rápida

– Modelos faseados: incremental, evolucionário

– Modelos iterativos: espiral

– Modelos ágeis: Extreme Programming

• Comparação: modelos de processos– Usados para capturar e melhorar o processo de desenvolvimento

11Engenharia de Requisitos - Universidade da Madeira

Cascata

• Vista do desenvolvimento– Um processo de refinamento por passos

– Uma vista de gestão de alto nível

• Problemas:– Vista estática dos requisitos - ignora a

volatilidade

– Falta de envolvimento dos utilizadoresuma vez escrita a especificação

– Separação irrealista entre especificação edesenho

– Não se acomoda à prototipagem,reutilização, ...

12Engenharia de Requisitos - Universidade da Madeira

Modelo V

13Engenharia de Requisitos - Universidade da Madeira

Ciclo de vida da prototipagem

• É usada para:– Compreender os requisitos da interface com o utilizador– Examinar a viabilidade de uma abordagem de design proposta– Explorar assuntos ao nível do desempenho do sistema

• Problemas:– Os utilizadores tratam o protótipo como se fosse o produto final– Um protótipo é apenas uma especificação parcial

14Engenharia de Requisitos - Universidade da Madeira

Modelos de ciclo de vida faseados

15Engenharia de Requisitos - Universidade da Madeira

Modelo espiral

16Engenharia de Requisitos - Universidade da Madeira

Modelos ágeis: Extreme Programming

17Engenharia de Requisitos - Universidade da Madeira

Existirá um”ciclo de vida” de requisitos?

18Engenharia de Requisitos - Universidade da Madeira

Ciclo de inquéritos

19Engenharia de Requisitos - Universidade da Madeira

Conclusões

• O que é a engenharia?– Não muito diferente da ciência– Maior consciência da responsabilidade profissional

• Devido ao âmbito imediato de potencial dano público

– Engenharia de sistemas e engenharia de software envolvem design radical

• Projectos de engenharia– Não conseguimos controlar o que não conseguimos medir– Restrições

• Existe um cliente?• Sistema existente / Componentes existentes / família de produtos existente

• Ciclos de vida dos projectos– Úteis para comparar projectos em termos gerais– Representam filosofias de desenvolvimento de software diferentes– Os requisitos também evoluem ao longo do seu próprio ciclo de vida