SONI JOÃO DA SILVA
REENGENHARIA DO SISTEMA DE GERENCIAMENTO DE PATRIMÔNIO DO TRIBUNAL REGIONAL DO TRABALHO DE SANTA CATARINA
Palhoça 2010
REENGENHARIA DO SISTEMA DE GERENCIAMENTO DE PATRIMÔNIO DO TRIBUNAL REGIONAL DO TRABALHO DE SANTA CATARINA
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Ciência da Computação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharelado em Ciência da Computação.
Prof. e orientador: Osmar de Oliveira Braz Júnior, Msc. Eng. Prof. e co-orientador: Ricardo Villarroel Dávalos, Dr. Eng.
Palhoça 2010
REENGENHARIA DO SISTEMA DE GERENCIAMENTO DE PATRIMÔNIO DO TRIBUNAL REGIONAL DO TRABALHO DE SANTA CATARINA
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título Bacharelado em Ciência da Computação e aprovado em sua forma final pelo Curso de Graduação em Ciência da Computação da Universidade do Sul de Santa Catarina.
Palhoça, 15 de junho de 2010.
______________________________________________________ Prof. e orientador: Osmar de Oliveira Braz Júnior, Msc. Eng.
Universidade do Sul de Santa Catarina
______________________________________________________ Prof. Vera Rejane Niedersberg Schuhmacher, Msc.
Universidade do Sul de Santa Catarina
______________________________________________________ Antonio Manoel da Silva
Ao meu pai em memória e minha mãe pela educação, caráter e incentivo na busca de um ideal. A minha esposa e filhos pela paciência e compreensão nos momentos de ausência familiar.
Agradeço a Deus pela saúde e força de vontade ao longo desta caminhada.
À minha esposa Sônia companheira de todas as horas, que em muitos momentos realizou seus afazeres e os meus, para que eu me dedicasse integralmente a esta empreitada.
Aos meus filhos: Vânio e Fabrício que no decorrer destes anos de dedicação aos estudos na graduação, de crianças se tornaram homens, pela compreensão dos momentos que não podemos compartilhar juntos.
Ao Mestre e amigo, professor Osmar de Oliveira Braz Junior orientador, pela condução, apoio no trabalho e pelo conhecimento adquirido nas disciplinas ministradas no decorrer do curso, que foram o alicerce para o nosso aprendizado bem como do trabalho aqui documentado.
À professora Vera Rejane Niedersberg Schuhmacher pelos ensinamentos, estímulo e apoio nessa trajetória.
Ao professor Ivo Zimmermann pela colaboração na correção ortográfica e gramatical que foi de fundamental importância na valorização desta obra.
Ao professor Co-orientador: Dr. Eng. Ricardo Villarroel Dávalos pela colaboração. A todos os professores que tiveram sua parcela na construção da nossa formação acadêmica.
Aos familiares e amigos de modo geral pela compreensão e apoio.
Aos funcionários do Tribunal Regional do Trabalho de Santa Cataria, da Secretaria de Informática do Serviço de Desenvolvimento de Sistema, Gustavo Bestetti Ibarra pelo apoio e ajuda na opção do tema e o fornecimento das informações prestadas. A Glademir Maria Silveira Sartori por acreditar e confiar às informações sobre o sistema atual, essenciais e indispensáveis para a engenharia reversa. Do Setor de Cadastro e Administração de Bens principalmente ao Antonio Manoel da Silva pela ajuda na compreensão das telas do sistema atual e do Almoxarifado pelos esclarecimentos sobre a rotina de trabalho envolvendo o sistema. Aos colegas do nosso Setor de Gráfica pelo apoio, em especial a Alexandre Zaia pela compreensão e estímulo.
“... você tem dois pés para cruzar a ponte...” (Raul Seixas / Marcelo Motta / Paulo Coelho).
RESUMO
O desenvolvimento de um sistema de software, robusto, de qualidade é caro, entretanto, em sistemas legados, que, com o passar dos anos, acabam obsoletos, seja devido a mudanças tecnológicas, ao surgimento de alguma implementação que a metodologia de desenvolvimento encontra-se ultrapassada ou à linguagem de programação que ficou obsoleta, a reengenharia desse sistema tem vantagens sobre a construção de um novo, partindo do zero, por diminuir custos e riscos devido a erros e tempo de desenvolvimento, uma vez que irá buscar os requisitos no sistema existente. A utilização do processo de desenvolvimento, IBM
Rational Unified Process (IBM RUP) customizado as necessidades do sistema, veio a agregar
valores à obra por conduzir esse processo de forma iterativa e incremental, documentando o processo de desenvolvimento do sistema.
ABSTRACT
The development of a software system, robust, of quality is expensive, however, in legacy systems, which over the years, eventually are obsolete, either due to technological change, the rise of another implementation where the development methodology is exceeded by it or if the programming language has become obsolete, the reengineering of this system has advantages over building of a new one from scratch, by reducing costs and risks due to errors and development time, as it will pick up the system requirements of existent system. The use of the development process, IBM Rational Unified Process (RUP IBM) customized to the needs of the system, came to add value to work for leading this process of iterative and incremental way, documenting the process of system development.
LISTA DE ILUSTRAÇÕES
Figura 1 – Consulta ao sistema atual. ... 17
Figura 2 – Eolípila. ... 23
Figura 3 – Reengenharia na construção civil... 24
Figura 4 – Usuários de um documento de requisitos. ... 31
Figura 5 – Modelo em cascata... 37
Figura 6 – Prototipação. ... 38
Figura 7 – Modelo espiral... 39
Figura 8 – Modelo iterativo e incremental. ... 40
Figura 9 – Método Fusion. ... 42
Figura 10 – Rational Unified Process... 45
Figura 11 – Engenharia Avante x Engenharia Reversa... 49
Figura 12 – Etapas metodológicas... 53
Figura 13 – Sistema atual. ... 54
Figura 14 – Sistema proposto. ... 55
Figura 15 – Workflow Gerenciamento de Projeto... 59
Figura 16 – Workflow Requisitos. ... 60
Figura 17 – Workflow Refinamento do Plano de Desenvolvimento... 60
Figura 18 – Workflow Análise e Design. ... 62
Figura 19 – Workflow Ambiente... 62
Figura 20 – Workflow Implementação... 63
Figura 21 – Workflow Teste... 64
Figura 22 – Workflow Produto de Teste Beta... 65
Figura 23 – Workflow Finalizar Projeto... 66
Figura 24 – Ambiente tecnológico. ... 66
Figura 25 – Tela Inicial. ... 68
Figura 26 – Tela Inserir Patrimônio. ... 69
Figura 27 – Tela Consultar Itens da Nota de Empenho... 70
LISTA DE TABELAS
Tabela 1 – Workflows Estáticos no Rational Unified Process... 44 Tabela 2 – Testes realizados no protótipo... 72
LISTA DE SIGLAS
ASP – Active Server Pages EA – Enterprise Architect
CASE – Computer-Aided Software Engineering
DBA – Database Administrator (Administrador do Banco de Dados) ODBC – Open Data Base Connectivity
PDF – Portable Document Format IBM RUP – Rational Unified Process
SCAB – Setor de Cadastro e Administração de Bens SEDES – Serviço de Desenvolvimento de Sistema SEINFO – Secretaria de Informática
SEMAP – Serviço de Material e Patrimônio SGBD – Sistema Gerenciador de Banco de Dados
SIAFI – Sistema Integrado de Administração Financeira do Governo Federal SRS – Software Requirements Specification
TRT/SC – Tribunal Regional do Trabalho de Santa Catarina UML – Unified Modeling Language
VT – Vara do trabalho (unidades de primeira instância da Justiça do Trabalho) WEB – World Wide Web
1 INTRODUÇÃO...15 1.1 PROBLEMÁTICA ...16 1.2 OBJETIVOS ...19 1.2.1 Objetivo Geral...19 1.2.2 Objetivos Específicos ...19 1.3 JUSTIFICATIVA ...19 1.4 ESTRUTURADAMONOGRAFIA ...20 2 REVISÃO BIBLIOGRÁFICA ...22 2.1 ENGENHARIA ...22 2.1.1 Engenharia de Software ...24 2.1.1.1 Engenharia de Sistemas ...26 2.2 PROCESSODESOFTWARE...27
2.2.1 Atividades do processo de desenvolvimento ...28
2.2.1.1 Levantamento de Requisitos ...29 2.2.1.2 Análise de Requisitos...32 2.2.1.3 Projeto ...33 2.2.1.4 Implementação...35 2.2.1.5 Testes ...35 2.2.1.6 Implantação...36
2.3 MODELODEPROCESSODESOFTWARE...36
2.3.1.1 Modelo em Cascata...36
2.3.1.2 Prototipação ...37
2.3.1.3 Modelo Espiral...38
2.3.1.4 Modelo Iterativo e Incremental...39
2.3.1.5 Método Fusion ...41
2.3.1.6 Rational Unified Process...42
2.4 PROCESSODEDESENVOLVIMENTODAREENGENHARIA ...45
2.4.1 Reengenharia de Software ...46
2.4.1.1 Avaliação da Reengenharia...49
2.5 CONCLUSÕESDOCAPÍTULO ...50
3 MÉTODO ...51
3.1 CARACTERIZAÇÃODOTIPODEPESQUISA...51
3.3 PROPOSTADASOLUÇÃO...53
3.4 DELIMITAÇÕES ...55
3.5 CONCLUSÕESDOCAPÍTULO ...56
4 PROCESSO DE DESENVOLVIMENTO ...57
4.1 CUSTOMIZAÇÃODOIBMRUP ...57
4.1.1 Concepção...58 4.1.1.1 Gerenciamento de Projeto...58 4.1.1.2 Requisitos...59 4.1.2 Elaboração...60 4.1.2.1 Gerenciamento de Projeto...60 4.1.2.2 Requisitos...61 4.1.2.3 Análise e Design ...61 4.1.2.4 Ambiente...62 4.1.3 Construção...63 4.1.3.1 Implementação...63 4.1.3.2 Testes ...64 4.1.4 Transição ...64 4.1.4.1 Implantação...65 4.1.4.2 Gerenciamento de Projeto...65 4.2 AMBIENTEDEDESENVOLVIMENTO ...66 4.3 IMPLEMENTAÇÃODOSISTEMA ...68 4.4 CONCLUSÕESDOCAPÍTULO ...71 5 TESTE E VALIDACÃO ...72 5.1 TESTE ...72 5.2 VALIDAÇÃO...73 6 CONCLUSÕES E RECOMENDAÇÕES...74 6.1 CONCLUSÕES ...74 6.2 RECOMENDAÇÕES ...75 REFERÊNCIAS ...76 APÊNDICES...78 APÊNDICE A – VISÃO ...79 APÊNDICE B – GLOSSÁRIO...91
APÊNDICE C – LISTA DE RISCOS...98
APÊNDICE D – PLANO DE DESENVOLVIMENTO DE SOFTWARE...103
APÊNDICE E – PLANO DE ITERAÇÃO ...110
APÊNDICE F – ESPECIFICAÇÃO DE REQUISITOS DE SOFTWARE...116
APÊNDICE H – ESPECIFICAÇÃO DE CASOS DE USO PRIMÁRIOS ...131
APÊNDICE I – DOCUMENTO DE ARQUITETURA DE SOFTWARE...187
APÊNDICE J – GUIA DE DESIGN DO SISTEMA ATUAL...198
APÊNDICE K – GUIA DE DESIGN DO SISTEMA PROPOSTO...207
APÊNDICE L – ESPECIFICAÇÃO DA REALIZAÇÃO DE CASOS DE USO ...223
APÊNDICE M - GUIA DE TESTE ...286
1 INTRODUÇÃO
Com a globalização, as empresas buscam formas de redução de custos, para manterem-se competitivas e atraentes no mercado, empregam tecnologia de ponta na fabricação de produtos, investem em sistemas que automatizam a produção e a logística, minimizando custos.
No passado, o serviço público era sinônimo de cabide de emprego, hoje, felizmente, mudanças significativas são visíveis nesse contexto. O setor público sente a necessidade de modernizar-se, enxugando a máquina administrativa e reduzindo custos, para dar um atendimento digno de qualidade ao contribuinte.
O Tribunal Regional do Trabalho de Santa Catarina (TRT/SC), criado em 1981, é um órgão especializado da Justiça do Trabalho de segunda instância e sua principal função consiste em mediar conflitos entre empregados e empregadores.
O TRT/SC conta, atualmente, com cinquenta e seis varas trabalhistas, que são as unidades de primeira instância no Estado de Santa Catarina.
Segundo BRASIL (2009A) (a Corregedoria (2009)), no período de janeiro a novembro de 2009, a Justiça do Trabalho de Santa Catarina recebeu 59.368 processos em suas unidades judiciárias de primeira instância, em que 59.269 desses processos foram solucionados, outros estão em trâmite ou foram remetidos para a segunda instância.
Desde a sua criação, o TRT/SC passa por uma evolução constante, para manter-se atualizado e operante com o aparelhamento da máquina administrativa e judiciária e promovendo treinamentos constantes de seus colaboradores. .
Com o advento da World Wide Web (WEB), unindo áreas remotas, é possível a criação de sistemas como: o processo eletrônico, em fase de implantação no TRT/SC, agilizando a tramitação em juízo, atendendo as necessidades ambientais, com o fim da cópia impressa, em que todo processo é produzido e julgado de forma eletrônica.
Com a implementação de novas tecnologias, surge a necessidade de remodelar o organograma da instituição, em que setores ficam obsoletos e outros são criados. A Secretaria de Informática (SEINFO) tem seu papel fundamental, trabalhando lado a lado com diversas áreas, de forma a dar sustentabilidade ao cotidiano da instituição, com a criação e aquisição de sistemas, automatizando todo processo administrativo e judiciário, sua manutenção e administração.
O Setor de Cadastro e de Administração de Bens (SCAB) é vinculado ao Serviço de Material e Patrimônio (SEMAP), que pertence a Secretaria Administrativa do TRT/SC. Segundo BRASIL (2009B) (Patrimônio (2009)), entre as atribuições do SCAB, destacam-se:
- receber e conferir, juntamente com o Setor de Almoxarifado, os materiais permanentes adquiridos pelo Tribunal;
- estocar os materiais permanentes;
- registrar a incorporação de bens permanentes móveis e imóveis ao patrimônio do TRT/SC;
- proceder ao tombamento dos materiais permanentes;
- receber da direção do SEMAP determinações para fornecimento dos materiais e processá-las;
- acondicionar e expedir aos usuários os materiais permanentes;
- registrar, controlar e manter atualizados os dados referentes à transferência dos bens móveis entre as unidades administrativas e judiciárias;
- inventariar, anualmente, com apoio das Varas do Trabalho, localizadas fora da Grande Florianópolis, o patrimônio do Tribunal;
- expedir termos de responsabilidade;
- atender e solucionar as questões dirigidas ao Setor acerca do fornecimento dos materiais permanentes;
- manter atualizada a classificação dos bens permanentes e subsidiar o Setor de Métodos e Controle com informações dos bens que poderão ser baixados do patrimônio, incorporados ao mesmo e/ou doados a instituições que os requeiram; - diligenciar e controlar os registros de bens imóveis;
- manter atualizados relatórios referentes aos bens do Tribunal.
O Sistema de Controle de Patrimônio tem por finalidade garantir a transparência dos investimentos realizados na aquisição e na distribuição de equipamentos pelo TRT/SC, permitindo auditorias interna ou externa, em que a prestação de contas seja transparente.
Proporcionar um ambiente de trabalho agradável para os colaboradores do SCAB, buscando uma forma simples de desburocratizar a administração do patrimônio público, com uma perfeita harmonia entre colaboradores e o sistema.
1.1 PROBLEMÁTICA
O TRT/SC conta com um sistema de gerenciamento de patrimônio genérico, que “são sistemas do tipo stand-alone, produzidos por uma organização de desenvolvimento e vendidos no mercado para qualquer cliente disposto a comprá-los”. (SOMMERVILLE, 2007, p. 4).
O sistema atual, segundo o relato feito pelos funcionários do SCAB, é uma cópia de um sistema existente no Tribunal Superior do Trabalho, que abrange várias áreas, e foi customizado para o gerenciamento de controle de patrimônio do TRT/SC.
Por não ser um sistema personalizado, ser heterogêneo, em que a parte principal é desenvolvida com a ferramenta Oracle-Forms, e tendo o TRT/SC o quadro de funcionários especializado nessa ferramenta reduzido.
Em virtude de que os investimentos da instituição estão concentrados na padronização dos sistemas na linguagem de programação Java em ambiente WEB, há o interesse por parte da SEINFO em adquirir um novo sistema.
Seguindo o mesmo raciocínio do parágrafo anterior, relata-se ainda que o sistema atual conta com um agravante, que é o fato de não possuir uma documentação adequada, tornando, assim, sua manutenção uma tarefa problemática para a equipe de manutenção.
Segundo uma demonstração realizada pelos funcionários do SCAB, foi possível constatar, que, na customização do sistema, consta telas que não são necessárias as tarefas realizados pelo SCAB, ou outro setor que tenha acesso ao sistema de gerenciamento de patrimônio, além de consultas e relatórios carentes de uma formatação adequada.
É possível verificar-se problemas de formatação de páginas, conforme a ilustração apresentada na Figura 1, a seguir.
Figura 1 – Consulta ao sistema atual.
Para o funcionário responsável por um setor imprimir um termo de responsabilidade de recebimento de material permanente, uma vez que o sistema atual não foi instalado em todos os setores do TRT/SC, outra parte do sistema foi desenvolvida em linguagem Active Server Pages (ASP) para ambiente WEB.
Para atender a necessidade descrita no parágrafo anterior, o Serviço de Desenvolvimento de Sistema (SEDES) é obrigado a manter dois sistemas que atendem um mesmo propósito que é o gerenciamento de patrimônio.
Devido aos problemas relatados nessa seção e as solicitações feitas pelo SCAB de mudanças e atualizações serem atendidas em pequeno número em um prazo longo, ou não serem atendidas, prejudicando, assim, o andamento do serviço executado por esse setor, surgiu a necessidade de mudanças do sistema atual para um novo sistema, justificando-se, assim, o desenvolvimento da presente monografia.
O Sistema de Gerenciamento de Patrimônio Proposto tem por finalidade:
• automatizar e padronizar o processo de gerenciamento de patrimônio do TRT/SC, conforme as normas estabelecidas pela SEIMFO;
• oferecer artifícios para consultas e controle dos bens cadastrados, seja em estoque, no almoxarifado, ou disponibilizados nas dependências do órgão, por meio da autenticação do usuário na intranet, pelo seu perfil, com poderes limitados por local de trabalho, em que será autorizado pelo administrador do sistema. Para Panagopoulos (2009), “intranet é um ambiente que usa tecnologia idêntica a da Internet, só que funciona dentro da rede local de uma empresa, protegido do exterior por um firewall”;
• contará com uma interface amigável, que é uma das reinvidicacões dos colaboradores do SCAB;
Em um segundo momento, pretende-se, ainda, implementar um catálogo dos bens cadastrados, constando a imagem do bem em destaque, em que o setor requisitante poderá navegar e decidir sobre a aquisição. Esse artifício não fará parte do escopo do trabalho.
1.2 OBJETIVOS
Nesta seção são apresentados os objetivos: geral e específicos.
1.2.1 Objetivo Geral
Desenvolver um protótipo de sistema de gerenciamento de patrimônio voltado para WEB para o TRT/SC, por meio da reengenharia do sistema atual.
1.2.2 Objetivos Específicos
O projeto tem como objetivos específicos:
• integrar a reengenharia de software em um processo interativo e incremental;
• estudar processos de reengenharia para aproveitamento das melhores práticas em um processo de desenvolvimento;
• usar ferramenta CASE na engenharia reversa para recuperar o maior número de artefatos para o novo sistema;
• construir um protótipo de sistema em ambiente WEB.
1.3 JUSTIFICATIVA
No segundo semestre de 2003, quando demos início aos estudos no curso de Ciência da Computação, tínhamos um propósito que era o aprendizado de banco de dados e
sabíamos que era necessário aprender, também, uma linguagem de programação de alto nível. Esse segundo item teve início já na primeira fase do curso e, durante todo o trajeto, ficou evidente o nosso prazer em realizar as atividades inerentes às disciplinas de Programação e Estrutura de Dados.
Com um aprendizado razoável em programação, deu-se início o aprendizado de banco de dados, sendo que as disciplinas de Engenharia de Software vieram a contribuir ainda mais, solidificado o aprendizado.
As disciplina de Programação para WEB e Interface Humano Computador proporcionaram um aprendizado na elaboração das interfaces visuais e aprofundaram um maior conhecimento na área de programação.
Já, nesse estágio do curso, sabíamos que o nosso trabalho final não poderia ser outro senão um protótipo de sistema para WEB, que utilizasse persistência de dados.
Em busca de um tema, entramos em contato com a SEINFO do TRT/SC, que sinalizou com a opção da criação desse sistema, uma vez que havia reivindicação por parte do SCAB, conforme citado na seção 1.1 deste capítulo, de um sistema com maior funcionalidade e praticidade.
O autor justifica o tema proposto por ser funcionário da instituição, o que lhe favorece novas oportunidades de demonstrar seu conhecimento na área, pela produção do trabalho dentro do TRT/SC.
1.4 ESTRUTURA DA MONOGRAFIA
O presente trabalho encontra-se estruturado da seguinte forma:
• capítulo 1 – descreve a introdução, objetivos, justificativa e estrutura da monografia;
• capítulo 2 – é realizada uma coletânea do acervo bibliográfico pesquisado que fundamenta o trabalho;
• capítulo 3 – são descritos os métodos usados para elaborar o trabalho; • capítulo 4 – é realizado um estudo de caso, por meio da metodologia IBM RUP, analisando o sistema atual e a realização do desenvolvimento de um protótipo para o sistema proposto;
• capítulo 5 – apresenta os testes, e validação.
• capítulo 6 – são abordadas as conclusões e recomendações para trabalhos futuros.
2 REVISÃO BIBLIOGRÁFICA
Este capítulo aborda as obras de diferentes autores sobre o assunto em questão, embasando a monografia segundo os autores, delimitado o estudo para a área de desenvolvimento de um software, tendo como base um sistema existente, em que será aplicada a reengenharia.
“O software não se desgasta” (PRESSMAN, 1995, p. 14), porém, com o passar do tempo, atualizações são necessárias, para que continue a ser útil, desenvolvendo as funções para as quais foi projetado. Mudanças tecnológicas, modernização, padronização dos sistemas, adição de funcionalidades não previstas no projeto original são questões que fazem com que o software se deteriore ou acabe por não mais atender as necessidades da empresa.
2.1 ENGENHARIA
Quando se aborda o termo “engenharia de software”, é conveniente definir engenharia em termos genéricos. Algumas definições sobre engenharia estão fundamentadas, e, ao longo da história, alguns relatos da necessidade da criação da engenharia são descritos no presente trabalho.
Segundo Houaiss (2001), a engenharia pode ser definida como "aplicação de métodos científicos ou empíricos à utilização dos recursos da natureza em benefício do ser humano".
A engenharia é tão antiga quanto a história da humanidade, ela “[...] confunde-se com a história da própria humanidade e teve início a cerca de sete milhões de anos”. Mediante estudos realizados por paleontólogos, a fabricação de ferramentas rudimentares teve início, devido aos primeiros hominídeos serem carnívoros. (CAVALCANTE, 2009).
Conforme o descrito acima e indo ao encontro da modernização, Cavalcante (2009) descreve o invento da eolípila, um aparelho formado por uma câmara com tubos curvados, em que sai o vapor, inventado no primeiro século por Heron de Alexandria, é relatado como sendo o primeiro motor a vapor documentado. A eolípila é mostrada, a seguir, na Figura 2.
Figura 2 – Eolípila.
Fonte: Adaptado de Cavalcante (2009).
Se Heron tivesse dominado essa forma de energia rotativa, o motor a vapor teria sido inventado quase dois mil anos antes da sua reinvenção. Cavalcante (2009) conclui que o motor a vapor foi criado a partir de uma idéia existente, redesenhada e remodelada, dando origem a um produto novo, ou seja, uma forma de reengenharia.
A reengenharia fica mais evidente, quando comparada entre objetos sólidos, como é o caso da engenharia civil, ilustrado na Figura 3, a seguir.
Figura 3 – Reengenharia na construção civil. Fonte: Adaptado de Braga (2006).
2.1.1 Engenharia de Software
A engenharia de software abrange um conjunto de três elementos fundamentais: métodos, ferramentas e procedimentos – que possibilita ao gerente o controle do processo de desenvolvimento do software e oferece ao profissional uma base para a construção de software de alta qualidade e produtividade. (PRESSMAN, 1995, p. 31).
Para Sommerville (2007), “a engenharia de software é uma disciplina de engenharia relacionada a todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até sua manutenção depois que este entrar em operação”.
Os métodos de engenharia de software proporcionam os detalhes de “como fazer” para construir o software. Os métodos envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa do projeto, análise de requisitos de software e de sistemas, projeto de estrutura de dados, arquitetura de programa e algoritmo de processamento, codificação, teste e manutenção. Os métodos da engenharia de software muitas vezes introduzem uma notação gráfica ou orientada a linguagem especial e introduzem um conjunto de critérios para a qualidade do software. As ferramentas de engenharia de software proporcionam apoio automatizado ou semi-automatizado aos métodos. Atualmente existem ferramentas para sustentar cada um dos métodos anotados anteriormente. Quando as ferramentas são integradas de forma que a informação criada por uma ferramenta possa ser usada por outra, é estabelecido um sistema de suporte ao desenvolvimento de software chamado de engenharia de software auxiliada por computador (CASE – Computer-Aided Software Engineering). O CASE combina software, hardware e um banco de dados de engenharia de software (uma estrutura de dados contendo importantes informações sobre análise, projeto, codificação e teste).
Os procedimentos da engenharia de software constituem o elo de ligação que mantém juntos os métodos e as ferramentas e possibilita o desenvolvimento racional e oportuno de software de computador. Os procedimentos definem a sequência em que os métodos serão aplicados, os produtos (deliverable) que exige que sejam entregues (documentos, relatórios, formulários etc.), os controles que ajudam a assegurar a qualidade e a coordenar as mudanças, e os marcos de referência que possibilitam aos gerentes de software avaliar o processo. (PRESSMAN, 1995, p. 33).
Para Sommerville (2007), Software não é somente o programa, mas todos os artefatos que fazem o programa funcionar adequadamente.
Conforme o exposto, no parágrafo acima, esses artefatos são programas e arquivos de configuração que fazem a comunicação da plataforma com o software, envolvem, ainda, um conjunto de documentos que são a planta do sistema, descrevendo a sua concepção e manuais de usuário, que ensina de forma sucinta como operar com o software ou buscar ajuda
on line, obtendo as últimas atualizações e as informações do produto.
Nos primórdios, ao escrever um software, o desenvolvedor tinha sua planta na cabeça, em que, em muitos casos, a documentação era rara ou inexistente. Caso houvesse falhas, ele mesmo as reparava. A maior parte do software era desenvolvida e, em última análise, usada pela própria pessoa ou organização. (PRESSMAN, 1995, p. 5).
Com o passar do tempo e com o avanço da tecnologia, novas ferramentas para apoio à engenharia de software foram desenvolvidas. O CASE segundo Sommerville (2005, p. 57), é a denominação dada ao software, usado no apoio das atividades de processo de
software. Entre essas atividades, destacam-se: a engenharia de requisitos, projetos,
desenvolvimento de programas e teste.
Incluem-se, no grupo de ferramentas CASE, os editores de diagramas, dicionário de dados, compiladores, debuggers, ferramenta de construção de sistemas etc. A seguir, é apresentada uma definição da tecnologia CASE.
A tecnologia CASE fornece apoio ao processo de software pela automação de algumas atividades de processo e pelo fornecimento de informações sobre o software que esta sendo desenvolvido. Exemplo de atividades que podem ser automatizadas com o uso do CASE incluem:
- o desenvolvimento de modelos gráficos de sistema como parte da especificação de requisitos ou do projeto de software;
- a compreensão de um projeto por intermédio do uso de um dicionário de dados com informações sobre as entidades e as relações em um projeto;
- a geração de interfaces com o usuário com base em uma descrição de interface gráfica criada interativamente pelo usuário;
- o debugging do programa por meio do fornecimento de informações sobre um programa em execução;
- a tradução automática de programas a partir de uma versão antiga de uma linguagem de programação, como COBOL, para uma versão mais recente.
A tecnologia CASE está disponível atualmente para a maioria das atividades rotineiras do processo de software. Isso levou a alguns aprimoramentos de qualidade
e produtividade de software, embora estes sejam menores do que os previstos pelos primeiros defensores do CASE. (SOMMERVILLE, 2007, p. 57).
2.1.1.1 Engenharia de Sistemas
“A engenharia de sistemas é a atividade de especificação, projeto, implementação, validação, implantação e manutenção de sistemas”. (SOMMERVILLLE, 2007, p. 17).
O autor mencionado no parágrafo anterior comenta que os engenheiros, ao projetarem o sistema, levam em conta, além do software, o hardware e as interações do sistema com usuários e seu ambiente. Fatores, como as restrições de criação e operação, devem ser analisados para que o sistema tenha seus objetivos alcançados.
Para Pressman (1995), a engenharia de sistemas de software é uma atividade destinada a solucionar problemas. As funções necessárias para o funcionamento do sistema são desvendadas, analisadas e designadas dos elementos individuais do sistema.
O autor citado a cima comenta que o analista inicia os trabalhos por meio da coleta de requisitos definidos pelo cliente e deriva uma representação da função, desempenho, interfaces, restrições de projeto e estrutura de informações que podem ser atribuídos a cada um dos elementos de sistema genéricos.
Segundo Maffeo (1992), “em termos genéricos, pode-se definir um sistema como sendo: um conjunto, identificável e coerente de elementos que interagem, coesivamente, em que cada elemento pode ser um sistema”.
Para Sommerville (2007), “um sistema pode ser definido como um conjunto de elementos interrelacionados que interagem no desempenho de uma função”.
Seguindo a referência anterior, relata-se que sistemas técnicos, baseados em computadores, são aqueles que incluem hardware e software, e não incluem procedimentos e processos. São incluídos nessa categoria de sistemas televisores, telefones celulares, além de grande parte dos softwares de computadores pessoais.
Continuando com a linha de raciocínio, Sommerville (2007) considera que as organizações e usuários usam sistemas técnicos para alguma finalidade, mas o conhecimento dessa finalidade não é o propósito do sistema, como exemplo, no caso de um processador de textos, o processador não sabe que está escrevendo um livro.
Ainda, o mesmo autor enfatiza que os sistemas sociotécnicos podem incluir um ou mais sistemas técnicos, mas incluem, também, conhecimento de como o sistema deve ser usado para alcançar seu principal objetivo. Portanto, esses sistemas têm processos operacionais definidos, incluem pessoas como partes inerentes ao sistema.
2.2 PROCESSO DE SOFTWARE
Um processo de software, para Sommerville (2007, p. 42), representa um conjunto de atividades padronizadas para produção de um produto de software. As atividades envolvem o desenvolvimento do software, usando uma linguagem de programação adequada como, por exemplo: Java ou C. Porém, em circunstância em que já existe um sistema operando, que não atende mais às necessidades da empresa e a seus usuários, o novo software pode ser desenvolvido a partir da ampliação ou modificando o sistema existente.
O autor citado acima, menciona, que a complexidade de um processo de software dependerá da natureza que esse software representa e a resolução do problema dependerá da criatividade de seus criadores, em que a automatização do processo tem sucesso limitado.
Booch et al. (2000, p. 3) relatam que, ao entregar um software de qualidade e de conformidade com aquilo que foi contratado, não é somente entregar documentos bonitos e códigos bem elaborados, é necessário reunir-se e interagir com os usuários de forma disciplinada, tendo como objetivo expor requisitos reais do sistema.
Sommerville (2007, p. 42) entende que as ferramentas CASE podem apoiar algumas atividades de processo. Como não são ferramentas que assumem o processo criativo, é necessária a criatividade dos engenheiros envolvidos no processo de software. A principal razão para as limitações da eficiência dessas ferramentas são decorrentes da imensa diversidade dos processos de software.
Destacam-se algumas ferramentas CASE usadas para aplicação na engenharia reversa como: Rational Rose Developer for UNIX, que, segundo Rational (2009), importa um sistema já implementado, permitindo, assim, uma melhor visualização desse sistema.
Seguindo a mesma linha de raciocínio destaca-se que a ferramenta Enterprise
relacionamento, partindo-se de SGBD existente com uso de um driver Open Data Base
Connectivity (ODBC).
Não existe um processo ideal, e varias organizações desenvolvem abordagens inteiramente diferentes para o desenvolvimento de software. Os processos evoluíram para explorar as capacidades das pessoas em uma organização e as características específicas dos sistemas que estão sendo desenvolvidos. No caso de alguns sistemas, como os sistemas críticos, é necessário um processo de desenvolvimento muito estruturado. Nos sistemas de negócios, com requisitos que mudam rapidamente, um processo flexível e ágil é provavelmente mais eficaz.
Embora existam muitos processos de software diferentes, algumas atividades fundamentais são comuns a todos eles, como:
- especificação de software. A funcionalidade do software e as restrições sobre sua operação devem ser definidas;
- projeto e implementação de software. O software que atenda à especificação deve ser produzido;
- validação de software. O software deve ser validado para garantir que ele faça o que o cliente deseja;
- evolução do software. O software deve evoluir para atender às necessidades mutáveis do cliente. (SOMMERVILLE, 2007, p. 42).
2.2.1 Atividades do processo de desenvolvimento
Bezerra (2002, p. 20) destaca que o “processo de desenvolvimento classifica, em atividades, as tarefas realizadas durante a construção de um sistema de software”.
Segundo Coleman et al. (1996, p. 300), durante o processo de desenvolvimento, se alguma das atividades não puder ser realizada, o plano deve incluir uma atividade para a tomada de decisão. Eles salientam, no entanto, que o plano deve estabelecer um cronograma, alocando recursos para as atividades necessárias à produção que envolve os riscos.
No presente trabalho, na seção que trata sobre o modelo de processo de software, serão descritos alguns dos modelos de processos, cada um com suas particularidades, na forma de arranjo e encadeamento dessas atividades, porém algumas atividades, com pequenas alterações, são comuns à maioria dos processos existentes. Algumas dessas atividades são descritas a seguir.
2.2.1.1 Levantamento de Requisitos
Bezerra (2002, p. 20) destaca que a atividade de levantamento de requisitos corresponde a etapa de compreensão do problema e que este levantamento tem como seu principal objetivo a produção de uma visão única para os desenvolvedores e usuários do problema a ser resolvido.
O autor citado anteriormente comenta que, é nessa etapa que desenvolvedores e clientes procuram levantar e definir necessidades para o futuro sistema.
“Formalmente, um requisito é uma condição ou capacidade que deve ser alcançada ou possuída por um sistema ou componente deste para satisfazer um contrato, padrão, especificação ou outros documentos formalmente impostos”. Maciaszek (2000 apud BEZERRA, 2002, p. 20).
Sommerville (2007, p. 80) entende que alguns dos problemas encontrados, durante a engenharia de requisitos, resultam de uma falta de separação entre os níveis de descrição, ou seja, ele separa os requisitos em:
• requisitos de usuário, que é uma abstração para os requisitos de alto nível; • requisitos de sistema, para a descrição detalhada do que o sistema deve fazer. Ambos os requisitos, são mais bem detalhados no decorrer do presente capítulo.
Bezerra (2002, p. 20) destaca que os requisitos de sistema são definidos, partindo-se do domínio de negócio.
Ainda, nessa mesma linha de considerações, é importante frisar que: domínio de negócios é a área de conhecimento especifica em que um determinado sistema será desenvolvido. Em outras palavras, domínio de negócios é uma visão do mundo real que tem relevância no desenvolvimento de um sistema.
Os requisitos de sistemas de software, segundo Sommerville (2007, p. 79), podem ser expressos como requisitos de usuário e de sistema como definidos anteriormente por ele, e diferenciados por requisitos funcionais e requisitos não funcionais. Os requisitos serão descritos detalhadamente mais adiante.
Continuando a análise anterior, Bezerra (2002, p. 20) ressalta que: “Os requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e as suas restrições
operacionais”. Considera, ainda, que esses requisitos representam o que o cliente deseja em termos de sistema para resolução dos seus problemas.
“O processo de descobrir, analisar, documentar e verificar os serviços e restrições é chamado de engenharia de requisitos”. (SOMMERVILE, 2007, p.79).
Com o levantamento dos requisitos, a equipe de desenvolvedores tem os artifícios para identificar o domínio do negócio que deverá ser automatizado pelo novo sistema de
software. No entanto, a engenharia de requisitos pode ser o maior problema enfrentado no
desenvolvimento de sistemas de software grandes e complexos. (SOMMERVILE, 2007; BEZERRA, 2002).
Sommerville (2007, p. 80) afirma que: (1) requisitos de usuário são declarações em linguagem natural, contemplados com diagramas de quais serviços são esperados pelo sistema proposto e suas restrições às quais deve operar; (2) requisitos de sistema são definições detalhadas das funções, serviços e restrições operacionais do sistema. Os requisitos de sistema são classificados em:
1. requisitos funcionais – são os requisitos que definem as funcionalidades do sistema, reação do sistema em uma entrada específica e o comportamento do sistema em uma situação. Quando são requisitos de usuários são descritos de forma bastante abstrata, porém descrevem as funções de sistema em detalhes como as entradas, saídas e exceções;
2. requisitos não funcionais – são declaradas nestes requisitos, as características referentes à qualidade do sistema, com relação às suas funcionalidades, apontando as restrições sobre serviços ou funções oferecidas pelo sistema;
3. requisitos de domínio – são derivações do domínio da aplicação do sistema, incluem uma terminologia específica de domínio ou se referem a conceitos do domínio. Como esses requisitos são especializados, há certa dificuldade de compreensão por parte dos engenheiros de software no que se refere à relação com outros requisitos do sistema. (BEZERRA 2002; SOMMERVILLE 2007).
Sommerville (2007, p. 91) explica que um documento de requisitos de software, ou especificação de requisitos de software para alguns autores, ou ainda Software
Requirements Specification (SRS), “é a declaração oficial do que os desenvolvedores de
O autor citado acima, entende que, nesse documento, devem-se conter os requisitos de usuário e o detalhamento dos requisitos de sistema.
Seguindo a mesma linha de raciocínio, ele considera que, em alguns casos, ambos os requisitos podem estar integrados na mesma descrição. Em outros casos, os requisitos de usuário são definidos em uma introdução dentro da especificação do sistema.
Ainda, continuando com a mesma linha de raciocínio em que o autor citado comenta que, sistemas de grande porte com um número elevado de requisitos, os requisitos detalhados de sistema podem ser escritos em documentos separados. A Figura 4 ilustra os possíveis usuários do documento e de como eles o utilizam.
Figura 4 – Usuários de um documento de requisitos. Fonte: Adaptado de Sommerville (2007).
Bezerra (2002, p. 22) compreende que uma questão importante sobre o documento de requisitos é que essa documentação não contenha as soluções de elucidação técnica adotadas no desenvolvimento do sistema.
Por conseguinte, seguindo o mesmo entendimento do parágrafo anterior, o alvo do levantamento de requisitos deve ser: o que o usuário necessita do novo sistema. O autor citado anteriormente, alerta, ainda, que “novos sistemas serão avaliados pelo seu grau de conformidade aos requisitos, não importa quão complexa a solução tecnológica tenha sido”.
Ainda nessa, mesma linha de considerações, ele esclarece que requisitos descrevem o problema a ser resolvido pelo sistema, não descrevem a solução adotada com o uso de software para a resolução do problema.
Destaca, ainda, que o sistema deva ser compreendido antes de ser construído. E que, é com o levantamento dos requisitos que o sistema é compreendido, evidenciando, assim, a importância para o perfeito desenvolvimento de todo o projeto.
Por conseguinte, ele entende que, em sistemas de certa complexidade, é impossível pensar em todos os detalhes no início e que, principalmente, quando o sistema entra em produção, durante o decorrer de seu uso, os próprios usuários descobrirão requisitos que não tinham sido especificados durante o projeto.
2.2.1.2 Análise de Requisitos
Bezerra (2002, p. 24) sustenta que “o termo análise corresponde a ‘quebrar’ um sistema em seus componentes e estudar como tais componentes interagem com o objetivo de entender como esse sistema funciona”.
Continuando com a mesma linha de raciocínio, o autor citado anteriormente considera que, no contexto dos sistemas, a análise de requisitos é a etapa em que o estudo dos requisitos levantados deve ser detalhado. Após o estudo então os modelos que representam o sistema serão construídos.
Já Pressman (1995, p. 231) salienta que o entendimento dos requisitos é primordial para alcançar o sucesso no desenvolvimento do software. Ele argumenta que, mesmo que tenha sido realizado um bom projeto e bem codificado, se foi mal analisado e especificado, com certeza, desapontará o usuário, causando inconvenientes ao desenvolvedor.
Em vista disso, ele descreve que a tarefa de análise de requisitos é a forma de realizar descobertas, um refinamento dos requisitos, modelagem e da especificação do sistema. Então, o software, refinado durante o planejamento do projeto, será aperfeiçoado em detalhes.
Rumbaugh et al. (1994, p. 345) sustentam que a diferença entre análise e o projeto, dá à impressão de não seguir uma regra, ou ser confusa, eles entendem que a regra a seguir guia o projetista na tomada de decisões a respeito do escopo correto da análise e projeto.
Os autores citados acima observam que o modelo da análise deve acrescentar as informações sob o mundo real, apresentando, assim, a visão externa do sistema, e que é este modelo que o cliente deve compreender, pois fornecerá uma base útil sem dar margem a dúvidas sobre os requisitos verdadeiros do sistema.
Seguindo a mesma linha de raciocínio os autores comentam que esses requisitos verdadeiros são aqueles necessários, possíveis de serem alcançados, para o perfeito funcionamento do produto de software.
Acrescentam, ainda, que, diferente do modelo de análise, o modelo de projeto depende da relevância para a perfeita implementação em computador, devendo ser eficiente e de codificação prática. Dizem, ainda, que, na prática, partes do modelo de análise podem ser implementadas sem modificar, havendo, assim, uma considerável sobreposição dos modelos citados.
Que os detalhes de níveis inferiores omitidos no modelo de análise devem ser citados no modelo de projeto. Eles registram, ainda, que os dois modelos combinam-se, oferecendo uma valiosa documentação, em perspectivas diferentes que se complementam.
Bezerra (2002, p. 24) sustenta que, no levantamento de requisitos bem como na análise de requisitos, não será considerado o ambiente tecnológico a utilizar. O primordial, aqui, é construir uma estratégia para solucionar o problema, sem a preocupação de como essa estratégia será realizada.
Ele afirma que, no processo de desenvolvimento orientado a objetos, o resultado da análise são os modelos representativos da estrutura das classes de objetos que compõem o sistema. Aponta, ainda, que o resultado da análise, também, são modelos que especificam as funcionalidades do sistema.
Pressman (1995, p. 231) menciona que analisar e especificar requisitos parece ser uma tarefa simples, entretanto, o conteúdo de comunicação é muito elevado. Há um grau de interpretações errôneas e informações falsas muito fortes. É, nesse momento, que o que o cliente fala e acaba sendo interpretado de outra maneira, levando ao erro nos requisitos e na sua posterior análise, caso não seja detectado.
2.2.1.3 Projeto
Alguns autores separam projeto em uma seção, em outros, é parte do ‘processo de desenvolvimento’. Nesta monografia, considerou-se projeto como subtítulo de processo de desenvolvimento.
É oportuno destacar que, segundo Bezerra (2002, p. 26), embora a análise e o projeto sejam referenciados separadamente, essas duas fases não são assim tão distintos e que, principalmente, no desenvolvimento de sistemas orientados a objetos, as atividades dessas duas fases, constantemente, se misturam.
Ele sustenta que o os requisitos são o foco principal da análise. Considera que a fase do projeto é a fase que determina a forma de como o sistema funcionará para atender os requisitos, de acordo com a tecnologia existente. Nessa fase, a de projetos, são considerados os aspectos físicos e dependentes de implementação.
Ele esclarece que as restrições tecnológicas são adicionadas na fase de projeto aos modelos construídos na fase de análise. Alguns exemplos que podem ser considerados na fase de projeto são: arquitetura do sistema, padrão de análise gráfica, linguagem de programação, gerenciador de banco de dados etc.
Martins (2007, p. 258) destaca que “os objetivos do projeto devem ser específicos, mensuráveis e realísticos”. Considera que o plano de projeto tem como seu foco principal os objetivos do projeto, partindo do ponto de vista do negócio. A importância aqui é indicar o que será produzido, não contemplando o por que será produzido.
Pressman (1995, p. 416) afirma que “o projeto de dados transforma o modelo de domínio de informação criado durante a análise nas estruturas de dados que serão exigidas para se implementar o software”.
Ele reforça, ainda, que a relação entre os componentes estruturais do sistema é definida no projeto de arquitetura, e que o projeto procedimental irá transformar esses componentes numa descrição procedimental de software. Em decorrência, o código fonte é escrito e os testes realizados, podendo, assim, validar o software.
Bezerra (2002, p. 25) reforça que, no processo de desenvolvimento orientado a objeto, as classes de objetos relacionadas, do sistema, são distribuídas, pelo projeto de arquitetura, em subsistemas e seus componentes, distribuindo, assim, esses componentes fisicamente pelos recursos de hardware disponíveis.
Enfatiza, entretanto, que os diagramas UML, utilizados nessa fase do projeto, são os diagramas de implementação, e que as colaborações entre os objetos de cada módulo, no momento de detalhamento do projeto, são modeladas, tendo como objetivo alcançar a funcionalidade do módulo. Destaca que, ainda nessa fase do projeto, são criados os projetos de interface com o usuário e banco de dados.
Ao referir-se aos diagramas UML, para complementar o parágrafo anterior, ele afirma que são utilizados, aqui, os diagramas de: classe, casos de uso, de interação, de estados e diagrama de atividades.
2.2.1.4 Implementação
É na fase de implementação que ocorre a programação propriamente dita escrita em uma linguagem de alto nível, como exemplo Java ou C++, toda documentação descrita, na fase de projeto, é codificada e compilada, resultando, então, um código executável. (BEZERRA, 2002, p. 26).
No processo de desenvolvimento orientado a objetos, segundo o autor citado no parágrafo anterior, as classes de objetos, são definidas e implementadas, mediante o uso de uma linguagem de programação orientada objetos.
Coleman et al. (1996, p. 300) por sua vez, reforçam que a implementação tem de ser correta, comportando-se da forma que foi escrita no projeto, satisfazendo, assim, os requisitos levantados. Consideram que deva ser econômica, do ponto de vista de software e hardware, economizando, assim, tempo e memória.
2.2.1.5 Testes
Bezerra (2002, p. 26) salienta que os testes são realizados, levando-se em conta várias atividades, em que um relatório de teste deve ser obtido, contendo informações a respeito de erros detectados no software. Ao final dos testes, os módulos do sistema são integrados, compondo, assim, o produto que é o software.
2.2.1.6 Implantação
No processo de implantação, o sistema é empacotado e, posteriormente, será distribuído para instalação no ambiente do usuário. Nessa etapa, os manuais do sistema são escritos; usuários são treinados para o correto uso do sistema. (BEZERRA, 2002, P. 26).
2.3 MODELO DE PROCESSO DE SOFTWARE
Para Booch et al. (2000, p. 6), “os modelos fornecem uma cópia do projeto de um sistema”. Esses autores relatam que, com o uso dos modelos, planos detalhados, podem ser alcançados ou em um primeiro momento, uma visão mas abstrata do sistema. Afirmam, ainda, que, com um modelo, quatro objetivos podem ser alcançados:
1. os modelos dão uma panorâmica do sistema como ele é, ou como gostaríamos que ele fosse;
2. que, por meio dos modelos, pode ser especificada a estrutura ou comportamento de um sistema;
3. que os modelos guiam os projetistas durante a construção do sistema; 4. que os modelos fornecem artifícios para documentar as decisões tomadas. Sommerville (2007, p. 43) descreve um modelo de processo de software como sendo “uma representação abstrata de um processo de software”. O autor destaca que cada modelo expõe um processo de certa forma, fornecendo somente informações parciais sobre esse processo. A seguir, apresenta-se uma breve descrição dos principais modelos.
2.3.1.1 Modelo em Cascata
Segundo Pressman (1995), o modelo em cascata “requer uma abordagem sistemática, sequencial ao desenvolvimento do software, que se inicia no nível do sistema e
avança ao longo da análise, projeto, codificação, teste e manutenção”. Como é um modelo sequencial, uma versão do software só fica pronta numa etapa avançada do desenvolvimento, em que erros no projeto são percebidos. O modelo em cascata é representado, conforme a Figura 5, mostrada a seguir.
Figura 5 – Modelo em cascata.
Fonte: Adaptado de Sommerville (2007).
2.3.1.2 Prototipação
Para Pressman (1995, p. 35), a prototipação é definida como um processo que conduz o desenvolvedor na criação de um modelo de software implementado posteriormente, destacando que esse modelo pode assumir uma das formas descritas a seguir:
1. um protótipo desenhado em uma folha ou em uma ferramenta gráfica para desenho no computador. Descreve as interações homem máquina, capacitando o usuário a entender quantas interações ocorrerão;
2. um protótipo que implementa um subconjunto das funções requisitadas do software a ser desenvolvido;
3. um programa existente que executa alguma ou todas as funções que o software fornecerá e que possua outras características a serem melhoradas posteriormente .
Para Pressman (1995, p. 36), a prototipação tem início com a coleta dos requisitos, em que o desenvolvedor interage com o cliente, definindo os objetivos globais para o software. A seguir, a Figura 6 ilustra o modelo.
Figura 6 – Prototipação.
Fonte: Adaptado de Pressman (1995).
2.3.1.3 Modelo Espiral
Nesse modelo, segundo Sommerville (2007, p. 48), “o processo é representado como um espiral”, também, relata que cada loop na espiral demonstra uma fase do processo de software, começando com a elaboração dos objetivos, como desempenho e funcionalidade.
O autor citado no parágrafo anterior destaca que os caminhos seguidos, para alcançar os objetivos e as restrições impostas sobre cada um, são enumerados, sendo cada alternativa avaliada em relação a cada objetivo em que os focos de risco do projeto são identificados. O modelo espiral está representado na Figura 7, a seguir.
Figura 7 – Modelo espiral.
Fonte: Adaptado de Sommerville (2007).
2.3.1.4 Modelo Iterativo e Incremental
Para Bezerra (2002, p. 33), “modelo de ciclo de vida incremental e iterativo foi proposto como uma resposta aos problemas encontrados no modelo cascata”. Também, ele relata que o desenvolvimento de um produto de software, seguindo essa abordagem, é dividido em ciclos, sendo identificadas em cada ciclo de desenvolvimento as fases de análise, projeto, implementação e testes.
Ele destaca, ainda, que, diferente do modelo em cascata em que as fases de análise, projeto, implementação e testes, são realizados somente uma vez. Nesse modelo, um
processo de desenvolvimento de software divide o desenvolvimento em ciclos, em que cada um dos ciclos compreende um subconjunto de requisitos.
Seguindo-se a linha de raciocínio anterior, em que os requisitos são desenvolvidos, e, no ciclo seguinte, outro subconjunto de requisitos é considerado para ser desenvolvido, produzindo, assim, um novo incremento no sistema que foi estendido a partir do incremento anterior, em que foram adicionadas novas capacidades funcionais.
Os ciclos prosseguem e, assim, o desenvolvimento evoluir em versões, com a criação de novas funcionalidades de forma incremental e iterativa até o completo desenvolvimento do sistema.
O modelo iterativo e incremental é exibido, na Figura 8, apresentando três ciclos de desenvolvimento para dar um melhor entendimento da sua funcionalidade.
Figura 8 – Modelo iterativo e incremental. Fonte: Adaptado de Bezerra (2002).
Bezerra (2002, p. 34) comenta, entretanto, que, “no modelo de ciclo de vida incremental e iterativo, um sistema de software é desenvolvido em vários passos similares (iterativo). Em cada passo, o sistema é estendido com mais funcionalidades (incremental)”.
Bezerra (2002, p. 34) relata, ainda, que, nesse modelo, a participação do usuário, nas atividades de desenvolvimento do sistema, diminui bastante a probabilidade de interpretações erradas quanto aos requisitos levantados.
Entretanto, seguindo o mesmo raciocínio do parágrafo anterior o autor citado comenta que vários autores alertam que, no modelo iterativo e incremental, o usuário pode se entusiasmar excessivamente com a primeira versão do sistema e querer implementar essa versão, prejudicando, assim, o andamento do projeto.
Outro ponto positivo a considerar é que os riscos do projeto podem ser mais bem gerenciados, se seguidos, conforme esse modelo.
2.3.1.5 Método Fusion
A literatura pesquisada referente à reengenharia está embasada nas dissertações, em que os autores fazem menção na tese desenvolvida por Penteado (1996). O estudo sobre reengenharia foi realizado tomando, como base, esse rico acervo disponível na internet.
O acervo mencionado aponta para o Método Fusion, utilizado como o método de desenvolvimento de software por esses autores em suas obras.
Continuando com o trabalho de pesquisa, em que a obra literária dos criadores do
Método Fusion, Coleman et al. (1996), a biblioteca desta instituição possui um exemplar, teve-se contato direto com a obra e por isso considerou-se conveniente fazer-se referências a ela.
Os autores citados no parágrafo anterior, quando se referem ao Método Fusion, afirmam tratar-se de um método de desenvolvimento para produzir software orientado a objetos, fornecendo recursos para análise, projeto e implementação.
Continuando o raciocínio acima eles destacam que esse método esteja baseado em um conjunto resumido, porém completo, de notações para coleta de decisão, de análise e de projeto. Estas notações são discutidas a seguir.
Uma característica a destacar sobre o Método Fusion é que, além do desenvolvimento de novos sistemas, pode ser aplicado na reengenharia, segundo seus criadores.
Esse método divide o processo de desenvolvimento em análise, projeto e implementação. Essas fases serão discutidas, detalhadamente, na seção atividades do processo de desenvolvimento. Seus autores observam que o método mantém um dicionário de dados
para a identificação e descrição detalhada das entidades existentes no sistema, servindo de referência em todo o processo de desenvolvimento.
Entretanto, seus criadores mencionam que o método não possui uma etapa de captura de requisitos. Consideram que o documento de requisitos inicial deverá ser fornecido pelo usuário. O Método Fusion está representado na Figura 9, a seguir.
Figura 9 – Método Fusion.
Fonte: Adaptado de Coleman et al. (1996).
2.3.1.6 Rational Unified Process
O IBM RUP, segundo Sommerville (2007, p. 54), “é um modelo construído por fases que identificam quatro fases discretas no processo de software”.
Alguns autores argumentam que o IBM RUP é um framework para gerar processos. Sommerville (2007, p. 54) explica que, diferente do modelo em cascata, as fases
coincidem com as atividades do processo. O IBM RUP mantém uma relação mais restrita com os negócios do que com assuntos técnicos. As fases do IBM RUP são descritas a seguir:
1. concepção ou iniciação – o objetivo dessa fase é instaurar um business case para o sistema. Portanto, é necessário identificar as entidades externas, ou seja, pessoas e sistemas que deverão interagir com o sistema. As informações obtidas servem para avaliar a forma que o sistema contribui com o negócio. Caso a contribuição seja pequena, o projeto pode ser cancelado depois dessa fase;
2. elaboração – tem como objetivo desenvolver a compreensão do domínio do problema, estabelecer um framework de arquitetura para o sistema, criar um planejamento do projeto, sendo identificados os riscos principais, em que, no fim dessa fase, um modelo de requisitos para o sistema será criado, mediante a especificação dos casos de uso em UML, além de uma descrição da arquitetura e um plano de desenvolvimento para o software. 3. construção – essa fase mantém estreita relação com o projeto, programação
e teste de sistema. O sistema é desenvolvido em partes paralelamente que serão integradas nessa fase. No final dessa fase, o sistema já estará em funcionamento com a documentação pronta para ser apresentada aos usuários.
4. transição – é a fase em que o sistema é transferido da equipe de desenvolvedores para os usuários, é posto em atividades, funcionando, normalmente, em seu ambiente operacional.
Ainda, seguindo o relato acima, destaca-se que a iteração do IBM RUP é constituída de duas formas, cada fase pode ser feita de forma iterativa, tendo resultados desenvolvidos incrementalmente.
Quanto ao número de iterações, Kruchten (2003, p. 110) destaca que, costumeiramente na fase de concepção de um projeto, não serão realizadas iterações reais, devido essa fase normalmente contemplar somente o planejamento e a comercialização de atividades.
Seguindo-se, ainda, o comentário, citado no parágrafo anterior, na fase de elaboração, poderá ocorrer uma iteração, na fase de construção e de transição deverá ocorrer no mínimo uma sendo que, no caso desta em que um software pode ser de baixa qualidade ou de grande complexidade, haverá a necessidade de mais iterações.
Sommerville (2007, p. 54) enfatiza que a visão estática do IBM RUP visualiza as atividades do processo de desenvolvimento, chamadas de workflows, para tanto são denominados seis workflows de processos principais e três de apoio.
O IBM RUP foi projetado em conjunto com a linguagem UML, portanto a descrição dos workflows segue a orientação em termos dos modelos associados.
Sommerville (2007, p. 54) argumenta que a principal vantagem de apresentar as visões estática e dinâmica é devido às fases do processo de desenvolvimento não estarem associados aos workflows específicos. Os principais workflows de engenharia e de apoio podem ser observados na Tabela 1, a seguir.
Tabela 1 – Workflows Estáticos no Rational Unified Process Workflows Descrição
Modelagem de negócios
Os processos de negócios são modelados, usando casos de uso de negócios.
Requisitos Os agentes que integram com o sistema são identificados, e os casos de uso são desenvolvidos para modelar os requisitos de sistema.
Análise e projeto Um modelo de projeto é criado e documentado, usando modelos de arquitetura, modelos de componente, modelo de objeto e modelos de sequência.
Implementação Os componentes de sistema são implementados e estruturados em subsistemas de implementação. A geração automática de código com base nos modelos de projeto ajuda a acelerar esse processo.
Teste O teste é um processo iterativo realizado em conjunto com a implementação. O teste de sistema segue o término da implementação. Implantação Uma versão do produto é criada, distribuída aos usuários e instalada no
local de trabalho. Gerenciamento de
configuração e mudanças
Esse workflow de apoio gerencia as mudanças do sistema.
Gerenciamento de projetos
Esse workflow de apoio gerencia o desenvolvimento do sistema.
Ambiente Esse workflow está relacionado à disponibilização de ferramentas
apropriadas de software para a equipe de desenvolvimento. Fonte: Adaptado de Sommerville (2007).
Segundo Kruchten (2003, p. 3), o IBM RUP pode ser implementado na reengenharia por meio de artefatos extraídos do sistema legado com a aplicação da engenharia reversa.
Os processos de desenvolvimentos do IBM RUP podem ser melhores compreendidos na Figura 10, que demonstra o esforço realizado na atividade das disciplinas em cada fase.
Figura 10 – Rational Unified Process. Fonte: Adaptado de Syns (2009).
2.4 PROCESSO DE DESENVOLVIMENTO DA REENGENHARIA
Em se tratando de reengenharia, há várias situações de desenvolvimento, segundo Coleman et al. (1996, p. 287) que podem ser: o acréscimo de novas funcionalidades com uma nova tecnologia de implementação, até mesmo a introdução completa de uma nova tecnologia.
Continuando a citação anterior, eles consideram que a reengenharia deva ser usada em casos em que haja a necessidade de alteração de alguma ou total funcionalidade do
software. Na sequência, é descrito o processo em que é realizada uma implementação parcial
com alterações na funcionalidade:
1. identificar partes do sistema – se faz necessário a identificação da parte do sistema a ser reimplementado e suas interações;
2. preparar o modelo de análise – partindo da documentação do sistema existente, cabe aqui a produção de modelos de análise para o sistema ou parte dele que será submetido a reengenharia;
3. mapear o modelo de análise para o sistema existente – esse mapeamento está sujeito às seguintes restrições: mapear cada componente da análise e o relacionamento existente no modelo de análise. Um documento deve conter um elemento consistente com o código fonte;
4. importar novos requisitos – os modelos sofreram mudanças de acordo com novos requisitos;
5. avaliar a interface do novo componente – nessa etapa, a interface deve ser completamente definida, partindo da parte que será trocada e considerando a parte do sistema restante;
6. projetar um novo subsistema – contempla o projeto do novo componente e a sua interface para o sistema antigo;
7. modificar o sistema antigo – finalmente, com a adição de uma interface no sistema antigo, permitindo, assim, que os agentes interajam com os componentes do novo sistema.
2.4.1 Reengenharia de Software
Com a crescente evolução da tecnologia, a informática atua na linha de frente dessa metamorfose tecnológica que o mundo globalizado vem sofrendo. Um software robusto que atue numa área como, por exemplo: um sistema de controle de tráfegos aéreos em que centenas de software operam em conjunto, são extremamente complexos e caros. (SOMMERVILLE, 2007, p. 331).
Continuando com a linha de raciocínio, o autor citado sustenta que, com o passar dos anos esses produtos acabam obsoletos devido a mudanças de tecnologia. Surge a
necessidade de implementação de alguma função que por terem sido projetados por uma metodologia ultrapassada ou uma linguagem de programação em desuso não comportam as mudanças necessárias.
Sommerville (2007, p. 331) destaca que, no projeto, a partir de um sistema legado, a reengenharia desse sistema tem vantagens em relação à construção de um novo projeto, partindo do zero, principalmente, pela redução de riscos devido ao desenvolvimento desse tipo de software tender a erros de especificação ou problemas no desenvolvimento.
Conforme o raciocínio descrito, no parágrafo acima, o projeto tende a atrasos na entrega, onerando os custos de desenvolvimento, podendo ocorrer inclusive a perda do negócio. A reengenharia tem um custo reduzido em relação ao desenvolvimento de um novo
software, por buscar, principalmente, os requisitos no software existente.
Conforme o exposto nessa seção, se torna evidente que a reengenharia deve ser usada quando da existência de um software legado.
Sommerville (2007, p. 331) enfatiza que a reengenharia de software aplicada, em sistemas legados, torna sua manutenção fácil.
Seguindo a mesma linha de raciocínio, ele comenta que a reengenharia pode produzir nova documentação, organização e reestruturação do sistema, convertendo o sistema legado em uma linguagem de programação moderna com a modificação e atualização da estrutura existente. O sistema continua a desenvolver suas atividades, com uma interface atualizada mais moderna.
Jacobson e Lidström (1991, apud PENTEADO, 1996, p. 52) “definem reengenharia como sendo composta de engenharia reversa + ∆ + engenharia avante”. Mencionam que o processo seja iniciado com:
• na engenharia reversa, é feita uma definição abstrata do sistema;
• o ∆ é um representativo das modificações de funcionalidades do sistema e da sua implementação;
• a engenharia avante é o desenvolvimento normal do sistema, criando o aplicativo propriamente dito em uma linguagem de programação orientada a objetos.
Segundo Chikofsky e Cross (1990, apud MORAIS, 2003), a reengenharia de
software é uma análise para a alteração de um sistema e reconstruí-lo em outra linguagem de
programação, podendo alterar funcionalidades e adicionar outras, empregando a engenharia reversa, para identificar o maior número possível de artefatos do sistema e seus interrelacionamentos.
Penteado (1996) destaca três cenários para a reengenharia, relacionados abaixo: 1. trocar a implementação sem perda da funcionalidade;
2. troca parcial da implementação sem perda da funcionalidade; 3. troca da funcionalidade.
Yourdon e Constantine (1978, apud PENTEADO, 1996, p. 52) definem engenharia reversa como um conjunto de teorias, métodos e tecnologias de apoio ao projeto, implementando um processo de extração de informações de um software existente, produzindo a documentação necessária de acordo com o código existente.
Chikofsky e Cross (1990 apud BOSSONARO) definem a engenharia reversa como sendo um processo para analisar um sistema, identificando seus componentes e interrelacionamentos, para criação de representações desse sistema em outra forma ou em um nível mais alto de abstração.
Para Morais (2003), a engenharia reversa, orientada a objetos, possibilita a recuperação de um modelo de análise, partindo do código fonte do sistema antigo. Esse modelo será usado na engenharia avante como complemento no processo de reengenharia orientada a objetos.
Ré (2002) declara, em sua tese, que “um processo de engenharia reversa baseada, na interface Web, é conduzido para esses sistemas-base, visando a produzir a especificação de requisitos e, por intermédio dessa especificação, criar um modelo de classe do domínio”. A Figura 11 representa o processo de engenharia avante x engenharia reversa.
