O uso sistemático de processo de software favorece a qualidade do produto gerado e orienta os passos para a construção do software aderente a qualidade esperada. Processos são comumente especificados e representados por linguagens de modelagem de processo de software conhecidas como Software Process Modeling Language (SPML). Dentre essas linguagens, a Software & Systems Process Engineering Metamodel (SPEM) se destaca por ser um perfil Unified Modeling Language (UML) para modelagem de processo de software e sistemas. Processos de software evoluem junto as necessidades da instituição e profissionais que o utilizam, necessitando serem monitorados e avaliados constantemente para manter as suas qualidades. Atualmente quatro formas de avaliações de processo são mais conhecidas entre as práticas da indústria e a literatura da engenharia de software, são elas: (i) avaliação do produto frente ao processo, (ii) verificações associadas a modelos de avaliação, (iii) validação através especificações formais e a (vi) visão sistêmica da engenharia de software centrada no ser humano. Embora seja possível aplicar qualquer uma das quatro formas de avaliações citados anteriormente para garantir a evolução e qualidade do processo de software, estas contam com algumas características que podem ser inconvenientes. Primeiramente estas formas de avaliações não realizam uma detecção precisa dos elementos do processo que potencialmente mais impactam negativamente a sua qualidade. Segundo estas avaliações se utilizam de dados obtidos após a execução do processo, assim só é possível verificar problemas no processo após a execução do mesmo, o que já pode acarretar alguns possíveis prejuízos. Mais especificamente quando estas formas de avaliação são realizadas pelo uso de simulação requerem um conhecimento específico para a execução dos procedimentos da simulação e o uso de dados simbólicos que simulem os dados do processo após a sua execução. Apesar de SPML como o SPEM serem usadas para melhorar o entendimento de um processo, a especificação de um processo pode ser feita de forma inadequada ferindo fatores de qualidade do processo. Este fenômeno pode ser comparado ao conceito de bad smells que são problemas de design em código de software e neste trabalho será apresentado como process smell por se observar problemas no design do processo. Assim, um process smell na especificação de um processo pode gerar impactos negativos a qualidade do processo e por consequência afetar a qualidade do produto de software. Neste sentido, esta pesquisa teve como objetivo especificar um catálogo de process smells para avaliar se a técnica de detecção de bad smells baseada no paradigma de código orientado a objeto de Marinescu (2004) pode apoiar a identificação de violações estruturais em processo de software modelos com SPEM. Para tanto foi estabelecida uma metodologia com duas etapas, ambas contando com validações feitas por survey com profissionais de engenharia de software. Na primeira etapa da metodologia foram realizadas as seguintes atividades: (1.i) a definição de similares entre elementos do paradigma de orientação a objeto e os elementos do SPEM, (1.ii) identificação e seleção do bad smells para adaptação para process smells baseado no SPEM (1.iii) a adaptação dos bad smells selecionados para process smells baseado no SPEM. Na segunda etapa da metodologia foram realizadas as seguintes atividades: (2.i) a definição das estratégias de detecção dos process smells e (2.ii) a avaliação e definição da estratégia para alcançar os respectivos valores limiares (thresholds) para as métricas de detecção dos process smells. Esta pesquisa mostrou que o catálogo proposto de process smells é claramente aceito pelos analistas. Contudo, avaliando o contexto da execução de um processo na prática, podem existir process smells mais significativos do que outros. Espera-se que o catálogo produzido possa apoiar a identificação de process smells em modelos de processo de software com o objetivo de indicar pontos nos quais o processo pode ser melhorado, antes mesmo da sua primeira execução, evitando problemas que afetam negativamente os atributos de qualidade do processo. Por exemplo a presença de muitos passos e muitos fluxos em tarefas o que afeta a compreensibilidade (capacidade de compreensão) ou problemas de modificabilidade (capacidade de modificação) como a o fato de ter muitas dependências entre os elementos do processo. Adicionalmente, foram obtidos aspectos que podem orientar melhorias deste catálogo em trabalhos futuros.