Archive for the processo de produção de software Category

O lúdico aplicado na melhoria de um processo de software

Posted in processo de produção de software, qualidade de software on March 31, 2014 by José Augusto Fabri

Várias pessoas questionam o motivo que me levou a construir bonecos e pipas durante os programas de melhoria de processo. O texto abaixo justifica a utilização de tais práticas.

Vários programas de melhoria de processo são abortados durante a sua implementação. Este problema é recorrente em empresas do segmento produtivo de software, pois os responsáveis pela implementação dos referidos programas encaram os modelos de qualidade (CMMI e MPS-BR) como uma “camisa de força, ou seja, as formas de implementação das áreas chaves do processo, propostas pelos referidos modelos, são interpretadas como verdade absoluta.

Durante a melhoria de um processo de software os colaboradores de uma determinada empresa devem alterar a sua forma de trabalho. Novas atividades ou tarefas devem ser inseridas na estrutura do processo, formulários que antes não eram preenchidos passam a ser e, principalmente, aspectos ligados à produtividade e qualidade são questões de suma importância.

Algumas empresas alteram a sua cultura de trabalho durante a execução do plano de melhoria de processo. Trabalhar, como consultor, dentro de um ambiente permeado por estas situações requer certo “jogo de cintura”. É necessário sair do trivial, treinamentos e possíveis alterações na forma de trabalho devem ser implementadas com parcimônia. Técnicas diferenciadas, com foco nas áreas chaves do processo, devem ser atacadas com eficiência e eficácia. A motivação dos envolvidos se caracteriza como um fator crítico de sucesso.

Dentro deste prisma acredita-se que os aspectos inerentes à melhoria de processo de software são suportado por questões ligadas ao ensino e aprendizagem. Ambos ocorrem em duas vias, hora os membros de uma consultoria (em melhoria de processo) compartilham o seu conhecimento com os envolvidos no ambiente produtivo – o ensino – em outros momentos são os envolvidos que agregam ao portfólio da consultoria – a aprendizagem.

Para compor um ambiente de ensino e aprendizagem (de mão dupla) altamente motivador, é necessário trabalhar o conceito do lúdico. A motivação tem como foco proporcionar prazer por meio do desenvolvimento de uma determinada atividade, e uma das formas de obter esse prazer é utilizar o referido conceito.

Salienta-se que os envolvidos com o aspecto produtivo de software, na maioria das empresas, são oriundos de vários ambientes. A diversidade na formação, na origem regional, no aspecto cultural e, principalmente, na experiência caracteriza-se como uma constante. Este fato alinha-se diretamente com uma dos principais pressupostos relacionados a aprendizagem.

“a aprendizagem humana pressupõe uma natureza social específica e um processo por meio do qual os aprendizes penetram, de forma diferenciada, dada a sua diversidade, na vida intelectual daqueles que o cercam” (Vygosky (1991)).

De posse do pressuposto destacado e assumindo que todos os envolvidos em um programa de melhoria de processo concebem representações sobre um determinado objeto (forma de trabalho, formulário a ser preenchido, padrão a ser seguido) por meio de suas práticas sociais (a diversidade na formação, na origem, na cultura, na experiência), e essas representações são delineadas a partir do grau de interesse e de qualidade (da informação obtida ou do produto gerado) proporcionadas pelo objeto; concluí-se que os atores sociais imersos no processo de ensino e aprendizagem estabelecem um relacionamento de simbolização/interpretação para com o objeto manipulado. É, justamente, este relacionamento que configura o significante e o significado do objeto.

O significante caracteriza-se como o signo linguístico é uma “imagem acústica” – sua consistência está na forma do objeto. O significado provê ao ator questões relacionadas ao conteúdo – o que eu posso fazer com o objeto.

O significado é assimilado por meio de uma rede de conhecimento pré-estabelecida pelos atores (envolvidos em um programa de melhoria de processo) é, esse tipo de rede que se encontra a origem e a permanência da simbolização/interpretação dos objetos.

Diversos teóricos da área pedagógica (diSessa et. al. (1982, 1983, 1985, 1988, 1993). Smith et. al. (1993), Clement (1983), McCloskey (1983), Resnick (1983)) têm como premissa que as concepções prévias devem ser compreendidas como parte ativa do desenvolvimento da simbolização/interpretação. Durante a institucionalização (ou melhoria) de um processo, para um determinado meio (ambiente produtivo de software), num mesmo tempo e num mesmo espaço (células produtivas do ambiente – por exemplo: célula de teste) teremos, para cada colaborador diferentes formas de simbolização/interpretação.

Dentro do contexto delineado, é possível delimitar a construção do conhecimento nos aspectos primitivos fenomenológicos, estruturas elementares obtidas por abstrações simples, fracionadas, que se relacionam entre si, com o objetivo de promover um determinado significado.

Segundo Kishimoto (1999), as técnicas lúdicas podem se relacionar de forma perspicaz com as estruturas elementares obtidas pelas abstrações. Estas técnicas são criadas com o objetivo de estimular o processo de aprendizagem. De nada adianta institucionalizar, durante o programa de melhoria de processo, questões ligada à produtividade, qualidade e gerência, se estas não se constituem conceitualmente para todos os envolvidos com o ambiente produtivo de software. Não se espera, por parte dos envolvidos, concepções alternativas sobre as questões delineadas, se estes não estiverem engajados no programa de melhoria. É necessário seduzir  o que lhes é apresentado, que encontrem o verdadeiro significado das atividades/tarefas (do processo), para que possam compreender a importância de um programa de melhoria. As práticas lúdicas vão de encontro à sedução supracitada.

É por meio do lúdico que os envolvidos em um ambiente de melhoria de processo são livres para determinar suas ações. A essência do brincar e a criação de uma nova relação entre os objetos, inerente a uma determinada área chave do processo, podem promover um ganho substancial no tempo e na qualidade de todo programa de melhoria. O brincar se constitui em um processo de extrema importância a favorece as transformações internas de um determinado ambiente.

Por fim, é importante discutir o lúdico como ideia de divertimento, um fazer humano amplo, que vai além de brincadeiras e jogos, traduzindo o sentimento, as atitudes de um sujeito envolvido em uma determinada ação, referindo-se ao prazer da celebração em função de envolvimento efusivo, transpondo a sensação de plenitude que acompanha significados verdadeiros dos brinquedos (em nosso caso, os objetos).

É dentro deste panorama que modelo de processo não pode ser encarado como uma “camisa de força”.

J. A. Fabri – fabri@utfpr.edu.br

A otimização da produtividade em uma empresa de software

Posted in gestão de projetos, processo de produção de software on March 10, 2014 by José Augusto Fabri

Muitos alunos, programadores, engenheiros e empresários me questionam: Como otimizar a produtividade dentro de uma empresa de software?

Minha resposta é direta, o aumento da produtividade está alinhado com o aumento do reuso dos artefato do processo software. Ou seja, mais componentes reutilizáveis dentro do ambiente de produção proporciona menos manutenção de seus produtos e uma melhoria significativa no tempo de produção. Dentro deste contexto você terá maior eficiência, aumentando o valor agregado de seu produto e fortalecendo o seu portfólio. Sua empresa deve se manter no quadrante verde da figura abaixo.

A ausência de um processo e ineficiência na gestão de projetos levam as empresas não praticar plenamente o reuso de software (em todos os níveis: código, artefatos … ). Este fato leva as empresas a trabalharem grande parte do tempo na manutenção corretiva e customizações  das funcionalidades. Ineficiência produtiva, menor valor agregado dos produtos e o enfraquecimento dos portfólios configuram as empresas dentro deste contexto (quadrante vermelho da figura).

reuso-produtividade

Existem empresas de software que desenvolvem para vários domínios do conhecimento, essas, por sua vez, estão impossibilitadas de praticar um alto grau de reuso, e mantém a sua produtividade com um número maior de colaboradores.

Por fim, as empresas que possuem uma base de componentes estável com uma baixa produtividade têm problemas com a prospecção de clientes e fechamento de contratos (quadrante amarelo).

Em qual quadrante se localiza sua empresa?

José Augusto Fabri – fabri@utfpr.edu.br

CMMI – número de certificações – 2013

Posted in processo de produção de software on January 8, 2014 by José Augusto Fabri

CMMI (Capability Maturity Model – Integration ou Modelo de Maturidade em Capacitação – Integração) caracteriza-se como um modelo de referência permeado por práticas (Genéricas ou Específicas) que se relacionam diretamente com a maturidade das das áreas do conhecimento da Systems Engineering (SE – Engenharia de Sistemas), Software Engineering (SW – Engenharia de Software), Integrated Product and Process Development (IPPD – Desenvolvimento Integrado de Processo e Produto) e Supplier Sourcing (SS).

O modelo foi desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon. Atualmente, o CMMI se caracteriza como uma uma evolução do CMM.

O CMMI é dividido em 5 níveis de maturidade, as empresa classificadas no nível 1 possuem um process ad-hoc, já as emrpesas classificados no nível 5 possuem um processo institucionalizado e otimizado. Geralmente empresas com um processo bem definido, produzem mais e com maior qualidade.

O SEI divulga sistematicamente o número de empresas avaliadas e o número de empresas certificadas. O Figura abaixo apresenta as empresas que possuem um número maior de certificações no nível 5 – classificação efetuada em setembro de 2013.

cmmi sep 2013

O relatório completo sobre as avaliações efetuadas pelos SEI podem ser obtidas neste link.

José Augusto Fabri – fabri@utfpr.edu.br

Metodologia, método, modelo de processo e processo.

Posted in processo de produção de software on December 10, 2013 by José Augusto Fabri

Existem uma ampla discussão científica a respeito das palavras: metodologia e método. Várias pessoas utilizam-nas como sinônimos. Porém, é importante destacar a diferença entre as duas. O método tem relação direta com o processo (como fazer algo?), e a metodologia é área de estudo de vários métodos. Esta definição está embasada na etimologia de ambas as palavras. Metodologia e Método possuem como radical Grego, méthodos = ‘caminho para chegar a um fim’ e logia = ‘estudo de’.

Na Engenharia de Software esta discussão assume um caráter contínuo. Alguns autores assumem que o método caracteriza o processo com uma série de atividades, utilizado na construção de um software, enquanto que uma metodologia se traduz na codificação de um conjunto de boas práticas recomendadas, acompanhada de material de treinamento, programas de educação formal, planilhas e diagramas. Dentro deste contexto, o método de Engenharia de Software pode ser considerado como parte da metodologia.

Outros autores direcionam a metodologia com base em uma abordagem filosófica do problema. Dentro deste contexto é possível afirmar que a Engenharia de Software é rica em métodos e pobre em metodologias. Dentro desta abordagem temos como abordagem metodológica a metodologia estruturada (embasada pelos pressupostos de Edward Yourdon, Chris Gane e Trish Sarson) e a metodologia Orientada a Objetos.

Já um modelo de processo pode ser definido como uma representação ou abstração das atividades caracterizadas em um processo de software. Geralmente, o modelo norteia a instanciação e o sequenciamento das atividades de um processo de software. Na literatura é possível encontrar vários modelos de processo:

Já o processo (de software) é caracterizado por meio de um conjunto de atividades bem definidas e documentadas que quando aplicadas, sistematicamente, garantem certo grau de qualidade na confecção do produto. Além do conjunto de atividades, o processo possui outros atributos como: matéria prima, mão de obra e recursos. Tais atributos são considerados os insumos do processo de produção. Salienta-se também que o processo deve possuir o conceito de retro-alimentação com o objetivo de garantir o caráter evolutivo do mesmo. Todo o processo é instanciado a partir de um modelo.

No meu ponto de vista temos:

  • Método ou processo ágil.
  • Instanciado a partir do modelo evolucionário.
  • Embasado na metologia estruturada ou orientada a objetos.

Por fim, fica a dica:

Embase corretamente os termos metodologia, método, modelo de processo e processo e os utilize de forma correta.

 José Augusto Fabri – fabri@utfpr.edu.br

Modelagem: do Problema ou do Negócio?

Posted in processo de produção de software on November 11, 2013 by José Augusto Fabri

Dentro de um projeto de desenvolvimento de software, a MODELAGEM DO NEGÓCIO se caracteriza como uma das atividades mais importantes. E por meio dela que as regras e os processos essências de um ambiente sistêmico são caracterizados.  Uma boa modelagem pode proporcionar a otimização do ambiente sistêmico, melhorando o fluxo e a velocidade das informações.  Algumas vezes, com a modelagem, é possível resolver o problema sem a implementação do software.  Neste post vou apresentar um case que valida esta afirmação.

Problema

Uma prefeitura de uma cidade de 60 mil habitantes deseja melhorar o processo de matriculas de alunos em suas creches. A secretaria da educação detectou a seguinte falha:  existem alunos matriculados em duas creches durante o mesmo período letivo. Em determinados dias da semana o pai deixa o aluno na creche A e em outros dias na creche B. Este procedimento diminui o número de vagas. Importante salientar o processo de matricula nas creches não é centralizado.

A modelagem do problema, mapeada na figura abaixo, mostra que o processo de matricula não é centralizado. Não existe uma comunicação entre as creches.

modelagem do problema

Solução proposta pela maioria dos analistas

Desenvolvimento de um software que possibilite a integração de todo o processo de matricula nas creches. As informações sobre o processo estão disponíveis em um servidor de dados e as creches acessam este servidor (via rede) e efetuam o matricula.

O projeto implica em:

  • adquirir o servidor e as estações de trabalho a serem utilizadas pelas creches;
  • proporcionar (via rede) a conexão de todas essas máquinas;
  • estabelecer um protocolo de segurança das informações;
  • implementar as regras contidas no protocolo.

Solução gerada com MODELAGEM DO NEGÓCIO

A MODELAGEM DO NEGÓCIO (vide figura abaixo) provê uma alternativa para resolver o problema.

modelagem do negocio

Centralizar o processo de matricula na secretaria municipal de educação. Diariamente as creches informam, via telefone, se existem vagas (pois o cancelamento da matricula pode ser feito diretamente na creche). A secretaria possui uma planilha eletrônica com as informações de todos os alunos matriculados. Os pais ou responsáveis efetuam a matricula na secretaria. A secretaria consulta a planilha. Se as informações do aluno estiverem cadastradas na planilha, a matricula é recusada.

Este projeto não implica:

  • no desenvolvimento do software;
  • na aquisição do servidor e das estações de trabalho;
  • na conexão das máquinas;
  • no estabelecimento e implementação de um protocolo de comunicação.

Discussão

A MODELAGEM DO NEGÓCIO vai além da modelagem do problema. A modelagem do problema apresenta um retrato da situação atual do processo. A MODELAGEM DO NEGÓCIO deve proporcionar uma alternativa altamente eficaz para cliente, ela deve retratar a melhor forma de execução das regras que compõem o negócio.

Deixe de modelar problema e passe a MODELAR NEGÓCIO!

José Augusto Fabri – UTFPR

Aplicando a simulação de cenários na especificação de requisitos de um software

Posted in gestão de projetos, gestão do conhecimento, processo de produção de software on October 15, 2013 by José Augusto Fabri

Pessoal, durante um curso sobre gestão de projetos fui questionado sobre as vantagens de se utilizar a simulação de cenários na especificação de requisitos.

Um cenário (em grego: skené (cena)) é composto de elementos físicos/virtuais que definem o espaço, os objetos no seu interior, cores, texturas, estilos e mobiliário, todos com o objetivo de caracterizar a relação entre os personagens para execução de uma (ou várias) ações.

Atualmente a simulação de cenários é amplamente utilizada na especificação de requisitos de um software. Este tipo de especificação se popularizou por meio da disseminação dos casos de uso.

Existem algumas formas para materializar a simulação de cenários dentro da atividade de levantamento e especificação de requisitos. Abaixo retrato três delas:

1 – Caso de uso (documento de descrição):

O Aluno se dirige a Secretaria Acadêmica munido dos documentos pessoais e solicita a sua matricula em um determinado curso. A Secretaria Acadêmica confere os documentos do Aluno, conforme estabelecido em seu protocolo. A Secretaria Acadêmica efetua a matricula do Aluno no curso solicitado. A Secretaria Acadêmica encaminha o Aluno para a Tesouraria. O Aluno realiza o pagamento da matricula. A Tesouraria emite o recibo de pagamento para o Aluno. O Aluno retorna a Secretaria Acadêmica e apresenta o recibo. A Secretaria Acadêmica confirma a matricula do Aluno e emite o comprovante de matricula.

2 – Diagrama de sequência:

diagrama de sequencia

3 – Utilização de vídeos para simulação de cenários – (vide vídeo – gerados pelos alunos do curso de Engenharia da Computação:

Qual delas é a melhor?

Não existe uma melhor forma de caracterização, todas elas se complementam pois possuem clientes diferenciados, o vídeo assim como o documento de descrição do caso de uso podem ser apresentados ao usuário final. O diagrama de sequência possui informações que podem ser utilizada pelos projetistas e programadores.

Quando utilizar esta técnica para levantar/especificar requisitos?

A simulação de cenários deve ser utilizada no levantamento e especificação dos requisitos custodiais – aqueles requisitos (cenas) que agregam um maior número de atores e objetos. Dificilmente você irá utilizar a simulação de cenários para especificar o requisito: cadastrar informações de cidades.

Vantagens:

A simulação de cenários, quando aplicada de forma híbrida (utilize – ao menos – duas formas de materialização) proporciona:

1- Uma visualização dinâmica do que ocorre no ambiente do usuário. Este tipo de visualização pode explicitar requisitos (artefatos e objetos) implícitos dentro do modelo de negócio.

2- Uma validação mais consistente dos usuários envolvidos com os requisitos. Durante o processo de validação, o usuário pode apontar objetos que não foram apresentados nas formas utilizadas para a materialização da cena.

3- Adere de forma perfeita a contexto da orientação a objetos. Trabalha de forma efetiva com Atores e Objetos.

Utilize a simulação de cenários com seus colaboradores – vide este documento como guia. Veja só o que os alunos da UTFPR (curso: Tecnologia em Análise e Desenvolvimento de Sistemas) acabaram de gerar (15 de outubro, 2013 – 20h42).

abraços

José Augusto Fabri – fabri@utfpr.edu.br

Proposta de um modelo para classificação dos programas de residência em software espalhados pelo país

Posted in gestão do conhecimento, processo de produção de software, qualidade de software on October 8, 2013 by José Augusto Fabri

Pessoal!

Venho trabalhando com o conceito de residência em software algum tempo. Nesse período tive contato direto com 7 programas. Cada um dos programas possui um modelo de implementação diferenciando. Ao analisar os modelos, tomei a liberdade de classifica-los em níveis de qualidade:

  • Nível 1 – Totalmente simulado: O ambiente de residência está incubado em laboratório e os projetos de software são simulados.
  • Nível 2 – Parcialmente simulado: O ambiente de residência está incubado em laboratório e os projetos software são importados da indústria. Neste caso o ambiente também é responsável pela entrega do software.
  • Nível 3 – Ambiente real de execução de projeto de software: O ambiente de residência em software é caracterizado na indústria (empresa do setor produtivo de software) e os projetos software são desenvolvidos para atender clientes reais.
  • Nível 4 – Ambiente real de execução de projetos de software e exportação de conhecimento: O ambiente de residência em software é caracterizado na indústria (empresa do setor produtivo de software) e os projetos software são desenvolvidos para atender clientes reais. Além de atender estes clientes o ambiente exporta conhecimento sobre processo de software, gestão de projetos e de qualidade e ferramentas.

Dos 7 programas: 1 se encontra no nível 1, 2 se encontram no nível 2, 4 se encontram no nível 3. Importante: Nenhum deles se encontram no nível 4.

O trabalho completo pode ser acessado por desta referência.

Duarte, A. S, et. al (2013). Proposal of a Model to Classify Software Residency Environments. InConferência Ibérica de Sistemas e Tecnologias de Informação Proceedings. Lisboa. Portugal.

Até a próxima.

J. A. Fabri – fabri@utfpr.edu.br

Aplicando os pontos por caso de uso para mapear a complexidade de um software

Posted in gestão de projetos, processo de produção de software on August 28, 2013 by José Augusto Fabri

Pessoal,

Nos últimos meses, vários interlocutores do blog Engenharia de Software solicitaram-me informações sobre o mapeamento da complexidade de um software utilizando pontos por caso de uso. O objetivo deste post é justamente trabalhar esse tema.

A técnica para mapear a complexidade de um software por Pontos de Caso de Uso foi proposta em 1993 por Gustav Karner. Ela é baseada em duas outras técnicas – Pontos de Função e o Mk II (adaptação da técnica dos pontos por função, comumente utilizada pelos ingleses). A técnica mapeia a complexidade dos atores e dos casos e uso.

1 – Calculando a complexidade dos atores do software

Classifique os atores envolvidos em cada caso de uso, de forma a obter um somatório de pontos não-ajustado. A classificação de atores utiliza a tabela abaixo: o peso total dos atores do software (Unadjusted Actor Weight, ou UAW) é calculado pela soma dos produtos do número de atores de cada tipo pelo seu respectivo peso (vide tabela 1).

Tabela 1

Ator Interface Peso
Simples Interface de programa (API)

1

Médio Protocolo (Ex.:TCP/IP) ou interface em modo texto

2

Complexo Interface gráfica

3

 2 – Calculando a complexidade dos casos de uso do software

De posse do calculo da complexidade dos atores, podemos mapear a complexidade dos casos de uso do software (Unadjusted Use Case Weight, ou UUCW). O calculo é obtido pela soma dos produtos do número de casos de uso de cada tipo pelo seu respectivo peso (vide tabela 2).

Tabela 2

Caso de Uso Descrição Peso
Simples <= 3 transações ou < 5 classes de análise

5

Médio 4-7 transações ou  5 a 10 classes de análise

10

Complexo > 7 transações ou > 10 classes  de análise

15

 Aplicando a técnica

Para aplicar a técnica eu utilizo dois artefatos gerados pela atividade de projeto, o diagrama de caso de uso e o diagrama de seqüência. O primeiro mapeia a complexidade dos atores e o segundo mapeia a complexidade dos casos de uso. Veja os diagramas nas figuras abaixo.

caso de uso - PpCU

diagrama de sequencia - PpCU

No diagrama de caso de uso é percebemos a presença de 3 atores, dois deles interagem com o software por meio de uma interface gráfica (Gerente e Cliente) e um interage com o software por meio de um protocolo TCP-IP. Neste caso possui dois atores complexos (Gerente e Cliente) – peso 3 e um médio (Sistema de Proteção ao Crédito) – peso 2 (vide tabela 1).

Calculando: 2 atores complexos * 3 + 1 ator médio * 2 = 8.

No diagrama de seqüência (artefato que mapeia a realização de um caso de uso) é possível encontrar 4 transações (troca de mensagens entre os objetos). Ao consultar a tabela 2 eu percebo que a complexidade média é mapeada no intervalo de 4 a 7 transações – peso 10.

Calculando: 1 caso de  médio * 10 = 10.

Basta agora somarmos os dois valores obtidos para obtermos pontos por casos de uso não ajustados (18).

Você pode optar ainda por aplicar o fator de ajuste essa medida encontrada – tema este para um outro post.

Abaixo você encontra um vídeo sobre a aplicação dos pontos por caso de uso. Você também pode utilizar essa planilha (ref: www.cin.ufpe.br/~if717/) para automatizar o seu calculo.

 

José Augusto Fabri – fabri@utfpr.edu.br

Requisitos e projeto de software x Pentágono Wars

Posted in gestão de projetos, Introdução a Engenharia de Software, processo de produção de software on August 21, 2013 by José Augusto Fabri

Pessoal,

No filme, aquilo que aconteceu com o tanque acontece com cerca de 2/3 dos projetos de software. Problemas na definição do escopo do projeto.

J. A. Fabri – fabri@utfpr.edu.br

Instanciando a definição genérica sobre processo para software

Posted in processo de produção de software on July 16, 2013 by José Augusto Fabri

Pessoal,

A vídeo-aula abaixo parte da definição genérica sobre processo  (vide último post) e instancia a ideia para software. Como ferramenta para persistir o conhecimento eu utilizei o cmap tools.

Boa aula.

J. A. Fabri

fabri@utfpr.edu.br

Follow

Get every new post delivered to your Inbox.

Join 37 other followers