**4. Quality driven development - Quality model as master plan of information systems**

Given the view on quality requirements constituting the core of requirements for an information system, an endeavor to fulfill them must also be the core process in system development. During the last ten years the software developer community has seen a rise of different approaches characterized by the word "driven". The experiences in case studies (e.g. Finne, 2011) using the comprehensive model suggest introducing still another approach that could be called simply "quality driven development". It does not only mean that quality design and implementation must be a truly integral part of software development that cannot be given up. It means raising the quality modeling from the role of being just a separate component to the status of an umbrella like driving force. If stakeholders in the end want a quality system, quality is also the issue to start with. All other goals and decisions should be subordinate to it and all other design elements in line with quality design. In this sense quality drives the whole development process, not only for example, architecting. And if quality is understood as realization of a set of desired and most essential system-context relationships, then a quality model can be seen having a DNA-like role and carrying the "genetic information" of system.

In an era that pursues agility it is often feared that the introduction of extra models cause too much overhead to development work in terms of calendar time, money and other resources that are badly needed to address more fundamental challenges. But what can be more fundamental than capturing, prioritizing and realizing core system requirements. Figure 11

Fig. 10. Graphical representation of coverage attribute model

**systems** 

"genetic information" of system.

**4. Quality driven development - Quality model as master plan of information** 

Given the view on quality requirements constituting the core of requirements for an information system, an endeavor to fulfill them must also be the core process in system development. During the last ten years the software developer community has seen a rise of different approaches characterized by the word "driven". The experiences in case studies (e.g. Finne, 2011) using the comprehensive model suggest introducing still another approach that could be called simply "quality driven development". It does not only mean that quality design and implementation must be a truly integral part of software development that cannot be given up. It means raising the quality modeling from the role of being just a separate component to the status of an umbrella like driving force. If stakeholders in the end want a quality system, quality is also the issue to start with. All other goals and decisions should be subordinate to it and all other design elements in line with quality design. In this sense quality drives the whole development process, not only for example, architecting. And if quality is understood as realization of a set of desired and most essential system-context relationships, then a quality model can be seen having a DNA-like role and carrying the

In an era that pursues agility it is often feared that the introduction of extra models cause too much overhead to development work in terms of calendar time, money and other resources that are badly needed to address more fundamental challenges. But what can be more fundamental than capturing, prioritizing and realizing core system requirements. Figure 11 shows how the creation and use of quality model elements are positioned in relation to objectoriented software development process (as presented by Jacobson et al., 1999).

Fig. 11. Quality modeling in relation to object-oriented development process

Awareness of context as well as perspectives and views of actors who participate in system development is mandatory in any kind of development approach. IS, the technical artifact, must always be designed. Further, no system exists separate from requirements that are sometimes conflicting and need to be prioritized. Use cases and scenarios are important stuff even in agile methodologies. Finally every system must be tested, assessed and compared to requirements. In these respects quality modeling does not bring any extra burden to the picture. The point in quality driven development is that quality of an information system is understood to be in first place determined by the existence and intensity of desired system-context relationships and consequently as well defined and measured in terms of these relationships. The quality meta-model, presented in previous section, provides a template for designing the relationships and relating the resulting model to other models needed in system development process. The point is further that a system specific quality model is the arch-model in system development and never left out of sight,

Quality Model – Master Plan and DNA of an Information System 147

would guide in focusing on the most relevant features of environment with respect to

After inception phase the overall quality design can start. It consists of creating a prioritized system specific set of domains (areas of concern) and quality attributes out of known alternatives. The results of inception phase together with the initial overall quality design form a kind of sketch of the target system in relation to context. In one of the case studies actors were given a large combined selection of domains and attributes and asked to prioritize them. This was found to be difficult for some informants because of too many items to deal with. Therefore, in the following case studies domain collection was separated from the "palette" and actors were asked to prioritize the domains (step 3) and attributes separately. During overall quality design conflicts may arise and a method for solving them must be found.

Case study observations suggest that after letting actors prioritize domains the most useful and productive step is eliciting positive and negative facts (step 4) indicating existence or the lack of quality inside each prioritized domain. This starts the detailed quality design. In the meta-model these facts are called "indicators" and they constitute an important part of individual quality attribute models. The identification of use cases, scenarios (step 5) and individual quality attributes (step 6) related to the facts can follow thereafter, as well as prioritizing the attributes. Next comes looking for contributors (step 7) and possibly attributing (step 8) the qualities more precisely to certain system constituents. In these steps actors need a lot of support from someone experienced in quality modeling. The assumption that stakeholders are able to understand and communicate present and future needs in a clear way has been recently criticized for example by Holmström and Sawyer (2011, 35). Defining internal contributors is part of system model and consequently requires that developers take part in the process. The steps from 5 to 8 are in practice carried out rather simultaneously than one after another. Unless system component or sub-system specific attribute collections and sets are used, quality characteristics are usually at the beginning of quality modeling attributed to the information system as a whole. More specific attributions grow up during the modeling process, especially in connection with contributor element. All the steps of detailed quality design can potentially affect and cause changes in the

After listing indicators and identifying use cases, scenarios and contributors there exists enough material for creating a formal representation each desired relationship between system and context called "model" (step 9). At this stage indicators, model and its verbal description can be used to refine the general definition of the attribute in question in domain-attribute set. The remaining steps are identification of attribute relationships (step 10), especially conflicts, and designing a procedure for measuring (step 11) actual attribute

The principles of flexibility and freedom are important in the selection of system specific domain-attribute sets and in quality-driven development in general. There are, however, some core requirements that are commonly acknowledged to be important per se and should always be included in attribute sets. First of all any information system must be feasible (before even trying to create or acquire it), available, accessible and sustainable. In addition, it must be useful and therefore frequently used or, in some cases (e.g. computer games), have an ability to entertain. All the other characteristics, usability in the front line,

overall quality design, i.e. the prioritized domain-attribute set.

values in connection with testing and operating the target system.

quality modeling.

and that everything what is done is done in the name of realizing the quality goals. The following guidelines for applying the quality meta-model are based on experiences of three case studies in East-Africa.

From Figure 11 one can one can see how overall quality design coincides with requirements capture in unified software development model. Jacobson et al. (1999) divide requirements into two categories: functional and non-functional requirements. Functional specifications tell what the system is supposed to do for the users. Non-functional requirements, in turn, correspond to what are traditionally called quality attributes, like performance, availability, etc. The core quality 'usefulness' in fact covers the functional requirements in Jacobson's model. Consequently a well designed and prioritized system specific attribute set with goal values and attribute relationships, can cover the whole range of requirements and act as a guide and driving force for the whole development process. The importance of integration between functional and other requirements is seen for example by Kotonya and Sommerville (1996).

The first task during a phase that can be called "*inception*" is always formation of an actor group that carries out quality modeling. This group is so important that it is positioned as the first element in quality meta-model followed by the initial understanding of the system and its context. The latter things have an impact on the selection of first group members. Even the first understanding of the system is inevitably an interpretation made by some human actor(s). If the group is formed when the project is initiated and most of the members participate also into other development activities of the same system, it guarantees that quality modeling will be integral and dominant part of the whole software development process. The actor-informant group is properly formed if all essential actorstakeholder categories are represented. Case studies showed, however, that it is often difficult to engage all relevant stakeholders. Therefore, it is practical to start the work with most immediate system users and expand the informant group later according to needs and possibilities. If relevant, cultural aspects have to be taken into account when actor group is formed. Some studies in developing countries (e.g. Thanasankit and Corbitt, 2000, using a Thai case) show that social structures and hierarchies can be tall. All kinds of decisions must be approved by managers or committees. In these kinds of environments actor group must cover not only people with knowledge but also people with power. Before starting the actual quality modeling the informant group must be aware of the perspectives (step 1a) its members possess and the views (step 1b) they can have of the target system and its context. After that comes the task of gaining initial understanding of system and context.

The information system can first be described (step 2a) to actors more or less as a "blackbox" or by simple structural diagrams. The purpose of this view is to turn attention from the very beginning to the desired relationships between system and its context, i.e. quality requirements. It resembles the Taylorian view where, for example, messages stored in information system have no inherent value, and the value of entire system emerges only within a context (see Scholl et al. 2011, 790). The description of information system will gradually become more detailed and transparent during "attribution" and "contributors" steps. After initial system description follows the initial description of the system context (step 2b). It is a more important task in the initial phase than description of the system itself. Entities in the environment, including different human actors, determine what is required of the relationships between system and context. *A* suitable "meta-model" or theory of context

and that everything what is done is done in the name of realizing the quality goals. The following guidelines for applying the quality meta-model are based on experiences of three

From Figure 11 one can one can see how overall quality design coincides with requirements capture in unified software development model. Jacobson et al. (1999) divide requirements into two categories: functional and non-functional requirements. Functional specifications tell what the system is supposed to do for the users. Non-functional requirements, in turn, correspond to what are traditionally called quality attributes, like performance, availability, etc. The core quality 'usefulness' in fact covers the functional requirements in Jacobson's model. Consequently a well designed and prioritized system specific attribute set with goal values and attribute relationships, can cover the whole range of requirements and act as a guide and driving force for the whole development process. The importance of integration between functional and other requirements is seen for example by Kotonya and

The first task during a phase that can be called "*inception*" is always formation of an actor group that carries out quality modeling. This group is so important that it is positioned as the first element in quality meta-model followed by the initial understanding of the system and its context. The latter things have an impact on the selection of first group members. Even the first understanding of the system is inevitably an interpretation made by some human actor(s). If the group is formed when the project is initiated and most of the members participate also into other development activities of the same system, it guarantees that quality modeling will be integral and dominant part of the whole software development process. The actor-informant group is properly formed if all essential actorstakeholder categories are represented. Case studies showed, however, that it is often difficult to engage all relevant stakeholders. Therefore, it is practical to start the work with most immediate system users and expand the informant group later according to needs and possibilities. If relevant, cultural aspects have to be taken into account when actor group is formed. Some studies in developing countries (e.g. Thanasankit and Corbitt, 2000, using a Thai case) show that social structures and hierarchies can be tall. All kinds of decisions must be approved by managers or committees. In these kinds of environments actor group must cover not only people with knowledge but also people with power. Before starting the actual quality modeling the informant group must be aware of the perspectives (step 1a) its members possess and the views (step 1b) they can have of the target system and its context.

After that comes the task of gaining initial understanding of system and context.

The information system can first be described (step 2a) to actors more or less as a "blackbox" or by simple structural diagrams. The purpose of this view is to turn attention from the very beginning to the desired relationships between system and its context, i.e. quality requirements. It resembles the Taylorian view where, for example, messages stored in information system have no inherent value, and the value of entire system emerges only within a context (see Scholl et al. 2011, 790). The description of information system will gradually become more detailed and transparent during "attribution" and "contributors" steps. After initial system description follows the initial description of the system context (step 2b). It is a more important task in the initial phase than description of the system itself. Entities in the environment, including different human actors, determine what is required of the relationships between system and context. *A* suitable "meta-model" or theory of context

case studies in East-Africa.

Sommerville (1996).

would guide in focusing on the most relevant features of environment with respect to quality modeling.

After inception phase the overall quality design can start. It consists of creating a prioritized system specific set of domains (areas of concern) and quality attributes out of known alternatives. The results of inception phase together with the initial overall quality design form a kind of sketch of the target system in relation to context. In one of the case studies actors were given a large combined selection of domains and attributes and asked to prioritize them. This was found to be difficult for some informants because of too many items to deal with. Therefore, in the following case studies domain collection was separated from the "palette" and actors were asked to prioritize the domains (step 3) and attributes separately. During overall quality design conflicts may arise and a method for solving them must be found.

Case study observations suggest that after letting actors prioritize domains the most useful and productive step is eliciting positive and negative facts (step 4) indicating existence or the lack of quality inside each prioritized domain. This starts the detailed quality design. In the meta-model these facts are called "indicators" and they constitute an important part of individual quality attribute models. The identification of use cases, scenarios (step 5) and individual quality attributes (step 6) related to the facts can follow thereafter, as well as prioritizing the attributes. Next comes looking for contributors (step 7) and possibly attributing (step 8) the qualities more precisely to certain system constituents. In these steps actors need a lot of support from someone experienced in quality modeling. The assumption that stakeholders are able to understand and communicate present and future needs in a clear way has been recently criticized for example by Holmström and Sawyer (2011, 35). Defining internal contributors is part of system model and consequently requires that developers take part in the process. The steps from 5 to 8 are in practice carried out rather simultaneously than one after another. Unless system component or sub-system specific attribute collections and sets are used, quality characteristics are usually at the beginning of quality modeling attributed to the information system as a whole. More specific attributions grow up during the modeling process, especially in connection with contributor element. All the steps of detailed quality design can potentially affect and cause changes in the overall quality design, i.e. the prioritized domain-attribute set.

After listing indicators and identifying use cases, scenarios and contributors there exists enough material for creating a formal representation each desired relationship between system and context called "model" (step 9). At this stage indicators, model and its verbal description can be used to refine the general definition of the attribute in question in domain-attribute set. The remaining steps are identification of attribute relationships (step 10), especially conflicts, and designing a procedure for measuring (step 11) actual attribute values in connection with testing and operating the target system.

The principles of flexibility and freedom are important in the selection of system specific domain-attribute sets and in quality-driven development in general. There are, however, some core requirements that are commonly acknowledged to be important per se and should always be included in attribute sets. First of all any information system must be feasible (before even trying to create or acquire it), available, accessible and sustainable. In addition, it must be useful and therefore frequently used or, in some cases (e.g. computer games), have an ability to entertain. All the other characteristics, usability in the front line,

Quality Model – Master Plan and DNA of an Information System 149

Allen D., Karanasios S., Slavova M. (2011). Working With Activity Theory: Context,

Alter S. (1999). A General, Yet Useful Theory of Information Systems. *Communications of the* 

Alter S. (2008). Defining information systems as work systems: implications for the IS field.

*for Education in Developing Countries, Iringa, Tanzania, July 10-12, 2006,* 3-4. Finne A. (2011). Towards a Quality Meta-Model for Information Systems. *Software Quality* 

Homström J., Sawyer S. (2011). Requirements engineering blinders: exploring information

IEEE (Institute of Electrical and Electronics Engineers) Standard Glossary of Software

ISO (International Organization for Standardization) 8402 (1994). *Quality management and* 

ISO (International Organization for Standardization) 9000 (2000). *Quality management systems* 

ISO (International Organization for Standardization) 9126 (2001). *Software Engineering –*

ISO (International Organization for Standardization) 12207 (2008). *Systems and software* 

Jacobson I., Booch G., Rumbaugh J. (1999). *The Unified Software Development Process.* Boston:

Khaddaj S., Horgan G. (2005). A Proposed Adaptable Quality Model for Software Quality

Kotonya G., Sommerville I. (1996). Requirement engineering with viewpoints. *IEEE Software* 

Macome E. (2008). On Implementation of an Information System in the Mozambican

Muhren W., van den Eede G., van de Walle B. (2008). Sensemaking and Implications for

Ongoing Crisis. *Information Technology for Development, 14(3),* 197-212. Narasimhaiah G., Lin S-L. (2010). Determinants of software quality: A survey of information systems project managers. *Information and Software Technology 52 (6)*, 602-610. Reeves C., Bednar D. (1994). Defining quality: Alternatives and implications. *The Academy of* 

Context: The EDM Case Viewed Through ANT Lenses. *Information Technology for* 

Information Systems Design: Findings From the Democratic Republic of Congo's

Buschmann F. (2011). Unusable Software Is Useless, Part1. *IEEE Software, 28 (1)*, 92-94. Finne A. (2006). Applying a Twofold Quality Model: Producing Groundwork for System

*Science and Technology. 62(4),* 776-788.

*Journal, 19(4),* 663-688.

Addison-Wesley.

*Engineering Journal, 11(1),* 5-18.

*Development, 14(2),* 154-170.

*Management Review, 19(3),* 419-445.

*Association for Information Systems. 1(3),* Art. 13.

*European Journal of Information Systems, 17(5),* 448-469.

*European Journal of Information Systems, 20(1)*, 34-47.

Engineering Terminology (1990). New York: IEEE.

*quality assurance – Vocabulary*. Geneva: ISO/IEC.

*– Fundamentals and vocabulary*. Geneva: ISO/IEC.

*Product Quality – Part 1: Quality Model*. Geneva: ISO/IEC.

*engineering – Software life cycle processes*. Geneva: ISO/IEC.

Assurance. *Journal of Computer Sciences, 1(4)*, 482-487.

Technology and Information Behavior. *Journal of the American Society for Information* 

Specific Attribute Models. In Hautop H., SutinenE., Duveskog M., Kinshuk, Mkocha A. (eds.) *Proceedings of the Fourth IEEE International Workshop on Technology* 

systems developers' black-boxing of the emergent character of requirements.

**6. References** 

follow from or affect the before mentioned. They hamper or make it easier to use the information system, make it less accessible etc. Figure 12 depicts this view.

Fig. 12. Core quality requirements

The division into core qualities and other qualities resembles the division into key quality factors and locally defined factors by Khaddaj and Horgan (2005) in their Adaptable Quality Model (AQM). The key factors are required of all products. Locally defined factors, in turn, apply only to the current product being developed. AQM defines in total seven key qualities: maintainability, usability, cost/benefit, security, reliability, timeliness and correctness. Compared to AQM Figure 12 represents even more fundamental requirements. In a recent article Buschmann (2011), in turn, underlines just usefulness (in his terminology "business suitability") and usability as the key requirements for software.

## **5. Conclusion**

The above sections have given a definition for quality with respect to information systems as technical artifacts. In addition they have presented a holistic conceptual framework for quality modeling and a way to apply it in the course of system development. The last section finally promoted quality model to arch-model of an information system. As a theory, the quality meta-model does not assert anything testable about the relationships between its elements. The most relevant method of evaluating the framework is assessing the actual quality models created by applying it. These system specific models must be useful, contain elements that represent the real world and be comprehensible. In addition the meta-model itself must be comprehensive, flexible, general enough and applicable to a variety of contexts. This entails repeated case studies. While the framework does not offer testable propositions, it opens a number of questions for future research. How to arrange quality attributes into categories? Can a widely acknowledged division into domains be achieved? Are some actor perspectives and views more informative and productive than others? What are the most relevant axes in the frame of reference that determine the appearance of system to an actor? How is the physical, infrastructural and cultural context reflected in quality mnodels?

#### **6. References**

148 Security Enhanced Applications for Information Systems

follow from or affect the before mentioned. They hamper or make it easier to use the

The division into core qualities and other qualities resembles the division into key quality factors and locally defined factors by Khaddaj and Horgan (2005) in their Adaptable Quality Model (AQM). The key factors are required of all products. Locally defined factors, in turn, apply only to the current product being developed. AQM defines in total seven key qualities: maintainability, usability, cost/benefit, security, reliability, timeliness and correctness. Compared to AQM Figure 12 represents even more fundamental requirements. In a recent article Buschmann (2011), in turn, underlines just usefulness (in his terminology

The above sections have given a definition for quality with respect to information systems as technical artifacts. In addition they have presented a holistic conceptual framework for quality modeling and a way to apply it in the course of system development. The last section finally promoted quality model to arch-model of an information system. As a theory, the quality meta-model does not assert anything testable about the relationships between its elements. The most relevant method of evaluating the framework is assessing the actual quality models created by applying it. These system specific models must be useful, contain elements that represent the real world and be comprehensible. In addition the meta-model itself must be comprehensive, flexible, general enough and applicable to a variety of contexts. This entails repeated case studies. While the framework does not offer testable propositions, it opens a number of questions for future research. How to arrange quality attributes into categories? Can a widely acknowledged division into domains be achieved? Are some actor perspectives and views more informative and productive than others? What are the most relevant axes in the frame of reference that determine the appearance of system to an actor? How is the physical, infrastructural and cultural context reflected in quality

"business suitability") and usability as the key requirements for software.

information system, make it less accessible etc. Figure 12 depicts this view.

Fig. 12. Core quality requirements

**5. Conclusion** 

mnodels?


**8**

Seppo Sirkemaa

*Finland* 

*Life Sciences and Business,* 

*Turku University of Applied Sciences,* 

 *Business Information Technology, Turku,* 

**Services for the Digital Citizen** 

Internet makes it possible to provide services in a new way, making it possible to create added value to the user. At the same time organizations may re-organize and streamline their processes. Internet is changing the way we purchase products and services. Through Internet we may gather background information on competing products and services, compare and purchase things without the need to leave home. From the business perspective there are several targets when moving activities to the internet, serving customers on a 24 / 7 –basis and global reach are issues that may prompt the development of e-business applications. One of the key drivers in e-business is that internet makes it

In private sector information technology, internet-based applications and technologies are used widely in e-business applications. Clearly, public sector needs to move from paper to electronic correspondence, and from this toward a self-service model where citizens can get the answers and make transactions through the internet (Atkinson & Leigh, 2003). The concept of service is inextricably linked to e-business applications and the types of services there are in e-business environment (de Ruyter et al., 2001). Here self-service is typical, users have learned to help themselves in finding information and buying products. This is the case also with citizens that are using electronic services provided by public organizations.

The development of electronic services in public sector organizations has been relatively slow (Hasan & Tibbits, 2000; McIvor et al., 2002). This is interesting, because it seems clear that also public sector would benefit from electronic access to services. It is not surprising that there is pressure and an increasing demand for development of e-services in public sector. It is noteworthy, that those who can access internet are in a different position than people who do not have this opportunity (Cullen, 2001). Equal access to internet and services that are made available through it is an issue all over the globe, and it concerns also

In this article we look at the challenges that development of electronic services in public sector organizations face. It is an environment which calls for cooperation of various departments and functions, and interaction between service providers, experts and other stakeholders. The question of interest is what makes providing electronic services in public

possible to increase company's efficiency and effectiveness (Rust & Kannan, 2003).

**1. Introduction** 

citizens in the industrialized world.

