Qualidade de Software Ltda

Do ponto de vista dos fornecedores o mercado de ferramentas para testes de software é um mercado em consolidação, pois nos últimos 18 meses ocorreram diversas aquisições entre as empresas: a Borland comprou a Segue Software. A Micro Focus comprou a Borland e a linha de produtos open de qualidade de software da Compuware. A HP comprou a Mercury (líder de mercado). IBM e HP adquiriram ferramentas de software para testes de segurança. A Microsoft continua sua expansão nesse mercado, adicionando ferramentas de gerenciamento e de testes manuais na próxima versão do Visual Studio (2010)
Leia mais …

É sabido que programas de certificação como o CMMI e o seu primo brasileiro MPS.BR tem colocado os olofotes sobre os processos de desenvolvimento. Muitas empresas denvolvedoras de software fizeram o seu trabalho de casa no que tange a definir, documentar, e divulgar seu processo de desenvolvimento. Feito isso o próximo passo e obter um nível de certificação. Obtida a certificação (nível 2, ou nível 3 ou…) aí e só alegria! Almoços de comemoração e muita publicidade, afinal de contas deu um bocado dc trabalho para conseguir a certificação. Mas e a qualidade do produto de software?

Bem, este é o ponto. Certificação do processo, não significa certificação do produto! É aí que mora o perigo! Deitado em berço esplêndido de uma certificação muitas empresas se esquecem da qualidade do produto.

Para garantir que um processo certificado produza um produto de software de qualidade será necessário uma boa equipe de qualidade assegurada, que não só execute checklists, mas faça inspeções em cada etapa do processo de desenvolvimento para se verificar a conformidade entre o que foi especificado e o que foi construído. Um produto de software pode ser produzido e até funcionar e mesmo assim não estar em conformidade com a especificação. Por exemplo, a especificação descreve uma arquitetura lógica de três camadas e o programador implementa em uma camada única. A especificacao descreve um determinado método de acesso e o programador implementa um método diferente, e assim vai sendo comprometida a qualidade do produto mesmo de uma empresa certificada.

E você o que pensa sobre a qualidade do produto de empresas certificadas? Dá para confiar cegamente?

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

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.

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.