Engenharia de Software II - AULA 8

Prévia do material em texto

Engenharia de software II
8º Aula
Evolução de software
Pessoal, chegamos a nossa última aula!
Quanto conhecimento até aqui, não é?
Agora, é o momento de abordarmos o último 
assunto de nossa disciplina: a evolução de software.
 Vamos lá?
Boa aula!
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de:
• entender a evolução do software;
• conhecer a dinâmica de evolução do software.
47
1 - Discussões iniciais sobre a evolução de software
2 - Dinâmica de evolução
Seções de estudo
1 - Discussões iniciais sobre a evolução 
de software
 Quando o sistema é implantado na empresa, ele precisa 
sofrer modificações para continuar atendendo às expectativas 
da empresa. Quando o software é colocado em uso, pode ser 
que surjam novos que requisitos, novas funcionalidades e 
necessidades.
Entre as questões relacionadas ao desenvolvimento de 
software, destacam-se a necessidade de buscar melhor qualidade, 
maior produtividade, melhor gerenciamento e custos menores 
para a manutenção. 
Do mesmo modo, há a necessidade de se diminuir os 
custos de equipamentos no processamento de dados e da sua 
disseminação nas áreas que os utilizam. Também tem crescido 
o interessa, bem como o conhecimento por parte dos usuários 
da tecnologia. Isso os deixa mais exigentes, tendo em vista que 
o conhecimento se torna acessível para além de somente os 
profissionais da área. Ao mesmo tempo, esse movimento faz 
com que a produtividade também cresça.
Passa a haver, então, a necessidade de outros métodos 
de trabalhos, com foco em novas tecnologias e softwares ou 
ferramentas. Os métodos artesanais acabam por ficarem 
obsoletos. Como a chave da produtividade nos dias 
contemporâneos é a automação, isso leva os profissionais a 
desenvolver software e produtos similares como qualquer outro 
tipo de produto manufaturado.
As mudanças nos negócios da empresa contribuem para 
que novos requisitos sejam gerados em relação ao software já 
existente. Assim, pode-se evoluir o software já existente, de 
modo a corrigir seus erros durante a operação e adaptá-lo a 
uma nova plataforma para aprimorar seu desempenho e outras 
características não funcionais. A evolução do software, assim, é 
uma constante.
Christoph (2004, p. 38) apresenta de modo muito claro a 
questão da evolução do software quando afirma que as mudanças 
decorrentes do mundo que vivemos devem ser refletidas nos 
softwares, e isso causa seu envelhecimento. Esse envelhecimento 
certamente está relacionado com o grau de satisfação do 
usuário. Um software envelhecido é aquele que deixa o usuário 
final com lacunas em seu trabalho, e é inevitável. O afastamento 
da chegada desse processo é que pode ser obtido seguindo 
alguns cuidados como:
Estruturar o software para a evolução. Sempre 
que um software tenha uma expectativa que não 
seja curta, deve-se fazer sua estrutura visando 
facilitar a evolução. Como não é possível se 
saber com exatidão quais mudanças serão feitas 
no futuro, deve-se, portanto avaliar as partes 
do software que estarão mais sujeitas a mudanças 
no decorrer de sua vida útil e desenvolvê-las 
de forma que estas mudanças ocorram mais 
facilmente. Apesar desta ser uma regra de 
programação aconselhável para todos os 
sistemas, normalmente ela é negligenciada 
devido aos prazos apertados da maioria dos 
projetos. 
Documentar adequadamente. Nem sempre a 
documentação de um projeto é escrita pela 
pessoa mais qualifi cada para tanto, e mesmo 
que esta venha a ser escrita adequadamente, 
é sempre necessário que seja atualizada a 
contento à medida que novas mudanças 
forem sendo feitas no código. Deve-se ter em 
mente que esta documentação poderá ser usada 
para atualizar o sistema daqui a vários anos, e é 
bem possível que estas atualizações não sejam 
feitas pelos autores originais, logo deve-se fazer 
um esforço adicional para que a documentação 
seja clara e concisa com o software, e que seja 
compreendida por outros que não os seus 
autores. 
Revisar a estrutura. Deve-se ter em mente 
que sempre que a estimativa de vida útil do 
software seja longa, revisões da estrutura são 
fundamentais. Caso exista uma equipe própria 
para a manutenção, é sempre uma boa política 
deixá-la participar da revisão. Vale lembrar que 
as revisões devem começar antes mesmo da 
codifi cação, tais revisões são baratas, rápidas 
e podem poupar muito tempo e recursos no 
futuro. Estranhamente estas revisões são muito 
pouco utilizadas na prática (CHRISTOPH, 
2004, p. 38).
A questão da evolução do software é muito importante, 
porque as organizações contemporâneas são completamente 
dependentes dos sistemas, nos quais, aliás, investem milhões 
de dólares. Os sistemas são importantes ativos de negócios, 
e deve haver alto investimento em mudanças para que o 
valor dos ativos permaneça. Boa parte dos orçamentos, em 
grandes empresas, é destinada para que se mantenha sistemas 
existentes. Muitas vezes, 90% dos custos de software estão 
relacionados com a evolução do software:
Uma vez que a necessidade de adaptação 
cresce e mudanças são sucessivamente 
implementadas, interações e dependências 
entre os elementos do sistema crescem em 
um padrão desestruturado e levam a um 
crescimento da entropia do sistema. A cada 
nova mudança, a estrutura original do software 
se tornará mais fragmentada, e o custo de 
novas mudanças aumentará gradativamente, 
até o momento em que estes custos não 
mais serão viáveis. Será então necessário um 
trabalho de reestruturação do software para 
que este tenha sua complexidade diminuída 
(CHRISTOPH, 2004, p. 40).
As evoluções necessárias após a implantação do 
sistema não estão relacionadas apenas com reparos ou 
defeitos do software. Muitas delas são feitas devido a novos 
48Engenharia de software II
2 - Dinâmica de evolução
requisitos gerados em resposta às mudanças nos negócios ou 
necessidades dos usuários. Pode-se começar criando o release 
1 do sistema. Uma vez entregue, mudanças são propostas e o 
desenvolvimento do release 2 começa quase imediatamente. 
De fato, a necessidade de evolução se torna óbvia mesmo antes 
de o software ser implantado. Inclusive, releases posteriores do 
software podem estar em desenvolvimento antes que a versão 
inicial tenha sido liberada.
Este é o modelo idealizado de evolução de software que 
pode ser aplicado em situações em que uma única organização 
é responsável tanto pelo desenvolvimento inicial do software 
como pela evolução dele. Os produtos de software mais 
genéricos são desenvolvidos usando-se essa abordagem. Por 
outro lado, o software sob encomenda pode ser desenvolvido 
externamente, mas sua evolução é de responsabilidade da 
equipe de desenvolvimento do cliente. Como alternativa, 
o usuário do software pode assinar um contrato separado com 
uma empresa externa para apoio e evolução do sistema.
Sommerville (2007) cita um conjunto de leis que foram 
definidas sobre as mudanças no software. Foi examinado o 
crescimento de vários sistemas de software de grande porte.
A primeira lei afi rma que a manutenção de 
sistema é um processo inevitável. Como o 
ambiente do sistema muda, novos requisitos 
surgem, e o sistema deve ser modifi cado. 
Quando o sistema modifi cado é reintroduzido 
no ambiente, este promove mais mudanças 
no ambiente, de modo que o processo de 
evolução recomeça.
A segunda lei afi rma que, quando um sistema 
é alterado, sua estrutura se degrada. A única 
maneira de evitar que isso aconteça é investir 
em manutenção preventiva. Você gasta 
tempo melhorando a estrutura do software sem 
aperfeiçoar sua funcionalidade. Obviamente, 
isso implica custos adicionais, além da 
implementação das mudanças de sistema 
exigidas.
A terceira lei é, talvez, a mais interessante e 
a mais controversa das leis de Lehman. Ela 
sugere que sistemas de grande portetêm uma 
dinâmica própria, estabelecida em um estágio 
inicial do processo de desenvolvimento. Isso 
determina a tendência geral do processo de 
manutenção de sistema e limita o número 
de possíveis alterações no mesmo. Lehman 
e Belady sugerem que essa lei seja uma 
consequência de fatores estruturais que 
infl uenciam e restringem a mudança do 
sistema, bem como os fatores organizacionais 
que afetam o processo de evolução 
(SOMMERVILLE, 2011, p. 169).
Tabela: Dinâmica da evolução de programas. (SOMMERVILLE, 2011, p. 169).
49
Os processos de evolução de software mudam de modo 
significativo, pois dependem do software, dos processos e 
do desenvolvimento e pessoas envolvidas. Em algumas 
organizações, muitas vezes, a evolução pode ser um processo 
informal. As solicitações de mudanças são feitas de modo 
informal e dependendo de conversas entre usuários e 
desenvolvedores. Já em empresas, é um processo formalizado, 
com documentação estruturada e produzida em cada estágio 
do processo:
Em algumas organizações, a evolução pode ser 
um processo informal no qual as solicitações 
de mudanças, na maioria das vezes, provêm de 
conversas entre os usuários e desenvolvedores. 
Em outras empresas, é um processo formalizado, 
com documentação estruturada e produzida 
em cada estágio do processo. Diante de um 
contexto em que softwares são desenvolvidos 
por equipes, conforme descrito anteriormente. 
A necessidade de uma documentação é 
primordial para a agilidade, compreensão das 
nomenclaturas utilizadas (variáveis) nos códigos 
fonte, transição dos métodos, segurança de 
informação e padronização no intercambio de 
dados entre as camadas (DUTRA; BONELLI, 
s.d., p. 7). 
O processo de evolução inclui a resolução de atividades 
essenciais de análise de mudanças, planejamento de releases, 
implementação de mudanças e liberação de um sistema para 
os clientes. O custo e o impacto das mudanças realizadas são 
avaliados para investigar quanto do sistema é afetado pelas 
mudanças e quando pode custar para implementar a mudança.
Figura 1. Processo de identifi cação de mudanças. Dutra; Bonelli, s.d., p. 8.
No planejamento de releases, as mudanças são todas 
consideradas. A partir de então, as decisões serão tomadas 
com base em quais mudanças deverão se implementadas na 
próxima versão do sistema. Quando as mudanças são validades, 
há a liberação de um novo release do sistema: “O processo de 
implementação de mudança é, essencialmente, uma interação 
do processo de desenvolvimento na qual as revisões do 
sistema são projetadas, implementadas e testadas” (DUTRA; 
BONELLI, s.d., p. 7).
Vale a pena
CHRISTOPH, Roberto de Holanda. Engenharia de 
software para software livre. Rio de Janeiro: PUC, Departamento 
de Informática, 2004.
Vale a pena ler
Referências 
CHRISTOPH, Roberto de Holanda. Engenharia de 
software para software livre. Rio de Janeiro: PUC, Departamento 
de Informática, 2004.
BONELLI, Eduardo Lessa; DUTRA, Luciano Vieira. 
Padrões de prototipação em novos processos de reconhecimento de 
padrões e aplicações de sensoriamento remoto: treinamento estruturado 
supervisionado. Curso de Pós-Graduação em Computação 
Aplicada (Cap) Instituto Nacional de Pesquisas Espaciais 
(INPE) – São José dos Campos – SP – Brasil.
OLIVEIRA, Frederico Bida de. Interfaces Usuário-Máquina. 
Disponível em: <https://sistemas.riopomba.ifsudestemg.edu.
br/dcc/materiais/1618984280_Apostila-Interfaces-Homem-
Maquina.pdf>. Acesso em: 4 mai. 2017.
SCHUHMACHER, Vera Schuhmacher; CASTIÑEIRA, 
Niedersberg Maria Inés; SOUZA, Aidê Luzia A. de; 
CAMARGO, Roselane M. M. Avaliação da Interface do Auto-
Atendimento das Agências do Besc: Uma Abordagem Ergonômica. 
Disponível em: <http://www.inf.furb.br/seminco/2003/
artigos/129-vf.pdf>. Acesso em: 5 mai. 2017.
Disponível em: <http://www.revista.vestibular.uerj.br/
coluna/coluna.php?seq_coluna=68>. Acesso em: 26 jun. 
2017.
FARIAS, Carina Machado de. Um método de teste funcional 
para verificação de componentes. Dissertação de Mestrado, 
Universidade Federal de Campina Grande, Centro de 
Ciências e Tecnologia, Coordenação de Pós-Graduação 
em Informática, Campina Grande, PB, Fevereiro de 2003.
Disponível em: <http://periodicos.unicesumar.edu.br/index.
php/iccesumar/article/viewFile/268/87>. Acesso em: 3 jul. 
2017.
Disponível em: <www.posse.ueg.br/index.php/
artigos.../204_abb417eacc8f79430b9aa95638135a15>.
Disponível em: <http://www.inf.ufrgs.br/~taisy/
disciplinas/textos/ConceitosDependabilidade.PDF>.