=Paper=
{{Paper
|id=Vol-1471/paper15
|storemode=property
|title=Processo de Introdução de Melhorias e de Correcções de Erros de Software em Sistemas de Telecomunicações
|pdfUrl=https://ceur-ws.org/Vol-1471/paper15.pdf
|volume=Vol-1471
|dblpUrl=https://dblp.org/rec/conf/quatic/OliveiraP95
}}
==Processo de Introdução de Melhorias e de Correcções de Erros de Software em Sistemas de Telecomunicações==
https://ceur-ws.org/Vol-1471/paper15.pdf
Titnlo :
"Processo de introduc50 de melhorias e de correcc6es de erros de software
em Sistemas de Telecomunicac5es".
Autores Eng' Sousa Oliveira.
Eng' Miguel Prudncio.
SIEMENS, S.A., Dept. ComutaAo e SOftware.
Av. Almirante Reis, no 65 1150 LISBOA.
Telef: (01) 350 2000 Fax: (01) 350 2424
Resnmo
-
No contexto de melhoria continua esta comunicao aborda o tern& das alter&Jes
introduzidas no software de sistemas hierarquizados, isto e, divididos em subsistemas e
m6dulos, para a implementac&o de melhorias ou correc(;:&o de erros. garantindo a
-. compatibilidade e a divulga&o coerente das sucessivas versHes dos diferentes m6dulos Que
constituem o sistema.
.--
Esta comunicao onde sero ainda referidas ferramentas de apoio para controlo da
rastreabilidade e das responsabilidades inerentes ao processo, esta organizada em trs
-- capitulos, o primeiro constituindo urns introdu&o global e Os dois seguintes abordando,
respectivamente, os relat6rios de falhas e a implementa(;:&o
das correcJes.
- Conclus6es, Esta de abreviaturas e defmiJes e bibliografla completam a comunica5o.
Os mercados abertos e a consequente concorr6ncla permanente levam a mantel sempre
presente o tri&ngulo:
Qualidads
Tempo Custos
Que, por outras palavras, significa
- evolu5o tecnol6gica e de facilidades,
- melhoria de processos,
- eliminaAo de erros.
P;'\gina I de II
155
Esta comunicao aborda em detalhe a metodologia do tratamento de erros desde o sen
levantamento (relat6rio de falha) seja ele intemo ou feito pelo cliente, at6 a sua solu50 e
implementso no campo.
Convem aqui referir Que Se trata de software existente em centrals telef6nicas ou outros
sistemas de telecomunicaJes e que, portanto, se encontra espalhado pot todo o pats,
eventualmente em diferentes lases de evoluo, isto e, em diferentes vers6es.
Igualmente conv6m separar os etros de software das avarias de hardware, visto serem tratados
de formas diferentes:
Os erros de software do origem a correc5es no c6digo.
As avarias de hardware so resolvidas por substituio e/ou reparao do dispositivo
avariado. O registo e tratamento estatistico destas avarias permite evidenciar eventuais
pontos fracos e a consequente tomada das ac6es correctivas e preventivas.
O registo das avatias referenciado ao dispositivo e ao componente assim como a
conservao do respectivo hist6rico permitem a rastreabilidade do processo e a
consequente evid8ncia de falhas ocasionais ou sistemafleas quer ao nivel do processo quer
ao nivel do produto.
Os erros de software levantados pelos relat6rios de falha (Fault reports) so corrigidos:
atrav(!s do c6digo foute implicando nova compilaAo e "Iirlkagem"
atrav6s de alters6es introduzidas directamente no c6digo m89uina, tomando, neste caso, o
nome depatch.
Quando o software de aplica&o CAPS)ainda Se encontra numa lase inicial de teste,
os erros detectados nessa lase s50, regra geral, corrigidos na foute e, posteriormente,
felts nova produo (compila80 ) dessa vets&ode software.
Quando um APS se encontra em lase final de testes e especialmente se a vetsAo de
software ja se encontra instalada no campo, as correcJes de erros sac feitas pot
patches fisicas~
Estas patches s80 introduzidas no ^PS atraves de ficheiros que executam varios
comandos.
A nossa comunicaAo vai &borderapenas este Segundo caso.
Uma vez criado o patch, este d testado inicialmente em sistemas simulados e depois nas
nossas centrals de teste equipadas com o hardware e o software Que Ihes permite criar
condi5es iguais as verificadas no campo quando o erro ocorreu.
Ap6s apronso deste polo cliente d feita a introduBo do patch em todas as centrals onde
aquela versko de software esteja implementada. Parte-Se do principio Que um erro no c6digo
do software esta presente em todas as centrais onde a vets8o do m6dulo de software afectado
estiver instalada, independentemente de ter sido detectado ou nAo.
P6gina 2 de II
156
A evoluo do so&ware EWSD, o processo de teste apertado e um acompanhamento
perrnanente nos primeiros tempos ap6s a entrega da verso piloto ao cliente, assim como as
condiJes especificas de cads central dependentes da sua localizao na rede, permitem
afirmar Que, normalmente, novos erros s6 aparecem em situa8"es muito especiais em que se
d a coincidncia de varios factores, o que justifica que urns determinada situao de erro s6
ocorre numa central e no em todas.
--
loaualmente, o processo de controlo dos patches garante a sua incluso em futuros
melhorarnentos dos respectivos m6dulos assim como a sua divulga8o a nine! mundial.
Resurnindo, a elimina&o dos erros de software 6 feita atraves da aplicao de dois processos
par&16105e interligados;
Processo "Relat6rio de Falha" que contempla o registo de todos Os dados e fases Que
conduzem a soluAo do problems.
-
Processo Patch Que contempla a alter&&o do program& (c6digo) e a sua implementao no
campo.
--
~ . Por outras palavras o processo patch resolve o problems eliminando a causa do erro e o
processo Relat6rio de Paths regista todas os elementos e passos Quepermitiram a solu5o do
problems.
2. Principios gen6ricos do processamento do Relat6rio de Paths (Fault Report)
2.1 Objectivos
-
A normaliza5o de conceitos relacionada com o processamento de Fault reports,
permitira resolver os erros de software encontrados de form&mais rapids.
A qualidade das correc5es e pois garantida pela normalizako de conceitos.
2.2 Processo
(ver fluxograma Relat6rios de Falha)
Ver fxgura I
As alineas seguintes descrevemas principaisfases do fluxograma.Os n1:mlemsQue
acompanhamos titulos referem as respectivasfasesno fluxograma.
157
Gerar reJat6rio
de falha no FET
2
3
Prossento
, pelo Desenvolvimto
I Resultadonegative Y 5
| da correcco I
Resultado positivo
da conccAo
Inserirnota de
correco no FET
CorrecAoOK
Fechodo Relat6riode faJha
Fig.1 - Fluxograma de proeessamento de relat6rios de falha
P:igina4 de I I
158
IntroduVAode elementos descrevendo o erro, no QueSe refere ao projecto envolvido,
sub sistema descriAo pormenorizada, inicio do processo, organizao responsavel,
hem como a prioridade de resoluo - tecnica e de cliente .
Localiza3o do erro dentro da organizao do sistema que, devido a estrutura
modular do software, permite associar aos diferentes grupos responsaveis pela sua
correco.
Identificao de falha que causa o problems.
Planeamento de ac6es correctivas.
Desenvolvimento, e teste das medidas correctivas.
Teste pelo nivel superior, garantindo a funcionalidade do sistema.
Libertao das correc6es, isto , a autoriza8o para colocar no campo
Teste da correco ja no ambiente de funcionamento da correc8o.
Ex: 'APS de campo'.
Coventario final do Fault Report.
2.3 Controlo
Os Fault Reports sa-oprocessados por varias entidades, logo, particular importcia
deve ser dads ao controlo de processo.
.- Dentro do processo, urns determinada taters e Iniciada logo Que esteja disponivel a
informs&o da tarefa anterior. Para cada taters deve ester indicado o responsAvele o
objectivo.
-- Quando uma tarefa esta terminada devem ser claros os resultados do processo
nessa lase, bem como a pr6xima tarefa. Normalmente, no final de cads tarefa Os
resultados devem ser determinados. ModifiesJes posteriores nAo sSo permitidas.
--
Em caso de absoluta necessidade, dever-Se-a abrir novo processo.
159
Em qualquer altura do processo deve ser possivel inquirir o estado de um Fault
Report, e a seguinte informa8o deve estar sempre disponivel:
- tarefas em aberto;
- tarefas completadas;
- organizacdo responsavel;
- resultados correntes.
Durante o processo, a sequencia de tarefas tern que ser transparente para qualquer
das entidades envolvidas.
A responsabilidade para cada uma das tarefas tern que ser clara. A organizao
prev a coordenao de todas as actividades relacionadas com um Fault Report.
E tambm possivel monitorizar grupos de Fault Reports por sistema, projecto ou
produto, hem como a sua observao individual.
Os tempos de reaco, visto normalmente o Fault Report passar por varias
organiza6es, so tambem controlados.
2.4 Ferramentas de apoio
Para implementer Os principios atrs enunciados, o procedimento de Fault Report e
apoiado, em ferramentas.
- Para processamento local. - FMERF/PROCONS;
- Para processamento central. - FEKAT.
Estas ferramentas usam interfaces com outras ferramentas, em particular com a CM
- Conjlguration Management e SSG Management.
O processamento de um Fault Report envolve as lases enunciadas em 2.2.
2.5 Entidades
As entidades envolvidas durante o processamento de Fault Reports sAo:
* Apoio ao Cliente
Esta entidade existe exclusivamente para Fault Reports emitidos pelo cliente.
Uma organiza&o local ou central pode ser envolvida dependendo da estrutura da
organiza&o.
* Apoio ao Relat6rio de Falha
Esta entidade controla a distribuiSo, monitorizao e apoio ao processamento de
Fault Reports. Esta tarefa 6 assumida pelo responsavel do sistema com falha e
pode ser alterada.
160
* Equipa de Desenvolvimento
Esta entidade responsavel pela analise do erro e, se necessio, a sua correcC5o
no respectivo Sub-Sistema.
'.~
* Equipa de Teste
Esta entidade assegura a funcionalidade dos Sub-Sistemas corrigidos em
conjuga&o com outras funcionalidades de sistema. Isto inclui introdugo de
.
correcJes, verificao e anise de falhas e verificao de correcJes.
3. Principios genericos do processamento de 'Patches'
3.1 Objectives
Os patches sa~ocorrecJes de c6digo-objecto de um software de aplicao
(S).
Um patch toma possivel a correco de erros durante a opera80 de um sistema
sem interrup80 das suas funcionalidades normals.
DescriBes de patches fem parte da document&80 oflcial entregue ao cliente,
sendo sujeitas a um apertado controlo de qualidade.
3.2 Pases de processamento de Patches
(ver fluxograma Patches)
Ver figura 2
Depois da analise de urn relat6rio de falha e caso o erro deva ser corrigido atravds
de um patch, devera a ea de desenvolvimento verifxcar o troo de c6digo onde o
mesmo ird ser inserido para determiner se tecnicamente d possivel a sua introdu&o.
Nessa verificaAo deverSo ser identificadas as diferenas de c6digos.
0 patch e`;testado pela equipa de desenvolvimento num simulador ou num ambiente
de teste aut6nomo.
161
An;iliSe do
DesenvolviTnento
162
A documentao do patch descreve o erro, a sua correco, assim como a descrio
das condi(;:5esde teste. Tal informa(;:Aosera utilizada posteriormente por outras
organizac6es dentro do processo. Esta informa(;:o introduzida atraves da
Ferramenta SSG.management.
A descri80 do patch que deve ser Clara e precisa, sera mais tarde incorporada na
base de dados SSG depois da respectiva revisSo.
A gemC5o de um patch produz um ficheiro de comando, qua a equipa de
desenvolvimento ou a equips teste, dard entrada na base de dados SSG. Estes
ficheiros de comando esto normalmente agmpados e administrados hum
determinado grupo de subsistema.
Antes do patch ser libertado, o desenvolvimento deve introduzir o comentario
correspondente ao relat6rio de falha no FEKAT.
Vers6es de sistema com correcC5es na fonte devem tambem ser incluidas no
FET.
Depois do patch ter sido testado com sucesso pela equips de desenvolvimento, e
passada para estado '02' (ver nota) e reportado para a equips do teste de sistema,
com inser8o de Covento no FEKAT.
.este do ?Glen_)el, Ste La
0 anl:incio darn patch disponivel em estado '02 para um determinado Fault'eport
vai conduzir ao teste do mesmo pela equips do teste de sistema que, ap6s o teste
com sucesso, colocar em 04' (ver nota) o estado da patch na base de dados SSG"
Seguir..se..a a respectiva inserCko de comento no FET, fechando assim o
relat6rio de falha. O teste do patch, quando negativo, originara novo cemento no
FET, sendo a equipa de desenvolvimento responsavel pela nova altersBo do
mesmo.
'.-.
Nata: Est&dodepatches
" 02 Patch testado pela equips do desenvolvimento
04 Patch testado pela equipa do teste de sistema
-
08 Patch errado
PAgina9 de I I
163
3.3 Tipos de Patches
A distino de tipos depatches serve para facilitar o seu processamento.
I) Backout Patches
Se Os patches forem incorrectos, devera ser possivel retira-los do sofrware de
aplica5o (APS),, utilizando para o efeito um backout patch.
Backout patches so unicamente gerados quando requiridos para elirninar outros.
2) Master and Slave patches
Slave patches podem ser introduzidos directamente no APS.
Patches com nomes de m6dulos, variaveis e endereOs numa forma simb6lica s80
chamados Master patches. Estes podem ser utilizados em variOs projectos, atraves
da gera80 dos Slave patches (mudando apenas os endereos).
Esta disponivel na base de dados SSG urn& ferramenta Que permite
automaticamente carregar estes patches convertendo o m6dulo simb6lico e nomes
de objectos num endereo fisico.
3) Patches com depend6ncias
Na documentao de um patch es previsto um campo Que devera
obrigatoriarnente ser preenchido Se houver alguma depend6ncia que podera ser :
- depend8ncia functional;
- dependncia com o projecto;
- depend6ncia de procedimento de incorporako;
- depend6ncia de HW e SW.
- depend6ncia de documenta&o de cliente.
Um pacote fisico de patches, contendo um ou variOspatches, devera ser defmido Se
a correc8o de um erro necessitar de variospatches ou se estes forem incorporados
nurna sequ8ncia especffica
4. Conclus6es
Este artigo pretende evidenciar a forma sistematica do tratamento dos erros de software desde
a sua deteco at6 a implementao da respectiva correco.
0 acompanhamento e registo das vas lases do processo permitem urn&rastreabilidade
completa incluindo as implementaJes no campo.
P;igina`10de I I
164
Abreviaturas e defmi6es
APS Application Program Software - software de aplica3o
EWSD Central electr6nica de Comutao Digital da Siemens
Fault Report Relat6rio de falha
FMERF/PROCONS Base de dados para registo e tratamento local dos relat6rios de falha
FEKAT Base de dados centralizada (a nivel mundial) para controlo dos
relat6rios de falha
CM Configuration Management Base de dados para controlo da
configuraAo do software (m6dulos, sub-sistemas, sistemas)
SSG Base de dados de Grupos de Sub-Sistemas
Patch AlteracAode software introduzida ao nivel do c6digo maquina
Bibliografla
I.[Siemens] Manual do Ap6s-Venda
2.[Siemens] Manual do FEKAT
3.[Siemens] Manual do PROCONS
4~[Siemens] Manual SSG Management
5.[Rydin 95] Rydin, Carlos; Corrio, Odete e Patrko, John
"GestAo de ConfiguraJes de Software de TelecomunicaJes"
Actas do Quatic 95, Lisboa, Dezembro 1995
6.[Almeida 95] Almeida Leonor; Nascimento, Nuno e Pinto, Luis
"SEPP@i : O Processo de Desenvolvimento, Produo e Manutenko de
Software para Sistemas de Telecomunica96es"
Actas do Quatic 95, Lisboa Dezembro 1995
P8gina 11 de i i
165
--
SIEMENS
Departamento de Comutac5o e Software.
QUATIC '95 20 Encontro Nacional para a Qualidade nas
Tecnologias de Informac5o e
Comunicac6es.
LNEC, Lisboa, 4-6.12.95
--
Curriculum Vitae abreviado dos autores da Comunicac5o:
"Processo de introduCAo de melhorias e de correcc6es de erros de
_
Software em Sistemas de Telecomunicac6es".
Eng'. Jos6 Luis Sousa Oliveira ~~
Nascimento: Lisboa 27.04.42
Gran academico: Licenciatura em Engenharia Electrotecnica pelo IST, em 1965
Dados Profissionais: Grupo Centrel: 1969-1987 ---
Emptel/Siemens: 1987-1992
Desde 1993 Chere de diviso, responsavel pela Qualidade da
Diviso de Vendas e ServiOs do Departamento de Comutao --
e Software da Siemens S.A.
Eng'. Miguel Prudncio
Nascimento: Portimo, 26.10.59
Gran academico: Bacharel em Engenharia Electr6nica e Telecomunica6es, pelo
ISEL, em 1983.
Dados Profissionais: Estagio na Siemens em 1983.
Ingresso na Siemens em 1984, funo: coordenador da area de
teste. -
.Ingresso na Timex (DivisAoComputadores) em 1986, funo:
Desenvolvimento de Hardware.
Ingresso na Emptel/Siemens em Abril'87 para a DivisAo de
Vendas e ServiOs.
Desde Outubro de 1991: Chee de sector da area de teste de
sistemas.
166