UNIVERSIDADE DE LISBOA · 2015-10-02 · Universidade de Lisboa para o efeito de arquivo e consulta...
45
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 Versão Pública Mestrado em Engenharia Informática 2007
Transcript of UNIVERSIDADE DE LISBOA · 2015-10-02 · Universidade de Lisboa para o efeito de arquivo e consulta...
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
Versão Pública
Mestrado em Engenharia Informática
2007
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
2007
DECLARAÇÃ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
_________________________________________
AGRADECIMENTOS 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”
Thomas Fuller
RESUMO 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).
ABSTRACT 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).
CONTEÚDO
1. INTRODUÇÃO.....................................................................................................................................................14
1.1 MOTIVAÇÃO .................................................................................................................................................14 1.2 OBJECTIVO...................................................................................................................................................14 1.3 ORGANIZAÇÃO DO DOCUMENTO.................................................................................................................15
2. APRESENTAÇÃO ...............................................................................................................................................17
2.1 APRESENTAÇÃO DA EMPRESA.....................................................................................................................17 2.1.1 Missão.....................................................................................................................................................17 2.1.2 Áreas de competência ............................................................................................................................17 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. SQA LOG BOOK ...................................................................................................................................................45 A.8. SQA GUIDE 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
Tabela 1 – Documentos produzidos no âmbito do estágio
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
normas internacionais e investigando o estado de arte.
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
31.Maio/07 Out/06 Nov/06 Dez/06 Jan/06 Mar/06 Abril/06
- 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 SS S S S S S S S
Maio/06
S S S
23 Mar 3º versão
S
15 Maio revisão formal
Revisão
Versão estável
Alterações
Elaboração do conteúdo
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
31.Maio/07 Out/06 Nov/06 Dez/06 Jan/06 Mar/06 Abril/06
- 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 SS S S S S S S S
Maio/06
S
Projecto SMICE-CR
Projecto WOW
Projecto WOW BCG
Projecto MESystem
& EnerCC
SQA guidebook
S
24 Abril Publicação do
SQA Guide Book
S
7 Maio Apresentação
formal
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.
Tabela 2 - Lista completa de ferramentas de software utilizadas
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
ACRÓ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
PM Project Manager
41
Acronyms Description
PMP Project Management Plan
QAP Quality Assurance Plan
QR Qualification Review
R.A.M.S. Reliability, Availability, Maintainability and Safety
RCS Reaction Control System
RLV Reusable Launch Vehicles
SDVP Software Development and Verification Plan
SGQ Sistema de Gestão de Qualidade
SP Support Plan
SPiCE Software Process Improvement and Capability dEtermination
SQA Software Quality Assurance
SRS Software Requirements Specification
SVF Software Verification Facility
TickIT ISO9001 aplicado ao desenvolvimento de software
TM Technical Manager
URS User Requirements Specification
WO Work-order
YSR System Requirements Specification
42
DEFINIÇÕES
Termo Definição
SPiCE
Norma internacional que tem como objectivo a avaliação de processos de software.
ISO
Organização internacional de uniformização para os sistemas de gestão de qualidade.
CMMMI
Modelo de maturação que apresenta um método de avaliação da maturidade do desenvolvimento de software de uma escala de 1 a 5.
Item Crítico Qualquer item que pode provocar risco inaceitável para o projecto requerendo especial atenção ou controlo relativamente a outros itens não-críticos [GSWS]
Software Crítico Software (podendo ser constituído por várias componentes) que suporta um sistema crítico que caso falhe pode provocar resultados com catastróficos, críticos ou com consequências graves [GSWS]
Gestão de configurações
(Configuration Management Plan)
Documento que tem como objectivo manter a integridade do produto/projecto que se encontra em desenvolvimento.
Plano de suporte (Support
plan)
Documento que apresenta o plano de suporte pós-entrega onde é definido o processo de comunicação entre a CSW e o cliente, orçamentos de correcção de erros, processos de pedidos/entregas de correcção de erros ou actualizações.
Plano de gestão de
projecto (Project Management Plan)
Documento onde apresenta um plano de desenvolvimento de um projecto: macros, datas, artefactos, papéis e responsabilidades da equipa, entre outros.
Sistema de Gestão de
Qualidade (Quality Management System)
Definição de processos em diversas áreas de acordo com as certificações da empresa. É um sistema que está sempre em processo de melhoria.
Software Quality
Assurance (Engenheiro da
Qualidade)
Pessoa responsável pela a implementação das actividades de avaliação de qualidade de acordo com o Sistema de Gestão de Qualidade da CSW. Reporta periodicamente ao gestor de projecto e departamento de qualidade o estado do projecto.
Software Development
Validation and Verification Plan
Documento onde é especificado o plano de desenvolvimento de software e plano de verificação de forma a assegurar que o software que está a ser desenvolvido satisfaz os requisitos definidos.
Galileo Software Standard
Plano de desenvolvimento de software no âmbito do projecto Galileo (GPS europeu) criado com base no ECSS E40/Q80.
Tailoring Forma como processo, definição ou programa (entre outros) é aplicada a uma determinada realidade, tendo em conta os seus objectivos e limitações.
TickIT
Esquema para a avaliação e registro de sistemas da qualidade de actividades de desenvolvimento, fornecimento e manutenção de software. Baseia- se no uso da norma ISO 9000-3 e de um guia, Tick IT Guide, para que os auditores apliquem adequadamente as normas ISO 9000.
43
Termo Definição
RAMS analysis
Actividade de engenharia que tem como objectivo avaliar a releability, availability, maintanability e safety de um sistema.
LISTA DE FIGURAS FIGURA 1 – MAPA DE CERTIFICAÇÕES DA EMPRESA .......................................................................................... 20 FIGURA 2 – CALENDARIZAÇÃO DAS TAREFAS REFERENTE À ELABORAÇÃO DO PLANO DE SOFTWARE ................. 25 FIGURA 3 – CALENDARIZAÇÃO DAS TAREFAS REFERENTE AO DEPARTAMENTO DE QUALIDADE.......................... 26 FIGURA 4 – FASES E MACROS DO PROJECTO.................................................................................................... 33 FIGURA 5 – CICLO DE VIDA APRESENTADO NO PLANO ....................................................................................... 34
LISTA DE TABELAS TABELA 1 – DOCUMENTOS PRODUZIDOS NO ÂMBITO DO ESTÁGIO ..................................................................... 15 TABELA 2 - LISTA COMPLETA DE FERRAMENTAS DE SOFTWARE UTILIZADAS ....................................................... 36
ÍNDICE REMISSIVO
ESA 19, 21, 31, 39, 41 FLPP2... 12, 15, 21, 23, 25, 27, 28, 29, 31, 37, 38, 41,
45 NASA.............................................................19, 39, 41 Sistema de Gestão de Qualidade
SGQ 9, 14, 15, 18, 19, 21, 24, 27, 28, 30, 32, 35, 36, 37, 39, 42
Software Development Validation and Verification Plan........................................9, 23, 31, 38, 42, 45
SQA Software Quality Assurance9, 12, 15, 21, 22, 24,
26, 27, 28, 30, 32, 34, 35, 37, 39, 42, 45, 46 SQA Form.....................................................27, 35, 45 SQA Guidebook................................15, 26, 27, 45, 46 SQA Logbook............................................................ 39
44
REFERÊNCIAS
[1] “GALILEO Software Standard (GSWS)”, Galileo Industries, 2004.
[2] “Guia do Projecto em Engenharia Informática do Mestrado em Engenharia
Informática do Departamento de Informática”, Departamento de Informática da
Faculdade de Ciências da Universidade de Lisboa (FCUL), Julho de 2006a.
[3] Intranet, site interno da empresa, Critical Software, S.A., 2007a.
[4] “Manual de Acolhimento”, Critical Software, S.A., 2006a.
[5] Metodologia MELANIE, EADS Astrium, 2007.
[6] “Proposta de Estágio: Engenheiro de Qualidade”, Critical Software, S.A., 2006b.
[7] “Proposta de Tese de Mestrado”, José Gonçalo Silva, 2004a.
[8] “Quality Manual”, Critical Software, S.A., 2004b.
[9] Sítio da Critical Software: www.criticalsoftware.com, 2007b
[10] Sítio da cadeira Processos de Qualidade em Sistemas Informáticos,
http://si.di.fc.ul.pt/pqsi/, Departamento de Informática da Faculdade de Ciências da
Universidade de Lisboa (FCUL), 2006b.
[11] “Software Development Process”, Critical Software, S.A., 2006c.
[12] “Software Development Verification and Validation Plan” FLPP2, Inês Dias, 2007.
[13] “SQA Log Book”, Critical Software, S.A., 2007c.
[14] “SQA Form”, Critical Software, S.A., 2007d.
[15] “SQA Guide Book, Critical Software, S.A., 2007e.
[16] “Technical Proposal: FLLP Period 1 Phase 2- WPD 64500”, Critical Software, S.A.,
2006d.
45
ANEXOS A informação contida nos anexos é de carácter confidencial.
A.1. Plano de Gestão de Configuração do Xception TM
A.2. Plano de Suporte do Xception TM
A.3. Plano de Gestão de Projecto do Xception TM
A.4. Acta de reunião de estágio
A.5. Conceitos GNC
A.6. Plano de Desenvolvimento, Validação e Verifica ção de Software do
FLPP2
A.7. SQA Log Book
A.8. SQA Guide Book
