Engenharia da qualidade

U

NIVERSIDADE DE

L

ISBOA

Faculdade de Ciências

Departamento de Informática

ENGENHEIRA DA QUALIDADE

projecto realizado na

Critical Software, S.A.

por

Inês de Sousa Ferreira Dias

Versão Pública

Mestrado em Engenharia Informática

UNIVERSIDADE DE LISBOA

Faculdade de Ciências

Departamento de Informática

ENGENHEIRA DA QUALIDADE

projecto realizado na

Critical Software, S.A.

por

Inês de Sousa Ferreira Dias

Projecto orientado pelo Prof. Dr. Luís Moniz e co-orientado por Engenheiro José Gonçalo Silva

Mestrado em Engenharia Informática

D

ECLARAÇÃO

Inês de Sousa Ferreira Dias, aluno nº 28781 da Faculdade de Ciências da Universidade de Lisboa,

declara ceder os seus direitos de cópia sobre o seu Relatório de Projecto em Engenharia Informática, intitulado “Engenheiro da Qualidade”, realizado no ano lectivo de 2006/2007 à Faculdade de Ciências da Universidade de Lisboa para o efeito de arquivo e consulta nas suas bibliotecas e publicação do mesmo em formato electrónico na Internet.

FCUL, 31 de Maio de 2007

_________________________________________

José Gonçalo Silva, supervisor do projecto de Inês de Sousa Ferreira Dias, aluna da Faculdade de

Ciências da Universidade de Lisboa, declara concordar com a divulgação do Relatório do Projecto em Engenharia Informática, intitulado “Engenheiro da Qualidade”.

Coimbra, 31 de Maio de 2007

A

GRADECIMENTOS

Agradeço à minha família por me terem dado o apoio necessário para tomar a decisão de seguir o estágio relativo à carreira que quero seguir. Agradeço a todos os meus amigos pela paciência da minha ausência e aos novos amigos pela partilha e o conforto.

Agradeço ao meu orientador José Gonçalo Silva pelas críticas construtivas transmitidas que permitiram que o meu trabalho ao longo do estágio tomasse um maior rigor e pragmatismo, para além das partilhas pessoais como amigo. Por fim, não poderia deixar de referir a equipa do Departamento de Qualidade pela motivação e disponibilidade que demonstraram ao longo do meu trabalho.

“All things are difficult before they are easy”

R

ESUMO

O insucesso de uma missão espacial significa uma perda considerável a muitos níveis. Para além da questão monetária, num satélite, a maioria das consequências são críticas pois leva a perda do mesmo e por conseguinte da missão, e no caso de missões tripuladas, as consequências podem ser catastróficas com a perda de vidas. Por conseguinte, é fundamental que o veículo espacial seja testado e validado no seu todo de forma a minimizar as hipóteses de fracasso. Neste contexto foi realizado um documento designado por Software Development

Validation and Verification Plan, no âmbito do projecto dos futuros lançadores (da EADS Astrium)

onde é descrito detalhadamente o plano de desenvolvimento de software e um plano de verificação referente à componente de voo do lançador, com objectivo de assegurar que o que está a ser desenvolvido satisfaz os requisitos definidos.

O conceito de qualidade sempre foi um conceito estratégico desde a fundação da empresa Critical Software, tendo sido uma vantagem competitiva de peso. O Departamento de Qualidade tem como objectivo principal garantir a entrega dos projectos dentro do orçamento, prazo acordado e finalmente, de acordo com os requisitos aprovados pelo cliente. A qualidade do

software é conseguido através da implementação de práticas de gestão de projecto,

coordenação e controlo convergindo num Sistema de Gestão de Qualidade (Quality

Management System) que segue as normas internacionais ISO 9001:2000 e ISO 15504 (SPiCE.

A tarefa de um Engenheiro de Software Quality Assurance (SQA) consiste em verificar se essas práticas estão a ser seguidas e orientar os colaboradores nessas tarefas, a fim de garantir a qualidade final do resultado e eventualmente melhorar os processos existentes.

PALAVRAS-CHAVE:

Plano de desenvolvimento, verificação e validação de software; Projecto Futuros Lançadores; Qualidade; Engenheiro de Qualidade (SQA); Sistema de Gestão de Qualidade (SGQ).

A

BSTRACT

The lack of success of a space mission means a considerable loss on many levels. Asides from the monetary issues, most of the consequences are considered to be critical, not only due the loss of the satellite and its consequent mission, but in the case of a crewed mission, the consequences may be catastrophic, leading to the loss of lives. Therefore, it is fundamental that the space vehicle be tested and validated as a whole, in order to minimise chances of failure. In this context, a document named Software Development Validation and Verification Plan was produced in the scope of the future launchers project (EADS Astrium) where the software development plan and verification plan are described in greater detail, regarding the flight launch component, with the objective to assure that what is being developed satisfies the defined requirements.

The quality concept has always been considered a strategic concept since Critical Software’s foundation, being a main competitive advantage. The Quality Department’s main objective is to guarantee project delivery, on budget, on time and finally, according to client approved requirements. The quality of software is obtained through the implementation of project management practices, coordination and control, converging into a Quality Management System which follows the international ISO 9001:2000 and ISO 15504 (SPiCE) standards. Software Quality Assurance Engineer (SQA) tasks consist in verifying if these practices are being followed and to coordinate the workers in these tasks, in order to guarantee the end result’s quality and eventually improve existing processes.

KEYWORDS:

Software Development Verification and Validation Plan; Future Launchers Project; Software Quality; Software Quality Assurance (SQA); Quality Management System (QMS).

C

ONTEÚDO

2.1.3 Sistema de Gestão da Qualidade... 18

2.2 APRESENTAÇÃO DO PROJECTO... 21

2.3 APRESENTAÇÃO DAS EQUIPAS DE TRABALHO... 21

3. METODOLOGIA E CALENDARIZAÇÃO ... 23

3.1 METODOLOGIA... 23

3.1.1 Plano de Software dos Futuros Lançadores... 23

3.1.2 Departamento da Qualidade ... 24 3.2 ACTIVIDADES DESEMPENHADAS... 24 4. ANÁLISE DO PROBLEMA... 29 4.1 TAREFAS DO PROJECTO FLPP2... 29 4.2 TAREFAS DE QUALIDADE... 30 5. CONCRETIZAÇÃO ... 31

5.1 PLANO DE DESENVOLVIMENTO VERIFICAÇÃO E VALIDAÇÃO DE SOFTWARE... 31

5.2 TAREFAS DO DEPARTAMENTO DA QUALIDADE... 34

5.3 FERRAMENTAS UTILIZADAS... 36 6. CONCLUSÕES ... 37 6.1 TRABALHO FUTURO... 37 6.2 CONCLUSÃO... 37 ACRÓNIMOS ... 40 DEFINIÇÕES ... 42 LISTA DE FIGURAS... 43 LISTA DE TABELAS ... 43 ÍNDICE REMISSIVO... 43 REFERÊNCIAS ... 44 ANEXOS... 45

A.1.PLANO DE GESTÃO DE CONFIGURAÇÃO DO XCEPTIONTM... 45

A.2.PLANO DE SUPORTE DO XCEPTIONTM... 45

A.3.PLANO DE GESTÃO DE PROJECTO DO XCEPTIONTM... 45

A.4.ACTA DE REUNIÃO DE ESTÁGIO... 45

A.5.CONCEITOS GNC... 45

A.6.PLANO DE DESENVOLVIMENTO,VALIDAÇÃO E VERIFICAÇÃO DE SOFTWARE DO FLPP2 ... 45

A.7.SQALOG BOOK... 45

14

1. Introdução

Após um período de aquisição de conhecimento é de esperar que um recém-licenciado tenha o potencial e o conhecimento para assegurar as suas funções com responsabilidade no mundo de trabalho tendo que para isso ser integrado em projectos reais. O Curso de Especialização Profissional em Engenharia Informática (CEPEI) é um curso de pós-graduação de cariz profissionalizante do Departamento de Informática da FCUL com o objectivo de integrar os alunos numa instituição de acolhimento, tipicamente externa, pública ou privada [2]. Nesse âmbito, surgiu a possibilidade deste estágio nomeado “Engenheiro da Qualidade” na empresa Critical Software S.A. nas instalações em Coimbra [6].

1.1

Motivação

A motivação da escolha de efectuar o estágio está relacionada com dois factores principais: a oportunidade profissionalizante e o âmbito do estágio.

O primeiro factor está relacionado com a forma como se processa o começo do estágio, sendo de alguma forma simplificado o seu início e com ele um começo de carreira no mundo real de trabalho.

O segundo factor, e mais significativo, está relacionado com o âmbito do estágio em causa, neste caso Engenheira da Qualidade. A cadeira de 4ºano (opcional) da área de Sistemas de Informação, designada Processos de Qualidade de Sistemas Informáticos, abriu o meu horizonte como Licenciada em Informática na forma como se desenvolve software. A referida cadeira tem como objectivo desenvolver capacidades de análise, de desenho, optimização e reutilização não só de processos de desenvolvimento de software mas de todos os restantes processos que lhe estão associados. De uma forma geral, apresenta noções do conceito qualidade, os objectivos e princípios associados à gestão de qualidade e apresentação de algumas normas de certificação (ISO 9001, CMMi, ISO/IEC 15504, IEEE/EIA 12207) [10].

Desta forma, a referida cadeira conseguiu numa vertente teórica cativar o meu interesse sobre o conceito qualidade e também sobre outros aspectos, por exemplo, como é feita uma certificação e por conseguinte a definição dos processos, a sua implementação, gestão e monitorização numa empresa real.

1.2

Objectivo

O objectivo do estágio de Engenheira da Qualidade é proporcionar o desenvolvimento de competências na área da qualidade através do estudo e o aprofundamento do Sistema de Gestão da Qualidade (SGQ) da Critical Software. O conhecimento do referido sistema é conseguido através do desenvolvimento de actividades de acompanhamento a projectos que se encontram em curso, a fim de assegurar o seu cumprimento [6].

15

O estágio está inserido na estratégia de consolidação da secção de Garantia de Qualidade, integrada na área da Confiabilidade, responsável pela prestação de serviços na área da qualidade a clientes externos. Esta secção tem como objectivo a implementação de Sistemas de Gestão de Qualidade, a auditoria a projectos, avaliação de processos e a respectiva apresentação de melhoria assim como a obtenção de certificados de qualidade.

A participação do estagiário estende-se também ao Departamento de Qualidade onde surgiu a oportunidade de aprofundar conhecimentos na mesma área e desenvolver competências relevantes.

Os objectivos genéricos do corrente estágio são [6]:

• Adquirir know-how em normas internacionais de qualidade, nomeadamente: ISO 9001:200, ISO 15504, ISO 12207 e CMMI;

• Acompanhar projectos em curso, acompanhar auditorias e avaliação de processos a fim de assegurar o cumprimento do Sistema de Gestão da Qualidade;

• Participar na manutenção e evolução do SGQ;

• Participar num projecto concreto da secção de Garantia de Qualidade (clientes externos).

1.3

Resultados do Estágio

Numa primeira fase, de forma a garantir o seguimento assertivo dos processos internos para o produto/projecto da empresa XcpetionTM, foram criados três documentos, estando a sua elaboração directamente relacionado com a fase de integração e aprendizagem do Sistema de Gestão de Qualidade da empresa. A tarefa principal do estágio esteve relacionada com o estudo/elaboração do Plano de Software do FLPP2. Por fim, e relacionado com as tarefas de SQA no Departamento da Qualidade surge a oportunidade da elaboração de um guia do SQA, onde é explicado todo o procedimento deste mesmo papel.

Como resultado do estágio, os seguintes documentos foram produzidos:

Nome do Documento

Plano de Gestão de Configurações do XcpetionTM Plano de Suporte do XceptionTM _(template)

Plano de Gestão de Projecto do XcpetionTM (template)

Plano de Desenvolvimento, Validação e Verificação de Software do FLPP2 SQA Guide Book

16

1.4

Organização do documento

O documento está organizado nas seguintes partes: no ponto 1 é efectuada uma introdução ao âmbito do estágio assim como a motivação e o objectivo do estágio; no ponto 2 a apresenta-se empresa de acolhimento; no ponto 3 é apresentada a metodologia de trabalho e a calendarização do estágio; no ponto 4 é efectuada uma análise do problema, ponto de partida para a realização do estágio; no ponto 5 é apresentada como foi efectuada a concretização do trabalho e no ponto 6, apresentam-se as conclusões. Por último, é apresentada a lista de acrónimos, definições, figuras e tabelas, assim como, o índice remissivo e a bibliografia. A secção de Anexos é apresentada os documentos utilizados e realizados no âmbito do estágio (confidenciais).

17

2. Apresentação

Esta secção tem como objectivo a apresentação da empresa de acolhimento e as suas diferentes competências finalizando com a apresentação com o papel da qualidade na empresa.

2.1

Apresentação da empresa

2.1.1 Missão

A missão da Critical Software é fornecer soluções, serviços e tecnologias fiáveis e inovadoras, para sistemas de informação críticos em empresas e organizações de diversos sectores, respondendo às necessidades de clientes de diversos mercados designadamente, telecomunicações, sector público, indústria, sector aeroespacial e defesa. Presta também serviços de consultoria e auditoria na área da Tecnologia de Informação. A empresa foi fundada em 1998 e emprega cerca de 300 pessoas, em escritórios localizados em Coimbra, Lisboa, Porto, San Jose na Califórnia e Southampton no Reino Unido [4]

O sucesso da CSW reside na utilização de níveis elevados de qualidade e inovação tecnológica como agentes na introdução de vantagens competitivas nos sistemas de informação e no negócio dos clientes e parceiros. O resultado prático é um portofólio sólido de soluções de elevada qualidade e conteúdo inovador, desenvolvidas dentro dos prazos e orçamentos com nível crescente de parcerias estratégicas com clientes de grande dimensão a nível nacional e internacional.

2.1.2 Áreas de competência

As áreas de competência permitem à empresa responder com flexibilidade aos desafios mais complexos dos clientes e parceiros. A empresa está dividida de uma forma estratégica em seis áreas de competência [4]:

• Enterprise Application Integration & Databases (EAI&DB);

• Redes e Comunicações;

• Sistema de Informação Fabris;

• Confiabilidade;

• Software de Ground Segment;

• Computação de Alto Desempenho ou HPC.

A área de EAI&DB lida com problemas complexos de integração e desenvolvimento de aplicações, aplicações em camadas múltiplas, aplicações orientadas à internet, desenho e optimização de bases de dados, data warehouse, data mining e soluções de integração

shop-flor utilizando para o efeito tecnologias abertas, recorrendo a boas práticas recomendadas pelas

18

A área de Redes e Comunicações centra-se no planeamento, desenho e desenvolvimento de soluções de comunicação. A comunicação eficiente é um ponto essencial nas organizações, sendo os sistemas de informação e as redes cada vez mais, tratados de uma forma integrada. Deste modo, existe uma grande necessidade de integração e mediação de sistemas, complementada pela necessidade de gerir, integrar e interligar múltiplos elementos da rede, protocolos e sistemas.

A área de Sistemas de Informação Fabris centra-se nos requisitos dos sistemas de informação de processos industriais e da sua integração com as linhas de produção. Os engenheiros desta área configuram soluções que respondem aos requisitos específicos dos diferentes processos industriais, desenvolvendo soluções numa plataforma comum, com componentes pré-desenvolvidos, validados e módulos testados.

A área de Confiabilidade centra-se na preocupação crescente sobre os aspectos de confiabilidade de sistemas de software e computadores. Actualmente, esta é uma questão vital devido à crescente importância do software na vida quotidiana e ao seu papel de controlo de processos e aplicações empresariais e críticas. Esta área abrange competências em técnicas de RAMS (Reliability, Availability, Maintainability and Safety), FDIR (Fault Detection, Isolation

and Recovery) e ISVV (Independent Software Verification and Validation). Em particular, como

fornecedora de ISVV, a empresa faz verificação de software e serviços de validação para vários mercados como o aeroespacial, automóvel, defesa, saúde, telecomunicações e finanças. A sua posição independente permite à CSW ter um estatuto único neste mercado.

A área de Software de Ground Segment fornece soluções para o sector das comunicações e

User Segment, sobretudo para o sector espacial, aeronáutico e defesa.

A área de Computação de Alto Desempenho dedica-se à resolução de problemas de desempenho dos Sistemas de Informação de empresas e organizações. Nos serviços estão incluídos a optimização, afinação e parameterização de processos, desenvolvimento de aplicações paralelas e paralelização de código. Os problemas solucionados abrangem o controlo de grandes volumes de dados, processos de escala (mais dados, mesmo tempo), aceleração de processos (mesmos dados, menos tempo) e a implementação de processos complexos e algoritmos.

2.1.3 Sistema de Gestão da Qualidade

A aposta da Critical Software na qualidade de software foi uma decisão de grande importância e de carácter estratégico tendo em conta a sua competência chave: desenvolvimento de soluções de alta segurança, fiabilidade, disponibilidade e desempenho de sistemas críticos permitindo a competitividade com outras empresas de grande importância. A prova dessa

19

aposta, está patente no facto de no primeiro ano de existência, ter conseguido que a Agência Aeronáutica e Espacial (NASA - National Aeronautics Space Agency) dos Estados Unidos da América se tornasse seu cliente.

Desde cedo, existiu a preocupação em garantir a implementação de regras básicas, procedimentos e ferramentas que por um lado, tinham como objectivo garantir a consistência nas tarefas, e por outro, o cumprimento de normas exigidas pelo sector aeroespacial, como por exemplo, as normas da Comunidade Europeia para a Normalização Aeroespacial (ECSS) e as recomendações do Laboratório de Engenharia de Software da Agência Aeronáutica e Espacial Nacional (NASA-SEL National Aeronautics Space Agency – Software Engineering Laboratory).

Numa primeira fase, o número reduzido de colaboradores, de projectos e a proximidade entre as pessoas não exigia um Sistema de Gestão de Qualidade (SGQ) com mais do que alguns processos de gestão e implementação. Porém, o crescimento da empresa (a nível de projectos e consequentemente de pessoal) obrigava a adaptação do SGQ às crescentes exigências da Critical [7].

Em Janeiro de 2000, Portugal aderiu à Agência Espacial Europeia (ESA – European Space Agency) e na mesma altura a ESA estava a seleccionar empresas europeias para testar o modelo experimental de avaliação de processos orientada à indústria aeroespacial “Spice for Space” (S4S). O modelo S4S é totalmente compatível com a norma ISO 15504, também conhecida por “Processos de Melhoria de Software e Determinação da Capacidade” (SPiCE). Visto que a Critical possuía fortes competência no sector aeroespacial, ganhou a candidatura à avaliação do S4S tendo dado início a um processo de melhoria dos processos. Em Maio de 2003, a Critical atingiu o nível 3 (numa escala de 0 a 5) de maturidade de acordo com os critérios de avaliação ISO 15504.

Segundo o manual de qualidade da Critical, as práticas rigorosas de gestão, coordenação e controlo de projectos e processos de engenharia do SGQ baseiam-se nas seguintes normas de qualidade internacionalmente conhecidas [7]:

• ECSS: normas europeias, definidas pela ESA, para o desenvolvimento de projectos no sector aeroespacial;

• ISO 9001:2000: normas internacionais para a garantia de qualidade em produtos e serviços;

• TickIT: interpretação da norma ISO 9001:2000 especialmente vocacionada para o desenvolvimento de software;

• ISO 12207: normas internacionais para processos de ciclos de vida no desenvolvimento de software;

• ISO 15504: normas internacionais para a avaliação da maturidade e capacidade de processos;

20

A certificação é um aspecto fulcral na projecção da empresa e na possibilidade de novos projectos em variadas áreas.

A empresa CSW opera com base num sistema de qualidade certificado que segue a norma ISO 9001:2000 segundo o referencial TickIT (British Standard Institute), sendo actualmente a única empresa Ibérica certificada.

Em 2005, realizou a certificação na área da defesa através do AQAP 150 e AQAP 2100 (certificação da NATO) com o objectivo de satisfazer os requisitos contratuais para qualquer cliente desta área.

Em 2006, consegue a certificação nível 3 do CMMI, equivalente à ISO 15504 (SPiCE); esta certificação fornece um guia sobre como tirar benefício através do controlo dos processos existentes da empresa. A certificação CMMI está a tornar-se uma referência mundialmente reconhecida como uma medida do desempenho de desenvolvimento de software e das empresas de engenharia, principalmente nos mercados americanos e asiáticos aumentando assim as possibilidades de negócio da empresa.

Para além das certificações referidas, consegue também a certificação EN9100 e EN9006. A certificação EN9100 é uma certificação da área aeroespacial com objectivo do aperfeiçoamento na qualidade e a viabilidade do sistema de qualidade de requisitos para a indústria aeroespacial. A certificação EN9006 tem como objectivo a unificação de requisitos para fornecedores de software. As certificações são uma extensão da ISO 9001 como o objectivo de melhorar o sistema de qualidade da empresa.

Figura 1 – Mapa de certificações da empresa [3]

A Qualidade representa assim um importante factor distintivo e uma vantagem competitiva para a empresa, num mercado que é extremamente concorrente. As vantagens para os clientes traduzem-se na condução de projectos dentro dos prazos e orçamentos, elevada qualidade das soluções entregues e redução de custos.

Os processos de qualidade na CSW incluem a organização e gestão, em que a engenharia e suporte são adaptados às necessidades específicas de cada cliente e projecto. Esta flexibilidade

21

permite à empresa dar uma resposta adequada a projectos de natureza e níveis de criticalidade distintas.

O processo de melhoria do SGQ é contínuo e definido com base nos comentários e níveis de satisfação dos seus clientes, com a colaboração directa do retorno da utilização pelas várias áreas de engenharia da empresa e por fim, de acordo com normas e práticas internacionais de engenharia de software.

2.2

Apresentação do projecto

O estágio assenta em duas áreas distintivas da empresa: Confiabilidade e no Departamento de Qualidade.

Na área da Confiabilidade, relacionada com tarefas de validação e verificação para clientes externos, surge a oportunidade de participar na especificação de um plano de software Verificação & Validação no âmbito do projecto dos Futuros Lançadores da ESA (FLPP2) tendo como base os standards (nomeadamente, ECSS E-40 e ECSS E-80) criados pela mesma entidade. Desta forma, é necessário saber aplicar o rigor dos standards tendo em conta os objectivos do plano a realizar e do seu objectivo final conseguindo por fim uma solução objectiva e criativa.

A contribuição do presente estágio na área da Qualidade é conseguida através do papel de

Software Quality Assurance que tem como objectivo a monitorização dos projectos através de

métodos que permitem a avaliação da conformidade dos mesmos com o SGQ assim como a identificação de problemas (não conformidades) e melhorias. Desta forma, é necessário desenvolver competências a nível da comunicação e conhecimento do SGQ de forma a depreender se o projecto está em concordância com os processos internos.

2.3

Apresentação das equipas de trabalho

O orientador de estágio por parte do Departamento de Informática da Faculdade de Ciências da Universidade de Lisboa é o Professor Luís Moniz e o supervisor por parte da Critical Software S.A. é o Engenheiro José Gonçalo Silva.

O trabalho desenvolvido desenrola-se em duas áreas distintas da empresa. A primeira equipa, relativa ao projecto FLPP2, é constituída por três elementos: Paulo Fernandes (Gestor de Projecto), Paulo Sacramento (Engenheiro de Projecto) e Nuno Silva (Engenheiro Técnico de Projecto). O cliente final do projecto FLPP2 é a ESA que contratou a EADS Astrium que por sua vez contratou a Critical Software S.A.. A segunda equipa, relativa a equipa do Departamento de Qualidade, é constituída por cinco elementos: Carla Nogueira (Responsável pelo o Departamento da Qualidade), Filipe Fonseca (Responsável pelo os SQAs), Susana Boavida (Suporte), Braselina Sousa (Suporte; Melhorias dos processos) e Ricardo Jesus (Responsável pelas Auditorias internas e externas).

22

Adicionalmente, o papel de SQA permitiu uma interacção com diferentes projectos e equipas (nomeadamente Gestores de Projecto) acelerando o aprofundamento das competências devido a uma maior diversidade de problemáticas.

23

3. Metodologia e Calendarização

Nesta secção é apresentada a metodologia de trabalho seguida em ambas as áreas que assentam o âmbito do estágio.

3.1

Metodologia

3.1.1 Plano de Software dos Futuros Lançadores

A elaboração do documento designado Software Development Verification and Validation Plan (SDVVP) tem como objectivo a especificação de um plano de desenvolvimento para além da componente de verificação e validação do mesmo tendo em conta os contexto e o seu objectivo.

Esta tarefa foi iniciada com a leitura de vários de documentos que serviram como base da elaboração do documentos, nomeadamente standards, sendo eles [16]:

• “Technical Proposal FLPP Period 1 Phase 2”, 2006, Critical Software; • “Quality Management Process” Critical Software S.A., 2006;

• “Software Development Process”, Critical Software S.A., 2006; • “Software Design”, Critical Software, 2006;

• “Reuse Process”, Critical Software, 2006; • “Verification Process”, Critical Software, 2006; • “Design Process”, Critical Software, 2006;

• “Galileo Software Standard”, 2004, Gain Industries; • “Project Life Cycle”, Critical Software, 2005; • ECSS Standards (ECSS-Q-80b e ECSS-E-40b);

• “Software Engineering Body of Knowledge”, Alain Abran & James W.Moore, 2004.

O ponto de partida para a elaboração da tabela de conteúdos foi o Galileo Software Standard (GSWS), que apesar de ter sido criado no âmbito do projecto Galileo (GPS Europeu) fornece informação que pode ser aplicada noutros contextos diferentes. Para além deste factor, o GSWS foi criado com base nos ECSS que vai ao encontro do requisito explicitado na proposta técnica para o cliente EADS Astrium que obriga a que o referido plano de software seja elaborado com base nos mesmos.

Após a revisão e aprovação da tabela de conteúdos pela equipa, deu-se início à fase de elaboração dos conteúdos do documento. Esta fase foi iniciada num momento em que o contexto em que o plano de desenvolvimento de software assentava não era claro visto que, por factores externos, a Reunião de Inicio do Projecto ainda não se tinha realizado. Desta

24

forma, o preenchimento dos conteúdos do documento foi feito com uma postura abrangente para que o impacto das alterações fosse minimizado.

Esta fase foi finalizada com uma revisão do documento, de forma a detectar incoerências ou erros nos conteúdos como um todo, passando para uma versão estável mas não aprovada.

Em meados de Abril, a reunião de início de projecto foi realizado com o cliente EADS Astrium, na Alemanha, onde foram esclarecidas algumas questões pertinentes para a realização do plano. Nesta altura, o cliente identificou o objectivo do plano de desenvolvimento de software, assim como problemas de gestão identificados em projectos passados. Assim, era possível nesse momento do estágio, perceber com mais clareza para quem, para quê e como o plano de software deveria ser direccionado.

Por fim, o plano foi convenientemente reformulado de forma a ser aplicável à realidade apresentada não descuidando os problemas identificados pelo o cliente. Esse plano foi submetido a revisão formal pela equipa enviado por fim, ao cliente para aprovação.

3.1.2 Departamento da Qualidade

Para que o referido SGQ seja seguido pelos os elementos da empresa, surge a criação de uma responsabilidade designada por SQA que tem o papel de orientar a implementação do dito sistema. Assim, o acompanhamento dos projectos é feita através de reuniões de progresso, auditorias e avaliações de qualidade. Para além disso, o SQA tem de ter uma atitude crítica de forma a avaliar como os processos poderão ser melhorados permitindo uma melhor adequação aos projectos tendo em conta ao que as certificações obrigam.

Esta competência foi conseguida, em linhas gerais, por três fases principais: o estudo dos processos chave, o acompanhamento por SQAs mais experientes e a aplicação do conhecimento conseguido. A primeira fase, em complemento com a tarefa de elaboração do plano de desenvolvimento, consistiu na leitura dos principais processos internos assim como a familiarização de algumas ferramentas de apoio a este tipo de tarefa. Na segunda fase, foi feita a observação e acompanhamento de projectos com outros SQAs de forma a interiorizar a postura correcta a seguir, para além de perceber com mais clareza o que significam cada um dos pontos do guia do SQA, designada por SQA Log Book (no Anexo 0). Por fim, foi delegado alguns projectos para que os conhecimentos fossem aplicados de forma a adquirir autonomia, experiência e sentido crítico em relação a este papel sendo que o número e a complexidade dos projectos a serem monitorizados foram crescendo ao longo do estágio.

3.2

Actividades desempenhadas

As tarefas realizadas ocorreram de forma paralela e estão conceptualmente divididas em duas áreas diferentes: Confiabilidade e Qualidade.

25

A intervenção com a primeira área está relacionada com a tarefa de elaboração do plano de

software para o FLPP2 representando na imagem seguinte, estando dividia em três fases

principais: estudo, elaboração e revisão.

Figura 2 – Calendarização das tarefas referente à elaboração do plano de software

No mundo real de trabalho é comum existirem atrasados (por parte do cliente e não só) nomeadamente clientes de grande peso e projectos de grande complexidade. Em particular, os projectos da área aeroespacial são caracterizados por um elevado nível de entropia relativamente ao seu contexto técnico devido, principalmente, à componente de investigação associada. Desta forma, o projecto FLPP2 não foi excepção tendo começado, formalmente, muito mais tarde do que esperado, apesar de internamente ter sido dado ao seu seguimento de forma a não comprometer os objectivos do estágio.

A primeira fase ocupou uma parte significativa do estágio estando incluídas a fase de integração (aproximadamente 1 mês) e da realização de algumas tarefas internas que permitiram uma aprendizagem mais prática do que estava efectivamente a ser estudado. Dessas tarefas estão incluídas a realização de um Plano de Gestão de Configuração Interno (CMP), Plano de Suporte (template) e um Plano de Gestão de Projecto (template) para o produto da Critical Software designado XceptionTM permitindo a aplicação de alguns processos internos assim como a integração no Departamento de Confiabilidade.

Concluída esta fase, de meados de Novembro a meados de Janeiro, deu-se início à realização da tabela de conteúdos do plano de software, tendo como base os documentos lidos e informação da proposta técnica. Após a sua revisão e aprovação iniciou-se a elaboração dos conteúdos do documento, sendo acompanhada por uma fase de revisão informal (mês de

07 Mar 2º versão

Elaboração do plano de software para o FLPP

04/Set/06 Out/06 Nov/06 Dez/06 _{Jan/06 Mar/06 Abril/06 31.Maio/07}

- Macros do Projecto Fev/06 10 Abril KOM interna 10 Mar KOM externa - Início da tarefa 14 Nov Início Tabela de Conteúdos 22 Dez 1º versão TC Estudo da documentação 25 Jan 1º versão Revisão e alterações Ajuste

S

S

S

S

S

S

S

S

S

S

S

S

S

S

26

Fevereiro) por alguns dos elementos da equipa permitindo ter um retorno do trabalho efectuado até ao momento.

Em Março de 2007 realizou-se a Reunião de Inicio do Projecto com o cliente, na Alemanha, permitindo à equipa colocar algumas questões (no âmbito do estágio e não só) e clarificar o propósito do plano e a sua aplicação assim como problemas e dificuldades identificadas noutros projectos anteriores com o mesmo âmbito. Neste momento, passaram a existir bases sólidas para proceder ao ajuste do conteúdo permitindo um maior rigor e detalhe.

Esta tarefa terminou com a entrega do documento para uma revisão técnica formal de forma a criar uma versão estável para ser disponibilizada à EADS Astrium.

A colaboração com o Departamento da Qualidade verificou-se através do desempenho de responsabilidade de SQA e mais tarde na melhoria de um documento guia (SQA Guidebook) (Anexo 0) sobre o papel de SQA. A calendarização dessas mesmas tarefas é apresentada na imagem em seguida:

Figura 3 – Calendarização das tarefas referente ao Departamento de Qualidade

Numa primeira fase, foi necessário um acompanhamento mais regular por parte de SQAs mais experientes para que, como nova SQA, começasse a produzir valor e conseguisse autonomia para intervir sozinha. Após esse período, foram delegados alguns projectos de forma a ser possível aplicação do conhecimento adquirido, em paralelo com o objectivo interno de garantir que todos os projectos em aberto na empresa tenham um acompanhamento/monitorização por parte de um SQA.

Tarefas Departamento da Qualidade

04/Set/06 Out/06 Nov/06 Dez/06 _{Jan/06 Mar/06 Abril/06 31.Maio/07}

- Inicio de acompanhamento de projectos Fev/06

Projecto MGF

- Marco das tarefa (SQA Guidebook)

12 Mar Início da elaboração do SQA Guide Book Acompanhamento

S

S

S

S

S

S

S

S

S

S

S

S

S

7 Maio Apresentação

27

A tarefa de SQA implicou um acompanhamento semanal de forma a ser possível apurar e antecipar possíveis problemas e não conformidades de forma a assegurar o cumprimento do SGQ da empresa. Esta tarefa exigiu uma intervenção activa no projecto, nomeadamente, a participação nas reuniões de progresso, reuniões de milestone, preenchimento de uma check-list que indica o nível de qualidade do projecto (SQA Log Book – Anexo 0), avaliação do projecto, criação de acções correctivas/preventivas, manutenção de alguns documentos e o preenchimento de um relatório semanal (SQA Form).

Na fase final de intervenção como SQA surgiu a possibilidade de formalizar o conhecimento adquirido num documento designado por SQA Guidebook que possibilitou o registo da experiência adquirida e o processo defendido pelo o Departamento da Qualidade, com objectivo final de apoiar mais e melhor todos os SQAs no exercício das suas funções e desta forma uniformizando as práticas subjacentes. Após a sua realização e revisão por parte do departamento responsável, este foi apresentado numa reunião de SQAs formalizando a sua aceitação.

Apesar de não terem sido referenciadas nos calendários apresentados anteriormente, ao longo do estágio realizaram-se outras actividades importantes: reuniões de progresso de estágio, reuniões de SQAs, reuniões do projecto FLPP2 e formações internas.

As reuniões de progresso de estágio (Anexo 0) foram realizadas de uma forma regular (numa base semanal e mais tarde quinzenal) com o supervisor José Gonçalo Silva permitindo um acompanhamento directo da intervenção da estagiária na empresa, tendo como resultado actas de reunião.

As reuniões de SQA tiveram como objectivo a apresentação de alterações importantes no processo que interfiram directamente com essa actividade, para além de permitir a exposição de dúvidas, problemas e sugestões.

As reuniões do projecto FLPP2 permitiram um acompanhamento das tarefas da equipa bem como a discussão das tarefas seguintes, prazos e monitorização de riscos e acções.

A formação na empresa foi uma constante, tendo especial incidência na primeira fase do estágio. As formações pertinentes realizadas durante o estágio foram as seguintes: ISO/IEC 15504 (SPiCE), análise RAMS, “Qualidade para os novos colaboradores”, formação para novos SQAs e “Writing Convincingly”.

Na primeira formação, que está relacionada com a participação directa com o Departamento da Qualidade, foi abordada a norma ISO/IEC 15504 (SPiCE) para a avaliação de processos de

software de uma forma esquematizada e com exemplos práticos. De uma forma sucinta, esta

norma define um modelo bidimensional que tem por objectivo a realização de avaliações de processos com o propósito de os melhorar (gerando o respectivo perfil e identificando os pontos fracos e fortes que serão utilizados para a elaboração de um plano de melhorias) e a

28

determinação da capacidade dos processos viabilizando a avaliação do potencial de um fornecedor.

Na segunda formação foi apresentada a definição, o processo e métodos de suporte à análise RAMS sendo a mesma incluída no plano de software para o FLPP2. Esta análise é uma condição habitual para a implementação de missões críticas que tem como objectivo demonstrar que o sistema está de acordo com os requisitos de segurança e caso isso não se verifique, modificar os mesmos para que no final os pressupostos de segurança se verifiquem.

Na terceira formação, designada por Qualidade para os novos colaboradores, foram apresentados os processos, práticas e normas descritos no SGQ seguidas pela empresa com objectivo de elucidar os novos colaboradores a importância do conceito de qualidade e de que forma os processos deverão ser implementados e seguidos.

Na quarta formação, designada por formação para novos SQAs foi apresentada a definição do papel do SQA, como este deve agir, para além das principais tarefas, e a forma de as elaborar de uma forma eficiente.

Na quinta formação, designada “Writing Convincingly” foram apresentadas técnicas e exemplos práticos de como escrever de uma forma convincente.

29

4. Análise do Problema

Nesta secção são apresentas as tarefas no âmbito do projecto FLPP2 assim como tarefas realizadas no Departamento da Qualidade.

4.1

Tarefas do projecto FLPP2

O programa FLPP2 surge no âmbito da Europa pretender ser uma referência de topo no que toca a tecnologia de reentrada dos futuros veículos aeroespaciais. Os estudos que foram efectuados sobre a tecnologia de reentrada crítica e o desenvolvimento da mesma, permitiram a passagem para a fase de criação de veículos experimentais, em particular o Veículo Experimental Intermédio (Intermediate eXperimental Vehicle - IXV) que permitam consolidar conhecimentos e a posição da Europa neste campo [16].

O plano de desenvolvimento de software elaborado assenta no desenvolvimento da parte de orientação, navegação e controlo (GNC ou Guidance, Navigation and Control) do veículo, ou seja, o software responsável pelo voo do veículo que permite direccionar e o controlar o mesmo, desde a sua posição inicial (em repouso) até ao seu objectivo, algures no espaço e o seu regresso seguro para Terra.

De forma a tornar a sua complexidade clara, são apresentadas em Anexo 0, os conceitos técnicos importantes no âmbito do projecto.

O documento desenvolvido poder-se-á dividir em duas partes principais: plano de desenvolvimento do software e plano de verificação e validação do software.

O plano de desenvolvimento de software de um projecto é de extrema importância pois define os métodos e práticas ao longo da duração do projecto, que deve ser aplicável para a resolução de problemas que eventualmente irão surgir ao longo do projecto. Assim, o plano de desenvolvimento de software deverá especificar um processo de desenvolvimento de software, definir o tipo de projecto em causa, definir uma estrutura das fases, detalhar cada uma das fases de desenvolvimento definindo as revisões e actividades de cada fase, definir orçamentos e escalonamento de tarefas das pessoas envolvidas, gestão de artefactos a entregar, identificação de riscos, definição de recursos e competências técnicas da equipa.

A informação definida no plano deverá ter em conta os objectivos, as necessidades, as actividades e os riscos do projecto em causa fornecendo assim um nível de orientação adequado e de informação relevante para cada um dos elementos envolvidos no projecto, confiança aos colaboradores e a definição dos resultados a produzir tendo em conta os

30

requisitos e expectativas. Assim o plano irá, de forma sistemática, controlar o desenvolvimento e com isso poderá potencialmente aumentar a eficiência e a eficácia do desenvolvimento de um projecto.

O plano de verificação de software é um documento onde deve estar definido um processo de forma a assegurar que o software que está a ser desenvolvido irá satisfazer os requisitos funcionais ou outros. Em cada passo do processo deverá ser garantido que o resultado produzido é o esperado, aumentando assim a qualidade do projecto, reduzindo os custos e os riscos durante o desenvolvimento do mesmo. Desta forma, o processo de validação avalia se o projecto está a cumprir o compromisso, tendo em conta os requisitos e parâmetros definidos, determinando quando é que os mesmos estão completos e correctos e, finalmente, que o trabalho produzido para cada fase satisfaz as condições impostas pela fase anterior. Esta avaliação é conseguida através da análise e da inspecção intermediária de todos os itens produzidos durante o projecto. Assim, este plano deverá cobrir todas as actividades que serão levadas a cabo em todas as fases do ciclo de vida.

4.2

Tarefas de Qualidade

Tendo em conta o peso estratégico que a Qualidade tem na empresa e a existência de um SGQ, é necessário garantir que os processos definidos são seguidos, e em caso de não conformidade, apurar a causa para que, se aplicável, melhorar o referido SGQ.

Neste contexto, surge o papel de SQA que pretende apurar se os processos estão de facto a ser seguidos através de uma postura positiva e motivante.

Numa primeira instância impõe-se o conhecimento rigoroso sobre o SGQ de forma permitir a avaliação da conformidade do projecto em causa. Para isso, é necessário o desenvolvimento de competências de comunicação para entender, com uma maior facilidade, as necessidade e dificuldades da equipa bem como as oportunidades, permitindo sempre que possível uma apresentação positiva e coerente do porquê da existência dos processos e das vantagens em seguir os mesmos.

31

5. Concretização

Nesta secção é apresentada a concretização das tarefas apresentadas na secção anterior, relativamente ao projecto FLPP2 e à colaboração com o Departamento da Qualidade.

5.1

Plano de Desenvolvimento Verificação e Validação de Software

No âmbito do projecto FLPP2, os artefactos criados são os seguintes [16]:

• IXV Software Requirements Specification (Onborard Software): especificação dos requisitos de software de bordo que IXV deve implementar:

• IXV Software Requirements Specification (Ground Software): especificação dos requisitos de software da secção ground que o IXV deve implementar.

• Software Development Verification and Validation Plan: documento elaborado durante o estágio que define um plano de desenvolvimento de software para o GNC.

• Preliminary Software Architecture Design Document: especificação do desenho da arquitectura do IXV.

• Software Interface Requirements Defininition for each Software product: especificação dos requisitos de interface para cada componente de software considerados no desenvolvimento do IXV.

• Software Re-use File: análise de reutilização (documentos, desenho, software, entre outros) aplicável ao desenvolvimento do IXV.

O ponto de partida da definição do plano foi necessariamente os standads ECSS (ECSS-E-40 e ECSS-E-80) da ESA com especial atenção para o Software Validation Facilities (SVF) e aplicações EGSE. Para além dos últimos standards referidos, foi também utilizado o Galileo Software Standard (GSWG).

O primeiro desafio no estudo dos referidos documentos foi interiorizar a sua estrutura visto que são bastante extensos e complexos e incluem muita informação que tem que necessariamente ser filtrada. Desta forma, a fase seguinte foi determinar de que forma a informação apresentada poderia ou deveria ser aplicados na elaboração do plano tendo em conta o seu objectivo.

Conforme referido na secção Actividades desempenhadas, nesta fase do projecto ainda não eram claros os objectivos do plano de software devido ao facto do mesmo não se ter

32

iniciado (por parte da EADS Astrium) sendo portanto vago para onde o plano deveria ser direccionado.

A abordagem inicial foi necessariamente generalista, de forma a permitir que os conteúdos não divergissem do objectivo e âmbito, não tendo sido, apesar disso, uma tarefa simples. Desta forma, o GSWS foi a principal base do documento devido à relativa clareza e objectividade, em particular, referente ao plano de desenvolvimento de software e verificação & validação. Para além disso, as tarefas de SQA obrigaram a um conhecimento mais profundo do SGQ da empresa, sendo que a grande parte dos processos (os aplicáveis na elaboração do plano de software) foram criados com base nos referidos standards, permitindo assim uma visão mais abrangente e uma fonte mais prática e consistente.

Numa segunda fase, a reunião de início do projecto foi realizada permitindo à equipa expor dúvidas e à EADS Astrium de expor os objectivos relativamente ao plano (e não só) para além de problemas identificados em projectos anteriores. Desta forma, foi dado como input pelo o cliente um exemplo do ciclo de vida utilizado em projectos anteriores do mesmo género, tendo sido apresentadas as suas características e os principais problemas dando início ao desafio principal da elaboração do plano de software tendo em conta as características do referido software para GNC.

O ciclo de vida apresentado pelo o cliente tem como base a abordagem em V [5] caracterizada pelo ênfase das fases de teste (verificação e validação) de acordo com a criticalidade do desenvolvimento deste tipo de software. Para além da sua componente crítica, este tipo de

software é caracterizado por uma grande número de algoritmos que apenas podem ser validados

em ambientes simulados. A existência de uma solução de qualidade depende em grande parte dos testes efectuados depois da integração das componentes envolvidas.

O cliente EADS Astrium identificou a necessidade da existência de três equipas diferentes (equipa de Software, equipa de desenvolvimento de Algoritmos e a equipa de Validação), a complexidade da integração (intermédia e final) das componentes (software e algoritmos) que implementam o sistema GNC e da validação unitária. As características identificadas podem ser definidas em três conceitos diferentes: equipas, testes e integração. A nova solução incluída no plano de desenvolvimento de software teria de apresentar uma solução criativa para as referidas características não descuidando os standards de referência (nomeadamente o ciclo de vida do GSWS).

A necessidade de equipas diferenciadas e especializadas foi identificada pelo o cliente noutros projectos anteriores, visto que o software que implementa o GNC é constituído por algoritmos complexos. Desta forma, a equipa de Software é responsável pela implementação da maior parte do software assim como decisões sobre a arquitectura e interface software/algoritmos. A equipa de desenvolvimento de Algoritmos é portanto responsável pela a especificação e implementação dos algoritmos necessários. Por fim, sendo a validação um factor crucial para a qualidade da

33

solução que está a ser desenvolvida, é nomeada uma terceira equipa designada equipa de Validação, responsável por validar algumas fases do projecto,

A solução final teve de incluir a informação cruzada do ciclo de vida apresentado pelo o cliente e o GSWS. Desta forma, a primeira alteração à proposta foi a inclusão de uma fase designada Fase de Planeamento (Planning phase) que teve como objectivo a definição, pela equipa de Software, do custo, do planeamento e de outros aspectos de gestão de forma a tornar claro as funções, datas e modus operandi dos intervenientes.

Outra característica adicionada, foi o facto de as equipas trabalharem de forma independente sendo definidos rigorosos pontos de sincronização de trabalho de forma a permitir alterações garantido a consistência da solução final. Para permitir este facto, foi necessário definir a comunicação entre as equipas e como esta deveria ser efectuada, sendo um ponto fulcral na parte de integração visto que, as três equipas envolvidas teriam que encontrar uma forma eficaz de reportar e interagir face a problemas encontrados.

A fase de Desenho Preliminar (Preliminary Design) foi delegada à equipa de Software permitindo que a equipa de desenvolvimento de algoritmos se concentrasse apenas nessa mesma tarefa, devido à sua complexidade, sendo definidos momentos de sincronização para que as decisões da equipa de Software fossem ajustadas com a realidade dos algoritmos especificados.

Outra diferença significativa da nova solução foi o facto da integração acontecer apenas quando as duas componentes (software e algoritmos) estivessem terminadas tendo passado na primeira fase de testes. Isto significa que a integração aconteceria quando o componente software passasse nos Testes Unitários e a parte dos algoritmos passasse na Validação (realizada pela a equipa de Validação) permitindo a detecção de problemas o mais cedo possível.

A imagem representa as fases e os pontos de sincronização identificados na nova solução:

Figura 4 – Fases e Macros do projecto [1];[12]

Em conclusão, a nova solução debruça-se sobre a minimização do impacto da coexistência de três equipas de forma a uniformizar a comunicação tendo em especial atenção a fase de testes de

34

integração. Por outro lado, é garantido que os testes unitários acontecem antes da integração ao contrário do que era proposto pelo o cliente. A solução criada no âmbito do plano de software (sendo descrita em detalhe no mesmo), é apresentada na Figura 4.

Figura 5 – Ciclo de Vida apresentado no plano [1];[12]

Em conclusão, a elaboração do plano de desenvolvimento de software obriga a uma postura crítica relativamente à complexidade do tema e a um alto nível de rigor a que os standards obrigam, não descuidando a criatividade e inovação das soluções, tornando o referido plano numa ferramenta prática, objectiva e aplicável à realidade em que a mesma se insere.

5.2

Tarefas do Departamento da Qualidade

O papel de SQA obriga a um acompanhamento regular do projecto tendo por base as evidências da concretização dos objectivos definidos para além da orientação da equipa sobre os objectivos a cumprir no futuro.

As actividades realizadas por um SQA são as seguintes [15]:

• Elaboração do Plano de Garantia de Qualidade (QAP – Quality Assurance Plan), sendo uma primeira versão publicada na KOM do projecto;

• Preenchimento de um guia designado SQA Log Book, obrigatório no caso de reuniões de milestone e a avaliação na ferramenta WISE (ver secção seguinte); FES SVF (Close-SVF (Open-TEAMS Algorithms Software Numerical Validation Implementation Implementation Software Detailed design Verification Algorithm Detailed Design Host GNC integration Preliminary design Preliminary analysis Preliminary analysis Planning phase Integration Verification and Validation FES Numerical Validation Validation Qualification Prototyping

35

• Verificar que a documentação está a ser produzida (relatórios de esforço, planos de progresso, actas de reunião, entre outros);

• Verificar que as entregas ao cliente estão a ser revistas pela a equipa de acordo com o plano;

• Verificar a conformidade do projecto face ao SGQ;

• Levantar não conformidades sempre que estas são detectadas, através da ferramenta Work Orders (WO) (ver secção seguinte), permitindo um acompanhamento assertivo e o não esquecimento das correcções a efectuar.

A realização do QAP tem como objectivo a identificação das actividades de qualidade assim como as decisões de tailoring e as diferenças relativas ao SGQ assim como as respectivas justificações. Ao longo do ciclo de vida do projecto, é aceitável que este plano se altere sendo da responsabilidade do SQA garantir a sua actualização.

O preenchimento do SQA Log Book tem como objectivo o registo global do projecto assim como a determinação do nível de conformidade (avaliação) com os processos internos tendo em conta a fase do projecto. Para além disso, possibilita a passagem de projectos entre SQAs sem que a informação sobre o histórico do projecto se perca.

A avaliação do projecto (verde, amarelo ou vermelho) é feita através do referido SQA Log Book permitindo o levantamento de acções caso haja ‘não conformidades’ sendo efectuada a comunicação do resultado da avaliação aos responsáveis pela área, qualidade e Gestor do Projecto o estado do projecto. Esta avaliação obriga a um preenchimento de Relatório de Avaliação (PAR – Product Assurance Report) onde fica registada a avaliação do mesmo, a descrição dos artefactos produzidos e os objectivos atingidos (ou não) no momento em que o projecto foi avaliado.

O preenchimento do SQA Form permite o registo do estado global dos projectos da empresa permitindo aos responsáveis da área aceder ao estado das tarefas de qualidade e o nível de conformidade dos projectos em relação ao SGQ.

Todas as tarefas referidas acima terão de ser realizadas para cada um dos projectos em que o SQA é responsável, tendo como objectivo final a identificação de alterações a realizar ao SGQ permitindo um melhor ajuste dos processos à realidade da empresa.

36

5.3

Ferramentas utilizadas

As ferramentas de software utilizadas para o desenvolvimento do projecto são as seguintes:

Nome Versão Notas

MS Word 2003 Edição de texto

MS Excel 2003 Folha de cálculo

MS Visio 2003 Criação de desenhos e diagramas técnicos.

Acrobat Reader 8 Leitura de documentos em formato PDF.

CVS 2.0 Repositório e ferramenta de gestão de versões.

WISE -

Sistema de Informação da Empresa (registo de esforço, informação sobre os projectos, registo de documentos, acesso aos processos e documentos do SGQ, entre outras funcionalidades).

WO - Sistema de registo e levantamento de acções.

37

6. Conclusões

Nesta secção é apresentada um balanço da minha colaboração com a Critical Software no âmbito do estágio Engenheiro de Qualidade.

6.1

Trabalho futuro

O projecto FLPP2 tem como artefactos um conjunto de documentos, no qual se insere o plano de software elaborado no âmbito deste estágio. Os documentos são referentes aos requisitos do IXV (requisitos de software de bordo, requisitos de software de ground, requisitos de interface), arquitectura, análise de reutilização e por fim, o plano de software [Critical Software, 2006d].

No fim do corrente estágio, os documentos de requisitos de software e o plano de software foram entregues ao cliente EADS Astrium, estando a equipa a aguardar os comentários do mesmo para proceder à correcção e revisão formal numa reunião (nas instalações de Coimbra) que deverá acontecer em meados de Junho. A partir do momento em que a fase de aceitação do plano de software for realizada, termina a colaboração no projecto FLPP2 no âmbito do estágio, continuando no entanto, a elaboração pela equipa dos documentos em falta.

Por outro lado, a intervenção com o Departamento de Qualidade, nomeadamente a partir das tarefas de SQA, permitiram desenvolver competências de comunicação e ao nível do SGQ abrindo portas para uma colaboração pós-estágio com a empresa, em projectos internos e externos de elevada responsabilidade, esperando boas perspectivas de futuro, tanto a nível pessoal como de carreira.

6.2

Conclusão

O projecto realizado no âmbito do CEPEI permitiu-me conhecer o ambiente de trabalho e o que na realidade implica uma carreira profissional. Neste contexto, é possível verificar de que forma conceitos teóricos adquiridos no percurso académico são aplicados na prática, particularmente, qualidade de software, processos, certificação, auditorias, avaliação de processos, entre outros.

Como resultado da minha intervenção foram produzidos variados documentos como referidos anteriormente, sendo o plano software e o guia do SQA os mais importantes, para além da minha intervenção como SQA que obriga a um elevado número de procedimentos e reuniões com a equipa.

38

O projecto de desenvolvimento do plano de software para o FLPP2, permitiu alargar os horizontes sobre o processo de desenvolvimento de projectos na área da aeroespacial (neste caso a criação de um lançador), algo que é conhecido através dos média (documentários, notícias) mas que aparentemente está a um nível inalcançável.

Considerando a criticidade da referida área e das resultantes missões aeroespaciais, em que o insucesso das mesmas poderá levar a perdas consideráveis de investimento, para além da possível perda de vidas, no caso de missões tripuladas, é necessário garantir que o veículo espacial seja testado e validado de forma a minimizar as probabilidades de fracasso. Desta forma, o desenvolvimento de qualquer uma das componentes que fazem parte do lançador IXV têm de ser rigorosamente planeadas e monitorizadas. Neste âmbito, surge o Software Development Verification and Validation Plan para o software de GNC - responsável pelo controlo de voo do veículo – que tem como objectivo o planeamento rigoroso das tarefas relacionadas com o seu desenvolvimento e integração.

O requisito obrigatório da proposta acordada com EADS Astrium foi que o plano deveria seguir de uma forma rigorosa os ECSS. Mas tendo em conta a sua extensão e estrutura generalista, de forma a poderem ser aplicáveis a um grande número de situações, juntado ao facto da indefinição do âmbito para o qual o plano teria de ser criado, desde cedo o standard do Galileo foi a escolha mais apropriada. O GSWS foi criado com base nos ECSS, por isso, não iria contra o requisito explicitado entre a EADS Astrium e a Critical. Para além disso, foi elaborado tendo em conta um projecto real e conhecido – GPS europeu - e devido à sua grande complexidade (número de equipas, dimensão do projecto) o referido standard apresenta uma estrutura fácil de captar e de aplicar. Em particular, apresenta variados templates que devem ser utilizados pelas equipas em causa, incluindo um plano de software. Depois de definida a tabela de conteúdos do plano tendo em conta o GSWS, foi necessário estudar todos os pontos para avaliar se os mesmos seriam ou não aplicáveis e por fim, se seriam úteis no dia-a-dia das futuras equipas de desenvolvimento do GNC do IXV.

Este tipo de projectos, na sua maioria, tem associado um elevado nível de entropia devido à sua complexidade e faceta de investigação. O projecto FLPP2, onde o plano de software esteve inserido, sofreu significativos atrasos tendo por isso, sido impossível o cumprimento rigoroso da calendarização inicial apresentada no Relatório Preliminar mas em contrapartida, as tarefas identificadas no mesmo foram efectuadas (elaboração da tabela de conteúdos, elaboração do conteúdo, revisões) tendo sido possível coincidir o fim da elaboração do plano de software com data final de estágio.

Por outro lado, as tarefas no Departamento da Qualidade foram efectuadas de uma forma regular e com objectivos claros tendo em conta o impacto estratégico desse mesmo

39

conceito na empresa visto que, as certificações conseguidas permitiram um crescimento sustentado da carteira de clientes de grande importância (ESA, NASA, entre outros) e por conseguinte, de projectos. Como tal, os processos definidos nesse âmbito de certificação que constituem o SGQ, terão de ser obrigatoriamente mantidos e melhorados. A existência do papel de SQA permite que os projectos sejam monitorizados de forma a garantir a conformidade dos mesmos com o referido sistema, desmistificando a sua aplicação e sempre que possível auxiliando na sua melhoria.

A minha colaboração com o Departamento de Qualidade foi conseguida através do papel de SQA, num total de 8 projectos. A monitorização da conformidade dos projectos com o SGQ é feita numa base diária através da leitura dos documentos realizados, análise da informação disponível na intra da empresa e/ou reuniões de progresso/milestone. Estes procedimentos permitem avaliar qual é o estado do projecto e, através da utilização do SQA Logbook, avaliar o nível de qualidade (avaliação semáforo: verde, amarelo ou vermelho) e orientar/informar os Gestores de Projecto as novas fases e o que estas implicam a nível de tarefas de qualidade. Esta tarefa é conseguida, principalmente, através de uma conversa com a equipa e a observação da mesma nas reuniões de projecto, permitindo avaliar qual é a postura relativamente ás tarefas de qualidade e como elas estão a ser garantidas. Caso a equipa, descuide essas tarefas, serão levantadas Work-orders e o projecto será avaliado (amarelo ou vermelho) sendo o resultado desta avaliação reportado para um nível alto (Departamento de Qualidade, Director da área, Director das áreas de Engenharia).

O papel de SQA exige uma grande capacidade de comunicação, de organização e por fim, um alto conhecimento dos processos existentes na empresa e principalmente, o que estes implicam e qual é o seu objectivo prático no projecto, ou seja, qual é a sua mais valia se foram seguidos. O carácter assertivo e destreza das tarefas realizadas pelo o SQA, é conseguida através da experiência ganha ao longo do tempo da intervenção. Considero que a minha capacidade neste papel, melhorou de forma significativa ao longo do estágio, aumentando a minha capacidade crítica, criativa e motivadora face à não-aceitação generalizada por parte das equipas de seguir os processos internos. A prova disso está no facto de ser responsável pela elaboração de um guia que permite uma normalização das tarefas realizadas por todos os SQAs existentes para além de, facilitar e motivar os novos SQAs.

40

A

CRÓNIMOS

Acronyms Description

AQAP Allied Quality Assurance Publication

AR Acceptance Review

EADS Austrium Empresa fabricante de sistemas aeroespaciais

CDR Critical Design Review

CEPEI Curso de Especialização Profissional em Engenharia Informática

CIL Configuration Items List

CM Configuration Management

CMP Configuration Management Plan

CMMI Capability Maturity Model Integration

CSW Critical Software, S.A.

CVS Concurrent Version System (Sistema de Versões Concorrentes)

DDS Detailed Design Specification

DSI Departamento de Sistemas e Infrastruturas

EA Enterprise Architecture (Ferramenta de UML)

ECSS European Cooperation for Space Standardization

EGSE Electrical Ground Support Equipment

ELV Expendable Launch Vehicles

EN9001, EN

9006 European Normative 9001, European Normative 9006

ESA European Space Agency

FDIR Fault Detection, Isolation and Recovery

FLPP2 Future Launcher Preparatory Program Phase 2

GNC Guidance, Navigation and Control

GPS Global Positioning System

GSWS Galileo Software Standards

HPC High Performance Computing

IEC International Electrotechnical Commission

IMU Inertial Measurement Unit

IEEE Institute of Electrical and Electronics Engineer, Inc. ISVV Independent Software Verification and Validation

ISO International Standards Organization

IXV Intermediate eXperimentaltal Vehicle

KO Kick-Off

KOM Kick-Off Meeting

NASA National Aeronautics and Space Administration

NASA-SEL National Aeronautics Space Agency – Software Engineering Laboratory

NATO North Atlantic Treaty Organization

NGL Next Generation Launcher

PAR Product Assurance Report

PCM Project Close Down Meeting

PDR Preliminary Design Review

PE Project Engineering

PINC Project Incident