1.

INTRODUÇÃO

A engenharia de software é a ciência e a arte de com economia, em tempo útil e de

forma elegante, especificar, projetar, implementar e manter atualizados e corretos,
programas, documentação e procedimentos operacionais para sistemas computacionais
de utilidade para a humanidade (Alan Brown, Anthony Earl e John McDermid). A
engenharia de software é definida, também, como "aplicação prática do conhecimento
científico no projeto e construção de programas e da documentação requerida para
desenvolver, operar e manter esses programas" (Boehm 80).
O estudo e sistematização do processo de desenvolvimento de software requer
que se conheçam as características do produto desejado e da tecnologia que será
utilizada em seu desenvolvimento.
Este processo é orientado pelo modelo de ciclo de vida, cujas funções primárias
são a de determinar as fases e a ordem das atividades envolvidas no desenvolvimento e
o estabelecimento de critérios para a transição das fases. Estes critérios de transição
incluem a determinação de diretrizes para o começo e a finalização das fases.
Os métodos, por sua vez, podem ser definidos como: "prescrições explícitas para
a realização de uma atividade ou conjunto de atividades do modelo de ciclo de vida"
[Charette 86]. Eles devem refletir um conjunto de diretivas para a aplicação sistemática
de técnicas e instrumentos. As técnicas podem ser definidas como um conjunto de
princípios para execução de uma tarefa específica do processo de desenvolvimento do
software. Os instrumentos tornam possível o uso de métodos e técnicas (Rocha 87),
(Crispim 92).
Este trabalho abordará o processo de desenvolvimento de software em geral,
através da descrição de alguns modelos de ciclo de vida e de alguns métodos de
construção de sistemas.

2. MODELOS DE CICLO DE VIDA

Modelos de ciclo de vida descrevem as etapas do processo de desenvolvimento

de sistemas e as atividades a serem realizadas em cada etapa. A definição dessas etapas
e atividades possibilitam prover marcos e pontos de controle para avaliação da
qualidade e gerência do projeto (Park 91).
O estudo do processo de desenvolvimento provocou o surgimento de várias
propostas de ciclo de vida que incluem desde o simples modelo artesanal de codificar e
consertar (Connors 92), (Pressman 92) até o modelo espiral (Boehm 88).
Inicialmente, o desenvolvimento de software era algo feito em pequena escala
com equipes pequenas ou, até mesmo, apenas com esforço individual. Neste momento,
a ênfase do processo estava na etapa de programação. Neste escopo o desenvolvimento
de software caracterizou-se pelo codificar e consertar, também chamado de
desenvolvimento artesanal ou ad-hoc, que consiste em se partir diretamente para a
codificação, seguida de correção. Esse ciclo é repetido até se completar o projeto
(Connors 92).
O aumento da complexidade e tamanho dos sistemas gerou algumas propostas
de ciclo de vida levando em conta o desenvolvimento de sistemas em grande escala
envolvendo grandes equipes. Isto acarretou uma mudança de enfoque com ênfase no
desenvolvimento de sistemas e não apenas de programas.
 A primeira proposta deu origem ao modelo tradicional ou cascata. Nesse modelo
as fases são executadas sistematicamente de forma seqüencial como ilustrado na figura
1 e normalmente tem as seguintes fases: Análise, Projeto, Construção, Avaliação e
Manutenção (Rocha 87), (Davis 90), (Ghezzi 91), (Pressman 92).

Análise
Projeto
Construção
Avaliação
Manutenção

Figura 1 - Modelo de Ciclo de Vida Clássico ou Cascata

Na fase de análise, também denominada análise de requisitos, são estabelecidos

os requisitos do sistema a ser desenvolvido. Nesta fase, o engenheiro de software
necessita compreender o domínio do problema no qual está trabalhando. Os requisitos e
a modelagem conceitual do sistema são documentados e, posteriormente, revisados pelo
usuário.
A análise de requisitos começa ao se reconhecer que um problema necessita da
tecnologia de informação como solução ou ao surgir uma idéia de um novo negócio ou
de um novo sistema de informação na empresa. Esta fase é concluída ao se ter uma
descrição completa do comportamento do software a ser construído documentado na
Especificação de Requisitos. Nesta fase são realizadas as atividades de análise do
problema, descrição do produto e avaliação da especificação do produto.
O projeto do software é, na realidade, um processo de múltiplos passos que
reforça quatro atributos importantes: estrutura de dados, arquitetura do software, detalhe
procedural e projeto da interface. A fase de projeto tem por objetivo traduzir os
requisitos definidos em uma representação de software com detalhes suficientes para
que possa ser implementado. Como os requisitos, o projeto é documentado
(Especificação de Projeto), sendo este realizado com base na Especificação de
Requisitos. Pode-se verificar que quanto mais refinado (detalhado) for a fase de projeto,
mais clara será a fase de construção.
Na fase de construção, os programas são codificados, as bases de dados criadas e
os módulos do software integrados. Uma vez que o código foi gerado, segue-se a fase
de avaliação da qualidade do software. Esta avaliação deve ser realizada através de
certificação utilizando inspeção, walkthrough, ou prova formal1 ou através de execução
experimental (testes).
Os testes concentram-se em validar os procedimentos lógicos internos do
programa, garantindo que todos os comandos foram testados e que o comportamento
funcional externo do sistema produz os resultados esperados para determinadas entradas
de dados.
_________________
1
Certificações e técnicas de avaliação da qualidade são definidos na seção 4 deste trabalho
 Teste é um elemento crítico no controle da qualidade de software e representa
uma revisão final das fases de análise, projeto e construção. A intenção da realização de
testes é achar erros e para que os testes sejam eficazes é necessário que estes sejam
planejados com seus objetivos claramente definidos. Na análise dos resultados deve-se
procurar identificar a falha que causou o erro evidenciado pelo teste. Testar
exaustivamente e completamente um software nem sempre é possível, por isso os testes
não podem assegurar a correção total de um sistema. Entretanto, a utilização de testes
combinados com algumas técnicas de controle da qualidade contribuem para se obter
um nível aceitável de confiabilidade.
O sistema é entregue ao usuário após se chegar a um resultado satisfatório na
fase de avaliação, com um certo grau de confiança. É claro que o sistema ainda passará
por alterações, devido principalmente a erros observados pelo usuário, ou por mudanças
necessárias para melhor adaptação ao ambiente do usuário, ou por problemas de
desempenho. A manutenção do software pode invocar novamente as outras fases do
ciclo, conforme indicado pelas setas na Figura 1.
O modelo de ciclo de vida evolucionário surgiu propondo um desenvolvimento
que expandisse o sistema gradativamente, permitindo que se obtivessem modelos do
comportamento do software antecipadamente, os denominados protótipos. A
prototipagem é uma forma de desenvolvimento incremental e contém quatro tipos
diferentes: ilustrativo (telas), simulado (acesso ao banco de dados é simulado),
funcional (subconjunto limitado) e evolucionário (começa pequeno e cresce). Os três
primeiros tipos são construídos para se atingir objetivos propostos a priori, sendo
considerados protótipos descartáveis. O protótipo evolucionário se tornará ao final um
produto operacional.
Na figura 2, pode-se observar a seqüência de eventos verificada no paradigma da
prototipagem (Pressman 92). Tal como o processo de desenvolvimento convencional de
software (modelo cascata), a prototipagem se inicia com a etapa de definição dos
requisitos. Todos os objetivos a serem atingidos pelo software são definidos, sendo
identificadas às áreas que merecem uma definição mais refinada.
A partir dos requisitos levantados na fase de definição, um projeto inicial é
construído e apresentado ao usuário, refletindo os aspectos visíveis do software. Este
projeto rápido leva à construção de um protótipo, que será avaliado pelo usuário e usado
para refinar os requisitos do software a ser desenvolvido. O processo de refinamento
dos requisitos traz benefícios para ambas as partes envolvidas no processo de
desenvolvimento do software. O usuário, ao participar do processo de desenvolvimento,
tem condições de contribuir para um maior refinamento dos requisitos, gerando maior
confiança no software em desenvolvimento. Outro benefício é que o desenvolvedor do
software pode compreender melhor o domínio sobre o qual está trabalhando e, a partir
das questões levantadas pelo usuário, bem como suas sugestões, poderá desenvolver um
produto de melhor qualidade e mais próximo ao produto requisitado.
 Início
Fim
Figura 2 -
Definição de
requisitos e
refinamento

Produto Projeto
Final rápido

Construção
Refinamento do
do protótipo
protótipo

Avaliação
do
usuário

Prototipagem (Pressman 92)

A rapidez na construção de um protótipo pode ser obtida com a reutilização de

software e ferramentas que automatizem a geração do protótipo.
Reutilização de software é o processo de desenvolvimento de software cujo
objetivo é utilizar a experiência adquirida e os produtos obtidos anteriormente, para o
desenvolvimento de novos produtos, podendo ser aplicada nas fases de Análise, Projeto,
Construção ou Avaliação. Assim sendo, a reutilização utiliza: código já testado
anteriormente, projetos validados, especificações de requisitos, e/ou planos para testes
(Pressman 92).
A expressão "reutilização de software" indica uma atividade particular no
desenvolvimento do software. As mudanças observadas no ciclo de vida do software são
mostradas na figura 3.

Análise
Projeto
Construção
Avaliação
Manutenção

Repositório

Figura 3 - Ciclo de Vida com Reutilização

 Outra forma de desenvolvimento é caracterizada pelo modelo de síntese
automática (figura 4) que transforma as especificações em programas (Balzer 81),
(Boehm 88), (Bersoff 91), (Connors 92).

Análise
Projeto
Construção
Avaliação
Síntese de
Projeto Manutenção
Síntese de
Projeto e Código

Síntese completa do Software

Figura 4 - Ciclo de Vida com Síntese Automática

O modelo em espiral proposto por Boehm (Boehm 88) mostrado na figura 5,

fornece uma estrutura de trabalho para a produção de software baseada em processo e
níveis de risco permitindo a análise dos riscos em várias etapas do desenvolvimento.
Esse modelo pode ser considerado um meta-modelo, pois podem abranger diferentes
outros modelos, desde o modelo cascata até os vários tipos de protótipos. É um modelo
cíclico.
A análise dos modelos de ciclo de vida pode ser feita considerando-se a
identificação monolítica ou incremental do processo de desenvolvimento. Na estrutura
de trabalho monolítica, os detalhes de cada fase são completados em sua totalidade,
antes do início da etapa seguinte. Sendo assim, o comportamento do software só pode
ser avaliado no final do desenvolvimento. Na estrutura incremental, os detalhes podem
ser retardados com o benefício de se produzir antecipadamente um protótipo mostrando
o funcionamento do produto (Connors 92).
 Figura 5 - Modelo Espiral (Boehm 88)

3. MÉTODOS DE DESENVOLVIMENTO

Na literatura de engenharia de software (Ross 77), (Yourdon e Constantine 78),

(Page-Jones 80), (Chandersekaran e Linder 81), (Jackson 83), (Ward e Mellor 85),
(Booch 86), (Warnier 86), (Chen 87), (De Marco 89), (Jones 90), (Yourdon 90), (Hatley
e Pirbhai 91), (Coad 92), encontramos diversas propostas de métodos que podem
atender diferentes paradigmas (dados, funções, objetos), para diversos domínios de
aplicação, com rigor de expressão diferente e aplicação em fases específicas.
Esses métodos apóiam os desenvolvedores de software na análise e
documentação do problema provendo um mecanismo de abstração, particionamento e
representação do problema a ser desenvolvido pelo sistema.
A fase de análise de requisitos é de suma importância no desenvolvimento de um
sistema, pois é a base para o desenvolvimento do software. Outro aspecto a considerar é
que o custo de correção de um erro encontrado nas fases posteriores à fase de projeto é
muito maior (2 a 40 vezes mais). Hoje em dia sabe-se que muitos erros (mais de 50%)
são cometidos na fase de análise e que estes podem ser facilmente detectados. As
consequências de não se detectar os erros nas fases de análise e projeto acarretam na
não satisfação do usuário, desentendimento entre os envolvidos, perda de tempo e
dinheiro e em até problemas jurídicos.
Por isso, os métodos de construção mais difundidos nos diferentes paradigmas e
as técnicas de elicitação dos requisitos serão abordados. Estas técnicas facilitam a
comunicação entre usuários e desenvolvedores, sendo fundamental principalmente por
ser a fase de análise uma atividade que requer uma intensa comunicação entre as partes
envolvidas.
 3.1 SADT

SADT (Structured Analysis and Design Technique) foi desenvolvido no início

dos anos 70 por Ross, sendo utilizado inicialmente pela U.S. Air Force e pela ITT
européia (Ross e Schoman 77), (Ross 85).
A estrutura de trabalho do SADT utiliza a técnica top-down onde o desenvolvedor inicia
representando o sistema a nível macro (diagrama de contexto), e depois refina
repetidamente cada diagrama representando um aspecto do sistema num nível mais
detalhado. Uma especificação com SADT é uma representação gráfica da estrutura
hierárquica do sistema. SADT permite a modelagem em termos de função e de dados,
possuindo como instrumentos um diagrama de atividades e um diagrama de dados
onde as atividades e os dados são representados através de retângulos e setas. Uma
definição sucinta deste método pode ser encontrada em (Rocha 87) e (Davis 90).

3.2 MÉTODOS ESTRUTURADOS

Os métodos conhecidos como estruturados são Análise Estruturada (DeMarco

89), Projeto Estruturado (Yourdon e Constantine 78), (Page-Jones 80), Análise Essencial
(Análise Estruturada Moderna) (McMenamim e Palmer 91), (Yourdon 90), Análise
Estruturada para Sistemas de Tempo Real (Ward e Mellor 85), (Hatley 87).
A Análise Estruturada foi desenvolvida por Gane (Gane 77) e DeMarco
(DeMarco 78) e está intimamente relacionada ao método de projeto desenvolvido por
Constantine e Yourdon, denominado Projeto Estruturado (Yourdon 78).
A Análise Estruturada consiste de um conjunto de técnicas e instrumentos com o
objetivo de auxiliar na análise e definição do sistema. Este método é similar ao SADT.
Utiliza uma linguagem gráfica e fornecendo uma visão top-down e particionada do
sistema. A Análise Estruturada é composta dos seguintes instrumentos:
 Diagrama de Fluxo de Dados, que representa o sistema como uma rede de
processos interligados entre si por fluxos de informação e depósitos de
dados.
 Dicionário de Dados que contém a definição dos dados utilizados no DFD.
 Especificação de Processos que define a lógica dos processos representados
no DFD.
No final dos anos 80, a Análise Estruturada havia sido aplicada nos mais
variados tipos de problemas (Davis 90). Entretanto, alguns problemas foram
encontrados e a Análise Essencial (McMenamin 84) surge definindo alguns conceitos e
facilitando a modelagem conceitual do sistema:
 Essência do Sistema ou Requisitos Essenciais é o conjunto de requisitos
verdadeiros, ou seja, requisitos que o sistema deve possuir para atingir o seu
propósito.
 Requisitos Falsos são aqueles requisitos que o sistema não necessita para atingir
seu propósito. Estes requisitos podem ser tecnológicos ou arbitrários.
  Tecnologia Perfeita é definida como a tecnologia que não possui limitações
físicas.
 Eventos e Respostas: um evento é uma mudança no ambiente externo que o
sistema deve responder e respostas é um conjunto de ações executadas pelo
sistema ao ocorrer um evento.
 Essência do sistema é composta de atividades essenciais e da memória essencial.
A atividade essencial é aquela que o sistema deve executar para atingir o seu
propósito utilizando uma tecnologia perfeita. Memória Essencial são os dados
armazenados pelo sistema para executar as atividades essenciais.
 Encarnação da Essência é um termo utilizado para representar a materialização
dos conceitos contidos no sistema, ou seja, o processo de desenvolvimento de
sistemas é redefinido nas seguintes etapas: definição da essência do sistema
(análise), seleção de uma encarnação da essência (escolha da tecnologia
utilizada) e projeto da implementação (projeto).
Esses conceitos possibilitaram algumas modificações na Análise Estruturada,
surgindo a denominada Análise Estruturada Moderna (Yourdon 90). Essas mudanças
reconhecem que:
 a construção da modelagem física e lógica da situação atual pode paralisar, isto
é, pode acarretar uma produtividade muito baixa na fase de análise;
 a estrutura top-down pura não é boa para sistemas complexos, podendo
introduzir decisões de implementação na fase de análise;
 os diagramas de entidade e relacionamento são extremamente válidos para
capturar a complexidade dos dados e seus relacionamentos.
O processo de modelagem da Análise Estruturada foi alterado para uma estrutura
outside-in, onde se define primeiro o contexto do sistema em relação ao seu ambiente
(definição de seus eventos externos). E a seguir, para cada evento é definido o
comportamento interno do sistema e criado o modelo comportamental que é composto
de: DFD’s particionados por eventos, hierarquia de DFD’s, Diagrama de Entidade e
Relacionamentos, Dicionário de Dados e Especificação de Processos.
Algumas aplicações são dependentes do tempo e por isso necessitam processar
informações sobre controle. Algumas extensões foram propostas para a Análise
Estruturada se adequar a sistemas de tempo real (Ward 85), (Hatley 87). Esses métodos
introduzem um novo diagrama, o Diagrama de Transição de Estados, que apresenta as
mudanças ocorridas no sistema dependentes do tempo. O conceito de fluxo de controle
é também introduzido, pois este não contém informação e sim um controle que dispara
um processo do sistema.
O Projeto Estruturado foi desenvolvido no início dos anos 70 por Constantine e
Yourdon (Yourdon e Constantine 78), (Page-Jones 80) e estabelece um conjunto de
características de qualidade de um bom projeto (coesão e acoplamento) e uma
linguagem para construir gráficos de estrutura. O objetivo do Projeto Estruturado é
projetar a arquitetura do sistema e de programas como estruturas de módulos de função
únicas e independentes. Esse método é utilizado na fase de projeto, principalmente ao
modelar o sistema com Análise Estruturada.
 3.3 MODELAGEM DE DADOS

O modelo de dados conceitual mais usado é o Modelo de Entidades e

Relacionamentos (MER) desenvolvido por Chen em 1976 (Battini 92) e adotado em
1988 como modelo de dados padrão pela ANSI.
O MER utiliza um diagrama (Diagrama de Entidades e Relacionamentos, DER)
que contém uma estrutura simples e um conjunto de conceitos restritos:
 entidades são qualquer objeto do mundo real sobre o qual se deseja guardar
informações;
 atributos são as informações sobre as instâncias de entidades, podendo ser
propriedades, fatos ou características das entidades;
 relacionamentos entre entidades é definido quando a informação desejada de
uma entidade A diz respeito a uma entidade B e a recíproca é verdadeira. Assim
existe um relacionamento entre a entidade A e B;
 generalização/especialização define um conjunto de entidades que representam
objetos do mundo real que se subdividem em categorias com atributos
parcialmente distintos. Este foi um conceito introduzido em algumas extensões
do MER;
 agregação é utilizada ao se necessitar relacionar um conjunto de entidades e um
conjunto de relacionamentos. O mecanismo de agregação define uma nova
classe a partir de um conjunto de outras classes que representam seus
componentes, ou seja, suas partes. Este também é um conceito introduzido,
posteriormente, em algumas extensões do MER.

O MER é um modelo bastante elogiado, mas existem também críticas. O conjunto

de conceitos incorporados no seu diagrama é uma vantagem, pois provê um modelo
poderoso de descrição da realidade. Entretanto, essa mesma simplicidade é criticada,
pois alguns detalhes não podem ser plenamente documentados no modelo. Outra crítica
é a de não existir um procedimento definido para construção do modelo (Batini 92).

3.4 MÉTODOS ORIENTADOS A OBJETOS

O conceito de Orientação a Objetos (OO) no desenvolvimento de software tem sua

raiz na linguagem Smalltalk. Nessa estrutura, os átomos da computação são objetos que
mandam mensagens entre si. Essas mensagens resultam na invocação de métodos, que
desempenham as ações necessárias. O objeto que envia a mensagem não necessita
conhecer como o objeto está organizado internamente, somente a resposta do objeto,
isto é, a mensagem específica enviada por esse objeto e seu formato (Colleman 94).
Objetos são grupados em classes quando elas compartilham a mesma interface,
respondem as mesmas mensagens da mesma forma. Isto permite que vários objetos
possam ser descritos em poucas classes. O modelo é dinâmico, pois quando o sistema
executa, objetos passam a existir, desempenham ações e depois cessam de existir ou
tornam-se inacessíveis. Objetos e classes de objetos possuem atributos, sendo que todos
os objetos de uma classe herdam os atributos das classes de que eles são membros.
Algumas vantagens da Orientação a Objetos são apontadas, tais como, flexibilidade,
reuso, extensibilidade e manutenibilidade. A abstração de dados, também é considerada
uma vantagem, pois detalhes da representação das classes são visíveis somente para
seus métodos, permitindo que diferentes implementações de uma classe possa ser usada
sem modificação do código (Colleman 94).
 Entretanto, alguns problemas também são mencionados: dificuldade de identificar
objetos e classes, necessidade de mudanças no gerenciamento do projeto e falta de
suporte para o trabalho em grupo (Colleman 94).
Na literatura existem várias propostas de métodos de análise e projeto orientado a
objetos: OOA/OOD (Object Oriented Analysis/ Object Oriented Design) de Coad e
Yourdon (1992), OMT (Object Modeling Technique) de Rumbaugh et alli (1991), e
OOIE (Object Oriented Information Engineering) de Martin e Odell (1992).
O método Fusion (Colleman 94) é um método para desenvolvimento OO
considerado de segunda geração que se baseou em outros métodos previamente
definidos. Ele provê suporte para três fases:
 Análise, no qual identifica objetos e classes do sistema, descreve seus
relacionamentos e define as operações que o sistema deve desempenhar.
 Projeto, onde se decide como representar as operações do sistema através da
interação com os objetos relacionados e como esses objetos ganham acesso entre
si.
 Implementação, onde se codifica o projeto em uma linguagem de programação.
UML é uma linguagem padrão para modelagem orientada a objetos. Ela surgiu
da fusão de três métodos, do BOOCH, OMT (Rumbaugh et al) e do Jacobson. E
é adotada como padrão para desenvolvimento orientado a objetos.

Bibliografia:

1) http://www.ime.uerj.br/~vera/projeto/apostila.pdf

2) http://www.inf.pucrs.br/~lleite/seII/material/ciclodevida.pdf

3) http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida

4) http://imasters.uol.com.br/noticia/1861/gerencia/modelos_de_ciclo_de_vida_por
_que_precisamos_deles_no_desenvolvimento/