Isto é um paradoxo, que tem colocado usuários e desenvolvedores de lados opostos em um processo que tem a mesma finalidade: o software. Desta forma, este artigo que será visto em duas partes, tem o propósito de caracterizar e levantar questões relevantes em relação ao usuário de software no seu processo de desenvolvimento.

Introdução

O processo de desenvolvimento de software tem passado por profundas transformações nestes últimos trinta anos. Apesar das técnicas e ferramentas terem evoluído, tais como a Unified Modelling Language (UML), linguagens orientadas a objetos, entre outros, existe um elemento que tem sido marginalizado neste processo até os dias de hoje, o usuário.

O usuário, interessado no desenvolvimento de um software, participa como elemento paradoxal dentro deste processo. Pode-se dizer que: o usuário contrata o serviço referente ao desenvolvimento, mas não sabe exatamente o que quer. Por outro lado, pode-se afirmar que ele entende do seu negócio ou empresa como ninguém, mas não sabe se expressar. Qualquer programador ou desenvolvedor que tenha trabalhado em projetos de desenvolvimento de software sabe que as situações anteriores são verdadeiras. Sabe ainda que os pesos delas em um processo de construção de um software é alto, chegando ao ponto de finalizar prematuramente o desenvolvimento.

Portanto, este artigo tenta caracterizar o usuário de software que participa do processo de desenvolvimento e não o que utiliza o software após a sua finalização. Também aponta características e prováveis soluções que assegurem ao usuário mais confiança na equipe que desenvolve o projeto.

O usuário

O usuário é parte chave do processo de desenvolvimento e uso do software. Componente da relação software-usuário, encontra-se na literatura a definição do primeiro. Segundo Fernandes (2005), software é uma sentença computável para a qual existe uma máquina capaz de executá-la. Outra definição, afirma que software é algo abstrato que tem a finalidade de satisfazer os desejos humanos pessoais ou coletivos. As soluções em software podem satisfazer as necessidades dos indivíduos bem como os meios de produção. O caráter abstrato do software o torna intangível, ou seja, sua produção não envolve matérias-primas consumíveis ao longo do processo produtivo, portanto, geralmente é classificado como serviço (ROSELINO, 2006).

Por outro lado, o que é o usuário? Como ele interage com a produção do software e qual sua relação com o mesmo? São perguntas que por mais que se pesquise não se encontram respostas acadêmicas adequadas e, também, não se encontram estudos relativos ao comportamento de usuários em relação aos processos de desenvolvimento de software.

Neste momento, apresenta-se uma definição: pessoa ou algo com cognição que interaja com um sistema computacional, com propósitos bem definidos. Esta definição serve para definir usuário de software produzido, manufaturado. Define-se também, o usuário para o processo de desenvolvimento: pessoa ou algo com cognição que forneça e contribua com as funcionalidades necessárias para que um software seja desenvolvido, participando durante todo o processo. Essas definições são importantes para o correto entendimento deste artigo, já que, a segunda definição é a que caracteriza o usuário discutido.

A seguir, apresenta-se uma série de fatos que demonstram que no processo de engenharia de software, suas atividades, entre outros, visualiza-se o usuário como um artefato e não como um elemento importante no processo.

O comportamento da indústria de software

Primeiramente, antes de se apresentar o comportamento da indústria de software, deve-se apresentar uma informação muito curiosa a respeito da eficiência dos projetos de software. Segundo o Instituto Standish Group (ISG) (1994), utilizando uma amostra de 365 companhias de desenvolvimento de sistemas, com um total de 8.380 aplicações, obtiveram-se os seguintes números: 31% dos softwares foram cancelados antes do termino do projeto; 53% dos softwares foram finalizados com custo selevados e com um prazo muito maior do que aqueles combinados em seu início. Para complementar, Jones (2001) em seu estudo sobre grandes projetos de software, afirma que o insucesso na área de desenvolvimento desses projetos é de aproximadamente 85%.

Segundo o ISG (1994), como pode ser observado abaixo, os principais problemas referentes ao desenvolvimento de projetos de software estão distribuídos da seguinte forma:

  Fatores críticos para um projeto de software      %
  1. Falta de especificação dos usuários           12,8
  2. Requisitos incompletos                        12,3
  3. Mudança de requisitos                         11,8
  4. Falta de apoio executivo                       7,5
  5. Tecnologia imatura                             7,0
  6. Falta de recursos                              6,4
  7. Expectativas irreais                           5,9
  8. Objetivos obscuros                             5,3
  9. Tempo irreal                                   4,3
  10. Tecnologia nova                               3,7
  11. Outros                                       23,0

Tabela 1: Fatores que influenciam os riscos de um projeto de software.

Os dados apresentados na tabela 1 apontam que a falta de especificação dos usuários é o elemento de maior risco dentro de um projeto de software. Além disso, se for considerado que os elementos dois e três da referida tabela tem como participante o usuário, pode-se afirmar que os riscos são elevados a 36,9% de todos os fatores que representam riscos no projeto de desenvolvimento de software.

Apesar da indústria de software saber da importância dos usuários no processo de desenvolvimento, só atualmente esta passou a dar mais importância ao mesmo. Primeiro, a mesma teve que resolver problemas referentes à infra-estrutura de ferramentas e processos relacionados aos projetos.

Como exemplo dessa preocupação cita-se, a criação da UML. Segundo Jacobson (2000), na metade da década de 70 existia uma grande quantidade de métodos de desenvolvimento orientados a objetos, enquanto que as aplicações a serem construídas se tornavam mais complexas. Exatamente nesta época, três metodologias entre as existentes se destacaram: o Objectory de Booch, o OOSE de Jacobson e o OMT de Rumbaugh. Já na década de 1990, indústrias como a Digital Equipment, Hewlett-Packard, Intel, entre outras, contribuíram como colaboradoras para o surgimento de uma linguagem de modelagem única e padrão, que resultou no surgimento da UML.

Ao mesmo tempo em que o ferramental evoluía, evoluíram também as normas para a área de desenvolvimento de software. O Instituto de engenharia elétrica e eletrônica (IEEE) definiu um conjunto de boas práticas, materializadas por meio do livro SWEBOK. O mesmo define uma coleção de áreas de conhecimentos dentro da engenharia de software, tal como apresentado na tabela 2.

  Requerimentos de software
  Desenho de software
  Construção de software
  Testes de software
  Manutenção de software
  Gerência de configuração de software
  Gerência de engenharia de software
  Processo de engenharia de software
  Métodos e ferramentas de engenharia de software
  Qualidade de software

Tabela 2: áreas de conhecimento do SWEBOK.

As áreas de conhecimento dentro do SWEBOK estão altamente inter-relacionadas e, dentro de cada área, existe uma coleção de sub-áreas que devem ser abordadas. Por exemplo, na área de conhecimento referente a requisitos de software, existe as seguintes sub-áreas: fundamentos de requisitos de software; processo; levantamento; análise; especificação, e; validação de requisitos. (SWEBOK, 2004).

Segundo Kontonya (1998) um requisito é uma declaração de um serviço ou restrição que deve ser implementada em um sistema. Desta forma, observa-se que existe dentro da engenharia de software a preocupação com o processo, como se observa na estrutura matricial e complexa apresentada no SWEBOK. E, o principal fornecedor de requisitos é o usuário que, neste contexto, não é o centro do processo de levantamento e análise de requisitos, mas parte dele.

Outra área de interesse no SWEBOK é a qualidade de software, já que também, está relacionada ao usuário. Carvalho (2001) afirma que a qualidade de um software é contabilizada pela quantidade de requisitos que são satisfeitos no processo de construção do mesmo. Novamente, quem atesta essa qualidade é o usuário. Mas, da mesma forma que na área de requisitos, este se apresenta como parte do processo.

Como a engenharia de requisitos acontece em um ambiente de desenvolvimento de software, Pohl (1994), apresenta os seguintes aspectos que afetam esta área:

• Métodos: análise estruturada ou orientada a objetos;
• Ferramentas: ferramentas para a representação dos requisitos;
• Aspectos sociais: o ambiente de trabalho da equipe de requisitos;
• Competência: diferença de capacitação das pessoas envolvidas no processo de requisitos;
• Restrições econômicas: limitador de recursos humanos, tempo, entre outros.

Observa-se que Pohl não inclui o usuário como elemento que afeta o levantamento, portanto, a preocupação incide sobre os elementos “internos” do processo de desenvolvimento de software, ou seja, analistas, programadores, ferramentas.

A indústria de software preocupa-se com ferramentas, métodos e normas da construção do software. Esse comportamento é conseqüência dos seguintes fatores:

1. é uma indústria nova, e;
2. está em pleno desenvolvimento de métodos e normas que automatize e garanta qualidade.

Apesar de estranho, o primeiro fator tem todo o fundamento. Se compararmos a arquitetura e a engenharia civil com a área de engenharia de software, observar-se-há muitas discrepâncias entre elas. A primeira que pode ser citada, refere-se à idade das ciências. A arquitetura e a engenharia civil estão acompanhando o desenvolvimento humano desde os tempos em que o homem se preocupou em estabelecer moradias, tanto que, os termos arquitetura romana, grega, são anteriores a existência de cristo. Da mesma forma pode-se falar da engenharia civil.

Ao contrário, a engenharia de software, como a conhecemos hoje, não tem mais do que trinta anos, surgiu no século XX, como produto da invenção do computador, criado durante as duas grandes guerras daquele século. Portanto, as metodologias de análise e projeto estão em processo de maturação.

Outra diferença entre arquitetura e engenharia civil e a engenharia de software está localizada nos insumos utilizados. As duas primeiras possuem insumos que conceitualmente estão bem formalizados e maduros, além de claro, serem tangíveis. Ao contrário, na engenharia de software, o insumo é abstrato e ainda não está maduro o suficiente para se “montar totalmente um software”. Para explicar melhor o fato, observem que, para se construir uma casa, deve-se utilizar tijolos, vigas, tintas, que estão todos manufaturados, facilitando o manuseio dos mesmos. Desta forma, o trabalho dos pedreiros está concentrado em “juntar” estes elementos e construir uma casa. Se o mesmo exemplo fosse transposto para a engenharia de software, poder-se-ia dizer que durante a construção, o pedreiro teria que inventar um tijolo e, como toda a invenção; poderia dar certo ou errado; colocando em risco todo o trabalho de construção da casa.

Mas, apesar da falta de padronização dos insumos, boas iniciativas também foram estabelecidas pela indústria de software para embarcar o usuário neste processo. Entre as boas iniciativas criadas pela indústria de software se destaca uma: os casos de uso. Segundo Cockburn (2005), os casos de uso em técnica texto, assim como os casos de uso em diagrama da UML, são elementos importantes para ajudar o analista a capturar as necessidades de negócio da aplicação a ser desenvolvida. Da mesma forma, ajudar o usuário a acompanhar o desenvolvimento do sistema.

Wazlawich (2004) cita que o processo de desenvolvimento de sistema se divide em grande quatro fases: análise, projeto, implementação e testes. Entre estas fases, a análise enfatiza a investigação do problema. Para que esta etapa seja realizada em menos tempo e com maior precisão necessita-se de um bom método de trabalho, tal como o proposto por Cockburn. Este cuidado é necessário, já que, ninguém é capaz de entender com perfeição um problema usual de sistemas de informação no primeiro contato.

O resultado de um processo de análise mal feito é um software que funciona, mas que não corresponde às necessidades estabelecidas pelo usuário. Segundo Wazlawich (2004), a qualidade no processo de análise é fundamental, já que, um erro encontrado na análise possui um custo ao ser corrigido; no projeto tem outro maior; na implementação, outro maior ainda; e assim por diante.

Portanto, o primeiro contato com o usuário é primordial para nortear o processo de análise e também todo o restante do desenvolvimento. Neste quesito, as mais recentes metodologias de desenvolvimento de software possuem fases de concepção, que de forma rápida tentam capturar as funcionalidades básicas do software e, com o tempo, refina-las. Exemplos destas metodologias são: o processo unificado (PU) e o extreme programming (XP).

Daremos continuidade na segunda parte, que será publicada em breve, com a participação do usuário no processo de análise, bem como sua importância, além dos cuidados e dicas para que este processo tenha sucesso

Welder Maurício de Souza
Contato: welder.mauricio@hotmail.com