Transcript
CENTRO UNIVERSITÁRIO NEWTON PAIVA
FACULDADE DE CIÊNCIAS EXATAS E TECNOLÓGICAS
CURSO DE SISTEMAS DE INFORMAÇÃO
MARCELA SIMÃO GOMES DA SILVA - 11114578
RESUMO CRÍTICO
"UMA ABORDAGEM CONCEITUAL À EVOLUÇÃO DOS REQUISITOS DIANTE DOS DESAFIOS DA ENGENHARIA DE SOFTWARE."
BELO HORIZONTE
2012
RAMOS, Paulo Henrique. Uma abordagem conceitual a evolução dos requisitos diante dos desafios da Engenharia de Software. http://www.cin.ufpe.br/~in1020/arquivos/monografias/2010_2/Monografia_Paulo.pdf
UMA ABORDAGEM CONCEITUAL A EVOLUÇÃO DOS REQUISITOS DIANTE DOS DESAFIOS DA ENGENHARIA DE SOFTWARE
INTRODUÇÃO
Este resumo trata-se do tema abordado pela monografia "Uma abordagem conceitual a evolução dos requisitos diante dos desafios da Engenharia de Software" do autor Paulo Henrique Ramos graduado em Ciência da Computação pela Universidade Federal de Pernambuco (UFPE), é a evolução dos requisitos na área de TI em que o problema a ser tratado é a busca de 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.
Diante de todas as problemáticas que envolvem a evolução dos requisitos de software, existe a necessidade de uma abordagem mais detalhada do assunto, que vai nos permitir 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á ser evitados, proporcionando assim uma segurança no desenvolvimento de um dado projeto.
É percebível que ao longo dessas ultimas cinco décadas a evolução dos softwares obteve um crescimento expressivo, que começaram com a arquitetura de computadores no qual o computador foi sendo aperfeiçoado e permitia assim um software bem mais dinâmico, com muito mais qualidade.
Assim, a vida do programador solitário saiu de moda em meados dos anos 90, não sendo abolido, mas sim contemplado com a chegada de novos profissionais, sendo assim o programador que antes trabalhava sozinho teve o seu trabalho subdividido em pequenas partes. Logo, o programador antigo que a principio era analista de sistema, gerente de projetos, realizava testes, entre outras funções, passou a trabalhar exclusivamente com a parte de desenvolvimento do software, deixando assim os demais processos para os outros funcionários que tem especialização para a área. Digamos que o programador teve uma melhoria em sua profissão. Após todas essas subdivisões e mudanças na área de TI, outros problemas surgiram muitos relacionados com a área de requisitos. O uso de novas metodologias para ajudar e auxiliar os profissionais durante o processo de desenvolvimento de software chamado requisitos de software foi sendo adicionado aos poucos a vida dos profissionais de TI. Mas temos o conhecimento de que o processo evolutivo necessita de uma estruturação bem definida e segura, pois, isso ira permitir uma total segurança para todos que estão envolvidos no projeto. Logo, a manutenção futura de algum software estará diretamente ligada a essa estruturação bem definida, pois, as possíveis melhorias dos softwares serão feitas da maneira mais objetiva possível. Porém toda essa manutenção devera seguir uma padronização que por sua vez tem a finalidade de dar sustentação ao projeto e gerar uma serie de garantias.
ENGENHARIA DE SOFTWARE
Estudos dentro da área de Engenharia de Software mostra que existe a necessidade de utilizar a Engenharia de requisitos na área de desenvolvimento de projetos, pois a segurança que é dada com o uso dessas metodologias solidifica o processo de fabricação do software.
Atualmente é comum que as empresas desenvolvedoras de software, realizem a documentação total de seus sistemas, pois o mercado atual já considera que as empresas que não tem os documentos de softwares são inviáveis para os padrões da atualidade, pois, os documentos geram uma segurança do projeto para os contratantes. A padronização visa alterações, melhorias e aperfeiçoamentos futuros e tem por finalidade satisfazer a empresa contratante e como conseqüência facilitar o cotidiano dos desenvolvedores.
A ausência da padronização pode gerar algumas conseqüências prejudiciais para ambos os lados envolvidos no projeto, como o aumento no custo do software, que pode ocasionar desistência por parte da empresa que contrata, estimativa de tempo de desenvolvimento insuficiente, trazendo assim prejuízo para a empresa contratada. Assim podemos tirar uma conclusão, sem documentação objetiva, inúmeros problemas são encontrados trazendo prejuízos.
A correção dos problemas, antes que o projeto passe para a fase de testes pode gerar uma economia significativa. Pois segundo Araujo e Dias (2010), o valor gasto para que um determinado defeito seja corrigido durante a fase de teste 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 de DERs (Documento de Especificação de Requisitos de Software). Já para Pressman (2002 apud MEIRA, 2008) o valor para correção é inferior, porem o custo vai aumentando gradativamente conforme avança a fase de desenvolvimento. Logo, para Pressman, o custo pode até ser inferior, mas não deixa de ser alto, porém na medida em que o projeto vai chegando perto da fase final "teste" o custo irá ser muito mais alto do que se for corrigido no inicio do projeto.
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. De acordo com estudos, os custos para correção de falhas seriam da seguinte forma: Se detectado na fase de Requisitos seria 2%, na fase de Projeto seria 6%, na fase de Codificação 11%, já na fase de testes o custo elevaria cerca de 81 %. Mostrando assim a importância da engenharia de requisitos dentro da área de desenvolvimento dos softwares.
Para que consiga obter um maior entendimento sobre o assunto de requisitos, saiba que a engenharia de requisitos esta situada em uma região onde há grande desentendimento e confusão. Exatamente entre o analista e o contratante sendo usada como arma e como escudo ao mesmo tempo, e sendo menosprezada como "algo" que se faz no inicio da analise, apenas um texto descrito e outras uma lista ou tabela a qual se deve cumprir em um tempo determinado. 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 possa iniciar o desenvolvimento do projeto solicitado. Em poucas palavras pode-se resumir engenharia de requisitos tem com função descobrir o que o cliente realmente quer do software.
EVOLUÇÃO DOS SOFTWARES
Atualmente o mercado de TI se diferencia do de antigamente em que pensavam que após concluir a instalação o processo estava terminado. As empresas têm um contrato por um longo tempo. Além de desenvolver o software após sua finalização vêm diversos serviços como mudanças, manutenção, entre outros. O processo evolutivo é marcado pela sua dinamicidade constante e pelas melhorias que são solicitadas quase que diariamente aos profissionais de TI. Desta maneira, ao termino 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 solicitados pelos usuários, vira também algo de extrema importância e intrínseco a continuidade do projeto, ou seja, a confiabilidade dos dados da empresa. A evolução dos softwares 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 que é bem elaborado facilita o processo de manutenção do software, porque quando o usuário necessitar de alguma mudança, aperfeiçoamento ou melhoria em seu software os desenvolvedores não sentiram dificuldade para realiza-la. Pois se engana quem pensa que o software não muda, porque todo sistema como tudo no mundo real muda, é muito pouco provável que um sistema não precise de mudança ao longo de sua vida útil. Um software que não sofre nenhum tipo de manutenção ou mudança com o passar do tempo vai se tornando obsoleto. Portanto a manutenção de software é algo indispensável para a continuidade da vida útil de um sistema. O software pode sim envelhecer isso fica totalmente perceptível, pois um sistema que não sofre mudanças ao longo do tempo pode cair em desuso. As mudanças ao longo do tempo podem ser divididas de duas formas: A primeira seria quando existe mudanças necessárias e elas não são implementadas e assim o sistema não se adequa as novas regras de negocio vigente, a segunda é quando as adaptações são realizadas, mas de maneira desorganizada e sendo assim geram problemas para o sistema como um todo, gerando novos erros e diminuindo sua manutenibilidade.
A MANUTENÇÃO DOS SOFTWARES DIANTE DO PROCESSO EVOLUTIVO
A evolução do 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. É 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. Como foi dito anteriormente a evolução do software são as possíveis mudanças que podem ser feitas no sistema afim de que ele se torne perfeito. Logo, esse processo evolutivo tem algumas particularidades que mostraram qual mudança deve ser realizada para que isso aconteça, após essa analise mostrará se as mudanças são validas ou se o software já caiu em desuso e deve ser abandonado. Se o abandono for a opção mais certa para o caso, então a partir dessa nova analise e desses quesitos que o usuário deseja mudar, criará um novo software, que estarão dentro das solicitações do usuário e dentro dos novos padrões de TI. Assim podemos dividir as principais atividades de manutenção lembrando sempre que de acordo com as necessidades das empresas.
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.
Existe uma grande duvida entre os usuários que utilizam um software diariamente e que necessitam de mudanças constantes, como diferenciar uma falha de um defeito, de um modo geral defeito é considerado uma anomalia de um produto já uma falha é considerada um dispositivo com defeito essas duas definições são associadas ao conceito de hardware, mas em software falha e defeito seguem o mesmo principio, falha e defeito é um problema de qualidade, mas que só é descoberto após a implantação na empresa contratante.
A vida útil de um software, assim como os problemas que ocorreram quando a fase de mudanças iniciarem. Da mesma maneira que o software "novo" poderá enfrentar certa resistência por parte dos usuários por conta do seu legado. Um grande exemplo clássico sobre isso seria: Um sistema do tipo universitário é um software que necessita de mudanças para não cair justamente em desuso, para não ficar fora do mercado, e precisa de mudanças por parte da interface, e com o tempo pode haver necessidade de adicionar funções. Pois é, essa mudança considerada melhoria pela empresa, os usuários no inicio da mudança tem certa resistência, pois o que é considerado novo, muitas pessoas reprimem preferindo o antigo sistema, pois já estava acostumado e para ele era muito melhor. O processo de manutenção é uma operação de extrema importância.
PRINCIPAIS NORMAS DE PADRONIZAÇÃO
A manutenção tem uma padronização, ou seja, segue princípios pré definidos 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. 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 ISO/IEC 12207, que teve inicio em 1989. Esta norma deveria ser estabelecida como um framework adaptável, que pudesse ser usado para auxiliar na gerencia e na construção do software (ibidem, p. 13).
A ISO/IEC 12207 é a norma ISO/IEC (ISO organização não-governamental, estabelecida em 1947, e que coordena o trabalho de órgãos de 127 países membros para promover a padronização de normas técnicas em âmbito mundial. IEC fundada em 1906, conta com a participação de mais de 50 países e publica normas internacionais relacionadas com eletricidade, eletrônica e áreas relacionadas.) que define processo de desenvolvimento de software. E tem como objetivo principal estabelecer uma estrutura comum para os processos de ciclo de vida e de desenvolvimento de softwares visando ajudar as organizações a compreenderem todos os componentes presentes na aquisição e fornecimento de software e, assim, conseguirem firmar contratos e executarem projetos de forma mais eficaz. Os processos fundamentais são necessários para que um software seja executado. Eles iniciam o ciclo de vida e comandam outros processos. São eles: Aquisição: possui o propósito de obter o produto e/ou serviço que satisfaça suas necessidades; Fornecimento: possui o propósito de prover um produto e/ou serviço; Desenvolvimento: possui o propósito de transformar um conjunto de requisitos em um produto ou sistema de software; Operação: possui o propósito de operar o produto no seu ambiente e prover suporte aos usuários; Manutenção: possui o propósito de modificar o produto de software e depois dar liberação para o uso. Algumas atividades importantes para o desenvolvimento de software serão descritas a seguir. São elas: Implementação; Levantamento de requisitos; Análise dos requisitos do software; Projeto da arquitetura do software; Projeto detalhado do software; Codificação e testes do software; Integração do software; Teste de qualificação do software; Instalação do software; Testagem e aprovação do software. Com base na norma ISO/IEC 12207.
Segundo a norma ISO/IEC 15504, também conhecida como SPICE, é uma evolução da ISO/IEC 12207, que assim como ela é a norma que define processo de desenvolvimento de software. Segundo a norma, uma avaliação de processo de software é uma investigação e análise disciplinada de processos selecionados de uma unidade organizacional em relação a um modelo de avaliação de processo. A ISO/IEC 15504 define um modelo de referência de processo que identifica e descreve um conjunto de processos considerados universais e fundamentais para a boa prática da engenharia de software, e define seis níveis de capacidade, seqüenciais e cumulativos que podem ser utilizados como uma métrica para avaliar como uma organização está realizando um determinado processo e também podem ser utilizados como um guia para a melhoria. A ISO/IEC 15504 define também um guia para a orientação da melhoria de processo, tendo como referência um modelo de processo e como uma das etapas a realização de uma avaliação de processo. Este guia sugere oito etapas seqüenciais, que inicia com a identificação de estímulos para a melhoria e o exame das necessidades da organização. Em seguida existem ciclos de melhoria, nos quais um conjunto de melhoria são identificadas, uma avaliação das práticas correntes em relação à melhoria é realizada, um planejamento da melhoria é feito, seguido pela implementação, confirmação, manutenção e acompanhamento da melhoria. São denominadas: 1: Documentação, 2: Gestão de configuração, 3: Garantia de qualidade, 4: Verificação, 5: Validação, 6: Revisão Conjunta, 7: Auditoria, 8: Resolução de Problemas.
Os desenvolvedores fazem os softwares, mas os clientes são os que vão usá-los. Por isso a necessidade urgente de sistematizar formas de evitar os custos elevadíssimos resultantes dos defeitos de software e dos erros não intencionais dos usuários. E isso só será possível se forem priorizadas e atendidas pelo menos quatro características de qualidade de softwares: usabilidade, confiabilidade, funcionalidade e manutenibilidade. Sendo estes os requisitos essenciais do produto de software, exigidos pelos compradores e atendidos pelos vendedores, veremos resultados positivos para ambas as partes e teremos softwares de melhor qualidade e mais úteis para os fins a que se destinam. Ainda é elevado o número de empresas brasileiras de software que não adotam técnicas para melhoria da qualidade de seus produtos, mas não há como negar que as empresas que desenvolvem software de qualidade são mais competitivas, o que é muito importante para sua sobrevivência em um mercado cada vez mais globalizado. A abertura de mercados externos para os softwares brasileiros exigirá uma nova postura frente à qualidade, beneficiando o mercado interno que acabará por exigir softwares melhores a menor preço. É preciso que os esforços em melhoria da qualidade de software tenham seu foco não no produto apenas (fazer software melhor), mas principalmente no processo (fazer melhor o software) e no cliente (fazer software mais fácil de usar).
CONCLUSÃO
Conclui-se que, 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 termino da implantação do mesmo. 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. Vimos que os benefícios que geram a partir da utilização das normas de padronização são perceptíveis, pois durante o processo de desenvolvimento de um sistema, é extremamente necessária uma solidificação do que foi acordado entre o cliente e a fabrica que desenvolverá o sistema. Onde ambas as partes estarão 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. Outro ponto importante mencionado é o processo evolutivo que os softwares vêm sofrendo nesses últimos anos tem como finalidade melhoramento das praticas da Engenharia de Software.
Portanto, conclui-se que a monografia "Uma abordagem conceitual a evolução dos requisitos diante dos desafios da Engenharia de Software" abrange esses assuntos Engenharia de Software, 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ções existentes, de uma maneira clara e objetiva e de fácil entendimento. O artigo se encontra muito bem estruturado e os temas abordados mantêm uma conexão correta. Porém em algumas partes o assunto se torna repetitivo e cansativo, dando uma impressão de que fala demasiadamente onde em determinados pontos não se vê necessidade de fazer isso, poderia ser mais breve. Mas a tese se encontra completa em todas as informações dadas, possibilitando assim ao leitor adquirir conhecimento sobre todos os assuntos abordados na dissertação.
