Noções de Engenharia de Software

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

1 Noções de Engenharia de Software
3. Análise de requisitos de sistema e de software 3.1 Análise de requisitos de sistema 3.2 Análise de requisitos de software Objetivo: mostrar o papel da análise de requisitos de sistema e sua aplicacação na análise de requisitos de software, bem como as principais atividades e documentos associados

2 3.1 ANÁLISE DE REQUISITOS DE SISTEMA
A análise de requisitos de sistema surgiu para solucionar problemas e o engenheiro de sistemas começa a sua resolução com metas e restrições definidas pelo cliente e deriva uma representação da função, desempenho, interfaces, restrições de projeto e estrutura Deve-se começar com a idéia de função desejada – demarcar o sistema ao identificar o escopo da função e desempenho requeridos (as restrições e as interfaces) Depois, deve-se passar para a tarefa de alocação – designar funções a um ou mais elementos do sistema

3 Exemplo: sistema de classificação por correia transportadora (CLSS)

4 O engenheiro de sistemas recebe uma declaraçaõ “nebulosa” dos objetivos do CLSS quanto ao movimento da linha, classificação, identificação, impressão, ordem e espaçamento Para demarcar, o engenheiro deve identificar o escopo da função e desempenho desejados Não basta dizer que o robô reagirá rapidamente quando a bandeja estiver vazia mas 1) indicar o que é uma bandeja vazia para o robô 2) saber os limites precisos de tempo 3) qual forma uma resposta deve assumir

5 Uma série de perguntas pode ser feita
Quantos números de identificação? Qual a velocidade da correia? Qual a distância da estação para os depósitos? E entre os depósitos? O que aconteceria se uma caixa não tivesse o número de identificação? E se o depósito fica cheio? As informações devem ser repassadas para outro canto? Que erro é aceitável? Que peças existem atualmente? Que restrições de orçamento e prazo?

6 Então, o engenheiro demarca as funções principais
FUNDAMENTAL! Note que o engenheiro não pergunta como a tarefa deve ser feita, mas o que é exigido Então, o engenheiro demarca as funções principais Ler a entrada do código de barras Ler o tacômetro de impulsos Decodificar os dados dos códigos de peças Executar busca em banco de dados Determinar a localização do depósito Produzir sinais de controle para o mecanismo de desvio

7 ... E faz alocações alternativas
1) treina e aloca operador de linha 2) um leitor de código e um controlador com um desvio mecânico 3) um leitor de código e um controlador com um braço mecânico Critérios para configuração do sistema Consideraçôes de projeto Considerações de negócio Análise técnica Avaliação da manufatura Questões humanas Interfaces ambientais Consideraçôes jurídicas Também deve se pensar em soluções não convencionais!!!

8 As informações reunidas durante a etapa de identificação das necessidades deve ser reunida num Documento Conceitual do Sistema com algumas funções

9 Diagrama geral de contexto da arquitetura
A modelagem é feita em um documento de especificaçao e pode ser feita em um diagrama de contexto da arquitetura e em um diagrama de fluxo da arquitetura Outras ferramentas como descrições e dicionários podem ser utilizados Diagrama geral de contexto da arquitetura

10 Diagrama do CLSS do contexto da arquitetura

11 Diagrama do CLSS do fluxo da arquitetura

12 3.2 ANÁLISE DE REQUISITOS DE SOFTWARE
Qualquer que seja o projeto ou a boa codificação de um programa, a sua má análise frustará o usuário Esforços de uma análise de requisitos de software Reconhecimento do problema Avaliação e síntese Modelagem Especificação Revisão No final, estar preparado para as ambiguidades “sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de que percebe que aquilo que ouviu não é o que eu pretendia dizer…”

13 Cada uma das tarefas descreve o problema de forma que uma solução global possa ser sintetizada
Exemplo: Um sistema de controle de estoques é exigido por um grande fornecedor de autopeças QUE PROBLEMAS NO ATUAL SISTEMA PODEM SER IDENTIFICADOS? Como nos requisitos de sistema, o foco da síntese e avaliação deve cair sobre “o que” e não “como” Um manual do usuário pode ser rascunhado para o caso em que um protótipo não esteja sendo desenvolvido

14 Um analista deve exibir nos seus esforços traços característicos…
Compreensão de conceitos abstratos Absorver fatos pertinentes Entender o ambiente do usuário Aplicar elementos do sistema aos elementos do usuário Comunicar-se bem nas formas escrita e verbal Capacidade de “ver as florestas entre as árvores” … e coordenar cada uma das tarefas associadas à análise de requisitos de software

15 Problemas durante a análise de requisitos de software
Dificuldade para obter informações pertinentes Complexidade Mudanças durante e após a análise O crescimento do sistema aumenta os problemas e as mudanças começam a ser vistas em termos de mudanças de exigência Primeira lei da engenharia de sistemas: “Não importa onde se esteja no ciclo de vida do sistema, o sistema se modificará, e o desejo de mudá-lo persistirá ao longo de todo o ciclo” (Bersoff)

16 Técnicas de comunicação e facilitação para especificação de aplicações
Um encontro pode estabelecer desconcerto entre as partes, mas algumas etapas podem ser iniciadas: Perguntas livres do contexto (direcionadas ao cliente) Quem está por trás do pedido deste trabalho? Quem usará a solução? Qual é o benefício econômico de uma solução? Há outra fonte para a solução exigida? Compreensão do problema (verbalização do cliente sobre uma percepção da solução) Como você caracterizaria um bom resultado? Qual problema essa solução resolverá? Você pode mostrar o ambiente? Existem questões de desempenho ou restrições especiais?

17 Metaperguntas (efetividade do encontro)
Você é a pessoa certa? Suas respostas são oficiais? Minhas perguntas são pertinentes ao problema que você tem? Estou fazendo perguntas demais? Há mais alguém que possa fornecer informações adicionais? Existe algo mais que devo perguntar-lhe? A técnica FAST (facilitated application specification techniques) estimula a criação de uma equipe conjunta de clientes e desenvolvedores e tem algumas diretrizes Encontros em locais neutros Regras para participação Agenda formal para cobrir os pontos importantes e informal para encorajar o fluxo de idéias Um moderador Mecanismos de definição

18 Após o encontro, desenvolvedores e clientes escrevem a requisição do produto com uma lista de objetos, suas restrições e desempenho, podendo ser feitas miniespecificações

19 Exemplo para uma empresa de produtos de consumo:
Nossa pesquisa indica que o mercado para sistemas de segurança domésticos cresce 40% ao ano. Gostaríamos de entrar no mercado construindo um sistema de segurança doméstico baseado em microprocessador que oferecesse proteção contra e/ou reconhecesse uma variedade de “situações” indesejáveis, tais como entrada ilegal, incêndio, alagamento e outros. O produto, experimentalmente chamado de SafeHOme, usará sensores apropriados para detectar cada situação, poderá ser programado pelo dono e telefonará automaticamente para uma agência de monitoração assim que uma situação for detectada

20

21 É importante saber ainda que:
Princípios de análise 1) o domínio de informação deve ser representado e compreendido 2) modelos que desenvolvam a informação, função e comportamento do sistema devem ser desenvolvidos 3) os modelos e o problema devem ser divididos em partições 4) o processo de análise deve mover-se da informação essencial para os detalhes de implementação É importante saber ainda que: O software processa dados e eventos O modelo do software é diferente do software O modelo tem partições com as funções mais importantes e os detalhes crescentes

22 Princípios da especificação
1) separar funcionalidade da implementação 2) linguagens de especificação orientadas a processos são exigidas 3) a especificação abrange o sistema do qual o software faz parte 4) a especificação deve abranger o ambiente 5) a especificação é um modelo cognitivo e obedece a algumas leis físicas 6) deve ser operacional 7) tolerante com a não inteireza 8) localizada e fracamente acoplada

23 Princípios da representação
1) pertinência ao problema 2) colocada em níveis 3) diagramas e outras notações restritas quanto ao número e consistente quanto ao uso O QUE SIGNIFICA ESTA NOTAÇÃO? 4) revisável Há também uma série de princípios para uma revisão detalhada de toda a especificação do software mais específica do que a do sistema

24 Revisão da especificação
Nível macroscópico Metas e objetivos permanecem consistentes? Interfaces foram descritas? O fluxo e a estruura são adequados? Os diagramas são claros? As funções estão no escopo? O comportamento é consistente com informação e funções? As restrições são realísticas? Qual é o risco tecnológico? Requisitos foram considerados? Critérios de validação foram detalhados? Há inconsistência, omissão, redundância? Contato com o cliente é completo? Protótipo ou manual foram revisados? Estimativas foram afetadas?

25 Revisão detalhada Enunciados da especificação
Olhar o porquê de conectivos persuasivos Por exemplo, certamente, obviamente, claramente Procurar termos vagos Algum, às vezes, usualmente, o mais, na maior parte Identificar listas incompletas Etc, assim po diante, daí pra frente, tal como Limites declarados com pressuposições não declaradas “códigos variam de 0 a 100” (inteiro, real…) Cuidado com pronomes pendentes Pedir prova das declarações com certeza Evitar outras definições para um mesmo termo Estrutura descrita em parágrafos (gráfico? Figura?) Quando houver cálculo, criar 2 exemplos