https://www.mdu.se/

Usability supporting architectural patterns (USAPs) have been shown to provide developers with useful guidance for producing a software architecture design that supports usability in a laboratory setting. In close collaboration between researchers and software developers in the real world, the concepts were proven useful. However, this process does not scale to industrial development efforts. In particular, development teams need to be able to use USAPs while being distributed world-wide. USAPs also must support legacy or already partially-designed architectures, and when using multiple USAPs there could be a potentially overwhelming amount of information given to the software architects. This paper describes the restructuring of USAPs using a pattern language to simplify the development and use of multiple USAPs. A delivery mechanism is also described that is suitable for industrial-scale adoption of USAPs. The delivery mechanism involves organizing responsibilities into a hierarchy, utilizing a checklist to ensure responsibilities have been considered, and grouping responsibilities in a fashion that both supports use of multiple USAPs simultaneously and also points out reuse possibilities to the architect.

This paper addresses the problem of supporting usability in the early stages of a product line architecture design. The product line used as an example is intended to support a variety of different products each with a radically different user interface. The development cycles for new products varies between three years and five years and usability is valued as an important quality attribute for each product in the line.

Usability-supporting architectural patterns (USAPs) were developed as a way to explicitly connect the needs of architecturally-sensitive usability concerns to the design of software architecture. In laboratory studies, the Cancellation USAP was shown to significantly improve the quality of architecture designs for supporting the ability to cancel a longrunning command, sparking interest from a large industrial organization to develop new USAPs and apply them to their product line architecture design. The challenges of delivering the architectural information contained in USAPs to practicing software architects led to the development of a pattern language for USAPs based on software responsibilities and a web-based tool for evaluating an architecture with respect to those patterns.

Sustainable development of industrial software systems with controllable outcome in terms of cost, schedule and quality despite changes originating from new technology, stakeholders’ concerns, organization, and business goals during long life-times is a challenge. Unruh has argued that numerous barriers to sustainability arise because today’s technological systems were designed and built for permanence and reliability, not change. Sustainability is a characteristic of a process or state that can be maintained at a certain level indefinitely. The implied preference would be for systems to be productive indefinitely, to be “sustainable”. For instance, “sustainable development” would be development of software systems that last indefinitely. Author Michael Pollan has defined an unsustainable system simply as “a practice or process that can’t go on indefinitely because it is destroying the very conditions on which it depends

Software engineering of today must consider organizational- and business issues as well as architectural issues for fast manufacturing of software. The semantics in a taxonomic scheme including organizational-, business- and architecture artifacts would help software engineers define explicit relations between software engineering artifacts at all levels and enable fast and flexible creation of process models for software manufacturing.

The Influencing Factors (IF) method guides the architect through stakeholders’ concerns to architectural decisions in line with current business goals. The result is a set of requirements on software quality attributes and business goals and highlighted trade-offs among software quality attributes and among business goals. The IF method is suitable for sustainable software systems since it allows new concerns, resulting from changes in business goals, stakeholder concerns, technical environment and organization, to be added to existing concerns.