Engenharia de Software

Começar. É Gratuito
ou inscrever-se com seu endereço de e-mail
Engenharia de Software por Mind Map: Engenharia de Software

1. O que é?

1.1. Parte da Engenharia de Sistemas que se ocupa de todos os aspectos da produção de software.

2. Processo

2.1. O que é?

2.1.1. Conjunto de atividades, ações e tarefas realizadas na criação de algum artefato.

2.2. Objetivo

2.2.1. Constituir a base para o gerenciamento de projetos de software e o processo define uma metodologia que deve ser estabelecida para a entrega efetiva de tecnologia de engenharia de software.

3. Método

3.1. O que é?

3.1.1. Abordagem estruturada para o desenvolvimento de software, facilitando a produção de software com qualidade e uma boa relação custo-benefício. Envolvem um amplo conjunto de atividades que incluem: planejamento, análise de requisitos, análise e projeto, implementação e testes.

3.2. Objetivo

3.2.1. Proporcionar os detalhes de “como fazer” para construir o software.

4. Ferramenta

4.1. O que é?

4.1.1. Itens capazes de agir de forma combinada e integrada que realizam o intercâmbio de informações, dados, artefatos e serviços entre si, suportando desde a análise de requisitos até a entrega do produto final.

4.2. Objetivo

4.2.1. Proporcionar apoio automatizado aos métodos de desenvolvimento de software.

5. Engenharia de Requisitos

5.1. O que é?

5.1.1. Caracteriza-se como o processo de descobrir, analisar, documentar e verificar os serviços e restrições.

5.2. Objetivo

5.2.1. Elaborar o quê deve ser feito (compreensão do problema) e não de como fazer, considerando o domínio do sistema.

5.3. Requisitos de Usuário

5.3.1. Declarações em uma linguagem natural com diagramas ou não, de quais serviços o sistema deverá fornecer a seus usuários e as restrições com as quais este deve operar.

5.4. Requisitos de Sistema

5.4.1. Descrições mais detalhadas das funções, serviços e restrições operacionais dos sistema de software. O documento de requisito do sistema (especificação funcional) deve definir exatamente o que deve ser implementado

5.5. Requisitos Funcionais

5.5.1. Requisitos diretamente ligados as funcionalidades e serviços do software. Caracterizam-se como declarações de serviços que o sistema deve fornecer, de como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em determinadas situações.

5.6. Requisitos Não Funcionais

5.6.1. Requisitos que expressam restrições que o software deve atender ou qualidades específicas que o software deve ter, ou seja, restrições técnicas, de modo a refletir restrições aos serviços ou funções oferecidas pelo sistema. Incluem restrições de tempo, restrições no processo de desenvolvimento e restrições impostas pelas normas. Ao contrário das características individuais ou serviços do sistema, os requisitos não funcionais, muitas vezes, aplicam-se ao sistema com o um todo

5.7. Processo de Engenharia de Requisto

5.7.1. A Engenharia de Requisitos estabelece o processo de definição de requisitos como um processo no qual o que deve ser feito deve ser elicitado, modelado e analisado. Este processo deve lidar com diferentes pontos de vista, e usar uma combinação de métodos, ferramentas e pessoal. O produto desse processo é um modelo, do qual um documento chamado requisitos é produzido.

5.7.2. Estudo de Viabilidade

5.7.2.1. Atividade que realiza-se o estudo da viabilidade do projeto, a partir do ponto de vista de negócio e orçamento. O resultado deve informar a decisão de avançar ou não, com uma análise mais detalhada.

5.7.3. Elicitação e Análise de Requisitos

5.7.3.1. Atividade que realiza-se o a identificação dos requisitos do sistema, a analise de tarefas etc, envolvendo o desenvolvimento de um ou mais modelos de sistemas e protótipos, para auxiliar na compreensão do sistema a ser especificado.

5.7.4. Especificação de Requisitos

5.7.4.1. Atividade que realiza-se a tradução das informações obtidas durante a atividade de análise em um documento que defina um conjunto de Requisitos de Usuário e dos Requisitos de Sistema.

5.7.5. Validação de Requisitos

5.7.5.1. Atividade que verifica-se os requisitos quanto a realismo, consistência e completude. Uma vez identificado erros no documento de requisitos, o documento deve ser modificado para correção dos problemas.

5.8. Diagrama de Use Cases

5.8.1. Representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com ele, as quais representam os requisitos funcionais do sistema. Essa técnica de modelagem da Unified Modeling Language (UML) demonstra um conjunto de Use Cases, Atores e seus relacionamentos.

5.8.2. Ator

5.8.2.1. Qualquer elemento externo ao sistema que interage com o mesmo.

5.8.3. Use Case

5.8.3.1. Representa uma funcionalidade do sistema, sem revelar a estrutura e o comportamento interno desse sistema.

5.8.4. Associação

5.8.4.1. É um tipo de relacionamento entre os Atores e os Use Cases ou entre os Use Cases e outros Use Cases.

5.9. Diagrama de Atividades

5.9.1. Pode representar o funcionamento de um software, um processo de negócios ou uma funcionalidade do software como um fluxo de trabalho por meio de um conjunto de ações.

5.9.2. Atividade

5.9.2.1. Representa um fluxo de trabalho que é representado no Diagrama de Atividade. Uma Atividade é composta por um conjunto de ações, ou seja, os passos necessários para que a atividade seja concluída.

6. Metodologia

6.1. Codificação de um conjunto de práticas recomendadas, às vezes acompanhada de material de treinamento, programas de educação formal, Planilhas, Diagramas.