Engenharia de Software

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

1 Engenharia de Software
Cláudio Larieira

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 Estimativas de Tamanho e Esforço : FPA, UCP, LOC e WBS Métricas de Software Possíveis Indicadores

3 Requisitos

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

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 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 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 Os requisitos se dividem em :
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 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 Requisitos Não-funcionais (segundo Sommerville)
Requisitos do Produto Requisitos Organizacionais Requisitos Externos Requisitos de Confiabilidade Requisitos de Eficiência Requisitos de Portabilidade Requisitos de Interoperabilidade Requisitos Éticos Requisitos de Facilidade de Uso Requisitos de Entrega Requisitos de Implementação Requisitos de Padrões Requisitos Legais Requisitos de Desempenho Requisitos de Espaço Requisitos de Privacidade Requisitos de Segurança

11 Requisitos podem ser obtidos através de :
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 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 Atividades de Requisitos
Mercado, Cliente, Gerenciamento Requisitos Analisa, Documenta, Revisa, Negocia Desenvolvimento de Requisitos Requisitos em Baseline Gestão de Requisitos Baseline corrente Baseline revisada Processo de Mudança de Requisitos Mercado, Cliente, Gerenciamento Ambiente de Projeto Mudanças de Requisitos Mudanças de Projeto

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 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 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 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 Outras possíveis abstrações de Documentos de Requisitos
Requisitos de Negócio Documento de Visão e Escopo Atributos de Qualidade Requisitos de Usuário Outros Requisitos Não Funcionais Documento de Caso de Uso Requisitos do Sistema Requisitos Funcionais Limitações Especificação de Requisitos de Software

19 Usando técnica de Casos de Uso Usando técnicas de Análise Essencial :
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 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 Estimativas

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 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 Function Points

25 Métricas de Software Alguns sites de apoio : FPA :
International Function Point Users Group ( Brazilian Function Point Users Grupo ( ISBSG ( COCOMO : Site com a técnica (

26 Métricas de Software

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 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 Triângulo da Qualidade de McCall’s
b l y P o r t a b i l y F l e x i b t y R e u s a b i l t y T e s t a b i l y I n t e r o p a b i l y P R O D U C T E V I S N P R O D U C T A N S I P R O D U C T E A I N C o r e c t n s U s a b i l t y E f i c e n y R e l i a b t y I n t e g r i y

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 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 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 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 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 Pondo em prática ... Pergunta :
Quais indicadores você estabeleceria para gerenciar sua Fábrica de Software ? Escolha ao menos 5.

36 Nesta aula, tratamos sobre :
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