Archive for the qualidade de software Category

Graduação em Engenharia de Software na UTFPR

Posted in Ferramentas, gestão de projetos, gestão do conhecimento, Introdução a Engenharia de Software, mercado produtor de software, processo de produção de software, qualidade de software on June 4, 2014 by José Augusto Fabri

modeloA Universidade Tecnológica Federal do Paraná – Campus Cornélio Procópio oferece, a partir do segundo semestre de 2014, o curso de Bacharelado em Engenharia de Software. Atualmente o profissional desta área é um dos mais procurados no Brasil e no Mundo. Veja o projeto pedagógico do curso neste link.

Na figura ao lado você encontra o modelo que norteou todo o desenvolvimento do projeto pedagógico.

Informações adicionais:
Titulação Conferida: Bacharel em Engenharia de Software.
Modalidade de Curso: Ensino presencial
Local de Oferta: Universidade Tecnológica Federal do Paraná Campus Cornélio Procópio.
Coordenação e Unidade Executora: Coordenadoria de Engenharia de Software
Duração do curso: 08 semestres letivos.
Regime escolar: Semestral, com a matrícula realizada por disciplina.
Número de vagas: 88 vagas por ano, com 44 vagas ofertadas em cada semestre.
Turno previsto: Noturno.

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

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

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

CMMI: número de certificações por continente

Posted in qualidade de software on July 3, 2013 by José Augusto Fabri

Pessoal,

Venho acompanhando sistematicamente a evolução do número de certificações no modelo CMMI. Este link traz os últimos números publicados pelo SEI.

Para quem não conhece o modelo segue uma descrição básica.

CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas  necessárias à maturidade em Systems Engineering (SE), Software Engineering (SW), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS). Desenvolvido pelo SEI (Software Engineering Institute) – Universidade Carnegie Mellon, o CMMI caracteriza-se como uma evolução do CMM e norteia um modelo único para o processo de melhoria.

O CMMI é dividido em 5 níveis de maturidade as empresas nos níveis 4 e 5 possuem uma maior qualidade no seu processo de software quando comparadas as empresas dos níveis 1 e 2.

Para maiores informações do modelo, acesse: http://www.sei.cmu.edu/cmmi/

J. A. Fabri

3Cs na Especificação de Requisitos de Software (ERS)

Posted in gestão de projetos, processo de produção de software, qualidade de software on November 20, 2012 by José Augusto Fabri

A Especificação de Requisitos tem como objetivo mapear os requisitos funcionais e não funcionais de um software. A especificação deve traduzir de maneira clara, concisa e consistente (os 3cs) o que o software deve processar (no caso dos requisitos funcionais) em um determinado ambiente (abertura para os requisitos não funcionais).

É possível especificar software utilizando:

O documento de especificação de requisitos deve atender a todos os stakeholders do projeto. Clientes, desenvolvedores, engenheiros, testadores, gerentes devem entender qual o processamento que será realizado por um determinado requisito funcional (imerso no ambiente sistêmico) e a sua complexidade.

A literatura apresenta algumas boas práticas que contribuem diretamente com os 3Cs. Vamos a elas:

  • O que especificar? Requisitos Funcionais,  interfaces externas, performance, restrições, atributos de segurança (por favor complete a lista nos comentários se esqueci de algo).
  • Características de uma especificação: Correta, não ambígua, completa, consistente, os requisitos devem ser ranqueados dada sua importância, os requisitos devem ser verificáveis e rastreáveis.
  • Aplicar ferramentas para agilizar a especificação dos requisitos: A agilidade deve estar presente na construção e na leitura do documento. Lembre-se!!! Temos que gerar documentos claros, concisos e consistentes.

É importante salientar que as boas práticas não garantem totalmente a qualidade da especificação dos requisitos – é somente por meio de um contato constante com o cliente (veja os posts: 1, 2, 3 que reportam a importância do contato com o cliente) e com o ambiente sistêmico é que a especificação dos requisitos irá possuir um grau de qualidade aceitável. Neste ponto é possível mapear um dos fatores crítico de sucesso para qualquer projeto – comunicação com o cliente e com o ambiente.

Tenha em mente que especificar requisitos é de extrema importância para definir o escopo de um projeto. Um projeto com o escopo bem definido pode minimizar a recorrência de problemas ligados a gestão, principalmente em produtos caracterizados como software.

Abraços

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

Proposta de um modelo de rastreabilidade de requisitos permeado por mapas mentais.

Posted in gestão do conhecimento, processo de produção de software, qualidade de software on May 2, 2012 by José Augusto Fabri

Pessoal.

O artigo anexo a este texto, apresenta a proposta de um modelo de rastreabilidade de requisitos de software baseado em mapas mentais. O artigo será publicado na 7ª Conferência Ibérica de Sistemas e Tecnologias de Informação (junho) – Madri Espanha.

Artigo.

Abraços.

O outro lado das métricas de um software

Posted in gestão de projetos, gestão do conhecimento, processo de produção de software, qualidade de software on March 12, 2012 by José Augusto Fabri

Esta semana me deparei com uma questão extremamente interessante e complexa. Existe um modelo (ou métrica) que estime o valor agregado que um software irá trazer após a sua implantação?

O valor agregado caracteriza-se pelo aumento do capital intelectual, financeiro e de gestão em uma organização do setor produtivo dado a incorporação de uma entidade (pessoa, grupo de pessoas, software, ferramenta ou processo).

A implantação de um software (desde que seja bem conduzida) pode trazer um aumento substancial dos capitais elencados no parágrafo anterior, a organização analisa seu modelo negócio, reorganiza processos, realoca pessoas e reflete sobre questões relacionadas à persistência do conhecimento.

Introduzir métricas dentro deste contexto não é uma tarefa fácil, demanda conhecimentos que transcendem a esfera puramente técnica relacionada à definição, desenvolvimento e implantação de um software. É necessário conhecer profundamente o ambiente sistêmico no qual o software irá funcionar. Conceitos ligados a planejamento de produção devem fazer parte do escopo do profissional que irá promover a aplicação destas métricas.

Antes de conceber um modelo, tentarei compartilhar um caso (real) sobre o retorno temporal e financeiro na execução de um determinado processo negócio, dada a análise correta e reorganização de processos.

O exemplo

Caracterização do problema:  Zaca (nome fictício) é uma cidade do interior do Brasil. Como toda cidade ela deveria oferecer creche a suas crianças em período integral. Porém este fato não ocorre (não vamos entrar no mérito social da questão). Em virtude do não oferecimento das vagas em tempo integral, os pais matriculam seus filhos na creche A pela manhã e na creche B no período da tarde. Com isto a criança ocupa duas vagas, uma na creche A e outra na creche B, promovendo uma menor democratização no número de vagas. A secretaria municipal da educação (SME) percebeu a “necessidade” de construir um software que una o processo de matrícula nas creches em uma rede de dados. A caracterização sistêmica elaborada a partir da descrição problema pode ser visualizada por meio do diagrama de seqüência representado no lado esquerdo.

Solução do problema (emitida por um consultoria após analisar o ambiente sistêmico – vide diagrama a direita): Não é necessário implementar software sobre uma rede de dados que una o processo de matrícula. É necessário apenas reestruturar os processos de negócio. Como? Seguindo os passos abaixo:

a)      Entre as 16h e 18h as 6 creches devem comunicar via telefone a SME a disponibilidade de vagas dada alguma desistência.

b)      A SME deve disponibilizar uma pessoa para captar e controlar estas vagas.

c)       Os pais não irão realizar a matricula na creche e sim na SME (visto que a cidade é de pequeno porte).

De posse do exemplo questiono: Qual foi o valor da organização sistêmica (reestruturação do processo) efetuada?

Para tentar responder esta questão utilizei a seguinte premissa:

se valor > preço então benefício > custo

O valor (não financeiro e sim no sentido do retorno gerado para a organização) da análise efetuada é extremamente alto se comparado ao preço do software e da infra concebida na caracterização do problema. Este fato nos remete a um aumento substância do benefício coletivo, a prefeitura de Zaca pode aplicar toda a verba que seria destinada a construção do software para resolver o problema central – construir mais creches para atender as crianças em tempo integral.

Esboço do modelo de métricas pós-implantação

O esboço do modelo de métricas pós-implantação leva em consideração aumento da:

  • Capacidade de gestão da organização: O software implantado proporciona uma maior governança dentro do ambiente organizacional? É possível prever o tempo/esforço/custo de um projeto com maior grau de certeza? Antes da implantação do software quantas previsões de tempo/custo/esforço se concretizavam? Este número aumentou após a implantação? O que isto implica em termos de satisfação do cliente? Qual a colaboração do software junto aos padrões de qualidade da organização?
  • Capacidade financeira da organização: A implantação do software provê uma diminuição de tempo e esforço para a execução de uma determinada tarefa? Se sim, qual é o valor quantitativo desta diminuição?
  • Capacidade intelectual da organização: O desenvolvimento e a implantação do software promoveram o aumento da visão organizacional dos colaboradores? É possível quantificar este aumento? O software possui subsídios para armazenar conhecimentos explícitos sobre o processo de negócio? Se sim, este conhecimento é de fácil recuperação?

Analise o ambiente organizacional após a implantação do software e tente responder estas questões. As respostas iram refletir o valor agregado que um software traz após a sua implantação.

Fabri – Universidade Tecnológica Federal do Paraná (fabri@utfpr.edu.br).

Follow

Get every new post delivered to your Inbox.

Join 38 other followers