Engenharia de Software: Conceitos e Melhores Práticas

Engenharia de Software

Engenharia de Software: Aplicação de abordagem sistemática, disciplinada e quantificável no desenvolvimento, operação e manutenção de software (IEEE, STD 610 – 1990).

Estabelecimento e uso de sólidos princípios de engenharia na obtenção de um software confiável, eficiente e economicamente viável (Fritz Bauer – 1969).

Início de um Projeto de Desenvolvimento de Software

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

Importância de um Time Coeso no Desenvolvimento de Software

Vantagens:

• Padronização de qualidade pode ser desenvolvida/implementada;
• Trabalho integrado: inibição devido a desconhecimento ou ignorância é reduzida;
• Membros aprendem uns com os outros e conhecem o trabalho de cada um;
• Esforço para a melhoria do programa de cada membro, em detrimento do Ego.

Determinação do Número Ideal de Módulos do Sistema

A curva em formato de parábola é gerada a partir da composição do custo unitário (por módulo) e o custo da integração dos módulos. O ponto de mínimo desta curva indica o custo mínimo no desenvolvimento de um sistema, composição entre baixar o custo unitário sem permitir que o custo de integração exploda.

Impacto da Coesão e Acoplamento na Qualidade do Sistema

Coesão e acoplamento são tidos como critérios de qualidade no desenvolvimento de software. Quanto maior a coesão e menor o acoplamento, maior a qualidade do código. O gráfico acima indica, de um ponto de vista puramente financeiro, o intervalo ótimo de número de módulos do sistema, o que pode estar em conflito com o número otimizado desde um ponto de vista de qualidade.

Sendo assim, com foco em custo, pode ser necessário diminuir a coesão e aumentar o acoplamento do sistema visando baratear o custo final do sistema.

Gerenciamento de Riscos em Projetos de Software

Definição:

Gerência de Risco (RM) - foca em identificar riscos e implementar planos que minimizem seus efeitos.

Processo de RM:

• Identificação - riscos de projeto, produto e negócio;
• Análise - estimar a probabilidade e as consequências desses riscos;
• Planejamento - desenho de um plano de contingência;
• Monitoração - monitorar os riscos durante o projeto.

Interfaces entre Sistemas em um Projeto de Software

O projeto de interfaces é um dos princípios básicos de um projeto de software e obrigatoriamente deve constar da definição e análise de requisito, tendo impacto direto na operação (manutenção). A quantidade e complexidade das interfaces influenciam diretamente o custo, prazo e dificuldade do projeto. Seu maior impacto vem da dificuldade do gerenciamento já que, na maioria das vezes, o owner e operação do outro sistema é independente, de difícil gerenciamento.

Segmentação de Sistemas Complexos em Subsistemas

A divisão faz uso de um dos princípios básicos da Engenharia de Software: a Segmentação (ou Decomposição). Basicamente sua vantagem reside em que a complexidade do problema das partes (subdivisões) é menor do que a do todo, resultando menor esforço de entendimento e trabalho.

Na etapa de desenvolvimento essa abordagem resulta em maior velocidade na entrega e na operação resulta em maior velocidade na manutenção (menor custo).

Coesão e Acoplamento: Análise Comparativa

Definições:

Coesão – medida da diversidade dos "tópicos" abordados por um módulo.

Acoplamento – medida da dependência de um módulo em relação aos outros.

Comparando as opções, o módulo A na Opção II (em relação a Opção I) apresenta menor coesão (depende de maior interação com outros módulos), enquanto os módulos B e C apresentam maior coesão. No aspecto geral, o acoplamento da Opção II é maior que da Opção I.

Efetivamente, fazendo-se uma análise de fan-in e fan-out dos módulos, vemos que estes são os módulos impactados:

Requisitos Funcionais vs. Não Funcionais

Definições:

Funcionais - funcionalidade do software que atende a uma necessidade de automação - “o quê” se espera seja feito.

Não-Funcionais – qualidades e restrições globais do sistema.

Requisitos Funcionais são aspectos específicos, funcionalidades solicitadas. Os não-funcionais são subjetivos, geralmente medidos de forma indireta.

Estratégias para Tratamento de Sistemas

A definição das opções de como tratar um sistema passa pela análise de Valor Estratégico x Qualidade, exatamente o gráfico apresentado.

A informação referente à qualidade do código é obtida analisando-se a quantidade e tipo de manutenções (registro histórico) e feedback do grupo de TI.

A informação referente ao valor estratégico é obtida mediante feedback dos stakeholders, adequação dos procedimentos ao domínio do sistema.

Com os dois feedbacks indicados acima é possível definir o quadrante em que se encontra o sistema.

1. A teoria de análise de sistemas legados indica que:

Baixa qualidade, alto valor negócio (I): reengenharia ou substituição;

Alta qualidade, alto valor de negócio (II): continuar operação;

Alta qualidade, baixo valor de negócio (III): CotS, eliminação ou manutenção;

Baixa qualidade, baixo valor de negócio (IV): sistemas devem ser substituídos.

Assim sendo, posicionando-se o sistema no gráfico, definimos qual a estratégia que melhor se adéqua.

Modelos de Análise na Fase de Desenvolvimento

Na fase de análise, três modelos que devem ser considerados são: do domínio da informação, o funcional e o comportamental.

Comunicação Eficaz: Canal Oral, Visual ou Misto?

A diferença fundamental é a da retenção da informação pela audiência:

Canal Após 3 horas Após 3 dias

Oral 70% 10%

Visual 70% 20%

Oral + Visual 85% 65%

Tipicamente, é mais eficiente comunicar-se com o grupo de trabalho via mescla de canais do que por um isolado.

Bibliotecas de Módulos: Vantagens e Desvantagens

A padronização de procedimentos de trabalho e documentação permite/facilita o entendimento do código e sua manutenção/desenvolvimento/adaptação por membros diversos da equipe.

1. Quando bem implementada/utilizada, gera awereness do grupo e permite o reuso.

Caso a biblioteca de módulos criada não seja extensa (em relação ao mercado de atuação), os módulos podem não atender à necessidade específica do cliente.

Estudo de Viabilidade: Aspectos Essenciais

Relatório que visa embasar a decisão de se a proposta (software ou sistema) é viável - aspectos técnicos, financeiros e temporais.

Estudo focado em analisar:

• Contribuição aos objetivos organizacionais;
• Integração com sistemas atualmente em uso;
• Orçamento x necessidades financeiras;
• Disponibilidade x necessidades técnicas.

Desafios na Etapa de Elicitação de Requisitos

Elicitação é sinônimo de Descobrimento de Requisitos, etapa em que o time técnico trabalha com o cliente para descobrir:

• Domínio da aplicação;
• Serviços requeridos;
• Vínculos e limitações.

Fundamental o envolvimento de todos os stakeholders no processo. Tipicamente o time técnico encontrará dificuldades do tipo:

• Stakeholders não têm claro as necessidades;
• Conflito de terminologia e linguagem (técnicos x negócio);
• Conflito de requisitos;
• Impactos organizacionais/políticos;
• Processo dinâmico: eliminação/alteração/surgimento de requisitos;
• Alteração do ambiente.