Introdução

Estamos vivendo um tempo onde não podemos mais levar 1 ano, 2 anos ou mais para fazermos um programa de computador (um sistema automatizado). Aspectos de custos e atendimento de necessidades, criadas pela competição, não permitem mais este luxo.

Ferramentas de desenvolvimento RAD (Rapid Application Development) adicionadas à banco de dados visualmente configuráveis indicam este curto caminho do desenvolvimento.

Mas e a análise? Nela, não encontramos o reaproveitamento? Aqueles que estão codificando, usando ferramentas que permitem a orientação a objetos, estão realmente fazendo códigos orientados a objetos? Estas perguntas são a motivação para a criação deste documento.

Visão orientada a objetos?

Quantos já não viram uma equipe de desenvolvimento, trabalhando em um software com diversos requisitos, construÍdo por uma equipe no mais alto sigilo? Ao fim, na entrega do software, temos a cortina retirada e o anúncio, bradado aos quatro cantos:

- Fizemos o primeiro software, realmente orientado a objetos da nossa empresa.

É evidente que, sem perceber, o anunciante denigre os softwares já construÍdos e em conseqüência, outras equipes, pois nunca houve um software deste calibre na nossa empresa!

Todos se resignam à constatação de pura incompetência e seguem com suas outras construções.

Mais tempo se passa e logo temos outra equipe anunciando a construção de um software... Há, este sim. Este é puramente orientado a objetos. Sem dúvida!

O problema com este approach é que:

* Ninguém sabe se os requisitos da primeira equipe estão repetidos no software da segunda equipe. * Os arquivos, que deveriam ser pacotes, do primeiro software podem ter abordado aspectos que o segundo e o terceiro não aproveitaram.

Bem, tenho que dar a má notÍcia: estas equipes não estão construindo softwares orientados a objetos. Podem estar construindo softwares orientados a classes, talvez a orgulho ou mesmo a teimosia. Mas de orientado a objetos tem muito pouco.

É neste sentido que uma visão orientada a objetos faz-se necessária. Esta visão é nas equipes de análise e desenvolvimento de software.

Não importa se a empresa tem várias equipes, de diversas empresas terceirizadas construindo software para ela. A mudança deve acontecer no sentimento de que não se analisa ou codifica orientado a objetos para enterrarmos o resultado em um buraco!

As pessoas devem ser reunidas e conscientizadas de que o mundo agora é outro. Se os concorrentes têm rapidez, temos de ter mais. Se nos enclausuramos, nos "nossos" projetos, levamos muito mais tempo para fazermos o fim de nosso trabalho que é:

a) Construir um software capaz de automatizar tarefas a fim de cumprir, melhor ou mais rapidamente, uma determinada atividade.

Este é o resumo da missão de qualquer departamento de desenvolvimento de software, desde os anos 50, no século passado.

Como Implementar esta Visão?

Primeiro deve haver o anúncio formal de que a propriedade de qualquer análise descrita, diagrama ou código criado é propriedade exclusiva da empresa.

Qualquer percepção contrária a isto, não deve ser incentivada.

Vale lembrar que aqui a empresa pode ter dois funcionários no seu departamento de desenvolvimento, isso não importa. Quanto mais jovem for a empresa neste campo, mais perspectiva terá de vir a fazer softwares realmente orientados a objetos.

Em segundo lugar, é preciso se criar a intranet, ou qualquer outra forma de divulgação eficiente, da empresa com todas as possibilidades de se publicar, para cada diagrama, caso de uso, ".dll", ".class", ou ".jar" os seguintes tópicos:

1. Nome do código, ou do caso de uso ou da análise descritiva, etc;
2. Breve descritivo de suas funções;
3. Sua finalidade;
4. Suas entradas e saÍdas;
5. Local fÍsico onde se encontram;
6. Permissões dadas ao código.
7. Possibilidade de importação rápida do código com exemplos claros de utilização.

Com esta biblioteca corporativa de código, criada e posta à disposição de todos os que têm permissões para acessar, podemos começar a pensar que estamos criando softwares orientados a objetos.

Desta forma, quando um analista estiver pensando um caso de uso, pode verificar na biblioteca se existe algo parecido e implementar um "include" deste trabalho já feito. Isto não é reaproveitamento?

Quando um programador for implementar código em uma operação, afim de transformá-la em um método, pode fazer sua pesquisa e descobrir se alguém ainda não pensou esta funcionalidade. Se já, bastará fazer um "import", "extend" , etc deste código e com isto se livrar do trabalho árduo de pensar novamente o trabalho.

Resultados Esperados

Nos primeiros seis meses, talvez um ano, a partir do momento em que se verificou este avanço, promovido pela mudança, poderá se ver uma melhor estimativa de prazos e custos.

Outras necessidades surgirão como a centralização dos variados componentes criados.

Verifique que o custo de horas com o time de desenvolvimento reduzirão, devido ao menor tempo requerido para a construção dos seus softwares.

Quando falo em custos, falo em custos de gerenciamento, análise, design e codificação.

Crie um histórico para avaliar seus resultados, isso pode ser feito em uma planilha de cálculo qualquer ou no software Intranet.

A Fábrica de Software

Reúna os analista e desenvolvedores, envolvidos na construção de software, mesmo estes sendo de empresas terceirizadas diferentes.

Informe-os da intenção organizacional, deixando claro que esta é a nova forma de trabalho desejada.

Trate este assunto como sendo um novo projeto. Para tanto crie um documento que especifique a "visão" deste projeto. Veja que todos os projetos, criados pela fábrica, terão o documento visão.

Crie outro documento que represente um repositório de termos, um Glossário para ser usado pelas equipes. Este glossário deve conter todos os termos com os quais você irá trabalhar no projeto. Veja que todos os projetos, criados pela fábrica, terão o documento Glossário. Este documento informa termos especÍficos do software. Por exemplo, se estivermos construindo um software para gerenciamento de transportadoras, sabemos que existe um documento que chama-se Resumo de Carga – RE, pois bem o que é uma RE, onde usá-la e para que serve? Estas respostas devem ser dadas pelo documento glossário.

Crie outro documento que represente a nomenclatura utilizada pela empresa. Neste documente, informe os prefixos e sufixos de:

* Banco de Dados;
* Tabelas;
* Variáveis;* Arquivos de Códigos;
* Outros;

Não permita que algum código ou arquivo seja criado sem obedecer ao documento Nomenclatura.

Crie casos de uso que representem a confecção de software, ou seja, casos de uso que permitam aos "stakeholders1" saberem o processo pensado de construção de software.

Crie um diagrama de classes que represente o seu ponto de vista sobre o inter-relacionamento entre as diversas fases de sua fábrica de software. Principalmente, divida seu software em pacotes reutilizáveis.

Adiante temos uma sugestão destes documentos, porém, a grande finalidade é a de disseminar estes interesses e deixar claro que existe alguém que funciona como regulador destes novos procedimentos.

Administração de Componentes - Visão

O termo Administração de Componentes2, não se refere a uma única pessoa. Pode-se ter uma área que faça este papel dentro da empresa, neste sentido vamos nos referir a este posto como área e não como pessoa.

É muito difÍcil se ter uma única pessoa, para confiarmos este trabalho, com conhecimentos tão abrangentes: bancos de dados, linguagens, tecnologias e metodologias.

Atribuições da Administração de Componentes

A área de administração de componentes tem como atribuições:

1. Manter o documento Visão, melhorando seu descritivo e permitindo que sua clareza atinja todos os nÍveis de stakeholders existentes. Este procedimento é para todos os projetos da fábrica.
2. Manter o documento de Glossário. Este documento deve ser acrescido de outros que o tempo definir como necessários. Apesar de permitir a inclusão de um termo ou abreviatura, este processo deve ser monitorado.
a. Quando algum interessado, enxergar a necessidade de inclusão de um termo, todos devem ser comunicados;
b. O termo deve ser acompanhado de sua explicação e um breve descritivo de sua necessidade;
Este procedimento é para todos os projetos da empresa.
3. Manter o diagrama de classes que explica, visualmente, o processo de criação de softwares da empresa, conjuntamente com o diagrama de seqüências.
4. Administrar a criação de Banco de Dados.
a. No caso de banco de dados relacionais, a área não deveria permitir a normalização de classes. Evitando se tratar classes como entidades de um banco de dados. Classes são classes, entidades de um banco de dados necessitam de normalização devido à redundância de dados e conseqüente ocupação de espaço fÍsico, além de que a normalização facilita consultas.
b. No caso de bancos de dados orientados a objetos, a representação do banco de dados deveria representar o modelo de classes existente para a aplicação em jogo.
5. Administrar o software de componentes.
Seja no caso do com+ (Microsoft) ou outro software de administração de componentes adotado, a nomenclatura e os métodos de acesso, devem seguir o documento Nomenclatura.
a. A distribuição dos componentes, o que chamamos de escalabilidade, deve ser balanceada de acordo com a sugestão da área que os criou mais a experiência da área de administração de componentes.
i. A distribuição de componentes, por vários servidores, faz com que a aplicação torne-se escalável. Sem esta distribuição, um software de caráter crÍtico estaria comprometido. O conhecimento desta distribuição deve estar de acordo com a especificação de hardware, ou seja, a infra-estrutura envolvida.
6. Administrar o software de publicação de páginas, conhecidos como servidores HTTP. Existem vários destes softwares e destacam-se o Apache (www.apache.org) e Internet Information Server – IIS (http://www.microsoft.com/windows2000/en/advanced/iis/default.asp?url=/windows2000/en/advanced/iis/default.htm).
a. Esta administração é no sentido de vigiar nomenclaturas, evitar longos códigos, promover uma consistente distribuição de diretórios.
i. Esta polÍtica deve ser informada aos stakeholders logo no inÍcio do projeto, conforme documento de Nomenclaturas, PolÍticas de Infra-Estrutura e Glossário.
7. Promover a manutenção da Intranet criada para facilitar o acesso dos stakeholders e evitar, dentro do possÍvel, a distribuição de e-mails desnecessários, estes podem ser difÍcies de se manter.
a. A Intranet deve conter uma forma de tracking3 de uma inclusão, alteração ou mesmo exclusão, que passa a ser lógica e não fÍsica, seja ela de um termo, uma polÍtica ou um diagrama.
b. Deve prever, também, uma polÍtica de acessos que permita a um stakeholder somente ler, alterar ou incluir, ou ainda uma combinação destas possibilidades.

Sugestão de rotina da Administração de Componentes

O máximo de atividades deste grupo devem ser automatizadas, afim de que seu tempo não seja totalmente consumido nestas atividades.

Criar Documento Visão

Introdução

Todo projeto deve possuir um documento o qual damos o nome de Visão.

Neste documento, temos um panorama da finalidade do software que será construÍdo, com suas atividades bem definidas. Deve ser prevista a Inclusão, Alteração. Deve haver uma forma de tracking de uma alteração.

Atores

Stakeholders – Administrador do projeto escolhido.

Cenário Principal

Informa o nome do projeto, local fÍsico onde o projeto pode ser guardado.

Software deve consistir o nome do projeto com permissões definidas pelo Administrador do software.

Digita um texto livre que define a missão do projeto.

Guarda em banco de dados as informações digitadas.

Informa os stakeholders, que participarão do projeto e seus direitos.

Cenário Alternativo

Permite inclusão de Stakeholders não cadastrados.

Criar Documento de Nomenclaturas e PolÍticas de Infra-Estrutura.

Introdução

Este documento possui regras que definem como devem ser os nomes de:

* Casos de Uso;
* Diagramas UML;
* Arquivos de Códigos (HTML, ASP, PHP, CLASS, JAR, JS, ETC.);
* Variáveis e seus retornos;
* Diretórios e subdiretórios;
* Servidores, como também seus caminhos;
* Clientes e suas localizações e forma de contato;
* Participantes do projeto e suas funções, como também formas de localização – e-mail, fone, endereço. Incluem-se aqui, os clientes.

Neste caso de uso Termo abrange: nomenclatura, polÍtica nome de pessoas e endereços fÍsicos.

Este documento será utilizado por todos os projetos da Empresa.

Atores

Stakeholders – Administrador, Analistas, Designers e Programadores do projeto criado.

Cenário Principal

Inclui, Altera e de forma restrita Exclui de forma lógica e não fÍsica. Porém, deve haver a possibilidade de exclusão fÍsica pelo Administrador do software.

Efetiva o tracking de uma inclusão, alteração ou mesmo exclusão, de um Termo. Este tracking mostra o histórico desde a criação do termo e suas alterações.

Permite a visualização do histórico no termo. Isto significa que todas as alterações, sofridas pelo termo são mostradas no software.

Importa os termos já adotados e marcados como Máster para este documento, evitando nova digitação.

As propriedades de cada Termo devem ser:

1. Nome do Termo e ou PolÍtica;
2. Utilização, breve descritivo;
3. Local. – Este item permite a busca em diretórios locais ou da rede de onde serão guardados os arquivos do novo software. O software parte do diretório principal criado pelo Administrador do Software. Aqui é apenas informado onde os arquivos do software serão criados.
4. Autor;
5. Data da Criação;
6. Data das Alterações;
7. Data da Exclusão.

Gera e-mail para os participantes de uma mudança ou inclusão ocorrida, podendo ser escolhido qual participante receberá o e-mail da alteração.

Cenário Alternativo

Um Termo, marcado como Máster, somente poderá ser alterado pelo Administrador do Software.

Criar Documento de termos do Glossário

Introdução

Deve existir um documento Glossário para cada projeto em que as equipes estiverem empenhadas. Cada software deve ter seu documento Glossário, pois, cada software tem suas peculiaridades que não são abrangidas pelos outros. Um Termo do glossário informa o que aquele termo significa para todos os envolvidos no software. Devido a esta unicidade, não existem Termos Máster.

Atores

Stakeholders – Administrador de Projeto.

Cenário Principal

Altera ou inclui um termo no documento de Glossário, os demais participantes são informados, de forma automática, via e-mail da mudança feita.

Gera, também a nova versão do documento, de modo que todos possam ver a nova alteração em HTML e PDF.

Exclui de forma restrita. Porém, deve haver a possibilidade de exclusão fÍsica pelo Administrador.

Deve haver uma forma de tracking de uma inclusão, alteração ou mesmo exclusão, que passa a ser lógica e não fÍsica, de um Termo.

Propriedades a Serem contempladas

Para cada termo do glossário, os seguintes tópicos devem ser contemplados:

1. Nome do Termo;
2. Breve descritivo de suas funções;
3. Sua finalidade;
4. Observações deste Termo.

Listar Termos do Glossário

Introdução

A visualização de um termo utilizado em casos de uso e outras documentações deve ser implementada a fim de permitir o melhor entendimento de um determinado ponto.

Atores

Stakeholders – Administrador, Analistas, Designers e Programadores do projeto criado.

Cenário Principal

Digita um termo e o software busca seu significado e outros dados dentro da base de dados.

Cenário Alternativo

Caso um termo não seja encontrado, permite o envio de e-mail para o Administrador, com o fim de solicitar a inclusão do termo.

Publicar arquivos em áreas de teste

A possibilidade de publicação em um determinado diretório é feita com a identificação, pelo software, da extensão do arquivo a ser publicado. A criação de um diretório virtual, para uso do Servidor HTTP, é feita pelo software e as permissões são fornecidas de forma automática.

Os componentes que serão abrigados pelo Servidor HTTP e pelo Servidor de Componentes seguem, também, uma inspeção pelo software Intranet. Caso não estejam dentro dos padrões definidos, incluindo seu tamanho, não será permitida a publicação do componente referido.

Deve haver uma forma de tracking de uma inclusão, alteração ou mesmo exclusão, dos arquivos desta área.

Criar Bancos de Dados de testes

Esta aplicação deve ser suficientemente inteligente para criar scripts de criação de bancos de dados, policiando as nomenclaturas de acordo com o disposto no documento Glossário.

No caso de banco de dados relacionais, a área não deveria permitir a normalização de tabelas, tratando-se classes como entidades de um banco de dados. Classes são classes, entidades de um banco de dados necessitam de normalização devido à redundância de dados e conseqüente ocupação de espaço fÍsico, além de que a normalização facilita consultas.

No caso de bancos de dados orientados a objetos, a representação do banco de dados deveria seguir o modelo de classes existente para a aplicação em jogo. Opções de criação de scripts seguindo as classes criadas devem existir.

Deve haver uma forma de tracking de uma inclusão, alteração ou mesmo exclusão, de qualquer entidade de um banco de dados.

Alterar PolÍticas de Acesso

O administrador da Intranet deve poder alterar os acessos dos stakeholders, de forma a permitir sua alteração, para qualquer combinação possÍvel.

Deve haver uma forma de tracking de uma inclusão, alteração ou mesmo exclusão, que passa a ser lógica e não fÍsica, de uma polÍtica de acesso.

Registrar Estimativas e Realização

O software intranet deve permitir se visualizar estimativas de cumprimento de prazo e custos. O software deve fornecer várias estimativas a partir de informações que são fornecidas pelo stakeholder.

Para este fim o software deve permitir as seguintes propriedades:

b) Número de Analistas;
c) Número de Designers;
d) Número de Programadores;
e) Número de LÍderes;
f) Número de Gerentes;
g) Número de horas de cada participante;

O número de casos de uso é calculado pelo próprio software.

O software deve guardar o histórico destas estimativas para averiguação futura.

Composição da Administração de Componentes

Creio que a composição da área é resultado direto do formato de cada empresa particular. A única necessidade é que este grupo exista, apesar de mudanças na gerência ou diretoria da Área de Tecnologia da Informação.

O descrito, nos itens anteriores, descreve a necessidade de um grupo bastante eclético.

Algumas pessoas crêem que estas pessoas, da Administração de Componentes, devem ser admitidas exclusivamente para este fim. Porem é necessário que se diga que estes profissionais podem, e devem, ser conhecedores do ambiente interno das áreas relacionadas à Tecnologia da Informação.

Podem ser profissionais que tem habilidades que se completam.

Verifique que muito pouco será acrescentado diariamente às tarefas deste grupo, depois de termos os itens anteriores bem definidos e automatizados.

Curso de UML

Curso de Desenvolvimento de Software Usando a Uml na Prática, aborda este e outros assuntos. Saiba mais em www.fabricaweb.com.br.

Implementar estas e outras soluções requer pensamento unÍssono. Isto somente será possÍvel se todos souberem como utilizar as variadas ferramentas disponÍveis. Uma das principais ferramentas a disposição é a UML e o Gerenciamento de Requisitos. Treinar stakeholders de software é investir em economia.

1 Stakeholders. Este termo vem do inglês. Na verdade são dois termos: "Stake" e "Holder", que significam depositário de dinheiro de apostas. O termo passou a ser adotado em informática como representando aqueles que tem interesse direto na consecução da automatização de alguma atividade. Neste sentido, são stakeholders, todos os envolvidos nesta automatização, como clientes, operadores, usuários do sistema, gerentes de projetos, programadores e analistas.
2 Componente é qualquer unidade que encapsule código. Veja que, diferentemente do que alguns programadores defendem, um arquivo que contém código, como por exemplo, HTML, ASP, PHP, JS, etc, também contem códigos e por esta razão são componentes.
3 Tracking, rastreamento de um determinado processo. Neste sentido, significa uma forma de saber: data, autoria e motivação de uma determinada inclusão ou motivação.