Aula 9 Especificação de Requisitos

Documentos relacionados
Aula 10 Especificação de Requisitos

Aula 8 Especificação de Requisitos

Aula 10 Arquitetura de Software e Exercício. Alessandro Garcia LES/DI/PUC-Rio Abril de 2017

Aula 9 Especificação de Requisitos Exercício

Aula 11 Modelagem da Arquitetura. Alessandro Garcia LES/DI/PUC-Rio Abril 2016

Aula 13 Modelagem da Arquitetura

Aula 12 Modelos Arquitetural e Físico Outros Princípios de Modularidade

Aula 14. Modelagem Física (e Exercício)

Aula 02 Conceitos e Princípios de Modularidade 1

Aula 02 Conceitos e Princípios de Modularidade 1

Aula 20 Testes 3. Alessandro Garcia Leonardo da Silva Sousa OPUS Group/LES/DI/PUC-Rio Dezembro 2016

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Prof. Fabiano Papaiz IFRN

Aula 07 Teste Automatizado Parte II

Aula 17 Revisão. Alessandro Garcia LES/DI/PUC-Rio Abril 2010

Engenharia de Requisitos

RUP RATIONAL UNIFIED PROCESS PRÁTICAS RECOMENDADAS. Prof. Fabiano Papaiz IFRN

REUSO E REUSABILIDADE

Introdução à Qualidade de Software

Programação Modular: Prova, Trabalho e Considerações Finais

Eng. de Requisitos: Atividades. Engenharia de Requisitos. Eng. de Requisitos: Processo. O Documento de Requisitos. Stakeholders

Aula 5 Introdução à Teste de Módulos. Alessandro Garcia LES/DI/PUC-Rio Agosto 2017

Aula 17 Decomposição sucessiva

Programação Orientada a Objetos

Eng. de Requisitos: Atividades. Engenharia de Requisitos. Eng. de Requisitos: Processo. O Documento de Requisitos. Stakeholders. Estudo de Viabilidade

ENGENHARIA DE SOFTWARE. Introdução

Paradigmas de Software

especificação por meio de exemplos não é garantia de corretude, mas a experiência mostra que tende a ser melhor do que o estado da prática hoje

Princípios da Engenharia de Software aula 03

ENGENHARIA DE SOFTWARE

Análise e projeto de sistemas

Engenharia de Software Aula 2.1 Introdução à Engenharia de Requisitos. Prof. Bruno Moreno

Professor Emiliano S. Monteiro

Análise de sistemas. Engenharia de Requisitos

Processos de software

Levantamento, Análise e Gestão Requisitos. Aula 03

2

Prof. Esp. Fabiano Taguchi

Introdução à Análise e Projeto de Sistemas

4/14/11. Processos de Engenharia de Requisitos. Engenharia de requisitos. Elicitação e análise. A espiral de requisitos

Introdução Diagrama de Classes Diagrama de Seqüência Diagrama de Atividades. Diagramas UML. Classe, Seqüência e Atividades. Marcio E. F.

Teste de Software. Competência: Entender as técnicas e estratégias de testes de Software

3 Uma Abordagem Orientada a Aspectos para o Desenvolvimento de Frameworks

Engenharia de Software. Projeto de Arquitetura

Modelagem de Casos de Uso (Parte 1)

SSC Engenharia de Software. Prof. Paulo C. Masiero

Unidade II MODELAGEM DE PROCESSOS. Profa. Gislaine Stachissini

Especificação de Sistemas de Software e a UML

Aula 04 Princípios de Modularidade 3 e Introdução à Teste de Software Alessandro Garcia

Engenharia de Software

FUNDAMENTOS DA ANÁLISE E PROJETO DE SISTEMAS. Projeto de Programas PPR0001

Requisitos de Software

Programação Modular. Alessandro Garcia. DI/PUC-Rio Agosto 2016

Descrição Arquitetural

Técnicas de Reutilização. Reutilização em Programação Orientada a Objetos. Considere três classes... Reuso de Classes.

Um Middleware de Inteligência Artificial para Jogos Digitais 105

Engenharia de Software

Aula 04 Conceitos e Princípios de Modularidade 3 Alessandro Garcia

Processos de Software

PROJETO ARQUITETURAL PARTE II: PADRÕES DE PROJETO. Projeto de Programas PPR0001

Introdução à Engenharia de Software

Material Disciplina Tópicos em Engenharia de Software Parte 1 (Introdução aos Conceitos Engenharia de Software) Prof. Wagner Santos C.

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA ENGENHARIA DE SOFTWARE

Roni Fabio Banaszewski UTFPR Universidade Tecnológica Federal do Paraná

Reuso de Software Aula Maio 2012

Análise e Projeto de Software

Como Modelar com UML 2

Bibliografia. Quais são os problemas? capacidade de construção. acompanha a demanda por novos programas. ameaçada por projetos ruins.

LIVRO ENGENHARIA DE SOFTWARE FUNDAMENTOS, MÉTODOS E PADRÕES

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Requisitos de sistemas

Aula 2 POO 1 Introdução. Profa. Elaine Faria UFU

Diagrama de Casos de Uso

Programação Modular: Exercício T4 e Considerações Finais

3 Arquitetura para a Coordenação e a Composição de Artefatos de Software

Aula 08 Ferramentas de desenvolvimento. Alessandro Garcia Alexander Chávez Eduardo Fernandes Leonardo Sousa LES/DI/PUC-Rio Setembro 2017

Programação para Games II. Professor Ariel da Silva Dias Orientação a Objetos

Engenharia de Requisitos

15/04/2013. Pensar Orientado a Objetos. Projeto Orientado a Objetos. Características de Objetos. Classe de Objetos. Comunicação entre Objetos

FUNDAÇÃO UNIVERSIDADE ESTADUAL DE MARINGÁ

Engenharia de Software

Engenharia de Software

DESENVOLVIMENTO BASEADO EM COMPONENTES

Prof. Fábio Lúcio Meira

Resumo de TCC: MAGIC: Um framework para jogos de cartas. Ademir Coelho

RUP RATIONAL UNIFIED PROCESS

Processos de Software by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Análise de Sistemas. Aula 5

RUP/PSDS. Introdução e Comparação

Prof. Dr. Thiago Jabur Bittar

Engenharia de Software

CONCEITOS DE PROJETOS - 2. Profa. Reane Franco Goulart

Engenharia de Software Aula 21. Revisão da Prova 2. Eduardo Figueiredo.

Engenharia de Software Aula 2.1 Introdução à Engenharia de Requisitos. Prof. Bruno Moreno

Resumo parcial da Tese de Doutorado. Um modelo de Sistema de Gestão do Conhecimento para grupos de pesquisa e desenvolvimento.

Teste de Software. Karen Frigo Busolin Novembro / 2010

Modelos de Processo de Software. SSC Engenharia de Software 1 Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2012

Modelagem de Sistemas Web. Modelagem de BD

Transcrição:

Aula 9 Especificação de Requisitos Alessandro Garcia LES/DI/PUC-Rio Abril 2016 Especificação Objetivos dessa aula Apresentar a importância e o que são especificações de requisitos, bem como conceitos relacionados Referência básica: Capítulo 10 Seção 8.3 Capítulo 9.4 Apêndice 2 Slides adaptados de: Staa, A.v. Notas de Aula em Programação Modular; 2008. Referência complementar Silva, R.P.; UML2 em Modelagem Orientada a Objetos; Florianópolis, SC: Visual Books; 2007 2/36 1

Sumário Retrabalho inútil Por que especificar? Especificação de requisitos requisitos funcionais requisitos não-funcionais Como identificar requisitos? 3/36 Visão do Desenvolvedor Mágico" Requisitos Descrição abstrata do problema Aqui o Milagre acontece Código Muitas membros envolvidos não estão interessados em tais decisões de baixo nível 4/36 2

Uma Visão Profissional Descrição explícita de requisites para evitar retrabalho inútil Requisitos Documentação das decisões de projeto Boas práticas de projeto modular Decisões relacionadas as estratégias organizacionais e do implementar primeiro Arquitetura Código 5/36 Como eliminar causas de retrabalho inútil? O que fazer para reduzir ou evitar de vez esse risco? produzir uma boa especificação do que se deseja que seja feito modelar o problema a resolver especificação de requisitos por exemplo: saber/descobrir antes quais são as funcionalidades básicas de um jogo de Xadrez tornar o projeto e implementação do jogo mais manutenível e reutilizável possível produzir uma arquitetura organização da solução adequada ao problema a resolver modelar a solução modelagem da arquitetura e modelagem física 6/36 3

O que é uma especificação? Especificação é um documento ou fragmento que: Determina o que deve ser feito, sem dizer como fazê-lo Especificações de um artefato são veículos de comunicação entre as diversas pessoas interessadas (stakeholders) neste artefato desenvolvedores do artefato e mantenedores do artefato desenvolvedores cliente que pretendem localizar e utilizar artefatos servidores já existentes (reuso) usuários que utilizarão um programa contendo o artefato os gerentes de desenvolvimento e manutenção Nem sempre sabemos exatamente o que desejamos precisamos ver para saber se está bom ou não dificuldade - exemplo: abrangência da solução 7/36 Por que especificar? Precisa-se saber, com precisão, o que o sistema deve implementar... Requisitos são funções, condições, atributos, propriedades ou características a serem satisfeitas pelo artefato Requisitos funcionais e não-funcionais Antes de começar a escrever código precisa-se saber o que este código deve fazer requisitos funcionais também é óbvio que, existindo condicionantes ou restrições, estas devem ser explicitadas antes requisitos não funcionais usualmente chamados de requisitos de qualidade» manutenibilidade» reusabilidade» confiabilidade: robustez, corretude, etc..» desempenho» segurança»... 8/36 4

Requisitos funcionais ou não-funcionais?? Outros exemplos: o sistema deve gerar um relatório com a descrição dos empréstimos diários o tempo de resposta deverá ser menor do que 10 ms o módulo deverá ser portátil melhor é enumerar os sistemas operacionais explicitamente deve ser possível fazer uma consulta as reclamações dos usuários nos últimos 5 dias o sistema deve ser robusto quanto os dados obtidos através de janelas de diálogos, i.e. devem ser validados 9/36 Jogo de Damas Requisitos Funcionais? 10/36 5

Jogo de Damas Requisitos Funcionais? Exemplos Jogo: o programa deve possibilitar o jogo entre duas pessoas, num tabuleiro de 8 x 8 casas alternadamente claras e escuras cada jogador deve possuir 12 peças (pretas ou brancas) e ter como objetivo capturar ("comer") as peças do adversário ganha aquele que "comer" todas ou a maior quantidade de peças do adversário o programa deve permitir que cada jogador movimente apenas uma peça por vez Peças: o programa deve permitir somente dois tipos de peças, a peça comum, que são as peças que os jogadores possuem no início do jogo e as damas se uma peça comum do jogador terminar uma rodada na última fileira de casas do lado oposto do tabuleiro, esta é substituída por uma dama etc... 11/36 Jogo de Damas Requisitos Não-Funcionais? 12/36 6

Jogo de Damas Requisitos Não-Funcionais? Exemplos Robustez: todos os dados de entradas (ex. movimentos) serão validados pelo jogo caso alguma entrada não seja válida, uma mensagem será exibida ao jogador informando dado inválido; ele terá nova oportunidade de digitar Corretude: todos os módulos devem ser testados individualmente, onde cada função dos módulos é estada em diferentes circunstâncias Reuso: restrição: deve-se reusar o Arcabouço de teste automatizado de forma a acelerar o processo de reutilização de projeto e implementação (e teste), deve-se maximizar a reutilização de módulos restrição: em particular, deve-se reusar o módulo LISTA do Arcabouço Manutenibilidade: todas funções e módulos deverão ser desenvolvidos utilizando padrões de documentação, garantindo assim que o programa seja de fácil manutenção restrição: usar catálogos do livro "Programação Modular (Staa, Arndt von) 13/36 Como descobrir requisitos? Um exemplo simplório Desenvolver um programa que computa raiz quadrada dá para começar sem nenhuma informação a mais? Veja algumas perguntas que podem surgir raiz quadrada de que? inteiros, reais, complexos? qual é a precisão requerida? float, double, múltipla? quantos algarismos significativos? existe alguma exigência de desempenho? tempo de resposta versus precisão deve-se verificar se o argumento fornecido é válido? x >= 0.? como responder se não for válido? condição de retorno ou cancelamento? 14/36 7

Como requisitos (F/NFs) são descobertos? Diretamente em entrevistas ou discussões com o cliente do sistema Mas eles pouco sabe o que querem mais tarde: elaboração de protótipos Busca de documentação disponível sobre sistemas semelhantes Alguns são requeridos pelo próprio gerente de projetos ou por membros do time p.e. reusabilidade de certos módulos, tais como definir módulos que encapsulem estruturas de dados genéricas p.e. manutenibilidade: evitar gastos com interfaces de módulos má projetadas, levando a instabilidades futuras no software Produtos novos de software: análise de mercado identificar necessidades de uma gama de potenciais clientes Ex.: algum tempo atrás... jogos em dispositivos móveis identificar características e deficiências de produtos dos competidores Ex.: inclusão de sons em jogos de dispositivos móveis trends futuros: novas tecnologias, p.e. aumento de capacidade de memória em dispositivos móveis 15/36 Terminologia Requisitos: são funções, condições, atributos, propriedades e características a serem disponibilizadas ou satisfeitas pelo artefato Hipóteses: são funções, condições, atributos, propriedades ou características assumidas como satisfeitas externamente à equipe de desenvolvimento o usuário logado tem direitos de ativar esta função pressupõe que os direitos já foram controlados antes de efetuar a chamada o volume de memória disponível será sempre suficiente para executar o programa mesmo assim sempre verifique se malloc( ) retornou NULL Restrições: são condições que restringem a liberdade de escolha de alternativas de construção do artefato sendo especificado o programa deverá ser redigido em C o módulo deverá utilizar a biblioteca xpto.lib Ago 2008 Arndt von Staa LES/DI/PUC-Rio 16/36 8

Descobrir novos requisitos Forma de se descobrir novos requisitos identifique as abstrações principais quais são as propriedades ou regras associadas com tais abstrações elaboree respondaperguntasdo tipo: Qual(is)? Onde? Quando? existem restrições e hipóteses? Abr 2010 Alessandro Garcia LES/DI/PUC-Rio 17/35 Jogo de Damas Requisitos Funcionais? Exemplos Jogo: (quaissão as regras?) como e onde é praticado o jogo? é praticado ente duas pessoas, num tabuleiro de 8 x 8 casas alternadamente claras e escuras qual é a dinâmica do jogo? cada jogador possui 12 peças (pretas ou brancas) e tem como objetivo capturar ("comer") as peças do adversário quem ganha? ganha aquele que "comer" todas ou a maior quantidade de peças do adversário quando pode ser feito o movimento de peças? cada jogador movimenta uma peça por vez Peças: (quais são as regras?) existem dois tipos de peças, a peça comum, que são as peças que os jogadores possuem no início do jogo e as damas se uma peça comum do jogador terminar uma rodada na última fileira de casas do lado oposto do tabuleiro, esta é substituída por uma dama etc... 18/36 9

Exercício Faça a especificação de requisitos com base no que foi apresentado hoje: não somente requisitos funcionais mas também: não-funcionais, hipóteses e restrições A especificação deve ser feita com seu grupo do trabalho Lembrete Regras básicas do jogo incluem: mão de onze, mão de ferro, esconder carta, situações de empate Abr 2010 Alessandro Garcia LES/DI/PUC-Rio 19/35 Dúvidas - Trabalho Passos 1) Elicite os requisitos Quais as funcionalidades do programa do jogo de Truco? Os requisitos serão importantes para que vocês descubram: Módulos, interfaces e dependências Quais outras características (estrutura/funções) dos módulos Lista? Set 2009 LES/DI/PUC-Rio 20/28 10

Não esquecer... Preencher tabela de atividades ao longo do processo. NÃO DEIXE PARA ÚLTIMA HORA, POIS VOCÊ NÃO SE LEMBRARÁ DO QUE FEZ TAL DIA, TAL HORA. Com relatórios similares a esse você aprende a planejar o seu trabalho. O relatório é INDIVIDUAL Ferramentas como gmake e batches de apoio deve ser utilizados 21/ 30 LES/DI/PU Dicas para o Trabalho Não esqueça de rever cuidadosamente: critérios de avaliação procedimentos para entrega do trabalho Certifique-se que seu trabalho atende os seguintes pontos: estruturação: contém tanto o fonte dos módulos de implementação quanto módulos definição (interface) siga princípios de modularidade: interfaces simples e documentadas,... obediência a padrões de programação não esqueçam de produzir arquivos LEIAME.TXT e RELATOR.TXT 22/ 30 LES/DI/PU 11

Aula 9 Especificação de Requisitos Alessandro Garcia LES/DI/PUC-Rio Abril 2016 12