999 resultados para Engenharia de software, Brasil
Resumo:
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.
Resumo:
Este trabalho de conclusão apresenta um método e uma ferramenta para avaliação da maturidade e da capacitação de ambientes de desenvolvimento de software baseado no uso da abordagem Goal/Question/Metric-GQM combinada aos métodos tradicionais de avaliação já existentes para o modelo Capability Maturity Model-CMM. A aplicação deste método através da ferramenta proposta permitirá a organização avaliada estabelecer o grau de conformidade preliminar dos seus processos em relação às exigências do modelo CMM. Esta avaliação poderá ser utilizada como ponto de partida para o estabelecimento de um processo de melhoria. O modelo CMM descreve uma série de estágios de maturidade que são atingidos através da satisfação de metas estabelecidas para áreas-chave do processo de desenvolvimento de software da organização. A evolução deste modelo, chamada de CMMI, Capability Maturity Model Integrated, possibilita que as organizações optem pela forma de implementação do modelo. Esta opção pode se dar através do uso do CMMI em estágios, vertical utilizando os níveis tradicionais do modelo, ou contínua; horizontal baseada nas áreas-chave de processo. Da mesma forma, a avaliação pode ser realizada sobre qualquer modelo escolhido. O modelo GQM descreve uma estrutura hierárquica baseada na existência de metas de melhoria preestabelecidas das quais são extraídas métricas e questões que as satisfazem. O nível de satisfação dessas metas é obtido através da análise das métricas relativas às questões aplicadas ao foco da avaliação Algumas ferramentas para avaliação dos processos relativos ao modelo CMM são apresentadas, tais como o questionário da maturidade e os modelos existentes para a criação de métodos de avaliação, CMM Apraisal Framework-CAF e Apraisal Requirements for CMMI-ARC. O diferencial apresentado é o estabelecimento de métricas objetivas e regras de interpretação dessas para a definição da satisfação de uma determinada área-chave de processo, ACP, do nível 2 do modelo CMMI. Além dessas contribuições vale destacar o estabelecimento de questões adicionais ao questionário da maturidade com o objetivo de capturar essas métricas e a criação de grafos GQM para cada ACP do nível 2 do CMMI. Esses grafos permitem a visualização do relacionamento existente entre cada ACP do nível 2 do CMMI com suas metas, questões e métricas. A aplicação do método e da ferramenta será demonstrada através da utilização de um estudo de caso aplicado na empresa DWA Informática Ltda.
Resumo:
O item não apresenta o texto completo, pois está passando por revisão editorial
Resumo:
Generalized hyper competitiveness in the world markets has determined the need to offer better products to potential and actual clients in order to mark an advantagefrom other competitors. To ensure the production of an adequate product, enterprises need to work on the efficiency and efficacy of their business processes (BPs) by means of the construction of Interactive Information Systems (IISs, including Interactive Multimedia Documents) so that they are processed more fluidly and correctly.The construction of the correct IIS is a major task that can only be successful if the needs from every intervenient are taken into account. Their requirements must bedefined with precision, extensively analyzed and consequently the system must be accurately designed in order to minimize implementation problems so that the IIS isproduced on schedule and with the fewer mistakes as possible. The main contribution of this thesis is the proposal of Goals, a software (engineering) construction process which aims at defining the tasks to be carried out in order to develop software. This process defines the stakeholders, the artifacts, and the techniques that should be applied to achieve correctness of the IIS. Complementarily, this process suggests two methodologies to be applied in the initial phases of the lifecycle of the Software Engineering process: Process Use Cases for the phase of requirements, and; MultiGoals for the phases of analysis and design. Process Use Cases is a UML-based (Unified Modeling Language), goal-driven and use case oriented methodology for the definition of functional requirements. It uses an information oriented strategy in order to identify BPs while constructing the enterprise’s information structure, and finalizes with the identification of use cases within the design of these BPs. This approach provides a useful tool for both activities of Business Process Management and Software Engineering. MultiGoals is a UML-based, use case-driven and architectural centric methodology for the analysis and design of IISs with support for Multimedia. It proposes the analysis of user tasks as the basis of the design of the: (i) user interface; (ii) the system behaviour that is modeled by means of patterns which can combine Multimedia and standard information, and; (iii) the database and media contents. This thesis makes the theoretic presentation of these approaches accompanied with examples from a real project which provide the necessary support for the understanding of the used techniques.
Resumo:
Uma linha de produtos de software (LPS), é um conjunto de produtos que partilham funcionalidades comuns, desenvolvidos de forma sistemática a partir de um conjunto de elementos de software base da LPS. As abordagens de desenvolvimento baseado em LPS revolucionaram a forma como as organizações realizam a engenharia de software. A obtenção de economias de escala, na concepção e distribuição de novos produtos, pela reutilização dos elementos de software base da LPS e instanciação dos variantes respectivos, é um dos principais benefícios na adopção desta abordagem. Numa LPS, a arquitectura de software de referência vai para além da dicotomia desenho/ codificação da arquitectura de software tradicional. A sua documentação, inclui a representação da arquitectura de software da LPS e respectivos pontos de variabilidade, bem como a descrição do processo para instanciação dos produtos. Numa pequena e média empresa (PME), os recursos humanos, técnicos e financeiros são escassos. A viabilidade da implementação de uma LPS adequa-se num contexto de redução de custos operacionais e eficiência do processo de produção dos produtos de software. O objectivo deste trabalho é o desenvolvimento e aplicação de uma metodologia para a gestão e implementação de uma LPS, adequada à realidade de uma PME. As principais contribuições do trabalho incluem: a) uma metodologia para a implementação e gestão de uma LPS adequada a uma PME, que prevê a definição da arquitectura de software da LPS com base num conjunto de produtos já existentes, b) a representação da arquitectura de software de uma LPS, suportado por modelos UML, estendidos através de um perfil UML, baseado em 3+1 perspectivas: dos requisitos, da implementação e dos componentes de execução, sendo que a vista (+1)ou “vista produtos” é uma instanciação das restantes três vistas no contexto particular da LPS ou de um produto, num determinado momento no tempo. A metodologia proposta foi aplicada à solução ARQUO™, uma solução real e em produção em diversas organizações.
Resumo:
Este relatório tem como objetivo apresentar e descrever alguns projetos realizados, metodologias utilizadas e toda a experiência que adquiri durante o meu estágio curricular para finalizar o curso de Mestrado em Engenharia Informática da Universidade da Madeira. O principal objetivo deste estágio foi experienciar um ambiente empresarial e ganhar alguma experiência profissional, algo que é bastante requisitado no mercado de trabalho nos dias de hoje. Neste relatório estão referenciadas algumas das responsabilidades que me foram atribuídas, como a liderança de uma equipa e a apresentação de algumas soluções para certos problemas técnicos, bem como a implementação das mesmas. Serão também caracterizadas e criticadas algumas decisões, procedimentos e metodologias utilizadas pela empresa que afetaram de certa forma o desenvolvimento de software de um ponto de vista geral e o próprio sucesso da empresa. Este relatório poderá servir de exemplo, não só para soluções para um problema técnico semelhante aos que aqui apresentei, mas também demonstrar o resultado de certos procedimentos e metodologias utilizadas na empresa no desenvolvimento de software.
Resumo:
VALENTIM, R. A. M. ; SOUZA NETO, Plácido Antônio de. O impacto da utilização de design patterns nas métricas e estimativas de projetos de software: a utilização de padrões tem alguma influência nas estimativas?. Revista da FARN, Natal, v. 4, p. 63-74, 2006
Resumo:
This study developed software rotines, in a system made basically from a processor board producer of signs and supervisory, wich main function was correcting the information measured by a turbine gas meter. This correction is based on the use of an intelligent algorithm formed by an artificial neural net. The rotines were implemented in the habitat of the supervisory as well as in the habitat of the DSP and have three main itens: processing, communication and supervision
Resumo:
Through the adoption of the software product line (SPL) approach, several benefits are achieved when compared to the conventional development processes that are based on creating a single software system at a time. The process of developing a SPL differs from traditional software construction, since it has two essential phases: the domain engineering - when common and variables elements of the SPL are defined and implemented; and the application engineering - when one or more applications (specific products) are derived from the reuse of artifacts created in the domain engineering. The test activity is also fundamental and aims to detect defects in the artifacts produced in SPL development. However, the characteristics of an SPL bring new challenges to this activity that must be considered. Several approaches have been recently proposed for the testing process of product lines, but they have been shown limited and have only provided general guidelines. In addition, there is also a lack of tools to support the variability management and customization of automated case tests for SPLs. In this context, this dissertation has the goal of proposing a systematic approach to software product line testing. The approach offers: (i) automated SPL test strategies to be applied in the domain and application engineering, (ii) explicit guidelines to support the implementation and reuse of automated test cases at the unit, integration and system levels in domain and application engineering; and (iii) tooling support for automating the variability management and customization of test cases. The approach is evaluated through its application in a software product line for web systems. The results of this work have shown that the proposed approach can help the developers to deal with the challenges imposed by the characteristics of SPLs during the testing process
Resumo:
Formal methods and software testing are tools to obtain and control software quality. When used together, they provide mechanisms for software specification, verification and error detection. Even though formal methods allow software to be mathematically verified, they are not enough to assure that a system is free of faults, thus, software testing techniques are necessary to complement the process of verification and validation of a system. Model Based Testing techniques allow tests to be generated from other software artifacts such as specifications and abstract models. Using formal specifications as basis for test creation, we can generate better quality tests, because these specifications are usually precise and free of ambiguity. Fernanda Souza (2009) proposed a method to define test cases from B Method specifications. This method used information from the machine s invariant and the operation s precondition to define positive and negative test cases for an operation, using equivalent class partitioning and boundary value analysis based techniques. However, the method proposed in 2009 was not automated and had conceptual deficiencies like, for instance, it did not fit in a well defined coverage criteria classification. We started our work with a case study that applied the method in an example of B specification from the industry. Based in this case study we ve obtained subsidies to improve it. In our work we evolved the proposed method, rewriting it and adding characteristics to make it compatible with a test classification used by the community. We also improved the method to support specifications structured in different components, to use information from the operation s behavior on the test case generation process and to use new coverage criterias. Besides, we have implemented a tool to automate the method and we have submitted it to more complex case studies
Resumo:
Software Products Lines (SPL) is a software engineering approach to developing software system families that share common features and differ in other features according to the requested software systems. The adoption of the SPL approach can promote several benefits such as cost reduction, product quality, productivity, and time to market. On the other hand, the SPL approach brings new challenges to the software evolution that must be considered. Recent research work has explored and proposed automated approaches based on code analysis and traceability techniques for change impact analysis in the context of SPL development. There are existing limitations concerning these approaches such as the customization of the analysis functionalities to address different strategies for change impact analysis, and the change impact analysis of fine-grained variability. This dissertation proposes a change impact analysis tool for SPL development, called Squid Impact Analyzer. The tool allows the implementation of change impact analysis based on information from variability modeling, mapping of variability to code assets, and existing dependency relationships between code assets. An assessment of the tool is conducted through an experiment that compare the change impact analysis results provided by the tool with real changes applied to several evolution releases from a SPL for media management in mobile devices
Resumo:
Software Repository Mining (MSR) is a research area that analyses software repositories in order to derive relevant information for the research and practice of software engineering. The main goal of repository mining is to extract static information from repositories (e.g. code repository or change requisition system) into valuable information providing a way to support the decision making of software projects. On the other hand, another research area called Process Mining (PM) aims to find the characteristics of the underlying process of business organizations, supporting the process improvement and documentation. Recent works have been doing several analyses through MSR and PM techniques: (i) to investigate the evolution of software projects; (ii) to understand the real underlying process of a project; and (iii) create defect prediction models. However, few research works have been focusing on analyzing the contributions of software developers by means of MSR and PM techniques. In this context, this dissertation proposes the development of two empirical studies of assessment of the contribution of software developers to an open-source and a commercial project using those techniques. The contributions of developers are assessed through three different perspectives: (i) buggy commits; (ii) the size of commits; and (iii) the most important bugs. For the opensource project 12.827 commits and 8.410 bugs have been analyzed while 4.663 commits and 1.898 bugs have been analyzed for the commercial project. Our results indicate that, for the open source project, the developers classified as core developers have contributed with more buggy commits (although they have contributed with the majority of commits), more code to the project (commit size) and more important bugs solved while the results could not indicate differences with statistical significance between developer groups for the commercial project
Resumo:
There is a growing interest of the Computer Science education community for including testing concepts on introductory programming courses. Aiming at contributing to this issue, we introduce POPT, a Problem-Oriented Programming and Testing approach for Introductory Programming Courses. POPT main goal is to improve the traditional method of teaching introductory programming that concentrates mainly on implementation and neglects testing. POPT extends POP (Problem Oriented Programing) methodology proposed on the PhD Thesis of Andrea Mendonça (UFCG). In both methodologies POPT and POP, students skills in dealing with ill-defined problems must be developed since the first programming courses. In POPT however, students are stimulated to clarify ill-defined problem specifications, guided by de definition of test cases (in a table-like manner). This paper presents POPT, and TestBoot a tool developed to support the methodology. In order to evaluate the approach a case study and a controlled experiment (which adopted the Latin Square design) were performed. In an Introductory Programming course of Computer Science and Software Engineering Graduation Programs at the Federal University of Rio Grande do Norte, Brazil. The study results have shown that, when compared to a Blind Testing approach, POPT stimulates the implementation of programs of better external quality the first program version submitted by POPT students passed in twice the number of test cases (professor-defined ones) when compared to non-POPT students. Moreover, POPT students submitted fewer program versions and spent more time to submit the first version to the automatic evaluation system, which lead us to think that POPT students are stimulated to think better about the solution they are implementing. The controlled experiment confirmed the influence of the proposed methodology on the quality of the code developed by POPT students