DE SOFTWARE

Universidade Federal de Pernambuco Centro de Informática

Pós-Graduação Stricto Sensu em Ciência da Computação

UMA ABORDAGEM CONCEITUAL A EVOLUÇÃO DOS REQUISITOS DIANTE DOS DESAFIOS DA ENGENHARIA

DE SOFTWARE

PAULO HENRIQUE RAMOS

RECIFE Março/2011

PAULO HENRIQUE RAMOS

UMA ABORDAGEM CONCEITUAL A EVOLUÇÃO DOS REQUISITOS DIANTE DOS DESAFIOS DA ENGENHARIA

DE SOFTWARE

Monografia apresentada ao Curso de Mestrado em Ciência da Computação, do Centro de Informática (CIn), da Universidade Federal de Pernambuco (UFPE), como requisito parcial de avaliação da disciplina de Engenharia de Requisitos, sob a orientação do Professor Jaelson Freire B. de Castro.

RECIFE Março/2011

RESUMO

É evidente a atenção que os profissionais de TI têm dado a evolução dos requisitos nesses últimos anos, tal tema é interligado a Engenharia de Software, tendo como objetivo a busca por soluções para amenizar os problemas que os projetos enfrentam durante o processo de desenvolvimento e posteriormente em melhorias que o software irá necessitar no futuro. É comum que o processo evolutivo necessite de uma estruturação bem definida e segura, pois, isso permite uma total segurança para todos os envolvidos no projeto. Logo, a manutenção futura do software dependerá da estruturação bem elaborada do projeto, assim as possíveis melhorias serão realizadas da maneira mais objetiva possível. No entanto, a manutenção deverá seguir uma padronização, que por sua vez busca atrelar o projeto a uma base de sustentação, com a finalidade de gerar garantias nos projetos, a fim de elencar de uma forma coesa tais necessidades. Pois, quando uma empresa contrata os serviços de uma fábrica de software, ela tem a intenção de solucionar os seus problemas, e também quer a segurança das suas informações, de uma forma que, caso seja necessária a implementação de novas funcionalidades, a empresa responsável realize as seguintes melhorias, adequando assim, o software as necessidades do mercado.

Palavras-chave: Evolução dos Requisitos; Tecnologia da Informação;

Engenharia de Software; manutenção; segurança.

Clearly the attention that IT professionals have given the evolution of requirements in recent years, this theme is linked to Software Engineering, having as objective thesearch for solutions to alleviate the problems faced during the project development process and subsequently improvements in the software will require in the future. It iscommon that the evolutionary process requires a well- defined structure and safe,because this allows a total security for all involved in the project. Therefore, the future maintenance of the software will depend on the elaborate structure of the project, so the possible improvements will be made more objective way possible. However,maintenance should follow a

pattern, which in turn seeks to link the project to a supportbase, in order to generate projects in guarantees in order to list in a cohesive way those needs. For when a company engages the services of a software factory, she intends tosolve their problems, and also wants the security of your information in a way that, ifnecessary the implementation of new

features, the company responsible perform

thefollowing improvements, adjusting so the software market needs.

Keywords: Evolution of Requirements, Information Technology, Software

Engineering, maintenance and security.

LISTA DE FIGURAS

Figura 1 : Principais erros cometidos, durante o processo de

desenvolvimento ... 11

Figura 2: Custo para correção de falhas ... 12

Figura 3: Custo com a manutenção de software ... 17

Figura 4: Fluxo envolvido na manutenção de software ... 18

Figura 5: Curva de esforço para manutenção de software ... 19

Figura 6: Ciclo de vida de manutenção de software ... 19

Figura 7: Estruturação da norma ISSO/IEC 12207 ... 24

Figura 8: Processos do ciclo de vida da norma ISSO/IEC 12207 ... 24

Figura 9: Atividades do processo de manutenção de software e sistema (ISSO/IEC 12207) ... 25

1 INTRODUÇÃO... 7

2 ENGENHARIA DE SOFTWARE... 9

3 EVOLUÇÃO DOS SOFTWARES... 14

3.1 A MANUTENÇÃO DOS SOFTWARES DIANTE DO PROCESSO EVOLUTIVO... 15

3.2 PRINCIPAIS NORMAS DE PADRONIZAÇÃO... 23

4 CONCLUSÃO... 27

5 GLOSSÁRIO... 30

6 REFERÊNCIAS... 31

1. INTRODUÇÃO

O presente estudo tem como principal finalidade realizar uma abordagem conceitual da evolução dos requisitos de software diante do crescimento que se tem presenciado ao longo dos anos na área de Engenharia de Software. Assim, observa- se toda a sua complexidade, além de se estabelecer como um modo de compreender os respectivos aspectos que permeiam a evolução dos requisitos de software.

Diante de todas as problemáticas que estão implicadas na evolução dos requisitos de software, percebemos a necessidade de uma abordagem mais detalhada de tal assunto, com o intuito de esclarecer e apresentar soluções concretas, tendo em vista a importância de tal metodologia perante o processo de elaboração dos requisitos de software, desta forma, atrasos e inconsistências futuras poderão ser evitados, proporcionando assim uma segurança no desenvolvimento de um dado projeto.

Buscando ainda um melhor entendimento sobre a evolução dos requisitos, trazemos alguns autores que procuram esclarecer os conceitos dessa temática, diante dos processos evolutivos das mesmas.

Assim, Araújo e Dias (2010) procuram esclarecer o que realmente vêm a ser a evolução dos requisitos, quando ele afirma que a “evolução dos processos de Engenharia de Requisitos, começa-se com a elicitação dos requisitos de usuário e a especificação dos requisitos de negócio para realizar um estudo de viabilidade”

(ARAÚJO; DIAS, 2010, p. 15).

Segundo Breitman (2000), “o desenvolvimento de sistemas de software é uma atividade complexa que envolve um grande número de recursos, coordenados de modo a atingir um mesmo objetivo” (ibidem, p. 32).

Em decorrência dessas especificações dos requisitos, Filho (2000) afirma que “a necessidade de desenhar e planejar para a revolução se faz presente na grande maioria dos projetos de software” (ibidem, p. 61). Deste modo, as abordagens citadas anteriormente pelos autores Araújo, Dias (2010), Breitman (2000) e por último Filho (2000), apenas confirmam tal necessidade diante das

circunstâncias encontradas ao longo da elaboração dos projetos. Assim, a evolução dos requisitos se torna um desafio impactante perante o mercado atual de TI.

É importante salientar a pluralidade dos aspectos positivos que repercutem sobre a Engenharia de Requisitos, nesse sentido percebemos as diversidades existentes no processo de evolução dos requisitos, ou ainda, elencar tais metodologias diante dos desafios propostos. No entanto, há sempre visões plurais e conflitivas quando se fala em Engenharia de Requisitos, assim nas seções subseqüentes é realizado um possível detalhamento onde tentaremos fazer esclarecimentos, detalhamentos e conclusões.

Segundo Pressman (2006), atualmente o software assume um duplo papel, no qual ele se define como um produto, ao mesmo tempo em que funciona como um veículo para entrega do produto, logo o software funciona como um transformador de informações, não importando em que tipo de tecnologia o mesmo funcione – atualmente temos como exemplo os sites de compra eletrônica, que necessitam ter uma portabilidade para o seu correto funcionamento, atendendo assim os mais variados tipos de clientes e consequentemente uma variedade de equipamentos eletrônicos que estão aptos acessar essas informações.

Dependendo da sua característica operacional, um determinado software poderá ser à base de um computador ou até mesmo a base de sustentação de uma empresa, visto que todas as informações da mesma se encontram em um banco de dados.

É perceptível que ao longo desses últimos 50 anos a evolução dos softwares obteve um crescimento significativo, isso se deve a uma série de fatores, que se iniciam com a arquitetura de computadores – memórias, processadores e mídias de armazenamentos que ao longo dos anos foram sendo aperfeiçoados, iniciando assim, uma geração de softwares bem mais dinâmicos, sofisticados e objetivos.

A verdade é que o programador solitário que em meados da década de 90 era tido como algo fora de moda, não foi extinto, e sim foi contemplado com a chegada de outros profissionais, ou seja, o programador teve o seu trabalho minuciosamente subdividido em partes, onde a figura de outros profissionais foi sendo adicionada, de uma maneira progressiva, que cada um exercesse a sua

função na empresa de desenvolvimento, realizando assim o seu devido papel na fábrica de software.

Logo, o antigo programador que a princípio era analista de sistema, gerente de projetos, realizava os testes necessários no software antes da implantação na empresa contratante, entre outras funções, passou a trabalhar exclusivamente com a parte de desenvolvimento do software, deixando os demais processos para os especialistas da área de tecnologia.

A verdade é que o programador solitário não foi extinto, ele apenas passou por um processo de melhoria na sua profissão, por conta do alto nível de complexidade que os softwares passaram a ser desenvolvidos, que por sua vez passaram por essas melhorias em virtude do alto nível de exigência dos clientes.

Após essas mudanças, outras problematizações iniciaram, pois, como a demanda pelo desenvolvimento de software utilizando novos métodos obteve um aumento considerável nos últimos anos, a quantidade de problemas como usabilidade e portabilidade se tornaram algo corriqueiro na última década, devido ao alto nível de complexidade dos softwares.

O uso dessas novas metodologias para auxiliar os profissionais de TI durante o processo de desenvolvimento de software começou a exigir documentações e análises de sistemas bem mais detalhados, proporcionando assim, um alto índice de satisfação dos clientes.

2. ENGENHARIA DE SOFTWARE

Diante da abordagem realizada neste estudo dentro da área de Engenharia de Software, é perceptível a necessidade de utilizar a Engenharia de Requisitos na área de desenvolvimento de projetos de pequeno, médio e grande porte, pois a segurança que é firmada com o uso dessas metodologias solidificam assim, o processo de fabricação do software, tornando-se imprescindível o uso de tais métodos.

Para Pressman (2006) a importância de softwares para os computadores foi algo não previsto a décadas passadas, quando ele enfatiza que:

Hoje, o software de computadores é a tecnologia única mais importante no palco mundial. É também um importante exemplo da lei das conseqüências não pretendidas. Ninguém na década de 1950 poderia ter previsto que o software fosse se tornar uma tecnologia indispensável para negócios, ciência e tecnologia. (ibidem, 2006, p.

01)

Engana-se o profissional de Engenharia de Software, que tem o pensamento retrógrado, no qual segundo ele não é necessário perder tempo desenvolvendo uma documentação do software, afinal, todos os requisitos e levantamentos não estão armazenados em nenhum disco físico propriamente dito, profissionais com tal característica, tendem a serem extintos em um futuro não muito distante, por causa do mercado competitivo do qual eles estão inseridos, assim como, a necessidade que as empresas contratantes têm com a segurança dos seus projetos, ou seja, a empresa responsável pelo desenvolvimento de softwares, que não se adequar as novas metodologias, será considerada inviável para os padrões da atualidade.

Atualmente é comum que empresas desenvolvedoras de software, realizem a documentação completamente de seus sistemas, visando assim, alterações, melhorias e aperfeiçoamentos futuros, deste modo, podemos definir tal iniciativa, como uma padronização, na qual tem por finalidade satisfazer a empresa contratante e consequentemente facilitar o cotidiano dos desenvolvedores.

A ausência da padronização pode gerar algumas consequências nada animadoras para os envolvidos nos projetos, como o aumento no custo do software, que pode ocasionar a desistência do projeto por parte da empresa contratante, estimativa de tempo de desenvolvimento insuficiente, trazendo assim prejuízo para a empresa contratada.

Para melhor compreensão de tais problematizações, sobre os principais problemas encontrados durante a elaboração e / ou desenvolvimento, de um software, caso uma documentação objetiva não seja feita por parte da empresa contratada, observe abaixo a figura 1, que descreve a afirmativa.

0 5 10 15 20 25

Falta de Especificação do Usuário Requisitos Incompletos Mudança de Requisitos Falta de Apoio Executivo Tecnologia Imatura Falta de Recursos Expectativas Irreais Objetivos obscuros Tempo irreal Tecnologia Nova Outros

Figura 1 – Principais erros cometidos, durante o processo de desenvolvimento.

Fonte - Meira (2008)

Segundo Araújo e Dias (2010), o valor gasto para que um determinado defeito seja corrigido durante a fase de testes pode ser superior a 30 vezes o custo inicial, caso essa mesma falha seja corrigida durante o processo de levantamento dos requisitos, ou seja, se tal erro for detectado inicialmente, a economia será bem significativa, além do tempo que não seria desperdiçado. Assim, os principais meios de evitar tais falhas é o uso de padronização, a realização de inspeção e as respectivas revisões das DERS.

No entanto, para Pressman (2002 apud MEIRA, 2008) o valor para a correção é inferior, porém, o custo vai aumentando gradativamente conforme a fase de desenvolvimento avança, assim:

O custo de correção de defeitos na fase de projeto é cerca de três a seis vezes mais alto do que na fase de definição de requisitos. E este custo aumenta ainda mais quando a correção de defeitos é realizada em fases mais avançadas do processo de desenvolvimento, como a fase de teste (ibidem, p.9).

Abaixo na figura 2, o gráfico explica de uma forma mais detalhada o custo que se tem com as possíveis correções de falhas, de imediato, é perceptível que os custos na fase de testes sejam superiores, quando comparado a fase de requisitos, fase de projeto e fase de codificação, deste modo, essa interpretação apenas ratifica o que os autores afirmaram nos parágrafos anteriores, quando Araújo e Dias (2010), atenta para o alto custo que um defeito poderá proporcionar, caso o mesmo não seja detectado na fase inicial do projeto, seguindo o mesmo raciocínio Pressman (2002 apud MEIRA, 2008), enfatiza tal problemática, que os custos terão um aumento considerável em fases mais avançadas.

Ou seja, um projeto mal elaborado na sua fase inicial, poderá sofrer consequências gravíssimas no futuro na sua parte financeira, ocasionando assim contratempos desnecessários que poderiam muito bem ser evitado durante a sua concepção ou ao menos reduzir ao menor índice de falha possível.

Figura 2 – Custo para correção de falhas Fonte – Araújo e Dias (2010)

De acordo com as diversas abordagens podemos citar Araújo e Dias (2010), que usam como referência o IEEE (Institute of Electrical and Electronics Engineers), onde os DERS deverão ser completos e não ambíguo, sendo assim, responsáveis por auxiliar os clientes de software na descrição das necessidades que os mesmos desejam cessar, e consequentemente que os desenvolvedores de softwares compreendam as respectivas necessidades do cliente.

Dentre outras características, uma das principais finalidades da Engenharia de Requisitos é a elaboração do DERS, que busca descrever as necessidades do usuário, para que se possa iniciar o desenvolvimento do projeto solicitado.

Ao término dos levantamentos, é preciso uma avaliação dos stakeholders que estão envolvidos no projeto, onde o foco principal é ter a certeza que os interesses de ambas as partes estão caminhando em harmonia, o que não quer dizer que não exista nenhum erro, a verdade é que os erros descobertos nessa fase custam um valor bem menor se comparados aos custos em etapas subsequentes do projeto (ARAÚJO; DIAS, 2010).

3. EVOLUÇÃO DOS SOFTWARES

Ao finalizar a implantação de um software, muitos profissionais e usuários têm o pensamento que tudo está concluído, e que nada mais vai ser necessário fazer ao longo dos tempos, esse pensamento é totalmente contrário ao cenário atual do mercado de TI.

Sabemos que o processo evolutivo do campo tecnológico é evidenciado no mercado atual, pela sua dinamicidade constante e pelas melhorias que são solicitadas quase que diariamente aos profissionais de TI. Desta maneira, ao término de uma implantação de um determinado software em uma empresa, o processo administrativo do mesmo estará apenas na sua fase inicial, pois, além das possíveis alterações que com o tempo serão solicitadas pelos usuários, virá também algo de extrema importância e intrínseco a continuidade do projeto, ou seja, a confiabilidade dos dados da empresa.

O processo evolutivo possui diversas ramificações, que tem como principal finalidade a evolução dos processos que tem como fator chave “a estruturação adequada dos componentes, voltada à facilidade de manutenção” (LEITE; SAYÃO;

STAA, 2003, p. 4). Ou seja, um projeto bem elaborado e consequentemente com uma estruturação bem lapidada, irá facilitar o processo de manutenção do software, pois, quando os usuários necessitarem de melhorias, aperfeiçoamentos ou de mudanças não sentirão dificuldades para realizar as devidas solicitações.

Por que todo sistema necessariamente sofre alterações ao longo da sua vida útil, pois, é pouco provável que desenvolvam um sistema que não precise de mudanças com uma certa periodicidade, caso isso aconteça, com o passar dos tempos o sistema vai ser considerado um sistema legado. Para melhor compreensão sobre essas questões, Araújo; Souza; Vale, (2010) fazem a seguinte colocação sobre tais indagações feitas por alguns profissionais e usuários:

Os sistemas geralmente refletem situações do mundo real e, com isso, há uma necessidade que o software mude acompanhando as mudanças de requisitos impostos pelo ambiente em que está

inserido. Se o sistema não sofre essas mudanças, pode ficar obsoleto e cair em desuso (ibidem, p. 20).

Portanto, fica extremamente perceptível que a manutenção de software é algo imprescindível para a continuidade da vida útil de um sistema. Portanto, chegamos ao entendimento que um software poderá sim envelhecer, e que na verdade é um processo inevitável, no entanto, sendo compreendidos, através de previsões, os efeitos que o mesmo poderá sofrer de uma forma negativa, em um futuro não muito distante, será reduzido de uma maneira considerável (ARAÚJO;

SOUZA; VALE, 2010).

Ainda segundo os mesmos autores, as mudanças ao longo dos anos poderão ser divididas em duas vertentes:

Quando as mudanças necessárias não são implementadas e o sistema não é adequado às novas regras de negócio utilizadas, e a segunda é quando as adaptações são feitas de maneira desordenada e acarretam problemas para o sistema como um todo, gerando novos erros e diminuindo sua manutenibilidade (ARAÚJO;

SOUZA; VALE, 2010, p. 20).

3.1 A Manutenção dos softwares diante do processo evolutivo

É natural a rotatividade na parte de manutenção do software, essa busca periódica e constante por melhorias se faz necessária, pois a ausência dessa manutenibilidade permite que o software ocioso, monótono e consequentemente com um desempenho abaixo do esperado, e se comparado a outros concorrentes, logo estará ultrapassado.

Diante das perspectivas que desafiam a Engenharia de Software, “a evolução de software compreende as mudanças que irão ocorrer em um programa a fim de deixá-lo completo e, se possível, livre de erros” (SOMMERVILLE, 2003 apud ARAÚJO; SOUZA; VALE, 2010, p. 20).

O processo evolutivo necessita de algumas particularidades, que por sua vez ditarão a real necessidade de mudanças do software, deste modo, após a análise

minuciosa, se chegará a um resultado que irá determinar o processo de evolução do software ou o completo abandono do mesmo, nesse caso, a melhor iniciativa será a projeção de um novo software utilizando a base nos requisitos dos softwares atuais, que por sua vez estão completamente aptos para funcionarem nos novos padrões de TI, seja na parte da arquitetura de computadores ou na base operacional. Os principais fatores são: custos, confiabilidade, capacidade de mudanças, desempenho e limitações (ARAÚJO; SOUZA; VALE, 2010).

Segundo Araújo; Souza; Vale (2010), as principais atividades de manutenção de software são divididas de acordo com as necessidades das empresas.

Apresentamos abaixo tais atividades, com uma breve descrição individual de cada atividade, visto que um aprofundamento mais extenso das mesmas necessitaria de um estudo mais específico para o dado assunto.

Manutenção Corretiva – É responsável pelo tratamento de erros emergenciais de uma determinada funcionalidade;

Manutenção Adaptativa – Se encarrega em alterar um software, para que o mesmo se adapte a um novo ambiente externo;

Manutenção Perfectiva – Permite a adição de novos requisitos, realizando assim, a inserção de novas funcionalidades;

Manutenção Preventiva – Sua principal finalidade é aumentar o seu grau de confiabilidade e manutenibilidade.

Pressman (2003 apud ARAÚJO; SOUZA; VALE, 2010) ressalta que “a manutenção de software pode ser responsável por mais de 70% de todo o esforço despendido por uma organização”. No entanto, esse valor tende a uma ascendente considerável à medida que o desenvolvimento vai aumentando. Na figura 3, o gráfico demonstra de uma forma mais objetiva a afirmativa de Pressman (2003), que busca esclarecer o esforço desperdiçado ao longo do desenvolvimento do software.

Figura 3 – Custo com a manutenção de software.

Fonte – Araújo; Souza; Vale (2010).

Paduelli (2009) utiliza como referência o IEEE (1998), quando se refere às atividades de manutenção de software, onde a caracterização dada pelas alterações de um produto de software que já foi entregue ao cliente, no entanto, sofrerá algumas modificações por conter determinados erros. Porém, essas correções proporcionarão um melhor rendimento do software, outros fatores como mudança de plataforma também poderá de encaixar perfeitamente nessa manutenção.

Ainda segundo Paduelli (2009), devemos levar em consideração os tipos diversos de software – sejam para a web ou desktop, no entanto, não como uma atividade individual, pois, durante o funcionamento das interações deverão ser realizadas com diversas partes, onde uma interação se faz necessária para que os objetivos sejam solucionados, para Polo et al. (1999 apud PADUELLI, 2009), esses tipos de atividades necessitam das seguintes partes: organização, mantenedor e usuário.

Em contrapartida Polo et al. (1999 apud PADUELLI, 2009) relata que há um relacionamento entre as partes e consequentemente a constituição de um dado fluxo para a execução dos pedidos de manutenção, apresentamos abaixo a figura 4, na qual ela mostra de uma maneira mais detalhada o funcionamento de tal atividade.

Figura 4 – Fluxo envolvido na manutenção de software.

Fonte – Paduelli (2009) - (Adaptação Polo et al. 1999)

Como diferenciar uma falha de um defeito em um determinado software?

Essa é uma pergunta bastante ouvida pelos usuários que utilizam um software diariamente e que necessitam de melhorias constantemente, segundo Pressman (2005 apud PADUELLI, 2009), um dado defeito é composto por uma anomalia do produto propriamente dito, ao encontro que uma falha tem como significado um dispositivo ou componente com defeito, lembrando que essa visão sistemática está associada ao contexto de hardware.

Em contrapartida, quando falamos de contexto de software, ambos os termos – falha e defeito seguem os mesmos princípios, ou seja, referem-se a algum problema de qualidade, que por sua vez, será descoberto apenas após a implantação do mesmo na empresa contratante.

Sabemos do tempo gasto com atividades de manutenção de software, para melhor entendimento, apresentamos abaixo a figura 5 que confirma tais afirmativas, caracterizando de uma forma objetiva os momentos de extremo esforço, que na maioria das vezes é proporcionado por fatores externos ao que é realmente de costume no cotidiano dos profissionais de TI.

Figura 5 – Curva de esforço para manutenção de software Fonte – Paduelli (2009) - (Adaptação de Bhatt et al. 2004)

Já para Kung e Hsu (1998 apud PADUELLI, 2009), a manutenção de um software possui um determinado ciclo de vida, onde ele procura enfatizar as seguintes fases: introdução, crescimento, maturidade e declínio, de uma maneira que as fases indiquem individualmente o tipo de tarefa que será mais incidente durante o ciclo, na figura 6, visualizamos de uma forma mais detalhada tais fases.

Figura 6 – Ciclo de vida de manutenção de software.

Fonte – Paduelli (2009) - (Adaptação de Kung & Hsu, 1998)

Ainda segundo Paduelli (2009), não é possível definir um tempo exato para que o software inicie a sua fase de declínio, essa afirmativa é confirmada quando o mesmo relata a seguinte definição:

Quanto tempo o software vai levar para entrar na fase de declínio é uma previsão quase impossível, visto que, uma vez na fase de maturidade, o software adquiriu certa estabilidade na organização, possivelmente já se enquadrando na classificação do sistema legado (ibidem, p.11).

Por essas e outras definições abordadas sobre o tema, nos permite o esclarecimento sobre a vida útil de um software, assim como, os problemas que ocorrerão quando a fase de mudanças se iniciarem, de uma maneira que o mesmo poderá enfrentar resistências por parte dos usuários, por conta de seu legado dentro da empresa.

É correto afirma que boa parte dos sistemas de tráfego aéreo continua operando com os sistemas que foram desenvolvidos nas décadas de 60 e 70, essa continuidade se deve a uma série de fatores que é abordada por Sommerville (2007) quando ele fala que:

Devido ao tempo e esforço necessários para desenvolver um sistema complexo, os sistemas de grande porte baseados em computadores têm vida longa. Sistemas militares, por exemplo, geralmente são projetados para durarem 20 anos e a maioria dos sistemas de controle de tráfego aéreo do mundo ainda conta com software e processos operacionais originalmente desenvolvidos nas décadas de 1960 e 1970 (ibidem, p. 25).

Para Swebok (2004 apud PADUELLI, 2009), o processo de manutenção de software se explica como uma operação de extrema importância, pois, boa parte dos custos se engloba no ciclo de vida de um software, e caso não haja habilidade durante o processo de mudança do software com certa rapidez e consequentemente com confiabilidade, causará uma perda de oportunidades de negócios

consideravelmente alta para a empresa Bennett & Rajlich, (2000 apud PADUELLI, 2009).

Essas afirmativas são concretizadas, quando Pressman (2005 apud PADUELLI, 2009), reforça que “o grande esforço necessário na manutenção se justifica pela abrangência do significado desse termo no contexto de software”.

Enquanto que Sommerville (2007) retrata que boa parte dos projetos utiliza o reuso de software nos seus projetos, logo, essa abordagem se solidifica por conta que as pessoas envolvidas nesse trabalho, possuem um conhecimento do projeto ou nos códigos existentes, dessa forma:

Esse reuso informal ocorre independentemente do processo de desenvolvimento usado. No entanto, nos últimos anos, uma abordagem para desenvolvimento de software, denominada engenharia de software, baseada em componentes (CBSE – Component-Based Software Engineering) e que conta com reuso, tem emergido e se tornado cada vez mais utilizada (ibidem, p. 46).

Paduelli (2009) relata que tais processos são mais que necessários quando entra em cena o quesito importância financeira, pois, o mesmo está atrelado com a manutenção de software podendo ser agravada quando se leva em consideração o risco para as possíveis oportunidades de negócio, que podem sofrer consequências por conta da falta de gerenciamento e compreensão total da dinâmica da atividade.

Uma pesquisa realizada por Dart et al. (2001 apud PADUELLI, 2009), relata que esse gerenciamento relaciona-se com três fatores de extrema importância, são eles, ferramentas, pessoas e por fim os processos, desta maneira, a complexidade da atividade gerencial surge com a finalidade de gerar benefícios para todos os profissionais envolvidos no projeto.

Segundo Paduelli (2009) a verdade é que as empresas necessitam de tal desafio – atividade de manutenção, no entanto, é fato também que o tempo desperdiçado com essa atividade é bem desafiador.

No entanto, é impraticável a visão que um determinado cliente modifique toda a sua base de TI – sistema / software, por conta de uma nova tecnologia que esteja fora dos padrões da atualidade.

Para Sommerville (2003 apud PADUELLI, 2009), esses sistemas representam ativos importantes da organização e ela estará disposta a investir de maneira a manter seus valores. Bhatt et al., (2004 apud PADUELLI, 2009), reforça que o crescimento no quesito complexidade dos softwares que são produzidos – em ambas as partes, funcional ou técnico, proporciona assim uma previsão vaga sobre os esforços de manutenção, em contrapartida, quando se trata de sistemas legados essa estimativa de esforços fica mais evidente.

3.2 Principais normas de padronização

A manutenção de software segue princípios, ou seja, uma padronização definida por um determinado comitê, que por sua vez, são estabelecidas normas, na qual tem a finalidade de organizar os processos durante o ciclo de vida de um dado software. Paduelli (2009) realiza uma definição sobre a finalidade de um comitê perante os princípios que devem ser seguidos, ao abordar o tema em um dos seus trabalhos ele relata que:

Dentre os objetivos do comitê estava o estabelecimento de um padrão para processos de ciclo de vida de software, que culminou com a norma ISSO/IEC 12207, que teve início em 1989. Esta norma deveria ser estabelecida como um framework adaptável, que pudesse ser usado para auxiliar na gerência e na construção do software (ibidem, p. 13).

Ainda segundo Paduelli (2009), o objetivo da utilização de tais normas, tem por finalidade reunir um conjunto de processos de engenharia de software, que a empresa em questão deverá usar durante tais processos, para que a mesma possa adquirir, fornecer, desenvolver ou manter o software em questão, onde tal afirmativa apenas confirma a documentação dos processos do ciclo de vida do software, ao utilizar-se do modelo de referência desses processos. Na figura 7 abaixo, observamos como funciona a organização citada no texto.

Figura 7 - Estruturação da norma ISO/IEC 12207 Fonte – Paduelli (2009)

Segundo a norma ISO/IEC 15504 apud Paduelli (2009), a figura 8 a seguir, demonstra como funciona a organização da norma. Lembrando que num total de três categorias, que por sua vez se totalizam em dez grupos de processos com um total de 47 processos.

Figura 8 - Processos do ciclo de vida da norma ISO/IEC 12207.

Fonte – Paduelli (2009)

Segundo a norma, a manutenção de software funciona como um dos processos que se encaixam dentro da categoria de processos fundamentais, assim, podemos observar tal afirmativa na figura 9, onde a mesma relata as principais atividades que fazem parte de tal processo (PADUELLI, 2009, p. 14).

Figura 9 - Atividades do processo de manutenção de software e sistema (ISO/IEC 12207).

Fonte – Paduelli (2009)

O que não podemos deixar passar despercebido é quanto ao processo de desenvolvimento de software, ou seja, os relacionamentos prováveis entre a qualidade de processo e do produto possuem um nível de complexidade bem considerável, tal afirmativa é reforçada por Sommerville (2007), quando o mesmo pontua o seguinte relato:

No desenvolvimento de software, portanto, o relacionamento entre qualidade de processo e qualidade de produto é mais complexo. É difícil medir os atributos de qualidade de software, como facilidade de manutenção, mesmo após o uso do software por um longo período (ibidem, p. 425).

Paduelli (2009), define que a implementação de um processo deve iniciar-se na fase inicial do ciclo de vida do software, deste modo Pigoski (1996 apud

PADUELLI, 2009) reafirma que o planejamento da manutenção deve ser preparado em paralelo com os planos de desenvolvimento, onde deverá ser definido o escopo de manutenção e consequentemente a identificação e as possíveis análises que servirá de alternativas, e por fim realizar a organização e contratação da equipe responsável pela manutenção, de uma maneira que relacione os devidos recursos com as respectivas responsabilidades.

Diante dessas colocações, chegamos um ponto bastante abordado na área de Engenharia de Software e suas ramificações ao falarmos de software, trata-se de sistemas legados ou como alguns autores escrevem software legado. Perguntas e indagações são pertinentes por tal problemática, no entanto, uma definição permite o pleno entendimento do tema em questão. Assim como foi abordado anteriormente nesse trabalho, quando se usa como exemplo os sistemas de tráfego aéreo, que ainda trabalham com softwares da década de 60 e 70.

Para Visaggio (2001 apud PADUELLI, 2009), “um sistema legado normalmente representa um dos bens com maior valor econômico de uma organização”, logo, qualquer que seja o tipo de mudança que venha a ser realizada na empresa / organização, terá consequências significativas, por conta do longo tempo de uso do mesmo software dentro da empresa.

Para Paduelli (2009), as possíveis variações que poderão ocorrer durante o processo de mudanças são o risco em substituir um software que seja estável, a familiaridade que os usuários têm com o software, ou seja, o hábito pelo longo tempo de uso, logo, alguns usuários rejeitam qualquer tipo de alteração que venha a acontecer em torno do software, qualquer que seja o tipo da mudança, irá proporcionar gastos com treinamentos de todos os usuários, e caso cheguem a uma conclusão que a melhor alternativa é o desenvolvimento de um novo software, o mesmo poderá ultrapassar a previsão de entrega e custos, e por fim, o novo software poderá ter uma quantidade de funcionalidades menor que o anterior, o que vem a ser um agravante para a realização de certas tarefas por parte dos usuários.

Para Sommerville (2007), o processo de avaliação de um sistema legado funciona da seguinte forma:

Ao avaliar um sistema legado, você deve observá-lo do ponto de vista dos negócios e da perspectiva técnica (Warren, 1998). Do ponto

de vista de mercado, você precisa decidir se a empresa realmente precisa do sistema. Da perspectiva técnica, você precisa avaliar a qualidade do software da aplicação e o software e hardware de apoio ao sistema (ibidem, p. 334).

.

4. CONCLUSÃO

O principal objetivo das empresas responsáveis pelo desenvolvimento de sistemas é a satisfação do cliente que contratou seus serviços, no entanto, é fato que o processo de implantação de um sistema não se limita ao término da implantação do mesmo.

Logo, os processos subsequentes são de extrema importância para a durabilidade do sistema e que futuras mudanças sejam realizadas de uma forma organizada, objetiva e coesa, visto que alterações é algo inevitável quando falamos de sistemas, pois diante do mundo globalizado do qual fazemos parte, sabemos da importância de nos mantermos preparados para tais desafios.

Por isso, são perceptíveis os benefícios que geram a utilização dessas normas de padronização, pois, durante o processo de desenvolvimento de um sistema, é extremamente necessária uma solidificação do que foi acordado entre ambas as partes – cliente e a fábrica que desenvolverá o sistema.

Objetivando uma parceria duradoura entre os envolvidos com o sistema, assim é de grande interesse que ambas as partes estejam cientes da necessidade que uma documentação esclarecedora de todo o sistema seja desenvolvida, onde a finalidade é a confiabilidade que a empresa contratante deverá ter junto a empresa contratada como garantia, diante dos desafios que o mercado de TI irá proporcionar.

Vimos durante a presente revisão de literatura, que o processo evolutivo que os softwares vêm sofrendo nesses últimos anos tem como finalidade o melhoramento das práticas da Engenharia de Software, na verdade esse processo evolutivo não é atual, ele apenas tem sofrido melhorias nesses últimos anos, assim como tem aumentando o índice de profissionais de TI que são adeptos a essas novas metodologias.

Portanto, os diversos autores citados durante o desenvolvimento deste trabalho, objetivam o presente estudo com a utilização de métodos e ferramentas que definem, exemplificam e solidificam a Engenharia de Software e as suas

ramificações, onde a principal finalidade é a busca por melhorias e redução de erros que venham a surgir em outras etapas do projeto, que sendo evitadas ou minimizadas no início, têm grandes chances de terem os custos reduzidos nas fases subsequentes.

Assim, os assuntos abordados durante esse trabalho é fruto de pesquisas, trabalhos relacionados, livros e experiências vivenciadas pelos diversos profissionais da área de TI, e também dos profissionais da área administrativa das empresas, que por ter o importante papel de realizar as melhores contratações tanto no campo administrativo, quanto na área de TI, estão plenamente embasados a participarem dessas decisões do campo tecnológico da empresa, pois a visão que os mesmos têm não se restringe apenas a área administrativa.

Por fim, o presente estudo não encerra as discussões e as possíveis melhorias futuras que a área de Engenharia de Software necessita com esse trabalho, a intenção é que tal assunto continue em constantes pesquisas, buscando sempre aperfeiçoamentos, melhorias e com uma visão global sobre a Engenharia de Software, a Engenharia de Requisitos, os softwares legados, a evolução dos softwares, as manutenções necessárias, assim como as possíveis melhorias dentro do processo de manutenção, as principais normas de padronização existentes e as possíveis melhorias que as mesmas poderão vir a sofrer futuramente.

GLOSSÁRIO

Stakeholders – Pessoa ou grupo que possuem interesses em determinadas ações e desempenho de uma empresa.

http://www.knoow.net/cienceconempr/gestao/stakeholder.htm

IEEE – Instituto de Engenheiros Eletricistas e Eletrônicos, um de seus papéis mais importantes é o estabelecimento de padrões para formatos de computadores e dispositivos.

http://pt.wikipedia.org/wiki/Instituto_de_Engenheiros_Eletricistas_e_Eletr%C3%B4nicos

DERS – Documento de Especificação de Requisitos de Software.

Software – É um segmento de comandos executados, manipulados, redirecionados, modificados ou seguidos gerando a alteração de uma informação (dado) ou evento.

http://www.compfixhd.com.br/software

TI – Tecnologia da Informação.

Engenharia – A engenharia é a ciência agregada ao esforço para empreender resultados tácitos ou não.

http://www.artigonal.com/carreira-artigos/engenharia-1264207.html

CBSE – Component-Based Software Engineering - Engenharia de Software Baseado em Componentes

Desktop – É a denominação dado basicamente ao gabinete com os acessórios internos como processador, cooler, placa-mãe, fonte de alimentação, discos rígidos, CD-ROM, Gravador de CD, Leitor de DVD, Gravador de DVD.

http://www.trofia.com/informatica/desktop-conceito

Web – Sistema de interligação de documentos e recursos através da Internet.

http://www.priberam.pt/dlpo/definir_resultados.aspx?pal=web

REFERÊNCIAS

ARAÚJO, Marco Antônio Pereira. DIAS, Nauane Karoline Brazolino. Boas práticas na engenharia de requisitos. Revista Engenharia de Software. Ed. 27. Ano 3.

2010, p. 14 – 21. Disponível em <http://www.devmedia.com.br/> Acesso em: 06 ago.

2010.

______. VALE, Ricardo Cunha. SOUZA, Vinícius Rodrigues de. O papel evolutivo do software – conceitos básicos sobre manutenção e evolução do software. Revista Engenharia de Software. Ed. 28. Ano 3. 2010, p. 19 – 25. Disponível em

<http://www.devmedia.com.br/> Acesso em: 16 set. 2010.

BREITMAN, Karin Koogan. Evolução de Cenários. 2000. Tese de Doutorado ao departamento de informática da Pontíficia Universidade Católica do Rio de Janeiro, PUC-RJ, 221 f. Disponível em: <http://www2.dbd.puc- rio.br/pergamum/tesesabertas/5000294091_00_completo.pdf> Acesso em: 28 Fev.

2011.

FILHO, Wilson de Pádua Paula. Engenharia de Software: fundamentos, métodos e padrões. 2000. Disponível em < http://www.4shared.com/file/- VLEha28/_LIVRO__Engenharia_de_Software.htm> Acesso em: 28 fev. 2011.

MEIRA, Alyne Figueirêdo. Melhoria do processo de engenharia de requisitos.

2008. Monografia apresentada ao curso de pós-graduação em ciências da computação, do Centro de Informática (CIn), UFPE, 2008. 46 f. Disponível em:

<http://www.cin.ufpe.br/~in1020/monografias.html> Acesso em: 07 Mar. 2011.

PADUELLI, Mateus Maida. Introdução à manutenção de software. Revista Engenharia de Software. Ed. 11. Ano 1. 2009, p. 8 – 19. Disponível em

<http://www.devmedia.com.br/> Acesso em: 22 ago. 2010.

PRESSMAN, Roger S. Engenharia de Software. McGraw-Hill. 6. ed. 2006.

SOMMERVILLE, Ian. Engenharia de software, 8ª edição / Ian Sommerville;

tradução: Selma Shin Shimizu Melnikoff, Reginaldo Arakaki, Edílson de Andrade Barbosa; revisão técnica: Kechi Kirama. – 8ª ed. – São Paulo : Pearson Addison- Wesley, 2007.