Blog no twitter

Acompanhe o blog engenhariasoftware no twitter, acesse:
http://twitter.com/engsw

abraços

J. A.

Que PAÍS queremos construir?

Caros Colegas

Acabei de receber um convite, no mínimo, inusitado. A referida “universidade” está prestes a passar por uma reavaliação do MEC e procura por professores doutores para “engrossar o caldo” de seu pobre corpo docente.

Por questões éticas, não divulgarei o nome da universidade, da cidade e do coordenador do curso.

Acredito que a comunidade deve ficar atenta no momento de escolher ou indicar cursos destas “universidades de beira de estrada”.

Segue o e-mail convite (atente-se para a questão ortográfica).

“Bom dia José, meu nome é xxxx sou o coordenador da computação da xxxx do campus de xxxxx, estou contatando você por indicação do professor yyy e do professor yyyy, José estou contratando um Dr. para esse primeiro momento  formular duas questoes mês no estilo ENADE em uma disciplina de vossa escolha, sem necessitar estar presente no campus, ganhando 1hora aula semana para tal atividade, (algo entorno de R$140,00 reais mês)se voce se enteressar favor retorne o contato o quanto antes”.

Acho que o trecho extraído da música de Renato Russo resume a situação que chegamos (http://letras.terra.com.br/legiao-urbana/46973/). Os grifos são de minha autoria.

Nas favelas, no senado (inclusive na universidade)

Sujeira pra todo lado

Ninguém respeita a constituição (muito menos a ética)

Mas todos acreditam no futuro da nação (Será?)

Que país é esse?

…

Mas o Brasil vai ficar rico (Quem é o Brasil?)

Vamos faturar um milhão (Quem? Eu? Você? O dono a universidade em questão?)

Quando vendermos todas as almas (Olha que estamos quase lá. Tem muito gente vendida em todas as esferas)

Dos nossos índios num leilão

Que país é esse?

…

J. A.

fabri@femanet.com.br

A relação entre conhecimento e gerência: Uma visão peculiar

É uma boa pedida para analisarmos nossa postura no mercado de trabalho. É uma verdadeira aula sobre o valor do trabalho em sua vida.

 

Ensinamos corretamente a engenharia de software?

A questão acima foi delineada por um interlocutor deste blog que trabalha em uma empresa do setor produtivo de software. Dentro da referida empresa ele é responsável por recrutar programadores e testadores.

Bem, confesso que não respondi a questão no momento que ela foi elaborada. Aproveito a oportunidade para afirmar que tenho várias dúvidas sobre organização curricular das disciplinas da área de engenharia de software. A questão que intitula este post me levou a delinear algumas reflexões.

A ordem que as disciplinas são apresentadas está correta?

A grande maioria dos cursos de computação e informática apresenta, em um primeiro momento, aos seus alunos as disciplinas introdutórias da área de programação. Posteriormente são tratados os conteúdos referentes às estruturas de dados. Aspectos relacionados ao levantamento de requisitos, e modelagem sistêmica ocupam terceiro lugar nesta ordem. As informações inerentes ao projeto de software são configuradas como o quarto item. Saliento que alguns cursos possuem algumas disciplinas que apóiam o desenvolvimento do projeto, geralmente estas apresentam IDEs e linguagens de programação aos alunos, possibilitando-lhes a própria “materialização” do software. Os aspectos ligados a teste de software, em quase 100% dos cursos, são tocados (quando são) de forma superficial.

Será que não seria mais interessante organizar o currículo da área de engenharia de software a partir da seguinte equação?

Engenharia de Software = {analise de sistemas + [projeto de software + (programação + teste) + implantação+manutenção]} + processo e gestão de projetos de software

Na equação, primeiramente, resolvemos os parênteses, ou seja, as disciplinas de lógica, algoritmo e estrutura de dados seriam apresentadas nos semestres iniciais. Posteriormente proponho que os aspectos formais ligados a testes sejam discutidos na disciplina de Engenharia de Software I. Em Engenharia de Software II seriam apresentados os conceitos relacionados a projeto de software. O corpo de conhecimento ligado a implantação e manutenção do software seriam apresentados, concomitantemente, à disciplina de Engenharia de Software II. Por fim aspectos ligados a análise de sistemas, fator que requer um maior nível de abstração, seria visto no final, em Engenharia de Software III.

Ao ensinar algoritmo devemos apresentar uma linguagem de programação?

Trabalho com a disciplina de Algoritmos e Estrutura de Dados I, meu plano de ensino contempla o ensino da linguagem C (nota: nesta disciplina existem outros professores, não tenho pleno poder de decisão sobre o plano). É interessante ensinar C? Será que um compilador portugol não seria menos indigesto para os alunos? Como minimizar o número de reprovações nestas disciplinas? Fiz algumas experiências e materializei-as neste post.

Em que momento do curso devemos apresentar os conceitos ligados a orientação a objetos?

Alguns currículos apresentam a OO logo nas séries iniciais, outros inserem tais conceitos na metade. Qual é o melhor momento para apresentar estes conceitos? Sinceramente, não tenho uma posição definida sobre este assunto.

Qualidade de software é um tema importante?

Será que nosso aluno conhece os conceitos ligados a qualidade de software? Todos sabem o que é um processo produção de software? Aspectos ligados a qualidade do processo e do produto são delineados nos cursos de computação? Na maioria dos cursos, tenho a impressão que estes conteúdos são comentados superficialmente junto aos alunos.

A gestão de projetos é um conteúdo que deve ser ministrado por um professor da área de engenharia de software ou da área de administração?

Aspectos ligados a tempo e esforço para o desenvolvimento de um projeto deve ser apresentados aos alunos. Tenho certeza os conteúdos ligados a gestão de projetos são de extrema importância. Em alguns currículos, vejo que tais conteúdos estão ligados as disciplinas da à administração. Não seria interessante que um professor da área de engenharia internalizasse esse conteúdo junto aos alunos.

Acredito que a maior parte das reflexões delineadas é compartilhada por toda comunidade. A discussão está aberta, espero que todos a fomente.

J. A.

fabri@femanet.com.br

Gerente!!! Mate no ninho

A gestão em projetos é caracterizada pela aplicação de conhecimentos, habilidades e técnicas inerentes ao planejamento, execução e controle das atividades processuais que “materializam” um determinado produto ou serviço.

Faz parte da rotina de um gerente controlar qualidade, custo, prazo e o escopo de qualquer tipo projeto. O profissional que se propõe a gerenciar alguma coisa deve aglutinar as pessoas em torno de um único objetivo. Gerir expectativas  dos clientes, internos  e externos, garante a motivação necessária para a execução de qualquer projeto.

Lido com vários gerentes nos mais variados domínios de conhecimento. Alguns deles são do tipo “linha dura”, outros possibilitam aos seus comandados uma abertura maior e poucos possuem a coragem de “matar um problema no ninho”. Durante essa convivência compilei vários ensinamentos, compartilharei neste post 4 deles.

O gerente de projetos não irá agradá-lo sempre.

Em determinados momentos a pessoa responsável pelo planejamento e controle do projeto irá tomar uma atitude que não agradará a “gregos” e “troianos”. Para o gerente o mais importante é o sucesso na execução do processo, ou seja, produto ou serviço gerado deve satisfazer as expectativas ao cliente, possuir um custo baixo e alto índice de qualidade. Lembre-se, só existe equipe quando existe projeto. A partir desta afirmação questiono: Quem é mais importante, você ou projeto?

Não repasse TODOS os problemas a seus colaboradores

Cansei de ver gerentes praticarem a administração “au au”. Esse gerente repassa suas considerações e decisões para um indivíduo ou para uma comissão. Esse problema eu endereço à comissão X, esse outro problema eu endereço ao professor Y. Com base nas reflexões e direcionamentos de X e Y o gerente toma a sua decisão.  Geralmente a decisão tomada não difere dos apontamentos de X e Y. Decisões que dizem respeito, somente, ao gerente de projetos não devem ser encaminhadas a alguém.

Centralize energia no projeto

Seja focado, não desperdice tempo e recursos com algo que gere um baixo valor agregado para o projeto. Procure centralizar suas forças e atitudes em aspectos que promovam benefício para o cliente. Parece óbvio, mas essa característica não está presente em grande parte dos gerentes.

Não reinvente a roda, utilize um modelo simples, prático e funcional para resolver os problemas

A simplicidade e a praticidade favorecem a funcionalidade. Costumo dizer que existem modelos universais e que funcionam muito bem. Gerente não é sua função quebrar paradigmas teóricos, os cientistas e pesquisadores possuem essa responsabilidade. No contexto universitário presenciei o advento de várias “rodas quadradas”, principalmente no planejamento de projetos pedagógicos. Lembre-se que a qualidade e a criatividade não estão no modelo e sim nas pessoas que executam o processo.

Desobrigar-se de agradar a todos, assumir responsabilidades, centralizar energia, não reinventar a roda, levará VOCÊ gerente a matar qualquer problema no ninho.

José Augusto

fabri@femanet.com.br

Utilizando o framework de Zachman para definição de um processo de produção de software

O framework Zachman foi originalmente concebido, na IBM, por John Zachman, no início dos anos 80 e é caracterizado como um quadro de trabalho que provê mecanismos para definir as características (processos, tecnologia e conectividade) de uma corporação.  Ele utiliza um modelo matricial bidimensional com seis interrogações básicas (O que? Como? Onde? Quem?  Quando? Por que?) cruzadas com seis tipos de modelos (escopo, modelo de negócio, modelo sistêmico, modelo tecnológico e apresentação detalhada).

Atualmente, o referido framework é classificado como um padrão mundial para expressar elementos básicos para a arquitetura corporativa e de sistemas de informação. Neste post vou apresentar como apliquei o framework no estabelecimento de um processo de produção de software de uma empresa localizada no estado de SP. Para atingir este objetivo vou dividir o texto em três seções: 1 – Contexto empresarial, 2 – Apresentação do framework, 3 – Uma pequena visão da definição e institucionalização de algumas tarefas do processo.

1 – Contexto empresarial

A empresa X necessitava estruturar um processo de produção de software para atender as prerrogativas delineadas no framework de Zachman. O objetivo da empresa era concorrer em um processo licitatório. Importante: o edital pontuava as empresas que demonstrassem conhecimento no referido framework. É salutar dizer que a empresa em questão possuía um processo de produção de software semi-estruturado (ou seja, algumas atividades do processo eram bem definidas e estavam consistentes, porém outras deixavam a desejar). Esta semi-estruturação facilitou muito o trabalho. Primeiramente detectamos quais as atividades do processo seriam aproveitadas e quais seriam reestruturadas. Posteriormente envolvemos os colaboradores (cerca de 20 pessoas) para trabalhar na reestruturação. Apresentamos o framework de Zachman aos colaboradores e por meio de um brainstorm iniciamos nosso trabalho. Todas as informações colhidas eram materializadas em redes semânticas e, posteriormente, mapeadas junto ao framework.

2 – O framework

O framework é caracterizado por uma matriz de 6 X 7. Nas linhas visualizam-se os modelos e nas colunas as questões. A leitura do framework deve ser feita da seguinte forma:

Linha modelo de negócio X Como? = definição dos processos de negócio.

3 – Uma pequena visão da definição e institucionalização de algumas tarefas do processo

Nesta seção será apresentada a definição e institucionalização da atividade que materializa o modelo de negócio, as demais seguem a mesma abordagem.

De posse do framework e das redes semânticas geradas, concluímos que materialização do processo de negócio possui como entrada as informações advindas da atividade de mapeamento do escopo. Neste caso, para o referido processo, teríamos 6 artefatos de entrada (vide figura abaixo) e seis artefatos de saída. A quantidade de artefatos, tanto de entrada como de saída, não necessita respeitar estritamente as prerrogativas impostas no framework, é possível perfeitamente adaptá-las dentro do contexto organizacional previamente definido.

Todos os artefatos de entrada e de saída respeitavam os padrões de projeto e de produto estabelecidos pela organização. Dentro do processo de consultoria também foi configurada uma base de conhecimento, com o objetivo de materializar os aspectos sintáticos e semânticos para o preenchimento de tais artefatos. Uma ferramenta de gestão, também foi configurada, seu objetivo era estabelecer as linhas base de: tempo, custo, escopo (configuração) e qualidade.

Por fim, gostaria de salientar que estou aberto a possíveis discussões e, se necessário for, posso “contar”, pessoalmente, tudo o que foi feito nesta experiência.

Abraços

J.A.