Falha de segurança em sistemas

Pizza, pizza...

A empresa  Domino’s Pizza, talvez a mais antiga dos EUA, com valor de mercado de  US$1.4 bilhões e 8700 pontos de venda no mundo todo, foi surpreendida recentemente por uma “promoção” em que foram distribuidas 11000 pizzas médias  gratuitamente, em Cincinatti (Ohio) e região. A origem do problema: um cupom de oferta online, de uma promoção que deveria ter ido ao ar em Dezembro de 2008, mas que não havia sido aprovada e estava na “fila de espera” para ser lançada.

O cupom da promoção que não foi lançada certamente continuou no diretório do website da empresa, só que não estava visível. Algum garoto mais esperto descobriu que se digitasse a palavra “bailout”  na janela de entrada de pedidos (esta palavra ficou muito em moda recentemente, com o socorro de bilhões de dólares que o governo estadunidense prestou ao seu  sistema financeiro) , o cupom aparecia no site e podia ser usado para ganhar pizzas gratuitamente. Dai para a noticia se espalhar pela região foi questão de um piscar de olhos e antes que o pessoal de TI da Domino’s pudesse perceber, o estrago já estava feito. Segundo a notícia, somente uma rede de 14  lojas na região de Cincinatti entregou 600 pizzas em um período curto, por conta desse cupom. Vejam aqui a notícia publicada  no sitio The Risk Factor, da IEEE Spectrum Online.

O que interessa aqui, do ponto de vista desta postagem, é a questão do preparo técnico dos profissionais da área, para lidar com a questão do risco e sua materialização. Os erros são inconcebivelmente infantis e conhecidos, inaceitáveis para quem tem alguma formação na área e procura pelo menos se manter informado. O caso acima, por exemplo, pode ter sido causado pelo descuido comum que é o de usar o mesmo local (diretório)  no servidor para desenvolvimento e publicação de sitios. Ou seja, fica tudo no mesmo lugar, sujeito a erros de todo tipo, inclusive o de publicar uma versão mais antiga do sitio, se não houver um controle de versões muito bem feito. Outro descuido muito comum e manjado demais é o de não usar um filtro eficiente para consultas SQL, que podem facilmente ser injetadas (SQL Injection) em uma janela de busca que fica disponivel nos sitios, e através da qual é possivel até apagar todo um BD usando o comando delete da SQL. Imaginem isso acontecendo em um sitio de um banco, apagando toda a tabela de senhas e login, etc.

Com uma frequência acima do que seria razoável, noticias como essa ai aparecem rodando na web. O sitio The Risk Factor, apontado acima, tem o objetivo de mostrar os riscos e a sua materialização, relacionados ao uso da TI. Outro sitio muito bom sobre os riscos, é o do pesquisador Peter Neumann, ele tem uma parte do sitio denominada RISKS, onde ficam relatados os principais riscos e problemas já acontecidos pelo uso da TI. Espero contribuições dos leitores sobre outros casos conhecidos, mandem ai…

(este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com)

The object primer

Object primer

Finalmente, terminei mais uma maratona de leituras das férias, a última é esse livro ai, The object primer, do Scott Ambler, na fila desde o final de 2006 (meu tempo para leituras é cada vez mais escasso). É um livro muito bem recomendado por quem está no mercado, enfrentando a modelagem e implementação de software na prática. Na academia, vejo raras referências a ele, talvez por ser um livro muito voltado para a prática, para o dia a dia e para o como-fazer. Que, afinal, é o que interessa para quem vai para o mercado, não é isso? O autor, Scott Ambler, é um dos precursores dos métodos ágeis, mantém vários sitios na web, dentre os quais recomendo a referência principal, o AmbySoft. O Ambler é autor de outros livros conhecidos, um deles traduzido para o português, Modelagem Ágil, também muito bom. O que vejo de muito positivo nas idéias do Scott Ambler, é que ele não é um agilista xiita, que acha que métodos ágeis resolvem tudo e estamos conversados, o resto é passado. Pelo contrário, em todos os seus escritos, ele tem o cuidado de deixar claros os limites dos métodos ágeis, mostrando os possiveis caminhos de adoção. Em momento algum, ele despreza o conhecimento acumulado no desenvolvimento de software com base em processos organizados e controlados, que continuam sendo muito mal entendidos pela maioria dos programadores e projetistas.

O livro é muito bom, e muito bem escrito. Como já disse, muito voltado para a prática, para o dia-a-dia, com base na experiência do Scott Ambler, que não é pouca. Não seria possivel numa postagem curtinha, falar do livro todo. Os capítulos que mais me agradaram foram: 5-Usage modeling, 6-User-interface development, 8-Conceptual domain modeling, 10-Agile architecture, 12-Structural design modeling, 13-Object oriented programming e 14-Agile database development.

O capítulo 10, em particular, é muito interessante, pois aborda um tópico completamente obscuro para a maioria dos programadores e projetistas: afinal, o que é a arquitetura do software? Considero este conceito o mais mal entendido de projeto de software, vai ser objeto de uma postagem exclusiva aqui, em breve. O capítulo 12 aborda extensivamente a construção de diagramas de classes do ponto de vista da engenharia de software, que é o objetivo final de todo projeto orientado a objetos. Este capítulo é complementar ao 8, minha dica é ler os dois em sequência, 8 e 12.

Se me perguntarem quais os capitulos devem ser lidos, recomendo ler todos. Mas, se você for obrigado a eliminar alguns e se concentrar na essência do livro, recomendo esses relacionados acima. O livro é um bom investimento em conhecimento, e está até barato no mercado de livros usados da Amazon. Bom proveito!

(este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com)

Engenharia de software na sala de aula (1)

   

 

 

 

Desafios...

Um dos desafios que enfrento todos os anos, e cada ano inteiro, é o de decidir o que ensinar em Engenharia de Software na graduação. Vejo um crescimento muito grande da área, as ramificações de assuntos estão aumentando, as implicações de um assunto no outro aumentam na mesma proporção. Além do enorme desafio da atualização na área, que merece uma postagem exclusiva, nós professores temos a sala de aula para enfrentar o ano inteiro, e os alunos estão lá confiantes de que vão sair das nossas disciplinas com algum conhecimento.

Normalmente os cursos oferecem duas disciplinas de 60 horas com algumas variações (algumas são de 75 ou 90 horas), e esse tempo não é suficiente para fazer os alunos botarem a mão na massa prá valer. E a quantidade de tópicos e assuntos é muito grande, e nós professores temos esse desafio: como organizar essas disciplinas, de forma tal que o aluno saia delas com conhecimento de fundamentos e com alguma prática? Eu tento uma mudança todos os anos, melhoro tópicos, mudo a forma de aplicar o projeto, os resultados não mudam muito.

Pensando na estrutura formal da área e dos conteúdos das disciplinas, temos o SWEBOK – Software Engineering Body of Knowledge,  um documento de valor inestimável para organizar as idéias, buscar conteúdos, referências bibliográficas. Esse guia, associado com o PMBOK – Project Management Body of Knowledge (esse para o caso de gerência de projetos), é  indispensável para todo professor da área, é obrigatório ter os dois volumes e conhecer seu conteúdo. A ACM-Association for Computing Machinery mantém atualizado um sitio na web com propostas organizadas de curriculo na área, vejam aqui o documento atualizado, 2006. A SBC-Sociedade Brasileira de Computação, também mantém as propostas de diretrizes curriculares, mas a base é essa mesma que já citei. Mas esse material ai ajuda na parte formal, estrutural, de conteúdos e sequenciamento. O desafio continua, afinal o que é que deve ir para a sala de aula? e como deve ir?

Continuando na minha linha de basear minhas disciplinas em processos (em outra postagem vou comentar sobre isso), tive uma experiência interessante  no segundo semestre de 2008, na Engenharia de Software II: adotei o livro do prof. Raul Wazlawick “Análise e projeto de sistemas de informação orientados a objetos” como manual de projeto, dividi o projeto em quatro partes, cada parte associada com um grupo de capitulos do livro, cobrindo o livro todo de cabo a rabo. O projeto foi relativamente simples e pequeno, assunto dentro da cultura dos alunos:  Agenda remota para telefones celulares (algumas operadoras já oferecem esse serviço) , e deixei os alunos darem asas à imaginação. 

Na terceira fase do projeto, cada grupo preparou um protótipo para testar o projeto e corrigir eventuais falhas, e foi muito bom, organizei uma pequena competição com os próprios alunos avaliando o trabalho dos colegas. Como era esperado, o protótipo forçou os grupos a revisarem os requisitos e suas especificações, levando a uma revisão do artefato de especificação de requisitos.  Paralelamente, eu andei com as aulas teóricas cobrindo os tópicos relativos a cada parte do projeto, no mesmo ritmo do próprio projeto, dentro da filosofia de Eng. Software baseada em Processos. Tentei seguir um modelo de condução da disciplina baseado em PBL-Project Based Learning, e gostei muito da experiência. Espero contribuições dos leitores desse blog, outras postagens sobre o assunto estão na fila esperando a oportunidade de pipocarem.

(este artigo foi escrito  por zeluisbraga, e postado no meu blog  zeluisbraga . wordpress . com) (this post was originally written by zeluisbraga, published on my blog  zeluisbraga . wordpress . com)

Inovação, trabalho em equipe e o processo de software

Watts Humphrey

Vou acumulando referências a livros  durante o ano, alguns eu compro, outros ficam na fila. Para ler quando der tempo, o que acontece normalmente nas férias. Só que a pilha fica meio alta, e dá até agonia ver tanto livro bom esperando para ser lido.

Esse livro ai, Managing technical people: innovation, teamwork and the software process, escrito pelo Watts S. Humphrey, eu acabo de ler. Para quem não conhece o autor, é nada mais nada menos que o grande mentor da criação do SEI-Software Engineering Institute, autor de vários livros ótimos em Eng. Software, e responsável pela criação, teste e disseminação dos processos PSP-Personal Software Process, TSP-Team Software Process e o conhecidissmo CMMi-Capability Maturity Model integrated. As referências e material sobre esses processos, a relação entre eles, o nível de adoção, white papers, processo de avaliação, etc., estão disponíveis nos sítios do SEI indicados acima.

Bom, peguei a referência a esse livro não sei mais onde, foi em algum bom blog de que assino o RSS. O livro é antigo, de 1997, ficou meio esquecido e não fez tanto sucesso editorial quanto os outros livros dele. Achei um livraço, merece ser lido pelo menos em parte. Apesar de não ter nenhuma novidade do ponto de vista de gerência de equipes para a área de Administração, a abordagem dele é dirigida para a área de TI, e ele conta toda a sua experiência no gerenciamento de equipes (inovadoras) de pessoal técnico (engenheiros, analistas, pesquisadores). Experiência que não é pouca, adquirida nos seus muitos anos de IBM, onde se aposentou. Lendo esse livro, dá para ter uma visão excelente do assunto, que só poderia ser adquirida lendo vários livros de Administração. E mesmo assim, ainda teriamos que selecionar o que ler, pois tem meia tonelada de livros sobre esse assunto.

Se você tem interesse na gerência de projetos, então esse é um livro obrigatório. Está fora de catálogo, só é possivel comprar no mercado de usados. Comprei o meu na Amazon, por US$1.66 mais US$15 de porte, não chegou a R$30,00, uma merreca para um livro desse calibre e pelo tanto que pude aprender com a sua leitura.

(este artigo foi escrito  por zeluisbraga, e postado no meu blog  zeluisbraga . wordpress . com) (this post was originally written by zeluisbraga, published on my blog  zeluisbraga . wordpress . com)

Boas práticas no desenvolvimento de software

Uma interrogação que me acompanha sempre é: como é que vamos capacitar as micro-empresas de desenvolvimento de software para se tornarem competitivas em termos de qualidade e poderem atuar em mercados globais? Os modelos de competência organizacional que tomam a norma ISO15504 como base, como o CMMI e o mpsBR, aplicam-se a pequenas, médias e grandes empresas, com no mínimo 30 funcionários e com um portfólio de sistemas e serviços mais abrangente. As micro-empresas ficam longe desse mundo, embora sejam submetidas a desafios semelhantes. Por exemplo, uma empresa incubada em alguma incubadora de empresas de base tecnológica, normalmente tem de três a cinco funcionários que se dedicam a desenvolver, comercializar e a manter apenas um tipo de software ou projeto (sem contar a parte administrativa da empresa…). Como é que uma empresa com esse perfil vai conseguir alcançar os níveis de qualidade exigidos pelo mercado?

Na última prova da disciplina Engenharia de Software II do Bacharelado em Ciência da Computação da UFV, segundo semestre de 2008, propus uma questão para fazer os alunos pensarem melhor nessa realidade:

2- Melhores práticas. Considere as seis melhores práticas para desenvolvimento de projetos de software adotadas na indústria, cuja adoção é muito facilitada quando se adota o RUP como modelo de processo: 1- Desenvolva software iterativamente; 2-Gerencie requisitos; 3-Utilize arquiteturas baseadas em componentes; 4-Utilize modelagem visual; 5-Verifique qualidade continuamente; 6-Mantenha alterações sob controle. (nota: descritas no primeiro capítulo do livro The Rational Unified Process: an introduction, do Phillippe Kruchten)

a-Uma pequena empresa de desenvolvimento de software, com até 10 profissionais com formação variada, assim distribuidos: 5 ainda são estudantes do sexto período de Computação na UFV; 3 são experientes, com mais de cinco anos de trabalho na empresa, graduados em computação; 2 se dedicam integralmente a atividades administrativas na empresa. Essa empresa, como qualquer outra, gostaria muito de ficar mais competitiva no mercado, iniciando um processo de mudança que permita uma melhoria na qualidade dos produtos que ela desenvolve. Indique, justificando e comentando, uma ordem de adoção das seis melhores práticas acima, que leve aos melhores resultados finais. b-Mostre, utilizando um gráfico de Curva de Aprendizagem, como a sua sequência sugerida na questão (a) permite uma curva de aprendizagem com um “vale do desespero” mais raso, proporcionando melhores resultados no médio prazo. Desenhe essa curva, e anote sobre ela os pontos em que a adoção de cada prática sugerida em (a) deve ocorrer. Justifique sempre.

Para encurtar a postagem, o resultado que deixaria qualquer professor satisfeitissimo, está na planilha abaixo. A turma tem 38 alunos, a linha de topo indica a ordem de adoção, e o número em cada célula indica o total de “votos”. É possivel que eu tenha perdido algum voto, tive que catar todos eles no texto de cada resposta, o que não alteraria muito o resultado.

PRÁTICAS	1	2	3	4	5	6
Des. Iterativo	2	3	13	7	8	4
Ger. Reqs.	15	16	3	2	1	0
Componente	1	1	8	8	6	13
Ling. Visual	16	14	1	2	1	2
Ver. Qualid.	3	1	6	8	9	11
Ger. Altera.	0	2	6	10	12	6

A ordem sugerida pelos alunos foi (número de votos em negrito): adoção de linguagem visual; gerenciar requisitos; desenvolvimento em ciclos iterativos; verificação contínua da qualidade; gerenciar e controlar alterações; desenvolvimento com componentes. Houve empate no primeiro e segundo lugares, perfeitamente explicável. Se a

Curva de aprendizagem - Gilberto V. Nunes

empresa já tem alguma maturidade e já usa uma linguagem visual tipo UML-Unified Modeling Language, já pode iniciar sua capacitação adotando práticas relacionadas com a gerência de requisitos. Que é uma das práticas de base para o nível G do modelo mpsBR, ou seja, altamente saudável que as empresas a adotem. Outro ponto muito interessante da planilha foi que, por exemplo, gerenciamento de alterações e desenvolvimento com componentes não seriam recomendadas em primeiro lugar, e que gerência de requisitos nunca seria a última prática a ser adotada, reparem que estão com zero votos nas duas colocações citadas. A curva de aprendizagem teria uma cara parecida com a que está ai acima, a cada nova prática adotada haveria uma queda na produtividade ou competência por um período cada vez menor, na medida em que se avance no processo de adoção. O desenho anterior tinha sido feito por mim a mouse livre no Paint, está claro que essa não é uma das minhas melhores habilidades, esse aí foi enviado por um aluno que elogiou demais o desenho anterior…

O resultado mostra que os alunos têm maturidade para encarar desafios no mundo real, e que saberiam usar o conhecimento adquirido na sala de aula em situações reais. Claro, falta a vivência do mercado, mas isso vem com o tempo. O que esse pequeno exemplo mostra é que é perfeitamente possivel colocar bons princípios na cabeça dos nossos jovens. Parabéns, turma!

O juramento do Engenheiro de Software

Florence Nightingale Pledge

É mais que sabido, repetido e divulgado, que o software faz parte da vida moderna. Conscientemente ou não, todo mundo interage com algum dispositivo que é controlado por software, no mínimo no telefone celular que boa parte da população possui. Com essa explosão nas aplicações e nas oportunidades do setor de produção de software, volta sempre à tona o assunto ética em computação. Que resulte em um código de conduta que possa ser tomado como guia para os produtores de software, contendo princípios morais que balizem as relações dos engenheiros de software com o seu trabalho e com a sociedade onde o produto do seu trabalho vai ser utilizado.

Esse é um tema mais que atual nas disciplinas de engenharia de software, que veio chegando devagar e hoje ocupa os primeiros capítulos dos bons livros da área. Como, por exemplo, na oitava edição do livro Engenharia de Software do Ian Sommerville, o tema veio para o primeiro capítulo. Nos livros de Sistemas de Informação que adoto, da dupla Kenneth Laudon e Jane Laudon, sempre tem um capítulo específico sobre ética e impactos sociais, que é obrigatório para complementar a formação dos alunos. O grande desafio é: como fazer para disseminar um código de conduta entre nossos alunos, de forma tal que façam parte do seu cotidiano como profissionais da engenharia de software?

Depois que descobri o Juramento do Engenheiro de Software, que fiz questão de traduzir e de levar para a sala de aula e evidentemente cobrar como assunto de prova, acho que o desafio ficou mais fácil de encarar. Um texto curto e grosso, que com poucas palavras traduz o que deveria ser um princípio de código de conduta. Fácil de lembrar, fácil de entender, simples para ser discutido na sala de aula, e para  ser utilizado na análise de casos sobre o tema. Que poderia significar para os engenheiros de software o mesmo que As três leis da robótica significam para os robôs. Reflitam…

JURAMENTO DO ENGENHEIRO DE SOFTWARE

Juro solenemente não causar dano ao software sob minha responsabilidade, não adotar propositalmente nenhuma prática danosa, e não utilizar nenhuma técnica, método ou ferramenta que eu não entenda em sua plenitude. Fervorosamente, prometo não me dedicar a práticas deletérias ou maléficas. Farei tudo ao meu alcance para expandir meu conhecimento e habilidades, e lutarei para manter e ajudar a elevar os padrões éticos da minha profissão. Com lealdade me empenharei para ajudar os clientes e usuários atingirem seus objetivos, manterei bem guardada toda e qualquer informação que chegar ao meu conhecimento na prática profissional, e me empenharei profundamente para que os projetos sob meus cuidados sejam desenvolvidos com ética e profissionalismo. (adaptado por Phillip A. Laplante, a partir do Juramento Profissional dos Enfermeiros, autoria atribuida a Florence Nightingale, publicado na revista ACM Queue de Junho de 2004)

Desenvolvimento ágil: casos de sucesso

A questão sobre os Métodos Ágeis continua, e começam a surgir dados confiáveis sobre casos de sucesso e relatos de experiências que podem ser reaproveitados em projetos semelhantes. Uma notícia recente me chamou a atenção (texto completo aqui), vou comentar a seguir.

EUREKA é uma rede inter-governamental européia criada em 1985, destinada a aumentar a competitividade  dos países da união européia em inovação, pesquisa e desenvolvimento, apoiado por centros de pesquisa e universidades. Uma das iniciativas dentro dessa rede é o projeto AGILE-ITEA,  dentro do ITEA – Information Tecnology for European Advancement.  AGILE nesse caso significa Agile Software Development of Embedded Systems, um projeto destinado a investigar a utilização de métodos ou princípios ágeis no desenvolvimento de software embarcado.

Boeing787 - Cabine de controle

Software embarcado é considerada a área de aplicação que mais se desenvolve no mundo, quase tudo hoje envolve uso de software: máquinas fotográficas, forno de micro-ondas, telefone celular,  relógios, controle de veiculos, etc. Os desafios são muitos, pois trata-se de desenvolver software para processadores com capacidade restrita de processamento, com baixo consumo de energia e conjunto restrito de instruções, projetados para uso específico. As técnicas tradicionais de engenharia de software certamente se aplicam, mas sujeitas às restrições naturais desse tipo de software, obrigando focar mais em código com o mínimo de linhas e muito eficiente. A principal restrição competitiva é o famoso time-to-market, que coloca muita pressão de tempo para que o software fique pronto, testado, instalado e rodando no processador alvo. Na indústria automobilistica, por exemplo, o investimento em produção de software embarcado é altissimo, pois os nichos de inovação são restritos e o controle de funções dos veículos via software é um caminho muito promissor. Ganha a competição quem chegar mais rápido ao mercado.

Os resultados animadores do AGILE-ITEA, medidos em 68 estudos de caso em vários tipos de indústria, mostram que técnicas ágeis podem ser usadas no desenvolvimento de software embarcado com ganhos de tempo e com custos mais baixos do que usando as técnicas tradicionais, sem abrir mão da qualidade. Essa economia de tempo tem um impacto positivo ao permitir atender à demanda crescente das indústrias com a mão de obra já disponível, tirando a pressão por formação de mais mão de obra. Comprovadamente, o uso de software embarcado  em dispositivos eletrônicos cresce muito mais rápido do que os avanços da própria eletrônica, e a produção do software necessário não acompanha essa evolução. O que não é grande novidade, as inovações em desenvolvimento de software estão sempre muito atrás do desenvolvimento do hardware e das necessidades das novas aplicações.

Esses resultados são animadores, um avanço real para as estatísticas de uso de métodos ágeis, pois ajudam a enxergar melhor uma classe de aplicações onde eles podem ser usados com vantagem sobre os métodos tradicionais baseados em planejamento.

Engenheiro de software: mais exigências de mercado

Mal começa o segundo semestre de cada ano, e as previsões sobre as novas exigências para as carreiras em TI começam a pipocar aqui e ali. Gerente de projetos, engenheiro de software englobando arquiteto de software, projetista e programador, estão sob constante pressão de evolução do conhecimento, pois o avanço tecnológico vem em alta velocidade, e temos que acompanhar. Já não é mais suficiente conhecer bem os fundamentos de  processos, UML, RUP, métodos ágeis, técnicas de teste de software, refatoração, padrões de análise e de projeto, linguagens…

O blog ReadWriteWeb trouxe o artigo Top 10 concepts that every software engineer should know (obrigado pela dica, João Gazolla). Vou comentar parte dele aqui, mas aconselho a leitura do artigo, que aponta para tendências que vão se transformar em exigências em pouco tempo: Interfaces, pois o usuário final é o objetivo dos sistemas, e com o avanço da convergência digital e ubiquidade, temos hoje uma base de usuários crescendo rapidamente, com necessidades e exigências específicas. Em termos de pesquisa, já estamos assistindo ao aparecimento das interfaces adaptativas, o que há 5 anos era apenas uma possibilidade;  Cloud computing, um novo conceito em utilização de recursos de TI incluindo a plataforma de software e desenvolvimento, tarifado pelo uso. Esse conceito já tem hoje impacto nas decisões sobre a hospedagem e o desenvolvimento de software, permitindo aos pequenos terem acesso barato a recursos antes caros e sofisticados, na medida certa da sua necessidade e disponibilidade financeira, competindo com os grandes na mesma raia. Foi lançado há algum tempo pela Amazon e já foi comentado aqui no blog na postagem Amazon.com e a inovação.

Os outros oito conceitos fazem parte dos fundamentos de qualquer bom curso superior de computação, e já não são tanta novidade assim. Exceto pelo fato de que o mercado puxou esses conceitos para a linha de frente, e hoje não basta ter feito uma disciplina na graduação, o conceito vai ser exigido na prática. Como por exemplo os conhecimentos em Bancos de Dados, necessários para decidir onde e como implementar a persistência dos sistemas; os conhecimentos em Complexidade de Algoritmos, o terror da turma nas disciplinas Projeto e Análise de Algoritmos, necessários para projeto ou escolha de algoritmos adequados a novas situações, evitando gargalos de execução quando o sistema é entregue. Que é um problema mais comum do que se imagina, os gargalos aparecem por conta da escolha de um algoritmo inadequado, erros de implementação, etc. Um conhecimento que não está listado no artigo, mas que hoje é obrigatório, é na área de Redes, já que a maioria dos sistemas são desenvolvidos para a web, o que envolve conceitos de concorrência, distribuição e outros nas decisões sobre implementação e distribuição. Isso sem contar que o desenvolvimento distribuido de software está em alta, impondo novos desafios.

Bom, olho vivo… essas considerações têm desdobramentos tanto na profissão quanto nos curriculos, que embora não tenham que acompanhar modismos, devem se adequar de tempos em tempos. E mais uma dica: a maioria dos alunos passa pelos cursos de graduação com baixo nível de interesse pelas disciplinas, muita displicência e pouco comprometimento em sala de aula e nos trabalhos práticos, mais interessados talvez em coisas mais amenas como namoros, festas, etc. Tudo tem seu tempo e deve ser dosado adequadamente. O preço a pagar por não aproveitar as oportunidades no momento certo é muito alto, o mercado vai cobrar, e o filtro para o sucesso na carreira está cada vez mais apertado.

E o usuário final, como é que fica no processo?

Venho acompanhando o desenrolar do problema com o rebatimento do banco traseiro do Fox, carro da Volkswagen de lançamento recente,  totalmente desenhado na filial brasileira e exportado daqui para o resto do mundo. As notícias de dedos decepados ou prensados no momento de voltar com o banco para a posição normal são várias, e até o momento, o problema foi resolvido apenas de maneira paliativa. O problema já é de conhecimento público, e estima-se que as vendas do Fox cairam de terceiro para quinto lugar entre o primeiro trimestre de 2007 e o primeiro trimestre de 2008, em parte devido ao impacto negativo do problema na confiança do consumidor.

Lendo uma reportagem na revista Exame de 7 de Maio de 2008, “O grande erro da Volks”, que recomendo aos leitores, é que um outro problema me saltou aos olhos: Desde o primeiro acidente registrado em 2004, a direção da Volkswagen sempre insistiu que o problema é das vítimas, que não haviam acionado o sistema corretamente. Posição esta confirmada pelo presidente da empresa em entrevista em cadeia nacional, em que ele afirma que basta seguir as instruções contidas no manual do proprietário para fazer a operação correta. Ainda segundo a reportagem, uma solução definitiva envolveria um grande esforço de reprojeto e retrabalho e seria inviável tanto do ponto de vista técnico quanto do ponto de vista econômico, pois afetaria a estrutura do carro.

Para a Volkswagen, reconhecer a falha significa reconhecer limitações no projeto do carro, já que o desenho do sistema de rebatimento do banco traseiro foi responsabilidade do setor de engenharia da Volks, e esse reconhecimento de falha seria um tranco na cultura da empresa. A área de engenharia ainda hoje não admite que o carro tem problemas. Para um engenheiro acostumado a desenhar e fabricar carros, o Fox realmente não tem problemas, o sistema funciona e o manual é claro a respeito da forma como operá-lo. O problema é que o consumidor não acha isso, e é ele quem compra e usa o carro.

Bom, mas e daí? que lições podemos tirar dessa questão? que relação ele tem com a Engenharia de Software? Não está parecendo que esse filme é exibido regularmente na nossa área? Requisitos, sempre os requisitos. Requisitos implementados errados, requisitos extraidos errados, requisitos especificados errados, requisitos não testados e não aferidos pelo controle de qualidade, requisitos não validados no mundo real… tudo remete ao usuário final, que segundo os métodos mais modernos e as tendências atuais, deve de alguma forma sempre fazer parte do processo desde o seu início. Desde que o ciclo de desenvolvimento em cascata caiu em desgraça (na minha opinião injustamente), e o desenvolvimento iterativo passou a ser a palavra de ordem no desenvolvimento de software, o usuário final passou a ocupar lugar de destaque. Hoje, tanto um processo RUP-like quanto um método ágil recomendam que o usuário faça parte permanente da equipe, com alta disponibilidade para o projeto.

A reportagem da revista Exame deve ser lida, representa uma lição muito interessante que não se encontra nos livros, daria até para transformar em um caso para usar em disciplinas de engenharia de software e engenharia de produção. A reportagem serve também para deixar claro que nas áreas tradicionais de engenharia, onde os processos são formalizados e seguidos à risca, falhas ocorrem e fogem ao controle dos gerentes de projeto, e o usuário final às vezes fica de fora do processo.

Pessoas ou processos?

O artigo citado no final da postagem me chamou a atenção, principalmente por ter sido escrito por Robert L. Glass, autor do livro Facts and fallacies of software engineering, de que gosto muito e uso em minhas disciplinas de engenharia de software. Há um tema que já se arrasta há algum tempo e que parece ainda estar longe de uma conclusão, sobre se a questão principal na gerência de projetos (de software) são os processos utilizados como modelo de desenvolvimento, são as pessoas envolvidas e que tocam os processos adiante, ou ambos? E o Robert Glass foi achar em um livro do Watts Humphrey, que é o grande mentor do SEI-Software Engineering Institute, uma discussão exatamente sobre esse tema. O livro, Managing for innovation, foi publicado pela primeira vez em 1987, e ficou meio esquecido talvez porque o tema não chamava tanta atenção assim na comunidade de engenharia de software da época, que estava mais preocupada com outros problemas. O livro foi republicado em 1997, com o título Managing technical people, e também parece que não teve muito impacto na comunidade.

A idéia de ambos os livros é a de que pessoas fazem a diferença no desenvolvimento de software e sistemas, e o autor explora a questão do ponto de vista da importância da criatividade e inovação e sua relação no desenvolvimento de projetos. Criatividade é a nossa capacidade de pensar em coisas novas, e inovação é nossa capacidade de realizar coisas novas. Nas palavras do próprio Humphrey, “While innovation requires creativity, it also involves a great deal of hard work” (inovação pressupõe criatividade, mas inovação envolve muito trabalho duro).

Uma relação interessante, já discutida em outros livros de administração, é a de que quando os gerentes controlam muito fortemente as atividades das pessoas nos projetos, o poder criativo da equipe cai muito, ao passo que um estilo gerencial mais livre e mais baseado na responsabilidade e compromisso das pessoas envolvidas, habilitam o aumento da criatividade. Uma outra relação interessante foi estabelecida com o grau de experiência administrativa, habilidade em gerenciar pessoas e conhecimento tecnológico do administrador de projetos e seu grau de envolvimento nos projetos. Nos projetos mais inovadores, os gerentes se envolveram pessoalmente no desenvolvimento do projeto e mantiveram contato permanente com o pessoal de desenvolvimento.

Uma primeira conclusão é que o maior nível de inovação em projetos acontece quando (a) o gerente tem muito conhecimento técnico e se envolve pessoalmente no desenvolvimento e (b) quando se aumenta a liberdade do pessoal técnico. Também não resta dúvida de que a base da inovação nos projetos está mais relacionada com os usuários finais e seu conhecimento sobre o que está sendo desenvolvido, do que com o pessoal de computação que se dedica mais à tecnologia e desenvolvimento: 75% de toda a inovação é impulsionada por forças de mercado. Ou seja, as necessidades do usuário é que determinam se uma inovação vai ter sucesso ou não, e não a tecnologia aplicada no seu desenvolvimento. Portanto, temos ai um conclusão muito interessante: as pessoas são tão importantes quanto os processos e as tecnologias, e as técnicas de gerenciamento de projetos devem levar esse fato em consideração para terem sucesso.

Managing for innovation, autor Rober L. Glass, coluna Practical Programmer, CACM March 2008, páginas 17-18