Searcharxiv⌕ Search

arXiv subjects

Mary Shaw

Publications and source records attributed to Mary Shaw.

11 recordsLinked to original sources
arXiv2026

Correctness, confidence, and context: Framing software assurance in the AI age

Software engineering has a complicated relationship with "correctness". We recognize the challenges of full formal rigor as well as many required properties beyond functional correctness. Although we satisfice in practice, we are still stuck in the mindset that we could reason our way to correctness, if only we had enough information. Unfortunately for our hopes of formal rigor, our expectations are shaped by unspoken knowledge that is personal, subjective, qualitative, and largely unavailable. Generative AI has introduced a new dimension to assurance: its foundation is statistical rather than formal. Traditional software engineering establishes confidence through rigorous reasoning, domain knowledge and expert judgment. In contrast, generative AI results are sophisticated predictions, "probably approximately correct". This inherently limits assurances about the results to probabilistic assertions. Further, the nuances that guide human judgment are often tacit or implicit. This knowledge casts only scant shadows into the digital record, so that critical source of knowledge is only faintly represented in AI models. We have many approaches for developing assurances that a software system does what it's expected to do, though most of them focus on code specifications rather than system requirements, let alone the system's fitness for its purpose. We have failed to develop a systematic understanding of the relative merits of the various approaches to assurance. I hope that generative AI will finally force us to tackle this. To that end, I will challenge us to think systematically about our assurance techniques, especially the role of hidden context and the challenges of AI. We need ways to make informed, reasoned choices about cost-effective combinations of approaches to developing confidence in our systems. We call ourselves software engineers. Let's act like engineers.

cs.SE↗
arXiv2026

SE Research is a Complex Ecosystem: Isolated Fixes Keep Failing -- and Systems Thinking Shows Why

The software engineering research community is productive, yet it faces a constellation of challenges: swamped review processes, metric-driven incentives, distorted publication practices, and increasing pressures from AI, scale, and outright scams. These issues are often treated in isolation, yet they arise from deep structural dynamics within the research ecosystem itself and distract us from the larger role of research in society. Meaningful progress requires a holistic system-level view. We sketch such a framework drawing on ideas from complex systems, ecosystems, and theory of change. Reframing SE's challenges through this lens reveals non-linear feedback loops that sustain current dysfunctions, and it helps to identify leverage points for reform. These are less a matter of isolated fixes and more a matter of exploring coordinated sets of fixes that operate across the SE ecosystem

cs.SE↗
arXiv2025

Curating Model Problems for Software Designing

Many disciplines use standard examples for education and to share and compare research results. The examples are rich enough to study from multiple points of view; they are often called model problems. Software design lacks such a community resource. We propose an activity for Designing 2025 in which participants improve some existing model problem descriptions and initiate new ones -- with a focus on use in software design education, plus potential utility in research.

cs.SE↗
arXiv2025

Contrasting to spark creativity in software development teams

Three decades of empirical research in high-performing software development teams provides evidence that creativity can be promoted by an effective, disciplined development culture. This paper describes 'contrasting' as a key driver for creativity; describes creativity moves, tactics used by high-performing teams to produce useful contrasts; and characterizes key development behaviours observed to support a 'culture' of creativity. The empirical research was carried out in a broad range of software development organizations and application domains.

cs.SE↗
arXiv2025

Design Obligations for Software, with Examples from Data Abstraction and Adaptive Systems

Producing a good software design involves not only writing a definition that satisfies the syntax of the chosen language or structural constraints of a design paradigm. It also involves upholding a variety of expectations about the behavior of the system: the semantic expectations. These expectations may apply not only at the code level, but also to more abstract system structures such as software architectures. Such high-level design paradigms provide a vocabulary of components or other constructs and ways to compose those constructs, but not all expressible designs are well-formed, and even well-formed designs may fail to satisfy the expectations of the paradigm. Unfortunately, these expectations are often implicit or documented only informally, so they are challenging to discover, let alone uphold. They may for example, require correct use of complex structures, internal consistency, compliance with external standards, adherence with design principles, etc. Further, the reasons for design decisions that uphold these expectations are often not explicit in the code or other representation of the system. I introduce the idea of 'design obligations', which are constraints on allowable designs within a given design paradigm that help to assure appropriate use of the paradigm. To illustrate this idea, I discuss design obligations for two paradigms: data abstraction and a class of adaptive based on feedback control.

cs.SE↗
arXiv2025

Revisiting Abstractions for Software Architecture and Tools to Support Them

The mid-1990s saw the design of programming languages for software architectures, which define the high-level aspects of software systems including how code components were composed to form full systems. Our paper "Abstractions for Software Architecture and Tools to Support Them" presented a conceptual view of software architecture based on abstractions used in practice to organize software systems, a language that supported these abstractions, and a prototype implementation of this language. By invitation, we reflect on the paper's principal ideas about system-level abstractions, place the work in a historical context of steadily increasing abstraction power in software development languages and infrastructure, and reflect on how progress since the paper's 1995 publication has been influenced, directly or indirectly, by this work. We describe current manifestations of architectural ideas and current challenges. We suggest how the strategy we used to identify and reify architectural abstractions may apply to current opportunities.

cs.SE↗
arXiv2024

tl;dr: Chill, y'all: AI Will Not Devour SE

Social media provide a steady diet of dire warnings that artificial intelligence (AI) will make software engineering (SE) irrelevant or obsolete. To the contrary, the engineering discipline of software is rich and robust; it encompasses the full scope of software design, development, deployment, and practical use; and it has regularly assimilated radical new offerings from AI. Current AI innovations such as machine learning, large language models (LLMs) and generative AI will offer new opportunities to extend the models and methods of SE. They may automate some routine development processes, and they will bring new kinds of components and architectures. If we're fortunate they may force SE to rethink what we mean by correctness and reliability. They will not, however, render SE irrelevant.

cs.SE↗
arXiv2024

Design Spaces and How Software Designers Use Them: a sampler

Discussions of software design often refer to using "design spaces" to describe the spectrum of available design alternatives. This supports design thinking in many ways: to capture domain knowledge, to support a wide variety of design activity, to analyze or predict properties of alternatives, to understand interactions and dependencies among design choices. We present a sampling of what designers, especially software designers, mean when they say "design space" and provide examples of the roles their design spaces serve in their design activity. This shows how design spaces can serve designers as lenses to reduce the overall space of possibilities and support systematic design decision making.

cs.SE↗
arXiv2024

AHA! Strategies for Gaining Insights into Software Design

These patterns describe the strategies I use to find novel or unorthodox insights in the area of software design and research. The patterns are driven by inconsistencies between what we say and what we do, and they provide techniques for finding actionable insights to address these inconsistencies. These insights may help to identify research opportunities; they may stimulate critiques of either research or practice; they may suggest new methods.

cs.SE↗
arXiv2023

Open Design Case Study -- A Crowdsourcing Effort to Curate Software Design Case Studies

Case study-based learning has been successfully integrated into various courses, including software engineering education. In the context of software design courses, the use of case studies often entails sharing of real successful or failed software development. Using examples of real-world case studies allows educators to reinforce the applicability and usefulness of fundamental design concepts, relate the importance of evaluating design trade-offs with respect to stakeholders' requirements, and highlight the importance of upfront design where students that lack industrial experience tend to overlook. However, the use of real-world case studies is not straightforward because 1.) there is a lack of open source repositories for real software design case studies and 2.) even if case studies are available, they are often reported without a standardized format, which may hinder the alignment between the case and the desired learning outcomes. To address the lack of software design case studies for educational purposes, we propose the idea of Open Design Case Study, a repository to crowdsource, curate, and recruit other educators to contribute case studies for teaching software design courses. The platform will also allow educators and students to share, brainstorm, and discuss design solutions based on case studies shared publicly on the repository.

cs.SE↗