Mapas conceituaia apresentando as técnicas para redação de um artigo científico

Posted in off topic with tags , on February 7, 2015 by José Augusto Fabri

Pessoal,

Desenvolvi 3 mapas conceituais com o objetivo de apresentar técnicas para redação de artigos. As mapa são baseados guia de desenvolvimento de artigos, publicado pelo grupo Stela – Programa de Pós-Graduação em Engenharia de Gestão do Conhecimento da Universidade Federal de Santa Catarina.

O mapa pode ser visualizado abaixo.

artigos

artigos1

 

 

 

 

artigos2

 

 

 

 

 

 

 

 

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

Gerente de Projetos e Escritórios de Projetos

Posted in gestão de projetos on December 2, 2014 by José Augusto Fabri

Diferença entre o Gerente de Projetos e Escritório de Projetos – por Ricardo Vargas.

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

Práticas XP dentro do Scrum

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

O Scrum é um processo de produção iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software (e de qualquer outro projeto). Geralmente o Scrum é adotado por uma equipe de desenvolvimento de produtos.

O Scrum pode ser encarado como um framwork com objetivo de organizar um conjunto de tarefas a ser realizadas objetivando a execução de um projeto.

No Scrum todas as tarefas são aglutinadas na Product Backlog – este artefato é caracterizado como uma lista de tudo aquilo que é necessário para executar o projeto.

A Product Backlog é fracionada, gerando listas menores – as Sprints Backlog. Estas listas são inseridas nas Sprints.

As Sprints caracterizam como ciclos temporais de trabalho, a duração de cada Sprint é de 2 a 4 semanas.

Diariamente, os envolvidos com o projeto realizam as Daily Scrum Meeting – reuniões diárias com o objetivo de verificar, junto aos membros da equipe (Scrum Team):

  1. O que você foi feito ontem?
  2. O que você vai fazer hoje?
  3. Existe algum impedimento?

Importante: Todos os membros Scrum Team devem participar destas reuniões.

Após o término das Sprints, o proprietário do produto (Product Owner) recebe parte do produto pronto gerado pelo projeto. É importante salientar que esta parte deve possuir um valor agregado.

Outro fator a ser destacado, o Scrum prevê também quw todo o projeto seja gerenciado pelo Scrum Master (“responsável por garantir que o Scrum Team se orienta pelos valores e práticas do Scrum”).

Programação extrema (do inglês eXtreme Programming – (XP)), é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver projetos com requisitos vagos e em constante mudança. A estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software é uma constante na metodologia.

O XP possui práticas interessantes, este texto destaca:

Produção em Pares: O colaborador nunca trabalha sozinho. Sempre existem dois colaboradores (o piloto e o navegador) trabalhando, ao mesmo tempo, em um mesmo problema.

Padronização:   A utilização de um padrão é uma prática em empresas que possuem um processo institucionalizado.

Refabricar: Esta prática recomenda tudo àquilo mal formulado sofra a nova fabricação, isto é, o artefato do projeto deve ser reescrito.

Metáfora: Formalmente, metáfora é uma figura linguística, em que há a substituição de um termo por outro, criando-se uma dualidade de significado. A metáfora é utilizada para explicar a ideia central do projeto de forma simples e objetiva. A utilização de metáforas aumenta a comunicabilidade com o cliente.

Design Simples: Desenvolva somente aquilo que foi solicitado. Não especule, a produção de especulada, na maioria das vezes, não é utilizada pelo cliente.

Jogo do Planejamento: Nas práticas ágeis as necessidades dos clientes são mapeadas em cartões de estórias. O cliente recebe um cartão, daqueles que você compra em uma livraria e nele é escrito tudo que uma determinada funcionalidade deve conter. O cliente juntamente com a equipe irá mapear o sequenciamento para o desenvolvimento das funcionalidades definidas nos cartões.

Reuniões em pé. Para agilizar o processo, todas as reuniões devem ser realizada em pé e possuírem horário de início e término. As reuniões não devem ultrapassar 30 minutos.

Após apresentar uma visão do Scrum e do XP, o texto propõe por meio de uma figura genérica a inserção das práticas XP dentro do Scrum.

figura

Perceba que as práticas do XP são grafadas em retângulos azuis, elas são inseridos no Scrum por meio das setas, por exemplo:

A metáfora pode ser aplicada na construção da Product Backlog;

As reuniões em Pé podem ser utilizadas para agilizar o Daily Scrum Meeting.

Por fim é importante salientar que a figura pode ser instanciada para qualquer tipo projeto objetivando a sua construção de forma organizada, padronizada, qualitativa e ágil.

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

Tecnologia em Análise e Desenvolvimento de Sistemas ou Bacharelado em Engenharia de Software?

Posted in Ensino de engenharia de software on August 5, 2014 by José Augusto Fabri

Vários alunos me questionam, sistematicamente, sobre as diferenças entre o Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas e o Bacharelado em Engenharia de Software.

Neste post tento enumerar rapidamente algumas.

1 – Curso de Bacharelado e Curso Superior de Tecnologia

O bacharelado, segundo o MEC (Ministério da Educação), é o curso superior que “confere ao diplomado competências em determinado campo do saber para o exercício de atividade acadêmica ou profissional”. Perceba que grifei o termo campo do saber. Esse grifo é proposital e indica que este tipo de curso irá possuir uma carga horária maior, pois o aluno irá mergulhar em todos os conteúdos de um determinado campo do conhecimento.

Os cursos superiores de tecnologia, em sua maioria, possuem 2000 horas. Além do tempo reduzido, eles têm um objeto de estudo bastante específico. Por exemplo: não há um curso tecnológico de jornalismo (campo do saber), mas é possível encontrar um de fotografia (objeto de estudo). Como a carga de conteúdo, neste tipo de curso, é menor e mais centralizada, os estudos são mais focados.

2 – Engenharia de Software ou Análise e Desenvolvimento de Sistemas

Engenharia de Software como campo de saber

Segundo Friedrich Ludwig Bauer “Engenharia de Software é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe em máquinas reais”.

A Engenharia de Software se concentra nos aspectos processuais (levantamento de requisitos, análise e projeto de sistemas, codificação, teste, implantação, manutenção, gestão de projetos, gestão de configuração e gestão da qualidade).

O termo Engenharia de Software foi criado na década de 1960 e utilizado oficialmente em 1968 na NATO Science Committee. Numa tentativa de contornar a crise do software e dar um tratamento de engenharia (mais sistemático e controlado) ao desenvolvimento de sistemas de software complexos.

Análise e Desenvolvimento de Sistemas como objeto de estudo

Perceba que o curso de Análise e Desenvolvimento de Sistemas se caracteriza como um objeto de estudo da Engenharia de Software. Neste tipo de curso teremos um aprofundamento nas atividades processuais de Modelagem de Negócio, Análise de Sistemas e Programação. As demais atividades do processo de software são encapsuladas em um grupo menor de disciplina.

3 – A diferença das matrizes curriculares e do tempo de integralização (cursos UTFPR – Campus Cornélio Procópio)

Ao analisar as matrizes curriculares dos cursos de Engenharia de Software e Tecnologia em Análise e Desenvolvimento de Sistemas é possível perceber:

  • As disciplinas ligadas algoritmos e programação de computadores são equivalentes em ambas às grades;
  • quando comparado ao curso de Análise e Desenvolvimento de Sistemas, o curso de Engenharia de Software possui um número maior de disciplinas ligadas à ideia de processo de produção  – veja os quadros grafados em azul nas grades. Dada esta diferença no número disciplina, o curso de Engenharia de Software possui uma carga horária 3250 horas, enquanto que o curso Tecnologia em Análise de Sistemas possui 2582.

4 – Qual curso é melhor?

Os dois cursos possuem um alto grau de excelência, a diferença está no tempo de formação. Para escolher você deve responder as seguintes questões:

Eu quero me aprofundar no campo do saber (engenharia de software) e ficar mais tempo na universidade?

Eu quero me aprofundar no objeto de estudo (análise e desenvolvimento de sistemas) e ficar menos tempo na universidade?

A opção pelo curso de Tecnologia em Análise e Desenvolvimento de Sistemas não inviabiliza que você possa complementar sua formação em outro momento. Para isto você pode cursar as demais disciplinas da Engenharia de Software.

José Augusto Fabri – UTFPR

O que é uma graduação? O que é uma especialização? O Que é um mestrado? O que é um Doutorado?

Posted in off topic on July 29, 2014 by José Augusto Fabri

graduacao-mestrad-doutoradoVários alunos me perguntam sobre a diferença entre graduação, especialização, mestrado e doutorado.

Vamos imaginar que a humanidade possui milhões de “partículas do conhecimento”, quando iniciamos nosso estudo no ensino fundamental e médio, caminhamos lentamente na direção de todas estas “partículas”. Este caminho é lento e tem a duração média de 12 anos.

Ao terminar o ensino médio, procuramos um curso de graduação. Neste momento, nós iremos nos aprofundarmos em um conjunto menor de “partículas” – as “partículas” da matemática. O tempo de caminhada é mais rápido, quando comparado ao efetuado na graduação.

Ao terminar a graduação, iremos nos especializar em uma área, por exemplo: Desenvolvimento de software para WEB. Um curso de especialização dura em média 360 horas e nos proporcionar aprofundarmos ainda mais em um conjunto mais restrito de “partículas” de conhecimento.

A mesma analogia apresentadas nos parágrafos anteriores também é válida para o curso de mestrado.

Por fim, no doutorado você se torna extremamente especializado em uma das “partículas do conhecimento” da humanidade e cria uma nova. Esta por sua vez, geralmente, é uma variação daquela que você se especializou (vide figura no início do post).

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

Engenharia de Software, CREA, SBC, ACM e ENADE

Posted in Ensino de engenharia de software on July 4, 2014 by José Augusto Fabri

O Conselho Regional de Engenharia e Agronomia (CREA) é uma autarquia responsável pela regulamentação das empresas e profissionais da área das engenharias clássicas, suas ramificações, como tecnólogos, técnicos industriais. É importante salientar que todo conselho regional é subordinado ao conselho federal – CONFEA.

O CONFEA surgiu em 11 de dezembro de 1933, por meio do Decreto nº 23.569, promulgado pelo presidente, Getúlio Vargas.

Atualmente, o CONFEA é regido pela Lei 5.194 de 1966, e representa também os geógrafos, geólogos, meteorologistas, tecnólogos dessas modalidades, técnicos industriais e agrícolas e suas especializações.

O objetivo do CREA e do CONFEA é:

Resguardar o interesse público e a ética no exercício das profissões das Engenharias, da Agronomia, das Geociências, das Tecnológicas e Técnicas, buscando sua valorização, através da excelência na regulamentação, organização e controle destas profissões” (fonte CREA-PR e CONFEA).

O curso de Engenharia de Software não é regulamentado pelo CREA.  É importante salientar que o referido curso é relativamente novo – a proposta pedagógica do curso é direcionada pela Association for Computer Machinery (ACM) e pelas diretrizes curriculares MEC desenvolvida em sua grande parte pela Sociedade Brasileira de Computação.

Outro fato de extrema importância, destacado neste texto, é a regulamentação da profissão na área de Informática (incluindo a Engenharia de Software).

A comunidade científica da computação vem trabalhando na regulamentação da profissão de Informática desde a década de 70.

Fruto dos debates ocorridos ao longo dos anos, nos diversos encontros de sua comunidade científica, em relação às vantagens e desvantagens de uma regulamentação da profissão de informática, a Sociedade Brasileira de Computação consolidou sua posição institucional em relação a esta questão pela formulação dos seguintes princípios, que deveriam ser observados em uma eventual regulamentação da profissão:

Exercício da profissão de Informática deve ser livre e independer de diploma ou comprovação de educação formal.

Nenhum conselho de profissão pode criar qualquer impedimento ou restrição ao princípio acima.

A área deve ser Auto-Regulada.

Os argumentos levantado junto à comunidade da SBC e que nortearam a formulação dos princípios acima estão detalhados na Justificação que acompanha o PL 1561/2003, o qual é integralmente apoiado pela Sociedade de Brasileira de Computação.

Fonte: homepage da SBC:

http://www.sbc.org.br/index.php?option=com_content&view=category&layout=blog&id=324&Itemid=964

Desconheço qualquer regulamentação para Engenharia de Software em outros países.

Outro fato que direciona inúmeros questionamentos é Exame Nacional de Desempenho dos Estudantes (ENADE) do curso Engenharia de Software. Neste ano serão avaliados os cursos de:

Arquitetura e Urbanismo; Sistema de Informação; Engenharia Civil; Engenharia Elétrica; Engenharia de Computação; Engenharia de Controle e Automação; Engenharia Mecânica; Engenharia Química; Engenharia de Alimentos; Engenharia de Produção; Engenharia Ambiental; Engenharia Florestal; Engenharia; Ciência da Computação; Ciências Biológicas; Ciências Sociais; Filosofia; Física; Geografia; História; Letras-Português; Matemática; Química; Artes Visuais; Educação Física; Letras-Português e Espanhol; Letras-Português e Inglês; Música; Pedagogia e os de Tecnologia em Análise e Desenvolvimento de Sistemas; Automação Industrial; Gestão da Produção Industrial e Redes de Computadores.

Perceba que o curso de Engenharia de Software não faz parte da lista, neste caso os formandos de 2014 estão isentos de participar do ENADE.

Por fim, em relação às questões que compõem o ENADE, tenho a plena convicção que teremos questões direcionadas a Engenharia de Software, assim como ocorre com os cursos de Licenciatura em Computação, Ciência da Computação, Engenharia da Computação e Sistemas de Informação – vide prova de 2011.

Qualquer dúvida sobre o curso por favor me escrevam.

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

Follow

Get every new post delivered to your Inbox.

Join 42 other followers