Archives for: July 2008
29.07.08
Understanding Database Licensing
To define the licensing scheme it is important to understand the various options involved. Choosing the wrong edition or the wrong licensing scheme can cause unnecessary costs.
DBMS has a lot of different editions and releases, and to choose which edition is the most suitable, it is necessary to analyze the features and capacity of each edition. For example, SQL Server 2000 Enterprise Edition supports up to 32 CPUs and 64Gb of RAM (more on 64-bit systems) while SQL Server 2000 Standard Edition supports up to 4 CPUs and 2GB of RAM.
After choosing the edition, it is necessary to choose the licensing scheme:
• Processor License: This is the simplest option. The cost of license is flat for each CPU running the database.
• Server and Device License: In this scheme, the cost of license is for each computer running the database (no matter how many CPUs it has) and for each device that accesses the data.
• Server and User License: In this case the cost of license is for each computer running the database and for each user that accesses the data.
The choice of licensing scheme depends on the number of registered active users in the application. For a Web Application with many users, as web site, for example, it is more suitable to choose the processor licensing option, while for an internal application with a few users it is more suitable to choose between user or device licensing.
Note: This information was based on the most common databases and describe the license options that their vendors offen provide. Before taking a decision of what is the best option for your company, please consult your database vendor for more information.
29.07.08
ISOSYSTEM on Oracle Real Application Clusters (RAC)
In July, SoftExpert products became compatible with Oracle’s Real Application Cluster (RAC) technology, offering to customers high scalability and availability to ISOSYSTEM Solutions. See More details of this technology:
Oracle RAC is a cluster database with a shared cache architecture that overcomes the limitations of traditional shared-nothing and shared-disk approaches to provide a highly scalable and available database solution for all business applications. Oracle RAC provides the foundation for enterprise grid computing.
What is RAC?
Oracle’s Real Application Clusters (RAC) option supports the transparent deployment of a single database across a cluster of servers, providing fault tolerance from hardware failures or planned outages. Oracle RAC running on clusters provides Oracle’s highest level of capability in terms of availability, scalability, and low-cost computing. Oracle RAC supports mainstream business applications of all kinds.
Continuous Availability
Oracle RAC provides very high availability for applications by removing the single point of failure with a single server. If a node in the cluster fails, the Oracle Database continues running on the remaining nodes. Individual nodes can be shutdown for maintenance while application users continue to work.
Flexible Scalability
Oracle Real Application Clusters provides flexibility for scaling applications. To keep costs low, clusters can be built from standardized, commodity-priced processing, storage, and network components. When you need more processing power, simply add another server without taking users offline servers to gain horizontal scalability. Oracle Cluster ware and Oracle RAC support up to 100 nodes in the cluster.
22.07.08
Documentar Projetos de TI: Fardo ou Necessidade?
Esse caso acontece sempre de forma semelhante, com algumas peculiaridades de cada empresa ou projeto, mas em linhas gerais, é sempre o mesmo.
O Gerente Noçãoless™ (GN) convoca os desenvolvedores para uma reunião onde um novo projetinho (calafrios nos desenvs) está se formando. Você já ouviu essa história antes, não é mesmo? Um projetinho, pequenino, baratinho, rapidinho de se fazer e manter. Tudo o que precisa ser feito já foi "levantado" em algumas atas de reunião e tudo são flores...
... até que a equipe de desenvolvimento começa a perguntar.
- Ahn, esse item aqui, "Criar um cadastro de clientes físicos e jurídicos.", o que exatamente o cliente quer?
- O GN™ volta com a resposta: são uns 20 campinhos, com pesquisa de CEP dinâmica, 18 campos de preenchimento, sendo dos quais 11 são obrigatórios e tem umas regrinhas de validação que eles querem também e... [mais algumas dúzias de requisitos entram].
Documentar é preciso, todos sabem disso, mas devido ao tamanho de alguns projetos, parece impraticável, um fardo burocrático e sem necessidade. Uma barreira para se chegar ao produto final, o conjunto de códigos que irá funcionar de forma coordenada e atender aos desejos do cliente.
De uma forma ou de outra, pessoas envolvidas com tecnologia entendem a necessidade de criar documentos, evidências, histórico e a indústria exige cada vez mais metodologias para gerar esse material de forma organizada. O maior problema atualmente enfrentado é justamente o custo da documentação.
Uma pessoa, ao encomedar o projeto de uma casa, entende perfeitamente os custos de um engenheiro ou arquiteto, ao projetar as plantas, calcular as quantidades de materiais, mão-de-obra, prestação dos serviços e obviamente, execução da obra. Tudo isso é documentado e o contratante paga por isso porque entende que sem esse plano e sem as plantas, nada irá sair do chão.
Agora o mesmo não é verdade para criar um aplicativo. Para reduzir custos, normalmente são cortados documentação e testes, justamente os dois pilares da qualidade. No final, ficamos, se muito, com um diagrama de base de dados mal feito. As atas de reunião dizem apenas linhas gerais como: quero uma casa de dois andares, com 3 quartos e cozinha ampla. A documentação verdadeira especifica quantos azulejos devem ser comprados para cobrir as paredes da cozinha, por exemplo. Em software, é isso que normalmente é cortado: a especificação, os casos de uso. Confia-se demais apenas em protótipos visuais e o cliente começa a mudar o escopo (scope creep, já falamos disso) porque ele disse na reunião que gostaria de uma interface divina.
Então, por falta de documentação, surgem falhas na comunicação entre as partes. O desenvolvedor pode criar algo formidável, mas que não era o foco do usuário: ele não precisava de um super cadastro, mas de um super relatório. Hoje em dia, testes de software ainda são propostos e projetados como um anexo ao desenvolvimento, como se fosse possível separar um do outro. Vejamos um exemplo simples abaixo:
Projeto XPTO
Planejamento e Documentação: Plano de Projeto, Casos de Uso, Diagramas de Classe, Base de Dados - 2000 horas
Desenvolvimento: Criar códigos, interface, montagem das telas, validações e toda a funcionalidade e correções - 5000 horas
Testes: 3000 horas
É claro que estou simplificando enormemente a divisão de tarefas, mas normalmente cortam-se horas de testes e de documentação para economizar e no final, todos saem perdendo:
- O sistema possui funcionalidades demais, que serão pouco ou nunca usadas;
- Há um alto índice de defeitos e erros;
- Os prazos foram todos estourados;
- O cliente perde a confiança na empresa desenvolvedora;
- A equipe fica desmotivada com o retrabalho e horas extras (muitas vezes não remuneradas);
- O cliente fica sem um produto necessário ao seu crescimento.
Mesmo em metodologias ágeis, alguma documentação é necessária. A forma de se usar o tempo e nível de detalhamento mudam de acordo com cada projeto. Mesmo o Extreme Programming, Scrum e Iconix exigem algum planejamento, mas é bastante comum o desenvolvimento iniciar com rascunhos em papel, linhas gerais do que a pessoa quer e alguns links para websites com funcionalidades que o cliente deseja.
Para se ter uma idéia de como um projeto pode sair do controle se não houver uma boa dose de planejamento e boa comunicação, certa vez, eu estava ministrando o treinamento de uma ferramenta que havíamos desenvolvolvido. O Analista de Negócios/Requisitos acompanhava e anotava as observações dos usuários. O treinamento essencialmente transformou-se em 3 semanas de levantamento de requisitos com literalmente dezenas de pessoas. Um dos usuários abriu o GMail e disse: queria que o sistema funcionasse assim. Outro foi mais longe: bem que podia ter aquelas ferramentas de desenho e edição do Word.
O sistema era para Web e tínhamos 2 semanas para colocar em produção. No final, tudo deu certo e algumas funcionalidades do GMail foram criadas, como o autosave e a parte de edição também foi criada, usando um componente comercial. A empresa levou prejuízo porque não houve um planejamento prévio e a documentação era bastante escassa e quase inexistente. Melhorou quando começamos a congelar os requisitos e aplicamos princípios do Scrum, já que o RUP sairia 40% mais caro... ou não?
O fato é que com a experiência, percebe-se que documentação é chato de se fazer e atualizar. Não há sensação de conquista, mas quando um projeto começa a dar errado, é muito bom olhar para o cliente e dizer: olha aqui, você aprovou exatamente o que fizemos, está escrito. Podemos mudar, mas o novo prazo será xyz. E acredite, a visão que esse cliente terá não é de um chato mercenário, mas de uma pessoa altamente profissional, organizada e que sabe o que está fazendo, mesmo que ele tenha que pagar mais por isso.
Moral do Post
- Defenda o projeto com a palavra escrita.
- Acordos verbais e camaradagem só funcionam quando tudo vai bem. Quando o tempo fechar, aquele que possuir evidências é que sairá vencedor.
- O cliente sempre tem razão, exceto quando o que ele se contradiz com o que foi escrito e aprovado 2 meses antes.
- Cortar documentação é o mesmo que cortar qualidade. Lembre-se que mesmo a metodologia mais ágil ainda exige o mínimo, como um e-mail.
- O fardo de levantar requisitos detalhadamente e fazer protótipos antes de começar a construir telas é recompensado depois, com menos retrabalho e mais prazo para alterações que serão pedidas fora dos acordos iniciais.
http://meiobit.com/documentar-projetos-de-ti-fardo-ou-necessidade
14.07.08
SoftExpert Starts New DBMS Validation
The Environment Validation team started, in July, DBMS (Database Management System) PosgreSQL validation process, which will be one more DBMS free option for installing ISOSYSYTEM.
Several tests will be performed, aiming at verifying if the tool meets predefined requirements. The expectation is that it will become an option to replace firebird, which has been showing some limitations due to ISOSYSTEM complexities. The limitations include:
-Data limit.
-Frequently corruption of database with large volume of Data.
-Low performance.
-Multilanguage limitations.
The change is focused on offering a reliable and robust database, which performance is equivalent to the best DBMS available on the market.
PostgreSQL is a fully-featured and free database. Its structure and architecture are similar to Oracle. Initially, it will be validated to those Operating Systems released for ISOSYSTEM. The following aspects will be analyzed: performance, data volume, reliability, information security, data structure and multilanguage support.
Besides validation in released Operating Systems, PostgreSQL will be tested and compared to other DBMS, such as SQL Server and Oracle, in Sizing tests. We hope that PostgreSQL performance is similar to both DBMS, thereby being a great option even for big customers.
At the end of this validation process, a Technical Report will be issued so as to verify if PostgreSQL has met expectations. In case of a positive answer, product adequacy will take place.
If having any questions, please contact by email the ones responsible for project - Cleiton Domazak cleitond@softexpert.com or Edilso Helmann edilsoh@softexpert.com.
09.07.08
ISOSYSTEM Validado para Windows 2008 Server 32bits
A partir de agora a SoftExpert conta com mais um SO homologado. O novo SO Server da Microsoft trouxe inúmeras inovações, entre elas o IIS que chega a sua versão 7 com uma cara nova e mudanças significativas na estrutura de menus, opções, funções e principalmente nas configurações do Web Site, permissões, Application Pool e MIME Types, um exemplo é a mudança no nome de “Virtual Directory” para “Application” e também a necessidade de adicionar módulos para funcionamento de algumas funcionalidades a exemplo da ISAPI do PHP que poderá somente ser utilizada se adicionada uma ”Role” chamada ISAPI Extensions.
O grande ganho do IIS 7 é a otimização de algumas rotinas e configurações que antes eram possíveis somente com um grande conhecimento dos comandos CSCRIPT e muita paciência, mesmo assim nem sempre resultavam no que se esperava.
Devido a essas grandes mudanças, o instalador do ISOSYSTEM terá que ser compatibilizado para que todas as configurações sejam feitas automaticamente pelo instalador, pois atualmente é necessária a configuração manual de todo o IIS 7 para o funcionamento do ISOSYTEM.
O ISOSYSTEM no Windows 2008 Server teve um grande ganho de desempenho, o exemplo mais notável disso é o PDF Converter que teve um aumento aproximado de 90 % no desempenho nas conversões dos documentos.
O único ponto negativo identificado foi a incompatibilidade do Windows 2008 Server com o Firebird 1.5, após a instalação do Firebird 1.5 o “Control Panel” do servidor trava assim que se tenta abri-lo, o mesmo acorre com o Windows Vista, a solução seria utilizar o Firebird 2.0 porém o WorkFlow não é compatível com esta versão do Firebird, vetando assim instalações em Windows 2008 Server com banco de dados Firebird. Os clientes que desejam utilizar o Windows 2008 Server e um banco de dados gratuito terão que aguardar a validação e adequação do ISOSYSTEM com o PostgreSQL.
Com a validação do Windows 2008 Server, foi desenvolvido um documento (TR000003) seguindo o mesmo padrão do Installation Guide juntamente com um vídeo que explicam todos os passos de configuração no Windows 2008, incluindo a preparação do ambiente.
O Laudo Técnico da validação do Windows 2008 Server está no ISOSYSTEM Document (LTEC000001).
XML Feeds