Introdução à Engenharia de Software

Prof. Marcelo de Barros

Para Pressman (2006)

◦ “Um software é um conjunto composto por instruções de computador, estruturas de dados e documentos”

Segundo o IEEE (1992)

◦ “Engenharia de Software é a aplicação de uma abordagem sistemática, disciplinada e quantificável, para o desenvolvimento, operação e manutenção do software, isto é, a aplicação da engenharia ao software”

Para Bauer (1969)

◦ A Engenharia de Software é “a criação e a utilização de sólidos princípios de engenharia a fim de obter software econômicos que sejam confiáveis e que trabalhem eficientemente em máquinas reais”

É uma disciplina da engenharia dedicada a todos os aspectos da produção de software.

Engenheiros de software devem adotar uma abordagem sistemática e organizada para o seu trabalho e usar técnicas e ferramentas apropriadas, de acordo com o problema a ser resolvido, e com as restrições e recursos disponíveis.

(Sommerville)

A ES almeja inserir as mesmas sistemáticas existentes em outras áreas da engenharia:◦ Custos aceitáveis

◦ Gerenciamento do processo de desenvolvimento

◦ Garantia do trabalho em equipe

◦ Desenvolvimento de softwares com qualidade

Alguns princípios devem ser trabalhados na Engenharia de Software como forma de manter o bom funcionamento do produto final:◦ Evitar dependência de determinas pessoas ou

processos

◦ Abstrair aspectos importantes

◦ Subdividir problemas complexos

◦ Reutilizar resultados (código)

◦ Flexibilização e modularização para facilitar a manutenção

A ES é multidisciplinar, podemos dizer que une as seguintes áreas:

◦ Ciência da Computação: abrange arquitetura de computadores, lógica de programação, estrutura de dados e algoritmos, etc.

◦ Administração: o engenheiro de software atua como gestor de um projeto, administrando prazos, equipes, custos, resultados, etc.

A ES é multidisciplinar, podemos dizer que une as seguintes áreas:

◦ Comunicação: habilidade para saber se expressar com clientes ou usuários

◦ Técnicas de solução de problemas: o engenheiro de software deve ser um solucionador de problemas, um gerador de soluções integradas e inteligentes

Década de 50◦ Surgiram os primeiros softwares

◦ Pesquisas eram voltadas para o hardware

◦ Hardware disponível apenas nos centros de pesquisa

◦ Software desenvolvido sem utilizar técnicas de engenharia

Década de 60◦ Surgiram os microprocessadores e o hardware

deixou de representar um problema

◦ Software tornou-se o foco dos pesquisadores

◦ Organizações começaram a desenvolver grandes sistemas

A falta de metodologia◦ As equipes de trabalho não tinham um modelo de

como desenvolver

◦ Não havia documentação adequada do que estava sendo produzido

◦ “E agora: como dar manutenção em um sistema que não tem projeto?”

1968 Conferência da OTAN, Garmisch◦ Objetivo: resolver a “Crise do Software”

◦ Software é entregue

Atrasado

Com orçamento estourado

Com falhas residuais

◦ Custo do hardware decrescente e custo do software em ascensão

Problemas◦ Prazos e custos não respeitados

◦ Ineficiência durante a etapa de definição de requisitos que não atendem às necessidades dos clientes

◦ Gerentes e coordenadores de projetos despreparados para controlar o desenvolvimento adequado de um software

Desafio◦ A Engenharia de Software dedica-se a

Reduzir custos

Melhorar a qualidade do software

Atender às expectativas do cliente

◦ Dividir o desenvolvimento de software em camadas

Processos (métodos + ferramentas)

Métodos (como fazer)

Ferramentas (apoio automatizado)

Processos (métodos + ferramentas)

Métodos (como fazer)

Ferramentas (apoio automatizado)

Processo (métodos + ferramentas)

◦ une os métodos às ferramentas;

◦ define a sequência dos métodos que serão aplicados e;

◦ define as ferramentas que serão disponibilizadas.

Métodos (como fazer)

◦ há diferentes métodos para as diferentes etapas do desenvolvimento;

◦ existem métodos para análise de requisitos, projeto, codificação, testes e manutenção.

Ferramentas (apoio automatizado)

◦ CASE (Computer Aided Software Engineering);

◦ análise estruturada, análise essencial ou orientada a objetos;

◦ ferramentas de banco de dados;

◦ linguagens de programação.

Estrutura de um processo aplicável à maioria dos projetos de software, sejam eles de pequena, média ou alta complexidade:

1. ComunicaçãoContempla alta comunicação e colaboração com o cliente/usuário e abrange o levantamento de requisitos.

2. PlanejamentoDescreve as tarefas técnicas, os riscos prováveis, os recursos necessários, os produtos que serão produzidos e um cronograma.

Estrutura de um processo aplicável à maioria dos projetos de software, sejam eles de pequena, média ou alta complexidade:

3. Modelagem Constrói modelos que permitem ao desenvolvedor e ao cliente entender melhor os requisitos do software e o software que atenderá esses requisitos.

4. Construção Contempla a criação dos códigos e a execução de testes.

Estrutura de um processo aplicável à maioria dos projetos de software, sejam eles de pequena, média ou alta complexidade:

5.ImplantaçãoAvaliação e feedback do cliente quanto ao software desenvolvido

Um Processo de Software é o conjunto de atividades cuja meta é o desenvolvimento ou evolução de um software.

As atividades genéricas em todos os processos de software são:

◦ Especificação: o que o sistema deve fazer e suas restrições de desenvolvimento.

◦ Desenvolvimento: produção do sistema de software.

◦ Validação: verificação de que o software é o que o cliente deseja.

◦ Evolução: mudança do software em resposta às demandas de mudança.

Software é um elemento do sistema lógico, desenvolvido ou projetado por engenharia, não

manufaturado (no sentido clássico)

Conjunto de instruções que, quando executadas, produzem a função e o

desempenho desejados

Quais são os passos para se construir um software?

Similaridade com a Engenharia Civil◦ O que o cliente pediu (na cabeça dele):

Similaridade com a Engenharia Civil◦ Planta (projeto) da casa:

Similaridade com a Engenharia Civil◦ Reflexão:

Num projeto de uma residência, é prudente ir direto para a construção sem qualquer planta ou planejamento?

E os custos? Tempo? Gastos?

E o principal: atender às necessidades e anseios do cliente?

Como trabalha a Engenharia de Software:

Software Básico

Software de Tempo Real

Software Comercial

Software Científico e de Engenharia

Software Embutido

Software de Computador Pessoal

Software de Inteligência Artificial

Básico◦ coleção de programas escritos para dar apoio a

outros programas

De Tempo Real◦ software que monitora, analisa e controla eventos

do mundo real

Comercial◦ sistemas de operações comerciais e tomadas de

decisões administrativas

Científico e de Engenharia◦ caracterizado por algoritmos de processamento de

números

Embutido ◦ usado para controlar produtos e sistemas para os

mercados industriais e de consumo

De Computador Pessoal ◦ envolve processamento de textos, planilhas

eletrônicas, diversões, etc.

De Inteligência Artificial ◦ faz uso de algoritmos não numéricos para resolver

problemas que não sejam favoráveis à computação ou à análise direta

Facilidade de manutenção

◦ O software deve evoluir para atender às necessidades de mudança.

Confiança

◦ O software deve ser confiável.

Eficiência

◦ O software não deve desperdiçar os recursos do sistema.

Usabilidade

◦ O software deve ser aceito pelos usuários para o qual foi projetado.

◦ Isso significa que ele deve ser compreensível, usável e compatível com outros sistemas.

Heterogeneidade

◦ Técnicas de desenvolvimento para construção de software que podem lidar com plataformas heterogêneas e ambientes de execução.

Entrega

◦ Técnicas de desenvolvimento para conduzir a entrega mais rápida de software.

Confiança

◦ Técnicas de desenvolvimento que mostram que o software pode ter a confiança dos seus usuários.

Processos de Engenharia de Software

Prof. Marcelo de Barros

No livro How to solve it (1945), o matemático George Pólyaaponta os principais pontos para a solução de problemas, os quais podem facilmente ser aplicados à Engenharia de Software:

◦ Entenda o problema (comunicação e análise)

◦ Planeje uma solução (modelagem e projeto de software)

◦ Execute o plano (geração de código)

◦ Examine o resultado quanto à precisão (teste e qualidade)

Entenda o problema

◦ Quem tem interesse na solução do problema?

◦ Quais dados, funções, características e comportamento são necessários para resolver o problema?

◦ É possível representar problemas menores para facilitar a compreensão?

◦ O problema pode ser representado graficamente?

Planeje a solução

◦ Já viu problemas parecidos?

◦ Já resolveu algum problema parecido?

◦ É possível subdividir os problemas?

◦ É possível definir um modelo que possa ser implementado?

Execute o plano

◦ A solução está de acordo com o plano?

◦ Cada componente da solução está correto?

Examine o resultado

◦ Foi elaborada uma estratégia de teste?

◦ O software foi avaliado de acordo com os requisitos?

Processos

Processo e Engenharia de Software na prática?

1. Comunicação

2. Planejamento

3. Modelagem

4. Construção

5. Implantação

Antes de tudo, os requisitos são coletados por meio de uma atividade de comunicação chamada levantamento de requisitos.

A comunicação para o entendimento de um problema, normalmente, é difícil.

A comunicação é considerada uma das atividades mais desafiadoras encontrada por um engenheiro de software.

Princípio 1: Escute

◦ Concentre-se nas respostas do interlocutor;

◦ Peça esclarecimentos quando algo estiver obscuro;

◦ Evite interrupções constantes;

◦ Evite sacudir a cabeça, virar os olhos;

◦ Evite influenciar a resposta do interlocutor.

Princípio 2: Prepare-se antes de se comunicar

◦ Gaste tempo para entender o problema;

◦ Se necessário, pesquise para entender o jargão do negócio.

Princípio 3: Alguém deve facilitar a atividade

◦ Toda reunião deve ter um facilitador para:

◦ Conduzir a conversa para que seja sempre produtiva;

◦ Mediar possíveis conflitos;

◦ Garantir que os outros princípios sejam seguidos.

Princípio 4: Comunicação face a face é melhor ◦ Mas a apresentação de uma outra forma de comunicação é sempre bem-

vinda. Por exemplo, um documento ou um desenho.

Princípio 5: Faça anotações e documente as decisões ◦ Alguém que participe da comunicação deve anotar todos os pontos e

decisões importantes.

Princípio 6: Busque colaboração ◦ Procure fazer com que os membros da equipe façam colaborações,

mesmo que pequenas, pois elas aumentam a confiança entre os membros.

Princípio 7: Conserve-se enfocado, modularize sua discussão ◦ O facilitador deve manter a conversa modular, abandonando um tópico

apenas depois que tiver sido resolvido.

Princípio 8: Se algo não está claro, desenhe uma figura ◦ Quando as palavras não conseguem deixar algo bem esclarecido,

normalmente, um desenho o faz.

Princípio 9: Quando concordar com algo, prossiga; quando não concordar, prossiga; se algo não está claro e não pode ser esclarecido no momento, prossiga ◦ Prosseguir, às vezes, é a melhor forma de conseguir agilidade na

comunicação.

Princípio 10: Negociação não é um concurso ou um jogo. Funciona melhor quando ambas as partes ganham ◦ Muitas vezes, engenheiros de software e clientes precisam negociar e a

negociação exige compromisso de todos.

Permitem à equipe de software definir um roteiro durante a execução da meta estratégica e dos objetivos táticos;

A falta de planejamento é algo que pode levar um projeto ao caos;

Todos os membros da equipe de software devem participar do planejamento.

Princípio 1: Entenda o escopo do projeto ◦ O escopo fornece à equipe de software um roteiro a seguir.

Princípio 2: Envolva o cliente na atividade de planejamento ◦ O engenheiro de software precisa negociar com o cliente ordem de

entrega, prazos e outros itens do projeto.

Princípio 3: Reconheça que o planejamento é iterativo ◦ Quando o trabalho se inicia, provavelmente, haverá modificações;

◦ Modelos de processos iterativos e incrementais determinam replanejamento, baseado em feedbacks.

Princípio 4: Estime com base no que se sabe ◦ Estimar fornece uma base para se calcular o esforço, o custo e a duração

das tarefas.

Princípio 5: Considere riscos à medida que se define o plano ◦ O plano do projeto deve ser ajustado para acomodar a probabilidade de

um risco vir a ocorrer

Princípio 6: Seja realista ◦ Omissões, ambiguidades e modificações são comuns;

◦ Existem falhas na comunicação entre as pessoas;

◦ As pessoas não trabalham durante todo o dia.

Princípio 7: Ajuste a granularidade à medida que o plano é definido ◦ Granularidade fina – fornece detalhes significativos de tarefas

incrementadas em um curto espaço de tempo;

◦ Granularidade grossa – fornece detalhes significativos de tarefas incrementadas em um longo espaço de tempo.

Princípio 8: Defina como a qualidade será garantida ◦ Se revisões técnicas formais vierem a ser usadas, elas devem ser definidas

no cronograma;

◦ Se a programação em pares vier a ser usada, isso deve ser definido dentro do plano.

Princípio 9: Descreva como as modificações serão acomodadas ◦ O planejamento pode ser comprometido por modificações;

◦ A equipe deve identificar como as modificações devem ser acomodadas durante o projeto.

Princípio 10: Acompanhe o plano com frequência e faça ajustes quando necessário ◦ Acompanhe o progresso do projeto diariamente;

◦ Identifique pontos em que o trabalho programado não está de acordo com o trabalho real conduzido.

Os modelos precisam representar os requisitos em diferentes níveis de abstração (do usuário e do técnico);

Na Engenharia de Software, existem duas classes de modelos: ◦ Modelo de análise e;

◦ Modelo de projeto.

O Modelo de Análise representa os requisitos do cliente sob três domínios: domínio da informação, domínio funcional e domínio comportamental;

O Modelo de Projeto representa características do software que ajudam os profissionais a construir: arquitetura, interface do usuário e componentes.

Princípio 1: O domínio de informação de um problema precisa ser representado e entendido ◦ O domínio da informação abrange os dados de entrada/saída do sistema e

os depósitos de dados.

Princípio 2: As funções a serem desenvolvidas pelo software devem ser definidas ◦ A descrição das funções pode ser de forma genérica ou detalhada.

Princípio 3: O comportamento do software precisa ser representado ◦ O comportamento se dá por meio das suas interações com o ambiente

externo.

Princípio 4: Os modelos que mostram informação, função e comportamento devem ser particionados de um modo que revele detalhes em forma de camadas ◦ Dividir um problema complexo em subproblemas de modo a torná-los mais

fáceis de se compreender.

Princípio 5: A tarefa de análise deve ir da informação essencial até os detalhes de implementação ◦ Um problema é descrito sem considerar como a solução será

implementada;

◦ Já os detalhes da implementação indicam como a solução será implementada.

Princípio 1: O projeto deve estar relacionado ao modelo de análise ◦ O modelo de projeto produz uma arquitetura com vários subsistemas e

projetos em nível de componentes.

Princípio 2: Sempre considere a arquitetura do sistema a ser construído ◦ A arquitetura é o esqueleto do sistema que será construído e afeta:

Interfaces;

Estruturas de dados;

Fluxo de controle;

Forma como o software poderá ser testado e;

Outros

Princípio 3: O projeto de dados é tão importante quanto o projeto de funções de processamento ◦ Um projeto de dados bem estruturado simplifica o fluxo do programa,

facilita a implementação de componentes e otimiza o processamento global.

Princípio 4: As interfaces (internas e externas) precisam ser projetadas cuidadosamente ◦ Interfaces bem projetadas tornam a integração mais fácil e ajuda o testador

durante a validação.

Princípio 5: O projeto de interface do usuário deve estar sintonizado com as necessidades do usuário final. Mas, em cada caso, ele deve enfatizar a facilidade de uso ◦ Mesmo que uma arquitetura esteja bem projetada, se o projeto de interface

for pobre, geralmente, o usuário tem a percepção de que o sistema é ruim.

Princípio 6: O projeto em nível de componente deve ser funcionalmente independente ◦ Um componente deve focar apenas uma função ou subfunção.

Princípio 7: Os componentes devem ser fracamente acoplados uns aos outros e ao ambiente externo ◦ À medida que o acoplamento aumenta, a probabilidade de propagação de

erros também aumenta.

Princípio 8: Representações de projeto (modelos) devem ser facilmente compreensíveis ◦ Se o projeto for difícil de entender, ele não serve como um meio de

comunicação.

Princípio 9: O projeto deve ser desenvolvido iterativamente. A cada iteração o projetista deve focar sempre a simplicidade ◦ As primeiras iterações refinam o projeto e corrigem erros;

◦ Mas, as últimas iterações devem procurar tornar o projeto o mais simples possível.

Contemplam um conjunto de tarefas de codificação e de teste no software que será entregue ao usuário;

A codificação pode ser: ◦ criação direta de código-fonte;

◦ geração automática de código executável.

O foco inicial do teste é nos componentes, também chamado de teste unitário.

Outros tipos de teste são: ◦ teste de integração – é realizado enquanto o sistema está sendo construído;

◦ teste de validação – avalia se o sistema completo atende os requisitos do cliente;

◦ teste de aceitação – é conduzido pelo cliente a fim de utilizar todas as funções necessárias.

Princípios de preparação: Antes de escrever uma linha de código certifique-se de: ◦ entender o problema que está tentando resolver;

◦ entender os princípios e conceitos básicos do projeto;

◦ escolher uma linguagem de programação que satisfaça às necessidades do software a ser construído e do ambiente em que ele vai operar;

◦ selecionar um ambiente de programação que forneça ferramentas para facilitar o trabalho;

◦ criar um conjunto de testes unitários que serão aplicados.

Princípios de codificação: Quando começar a escrever o código, certificar-se de: ◦ usar programação estruturada nos algoritmos;

◦ escolher estruturas de dados que atendam às necessidades do projeto;

◦ entender a arquitetura do software e criar interfaces consistentes com ela;

◦ criar ciclos aninhados que sejam fáceis de testar;

◦ definir nomes significativos para as variáveis;

◦ escrever códigos auto documentados;

◦ códigos devem ser identados.

Princípios de validação: Depois de completar o primeiro passo de codificação, certificar-se de:

◦ inspecionar o código adequado;

◦ corrigir testes unitários e corrigir os erros descobertos;

◦ refatorar o código.

O livro The Art of Software Testing (1979) comenta sobretestes: ◦ Teste é um processo de execução de um programa com a finalidade de

encontrar erros;

◦ Um bom caso de teste é aquele que tem alta probabilidade de encontrar um erro ainda não descoberto;

◦ Um teste bem sucedido é aquele que descobre um erro ainda não descoberto.

Princípio 1: Todos os testes devem estar relacionados aos requisitos do cliente ◦ Do ponto de vista do cliente, um erro severo é aquele no qual o programa

não atende aos seus requisitos.

Princípio 2: Os testes devem ser planejados muito antes de serem iniciados ◦ O planejamento de testes pode começar assim que o modelo de análise for

concluído.

Princípio 3: O princípio de Pareto se aplica ao teste de software ◦ 80% de todos os erros descobertos durante o teste estarão, provavelmente,

relacionados

Princípio 4: O teste deve começar no “varejo” e progredir até o “atacado” ◦ Deve-se procurar identificar erros não apenas em um componente, mas em

um conjunto deles.

Princípio 5: Testes exaustivos não são possíveis ◦ Dependendo da complexidade de um software, é impossível realizar todas

as combinações de teste. Mas, é possível, planejar os testes de modo a atender todos os componentes do software.

Teste de caixa-branca (ou teste de caixa de vidro) ◦ Garante que todos os caminhos independentes

de um módulo tenham sido exercitados

pelo menos uma vez;

◦ Exercita todas as decisões lógicas do lado Verdadeiro e Falso;

◦ Exercita as estruturas de dados internas para garantir a sua validade.

Teste de caixa-preta (ou teste comportamental) ◦ Focaliza os requisitos funcionais do software;

◦ Abordagem complementar aos testes de caixa branca;

◦ Tenta encontrar os seguintes erros de:

funções incorretas ou omitidas;

interface;

estrutura de dados ou acesso ao BD externo;

comportamento ou desempenho;

iniciação e término.

Os modelos modernos de processo de software são evolutivos e, assim, a implantação ocorre mais de uma vez;

Cada ciclo de feedback, depois que o software é entregue, fornece à equipe diretrizes importantes que resultam em modificações no software;

A entrega de um incremento representa um marco importante para qualquer projeto de software.

Princípio 1: As expectativas do cliente quanto ao software devem ser geridas ◦ Frequentemente, o cliente espera mais do que a equipe prometeu entregar

e a frustração é imediata.

Princípio 2: Um pacote completo de entrega deve ser montado e testado ◦ Um CD, DVD ou outra mídia deve ser entregue ao cliente e rigorosamente

testado.

Princípio 3: Um regime de suporte deve ser estabelecido antes de o software ser entregue ◦ Planejamento do suporte;

◦ Preparação de material.

Princípio 4: Materiais institucionais adequados devem ser fornecidos aos usuários finais ◦ Treinamento adequado;

◦ Descrever as diferenças do incremento de software em relação à versão anterior.

Princípio 5: Software defeituoso deve ser corrigido primeiro e, depois, entregue ◦ “Os clientes esquecerão que você entregou um produto de alta qualidade

alguns dias depois, mas eles nunca esquecerão os problemas que um produto de baixa qualidade lhes causou”, ditado no negócio de software.