Novos paradigmas de software

Novos paradigmas de software

Tenho visto muitos artigos na rede sobre novos paradigmas de desenvolvimento, como metodologias ágeis, TI Bimodal e outros - todos de fato carregam um elemento comum - o foco nos negócios, onde entender o que ocorre no lado "humano" de TI precisam ser levados mais em consideração. Isso é ótimo, pois tem sido uma reivindicação antiga dos usuários. A pergunta que fica é: Como ser compatível com os negócios, gerar documentação de qualidade e acima de tudo, imprimir um grau máximo de flexibilidade ao software para encarar os constantes desafios do meio de negócios?

Eu não apostaria em nenhuma ferramenta específica, mas sim em um conjunto de processos ou um método de design, associado à automação, onde cada mudança na plataforma de negócios gere as especificações de código a ser desenvolvido, e que essas especificações possam ser trabalhadas por geradores de código ou até mesmo por ferramentas tradicionais como C# , JAVA e linguagens para WEB em geral.

Considerando que as novas plataformas de desenvolvimento já contemplam ambientes multiplataforma e suportam múltiplas linguagens, basta um pequeno ajuste das equipes de desenvolvimento para a criação destes ambientes integrados, com bibliotecas e templates e voilá - temos uma plataforma automatizada para os novos ambientes de negócio, com alta flexibilidade, padronização e agilidade, de baixo custo e alto retorno - nada de ferramentas caras ou espalhafatosas, mas puro e simples código padronizado.

Ainda falta esse tipo de conscientização nas empresas e profissionais de forma a simplificar o desenvolvimento de software, mostrando o conceito de retorno do investimento de forma mais clara e objetiva.

Fabio Reis

I.T SPECIALIST L1 CERT. at IBM

9 a

Marco, quando eu falo em "muletas" é exatamente o que você acaba de dizer sobre os tais métodos "'ágeis", quando eu falo em rotas e historia, é exatamente o que você refere-se a "processo natural". Se voltarmos na história, vamos ver algo bastante curioso e inusitado hoje, vou resumir: - Alguns anos atrás quando a empresa contratava um profissional de T.I na área de MF (principalmente, vou dizer Mainframe, para ficar mais condizente com a situação), junto com o profissional vinha também "a tira colo" , se bem que embaixo do braço uma unidade de fita tipo rolo sem fim ou o antigo IBM DASD, nessas unidades vinham uma "biblioteca de reuso", continham um conjunto de ferramentas que o profissional ao longo do tempo acumulou. Pois bem, vamos ser honestos qual profissional de T.I que seja o miínimo capaz e competente não possui tal conjunto de ferramentas? Concordo com o você diz, apenas vou além, quando falo de competencia, é que um profissional competente ,já passou por uma serie de provações, ja encontrou as técnicas, os métodos que funcionam e que funcionam em prática. Nesse ponto , bem provável que em maioria esses métodos e práticas ligam-se , exatamente ao ponto que você enfatiza , reuso, adequação, disponibilidade de conhecimento, economia e principalmente uso racional e sensato de recursos, por exemplo alguns métodos exigem que documentação cansativa e extensa seja realizada para todo e qualquer projeto, use cases, test cases, business cases e oraio queo parta cases, ora!! quando todos esses cases terminarem provavelmente o cliente já perdeu interesse no processo ou em casos extremos , estressou-se tanto que desistiu ou até mesmo morreu, e no entanto o que foi produzido? Então as muletas são exatamente isso, dar "desculpas" para culpar o outro, por algo que era da sua responsabilidade, eu tenho um aplicação para desenvolver, se 50% do processo já existe pra que cases e mais cases? Por que não aproveitar os atalhos oferecidos? Por que não é Ágil? Ou será que é porque não é RaCional?

MARCO RIBEIRO

Data Architecture, Database Modeling and Design, Metadata Management and Data Governance

9 a

Fabio, muito obrigado pelos comentários! Muito conciso como sempre! Embora eu concorde com suas idéias em sua maioria, ainda falta muita agilidade nos processos de construção de software - o conceito de "fábrica" (no bom sentido) é a meu ver aquele em que as plataformas de negócio e sistemas são estanques e integradas ao mesmo tempo. Ao longo do tempo os componentes vão sendo construídos e não existe muito sentido em reconstruir componentes, ou reaprender processos de negócio - a automação é um processo natural, diferente do que apregoam os apóstolos dos processos ágeis, construa modelos, reutilize o que for possível e substitua o necessário - isso em nenhum momento é dar muletas ao pessoal de software - eles ainda vão ter de entender o que é preciso ser feito, através dos manuais e documentação, antes mesmo de codificar a primeira linha de código. Não falei de automação total, mas de um conjunto de métodos que privilegie a objetividade na construção de software - pois o resto nós já temos. Entenda antes de construir, automatize o que é possível e construa apenas o necessário - isso pode ser considerado economia de escala em software. Tem funcionado muito bem em projetos nos quais trabalhei. Eu quis fugir de muitos projetos em que o velho método (buscar documentação,entender, projetar e codificar) pois já na primeira etapa não havia "passado" - era simplesmente começar de novo.

Fabio Reis

I.T SPECIALIST L1 CERT. at IBM

9 a

Eu devo discordar um pouco com o colega e voltar alguns anos no tempo para explicar minha discordancia. Alguns anos atr'as (20 ou mais) , tinhamos no mercado basicamente duas figuras bem fundamentadas na area de TI., o Analista e programador. O programador lidava basicamente com codigo, linguagem e especificacoes fornecidas pelo Analista, porem , se voce queria ser Analista a regra mais basica era: APRENDA O " NEGOCIO" da empresa, e para um bom analista ser bem sucedido era preciso que o mesmo conhecesse a Contablidade, Estoque,Folha de Pagamento,Vendas,Contas a pagar , Chao de fabrica, nao apenas o chao , mas as vielas, ruas, avenidas e becos por mais estreitos , confusos e apertados que fossem, os caminhos , rotas que uma empresa deveria percorrer tinham que ser assimilados e o Analista tinha ter em sua mapa tais mapas. No momento de desenvolver uma aplicacao, nenhum analista pegava um GPS , mesmo porque nao existia, nao se tinha atalhos, era o cliente no mais puro grau com quem ele deveria lidar, reunir-se, a empresa precisava de automatizar a contabilidade? Era o Depto.Contabil a rota de sucesso que o Analista deveria percorrer, nao estou dizendo que o mesmo deveria ir ao Contador, Gerente Contabil , nao , o departamento como um todo deveria ser envolvido e essa era a unica chance da aplicacao a ser desenvolvida ter sucesso. Pois bem , hoje eu ouco falar muito em "business skill" , metodologias ageis,ambientes integrados, big data, geradores de codigos, nuvem, e ate mesmo o colega me vem com o lado "humano" de TI, porem nisso eu concordo , lado humano , toda essa parafernalha existente hoje sao otimas e muito bem vindas, porem as pessoas estao esquecendo da historia , a historia de TI a historia da tecnologia , e quando as pessoas perdem a historia , perdem tambem a referencia, esquecem-se de que o que faz diferenca na historia , na empresa e exatamente o " lado humano" , e por lado humano entenda " pessoas competentes" , quando voce tem gente competente trabalhando nenhuma metodologia as substitui, elas se adaptam , se enroscam, sao flexiveis ao tempo e a propria historia, trazem na mente nao apenas os mapas e rotas adequadas , porem o conhecimento historico de todas as viagens percorridas. Devemos ser responsaveis conosco como profissionais e como pessoas, naoa devemos entregar " muletas" aos jovens que iniciam a viagem, devemos sim, forjar-los na historia de espiritos profissionais " competentes" e capazes, so assim o futuro sera mais Objetivo, Claro, Conciso.

Entre para ver ou adicionar um comentário

Outros artigos de MARCO RIBEIRO

Outras pessoas também visualizaram

Conferir tópicos