Aula 8: Revisão de Conteúdo para AV1 - Modelagem de Sistemas de Informação

Senac Modelagem de Sistemas de Informação Bacharelado em Sistemas de Informação Profª Claudia Bianchi Progetti claudiabprogettispsenacbrclaudiaprogettihotmailcom Aula 8 Revisão do conteúdo para AV1 Aula 1 Software Dados formam informação que por sua vez forma requisitos Com requisitos se constrói um software Requisitos Software Dados Informações Aula 2 Processo de software e desenvolvimento ágil Ciclo de vida de desenvolvimento de sistemas Processo de software Conjunto de atividades relacionadas que levam à produção de um produto de software Software podem ser desenvolvidos do zero ou estendidos a partir de software já existente Uso de componentes préexistentes é uma prática comum Atividades fundamentais Especificação projeto implementação validação evolução FIGURA 21 O modelo em cascata Definição dos requisitos Projeto do sistema e do software Implementação e teste de unidade Integração e teste de sistema Operação e manutenção Sommerville 2019 FIGURA 22 Desenvolvimento incremental Atividades simultâneas Especificação Desenvolvimento Validação Versão inicial Versões intermediárias Versão final Sommerville 2019 FIGURA 23 Engenharia de software orientada para o reuso FIGURA 24 O processo de engenharia de requisitos Lidando com mudanças Mudança é inevitável em grandes projetos Requisitos mudam surgem novas pressões externas ao negócio mudam prioridades emergem novas tecnologias surgem novos projetos Mudanças causam custos Possíveis soluções Prototipação Entrega incremental Processo Unificado da Rational IBM Rational Unified Process RUP 2003 Modelo de processo híbrido Prototipação Incremental Iterativo Três perspectivas Dinâmica fases Estática disciplinasatividades Prática boas práticas Disciplinas Histórico motivação 1960s1970s crise do software 1980s1990s engenharia de software tradicional 2000s2010s engenharia de software ágil Manifesto ágil 2001 Estamos descobrindo maneiras melhores de desenvolver software fazendoo nós mesmos e ajudando outros a fazerem o mesmo Através deste trabalho passamos a valorizar Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Ou seja mesmo havendo valor nos itens à direita valorizamos mais os itens à esquerda Exemplos de métodos ágeis Extreme Programming XP Scrum Test Driven Development TDD Kanban Crystal Adaptative Software Development ASD Feature Driven Development FDD Dynamic Systems Development Method DSDM Agile Unified Process Sommerville 2019 Ciclo da Programação XP O processo Scrum Sommerville 2019 Os princípios dos métodos ágeis Aula 3 Requisitos Engenharia de requisitos Requisitos de sistemasoftware Descrições do que o sistemasoftware deve fazer os serviços que ele oferece as restrições sobre seu funcionamento Refletem as necessidades dos clientes que servem a uma finalidade determinada Engenharia de requisitos Requirements engineering processo de descobrir analisar documentos verificar e validar esses serviços e restrições Tipos de requisitos Requisitos funcionais Requisitos não funcionais Tipos de requisitos Requisitos funcionais Declarações de serviços que o sistema deve fornecer Declarações de como o sistema deve reagir a entradas específicas Declarações de como o sistema deve se comportar em determinadas situações Declarações do que o sistema não deve fazer Tipos de requisitos Requisitos não funcionais Restrições aos serviços ou funções oferecidos pelo sistema Incluem restrições de tempo restrições no processo de desenvolvimento e restrições impostas por normas Geralmente aplicamse ao sistema como um todo httpswwwateomomentocombrexemplosrequisitosnaofuncionais Adequação Funcional Completude Funcional Correção Funcional Adequação Funcional Eficiência de Desempenho Comportamento Temporal Utilização de Recursos Capacidade Compatibilidade Coexistência Interoperabilidade Usabilidade Reconhecimento de Adequabilidade Aprendizagem Operacionalidade Proteção Contra Erros do Usuário Estética da Interface do Usuário Acessibilidade Confiabilidade Maturidade Disponibilidade Tolerância à Falhas Recuperabilidade Segurança Confidencialidade Integridade Não Repúdio Autenticidade Prestação de Contas Manutenabilidade Modularidade Reusabilidade Analisabilidade Modificabilidade Testabilidade Portabilidade Adaptabilidade Capacidade de ser instalado Capacidade para substituir Qualidade de Produto de Software ISO25010 Qualidade ExternaInterna Aula 4 Elicitação e análise de requisitos Validação de requisitos Elicitação de requisitos Descoberta de requisitos elicitação de requisitos Processo de reunir informações sobre o sistema requerido e os sistemas existentes e separar dessas informações os requisitos de usuário e de sistema Fontes de informação documentação clientesusuários do sistema e especificações de sistemas similares Ferramentastécnicas observação etnografia imersão entrevistas cenários protótipos Figura 46 O processo de elicitação e análise de requisitos Validação de requisitos Processo de checar se os requisitos definem o sistema que o cliente realmente quer Validação de requisitos se sobrepõe à análise de requisitos uma vez que está preocupada em encontrar problemas com os requisitos Importante porque erros em um documento de requisitos podem gerar altos custos de retrabalho quando descobertos tardiamente Validação x Verificação Validação checar se os requisitos representam o sistema correto Verificação checar se os requisitos estão representados corretamente Exemplos de problemas comuns Validadecorretude a função era exatamente aquela Consistência diferentes requisitos não podem entrar em conflito Completude todos os requisitos necessários devem ter sido incluídos Realismo os requisitos incluídos devem poder realmente ser implementados Testabilidade os requisitos devem poder ser validados sobre o sistema implementado Exemplos de técnicas de VV Revisão os requisitos são analisados sistematicamente por uma equipe de revisores que busca por erros Prototipação um modelo executável do sistema em questão é demonstrado para os usuários finais e clientes Estes podem experimentar o modelo para verificar se ele atende às suas reais necessidades Projeto de casos de teste adiantar o processo de projetar casos de teste Exercício 1 A última etapa de engenharia de requisitos é a validação e gerenciamento de requisitos Sinalize qual das alternativas é falsa a Consistência é quando todos os requisitos necessários devem ter sido incluídos b Validação de requisitos é o processo de checar se os requisitos definem o sistema que o cliente realmente quer c Validação de requisitos se sobrepõe à análise de requisitos uma vez que está preocupada em encontrar problemas com os requisitos d Validação de requisitos é importante porque erros em um documento de requisitos podem gerar altos custos de retrabalho quando descobertos tardiamente e Validação é checar se os requisitos representam o sistema correto Exercício 2 Qualidade de software inclui o comportamento do software enquanto ele está executando bem como a estrutura e a organização dos programas do sistema e a documentação associada Isso se reflete nos atributos de software chamados não funcionais ou de qualidade Existem alguns problemas que afetam a qualidade Preencha as seguintes lacunas corretamente I diferentes requisitos não podem entrar em conflito II os requisitos devem poder ser validados sobre o sistema implementado III a função era exatamente aquela IV todos os requisitos necessários devem ter sido incluídos V os requisitos incluídos devem poder realmente ser implementados a Realismo Testabilidade Completude Validadecorretude Consistência b Realismo Validadecorretude Testabilidade Consistência Completitude c Completude Consistência Validadecorretude Realismo Testabilidade d Consistência Testabilidade Validadecorretude Completude Realismo e Testabilidade Completude Realismo Validadecorretude Consistência Aula 5 Modelagem de software Modelos de software são produzidos em Engenharia de requisitos Ajudam a extrair os requisitos Projeto de software Ajudam a descreverdocumentar o sistema Desenvolvimento de modelos abstratos de um sistema Cada modelo com uma visãoperspectiva diferente Deixa de fora detalhes Normalmente usando uma notação gráfica ex UML Aula 5 Modelagem de Sistemas de Informação UML começou a ser definida a partir de uma tentativa de Jim Rumbaugh e Grady Booch de combinar dois métodos populares de modelagem orientada a objeto Booch e OMT Object Modeling Language Mais tarde Ivar Jacobson o criador do método Objectory uniuse aos dois formando os famosos três amigos para a concepção da primeira versão da linguagem UML Unified Modeling Language Linguagem de Modelagem Unificada UML httpwwwomgorg traduzido Perspectivas de sistemas Perspectiva externa modela o contexto ou o ambiente do sistema Perspectiva de interação modela as interações entre um sistema e seu ambiente ou entre os componentes de um sistema Perspectiva estrutural modela a organização de um sistema ou a estrutura dos dados processados pelo sistema Perspectiva comportamental modela o comportamento dinâmico do sistema e como ele reage aos eventos Aula 6 Diagrama de Caso de Uso Emitir Extrato Emitir Saldo Realizar Saque Cliente include Encerrar Conta Abrir Conta Comum Abrir Conta Especial Abrir Conta Poupança Funcionário Manter Cliente Realizar Depósito Manter Cliente Registrar Movimento include extend Funcionário include extend extend extend include UC Sistema de Controle Bancário Exercício 1 Desenvolva o diagrama de casos de uso para um sistema de controle de cinema sabendo que Um cinema pode ter muitas salas sendo necessário portanto registrar informações a respeito de cada uma como sua capacidade ou seja o número de assentos disponíveis O cinema apresenta muitos filmes Um filme tem informações como título e duração Assim sempre que um filme for apresentado devese registrálo também Um mesmo filme pode ser apresentado em diferentes salas e em horários diferentes Cada apresentação em uma determinada sala e horários é chamada Sessão Um filme sendo apresentado em sessão tem um conjunto máximo de ingressos determinado pela capacidade da sala Os clientes do cinema podem comprar ou não ingressos determinado pela capacidade da sala Os clientes do cinema podem comprar ou não ingressos para assistir uma sessão O funcionário pode intermediar a compra do ingresso Um ingresso deve conter informações como tipo de ingresso meia entrada ou entrada inteira Além disso um cliente só pode comprar ingressos para sessões não encerradas Ator Caso de Uso Extend Include Sistema de controle de cinema Cliente Funcionário Manter Salas Manter Filmes Manter Sessões de Filme Vender Ingresso Exercício 2 Desenvolva o diagrama de casos de uso para um sistema de controle de clube social de acordo com os seguintes requisitos Para ingressar em um clube é necessário apresentar uma solicitação a ser avaliada por uma comissão nomeada pelo clube Em caso de aprovação o candidato pode associarse no clube Opcionalmente caso possua dependentes poderá associálo também o que aumentará o valor da mensalidade a ser paga Sendo sócio do clube deverá pagar uma mensalidade para poder frequentálo As mensalidades são geradas pelo clube levando em consideração a categoria do sócio e o número de dependentes Ator Caso de Uso Extend Include Sistema de controle de clube social Clube Sócio Apresentar pedido de aceitação Gerar mensalidades Associar Sócio Quitar Mensalidade Candidato Associar Dependentes extend Exercício 3 Desenvolva o diagrama de casos de uso para um sistema de controle de hotelaria sabendo que os requisitos funcionais mínimos do sistema são Os quartos podem ser alugados no momento em que o hóspede chega ao hotel desde que existam vagas ou serem reservados via internet Caso seja a primeira vez que o cliente aluga quartos ou os seus dados tenham mudado o hóspede deve ser cadastrado antes de finalizar o aluguel do quarto Além do aluguel do quarto o hotel oferece diversos serviços como restaurante lavar eou passar roupas entre outros Qualquer desses serviços se solicitado será cobrado na fatura final O hóspede pode também consumir os produtos contidos no frigobar que também são cobrados pelo hotel Quando o cliente for quitar a fatura quitará não somente as diárias dos quartos que alugou mas também qualquer serviço que tenha solicitado e os itens consumidos no frigobar O hóspede depois de quitar a fatura pode permanecer no hotel ou encerrar sua estadia Quando for encerrar sua estadia o hóspede deverá pagar quaisquer serviços ou diárias ainda não pagas Ator Caso de Uso Extend Include Sistema de controle de hotelaria Funcionário Reservar Quarto Manter Hóspede Alugar Quarto Solicitar Serviço Hóspede Quitar Diárias extend Encerrar Estadia include extend Quitar Serviços Quitar Consumo extend extend Bons Estudos