Teste e Análise de Software - Processos, Princípios e Técnicas

Autor: Mauro Pezzè, Michal Young
Editora: Artmed 
I.S.B.N.: 9788577802623
Edição: 1 / 2008
Idioma: Português
País de Origem: Brasil

Um software de qualidade não pode ser construindo sem a utilização de técnicas de teste e análise de software. Este livro apresenta um conjunto de técnicas de teste e análise em uma prática moderna. Escrito em linguagem acessível, abrange tópicos bem aprofundados e oferece uma visão geral sobre o assunto.


QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Introdução ao Teste de Software

Autor: Mario Jino, José Carlos Maldonado, Márcio Eduardo Delamaro
Editora: Elsevier - Campus
I.S.B.N.: 9788535226348
Edição: 2007
Idioma: Português
País de Origem: Brasil

Em 2006, a Sociedade Brasileira de Computação (SBC) organizou o seminário Grandes Desafios da Computação, onde foram identificados os mais importantes temas relacionados à área para a próxima década. Dentre eles, está o desenvolvimento tecnológico de qualidade e, conseqüentemente, a disponibilização de sistemas corretos, confiáveis e seguros. Nota-se também que, nos últimos anos, a indústria de software, no Brasil e no resto do mundo, tem empregado cada vez mais recursos na busca pela qualidade de seus produtos e na redução de seus custos de desenvolvimento e manutenção. Além da demanda criada pelas principais companhias de desenvolvimento de software, nota-se uma acentuada carência de profissionais aptos a atuar na área de qualidade e, mais especificamente, de teste de software.
Essas são apenas algumas razões que devem incentivar a leitura deste livro. Nele, procura-se apresentar as principais técnicas de teste de software, mostrando suas origens, evolução e tendências. Mostra, também, como essas técnicas vêm sendo aplicadas em domínios específicos como o desenvolvimento de software para a Web ou baseado em aspectos. Trata, ainda, de dois tópicos importantes e fortemente relacionados ao teste e qualidade de software que são: depuração e confiabilidade. 


QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Base de Conhecimento em Teste de Software

Autor: Aderson Bastos, Ricardo Cristalli, Trayahú Moreira, Emerson Rios
Editora: Martins Editora 
I.S.B.N.: 8599102893
Edição: 2 / 2007
Idioma: Português
País de Origem: Brasil

Obra de referência para os profissionais da área, indicada para o leitor que começa a se preparar para os exames de certificação. A fim de auxiliá-lo ainda mais nessa tarefa, foram selecionados os temas mais abordados nos principais exames. De maneira complementar, esta obra, desde sua primeira edição, é também fonte de consulta para a execução das atividades relacionadas ao teste de software. 



QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Obtendo Qualidade de Software com o RUP

Abstract. This article describes what should be considered in the software development to achieve acceptable quality patterns. The article shows that quality software is something that should be considered in all time in the application life cycle. One of the features that can maximize the software’s quality level is the iterative and incremental development. Moreover, the failures of the waterfall development process and the show and description of the Rational Unified Process (RUP)’s features will be approached.

Resumo. Este artigo descreve o que deve ser levado em consideração no desenvolvimento de software para atingir padrões de qualidade aceitáveis. O artigo mostra que a qualidade de software é algo que deve ser levado em consideração em todo momento do ciclo de vida do aplicativo. Uma das características que podem elevar o nível de qualidade do software é o desenvolvimento iterativo e incremental. Além disso, são abordadas as falhas do processo de desenvolvimento em cascata e a apresentação e descrição das características do Rational Unified Process (RUP).




1. Introdução

A cada dia que passa, as organizações se tornam mais dependentes dos sistemas de informação. Atualmente, não apenas sistemas que podem colocar a vida de pessoas em risco são considerados sistemas de missão crítica. Hoje, os sistemas de informação de muitas empresas são qualificados como de missão crítica, pois podem gerar enormes prejuízos financeiros caso haja eventuais problemas com os mesmos.

A atividade de desenvolvimento de software possui um alto grau de risco. Essa atividade já gerou grandes prejuízos no passado e continua gerando. Atualmente, muitos projetos de desenvolvimento de software são iniciados e não são terminados, e outros são terminados consumindo prazos e orçamentos bem acima do que foi estipulado no início do projeto. Além disso, muitos produtos desenvolvidos possuem um nível muito baixo de qualidade.

Conforme [Kruchten 2003], um produto de qualidade deve ter ausência de defeitos e, principalmente, deve atender aos propósitos desejados. Alguma coisa com qualidade deve fazer o que as pessoas querem que ela faça. Se alguma coisa é livre de defeitos, mas não faz o que as pessoas querem que ela faça, essa coisa é um produto desnecessário.

A qualidade de software não pode ser avaliada de maneira isolada. Softwares são desenvolvidos pelas organizações através de procedimentos. Um método pobre ou a ausência de uma metodologia pode ser a causa da baixa qualidade. Sendo assim, a avaliação da qualidade está diretamente relacionada com a qualidade de processos e metodologias utilizadas.

2. Metodologias de Desenvolvimento

Metodologias de desenvolvimento e estruturas de avaliação de processos podem ser comparadas sob duas dimensões: de um lado, temos o vértice pouca formalidade / muita formalidade e de outro, o método cascata / método iterativo, exemplificado através da Figura 1.


Figura 1: Mapa de processos

Os processos com pouca formalidade produzem o mínimo de documentação possível e procedimentos de trabalho bastante informais. Os formais possuem maior documentação, mantém o histórico dos artefatos gerados e possuem gerenciamento de mudanças.
O método cascata é um procedimento linear, onde a integração e os testes são feitos no fim do ciclo de desenvolvimento. O método iterativo é guiado pelo risco, ou seja, é voltado para a eliminação e minimização de riscos. A implementação da arquitetura, a integração e os testes são realizados desde o início do ciclo de vida do aplicativo.

2.1 Método Cascata

Esse método, também conhecido como seqüencial, ou linear, foi utilizado por muitos anos e ainda é utilizado. Segundo [Kroll e Kruchten 2003], esse processo se baseia nos seguintes passos:
  • Entender completamente o problema a ser resolvido, seus requisitos e suas restrições;
  • Projetar uma solução que atenda todos os requisitos e restrições. Examinar o projeto cuidadosamente e ter certeza que todas as parte interessadas concordam que essa é a solução certa;
  • Fazer a implementação do projeto, usando as melhores técnicas de engenharia;
  • Verificar se a solução atende aos requisitos estabelecidos;
  • Distribuir o produto.

Esse processo é similar à forma a qual pontes e edifícios são construídos. Algumas coisas devem ser feitas dessa maneira. Em um projeto com dois meses de duração, essa metodologia poderia ser usada. Mas normalmente, softwares não devem ser desenvolvidos dessa forma.

2.2 Método Iterativo e Incremental

O método iterativo foi criado para superar as dificuldades impostas pelo modelo cascata. Já que o modelo cascata pode ser usado com sucesso em projetos pequenos, onde o domínio do problema é bem conhecido, a solução encontrada foi dividir grandes projetos em projetos menores.
Dessa maneira, alguns requisitos e alguns riscos podem ser identificados, um projeto pode ser realizado, uma implementação pode ser construída para esse projeto, validada e testada. Esse processo se repete com outras partes do sistema até que o sistema inteiro seja terminado. Isso é chamado de modo iterativo.

Em cada pequena parte do sistema é feita uma iteração. A iteração segue o modelo seqüencial tradicional, com identificação de necessidades, análise, projeto, implementação e testes.
A cada iteração o sistema é incrementado até que o ciclo de desenvolvimento do aplicativo termine. Nesse ponto, um novo ciclo de desenvolvimento pode ser iniciado.

A maneira de desenvolver projetos através de várias iterações que vão incrementando o projeto até que se chegue a um objetivo é chamada de modo iterativo e incremental. Atualmente esse paradigma de desenvolvimento é bem aceito e vem sendo utilizado por várias metodologias de desenvolvimento de software.

3. O Rational Unified Process

Conforme [Kroll e Kruchten 2003], podemos ter três definições para o Rational Unified Process (RUP):
  • O RUP é uma maneira de desenvolvimento de software que é iterativa, centrada à arquitetura e guiada por casos de uso. É descrita em vários livros e artigos. Uma das maiores fontes de informações é o próprio produto IBM RUP [1], que contém guias detalhados, exemplos e modelos cobrindo todo o ciclo de vida do software;
  • O RUP é um processo de engenharia de software bem definido e bem estruturado. O RUP define claramente quem é responsável pelo que, como as coisas devem ser feitas e quando fazê-las. O RUP também provê uma estrutura bem definida para o ciclo de vida de um projeto RUP, articulando claramente os marcos essenciais e pontos de decisão;
  • O RUP é também um produto de processo que oferece uma estrutura de processo customizável para a engenharia de software. O produto IBM RUP suporta a customização e autoria de processos, e uma vasta variedade de processos, ou configuração de processos, podem ser montadas nele. Essas configurações do RUP podem ser criadas para suportar equipes grandes e pequenas, e técnicas de desenvolvimento disciplinadas ou menos formais. O produto IBM RUP contém várias configurações e visões de processos prontas que guiam analistas, desenvolvedores, testadores, gerentes de projeto, gerentes de configuração, analistas de dados, e outros membros da equipe de desenvolvimento em como desenvolver o software. Ele tem sido utilizado por muitas companhias em diferentes setores da indústria.

O RUP utiliza a Linguagem Unificada de Modelagem (UML [2]) para especificar, modelar e documentar artefatos. A UML é um padrão definido pelo OMG [3] e ter se tornado o padrão empresarial para a modelagem orientada a objetos [4] .

Por ser flexível e configurável, o RUP pode ser utilizado em projetos de pequeno, médio e grande porte. [Kroll e Kruchten 2003] mostra como o RUP pode ser utilizado em um projeto de uma semana com uma equipe de uma pessoa.

3.1 Os Princípios do RUP

Não existe uma maneira exata de aplicar o RUP, pois ele pode ser aplicado de várias formas e será diferente em cada projeto e organização. Porém, existem alguns princípios que podem caracterizar e diferenciar o RUP de outros métodos iterativos:
  • Atacar os riscos cedo e continuamente;
  • Certificar-se de entregar algo de valor ao cliente;
  • Focar no software executável;
  • Acomodar mudanças cedo;
  • Liberar um executável da arquitetura cedo;
  • Construir o sistema com componentes;
  • Trabalhar junto como um time;
  • Fazer da qualidade um estilo de vida, não algo para depois.

3.2 Elementos do RUP

O RUP possui cinco elementos principais: papéis, atividades, artefatos, fluxos de trabalho e disciplinas.
Um papel (ou perfil) define o comportamento e as responsabilidades de um determinado indivíduo ou grupo de indivíduos trabalhando como uma equipe. Papéis não são indivíduos e nem títulos de trabalho. Um indivíduo pode assumir vários papéis. São exemplos de papéis:
  • Analista de sistema – O indivíduo que assume este papel coordena a obtenção dos requisitos e a modelagem dos casos de uso identificando funcionalidades do sistema e estabelecendo limites do sistema;
  • Projetista – Esse indivíduo define responsabilidades, operações, atributos, relacionamentos de uma ou mais classes e determina como elas devem ser ajustadas para serem implementadas no ambiente;
  • Projetista de testes – Responsável pelo planejamento, projeto, implantação e avaliação de testes, incluindo a geração de plano e modelo de teste, implementando procedimentos de testes e avaliando a abrangência dos testes, resultados e a efetividade.

Uma atividade é uma unidade de trabalho que um indivíduo executa quando está exercendo um determinado papel e produz um resultado importante para o contexto do projeto. Cada atividade pode ser dividida em passos. São exemplos de atividades:

  • Planejar uma iteração: realizada pelo papel gerente de projeto;
  • Encontrar casos de uso e atores: realizada pelo papel analista de sistemas;
  • Rever o projeto: realizada pelo papel revisor de projeto;
  • Executar um teste de performance: realizado pelo papel testador de performance.

Um artefato é um pedaço de informação que é produzido, modificado ou utilizado em um processo. Os artefatos são os produtos de um projeto. São as coisas produzidas durante o desenvolvimento do projeto. Artefatos são utilizados como entradas de atividades e são produzidos como saída.
Os artefatos podem ter várias formas:
  • Um modelo, como um modelo de caso de uso, um modelo de projeto;
  • Um elemento de um modelo, como uma classe, um caso de uso, um sub-sistema;
  • Um documento, como um caso de negócio, glossário, visão;
  • Código fonte;
  • Executáveis.
A enumeração de atividades, papéis e artefatos não constituem um processo. É necessário saber a seqüência do desenvolvimento das atividades para que possam ser produzidos artefatos de valor para o projeto. Um fluxo de trabalho [5] é uma seqüência de atividades que são executadas para a produção de um resultado valioso para o projeto. Fluxos de trabalho podem ser representados por diagramas de seqüência, diagramas de colaboração e diagramas de atividades da linguagem UML. O RUP utiliza três tipos de fluxos de trabalho:
  • Fluxos de trabalho principais, associados com cada disciplina (figura 2);
  • Fluxos de trabalho de detalhe, para detalhar cada fluxo de trabalho principal (figura 3);
  • Planos de iteração, que mostram como a iteração deverá ser executada.

Figura 2: Fluxo de trabalho: requisitos


Figura 3: Detalhamento de fluxo de trabalho: analisar o problema

Uma disciplina é uma coleção de atividades relacionadas que fazem parte de um contexto comum em um projeto. As disciplinas proporcionam um melhor entendimento do projeto sob o ponto de vista tradicional de um processo cascata. A separação das atividades em disciplinas torna a compreensão das atividades mais fácil, porém dificulta mais o planejamento das atividades. O RUP possui nove disciplinas, divididas em disciplinas do processo e de suporte. As disciplinas de processo são: modelagem de negócios, requisitos, análise e projeto, implementação, teste e distribuição. As de suporte são: configuração e gerenciamento de mudanças, gerenciamento de projeto, e ambiente.


Figura 4: Arquitetura geral do RUP

Conforme mostra a figura 4, o RUP possui duas dimensões:
  • O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo à medida que se desenvolve. Representa o aspecto dinâmico do processo. É expresso em termos de fases, disciplinas e marcos.
  • O eixo vertical representa as disciplinas, que agrupam as atividades de maneira lógica, por natureza. Representa o aspecto estático do processo. É descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo.

3.3 O Ciclo de Vida de um Projeto RUP


O ciclo de desenvolvimento no RUP possui quatro fases: iniciação [6] , elaboração, construção e transição. Cada uma é concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais, como é mostrado na figura 5.


Figura 5: As fases e os marcos de um projeto
O ciclo de desenvolvimento termina com uma versão completa do produto de software. As fases definem estados do projeto, que são definidos por riscos que estão sendo mitigados ou questões que precisam ser respondidas.

A fase de iniciação, foca no tratamento de riscos relacionados com o caso de negócio. Deve ser verificado se o projeto é viável e se é financeiramente possível.

Na fase elaboração, o foco deve ser nos riscos técnicos e arquiteturais. O escopo deve ser revisado e os requisitos devem estar mais compreendidos.

Durante a construção, a atenção será voltada para os riscos “ lógicos ”, e a maior parte do trabalho será realizada.

Na fase de transição, serão tratados os riscos associados com a logística de distribuição do produto para a base de usuários.

Embora varie muito em empresas e projetos diferentes, um ciclo de desenvolvimento para um projeto de tamanho médio, possui uma distribuição de esforço e programação como é apresentado na tabela 1 e na figura 6.

Tabela 1. Distribuição de esforço e programação em projetos de médio porte.


Figura 6: Distribuição de esforço e programação em projetos de médio porte.

Conforme descrito na documentação do RUP, cada passagem pelas quatro fases gera uma geração do software. A menos que o produto "desapareça", ele irá se desenvolver na próxima geração, repetindo a mesma seqüência de fases de iniciação, elaboração, construção e transição. Esses ciclos subseqüentes são chamados de ciclos de evolução. A cada ciclo, são produzidas novas gerações.

Os ciclos de evolução podem ser disparados por melhorias sugeridas pelos usuários, mudanças no contexto do usuário, mudanças na tecnologia subjacente, reação à concorrência e assim por diante. Normalmente, a menos que ocorram mudanças significativas do produto ou da arquitetura, os ciclos de evolução têm fases de Iniciação e Elaboração bem menores, pois a definição e a arquitetura básicas do produto foram determinadas por ciclos de desenvolvimento anteriores.

4. Conclusão

Com a utilização de uma metodologia de desenvolvimento de software como o RUP, é possível obter:
  • Qualidade de software;
  • Produtividade no desenvolvimento, operação e manutenção de software;
  • Controle sobre desenvolvimento dentro de custos, prazos e níveis de qualidade desejados;
  • Estimativa de prazos e custos com maior precisão.

Apesar dos benefícios, deve-se ter a consciência que os benefícios não virão de maneira imediata. É necessário adquirir treinamento adequado, adaptação da metodologia no contexto ao qual ela será utilizada, apoio especializado para as equipes de desenvolvimento e tempo para a absorção da metodologia.

Mais informações a respeito do RUP podem ser obtidas no site do IBM RUP e também no site da comunidade IBM Rational. (IBM 2004).

Referências

Comunidade IBM RUP (2004) http://www-130.ibm.com/developerworks / rational / community, Novembro.
Fowler, Martin (2003) “ UML Distilled: A Brief Guide to the Standard Object Modeling Language ”, Addison Wesley, 3 ª Edição.
IBM Rational Unified Process Versão 2003.06.12.01. (2004) http://www-306.ibm.com/software/rational, Novembro.
IBM RUP (2004) http://www-130.ibm.com/developerworks/rational/products/rup,Novembro.
Kroll, P. e Kruchten P. (2003) “ The Rational Unified Process Made Easy: A Practitioner ' s Guide to the RUP ”, Addison Wesley.
Kruchten, P. (2003) “ The Rational Unified Process: An Introduction ”, Addison Wesley, 3 ª Edição.
Larman, Craig (2001) “ Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and the Unified Process ”, Prentice Hall, 2 ª Edição.
Object Management Group (2004) http://www.omg.org, Novembro.
Perrelli, Hermano (2004) “ Visão Geral do RUP ”. Centro de Informática, Universidade Federal de Pernambuco. http://www.cin.ufpe.br/~if717/slides/3-visao-geral-do-rup.pdf, Novembro.
[1] Após a compra da Rational pela IBM, o produto Rational Unified Process passou a se chamar IBM Rational Unified Process (IBM RUP).
[2] UML: Abreviatura do inglês Unified Modeling Language. [Fowler 2003] é uma ótima referência para esse assunto.
[3] OMG: Object Management Group.
[4] Consulte [Larman 2001] para informações sobre aplicação da UML para análise e projeto orientados a objeto
[5] O termo fluxo de trabalho vem do termo inglês workflow. Pode ser traduzido também como fluxo de atividade.
[6] Iniciação é a tradução do termo inglês “ inception ”. Esse termo é também traduzido como “ concepção ”.

Por: Ronaldo Rezende Vilela Luiz

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Qualidade de Software: Um Compromisso da Empresa Inteira

Qualidade de software é um assunto que muito se discute e pouco se pratica. Temos a impressão, às vezes, que o discurso da qualidade não passa disso mesmo: discurso. Desde o início dos tempos do desenvolvimento de software temos problemas de qualidade que não só ainda não foram resolvidos como ainda parece que se agravam a cada nova geração tecnológica. Prazos estourados, baixa produtividade, custos altos e qualidade deficiente parecem ser um fantasma que novas tecnologias não são nunca capazes de exorcizar.






Para abordarmos o problema da qualidade, é necessário, evidentemente, que tenhamos claro em primeiro lugar o que entendemos por qualidade de software. Utilizando uma simplificação, poderíamos dizer que todos os problemas de qualidade de software caem em uma das seguintes duas categorias: falhas na Qualidade de Conformidade e falhas na Qualidade de Desempenho.

Qualidade de Conformidade diz respeito à aderência do produto à finalidade para a qual foi construído. No nosso caso, estamos falando de software que dá ao seu usuário a funcionalidade de que ele precisa. Como é amplamente sabido, este tipo de qualidade é mosca branca na nossa área. Por sua vez, Qualidade de Desempenho refere-se à capacidade do produto em apresentar consistentemente a funcionalidade desejada. Em termos de software, isto quer dizer boa performance, ausência de bugs, tolerância a falhas de infra-estrutura (hardware), tolerância a erros do usuário etc.

Por quê deveríamos nos preocupar com a qualidade de software? Existem algumas razões óbvias. Ninguém gosta de software com bugs. Bugs podem causar prejuízos que variam desde a mera necessidade de reiniciar o sistema operacional até à perda de satélites de milhões de dólares (como o Clementine, um satélite construído para designar alvos, no projeto Guerra nas Estrelas, o qual, quando recebeu um comando para mirar um ponto na superfície lunar, ativou os foguetes direcionais e ficou girando até acabar o combustível...). Bugs podem fazer um banco perder milhões e perder a confiança dos clientes ou parar por horas uma companhia telefônica, impedindo a realização de telefonemas interurbanos (como já ocorreu com a AT&T). Os problemas de qualidade tendem a aumentar com o uso maciço das tecnologias de processamento distribuído, onde é muito mais difícil prever o que pode dar errado...

Mas não é só isso. Os esforços pela qualidade na indústria automobilística provaram a tempos que a qualidade não tem custo. Ao contrário do que muita gente pensa, os investimentos em qualidade pagam-se em pouco tempo. O aumento de qualidade sempre é acompanhado por aumento de produtividade e redução de custos na forma de menos retrabalho e menor índice de refugo. Isto sem falar na maior satisfação do cliente, que pode ser refletida muitas vezes em maior participação no mercado. Assim, o axioma que diz que investimentos em qualidade dão lucro é plenamente aceito pela indústria de manufatura. Infelizmente, não é fácil encontrar quem acredite nisto na área de software.

No entanto, as empresas que entenderam que não existem razões para acreditar que este axioma não funciona com software, puderam experimentar os benefícios da aplicação das técnicas de qualidade -presentes na Engenharia de Produção- na Engenharia de Software (leia a entrevista com Watts Humphrey nesta edição). Em um artigo na edição de março, apresentei e discuti o modelo CMM de qualidade de software, desenvolvido pela SEI (Software Engineering Institute). Comentei, naquela ocasião, que os esforços em melhoria da qualidade não podem ter seu foco no produto apenas (fazer software melhor), mas principalmente no processo (fazer melhor o software).

A SEI apresentou, em um estudo recente, alguns números impressionantes relativos a melhorias de desempenho em empresas que investiram em qualidade seguindo os passos do CMM. O aumento médio de produtividade foi em média 35% por ano, enquanto o número de bugs encontrados em software após a entrega foi reduzido em 39% ao ano, chegando em algumas empresas a 95%! A relação custo/benefício, comparando os investimentos em qualidade com o retorno financeiro em termos de redução de custos via aumento de produtividade e redução de retrabalho e manutenção, ficou em média em 5 para 1, chagando a 9 para 1 em alguns casos. Isto é, para cada dólar investido em qualidade, estas empresas economizaram 5 dólares em média. Qualquer pessoa que conheça o Retorno sobre o Investimento (ROI) típico no mercado poderá confirmar que um ROI de 5:1 não se encontra todo dia...

Por quê, então, existe tão pouco investimento em qualidade nas organizações típicas de desenvolvimento de software? Existe aí um problema cultural de grandes dimensões e difícil de superar. Infelizmente, a cultura atual de desenvolvimento de software baseia-se em crenças absurdas que se espalham por todos os níveis da organização. Nos níveis mais altos, isto é, na administração de informática, acredita-se que os investimentos típicos em qualidade de software (uso de processos padronizados de gerência de projetos, uso de metodologias de desenvolvimento, treinamento contínuo dos desenvolvedores, uso de métricas, estabelecimento de procedimentos eficazes de controle de qualidade de software etc.) são caros demais, são mera burocracia e, principalmente, causam o alongamento dos prazos de desenvolvimento. Esta crença errônea é agravada pela limitada cultura de informática dos usuários e clientes, que tendem a pressionar por prazos completamente fora da realidade. Não passa pela cabeça de um alto executivo da GM ou da Volkswagen exigir de seus engenheiros a construção de uma nova fábrica de caminhões em três meses. Em nossa área, porém, é mais ou menos a isto que estamos submetidos dia após dia. No dizer de DeMarco e Lister (Peopleware, 1987), "regularmente pondo o processo de desenvolvimento sob extrema pressão de tempo e depois aceitando produtos de baixa qualidade, a comunidade dos usuários de software mostrou seu verdadeiro padrão de qualidade".

O desenvolvedor, por outro lado, além de acreditar nestas mesmas coisas, não aceita que ninguém lhe diga como deve fazer seu trabalho, afirmando que padronização de procedimentos e uso de best practices seriam uma violência à sua "criatividade". Se levarmos em conta que a maioria dos desenvolvedores não foi formada em Engenharia de Software e aprendeu tudo o que sabe "na marra", fica difícil acreditar nesta afirmação. Afinal, quem de nós confiaria sua saúde a um "médico" que aprendeu sozinho a profissão (fora da faculdade) e que têm solene desprezo pelos manuais de medicina? O caso é que a maioria de nós desenvolvedores não sabe desenvolver software, e deveríamos ter a humildade de aprender com quem já aprendeu.

Existem erros graves de percepção subjacentes a estas crenças. O primeiro deles é em relação aos prazos. O executivo de informática costuma falhar em perceber que o tal "aumento nos prazos" é geralmente relativo aos prazos prometidos, e não aos efetivamente cumpridos. Como raramente são registrados os prazos reais, ao final dos projetos, o que fica no inconsciente do gerente como regra de referência são os prazos que ele costuma prometer, não os que ele cumpre! E não é preciso ter décadas de experiência na área para se saber que o cumprimento de cronogramas é a exceção, e não a regra.

É claro que a introdução de procedimentos visando o aumento da qualidade pode causar, num primeiro momento, uma pequena redução de produtividade, devido à curva de aprendizado. Isto acontece com a introdução de qualquer nova tecnologia em um ambiente de produção. De forma geral, a introdução de novas tecnologias segue o gráfico da figura 1. O grande problema é que estes projetos acabam sendo abandonados no ponto mínimo da curva, fazendo com que os recursos investidos se percam e baixando o moral dos envolvidos. Mesmo assim, na prática, tenho observado (e conversado com colegas também) que em ambientes de desenvolvimento caóticos (a grande maioria), qualquer esforço de melhoria, por simples que seja, causa rapidamente melhorias de produtividade. A "barriga" da curva é mínima ou mesmo inexistente. O simples esforço por melhorar a documentação do projeto e as verificações de qualidade desde o início reduzem significativamente o tempo gasto em testes e retrabalho, fazendo com freqüência com que mesmo o primeiro projeto em que se aplicam estas técnicas acabe sendo completado antes do que teria terminado sem estas mesmas técnicas, além manter alto o moral dos envolvidos.

A médio prazo, então, não há o que se discutir. Software com mais qualidade sofre menos manutenção, e as manutenções necessárias são feitas muito mais rapidamente. Isto libera recursos para o desenvolvimento de software novo, reduzindo o backlog e acelerando o desenvolvimento; mais software pode ser reutilizado; e o processo de desenvolvimento pode ser continuamente melhorado para aumentar sua eficiência (leia-se prazos menores).

Para um esforço de melhoria de qualidade de software em uma organização funcionar, toda a organização deve estar comprometida. Especificamente, são fundamentais o compromisso da alta administração (de informática e usuária) e dos desenvolvedores, incluindo aí seus gerentes imediatos.

Compromisso da alta administração não é apenas uma expressão bonita. Este compromisso tem que se materializar em ações concretas. São necessários recursos para processos de melhoria (dinheiro e pessoas). É necessário "bancar" o esforço quando surgem crises. É necessário colocar em prática processos que garantam que pressões irrealistas dos usuários não esfumacem a iniciativa. É necessário treinamento e ampla comunicação. Enfim, são necessárias ações que somente executivos em nível de diretoria ou acima podem realizar.

Em um esforço de melhoria da qualidade, o primeiro ponto é colocar em ordem o processo de planejamento e estimativas realistas de prazos. Assim, se o gerente de equipe não souber ou não quiser fazer este planejamento, nada vai acontecer. Para garantir uma negociação realista com os usuários, a alta administração tem que garantir que os prazos estimados pelo gerente sejam aceitos pelos usuários. Os desenvolvedores, por usa vez, tem que comprometer-se a cumprir estes prazos, para que a credibilidade das estimativas junto aos usuários cresça.

Dado que a alta administração garante prazos realistas e dá condições para que os desenvolvedores melhorem suas práticas, é responsabilidade destes últimos aplicarem no seu trabalho diário os conhecimentos adquiridos em treinamentos. Também precisam comprometer-se em buscar continuamente mais conhecimentos, através de leitura de revistas técnicas, livros, pesquisa na Internet etc. Afinal de contas, trata-se de melhorar o processo de engenharia e, se os próprios engenheiros não melhorarem suas práticas de trabalho, nada acontecerá. Em suma, os desenvolvedores devem melhorar seu trabalho, e a administração deve dar as condições para que isto aconteça.

Para ilustrar o que entendo por comprometimento gerencial, apresento um caso real onde estes conceitos foram aplicados.

Em uma empresa em que trabalhei, do setor financeiro, a questão de qualidade era crítica. Existia uma carga noturna de processamento batch em mainframe que era volumosa e sensível a problemas. Um programa que parasse, durante a noite, no caminho crítico da produção levava a atrasos enormes no final do processamento batch, entrava pelo dia adentro e não permitia a entrada dos sistemas on-line, impedindo ou dificultando muito a operação normal e o atendimento aos clientes. A maioria dos abends durante a noite era causa por falhas de planejamento, testes mal feitos ou falta de coordenação entre a equipe de desenvolvimento/manutenção e outra áreas chave tais como a produção ou a administração de bancos de dados. Para resolver o problema, foi instituído um processo de controle de manutenções, que exigia da equipe um planejamento detalhado, teste e coordenação com as áreas envolvidas. Nenhum programa poderia entrar em produção sem que todos os passos estabelecidos fossem cumpridos. Havia uma área especialmente encarregada de verificar o cumprimento do planejamento, cujo gerente respondia diretamente para o diretor de informática, evitando que pressões do gerente de desenvolvimento pudessem fazer com que se "passasse por cima" do processo estabelecido. Os desenvolvedores foram treinados no processo e foram-lhes mostrados os benefícios esperados. A solicitação de manutenção de prioridade normal tinha de ser apresentada com quase duas semanas de antecedência à entrada em produção dos programas alterados. Existia também a possibilidade de implantações de maior prioridade acontecerem em um período inferior a estas duas semanas.

Apesar de todas estas providências, este processo não funcionou num primeiro momento. Os usuários continuaram pressionando os analistas por prazo e estes também não tinham o hábito de planejar as manutenções. Quando o usuário pedia algo, a equipe simplesmente sentava e fazia. As exceções eram a regra e o processo praticamente não era cumprido. Solicitações de manutenção para o mesmo dia ou o dia seguinte eram aceitas sem maiores problemas e, freqüentemente programas eram alterados no ambiente de produção sem mesmo passarem pela formalidade do processo. Não será surpresa para o leitor saber que os problemas de abends em produção continuaram ocorrendo com a mesma freqüência.

Percebendo este problema, o diretor de informática, com suporte explícito do vice-presidente administrativo e tácito do presidente da empresa, estabeleceu que absolutamente todas as manutenções deveriam passar pelo processo. Além disso, os desenvolvedores e seus gerentes imediatos foram informados de que teriam de explicar muito bem cada abend em produção. Por outro lado, também foram encorajados a resistir às pressões dos usuários. Estes últimos foram educados a respeito do novo processo, e se deixou claro que eles, usuários, teriam que explicar muito bem por quê suas solicitações exigiam os prazos curtos pedidos. A área de administração de mudanças recebeu poder para barrar qualquer solicitação de manutenção que entendesse estar fora dos padrões de qualidade, adiando as implantações em uma semana. Qualquer confronto de prazo entre esta gerência e a de desenvolvimento/manutenção seria levado para a decisão do próprio diretor de informática, que ouviria as razões do usuário. Todo abend em produção passaria a ser documentado por escrito, tendo a equipe de desenvolvimento que explicar suas causas e o que seria feito para evitar a recorrência. Estatísticas começaram a ser coletadas provando uma correlação positiva entre abends e manutenções "urgentes", isto é, ficou comprovado que a maioria dos problemas em produção eram causados por programas alterados em manutenções "de um dia para o outro". Níveis de erros em produção e de manutenções de prioridade "urgente" versus prioridade normal (duas semanas) eram coletados e divulgados, separados por equipe. Gerentes de equipes com altas taxas de erros e manutenções "urgentes" tinham que explicar as razões. Usuários de nível médio (um gerente na área de contabilidade, por exemplo) tinha de explicar ao seu diretor por que a sua manutenção era urgente, para que este pudesse por sua vez explicar ao diretor de informática, que liberaria a manutenção se esta fosse realmente necessária.

É claro que, no início, houve uma chiadeira geral. Ouviam-se gritos de "terrorismo" e "burocracia" por todos os corredores. Usuários queixavam-se da "urgência" de suas manutenções (na maioria não tão urgentes assim, ou tornadas urgentes por não se ter feito planejamento no momento certo, com a devida antecedência). Desenvolvedores e seus gerentes imediatos não gostaram de ter a qualidade de seu trabalho medida e divulgada publicamente. Mas a alta administração foi em frente e não se deixou intimidar pela gritaria.

Qual foi o resultado? Com o tempo, usuários e desenvolvedores aprenderam a separar o "urgente" do urgente. Tanto os usuários quanto os desenvolvedores aprenderam a planejar melhor as manutenções. Prazos realistas passaram a ser estabelecidos. Alterações em programas passaram a ser melhor testadas. Todas as áreas técnicas e funcionais passaram a ser sistematicamente envolvidas em cada manutenção, evitando problemas de coordenação. Em pouco tempo, as manutenções planejadas passaram a apresentar taxas baixíssimas de erros em produção. Os atrasos de processamento, que aconteciam em mais da metade dos dias do mês, passaram a ocorrer apenas em dois ou três dias por mês. A médio prazo, a relação entre manutenções urgentes e planejadas foi ficando cada vez menor.



Afinal, diante das evidências, todo mundo teve de concordar que a coisa tinha melhorado muito. A empresa como um todo beneficiou-se com a maior disponibilidade dos sistemas e melhor serviço ao cliente. A cultura nascente de planejamento levou ao aumento de produtividade e a um gerenciamento de prioridades muito mais eficaz. Os usuários descobriram que o "day after" de cada manutenção não precisava ser a roleta-russa a que estavam acostumados. E os desenvolvedores aprenderam que trabalhar de forma planejada lhes rendia mais noites de sono não-interrompido (havia programadores que eram acordados à noite três vezes por semana, na maioria das vezes exigindo sua presença imediata para consertar programas "abendados") e a possibilidade de ir para casa no final do expediente, ao invés de às 11 horas da noite, como era a regra.

Observe-se que a empresa em questão é uma multinacional da área financeira, isto é, está imersa em um ambiente onde as mudanças acontecem muito depressa e a toda hora. Mudanças de mercado, mudanças de legislação, mudanças em diretrizes da matriz surgem o tempo todo. Mesmo assim, o processo descrito foi um sucesso total, e chegou-se a um nível de serviço invejável, sendo que verificou-se que apenas algo em torno de 10% das manutenções realmente necessitavam ser implementadas com urgência (prazo inferior duas semanas). Desta forma, se um processo como este pôde funcionar em uma organização com estas características, pode funcionar em qualquer ambiente empresarial.

Este exemplo deveria fazer com que gerentes de informática e usuários percebessem que o aumento da qualidade do software depende muito menos do uso de novas tecnologias do que do uso de práticas gerenciais adequadas. Treinar desenvolvedores e dar-lhes tempo para absorver o que aprenderam é fundamental. Impedir os usuários de colocar prazos absurdos para seus pedidos é fundamental. Alocar recursos (tempo, dinheiro e pessoas em dedicação integral) para trabalhar na melhoria dos processos de software é fundamental. É obvio que os desenvolvedores que estão construindo software não terão tempo para definir processos, metodologias, medir qualidade, definir, coletar e analisar métricas etc. Atribuir esta responsabilidade a quem está desenvolvendo software é a melhor garantia de que nada vai acontecer. Se queremos qualidade, temos que investir nela. Mas tendo a certeza de que este é um investimento que se paga muitas vezes. E em pouco tempo.

Publicado em Junho de 1997 na Developers Magazine.

Este artigo está apresentado aqui tal como foi enviado ao editor, podendo, devido ao processo de revisão da revista, estar ligeiramente diferente de sua versão publicada.

Ó Copyright por Átila Belloquim. Este documento pode ser reproduzido no todo ou em parte, desde que citada a fonte.

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin: