METODOLOGIA DE PROJETO

PROF. ANDRÉ S. OLIVEIRA

v.0.1a
 Introdução
Visão inicial da metodologia.

Este documento tem como objetivo a apresentação de uma metodologia

padronizada para o projeto de uma solução baseada no estudo das características
do problema. A metodologia apresentada é uma adaptação da empregada pelo
grupo de Sistemas Industriais Inteligentes (S2i, http://s2i.das.ufsc.br) para o
desenvolvimento de software.
A metodologia de projeto aqui apresentada baseia-se em sete etapas;
proposta, requisitos, análise, modelagem, implementação, testes e documentação. O
objetivo da adoção da metodologia é permitir o desenvolvimento rápido e
padronizado de soluções, permitindo a fácil detecção de erros e aumentando a
qualidade do projeto. Onde, são priorizados os aspectos mais relevantes do
problema, de forma a gerar uma solução otimizada. Contudo, a metodologia não
garante o sucesso do projeto. Este será apenas um guia de desenvolvimento para a
adoção das melhores decisões, fazendo com os pontos importantes do sistema sejam
detalhados a cada etapa. A figura 1 apresenta o fluxograma da metodologia de
projeto.

Figura 1 - Fluxograma da metodologia de projeto.

v.0.1a
 Proposta
O que será feito?

As idéias para o desenvolvimento de soluções inovadoras aparecem da

percepção das necessidades de mercados consumidores, seja através de pesquisas
mercadológicas na descoberta de nichos específicos, através da observação do
comportamento do mercado feita pelos próprios membros da equipe de
desenvolvimento, seus parceiros e seus contatos, ou apenas pelo aparecimento de
um problema.
A idéia encontrada para resolver algum problema deve ser escrita de forma
a ser apresentada para os outros membros do grupo, fornecendo uma explicação dos
seus propósitos e objetivos e servindo como uma proposta de trabalho. Alguns
pontos a serem incluídos nesta proposta são:
• Como a idéia poderia ser desenvolvida a partir dos conhecimentos
prévios já adquiridos pela equipe de desenvolvimento e o que ainda
precisa ser aprendido, delineando-se, idealmente, um conjunto de
fases a serem completadas.
• Limitações da solução desenvolvida a partir da idéia, explicitando-se
em que casos a solução desenvolvida pode ser aplicada e em que
casos ela apresentará falhas.
• Benefícios esperados com a implementação da solução. Em outras
palavras, o que é esperado financeiramente, economicamente e em
termos de desempenho com a implementação do sistema ao fim do
projeto.

A idéia deve ser discutida pelo grupo de desenvolvimento e os parceiros do

projeto, verificando-se a viabilidade da implementação do projeto. Se positiva, o
grupo de desenvolvimento (ou parte dele) deve se estruturar de forma a seguir com
as próximas etapas da metodologia de desenvolvimento.

v.0.1a
 Requisitos
O que queremos com o sistema?
O que ele deve fazer?

Nesta etapa, o grupo deve se preocupar em especificar aquilo que realmente

é fundamental para a operação do sistema, sem se preocupar em como vai fazer
para alcançar essas funcionalidades, levando-se em conta as necessidades
levantadas na proposta. Todos os requisitos necessários para a correta operação do
sistema devem ser definidos, tanto do ponto de vista estrutural quanto temporal.
Neste sentido, um documento respondendo as seguintes questões de forma
clara deve ser criado:
• Qual o objetivo do sistema?
• Qual é a situação atual?
• O que já se tem pronto (desenvolvido)?
• Quais são os problemas atuais?
• O que se espera deste sistema
• Que tipo de restrições o sistema deve atender?
• Que entradas e saídas o sistema deve fornecer?
• Quais são as restrições temporais?
• Quais são os outros requisitos?

A cada requisito é importante atribuir-se uma prioridade, em geral baixa,

média ou alta, simbolizando-se assim a quantidade de esforço que será empregado
para que esses requisitos sejam atendidos, de acordo com a seguinte classificação:

• Alta: requisitos essenciais ao projeto e ao funcionamento da solução.

O objetivo do projeto depende diretamente do cumprimento de todos
os requisitos com esta prioridade.
• Média: requisitos desejáveis ao projeto, mas não essenciais. O não
cumprimento destes requisitos não afeta o objetivo do projeto, mas
acarreta uma redução significativa nas funcionalidades da solução.
• Baixa: requisitos desejáveis ao projeto, não essenciais e que estão
ligados a aplicações específicas e especializadas. O não cumprimento
destes requisitos não afeta a funcionalidade da solução, uma vez que
estes requisitos podem ser implementados no futuro, quando e se
necessário.

Em seguida, o documento deverá ser apresentado para a equipe toda, que

irá dar sugestões e aprovará ou não o trabalho para autorizar a nova fase de
desenvolvimento.

v.0.1a
 Análise
Como os requisitos serão atendidos?

Nesta etapa, verificam-se as implicações e conseqüências dos requisitos para

o desenvolvimento da idéia, analisando-os de forma detalhada. Até este momento,
tinha-se apenas uma idéia superficial do que seria necessário para se desenvolver a
idéia proposta. A partir deste ponto, detalha-se como a idéia será desenvolvida de
forma a atender todos os requisitos do projeto.
A estrutura típica desta etapa é a listagem de todos os requisitos definidos
na etapa anterior por prioridade e detalhá-los, mostrando-se a sua importância e
uma possível forma de como atendê-los. É importante, nesta fase, a descrição de
todas as seqüências de tarefas e operações importantes para o sistema utilizando-
se alguma ferramenta, como, por exemplo, fluxogramas, facilitando-se, assim, o
entendimento. Uma boa ferramenta para se montar fluxogramas é o Microsoft
Visio.
Esta análise deve ser apresentada para a equipe toda para críticas,
sugestões e aprovação.

v.0.1a
 Modelagem
Qual será a estrutura do sistema?

Sabendo-se o que deve ser feito e tendo-se os requisitos bem definidos, bem
como uma análise detalhada destes e de como estes podem ser atendidos (ou seja,
tendo-se feito um estudo aprofundado do sistema e de como este deve se comportar
externamente), é necessário agora a especificação de como o sistema será
internamente. Nesta etapa, será definida uma arquitetura que permita que toda a
funcionalidade especificada seja efetivamente implementada. Existem dois
aspectos importantes a se considerar nesta fase, bem como duas sub-etapas.

• Interface: a etapa inicial para se especificar a arquitetura do sistema

é se especificar a interface que o sistema deverá possuir com seus
usuários, ou seja, como ele se apresentará ao mundo externo. Muito
da interface já foi previamente definido pela etapa de requisitos e
análise. A interface define todas as funções que o sistema oferece ao
usuário, definindo tudo o que é permitido ao usuário fazer com o
sistema.
• Arquitetura Interna: para que a interface seja funcional, é necessário
existir uma arquitetura interna que a implemente. Esta arquitetura
é totalmente transparente ao usuário, ou seja, ele não percebe que
ela existe. Esta parte do sistema não interage com o usuário, sendo
apenas utilizada pela interface para que esta forneça suas
funcionalidades.

A especificação da interface com o usuário se faz com o desenho da interface,

tanto para o caso de um software supervisório, quando para o emprego de
interfaces homem-máquina (IHMs). A ferramenta Microsoft Visio é uma opção para
o desenvolvimento de um software supervisório. Entretanto, uma alternativa é a
utilização de um simulador de circuitos eletrônicos, como o Proteus, que pode
auxiliar no desenvolvimento de IHMs, e ainda, permitir a simulação da mesma. A
definição da interface e da arquitetura interna irá servir de estrutura inicial para a
implementação do sistema.
Esta modelagem também será apresentada para a equipe. Somente a após a
aprovação deste, é que o desenvolvimento tem seqüência. Em geral, para sistemas
complexos, dois projetos são necessários: o projeto estrutural e o projeto executivo.

v.0.1a
 Projeto Estrutural

O projeto estrutural é a forma mais pura do projeto. É elaborado sem

considerar as limitações impostas à modelagem pela linguagem de programação
com a qual o sistema será implementado. Aqui se pensa apenas em como se
explorar os recursos da modelagem e seus diagramas, para que o sistema apresente
as funcionalidades requeridas.

Projeto Executivo

O projeto executivo parte do projeto estrutural e o modifica de forma a

superar as limitações impostas pela linguagem de programação, na qual, o sistema
será programado. Aqui, aspectos particulares da linguagem de programação são
levados em conta para tanto facilitar/simplificar a implementação quanto para
permitir que determinados aspectos da modelagem sejam corretamente
implementados.

v.0.1a
 Implementação
Como programar?

Nesta etapa da metodologia de desenvolvimento da solução parte-se do

projeto executivo do sistema e implementa-se a solução a partir desta estrutura de
projeto. As informações reunidas na etapa de análise de requisitos também são
importantes nesta etapa, fornecendo uma visão detalhada de como muitas coisas
serão colocadas em prática.
A utilização de ferramentas para a programação é altamente recomendada.
Bons ambientes de desenvolvimento podem facilitar a tarefa de programação,
integrando compiladores, ligadores, debugadores e ambientes para o
desenvolvimento de interfaces gráficas. Para uma interface de alto nível alguns
ambientes de desenvolvimentos são sugeridos, como: o Borland Builder C++,
WxDev C++ (http://wxdsgn.sourceforge.net/), o Borland Delphi e o Lazarus
(http://www.lazarus.freepascal.org/). Para o desenvolvimento de soluções baseadas
e firmwares, utiliza-se o ambiente de desenvolvimento integrado Mplab IDE (para
soluções em assembly), O Mplab C30 (para a utilização de DSCs empregando a
linguagens C), ambos podem ser obtidos gratuitamente em
http://www.microchip.com.
Uma observação importante aqui é a de que se deve manter o código-fonte
do sistema sempre bem documentado, de acordo com algum padrão definido pelo
grupo (normas de nomenclatura). Além disso, é importante o armazenamento de
versões intermediárias da solução.

v.0.1a
 Testes
Como provar que o sistema funciona?

Estando o sistema desenvolvido, é importante testá-lo de forma que se tenha

certeza de que o seu funcionamento é aquele especificado pelos requisitos. Existem
diversas metodologias para o teste de sistemas de software.
Uma das formas de se fazer isto é através da montagem de um pequeno
protótipo que use o sistema. Assim, cada função que seja parte da interface é
cuidadosamente analisada e o sistema como um todo é colocado em funcionamento
sob condições críticas, como longo tempo de testes. É importante que os testes
sejam especificados anteriormente e que um relatório de testes seja gerado, onde os
programadores descrevem os testes efetuados e os resultados alcançados.
A equipe toda poderá testar o módulo. Posteriormente, a equipe de
desenvolvimento apresenta o relatório de testes para a equipe toda, para a sua
aprovação.

v.0.1a
 Apêndices
Como o sistema foi implementado?

Nesta etapa são armazenadas todas as informações relevantes a como o

sistema foi desenvolvido. Esta é uma das etapas mais importantes de todo o
projeto, pois permite que o sistema seja posteriormente modificado e reaproveitado.
Com a documentação do projeto é possível acabar com dúvidas que possam
surgir na hora de instalar, configurar ou até mesmo utilizar o sistema. Além disso,
caso mudanças necessitem ser feitas por outros colaboradores, este tópico serve
como uma base para solução de problemas que possam acontecer durante o
desenvolvimento ou atualização do sistema.
A documentação também inclui outros aspectos abordados a seguir, como o
cronograma, a equipe, hardware e software, problemas encontrados, correio e
referências bibliográficas.

Cronograma

Com a aprovação da proposta para o desenvolvimento do sistema, a equipe de

desenvolvimento deve planejar quanto tempo será necessário para o desenvolvimento e
testes do sistema. O cronograma deverá apresentar as atividades que serão desenvolvidas e
o tempo que será gasto individualmente e coletivamente para a conclusão da tarefa.
O cronograma também deve ser apresentado à equipe de desenvolvimento para
aprovação.

Equipe

Para o bom e perfeito desenvolvimento das tarefas uma equipe deverá ser
formada. Mesmo que contenha apenas um integrante é necessário que exista um corpo de
decisão e coordenação para cada sistema a ser implementado.
A estrutura para a equipe proposta é a seguinte:

• Desenvolvedores: pessoas envolvidas com o desenvolvimento do sistema.

Em geral são as pessoas que irão programar o sistema e fazer as coisas
funcionar.
• Coordenação: é quem irá supervisionar o trabalho, fornecendo sugestões de
como proceder em situações difíceis.
• Chefe do Grupo: é quem decide sobre as questões de alto nível do projeto,
em geral o seu início e seu fim.

A estrutura da equipe e as informações de contato devem ser descritas nesse tópico.

v.0.1a
 Hardware, Software e Firmware

Neste tópico são listados quais são os requerimentos de hardware, software

e firmware para que o sistema funcione da melhor forma possível. Todo sistema,
possui um lista de requerimentos mínimos que garanta o seu funcionamento de
maneira adequada. Aqui lista-se quais são os requisitos.
• Hardware:
o Características do sistema em que foi desenvolvido.
o Informações técnicas dos componentes.
o Esquemático e Layout.
• Software:
o Ferramentas de desenvolvimento.
o Ajuda e documentação.
o Especificações dos softwares de desenvolvimento.
• Firmware
o Ferramentas de desenvolvimento.
o Ajuda e documentação.
o Especificações das configurações e fluxos alternativos de
execução. Deve ser gerado um fluxograma de execução do
código.

Problemas

Neste tópico são listados todos os problemas que aconteceram durante o

processo de desenvolvimento do sistema. É importante documentar, aqui, todos os
truques utilizados para o desenvolvimento e pontos cuja solução demandou muito
tempo para ser encontrada.

Correios

Durante o processo de desenvolvimento da solução são recebidos e enviados

emails referentes ao tema. Para que todas as informações relativas ao sistema
sejam arquivadas esta seção serve como um arquivo que indica os documentos que
se referem a este projeto.

Referências

Para o desenvolvimento de um bom sistema, vários documentos são lidos e

analisados para facilitar o processo. A fim de facilitar a busca de mais informações
relacionadas ao sistema, uma boa referência bibliográfica é essencial. Para que a
documentação seja perfeita é importantíssimo também apresentar quais foram as
fontes utilizadas para o desenvolvimento da solução. Diversas fontes podem ser
consultadas, e todas devem ser listadas, como, por exemplo, livros, artigos,
periódicos, sítios da Internet, entre outros.

v.0.1a
 Fluxogramas

Os programas podem ser representados por fluxogramas, ou seja, diagramas

que representam a ação do programa a partir de um número limitado de símbolos
que representam as ações básicas que um programa pode fazer.

Um fluxograma consiste num conjunto dessas estruturas ligadas umas às

outras através dos símbolos de conexão. Um mesmo programa pode ser descrito, em
diferentes níveis de detalhe, por diferentes fluxogramas. O uso de fluxogramas no
projeto de softwares e firmwares
irmwares,, da sua concepção inicial ao produto final,
contribui bastante para a obtenção de programas bem-estruturados
bem estruturados e confiáveis.

Os seguintes elementos bastam para representar os programas de

computador como fluxogramas:

Elementos de um fluxograma

Utilizado
para indicar o inicio
e o fim de
um algoritmo.

Indica o
sentido do fluxo.

Símbolo de
ação - indica que
uma ação deve ser
executada.

Símbolo de
decisão - indica que
uma decisão deve
ser tomada.
 As três estruturas de controle de entrada/saída únicas:

1. A estrutura de seqüência: as ações são

executadas, uma por vez, de forma
encadeada, na ordem definida no
programa.

2. A estrutura de seleção: a partir

da verificação de uma condição, o
programa realiza ou não uma
ação e volta à seqüência do
programa.

3. A estrutura de repetição: um bloco de

ações é repetido um número de vezes
conforme se deseje, e após isso o controle
volta à seqüência do programa.

A exigência de que a entrada e a saída de cada estrutura seja única facilita

muito a construção de fluxogramas simples e não limita as possibilidades do que a

v.0.1a
estrutura faz. Um programa estruturado é descrito por um fluxograma formado
pela combinação dessas estruturas de acordo com duas regras de formação apenas,
empilhamento e alinhamento. Um programa estruturado pode ser formado pela
aplicação das seguintes regras:

1) Iniciar com o fluxograma mais simples.

2) Qualquer retângulo (ação) pode ser substituído por dois retângulos em
seqüência. Isso significa que uma ação complexa do fluxograma inicial
pode ser quebrada em ações mais simples, até que se chegue à ação mais
elementar possível.
3) Qualquer retângulo pode ser substituído por qualquer estrutura de
controle. Isso significa que entre as ações representadas no retângulo
inicial podem estar tomadas de decisão
4) As regras 2 e 3 podem ser aplicadas quantas vezes quiser em qualquer
ordem.

Aplicar as regras sempre resulta em um fluxograma estruturado com uma

aparência de blocos de construção. A regra 2 gera uma pilha de estruturas de
controle, e por isso é conhecida como regra do empilhamento. A regra 3 é chamada
de regra de alinhamento pois resulta em estruturas de controle devidamente
aninhadas. A regra 4, por sua vez, gera estruturas maiores.

A aplicação repetida dessas regras, em sucessivos níveis de detalhe,

representa o trabalho de se escrever um programa de computador e seu algoritmo,
da definição inicial do que deve ser feito até o código do programa.

As estruturas de controle de entrada/saída em linguagens de

programação de Alto Nível

As três estruturas de controle de entrada saída únicas podem ser

decompostas em sete diferentes estruturas de controle, que são as seguintes:

SEQUÊNCIA:

Implementada naturalmente na forma que o compilador interpreta o código

escrito do programa.

SELEÇÃO:

Estruturas de seleção, todas redutíveis a estrutura de seleção única básica

da programação estruturada. São elas:

v.0.1a
 Estrutura if (seleção única)

if (condição)
{
bloco de instruções;
}

Se condição for verdadeira, o programa executa o bloco de instruções e

continua para a próxima instrução.

Estrutura if/else (seleção dupla)

if (condição) {
bloco de instruções 1;
}
else {
bloco de instruções 2;
}

Se condição for verdadeira, o programa executa o bloco de instruções 1, e se

for falsa executa o bloco de instruções 2, após o que continua para a próxima
instrução.

v.0.1a
 Estrutura switch (seleção múltipla)

Switch (critério) {
case possibilidade1:
bloco de instruções 1;
break;
case possibilidade2:
bloco de instruções 2;
break;
case possibilidadeN:
bloco de instruções N;
break;

default:
bloco de instruções alternativo;

A estrutura verifica se o valor da variável critério é igual a cada uma das N

possibilidades dadas por possibilidade1, possibilidade2, ... , possibilidadeN, e
executa o bloco de instruções correspondente. Caso critério seja diferente de todas
as possibilidades, o bloco de instruções alternativo é executado. A alternativa
"default" é opcional. Após uma instrução "break" ou após executar a alternativa
"default" o controle segue para a próxima instrução após a estrutura.

v.0.1a
REPETIÇÃO:

A estrutura de repetição geralmente é formalizada em três formas

diferentes:

Estrutura while

while (condição) {
bloco de instruções;
}

O programa verifica a condição e, se for verdadeira, executa a ação do bloco

de instruções, após o que torna a verificar a condição. A execução do bloco de
instruções é repetida até que a condição se torne falsa. Nesse caso, o controle do
programa segue para a primeira instrução após a estrutura.

Estrutura do/while

do {
bloco de instruções;
}
while (condição);

v.0.1a
 Na estrutura do/while,
do/while o programa primeiro executa a ação definida pelo
bloco de instruções e testa a condição. Se for verdadeira, o bloco de instruções é
repetido e a condição é novamente testada. Se for falsa, o programa segue para a
primeira instrução após a estrutura.

Estrutura for

for(expressão1; expressão2;
expressão3)
{
bloco de instruções;
}

Essa estrutura de repetição implementa um contador que irá controlar

quantas vezes a ação será repetida. A (expressão1) define o contador e seu valor
inicial, e a expressão3 incrementa ou decrementa o valor do contador cada vez que
o bloco de instruções é executado. O loop é encerrado quando a condição definida
em expressão2 deixar de ser verdadeira.

v.0.1a