Disciplina Engenharia de Software

Prof. Rika Luz [email protected] Aula 01

O que é Engenharia de Software?

Segundo Sommerville, Engenharia de software é uma disciplina de engenharia

relacionada com todos os aspectos da produção de software, desde os estágios iniciais de
especificação do sistema até sua manutenção, depois que este entrar em operação.
Nessa definição dada por Sommerville temos duas frases importantes que vamos
discutir a seguir:
✓ Disciplina de Engenharia – É dito uma disciplina, porque os engenheiros estão sempre
aplicando teorias, métodos e ferramentas sempre aonde as mesmas forem mais
apropriadas e usando-as de modo seletivo, além disso, os engenheiros estão sempre
estudando novas maneiras e métodos de solucionar os problemas.

De modo genérico, a prática é uma coleção de conceitos, princípios, métodos e

ferramentas da qual um engenheiro de software faz uso diariamente.
A prática preenche um modelo de processo de software com as receitas técnicas e
gerenciais necessárias para fazer o serviço.

1
Disciplina Engenharia de Software
Prof. Rika Luz [email protected] Aula 01

PRINCÍPIOS CENTRAIS

Existem 7 princípios centrais para a prática da engenharia de software:

O Primeiro Princípio: A razão por que tudo existe

Um sistema de software existe por uma razão: para fornecer valor aos seus usuários.
Todas as decisões devem ser tomadas com isso em mente. A pergunta deve ser feita: Isso
adiciona valor real ao sistema? Se a resposta for não, não faça. Todos os outros princípios se
apoiam nesse.

O Segundo Princípio: KISS (Keep it Simple,Stupid – Mantenha a coisa simples)

Todo projeto deve ser tão simples quanto possível. Isso facilita ter um sistema mais
fácil de entender e de manter, mas não quer dizer que características internas, devam ser
descartadas em nome da simplicidade. Simples também não significa rápido e sujo.

O Terceiro Princípio: Mantenha a Visão

Uma visão clara é essencial para o sucesso de um projeto de software. Ter um
arquiteto fortalecido que possa manter a visão e exige que ela seja respeitada ajuda a garantir
um projeto de software muito bem sucedido.
O Quarto Princípio: O que você produz outros vão consumir

De um modo ou de outro alguém mais vai usar, manter, documentar ou precisará

entender o seu sistema. Assim, sempre especifique, projete e implemente sabendo que mais
alguém terá de entender o eu você está fazendo.

O Quinto Princípio: Esteja Aberto para o Futuro

Os sistemas de software com verdadeira “força industrial” precisam durar muito mais.
Para fazer isso com sucesso, eles precisam estar prontos para se adaptar a essas e outras
modificações. Sistemas que fazem isso com sucesso são aqueles que foram projetados dessa
forma desde o início.

O Sexto Princípio: Planeje com Antecedência o Reuso

Reuso poupa tempo e esforço. O reuso de código e de projetos tem sido proclamado
como um importante benefício do uso de tecnologia orientada a objetos.
Planejar o reuso com antecedência reduz custo e aumenta o valor tanto dos
componentes reusáveis quanto do sistema ao qual será incorporado.

O Sétimo Princípio: Pense!

Raciocinar clara e completamente antes da ação quase sempre produz melhores
resultados. Quando você pensa sobre algo é mais provável que o faça corretamente. Você
também adquire conhecimento sobre como fazê-lo novamente.

2
Disciplina Engenharia de Software
Prof. Rika Luz [email protected] Aula 01

PRÁTICA DA COMUNICAÇÃO

Antes que os requisitos do cliente possam ser analisados, modelados ou especificados,

eles precisam ser coletados por meio de uma atividade de comunicação. O caminho da
comunicação para o entendimento é frequentemente cheio de buracos.

Os princípios da comunicação são:

Princípio 1: Escute
Tente se concentrar nas palavras do interlocutor em vez de na formulação de sua
resposta a essas palavras. Peça esclarecimento se algo estiver obscuro.

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

Gaste tempo em entender o problema antes de se encontrar com os outros, pesquise
a respeito para entender a “linguagem” do usuário.

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

Toda reunião de comunicação deve ter um líder(facilitador) para manter a conversa
se movendo em uma direção produtiva, para mediar qualquer conflito e para garantir que os
outros princípios sejam seguidos.

Princípio 4: Comunicação face a face é melhor

Costuma funcionar melhor quando alguma outra representação da comunicação
relevante é apresentada.

Princípio 5: Faça anotações e documente as decisões

As coisas têm um modo de escorrer por entre os dedos. Alguém que participe da
comunicação deve servir como um registrador e anotar todos os pontos importantes.

Princípio 6: Busque Colaboração

Colaboração e consenso ocorrem quando o conhecimento coletivo dos membros da
equipe é combinado para descrever funções e características do sistema.

Princípio 7: Conserve-se focado, modularize sua discussão

Quanto mais pessoas estiverem envolvidas em uma comunicação, mais
provavelmente aquela discussão vai ficar saltando de um tópico para o outro. O facilitador
deve manter a conversa modular, abandonando um tópico apenas depois que estiver
resolvido.

Princípio 8:Se algo não esta claro desenhe uma figura

A comunicação verbal vai só até um certo ponto, um esboço ou um desenho pode
frequentemente fornecer esclarecimento.

Princípio 9: Prossiga
A comunicação, como qualquer atividade de engenharia leva tempo, requer discussão
e devem prosseguir com a reunião sem se prender a eles nesse momento.

Princípio 10: Negociação

Existem muitas instancias em que os engenheiros de software e os clientes devem

negociar funções e características, isso deve ser feito de modo que ambas as partes saiam
ganhando, assim sendo negociação exige comprometimento de ambas as partes.
3
Disciplina Engenharia de Software
Prof. Rika Luz [email protected] Aula 01

PRATICAS DO PLANEJAMENTO

A atividade de planejamento inclui um conjunto de praticas gerencial e técnicas que

permitem a equipe de software definir um roteiro enquanto ela se move em direção a sua
meta estratégica e seus objetivos táticos.
Em muitos projetos o planejamento excessivo consome tempo e não produz frutos,
mas a falta de planejamento é uma receita para o caos. O planejamento deve ser conduzido
com moderação.
Independente do rigor com o qual o planejamento é conduzido os princípios a seguir
se aplicam:

Princípio 1: Entenda o escopo do Projeto

É impossível usar um roteiro se você não souber para onde está indo. O escopo
fornece a equipe de software um destino

Princípio 2: Envolva o cliente na atividade de planejamento

O cliente que define as prioridades e oferece as restrições do projeto, por isso ele
deve ser envolvido no planejamento.

Princípio 3: Reconheça que o planejamento é iterativo

Um plano de projeto nunca é gravado em pedra. Quando o trabalho tem início, é
muito provável que as coisas se modifiquem, como consequência o plano deve ser ajustado
para acomodar as modificações.

Princípio 4: Estime com base no que é sabido

A intenção de uma estimativa é fornecer uma indicação de esforço, o custo, a duração
de tarefas com base no entendimento atual da equipe quanto ao trabalho a ser feito.

Princípio 5: Considere riscos à medida que você define o plano

Se a equipe tiver definido riscos que têm grande impacto e alta probabilidade, é
necessário planejamento e contingência.

Princípio 6: Seja realista

As pessoas não trabalham 100% do tempo do dia, sempre há ruídos em qualquer
comunicação humana, omissões, ambiguidade.

Princípio 7: Ajuste a granularidade a medida que você define o plano

Granularidade refere-se ao nível de detalhes introduzido à medida que um plano de
projeto é desenvolvido.

Princípio 8: Defina como você pretende garantir a qualidade

O plano deve identificar como a equipe de software pode garantir a qualidade.

Princípio 9: Descreva como você pretende acomodar as modificações

Mesmo o melhor planejamento pode ser comprometido por modificações
descontroladas. A equipe de software deve identificar como as modificações devem ser
acomodadas a medida que o trabalho prossegue.

Princípio 10: Acompanhe o plano com frequência e faça os ajustes necessários

Projetos de software se atrasam um dia de cada vez. Assim faz sentido acompanhar o
progresso diariamente, procurando áreas problemáticas e situações em que o trabalho não
esta de acordo com o programado.
4
Disciplina Engenharia de Software
Prof. Rika Luz [email protected] Aula 01

PRÁTICA DA MODELAGEM

No trabalho de engenharia de software, duas classes de modelos são criadas:

modelos de análise e modelos de projeto. Os modelos de analise representam os requisitos do
cliente mostrando o software em três domínios diferentes: o domínio de informação, o
domínio funcional e o domínio comportamental. Os modelos de projeto representam
características de software que ajudam os profissionais a construí-lo efetivamente: a
arquitetura, a interface com o usuário e detalhes em nível de componentes.

PRINCÍPIOS DA MODELAGEM DE ANÁLISE

Princípio 1: O domínio da informação de um problema precisa ser representado e entendido

O domínio de informação abrange os dados que fluem para dentro do sistema, os
dados que fluem para fora do sistema e os depósitos de dados que coletam e organizam os
objetos de dados persistentes.

Princípio 2: As funções a serem desenvolvidas pelo software devem ser definidas.

As funções do software fornecem benefícios diretos aos usuários finais. Algumas
funções transformam os dados que fluem para dentro do sistema. Em outros casos, as funções
efetuam algum nível de controle sobre o processamento interno do software.As funções
podem ser descritas em vários níveis de abstração diferentes que vão desde uma declaração
geral até uma descrição detalhada.

Princípio 3: O comportamento do software precisa ser representado

O comportamento do software do computador é guiado por suas iterações com o
ambiente externo. Entradas fornecidas pelos usuários finais, dados de controle fornecidos por
um sistema externo ou monitoramento de dados coletados em uma rede, todos fazem com
que o software se comporte de um modo específico.

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.
A modelagem de analise é o primeiro passo na solução de um problema de
engenharia de software. Ela permite que os profissionais entendam melhor o problema e
estabelece uma base para a solução. Um problema complexo, e grande é dividido em
subproblemas. Esse é o conceito chamado de particionamento e é uma estratégia chave na
modelagem de analise.

Princípio 5: A tarefa de análise deve ir da informação essencial até os detalhes de

implementação.
A modelagem de análise começa descrevendo o problema na perspectiva do usuário
final. A “essência” do problema é descrita sem qualquer consideração de como uma solução
será implementada. Os detalhes de implementação indicam como a essência será
implementada.

5
Disciplina Engenharia de Software
Prof. Rika Luz [email protected] Aula 01

PRINCÍPIOS DE MODELAGEM DE PROJETO

O modelo de projeto é equivalente às plantas de engenharia de uma casa. Ele começa

com a representação da totalidade do objeto a ser construído e lentamente refina o objeto.

Princípio 1: O projeto deve estar relacionado ao modelo de análise.

O modelo de projeto traduz essa informação em uma arquitetura: um conjunto de
subsistemas que implementam as funções principais e um conjunto de projetos em nível de
componentes que são a realização das classes de análise.

Princípio 2: Sempre considere a arquitetura do sistema a ser construído.

A arquitetura de software é o esqueleto do sistema a ser construído. Ela afeta as
interface, estruturas de dados, fluxo de controle e comportamento do programa. Por todas
essas razões o projeto deve começar com considerações arquiteturais.

Princípio 3: O projeto dos dados é tão importante quanto o projeto de funções de

processamento.
Um projeto de dados bem estruturado ajuda a simplificar o fluxo do programa e torna
a implementação mais fácil.

Princípio 4: As interfaces precisam ser projetadas com cuidado.

A maneira como os dados fluem entre os componentes de um sistema tem muito a
ver com a eficiência do processamento, a programação de erros e a simplicidade do projeto.

Princípio 5: O projeto de interface do usuário deve estar sintonizado com as necessidades

dos usuários finais.
A interface do usuário é a manifestação visível do software. Não importa quão
sofisticada sejam suas funções interna quão abrangente suas estruturas de dados, quão bem
projetada sua arquitetura, um projeto de interface pobre conduz, muitas vezes, à percepção
de que o software é ruim.

Princípio 6: O projeto em nível de componentes deve ser funcionalmente independente.

A independência funcional é uma medida da objetividade de um componente de
software.

Princípio 7: Os componentes devem ser fracamente acoplados uns aos outros e ao ambiente
externo.
O acoplamento é conseguido de muitos modos – Via interface de componentes, por
mensagem, por meio de dados globais. À medida que o nível de acoplamento aumenta a
probabilidade de programação com erros também aumenta.

Princípio 8: Representação de projeto deve ser facilmente compreendida.

O objetivo do projeto é comunicar a informação para os profissionais que vão gerar o
código, para aqueles que vão testar o código, e para outros que podem vir a manter o
software no futuro, portanto a mesma deve ser de fácil entendimento para todos.

Princípio 9: O projeto deve ser desenvolvido iterativamente. A cada iteração o projetista

deve lutar por maior simplicidade.
Como quase todas as atividades criativas, o projeto ocorre iterativamente. As
primeiras iterações trabalham para refinar o projeto e corrigir erros, mas as últimas iterações
devem procurar tornar o projeto o mais simples possível.

6
 Disciplina Engenharia de Software
Prof. Rika Luz [email protected] Aula 01

PRÁTICAS DA CONSTRUÇÃO

A prática da construção compreende um conjunto de tarefas de codificação e teste

que levam ao software operacional que está pronto para ser entregue ao cliente ou ao usuário
final.
Os princípios e conceitos que dirigem a tarefa de codificação são estilo de
programação, linguagem de programação e métodos de programação rigorosamente
definidos.

Princípios de Preparação.

Antes de escrever uma linha de código certifique-se de:

1. Entender o problema que esta tentando resolver.

2. Entender os princípios e conceitos básicos do projeto
3. Escolher uma linguagem de programação que satisfaça as necessidades do software a ser
construído e do ambiente que vai operar.
4. Selecionar um ambiente de programação que fornece ferramentas para facilitar o seu
trabalho.
5. Criar um conjunto de testes unitários que será aplicado tão logo componente que você está
codificando for completado.

Princípios de codificação:

Quando começar a escrever o código certifique-se de:

1. Restringindo seus algoritmos seguindo a pratica de programação estruturada.

2. Selecionar estruturas de dados que atendam as necessidades do projeto.
3. Entender a arquitetura do software e criar interfaces que sejam consistentes com ela.
4. Conservar a lógica condicional tão simples quanto possível.
5. Criar ciclos aninhados de modo que sejam facilmente testáveis.
6. Selecionar nomes significativos de variáveis e seguir outras normas locais de codificação.
7. Escrever códigos que é auto documentado.
8. Criar uma disposição visual que auxilie o entendimento.

Princípios de validação:

Depois de completar seu primeiro passo de codificação, certifique-se de:

1. Conduzir uma inspeção de código quando adequado

2. Realizar testes unitários e descobrir os erros encontrados
3. Refabricar o código quando necessário.

7
Disciplina Engenharia de Software
Prof. Rika Luz [email protected] Aula 01

PRATICAS DA IMPLANTAÇÃO

A implantação não ocorre uma única vez, mas várias vezes, à medida que o software
caminha para ficar completo.
A entrega de um incremento de software apresenta um marco importante para
qualquer projeto de software. Alguns princípios chave devem ser seguidos à medida que a
equipe se prepara para entregar um incremento.

Princípio 1: As expectativas do cliente quanto ao software devem ser geridas

Muito frequentemente, o cliente espera mais do que a equipe prometeu entregar e o
desapontamento é imediato, isso resulta em feedback não produtivo e arruína o moral da
equipe. Um engenheiro de software deve ser cuidadoso com o envio de mensagens
conflitantes ao cliente.

Princípio 2: Um pacote completo de entrega deve ser montado e testado.

Um CD ou outra mídia contendo todo o software executável, arquivos de dados de
suporte, documentos de suporte e ouras informações relevantes deve ser montado e
rigorosamente testado por testes beta com usuários reais.

Princípio 3: Um regime de suporte deve ser estabelecido antes do software ser entregue.
Um usuário final espera receptividade e informação segura quando uma questão ou
um problema surge. Se o suporte é ad hoc ou, pior, inexistente, o cliente ficará insatisfeito
imediatamente.

Princípio 4: Materiais institucionais adequados devem ser fornecidos aos usuários finais.
A equipe de software entrega mais do que um software em si. Ajuda de treinamento
adequado deve ser desenvolvida, diretrizes de depuração deve ser fornecida e uma descrição
de “o que é diferente nesse incremento de software” deve ser publicada.

Princípio 5: Software defeituoso deve ser corrigido primeiro e depois entregue

Pressionados pelo tempo, algumas organizações de software entregam incrementos
de baixa qualidade com um aviso ao cliente que defeitos serão consertados na versão
seguinte. Isso é um erro.