HELTON EDUARDO RITTER
MAYCON VIANA BORDIN
DESENVOLVIMENTO DE UM SOFTWARE PARA SEQUENCIAMENTO
DA PRODUÇÃO DE UMA INDÚSTRIA METAL-MECÂNICA
Três de Maio
2010
HELTON EDUARDO RITTER
MAYCON VIANA BORDIN
DESENVOLVIMENTO DE UM SOFTWARE PARA SEQUENCIAMENTO
DA PRODUÇÃO DE UMA INDÚSTRIA METAL-MECÂNICA
Relatório da Prática Profissional Direcionada V
Sociedade Educacional Três de Maio
Faculdade Três de Maio
Curso de Bacharelado em Sistemas de Informação
Professores Orientadores:
M. Sc. Cristiano Schwening
Esp. Leila Dalazen
M. Sc. Adalberto Lovato
Esp. Tiago Cesa Seibel
Três de Maio
2010
RESUMO
Este trabalho apresenta a solução de sequenciamento da produção para uma
fabricante de peças de colheitadeiras como parte da Prática Profissional Direcionada V
do curso de Sistemas de Informação da SETREM e foi desenvolvido no segundo
semestre de 2010. O problema atual era sequenciar um grande número de peças para
serem produzidos em pequenos lotes, usando planilha eletrônica o que demanda tempo
excessivo para produzir o sequenciamento. O procedimento atual é eficiente para um
pequeno conjunto, mas fica ineficiente à medida que o número de conjuntos aumenta.
O software foi desenvolvido após uma detalhada análise do cenário, na fase de projeto.
Foi desenvolvido em linguagem Java e PostgreSQL como banco de dados. Os
objetivos foram alcançados após uma abrangente fase de testes providos pelas
recomendações de Engenharia de Software.
Palavras chave: Sequenciamento da produção, Engenharia de Software, Java.
ABSTRACT
This paper presents the solutions for a scheduling problem in a original equipment
manufacturer for parts of combine harvesters as part of the practice work of the
Information System course in SETREM College, during the second semester of 2010.
The actual problem was to schedule a great number of parts to be produced in small
batches. The sequencing was manually made in an electronic spreadsheet, demanding
huge amount of time. The procedure was suitable for an initial small amount of parts, but
as the number of parts increased, the used method became out dated and inefficient.
The present software was preceded by a deep analysis of the new scenario and
followed by a set of diagrams, like UML pattern during the project step. The software
was developed using Java programming language, and PostgreSQL database was
used. The goals were achieved after an comprehensive set of tests provided by good
Software Engineering practices.
Key Words: Production Schedule, Software Engineering, Java.
LISTA DE FIGURAS
Figura 1: Cronograma de Atividades do Projeto ............................................................. 20
Figura 2: Orçamento do projeto. ..................................................................................... 21
Figura 3: Fases do modelo em cascata. ........................................................................ 31
Figura 4: Modelo de prototipagem. ................................................................................. 32
Figura 5: Modelo em espiral. .......................................................................................... 34
Figura 6: O processo extreme programming. ................................................................. 36
Figura 7: Tipos de requisites não-funcionais. ................................................................. 41
Figura 8: Exemplo de requisito de sistema. ................................................................... 42
Figura 9: Tradução do modelo de análise para um modelo de projeto. ......................... 45
Figura 10: Dimensões do modelo do projeto. ................................................................. 47
Figura 11: Qualidade no ciclo de vida. ........................................................................... 61
Figura 12: Exemplo do pattern façade. .......................................................................... 64
Figura 13: Exemplo do pattern Presentation Model. ...................................................... 65
Figura 14: Plataforma Java. ........................................................................................... 70
6
LISTA DE SIGLAS
CMM – Capability Maturity Model
CMMI – Capability Maturity Model Integration
CRC – Class-Resposability-Colaborator
GCJ – GNU Compiler for Java
GUI – Graphic User Interface
HTML – Hyper Text Markup Language
IDE – Integrated Development Environment
IEC – International Electrotechnical Commission
ISO – International Organization for Standardization
JDK – Java Development Kit
JIT – Just In Time
7
JRE – Java Runtime Environment
JVM – Java Virtual Machine
KISS – Keep It Simple, Stupid!
MER – Modelo de Entidades-Relacionamentos
MVC – Model-View-Controller
OO – Orientação a Objetos
ORM – Object-Relational Mapping
PDF – Portable Document Format
PMP – Plano Mestre de Produção
RAD – Rapid Application Development
RTF – Rich Text Format
SDK – Software Development Kit
SEI – Software Engineering Institute
SGBD – Sistema Gerenciador de Banco de Dados
SQA – Software Quality Assurance
SQL – Structured Query Language
SRS – Software Requirements Specification
8
UML – Unified Modeling Language
XP – eXtreme Programming
9
SUMÁRIO
RESUMO.......................................................................................................................... 3
ABSTRACT ...................................................................................................................... 4
LISTA DE FIGURAS ........................................................................................................ 5
LISTA DE SIGLAS ........................................................................................................... 6
SUMÁRIO ........................................................................................................................ 9
INTRODUÇÃO ............................................................................................................... 13
CAPÍTULO 1: ASPECTOS METODOLÓGICOS ........................................................... 15
1.1 TEMA ....................................................................................................................... 15
1.1.1 Delimitação do Tema ........................................................................................... 15
1.2 JUSTIFICATIVA ....................................................................................................... 15
1.3 PROBLEMA ............................................................................................................. 16
1.4 HIPÓTESES ............................................................................................................. 17
1.5 OBJETIVOS ............................................................................................................. 17
1.5.1 Objetivo Geral ...................................................................................................... 17
1.5.2 Objetivos Específicos ......................................................................................... 17
1.6 METODOLOGIA ....................................................................................................... 18
1.6.1 Métodos de Abordagem ...................................................................................... 18
1.6.2 Métodos de Procedimento .................................................................................. 18
1.6.3 Técnicas de Pesquisa ......................................................................................... 19
10
1.7 CRONOGRAMA ....................................................................................................... 20
1.8 RECURSOS ............................................................................................................. 21
1.9 ORÇAMENTO .......................................................................................................... 21
CAPÍTULO 2: FUNDAMENTAÇÃO TEÓRICA .............................................................. 22
2.1 A EMPRESA ............................................................................................................ 22
2.2 ADMINISTRAÇÃO DA PRODUÇÃO ........................................................................ 22
2.2.1 Visão Geral das Atividades do Planejamento Operacional ............................. 23
2.2.1.1 Planejamento de Longo Prazo ........................................................................... 23
2.2.1.2 Planejamento de Médio Prazo ........................................................................... 24
2.2.1.3 Planejamento de Curto Prazo ............................................................................ 24
2.2.1.4 Estratégias do Planejamento da Produção ........................................................ 26
2.2.2 Programação e Sequenciamento de um Ambiente Job Shop ......................... 27
2.3 ENGENHARIA DE SOFTWARE .............................................................................. 29
2.3.1 Modelos de Processos ........................................................................................ 30
2.3.1.1 Modelo em Cascata............................................................................................ 30
2.3.1.2 Prototipagem ...................................................................................................... 31
2.3.1.3 Modelo Espiral .................................................................................................... 33
2.3.1.4 XP (eXtreme Programming) ............................................................................... 34
2.3.2 Fases de um Projeto ........................................................................................... 38
2.3.2.1 Levantamento dos Requisitos ............................................................................ 39
2.3.2.2 Análise ................................................................................................................ 42
2.3.2.2 Projeto ................................................................................................................ 44
2.3.2.4 Desenvolvimento ................................................................................................ 48
2.3.2.5 Testes ................................................................................................................. 48
2.3.2.5.1 Teste de Software Orientado a Objetos .......................................................... 50
2.3.2.5.2 Teste de Unidade ............................................................................................ 51
2.3.2.5.3 Teste de Integração......................................................................................... 52
2.3.2.5.4 Teste de Validação .......................................................................................... 53
2.3.2.5.5 Teste de Sistema ............................................................................................ 54
2.3.2.5.6 Depuração ....................................................................................................... 55
11
2.3.2.6 Manutenção ........................................................................................................ 57
2.3.3 Qualidade de Software ........................................................................................ 58
2.3.3.1 Qualidade do Produto e Processos .................................................................... 60
2.3.4 Design Patterns ................................................................................................... 63
2.3.4.1 Facade Pattern ................................................................................................... 63
2.3.4.2 Presentation Model............................................................................................. 64
2.3.4.3 MVC (Model-View-Controller) ............................................................................. 65
2.3.5 Refactoring (ou refatoração, ou ainda refabricação) ....................................... 66
2.4 BANCO DE DADOS ................................................................................................. 67
2.5 FERRAMENTAS UTILIZADAS ................................................................................. 68
2.5.1 Java ...................................................................................................................... 68
2.5.2 NetBeans .............................................................................................................. 70
2.5.3 Hibernate Framework .......................................................................................... 71
2.5.4 JUnit Framework ................................................................................................. 72
2.5.5 Javadoc ................................................................................................................ 72
2.5.5 Toad Data Modeler .............................................................................................. 72
2.5.6 PostgreSQL .......................................................................................................... 73
2.5.7 Enterprise Architect ............................................................................................ 74
CAPÍTULO 3: RESULTADOS ....................................................................................... 75
3.1 SITUAÇÃO ATUAL DA EMPRESA .......................................................................... 75
3.2 ESPECIFICAÇÃO DOS REQUISITOS DO SISTEMA ............................................. 76
3.2.1 Domínio do Problema ......................................................................................... 76
3.2.2 Resultados Esperados ........................................................................................ 78
3.2.3 Impacto do Sistema na Empresa ....................................................................... 78
3.3 ANÁLISE E PROJETO DO SISTEMA ...................................................................... 79
3.3.1 Casos de Uso ....................................................................................................... 79
3.3.2 Diagramas de Atividade ...................................................................................... 79
3.3.3 Diagramas de Classes ........................................................................................ 80
3.3.4 Modelo Entidade Relacionamento ..................................................................... 80
3.4 DESCRIÇÃO DO DESENVOLVIMENTO ................................................................. 80
3.5 TESTES DO SISTEMA ............................................................................................ 81
12
3.6 MANUTENÇÃO DO SISTEMA ................................................................................. 82
CONCLUSÃO ................................................................................................................ 84
REFERÊNCIAS .............................................................................................................. 87
APÊNDICES .................................................................................................................. 90
APÊNDICE A: Especificação dos Requisitos do Sistema ..................................................
APÊNDICE B: Documento de Arquitetura ..........................................................................
APÊNDICE C: Plano de Testes ...................................................................................... 90
APÊNDICE D: Relatório de Testes ....................................................................................
APÊNDICE E: Manual do Usuário ......................................................................................
APÊNDICE F: Modelo Entidades-Relacionamentos ..........................................................
13
INTRODUÇÃO
As empresas normalmente evoluem com o passar do tempo, superam-se as
dificuldades burocráticas, a complexidade de produzir um produto, comercializar,
fidelizar. Uma vez o processo estando estável faz-se perceptível o maior dos desafios:
otimizá-lo.
Entenda-se que numa otimização, cada unidade do processo possui suas
complexidades características, e que influenciam sistematicamente o todo. Em uma
metalúrgica, um processo que pode ser otimizado para obter um melhor custo-benefício
é o sequenciamento fino da produção, esta foi a demanda apresentada pela
Metalúrgica Fratelli, e que este trabalho fruto da Prática Profissional Direcionada V,
focada em sistemas de produção, busca auxiliar na melhora do processo através do
desenvolvimento de um software especialista.
O desenvolvimento de uma solução em software, para prover soluções a um
problema real e estratégico de uma organização necessita de uma base sólida de
conhecimentos que possam auxiliar a diminuir a complexidade, e garantir a qualidade
seja quanto a requisitos ou aspectos técnicos. A engenharia de software provê
recomendações que inferem positivamente no êxito de todas as fazes de um sistema,
desde o planejamento a implantação e posterior suporte.
14
Tendo a modelagem do problema real representada computacionalmente
através de um padrão, como o UML e demais questões iniciais resolvidas, precisa-se
eleger ferramentas de desenvolvimento. Neste quesito, a opção feita pela linguagem de
programação Java, e IDE NetBeans mostra-se alinhada à possibilidade de implementar
as recomendações da engenharia de software.
O capítulo 1 apresenta o projeto deste trabalho, planejamento, metodologias
utilizadas e justifica a pertinência deste trabalho frente ao contexto do problema. No
capítulo 2, discutem-se os itens básicos para que o problema possa ser compreendido
na minúcia que a especificidade do sequenciamento fino da produção requer.
Finalmente, apresentam-se os resultados obtidos no terceiro capítulo, neste que prova-
se as hipóteses e valida-se através dos testes os objetivos descritos no primeiro
capítulo.
O sequenciamento fino da produção, pela sua complexidade (como apresenta o
cap. 2), é uma atividade que requer softwares alinhados a estrutura física, recursos
materiais, critérios de tempo entre outros particulares, e até por vezes ao produto a ser
produzido. A carga de processamento tende a ser alta, por isso em algumas situações,
não é viável uma busca exaustiva das possibilidades do sequenciamento, fazendo-se
necessário o uso de uma heurística na busca de uma solução boa. Sugestões de
melhorias futuras são apresentadas no capítulo 3.
15
CAPÍTULO 1: ASPECTOS METODOLÓGICOS
1.1 TEMA
Desenvolvimento um software para o sequenciamento de produção em uma
indústria metal-mecânica.
1.1.1 Delimitação do Tema
Desenvolvimento de um software em linguagem de programação Java para o
sequenciamento da produção da metalúrgica Fratelli localizada em Santa Rosa – RS,
fazendo uso das metodologias e boas práticas da Engenharia de Software durante todo
o projeto.
Este projeto foi desenvolvido dentro da Prática Profissional Direcionada V do
curso de Bacharelado em Sistemas de Informação, envolvendo as disciplinas de
Engenharia de Software, Sistemas de Produção e Programação Comercial III, no
período de julho a dezembro de 2010 na Sociedade Educacional Três de Maio –
SETREM, na cidade de Três de Maio, RS.
1.2 JUSTIFICATIVA
O planejamento da produção tem por objetivo a melhoria da cadeia de
produção, visando melhor atender os clientes e consequentemente garantir a
sustentabilidade da organização. Esse planejamento é formado pelo plano agregado,
de longo prazo; o Plano Mestre de Produção (PMP), em médio prazo; e as técnicas de
seqüenciamento (ou programação fina), visando a operacionalização diária.
Enquanto o planejamento agregado e o PMP possuem métodos padronizados e
largamente aceitos, o sequenciamento diário da produção fica restrito as características
peculiares de cada negócio demandando métodos e técnicas personalizados.
A programação fina determina como será distribuída a produção entre os
recursos disponíveis (máquinas, pessoas, processos). A aplicação de técnicas e
métodos que buscam a otimização do sequenciamento traduzem-se em melhor
utilização das máquinas e conformidade com o tempo de entrega. A consequência disto
é o melhor atendimento do cliente, maximização da eficiência produtiva e redução de
custos.
A metalúrgica Fratelli já possui uma solução para o sequenciamento de sua
produção. A solução projetada inicialmente para 16 diferentes conjuntos não é
escalável e assim revelou insuficiências no sequenciamento de uma gama maior de
conjuntos, que hoje atinge cerca de 50.
Daí a necessidade de uma solução que consiga ser escalável, atendendo as
crescentes demandas da indústria, através de um sistema mais eficiente, que
proporcione maior agilidade no sequenciamento.
1.3 PROBLEMA
Como desenvolver um software utilizando métodos de engenharia de software
que seja capaz de sequenciar a produção de uma indústria metal-mecânica?
17
1.4 HIPÓTESES
A solução fornecida pelo software torna o processo de sequenciar a
produção mais rápido do que a solução atualmente empregada na
empresa.
A utilização de testes unitários diminui a ocorrência de erros no software e
facilita a execução de testes.
1.5 OBJETIVOS
Nesta seção encontram-se os objetivos gerais deste projeto bem como os
objetivos específicos.
1.5.1 Objetivo Geral
Desenvolver um software que seja capaz de sequenciar a produção diária da
metalúrgica de forma eficiente.
1.5.2 Objetivos Específicos
Definir o escopo do projeto e levantar os requisitos dos clientes.
Buscar o embasamento teórico nas áreas envolvidas pelo projeto.
Pesquisas e testes sobre as ferramentas que serão utilizadas no
desenvolvimento.
Desenvolver a análise com base nos requisitos levantados.
Desenvolver o software e as unidades de teste.
Documentar as classes do software.
18
Comparações dos resultados obtidos com o método utilizado atualmente na
indústria.
Produzir o relatório, artigo e a apresentação dos resultados.
1.6 METODOLOGIA
Através do desenvolvimento do problema, todo trabalho busca analisar,
desenvolver observações, criticá-los e interpretá-los. A metodologia fornece os métodos
e técnicas para a correta investigação do pensamento e desenvolvimento do problema
em direção à busca de soluções (OLIVEIRA, 2002).
1.6.1 Métodos de Abordagem
Este trabalho é classificado como quantitativo, sendo focalizado “em termos de
grandeza ou quantidade do fator presente em uma situação.” (MARCONI; LAKATOS,
2006, p. 148).
De forma mais específica, este trabalho é quantitativo, pois se baseia em
valores numéricos para a comparação entre os resultados obtidos pelo software em
comparação com outras abordagens para a solução do problema.
1.6.2 Métodos de Procedimento
Através dos requisitos dos usuários e com o conhecimento necessário a
respeito das áreas abordadas neste trabalho, estes obtidos através de técnicas de
pesquisa descritas na próxima seção, desenvolve-se a análise. Esta é basicamente
uma representação gráfica e mais detalhada do que o sistema deve abranger, fruto da
observação e pesquisa indireta a respeito do problema.
Depois de formada a análise, existe o projeto do sistema, onde se determina as
ferramentas que serão utilizadas com base no problema abordado. Esta atividade serve
19
de base para o inicio do desenvolvimento do sistema, este primariamente uma pesquisa
laboratorial, pois é preciso levar em conta que apesar de a análise fornecer “o que deve
ser feito” e o projeto fornecer o “como será feito” e o “com o que será feito”, o
desenvolvimento é onde de fato será feito o software, produto principal deste trabalho.
Tanto na análise como no projeto do sistema serão usados diagramas para a
representação dos dados armazenados pelo sistema, o ambiente do sistema e seu
comportamento em determinadas situações. Estas representações se darão através
dos diagramas da UML e de Entidades-Relacionamentos.
1.6.3 Técnicas de Pesquisa
“Técnica é um conjunto de preceitos ou processos que se serve uma ciência ou
arte; é a habilidade para usar esses preceitos ou normas, a parte prática. Toda ciência
utiliza inúmeras técnica na obtenção de seus propósitos.” (MARCONI; LAKATOS, 2006,
p. 63).
O primeiro passo no desenvolvimento deste trabalho foi o levantamento de
informações a respeito do problema da empresa. Isso se deu através de entrevistas
com os envolvidos na atividade da empresa e também pela visitação da empresa para
a observação de como o funcionamento se dá atualmente e quais os problemas que lá
incorrem.
Outra forma de levantar informações a respeito do problema foi através de
pesquisa bibliográfica, onde se buscou livros, periódicos e artigos que abordassem o
assunto. Sendo importante ressaltar que o recolhimento de informações foi feito em
todas as áreas envolvidas neste trabalho, não somente aquela relacionada diretamente
com o problema. Áreas estas que passam a ser abordadas na seção seguinte.
20
1.7 CRONOGRAMA
O projeto segue o seguinte cronograma, que teve início no mês de julho a
dezembro de 2010, observando-se nele as atividades propostas e realizadas conforme
a Figura 1.
A primeira linha indica os meses de duração do projeto, de julho a dezembro de
2010.
A primeira coluna referencia cada uma das fases de desenvolvimento
apresentadas no item 1.6 (metodologia) e reproduzida na Figura 1. Os asteriscos
indicam os meses em que cada fase será desenvolvida.
Onde houver *, significa o cronograma previsto e onde houver sombreamento
representa o cronograma executado.
Meses - 2010
Fases do Projeto
Julh
o
Agosto
Sete
mbro
Outu
bro
Novem
bro
Dezem
bro
Fundamentação Teórica * *
Levantamento dos Requisitos
*
Modelo Entidades Relacionamentos
*
Análise do sistema
*
Desenvolvimento do Sistema
* *
Testes de Qualidade
* *
Entrega do Relatório e Artigo Parciais
*
Entrega do Relatório e Artigo Finais
*
Apresentação da Prática
*
Entrega do Relatório e Artigo Corrigidos
*
Fonte: BORDIN, RITTER, DALAZEN, LOVATO, SCHWENING, SEIBEL (2010).
Figura 1: Cronograma de Atividades do Projeto
21
1.8 RECURSOS
Computadores pessoais (e notebooks)
Pendrives
Livros
Softwares
1.9 ORÇAMENTO
Descrição Quantidade Valor Total
Impressão Projeto 25 R$ 0,12 R$ 3,00
Impressão Relatório Parcial 80 R$ 0,12 R$ 9,60
Impressão Artigo Parcial 12 R$ 0,12 R$ 1,44
Impressão Relatório Final 390 R$ 0,12 R$ 46,80
Impressão Artigo Final 12 R$ 0,12 R$ 1,44
Impressão Relatório Corrigido 130 R$ 0,12 R$ 15,60
Horas trabalhadas (x2) 120 R$ 12,00 R$ 1.440,00
Total: R$ 1.517,88
Fonte: BORDIN, RITTER, DALAZEN, LOVATO, SCHWENING, SEIBEL (2010).
Figura 2: Orçamento do projeto.
CAPÍTULO 2: FUNDAMENTAÇÃO TEÓRICA
Neste capítulo são abordados todos os assuntos empregados no
desenvolvimento deste trabalho, dando o devido enfoque para Sistemas de Produção,
que contém o embasamento necessário para a compreensão do problema que se
propôs resolver e também a respeito de Engenharia de Software, fornecendo o material
necessário para a melhor organização do projeto, seguindo padrões, modelos e boas
práticas descritas na literatura.
2.1 A EMPRESA
A Metalúrgica Fratelli foi fundada em julho de 1986 e está localizada no
município de Santa Rosa – RS. Atualmente possui certificação ISSO 9001:2004 e conta
com mais de 70 funcionários. Produz peças para colheitadeiras, tratores e outros
equipamentos não automotivos, tendo como principais clientes AGCO, John Deere e
Brunning (TABORDA, 2008).
2.2 ADMINISTRAÇÃO DA PRODUÇÃO
Na manufatura, a meta do plano agregado é nivelar a demanda dos produtos da
empresa com a sua capacidades ou habilidade de fornecê-los a um custo mínimo
(DAVIS; AQUILANO; CHASE, 2001).
23
O processo de planejamento agregado identifica os métodos alternativos para
compatibilizar a oferta e a demanda, segundo a perspectiva da Administração da
Produção (DAVIS; AQUILANO; CHASE, 2001).
2.2.1 Visão Geral das Atividades do Planejamento Operacional
O planejamento da produção se divide em escalas de tempo (longo, médio e
curto prazo), cada escala tem o seu nível de detalhamento, e se relaciona com outros
setores da empresa como vendas, marketing e gestão de pessoas (DAVIS; AQUILANO;
CHASE, 2001).
2.2.1.1 Planejamento de Longo Prazo
Normalmente feito todo ano em relação a um tempo geralmente maior que um
ano, mas este tempo varia de acordo com o tipo de atividade da empresa, pode ir de 5
a 10 anos (DAVIS; AQUILANO; CHASE, 2001).
O planejamento de longo prazo inicia com a declaração dos objetivos da
organização e suas metas para os próximos 2 a 10 anos. O planejamento estratégico
do grupo articula como esses objetivos e metas serão atingidas levando em conta a
capacitação da empresa e seu ambiente econômico e político, projetando sua previsão
de negócios (DAVIS; AQUILANO; CHASE, 2001).
Os elementos do planejamento estratégico incluem a delimitação da linha de
produtos, dos níveis de qualidade e preço e das metas de penetração no mercado. O
planejamento de recursos identifica as instalações, os equipamentos e o pessoal
necessário para viabilizar o plano de produção em longo prazo. Desta forma, é
frequentemente chamado de planejamento da capacidade em longo prazo (DAVIS;
AQUILANO; CHASE, 2001).
24
2.2.1.2 Planejamento de Médio Prazo
Para um período de 6 a 8 meses, planejado para o semestre e revisado a cada
trimestre, pois este planejamento já é mais específico (DAVIS; AQUILANO; CHASE,
2001).
No planejamento de médio prazo se faz o planejamento agregado da produção,
a previsão de vendas por item, o programa mestre de produção (PMP), e o
planejamento grosseiro da capacidade.
O plano agregado fornece ligação entre os planos estratégicos (longo prazo) e
o planejamento intermediário. Especifica a produção mensal ou trimestral necessária
para os principais grupos de produtos, fornece dados de quantas horas de trabalho
serão necessárias, e alocação de unidades de trabalho.
A previsão de vendas por item fornece dados para o plano mestre de produção,
monitorar essa informação denomina-se gestão da demanda.
O programa mestre de produção gera para o fabricante gera para o fabricante a
quantidade e os dados dos produtos finais individuais. Ele depende do plano de produto
e de mercado e do plano de recursos.
2.2.1.3 Planejamento de Curto Prazo
Para um período de um dia a 6 meses. Normalmente revisado semanalmente,
ou em alguns casos diariamente. É o planejamento fino da produção. Varia muito de
empresa para empresa (DAVIS; AQUILANO; CHASE, 2001).
Este plano é bem específico, e subdivide-se geralmente em outros, que são:
Plano de materiais – Considera as necessidades de materiais a partir do
PMP e explode suas submontagens e componentes. O plano de materiais
25
especifica quando a produção e os pedidos de compra devem ser
colocados para cada peça e para as submontagens, para que os produtos
sejam concluídos segundo a programação (DAVIS; AQUILANO; CHASE,
2001).
Planejamento das necessidades e de capacidade – Fornece uma
programação detalhada de quando cada operação deve ser executada em
cada centro de trabalho, e quanto tempo levará para ser processada
(DAVIS; AQUILANO; CHASE, 2001).
Programação da montagem final – Essa atividade identifica as diversas
operações necessárias para colocar o produto em sua forma final. É aqui
que o produto e suas características finais são programadas (DAVIS;
AQUILANO; CHASE, 2001).
Plano e controle de Entrada/Saída – Refere-se a uma variedade de
relatórios e procedimentos, ressaltando as demandas programadas e as
restrições de capacidade derivadas do plano de materiais (DAVIS;
AQUILANO; CHASE, 2001).
Controle das atividades de produção – A programação e o controle das
atividades no chão de fábrica. Envolve a programação e o controle das
atividades do dia a dia no chão de fábrica. Neste ponto, o programa mestre
de produção é alterado segundo as prioridades imediatas da organização
diária do trabalho (DAVIS; AQUILANO; CHASE, 2001).
Planejamento e controle das compras – O planejamento e controle de
entrada/saída são necessários para se certificar de que a aquisição não é
somente para obtenção de materiais em tempo de obedecer a
programação, mas também para se estar ciente sobre os mesmos, os
quais, por várias razões, podem ter as entregas programadas (DAVIS;
AQUILANO; CHASE, 2001).
26
Resumidamente, todas as abordagens de planejamento tentam equilibrar a
capacidade necessária com a capacidade disponível, e a partir daí programar e
controlar a produção levando em conta as mudanças no balaço de capacidade. Um
bom sistema de planejamento é completo quando, sem ser opressivo, tem a confiança
de seus usuários na estrutura da organização (DAVIS; AQUILANO; CHASE, 2001).
2.2.1.4 Estratégias do Planejamento da Produção
Existem, essencialmente, três estratégias de planejamento da produção. Essas
estratégias envolvem um compromisso entre a quantidade e a mão de obra, os horários
de trabalho, os estoques e outras reservas (DAVIS; AQUILANO; CHASE, 2001).
1. Estratégia de acompanhamento da demanda – Nivelar a taxa de produção
para atingir exatamente a taxa de saída exigida pela demanda, através da
contratação e da demissão de empregados. O sucesso desta estratégia
depende da existência de um grupo de candidatos a emprego, treinados,
prontos para serem contratados quando do aumento do volume de pedidos.
Existem impactos motivacionais óbvios. Quando as reservas de pedidos em
carteira estiverem baixas, os empregados podem se sentir-se compelidos a
reduzir a velocidade de produção pelo medo de serem demitidos, assim que
os pedidos existentes sejam concluídos.
2. Mão de obra estável, horas de trabalho variáveis – variar a produção
(saída) pela variação de número de horas trabalhadas através de
programações flexíveis de trabalho e de horas extras. Essa estratégia
fornece continuidade da mão de obra, e evita tanto os custos emocionais
como os tangíveis, de contratar e despedir pessoal, associados a estratégia
de acompanhamento da demanda.
3. Estratégia de capacidade constante – Manter a mão de obra estável
trabalhando com uma taxa de produção constante. A escassez e o excesso
são absorvidos pelos níveis flutuantes de estoques, de pedidos em carteira
27
e de vendas perdidas. Os empregados beneficiam-se das horas de trabalho
estáveis, mas os custos em estoque são aumentados. Outra preocupação é
a possibilidade dos produtos em estoque se tornarem obsoletos.
Quando apenas uma destas variantes é utilizada para absorver as flutuações
da demanda, tem-se uma estratégia pura; quando uma ou mais são utilizadas em
combinação, tem-se uma estratégia mista. Como você pode suspeitar, as estratégias
mistas são mais amplamente aplicadas na indústria (DAVIS; AQUILANO; CHASE,
2001).
A subcontratação também pode ser aplicada, isso se faz sob demanda, mas é
uma estratégia perigosa, o fabricante pode perder o controle sobre a programação e a
qualidade. A vantagem é de se estar trabalhando com uma pessoa jurídica e não física,
logo não há o desgaste de uma demissão (DAVIS; AQUILANO; CHASE, 2001).
2.2.2 Programação e Sequenciamento de um Ambiente Job Shop
Um Job Shop é uma organização funcional cujos departamentos ou centros de
trabalho são organizados em torno de processos particulares, os quais consistem em
tipos específicos de equipamentos e/ou operações, tais como perfuração e montagem
em uma fábrica, operações de leitura ótica (scanner) e impressão em um laboratório de
computação, ou salas para exames especiais e, uma emergência de um hospital
(DAVIS; AQUILANO; CHASE, 2001).
Uma programação é uma distribuição temporal utilizada para distribuir
atividades, utilizando recursos ou alocando instalações. A proposta da programação de
operações em uma Job Shop é desagregar o Programa Mestre de Produção (PMP) em
atividades semanais, diárias e por hora, sequenciadas no tempo – em outras palavras,
especificar em termos precisos a carga de trabalho planejada no processo de produção
para o curto prazo. O controle de operações monitora o progresso das ordens e,
quando necessário, expede ordens e ajusta a capacidade do sistema para assegurar o
cumprimento do PMP (DAVIS; AQUILANO; CHASE, 2001).
28
Ao projetar-se um sistema de programação e controle, deve-se tomar
providências para que se atinja um desempenho eficiente das seguintes funções:
4. Alocar ordens, equipamentos e pessoal para os centros de trabalho ou para
locais específicos. Essencialmente isto é o planejamento da capacidade no
curto prazo.
5. Determinar a sequencia da execução das ordens. Isto é, estabelecer tarefas
prioritárias.
6. Iniciar a execução do trabalho programado, normalmente denominado
despacho das ordens.
7. Controle do chão de fábrica, que envolve: revisar o status e controlar o
progresso das ordens conforme elas estejam sendo executadas; também
expedir ordens atrasadas e críticas.
8. Revisar a programação para contemplar alterações recentes nos status das
ordens.
9. Garantir que os padrões de controle de qualidade estão sendo atingidos.
A dificuldade em fazer-se essa programação encontram-se justifica nos
seguintes fatores:
Este bem/serviço pode nunca ter sido feito anteriormente; assim as
estimativas do tempo de duração esperado para a conclusão dos diversos
componentes pode ser bastante diferente do tempo real.
A sequencia de operações é extremamente flexível e, com uma mão de
obra multifuncional, o número de sequencias possíveis pode ser enorme.
29
Tentar avaliar os resultados esperados das diferentes sequencias com o
objetivo de encontrar a melhor é, normalmente muito difícil.
Para operações diferentes, o parâmetro para determinação da “melhor”
sequencia pode variar – em um caso pode ser a minimização do
desperdício, em outra pode ser a minimização do tempo ocioso das
instalações, e por um terceiro pode ser a maximização do ganho e assim
por diante. Assim mesmo com extensas pesquisas feitas no campo da
programação de Job Shops, é difícil encontrar algoritmos quantitativos que
sejam apropriados para todas as situações.
2.3 ENGENHARIA DE SOFTWARE
Toda a engenharia deve ter como base o foco na qualidade, e na engenharia de
software não é exceção. Esta é formada por várias camadas, sendo elas: foco na
qualidade, processos, métodos e ferramentas (PRESSMAN, 2006).
Os processos são aqueles responsáveis por unir as camadas da engenharia de
software. Através de processos se define o que será feito, como serão utilizadas as
tecnologias de engenharia de software. São fundamentais para o controle gerencial de
projetos, bem como torna mais organizado um projeto definindo a ele os passos que
devem ser seguidos de acordo com o tipo de projeto que se está desenvolvendo
(PRESSMAN, 2006).
Enquanto que os processos especificam o que fazer dentro de um projeto,
fornecendo as bases para o gerenciamento de projetos e organização do mesmo, os
métodos ficam encarregados de mostrar como fazer cada tarefa dentro de um projeto.
Exemplos de métodos podem ser: comunicação, planejamento, modelagem, construção
e implantação. E para auxiliar tanto os processos como os métodos de um projeto
podem ser utilizadas ferramentas de engenharia de software (PRESSMAN, 2006).
30
Como foi dito anteriormente, a definição dos processos que serão seguidos
depende do projeto que se está planejando executar. Mesmo com variações, grande
parte dos projetos é composta por fases comuns, como: especificação, modelagem e
implementação, validação e evolução (as necessidades mudam com o tempo)
(SOMMERVILLE, 2006).
Entretanto, existem modelos de processos para o desenvolvimento de
sistemas, estes modelos serão brevemente abordados na próxima seção deste
capítulo.
2.3.1 Modelos de Processos
De acordo com Sommerville (2006), modelos de processos são representações
abstratas de processos de software. Cada modelo possuir suas particularidades,
oferecendo uma perspectiva diferente dos processos. Os modelos mais conhecidos
são: modelo em cascata, desenvolvimento evolucionário e engenharia de software
baseada em componentes.
Além destes modelos, Pressman (2006) cita os modelos incrementais, como o
modelo RAD (Rapid Application Development) e o modelo incremental; os modelos
evolucionários, como a prototipagem, o modelo espiral, e o modelo de desenvolvimento
concorrente. Existem ainda os modelos de processos da metodologia ágil: XP, ASD,
DSDM, Scrum, Crystal, FDD, AM.
Serão abordados nas próximas seções os modelos que mais se aproximam
com o utilizado neste trabalho ou que tenham de alguma forma influenciado os
processos de desenvolvimento deste projeto.
2.3.1.1 Modelo em Cascata
Ele é conhecido como modelo em cascata porque todas as fases de software
estão colocadas em sequência, uma após a outra, sendo que uma fase não pode iniciar
31
antes de a fase anterior ter sido finalizada. Esse modelo está ilustrado na Figura 3
(SOMMERVILLE, 2006).
Fonte: SOMMERVILLE, 2006, p. 66.
Figura 3: Fases do modelo em cascata.
Uma das principais críticas a este modelo é exatamente pela sua característica
mais marcante, a disposição das fases de software em cascata. O principal problema
desta abordagem envolve a dificuldade de se concluir uma fase de um projeto sem
produzir sequer um erro ou cometer algum engano quanto aos requisitos dos
stakeholders. E isso é um problema, pois se os problemas não forem corrigidos logo no
início do projeto poderão custar muito mais para serem senados nas fases finais
(SOMMERVILLE, 2006).
Este modelo é ainda caracterizado pela produção de documentação em cada
fase de software, tornando-o compatível com vários outros modelos de processos. Por
outro lado, ele se mostra como um modelo com pouca flexibilidade e que não leva em
conta imprevistos implicados em projetos de software (SOMMERVILLE, 2006).
2.3.1.2 Prototipagem
Como o próprio nome insinua, trata-se de um modelo de processos baseado
em protótipos. Esta abordagem pode, na verdade, ser utilizada em qualquer outro
32
modelo de processos, mas seu uso fica concentrado em projetos onde não exista uma
definição concreta daquilo que deve ser construído (PRESSMAN, 2006).
Neste modelo uma definição dos objetivos do software é feita com o cliente,
identificando as necessidades e salientando pontos que não estão muito claros. Com
essas informações já é possível construir um protótipo do sistema, através deste
protótipo o cliente vai fornecendo mais informações sobre o que ele precisa. A Figura 4
ilustra o ciclo existente no modelo de prototipagem, reforçando que este modelo faz
parte dos modelos evolucionários (PRESSMAN, 2006).
Fonte: PRESSMAN, 2006, p. 43.
Figura 4: Modelo de prototipagem.
Este protótipo desenvolvido deverá ser descartável, ou seja, ela simplesmente
serve para que as necessidades dos clientes sejam melhor captadas. Até porque este
protótipo em grande parte das vezes não irá seguir padrões de desenvolvimento,
otimizações de código, boas práticas. É possível ainda que a linguagem utilizada pelo
protótipo não seja a mesma que será usada para o software final, sendo esta primeira
utilizada apenas por facilitar o desenvolvimento rápido de aplicações (PRESSMAN,
2006).
33
E é aí que alguns problemas aparecem e devem ser tratados com cuidado. O
primeiro é o desconhecimento por parte do cliente de que a aplicação que lhe foi
apresentada trata-se apenas de um protótipo e exige modificações no protótipo para
que ele possa usá-lo. E o outro problema é utilizar este protótipo como base para o
desenvolvimento do software final, e isso é um problema exatamente pelo fato de o
protótipo não ter um nível de qualidade muito bom (PRESSMAN, 2006).
É por isso que deve haver uma boa comunicação com o cliente, para deixar
claro os propósitos de se utilizar protótipos e que o verdadeiro software será
desenvolvido seguindo padrões de qualidade.
2.3.1.3 Modelo Espiral
O modelo em espiral foi proposto por Boehm e une a prototipagem e o modelo
em cascata. O projeto passa a ser executado de forma cíclica, sendo que a cada ciclo o
software vai evoluindo. Sendo que a cada ciclo o planejamento do projeto é reajustado
de acordo com as circunstâncias (PRESSMAN, 2006).
Na Figura 5 percebe-se que as atividades do projeto vão sendo executadas em
sentido horário e que a cada novo ciclo uma nova análise dos riscos é feita, bem como
o protótipo evolui. Dentre as vantagens dessa abordagem está a redução dos riscos em
um projeto, além do desenvolvimento de protótipos ao longo dos ciclos do projeto. Esse
modelo leva em consideração que os softwares não são estáticos, mas sim que eles
também tendem a evoluir com o tempo (PRESSMAN, 2006).
34
Fonte: SOMMERVILLE, 2006, p. 74.
Figura 5: Modelo em espiral.
Dentre os problemas deste modelo estão o fato de o orçamento do projeto ser
revisado a cada ciclo, e quando organizações exigem orçamentos fixos isso pode se
tornar um problema. A análise dos riscos também é feita a cada ciclo do projeto, e isso
é muito bom, o que pode ser um problema é o levantamento precário dos riscos
envolvidos no projeto, o que pode gerar problemas (PRESSMAN, 2006).
2.3.1.4 XP (eXtreme Programming)
XP é uma metodologia “peso-leve” para equipes de desenvolvimento de
software de pequeno e médio porte, focada principalmente em projetos com requisitos
que tendem a mudar com freqüência ou que não sejam muito claros (BECK, 1999).
As idéias e métodos de XP foram abordados pela primeira vez na década de
1980. Entretanto, apenas ganharam notoriedade quando Kent Beck fez uma publicação
sobre o assunto, Beck (1999) (PRESSMAN, 2006).
35
Para Beck (1999) é fato que muitas das idéias que compõe XP fazem parte do
senso comum, com a diferença que eXtreme significa que estas idéias devem ser
levadas realmente ao máximo, dentre elas tem-se:
Revisar o código a toda hora (programação em pares).
Testar o tempo todo (testes de unidade), até mesmo os requisitos do cliente
(testes funcionais).
Melhorar a modelagem do sistema com refatoração de código.
Simplificar ao máximo a modelagem do sistema (KISS).
Definir e melhorar a arquitetura sempre.
Integrar e testar ela várias vezes por dia.
Iterações com durações curtas, as mais curtas possíveis.
Através dessas idéias Beck (1999) queria que programadores pudessem se
preocupar com aquilo que realmente tinha importância dentro de um projeto, tomando
as decisões naquilo que eles melhor sabem e sempre com ajuda para encarar os
problemas. E do outro lado, para os consumidores (ou clientes) e gerentes, XP traria
maior rendimento ao desenvolvimento, mostrando resultados concretos em direção aos
objetivos dentro de poucas semanas. Além disso, mudanças poderiam ser feitas no
meio do projeto sem que isso implicasse custos exorbitantes.
36
Fonte: PRESSMAN, 2006, p. 64.
Figura 6: O processo extreme programming.
Na Figura 6 o modelo de processos do XP é claramente cíclico. Tratam-se de
iterações ou incrementos do projeto, e em cada iteração todas as fases (ou melhor,
atividades) descritas acima são executadas.
A primeira atividade descrita é o planejamento. Aqui serão criadas as histórias
que descrevem funcionalidades e características que o software deve ter. Elas são
criadas pelos clientes e colocadas em cartões juntamente com um valor que irá definir a
prioridade da história. Depois de reunidos os cartões, a equipe do projeto irá estimar o
custo em tempo das histórias, aquelas com alto custo serão re-avaliadas com o cliente
para serem divididas em mais de uma história (PRESSMAN, 2006).
Nesta atividade são ainda definidas quais as histórias que serão
implementadas, o que pode variar da quantidade de histórias que foram criadas. Depois
da primeira iteração será possível então estimar o tempo que levará para terminar o
projeto (PRESSMAN, 2006).
Na fase de projeto o único produto resultante serão os cartões CRC (Class-
Resposability-Colaborator), que servem para identificar as classes de objetos relevantes
37
às histórias que serão implementadas no incremento corrente. Além disso, protótipos
podem ser criados caso sejam encontradas dificuldades em alguma história, isso é
importante para que os riscos envolvidos sejam reduzidos (PRESSMAN, 2006).
Falando em riscos, é importante frisar a preocupação que XP tem com os riscos
envolvidos em projetos de software. É por isso que existem iterações com períodos
curtos de tempo, evitando assim acúmulo de atrasos durante o projeto e as histórias de
maior prioridade tem sempre a preferência, enquanto que as que por ventura atrasaram
passam a ter menor prioridade (BECK, 1999).
Outras atitudes que ajudam na redução de riscos são a atenção aos testes,
estes realizados diversas vezes por dia através de testes de unidade e com a exigência
de sempre se ter um sistema funcional. Em adição a esta atitude está a programação
em duplas que tem mostrado grande efetividade na redução da taxa de erros de
software. E outra atitude muito importante é o envolvimento do cliente com o projeto,
sendo que este passa a fazer parte da equipe, sempre dando feedback sobre os
resultados obtidos (BECK, 1999).
Dentro do projeto pode haver ainda a refatoração (refactoring ou refabricação)
do código criado durante as iterações anteriores. A refatoração trata de tornar o código
mais claro, sem que isso altere o comportamento do mesmo. Ou como Fowler et al.
(1999) coloca: “É uma forma disciplinada de limpar o código que minimiza as chances
de se introduzir bugs.”.
Na codificação a primeira coisa que deve ser feita é a construção de testes de
unidade para cada uma das histórias que serão implementadas na iteração atual.
Depois de construídos os testes o desenvolvedor passa a implementar as funções para
a execução das histórias e tão logo tenha implementado-as pode efetuar os testes de
unidades para verificar se a codificação está em concordância com os testes
(PRESSMAN, 2006).
38
Outro ponto forte de XP quanto à atividade de codificação é a programação em
pares. Isso mostra a preocupação desta metodologia em prover softwares de
qualidade, pois através da programação em pares a descoberta de erros é muito mais
rápida, além disso, com duas pessoas debruçadas sobre o mesmo código mais idéias
irão surgir e consequentemente implementações mais criativas e eficientes. E como
mais uma medida para garantir a qualidade e reduzir os erros, a integração do sistema
é feita diariamente (integração contínua), isso evita problemas de compatibilidade e
interface.
Ficou evidente que XP é muito enfático quanto à realização contínua de testes
em um sistema, principalmente durante a codificação do sistema. Ainda assim, uma
atividade da iteração é reservada somente para a realização de testes. Nesta atividade,
os testes unitários (ou de unidade) são organizados de forma sequencial,
principalmente porque muitos testes são interdependentes. Isso vêm a facilitar os testes
de integração e validação, possibilitando tais verificações diariamente sem muito custo
(PRESSMAN, 2006).
E por último, são efetuados os testes dos clientes, este tem por finalidade
verificar a conformidade do sistema com as histórias criadas pelos clientes. O teste
valida o sistema pela perspectiva do cliente (PRESSMAN, 2006).
2.3.2 Fases de um Projeto
A seguir serão abordadas as principais fases de um projeto, elas são as
principais, pois a maioria dos modelos de processos faz uso delas, embora elas possam
ser arranjadas de formas diferentes, conforme pôde ser visualizado nas seções
anteriores.
Cada fase de um projeto corresponde a uma etapa que deve ser executada
para que o objetivo principal do projeto seja alcançado. Uma fase na maioria das vezes,
se não todas, tem por objetivo gerar um produto. Este não precisa necessariamente ser
parte dos entregáveis de um projeto, ele pode estar relacionado mais com o
39
gerenciamento de projetos e pode ocorrer uma ou mais vezes, dependendo da
abordagem escolhida.
2.3.2.1 Levantamento dos Requisitos
O levantamento de requisitos, também chamado de fase de Comunicação por
Pressman (2006), pode ser considerado uma das mais importantes fases em um
projeto, pois ela é a responsável pela captação dos requisitos que serviram de base
para a execução de todas as outras fases do projeto. E finalmente, para o sistema em
questão que, quando entregue, deverá atender as necessidades dos usuários
explicitadas em requisitos.
Daí a importância de se captar corretamente os requisitos dos usuários. E essa
questão está totalmente relacionada com a forma que a comunicação é desenvolvida
entre clientes e membros da equipe de projeto (como o gerente de projeto, analista).
Uma comunicação clara e onde exista compreensão de ambas as partes com certeza
irá fornecer requisitos muito mais consistentes e consequentemente o produto, quando
entregue, terá muito mais chances de atender as necessidades dos clientes e de fato
agregar valor a sua organização (PRESSMAN, 2006).
Sommerville (2006) deixa claro que deve haver distinção entre os tipos de
requisitos, do usuário e do sistema. Enquanto o primeiro trata do quê o sistema deve
atender e sobre quais circunstâncias, utilizando uma linguagem de mais fácil
compreensão; o segundo aborda as funcionalidades do sistema de forma mais técnica,
informando precisamente o que cada funcionalidade deve fazer, sobre quais
circunstâncias e qualquer outro detalhe pertinente.
E qual o motivo de existirem dois tipos de requisitos? Simples, porque cada um
deles é direcionado para diferentes leitores. Descrições de requisitos em linguagem
mais simples e que não trata o problema nos mínimos detalhes está direcionada para
os clientes que não precisam conhecer exatamente como será implementada a
40
funcionalidade, contanto que ele saiba que ela estará sendo contemplada da forma que
foi acordada.
Por sua vez, os requisitos de sistema estão sub-divididos em três categorias,
sendo elas:
Requisitos funcionais: descrevem as funcionalidades que o sistema deve
possuir e como ele deve reagir em determinadas situações.
Requisitos Não-funcionais: descreve funcionalidades do sistema como um
todo, estas podendo ser algum tipo de serviço ou função, geralmente este
tipo de requisito trata de questões não relacionadas com o problema
principal, mas que mesmo assim precisam ser em algum ponto definidas.
Vale ressaltar que não atingir um requisito não-funcional pode significar que
o sistema não poderá ser usado pelos usuários, levando em conta que
requisitos desta natureza podem exigir níveis de confiabilidade, segurança,
performance, dentre outros. Descrições mais detalhadas sobre atributos do
software podem ser vistas na seção 2.3.3.1 que aborda a qualidade do
produto de software.
Requisitos de domínio: são aqueles relacionados diretamente com o
ambiente onde estará inserido o sistema.
Os requisitos não funcionais podem ainda ser divididos em vários tipos, de
acordo com o atributo que se busca atender em um software. Na Figura 7 é possível
visualizar a estrutura dos tipos de requisitos em forma hierárquica. Basicamente
existem os requisitos não-funcionais do produto, que dizem respeito ao comportamento
do produto; os da organização, que dizem respeito a políticas e padrões que definem
como o projeto deverá ser executado; e os externos, estes relacionados com qualquer
coisa externa ao sistema, desde legislações até a integração com outros sistemas
existentes (SOMMERVILLE, 2006).
41
Fonte: SOMMERVILLE, 2006, p. 122.
Figura 7: Tipos de requisites não-funcionais.
Quanto à forma pela qual serão apresentados os requisitos, Sommerville (2006)
coloca em seu livro alguns exemplos, dos quais um foi escolhido (Figura 8) por mostrar
riqueza em detalhamento, o que não significa que ele deva ser seguido na construção
dos requisitos, mas que serve de base para a construção de um modelo próprio, se
necessário.
O exemplo da Figura 8 tem em seu cabeçalho (em fundo preto) o nome do
requisito, no caso o controle de insulina. Na função, é feita uma breve descrição sobre o
que esse requisito deverá fazer, enquanto que a descrição se encarrega de detalhar
melhor como isso será feito. A entrada é aquilo que se faz necessário para atingir o
objetivo, a fonte é de onde esta entrada veio e a saída é o resultado que se obteve
através do processamento das entradas, este descrito em detalhes na ação. Além
disso, para que o requisito aconteça se fazem necessários alguns requisitos, bem como
pré-condições, executando o requisito e obtendo uma pós-condição e eventuais efeitos
colaterais (SOMMERVILLE, 2006).
42
Fonte: SOMMERVILLE, 2006, p. 132.
Figura 8: Exemplo de requisito de sistema.
Com foi descrito nos parágrafos anteriores, existe uma grande importância em
se descrever requisitos de software de forma completa e não ambígua. Foi pensando
nisso que foi criada a IEEE 830, um documento que contém as práticas recomendadas
para a especificação de requisitos de software (SRS – Software Requirements
Specification).
2.3.2.2 Análise
Yeates e Wakefield (2004) descrevem a fase de análise como sendo a
responsável pela especificação dos requisitos do negócio e da plataforma técnica e
como será realizado o desenvolvimento do sistema. A análise tem como objetivo a
modelagem e descrição detalhada do sistema através de diagramas. Estes devem
43
fornecer uma visão do sistema sob diversas perspectivas, de modo claro e simples
(PRESSMAN, 2006).
Existem duas abordagens principais para a modelagem de análise: estruturada
e orientada a objetos. Este trabalho adota a orientação a objetos, mais especificamente
a UML (Unified Modeling Language) (PRESSMAN, 2006).
A orientação a objetos é um paradigma adotado pela maioria das linguagens
modernas de programação, principalmente por facilitar a compreensão do sistema e
desenvolvimento, além de facilitar a reutilização de códigos e criação de testes.
Com a larga adoção do novo paradigma pelas novas linguagens de
programação, passou-se a ter a necessidade de uma linguagem que possibilita-se a
modelagem de sistemas dentro deste novo paradigma. A união de diversos modelos
deu origem a UML, hoje padrão na análise de sistemas orientados a objetos, formada
por diversos diagramas que tem por objetivo mostrar o sistema sob um ângulo
específico de visão.
Booch, Rumbaugh e Jacobson (2005) colocam entre os principais objetivos da
análise de sistemas:
Visualizar um sistema como ele é ou deve ser.
Especificar a estrutura e comportamento de um sistema.
Uso de um modelo padrão que permita a construção do sistema.
Documentação do sistema construído.
Apesar das vantagens que a UML pode trazer para a modelagem de um
sistema, e isso é evidenciado por Booch, Rumbaugh e Jacobson (2005), é importante
lembrar que apenas criar diagramas não irá abençoar um sistema, pois a modelagem é
44
apenas mais uma etapa dentre várias da engenharia de software que poderão garantir
a qualidade do produto entregue. Alex Bell (2004) descreve em seu artigo “Death by
UML Fever” alguns dos sintomas preocupantes com a relação à UML na engenharia de
software.
Pressman (2006) ainda faz menção a modelagem de dados que, neste caso,
faz uso do modelo de entidade-relacionamento (MER). É o modelo mais utilizado para a
modelagem de bancos de dados relacionais. Uma descrição mais detalhada pode ser
obtida na seção 2.4 deste trabalho.
2.3.2.2 Projeto
O projeto de software se situa entre a análise e a codificação do sistema. Nesta
fase são criados modelos do software que, diferentemente do modelo de análise,
buscam detalhar as interfaces, arquitetura, estrutura de dados e componentes
necessários para a construção do sistema (PRESSMAN, 2006).
A Figura 9 demonstra a conversão de um modelo de análise para um modelo
de projeto, indicando que elementos da análise são usados para formar cada um dos
modelos de projeto, estes dispostos em pirâmide. Através dos elementos baseados em
classes (diagramas de classe, modelo crc) é possível criar o projeto de dados e melhor
detalhamento das classes no projeto de classes (PRESSMAN, 2006).
Enquanto isso, o projeto arquitetural se alimenta dos elementos de classes e de
fluxos definindo “[...] os relacionamentos entre os principais elementos estruturais do
software, os estilos arquiteturais e padrões de projeto que podem ser usados para
satisfazer os requisitos definidos para o sistema [...]” (PRESSMAN, 2006, p. 187).
No projeto de interfaces se define a comunicação do sistema com outros
sistemas, as entradas e saídas dele e como elas ocorrerão. E, à partir dos elementos
de classes, fluxo e comportamento se forma o projeto em nível de componente, que
descreve de forma procedural os componentes deste software (PRESSMAN, 2006).
45
Fonte: PRESSMAN, 2006, p. 187.
Figura 9: Tradução do modelo de análise para um modelo de projeto.
Projeto em engenharia de software significa qualidade, e nas palavras de
Pressman (2006, p. 187), essa fase irá servir de base “[...] para todos os passos de
engenharia de software e de suporte de software que se seguem.”
O resultado do projeto é uma documentação que descreve em detalhes o
sistema em construção. A tendência de tal documentação é aumentar o nível de
detalhamento a cada iteração do projeto. Para que seja um projeto de qualidade, a
documentação deve contemplar todos os requisitos do sistema, implícitos e explícitos;
deve fornecer informações suficientes para a codificação, teste e manutenção do
sistema; e deve abranger tudo a respeito do sistema (PRESSMAN, 2006).
Segundo Pressman (2006), um projeto de qualidade deve apresentar as
seguintes diretrizes:
Arquitetura: organização dos módulos de um sistema, a forma como
interagem entre si e as estruturas de dados utilizadas.
46
Padrões: utilizar soluções comprovadas para a solução de problemas
específicos de um projeto.
Modularidade: dividir um sistema em partes menores, isso facilita a
compreensão das partes. Entretanto, quando se atinge um número muito
grande de módulos o custo do projeto e de integração passa a ser alto,
anulando as vantagens dessa diretriz.
Ocultamento da Informação: estende as características da modularidade
ao esconder dados e operações que não precisam ser conhecidas pelos
outros módulos. Além disso, isso facilita teste, manutenção e limita a
propagação de erros dentro do sistema.
Independência Funcional: envolve tanto a modularidade como o
ocultamento de informações. A principal idéia aqui é tornar o mais
independente possível cada módulo, sendo que a comunicação deve
acontecer através de interfaces simples, evitando o máximo de
interdependência entre módulos.
Refinamento: ir aprofundamento as especificações do sistema a cada
elaboração. Facilita a criação do modelo de projeto por partes, sendo que a
cada melhoramento mais detalhes serão agregados ao modelo.
Refabricação: por vezes refatoração, é muito incentivado em metodologias
ágeis, muito bem abordado por Fowler et al. (1999). Basicamente trata-se
de melhorar o projeto ou código do sistema, removendo redundâncias,
melhorando a compreensão e desempenho (para códigos) sem modificar o
comportamento externo. O tópico é melhor abordado na seção 2.3.5.
Classes de Projeto: são refinamentos das classes criadas para a
compreensão do negócio na fase de análise. Estas classes se subdividem
47
em: classes de interface com o usuário, classes do domínio de negócio,
classes de processo, classes persistentes e classes de sistema.
Na Figura 9 foi possível ver quais os elementos fornecidos pela análise que são
utilizados para a construção dos modelos de projeto. Já a Figura 10 mostra um gráfico
do nível de abstração e dos processos em relação aos modelos de análise e projeto.
Estando o primeiro dentro das dimensões mais abstratas e o segundo com baixa
abstração, significando que ele aborda mais a fundo as questões técnicas do sistema.
Quanto aos processos, eles descrevem o nível de evolução do projeto.
Fonte: PRESSMAN, 2006, p. 198.
Figura 10: Dimensões do modelo do projeto.
Os elementos de arquitetura são a base para o projeto, e se baseiam em
classes, subsistemas e diagramas de colaboração. Já os elementos de interface se
preocupam especificamente com o fluxo de dados dentro do sistema. Em nível de
componente o que existe é uma descrição detalhada de cada componente, como se dá
o processamento dos dados dentro deste componente e como será a interface que dará
48
acesso a esse componente. E em nível de implantação trata de onde serão alocados
fisicamente o software e outros sistemas utilizados por ele (PRESSMAN, 2006).
2.3.2.4 Desenvolvimento
Essa fase recebe como entrada a documentação do projeto e análise e
desenvolve ou adquire os componentes necessários para se implementar todos os
requisitos do sistema ou, em modelos de processo com iterações, os requisitos
planejados para a iteração. Nessa fase também são construídos os testes unitários e é
feita a integração do sistema (PRESSMAN, 2006).
Como foi dito acima, nesta fase também são desenvolvidos os testes unitários.
Estes testes têm por objetivo testar as funcionalidades de cada método das classes de
um sistema. Testes unitários são testes automatizados, ou seja, eles devem ser bem
escritos uma vez e depois é apenas executá-los para verificar se existem ou não erros
no código.
Dentro de XP é considerada uma boa prática escrever antes o teste e depois
implementar os métodos da classe que deve estar em conformidade com o teste. Para
Beck (1999) os testes têm uma perspectiva de longo e curto prazo. Em longo prazo o
programa tende a viver mais, pois mais mudanças podem ser feitas e a escrita de mais
testes aumenta a confiança no sistema.
Em curto prazo programadores conseguem testar todo o seu sistema
simplesmente ao apertar um botão. Além disso, escrever testes aumenta a
produtividade, pois não se perde tempo posterior debugando o código escrito (BECK,
1999).
2.3.2.5 Testes
Os testes dentro de um projeto de software existem para garantir que o
programa que está sendo desenvolvido esteja de acordo com as especificações e que
49
entregue um produto de acordo com as expectativas dos clientes (SOMMERVILLE,
2006).
Para Beck (1999), funcionalidades de software que não podem ser testadas não
existem. O autor ainda traz o conceito de escrever os testes antes de codificar, ou seja,
pensar no que é preciso e só depois implementar o que é necessário.
Dentro da fase de testes existem dois processos distintos, são eles: verificação
e validação. O primeiro se encarrega de verificar se o software está sendo desenvolvido
corretamente, enquanto o segundo verifica se o software está de acordo com as
especificações. O teste, segundo Pressman (2006) é a última fase na qual se pode
avaliar a qualidade de um software, e como afirma o autor, a qualidade não é obtida
com testes, ela é apenas confirmada, sua obtenção só se dá através de métodos
corretos de engenharia de software, boas praticas e correta gestão do projeto.
Muitas pessoas, quando pensam em teste, imaginam que esta é uma fase que
deve ser realizada por pessoas de fora da organização que aparecem do nada e fazem
os testes. Quanto aos desenvolvedores existe aquela sensação de que as pessoas que
vão realizar os testes vieram apenas para destruir aquilo que foi feito com tanto esforço.
E, por outro lado, espera-se que esta equipe de testes resolva todos os problemas do
sistema (PRESSMAN, 2006).
Todas as situações descritas acima por muitas vezes acontecem, o que não as
torna algo verdadeiro, pelo menos não deveria ocorrer desta forma. Primeiro porque a
equipe que irá desenvolver os testes deve estar envolvida também nas fases de análise
e projeto do sistema, afinal eles devem estar envolvidos com a forma pela qual o
sistema está sendo concebido e também porque com este envolvimento o
conhecimento a respeito do sistema ficará muito maior quando forem feitos os testes
(PRESSMAN, 2006).
Também não é verdade que os desenvolvedores não devem realizar testes,
pelo contrário, são eles que irão fazer os primeiros testes no sistema. Estes geralmente
50
são os testes unitários, que serão abordados mais a frente. Outros testes que também
podem ser realizados pelos desenvolvedores são os testes de integração, que irão
integrar módulos e garantir que estes estão se comunicando corretamente
(PRESSMAN, 2006).
Por fim, os desenvolvedores do sistema devem sim estar envolvidos na
realização dos testes juntamente com as equipes de testes, para garantir que os testes
serão rigorosos, além de que eventuais erros podem ser imediatamente corrigidos pelo
desenvolvedor.
Pressman (2006) define duas estratégias para testes de software, a primeira é a
abordagem convencional e a segunda é a abordagem orientada a objetos. Como este
trabalho terá sua análise e desenvolvimento orientados a objetos é conveniente abordar
apenas a segunda estratégia de testes, o que acontece na seção abaixo.
2.3.2.5.1 Teste de Software Orientado a Objetos
Pressman (2006, p. 302) diz o seguinte: “O objetivo do teste é simplesmente
encontrar o maior número possível de erros com uma quantidade de esforço
gerenciável aplicada durante um intervalo de tempo realístico.”. O autor coloca ainda
que esse conceito é verdadeiro tanto para as estratégias tradicionais de teste como
para as orientadas a objetos (OO), o que muda aqui é como serão feitos os testes, as
táticas de teste.
Seguindo Pressman (2006), as principais mudanças em questões estratégicas
quanto aos testes se dão nos testes unitários (ou de unidade) e nos testes de
integração. Estes dois assuntos serão abordados nas próximas seções juntamente com
testes de validação e de sistema.
51
2.3.2.5.2 Teste de Unidade
Segundo Sommerville (2006), testes unitários são os responsáveis por testar
componentes individuais de um sistema. Trazendo isso para o paradigma da orientação
a objetos, testes unitários ficam encarregados de testar os métodos das classes. Testes
unitários são escritos pelos próprios programadores, como afirma Beck (1999).
Sommerville (2006) coloca ainda que testes unitários podem ser direcionados
para componentes, mesmo na orientação a objetos, pois estes componentes podem ser
formados por várias classes e possuírem uma interface em comum para acessar as
funcionalidades. É algo como um conjunto de classes internas, cada uma com seu
papel bem definido e que juntas são capazes de executar determinadas tarefas e é aí
que entra a interface que irá fazer a comunicação entre as classes internas e com o
exterior do componente.
Seguindo o exemplo acima, os testes unitários podem ser escritos para cada
uma das classes que compõe o componente, testando cada um dos métodos de cada
classe. E também podem ser escritos testes que irão verificar o componente através de
sua interface. Essa abordagem já pode ser considerada como teste de integração, pois
lida com funcionalidades que existem através da colaboração de várias classes. Testes
de integração serão abordados na próxima seção.
Voltando para a classe como unidade isolada, Sommerville (2006) coloca três
pontos que precisam ser testados em uma classe:
Todos os métodos associados à classe.
A atribuição e verificação de todos os atributos da classe. O autor se refere
a essas operações como setting e interrogation, algo bem próximo aos
getters e setters usados nas classes para atribuir e resgatar valores de
atributos das classes.
52
Simular todas as possíveis mudanças de estados de uma classe.
Enquanto os dois primeiros testes de classe são isolados, o último teste
(simulação de estados) é o mais importante, porque este tipo de teste irá testar vários
métodos da classe de uma só vez. Ele é o teste que mais se aproxima da realidade,
porque métodos de classes geralmente interagem entre si para desempenhar uma
funcionalidade e testar os métodos separadamente é importante, mas apenas testando
eles de forma integrada é possível saber se a classe realmente entrega as
funcionalidades que fornece (SOMMERVILLE, 2006).
Atualmente existem muitos frameworks disponíveis para a criação de testes de
unidade automatizados. Este trabalho irá utilizar o JUnit, um framework em Java que
permite a criação de testes unitários e a execução automática dos mesmos. Mais
detalhes na seção 2.5.4.
2.3.2.5.3 Teste de Integração
Quando se fala em orientação a objetos outro teste que precisa de estratégias
específicas para este paradigma é o teste de integração, ou melhor, os testes de
integração, levando em conta que muitos devem ser conduzidos até a conclusão do
sistema.
Pressman (2006) coloca duas principais estratégias para se desenvolver testes
de integração OO:
Teste baseado no caminho de execução – segue mais ou menos a idéia de
componentes, só que neste caso o teste é feito em cima de uma
funcionalidade do sistema. Geralmente uma funcionalidade precisa de
várias classes para ser desempenhado, este teste visa verificar se a
funcionalidade está de fato sendo realizada corretamente.
53
Teste baseado no uso – divide as classes em camadas, de acordo com sua
dependência em relação a outras classes. Assim, os testes iniciam com as
classes independentes e vai abrangendo aquelas que dependem de outras
para desempenhar o seu papel até que todo o sistema tenha sido coberto
pelos testes.
Testes de integração podem contar ainda com pseudocontroladores e
pseudocontrolados. Os primeiros podem ser utilizados para testar classes, conjuntos de
classes ou mesmo para simular funcionalidades sem que a interface gráfica esteja
construída. E os últimos podem ser empregados em testes que envolvem a colaboração
entre várias classes e uma ou mais delas ainda não foi construída (PRESSMAN, 2006).
Esta pode ser considerada com a última etapa de testes onde há distinção entre
softwares convencionais e softwares que aplicam o paradigma da orientação a objetos.
Daqui para frente os testes conduzidos serão focados naquilo que é visível para o
usuário, ou seja, o produto final. Começando pelo teste de validação, visto a seguir.
2.3.2.5.4 Teste de Validação
Como foi exposto no parágrafo anterior, o teste de validação independe de se o
software foi ou não construído com orientação a objetos. A validação busca asseverar
se o produto, sob o mesmo ponto de vista do usuário, está de acordo com as
especificações definidas nos requisitos do sistema (PRESSMAN, 2006).
Para se validar um software é preciso criar um plano de testes, neste plano
serão definidas as classes de testes que deveram ser conduzidas bem como os casos
de testes projetados.
Casos de teste têm por objetivo verificar uma funcionalidade do sistema, onde
são selecionadas as entradas que serão feitas no sistema e é feita a documentação das
saídas esperadas. Recomenda-se aqui a automatização desses testes, principalmente
pela economia de tempo (SOMMERVILLE, 2006).
54
Sommerville (2006) faz ainda a divisão dos casos de teste em: teste baseado
em requisitos, teste particionado e teste estrutural. O primeiro serve para validar os
requisitos do sistema, o segundo divide os dados do sistema em grupos (partições) de
acordo com as semelhanças e cria testes com entradas e saídas de todas estas
partições, e o terceiro busca criar conjuntos de testes que verifiquem todas as
funcionalidades do sistema.
Os testes baseados em requisitos destacam a importância de se descrever bem
os requisitos do sistema, pois requisitos devem ser testáveis. Testes de requisitos,
como afirma Sommerville (2006), tem por objetivo validar e não encontrar erros. A
diferença é que um sistema pode estar livre de erros e ainda assim não satisfazer as
necessidades dos clientes, por isso testes baseados em requisitos são importantes.
Com tantos meios de se realizar testes e validar o sistema deve haver alguma
forma de relatar esses erros. Pressman (2006) faz menção a lista de deficiências, que
descreve os desvios de especificação e erros do sistema. Através desta lista se darão
as negociações com clientes para a resolução dos problemas, lembrando que testes de
validação geralmente são efetuados após o desenvolvimento do sistema, o que
significa que eventuais correções podem alterar a data de entrega do produto.
2.3.2.5.5 Teste de Sistema
“Teste de sistema é [...] uma série de diferentes testes cuja finalidade principal é
exercitar por completo o sistema baseado em computador.” (PRESSMAN, 2006, p.
306). Essa série de diferentes testes pode ser classificada em vários tipos, de acordo
com Pressman (2006), que são:
Teste de recuperação – são testes que forçam o sistema a falhar e avaliam
se ele se recuperou corretamente. Também é feita a medição do tempo de
recuperação, sendo que este pode estar dividido em tempo de correção
(quando o sistema se recupera sozinho) e reparo (quando se faz necessária
a intervenção humana para recuperação do sistema).
55
Teste de segurança – busca verificar as vulnerabilidades de um sistema
através de todo e qualquer artifício e técnica disponível para de alguma
forma invadir, danificar ou prejudicar o sistema ou seus usuários. Sistemas
organizacionais, por exemplo, podem conter informações valiosas que não
devem cair nas mãos de concorrentes, com instituições bancárias as
informações são mais sensíveis ainda. Ataques com intenção de derrubar
um sistema podem causar prejuízos enormes a cada hora em que
permanecem fora do ar. Enfim, o nível de segurança de um sistema
depende de muito da situação, mas como Pressman (2006, p. 306) afirma,
a questão é “[...] tornar o custo da invasão maior do que o valor da
informação que será obtida.”
Teste de estresse – tenta colocar o sistema sob condições extremas para
verificar até onde ele consegue agüentar. Esse tipo de teste diz muito a
respeito da escalabilidade do sistema e pode ser exemplificado com algo
como: “hoje o sistema tem em média 10 operações por minuto, mas será
que quando houver 1000 operações por minuto ele irá agüentar?”.
Teste de desempenho – verificam o desempenho do sistema em tempo de
execução. Várias variáveis podem ser coletadas para avaliar o desempenho
de um sistema e diagnosticar as causas dos problemas envolvendo o
sistema em teste.
2.3.2.5.6 Depuração
Segundo Pressman (2006), o resultado de testes bem sucedidos é a depuração
dos erros encontrados. Esse processo consiste em identificar as causas para os
sintomas detectados nos casos de teste e corrigi-los. O que pode acontecer em alguns
casos é que o engenheiro de software não consegue encontrar as causas para aqueles
sintomas. Nesses casos, ele irá (deveria ao menos) criar casos de teste com base em
suspeitas para verificar se alguma delas é verdadeira e então corrigir o erro.
56
Para corrigir o erro Pressman (2006) coloca três estratégias:
Força bruta: pode ser considerado o último recurso para se corrigir um erro,
quando nada mais funcionou. Como o próprio nome insinua, trata-se de
testar tudo o que for possível até encontrar o erro ou perder considerável
tempo e desistir.
Rastreamento: é partir da fonte do sintoma e ir percorrendo os possíveis
caminhos que levam ao erro através do código fonte. O autor adverte que à
medida que o programa vai crescendo também cresce a dificuldade de se
rastrear erros.
Eliminação da causa: os dados relacionados aos sintomas são organizados
e uma lista de causas potenciais é feita. Hipóteses podem ser
desenvolvidas e através dos dados conhecidos pode ser possível aceitar ou
refutar a hipótese. Casos de teste também são conduzidos para verificar se
a hipótese é ou não verdadeira.
Aliado a estas estratégias estão ferramentas que podem auxiliar na descoberta
das causas dos erros. Alguns ambientes integrados de desenvolvimento (IDE –
Integrated Development Environment), por exemplo, fornecem ferramentas para
correção de erros de sintaxe no código e debuggers que permitem ao desenvolvedor
percorrer o código passo a passo até o momento em que o erro ocorreu.
Pressman (2006) também ressalta os cuidados que devem ser tomados ao se
efetuar a correção do código defeituoso. O primeiro cuidado diz respeito à lógica
utilizada no trecho defeituoso, eventualmente o erro pode ter ocorrido devido a uma
interpretação errada e é preciso verificar se esse erro de lógica não foi introduzido em
outras partes do código.
O segundo cuidado que deve ser tomado é com relação aos erros que podem
ser desencadeados com a correção do erro original. E o terceiro cuidado, ou conselho,
57
é a importância de se identificar as atitudes que poderiam ter sido tomadas para evitar a
ocorrência do erro, e não somente no projeto em questão, mas em qualquer outro
projeto futuro (PRESSMAN, 2006).
Esse último cuidado lembra muito o sistema de produção da Toyota devido à
ênfase dada aos erros na produção. Quando um erro ocorre, a produção deve
imediatamente parar, assim todos tomam conhecimento do erro e assim aprendem com
o mesmo e tem grandes chances de não repeti-lo. Obviamente não cabe aqui falar das
questões culturais com relação a cometer erros no Japão, mas a idéia básica é
interessante e pode ter aplicação em projetos de software.
2.3.2.6 Manutenção
A capacidade de um software receber modificações é conhecida como
manutenibilidade. O que segundo a ISO/IEC 9126-1 (2003, p.10) “podem incluir
correções, melhorias ou adaptações do software devido a mudanças no ambiente e nos
seus requisitos ou especificações funcionais.”
Pressman (2006) coloca vários aspectos que podem (e provavelmente irão)
dificultar a manutenção de sistemas:
Softwares antigos utilizavam técnicas e metodologias de engenharia de
software e codificação que hoje não se aplicam mais, isso quando
utilizavam alguma metodologia.
As tecnologias da época atendiam a demandas que hoje já foram
substituídas por novas demandas. O uso de tecnologias antigas pode vir a
dificultar a manutenção de um sistema.
A falta de boa documentação dificulta a compreensão do sistema,
consequentemente dificultando a manutenção do mesmo.
58
Esses problemas citados não deixam dúvidas sobre a importância da
engenharia de software. Ela está diretamente relacionada com a qualidade do produto
que será desenvolvido e se preocupa com todos os aspectos de um software.
A manutenibilidade de um sistema não fica restrita a um punhado de técnicas
específicas, mas sim ao uso da engenharia como um todo. Desde o levantamento
correto dos requisitos (e posterior documentação detalhada dos mesmos); a análise e
projeto, provendo toda a arquitetura do sistema através de diagramas e documentos
com descrições detalhadas; da correta escolha das ferramentas que serão utilizadas,
levando em conta todos os aspectos das mesmas, inclusive a documentação
disponível; e do uso das melhores práticas de codificação e testes.
2.3.3 Qualidade de Software
Pressman (2006, p.578) traz uma definição de qualidade do American Heritage
Dictionary que diz que a qualidade é “uma característica ou atributo de alguma coisa”.
Mas o autor acrescenta que devido a natureza intelectual do software existe uma
dificuldade maior em se medir qualidade.
Bem como Sommerville (2006) coloca, as noções de qualidade na manufatura
dizem que um produto deve atender as especificações. Entretanto, se tratando de
software pode haver alguns problemas, e o autor coloca alguns deles:
Para haver qualidade o software deve atender as especificações dos
clientes, entretanto existem as necessidades da organização que também
precisam ser atendidas para garantir, por exemplo, a manutenibilidade do
software.
Dificuldade de especificar certas características de qualidade de software
sem ser ambíguo.
59
Mesmo estando em conformidade com as especificações os usuários
podem não considerá-lo um produto de boa qualidade se este não atender
as suas expectativas.
Este ultimo item condiz muito com a afirmação de Pressman (2006) ao
mencionar uma fórmula para satisfação do usuário, pois o autor afirma que se o usuário
não estiver satisfeito nada mais importa.
Através deste cenário, a gestão da qualidade existe para trazer a qualidade ao
software. Pressman (2006, p.577) lista o que é abrangido pela gestão da qualidade
como sendo:
Processo de garantia de qualidade de software (Software Quality Assurance
– SQA).
Tarefas específicas de garantia de qualidade e controle de qualidade.
Práticas de engenharia de software efetiva.
Controle de todos os produtos de trabalho de software e das modificações
feitas neles.
Um procedimento para garantir a satisfação de normas de desenvolvimento
de software.
Mecanismos de medição e relatório.
Entretanto, Sommerville (2006, p.642) coloca que “existe muito mais em
gerenciamente de qualidade do que padrões e a burocracia associada para garantir que
aqueles foram seguidos”. O autor é favorável a criação de uma cultura da qualidade,
onde cada membro da equipe está comprometido com a qualidade do software e com a
criação de novas abordagens para melhorar a qualidade. Outra justificativa para se criar
60
tal cultura é pelo fato de haverem características intangíveis dentro de um software
(elegância, legibilidade, etc.), e dentro de um projeto as pessoas que mostram interesse
e comprometimento com esses aspectos do software devem ser incentivadas.
Ainda assim, Sommerville (2006) não descarta o gerenciamento de qualidade
formal, pois em grandes sistemas a documentação sobre a qualidade é importante para
que seja verificado tudo o que está sendo feito pelos grupos. Enquanto que times
menores não precisam se preocupar com tanta documentação, pois não existem tantos
problemas na comunicação e essa pode ser mais informal. Ainda assim, a ênfase na
cultura da qualidade é muito importante para garantir a mesma nos softwares.
Dentro das organizações a garantia da qualidade do software fica sob
responsabilidade de todos os envolvidos com a produção do software, fazendo parte de
um grupo de SQA (Software Quality Assurance). De um lado engenheiros de software
ficam responsáveis pela aplicação de métodos e técnicas adequadas, revisões técnicas
e planejamento e execução de testes. Enquanto isso, um grupo de SQA fica
responsável pelo plano de qualidade do projeto; ajuda na descrição e revisão do
processo de software do projeto; faz a revisão dos produtos, bem como sua
documentação e condução e documentação de desvios; e relata inconformidades no
projeto à gerência (PRESSMAN, 2006).
2.3.3.1 Qualidade do Produto e Processos
Em qualidade existe ainda a qualidade do produto e a qualidade do processo.
Na manufatura, a qualidade no processo afeta diretamente a qualidade do produto.
Entretanto, software não é manufaturado, mas sim projetado, pois é proveniente de um
processo criativo, não mecânico. E para Sommerville (2006), fica difícil determinar como
as características do processo afetam os atributos do software, e principalmente como
as mudanças nos processos irão afetar o produto.
61
Em contraposto à afirmação de Sommerville (2006), a ISO/IEC 9126-1 (2003)
assegura que a qualidade de processo contribui para melhorar a qualidade do produto
de software.
A Figura 11 demonstra a influência da qualidade no processo nos atributos de
qualidade interna (qualidade sob o ponto de vista interno, ex.: código fonte), que
influenciam os atributos de qualidade externa (qualidade sob o ponto de vista do
produto final, acabado), que por sua vez influenciam a qualidade em uso do software
(qualidade sob o ponto de vista do usuário).
Fonte: ISO/IEC 9126-1, 2003, p.4.
Figura 11: Qualidade no ciclo de vida.
Como o objetivo deste trabalho não está no estudo e uso intensivo de normas e
padrões de qualidade em software, aqui serão apenas exibidos os atributos de
qualidade de software (interna e externa), enquanto que uma descrição mais detalhada
dos mesmos pode ser encontrada em ISO/IEC 9126-1 (2003), além dos modelos de
qualidade de Boehm, McCall e Dromey.
Retornando a qualidade no processo de software, Sommerville (2006), apesar
de suas colocações, afirma que a qualidade dos processos mostrou significante
influência na qualidade de software, e que o primeiro pode sim levar a um software com
menos erros.
E assim como para o produto de software existem padrões, como para a
especificação de requisitos (ver seção 2.3.2.1.1), documentação de código (e.g.,
62
Javadoc (em 2.5.5)), e codificação (ver 2.3.4). Processos de software também possuem
padrões que definem os processos que devem ser seguidos durante o projeto de
software (SOMMERVILLE, 2006).
Dentre eles, os principais são:
ISO 9001 – padrão aplicado em organizações preocupadas com a
qualidade do processo e que projetam, desenvolvem e mantém produtos.
Apesar de não ter sido desenvolvida especificamente para o
desenvolvimento de software, ainda assim ela pode ser usada para a
definição de processos de software (SOMMERVILLE, 2006).
De acordo com Sommerville (2006), este padrão se preocupa com a
definição de processos que serão usados pela organização e com a
documentação relacionada aos processos que garante que a organização
está seguindo os processos definidos. O autor ainda afirma que o fato de
uma empresa ter ISO 9001 não impede que ela produza software de baixa
qualidade, pois o simples fato de ela estar definindo processos e os
seguindo garante que ela esteja de acordo com o padrão, mesmo que ela
tenha definido de forma incompleta um de seus processos.
CMMi – ou Capability Maturity Model Integration, é um framework para o
melhoramento de processos desenvolvida pelo SEI (Software Engineering
Institute) como uma tentativa de integrar os diversos modelos existentes
(incluindo o CMM). A maturidade dos processos da organização pode ser
classificado em níveis de 1 ao 5. Este modelo define ainda 24 áreas de
processos importantes para a capacitação e melhoramento de processos.
ISO/IEC 15504 – é um framework para a auto-avaliação da organização
com relação a uma gama de boas práticas para então melhorar seus
processos. Ele se divide em duas dimensões: dimensão de processo,
objetivos essenciais do processo que podem ser medidos; dimensão de
63
capacitação de processo, atributos comuns a qualquer processo e que
representam as características necessárias para gerenciar e melhorar um
processo (PAULK, 1999).
MPS.BR – é um modelo para Melhoria de Processo de Software Brasileiro.
O modelo está organizado em duas grandezas: de processo, baseado na
norma ISO/IEC 12207 e que dita o que deve ser feito para garantir a
qualidade nos processos; e de capacidade, que são os atributos de um
processo que definem o grau de capacitação do processo (FERREIRA,
2009).
Este modelo é ainda compatível com o modelo CMMI e está de acordo com
a norma ISO/IEC 15504. A classificação da maturidade de processos
começa com a letra G, menor grau de maturidade, e se estende até a letra
A, com maior grau de maturidade (FERREIRA, 2009).
2.3.4 Design Patterns
Design patterns são soluções para problemas, elas não descrevem como a
solução deve ser implementada, mas dão uma descrição de como o problema pode ser
resolvido, ou melhor, fornecem a base para a criação de uma solução para um
problema. Com essa descrição abstrata da solução é possível então utiliza - lá em
diversos projetos com problemas semelhantes, ficando a implementação a cargo da
equipe do projeto (SOMMERVILLE, 2006).
Nas próximas seções serão abordados alguns design patterns importantes para
os quais se encontrou aplicabilidade no presente trabalho.
2.3.4.1 Facade Pattern
Segundo Gamma et al. (1994), o façade define o uso de uma interface unificada
para um conjunto de interfaces de um sub-sistema. A principal motivação de se usar um
64
façade é a redução da complexidade do sistema, dividindo-o em sub-sistemas e através
do façade diminuindo a comunicação e a dependência entre as partes do sistema.
A Figura 12 exemplifica a idéia deste design pattern, que é a de criar uma
interface que simplifique o acesso a um sub-sistema. Utilizando o façade, clientes que
precisam ter acesso ao sub-sistema não precisam lidar com as classes de baixo nível
do sub-sistema, tão pouco precisam saber a ordem certa de passos para obter um
serviço daquele sub-sistema, o cliente simplesmente precisa acessar o façade e este se
preocupa com os detalhes de mais baixo nível (GAMMA, et al., 1994).
Fonte: GAMMA, et al., 1994, p.208.
Figura 12: Exemplo do pattern façade.
É importante relater ainda que a existência de um façade abstraindo as
complicações de um sub-sistema não impede que clientes acessem as classes deste
sub-sistema quando houver necessidade. Vale ressaltar ainda que a menor
dependência entre as partes de um sistema o torna mais portável, quando se fizer
presente a necessidade (GAMMA, et al., 1994).
2.3.4.2 Presentation Model
O Presentation Model é um design pattern onde a idéia central é a de remover
da view (camada visual do sistema – ou GUI (Graphic User Interface)) seu estado e seu
comportamento e colocá-los em um model, o Presentation Model (FOWLER, 2004).
65
Essa classe (Presentation Model) contém todo o estado e comportamento da
view, entretanto ela não possui controle sobre a renderização dos componentes visuais
da view. A Figura 13 apresenta a estrutura básica de classes seguindo o pattern
apresentado. Neste exemplo a classe Album Window é a view, Album é o model – i.e.
– quem armazena as informações, e o Album Presentation Model, o responsável por
fazer a conexão entre a view e o model. Ou seja, quando dados forem atualizados na
view, a classe recebe os dados e os atualiza no model, e o contrário também é
verdadeiro. Isso é conhecido como data binding (FOWLER, 2004).
Fonte: FOWLER, 2004.
Figura 13: Exemplo do pattern Presentation Model.
Fowler (2004) coloca ainda duas possibilidade de se implementar o pattern, em
uma delas a view faz referência ao Presentation Model e na outra o Presentation Model
faz a referência a view.
2.3.4.3 MVC (Model-View-Controller)
Para Sommerville (2006), o MVC é um dos mais bem conhecidos frameworks
para desenvolvimento de aplicações com interface gráfica. O fato de uma framework
estar aqui se dá pelo fato de que ela é composta por vários design patterns. Além disso,
Bergin (2007) faz referência ao MVC como sendo um pattern ao invés de framework, o
66
que não deixa de estar certo já que o MVC é uma idéia abstrata e a implementação do
mesmo fica a cargo dos desenvolvedores.
Basicamente, o MVC consiste em dividir as entradas de dados do usuário, a
modelagem do mundo real e as respostas dadas aos usuários em três camadas
distintas. No model persiste a modelagem do mundo real, as regras de negócio; na view
está a apresentação dos dados do model para o usuário; e no controller está a
responsabilidade de repassar os dados inseridos na view para o model (BURBECK,
1997).
2.3.5 Refactoring (ou refatoração, ou ainda refabricação)
Nas palavras de Fowler et al. (1999):
Refatoração é o processo de modificar um software sem que isso altere o comportamento externo do código, mas melhore sua estrutura interna. É uma maneira disciplinada de limpar o código minimizando as chances de se introduzir erros. Em essência, quando você refatora você está melhorando a estrutura do código depois dele ter sido escrito.
Refatorar é importante porque pode tornar o código mais compreensível e fácil
de modificar, algo importante quando se fala em sistemas legados. Refatorar também
ajuda a melhorar códigos que foram modificados e foram perdendo qualidade na
estrutura e estão se tornando difíceis de compreender. Com a refatoração a estrutura
do código se mantém com qualidade, e isso ajuda no descobrimento de erros e
consequentemente torna o desenvolvimento mais rápido (FOWLER, 1999).
Quando no desenvolvimento, a principal tarefa do programador está em
adicionar funcionalidades e criar os testes para garantir que estas funcionalidades estão
entregando aquilo que elas propuseram. Do outro lado está a refatoração, ela não
adiciona funcionalidades tampouco cria novos testes para elas. Entretanto, ela melhora
o código e o torna mais fácil de compreender e consequentemente de encontrar erros e
de modificar. Entretanto, cabe ao programador avaliar quando vale a pena utilizar a
refatoração e quando não. Também é preciso estar ciente de que algumas vezes
67
modificações nas interfaces precisaram ser feitas, o que leva a modificação de várias
partes afetadas (FOWLER, 1999).
O fato é que quando bem utilizada a refatoração pode sim melhorar a qualidade
do código produzido e como consequência pode trazer agilidade no desenvolvimento
de software, além de diminuir a quantidade de erros.
2.4 BANCO DE DADOS
Quando se fala em tecnologia da informação não há como não fazer relação
com banco de dados. É através deles que organizações armazenam os dados de todas
as suas operações. Logo, bancos de dados são ferramentas fundamentais em sistemas
de informação, pois são eles que armazenam aquilo que mais tem valor para uma
organização.
Enquanto o banco de dados é o responsável pelo armazenamento de dados,
existe o sistema gerenciador de banco de dados (SGBD) – este sendo o responsável
pela manipulação dos acessos ao banco de dados. Os bancos de dados mais utilizados
atualmente são os relacionais, neles os dados estão dispostos em tabelas bi-
dimensionais onde as linhas são os registros e as colunas são os atributos. Além dos
bancos de dados relacionais existem outros, como os orientados a objetos e orientados
a documentos (DATE, 2004).
Bancos de dados relacionais utilizam principalmente SQL (Structured Query
Language) para permitir o acesso aos dados em suas bases. Quanto à modelagem de
banco de dados – algo vital para a construção de um sistema sólido de informações –
ela está dividida em modelagem conceitual e lógica. A conceitual é independente de
SGBD enquanto que a lógica é dependente, e nesta última as especificações mais
peculiares aos SGBDs são informadas. Na modelagem lógica, o modelo que mais se
sobressaiu foi o modelo de entidades-relacionamentos (ou ER) criado por Peter Chen
em 1976 (DATE, 2004).
68
Neste trabalho, o SGBD utilizado foi o PostgreSQL (ver 2.5.6), mas com o uso
de ferramentas de modelagem que permitam a conversão de um modelo conceitual
para um modelo lógico e do framework Hibernate (ver 2.5.3) as chances de o sistema
ser portável para outros SGBDs é muito maior.
Entretanto, é importante ressaltar que mesmo com o uso de um framework de
ORM, algumas vezes queries (consulta à informações) precisam ser personalizadas,
tanto para que um conjunto distinto de informações seja obtido como para tirar maior
vantagem de funções específicas do SGBD. Isso acaba com a portabilidade do sistema,
que precisa ter suas queries reescritas para garantir a compatibilidade com cada SGBD.
Aí vale uma avaliação de qual abordagem é a melhor: tirar vantagem de funções
específicas para ganhar algum tipo de vantagem e perder a portabilidade; ou manter a
portabilidade e largar mão de recursos extras que poderiam adicionar funcionalidades
ao sistema.
2.5 FERRAMENTAS UTILIZADAS
2.5.1 Java
A linguagem Java foi criada em 1991 dentro da Sun Microsystems por James
Gosling e era baseada na linguagem C++. Devido à falta de interesse do mercado Java
só foi publicamente apresentado em 1995, quando se viu o possível interesse do
público em vista da explosão da internet (DEITEL, P. J.; DEITEL, H. M., 2007).
Java é uma linguagem orientada a objetos, sendo assim, ela é formada por
classes que por sua vez são compostas por métodos e atributos. Para Deitel, P. e
Deitel, H. (2007) é possível aprender Java de duas maneiras: escrevendo as próprias
classes e utilizando bibliotecas de classes (chamadas ainda de APIs).
Java é atualmente considerada uma linguagem madura. Além disso, ela é uma
linguagem de alto nível, ou seja, o programador não precisa se preocupar com detalhes
muito específicos como alocação de memória. Em Java muitos detalhes que poderia
69
causar problemas em outras linguagens aqui são checados para evitar erros de
execução (GOSLING, et al., 2005).
Uma das principais características de Java, muito alardeada por sinal, é a
portabilidade da linguagem. Isso ocorre porque diferentemente das outras linguagens
compiladas, Java não é compilado diretamente para código nativo de máquina, mas sim
para o que se chama de bytecodes. Esses bytecodes ficam armazenados em arquivos
.class e quando um programa Java é executado eles são carregados do disco rígido
para a memória do computador, é feita então uma verificação dos bytecodes para
garantir que eles não estejam violando as restrições de segurança de Java, e por fim
uma máquina virtual (JVM ou Java Virtual Machine) lê esses bytecodes e compila-os
em tempo de execução (JIT ou just-in-time) para linguagem de máquina (DEITEL, P. J.;
DEITEL, H. M., 2007).
Levando em consideração a forma como programas são executados em Java é
possível compreender o fato de muitos programas desenvolvidos na linguagem
tomarem muito tempo para iniciar (compilação just-in-time), bem como a quantidade de
memória mínima utilizada (JVM).
Projetos como o GCJ (GNU Compiler for Java) foram criados para tentar
melhorar a performance de Java. O GCJ serve para compilar diretamente em código
nativo de máquina programas escritos em Java. Infelizmente o uso do compilador
muitas vezes pode não ser tão vantajoso. Isso porque a cada nova atualização do Java
o compilador também teria de se adaptar, o que muitas vezes leva algum tempo (se
ocorrer). Além disso, o suporte a Swing é parcial, ou seja, a aplicação estaria passível
de ter problemas de compatibilidade.
Em 2007 a Sun Microsystems liberou todo o código fonte da linguagem sob
licença GPL. Atualmente a linguagem se encontra na versão 6 para as plataformas
Solaris, Linux, Windows, MAC OS X. Java é distribuído de duas formas: pela JDK (Java
Development Kit) que é voltada para desenvolvedores; e JRE (Java Runtime
Environment), que é a SDK sem o compilador, cabeçalhos e outros utilitários. Além
70
disso, Java está disponível em três versões: Java EE (Enterprise Edition), para
servidores; Java ME (Micro Edition), para dispositivos móveis e sistemas embarcados; e
Java SE (Standard Edition), que é a versão padrão para desenvolvimento de aplicativos
(JAVA DOC., 2010).
Na Figura 14 é possível visualizar as tecnologias e bibliotecas que atualmente
compõe a plataforma Java.
Fonte: <http://sheikyerbouti.developpez.com/tmp/j2se5.gif>.
Figura 14: Plataforma Java.
2.5.2 NetBeans
NetBeans foi a primeira IDE desenvolvida para Java, ela foi criada em 1996 e o
principal objetivo desta ferramenta era trazer a facilidade da programação em Delphi
para Java. Em 1999 a Sun Microsystems adquiriu a ferramenta NetBeans bem como
Forté e o nome da nova ferramenta passou a ser Forté for Java (NETBEANS.ORG,
2010).
71
No ano 2000 o NetBeans se tornou um projeto open-source, sendo ainda
patrocinado pela Sun Microsystems. Com a compra da Sun pela Oracle esta última
passou a patrocinar o projeto, juntamente com a comunidade envolvida no seu
desenvolvimento (NETBEANS.ORG, 2010).
Atualmente a ferramenta se encontra na versão 6.9 que roda nas plataformas
Windows, Linux, Solaris e Mac OS X e dá suporte a várias linguagens além de Java,
como: PHP, C/C++, Ruby, Javascript. O NetBeans também dá suporte a modelagem de
diagramas UML em forma de um módulo, além disso é possível instalar plugins que
fornecem novas funcionalidades a IDE (NETBEANS.ORG, 2010).
2.5.3 Hibernate Framework
Hibernate é uma ferramenta de mapeamento objeto-relacional (ORM) que
busca facilitar o acesso a dados em bancos de dados relacionais através da linguagem
Java ou .NET. Ferramentas de ORM dispensam a codificação de códigos SQL,
constroem consultas SQL otimizadas e funcionam independentemente do SGBD
utilizado (BAUER; KING, 2005).
De acordo com Bauer e King (2005) o Hibernate começou a ser desenvolvido
em 2001 por Gavin King como um projeto open source e sem fins comerciais. No fim de
2003 o projeto se juntou ao jboss.org devido à maior demanda pela ferramenta. A
framework passou então a ter um âmbito comercial, sendo que a JBoss Inc. passou a
dar suporte e treinamento a ferramenta.
Bauer e King (2005) ainda citam as principais técnicas utilizadas para a
persistência do banco de dados e afirmam que por enquanto a melhor delas é a ORM.
Dentre suas qualidades, as principais são: maior produtividade, isso porque o
programador não precisa gastar tempo montando SQLs; facilita a manutenção, levando
em conta que com um ORM menos código será escrito e há uma grande chance de se
diminuir as chances de se cometer erros; melhor performance, apesar de muitos
argumentarem que códigos escritos a mão pode ser melhor otimizados um ORM
72
também realiza otimizações em todas as interações com o banco de dados, além de
lidar com as peculiaridades de cada banco de dados; e a independência de banco de
dados, ou seja, com um ORM sua aplicação se torna portável entre os SGBDs
suportados pela ferramenta de persistência.
2.5.4 JUnit Framework
JUnit é uma framework para realização de unidades de teste em Java, foi criada
em 1997 por Erich Gamma e Kent Beck. A framework é open source e é distribuída
através da licença IBM’s Common Public License Version 1.0 e atualmente se encontra
na versão 4.8 (TAHCHIEV, et al., 2009).
Unidades de teste servem para avaliar o comportamento de uma unidade de
trabalho. Essa unidade comumente é um método de uma classe, sendo que o teste fica
encarregado de fornecer os dados exigidos pelo método e receber o resultado deste
método e verificar se a resposta recebida está correta. O autor também cita o contrato
de API, aonde o método se compromete a fornecer os dados corretos quando forem
requisitados seus serviços, e uma quebra de contrato poderia ser expressa por uma
exception lançada pelo método (TAHCHIEV, et al., 2009).
2.5.5 Javadoc
Ferramenta criada pela Sun Microsystems para a geração de documentação de
API em HTML através de comentários inseridos no próprio código fonte. A ferramenta
está disponível juntamente com o Java SDK (Software Development Kit) e atualmente
se encontra na versão 1.5 (JAVA DOC., 2010).
2.5.5 Toad Data Modeler
O Toad é uma ferramenta para modelagem de banco de dados paga e para
Windows. Ela permite a criação de projetos tanto lógicos como físicos. Neste último, dá
73
suporte aos seguintes SGBDs: DB2, MS Access, MS SQL Server, MySQL, Oracle,
PostgreSQL e Sybase ASE (QUEST SOFT., 2010).
A ferramenta ainda permite a geração de documentação a partir do modelo
criado, exportando para HTML, RTF ou PDF. Além de permitir a exportação do modelo
visual para imagem. Entre as maiores vantagens da ferramenta está o suporte aos
últimos recursos disponíveis nas mais recentes versões dos SGBDs (QUEST SOFT.,
2010).
A geração dos scripts para criação do banco é totalmente configurável. Além
disso, é possível fazer a engenharia reversa diretamente da ferramenta, verificar por
erros no modelo de dados criados, sincronizar os modelos com bancos de dados físicos
e fazer o controle de versões de modelos (QUEST SOFT., 2010).
2.5.6 PostgreSQL
PostgreSQL é um banco de dados relacional open source, foi criado como um
projeto acadêmico da UC Berkeley pelo professor Michael Stonebraker, em 1986, como
continuação do projeto de banco de dados chamado de Ingres. O início do Postgres se
deu com o intuito de provar academicamente a teoria dos bancos de dados objeto-
relacional. Com o tempo o banco de dados passou a integrar a linguagem SQL para
interface de comunicação (BLUM, 2007).
O PostgreSQL é considerado atualmente o mais poderoso SGBD de código
aberto disponível. Está na versão 8.4 e está disponível nas plataformas Windows, UNIX
e Linux. Tem suporte total a foreign keys, joins, views, triggers e stored procedures (em
diversas linguagens). Além de suportar o armazenamento de imagem, áudio e vídeo
(POSTGRESQL.ORG, 2010).
74
2.5.7 Enterprise Architect
É uma ferramenta proprietária de modelagem para UML 2 e SysML com
suporte oficial para Windows, e atualmente está na versão 8. Com essa ferramenta é
possível desenvolver toda a análise de um sistema, desde os requisitos até os
diagramas da UML e os modelos de dados. A ferramenta oferece ainda integração com
várias IDEs, dentre elas Eclipse e Visual Studio (SPARX SYS., 2010).
Com a ferramenta é possível ainda importar e exportar códigos para as
principais linguagens de programação do mercado. Além da geração de documentação
através de templates customizáveis (SPARX SYS., 2010).
75
CAPÍTULO 3: RESULTADOS
Neste capítulo encontram-se os resultados obtidos neste projeto desde a fase
de levantamento dos requisitos, passando pela análise e projeto do sistema, testes, até
chegar à apresentação do sistema como produto de software.
3.1 SITUAÇÃO ATUAL DA EMPRESA
Este trabalho foi desenvolvido com base em um problema encontrado na
Metalúrgica Fratelli, localizada em Santa Rosa – RS. Fundada em julho de 1986,
atualmente trabalha na produção de peças para colheitadeiras, tratores e outros
equipamentos não automotivos.
O problema em questão diz respeito ao sequenciamento da produção dentro da
indústria. Atualmente ele é feito através de planilhas eletrônicas que controlam o que
deve ser feito, quando, onde e que quantidade. O problema é que sequenciar a
produção através das planilhas eletrônicas está começando a se tornar uma tarefa
árdua e a tendência é de ficar cada vez mais difícil levando em conta que novos
conjuntos passarão a ser sequenciados através destas planilhas.
Outro problema envolvendo as planilhas eletrônicas é que elas, com o tempo,
se tornam muito pesadas devido à grande quantidade de dados nelas armazenados, o
que as torna inutilizáveis dentro de meses.
76
3.2 ESPECIFICAÇÃO DOS REQUISITOS DO SISTEMA
O levantamento dos requisitos ocorreu através de entrevistas com os
interessados e envolvidos na atual solução de sequenciamento utilizada dentro da
metalúrgica. Ao menos três reuniões foram feitas para que a definição dos requisitos
estivesse clara o suficiente para que o software pudesse passar para a modelagem.
A importância de discutir com os usuários sobre o problema a ser solucionado é
de fundamental importância para que se compreenda o que de fato o usuário deseja, e
o que realmente ele precisa que o software faça para ele. Neste projeto foi possível
notar com clareza a evolução das especificações do software que começaram apenas
com um esboço vago daquilo que o usuário realmente desejava.
E a cada nova visita aos usuários, os requisitos foram sendo melhor
trabalhados e começaram a se aproximar mais da real solução de seus problemas com
relação ao sequenciamento da produção dentro da metalúrgica. Isso mostra a
importância da comunicação com os usuários e do constante feedback a respeito das
evoluções na descrição dos requisitos.
Outro aspecto importante de ser ressaltado é a forma como os requisitos serão
descritos em um primeiro momento. Enquanto não existir uma boa compreensão a
respeito do problema dos usuários, a descrição dos requisitos deve permanecer breve e
clara. A especificação detalhada dos requisitos só deve ser feita quando o problema foi
bem compreendido e o cliente está de acordo com as especificações.
O documento de especificação dos requisitos encontra-se no Apêndice A deste
relatório, especificamente na seção 3 do documento.
3.2.1 Domínio do Problema
Como foi exposto na seção 3.1, o problema principal da empresa com relação
ao sequenciamento da produção está relacionado com a ferramenta atualmente
77
utilizada para desempenhar esta tarefa. As planilhas eletrônicas utilizadas atualmente,
apesar de terem conseguido desempenhar seus papéis, não são uma solução
escalável. Ou seja, essa solução não é capaz de crescer juntamente com a quantidade
de conjuntos envolvidos no sequenciamento, pois quanto mais conjuntos são
adicionados, mais demorado fica para abrir as planilhas e mais tempo se leva para
sequenciar as ordens de produção.
Simplificando as especificações do sistema do Apêndice A, a metalúrgica
possui células de trabalho, também chamadas de operações, são por estes locais que a
matéria prima passa para se tornar um componente. Componentes formam conjuntos, e
estes também passam por células de trabalho para que venham a formar um conjunto
acabado. Tanto componentes como conjuntos precisam de um determinado período de
tempo em cada uma das células de trabalho para serem transformados.
Esse tempo pode também ser chamado de lead time. Quando uma ordem de
produção é recebida ela possui uma data de entrega, a identificação do conjunto que
deve ser produzido e a respectiva quantidade dele. Agora, para saber quando os
componentes do conjunto devem começar a ser produzidos é preciso saber o lead time
para a produção deste conjunto.
Para calcular o lead time do conjunto é preciso somar o maior lead time dentre
os componentes que formam o conjunto com a soma dos lead times para as operações
do conjunto. Com essas informações é possível afirmar o dia em que o conjunto deverá
começar a ser produzido, bem como informar o dia em que cada um dos componentes
deverá passar pelas células de trabalho, bem como o próprio conjunto.
Para uma melhor compreensão de como funciona o sequenciamento da
produção, verificar o Apêndice B, seção 8.1.
Os dados do sequenciamento são expostos em planilhas eletrônicas com as
colunas indicando os dias e as linhas indicando os componentes a serem produzidos.
Cada célula de trabalho tem seu sequenciamento individual, além do sequenciamento
78
mestre que exibe o dia em que a produção dos componentes deverá começar. Estas
planilhas têm dois propósitos, além do controle da produção, são eles: informar os
clientes sobre o andamento de seus pedidos e servir de guia para os trabalhadores do
chão de fábrica.
3.2.2 Resultados Esperados
Nas seções anteriores foi possível tomar um bom conhecimento dos problemas
enfrentados pela metalúrgica no sequenciamento de sua produção e a importância que
o sequenciamento tem para eles. De fato, a aplicação do sequenciamento da produção
através das planilhas eletrônicas trouxe muitos benefícios a metalúrgica, sendo o
principal deles a diminuição do tempo necessário para se atender um pedido.
O objetivo principal deste trabalho foi o de automatizar boa parte das atividades
relacionadas ao sequenciamento de produção, reduzindo ao máximo o esforço
necessário para a obtenção dos mesmos resultados, as planilhas eletrônicas com o
sequenciamento da produção.
Isto é exatamente o que o software faz, ele diminui o esforço necessário para o
sequenciamento da produção da metalúrgica através da automatização de
determinadas tarefas, como o sequenciamento da produção, principal tarefa do
sistema. Além disso, com o sistema é possível controlar os clientes, componentes,
conjuntos e ordens de produção armazenados no sistema.
Uma detalhada descrição de todas as funcionalidades do sistema pode ser
encontrada no Apêndice E, o manual do usuário.
3.2.3 Impacto do Sistema na Empresa
Até o momento da finalização do relatório o software não havia sido
apresentado aos interessados da metalúrgica. Portanto, não é possível precisar o
79
impacto do sistema na empresa, visto que não há a aprovação do software com relação
às expectativas dos usuários.
Entretanto, é possível especular que se e somente se o software estiver de
acordo com as expectativas dos usuários, com certeza ele virá a melhorar a tarefa de
sequenciamento de produção, facilitando a tarefa e permitindo aos usuários o uso de
seu tempo em tarefas que venham a agregar mais valor a metalúrgica, deixando a
criação das planilhas eletrônicas a cargo do software.
3.3 ANÁLISE E PROJETO DO SISTEMA
A análise e projeto do sistema foram desenvolvidos com base no documento de
especificação dos requisitos do sistema (Apêndice A). Estas duas fases deste projeto
deram origem a um segundo artefato, o Documento de Arquitetura (Apêndice B). Este
documento tem por objetivo a descrição da estrutura que serviu de base para o
desenvolvimento do sistema, bem como a ilustração do seu comportamento.
3.3.1 Casos de Uso
Como parte da análise do software, foram construídos os diagramas de casos
de uso, estes ilustram as funcionalidades do sistema e os atores que delas participam.
Os diagramas de caso de uso, bem como detalhada descrição de cada um deles, estão
no Apêndice A, na seção 2.2.
3.3.2 Diagramas de Atividade
Neste projeto apenas um diagrama de atividades foi desenhado, este diagrama
descreve a mais importante das tarefas que o software desempenha, o sequenciamento
da produção. Este diagrama pode ser encontrado no Apêndice B, na seção 8.1.
80
3.3.3 Diagramas de Classes
Os diagramas de classe criados para este sistema também se encontram no
Documento de Arquitetura (Apêndice B), na seção 7. Estes diagramas serviram de base
para a criação da aplicação durante a fase de desenvolvimento do sistema.
3.3.4 Modelo Entidade Relacionamento
O modelo de entidades-relacionamentos segue as especificações definidas na
Especificação dos Requisitos do Sistema, bem como os diagramas de classe do
Documento de Arquitetura. O MER pode ser visualizado no Apêndice F.
3.4 DESCRIÇÃO DO DESENVOLVIMENTO
Com a fase de análise e projeto do sistema em estágio final, o desenvolvimento
pode tomar início, começando pela geração das classes do sistema a partir dos
diagramas criados no projeto do sistema. A primeira etapa do desenvolvimento foi a
montagem da estrutura básica de pacotes e classes do sistema, com base nos
diagramas fornecidos pelo Documento de Arquitetura (Apêndice B).
Com a estrutura base da aplicação pronta, iniciou-se o mapeamento do banco
de dados criado a partir do modelo ER através da ferramenta Hibernate. Todo o
mapeamento foi feito utilizando arquivos XML, também utilizou-se de XML para a
criação das regras de validação com a ferramenta Hibernate Validator. Com o
mapeamento completo, passou-se então a implementação dos métodos das classes do
sistema.
A abordagem adotada para o desenvolvimento foi a de completar um módulo
por vez, implementando todas as camadas do módulo de uma vez e então partindo
para o próximo módulo do sistema. O desenvolvimento também fez o uso intensivo de
testes unitários, sendo estes escritos para todas as classes com métodos relevantes o
suficiente para necessitarem de testes. Para cada método criado, um teste unitário
81
também foi criado, e este método só poderia ser utilizado por outras classes depois de
ter passado pelos testes. Ao final de cada dia todos os testes eram executados para
garantir que as modificações efetuadas no sistema não haviam afetados outras partes
do sistema, além de verificar se a integração do sistema estava sendo bem sucedida.
Além da realização de testes unitários, testes de integração entre classes foram
conduzidos durante o desenvolvimento do sistema. Tanto os testes unitários como os
de integração fizeram uso da ferramenta JUnit, ferramenta esta que facilitou a execução
dos testes, bem como a criação de relatórios. O relatório dos testes unitários pode ser
encontrado na seção 3.1 do Apêndice D.
Outra prática adotada durante o desenvolvimento do sistema foi o uso da
ferramenta Javadoc para documentação das classes e respectivos métodos. Esta
ferramenta permite a criação de detalhada descrição de classes e métodos, informando
dentre várias informações os parâmetros de entrada, variável de retorno, versão da
classe, data de criação, autor da classe, etc.
Este tipo de documentação é conhecido como documentação de API, pois gera
rica documentação a respeito das funcionalidades fornecidas pelas classes, permitindo
que outras pessoas compreendam o propósito de cada classe e as funções que ela
provê.
Ao final do desenvolvimento do sistema, outra prática foi aplicada, desta vez a
prática do refactoring, ela foi aplicada em partes críticas do código que demandavam
maior desempenho e principalmente clareza de código para melhorar a compreensão
de quem vir a lê-lo.
3.5 TESTES DO SISTEMA
Além dos testes unitários, o software foi submetido a testes funcionais. Em um
primeiro momento foram criados os casos de teste para as funcionalidades do sistema,
82
estes descritos no Apêndice C. Com base nos casos de teste foram criados os testes
automatizados para o sistema utilizando a ferramenta IBM Rational Functional Tester.
O relatório dos testes funcionais pode ser encontrado na seção 3.2 do Apêndice
D.
3.6 MANUTENÇÃO DO SISTEMA
Como foi colocado no Capítulo 2, a manutenibilidade de um software é dada
pela capacidade deste software receber modificações, podendo ser uma correção,
melhoria ou adaptação. E para que isso seja possível o código fonte do software
precisa estar bem escrito e documentado.
Este projeto fez uso de algumas práticas durante o desenvolvimento do
software para garantir um código melhor escrito e bem documentado. Estas práticas
foram descritas na seção 3.5, sendo elas: documentação de API e refactoring. Estas
práticas possibilitaram a criação de códigos mais simples e com detalhada descrição de
cada parte do código.
Aliado a estas práticas está o Documento de Arquitetura (Apêndice B), este
responsável pela descrição de toda arquitetura que serviu de base para o
desenvolvimento do software. Isso significa que qualquer pessoa que deseje
compreender a estrutura básica do software pode encontrar informações suficientes
neste documento.
Outra forma de compreender melhor a estrutura do sistema seria através de
engenharia reversa. Várias ferramentas de modelagem UML fornecem essa
funcionalidade de importar um sistema para dentro do modelador, e este então
transforma o código importando em diagramas de classes, com suas relações, métodos
e atributos.
83
Outro ponto importante da manutenção de um software é a atualização da
documentação, neste caso, o Documento de Arquitetura. Este deve ser atualizado a
cada modificação efetuada na estrutura do sistema. Além deste documento, todos os
outros documentos devem ser atualizados quando novas funcionalidades forem
introduzidas.
CONCLUSÃO
Uma das premissas mais básicas ao se conceber um software é o de que ele
irá suprir uma necessidade de um determinado público. Mas apenas construir um
software que atenda a essas necessidades não é suficiente para criar uma demanda
pelo software. Então o que seria capaz de criar tal demanda?
Antes de responder a esta questão, é importante lembrar que um software é
apenas um meio para atingir um objetivo, ele automatiza processos, os torna mais
eficientes e mais eficazes. Poderia então a aquisição de um software trazer benefícios a
uma organização?
A verdade é que isso depende de cada organização, e de como estão
estruturados os seus processos. Como poderá uma empresa sentir uma necessidade
se ela nem ao menos possui profissionais capazes de identificar tais deficiências?
Mesmo o software que siga rigorosamente as especificações de requisitos poderá ser
insatisfatório para a organização, não necessariamente porque o software foi mal
planejado, mas porque a organização pode estar tendo dificuldades de se adaptar aos
novos processos, principalmente quando não se possuía nenhum até o momento.
Um novo sistema vai muito além de um programa de computador, sua
implantação requer disciplina e cooperação dentro da organização para que ele venha
a trazer benefícios a esta.
Durante a execução deste projeto foi possível perceber que a inserção de uma
maneira nova de se fazer as coisas em uma indústria pode levar algum tempo. E foi
isso que levantou a questão da relevância de se adquirir um software. É mais do que
evidente a importância de pessoas capazes de mobilizar uma organização para
modificar um processo.
Portanto, o sucesso de um software está intrinsecamente relacionado a
capacidade de a organização adotar novos processos.
Na empresa onde este projeto foi realizado os processos para o
sequenciamento da produção já estavam sendo aplicados. E foi através de
metodologias e boas práticas de Engenharia de Software que as especificações do
software foram descritas visando o máximo de acurácia com relação a estes processos.
Tendo o software seguido rigorosamente estas especificações e tendo elas sido
testadas através de testes de funcionalidades é possível afirmar que o software atende
as necessidades dos usuários, provendo uma ferramenta capaz de fornecer uma
solução que torna o sequenciamento da produção mais rápido do que a solução
atualmente empregada ao mesmo tempo em que provê resultados de igual acurácia
com relação aos obtidos através dos métodos atualmente utilizados na empresa.
Além do alinhamento do software desenvolvido com relação as especificações
obtidas, a satisfação do usuário também está relacionada com a confiabilidade do
software. Para tanto, durante o desenvolvimento do software, testes unitários foram
criados para as classes mais relevantes do sistema. Entretanto, não foi possível
comprovar que testes unitários diminuem a ocorrência de erros, pois para comprovar tal
afirmação seria preciso ter um histórico de erros em outros projetos onde testes
unitários não foram aplicados.
Ainda assim, todas as práticas e métodos aplicados neste projeto vieram de
alguma forma a beneficiar o produto final, assegurando maior confiabilidade ao
86
software, o que foi comprovado através dos resultados dos testes unitários e de
funcionalidades.
Um dos grandes desafios na modelagem do software foi a de abstrair todas as
regras de negócios dos requisitos captados e construir uma especificação mais
generalista, mas que conseguisse atender as peculiaridades da metalúrgica sem,
entretanto, engessar a aplicação às regras específicas do negócio.
Portanto, a utilização de metodologias de Engenharia de Software possibilitam
a melhor compreensão do problema a ser resolvido, bem como fornecem meios de
garantir a qualidade do software e de manter uma documentação capaz de auxiliar na
compreensão do funcionamento do software.
Também é possível concluir que a implantação de um software dentro de uma
organização vai muito além da aquisição do software. A organização precisa de
maturidade e de pessoas que sejam capazes de provocar a mudança dentro da
organização, para que um software possa de fato trazer benefícios a ela.
REFERÊNCIAS
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 9126-1.
Engenharia de software – Qualidade de produto – Parte 1: Modelo de qualidade.
2003.
BAUER, Christian; KING, Gavin. Hibernate in Action. Greenwich: Manning, 2005.
BECK, Kent. Extreme Programming Explained: Embrace Change. Addison-Wesley,
1999.
BELL, Alex E. Death by UML Fever. Queue, Volume 2, Issue 1, March 2004, ACM.
BERGIN, Joseph. Building Graphical User Interfaces with the MVC Pattern. Pace
University, 02 Set. 2007. Disponível em:
<http://pclc.pace.edu/~bergin/mvc/mvcgui.html>.
BLUM, Richard. PostgreSQL 8 for Windows. McGraw-Hill, 2007.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. The Unified Modeling
Language User Guide – 2ª Edição. Addison-Wesley, 2005.
BURBECK, Steve. Applications Programming in Smalltalk-80: How to use Model-
View-Controller (MVC). The University of Illinois at Urbana-Champaign Smalltalk
88
Archive, 04 Mar. 1997. Disponível em: <http://st-www.cs.illinois.edu/users/smarch/st-
docs/mvc.html>.
DATE, Chris J. An Introduction to Database Systems – 8ª Edição. Pearson, 2004.
DAVIS, Mark M.; AQUILANO, Nicholas J.; CHASE, Richard B. Fundamentos da
Administração da Produção – 3ª Edição. Porto Alegre: Artmed, 2001.
DEITEL, P. J.; DEITEL, H. M. Java: How To Program – 7ª Edição. New Jersey:
Pearson, 2007.
FERREIRA, Wilker Felix. MPS.BR: Um Estudo do Modelo MPS.BR como Benefício
para as Pequenas e Médias Empresas. Universidade Estadual de Goiás, 2009.
FOWLER, Martin. Presentation Model. Divulgado em: 19 Jul 2004. Disponível em:
<http://martinfowler.com/eaaDev/PresentationModel.html>.
FOWLER, Martin; BECK, Kent; BRANT, John; OPDYKE, William; ROBERTS, Don.
Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999.
GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John M. Design
Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994.
GOSLING, James; JOY, Bill; STEELE, Guy; BRACHA, Gilad. The Java Language
Specification – 3ª Edição. Addison-Wesley, 2005.
Java Documentation. Disponível em:
<http://www.oracle.com/technetwork/java/javase/documentation/index-jsp-135444.html>.
Acesso em: 04 ago. 2010.
MARCONI, Marina de Andrade; LAKATOS, Eva Maria. Técnicas de pesquisa – 6ª
Edição. São Paulo: Atlas, 2006.
89
NetBeans Official Website. Disponível em: <http://netbeans.org/>. Acesso em: 01 ago.
2010.
OLIVEIRA, S. L. Tratado de Metodologia Científica: projetos de pesquisas, TGI, TCC,
monografias, dissertações e teses – 2ª Edição. São Paulo: Pioneira, 2002.
PAULK, Mark C. Analyzing the Conceptual Relationship Between ISO/IEC 15504
(Software Process Assessment) and the Capability Maturity Model for Software.
Proceedings of the Ninth International Conference on Software Quality, Cambridge, MA,
4-6 Oct 1999, pp. 293-303.
PostgreSQL.org. PostgreSQL Official Website. Disponível em:
<http://www.postgresql.org/>. Acesso em: 02 ago. 2010.
PRESSMAN, Roger. Engenharia de Software – 6ª Edição. McGraw-Hill, 2006.
Quest Software. Toad Data Modeler. Disponível em: <http://www.quest.com/toad-data-
modeler/>. Acesso em: 04 ago. 2010.
SOMMERVILLE, Ian. Software Engineering – 8ª Edição. Addison-Wesley, 2006.
Sparx Systems. Enterprise Architect. Disponível em:
<http://www.sparxsystems.com.au/>. Acesso em: 04 ago. 2010.
TABORDA, Loana Wollmann. Sequenciamento da Produção em Indústria Metal-
Mecânica. Três de Maio: SETREM, 2008.
TAHCHIEV, Petar; LEME, Felipe; MASSOL, Vincent; GREGORY, Gary. JUnit in Action
– 2ª Edição. Greenwich: Manning, 2009.
YEATES, Donald; WAKEFIELD, Tony. Systems Analysis and Design – 2ª Edição.
Harlow: Pearson, 2004.
APÊNDICES
APÊNDICE A: Especificação dos Requisitos do Sistema
APÊNDICE B: Documento de Arquitetura
APÊNDICE C: Plano de Testes
APÊNDICE D: Relatório de Testes
APÊNDICE E: Manual do Usuário
APÊNDICE F: Modelo Entidades-Relacionamentos
APÊNDICE A
ESPECIFICAÇÃO DOS REQUISITOS DO SISTEMA
APÊNDICE B
DOCUMENTO DE ARQUITETURA
APÊNDICE C
PLANO DE TESTE
APÊNDICE D
RELATÓRIO DE TESTES
APÊNDICE E
MANUAL DO USUÁRIO
96
APÊNDICE F
MODELO ENTIDADES-RELACIONAMENTOS