Archive for the gestão de projetos 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

Kanban no desenvolvimento distribuído de software

Posted in gestão de projetos on May 14, 2014 by José Augusto Fabri

kanban ddsKanban é uma palavra de origem japonesa que significa placa ou registro. O Kanban permite agilizar a produção de componentes de software. Originário na indústria automobilística, os Kanbans físicos (cartões – ou post-it) se movimentam ou transitam entre as atividades de um processo de produção, permitindo uma gestão eficaz de um projeto – Esta forma gestão foi conhecida como Sistema Toyota de Produção.

No mês de abril realizei um experimento utilizando o Kanban no desenvolvimento distribuído de software.  O relato do experimento é dividido em 3 partes

1 – Caracterização do problema.

Uma empresa de software recebeu a incumbência de gerir um projeto de software cujo desenvolvimento teria características distribuídas.

Essa empresa fracionou o projeto e subcontratou três sites (outras empresas) para o desenvolvimento.

Cada site recebeu uma fração do projeto a ser desenvolvimento. Esta fração foi dividida em funcionalidades. Importante: O projeto já estava especificado e os sites eram responsáveis somente pela implementação e pelo teste do software.

2 – Princípios da gestão de projeto utilizados.

Ao receber o projeto, a empresa, responsável pela gestão global, consultou a sua base histórica de projetos e delineou as estimativas de custo, prazo e esforço. Estas informações foram consolidadas na Estrutura Analítica do Projeto (EAP) e no Cronograma.

Os pacotes de trabalho da EAP foram distribuídos para os 3 sites.  Os sites de posse destes pacotes consultaram a sua base histórica de projetos e estimaram o custo, o esforço e o tempo. Estas estimativas foram confrontadas com aquelas geradas com as da responsável pela gestão global do projeto. Este tipo de confronto, denomino como equalização do projeto. Realizado o confronto os sites popularam a coluna to do do quadro Kanban.

3 – A execução e o controle do projeto.

Durante a execução do projeto os sites percorreram as atividades de implementação e teste de software. Estas duas atividades caracterizam duas colunas do quadro kanban. É importante salientar que o quadro Kanban estava centralizado na ferramenta kanbanize (kanbanize.com).

É importante salientar que a ferramenta proporciona que todos os sites enxerguem um único quadro Kanban do projeto. Dentro desta ótica, ao movimentar os pacotes de trabalho de to do para implementaçãoe de implementação para teste todos tinham conhecimento sobre o andamento do projeto.

Quando os pacotes atingiram a coluna done do quadro Kanban, as informações sobre tempo, custo e esforço de produção foram caracterizadas pela própria ferramenta. Essas informações foram estruturadas e inseridas na base histórica da empresa responsável pela gestão global do projeto.

A Figura apresentada no início do post tenta resumir o relato do experimento realizado.

Por fim, é importante salientar este relato atenta somente as questões ligadas a planejamento, execução e controle do desenvolvimento distribuído de um projeto de software. Problemas sobre o fracionamento e integração do projeto foram mapeados porém não relatados.

Fabri – fabri@utfpr.edu.br

A relação entre a motivação e a expectativa

Posted in gestão de projetos on April 15, 2014 by José Augusto Fabri

Na sua vida, você deve estabelecer uma relação ótima entre a motivação e expectativa.

Na minha singular visão, a motivação é caracterizada como uma força interior com intensidade oscilante. Acredito ainda que não é possível motivar alguém a realizar uma determinada tarefa. Existe sim a possibilidade de criar um ambiente motivador para a execução de um projeto específico. É neste ambiente que as pessoas encontrarão por si só os motivos para executar ações necessárias ao sucesso de um projeto (de trabalho, pessoal …).

A expectativa caracteriza-se como uma condição de quem espera pela ocorrência de algo (bom ou ruim). Esta espera é baseada em comportamentos e probabilidade.

Em seu dia-a-dia você deve possuir expectativas positivas, fato este que irá motivá-lo para que elas ocorram.  Uma expectativa positiva é o fator crítico de sucesso na construção do ambiente motivador.

O quadro abaixo relaciona de uma forma simples a motivação e a expectativa.

motivacao e expectativa

Mantenha-se no quadrante verde. Evite o quadrante vermelho. Se você trabalha muito e não obtém retorno, reveja suas expectativas – quadrante azul. Se você possui boas expectativas e não está motivado, geralmente, você se encontra no estado de comodismo – quadrante laranja.

Iniciação Tecnológica da UTFPR – Cornélio Procópio gera Plugin astah para contagem de pontos por função

Posted in Ferramentas, gestão de projetos on March 24, 2014 by José Augusto Fabri

brÉ com satisfação que comunico a lançamento (versão beta) do Plugin para contagem de pontos por função em um projeto de software.

O plugin é fruto de um Projeto de Iniciação Tecnológica (PIBIT) da Universidade Tecnológica Federal do Paraná – Campus Cornélio Procópio.

Allan Mori, aluno do curso de Engenharia da Computação, trabalha ativamente na implementação do plugin sob minha orientação.

O Plugin está disponível para a versão 6.7.x do astah professional.

A versão 0.9 do plugin se caracteriza-se como uma  versão beta e tem como objetivo colher melhorias junto a comunidade da engenharia de software.

Link para download do plugin

Link para download da forma de utilização do plugin.

Para sabe mais sobre a teoria de pontos por função acesse: http://wp.me/pcuYv-zd

Parabéns Allan pelo trabalho realizado.

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

Kanban em quadrinhos

Posted in gestão de projetos on March 17, 2014 by José Augusto Fabri

Pessoal, no início do ano tive que apresentar o Kanban a uma empresa de produção de software. Na apresentação utilizei uma estória em quadrinhos. Compartilho com vocês o quadrinhos utilizados.

kanban em quadrinhos

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

Problemas mais frequentes na gestão de projeto

Posted in gestão de projetos on January 7, 2014 by José Augusto Fabri

Segundo o pmsurvey.org (uma pesquisa anual , organizada voluntariamente pelos Chapters do PMI – Project Management Institute de diversos países) os problemas mais frequentes na gestão de projeto são:

  • Comunicação (66,3% dos projetos);
  • Escopo (59,2%);
  • Cumprimento de prazos (55,8%);
  • Insuficiência de recursos humanos (47,6%);
  • Riscos (44,6%);
  • Estimativas (42,5%).

É importante salientar que a pesquisa congrega informações de 676 organizações.

Ao analisar o relatório na íntegra é possível perceber que existe uma relação direta entre os problemas citados. Vamos a ela:

  • Problemas relacionados à falta de comunicação geram escopo incompletos, este fato já discutido por este blog, esta discussão é retratada no posts 1 e 2.
  • Escopo incompleto gera estimativas incorretas.
  • Com estimativas incorretas é impossível definir prazos e recursos consistentes. Dentro deste contexto o risco do projeto falhar é enorme.

Concluindo: Em um projeto prefira palavras que salvam em detrimento as palavras que agradam.

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

A construção de um relacionamento com o cliente interno

Posted in gestão de projetos, gestão do conhecimento on October 30, 2013 by José Augusto Fabri

níveis do sit togetherO relacionamento define a forma de comunicação (ou tratamento) entre os indivíduos em um determinado ambiente. Quando a comunicação flui de forma simples e tranquila constata-se que existe um bom relacionamento entre as partes.

O relacionamento pode assumir algumas facetas, neste texto cito 3:

  • Parceria: trabalho que os indivíduos de uma equipe realizam em conjunto para alcançar um objetivo comum. É importante que exista harmonia e interesse entre as partes para que a parceria ocorra.
  • Autoridade:  a pessoa que possui maior poder em um ambiente social, e por consequência, é responsável por coordenar o relacionamento entre pessoas. Importante: Nunca utilize a autoridade de forma indiscriminada. A autoridade deve ser conquistada, isso irá gerar a liderança.
  • Liderança: autoridade não imposta, mas, conquistada. Os indivíduos de um determinado ambiente consentem em dar autoridade para uma pessoa, mesmo que informalmente. Líder é aquele que influência sem imposição. Harmonia de interesses, carisma e companheirismo são palavras de ordem que permeiam a liderança.

A construção de um relacionamento com seu cliente interno (ou colaboradores) passa pelo estabelecimento de uma relação de proximidade, ouça o que o colaborador tem a dizer, tente proporcionar situações de parcerias entre você e ele. Proporcione situações em que seu colaborador melhore o seu processo. Conquiste a sua liderança.

Existem diversas práticas para a construção deste tipo de relacionamento. Dentro de meus ambientes sociais proponho a utilização do sit together (sentar junto) – prática advinda de processo ágeis.

Durante as relações de trabalho, o sit together poder ocorrer em 5 níveis:

1 – Workstation: Lideres de células sentam junto com seus colaboradores e buscam soluções ligadas as práticas individuais para melhoria do processo e do produto. Este tipo de relacionamento é facilitado devido a proximidade já pré-estabelecida entre líderes e colaboradores.

2 – Célula de Produção: Neste nível, o sit together, permeia toda a célula de produção. O líder busca difundir novas práticas (criadas no nível de workstation) para a melhoria do processo na célula. Essa difusão pode ocorrer formalmente, via treinamento ou reunião, ou informalmente, durante uma atividade lúdica proposta pelo líder.

3 – Colmeia:  Neste nível, o sit together, reúne todas as células de produção da empresa. Geralmente, a empresa busca a institucionalização completa das boas práticas delineadas. Dada a quantidade de células, e consequentemente de colaboradores, a institucionalização das práticas neste nível possui uma maior complexidade se comparada a outras duas. Aqui o sit together pode ocorrer formalmente, porém é interessante que ele ocorra por meio de uma atividade lúdica, por exemplo: você poderia promover o conhecimento sobre as boas práticas de um processo produção solicitando que os colaboradores desenvolvessem ou participassem de alguma atividade que não faz parte de seu cotidiano – um jogo de empresas, a criação de um produto a partir de materiais recicláveis.

4 – Nível Empresarial: Neste nível o sit together ultrapassa as fronteiras do ambiente produtivo e operacional e ocorre nos níveis tático e estratégico. Gerentes e diretores sentam juntos e discutem as políticas, o modelo de governança e, principalmente, traçam novas estratégia para a empresa. Para mediar o sit together neste nível é necessário um conhecimento profundo sobre o modelo de negócio na qual a empresa está imersa.

5 – Relações sociais e externas. Neste nível o sit together ocorre entre parceiros corporativos. Um bom exemplo de relacionamento neste nível são os arranjos produtivos locais e os parques de tecnologia. Posições estratégicas e políticas da região são fomentadas neste nível.

Enfim, para que o sit together possa ocorrer de forma harmônica e consistente é necessário que parcerias sejam estabelecidas e lideranças sejam fomentadas em todos os níveis.

José Augusto Fabri – UTFPR – CP

Alessandro Silveira Duarte  – UTFPR – CP

André Endo – UTFPR – CP

Motivação e trabalho segundo Daniel Godri

Posted in gestão de projetos, off topic on October 19, 2013 by José Augusto Fabri

Motivação e trabalho segundo Daniel Godri, vale a pena investir o seu tempo e assistir esse vídeo.

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

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

Follow

Get every new post delivered to your Inbox.

Join 38 other followers