Como definir um Processo?

Esse post descreve o primeiro de uma série de artigos que escreverei sobre definição de processo. Um dos primeiros passos para definir um processo é escolher um padrão para

O padrão de modelagem adotado para definição do processos é baseados no SPEM 2.0. O SPEM 2.0 (Software Process Engineering Metamodel), metamodelo proposto pela OMG (Object Management Group) para a descrição de um processo concreto de desenvolvimento de software ou uma família relacionada de processos de desenvolvimento de software.

Controle de Qualidade

O Controle de Qualidade é uma ação reativa, que visa detecar e corrigir defeitos. Considerando o CMMI e o MPS.Br, o controle de qualidade é estabelecido pelas práticas de Verificação e Validação (V&V). A seguir é apresentada uma comparação entre V&V.

Como realizar o Planejamento de Qualidade?

Após experimentar erros e acertos atuando como Analista de Qualidade (QA), compartilho algumas lições aprendidas sobre planejamento de qualidade.

Iniciar Planejamento. A primeira reunião de planejamento de qualidade, realizado no início do projeto, deve ser moderada pelo QA e contar com a participação do gestor do projeto e pessoal externo ao projeto que apoia ou é impactado  pelo desenvolvimento do software (ex.: escritório de projeto, pessoal de manutenção, pessoal responsável pelo contrato e negociação com cliente). Nessa primeira reunião ocorrerá o entendimento do produto e projeto e a instanciação do processo. O resultado dessa reunião influenciará diretamente no cronograma do projeto, o que reforça a necessidade de realizar o  planejamento da qualidade em paralelo com o planejamento do projeto.

Entender as características do produto e projeto: O gestor do projeto deve apresentar o produto e projeto, descrevendo seu escopo, cliente, prazo e principais particularidades e problemas já identificados. É importante identificar se o projeto desenvolverá um produto do zero ou se é evolução de um produto já existente, o tipo da aplicação (desktop, web, data warehouse, software livre, processamento batch, entre outros). Se trata-se de um projeto que evoluirá um produto, deve-se investigar como foi desenvolvido o produto já existente (como está a situação de testes, configuração e mudança, arquitetura, especificação).

Instanciaçao do Processo. O Processo padrão da organização deve ser apresentado e adaptado para o contexto do projeto e produto, conforme identificado no item anterior. Nessa adaptação deve-se discutir o que será mantido, alterado, removido e incluido do processo padrão. O resultado dessa instanciação deve ser documentado para servir de referência para a elaboração do cronograma, execução do processo e avaliação de aderência ao processo (realizada pelo QA). É importante documentar as seguintes informações na instanciação:

• Versão do processo utilizado
• Participantes
• Contexto do Projeto/Produto
• Tarefas mantidas (será realizada conforme o processo padrão). Descrever as saídas esperadas.
• Tarefas novas (não existe no processo padrão). Indicar o procedimento para executar essa tarefa e a saída esperada.
• Tarefa adaptadas (existe no processo padrão, mas será adaptada). Descrever a adaptação e a saída esperada.
• Tarefas removidas (existe no processo padrão, mas o projeto não utilizará).

Durante execução do projeto novas adaptações do processo podem ser necessárias, assim, essa instanciação poderá ser alterada, mas deve-se controlar as mudanças realizadas com histórico de versões.

Identificar os Indicadores de Qualidade. O QA deve se basear nos indicadores de qualidade para monitorar o projeto e avaliar se os produtos atingiram a qualidade desejada. Assim, o planejamento de qualidade deve mapear os indicadores de garantia e controle de qualidade, bem como as metas e  mecanismos para atingí-los e para medí-los. Exemplos de indicadores de qualidade são: Percentual de Aderência ao Processo, Percentual de Conformidade do Produto, Percentual de Cobertura dos Testes (unitários, funcionais, desempenho).

Agendamento das Avaliações da Qualidade. O QA deve identificar o cronograma das entregas dos produtos e baseado nessa informação deve agendar, com o gestor do projeto, as avaliações da qualidade (aderência aos padrões dos produtos e ao processo).

Verificar Riscos. Alguns autores defendem que uma das ações do planejamento da qualidade é a identfiicação e o gerenciamento de riscos que afetam a qualidade do produto. Entretanto, na prática, gerenciamento de riscos é uma atividade realizada pelo gestor no planejamento do projeto, então, cabe ao QA apenas verificar se foram identificados os principais riscos que podem afetar a qualidade do produto  e as ações para evitar esses riscos. Exemplos de riscos que afetam a qualidade do produto são deficiência/mudança em requisitos, tamanho subestimado, restrições tecnológicas (ex.: ambiente).

Plano de Qualidade. A saída do Planejamento de Qualidade é um plano contendo os resultados dos passos listados anterioremente. Entretanto, deve-se evitar repetir informações já definidas em outros artefato (ex: cronograma), de maneira que facilite a manutenção da informação. Quando a informação já está definida em outro artefato, basta referenciá-lo no plano. O Plano também deve ser objetivo para facilitar sua  manutenção e leitura.

Comunicar Plano de Qualidade. O Plano de Qualidade deve ser disponibilizado para todos os envolvidos no projeto. É importante que o cliente seja comunicado sobre o processo de desenvolvido de software que o projeto seguirá, de maneira que haja o comprometimento com as etapas e entregas do projeto.

Como uma informação pode ser entendida e perdida

O Eclipse do Sol: uma estória que conta com humor como uma informação pode ser entendida e perdida:

Capitão ao Sargento-ajudante:
- Sargento! Dando-se amanhã um Eclipse do Sol, determino que a companhia esteja formada, com uniforme de campanha, no campo de exercícios, onde darei explicações em torno do raro fenômeno que não acontece todos os dias. Se por acaso chover, nada poderá se ver e neste caso fica a companhia dentro do quartel.

Sargento-ajudante ao Sargento:
- Sargento! De ordem de meu capitão, amanhã haverá um Eclipse do Sol, em uniforme de campanha. Toda a companhia terá de estar formada no campo de exercícios, onde meu Capitão dará explicações necessárias, o que não acontece todos os dias. Se chover, o fenômeno será mesmo dentro do quartel.

Sargento ao Cabo:
- Cabo, o nosso Capitão fará amanhã um Eclipse do Sol no campo de exercícios. Se chover, o que não acontece todos os dias, nada se poderá ver. Em uniforme de campanha, o Capitão dará a explicação necessária, dentro do quartel.

Cabo aos Soldados:
- Soldados, amanhã, para receber o Eclipse do Sol, que dará as explicações necessárias sobre o Capitão, o fenômeno será em uniforme de exercício, isto se chover dentro do quartel, o que não acontece todos os dias.

J. R. Whitaker, A Técnica da Comunicação Humana

A Triologia de Juran

Joseph Juran colaborou no esforço de reconstrução da indústria japonesa pós-guerra e, junto com Deming, entrou para o rol dos grandes mestres da Qualidade com os trabalhos lá desenvolvidos, e que contribuíram para alçar o país à classe de potência mundial e referencial na prática da Qualidade [1].

Para Juran, o gerenciamento da qualidade é constituída de três grandes processos interrelacionados: Planejamento, Controle e Melhoria [2]. 

Planejamento. Segundo Juran, Qualidade não acontece por acidente, ela deve ser planejada. Cada cliente tem perfil e necessidades diferentes, e por isso necessitam de um planejamento de qualidade direcionado para suas particularidades. Esse planejamento deve envolver os seguintes passos:

• estabeleça os objetivos da qualidade; 
• identifique os clientes (internos e externos);
• identifique as necessidades dos clientes; 
• defina as características do produto que satisfaçam essas necessidades; 
• crie processos capazes de produzir essas características do produto;
• estabeleça os controles do processo, e transferir os planos para as áreas operacionais.

Controle. O desempenho deve ser monitorado durante a operação, de maneira que seja obtida a estabilidade e prevenção de mudanças indesejáveis ou inesperados. O controle é estabelecido da seguinte maneira:

• avalie o desempenho atual;
• compare o desempenho atual com os objetivos fixados; 
• atue sobre as divergências, definindo ações corretivas.

Melhoria. Melhoria contínua da qualidade por meio de mudanças planejadas, previstas e controladas. Para isso, siga os seguintes passos:

• reconheça as necessidades de melhoria;
• estabeleça a infra-estrutura;
• identifique os projetos de melhoria; 
• estabeleça a equipe do projeto com responsabilidade clara por obter uma conclusão satisfatória ao projeto;
• forneça os recursos, motivação, e treinamento necessários para: a) diagnosticar as causas; b) estimular o estabelecimento de ações corretivas e estabelecer controles para assegurar os ganhos.

Na proposta de Juran é possível observar que o foco sempre é o Cliente. Cliente possui necessidades, que restrigem as características do Produto. Processo define as ações necessárias para desenvolver o Produto correto.  Nessa produção, melhorias alcançadas devem ser incorporadas em padrões, de maneira que sejam repetidas! É preciso sempre lembrar que "Excelência não é um ato, mas sim um hábito".

________________________________
[1] http://qualiblog.wordpress.com
[2] Juran, M., Juran’s Quality Handbook, 5th ed.

Os 14 princípios da Qualidade

Qualidade, qualidade, qualidade. Antes de Cristo (384 - 322 a.C), Aristóteles já falava sobre isso, quando dizia:

"Nós somos aquilo que fazemos repetidamente. Excelência, então, não é um ato, mas sim um hábito".

Qualidade também foi um tema explorado logo após a segunda guerra mundial, quando William Edwards Deming, conhecido como o pai do renascimento industrial japonês e um dos gurus da qualidade, ajudou a indústria japonesa a superar a sua crise [1].

Deming foi procurado pelo Japão para ajudar a mudar a percepção de que o país somente produzia imitações baratas para uma nação que poderia produzir produtos inovadores e de qualidade. Segundo Deming, se os japoneses seguissem as suas instruções, eles poderiam conseguir os seus objetivos em cinco anos.  Poucos acreditaram, mas decidiram aceitar o desafio e, para a surpresa do próprio Deming, conseguiram sucesso em quatro anos [1].

Dentre as contribuições de Deming, destaca-se os 14 princípios da Qualidade [2][3]:

1. Criar constância de propósito de aperfeiçoamento do produto e serviço, obetivando torná-los competitivos, perpetuá-los no mercado e gerar empregos.
2. Adotar a nova filosofia. Vivemos numa nova era econômica. A administração ocidental deve despertar para o desafio, conscientizar-se de suas responsabilidade e assumir a liderança em direção à transformação.
3.  Acabar com a dependência de inspeção para a obtenção da qualidade. Eliminar a necessidade de inspeção em massa, priorizando a internalização da qualidade do produto.
4. Acabar com a prática de negócio compensador baseado apenas no preço. Em vez disso, minimizar o custo total. Insistir na idéia de um único fornecedor para cada item, desenvolvendo relacionamentos duradouros, calcados na qualidade e na confiança.
5. Aperfeiçoar constante e continuamente todo o processo de planejamento, produção e serviços, com o objetivo de aumentar a qualidade e a produtividade e, conseqüentemente, reduzir os custos. 
6. Fornecer treinamento no local de trabalho.
7. Adotar e estabelecer liderança. O objetivo da liderança é ajudar as pessoas a realizar um trabalho melhor.
8. Eliminar o medo.
9. Quebrar as barreiras entre departamentos.
10. Eliminar slogans, exortações, e metas dirigidas aos empregados.
11. Eliminar padrões artificiais (cotas numéricas) para o chão de fábrica, a administração por objetivos (APO) e a administração através de números e metas numéricas.
12. Remover barreiras que despojem as pessoas de orgulho no trabalho. Isso significa a abolição das avaliações de desempenho ou de mérito e da administração por objetivos ou por números.
13. Estabelecer um programa rigoroso de educação e auto-aperfeiçoamento para todo o pessoal.
14. Colocar todos da empresa para trabalhar de modo a realizar a transformação. A transformação é tarefa de todos.

Um dos destaques de Deming é a necessidade do foco na qualidade através da Melhoria Contínua do Processo e Produto,  uma visão que busca a competitividade e a redução de custos.


 ___________________________________________________________________________


[1] http://www.qualidade.eng.br
[2] http://qualiblog.wordpress.com
[3] Deming, W. E. Out of the Crisis, MIT Press, 2000

Mitos sobre Metodologias de Desenvolvimento de Software

Nas minhas últimas experiências e discussões sobre Metodologias de Desenvolvimento de Software, tenho percebido que esse é um assunto que tem seita, crença, mitos e valores. As visões ordotoxas sobre determinadass metodologias de desenvolvimento de software fazem com que os seguidores de "seitas" criem verdadeiros mitos sobre esse assunto, tais como: O meu processo de desenvolvimento de software é o melhor. Essa é a crença de quem não enxerga o contexto do projeto. A organização, o tipo de cliente, a equipe, o domínio do problema têm características próprias, e precisam de um processo direcionado para suas necessidades. Nenhum processo caixa preta servirá para todas as organizações.

Modelagem de Processos

Semana passada estava trabalhando na definição de um processo de desenvolvimento de sofwtare para uma empresa, e entre as pesquisas que fiz, encontrei uma solução bem interessante: o EPF (Eclipse Process Framework). Esse framework permite criar plugins de processos, que são bastante simples de alterar para uma organização ou projeto. Em cada plugin você define padrões e biblioteca de métodos que podem ser reusados facilmente, inclusive em outros processos. Existem alguns plugins de processos já prontos para serem customizados, como o OpenUP, XP e Scrum. Estou trabalhando com o plugin do OpenUP, é um processo que une conceitos do RUP e de metodologias ágeis (SCRUM e XP). Fiz algumas modificações no processo para deixá-lo mais simples e adequar à realidade da empresa interessada. Com a ajuda do EPF isso é feito de maneira totalmente automatizado. Esse framework permite publicar todo o processo na WEB, com diagramas, modelagem de tarefas, atividades e papéis já gerados automaticamente (ver exemplo).

Direto da Bahia :) : Revolução Francesa vira jogo brasileiro

Um grupo de pesquisa baiano está desenvolvendo um game para ensinar jovens a partir de 14 anos sobre a Revolução Francesa. Trata-se de "Tríade: Igualdade, Fraternidade, Liberdade", um RPG single-player que leva o jogador para a França do século 18. ( mais informações )

Achei esse projeto bem interessante, seu objetivo eduacacional é muito bom. Além do mais o game, que tem lançamento previsto para agosto de 2008, será gratuito, com distribuição prevista em escolas de Salvador.

Fico orgulhosa por saber que tenho um grande amigo participando desse projeto, grande Abelmon :).

Você pode fazer a diferença...

Aproveitando o clima natalino que se aproxima, vou utilizar esse post para divulgar um trabalho social muito bonito que vem sendo desenvolvido com idosos em Salvador, o Abrigo São Gabriel. Conduzida pelo irmão Gabriel, essa instituição acolhe idosos abandonados, carentes de afeto, de carinho, de um lar... Este abrigo é mantido apenas com doações, quem quiser contribuir com esse GRANDE trabalho pode obter mais informações aqui.

Mas acreditem, bem mais que doação material, esses idosos precisam de amor! Quem puder visitar, conversar, abraçar, verá como eles se sentem felizes com nossa simples presença, palavra, carinho.

Vamos tentar fazer a diferença... e não apenas no Natal!

JabRef

Estou utilizando o JabRef para gerenciar as referências da minha dissertação do mestrado. Esta ferramenta tem me ajudado bastante na organização dos materiais (artigos, livros, relatórios técnicos, entre outros) .

Algumas funcionalidades legais do JabRef que tenho usado:
- cadastro de bibtext source, review, abstract ...
- geração automática de bibtex keys
- geração das referências já padronizadas ( formato do arquivo: rtf)
- exportação para Html ( existem vários templates legais )

Um recurso que seria interessante na ferramenta é o cadastro de review como html, permitir incluir link para outra referência, urls externas, imagens. Isso seria bom para relacionar referências, selecionar imagens que serão utilizadas na dissertação.

Software Product Line Scoping

The goal of this post is present the main topics of the survey realized in software product line scoping. This survey is part of my master thesis, in that I will define an approach to software product line requirement engineering. The basic steps of the approach are scoping, elicitation, modeling, validation and requirements management.

Scope gives support for all further product line activities, so it is very important. But some challenges are identified in scoping, such as scope size, wrong products, absence of essential stakeholders, economic problem, social problem , specific context and different needs of organizations.

In the survey were analyzed 9 approaches. For each approach were identified: activities of scoping, strengths and weaknesses. Then, the more relevant activities found on the survey were grouped on a matrix and the approaches were compared.

The conclusions of the analysis are: the more complete approach is Pulse Scoping Process; the Pulse-ECO is the more referenced approach in the literature identified in this work; few approaches have activities to treat social problem of scoping; one approach has activity to identify available assets; only one approach defines relation between domains; and only one approach has guidelines to different contexts.

Before this scenario, my initial proposal to software product line scoping is adapt Pulse Scoping Process to the reuse tool domain, adding activities to: help the marketing team on product portfolio scoping (e.g. identify customer segments, prioritize each segment; identify essential stakeholders); identify sub-domains and their relations; consider view point of the whole optimal and of the individual optimal; identify available assets.

The presentation (see) of the survey was done for the I.N.1.0.3.8 - Advanced Seminars in Software Reuse course at Cin/UFPE. Participants of the seminar discussed about the approaches comparison criteria and risk in reuse the available assets. The reuse of available assets can reduce efforts, but is necessary evaluate their impact in product line. The approaches comparison matrix can be improved (e.g. define the level of completeness of each activity in the approaches).