[13] The End

Bom, pessoal, hora das despedidas.

Obrigado à professora Renata e aos colegas pela paciência de ler (e muitas vezes até se dar ao trabalho de comentar!) estas mal tecladas linhas.

O balanço final dos blogs me parece mais positivo do que eu, particularmente, esperava. E todos lucraram com a disciplina, descobrindo que tratamento de informação é matéria complexa e sujeita a meandros e rigores que vão além do que supõe nossa vã filosofia (e o Excel).

Podemos não ser ainda capazes de utilizar plenamente as ferramentas disponíveis para tratamento de informação, mas já sabemos que várias, diferentes, existem.

[12] Gerenciamento de Projetos

Ok. Último resumo. Sobre Gerenciamento de Projetos, baseado na apresentação feita em aula por Nádia, Rafaela e eu. E dessa vez não justifiquei minha fama de falar demais em apresentações. Nádia e Rafinha conseguiram me superar!

Projeto é um esforço temporário empreendido para criar um produto ou serviço único, com início e fim definidos. Gerenciar o projeto é planejar, acompanhar e controlar todos os seus aspectos, e a motivação de todos os envolvidos, de forma a alcançar dentro do prazo, custo, qualidade e performance especificados os objetivos inicialmente estabelecidos.

Historicamente, pode-se traçar a trajetória do gerenciamento de projetos desde antigas idéias Confucianas, na China, passando bem mais recentemente, no início do século XX, por Henry Gantt seus gráficos, WBS (Work Breakdown Structure), APS (Analytical Project Structure). Nos anos 50 surge o PERT (Program Evaluation and Review Technique), como ferramenta auxiliar para o desenvolvimento dos mísseis Polaris para a Marinha americana, seguido pelo CPM (Critical Path Method), desenvolvido pela DuPont e Remington Rand, e voltado para a instalação e manutenção de plantas industriais. PERT e CPM foram utilizados pela NASA nos anos 60 para o desenvolvimento do Projeto Apolo. Nos anos 80 o PMI (Project Management Institute) delineou, através do PMBOK (Project Management Body of Knowledge), linhas mestras que recomendava como aplicáveis a projetos em geral.

Em termos gerais, projetos são abordados sistematicamente como uma sequência de fases (Início, Planejamento, Execução, Monitoramento, Encerramento) onde Tempo, Custo e Escopo são as variáveis que devem ser controladas.

A abordagem PMBOK expande e detalha as variáveis a gerenciar. Além do PMBOK, outros métodos padronizados de gerenciamento são muito utilizados (por exemplo, ISO 10006, CCPM, PRINCE2).

Métodos de contabilização (Project Accounting) podem e devem ser utilizados, bem como ferramentas informatizadas, como MS Project e MS DynamicsGP (Microsoft) e PROF (DBConsult), por exemplo, de modo a facilitar o gerenciamento de projetos.

[11] ERP, Data Warehouse et al

Na última aula fomos presenteados com uma palestra extremamente interessante sobre ERP (Enterprise Resource Planning), ministrada pelo senhor Fábio Medeiros da MD Sistemas.

O Sr. Fábio é sócio da MD Sistemas, que se dedica à implantação de sistemas ERP (Sapiens da Senior Systems) em empresas de diferentes segmentos de negócios, e traçou um esboço abrangente com os propósitos, funcionalidades e limitações de um sistema ERP, além de discorrer sobre as peculiaridades e dificuldades para implantação do mesmo.

Sintetizando, um sistema ERP busca abrigar sob regras comuns todos os dados de interesse da empresa (administrativos, contábeis, de vendas, de produção, de compras, etc), interligando-os e buscando evitar desperdícios e esforços desnecessários, como a entrada repetida de um mesmo dado, a representação de um mesmo dado sob formas diferentes, e assim por diante. O objetivo é prover informações que auxiliem as decisões negociais de uma empresa de forma mais rápida, precisa, transparente e inteligível.

Em seguida a professora Renata introduziu o conceito de Data Warehousing (DW). Numa comparação cinematográfica, bancos de dados de sistemas ERP guardam os fotogramas dos eventos empresariais, enquanto o DW procura estruturar e guardar o filme inteiro. Isto se presta a estudos, projeções, acompanhamento de tendências, identificação de padrões, sendo poderoso auxiliar na definição de estratégias para os negócios. Guardando as devidas proporções, poderíamos dizer que um sistema ERP é ferramenta eminentemente tática e subsidiariamente estratégica, enquanto o DW é eminentemente estratégico (e subsidiariamente tático). Uma vez estruturados e armazenados, os dados ficam disponíveis para a aplicação de técnicas, métodos e ferramentas analíticos, como OLAP (OnLine Analytical Processing) e Data Mining.

E para finalizar a aula, fomos apresentados ao conceito de sistemas especialistas, que buscam mimetizar o "comportamento" de um especialista trilhando uma "árvore de decisão" de modo a obter respostas finais precisas e consistentes. Exemplos: Sistemas eletrônicos para regulagem de motores automotivos, que captam através de sensores os parâmetros de funcionamento de um motor e indicam os ajustes que precisam ser feitos. Ou o caso da malária (este sem o adjutório de recursos eletrônicos): a malária é doença comum na região norte/centro-oeste do país, mas a partir da década de 50 foi praticamente erradicada no sul/sudeste. Com as migrações internas, a malária reapareceu recentemente nestas últimas, mas frequentemente não é diagnosticada devido à falta de experiência dos médicos da região com a doença. Preocupado, o Ministério da Saúde reuniu um painel de especialistas em malária, na Fundação Oswaldo Cruz, para que estes desenvolvam um protocolo para diagnóstico da doença. O protocolo (ainda a ser publicado) consiste basicamente numa "árvore de decisão", com perguntas e testes norteando o diagnóstico. A folha de protocolo (com procedimentos do tipo se febre>39º então prossiga ; se febre ocorre de 3 em 3 dias então prossiga ; etc) pode ser considerada um "sistema especialista": permite a não-especialistas alcançar um diagnóstico correto, emulando os procedimentos de um especialista.

[10] XML

Hoje nossa turma foi apresentada às linguagens de marcação (Markup Languages), que usam tags (rótulos, marcadores) para instruir sobre o quê se deseja fazer com um determinado dado.

Começamos direto com a XML (eXtensible Markup Language), uma linguagem de marcação parecida em alguns aspectos com a HTML (Hyper Text Markup Language) porém mais poderosa e flexível, no que se propõe a fazer, com tags de livre definição. A XML foi desenvolvida para descrever e transportar dados entre nós da rede (internet ou outra), enquanto a HTML está mais voltada para a exibição de dados. A aplicação de estilos e firulas aos dados pode ser especificada com o uso da XSL (eXtensible Stylesheet Language)

Numa descrição abreviada, você: diz como quer estruturar, envelopar e transportar seus dados, com a XML ; diz como quer que eles sejam "embelezados" para apresentação, com a XSL ; mostra afinal na sua página da internet, com a HTML.

Fizemos alguns exercícios (nosso grupo, como de praxe, loosely envolving Juan, Renan, Tissiana e eu) estruturando dados com XML, que envolveram uma fase conceitual de observá-los inicialmente no velho modelo de "árvore invertida".

A "beleza" das linguagens de marcação, me parece, está em usar um arcabouço primitivo de extrema simplicidade (caracteres e arquivos texto) para obter resultados e soluções complexos. Isto cria uma razoável independência de protocolos, sistemas operacionais, hardware, etc. Afinal, "todo mundo" é capaz de gerar, ler e carregar ASCII!

Por fim, a professora nos deu o "caminho das pedras" para solucionar os problemas com a base de dados da clínica médica, apresentando uma consulta SQL que permite recuperar dados em diferença entre duas tabelas.

Ah! Em tempo: bem vindos ao Miss Blog 2007, que vai escolher uma (um?) digna representante das blogueiras (blogueiros?) fucapianas.

[9] Banco de Dados - III

Voltamos ao problema da montagem do banco de dados para a marcação de consultas de uma clínica médica, abordando-o agora à luz dos novos conhecimentos adquiridos ao longo das duas últimas aulas.

A definição dos dados a serem guardados e tabelas a serem montadas foi relativamente sopa-no-mel. A estruturação dos relacionamentos e montagem de consultas para mera visualização dos dados inseridos também pode ser classificada na categoria mamão-com-açúcar.

A coisa emperrou seriamente quando chegamos à fase de construir consultas SQL para recuperar e manipular os dados armazenados de forma que se mostrasse útil para os usuários finais do sistema (em especial a secretária e o paciente). Eu, Juan, Renan e Tissiana quebramos a cabeça, sem chegar a uma solução satisfatória.

O banco de dados obtido como produto final é responsabilidade minha. Será entregue para a professora e pode ser muito útil como exemplo de violações e transgressões às normas do modelo relacional. O pior é que não está funcionando!

De qualquer forma, valeu para o aprendizado de como é importante, mesmo para bancos de dados aparentemente simples, o esmiuçamento do problema na fase conceitual e uma detalhada e documentada estipulação do modelo relacional.

O mais valioso destas aulas foi visualizar as diferenças entre ferramentas. Por que usar um SGBD no lugar de uma planilha eletrônica? Deu pra notar que o SGBD é ferramenta mais adequada quando uma coleção de dados tem perspectiva de vir a ser muito grande, e seja atualizada constantemente.

Além disso, e mais importante: é uma ferramenta que permite diferentes formas de recuperação, visualização e manipulação dos dados sem que seja necessário alterar a estrutura onde os mesmos estão guardados (desde que estas estruturas tenham sido adequadamente especificadas e montadas).

[8] Banco de Dados - II

Querido diário

Hoje demos continuidade ao nosso aprendizado sobre o Access.

Aprendemos sobre o uso da SQL como linguagem para consulta e manipulação de um banco de dados. Usamos um "banco de testes" preparado pela professora com um sistema de reservas para companhias aéreas.

Vimos sobre o uso das cláusulas SELECT, FROM, INNER JOIN e WHERE da SQL, e de alguns operadores como AND e IN, nas consultas de seleção.

Nota 1: Levar uma caixa de bombons pra Márcia.

Vimos também o uso das cláusulas UPDATE e SET para consultas de atualização e INSERT INTO para consultas acréscimo.

Nota 2: Levar uma caixa de bombons E um buquê de flores pra Márcia.

[7] Banco de Dados - I

Querido diário

Hoje nossa turma foi conduzida ao laboratório de informática pela Profª Renata, e apresentada pela primeira vez (ou a primeira vez para a maioria da turma, pelo menos) ao Access - o sistema gerenciador de bancos de dados de uso geral da Microsoft.

Nosso objetivo, conforme colocado pela professora, será desenvolver um banco de dados para a marcação de consultas de uma pequena clínica com quatro médicas de diferentes especialidades. Não deve ser difícil. Afinal, a Márcia, secretária do meu dentista, faz isso todo dia só com a ajuda de uma pequena agenda, um lápis e uma borracha.

A professora ficou tentando nos fazer perder tempo discutindo e montando um modelo conceitual para os dados. Mas nós não estávamos dispostos a perder tempo com tais detalhes: o negócio é meter logo a "mão na massa"!

Recebemos então as primeiras noções sobre o uso do Access, com apresentação das telas do mesmo.

Depois aprendemos sobre a definição de Tabelas (onde os dados serão guardados), os campos que formam seus registros, características de cada tipo de campo, definição de chaves primárias, secundárias e estrangeiras.

Definidas as tabelas, aprendemos sobre como estabelecer os relacionamentos entre as mesmas, através das chaves.

Nota 1: A professora tinha razão. Devíamos ter perdido mais tempo com o maldito modelo conceitual.
Nota 2: Convidar a Márcia pra jantar - ela é muito mais inteligente do que eu imaginava!