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

Curso de astah professional na UTFPR

Posted in Introdução a Engenharia de Software on October 20, 2011 by José Augusto Fabri

Pessoal!

No dia 19 de novembro – sábado estarei ministrando um curso sobre as potencialidades do astah professional.

Tópicos a serem abordados durante o curso:

Introdução a UML com astah: Caso de uso para modelagem do negócio e do software: Diagrama; Documento de casos de uso; Customização de um documento de caso de uso. Diagrama de Seqüência; Diagrama de classes; Consistência entre os diagramas.

Demais artefatos utilizados no desenvolvimento de software: Mapas mentais; Diagrama de fluxo de dados; Diagrama de entidade e relacionamento; Diagrama de requisitos; Tabela de requisitos; Relacionando os artefatos com a UML.

Exportando e importando artefatos: Gerando arquivos rtf e pptx a partir dos mapas mentais; Gerando código em C++, C e Java; Princípios básicos da engenharia reversa.

Plugins para o astah.

Compartilherei com a comunidade todo o material desenvolvido para o curso.

As inscriçoes para o mesmo podem ser feitas no Departamento de Apoio de Projetos Tecnológicos – UTFPR campus Cornélio Procópio. Fone (43) 3520-4015.

Abraços a todos

José Augusto Fabri – Universidade Tecnológica Federal do Paraná – Campus Cornélio Procópio. fabri@utfpr.edu.br

 

 

Toda análise de sistema é estruturada

Posted in Introdução a Engenharia de Software on September 26, 2011 by José Augusto Fabri

Vários profissionais da área de engenharia de software caracterizam as metodologias de análise de sistemas em orientada a objetos ou estruturada (essencial).

Eu, particularmente, acredito que toda análise é estruturada e essencial para o desenvolvimento de qualquer software.

Para fundamentar minha colocação vou ao dicionário buscar o significado do radical da palavra estruturada, o verbo estruturar.

“Dar estrutura, organizar, dispor segunda uma ordem”.

Ao utilizar o paradigma OO organizo como os objetos irão se comportar em um determinado ambiente ou cena. Lembre-se que o objeto possui atributos (dados), que podem ou não ser persistidos (a persistência está ligada ao banco), e comportamentos (funções ou procedimentos). A relação dos objetos dentro de uma cena deve ser organizada e, na grande maioria das vezes, seguir uma ordem cronológica.

No paradigma “estruturado” a organização ocorre junto aos processos (funcionalidades) e dados.

Em ambos os paradigmas levantamos as características que irão compor um software, características estas que irão se transformar em requisitos funcionais, e estruturamos a base dados que irá dar suporte o software como um todo. Ao optar por qualquer paradigma eu sempre estruturarei alguma coisa.

Enfim, em meu ponto de vista existem dois paradigmas de análise: a orientada a objetos e a orientada a eventos.

Abraços

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

As potencialidades do astah professional uml – parte 4

Posted in Introdução a Engenharia de Software on September 14, 2011 by José Augusto Fabri

Pessoal, na última semana iniciei um tutorial básico sobre as potencialidades do astah professional uml. O primeiro post propõe o levantamento de requisitos e o mapeamento do escopo de um projeto de software por meio de mapas mentais. O segundo trabalha a customização do documento para especificação de casos de uso. O terceiro apresenta a concepção do diagrama de classes e de seqüência, a partir dos casos de uso, salientando a consistência entre ambos. Este post, parte do diagrama de classes, identifica as classes que serão persistidas no projeto e gera o diagrama de entidade e relacionamento.

figura 3
figura 3

O Tutorial

Vou partir do diagrama de classe gerado na parte 3 do tutorial (naquele post a figura em questão foi identificada como figura 3). Nele é possível perceber a presença das classes: Aluno, Secretário da Pós, Banco e Prontuário. Algumas delas são caracterizadas como classes de negócios (Secretário da Pós, Banco) e outras como classes de persistência (Aluno e Prontuário). Lembrando que as classes de persistências irão persistir (ou armazenar) dados nas tabelas. Neste caso temos duas classes que serão configuradas como tabelas (Aluno e Prontuário).

De posse das classes que serão persistidas, acesse o menu Diagram e clique na opção ER-Diagram. Selecione as

figura 1
figura 1

referidas classes na árvore de negação, arrastando-as para dentro diagrama ER, perceba que as tabelas serão geradas automaticamente. Estabeleça o relacionamento cardinal de 1 para muitos entre as tabelas Aluno e Prontuário (figura 1).

Para finalizar os post que configuram este tutorial, disponibilizo um projeto simples, porém completo. Basta abri-lo na versão professional do astah.

Abraços

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

Follow

Get every new post delivered to your Inbox.

Join 38 other followers