Engenharia de Software Profa Mariela Ins Corts marielalarces

Engenharia de Software Profa. Mariela Inés Cortés mariela@larces. uece. br 2017 21/02/2021

Agenda da Disciplina Sumário do Sommerville. Engenharia de Software, 9 th ed. , Ian Sommerville, Ed. Prentice-Hall, 2011. 21/02/2021

Metodologia de Avaliação Discussão de artigos, elaboração de resenhas. . . Trabalho de Pesquisa Documento escrito Apresentações 21/02/2021

21/02/2021

. . . mas qual a definição de Engenharia de Software? ? 21/02/2021

Engenharia (<latim ingeniu = "faculdade inventiva, talento") é a arte, a ciência e a técnica de bem conjugar os conhecimentos especializados (científicos) de uma dada área do saber com a sua viabilidade técnico-econômica, para produzir novas utilidades e/ou transformar a natureza, em conformidade com idéias bem planejadas. 21/02/2021

Engenharia de Software Disciplina que utiliza um conjunto de métodos, técnicas e ferramentas para analisar, projetar e gerenciar o desenvolvimento e manutenção de software, visando produzir e manter software dentro de prazos, custos e qualidade estimados. Abordagem sistemática para o desenvolvimento, operação e descarte de software. Aplicação prática de conhecimento científico ao projeto e construção de software. Termo criado na década de 1960 e utilizado oficialmente em 1968 na NATO Science Committee. Sua criação surgiu numa tentativa de contornar a crise do software. Objetivo: Maximizar a qualidade do software e aumentar a produtividade e satisfação, tanto dos clientes quanto dos profissionais e engenheiros de software envolvidos. 21/02/2021

Engenharia de Software Como automatizar* ? Como aplicar ? Ferramentas Metodologias O que fazer ? Métodos e Técnicas Como fazer ? Princípios *CASE (Computer-Aided Software Engineering): Ferramentas integradas para desenvolver software. 21/02/2021

Princípios da Eng. de Software Modularidade - Consiste na divisão de sistemas complexos em partes menores e mais simples com características desejáveis (coesão e acoplamento). Decomposição é o ato de dividir um problema original em subproblemas recursivamente. Composição é o ato de juntar os elementos componentes de um problema até chegar ao sistema completo. Separação de Conceitos - Separar conceitos permite-nos trabalhar com aspectos individuais e diferentes de um mesmo problema. Esta separação facilita o entendimento, focando a atenção em certas características mais significativas (Abstração). Generalidade/Especialidade - Soluções genéricas tendem a ser mais caras em termos de recursos e em tempo de desenvolvimento, ao contrário das soluções específicas. 21/02/2021

Princípios da Eng. de Software Rigor e Formalidade - O processo de software é uma atividade criativa tendendo naturalmente à imprecisão. O rigor é a abordagem que produz produtos mais confiáveis pelo controle das variáveis envolvidas. Formalidade implica que o processo esteja dirigido e avaliado por leis matemáticas. Incrementabilidade - Caracteriza o processo em modo passo a passo, incrementalmente. O objetivo desejado é atingido por aproximações sucessivas. Útil quando os requisitos iniciais não foram todos obtidos antes do início do desenvolvimento da aplicação. Antecipação de Mudanças - Sistemas de software são desenvolvidos enquanto seus requisitos ainda não estão totalmente claros. Quando o sistema é finalmente liberado, novos requisitos podem ser descobertos e requisitos antigos atualizados através do “feedback” do usuário. 21/02/2021

Chaos Report 1994 Standish Group International Type 1: Succeded Type 2: Challenged Type 3: Failed

Resumo Chaos Report 1994 16, 2% 31, 1% 52, 7% Succeeded Failed Challenged

Fatores de sucesso 94 e 2008

Enfrentando o Desafio No Silver Bullet …* Nenhuma ferramenta ou tecnologia irá produzir um aumento significativo (de ordens de magnitude) na produtividade do desenvolvimento de software Porquê? Complexidade Acidental. Erros de compilação, poder de expressividade das linguagens de programação, etc. Complexidade Essencial. Complexidade, necessidade de modificações, Adaptabilidade. *No Silver Bullet: Essence and Accidents of Software Engineering, by Frederick P. Brooks, http: //www. lips. utexas. edu/ee 382 c-15005/Readings 1/05 -Broo 87. pdf 21/02/2021

No Silver Bullet … Brooks discute porquê várias tecnologias não são a bala de prata. Ambientes de desenvolvimento integrado (IDEs); Linguagem de programação Ada; Orientação a Objetos; Inteligência Artificial; Sistemas Especialistas; Todas elas enfocam nas complexidade acidental 21/02/2021

A Computer Science Perspective Of Bridge Desing, by Alfred Spector and David Gifford What kinds of lessons does a classical engineering discipline like bridge design have for an emerging engineering discipline like computer systems design? Case-study editors Alfred Spector and David Gifford consider the insight and experience of bridge designer Gerard Fox to find out how strong the parallels are. 21/02/2021

Responsabilidade profissional e ética Computadores desempenham papel central na Sociedade e Engenheiros de Software contribuem e participam de todo o processo de desenvolvimento de sistemas. Engenheiros de Software devem se comportar de maneira honesta e responsável e aderir al compromisso de exercer sua profissão de forma benéfica e respeitada. Aderir ao Código de Ética e de Prática Profissional 21/02/2021

Questões de responsabilidade profissional Confidencialidade Competência Direitos de propriedade inteletual Uso indevido do computador 21/02/2021

Código de Ética e de Prática Profissional: Princípios PÚBLICO. Agir consistentemente com o interesse público. CLIENTE E EMPREGADOR. Agir em conformidade com os melhores interesses de cliente e empregador em consistência com interesse público. PRODUTO. Assegurar que seus produtos cumpram o mais alto padrão profissional possível. JULGAMENTO. Manter integridade e independência em seu julgamento profissional. 21/02/2021

Código de Ética e de Prática Profissional: Princípios GERENCIAMENTO. Promover abordagem ética para o gerenciamento do desenvolvimento e manutenção do software. PROFISSÃO. Fomentar a integridade e reputação da profissão, de modo consistente com o interesse público. COLEGAS. Ser justo e dar apoio aos colegas. PESSOAL. Participar de aprendizado constante com relação à prática da sua profissão. 21/02/2021

Código de Ética e de Prática Profissional Software Engineering Code of Ethics is Approved Communications of the ACM Volume 42 , Issue 10 Pages: 102 - 107 Year of Publication: 1999 Reflita sobre dilemas éticos aos que um Engenheiro pode estar sujeito. Como se posicionar em resposta aos mesmos? 21/02/2021

Processo de Software Desenvolvimento de SW é uma atividade criativa e complexa. Alto número de projetos não chegam ao fim, ainda. . . 21/02/2021

Processo de Software 21/02/2021

Processo de Software Um processo de desenvolvimento de software tem como objetivo a formalização e sistematização das atividades relacionadas à elaboração de sistemas informáticos. Definir as atividades a serem executadas ao longo do projeto. Quando, como e por quem serão executadas. Prover pontos de controle para verificar o andamento. Padronizar o desenvolvimento de SW Reproduzível Definido Medível em relação a rendimento. Otimizável. 21/02/2021

Processo de Software Conjunto estruturado de atividades necessárias para desenvolver um sistema de software. Especificação Desenvolvimento Validação Evolução Um modelo de processo de software é uma representação abstrata de um processo. 21/02/2021

Fase de Especificação Focaliza " que" será desenvolvido informação a ser processada função e desempenho desejados comportamento esperado do sistema interfaces a serem estabelecidas restrições de projeto critérios de validação exigidos 21/02/2021 Atividades: • Especificação de SW. • Engenharia de requisitos

Fase de Definição Processo de Especificação de Software estabelece quais serviços são requeridos e as restrições sobre operação e desenvolvimento. 21/02/2021

Processo de Engenharia de Requisitos Levantamento de requisitos: etapa de compreensão do problema aplicada ao desenvolvimento de software. Objetivo: que usuários e desenvolvedores tenham a mesma visão do problema a ser resolvido. Levantar e definir as necessidades ou requisitos a partir do domínio do negócio. Análise de requisitos: envolve o estudo detalhado dos requisitos levantados e construção de modelos representando o sistema a ser construído, os quais serão verificados e validados. Não leva em conta o ambiente tecnológico. 21/02/2021

Fase de Desenvolvimento Focaliza "como " o software será Focaliza " desenvolvido estruturação dos dados arquitetura do software implementação de detalhes procedimentais caracterização das interfaces tradução do projeto para uma linguagem de programação realização de testes 21/02/2021 Atividades: • Projeto • Implementação • Testes • Implantação

Fase de Desenvolvimento Projeto: determina-se como o sistema funcionará para atender a especificação, considerando os recursos tecnológicos existentes. Descrição computacional do que o software deve fazer, em consistência com a analise. Atividades principais: Projeto da arquitetura Projeto detalhado Implementação: tradução da descrição computacional da fase de projeto em código executável. Verificação e validação do sistema construído levando em conta a especificação da fase de projeto. Implantação: empacotamento, distribuição e instalação no ambiente do usuário. Geração de manuais e treinamento. 21/02/2021

Processo de Projeto de Software 21/02/2021

Verificação e Validação do Software Verificação e validação estabelece como o sistema está conforme com a sua especificação e casa os requisitos do cliente. Envolve checagem, processos de revisão e testes. A atividade de execução de testes envolve a execução do sistema contra casos de teste derivados da especificação. 21/02/2021

Processo de Testes 21/02/2021

Fases de teste no processo de software dirigido a planos 21/02/2021

Fase de Evolução Focaliza as "mudanças " que ocorrerão depois que o software for Focaliza as " liberado para uso operacional, associadas a: correção de erros adaptações exigidas conforme o ambiente do software evolui mudanças devido a melhoramentos ocorridos por alterações nos requisitos dos clientes A fase de evolução ou manutenção reaplica os passos das fases de definição e desenvolvimento, mas faz isso no contexto de um software existente. 21/02/2021

Ferramentas CASE Computer-Aided Software Engineering Sistemas de software cujo objetivo é fornecer suporte automatizado para as atividades do processo de software. Upper-CASE Ferramentas de suporte às atividades de processo iniciais de requisitos e projeto. Lower-CASE 21/02/2021 Ferramentas de suporte às atividades mais avançadas tais como programação, depuração e testes.

Atividades de Apoio ao Processo de Software As três fases genéricas do processo de software são complementadas por uma série de atividades de apoio. Controle e Acompanhamento do Projeto de Software Revisões Técnicas Formais Garantia de Qualidade de Software Gerenciamento de Configuração de Software Preparação e Produção de Documentos Gerenciamento de Reusabilidade Métricas As atividades de apoio são aplicadas durante todo o processo de desenvolvimento de software 21/02/2021

Componente Humano Em virtude do tamanho e complexidade, o desenvolvimento de sistemas de software é um empreendimento realizado em equipe. Gerentes de projeto Analistas Projetistas Arquitetos de software Programadores Clientes Avaliadores de qualidade 21/02/2021

Modelos de Ciclo de Vida de Software Encadeamento específico das atividades típicas envolvidas no processo de desenvolvimento de um sistema Cascata Desenvolvimento Incremental E. S. orientada a reuso Lidando com mudanças Prototipação Incremental Modelo Espiral 21/02/2021

Para Escolha de um Ciclo de Vida de Software. . . Abordagem sistemática para desenvolver um projeto de software. O projeto geralmente é documentado com um conjunto de modelos gráficos. Escolha depende de: Natureza do projeto e da aplicação Métodos e ferramentas a serem usados ou disponíveis Controles e produtos que precisam ser entregues Prazos e recursos disponíveis 21/02/2021

Modelo Cascata Modelo dirigido a planos onde as fases de especificação e desenvolvimento são separadas e distintas. Projetos reais raramente seguem o fluxo sequencial que o modelo propõe. É difícil estabelecer todos os requisitos no início. Dificuldade de acomodação de mudanças. A versão executável do software só fica disponível numa etapa avançada do desenvolvimento. 21/02/2021

Desenvolvimento incremental Especificação, desenvolvimento e validação são intercaladas. Pode ser dirigido a planos ou ágil. 21/02/2021

Problemas do desenvolvimento incremental • O processo não é visível. Gerentes precisam de entregas regulares para medir o progresso. Se os sistemas são desenvolvidos de forma rápida, não é viável do ponto de vista do custo produzir documentação para refletir todas as versões do sistema. • A estrutura do sistema tende a degradar conforme novos incrementos são adicionados. A menos que tempo e dinheiro sejam gastos na reconstrução para melhorar o software, as mudanças regulares tendem a corromper a estrutura do sistema. A incorporação posterior de mudanças no software se torna progressivamente mais difícil e cara.

Engenharia de software orientada a reúso Baseada no reúso sistemático em que os sistemas são integrados componentes existentes ou sistemas COTS (Commercial-off-the-shelf). • Estágios do processo: Análise de componentes; Modificação de requisitos; Projeto de sistema com reúso; Desenvolvimento e integração. • Atualmente, o reúso é a abordagem padrão para a construção de vários tipos de sistemas de negócio. •

Engenharia de software orientada a reúso Onde tipos de componentes podem ser Web services, Coleções de objetos ou Sistemas de software stand-alone (COTS).

Ciclos Iterativos Requisitos do sistema SEMPRE evoluem durante o projeto, assim a iteração do processo onde os estágios iniciais são retrabalhados faz parte do processo para sistemas grandes. É difícil, ou mesmo impossível, estabelecer a priori uma especificação detalhada dos requisitos. Iteração pode ser aplicada a qualquer modelo de processo genérico. Abordagens mais utilizadas Desenvolvimento incremental Desenvolvimento em espiral 21/02/2021

Incremental Combina elementos do modelo cascata com a filosofia iterativa da prototipação. O desenvolvimento e entrega do sistema aos clientes é particionado em incrementos, onde cada incremento realiza uma parte da funcionalidade requerida, até que o produto final é obtido. Os requisitos de usuário são priorizados e os requisitos de maior prioridade são considerados nos incrementos iniciais. Uma vez que um incremento é iniciado, os requisitos são congelados, no entanto, requisitos para incrementos posteriores podem continuar a evoluir. 21/02/2021

Incremental 21/02/2021

Incremental: Vantagens Valor de cliente pode ser entregue em cada incremento, assim as funcionalidades do núcleo do sistema são alcançadas mais cedo. Incrementos iniciais atuam como um protótipo na busca de elicitar os requisitos de incrementos posteriores. Reduz o risco de falha sobre o projeto. Riscos técnicos podem ser administrados. Serviços do sistema de prioridade mais alta tendem a receber mais testes parciais. 21/02/2021

Espiral Modelo Dirigido a Riscos proposto por Boehm (1988). Engloba características do ciclo de vida Cascata e da Prototipação adicionando a Análise de Risco. 21/02/2021 Usa a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de riscos. Cada volta representa uma fase, que é dividida em quatro setores: definição de objetivos, avaliação e redução de riscos, desenvolvimento e validação, e planejamento.

Espiral Planejamento Análise dos Riscos Engenharia Avaliação do Cliente 21/02/2021

Espiral É a abordagem mais realística para o desenvolvimento de software em grande escala. Usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva. Exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso. 21/02/2021

Disciplinas de Requisitos Engenharia de Requisitos. Disciplina da E. S. consistente num conjunto de técnicas de levantamento, documentação e análise. Processo de estabelecer os serviços que o cliente necessita do sistema e as restrições sob as quais o sistema opera e é desenvolvido. Requisitos são as descrições dos serviços e restrições do sistema geradas durante o processo de engenharia de requisitos. Gestão de Requisitos. Disciplina da E. S. que procura manter sob controle o conjunto de requisitos. Reduz instabilidade dos requisitos. Reduz custos. 21/02/2021

Requisitos de Software Descrições e especificações de um sistema. Característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir seus objetivos. Levantados pela equipe de projeto junto a clientes e usuários. • Requisitos servem para: Compreensão comum entre clientes e equipe desenvolvimento; Base para proposta de um contrato; Base para verificar e decidir pela aceitação do produto; Guiar e orientar a equipe no desenvolvimento. 21/02/2021 de

Fontes de requisitos Ambiente físico Interfaces Funcionalidade Documentação Dados Recursos Segurança Garantia da qualidade Usuários e fatores humanos 21/02/2021

Características dos requisitos 21/02/2021 Corretos Precisos Completos Consistentes Realistas Necessários Verificáveis Rastreáveis Priorizados

Tipos de requisitos de acordo com a perspectiva • Pode variar de uma declaração abstrata de alto nível de um serviço ou restrição do sistema, para uma especificação matemática funcional. • Requisitos de usuário Declarações dos serviços que o sistema deverá fornecer e suas restrições operacionais do ponto de vista do cliente/usuário. Utilização de notação que facilite a comunicação entre as partes (em linguagem natural ou com uso de diagramas ). 21/02/2021

Tipos de requisitos de acordo com a perspectiva • Requisitos de sistema Redefine os requisitos de usuário em termos técnicos apropriados para o desenvolvimento do projeto do sistema Documento estruturado com descrições detalhadas funções do sistema, serviços e restrições operacionais. Podem ser usadas como parte do contrato entre cliente e empresa. Servem como base para o projeto do sistema. Podem ser expressos usando modelos de sistema ou notações formais. 21/02/2021

Requisitos de usuário e de sistema 21/02/2021

Requisitos Funcionais Descrevem o comportamento esperado do sistema. Funcionalidades ou serviços que o sistema deve fornecer, como o sistema irá a reagir a entradas particulares e como irá a se comportar em determinadas situações. Têm a finalidade de agregar valor ao usuário. Requisitos funcionais serão implementados no próprio sistema e a implementação desses requisitos caracteriza um sistema. 21/02/2021

Exemplos de Requisitos Funcionais O usuário deve ser capaz de efetuar consultas sobre todo o conjunto inicial de banco de dados ou selecionar um subconjunto deste. O sistema deve fornecer visualizadores apropriados para o usuário ler documentos no arquivo de documentos. Cada pedido deve possuir um identificador único (NUM_PEDIDO), que o usuário deve ser capaz de copiar para a área de armazenamento permanente de contas. 21/02/2021

Requisitos Não-Funcionais Restrições sobre os serviços ou funções oferecidos pelo sistema tais como restrições temporais, sobre o processo de desenvolvimento, padrões, etc. Requisitos de Produto, especificam como o produto deve se comportar, e. g. velocidade de execução, confiabilidade, etc. Requisitos Organizacionais, consequência de políticas organizacionais, e. g. padrões de processo usados, requisitos de implementação, etc. Requisitos Externos, levantados a partir de fatores externos ao sistema e ao processo de desenvolvimento, e. g. requisitos de interoperabilidade, requisitos legislativos, etc. 21/02/2021

Classificação de Requisitos Não. Funcionais 21/02/2021

Requisitos de Domínio Derivados refletem características do domínio da aplicação. Podem ser derivados em: Novos requisitos funcionais, Novos requisitos não-funcionais Definir computações específicas (regras de negócio). Se os requisitos do domínio não forem satisfeitos, o sistema pode ser inadequado. Problemas 21/02/2021 Entendibilidade Implícitos por serem óbvios

Documento de requisitos de software • O documento de requisitos de software é a declaração oficial do que é demandado dos desenvolvedores do sistema. • deve incluir ambas, uma definição de requisitos do usuário e uma especificação de requisitos do sistema. • deve definir O QUE o sistema deve fazer ao invés de COMO deve fazê-lo. Guia para escrever requisitos: Estabelecer um formato padrão. Uso da linguagem de uma forma consistente para estabelecer os requisitos mandatários e os desejáveis. Identificar os trechos chave dos requisitos 21/02/2021

Requisitos do Documento de Requisitos Especificar a funcionalidade do sistema Especificar o comportamento externo do sistema Especificar restrições de implementação Registrar previsões sobre o ciclo de vida do sistema, i. e. predizer mudanças Caracterizar respostas a eventos não esperados Não descrever detalhes de projeto ou implementação nem aspectos gerenciais Servir como ferramenta de referência para manutenção 21/02/2021

Usuários do Documento de Requisitos Cliente Gerente Engenheiro de Sistemas Engenheiro de Teste Engenheiro de Manutenção 21/02/2021 Especifica os requisitos e os lê para checar que casam suas necessidades. Estes especificam mudanças nos requisitos Usa o documento de requisitos para planificar o sistema e seu processo de desenvolvimento Usa os requisitos para entender como o sistema é desenvolvido Usa os requisitos para desenvolver testes de validação para o sistema Usa os requisitos para ajudar a entender o sistema e os relacionamentos entre as partes

Modalidades para Especificações Notação 21/02/2021 Descrição Linguagem Natural Flexível mas ambígua. Linguagem Natural Estruturado Definição de formato padrão ou templates. Linguagem de descrição de projeto Usa uma linguagem do tipo de programação com propriedades mais abstratas definindo um modelo operacional do sistema. Notações gráficas Linguagem gráfica. Especificações matemáticas Baseada em conceitos matemáticos tais como maquinas de estados finitos e conjuntos. Não admite ambiguidades, mas difíceis de entender pelos clientes.

Especificação em linguagem natural

Especificação estruturada

Especificação tabular

Processos de engenharia de requisitos • Os processos usados para a engenharia de requisitos variam muito, dependendo do domínio da aplicação, das pessoas envolvidas e da organização que desenvolve os requisitos. • No entanto, existe uma série de atividades genéricas comuns a todos os processos Elicitação ou levantamento (descoberta) de requisitos; Análise de requisitos; Validação de requisitos; Gerenciamento de requisitos. • Na prática, engenharia de requisitos é uma atividade iterativa em que estes processos são intercalados.

Visão em espiral do processo de engenharia de requisitos

Levantamento de requisitos “Requirements elicitation is perhaps the most difficult, most critical, most error-prone, and most communication-intensive aspect of software development. ” Karl Wiegers, 2003 21/02/2021

Levantamento de requisitos Às vezes chamada de elicitação ou descoberta de requisitos. Processo que visa a obter o enunciado completo, claro e preciso dos requisitos de um produto de software. Resultado principal do fluxo: Especificação de Requisitos de Software 21/02/2021

Levantamento e análise de requisitos • Engenheiros de software trabalham com stakeholders do sistema para descobrir sobre o domínio da aplicação, os serviços que o sistema deve fornecer, o desempenho do sistema necessários, restrições de hardware, outros sistemas, etc. Pode envolver usuários finais, gerentes, engenheiros envolvidos na manutenção, especialistas de domínio, sindicatos, e até os reguladores externos.

Problemas de análise de requisitos • Os stakeholders não sabem o que realmente querem. • Os stakeholders expressam requisitos em seus próprios termos. • Diferentes stakeholders podem ter requisitos conflitantes. • Fatores políticos e organizacionais podem influenciar os requisitos de sistema. • Os requisitos mudam durante o processo de análise. Novos stakeholders podem surgir e o ambiente de negócios pode mudar.

Técnicas para Levantamento de Requisitos Entrevista Observação Demonstração de tarefa Estudo de Documentos Substituir o Usuário (Role playing) Questionário Brainstorming e Brainwriting Prototipação Estudo de Empresas Similares Workshops ou Oficinas de Requisitos 21/02/2021

Entrevistas • Entrevistas formais ou informais com os stakeholders fazem parte da maioria dos processos de engenharia de requisitos. • Entrevistas são boas para a obtenção de um entendimento geral do que os stakeholders fazem e como eles podem interagir com o sistema. • Complementam informações advindas de outras fontes. • Tipos de entrevista Entrevistas fechadas com base em uma lista de perguntas prédeterminada. Entrevistas abertas, em que várias questões são exploradas com os stakeholders.

Entrevistas, na prática • Entrevistar eficazmente Ter a mente aberta, evitar ideias pré-concebidas sobre os requisitos e estar disposto a ouvir os stakeholders. Induzir os entrevistados a discutir usando uma questão trampolim, uma proposta de requisitos, ou trabalhando em conjunto em um sistema protótipo. • Entrevistas podem não ser boas para a compreensão dos requisitos de domínio ou restrições organizacionais: Engenheiros de requisitos não podem entender a terminologia específica de domínio; Algum conhecimento de domínio é tão familiar que as pessoas acham difícil articular ou pensam que não vale a pena articular. Questões de poder.

Casos de uso • Casos de uso é uma técnica da UML baseada em cenários que identificam os atores envolvidos numa interação • Um conjunto de casos de uso deve descrever todas as possíveis interações com o sistema. • Modelo gráfico de alto nível complementado por uma descrição tabular mais detalhada. • Diagramas de sequência podem ser usados para adicionar detalhes aos casos de uso, mostrando a sequência de processamento de eventos no sistema.

Casos de uso para o MHC-PMS

Cenários • Cenários são exemplos da vida real de como um sistema pode ser usado. • Sessões de interação. • Descritos como texto ou diagramas. • Úteis para adicionar detalhes. • Eles devem incluir: A descrição da situação inicial; A descrição do fluxo normal de eventos; A descrição do que pode dar errado; Informações sobre outras atividades concorrentes; A descrição do estado do sistema quando o cenário acaba.

Cenário para a coleta do histórico médico

Cenário para a coleta do histórico médico

Etnografia • Parte do principio que o contexto social e organizacional afetam o funcionamento prático do sistema. • Etnografia é uma técnica de observação para compreender os processos operacionais. • Um analista (observador imparcial) faz uma imersão observando e analisando como as pessoas realmente trabalham. • As pessoas não precisam explicar ou articular seu trabalho. • Podem ser observados fatores sociais e organizacionais de importância e descobrir requisitos implícitos. • Estudos etnográficos têm mostrado que o trabalho geralmente é mais rico e complexo do que o sugerido pelos modelos simples de sistemas.

mbito da etnografia • Útil para a descoberta de • Requisitos que são derivados da maneira como as pessoas realmente trabalham e não da maneira como as definições de processo sugerem que elas deveriam trabalhar. • Requisitos que são derivados da cooperação e conscientização das atividades das outras pessoas. • Foco no usuário final. • É eficaz para a compreensão dos processos existentes, mas não pode identificar novos recursos que devem ser adicionados a um sistema.

Validação dos requisitos Processo que determina se a especificação dos requisitos é consistente com o que o cliente quer. Técnicas de Validação Técnicas manuais Referência cruzada Entrevistas Revisões periodicas Listas de verificação Cenários Provas matemáticas Técnicas automatizadas Referência cruzada Protótipos Geração de casos de teste Ocorre junto com a análise dos requisitos. Custo de erros nos requisitos é alto. 21/02/2021

Validação dos requisitos • Validade. O sistema fornece as funções que melhor atendem às necessidades do(S) cliente(S)? • Consistência. Existe algum conflito de requisitos? • Completude. Estão incluídas todas as funções e restrições requeridas pelo cliente ? • Realismo. Os requisitos podem ser implementados com o orçamento e a tecnologia disponíveis? • Verificabilidade. Os requisitos podem ser verificados?

Gerenciamento de requisitos • O ambiente técnico e de negócios do sistema muda após a instalação. Um novo hardware introduzido, interface do sistema com outros sistemas, as prioridades do negócio podem mudar. . . • As pessoas que pagam por um sistema e os usuários desse sistema raramente são as mesmas pessoas. Interesses podem entrar em conflito e, após a entrega, pode ser necessário adicionar novos recursos para suporte ao usuário. • Sistemas de grande porte costumam ter muitos usuários com necessidades diferentes e prioridades que podem ser conflitantes. Os requisitos do sistema final são um compromisso entre as partes que, onde o balanço de apoio dado aos diferentes usuários pode precisar ser mudado.

Gerenciamento de requisitos • É preciso manter o controle das necessidades individuais e manter ligações entre os requisitos dependentes para que seja possível avaliar o impacto das mudanças nos requisitos. • Envolve compreensão e controle de mudanças. • É necessário estabelecer um processo formal para fazer propostas de mudança e ligar essas aos requisitos de sistema.

Planejamento do gerenciamento de requisitos • Estabelece o nível de detalhamento necessário para o gerenciamento de requisitos. Decisões do gerenciamento de requisitos: Identificação de requisitos. Cada requisito deve ser identificado para que ele possa ser comparado com outros requisitos. Processo de gerenciamento de mudanças. Esse é o conjunto de atividades que avaliam o impacto e o custo das mudanças. Políticas de rastreabilidade. Essas políticas definem as relações entre cada requisito e entre os requisitos e o projeto do sistema que deve ser registrado. Ferramentas de suporte. Sistemas de gerenciamento de requisitos e rastreabilidade, de gerenciamento de mudanças. Até sistemas especialistas, ou simples planilhas e sistemas de banco de dados.

Gerenciamento de mudança de requisitos • Análise de problema e especificação de mudanças. Durante essa fase, o problema ou a proposta de mudança é analisada para verificar se é válida. O feedback dessa análise é devolvido para o solicitante, que pode responder ou decidir retirar o pedido. • Análise de mudanças e custos. O efeito da mudança proposta é avaliado por meio de informações de rastreabilidade e conhecimento geral dos requisitos do sistema. Uma vez que essa análise é concluída, toma-se a decisão de prosseguir ou não com a mudança de requisitos. • Implementação de mudanças. O documento de requisitos e, se necessário, o projeto e implementação do sistema, são modificados.

Rastreabilidade dos Requisitos e d a d ão i l ç i a b r ea nfigu r t s Ra de co a i c n erê 21/02/2021 G

Trabalho de Pesquisa • Pesquise artigos sobre algum tópico de engenharia de requisitos para apresentação em aula (máx. 20 minutos) para o dia 20 de abril. • Individual. • Artigos de fontes confiáveis, i. e. , publicados em jornais e conferencias qualificados. 21/02/2021