Texto de pré-visualização
Senac Modelagem de Sistemas de Informação Bacharelado em Sistemas de Informação Profª Claudia Bianchi Progetti claudiabprogettispsenacbrclaudiaprogettihotmailcom Aula 2 Processo de software e desenvolvimento ágil Ciclo de vida de desenvolvimento de sistemas MODELOS DE PROCESSO DE SOFTWARE E ATIVIDADES DE SOFTWARE FIGURA 11 Perguntas frequentes sobre engenharia de software Pergunta Resposta O que é software Programas de computador e documentação associada Os produtos de software podem ser desenvolvidos dos para um determinado cliente ou para um mercado genérico Quais são os atributos do bom software O bom software deve proporcionar a funcionalidade e o desempenho necessários e deve ser mantido útil e com dependabilidade dependability O que é engenharia de software A engenharia de software é uma disciplina de engenharia que se preocupa com os aspectos da produção de software desde sua concepção inicial até sua operação e manutenção Quais são as atividades fundamentais da engenharia de software Especificação desenvolvimento validação e evolução do software Qual é a diferença entre engenharia de software e ciência da computação A ciência da computação se concentra na teoria e nos fundamentos A engenharia de software se preocupa com as questões práticas de desenvolver e entregar software útil Qual é a diferença entre engenharia de software e engenharia de sistemas A engenharia de sistemas se preocupa com todos os aspectos do desenvolvimento de sistemas computacionais incluindo hardware software e engenharia de processos A engenharia de software faz parte desse processo mais geral Quais são os principais desafios enfrentados pela engenharia de software Lidar com a crescente diversidade com as demandas por menores prazos de entrega e desenvolver software confiável Quais são os custos da engenharia de software Aproximadamente 60 dos custos de software são relativos ao desenvolvimento e 40 aos testes Quanto ao software personalizado os custos de evolução frequentemente ultrapassam os de desenvolvimento Quais são os melhores métodos e técnicas de engenharia de software Ainda que todos os projetos de software devam ser gerenciados e desenvolvidos profissionalmente técnicas diferentes são adequadas para tipos diferentes de sistemas Por exemplo jogos devem ser sempre desenvolvidos usando uma série de protótipos enquanto sistemas de controle críticos em segurança requerem o desenvolvimento de uma especificação completa e analisável Não há métodos ou técnicas que sejam bons para todos os casos Quais diferenças a internet trouxe para a engenharia de software A internet não só levou ao desenvolvimento de sistemas massivos largamente distribuídos baseados em serviços como também deu base para a criação de uma indústria de aplicativos ou apps para dispositivos móveis que mudou a economia de software 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 Modelos de processo de software Representação simplificada abstrações de um processo de software Representam frameworks Modelos mais comuns Cascata Incremental Orientado a reuso FIGURA 21 O modelo em cascata FIGURA 22 Desenvolvimento incremental FIGURA 23 Engenharia de software orientada para o reuso Atividades do processo Atividades técnicas de colaboração e de gestão Objetivo especificar projeto e testar o software Diferentes ferramentas são usadas como apoio Atividades básicas Especificação Desenvolvimento Validação Evolução O processo de engenharia de requisitos Um modelo geral do processo de projeto Estágios do teste FIGURA 28 Evolução do sistema de software PROCESSO UNIFICADO 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 FIGURA 29 Desenvolvimento de um protótipo FIGURA 210 Entrega incremental Definir esboço dos requisitos Atribuir requisitos aos incrementos Projetar arquitetura do sistema Desenvolver incrementos do sistema Sistema incompleto Validar o incremento Integrar o incremento Validar o sistema Implantar o incremento Sistema completo Sistema final Sommerville 2019 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 Modelagem de Negócios Requisitos Análise e Design Implementação Teste Implantação Gerenc de Configuração e Mudança Gerenciamento de Projeto Ambiente Fases Iniciação Elaboração Construção Transição Iterações Inicial Elab nº 1 Elab nº 2 Const nº 1 Const nº 2 Const nº N Trans nº 1 Trans nº 2 IBM RUP Requisitos Visão Geral Novo Sistema Sistema Existente Nova Entrada Analisar o Problema Problema Incorreto Compreender as Necessidades dos Envolvidos Endereçar o problema correto Gerenciar Requisitos Mutáveis Definir o Sistema Gerenciar o Escopo do Sistema Não posso fazer todo o trabalho Trabalhar no escopo Refinar a Definição do Sistema IBM RUP Detalhamento do Fluxo de Trabalho Compreender as Necessidades dos Envolvidos Processo Unificado da Rational Exemplos de boas práticas Compreender as necessidades dos envolvidos Entrevistas Workshop de Requisitos Brainstorming e filtro de ideias Workshop de Caso de Uso Encenação Interpretação de papéis Análise dos requisitos existentes MÉTODOS ÁGEIS DESENVOLVIMENTO ÁGIL E DIRIGIDO A PLANOS Histórico motivação 1960s1970s crise do software Problemas com orçamento Problemas com prazo Problemas com qualidade Problemas com requisitos Problemas com manutenibilidade Etc Histórico motivação 1980s1990s engenharia de software tradicional Planejamento cuidadoso Qualidade formalizada Uso de métodos de análise e design Ferramentas CASE Computeraided software engineering Processo de desenvolvimento rigoroso e controlado abordagem pesada Histórico motivação 1980s1990s engenharia de software tradicional Desenvolvimento de softwares grandes e críticos ex sistemas aeroespaciais e de governo Sistemas duradouros precisam ter muito boa manutenibilidade Grandesdiferentes empresas Grandes equipes podendo estar dispersas geograficamente Longos períodos até 10 anos Histórico motivação 2000s2010s engenharia de software ágil Mudanças rápidas Novas oportunidades novos mercados novos produtos novos concorrentes Importância do software nesse cenário precisam ser desenvolvidos rapidamente com agilidade Tempo passar a ser o mais importante em alguns casos mais importante que qualidade Histórico motivação 2000s2010s engenharia de software ágil Requisitos instáveis muitas vezes Requisitos iniciais mudam pois clientes acham impossível prever como um sistema afetará as práticas de trabalho como um sistema interagirá com outros sistemas quais operações do usuário devem ser automatizadas Se todos requisitos forem definidos no início quando o software estiver pronto ele pode já estar desatualizado Histórico motivação 2000s2010s engenharia de software ágil Ambientes corporativos menores médio e pequeno porte Processos pesados causam muito overhead Gastase muito com planejamentoanálise comparando com implementaçãoteste Ainda no final da década de 1990 desenvolvedores propuseram processos mais leves os métodos ágeis Objetivo produzir rapidamente softwares úteis por meio de incrementos com cada incremento incluindo novas funcionalidades 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 Os princípios dos métodos ágeis Dificuldades limitações Cliente deve estar disposto e capaz de passar o tempo com a equipe de desenvolvimento Cliente deve ser capaz de representar todas as partes interessadas Membros da equipe podem não ter a personalidade adequada A organização pode não ter a cultura adequada Organizações investiram muito em definição e organização de processos Dificuldades limitações Priorizar mudanças pode ser extremamente difícil principalmente se há muitas partes envolvidas Manter simplicidade poder ser complicado Podese levar tempo para se fazer as simplificações desejáveis Pode dificultar negociações contratuais incluindo terceirizações Depende de maturidade de desenvolvedores FIGURA 31 Desenvolvimento dirigido por plano e desenvolvimento ágil Sommerville 2011 Implementação e teste unitário MÉTODOS ÁGEIS Sommerville 2019 Ciclo da Programação XP Proprietade coletiva Os pares de desenvolvedores trabalham em todas as áreas do sistema de modo que não se tornam ilhas de conhecimento e todos os desenvolvedores assumem a responsabilidade por todo o código Qualquer um pode mudar qualquer coisa Integração contínua Assim que o trabalho em uma tarefa é concluído ele é integrado ao sistema completo Após qualquer integração desse tipo todos os testes de unidade no sistema devem passar Planejamento incremental Os requisitos são registrados em cartões de história e as histórias a serem incluídas em um lançamento são determinadas de acordo com o tempo disponível e com sua prioridade relativa Os desenvolvedores decompen essas histórias em tarefas de desenvolvimento Representante do cliente Um representante do usuário final do sistema o cliente deve estar disponível em tempo integral para o time de programação Em um processo como esse o cliente é um membro do time de desenvolvimento sendo responsável por levar os requisitos do sistema ao time visando sua implementação Programação em pares Os desenvolvedores trabalham em pares conferindo o trabalho um do outro e oferecendo o apoio necessário para que o resultado final seja sempre satisfatório Refatoração Todos os desenvolvedores devem refatorar o código continuamente logo que sejam encontradas possíveis melhorias para ele Isso mantém o código simples e de fácil manutenção Projeto design simples Deve ser feito o suficiente de projeto design para satisfazer os requisitos atuais e nada mais Prescrição de medicação Kate é uma médica que deseja prescrever medicação para um paciente que frequenta sua clínica O registro do paciente já é exibido em seu computador então ela deve clicar no campo de medicação e selecionar medicação atual nova medicação ou substâncias Se escolher medicação atual o sistema pedirá para que ela verifique a dose se quiser mudála Kate fornecerá a nova dose e depois deverá confirmar a prescrição Se escolher nova medicação o sistema presumirá que ela sabe qual medicação prescrever Ao digitar as primeiras letras da medicação o sistema exibirá uma lista de possíveis medicamentos que começam com essas letras Ao escolher a medicação necessária o sistema responderá pedindo que ela confirme se a medicação escolhida está correta Ela deverá fornecer a dose e depois confirmar a prescrição Se ela escolher substâncias o sistema exibirá uma caixa de busca para a substância aprovada e então ela poderá pesquisar o medicamento que deseja Feita a busca lhe será solicitado que confirme se o medicamento selecionado está correto Ela deverá fornecer a dose e depois confirmar a prescrição O sistema sempre verificará se a dose está dentro da faixa aprovada Se não estiver será pedido a Kate que faça uma alteração Depois de confirmar a prescrição ela será exibida para conferência Kate deverá clicar em OK ou em Alterar Se OK for selecionado a prescrição será registrada no banco de dados de auditoria Se clicar em Alterar o processo de Prescrição de medicação é executado novamente Exemplos de cartões de tarefa para prescrição de medicação Tarefa 1 Mudar a dose do medicamento prescrito Tarefa 2 Seleção de substância Tarefa 3 Verificação da dose A verificação da dose é uma precaução de segurança para conferir se o médico não prescreveu uma dose perigosamente pequena ou grande Usando a identificação da substância para o nome genérico do medicamento procure a substância e recupere a dose máxima e a mínima recomendadas Confira a dose prescrita em relação ao máximo e ao mínimo Se estiver fora da faixa emita uma mensagem de erro dizendo que a dose é alta ou baixa demais Se estiver dentro da faixa habilite o botão Confirmar Características adicionais O cliente prioriza as histórias para implementação escolhendo as que podem ser imediatamente usadas por ele dentro de duas semanas Requisitos mudam histórias não implementadas mudam ou podem ser descartadas novos cartões podem ser desenvolvidos A nova versão só é aceita se todos os testes foram executados e passarem Na prática nem todos os princípios são sempre adotados Teste em XP Testfirst Teste incremental a partir de cenários Envolvimento de usuáriosclientes no desenvolvimento de testes e validação Uso de frameworks de testes automatizados Programação em pares Propriedade e responsabilidade coletiva ideia não nova de programação sem ego Revisão informal Apoio à refatoração Mais ganhos para programadores menos experientes O ciclo de sprint do Scrum Revisar o trabalho a ser feito Escolher os itens Planejar a sprint Scrum Revisar a sprint Sprint Backlog do produto Backlog da sprint Software potencialmente entregável Quando aplicar A análise mais simplesbásica indica em geral para Produtos novos Pequenomédio porte Existe o compromisso claro do cliente de se envolver no processo de desenvolvimento Não há muitas regrasregulamentos externos que afetam o software Para equipes pequenasintegradas Quando não aplicar Em geral Sistemas muito grandes Para sistemas críticos ex controle de segurança quando uma análise completa do sistema é essencial Para equipes grandes eou distribuídas Para manutençãoextensão de software Cliente prefere passar uma especificação e receber o software depois de um tempo Depende de regulamentações externas que não mudam Quando não aplicar Sistemas de grande porte Não é possível focar apenas no código do sistema É necessário fazer mais projeto adiantado e documentação do sistema A arquitetura de software precisa ser projetada É necessário haver documentos produzidos para descrever os aspectos críticos do sistema como esquemas de banco de dados a divisão de trabalho entre as equipes etc Quando não aplicar Há relatos de uso de métodos ágeis para sistemas grandescríticos eou com equipes grandesdistribuídas Mas ajustes consideráveis precisam ser aplicados Kanban Kanban é um sistema de gestão visual para controle de tarefas e fluxos de trabalho através da utilização de colunas e cartões Quadro Kanban Para fazer Planejar Executar Revisar Ajustar Feito Bibliografia da Aula MEDEIROS E Desenvolvendo software com UML 20 definitivo Pearson 2004 PFLEEGER S L Engenharia de software teoria e prática 2a ed Pearson 2004 RATIONAL Rational Unified Process Best Practices for Software Development Teams Disponível em httpswwwibmcomdeveloperworksrationallibrarycontent03July100012511251bestpractices TP026Bpdf Data de acesso agosto2020 SOMMERVILLE I Engenharia de software 10 ed São Paulo Pearson 2019
Texto de pré-visualização
Senac Modelagem de Sistemas de Informação Bacharelado em Sistemas de Informação Profª Claudia Bianchi Progetti claudiabprogettispsenacbrclaudiaprogettihotmailcom Aula 2 Processo de software e desenvolvimento ágil Ciclo de vida de desenvolvimento de sistemas MODELOS DE PROCESSO DE SOFTWARE E ATIVIDADES DE SOFTWARE FIGURA 11 Perguntas frequentes sobre engenharia de software Pergunta Resposta O que é software Programas de computador e documentação associada Os produtos de software podem ser desenvolvidos dos para um determinado cliente ou para um mercado genérico Quais são os atributos do bom software O bom software deve proporcionar a funcionalidade e o desempenho necessários e deve ser mantido útil e com dependabilidade dependability O que é engenharia de software A engenharia de software é uma disciplina de engenharia que se preocupa com os aspectos da produção de software desde sua concepção inicial até sua operação e manutenção Quais são as atividades fundamentais da engenharia de software Especificação desenvolvimento validação e evolução do software Qual é a diferença entre engenharia de software e ciência da computação A ciência da computação se concentra na teoria e nos fundamentos A engenharia de software se preocupa com as questões práticas de desenvolver e entregar software útil Qual é a diferença entre engenharia de software e engenharia de sistemas A engenharia de sistemas se preocupa com todos os aspectos do desenvolvimento de sistemas computacionais incluindo hardware software e engenharia de processos A engenharia de software faz parte desse processo mais geral Quais são os principais desafios enfrentados pela engenharia de software Lidar com a crescente diversidade com as demandas por menores prazos de entrega e desenvolver software confiável Quais são os custos da engenharia de software Aproximadamente 60 dos custos de software são relativos ao desenvolvimento e 40 aos testes Quanto ao software personalizado os custos de evolução frequentemente ultrapassam os de desenvolvimento Quais são os melhores métodos e técnicas de engenharia de software Ainda que todos os projetos de software devam ser gerenciados e desenvolvidos profissionalmente técnicas diferentes são adequadas para tipos diferentes de sistemas Por exemplo jogos devem ser sempre desenvolvidos usando uma série de protótipos enquanto sistemas de controle críticos em segurança requerem o desenvolvimento de uma especificação completa e analisável Não há métodos ou técnicas que sejam bons para todos os casos Quais diferenças a internet trouxe para a engenharia de software A internet não só levou ao desenvolvimento de sistemas massivos largamente distribuídos baseados em serviços como também deu base para a criação de uma indústria de aplicativos ou apps para dispositivos móveis que mudou a economia de software 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 Modelos de processo de software Representação simplificada abstrações de um processo de software Representam frameworks Modelos mais comuns Cascata Incremental Orientado a reuso FIGURA 21 O modelo em cascata FIGURA 22 Desenvolvimento incremental FIGURA 23 Engenharia de software orientada para o reuso Atividades do processo Atividades técnicas de colaboração e de gestão Objetivo especificar projeto e testar o software Diferentes ferramentas são usadas como apoio Atividades básicas Especificação Desenvolvimento Validação Evolução O processo de engenharia de requisitos Um modelo geral do processo de projeto Estágios do teste FIGURA 28 Evolução do sistema de software PROCESSO UNIFICADO 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 FIGURA 29 Desenvolvimento de um protótipo FIGURA 210 Entrega incremental Definir esboço dos requisitos Atribuir requisitos aos incrementos Projetar arquitetura do sistema Desenvolver incrementos do sistema Sistema incompleto Validar o incremento Integrar o incremento Validar o sistema Implantar o incremento Sistema completo Sistema final Sommerville 2019 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 Modelagem de Negócios Requisitos Análise e Design Implementação Teste Implantação Gerenc de Configuração e Mudança Gerenciamento de Projeto Ambiente Fases Iniciação Elaboração Construção Transição Iterações Inicial Elab nº 1 Elab nº 2 Const nº 1 Const nº 2 Const nº N Trans nº 1 Trans nº 2 IBM RUP Requisitos Visão Geral Novo Sistema Sistema Existente Nova Entrada Analisar o Problema Problema Incorreto Compreender as Necessidades dos Envolvidos Endereçar o problema correto Gerenciar Requisitos Mutáveis Definir o Sistema Gerenciar o Escopo do Sistema Não posso fazer todo o trabalho Trabalhar no escopo Refinar a Definição do Sistema IBM RUP Detalhamento do Fluxo de Trabalho Compreender as Necessidades dos Envolvidos Processo Unificado da Rational Exemplos de boas práticas Compreender as necessidades dos envolvidos Entrevistas Workshop de Requisitos Brainstorming e filtro de ideias Workshop de Caso de Uso Encenação Interpretação de papéis Análise dos requisitos existentes MÉTODOS ÁGEIS DESENVOLVIMENTO ÁGIL E DIRIGIDO A PLANOS Histórico motivação 1960s1970s crise do software Problemas com orçamento Problemas com prazo Problemas com qualidade Problemas com requisitos Problemas com manutenibilidade Etc Histórico motivação 1980s1990s engenharia de software tradicional Planejamento cuidadoso Qualidade formalizada Uso de métodos de análise e design Ferramentas CASE Computeraided software engineering Processo de desenvolvimento rigoroso e controlado abordagem pesada Histórico motivação 1980s1990s engenharia de software tradicional Desenvolvimento de softwares grandes e críticos ex sistemas aeroespaciais e de governo Sistemas duradouros precisam ter muito boa manutenibilidade Grandesdiferentes empresas Grandes equipes podendo estar dispersas geograficamente Longos períodos até 10 anos Histórico motivação 2000s2010s engenharia de software ágil Mudanças rápidas Novas oportunidades novos mercados novos produtos novos concorrentes Importância do software nesse cenário precisam ser desenvolvidos rapidamente com agilidade Tempo passar a ser o mais importante em alguns casos mais importante que qualidade Histórico motivação 2000s2010s engenharia de software ágil Requisitos instáveis muitas vezes Requisitos iniciais mudam pois clientes acham impossível prever como um sistema afetará as práticas de trabalho como um sistema interagirá com outros sistemas quais operações do usuário devem ser automatizadas Se todos requisitos forem definidos no início quando o software estiver pronto ele pode já estar desatualizado Histórico motivação 2000s2010s engenharia de software ágil Ambientes corporativos menores médio e pequeno porte Processos pesados causam muito overhead Gastase muito com planejamentoanálise comparando com implementaçãoteste Ainda no final da década de 1990 desenvolvedores propuseram processos mais leves os métodos ágeis Objetivo produzir rapidamente softwares úteis por meio de incrementos com cada incremento incluindo novas funcionalidades 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 Os princípios dos métodos ágeis Dificuldades limitações Cliente deve estar disposto e capaz de passar o tempo com a equipe de desenvolvimento Cliente deve ser capaz de representar todas as partes interessadas Membros da equipe podem não ter a personalidade adequada A organização pode não ter a cultura adequada Organizações investiram muito em definição e organização de processos Dificuldades limitações Priorizar mudanças pode ser extremamente difícil principalmente se há muitas partes envolvidas Manter simplicidade poder ser complicado Podese levar tempo para se fazer as simplificações desejáveis Pode dificultar negociações contratuais incluindo terceirizações Depende de maturidade de desenvolvedores FIGURA 31 Desenvolvimento dirigido por plano e desenvolvimento ágil Sommerville 2011 Implementação e teste unitário MÉTODOS ÁGEIS Sommerville 2019 Ciclo da Programação XP Proprietade coletiva Os pares de desenvolvedores trabalham em todas as áreas do sistema de modo que não se tornam ilhas de conhecimento e todos os desenvolvedores assumem a responsabilidade por todo o código Qualquer um pode mudar qualquer coisa Integração contínua Assim que o trabalho em uma tarefa é concluído ele é integrado ao sistema completo Após qualquer integração desse tipo todos os testes de unidade no sistema devem passar Planejamento incremental Os requisitos são registrados em cartões de história e as histórias a serem incluídas em um lançamento são determinadas de acordo com o tempo disponível e com sua prioridade relativa Os desenvolvedores decompen essas histórias em tarefas de desenvolvimento Representante do cliente Um representante do usuário final do sistema o cliente deve estar disponível em tempo integral para o time de programação Em um processo como esse o cliente é um membro do time de desenvolvimento sendo responsável por levar os requisitos do sistema ao time visando sua implementação Programação em pares Os desenvolvedores trabalham em pares conferindo o trabalho um do outro e oferecendo o apoio necessário para que o resultado final seja sempre satisfatório Refatoração Todos os desenvolvedores devem refatorar o código continuamente logo que sejam encontradas possíveis melhorias para ele Isso mantém o código simples e de fácil manutenção Projeto design simples Deve ser feito o suficiente de projeto design para satisfazer os requisitos atuais e nada mais Prescrição de medicação Kate é uma médica que deseja prescrever medicação para um paciente que frequenta sua clínica O registro do paciente já é exibido em seu computador então ela deve clicar no campo de medicação e selecionar medicação atual nova medicação ou substâncias Se escolher medicação atual o sistema pedirá para que ela verifique a dose se quiser mudála Kate fornecerá a nova dose e depois deverá confirmar a prescrição Se escolher nova medicação o sistema presumirá que ela sabe qual medicação prescrever Ao digitar as primeiras letras da medicação o sistema exibirá uma lista de possíveis medicamentos que começam com essas letras Ao escolher a medicação necessária o sistema responderá pedindo que ela confirme se a medicação escolhida está correta Ela deverá fornecer a dose e depois confirmar a prescrição Se ela escolher substâncias o sistema exibirá uma caixa de busca para a substância aprovada e então ela poderá pesquisar o medicamento que deseja Feita a busca lhe será solicitado que confirme se o medicamento selecionado está correto Ela deverá fornecer a dose e depois confirmar a prescrição O sistema sempre verificará se a dose está dentro da faixa aprovada Se não estiver será pedido a Kate que faça uma alteração Depois de confirmar a prescrição ela será exibida para conferência Kate deverá clicar em OK ou em Alterar Se OK for selecionado a prescrição será registrada no banco de dados de auditoria Se clicar em Alterar o processo de Prescrição de medicação é executado novamente Exemplos de cartões de tarefa para prescrição de medicação Tarefa 1 Mudar a dose do medicamento prescrito Tarefa 2 Seleção de substância Tarefa 3 Verificação da dose A verificação da dose é uma precaução de segurança para conferir se o médico não prescreveu uma dose perigosamente pequena ou grande Usando a identificação da substância para o nome genérico do medicamento procure a substância e recupere a dose máxima e a mínima recomendadas Confira a dose prescrita em relação ao máximo e ao mínimo Se estiver fora da faixa emita uma mensagem de erro dizendo que a dose é alta ou baixa demais Se estiver dentro da faixa habilite o botão Confirmar Características adicionais O cliente prioriza as histórias para implementação escolhendo as que podem ser imediatamente usadas por ele dentro de duas semanas Requisitos mudam histórias não implementadas mudam ou podem ser descartadas novos cartões podem ser desenvolvidos A nova versão só é aceita se todos os testes foram executados e passarem Na prática nem todos os princípios são sempre adotados Teste em XP Testfirst Teste incremental a partir de cenários Envolvimento de usuáriosclientes no desenvolvimento de testes e validação Uso de frameworks de testes automatizados Programação em pares Propriedade e responsabilidade coletiva ideia não nova de programação sem ego Revisão informal Apoio à refatoração Mais ganhos para programadores menos experientes O ciclo de sprint do Scrum Revisar o trabalho a ser feito Escolher os itens Planejar a sprint Scrum Revisar a sprint Sprint Backlog do produto Backlog da sprint Software potencialmente entregável Quando aplicar A análise mais simplesbásica indica em geral para Produtos novos Pequenomédio porte Existe o compromisso claro do cliente de se envolver no processo de desenvolvimento Não há muitas regrasregulamentos externos que afetam o software Para equipes pequenasintegradas Quando não aplicar Em geral Sistemas muito grandes Para sistemas críticos ex controle de segurança quando uma análise completa do sistema é essencial Para equipes grandes eou distribuídas Para manutençãoextensão de software Cliente prefere passar uma especificação e receber o software depois de um tempo Depende de regulamentações externas que não mudam Quando não aplicar Sistemas de grande porte Não é possível focar apenas no código do sistema É necessário fazer mais projeto adiantado e documentação do sistema A arquitetura de software precisa ser projetada É necessário haver documentos produzidos para descrever os aspectos críticos do sistema como esquemas de banco de dados a divisão de trabalho entre as equipes etc Quando não aplicar Há relatos de uso de métodos ágeis para sistemas grandescríticos eou com equipes grandesdistribuídas Mas ajustes consideráveis precisam ser aplicados Kanban Kanban é um sistema de gestão visual para controle de tarefas e fluxos de trabalho através da utilização de colunas e cartões Quadro Kanban Para fazer Planejar Executar Revisar Ajustar Feito Bibliografia da Aula MEDEIROS E Desenvolvendo software com UML 20 definitivo Pearson 2004 PFLEEGER S L Engenharia de software teoria e prática 2a ed Pearson 2004 RATIONAL Rational Unified Process Best Practices for Software Development Teams Disponível em httpswwwibmcomdeveloperworksrationallibrarycontent03July100012511251bestpractices TP026Bpdf Data de acesso agosto2020 SOMMERVILLE I Engenharia de software 10 ed São Paulo Pearson 2019