Este trabalho apresenta uma ferramenta para gerenciamento de projetos, priorizando as fases de planejamento e o controle do desenvolvimento de software. Ao efetuar o planejamento de um projeto é necessário estimar o prazo, o custo e o esforço necessário, aplicando técnicas já aprovadas, existentes na literatura, tais como: Estimativa do Esforço, Estimativa de Putnam, Modelo COCOMO, Análise de Pontos por Função, Pontos de Particularidade e PSP. É necessária a utilização de uma ferramenta que automatizem o processo de estimativa. Hoje no mercado, encontram-se várias ferramentas de estimativas, tais como: ESTIMACS, SLIM, SPQR/20, ESTIMATE Professional. O controle do desenvolvimento do projeto está relacionado ao acompanhamento do projeto, do profissional e da própria estimativa de custo e esforço de desenvolvimento. Nenhuma das ferramentas estudadas permitiu o controle do projeto por parte da gerência, por isto esta se propondo o desenvolvimento uma nova ferramenta que permita o planejamento e controle do processo de desenvolvimento. Esta ferramenta deve permitir a comparação entre as diversas técnicas de estimativas, desde que baseadas na mesma medida de tamanho: pontos por função. Para exemplificar o uso desta ferramenta, foram aplicados dois estudos de casos desenvolvidos pela empresa Newsoft Consultoria de Informática.

Resumo não disponível

Os requisitos direcionam o desenvolvimento de software porque são cruciais para a sua qualidade. Como conseqüência tanto requisitos funcionais quanto não funcionais devem ser identificados o mais cedo possível e sua elicitação deve ser precisa e completa. Os requisitos funcionais exercem um papel importante uma vez que expressam os serviços esperados pela aplicação. Por outro lado, os requisitos não funcionais estão relacionados com as restrições e propriedades aplicadas ao software. Este trabalho descreve como identificar requisitos não funcionais e seu mapeamento para aspectos. O desenvolvimento de software orientado a aspectos é apontado como a solução para os problemas envolvidos na elicitação e modelagem dos requisitos não funcionais. No modelo orientado a aspectos, o aspecto é considerado o elemento de primeira ordem, onde o software pode ser modelado com classes e aspectos. As classes são comumente usadas para modelar e implementar os requisitos funcionais, já os aspectos são adotados para a modelagem e implementação dos requisitos não funcionais. Desse modo, é proposta a modelagem dos requisitos não funcionais através das fases do ciclo de vida do software, desde as primeiras etapas do processo de desenvolvimento. Este trabalho apresenta o método chamado FRIDA – From RequIrements to Design using Aspects, cujo objetivo é determinar uma forma sistemática para elicitar e modelar tanto os requisitos funcionais quanto os não funcionais, desde as fases iniciais do ciclo de desenvolvimento. Em FRIDA, a elicitação dos requisitos não funcionais é realizada usando-se checklists e léxicos, os quais auxiliam o desenvolvedor a descobrir os aspectos globais – utilizados por toda a aplicação – bem como, os aspectos parciais que podem ser empregados somente a algumas partes da aplicação. O próximo passo consiste na identificação dos possíveis conflitos gerados entre aspectos e como resolvê-los. No método FRIDA, a identificação e resolução de conflitos é tão importante quanto a elicitação de requisitos não funcionais, nas primeiras fases do ciclo de vida do software. Além disso, é descrito como usar a matriz de conflitos para automatizar esse processo sempre que possível. A extração dos aspectos e sua modelagem visual são características muito importantes, suportadas pelo método, porque elas possibilitam a criação de modelos que podem ser reutilizados no futuro. Em FRIDA, é demonstrado como transformar os requisitos em elementos da fase de projeto (classes e aspectos) e como traduzir esses elementos em código. Outra característica do método FRIDA é que a conexão entre diagramas, que pertencem a diferentes fases do processo de desenvolvimento do software, permite um alto nível de rastreabilidade. Em resumo, FRIDA requer que o desenvolvedor migre de uma visão puramente funcional para outra que contemple também os requisitos não funcionais.

Atualmente, um dos grandes desafios para qualquer desenvolvedor de software é projetar um sistema que reutilize ao máximo elementos de código e de projeto existentes, visando diminuir o tempo e o esforço exigidos na produção do software. Entre as inúmeras formas de possibilitar reuso no contexto do desenvolvimento segundo o paradigma da orientação a objetos, destaca-se a abordagem de frameworks. A grande importância da documentação de software utilizada no processo de desenvolvimento aliada às características de frameworks serviram como motivação para este trabalho. A documentação dentro do processo de desenvolvimento de software não faz parte de uma fase definida, mas ocorre durante toda sua existência, em paralelo com outras fases do ciclo de vida. A abordagem de frameworks dentro deste contexto enfoca o tratamento de templates e definições das características dos artefatos de software (incluindo não somente código mas também produtos de análise, projeto, frameworks, componentes, diagramas, entre outros), facilitando e acelerando o processo de documentação. Um framework, devido a suas características peculiares que serão examinadas e explicitadas no trabalho, contém uma série de informações que podem, além de apoiar a documentação, ser úteis para produção de outros artefatos (por exemplo, planejamentos de teste, scripts de bancos de dados, padrões de codificação, entre outros) do processo de desenvolvimento. Assim, em um processo de desenvolvimento evolutivo, que utiliza a geração de artefatos como recurso, a manutenção pode ser integralmente realizada somente na especificação e não diluída nos artefatos gerados. O objetivo deste trabalho é investigar, propor e desenvolver uma ferramenta de documentação e geração de artefatos de software, denominado FrameworkDoc. O termo documentação de software aqui utilizado se refere a documentação de desenvolvimento de software, incluindo artefatos, arquiteturas, ferramentas entre outros. Serão abordados dois principais aspectos: primeiramente, a geração automática de documentação dentro do processo de desenvolvimento de software e depois a geração de outros artefatos deste processo, a partir das definições de alto nível disponíveis através do framework. Exemplos de aplicações do FrameworkDoc em projetos reais são apresentados. No entanto, os documentos e artefatos de software considerados foram definidos de forma suficientemente genérica para serem aproveitados em outros contextos.

Submitted by Johnny Rodrigues (johnnyrodrigues@ufcg.edu.br) on 2018-09-26T14:56:47Z No. of bitstreams: 1 PRYSCILLA MARCILI DÓRA SALISTER - DISSERTAÇÃO PPGCC 2011..pdf: 24571098 bytes, checksum: c199bc1e761c5a1a5807b986a0b07ed1 (MD5) / Made available in DSpace on 2018-09-26T14:56:47Z (GMT). No. of bitstreams: 1 PRYSCILLA MARCILI DÓRA SALISTER - DISSERTAÇÃO PPGCC 2011..pdf: 24571098 bytes, checksum: c199bc1e761c5a1a5807b986a0b07ed1 (MD5) Previous issue date: 2011-12-12 / As atividades realizadas há mais de 10 anos no LSD (Laboratório de Sistemas Distribuídos) apontam para uma consolidação de resultados na área de Sistemas Distribuídos, principalmente, nas pesquisas em Grades Computacionais, Computação nas nuvens, Sistemas Peer-toPeer (P2P), Tolerância a Falhas, Desenvolvimento de Software Distribuído e Concorrente e, mais recentemente, Aplicações Industriais e Qualificação de Software. Um dos principais projetos do laboratório é o OurGrid, uma grade aberta, free-to-join, que agrega serviços computacionais e dá suporte a uma gama de aplicações chamadas de bag-of-tasks. O OurGrid é um software livre e existe um número expressivo de instituições, dentro e fora do país, que usaram ou estão usando essa tecnologia. Dentro do escopo do laboratório também desenvolveram-se outros produtos como o OurBackup [Oliveira, 2007], um sistema de backup P2P baseado em redes sociais, o JIC, protocolo de comunicação do OurGrid, entre outros. Em todos os casos, o LSD buscou problemas reais no contexto do desenvolvimento e utilização desses produtos de software por clientes externos ao laboratório para desenvolver sua pesquisa. Pela importância desses projetos e por ser uma das iniciativas em grades computacionais de grande sucesso no Brasil, o LSD tem tido a preocupação em oferecer produtos de qualidade para a comunidade de usuários de grades. Em função do cenário do LSD, isto é, equipe composta, em sua maioria, por alunos de graduação em Ciência da Computação; histórico da universidade no desenvolvimento de software; experiência em elaboração de processo de desenvolvimento como XP1 [XP1, 2002] e OurProcess [OurProcess] e o tipo de software desenvolvido, optou-se por solucionar o problema de qualidade baixa nos produtos iniciando pela elaboração de um novo processo de desenvolvimento, isso porque a qualidade dos produtos desenvolvidos não estava nos níveis idealizados. Essa preocupação com a qualidade resultou no OurQualityProcess (OQP) um processo baseado na metodologia ágil XP [Beck, 2001], com a incorporação de práticas da metodologia não ágil e evitando a intrusividade excessiva no trabalho dos desenvolvedores. Os resultados obtidos com o OQP mostraram fortes indícios de melhoria na qualidade dos produtos desenvolvidos através de comparações estatísticas utilizando a metodologia científica no estudo de alguns casos. / The tasks which have been executed for more than 10 years on LSD (Distributed System Laboratory) show a consolidation of results in Distributed Systems area, mainly in research on Grids Computing, Cloud computing, Peer-to-Peer (P2P) Systems, Fault Tolerance, Distributed Systems Development and Concurrent Systems development and more recently, Industrial Applications and Software Qualification. One of the main projects of the laboratory is the OurGrid, an open grid, free-to-join, which combines computational services and supports a range of applications called bag-of-tasks. OurGrid is free software and there are a significant number of institutions, inside and outside the country, which have used or are still using this technology. In the laboratory scope other products, were also developed such as OurBackup [Oliveira, 2007], a P2P backup system based on social networks, the JIC, OurGrid communication protocol, among others. In ali cases, LSD looked for real problems in the development context and use of these software products by externai customers of the laboratory to develop its research. According to the importance of these projects and for it being one of the initiatives in the great Grid success in Brazil, LSD has been concerned about offering quality products to the community of grid users. Due to the LSD scenario (team composed mostly by graduate students in Computer Science, university history in software development, experience in defining processes as XP1 [XP1, 2002] and OurProcess and the type of software developed, we chose to pursue quality in the products starting with the drafting of a new development process, which is why the quality of the products developed was less than what was expected. This concern for quality has resulted in OurQualityProcess (OQP), a process based on Agile XP [Beck, 2001], with the incorporation of practices from traditional methodology and avoiding excessive intrusiveness in the work of developers. The results obtained with the OQP showed strong signs of improvement in the quality of the products developed through statistical comparisons using a scientific methodology in the study of some cases.

Dissertação (mestrado)—Universidade de Brasília, Departamento de Ciência da Computação, 2012. / Submitted by Albânia Cézar de Melo (albania@bce.unb.br) on 2012-10-10T12:53:55Z No. of bitstreams: 1 2012_LucineiaTurnes.pdf: 1369372 bytes, checksum: 5197ad2360de4ddb71bb0135cff80b22 (MD5) / Approved for entry into archive by Guimaraes Jacqueline(jacqueline.guimaraes@bce.unb.br) on 2012-10-15T11:46:52Z (GMT) No. of bitstreams: 1 2012_LucineiaTurnes.pdf: 1369372 bytes, checksum: 5197ad2360de4ddb71bb0135cff80b22 (MD5) / Made available in DSpace on 2012-10-15T11:46:52Z (GMT). No. of bitstreams: 1 2012_LucineiaTurnes.pdf: 1369372 bytes, checksum: 5197ad2360de4ddb71bb0135cff80b22 (MD5) / Suporte ferramental e essencial para a Engenharia de Aplica ção em Linhas de Produto de Software (LPS). Apesar de uma variedade de ferramentas existentes, a maioria delas não apresenta suporte adequado a con gurabilidade e exibilidade. Assim sendo, e dif cil para elas serem aplicadas em diferentes contextos, por exemplo, endere car variabilidade em diferentes combina ções de artefatos e permitir a inserção e o gerenciamento de variabilidades de novos artefatos de diferentes dom nios. Para abordar esta questão, e necessário explorar sistematicamente a comunalidade e, adequadamente, gerenciar a variabilidade de tais ferramentas. Nesse sentido, realizamos uma an alise comparativa de t ecnicas de gerenciamento de variabilidades para o desenvolvimento de ferramentas de LPS no contexto da ferramenta Hephaestus. A an alise revela que duas t ecnicas, uma anotativa e outra transformacional, são as mais adequadas ao gerenciamento de variabilidades em Hephaestus, e que a sua combina ção e uma estrat egia viável para melhorar esse gerenciamento. Além disso, apresentamos a an álise, projeto e implementa ção do dom ínio e um processo que suporta a evolu cão de Hephaestus-PL, uma linha de produtos de ferramentas de linha de produtos de software onde o gerenciamento de variabilidades foi implementado por abordagem transformacional usando opera c~oes de metaprogramação. Hephaestus-PL suporta um processo que permite a instanciaç~~ao de ferramentas de linha de produtos modelando a variabilidade em novos e em qualquer combina ção de artefatos, e foi desenvolvida por bootstrapping de versões da ferramenta Hephaestus. Este processo suporta a aborda- gem reativa e a exibilidade para introduzir novos ativos aumentando a con gurabilidade de Hephaestus-PL e permitindo a gera cão de diferentes instâncias de Hephaestus-PL. Uma avalia cão da solu ção proposta revela que a mesma melhorou a con gurabilidade e exibilidade quando comparamos com as evolu cões anteriores de Hephaestus. ______________________________________________________________________________ ABSTRACT / Tool support is essential for application engineering in software product lines. Despite a myriad of existing tools, most still lack adequate support for con gurability and exibility, so that it is hard for them to be applied in di erent contexts, e.g., addressing variability in an arbitrary combination of di erent artifacts and introducing and managing variabil- ity in new artifacts. Addressing this issue requires systematically exploring underlying commonality and adequately managing variability of such tools. Accordingly, we have conducted a comparative analysis of variability management techniques for SPL tool development in the context of the SPL Hephaestus tool. The analysis reveals that two techniques, one annotative and another transformational, are most suitable to variability management in Hephaestus, and that their combination is a feasible strategy to improve such management. Furthermore, we present domain analysis, design, implementation, and a supporting process for extending Hephaestus-PL, a software product line of software product line tools whose variability management was implemented by transformational approach us- ing metaprogramming operations. Hephaestus-PL is supported by a process allowing instantiating product line tools for modeling variability in new and in any combination of artifacts, and has been developed by bootstrapping previous versions of the Hephaestus tool. This process supports the reactive approach and exibility to add new assets increas- ing the con gurability of Hephaestus-PL and reaching the goal of enabling the generation of di erent instances of Hephaestus-PL. An assessment of the proposed solution reveals that it has improved con gurability and exibility when compared to previous evolution of Hephaestus.

Arquiteturas de software e teste de software desempenham um papel essencial no processo de desenvolvimento de produtos de software de alta qualidade. Com base em um mapeamento sistemático, pode-se observar que as atividades de estabelecimento de arquiteturas de software não consideram representar informações de teste de software associadas às visões da arquitetura, em particular de arquiteturas de referência. Este trabalho tem por objetivo propor um processo que induza a representação de informações de teste de software no estabelecimento de arquiteturas de referência. Dessa forma, além de se abstrair a essência de um conjunto de arquiteturas de software de um domínio de aplicação, facilitando o projeto de novas arquiteturas por meio do reúso e padronização de elementos arquiteturais, promove-se também o reúso e a padronização de informações de teste. Este trabalho é realizado a partir do modelo RAModel e do processo ProSA-RA. O RAModel apresenta um conjunto de elementos essenciais para o projeto de arquiteturas de referência. O ProSA-RA por sua vez apresenta um processo que sistematiza o estabelecimento de arquiteturas de referência, considerando os elementos do RAModel. Em particular, propõe-se um processo denominado ProSA-RAT . Esse processo viabiliza a definição de processos de teste adequados a domínios de aplicação específicos promovendo o reúso e padronização de informações de teste nas etapas iniciais de processos de desenvolvimento baseados em arquitetura. Um estudo de viabilidade do ProSA-RAT foi conduzido e um exemplo no domínio de robótica é apresentado. / Software architectures and software testing play an essential role in the development process of high quality software products. Based on a systematic mapping, it could be observed that the activities of establishing software architectures do not consider to represent software test information associated with the architecture views, in particular of reference architectures. The objective of this work is to propose a process that induces the representation of software test information in the establishment of reference architectures. Thus, in addition to abstracting the essence of a set of architectures of an application domain, facilitating the design of new architectures through the reuse and standardization of architectural elements, reuse and standardization of test information are also promoted. This work is carried out using the RAModel and the ProSA-RA. RAModel presents a set of essential elements for the design of reference architectures. ProSA-RA, on the other hand, presents a process that systematizes the establishment of reference architectures, considering the elements of the RAModel. In particular, a process named ProSA-RAT is proposed. This process facilitates the definition of test processes adequate to specific application domains by promoting the reuse and standardization of test information in the early stages of architecture based development processes. A feasibility study of ProSA-RAT has been carried out and an example in the field of robotics is presented.

Resumo não disponível

Atualmente, um dos grandes desafios para qualquer desenvolvedor de software é projetar um sistema que reutilize ao máximo elementos de código e de projeto existentes, visando diminuir o tempo e o esforço exigidos na produção do software. Entre as inúmeras formas de possibilitar reuso no contexto do desenvolvimento segundo o paradigma da orientação a objetos, destaca-se a abordagem de frameworks. A grande importância da documentação de software utilizada no processo de desenvolvimento aliada às características de frameworks serviram como motivação para este trabalho. A documentação dentro do processo de desenvolvimento de software não faz parte de uma fase definida, mas ocorre durante toda sua existência, em paralelo com outras fases do ciclo de vida. A abordagem de frameworks dentro deste contexto enfoca o tratamento de templates e definições das características dos artefatos de software (incluindo não somente código mas também produtos de análise, projeto, frameworks, componentes, diagramas, entre outros), facilitando e acelerando o processo de documentação. Um framework, devido a suas características peculiares que serão examinadas e explicitadas no trabalho, contém uma série de informações que podem, além de apoiar a documentação, ser úteis para produção de outros artefatos (por exemplo, planejamentos de teste, scripts de bancos de dados, padrões de codificação, entre outros) do processo de desenvolvimento. Assim, em um processo de desenvolvimento evolutivo, que utiliza a geração de artefatos como recurso, a manutenção pode ser integralmente realizada somente na especificação e não diluída nos artefatos gerados. O objetivo deste trabalho é investigar, propor e desenvolver uma ferramenta de documentação e geração de artefatos de software, denominado FrameworkDoc. O termo documentação de software aqui utilizado se refere a documentação de desenvolvimento de software, incluindo artefatos, arquiteturas, ferramentas entre outros. Serão abordados dois principais aspectos: primeiramente, a geração automática de documentação dentro do processo de desenvolvimento de software e depois a geração de outros artefatos deste processo, a partir das definições de alto nível disponíveis através do framework. Exemplos de aplicações do FrameworkDoc em projetos reais são apresentados. No entanto, os documentos e artefatos de software considerados foram definidos de forma suficientemente genérica para serem aproveitados em outros contextos.

Os requisitos direcionam o desenvolvimento de software porque são cruciais para a sua qualidade. Como conseqüência tanto requisitos funcionais quanto não funcionais devem ser identificados o mais cedo possível e sua elicitação deve ser precisa e completa. Os requisitos funcionais exercem um papel importante uma vez que expressam os serviços esperados pela aplicação. Por outro lado, os requisitos não funcionais estão relacionados com as restrições e propriedades aplicadas ao software. Este trabalho descreve como identificar requisitos não funcionais e seu mapeamento para aspectos. O desenvolvimento de software orientado a aspectos é apontado como a solução para os problemas envolvidos na elicitação e modelagem dos requisitos não funcionais. No modelo orientado a aspectos, o aspecto é considerado o elemento de primeira ordem, onde o software pode ser modelado com classes e aspectos. As classes são comumente usadas para modelar e implementar os requisitos funcionais, já os aspectos são adotados para a modelagem e implementação dos requisitos não funcionais. Desse modo, é proposta a modelagem dos requisitos não funcionais através das fases do ciclo de vida do software, desde as primeiras etapas do processo de desenvolvimento. Este trabalho apresenta o método chamado FRIDA – From RequIrements to Design using Aspects, cujo objetivo é determinar uma forma sistemática para elicitar e modelar tanto os requisitos funcionais quanto os não funcionais, desde as fases iniciais do ciclo de desenvolvimento. Em FRIDA, a elicitação dos requisitos não funcionais é realizada usando-se checklists e léxicos, os quais auxiliam o desenvolvedor a descobrir os aspectos globais – utilizados por toda a aplicação – bem como, os aspectos parciais que podem ser empregados somente a algumas partes da aplicação. O próximo passo consiste na identificação dos possíveis conflitos gerados entre aspectos e como resolvê-los. No método FRIDA, a identificação e resolução de conflitos é tão importante quanto a elicitação de requisitos não funcionais, nas primeiras fases do ciclo de vida do software. Além disso, é descrito como usar a matriz de conflitos para automatizar esse processo sempre que possível. A extração dos aspectos e sua modelagem visual são características muito importantes, suportadas pelo método, porque elas possibilitam a criação de modelos que podem ser reutilizados no futuro. Em FRIDA, é demonstrado como transformar os requisitos em elementos da fase de projeto (classes e aspectos) e como traduzir esses elementos em código. Outra característica do método FRIDA é que a conexão entre diagramas, que pertencem a diferentes fases do processo de desenvolvimento do software, permite um alto nível de rastreabilidade. Em resumo, FRIDA requer que o desenvolvedor migre de uma visão puramente funcional para outra que contemple também os requisitos não funcionais.