Engenharia de Software: Requisitos, Gestão e Manutenção

Critérios de Seleção

Possíveis critérios e informações para seleção:

• Informação fornecida pelos candidatos (CV);
• Entrevistas e conversas;
• Recomendações e comentários de pessoas que conhecem ou trabalharam com os candidatos;
• Experiência: no domínio da aplicação, na plataforma e na linguagem de programação;
• Habilidade na solução de problemas;
• Aspectos pessoais: educação, comunicação, flexibilidade, atitude e personalidade.

Possíveis problemas:

• Em um insourcing, a organização pode não querer “perder” pessoas para um novo projeto. O envolvimento parcial é inevitável;
• Recém-formados podem não possuir habilidades específicas (mas pode ser uma maneira simples de introduzir novas);
• A proficiência técnica pode ser menos importante que habilidades sociais;
• Cuidado com habilidades de alta procura e baixa oferta;
• Aspectos políticos ou culturais sobrepujando os técnicos;
• Resistência à mudança.

Engenharia de Requisitos: Estudo de Viabilidade

Estudo de Viabilidade: Decidir se a proposta (software ou sistema) é viável nos aspectos técnicos, financeiros, humanos e temporais.

O Estudo de Viabilidade antecede o projeto em si, sendo algumas vezes denominado de anteprojeto. Seu principal entregável (deliverable) é o Relatório de Viabilidade, que detalha os prós e contras da solução proposta, problemas da situação atual, impactos da (não) implementação e necessidades financeiras, tecnológicas e humanas.

Gerência de Mudança

Processo de requisição, análise de viabilidade, análise de impacto, planejamento, implementação e avaliação/validação de uma alteração em um sistema ou software. Possui dois objetivos principais:

• Suporte ao processo de mudança;
• Permitir a rastreabilidade.

Na etapa de desenvolvimento, tipicamente, analisa alterações de requisitos. É fundamental manter o controle do relacionamento entre a origem de um requisito, suas conexões, interdependências e o desenho do sistema ou software.

Importância da Identificação de Requisitos

Qual a importância e o impacto da clara identificação dos requisitos nas etapas?

A correção de erros pós-entrega, já na etapa de evolução (operação, produção ou manutenção), pode apresentar um custo 100 vezes superior ao de sua correção na fase de desenvolvimento ou validação.

Processo PDCA

Desenho esquemático do processo PDCA:

• Plan: Planejamento;
• Do: Ação / Implementação;
• Check: Verificação / Validação;
• Act: Correção.

Metodologia 5W1H

O que significa a sigla 5W1H? Onde e como é utilizada?

Sigla de uma metodologia básica de acompanhamento e gerenciamento. É composta pelas iniciais dos termos em inglês: What (o quê), When (quando), Where (onde), Who (quem), Why (por que) e How (como). É utilizada na definição dos aspectos básicos de um projeto.

Tipos de Manutenção de Software

Em uma empresa, após um ano de utilização de seu ERP, diferentes cenários podem exigir manutenção. Os três tipos existentes são:

• Corretiva: Correção de erros;
• Adaptativa: Ajuste de componentes;
• Evolutiva: Adição de novos componentes.

Cenário 1: Mudança de legislação. Do texto, temos que houve uma mudança de legislação, significando algo que já existe e foi alterado. Portanto, o tipo de manutenção é a Adaptativa.

Cenário 2: Nova funcionalidade. Do texto, temos que houve uma nova necessidade, significando algo que não existe. Portanto, o tipo de manutenção é a Evolutiva.

Cenário 3: Erro de requisitos. Do texto, temos que houve um erro relacionado a requisitos (mau entendimento). Portanto, o tipo de manutenção é a Corretiva.

Análise de Sistemas Legados e Reengenharia

A definição das opções de como tratar um sistema passa pela análise de Valor Estratégico vs. Qualidade. A teoria indica:

• I. Baixa qualidade, alto valor de negócio: Reengenharia ou substituição;
• II. Alta qualidade, alto valor de negócio: Continuar operação;
• III. Alta qualidade, baixo valor de negócio: CotS, eliminação ou manutenção;
• IV. Baixa qualidade, baixo valor de negócio: Sistemas devem ser substituídos.

Perguntas de Classificação:

• Em qual situação um sistema é indicado para reengenharia? Resposta a) apenas na situação I (Baixa Qualidade e Alto Valor Estratégico).
• Em qual situação um sistema é indicado para substituição? Resposta c) apenas nas situações I e IV (Sistemas de Baixa Qualidade).
• Em qual situação um sistema não deve sofrer alteração? Resposta e) apenas na situação II (Alta Qualidade e Alto Valor Estratégico).

Princípios Básicos da Engenharia de Software

• Formalidade: Processos de desenvolvimento e gerência de software regidos e orientados por passos precisos e exatos.
• Abstração: Identificação dos aspectos relevantes do problema analisado, ignorando-se detalhes secundários.
• Decomposição: Subdivisão de processos ou atividades complexas em seus aspectos específicos, permitindo sua alocação a equipes especialistas e no tempo.
• Generalização: Oposta à especialização, permite que o produto desenvolvido atue em uma ampla área de atividades.
• Flexibilização: Facilidade de alterar o produto desenvolvido.

Mitos do Desenvolvimento de Software

Por que o mito de aumentar a equipe em caso de atraso está errado? Conforme a realidade descrita, a entrada de novos membros gera um atraso ainda maior, pois exige tempo para treinamento dos novos integrantes e aumenta exponencialmente a complexidade da comunicação interna da equipe.