O produto de software e a organização de desenvolvimento

Atualmente, há cada vez mais sistemas controlados por software, fazendo com que a economia de praticamente todos os países seja muito dependente da qualidade dos softwares por eles usados, justificando um investimento significativo nesse setor.


Há alguns anos atrás, desenvolvia-se software de uma maneira completamente artesanal. A partir de uma simples definição dos requisitos do software, partia-se imediatamente para a implementação do mesmo. Hoje em dia, ainda há muitas empresas que desenvolvem software dessa maneira, mas várias outras estão mudando suas formas de trabalho.


A forma artesanal de trabalho, geralmente, não traz grandes problemas para o desenvolvimento de software de pequeno porte, o qual não exige um esforço muito grande de implementação. Porém, para softwares de grande porte, sérios problemas na implementação podem comprometer todo o projeto.


Com o desenvolvimento cada vez maior da tecnologia de hardware e a conseqüente disponibilidade de máquinas cada vez mais potentes e baratas, o uso de computadores tem-se tornado cada vez mais difundido em diversas áreas. Isso tem feito com que aumente a demanda por software cada vez maior e mais complexo. No entanto, a demanda por software tem-se tornado maior que a capacidade do mercado para atendê-la.


Muitos projetos são entregues com um grande atraso, custando muito mais que o inicialmente previsto, sendo não confiáveis, difíceis de manter e/ou não tendo um desempenho satisfatório. Além do mais, na tentativa de se consertar os erros, muitas vezes introduzem-se mais erros. Geralmente, a quantidade de problemas é diretamente proporcional ao aumento da complexidade do software produzido nos dias de hoje. Esses problemas no desenvolvimento de software são conhecidos mundialmente como a “crise de software”. Ou seja, a “crise de software” corresponde à incapacidade da indústria de software de atender prontamente à demanda do mercado de software, dentro dos custos e dos níveis de qualidade esperados.


Desde os anos 1960, quando o termo “crise de software” foi pronunciado pela primeira vez, muitos problemas desta área foram identificados e muitos deles ainda persistem até os dias de hoje, tais como [Gibbs1994]:


Previsão pobre – desenvolvedores não prevêem adequadamente quanto tempo e esforço serão necessários para produzir um sistema de software que satisfaça às necessidades (requisitos) dos clientes/usuários. Sistemas de software são geralmente entregues muito tempo depois do que fora planejado;


- Programas de baixa qualidade – programas de software não executam o que o cliente deseja, conseqüência talvez da pressa para se entregar o produto. Os requisitos originais podem não ter sido completamente especificados, ou podem apresentar contradições, e isto pode ser descoberto muito tarde durante o processo de desenvolvimento;


- Alto custo para manutenção – quando o sistema é construído sem uma arquitetura clara e visível, a sua manutenção pode ser muito custosa;


- Duplicação de esforços – é difícil compartilhar soluções ou reusar código, em função das características de algumas linguagens adotadas, por falta de confiança no código feito por outra pessoa e até mesmo pela ausência/deficiência de documentação das rotinas e dos procedimentos já construídos.


O reconhecimento da existência da crise de software tem provocado uma forte mudança na forma de como as pessoas desenvolvem software de grande porte, visto que o processo de desenvolvimento atual é mais disciplinado do que no passado. Foi proposto que o desenvolvimento de software deixasse de ser puramente artesanal e passasse a ser baseado em princípios de Engenharia, ou seja, seguindo um enfoque estruturado e metódico. Assim, surgiu o termo Engenharia de Software, que se refere ao desenvolvimento de software por grupos de pessoas, usando princípios de engenharia e englobando aspectos técnicos e não-técnicos, de modo a produzir software de qualidade, de forma eficaz e dentro de custos aceitáveis.


Portanto, a Engenharia de Software engloba não apenas o desenvolvimento de programas, mas também toda a documentação necessária para o desenvolvimento, instalação, uso e manutenção dos programas. O temo “ciclo de vida de software” compreende todas as etapas, desde a concepção inicial do software, até a sua implementação, implantação, uso e manutenção, de modo que, ao final de cada uma destas etapas, um ou mais documentos são produzidos.


Engenheiros de software devem adotar uma abordagem sistemática e organizada para seu trabalho e usar ferramentas e técnicas apropriadas, dependendo do problema a ser solucionado, das restrições de desenvolvimento e dos recursos disponíveis. Além das técnicas de especificação e implementação de software, os engenheiros de software devem ter conhecimento também de outras técnicas como, por exemplo, de gerenciamento de software. Dessa forma, aumenta-se a probabilidade de produzir software de grande porte com qualidade, ou seja, software que satisfaça os requisitos do usuário, bem como as expectativas de tempo e de orçamento.


As ODSs (Organizações de Desenvolvimento de Software)[1], com o intuito de minimizar os problemas do desenvolvimento do software, têm geralmente adotado metodologias de desenvolvimento de software. Todavia, os paradigmas metodológicos para desenvolvimento de software têm sido considerados somente em termos de “um método” de análise/projeto/implementação, isto é, um conjunto de conceitos, técnicas e notações. Essa visão elimina os aspectos tecnológicos, contextuais e organizacionais que potencialmente existem dentro de um processo de software.


Os ambientes tradicionais das ODSs geralmente suportam apenas a engenharia do produto, assumindo um processo implícito e tendo como foco principal o produto. Essa visão tem limitado as ODSs no que diz respeito à tomada de decisões, ao estabelecimento e arquivamento de metas organizacionais, à determinação de pontos para melhoria, à estipulação de prazos para entrega de produtos e à obtenção de uma certificação. O capítulo 2 apresenta os aspectos evolutivos das ODSs e seus produtos de software.


De forma geral, pode-se dividir as funções de uma ODS em três grupos principais [Garg1996][2]:


1. Definir, analisar, simular, medir e melhorar os processos da organização;


2. Construir o produto de software;


3. Medir, controlar, modificar e gerenciar os projetos de software.


Estes três grupos são abordados, respectivamente, pela Engenharia de Processo, pela Engenharia de Produto e pelo Gerenciamento de Projeto. O relacionamento entre estes grupos é mostrado na Figura 1.1.












Figura 1.1: Relacionamento entre engenharia de processo, gerenciamento de projeto e engenharia do produto


A engenharia de processo tem como meta a definição e a manutenção dos processos da ODS. Ela deve ser capaz de facilitar a definição, a análise e a simulação de um processo, assim como estar apta a implantá-lo, avaliá-lo, medi-lo e melhorá-lo. A engenharia de processo trata os processos de software de uma forma sistemática com um ciclo de vida bem definido. O capítulo 6 aborda este tema discorrendo sobre qualidade de software, um tema cada vez mais relevante e que engloba avaliação e melhoria contínua dos processos da ODS.


O gerenciamento de projeto tem o objetivo de assegurar que processos particulares sejam seguidos, coordenando e monitorando as atividades da engenharia do produto. Um processo de gerenciamento de projeto deve identificar, estabelecer, coordenar e monitorar as atividades, as tarefas e os recursos necessários para um projeto produzir um produto e/ou serviço de acordo com seus requisitos. Todavia, gerenciar projetos de software é uma atividade complexa devido a uma série de fatores, tais como: dinamicidade do processo, grande número de variáveis envolvidas, exigência de adaptabilidade ao ambiente de desenvolvimento e constantes alterações no que foi planejado. Esses fatores dificultam o trabalho das equipes de desenvolvimento na medição do desempenho dos projetos, na verificação de pontos falhos, no registro de problemas, na realização de estimativas e planejamentos adequados. O capítulo 4 aborda esse tema.


A engenharia do produto é encarregada do desenvolvimento e manutenção dos produtos e serviços de software. A principal figura da engenharia do produto é a metodologia de desenvolvimento, que engloba uma linguagem de representação, um modelo de ciclo de vida e um conjunto de técnicas. Os ambientes tradicionais de desenvolvimento de software têm se preocupado essencialmente com a engenharia do produto, assumindo um processo implícito e tendo como foco o produto. Todavia, a engenharia do produto por si só é insuficiente para suprir as necessidades da ODS e torná-la mais produtiva e adequada às exigências do mercado. O capítulo 3 aborda os modelos de ciclo de vida mais utilizados na engenharia do produto. O capítulo 5 descreve as principais atividades da engenharia de produto.

---

[1] Uma ODS representa uma organização independente, ou um departamento ou uma unidade dentro de uma organização, que é responsável por desenvolver, manter, oferecer ou operar um produto ou serviço de software ou um sistema de software intensivo [Wang1999].

[2] A Engenharia de Software deve considerar estas funções objetivando a produção de software de maior qualidade e a melhoria do desempenho da ODS, ou seja, torná-la mais produtiva.

9 passos para uma Guilda de sucesso.

1- Concentre-se em tornar-se melhor em seu papel: compartilhar conhecimentos, experiências, ter ideias, criar habilidades, compreender as dificuldades, etc. Assim, ao final de cada Guilda, você deve ser um QA, ScrumMaster ou Product Owner melhor.

            Dica: treine e desenvolva o seu papel;

 2- Motive e divirta: Guildas são treinamentos entre amigos. Você compartilha não só conhecimentos sobre seu papel, mas também desafios. As Guildas precisam ser enérgicas e divertidas, para que você possa tirar o máximo proveito disso.

            Dica: Faça reuniões descontraídas;

3- Aprendizagem: Aprendemos dando feedbacks uns aos outros. Certifique-se de trabalhar com um feedback construtivo. Diga o que você faz bem, antes de dizer como melhorar. Lembre-se: todos devem sair com mais energia do que chegaram, por isso não se concentre demais no lado negativo somente.

            Dica: Aprendizagem é unir o a melhoria no seu papel com motivação;

4- Ambiente seguro: as Guildas devem ser seguras. Este é o lugar para mostrar todos os pontos fracos e trabalhar juntos para nos tornarmos melhores. Cometer erros durante as guildas é obrigatório. Este é o lugar para aprender, por isso este é o lugar para cometer erros e onde as falhas são permitidas. Caso nos sintamos mais confortáveis podemos fazer acordos explícitos sobre a segurança e confidencialidade das guildas: "O que acontece na guilda, permanece na guilda".

            Dica: Esse é o lugar certo para errar;

5- Encha sua caixa de ferramentas: Guildas são todas sobre a construção de habilidades. A comunicação e interação é crucial. Forneça ferramentas para o seu papel. Ensine e descubra formatos de oficinas, jogos, simulações, etc, para serem usados em suas práticas diárias.

            Dica: Seja criativo nas rotinas diárias;

6- Desafiar uns aos outros - Desafiar uns aos outros é crucial para a aprendizagem. Para isso você precisa de um ambiente seguro e ferramentas que permitam desafiar construtivamente. Isso instiga a busca pelo conhecimento.

            Dica: Desafie positivamente;

7- Timebox: determinar o tempo, para não encerrar cedo ou tarde demais. O Timebox garante que todos os tópicos importantes são abordados.

            Dica: planeje o tempo de cada tópico da Guilda;

8- Foco: Guildas são realizadas em uma abordagem de melhoraria continua, portanto, o foco deve ser em melhorar rotinas e/ou processos pertinentes ao papel.

Dica: organizar as Guildas para garantir foco e nitidez.

9- Trocar experiências: Conhecimento e experiência são interessantes, mas quando eles não geram mudanças, não são eficazes. As mudanças podem ser comportamentais (pessoais ou do grupo). O que vamos fazer diferente após esta reunião? Como vamos garantir que isso vai realmente ser feito? Quanto maior a melhoria, melhor a reunião.

Dica: Reserve pelo menos meia hora de cada guilda para converter ideias em ações e priorizar junto aos envolvidos.

Como o Docker pode nos auxiliar nos testes?

Um dos problemas mais comuns do QAs está relacionado ao ambiente de testes. Há inúmeras variáveis que podem interferir no resultado do teste como: dependências (pacotes instalados, versão, arquitetura, etc.), configurações (php.ini, Ngnix, Apache, Tomcat, etc.), dentre outras.

Considerando esse cenário você deve estar se questionando, qual a vantagem em utilizar o docker nos ambiente de testes?

Vantagens:

• A execução em qualquer máquina sempre irá rodar de forma esperada, com bibliotecas, dependências e permissões configuradas;
• Elimina o uso de máquina virtual específica para realização do teste;
• Possibilita a criação de imagens* com combinações de ambientes  diferentes;
• Imutabilidade, ou seja, você cria o container uma única vez, versiona e distribui posteriormente.
• Padronização dos ambientes;
• Facilidade na distribuição das atualizações de dependências, bibliotecas e parâmetros;
• Particiona a máquina, e roda processos menores com menor consumo de recurso;
• Elimina a história do “Na minha máquina funciona”.

Desvantagens:

• Perda da variação de ambientes;
•  Devs/QAs não adquirem conhecimento sobre as parametrizações do ambiente. 

Como iniciar:

• O primeiro passo é identificar as dependências e configurações que o software necessita;
• Crie uma imagem considerando os parâmetros mapeados. Ver:  https://docs.docker.com/engine/reference/;
• Distribua a imagem para o seu time de QAs/Devs;
• Institucionalize e incentive o uso.

Como o Docker pode nos auxiliar nos testes?

Um dos problemas mais comuns do QAs está relacionado ao ambiente de testes. Há inúmeras variáveis que podem interferir no resultado do teste como: dependências (pacotes instalados, versão, arquitetura, etc.), configurações (php.ini, Ngnix, Apache, Tomcat, etc.), dentre outras.

Considerando esse cenário você deve estar se questionando, qual a vantagem em utilizar o docker nos ambiente de testes?

Vantagens:

• A execução em qualquer máquina sempre irá rodar de forma esperada, com bibliotecas, dependências e permissões configuradas;
• Elimina o uso de máquina virtual específica para realização do teste;
• Possibilita a criação de imagens* com combinações de ambientes  diferentes;
• Imutabilidade, ou seja, você cria o container uma única vez, versiona e distribui posteriormente.
• Padronização dos ambientes;
• Facilidade na distribuição das atualizações de dependências, bibliotecas e parâmetros;
• Particiona a máquina, e roda processos menores com menor consumo de recurso;
• Elimina a história do “Na minha máquina funciona”.

* A imagem docker a base para o contêiner docker onde tudo começa a se formar. São muito similares às imagens de disco padrão de sistema operacional.

Desvantagens:

• Perda da variação de ambientes;
•  Devs/QAs não adquirem conhecimento sobre as parametrizações do ambiente. 

Como iniciar:

• O primeiro passo é identificar as dependências e configurações que o software necessita;
• Crie uma imagem considerando os parâmetros mapeados. Ver:  https://docs.docker.com/engine/reference/;
• Distribua a imagem para o seu time de QAs/Devs;
• Institucionalize e incentive o uso.

Qualidade de Software - Parte II

O Produto de Software e a Organização de Desenvolvimento

Impulsionados pelas mudanças tecnológicas e pelo amadurecimento das atividades de desenvolvimento de software os produtos, as organizações de desenvolvimento (ODSs) e seus processos associados mudaram no decorrer das últimas décadas. Este capítulo faz uma retrospectiva desses elementos.
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 

Com o intuito de preencher esta lacuna, alguns centros de desenvolvimento de software foram montados como empresas apartadas do cliente/usuário. É bom deixar claro que as fábricas de software não surgiram em decorrência de uma idéia, mas sim de bons desenvolvedores que passaram a oferecer sua solução de software para diversas empresas, assegurando uma continuidade do produto que desenvolviam. Isso possibilitava que o comprador do software tivesse uma garantia contratual de manutenção e evolução do produto. Apesar dos sistemas perderem em especificidade, começava a despontar uma solução de software barato (pois era vendido para diversas empresas) e de melhor qualidade.
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.

Qualidade de Software - Parte I

Atualmente, há cada vez mais sistemas controlados por software, fazendo com que a economia de praticamente todos os países seja muito dependente da qualidade dos softwares por eles usados, justificando um investimento significativo nesse setor.

Há alguns anos atrás, desenvolvia-se software de uma maneira completamente artesanal. A partir de uma simples definição dos requisitos do software, partia-se imediatamente para a implementação do mesmo. Hoje em dia, ainda há muitas empresas que desenvolvem software dessa maneira, mas várias outras estão mudando suas formas de trabalho.

A forma artesanal de trabalho, geralmente, não traz grandes problemas para o desenvolvimento de software de pequeno porte, o qual não exige um esforço muito grande de implementação. Porém, para softwares de grande porte, sérios problemas na implementação podem comprometer todo o projeto.

Com o desenvolvimento cada vez maior da tecnologia de hardware e a conseqüente disponibilidade de máquinas cada vez mais potentes e baratas, o uso de computadores tem-se tornado cada vez mais difundido em diversas áreas. Isso tem feito com que aumente a demanda por software cada vez maior e mais complexo. No entanto, a demanda por software tem-se tornado maior que a capacidade do mercado para atendê-la.

Muitos projetos são entregues com um grande atraso, custando muito mais que o inicialmente previsto, sendo não confiáveis, difíceis de manter e/ou não tendo um desempenho satisfatório. Além do mais, na tentativa de se consertar os erros, muitas vezes introduzem-se mais erros. Geralmente, a quantidade de problemas é diretamente proporcional ao aumento da complexidade do software produzido nos dias de hoje. Esses problemas no desenvolvimento de software são conhecidos mundialmente como a “crise de software”. Ou seja, a “crise de software” corresponde à incapacidade da indústria de software de atender prontamente à demanda do mercado de software, dentro dos custos e dos níveis de qualidade esperados.

Desde os anos 1960, quando o termo “crise de software” foi pronunciado pela primeira vez, muitos problemas desta área foram identificados e muitos deles ainda persistem até os dias de hoje, tais como [Gibbs1994]:

Previsão pobre – desenvolvedores não prevêem adequadamente quanto tempo e esforço serão necessários para produzir um sistema de software que satisfaça às necessidades (requisitos) dos clientes/usuários. Sistemas de software são geralmente entregues muito tempo depois do que fora planejado;

- Programas de baixa qualidade – programas de software não executam o que o cliente deseja, conseqüência talvez da pressa para se entregar o produto. Os requisitos originais podem não ter sido completamente especificados, ou podem apresentar contradições, e isto pode ser descoberto muito tarde durante o processo de desenvolvimento;

- Alto custo para manutenção – quando o sistema é construído sem uma arquitetura clara e visível, a sua manutenção pode ser muito custosa;

- Duplicação de esforços – é difícil compartilhar soluções ou reusar código, em função das características de algumas linguagens adotadas, por falta de confiança no código feito por outra pessoa e até mesmo pela ausência/deficiência de documentação das rotinas e dos procedimentos já construídos.

O reconhecimento da existência da crise de software tem provocado uma forte mudança na forma de como as pessoas desenvolvem software de grande porte, visto que o processo de desenvolvimento atual é mais disciplinado do que no passado. Foi proposto que o desenvolvimento de software deixasse de ser puramente artesanal e passasse  a ser baseado em princípios de Engenharia, ou seja, seguindo um enfoque estruturado e metódico. Assim, surgiu o termo Engenharia de Software, que se refere ao desenvolvimento de software por grupos de pessoas, usando princípios de engenharia e englobando aspectos técnicos e não-técnicos, de modo a produzir software de qualidade, de forma eficaz e dentro de custos aceitáveis.

Portanto, a Engenharia de Software engloba não apenas o desenvolvimento de programas, mas também toda a documentação necessária para o desenvolvimento, instalação, uso e manutenção dos programas. O temo “ciclo de vida de software” compreende todas as etapas, desde a concepção inicial do software, até a sua implementação, implantação, uso e manutenção, de modo que, ao final de cada uma destas etapas, um ou mais documentos são produzidos.

Engenheiros de software devem adotar uma abordagem sistemática e organizada para seu trabalho e usar ferramentas e técnicas apropriadas, dependendo do problema a ser solucionado, das restrições de desenvolvimento e dos recursos disponíveis. Além das técnicas de especificação e implementação de software, os engenheiros de software devem ter conhecimento também de outras técnicas como, por exemplo, de gerenciamento de software. Dessa forma, aumenta-se a probabilidade de produzir software de grande porte com qualidade, ou seja, software que satisfaça os requisitos do usuário, bem como as expectativas de tempo e de orçamento.

As ODSs (Organizações de Desenvolvimento de Software)[1], com o intuito de minimizar os problemas do desenvolvimento do software, têm geralmente adotado metodologias de desenvolvimento de software. Todavia, os paradigmas metodológicos para desenvolvimento de software têm sido considerados somente em termos de “um método” de análise/projeto/implementação, isto é, um conjunto de conceitos, técnicas e notações. Essa visão elimina os aspectos tecnológicos, contextuais e organizacionais que potencialmente existem dentro de um processo de software.

Os ambientes tradicionais das ODSs geralmente suportam apenas a engenharia do produto, assumindo um processo implícito e tendo como foco principal o produto. Essa visão tem limitado as ODSs no que diz respeito à tomada de decisões, ao estabelecimento e arquivamento de metas organizacionais, à determinação de pontos para melhoria, à estipulação de prazos para entrega de produtos e à obtenção de uma certificação. O capítulo 2 apresenta os aspectos evolutivos das ODSs e seus produtos de software.

De forma geral, pode-se dividir as funções de uma ODS em três grupos principais [Garg1996][2]:

1.   Definir, analisar, simular, medir e melhorar os processos da organização;

2.   Construir o produto de software;

3.   Medir, controlar, modificar e gerenciar os projetos de software.

Estes três grupos são abordados, respectivamente, pela Engenharia de Processo, pela Engenharia de Produto e pelo Gerenciamento de Projeto.  O relacionamento entre estes grupos é mostrado na Figura 1.1.

Figura 1.1: Relacionamento entre engenharia de processo, gerenciamento de projeto e engenharia do produto

A engenharia de processo tem como meta a definição e a manutenção dos processos da ODS. Ela deve ser capaz de facilitar a definição, a análise e a simulação de um processo, assim como estar apta a implantá-lo, avaliá-lo, medi-lo e melhorá-lo. A engenharia de processo trata os processos de software de uma forma sistemática com um ciclo de vida bem definido. O capítulo 6 aborda este tema discorrendo sobre qualidade de software, um tema cada vez mais relevante e que engloba avaliação e melhoria contínua dos processos da ODS.

O gerenciamento de projeto tem o objetivo de assegurar que processos particulares sejam seguidos, coordenando e monitorando as atividades da engenharia do produto. Um processo de gerenciamento de projeto deve identificar, estabelecer, coordenar e monitorar as atividades, as tarefas e os recursos necessários para um projeto produzir um produto e/ou serviço de acordo com seus requisitos. Todavia, gerenciar projetos de software é uma atividade complexa devido a uma série de fatores, tais como: dinamicidade do processo, grande número de variáveis envolvidas, exigência de adaptabilidade ao ambiente de desenvolvimento e constantes alterações no que foi planejado. Esses fatores dificultam o trabalho das equipes de desenvolvimento na medição do desempenho dos projetos, na verificação de pontos falhos, no registro de problemas, na realização de estimativas e planejamentos adequados. O capítulo 4 aborda esse tema.

A engenharia do produto é encarregada do desenvolvimento e manutenção dos produtos e serviços de software. A principal figura da engenharia do produto é a metodologia de desenvolvimento, que engloba uma linguagem de representação, um modelo de ciclo de vida e um conjunto de técnicas. Os ambientes tradicionais de desenvolvimento de software têm se preocupado essencialmente com a engenharia do produto, assumindo um processo implícito e tendo como foco o produto. Todavia, a engenharia do produto por si só é insuficiente para suprir as necessidades da ODS e torná-la mais produtiva e adequada às exigências do mercado. O capítulo 3 aborda os modelos de ciclo de vida mais utilizados na engenharia do produto. O capítulo 5 descreve as principais atividades da engenharia de produto.

---

[1] Uma ODS representa uma organização independente, ou um departamento ou uma unidade dentro de uma organização, que é responsável por desenvolver, manter, oferecer ou operar um produto ou serviço de software ou um sistema de software intensivo [Wang1999].

[2] A Engenharia de Software deve considerar estas funções objetivando a produção de software de maior qualidade e a melhoria do desempenho da ODS, ou seja, torná-la mais produtiva.

Lições Aprendidas com Teste Automatizado

Meu nome é Ieda Alves e a quase 3 anos eu trabalho aplicando testes automatizados nos produtos desenvolvidos pela empresa onde eu trabalho.

O que é importante saber sobre o teste automatizado?

Primeiro de tudo, para se realizar esse tipo de teste é preciso fazer uso de uma ferramenta que automatize as funcionalidades do sistema. Existem várias no mercado, porém neste artigo vou me ater a apenas uma para garantir o foco.

Segundo, quem garante a eficiência e cobertura do teste não é a ferramenta e sim o tester, ou seja, você ou a pessoa que utilizará a ferramenta. Como a própria denominação “Ferramenta” já diz, o software de automatização é um utensílio de trabalho, não faz milagre sozinho. Cabe ao testador e gerente de teste programar e planejar a execução da automatização de teste.

Terceiro e não menos importante, o planejamento e priorização do teste farão a diferença na dinâmica de gravação dos testes. Conhecer o sistema que será testado faz parte do planejamento, não saber o comportamento e estrutura do que se pretende gravar provavelmente proporcionará tempo e dinheiro jogado fora.

Ferramenta de automação de testes.

Apesar de existirem N ferramentas existentes por ai no mercado como Arbiter, Selenium, TestComplete entre outras, este artigo tratará apenas da ferramenta proprietária Rational Functional Tester – IBM.

A RFT (Rational Functional Tester) é uma solução de teste funcional e de regressão automatizada para equipes de QA preocupadas com a qualidade de seus aplicativos Java™ baseados na Web, Microsoft® Visual Studio, NET®, baseados em terminal, SAP, Siebel e Web 2.0.

Atualmente a RFT está na versão 8.2.1 e as atualizações são garantidas pelo sistema web da IBM. Claro que como um software proprietário é preciso ter a licença para poder fazer as ditas atualizações. Diga-se de passagem, não é um software barato.

O software utiliza a plataforma Eclipse como suporte às funcionalidades e interface e os testes são executados na ideologia gravar/reproduzir. A gravação é iniciada e basicamente todas as ações do testador no sistema são gravadas na forma de scripts em linguagem Java ou Visual Basic. Os scripts são totalmente editáveis e passíveis de manipulação.

Após a gravação é só mandar reproduzir o script gravado, todas as ações serão repetidas conforme executado pelo testador. A ferramenta fornece um relatório na forma de log dos eventos manipulados pelo escript, inclusive se durante a execução aconteceu algo inesperado.

Também é possível manter revisões dos scripts em um repositório SVN, assim é mantido a rastreabilidade de tudo que foi gravado.

Em conjunto com a RFT utilizo outro software chamado Test Mananger, também da IBM. Este software faz o gerenciamento e a aglutinação dos scripts criados na RFT. É neste momento que a estrutura seqüencial e funcional do teste é criada. São criadas as suítes de execução que por sua vez incorporam os Test Cases (Casos de testes – os scripts). É esta execução em cadeia que garante a qualidade do teste automatizado.

Nesta ferramenta também é possível configurar e recolher evidências dos testes, como por exemplo, logs de execução, gráficos e relatórios populados, o que agrega grande valor a execução do teste automatizado, uma vez que comprova as funcionalidades do sistema testado, na forma de documentação também automática.

Experiência do testador.

Tudo isso parece uma maravilha, porém não é esse “mar de rosas não”, as ferramentas são "temperamentais" e é ai que entra as habilidades dos testadores. O que está descrito no site de especificações das ferramentas não ajudam muito, o que vale mesmo são as lições apreendidas durante o projeto piloto.

Existem muitos detalhes que não são nada intuitivos e alguns comportamentos que as ferramentas não tratam, incompatibilidade com o browser é uma delas, e isso precisa ser contornado.  Sem falar na oneração do processamento e acumulo de cache.

O testador precisa mais do que nunca do seu perfil investigativo, pois é difícil trocar experiências a respeito da RFT. O Site da IBM muitas vezes se transforma em um labirinto, principalmente no início, quando se está começando. Até se encontrar algo útil levam-se horas. Ir a fundo nas configurações algumas vezes pode estragar com tudo, por isso deve sempre anotar ou guardar as configurações originais ou seja, aquele backup sempre será uma boa idéia. Precaução e bom senso são as palavras.

Planejamento dos Testes

Para se automatizar um sistema é preciso que o mesmo esteja estável, pois o  objetivo principal do teste automatizado é homologar um produto garantindo que os recursos já validados em uma versão anterior continuam funcionando após a inclusão de novas melhorias/requisitos.

O teste automatizado começa antes da gravação propriamente dita, o mais importante na hora de automatizar um sistema é conhecê-lo. Saber o seu fluxo de funcionamento, suas dependências entres registros, entrada e saídas. Assim é possível criar um roteiro de gravação.

O roteiro de gravação é um documento que serve como guia e recolhimento de informações acerca do sistema. Nele devem estar relatadas as dependências entre registros, ou seja, os pré-requisitos para cada registro a ser gravado, além disso, deve estar descrito o fluxo que se deve seguir dentro do sistema, por onde começar e todas as etapas críticas que precisam ser gravadas.

Uma técnica também muito utilizada é chamada de "stubs", que consiste em popular os registros / telas mais simples e com poucos campos através de scripts e/ou congelando a base de dados já com esses dados inseridos. A automatização de um sistema deve ter como foco garantir o fluxo principal e os requisitos crítico do sistema em automatização.

Com base no roteiro de teste fica muito mais fácil criar os Casos de Testes. Cada script pode ser um caso de teste, isso vai depender da métodologia adotada pela área de teste, porém criar scripts muito logos nãp são uma boa idéia, principalmente na hora de manutení-lo.

Por enquanto esse artigo fica por aqui, espero futuramente contribuir mais sobre as peculiaridades do teste automatizado e da ferramenta RFT com as minhas experiências e rotinas de trabalho.

Ieda Alves.