mdh.sePublications
Change search
CiteExportLink to record
Permanent link

Direct link
Cite
Citation style
  • apa
  • ieee
  • modern-language-association-8th-edition
  • vancouver
  • Other style
More styles
Language
  • de-DE
  • en-GB
  • en-US
  • fi-FI
  • nn-NO
  • nn-NB
  • sv-SE
  • Other locale
More languages
Output format
  • html
  • text
  • asciidoc
  • rtf
Exploring Sustainable Industrial Software System Development: within the Software Architecture Environment
Mälardalen University, School of Innovation, Design and Engineering. (Embedded Systems Software Engineering)
2009 (English)Licentiate thesis, comprehensive summary (Other academic)
Abstract [en]

This thesis describes how sustainable development definitions can be transposed to the software architecture environment for the industrial software system domain. In a case study, sustainable development concerns from three companies are investigated for their influence on the dimensions of sustainable development: economical, environmental, and social sustainability. Classifying the case study’s concerns, in the thesis’s Software Engineering taxonomy, shows that the software development concerns are in majority and the software architecture concerns surprisingly few. The economical sustainability concerns dominate followed by social sustainability concerns, including both concerns successfully met and concerns to be met.

Sustainable industrial software system development is in the thesis defined as: “Sustainable industrial software system development meets current stakeholders’ needs without compromising the software development organization’s ability to meet the needs of future stakeholders”. Understanding current and future stakeholders concerns is necessary for the formulation of sustainability goals and metrics. Clarifying the interrelationships among stakeholders’ concerns’ impact on business goals and software qualities, in the thesis’s Influencing Factors method, proves to help stakeholders understand their future needs.

Trust is found to be critical for sustainable development. For the establishing of trust between system and system users, the usability quality is vital. To implement usability support in the architecture in the early design phase, reusable architectural responsibilities are created. The reusable architectural responsibilities are integrated into an experience factory and used by the product line system architects, resulting in a return of investment of 25:2.

Place, publisher, year, edition, pages
Västerås: Mälardalens högskola , 2009.
Series
Mälardalen University Press Licentiate Theses, ISSN 1651-9256 ; 107
National Category
Engineering and Technology
Research subject
Computer Science
Identifiers
URN: urn:nbn:se:mdh:diva-6672ISBN: 978-91-86135-36-2 (print)OAI: oai:DiVA.org:mdh-6672DiVA: diva2:232331
Presentation
2009-10-15, Kappa, Mälardalens Högskola, Västerås, 13:00 (English)
Opponent
Supervisors
Projects
Pasas- Analyzing the enterprise-, system-, and software architecture impact of stakeholders’ concerns for profitable industrial software systems
Available from: 2009-08-21 Created: 2009-08-21 Last updated: 2009-11-10Bibliographically approved
List of papers
1. Preparing Usability Supporting Patterns for Industrial Use
Open this publication in new window or tab >>Preparing Usability Supporting Patterns for Industrial Use
2008 (English)In: International Workshop of the Interplay of Usability Evaluation and Software Development (I-USED), Pisa, Italy, 2008, 2008Conference paper, Published paper (Refereed)
Abstract [en]

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.

National Category
Computer Science
Research subject
Computer Science
Identifiers
urn:nbn:se:mdh:diva-6665 (URN)
Available from: 2009-08-21 Created: 2009-08-21 Last updated: 2009-08-21Bibliographically approved
2. Supporting Usability in Product Line Architectures
Open this publication in new window or tab >>Supporting Usability in Product Line Architectures
2009 (English)In: Software Product Lines Conference, SPLC 2009, San Francisco, USA, 2009Conference paper, Published paper (Refereed)
Abstract [en]

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.

Traditionally, usability is achieved in a product by designing according to specific usability guidelines, and then performing user tests. User interface design can be performed separately from software architecture design and prototyping, but user tests cannot be performed before detailed UI design and prototyping. If the user tests discover usability problems leading to required architectural changes, the company would not know about this until two years after the architecture design was complete. This problem was addressed by identifying a collection of 19 well known usability scenarios that require architectural support. In our example, the stakeholders for the product line prioritized three of these scenarios as key product-line scenarios for improving usability. For each of these three chosen product-line scenarios we developed an architectural responsibility pattern that provided support for the scenario. The responsibilities are expressed in terms of architectural requirements with implementation details and rationales. The responsibilities were embodied in a web based tool for the architects.

The two architects for the product line developed a preliminary design and then reviewed their design against the responsibilities supporting the scenarios. The process of review took a day and the architects conservatively estimated that it saved them five weeks of effort later in the project.

 

Identifiers
urn:nbn:se:mdh:diva-6666 (URN)
Available from: 2009-08-21 Created: 2009-08-21 Last updated: 2009-08-21Bibliographically approved
3. A Responsibility-Based Pattern Language forUsability-Supporting Architectural Patterns
Open this publication in new window or tab >>A Responsibility-Based Pattern Language forUsability-Supporting Architectural Patterns
2009 (English)In: EICS 2009, July 14-17, 2009, Pittsburgh, PA, USA, 2009Conference paper, Published paper (Refereed)
Abstract [en]

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.

National Category
Computer Science
Research subject
Computer Science
Identifiers
urn:nbn:se:mdh:diva-6668 (URN)
Available from: 2009-08-21 Created: 2009-08-21 Last updated: 2009-08-21Bibliographically approved
4. Business Sustainability for Software Systems
Open this publication in new window or tab >>Business Sustainability for Software Systems
2008 (English)In: Business Sustainability 2008, Ofir, Portugal, 2008Conference paper, Published paper (Refereed)
Abstract [en]

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

National Category
Computer Science
Research subject
Computer Science
Identifiers
urn:nbn:se:mdh:diva-6664 (URN)
Available from: 2009-08-21 Created: 2009-08-21 Last updated: 2009-08-21Bibliographically approved
5. Software Engineering featuring the Zachman Taxonomy
Open this publication in new window or tab >>Software Engineering featuring the Zachman Taxonomy
2009 (English)Report (Other academic)
Abstract [en]

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.

In this paper we present our software engineering taxonomic scheme, featuring the Zachman Enterprise Architecture taxonomy. The taxonomic scheme classifies software engineering artifacts from the IEEE Software Engineering Book Of Knowledge according to Zachman’s relationship rules and our interpretation of the Zachman taxonomy.

The software engineering taxonomic scheme proved to give useful insights to how customer sites and development sites may interact for fast innovation exemplified with the companies Apple (AppStore) and Google. The scheme also proved to be useful for process analysis which is shown for the Scrum process.

Identifiers
urn:nbn:se:mdh:diva-6670 (URN)
Available from: 2009-08-21 Created: 2009-08-21 Last updated: 2013-12-03Bibliographically approved
6. Guiding Architectural Decisions with the Influencing Factors Method
Open this publication in new window or tab >>Guiding Architectural Decisions with the Influencing Factors Method
2008 (English)In: Working IEEE/IFIP Conference on Software Architecture (WICSA) 2008, 2008Conference paper, Published paper (Refereed)
Abstract [en]

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.

National Category
Computer and Information Science
Research subject
Computer Science
Identifiers
urn:nbn:se:mdh:diva-6661 (URN)10.1109/WICSA.2008.22 (DOI)2-s2.0-49949113018 (Scopus ID)
Available from: 2009-08-21 Created: 2009-08-20 Last updated: 2016-06-03Bibliographically approved
7. Applying the Software Engineering Taxonomy
Open this publication in new window or tab >>Applying the Software Engineering Taxonomy
2009 (English)Report (Other academic)
Publisher
44 p.
Identifiers
urn:nbn:se:mdh:diva-6855 (URN)
Available from: 2009-09-24 Created: 2009-09-24 Last updated: 2013-12-03Bibliographically approved

Open Access in DiVA

fulltext(1577 kB)707 downloads
File information
File name FULLTEXT01.pdfFile size 1577 kBChecksum SHA-512
bbf5b984047aee7a47c6bb76f8a986cabe4cf70f02126d03584a6f610bf0d300a8601f6d32b4e1cd00b9ae0dc0181af47a888433e59693858ebafe86753fee27
Type fulltextMimetype application/pdf

Search in DiVA

By author/editor
Stoll, Pia
By organisation
School of Innovation, Design and Engineering
Engineering and Technology

Search outside of DiVA

GoogleGoogle Scholar
Total: 707 downloads
The number of downloads is the sum of all downloads of full texts. It may include eg previous versions that are now no longer available

Total: 244 hits
CiteExportLink to record
Permanent link

Direct link
Cite
Citation style
  • apa
  • ieee
  • modern-language-association-8th-edition
  • vancouver
  • Other style
More styles
Language
  • de-DE
  • en-GB
  • en-US
  • fi-FI
  • nn-NO
  • nn-NB
  • sv-SE
  • Other locale
More languages
Output format
  • html
  • text
  • asciidoc
  • rtf