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