Escrito por Cristina Ângela Filipak Machado - GPT - Ramal 333

A ênfase em qualidade no processo de desenvolvimento de software tem sido uma constante nos últimos anos na Celepar - Companhia de Informática do Paraná.

Diversos esforços têm sido empreendidos neste sentido, sendo que, atualmente, temos nos dedicado a duas grandes frentes de trabalho: Uma diz respeito à busca de atualização em relação ao que tem ocorrido na comunidade de software com relação à qualidade. A outra tem sido a definição de procedimentos a serem implementados, utilizando estes conhecimentos adquiridos, visando o aperfeiçoamento do processo de desenvolvimento de software, o que acarretou na definição da nova estrutura da Metodologia de Desenvolvimento de Serviços da Celepar - MDS.

Temos utilizado para a definição da metodologia uma série de referências conceituais que estão baseadas em normas e métodos de trabalho. Tais como :

• Norma ISO/IEC 12207-1 - Processos de Ciclo de Vida de Software. Define a estrutura de processos necessários para o desenvolvimento de um software e fornece diretrizes para embasar o contrato entre 2 partes.
• Norma NBR 13596 (ISO/IEC 9126)- Avaliação de Produto de Software- Características de Qualidade e Diretrizes para o seu uso. Tem como principal foco a definição de características e subcaracterísticas de qualidade de produto de software a ser aplicado ao longo do ciclo de vida de desenvolvimento do software.
• A Norma NBR 9000-3- Normas de gestão de qualidade e garantia da qualidade. Tem como objetivo fornecer orientação quando um contrato entre duas partes exigir a demonstração da capacidade de um fornecedor em desenvolver, fornecer e manter produtos de software.
• O modelo SPICE- Melhoria e Avaliação do Processo de Software e Determinação de Capacidade. Fornece uma estrutura para medição da capacidade dos processos de desenvolvimento de software e, baseado nesta medição, são propostas melhorias neste processo.
• O modelo CMM-Capability Maturity Model fornece uma estrutura para apoiar as empresas produtoras de software na evolução dos seus processos e ajuda a prioritizar esforços de melhoria de processos dentro da organização. Também está baseado em medições da capacidade dos processos de desenvolvimento de software.
• As propostas GQM (Goal, Question, Metrics), QIP-Quality Improvement Paradigm e EP- Experience Factory que foram formuladas pelo Software Engineering Laboratory e University of Maryland. O GQM fornece um roteiro para a análise e definição de um plano de medição para software. O QIP direciona todo o trabalho proposto, fornecendo o roteiro para a execução do Plano de Melhoria. O EP apresenta uma forma de generalizar, consolidar e disseminar as experiências por toda a empresa. O conjunto destes métodos dá à empresa uma forma de melhorar o processo de desenvolvimento de software dentro da organização baseado no reuso de experiências bem sucedidas.
  

O principal objetivo deste artigo é repassar estas referências conceituais adquiridas neste último ano de trabalho e relacionar a nossa MDS-Celepar.

O artigo será dividido em 6 partes. Cada uma delas abordará uma referência conceitual e no final iremos descrever como estamos trabalhando com todas estas questões na empresa. Muitos destes modelos possuem o mesmo objetivo só que a maneira como proceder para se alcançar estes objetivos diferem entre si. É importante conhecermos todos eles para definirmos o que é melhor para nós e o que reflete melhor a nossa realidade. Vamos ao trabalho ! A Norma 12207-1-Processos do Ciclo de Vida do Software.


Alguns fatores foram motivadores para a elaboração da norma 12207-1. Um deles é que o ambiente de desenvolvimento tem proliferado sem uma estrutura comum e uniforme para o ciclo de vida do software. Isto acarreta uma certa confusão entre os papéis a serem desempenhados pelas pessoas que estão ligadas ao ambiente de desenvolvimento de software. Normalmente existe uma "nuvem negra" entre a questão técnica e a gerencial. Este problema é mais evidenciado quando existe uma subcontratação de alguma parte do processo. Com uma estrutura bem definida, as pessoas conseguem dentro da organização entender o processo, saber os papéis a serem desempenhados por cada componente do grupo e utilizar uma mesma linguagem.

A norma define os processos que devem ser executados, dizendo quais são os requisitos que devem ser contemplados e os produtos a serem gerados por cada processo. A sua aplicação é, principalmente, para contrato entre duas partes, independente destas partes serem de uma mesma organização.

A estrutura da norma foi concebida de maneira que fosse flexível, modular e pudesse ser adaptável à necessidade do produto a ser implementado. Para isto é essencial a modularidade e a definição da responsabilidade. Entende-se por modularidade a característica existente na definição dos processos que possuem o mínimo de acoplamento e o máximo de coesão. Em princípio, todos os processos possuem uma única função no ciclo de vida. A responsabilidade sobre um processo se dá à medida que cada processo é considerado de responsabilidade de uma parte envolvida. Esta característica facilita a adaptação e aplicação da norma em um projeto, onde várias pessoas podem estar legalmente envolvidas. A estrutura da norma é melhor entendida pela seguinte figura :

Ela é estruturada em um conjunto de processos, atividades e tarefas que podem ser adaptadas de acordo com os projetos de software. Os processos da norma são organizados em 3 blocos de acordo com a funcionalidade destes processos.

Os processos primários formam o ciclo de vida do software, e são essenciais ao desenvolvimento do produto. Eles formam um conjunto de 5 processos que são:

1) Processo de aquisição. Define as atividades do adquirente, organização que adquire um sistema ou produto de "software". Inicia-se com a definição da necessidade de adquirir um sistema ou um produto de software. O Processo continua com a preparação e emissão de pedido de proposta, seleção de fornecedor e administração do processo de aquisição através da aceitação do produto de software.

2) Processo de fornecimento. Define as atividades do fornecedor, organização que provê o produto de "software" ao adquirente. O processo pode ser iniciado tanto por uma decisão de preparar uma proposta para responder a uma solicitação de proposta de um adquirente quanto pela assinatura e participação em um contrato com o adquirente para fornecer o produto de software. O processo continua com a identificação dos procedimentos e recursos necessários para gerência e garantia do projeto, incluindo o desenvolvimento e a execução dos planos de projeto até a entrega do produto de software para o adquirente.

3) Processo de desenvolvimento. Define as atividades do desenvolvedor, organização que define e desenvolve o produto do "software". O processo contém as atividades para análise de requisitos, planos, codificações, integração, testes, instalação e aceitação, relacionadas ao software.

4) Processo de operação. Define as atividades do operador, organização que provê serviço de operação de um sistema computacional no seu ambiente de funcionamento para seus usuários.

5) Processo de manutenção. Define atividades do manutenedor, organização que provê os serviços de manutenção do "software", isto é, gerenciamento de modificações no "software" para mantê-lo atualizado e em perfeita operação. Este processo inclui a migração e a retirada do "software".

O processo de apoio é um conjunto de oito processos. Um processo de apoio auxilia um outro processo como uma parte integrante, com um propósito distinto e contribui para o sucesso e qualidade do projeto de "software". Um processo de apoio é utilizado, quando necessário, por outro processo. Os processos de apoio são:

1) Processo de documentação. Define as atividades para registro da informação produzida por um processo de ciclo de vida.

2) Processo de gerência de configuração. Define as atividades de gerenciamento de configuração, que é composta por: identificar, definir e estabelecer os itens de configuração para o software em um sistema; controlar as alterações e versões dos itens; registrar e apresentar a situação dos itens e dos pedidos de alteração; garantir a integridade, a consistência e a correção dos itens; e controlar o armazenamento, a utilização e a distribuição dos itens.

3) Processo de garantia de qualidade. Define as atividades para garantir objetivamente que os produtos de "software" estão em conformidade com seus requisitos especificados e aderem aos seus planos estabelecidos. A abrangência do processo inclui questões como garantia de qualidade do produto (NBR 13596), do processo e do sistema de qualidade (ISO 9001).

4) Processo de verificação. Define as atividades (para o adquirente, o fornecedor, ou uma parte independente) para verificação dos produtos de "software" em profundidade variável, dependendo do projeto de "software". É um processo para determinar se os requisitos para um sistema ou software estão completos e corretos e se os produtos de software em cada fase atendem os requisitos ou condições impostas nas fases anteriores.

5) Processo de validação. Define as atividades (para o adquirente, o fornecedor ou a parte independente) para validação dos produtos produzidos pelo projeto de "software". É um processo para determinar se os requisitos e o produto final, sistema ou software construído, atendem ao uso específico proposto.

6) Processo de revisão conjunta. Define as atividades para avaliação do estado e produtos de uma atividade. As revisões conjuntas são feitas tanto nos níveis de gerenciamento do projeto como nos níveis técnicos e são executadas durante a vigência do contrato.

7) Processo de auditoria. Define as atividades para determinar a conformidade com requisitos, planos e contrato. Este processo pode ser utilizado por quaisquer duas partes, onde uma delas (parte auditora) audita os produtos de "software" ou as atividades de outra parte (parte auditada).

8) Processo de resolução de problemas. Define um processo para análise e remoção dos problemas (incluindo não conformidades) independente da sua natureza ou origem que forem descobertos durante o desenvolvimento, operação, manutenção ou outros processos.

O processo organizacional é um conjunto de quatro processos. Este bloco é exclusivamente de responsabilidade da organização, pois é utilizado para estabelecer e implementar uma estrutura básica constituída dos processos e das pessoas associadas ao ciclo de vida para que eles sejam continuamente melhorados. São tipicamente utilizados fora do domínio de projetos e contratos específicos; entretanto, ensinamentos de projetos e contratos contribuem para a melhoria da organização. Os processos organizacionais são:

1) Processo de gerência. Define as atividades básicas da gerência, incluindo gerência de projeto, durante os processos de ciclo de vida.

2) Processo de infra-estrutura. Define as atividades básicas para o estabelecimento da estrutura básica de um processo. A infra-estrutura pode incluir hardware, software, ferramentas, técnicas, padrões e facilidades para o desenvolvimento, operação ou manutenção.

3) Processo de melhoria. Define as atividades básicas que uma organização (isto é, adquirente, fornecedor, desenvolvedor, operador, manutenedor, ou o gerente de outro processo) executa para o estabelecimento, e medição, controle e melhoria do seu processo de ciclo de vida.

4) Processo de treinamento. Define as atividades para prover pessoal adequadamente treinado.

Os processos de apoio e organizacionais devem existir independente do projeto.

Vale ressaltar que a norma contém um conjunto de blocos de construção bem definidos (processos). O usuário da norma deve selecionar, adaptar e juntar estes processos apropriadamente e com um custo razoável para o projeto ou organização. No entanto, a norma fortemente recomenda que tal adaptação preserve a arquitetura, intenção e integridade da norma. Por exemplo, pela inclusão de elementos, mas anotados como "não aplicáveis", mais a razão pela inserção de novos procedimentos.

Existe uma comissão de estudos da ABNT-SC10 que tem trabalhado sobre esta norma internacional, portanto qualquer esclarecimento adicional poderá ser adquirido através do e-mail : cristina@lepus.celepar.br.

Este artigo foi baseado num trabalho técnico escrito pela Cristina (Celepar/GPT), Luiz Carlos (Celepar/GPS) e Rosane (Celepar/DITEC-D).

Referências Técnicas:

• Proposta Técnica para a Implantação da Avaliação de Qualidade de Produto para a Celepar feita pelo CTI.
• Resumo das normas de qualidade, José Ignácio Jaeger - Procergs.
• Norma ISO/IEC 12207-1 - Processos de Ciclo de Vida de Software.