O Projeto Aeroportuário consiste em uma atividade com alto grau de complexidade. As modernas técnicas de Gerenciamento de Projeto utilizadas na atualidade permitem um correto planejamento, gerenciamento e acompanhamento das atividades envolvidas em um projeto com este grau de complexidade. Ainda assim, existe espaço para o aperfeiçoamento de alguns conceitos, contribuindo para aumentar o controle e eficiência do gerenciamento do projeto. Os ganhos obtidos com a aplicação da Gestão de Configuração em projetos com produtos/serviços de alta repetibilidade resultaram em um estudo de caso para aplicação desta metodologia em um projeto com as características do projeto aeroportuário. Este trabalho propõe a adoção da Gestão de Configuração para auxiliar no gerenciamento do projeto aeroportuário, monitorando e garantindo o atingimento dos resultados contratados, além de prover a todo tempo a situação da configuração do projeto, verificando-se a validade da aplicação da Gestão de Configuração em projetos desta natureza.

A construção de software é um empreendimento de alto risco. Encontra na literatura que, no ano de 2009, 68% dos projetos de TI apresentaram falhas em prazo, custo ou qualidade. O Tribunal de Contas da União ressalta que a metodologia de desenvolvimento deve ser executada pelas organizações governamentais de forma sistemática e documentada, para permitir a avaliação e a melhoria do processo, com vistas à produção de software de qualidade. Neste contexto de metodologias para minimizar falhas, identificou-se em guias de boas práticas de gestão de projetos, livros e normas que tudo começa a partir da definição do escopo, sem o qual não é possível continuar o trabalho de gestão. Sendo assim, a deficiência da definição do escopo de um projeto aponta para um Modelo de Inspeção baseado em Checklist, com a finalidade de garantir que as principais informações geradas pelo grupo de processos de planejamento da gestão de escopo de projetos de sistema de TI, sejam observadas de forma adequada e estejam refletidas nos documentos produzidos por organizações públicas, mais especificamente do âmbito do Comando da Aeronáutica (COMAER). Para tanto, o trabalho é dividido em quatro partes: (1) identificar as informações relevantes para criar uma lista de verificação, a fim de auxiliar uma organização do Comando da Aeronáutica na execução do grupo de processos de planejamento da gestão de escopo, bem como, definir um método de inspeção baseado em uma técnica de leitura para ser utilizado na aplicação prática do modelo proposto; (2) apresentar a concepção do modelo da lista de verificação, a contextualização da mesma segundo o PMBOK e uma implementação do processo de inspeção para a aplicação prática do modelo proposto; (3) aplicar o modelo proposto através de dois exemplos de desenvolvimento de software, interno e terceirizado, por organizações militares da FAB; (4) avaliar o modelo proposto comparando os resultados obtidos com os problemas identificados pelos integrantes dos projetos nos exemplos estudados, realizando uma discussão acerca das conclusões obtidas. A tese conclui que o modelo desenvolvido: pode (1) minimizar os problemas identificados nos exemplos estudados; é (2) mais completo do que o PMBOK porque é necessário pesquisar informações em outras fontes de consulta para complementar as informações contidas neste guia de conhecimento; pode (3) prevenir os impactos de problemas legais desde as fases iniciais do projeto.

Open Source Design (OSD) é uma estratégia de desenvolvimento adotada por comunidades que desenvolvem produtos manufaturados colaborativamente, em um regime copyleft e rede peer to peer virtual. O resultado é um conjunto de informações capazes de permitir a fabricação remota em que o usuário pode construir o seu produto, ao invés de um sistema produtivo específico previamente definido, como no desenvolvimento tradicional. A tangibilidade e a distância física entre desenvolvedores impõem barreiras à colaboração, mas avanços como a tecnologia de impressão 3D fez surgir plataformas virtuais para o compartilhamento de arquivos que tornam esta realidade possível. O número deste tipo de plataformas é significativo e há problemas na delimitação teórica do fenômeno e questões em aberto. No desenvolvimento OSD faz-se necessário o uso de objetos de fronteira (Boundary Objects – BOs). Qual o papel destes objetos? Eles estão presentes nas plataformas citadas? As plataformas existentes possuem recursos para a gestão destes objetos? Quais as características que estas plataformas devem apresentar para viabilizar o desenvolvimento OSD? Este trabalho reúne um conjunto de investigações para elucidar as questões acima. Por meio de um estudo de caso inicial e revisões sistemáticas, os conceitos foram analisados e propostos teoricamente. Por meio de um levantamento de 686 projetos de seis comunidades OSD diferentes hospedadas na plataforma Thingiverse, auxiliado por uma análise de conteúdo sobre a relação entre plataforma e colaboração, em seis projetos de diferentes plataformas, foi possível discutir o papel das plataformas utilizadas por comunidades OSD. Discute-se a relação com o desempenho do projeto e com a colaboração alcançada, identificando-se problemas potenciais e soluções latentes. Os resultados indicam que as plataformas estudadas, entre as mais difundidas, apresentam limitações. Finalmente, por meio da análise conjunta dos resultados, à luz das práticas de gestão de configuração existentes no desenvolvimento tradicional, foi possível identificar uma lista de propriedades latentes, que poderiam ser incorporadas nas plataformas, como: estrutura do produto, versionamento, ferramentas de armazenamento e rastreabilidade, auditoria, controle da configuração e governança da interface. As propriedades identificadas são uma contribuição importante para a inserção em ferramentas de design colaborativo. / Open Source Design (OSD) is a strategy adopted by communities that develop collaboratively manufactured products in a copyleft conditions and on a peer to peer network. The result is a set of information that allow the remote manufacturing where the users can build their own products, despite of a specific productive system previously defined as the traditional development. The tangibility and the geographic distance among developers impose barriers on the collaboration, on the other hand technology breakthroughs in the 3D printer technology made arise virtual platforms to share files that made this reality achievable. The number of these types of platforms is increasing and there are difficulties to delimitating of the phenomenon and there are gaps that need investigation. Is required the use of BOs in OSD development? What is the role of these BOs? Are they used in the mentioned platforms? Do the current platforms have features to the management of BOs? Which features must these platforms have to make feasible the OSD development? This thesis gathers an amount of investigations to elucidate the questions above. Through an initial study of case and systematic revisions, the concepts were analyzed and theoretically proposed. There was collected information of 686 projects from 6 different OSD communities hosted on the Thingiverse platform; in complement a content analysis about the relation between the platform and collaboration in six projects of three different platforms, to discuss the role of the platforms used for OSD communities. It is discussed the relation between the performance project with the collaboration, identifying the potential problems and the latent solutions. The result indicates that the investigated platforms, even the most widespread, present limitations. Finally, using a combined analysis of the results, according to the practices of management configuration existent in the traditional development, it was possible to identify a list of features that could be incorporated in the platforms, such: product structure, versioning, storage tools and traceability, audits, control configuration, governance. The identified features are important contributions to the insertion in tools of collaborative design.

Open Source Design (OSD) é uma estratégia de desenvolvimento adotada por comunidades que desenvolvem produtos manufaturados colaborativamente, em um regime copyleft e rede peer to peer virtual. O resultado é um conjunto de informações capazes de permitir a fabricação remota em que o usuário pode construir o seu produto, ao invés de um sistema produtivo específico previamente definido, como no desenvolvimento tradicional. A tangibilidade e a distância física entre desenvolvedores impõem barreiras à colaboração, mas avanços como a tecnologia de impressão 3D fez surgir plataformas virtuais para o compartilhamento de arquivos que tornam esta realidade possível. O número deste tipo de plataformas é significativo e há problemas na delimitação teórica do fenômeno e questões em aberto. No desenvolvimento OSD faz-se necessário o uso de objetos de fronteira (Boundary Objects – BOs). Qual o papel destes objetos? Eles estão presentes nas plataformas citadas? As plataformas existentes possuem recursos para a gestão destes objetos? Quais as características que estas plataformas devem apresentar para viabilizar o desenvolvimento OSD? Este trabalho reúne um conjunto de investigações para elucidar as questões acima. Por meio de um estudo de caso inicial e revisões sistemáticas, os conceitos foram analisados e propostos teoricamente. Por meio de um levantamento de 686 projetos de seis comunidades OSD diferentes hospedadas na plataforma Thingiverse, auxiliado por uma análise de conteúdo sobre a relação entre plataforma e colaboração, em seis projetos de diferentes plataformas, foi possível discutir o papel das plataformas utilizadas por comunidades OSD. Discute-se a relação com o desempenho do projeto e com a colaboração alcançada, identificando-se problemas potenciais e soluções latentes. Os resultados indicam que as plataformas estudadas, entre as mais difundidas, apresentam limitações. Finalmente, por meio da análise conjunta dos resultados, à luz das práticas de gestão de configuração existentes no desenvolvimento tradicional, foi possível identificar uma lista de propriedades latentes, que poderiam ser incorporadas nas plataformas, como: estrutura do produto, versionamento, ferramentas de armazenamento e rastreabilidade, auditoria, controle da configuração e governança da interface. As propriedades identificadas são uma contribuição importante para a inserção em ferramentas de design colaborativo. / Open Source Design (OSD) is a strategy adopted by communities that develop collaboratively manufactured products in a copyleft conditions and on a peer to peer network. The result is a set of information that allow the remote manufacturing where the users can build their own products, despite of a specific productive system previously defined as the traditional development. The tangibility and the geographic distance among developers impose barriers on the collaboration, on the other hand technology breakthroughs in the 3D printer technology made arise virtual platforms to share files that made this reality achievable. The number of these types of platforms is increasing and there are difficulties to delimitating of the phenomenon and there are gaps that need investigation. Is required the use of BOs in OSD development? What is the role of these BOs? Are they used in the mentioned platforms? Do the current platforms have features to the management of BOs? Which features must these platforms have to make feasible the OSD development? This thesis gathers an amount of investigations to elucidate the questions above. Through an initial study of case and systematic revisions, the concepts were analyzed and theoretically proposed. There was collected information of 686 projects from 6 different OSD communities hosted on the Thingiverse platform; in complement a content analysis about the relation between the platform and collaboration in six projects of three different platforms, to discuss the role of the platforms used for OSD communities. It is discussed the relation between the performance project with the collaboration, identifying the potential problems and the latent solutions. The result indicates that the investigated platforms, even the most widespread, present limitations. Finally, using a combined analysis of the results, according to the practices of management configuration existent in the traditional development, it was possible to identify a list of features that could be incorporated in the platforms, such: product structure, versioning, storage tools and traceability, audits, control configuration, governance. The identified features are important contributions to the insertion in tools of collaborative design.