Towards a Mobile Software Engineering Education Mira Kajko-Mattsson KTH School of Information and Communication Technology Royal Institute of Technology Kista, Sweden mkm2@kth.se Abstract It is high time we looked at the education of software engineering from a global and mobile perspective. To achieve this, we suggest a new educational paradigm, in which future software engineering students and lecturers are mobile and agile. They may enroll at any globally established educator providing educational services on various abstraction levels. This paper suggests a Globalization Ladder, a tool aiding the software community to develop a global software engineering education program 1. Introduction Whether you like it or not, transition to a global scale is rolling forward. It does no longer embrace economies, societies and cultures but also education. Hence, it is high time we treated education of software engineers from a global perspective. Most of the software engineering educators develop and follow curricula with a strong focus on the local needs of their universities or school systems. Very few of them, however, consider globalization as one of their defining terms [16]. Those who do, on the other hand, try to meet globalization demands by offering various international software engineering programmes. Still however, they follow their own locally specified curricula built on their own locally specified scope of software engineering domain. To enable globalization of the software engineering education and training, the software community has developed a set of common guidelines and put it into a framework called SWEBOK [20]. SWEBOK s mission is to identify the body of knowledge with the main purpose of promoting a consistent view of the software engineering domain worldwide and for providing guidance to the standard organizations to develop a global curriculum, such as for instance [22]. Figure 1. Kajko-Mattsson s Globalization Ladder Defining a global software engineering curriculum is not enough however. Departments still have difficulties to assess students progress and competence, particularly in the context of providing education to the nationally and internationally mobile students [9]. The difficulty lies in tracking students competence and progress as they transfer from one school to another. Today, courses and grades acquired in various schools do not tell us enough about the details of students achievements. When enrolling or employing students, the academic and industrial bodies have no way of knowing whether the students have requisite knowledge. Many times, the information acquired from the student s degree documents is too abstract and incomplete thus leading to an inaccurate judgment of their knowledge and skills [9]. For this reason, many departments have long expressed the need for a more comprehensive assessment approach when enrolling and graduating students from various national and international educational instances [9]. In this paper, we suggest a Globalization Ladder (GL), a tool aiding the educators in adapting to a global software engineering educational programme. The utmost mission of GL is (1) to achieve a mobile
Figure 2. GL Components self-educating and self-counseling software engineering student who creates his own educational plan in a global network of software engineering educators and (2) to enable a mobile lecturer to provide educational services in any global software engineering educational context. Its goal is (1) to aid educators and industry to make better and more informed decisions about the competence and skills of the under-graduate and graduate students, and (2) to constitute a benchmark for a comparative assessment of different educators. The remainder of this paper is as follows. Section 2 presents current status within education today. Section 3 provides an overview of the GL. Section 4 presents its inherent levels. Finally, Section 5 makes conclusions and suggestions for future work. 2. Status Today The software community has done a lot to understand and improve the development capability of software organizations. It has realized it in form of various tools such as Capability Maturity Model (CMM), Software Process Improvement and Capability Determination (SPICE) and other models [17, 19]. To optimize development results, the process improvement models have been complemented with peopleware models focusing on continuously improving management and development of the organizational human assets [5, 6]. The understanding of peopleware in an industrial context is quite straightforward. Here, one claims that the better the human asset the higher the maturity of software organizations and thereby the higher product quality [17]. However, one does not deny that some immature organizations may strongly benefit from employing highly talented individuals. Regarding the academic context, this relationship is somewhat similar. We distinguish between two types of peopleware in the academia: pedagogical cadre and students. There is a common opinion that it is more probable that the more mature the educator, the better quality of the education and thereby the more knowledgeable peopleware. However, just as in the industrial context, one does not deny that the quality of the educators may strongly benefit thanks to the individuals abilities and talents. Many educators throughout the world offer a diverse set of courses. These courses vary in size, objectives, target markets, resources, and relation to research and quality. Bearing this in mind, it may not always be easy for students to choose among a myriad of available educators. Preferably, the students should strive to enroll in more mature educating instances. But, how can they assess their teaching capabilities? Unfortunately, there is no way of assessing current educators with respect to how capable they are to deliver their products competency. When choosing their educators today, students mainly follow their national and/or international reputation. The software engineering community could benefit much more by focusing its efforts not only on enabling assessment of software production within the industry but also on enabling a similar assessment of educational capabilities within the academia [15]. For this reason, it needs a stage-wise educational model, similar to [17, 19]. GL constitutes such a model. 3. Overview of GL To provide a platform for educating mobile students, the educators need to undergo various changes. These changes are illustrated with the aid of a ladder shown in Figure 1. Its lowest level is No curriculum and no control and the highest one is Global Educator. Below, we briefly describe them. Level 1 No curriculum and no control: The educators do not follow any curriculum. They do not have any control over the courses and their contents. The choice of courseware and its contents is made by individual lecturers. Level 2 No curriculum and some control: At Level 2, the educators still do not follow any particular curriculum. However, they start having control over their courses and their relationships. The course choice is now managed by a software engineering education owner whose role is to keep track of the software engineering courses. Level 3 Provincial curriculum: The educators have agreed on a core body of software engineering knowledge. Using it as a basis, they have developed their local curricula and curriculum dialects specifically adapted to various software engineering contexts and national needs. Level 4 Joint curriculum: As collaborators, two or several educators create a joint curriculum in order to match the particular aims of a distributed educational programme. Level 5 Global curriculum: Educators use a global curriculum and market their educational programmes by displaying adherence to the values and purposes of the global curriculum. Level 6 Global educator: The traditional pattern that one student and one lecturer affiliate with only
Table 1. Summary of the educational levels one educator or a set of joint educators does no longer apply at this level. Both students and lecturers may enroll at any globally established educator on an individual course level. In addition to the above-listed levels, GL is described using the components listed in Figure 2. These are: Curriculum: The educators are assessed whether they have defined and followed the curriculum. Focus: The educators are evaluated according to their focus on (1) teaching practical and theoretical knowledge and skills, (2) balance between cooperative and individual educational approach, (3) choice of software lifecycle phases to be included in their curricula, and (4) relation to the related disciplines such as socio-economic sciences and other engineering domains. CourseWare: Here, the provision of courseware is assessed with respect to the designation of software engineering topics, relationships among them, control over their contents and development and adherence to the curriculum. Peopleware: The organizational capability of managing peopleware (academic cadre and
students) is assessed. Here, one considers the capabilities of developing their competence and the long-term knowledge equipment to meet future software engineering trends and challenges. Levels: Here, one places the educator on the GL level via which one evaluates how far the educator is from reaching the utmost globalization level, if relevant. Finally, GL implements the responsibility shift. As shown in Figure 1, the responsibilities shift from an individual lecturer to the international software community. 4. GL Levels In this section, we present the GL levels. The levels are presented in Sections 4.1-4-6, respectively. They are also summarized in Table 1. 4.1. Level 1: No Curriculum and No Control At Level 1, educators lack a software engineering education curriculum. Hence, their way of providing educational services is ad-hoc and chaotic. They exhibit lack of agreement on the core body of software engineering knowledge and lack of learning objectives. The choice of courses to be provided and their contents is on an arbitrary basis. It is mainly based on the competencies available on the educator s side. Many times, such educators are skewed more towards practical courses such as programming in certain languages and less towards more theoretical ones. The educators mainly focus on some specific lifecycle phase or sub-phase, such as for instance, implementation sub-phase within development. The educators display an unorganized way of developing courseware. They mainly focus on identifying topic areas, rather than imposing a structure on the relationships among those topics. Due to the fact that the choice of courseware is individually managed by the lecturers, the educators do not posses enough insight into the contents of their courses. The educators lack insight into their human assets. They lack control over the competence development of both their pedagogical cadre and students. Regarding the competence of the lectures, no major effort is put into its development. Lecturers may or may not have competence to teach at the university level. As pointed out in [7], many seats of learning still do not utilize qualified lecturers for teaching their courses. The educators lack learning objectives. The competence of students is strongly limited to what is offered by those departments. Although their graduate students may be directly utilized for practical purposes within the industry, they may not be equipped enough to meet future challenges and trends within software engineering. 4.2. Level 2: No Curriculum and Some Control At Level 2, the departments still lack a software engineering curriculum and they display abstract and general learning objectives. They have not agreed on the core body of software engineering knowledge. The choice of courses to be offered and their contents is made by a role of a software engineering education owner who keeps track of the software engineering courses given on the educator s side. This choice, however, is made on a half-arbitrary and half-formalized basis being still dependent on the individual competencies available within departments and their will to manage the courses. In contrast to Level 1, however, one focuses more on a balance between practice and theory and one promotes more efficient work environments enabling student collaboration [21]. One also extends the lifecycle coverage from one particular lifecycle phase to several interrelated phases. At Level 2, one recognizes the fact that the profession of software engineering is tightly related to other topics and disciplines such as socioeconomic science, other engineering domains and various soft topics [3, 4, 12]. Hence, one attempts to extend the focus from pure software engineering course portfolio to a more mixed one. Special stress is put on increasing students awareness of the richness and complexity of the human aspect and problems that students may face in the software production world [12]. Here, one keeps in mind that technical and theoretical expertise is not enough; social competence is important as well [13]. 4.3. Level 3: Provincial Curriculum At Level 3, the educators have defined and followed a locally developed curriculum. The curriculum prescribes a core body of knowledge to be offered by the educator. It clearly specifies the fundamental purpose of the software engineering programme by identifying key concepts, knowledge domains and contexts. Using it, the educators may make decisions on the contents and competencies to be provided as a baseline and on the balance between practical, theoretical and soft components. The professional objectives of software engineering students vary widely, from software developer to software manager, to security expert, and to researcher. Also, the broadness and diversity of the software engineering discipline does not allow the educators to cover all its facets. Striving for full software engineering coverage implies risks such as superficiality and negligence of some essential components [18].
At Level 3, the educators recognize the strong diversity of software engineering domain and its profession. Hence, they stay focused on meeting specific educational and professional goals by offering sets of the entire software engineering body of knowledge. They do it by creating curriculum dialects specifically adapted to meet these goals. These dialects may be planned with the help of instruments such as, for instance, Bloom s Taxonomy [2]. They may cover the following dimensions [4]: different levels of abstraction defining hardware and software components balance of computing contents with other branches of science and engineering balance between theory, modeling and practical applications of them balance between technical and non-technical material. The software engineering discipline is specified in terms of an entire software lifecycle spanning from development to retirement. Focus is put on a set of body of knowledge pivotal for delivering the educator s provincial curriculum. At Level 3, the educators recognize the problem of teaching introductory courses. Due to the wide scope of the software engineering domain, the introductory courses are regarded to be one of the hardest to learn and teach [14]. As a solution, the educators identify various knowledge domains on several abstraction levels and create hierarchies among these levels. These hierarchies are then traceable with various vertical and horizontal red threads. The hierarchical introduction of software engineering topics is an initial step towards componentization of the courseware, where each component is on a specific abstraction level and is strongly dependent on the components on the lower abstraction levels. Because the curriculum is distributed across these hierarchies, the hierarchies should not have any holes in the sense of missing layers [4]. The educators have full insight into their human assets. They cultivate and improve the competence of their pedagogical cadres. They do it in the following: create specifications of each lecturer role, its job description and required qualifications make an organization-wide inventory of their knowledge and skill assets match the role specifications and knowledge and skill assets to their provincial curricula and define further competence needs continuously evaluate the qualifications and educational needs of their pedagogical cadre with respect to their roles, career plans and future educational needs. Regarding the students capabilities, the educators display a disciplined and organized way of developing their competence by clearly specifying learning goals and objectives and by relating them to their local curricula. The graduate students are now equipped to meet future software engineering challenges and trends. 4.4. Level 4: Joint Curriculum Some educational programmes may be dedicated to several disciplines in which software engineering is one part. Hence, they may not always be managed by one educator. Several educators may have to be involved instead. To be able to provide such educational programmes, the educators have to commonly define a joint curriculum. The joint curriculum provides a basis for making decisions on the allocation of curriculum part to different disciplines, topics and educators. In addition to the local hierarchies of their own courseware, the distributed educators create the hierarchies of the distributed courseware and establish vertical and horizontal red threads among them. The educators cultivate and improve the competence of their respective pedagogical cadres. In addition to this, they have to possess general insight into the capabilities of their co-operating educators. This is because they must jointly put effort into identifying common sets of knowledge required for shipping the joint educational programme. Regarding the students, just as on the former level, the educators display a disciplined and organized way of developing student competence by clearly specifying the learning goals and objectives and by relating them to their joint curricula. In contrast to the former levels, the student results get recorded in a distributed form within each respective education provider. Their overall results however are centrally managed by the primary education provider. 4.5. Level 5: Global Curriculum The software engineering curriculum is internationalized and globalized. The global curriculum is continuously evolved to meet the changing needs of the software engineering community [8]. However, it should evolve with caution [11]. It should emphasize principles and recognize stable and long-lasting core concepts and exclude the specific domains and related disciplines [11, 20].
Figure 3. Global Service-Oriented Education Any educator can use the global curriculum. The educators market their local educational programmes by displaying adherence to the values and purposes of the global curriculum. Still, however, they need to be consistent with their national educational strategies. Just as on the previous level, the focus is put on a set of body of knowledge and the whole software lifecycle. This time, however, the software community provides suggestions for how to tailor it when creating specific educational programmes. At Level 5, the software community identifies various global curriculum components, creates appropriate hierarchies among them and establishes vertical and horizontal red threads among them. These global hierarchies should provide a basis for educators to define their own courseware components. Regarding the competence of pedagogical cadre, the educators announce their educational capabilities with respect to the global curriculum. Here, one has insight into the pedagogical capabilities on an educator level. Regarding the students capabilities, the students develop their competence according to a globally recognized curriculum. By assuring that their educational programmes follow it, they gain confidence in their preparations for their future professional life. 4.6. Level 6: Global Educator The traditional pattern that students and lecturers are affiliated with one educator or a set of joint educators does no longer apply at this level. By contrast, future software engineering students and lecturers are mobile and agile. Both of them may enroll at several educators simultaneously. The students graduate documents are made up of pieces and patches obtained from several educators [9]. To enable the agility and global mobility of future software engineering students and lecturers, the software community must prepare for it. This may be done by creating global repositories covering the following information: Global curriculum. Global suggestions for curriculum dialects. Curriculum dialects as implemented by various educators. Suggestions for tailoring the components of the global curricula to the individual student needs. Specification of the courses implementing the tailored curricula and/or curriculum dialects. Identification of the educators providing the courses. Evaluation of the educators with respect to their adherence to the promised curricula (global/tailored/dialect ones). Global job description and required qualifications. Global repository of lectures who may provide educational services and evaluation of their pedagogical capabilities. Global repository of students and their grades. The concept of a global educator leads to a new educational paradigm in which students have freedom in choosing their own educator, curriculum and courseware. This sparks the desire for student independence and self-education thus leading to a creation of a global, mobile and agile software engineering student. Also, the lecturers are no longer dependent on one educator. They may offer their pedagogical services in a global context. Just as on the previous level, the focus is put on a set of body of knowledge, the whole software lifecycle, and suggestions for how to tailor the global curriculum when creating specific educational programmes. In addition, the focus is put on providing advice to students on how to tailor their individual educational programmes. The software engineering education is visualized in Figure 3. It is componentized on a global level. Based on the global software engineering curriculum, the educators create components of courseware on various abstraction levels and define interfaces among them. Information about these components and their dependencies is stored in a common global repository. When defining their educational programmes, the students may choose them from the common global courseware repository. The repository is similar to the one as suggested in [1]. The difference is that it does not cover research information but constitutes a basis for providing global service-oriented education. Regarding the competence of the pedagogical cadre, the software community gets full insight into the globally registered educators and globally
registered individual lectures. The insight is both on an educator and lecturer level. The lectures, however, get a better opportunity to globally display their competence and pedagogical capability. Regarding the students, they may choose to either acquire an educational programme designed by a particular education provider or they may tailor their individual educational programmes by following the global suggestions for tailoring individual programmes. The student results may either be recorded on their respective educators sites or they may be recorded in the global educational repository. 5. FINAL REMARKS The era of globalization is here and there is nothing we can do to stop it. Instead, we should adapt to it by revising our paradigm of teaching software engineering. In this paper, we suggest a new educational paradigm based on GL. Its goal is to aid educators and software community to develop a global software engineering educational program. The GL model presented herein only outlines a stage-wise effort towards providing global software engineering educational services. Despite its infant stage, it may already provide a frame of reference to be used by the educators in their globalization effort. The model, however, needs further revision and detailing to provide a fully-fledged framework for the software engineering educators worldwide. For this reason, we cordially invite the software community to base their future work on our model. 10. References [1] T. Alexander, J. M. Bieman, R. B. France, A software engineering research repository, ACM SIGSOFT Software Engineering Notes, 29(5), 2004, pp. 1-4. [2] L. W. Anderson, D. R. Krathwohl, A taxonomy for learning, teaching and assessing: A revision of Bloom's Taxonomy of educational objectives: Complete edition, Longman, 2001 [3] M.A. Ardis, S.V. Chenoweth, F.H. Young, The Soft topics in software engineering education, Frontiers in Educaton Conference, 2008, pp. F3H-1-F3H-6. [4] A.J. Cowling, A Multi-Dimensional Model of the Software Engineering Cumiculum, Conference on Software Engineering Education and Training, 1998, pp.0044, [5] B. Curtis, W.E. Hefley, S. Miller, The People Capability Maturity Model: Guidelines for Improving the Workforce, Addison Wesley Longman, 2002. [6] M. Kajko-Mattsson, S. Forssander, U. Olsson, Corrective Maintenance Maturity Model: Maintainer s Education and Training, International Conference on Software Engineering, IEEE Computer Society Press, ISBN: 0-7695-1050-7, 2001, pp. 610-619. [7] M. Kajko- Mattsson, H. Blomquist, Y. Lundberg, A Survey of the Competence of IT-Pedagogical Cadre, IEEE International Conference on Information Technology: Research and Education, IEEE Computer Society Press, ISBN: 0-7803-7724-9, 2003, pp. 210-214. [8] B. Nell, N.B. Dale, A.D. McGettrick, J. Impagliazzo, R. M. Aiken, E. B. Koffman, J. Leisy, A historical look at curricula and materials. SIGCSE, 2009, pp. 197-198. [9] P. T. Ewell, P.R. Schild, K. Paulson, Following the Moble Student: Can We Develop the Capacity for e Comprehensive Database to Assess Student, National Center for Higher Education Management Systems, 2003. [10] G. Gary Ford, N. Gibbs, A Master of Software Engineering Curriculum: Recommendations from the Software Engineering Institute, Computer, vol. 22, no. 9, 1989, pp. 59-71, Sept. [11] C. Ghezzi, D. Mandrioli, The challenges of software engineering education, ICSE, 2005, pp. 637-638. [12] O. Hazzan, J. Tomayko, Teaching human aspects of software engineering, ICSE, 2005. [13] P. Inverardi, M. M. Jazayeri,: Software Engineering Education in the Modern Age, International Conference on Software Engineering, Lectures, Springer, 2006. [14] P. Jalote, Teaching an Introductory Software Engineering Course in a Computer Science Program. CSEE&T, 2009. [15] T. Lethbridge, J.H. Díaz-Herrera, J. Richard, R.J. LeBlanc, J.B. Thompson, Improving software practice through education: Challenges and future trends. FOSE, 2007, pp. 12-28. [16] J. Lule, 2009, Creating the Global Studies Curriculum A Space for the Local?, http://globalejournal.org/2009/07/13/creating-the-global-studiescurriculum-a-space-for-the-local/, 2009. [17] M.C. Paulk, C. V. Weber, B. Curtis, M. B. Crissis, The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, 1995. [18] A. B. Pyster, R. Turner, D. Henry, K. Lasfer, L. Bernstein, K. Baldwin, The Current State of 28 Software Engineering Masters Degree Programs. CSEE&T, 2008. [19] ISO/IEC 15504 Standard, http://www.isospice.com/, retrieved on October 4, 2009. [20] SWEBOK. Guide to the Software Engineering Body of Knowledge (SWEBOK). www.swebok.org, 2009. [21] L. Williams, L. Layman, K. M. Slaten, S. B. Berenson, C. B. Seaman, On the Impact of a Collaborative Pedagogy on African American Millennial Students in Software Engineering. ICSE, 2007. [22] ACM, AIS, IEEE, Computing Curricula 2005, http://www.acm.org/education/curric_vols/cc2005march0 6Final.pdf, retrieved on April 10, 2010.