Baixe o app para aproveitar ainda mais
Prévia do material em texto
PROFESSORA POLYANNA P. GOMES FABRIS Especialista em Engenharia de Software com UML PROCESSOS DE NEGÓCIO E SOFTWARE Vídeo Aula 1 Conceito da Engenharia de Software em Processos de Negócios Livros Indicados Como escolher o melhor modelo de desenvolvimento de Software Conhecer alguns Ciclos de vida de Software e o processo Por que surgiu Engenharia de Software? OBJETIVOS DESTA AULA 1950 a 60 (Primeira Era) 1970 (Segunda Era) 1980 (Terceira Era) 1990 (Quarta Era) HISTÓRICO DE SOFTWARE INSTRUÇÕES (programas de computador) executados em computador geram informações através das funcionalidades ESTRUTURAS DE DADOS que possibilitam que os programas manipulem adequadamente a informação DOCUMENTOS que descrevem a construção, operação e o uso dos programas COMPOSIÇÃO DO SOFTWARE Minha informação Projetos e Manuais Executar uma função PROFESSORA POLYANNA P. GOMES FABRIS Especialista em Engenharia de Software com UML PROCESSOS DE NEGÓCIO E SOFTWARE Vídeo Aula 2 Características e a crise de software Após configurado ocorre a estabilização do Software; A cada modificação eleva-se os índices de falhas; Ao longo do tempo a curva de falhas continua aumentando. CARACTERÍSTICAS DE SOFTWARE CARACTERÍSTICAS DE SOFTWARE Dimensão espacial O Software se deteriora Gerentes de projetos sem experiências Resistência a mudanças CAUSAS DA CRISE DO SOFTWARE Falta de treinamento contínuo Aumento expressivo da demanda por Software CAUSAS DA CRISE DO SOFTWARE Estimativa de prazo e de custos Produtividade das pessoas Dificuldade em manter o Software Qualidade de Software CONSEQUÊNCIAS DA CRISE PROFESSORA POLYANNA P. GOMES FABRIS Especialista em Engenharia de Software com UML PROCESSOS DE NEGÓCIO E SOFTWARE Vídeo Aula 3 A Engenharia de Software Em 1968, Fritz Bauer diz: “O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais.” (Roger Pressman “Engenharia de Software”) A Engenharia de Software surgiu com foco em qualidade no processo de Software. ENGENHARIA DE SOFTWARE 1) Aplicação de uma abordagem sistemática, disciplinada e quantificável ao desenvolvimento, operação e manutenção de software, ou seja, a aplicação da Engenharia ao Software 2) O estudo de abordagens do tipo declarado em (1) [IEEE] ENGENHARIA DE SOFTWARE Foco na Qualidade Processo Métodos Ferramentas Base fundamental A Qualidade Total e outras iniciativas equivalentes com objetivo de resultar em mudanças culturais permitindo o avanço na implementação da maturidade na Engenharia de Software Estrutura Framework que permite atividades conscientes e formais, através das pessoas e de objetivos previstos em resultados estabelecidos para cada área do processo Instrumentos Mecanismos que integram metodologia, processo e tarefas automatizados, também chamado de CASE (Computer Aided Software Engineering) “Como fazer” Conjunto de Tarefas com técnicas particulares para cada fase do desenvolvimento de Software Ao iniciar uma fase são necessários produtos da fase anterior; Para realizar atividades previstas na fase, são necessários Metodologias e Recursos (humanos, hardware, software, etc); Resultando novos produtos de acordo com o previsto na fase. ELEMENTOS DO CICLO DE VIDA FASE Produtoresultante Produtos da Fase anterior Método de desenvolvimento Recursos Necessário PROFESSORA POLYANNA P. GOMES FABRIS Especialista em Engenharia de Software com UML PROCESSOS DE NEGÓCIO E SOFTWARE Vídeo Aula 4 Modelos de Processos (Parte 1) Natureza da aplicação a ser desenvolvida; Metodologia e Ferramentas a serem utilizadas; Produto ou serviço final a ser entregue; Complexidade da aplicação; Disponibilidade dos envolvidos no projeto; Quantidade de interação com usuários. COMO ESCOLHER O MODELO Chamado de Clássico ou Cascata; Foi o primeiro modelo adotado no desenvolvimento de software; O modelo mais usado na engenharia de software; As fases são estabelecidas pelas Funções realizadas na engenharia convencional; Abordagem sistemática. MODELO SEQUENCIAL OU CLÁSSICO PROJETO CODIFICAÇÃO TESTE Engenharia de Sistemas/Informação ANÁLISE Análise Projeto Codificação Teste Manutenção Modelo original proposto por Royce com feedback Engenharia de sistemas Engenharia de Sistemas –Coletar os requisitos do sistema, quantidade restrita de projeto e análise de alto nível; –Priorizar o essencial do software; – Identificar interfaces com outros sistemas, banco de dados, entre outros. MODELO SEQUENCIAL OU CLÁSSICO Análise de Requisitos –Coletar os requisitos com detalhamento; –Priorizar o escopo de um único sistema; –Compreender o domínio da informação, as regras de negócios e funcionalidades; –Documentar e validar requisitos. MODELO SEQUENCIAL OU CLÁSSICO Projeto – Transferir o conhecimento dos requisitos em estrutura e arquitetura de software Compor projeto em: –estrutura de dados; – arquitetura de software; –procedimentos detalhados; – caracterização da interface. MODELO SEQUENCIAL OU CLÁSSICO Codificação –Transferir o conhecimento do projeto em programas de computador; – Estruturar logicamente os comandos para atender os procedimentos especificados; –Construção do projeto. MODELO SEQUENCIAL OU CLÁSSICO Teste –Verificar se o software está fornecendo todas informações previstas nos requisitos; – Encontrar falhas de construção; –Garantir que todas instruções sejam testadas. MODELO SEQUENCIAL OU CLÁSSICO PROFESSORA POLYANNA P. GOMES FABRIS Especialista em Engenharia de Software com UML PROCESSOS DE NEGÓCIO E SOFTWARE Vídeo Aula 5 Modelos de Processos (Parte 2) Apropriado quanto o cliente não tem os requisitos de entradas e saídas devidamente definidos; É usado como um mecanismo para identificar Requisitos de Software; Criação de um modelo bem próximo do que o Software irá possuir; O cliente participa ativamente da construção e validação do Protótipo. MODELO PROTOTIPAÇÃO Baseado no modelo sequencial, porém com características de maior velocidade; O desenvolvimento é rápido por utilizar uma construção baseada em componentes; Utilizado somente quando o escopo do Software é específico e restrito; Uso de Ferramentas de desenvolvimento. MODELO 4ª GERAÇÃO Requisitos Implementação Projetos Testes MODELO 4ª GERAÇÃO 1. Requisitos são detalhados, com o cliente; 2. O projeto curto e consistente; 3. A geração de código são automáticas; 4. Execução de testes e documentação de uso do Software. MODELO 4ª GERAÇÃO Potencialmente usado para desenvolvimento rápido e incremental; Liberação de versões incrementais para implantação; Novas versões são complementares e-ou melhoradas; MODELO ESPIRAL 1. Determinação dos objetivos; 2. Análise e tratamento dos Riscos; 3. Desenvolvimento e validação do Software; 4. Avaliação com o cliente. MODELO ESPIRAL Utiliza o processo iterativo; Organização baseada no conteúdo; –Disciplinas, papéis, artefatos, atividades; –Processo de configuração, processo Evolutivo; Elementos chave do RUP: Funções, Tarefas e Produtos de Trabalho (artefato); Uma iteração pode incluir múltiplas disciplinas; Granularidade: tarefas de poucas horas a poucos dias. MODELO RUP PROFESSORA POLYANNA P. GOMESFABRIS Especialista em Engenharia de Software com UML PROCESSOS DE NEGÓCIO E SOFTWARE Vídeo Aula 6 Engenharia de Requisitos Determinar o escopo do sistema; Meio para interação com os usuários; Tipos de requisitos; Como levantar requisitos. OBJETIVOS DESTA AULA “Condição necessária para a obtenção de certo objetivo.” Requisitos funcionais e não-funcionais. Alternativas para melhorar e agilizar uma tarefa. Alternativas para solucionar um problema. DEFINIÇÕES DE REQUISITOS Qualidade está relacionada com os Requisitos designados para o Software. Não conformidades aos requisitos considera-se falta de qualidade. Qualidade deve ser definida, medida, monitorada, gerenciada e melhorada. Prioridade na comunicação e descrição do requisito. Visão profissional da qualidade RequisitosRequisitos Engenharia de Software Requisitos Atendidos Usuário Software REQUISITOS NO PROCESSO PROFESSORA POLYANNA P. GOMES FABRIS Especialista em Engenharia de Software com UML PROCESSOS DE NEGÓCIO E SOFTWARE Vídeo Aula 7 Análise de Requisitos Atividade a ser executada após a definição do Escopo do sistema. Desempenhada por um Analista de Sistemas, com apoio do Analista de Negócios e participação dos Usuários finais. Gerenciar requisitos a serem desenvolvidos e em desenvolvimento. Analisar impacto das mudanças de requisitos. ANÁLISE DE REQUISITOS Demanda em software está a cada dia mais específica. Requisitos são necessidades pontuais. Sempre deve promover a solução de problemas. RECONHECIMENTO DO PROBLEMA Não importa um bom design e uma boa programação, caso os requisitos não refletirem o que usuário necessita. A meta é o reconhecimento dos elementos básicos do problema, conforme percebido pelo cliente. RECONHECIMENTO DO PROBLEMA Administrador do projeto Clientes Analistas Desenvolvedores Plano de projeto de Software Especificação de requisitos de Software Construção do Software REQUISITOS MAL DEFINIDOS “O novo sistema automatizado traz maior velocidade aos nossos negócios. Vamos perder Clientes mais rapidamente.” PROFESSORA POLYANNA P. GOMES FABRIS Especialista em Engenharia de Software com UML PROCESSOS DE NEGÓCIO E SOFTWARE Vídeo Aula 8 Avaliação do Problema Avaliar o problema na situação real, ambiente do usuário. Reconhecer e definir as funcionalidades do novo sistema. Identificar as entradas e saídas do sistema (dados e informações). AVALIAÇÃO DO PROBLEMA E SÍNTESE DA SOLUÇÃO Entender o comportamento do sistema. Estabelecer características de Interface. Determinar as restrições do projeto. AVALIAÇÃO DO PROBLEMA E SÍNTESE DA SOLUÇÃO Descrição do fluxo e estrutura da informação. Refinamento detalhado de todas funções. Estabelecimento das características das interfaces. ESPECIFICAÇÃO DE REQUISITOS Foco em “o que” o sistema deverá contemplar, não em “como”. Detalhamento das restrições. Especificação dos critérios de validação. Validação dos requisitos com o cliente. ESPECIFICAÇÃO DE REQUISITOS Para refletir PROFESSORA POLYANNA P. GOMES FABRIS Especialista em Engenharia de Software com UML PROCESSOS DE NEGÓCIO E SOFTWARE Vídeo Aula 9 Levantamento de Requisitos Compreende conceitos abstratos. Capacidade de sintetizar “soluções”. Visualizar fatos em fontes conflitantes ou confusas. Entender o ambiente do usuário. Boa comunicação verbal e escrita. HABILIDADES DE UM ANALISTA –Conhecer o problema e alternativas para solução. – Exemplo de como NÃO deve acontecer... LEVANTAMENTO DE REQUISITOS Eu vou subir e ver o que eles querem e o resto de vocês comecem a codificar. Elaborar uma lista de desejos dos usuários. Priorizar os requisitos coletados. Conhecer detalhadamente as regras de negócios. Escolher os envolvidos de acordo com escopo do projeto. Sintetizar o problema. Revisar e validar requisitos. LEVANTAMENTO DE DADOS Certificar-se de que está executando o levantamento com a pessoa certa (é oficial?). Conhecer restrições que impedem soluções do problema (performance, escalabilidade, portabilidade, etc). INICIANDO LEVANTAMENTO Vamos refletir um pouco sobre o assunto... Todas informações novas são estimulantes, certo? Mas nem sempre conseguimos aprender tudo somente nas reuniões... Facilitaded Application Specification Techniques. Conhecida como JAD (Joint Application Development). Reunião em local neutro. Participação dos Analistas de sistemas e do Cliente. REUNIÃO – FAST Deve ser elaborada um agenda dos pontos mais importantes. Um moderador é designado para controlar a reunião. Um mecanismo é definido (planilha, flip-chart, ou cartazes). Relacionar as possíveis soluções para o problema. REUNIÃO – FAST Preparação do workshop. Conduzir a sessão. Encontros no qual o analista expõe uma tecnologia ou cenário. Os participantes devem conhecer e dar sugestões. Consolidar resultados. WORKSHOP Definir o objetivo do encontro. Gerar o maior número de ideias para o assunto. Não permitir críticas ou debates. Reunir e combinar as ideias. Todos devem expressar seu voto. Priorizar cada ideia por categoria. BRAINSTORMING Exemplo para Brainstorming PROFESSORA POLYANNA P. GOMES FABRIS Especialista em Engenharia de Software com UML PROCESSOS DE NEGÓCIO E SOFTWARE Vídeo Aula 10 Complemento Glossário – Sinônimos – Siglas –Termos técnicos Análise de risco –De Projeto – Técnico REQUISITO – COMPLEMENTO Protótipos e provas – Janelas –Relatórios –Gráficos – Formulários REQUISITO – COMPLEMENTO O que o sistema deve fazer (“o que”). – Evidentes – o que é mostrado para o usuário em forma de diálogo com o sistema. –Ocultos – o que é executado pelo sistema porém não é mostrado na interface com o usuário. Restrições para que o requisito não seja atendido REQUISITO – FUNCIONAL Restrições colocadas sobre como o sistema deve realizar seus requisitos funcionais. –Obrigatórios – devem ser obtidos de qualquer maneira. –Desejados – podem ser obtidos caso não cause defeito no procedimento. Restrições a nível do sistema – ou seja, Suplementares. REQUISITO – NÃO-FUNCIONAL Segurança – restrições de acesso, por perfil de usuário à determinadas funções ou informações. Performance – nível de aceitação para resposta a uma determinada interface. REQUISITO – NÃO-FUNCIONAL Compatibilidade – tipo de modem, impressora, moeda do país, são configuráveis. Implementação – linguagem de programação, reutilização de biblioteca disponíveis (legado). REQUISITO – NÃO-FUNCIONAL Através de Fluxo de informação ou de funcionalidade. Através de Caso de uso. Representar as interfaces com o usuários. REQUISITOS – REPRESENTAÇÃO Descrição funcional; Descrição comportamental; Critério de Validação; Referências. REQUISITOS – REPRESENTAÇÃO Engenharia de requisitos http://www.inf.ufes.br/~falbo/files/Notas_Aula_ Engenharia_Requisitos.pdf Conceitos: Especificação de requisitos http://www.macoratti.net/07/ 12/net_fer.htm Saiba mais... http://elearning.bizagi.com/my/ http://tiinteligente.blogspot.com.br/2012/12/c obit-estrutura-dos-processos.html LINK COMPLEMENTAR PROFESSORA POLYANNA P. GOMES FABRIS Especialista em Engenharia de Software com UML
Compartilhar