A5057124086- Software Engineering Research
- Advanced Software Engineering Methodologies
- Software Engineering Techniques and Practices
- Software System Performance and Reliability
- Service-Oriented Architecture and Web Services
- Open Source Software Innovations
- Software Reliability and Analysis Research
- Logic, programming, and type systems
- Product Development and Customization
- Model-Driven Software Engineering Techniques
- Business Process Modeling and Analysis
- Formal Methods in Verification
- Logic, Reasoning, and Knowledge
- Design Education and Practice
- Real-Time Systems Scheduling
- Innovation Policy and R&D
- Technology Assessment and Management
- Systems Engineering Methodologies and Applications
- Distributed systems and fault tolerance
- Scientific Computing and Data Management
- Human Resource Development and Performance Evaluation
- Web Applications and Data Management
- ERP Systems Implementation and Impact
- Distributed and Parallel Computing Systems
- Software Testing and Debugging Techniques
Carnegie Mellon University
2012-2022
Software Engineering Institute
2011-2022
Save Ellis Island
2014-2015
Stockholm Environment Institute
2014-2015
Instituto Federal do Rio Grande do Norte
2013
Technische Universität Ilmenau
2013
Universidade Federal do Rio Grande do Norte
2013
Centro Universitário Leonardo da Vinci
2013
Lancaster University
2013
Harvard University Press
2013
This lecture maps the concepts and templates explored in this tutorial with well-known architectural prescriptions, including 4+1 approach of Rational Unified Process, Siemens Four Views approach, ANSI/IEEE-1471-2000 recommended best practice for documenting architectures software-intensive systems. The concludes by re-capping highlights tutorial, asking feedback.
The metaphor of technical debt in software development was introduced two decades ago to explain nontechnical stakeholders the need for what we call now "refactoring." As term is being used describe a wide range phenomena, this paper proposes an organization landscape, and introduces papers on contained issue.
Delivering increasingly complex software-reliant systems demands better ways to manage the long-term effects of short-term expedients. The technical debt metaphor is gaining significant traction in agile development community as a way understand and communicate such issues. idea that developers sometimes accept compromises system one dimension (e.g., modularity) meet an urgent demand some other deadline), incur "debt": on which "interest" has be paid "principal" should repaid at point for...
The technical debt metaphor is widely used to encapsulate numerous software quality problems. attractive practitioners as it communicates both and nontechnical audiences that if problems are not addressed, things may get worse. However, unclear whether there practices move this beyond a mere communication mechanism. Existing studies of have largely focused on code metrics small surveys developers. In paper, we report our survey 1,831 participants, primarily engineers architects working in...
Practices designed to expedite the delivery of stakeholder value can paradoxically lead unexpected rework costs that ultimately degrade flow over time. This is especially observable when features are developed based on immediate value, while dependencies may slow down future development efforts neglected. The technical debt metaphor conceptualizes this tradeoff between short-term and long-term value: taking shortcuts optimize in short term incurs debt, analogous financial must be paid off...
The agile software development paradigm and plan-driven approaches each have their strengths shortcomings. former emphasizes rapid, flexible development, while the latter project process infrastructure. Many practitioners, particularly of methods, tend-to view architecture in light side spectrum. They think that architecture-centric methods are too much work, equating them with high-ceremony processes emphasizing document production. But many elements make up a successful approach, including...
As the pace of software delivery increases and technology rapidly changes, organizations seek guidance on how to insure sustainability their development effort. Over past four years running workshops Managing Technical Debt, we have seen increased interest from industry understanding managing technical debt. A better concept debt, approach it, both a theoretical practical perspective is necessary advance its state art practice. In this paper, highlight current confusion in definition...
We compare five industrial software architecture design methods and we extract from their commonalities a general approach. Using this approach, across the artifacts activities they use or recommend, pinpoint similarities differences. Once get beyond great variance in terminology description, find that 5 approaches have lot common match more less "ideal" pattern introduced.
There is growing interest in continuous delivery practices to enable rapid and reliable deployment. While are important, we suggest architectural design decisions equally important for projects achieve goals such integration (CI) build, automated testing reduced deployment-cycle time. Architectural that conflict with deploy ability can impede the team's desired state of deployment may result substantial technical debt. To explore this assertion, interviewed three project teams striving...
Software is being produced so fast that its growth hinders sustainability. Technical debt, which encompasses internal software quality, evolution and maintenance, reengineering, economics, growing such management becoming the dominant driver of engineering progress. It spans life cycle, capitalizes on recent advances in fields as source code analysis, quality measurement, project management. Managing technical debt will become an investment activity applying economic theories. effectively...
This report revises the Attribute-Driven Design (ADD) method that was developed by Carnegie Mellon Software Engineering Institute. The motivation for revising ADD came from practitioners who use and want to be easier learn, understand, apply. The is an approach defining a software architecture in which design process based on quality attribute requirements. follows recursive decomposes system or element applying architectural tactics patterns satisfy its driving requirements. This...
Lean practices use the principle of Little's law to improve flow value end user by eliminating sources waste from a software development process. defines throughput as ratio work in process and cycle time. Increasing (or productivity) requires continuously improving (that is, decreasing) time while ensuring that work-in-process limit doesn't exceed capacity available work. This article shares experiences regarding role architecture plays lean management practices. Release plans give much...
Concretely communicating technical debt and its consequences is of common interest to both researchers software engineers. In the absence validated tools techniques achieve this goal with repeatable results, developers resort ad hoc practices. Most commonly they report using issue trackers or their existing backlog management practices capture track debt. a manual examination 1,264 issues from four open source industry government projects, we identified 109 examples Our study reveals that...
Abstract : The Architecture Tradeoff Analysis Initiative at the Carnegie Mellon Software Engineering Institute (SEl) has developed a number of architecture-centric methods currently in use including SEISM Method (ATAM), SEl Quality Attribute Workshop (QAW), Cost Benefit (CBAM), Active Reviews for Intermediate Designs (ARID), and SE Attribute-Driven Design (ADD) method. Building on our success developing piloting collection software architecture methods, we're now focusing integrating them,...
The output of 18 software architecture evaluations are analyzed to find patterns in the risk themes identified evaluations. major results are: i) A categorization ii) observation that twice as many risks "omission " "commission ". iii) failure a relationship between business and mission goals system from an evaluation system. iv) domain being evaluated associated with development this investigation have application practitioners by suggesting activities on which developers should put greater...