A intenção desse post é convidá-los para a demonstração prática e a banca do nosso projeto de formatura e para conhecer a FEBRACEv ao vivo.

A demonstração prática do projeto de formatura será segunda, dia 14/12, a tarde (das 13h30 às 16h30) na sala C1-49 do prédio da Engenharia Elétrica da Escola Politécnica da USP. A banca será terça, dia 15/12, de manhã (às 9h15) na sala B2-08, também na Elétrica.

Veja o pôster e o press release do projeto.

Esperamos vocês lá!

Como outras metodologias ágeis, o XP se opõe a diversas premissas assumidas pelas metodologias tradicionais de engenharia de software. Uma dessas premissas é a possibilidade de prever todos os passos necessários para o desenvolvimento de um sistema, por um detalhado levantamento de características do problema a ser resolvido e da solução a ser desenvolvida. O XP assume a presença constante das mudanças durante o processo de desenvolvimento e propõe uma série de práticas para lidar com elas.

A programação extrema é descrita por meio de seus valores, princípios e práticas. As práticas são uma série de técnicas a serem aplicadas no dia-a-dia de trabalho da equipe. Os valores são a noção do que é certo e do que é errado no relacionamento da equipe com o trabalho e entre si. Os valores fundamentam as práticas. Porém, os valores do XP são universais e independem do contexto do desenvolvimento de software, estando assim muito distante das práticas. A ponte entre os valores e as práticas são os princípios, que trazem orientações para um contexto específico.

Uma equipe usando XP possui quatro papéis principais:

• Programadores: foco central da metodologia, sem hierarquia.
• Coach: pessoa com mais experiência no time, responsável por lembrar os outros das práticas e dos valores de XP. O coach não é necessariamente o melhor programador da equipe, mas deve ser o que mais entende da metodologia XP.
• Tracker: pessoa responsável por coletar dados e informações, e apresentar para a equipe em algum formato que possa ser facilmente entendido (por exemplo usando gráficos). O intuito é mostrar o andamento do projeto e ajudar a tomar decisões de implementação, arquitetura e design. O próprio coach pode fazer esse papel ou o time escolhe quem o exercerá.
• Cliente: em XP o cliente faz parte da equipe. Deve estar sempre presente e pronto para responder às dúvidas dos programadores.

Valores
O primeiro dos valores do XP é a Comunicação, por pressupor que a maioria dos problemas de um projeto ocorrem por dificuldades nesse aspecto. A comunicação constante e eficaz entre os membros da equipe permeia todo processo de desenvolvimento, e é ressaltado em diversas das práticas do XP.

Outro princípio é a Simplicidade, que leva a equipe a buscar sempre as soluções mais simples a um dado problema, sem tentar otimizações precoces ou a a tentativa de resolução de um problema futuro.

Como não há uma direção pré-definida a ser seguida, a equipe de XP precisa constantemente saber onde se encontra para poder determinar seus próximos passos. O valor que orienta a equipe à rápida resposta sobre as ações realizadas é o Feedback.

Coragem é a ação efetiva frente à insegurança, para a tomada de decisões necessárias ao projeto.

O último valor é o Respeito. Os membros da equipe devem se importar uns com os outros e com as ações realizadas.

Princípios

Os princípios definidos na segunda edição do livro Extreme Programming Explained do Kent Bech são as seguintes:

• Humanidade: O software é desenvolvido por pessoas. As necessidades pessoais dos membros da equipe devem ser levadas em consideração no processo de desenvolvimento.
• Economia: A produção de software não está à parte do processo econômico, e seus aspectos devem ser considerados.
• Benefício mútuo: Qualquer atividade deve beneficiar todas as pessoas envolvidas (desenvolvedores e clientes). Decisões emergenciais, que custem a uma pessoa, representam uma perda ao projeto como um todo.
• Auto semelhança: A estrutura de uma solução deve ser utilizada em outros contextos, mesmo que em diferentes escalas.
• Aperfeiçoamento: Deve-se sempre buscar a realização do melhor trabalho possível no dia de hoje.
• Diversidade: As equipes devem ser formadas por pessoas com diferentes perfis. Os conflitos que possam surgir dessa escolha são compensados pelo benefício das múltiplas visões sobre um problema.
• Reflexão: Não é suficiente realizar tarefas, é necessário constantemente revisitar o trabalho feito e refletir sobre as decisões tomadas, analisando as razões dos sucessos e das falhas.
• Fluxo: O fluxo é a realização simultânea de várias etapas do processo de desenvolvimento, ao invés de separar as fases e trabalhá-las isoladamente.
• Oportunidade: Problemas devem ser vistos como oportunidades de mudança.
• Redundância: Normalmente vista como desperdício, a redundância é o melhor caminho para lidar com as falhas, e deve ser empregada em diversos contextos (múltipla resolução de um problema, programação pareada, etc.).
• Falha: Quando não se sabe a maneira de resolver um problema, deve-se implementar uma alternativa que falhe e aprender com ela. As falhas não são um desperdício, e sim conhecimento.
• Qualidade: Qualidade não deve ser vista como uma variável de controle, negociável, e deve ser sempre buscada.
• Pequenos passos: Ao dar grandes passos, leva-se muito tempo para realizá-los e, caso tenham sido dados na direção errada, é mais difícil voltar atrás. Agindo dessa maneira, é frequente o temor da necessidade de mudanças. Pequenos passos são uma postura mais adequada em processos complexos.
• Aceitação de responsabilidade: A responsabilidade não deve ser designada, deve ser aceita.

Uma figura que é resume bem os valores, os princípios e as práticas está mostrada abaixo.

Ela disse que basicamente existem duas formas de fazer um estudo de usabilidade. Uma é fazendo a aplicação de heurísticas e a outra é fazendo testes com usuários. No caso de aplicação de heurísticas, existe o que chamam de Design Patterns, que é um conceito de arquitetura. Nesse caso, pattern não possui o mesmo sentido de standard (padrão), mas sim de “estampa”, coisas que se repetem com frequência.

A prof Lucia indicou vários sites sobre o assunto, os quais compartilhamos com vocês.

A grande pesquisadora de patterns é a Jenifer Tidwell e que ela tem vários matérias disponíveis na web:
http://jtidwell.net/ (site pessoal)
http://designinginterfaces.com/ (site do livro dela)
http://www.time-tripper.com/uipatterns/ (site com os patterns dela)
http://www.mit.edu/~jtidwell/interaction_patterns.html (site com uma parte do conteúdo do livro dela)

Outro site legal que tem vários exemplos de patterns é o Quince: http://quince.infragistics.com/UX-Design-Patterns.aspx

Outra pessoa que mexe com isso é o Van Welie e o no site dele tem vários patterns disponíveis: http://www.welie.com/patterns/index.php

Bom, essas são as dicas de hoje!

Mas o que é usabilidade?

Segundo Nielsen, usabilidade é um atributo qualitativo que avalia o quanto fácil é uma interface de usuário para ser usada. A palavra “usabilidade” também se refere ao método de melhorar a facilidade de uso durante o processo de design.

Usabilidade é definida por cinco componentes qualitativos:

• Aprendizado: Quão fácil é para usuários realizar tarefas básicas na primeira vez que eles defrontam-se com o design?
• Eficiência: Uma vez que os usuários aprenderam o design, quão rápido eles podem realizar as tarefas?
• Memorização: Quando os usuários retornam para o design depois de um período sem usá-lo, quão fácil eles podem restabelecer a proficiência?
• Erros: Quantos erros os usuários cometem, qual a gravidade desses erros, e quão fácil eles recuperam dos erros?
• Satisfação: Quão é agradável de usar o design?

Há muitos outros atributos qualitativos importantes. Um dos mais importantes é a utilidade, que remete para a funcionalidade do design: Será que o design permite aos usuários fazer o que eles necessitam? Usabilidade e utilidade são igualmente importantes: pouco importa que algo é fácil de fazer, se não é o que você quer fazer.

E porque a usabilidade é importante na web?

A usabilidade é uma condição necessária para se “sobreviver” na web. Se o usuário achar difícil usar seu site, ele simplesmente não usará mais e irá procurar outro que ofereça a mesma coisa. Se a home do site não for clara em transmitir o que o site faz e para que serve, o usuário não entenderá e irá embora. Se os usuários se sentirem perdidos no site, eles simplesmente sairão dele. Se as informações do site forem difíceis de ler ou de entender, outro motivo que eles o abandonarão. Enfim, se o usuário encontrar dificuldades em usar seu site, ele simplesmente o abandonará sem maiores constrangimentos. Isso mostra a importância do design na retenção de usuários no seu site.

Não é a toa que essa é uma preocupação que temos na construção no nosso sistema. Afinal, queremos reter e atrair usuários para a rede social e isso será decisivo para o sucesso e o cumprimento de um dos nossos principais objetivos que é o de fomentar e estimular os jovens a discutir e fazer ciência.

Como a parte de programação do projeto está praticamente terminada no FEBRACEv, a partir de agora nos focaremos em melhorar a usabilidade dele.

Continuaremos postando aqui as novidades do projeto.

O Django é um framework para desenvolvimento web. A linguagem de programação usada com esse framework é o Python.

O Python é uma linguagem de programação de alto nível, interpretada, imperativa, orientada a objetos, de tipagem dinâmica e forte. Foi lançada por Guido van Rossum em 1991. Atualmente possui um modelo de desenvolvimento comunitário, aberto e gerenciado pela organização sem fins lucrativos Python Software Foundation.

Uma das principais características do Python é ser uma linguagem de fácil leitura e entendimento. Para a separação de blocos de código, a linguagem usa espaços em branco e indentação ao invés de delimitadores visuais como chaves (C, Java) ou palavras (BASIC, Fortran, Pascal). Diferente de linguagens com delimitadores visuais de blocos, em Python a indentação é obrigatória e não só uma boa prática de programação.

O Django usa uma arquitetura conhecida como MTV, Model-Template-View, que nada mais é que uma variação do modelo MVC (Model, View, Controller), arquitetura na qual separam-se as regras de negócios (Controller), os dados e métodos de acessos aos mesmos (Model) e as regras de apresentação (View). Essa separação tem por objetivo o desacoplamento da lógica entre essas camadas, de maneira que cada uma delas pode ser modificada sem alterar o funcionamento das outras. Essa arquitetura também facilita a modularidade do sistema.

No caso da arquitetura MTV, o framework Django é o que faz as vezes de controlador da arquitetura MVC. Sendo assim, na arquitetura MTV, o Controller não é responsável pela lógica do negócio e sim pelo funcionamento do sistema. Além de models, views e templates, no Django há também o URL dispatcher, middlewares e handlers e são estes que são encarados como Controller.

O URL dispatcher é o componente responsável em analisar os endereços requisitados pelo cliente e redirecionar essa requisição para a aplicação correta. Já o middleware é um conjunto de componentes que realizam pré e pós filtragens nas requisições, o que possibilita funcionalidade como internacionalização de uma aplicação e gerenciamento de sessões autenticadas.

No Model, são escritas as classes que designarão as tabelas no banco de dados. A manipulação dessas tabelas ocorre através do ORM (mapeamento objeto relacional) e, por isso, não é necessária a escrita de querys em SQL para a persistência dos dados. Uma outra vantagem é baixa preocupação com qual sistema gerenciador de banco de dados será usado, uma vez que o ORM suporta vários sistemas. Há suporte atualmente para MySQL, PostgreSQL e SQLite.

Nessa camada também devem ser escritas as regras de acesso às informações, regras para os eventos de cada modelo (métodos save, delete, etc.), e também regras genéricas para eventos que podem ser usados em mais de um modelo (sinais). Toda a lógica de manipulação da informação de uma aplicação estará em seu modelo.

Na camada View, são escritas as regras de negócio e as regras de apresentação do sistema.

Na camada Template é definida a forma de apresentação dos dados que a View envia. Com o sistema de templates do Django é possível criar heranças, ou seja, um template base contendo a estrutura básica do sistema e templates específicos que herdam as características deste template base e atribuem/criam suas próprias características.

Com o uso do framework Django, um projeto é um conjunto de aplicações. Uma aplicação é uma determinada funcionalidade que compõe um projeto. Por causa disso, há a idéia de aplicações plugáveis no Django que é uma aplicação que pode ser usada em mais de um projeto com nenhuma ou quase nenhuma alteração de código. Isso quer dizer que a aplicação deve ter seus próprios modelos, suas próprias views, seus próprios templates e encapsular o máximo possível de código que não se enquadre em um desses elementos.

Para quem deseja aprender Django uma boa referência é o Django Book, que é um livro disponível na web, escrito pelo Bennet, que é um desenvolvedor bastante conceituado em Django.

Outra referência bastante completa é a própria documentação disponível no site do django (http://docs.djangoproject.com/en/dev/).

Até mais!

O que muito ajudou para que isso fosse possível foi o uso de modelos reusáveis em Django.  Existe um site que agrega muitos modelos reusáveis de boa qualidade que é o Django Pluggables.

A vantagem de usar módulos reusáveis é não ter que implementar novamente funcionalidades muito comuns em diversos aplicativos. Por exemplo, muitos sites possuem um fórum para discussão e é muito interessante que isso seja um módulo reusável que pode ser usado nos diversos sites sem a necessidade de cada um reprogramar isso.

No caso do FEBRACEv, os modelos reusáveis são todos de código-aberto. A vantagem dos módulos serem de código-fonte aberto é a possibilidade de alteração deles para que se adequem para o nosso caso. Apesar dos modelos possuírem funcionalidades “padrão”, algumas vezes é necessário fazer alguma adaptação para se integrar ao aplicativo em específico. Por exemplo, no nosso caso temos uma galeria de fotos, porém foi necessário fazer algumas alterações no código-fonte para que cada projeto pudesse ter a sua própria galeria e só os participantes de um determinado projeto pudessem alterá-la.

Os módulos reusáveis que usamos no FEBRACEv foram:

• Django Profiles: módulo para a criação, edição e gerenciamento de perfis para rede sociais. O autor desse módulo é Bennet, que é um dos desenvolvedores mais conceitados em Django. Está disponível no Bit Bucket;
• Django Photologue: módulo para gerenciamento de galerias de fotos. É bem completo e pelo que pudermos perceber e ler por aí é o módulo mais completo em Django para essa funcionalidade. Está disponível no Google Code;
• Django Basic Blog: módulo para gerenciamento de blog. Ele é bem simples e é um sistema para um blog só. Está disponível no Google Code;
• Django Tagging: módulo que permite associar tags com algum conteúdo. Está disponível no Google Code;
• Django Registration: módulo para cadastro de novo usuário e para login em um sistema. Está disponível no Bit Bucket e
• Django Messages: módulo para envio de mensagens diretas entre dois usuários. Possui uma caixa de entrada, uma caixa de saída e lixeira onde os usuários podem verificar suas mensagens e respondê-las. Está disponível no Google Code.

A grande maioria dos módulos reusáveis já possuem templates bem simples, o que faz com que eles sejam bem simples de “plugar” na sua aplicação. Na grande maioria dos casos, basta você alterar o settings.py da sua aplicação, adicionando na lista INSTALLED_APPS o novo módulo e alterar o urls.py para filtrar as urls para redirecionar para a pasta certa.

É isso!

Nesse meio tempo, ocorreram muitas coisas. Houve a banca do projeto de formatura no PSI no fim de junho e tivemos que correr para implementar mais funcionalidades para apresentação. Também tivemos que correr para escrever a monografia (ou pelo menos uma primeira versão dela para entregar no PSI). No final, tudo deu certo! Apresentamos no PSI e os professores gostaram muito do projeto. E o Leandro se formou, pois só faltava essa matéria para ele…

Bom, depois dessa correria, não páramos não. Ainda temos que apresentar o projeto em dezembro no PCS, mas claro que uma versão mais refinada da que foi apresentada no PSI. E o trabalho prossegue!

Vamos fazer mais alguns posts em breve contando mais uma coisinhas do projeto!

Normalmente disciplinas de projeto de formatura baseiam suas avaliações fortemente no acompanhamento das documentações desenvolvidas pelos grupos. O problema é que isso é incompatível com o uso das metodologias agéis de desenvolvimento de software. Essas metodologias preferem obter um software funcionando a ter uma documentação extensa sobre o sistema.

Nesse mês, teríamos que entregar a especificação do nosso projeto para a avaliação final da disciplina. Nosso problema era como fazer uma “especificação ágil”? Coloco entre aspas porque qualquer agilista me mataria ao me ouvir falar em especificação de software…

Nossa primeira atitude foi procurar na bibliografia existente sobre o assunto alguma resposta para esse grande dilema. Achamos bons artigos com relatos sobre o uso de metodologias agéis em projetos de formatura. Porém, apesar de úteis para nosso projeto, não resolviam a nossa questão inicial, pois eram relatos de professores que decidiram introduzir o XP nas disciplinas de projeto de formatura. Inclusive, em um desses artigos, o autor comenta que teve que alterar o critério de avaliação da disciplina de modo a avaliar coerentemente o andamento dos projetos, já que não havia mais uma documentação para ser avaliada.

O problema no nosso caso é que não são os professores que querem introduzir o XP no projeto de formatura e sim os alunos de um projeto em específico que querem usá-lo, e que sabem que o critério de avaliação leva em conta principalmente a documentação produzida.

Já que a bibliografia não nos ajudou a resolver nosso problema, então decidimos apelar para algum professor especialista na área. Porém, na Escola Politécnica não há nenhum professor da área de Engenharia de Software que trabalhe com metodologias agéis, todos trabalham com RUP. Enfim, entramos em contato com o professor Fabio Kon do IME que é especialista na área.

Foi relatado que eles já haviam tentado em uma disciplina de Engenharia de Software (na qual estavam usando XP como metodologia de desenvolvimento) gerar também documentação e o resultado foi um fracasso.  O que eles fizeram foi criar um adaptador entre o professor e o time. O professor explicava o que queria (diagramas, relatórios e etc) e o time transforma em cartões e tentava não só gerar documentos, mas também gerar código junto. Isso não deu certo, porque no final, a sequência de coisas era muito mais parecida com cascata do que com ágil, e para manter os documentos atualizados a sobrecarga era grande.

Percebemos que estávamos tentando unir dois mundos que pareciam não se conversar muito bem. Como não achamos respostas na bibliografia e nem com especialistas percebemos que nós mesmos teríamos que definir o que seria o nosso documento de especificação de acordo com o “bom senso”.

Tínhamos duas alternativas. A primeira era usar a documentação usada pelo RUP com seu levantamento de requisitos, modelo de casos de uso, modelo de classes e de seqüência, modelo de banco de dados, arquitetura de software e plano de testes. Se usássemos essa documentação estaríamos fadados aos problemas que o professor do IME nos havia dito, sendo que um de nossos principais objetivos do projeto de formatura não seria atingido (explorar o XP para o desenvolvimento de um projeto de formatura).

A segunda alternativa era criar uma especificação mais leve e geral que não nos amarrasse e em que fosse possível que os requisitos mudassem sem que criasse uma grande sobrecarga para alterar toda a documentação feita. E foi isso que decidimos fazer. A nossa especificação foi definida como contendo as seguintes seções:

• Compilação das histórias iniciais levantadas através do jogo do planejamento com o cliente;
• Definição da 1a. iteração do sistema (quais dessas histórias seriam as primeiras a serem implementadas);
• Tecnologias a serem utilizadas e
• Arquitetura do software (mostrando seus módulos principais).

Com essa especificação a idéia não é fechar os requisitos para que estes não mudem mais, mas sim dar uma idéia melhor do que é a proposta do projeto. Por isso, colocamos as histórias iniciais, o que não quer dizer que não haja outras histórias que possam ser descobertas ao longo da implementação.

Acho até que resolvemos bem o dilema em que nos encontrávamos… Se alguém quiser ver a “especificação de software”, basta acessar aqui.

• O objeto do Projeto de Formatura
• As possíveis automações que possam ser associadas a esse projeto
• Os benefícios decorrentes da aplicação da automação escolhida
• A arquitetura do sistema de automação considerado
• A infra-estrutura de energia e de telecomunicações demandada pelo projeto
• A confiabilidade do resultado do projeto
• A qualificação de mão de obra para a elaboração, operação e manutenção
• Os riscos decorrentes da utilização do resultado do projeto
• Os aspectos éticos que tenham que ser observados
• As interferências com o meio ambiente que possam decorrer
• Os impactos sociais, positivos e negativos, que possam decorrer
• A disposição final dos resíduos após a vida útil do resultado do projeto
• Os possíveis melhoramentos que possam ser adicionados
• Os aspectos de inovação consideráveis
• A viabilidade da transformação do resultado num produto industrializado
• A abrangência de volume de aplicação estimado do resultado
• Os principais investimentos necessários para a industrialização
• Conclusão

Achei muito interessante o trabalho, pois, além de explorar os conceitos de automação, explorou outros aspectos muito importantes que dificilmente são pensados ao se fazer um projeto qualquer. Tenho certeza que a reflexão a cerca desses assuntos enriqueceu em muito o trabalho de formatura e pretendo incorporar alguns desses assuntos na monografia em si.

Para quem está fazendo algum projeto sugiro fazer o exercício de pensar nesses tópicos, sendo que enfatizo pensar nos riscos decorrentes da utilização do projeto, os aspectos éticos envolvidos, as interferências com o meio ambiente, os impactos sociais positivos e negativos, a disposição final dos resíduos após a vida útil do projeto, aspectos de inovação e a viabilidade do projeto. Com certeza, isso enriquecerá seu projeto, além de permitir uma visão mais ampla e sistêmica.

Para quem quiser ler o trabalho escrito produzido sobre o projeto de formatura a cerca desses tópicos, clique aqui.

A retrospectiva é dividida em 3 momentos: tarefas realizadas, avaliação dos pontos positivos e negativos e idéias surgidas.

No período entre a 1ª e a 2ª retrospectiva, foram realizadas as seguintes atividades:

• questionário de perfil de uso: devido a algumas sugestões recebidas da equipe da FEBRACE e de outras pessoas com experiência em levantamento de dados com usuários foram feitos melhoramentos no questionário;
• aplicação do questionário: a FEBRACE ocorreu nos dias 17, 18 e 19 de março e durante esse período foram aplicados questionários para alunos e professores participantes, além de visitantes da feira. Ainda não houve tempo para a compilação dos dados dos questionários. Foram recolhidos 520 questionários;
• automação do processamento de dados coletados com os questionários: o método escolhido para a aplicação do questionário foi em papel. Porém, com o objetivo de facilitar a compilação desses dados será usada a ferramenta Lime Survey. Assim, os dados de cada questionário podem ser inseridos nessa ferramenta de forma mais rápida e prática, e, pelo fato de ser online, o trabalho poder ser mais facilmente entre os membros do grupo. Além disso, a ferramenta já faz gráficos e cálculos de desvio padrão;
• decisão das tecnologias a serem utilizadas no projeto: o projeto será desenvolvido em plataforma Linux, usando o servidor web Apache. A linguagem escolhida foi Python, com o uso do framework Django para a construção de aplicações web. Serão usadas ferramentas para teste automatizado de código como o PyUnit, o Twil e o Selenium. Uma possibilidade levantada pelo grupo é a do uso de componentes reusáveis do Django Plugables. O banco de dados a ser utilizado ainda está em aberto, sendo que para se decidir serão testados os desempenhos dos bancos de dados MySQL e PostgreSQL.

A 3ª apresentação de acompanhamento foi feita hoje e foi um sucesso!!! hehehe