Spelling suggestions: "subject:"8oftware anevolution"" "subject:"8oftware arevolution""
71 |
Automatic Visualization of the Version history of a Software System in Three DimensionsAsokan, Ramya 15 April 2004 (has links)
Software changes constantly and continuously. It is often beneficial to record the progressive changes made to software, so that when any problems arise, it is possible to identify the change that might have caused the problem. Also, recording these changes enables recovery of the software as it was at any point of time. A version control system is used to track modifications to software. Version control systems (VCS) display when and where a change was made. In the case of multiple developers working on the same software system, version control systems also record which developer was responsible for the change. RCS, SCCS and CVS are examples of such version control systems, and they usually have a command-line interface. The widespread use of CVS has however given rise to a host of "CVS clients", which provide a two-dimensional graphical interface to CVS. While working with a version control system in two dimensions is a definite improvement over traditional command line interfaces, it is still not sufficient to display all the necessary information in a single view. Using three dimensions to display the information from a version control system like CVS is an effective and efficient way to represent multiple attributes in a single view. There are many advantages to using a third dimension for visualizing the version history and evolution of software. A three-dimensional visualization tool has been developed to provide insights into the structure and characteristics of the history of a software system. It demonstrates the benefits of three-dimensional visualization and illustrates a framework that can be used to automatically derive information from a version control system. / Master of Information Systems
|
72 |
Integrated Management of Variability in Space and Time in Software FamiliesSeidl, Christoph 14 March 2017 (has links) (PDF)
Software Product Lines (SPLs) and Software Ecosystems (SECOs) are approaches to capturing families of closely related software systems in terms of common and variable functionality (variability in space). SPLs and especially SECOs are subject to software evolution to adapt to new or changed requirements resulting in different versions of the software family and its variable assets (variability in time). Both dimensions may be interconnected (e.g., through version incompatibilities) and, thus, have to be handled simultaneously as not all customers upgrade their respective products immediately or completely. However, there currently is no integrated approach allowing variant derivation of features in different version combinations.
In this thesis, remedy is provided in the form of an integrated approach making contributions in three areas: (1) As variability model, Hyper-Feature Models (HFMs) and a version-aware constraint language are introduced to conceptually capture variability in time as features and feature versions. (2) As variability realization mechanism, delta modeling is extended for variability in time, and a language creation infrastructure is provided to devise suitable delta languages. (3) For the variant derivation procedure, an automatic version selection mechanism is presented as well as a procedure to derive large parts of the application order for delta modules from the structure of the HFM. The presented integrated approach enables derivation of concrete software systems from an SPL or a SECO where both features and feature versions may be configured.
|
73 |
Integrated Management of Variability in Space and Time in Software FamiliesSeidl, Christoph 22 February 2016 (has links)
Software Product Lines (SPLs) and Software Ecosystems (SECOs) are approaches to capturing families of closely related software systems in terms of common and variable functionality (variability in space). SPLs and especially SECOs are subject to software evolution to adapt to new or changed requirements resulting in different versions of the software family and its variable assets (variability in time). Both dimensions may be interconnected (e.g., through version incompatibilities) and, thus, have to be handled simultaneously as not all customers upgrade their respective products immediately or completely. However, there currently is no integrated approach allowing variant derivation of features in different version combinations.
In this thesis, remedy is provided in the form of an integrated approach making contributions in three areas: (1) As variability model, Hyper-Feature Models (HFMs) and a version-aware constraint language are introduced to conceptually capture variability in time as features and feature versions. (2) As variability realization mechanism, delta modeling is extended for variability in time, and a language creation infrastructure is provided to devise suitable delta languages. (3) For the variant derivation procedure, an automatic version selection mechanism is presented as well as a procedure to derive large parts of the application order for delta modules from the structure of the HFM. The presented integrated approach enables derivation of concrete software systems from an SPL or a SECO where both features and feature versions may be configured.:I. Context and Preliminaries
1. The Configurable TurtleBot Driver as Running Example
1.1. TurtleBot: A Domestic Service Robot
1.2. Configurable Driver Functionality
1.3. Software Realization Artifacts
1.4. Development History of the Driver Software
2. Families of Variable Software Systems
2.1. Variability
2.1.1. Variability in Space and Time
2.1.2. Internal and External Variability
2.2. Manifestations of Configuration Knowledge
2.2.1. Variability Models
2.2.2. Variability Realization Mechanisms
2.2.3. Variability in Realization Assets
2.3. Types of Software Families
2.3.1. Software Product Lines
2.3.2. Software Ecosystems
2.3.3. Comparison of Software Product Lines and Software Ecosystems
3. Fundamental Approaches and Technologies of the Thesis
3.1. Model-Driven Software Development
3.1.1. Metamodeling Levels
3.1.2. Utilizing Models in Generative Approaches
3.1.3. Representation of Languages using Metamodels
3.1.4. Changing the Model-Representation of Artifacts
3.1.5. Suitability of Model-Driven Software Development
3.2. Fundamental Variability Management Techniques of the Thesis
3.2.1. Feature Models as Variability Models
3.2.2. Delta Modeling as Variability Realization Mechanism
3.2.3. Variant Derivation Process of Delta Modeling with Feature Models
3.3. Constraint Satisfaction Problems
3.4. Scope
3.4.1. Problem Statement
3.4.2. Requirements
3.4.3. Assumptions and Boundaries
II. Integrated Management of Variability in Space and Time
4. Capturing Variability in Space and Time with Hyper-Feature Models
4.1. Feature Models Cannot Capture Variability in Time
4.2. Formal Definition of Feature Models
4.3. Definition of Hyper-Feature Models
4.4. Creation of Hyper-Feature Model Versions
4.5. Version-Aware Constraints to Represent Version Dependencies and Incompatibilities
4.6. Hyper-Feature Models are a True Extension to Feature Models
4.7. Case Study
4.8. Demarcation from Related Work
4.9. Chapter Summary
5. Creating Delta Languages Suitable for Variability in Space and Time
5.1. Current Delta Languages are not Suitable for Variability in Time
5.2. Software Fault Trees as Example of a Source Language
5.3. Evolution Delta Modules as Manifestation of Variability in Time
5.4. Automating Delta Language Generation
5.4.1. Standard Delta Operations Realize Usual Functionality
5.4.2. Custom Delta Operations Realize Specialized Functionality
5.5. Delta Language Creation Infrastructure
5.5.1. The Common Base Delta Language Provides Shared Functionality for all Delta Languages
5.5.2. Delta Dialects Define Delta Operations for Custom Delta Languages
5.5.3. Custom Delta Languages Enable Variability in Source Languages
5.6. Case Study
5.7. Demarcation from Related Work
5.8. Chapter Summary
6. Deriving Variants with Variability in Space and Time
6.1. Variant Derivation Cannot Handle Variability in Time
6.2. Associating Features and Feature Versions with Delta Modules
6.3. Automatically Select Versions to Ease Configuration
6.4. Application Order and Implicitly Required Delta Modules
6.4.1. Determining Relevant Delta Modules
6.4.2. Forming a Dependency Graph of Delta Modules
6.4.3. Performing a Topological Sorting of Delta Modules
6.5. Generating Variants with Versions of Variable Assets
6.6. Case Study
6.7. Demarcation from Related Work
6.8. Chapter Summary
III. Realization and Application
7. Realization as Tool Suite DeltaEcore
7.1. Creating Delta Languages
7.1.1. Shared Base Metamodel
7.1.2. Common Base Delta Language
7.1.3. Delta Dialects
7.2. Specifying a Software Family with Variability in Space and Time
7.2.1. Hyper-Feature Models
7.2.2. Version-Aware Constraints
7.2.3. Delta Modules
7.2.4. Application-Order Constraints
7.2.5. Mapping Models
7.3. Deriving Variants
7.3.1. Creating a Configuration
7.3.2. Collecting Delta Modules
7.3.3. Ordering Delta Modules
7.3.4. Applying Delta Modules
8. Evaluation
8.1. Configurable TurtleBot Driver Software
8.1.1. Variability in Space
8.1.2. Variability in Time
8.1.3. Integrated Management of Variability in Space and Time
8.2. Metamodel Family for Role-Based Modeling and Programming Languages
8.2.1. Variability in Space
8.2.2. Variability in Time
8.2.3. Integrated Management of Variability in Space and Time
8.3. A Software Product Line of Feature Modeling Notations and Constraint Languages
8.3.1. Variability in Space
8.3.2. Variability in Time
8.3.3. Integrated Management of Variability in Space and Time
8.4. Results and Discussion
8.4.1. Results and Discussion of RQ1: Variability Model
8.4.2. Results and Discussion of RQ2: Variability Realization Mechanism
8.4.3. Results and Discussion of RQ3: Variant Derivation Procedure
9. Conclusion
9.1. Discussion
9.1.1. Supported Evolutionary Changes
9.1.2. Conceptual Representation of Variability in Time
9.1.3. Perception of Versions as Incremental
9.1.4. Version Numbering Schemes
9.1.5. Created Delta Languages
9.1.6. Scalability of Approach
9.2. Possible Future Application Areas
9.2.1. Extend to Full Software Ecosystem Feature Model
9.2.2. Model Software Ecosystems
9.2.3. Extract Hyper-Feature Model Versions and Record Delta Modules
9.2.4. Introduce Metaevolution Delta Modules
9.2.5. Support Incremental Reconfiguration
9.2.6. Apply for Evolution Analysis and Planning
9.2.7. Enable Evolution of Variable Safety-Critical Systems
9.3. Contribution
9.3.1. Individual Contributions
9.3.2. Handling Updater Stereotypes
IV. Appendix
A. Delta Operation Generation Algorithm
B. Delta Dialects
B.1. Delta Dialect for Java
B.2. Delta Dialect for Eclipse Projects
B.3. Delta Dialect for DocBook Markup
B.4. Delta Dialect for Software Fault Trees
B.5. Delta Dialect for Component Fault Diagrams
B.6. Delta Dialect for Checklists
B.7. Delta Dialect for the Goal Structuring Notation
B.8. Delta Dialect for EMF Ecore
B.9. Delta Dialect for EMFText Concrete Syntax Files
|
74 |
Multilayered analysis of co-development of business information systemsAram, Michael, Neumann, Gustaf 01 July 2015 (has links) (PDF)
Business information systems (BIS) comprise technological (e.g. programs), informational (e.g. content) and social artifacts (e.g. collaboration structures). Typically, such systems are constantly and collectively developed (co-developed) further by a variety of individuals within the organization. By recognizing these varying types of actors (concerning their goals, technical expertise and language means) and their predominantly developed artifact type, one can distinguish two types of subsystems: technical subsystems wherein the development of the system behavior is conducted by software developers; and business subsystems dominated by end-users developing informational artifacts. So far, co-development structures within and between these subsystems are not well understood, especially the aspect that - potentially driven by appropriate measures such as the provision of domain-specific languages - co-development might shift between these subsystems.
This paper presents an approach for characterizing the co-development of real-world BIS with respect to direct participation from different kinds of contributors. This multilayered approach allows us to analyze the co-development with programming languages, domain-specific languages and end-user tools. The approach is suited to assess the direct participation of individuals from different subsystems in the development of evolving BIS. We focus on the intersection of these subsystems, present appropriate metrics and a multilayered analysis scheme. Contributions to artifacts are analyzed using social network analysis to detect structural properties of continuous co-development.
The application to Learn@WU, a real-world BIS, demonstrates how end-user enabling technologies have shifted the co-development effort of the system from a small group of developers to a several orders of magnitude larger group of contributors. We observed an increase of direct participation over time on both informational and executable artifacts, while the number of technical experts was more or less constant.
Our approach may act as a trigger for the application and further development of rigorous instruments for assessing co-development of BIS. (authors' abstract)
|
75 |
Gestion autonomique d'applications dynamiques sûres et résilientes / Autonomic Management of Reliable and Resilient Dynamic ApplicationsCalmant, Thomas 19 October 2015 (has links)
Les architectures orientées services (SOA) sont considérées comme le moyen le plus avancé pour réaliser et intégrer rapidement des applications modulaires et flexibles.Dans ce domaine, les plates-formes SOA à disposition des développeurs et des architectes de produits logiciels sont multiples; les deux plus évoluées d'entre elles étant SCA et OSGi.Une application s'appuyant sur l'une de ces plates-formes peut ainsi être assemblée avec le minimum de composants nécessaires à la réalisation de ses tâches, afin de réduire sa consommation de ressources et d'augmenter sa maintenabilité.De plus, ces plates-formes autorisent l'ajout de composants greffons qui n'étaient pas connus lors des phases initiales de la réalisation du produit.Elles permettent ainsi de mettre à jour, d'étendre et d'adapter continuellement les fonctionnalités du produit de base ou des services techniques nécessaires à sa mise en production, sans interruption de service.Ces capacités sont notamment utilisées dans le cadre du paradigme DevOps et, plus généralement, pour mettre en œuvre le déploiement continu d'artefacts.Cependant, l'extensibilité offerte par ces plates-formes peut diminuer la fiabilité globale du système: une tendance forte pour développer un produit est l'assemblage de composants provenant de tierces-parties. De tels composants peuvent être d'une qualité inconnue voire douteuse.En cas d'erreur, de détérioration des performances, etc., il est difficile de diagnostiquer les composants ou combinaisons de composants incriminés.Il devient indispensable pour le producteur d'un logiciel de déterminer la responsabilité des différents composants impliqués dans un dysfonctionnement.Cette thèse a pour objectif de fournir une plate-forme, Cohorte, permettant de concevoir et d'exécuter des produits logiciels extensibles et résilients aux dysfonctionnements d'extensions non qualifiées.Les composants de tels produits pourront être développés dans différents langages de programmation et être déployés (ajout, mise à jour et retrait) en continu et sans interruption de service.Notre proposition adopte pour principe d'isoler les composants considérés comme instables ou peu sûrs.Le choix des composants à isoler peut être décidé par l'équipe de développement et l'équipe opérationnelle, à partir de leur expertise, ou bien déterminé à partir d'une combinaison d'indicateurs.Ces derniers évoluent au cours du temps pour refléter la fiabilité des composants.Par exemple, des composants peuvent être considérés fiables après une période de quarantaine; une mise à jour peut entraîner la dégradation de leur stabilité, etc..Par conséquent, il est indispensable de remettre en cause les choix initiaux dans l'isolation des composants afin, dans le premier cas, de limiter le coup des communications entre composants et, dans le deuxième cas, de maintenir le niveau de fiabilité du noyau critique du produit. / Service-Oriented architectures (SOA) are considered the most advanced way to develop and integrate modular and flexible applications.There are many SOA platforms available for software developers and architects; the most evolved of them being SCA and OSGi.An application based on one of these platforms can be assembled with only the components required for the execution of its tasks, which helps decreasing its resource consumption and increasing its maintainability.Furthermore, those platforms allow adding plug-ins at runtime, even if they were not known during the early stages of the development of the application.Thus, they allow updating, extending and adapting the features of the base product or of the technical services required for its execution, continuously and without outage.Those capabilities are applied in the DevOps paradigm and, more generally, to implement the continuous deployment of artifacts.However, the extensibility provided by those platforms can decrease the overall reliability of the system: a strong tendency in software development is the assembly of third-parties components.Such components may be of unknown or even questionable quality.In case of error, deterioration of performance, ... it is difficult to identify the implicated components or combinations of components.It becomes essential for the software producer to determine the responsibility of the various components involved in a malfunction.This thesis aims to provide a platform, Cohorte, to design and implement scalable software products, resilient to malfunctions of unqualified extensions.The components of such products may be developed in various programming languages and be deployed continuously (adding, updating and withdrawal) and without interruption of service.Our proposal adopts the principle of isolating the components considered unstable or insecure.The choice of the components to be isolated may be decided by the development team and the operational team, from their expertise, or determined from a combination of indicators.The latters evolve over time to reflect the reliability of components.For example, components can be considered reliable after a quarantine period; an update may result in deterioration of stability, ...Therefore, it is essential to question the initial choices in isolating components to limit, in the first case, the scope of communications between components and, in the second case, to maintain the reliability of the critical core of the product.
|
76 |
Evolução de software baseada em avaliação de arquiteturas. / Software evolution based on architecture evaluation.Pontes, Danielle Pompeu Noronha 16 March 2012 (has links)
Este trabalho discorre sobre o estudo da utilização do método de avaliação ATAM como referência para um roteiro para evolução arquitetural. O estudo apresentado está dividido em duas partes: a elaboração de um roteiro para evolução de software e a aplicação do roteiro em um ambiente real de um sistema para automação de linhas aéreas. O objetivo é avaliar o uso do método de avaliação de arquitetura para direcionar a evolução do software. As diretrizes geradas neste trabalho orientam as ações a serem tomadas com base em evidências obtidas pela avaliação, possibilitando ao software que exiba os atributos de qualidade desejados. / This paper discusses the study of the use of ATAM evaluation method as a reference to a roadmap for architectural evolution. The present study is divided into two parts: the preparation of a roadmap for software development and implementation of the roadmap in a real environment of a system for automation of airlines. The goal is to evaluate the use of architecture evaluation method to direct the evolution of software. The guidelines generated in this work have guided the actions to be taken based on evidence obtained by the evaluation, enabling the software that displays the desired quality attributes.
|
77 |
Understanding and automating application-level caching / Entendendo e automatizando cache a nível de aplicaçãoMertz, Jhonny Marcos Acordi January 2017 (has links)
O custo de serviços na Internet tem encorajado o uso de cache a nível de aplicação para suprir as demandas dos usuários e melhorar a escalabilidade e disponibilidade de aplicações. Cache a nível de aplicação, onde desenvolvedores manualmente controlam o conteúdo cacheado, tem sido adotada quando soluções tradicionais de cache não são capazes de atender aos requisitos de desempenho desejados. Apesar de sua crescente popularidade, este tipo de cache é tipicamente endereçado de maneira ad-hoc, uma vez que depende de detalhes específicos da aplicação para ser desenvolvida. Dessa forma, tal cache consiste em uma tarefa que requer tempo e esforço, além de ser altamente suscetível a erros. Esta dissertação avança o trabalho relacionado a cache a nível de aplicação provendo uma compreensão de seu estado de prática e automatizando a identificação de conteúdo cacheável, fornecendo assim suporte substancial aos desenvolvedores para o projeto, implementação e manutenção de soluções de caching. Mais especificamente, este trabalho apresenta três contribuições: a estruturação de conhecimento sobre caching derivado de um estudo qualitativo, um levantamento do estado da arte em abordagens de cache estáticas e adaptativas, e uma técnica que automatiza a difícil tarefa de identificar oportunidades de cache O estudo qualitativo, que envolveu a investigação de dez aplicações web (código aberto e comercial) com características diferentes, permitiu-nos determinar o estado de prática de cache a nível de aplicação, juntamente com orientações práticas aos desenvolvedores na forma de padrões e diretrizes. Com base nesses padrões e diretrizes derivados, também propomos uma abordagem para automatizar a identificação de métodos cacheáveis, que é geralmente realizado manualmente por desenvolvedores. Tal abordagem foi implementada como um framework, que pode ser integrado em aplicações web para identificar automaticamente oportunidades de cache em tempo de execução, com base na monitoração da execução do sistema e gerenciamento adaptativo das decisões de cache. Nós avaliamos a abordagem empiricamente com três aplicações web de código aberto, e os resultados indicam que a abordagem é capaz de identificar oportunidades de cache adequadas, melhorando o desempenho das aplicações em até 12,16%. / Latency and cost of Internet-based services are encouraging the use of application-level caching to continue satisfying users’ demands, and improve the scalability and availability of origin servers. Application-level caching, in which developers manually control cached content, has been adopted when traditional forms of caching are insufficient to meet such requirements. Despite its popularity, this level of caching is typically addressed in an adhoc way, given that it depends on specific details of the application. Furthermore, it forces application developers to reason about a crosscutting concern, which is unrelated to the application business logic. As a result, application-level caching is a time-consuming and error-prone task, becoming a common source of bugs. This dissertation advances work on application-level caching by providing an understanding of its state-of-practice and automating the decision regarding cacheable content, thus providing developers with substantial support to design, implement and maintain application-level caching solutions. More specifically, we provide three key contributions: structured knowledge derived from a qualitative study, a survey of the state-of-the-art on static and adaptive caching approaches, and a technique and framework that automate the challenging task of identifying cache opportunities The qualitative study, which involved the investigation of ten web applications (open-source and commercial) with different characteristics, allowed us to determine the state-of-practice of application-level caching, along with practical guidance to developers as patterns and guidelines to be followed. Based on such patterns and guidelines derived, we also propose an approach to automate the identification of cacheable methods, which is often manually done and is not supported by existing approaches to implement application-level caching. We implemented a caching framework that can be seamlessly integrated into web applications to automatically identify and cache opportunities at runtime, by monitoring system execution and adaptively managing caching decisions. We evaluated our approach empirically with three open-source web applications, and results indicate that we can identify adequate caching opportunities by improving application throughput up to 12.16%. Furthermore, our approach can prevent code tangling and raise the abstraction level of caching.
|
78 |
Evolução de software baseada em avaliação de arquiteturas. / Software evolution based on architecture evaluation.Danielle Pompeu Noronha Pontes 16 March 2012 (has links)
Este trabalho discorre sobre o estudo da utilização do método de avaliação ATAM como referência para um roteiro para evolução arquitetural. O estudo apresentado está dividido em duas partes: a elaboração de um roteiro para evolução de software e a aplicação do roteiro em um ambiente real de um sistema para automação de linhas aéreas. O objetivo é avaliar o uso do método de avaliação de arquitetura para direcionar a evolução do software. As diretrizes geradas neste trabalho orientam as ações a serem tomadas com base em evidências obtidas pela avaliação, possibilitando ao software que exiba os atributos de qualidade desejados. / This paper discusses the study of the use of ATAM evaluation method as a reference to a roadmap for architectural evolution. The present study is divided into two parts: the preparation of a roadmap for software development and implementation of the roadmap in a real environment of a system for automation of airlines. The goal is to evaluate the use of architecture evaluation method to direct the evolution of software. The guidelines generated in this work have guided the actions to be taken based on evidence obtained by the evaluation, enabling the software that displays the desired quality attributes.
|
79 |
Analysis of cross-system porting and porting errors in software projectsRay, Baishakhi 11 November 2013 (has links)
Software forking---creating a variant product by copying and modifying an existing project---is often considered an ad hoc, low cost alternative to principled product line development. To maintain forked projects, developers need to manually port existing features or bug-fixes from one project to another. Such manual porting is not only tedious but also error-prone. When the contexts of the ported code vary, developers often have to adapt the ported code to fit its surroundings. Faulty adaptations or inconsistent updates of the ported code could potentially introduce subtle inconsistencies in the codebase. To build a deeper understanding to cross-system porting and porting related errors, this dissertation investigates: (1) How can we identify ported code from software version histories? (2) What is the overhead of cross-system porting required to maintain forked projects? (3) What is the extent and characteristics of porting errors that occur in practice? and (4) How can we detect and characterize potential porting errors? As a first step towards assessing the overhead of cross-system porting, we implement REPERTOIRE, a tool to analyze repeated work of cross-system porting across peer projects. REPERTOIRE can detect ported edits between program patches with high accuracy of 94% precision and 84% recall. Using REPERTOIRE, we study the temporal, spatial, and developer dimensions of cross-system porting using 18 years of parallel evolution history of the BSD product family. Our study finds that cross-system porting happens periodically and the porting rate does not necessarily decrease over time. The upkeep work of porting changes from peer projects is significant and currently, porting practice seems to heavily depend on developers doing their porting job on time. Analyzing version histories of Linux and FreeBSD, we derive five categories of porting errors, including incorrect control- and data-flow, code redundancy, and inconsistent identifier and token renamings. Leveraging this categorization, we design a static control- and data-dependence analysis technique, SPA, to detect and characterize porting inconsistencies. SPA detects porting inconsistencies with 65% to 73% precision and 90% recall, and identify inconsistency types with 58% to 63% precision and 92% recall on average. In a comparison with two existing error detection tools, SPA outperforms them with 14% to 17% better precision. / text
|
80 |
The traceable lifecycle modelNadon, Robert Gerard 01 August 2011 (has links)
Software systems today face many challenges that were not even imagined decades prior. Challenges including the need to evolve at a very high rate, lifecycle phase drift or erosion, inability to prevent the butterfly effect where the slightest change causes unimaginable side effects throughout the system, lack of discipline to define metrics and use measurement to drive operations, and no "silver bullet" or single solution to solve all the problems of every domain, just to name a few. This is not to say that the issues stated above are the only problems. In fact, it would be impossible to list all possible problems--software itself is infinitely flexible bounded only by the human imagination. These are just a portion of the primary challenges today's software engineer faces. There have been attempts throughout the history of software to resolve each one of these challenges. There have been those who tried to tackle them individually, simultaneously, as well as various combinations of them at one time. One such method was to define and encapsulate the various phases within software, which has come to be called a software lifecycle or lifecycle model. Another area of recent research has lead to the hypothesis that many of these challenges can be resolved or at least facilitated through proper traceability methods. Virtually none of today's software components are completely derived from scratch. Rather, code reuse and software evolution become a large portion of the software engineer's duties. As Vance Hilderman at HighRely puts it, "Research has shown that proper traceability is vital. For high quality and safety-critical engineering development efforts however, traceability is a cornerstone not just for achieving success, but to proving it as well." So if software is not derived from scratch, having the traceability to know about its origination is invaluable. Given today's struggles, what is in store for the future software engineer? This paper is an attempt to quantify and answer (or at least project a possibility) that involves a new mindset and a new lifecycle model or structure change that may assist in tackling some of the above referenced issues. / text
|
Page generated in 0.0895 seconds