<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Teaching Information Systems: an i*-based approach</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Juan Pablo Carvallo</string-name>
          <email>pablo.carvallo@ucuenca.edu.ec</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Computer Science Department University of Cuenca</institution>
          ,
          <country country="EC">Ecuador</country>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2015</year>
      </pub-date>
      <fpage>7</fpage>
      <lpage>12</lpage>
      <abstract>
        <p>Modern enterprises rely on information systems (IS) both to support their operation and provide information required to endorse strategic decisions. Because of their increasing complexity, such systems are usually constructed by integrating software components of different nature and origins, into hybrid systems, for which architectural design plays a fundamental role. If well engineered, it becomes the blueprint required for IS to add value to the organization. However, IS architecting is not an easy task, mainly due to the fact that engineers often lack of knowledge related to business strategy and operations, but also proper training in methods and techniques required to conduct IS architectural design in a well-structured way, without losing focus on business strategy. In this paper we present an i*-based approach to lecture information systems, which keeps in mid both business strategy and technology.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>
        Modern enterprises rely their strategy on Information Systems (IS) required to,
support and orchestrate their operation, provide information to endorse decision making,
and eventually add value to their businesses. Because of their complexity, such systems
are currently built by integrating components of different nature into Hybrid Systems
[
        <xref ref-type="bibr" rid="ref1">1</xref>
        ], encompassing third-party Off-The-Shelf components [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ], legacy and bespoke
systems. IS architecture plays a fundamental role. It is used to guide components
construction and/or selection, and integration into a dependable systems, in which components
interact in a reliable and coordinated way to support business strategy.
      </p>
      <p>However, IS architecting is not an easy task; engineers are usually trained in methods
and technologies required to design and build components from the scratch, but often
lack knowledge related to business strategy and operations. This leads them to
prioritize technology over strategy and thus, to assemble IS that do not fully comply with
needs or add value to organizations. It also leads them to adopt merely operative,
subordinated roles, instead of visionary, managerial and strategic ones, hampering
professional growth.</p>
      <p>It is therefore highly relevant to improve their training to include curricula covering
these aspects. This paper presents an i* based approach to lecture IS, intended to
develop skills related to business modeling and strategy, and the understanding of their
impact on IS architecture and vice versa.</p>
      <p>The remaining of this paper is structured as follows; section 2 introduces the context
and the course; section 3 describes the lecturing method; Section 4 gives some
concluding remarks.
2</p>
    </sec>
    <sec id="sec-2">
      <title>The context and objectives of the course</title>
      <p>
        Cuenca University is one of the top five ranked universities in Ecuador. Its
Engineering Faculty offers major degrees in several engineering fields including Systems
Engineering. This five years long program includes, in addition to general education,
courses mainly related to the ACM software engineering curricula [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ], but also some in
relation to Computer Science. Information Systems is a core course in the Systems
Engineering program. Lectured in the second semester of the fourth academic year, it
encompasses 64 core hours of classroom activities. Its learning objectives are:
 Understand the managerial role of the systems engineers and its responsibility as
value generators for the organization.
 Identify the responsibility (dependencies) of an organization in relation to its context
and the strategy required to fulfill it.
 Understand enterprise organization (value chain –see next section-) and the roles of
organizational areas to support enterprise strategy.
 Identify the benefits that a IS could bring to the organization in order to support its
strategy (external requirements) and operation (internal requirements)
 Define the IS architecture required to support decision making at different
organizational levels, and the goals for software components required to implement it.
      </p>
      <p>The main goal of the course is getting students to understand and keep focus on
business strategy, in order to design IS architectures required to construct systems that
generate value to the organization and the actors in its context.
3</p>
    </sec>
    <sec id="sec-3">
      <title>The lecturing method</title>
      <p>
        The course is conducted in a semi-industrial way; students are required to complete
analysis and modelling activities in industrial settings (organizations that agreed to
cooperate with the program). Students work in couples to complete assignments,
supported by responsible of the assigned organizations. At the end of academic period,
organizations are provided with all documents produced in the course. Academic
process starts by constructing Context Models (CM) of the organization and ends with the
identification of the IS architecture (actors that structure the system, services that must
be covered by each of them and their relationships). The course is divided into 7 units
(in addition to its introduction). The first three units provided basic information in
relation to methods, models and notations to be used, whilst units 4 through 7 are intended
to guide students on the core assignments, making strong use of i* models and
modelling techniques (see Fig. 1). The next paragraphs resume activities conducted in each
of these units.
 Unit 1: The business strategy framework. Strategic framework is based in Porter’s
models of market forces and value chain [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]. The first is designed to analyze the
influence of five competitive forces on business context (threat of new entrants;
threat of substitution; bargain power of customers; bargain power of suppliers; and
rivalry among current competitors) and reason about strategies to make
organizations profitable. To balance the forces, enterprises adopt an internal organization
known as Value Chain, which encompasses five primary (inbound logistics;
operations; outbound logistics; marketing &amp; sales; and support) and four support
(Infrastructure; human resources management; technology development; and
procurement) value activities (VA), required to generate value and eventually a margin
(difference among total value generated and cost of performing VA). Primary activities
are core and specific of business whilst supporting ones are transversal to them.
      </p>
      <p>
        Students are required to analyze organizational chart and identify organization’s
value chain, by aligning Organizational Areas (OA) with value activities included
in Porter’s generic value chain model (see Fig.2). Next, they are required to analyze
the organization in relation to each market force, with support of representatives of
each OA, and identify Context Actors (CA) in relation to them, e.g. types of suppliers
(services/raw materials/supplies, domestic/international, etc.), types of consumers
(local/national/international, cash/credit, etc.). We advise students to acknowledge
four types of actor’s hardware, software, organizations and people.
 Unit 2 and 3: Introductory concepts. Unit 2 provides basic training on composite
hybrid systems [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ], types of components that can be used for their construction,
empirics to support the decision whether to acquire or build a component from the
scratch and a quick review of integration techniques. Unit 3, introduces students to
i* modelling notation; SD and SR models and their constructs are reviewed and
several examples are provided. The course adopts the simplified version of the i*
metamodel reported in [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] e.g. actors are treated in a generic manner, without
distinguishing roles, positions and agents; use only is-a and is-part-of actor links; avoid task
dependencies since they are too low level (focus on goals that can be operationalised
by them); use just goals as intentional elements and goal decompositions as
intentional elements links, inside actors’ boundaries, etc.
 Unit 4: Modelling the enterprise context. The organization and its strategy are
analysed in detail, to identify its role inside the context. CA identified in unit 1 are
examined in relation to each OA in the value chain, to identify strategic needs among
them (Context Dependencies –CD-). Also OAs are analysed in relation to each other
to identify their strategic interactions (Internal Dependencies –ID-). Students are
asked to construct an i* SD context model from the perspective of each OA,
including their related CA and OAs as well as their CD and ID. Resulting models are
combined into a single enterprise Context Model (see Unit 4 of Fig. 1). Guidelines
included in [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] are provided to help identify CD and ID. Graphical guidelines are also
provided e.g., change the graphical representation of dependencies from standard
curved lines with oriented “D”s, to straight lines with arrowheads (see Fig. 1).
 Unit 5: Modelling the environment of the system. An IS-to-be is placed into the
organization, and the impact that it has over the context is analysed. Strategic
dependencies identified in unit 4 (internal and external), are examined to determine
which of them may be totally or partially satisfied by IS. These dependencies are
redirected inside the i* SD diagram to the IS. The model includes the organization
itself as an actor in IS environment, its needs are modelled as strategic dependencies
over the IS (see Unit 5 of Fig. 1). Context Model resulting from unit 4 is transformed
to its tabular form as proposed in [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ] (see first 5 columns of table 1), to help manage
size. Columns “Total” and “Partial” are used to state which dependencies can be
fully or partially automated. These dependencies structure the Context Model of the
IS (SCM). “Why” column is used to state reasons why dependencies are considered
to be automatable (for teacher validation purposes).
 Unit 6: Decomposition of system goals and identification of system actors.
Dependencies included in the SCM are analysed and decomposed into a hierarchy of
goals required to satisfy them. The goals represent the services that IS must provide,
to support interaction with CA and OA activities. An i* SR diagram for the system
is built, using means-end links of type goal-goal (representing then a decomposition
of objectives into sub-objectives) (see Unit 6 of Fig. 1). Column “How” is added to
the table resulting from unit 5, to state goals and sub-goas in the tabular
representation (see table 1). As a hint for goal identification we ask students to think about
basic data to be stored, transactions and processes required to manage and transform
it and, basic queries and reports to be obtained. Sub-goals are refined until they
represent services atomic enough, such that it does not makes sense to further reduce
them. The process is complete when all the CD and ID have been considered and
linked to appropriated sub-goals required for their fulfillment.
 Unit 7: Identification of system architecture. Finally, goals included in the SR
model are analysed and systematically grouped into System Actors (SA). Objectives
are clustered into services, according to an analysis of the strategic dependencies
with the environment and an exploration of software components marketplace.
Relationships between SA that form IS architecture are described according to the
direction of the means-end links that exist among the objectives included inside them
(See Unit 7 of Fig. 1). Additional columns are added to the table, one for each SA
identified (see table 1). Goals and sub-goal are linked to SA by placing a capital
letter “I” in the proper cell (SA column; goal/sub-goal row) if they have to be
implemented in SA, and a “D” when they require data or supporting functionality from
other SAs (interoperability requirements). SA are not software components; they
represent atomic software domains for which several situations may occur: there can
be a software component covering the functionality of several SA; the functionality
of a single SA is covered by several software components for ubiquity reasons e.g.
mobile and local applications; or there can be cases for which no software
components exist, leading to the need of bespoke software.
      </p>
    </sec>
    <sec id="sec-4">
      <title>Concluding remarks</title>
      <p>This paper presents an i*-based approach for lecturing IS and IS architecture. The
approach helps students to keep focus on business strategy and technology at a time. It
starts by modelling the environment of the organization and concludes with the
definition of the IS architecture required to support its operation and the strategic interactions
with actors in its context. The lecturing method makes intensive use of i* models; after
conducting the course in several editions, we have found that the method provides
several benefits for students:</p>
      <p>Although we find the lecturing method very valuable and the evaluation of students
is usually positive, there are problems of different nature that we have to address:
Notational (organic nature of graphical notation, difficulties to scale and poor tool support,
problems typically associated to i* models); Semantic (confusion among dependency
types, their direction or the correct way to state their descriptions); Decomposition and
groping of goals; and Organizational (lack of organizations willing to cooperate, or
size of the ones willing to do it -too large o too small-).</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <source>Proceedings of the 7th International Intl. Conference on Composition-Based Software Systems (ICCBSS)</source>
          , IEEE,
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <given-names>J.</given-names>
            <surname>Li</surname>
          </string-name>
          et al.
          <article-title>A State-of-the-Practice Survey of Risk Management in Development with Off-theShelf Software Components</article-title>
          .
          <source>IEEE TSE</source>
          ,
          <volume>34</volume>
          (
          <issue>2</issue>
          ),
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          <article-title>3. The Joint Task Force for Computing Curricula 2005</article-title>
          .
          <article-title>Computing Curricula 2015</article-title>
          .
          <article-title>ACM</article-title>
          and IEEE,
          <year>2006</year>
          . Available at https://www.acm.org/education/education/curric_vols/CC2005- March06Final.pdf
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <given-names>M.E. Porter. Competitive</given-names>
            <surname>Strategy</surname>
          </string-name>
          . Free Press,
          <year>1980</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Carvallo</surname>
            ,
            <given-names>J.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Franch</surname>
            ,
            <given-names>X.</given-names>
          </string-name>
          <article-title>On the Use of i* for Architecting Hybrid Systems: A Method and an Evaluation Report</article-title>
          .
          <source>PoEM</source>
          <year>2009</year>
          . LNBIP, Springer,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Carvallo</surname>
            ,
            <given-names>J.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Franch</surname>
            ,
            <given-names>X.</given-names>
          </string-name>
          <article-title>Building Strategic Enterprise Context Models with i*: A PatternBased Approach</article-title>
          .
          <source>TEAR</source>
          <year>2012</year>
          . LNBIP, Springer,
          <year>2012</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <given-names>C.</given-names>
            <surname>Ayala</surname>
          </string-name>
          et al.
          <source>A Comparative Analysis of i*-based Agent-Oriented Modeling Languages. SEKE</source>
          <year>2005</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>