Archive for the Introdução a Engenharia de Software 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

Requisitos e projeto de software x Pentágono Wars

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

Pessoal,

No filme, aquilo que aconteceu com o tanque acontece com cerca de 2/3 dos projetos de software. Problemas na definição do escopo do projeto.

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

Iteração de projeto ou de produto?

Posted in Ensino de engenharia de software, gestão de projetos, Introdução a Engenharia de Software on October 10, 2012 by José Augusto Fabri

A iteração é uma fatia de tempo definida dentro do projeto em que a equipe de desenvolvimento entrega uma versão estável e executável do produto (em nosso caso – um software). Além da entrega da versão, a iteração prevê também que a equipe disponibilize toda a documentação de apoio, scripts de instalação ou similares, necessários para usar a referida versão. É importante salientar que o executável é demonstrável, permitindo que a equipe apresente o real progresso do projeto aos stakeholders. O objetivo da iteração é obter críticas sobre o trabalho de modo que se possa melhorar compreensão do que necessita ser feito durante a execução (do restante) do projeto. Saliento que a iteração é construída com base nos resultados da iteração precedente, e reflete a um incremento de produto. As iterações possuem um marco definido no cronograma.

Eu, particularmente, classifico uma iteração em 2 tipos.

  • Iteração de projeto (ou pré-iteração): momento em que a equipe de desenvolvimento se reúne para verificar se os artefatos gerados durante a execução do projeto estão consistentes. Por exemplo: a) os pacotes de trabalho estabelecidos na EAP estão elencados no cronograma. b) o processo para a produção foi contemplado durante o desenvolvimento dos artefatos. c) o tempo estabelecido (previsto) para o desenvolvimento do trabalho foi respeitado. d) é necessário (re)planejar alguma fase do projeto. A iteração de projeto tem como objetivo estabilizar (parcialmente ou totalmente) um conjunto de artefatos. Perceba que este tipo de iteração não prevê necessariamente a entrega de um produto executável e sim artefatos que demonstre o progresso da equipe para os stakeholders.
  • Iteração de produto: Este tipo de iteração prevê a entrega de um produto executável, juntamente com todos os artefatos de projeto gerados durante a execução do processo. O produto entregue é estável e utilizável, neste caso ele deve gerar (ou aumentar) o valor agregado para o cliente.

Quando utilizar a iteração de projeto e quando utilizar a iteração de produto?

A de projeto pode ser utilizada pela equipe de desenvolvimento para verificar se o projeto está caminhando como o planejado. É interessante que este tipo de iteração seja sistematizada a aconteça com certa freqüência.

A de produto deve ser utilizada quando novas versões executáveis do produto são estabilizadas. Ela pode acontecer em uma freqüência menor se comparada com a primeira. Importante: Este tipo de iteração também deve ser sistematizada e demarcada no cronograma de execução do projeto.

Para finalizar, questiono: Como desenvolver uma boa iteração (de projeto ou de produto)?

Abraços

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

Dica: Video-Aulas sobre Linguagem C

Posted in Ensino de engenharia de software, Introdução a Engenharia de Software on September 18, 2012 by José Augusto Fabri

Pessoal, compartilho com vocês um link que possui uma série de vídeo-aulas sobre a linguagem C. Vale a pena dar uma olhada.

Abraços

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

A capacidade de produção em um projeto de software

Posted in gestão de projetos, Introdução a Engenharia de Software, processo de produção de software on May 17, 2012 by José Augusto Fabri

Caro desenvolvedor! Você consegue responder a questão abaixo:

Qual é a sua capacidade de produção em um projeto de software?

A resposta para esta questão passa pelo estabelecimento de unidades de medida. Vamos fazer uma analogia, na engenharia civil, um operário é capaz de assentar X metros quadrados de um piso de tamanho 30 cm X 30 cm em 6 horas de trabalho. Perceba que a unidades foram estabelecidas – metros quadrados e horas de trabalho.

A unidade de medida utilizada na engenharia de software continua sendo a de pontos por função. Essa evidência pode ser constatada em uma consulta rápida ao mercado e aos grupos de usuários que trabalham com a referida unidade: ifpug e bfpug.

Dentro deste contexto a questão sobre uma especialização: Quanto tempo você leva para produzir X pontos por função?

Para mapear a resposta você deve:

a)      Implementar uma funcionalidade de um software qualquer.

b)      Marcar o tempo gasto na implmentação.

c)      Delimitar a quantidade de pontos por função da funcionalidade.

Simples assim?

Sim, simples assim!!!

Veja só a experiência que fiz um grupo de desenvolvedores (4 no total):

a)      Apresentei a eles 3 funcionalidades a serem desenvolvidas, totalizando 25 pontos por função.

b)      Solicitei a eles que implementassem as funcionalidades e marcassem o tempo (em minutos).

Resultado:

Tempo para cada desenvolvedor / linguagem utilizada

134 / vb.net

135 / c#

120 / vb.net

128 / java

Média: 130 minutos.

Com essas medidas você consegue estabelecer a capacidade produtiva de forma individual ou de uma equipe.

Faça o teste. Iniciativas como estas podem proporcionar melhorias significativas no seu perfil profissional e no seu ambiente de trabalho.

Abraços.

Fabri – fabri@utfpr.edu.br

A ótica diferenciada do documento de visão e escopo

Posted in gestão de projetos, Introdução a Engenharia de Software, processo de produção de software on March 29, 2012 by José Augusto Fabri

A atividade de gerenciamento de um projeto de software contempla o desenvolvimento do documento de escopo e visão. Neste documento serão mapeadas informações de extrema importância, destaco algumas:

  • Descrição do problema;
  • Posicionamento, perspectiva  do produto;
  • Envolvidos, ambiente e suas necessidades;
  • Demografia de mercado;
  • Recursos;
  • Restrições;
  • Desempenho.

Perceba que estas informações delimitam características do produto a ser desenvolvido dado um determinado problema – a idéia de escopo.

Determinar a visão vai muito mais além. A visão tem como objetivo oportunizar a inovação de um determinado produto, alinhavar expectativas em uma esfera global de mercado. Durante o desenvolvimento do documento, nós analistas de sistemas, nos esquecemos destas características intrínsecas à visão. Visualizamos apenas os problemas do cliente e delimitamos uma possível solução (o lado pobre da visão).

Dentro deste contexto, perceba que o documento de visão E escopo é uma conjunção de duas entidades distintas:

  • Visão: possível inovação que o produto caracterizado como software pode trazer. Valor agregado que aquele produto dispensará sobre o meu portfólio.
  • Escopo: solução para um determinado problema de um determinado cliente.

Neste contexto nem sempre a visão alinha-se com o escopo, ou seja, ela vai muito mais além das necessidades de automação das informações de uma determinada organização.

Lembre-se, uma visão pode lhe proporcionar projetos fantásticos, inicializados a partir do escopo.

Fabri – fabri@utfpr.edu.br

Follow

Get every new post delivered to your Inbox.

Join 38 other followers