universidade federal fluminense roberto · pdf fileuniversidade federal fluminense roberto...
TRANSCRIPT
UNIVERSIDADE FEDERAL FLUMINENSEROBERTO SOUZA YACOUB JUNIOR
CICLO DE VIDA DE UM SOFTWARE: UM CASO DE ESTUDO DE UMA EMPRESA IMOBILIÁRIA
Niterói2008
ROBERTO SOUZA YACOUB JÚNIOR
CICLO DE VIDA DE UM SOFTWARE:UM CASO DE ESTUDO DE UMA EMPRESA IMOBILIÁRIA
Trabalho de Conclusão de Curso subme-
tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do Titilo de Tecnólogo
em Sistemas de Computação.
Orientador:
LEANDRO SOARES DE SOUSA
NITERÓI2008
ROBERTO SOUZA YACOUB JÚNIOR
CICLO DE VIDA DE UM SOFTWARE:UM CASO DE ESTUDO DE UMA EMPRESA IMOBILIÁRIA
Trabalho de Conclusão de Curso subme-
tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do Título de Tecnólo-
go em Sistemas de Computação.
Niterói, ___ de _______________ de 2008.
Banca Examinadora:
_________________________________________
Leandro Soares de Sousa, Msc. – Tutor Orientador
UFF - Universidade Federal Fluminense
_________________________________________
Talita de Oliveira Ferreira, Msc. – Avaliador
UFRJ – Universidade Federal do Rio de Janeiro
Dedico este trabalho a meus Avós que me
proveram estadia e cuidados durante as se-
manas de provas em Três Rios.
AGRADECIMENTOS
A Deus, que sempre colocou obstáculos na
minha vida e me proveu forças para removê-
los.
A meu Orientador Leandro pela paciência e
atenção que me concedeu durante o trabalho.
Aos Meus filhos e esposa pelo entendimento
e aceitação da minha ausência nos momen-
tos de estudo e avaliações.
A minha mãe por ter me apresentado o CE-
DERJ e incentivado a volta aos estudos.
“A inteligência não está em deter o conheci-
mento, mas sim em saber usá-lo”.
Roberto Yacoub
RESUMO
Considerando a evolução da informática nos últimos vinte anos, propo-mos, neste trabalho, apresentar o ciclo de vida de um software idealizado no final da década de 80 e que se mantém no mercado até hoje, quase 20 anos depois, ainda em seu estágio de maturidade. No texto escrevemos como a evolução tecnológica e as mudanças no mercado afetaram e afetam esse sistema, bem como sugestões para futuras implementações e evoluções.
Palavras-chaves: ciclo de vida, evolução e FoxPro.
LISTA DE ILUSTRAÇÕES
Figura 3.1: Hierarquia de um Processo do Ciclo de Vida..........................19
Figura 3.2:Fases do Ciclo de Vida (Fonte: ABNT [4])...............................20
Figura 3.3: Relacionamento entre as fases (Fonte: ABNT [3])..................21
Figura 3.4: Visão de todo o processo (Fonte: ABNT [3])...........................22
Figura 4.5: Primeiro Diagrama do Sistema................................................27
Figura 4.6: Topologia da Primeira Rede....................................................31
Figura 4.7: Arquitetura do Sistema Atual...................................................35
Figura 4.8: Tela da Versão Atual (Sistema em Modo Consulta Locatário)
.....................................................................................................................................36
Figura 4.9: Tela da Versão Atual (Sistema em Modo Consulta Caixa).....37
Figura 4.10: Tela da Versão Atual (Sistema em Modo Consulta Adminis-
trativo)..........................................................................................................................38
Figura 4.11: Tela da Versão Atual (Sistema em Modo Consulta Devolu-
ção)..............................................................................................................................39
Figura 4.12: Tela da Versão Atual (Sistema em Modo Anúncio)..............40
Figura 4.13: Tela da Versão Atual (Sistema em Modo Jurídico)...............41
Figura 4.14: Diagrama da disposição de equipamentos...........................42
Figura 4.15: Foto do Ambiente de Trabalho da Empresa Imobiliária........43
Figura 4.16: Foto da fachada da empresa com as suas 3 lojas................44
LISTA DE TABELAS
Tabela 1: Produtividade da Empresa com a Introdução e Evolução do SCI
.....................................................................................................................................50
LISTA DE GRÁFICOS
Gráfico 3.1: Ciclo de Vida..........................................................................26
LISTA DE ABREVIATURAS E SIGLAS
SCI – Sistema de Controle Imobiliário
CLIPPER – Linguagem de programação
FOXPRO – Linguagem de programação
DBF – Data Base File
DOS – Disk Operating System
POO – Programação Orientada a Objetos
DER – Diagrama de Entidade e Relacionamento
EPC - Event-Driven Process Chain
SUMÁRIO
RESUMO ..................................................................................................... 7
LISTA DE ILUSTRAÇÕES .......................................................................... 8
LISTA DE TABELAS ................................................................................... 9
LISTA DE GRÁFICOS ............................................................................... 10
LISTA DE ABREVIATURAS E SIGLAS .................................................... 11
1 INTRODUÇÃO ........................................................................................ 13
2 O CONTEXTO ......................................................................................... 15
2.1 A Empresa ......................................................................................................... 16
2.2 O PROBLEMA ................................................................................................... 16
2.3 A Solução ........................................................................................................... 17
3 Ciclo de vida de um software ................................................................. 18
3.1 PROCESSOS FUNDAMENTAIS ...................................................................... 23
3.2 PROCESSOS DE APOIO .................................................................................. 24
3.3 PROCESSOS ORGANIZACIONAIS ................................................................. 25
4 O PRODUTO ........................................................................................... 27
4.1 versão inicial ...................................................................................................... 27
4.2 Evolução do produto .......................................................................................... 29
4.3 Versão Atual ...................................................................................................... 35
5 O Futuro .................................................................................................. 46
5.1 Evolução do sistema .......................................................................................... 46
5.2 Aprimoramentos nas tÉcnicas de desenvolvimento .......................................... 46
5.3 Uma visão de negócios ..................................................................................... 47
CONCLUSÕES ......................................................................................... 50
REFERÊNCIAS BIBLIOGRÁFICAS .......................................................... 52
1 INTRODUÇÃO
Este trabalho tem como objetivo apresentar o ciclo da vida (nascimento,
maturidade, senectude e inevitável morte) de um sistema computadorizado produzi-
do a cerca de 20 anos pelo próprio autor. O software em questão foi desenvolvido
em uma empresa do setor imobiliário na qual fui estagiário no final dos anos 80. O
estágio nesta empresa ocorreu devido a conclusão do curso de técnico em informáti-
ca industrial, pelo colégio técnico Universitário da UFJF (Universidade Federal de
Juiz de Fora), que em seus requisitos acadêmicos incluía um estágio.
Hoje, o mesmo software ainda é utilizado por este mesmo cliente, porém,
com o passar do tempo, ele cresceu e se transformou em um sistema mais abran-
gente e complexo. Vimos então a oportunidade de, na conclusão do curso de gradu-
ação pelo CEDERJ, expor as diferenças entre as técnicas da época e as atuais, bem
como evidenciar a diferença na abordagem dos problemas por um técnico e, agora,
por um profissional de nível superior.
Antes de prosseguirmos no texto devemos apresentar um conceito para o
ciclo de vida de um produto, que segue abaixo:
“Em termos de produto material tem como definição para ciclo de vida o conjunto de transformações que um produto sofre desde de sua idealização até o momento que é descontinuado”. (texto extraído do sítio http://pt.wikipe-dia.org/wiki/Ciclo_de_vida, 19-Maio-2008).
O modelo de ciclo de vida do produto pode auxiliar na análise do estágio
de maturidade de um produto, todavia não serve como parâmetro para seu sucesso
ou fracasso. Embora saibamos que quanto maior for o tempo de permanência na
sua fase de maturidade maior será sua possibilidade de sucesso.
13
Os produtos atualmente têm ciclos de vida cada vez mais curtos e muitos
produtos, em indústrias maduras, são revitalizados através da diferenciação e da
segmentação do mercado alvo. No caso do produto, aqui apresentado, nossa
abordagem foi de uma revitalização evolutiva, com o objetivo de manter o produto
durante o maior tempo possível em sua fase de maturidade.
Este trabalho foi organizado da seguinte forma:
• no capítulo 2 apresentamos a empresa, o problema e a solução
encontrada;
• no terceiro capítulo abordamos alguns aspectos do ciclo de vida,
com suas fases e processos;
• o quarto capítulo descreve o produto propriamente dito;
• no quinto capítulo mostraremos as possíveis alterações visando o
futuro; e
• finalmente, no Capítulo 6, apresentamos as conclusões do trabalho.
14
2 O CONTEXTO
Um modelo de ciclo de vida define o estado e as fases nas quais se movi-
menta um projeto de desenvolvimento de software. O primeiro modelo de ciclo de
vida para um software, conhecido por modelo em “cascata”, foi definido por Winston
Royce [6] no final da década de 70, quando muitas equipes de desenvolvimento o
adotaram como ciclo de vida padrão, o mesmo reinou absoluto por cerca de 10
anos. Porém, este modelo foi alvo de numerosas críticas devido às restrições e difi-
culdades no desenvolvimento de software, principalmente no que tange o fator tem-
po, que é crítico nesta atividade. Em seu lugar apareceram muitos modelos, que pro-
punham um desenvolvimento mais ágil que atuavam de forma incremental e evoluti-
va, tais como incremental espiral e RAD [7].
De forma a nos situarmos no tempo, devemos observar que a tecnologia
da época era muito restrita e incipiente, principalmente quanto aos recursos de pro-
cessamento comparados aos atuais, não nos esqueçamos de que estamos falando
do final da década de 80. A disponibilidade de recursos humanos era muito peque-
na, visto que não existiam no Brasil profissionais de informática em quantidade e
com formação específica para desenvolver esta atividade. Naquela época, normal-
mente, o desenvolvimento de software era efetuado por um engenheiro ou por al-
gum profissional de outra área afim, que aprendeu de alguma forma esta atividade,
assim sendo, a utilização de técnicas e modelos de desenvolvimento era algo quase
impraticável.
Neste contexto nasceu o software SCI (Sistema de Controle Imobiliário),
cujo desenvolvimento utilizamos como exemplo neste trabalho, que foi criado da ne-
cessidade de automação das funções de administração de uma imobiliária de médio
porte.
15
Nas próximas subseções apresentamos a empresa e suas necessidades,
visando estabelecer o contexto no qual este sistema foi desenvolvido.
2.1 A EMPRESA
No final da década de 80 o mercado imobiliário estava em contração en-
quanto o de informática começava a se expandir, esta expansão foi devido à possibi -
lidade da queda da Lei de Reserva de Mercado para a Informática, cujo término efe-
tivamente ocorreu em 1991. Este fato proporcionou às empresas, notadamente de
pequeno e médio porte, a possibilidade do acesso a estas novas tecnologias. Essas
empresas começaram a automatizar processos repetitivos, que eram, até então, rea-
lizados manualmente por seus funcionários.
A empresa em questão contava com quatro funcionários para administrar
cerca de 250 imóveis. Neste momento, todos os procedimentos administrativos eram
manuais, desde a emissão de recibos até contratos de locação de imóveis e, ainda,
sua conta corrente bem como os extratos para os clientes.
2.2 O PROBLEMA
A maior dificuldade, na época, era de contratar mais funcionários para po-
der administrar uma quantidade maior de imóveis, observado o contexto no qual o
mercado se encontrava, ou seja, em recessão.
A solução encontrada foi de automatizar certos processos reduzindo o en-
volvimento dos funcionários e, como conseqüência, aumentado a produtividade e a
confiabilidade do serviço prestado.
16
2.3 A SOLUÇÃO
A solução para os problemas relatados foi o desenvolvimento de um pro-
duto, que deveria atender de forma incisiva aos anseios dos clientes, ou seja, reduzir
o tempo de geração e impressão dos recibos, calcular os valores das contas corren-
tes, atualizar o cadastro dos imóveis, imprimir contratos e documentos bem como
manter estas informações em uma base de dados ao alcance dos usuários.
Este produto e sua evolução foram detalhados no Capítulo 4.
17
3 CICLO DE VIDA DE UM SOFTWARE
Neste capítulo, introduzimos alguns aspectos do ciclo de vida de um
software que servem como base para a descrição do produto e de sua evolução.
Atualmente, o mercado demanda pela produção de software em larga es-
cala e com custos reduzidos. Para alcançar estes objetivos de forma segura e efici-
ente, novas técnicas foram desenvolvidas e, em sua maioria, tiveram origem na en-
genharia. Este conjunto de técnicas e metodologias foi designado por Engenharia de
Software, que visa aumentar a produtividade e qualidade em todos os aspectos que
fazem parte da atividade de desenvolver software.
O desenvolvimento e a manutenção de software são tarefas novas e, por
não seguirem regras de produção bem definidas, como nas demais engenharias,
sempre deixavam muito a desejar. Os principais insatisfeitos eram os usuários dos
sistemas que, muitas vezes, não viam seus anseios totalmente correspondidos. Es-
tas dificuldades aumentaram os custos de desenvolvimento de forma significativa e,
conseqüentemente, reduziram a lucratividade das empresas desenvolvedoras de
software. A normalização e normatização do processo de desenvolvimento de
software, introduzidas pela Engenharia de Software através da definição dos mode-
los de Ciclo de Vida, foram fatores importantes para reduzir esta “tensão” entre os
dois principais envolvidos: o cliente e o fornecedor de produtos de software. Os mo-
delos de Ciclo de Vida para o desenvolvimento de software tornaram o processo
mais claro e acessível para ambas às partes. Isto facilitou a interação entre os envol-
vidos e simplificou o controle de todo o processo.
18
O ciclo de vida de um software pode ser subdividido em três tipos de pro-
cessos: os fundamentais, os de apoio e os organizacionais. Antes de detalharmos
esta subdivisão, devemos esclarecer que os processos são compostos por um con-
junto de atividades. Estas atividades são compostas por tarefas. A hierarquia que
compõe um processo é representada na Figura 3.1, apenas para fins ilustrativos.
Figura 3.1: Hierarquia de um Processo do Ciclo de Vida
Um processo é definido pelas suas atividades e cada atividade é adicio-
nalmente definida pelas suas tarefas, sendo que cada atividade é subordinada a um
processo, que é um conjunto de tarefas intimamente ligadas. Uma tarefa é um requi-
sito, uma declaração própria, uma recomendação ou uma ação permissível, ou seja,
são os elementos básicos que compõem o processo, como descrito em [5].
19
Na Figura 3.2 apresentamos a hierarquia dos três processos que definem
o ciclo de vida de um software, nela incluímos apenas até o nível das atividades
para facilitar a visualização.
Figura 3.2:Fases do Ciclo de Vida (Fonte: ABNT [4])
20
Na Figura 3.3, podemos observar os relacionamentos entre as fases do
ciclo de vida de um software. As ligações entre os objetos correspondem às respon-
sabilidades de cada parte com o seu respectivo responsável, bem como o grau de
dependência e acoplamento entre elas.
Figura 3.3: Relacionamento entre as fases (Fonte: ABNT [3])
21
Na Figura 3.4 temos uma visão geral de todo o processo. Como esta é
uma visão macroscópica ela abrange todos os processos e atividades, detalhados
nas próximas subseções.
Figura 3.4: Visão de todo o processo (Fonte: ABNT [3])
22
3.1 PROCESSOS FUNDAMENTAIS
Os processos fundamentais começam com o levantamento das informa-
ções e a execução, propriamente dita, do desenvolvimento, operação ou manuten-
ção de produtos de software, como descrito na seqüência:
i. Processo de Aquisição: define as atividades do ad-
quirente, organização que adquire um sistema ou produto de software,
inclui também a emissão de pedido de proposta, seleção de fornecedor
e gerência do processo de aquisição.
ii. Processo de Fornecimento: define as atividades
do fornecedor, organização que provê o produto de software ao adqui-
rente, ou seja, determina os procedimentos e recursos necessários para
gerenciar e garantir o projeto, o desenvolvimento e a execução dos pla-
nos do projeto até a entrega do sistema, ou seja, o software para o ad-
quirente.
iii. Processo de Desenvolvimento: define as ativida-
des do desenvolvedor, organização que define e desenvolve o produto,
que contém as atividades para análise de requisitos, projeto, codificação
integração, testes, instalação e aceitação relativas ao software.
iv. Processo de Operação: define as atividades do
operador, ou seja, organização que provê serviço de operação de um
sistema computacional no seu ambiente e para seus usuários, bem
como cobrar, também, o suporte operacional.
v. Processo de Manutenção: define as atividades do
mantenedor, organização que provê os serviços de manutenção do
software, ou seja, os serviços de manutenção para deixar o software de
23
alguma forma atualizado. Seu objetivo é modificar um produto de
software existente, preservando a sua integridade.
3.2 PROCESSOS DE APOIO
Estes processos servem de auxílio para algum processo. Desta forma,
contribuem para o sucesso e qualidade do projeto de software, são empregados e
executados, quando necessário, por outro processo. Estes processos são definidos
na seqüência:
i. Processo de documentação: define as atividades para registro das infor-
mações geradas por um processo ou atividade do ciclo de vida.
ii. Processo de Gerência de Configuração: define as atividades para a
aplicação de procedimentos administrativos e técnicos, por toda a vida do
software, identifica e define os itens de software em um sistema, bem
como estabelece suas linhas básicas.
iii. Processo de Garantia da Qualidade: define as atividades para fornecer
a garantia adequada para que o software esteja de acordo com seus re-
quisitos previamente especificados.
iv. Processo de Verificação: define as atividades para verificação se os pro-
dutos de software atendem completamente os requisitos impostos a eles.
v. Processo de Validação: define se os requisitos do produto final atendem
ao uso especifico proposto.
24
vi. Processo de Revisão Conjunta: define as atividades necessárias para
avaliar a situação e produtos de uma atividade de um projeto, se apropria-
das, e é efetuado tanto no nível de gerenciamento quanto no nível técnico.
vii. Processo de Auditoria: define as atividades para determinar adequação
aos requisitos, planos e contrato, quando for apropriado.
viii.Processo de Resolução de Problemas: define um processo para anali-
sar e resolver os problemas, que são descobertos durante a execução do
desenvolvimento, operação, manutenção ou demais processos.
3.3 PROCESSOS ORGANIZACIONAIS
São utilizados com o intuito de melhorar continuamente a estrutura e os
processos do ciclo de vida do software. Estes são listados a seguir:
i. Processo de Gerência: define as atividades do responsável pelo
gerenciamento do produto, do projeto e das respectivas tarefas,
como aquisição, fornecimento, desenvolvimento, operação, manu-
tenção ou processos de apoio.
ii. Processo de Infra-estrutura: define as atividades para estabele-
cer e manter a infra-estrutura necessária para qualquer um dos
processos, tais como: hardware, software e ferramentas tanto para
desenvolvimento quanto para manutenção.
iii. Processo de Melhoria: este processo define as atividades para o
estabelecimento, avaliação, medição, controle e melhoria do ciclo
de vida de software.
25
iv. Processo de Treinamento: define as atividades para o treinamen-
to do pessoal, que utilizará o software.
v. Modelo de ciclo de vida: estrutura contendo processos, ativida-
des e tarefas envolvidas no desenvolvimento, operação e manuten-
ção de um produto de software, abrangendo a vida do sistema des-
de a definição de seus requisitos até o término de seu uso, confor-
me descrito em [4]
A importância do ciclo de vida no negócio de desenvolvimento de sistemas
é entender que o software é um produto. O modelo de ciclo de vida do produto pode
auxiliar na análise do estágio de maturidade de um produto. A manutenção do
software na fase da maturidade é o que possibilita a maior rentabilidade do mesmo.
Este fato pode ser observado no Gráfico 3.1, que expressa a lucratividade de um
produto de software no decorrer de seu ciclo de vida (tempo).
Gráfico 3.1: Ciclo de Vida
Fonte: sítio http://pt.wikipedia.org/wiki/Ciclo_de_vida, 19-Maio-2008.
26
4 O PRODUTO
Neste capítulo, apresentamos o produto desenvolvido bem como a sua
evolução até a data da elaboração deste trabalho.
4.1 VERSÃO INICIAL
O SCI foi concebido com o intuito de auxiliar o trabalho dentro de uma
empresa imobiliária voltada para a locação de imóveis. Este sistema tinha como fun-
ções básicas: manter o cadastro dos locadores e locatários; impressão de recibos de
locatários e extratos para locadores; e o cálculo de conta corrente. De forma a ilus-
trar a versão inicial do SCI apresentamos na Figura 4.1 o primeiro diagrama dese-
nhado para o sistema.
Figura 4.5: Primeiro Diagrama do Sistema
27
O Cadastro de Locadores, na Figura 4.1, tinha como função armazenar
os dados pessoais dos mesmos tais como nome, endereço, telefone, etc. O Cadas-tro de Locatários, além de conter os dados cadastrais dos locatários, armazenava
as informações pertinentes à locação propriamente dita, tais como: valor do aluguel;
endereço do imóvel locado; índice de reajuste (IGP,IGP,IPCA); e o mês do reajuste.
As entidades Recibos de Locatário e Recibos de Locador tinham como função
emitir os recibos, para que o locatário pudesse efetuar o pagamento, que continham,
além das informações cadastrais e o valor de outros lançamentos como IPTU, o va-
lor do condomínio e etc. O Recibo do Locador era um espelho do recibo do inquili-
no (locatário), porém nele era lançado o valor do percentual da comissão, que seria
deduzida do valor a receber pelo locador. A função Conta Corrente e Extrato era
um simples histórico de créditos e débitos, conforme os recibos iam sendo baixados
no sistema, gerando um acompanhamento que poderia ser usado para a declaração
do imposto de renda. Essa função era muito útil para locadores que tinham mais de
um imóvel.
Na época, a tecnologia para o acesso e armazenamento de informações,
mais moderna, para o uso em máquinas de pequeno porte, era o CLIPPER. Este foi
usado em sua versão Summer 87 e executado no sistema operacional DOS da Mi-
crosoft.
A interface de comunicação com o usuário era pouco amigável, já que
era feita em modo texto, e não oferecia muitos recursos para o cliente. Outros pro-
blemas freqüentes eram a quebra de arquivos de índice (.NTX) que aconteciam roti -
neiramente devido às falhas na escrita da lista encadeada e nos próprios arquivos
DBF, que às vezes eram corrompidos. Esses problemas tornavam a tarefa de
backup indispensável para salvaguardar o funcionamento do sistema.
Devido às tecnologias disponíveis na época o hardware escolhido foi um
IBM PC XT com uma freqüência do processador de apenas 4.77 MHz, 640Kb de
memória principal e com disco de armazenamento de 10 Mb. Este não foi escolhido
devido às capacidades técnicas mas sim pelo fator de mercado, pois era o único
28
equipamento, não nacional, disponível para compra com um valor acessível. Como
só havia um equipamento somente uma pessoa utilizava o sistema por vez, este fa-
tor foi decisivo na escolha de apenas um operador, ou seja, todas as requisições
eram passadas para uma pessoa, que efetuava a operação no computador e depois
retornava a informação para o requerente.
4.2 EVOLUÇÃO DO PRODUTO
Como na época de seu desenvolvimento o padrão ainda era o ciclo de
vida em “cascata”, o mesmo foi usado. Porém, não surtiu muito efeito devido à de-
mora para se obter um produto final. Esta idéia inicial foi abandonada e substituída
por um modelo incremental, no qual o fator principal passou a ser o tempo de res-
posta às necessidades do cliente. Esse modelo tratava o desenvolvimento do siste-
ma “olhando” das partes para o todo, ou seja, com uma visão Down – top .
Devido a este novo modelo, uma engenharia reversa tornou-se necessá-
ria, tomando por base as funções realizadas pelos funcionários e implementando as
funcionalidades aos poucos, de forma a aumentar os atributos de cada uma delas
com o passar do tempo. Neste momento, ocorreu uma mudança no software de ge-
renciamento de arquivos de dados e passamos a utilizar o DBASE III, o qual oferecia
maior flexibilidade para as funções do dia a dia, porém, como o DBASE III não era
usado na empresa como uma linguagem de programação e sim uma linguagem de
consulta aos arquivos de dados (instruções digitadas diretamente na linha de co-
mandos), necessitávamos de profissionais qualificados para construir as consultas e
emitir os relatórios.
Após a conclusão do desenvolvimento do sistema, que durou cerca de 18
meses, este já não era um sistema, mas sim de um conjunto de artefatos gerencia-
dos por um operador. Neste momento, devido à necessidade de se ter um maior
grau de acoplamento entre os diversos artefatos, houve nova mudança que serviu
29
para integrar os artefatos e gerar uma maior coesão das partes no todo. Com este
objetivo, uma nova plataforma de desenvolvimento teve que ser adotada, pois com
DBASE III não era possível atender a estas expectativas devido a sua interface não
muito amigável e os métodos deficitários de acesso aos dados. Na época, decidi-
mos adotar o FoxPro 2.0, por que era uma linguagem de programação que podia ser
interpretada ou compilada e seu formato para o armazenamento dos dados era mais
seguro e eficiente. No acesso aos dados o FoxPro 2.0 utilizava a tecnologia
Rushmore1, porém o fator primordial para sua utilização foi a interface, que apesar
de continuar sendo em modo texto já utilizava o mouse e permitia aplicar a idéia de
botões e preview de relatórios na tela.
Após esta fase de seleção de software, iniciamos o desenvolvimento des-
ta nova versão em FoxPro 2.0 para que, finalmente, em 1992 fosse então implanta-
do o verdadeiro sistema que, em certas partes, já era autônomo e poderia ser opera-
do por qualquer funcionário com um mínimo de treinamento. Nesta ocasião o equi-
pamento foi substituído por um PC AT 286. Com esta nova versão ganhamos em
agilidade, pois a imobiliária já havia crescido e a quantidade de registros na base de
dados havia aumentado consideravelmente. A tecnologia Rushmore aumentava em
até 6 vezes a velocidade no acesso às informações e os problemas de quebra de ar-
quivos de índices haviam sido superados, pois os arquivos CDX usados pela lingua-
gem eram mais seguros e estes tinham uma menor probabilidade de perda de inte-
gridade. Em termos de estruturação do sistema, criamos uma série de novas entida-
des, provendo novas funcionalidades tais como, por exemplo, o controle de imóveis
vazios e aluguéis em atraso.
Após a implantação, em 1992, o sistema entrou em uma fase de estabili-
dade, mas objetivando evitar a “senectude” dentro do modelo de ciclo de vida, as
manutenções não visavam apenas corrigir os erros e os defeitos apresentados, mas
também evoluir o sistema, com novas técnicas e conceitos introduzidos pela indús-
tria da informática. Uma aplicação destes novos conceitos foi na transformação do
sistema de mono usuário para multi-usuário, isto foi possível com a chega da rede
1 tecnologia Rushmore é uma técnica de acesso a dados que faz uso de índices compactos carrega-
dos na memória para acelerar o acesso aos dados
30
NOVEL e depois com os ambientes gráficos como o WINDOWS 3.11. Devido a es-
tes fatores, o sistema sofreu uma grande alteração nos seus conceitos básicos. A
base de dados passou a ser compartilhada em uma rede local de computadores que
anteriormente não existia, nesta ocasião foram instaladas mais 3 máquinas PC AT
386 DX 66.
O principal problema encontrado, na época, foi garantir a integridade das
informações em múltiplos acessos simultâneos à base de dados. Este problema foi
solucionado usando técnicas de programação para o travamento e destravamento
dos registros (lock e unlock) usados pelos usuários enquanto outros usuários fica-
vam na espera pela liberação do recurso. A topologia da rede escolhida foi a de bar-
ramento único devido à disposição física dos equipamentos, como apresentado na
Figura 4.2, e o meio de propagação do sinal era um cabo coaxial.
Figura 4.6: Topologia da Primeira Rede
O conceito de estação de trabalho foi introduzido na empresa onde usuá-
rios chave do processo da administração tinham seu próprio computador e o softwa-
re passou a trabalhar de forma mais integrada com as atividades dos funcionários
Com a mudança dos sistemas operacionais, para o Windows, houve a ne-
cessidade de se trocar novamente a plataforma de desenvolvimento do FoxPro 2.0
31
para o FOXPROW 2.5. Esta mudança propiciou a utilização das interfaces gráficas,
que são muito mais amigáveis. O principal impacto gerado por essa mudança foi na
aparência do sistema, com o uso de interfaces gráficas introduzimos uma nova dis-
tribuição das atividades dentro do sistema, janelas podiam então ser sobrepostas e
um acesso à informação poderia ser feito em forma de cascata, facilitando as tarefas
dos usuários, embora as funcionalidades permanecessem as mesmas.
Atualmente nos parece usual, mas a idéia de se criar eventos em progra-
mação aumentou, e muito, a facilidade na operação do sistema. O usuário passou a
conviver com botões, caixas de texto, barras de rolagem e outros componentes que
até então eram muito pouco utilizados, mas já existiam no FOXPRO 2.0. Com a ver-
são 2.5 estes componentes ganharam ainda mais importância.
O fator “interação como o usuário” atingiu seu ápice por volta do ano
2000, quando o VISUAL FOXPRO 6.0 foi instalado. O sistema evoluiu a um ponto,
devido à facilidade da interação do homem com a máquina, que este pôde obter re-
sultados ainda mais satisfatórios e ágeis para os usuários. Neste momento, o siste-
ma passou a ser visto como “mais um funcionário” a colaborar para o crescimento
da empresa. Alguns pontos desta evolução devem ser destacados, tais como: o sis-
tema gerava automaticamente os avisos de aluguéis em atraso, relatórios de re-lo-
cação, cartas de cobrança e avisos de entrega de imóvel, sem que o usuário tivesse
que solicitá-los.
As funcionalidades do sistema já haviam se expandido além da fronteira
da simples impressão de recibos ou da manutenção de contas correntes, pois já era
um sistema conectado à Internet, com diversas responsabilidades, entre elas: a ma-
nutenção de sites para anúncio de imóveis para alugar e vender, controle do fluxo de
caixa da empresa e sua escrita contábil.
Nesta fase, o conceito de “estação de trabalho” já estava entranhado na
empresa e cada funcionário tinha o seu próprio computador. Com a migração para o
sistema operacional para o Windows 98, o cabo coaxial foi retirado e adotou-se um
hub usando cabos de par trançado. Isso proveu um acesso mais rápido através da
32
rede e, em conjunto com a utilização das APIs do Windows 98, nos deu a possibili-
dade de trabalhar com objetos mais complexos, como, por exemplo, fotos armaze-
nadas no sistema.
Além da evolução tecnológica, neste período outras questões relevantes
devem ser destacadas:
i. Diversas alterações corretivas foram implementadas devido a
desvios no entendimento do problema, tanto no domínio do ne-
gócio, por parte do programador, quanto pela falta de visão por
parte do cliente. Isso acarretou em grandes problemas, pois par-
tes cruciais do sistema tiveram que ser revistas e em muitos ca-
sos re-escritas, causando atrasos e custos adicionais. Para que
esse problema não voltasse a acontecer, o programador se es-
pecializou neste domínio de negócio, estudando mais a fundo a
lei do inquilinato e as arquiteturas de referencia disponíveis na
época.
ii. As turbulências geradas pelos planos Collor, verão, URV, con-
versão de moedas e outras mudanças na economia refletiram
diretamente no sistema, havendo a necessidade de diversas in-
tervenções para adaptar o sistema às regras de negócio impos-
tas pelo mercado.
iii. O principal problema enfrentado foi a mudança na lei o inquilina-
to que ocorreu simultaneamente ao Plano Real. Os reajuste dos
aluguéis passaram a seguir regras não previstas no projeto inici-
al, isto desencadeou numa série de alterações nas estruturas de
banco de dados que se propagaram por todo o sistema, trazen-
do uma certa dificuldade para estabilizá-lo novamente. Nesta
oportunidade começou a ser cogitada a idéia de utilizar compo-
nentes para que o sistema ficasse menos susceptível as intem-
péries dos governos, ou seja, quando fosse necessária alguma
33
alteração seria construído um novo componente de software
que substituiria o anterior (deprecate). Esta estratégia funciona
até um certo ponto, pois sabemos que não temos como prever
todas as possíveis mudanças, mas a idéia central foi de minimi-
zar os possíveis impactos sofridos pelo sistema.
Neste ponto, o produto já havia atingido sua maturidade, dentro do seu ci-
clo de vida, e a idéia então foi de mantê-lo sempre maduro, para que não se dege-
nerasse.
Baseado neste conceito, em 2004 houve nova mudança, que foi a criação
de módulos operacionais. Estes módulos transformaram o SCI em um sistema de
gestão e administração por setor de trabalho dentro da empresa. Esta fase durou
quase dois anos e na sua construção foi adotada a arquitetura cliente / servidor, que
utilizava um banco de dados relacional. Estas e outras questões são apresentadas
na próxima subseção, que corresponde ao estágio atual do CSI.
34
4.3 VERSÃO ATUAL
Em sua versão atual, o sistema é composto por seis módulos e uma caixa
de ferramentas, como ilustrado pela Figura 4.3.
Figura 4.7: Arquitetura do Sistema Atual
Na seqüência, temos a descrição de cada um dos módulos da Figura 4.3:
• Módulo de Consulta: consiste em deixar o usuário consultar todas as infor-
mações, porém este não consegue alterar nada. O principal objetivo deste
módulo é de viabilizar a qualquer usuário, independente do grau de restrição,
consultas às informações sobre as locações, aluguéis em atraso, oferta de
imóveis para alugar, entre outras. Uma ilustração sobre este módulo é apre-
sentada na Figura 4.4.
35
Figura 4.8: Tela da Versão Atual (Sistema em Modo Consulta Locatário)
• Módulo Caixa: este módulo específico executa em apenas duas máquinas,
que estão ligadas em rede e às suas próprias impressoras escravas. Estas
impressoras operam com formulários próprios para recibos, que podem ser
impressos para locatários ao efetuar o pagamento ou locadores quando do
recebimento do aluguel. Basicamente, a idéia é de uma “caixa registradora”,
como ilustrado pela Figura 4.5. Hoje esta empresa opera este módulo em
apenas duas máquinas, como dito anteriormente, embora o sistema comporte
até nove módulos caixas executando simultaneamente.
36
Figura 4.9: Tela da Versão Atual (Sistema em Modo Consulta Caixa)
• Módulo Administrativo: este processo é o coração do sistema e somente
usuários com privilégios específicos têm acesso. Este módulo é por onde se
introduz uma grande parte das informações a serem processadas, tais como
novos locadores e locatários. Nele é feito, também, o lançamento de contas
extras como água, IPTU e condomínio, bem como a manutenção dos dados
cadastrais (Figura 4.6).
37
Figura 4.10: Tela da Versão Atual (Sistema em Modo Consulta Administrativo)
• Módulo de Devolução: neste módulo são definidas as atividades de devolu-
ção do imóvel (Figura 4.7), que nada mais são que uma seqüência de docu-
mentos e certidões emitidas pelo sistema para comprovar, junto ao inquilino,
o fim de um contrato de locação. Neste ponto, o imóvel e colocado com o sta-
tus de “imóveis para alugar” e passa ser gerenciado pelo módulo de
“Anúncio”.
38
Figura 4.11: Tela da Versão Atual (Sistema em Modo Consulta Devolução)
• Módulo Anúncio: estrutura contendo processos de anúncio de imóveis, im-
pressão de pastas e cartões de vitrine. A sua principal atividade é a de geren-
ciar o site da empresa. Para tal, o sistema exporta um XML, contendo as in-
formações da oferta para locação, que é incorporado ao site da empresa atra-
vés de uma transferência via FTP. Uma ilustração sobre este módulo é apre-
sentada na Figura 4.8.
39
Figura 4.12: Tela da Versão Atual (Sistema em Modo Anúncio)
• Módulo Jurídico: módulo que contém os processos, atividades e tarefas en-
volvidas no acompanhamento jurídico dos contratos. Por exemplo, quando de
uma inadimplência for superior a 10 dias o sistema encaminha o registro ao
setor jurídico, que através de intervenção humana adota a melhor maneira de
proceder. Este módulo, também, é o responsável por contabilizar custas judi-
ciais, agenda de audiências e acompanhamento de processos em geral (Figu-
ra 4.9).
40
Figura 4.13: Tela da Versão Atual (Sistema em Modo Jurídico)
• Caixa de Ferramentas: a Caixa de Ferramentas é um componente criado vi-
sando à utilização da orientação a objetos, que será o novo passo em direção
ao futuro do SCI. Nela estão implementadas várias funções, tanto para o
acesso ao banco de dados quanto às funções de cálculos simples, que são
usadas com grande freqüência em várias partes do sistema. Este módulo foi
construído com o objetivo de reutilizar componentes de software. Conforme
descrito em [2] e [1].
41
Com fins ilustrativos apresentamos, na Figura 4.10, um diagrama conten-
do a disposição física de 10 equipamentos e dos módulos do sistema.
Figura 4.14: Diagrama da disposição de equipamentos.
42
Na Figura 4.11, apresentamos a configuração real dos funcionários que
utilizam o SCI.
Figura 4.15: Foto do Ambiente de Trabalho da Empresa Imobiliária.
Finalmente, durante todo este período, desde o nascimento do SCI, a em-
presa Sênior Imóveis, mostrada na foto 4.12, evoluiu e software certamente auxiliou
neste crescimento. No início, era apenas como uma maneira de armazenar as infor-
mações cadastrais, depois integrando o uso dos computadores com os funcionários
e atualmente dividindo as atividades por setores e utilizando o software como uma
ferramenta de produtividade indispensável no dia a dia da empresa.
43
Figura 4.16: Foto da fachada da empresa com as suas 3 lojas.
As diversas inovações, tanto na tecnologia do hardware (com novas má-
quinas, arquiteturas de rede e acesso à Internet) quanto nos sistemas operacionais
(sendo mais íntegros e confiáveis), bem como um conhecimento maior do domínio
do negócio alvo do SCI, por parte do desenvolvedor, transformaram o sistema em
um conjunto de ferramentas flexível, que podem ser configuradas para oferecer su-
porte a pequenas, médias ou grandes empresas administradoras de imóveis.
44
O fator de construção baseada em componentes do SCI fez com que as
manutenções, tanto evolutivas quanto adaptativas, possam ser efetuadas com um
baixo custo e em tempo reduzido. Isto devido ao fato de que a troca de um ou mais
componentes é bem menos custosa que a troca de um sistema inteiro conforme
descrito em [1].
45
5 O FUTURO
Neste capítulo, apresentamos uma visão do que temos previsto para a
evolução do produto SCI. Desta forma, abordaremos três pontos: a evolução do sis-
tema, o aprimoramento das técnicas de desenvolvimento e uma visão de negócios.
5.1 EVOLUÇÃO DO SISTEMA
As novas versões, em pauta hoje, visam à implementação de biometria no
atendimento aos locadores na hora de receber seus aluguéis, já que somente pes-
soas cadastradas podem receber o aluguel. Esta biometria será utilizada para o re-
conhecimento de digitais no ato do recebimento, substituído assim cartões magnéti-
cos e senhas, agilizando o recebimento dos valores pelos locadores, que não rece-
bem através de depósitos bancários. Acreditamos que até o final deste ano esta al-
teração já esteja implantada e em funcionamento.
5.2 APRIMORAMENTOS NAS TÉCNICAS DE DESENVOLVIMENTO
Sabemos que “ninguém é eterno”, isto é um fato, porém uma empresa
pode durar séculos. Neste contexto, o nosso principal objetivo de manter o sistema
em sua maturidade dentro do ciclo de vida. Com este objetivo, nossa idéia é de efe-
tuar novas mudanças evolutivas de grande porte, passando todo o sistema para o
VISUAL FOXPRO 9.0, já em POO, com uma documentação mais abrangente, inclu-
indo DER , EPC e casos de uso.
46
O maior resultado obtido com a documentação do software será a possibi-
lidade de incluir novos profissionais de informática na empresa. Desta forma, criar
uma equipe de desenvolvimento, que poderá “manter” o sistema independente da
falta de um ou outro programador.
5.3 UMA VISÃO DE NEGÓCIOS
Hoje, o SCI tornou-se um produto comercializado pela AUGE Tecnologia
em Informática LTDA, que conta com quatro trabalhadores, incluindo o autor deste
trabalho que desempenha o papel de diretor.
O produto conta com 17 clientes em 4 cidades diferentes do país. A em-
presa AUGE Tecnologia em Informática LTDA tem no SCI o seu “carro chefe”, o que
representa aproximadamente 60% do seu faturamento.
A comercialização do SCI para outras empresas aconteceu de forma na-
tural e gradativa, ou seja, outros administradores de imóveis da cidade ao ver o pro-
duto em funcionamento, dentro da Sênior Imóveis, quiseram obter maiores informa-
ções e acabaram por adquirir o produto.
Em 1998, quando da abertura da empresa Auge Informática LTDA, houve
a idéia de transformar o SCI em um “software de prateleira”, então optei por uma
segmentação do mercado, subdividindo o SCI em 3 versões diferentes, com o objeti-
vo de alcançar todo o setor de imobiliárias, que foram descritos na seqüência:
• Uma versão, a mais simples, utilizaria um formulário contínuo para a impres-
são dos recibos, na qual estes seriam impressos antecipadamente, e depois
baixados por demanda;
47
• Na segunda versão, o usuário imprimiria o recibo no momento que o cliente
fosse efetuar o pagamento, isso seria interessante pois o próprio sistema cal-
cularia a multa por atraso e já daria baixa no pagamento no momento da im-
pressão;
• A terceira versão, mais completa, emitiria boletos bancários na própria imobili -
ária, ou geraria arquivos texto do tipo CNAB 2402, porém era uma versão que
dava muito trabalho na instalação e manutenção, visto que os formatos de im-
pressão mudavam de banco para banco.
Estas versões tanto a mais simples quanto a mais completa e entre elas
uma versão intermediária, tinham como intuito de compor um preço mais justo con-
forme as reais necessidades da empresa adquirente.
Todavia, não obtive muito sucesso devido à falta de pessoal especializa-
do para dar treinamento dentro da empresa adquirente. Nesta fase comercializamos
de apenas quatro cópias, o que nos fez voltar novamente para a propaganda de
“Boca em Boca”.
Hoje, o software é comercializado por indicações de usuários anteriores,
ou através do site da Auge Informática, onde apenas fazemos uma propaganda e
fornecemos um telefone para contato. Caso o cliente se interesse, marcamos uma
demonstração se este estiver em nossa região, caso contrário enviamos uma cópia
de demonstração.
Caso o cliente demonstre interesse em adquirir realmente o software, en-
tão acertamos o preço e enviamos à cidade do cliente dois técnicos, que são res-2 Os bancos usam o padrão Febraban CNAB 400 ou 240 para receber (remessa) e enviar (retorno) in-
formações para as empresas clientes usando arquivos. O objetivo destes arquivos é intercambiar in-
formações digitalmente entre o sistema de informática do banco e o do cliente. Dentre as informa-
ções podemos citar: cobrança (boletos bancários), pagamentos, extrato (para conciliação), débito
em conta, vendedor e custódia de cheques. Cada um destes produtos tem seu fluxo de informação e
portanto um layout.
48
ponsáveis pela instalação, configuração e treinamento, todos estes procedimentos
levam cerca de quinze dias.
49
CONCLUSÕES
A principal conclusão que chegamos foi o significativo ganho de produtivi-
dade que o SCI propiciou a esta empresa. Este aumento de produtividade fica evi-
dente nos dados contidos na Tabela 1. Nela comparamos a produtividade dos funci -
onários em dois momentos: no início do sistema e atualmente. Esta comparação faz
uso dos seguintes dados: a quantidade de funcionários da empresa, a quantidade de
imóveis administrados e, também, a relação da quantidade de funcionários e de imó-
veis administrados.
Tabela 1: Produtividade da Empresa com a Introdução e Evolução do SCI
Tempo Funcionários Imóveis Imóveis por funcionárioInício do sistema 4 250 ~62,5Atualmente 19 4500 ~236,8
Podemos concluir que a produtividade praticamente quadruplicou neste
período e que tal produtividade sem esta ferramenta seria impraticável. Hoje, mais
do que nunca, o SCI é de vital importância para a sobrevivência desta empresa no
setor.
Um outro dado, também relevante, foi à utilização de computadores por
parte dos funcionários, que nesta empresa saltou de 1 para 24 neste período de
tempo, ou seja, de 0,25 máquina por funcionário para 1,26.
Entendemos que o produto ainda está em sua fase de maturidade, dentro
do seu ciclo de vida, mas é muito difícil prever quando este cairá em desuso, ou
seja, no período de senectude do ciclo de vida. Sabemos, sim, que dependerá basi-
camente da nossa capacidade em prever as mudanças e tentar suprir as necessida-
des antes mesmo que elas apareçam, de entender e aceitar as mudanças do merca-
do e nas necessidades e anseios dos clientes, para que possamos continuar na fase
de maturidade do produto.
50
Finalmente, temos a certeza de que muitas falhas no processo de desen-
volvimento teriam sido evitadas com a utilização das técnicas de desenvolvimento,
aprendidas neste curso e discutidas no Capítulo 3. Estes conhecimentos nos teriam
poupando muito tempo e dinheiro. Outro ponto importante, que cabe destacar, é que
o estudo continuado possibilitou ao autor a aquisição de novos conhecimentos, práti-
cos e teóricos, que quando aplicados no dia a dia podem, com certeza, trazer bons
frutos para o futuro da Auge Informática.
51
REFERÊNCIAS BIBLIOGRÁFICAS
[1] J. Sametinger, Springer, Software Engineering with Reusable Compon-ents; SPRINGER-VERLAG NEW YORK , 1997
[2] Josiane Larman, Utilizando UML e Padrões bookman, 2007
[3] ISO/AFNOR, Dictionary of computer science, https://www.cs.tcd.ie
1989
[4] ISO/IEC 2382-1- https://www.cs.tcd.ie ,1993
[5] ISO/IEC/JTC1/SC7/WG7 N94 – Information Technology -Guide for ISO/IEC ht-tps://www.cs.tcd.ie, 2007
[6] Royce, Winston (1970),Managing the Development of Large Software Systems, Proceedings of IEEE WESCON, TRW , 26 (August): 1991
[7] Eduardo BEZERRA, Princípio de Análise e Projeto de Sistemas com UML, Campus; 2002
52