GERENCIAMENTO DE PROJETOS

Prévia do material em texto

GERENCIAMENTO DE PROJETOS
resposta
Gerenciamento ágil de projetos
1. No início do novo milênio, os métodos de gerenciamento de projetos conhecidos como “tamanho _______” eram percebidos como ___________ para abarcar as necessidades e os objetivos dos novos produtos e serviços que estavam sendo propostos naquela época, levando a(o) ___________ dos chamados métodos __________.
Assinale a alternativa que completa adequadamente as lacunas.​​​
Resposta correta
C. único; insuficientes; surgimento; ágeis.
Por que esta resposta é a correta?
No início do novo milênio, os métodos de gerenciamento de projetos conhecidos como “tamanho único” ou tradicional eram percebidos como insuficientes para abarcar as necessidades e os objetivos dos novos produtos e serviços que estavam sendo propostos naquela época, levando ao surgimento dos chamados métodos ágeis.
2. Gerenciamento tradicional e ágil são dois métodos de gestão de projetos que se diferenciam entre si. Ambos estão certos e ao mesmo tempo não estão tendo em vista que o ambiente de projetos possui uma complexidade ampla, que vai muito além de um modelo padrão de gerenciamento.
Avaliando características marcantes de cada um desses dois métodos, é verdadeiro afirmar que:​​​​​​​
Você acertou!
E. a metodologia de planejamento e programação de projetos em ondas é uma característica do gerenciamento ágil.
Por que esta resposta é a correta?
O gerenciamento de projeto tradicional preconiza um alto grau de detalhamento e previsibilidade. Tem como centro o planejamento completo do projeto, do início ao fim, e utiliza uma lógica de planejar, executar e corrigir eventuais desvios, fazendo com que se encontre em uma zona previsível e permitindo que a maioria dos riscos seja identificada antes mesmo de o projeto ter início. Já o gerenciamento ágil vive em uma zona de imprevisibilidade, adotando uma abordagem mais experimental e adaptativa. Assim, o projeto evolui ao longo do seu desenvolvimento, estando relacionado com a metodologia de planejamento e programação de projetos em ondas. Portanto, o desenho final do projeto não é conhecido em grande detalhamento, mas sim construído por meio de interações incrementais ao longo do tempo.
3. Ao compararmos os métodos de gerenciamento de projetos tradicional e ágil, é possível elencarmos características e objetivos que os distinguem.
Assinale a alternativa que demonstra de forma correta a diferença entre os métodos tradicional e ágil, comparando uma mesma característica em ambos os modelos.​​​​​​​
Você acertou!
A. Desenho do projeto: no tradicional é definido no início do projeto, enquanto no ágil é definido ao longo do seu desenvolvimento.
Por que esta resposta é a correta?
Gerenciamento tradicional: desenho no início, escopo fixo, entregas, congela o desenho assim que possível, baixa incerteza.
Gerenciamento ágil: desenho contínuo, escopo flexível, atributos/requisitos, congela o desenho o mais tarde possível, alta incerteza.
4. O desenvolvimento interativo e evolutivo é um atributo marcante do gerenciamento ágil, que faz com que o projeto apresente determinadas características e gere resultados peculiares.
Sobre os resultados alcançados com o desenvolvimento interativo e evolutivo, é correto afirmar que:
Você acertou!
D. aumenta a probabilidade de que o produto final satisfaça as necessidades dos clientes.
Por que esta resposta é a correta?
O desenvolvimento interativo e evolutivo é mais efetivo que o gerenciamento tradicional quando se trata de criar um novo produto. Isso porque traz inúmeras vantagens ao projeto, como: integração, verificação e validação contínuas do produto em evolução; demonstração frequentemente da evolução, aumentando a probabilidade de que o produto final satisfaça as necessidades dos clientes; detecção de defeitos e problemas assim que ocorrem. 
5. O gerenciamento ágil pode ser compreendido como uma metodologia composta por vários métodos que auxiliam na construção de sua proposta de gestão, como: Scrum, extreme programming (XP), gerenciamento ágil, lean development, rational unified process (RUP), Crystal Clear, dynamic systems development method (DSDM) e rapid product development (RDP). Cada método possui aplicações únicas, mas a maioria se baseia em princípios de gerenciamento ágil.
Qual das alternativas abaixo apresenta de forma correta um desses princípios?​​​​​​​
Você acertou!
E. Melhoria contínua: as equipes refletem, aprendem e se adaptam às necessidades que vão surgindo ao longo do projeto.
Por que esta resposta é a correta?
Os métodos integrantes do gerenciamento ágil estão baseados em princípios como: 
a) foco no valor do cliente: prioriza os requisitos e atributos que são guiados para o negócio;
b) entrega interativa e incremental: cria um fluxo de valor que é destinado ao cliente no momento em que compartimentaliza as entregas do projeto em pequenos incrementos funcionais;
c) experimentação e adaptação: inicia-se com testes de pressupostos, criando protótipos funcionais para solicitar feedback ao cliente, o que possibilita reafirmar e melhorar os requisitos do produto;
d) auto-organização: decisão mais efetiva, pois organiza os membros da equipe descrevendo quem fará o quê; 
e) melhoria contínua: as equipes refletem, aprendem e se adaptam às necessidades que vão surgindo ao longo do projeto.
Métricas para gerenciamento de projetos e código-fonte
1. Assinale a alternativa que corresponde à técnica mais comum para a estimativa de projeto.
Você acertou!
C. Estimativa baseada em processo.
Por que esta resposta é a correta?
Muitas são as técnicas para fazer estimativas de projeto, mas a mais comum entre elas é a estimativa baseada em processo.
2. Sobre o escopo do projeto, é correto afirmar que:
Você acertou!
A. é o que será feito no projeto.
Por que esta resposta é a correta?
O escopo descreve o que será feito no projeto, ou seja, é a descrição detalhada dos produtos e serviços a serem gerados para atender aos objetivos do projeto.
3. Assinale a alternativa que corresponde às entradas para o planejamento do escopo.
Você acertou!
D. A descrição do produto, as premissas e as restrições. 
Por que esta resposta é a correta?
Para fazer o planejamento do escopo, algumas entradas são necessárias. A descrição do produto, as premissas e as restrições são exemplos de entradas para o planejamento.
4. Segundo Sommerville, métricas de software:
Você acertou!
A. medem a produtividade da equipe e indica a qualidade do produto.
Por que esta resposta é a correta?
As métricas de software fazem medições de produtividade da equipe e indicam, entre outras coisas, a qualidade do produto.
5. Assinale a alternativa que corresponde às ferramentas para gerenciamento de projetos.
Você acertou!
A. Trello, MS Project e JDepend.
Por que esta resposta é a correta?
O uso de ferramentas para o gerenciamento de projeto é essencial para auxiliar na sua gestão. Existem ferramentas específicas para esse gerenciamento, como, por exemplo: Trello, MS Project e JDepend.
Técnicas para estimativa de tamanho
1. 
Em gerenciamento de projetos, fazer estimativas é uma prática constante. As técnicas para estimar custo, esforço e prazo são utilizadas pelos gestores de projetos com frequência. Baseado nesse conceito, assinale a alternativa que corresponde à relação da medição e e estimativa de software em pontos de função.
Você acertou!
D. 
Medição e estimativa de software em pontos de função têm como um de seus objetivos medir a funcionalidade solicitada pelo usuário, antes do projeto de software, de forma a estimar seu tamanho e seu custo.
Por que esta resposta é a correta?
Assinale a alternativa que corresponde ao objetivo principal da Análise de Pontos de Função:
Você acertou!
D. 
Medir a funcionalidade de um software ou aplicativo.
Por que esta resposta é a correta?
O objetivo principal da Análise de Pontos de Função é medir o software para verificar o que foi requisitado e o que foi entregue ao cliente. Portanto, seu objetivo principal é medir a funcionalidade de um software.
3. 
A técnica UCP (Use Case Points) estima otamanho do software em pontos de caso de uso e esforço. Sobre a UCP, assinale a resposta correta:​​​​​​​
Resposta correta
A. 
Para utilizar a referida métrica, é necessário que a organização tenha um único padrão e estilo para escrever casos de uso.
Por que esta resposta é a correta?
Para conseguir resultados iguais, é necessário ter um único padrão e estilo para escrever casos de uso. O contrário disso levará a resultados diferentes. Esse item envolve quantidade de atores, complexidade técnica e ambiental.
4. 
O Constructive Cost Model (COCOMO) é um modelo utilizado para estimar projetos de software. Analise as opções a seguir e assinale a que corresponde ao modelo intermediário do COCOMO.
Você acertou!
E. 
Práticas de programação modernas, tamanho da base de dados e nível de aptidão dos programadores.
Por que esta resposta é a correta?
O modelo COCOMO utiliza práticas modernas, leva em consideração o tamanho da base de dados e o nível de aptidão da equipe. Desconsidera fatores de SE e EE.
5. 
COCOMO é uma técnica para estimar software, a qual  permite calcular, a partir de estimativas de tamanho deste, valores para:​​​​​​​
Você acertou!
E. 
esforço e tempo de desenvolvimento.
Por que esta resposta é a correta?
COCOMO utiliza estimativas de tamanho de software para calcular estimativas de esforço, tempo de desenvolvimento e custo.
Software Engineering Body of
1. 
O SWEBOK apresenta a engenharia de software como um conjunto de áreas de conhecimento necessários para se trabalhar com desenvolvimento de software, desde a codificação em si até a gestão de projetos. Dentre essas áreas, há uma delas que aponta o gerenciamento e a mensuração da engenharia de software, outra que é composta pela verificação dinâmica de uma seleção de domínios de execuções, normalmente infinito, contra o comportamento esperado e, além destas, uma área que aborda considerações relativas à qualidade de software, que vão além dos processos de ciclo de vida dele.
Analise as opções abaixo e assinale as que correspondem às três áreas citadas.
Você acertou!
A. 
Gerência de engenharia de software, teste de software, qualidade de software.
Por que esta resposta é a correta?
As áreas de conhecimento (KAs) são divididas para melhor entendimento e abrangência da engenharia de software. Cada área, com sua particularidade, visa a nortear o desenvolvimento com melhores práticas e qualidade, dentro de padrões esperados. Dentre essas áreas, podem ser citadas as seguintes: Gerência de engenharia de software, que norteia o gerenciamento e a mensuração da engenharia de software; teste de software, que é composta pela verificação dinâmica de uma seleção de domínios de execuções normalmente infinito, contra o comportamento esperado; e qualidade de software, que aborda considerações relativas à qualidade dele, para além dos processos de ciclo de vida.
2. 
A engenharia de software é uma área do conhecimento da computação voltada para especificação, desenvolvimento e manutenção de sistemas de software, aplicando tecnologias e práticas de gerência de projetos e outras disciplinas, objetivando organização, produtividade e qualidade.
Visando esses objetivos, a IEEE desenvolveu o SWEBOK, que é um guia de referência organizado e que contém um conjunto de conhecimentos que foram divididos em áreas e subáreas.
Baseado nesse contexto, analise as alternativas abaixo e assinale a que representa a quantidade de áreas do guia SWEBOK, 2014.
Você acertou!
E. 
15 áreas
Por que esta resposta é a correta?
 O SWEBOK foi pensado para estabelecer conjuntos de critérios e normas adequadas para a prática profissional da engenharia de software, nos quais decisões industriais, certificações profissionais e currículos educacionais pudessem se basear. Para isso, ele foi dividido em 15 áreas de conhecimento, conhecidas também como KAs (Knowledge Areas): Requisitos de Software, Design de Software, Construção de Software, Teste de Software, Manutenção de Software, Gerência de configuração de Software, Gerência de Engenharia de Software, Processo de Engenharia de Software, Modelos e Métodos de Engenharia de Software, Qualidade de Software, Prática em Engenharia de Software Profissional, Economia em Engenharia de Software, Fundamentos da Computação, Fundamentos Matemáticos, Fundamentos da Engenharia.
3. 
Qualidade de software aborda considerações relativas à qualidade que vão além dos processos de ciclo de vida dele. Uma vez que a qualidade de software é um assunto presente em todas as partes na engenharia de software, também é considerada em muitas outras áreas de conhecimento. A área do conhecimento Qualidade de Software, do SWEBOK, está dividida em tópicos. São eles:
a. Fundamentos de qualidade de software.
b. Métricas de desempenho.
c. Gerência do processo de qualidade de software.
d. Considerações práticas. 
Analise as opções a seguir e assinale a que corresponde aos tópicos da área de qualidade de software.
Você acertou!
D. 
Estão corretas as alternativas a, c e d.
Por que esta resposta é a correta?
A área da qualidade de software é composta por um conjunto de atividades relacionadas à garantia de qualidade dele. Entre elas, estão as de verificação e de validação. Aqui, tratamos de fundamentos de qualidade de software, gerência do processo de qualidade e considerações práticas.
4. 
Dentre as áreas de conhecimento do SWEBOK, temos a área chamada processo de engenharia de software. Nela, o foco está nas atividades técnicas e gerenciais dentro do processo. Baseando-se nesta afirmativa, analise as opções abaixo e assinale as que correspondam aos focos da área de processo de engenharia de software:
Você acertou!
A. 
definição do processo, ciclo de vida, avaliação e melhoria do processo, métricas e ferramentas.
Por que esta resposta é a correta?
Como foco, a área de processo de engenharia de software sugere modelos que ajudam na definição do processo de software, ciclo de vida do software, avaliação e melhoria do processo de software, métricas de software e ferramentas para o processo de engenharia de software.
Exercícios
Respostas enviadas em: 18/06/2021 10:03
5. 
O guia SWEBOK nasceu com o propósito de descrever um corpo de conhecimento não engessado para nortear as atividades de desenvolvimento de software.
Para compor o guia, foram pensados objetivos principais. Analise as opções a seguir e assinale o objetivo que foi construído e apoiado por diversos profissionais da área e de vários países.
Você acertou!
A. 
Promover uma visão consistente da engenharia de software no âmbito mundial.
Por que esta resposta é a correta?
Um dos objetivos do SWEBOK contou com a ajuda de profissionais de vários países que se uniram para estabelecer um conjunto apropriado de critérios e normas para a prática profissional da engenharia de software, por meio de uma visão consistente dela em âmbito mundial.
Técnicas para estimativa de tamanho e de custo Objetivos de aprendizagem Ao final deste texto, você deve apresentar os seguintes aprendizados: Classificar as técnicas de estimativas function points analysis (FPA), use case points (UCP) e constructive cost model (COCOMO). Identificar as diferenças entre as técnicas (FPA, UCP e COCOMO). Avaliar as técnicas de estimativas (FPA, UCP e COCOMO). Introdução Neste capítulo, você vai estudar sobre técnicas para estimativa de tamanho e de custo. Para o sucesso de um projeto de desenvolvimento de software, trabalhar com estimativas é essencial. Quando falamos em sucesso, o esperado é que o produto, além de atender às necessidades do usuário, seja desenvolvido dentro do tempo estimado e de acordo com o orçamento planejado. Com as estimativas, podemos calcular: esforço de desenvolvimento de software, custo de software, taxa de produção de software, taxa de manutenção de software e nível de produtividade da equipe. Continue lendo o capítulo e aprenda sobre as técnicas de estimativas de tamanho e de custo de um projeto de software. As técnicas para estimativas Fazer estimativas não é uma tarefa simples. Fazer estimativas requer esforçoe talvez você tenha que fazer uma estimativa inicial com base em uma defi nição de requisitos de usuário de mais alto nível. Alguns desafios, tais como precisar usar novas tecnologias, desconhecimento das habilidades das pessoas envolvidas no projeto, entre outros, dificultam estimar custos de desenvolvimento precisamente no início de um projeto. A estimativa de custo de projeto é autossuficiente e é usada para definir o orçamento do projeto e o produto é ajustado para cumprir o planejado. Para auxiliar nas estimativas, existem algumas técnicas que podem ser usadas. Todas elas contam com o conhecimento explícito dos gestores de projetos que usam os projetos anteriores para chegar a uma estimativa de recursos necessários para o desenvolvimento do projeto atual. Porém, diferenças significativas podem acontecer entre projetos passados e futuros, podendo afetar as estimativas. Para auxiliar nas estimativas, existem algumas técnicas. Dentre elas, podemos citar: FPA, UCP e COCOMO. A técnica FPA Segundo Summerville, a técnica FPA dimensiona uma aplicação na perspectiva do usuário fi nal, ao invés de levar em consideração as características técnicas da linguagem utilizada. Na visão do usuário, essa aplicação nada mais é do que um conjunto de funções do negócio que o auxiliam na realização de suas tarefas. A análise dessa função é feita sob a ótica do que será fornecido, e não de como é fornecido ou “como” é abstraído, assim fica mais fácil para o usuário entender o que será entregue. Na técnica de análise de pontos de função (FP), somente componentes visíveis ao usuário são considerados para o dimensionamento. Essa técnica considera a funcionalidade geral que a aplicação proporciona ao usuário. A FPA tem como objetivo medir o que o software faz e, dessa forma, determinar o seu tamanho. A partir daí as estimativas de esforço, produtividade e custo são calculadas ajudando a: prover uma métrica de medição para apoiar a análise de produtividade e da qualidade. prover uma forma de estimar o tamanho do software. prover um fator de normalização para comparação de software. As premissas do FPA são: entradas externas (EE). saídas externas (SE). arquivos lógicos internos (ALI). arquivos de interface externa (AIE). consulta externa (CE). 2 Técnicas para estimativa de tamanho e de custo Após levantar as funcionalidades do software, um valor numérico é atribuído a cada uma delas de acordo com a complexidade. Veja os Quadros 1 a 5. Fonte: Adaptado de Paula Filho (2008). Campos (TD) Arquivos (AR) 1 a 4 itens de dados referenciados 5 a 15 itens de dados referenciados 16 ou mais itens de dados referenciados 0 ou 1 tipo de arquivo referenciado Simples Simples Médio 2 tipos de arquivos referenciados Simples Médio Complexo 3 ou mais tipos de arquivos referenciados Médio Complexo Complexo Quadro 1. Complexidade das EEs Fonte: Adaptado de Paula Filho (2008). Campos (TD) Arquivos (AR) 1 a 5 itens de dados referenciados 6 a 19 itens de dados referenciados 20 ou mais itens de dados referenciados 0 ou 1 tipo de arquivo referenciado Simples Simples Médio 2 ou 3 tipos de arquivos referenciados Simples Médio Complexo 4 ou mais tipos de arquivos referenciados Médio Complexo Complexo Quadro 2. Complexidade das saídas externas (SE) Técnicas para estimativa de tamanho e de custo 3 Fonte: Adaptado de Paula Filho (2008). Campos (TD) Registros (TR) 1 a 19 itens de dados referenciados 20 a 50 itens de dados referenciados 51 ou mais itens de dados referenciados 1 tipo de registro lógico Simples Simples Médio 2 a 5 tipos de registros lógicos Simples Médio Complexo 6 ou mais tipos de registros lógicos Médio Complexo Complexo Quadro 3. Complexidade dos arquivos lógicos internos (ALI) Fonte: Adaptado de Paula Filho (2008). Campos (TD) Registros (TR) 1 a 19 itens de dados referenciados 20 a 50 itens de dados referenciados 51 ou mais itens de dados referenciados 1 tipo de registro lógico Simples Simples Médio 2 a 5 tipos de registros lógicos Simples Médio Complexo 6 ou mais tipos de registros lógicos Médio Complexo Complexo Quadro 4. Complexidade de arquivos de interface externa (AIE) 4 Técnicas para estimativa de tamanho e de custo Fonte: Adaptado de Paula Filho (2008). Campos (TD) Arquivos (AR) 1 a 5 itens de dados referenciados 6 a 19 itens de dados referenciados 20 ou mais itens de dados referenciados 0 ou 1 tipo de arquivo referenciado Simples Simples Médio 2 ou 3 tipos de arquivos referenciados Simples Médio Complexo 4 ou mais tipos de arquivos referenciados Médio Complexo Complexo Quadro 5. Complexidade dos consulta externa (CE) Após levantar o número de ocorrências, aplica-se o peso de acordo com a complexidade para se chegar ao resultado. Um exemplo é apresentado na Figura 1. Figura 1. Exemplo de tabela para cálculo de pontos. Fonte: Paula Filho (2008). Função Entrada externa Simples Médio Complexo Simples Médio Complexo Total 1 Total 2 Simples Médio Complexo × 3 = × 4 = × 6 = = × 4 = × 5 = × 7 = = × 3 = × 4 = × 6 = = × 5 = × 7 = × 10 = = × 7 = × 10 = × 15 = = Total 5 Simples Médio Complexo Total 3 Simples Médio Complexo Total 4 Saída externa Arquivos lógicos internos Arquivo interface externo Consultas Nº de ocorrências Complexidade Peso Resultado Técnicas para estimativa de tamanho e de custo 5 Esta técnica serve para diversos propósitos para o desenvolvimento de software, pois ajuda a minimizar a subjetividade nas estimativas por meio da padronização de critérios, de acordo com os Quadros 1 a 5 anteriores. Veja a Figura 2 a seguir. Figura 2. Passos da contagem por FP. Fonte: Adaptada de Ribeiro (2013, documento on-line). Determinar tipo de contagem Identicar a fronteira da aplicação Contar funções tipo dados Contar funções tipo transação Calcular número de pontos de função ajustados Calcular pontos de função não ajustados Calcular valor do fator de ajuste A técnica UCP A técnica “pontos por caso de uso” foi baseada na análise de FP. Essa técnica estima o tamanho de um software baseado no modo como os usuários utilizarão o sistema; pela complexidade das ações que são requeridas por cada usuário e pela análise do workfl ow da realização das tarefas. Essa técnica estima o tamanho do software na fase de levantamento de casos de uso. Para isso, utiliza os próprios documentos gerados nessa fase para subsidiar o cálculo dimensional. Tem como objetivo medir software orientado a objeto e tem sua utilização mais simplificada que a UCP. A UCP, a exemplo da FPA, também utiliza tabelas de classificação de complexidade, conforme mostram a seguir os Quadros 6 e 7. 6 Técnicas para estimativa de tamanho e de custo Fonte: Adaptado de Paula Filho (2008). Complexidade Definição Peso Simples Quando o ator representa um sistema externo que é acessado por meio de API. 1 Médio Quando o ator representa um sistema externo, acessado por meio de um protocolo de comunicação, por exemplo TCP/IP. 2 Complexo Quando o ator interage com o sistema por meio de uma interface gráfica GUI. 3 Quadro 6. Classificação dos atores envolvidos Fonte: Adaptado de Paula Filho (2008). Complexidade Definição Peso Simples Quando o caso de uso tem três ou menos transações, incluindo cenários alternativos, e sua realização deve acontecer com menos de cinco objetivos (classes de análise). 5 Médio Quando o caso de uso tem de 4 a 7 transações, incluindo cenários alternativos, e sua realização deve acontecer com 5 a 10 objetivos (classes de análise). 10 Complexo Quando o caso de uso tem mais de sete transações, incluindo cenários alternativos, e sua realização deve acontecer com mais de 10 objetivos (classes de análise). 15 Quadro 7. Classificação dos casos de uso Técnicas para estimativa de tamanho e de custo 7 Métricas A primeira métrica a ser gerada é a unajusted use case point (UUCP) ou pontos de casos de uso não ajustado, onde: UCCP = total dos pesos dos atores relacionados + total de pesos dos casos de uso relacionados. A segunda métrica a ser gerada é o technical complexity factor (TCF) ou fator de complexidade. Esse fator tem uma escala de 0 a 5, onde o 0 é o menos relevantee o 5 é o mais relevante. Observe o Quadro 8. Fonte: Adaptado de Paula Filho (2008). Código fator Descrição do fator Peso Valor (fator) Resultado F1 Sistema distribuído 2 0 F2 Performance 1 0 F3 Eficiência para o usuário final (on-line) 1 0 F4 Processamento interno complexo 1 0 F5 Código deve ser recusável 1 0 F6 Fácil para instalar 0,5 0 F7 Fácil para usar 0,5 0 F8 Portável 2 0 F9 Fácil para mudar 1 0 F10 Concorrente 1 0 F11 Seguro 1 0 F12 Fornece acesso direto para third parties (sistemas/ componentes externos) 1 0 F13 É requerido treinamento do usuário para usar o software 1 0 Quadro 8. Cálculo de fator 8 Técnicas para estimativa de tamanho e de custo O valor do fator será atribuído pelo gestor de acordo com o estipulado da relevância. Para calcular, utiliza-se a seguinte fórmula: TCF = 0,6 + (0,01 ∙ TFATOR) A terceira métrica gerada é o environmental factor (EF) ou fator ambiente. Esse fator tem uma escala de 0 a 5, onde 0 é o menos relevante e 5 é o mais relevante. Observe o Quadro 9. Fonte: Adaptado de Paula Filho (2008). Código fator Descrição do fator Peso Valor (fator) Resultado F1 Familiaridade com o processo de desenvolvimento orientado a objetos adotado 1,5 0 F2 Colaboradores de meio período -1 0 F3 Capacidade de análise 0,5 0 F4 Experiência em desenvolvimento de aplicações deste gênero 0,5 0 F5 Experiência em orientação a objetos 1 0 F6 Motivação 1 0 F7 Dificuldade na linguagem de programação -1 0 F8 Requisitos estáveis 2 0 Quadro 9. Cálculo de fator O valor do fator também será atribuído pelo gestor de acordo com o estipulado da relevância. Para calcular, utiliza-se a seguinte fórmula: EF = 1,4 + (-0,03 ∙ EFATOR) Técnicas para estimativa de tamanho e de custo 9 Tendo o valor dessas fórmulas, é possível calcular o UCP final, onde: UCP = UUCP ∙ TCF ∙ EF Após encontrar o UCP final, podemos encontrar a estimativa de horas, em que a maioria das literaturas sugerem a aplicação de 20 horas por pontos de caso de uso. Então: estimativa de horas = UCP ∙ 20 Fazendo esses cálculos para os casos de uso, você terá as estimativas necessárias. O UCP e a FPA não consideram apenas o desenvolvimento do software, mas também toda a parte de análise, projeto, teste e treinamento, ou seja, todo o projeto. A técnica COCOMO A técnica COCOMO tornou-se um dos modelos de estimativa de custo de software mais usados. Essa técnica foi criada por meio de coleta de dados com base em um grande número de projetos de software (SOMMERVILLE, 2007). Existem duas versões: COCOMO e COCOMO II. COCOMO é apresentado na forma de um conjunto de modelos divididos em simples, moderados e incorporados (Quadro 10). 10 Técnicas para estimativa de tamanho e de custo Fonte: Adaptado de Sommerville (2007). Complexidade Descrição Simples Aplicações bem compreendidas, desenvolvidas por pequenas equipes. Modelo estatístico que calcula o esforço de desenvolvimento de software e seu custo em função do tamanho de linhas de código desenvolvido. Moderada Projetos mais complexos em que os membros da equipe podem ter experiência limitada com os sistemas relacionados. Modelo que calcula o esforço de desenvolvimento do software em função do tamanho do programa que inclui custo, avaliação subjetiva do produto hardware, pessoas e atributos do projeto. Incorporada Projetos complexos nos quais o software é parte de um conjunto complexo e fortemente acoplado de hardware, software, leis e procedimentos operacionais. Incorpora características da versão intermediária com uma avaliação de impacto de custo em cada passo de todo o projeto. Quadro 10. Modelos COCOMO Modelo COCOMO básico A versão COCOMO considerava que o software seria desenvolvido de acordo com o modelo tradicional cascata, usando linguagem de programação como C e Fortran. Porém, desde a sua proposta inicial, muitas mudanças ocorreram no desenvolvimento de software. Esse modelo evoluiu para um modelo de estimativas mais abrangentes, o COCOMO II, que reconhece abordagens diferentes para o desenvolvimento de software, como a prototipação, o desenvolvimento por composição de componentes e o uso de programação de banco de dados. Veja no Quadro 11 as áreas de que trata. Técnicas para estimativa de tamanho e de custo 11 Fonte: Adaptado de Sommerville (2007). Modelo de composição de aplicação Usado durante os primeiros estágios da engenharia de software, em que o protótipo das interfaces de usuário, a consideração da interação de software e de sistema, a avaliação do desempenho e a avaliação da maturidade da tecnologia são de suma importância. Modelo de estágio do início do projeto Usado quando os requisitos tiverem sido estabilizados e a arquitetura básica de software tiver sido estabelecida. Modelo de estágio pós-arquitetura Usado durante a construção do software. Quadro 11. Modelos do COCOMO básico Veja a seguir as equações COCOMO básicas. E = Ab(KLOC)exp(Bb) - esforço aplicado pessoa-mês D = Cb(E.exp(Db)) - tempo de desenvolvimento (meses cronológicos) P = E/D Onde: E é o esforço aplicado pela pessoa no mês; D é o tempo de desenvolvimento em meses cronológicos; KLOC é o número calculado de linhas de código para o projeto (expressado em milhares); P é o número das pessoas necessário. Os coeficientes ab, bb, cb e db são dados no Quadro 12. 12 Técnicas para estimativa de tamanho e de custo Fonte: Adaptado de Sommerville (2007). Projeto de software ab bb cb db Orgânico 2.4 1.05 2.5 0.38 Semidestacado 3.0 1.12 2.5 0.35 Embutido 3.6 1.20 2.5 0.32 Quadro 12. Coeficientes Modelo COCOMO intermediário É a ampliação do modelo básico ampliado para levar em consideração os atributos direcionadores de custo, tais como: atributos do produto (confiabilidade, tamanho BD e complexidade); atributos do hardware (restrições de desempenho, memória, etc.); atributos de pessoal (experiência); atributos de projeto (uso de case, metodologias, cronograma de atividades, etc.); Total = 15 atributos (pontua-se em uma escala de 0 a 6 pontos, onde 0 é muito baixo e 6 é muito alto). Classificação: determina-se um multiplicador de esforços; calcula-se o fator de ajuste de esforço, em que os valores variam de 0.9 a 1.4. Técnicas para estimativa de tamanho e de custo 13 Veja a seguir as equações COCMO intermediário. E = Ai(LOC). Exp(bi) × FAE (pessoa-mês) Onde: E é o esforço aplicado em pessoas por mês; KLOC é o número de linhas de código (expressado em milhares) para o projeto; EAF é o fator calculado acima. Os coeficientes ai e bi são dados no Quadro 13. Fonte: Adaptado de Sommerville (2007). Projeto de software ai bi Início (orgânico) 3.2 1.05 Meio (semidestacado) 3.0 1.12 Fim (embutido) 2.8 1.5 Quadro 13. Coeficientes Para estimativas utilizando o COCOMO, pode-se usar o software. A base de análise para os FPs são a análise de requisitos e a estimativa. 14 Técnicas para estimativa de tamanho e de custo PAULA FILHO, W. P. Engenharia de software: fundamentos, métodos e padrões. 3. ed. Rio de Janeiro: LTC, 2008. RIBEIRO, G. Métricas de softwares. 2013. Disponível em: . Acesso em: 20 out. 2018. SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson, 2007. Leituras recomendadas PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem profissional. 8. ed. Porto Alegre: Penso, 2016. STEFFEN, J. B. O que são essas tais de metodologias Ágeis? 23 jan. 2012. Dispo
Software Engineering Body of Knowledge (SWEBOK)
Mesmo em assuntos não ligados à tecnologia, cada vez mais se faz necessária a padronização e o uso de métodos e processos para melhorar a qualidade dos projetos. Nesse sentido, a IEEE desenvolveu e mantém o guia SWEBOK com a intenção de divulgar as melhores práticas relacionada à engenharia de software.
O Guia SWEBOK, em sua terceira versão, é composto por quinze áreas do conhecimento que abrangem os principais aspectos relacionados à projetos de engenharia de software. Cada uma dessas áreas foram desenvolvidas por meio de boas práticas coletadas ao longo de décadas e em vários países.
Nesta Unidade de Aprendizagem, você vai conhecer o guia SWEBOK, bem como seus objetivos, áreas de conhecimento e informaçõesrelacionadas às certificações profissionais disponíveis.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
· Descrever o guia SWEBOK e seus objetivos.
· Categorizar as áreas de conhecimento do SWEBOK.
· Explicar as modalidades de certificação do SWEBOK.
Infográfico
Cada vez mais se faz necessária a produção de qualidade e que ela satisfaça os clientes e os padrões de qualidade das organizações. Para isso, a engenharia de software tem evoluído com modelos e processos de desenvolvimento descritos em corpos de conhecimento.
Assim como o SWEBOK é um guia para a engenharia de software, o PMBOK é um importante guia para o gerenciamento de projetos.
Veja um comparativo entre SWEBOK e PMBOK neste Infográfico.
SWEBOK
· Guia com assuntos essenciais na área de engenharia de software.
· É conduzido pelo IEEE.
· Tem como objetivo principal estabelecer um conjunto apropriado de critérios e normas para a pratica profissional da engenharia de software.
· É estruturado em áreas de conhecimento.
· Descreve processos de desenvolvimento e manutenção de software
· É aplicável na área de engenharia de software.
· É pouco utilizado no Brasil.
Cerificado relacionados
- Certificação de Desenvolvedor de software Associado (ASD).
- Certificação para desenvolvedor de software profissional (PSD)
- Mestre Profissional em Engenharia de Software (PSEM)
PMBOK
· Conjunto de praticas de gerência de projetos.
· Conduzido pelo PMI
· Tem como objetivo principal fornecer como visão geral sobre o conjunto de conhecimento em gerenciamento de projetos.
· ÉE estruturado em áreas de conhecimento e grupos de processos
· Descrever processos, ferramentas e técnicas de gerenciamento de projetos.
· É aplicável em várias áreas da organização 
· É muito utilizado no Brasil.
Cerificado relacionados
- Técnico certificado em Gestão de projetos (CAPM)
- Profissional de gestão de Projetos (PMP)
- Profissional de Gestão de Programas (PgMP)
- Profissional de Gestão de Portifólio (PfMP)
- Profissional em analise de negócios do PMI ( PMI-PBA)
- Profissional Agil certificado do PMI (PMI-RMP)
-Profissional de Gestão de Cronograma PMI (PMI-SP)
LIVRO
Software Engineering Body of Knowledge (SWEBOK) Objetivos de aprendizagem Ao final deste texto, você deve apresentar os seguintes aprendizados: � Descrever o guia SWEBOK e seus objetivos. � Categorizar as áreas de conhecimento do SWEBOK. � Explicar as modalidades de certificação sobre o SWEBOK. Introdução Com o aumento da demanda pelo desenvolvimento de software, em decorrência do crescente número de aplicativos disponíveis em dispositivos móveis, surgiu também a necessidade de padronização e métodos para melhorar a qualidade desses software. Nesse sentido, foi elaborado o Software Engineering Body of Knowledge (SWEBOK), um guia de uso e aplicação das melhores práticas de engenharia de software. O SWEBOK foi desenvolvido a partir de boas práticas coletadas ao longo de décadas em vários países. Seu principal objetivo é divulgar um conjunto de práticas, ferramentas e técnicas para o desenvolvimento de atividades de engenharia de software. Assim, neste capítulo, você vai estudar o SWEBOK, compreendendo quais são seus objetivos e suas áreas de conhecimento. Por fim, você vai verificar quais são as modalidades de certificação profissional relacionadas a esse guia. 1 Projeto SWEBOK Segundo Pressman e Maxim (2016), a engenharia de software é uma disciplina que reúne um conjunto de métodos, processos e ferramentas para o desenvolvimento de software, com processos que podem ser utilizados em todo o ciclo de vida de um projeto de software. Nesse contexto, o Instituto de Identificação interna do documento 5UVZ0Q6SJ5-BDUBFU1 Engenheiros Eletricistas e Eletrônicos (IEEE, do inglês Institute of Electrical and Electronics Engineers) é responsável pelo projeto do SWEBOK, que atualmente está em sua terceira versão e é disponibilizado de forma gratuita no website da IEEE Computer Society (BOURQUE; FAIRLEY, 2014). O SWEBOK tem o objetivo de auxiliar as organizações que trabalham com desenvolvimento de sistemas a terem uma visão mais consistente sobre o processo de desenvolvimento de software. O principal objetivo do guia SWEBOK é descrever o conhecimento relacionado à área da engenharia de software. O guia também é conhecido como Relatório Técnico 19759 da Organização Internacional de Normalização (ISO, do inglês International Organization for Standardization) e da Comissão Eletrotécnica Internacional (IEC, do inglês International Electrotechnical Commission). Além disso, segundo a IEEE (c2020, tradução nossa), o guia SWEBOK: � apresenta e descreve as características relacionadas ao conteúdo da engenharia de software; � promove uma visão consistente de como a engenharia de software é vista e utilizada no âmbito mundial; � esclarece e delimita as fronteiras entre a engenharia de software e as outras disciplinas relacionadas (ciência da computação, gerência de projetos, engenharia da computação, matemática, entre outras); � disponibiliza material de apoio para o autoaprendizado e a certificação individual de engenheiros de software. A versão 3 do SWEBOK, lançada em 2014, é composta por 15 áreas de conhecimento, também conhecidas por knowledge areas. São elas: 1. Requisitos de software 2. Design de software 3. Construção de software 4. Teste de software 5. Manutenção de software 6. Gerência de configuração de software 7. Gerência de engenharia de software 8. Processo de engenharia de software 9. Modelos e métodos de engenharia de software 10. Qualidade de software 11. Prática em engenharia de software profissional 2 Software Engineering Body of Knowledge (SWEBOK) Identificação interna do documento 5UVZ0Q6SJ5-BDUBFU1 12.Economia em engenharia de software 13. Fundamentos da computação 14. Fundamentos matemáticos 15. Fundamentos da engenharia A seguir, vamos explicar cada uma das 15 áreas. Aqui olhe 1 Requisitos de software Os requisitos correspondem às necessidades e restrições do produto de software e ajudam nas soluções e nos problemas do mundo real. Nessa área, temos a elicitação, a análise, as especificações e a validação dos requisitos funcionais e não funcionais. Nos projetos de software, na maioria das vezes, as principais falhas ocorrem devido às dificuldades em se entender as necessidades do usuário. Por isso, fazer um bom levantamento de requisitos é extremamente importante. O SWEBOK apresenta alguns pontos relacionados à área de requisitos de software, descritos a seguir. � Fundamentos dos requisitos de software: requisitos são propriedades que devem espelhar o mundo real com o intuito de resolver um problema. Requisitos podem ser de produto ou de processo, funcionais ou não funcionais, e de sistema ou de software. Também podem apresentar propriedades emergentes. Precisam ser, preferencialmente, quantificáveis. � Processo de requisitos: essa área inclui o planejamento de requisitos, mostrando como os processos de requisitos vão integrar-se com os processos de software. Nessa fase, são discutidos os modelos e atores de processo. Também é definido como serão o suporte e o gerenciamento de processos, além dos processos que visam à qualidade e à melhoria de processos. � Elicitação de requisitos: essa área visa a efetuar a captura e a aquisição dos requisitos de software, identificando as fontes dos requisitos. Nessa fase, é importante definir as fontes de requisitos e as técnicas de elicitação. � Análise de requisitos: a análise é a responsável por fazer a ligação entre a alocação de software em nível de sistema e o projeto de software, ajudando o engenheiro a aprimorar e construir modelos. Segundo Pressman e Maxim (2016, p. 122), “[...] se você não analisa, é altamente provável que construa uma solução de software muito elegante que resolve o problema errado”. Nessa fase, são feitas a classificação e a modelagem Software Engineering Body of Knowledge (SWEBOK) 3 Identificação interna do documento 5UVZ0Q6SJ5-BDUBFU1 conceitual de requisitos, o projeto arquiteturale a alocação de requisitos, a negociação de requisitos entre o time de desenvolvimento e o cliente e, por fim, a análise formal. � Especificação de requisitos: compreende a atribuição de valores numéricos para os objetivos do projeto, e a atividade principal dessa área é a documentação do sistema. Nessa fase, é feita a documentação de definição do sistema, a especificação dos requisitos de sistema e a especificação dos requisitos de software. � Validação de requisitos: a documentação levantada na especificação de requisitos pode ser utilizada para a validação da conformidade com os padrões da organização. Essa fase visa a enumerar os problemas encontrados e inclui a revisão de requisitos, a prototipação, a validação de modelos e os testes de aceitação. � Considerações práticas: aqui são descritos tópicos para serem compreendidos na prática e, ao mesmo tempo, para validar os atributos e o tamanho das alterações nos requisitos e fazer a estimativa de custo para o desenvolvimento e a manutenção � Ferramentas para requisitos de software: usualmente suportam diversas atividades, como documentação, rastreamento e gerenciamento da mudança. Há duas principais categorias: ferramentas para modelagem e ferramentas para o gerenciamento de requisitos. 2 Design de software A área do design, ou projeto, de software está relacionada ao ciclo de vida do projeto, em que são feitas a análise dos requisitos e a descrição da estrutura interna do software. Aqui, definem-se a arquitetura, os componentes, as relações e outras características do sistema. Essa área é apresentada com a estrutura descrita a seguir. � Fundamentos do projeto de software: discute os conceitos gerais relacionados à arquitetura do software, como o contexto, o processo e os princípios fundamentais em design de software. � Questões-chave em design de software: nessa fase, são discutidas questões relacionadas à arquitetura, como concorrência, controle de eventos, persistência de dados e segurança. � Estrutura e arquitetura de software: apresenta estruturas e estilos arquiteturais e padrões, discute as decisões de arquitetura e apresenta conjuntos de programas e frameworks. 4 Software Engineering Body of Knowledge (SWEBOK) Identificação interna do documento 5UVZ0Q6SJ5-BDUBFU1 � Projeto da interface com o usuário: discursa sobre questões relacionadas a princípios, problemas, modalidades, formas de apresentação e outros tópicos relacionados à experiência do usuário com o sistema. � Análise e avaliação de qualidade do projeto de software: discute os atributos de qualidade, a análise, as métricas e as técnicas de avaliação de design de software. � Notações do projeto de software: diferencia descrições estruturais (visualizações estáticas) e descrições comportamentais (visualizações dinâmicas). � Estratégias e métodos para o projeto de software: apresenta as principais estratégias voltadas ao design de software, como orientada a função, orientada a objeto, centrada nos dados ou baseada em componentes, entre outras. � Ferramentas para o projeto de software: podem ser utilizadas como apoio para a criação do artefato de software. Usualmente, possibilitam as atividades de traduzir o modelo de requisitos em uma representação de projeto, além de apoiar a representação da interface e dos componentes funcionais, entre outras atividades. 3 Construção de software Essa área integra as demais áreas de conhecimento do guia SWEBOK, mas se destaca um relacionamento maior com o projeto e os testes de software. Estão inseridas aqui as atividades de implementação, verificação, testes de unidade e teste de integração e depuração. Essa seção trata dos pontos descritos a seguir. � Fundamentos da construção: apresenta técnicas para ajudar a reduzir a complexidade e antecipar necessidades de mudança, verificação, reúso e outros padrões relacionados. � Gerenciamento da construção: introduz os modelos de ciclo de vida, o planejamento e as métricas relacionadas à construção de software. � Considerações práticas: trata de questões como o design da construção, as linguagens, a codificação, a qualidade na construção, a integração, entre outros tópicos relacionados. � Tecnologias para construção: apresenta diversos conceitos relacionados a tecnologias para o desenvolvimento de software, como projeto e uso de interfaces de programação de aplicações, padrões de plataforma, modelos executáveis, middleware etc. Software Engineering Body of Knowledge (SWEBOK) 5 Identificação interna do documento 5UVZ0Q6SJ5-BDUBFU1 � Ferramentas para a construção de software: apoiam o desenvolvimento do software em si por meio dos ambientes de desenvolvimento, dos construtores de interface gráfica, das ferramentas para teste unitário e das ferramentas para análise de desempenho. 4 Teste de software Segundo o SWEBOK (BOURQUE; FAIRLEY, 2014), o teste de software é uma atividade realizada para a avaliação da qualidade do produto, efetuando sua melhoria por meio da identificação de defeitos e problemas. Aqui, é feita a verificação do comportamento do software a partir de casos de testes, para verificar se o comportamento está dentro do esperado. A área de testes de software inclui as subáreas descritas a seguir. � Fundamentos de teste de software: introduz terminologias e problemas- -chave e fala do relacionamento de testes de software com outras áreas do conhecimento. � Níveis de teste: discute a importância de definir bem o alvo e os objetivos do teste. � Técnicas de testes: apresenta as técnicas mais utilizadas, como a técnica baseada na intuição e experiência do engenheiro de software, a baseada no código e a baseada em falhas, e discute como selecionar e/ou combinar as técnicas mais adequadas de acordo com o contexto. � Métricas relacionadas aos testes: trata especificamente de duas avaliações, a avaliação do programa que está sendo testado e a avaliação dos testes que foram executados. � Processo de testes: fala das aplicações práticas relacionadas às atividades de testes. � Ferramentas para o teste de software: inclui ferramentas para a criação de drivers e stubs, para a geração de casos de teste, para a captura e repetição de erros, para testes de regressão, entre outras. 5 Manutenção de software Essa área tem como foco principal dar suporte ao produto no ciclo de vida operacional. Esse suporte efetivo pode ser fornecido antes ou depois da entrega ao cliente: antes, desenvolvendo atividades de planejamento; depois, nas codificações para corrigir as falhas e melhorar o desempenho. De forma 6 Software Engineering Body of Knowledge (SWEBOK) Identificação interna do documento 5UVZ0Q6SJ5-BDUBFU1 geral, as manutenções de software podem ser corretivas, adaptativas, perfectivas ou preventivas. Na manutenção corretiva, o software é modificado para corrigir os erros encontrados. Na manutenção adaptativa, o software é alterado para se adaptar às mudanças do ambiente externo. Já na manutenção perfectiva, o software é aprimorado conforme solicitação do cliente. Por fim, na manutenção preventiva, o software é modificado para facilitar as correções, adaptações e melhorias. A área de manutenção é apresentada conforme as subáreas apresentadas a seguir. � Fundamentos de manutenção de software: introduz a terminologia relacionada à manutenção de software, à natureza da manutenção, à sua necessidade, além de categorias, custos etc. � Questões-chave em manutenção de software: discute questões técnicas, gerenciais e relacionadas à estimativa de custos da manutenção. � Processo de manutenção: especifica as práticas mais comuns relacionadas a processos e atividades de manutenção. � Técnicas para a manutenção: apresenta técnicas como reengenharia, engenharia reversa e migração. � Ferramentas para a manutenção de software: ferramentas que são utilizadas quando o software está sendo modificado, como ferramentas que verificam a dependência entre trechos de código-fonte. 6 Gerência da configuração de software (GCS) Essa é a área que tem por finalidade controlar as versões do software durante o desenvolvimento do projeto e apresentaas atividades descritas a seguir. � Gerenciamento do processo de GCS: discute o contexto organizacional, as restrições e guias para o processo de GCS, o planejamento, o plano e a sobrevivência de sistemas de GCS. � Identificação da configuração do software: apresenta os itens a serem controlados e as bibliotecas de software. � Controle da configuração do software: fala sobre requisições, avaliações e aprovação de mudanças, sobre implementação de mudanças nos software e sobre desvios e desistências. � Controle do status de configuração de software: apresenta a importância da informação e do relatório de status do software de configuração. Software Engineering Body of Knowledge (SWEBOK) 7 Identificação interna do documento 5UVZ0Q6SJ5-BDUBFU1 � Auditoria da configuração de software: discute a auditoria funcional e física. � Gerenciamento e entrega das releases do software: discute as entregas de software e o versionamento. � Ferramentas para a GCS: incluem ferramentas para a identificação, o empacotamento e a entrega do produto de software. Ferramentas nessa categoria incluem ferramentas de controle de versão e de controle de mudanças. Um exemplo muito utilizado é o GitHub (c2020), uma das ferramentas de versionamento de software mais utilizadas no mundo, que hospeda mais de 100 milhões de repositórios de código-fonte contendo as mais diferentes linguagens de programação. 7 Gerência da engenharia de software Esta área se destina às atividades de gerenciamento do projeto de software, como planejamento, coordenação, medição, monitoração, controle e documentação, a fim de garantir software de qualidade. O projeto é algo com início, meio e fim, ou seja, é temporário e tem o objetivo de criar um produto ou um serviço. Segundo Pressman e Maxim (2016), a gestão do projeto engloba o planejamento, a monitoração e o controle de todos os eventos que acontecem durante o processo de desenvolvimento do software. O gerenciamento da engenharia de software é dividido conforme descrito a seguir. � Iniciação e definição do escopo: inclui a determinação e negociação dos requisitos, a análise de viabilidade e a discussão do processo para revisão de requisitos. � Planejamento do projeto de software: trata do planejamento, da determinação dos entregáveis do projeto, das estimativas de esforço, do cronograma e custo, da alocação de recursos, da gerência de riscos, da gerência da qualidade e da gerência do plano do projeto. � Declaração do projeto de software: inicia a implementação do plano definido na etapa anterior. Trata da aquisição de recursos, da implementação de métricas de processo, do monitoramento, do controle e dos relatórios do progresso. � Revisão e avaliação: determina a satisfação dos requisitos e revisa e avalia o desempenho. � Encerramento: determina o fechamento do projeto e encerra as atividades. 8 Software Engineering Body of Knowledge (SWEBOK) Identificação interna do documento 5UVZ0Q6SJ5-BDUBFU1 � Métricas de desempenho em engenharia de software: estabelece e mantém um comprometimento com as medições, planeja e executa os processos de medição e, por fim, avalia as medições. � Ferramentas para o gerenciamento da engenharia de software: facilitam a visibilidade e o controle do software em desenvolvimento. Incluem ferramentas para planejamento e rastreabilidade do projeto, para gerenciamento de riscos, para facilitar a comunicação e para cálculo das métricas. 8 Processo de engenharia de software Compreende um conjunto de atividades que facilitam a transformação de ideias abstratas em projetos de software. É composto pelas subáreas descritas a seguir.
 � Definição do processo de software: definições gerenciais e arquiteturais.
 � Ciclo de vida do software: apresenta categorias, modelos, adaptação de processos e outras considerações práticas. 
� Avaliação e melhoria do processo de software: trata sobre os modelos e métricas relacionados à avaliação e sobre os modelos relacionados à melhoria do processo de software.
 � Métricas de software: métricas relacionadas a processo e produto, à qualidade dos resultados mensurados, aos modelos de informação de software e às técnicas para identificar métricas de processo de software.
 � Ferramentas para o processo de engenharia de software: inclui ferramentas para desenho de fluxos, diagramas, mapeamento das atividades, painel de controle, dashboard etc. 
9 Modelos e métodos de engenharia de software Nessa área, são pesquisados modelos e métodos que aumentem a produtividade, auxiliando no ciclo de vida do software. Essas ferramentas automatizam atividades do processo, liberando o analista para se concentrar nas atividades que exigem esforço intelectual. Essa área se divide nas subáreas descritas a seguir. � Modelagem: introduz os princípios da modelagem, as propriedades e a expressão dos modelos, contextualiza sintaxe, semântica e pragmática, além de pré-condições, pós-condições e invariantes. Software Engineering Body of Knowledge (SWEBOK) 9 Identificação interna do documento 5UVZ0Q6SJ5-BDUBFU1 � Tipos de modelos: discute os modelos informacional, comportamental e estrutural. � Análise de modelos: discursa sobre a completeza, a consistência, a correção, a rastreabilidade e a análise de interação dos modelos. � Métodos de engenharia de software: discute os métodos heurístico, formal, por protótipo e ágeis. 10 Qualidade de software Para falar de qualidade, é necessário observar vários aspectos relacionados ao produto, como desenvolvimento, manutenção e uso. Melhorar a qualidade é um dos principais objetivos da engenharia de software, e isso é possível a partir da utilização de métodos e tecnologias. Empresas que trabalham a melhoria da qualidade geralmente utilizam modelos como Capability Maturity Model Integration ou normas técnicas como a ISO/IEC 9126. Essas empresas podem pleitear a certificação como forma de garantir aos seus clientes que elas desenvolvem e entregam produtos com maior qualidade. A qualidade de software se divide nas subáreas descritas a seguir.
 A - Fundamentos da qualidade de software: discute o impacto da cultura e da ética na qualidade de software, a relação de valor versus custo na qualidade, as características de modelos, a melhoria na qualidade do software e a segurança de sistemas.
 C - Processos de gerência da qualidade de software: apresenta os conceitos relacionados à garantia da qualidade, à verificação, à validação, às revisões e à auditoria da qualidade do software. 
D - Considerações práticas: fala sobre os requisitos de qualidade, introduz a caracterização de defeito, apresenta técnicas para a gerência da qualidade do software e discursa sobre as métricas de qualidade no software.
 � Ferramentas para o processo de qualidade de software: inclui ferramentas de análise estática e dinâmica para analisar a qualidade do software. As primeiras 10 áreas de conhecimento, discutidas até então, tratam especificamente de conteúdo diretamente relacionado ao produto e ao processo de software. As próximas cinco áreas a serem apresentadas também são bastante relevantes para a engenharia de software, pois tratam de conceitos relacionados e fundamentais à prática da engenharia de software. 
10 Software Engineering Body of Knowledge (SWEBOK) Identificação interna do documento 5UVZ0Q6SJ5-BDUBFU1 11 Prática profissional em engenharia de software Esta área apresenta os conhecimentos, as habilidades e as atitudes necessárias a um indivíduo que trabalha com engenharia de software. Discursa sobre questões como o profissionalismo e o uso de dinâmicas de grupo e psicologia e fala da importância das habilidades de comunicação. 12 Economia em engenharia de software Aborda o contexto econômico da engenharia de software pela perspectiva de negócios, com bastante ênfase no custo para o desenvolvimento de um projeto de software. Nessa área, são apresentados os fundamentos de economia em engenharia de software. Também se discute o ciclo de vida da economia, os riscos e as incertezas, os métodos de análise econômica e, por fim, as considerações práticas em relação aoaspecto econômico para o desenvolvimento de sistemas. 13 Fundamentos de computação Na área de conhecimento sobre os fundamentos de computação, são abordados conceitos fundamentais relacionados à ciência da computação, como as principais técnicas para resolução de problemas, a abstração, os fundamentos de programação, as ferramentas e técnicas para debugação, as noções básicas sobre linguagem de programação, os fatores humanos etc. 14 Fundamentos matemáticos Apresenta conceitos matemáticos importantes para facilitar a abstração de engenheiros de software ao trabalhar com um problema computacional baseado em matemática, como a teoria dos conjuntos, as relações e funções, a lógica básica, os grafos e árvores, a teoria dos números, as estruturas algébricas, entre outros. 15 Fundamentos de engenharia Entre as técnicas e os métodos de engenharia que podem ser aplicadas à engenharia de software, podemos citar: métodos empíricos e técnicas experimentais, análise estatística, métricas, modelagem, simulação e prototipagem, análise de causa raiz, entre outras. Software Engineering Body of Knowledge (SWEBOK) 11 Identificação interna do documento 5UVZ0Q6SJ5-BDUBFU1 2 Certificações SWEBOK O mercado de tecnologia da informação vem desenvolvendo-se e tornando-se cada vez mais competitivo no que diz respeito a novas tecnologias e também aos serviços prestados. Adotar modelos e padrões de qualidade ajuda as empresas a se diferenciarem das demais, pois, com isso, demostram maior organização e preocupação quanto aos produtos desenvolvidos. A IEEE disponibiliza três tipos de certificação relacionadas ao SWEBOK, descritas a seguir. � Associate Software Developer — Certificação de Desenvolvedor de Software Associado: para esta certificação, os candidatos devem comprovar que possuem os requisitos básicos de conhecimento relacionados ao desenvolvimento de produtos de software. O candidato deve demonstrar conhecimento sobre os princípios e processos relacionados às áreas de requisitos, design, construção e teste de software. ■ Não há pré-requisitos para esta certificação, embora seja essencial o estudo do SWEBOK. ■ O exame é on-line, dura 100 minutos e é composto por 80 questões. � Professional Software Developer — Certificação para Desenvolvedor de Software Profissional: o candidato a esta modalidade deve apresentar proficiência como desenvolvedor de software nas mesmas quatro áreas de conhecimento básicas (requisitos, design, construção e teste de software). ■ Não há pré-requisitos para esta certificação, embora seja essencial o estudo do SWEBOK. Ainda, é recomendado um mínimo de dois anos de educação superior em Ciência da Computação ou equivalente, além de dois anos de experiência na indústria de software. ■ O exame é on-line, dura três horas e é composto por 160 questões. � Professional Software Engineering Master — Mestre Profissional em Engenharia de Software: esta é a certificação mais completa e mais complexa. O candidato deverá comprovar maestria em 11 áreas de conhecimento do SWEBOK: requisitos, design, construção, teste, manutenção, gerência de configuração, gerência da engenharia de software, modelos e métodos, qualidade e economia em engenharia de software. ■ Não há pré-requisitos para esta certificação, embora seja essencial o estudo do SWEBOK. Ainda, é recomendado um mínimo de quatro anos de educação superior em Ciência da Computação ou equivalente, além de quatro anos de experiência na indústria de software. ■ O exame é on-line, dura três horas e é composto por 160 questões. 12 Software Engineering Body of Knowledge (SWEBOK) Identificação interna do documento 5UVZ0Q6SJ5-BDUBFU1 As certificações do desenvolvedor de software associado da IEEE Computer Society são projetadas para avaliar e validar o conhecimento de engenharia de software e as habilidades de desenvolvimento. A avaliação reúne várias áreas de conhe
Tabela de requisitos levantados