Qualidade de Software Ltda

Tenho trabalhado muito com a implantação de metodologia de desenvolvimento de sistemas, e o que ouço freqüentemente dos desenvolvedores basicamente é que ela burocratiza o processo de desenvolvimento. Será?

Considere o RUP, que é formado por nove disciplinas cada uma com um conjunto de artefatos, produtos de trabalhos, checklists, templates, papéis etc. Quem consegue desenvolver um software seguindo completamente todas essas nove disciplinas? Certamente ninguém, nem a própria IBM. Ocorre que não se recomenda adotar o RUP, ou qualquer outra metodologia, sem uma devida "customização" da mesma para as necessidades de cada equipe de desenvolvimento. Customizar significa adotar apenas o necessário, o suficiente.

A adoção de uma metodologia adequada às suas necessidades de desenvolvimento de sistemas traz vários benefícios como: estabelecer uma linguagem comum para a equipe de desenvolvimento e os envolvidos no projeto (clientes, patrocinadores e fornecedores), atender a requisitos legais de compliance, SOX, auditorias e órgãos regulamentadores, melhorar a qualidade do software; rápida capacitação de novos colaboradores quanto ao processo de desenvolvimento adotado pela equipe, protege os ativos de software produzidos pela empresa além de permitir que qualquer membro da equipe possa sair de férias, sem parar o processo de desenvolvimento, ou de ser chamado nas suas férias para uma manutenção emergencial em um software em produção!

Qual a melhor metodologia a ser adotada? Para mim será aquela que representa apenas o necessário através de um conjunto de práticas (casos de uso, diagramas da UML, modelagem de processos de negócios, etc) de atividades, quem desempenha qual papel no processo de desenvolvimento e com um conjunto mínimo de artefatos que agreguem valor ao processo de desenvolvimento. Isso não é burocratizar, é racionalizar o desenvolvimento.

Quem tiver interesse em conhecer um conjunto com diversos links sobre as diversas metodologias de desenvolvimento atuais, elaborei uma lista no Delicious. Acesse: http://del.icio.us/prasabermais

Cada vez mais as empresas que desenvolvem software estão dedicando mais atenção à etapa de testes. Com o aumento do interesse nessa etapa do desenvolvimento, há necessidade de se ter acesso a bons a materias de referência: livros, sites, artigos, glossários etc. Tenho conversado bastante com fornecedores de serviços de testes, e vejo claramente como o vocabulário da área de testes ainda não está cristalizado. É comum haver problemas na definição de testes unitários, testes de sistemas, testes de integração, casos de testes, cenários de testes, condições de testes e por aí vai…Cada um tem a sua própria definição para cada termo. Penso que na área de codificação os termos já estejam bem mais critalizados se comparados com os termos de testes!

Certamente uma contribuição para sedimentação dos conceitos de testes são os processos de certificação. Segue abaixo as duas ofertas mais conhecidas de serviços de certificação:

1) a certificação do BSTQB (Certified Tester, Foundation Level – CTFL, provida pelo ISTQB). Veja mais informações sobre essa certificação no site – http://www.bstqb.org.br/modules/content/index.php?id=2.

2) e a certificação da ALATS (Certificação Brasileira de Teste de Software – CBTS). Veja mais informações sobre essa certificação no site – http://www.alats.org.br/Default.aspx?tabid=28

No site da BSTQB você encontra um conteúdo (em português) sobre fundamentos de testes (disponível em Syllabus Foundation Level), e ainda um glossário (disponível em ISTQB – Glossário de Termos de Teste). É um material que todo profissional da área de testes deveria ter conhecimento! Confira!

Um dos grandes desafios para as equipes de desenvolvimento de sistemas que desejam elevar o nível de maturidade do seu processo de desenvolvimento, é necessariamente definir qual é o seu processo de desenvolvimento, ou seja: quais são os papéis, atividades, tarefas, passos, artefatos e resultados existentes no seu processo de desenvolvimento.

Embora definir um processo de desenvolvimento, possa parecer uma atividade simples e rápida, pois temos no mercado uma vasta gama de processos de desenvolvimento comerciais, como o RUP, XP, SCRUM, etc…, geralmente essa não é uma tarefa simples se a sua equipe de desenvolvimento tiver aproximadamente 100 desenvolvedores, divididos em grupos de 10 a 15 pessoas, e desenvolverem sistemas com características distintas: programas on-line, batch, plataforma mainframe e plataforma distribuída (open).

Ainda que exista no mercado uma série de metodologias de desenvolvimento "prontas", sempre será necessário customizá-la para a realidade de cada empresa, e de cada equipe de desenvolvimento. Essa customização deve preferencialmente ser feita com a participação de representantes das equipes de desenvolvimento, de forma a se definir um processo que represente as necessidades reais das equipes de desenvolvimento e para que também seja "aceito" pelas equipes, para que possa ser praticado, e não se torne um adereço sem utilidade.

Definido o processo para a equipe de desenvolvimento, o próximo passo é publicar e comunicar esse processo. Para isso, recomendo conhecer a ferramenta EPF (Eclipse Process Framework) disponível em  http://www.eclipse.org/epf/. O EPF é um projeto da comunidade Eclipse (http://www.eclipse.org) que tem dois principais objetivos: 1) prover uma ferramenta para elaboração de processos de engenharia de software (figura 1), abrangendo autoria de métodos e processo, gerenciamento de bibliotecas de processos, configuração e publicação de processos, e 2) prover conteúdos de processos de gerenciamento e desenvolvimento de sistemas (figura 2), com foco em desenvolvimento iterativo, agil, incremental aplicáveis a diversas plataformas de desenvolvimento.

Figura 1 – Exemplo da ferramenta de autoria de processo 

Figura 2 -  Exemplo de conteúdo de processo de desenvolvimento: OpenUP

Tenho acompanhado a evolução do EPF desde suas versões iniciais, e vale a pena conhecer esse produto. Atualmente está disponível no site a versão 1.2.0.4 e os conteúdos de processos para OPENUP, XP e SCRUM. Pode ser um boa alternativa para pequenas e médias empresas que desejam definir, documentar e comunicar o seu processo de desenvolvimento, e assim buscar um melhor nível de maturidade tanto do processo quanto do produto de software.

ps.: A IBM é patrocinadora desse projeto, e comercializa o produto denominado Rational Method Composer, derivado do EPF.

Nos dias 18 e 19 de Junho participei do evento acima dedicado a comunidade de desenvolvimento de software e obviamente, usuários da IBM e mais especificamente dos softwares da Rational, que está desenvolvendo uma nova família de produtos baseados na plataforma Jazz (acesse o site do projeto em http://jazz.net/pub/index.jsp). Segundo o site, o Jazz é um projeto da IBM Rational para construir uma plataforma escalável, de colaboração para integração de todas as fases de desenvolvimento. O objetivo do Jazz é o de ajudar as equipes de desenvolvimento a constuir software melhor, de forma mais produtiva e agradável (bem marketeiro, hein?).

O objetivo desse post, obviamente não é fazer propaganda da   IBM Rational e sim divulagar, para quem se interessar, que as apresentações realizadas nesse evento estão disponíveis em: http://www.detaileventos.com.br/ibm_dc2008/downloads.htm

Vale a pena conferir!

Para que possamos compreender como produzir software com qualidade, se faz necessário contextualizar o que é qualidade.

Desde a década de 70, quando os softwares estavam restritos aos centros de pesquisas, áreas militares e às grandes empresas, até os dias atuais em que estão cada vez mais presentes em diversas atividades da sociedade, a engenharia de software tem contribuído para estabelecer um processo de desenvolvimento consistente, racional e que produza um produto confiável e com qualidade.

A importância do software na vida das pessoas aumenta a cada dia e tanto a vida pessoal quanto a profissional podem ser melhoradas com a presença de um software de alta qualidade. A qualidade do produto de software corresponde à totalidade das características que lhe confere a capacidade de satisfazer necessidades explícitas e implícitas (NBR ISO/IEC 14598-1, p.4)

A definição do que é qualidade do produto de software envolve várias características, como funcionalidade, confiabilidade, usabilidade, manutenabilidade, portabilidade e eficiência. Esta pode ser definida como a capacidade do produto de software apresentar desempenho apropriado relativo à quantidade de recursos usados sob condições especificadas. (NBR ISO/IEC 9126-1, p.7 e 10)

Dimensões da qualidade de um sistema Web

Petrasch (1999, p1) define qualidade de um software como:

“A existência de características em um produto, as quais correspondem aos requisitos. Além disto deve-se considerar as características que não correspondem aos requisitos, as quais reduzem a qualidade do software, e também as características neutras, as quais não são relevantes para a qualidade. Está claro que não só as presenças de características são importantes, mas também as ausências de características contra produtivas.”

Segundo essa definição, a qualidade de um software é determinada diretamente pela existência de características como, por exemplo, funcionalidade e desempenho, que atendam a requisitos definidos para o sistema. Além disso, em um software de qualidade deve inexistir características que não estejam associadas aos requisitos. A definição dos requisitos de qualidade de um software muda em função do valor que cada usuário atribui a eles em função do seu tipo de uso. Assim, a definição de qualidade não é um conceito estático.

Garvin, A. (1988) destaca a importância do modelo de qualidade baseado no usuário, no qual essa característica passa a ser medida pela percepção da pessoa que o utiliza. O usuário determina se o sistema em questão atende suas diversas expectativas, dentre elas: a funcionalidade, a usabilidade e o desempenho. Assim, a qualidade de um sistema não é um atributo absoluto, ela pode variar em função das expectativas de diferentes usuários. (IEEE Standard Glossary of Software Engineering Terminology IEEE-STD-729-1983)

Offutt (2002, p.26) afirma, quanto à qualidade de sistemas Web, que:

“Desenvolvedores de sistemas Web somente obtém um retorno do seu investimento se o seu Web site satisfaz a necessidade dos seus clientes. E, diferente de muitos vendedores de software, se a nova empresa concorrente publica um site de mais alta qualidade, os clientes irão quase que imediatamente mudar os seus negócios para este novo site, uma vez que eles descubram este site. Assim ao invés de “mais cedo, porém pior”, é freqüentemente mais vantajoso, “mais tarde, e melhor”.

Nessa citação, o autor destaca a importância da qualidade no caso para sistemas Web e justifica, através da satisfação dos futuros usuários, a dimensão de tempo no ciclo de desenvolvimento: ele defende que se deve desenvolver um sistema melhor, ainda que leve um tempo maior.

Os principais requisitos de qualidade de software do ponto de vista do usuário são: a funcionalidade, a usabilidade e o desempenho, caracterizadas através do gráfico 1, que demonstra as diferentes dimensões de qualidade de um software e a importância de cada uma delas sob o ponto de vista do desenvolvedor e do usuário.(Stutzke, 2002, p. 5)

Gráfico 1 – As dimensões da qualidade e sua importância

(Adaptado de Stutzke, p.1)

Segundo o gráfico 1 o a funcionalidade, a usabilidade e o desempenho são as três principais dimensões de qualidade para os usuários.Portanto o processo de desenvolvimento de um sistema deve contemplar atividades de avaliação que permitam construir um sistema que atenda a objetivos pré-estabelecidos para as dimensões de qualidade mais valorizadas pelos usuários de um determinado software.