Arquivo

Archive for the ‘UERJ’ Category

A história de um projeto (assim como os nossos)

Foi publicado hoje na InfoQ (www.infoq.com) um post de Olivier Mallassi contando a história de um projeto que, segundo ele mesmo, não é “nem mais complexo nem mais simples” que outros.

No entanto é uma história bastante conhecida por qualquer um que já tenha passado por alguns projetos de Software (mesmo que em equipes menores que a mencionada no post).

Há entradas no texto para frases e trabalhos que gosto muito, como:

“Adding manpower to a late software project makes it later”, de Fred Brooks

“Software Engineering: An Idea Whose Time Has Come and Gone?”, de Tom De Marco onde ele fala sobre como a famosa frase “You can’t control what you can’t measure” foi mal interpretada…

O artigo é grande mas é uma excelente leitura! Recomendo!

Segue o link: http://www.infoq.com/articles/mallassi-project-story

Anúncios

Códigos de exemplo e exercícios em Java

14/04/2010 1 comentário

Fala galera!

Atualizei meu repositório no google-code (http://code.google.com/p/exercicios-java-uerj/) com os últimos projetos que trabalhamos em sala (curso de extensão em Java – UERJ/IME). Quem quiser pode fazer o check-out via svn ou download do .rar, na área de específica.

Aos que não fizeram o curso mas acompanham o blog, sintam-se a vontade para baixar, melhorar e opinar…

Grande abraço e, aos que estiveram no curso, parabéns e obrigado pela atenção!

Errando logo no início com as famosas RFP´s

14/02/2010 2 comentários

Enquanto curtia a pequena folga de carnaval (trabalharei segunda e quarta-feira – arghhhh)  parei para conferir os e-mails e li este post:

Primeiro passo para um projeto de software falhar: a RFP

A questão levantada pelo autor é bastante interessante e é uma grande realidade em diversas empresas.

– Vamos desenvolver um projeto? Então, escreveremos uma RFP, a entregaremos a algumas empresas e contrataremos a que melhor nos atender (a partir daí, “a que melhor nos atender” pode significar diversas coisas e até, simplesmente, a mais barata).

O problema é que estão negando um princípio muito importante da construção de softwares: Não sabemos o que queremos no início (vide cone da incerteza). Daí, especificamos, no início, algo que pode não ser o mais interessante no final e exigimos que seja feito exatamente daquele jeito.

Em contrapartida, o fornecedor incluirá cláusulas contratuais que bloqueiem (ou ao menos dificultem) qualquer alteração no escopo do projeto, sob pena de multas contratuais. Assim, fazem com que sejam fixados preço, prazo e escopo (logo, a única coisa que pode e vai variar será a QUALIDADE) e, o pior, geralmente não definimos o que será considerado como software de qualidade, no início.

Por exemplo, no que se refere a mudanças no escopo, imagine o impacto que a seguinte frase pode causar no sucesso de um projeto de software (falando de funcionalidades que atendem de forma eficiente e eficaz as necessidades dos usuários e não simplesmente de entregar dentro do prazo e custo definidos – aliás, entregar com prazo e custo dentro do estimado no início é o mais difícil de acontecer):

“Quaisquer alterações no escopo deverão ser apresentadas com no mínimo 30 dias de antecedência e estarão sujeitas a análise do fornecedor”.

Claro que, geralmente, estas alterações serão aceitas pelo fornecedor, desde que o cliente aceite pagar (bem) mais por isso. Afinal, já existem dezenas de documentos definindo o que será feito e tudo deverá ser alterado…

É incrível como, apesar de tanto movimento a favor de melhores práticas e métodos, ainda encontramos diversas empresas com modelos de contratação que não favorecem o sucesso dos projetos de software.

Logo de início, exige-se zilhões de entregáveis que devem ser entregues antes que qualquer linha de código tenha sido escrita. Daí, o que vemos no final são pilhas de documentos mortos desatualizados (ou raramente/precariamente atualizados) e software que não é compatível com o que foi escrito…

De qualquer maneira, alguns pontos que precisamos levantar são:

Estariam os fornecedores preparados/receptíveis para contratos ágeis?

Estariam os clientes e fornecedores preparados para compartilharem os riscos nos projetos de software ao invés de continuarem no “jogo de empurra” onde um quer deixar a culpa para o outro?

É…, sei não viu…

A[]´s e até mais.

Java EE 6: Comeando com Bean Validation

Exemplos de código e Exercícios em Java

17/12/2009 1 comentário

Como havia prometido ao pessoal do curso de extensão em Java da UERJ/IME, estou preparando alguns códigos de teste e exercícios para auxiliar no aprendizado fora das aulas.

Assim, acabo de fazer o primeiro commit deste material no GoogleCode e podem acessar através do link: http://code.google.com/p/exercicios-java-uerj/.

Os exemplos foram feitos utilizando o Eclipse. Sigam os passos abaixo para baixarem e explorarem os exemplos:

  1. Faça o download do arquivo ExerciciosJavaUerj.rar através do link acima (ou clicando aqui);
  2. Descompacte o arquivo na workspace do Eclipse em utilização;
  3. No Eclipse, acesse File -> Import -> Existing Projects into Workspace e clique em Next;
  4. Clique em “Browse”, selecione o diretório o arquivo foi descompactado e clique em “Finish”;
  5. Pronto! A esta altura o projeto já deve estar aparecendo na lista de projetos do Eclipse.

Uma outra dica de fonte de estudo é o site http://www.java2s.com/. Aqui podem ser encontrados diversos exemplos de código (disponível para download) para as mais variadas coisas. Vale a pena dar uma olhada…

Qualquer dúvida e/ou problemas, me avisem. Boa sorte e bons estudos!

UML como documentação?

01/12/2009 6 comentários

Uma coisa que muitos acabam confundindo é a real função da Unified Modeling Language – UML: UML para documentação ou para entendimento de um problema?

O Craig Larman fala disso no livro “Utilizando UML e Padrões” e cita que diversas pessoas perdem muito tempo modelando com UML no sentido de documentar e atrasam a codificação. Quando vão ver, tudo aquilo que foi modelado em diversos diagramas “bonitos” e que demoram bastante tempo ($$$) para serem produzidos não são soluções que poderiam ser implementadas na realidade.

UML é para modelagem, visando que as pessoas entendam o problema e a solução proposta. Uma vez que a informação foi passada, se quiser registrar o que foi desenhado, tire uma foto e guarde. Pronto!

Exemplo de modelo criado durante reunião com cliente

O Vinicus Teles, no seu livro sobre XP, fala, inclusive, que em sua experiência dificilmente precisou dessas fotos.

Em alguns casos, os modelos são realmente importantes e precisam ser registrados (como modelos de domínio e diagramas de atividade modelando o fluxo do processo, por exemplo). Nestes casos, após modelar, transfira para uma ferramenta case e deixe arquivado (o modelo acima, por exemplo, foi inserido em um documento de visão, criado no início do projeto).

Mas é bom lembrar que de nada adianta se este modelo não for atualizado ao longo do tempo. Documentação desatualizada é pior que não ter documentação!

Agile utiliza UML?

Métodos ágeis podem, sim, utilizar UML. Eu inclusive utilizo bastante, porém temos que ter em mente que o que é importante é saber bastante sobre análise e projeto orientado a objetos, padrões, modelagem e não apenas saber UML.

Os métodos ágeis usam esse tipo de modelagem (visando entendimento de um problema e criação da solução), seja com UML ou o quer que seja. Uma boa referência são os artigos do Scott Ambler (em Agile Modeling) sobre o assunto.

Modele para entender, em um quadro branco, em grupo (e junto com o cliente quando quiser descobrir os conceitos do negócio e modelá-los no sistema), tire foto ou deixe isso fixado na parede da sala de projeto e corra para desenvolver o que modelou, pois é isso que vai dizer se o que desenhou está correto…

Com relação a o que é feito antes de por o software para rodar, devo dizer que não acredito nessa idéia de esperar até que todo o software esteja pronto e documentado com belos diagramas para aí sim validar e colocar em produção! Métodos ágeis trabalham com iterações e o software vai sendo produzido aos poucos (incrementalmente) e a cada novo incremento, temos uma versão funcional do software que já pode ser colocada em produção, gerando valor para o cliente.

Uma grande fase de design ou de modelagem no início, o famoso Big Design Up Front (BDUF) ou Big Modeling Up Front (BMUF), retardando o desenvolvimento, não vai garantir qualidade ao seu projeto do ponto de vista do design. Para isso, existem diversas práticas que podem ser utilizadas durante o processo de desenvolvimento, como programação em par, TDD, etc…

Bom, IMHO, é isso…

PS.: Após escrever e publicar este post, cheguei a esse vídeo do Vinicius: http://vimeo.com/1450383. Sem tirar nenhuma vírgula, é isso!

Tags:, ,

Java SDK + Eclipse + JBoss Tools + Tomcat (instalação e configuração inicial)

30/11/2009 2 comentários

A instalação e configuração inicial do Eclipse já me causou bastante dor de cabeça, especialmente por achar que uma boa IDE não nos deve fazer perder tempo com coisas relativas a configuração (até porque a intenção é ajudar na produtividade).  Essa é um dos motivos de gostar do NetBeans, mas como em alguns casos precisamos de algo mais “leve”, vamos ao Eclipse!

Tentarei ajudar nesta etapa inicial de instalação do Java SDK, configuração inicial do Eclipse (com alguns plugins comuns) e Tomcat6.

Leia mais…

Tags:,