A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Engenharia de Software Cláudio Larieira

Apresentações semelhantes


Apresentação em tema: "Engenharia de Software Cláudio Larieira"— Transcrição da apresentação:

1 Engenharia de Software Cláudio Larieira

2 2 Plano de Aula – 3o. período Requisitos Conceitos Tipos de requisitos Atividades de gestão e engenharia Técnicas de elicitação Fontes de requisitos Workshop sobre Requisitos Estimativas Conceitos Estimativas de Tamanho e Esforço : FPA, UCP, LOC e WBS Métricas de Software Conceitos Possíveis Indicadores

3 3 Requisitos

4 4 Pondo em prática... Você aceitaria ou não o documento de requisitos do Sistema de Segurança apresentado ? E o projeto ?

5 5 Dificuldades em se obter Requisitos Usuários nem sempre sabem o que efetivamente desejam do sistema Diferença de linguagem entre os usuários e a equipe de projeto, ocasionando problemas de entendimento Requisitos iguais, expressados de maneira diferente, por diferentes usuários Fatores políticos na definição de requisitos Constante mudança de requisitos em função de mudanças de cenário econômico e de negócio Ansiedade dos usuários em ter o software implementado rapidamente, não permitindo que se executem adequadamente as atividades de requisitos Resistência ao software a ser implementado Complexidade dos problemas de negócio

6 6 Requisitos Segundo IEEE (The Institute of Electrical and Electronics Engineers), Requisito é : Uma condição ou capacidade requerida por um usuário para resolver um problema ou atingir um objetivo Uma condição ou capacidade que deve ser atingida ou possuída por um sistema ou partes de um sistema para satisfazer um contrato, padrão, especificação ou outros documentos

7 7 Características de um Requisito Segundo Wiegers, todo requisito deve ser : Completo – descrevendo plenamente a necessidade a ser implementada Correto – atendendo de maneira inequívoca a necessidade solicitada Exequível – podendo ser implementado dentro das limitações e ambiente do sistema Necessário – correspondendo a algo que o usuário realmente necessita Priorizado – podendo ser alocado nas iterações ou release de um software conforme o momento adequado Não ambíguo – sem margem de dúvidas ou de interpretação Verificável – passível de verificação e validação

8 8 Tipos de Requisito Os requisitos se dividem em : Requisitos de Usuário – descrevendo as funções que o sistema deverá ter e as limitações sob as quais deverá operar Requisitos de Sistema – descrevendo a maneira como o sistema deverá responder às necessidades dos usuários Requisitos de Software – descrevendo detalhadamente a maneira como o software deverá ser construído

9 9 Requisitos de Sistema Os requisitos de sistema se dividem em : Funcionais – descrevendo os comportamentos esperados para o sistema Não funcionais – descrevendo as restrições sobre os serviços ou as funções oferecidas pelo sistema, tais como : De produto : facilidade de uso, desempenho, espaço, confiabilidade e portabilidade Organizacionais : entrega, implementação e padrões Externos : interoperabilidade, éticos e legais

10 10 Requisitos Não-funcionais (segundo Sommerville) Requisitos de Eficiência Requisitos de Confiabilidade Requisitos de Portabilidade Requisitos do Produto Requisitos Externos Requisitos Organizacionais Requisitos Não Funcionais Requisitos de Facilidade de Uso Requisitos de Desempenho Requisitos de Espaço Requisitos de Implementação Requisitos de Entrega Requisitos de Padrões Requisitos de Interoperabilidad e Requisitos Éticos Requisitos de Privacidade Requisitos de Segurança Requisitos Legais

11 11 Fontes de Requisitos Requisitos podem ser obtidos através de : Entrevistas e discussões com potenciais usuários Documentos sobre produtos próprios ou de concorrentes Especificações de sistemas atuais Relatórios de problemas ou de solicitação de melhoria de sistemas atuais Pesquisas de marketing ou questionários de usuários Observação de usuário trabalhando Análise de cenários

12 12 Atividades de Requisitos Os requisitos são tratados em Engenharia de Software sob duas perspectivas : Engenharia de Requisitos : atividades relacionadas ao desenvolvimento do requisito Gestão de Requisitos : atividades relacionadas ao gerenciamento dos requisitos documentados

13 13 Atividades de Requisitos Analisa, Documenta, Revisa, Negocia Mercado, Cliente, Gerenciamento Requisitos Requisitos em Baseline Desenvolvimento de Requisitos Gestão de Requisitos Processo de Mudança de Requisitos Baseline corrente Baseline revisada Mercado, Cliente, Gerenciamento Ambiente de Projeto Mudanças de Requisitos Mudanças de Projeto

14 14 Atividades de Requisitos Engenharia de Requisitos envolve : Elicitação – identificar os usuários e coletar os requisitos Análise – compreender o domínio do problema, resolver conflitos e priorizar requisitos Especificação – documentar os requisitos de maneira compreensível, através de modelagem Verificação - garantir que eles estejam adequados

15 15 Atividades de Requisitos Gestão de Requisitos envolve : Identificação – garantir que cada requisito tenha uma identidade única dentro do projeto Controle de Mudanças – avaliar o impacto e o custo as mudanças Rastreabilidade - permitir que haja uma amarração entre os requisitos documentados e a implementação do software Manutenção da baseline – garantir a integridade da base de requisitos do projeto

16 16 Documentos de Requisitos Todos os requisitos a serem implementados devem ser consolidados em um artefato onde possam ser identificados e claramente especificados para que componham a baseline do projeto de software Os documentos de requisitos devem ser colocados sob gestão de configuração para que se mantenha a integridade das informações e visibilidade de progresso e mudanças ao longo do tempo de projeto

17 17 Possíveis abstrações de Documentos de Requisitos Documento de Definição do Sistema - requisitos em um nível mais alto, com a visão de negócio ou de sistema, para que se estabeleça um entendimento e comprometimento dos requisitos juntos aos usuários System Requirements Specification - requisitos em um nível de abstração intermdíario, com a visão de implementação do sistema Software Requirements Specification - requisitos em um nível de abstração mais baixo, com a visão de implementação do software, para que se apresente à equipe de projeto os requisitos e a solução a ser implementada

18 18 Outras possíveis abstrações de Documentos de Requisitos Requisitos de Negócio Requisitos de Usuário Documento de Visão e Escopo Documento de Caso de Uso Atributos de Qualidade Requisitos Funcionais Requisitos do Sistema Especificação de Requisitos de Software Outros Requisitos Não Funcionais Limitações

19 19 Requisitos Algumas possibilidades de se fazer engenharia de requisitos em projetos de software combinadas com WBS : Usando técnica de Casos de Uso Usando técnicas de Análise Essencial : Diagrama de Contexto, DFD, DER, tabelas de decisão, árvores de decisão e pseudo-código Usando técnicas de JAD Usando técnicas de entrevista e questionário Usando técnicas de Prototipação

20 20 Pondo em prática... E agora que você conhece um pouco mais sobre Requisitos, você aceitaria ou não o documento de requisitos do Sistema de Segurança apresentado ? Liste argumentos para a sua decisão.

21 21 Estimativas

22 22 Estimativas de tamanho de software Métricas mais conhecidas : LOC (line of code) : Através de contagem de linhas de programação obtém- se o esforço necessário WBS (Work Breakdown Structure) : Através de deliverables, encontra-se o tamanho do software FPA (Function Point Adjusted) : Através de contagem dos elementos de transação e de dados, obtém-se o tamanho funcional do software UCP (Use Case Point) : Semelhante ao FPA, porém voltado a Casos de Uso COCOMO (Constructive Cost Model) : Modelo onde se obtém custo, esforço e prazo

23 23 FPA – Function Point Adjusted A métrica de ponto de função, primeiramente proposta por Albrecht (IBM, em 1979), pode ser usada efetivamente como um meio de mensurar as funcionalidades entregues por um sistema. Pontos de Função são derivados usando um relacionamento empírico baseado em medidas quantificáveis do domínio de informação do software e suas respectivas complexidades Estes valores sobre o domínio da informação são definidos da seguinte maneira : Número de external inputs (EIs) Número de external outputs (EOs) Número de external inquiries (EQs) Número de internal logical files (ILFs) Número de external interface files (EIFs)

24 24 Function Points

25 25 Métricas de Software Alguns sites de apoio : FPA : International Function Point Users Group (http://www.ifpug.org) Brazilian Function Point Users Grupo (http://www.bfpug.org)http://www.bfpug.org ISBSG (http://www.isbsg.org) COCOMO : Site com a técnica (http://sunset.usc.edu/research/COCOMOII/index.html)

26 26 Métricas de Software

27 27 Pondo em prática... Pergunta : Como avaliar que a Fábrica de Software do estudo de caso está desempenhando bem? Escolha ao menos 5 maneiras de medir.

28 28 Aprendendo com dados quantitativos e qualitativos Organizações podem aprender e melhorrar através de : Coleta e análise de dados quantitativos sobre processos de desenvolvimento e produtos Coleta e análise de dados qualitativos, por exemplo, o que os desenvolvedores pensam sobre os processos de desenvolvimento e produtos

29 29 Triângulo da Qualidade de McCalls Maintainability Maintainability Flexibility Flexibility Testability Testability Portability Portability Reusability Reusability Interoperability Interoperability Correctness Correctness Reliability Reliability Efficiency Efficiency Integrity Integrity Usability Usability PRODUCT TRANSITION PRODUCT TRANSITION PRODUCT REVISION PRODUCT REVISION PRODUCT OPERATION PRODUCT OPERATION

30 30 Medidas, Métricas e Indicadores Uma medida provê uma indicação quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo de um produto ou processo O glossário IEEE define uma métrica como uma medida quantitativa do grau a qual um sistema, um componente ou um processo possui de um dado atributo. Um indicador é uma métrica ou a combinação de métricas que provêem uma visão sobre um processo de software, um projeto ou o produto propriamente dito

31 31 Descomplicando... O quê é uma métrica ? É um processo que permite aos desenvolvedores/gestores obter visão sobre medidas quantitativas de um software e do processo de software melhorando a eficácia de planejamento e controle Por quê isto é importante ? Elimina a subjetividade das análises a serem realizadas Antecipa tendências na implementação do software Permite realizar comparações

32 32 Métricas de Software O quê é possível medir em um software ? Tamanho Esforço Custo Prazo Risco Recurso computacional crítico Retrabalho Erros em testes Falhas em produção Produtividade da equipe Etc.

33 33 Métricas de Software Quais os possíveis indicadores ? Tamanho – pontos de função, pontos por caso de uso, linhas de código, etc. Esforço – horas de esforço por tipo de complexidade de programa Custo – custo médio por programa Prazo – desvio médio de projeto Retrabalho – quantidade de retornos de teste Erros em testes – quantidade de defeitos em funcionalidade Falhas em produção – quantidade de páginas web não encontradas Produtividade da equipe - número de linhas codificadas por mês Etc.

34 34 Processo de Mensuração Formulação – A derivação das medidas de software e das métricas apropriadas para a representação do que se espera conhecer sobre o software, projeto ou processo. Coleta – O mecanismo usado para acumular os dados requeridos para derivar as métricas formuladas. Análise – A consolidação das informações obtidas e a aplicação de ferramentas matemáticas. Interpretação – A avaliação dos resultados da métrica resulta em um esforço para obter uma visão sobre a qualidade representada do software, projeto ou processo. Feedback – Recomendações derivadas da interpretação das métricas transmitidas ao time de desenvolvimento.

35 35 Pondo em prática... Pergunta : Quais indicadores você estabeleceria para gerenciar sua Fábrica de Software ? Escolha ao menos 5.

36 36 Encerrando nossa aula Nesta aula, tratamos sobre : Requisitos Conhecendo melhor o conceito sobre requisitos, os tipos possíveis e as atividades propostas pela Engenharia de Software para tratá-los Discutindo sobre técnicas de elicitação alternativas à técnica de WBS proposta pelo PMBOK Aprendendo como avaliar de maneira mais objetiva a qualidade dos requisitos recebidos


Carregar ppt "Engenharia de Software Cláudio Larieira"

Apresentações semelhantes


Anúncios Google