Desenvolvimento de Software Orientado a Negcios, uma nova abordagem sobre o conceito de desenvolvimento de software.

Magno de Andrade Queiroz1

Resumo Este artigo formaliza uma nova abordagem para a implementao de softwares com objetivos bem especficos no sentido de propor um novo paradigma para o desenvolvimento de sistemas. Como Principais resultados obtm-se uma maior agilidade no processo e conseqentemente a reduo de custos financeiros, tempo e mo-de-obra empregada em projetos de desenvolvimento de sistemas de informao visto que o modelo atual de desenvolvimento de software apresenta altos custos e longos prazos. Para isso realizou-se um experimento focado em avaliar a viabilidade e possveis benefcios no uso do paradigma relacionado. Palavras Chave Engenharia de Software, Paradigmas, Mtodos geis, Mtricas de Software Abstract This article validate a new approach for software development with specific objects to purpose a new paradigm in software engineer that gives as results a better agility to the process and consequently reduces financial costs, time and human resources employed in information systems projects, Once the software development model is inefficient when talk about aspects like budget and duration .For this reason have been made an experience focused on evaluate the feasibility and possible benefits in using the paradigm of related tool

Key words: Software Engineering, software metrics Paradigms, Agile Methods,

1- Introduo
1

Bacharel e cincia da computao pela Universidade Federal da Bahia UFBA (2005). Atualmente Diretor de pr-vendas da Softwell Solutions, tendo experincia de anlise de sistemas, modelagem de dados, desenvolvimento de sistemas, banco de dados, programao, metodologias geis de desenvolvimento, modelagem de processos, gerncia de projetos. magno.queiroz@gmail.com

O principal desafio da engenharia de software prover metodologias capazes de desenvolver software, com qualidade, cumprindo prazos e sem necessitar de mais recursos que os alocados. Sem dvidas a principal dificuldade encontrada a falta de um processo bem definido de desenvolvimento de software, isso implica diretamente em altos custos financeiros e muito tempo gasto para se implementar solues computacionais (Pressman, 2007). Aliado a este cenrio, a falta de ferramentas robustas capazes de suprir todas as etapas do processo de desenvolvimento sem dvidas colabora para altos ndices de insucesso em projetos de software(Gartner 2009). O Desenvolvimento de Software Orientado a Negcios visa, atravs de uma nova abordagem para o processo de desenvolvimento, prover redues de recursos, tanto financeiros quanto recursos humanos e tempo gastos nos projetos. Para isso esse novo paradigma prope, alm da adoo de prticas geis de desenvolvimento, a sua principal inovao que a extino da codificao escrita na fase de implementao, por se tratar de uma etapa muito dispendiosa no processo de desenvolvimento. Desde o incio da computao, por volta da dcada de 40 quando s se havia manipulao de bits, j se fomentava a necessidade de se elevar o nvel da forma de programar computadores sem se perder o poder da linguagem binria. Com isso surge o assembly na dcada de 50, o que resultou em uma grande revoluo na rea de computao, pois j se era possvel escrever programas usando uma estrutura mais intuitiva que zeros e uns atravs desta forma de codificao (OReilly, 2009). A partir da outras grandes revolues surgiram nas linguagens de programao, e nas arquiteturas de desenvolvimento de software. Os problemas ficam cada vez mais complexos e as linguagens precisaram evoluir para serem capazes de solucionar tais problemas. Surgem linguagens estruturadas, funcionais, dentre outras, e com elas a formalizao de conceitos como estruturas de repetio, condicionais, funes, procedimentos, estruturas de dados, que sem dvida ajudaram a abstrair ainda mais a forma de se implementar solues computacionais para problemas do mundo real. Ainda nessa poca a limitao da computao era o hardware, ou seja, as linguagens eram extremamente poderosas, mas as mquinas eram caras e de baixo poder computacional. No final da dcada de 60 os pensadores da poca se reuniram para discutir a necessidade de se encarar o processo de desenvolvimento de software como uma engenharia, grandes nomes como E.W. Dijkstra, H.R. Gillette, R.M. Graham, M.D. McIlroy, estiveram presentes em um encontro intitulado de The Nato Software Engineering Conference (NESC,1968) onde foram abordadas tendncias e padres que deveriam ser seguidos no processo de desenvolvimento, nessa poca j se pensava em desenvolvimento de software como um processo de engenharia e conceitos como modularizao e componentizao comeariam a surgir.

Mais adiante surge a programao orientada a objetos, uma outra grande revoluo da computao, pois eleva-se o nvel de abstrao e as solues computacionais so facilmente modeladas utilizando esse paradigma. Junto a isso surgem poderosos sistemas gerenciadores de bancos de dados ( SGBDs) que colaboraram bastante nas implementaes de sistemas de informao. Neste contexto a engenharia de software colabora com os Padres de Projeto (Design Patterns) no sentido de padronizar e agilizar a implementao de solues. (Erich Gamma, Design Patterns: Elements of Reusable Object-Oriented Software, 1995) Todas as revolues ocorridas na computao foram motivadas primeiro para se elevar cada vez mais o nvel de abstrao tornando os cdigos cada vez mais intuitivos, porm no deixando de lado as limitaes de hardware que sempre inviabilizam tais mudanas, segundo para facilitar o processo de desenvolvimento de software, tornando-o cada vez menos complexo. Nesse cenrio surge o conceito de Distncia Cognitiva que pode ser definido como: Quantidade de esforo intelectual que tem que ser despendido por desenvolvedores de software de um estgio de desenvolvimento at outro. (Krueger, 1992), e a engenharia de software tenta, em cada paradigma criado, reduzir a distancia cognitiva na produo de sistemas, ou seja tornar o processo de desenvolvimento menos moroso, este o objetivo da Orientao a Negcio. O cenrio atual completamente diferente, hoje existem hardwares extremante poderosos e de custos relativamente baixos, e o que se fomenta atualmente so mudanas nas reas de desenvolvimento de softwares com o intuito de elevar o nvel de abstrao tornando o desenvolvimento muito mais simples e menos custoso. Nos ltimos anos diversas linguagens foram criadas e outras modificadas, porm todas elas sobrepem os mesmos conceitos, ou seja, as diferenas so mnimas e na sua forma geral elas possuem a mesma estrutura e o mesmo conjunto de conceitos. Recentemente surgem conceitos como orientao a aspectos1, MDA2, Ontologias3, WISEWIG4, BPM5, sempre com o objetivo de se elevar cada vez mais o nvel das solues.

orientao a aspectos - www.aspectos.org 2- MDA http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER06/dias.pdf 3Ontologias:- http://www.inf.ufes.br/~falbo/download/pub/2004-JIISIC-1.pdf 4WISEWIG - http://wisewig.sourceforge.net/ 5BPM: CBOK- http://www.theiia.org/research/common-body-of-knowledge/
1-

Outro fator que estimula a formalizao desse novo paradigma a atual situao do cenrio de mo-de-obra disponvel no mercado, existe uma variedade de profissionais especializados em arquiteturas, que hoje so consideradas ultrapassadas, mas que h pouco tempo atrs eram
3

consideradas de altssima tecnologia. Nota-se tambm que o custo e o tempo que se perde para capacitar estes profissionais em linguagens atuais um fator impactante nos custos do projeto, visto que as linguagens se atualizam diariamente, e ter profissionais especialistas disponveis no mercado algo extremamente complicado. A figura abaixo demonstra bem esse cenrio.

Figura 01 Cenrio Atual de mo-de-obra (fonte: elaborada pelo prprio autor, 2008)

A Figura 01 ilustra que a cada dia surgem novas tecnologias que tornam mais difcil o domnio de todas elas por um profissional da rea de TI. A idia ter-se ferramentas suficientemente robustas e intuitivas, de maneira que todos os profissionais, independente da tecnologia em que so especialistas, sejam produtivos em quaisquer projetos. Para isso torna-se necessria a utilizao de ferramentas capazes de prover essa abstrao. O modelo de desenvolvimento utilizado atualmente alm de improdutivo muito custoso e extremamente acoplado aos especialistas em certas arquiteturas e linguagens. O objetivo apresentar uma arquitetura que abstraia a codificao e deixe em evidncia as regras e fluxos de negcio, gerando assim um maior aproveitamento do tempo de concepo e desenvolvimento para atividades distintas como especificao, modelagem, prototipagem em menos atividades alm de unir atividades afins com o objetivo de customizar o processo de desenvolvimento de software e conseqentemente reduzir a Distncia Cognitiva no processo de desenvolvimento de solues computacionais. Para isso prope-se a utilizao de ferramentas e estruturas, suficientemente robustas, capazes de desenvolver sistemas complexos, atuando em todas as etapas de desenvolvimento, desacoplando ao mximo das linguagens de programao, utilizando, por exemplo, fluxos, diagramas visuais, componentes de software, e muitos outros conceitos que servem como arcabouo dessa arquitetura proposta. Ou seja o programador no precisa ser especialista em uma determinada tecnologia, basta conhecer lgica de programao e a regra de negcio para que ele seja produtivo
4

2- O Desenvolvimento de Software Orientado a Negcios

O Desenvolvimento de Software Orientado a Negcios um paradigma que, por meio da unio de vrios conceitos como: Ferramentas RAD1, orientao a eventos, reutilizao de componentes de software, mtodos geis de desenvolvimento, linguagens de quarta gerao (4GL) e de altssimo nvel (VHLL)2, sistemas de transformao (XSTL 3, MDA4), BPM5, WISEWIG6, dentre outros, visa, sobretudo aumentar a produtividade e reduzir os custos no processo de desenvolvimento de software. Como se sabe existem diversas linguagens de programao, porm quase todas so bem semelhantes no que diz respeito a sua estrutura e conceitos. de conhecimento notrio que as linguagens atuais possuem um grande e vasto conjunto de funcionalidades e um grande conjunto de termos sintticos o que dificulta o aprendizado de sua estrutura por parte do programador. O ser humano tem um conjunto finito de informaes que ele consegue assimilar, linguagens atuais so muito poderosas, mas so de difcil assimilao por possurem muitos termos, e que muitas vezes no so nada intuitivos. Alguns IDEs procuram resolver isso permitindo que o programador utilize varias linguagens de programao em seus cdigos, isso facilita muito, mas no resolve o problema pois de qualquer maneira o programador tem que dominar uma grande quantidade de informaes acerca da linguagem. O foco do da arquitetura de desenvolvimento sugerida o negcio, ou seja, a linguagem (linha de cdigo) um mero detalhe, o programador deixa de ser especialista na linguagem para ser especialista no negcio, podendo assim redistribuir o tempo economizado na codificao em outras etapas do projeto.
12-

34-

5-

6-

RAD - Rapid Application Development - http://www.sei.cmu.edu/ VHLL Very high-level programming language http://darynholmes.wordpress.com/2008/04/07/very-high-level-language%E2%80%93-so-what/ XSTL- Extensible Stylesheet Language Family - http://www.w3.org/Style/XSL/ MDA - Model Driven Architeture - http://wer.inf.pucrio.br/WERpapers/artigos/artigos_WER06/dias.pdf BPM - Business Process Management CBOKhttp://www.theiia.org/research/common-body-of-knowledge/ WISEWIG - What-You-See-Is-What-You-Get- http://wisewig.sourceforge.net/

A proposta ao invs de se utilizar cdigo escrito utilizar-se de um modelo de programao baseada em fluxos intuitivos, ou seja, no se tem a necessidade de se escrever cdigos e sim utilizar fluxogramas seguindo uma abordagem estruturada em que os algoritmos so implementados por meio de fluxos visuais utilizando-se diagramas que representam condicionais, laos, interaes, processamentos, uma chamada a um outro fluxo, dentre outros. Nesta abordagem a dificuldade de se assimilar os detalhes sintticos da linguagem abolida, pois os fluxogramas so extremamente intuitivos de fcil visualizao e entendimento. Para que isso possa acontecer, a ferramenta de programao precisa possuir uma API (Application Programming Interface) ampla e extensvel, disponibilizando diversas funcionalidades prontas, e
5

permitindo a criao de novas funcionalidades, evitando a limitao da tecnologia. A figura abaixo ilustra esta situao:

Figura 02 Elementos da Programao por Fluxos. (fonte: elaborada pelo prprio autor, 2008)

Considere o Algoritmo de ordenao BubbleSort (Algoritmo clssico de ordenao de vetores conhecido como algoritmo das bolhas ou flutuao) : A seguir so fornecidas diferentes implementaes deste algoritmo, considerando linguagens de programao com diferentes nveis de abstrao. Observa-se que mesmo para as linguagens de mais alto nvel, a compreenso do algoritmo facilitada pela representao utilizando fluxo de controle, apresentada ao final, na Figura 03

1. Escrito em Assembly.
/*void bubble_as2 (int *x, int n);*/ .globl bubble_as2 bubble_as2: pushl %ebp movl %esp, %ebp movl 12(%ebp), %eax /* tamanho -> %eax */ movl 8(%ebp), %ecx /* incio do vetor -> %ecx */ movl $4, %ebx dec %eax mul %ebx addl %eax, %ecx /* %ecx aponta p/ o ltimo do elemento do vetor */
6

pushl %ecx _bubble_as2_l1: movl $0, %edx movl 8(%ebp), %ebx movl %ebx, %eax addl $4, %eax _bubble_as2_l2: cmp %eax, %ecx jl _bubble_as2_l1_end movl (%ebx), %ecx cmp (%eax), %ecx jl _bubble_as2_l2_end movl (%eax), %edx movl %edx, (%ebx) movl %ecx, (%eax) movl $1, %edx _bubble_as2_l2_end: movl %eax, %ebx addl $4, %eax movl (%esp), %ecx jmp _bubble_as2_l2 _bubble_as2_l1_end: cmp $0, %edx je _bubble_as2_fim popl %ecx subl $4, %ecx pushl %ecx jmp _bubble_as2_l1 _bubble_as2_fim: leave ret

2. Escrito em C
void bubble(int v[], int qtd) { int i; int trocou; int aux; do { qtd--; trocou = 0; for(i = 0; i < qtd; i++) if(v[i] > v[i + 1]) { aux = v[i]; v[i] = v[i + 1]; v[i + 1] = aux; trocou = 1;
7

} }while(trocou); }

3. Escrito em Phyton
sub swap { ($_[0], $_[1]) = ($_[1], $_[0]); } sub bubble_sort { for ($i=$|; $i < $#_; ++$i) { for ($j=$|; $j < $#_; ++$j) { ($_[$j] > $ _[$j+1]) && swap($_[$j], $_[$j+1]); } } }

4. Escrito em Pearl
for(i = 1:n) for(j = 1:n-1) if(x(j) > x(j + 1)) aux = x(j); x(j) = x(j + 1); x(j + 1) = aux; end end end

5.

Escrito em MatLab

def bubblesort(l): for passesLeft in range(len(l)-1, 0, -1): for index in range(passesLeft): if l[index] < l[index + 1]: l[index], l[index + 1] = l[index + 1], l[index] return l

6. Escrito em Fluxos

Figura 03. Representa uma Implementao Do Algoritmo de Ordenao BubbleSort. (Fonte: elaborada pelo autor, 2008)

Sem dvidas nota-se que a programao por fluxos muito mais intuitiva, legvel, fcil de manter, e o principal aspecto, muito menos custoso implementar algoritmos utilizando fluxos que utilizar os moldes tradicionais de linguagens escritas. Outro aspecto a facilidade de se capacitar profissionais, de diversos perfis, nessa sintaxe, e a conseqncia da adoo desse modelo de programao ter-se uma equipe com produtividade alta, homognea e de um baixo custo. Esse paradigma a materializao de todas as necessidades e tendncias de transformaes que as linguagens de programao e os processos de desenvolvimento de software esto sofrendo. Alguns pensadores da rea visualizaram estas tendncias, um pesquisador da Microsoft, Todd Proebsting, j sinalizou pra essa realidade, ele afirma que: "O problema mais importante na criao de uma linguagem de programao moderna como melhorar a produtividade do programador j que o hardware hoje suficientemente poderoso e no requer que compiladores otimizem massivamente o cdigo e os dados de um programa para obter uma boa performance".
9

Em um outro artigo [http://logbr.reflectivesurface.com/2003/05/14/mais-sobrea-evolucao-de-linguagens-de-programacao/] o autor expe com muita clareza as tendncias das linguagens do futuro.

Linguagens de programao do futuro provavelmente valorizaro mais a produtividade do que o poder bruto. Linguagens de programao do futuro provavelmente sero mais concisas, construindo sobre bases mais simples. Linguagens de programao do futuro provavelmente agregaro diferentes paradigmas. Linguagens de programao do futuro provavelmente faro uso de bons ambientes de desenvolvimento para melhorar a produtividade. Linguagens de programao do futuro provavelmente encontraro modos de equilibrar conciso e legibilidade. Linguagens de programao do futuro provavelmente integraro mecanismos de extenso nos nveis semnticos e sintticos mais bsicos das mesmas, permitindo que programadores as evoluam de maneira simples quando necessrio.

E o que se observa que todas as idias supracitadas esto em consonncia com as idias propostas pela arquitetura de desenvolvimento orientado a negcios. Historicamente tentou-se desenvolver softwares seguindo modelos idealizados em outras engenharias, muitas prticas como a prototipagem,e a utilizao de componentes herdadas de outras engenharias foram adotadas pelos desenvolvedores, mais observa-se que os processos de desenvolvimento de software ainda so muito custosos, sendo o ser humano o limite do processo, ou seja, o desenvolvedor precisa assimilar um conjunto extenso de termos da linguagem de programao e dos padres de desenvolvimento, para obter um bom desempenho e conseqentemente uma produtividade satisfatria. O objetivo da arquitetura de desenvolvimento Orientada a Negcios inverter a lgica de desenvolvimento adotada atualmente, o limite seria a mquina, e as ferramentas seriam suficientemente capazes de promover as abstraes necessrias para se promover uma alta produtividade a um baixo custo. Isso quebraria o paradigma de desenvolvimento de software adotado pela maioria dos engenheiros de software.

10

O Desenvolvimento de Software Orientado a Negcios pode ser visualizado como sendo a adoo de um conjunto de prticas aliado a quebra de paradigma supracitada. Observa-se um grande conjunto de etapas no processo de desenvolvimento. Especificao de requisitos, anlise de requisitos, modelagem, implementao, testes e homologao so muitos custosas, a arquitetura de desenvolvimento proposta visa em primeira instncia agilizar estas etapas tendo como conseqncia a reduo da quantidade de etapas e a reduo do tempo de desenvolvimento. A idia que se possam realizar todas as etapas de desenvolvimento em uma nica ferramenta suficientemente poderosa e capaz de prover todos os servios necessrios para o desenvolvimento de software. A justificativa para isso muito simples, com a utilizao de uma nica ferramenta em todo o projeto de desenvolvimento reduz-se o tempo de manuteno, pois eleva-se o nvel de rastreabilidade podendo-se mensurar de forma precisa os impactos causados em alteraes em qualquer fase do projeto. Com isso aumenta-se o nvel de integrao entre as etapas de desenvolvimento, tarefas que eram executadas de forma independente e em ferramentas distintas, podem ser executadas em uma nica ferramenta e em uma nica fase, por exemplo,a prototipagem, a modelagem e a implementao podem ser agregadas em uma nica etapa, ou seja, trs tarefas sendo executadas de uma s vez, isso implica em reduo de tempo de desenvolvimento, reduo de custo de produo, e facilidade de manuteno pois uma alterao ter impacto em trs etapas de desenvolvimento. Atualmente, se gasta muito tempo e recursos financeiros no desenvolvimento de sistemas seguindo os padres adotados. A proposta mostrar que possvel desenvolver grandes sistemas em pouco tempo e com uma equipe reduzida, desde que se quebrem os paradigmas e padres de desenvolvimento utilizados. Normalmente o processo de desenvolvimento de sistemas segue o modelo proposto pelo fluxograma a seguir:

Figura 04. Etapas convencionais do Desenvolvimento de Software.

11

(fonte elaborada pelo prprio autor, 2008)

Na arquitetura de desenvolvimento proposta, o fluxo seria:

Figura 05. Etapas otimizadas do Desenvolvimento de Software. (fonte elaborada pelo prprio autor, 2008)

Ou seja, o que antes era feito em oito etapas, nesta proposta poder ser feito em quatro etapas, alm de reduzir em metade as etapas do desenvolvimento, esse modelo proposto facilita a manutenibilidade e rastreabilidade de requisitos.

3 - Experimento
Fez um experimento implementando uma tela simples de cadastro dos dados pessoais de clientes para se mensurar o ganho de produtividade em se utilizar a abordagem apresentada e conseqentemente comprovar a tese proposta. O seguinte cenrio foi reproduzido: 1. Especificao da Tela: A tela deve armazenar dados referentes a clientes pessoa fsica de uma organizao, os dados as serem armazenados so: Nome completo, Data de nascimento, RG, CPF, Nacionalidade, estado civil, Profisso, renda atual, data do cadastro, e-mail, telefone fixo, telefone celular e endereo. A tela dever testar, antes de gravar o registro, se o CPF digitado vlido. A tela dever permitir a gravao de mais de um endereo por cliente.

12

A tela dever testar, antes de gravar o registro, se o e-mail digitado vlido. Dever existir um mecanismo de busca, para localizar clientes pelo nome, cpf e rg, de maneira que essa busca seja efetuada na prpria tela de cadastro. A tela dever funcionar em ambiente WEB O experimento dever ser implementado utilizando-se de uma arquitetura em 3 camadas, uma de apresentao, uma de regras de negcio e outra de armazenagem de dados. A camada de armazenagem ser previamente juntamente com a especificao do experimento. disponibilizada

Aps a concluso do experimento ser dada uma manuteno na tela de maneira que se gere uma Listagem dos clientes cadastrados. A tela dever ser previamente testada para contemplar todas as situaes especificadas, e o tempo de teste ser considerado no tempo total de implementao. Para execuo do experimento foram convidados dois profissionais experientes em cada arquitetura utilizada, e outro profissional experiente em testes foi convidado para realizar os testes na tela. Disponibilizou-se uma modelagem de dados no banco MS-SQLSERVER com um conjunto de tabelas capazes de contemplar o armazenamento dos dados conforme a especificao da tela. No poder haver validaes em banco de dados, ou seja, todas as regras de negcio devero ser implementadas em uma camada separada dos dados. Segue abaixo uma figura com a visualizao disponibilizadas para se realizar este experimento. das tabelas

2- Descrio do modelo de dados disponibilizado.

13

Fig 06. Modelo de dados do experimento. (fonte elaborada pelo prprio autor, 2008)

3- Tecnologias utilizadas. Para a execuo desse experimento foram utilizadas dois ambientes de desenvolvimento:
o

.Net Framework 3.0 utilizando o ambiente de desenvolvimento de aplicaes Microsoft Visual Studio 2008 com a tecnologia Ajax.Net. Maker 2.5, ambiente de desenvolvimento gil de aplicaes WEB desenvolvido pela empresa brasileira Softwell Solutions. (http://www.softwell.com.br/web/).

O experimento foi feito com softwares licenciados, para o Microsoft Visual Studio 2008 foi utilizada uma licena acadmica disponibilizada pela UNIFACS, e para o Maker 2.5 uma licena cedida pela Softwell Solutions para realizao desse experimento.

Screen Shots das telas implementadas Asp.Net Maker

14

Figura 07- Telas do experimento (fonte elaborada pelo prprio autor, 2008)

4- Critrios de Comparao

15

Como mtricas para mensurar este experimento utilizaram-se: Esforo, Prazo e Custo. Como Apoio para se calcular estas mtricas utilizou-se pontos por funo em cada cenrio reproduzido.

5- Anlise de Pontos por Funo

Considere as tabelas abaixo:

o

Tipos de Funo do sistema e seus respectivos pesos de acordo com a complexidade de cada funo. Tipo de Funo Entradas Externas (EE) Sadas Externas (SE) Consultas Externas (CE) Arquivos (ALI) Lgicos Baixa Mdi a 3 4 3 4 5 4 10 7 Alta 6 7 6 15 10

Internos 7

Arquivos de Interface Externa 5 (AIE)

Tabela 01- Tipos de Funes X Pesos por complexidade (extrada de http://www.isbsg.org/ )

o Tabela de Caractersticas Gerais: Questes escala(1 a 5) 1 - Comunicao de Dados 2 - Processamento Distribudo de Dados 3 - Desempenho 4 - Configurao Intensamente Utilizada 5 - Taxa de Transao 6 - Entrada de Dados On-Line 7 - Eficincia do Usurio Final 8 - Atualizao On-Line 9 - Processamento Complexo 10 - Reutilizao 11 - Facilidade de Instalao 12 - Facilidade de Operao
16

1 2 1 2 1 2 3 2 3 4 3 2

13 - Mltiplas Localidades 14 - Facilidade de Alterao N Total

Tabela 02. Caractersticas Gerais do sistema (extrada de http://www.isbsg.org/ )

3 2 31

Legenda 0 1 2 3 4 5 Nenhuma influncia Influncia mnima Influncia moderada Influncia mdia Influncia significante Influncia forte
Tabela 03. Legenda Caractersticas Gerais do sistema (extrada de http://www.isbsg.org/ )

Anlise do experimento: o EE = 2 Dados do Cliente Dados do endereo Listagem dos Clientes Consulta a Cliente Arquivo de Pessoa Arquivo de Endereo Arquivo de Nacionalidade Arquivo de Profisso

o SE = 1 o CE = 1 o ALI = 4

o AIE = 0 Clculos o Considerando:

17

ADD a contagem no ajustada das funes do projeto VAF o fator de ajuste da contagem. AFP o valor ajustado da contagem.

o Tem-se Nt(total) = N1+N2++N14 VAF = 0,65 + (0,01 X Nt(total)) AFP = ADD * VAF

o Clculo da contagem no ajustada ADD = PxEE + PxSE + PxCE + PxALI + PxAIE ADD = 3x3 + 4x1 + 3x1 + 7x4 + 5x0 ADD = 9 + 4 + 3 + 28 + 0 ADD = 44

o Clculo do fator de Ajuste da contagem:

VAF= 0,65 + (0,01 X Nt(total)) VAF = 0,65 + (0,01 X 31) VAF = 0,96

o Clculo do Valor Ajustado:

AFP= ADD * VAFasp.net AFP= 44 * 0,96 AFP = 42,24

Nt(total) ADD VAF AFP

31 44 0,96 42,24
Tabela 04. Resultado

Esforo, Prazo e Custo Considerando que este experimento foi implementado no maker e em Asp.net, com um profissional, como descrito na etapa de especificao do experimento, e que se trata de uma aplicao trivial, segue abaixo os tempos listados:

18

Maker Tempo 1h

Asp.net 160h

Tabela 05. Tempo de implementao

Considere R como sendo o rendimento do profissional em pontos por funo por Hora Maker: 42,24PF ----------1h Rmaker = 42,24pf/h ASP.NET 42,24 pf ----------160 R ----------- 1 h Rasp.net = 0,014pf/h ou 3,78h/pf Ou seja o rendimento do Maker nesse experimento foi cerca de 159,66 vezes maior que o rendimento do Asp.Net

4- Consideraes finais Este artigo deixa evidente a necessidade de inovao tecnolgica, pois os moldes tradicionais de desenvolvimento de software alm de muito complexos so dispendiosos, pois gasta-se um tempo considervel no desenvolvimento de solues computacionais e os recursos humanos empregados precisam ser extremamente especialistas para se obter uma produtividade satisfatria. Os softwares so desenvolvidos hoje da mesma forma que eram implementados a 30 anos atrs. O desenvolvimento de software Orientado a Negcios mostra que possvel desenvolver softwares robustos a um baixo custo de produo / implantao, sendo necessrio para isso a utilizao de ferramentas poderosas e capazes de atuar em todas as etapas do processo de desenvolvimento e capazes de prover a abstrao necessria para se elevar o nvel da programao. Ou seja, inovando a forma atual de desenvolvimento. Como prova destas afirmaes fez-se o experimento, concluindo a eficincia e eficcia da abordagem orientada a negcios. Produzir software 159 vezes mais rpido que abordagem tradicional um bom indicio que precisamos mudar a tica da forma de se desenvolver sistemas. Alem do Maker desenvolvido pela Softwell Solutions outras empresas apostam nesse modelo de desenvolvimento como sendo o padro do futuro. A Sun tambm aposta nessa abordagem, o ncleo de pesquisa da intuio, a Sun Labs desenvolve uma ferramenta denominada ACE
19

(http://research.sun.com/projects/ace/), que ainda est em fase de testes e pesquisa que promete ser capaz de implementar estas idias abordadas. A Microsoft tambm pesquisa essa abordagem de desenvolvimento, recentemente lanou o Microsoft Visual Studio 2008, uma ferramenta capaz de programar por Wokflows (Microsoft Workflow Foundation), mas a codificao ainda no foi extinta nessa ferramenta escrevem-se algoritmos atravs de fluxogramas, mas necessrio editar cada componente do fluxograma escrevendo cdigo. Conclui-se este artigo com a mensagem de que preciso inovar a tecnologia pois todas as engenharias evoluram bastante nas ultimas dcadas e preciso promover essa evoluo na engenharia de software.

5- Referncias
Hewett, Baecker et. al. (1992 1996). ACM SIGCHI Curricula for HumanComputer Interaction, http://sigchi.org/cdg/cdg2.html, Dezembro. Pressman, Roger S. Engenharia de Software Terceira Edio. Pearson 1995 Shneiderman, Ben (1998), Designing the User Interface Strategies for Effective Human-Computer Interaction, Addison-Wesley , Third Edition. Sommerville, Ian Software Engineering Addison-Wesley, 5th Edition (1995) http://www.pr.gov.br/batebyte/edicoes/2000/bb99/modelos.htm http://www.softwell.com.br/web http://pt.wikipedia.org/wiki/Bubblesort http://www.microsoft.com/brasil/corporativo/connect/news_content/workflow.ms px http://research.sun.com/projects/ace/ http://www.santahelena.ueg.br/apostilas/gomide/2008/primeiro/pontoFun cao.pdf www.aspectos.org http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER06/dias.pdf: http://www.inf.ufes.br/~falbo/download/pub/2004-JIISIC-1.pdf http://wisewig.sourceforge.net/ http://www.dcc.unicamp.br/ic-tr-ftp/2005/05-06.ps.gz http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html http://oreilly.com/pub/a/oreilly/news/languageposter_0504.html Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. 1.ed. Estados Unidos da Amrica: Addison-Wesley, 1995.

20