Archive for the gestão do conhecimento 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

Gestão de expectativa para minimizar a rotatividade de empresas de TI

Posted in gestão do conhecimento on December 5, 2013 by José Augusto Fabri

A Teoria das Expectativas foi desenvolvida pelo psicólogo Victor Vroom. Esta teoria procura explicar questões relacionadas à motivação humana. Vroom propõe que o processo de motivação deve ser delineado a partir dos objetivos e das escolhas de cada indivíduo e das suas expectativas em atingir a esses mesmos objetivos. Sinteticamente, o autor defende que a força motivacional (M) de um determinado indivíduo, corresponde ao produto do valor atribuído a um objetivo (V) pela expectativa de alcançar esse objetivo (E). Neste caso temos:

M = V * E.

M: força motivacional;

V: Valor de um objetivo;

E: expectativa de alcançar esse objetivo.

Tendo em vista que o valor de objetivo é intrínseco ao indivíduo eu proponho que: A gestão de parte do processo motivacional deve ser efetuada, somente, sobre a expectativa (E).

Para defender esta proposição vou partir de duas características inerentes a qualquer indivíduo que influem diretamente na composição do valor de um objetivo (V).

Autoconhecimento: A pessoa (ou indivíduo) tem a noção exata de seu conhecimento (saber-se). A capacidade de promover uma autoavaliação sistemática e constante é inata a este tipo pessoa.

Conhecimento do ambiente: o ambiente no qual o indivíduo está imerso é analisado constantemente. Opções, tendências, limitações e alternativas de desenvolvimento pessoal e profissional fazem parte do metiê desta pessoal.

Tanto o autoconhecimento como o conhecimento do ambiente são internalizados pela própria pessoa, ou seja, estas características não fazem parte de um processo de ensino e aprendizagem. Eu não consigo ensinar (ou aprender) autoconhecimento e conhecimento do ambiente.

De posse destas características (intrínsecas) um determinado indivíduo determina, por meio de referenciais individuais, seus objetivos e atribui um valor (ou prioridade a eles). Perceba que este valor pertence à pessoa (ele foi atribuído segundo o autoconhecimento e o conhecimento do ambiente), somente ela possui o poder de alterá-lo. Este fato valida a proposição destacada neste texto: A gestão de parte do processo motivacional deve ser efetuada, somente, sobre a expectativa (E).

O problema passa a ser a composição da variável E.

Neste post vamos estabelecer diretrizes de composição para esta variável que possibilite minimizar a rotatividade de pessoal em empresas de TI. Importante: você pode estabelecer diretrizes de composição da variável E em outros contextos.

O processo de composição da variável E:

Vamos supor que um desenvolvedor de software possui um grande conhecimento em .NET – ele sabe disso – AUTOCONHECIMENTO. O ambiente (neste caso de mercado) possui excelentes oportunidades para trabalhar com JAVA – o desenvolvedor também sabe disso – CONHECIMENTO DO AMBIENTE.  De posse destas informações ele estabelece como objetivo: “aprender Java e conseguir uma melhor oportunidade de trabalho”. O objetivo, delineado, possui prioridade para o desenvolvedor. Neste caso o valor do objetivo (V) é alto.

Enquanto empresa, como eu posso gerir a expectativa deste colaborador?

Componha a variável E tendo em vista 4 diretrizes:

1 – estabeleça ciclos (curto) para o atendimento dos objetivos: Insira este desenvolvedor em um projeto JAVA ou proporcione um treinamento nesta tecnologia para este desenvolvedor. Importante: não desligue o desenvolvedor dos projetos .NET, lembre-se que você necessita do conhecimento dele dentro destes projetos.

2 – proponha desafios focados nos objetivos: Por exemplo, você pode desafiar o seu desenvolvedor a construir um produto (ou uma funcionalidade, ou um componente) em Java. O sentimento de aprendizado aliado ao valor agregado para a empresa irá imergir junto ao desenvolvedor.

3 – Surpreenda o seu colaborador: Você pode estabelecer prêmios e participação no lucro do projeto se o desenvolvedor superar as metas traçadas na proposição dos desafios. Isso pode aumentar a expectativa do desenvolvedor junto a empresa.

4 – Proponha outros objetivos junto ao seu colaborador. Será que o desenvolver não vislumbra conhecer a fundo um framework, o Struts por exemplo. Proporcione que esses objetivos sejam atingidos – retornando a diretriz 1.

Perceba que ao detectar que o colaborador possui um objetivo e este se traduz em uma nova perspectiva de trabalho (rotatividade), as diretrizes apresentadas neste post sugerem que você componha a variável E de forma rápida, com elementos desafiadores, com a possibilidade de crescimento, e com a capacidade de atingir novos objetivos. Em hipótese alguma podemos zerar E, pois:

M = V * 0

M = 0.

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

Carreira proteana e profissionais de TI

Posted in gestão do conhecimento on December 5, 2013 by José Augusto Fabri

Um dos grandes problemas das empresas de Tecnologia da Informação é minimizar a rotatividade de pessoal.

Os clientes internos em uma empresa de Tecnologia de Informação possuem uma carreira com característica proteana. Proteana tem origem na palavra grega Proteus, deus do mar, que muda suas características conforme a sua vontade. Um colaborador que se insere em uma carreira proteana não enxerga grandes dificuldades em mudar de emprego, empresas ou setor. Nesta carreira o colaborador está sempre em busca de algo novo.

Quais as características de um cliente interno imerso em uma carreira proteana?

Autoconhecimento: O cliente interno (ou colaborador) tem a noção exata de seu conhecimento técnico (saber-se). A capacidade de promover uma autoavaliação sistemática e constante é inata a este tipo pessoa.

Conhecimento de mercado: o mercado dentro e fora do contexto empresarial na qual o cliente interno está imerso é analisado. Opções, tendências, limitações e alternativas de desenvolvimento profissional fazem parte do metiê do colaborador.

Objetivo da carreira: Ao se aprofundar no conhecer a si mesmo e no conhecimento de mercado, o colaborador tem a capacidade de estabelecer referenciais individuais focados nos seus objetivos de vida e, principalmente, na sua carreira. Dentro deste contexto o colaborador busca responder constantemente a seguinte questão: Como posso estar mais feliz daqui a 4 anos?

Estratégia de carreira: De posse dos objetivos, o colaborador utiliza-se da seguinte pergunta: Qual é a estratégia que irei traçar para alcança-los? Por exemplo: o colaborador tem como estratégia a diversificação de seu portfólio de conhecimento, para isto ele irá em busca de uma nova tecnologia. Aqui ele decide deixar o seu ambiente de trabalho e procura um NOVO.

Para minimizar a rotatividade de pessoal as empresas de TI devem captar constantemente os objetivos da carreira de seus clientes internos e gerir suas expectativas. Esse é um assunto para o próximo post.

J. A. 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

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

Institucionalizando o conceito de base histórica de projetos em empresas de produção de software

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

Uma base histórica tem como objetivo colecionar informações sobre os aspectos produtivos dentro de um projeto. Em empresas focadas na produção de software a base pode conter, entre outras informações, o tempo e o esforço para a execução das atividades do processo e o custo na produção dos artefatos. Por exemplo, duas pessoas trabalharam 10 horas para confeccionar o manual do usuário de um software qualquer.

Existe uma grande dificuldade na institucionalização dessas bases nas empresas do setor produtivo de software. Nos últimos 3 anos visitei cerca de 15 empresas e pude comprovar esse fato.

Com o objetivo sanar essa dificuldade esse texto propõe um método simples e rápido para a concepção -INICIAL- desta base. É importante salientar que o método é aplicado, pelo autor deste blog, nas primeiras horas das consultorias sobre a institucionalização de processo de software.

O método:

1 – Solicite que empresa faça um levantamento dos projetos de software que foram concluídos e implantados em seus clientes.

2 – Implemente junto a lista o tempo (em anos, meses, dias ou horas – depende do escopo do projeto) e o envolvidos com cada projeto.

3 – Mapeie quanto tempo os envolvidos despenderam no projeto.

4 – Cada projeto da lista deve possuir uma breve descrição de seu escopo.

5 – Armazene essas informações em um base de dados – iniciamos a materialização da base.

Ao receber uma nova solicitação de um projeto, a empresa pode consultar a base, verificar se existe um projeto semelhante, geralmente essa resposta é positiva, pois as empresas de software costumam focar alguns modelos de negócios. De posse das informações instanciadas na base, a empresa pode realizar aquilo que chamo de “chute guiado”, melhorando assim a suas estimativas.

O próximo passo agora é analisar o processo das empresas, propor melhorias e refinar a base histórica.

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

Várias formas de especificação de um requisito de software

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

Existem diversas formas de se especificar um requisito funcional. Neste post apresento algumas.

Requisito a ser especificado: Efetuar Matricula

a) Linguagem natural

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.

b) Caso de Uso

caso de uso - esp2

Especificação do Caso de Uso

UseCase: Efetuar Matricula
Sumário: Possibilitar que o aluno, assim que aprovado no processo de seleção (ENEM ou vestibular tradicional) realize sua matricula.
Atores:  Aluno, Secretaria Acadêmica, Tesouraria
Pré-Condições: Aluno aprovado no processo de seleção.
Fluxo Normal: 
1 - Aluno entrega documentação na Secretaria Acadêmica.
2 - Secretaria Acadêmica confere documentação.
3 - Aluno preenche formulário de matricula.
4 - Secretaria Acadêmica solicita que Aluno realize o pagamento da taxa de matricula.
5 - Aluno acessa a Tesouraria para pagamento da taxa de matricula.
6 - Tesouraria entrega recibo para Aluno.
7 - Aluno retorna a Secretaria Acadêmica para efetivar matricula.
8 - Secretaria Acadêmica efetiva a matricula.
9 - Secretaria Acadêmica entrega comprovante de matricula para o aluno.
Fluxo Alternativo: 
2.a - Documentação do aluno incompleta.
2.r - Secretaria Acadêmica solicita ao Aluno que apresente a documentação completa para efetuar matricula.
3.a - Aluno não realiza o pagamento.
3.r - Secretaria Acadêmica não efetiva matricula do aluno.

c) Diagrama de Sequência

diagrama de sequencia

d) Diagrama de Fluxo de Dados

dfd

e) Mapa Conceitual

mapa conceitual  - funcionalidade esp 4

f) Mapa Mental

mapa mental - funcionalidade

É possível estabelecer qual é a melhor forma de especificação?

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

Utilizando o diagrama de espinha de peixe para a definição do escopo de um projeto de software.

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

espinha-gen

O Diagrama de Ishikawa, também denominado Diagrama de Causa e Efeito ou Diagrama Espinha-de-peixe caracteriza-se como uma ferramenta utilizada pela Teoria Geral da Administração para a gestão e Controle de Qualidade de diversos processos. O diagrama foi proposto pelo engenheiro Kaoru Ishikawa em 1943.

espinha-insA sua composição estrutural mapeia as causas de um determinado problema. Toda e qualquer causa pode ser classificada em seis tipos diferentes: Método, Matéria prima, Mão-de-obra, Máquinas, Medida e Meio ambiente (o diagrama também é conhecimento como Diagrama 6Ms).

Exemplo: A causa (ou motivo) que leva a ocorrência de um determinado problema pode estar relacionado a composição da Matéria prima, ou o atraso no processamento das informações de uma determinada Máquina, ou ainda, na falta de capacidade da Mão de obra.

Perceba que a composição estrutural do diagrama é composta por (vide figura em anexo):

  • Cabeçalho: Título, data, autor.
  • Efeito: Título do projeto (ou problema a ser resolvido). O título é escrito no lado direito, envolvido pela cabeça do peixe.
  • Eixo central: Uma flecha horizontal apontando para o projeto.
  • Categoria: Principais grupos de fatores que se relacionam com o projeto.
  • Causa: Todo e qualquer projeto é fracionado em sub-projetos (ou sub-causa), perceba que é necessário executar sub-projetos (ou sub-causas) para atingir o sucesso no projeto como um todo.
  • Sub-causa: Causa que pode contribuir com uma causa maior.

As figuras mapeadas no início deste post apresentam a estrutura genérica e a aplicabilidade de um diagrama em um projeto de software.

Perceba que na cabeça da espinha você encontra a idéia do projeto: Desenvolvimento de uma ferramenta de planejamento e controle de produção de software (PCP-SW). A primeira superior espinha mapeia as pessoas envolvidas no projeto; a segunda as atividades de processo sistêmico; a terceira os equipamentos necessários para que o projeto possas ser implantado com sucesso. As espinhas da parte inferior mapeiam as fontes dos requisitos, o ambiente no qual o projeto será implantado e forma de gestão que será aplicada.

Benefícios do diagrama:

  • Possibilita o mapeamento do escopo do projeto;
  • Registra as causas potenciais que podem ser revistas e atualizadas;
  • Possibilita aglutinação, via brainstorm, dos stakeholders durante o desenvolvimento do diagrama.

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

A importância do log de projeto

Posted in gestão de projetos, gestão do conhecimento on December 10, 2012 by José Augusto Fabri

log de projetoEm um projeto, o log tem como objetivo registrar os eventos relevantes durante a atividade execução. Esse registro possui uma grande importância, pois é a partir dele você consegue estabelecer um controle efetivo das atividades executadas. O registro também serve como artefato de entrada para ajustes na EAP e no Cronograma.

Em meus projetos, utilizo mapas mentais (veja modelo – figura ao lado) para gerar os logs – (perceba que cada projeto possui um mapa-log). No mapa registro :

  • Data-hora da do evento;
  • Evento;
  • Envolvidos;
  • Ocorrências;
  • Decisões tomadas.

Por fim, é importante salientar que o log facilitará a construção do relatório final de projeto e proporcionará a criação de banco de lições aprendidas.

Fabri – fabri@utfpr.edu.br

Follow

Get every new post delivered to your Inbox.

Join 38 other followers