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

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

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

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

Requisitos Sistêmicos e a Semiótica

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

A Semiótica tem como objetivo mapear conceitos sobre a semiose (fenômenos culturais caracterizados pelo seu significado e significante) e a concepção dos signos. Ambos os conceitos são derivados da palavra grega σημεῖον (sēmeion) – que significa signo. A teoria que alicerça a semiótica foi utilizada pela primeira vez, em 1670, como disciplina de um curso de medicina por Henry Stubbes (físico Inglês) com o objetivo de estudar a interpretação dos sinais.

A semiótica possuir uma maior abrangência quando alinhada a linguística, ciência esta que tem como objetivo estudar o sistema sígnico (de significados) da linguagem verbal.

A semiótica tem como objetivo mapear todo e qualquer sistema sígnico – Artes visuais, músicas, fotografia, cinema, culinária, vestuário, gestos, religião, ciência, etc.

Outro aspecto importante e caracteriza a semiótica por meio da interpretação dos sistemas sígnico em dois planos complementares: 1 – a forma (significante – aquilo que representa algo); 2 – o conteúdo (significado do que é indicado pelo significante).

Se analisarmos os conceitos que alicerçam a semiótica é possível estabelecer uma relação direta com a concepção dos requisitos em qualquer ambiente sistêmico, pois este ambiente, também é caracterizado pela sua forma e pelo seu conteúdo. A forma caracteriza a representatividade do sistema dentro de um, ou mais, contextos. Esta representatividade se traduz em uma série de conteúdos que podem ser materializados por um conjunto de signos pré-estabelecidos.

Vamos a um exemplo prático:

O sistema universitário possui uma representação concreta dentro dos contextos de ensino, pesquisa e extensão. Este sistema pode significar ascensão social, desenvolvimento de uma nação e melhoria contínua de uma determinada região. O referido sistema é composto de vários objetos que norteiam o seu conteúdo, destaco aqui, professores, pesquisadores, teses, dissertações, artigos científicos, projetos de pesquisa, equipamentos, laboratórios, etc. Dentro da engenharia de software esses objetos podem ser representados por um conjunto símbolos pré-estabelecidos. Os símbolos utilizados na representação devem atacar diretamente os dois planos citados – a forma (significante – aquilo que representa algo) e o conteúdo (significado do que é indicado pelo significante).

Enfim, podemos usufruir dos vários pressupostos da semiótica para explicitar requisitos implícitos, este á um assunto para um bom trabalho de pesquisa.

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

Follow

Get every new post delivered to your Inbox.

Join 44 other followers