Gestão, Ferramentas, Sistemas e Ambientes - Dúvidas e Discussão de Programação - Portugal-a-Programar
Gestão, Ferramentas, Sistemas e Ambientes
Por M6, 9 de Maio de 2006 em Dúvidas e Discussão de Programação
Participo à pouco tempo neste fórum mas creio que actualmente a maioria dos seus utilizadores têm pouca experiencia, a julgar pelos muitos tópicos de perguntas de iniciados e a pedir ajuda/orientação sobre o vasto mundo da programação.
Tendo já alguns anos disto "no pelo", resolvi partilhar, em particular com os mais recentes neste mundo, algum conhecimento e orientação. Convido todos quantos têm criticas construtivas e ideias a partilhá-las aqui.
Ao longo de cada tópico vou colocar links com informação relacionada: sites, livros, ferramentas, etc.. A informação relacionada mostra o que de melhor existe no tópico e com o qual tomei conhecimento. Alguma informção é de acesso livre outra é comercial e como tal, paga.
Antes de começar, devo referir que sou pragmático e algumas das coisas que vou aqui dizer não são "politicamente correctas", mas são reais e fruto da minha experiência. Vou usar os termos que são standards de facto na indústria, pelo que quem tiver dúvidas sobre o significado de algum termo, diga.
Todas as questões, exclarecimentos e críticas que tenham devem ser enviadas directamente para mim através do sistema de mensagens, sob pena dos posts aqui colocados serem eliminados.
Dado o conjunto de temas que pretendo abordar aqui e a limitação funcional dos 20000 caracteres por post, irei dividir os temas por posts.
Os assuntos que pretendo abordar são:
- Análise e Desenho
- Desenvolvimento e Testes Unitários
Programar é visto por imensas pessoas como uma arte mágica em que uma pessoa se senta em frente a um computador "matraqueia" o teclado, dando ordens aos anõezinhos mágicos que vivem dentro da caixa onde se metem os CDs , e no final sai um programeca que faz mais ou menos aquilo que se quer. Esta visão, perdoem-me a redundância, além de totalmente errada, não podia estar mais longe da verdade.
Ninguém programa só por programar, fazendo linhas de código sem qualquer nexo.
Um programa existe como sendo a solução para um problema e está contextualizado num projecto. Essa contextualização existe, grosso modo, da seguinte forma:
- antes do programa: define-se o problema, define-se a solução, especificam-se as regras;
- durante o programa: implementam-se as regras, documenta-se o código;
- depois do programa: suporta-se o programa;
Assim, antes de se programar uma linha de código que seja, existe todo um conjunto de tarefas que têm de ser cumpridas de forma a que a programação do sistema seja correcta, completa e solucione o problema, ou responda à necessidade, que originou o programa.
Depois de se terminar o programa, há ainda um conjunto de tarefas que é necessário efectuar, como por exemplo gerar a documentação técnica.
Tipicamente, a acção de programar é apenas uma tarefa no meio de um imenso projecto. Tudo o que está antes da programação define um conjunto de regras e procedimentos a que o programa deve obedecer, influenciando-o directamente. Tudo o que está após a programação acenta no programa e tem de estar coerente com este, de forma a que o programa seja efectivamente útil a quem o usa, e não seja uma dor de cabeça a quem o suporta.
Do que eu estou aqui a falar é do método, abordagem, ou processo, usado no desenvolvimento do projecto em que o programa se insere. Este modelo é tipicamente em cascata, em que as várias partes do projecto se encadeiam sequenciamente, ou em espiral, onde ocorrem várias passagens pelas várias partes do projecto até este terminar. Isto é o que podem aprender nos livros. No mundo real, o sistema em cascata raramente funciona correctamente e o modelo em espiral é usado de forma "leviana", não passando por todas as fazes em cada iteração. Um modelo mais recente do que este, que se aplica a equipas pequenas até 10 pessoas, é o Extreme Programming, conhecido e denominado XP. Neste modelo existem ciclos pequenos e rápidos de construção de funcionalidades até o projecto estar concluído.
Feito o contexto da programação, passemos à fase inicial onde se define o que o programa deve, ou não, fazer: os requisitos.
Extreme Programming Explained: Embrace Change, livro de um dos "pais" do XP, Kent Beck.
What is Extreme Programming?, site sobre o método XP, útil para quem quer aprender.
Extreme Programming, definição de XP.
- Cascata (Waterfall): Waterfall model, definição do modelo.
- Espiral (Spiral): Spiral model, definião do modelo.
Definido de forma lata, os requisitos definem as regras a que o programa deve respeitar. Nesta fase define-se, de forma clara, tudo o que o programa deve implementar, mas não se fazem quaisquer definições, nem restrições, sobre como tal vai ser abordado. Um documento de requisitos deve responder aos seguintes pontos:
Funcionalidade. O que deve fazer o software?
Interfaces externas. Como interage o software com as pessoas, com o hardware do sistema, com outro hardware,
e com outro software?
Performance. Qual é a velocidade, disponibilidade, tempo de resposta, tempo de recuperação das várias funções
do software, etc.?
Atributos. Quais as considerações relativas à portabilidade, correcção, mantenabilidade, segurança, etc.?
Restrições de desenho impostas numa implementação. Existem exigências padrão, linguagem de
implementação, políticas para integridade da base de dados, limites de recursos, ambientes operacionais, etc.?
Este documento é a "Bíblia" do projecto: um requisito ou está escrito neste documento ou não existe.
Muitas vezes, para agradar aos clientes, à gestão ou esconder uma falha no levantamento de requisitos, o programador é confrontado com uma enorme pressão para implementar "mais uma coisinha", sem, obviamente, aumentar o tempo nem o custo do projecto. É este documento que dita se o programador implementa, ou não, essa tal "coisinha": se não está no documento então não vai ser implementada.
Quando é necessário efectuar uma alteração, então é necessário recorrer a mecanismos próprios, como por exemplo, change requests. Estes documentos efectuam um pedido de alteração, que tem de ser avaliado em diversos pontos, como por exemplo, análise de impactos. Se o cliente estiver disposto a pagar pela alteração, então esse change request, tipicamente, dá origem a um novo caderno de requisitos.
Uma vez fechados os requisitos, os mesmo só podem ser alterados através de change requests e o projecto segue para uma nova fase: análise e desenho.
O standard 830 da IEEE é uma recomendação prática para escrever especificações de requisitos de software, descrevendo o
conteúdo e as qualidades de um bom documento de especificações e apresentando diversos exemplos.
IEEE, site oficial.
IEEE, artigos para download.
IEE 830, traduzido em português.
Practical Software Requirements: Manual of Content and Style, uma leitura aconselhada neste tópico.
Borland Caliber, ferramenta de gestão de requisitos que suporta o standard IEEE 830.
A fase de análise e desenho consiste na definição funcional do sistema e na escolha da sua arquitectura. Muitas vezes é necessário partir de uma base já instalada, usando uma determinada plataforma ou uma base de dados já existente. Esta realidade restringe as escolhas efectuadas e o sistema tem de se adaptar a estas exigências.
É nesta fase que se define os use cases, modelo de dados, os módulos do sistema, as funcionalidades, as interfaces gráficas, as mensagens de erro, etc. que respondem aos requisitos definidos.
Uma vez feita a análise e definido o desenho, qualquer alteração só pode ser efectuada a partir de um change request. Também aqui o programador sofre pressões para alterar a cor daquele botão ou o texto de uma determinada mensagem. Também aqui o programador deve salvaguardar a correcta implementação do que está definido. É necessário ter em mente que uma alteração pode colocar em risco todo o projecto, uma vez que pode ter impactos graves no mesmo. No entanto, dependendo da alteração pedida, o bom senso deve imperar, e a alteração da cor de uma mensagem de erro de vermelho claro para vermelho escuro não coloca o o bom funcionamento do sistema. Mas é bom ter em atenção de que a decisão tomada é da responsabilidade do programador, que pode ter de arcar com as consequências dessa decisão.
Tipicamente é nesta altura que a equipa se separa e os técnicos avançam para a implementação e os funcionais avançam para a definição dos cadernos de testes funcionais.
Uma vez definido o que se vai implementar e como, passamos à fase seguinte: a implementação.
- ArgoUML, aplicação open source para modelação UML.
- Magic Draw, ferramenta CASE com modelação UML.
- PowerDesigner, ferramenta de modelação de dados da Sybase.
Reunidas (quase) todas as condições, inicia-se o desenvolvimento do programa, ou a implementação do sistema, como se diz na gíria da indústria.
Nesta fase implementam-se as especificações definidas de forma a construir todo o sistema. Normalmente o processo inicia-se com a construção do modelo de dados e de seguida, ou em paralelo, arranca o desenvolvimento das aplicações.
Dependendo das características do projecto, o desenvolvimento pode ocorrer sequencialmente ou em paralelo nas várias áreas envolvidas.
Por exemplo, um projecto web pode arrancar com o grafismo e o modelo de dados ao mesmo tempo e, após a conclusão destas tarefas, passar à animação das páginas. Por outro lado, um projecto bancário pode iniciar-se com a implementação das interfaces dos serviços disponibilizados ao mesmo tempo que arranca a integração com o modelo de dados já existente.
O planeamento do desenvolvimento raramente é da competência do programador. No entanto, este deve ter voz activa no que toca à aceitação, ou rejeição, de um planeamento. É prática comum a gestão aparecer com um planeamento feito em MS Project com um conjunto de tarefas para um recurso, neste caso um programador, executar num dado espaço de tempo. Este tipo de planeamento é, muitas vezes, irrealista e possui uma filosofia totalmente errada. Ninguém melhor do que a equipa técnica que vai executar determinada tarefa sabe estimar quanto tempo demorará a mesma a ser implementada.
As consequências deste tipo de actos levianos costuma revelar-se na qualidade do produto final. A pressão imposta sobre os programadores é, nesta fase, imensa, sendo o objectivo crítico não falhar com os milestones que salpicam o gant chart do Project.
Nesta situação é comum o programador despachar código o mais rapido possível, sacrificando os testes que deveriam ser feitos.
Para evitar estas situações, um programador nunca deve aceitar um planeamento com o qual não se sente confortável. Esta posição gera, por vezes, conflitos que podem ser complicados de gerir, em particular quando a gestão do projecto não compreende o porquê de não ser possível efectuar determinada tarefa no prazo estipulado no Project que já foi aprovado pelo cliente.
Sabendo qual o caminho a seguir e como o percorrer, para iniciar a tarefa de implementação falta apenas o ambiente de desenvolvimento e as ferramentas.
O ambiente de desenvolvimento, muitas vezes erradamente confundido com o IDE e plataforma usado no desenvolvimento, contém toda a envolvente à tarefa de desenvolvimento. Estou a falar de sistemas de controle de versões, bug tracking, build, backup, testes automáticos e afins que permitem que o desenvolvimento decorra de melhor maneira.
Neste contexto, uma das ferramentas mais importantes, é o sistema de controlo de versões. Nunca, mas nunca se inicia o desenvolvimento sem um sistema destes. Um sistema de controlo de versões é o que permite que os programadores durmam descansados sabendo que o seu trabalho está salvaguardado de qualquer catastrofe. Este sistema permite o desenvolvimento em simultâneo de toda uma aplicação sem que os programadores se atropelem e estraguem o trabalho uns dos outros. Este sistema guarda todas as versões submetidas, permite a consulta de diferenças entre versões, efectua merges automáticos, faz tags e branches.
Um sistema de controle de versões per se não prescinde de um sistema de backup sobre o mesmo. E esta é outra peça fulcral que permite que a gestão do projecto durma descansada. A implementação de um sistema de backup diário, ou semanal, é fácil e barato pelo que não existe razão absolutamente nenhuma para a sua não existência.
Um sistema sem o qual o projecto, e os programadores, não podem viver é um sistema de bug tracking. Este sistema regista todos os bugs, evoluções e correcções dos mesmos. Este tipo de sistema permite saber quais, entre outras coisas, quais os problemas que aconteceram, porque aconteceram, como foram resolvidos e quais os problemas actualmente existentes e em correcção.
Outra ferramenta imprescindível é um sistema de build automático. Este tipo de sistema permite validar se todo o código desenvolvido até à data, quando junto, compila sem erros. Este tipo de procedimento é tipicamente executado durante a noite - embora não seja incomum a sua execução durante a hora de almoço - de forma a que quando os programadores cheguem tenham disponível um log sobre a execução da compilação, detectando assim erros e permitindo uma evolução estável do produto. Este tipo de processo aleado ao sistema de controle de versões resulta numa excelente parceria uma vez que todas as versões, ou pelo menos a última, que compilem sem erros devem ser marcadas como estáveis ao nível do desenvolvimento. Isto permite eliminar o stress e os erros humanos quando, vindos do nada, os programadores são obrigados pela chefia a fazer uma demo do produto naquele exacto momento a um potencial cliente que está a visitar as instalações. Este comportamento ilustra bem que muitas pessoas não têm a mínima ideia do que é "desenvolver". Nessa altura existem duas hipóteses: mostrar o que têm no preciso momento, que tipicamente nem sequer compila ou executa com erros e mensagens de debug por se estar a escrever código ou a corrigir um problema, ou mostrar a última versão que compilou bem, tendo a garantia de que a execução vai correr bem.
Uma ferramenta que muitas vezes nem os próprios programadores dão muita importância é a ferramenta de geração de documentação técnica. Esta ferramenta permite ter sempre actualizada toda a documentação técnica do código desenvolvido.
Outra ferramenta extremamente importante e muitas vezes relegada para planos secundário e não usada é uma ferramenta de testes automáticos. Uma ferramenta destas garante a qualidade do produto nas várias fazes do seu desenvolimento, incluindo a qualidade do produto final. Este tipo de ferramentas permite verificar se uma funcionalidade, ou um pedaço de código, tem erros ou não. É sabido que quanto mais tarde se encontra um bug mais cara é a sua resolução. Este tipo de sistemas permite detectar um enorme conjunto de problemas enquanto os programadores têm ainda bastante fresco na sua cabeça o código correspondente.
A combinação destas ferramentas resulta num aumento substancial da qualidade do produto final e na qualidade de vida de todos quantos estão envolvidos no projectos, em particular os programadores. É fácil compreender as enormes mais valias de um sistema que combina todas estas ferramentas:
1. Sistema automático de build:
1.1. Se existem erros, saltar para o passo 99.
1.2. Caso contrário, marcar o código como compilável.
2. Execução dos testes unitários.
2.1. Se existem erros, saltar para o passo 99.
2.2. Caso contrário, marcar o código como estável.
3. Efectuar a geração da documentação técnica:
3.1. Guardar no servidor de controlo de versões a documentação técnica.
3.2. Disponibilizar, por exemplo num servidor, esta última versão da documentação técnica.
4. Executar os testes funcionais.
4.1. Se existem erros:
4.1.1. Caso seja possível, ou faça sentido, registar o bug no sistema de bug tracking.
4.1.2. Saltar para o passo 99.
4.2. Caso contrário:
4.2.1. Marcar o código como versão Alfa, ou Beta, dependendo do estado do desenvovilmenteo do produto.
4.2.2. Guardar no servidor de controlo de versões todos os binários e efectuar a mesma tag do passo 4.2.1. sobre os mesmos.
4.2.3. Disponibilizar, por exemplo num servidor, as últimas versões todos os binários.
99. Enviar um email a todos os interessados com o resultado do processo.
Num sistema destes, os erros são apanhados pela equipa de desenvolvimento, i.e., muito antes da equipa de testes testar uma funcionalidade, já os programadores resolveram o grosso dos bugs que normalmente a equipa de testes costuma apanhar numa fase inicial. Desta forma, a equipa de testes vai reportar bugs mais complexos e difícieis de encontrar através de baterias de testes automáticas.
A pareceria entre os programadores e a equipa de testes é também uma mais valia, uma vez que permite criar uma simbiose produtiva na produra qualiade máxima do produto.
Quando o processo de desenvolvimento de produto não tem estas ferramentas, os produtos vão ser testados pelos clientes que se queixam dos erros que apanham. Nesta última situação adivinhem quem vai ser culpado, quem vai ter de ficar até mais tarde para corrigir o problema, quem vai ter de fazer um enorme esforço, 4,5,6 meses mais tarde, quem vai ser penalizado em caso de avaliação?
Nem mais, o programador.
O ambiente de desenvolvimento é assim uma peça fulcral que salvaguarda e garante a qualidade do trabalho dos programadores. Por vezes a gestão do projecto não compreende a necessidade de investir em todas estas ferramentas e nega-se a montar todo este "aparato". Essas pessoas são, normalmente, mal informadas sobre as enormes mais valias que todo este circo trás para a empresa, não só a nível humano - não desgasta as pessoas pois os problemas são rapidamente detectados e corrigidos -, poupa imenso dinheiro à empresa - em particular por esta não ter de possuir uma equipa de testes e de suporte tão grande e porque não vai ter de desviar, meses mais tarde, um programador que já se encontra a trabalhar noutro projecto para corrigir o problema, não impactando assim esse projecto - e, por fim, cria perante os clientes uma imagem sólida e de qualidade.
- Doxygen, geração de documentação técnica.
- QA Wizard, robot para automatização de testes.
- ANT, ferramenta de build.
- Controle de Versões:
Subversion, sistema de controle de versões open source.
Subversion, livro de Subversion.
CVS, sistema de controle de versões open source.
WinCVS, GUI para o CVS.
CVS, manual e utilização no mundo real.
- Bug Track:
Bugzilla, bug tracker open source.
Eventum, issue tracker open source.
Tendo toda a envolvente montada, avança-se para a programação propriamente dita.
Independentemente da linguagem, ou linguagens, e sistemas ou plataformas envolvidas no processo de desenvolvimento, existe um conjunto de normas e ferramentas que são imprescindíveis no dia-a-dia da programação.
O uso de um standard para as linguagens envolvidadas é crítico. Caso não exista um standard da equipa, deve ser adoptado um standard massivamente aceite, por exemplo o standard da Sun no caso do Java. Só assim é possível que todo o código desenvolvido pela equipa possa ser lido e compreendido rapida e facilmente por qualquer pessoa da equipa.
Os comentários, sendo parte integrante de um standard, não devem ser descurados. Se bem que o código deve ser simples e auto-explicativo, por vezes existem pedaços de código mais críticos ou complexos que merecem uma explicação adicional. A documentação de uma função ou procedimento, tipicamente junto à definição da sua assinatura, é imprescindível. É uma boa regra da programação escrever a assinatura da função e a sua documentação num único passo. Os comentários permitem compreender melhor o código e, usando uma ferramenta de geração de documentação técnica, construir de forma automática toda a documentação técnica do produto.
Todo o código desenvolvido deve ter associado uma bateria de testes unitários para garantir o sue correcto funcionamento. Estes testes devem englobar, além da verificação do correcto funcionamento nos casos normais, casos limites e casos de erro. Só assim é possível garantir que o código faz o que é suposto sabe o que fazer aquando da existência de um erro. Quase todas as linguagens de desevolvimento possuem uma framework de testes unitários, como acontece com o JUnit para Java (que vem de raíz no Eclipse) ou o PyUnit no caso do Python.
Os testes unitários têm também de ser comentados, de forma a que, em caso de erro, se compreenda o que estava a ser testado quando ocorreu a falha.
Todos os bugs detectados devem ser registados num sistema de bug tracking. Este sistema permite a construção de uma knowledge base dos problemas com que o projecto se deparou e permite, no caso de ser uma nova versão, saber exactamente o que foi corrigido nesta nova versão e, por exclusão, o que falta ainda corrigir.
Outra funcionalidade extremamente útil é saber quando, por quem, e como ficou resolvido o bug corrgido, fazendo mensão directa a, por exemplo, uma tag do controle de versões.
O uso correcto do controle de versões é parte do dia-a-dia de qualquer programador. Não havendo uma regra para submeter código, o bom senso deve imperar. Tipicamente o código é submetido ao fim do dia de trabalho, quando se termina uma funcionalidade ou o código se encontra estável. Um comentário, ou descrição, deve sempre acompanhar a submissão do código. Esta regra é ainda mais importante na aquando da correcção de um bug, onde deve ficar registado o identificador do mesmo.
Existe um conjunto de aplicações que fazem parte da "caixa de ferramentas" de qualquer programador. Uma shell que permita scripting "decente", um editor de texto genérico com suporte de multiplos formatos de texto, um programa de grep e um diff/merge são disso exemplos. Certos sistemas disponibilizam já muitas destas ferramentas.
O uso de standards, de processos e de ferramentas certas disponibiliza ao programador as condições certas para que a sua produtividade seja alta. A redução de bugs na versão final e a
- Standards de Codificação:
GNU Standard
- Cygwin, ambiente identico ao Linux para Windows. Disponibiliza uma boa shell para Windows.
- Eclipse, IDE multi-plataforma com imensos plugins para várias linguagens de programação, como por exemplo Java e Python. Possui plugins de profiling, standard coding, UML design e muito mais.
- MinGW, conjunto de ferramentas, bibliotecas e headers que permitem a construção de aplicações Windows nativas não dependentes de libliotecas third party.
PSPad, editor gratuíto para Windows. Suporta ficheiros texto (DOS, UNIX, MAC e Unicode) e binários, com syntax highlight, code compleation, navegador de código, multilingue, dicionários, correcção ortográfica, templates, comparação de ficheiros e muito mais .
Emacs, editor de texto (DOS, UNIX, MAC e Unicode), programável, extensível, com syntax highligh, multi-plataforma e muito mais.
- WinMerge, aplicação open source de comparação de ficheiros (DOS, UNIX, MAC e Unicode) e directórios. Permite a geração de relatórios e o merge de ficheiros.
- Windows Grep, aplicação gratuita de pesquisa sobre ficheiros (texto, binários e dentro de zips) suportando expressões regulares e substituição de texto.
- 7-Zip, aplicação gratuíta, distribuída sob a licença GNU LGPL, de compressão de ficheiros.
A documentação é um dos pontos mais críticos, importantes e, muitas vezes, esquecidos num projecto. A documentação, tanto a nível técnico para a equipa de desenvolvimento como a nível funcional para o utilizador final, é imprescindível.
A documentação técnica, já abordada num tópico anterior, facilita a vida de toda a equipa de programação, permitindo a consulta e promovendo a discussão das opções técnicas efectuadas.
A documentação de um produto para o utilizador final, à qual me vou referir de agora em diante apenas por documentação, tanto pode ser uma mais valia para o produto como um factor de fracasso para um projecto.
Qualquer utilizador de uma aplicação espera ter disponível a documentação necessária para o ajudar em qualquer tarefa, seja ela a instalação, configuração ou utilização da aplicação em causa. A falta de documentação, ou uma documentação mediocre ou insuficiente, pode levar um utilizador ao insucesso no desempenho de uma dada tarefa e fazer com que um produto passe a ser visto como mau e dispensavel. É critico que a documentação responda a todas as dúvidas e ajude o utilizador a usar a aplicação, caso contrário o utilizador vai sentir-se frustrado, perder o interesse pela aplicação e catalogá-la como má.
Já uma documentação bem construída e que responsa ao utilizador de forma positiva sempre que o mesmo necessite de ajuda, causa uma sensação de sucesso e produtividade passando a aplicação a ser vista como uma mais valia e um aliado de valor.
Construção da Documentação
A documentação sai do documento de requisitos e, por vezes, da análise funcional, ambos cobertos num tópico anterior. É nesses dois documentos que está definido e explicado tudo quanto a aplicação faz, não faz, como faz, como se usa e para que serve.
Se, por exemplo, a aplicação tem de suportar como funcionalidade de segurança o uso de chaves RSA, então a documentação deve fazer menção do que é uma "RSA Key" e qual o comportamento que a aplicação tem quando esta funcionalidade está ligada e desligada. Escrever uma baboseira do tipo "Active as chaves RSA caso pretenda usar esta funcionalidade" ou "Para usar chaves RSA active esta opção" é totalmente inútil e vai contra todas as expectativas do utilizador. Uma pessoa que não sabe o que é uma chave RSA não vai ficar a saber qual a diferença entre ter a opção activa e inactiva, logo vai achar que a documentação não presta e é totalmente inútil por não a ajudar a usar a aplicação de forma produtiva para as suas necessidades.
A inclusão de um tutorial ou a explicação passo-a-passo no uso de uma determinada funcionalidade ajuda um utilizador a compreender melhor a aplicação, a tirar maior rendimento e a ganhar proficiência na mesma. Existem algumas funcionalidades que fazem mais sentido quando combinadas com outras, como é o caso da inclusão do número de página no rodapé de uma folha. Tipicamente, para se colocar o número de página no rodapé de uma folha é necessário conjugar a funcionalidade de tornar o rodapé evitável com a funcionalidade de inserir o número de página. Se um utilizador estiver interessado em introduzir o número de página, o manual deve fazer menção ao rodapé e ter um pequeno guia passo-a-passo exemplificando como o utilizador pode introduzir o número de página no rodapé. Esta explicação passo-a-passo ligada com o rodapé faz mais sentido e é mais útil para o utilizador, em especial se o mesmo não tem grandes conhecimentos da aplicação, do explicar simplesmente o que é o número de página e como fazendo "Inserir->Número de Página" se coloca o número da página no texto.
Por vezes os manuais têm um "troubleshooting" e uma secção de FAQ onde se responde a um conjunto de dúvidas comuns e frequentes. Esta secção nasce a partir dos testes funcionais efectuados pela equipa de QA e da colecção de problemas que os utilizadores mais reportam.
A construção destas secções é um investimento valioso em todo o produto.
Se a documentação contemplar estas duas secções faz com que um utilizador possa, por si só, descobrir e resolver um problema, criando uma sensação de satisfação e produtividade proporcionada pelo produto. As vantagens não se esgotam aqui. Ajudar o utilizador a detectar e resolver os seus próprios problemas revela-se uma enorme vantagem económica para a empresa, pois permite ter uma equipa de suporte mais pequena, focada e especializada em problemas realmente graves, não perdendo tempo nem energia a explicar porque, por exemplo, o utilizador não consegue usar a aplicação em 640x480 por esta ter sido desenhada para um mínimo de 800x600.
A documentação tem enormes mais valias para o produto e para a empresa. Além de não gorar as expectativas do utilizador, uma boa documentação ajuda a cimentar a confiança no produto e na empresa, fazendo com que o utilizador se sinta confiante, bem sucedido e produtivo no uso do produto. Este facto cria uma boa imagem do produto, e da empresa, evidenciando a qualidade do trabalho feito e passando a ser bem referenciada no mercado. Estes factos, quando adicionados à necessidade de um equipa de suporte mais pequena, tornam-se economicamente interessantes e relevantes para que uma empresa séria invista na criação de uma boa documentação.
DocBook XML Resources at CERN, um conjunto de recursos sobre Docbook usados pelo CERN.
DocBook Technical Committee Document Repository, repositório de documentação do comité técnico do Docbook na Oasis.
OASIS DocBook TC, comité técnico do Docbook na Oasis.
A título de curiosidade, o Docbook é usado pela O'Reilly na escrita dos seus livros.
A qualidade de um produto, seja ele software ou não, depende muito dos testes que a área de qualidade efectua.
Cada release efectuada de um determinado produto deve ser disponibilizada à equipa de Quality Assurance (QA). É esta equipa que vai testar o produto de forma a encontrar dois tipos de problemas:
- coerência com o caderno de requisitos
Esta equipa é responsável por definir e executar testes, incluindo testes de carga, paralelismo, etc., de forma a tentar encontrar falhas. É comum as equipas de QA terem acesso ao produto a partir da sua versão Alfa. Esta equipa trabalha em conjunto com a equipa de desenvolvimento, pois o seu trabalho permite que aos programadores reproduzir, compreender e corrigir as anomalias detectadas.
Cada problema encontrado é reportado num sistema de bug tracking de forma a que seja possível confirmar a correcção do problema detectado e ficando registada a causa e solução. Este processo permite construir uma base de conhecimento sobre o produto que serve um conjunto de equipas:
- Desenvolvimento: em caso de reporte de um problema igual ou identico o programador consulta a causa provável e a possível solução, poupando tempo, dinheiro, paciência e desgaste.
- QA: permite construir um conjunto de testes com um grau de granularidade cada vez mais fino procurando comportamentos incorrectos em situações identicas.
- Suporte: permite identificar se um determinado problema já foi reportado e até resolvido. Permite também construir uma FAQ, que pode também ser distribuída com o produto ou disponibilizada na internet, disponibilizando muitas soluções de forma rápida.
Embora por vezes certos tipos de testes tenham de ser feitos assim ou tenham de ter acompanhamento human, normalmente a equipa de QA não efectua testes de forma manual, usa robots de forma a que estes executem os testes. O uso de robots é imprescindível para a área de QA. Sem eles não é possível efectuar testes de carga reais nem simular paralelismo no uso de uma aplicação. Mais ainda, sem o uso de robots não é possível integrar os testes com o processo de nightly builds, nem sequer é possível garantir a execução exactamente igual dos testes nem repetir um teste inumeras vezes até à exaustão. Um robot pode passar 12 horas durante uma noite sempre a efectuar testes sem se enganar, totalmente "focado", sem se atrapalhar com o cansaço, etc.. Os robots são assim um aleado valioso da equipa de QA e de todo o processo de desenvolvimento, garantindo a qualidade de um produto.
Nem todas as empresas e gestores compreendem a real importância, mais valia e necessidade da existência de uma área de QA. Todos gostam de apregoar a qualidade dos seus produtos, mas a verdade é muito poucos a têm e menos ainda são as empresas e gestores que compreendem o que realmente é necessário para garantir um determinado nível de qualidade. Mesmo as empresas que têm equipas de QA, nem todas compreendem a necessidade de ter robots, caindo mais uma vez na falácia de que comprar um robot é gastar dinheiro, quando na realidade tal é um investimento rapidamente amortizado, e preferindo desgastar o capital humando da equipa de QA em tarefa extremamente repetitivas e nada competitivas em comparação com a performance de um robot.
- Robots de Testes Funcionais:
WinRunner, possui integração e pode ser expandido.
QA Wizard, simples de usar.
Descrito de forma simples, deployment é a actividade de instalar e configurar uma aplicação, garantindo que no final o sistema está a funcionar correctamente. Um deployment pode variar entre a execução de um simples script de instalação até actividades mais complexas e integradas, envolvendo várias áreas, como seja a disponibilização do hardware, configuração de uma base de dados e gestão de acessos numa rede. Tudo depende da arquitectura e complexidade do sistema em questão e da flexibilidade e operacionalidade das áreas envolvidas.
Um deploy começa sempre por um guião que possui uma lista de tarefas cujas pessoas envolvidas vão marcando como executadas à medida que o deploy vai evoluindo. À cabeça dessa lista de tarefas está sempre o backup. Um deploy começa sempre pelo backup de tudo onde o novo sistema vai tocar, ou impactar. Por vezes este passo é descurado, sendo o seu resultado uma catastrofe enorme caso o deploy falhe ou tenha de ser abortado.
Uma salvaguardado o sistema através do backup, passa-se à instalação de todas as peças de software, incluíndo scripts de manipulação de modelos de dados. Esta tarefa deve ser efectuada de forma automática, embora sejam comuns as execuções destes scripts de forma manual. Esta abordagem não é a correcta, em particular quando existe uma sequência de passos de instalação com dependências associadas a esta tarefa. A introdução de intervenção humana é totalmente desaconselhável uma vez que tal é uma potencial fonte de erros.
Uma vez tendo o software pronto, inicia-se a configuração. Tal pode variar entre acesso a máquinas remotas à simples edição de ficheiros de configuração onde quais os serviços que devem arrancar no boot de uma máquina.
Tendo toda a infraestrutura pronta, é hora de executar uma bateria de testes de validação do deploy. Estes testes devem ser efectuados de forma automática, não só pelo facto da intervenção humana pode introduzir erros mas também porque a execução automatica de uma bateria de testes de validação é mais rápida e permite um grau de confiança superior, uma vez que estes testes devem também ter sido executados enumeras vezes pela equipa de QA.
Após a validação do resultado dos testes, é hora de disponibilizar o sistema em produção como total garantia e confiança no seu correcto funcionamento.
- Inno Setup, instalador para Windows, freeware, com código fonte incluído, suporte multilingue e plugins disponiveis.
- RPM, sistema de gestão de pacotes que permite, entre outras coisas, instalar aplicações.
- Self-Extractable Archives, .tar.gz shell scripts com auto-descompressão úteis para efectuar instalações.
Uma vez entregue o produto, é altura de iniciar o suporte. Dependendo da criticidade do sistema e do negócio, o suporte pode variar de entre umas simples 8 horas por mês, para manutenção ou simples alterações, até planos 24x7 com tempos de resposta abaixo das 2 horas.
Independentemente do plano de suporte, o mais provavel é que existam alterações ao sistema. Essas alterações têm impactos não só no sistema instalado como no desenvolvimento da nova versão do sistema, quando, por exemplo, se detecta e corrige um bug.
Esta actividade é de extrema importância económica e estratégica, uma vez que a actividade de suporte é tanto mais lucrativa e bem vista quanto menor for a sua solicitação. Ou seja, sempre que num ciclo, tipicamente mensal, a actividade de suporte é cobrada mas não ocorreu nenhuma intervenção a esse nível, isso quer dizer que (i) a, ou as, pessoas responsáveis por essa actividade puderam trabalhar noutra actividade e (ii) a qualidade do produto é boa e o cliente deve estar satisfeito.
Uma estrutura de suporte envolve, tipicamente, pelo menos duas linhas, uma de contacto directo com o cliente, que filtra, despista e resolve os problemas mais fáceis. Para reduzir os custos de suporte, é imprescindível a criação de FAQs e a distribuição de patchs que corrigem anomalias detectadas. Tudo isto permite aumentar a independência do cliente em relação ao suporte e consequentemente baixar os custos desta actividade. A construção e disponibilização de FAQs tanto para os clientes como para as equipas de suporte permite uma resposta rápida que é do agrado de todos. A equipa de suporte tem a seu cargo a identificação dos problemas mais recorrentes, que devem ser incluídos na FAQ, de forma a que a frequência de pedidos de suporte para esses problemas baixe.
Uma actividade como a de suporte necessita de uma estrutura de apoio bem montada de forma a garantir o seu correcto e fluído funcionamento. O uso de um sistema de registo de ocorrências é indispensavel. Sempre que um problema é relatado, o utilizador deve ser identificado, incluindo nessa identificação pelo menos um contacto directo, e deve ser recolhida a maior quantidade de informação possível de forma a ajudar a encontrar o problema. Assim que o problema for registado no sistema, o cliente que o relatou deve ser informado, tipicamente através de um email automatico enviado pelo sistema, de que a empresa tomou conhecimento do problema e que o vai resolver. Quando o problema for resolvido e dado como fechado, o utilizador que o reportou deve ser notificado desse evento.
Um sistema de suporte a esta actividade deve permitir fluxo de estados dos problemas e suporte passagem entre as várias linhas envolvidadas assim bem como a fusão e relação entre problemas iguais, identicos ou relacionados. A ligação entre este sistema e o sistema de bug tracking de desenvolvimento e de QA permite que tanto a equipa de desenvolvimento como a equipa de QA fiquem com a anomalia registada nos seus sistemas permitindo, caso se justifique, que as mesmas entrem nas suas baterias de teste para garantir que a anomalia encontrada não volta a acontecer.
Um site institucional, de suporte, ou um fórum, que permita a um cliente encontrar a solução do seu problema sozinho, recorrendo, por exemplo, a uma FAQ é também um aliado valioso nesta actividade.
A ligação orgânica entre as várias linhas de suporte é também de exprema importância, quanto mais perto as linhas trabalharem melhor será a resposta aos problemas reportados.
A actividade de suporte é assim uma mais valia para a empresa, uma vez que quando bem montada e acente sobre produtos com qualidade é uma boa fonte de receitas e uma excelente bandeira de marketing ao nível da qualidade. É também uma enrome mais valia para o cliente que tem aí uma rede de segurança caso algo corra mal.
- Request Tracker, conhecido simplesmente como RT, este sistema open source é dos mais usados mundialmente.
- Industry Best Practices Help Desk & ITSM / ITIL Software, conjunto de aplicações para help desk e network operations center.