Engenharia de Software - Uma Abordagem Profissional RESUMO CRÍTICO
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. Etem 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.
0 comentários