The Bug Bang Theory

Ontem, dia 19 de maio de 2010, realizei minha terceira palestra em universidades, convidado pelo Centro Universitário de Belo Horizonte (UNI-BH).

Em primeiro lugar, gostaria de agradecer a UNI-BH e toda sua administração pelo convite, aos alunos pela paciência e atenção durante toda a palestra, ao meu amigo Junior Braga pela indicação e ao professor Tarcizo José pela ajuda, orientação e apoio durante todo o evento. Agradecimentos também a Fabíola Lara, Marlon Lima e Vanessa Vaz (colegas de trabalho) pela revisão, ao Ricardo Antunes por alguns slides e as nossas “fontes inesgotáveis” de conhecimento como a UFMG e a DFTestes, de onde boa parte do material foi baseado ou estudado.

Gostaria de elogiar a UNI-BH pela iniciativa e pela organização, diversidade e pontualidade do evento, meus parabéns!
O evento contou com outros profissionais e acadêmicos do setor de computação, sistemas e engenharias, como Marcio Sete da Challenge, Leonardo Martins e Charles Fortes da Paiva Piovesan, Gibran Silva da Localiza entre vários outros talentos de Belo Horizonte e região.

O tema da minha palestra foi “Introdução a Automação de Teste de Software”, mas claro que, por envolver alunos de todos os períodos e vários cursos (inclusive fora de TI como Engenharias), a palestra não pôde ser totalmente técnica, e abordamos boa parte do planejamento, elaboração e analise de testes funcionais e não funcionais, que não fazem parte unicamente das atividades de automatização.

Abaixo o Slide:

Introdução a Automação de Teste de Software

View more presentations from Camilo Ribeiro.

Abaixo um passo a passo explicando um pouco do que foi comentado durante a palestra (slide a slide):

Inicialmente conversamos um pouco sobre o motivo central da existência de qualquer departamento de qualidade e teste de software, até mesmo dos processos de desenvolvimento. Consideramos a filosofia de que existem diversos tipos diferentes de defeitos, assim como planejamento quando o cronograma não foi realista, análise quando um requisito não é corretamente detalhado no diagrama de atividades, de software quando uma falha é identificada etc. Discutimos sobre o custo que isso pode representar a um projeto e sobre os momentos em que podemos identificar esses defeitos, considerando alguns estudos como o de Boehm sobre o custo dos defeitos e o de Wheeler sobre a distribuição dos defeitos ao longo do projeto de desenvolvimento de software. Mais conteúdo sobre esses temas pode ser encontrado nos posts “Comentários sobre a Semana de Sistemas de Informação 2010 da PUC” e no “Bug is Dead“.

Falamos então, sobre existirem diferentes “técnicas” para aumentar a qualidade de um produto de software. Que nenhuma delas é por si só a verdade absoluta, mas que um conjunto delas, aplicadas nos momentos mais adequados podem aumentar a confiabilidade de que o produto está funcionando adequadamente. Usando a analogia das joaninhas acima (Ladybug em inglês, por isso são representadas como “bugs”, sentido figurado genérico na área de computação para problemas em softwares), podemos considerar que essas diversas técnicas são diferentes inseticidas, e que cada um deles tem maior eficácia contra cada um dos “bugs” que podem existir no processo de desenvolvimento de produtos de software.

Quando o assunto é automação de teste de software, o que estamos fazendo, basicamente, é automatizar a aplicação desse inseticida, ou seja, automatizando o processo de teste de software que tem efeitos principalmente em dois tipos de defeitos: Defeitos de Software e Defeitos de Arquitetura (veremos a frente alguns pontos que justificam essa afirmação). Como o nosso foco será nesse inseticida em especial, discutimos os conceitos e sua evolução de 1979 até os dias de hoje. Com isso eliminamos do escopo de estudo, outras aplicações, como inspeções, revisão estatica de código, etc. Para saber mais sobre os diversos mecanismos que um profissional de teste de software ou qualquer outra pessoa que vise melhorar o produto pode usar, recomendo a leitura do material gratuito do ISTQB, mantido e revisado em português pelo BSTQB que pode ser baixado da seguinte página: http://www.bstqb.org.br/?q=node/12

Falamos bastante sobre os “três fundamentos” ou pilares do teste de software que representam o nosso “GPS”. Conceitos importantes de aliar para entender melhor o escopo da automação em cada nível, as ferramentas e técnicas usadas para cada tipo de teste e os conhecimentos exigidos para cada técnica. Ressaltamos um pouco o conceito definido de caixa branca, preta e cinza, lembrando que a caixa branca ou transparente (também chamada de caixa de vidro por alguns autores, inclusive Glenford Myers, divulgador do conceito) está diretamente relacionada a estrutura do produto, seu código fonte, sua arquitetura e seus recursos em geral, enquanto o teste de caixa preta está relacionado aos seus requisitos, as necessidades que o produto visa solucionar e os testes de caixa cinza são intermédios entre as duas principais técnicas. Um exemplo interessante de teste de caixa cinza pode ser testar com acesso ao banco de dados, mas isso varia de autor para autor.

Como muito bem descrito na palestra “Automação de Testes, Mitos e Verdades” do Elias Nogueira, especialmente no slide 7 (Falsas Expectativas), muitas pessoas acreditam, por diferentes motivos, que automatizar o teste de software vai resolver todos os problemas. Infelizmente, automatização de testes não é a cura do câncer dos nossos projetos de software, primeiramente porque antes de automatizar testes, temos que ter bons testes especificados. Em um artigo da IBM chamado “Traceability from Use Cases to Test Cases” que foi citado em um treinamento/conferência há dois anos atrás, foi apresentada uma estrutura como a descrita abaixo que eu aproveitei por ser muito didática. Nela é apresentado um modelo ainda simples, pois não considera a rastreabilidade entre diferentes necessidades, funcionais e não funcionais, ou seja, testar é uma atividade extremamente analítica, complexa e desafiadora!

Detalhamos também os níveis de teste, explicando o modelo em V que há muitos anos vem sendo usado, e, apesar de não ser o melhor modelo para aplicação de teste de software hoje, continua sendo muito didático e ainda bastante próximo da realidade dos nossos processos de desenvolvimento de software. Chegamos a conclusão também, que momentos diferentes tem objetivos diferentes, consequentemente, planejamento e elaboração próprios, assim como robôs ou modelos de automação diferentes, que serão propostos e explicados mais adiante.

Automatizando Teste de Unidade:

Falamos sobre o conceito de teste de unidade e sobre os diversos itens que podem ser a nossa unidade. Para facilitar o entendimento, definimos a nossa unidade como uma classe, nossa linguagem de programação como Java e nosso framework de desenvolvimento de testes de unidade como o JUnit. Então falamos sobre a relação de cada classe, com seus diversos caminhos ou galhos (ver The Art of Software Tesging, 1979 de Glenform Myers para mais detalhes) que podem ser validados de diversas formas por testes desenvolvidos em qualquer momento, depois da classe, durante a criação da classe ou antes da criação da classe. Comentamos sobre esse último caso em especial, sobre a existência de uma regra chamada “Code the Unit Test First” do XP, que também foi comentado por mim no post “Uma introdução a TDD com JUnit“.

Automatizando Teste de Integração:

Comentamos sobre o escopo de validar a integração entre as unidades (normalmente já testadas). Basicamente, podemos imaginar que com dados validos entrando e sempre retornando valores ou resultados válidos, o que pode ser avaliado com o conjunto de testes de unidade, mas, ainda assim, podem existir defeitos entre esses valores que não foram identificados anteriormente. Nesse ponto é que o teste de integração atua, conferindo a conformidade com os requisitos e tentando identificar problemas na integração entre as unidades do sistema. Testando a comunicação (troca de informação) entre os vários contratos das unidades. Vimos também os três principais modelos descritos no terceiro slide, e recomendei o uso do modelo Bottom up para aplicação de testes de integração de funcionalidade e do modelo top down em testes de integração de desempenho/carga.

Automatizando Teste de Sistema:

Comentamos sobre os testes de sistema serem os primeiros a ser desenhados e usados nas organizações quando começam a ter mais maturidade, obviamente, assim também acontece com a automatização dos testes. Também falamos que é aqui que o Analista de Teste e o Testador atuam com mais frequencia e intensidade, elaborando casos de teste em nível de caso de uso e validando a maior parte dos requisitos do software. Relembramos os comentários feitos no slide “Testar é  muito mais que automatizar” sobre a forma de desenvolver casos de teste baseados em casos de uso e cenários de teste. Para entender um pouco mais sobre o assunto, leia “Um modelo para elaboração de cenários e casos de teste“.

Importante comentar sobre os slides abaixo. As figuras são unicamente ilustrativas e de certa forma até cômicas, mas não quero que você leitor, tenha uma interpretação de que programadores produzem “lixo” nem que sem uma ferramenta de automação o código fica com qualidade inferior. O que quero demonstrar é que quando temos ferramentas de apoio ao nosso processo, podemos melhorar a qualidade de vida e de trabalho de todos os envolvidos no processo de desenvolvimento de software. Nos slides abaixo, quero passar a mensagem que, uma vez que exista um processo definido e aplicado, esse processo por si só, ajuda a melhorar a qualidade do software, mas muitas vezes ele se torna repetitivo, cansativo e pouco desafiador, abaixando a motivação dos envolvidos. Esse cenário é agravado em empresas do seguimento de produtos, pois os colaboradores normalmente podem ficar anos com os mesmos sistemas. Com ferramentas de apoio como as de automatização de testes funcionais, podemos tornar essas atividades mais desafiadoras, eficazes e gerenciáveis, permitindo mais tempo para os desenvolvedores e testadores evoluírem outros aspectos da organização.

Comentamos também sobre a estrutura de teste de sistema usada na maioria das ferramentas de automação de testes, onde desenvolvemos ou gravamos e refinamos vários scripts, e em seguida planejamos uma execução ordenada desses scripts, inclusive selecionando dados específicos de um repositório qualquer.

Automatizando Teste de Aceite:

Entendemos o conceito de teste de aceite, e verificamos que esses testes, normalmente, são do cliente. E o objetivo deles não é nem encontrar defeitos, nem garantir que o software não tenha defeitos, mas sim avaliar o software e ter certeza que esse atende aos requisitos esperados, por isso, esses são testes muito pessoais. Chegamos então a conclusão, que muitas vezes não é interessante ter esses testes automatizados, pois na maioria quase que absoluta dos casos, perderia o valor agregado para o cliente.

Porem, vimos também que existem requisitos não funcionais, que são inviáveis de testar sem a ajuda de ferramentas sofisticadas, assim como os testes de carga e outros relacionados ao desempenho do sistema. Apresentei um exemplo de sumário de informações que podemos coletar nesses testes, para tentar identificar o principal problema no sistema, arquitetura ou ambiente da aplicação, assim como foi demonstrado que um sistema na internet pode ser afetado por inúmeras variáveis, como quantidade de acessos, recursos disponíveis e algoritmos aplicados.

Exemplifiquei com a apresentação de um vídeo contendo a execução de um caso real de automação e expliquei a plataforma utilizada, que também foi explicada no post Comentários sobre a palestra “Técnicas de Teste” na UNA, e pelo mesmo motivo não posso publicá-los na internet .

Comentei brevemente sobre a arquitetura dos testes automatizados na plataforma de reuso Praxis, que estudo atualmente na UFMG. Todo o trabalho desenvolvido pode ser baixado através da minha página do Departamento de Ciência da Computação da UFMG http://homepages.dcc.ufmg.br/~camilo ou também através do sítio do professor e criador do praxis, o Prof. Dr. Wilson de Pádua http://homepages.dcc.ufmg.br/~wilson.

Os testes no praxis são realizados de uma forma extremamente automática, e com uma arquitetura tão bem definida, que depois de criar todo o arcabolço do teste, a criação dos casos de teste passa a ser feita através de linhas simples, com vírgulas separando os dados que serão utilizados. Ou seja, os testes podem mudar que você não precisa mudar uma linha de código fonte, apenas os valores de entrada e saída. É claro que um conjunto de conhecimentos e muita prática são necessários para criar e manter os testes antes desse nível de automatização, mas vale ressaltar, que o praxis é um modelo de desenvolvimento de software para fins acadêmicos, logo não são muito reproduzíveis em fábricas e projetos de software. Apesar do praxis ser muito criticado (principalmente por ignorância e pré julgamento), eu acredito que seja o melhor modelo de engenharia de software para se ensinar e aprender (minha opinião). Para saber mais sobre o praxis pode adquirir o livro “Engenharia de Software: fundamentos, métodos e padrões – terceira edição” do Wilson de Pádua.

Assim encerramos, com agradecimentos já citados no início dessa publicação, mas, agradecer a quem nos apóia e nos escuta nunca é demais, por isso agradeço novamente a UNI-BH e aos meus colegas revisores

Novamente, muito obrigado pela presença e paciência ao assistir a palestrar e visitar a minha página. Sinto muito não ter reservado alguns minutos a mais para eventuais dúvidas, mas gostaria de ressaltar que estou sempre disponível para quaisquer dúvidas aqui no blog ou por e-mail camilo [at] camiloribeiro [dot] com

Bibliografia:

•Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. ISBN 0-471-04328-1.
•BOEHM, B.W., 1981, Software Engineering Economics, Prentice Hall.
•WHEELER, D.A., BRYKEZYNSKI, B., MEESON, R.N., 1996, Software Inspections: An Industry Best Practice, IEEE Computer Society.
• PRESSMAN, R.S., 2001, Software Engineering: A Practitioner´s Approach, Fifth Edition, McGraw Hill.
•[ISO9126] ISO/IEC 9126-1:2001, Software Engineering – Software Product Quality
•ISQTQB Glossário de termos usados no Teste de Software Versão 1.0
• Foundation Level ISTQB Syllabus, ISTQB
•PÁDUA FILHO (2003), Wilson. Engenharia de Software – Fundamentos, Métodos e Padrões. 3ª Edição. LTC Editora, 2009.
•RIOS, E., MOREIRA, T., SOUZA, A., CRISTALLI, R . Base de Conhecimento em Teste de Software 2ª Edição. Martins, 2007.
•IEEE Standards Board, “IEEE Standard for Software Unit Testing: An American National Standard, ANSI/IEEE Std 1008-1987″ in IEEE Standards: Software Engineering, Volume Two
•IEEE Std 829-2008.
•IEEE Std 610
• Hetzel, Bill, The Complete Guide to Software Testing, 1993, Ed.2
•CBT-TST110, Computer Based Training TST110 Principals of Software Testing for Testers;
•IEEE729-1983
•NOGUEIRA, Elias. Automação de Teste – Mitos e Verdades, 4° Encontro Mensal ALATS, http://www.slideshare.net/elias.nogueira, 2009
• IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries; IEEE; New York, NY.; 1990
•MERCI2010, Praxis 3.0 – Wilson de Pádua. http://homepages.dcc.ufmg.br/~wilson/praxis/ 2010
•ZIELCZYNSKI, Peter, Traceability from Use Cases to Test Cases,  http://www.ibm.com/developerworks/rational/library/04/r-3217/ IBM Rational Technical library, 2006

A alguns dias recebi um e-mail de uma amiga da comunidade de testes DFTestes (Fabiana Maronez), perguntando como usar o TestLink para gerenciar o QA (Garantia de Qualidade).
A maioria de nós certamente pensaria que é uma idéia um pouco distorcida. Usar uma ferramenta de gerência de testes para realizar QA? Mas com um pouco de criatividade e vontade de eliminar as planilhas, pensei em uma solução que pode atender o que a nossa colega solicita.

Para quem ainda não está habituado, podemos dizer que Quality Assurance (ou simplesmente QA) são atividades de auditoria que os processos baseados em modelos de melhoria como o CMMi e as ISO possuem para garantir que o processo está sendo seguido adequadamente. Para isso, normalmente são usadas planilhas e mais planilhas, com vários critérios. Essas planilhas são usadas de várias formas diferentes, desde uma para cada artefato até uma para cada projeto, mas a dificuldade de gerar relatórios e coletar indicadores quase sempre é surreal.

Obs: Para perfeita compreensão desse post, é necessário conhecimento básico em QA e na ferramenta TestLink. Recomendável também um conhecimento básico sobre CMMi.
Termos usados entre parênteses na cor verde ” (exemplo) “ simbolizam o que seria feito no TestLink em um projeto de teste.

Abaixo vou demonstrar uma forma de gerenciamento das auditorias com redução significativa do esforço:

1 – Criar um produto do TestLink para o QA.
(Criar um produto do TestLink)

É importante usar a opção  “Gerenciar Requisitos”, para futuramente usarmos rastreabilidade das práticas para os Casos de Auditoria*.
*Casos de auditoria é um nome improvisado que eu arrumei para classificar casos de teste voltados para o processo, substituindo os tradicionais critérios.

2 – Cadastrar as práticas.

(Cadastrar especificações de requisitos e requisitos)

O cadastro das práticas é opcional, mas agrega muito valor, pois facilita a compreensão do fundamento da existência de cada”caso de auditoria” . Não existe uma forma definitiva de inserir as praticas, mas no caso do CMMi, uma forma que eu achei muito interessante é criar Especificações de requisitos para cada PA (Process Area) e um requisitos para cada SG (Specific Goal) e SP (Specific Practice), como ilustrado acima.

3 – Criar os casos de auditoria
(Especificar casos de teste)
Ao criar os casos de auditoria, é importante usar o nosso conhecimento em casos de teste para definir pré-condições, procedimentos e resultados esperados, muito próximo do que fazemos com os casos de teste para nossos softwares.
Normalmente, os QAs são realizados somente com critérios, o que torna o processo de auditoria muito custoso, pois qualquer pessoa que precise realizar o QA deve antes ser muito treinada no processo e no modelo de melhoria de processos adotado. A ultilização de casos de auditoria, além de gerenciar e simplificar métricas do QA, torna o processo menos dependente de treinamento, e possivelmente adaptável para testadores ou analistas de teste, porque uma pessoa com muito conhecimento do processo e do modelo pode definir um conjunto de casos de auditoria e pessoas com menos conhecimento podem executá-los, assim como analistas de teste e testadores.

4 – Atribuindo práticas ao caso de auditoria
(Vincular requisitos aos casos de teste)
Nesse momento vinculamos as práticas que devem ser cobertas pelo caso de auditoria, de forma a criar uma rastreabilidade por prática. Isso será importante para verificar quando cada prática é coberta e quais os casos de auditoria são mais críticos.

Quando cadastramos podemos ver o caso de auditoria como a imagem abaixo:
Acima podemos ver como cada caso de auditoria fica no final de sua especificação. Com pré-condição, passos descrevendo a sequencia de ações para executá-lo, resultado esperado e práticas vinculadas.

Assim devem ser feitos todos os “critérios” usados para a auditoria. Uma vez cadastrados, podem ser editados e modificados livremente, da mesma forma que os casos de teste de projetos de software.

5 – Definindo projetos
(Criar um Plano de Teste e adicionar Casos de Teste a esse plano)
Todo o trabalho até aqui, é realizado somente uma vez, e modificado sempre que um critério ou caso de auditoria precisa fica desatualizado. De agora em diante, apenas criamos “projetos” (planos de teste do TestLink) e releases para suas auditorias. O trabalho de armazenar as informações e controlar os artefatos e evidências, fica totalmente a cargo da ferramenta.
Criamos para cada projeto que será auditado, um novo “plano de teste”, que podemos chamar de “plano de auditoria”.
Aqui “começa a mágica”. Podemos definir para cada plano de auditoria um conjunto de casos de auditoria, de forma a permitir a customização do processo.
Para isso, basta selecionar os casos de auditoria no momento de vinculá-los a cada um dos projetos, de acordo com a demonstração abaixo. No exemplo acima podemos selecionar apenas os casos de auditoria que o “Projeto para auditoria 02″ irá usar.

6 – Preparando para executar uma auditoria.
(Criar uma nova release para o plano)
Na demostração acima, ao criar uma release do TestLink estamos criando uma instancia do QA planejado para aquele projeto, ou seja, estamos permitindo a execução dos casos de auditoria para o “Projeto para auditoria 02″.

7 – Executando a auditoria.
(Executar a release)
Agora executamos cada um dos casos de auditoria. A execução é semelhante a tradicional (caso de teste). O resultado pode ser positivo (aprovado), negativo (não-conformidade) ou bloqueado (indisponível), em qualquer caso podemos tomar ações para evidenciar ou complementar a nossa execução.
Evidência de auditoria: Uma evidência como um print do documento, do registro ou qualquer tipo de arquivo que possa comprovar a auditoria pode ser vinculado ao resultado “Passou” da execução.
(Salvar um anexo a execução do caso de teste)
Não conformidade encontrada: Para as não-conformidades encontradas, normalmente é cadastrado um “bug” no bugzilla ou no mantis, de forma a não conformidade adotar o mesmo workflow dos defeitos. Se esse for o caso, podemos usar a integração Defect Tracking System/TestLink para gerenciar as não conformidades.
(Cadastrar um bug no Bugzilla, Mantis, Eventum ou qualquer outra ferramenta integrada ao TestLink)

Caso o resultado do caso de auditoria tenha sido Bloqueado, o Analista de QA deve informar o motivo do bloqueio nas notas.

8 – Visualizando sumário de auditorias.
(Resultados)
Agora temos todos os relatórios do TestLink, usados para gerenciar nossos casos de teste, aplicáveis aos casos de auditoria usados anteriormente.

Alguns relatórios interessantes:
a – Relatório baseado em requisitos:
Nesse contexto ele nos permite avaliar cada uma das práticas que devem ser atendidas pelo CMMi ou outro modelo de melhoria como ISO ou MPS.BR, do ponto de vista de cobertura por auditoria.

b – Métricas gerais do plano de auditoria:
Aqui podemos acompanhar a evolução das execuções de várias “auditorias” (releases) de uma forma simples.

Esse post foi motivado por uma não existência de uma ferramenta própria para a execução de auditorias para processos baseados em modelos de qualidade (pelo menos ao meu conhecimento), como a ISO e CMMi, em fábricas de software, onde, normalmente são usados critério difíceis de compreender, em planilhas controladas manualmente, o que causa um desperdício de produtividade e perda da qualidade.

Importante ressaltar que o TestLink não é uma ferramenta própria para essa finalidade, mas podemos aproveitar o conhecimento do TestLink para adaptar um pouco alguns conceitos, desde que seja para melhor.

Em breve devo disponibilizar os pacotes para importação com todas as PAs do CMMi Dev1.2 em CSV e outro com uma tradução especial em português usando os termos citados acima.

Estou disponível para questionamentos, críticas e sugestões.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

A Universidade Federal de Minas Gerais, melhor universidade de Minas Gerais e melhor ciência da computação do país, abre nessa semana o edital oficial para o Curso de Pós-Graduação em Ciência da computação (Lato Sensu) com ênfase em Engenharia de Software, que “tem por objetivo o aprimoramento da qualificação profissional de pessoal de nível superior que atua na área de desenvolvimento e gestão de projetos de software.”

Estou na metade do curso e posso confirmar a qualidade oferecida pela UFMG.

Na turma 15 (atual) estamos trabalhando com a metodologia Praxis, na versão 3.0 , desenvolvida pelo Dr. Wilson de Pádua Filho, professor do DCC (Departamento de Ciência da Computação) e do próprio curso de engenharia de software, e a linguagem de programação Java.

O curso requer um forte trabalho em equipe, vasta pesquisa acadêmica, profundo conhecimento em Java e RUP, além de muita força de vontade, paciência e determinação, para passar noites e fins de semana estudando e preparando trabalhos práticos, onde simulamos um projeto em suas diversas fases, com prazos, custo, mudanças de requisitos, gerência de configuração e etc., tudo seguindo o processo Praxis 3.0 apresentado no livro Engenharia de Software – Fundamentos, Métodos e Padrões do Wilson de Pádua Filho, ferramentas da IBM e da Eclipse Foundation e conhecimentos adquiridos no próprio curso.

O curso tem duração de aproximadamente um ano e dois meses (incluindo a monografia), contemplando a seguinte grade:
Ambientes de Programação – Uma visão geral sobre linguagens de programação e compiladores.
Programação Modular – Apresentação dos princípios de programação, padrões de projetos e programação.
Estruturas de Dados Fundamentais – Análise de algoritmos e estudo das estruturas de dados e suas aplicações.
Sistemas de Banco de Dados – Modelagem e análise, álgebra relacional, SQL, SGBD.
Engenharia de Produtos de Software I – Estudo de Engenharia de Software e Aplicação do processo Praxis.
Engenharia de Produtos de Software II - Estudo de Engenharia de Software e Aplicação do processo Praxis.
Engenharia de Usabilidade: Produtos -
Gestão de Projetos de Software I - Gestão de Projetos e Aplicação do processo Praxis.
Gestão de Projetos de Software II – Gestão de Projetos e Aplicação do processo Praxis.
Engenharia de Usabilidade: Processo -
Desenvolvimento de Pesquisa e Projetos de Informática I – Desenvolvimento da monografia.
Desenvolvimento de Pesquisa e Projetos de Informática II – Desenvolvimento da monografia.
Tópicos em Engenharia de Software I – Estudo de engenharia de software, ferramentas e técnicas.
Tópicos em Engenharia de Software II – Estudo de engenharia de software, ferramentas e técnicas.

Todos os professores são doutores, com vasta experiência e muita didática. Os laboratórios e bibliotecas são as do Departamento de Ciência da Computação da UFMG.

É importante ressaltar que o curso oferece uma grade (apresentada acima) para profissionais que trabalhem em todas as disciplinas da engenharia de software e não somente com programação. Na verdade, acredito que profissionais desenvolvedores/programadores devem procurar outros cursos, como o Análise de Sistemas da UFMG ou Arquitetura de Software do IGTI. O curso, apesar de cobrar muito, oferece pouco aprendizado em programação, focando em processos.

Para engenheiros de processos, analistas de requisitos, analistas de teste, analistas de sistemas entre outros, o curso é muito interessante.

Para mais informações: http://dcc.ufmg.br/especializacao/cei/EngSoft/engSoft_apresentacao.html

Uma ótima opção