HELTON EDUARDO RITTER MAYCON VIANA BORDIN

DESENVOLVIMENTO DE UM SOFTWARE PARA SEQUENCIAMENTO DA PRODUO DE UMA INDSTRIA METAL-MECNICA

Trs de Maio 2010

HELTON EDUARDO RITTER MAYCON VIANA BORDIN

DESENVOLVIMENTO DE UM SOFTWARE PARA SEQUENCIAMENTO DA PRODUO DE UMA INDSTRIA METAL-MECNICA

Relatrio da Prtica Profissional Direcionada V Sociedade Educacional Trs de Maio Faculdade Trs de Maio Curso de Bacharelado em Sistemas de Informao

Professores Orientadores: M. Sc. Cristiano Schwening Esp. Leila Dalazen M. Sc. Adalberto Lovato Esp. Tiago Cesa Seibel

Trs de Maio 2010

RESUMO Este trabalho apresenta a soluo de sequenciamento da produo para uma fabricante de peas de colheitadeiras como parte da Prtica Profissional Direcionada V do curso de Sistemas de Informao da SETREM e foi desenvolvido no segundo semestre de 2010. O problema atual era sequenciar um grande nmero de peas para serem produzidos em pequenos lotes, usando planilha eletrnica o que demanda tempo excessivo para produzir o sequenciamento. O procedimento atual eficiente para um pequeno conjunto, mas fica ineficiente medida que o nmero de conjuntos aumenta. O software foi desenvolvido aps uma detalhada anlise do cenrio, na fase de projeto. Foi desenvolvido em linguagem Java e PostgreSQL como banco de dados. Os objetivos foram alcanados aps uma abrangente fase de testes providos pelas recomendaes de Engenharia de Software. Palavras chave: Sequenciamento da produo, 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: Oramento 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 no-funcionais. ................................................................. 41 Figura 8: Exemplo de requisito de sistema. ................................................................... 42 Figura 9: Traduo do modelo de anlise para um modelo de projeto. ......................... 45 Figura 10: Dimenses do modelo do projeto. ................................................................. 47 Figura 11: Qualidade no ciclo de vida. ........................................................................... 61 Figura 12: Exemplo do pattern faade. .......................................................................... 64 Figura 13: Exemplo do pattern Presentation Model. ...................................................... 65 Figura 14: Plataforma Java. ........................................................................................... 70

LISTA DE SIGLAS

CMM CMMI CRC GCJ GUI HTML IDE IEC ISO JDK JIT

Capability Maturity Model Capability Maturity Model Integration Class-Resposability-Colaborator GNU Compiler for Java Graphic User Interface Hyper Text Markup Language Integrated Development Environment International Electrotechnical Commission International Organization for Standardization Java Development Kit Just In Time

JRE JVM KISS MER MVC OO ORM PDF PMP RAD RTF SDK SEI SGBD SQA SQL SRS

Java Runtime Environment Java Virtual Machine Keep It Simple, Stupid! Modelo de Entidades-Relacionamentos Model-View-Controller Orientao a Objetos Object-Relational Mapping Portable Document Format Plano Mestre de Produo Rapid Application Development Rich Text Format Software Development Kit Software Engineering Institute Sistema Gerenciador de Banco de Dados Software Quality Assurance Structured Query Language Software Requirements Specification

UML XP

Unified Modeling Language eXtreme Programming

SUMRIO

RESUMO.......................................................................................................................... 3 ABSTRACT...................................................................................................................... 4 LISTA DE FIGURAS ........................................................................................................ 5 LISTA DE SIGLAS ........................................................................................................... 6 SUMRIO ........................................................................................................................ 9 INTRODUO ............................................................................................................... 13 CAPTULO 1: ASPECTOS METODOLGICOS ........................................................... 15 1.1 TEMA ....................................................................................................................... 15 1.1.1 Delimitao do Tema........................................................................................... 15 1.2 JUSTIFICATIVA ....................................................................................................... 15 1.3 PROBLEMA ............................................................................................................. 16 1.4 HIPTESES ............................................................................................................. 17 1.5 OBJETIVOS ............................................................................................................. 17 1.5.1 Objetivo Geral ...................................................................................................... 17 1.5.2 Objetivos Especficos ......................................................................................... 17 1.6 METODOLOGIA ....................................................................................................... 18 1.6.1 Mtodos de Abordagem...................................................................................... 18 1.6.2 Mtodos de Procedimento.................................................................................. 18 1.6.3 Tcnicas de Pesquisa ......................................................................................... 19

10

1.7 CRONOGRAMA ....................................................................................................... 20 1.8 RECURSOS ............................................................................................................. 21 1.9 ORAMENTO .......................................................................................................... 21 CAPTULO 2: FUNDAMENTAO TERICA.............................................................. 22 2.1 A EMPRESA ............................................................................................................ 22 2.2 ADMINISTRAO DA PRODUO ........................................................................ 22 2.2.1 Viso Geral das Atividades do Planejamento Operacional ............................. 23 2.2.1.1 Planejamento de Longo Prazo ........................................................................... 23 2.2.1.2 Planejamento de Mdio Prazo ........................................................................... 24 2.2.1.3 Planejamento de Curto Prazo ............................................................................ 24 2.2.1.4 Estratgias do Planejamento da Produo ........................................................ 26 2.2.2 Programao 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 Anlise................................................................................................................ 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 Integrao......................................................................................... 52 2.3.2.5.4 Teste de Validao .......................................................................................... 53 2.3.2.5.5 Teste de Sistema ............................................................................................ 54 2.3.2.5.6 Depurao ....................................................................................................... 55

11

2.3.2.6 Manuteno........................................................................................................ 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 refatorao, ou ainda refabricao) ....................................... 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 CAPTULO 3: RESULTADOS ....................................................................................... 75 3.1 SITUAO ATUAL DA EMPRESA .......................................................................... 75 3.2 ESPECIFICAO DOS REQUISITOS DO SISTEMA ............................................. 76 3.2.1 Domnio do Problema ......................................................................................... 76 3.2.2 Resultados Esperados ........................................................................................ 78 3.2.3 Impacto do Sistema na Empresa ....................................................................... 78 3.3 ANLISE 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 DESCRIO DO DESENVOLVIMENTO ................................................................. 80 3.5 TESTES DO SISTEMA ............................................................................................ 81

12

3.6 MANUTENO DO SISTEMA ................................................................................. 82 CONCLUSO ................................................................................................................ 84 REFERNCIAS .............................................................................................................. 87 APNDICES .................................................................................................................. 90 APNDICE A: Especificao dos Requisitos do Sistema .................................................. APNDICE B: Documento de Arquitetura .......................................................................... APNDICE C: Plano de Testes...................................................................................... 90 APNDICE D: Relatrio de Testes .................................................................................... APNDICE E: Manual do Usurio ...................................................................................... APNDICE F: Modelo Entidades-Relacionamentos ..........................................................

13

INTRODUO As empresas normalmente evoluem com o passar do tempo, superam-se as dificuldades burocrticas, a complexidade de produzir um produto, comercializar, fidelizar. Uma vez o processo estando estvel faz-se perceptvel o maior dos desafios: otimiz-lo. Entenda-se que numa otimizao, cada unidade do processo possui suas complexidades caractersticas, e que influenciam sistematicamente o todo. Em uma metalrgica, um processo que pode ser otimizado para obter um melhor custo-benefcio o sequenciamento fino da produo, esta foi a demanda apresentada pela Metalrgica Fratelli, e que este trabalho fruto da Prtica Profissional Direcionada V, focada em sistemas de produo, busca auxiliar na melhora do processo atravs do desenvolvimento de um software especialista. O desenvolvimento de uma soluo em software, para prover solues a um problema real e estratgico de uma organizao necessita de uma base slida de conhecimentos que possam auxiliar a diminuir a complexidade, e garantir a qualidade seja quanto a requisitos ou aspectos tcnicos. A engenharia de software prov recomendaes que inferem positivamente no xito de todas as fazes de um sistema, desde o planejamento a implantao e posterior suporte.

14

Tendo a modelagem do problema real representada computacionalmente atravs de um padro, como o UML e demais questes iniciais resolvidas, precisa-se eleger ferramentas de desenvolvimento. Neste quesito, a opo feita pela linguagem de programao Java, e IDE NetBeans mostra-se alinhada possibilidade de implementar as recomendaes da engenharia de software. O captulo 1 apresenta o projeto deste trabalho, planejamento, metodologias utilizadas e justifica a pertinncia deste trabalho frente ao contexto do problema. No captulo 2, discutem-se os itens bsicos para que o problema possa ser compreendido na mincia que a especificidade do sequenciamento fino da produo requer. Finalmente, apresentam-se os resultados obtidos no terceiro captulo, neste que provase as hipteses e valida-se atravs dos testes os objetivos descritos no primeiro captulo. O sequenciamento fino da produo, pela sua complexidade (como apresenta o cap. 2), uma atividade que requer softwares alinhados a estrutura fsica, recursos materiais, critrios 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 situaes, no vivel uma busca exaustiva das possibilidades do sequenciamento, fazendo-se necessrio o uso de uma heurstica na busca de uma soluo boa. Sugestes de melhorias futuras so apresentadas no captulo 3.

15

CAPTULO 1: ASPECTOS METODOLGICOS 1.1 TEMA Desenvolvimento um software para o sequenciamento de produo em uma indstria metal-mecnica. 1.1.1 Delimitao do Tema Desenvolvimento de um software em linguagem de programao Java para o sequenciamento da produo da metalrgica Fratelli localizada em Santa Rosa RS, fazendo uso das metodologias e boas prticas da Engenharia de Software durante todo o projeto. Este projeto foi desenvolvido dentro da Prtica Profissional Direcionada V do curso de Bacharelado em Sistemas de Informao, envolvendo as disciplinas de Engenharia de Software, Sistemas de Produo e Programao Comercial III, no perodo de julho a dezembro de 2010 na Sociedade Educacional Trs de Maio SETREM, na cidade de Trs de Maio, RS. 1.2 JUSTIFICATIVA O planejamento da produo tem por objetivo a melhoria da cadeia de produo, visando melhor atender os clientes e consequentemente garantir a sustentabilidade da organizao. Esse planejamento formado pelo plano agregado,

de longo prazo; o Plano Mestre de Produo (PMP), em mdio prazo; e as tcnicas de seqenciamento (ou programao fina), visando a operacionalizao diria. Enquanto o planejamento agregado e o PMP possuem mtodos padronizados e largamente aceitos, o sequenciamento dirio da produo fica restrito as caractersticas peculiares de cada negcio demandando mtodos e tcnicas personalizados. A programao fina determina como ser distribuda a produo entre os recursos disponveis (mquinas, pessoas, processos). A aplicao de tcnicas e mtodos que buscam a otimizao do sequenciamento traduzem-se em melhor utilizao das mquinas e conformidade com o tempo de entrega. A consequncia disto o melhor atendimento do cliente, maximizao da eficincia produtiva e reduo de custos. A metalrgica Fratelli j possui uma soluo para o sequenciamento de sua produo. A soluo projetada inicialmente para 16 diferentes conjuntos no escalvel e assim revelou insuficincias no sequenciamento de uma gama maior de conjuntos, que hoje atinge cerca de 50. Da a necessidade de uma soluo que consiga ser escalvel, atendendo as crescentes demandas da indstria, atravs de um sistema mais eficiente, que proporcione maior agilidade no sequenciamento. 1.3 PROBLEMA Como desenvolver um software utilizando mtodos de engenharia de software que seja capaz de sequenciar a produo de uma indstria metal-mecnica?

17

1.4 HIPTESES A soluo fornecida pelo software torna o processo de sequenciar a produo mais rpido do que a soluo atualmente empregada na empresa. A utilizao de testes unitrios diminui a ocorrncia de erros no software e facilita a execuo de testes. 1.5 OBJETIVOS Nesta seo encontram-se os objetivos gerais deste projeto bem como os objetivos especficos. 1.5.1 Objetivo Geral Desenvolver um software que seja capaz de sequenciar a produo diria da metalrgica de forma eficiente. 1.5.2 Objetivos Especficos Definir o escopo do projeto e levantar os requisitos dos clientes. Buscar o embasamento terico nas reas envolvidas pelo projeto. Pesquisas e testes sobre as ferramentas que sero utilizadas no desenvolvimento. Desenvolver a anlise com base nos requisitos levantados. Desenvolver o software e as unidades de teste. Documentar as classes do software.

18

Comparaes dos resultados obtidos com o mtodo utilizado atualmente na indstria.

Produzir o relatrio, artigo e a apresentao dos resultados.

1.6 METODOLOGIA Atravs do desenvolvimento do problema, todo trabalho busca analisar, desenvolver observaes, critic-los e interpret-los. A metodologia fornece os mtodos e tcnicas para a correta investigao do pensamento e desenvolvimento do problema em direo busca de solues (OLIVEIRA, 2002). 1.6.1 Mtodos de Abordagem Este trabalho classificado como quantitativo, sendo focalizado em termos de grandeza ou quantidade do fator presente em uma situao. (MARCONI; LAKATOS, 2006, p. 148). De forma mais especfica, este trabalho quantitativo, pois se baseia em valores numricos para a comparao entre os resultados obtidos pelo software em comparao com outras abordagens para a soluo do problema. 1.6.2 Mtodos de Procedimento Atravs dos requisitos dos usurios e com o conhecimento necessrio a respeito das reas abordadas neste trabalho, estes obtidos atravs de tcnicas de pesquisa descritas na prxima seo, desenvolve-se a anlise. Esta basicamente uma representao grfica e mais detalhada do que o sistema deve abranger, fruto da observao e pesquisa indireta a respeito do problema. Depois de formada a anlise, existe o projeto do sistema, onde se determina as ferramentas que sero 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 anlise 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 anlise como no projeto do sistema sero usados diagramas para a representao dos dados armazenados pelo sistema, o ambiente do sistema e seu comportamento em determinadas situaes. Estas representaes se daro atravs dos diagramas da UML e de Entidades-Relacionamentos. 1.6.3 Tcnicas de Pesquisa Tcnica um conjunto de preceitos ou processos que se serve uma cincia ou arte; a habilidade para usar esses preceitos ou normas, a parte prtica. Toda cincia utiliza inmeras tcnica na obteno de seus propsitos. (MARCONI; LAKATOS, 2006, p. 63). O primeiro passo no desenvolvimento deste trabalho foi o levantamento de informaes a respeito do problema da empresa. Isso se deu atravs de entrevistas com os envolvidos na atividade da empresa e tambm pela visitao da empresa para a observao de como o funcionamento se d atualmente e quais os problemas que l incorrem. Outra forma de levantar informaes a respeito do problema foi atravs de pesquisa bibliogrfica, onde se buscou livros, peridicos e artigos que abordassem o assunto. Sendo importante ressaltar que o recolhimento de informaes foi feito em todas as reas envolvidas neste trabalho, no somente aquela relacionada diretamente com o problema. reas estas que passam a ser abordadas na seo seguinte.

20

1.7 CRONOGRAMA O projeto segue o seguinte cronograma, que teve incio no ms 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 durao 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 Novembro Agosto Julho Fases do Projeto Dezembro * Setembro Outubro * * * * *

Fundamentao Terica Levantamento dos Requisitos Modelo Entidades Relacionamentos Anlise do sistema Desenvolvimento do Sistema Testes de Qualidade Entrega do Relatrio e Artigo Parciais Entrega do Relatrio e Artigo Finais Apresentao da Prtica Entrega do Relatrio 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 ORAMENTO

Descrio Impresso Projeto Impresso Relatrio Parcial Impresso Artigo Parcial Impresso Relatrio Final Impresso Artigo Final Impresso Relatrio Corrigido Horas trabalhadas (x2)

Quantidade 25 80 12 390 12 130 120

Valor R$ 0,12 R$ 0,12 R$ 0,12 R$ 0,12 R$ 0,12 R$ 0,12 R$ 12,00 Total:

Total R$ 3,00 R$ 9,60 R$ 1,44 R$ 46,80 R$ 1,44 R$ 15,60 R$ 1.440,00 R$ 1.517,88

Fonte: BORDIN, RITTER, DALAZEN, LOVATO, SCHWENING, SEIBEL (2010).

Figura 2: Oramento do projeto.

CAPTULO 2: FUNDAMENTAO TERICA Neste captulo so abordados todos os assuntos empregados no

desenvolvimento deste trabalho, dando o devido enfoque para Sistemas de Produo, que contm o embasamento necessrio para a compreenso do problema que se props resolver e tambm a respeito de Engenharia de Software, fornecendo o material necessrio para a melhor organizao do projeto, seguindo padres, modelos e boas prticas descritas na literatura. 2.1 A EMPRESA A Metalrgica Fratelli foi fundada em julho de 1986 e est localizada no municpio de Santa Rosa RS. Atualmente possui certificao ISSO 9001:2004 e conta com mais de 70 funcionrios. Produz peas para colheitadeiras, tratores e outros equipamentos no automotivos, tendo como principais clientes AGCO, John Deere e Brunning (TABORDA, 2008). 2.2 ADMINISTRAO DA PRODUO 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 mnimo (DAVIS; AQUILANO; CHASE, 2001).

23

O processo de planejamento agregado identifica os mtodos alternativos para compatibilizar a oferta e a demanda, segundo a perspectiva da Administrao da Produo (DAVIS; AQUILANO; CHASE, 2001). 2.2.1 Viso Geral das Atividades do Planejamento Operacional O planejamento da produo se divide em escalas de tempo (longo, mdio e curto prazo), cada escala tem o seu nvel de detalhamento, e se relaciona com outros setores da empresa como vendas, marketing e gesto de pessoas (DAVIS; AQUILANO; CHASE, 2001). 2.2.1.1 Planejamento de Longo Prazo Normalmente feito todo ano em relao 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 declarao dos objetivos da organizao e suas metas para os prximos 2 a 10 anos. O planejamento estratgico do grupo articula como esses objetivos e metas sero atingidas levando em conta a capacitao da empresa e seu ambiente econmico e poltico, projetando sua previso de negcios (DAVIS; AQUILANO; CHASE, 2001). Os elementos do planejamento estratgico incluem a delimitao da linha de produtos, dos nveis de qualidade e preo e das metas de penetrao no mercado. O planejamento de recursos identifica as instalaes, os equipamentos e o pessoal necessrio para viabilizar o plano de produo 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 Mdio Prazo Para um perodo de 6 a 8 meses, planejado para o semestre e revisado a cada trimestre, pois este planejamento j mais especfico (DAVIS; AQUILANO; CHASE, 2001). No planejamento de mdio prazo se faz o planejamento agregado da produo, a previso de vendas por item, o programa mestre de produo (PMP), e o planejamento grosseiro da capacidade. O plano agregado fornece ligao entre os planos estratgicos (longo prazo) e o planejamento intermedirio. Especifica a produo mensal ou trimestral necessria para os principais grupos de produtos, fornece dados de quantas horas de trabalho sero necessrias, e alocao de unidades de trabalho. A previso de vendas por item fornece dados para o plano mestre de produo, monitorar essa informao denomina-se gesto da demanda. O programa mestre de produo 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 perodo de um dia a 6 meses. Normalmente revisado semanalmente, ou em alguns casos diariamente. o planejamento fino da produo. Varia muito de empresa para empresa (DAVIS; AQUILANO; CHASE, 2001). Este plano bem especfico, e subdivide-se geralmente em outros, que so: 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 produo e os pedidos de compra devem ser colocados para cada pea e para as submontagens, para que os produtos sejam concludos segundo a programao (DAVIS; AQUILANO; CHASE, 2001). Planejamento das necessidades e de capacidade Fornece uma programao detalhada de quando cada operao deve ser executada em cada centro de trabalho, e quanto tempo levar para ser processada (DAVIS; AQUILANO; CHASE, 2001). Programao da montagem final Essa atividade identifica as diversas operaes necessrias para colocar o produto em sua forma final. aqui que o produto e suas caractersticas finais so programadas (DAVIS; AQUILANO; CHASE, 2001). Plano e controle de Entrada/Sada Refere-se a uma variedade de relatrios e procedimentos, ressaltando as demandas programadas e as restries de capacidade derivadas do plano de materiais (DAVIS; AQUILANO; CHASE, 2001). Controle das atividades de produo A programao e o controle das atividades no cho de fbrica. Envolve a programao e o controle das atividades do dia a dia no cho de fbrica. Neste ponto, o programa mestre de produo alterado segundo as prioridades imediatas da organizao diria do trabalho (DAVIS; AQUILANO; CHASE, 2001). Planejamento e controle das compras O planejamento e controle de entrada/sada so necessrios para se certificar de que a aquisio no somente para obteno de materiais em tempo de obedecer a programao, mas tambm para se estar ciente sobre os mesmos, os quais, por vrias razes, podem ter as entregas programadas (DAVIS; AQUILANO; CHASE, 2001).

26

Resumidamente, todas as abordagens de planejamento tentam equilibrar a capacidade necessria com a capacidade disponvel, e a partir da programar e controlar a produo levando em conta as mudanas no balao de capacidade. Um bom sistema de planejamento completo quando, sem ser opressivo, tem a confiana de seus usurios na estrutura da organizao (DAVIS; AQUILANO; CHASE, 2001). 2.2.1.4 Estratgias do Planejamento da Produo Existem, essencialmente, trs estratgias de planejamento da produo. Essas estratgias envolvem um compromisso entre a quantidade e a mo de obra, os horrios de trabalho, os estoques e outras reservas (DAVIS; AQUILANO; CHASE, 2001). 1. Estratgia de acompanhamento da demanda Nivelar a taxa de produo para atingir exatamente a taxa de sada exigida pela demanda, atravs da contratao e da demisso de empregados. O sucesso desta estratgia depende da existncia 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 produo pelo medo de serem demitidos, assim que os pedidos existentes sejam concludos. 2. Mo de obra estvel, horas de trabalho variveis variar a produo (sada) pela variao de nmero de horas trabalhadas atravs de programaes flexveis de trabalho e de horas extras. Essa estratgia fornece continuidade da mo de obra, e evita tanto os custos emocionais como os tangveis, de contratar e despedir pessoal, associados a estratgia de acompanhamento da demanda. 3. Estratgia de capacidade constante Manter a mo de obra estvel trabalhando com uma taxa de produo constante. A escassez e o excesso so absorvidos pelos nveis flutuantes de estoques, de pedidos em carteira

27

e de vendas perdidas. Os empregados beneficiam-se das horas de trabalho estveis, mas os custos em estoque so aumentados. Outra preocupao a possibilidade dos produtos em estoque se tornarem obsoletos. Quando apenas uma destas variantes utilizada para absorver as flutuaes da demanda, tem-se uma estratgia pura; quando uma ou mais so utilizadas em combinao, tem-se uma estratgia mista. Como voc pode suspeitar, as estratgias mistas so mais amplamente aplicadas na indstria (DAVIS; AQUILANO; CHASE, 2001). A subcontratao tambm pode ser aplicada, isso se faz sob demanda, mas uma estratgia perigosa, o fabricante pode perder o controle sobre a programao e a qualidade. A vantagem de se estar trabalhando com uma pessoa jurdica e no fsica, logo no h o desgaste de uma demisso (DAVIS; AQUILANO; CHASE, 2001). 2.2.2 Programao e Sequenciamento de um Ambiente Job Shop Um Job Shop uma organizao funcional cujos departamentos ou centros de trabalho so organizados em torno de processos particulares, os quais consistem em tipos especficos de equipamentos e/ou operaes, tais como perfurao e montagem em uma fbrica, operaes de leitura tica (scanner) e impresso em um laboratrio de computao, ou salas para exames especiais e, uma emergncia de um hospital (DAVIS; AQUILANO; CHASE, 2001). Uma programao uma distribuio temporal utilizada para distribuir atividades, utilizando recursos ou alocando instalaes. A proposta da programao de operaes em uma Job Shop desagregar o Programa Mestre de Produo (PMP) em atividades semanais, dirias e por hora, sequenciadas no tempo em outras palavras, especificar em termos precisos a carga de trabalho planejada no processo de produo para o curto prazo. O controle de operaes monitora o progresso das ordens e, quando necessrio, 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 programao e controle, deve-se tomar providncias para que se atinja um desempenho eficiente das seguintes funes: 4. Alocar ordens, equipamentos e pessoal para os centros de trabalho ou para locais especficos. Essencialmente isto o planejamento da capacidade no curto prazo. 5. Determinar a sequencia da execuo das ordens. Isto , estabelecer tarefas prioritrias. 6. Iniciar a execuo do trabalho programado, normalmente denominado despacho das ordens. 7. Controle do cho de fbrica, que envolve: revisar o status e controlar o progresso das ordens conforme elas estejam sendo executadas; tambm expedir ordens atrasadas e crticas. 8. Revisar a programao para contemplar alteraes recentes nos status das ordens. 9. Garantir que os padres de controle de qualidade esto sendo atingidos. A dificuldade em fazer-se essa programao encontram-se justifica nos seguintes fatores: Este bem/servio pode nunca ter sido feito anteriormente; assim as estimativas do tempo de durao esperado para a concluso dos diversos componentes pode ser bastante diferente do tempo real. A sequencia de operaes extremamente flexvel e, com uma mo de obra multifuncional, o nmero de sequencias possveis pode ser enorme.

29

Tentar avaliar os resultados esperados das diferentes sequencias com o objetivo de encontrar a melhor , normalmente muito difcil. Para operaes diferentes, o parmetro para determinao da melhor sequencia pode variar em um caso pode ser a minimizao do desperdcio, em outra pode ser a minimizao do tempo ocioso das instalaes, e por um terceiro pode ser a maximizao do ganho e assim por diante. Assim mesmo com extensas pesquisas feitas no campo da programao de Job Shops, difcil encontrar algoritmos quantitativos que sejam apropriados para todas as situaes. 2.3 ENGENHARIA DE SOFTWARE Toda a engenharia deve ter como base o foco na qualidade, e na engenharia de software no exceo. Esta formada por vrias camadas, sendo elas: foco na qualidade, processos, mtodos e ferramentas (PRESSMAN, 2006).

Os processos so aqueles responsveis por unir as camadas da engenharia de software. Atravs de processos se define o que ser feito, como sero utilizadas as tecnologias de engenharia de software. So 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 organizao do mesmo, os mtodos ficam encarregados de mostrar como fazer cada tarefa dentro de um projeto. Exemplos de mtodos podem ser: comunicao, planejamento, modelagem, construo e implantao. E para auxiliar tanto os processos como os mtodos de um projeto podem ser utilizadas ferramentas de engenharia de software (PRESSMAN, 2006).

30

Como foi dito anteriormente, a definio dos processos que sero seguidos depende do projeto que se est planejando executar. Mesmo com variaes, grande parte dos projetos composta por fases comuns, como: especificao, modelagem e implementao, validao e evoluo (as necessidades mudam com o tempo) (SOMMERVILLE, 2006). Entretanto, existem modelos de processos para o desenvolvimento de sistemas, estes modelos sero brevemente abordados na prxima seo deste captulo. 2.3.1 Modelos de Processos De acordo com Sommerville (2006), modelos de processos so representaes abstratas de processos de software. Cada modelo possuir suas particularidades, oferecendo uma perspectiva diferente dos processos. Os modelos mais conhecidos so: modelo em cascata, desenvolvimento evolucionrio e engenharia de software baseada em componentes. Alm destes modelos, Pressman (2006) cita os modelos incrementais, como o modelo RAD (Rapid Application Development) e o modelo incremental; os modelos evolucionrios, 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. Sero abordados nas prximas sees 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 esto colocadas em sequncia, uma aps a outra, sendo que uma fase no pode iniciar

31

antes de a fase anterior ter sido finalizada. Esse modelo est ilustrado na Figura 3 (SOMMERVILLE, 2006).

Fonte: SOMMERVILLE, 2006, p. 66.

Figura 3: Fases do modelo em cascata. Uma das principais crticas a este modelo exatamente pela sua caracterstica mais marcante, a disposio 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 no forem corrigidos logo no incio do projeto podero custar muito mais para serem senados nas fases finais (SOMMERVILLE, 2006). Este modelo ainda caracterizado pela produo de documentao em cada fase de software, tornando-o compatvel com vrios outros modelos de processos. Por outro lado, ele se mostra como um modelo com pouca flexibilidade e que no leva em conta imprevistos implicados em projetos de software (SOMMERVILLE, 2006). 2.3.1.2 Prototipagem Como o prprio nome insinua, trata-se de um modelo de processos baseado em prottipos. Esta abordagem pode, na verdade, ser utilizada em qualquer outro

32

modelo de processos, mas seu uso fica concentrado em projetos onde no exista uma definio concreta daquilo que deve ser construdo (PRESSMAN, 2006). Neste modelo uma definio dos objetivos do software feita com o cliente, identificando as necessidades e salientando pontos que no esto muito claros. Com essas informaes j possvel construir um prottipo do sistema, atravs deste prottipo o cliente vai fornecendo mais informaes sobre o que ele precisa. A Figura 4 ilustra o ciclo existente no modelo de prototipagem, reforando que este modelo faz parte dos modelos evolucionrios (PRESSMAN, 2006).

Fonte: PRESSMAN, 2006, p. 43.

Figura 4: Modelo de prototipagem. Este prottipo desenvolvido dever ser descartvel, ou seja, ela simplesmente serve para que as necessidades dos clientes sejam melhor captadas. At porque este prottipo em grande parte das vezes no ir seguir padres de desenvolvimento, otimizaes de cdigo, boas prticas. possvel ainda que a linguagem utilizada pelo prottipo no seja a mesma que ser usada para o software final, sendo esta primeira utilizada apenas por facilitar o desenvolvimento rpido de aplicaes (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 aplicao que lhe foi apresentada trata-se apenas de um prottipo e exige modificaes no prottipo para que ele possa us-lo. E o outro problema utilizar este prottipo como base para o desenvolvimento do software final, e isso um problema exatamente pelo fato de o prottipo no ter um nvel de qualidade muito bom (PRESSMAN, 2006). por isso que deve haver uma boa comunicao com o cliente, para deixar claro os propsitos de se utilizar prottipos e que o verdadeiro software ser desenvolvido seguindo padres 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 cclica, sendo que a cada ciclo o software vai evoluindo. Sendo que a cada ciclo o planejamento do projeto reajustado de acordo com as circunstncias (PRESSMAN, 2006). Na Figura 5 percebe-se que as atividades do projeto vo sendo executadas em sentido horrio e que a cada novo ciclo uma nova anlise dos riscos feita, bem como o prottipo evolui. Dentre as vantagens dessa abordagem est a reduo dos riscos em um projeto, alm do desenvolvimento de prottipos ao longo dos ciclos do projeto. Esse modelo leva em considerao que os softwares no so estticos, mas sim que eles tambm tendem a evoluir com o tempo (PRESSMAN, 2006).

34

Fonte: SOMMERVILLE, 2006, p. 74.

Figura 5: Modelo em espiral. Dentre os problemas deste modelo esto o fato de o oramento do projeto ser revisado a cada ciclo, e quando organizaes exigem oramentos fixos isso pode se tornar um problema. A anlise dos riscos tambm feita a cada ciclo do projeto, e isso muito bom, o que pode ser um problema o levantamento precrio 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 mdio porte, focada principalmente em projetos com requisitos que tendem a mudar com freqncia ou que no sejam muito claros (BECK, 1999). As idias e mtodos de XP foram abordados pela primeira vez na dcada de 1980. Entretanto, apenas ganharam notoriedade quando Kent Beck fez uma publicao sobre o assunto, Beck (1999) (PRESSMAN, 2006).

35

Para Beck (1999) fato que muitas das idias que compe XP fazem parte do senso comum, com a diferena que eXtreme significa que estas idias devem ser levadas realmente ao mximo, dentre elas tem-se: Revisar o cdigo a toda hora (programao em pares). Testar o tempo todo (testes de unidade), at mesmo os requisitos do cliente (testes funcionais). Melhorar a modelagem do sistema com refatorao de cdigo. Simplificar ao mximo a modelagem do sistema (KISS). Definir e melhorar a arquitetura sempre. Integrar e testar ela vrias vezes por dia. Iteraes com duraes curtas, as mais curtas possveis.

Atravs dessas idias Beck (1999) queria que programadores pudessem se preocupar com aquilo que realmente tinha importncia dentro de um projeto, tomando as decises 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 direo aos objetivos dentro de poucas semanas. Alm disso, mudanas poderiam ser feitas no meio do projeto sem que isso implicasse custos exorbitantes.

36

Fonte: PRESSMAN, 2006, p. 64.

Figura 6: O processo extreme programming. Na Figura 6 o modelo de processos do XP claramente cclico. Tratam-se de iteraes ou incrementos do projeto, e em cada iterao todas as fases (ou melhor, atividades) descritas acima so executadas. A primeira atividade descrita o planejamento. Aqui sero criadas as histrias que descrevem funcionalidades e caractersticas que o software deve ter. Elas so criadas pelos clientes e colocadas em cartes juntamente com um valor que ir definir a prioridade da histria. Depois de reunidos os cartes, a equipe do projeto ir estimar o custo em tempo das histrias, aquelas com alto custo sero re-avaliadas com o cliente para serem divididas em mais de uma histria (PRESSMAN, 2006). Nesta atividade so ainda definidas quais as histrias que sero

implementadas, o que pode variar da quantidade de histrias que foram criadas. Depois da primeira iterao ser possvel ento estimar o tempo que levar para terminar o projeto (PRESSMAN, 2006). Na fase de projeto o nico produto resultante sero os cartes CRC (ClassResposability-Colaborator), que servem para identificar as classes de objetos relevantes

37

s histrias que sero implementadas no incremento corrente. Alm disso, prottipos podem ser criados caso sejam encontradas dificuldades em alguma histria, isso importante para que os riscos envolvidos sejam reduzidos (PRESSMAN, 2006). Falando em riscos, importante frisar a preocupao que XP tem com os riscos envolvidos em projetos de software. por isso que existem iteraes com perodos curtos de tempo, evitando assim acmulo de atrasos durante o projeto e as histrias de maior prioridade tem sempre a preferncia, enquanto que as que por ventura atrasaram passam a ter menor prioridade (BECK, 1999). Outras atitudes que ajudam na reduo de riscos so a ateno aos testes, estes realizados diversas vezes por dia atravs de testes de unidade e com a exigncia de sempre se ter um sistema funcional. Em adio a esta atitude est a programao em duplas que tem mostrado grande efetividade na reduo 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 refatorao (refactoring ou refabricao) do cdigo criado durante as iteraes anteriores. A refatorao trata de tornar o cdigo mais claro, sem que isso altere o comportamento do mesmo. Ou como Fowler et al. (1999) coloca: uma forma disciplinada de limpar o cdigo que minimiza as chances de se introduzir bugs.. Na codificao a primeira coisa que deve ser feita a construo de testes de unidade para cada uma das histrias que sero implementadas na iterao atual. Depois de construdos os testes o desenvolvedor passa a implementar as funes para a execuo das histrias e to logo tenha implementado-as pode efetuar os testes de unidades para verificar se a codificao est em concordncia com os testes (PRESSMAN, 2006).

38

Outro ponto forte de XP quanto atividade de codificao a programao em pares. Isso mostra a preocupao desta metodologia em prover softwares de qualidade, pois atravs da programao em pares a descoberta de erros muito mais rpida, alm disso, com duas pessoas debruadas sobre o mesmo cdigo mais idias iro surgir e consequentemente implementaes mais criativas e eficientes. E como mais uma medida para garantir a qualidade e reduzir os erros, a integrao do sistema feita diariamente (integrao contnua), isso evita problemas de compatibilidade e interface. Ficou evidente que XP muito enftico quanto realizao contnua de testes em um sistema, principalmente durante a codificao do sistema. Ainda assim, uma atividade da iterao reservada somente para a realizao de testes. Nesta atividade, os testes unitrios (ou de unidade) so organizados de forma sequencial, principalmente porque muitos testes so interdependentes. Isso vm a facilitar os testes de integrao e validao, possibilitando tais verificaes diariamente sem muito custo (PRESSMAN, 2006). E por ltimo, so efetuados os testes dos clientes, este tem por finalidade verificar a conformidade do sistema com as histrias criadas pelos clientes. O teste valida o sistema pela perspectiva do cliente (PRESSMAN, 2006). 2.3.2 Fases de um Projeto A seguir sero abordadas as principais fases de um projeto, elas so as principais, pois a maioria dos modelos de processos faz uso delas, embora elas possam ser arranjadas de formas diferentes, conforme pde ser visualizado nas sees anteriores. Cada fase de um projeto corresponde a uma etapa que deve ser executada para que o objetivo principal do projeto seja alcanado. Uma fase na maioria das vezes, se no todas, tem por objetivo gerar um produto. Este no precisa necessariamente ser parte dos entregveis 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, tambm chamado de fase de Comunicao por Pressman (2006), pode ser considerado uma das mais importantes fases em um projeto, pois ela a responsvel pela captao dos requisitos que serviram de base para a execuo de todas as outras fases do projeto. E finalmente, para o sistema em questo que, quando entregue, dever atender as necessidades dos usurios explicitadas em requisitos. Da a importncia de se captar corretamente os requisitos dos usurios. E essa questo est totalmente relacionada com a forma que a comunicao desenvolvida entre clientes e membros da equipe de projeto (como o gerente de projeto, analista). Uma comunicao clara e onde exista compreenso 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 organizao (PRESSMAN, 2006). Sommerville (2006) deixa claro que deve haver distino entre os tipos de requisitos, do usurio e do sistema. Enquanto o primeiro trata do qu o sistema deve atender e sobre quais circunstncias, utilizando uma linguagem de mais fcil compreenso; o segundo aborda as funcionalidades do sistema de forma mais tcnica, informando precisamente o que cada funcionalidade deve fazer, sobre quais circunstncias e qualquer outro detalhe pertinente. E qual o motivo de existirem dois tipos de requisitos? Simples, porque cada um deles direcionado para diferentes leitores. Descries de requisitos em linguagem mais simples e que no trata o problema nos mnimos detalhes est direcionada para os clientes que no 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 esto sub-divididos em trs categorias, sendo elas: Requisitos funcionais: descrevem as funcionalidades que o sistema deve possuir e como ele deve reagir em determinadas situaes. Requisitos No-funcionais: descreve funcionalidades do sistema como um todo, estas podendo ser algum tipo de servio ou funo, geralmente este tipo de requisito trata de questes no relacionadas com o problema principal, mas que mesmo assim precisam ser em algum ponto definidas. Vale ressaltar que no atingir um requisito no-funcional pode significar que o sistema no poder ser usado pelos usurios, levando em conta que requisitos desta natureza podem exigir nveis de confiabilidade, segurana, performance, dentre outros. Descries mais detalhadas sobre atributos do software podem ser vistas na seo 2.3.3.1 que aborda a qualidade do produto de software. Requisitos de domnio: so aqueles relacionados diretamente com o ambiente onde estar inserido o sistema. Os requisitos no funcionais podem ainda ser divididos em vrios tipos, de acordo com o atributo que se busca atender em um software. Na Figura 7 possvel visualizar a estrutura dos tipos de requisitos em forma hierrquica. Basicamente existem os requisitos no-funcionais do produto, que dizem respeito ao comportamento do produto; os da organizao, que dizem respeito a polticas e padres que definem como o projeto dever ser executado; e os externos, estes relacionados com qualquer coisa externa ao sistema, desde legislaes at a integrao com outros sistemas existentes (SOMMERVILLE, 2006).

41

Fonte: SOMMERVILLE, 2006, p. 122.

Figura 7: Tipos de requisites no-funcionais. Quanto forma pela qual sero 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 no significa que ele deva ser seguido na construo dos requisitos, mas que serve de base para a construo de um modelo prprio, se necessrio. O exemplo da Figura 8 tem em seu cabealho (em fundo preto) o nome do requisito, no caso o controle de insulina. Na funo, feita uma breve descrio sobre o que esse requisito dever fazer, enquanto que a descrio se encarrega de detalhar melhor como isso ser feito. A entrada aquilo que se faz necessrio para atingir o objetivo, a fonte de onde esta entrada veio e a sada o resultado que se obteve atravs do processamento das entradas, este descrito em detalhes na ao. Alm disso, para que o requisito acontea se fazem necessrios alguns requisitos, bem como pr-condies, executando o requisito e obtendo uma ps-condio e eventuais efeitos colaterais (SOMMERVILLE, 2006).

42

Fonte: SOMMERVILLE, 2006, p. 132.

Figura 8: Exemplo de requisito de sistema. Com foi descrito nos pargrafos anteriores, existe uma grande importncia em se descrever requisitos de software de forma completa e no ambgua. Foi pensando nisso que foi criada a IEEE 830, um documento que contm as prticas recomendadas para a especificao de requisitos de software (SRS Software Requirements Specification). 2.3.2.2 Anlise Yeates e Wakefield (2004) descrevem a fase de anlise como sendo a responsvel pela especificao dos requisitos do negcio e da plataforma tcnica e como ser realizado o desenvolvimento do sistema. A anlise tem como objetivo a modelagem e descrio detalhada do sistema atravs de diagramas. Estes devem

43

fornecer uma viso do sistema sob diversas perspectivas, de modo claro e simples (PRESSMAN, 2006). Existem duas abordagens principais para a modelagem de anlise: estruturada e orientada a objetos. Este trabalho adota a orientao a objetos, mais especificamente a UML (Unified Modeling Language) (PRESSMAN, 2006). A orientao a objetos um paradigma adotado pela maioria das linguagens modernas de programao, principalmente por facilitar a compreenso do sistema e desenvolvimento, alm de facilitar a reutilizao de cdigos e criao de testes. Com a larga adoo do novo paradigma pelas novas linguagens de programao, passou-se a ter a necessidade de uma linguagem que possibilita-se a modelagem de sistemas dentro deste novo paradigma. A unio de diversos modelos deu origem a UML, hoje padro na anlise de sistemas orientados a objetos, formada por diversos diagramas que tem por objetivo mostrar o sistema sob um ngulo especfico de viso. Booch, Rumbaugh e Jacobson (2005) colocam entre os principais objetivos da anlise de sistemas: Visualizar um sistema como ele ou deve ser. Especificar a estrutura e comportamento de um sistema. Uso de um modelo padro que permita a construo do sistema. Documentao do sistema construdo.

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 no ir abenoar um sistema, pois a modelagem

44

apenas mais uma etapa dentre vrias da engenharia de software que podero garantir a qualidade do produto entregue. Alex Bell (2004) descreve em seu artigo Death by UML Fever alguns dos sintomas preocupantes com a relao UML na engenharia de software. Pressman (2006) ainda faz meno 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 descrio mais detalhada pode ser obtida na seo 2.4 deste trabalho. 2.3.2.2 Projeto O projeto de software se situa entre a anlise e a codificao do sistema. Nesta fase so criados modelos do software que, diferentemente do modelo de anlise, buscam detalhar as interfaces, arquitetura, estrutura de dados e componentes necessrios para a construo do sistema (PRESSMAN, 2006). A Figura 9 demonstra a converso de um modelo de anlise para um modelo de projeto, indicando que elementos da anlise so usados para formar cada um dos modelos de projeto, estes dispostos em pirmide. Atravs dos elementos baseados em classes (diagramas de classe, modelo crc) possvel 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 padres 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 comunicao do sistema com outros sistemas, as entradas e sadas dele e como elas ocorrero. E, partir dos elementos de classes, fluxo e comportamento se forma o projeto em nvel de componente, que descreve de forma procedural os componentes deste software (PRESSMAN, 2006).

45

Fonte: PRESSMAN, 2006, p. 187.

Figura 9: Traduo do modelo de anlise 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 documentao que descreve em detalhes o sistema em construo. A tendncia de tal documentao aumentar o nvel de detalhamento a cada iterao do projeto. Para que seja um projeto de qualidade, a documentao deve contemplar todos os requisitos do sistema, implcitos e explcitos; deve fornecer informaes suficientes para a codificao, teste e manuteno 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: organizao dos mdulos de um sistema, a forma como interagem entre si e as estruturas de dados utilizadas.

46

Padres: utilizar solues comprovadas para a soluo de problemas especficos de um projeto.

Modularidade: dividir um sistema em partes menores, isso facilita a compreenso das partes. Entretanto, quando se atinge um nmero muito grande de mdulos o custo do projeto e de integrao passa a ser alto, anulando as vantagens dessa diretriz.

Ocultamento da Informao: estende as caractersticas da modularidade ao esconder dados e operaes que no precisam ser conhecidas pelos outros mdulos. Alm disso, isso facilita teste, manuteno e limita a propagao de erros dentro do sistema.

Independncia Funcional: envolve tanto a modularidade como o ocultamento de informaes. A principal idia aqui tornar o mais independente possvel cada mdulo, sendo que a comunicao deve acontecer atravs de interfaces simples, evitando o mximo de

interdependncia entre mdulos. Refinamento: ir aprofundamento as especificaes do sistema a cada elaborao. Facilita a criao do modelo de projeto por partes, sendo que a cada melhoramento mais detalhes sero agregados ao modelo. Refabricao: por vezes refatorao, muito incentivado em metodologias geis, muito bem abordado por Fowler et al. (1999). Basicamente trata-se de melhorar o projeto ou cdigo do sistema, removendo redundncias, melhorando a compreenso e desempenho (para cdigos) sem modificar o comportamento externo. O tpico melhor abordado na seo 2.3.5. Classes de Projeto: so refinamentos das classes criadas para a compreenso do negcio na fase de anlise. Estas classes se subdividem

47

em: classes de interface com o usurio, classes do domnio de negcio, classes de processo, classes persistentes e classes de sistema. Na Figura 9 foi possvel ver quais os elementos fornecidos pela anlise que so utilizados para a construo dos modelos de projeto. J a Figura 10 mostra um grfico do nvel de abstrao e dos processos em relao aos modelos de anlise e projeto. Estando o primeiro dentro das dimenses mais abstratas e o segundo com baixa abstrao, significando que ele aborda mais a fundo as questes tcnicas do sistema. Quanto aos processos, eles descrevem o nvel de evoluo do projeto.

Fonte: PRESSMAN, 2006, p. 198.

Figura 10: Dimenses do modelo do projeto. Os elementos de arquitetura so a base para o projeto, e se baseiam em classes, subsistemas e diagramas de colaborao. J os elementos de interface se preocupam especificamente com o fluxo de dados dentro do sistema. Em nvel de componente o que existe uma descrio 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 nvel de implantao trata de onde sero alocados fisicamente o software e outros sistemas utilizados por ele (PRESSMAN, 2006). 2.3.2.4 Desenvolvimento Essa fase recebe como entrada a documentao do projeto e anlise e desenvolve ou adquire os componentes necessrios para se implementar todos os requisitos do sistema ou, em modelos de processo com iteraes, os requisitos planejados para a iterao. Nessa fase tambm so construdos os testes unitrios e feita a integrao do sistema (PRESSMAN, 2006). Como foi dito acima, nesta fase tambm so desenvolvidos os testes unitrios. Estes testes tm por objetivo testar as funcionalidades de cada mtodo das classes de um sistema. Testes unitrios so testes automatizados, ou seja, eles devem ser bem escritos uma vez e depois apenas execut-los para verificar se existem ou no erros no cdigo. Dentro de XP considerada uma boa prtica escrever antes o teste e depois implementar os mtodos da classe que deve estar em conformidade com o teste. Para Beck (1999) os testes tm uma perspectiva de longo e curto prazo. Em longo prazo o programa tende a viver mais, pois mais mudanas podem ser feitas e a escrita de mais testes aumenta a confiana no sistema. Em curto prazo programadores conseguem testar todo o seu sistema simplesmente ao apertar um boto. Alm disso, escrever testes aumenta a produtividade, pois no se perde tempo posterior debugando o cdigo 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 especificaes e que

49

entregue um produto de acordo com as expectativas dos clientes (SOMMERVILLE, 2006). Para Beck (1999), funcionalidades de software que no podem ser testadas no 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 necessrio. Dentro da fase de testes existem dois processos distintos, so eles: verificao e validao. 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 especificaes. 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 no obtida com testes, ela apenas confirmada, sua obteno s se d atravs de mtodos corretos de engenharia de software, boas praticas e correta gesto do projeto. Muitas pessoas, quando pensam em teste, imaginam que esta uma fase que deve ser realizada por pessoas de fora da organizao que aparecem do nada e fazem os testes. Quanto aos desenvolvedores existe aquela sensao de que as pessoas que vo realizar os testes vieram apenas para destruir aquilo que foi feito com tanto esforo. E, por outro lado, espera-se que esta equipe de testes resolva todos os problemas do sistema (PRESSMAN, 2006). Todas as situaes descritas acima por muitas vezes acontecem, o que no as torna algo verdadeiro, pelo menos no deveria ocorrer desta forma. Primeiro porque a equipe que ir desenvolver os testes deve estar envolvida tambm nas fases de anlise e projeto do sistema, afinal eles devem estar envolvidos com a forma pela qual o sistema est sendo concebido e tambm porque com este envolvimento o conhecimento a respeito do sistema ficar muito maior quando forem feitos os testes (PRESSMAN, 2006). Tambm no verdade que os desenvolvedores no devem realizar testes, pelo contrrio, so eles que iro fazer os primeiros testes no sistema. Estes geralmente

50

so os testes unitrios, que sero abordados mais a frente. Outros testes que tambm podem ser realizados pelos desenvolvedores so os testes de integrao, que iro integrar mdulos e garantir que estes esto se comunicando corretamente (PRESSMAN, 2006). Por fim, os desenvolvedores do sistema devem sim estar envolvidos na realizao dos testes juntamente com as equipes de testes, para garantir que os testes sero rigorosos, alm de que eventuais erros podem ser imediatamente corrigidos pelo desenvolvedor. Pressman (2006) define duas estratgias para testes de software, a primeira a abordagem convencional e a segunda a abordagem orientada a objetos. Como este trabalho ter sua anlise e desenvolvimento orientados a objetos conveniente abordar apenas a segunda estratgia de testes, o que acontece na seo 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 nmero possvel de erros com uma quantidade de esforo gerencivel aplicada durante um intervalo de tempo realstico.. O autor coloca ainda que esse conceito verdadeiro tanto para as estratgias tradicionais de teste como para as orientadas a objetos (OO), o que muda aqui como sero feitos os testes, as tticas de teste. Seguindo Pressman (2006), as principais mudanas em questes estratgicas quanto aos testes se do nos testes unitrios (ou de unidade) e nos testes de integrao. Estes dois assuntos sero abordados nas prximas sees juntamente com testes de validao e de sistema.

51

2.3.2.5.2 Teste de Unidade Segundo Sommerville (2006), testes unitrios so os responsveis por testar componentes individuais de um sistema. Trazendo isso para o paradigma da orientao a objetos, testes unitrios ficam encarregados de testar os mtodos das classes. Testes unitrios so escritos pelos prprios programadores, como afirma Beck (1999). Sommerville (2006) coloca ainda que testes unitrios podem ser direcionados para componentes, mesmo na orientao a objetos, pois estes componentes podem ser formados por vrias classes e possurem 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 so capazes de executar determinadas tarefas e a que entra a interface que ir fazer a comunicao entre as classes internas e com o exterior do componente. Seguindo o exemplo acima, os testes unitrios podem ser escritos para cada uma das classes que compe o componente, testando cada um dos mtodos de cada classe. E tambm podem ser escritos testes que iro verificar o componente atravs de sua interface. Essa abordagem j pode ser considerada como teste de integrao, pois lida com funcionalidades que existem atravs da colaborao de vrias classes. Testes de integrao sero abordados na prxima seo. Voltando para a classe como unidade isolada, Sommerville (2006) coloca trs pontos que precisam ser testados em uma classe: Todos os mtodos associados classe. A atribuio e verificao de todos os atributos da classe. O autor se refere a essas operaes como setting e interrogation, algo bem prximo aos getters e setters usados nas classes para atribuir e resgatar valores de atributos das classes.

52

Simular todas as possveis mudanas de estados de uma classe.

Enquanto os dois primeiros testes de classe so isolados, o ltimo teste (simulao de estados) o mais importante, porque este tipo de teste ir testar vrios mtodos da classe de uma s vez. Ele o teste que mais se aproxima da realidade, porque mtodos de classes geralmente interagem entre si para desempenhar uma funcionalidade e testar os mtodos separadamente importante, mas apenas testando eles de forma integrada possvel saber se a classe realmente entrega as funcionalidades que fornece (SOMMERVILLE, 2006). Atualmente existem muitos frameworks disponveis para a criao de testes de unidade automatizados. Este trabalho ir utilizar o JUnit, um framework em Java que permite a criao de testes unitrios e a execuo automtica dos mesmos. Mais detalhes na seo 2.5.4. 2.3.2.5.3 Teste de Integrao Quando se fala em orientao a objetos outro teste que precisa de estratgias especficas para este paradigma o teste de integrao, ou melhor, os testes de integrao, levando em conta que muitos devem ser conduzidos at a concluso do sistema. Pressman (2006) coloca duas principais estratgias para se desenvolver testes de integrao OO: Teste baseado no caminho de execuo segue mais ou menos a idia de componentes, s que neste caso o teste feito em cima de uma funcionalidade do sistema. Geralmente uma funcionalidade precisa de vrias 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 dependncia em relao 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 integrao 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 grfica esteja construda. E os ltimos podem ser empregados em testes que envolvem a colaborao entre vrias classes e uma ou mais delas ainda no foi construda (PRESSMAN, 2006). Esta pode ser considerada com a ltima etapa de testes onde h distino entre softwares convencionais e softwares que aplicam o paradigma da orientao a objetos. Daqui para frente os testes conduzidos sero focados naquilo que visvel para o usurio, ou seja, o produto final. Comeando pelo teste de validao, visto a seguir. 2.3.2.5.4 Teste de Validao Como foi exposto no pargrafo anterior, o teste de validao independe de se o software foi ou no construdo com orientao a objetos. A validao busca asseverar se o produto, sob o mesmo ponto de vista do usurio, est de acordo com as especificaes definidas nos requisitos do sistema (PRESSMAN, 2006). Para se validar um software preciso criar um plano de testes, neste plano sero definidas as classes de testes que deveram ser conduzidas bem como os casos de testes projetados. Casos de teste tm por objetivo verificar uma funcionalidade do sistema, onde so selecionadas as entradas que sero feitas no sistema e feita a documentao das sadas esperadas. Recomenda-se aqui a automatizao desses testes, principalmente pela economia de tempo (SOMMERVILLE, 2006).

54

Sommerville (2006) faz ainda a diviso 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 (parties) de acordo com as semelhanas e cria testes com entradas e sadas de todas estas parties, e o terceiro busca criar conjuntos de testes que verifiquem todas as funcionalidades do sistema. Os testes baseados em requisitos destacam a importncia de se descrever bem os requisitos do sistema, pois requisitos devem ser testveis. Testes de requisitos, como afirma Sommerville (2006), tem por objetivo validar e no encontrar erros. A diferena que um sistema pode estar livre de erros e ainda assim no satisfazer as necessidades dos clientes, por isso testes baseados em requisitos so importantes. Com tantos meios de se realizar testes e validar o sistema deve haver alguma forma de relatar esses erros. Pressman (2006) faz meno a lista de deficincias, que descreve os desvios de especificao e erros do sistema. Atravs desta lista se daro as negociaes com clientes para a resoluo dos problemas, lembrando que testes de validao geralmente so efetuados aps o desenvolvimento do sistema, o que significa que eventuais correes podem alterar a data de entrega do produto. 2.3.2.5.5 Teste de Sistema Teste de sistema [...] uma srie de diferentes testes cuja finalidade principal exercitar por completo o sistema baseado em computador. (PRESSMAN, 2006, p. 306). Essa srie de diferentes testes pode ser classificada em vrios tipos, de acordo com Pressman (2006), que so: Teste de recuperao so testes que foram o sistema a falhar e avaliam se ele se recuperou corretamente. Tambm feita a medio do tempo de recuperao, sendo que este pode estar dividido em tempo de correo (quando o sistema se recupera sozinho) e reparo (quando se faz necessria a interveno humana para recuperao do sistema).

55

Teste de segurana busca verificar as vulnerabilidades de um sistema atravs de todo e qualquer artifcio e tcnica disponvel para de alguma forma invadir, danificar ou prejudicar o sistema ou seus usurios. Sistemas organizacionais, por exemplo, podem conter informaes valiosas que no devem cair nas mos de concorrentes, com instituies bancrias as informaes so mais sensveis ainda. Ataques com inteno de derrubar um sistema podem causar prejuzos enormes a cada hora em que permanecem fora do ar. Enfim, o nvel de segurana de um sistema depende de muito da situao, mas como Pressman (2006, p. 306) afirma, a questo [...] tornar o custo da invaso maior do que o valor da informao que ser obtida.

Teste de estresse tenta colocar o sistema sob condies extremas para verificar at onde ele consegue agentar. Esse tipo de teste diz muito a respeito da escalabilidade do sistema e pode ser exemplificado com algo como: hoje o sistema tem em mdia 10 operaes por minuto, mas ser que quando houver 1000 operaes por minuto ele ir agentar?.

Teste de desempenho verificam o desempenho do sistema em tempo de execuo. Vrias variveis 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 Depurao Segundo Pressman (2006), o resultado de testes bem sucedidos a depurao 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 no 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 ento corrigir o erro.

56

Para corrigir o erro Pressman (2006) coloca trs estratgias: Fora bruta: pode ser considerado o ltimo recurso para se corrigir um erro, quando nada mais funcionou. Como o prprio nome insinua, trata-se de testar tudo o que for possvel at encontrar o erro ou perder considervel tempo e desistir. Rastreamento: partir da fonte do sintoma e ir percorrendo os possveis caminhos que levam ao erro atravs do cdigo fonte. O autor adverte que medida que o programa vai crescendo tambm cresce a dificuldade de se rastrear erros. Eliminao da causa: os dados relacionados aos sintomas so organizados e uma lista de causas potenciais feita. Hipteses podem ser desenvolvidas e atravs dos dados conhecidos pode ser possvel aceitar ou refutar a hiptese. Casos de teste tambm so conduzidos para verificar se a hiptese ou no verdadeira. Aliado a estas estratgias esto ferramentas que podem auxiliar na descoberta das causas dos erros. Alguns ambientes integrados de desenvolvimento (IDE Integrated Development Environment), por exemplo, fornecem ferramentas para correo de erros de sintaxe no cdigo e debuggers que permitem ao desenvolvedor percorrer o cdigo passo a passo at o momento em que o erro ocorreu. Pressman (2006) tambm ressalta os cuidados que devem ser tomados ao se efetuar a correo do cdigo defeituoso. O primeiro cuidado diz respeito lgica utilizada no trecho defeituoso, eventualmente o erro pode ter ocorrido devido a uma interpretao errada e preciso verificar se esse erro de lgica no foi introduzido em outras partes do cdigo. O segundo cuidado que deve ser tomado com relao aos erros que podem ser desencadeados com a correo do erro original. E o terceiro cuidado, ou conselho,

57

a importncia de se identificar as atitudes que poderiam ter sido tomadas para evitar a ocorrncia do erro, e no somente no projeto em questo, mas em qualquer outro projeto futuro (PRESSMAN, 2006). Esse ltimo cuidado lembra muito o sistema de produo da Toyota devido nfase dada aos erros na produo. Quando um erro ocorre, a produo deve imediatamente parar, assim todos tomam conhecimento do erro e assim aprendem com o mesmo e tem grandes chances de no repeti-lo. Obviamente no cabe aqui falar das questes culturais com relao a cometer erros no Japo, mas a idia bsica interessante e pode ter aplicao em projetos de software. 2.3.2.6 Manuteno A capacidade de um software receber modificaes conhecida como manutenibilidade. O que segundo a ISO/IEC 9126-1 (2003, p.10) podem incluir correes, melhorias ou adaptaes do software devido a mudanas no ambiente e nos seus requisitos ou especificaes funcionais. Pressman (2006) coloca vrios aspectos que podem (e provavelmente iro) dificultar a manuteno de sistemas: Softwares antigos utilizavam tcnicas e metodologias de engenharia de software e codificao que hoje no se aplicam mais, isso quando utilizavam alguma metodologia. As tecnologias da poca atendiam a demandas que hoje j foram substitudas por novas demandas. O uso de tecnologias antigas pode vir a dificultar a manuteno de um sistema. A falta de boa documentao dificulta a compreenso do sistema, consequentemente dificultando a manuteno do mesmo.

58

Esses problemas citados no deixam dvidas sobre a importncia 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 no fica restrita a um punhado de tcnicas especficas, mas sim ao uso da engenharia como um todo. Desde o levantamento correto dos requisitos (e posterior documentao detalhada dos mesmos); a anlise e projeto, provendo toda a arquitetura do sistema atravs de diagramas e documentos com descries detalhadas; da correta escolha das ferramentas que sero utilizadas, levando em conta todos os aspectos das mesmas, inclusive a documentao disponvel; e do uso das melhores prticas de codificao e testes. 2.3.3 Qualidade de Software Pressman (2006, p.578) traz uma definio de qualidade do American Heritage Dictionary que diz que a qualidade uma caracterstica 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 noes de qualidade na manufatura dizem que um produto deve atender as especificaes. Entretanto, se tratando de software pode haver alguns problemas, e o autor coloca alguns deles: Para haver qualidade o software deve atender as especificaes dos clientes, entretanto existem as necessidades da organizao que tambm precisam ser atendidas para garantir, por exemplo, a manutenibilidade do software. Dificuldade de especificar certas caractersticas de qualidade de software sem ser ambguo.

59

Mesmo estando em conformidade com as especificaes os usurios podem no consider-lo um produto de boa qualidade se este no atender as suas expectativas.

Este ultimo item condiz muito com a afirmao de Pressman (2006) ao mencionar uma frmula para satisfao do usurio, pois o autor afirma que se o usurio no estiver satisfeito nada mais importa. Atravs deste cenrio, a gesto da qualidade existe para trazer a qualidade ao software. Pressman (2006, p.577) lista o que abrangido pela gesto da qualidade como sendo: Processo de garantia de qualidade de software (Software Quality Assurance SQA). Tarefas especficas de garantia de qualidade e controle de qualidade. Prticas de engenharia de software efetiva. Controle de todos os produtos de trabalho de software e das modificaes feitas neles. Um procedimento para garantir a satisfao de normas de desenvolvimento de software. Mecanismos de medio e relatrio.

Entretanto, Sommerville (2006, p.642) coloca que existe muito mais em gerenciamente de qualidade do que padres e a burocracia associada para garantir que aqueles foram seguidos. O autor favorvel a criao de uma cultura da qualidade, onde cada membro da equipe est comprometido com a qualidade do software e com a criao de novas abordagens para melhorar a qualidade. Outra justificativa para se criar

60

tal cultura pelo fato de haverem caractersticas intangveis dentro de um software (elegncia, 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) no descarta o gerenciamento de qualidade formal, pois em grandes sistemas a documentao sobre a qualidade importante para que seja verificado tudo o que est sendo feito pelos grupos. Enquanto que times menores no precisam se preocupar com tanta documentao, pois no existem tantos problemas na comunicao e essa pode ser mais informal. Ainda assim, a nfase na cultura da qualidade muito importante para garantir a mesma nos softwares. Dentro das organizaes a garantia da qualidade do software fica sob responsabilidade de todos os envolvidos com a produo do software, fazendo parte de um grupo de SQA (Software Quality Assurance). De um lado engenheiros de software ficam responsveis pela aplicao de mtodos e tcnicas adequadas, revises tcnicas e planejamento e execuo de testes. Enquanto isso, um grupo de SQA fica responsvel pelo plano de qualidade do projeto; ajuda na descrio e reviso do processo de software do projeto; faz a reviso dos produtos, bem como sua documentao e conduo e documentao de desvios; e relata inconformidades no projeto gerncia (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 no manufaturado, mas sim projetado, pois proveniente de um processo criativo, no mecnico. E para Sommerville (2006), fica difcil determinar como as caractersticas do processo afetam os atributos do software, e principalmente como as mudanas nos processos iro afetar o produto.

61

Em contraposto afirmao 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 influncia da qualidade no processo nos atributos de qualidade interna (qualidade sob o ponto de vista interno, ex.: cdigo 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 usurio).

Fonte: ISO/IEC 9126-1, 2003, p.4.

Figura 11: Qualidade no ciclo de vida. Como o objetivo deste trabalho no est no estudo e uso intensivo de normas e padres de qualidade em software, aqui sero apenas exibidos os atributos de qualidade de software (interna e externa), enquanto que uma descrio mais detalhada dos mesmos pode ser encontrada em ISO/IEC 9126-1 (2003), alm dos modelos de qualidade de Boehm, McCall e Dromey. Retornando a qualidade no processo de software, Sommerville (2006), apesar de suas colocaes, afirma que a qualidade dos processos mostrou significante influncia 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 padres, como para a especificao de requisitos (ver seo 2.3.2.1.1), documentao de cdigo (e.g.,

62

Javadoc (em 2.5.5)), e codificao (ver 2.3.4). Processos de software tambm possuem padres que definem os processos que devem ser seguidos durante o projeto de software (SOMMERVILLE, 2006). Dentre eles, os principais so: ISO 9001 padro aplicado em organizaes preocupadas com a qualidade do processo e que projetam, desenvolvem e mantm produtos. Apesar de no ter sido desenvolvida especificamente para o

desenvolvimento de software, ainda assim ela pode ser usada para a definio de processos de software (SOMMERVILLE, 2006). De acordo com Sommerville (2006), este padro se preocupa com a definio de processos que sero usados pela organizao e com a documentao relacionada aos processos que garante que a organizao est seguindo os processos definidos. O autor ainda afirma que o fato de uma empresa ter ISO 9001 no 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 padro, 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 organizao pode ser classificado em nveis de 1 ao 5. Este modelo define ainda 24 reas de processos importantes para a capacitao e melhoramento de processos. ISO/IEC 15504 um framework para a auto-avaliao da organizao com relao a uma gama de boas prticas para ento melhorar seus processos. Ele se divide em duas dimenses: dimenso de processo, objetivos essenciais do processo que podem ser medidos; dimenso de

63

capacitao de processo, atributos comuns a qualquer processo e que representam as caractersticas necessrias 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 so os atributos de um processo que definem o grau de capacitao do processo (FERREIRA, 2009). Este modelo ainda compatvel com o modelo CMMI e est de acordo com a norma ISO/IEC 15504. A classificao da maturidade de processos comea 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 so solues para problemas, elas no descrevem como a soluo deve ser implementada, mas do uma descrio de como o problema pode ser resolvido, ou melhor, fornecem a base para a criao de uma soluo para um problema. Com essa descrio abstrata da soluo possvel ento utiliza - l em diversos projetos com problemas semelhantes, ficando a implementao a cargo da equipe do projeto (SOMMERVILLE, 2006). Nas prximas sees sero 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 faade define o uso de uma interface unificada para um conjunto de interfaces de um sub-sistema. A principal motivao de se usar um

64

faade a reduo da complexidade do sistema, dividindo-o em sub-sistemas e atravs do faade diminuindo a comunicao e a dependncia entre as partes do sistema. A Figura 12 exemplifica a idia deste design pattern, que a de criar uma interface que simplifique o acesso a um sub-sistema. Utilizando o faade, clientes que precisam ter acesso ao sub-sistema no precisam lidar com as classes de baixo nvel do sub-sistema, to pouco precisam saber a ordem certa de passos para obter um servio daquele sub-sistema, o cliente simplesmente precisa acessar o faade e este se preocupa com os detalhes de mais baixo nvel (GAMMA, et al., 1994).

Fonte: GAMMA, et al., 1994, p.208.

Figura 12: Exemplo do pattern faade. importante relater ainda que a existncia de um faade abstraindo as complicaes de um sub-sistema no impede que clientes acessem as classes deste sub-sistema quando houver necessidade. Vale ressaltar ainda que a menor dependncia entre as partes de um sistema o torna mais portvel, quando se fizer presente a necessidade (GAMMA, et al., 1994). 2.3.4.2 Presentation Model O Presentation Model um design pattern onde a idia 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) contm todo o estado e comportamento da view, entretanto ela no possui controle sobre a renderizao dos componentes visuais da view. A Figura 13 apresenta a estrutura bsica de classes seguindo o pattern apresentado. Neste exemplo a classe Album Window a view, Album o model i.e. quem armazena as informaes, e o Album Presentation Model, o responsvel por fazer a conexo 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 contrrio tambm 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 referncia ao Presentation Model e na outra o Presentation Model faz a referncia a view. 2.3.4.3 MVC (Model-View-Controller) Para Sommerville (2006), o MVC um dos mais bem conhecidos frameworks para desenvolvimento de aplicaes com interface grfica. O fato de uma framework estar aqui se d pelo fato de que ela composta por vrios design patterns. Alm disso, Bergin (2007) faz referncia ao MVC como sendo um pattern ao invs de framework, o

66

que no deixa de estar certo j que o MVC uma idia abstrata e a implementao do mesmo fica a cargo dos desenvolvedores. Basicamente, o MVC consiste em dividir as entradas de dados do usurio, a modelagem do mundo real e as respostas dadas aos usurios em trs camadas distintas. No model persiste a modelagem do mundo real, as regras de negcio; na view est a apresentao dos dados do model para o usurio; e no controller est a responsabilidade de repassar os dados inseridos na view para o model (BURBECK, 1997). 2.3.5 Refactoring (ou refatorao, ou ainda refabricao) Nas palavras de Fowler et al. (1999):
Refatorao o processo de modificar um software sem que isso altere o comportamento externo do cdigo, mas melhore sua estrutura interna. uma maneira disciplinada de limpar o cdigo minimizando as chances de se introduzir erros. Em essncia, quando voc refatora voc est melhorando a estrutura do cdigo depois dele ter sido escrito.

Refatorar importante porque pode tornar o cdigo mais compreensvel e fcil de modificar, algo importante quando se fala em sistemas legados. Refatorar tambm ajuda a melhorar cdigos que foram modificados e foram perdendo qualidade na estrutura e esto se tornando difceis de compreender. Com a refatorao a estrutura do cdigo se mantm com qualidade, e isso ajuda no descobrimento de erros e consequentemente torna o desenvolvimento mais rpido (FOWLER, 1999). Quando no desenvolvimento, a principal tarefa do programador est em adicionar funcionalidades e criar os testes para garantir que estas funcionalidades esto entregando aquilo que elas propuseram. Do outro lado est a refatorao, ela no adiciona funcionalidades tampouco cria novos testes para elas. Entretanto, ela melhora o cdigo e o torna mais fcil de compreender e consequentemente de encontrar erros e de modificar. Entretanto, cabe ao programador avaliar quando vale a pena utilizar a refatorao e quando no. Tambm preciso estar ciente de que algumas vezes

67

modificaes nas interfaces precisaram ser feitas, o que leva a modificao de vrias partes afetadas (FOWLER, 1999). O fato que quando bem utilizada a refatorao pode sim melhorar a qualidade do cdigo produzido e como consequncia pode trazer agilidade no desenvolvimento de software, alm de diminuir a quantidade de erros. 2.4 BANCO DE DADOS Quando se fala em tecnologia da informao no h como no fazer relao com banco de dados. atravs deles que organizaes armazenam os dados de todas as suas operaes. Logo, bancos de dados so ferramentas fundamentais em sistemas de informao, pois so eles que armazenam aquilo que mais tem valor para uma organizao. Enquanto o banco de dados o responsvel pelo armazenamento de dados, existe o sistema gerenciador de banco de dados (SGBD) este sendo o responsvel pela manipulao dos acessos ao banco de dados. Os bancos de dados mais utilizados atualmente so os relacionais, neles os dados esto dispostos em tabelas bidimensionais onde as linhas so os registros e as colunas so os atributos. Alm 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 construo de um sistema slido de informaes ela est dividida em modelagem conceitual e lgica. A conceitual independente de SGBD enquanto que a lgica dependente, e nesta ltima as especificaes mais peculiares aos SGBDs so informadas. Na modelagem lgica, 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 converso de um modelo conceitual para um modelo lgico e do framework Hibernate (ver 2.5.3) as chances de o sistema ser portvel para outros SGBDs muito maior. Entretanto, importante ressaltar que mesmo com o uso de um framework de ORM, algumas vezes queries (consulta informaes) precisam ser personalizadas, tanto para que um conjunto distinto de informaes seja obtido como para tirar maior vantagem de funes especficas 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 avaliao de qual abordagem a melhor: tirar vantagem de funes especficas para ganhar algum tipo de vantagem e perder a portabilidade; ou manter a portabilidade e largar mo 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 possvel interesse do pblico em vista da exploso 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 so compostas por mtodos e atributos. Para Deitel, P. e Deitel, H. (2007) possvel aprender Java de duas maneiras: escrevendo as prprias classes e utilizando bibliotecas de classes (chamadas ainda de APIs). Java atualmente considerada uma linguagem madura. Alm disso, ela uma linguagem de alto nvel, ou seja, o programador no precisa se preocupar com detalhes muito especficos como alocao de memria. Em Java muitos detalhes que poderia

69

causar problemas em outras linguagens aqui so checados para evitar erros de execuo (GOSLING, et al., 2005). Uma das principais caractersticas de Java, muito alardeada por sinal, a portabilidade da linguagem. Isso ocorre porque diferentemente das outras linguagens compiladas, Java no compilado diretamente para cdigo nativo de mquina, mas sim para o que se chama de bytecodes. Esses bytecodes ficam armazenados em arquivos .class e quando um programa Java executado eles so carregados do disco rgido para a memria do computador, feita ento uma verificao dos bytecodes para garantir que eles no estejam violando as restries de segurana de Java, e por fim uma mquina virtual (JVM ou Java Virtual Machine) l esses bytecodes e compila-os em tempo de execuo (JIT ou just-in-time) para linguagem de mquina (DEITEL, P. J.; DEITEL, H. M., 2007). Levando em considerao a forma como programas so executados em Java possvel compreender o fato de muitos programas desenvolvidos na linguagem tomarem muito tempo para iniciar (compilao just-in-time), bem como a quantidade de memria mnima 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 cdigo nativo de mquina programas escritos em Java. Infelizmente o uso do compilador muitas vezes pode no ser to vantajoso. Isso porque a cada nova atualizao do Java o compilador tambm teria de se adaptar, o que muitas vezes leva algum tempo (se ocorrer). Alm disso, o suporte a Swing parcial, ou seja, a aplicao estaria passvel de ter problemas de compatibilidade. Em 2007 a Sun Microsystems liberou todo o cdigo fonte da linguagem sob licena GPL. Atualmente a linguagem se encontra na verso 6 para as plataformas Solaris, Linux, Windows, MAC OS X. Java distribudo de duas formas: pela JDK (Java Development Kit) que voltada para desenvolvedores; e JRE (Java Runtime Environment), que a SDK sem o compilador, cabealhos e outros utilitrios. Alm

70

disso, Java est disponvel em trs verses: Java EE (Enterprise Edition), para servidores; Java ME (Micro Edition), para dispositivos mveis e sistemas embarcados; e Java SE (Standard Edition), que a verso padro para desenvolvimento de aplicativos (JAVA DOC., 2010). Na Figura 14 possvel visualizar as tecnologias e bibliotecas que atualmente compe 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 programao 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 verso 6.9 que roda nas plataformas Windows, Linux, Solaris e Mac OS X e d suporte a vrias linguagens alm de Java, como: PHP, C/C++, Ruby, Javascript. O NetBeans tambm d suporte a modelagem de diagramas UML em forma de um mdulo, alm disso possvel 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 atravs da linguagem Java ou .NET. Ferramentas de ORM dispensam a codificao de cdigos SQL, constroem consultas SQL otimizadas e funcionam independentemente do SGBD utilizado (BAUER; KING, 2005). De acordo com Bauer e King (2005) o Hibernate comeou 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 ento 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 tcnicas utilizadas para a persistncia do banco de dados e afirmam que por enquanto a melhor delas a ORM. Dentre suas qualidades, as principais so: maior produtividade, isso porque o programador no precisa gastar tempo montando SQLs; facilita a manuteno, levando em conta que com um ORM menos cdigo ser escrito e h uma grande chance de se diminuir as chances de se cometer erros; melhor performance, apesar de muitos argumentarem que cdigos escritos a mo pode ser melhor otimizados um ORM

72

tambm realiza otimizaes em todas as interaes com o banco de dados, alm de lidar com as peculiaridades de cada banco de dados; e a independncia de banco de dados, ou seja, com um ORM sua aplicao se torna portvel entre os SGBDs suportados pela ferramenta de persistncia. 2.5.4 JUnit Framework JUnit uma framework para realizao de unidades de teste em Java, foi criada em 1997 por Erich Gamma e Kent Beck. A framework open source e distribuda atravs da licena IBMs Common Public License Version 1.0 e atualmente se encontra na verso 4.8 (TAHCHIEV, et al., 2009). Unidades de teste servem para avaliar o comportamento de uma unidade de trabalho. Essa unidade comumente um mtodo de uma classe, sendo que o teste fica encarregado de fornecer os dados exigidos pelo mtodo e receber o resultado deste mtodo e verificar se a resposta recebida est correta. O autor tambm cita o contrato de API, aonde o mtodo se compromete a fornecer os dados corretos quando forem requisitados seus servios, e uma quebra de contrato poderia ser expressa por uma exception lanada pelo mtodo (TAHCHIEV, et al., 2009). 2.5.5 Javadoc Ferramenta criada pela Sun Microsystems para a gerao de documentao de API em HTML atravs de comentrios inseridos no prprio cdigo fonte. A ferramenta est disponvel juntamente com o Java SDK (Software Development Kit) e atualmente se encontra na verso 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 criao de projetos tanto lgicos como fsicos. 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 gerao de documentao a partir do modelo criado, exportando para HTML, RTF ou PDF. Alm de permitir a exportao do modelo visual para imagem. Entre as maiores vantagens da ferramenta est o suporte aos ltimos recursos disponveis nas mais recentes verses dos SGBDs (QUEST SOFT., 2010). A gerao dos scripts para criao do banco totalmente configurvel. Alm disso, possvel fazer a engenharia reversa diretamente da ferramenta, verificar por erros no modelo de dados criados, sincronizar os modelos com bancos de dados fsicos e fazer o controle de verses de modelos (QUEST SOFT., 2010). 2.5.6 PostgreSQL PostgreSQL um banco de dados relacional open source, foi criado como um projeto acadmico da UC Berkeley pelo professor Michael Stonebraker, em 1986, como continuao do projeto de banco de dados chamado de Ingres. O incio do Postgres se deu com o intuito de provar academicamente a teoria dos bancos de dados objetorelacional. Com o tempo o banco de dados passou a integrar a linguagem SQL para interface de comunicao (BLUM, 2007). O PostgreSQL considerado atualmente o mais poderoso SGBD de cdigo aberto disponvel. Est na verso 8.4 e est disponvel nas plataformas Windows, UNIX e Linux. Tem suporte total a foreign keys, joins, views, triggers e stored procedures (em diversas linguagens). Alm de suportar o armazenamento de imagem, udio e vdeo (POSTGRESQL.ORG, 2010).

74

2.5.7 Enterprise Architect uma ferramenta proprietria de modelagem para UML 2 e SysML com suporte oficial para Windows, e atualmente est na verso 8. Com essa ferramenta possvel desenvolver toda a anlise de um sistema, desde os requisitos at os diagramas da UML e os modelos de dados. A ferramenta oferece ainda integrao com vrias IDEs, dentre elas Eclipse e Visual Studio (SPARX SYS., 2010). Com a ferramenta possvel ainda importar e exportar cdigos para as principais linguagens de programao do mercado. Alm da gerao de documentao atravs de templates customizveis (SPARX SYS., 2010).

75

CAPTULO 3: RESULTADOS Neste captulo encontram-se os resultados obtidos neste projeto desde a fase de levantamento dos requisitos, passando pela anlise e projeto do sistema, testes, at chegar apresentao do sistema como produto de software. 3.1 SITUAO ATUAL DA EMPRESA Este trabalho foi desenvolvido com base em um problema encontrado na Metalrgica Fratelli, localizada em Santa Rosa RS. Fundada em julho de 1986, atualmente trabalha na produo de peas para colheitadeiras, tratores e outros equipamentos no automotivos. O problema em questo diz respeito ao sequenciamento da produo dentro da indstria. Atualmente ele feito atravs de planilhas eletrnicas que controlam o que deve ser feito, quando, onde e que quantidade. O problema que sequenciar a produo atravs das planilhas eletrnicas est comeando a se tornar uma tarefa rdua e a tendncia de ficar cada vez mais difcil levando em conta que novos conjuntos passaro a ser sequenciados atravs destas planilhas. Outro problema envolvendo as planilhas eletrnicas que elas, com o tempo, se tornam muito pesadas devido grande quantidade de dados nelas armazenados, o que as torna inutilizveis dentro de meses.

76

3.2 ESPECIFICAO DOS REQUISITOS DO SISTEMA O levantamento dos requisitos ocorreu atravs de entrevistas com os interessados e envolvidos na atual soluo de sequenciamento utilizada dentro da metalrgica. Ao menos trs reunies foram feitas para que a definio dos requisitos estivesse clara o suficiente para que o software pudesse passar para a modelagem. A importncia de discutir com os usurios sobre o problema a ser solucionado de fundamental importncia para que se compreenda o que de fato o usurio deseja, e o que realmente ele precisa que o software faa para ele. Neste projeto foi possvel notar com clareza a evoluo das especificaes do software que comearam apenas com um esboo vago daquilo que o usurio realmente desejava. E a cada nova visita aos usurios, os requisitos foram sendo melhor trabalhados e comearam a se aproximar mais da real soluo de seus problemas com relao ao sequenciamento da produo dentro da metalrgica. Isso mostra a importncia da comunicao com os usurios e do constante feedback a respeito das evolues na descrio dos requisitos. Outro aspecto importante de ser ressaltado a forma como os requisitos sero descritos em um primeiro momento. Enquanto no existir uma boa compreenso a respeito do problema dos usurios, a descrio dos requisitos deve permanecer breve e clara. A especificao detalhada dos requisitos s deve ser feita quando o problema foi bem compreendido e o cliente est de acordo com as especificaes. O documento de especificao dos requisitos encontra-se no Apndice A deste relatrio, especificamente na seo 3 do documento. 3.2.1 Domnio do Problema Como foi exposto na seo 3.1, o problema principal da empresa com relao ao sequenciamento da produo est relacionado com a ferramenta atualmente

77

utilizada para desempenhar esta tarefa. As planilhas eletrnicas utilizadas atualmente, apesar de terem conseguido desempenhar seus papis, no so uma soluo escalvel. Ou seja, essa soluo no capaz de crescer juntamente com a quantidade de conjuntos envolvidos no sequenciamento, pois quanto mais conjuntos so adicionados, mais demorado fica para abrir as planilhas e mais tempo se leva para sequenciar as ordens de produo. Simplificando as especificaes do sistema do Apndice A, a metalrgica possui clulas de trabalho, tambm chamadas de operaes, so por estes locais que a matria prima passa para se tornar um componente. Componentes formam conjuntos, e estes tambm passam por clulas de trabalho para que venham a formar um conjunto acabado. Tanto componentes como conjuntos precisam de um determinado perodo de tempo em cada uma das clulas de trabalho para serem transformados. Esse tempo pode tambm ser chamado de lead time. Quando uma ordem de produo recebida ela possui uma data de entrega, a identificao do conjunto que deve ser produzido e a respectiva quantidade dele. Agora, para saber quando os componentes do conjunto devem comear a ser produzidos preciso saber o lead time para a produo 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 operaes do conjunto. Com essas informaes possvel afirmar o dia em que o conjunto dever comear a ser produzido, bem como informar o dia em que cada um dos componentes dever passar pelas clulas de trabalho, bem como o prprio conjunto. Para uma melhor compreenso de como funciona o sequenciamento da produo, verificar o Apndice B, seo 8.1. Os dados do sequenciamento so expostos em planilhas eletrnicas com as colunas indicando os dias e as linhas indicando os componentes a serem produzidos. Cada clula de trabalho tem seu sequenciamento individual, alm do sequenciamento

78

mestre que exibe o dia em que a produo dos componentes dever comear. Estas planilhas tm dois propsitos, alm do controle da produo, so eles: informar os clientes sobre o andamento de seus pedidos e servir de guia para os trabalhadores do cho de fbrica. 3.2.2 Resultados Esperados Nas sees anteriores foi possvel tomar um bom conhecimento dos problemas enfrentados pela metalrgica no sequenciamento de sua produo e a importncia que o sequenciamento tem para eles. De fato, a aplicao do sequenciamento da produo atravs das planilhas eletrnicas trouxe muitos benefcios a metalrgica, sendo o principal deles a diminuio do tempo necessrio para se atender um pedido. O objetivo principal deste trabalho foi o de automatizar boa parte das atividades relacionadas ao sequenciamento de produo, reduzindo ao mximo o esforo necessrio para a obteno dos mesmos resultados, as planilhas eletrnicas com o sequenciamento da produo. Isto exatamente o que o software faz, ele diminui o esforo necessrio para o sequenciamento da produo da metalrgica atravs da automatizao de

determinadas tarefas, como o sequenciamento da produo, principal tarefa do sistema. Alm disso, com o sistema possvel controlar os clientes, componentes, conjuntos e ordens de produo armazenados no sistema. Uma detalhada descrio de todas as funcionalidades do sistema pode ser encontrada no Apndice E, o manual do usurio. 3.2.3 Impacto do Sistema na Empresa At o momento da finalizao do relatrio o software no havia sido apresentado aos interessados da metalrgica. Portanto, no possvel precisar o

79

impacto do sistema na empresa, visto que no h a aprovao do software com relao s expectativas dos usurios. Entretanto, possvel especular que se e somente se o software estiver de acordo com as expectativas dos usurios, com certeza ele vir a melhorar a tarefa de sequenciamento de produo, facilitando a tarefa e permitindo aos usurios o uso de seu tempo em tarefas que venham a agregar mais valor a metalrgica, deixando a criao das planilhas eletrnicas a cargo do software. 3.3 ANLISE E PROJETO DO SISTEMA A anlise e projeto do sistema foram desenvolvidos com base no documento de especificao dos requisitos do sistema (Apndice A). Estas duas fases deste projeto deram origem a um segundo artefato, o Documento de Arquitetura (Apndice B). Este documento tem por objetivo a descrio da estrutura que serviu de base para o desenvolvimento do sistema, bem como a ilustrao do seu comportamento. 3.3.1 Casos de Uso Como parte da anlise do software, foram construdos 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 descrio de cada um deles, esto no Apndice A, na seo 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 produo. Este diagrama pode ser encontrado no Apndice B, na seo 8.1.

80

3.3.3 Diagramas de Classes Os diagramas de classe criados para este sistema tambm se encontram no Documento de Arquitetura (Apndice B), na seo 7. Estes diagramas serviram de base para a criao da aplicao durante a fase de desenvolvimento do sistema. 3.3.4 Modelo Entidade Relacionamento O modelo de entidades-relacionamentos segue as especificaes definidas na Especificao dos Requisitos do Sistema, bem como os diagramas de classe do Documento de Arquitetura. O MER pode ser visualizado no Apndice F. 3.4 DESCRIO DO DESENVOLVIMENTO Com a fase de anlise e projeto do sistema em estgio final, o desenvolvimento pode tomar incio, comeando pela gerao das classes do sistema a partir dos diagramas criados no projeto do sistema. A primeira etapa do desenvolvimento foi a montagem da estrutura bsica de pacotes e classes do sistema, com base nos diagramas fornecidos pelo Documento de Arquitetura (Apndice B). Com a estrutura base da aplicao pronta, iniciou-se o mapeamento do banco de dados criado a partir do modelo ER atravs da ferramenta Hibernate. Todo o mapeamento foi feito utilizando arquivos XML, tambm utilizou-se de XML para a criao das regras de validao com a ferramenta Hibernate Validator. Com o mapeamento completo, passou-se ento a implementao dos mtodos das classes do sistema. A abordagem adotada para o desenvolvimento foi a de completar um mdulo por vez, implementando todas as camadas do mdulo de uma vez e ento partindo para o prximo mdulo do sistema. O desenvolvimento tambm fez o uso intensivo de testes unitrios, sendo estes escritos para todas as classes com mtodos relevantes o suficiente para necessitarem de testes. Para cada mtodo criado, um teste unitrio

81

tambm foi criado, e este mtodo 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 modificaes efetuadas no sistema no haviam afetados outras partes do sistema, alm de verificar se a integrao do sistema estava sendo bem sucedida. Alm da realizao de testes unitrios, testes de integrao entre classes foram conduzidos durante o desenvolvimento do sistema. Tanto os testes unitrios como os de integrao fizeram uso da ferramenta JUnit, ferramenta esta que facilitou a execuo dos testes, bem como a criao de relatrios. O relatrio dos testes unitrios pode ser encontrado na seo 3.1 do Apndice D. Outra prtica adotada durante o desenvolvimento do sistema foi o uso da ferramenta Javadoc para documentao das classes e respectivos mtodos. Esta ferramenta permite a criao de detalhada descrio de classes e mtodos, informando dentre vrias informaes os parmetros de entrada, varivel de retorno, verso da classe, data de criao, autor da classe, etc. Este tipo de documentao conhecido como documentao de API, pois gera rica documentao a respeito das funcionalidades fornecidas pelas classes, permitindo que outras pessoas compreendam o propsito de cada classe e as funes que ela prov. Ao final do desenvolvimento do sistema, outra prtica foi aplicada, desta vez a prtica do refactoring, ela foi aplicada em partes crticas do cdigo que demandavam maior desempenho e principalmente clareza de cdigo para melhorar a compreenso de quem vir a l-lo. 3.5 TESTES DO SISTEMA Alm dos testes unitrios, 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 Apndice C. Com base nos casos de teste foram criados os testes automatizados para o sistema utilizando a ferramenta IBM Rational Functional Tester. O relatrio dos testes funcionais pode ser encontrado na seo 3.2 do Apndice D. 3.6 MANUTENO DO SISTEMA Como foi colocado no Captulo 2, a manutenibilidade de um software dada pela capacidade deste software receber modificaes, podendo ser uma correo, melhoria ou adaptao. E para que isso seja possvel o cdigo fonte do software precisa estar bem escrito e documentado. Este projeto fez uso de algumas prticas durante o desenvolvimento do software para garantir um cdigo melhor escrito e bem documentado. Estas prticas foram descritas na seo 3.5, sendo elas: documentao de API e refactoring. Estas prticas possibilitaram a criao de cdigos mais simples e com detalhada descrio de cada parte do cdigo. Aliado a estas prticas est o Documento de Arquitetura (Apndice B), este responsvel pela descrio de toda arquitetura que serviu de base para o desenvolvimento do software. Isso significa que qualquer pessoa que deseje compreender a estrutura bsica do software pode encontrar informaes suficientes neste documento. Outra forma de compreender melhor a estrutura do sistema seria atravs de engenharia reversa. Vrias ferramentas de modelagem UML fornecem essa funcionalidade de importar um sistema para dentro do modelador, e este ento transforma o cdigo importando em diagramas de classes, com suas relaes, mtodos e atributos.

83

Outro ponto importante da manuteno de um software a atualizao da documentao, neste caso, o Documento de Arquitetura. Este deve ser atualizado a cada modificao efetuada na estrutura do sistema. Alm deste documento, todos os outros documentos devem ser atualizados quando novas funcionalidades forem introduzidas.

CONCLUSO Uma das premissas mais bsicas ao se conceber um software o de que ele ir suprir uma necessidade de um determinado pblico. Mas apenas construir um software que atenda a essas necessidades no suficiente para criar uma demanda pelo software. Ento o que seria capaz de criar tal demanda? Antes de responder a esta questo, importante lembrar que um software apenas um meio para atingir um objetivo, ele automatiza processos, os torna mais eficientes e mais eficazes. Poderia ento a aquisio de um software trazer benefcios a uma organizao? A verdade que isso depende de cada organizao, e de como esto estruturados os seus processos. Como poder uma empresa sentir uma necessidade se ela nem ao menos possui profissionais capazes de identificar tais deficincias? Mesmo o software que siga rigorosamente as especificaes de requisitos poder ser insatisfatrio para a organizao, no necessariamente porque o software foi mal planejado, mas porque a organizao pode estar tendo dificuldades de se adaptar aos novos processos, principalmente quando no se possua nenhum at o momento. Um novo sistema vai muito alm de um programa de computador, sua implantao requer disciplina e cooperao dentro da organizao para que ele venha a trazer benefcios a esta.

Durante a execuo deste projeto foi possvel perceber que a insero de uma maneira nova de se fazer as coisas em uma indstria pode levar algum tempo. E foi isso que levantou a questo da relevncia de se adquirir um software. mais do que evidente a importncia de pessoas capazes de mobilizar uma organizao para modificar um processo. Portanto, o sucesso de um software est intrinsecamente relacionado a capacidade de a organizao adotar novos processos. Na empresa onde este projeto foi realizado os processos para o

sequenciamento da produo j estavam sendo aplicados. E foi atravs de metodologias e boas prticas de Engenharia de Software que as especificaes do software foram descritas visando o mximo de acurcia com relao a estes processos. Tendo o software seguido rigorosamente estas especificaes e tendo elas sido testadas atravs de testes de funcionalidades possvel afirmar que o software atende as necessidades dos usurios, provendo uma ferramenta capaz de fornecer uma soluo que torna o sequenciamento da produo mais rpido do que a soluo atualmente empregada ao mesmo tempo em que prov resultados de igual acurcia com relao aos obtidos atravs dos mtodos atualmente utilizados na empresa. Alm do alinhamento do software desenvolvido com relao as especificaes obtidas, a satisfao do usurio tambm est relacionada com a confiabilidade do software. Para tanto, durante o desenvolvimento do software, testes unitrios foram criados para as classes mais relevantes do sistema. Entretanto, no foi possvel comprovar que testes unitrios diminuem a ocorrncia de erros, pois para comprovar tal afirmao seria preciso ter um histrico de erros em outros projetos onde testes unitrios no foram aplicados. Ainda assim, todas as prticas e mtodos aplicados neste projeto vieram de alguma forma a beneficiar o produto final, assegurando maior confiabilidade ao

86

software, o que foi comprovado atravs dos resultados dos testes unitrios e de funcionalidades. Um dos grandes desafios na modelagem do software foi a de abstrair todas as regras de negcios dos requisitos captados e construir uma especificao mais generalista, mas que conseguisse atender as peculiaridades da metalrgica sem, entretanto, engessar a aplicao s regras especficas do negcio. Portanto, a utilizao de metodologias de Engenharia de Software possibilitam a melhor compreenso do problema a ser resolvido, bem como fornecem meios de garantir a qualidade do software e de manter uma documentao capaz de auxiliar na compreenso do funcionamento do software. Tambm possvel concluir que a implantao de um software dentro de uma organizao vai muito alm da aquisio do software. A organizao precisa de maturidade e de pessoas que sejam capazes de provocar a mudana dentro da organizao, para que um software possa de fato trazer benefcios a ela.

REFERNCIAS

ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. 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. Disponvel 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 Edio. Addison-Wesley, 2005. BURBECK, Steve. Applications Programming in Smalltalk-80: How to use ModelView-Controller (MVC). The University of Illinois at Urbana-Champaign Smalltalk

88

Archive, 04 Mar. 1997. Disponvel em: <http://st-www.cs.illinois.edu/users/smarch/stdocs/mvc.html>. DATE, Chris J. An Introduction to Database Systems 8 Edio. Pearson, 2004. DAVIS, Mark M.; AQUILANO, Nicholas J.; CHASE, Richard B. Fundamentos da Administrao da Produo 3 Edio. Porto Alegre: Artmed, 2001. DEITEL, P. J.; DEITEL, H. M. Java: How To Program 7 Edio. New Jersey: Pearson, 2007. FERREIRA, Wilker Felix. MPS.BR: Um Estudo do Modelo MPS.BR como Benefcio para as Pequenas e Mdias Empresas. Universidade Estadual de Gois, 2009. FOWLER, Martin. Presentation Model. Divulgado em: 19 Jul 2004. Disponvel 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 Edio. Addison-Wesley, 2005. Java Documentation. Disponvel 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. Tcnicas de pesquisa 6 Edio. So Paulo: Atlas, 2006.

89

NetBeans Official Website. Disponvel em: <http://netbeans.org/>. Acesso em: 01 ago. 2010. OLIVEIRA, S. L. Tratado de Metodologia Cientfica: projetos de pesquisas, TGI, TCC, monografias, dissertaes e teses 2 Edio. So 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. Disponvel em:

<http://www.postgresql.org/>. Acesso em: 02 ago. 2010. PRESSMAN, Roger. Engenharia de Software 6 Edio. McGraw-Hill, 2006. Quest Software. Toad Data Modeler. Disponvel em: <http://www.quest.com/toad-datamodeler/>. Acesso em: 04 ago. 2010. SOMMERVILLE, Ian. Software Engineering 8 Edio. Addison-Wesley, 2006. Sparx Systems. Enterprise Architect. Disponvel em:

<http://www.sparxsystems.com.au/>. Acesso em: 04 ago. 2010. TABORDA, Loana Wollmann. Sequenciamento da Produo em Indstria MetalMecnica. Trs de Maio: SETREM, 2008. TAHCHIEV, Petar; LEME, Felipe; MASSOL, Vincent; GREGORY, Gary. JUnit in Action 2 Edio. Greenwich: Manning, 2009. YEATES, Donald; WAKEFIELD, Tony. Systems Analysis and Design 2 Edio. Harlow: Pearson, 2004.

APNDICES

APNDICE A: Especificao dos Requisitos do Sistema APNDICE B: Documento de Arquitetura APNDICE C: Plano de Testes APNDICE D: Relatrio de Testes APNDICE E: Manual do Usurio APNDICE F: Modelo Entidades-Relacionamentos

APNDICE A ESPECIFICAO DOS REQUISITOS DO SISTEMA

APNDICE B DOCUMENTO DE ARQUITETURA

APNDICE C PLANO DE TESTE

APNDICE D RELATRIO DE TESTES

APNDICE E MANUAL DO USURIO

96

APNDICE F MODELO ENTIDADES-RELACIONAMENTOS