quarta-feira, 8 de maio de 2013

Recordar é Viver



5S
5S é uma ferramenta de trabalho que permite desenvolver um planejamento sistemático de classificação, ordem, limpeza, permitindo assim de imediato maior produtividade, segurança, clima organizacional, motivação dos funcionários e consequente melhoria da competitividade organizacional.

Seiri (整理) - Senso de utilização.
Seiton (整頓) - Senso de ordenação.
Seisō (清掃) - Senso de limpeza.
Seiketsu (清潔) - Senso de Higiene.
Shitsuke (躾) - Senso de autodisciplina.


Os propósitos da metodologia 5S são de melhorar a eficiência através da destinação adequada de materiais (separar o que é necessário do desnecessário), organização, limpeza e identificação de materiais e espaços e a manutenção e melhoria do próprio 5S.

Os principais benefícios da metodologia 5S são:
  1. Maior produtividade pela redução da perda de tempo procurando por objetos. Só ficam no ambiente os objetos necessários e ao alcance da mão.
  2. Redução de despesas e melhor aproveitamento de materiais. A acumulação excessiva de materiais tende à degeneração.
  3. Melhoria da qualidade de produtos e serviços
  4. Menos acidentes do trabalho.
  5. Maior satisfação das pessoas com o trabalho.
Os 5 S's são:
  • Seiri (整理): Senso de utilização.
    • Refere-se à prática de verificar todas as ferramentas, materiais, etc. na área de trabalho e manter somente os itens essenciais para o trabalho que está sendo realizado. Tudo o mais é guardado ou descartado. Este processo conduz a uma diminuição dos obstáculos à produtividade do trabalho.
  • Seiton (整頓): Senso de ordenação.
    • Enfoca a necessidade de um espaço organizado. A organização, neste sentido, refere-se à disposição das ferramentas e equipamentos em uma ordem que permita o fluxo do trabalho. Ferramentas e equipamentos deverão ser deixados nos lugares onde serão posteriormente usados. O processo deve ser feito de forma a eliminar os movimentos desnecessários.
  • Seisō (清掃): Senso de limpeza.
    • Designa a necessidade de manter o mais limpo possível o espaço de trabalho. A limpeza, nas empresas japonesas, é uma atividade diária. Ao fim de cada dia de trabalho, o ambiente é limpo e tudo é recolocado em seus lugares, tornando fácil saber o que vai aonde, e saber onde está aquilo o que é essencial. O foco deste procedimento é lembrar que a limpeza deve ser parte do trabalho diário, e não uma mera atividade ocasional quando os objetos estão muito desordenados.
  • Seiketsu (清潔): Senso de Higiene.
    • Em Japones, Seiketsu traduz-se por higiene, no sentido filosofico de "higienismo", ou seja, no sentido do cuidade da higiene própria em todos os niveis, diferenciando-se, assim, de Seiso. Muitos tem confundido este senso com normalização,mas normalização é um conceito que pertence ao modelo qualidade, em especial de ISO e outras certificações. Estes modelos de normalização são posteriores ao Programa 5 S. Por isso, o 5 S é considerado o primordio dos Programas de Qualidade.
  • Shitsuke (): Senso de autodisciplina.
    • Refere-se à manutenção e revisão dos padrões. Uma vez que os 4 Ss anteriores tenham sido estabelecidos, transformam-se numa nova maneira de trabalhar, não permitindo um regresso às antigas práticas. Entretanto, quando surge uma nova melhoria, ou uma nova ferramenta de trabalho, ou a decisão de implantação de novas práticas, pode ser aconselhável a revisão dos quatro princípios anteriores.

Normas da Qualidade

ABNT NBR ISO/IEC 14102:2002
Tecnologia de informação - Orientação para avaliação e seleção de ferramentas CASE

ABNT ISO/IEC TR 14471:2003
Tecnologia da informação - Engenharia de software - Orientação para adoção de ferramentas CASE

ABNT NBR ISO/IEC 9126-1:2003
Engenharia de software - Qualidade de produto Parte 1: Modelo de qualidade

ABNT NBR ISO/IEC 14598-2:2003
Engenharia de software - Avaliação de produto Parte 2: Planejamento e gestão

ABNT NBR ISO/IEC 14598-3:2003
Engenharia de software - Avaliação de produto Parte 3: Processo para desenvolvedores

ABNT NBR ISO/IEC 14598-4:2003
Engenharia de software - Avaliação de produto Parte 4: Processo para adquirentes

ABNT NBR ISO/IEC 14598-5:2001
Tecnologia de informação - Avaliação de produto de software Parte 5: Processo para avaliadores

ABNT NBR ISO/IEC 14598-6:2004
Engenharia de software - Avaliação de produto Parte 6: Documentação de módulos de avaliação

ABNT ISO/IEC TR 24774:2010
Engenharia de software e de sistemas — Gerenciamento de ciclo de vida — Orientações para descrição de processos

ABNT NBR ISO/IEC 25000:2008
Engenharia de software - Requisitos e avaliação da qualidade de produtos de software (SQuaRE) - Guia do SQuaRE

ABNT NBR ISO/IEC 25001:2009 
Engenharia de software - Requisitos e avaliação da qualidade de produto de software (SQuaRE) - Planejamento e gestão

ABNT NBR ISO/IEC 25020:2009 
Engenharia de software - Requisitos e avaliação da qualidade de produto de software (SQuaRE) - Guia e modelo de referência para medição

ABNT NBR ISO/IEC 25030:2008
Engenharia de software - Requisitos e Avaliação da Qualidade de Produto de Software (SQuaRE) - Requisitos de qualidade

ABNT NBR ISO/IEC 25051:2008
Engenharia de software - Requisitos e avaliação da qualidade de produto de software (SQuaRE) - Requisitos de qualidade de produto de software comercial de prateleira (COTS) e instruções para teste

ABNT NBR ISO/IEC 25062:2011
Engenharia de software — Requisitos e avaliação da qualidade de produto de software (SQuaRE) — Formato comum da indústria (FCI) para relatórios de teste de usabilidade

Grande Abraço,
Gilberto Ribeiro.

MPS.BR

O Guia de Implementação fornece orientações para implementar os níveis de maturidade descritos no Modelo de Referência MR-MPS, detalhando os processos contemplados nos respectivos níveis de maturidade e os resultados esperados com a implementação dos processos.

Este documento é destinado, mas não está limitado, a organizações interessadas em utilizar o MR-MPS para melhoria de seus processos de software e às Instituições Implementadoras (II) e às Instituições Avaliadoras (IA).

Implementação do MR-MPS em organizações do tipo Fábrica de Software

As organizações do tipo Fábrica de Software são contratadas para o desenvolvimento da etapa de codificação de projetos de software. Nestes casos, as demais etapas do ciclo de vida (como, por exemplo, requisitos e especificações) são de responsabilidade da organização contratante.

Os projetos em uma Fábrica de Software iniciam com a recepção e a aceitação das especificações, o que representa, para estas organizações, o entendimento dos requisitos.

Este Guia de Implementação trata de como organizações do tipo Fábrica de Software podem implementar o MR-MPS e estar aderentes a um de seus níveis de maturidade.

Alguns processos podem ser excluídos, total ou parcialmente, do escopo de uma avaliação MPS por não serem pertinentes ao negócio da unidade organizacional que está sendo avaliada. Cada exclusão deve ser justificada no Plano de Avaliação. A aceitação das exclusões e suas justificativas é responsabilidade do Avaliador Líder, conforme descrito no Guia de Avaliação [SOFTEX, 2009b].

Para organizações do tipo Fábrica de Software não são permitidas exclusões dos seguintes processos ou de seus resultados esperados: 
  • Avaliação e Melhoria do Processo Organizacional (AMP)
  • Definição do Processo Organizacional (DFP)
  • Garantia da Qualidade (GQA)
  • Gerência de Configuração (GCO)
  • Gerência de Decisões (GDE)
  • Gerência de Projetos (GPR)
  • Gerência de Portfólio de Projetos (GPP)
  • Gerência de Recursos Humanos (GRH)
  • Gerência de Requisitos (GRE)
  • Gerência de Reutilização (GRU)
  • Gerência de Riscos (GRI)
  • Medição (MED)
  • Verificação (VER)

Para organizações do tipo Fábrica de Software é permitida a exclusão do seguinte processo, seguindo as orientações da Tabela 4-1.
  • Desenvolvimento para Reutilização (DRU)
     
 

Para organizações do tipo Fábrica de Software são permitidas exclusões dos seguintes processos ou de seus resultados esperados, dependendo das características da organização:
  • Aquisição (AQU)
  • Desenvolvimento de Requisitos (DRE)
  • Integração de Produto (ITP)
  • Projeto e Construção do Produto (PCP)
  • Validação (VAL)

A discussão de quando cada resultado pode ser excluído é feita ao longo deste guia de implementação ao se tratar de cada processo específico. Com relação aos resultados de atributos de processo, nos níveis A e B, os resultados RAP 23 a RAP 46 podem ficar fora do escopo da avaliação para alguns dos processos da organização. Apenas os processos críticos da organização, selecionados para controle estatístico, devem implementar todos os resultados de atributos de processo.

Descrição do MR-MPS

O Modelo de Referência MR-MPS define níveis de maturidade que são uma combinação entre processos e sua capacidade.

A definição dos processos segue os requisitos para um modelo de referência de processo apresentados na ISO/IEC 15504-2, declarando o propósito e os resultados esperados de sua execução. Isso permite avaliar e atribuir graus de efetividade na execução dos processos. As atividades e tarefas necessárias para atender ao propósito e aos resultados esperados não são definidas neste guia, devendo ficar a cargo dos usuários do MR-MPS.

A capacidade do processo é a caracterização da habilidade do processo para alcançar os objetivos de negócio, atuais e futuros; estando relacionada com o atendimento aos atributos de processo associados aos processos de cada nível de maturidade.

Níveis de maturidade


Os níveis de maturidade estabelecem patamares de evolução de processos, caracterizando estágios de melhoria da implementação de processos na organização. O nível de maturidade em que se encontra uma organização permite prever o seu desempenho futuro ao executar um ou mais processos. O MR-MPS define sete níveis de maturidade:
  1. A (Em Otimização)
  1. B (Gerenciado Quantitativamente)
  1. C (Definido)
  1. D (Largamente Definido)
  1. E (Parcialmente Definido)
  1. F (Gerenciado)
  1. G (Parcialmente Gerenciado)

A escala de maturidade se inicia no nível G e progride até o nível A. Para cada um destes sete níveis de maturidade é atribuído um perfil de processos que indicam onde a organização deve colocar o esforço de melhoria. O progresso e o alcance de um determinado nível de maturidade do MR-MPS se obtêm quando são atendidos os propósitos e todos os resultados esperados dos respectivos processos e os resultados esperados dos atributos de processo estabelecidos para aquele nível.

A divisão em 7 estágios tem o objetivo de possibilitar uma implementação e avaliação adequada às micros, pequenas e médias empresas. A possibilidade de se realizar avaliações considerando mais níveis também permite uma visibilidade dos resultados de melhoria de processos em prazos mais curtos.

Processo

Os processos no MR-MPS são descritos em termos de propósito e resultados. O propósito descreve o objetivo geral a ser atingido durante a execução do processo. Os resultados esperados do processo estabelecem os resultados a serem obtidos com a efetiva implementação do processo. Estes resultados podem ser evidenciados por um produto de trabalho produzido ou uma mudança significativa de estado ao se executar o processo.

Capacidade do processo

A capacidade do processo é representada por um conjunto de atributos de processo descrito em termos de resultados esperados. A capacidade do processo expressa o grau de refinamento e institucionalização com que o processo é executado na organização/unidade organizacional. No MR-MPS, à medida que a organização/unidade organizacional evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido.

O atendimento aos atributos do processo (AP), pelo atendimento aos resultados esperados dos atributos do processo (RAP), é requerido para todos os processos no nível correspondente ao nível de maturidade, embora eles não sejam detalhados dentro de cada processo. Os níveis são acumulativos, ou seja, se a organização está no nível F, esta possui o nível de capacidade do nível F que inclui os atributos de processo dos níveis G e F para todos os processos relacionados no nível de maturidade F (que também inclui os processos de nível G). Isto significa que, ao passar do nível G para o nível F, os processos do nível de maturidade G passam a ser executados no nível de capacidade correspondente ao nível F. Em outras palavras, na passagem para um nível de maturidade superior, os processos anteriormente implementados devem passar a ser executados no nível de capacidade exigido neste nível superior.

Os diferentes níveis de capacidade dos processos são descritos por nove atributos de processo (AP), conforme definido a seguir:

AP 1.1 O processo é executado: Este atributo é uma medida do quanto o processo atinge o seu propósito.
AP 2.1 O processo é gerenciado: Este atributo é uma medida do quanto a execução do processo é gerenciada.
AP 2.2 Os produtos de trabalho do processo são gerenciados: Este atributo é uma medida do quanto os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente.
AP 3.1 O processo é definido: Este atributo é uma medida do quanto um processo padrão é mantido para apoiar a implementação do processo definido.
AP 3.2 O processo está implementado: Este atributo é uma medida do quanto o processo padrão é efetivamente implementado como um processo definido para atingir seus resultados.
AP 4.1 O processo é medido: Este atributo é uma medida do quanto os resultados de medição são usados para assegurar que a execução do processo atinge os seus objetivos de desempenho e apoia o alcance dos objetivos de negócio definidos.
AP 4.2 O processo é controlado: Este atributo é uma medida do quanto o processo é controlado estatisticamente para produzir um processo estável, capaz e previsível dentro de limites estabelecidos.
AP 5.1 O processo é objeto de melhorias e inovações: Este atributo é uma medida do quanto as mudanças no processo são identificadas a partir da análise de defeitos, problemas, causas comuns de variação do desempenho e da investigação de enfoques inovadores para a definição e implementação do processo.

AP 5.2 O processo é otimizado continuamente: Este atributo é uma medida do quanto as mudanças na definição, gerência e desempenho do processo têm impacto efetivo para o alcance dos objetivos relevantes de melhoria do processo.

O alcance de cada atributo de processo é avaliado utilizando os respectivos resultados esperados de atributo de processo (RAP). Os atributos de processos e seus respectivos resultados esperados são discutidos ao se descrever cada um dos níveis do MR-MPS.

A Tabela abaixo apresenta os níveis de maturidade do MR-MPS, os processos e os atributos de processo correspondentes a cada nível.
  

Fonte: MPS.BR

CMMI

Visando a melhoria do desenvolvimento de software, vários modelos para avaliação do processo de produção de software têm sido propostos por instituições no mundo inteiro.

Dentre os mais utilizados, podemos citar o Capability Maturity Model (CMM), do Software Engineering Institute (SEI), o qual tem sido bastante utilizado pelas empresas de software.

O CMMI fornece às organizações diretrizes para controlar seus processos de desenvolvimento de software, de modo a desenvolver e manter software de melhor qualidade, bem como instituir uma cultura de excelência em engenharia e gerenciamento de projetos de software. O CMMI propõe um caminho gradual, através de níveis de maturidade da capacitação, que leva as organizações a se aprimorarem continuamente na busca das suas próprias soluções para os problemas inerentes ao desenvolvimento sistemático de software. A capacitação aqui mencionada refere-se a habilitação que a organização tem em sistematicamente produzir software com a qualidade esperada, dentro dos prazos acordados e com os recursos estimados.

A estrutura do CMM consiste de cinco (1 a 5) níveis de maturidade:

Nível 1: Inicial. O processo de desenvolvimento de software é caracterizado como ad-hoc, podendo facilmente chegar ao caos. Poucos processos estão definidos e o sucesso do projeto depende do esforço individual de cada um envolvido.

Nível 2: Repetível. Processos básicos para gerenciamento de software são estabelecidos para controlar e acompanhar custos, cronograma e funcionalidades. Neste nível, o processo é caracterizado como disciplinado, estando sob o controle efetivo de políticas de gerenciamento de projetos, seguindo planos realistas, baseado em desempenho de projetos similares já realizados.

Nível 3: Definido. Os processos de gerenciamento e das atividades de engenharia de software estão documentados e padronizados, integrando o padrão de processo de software da organização. Todos os projetos utilizam esses processos padrões.

Nível 4: Gerenciado. Medidas detalhadas do processo de software e da qualidade dos produtos são colhidas. Tanto o processo de software quanto o produto são quantitativamente entendidos e controlados.

Nível 5: Otimizado. Melhorias contínuas no processo são realizadas baseadas nos feedbacks quantitativos dos processo e produtos. Cada nível de maturidade indica o nível de capacidade do processo de desenvolvimento de software da organização. Por exemplo, no Nível 2 a capacidade do processo da organização foi elevada de ad hoc para disciplinada por terem sido estabelecidos controles para o gerenciamento do projeto.


Estudando a Viabilidade de um Projeto - I

O Estudo da Viabilidade antecede a análise de requisitos, desta forma antes de avançarmos com uma análise mais profunda pouparemos tempo e dinheiro dos investidores se concentrarmos nossos esforços primeiro no estudo da viabilidade. Com ele conseguimos avaliar o projeto do ponto de vista tecnológico, ambiental, organizacional, financeiro, ambiental, político, disponibilidade de recursos, tempo, entre outras.

Algumas questões direcionadas aos especialistas do negócio podem ser formuladas, tais como:
  • O sistema contribuirá para os objetivos da organização?
  • Dadas as restrições tecnológicas, organizacionais e temporais associadas ao projeto, será que o sistema pode ser implementado?
  • Caso haja necessidade de integração entre diferentes sistemas, será que esta é possível?
  • Se o novo sistema não fosse implementado, quais seriam as alternativas para a organização?
  • Quais são os problemas que os sistemas atuais apresentam e como é que um sistema novo irá resolver estas falhas?
  • De que forma é que o sistema irá contribuir diretamente para os objetivos da organização?
  • É possível a integração com os outros sistemas da organização?
  • Com que facilidade é que se consegue partilhar informação entre estes sistemas?
  • Existe orçamento suficiente para o desenvolvimento do projeto?

Podemos considerar como maior criticidade a primeira questão: Será que o sistema contribui para os objetivos da organização? Pois todo sistema tem como fim agregar valor ao negócio do cliente, do investidor. É comum encontrarmos sistema que foram descontinuados pela falta de uso, por não atender os objetivos da empresa em fim por não agregar valor algum ao negócio do cliente. Geralmente foram soluções impostas pelos desenvolvedores com base em experiência em outros projetos, mas sem levar em consideração o negócio do cliente, ou seja, o conceito de abstração foi totalmente negligenciado pelos analistas, pois quando desenvolvemos um sistema desenvolvemos para alguém e precisamos entender o domínio do negócio.
  • Como responder as questões acima?
  • Quem possui estas informações?
  • Quem devemos envolver?

Geralmente os futuros usuários do sistema, porque já o fazem manualmente ou com um poll de sistemas que precariamente atende as suas necessidades. Devemos identificar os especialistas no negócio que detém o conhecimento do negócio. Podemos elaborar uma lista que servirá de norteará o estudo:
  • Usuários dos sistemas ou processo atual.
  • Os responsáveis pelos departamentos que utilizarão o sistema.
  • Os técnicos familiarizados com as tecnologias envolvidas.
  • Os responsáveis pela manutenção futura do sistema.
  • Todos aqueles que terão qualquer tipo de interação com o novo sistema, ou serão por ele afetados.

Como produto do estudo da viabilidade, teremos um relatório que auxilia na decisão gerencial na continuação do desenvolvimento do projeto, tornando mais claras as restriçõesdo projeto e definindo também a Visão Macro do Sistema.

Algumas das atividades envolvidas nesta fase incluem:
  • Compreensão do Domínio
  • Identificação das partes interessadas
  • Requisitos funcionais e não funcionais macros.
  • Identificação e análise de problemas

Para facilitar a compreensão deste processo podemos dividir o estudo da viabilidade técnica em três fases:
  • Viabilidade Técnica
  • Econômica
  • Legal.

Viabilidade técnica

Nesta fase avaliamos a função, o desempenho e as limitações que um sistema terá dentro dos processos da empresa, possibilitando identificar se o sistema atenderá ou não as necessidades do cliente. Esbarramos geralmente na dificuldade que o cliente tem de verbalizar os processos da empresa, para ele tudo é muito trivial e na maioria das vezes precisamos ajuda-los a mapear os processos. Como realizar a viabilidade técnica quando o cliente não sabe exatamente o que ele quer? Como avaliar desempenho e as limitações se ainda não entendemos o domínio do negócio? A falta de entendimento pode comprometer o desenvolvimento de um módulo do sistema ou até mesmo o sistema inteiro.

Ponto que levamos em consideração também:
  • Quais tecnologias são necessárias?
  • Quais novos algoritmos são necessários?
  • Quais novos processos são necessários?
  • Quais são os riscos envolvidos de que maneira esta tecnologia afeta os custos?

Viabilidade Econômica

O objetivo desta etapa e mostrar para o cliente se o investimento que ele prende realizar trará lucro ou benefícios para a empresa. Os fatores que devemos levar em consideração são:
  • A equipe de desenvolvimento é capacitada?
  • Será necessária aquisição de licença para o desenvolvimento do sistema?
  • Será necessária aquisição de licença para a implantação do sistema na empresa?
  • Qual o custo com hardware?
  • Qual a relação custo benefício?

Viabilidade Legal

A viabilidade legal esta atrelada as leis federais, estaduais e municipais que regulamentam negócio.

Grande Abraço,
Gilberto Ribeiro