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(;:&ode 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(;:&doas 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: Que,por outras palavras, significa - evolu5o tecnol6gica e de facilidades, - melhoria de processos, - eliminaAo de erros.
"Processo de introduc50 de melhorias e de correcc6es de erros de software em Sistemas de Telecomunicac5es".
Autores
Qualidads
Tempo
Custos 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. --~ .
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 par&1610e5interligados; de dois processos 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 campo. no 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)
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.
(ver fluxograma Relat6rios de Falha)
As alineas seguintes descrevemas principaisfases do fluxograma.Os n1:mlemsQue acompanhamos titulosreferemas respectivasfasesno fluxograma.
Gerar reJat6rio de falha no FET 2
3 ,
Prossento pelo Desenvolvimto I Resultadonegative | dacorrecco I
Y
5 Resultado positivo da conccAo
Inserirnota de correco no FET
CorrecAoOK
Fechodo Relat6riode faJha IntroduVAode elementos descrevendo o erro, no QueSerefere 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.
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. .--
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 Queesteja 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-aabrir novo processo. 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.
Para implementer Osprincipios 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.
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. .
* 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.
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.
(ver fluxograma Patches)
Depois da analise de urn relat6rio de falha e caso o erro deva ser corrigido atravds de um patch, devera a ea de desenvolvimento verifxcaro 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`t;estado pela equipa de desenvolvimento num simulador ou num ambiente de teste aut6nomo.
An;iliSedo DesenvolviTnento '.-. "
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 Clarae 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:inciodarn 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 dopatch, quando negativo, originara novo cemento no FET, sendo a equipa de desenvolvimento responsavel pela nova altersBo do mesmo.
Nata: Est&dodepatches 02 04 08
Patch testado pela equips do desenvolvimento
I) Backout Patches A distino
de tipos depatches serve para facilitar o seu processamento.
Se Os patches forem incorrectos, devera ser possivel retira-los do sofrware de aplica5o (APS),,utilizando para o efeito um backoutpatch.
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 variOsprojectos, 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.
Na documentao de um patch es previsto um campo Que devera obrigatoriarnente ser preenchido Sehouver 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 depatches, contendo um ou variOspatches, devera ser defmido Se a correc8o de um erro necessitar de variospatches ou se estes forem incorporados nurna sequ8ncia especffica
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;ig1in6a4`10de I I
APS EWSD Fault Report FMERF/PROCONS FEKAT CM SSG Patch
Application Program Software - software de aplica3o Central electr6nica de Comutao Digital da Siemens Relat6rio de falha Base de dados para registo e tratamento local dos relat6rios de falha Base de dados centralizada (a nivel mundial) para controlo dos relat6rios de falha Configuration Management Base de dados para controlo da configuraAo do software (m6dulos, sub-sistemas, sistemas) Base de dados de Grupos de Sub-Sistemas
AlteracAode software introduzida ao nivel do c6digo maquina
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 "GestAode 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 Software para Sistemas de Telecomunica96es" Actas do Quatic 95, Lisboa Dezembro 1995 e Manutenko de SIEMENS
"Processo de introduCAo de melhorias e de correcc6es de erros de
Dados Profissionais:
Portimo, 26.10.59 Bacharel em Engenharia Electr6nica e Telecomunica6es, pelo ISEL, em 1983.
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.