Desenvolvimento de um Software para Sequenciamento da Produção em uma Indústria Metal-Mecânica...

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


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;


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;


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;


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


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


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


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


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


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


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


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


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.


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

Desenvolvimento de um Software para Sequenciamento da Produção em uma Indústria Metal-Mecânica...

Documents

Transcript of Desenvolvimento de um Software para Sequenciamento da Produção em uma Indústria Metal-Mecânica...