Engenharia de Software Fidedigno
http://www.ic.unicamp.br/~cmbm/desafios_SBC/Arndt.pdf
Engenharia de Software Fidedigno
Arndt von Staa
2006
1. Motivação
Em virtude da crescente participação de software na socie
dade, torna-se cada vez mais
necessário assegurar que seja fidedigno. Um software é di
to
fidedigno
(inglês:
dependable
)
quando se pode justificavelmente depender dele assumin
do riscos de danos compatíveis
com o serviço do software. Em [ALRL 2004] Avizienis e out
ros estabelecem as propriedades
que sistemas fidedignos devem possuir. Com pequenas modifica
ções temos:
Disponibilidade
: estar pronto para prestar serviço correto sempre que
se necessite do
software.
Confiabilidade
: habilidade de prestar continuamente serviço correto.
Segurança
: (
safety
) habilidade de evitar conseqüências catastróficas relativas
tanto
aos usuários como ao ambiente.
Proteção
: habilidade de evitar tentativas de agressão bem sucedidas.
Privacidade
: habilidade de proteger dados e código contra acesso indevido.
Integridade
: ausência de alterações não permitidas (corrupção de elemento
s).
Robustez
: habilidade de detectar falhas de modo que os danos (as c
onseqüências
de erros ou falhas) possam ser mantidas em um patamar aceitável.
Recuperabilidade
: habilidade em ser rapidamente reposto em operação fided
igna após a
ocorrência de uma falha.
Manutenibilidade
: habilidade de ser modificado (evoluído) ou corrigido
sem que novos
problemas sejam inseridos.
Depurabilidade
habilidade de apoio à diagnose e à eliminação de possívei
s falhas a
partir de relatos gerados.
Em [BB 2001] Basili e Boehm mencionam que cerca de 50% dos
sistemas de software
tornados disponíveis contêm faltas não triviais. Mencion
am ainda que cerca de 90% do
tempo inoperante de um sistema se deve a cerca de 10% das
faltas nele contidas. Por outro
lado, é sabido que falhas podem acontecer, independentem
ente de quão bem se tenha
desenvolvido o software. As causas vão desde a reconhecid
a falibilidade humana até
condições que fogem do controle dos desenvolvedores
, tais como erros de máquina
(possivelmente por causas externas), erros na plataforma u
sada (sistema operacional,
hardware, rede, banco de dados, etc.), falta de energia, falhas
em software que coexiste na
máquina, agressões (ex. vírus, furto de dados, uso indevido).
Pode-se afirmar que é utópico almejar sistemas absolutam
ente fidedignos por construção
[PBBCCCEFKMOSTTT 2002]. Consequentemente, como não se pod
e assegurar a ausência de
falhas, deve-se tentar conviver com a presença delas atravé
s da construção de sistemas
tolerantes a falhas, recuperáveis, diagnosticáveis e depuráve
is. Uma possibilidade adicional
é permitir que sistemas possam reduzir a sua funcionali
dade ou capacidade de modo a
assegurar fidedignidade no evento de alguma falha [Bentley 2005].
Uma outra fonte de problemas é a deterioração do softwar
e [EKGMM 2001]. Diferente da
manutenção de artefatos físicos, a deterioração do software
tende a ser uma conseqüência da
sua manutenção. Entretanto, é impossível evitar que ocorra
a necessidade de evolução.
Vários autores mencionam que 75% ou mais do esforço de m
anutenção decorre da evolução
ou adaptação do software). Surge então a necessidade de dese
nvolver software de forma que
seja manutenível. Ou seja, deseja-se que o custo da manute
nção seja compatível com a
dimensão da funcionalidade alterada e que se possa assegurar
que a fidedignidade não seja
comprometida à medida que se realizam manutenções. É rec
onhecido também que para tal é
necessário que, à medida que o software vai sendo modific
ado, se deva realizar manutenção
preventiva, ou seja reestruturar o software com vistas a r
estabelecer a necessária qualidade
de engenharia.
2. Objetivos de longo prazo
É reconhecido ser um desafio desenvolver a baixo custo
software com as características
acima discutidas. Em particular deve-se levar em conta a g
rande tendência para o
desenvolvimento de sistemas distribuídos (residentes
na
Web
) e autônomos. É sabido que
tais sistemas representam um desafio a todas as tentativas
de garantia da fidedignidade tal
como descrita acima.
Para alcançar estes objetivos é necessário aprimorar as fe
rramentas disponíveis. É necessário
desenvolver
frameworks
, métodos, técnicas padrões de arquitetura e de projeto c
apazes de
auxiliar os desenvolvedores a atingirem estes objetivos
. Finalmente, é necessário reestruturar
currículos e desenvolver material de ensino de modo q
ue os profissionais formados estejam
preparados a utilizar este novo instrumental.
3. Referências bibliográficas
[ALRL 2004] Avizienis, A.; Laprie, J-C.; Randell, B
.; Landwehr, C.; “Basic Concepts and
Taxonomy of Dependable and Secure Computing”;
IEEE Transactions on Dependable
and Secure Computing
1(1); Los Alamitos, CA: IEEE Computer Society; 200
4; pags
11-33
[BB 2001] Basili, V.R.; Boehm, B.W.; “Software Defec
t Reduction Top 10 List”;
IEEE Computer
34(1); Los Alamitos, CA: IEEE Computer Society; 200
1; pags 135-137
[EKGMM 2001] Eick, S.G.; Karr, A.K.; Graves, T.L.;
Marron, J.S.; Mockus, A.; “Does Code Decay?
Assessing the Evidence from Change Management Data”
;
IEEE Transactions on
Software Engineering
27(1); Los Alamitos, CA: IEEE Computer Society; 20
01; pags 1-
12
[PBBCCCEFKMOSTTT 2002] Patterson, D.; Brown, A.; B
roadwell, P.; Candea, G.; Chen, M.;
Cutler, J.; Enriquez, P.; Fox, A.; Kycyman, E.; Mer
zbacher, M.; Oppenheimer, D.;
Sastry, N.; Tetzlaff, W.; Traupman, J.; Treuhaft, N.
;
Recovery Oriented Computing
(ROC): Motivation, Definition, Techniques, and Case
Studies
; Technical Report
UCB/CSD-02-1175, Computer Science, University of Ca
lifornia Berkeley; 2002;
Buscado em: 7/8/2004; URL: http://roc.cs.berkeley.e
du/papers/ROC_TR02-
1175.pdf
[Bentley 2005] Bentley, P.; “Investigations into Gr
aceful Degradation of Evolutionary
Developmental Software”;
Natural Computing
4(4); Berlin: Springer; 2005; pags 417-
437
0 comentários