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

Quando a programação em pares deve ser adotada em ambiente empresarial?

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

Pessoal…

Atualmente existem várias questões sobre a adoção da programação em pares. Este tipo de arranjo é mais produtivo se comparado ao arranjo individual? É possível estabelecer momentos em que uma empresa deve adotar o arranjo emparelhado no ambiente de programação?

Para responder estas questões eu e professor Alexandre L´Erario desenvolvemos 7 experimentos controlados, 4 deles no ambiente acadêmico e 3 no ambiente empresarial.

A realização dos experimentos mostrou que para problemas (programas) de complexidade alta a produção em pares é mais produtiva (tempo de produção) e provê código de maior qualidade.

Com base nos resultados gerados com os experimentos, concluímos que o arranjo emparelhado deve ser adotado em um ambiente empresarial somente na solução de problemas (programas) complexos.

Importante: Para detectar problemas de complexidade alta a empresa deve possuir um processo de software definido e institucionalizado.

O trabalho na íntegra pode ser obtido a partir deste link.

José Augusto Fabri e Alexandre L´Erario – fabri@utfpr.edu.br

plugin astah – calculando pontos por função-entradas

Posted in astah, gestão de projetos, processo de produção de software on December 7, 2015 by José Augusto Fabri

logo-friendsPessoal, neste post, vou apresentar como realizar o calculo dos pontos por função – analisando as entradas de dados. Caso você não esteja acompanhando a série de posts sobre o plugin sugiro que leia o primeiro e o segundo.

Se você não conhece a teoria de pontos por função, acesse este tutorial.

Para realizar o calculo siga os passos abaixo:

1 – abra o astah Professional

2 – abra o arquivo gerado a partir do post anterior.

3 – crie um diagrama de caso de uso. Clique no item de menu Diagram e posteriormente escolha a opção UseCase Diagram.

4 – Crie o ator User e os casos de uso to insert people e to insert cities. Faça a relação entre os atore casos de uso (vide figura abaixo).

5 – Você necessita avisar o astah que estes casos de uso se caracterizam como entradas. Para isto vamos “estereotipá-los” com <<input>>. Clique no caso de uso to insert people e depois clique na aba Stereotype (1), clique no botão Add (2) e digite <<input>>  para o estereótipo (3) (veja os círculos em preto na figura abaixo).

calculo entrada 1

6 – Agora você deve informar quantos arquivos e quantos campos esta entrada irá manipular. Para inserir o registro de uma pessoa é necessário manipular os dados da tabela cidades (lembre-se do Diagrama de Entidade e Relacionamento que você criou). Para realizar este passo clique no caso de uso to insert people (1), na aba TaggedValue (2), no botão Add (3) e digite Files para o campo Name (4) e 2 para campo Value (5). Clique novamente no botão Add e digite Fields para o campo Name e 5 para o campo Value. Esta entrada de dados irá manipular 2 arquivos e 5 campos (3 campos da tabela people e 2 campos da tabela cities) – vide Figura abaixo:

calculo entrada 2

7 – Repita os passos 5 e 6 para o caso de uso to insert cities. Neste caso de uso o Files será 1 e o Fields 2 (a entrada irá manipular uma tabela (ou arquivo) e dois campos).

8 – Execute o plugin astah para contagem de pontos por função, menu Tools, item Metrics, opção Function Point.

A contagem resultará em 21 pontos por função.

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

 

plugin astah – calculando pontos por função – arquivos lógicos internos

Posted in gestão de projetos, processo de produção de software on December 1, 2015 by José Augusto Fabri

Pessoal, neste post, vou apresentar como realizar o calculo dos pontos por função – analisando somente os arquivos lógicos internos. Caso você não esteja acompanhando a série de posts sobre o plugin sugiro que leia este.

Se você não conhece a teoria de pontos por função, acesse este tutorial.

Para realizar o calculo siga os passos abaixo:

1 – abra o astah Professional.

2 – crie um novo projeto – menu file – new.

3 – crie um diagrama de entidade e relacionamento (vide figura abaixo).

calculo ali - der1

4 – Crie a tabela Pessoas (People) e Cidades (Cities). Insira o campos na tabelas conforme a figura abaixo.

calculo ali - der2

5 – Execute o plugin astah para contagem de pontos por função, menu Tools, item Metrics, opção Function Point.

A contagem resultará em 14 pontos por função.

No próximo post iremos apresentar a contagem dos pontos por caso de uso.

Até a próxima

J. A. Fabri

fabri@utfpr.edu.br

 

plugin astah para contagem de por função

Posted in astah, gestão de projetos, processo de produção de software on November 25, 2015 by José Augusto Fabri

Pessoal, em 2014 tive a oportunidade de lançar a versão beta do plugin astah para contagem de pontos por função. O plugin foi desenvolvimento durante um projeto de iniciação tecnológica da Universidade Tecnológica Federal do Paraná – Campus Cornélio Procópio.

Depois de uma longa jornada, hoje tenho a oportunidade de compartilhar com vocês a versão 1 do plugin. Esta versão pode ser obtida por meio deste link.

Para instalar o plugin você pode utilizar o este guia.

Se você já conhece a teoria de pontos por caso por função você pode utilizar o plugin a partir deste guia.

Agora se você não nada sobre pontos por função, você pode aprender a “metrificar” um software com este pontos a partir deste tutorial.

Nas próximas semanas irei publicar alguns tutoriais detalhando sobre como utilizar o plugin.

É importante salientar que o projeto foi desenvolvimento pelo aluno Allan V. Mori. Parabéns Allan pelo trabalho desenvolvido.

Fique a vontade para utilizar o plugin em seus projetos.

abraços

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

A engenharia do como

Posted in Introdução a Engenharia de Software, processo de produção de software with tags , , on June 11, 2015 by José Augusto Fabri

A engenharia pode ser caracterizada como a arte de aplicar os conhecimentos, advindos das mais variadas áreas de conhecimento, na criação ou aperfeiçoamento de materiais, estruturas, máquinas, aparelhos, sistemas ou processos.

Já a ENGENHARIA DE SOFTWARE pode ser considerada uma área da Ciência da Computação que tem como objetivo a especificação, desenvolvimento e manutenção de sistemas de software. Atualmente, a ENGENHARIA DE SOFTWARE,                também estabelece uma relação estreita com outras áreas do conhecimento, tais como: Gerência de Projetos; Teoria da Qualidade; Gestão de Conhecimento.

Ao analisar ambas as definições é possível perceber que todas tratam o que fazer e não como fazer. Este fato é estendido aos livros, modelos de qualidade, disciplinas, consultorias e cursos ligados  à ENGENHARIA seguem o mesmo raciocínio, relatam o que e não como.

Afirmo isto com legitimidade, pois participo de diversas consultorias e trabalho dentro de um curso de engenharia de software que contrapõe a afirmação apresentada acima. A prova desta contraposição está ligada ao feedback que recebo de vários alunos e clientes (empresas que nos contratam, via Fundação, em consultorias). Estes feedbacks estão armazenados em minha base histórica de projetos, compartilho alguns com vocês.

  • O método de trabalho delineado pela sua equipe para nossa empresa alterou nossa forma de trabalho. Vocês executaram conosco, de forma prática, o método proposto, todos perceberam como fazer para estabelecer métricas de qualidade. A outra consultoria dizia-nos apenas o que fazer”. (feedback obtido após a implantação de um processo em uma empresa).
  • Professor, em sua disciplina sempre você apresenta como trabalhar a engenharia de software, você vai além do campo teórico, sempre embuti a prática em todas as aulas – esta constatação também pode ser estendida a todos os demais professores” (feedback obtido no final de 2014, após ministrar aulas de introdução a engenharia de software, no curso de Bacharelado em Engenharia de Software da Universidade Tecnológica Federal do Paraná).

Todos nós, profissionais que trabalhamos diretamente com as Engenharias, devemos relatar para toda a comunidade, acadêmica e empresarial, como fazer e não somente o que fazer.

O como fazer gera mais positividade, ou seja, a percepção do processo é real e todos entendem passo a passo aquilo o que está sendo construído. Possibilitam os envolvidos a receber um conjunto de conhecimentos mais sólidos.

Importante: O como fazer provê um aprendizado mais rápido e com maior qualidade.

Saia da esfera teórica e atinja a prática, durante a realização de seu trabalho, de suas aulas, de suas consultorias e na concepção de seus livros e materiais – foque mais o como.

Acredito que estamos perdendo este horizonte. As nossas universidades são, em sua grande parte, teóricas. A indústria necessita de pessoas que resolvem problemas de forma rápida e consistente.

Enfim, que tal praticar mais a engenharia do como e menos a engenharia do que?

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

Mapa conceitual representando conceitos de processo de software

Posted in processo de produção de software with tags , on February 14, 2015 by José Augusto Fabri

Pessoal,

Compartilho o mapa conceitual representando conceitos de processo de software. O mapa foi desenvolvido em uma das aulas de engenharia de software da UTFPR campus CP.

mapaProcessSw

Prof. Fabri – fabri@utfpr.edu.br

Instanciadas as Práticas XP aliadas ao Scrum em um projeto

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

figuraPessoal, no último post o Scrum incorporou algumas práticas do XP. Neste texto iremos instanciar o modelo genérico (vide figura ao lado) em um projeto de software. O projeto tem como meta desenvolver um software para controle de uma clínica médica.

Para apresentar o modelo instanciado vou assumir que a minha Product Backlog está configura e conta com os seguintes itens:

Agendar consultas; Cadastrar Cidades; Cadastrar Convênios; Cadastrar Exames; Cadastrar Laboratórios; Cadastrar Médicos; Cadastra Pacientes; Consultar Pacientes; Emitir Relatório de Pacientes por Clientes; Emitir Relatório Gerado na Consulta; Habilitar Convênios Médicos; Habilitar Exames; Realizar Pré-Consultas.

Iremos utilizar os Cartões de Estórias (vide quadro 1) para formatar um dos itens da Product Backlog. Importante, em nosso projeto teremos um total 13 cartões como este. Nota: É possível utilizar as Metáforas para definir o conteúdo das Estórias (não iremos retratar como construir uma Metáfora neste texto).

————————————————————————–

Item da Product Backlog: Emitir Relatório Gerado na Consulta

A emissão do relatório gerado na consulta tem como objetivo apresentar ao paciente os exames que ele necessita realizar, quais são os laboratórios habilitados a realizar esses exames, os medicamentos que ele deve consumir, informações sobre o exame clínico: peso, altura, pressão, circunferência abdominal. O relatório é emitido logo após a consulta. Os dados que constituem o relatório são gerados pelo médico durante a execução da consulta.

————————————————————————–

Quadro 1 – Cartão de Estória

De posse dos cartões é necessário definir quantos (e quais) irão compor a Sprint. Neste momento a prática Jogo do Planejamento é instanciada (quadro 2).

————————————————————————–

Jogo do planejamento

Minha equipe é capaz de produzir 4 Estórias a cada Sprint (duração de minha Sprint é de 2 semanas).

O Product Owner priorizou 5 Estórias: Emitir Relatório de Pacientes por Clientes; Emitir Relatório Gerado na Consulta; Habilitar Convênios Médicos; Habilitar Exames; Realizar Pré-Consultas.

Durante a negociação o Scrum Master argumentou que não era possível emitir qualquer tipo de relatório sem antes armazenar as informações de médicos  e pacientes. O mesmo ocorre com as consultas, pré-consultas e habilitação de exames.

Scrum Master e Product Onwer chegam a um acordo, a Sprint terá 4 Estórias: Cadastrar Cidades; Cadastrar Convênios; Cadastrar Exames; Cadastrar Laboratórios.

————————————————————————–

Quadro 2 – Jogo do Planejamento

Realizado o Jogo do Planejamento teremos a nossa Daily Scrum Meeting (vide a ilustração desta reunião no quadrinhos abaixo). Perceba que a Daily Scrum Meeting é formatada seguindo as prerrogativas do Stand-up Meeting (reunião em pé).

daily scrum meeting

Percebam (nos quadrinhos) que a respostas dos pares são as mesmas. E nenhum integrante do Scrum Team aponta dificuldades.

Após a realização da Daily Scrum Meeting os pares (Pair Programming) iniciam a construção das funcionalidades (Pair Programming) espelhadas nos Cartões Estórias, utilizando esse Padrão de Código. Um dos Pares observou que algumas funcionalidades desenvolvidas em outro produto não respeitavam a Padronização de Código e partiram para um processo de Refabricação da referida funcionalidade. Esta percepção ocorreu porque o Par utilizou a prática de reuso para construir o Cadastro de Cidades.

Outra prática importante delineada pelo par é o Design Simples (esta não será ilustrada neste texto).

Ao término da Sprint um incremento do produto foi entregue ao Product Owner.

Todo o ciclo de produção proposto do Scrum foi percorrido.

Fabri – fabri@utfpr.edu.br

Follow

Get every new post delivered to your Inbox.

Join 680 other followers