Engenharia de Software no mundo atual

A Engenharia de Software (ES) evoluiu muito nos últimos anos para adequar-se a uma nova dinâmica em que a sociedade e as organizações estão cada vez mais conectadas.

Com as crescentes pressões impostas por inovação, produtividade com prazos cada vez mais curtos, flexibilidade, melhorias no desempenho, funcionalidade e qualidade dos produtos desenvolvidos, a ES como se conheceu à 15 anos atrás teve que se reciclar, várias vezes por sinal, sem que talvez pudéssemos ter percebido.

Interessante observar que nesta rápida evolução, várias metodologias, processos e ferramentas surgiram para dominar a complexa atividade que é construir software com qualidade. Algumas são usadas até hoje mas muitas foram esquecidas ou substituídas por algo melhor no mercado.

Iniciei minha carreira na Informática pouco tempo depois da UML (Unified Modeling Language) ser aprovada como padrão pelo OMG (Object Management Group). Foi uma fase de grande aprendizado, diga-se de passagem. Nessa época, cursava Técnico em Informática, o paradigma dominante era Cliente/Servidor e as linguagens de programação top da minha cidade eram Delphi e Visual Basic.

Trabalhava em uma empresa RAT Bematech que desenvolvia sistemas de Gestão Empresarial (Ex.: controle de estoque, financeiro, boleto bancário, pontos de venda (PDV) e TEF discado) para a região de Santa Maria e arredores no RS. Nesta época, a Internet era discada e os grandes clientes pagavam muito caro para colocar links de conexão de 800k para integrar as suas lojas.

Nesse contexto, o que mais me marcou foi com certeza a metodologia e o processo de desenvolvimento de software utilizado na empresa em que trabalhava: a regra era seguir UML a risca e produzir muita documentação. Muitas vezes os desenvolvedores discutiam muito sobre a real necessidade de tantos artefatos pois o framework utilizado já fazia muita coisa. Além do mais, as ferramentas bem como o hardware da época eram muito lentos e os analistas perdiam muito tempo aguardando a ferramenta de modelagem UML compilar o portal da documentação.

Desta época até o presente, quase tudo mudou e na minha opinião para melhor. Pode-se

dizer que houve um amadurecimento da TIC. Hoje é comum as empresas pensarem de forma Ágil. Ser Ágil significa dizer que os engenheiros vão produzir somente os artefatos que podem agregar valor ao negócio. É como se estivéssemos livres: Se antes éramos obrigados a produzir um determinado diagrama sabendo que o desenvolvedor sequer iria utilizar apenas para constar no site da documentação, agora podemos ter a liberdade de fazer a documentação que realmente importa, ou seja, fazer as próprias escolhas.

Claro que toda essa mudança na forma de pensar em ES precisou ser absorvida pelos profissionais. Com certeza, o pessoal que viveu esta fase entende muito bem o que as metodologias ágeis de hoje significam e quem é recente na área pode ter uma certa dificuldade para entender porque isso é tão marcante.

Para concluir, hoje as empresas buscam Analistas e Desenvolvedores poliglotas. Por isso, torna-se importante conhecer vários processos, métodos e ferramentas. A escolha de cada uma delas dependerá do projeto e dos requisitos de qualidade que se buscam. Portanto, nada é fixo, pelo contrário, tudo é dinâmico e pode mudar a qualquer hora.

Att.

Everton de Vargas Agilar

Blogs, Data Science, profissional 2.0 e inspiração

Olá a todos! Esse será o primeiro post (de muitos?) ligado à disciplina de Tópicos avançados de Engenharia de Software do MPCA/UnB. Também será minha primeira vez escrevendo em blogs. Por não gostar de me expor e não curtir muito escrever, não possuo o hábito de botar no papel minhas idéias ou compartilhar pensamentos em redes sociais. Sempre passei bem longe de possuir blog ou  algo semelhante.  Mas, após uma discussão em sala de aula onde fomos instigados a refletir sobre os profissionais e a dinâmica do mercado de trabalho de engenharia de software em um mundo repleto mudanças, farei minha estréia nesse universo de blogs expondo aquilo que  penso sobre o assunto.

A princípio, por não ter experiência e não ser formado na área, imaginei que nada tinha a ver com o assunto e me esforçaria muito para conseguir escrever poucas linhas, porém logo percebi o engano ao lembrar dos acontecimentos que me trouxeram até aqui.

Tentarei ser breve na história. Em 2006 entrei no curso de Estatística na UnB e junto comigo  entrou um colega que, após alguns semestres, acabou largando a estatística,  cursou Ciência da Computação, durante um intercâmbio conheceu uma canadense, casou-se com ela e se mudou para lá, onde atualmente trabalha como engenheiro de software. Acabei perdendo contato com ele, mas em maio/2014, pesquisando sobre Big Data, acabei descobrindo quase sem querer o blog sobre Data Science que ele havia criado (https://alquimiadedados.wordpress.com/). Li todas as postagens e uma frase no post inaugural dele me chamou a atenção:

"Enfim, espero criar aqui uma fonte rica em informações sobre Data Science, em português, para, quem sabe, ajudar a fomentar essa profissão no Brasil.” 

 E foi justamente o que aconteceu. Pode ficar feliz, grande Mesquitão, porque você me inspirou a pesquisar ainda mais sobre o assunto e despertou o desejo de investir tempo e esforço nessa área. Foi um blog, portanto, aquilo que me fez procurar um curso dessa área no Brasil, encontrar o MPCA e chegar à essa disciplina.

E como isso se relaciona ao tema da discussão? Já posso tirar uma grande lição sobre quão importante é compartilhar conhecimento, mas, além disso, percebi também que a engenharia de software em sua versão 2.0 também influenciou bastante a minha presença aqui. É fácil perceber que vivemos em um mundo onde dados são gerados em uma velocidade impressionante e das mais diversas formas. Para capturar, armazenar e tratar esses dados foi necessário a criação de novas técnicas e plataformas de software como MapReduce, GFS e Hadoop. E daí, pensava eu, não é isso que quero pesquisar. Pretendo me envolver com a análise e extração de conhecimento desses dados, mas é necessário reconhecer que sem as evoluções que ocorreram em engenharia de software o Data Science não existiria da forma como é hoje. Caso queira ser um profissional na área é desejável, portanto, ter um conhecimento mínimo sobre as plataformas de software existentes e como utilizá-las de forma adequada.

Aprofundando um pouco mais na questão do profissional 2.0 e como isso se envolve com minha pesquisa e com meu trabalho, vi que para analisar e visualizar esses dados, além dos conhecimentos já mencionados, é necessário ter domínio de algoritmos de machine learning, técnicas estatísticas, bancos de dados SQL e NoSQL, dentre outros. E onde eu estava no meio disso tudo? Preso na parte de técnicas estatísticas, completamente cego para todo o resto. No meu trabalho percebo diariamente a dificuldade cada vez maior para lidar com grandes quantidades de dados  e de extrair conhecimento útil deles. A estatística sozinha já não está mais dando conta de tanta informação.  Para dar conta de tudo isso, preciso me tornar um profissional 2.0, conhecer outras áreas, buscar novas formas de resolver problemas, me desprender de vícios antigos, acabar com o amor apenas ao que já conheço. Acontece que esse é um caminho difícil. Quando informei à alguns colegas e parentes que faria um mestrado em Computação, todos me perguntaram o porquê disso. Por que enfiar a cara em uma área completamente desconhecida? Por que se dar ao trabalho de aprender tantas coisas novas quando é muito mais fácil me especializar naquilo que já sou bom? Ainda hoje escuto vários questionamentos nesse sentido, mas acredito ter tomado a decisão correta. Por que minha base teórica em estatística não pode se unir a conhecimentos de programação, data mining, bases de dados e outros para me tornar um profissional melhor do que sou hoje?

Enfim, quais lições tiro dessa breve reflexão? Que não podemos nos limitar e fechar as portas para novos desafios. Em um mundo 2.0, o profissional que quiser ser bem sucedido precisa se renovar sempre e diversificar seus conhecimentos para resolver os problemas que aparecerem da melhor forma possível. E sim, se expor, mesmo de forma virtual, continua difícil para mim, mas começo a pensar que os benefícios valem o esforço. Escrever um blog é uma excelente forma de transmitir conhecimento e inspirar outras pessoas. Afinal, foi isso que me trouxe aqui... e quem sabe não inspiro alguém também!?

Felipe Alves Fonseca é aluno do Mestrado Profissional em Computação Aplicada da Universidade de Brasília e assessor na área de risco de crédito do Banco do Brasil.

Fábrica de software: comparando maçãs com laranjas

O termo "fábrica de software" apresenta uma abordagem para o desafio de muitas organizações para o desenvolvimento de software. Sugere-se uma estrutura de profissionais, processos e metodologias num formato semelhante à estrutura de uma fábrica tradicional, monitorada por uma série de indicadores de qualidade e produtividade em cada etapa, buscando massificar a produção de software, gerando mais software no menor prazo possível com um nível de qualidade aceitável, e com o menor custo possível.

Greenfield (2004) apresenta a idéia básica dessa abordagem: "Outras indústrias aumentaram sua capacidade passando do artesanato, onde produtos inteiros são criados desde o início por indivíduos ou pequenas equipes, para a fabricação, onde uma larga gama de produtos é montada rapidamente com componentes reutilizáveis, criados por diversos fornecedores e onde as máquinas automatizam as repetições ou as tarefas subalternas. Elas padronizaram processos, projetos e embalagem, usando de linhas de produtos que facilitam a reutilização sistemática e cadeias logísticas que distribuem o custo e o risco. Algumas são, hoje, capazes de uma personalização em massa, onde as variantes do produto são criadas de forma rápida e não dispendiosa, de acordo com o pedido, para atender às necessidades específicas de clientes individuais."

Ainda conforme Greenfield (2004), na indústria em geral, essa reutilização sistemática pode gerar dois tipos de economia: de escala e de escopo. A economia de escala ocorre quando várias cópias idênticas de um único projeto são produzidos em série. Por exemplo, em uma gráfica, para gerar a matriz de impressão de um livro, há um custo, mas para imprimir mil exemplares do mesmo livro, o custo por unidade é menor. Geralmente a matriz exige um custo de desenvolvimento. A produção das cópias segue um processo diferenciado, pautado pela automação e mecanização, que tem um custo mais baixo.

A economia de escopo é caracterizada quando há reutilização de práticas, processos, ferramentas e materiais para o desenvolvimento de mais de um projeto. Tomemos como exemplo a fabricação de um carro: ele é composto por diversos componentes, como chassi, interior, farol, etc, e às vezes diversos modelos de automóveis aproveitam projetos já existentes desses componentes, variando um item ou outro. Por exemplo: não é incomum verificar que entre alguns modelos de automóveis da mesma marca, vários componentes são bem parecidos (farol, direção, etc.).

E aplicando esses conceitos na produção de software, há situações em que se terá a economia de escala, como no caso em que um mesmo produto (por exemplo, um Sistema Operacional ou uma suíte de escritório) é comercializado em grande escala (definição conhecida como "software de prateleira"), mas em boa parte das situações de desenvolvimento se desenvolve um produto para atender uma necessidade específica da organização, gerando apenas um "original" do mesmo. Nesses casos, não há economia de escala. Mas é possível obter a economia de escopo, conforme Greenfield (2004): "Podemos então ver onde maçãs estão sendo comparadas com laranjas. A produção nas indústrias físicas foi ingenuamente comparada ao desenvolvimento de software. Não faz sentido procurar economias de escala no desenvolvimento de nenhuma espécie, seja de software, seja de bens físicos. Nós podemos, por outro lado, esperar que a industrialização do desenvolvimento de software explore economias de escopo."

Nesta visão, e sob o contexto em que grande parte das fábricas de software desenvolvem um produto por demanda (ou seja, não há "produção em série" nem economia de escala), é uma visão errônea visualizar uma fábrica de software como uma linha de produção de automóveis, por exemplo, mas visualizar a fábrica de software como a área de desenvolvimento do projeto de um automóvel me parece mais conveniente. É um trabalho que requer muito mais atividade mental do que "braçal". E infelizmente, existem "donos" de fábricas de software com a primeira visão apresentada, querendo que desenvolvedores trabalhem como operários, produzindo "x" linhas de código por hora a um custo mais baixo possível. E essa abordagem errônea faz com essas fábricas tenham uma alta rotatividade de pessoal, o que torna difícil de implementar o que seria justamente o maior benefício que uma idéia de fábrica poderia trazer para o desenvolvimento de software, que seria a reutilização de componentes de outros projetos, processos maduros e bem estabelecidos, que resultariam na economia de escopo.

E pela natureza da atividade, a retenção dos talentos se torna fundamental. Voltando à comparação com a área de desenvolvimento do projeto de um automóvel, pode-se afirmar que a qualidade do trabalho das pessoas envolvidas estará representado no resultado final. No desenvolvimento de software é semelhante.

Enfim, algumas visões erradas nas implementações de um ambiente de fábrica de software fizeram com que o conceito fosse desvirtuado para algo errado e ineficiente. Comparar fábrica de software com uma linha de produção "em série" também não é a melhor comparação, e pode levar a conclusões erradas sobre o seu conceito. Implementar processos eficientes, buscar a reutilização e reter talentos não é ir contra o conceito de fábrica de software, mas sim utilizá-lo da forma adequada.


Referência
----------

GREENFIELD, J. O caso das fábricas de software. Disponível em <https://msdn.microsoft.com/pt-br/library/aa480032.aspx>. Acesso em 28 de maio de 2015.

Programador poliglota

Há tempos tenho ouvido falar sobre o tema, mas não havia parado para analisar e principalmente entender o desafio. É fácil ser poliglota ? Se eu não for poliglota estou perdido, fadado a virar um "dinossauro". Vou começar relembrando quantas linguagens de programação aprendi no meus trinta e poucos anos de carreira. Comecei programando no bom e velho Basic, aquele das calculadoras CASIO e do saudoso APLLE II, acho que fiz alguma coisa no TK 45 também. Serviu apenas para aguçar minha curiosidade no mundo da programação. Precisava me profissionalizar e fazer algo no mundo acadêmico, fui apresentado nos bancos da faculdade ao COBOL, aquele do FILLER 0, ao elegante PASCAL e ao minucioso e potente C, linguagem de cabra macho. Aprender estrutura de dados em PASCAL foi "massa". Veio o Windows 98, mouse, interface gráfica, o mundo pra mim , passou a se chamar Visual Basic, dava até pra programar no Excel. Era lindo, alguns clicks e a tela estava pronta, mas o código era meio "macarrônico". Tinha que aguentar a gozação de meus colegas do Delphi : "quando você vai aprender a programar de verdade, vem pro Delphi , o mundo agora é cliente-servidor". Me convenceram, foram algumas estripulias no Delphi Até que gostava, mas tinha uma raiva danada de um tal de BDE. Chega de programação estruturada, o negócio agora é orientação a objeto e se você que aprender tem ir pro JAVA ou C++. Estou até agora no Java. Por fim, resolvi fazer mestrado, abrir a mente para computação e fui apresentado às linguagens funcionais : Haskell e Erlang. Nunca imaginei que programaria sem ponteiros, variáveis globais ou passagem por parâmetro. Poxa, já ia esquecendo do Java Script, segundo o meu professor, Alexandre Gomes, é a linguagem que  mais tem código no github.

Resumo da história, umas oito linguagens para trinta anos, se formos pela média seriam uns quatro anos por linguagem. A verdade é que não dá para parar no tempo, novos paradigmas surgem e você tem de se manter produtivo. Acho que cheguei na palavra chave : produtividade. A gama de linguagens hoje é extensa e cada qual tem seu nicho ou "sua praia" . Dêem uma olhada em http://blog.codeeval.com/  , além de algumas que citei, temos presentes Python, Ruby, C#, Php , Perl, Objetive-C. E agora, pra ser poliglota tenho que encarar a curva de aprendizado de todas elas ? Acho que não, mas tenho que entender a capacidade, a fragilidade e os princípios de cada uma. Tenho que ir nas profundezas de cada uma ? Acho que não, mas vale a pena avaliar suas sintaxes e o quão generalistas ou especialistas elas são. Ser poliglota é um pouco mais de postura do que de leitura, é um pouco mais de visão do que digitação.

Drausio Santos é aluno do Mestrado Profissional de Computação Aplicada da UNB

Tecnologia no Mundo 2.0

A chamada era da informação em que vivemos atualmente reverbera em todos os campos de nossas vidas com bastante intensidade. Seja nas relações profissionais, momentos de entretenimento, realização de compras, comunicação com quem está fisicamente distante (e mesmo com quem está fisicamente próximo) os recursos tecnológicos estão sempre presentes. Acompanhar as tendências tecnológicas é, de fato, estritamente necessário para quem quer se ver incluído nesse mundo 2.0.

Já que foi mencionado mundo 2.0 vamos discorrer um pouco sobre esse conceito. O termo 2.0 está presente como acréscimo a outros termos frequentemente entoados pela Internet: Web 2.0 é um dos mais frequentes. Podemos considerar 2.0 como sendo um designativo, de maneira até intuitiva, de uma segunda etapa das coisas. A Web 2.0, por exemplo, está inundada por wikis, blogs, redes sociais que englobam os mais diferentes perfis e permitem o compartilhamento de informações em uma velocidade muitas vezes difícil de acompanhar. Todos podem participar ativamente das atividades na Web 2.0. O grande cerne da questão, que concede à Web um aspecto multifacetado e que propicia a participação de todos, é a cooperação. Não há mais espaço para ideias que permanecem sempre no casulo, que enxergam apenas uma parte e unicamente o agora, que seguem tendências retrógradas sem adicionar um diferencial. Pelo menos não de um ponto de vista tecnológico.

Um exemplo nítido de compartilhamento na Web 2.0 são as redes sociais digitais. As redes sociais que encontramos na Web promovem uma extensão das interações sociais para o contexto digital. Uma fórmula que deu certo, e que hoje é espaço não só para comunicação, conectar quem está fisicamente distante, expor momentos marcantes da vida offline, mas também como forma de promover um negócio, por exemplo. Essa tendência de estender naturalmente os hábitos do indivíduo (ou mesmo de ser uma extensão do próprio indivíduo) está presente na construção de software e itens tecnológicos no nosso mundo 2.0. Aqueles produtos que se mantem estagnados, que não acompanham tendências e que não se adequam como extensão dos hábitos sociais, estão fadados a sucumbirem. É necessário evoluir os conceitos de um software em consonância com as preferências do público.

Os smartphones e tablets se tornaram produtos muito comuns. Em um mundo em que o número de linhas móveis ativas já ultrapassa a população mundial (Segundo dados publicados em http://www.tudocelular.com/curiosidade/noticias/n43451/ha-mais-celulares-ativos-do-que-pessoas-no-mundo.html - 07 de outubro de 2014), é plausível cravar que o uso de smartphones é uma tendência que veio para ficar, ao menos por um longo período. Exemplificando o fato de que no mundo 2.0 não há muito espaço para processos isolados e de olhar restrito (sobretudo de um ponto de vista comercial), e, por consequência, a produção tecnológica também não, o Windows 8 adotou uma interface que se aproxima muito daquela utilizada por sistemas operacionais como Android e IOS (comuns em smartphones e tablets), esperando, dentre outras coisas, familiarizar os usuários com o uso destas plataformas e possibilitar o uso do seu sistema em tablets e smartphones. Não fez outra coisa senão seguir o fluxo mais promissor comercialmente, adequar-se às tendências.  Complementarmente, a Microsoft entenderá o código desenvolvido para Android e o traduzirá para o sistema operacional Windows 10, dando suporte a apps portados do Android e iOS (segundo publicação verificada no site https://tecnoblog.net/177716/project-astoria-portar-apps-android-windows-10/ - 04 de maio de 2015). Isso deverá ser estratégico para sanar os problemas do Windows nos smartphones, já que os aplicativos para a plataforma Windows Phone ainda pecam em termos quantitativos e qualitativos. Essa postura possivelmente geraria repulsa em uma “versão” anterior ao mundo 2.0 em que vivemos quando estabelecida entre concorrentes.

É imperativo que não ocorra acomodação, quem trabalha com tecnologia não pode cair na zona de conforto, tampouco manter uma cultura empresarial rígida se colocando sempre como autossuficiente. A Nokia, por exemplo, que já foi sinônimo de durabilidade, que já esteve no topo da telefonia celular, se manteve rígida em suas políticas e não quis assimilar as tendências. A marca acabou perdendo a corrida de smartphones e sendo incorporada pela Microsoft. Outros exemplos podem ser mencionados: Kodak, Walkman e Diskman da Sony etc. Ainda que a situação atual da empresa seja próspera, é no mínimo imprudente fechar os olhos para o resto do mundo achando que se tornou absoluta e por tempo indeterminado. Atualmente, no mercado de software, quem não assume uma postura colaborativa, de assimilar aquilo que se firma como tendência em vez de querer impor goela abaixo seus moldes a qualquer custo, está fadado a declinar.

A questão aqui é que incorporar aspectos do concorrente tem sido uma boa alternativa nesse universo competitivo. Parafraseando Leonardo Da Vinci: Um bom artista copia, um grande artista rouba. Então, um bom artista também incorpora ao seu produto uma tecnologia compartilhada, uma tendência ou ideia, adota as interseções em vez dos caminhos sempre paralelos. Isso, sem dúvidas, representa um upgrade muito importante nesse universo 2.0. Trazer o compartilhamento para o âmbito da competição.

Raphael Magalhães Hoed é aluno do Mestrado Profissional em Computação Aplicada da Universidade de Brasília e professor de Informática no Instituto Federal de Educação, Ciência e Tecnologia do Norte de Minas Gerais.

Especialista Generalista e Dinâmica de Mercado de Software

Neste post falarei sobre alguns temas e discussões que ocorreram na primeira aula de Tópicos Avanças em Engenharia de Software, falarei sobre dois assuntos : Especialista Generalista e Dinâmica de mercado de software.

       Especialista Generalista – Na discussão sobre este tema na sala, falamos sobre os profissionais que se especializam em uma única tecnologia e que algumas vezes podem tendenciar em determinada situação o uso da tecnologia ou ferramenta que dominam, mesmo que não seja a melhor solução. Alguns profissionais restringem-se a uma tecnologia chegando até ter aversão por outra ou não desejam conhecer outras tecnologias, podendo até ficar fora do mercado de trabalho quando uma tecnologia e superada por outra. Atualmente trabalho com DBA multidisciplinar (Oracle, SQL Server, Posgres e Mysql) isto por opção minha, temos DBAs especifico de cada SGBD, mas mesmo assim prefiro entender os pontos fortes e fracos de cada banco de dados, isso ajuda tomar decisões como licenciamentos dos fabricantes, novas compras, implementações e implantações etc. Tenho uns três anos de experiência em TI já somado as áreas que passei : trabalhei com analise de sistemas, implantação e manutenção de sistemas, criação e geração de relatórios em SQL, participei de projetos de BI, realizei trabalhos como Analista de segurança da Informação, Investigação digital. Cito algumas experiências positivas que tive com o conhecimento multidisciplinar : Em um almoço tinha um colega chefe de seção que queria provar a inocência de outro colega que foi acusado de não ir trabalhar, uma das provas que eles queriam era o log do usuário na rede para ajudar na constatação que ele estava trabalhando, porém o registro de log estava desabilitado por questões técnicas, fiquei sabendo e me prontifiquei a ajudar com técnicas black hat (hacker chapéu preto) eu poderia tentar coletar da própria maquina, mesmo estando desabilitado e funcionou o colega foi inocentado, trava-se de uma denuncia falsa. Outra experiência foi quanto a metodologia usada para backup no SQL Server, onde um DBA Experiente e certificado tinha implementado, um dia atendendo uma demanda notei que algumas bases eram muitos maiores do que seu próprio backup em N vezes, então comecei a testar outra metodologia semelhante outro SGBD que economizou aproximadamente 70% de espaço em disco para cada base de dados, isso em um ambiente grande como um Data Center é bem considerável. 

      Dinâmica do Mercado de Software – outro tema bastante discutido foi este envolvendo as técnicas atuais de Engenharia de Software, e os possíveis rumos da Engenharia de Software 2.0, as novas abordagens, metodologias, o “pensar fora da caixa" . Quando pensando em um tema, uma linha de pesquisa que eu gostasse que fossa algo motivador, comecei a analisar os softwares e as formas utilizadas de teste e fui analisando o aumento de ataques cibernéticos, e percebi que algumas vezes softwares e aplicações não contemplam um nível de segurança aceitável que suporte tais ataques, pois a metodologias e testes aplicados não foram projetadas para analisar e testar esses ataques. Pesquisei em base nacionais e internacionais sobre o tema e verifiquei que tinha poucos projetos neste sentido, então cheguei um tema com a posposta de contribuir com a segurança dos software do DF, meu tema em desenvolvimento e pesquisa no PPCA –UNB é: Segurança da Informação utilizando Técnicas de Ataques Cibernéticos no Ciclo de Desenvolvimento e manutenção de Software no Data Center GDF. Uma experiencia relacionada a isso foi o Coordenador de Infra e Produção me pediu para eu analisar a segurança de uma nova aplicação de um orgão publico que teria sido bem cara, antes que esta aplicação fosse disponibilizada para uso da população, após a implantação testei a aplicação e para minha surpresa em menos de um minuto consegui acesso restrito ao dados, em outras palavras consegui invadir. Por fim a Aplicação foi rejeitada em atendimento a lei 25750/2005 que dispõe sobre a prevenção das entidades publicas do DF, para que a falha fosse corrigida. 

Fábrica de Software?

Olá pessoal, inicio esta discussão, fruto de um debate iniciado no âmbito da disciplina de Engenharia de Software, acerca da contratação de serviços de desenvolvimento e manutenção de sistemas, na modalidade denominada Fábrica de Software. Antes de tratar especificamente desse assunto, é importante delinear o paradigma atual de contratação de Soluções de Tecnologia da Informação no Governo Federal.

Os órgãos da Administração Pública Federal (APF) têm adotado a prática da execução indireta dos serviços que dão suporte às suas áreas finalísticas, conhecida comumente como “terceirização de serviços”, inserindo-se entre estes os serviços de Tecnologia da Informação (TI).

Este fato deve-se, principalmente, às disposições estabelecidas no Decreto-Lei 200/1967, que traz, no art. 10, §7º, a diretriz para que a APF se desobrigue da realização de tarefas executivas (execução de tarefas operacionais), recorrendo, sempre que possível, à execução indireta.

De acordo com o Decreto, os principais objetivos da a adoção da execução indireta são: permitir que a Administração Pública Federal execute melhor as atividades de gestão e governança; e impedir o crescimento desmesurado da máquina administrativa, em função da incorporação de tarefas de caráter operacional.

Neste aspecto, é importante lembrar que os serviços de TI são normatizados no âmbito do SISP. O SISP - Sistema de Administração dos Recursos de Tecnologia da Informação – tem o objetivo de organizar a operação, controle, supervisão e coordenação dos recursos de informação e informática da administração direta, autárquica e fundacional do Poder Executivo Federal.

O SISP instituiu a Instrução Normativa-SLTI/MP nº 4 de 2014 que dispõe sobre o processo de contratação de Soluções de Tecnologia da Informação, que é o atual paradigma de contratação de Serviços de TI, abrangendo inclusive os serviços de desenvolvimento e manutenção de sistemas, na modalidade denominada Fábrica de Software.

Depois dessa digressão, retomamos nosso foco, discorrer sobre os serviços de desenvolvimento e manutenção de sistemas, na modalidade denominada Fábrica de Software. Mais especificamente, o que eu gostaria de discutir é sobre um conceito inerente à denominação "Fábrica de Software".

Esta denominação embute uma analogia dos serviços de desenvolvimento de sistemas a uma fábrica ou estabelecimento fabril, que nos moldes e metodologias se afiguraria ao paradigma do Fordismo. Essa apropriação é resultado da proximidade e influência da área de conhecimento da engenharia sobre a Tecnologia da Informação.

De fato, podemos de relance observar esta influência, nas terminologias, no métodos e nas metodologias, nas áreas de estudo, entre outros. Não que constitua algum demérito estas heranças, desde que guardadas as devidas proporções. Esta premissa se aplica perfeitamente ao falarmos de Fábricas de Software, que tem sido considerada e gerenciada como uma atividade fabril, em seu sentido original.

Esta conclusão não se fundamenta apenas no aspecto semântico. As Fábrica de Software reproduzem praticamente todos os aspectos de um modelo fordista: racionalismo; padronização, linhas de produção lineares; produção em massa; foco em processos e divisão do trabalho hierárquica.

Certamente estes aspectos contribuem para a eficiência das atividades desenvolvidas nas Fábricas de Software, desenvolvimento de sistemas que contribuam para o alcance de determinados objetivos. Até este ponto nada a reparar, o que tem sido discutido amplamente, e foi o cerne da provocação que incentivou estas considerações, é a adequação deste modelo à natureza do produto pretendido: software ou sistema de informação.

Obviamente partimos da premissa de que existem certos produtos que são mais adequados a um processo industrial do que outros. Assim como existem certos produtos cujas características exigem por si só um processo mais artesanal. Trazendo esta análise aos produtos software ou sistema de informação, podemos fazer a seguinte analogia: software está para um veículo automotor, assim como sistemas estariam para veículos espaciais.

Um software normalmente atende a resolução de um problema específico, pode possuir regras e características padronizadas, os requisitos e as especificações são facilmente identificadas, dentre outras características. Partindo destes pressupostos, o que se verifica de fato é que o processo de "construção" do software é mais previsível. Desse modo, são mais suscetíveis ao processo do que à atividade humana, no sentido de que se o processo for repetível as variações nos produtos são menos relevantes.

Por outro lado, os sistemas são produtos predominantemente intelectuais, portanto muito mais suscetíveis às variabilidades da ação humana. Tomadas determinadas entradas (requisitos, especificações, etc), a mera utilização de uma receita (processo) não garante que será gerado o mesmo produto. Dessa forma, o "produto" sistema depende muito mais da atividade humana do que do processo, poderíamos caracterizá-los como mais adequado a um processo artesanal. 

Estas constatações não são recentes, a tempos consideráveis a literatura acadêmica de engenharia de software relata observações similares. Isto nos leva a indagar, quais circunstâncias levam os contratantes ou usuários dos serviços de Fábrica de Software a não considerarem tais características. O que tem sido observado no âmbito da Administração Pública Federal é uma predominância da utilização de Fábricas de Software de modo indistinto, softwares e sistemas são demandados à empresas contratadas, sem considerar suas complexidades, características, ou peculiaridades que poderiam levar à utilização de uma "fabricação" mais fabril ou mais artesanal.

Estes aspectos abordados são relevantes não apenas sob a ótica conceitual, é sabido que a eficiência tende a acarretar economicidade. Dessa forma, a não diferenciação acaba gerando ineficiência e ineficácia, segundo as estatísticas do ISBSG, International Software Benchmarking Standards Group, são  comuns os projetos de desenvolvimento em regime de fábrica que acabam fracassando.

O propósito destas considerações foi discorrer brevemente sobre a adequação do modelo de Fábrica de Software ao desenvolvimento de softwares e sistemas de informação, e fomentar discussões sobre melhorias cabíveis para reduzir as ineficiências observáveis no paradigma atual. Espero ter trazido contribuições para o debate, e em breve serão trazidas outras considerações relevantes sobre o assunto.

Celson Carlos Martins Júnior é aluno do Mestrado Profissional em Computação Aplicada da Universidade de Brasília, Servidor Público do Ministério do Planejamento, e atua na SLTI em contratações  de Tecnologia da Informação.