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.
cristina@lepus.celepar.br
|
