A questão da Unidade de Medida (e os Erros de Sistema???)

Muitas vezes nos deparamos com algo que parece extremamente simples no projeto de uma aplicação, porém, pode se revelar complexo quando de sua operacionalização.

O mundo real distingue entre coisas que podem ser simplesmente contadas e coisas que possuem valores agregados. Por exemplo, DVDs são um tipo de artigo que pode-se denominar de "countable", pois precisamos criar uma coluna em uma tabela (entidade) para que sua quantidade, digamos em estoque seja registrada. Entretanto existem produtos ou artigos (como líquidos ou carnes, que são medidos por peso, volume, ou alguma outra unidade).
E ai começa então o nosso problema, pois são produtos de valores medidos, e não simplesmente contáveis.
É natural que você quando estiver modelando o seu banco de dados, crie além da coluna para quantidade, uma coluna para identificação da unidade de medida, ou de armazenamento.Porém isto é mero formalismo pois nada garante nos resultados de uma aplicação.
Quando a aplicação desenvolvida tratar somente de unidades, ou seja, seu produto ou artigo é sempre um artigo "countable" os dados existentes no BD referentes à quantidade deverão sempre concordar com os valores existentes em contagem no mundo real.(Inventário de estoques).Desde que sejam lançadas as perdas e quebras.

Sempre que isto acontecer, todo mundo ficará feliz pela qualidade da aplicação e da integridade de dados do Banco de Dados. Entretanto quando estivermos trabalhando com estoques de produtos ou artigos que não se classificam simplesmente como contáveis, e sim de possuírem uma unidade de medida agregada ao valor quantitativo, e este fato ocorrer é claro que todos podem ficar felizes, mas é extremamente suspeito este resultado de concordância.

Vocês devem se perguntar o porque da minha colocação.

É que eu acredito por experiência que neste caso sempre devem ocorrer alguns erros, ou melhor, diferenças de valores entre o BD e o mundo real.

Existem três possibilidades de resultados entre o BD e o mundo real:

1) Podem ser exatamente iguais ao que efetivamente existe;
2) O valor do BD pode ser menor que o que existe;
3) Ou os valores do BD pode ser maior do que efetivamente existe.

Se tratarmos com artigos que tem quantidade com agregação de uma unidade de medida, e não simplesmente uma quantidade absoluta, o BD igualar seus valores de quantidade exatamente com o real, é bom demais para ser verdade.

Por exemplo, líquidos evaporam ou as balanças não são calibradas corretamente.

A nossa meta deve ser de manter cem por cento sem erro dentro de limites e nos preocupar somente com perdas e encolhimentos de valores muito grandes.

Porém o que deve ser nosso objetivo é entender que irá sempre existir uma perda constante por evaporação nos líquidos, ou pequenos vazamentos, ou modificação de peso por perda de líquido ou massa, a probabilidade desta perda acontecer é alta.
Logo dificilmente teremos o valor do BD igualado com o mundo real simplesmente através de recursos da aplicação ou do BD.

Por exemplo, um tanque de combustível. Sempre que abrirmos o tanque para realizar a medição e identificar quantos litros existem, haverá uma perda neste momento decorrente da expansão dos vapores do mesmo, logo a quantidade anterior menos quantidade retirada ou vendida nunca irá ser igual ao saldo atual.
Conclui-se que mesmo bem modelado um BD, podem ser apresentados resultados não previstos, sem que exista culpa na aplicação ou no próprio modelo projetado para o BD.
Agora cuidado para não inventar índices de correção de estoque aplicados automaticamente, ou algo similar porque você estará somente aumentando a complexidade da aplicação ou do BD sem nenhuma garantia absoluta de resultado.

Lembro-me certa vez em que realizava o modelo de dados de um supermercado e me deparei com dilema similar a este na hora de desenhar o processo relativo ao açougue e ao tratamento das carnes.

Carnes em Supermercados

É incrível, mas a quantidade de carnes que entram em um supermercado nunca é igual a que sai, por mais que realize um modelo de dados detalhado e especifique com qualidade a aplicação, dificilmente você terá números confiáveis.

Acontece que o que entra, por exemplo, é um traseiro bovino com digamos 30 Kg. Ele é primeiramente desossado. Temos então por lógica de composição um peso de ossos e um total de carnes. Até ai teoricamente tudo bem, pois já temos uma perda neste ponto que pode ser perda de líquidos na carne durante o processo de desossa.(temperatura ambiente, manuseio, ect)

As carnes são então classificadas conforme o seu tipo de corte, tais como alcatra, chã de dentro, picanha, maminha, etc. Mas não devemos esquecer que são retirados os excessos de sebo e gorduras das carnes. Digamos que são guardadas até o final do processo para serem pesadas e registradas as perdas deste material.

Estas carnes irão para os balcões, pesadas ou para serem pesadas no momento da compra.

Ai então podem acontecer dois fatos:

1) O Peso total vendido de carnes ser maior que o peso lançado no momento da separação dos cortes.

Erro do sistema? Não !

Simplesmente pode haver ganho de peso através de absorção de umidade e do resfriamento do balcão frigorífico onde as carnes estão expostas. Incrível mas isto acontece mesmo.

2) O peso total vendido ser menor que o peso lançado como entrada de estoques de carnes.

Se for considerado o valor da entrada antes da dessosa, e os traseiros por exemplo ficarem muito tempo inteiros ou expostos a uma temperatura alta durante o processo de dessosa, pode haver acentuada perda de peso, o que resultará num lançamento de carne dessosada em peso menor do que entrou.

Então o que objetivamos com este artigo e destacar a importância da utilização de unidades de medidas e do entendimento de seus reflexos no mundo real. Já encontrei analistas arrancando cabelos para descobrir em qual dos processos existia algum erro que se justificavam as diferenças de estoque entre o BD e o inventário, ou entre simplesmente o que fazer quando a diferença entre o valor que entra e o valor que sai não resulta em ZERO, e o estoque real é zero.

Em outro momento irei comentar a questão da identificação do corte das carnes, pois é outro ponto onde podem existir erros que resultam neste caso em um valor de estoque vendido maior ou menor ao valor do estoque que deveria ser vendido.


Posted by Felipe Machado em Sábado, Maio 01, 2004

Comentários:

Generalização -Tipologias de ocorrências ( O retorno) In English
A utilização de generalização em um modelo de dados possui diversos tipos de interpretações.
Ontem apresentamos somente o básico, por assim dizer, e hoje vamos evoluir um pouco mais em termos de aplicação das interpretações de generalização.
Iniciamos pelas generalizações do tipo disjoint, em que a interpretação dos objetos existentes no contexto nos faz concluir que existem múltiplos tipos de um determinado objeto que possuem atributos em comum, ou melhor, todos os atributos são comuns sempre, porém, objetos de uma categoria pertencem somente a esta categoria e a nenhuma mais.
Mas porque existe então a aplicação de Generalização? Não bastaria simplesmente escolher a nomenclatura mais significativa para este objeto, esta entidade?
Normalmente o que encontramos é que existem fatos no contexto que são relacionados somente a um destes objetos que estão na Generalização. Vamos a um exemplo para entendermos melhor a situação:
Identificamos a entidade Funcionários, porém também encontramos na análise do contexto os objetos engenheiro, motorista e secretaria como elementos distintos com tratamentos específicos em áreas distintas de negócios. Existe na organização um controle de veículos e quem o dirigiu em determinada data e horário, assim como existem projetos em que quem participa e possui informações de controle são os engenheiros responsáveis pelos mesmos e ainda por cima nos apresentaram a existência do papel de secretária que está relacionado ao agendamento de reuniões.



Observe que são três tipos diferentes de funcionários, e que possuem fatos associados a cada uma destas categorias. Já qualifiquei os três tipos como sendo nada mais nada menos que especializações de funcionários, ou seja, subtipos da entidade supertipo que é funcionário.
Como não existe em nosso exemplo nenhum atributo que seja específico das categorias (até poderia existir, mas não iremos usar no exemplo), existe a necessidade de um identificador do tipo de funcionário, um atributo Tipo_Funcionario, que terá os valores "E" para engenheiro, "M" para motorista e "S" para secretária. Vejam a tabela a seguir e o diagrama ER lógico básico. (atenção as ferramentas CASE não implementam esta representação).



Imagine agora que em nossos levantamentos para compreensão do contexto observamos que os engenheiros são responsáveis pelos projetos da empresa. Cada projeto tem um engenheiro responsável e um engenheiro pode ser responsável por muitos projetos na empresa.

Outrossim, identificamos também que os motoristas dirigem os veículos da empresa. Sendo que um motorista pode dirigir vários veículos e que cada veículo pode ser dirigido por múltiplos motoristas. Evidentemente em momentos diferentes. Já que nosso modelo de dados é espacial em termos de tempo.

Igualmente, Secretárias são responsáveis pelo agendamento de reuniões de projetos. Uma Secretária pode agendar múltiplas reuniões, porém cada reunião somente é agendada por uma Secretária somente.

Vamos ver como fica o nosso modelo neste caso, utilizando o Conceito de Generalização para a entidade Supertipo Funcionários e de Especialização para os Subtipos.



Poderia alguém perguntar: Mas para que serve utilizar esta notação?
A resposta é evidente, pois apesar de o modelo físico final implementar somente uma tabela, a tabela funcionários, os subtipos podem ser implementados através de views, e estas views estarem relacionadas então com Projeto, com Veículo e com Reunião.
O importante é a expressividade do mundo real, do mini-mundo que analisamos.
Como todos os elementos de funcionários se relacionam com departamento, como notou que observou a tabela apresentada o modelo lógico final ficaria:




Amanhã continuaremos nossa saga de exploração das opções de Generalização. Aguardem, que vem muito mais por ai.

Dúvidas e-mail me



Generalization - Typologies of occurrences (The return) . (Traduced by Elaine Daudt)

The generalization use in a model of data possesses several types of interpretations.

Yesterday we only presented the basic, so to say , and today we will develop a more little in terms of application of the generalization interpretations.

We began for the generalizations of the type disjoint, in that the interpretation of the existent objects in the context makes us to conclude that multiple types of a certain object that possess attributes in common exist, or better, all the attributes are always common, however objects of determined category belong only to this category and not more
Why it exists the application of Generalization then?

We identified the entity Employees, even so we also found in the analysis of the context the engineer objects , driver and secretary as different elements with specific treatments in different areas of business. It exists in the organization a control of vehicles and who drove it in certain date and schedule, as well as projects they exist in that who participates and it possesses control information they are the responsible engineers for the same ones and still for top they presented us the existence of secretary's role that is related to the arrange the meetings.



Observe that they are three types different from employees, and that possess facts associated to each one of these categories. I already qualified the three types as being anything else less than employees' specializations, that is to say, subtypes of the supertype entity that is an employee.

As it doesn't exist in our example any attribute that is specific of the categories , the need of a badge of the employee type, an attribute employees type, that will have the values " exists AND " for engineer, M " for driver and " S " for secretary. See the following table and the basic logical diagram ER. (attention the tools CASE don't implement this representation).



Imagine now that in our surveys for understanding of the context we have observed that the engineers are responsible for the projects of the company. Each project has a responsible engineer and an engineer can be responsible for many projects in the company.



Likewise , we also identified that the drivers drive the vehicles of the company. And a driver can drive several vehicles and that each vehicle can be driven by multiple drivers. Evidently in different moments, in as much as our model of data is spatial in terms of time.

Equally, secretaries are responsible for the dating of meetings of projects. A secretary cannot dating multiple meetings, even so each meeting is only dating by only a Secretary.

We will see as it is our model in this case, using the Concept of Generalization for the Super-type employees entity and of Specialization for the Subtypes.



It could somebody to ask: But so that it serves to use this notation?

The answer is evident, because in spite of the final physical model to implement only a table, the table employees, the subtypes can be implemented through views, and these inclination be related then with Project, with Vehicle and with Meeting.

The important is the expressivity of the real world, of the mini-world that we have analyzed.

As all the elements of employees are related with department, as it has noticed that it has observed the presented table the final logical model it would be:



Tomorrow we will continue our saga of exploration of the options of Generalization.

Await, it is coming much more about.

Doubts e-mail me






Posted by Felipe Machado em Sexta-feira, Abril 30, 2004

Comentários:

Generalização e Encapsulamento de Entidades

Quando identificamos entidades em um contexto caracterizamos as suas características através de seus atributos.
Analisamos a sua existência através do entendimento de um mini-mundo.
Muitas vezes encontramos entidades variadas em que ficamos em dúvida sobre a sua existência ou não. Encontramos e definimos a existência de objetos aparentemente distintos em classe. Porém temos que realizar a caracterização de entidades por semelhanças e diferenças
Por exemplo, suponha uma organização categoriza o trabalho que faz em projetos internos e externos.
Projetos internos são realizados em alguma unidade dentro da organização.
Projetos externos são realizados fora da organização.
Nós podemos reconhecer que ambos os tipos de projetos são semelhantes, pois cada um envolve trabalho realizado por empregados da organização dentro de um determinado horário, por exemplo.
Evidentemente que nós também reconhecemos isso há diferenças entre eles.
Projetos externos têm atributos específicos, como um identificador de cliente e o valor a ser pago pelo cliente.
Este processo de categorizar entidades pelas semelhanças e diferenças é o modelo conhecido como Generalização

Uma generalização é um grupamento estruturado de entidades que compartilham atributos comuns. É um método poderoso e extensamente usado por representar características comuns entre entidades enquanto preservadas as diferenças entre elas. É a relação entre uma entidade e um ou mais versões refinadas da mesma entidade. A entidade que é inicialmente refinada é chamada o supertipo e cada refinamento de versão da entidade é chamado subtipo.

Deveriam ser usadas hierarquias de generalização quando (1) um número grande de entidades parece ser do mesmo tipo, (2) Os mesmos atributos são repetidos para entidades múltiplas, ou (3) o modelo está evoluindo continuamente.
Hierarquias de generalização melhoram a estabilidade do modelo permitindo que mudanças possam ser feitas somente a essas entidades selecionadas para a mudança e simplificam o modelo reduzindo em muitos casos o número de entidades no mesmo.
Tenho observado em muitos fóruns mundiais a existência de um grande número de dúvidas na utilização da opção de Generalização, porém a maioria por falta de, um gasto de tempo ou um pouco de inexperiência, em montar composições de conceitos, de visualizar objetos embutidos em outros (encapsulamento).

Para construir uma hierarquia de generalização, todos os atributos comuns são designados ao supertipo.
No supertipo também é definido um atributo, um discriminador cujos valores identificam as categorias dos subtipos.
Atributos sem igual em alguma categoria devem ser definidos no subtipo apropriado.
Cada subtipo também herda a chave primária do supertipo.
Deveriam ser eliminados subtipos que têm só uma chave primária como regra.
Os subtipos são relacionados ao supertipo por um relacionamento um-para-um.

Generalização Disjoint e Overlapping

Uma hierarquia de generalização ou pode ser overlapping ou disjoint.
Em uma hierarquia overlapping uma instância de entidade pode ser parte de múltiplos subtipos.
Por exemplo, representar as pessoas em uma universidade você identificou a PESSOA como uma entidade de supertipo que tem três subtipos, PROFESSOR, STAFF, e ESTUDANTE.

É bastante provável que um indivíduo esteja em mais de um subtipo, uma pessoa qualificada STAFF também pode estar registrado como um estudante, por exemplo, neste caso então não temos a existência de um atributo qualificador no supertipo.
Em uma hierarquia disjoint, uma instância de entidade só pode estar em um subtipo.
Por exemplo, entidade EMPREGADO , pode ter dois subtipos, pode ter Engenheiro e pode ser Vendedor. Um empregado pode ser um tipo ou o outro, mas não ambos, o que justifica por si só a existência de um atributo qualificador, por exemplo, tipo_empregado

É muito importante desenvolver a nossa capacidade de abstração para visualizar estas ocorrências em um contexto sob análise.

Nos casos de Hierarquias disjoint é a existência muitas vezes de atributos específicos nas especializações (subtipos).
No exemplo da figura poderíamos ter a seguinte situação:
Engenheiro possui informações sobre seu registro no órgão de classe (No Brasil no CREA), além da sua especialização (Cntrução Civil, Mecânica, Eletrônica, etc) e Vendedor possui informações sobre linha de produtos que vende, região de atuação.
Estes dados são específicos de cada um dos subtipos apresentados, mas não fazem parte da descrição de todos os outros funcionários.
Como se implementa logicamente isto?

Através da criação de entidades subtipos, que no modelo físico iram existir fisicamente como tabelas relacionadas de um-para-um com o supertipo.

Para este exemplo não nos preocupamos com os datatypes dos atributos, motivo pelo qual todos estão com char(18).

CREATE TABLE Funcionario (
RG char(18) NOT NULL,
Nome char(18) NULL,
Endereco char(18) NULL,
Telefone char(18) NULL,
Tipo_Empregado char(18) NULL, PRIMARY KEY (RG ASC) (Não está no diagrama, só para destacar aqui sua importância)
)
CREATE TABLE Engenheiro (
RG char(18) NOT NULL,
CREA char(18) NULL,
Especializacao char(18) NULL,
PRIMARY KEY (RG ASC),
FOREIGN KEY (RG)
REFERENCES Funcionario (RG)
ON DELETE CASCADE
ON UPDATE CASCADE
)
CREATE TABLE Vendedor (
RG char(18) NOT NULL,
Linha_de_Produto char(18) NULL,
Regiao char(18) NULL,
PRIMARY KEY (RG ASC),
FOREIGN KEY (RG)
REFERENCES Funcionario (RG)
ON DELETE CASCADE
ON UPDATE CASCADE
)


Em breve vamos continuar a discutir a implementação de hierarquias efetivamente em modelos Entidade- Relacionamento através de Generalização.



Posted by Felipe Machado em Quinta-feira, Abril 29, 2004

Comentários:

You Need a Conceptually Oriented Programmer on Your Team - MARCH 29, 2004 (COMPUTERWORLD)
Opinion by Alexander Katsenelinboigen

"Encontrei finalmente quem concorde com minhas idéias"

- For much of the work that human beings perform, both the what and the how are defined. Under these circumstances, it's easy to evaluate employee performance or to devise hiring criteria. But where the task offers a limited degree of freedom, hiring managers must decide whether any marginal benefits to be gained with a more creative individual would justify the drawbacks, such as a higher salary.
Staffing software development positions is the case in point. For most companies, software isn't the principal product but a tool to support operations. Often, they lack in-house expertise in software development (especially given the methodological advances of the past decade). Companies need to devise hiring criteria for software developers, because those used in other fields translate poorly to IT.
For software developers, the what and especially the how of the work aren't rigidly defined. Gathering business requirements (the what) upfront is fraught with problems, because the requirements are usually ambiguous and will evolve in ways that will affect the software design. As for the how, programmers are often given a lot of leeway in the implementation with only loose guidelines. This shifts the burden of partitioning the task to the developer. All these factors have a bearing on the hiring criteria.
a highly simplified matrix of worker types and types of work (of course, each dimension isn't dichotomous; also, experience and creativity aren't mutually exclusive, but they're only made so here to illustrate in
The general trend today seems to be that the more conceptual approach is making it into the mainstream, from college curricula to best practices.
Still, many companies treat software development like Category 1 and thus prefer diligent, experienced workers, sometimes to the detriment of conceptually oriented ones. This can be a problem at companies where poor software practices are deeply ingrained. Where developers aren't required to program against a well-designed blueprint (a framework of abstractions), the benefits of hiring conceptually oriented programmers who can deal with architectural issues are particularly pronounced. Paradoxically, such companies tend to have rigid salary caps for programmers, narrow requirements and a habit of hiring technical-school types who might be experienced but lack an understanding of general issues. IT managers in these companies tend to quantify the amount of work to be done in terms of deliverables that business users care about (such as a certain number of screens with specific functionality) rather than decompose the application into appropriate abstractions (for example, for typical Web application layers -- front controller, session facade, entity objects and others). Quantifying the work this way makes management biased toward programmers who have narrow specializations.
How the system is decomposed and then aggregated has a major effect on the division of labor among developers, the number of developers needed and future maintenance costs. As a trivial but not such a far-fetched example, a project leader may simply split 50 screens among team members; alternatively, he could adopt a framework where individual screens are a byproduct of a particular methodology, which abstracts common logic into separate layers. Another benefit of a high-level approach is that abstractions reveal the underlying commonality of seemingly disparate modules. This comes to the fore when business needs are translated into software building blocks.
So the work accomplished is more a function of how the software system is decomposed (which hinges on developers' analytical skills) rather than of the number of programmers involved.
The Role of Culture
Lack of an IT culture may be one reason management fails to appreciate conceptually oriented programmers. Sometimes managers grow into leadership positions simply because of their seniority, experience or personal skills, and their overall understanding of software development isn't up to the task. Some managers believe that providing training in some software package or technology is sufficient. Another frequent mistake is to bring practices that succeed in small-scale projects into larger ones. But compared with building a shed (where one or two carpenters may suffice), building a skyscraper calls for an extensive hierarchy of people (architects, engineers, skilled and unskilled workers and others).
Of course, companies have limited resources, so they have to resolve the trade-off between a programmer's salary and other qualifications. The problem is that management tends to underestimate the need for a broader understanding of software design, even on the part of rank-and-file programmers.
What to Do
First, management must recognize the "fuzzy" nature of software development and promote (or at least be receptive to) conceptually oriented programmers. The selection process should emphasize candidates' analytical abilities rather than their experience in some narrow field (if both are too costly). Training should focus on general concepts rather than specific technologies. If Type 1 programmers are preferred, hire at least one person versed in architecture who can design a blueprint against which programmers will be required to code. I would go so far as to say that an architect should feel emotional abhorrence for inelegant solutions in order to stand up to short-term pressures, which invariably dictate clumsy solutions.




Para ler mais vá até a ComputerWorld





Posted by Felipe Machado em Quarta-feira, Abril 28, 2004

Comentários:

Sempre é bom receber notícias boas

Obrigado aos meus leitores


Prezado Autor,

Informamos que o livro "Tecnologia e Projeto de Data Warehouse"
está entre os títulos mais vendidos do mês de Abril.

EDITORA ÉRICA LTDA.




Posted by Felipe Machado em Terça-feira, Abril 27, 2004

Comentários:

O lado ainda intuitivo da análise de sistemas.

A nível empresarial, é importante assegurar que você entende o que seu cliente necessita.
Porém se analisarmos todas as metodologias de desenvolvimento de sistemas, veremos que todas sem exceção definem a existência de uma etapa de levantamento de necessidades, ou requisitos de sistemas. Entretanto em nenhuma delas encontramos alguma técnica estruturada que possibilite a execução desta etapa de forma não intuitiva ou completamente empírica.

A própria UML é elaborada dentro dos padrões de orientação a processos, apesar de definida como orientada a objetos, pois nenhuma das metodologias realizadas para a utilização de UML deixa de começar o processo todo de utilização das técnicas estruturadas pelos Use Case, o que nada mais é do que realizar uma análise através dos processos de negócio de uma organização.
Não existe nestas metodologias inclusive um casamento, uma aderência ao negócio em si, mas sim aderência aos processos individualizados, pois quando realizamos Use Case não estamos centrando os processos de forma completamente estruturada, pois os mesmos originam-se em um conjunto de "requisitos" que foram levantados ainda empiricamente, intuitivamente sem técnica específica, ou melhor, ainda sem foco de negócios, pois estamos prevalecendo mais sempre à técnica UML a ser utilizada do que ao entendimento efetivo do negócio para então obtermos o entendimento da necessidade.
Isto não é uma crítica à utilização de UML, mas um alerta de que mesmo com orientação a objetos, com a UML em si, os problemas de qualidade de software, de tempos de desenvolvimento e incidência de erros em projetos de software continuam ainda altos.
Muitas vezes temos sistemas desenvolvidos de forma rápida e com boa qualidade funcional, de interfaces, de navegação, porém incompletos no que tange às reais necessidades do usuário, sendo disfarçadas estas falhas através do que chamam de planejamento evolutivo da aplicação, como se fosse normal começar um sistema já com necessidades não atendidas, que fazem então parte da fase dois do sistema. Piada!
Não temos ou temos ferramentas de software que auxiliam o processo de levantamento de requisitos, tais como ferramentas de brain-storm, e/ou ferramentas de gestão do conhecimento?
Sozinhas sem a definição de uma técnica para tal, estas ferramentas poderiam auxiliar ou complementar a etapa de levantamento de requisitos?
A resposta evidentemente é não!
O que falta

Necessitamos é definir um conjunto de técnicas para o levantamento de requisitos e entendimento do negócio, e isto não está escrito em nenhuma das metodologias existentes no mercado, desde os tempos da análise estruturada que vimos buscando esta solução, mas como esta solução não está associada ou não é de interesse dos fabricantes de CASES do mercado, ela simplesmente até os dias de hoje não evolui, ou não se desenvolveu.
O exemplo que cito é simples, a área Contábil de uma organização qualquer, seja pública ou privada.
Você pode ser formado pela melhor universidade do país em Engenharia da Computação, domina todas as técnicas para construção de sistemas eficientes, desde a metodologia do estado da arte, até às ferramentas e linguagens de programação e suas técnicas, ou seja, você é uma sumidade em TI.
Mas o que você sabe sobre Contabilidade? Qual o objeto principal desta área? O que faz uma contabilidade?
Então se você tiver de desenvolver uma aplicação para a contabilidade desta organização, você irá começar do zero, onde seus conhecimentos por melhores que sejam de nada valem, pois você é um completo ignorante no assunto e você tem a obrigação de desenvolver um sistema! Começou a pressão sobre você! Corra!
Corra primeiro a um manual básico de contabilidade, inteire-se dos termos e conceitos, e por fim estude os processos contábeis básicos, e você terá dado o primeiro passo antes de iniciar o seu "levantamento de requisitos".
Agora como é de praxe e porque a hierarquia tem de ser seguida (outra bobagem inserida no contexto de análise e que somente atrapalha) você deve falar primeiramente com o executivo da área, o gestor da área provavelmente, e ele lhe dirá o que?
Ele irá falar em um nível executivo, e você vai anotar algumas coisas não importantes e provavelmente não anotará algumas muito importantes, até porque você ainda não tem domínio completo dos processos da área e objetivos reais do negócio.
Em síntese as suas anotações neste nível de levantamento não serão muito úteis ou quase nada úteis. E lá vai você começar as reuniões de levantamento de requisitos com os usuários. Qual a escala de usuários a ser entrevistada? É completamente aleatória para você ou é decidida por alguém responsável pela área e sob a sua ótica de operações, que necessariamente não é a ótica de sistemas.
A proposta
Nossa proposta que apresentamos neste primeiro "paper" sobre o assunto é que seja definida uma regra estruturada para a elaboração de uma grade de levantamento de requisitos. Mas para isto é necessário conhecer completamente a área de negócios? Não, temos de buscar uma alternativa para adquirir este conhecimento através do nosso avanço pela grade de entrevistas. Mas esta grade de entrevistas é definida exclusivamente pelo desenvolvedor?
Também não, exige a participação do usuário na sua confecção. Mas que usuário irá fazer esta participação? Preferencialmente o executivo mor da área, mas sob uma orientação de nossos objetivos e não somente dos dele.
Como é esta grade de cronologia de levantamento de requisitos?

Vamos apresentar aqui a nossa sugestão de grade inicial, a qual deverá ser preenchida pelos seus usuários como um todo, ou pelo gestor da área, seja que área for de negócios.

Observe que estamos propondo uma grade onde existe já uma pré-orientação a objetos, mas não necessariamente pois não especificamos ainda que resultado queremos obter em termos de técnicas de análise. Somente estamos propondo uma organização do processo de levantamento de requisitos em uma área de negócios desconhecida do desenvolvedor. A proposição é a criação de um hábito de buscar identificar antes dos processos, quais objetos realizam a dinâmica de operações da área de negócios, não necessariamente identificando seus processos ou use cases, pois não é este o objetivo do momento e não existe tempo tampouco para você aprender como funciona uma contabilidade, mas necessitamos conhecer a essência deste negócio, e isto pode ser realizado através da identificação de seus principais objetos, com reuniões rápidas e objetivas.
Em cada uma destas reuniões realizadas de acordo com a seqüência proposta deve resultar em um conjunto de objetos de interesse e alto envolvimento na área, porém nada nos garante que temos todos os objetos necessários neste momento, as técnicas que seguiremos apresentando neste blog em continuação a este artigo é que nos conduziram a um levantamento de requisitos efetivamente proveitoso e documentado o que é mais importante.
Em texto próximo iremos apresentar uma simulação de resultados da execução da grade de reuniões e um formato de matriz de CRUD (Create, Read, Update e Delete) adaptado para sua utilização em técnicas de análise de requisitos, e que define claramente a importância, classificação e dependência entre objetos de um projeto de sistemas.
Neste ponto gostaria de destacar que a organização inicial apesar de parecer simples, nunca é planejada desta forma e tampouco executada na grande maioria dos projetos de sistemas independentemente do porte da organização. O que encontramos é uma completa utilização de reuniões não planejadas e intuitivas na descoberta dos chamados "requisitos de sistemas".


Posted by Felipe Machado em Segunda-feira, Abril 26, 2004

Comentários:

A documentação nossa de cada dia nos dai hoje.......
by Márcio Oliveira

Muito se fala, e escreve, sobre os efeitos do excesso de informação dos dias atuais.

Somos vítimas das demandas de um mundo extremamente dinâmico, que nos exige competências muitas vezes de pouca ou nenhuma importância para a execução de nossas atividades.

Os profissionais modernos, especialmente os da área de tecnologia precisam constantemente expandir e reciclar seus conhecimentos.

O que fazer?

Existem vários caminhos para isto, sendo o mais freqüente, em minha opinião, o autodidatismo. O treinamento formal nem sempre é uma opção: o custo pode não caber no orçamento, pode não estar geograficamente próximo, pode nem existir. Pense nos profissionais de ponta.

E com relação à fonte da informação? Creio que o mesmo raciocínio pode ser aplicado: a busca através da Internet, fonte inesgotável de informação gratuita, é imbatível. Escolha um assunto e faça uma visita à sua livraria favorita. Dependendo da demanda do mercado, você vai achar uma quantidade imensa de livros: de "for dummies" e "aprenda em 24h" a "bíblias" e "official certification training". Faça as contas...

Ok, estamos decididos a estudar por nossa conta e fazer uma pesquisa. Damos uma olhada desconfiada no material que já temos e, receosos em relação à sua atualidade, partimos para a Internet. Se o assunto é complexo e de difícil localização, pedimos também uma ajuda aos amigos.

Eu e outros que conheço fazemos isto há anos.

Aqui começa a confusão!
Dê uma olhada nos classificados de informática. Os menores discos rígidos disponíveis são os de 40Gb. Há alguns anos eu usava um de 2 Gb, e já me parecia um exagero.

Agora experimente fazer o que eu fiz pouco antes de começar a escrever este artigo: examine a pasta que contém os seus documentos. A minha pasta "Meus Documentos" ocupa nada menos que 2.75 Gb, com 37751 arquivos divididos em 5654 pastas. Não tem nenhuma foto, vídeo ou arquivo mp3, os quais mantenho em CD Rom. Detalhe: perdi meu HD (sem backup), há dois anos.

Se fosse um internauta novato com banda larga, dava pra conceder um desconto pelo compreensível entusiasmo com a Web. Não é o caso. Moro no estado do Rio de Janeiro, na região dos lagos, e uso uma conexão discada de 33.6Kb.

A realidade é que, diante da urgente necessidade de obter material para incrementar nosso conhecimento a tendência é a busca atropelada por meio dos mecanismos citados anteriormente.

Diante da profusão de recursos terminamos a pesquisa com diversos arquivos e links. Os links (às vezes), vão para os favoritos, e os arquivos, normalmente para uma pasta com o nome do assunto.

Ao estudarmos o material obtido, a nossa tendência é a de parar na segunda ou terceira fonte encontrada, quando começamos a achar tudo igual, e ficarmos de avaliar as demais quando tivermos tempo. Este tempo, naturalmente, será dedicado a alguma outra pesquisa, possivelmente sobre o mesmo tema. E assim a "saga" continua...

E a pasta com o nome do arquivo? Provavelmente vai ficar do jeito que estava, sem um índice ou outra referência ao seu conteúdo e, ainda por cima, correndo o sério risco de ganhar uma "irmã gêmea" em outro diretório, depois que decidirmos por um novo modelo de organização.

Algum dia, quando precisarmos liberar espaço no disco rígido, teremos a estranha sensação de estar examinando o computador de outra pessoa...

Alguma idéia?

Várias!

Ao localizarmos ou recebermos uma informação deveríamos, no mínimo:

 Verificar se a fonte da informação merece crédito;
 Avaliar a relevância do seu conteúdo, segundo nosso ponto de vista;
 Compará-lo ao material que já possuímos;
 Armazená-lo e catalogá-lo junto aos materiais afins;

Quem tem tempo para fazer isto?

Bom, pense no tempo que você gasta fazendo a pesquisa. Pense no sufoco de ter que desenvolver uma competência mínima num determinado assunto até depois de amanhã. Use isto como argumento para se convencer a manter um mínimo de organização.

Definir uma estrutura de diretório simples para o material de pesquisa é muito saudável. Por exemplo, você pode criar uma estrutura de pastas como: e-books, artigos, tutoriais, programas, etc. Depois replique esta estrutura sob cada assunto pesquisado.

Agrupe os assuntos em categorias afins, numa estrutura hierárquica. O diretório Análise, por exemplo, poderia conter os subdiretórios Orientada a Objetos, Estruturada e Essencial. Dentro de cada um deles teríamos uma réplica da estrutura proposta no parágrafo anterior. Isto também vale para organização dos seus bookmarks.

Crie índices em cada pasta. Uma vez definida a estrutura que vai ser replicada, crie um modelo no seu editor de texto. A cada documento adicionado, basta criar uma nova entrada no índice, e um pequeno resumo do conteúdo do documento.

Também existem ferramentas capazes de criar e atualizar estes índices. Infelizmente a maioria é paga.

Uma ferramenta muito interessante, capaz de fazer a pesquisa pelo conteúdo dos documentos, é o Inforapid, disponível para download . É gratuito para uso não comercial, e faz busca de documentos espalhados em redes, até mesmo por links neles contidos. Os resultados das pesquisas são exibidos de forma semelhante a ferramentas como o Google ou Altavista.

Invista também um tempo para registrar o conteúdo dos arquivos armazenados em CDs. Vale a pena transferir para eles o material que você não está usando mais. Graças à volatilidade que o conhecimento assume hoje, em pouco tempo ele poderá adquirir um valor muito mais histórico.

Procure no Superdownloads ou no Download.com que você irá encontrar vários sharewares com esta finalidade. Uma planilha eletrônica é uma alternativa válida.

Depois da tarefa inicial de tratar o legado, aposto que o seu processo de qualificação ficará muito mais eficiente.






Posted by Felipe Machado em Domingo, Abril 25, 2004

Comentários: