Um Paralelo entre Residência Médica e a Residência em Software

Atualmente, o termo residência em software é utilizado por várias instituições de ensino superior, empresas, pesquisadores da área da educação em ciência da computação e órgãos de fomento a pesquisa (cito o CNPq que lançou, no início deste ano, um edital para financiar programas de residência em software no país – www.cnpq.br). 

A idéia de residência médica foi criada no Brasil pelo decreto número 80.281 de 05 de setembro de 1977, e se caracteriza como uma modalidade de ensino de pós-graduação. Esta pós visa o aperfeiçoamento dos médicos sob a forma de um curso de especialização, na qual este se insere em uma instituição de ensino ligada à área de medicina. Ao concluir o curso o médico adquire o título de especialista. O tempo de residência médica irá variar de acordo com a especialização. Especialistas em cirurgias ficam 4 anos imersos no ambiente de residência. Já para obter a especialidade de ginecologista, o tempo de residência é de 3 anos. Outras especialidades possuem residência de dois anos.

Na medicina, o residente vive, na maioria das vezes, em um ambiente hospitalar, situações reais dentro de seu escopo de conhecimento. Tal experiência é monitorada por um corpo de especialistas. A residência em software tende a tomar mesma linha de raciocínio: proporcionar uma vivência ao aluno de graduação ou aos profissionais já formados das áreas de TI (alunos de pós), dentro de um ambiente real, que possua políticas de qualidade bem definidas, com o objetivo de promover a disseminação dos conceitos de qualidade de software, processo de produção e gestão de projetos para a área de engenharia de software.

Salienta-se que um dos primeiros trabalhos publicados que relata a idéia de residência é brasileiro, o Centro de Informática da Universidade Federal de Pernambuco apresenta a idéia de residência focada em teste de software, vale a pena dar uma olhada (SAMPAIO, A. et. al. Software Test Program. A Software Residency Experience. Proceedings of 27th International Conference on Software Engineering (Educational Track). St. Louis, USA. 2005). Outras experiências completam este quadro:

·        Programa de residência do Bank of New York Mellon: com início em 2008, tem o objetivo de formar engenheiros para as áreas de desenvolvimento, análise de negócios e gerenciamento de projetos. No desenvolvimento, focando J2EE, XML, Business Inteligence System e Datamining WebService. Na análise de negócio, focando a ajuda ao cliente em seu entendimento da tecnologia necessária e do necessário alinhamento desta com seu negócio. No gerenciamento de projetos e processos, focando o provimento de um conjunto de conhecimentos específicos de gestão e de execução de processos de produção de software. (http://www.bnymellon.com/careers/softwareresidency.html);

·        Programa de residência da Universidade Federal da Bahia: criado em 2005, com foco específico em governo eletrônico;

·        Centro de Residência do Departamento de Engenharia de Produção da Escola Politécnica da Universidade de São Paulo: iniciado em 2002, com o objetivo de prover uma formação sólida para os profissionais de TI, principalmente sob a ótica da qualidade de software;

·        Programa de Residência em Desenvolvimento de Software PUC - Rio - http://wiki.les.inf.puc-rio.br/index.php/PRDS

·        Centro de Residência da Faculdade de Tecnologia de Ourinhos: criado em 2005, em parcerias com o Departamento de Engenharia de Produção da Escola Politécnica da Universidade de São Paulo e com a iniciativa privada, focando o provimento de uma formação qualificada aos estudantes do último ano do curso de graduação na área de qualidade e produtividade de software (maiores informações sobre a residência em software da FATEC-OU pode ser verificada em Residência em Software: Um Caso Real e uma Proposta Genérica para a Normatização de Novos Programas);

É, perfeitamente, possível estabelecer uma relação direta entre a residência médica e a residência em software. A primeira, para se concretizar, necessita das seguintes entidades:

·          Curso Superior (graduação e pós-graduação em Medicina);

·          Hospital;

·          Residentes (médicos);

·          Pacientes;

·          Médicos/Professores (tutores no ambiente de residência médica);

·          Laboratórios;

·          Produtos de trabalho.

Já a segunda necessita de:

·        Curso Superior (graduação e pós-graduação na área de informática);

·        Empresas produtoras de software atuando no mercado (o hospital da residência em software);

·        Residentes (alunos do último ano de graduação ou profissionais da área de engenharia de software (aluno de pós));

·        Clientes/empresas que necessitam de software (o paciente da residência em software)

·        Engenheiros de Software/Professores (tutores no ambiente de residência em software)

·        Laboratórios

·        Produtos de trabalhos.

Por fim, é salutar dizer a todos que um programa de residência em software deve inserir o aluno da graduação ou da pós-graduação em um ambiente real de produção de software e este ambiente é encontrado, na maioria das vezes, no contexto empresarial. No Brasil, será que a residência pode colaborar com a melhoria do processo e do produto caracterizado como software?

 

José Augusto Fabri

Faculdade de Tecnologia de Ourinhos

Fundação Educacional do Município de Assis

 

Fontes de consulta:

SAMPAIO, A. et. al. Software Test Program. A Software Residency Experience. Proceedings of 27th International Conference on Software Engineering (Educational Track). St. Louis, USA. 2005.

SAMPAIO, C. A. S.; LIMA, J. M. Residência em Software. Revista PROQUALIT – Qualidade na Produção de Software. Editora UFLA. Volume 2. Número 1. Maior de 2006.

FABRI, J. A.; TRINDADE, A. L. P. Residência em Software: Um Caso Real e uma Proposta de Genérica para a Normatização de Novos Programas. VII Jornadas Iberoamericanas de Ingeniería del Software e Ingeniería del Conocimento. Quito. Ecuador. Fevereiro de 2008.

o SOFTWARE pode ser chamado de SISTEMA?

Vários profissionais que atuam no mercado utilizam a palavra SISTEMA para denominar um produto caracterizado como SOFTWARE, desta forma,  a palavra SISTEMA  pode ser utilizada como sinônimo de SOFTWARE? Todo SOFTWARE pode ser classificado como SISTEMA?

Segundo Sommerville, Pressman, Paula Filho e Pedrycz, o termo SOFTWARE é definido como um programa de computador, uma seqüência lógica de instruções a serem seguidas e/ou executadas, na manipulação de um determinado conjunto de informações. SOFTWARE, também, pode ser classificado como um conjunto de produtos desenvolvidos durante o processo de software, por exemplo: programa de computador, manuais, especificações e planos de teste.

Já Ludwig von Bertalanffy define SISTEMA como um conjunto de elementos que se conectam, harmonicamente, com o objetivo de formar um todo unificado (é importante afirmar que isso acontece com o SOFTWARE, somente quando o mesmo é dividido em partes). Em grego (primeira língua a utilizar a palavra em questão), SISTEMA significa combinar, ajustar e formar um conjunto. A partir da obra de Bertalanffy, é possível inferir alguns conceitos primários da teoria de SISTEMA:

1.     Todo SISTEMA está ligado à totalidade de um corpo de conhecimento ou a uma teoria específica (conceito aderente a idéia de SOFTWARE).

2.    Um SISTEMA pode sofrer constante mecanização ou automação agilizando, assim, a execução de seus processos (nesse caso o SOFTWARE passa a ser caracterizado apenas como uma ferramenta e não como um SISTEMA).

3.    Um SISTEMA só é criado quando surge uma nova teoria (conceito pouco aderente a idéia de SOFTWARE).

Com base nos relatos de Bertalanffy e nas definições de propostas por Sommerville, Pressman, Paula Filho e Pedrycz, acredito que SOFTWARE não deva ser denominado como SISTEMA, tal afirmação está alicerçada nos três conceitos destacados anteriormente.

Não podemos classificar como SISTEMA um SOFTWARE que controla a parte acadêmica de uma universidade ou de uma escola. O SISTEMA de controle acadêmico foi modelado  com o surgimento da própria universidade (datada do século XII) ou da própria escola. Foi com a criação da “teoria sistêmica universitária” que os processos de controle de freqüência, de matrícula e de controle de notas foram criados. O SISTEMA bancário pode ser considerado outro exemplo: o SOFTWARE ou um conjunto de SOFTWARES apenas automatizam o processo dentro desse SISTEMA (no Brasil tal SISTEMA surgiu em 12 de outubro de 1808). Não desenvolvemos o SISTEMA para controle bancário, mas um SOFTWARE para controle bancário.

Um dos poucos SOFTWARES que podem ser chamado de SISTEMA, é o SISTEMA operacional computacional, o qual surgiu com o advento do computador (uma nova teoria ou uma nova invenção).

Na maioria das situações, cometemos um grande erro ao denominar SOFTWARE como SISTEMA. Não é trivial criar um SISTEMA, podemos modelá-lo. SISTEMA está ligado a alguma coisa nova, a uma nova teoria, a uma invenção, a um novo paradigma.

É fundamental destacar que essa é a minha posição sobre o assunto. E a sua?

Prof. José Augusto Fabri

Fontes de Consulta:

BERTALANFFY, Ludwig von. Teoria Geral dos Sistemas. Tradução de Francisco M. Guimarães. 2ª. Edição. Petrópolis, Vozes. 1975.

Como motivar o aluno nas disciplinas introdutórias da área de programação?

Vários cursos, das mais variadas áreas do conhecimento, possuem em sua estrutura curricular a disciplina de lógica de programação, na qual esta trabalha, basicamente, com o ensino de algoritmos e linguagens de programação. Na maioria das universidades, centros universitários e faculdades isoladas o ensino, direcionado pela disciplina em questão, está focado predominantemente no paradigma estruturado aliado a utilização de linguagens procedurais como C e Pascal. Um fato chama a atenção nestas disciplinas: A QUANTIDADE DE REPROVAS OU DESISTÊNCIAS. Os dados apresentados a seguir comprovam minha afirmação:

·          Os cursos de lógica de programação iniciam com uma média de 50 alunos e em poucos meses, constata-se que taxa de reprovação (ou desistência) chega a 60% (dados extraído de Rocha (1993)).

·          Os dados delineados por Rocha (1993) são compartilhados pelas instituições que apadrinham o autor deste texto, a Fundação Educacional do Município de Assis (www.femanet.com.br) e a Faculdade de Tecnologia de Ourinhos (www.fatecou.edu.br), vejam só:

o     Faculdade de Tecnologia de Ourinhos – Ingressantes: 200 alunos. Concluintes: cerca de 50%.

o     Fundação Educacional do Município de Assis – Ingressantes: 70 alunos. Concluintes: cerca de 55%.

Com base nos números apresentados é possível constatar que nós professores estamos com um problema eminente nas mãos.  Será que existem meios que possibilitem o ensino de lógica de programação com mais eficiência e eficácia? As linguagens e o paradigma nos cursos de lógica de programação são adequados ao ensino? Como motivar o aluno dentro das disciplinas introdutórias da área de programação? Alguns trabalhos buscam constantemente uma solução para estas questões, entre eles é possível citar Baranauskas (1993), Fernandes et. al. (2000), Fernandes e Menezes (2001) e Prus (2001). Vale à pena dar uma olhada neles.

Neste texto gostaria de tratar uma questão em especial: a motivação dos alunos nas disciplinas introdutórias de programação.

É de conhecimento da comunidade que os alunos ingressantes nos cursos, de computação, nasceram na era da informação, tem um contato estreito com diversas mídias, e seu raciocínio não é linear. Alguns fatos chamam a atenção na formação básica destes alunos, destaco três deles, fique a vontade para apresentar um número maior:

·          A leitura não é um hábito cultivado sistematicamente. Em uma pesquisa feita com meus alunos pude constatar que cerca de 90% não leram livro algum em 2007.

·          A maioria dos alunos não possui o hábito de passar horas e horas estudando. A necessidade de estudar algumas horas durante todos os dias não é uma idéia bem aceita entre eles.

·          Adoram jogar, isto mesmo, trabalhamos com a geração dos jogos digitais.

Ao contrapor os itens citados às características que permeiam as disciplinas introdutórias da área de programação esbarramos na seguinte “regra de produção”.

SE os alunos não possuem o hábito de ler E não passam horas estudando ENTÃO os cursos de lógica de programação possuem altos índices de reprovação ou abandonos.

(A regra de produção está contextualizada para o ensino de lógica de programação. Será que ela pode ser generalizada?).

Para que a regra apresentada não seja disparada, é necessário que nós professores motivemos nossos alunos. Parto do seguinte premissa: as tarefas mais interessantes são menos árduas de realizar. Dentro deste contexto desenvolvi uma experiência junto aos alunos do primeiro ano, do curso de Análise de Sistemas e Tecnologias da Informação, da FATEC de Ourinhos, tal experiência é baseada no trabalho “O Ensino de Lógica de Programação e o Desenvolvimento de Jogos Educacionais: Um Caso Aplicado aos Alunos do Curso de Licenciatura Plena em Matemática”, publicado no final do ano de 2007. Para contextualizar a idéia de algoritmo, propus aos alunos o desenvolvimento de um jogo. Apresentei, a eles, em 6 horas, o conceito básico de algoritmo e alguns comandos da linguagem logo (logo é caracterizada como uma linguagem interpretada voltada, principalmente, para o ensino de crianças e aprendizes em programação, para maiores informações faça o download em www.nied.unicamp.br/publicacoes/pub.php?classe=software&cod_publicacao=70). E, por fim, incentivei-os a desenvolver um jogo para ensinar matemática e aritmética para crianças.

Para o desenvolvimento do jogo estabeleci o seguinte processo:

1.     Atividade 1 – Desenvolvimento e validação, junto ao professor, da interface do jogo.

2.     Atividade 2 – Programação do jogo. Importante: Os conceitos de testes formais não foram abordados.

Após terminar o desenvolvimento, propus os alunos que apresentassem os seus joguinhos em uma seção pública, veja só alguns resultados:

·          Jogo 1: Passeio com a TAT. Objetivo: Fazer com que a TAT leve seus amiguinhos para passear, utilizando meios como distância e ângulos. Os comandos utilizados nesse jogo é pf (para frente); pt (para trás); pe (para esquerda) e pd (para direita). Público alvo: Criança alfabetizadas. Autoras: Camila, Lorena, Marija e Tamirys.

·          Jogo 2: Super Turtle 2008. Objetivos: Cada participante terá que levar a sua tartaruga até o fim do tabuleiro. O jogo é para dois jogadores. Público alvo: Crianças alfabetizadas. Autores: Cleiton, Carla e Karoline.

·          Jogo 3: Caça ao Tesouro. Objetivos: Levar a tartaruga TAT ao mapa, a chave, a pá e ao tesouro. Público alvo: Crianças alfabetizadas.  Autores: Rafael, Julcimar, Rodrigo e Rodrigo Mascari.

As interfaces dos jogos 1, 2 e 3 podem ser verificadas no arquivo Interface dos jogos.

Com o desenvolvimento dos jogos foram colhidos alguns resultados resultado qualitativos, detaco alguns deles::

1.    Aumento da motivação do aluno para com a disciplina. Os alunos questionam se é possível fazer algo mais elaborado com a linguagem C. Respondo que sim, porém é necessário, neste momento, termos uma boa “alfabetização algorítmica”.

2.     Aumento do conhecimento e habilidades dos alunos dentro da área de lógica programação. O programa de computador foi desmistificado logo no início da disciplina.

3.     Expectativa de continuidade dos estudos dentro da área de desenvolvimento de jogos educacionais, principalmente, nos próximos anos da faculdade.

4.     O aluno tem consciência que para produzir um programa é necessário algumas horas de estudo.

A experiência apresentada encontra-se em um estágio inicial, resultados quantitativos relacionados ao número de desistências e reprovas só serão obtidos no final deste semestre. Fica a sugestão para os professores trabalharem com produção de um jogo logo no início da disciplina de programação. Por favor, não se esqueça de estabelecer um processo de produção para trabalhar com este tipo de desenvolvimento.

José Augusto Fabri

Referências

Rocha, H. V. (1993). Representações Computacionais Auxiliares ao Entendimento de Conceitos de Programação. In: “Computadores e Conhecimento: Repensando a Educação”. Livro organizado por Valente, J. A. Editora Unicamp.

Prus, E. M. (2001). “Um Modelo de Sistema Tutor Inteligente Aplicado ao Ensino da Programação Estruturada”. Dissertação de mestrado ao Departamento de Engenharia de Produção e Sistemas da Universidade Federal de Santa Catarina.

Baranauskas, M. C. C. (1993). Uma Abordagem Construcionista ao Design de um Ambiente para Programação em Lógica. In: “Computadores e Conhecimento: Repensando a Educação”. Livro organizado por Valente, J. A. Editora Unicamp.

Fernandes, C. S.; Menezes, P. B. (2001) Metodologia do Ensino de Ciência da Computação: Uma Proposta Para Criança. In: “Anais do Workshop de Informática na Escola”. Fortaleza – Ceará.

Fernandes, C. S., Menezes, P. B., Accorsi, F. (2000) A Propose of Teaching Computer Sciencefor Children. In: “Internacional Conference on Engineering and Computer Education – ICECE”, São Paulo.

Fabri. J. A. O Ensino de Lógica de Programação e o Desenvolvimento de Jogos Educacionais: Um Caso Aplicado aos Alunos do Curso de Licenciatura Plena em Matemática. In Anais do Simpósio Brasileiro de Informática na Educação. São Paulo, 2007.

Nossas Fábricas de Softwares são Melhores que as Fábricas Japonesas de Década de 1970?

 

Freqüentemente encontro com ex-alunos, amigos que trabalham no setor produtivo de software, colegas de outras instituições, e pergunto: Por onde andas? Qual a empresa que você trabalha? O que esta empresa faz? Em várias ocasiões recebo as seguintes respostas:  

• Professor estou trabalhando em uma fábrica de software (resposta delineada por ex-alunos e amigos).
• Na minha instituição de ensino estamos desenvolvendo um piloto para a composição de uma fábrica de software (resposta delineada por colegas de outras instituições).

Costumo ver também várias empresas utilizarem o termo fábrica de software na composição de seu nome fantasia ou de seu processo de produção. Com base nestas informações, questiono: Será que sabemos o que realmente é uma fábrica de software? Será que o processo fabril de produção de software evoluiu durante os últimos 40 anos ou estamos usando as mesmas práticas apresentadas ao mundo, pelos japoneses, na década de 1970? O que temos de novo nesta área?

 

A meu ver, uma fábrica de software deve ser caracterizada como uma organização estruturada, voltada para a produção do produto software, totalmente alicerçada na engenharia e com organização do trabalho, modularização de componentes e escalabilidade produtiva caracterizada. Deve possuir, ainda: um ambiente de gerenciamento de projetos; um processo padronizado, definido e institucionalizado; políticas que garantam a qualidade do produto; um conjunto de ferramentas para mecanizar gerenciamento de projeto, processo e construção; técnicas para medir e estimar custo, prazo e tamanho de uma equipe para um determinado projeto; ambiente de teste definido e padronizado; foco em um segmento de mercado e; política de desenvolvimento de recursos humanos.

 

A primeira pessoa a utilizar o termo fábrica de software foi Bemer em 1969. Além dele, na década de 1970, várias empresas Japonesas instituíram um processo fabril em seu contexto produtivo, entre elas é possível citar: a Hitachi: fábrica instalada em 1969; a Toshiba: fábrica instalada em 1977; a NEC: fábrica instalada na década de 1970; a Fujitsu: fábrica instalada em 1979.

 

Todas as empresas citadas no parágrafo anterior conseguiram altos índices de produtividade e qualidade dentro do setor produtivo de software, neste texto, como exemplo, cito os índices obtidos pela Toshiba (veja a Tabela 1).

 

Ao analisar a Tabela 1, é possível constatar alguns pontos importantes:

• Na Toshiba, em 1972, o total de linhas de código entregues em Assembly por programador era de 1230. Após a instalação da fábrica, em 1978, este número cresceu 37%, culminando em 154% em 1985. 
•  A empresa em questão, em 1985, atingiu um percentual de 48% no reuso de código. A cada 100 linhas de código entregues aos clientes, 48 linhas eram caracterizadas como reuso de código. Será que este pessoal conhecia a idéia a idéia de componentização? Será que o código componentizado era de qualidade?

Para efeitos comparativos vou apresentar alguns dados quantitativos, brasileiros, mapeados por Costa (2003) e um estudo de caso feito em 6 fábricas brasileiras (cinco delas possuem certificação CMMI, a sexta possui ISO 9001). Maiores detalhes sobre este estudo pode ser verificado no artigo em anexo: Um Estudo Comparativo entre as Fábricas de Softwares Brasileiras e Japonesas.

 

Costa (2003) apresenta uma pesquisa envolvendo 31 empresas, as mais significativas, que atuam no mercado brasileiro utilizando o modelo de Fábrica de Software. Destas, apenas 41% aplicam um ciclo completo de desenvolvimento de software para seus produtos; 45% aplicam metodologia própria; 16% utilizam ferramentas de controle de projetos; 14% possuem certificação CMMI ou ISO; 13% utilizam ferramentas CASES e 10% aplicam métricas de qualidade.

 

As 6 empresas citadas no artigo (Um Estudo Comparativo entre as Fábricas de Softwares Brasileiras e Japonesas) implementam um ciclo completo de desenvolvimento, porém encaram como fábrica, somente a produção de código. O conceito de reuso de código ou componentização é praticada formalmente somente um uma delas, as demais praticam tal conceito de maneira informal. Todas as empresas, inclusive as japonesas, utilizam no mínimo uma ferramenta para gestão de projeto e controle da produtividade. As fábricas brasileiras também possuem um controle rigoroso em relação à produtividade, porém nenhuma delas controla a produtividade como a Toshiba. Por fim, as empresas japonesas não utilizavam qualquer tipo de norma de qualidade, como por exemplo: o CMMI, porém as métricas sobre a qualidade do processo e do produto são verificadas em todas as fábricas nipônicas.

 

Ao analisar o contexto apresentado é possível verificar que o processo fabril das empresas brasileiras pesquisadas não sofreu grandes mudanças quando comparados aos processos japoneses da década de 1970 e 1980, principalmente, sob a luz do controle de produção. Este fato mostra que a teoria processual para software com características fabris vem sendo aplicada, sistematicamente, a cerca de 40 anos. Os modelos de qualidade de software e de gerenciamento de projetos contribuíram para a disseminação de alguns aspectos de qualidade (nas empresas brasileiras), já praticados pelas empresas japonesas. Podemos dizer que houve, sim, uma modernização das ferramentas de gestão, promovendo uma maior integração de dados de controle de produção, da forma de programar (com a institucionalização da orientação a objetos – lembrando que a OO foi criada na década de 70), com o adventos das IDEs e com a forma da distribuição das informações. Porém, a essência dos aspectos de controle de produção, e de gestão de projetos continua teorizando as bases conceituais definidas pelos japoneses. Será que a gestão de um processo de produção de software evoluiu em algum lugar?

 

Saudações.

 

Prof. José Augusto Fabri.

Faculdade de Tecnologia de Ourinhos.

Fundação Educacional do Município de Assis.

 

Fonte de Consulta:

 

Bemer, R. W.; The Economics of Program Production; In: Information Processing -  vol.II, no 68; Amsterdan: North-Holland Publ.Co, 1969

 

Costa, Ivanir; Contribuição para o aumento da qualidade e produtividade de uma fábrica de software através da padronização do processo de recebimento de serviços de construção de softwares - 174 pag.; Tese (Doutorado) Apresentada ao Departamento de Engenharia de Produção da Universidade de São Paulo; São Paulo: PoliUSP, 2003

 

Cusumano. M. A. Japan’s Softwares Factories. New York: Oxford University Press. 1991.

Fabri, J. A. et. al. Um Estudo Comparativo entre as Fábricas de Softwares Brasileiras e Japonesas. Simpósio Internacional de Melhoria de Processo de Software. São Paulo. 2007.

A Programação em Par (Pair Programming) pode Melhorar a Capacidade Produtiva de uma Empresa de Desenvolvimento de Software?

O desenvolvimento de um produto caracterizado como software é norteado por um processo de produção. Este processo, por sua vez, é dividido em atividades, tais como: levantamento requisitos, modelagem de negócio, projeto do software, implementação, teste e a implantação. A programação em par é uma das “boas práticas” propostas para atividade de implementação. Mas o que vem a ser tal tipo de programação? Quando ela surgiu? Existem benefícios de se trabalhar com a programação em par? Ela melhora a capacidade produtiva de uma empresa? Se sim, existem resultados quantitativos que comprovam este fato?

O primeiro relato da programação em par é datado de 1995, na obra de L. L. Constantine (veja a fonte de consulta no final deste texto), posteriormente, esta prática foi incorporada pela proposta do eXtreme Programming.

A programação em par é uma técnica na qual dois desenvolvedores trabalham em um mesmo problema, ao mesmo tempo e em uma mesma estação de trabalho. Enquanto uma pessoa assume o teclado (o PILOTO) e digita os comandos que farão parte do programa, a outra (o NAVEGADOR) realiza o trabalho de estrategista.

Benefícios da programação em par: Revisão constante do código, alguns erros são corrigidos no ato. A modelagem do programa pode ficar mais otimizada, pois existem dois programadores trabalhando para solucionar um mesmo problema. A modelagem do programa é, geralmente, mais simples.

Porém existem algumas questões negativas que pairam sobre a prática aqui apresentada:

• Por que colocar dois programadores para fazer o trabalho de um?
• Não estamos desperdiçando um programador?

Para responder tais questões, apresento neste artigo três experiências desenvolvidas com a programação em par. Duas delas foram desenvolvidas junto aos alunos do 5º ano do curso de Ciência da Computação (BCC) da Fundação Educacional do Município de Assis (www.fema.edu.br) e uma junto aos alunos do 6º semestre do curso de Analise de Sistemas e Tecnologias da Informação (ASTI) da Faculdade de Tecnologia de Ourinhos (www.fatecou.edu.br). Saliento que tais experiências foram adaptadas do trabalho publicado por Laurie Williams (http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF). A Tabela 1 (Informações mapeadas nas experiências) apresenta as informações mapeadas nas três experiências.

Ao analisar os resultados, apresentados na Tabela 1, é possível constatar que os algoritmos desenvolvidos em par apresentam uma maior qualidade. Na experiência de 2007, 100% dos algoritmos desenvolvidos por dois programadores rodaram, contra 55% desenvolvidos individualmente. Em 2008, a tendência é a mesma. Um resultado que chama a atenção na tabela é o tempo de desenvolvimento, os pares foram mais rápidos que os programadores individuais, nas experiências desenvolvidas na FEMA. Na FATEC o tempo de desenvolvimento foi de 36 minutos para ambos. Na experiência desenvolvida por Constantine (1995) é possível verificar que o tempo de desenvolvimento dos pares tendem a cair com o passar do tempo, fato este confirmado junto aos alunos da FEMA.

Com base nos números apresentados é possível constatar que programação em par pode melhorar a capacidade produtiva, principalmente na questão da qualidade do produto, de uma empresa software, basta que seus gestores tenham coragem de implementá-la.

Por fim, gostaria de agradecer aos alunos que participaram desta experiência e convidar a comunidade empresarial a implementar tal prática e compartilhar os relatos de sua produtividade com todos.

Saudações.

Prof. Dr. José Augusto Fabri.
Faculdade de Tecnologia de Ourinhos.
Fundação Educacional do Município de Assis.

Fonte de consulta:
L. L. Constantine, Constantine on Peopleware. Englewood Cliffs, NJ: Yourdon Press, 1995.

Ações que podem promover melhoria na qualidade do software Brasileiro

Ao tentar responder a questão: “Quem pode mudar o mercado brasileiro no setor produtivo de software” (vide o texto anterior) recebi questões, críticas e sugestões de alguns colegas, algumas delas, a meu ver, merecem destaque:

1. Por onde começar a mudança?
2. Boas práticas não são bem aceitas, principalmente, entre os profissionais da área.
3. Os profissionais não estão atentos as questões de melhorias e sempre fazem tudo para ontem.
4. Não adianta que o recém formado saiba qualidade profundamente, ele não será um gerente de projeto. O aluno precisa conhecer JAVA, .NET, Oracle para encontrar um emprego.
5. Os conceitos de qualidade devem ser empregados em programas de pós-graduação.

Antes de apresentar um conjunto de ações para iniciar o processo de mudança no setor produtivo de software e desenvolver as considerações relativas às questões, críticas e sugestões, vamos recordar que o desafio da mudança está ligado, diretamente, aos alunos, professores, profissionais do mercado, empresas e universidades – não isentamos o governo, lembre-se disto. (vide texto: Quem pode mudar o mercado brasileiro no setor produtivo de software?)

Para iniciar o processo de mudança, podemos estabelecer um conjunto de ações nos primeiros anos da graduação, os professores que trabalham com as disciplinas de programação poderiam cobrar de seus alunos uma padronização do código, existem diversos modelos disponíveis, sugestão: o Java Code Convention (http://java.sun.com/docs/codeconv/). Para aqueles que não trabalham com Java, existe a possibilidade de propor uma padronização de código, independentemente, da linguagem.

O checklist de teste também pode ser aplicado aos alunos das séries iniciais. Veja só uma proposta, extremamente simples:

• Teste de consistência: Campo deve possuir somente entrada M ou F, entre com outra letra.
• Teste de dígito verificador: CGC, CPF, etc.
• Teste de limite de campo: Uma variável ou um campo qualquer é definido como inteiro, entre com o valor que supere o limite do campo.
• Teste de número negativo: Entre com um valor negativo para o campo idade.
• Teste de zero ou Branco: Digite zero para o código e branco para o nome.

Nota: Utilizei o checklist apresentado com várias pessoas em vários ambientes: empresas, sala de aula (formandos), cursos de pós-graduação. Cerca 95% dos programas desenvolvidos não passaram no teste.

Ao passar uma lista de exercício, desenvolva o cronograma de entrega junto ao aluno, utilize algum software que proveja este recurso. Sugestão: Gantt Project disponível em http://ganttproject.biz/download.php. Force o aluno a controlar e corrigir o cronograma proposto durante a execução da lista de exercícios. Compare o orçado ao realizado.

Apresente algumas listas de exercícios na língua inglesa para os seus alunos, colabore com o professor da disciplina de Inglês Técnico.

Apresente ao aluno das séries iniciais softwares de controle de versão, temos vários disponíveis: cvs (http://www.tortoisecvs.org/download.shtml), subversion (http://subversion.tigris.org/). Lembre-se que o aluno pode controlar as versões do programa em desenvolvimento.

Dê noções de rastreabilidade de requisitos, lembre-se que a implementação de um programa depende de um enunciado em uma lista de exercício, de um projeto de algoritmo apresentado em fluxograma (ou portugol) e, por fim, o programa será melhorado, constantemente, até chegar a um produto que agrade ao cliente, que neste caso é o professor. Tudo isto está interligado e pode ser rastreado.

Desenvolva junto ao aluno um diário de bordo, faça-o anotar em um caderno a data e o tempo de desenvolvimento de um determinado algoritmo ou programa.

Apresentei algumas “boas práticas”, se assim os senhores me permitirem delineá-las para a área de produção de software, que podem ser aplicadas nas séries iniciais. Fique a vontade para apresentar sugestões para as séries intermediárias e finais.

É importante ressaltar que se as boas práticas foram tratadas durante todo o tempo que o aluno permanece na universidade com certeza elas serão melhores aceitas ou incorporadas pelas empresas no futuro. Se os alunos souberem a sua capacidade de produção, não teremos tantos projetos atrasados (faça a seguinte experiência: pergunte ao aluno ou aos profissionais de mercado qual a sua capacidade de produção?). Lembre-se que os alunos de hoje são os profissionais de amanhã.

Concordo que o recém formado, não será contratado, na maioria das vezes, como um gerente de projeto, concordo também que ele deve saber todas as tecnologias citadas no item 4 (vide o início deste texto). Porém, acredito que a tecnologia não é o foco mais importante dentro da nossa área, lembre-se que uma base teórica sólida provê ao aluno a capacidade de aprender qualquer tecnologia. A tecnologia é instável e os paradigmas são estáveis (não é trivial quebrar ou propor um novo paradigma, vide Thomas Kuhn). Questiono: O que é mais importante, conhecer o paradigma orientado a objetos ou os comandos de uma linguagem de programação orientada o objetos? Álgebra relacional ou a interface de trabalho de um banco de dados?

Ressalto, também, que não podemos transferir a responsabilidade das práticas de qualidade para os programas de pós-graduação, devemos sim apresentá-las aos nossos alunos em todos os momentos. Desenvolver a cultura da qualidade é muito mais fácil nas séries iniciais dos cursos de graduação, neste momento o aluno não possui vícios. A boa educação é um exemplo disto.

Enfim, me limitei a vislumbrar algumas ações de melhorias que podem ser aplicadas dentro das universidades, deixo o convite para os profissionais da área, empresas enriquecerem esta discussão.

Saudações.

Prof. Dr. José Augusto Fabri.
Faculdade de Tecnologia de Ourinhos.
Fundação Educacional do Município de Assis.

Quem pode mudar o mercado brasileiro no setor produtivo de software?

Após a redação do texto “O Brasil como um mercado emergente na produção de software” fui questionado e por alguns colaboradores sobre alguns temas:

• A importância da universidade no contexto apresentado.
• Quem tomará a iniciativa para colocar o país dentro do seleto grupo dos exportadores de software: Governo ou empresas?
• Leis trabalhistas e a alta taxa de impostos.
• Dificuldade dos programadores brasileiros com a língua inglesa.

 Ao analisar as questões, pude verificar que todos concordaram com o último parágrafo do texto: “Enfim, não basta somente apresentar ao mundo todas as potencialidades descritas aqui, é necessário que o governo diminua a carga tributária, não podemos pagar cerca de 40% do que arrecadamos para sustento do próprio governo. As empresas, também devem fazer sua parte, se conscientizar que é somente com a qualidade no processo e no produto que poderão atingir mercados internacionais. As universidades e faculdades de tecnologias, também, devem formar profissionais de qualidade para setor produtivo de software”.

Com base neste contexto, afirmo que o aumento da exportação do produto de software no Brasil depende de cada um de nós, isto é: somente por meio de um MOVIMENTO DE CLASSE que alguma coisa pode ser alterada. Vou citar alguns exemplos:

• Inconfidência Mineira (1785): Revolta dos proprietários rurais, intelectuais, clérigos e militares (CLASSES) contra a cobrança de impostos do governo português (a Derrama).
• Proclamação da república: União de um grupo de militares (CLASSE) que culminou na proclamação da república em 1889.
• Movimento das Diretas Já (1984): Movimento civil (CLASSES) liderado por Fernando H. Cardoso, Luis I. Lula da Silva, Ulysses Guimarães, entre outros. Objetivo: Eleições com o voto direto.
• Impeachment do presidente Fernando Collor de Melo: União dos estudantes e da população (CLASSES) para caçar o presidente da república acusado de corrupção. Quem não se lembra da histórica votação ABERTA do congresso nacional.
• Na esfera internacional o destaque vai para a Revolução Francesa (1789 a 1799). União de diversas esferas da sociedade (CLASSE) contra os 2 primeiros poderes da França (Clero e Monarquia).

Uma ação em conjunto dos profissionais da área, estudantes, professores universitários pode colocar este país no lugar que ele merece. É importante que tenhamos consciência sobre a necessidade da qualidade no processo de produção de software, não podemos conviver e aceitar os seguintes números (fonte: pesquisa sobre qualidade e produtividade em software publicada pela Secretaria de Política de Informática. Total de empresas pesquisadas: cerca de 450 - www.mct.gov.br/sepin):

• Somente 69,1% das empresas brasileiras desenvolvem o controle de versão de seus produtos;
• A gerência dos requisitos é feita 24,4%;
• Estimativa de custo é desenvolvida em 55% e a estimativa de esforço em 45,7%;
• Já a estimativa de tamanho é feita em 29%. Questiono: Como as empresas estimam esforço e custo sem estimar o tamanho do software? Será que as empresas sabem o que estão respondendo?
• A Gerência de risco é feita em 11,8% das empresas;
• Gestão de mudança, 10,4%;
• Planejamento formal dos testes, 37,8%;
• Utilização de depurador, 39%.

 Os números apresentados são de 2002, será a situação em 2008 é diferente? Eu afirmo que não. Basta responder a seguinte pergunta: Quem de nós utiliza todas as práticas citadas no processo de desenvolvimento de software (só enumerei algumas, se colocar todas as práticas necessárias a situação fica pior ainda)? Será que temos um processo definido em nossa empresa?

A revolução tem que partir de nós. Temos que direcionar a melhoria da produtividade de software neste país, independente da política governamental. Vou citar algumas ações que podem ser tomadas de imediato:

• Aluno e Profissional da área de mercado: Tomar consciência que existe algo a mais que JAVA, .NET, Linux e Windows. Conhecemos bem estas tecnologias e claro que elas são importantes, porém a engenharia de software vai muito mais longe. Quem de nós conhece pontos por função? O conhecimento na língua inglesa é fundamental. Empresas relatam que profissionais brasileiros não sabem ler textos em inglês, e muito menos falar.
• Empresa: É necessário possuir certificação de qualidade em processo de produção de software. Não tem outra escapatória! Siga o exemplo desta relação de empresas (http://www.mct.gov.br/index.php/content/view/13885.html).
• Professores: É necessário aplicar as práticas relacionadas à engenharia de software a partir dos primeiros anos. Não conheço nenhuma universidade que trabalhe a questão do teste formal nas disciplinas introdutórias da área de programação. Por favor, apresente um checklist básico de teste aos alunos, este é um artefato do processo de produção. Uma padronização de código também poderia ser utilizada. Dê textos em inglês para os alunos. Cobre a leitura destes textos.
• Universidades: Abolir, principalmente, o mercantilismo e se preocupar estritamente com as questões de qualidade do ensino.

Enfim, não estou isentando o governo de qualquer ação de incentivo à produção e exportação de software no Brasil. Afirmo que uma reforma tributária deve ser feita rapidamente. Abrandar as leis trabalhistas também é necessário. Porém, acredito que uma mudança efetiva começa pela nossa CLASSE (profissionais do mercado, alunos, professores, universidade e empresas). O Brasil e mundo são exemplos disso.

Prof. Dr. José Augusto Fabri

Fundação Educacional do Município de Assis

Faculdade de Tecnologia de Ourinhos.

fabri@femanet.com.br

O Brasil como um Mercado Emergente na Produção e Exportação de Software

Atualmente, a produção de software no Brasil é, altamente, deficitária se olhada sob a luz da balança comercial. Em 2007 o país importou cerca de US$ 3 bilhões e as exportações chegaram perto dos US$ 250 milhões. Para cada dólar exportado o país importa 10. Em 2005 a situação era pior ainda, neste ano o Brasil importou cerca de US$ 7.41 bilhões e exportou somente US$ 178 milhões. Para efeitos comparativos, países emergentes como a Índia e a Irlanda exportam cerca de 8 vezes o que importam. Analisando os números questiona-se: Como alterar este cenário dentro de nosso país?

Para responder tal questão vamos destacar algumas potencialidades brasileiras dentro das seguintes áreas: ativos de Tecnologia da Informação (investimentos) e engenharia de software:

• Os grandes investidores em TI continuam sendo os Estados Unidos (US$ 439 bilhões/ano) seguido pelo Japão (US$ 108 bilhões/ano) o Reino Unido e Alemanha completam esta lista.
• Em 2006 o mundo investiu cerca de US$ 1.16 trilhões em TI. No Brasil os investimentos chegaram à casa de US$ 16.2 bilhões superando Índia, Koreia, Rússia, México e Argentina, países estes classificados como emergentes no cenário econômico mundial.
• O Brasil é o 12º. no mundo com o maior investimento em TI, o único país emergente na nossa frente é a China.
• O mercado consumidor brasileiro é extremamente promissor, por exemplo: temos a 5ª. população do mundo, somos os 6º. em números de celulares.
• Alguns ativos de TI, também, merecem destaque neste contexto:
  • A urna eletrônica: Em 2006, 126 milhões eleitores votaram utilizando tal dispositivo (100% dos eleitores). Cerca de 430.000 urnas foram utilizadas. Cerca de 90% dos votos, para a presidência da república, foram processados em 90 minutos.
  • O Brasil é primeiro país no mundo a informatizar a declaração de imposto de renda. Todos nós sabemos das potencialidades dos processos informatizados da receita federal.
  • O Brasil é um dos líderes em projetos de eGoverment, um exemplo disso é o pregão eletrônico, chamado de comprasNet. Com a implantação deste sistema o governo agilizou em 70% o tempo de compra de um produto licitado. Outros 2.000 serviços governamentais são oferecidos via internet.
• O poderio de mão de obra brasileiro também merece ser destacado:
  • O país possui a segunda maior base de desenvolvedores Java do mundo (100.000 desenvolvedores).
  • Nos últimos 3 JavaOne (maior evento Java do mundo) um projeto brasileiro venceu a Duke’s Choice Award, categoria esta que seleciona a aplicação mais inovadora desenvolvida em Java.
• Outro ativo de TI que merece destaque é o sistema bancário brasileiro. Em algumas áreas como: sistema de pagamentos; Internet Banking; cartões e ATMs o Brasil se caracteriza como líder mundial.

O contexto, brasileiro, acima apresentado, não é explorado dentro do mercado mundial de TI, esta afirmação pode ser comprovada com os seguintes dados:

• Os Estados Unidos agregam 80% das operações de offShore (instalação de uma filial, geralmente, em um país emergente cuja mão de obra é mais barata, para fins de tercerização de bens e serviços) no mundo.
• Na União Européia, o Reino Unido, a Alemanha e a França congregam grande parte dos 20% restantes.
• No contexto asiático, o destaque vai para o Japão.

A América Latina exportou 1.8% das necessidades americanas dentro da área de TI.  O Brasil “lidera” esse quadro com 1%. Somente a Índia atendeu cerca 84% das necessidades americanas na área de software. É importante ressaltar que a Índia não possui um cenário tão promissor quanto o descrito anteriormente.

Os fatos apresentados nos remetem a sugerir uma segunda questão: Como o Brasil pode utilizar suas potencialidades para se tornar um dos maiores exportadores de serviços de TI no mundo?

É necessário enfatizar todo o cenário tecnológico favorável apresentado anteriormente, mostrar ao mundo, principalmente, aos americanos o que temos de melhor: O SISTEMA BANCÁRIO/FINANCEIRO (SB/F). É importante salientar que grande parte das operações de offShore americana foca, estritamente, o mercado financeiro. Veja alguns fatores que colocaram o Brasil na liderança neste quesito.

A evolução do  SB/F ocorreu nas décadas de 1970 e 1980, nesta época o Brasil estava fechado para as importações de bens e serviços caracterizados como TI. Este fato, aliado a instabilidade financeira, a constante mudança de moeda e a um sistema tributário, totalmente, caótico (que ainda existe) levaram os bancos locais a desenvolverem seus próprios sistemas, gerando assim, um profissional extremamente capacitado na área de negócios financeiros.

Dentro do contexto sistêmico bancário, outras informações merecem ser destacadas: O Brasil é o único país do mundo que possui 5 bancos de capital nacional na liderança no mercado interno. Temos a maior plataforma Mainframe instalada no mundo (nota: as grandes operações bancárias nos Estados Unidos ainda continuam utilizando esta plataforma). O Brasil possui milhares de “Coboleiros” com uma vasta experiência, não só na linguagem, mas também no ambiente financeiro. O número de sofisticação e funcionalidades do Internet Banking brasileiro é a maior do mundo. Proporcionalmente, cerca de 40% da população brasileira utiliza Internet Banking, nenhum país possui este número. O sistema de cartão de crédito brasileiro é sólido e dinâmico (tal sistema já existe a 50 anos). Cerca de 40% da população brasileira utilizou cartão de crédito em 2006 e mais de 1 milhão de estabelecimentos aceitam este tipo de cartão. Temos o maior número de ATMs por contas, só para ter uma idéia 10% dos ATMs instalados no mundo estão no Brasil. A BOVESPA possui o maior patrimônio líquido do mundo. O Sistema de Pagamento Brasileiro compensa em menos que 48 horas qualquer cheque emitido no país, somos campões neste quesito.

Outro ponto de destaque é o fuso-horário brasileiro, estamos a 4 horas da Comunidade Européia e de 1 (uma) a 3 horas dos Estados Unidos.

O Brasil possui: uma cultura “ocidentalizada” semelhante à européia e a americana; uma excelente infra-estrutura de comunicação em fibra-ótica, a ligação de várias das grandes cidades é exemplo disso.

Não temos desastres naturais e terrorismo, uma diversidade étnica domina a genética da população brasileira, o país é pacífico por natureza (não temos disputas com nossos vizinhos na América do Sul).

Enfim, não basta somente apresentar ao mundo todas as potencialidades descritas aqui, é necessário que o governo diminua a carga tributária, não podemos pagar cerca de 40% do que arrecadamos para sustento do próprio governo. As empresas, também devem fazer sua parte, se conscientizar que é somente com a qualidade no processo e no produto que poderão atingir mercados internacionais. As universidades e faculdades de tecnologias, também, devem formar profissionais de qualidade para setor produtivo de software.

Prof. Dr. José Augusto Fabri

Fundação Educacional do Município de Assis

Faculdade de Tecnologia de Ourinhos 

fabri@femanet.com.br 

 

Fontes de consulta:

Brasilian Association of Information Technology and Communication Companies – www.brasscom.com.br

Ministério de Ciência e Tecnologia, Secretária de Política em Informática – www.mct.gov.br/sepin

Ministério do Desenvolvimento, Indústria e Comércio Exterior http://desenvolvimento.gov.br/portalmdic/sitio/interna/interna.php?area=5&menu=1161