Engenharia de Software

Apresentação em tema: "Engenharia de Software"— Transcrição da apresentação:

1 Engenharia de Software
Análise e Desenvolvimento de Sistemas Engenharia de Software Janete Pereira do Amaral

2 REQUISITOS DE SOFTWARE
Área de Conhecimento (SWEBOK) dividida nos seguintes tópicos: Fundamentos de Requisitos de Software Processo de Requisitos Elicitação de Requisitos - captura, descoberta, aquisição Análise de Requisitos - detecção e resolução de conflitos, descoberta dos limites e interações do sistema com o ambiente (mapeamento dos requisitos do sistema para requisitos do software) Especificação de Requisitos - estrutura, qualidade e verificação do documento de requisitos Validação de Requisitos - verificação de omissões, conflitos e ambigüidades + adequação às normas de qualidade Considerações Práticas - gestão de mudanças, manutenção da consistência com as fases posteriores

3 REQUISITOS DE SOFTWARE - FUNDAMENTOS
REQUISITOS: Definição É uma propriedade que deve ser exibida no software, para solucionar algum problema no mundo real. Um problema pode ser: - automatizar parte de uma tarefa de alguém que utilizará o software - suportar os processos do negócio da organização - corrigir saídas de um software existente - controlar um dispositivo, etc. Os requisitos de software são uma combinação complexa das exigências de diferentes pessoas, em diferentes níveis numa organização, e do ambiente em que o software operará. Uma propriedade essencial de todos os requisitos de software é que seja verificável. Pode ser difícil ou caro verificar determinados requisitos de software. Ex.: A verificação dos requisitos de desempenho de um Call-Center pode requerer o desenvolvimento de um software de simulação.

4 REQUISITOS DE SOFTWARE - 3 NÍVEIS
Requisitos do Usuário Declarações em linguagem natural e também em diagramas, sobre as funções que o sistema deve fornecer e as restrições sobre as quais deve operar. Problemas encontrados: Falta de clareza / Confusão de requisitos / Fusão de requisitos Requisitos de Sistema – Especificação Funcional Estabelecem detalhadamente as funções e as restrições de sistema. O documento de requisitos de sistema, algumas vezes chamado de especificação funcional, deve ser preciso. Ele servirá como um contrato entre o comprador do sistema e o desenvolvedor do software. Especificação de Projeto de Software É uma descrição abstrata de projeto de software; que é uma base para o projeto e a implementação mais detalhados. Essa especificação acrescenta mais detalhes à especificação de requisitos do sistema. Sommerville

5 REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS
Descrevem as funções que o software deve executar. Por exemplo: formatar um texto ou modular um sinal. São conhecidos como capacidades disponíveis no software Requisitos Não-Funcionais São aqueles que atuam restringindo a solução. São chamados de restrições ou requisitos de qualidade. São os requisitos inerentes à performance, manutenibilidade, segurança, confiabilidade, etc.

6 REQUISITOS NÃO-FUNCIONAIS

7 DEFINIÇÃO DE REQUISITOS - Modelo FURPS+ (RUP)
(Functionality, Usability, Reliability, Performance e Supportability) Categoria Funcionalidade (Functionality) Conjuntos de recursos / Habilidades / Segurança Usabilidade (Usability) Fatores humanos / Estética / Consistência na interface do usuário / Ajuda on-line e contextual / Assistentes e agentes / Documentação do usuário / Materiais de treinamento Confiabilidade (Reliability) Freqüência e gravidade de falha / Possibilidade de recuperação / Possibilidade de previsão / Exatidão / Tempo médio entre falhas (MTBF) Desempenho (Performance) Velocidade / Eficiência / Disponibilidade / Exatidão / Taxa de transferência / Tempo de resposta / Tempo de recuperação / Uso de recursos Suportabilidade (Supportability) Possibilidade de teste / Extensibilidade / Adaptabilidade / Manutenibilidade / Compatibilidade / Possibilidade de configuração / Possibilidade de serviço / Possibilidade de instalação / Possibilidade de localização (internacionalização) "+" em FURPS+ inclui ainda os requisitos: restrições de design, requisitos de implementação, requisitos de interface e requisitos físicos

8 REQUISITOS DE SISTEMA E REQUISITOS DE SOFTWARE
Sistema significa uma combinação de elementos para realizar um objetivo definido. Inclui hardware, software, firmware, pessoas, informações, técnicas, funcionalidades, serviços e outros elementos de suporte Requisitos de Sistema são requisitos para o sistema como um todo. Compreende requisitos do usuário, requisitos de outros patrocinadores (tais como agências reguladoras) e requisitos sem fonte humana identificável. Num sistema contendo componentes de software, os Requisitos de Software são derivados dos requisitos de sistema

9 Podem ser requisitos funcionais e não-funcionais
REQUISITOS DE DOMÍNIO São requisitos que se originam do domínio da aplicação do sistema e que refletem características deste domínio. Podem ser requisitos funcionais e não-funcionais

10 PROCESSO DE REQUISITOS
Modelos de Processo de Requisitos Não é uma atividade discreta do início do ciclo de vida do software, mas um processo iniciado no começo do projeto e que continua sendo refinado durante todo o ciclo. Identifica os requisitos de software como itens de configuração e gerencia estes itens usando as mesmas práticas de gerência de configuração, como os demais produtos do processo Necessita ser adaptado para a organização e para o contexto do projeto Compreende as atividades de elicitação, análise, especificação e validação que são configuradas para diferentes tipos de projetos e restrições. Inclui também atividades que fornecem entrada para o processo de requisitos, tais como marketing e estudo de viabilidade.

11 PROCESSO DE REQUISITOS
Estudo de Viabilidade O processo de Engenharia de Requisitos deve começar com um estudo de viabilidade. É um estudo breve, direcionado, que se destina a responder a algumas perguntas: O sistema contribui para os objetivos gerais da organização? O Sistema pode ser implementado com a utilização da tecnologia atual dentro das restrições de custo e de prazo? O Sistema pode ser integrado com outros sistemas em operação? Depois do Estudo de Viabilidade, o próximo estágio do processo é a Elicitação e a Análise de Requisitos

12 PROCESSO DE REQUISITOS
Atores do Processo - O papel dos que participam do processo de requisitos Usuários – Aqueles que operam o software. É frequentemente um grupo heterogêneo, compreendendo pessoas com diferentes papéis e requisitos - Clientes – Aqueles que adquirem o software ou que representam o mercado-alvo do software - Analistas de Mercado – Um produto de massa não tem um cliente específico. As pessoas de marketing necessitam estabelecer o que o mercado necessita, e agir como um interlocutor dos clientes Reguladores – Muitos tipos de aplicação, tais como aplicações bancárias e aplicações para transportes públicos são regulamentadas. Software nestes domínios devem obedecer aos requisitos impostos pelas autoridades reguladoras Engenheiros de Software – Estes indivíduos têm interesse na lucratividade do desenvolvimento de software, por meio do reuso de componentes. Se o cliente possui um requisito que compromete o potencial para reuso, o engenheiro de software deve ponderar seus objetivos em relação aos objetivos do cliente Nem sempre é possível atender perfeitamente aos requisitos de todos os envolvidos. O trabalho do engenheiro de software é negociar um meio termo que seja aceitável para os principais patrocinadores, dentro das restrições orçamentárias, técnicas, legais e outras.

13 ELICITAÇÃO DE REQUISITOS
Seu objetivo é identificar a origem dos requisitos e como os Engenheiros de Software podem coletá-lo É o primeiro estágio na construção do entendimento do problema que o software deverá solucionar. É fundamentalmente um atividade humana. A elicitação de requisitos é também chamada de captura de requisitos, descoberta de requisitos e aquisição de requisitos Um dos princípios da Engenharia de Software é estabelecer uma boa comunicação entre Usuários e Engenheiros de Software. Antes de começar o desenvolvimento de um software, o especialista em requisitos deve fazer a ponte para esta comunicação. Eles devem mediar entre o domínio dos usuários e o mundo técnico dos engenheiros de software

14 FONTES DE REQUISITOS Num software, os requisitos podem ter várias fontes. É essencial que todas elas sejam avaliadas quanto a seu impacto no software: Objetivos - Refere-se aos objetivos de alto nível do software. Fornecem a motivação para o software, mas frequentemente eles são vagamente formulados. Engenheiros de Software necessitam dar atenção à determinação das prioridades e custos dos objetivos. Um estudo de viabilidade é um instrumento considerado de baixo custo para realizar esta avaliação. Conhecimento do Domínio – O Engenheiro de Software necessita adquirir ou ter disponível conhecimento sobre o domínio da aplicação. Este conhecimento permite ao Engenheiro de Software inferir o conhecimento tácito (não articulado) dos patrocinadores e determinar o trade-offs necessário entre os requisitos conflitantes, podendo muitas vezes ser necessário tomar decisões.

15 FONTES DE REQUISITOS 3. Patrocinadores - Muitos softwares tornam-se insatisfatório porque levam em conta apenas os requisitos de um grupo de patrocinadores. Quando o software é disponibilizado observa-se a dificuldade em seu uso a inadequação à estrutura cultural e política dos clientes da organização. O Engenheiro de Software necessita identificar, representar e gerenciar os pontos de vista dos diferentes tipos de patrocinadores. 4. O Ambiente Operacional – Requisitos são derivados do ambiente em que o software será executado. Por exemplo: restrições de tempo para software de tempo real ou restrições de interoperabilidade em ambientes de escritório. Isto deve ser bem analisado, porque poderá afetar os custos, a viabilidade, além de restringir as escolhas do projeto. 5. O Ambiente Organizacional – Software é frequentemente requerido para fornecer suporte a um processo de negócio, o qual está condicionado pela estrutura, cultura e políticas internas da organização. O Engenheiro de Software necessita estar sensível a isto, uma vez que o novo software não deve forçar mudanças não planejada nos processos de negócio.

16 TÉCNICAS DE ELICITAÇÃO DE REQUISITOS
Uma vez que as fontes de requisitos foram identificadas, o Engenheiro de Software pode iniciar a elicitação dos requisitos. São técnicas para os patrocinadores articularem seus requisitos. O Engenheiro de Software necessita ser sensibilizado para o fato de que usuários podem ter dificuldade em descrever suas tarefas, podem deixar de prestar informações importantes ou não estarem dispostos à cooperar. É importante entender que a elicitação não é uma atividade passiva, e mesmo que os patrocinadores sejam cooperativos e articulados, o Engenheiro de Software ainda terá que trabalhar duramente para elicitar a informação correta. Existem várias técnicas para elicitação de requisitos, tais como: Entrevista / Questionário Observação Direta Cenários Protótipos Reuniões facilitadas / JAD Pontos de Vista UML - Casos de Uso Inspeção

17 TÉCNICAS DE ELICITAÇÃO DE REQUISITOS
Entrevista - É um meio tradicional de elicitar requisitos. É importante entender as vantagens e limitações das entrevistas e como elas devem ser conduzidas. Cenários - É um valoroso meio para fornecer contexto a elicitação de requisitos. Ele permite o Engenheiro de Software fornecer um framework para questões sobre tarefas do usuário permitindo serem feitas questões do tipo ‘e se’ e ‘como isto é feito’. O exemplo mais comum de cenários é o Casos de Uso Protótipo - É uma ferramenta de muito valor para a clarificação de requisitos. Eles podem agir numa forma similar aos cenários, fornecendo aos usuários um contexto que permite melhor entender quais informações eles necessitam fornecer. Há uma grande variedade de técnicas de prototipação, que vai desde o projeto de telas em papel até versões beta-teste de produtos de software

18 TÉCNICAS DE ELICITAÇÃO DE REQUISITOS
Reuniões Facilitadas - O propósito é obter um esforço conjunto, partindo-se da hipótese que um grupo de pessoas pode trazer mais insights para os requisitos de software que pessoas isoladas. Nestas reuniões podem ser realizados brainstorms e refinamento de idéias que nem sempre é possível realizar em outras técnicas. Uma outra vantagem é que os requisitos conflitantes emergem mais rapidamente, permitindo que os patrocinadores vejam onde se encontra o conflito. Esta técnica pode resultar num mais rico e consistente conjunto de requisitos. Estas reuniões necessitam serem cuidadosamente manuseadas para prevenir situação não desejáveis. Observação direta - A importância do contexto do software dentro do ambiente organizacional tem levado à adaptação de técnicas de observação para a elicitação de requisitos. Engenheiros de Software aprendem sobre as tarefas dos usuários imergindo no ambiente e observando como os usuários interagem com o software, e com os demais usuários. Estas técnicas são relativamente caras, mas permitem mostrar que muitas tarefas dos usuários e os processos de negócios são muito complexos para seus atores descreverem facilmente.

19 ANÁLISE DE REQUISITOS Objetivo:
Detectar e resolver conflitos entre os requisitos Descobrir os limites do software e como ele deve interagir com seu ambiente Elaborar os requisitos do sistema para derivar os requisitos do software Cuidado deve ser tomado para descrever requisitos precisamente para ser possível validar os requisitos, verificar sua implementação e estimar seus custos Classificação de Requisitos Se os requisitos são funcionais ou não-funcionais Se os requisitos são derivados de um ou mais requisitos de alto nível ou de uma propriedade emergente ou está sendo imposto diretamente por um patrocinador ou alguma outra fonte Se o requisito é do produto ou do processo. Requisitos do processo podem restringir a escolha da empresa a ser contratada, o processo de Engenharia de Software ou os padrões a serem adotados.

20 ANÁLISE DE REQUISITOS A Prioridade dos Requisitos
Em geral, os requisitos de maior prioridade e os mais essenciais são aquele que atingem os objetivos do software. A prioridade é frequentemente classificada numa escala fixa, como obrigatória, altamente desejável, desejável e opcional. A prioridade tem que ser balanceada em relação aos custos de desenvolvimento e de implementação. O Escopo dos Requisitos Refere-se à extensão na qual o requisito afeta o software e seus componentes. Alguns requisitos, como os não-funcionais, têm um escopo global e sua satisfação não pode ser alocada a um componente específico. Um requisito com escopo global pode afetar a arquitetura do software e o projeto de muitos componentes, enquanto aqueles com o escopo mais estreito pode oferecer uma variedade de opções de projeto e têm pouco impacto na satisfação de outros requisitos. Volatilidade/Estabilidade Alguns requisitos mudam durante o ciclo de vida do software, e até mesmo durante o processo de desenvolvimento. É importante prever a probabilidade das mudanças de requisitos acontecerem. Identificar os requisitos potencialmente voláteis pode auxiliar na elaboração de um projeto que seja mais tolerante a falhas.

21 ANÁLISE DE REQUISITOS Modelagem Conceitual
O desenvolvimento de modelos dos problemas do mundo real é o ponto chave para a análise de requisitos. Seu propósito é auxiliar no entendimento do problema antes do início do projeto da solução. Modelos conceituais compreendem modelos das entidades do domínio do problema configurados para refletir os relacionamentos e dependências do mundo real. Vários tipos de modelos podem ser elaborados. Tais como fluxos de controle e de dados, modelos de estado, trace de eventos, interações dos usuários, modelos de objetos, modelos de dados e muitos outros Dentre os fatores que influenciam a escolha de um modelo incluem: 1- A natureza do problema. Alguns software demandam certos aspectos a serem analisados rigorosamente. Ex.: modelos de controle de fluxo e de estado são mais apropriados para software de tempo real que para software de gerenciamento de informações. O oposto se dá para modelos de dados. 2- A experiência do Engenheiro de Software É frequentemente mais produtivo adotar a notação de modelagem ou o método que o Engenheiro de Software tenha mais experiência.

22 ANÁLISE DE REQUISITOS Negociação de Requisitos
3- O Processo de Requisitos do Cliente Clientes podem impor sua notação, seu método favorito, ou proibir aquele que não lhe seja familiar. 4- A Disponibilidade de Métodos e Ferramentas Notações ou métodos que não são bem suportados por treinamento ou por ferramenta podem não obter larga aceitação, mesmo se ele for apropriado para determinado tipo de problema Na maioria dos casos, é útil iniciar construindo um modelo de contexto. O contexto do software fornece a conexão entre o software e seu ambiente externo. É importante entender o contexto do software em seu ambiente operacional e identificar suas interfaces com este ambiente. Negociação de Requisitos Um outro termo para negociação de requisitos é resolução de conflitos. Na resolução de problemas com requisitos onde ocorrem conflitos entre patrocinadores requerendo caraterísticas incompatíveis

23 ESPECIFICAÇÃO DE REQUISITOS
O termo “Especificação dos Requisitos de Software” refere-se à produção de um documento que deve ser sistematicamente revisado, avaliado e aprovado. Para sistemas complexos três diferentes tipos de documentos devem ser produzidos: Definição do sistema, Requisitos do Sistema e Requisitos de Software. Para software simples, somente um destes três é requerido. 1. Documento de Definição do Sistema Registra os requisitos do sistema numa perspectiva de alto nível. Dentre seus leitores estão os representantes dos usuários do sistema e clientes. Seu conteúdo deve ser apresentado com termos do domínio do problema. O documento lista os requisitos do sistema com informações sobre os objetivos globais do sistema, o ambiente alvo, restrições, definições e requisitos não funcionais. Ele também pode incluir modelos conceituais para ilustrar o contexto do sistema, cenários e entidades do domínio, bem como dados, informações e fluxos de trabalho.

24 ESPECIFICAÇÃO DE REQUISITOS
2. Especificação de Requisitos do Sistema Separam a descrição dos requisitos do sistema da descrição dos requisitos do software. Nesta visão, os requisitos do sistema é especificado, os requisitos do software são derivados dos requisitos do sistema e os requisitos para os componentes do software são especificados. 3. Especificação de Requisitos de Software A especificação dos requisitos de software estabelecem as bases para o acordo entre clientes e fornecedores sobre o que o produto software deve fazer, como também o que não é esperado que seja feito. Para leitores não técnicos, o documento de especificação de requisitos é frequentemente acompanhado pelo documento de definição de requisitos Requisitos de software são frequentemente escritos em linguagem natural, mas na especificação de requisitos de software, isto pode ser suplementado por descrições formais e semi-formais

25 VALIDAÇÃO DE REQUISITOS
O documento de requisitos deve ser submetido ao procedimento de validação de verificação. O requisitos devem ser validados para assegurar que o Engenheiro de Software entendeu os requisitos. É importante que o documento de requisitos esteja em conformidade com os padrões da empresa e seja entendível, consistente e completo. Notações formais oferecem uma vantagem importante de permitir que as propriedades sejam provadas. Os patrocinadores, incluindo representantes dos clientes e desenvolvedores, devem revisá-los Documentos de requisitos devem ser tratados como nas práticas de gerência de configuração, ou seja, como qualquer artefato do processo de desenvolvimento de software É normal que seja especificado um ou mais pontos no processo de requisitos nos quais os requisitos serão validados. O objetivo é identificar qualquer problema antes dos recursos serem alocados para atender o requisito

26 REVISÃO DOS REQUISITOS
Validação por inspeção ou revisão dos documentos de requisitos. Um grupo de revisores é designado para procurar erros, falhas de definição, falta de clareza e desvios dos padrões. A composição do grupo que conduz a revisão é importante e deve ser guiado por um check-list.

27 VALIDAÇÃO DE REQUISITOS
Prototipação Prototipação é um meio para a validação da interpretação do requisitos do software, bem como para elicitação de novos requisitos. A vantagem dos protótipos é que eles podem tornar mais explícita a interpretação das decisões do Engenheiro de Software, e quando necessário, fornecer feedback ou explicitar o porque eles estão errados Várias pessoa recomendam o uso de protótipo que evitam software, devido ao custo de seu desenvolvimento. Entretanto, se na construção do protótipo for evitado gastos de recursos causado pela tentativa de satisfazer requisitos errôneos, eles podem ser mais facilmente justificados Validação do Modelo É necessário validar a qualidade dos modelos desenvolvidos durante a análise. Ex.: No modelos de objetos -> fazer a análise estática para verificar o fluxo de comunicação entre os objetos. Testes de Aceitação Uma propriedade dos requisitos de um software é que deve ser possível validá-lo para saber se o produto final satisfará. Requisitos que não podem ser validados são considerados “desejos”. Uma tarefa importante é planejar como verificar cada requisito. Identificar e projetar teste de aceitação pode ser difícil para requisitos não funcionais. Para serem validados, deve ser observado se eles podem ser quantificados

28 PROBLEMAS NA ÁREA DE REQUISITOS
Comunicação Domínio de aplicação mal definido Inconsistências Falta de completeza Ambigüidade Falta de métricas TEMAS DE PESQUISA Combinar diferentes Técnicas de Elicitação Definir métricas Criar ferramentas para automatizar o processo de requisitos Desenvolver métodos (ou adaptar os já existentes) para Processos Ágeis Pesquisar Requisitos de Software Livre e similares