Selecting the right method for the right project

The development of information systems is constantly changing. As a background of the change, there is almost a traditional problem about the high failure rates of information systems development (ISD) projects, but it is no longer the only change-driving force. The role of information systems and their strategic significance has increased considerably due digitalization. This has happened also in the areas of business, which have not been traditionally thought as IT-oriented. Furthermore, the new agile development methods have forced ISD clients to take more responsibility for ISD than before. In practice, this means that completely outsourcing ISD is not as sensible nor as simple as before. ISD clients who acquire information systems must be aware of the different ISD methods and be able to compare and choose the most suitable for the business situation and the objectives in question. ISD method selection is rarely studied, and the majority of publications concentrate on different selection criteria relating to the ISD method choice without a clear selection model. Only a few ISD method selection models were found in the literature. Furthermore, the earlier ISD method selection models are restricted by two factors: firstly, the recommendations behind the prior ISD selection models do not correspond to today’s thoughts about the ISD methods; secondly, prior ISD selection models concentrate only on the properties of the ISD pro-jects, and attention is not really given to the business environment or the business to be developed. In a situation like this, it was considered necessary to develop and study an ISD selection framework which takes the business development and business environment into account as well. Furthermore, it was seen as necessary to study both the customer and supplier practices related to the ISD method choice. The objective was to understand the present situation and estimate how the developed ISD selection framework could be utilized in the future. The study was carried out in several stages. Firstly, two unsuccessful ISD projects were studied in the case study, and it was found that the ISD method used in the projects did not correspond to the properties of the business environment in either case. After that, a contingency theory–motivated ISD selection framework was developed, and a systematic literature review was conducted to study earlier ISD method selection criteria and compare them with the developed ISD method selection framework. In the next stage, expert interviews were done. Altogether, 31 ISD experts working on the borderline between the IS sup-plier and client were interviewed and asked their opinions on existing ISD method selection practices by both the client and the supplier. Furthermore, the experts were asked for their opinions on the recommendations of earlier ISD method selection models and on the developed ISD method selection framework. As a result of the study, it can be stated that the developed ISD method framework covers both the previous ISD method selection criteria, which mainly concentrates on ISD project factors, and the business environment factors. Whereas the majority of the interviewed experts considered the developed ISD method selection framework useful, the recommendations of earlier ISD method selection models were regarded as outdated. Furthermore, it was noticed that in IS client organizations, there was almost no discussion about the ISD methods, and in the supplier organizations, the discussion was very rare. Any systematic projectspecific ISD method selection practice had not been perceived in either organizations. Supplier organizations can justify their reasons for favouring a certain ISD method with the bounded rationality, whereas the operation of customer companies doing (or not doing) the ISD method selection seems to be filling the features of functional stupidity. In the future, it is important to study how to plant the ISD method selection as part of the starting stage of the ISD project. In addition, the developed ISD method selection framework should be tested in the practice.Tietojärjestelmien kehittäminen on jatkuvassa murroksessa. Muutoksen taustalla on jo perinteiseksi muodostunut ongelma tietojärjestelmäprojektien epäonnistumisesta, mutta se ei ole enää ainoa syy. Digitalisaation myötä tietojärjestelmien rooli ja strateginen merkitys on kasvanut huomattavasti myös sellaisilla liiketoiminta-alueilla, joita ei ole ajateltu IT-orientoituneina. Lisäksi uudet ketterät tietojärjestelmien kehittämismenetelmät osallistavat tietojärjestelmäprojektien asiakkaat, jotka joutuvat entistä vastuullisempaan asemaan. Käytännössä tämä kaikki merkitsee sitä, että tietojärjestelmien kehittämisen täydellinen ulkoistaminen ei enää ole yhtä mielekästä, eikä myös yhtä yksinkertaista kuin ennen. Tässä tilanteessa myös tietojärjestelmiä hankkivan asiakkaan pitää tietää erilaisista kehittämismenetelmistä ja kyetä vertailemaan ja valitsemaan kyseiseen liiketoimintatilanteeseen ja tavoitteisiin parhaiten sopiva kehittämismenetelmä. Tietojärjestelmien kehittämismenetelmien valintaa on tutkittu vähän ja suurin osa löydetyistä julkaisuista keskittyy listaamaan erilaisia menetelmävalintaan liittyviä kriteerejä. Varsinaisia tietojärjestelmien kehitysmenetelmien valintamalleja on esitetty vain muutamia. Aiempien valintamallien käyttökelpoisuutta rajoittaa kaksi tekijää: ensinnäkin mallien taustalla olevat olettamukset eivät välttämättä täsmää tämän päivän ajatuksiin kehittämismenetelmistä, ja toisekseen valintamallit keskittyvät tietojärjestelmien kehittämisprojektien ominaisuuksiin, kehitettävää liiketoimintaa tai liiketoimintaympäristöä ei aikaisemmissa valintamalleissa juurikaan huomioida. Tilanteen ollessa tämä kehitimme ja tutkimme tietojärjestelmän kehittämismenetelmien valintamallia, joka ottaa huomioon myös samaan aikaan tapahtuvan liiketoiminnan kehittämisen ja liiketoimintaympäristön. Lisäksi tutkimme tietojärjestelmän kehittämismenetelmien valintaan liittyviä käytäntöjä sekä asiakkaan että toimittajan näkökulmasta. Tavoitteena oli ymmärtää menetelmävalinnan nykytilannetta ja arvioida miten valintamallia voisi jatkossa hyödyntää. Tutkimus toteutettiin useammassa vaiheessa. Ensimmäiseksi tapaustutkimuksin tutkittiin kahta epäonnistunutta tietojärjestelmäkehitysprojektia, ja havaittiin että kummassakaan tapauksessa valittu tietojärjestelmän kehittämismalli ei vastannut liiketoimintaympäristön tarpeita. Sen jälkeen kehitimme kontingenssiteoreettisen tietojärjestelmän kehitysmenetelmän valintamallin, jota verrattiin systemaattisella kirjallisuuskatsauksella löydettyihin aikeisempiin valintasuosituksiin. Vertailun jälkeen haastateltiin 31 asiantuntijaa. Haastatteluilla selvitettiin nykyisiä tietojärjestelmän kehitysmenetelmien valintaan liittyviä käytäntöjä, niin tietojärjestelmäasiakkaan kuin toimittajan näkökulmasta. Lisäksi asiantuntijoilta kysyttiin heidän mielipidettään aiempien valintamallien taustalla olevista väittämistä sekä nyt kehitetystä valintamallista. Tulos on, että ehdottamamme kontingessimalli kattaa sekä aiemmat, projektinominaisuuksiin keskittyvät valintakriteerit, että myös liiketoimintaympäristön epävarmuuteen liittyvät tekijät. Suurin osa haastatelluista asiantuntijoista (23 vastaajaa 31 haastatellusta) piti ehdotettua valintamallia käyttökelpoisena. Aiempien valintamallien taustalla olevat väittämät koettiin ajastaan jälkeen jääneiksi. Lisäksi havaittiin, että asiakasyrityksissä keskustelua tietojärjestelmän kehittämismenetelmistä ei käytännössä ollut juuri lainkaan, eikä myöskään suurimmassa osassa toimittajayrityksiä. Mitään säännöllistä projektikohtaista valintakäytäntöä ei kummissakaan yrityksissä oltu havaittu. Haastateltujen asiantuntijoiden mukaan kehittämisprojekteissa kuitenkin pääsääntöisesti käytetään jotain tietojärjestelmän kehittämismenetelmää, ja syyt menetelmän käyttöön vaihtelevat. Toimittajayritysten syyt tietyn menetelmän suosimiseen ovat pääosin perusteltavissa rajoitetulla rationaalisuudella (bounded rationality), kun taas asiakasyritysten toiminta menetelmän valinnassa näyttää täyttävän toiminnallisen typeryyden (functional stupidity) tunnuspiirteet. Jotta kehitetystä mallista tulee asiakasyrityksille hyödyllinen käytännön työkalu, on seuraavaksi syytä tutkia miten tietojärjestelmän kehittämismenetelmän valinta saadaan osaksi projektin käynnistämisvaiheen tehtäviä. Tärkeää on myös testata nyt esitetyn kontingenssimallin toimivuutta käytännön tilanteissa

Project-specific software engineering methods : composition, enactment, and quality assurance

Softwareentwicklungsmethoden beschreiben Best-Practice-Ansätze für die Entwicklung von Softwaresystemen. Damit sind Methoden einfachen Ad-Hoc-Ansätzen überlegen und ihr Einsatz unterstützt die Entwicklung von hochqualitativer Software. Jedoch erfordert der effektive Einsatz von Methoden, drei Dinge: Erstens müssen Methoden auf aktuellen Methodeninhalten basieren, zweitens müssen sie auf den Projektkontext angepasst werden und drittens müssen sie wie vorgeschrieben von dem Projektteam angewendet werden. Ansonsten gefährden veraltete, unangepasste oder falsch angewendete Methoden den Projekterfolg. Während andere Ansätze nur einige dieser Aspekte abdecken, präsentieren wir einen umfassenden, werkzeugbasierten Ansatz, der alle Aspekte des Managements von Softwareentwicklungsmethoden abdeckt. Unser Ansatz ermöglicht die Erstellung von formalen, kompositions-basierten Methodenmodellen. Erstens werden Methodenmodelle aus formalen Methodenbausteinen zusammengesetzt. Diese repräsentieren, aktuelle Methodeninhalte und werden in einer aktualisierbaren Methodenbasis gehalten. Zweitens werden Methodenmodelle projektspezifisch und kontextbasiert komponiert. Drittens wird ihre korrekte Anwendung durch den Einsatz einer Process-Engine sichergestellt. Unsere Proof-Of-Concept-Implementierung demonstriert die Machbarkeit unseres Ansatzes und stellt Werkzeugunterstützung für die Definition von Methodenbausteinen, die konsistente Methodenmodellkomposition und die Ausführung mit Standard-Process-Engines zur Verfügung.Software engineering methods describe structured, repeatable best practice approaches for the engineering of software systems. The project team of a software project enacts a method and applies the described activities. As methods are superior to ad-hoc build and fix approaches, they benefit the creation of high-quality software. However, for the efficient use of methods, first, they need to be based on state of the practice method content, second, they need to be tailored to the project context, and third, they need to be enacted as prescribed. Otherwise, outdated, unsuitable, or wrongly enacted methods can impede the creation of the software system. While other approaches focus on supporting some of these aspects, our approach is a holistic tool-supported approach that covers all of them. It allows creating formally defined composition-based method models. First, method models are composed from formal building blocks that represent method content and are stored in an extensible, updatable repository. Second, they are composed specifically for a project and tailored to its characteristics. Here the novel notion of method patterns is used to guide the composition process. Third, their correct enactment is supported with a process engine. Our proof-of-concept implementation demonstrates the feasibility of the approach. It provides tooling to define building blocks, to compose them to method models consistently, and to execute them with standard process engines.Masud Fazal-BaqaieTag der Verteidigung: 15.09.2016Universität Paderborn, Fakultät für Elektrotechnik, Informatik und Mathematik, Univ., Dissertation, 201

Adaptivity engineering : Modeling and quality assurance for self-adaptive software systems

Moderne Softwareentwicklung nutzt Techniken der Selbstadaptation, um Wartung von Softwaresystemen zu automatisieren und diese somit flexibler und robuster zu gestalten. Allerdings führt die Einführung solcher Techniken zu größeren und komplizierten Softwareentwürfen. Die Konsequenz sind Fehler im Entwurf. In der Literatur werden konstruktive Methoden wie MDE oder Patterns und analytische Methoden wie Testen oder Model Checking vorgeschlagen, um das Komplexitätsproblem zu verringern. Allerdings werden die Techniken der Selbstadaption von solchen Methoden bisher noch wenig unterstützt, d.h. dass es wenige integrierte Ansätze für die explizite Modellierung und Qualitätssicherung von Selbstadaptation gibt. In dieser Arbeit schlagen wir einen integrierten Modellierungs- und Qualitätssicherungsansatz für den Entwurf selbstadaptiver Softwaresysteme vor. Es werden sowohl konstruktive Methoden (z.B. Sprachen) als auch analytische Methoden (z.B. Model Checking) für die Unterstützung der Entwicklung solcher Systeme vorgeschlagen. Beide Typen von Methoden sind in Standardtechniken und Werkzeuge integriert. Im Ergebnis wird der Entwickler in der Modellierung selbstadaptiver Softwaresysteme durch den Einsatz von adaptionsspezifischen Sprachen unterstützt. Durch die dazu passenden Qualitätssicherungsverfahren erhält der Entwickler unmittelbare Rückmeldung über die Qualität seiner Modelle. Somit wird die Entwicklung selbstadaptiver Systeme bereits in frühen Phasen des Entwicklungsprozesses unterstützt, Entwurfsfehler werden vermieden und somit bessere Software gebaut.Modern software engineering introduces self-adaptivity features to perform automatic maintenance and make software systems more flexible and resilient. Unfortunately, introducing the additional self-adaptivity features makes software design bloated and complicated. As a consequence, software design models are often prone to errors. The literature proposes constructive approaches such as MDE, patterns, etc. as well as analytical approaches such as testing or model checking to solve the problem of complexity in general. However, there is no sufficient adaptivity-specific support throughout the engineering process, i.e. no approaches that support the creation of self-adaptivity specification models and their quality assurance. In this thesis, we will propose an integrated modeling and quality assurance environment for designing self-adaptive software systems. Therefore, we will propose constructive methods (e.g., languages) and analytical methods (e.g., model-checking) to support the engineering of these systems. Both types of methods are integrated into standard software engineering techniques and tools. As a result, the designer is supported in modeling self-adaptive software systems using concern-specific languages and receives immediate feedback about the quality of his models. This way, software engineering for self-adaptive systems is getting supported starting at the early design phase leading to less errors produced, and thus, to better software, overall.Tag der Verteidigung: 26.09.2013Paderborn, Univ., Diss., 201