A seção 2.1 e 2.2 abordam, respectivamente, a evolução dos produtos de software e a evolução das organizações de desenvolvimento. A seção 2.3 apresenta os processos existentes em uma ODS, demonstrando modelos e elucidando conceitos.
2.1 O PRODUTO DE SOFTWARE
Tem-se observado muitas mudanças nos produtos de software que, nos últimos anos, surgem em prateleiras de supermercados ou mesmo disponíveis gratuitamente na Web. Conseqüência do aperfeiçoamento tecnológico e da maturidade no desenvolvimento de software adquiridos no decorrer dos anos.Anterior à revolução gerada pelo surgimento dos PCs (Personal Computers), o software , geralmente, era confeccionado dentro da empresa que iria utilizá-lo. Os detalhes do negócio então eram do conhecimento dos desenvolvedores. O software também era monolítico e específico para “rodar” na plataforma da empresa, considerando o seu ambiente e os seus processos. De responsabilidade organizacional e não contratual, se o software executasse as funções a que se propunha, geralmente, já satisfazia os seus usuários/clientes.
O produto de software hoje confeccionado pelas ODSs possui características diferenciadas, desde a sua especificação até a entrega. Em primeiro lugar, ele deve ser o mais geral, flexível e parametrizável possível. Deve estar apto a “rodar” em empresas diferentes, que possuam inclusive processos de negócio também diferentes. O usuário, que determinava os requisitos do software, passou muitas vezes até mesmo a não existir, exigindo que a equipe de desenvolvimento se adaptasse e passasse a buscar o conhecimento de outras formas. Muitas sub-áreas da Engenharia de Software surgiram (ou foram reforçadas) para satisfazer esses novos quesitos como, por exemplo, Engenharia do Conhecimento, Engenharia de Requisitos, Arquitetura de Software, Sistemas Distribuídos.
Alguns fatores de qualidade passaram a ser exigidos para o produto de software. Entre esses fatores, podem-se citar os externos como usabilidade, portabilidade, manutenibilidade etc. e fatores de qualidade internos como reusabilidade, modularidade, flexibilidade etc. Uma constante melhoria no processo que desenvolve o produto também passou a ter relevância, pois um processo de software de alta qualidade deve, por conseqüência, gerar um produto de alta qualidade. Pode-se dizer que qualidade é uma das palavras chaves na Engenharia de Software e é medida atualmente de duas formas: (1) qualidade do produto e (2) qualidade do processo. Em um post especifico será detalhado os padrões que avaliam e propõem melhoria da qualidade.
Outro aspecto interessante deste novo software que estamos produzindo é o fato de gerar uma demanda muitas vezes ainda não existente. Podem-se citar vários softwares que surgiram desta forma, como: o Windows, o Netscape, o Word, o Yahoo e os RPGs.
A Figura 2.1 sintetiza algumas diferenças entre o produto de software que produzíamos nos primórdios da computação e os que hoje são desenvolvidos.
2.2 A ORGANIZAÇÃO DE DESENVOLVIMENTO DE SOFTWARE
É natural que um produto confeccionado com características tão diferentes das iniciais também fosse gerado por uma ODS diferente. Nesta seção é visto o quanto as organizações mudaram para satisfazer as necessidades da confecção dos produtos de software e se adequarem às novas tecnologias e tendências mercadológicas.
2.2.1 Núcleo de Processamento de Dados
Os primeiros tipos de computadores produzidos foram os mainframes, equipamentos caros e de difícil manutenção e operação. Uma empresa que resolvesse adquirir um equipamento deste porte sofria a imediata conseqüência de necessitar contratar, também, uma grande equipe para produzir e operar os softwares (tanto os desenvolvidos por ela, quanto os de suporte ao desenvolvimento).
Os contratos de venda, aluguel e manutenção desses equipamentos ultrapassavam as cifras de milhares de dólares. Somente em grandes empresas, com um bom faturamento e em grandes universidades, observávamos o computador. As equipes dentro dos centros de desenvolvimento de software eram grandes e era requerida muita especialização por parte de quem desenvolvia software.
As ODSs (nomeadas de núcleos ou centros de processamento de dados - CPDs ou NPDs) eram compostas, salvo algumas exceções, por setores agrupados baseados nas tarefas (funções) que cada um desempenhava em relação ao desenvolvimento e operação do software. A Figura 2.2 mostra um exemplo de um organograma de um NPD.
Na divisão de desenvolvimento se concentrava a confecção do produto de software. O setor de análise levantava informações junto aos usuários e especificava logicamente e fisicamente o software, enquanto o setor de programação codificava as especificações definidas pelos analistas de sistemas. Dentro do setor de programação poderíamos observar duas equipes distintas: equipe de desenvolvimento (encarregada dos novos programas) e a equipe de manutenção (encarregada de manter os programas já desenvolvidos e em produção).
A divisão de suporte possuía duas características principais. A primeira era manter em funcionamento os equipamentos e os softwares, instalando e configurando, além de ter contínua preocupação com o desempenho. A segunda característica era promover a capacitação do pessoal do NPD. Isso implicava em estudo de novas tecnologias e treinamento apropriado. Devido à complexidade do gerenciamento dos mainframes, a divisão de suporte requeria pessoal altamente especializado. Dar suporte à operação do software e a seu desenvolvimento não era tarefa fácil.
A divisão de produção era responsável por executar, obter os resultados e implantar as informações. O setor de digitação realizava a digitação dos documentos ou planilhas que vinham do usuário, além dos programas do setor de programação. Devido ao pouco acesso que as pessoas tinham aos computadores, os usuários preenchiam planilhas com as informações a serem armazenadas nos computadores para posterior processamento. O setor de conferência conferia se havia erros nos dados digitados, se os resultados produzidos pelo processamento estavam corretos etc. Muitos artifícios eram utilizados para garantir a digitação correta dos dados, entre eles o “total de lote” que representava uma totalização dos valores digitados para posterior conferência. As execuções eram solicitadas pelos usuários ou tinham datas pré-determinadas. Essas execuções eram realizadas no setor de operação que também administrava o hardware.A documentação de um sistema era um trabalho muito árduo e cansativo. A utilização de máquinas de datilografia, pastas mantidas manualmente etc., traziam um custo muito elevado para se manter o sistema atualizado. Por isso, alguns NPDs possuíam um setor de documentação que era encarregado de realizar todas as alterações feitas manualmente por analistas, programadores e operadores.
A qualidade do produto e do processo que o confeccionava era uma preocupação constante nos NPDs. Todavia, a Engenharia de Software ainda engatinhava em seus conceitos e não havia maturidade em relação a padrões de qualidade do produto e do processo de software. O alto custo do “homem especializado em computação” e de “hora máquina” obrigava também estas organizações a medirem seu processo. Em suma, os NPDs primavam por usar uma metodologia de desenvolvimento, documentar os sistemas, medir as atividades pessoais e dar um custo para cada tarefa desenvolvida.
Os pontos apontados como falhos para esta estrutura estão mais ligados à tecnologia empregada do que à estrutura propriamente dita. Com a saída do desenvolvimento dos NPDs para pequenas equipes de desenvolvimento em empresas específicas, houve uma perda da qualidade do processo e do produto. Inclusive tornando a computação desacreditada perante aqueles que necessitavam e/ou pretendiam desenvolver um software.
2.2.2 Pequeno Centro de Desenvolvimento
A evolução do hardware e software mudou significativamente o processo de desenvolvimento e a estrutura das organizações. Com a chegada e barateamento dos PCs, muitas empresas de pequeno e médio porte puderam adquirir computadores e contratar pequenas equipes para automatizar seus processos. Assim, as funções realizadas de formas distintas dentro de um NPD começaram a ser fundidas no ambiente de desenvolvimento e produção. Figuras pejorativas (e que posteriormente passaram até mesmo a incorporar carreiras organizacionais) surgiram como o programalista (programador + analista) e o anador (analista + programador).Sistemas como folha de pagamento, contas a pagar, contabilidade, controle de estoque, entre outros, invadiram as pequenas e médias empresas. A função “super-valorizada” de quem produzia software tornou-se algo tão comum como um escriturário ou um contador. A Figura 2.3 ilustra um exemplo de um pequeno centro de desenvolvimento dentro de uma empresa de pequeno ou médio porte.
Todavia, qual foi o problema destes pequenos centros de desenvolvimento? Em primeiro lugar tinha-se um cliente (usuário) alheio às dificuldades do desenvolvimento de software, que acreditava que qualquer programador resolveria a automação de sua empresa. E em segundo lugar, um grupo de desenvolvimento imaturo metodologicamente e, em sua maioria, descompromissado com o futuro do produto que confeccionavam. Esses dois pontos trouxeram diversos problemas para a informática. Muitas empresas, em pouco tempo, se viram à mercê de um software inoperável ou de difícil/impossível manutenção. Poucos empresários passaram a confiar em quem produzia software para solucionar os problemas ou melhorar a produtividade de seu negócio. Criou-se uma lacuna entre quem precisava do software e quem o produzia.
2.2.3 Fábrica de Software
Atualmente, as fábricas de software são realidades e se tornaram muito mais complexas do que poderíamos imaginar. Além de possuírem as funções de desenvolvimento que existiam nos NPDs, somaram a si funções de negócio e administrativas, algumas até possuindo departamentos especializados em pesquisa (ver Figura 2.4). Trabalham, muitas vezes, dispersas em áreas geográficas diferentes e sub-contratam serviços. São impulsionadas e avaliadas pelos mesmos quesitos de qualquer outra indústria: qualidade do produto e produtividade.
A Figura 2.5 caracteriza algumas diferenças entre a organização que produzia software na década de 1970 e a organização que atualmente desenvolve software. É lógico que nem todas as organizações se encaixam em uma ou outra ponta. Quando se fala, por exemplo, que no ano 2000 as organizações estão fora da empresa que necessita do software, não se está ditando nenhuma regra absurda, apenas trata-se do mais comumente encontrado e de uma tendência que é vislumbrada.
 |
| Figura 2.5: NPDs versus fábricas de software |
A próxima seção apresenta aspectos referentes aos processos utilizados pelas ODSs para produzir software.
2.3 OS PROCESSOS DA ODS
Um processo pode ser definido como um conjunto de atividades inter-relacionadas que transformam um conjunto de entradas em resultados [ISO12207:95]. Segundo a ISO15504 [ISO15504:1-9:98] processo de software é um conjunto de processos utilizados por uma ODS ou um projeto de software para planejar, gerenciar, executar, monitorar, controlar e melhorar as atividades que estão relacionadas com software.
O trabalho de Wang [Wang99] apresenta um framework unificado de um sistema de processo para uma ODS. A Figura 2.6 mostra este modelo, que está dividido em três agrupamentos principais: o modelo do processo, o modelo de avaliação do processo e o modelo de melhoria do processo.
O modelo do processo é utilizado para descrever a organização, sua categoria, sua hierarquia, o inter-relacionamento e as instâncias dos seus processos. O modelo de processo descrito por [Wang1999] identifica três conjuntos de subsistemas: processo organizacional, processo de desenvolvimento de software e processo de gerenciamento. Os processos organizacionais regulam as atividades que são geralmente praticadas em uma ODS acima do nível de projeto. Os processos de desenvolvimento e de gerenciamento são interativos e, em paralelo, atuam sobre o projeto.
O modelo de avaliação do processo serve para definir procedimentos para avaliar os pontos fortes e fracos dos processos da ODS, além de identificar os pontos para melhoria. Através do modelo de melhoria do processo podem-se definir procedimentos sistemáticos para uma efetiva melhoria do desempenho dos processos da ODS, mudando os processos correntes ou adicionando a eles novos processos para correção ou melhoria de problemas identificados. O processo de melhoria vem a seguir do processo de avaliação e o relacionamento entre eles forma um ciclo repetitivo até o processo de a ODS estar otimizado. Exemplo disso é o plan-do-check-act descrito por Campos [Campos1992]. O capítulo 6 detalhará os aspectos referentes à avaliação e melhoria dos processos de software.
Diversos modelos, normas e padrões definem certificação, avaliação e melhoria para o processo de software, entre eles, podem-se citar: a ISO9000 [ISO9000-3:1997], CMM [Paulk1993] [Paulk1997], CMMI [CMMI:00], ISO15504 [ISO15504:1-9:98] e BootStrap [Kuvaja1993] [Kuvaja1994]. O capítulo 6 detalhará os aspectos referentes a essas normas e padrões.
Apesar das ODSs durante muito tempo negligenciarem a especificação e o gerenciamento de seus processos, estes sempre existiram. Porém, não há um consenso de que tipo de processo de software deva ser utilizado em uma ODS, pois alguns processos se adequam melhor a certos tipos de aplicações do que outros. Além disso, uma ODS pode, inclusive, possuir diversos padrões de processos de software sendo utilizados em projetos distintos.
O reconhecimento das necessidades dos modelos de processo de software tem deixado um amplo campo de trabalho em muitas direções. As ODSs têm verificado que definindo seus processos pode-se melhorar sua eficácia e a qualidade dos produtos e serviços que realiza.-------------------------------------------------------------------------------------------------------------------------------------
[3] Utilizaremos os termos "software" e "sistema" como sinônimos, apesar do último ser mais abrangente.
[4] Especificar um software neste contexto significa criar um modelo computacional, independente da plataforma computacional que será utilizada.
