Please enable JavaScript.

Coggle requires JavaScript to display documents.

ENGENHARIA DE SOFTWARE - Coggle Diagram

- - - - A integração entre as atividades
      - Bom andamento das atividades
- - - - Exemplo: teclas digitais de um forno micro-ondas, fone via bluetooth
  - - - Exemplo: Calculos complexos (autocad)
  - - - Exemplo: robótica
  - - - Exemplo: software de gestão empresaria (Apps), word, excel, whatsapp etc.
  - - - Exemplo: Siri, Alexa, Cortana
  - - - Exemplo: sistema
        operacional e compiladores
- - - - divide as responsabilidades de forma individual ou coletiva
    - - Conforme o Planejamento, os Gestores têm a possibilidade de estimar e medir o tempo para o desenvolvimento de cada Projeto
    - - Importância fundamental
      - Por meio dela que as equipes de desenvolvimento recebem informações
      - Necessidade do Cliente em relação ou produto que está sendo desenvolviddo
  - - - Mudanças Processuais
      - Mudanças Tecnológicas
  - - - aplicativos, softwares, jogos e variados tipos de sistema para
        computadores, dispositivos móveis e consoles
    - - design e funcionalidade de softwares
    - - gerenciamento de projetos em empresas de computação e software
    - - testes e ajustes em sistemas já existentes
- - - - Definição das funcionalidades do software e as restrições em seu funcionamento
        
        Envolve
        
        Engenharia de sistema
        
        questões extra software
        
        análise de requisitos na qual levanta as
        necessidades do software
        
        estabelece uma solução geral para
        o problema
        
        produção de um documento com a especificação de requisitos e
        a especificação de Sistema
        
        inclui um plano de
        testes para verificar a adequação
        
        descrição funcional do sistema
    - - planejamento do software
        
        Projeto arquitetural
        
        desenvolve um modelo conceitual, composto de módulos mais ou menos independentes
        
        Projeto de interface
        
        cada módulo tem sua interface de comunicação estudada e definida
        
        Projeto detalhado
        
        os módulos em si são definidos, e possivelmente traduzidos para pseudocódigo
    - - o software deve ser produzido de modo que cumpra sua especificação
      - acontece a chamada “programação” ou “codificação”
      - Após a programação o código precisa ser validado
        
        Teste de Unidade e de Módulo
        
        são feitos testes para verificar a presença de erros e
        comportamento adequado em nível das funções e módulos básicos do sistema
        
        Integração
        
        união de diferentes módulos implementados em um único produto e testes da integração entre eles quando operando em conjunto
    - - software precisa evoluir para atender a novas
        necessidades ou mudanças solicitadas pelo cliente
      - O software em geral entra em um ciclo
        iterativo que abrange todas as fases anteriores
    - - cada tipo de projeto um Modelo de Processo será o mais adequado
      - a escolha de um modelo deve ser embasada no custo-benefício que ele pode trazer no momento do desenvolvimento
      - projeto pequeno não serão necessárias muitas tratativas de controle podendo talvez ser desenvolvido por um ou dois programadores
      - projetos maiores, um controle mais minucioso de variantes será necessário, por causa da maior quantidade de mudanças durante o processo
      - Modelos genéricos de processo de software
        
        Modelo cascata
        
        separa e distingue as fases de especificação e desenvolvimento
        
        Desenvolvimento evolucionário
        
        as atividades de especificação e desenvolvimento estão entrelaçadas
        
        Desenvolvimento baseado no reuso
        
        o software é montado a partir de componentes
        existentes
      - Modelos são classificados em dois grupos
        
        Metodologias tradicionais
        
        mais empregado em empresas com comunicação formal, com
        projetos longos e complexos e requisitos bem definidos
        
        Metodologias ágeis
        
        usado por organizações que dão ênfase à colaboração, projetos que possuem requisitos que mudam muito e exigem comunicação mais próxima com o cliente
- - - - surgimento de outros
        modelos
        
        Evolução dos modelos de ciclo de
        vida
        
        Espiral
    - - Mais conhecido entre os profissionais da área de desenvolvimento de sistemas
      - Nome de cascata por ser um processo executado em sequência
      - Primeiro modelo de ciclo de vida de desenvolvimento de software
      - Chamado de Ciclo de vida clássico
      - Modelo sugere uma abordagem sequencial e sistemática
        
        Fases
        
        modelagem
        
        construção
        
        planejamento
        
        disponibilação
        
        especificação dos requisitos do cliente
        
        suporte contínuo do software concluído
      - Apresenta etapas muito bem
        definidas
      - Facilita o gerenciamento dos projetos
      - Separação do projeto em etapas
      - O modelo não prevê alterações de requisitos
        no meio do processo
      - Apenas uma definição detalhada no início que será implementada criteriosamente para ser entregue ao final do fluxo
      - O desenvolvimento de software tem algumas particularidades que tornam o modelo em cascata inapropriado
        
        Leva a diversos
        contratempos (DESVANTAGENS)
        
        problemas financeiros devido à ultrapassagem do orçamento previsto
        
        dificuldade em atender às expectativas dos usuários finais
        
        dificuldade para cumprir o cronograma do projeto e os prazos de entrega
        
        Equipe limitada a produtividade
      - Mudança de requisitos
        
        O modelo cascata não permite flexibilidade
        
        Todas as etapas são
        executadas e o primeiro resultado só é visto no final
        
        Requisitos de um software não são sempre estáveis
        
        Necessidades dos clientes mudam com o tempo
        
        Caso o desenvolvimento seja demorado
        
        quando as etapas do modelo em cascata forem concluídas e o software estiver pronto, pode ser que ele já esteja obsoleto
  - - - feita após um primeiro contato com o cliente e objetiva que todos os envolvidos consigam interagir com esse protótipo
      - tendo uma ideia de como o software funcionará para
        aprovar ou sugerir modificações
    - - Desvantagens
        
        fonte de retrabalho e alto custo
        
        considerar um tempo de
        criação e validação do protótipo
        
        o ciclo de vida do software pode demandar
        maior tempo para ser executado
      - Vantagens
        
        os requisitos se tornam mais visuais e intuitivos
        
        possibilita que o cliente tenha maior certeza de que expressou suas necessidades corretamente
        
        receberá o software esperado
  - - - vantagens
        
        apresenta requisitos e etapas bem definidos
      - desvantagens
        
        alto custo de execução, por considerar diversas prototipações, uma para cada fase percorrida
    - - Estágio 2
        
        devem ser analisados os riscos das
        decisões do estágio anterior construindo protótipos ou realizando simulações do software
      - Estágio 3
        
        consiste nas atividades da fase de desenvolvimento, incluindo
        design, especificação, codificação e verificação, A principal característica é que a cada especificação que vai surgindo a cada ciclo
      - Estágio 1
        
        devem ser determinados objetivos, soluções
        alternativas e restrições
      - Estágio 4
        
        compreende a revisão das etapas anteriores e o planejamento da
        próxima fase.
        
        neste planejamento, dependendo dos resultados obtidos nos
        estágios anteriores, as decisões, análise de riscos e verificação pode-se optar por seguir o desenvolvimento num modelo linear, tal como o cascata, Evolutivo ou Transformação
- - - - O funcionamento versus documentação
        
        favorece a funcionalidade da criação de
        software e não somente o design
      - Colaboração do cliente
        
        funcionalidade da criação de software, que favorece a interação
        contínua com o cliente a fim de compreender seus desejos e anseios com mais precisão
      - As pessoas frete ao processo
        
        objetiva favorecer relacionamentos no ato da
        construção do software
      - Consertar problemas e se adaptar a mudanças
        
        favorece uma construção dinâmica
        e não engessada, onde consertar problemas é mais importante que manter a burocracia
  - - - Atende vários tipos de projetos e tem como valor a comunicação com o cliente e relacionamento do desenvolvedor com o cliente
      - Objetivo de reduzir o tempo
      - Evita a criação de ferramentas complexas que não serão utilizadas
      - Busca diferenciar a metodologia específica conforme a natureza de cada projeto
      - Permite que os desenvolvedores se manifestem quando algo os incomodar
    - - Fragmenta os projetos de gestão e de software em features (funcionalidades)
      - Planejamento voltado ao método incremental por funcionalidade
        
        Exemplo
        
        primeiro item a ser feito é a área do cliente completa
        
        segundo item será o carrinho de compras
        completo
        
        terceiro item será o catálogo completo, etc.
      - Criar um design que simplifica a navegação e promove a experiência do usuário
      - Elaboração de lista de tarefas de funcionalidades onde cada passo tem foco em alguma funcionalidade do software
      - Testar cada função em detrimento de testar uma interface
    - - Usado em situações onde o tempo e a verba são limitados
      - Este método busca entregar pelo menos 80% do projeto em até 20% do tempo disponibilizado
        
        Fases
        
        Pré-projeto
        
        Elabora orçamento
        
        Desenho do projeto
        
        Escolha do projeto
        
        Assinatura do contrato
        
        Ciclo de Vida
        
        Criação de protótipos de modelos incrementais
        
        Implementação
        
        Analisa a viabilidade
        
        Pós-projeto
        
        Ocorrem as alterações
        
        Correção de problemas
        
        Manutenção
        
        Gestão de risco
      - A DSDM é recomendada
        
        quando os projetos são formados
        por uma nova tecnologia e precisam ser acompanhados de testes do usuário
        
        remetem a um lançamento de produto com data marcada
        
        quando os projetos são urgentes
      - a DSDM tem cronograma
        e orçamento fechados, mas o roteiro é aberto
    - - metodologia possui algumas práticas
        
        Equipe inteira
        
        as reuniões devem ser em pé e devem ser rápidas
        
        Programação em par
        
        um desenvolvedor mais experiente fica com um novato, o novato
        codifica e o mais experiente programa. O benefício deste método é que ele é revisado por duas pessoas
        
        Ritmo sustentável
        
        as equipes devem trabalhar 40 horas, divididas em 8 horas por dia, sem sobrecarga
        
        Padronizações de código
        
        a equipe de dev (developers) determina regras de codificação
        de salvamento, bem como as boas práticas que devem ser seguidas. Assim, parecerá que foi a mesma pessoa que editou o código, ele ficará com uma “cara” única
        
        Teste de usuário
        
        em equipes pequenas são realizados testes do software por clientes e desenvolvedores da empresa para avaliar sua qualidade
        
        Desenvolvimento orientado a teste
        
        elaborar códigos de forma que sejam capazes de ser
        testados por software de teste como Imeter (um software que mede desempenho), Selenium (um software que mede erros de sites)
        
        Propriedade coletiva
        
        qualquer pessoa do time pode usar o código do programa sem
        precisar de permissão para alterar, assim todos têm a oportunidade de conhecer o código inteiro e se familiarizar com ele, importante para agilizar manutenções
        
        Refatoração
        
        processo de otimizar a estrutura do código sem alterar o seu
        comportamento externo para o usuário final
        
        Jogos de planejamento
        
        no início da semana os clientes e developers (desenvolvedores)
        se reúnem parar priorizar funcionalidades que serão entregues no final da semana. Cada versão deve ser pequena
        
        Integração contínua
        
        integrar alterações de forma contínua, sem esperar uma semana,
        por exemplo. Permite saber a real situação do software da programação
        
        Entregas curtas
        
        entregar pequenos pedaços para o cliente corrigir e avaliar, aumentando a probabilidade de acertar o todo
        
        Metáfora
        
        entender a linguagem e as expressões do cliente
        
        Design simples
        
        o código deve ter exatamente o que o cliente pediu
      - Criado em 1996 possui como princípios básicos
        
        Qualidade
        
        Mudanças incrementais
        
        feedback rápido/Mudanças
    - - faz a construção do sistema por etapas, de incremento
        em incremento
      - Geralmente, concluindo uma etapa e após o cliente dar alguns feedbacks
      - Cada etapa é uma parte inteira
    - - Criado por Schwaber e Sutherland
        
        Scrum é um método para organização de equipes
        
        grupo de pessoas se organiza para desenvolver soluções para problemas complexos gerando
        produtos com alto valor para as organizações
        
        Os princípios oferecem condições de aplicar um processo de desenvolvimento que envolva
        
        análise
        
        projeto
        
        requisitos
        
        evolução
        
        entrega
      - Principais atividades
        
        aptidão da equipe para obter êxito com o Scrum
        
        promoção do Scrum por meio de compartilhamento de boas práticas para reconhecer o sucesso da aplicação do método
        
        desejo de adotar o Scrum como meio de resolver os problemas atuais
        
        transferência das implicações do uso de Scrum para toda a empresa
        
        reconhecimento que o processo atual não está mais permitindo a entrega dos resultados esperados
      - Sprint
        
        intervalo de tempo no qual um conjunto de atividades deve ser
        executado
        
        Início
        
        Sprint Planning Meeting
        
        reunião de planejamento na qual o cliente prioriza os itens do Product Backlog
        
        Product Backlog
        
        Lista das funcionalidades a serem implementadas em um projeto
        
        As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog
        
        A cada dia de uma Sprint a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum
        
        objetivo é aprimorar conhecimento sobre o que foi feito no dia
        anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia
        
        Ao final de um Sprint a equipe apresenta as funcionalidades implementadas em uma
        reunião
        
        Finalmente faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo
      - Backlog do produto
        
        é composto por todas as necessidades de desenvolvimento do
        produto através da visão do cliente
        
        é um documento vivo e nunca estará
        completo
        
        Project Owner (PO) interagirá constantemente com as partes interessadas do
        produto a fim de manter este backlog priorizado, atualizado e evoluindo
      - Backlog da Sprint
        
        é o conjunto de itens do backlog do produto selecionados para serem desenvolvidos durante a Sprint
        
        somente o time de desenvolvimento tem autonomia para
        alterar os itens de backlog durante uma Sprint
      - Quadro Kanban
        
        ferramenta de gestão visual que representa a característica de transparência do Scrum
        
        através de um quadro de tarefas, que pode ser físico ou digital, a equipe visualiza os itens a serem desenvolvidos e seu andamento
        
        a divisão das colunas do quadro geralmente é entre
        “Backlog”, “A fazer”, “Fazendo” e “Pronto”
      - Definição de pronto
        
        para um determinado membro do time
        a definição de pronto pode significar que o item foi acoplado ao código fonte sem causar
        erros
        
        na visão de um testador pode significar “sem bugs”
- - - - formas de executar tal ação
        
        Cenários
        
        Casos de uso
        
        Entrevistas
        
        Etnografia
        
        Requisitos funcionais e não funcionais
        
        Requisitos funcionais
        
        Requisitos não funcionais
        
        Requisitos no Ciclo de Vida do Projeto
        
        Identificação das regras de negócio
- - - - analisar questões que serão usadas
        
        arquitetura do sistema
        
        linguagens de programação
        
        banco de dados
        
        interface gráfica e outros elementos
        
        gerar uma descrição computacional do que o
        software irá fazer
        
        projeto da arquitetura (também chamado
        de projeto de alto nível)
        
        projeto detalhado (também chamado de projeto de baixo nível)
      - quatro atividades
        que podem ou não fazer parte do processo de projeto de sistemas de informação
        
        Projeto de interface
        
        Projeto de componente
        
        Projeto de arquitetura
        
        Projeto de banco de dados
      - Diagramas
        
        ilustra de forma gráfica como será o funcionamento do software, sua execução, atuação do sistema no dia a dia do negócio
        
        Diagrama de atividades
        
        permite ao destinatário ter uma visão mais positiva daquilo que está solicitando à equipe de desenvolvimento
        
        permite visualizar detalhadamente os fluxos do sistema no que diz respeito às ações que
        podem ser feitas e aos caminhos percorridos na utilização deste sistema
        
        elementos básicos
        
        atividades e transições
        
        decisões
        
        estados iniciais e finais
        
        união
        
        bifurcação
        
        raias
        
        principais objetivos são de documentar os aspectos funcionais do programa, demonstrar
        aspectos específicos de alguma rotina explicitar questões relacionadas aos requisitos
        funcionais e explicar de forma macro o sistema
        
        Diagrama de interação
        
        ilustrar como os objetos interagem por meio de
        mensagens, usados para modelagem de objetos dinâmica
        
        tipos comuns
        de diagramas de interação
        
        diagramas de sequência
        
        pontos fracos
        
        1 more item...
        
        pontos fortes
        
        1 more item...
        
        diagramas de comunicação
        
        pontos fortes
        
        1 more item...
        
        pontos fracos
        
        1 more item...
        
        Diagrama de Estado
        
        faz parte
        de uma modelagem dirigida a eventos
        
        mostra os estados, o sistema e os
        eventos que causam transições de um estado para outro
        
        não mostram o fluxo de dados
        dentro do sistema
        
        podem incluir informações adicionais sobre os processamentos
        realizados em cada estado
        
        Principais
        aplicações
        
        Descrever objetos orientados a eventos em um sistema reativo
        
        Ilustrar cenários de caso de uso em um contexto de negócios
        
        Descrever como um objeto se move por vários estados em seu tempo vida
        
        Mostrar o comportamento geral de uma máquina de estados ou o comportamento de um conjunto relacionado de máquinas de estados
        
        Diagrama de casos de uso
        
        descreve a funcionalidade proposta para um novo sistema que
        será projetado, excelente ferramenta para o levantamento dos requisitos funcionais do sistema
        
        Elementos que fazem parte do Diagrama
        
        ator
        
        cenário
        
        tipos de relacionamento
        
        generalização
        
        dependência
        
        associação
- - - - centralizado
        
        trabalha apenas com um servidor e diversas áreas de trabalho, baseados na arquitetura cliente-servidor
      - distribuído
        
        recomendado para equipes com muitos desenvolvedores e que se encontram em diferentes locais
    - - pull: com esta operação é possível pegar a versão de outra área de trabalho e mesclar
        com a sua
      - push: com esta operação temos o processo inverso do pull, ou seja, enviando para outra área a sua versão do projeto