TOWARDS AUTOMATING THE DEVELOPMENT OF...

TOWARDS AUTOMATING THE DEVELOPMENT OF A

FAMILY OF ELEARNING SYSTEMS

By

Sridhar Chimalakonda 200707030

[email protected]

A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF

Master of Science (by Research) in

Computer Science & Engineering

Software Engineering Research Lab

International Institute of Information Technology

Hyderabad, India

March 2010

Dedicated to the unique teacher of my life,

Prof. Kesav V. Nori,

The Man of Fundamentals

INTERNATIONAL INSTITUTE OF INFORMATION TECHNOLOGY

Hyderabad, India

CERTIFICATE

It is certified that the work contained in this thesis, titled “TOWARDS AUTOMATING

THE DEVELOPMENT OF A FAMILY OF ELEARNING SYSTEMS” by Sridhar

Chimalakonda (200707030) submitted in partial fulfillment for the award of the degree

of Master of Science (by Research) in Computer Science & Engineering, has been

carried out under my supervision and it is not submitted elsewhere for a degree.

Date: Advisor:

Prof. Kesav V. Nori

Distinguished Professor,

IIIT-Hyderabad

Acknowledgements

In my wonderful journey towards this thesis, I came to the most beautiful part that gives

me an opportunity to thank all the people who have contributed to this thesis.

It was a dream for me to do research on the topic of “Software Factories” and a divine

gift to have Prof. Kesav V. Nori as my advisor who has envisioned this idea since 25

years. I can definitely say that he has put utmost effort in driving this thesis, correcting,

and questioning me until it reached required levels of quality. I am sure that this effort

has materialized in my thesis, without his support, perhaps I would have reached some

other end. My heartful thanks to him for allowing me to think at an abstract level and

pushing me to the extreme end of getting into minutest of details and deliver research in

practice. He has awakened the researcher in me by continuously questioning my ideas

for correctness and teaching me that being an engineer is crucial to become a

researcher. I have never dreamt that a research undertaken at a university can reach

people in the rural areas in a span of two years but he has driven me to make it possible

and make a social contribution. On the personal side, he is a wonderful person to work

with and my deep gratitude to him for being my “Guru”. Special thanks to my reviewers

Prof. Jayanthi Sivaswamy and Mr. Shatrunjay Rawat for their valuable reviews.

My special thanks to Dr. Vikram Jamwal (Sirji) for reviewing my thesis a number of

times, discussing the various viewpoints of my thesis, analyzing, and commenting on it.

Your motivation and support during the period of this thesis are extraordinary. Your witty

humor has helped me to keep myself cool.

Many thanks to the team at SERL, IIIT-Hyderabad (Kirti, Amit, Swathy,Bhudeb) headed

by Dr. Vasudeva Varma for providing their valuable support. My friends (big list) at IIIT-

Hyderabad have helped me in all regards. I would also like to thank IIIT-Hyderabad for

funding my education and most importantly providing a wonderful research

environment. Heartfelt thanks to TCS for providing me an opportunity to work with Prof.

Kesav V. Nori and contribute to the Adult Literacy Programme (ALP). I would like to

thank all the members of TCS Innovation Labs for Business Systems (BSCC) for

providing their valuable suggestions throughout the thesis – Mr. MGPL, Prof.

Viswanath, Swami Sir, Supriya, Padma, Doji, Raman, Sekhar, Tirumal, Ravi Shankar,

Nitin and all others. Mr. Jose Kumar needs a special mention for being so nice with me

and supporting in all circumstances so as Mr. Anand Kumar, without his tool this thesis

would not have been possible. My friends Anupam, Hemant, and Anandita at BSCC

have provided good discussions so as Nanaji.

Without the continuous drive of Mr. Azmath Ali, the practical realization of this thesis

would not have been possible. He has made me work and has not stopped working until

the work I have done reached the needy people. He made my dream of “Pragmatic

Research” possible. Thanks a lot Azmath. Special thanks to Mr. Amarendar Reddy

(Reddy garu) for showing the power of technology to help the needy people. Thanks to

Dr. F.C. Kohli for envisioning the idea of ALP, Prof. P.N Murthy garu for his contribution

to ALP and all members of ALP team (Sudeep, Pallavi) at TCS.

Thanks to Mr. Srihari Boregowda, director of Canarys Automations Ltd., Bangalore for

providing a research position in Component Factory, Scorpus Innovation Team and for

giving me the opportunity of doing Architecture & Process Consulting at such an early

stage of my career. His support has helped me in driving towards Software Factories

vision, which is the core part of this thesis. Special thanks to Prof. K.V. Dinesha of IIIT-

Bangalore, who has supported me whenever I am down both technically and personally.

Prof. C. A. R. Hoare requires a special mention for reviewing some parts of this thesis

and providing his valuable comments so as Prof. Dan Lee, who has given me an

opportunity to discuss about my thesis in broader context at an ISO/JTC1 SC7 Plenary.

Surprisingly, a number of spiritual gurus like Swami Sukhabodhananda, Chinna Jeeyar

Swamiji, Swami Sundara Chaitanyananda and others have helped me to relax during

the stress periods of this thesis. Thanks to all of them.

Finally and most importantly, I would like to thank my parents and brother for their

unprecedented love and support throughout the thesis (I cannot express my thanks

through words here). Oh My God!!! Many thanks to God!!!

Abstract

Illiteracy is an impediment to India’s development as approximately only 66% of the

population is literate, with about 150 million adult illiterates. Tata Consultancy Services

(TCS), an Indian Software House has initiated Adult Literacy Programme (ALP) as a

solution to adult illiteracy problem in India, developed ALP products under this initiative

and has made over 1,20,000 people literate across India. An ALP product is an

eLearning system that employs Computer Based Functional Literacy (CBFL) as the

underlying technology to teach adult illiterates of a particular language. However, the

goal of ALP initiative is to develop and maintain ALP products for 22 Indian languages

and their major dialects. The scope also includes development of ALP products to help

migrants from one linguistic region to another.

It is labor intensive to develop and maintain a family of ALP products because of the

enormous number and huge variety of products. The ALP Problem is concerned with

the automating the development of a family of ALP products. In this thesis, we present

ALP Factory as a solution to the ALP Problem, which has resulted significant

improvements in productivity levels of up to 89%. We have also developed Prerak

Training Factory that pertains to automating the development of training software for the

ALP family of products. We found that development of a family of eLearning Systems is

a common problem in developing computer-based systems for computer literacy,

technical literacy, vocational training, school education and thus presenting us with the

problem of automating software development.

Despite many decades of intensive research towards software industrialization and

software product lines to improve software productivity, the automation problem is a

daunting task. In this thesis, we propose TALES as an approach towards automating

the development of a family of eLearning Systems. This approach was borne out of our

experience of providing a solution to the ALP problem and inspired from traditional

manufacturing. This approach progresses by first gaining a deeper understanding of the

problem domain, designing a solution based on this understanding to handle the scale

and variety of software products. Then various kinds of standardization focusing on

product structure, production processes, and raw material are developed to provide a

standard platform that enables assembly and interchange of parts. The next step

involves the development of Virtual Assembly Lines that facilitate the automation of

production processes by weaving processes with tools and hence producing a family of

similar but distinct products. This approach is supported by repositories of components,

tools, and processes. The uniqueness of TALES approach is its ability to facilitate non-

technical users during software development.

Publications

Sridhar Chimalakonda, Kesav V. Nori, "Automating an eLearning

System - A Case Study," cseet, pp.150-153, 2009 22nd Conference

on Software Engineering Education and Training, 2009.

Sridhar Chimalakonda, Azmath Ali, Kesav V. Nori, “Transforming

Literacy through ICTs” Accepted as poster at IEEE Conference on

Technology for Humanitarian Challenges, 28th August, 2009,

Bangalore, India.

x

Contents

Table of Contents ............................................................................................... x

List of Figures .................................................................................................. xiii

List of Tables .................................................................................................... xv

1 Introduction ......................................................................................................... 1

1.1 Background & Motivation ............................................................................. 1

1.2 Problem Statement ...................................................................................... 2

1.2.1 The ALP Problem & Solution Outline .................................................... 4

1.2.2 The Automation Problem & Solution Outline ......................................... 5

1.3 Contributions of this Thesis ............................................................................ 6

1.4 Organization of the Thesis .............................................................................. 9

2 The ALP Case Study & Problem Domain Exploration ................................... 11

2.1 Broader Context of ALP Case Study ............................................................ 11

2.2 Problem Domain and National Literacy Mission ........................................... 12

2.3 Technology ................................................................................................... 13

2.3.1 Uniform Model and Methodology ........................................................ 14

2.3.2 An ALP Product .................................................................................. 16

2.3.3 The ALP Problem – One of the core challenges of this thesis ............ 17

2.3.4 Issues & Challenges ........................................................................... 20

2.4 Delivery Model .............................................................................................. 20

2.5 Problem Domain Exploration ........................................................................ 21

2.5.1 Understanding the “class of problems” ............................................... 21

2.5.2 Designing a solution in the problem domain ....................................... 22

3 Building a Standard Platform .......................................................................... 25

3.1 Motivation ..................................................................................................... 25

xi

3.2 Uniform Product Structure ............................................................................ 27

3.3 Standard Production Processes ................................................................... 29

3.4 Standard Components .................................................................................. 31

4 Automating Production Processes ................................................................. 33

4.1 Production Processes ................................................................................... 33

4.2 Automating Production Processes ................................................................ 36

4.2.1 ALP Product Structure Creation .......................................................... 37

4.2.2 ALP Dialect Generation ...................................................................... 39

4.3 Assembly Tool .............................................................................................. 40

4.4 Development of Products by Non-Technical Users ...................................... 42

5 Practice & Results ............................................................................................ 43

5.1 ALP Factory .................................................................................................. 43

5.2 Supporting Repositories in ALP Factory ....................................................... 45

5.3 Development of ALP products using ALP Factory ........................................ 46

5.3.1 ALP Base Product ............................................................................... 46

5.3.2 ALP Product-in-Dialect ........................................................................ 47

5.4 Evaluation ..................................................................................................... 48

5.4.1 Case Study: ALP Spanish – Illustration of creating ALP Product using

ALP Factory ................................................................................................. 50

5.4.2 Case Study: ALP Urdu-in-Telugu Dialect - Illustration of creating ALP

Product-in-Dialect using ALP Factory .......................................................... 53

5.5 Quantitative Analysis .................................................................................... 57

5.6 Prerak Training ............................................................................................. 69

5.6.1 Prerak Training Problem ..................................................................... 69

5.6.2 Design of Prerak Training Factory ...................................................... 71

6 The TALES Approach ....................................................................................... 78

6.1 Motivation ..................................................................................................... 78

6.2 Insights from ALP Factory and Prerak Training Factory Experience ............ 79

6.3 Insights from Traditional Manufacturing ........................................................ 80

6.4 The TALES Approach ................................................................................... 83

6.5 Problem Domain Exploration ........................................................................ 84

xii

6.6 Standardization ............................................................................................. 84

6.6.1 Role and Importance of Standardization ............................................. 85

6.6.2 Types of Standardization .................................................................... 86

6.7 Virtual Assembly Lines ................................................................................. 90

6.8 Supporting Repositories ............................................................................... 92

7 Related Work ..................................................................................................... 93

7.1 Revising Research Context .......................................................................... 93

7.2 ALP Factory and Related Work .................................................................... 94

7.2.1 ALP Problem and the classical M X N compiler problem .................... 94

7.2.2 ALP Factory and Compiler Compilers ................................................. 95

7.3 TALES Approach and Related Work ............................................................ 96

7.3.1 Automation Problem in a broader context ........................................... 96

7.3.2 Traditional approaches to improving productivity ................................ 97

7.3.3 Software Product Lines ....................................................................... 97

7.3.4 Towards Software Industrialization ................................................... 103

7.3.5 Discussion......................................................................................... 106

8 Conclusions & Future Work .......................................................................... 108

8.1 Conclusions ................................................................................................ 108

8.2 Contributions .............................................................................................. 109

8.3 Challenges .................................................................................................. 111

8.4 Future Research Directions ........................................................................ 113

9 Bibliography .................................................................................................... 116

xiii

List of Figures

2.1 Broader context of ALP case study ......................................................................... 12

2.2 Multimedia environment for an ALP product (CBFL) ............................................... 15

2.3 Phonetic model........................................................................................................ 15

2.4 Lesson structure ...................................................................................................... 15

2.5 A typical screenshot (called as scene) in an ALP product,…………………………. 17

2.6 Scope of ALP product variants ................................................................................ 17

2.7 Example of ALP product variants ............................................................................ 18

2.8 ALP Base Products developed by TCS .................................................................. 18

2.9 Evolution of “a class of problems” in problem domain ............................................. 22

2.10 Design of solution in the problem domain ............................................................. 23

3.1 Uniform standard structure for ALP family of products ............................................ 28

3.2 A standard production process ................................................................................ 30

3.3 Chapter process ...................................................................................................... 30

3.4 (A) Before standardization, (B) After standardization .............................................. 31

4.1 Production process (Top), Process step (Bottom) ................................................... 35

4.2 An example production process in ALP case study ................................................. 36

4.3 ALP Product Structure Creation process ................................................................. 37

4.4 Structure Factory Tool .......................................................................... 378

4.5 Generated product structure ................................................................................... 38

4.6 ALP Dialect Generation process ............................................................................. 39

4.7 eScript Code snippet for replacing sound elements in an ALP product ................... 41

5.1 Core components of ALP Factory ........................................................................... 44

5.2 Process of creating ALP base product using ALP Factory ...................................... 46

5.3 Process of creating ALP Product-in-Dialect using ALP Factory .............................. 47

5.4 Process of creating ALP Spanish Product using ALP Factory……………………….51

xiv

5.5 An excerpt from a lesson of instruction material for Spanish ………………………..52

5.6 A design template to create lessons of Spanish language showing the repository of

visual elements …………….…………………………………. ……………………………...52

5.7 ALP Spanish under development……………………………… ………………………53

5.8 Process of creating ALP Urdu-in-Telugu Dialect…………….. ………………………54

5.9 A scene from existing ALP Urdu product ………………………………………………55

5.10 A scene from Standardized ALP Urdu showing processed output of a tool ……...56

5.11 Tool generating sound report (Left) and generated report (Right)…………………56

5.12 Work breakdown structure of ALP Product (Showing at an outline view of 5)….. .59

5.13 Continued from Figure 5.12 showing remaining parts……… ………………………60

5.14 Work breakdown structure of ALP Product at Scene level (Outline view of 10)… 61

5.15 Comparison of Effort Distribution without and with ALP Factory ….……………....62

5.16 Effort Distribution of Sub-Systems in ALP Product………………………………......63

5.17 Sub-System Wise Effort Comparison without and with ALP Factory………………63

5.18 Effort Distrubution in a Chapter ………………………………………………………..64

5.19 Chapter Wise Effort Comparison without and with ALP Factory …………………..65

5.20 Scene Wise Effort Distribution…………….……………………………………….…..66

5.21 Scene Wise Effort Comparision without and with Factory ……………………….....66

5.22 Effort Distribution for creating an ALP Product-in-Dialect….………………………..67

5.23 Effort Comparison during Maintenance of ALP Product………………………….....68

5.24 Task Level Effort Comparison during Maintenance of ALP Product……………....69

5.25 Screenshot of development of prerak training software ........................................ 72

5.26 Uniform product structure for Prerak training software .......................................... 74

5.27 A high-level process during development of prerak training software ................... 75

5.28 Major components of Prerak Training Factory ...................................................... 77

6.1 Core activities of TALES approach........................................................................ 833

6.2 Product structure of a typical car ........................................................................... 877

6.3 Assembly operation ............................................................................................... 888

6.4 Standard parts & services in eLearning Systems .................................................. 888

6.5 Standardization in ALP case study ........................................................................ 900

6.6 Virtual Assembly Lines in ALP Case Study ............................................................. 91

xv

List of Tables

2.1 Scope of ALP products and their utility .................................................................... 19

5.1 Important tools in ALP Factory ................................................................................ 45

5.2 Overview of technologies for delivering training content ......................................... 72

5.3 Mapping between training content and technologies............................................... 73

6.1 Comparison of Traditional Manufacturing and Software Industry ............................ 81

8.1 Summary of contributions ...................................................................................... 109

1

Chapter 1

Introduction

In this chapter, we present an introduction to our work towards automating the

development of a family of eLearning Systems undertaken at Tata Consultancy

Services (TCS), an Indian Software House. We introduce the background to our work in

Section §1.1. We then present the problem statement in Section §1.2. Section §1.3

summarizes the main contributions of this thesis and Section §1.4 describes the

structure of this thesis.

1.1 Background & Motivation

There are nearly 150 million1 adult illiterates in India who can speak a language but

cannot read or write. To cater to this large chunk of population, Tata Consultancy

Services (TCS), an Indian Software House has initiated Adult Literacy Programme

(ALP) to aid speeding up the eradication of Adult Illiteracy in India, and developed ALP

products under this initiative. An ALP product is an eLearning system that employs

Computer Based Functional Literacy (CBFL) [87] [5] as the underlying technology to

teach adult illiterates of a particular language. ALP Products are based on National

Literacy Mission’s (NLM) 2 uniform approach for teaching adult illiterates and

1 According to Census of India, 2001

2 NLM was set up by the Government of India on 5 May 1988 with an aim to eradicate illiteracy in India.

CHAPTER 1. INTRODUCTION

2

instructional material was developed by State Resource Centers (SRCs)3 for each of

the Indian Languages and their major dialects.

TCS has developed ALP Products addressing 9 Indian languages, supported the

development of similar products for two African tribal languages and is currently

involved in the development of ALP Products for Spanish and Arabic Languages. Even

though this experience has shown the efficacy of using technology for teaching adult

illiterates which is evident in terms of making over 1,20,000 people literate across India

[29], the efforts of development and maintenance have been very high. Each of the

earlier efforts have taken anywhere between 5 to 6 person years for the initial versions

of the products. This huge amount of effort for developing and maintaining a single ALP

Product inhibits the use of technology as a means of teaching adult illiterates and thus

presents a strong need for reducing this amount of effort. This need is strengthened as

effort gets enormous because the scope of ALP initiative includes 22 Indian Languages

and their major dialects, and further presents the challenge of reducing the involvement

of technical people during ALP Product development.

This background has set the motivation to come up with software solutions that

significantly reduce human effort during development and maintenance of ALP products

and also envisages the need for studies in the area of software engineering for an

increased use of automation in software development processes.

1.2 Problem Statement

The input to this thesis work comes in the form of 9 ALP Products developed by TCS.

An analysis of these products revealed that the products are inconsistent and their

development is sporadic and unstructured requiring the need for redevelopment. ALP

Products addressing the rest of the Indian Languages (13) have to be developed from

scratch and delivering these products in any Indian Language Dialect as medium of

instruction calls for development of another set of ALP Products increasing the scope. If

3 SRCs are registered societies fully funded by Government of India to assist in the preparation of suitable

literacy primers for the illiterate adults and also provide academic and technical support to NLM.


3

the effort to develop and maintain a single ALP Product is 5 to 6 person-years, the effort

to develop and maintain this huge scale and variety of ALP Products is enormous. This

thesis is concerned with the problem of containment of the effort during development

and maintenance of ALP Products. In this thesis, we further demonstrate that the

approach adopted in containing the effort can be applicable to other examples of

eLearning Systems by presenting a study of use of this approach to facilitate the

training of (IT illiterate) teachers.

An analysis of the ALP Products (eLearning Systems) in the context of this thesis has

led to the observation that their software development does not involve writing code; but

on the other hand, involves organizing vast volumes of audio-visual data and

orchestrating their presentation using a multimedia platform, such as Macromedia

Flash. The ALP Case Study is a bare bones study of software development that did not

involve programming, but organizing a large scale of elements from which the required

software is composed and constructed. These kinds of systems are prime candidates

for software manufacturing and this thesis is concerned with demonstrating that a

manufacturing approach to software construction is possible in these kinds of systems.

To summarize, the research objectives of this thesis are formulated as follows:

To design and implement a software system that significantly reduces the human

effort during development and maintenance of a family of ALP Products and at

the same time addresses the complexity that arises from a large scale and

variety of products inherent in the problem.

To demonstrate that a manufacturing approach to software construction is

possible if the development of software systems involves little or no coding and if

the solution focuses on a specific family of systems rather than a single system.

More specifically, this thesis addresses the following problems outlined in Section

§1.2.1 and Section §1.2.2.


4

1.2.1 The ALP Problem & Solution Outline

TCS has developed ALP Products addressing 9 Indian languages but being a

multilingual society, India has 22 official languages4 and 3 dialects on average per

language. Hence, there is a definite need to develop ALP Products addressing each of

these languages and also delivering each of these products using their dialects as

medium of instruction. There are enormous possibilities open that extend the original

scope of ALP Products. An ALP product can be adapted to teach in any Indian

language dialect, so that migrants from other linguistic regions could learn using the

local language. Those who are not familiar with any Indian language could learn a local

language using an English version of the ALP Product. These possibilities lead to a total

of ((22 Languages X 3 Dialects) X (22 Languages X 3 Dialects)) ALP Products to be

developed. Considering the effort of 5.01 person years for each ALP Product,

development of ALP products at such a mass scale and huge variety is a major

challenge. The ALP Problem is concerned with significantly reducing the human

effort during development and maintenance of ALP Products and at the same

time addressing the scale and variety inherent in the problem. We elaborate the

ALP problem in Section §2.3.3 in the context of problem domain.

From a software engineering viewpoint, the ALP problem requires development of ((L X

D) X (L X D)) ALP products, for L languages and D dialects. This is similar to the

classical problem of making M X N compilers for M programming languages and N

machines [62]. Making each compiler is a manually intensive task and there is no end to

the possibility of new languages and machines. Despite decades of intellectual

research, compiler projects continue to be manually intensive. The PQCC experiment

[71] attempted the automated construction of high quality, highly optimizing compilers.

However, there is still a lot of intensive work in automating compiler construction mainly

because the focus was on tools and still the process of creating compilers required

expertise in invoking the tools in the process, providing inputs and interpreting the

outputs from the tools. On the other hand, the solution that this thesis provides is driven

4 Constitution of India, page 330, EIGHTH SCHEDULE, Articles 344 (1) and 351. Languages.


5

by processes, supported by tools and can be used by even non-technical people to

develop and maintain ALP Products.

1.2.2 The Automation Problem & Solution Outline

The ALP problem introduced in previous section focuses on the adult illiteracy problem

of India. However, adult illiteracy is a worldwide problem and there is enormous

possibility of developing eLearning Systems in integrating migrating linguistic groups

from one nation to another. With the emergence of computer based learning

environments as a powerful aid to teaching, there is a strong need to develop eLearning

Systems for a wide variety of scenarios like literacy, computer literacy, technical literacy,

vocational training, and eLearning Systems for school education. In Section §5.6, we

present the Prerak5 Training problem, that involves automating the development of

eLearning Systems for training material. These numerous possibilities present the

challenge of developing and maintaining an enormous number of similar but distinct

eLearning Systems. Our analysis of these kinds of eLearning Systems showed that their

development and maintenance involves little or no coding and hence making them

prime candidates for application of ideas from software manufacturing. Developing and

maintaining a family6 of eLearning Systems at such a mass scale and variety is a

daunting task. Thus, the Automation Problem is concerned with automating the

development of a family of eLearning Systems and also demonstrating that a

manufacturing approach to software construction is possible in these kinds of

systems.

The idea of solving “a class of problems”7 as opposed to a single problem was long

emphasized by David Parnas in [92]. The software industry has witnessed two decades

5 A Prerak is a person who has either passed or failed 10

th class (high school education) and facilitates

teaching adult illiterates by running an ALP Product. 6 We use the term family as defined by David Parnas in [92] to mean “studying a set of problems by first

studying the common properties of the set and then determining the special properties of the individual family members”. 7 We use the colloquial term “a class of problems” to refer to a set of problems in the problem domain.

The terms family and class are used interchangeably in this thesis.


6

of intensive research by the software product lines community that fosters reuse across

a class of problems or a market segment. The essence of software product lines is the

systematic and efficient creation of different products tailored to customers’ needs [27].

However, most of these efforts focused on developing systems that involve code

components whereas the eLearning Systems in the context of this thesis involve

multimedia components like visual and sound elements forcing us to develop an

approach that is suitable to these kinds of systems.

Software Factories [34] and Software industrial revolution [31] have long been proposed

as a silver bullet to software crisis several decades before, but still this vision remains

as an unfulfilled promise. The notion of mass production in the context of software was

first introduced in the famous NATO 1968 conference by John Mcrolly where the

famous statement “the software Industry is not industrialized” [80] was made. Despite

numerous advances in software construction, this affirmation remains valid today in

many aspects and is backed by the long history of software failure rates [61] [49] [42]

that are well documented in the literature. Recently, the idea of Software Factories [52]

was rejuvenated by Greenfield et al based on contributions from software product lines

community and other critical innovations of software engineering. Most of these efforts

have aimed at industrializing software development, however did not emphasize

enough on the principles of traditional manufacturing.

In this thesis, we demonstrate that a manufacturing approach to software construction is

possible by focusing on a family of eLearning Systems and then based on our

experience of addressing ALP Problem, Prerak Training Problem and inspiration from

traditional manufacturing, we propose TALES approach as a solution towards

automating the development of a family of eLearning Systems.

1.3 Contributions of this Thesis

Emerging from the context of engineering and a social innovative project, the

contributions of this thesis are three fold. To make an engineering contribution in terms

of developing a practical solution to ALP Problem and Prerak Training Problem, to make


7

an academic contribution in terms of demonstrating that a manufacturing approach to

software construction is possible, proposing an approach to the Automation Problem

and finally to make a contribution to the society by involving non-technical users during

production of ALP products.

The following are the main contributions of this thesis:

§1 ALP FACTORY: A SOLUTION TO THE ALP PROBLEM

Problem Statement: Provide a solution to the ALP problem i.e., How to significantly

reduce the effort during development and maintenance of ALP Products and at the

same time address the problem of scale and variety inherent in the problem?

Contribution: We present ALP Factory as the result of our experiment in developing a

solution to the ALP problem and show that drastic improvements in productivity can be

achieved. The major contributions under ALP Factory are:

A detailed understanding and analysis of the ALP problem domain and

identification of the ALP problem as a class of problems.

A demonstration of the need for an automated approach to solve the ALP

problem as it exhibits the characteristics of mass-scale and variety.

An illustration of the importance and use of an underlying uniform model

applicable to the ALP family of products.

A refinement of the ALP product into elements of problem domain and solution

domain as part of the design process in the problem domain.

A standard platform for the ALP family of products consisting of a uniform

product structure, standardized production processes and standardized

components.

Automation of production processes in ALP case study

o ALP Product Structure Creation process

o ALP Dialect Generation process

o Tools to automate process steps within a production process.


8

An illustration of the usage of an innovative assembly tool that automates the

development processes in ALP case study.

ALP Factory also enables non-technical users of NGOs and Government with

basic computer literacy to develop and maintain ALP products.

§2 TALES APPROACH: A SOLUTION TO THE AUTOMATION PROBLEM

Problem Statement: Provide a solution to the Automation problem i.e., How to automate

the development of a family of eLearning Systems if their software development

involves little or no coding?

Contribution: We propose TALES as a manufacturing approach to software construction

of a family of eLearning Systems.

The major contributions under TALES approach are:

A demonstration of the need for standardization as an underlying platform that

exploits the commonality of the problem domain and provides mechanisms for

producing a required variety of similar but distinct products.

An illustration of the role of standardization as a facilitator of assembly and

interchange of parts during development and maintenance.

Various kinds of standardization during the automation of a family of eLearning

Systems

Drawing inspiration from assembly lines of traditional manufacturing, we have

proposed the concept of virtual assembly lines in the context of software

development. Virtual assembly lines are created by composing processes and

weaving them with tools.

An illustration of the significance of component, tool and process repositories

during automation of software development processes.


9

1.4 Organization of the Thesis

In this chapter, we have provided an overview of the thesis. We have introduced ALP

Problem, Prerak Training Problem and the Automation Problem, and explained how

there is tremendous demand and pressure to automate the development of a family of

eLearning Systems. We have summarized the main contributions of this thesis in

previous section and we describe the structure of this thesis in this section. The

remainder of this thesis is organized as follows:

In Chapter §2, we introduce the ALP case study which is at the core of this thesis. We

present the background of the case study and then elaborate the challenges that arose

in the ALP problem. We discuss our understanding and analysis of the case study in

detail as this work forms a major part of problem domain exploration and provide the

design process of solution in the problem domain.

In Chapter §3, we provide motivation for building a standard platform. We present the

need for a uniform product structure and then present it in ALP case study. We then

present the standard processes that we have developed during the ALP case study and

finally we introduce the standard components that we have developed.

In Chapter §4, we illustrate how we have automated production processes in the ALP

case study. We illustrate the notion of a production process and then present a couple

of examples of automating production processes. We then present an assembly tool

that we have used during automation and finally we end the chapter by explaining how

automating production processes facilitates production of software by even non-

technical users.

In Chapter §5, we present ALP Factory, the practical system that resulted from building

a standard platform and automating production processes. We present the evaluation of

using ALP Factory by presenting two case studies. We then present the results of

speeding up the development of ALP Products and provide a detailed quantitative

analysis. We present the Prerak Training Problem and provide an outline of Prerak

Training Factory, which was developed on the similar lines of ALP Factory.


10

In Chapter §6, we present TALES approach as an academic contribution of this thesis.

We explain our insights of ALP Factory, Prerak Training Factory and learnings from

traditional manufacturing. We then present TALES as an approach towards automating

a family of eLearning Systems based on our experience and inspiration from traditional

manufacturing. We explain the importance of problem domain exploration; present

various kinds of standardization like product structure, production process, and raw

material; introduce the notion of virtual assembly lines that automate production

processes and then present the supporting repositories in our approach.

In Chapter §7, we present and explain the key ideas related to ALP problem,

Automation problem and discuss their solutions to the solutions provided in this thesis.

We explain how the TALES approach is related to software product lines, software

industrialization and provide a number of insights during this analysis.

In Chapter §8, we present the conclusions of our experiment in automating a family of

ALP products and summarize the TALES approach. We then summarize the

contributions of this thesis and provide some perspectives on future directions.

11

Chapter 2

The ALP Case Study & Problem Domain

Exploration

In this chapter, we present the ALP case study that provides the context for the ALP

problem of this thesis. In Section §2.1, we present ALP case study in the broader

context of adult illiteracy problem. The efforts of National Literacy Mission that are part

of the problem domain are explained in Section §2.2. Section §2.3 presents the

Technology aspect of the solution and TCS’ efforts towards the adult illiteracy problem.

Section §2.3.1 presents the uniform model and methodology that underlies the ALP

class of problems and Section §2.3.2 shows an instance of ALP product. Section §2.3.3

elaborates ALP problem of this thesis and Section §2.4 briefs the delivery model of ALP

products. The design of solution in problem domain is explained in Section §2.5.

2.1 Broader Context of ALP Case Study

“Illiteracy is a termite that has the potential to cripple the most powerful of the nations of

the world” and India is a persistent sufferer of this problem. A solution to this problem

requires collaboration, support, and resources from a number of organizations because

of the scale and variety of the problem. The major organizations/players and their

activities in speeding up adult literacy rate in India are shown in Figure §2.1. National

Literacy Mission (NLM) was set up by the Government of India on 5 May 1988 with an

CHAPTER 2. THE ALP CASE STUDY & PROBLEM DOMAIN EXPLORATION

12

aim to eradicate illiteracy in the country by imparting functional literacy to non-literates.

In the context of ALP case study, NLM has provided a uniform approach applicable for

all Indian languages and their major dialects. TCS has designed and developed

technology to deliver the instructional material. It has delivered a uniform model and

methodology to teach adult illiterates in the form of CBFL Technology. Delivering the

technology to adult illiterates in rural areas across India is a huge problem in itself.

Government and several NGOs have provided infrastructure and channels to deliver the

software to the needy people and bring the field feedback to technology players. These

three players collaborate and share feedback from each other to ultimately solve the

problem of adult illiteracy using Information and Communication Technologies (ICTs).

Figure 2.1 Broader context of ALP case study

The next sections of this chapter elaborate these three organizations, their activities and

responsibilities in relation to this thesis.

2.2 Problem Domain and National Literacy Mission

The 2001 census shows that approximately only 66% of the population in India is

literate, with about 150 million adult illiterates. This speaks of a large chunk of the

population that is far from the shores of knowledge, ignorant of the digital wealth of

information and unable to participate in the emerging Knowledge Based Society. NLM

took a major initiative to address the problem of adult illiteracy, devised its uniform

approach applicable to all Indian Languages and their major spoken dialects and the

State Resource Centres (SRCs) have delivered the instruction material based on this

Problem Domain (NLM)

•Uniform Approach applicable for all Indian Langauges

•State Resource Centers (SRCs) have provied instruction material

Technology (TCS)

•Uniform Teaching Methodology

•CBFL Technology

•ALP Factory (This Thesis)

Delivery (Gov, NGOs)

•Delivery Model

•Field Feedback


13

uniform approach. This instruction material is devised to deliver functional literacy,

which is defined by NLM as acquiring the skills of reading, writing and basic arithmetic

along with the ability to apply them to one’s day-to-day life [11]. Despite a number of

initiatives by NLM to eradicate illiteracy, literacy growth of 1.5% per year8 was nearly

equal to population growth, making total literacy a distant goal. Besides time, the current

literacy initiative, based on the traditional pedagogical methodology, was proving to be

very costly in terms of trained teachers, school facilities and other infrastructure.

2.3 Technology

TCS started its work in experimenting with information technology to aid in speeding up

the eradication of Adult Illiteracy in India in the year 2000. They called it Computer

Based Functional Literacy (CBFL) [87] as a part of their Adult Literacy Programme

(ALP). Their solution is based on the approach and instruction material created under

the aegis of the National Literacy Mission, through its affiliated State Resource Centres

(SRCs) in each of the (linguistically based) states or regions of India. This solution

involved teaching through words based on the instruction material designed by SRCs

and at the end of this, a learner is able to read and write the language. This ALP

programme includes working with Government Agencies and NGOs, apart from

volunteers from TCS. TCS has been donating used computers, their CBFL software,

and their time as a part of this programme. The programme has spread beyond its

original scope and is now addressing phonetic languages (such as European

Languages, Arabic, and tribal languages in South Africa). It is also being used to help

migrants of different linguistic communities in other linguistic regions.

The activities of technology undertaken by TCS are further divided into the following

challenges:

Develop a uniform model and methodology to teach adult illiterates that is

applicable to all Indian Languages and their major dialects (Section §2.3.1).

8 According to a report from National Sample Survey Organization (NSSO) - India’s official census agency


14

Design and development of software that uses ICTs to deliver this model

(Section §2.3.2).

Automate the development of software that uses ICTs to deliver this model

for all Indian Languages and their major dialects (This Thesis - Section

§2.3.3).

In this thesis, we focus only on technological challenges creating instances and

versions of ALP products in different languages i.e., the third challenge of automating

the development of ALP products We will also show how the efforts to achieve the first

two responsibilities have laid a foundation for the third responsibility.

2.3.1 Uniform Model and Methodology

The method of delivering instruction to adult illiterates requires a different philosophy

and methodology of teaching than teaching schoolchildren [67] [82]. TCS has

developed a uniform model and methodology to teach adult illiterates and that is

applicable to all Indian languages and their major dialects. In this model, the core

concepts to be conveyed are delivered by using reasoning technologies like case-

based, rule-based, and model-based reasoning, to support instruction as well as

assessment and feedback. Integrated approaches to teaching have been successful in

a number of cases as presented in [50] [76] [95]. Case-based reasoning is used to

derive new words from similar old words [2] while rule-based reasoning is used to

create rules of inference to cover all the cases required for imparting functional literacy.

Visual elements are used to introduce words, letters, and their associated sounds and

instruction are delivered using sound elements. Storyboard and puppet theatre models

are formed using the visual and sound elements as an effective means of delivering

instruction.

As shown in Figure §2.2, multimedia engine is used to integrate storyboard, reasoning

techniques and deliver the required instruction material on a single platform. This

methodology focuses on functional literacy as defined by NLM and involves teaching of

Reading, Writing, and Arithmetic skills. This uniform model and methodology is

applicable to environments to teach adult illiterates using ICTs. The significance of this


15

model is that it relies on an underlying sound philosophy as shown in Figure §2.3, which

is beyond the scope of this thesis. It employs the cognitive method, which is drawn from

the theory of cognition and laws of perception. As per the Cognitive Process, when one

reads, cognition takes place directly through the recognition of Graphic Patterns,

indirectly through Sound Patterns and inferentially through Feelings and Sensations.

Figure 2.2 Multimedia environment for an ALP product (CBFL)

Figure 2.3 Phonetic model Figure 2.4 Lesson structure


16

Figure §2.4 shows that the approach starts by presenting the common words and

phrases known to the adult illiterates by using visual elements. The words are then

broken down into composite sounds (syllables) and are associated with its graphic

presentation. Composite sounds are decomposed into simple sounds (vowels and

consonants) and are associated with their graphic presentation. This approach relies on

native intelligence and cognitive capabilities of adult illiterates to recognize patterns and

create associations. It arrives at the alphabet at the end of the course and equips the

learner with the ability to cope with unending variety of words through finite means of

composition with the alphabet.

The core idea here is to illustrate that every ALP product developed in the ALP initiative

relies on the model presented in this section and as this model is based on sound

theory, the ALP products work in principle.

2.3.2 An ALP Product

An ALP product is an extremely simple-to-use eLearning system that employs CBFL as

the underlying technology and is based on the philosophy and model in Section §2.3.1.

This solution uses animated graphics patterns for visualization and audio appreciation

for explaining the visual elements. Such a combination of graphic patterns of

visualization and repetition of sound patterns leads to recognition, retention, and recall

of words. The settings for the lessons are visually stimulating and crafted in a manner

so that learners can easily relate to their surroundings. The accompanying voiceover

reinforces the learner's ability to grasp the lessons easily, and repetition adds to the

strengthening of what is learned. Figure §2.5 shows a typical screenshot of a scene in

an ALP product. The system mainly consists of visual elements like letters, words,

logos, pictures and sound elements corresponding to the instructional material and

instructions. The culture of the language affects the screen of the ALP product. An ALP

product on an average consists of around 750 scenes like the one shown in Figure §2.5

and around 20,000 visual elements and 2,500 sound elements.


17

Figure 2.5 A typical screenshot (called as scene) in an ALP product, (1) Layers, (2) Visual elements on stage, (3) Sound elements on stage, (4) Visual elements and sound

elements in library, (5) Slate for exercises

2.3.3 The ALP Problem – One of the core challenges of this thesis

In this section, we elaborate the ALP

problem that we have introduced in Section

§1.2.1 of this thesis. Figure §2.6 shows the

scope of the ALP products targeted under

the ALP initiative corresponding to 22 Indian

languages, their major dialects, and Figure

§2.7 shows some of the Indian languages

and their major dialects.

Lang 1 (ALP product)

Dialect1

Dialect2

Dialect3

...


Dialect1

Dialect2

Dialect3

...

...

...

...

...

...


Dialect1

Dialect2

Dialect3

...

Figure 2.6 Scope of ALP product variants


18

An ALP Product has to be developed for each

language and their major dialects requiring

(22 X 3) products to be developed. However,

to teach any of the (22 X 3) language dialects

using any other language dialect the number

of products to be developed amounts to a

massive ((22 X 3) X (22 X 3)) (=4356)

products. We call these products as family of

ALP products and classify them as:

ALP Base Product: An ALP Base Product is a used to teach a language to adult

illiterates using its native language as medium of instruction. During this product

development, visual and sound elements are developed to teach the learning material

based on the uniform model and methodology described in Section §2.3.1. Figure §2.8

shows the ALP base products developed by TCS for 9 Indian languages. More recently,

TCS has started the development of ALP products for Arabic and Spanish.

Figure 2.7 Example of ALP product variants

Hindi

Khariboli (UP)

Brajbhasa

Bhojpuri

...

Marathi

Ahirani

Khandeshi

Konkani

...

...

...

Telugu

Rayalaseema

Telangana

Andhra

Figure 2.8 ALP Base Products developed by TCS


19

The need to teach a language to migrants from one linguistic region to another requires

development of ALP products. Teaching any Indian language in English is worthwhile

for people who cannot speak any Indian language. This adds another dimension to the

number of products to be developed. Once an ALP product has been sent to the field,

the experience results in new changes in the material and hence field learning should

be incorporated into the technology. Each time the request for changes come, a new

version of ALP product has to be developed making the scope, scale, and variety of

ALP products enormous. The products of ALP initiative exhibit two characteristics that

drive for an automated approach.

Mass-Scale: A large number of products have to be developed.

Variety: There is huge variety in the products to be developed. For example,

analyzing the different products in Figure §2.8 reveals that they have different

stages (user interface consisting of font, style, color of the letters and words)

based on the culture of the dialect.

Thus, the ALP problem deals with automating the development of ALP products based

on individual language/dialect requirements by assembling visual and sound elements.

In this thesis, we provide a solution to this problem of automating the development of

ALP products for all Indian languages and their major dialects or developing a family

of ALP products at a mass scale. Table §2.1 summarizes the scenarios and utility of

the family of ALP products. The core idea here is to demonstrate the need for a mass

scale of products rather than on the exact number of products.

Table 2.1 Scope of ALP products and their utility

Products Audience Comments

22 ALP products for 22

Indian Languages

Adult Illiterates of the

language

These are base products, which are

required to teach each of the 22 languages

e.g. Hindi, Telugu, Tamil

(22 X 3) products – with 3

dialects on average per

language

Adult Illiterates of the

language

Teaching adult illiterates using a dialect

requires these products

e.g. Hindi-in-Bhojpuri, Hindi-in-Khariboli


20

2.3.4 Issues & Challenges

We have found that the development of multimedia material and ALP products for

different Indian languages undertaken by TCS is sporadic and unstructured. During

development, there are many inconsistencies found in the instructional material and led

to even greater problems during maintenance and upgradation. The main concerns are:

The products that are developed for different languages by different teams do not

have consistent structure.

The product development process varies from one product to another product.

The cost of the product and the resources required to develop the product are

high and vary from one product to another.

These issues and challenges get elevated in case of ALP problem, as the goal is to

develop and maintain a huge number of similar but distinct products based on individual

language/dialect requirements and hence forcing for an automated approach. We will

provide our solution to these issues and challenges in forthcoming chapters.

2.4 Delivery Model

We have presented the uniform approach provided by NLM for all Indian languages and

their major dialects in Section §2.2. Section §2.3 exemplified how TCS came up with a

uniform model and methodology for all Indian languages and dialects, and the

technology to implement this model. The next challenge is to connect this technology to

the needy people i.e., reach 150 million adult illiterates especially in rural areas. This

responsibility is taken up by Government of India and NGOs. TCS has collaborated with

a number of NGOs throughout India for spread of ALP product. It has collaborated with

(22 X 3) X (22 X 3) ALP

Products

Immigrants from other

linguistic regions i.e.,

who do not know the

language

Teaching a language dialect using any

other language dialect.

e.g. Hindi (UP)-in-Telugu(Andhra)


21

Mahita NGO9 for the spread of ALP product in the state of Andhra Pradesh and recently

with The Siasasat NGO10 of Hyderabad to spread Urdu Version of ALP product. These

efforts have resulted in making 1,20,000 people literate across India. Government and

NGOs have setup a number of centres to deploy the software developed by TCS to

teach adult illiterates. However, providing infrastructure to run and facilitate ALP

products is a major challenge. Another major challenge of ALP initiative is to make the

development of ALP products extremely simple so that NGOs and Government can

develop and manage the product based on their requirements. This step rapidly speeds

up the spread of literacy, as a large number of non-technical resources are already

available with Government and NGOs, and using them to develop ALP products

reduces the effort in developing technology. In Section 4.4, we will show how we have

progressed towards solving this challenge by developing and using tools that facilitate

non-technical people to develop customized ALP products based on local requirements.

2.5 Problem Domain Exploration

In the earlier sections in this chapter, we have provided a detailed understanding and

analysis of the ALP case study. We concluded that the ALP problem is concerned with

“a class of problems” that are similar but distinct in nature rather than developing a

solution to a stand-alone problem. We also showed that because of the scale and

variety of ALP problem, there is a strong need to rely on a theory that underlies the

solution to ensure that the products work in principle. In this section, we will show how

this understanding has helped us in designing a solution in the problem domain.

2.5.1 Understanding the “class of problems”

A problem domain consists of a number of problems and the understanding of the

required “class of problems” evolves from a generic view of problem domain. This

process starts by understanding the problem domain at a high level and creating a

9 Established in 1994 with registration no. 5238/94, MAHITA. Web. 19 Oct. 2009. <http://www.mahita.in/>.

10 Established in 2002 with registration no. 125/2002.


22

boundary between various parts of the problem domain. Figure §2.9 shows one view of

the evolution of problems in the ALP case study. The evolution starts with the domain of

“Learning” and progresses towards an

approach involving ICTs that takes us to the

eLearning domain. India being a multilingual

society, the problem requires developing

eLearning systems for multilingual societies.

The focus of audience is on adult illiterates and

hence the problem focuses to teach adult

illiterates. The problem domain can have

number of other “class of problems”. For

example, a class of problems might be

development of eLearning systems to teach

computer literacy.

2.5.2 Designing a solution in the problem domain

We start the design of solution in the problem domain as it lays a strong foundation for

further activities. The process starts by understanding the problem domain and then

progressing towards a detailed analysis of the problem domain. Then parts11 of the

problem domain are continuously refined and relationships between the parts are

created. The core idea is to come up with a solution within the problem domain such

that there is a theory that we can rely on for developing a solution to the ALP class of

problems.

Figure §2.10 shows a portion of the refinement process and connection between the

parts of problem domain and solution domain12 of ALP case study. Columns (1) and (2)

represent the process in problem domain and columns (3) and (4) show the refinement

in the solution domain. The refinement process is continued until simple elements are

obtained and a clear demarcation between various parts is obtained.

11

The term part refers to systems, components, tools, and processes at different levels of granularity. 12

We use the term “solution domain” in this chapter to mean the solution within the problem domain.

Learning

eLearning

eLearning for Multlingual

Societies

eLearning for Adult Illiterates

Figure 2.9 Evolution of “a class of problems” in problem domain


23

(4) Refinement of parts in Solution Domain

(3) Parts in Solution Domain

(2) Refinement of parts in Problem Domain

(1) Parts in Problem Domain

ALP Product

Fundamental Principles

Cognition, Pedagogy Temporal

Dimension

Audio-Visual

Connection for words

Teaching Mode

Traditional Method

Functional Literacy

(Read, wRite, aRithm

etic)

Puppet Theatre Model

Reader Package

Writing Package

Arithmetic Package

eBook Package

Teach through words

New words

through old words

Forming words

through new

sounds

Learning Material

Choice , Number and Order of words

Source material

from NLM, Pictu

res

Books, Chapters, Scen

es

Audio Elements

Visual Elements

Package BooksFiling

Cabinet

Mode of delivery

Printed material

Primers as source

material

Electronic media

Flash movies

Phoneme Symbols

Movie Clips

Images

Figure 2.10 Design of solution in the problem domain


24

Let us consider the “Teaching Mode” part in the problem domain in column (1) and

analyze its refinement. The teaching mode is refined into three sub-parts “Traditional

Method”, “Functional Literacy” and “Teach through words”. NLM focuses on functional

literacy for the class of adult illiterates as that will be useful to them in their day-to-day

life. NLM has defined functional literacy through three 3 R's. Reading, wRiting and

aRithmetic. These skills were taught by using a puppet theatre model in the solution

domain and it has been further refined in the solution domain (column 4) by developing

three packages as sub-systems and an electronic version of instruction material

(eBook) is also developed. Adult illiterates are familiar with words but do not know how

to read or write hence the methodology to teach through words is better than teaching

through letters.

Letters are introduced through words, new words are introduced based on the old

words, and new sounds are introduced based on old sounds. Similarly, various parts of

the problem domain are analyzed and refined until clarity builds up and a common

structure is obtained in the solution domain. For example, Audio-visual connection is

maintained through the puppet show model and that is the basis of the temporal

dimension added in the solution domain.

The solution we have presented in this section is based on research done by NLM,

TCS’ CBFL and relies on theory of cognition and laws of perception as outlined in

Section §2.3.1. In the next couple of chapters, we explain how we have approached

towards solving the ALP problem by developing a solution based on this understanding

and analysis of the problem domain.

25

Chapter 3

Building a Standard Platform

In this chapter, we present a standard platform for the ALP class of problems that

provides an underlying structure and supports further activities of automation. Section

§3.1 provides motivation for building a standard platform. Section §3.2 presents a

uniform standard structure for the ALP class of problems. Standard production

processes in ALP case study are presented in Section §3.3 and Section §3.4 presents

the standard components of ALP products.

3.1 Motivation

In the previous chapter, we have shown that development and maintenance of the

family of ALP products is a huge challenge because of the mass scale and variety

inherent in the ALP problem. We have also presented the major issues and challenges

towards their development in Section §2.4. The major issues can be summarized as:

Lack of a consistent structure across all products.

Lack of a uniform development process for all products.

Lack of availability of components in a standard form during development of ALP

products.

CHAPTER 3. BUILDING A STANDARD PLATFORM

26

In addition to these, we have identified the following issues:

Reinventing the wheel for every product in terms of understanding the problem

domain and development process hampers resources.

Developers of one product cannot work immediately on other product.

Difficult to implement a unique teaching methodology across all products.

Sharing of knowledge and transfer of ideas between teams of different products

is difficult.

People management issues arise because of the scale and variety of products.

Difficult for users to learn multiple languages as all of them might not have a

consistent structure.

Maintenance of individual products becomes a challenge.

The first step towards achieving our goal of automating the development of the ALP

family of products (Section §2.3.3) is to overcome the above major issues and build a

standard platform that lays a foundation for further activities in automation. We have

presented the uniform model and methodology applicable for the ALP class of problems

in Section §2.3.1. A number of organizations like The IMS Global Learning Consortium,

Inc. (IMS), IEEE’s Learning Technology Standards Committee (LTSC), and

Subcommittee 36 (SC36) of International Standards Organization (ISO)’s Joint

Technical Committee 1(JTC1) have proposed standards in the area of eLearning

Systems [45]. However, most of these efforts have been towards building eLearning

Systems that are web-enabled, self-driven, and developed for an advanced learner

rather than an adult illiterate, which is the focus of this thesis. Standards are proposed

and practiced in the world of software in many areas such as standard specification of

software, standards in reuse, standard components, standard architecture, standard

processes, and technology standards but less emphasis was given to standards for a

class of problems [26].

A standard platform provides an underlying common structure from which new products

are efficiently developed [81]. Building a standard platform for a family of products

requires understanding the operational processes at root level and orchestrating them in

a form that will exploit the common nature of software products and at the same, which


27

can provide scope for implementation of variations. In this chapter, we explain how we

have approached towards a solution to some of the problems outlined in this section by

building a standard platform for the ALP family of products.

3.2 Uniform Product Structure

Product structure consists of the organization of systems, sub-systems, and

components of the product and their relationships. The existing ALP products for

different languages are developed by different teams at different locations. This has

resulted in the lack of a uniform product structure across the products leading to

inconsistency and a number of challenges in terms of product development and

maintenance. Considering the scale and variety of the family of ALP products, the

inconsistency problems created by different product structure for 4356 products are

enormous. An ALP product consists of around 20,000 visual and 2,500 sound elements

on an average, which are used to facilitate teaching of instruction material to adult

illiterates. Creating and maintaining a product structure consisting of such a large scale

of elements is a difficult task and hence creating and maintaining the family of ALP

products, each consisting of 22,500 elements is an enormous task. To overcome this

problem, we have created a uniform product structure that is applicable to the entire

family of ALP products with scope for variations.

Figure §3.1 [A] shows a portion of the logical standardized product structure that we

have created for the ALP family of products. The product structure at the top level

consists of Reader, Writing, Arithmetic, and eBook parts, which are further refined to

sub-systems and granular parts. This product structure is based on the uniform

instruction material provided by SRCs under the guidelines of NLM. The core concepts

of reading, writing, and basic arithmetic arrived during the research in problem domain

transformed to sub-systems in the product. The filing structure of the practical ALP

product and its relationship with the logical structure is shown in Figure §3.1 [B]. Every

ALP product in the ALP initiative will be derived from this uniform structure providing a

consistent view of product for developers and a standard structure that can be used for

processing by tools. From an external viewpoint, the Figure §3.1 shows that the product


28

structure is functional decomposition of products. However, standardization is not just a

functional decomposition of product but rather the first step towards componentization.

The interfaces between various parts are defined and the composition process of

various parts is also standardized during product structure standardization. However, a

more formal notation is required to capture the interface standards.

Figure 3.1 Uniform standard structure for ALP family of products


29

3.3 Standard Production Processes

The 9 ALP products developed by TCS have followed their own development process

resulting in a number of issues as presented in Section §2.3.4 and Section §3.1.

Consider the scenario of a different development process for the 4356 products in the

ALP initiative. The products that are created using these processes will be inconsistent

and even a single change requires huge amount of work. Standard production

processes mainly yield two huge benefits. One is consistent product structure across

the products and the other is process automation. The goal of automating the

production of ALP products is well supported by employing tools in standard production

processes.

Tools can automate processes when they are made explicit and are modeled at a level

of detail. Hence, for each of the sub-systems in the product, a process is modeled and

all of these sub-processes are integrated in a certain order to make up the production

process. The production process consists of process steps in a certain order and at

each of the process step; a tool(s) takes the raw material, processes it, and delivers the

product to the next step. The experience of building a number of products in the

problem domain decides the production process and is embedded in the processes and

tools. Processes can be automated by employing tools at each of the process steps.

We have modeled standard production processes during development of ALP products

by using a modified version of finite state machines (FSMs) [109]. Each state of FSM

represents a process step along with the events that trigger the process steps and the

corresponding actions. For every element; be it a system, component or a simple

element, we can track the element, where it is used and how it interfaces with other

parts of the system using the FSMs developed.

Figure §3.2 shows a high-level process of a typical ALP product. This production

process is the composition of sub-processes for Reader, Writer and Arithmetic and each

of these processes are refined to further granular levels. For example, the Reader

process consists of Books organized into Chapters and which further consists of


30

Scenes. A process at the Chapter level is at a low level of granularity consisting of the

flow of the Scenes. The “link” action is used to compose production processes. The

Chapter process shown in Figure §3.3, which starts with an “Intro Process” followed by

“Title Process” that introduces the title of the chapter. The required number of

phonemes and words are explained in their corresponding processes followed by an

“Exercise Process” and an end scene. The development process of individual scenes is

also standardized in a similar way. The next level of granularity of “Exercise process” is

presented in Section §4.1 during production process automation.

Figure 3.2 A standard production process

Figure 3.3 Chapter process


31

3.4 Standard Components

Visual and sound elements are the major components in an ALP product. Automating

the development of ALP products requires these components to be available in a

standard form such that tools can process them. We have introduced a standard

nomenclature to designate each of the elements that are present in the product

structure. Every element has a prefix like Bookm, Chaptern and Sceneo, where m, n, o

represent respective Book, Chapter and Scene as per the standard naming

NameofElement_Type_No. Figure §3.4 [A] shows the elements before standardization

and Figure §3.4 [B] after standardization. As can be noticed from this figure, the names

Figure 3.4 (A) Before standardization, (B) After standardization


32

of the elements before standardization cannot be processed by a tool whereas after

standardization, tools can process the elements based on standard nomenclature. We

have also introduced standards for font, size, and color of visual elements, and format

and duration for sound elements. This standardization creates a huge benefit during the

maintenance of the product. A common requirement for the ALP product is to change

an element across the product based on a new requirement. A visual or audio element

is typically present in 750 scenes of the product and to accommodate the change, a

change has to be made at 750 places. This standardization in place has allowed us to

write a script that replaces the existing element with the new element at 750 places at

once making the maintenance easier.

Developing ALP Product-in-Dialect involves development of ALP product for various

dialects from an existing base product using local dialect as the medium of instruction.

This means that an ALP product has to be developed to teach a given language L1

using its different dialects D1, D2, D3 as medium of instruction. To achieve this, the

sound elements in the base product should be replaced by sound elements of the local

dialect. All the elements of the product are organized in a folder, in a computer filing

cabinet as it were, in a specified manner as per the standard, so that when an ALP

product is invoked with this new folder, a newly edited version of an earlier developed

ALP product that reflects new requirements is available. This can be achieved only

when the existing ALP product and new sound elements are in a standard form.

In this chapter, we have presented the standard platform consisting of a uniform product

structure, standard production processes, and standard components that lay a

foundation for further activities of automation. The lessons learned from this effort of

building a standard platform have evolved into the important aspect of standardization in

our approach which is detailed in Section §6.6. In the next chapter, we will see how we

have automated production processes by leveraging on the standard platform built in

this chapter.

33

Chapter 4

Automating Production Processes

In this chapter, we illustrate how we have automated production processes in the ALP

case study. Section §4.1 introduces the notion of production processes and describes a

couple of production processes in the ALP case study. Section §4.2 describes the most

important production processes that we have automated in the ALP case study. Section

§4.3 presents the assembly tool that facilitated the automation of production processes

in ALP case study and Section §4.4 explains how ALP Dialect Generation facilitates

non-technical users during development of ALP product variants.

4.1 Production Processes

Development of the ALP family of products within TCS happened at different locations

in India developed by different teams. A major challenge of this approach is that the

product development process varies from one product to another product leading to an

extensive work by the teams in understanding and developing a process for every ALP

product. Because of the scale and variety in the ALP problem, there is a strong need to

come up with standardized processes across the development of family of ALP

products. This need was strengthened by the automation goal of this thesis. In Section

CHAPTER 4. AUTOMATING PRODUCTION PROCESSES

34

§3.3, we have presented the need for standard production processes in ALP case study

and in this chapter, we present a couple of production processes in ALP case study and

show how we have automated these production processes.

We have observed and analyzed development of two ALP products performed by four

developers and came up with standard processes for production. We have used screen

recording tools to record their activities on screen and to identify the exact tasks they

perform during development. We have then analyzed the work patterns and came up

with standard ways of performing the activities. As mentioned in Section §3.3, we have

modeled these processes using finite state machines. We have performed this activity

of developing production processes for most of the time consuming activities during

development. Even though there are differences between how individual developers

work, we have observed that most of the tasks can be performed in standard ways

leading us for the development of standard production processes. We have also created

a process repository of most time-consuming tasks in the case study. We have detailed

the processes by identifying the input and output for every process step such that tools

can process them.

Our goal in this thesis has been not just to come up with standard production processes

but most importantly to automate them. Towards this end, we have made an important

decision that affected our research. We have modeled the processes at a granular level

of detail such that only atomic tasks are present in the process. If automation has to be

enabled by replacing a person with a tool, then the process has to be detailed enough

such that only the simple things that can be done by computer are specified in the

process. This led us to the following core principle:

“Only simple things can be automated”. This was the dictum followed in the

development of PQCC, Production Quality Compiler Compiler project [71] enunciated

by Bill Wulf, who directed this research. The core idea of this principle is that

complicated things require human labor and this hampers our goal of automation.

Therefore, complicated things should be iteratively refined until we get to the simplest

things. Simple things can be automated by employing tools and does not require human

labor. This means that the production processes should be detailed enough with clear


35

inputs and outputs such that a tool can automate the process. This requires an

expertise of performing the process manually to model and automate the processes.

We consider a production process as a standard way of producing products (interim or

final) or services. It consists of a sequence of process steps and each of these process

steps takes raw material as input, transforms the raw material into interim or finished

products.

Figure 4.1 Production process (Top), Process step (Bottom)

Figure §4.1 shows a simple structure of a production process and a process step. The

raw material in this figure can be components, processes, or tools. We will elaborate

these through specific examples in this section. The output of a process step can be an

interim product to be processed by next step or final product. The sequence of process

steps executed in a certain order to accomplish a task is called a production process.

An ALP product teaches adult illiterates using multimedia elements and as part of this,

exercises are given to the students to test the students whether they have understood

the phonemes and words introduced in chapters. An exercise scene is thus developed

for every chapter (there are 24 chapters in an ALP product) of the product which means

that 24 exercise scenes have to be developed for every product. Figure §4.2 shows the

“development process of exercise scene” as followed by software developers during

development. The purpose of demonstrating this process is to illustrate that myriad of

details are required to automate production processes and most importantly, these

processes can be modeled only if the manual process is clearly understood. The states

represent the state of the product at that point of time. For example, the state “Jumbled

Phonemes” means that the phonemes placed on the scene are already jumbled and the

Process Step1

Process Step2

...Process Step n

Product

Raw MaterialTransformation

ProcessProduct

(Interim/Final)


36

state “Inserted Sound” means that sound is inserted into the scene. The transitions

represent the actions that are to be performed to go to the next state. The action “drag

& drop” means that certain objects have to be dragged and dropped on to the screen

and “convert” means that some objects have to be converted to clips. In addition to this,

the inputs for each of the process steps are tagged along with the outputs.

Figure 4.2 An example production process in ALP case study

Developing production processes is a painful exercise but the investment in this activity

can be reused across the development of a family of products. This is a onetime activity

and can be refined if the development process changes. The level of detail in the

processes facilitates automation. High-level production processes are composed of

primitive production processes that generate parts of the standard product structure.

4.2 Automating Production Processes

A fundamental motivation for an automated approach to ALP problem is to reduce the

human labor that is required for the development of the ALP family of products (4356).

The goal of improving productivity at a mass-scale requires this human labor to be

supported or even replaced by tools. With the efforts of problem domain exploration,

standardization and tools, we have composed production processes and weaved them


37

with tools to facilitate automation. In this section, we present automation of two of the

most important production processes in ALP case study.

ALP Product Structure Creation

ALP Dialect Generation

4.2.1 ALP Product Structure Creation

The ALP product structure consists of around 20,000 visual and 2,500 sound elements

organized into acts, scenes, chapters, books and so on. The standard structure of this

product is explained in Section §3.2. The development of every ALP product involves

creation of this massive structure and this process consumes a lot of time during

development. We have developed ALP Product Structure Creation, which creates the

entire ALP product structure based on standard nomenclature and a set of templates.

Figure 4.3 ALP Product Structure Creation process

Figure §4.3 shows the high-level production process that creates this mammoth

physical structure of the product. It consists of four production processes, the input for

each process is shown in the first row, and the transformed input is shown in the third

row. The output of one production process acts as an input to the next production

NLM Primers

•Standard Nomenclature

Standard Design

•Design Stage, Items

Configuration ItemsStructure Factory

Tool

Create Standard Product

Structure

Design ALP Templates

Product Configuration

Generate Product

Product Structure

• Filing Cabinet Structure TemplatesProduct

ConfigurationPhysical Product

Structure


38

process along with other inputs. Each of these production processes is supported by

tools.

The first production process transforms the instructional material into a standard form as

defined by the standard nomenclature. The second production process takes the

standard design of all the lessons and produces templates for them. The required

elements of the product are configured in the third process and the fourth process

generates the physical product structure by assembling the required product

configuration items.

Figure 4.4 Structure Factory Tool Figure 4.5 Generated product structure

Figure §4.4 shows the tool that we have developed and used to create the product

structure. This tool takes templates and production configuration as input and creates

the physical product structure that is shown in Figure §4.5. This physical structure

consists of 30 folders, each folder on average contains 25 files, and each of the file

consists of around 30 elements amounting to generation of around 20,000 elements.


39

The generated product structure has to be manually customized based on the specific

needs of the ALP product.

4.2.2 ALP Dialect Generation

Teaching a given Indian language dialect using any other language dialect is one of the

major class of products in the ALP initiative. A special property of these products is that

visual part of the product remains same where as the sound elements or medium of

instruction varies between product to product. This fact is exploited by ALP Dialect

Generation (Figure §4.6) process to generate an ALP Product-in-Dialect from an

existing ALP product.

Figure 4.6 ALP Dialect Generation process

The first production process in Figure §4.6 is the process of re-engineering the existing

product to a standard form. The sound elements after this process are in a standard

form and can be replaced by sound elements for the new dialect. We have created a

tool that will extract the sound elements from an existing product and standardizes them

as per the nomenclature and this step is performed in the second production process.

The new sound elements have to be recorded in the required dialect and the script for

Existing Product; Nomenclature

Existing ProductScript for new

sound elements

Standard Product, Sound

elements

Standardize Existing Product

Extract Sound

Elements

Develop new sound

elements

Sound Factory

Standard ProductSound Elements (Filing Cabinet)

New Sound Elements (Filing

Cabinet)

ALP Product for choosen dialect


40

this is developed during the third production process. On an average, around 2500

sound elements of duration ranging from 2 seconds to 10 minutes have to be

developed. This process is carried out by language experts and is still a manual

process. Emergence of tools from language research for converting sounds in one

language to another language at required levels of quality will enable automating this

process also. The standard product along with new sound elements allows the creation

of ALP Product-in-Dialect. We have generated this product by interchanging the parts of

an existing product with new parts and re-assembling them. Interchange of parts is

possible because of standardization of components.

4.3 Assembly Tool

Automating production processes requires composition of low level processes with tools

and to achieve this, we have used an assembly tool called eScript [4]. eScript is a an

innovative tool developed at TCS Innovation Labs for Business Systems, Hyderabad.

The core idea of eScript is the use of screen scraping technology to automate repetitive,

resource intensive and rote menial tasks. It relies on the fact that the actions performed

during development process must manifest in the form of some screen actions. For

example, the developer starts by opening an Integrated Development Environment

(IDE), and the actions might include opening the IDE by clicking an icon or using a

keyboard shortcut. eScript replicates these actions through a programming system as if

they are performed by the developer. This requires modeling production processes at a

lower level of detail consisting of only primitive operations as we have shown in the

exercise process in Section §4.1. In our case study, for example, the activity “insert”

means that some object has to be inserted into an application. Given the detailed set of

actions that a developer performs, eScript replicates those actions without human

involvement and hence acting as a robot. We have used eScript to compose low-level

processes and invoke actions without human intervention and thus enabling

automation. We have also used other technologies like Java Script Flash Language

(JSFL), Visual Basic and Visual C++ for developing tools. However, eScript acts an


41

assembly tool that invokes a number of other tools and performs actions without human

intervention.

Figure §4.7 shows a fragment of an eScript code snippet. A deeper look at the script

shows that the commands in eScript code are used to invoke actions that are performed

by developer. For example, the developer has to open the multimedia authoring

environment to work on developing the ALP product. The command StartApplication

(line no.10) is used to perform this task. Then some actions are invoked through the

menu items of multimedia authoring environment. This is achieved by invoking the

ActivateMenu command (line no.14). A developer performs navigation and uses

keyboard and mouse to do some tasks. The commands NavigateInScreen (line no.18)

and MouseClick (not shown in figure) are used to achieve this. eScript also has other

commands that help in automating production processes.

Figure 4.7 eScript Code snippet for replacing sound elements in an ALP product


42

We have learnt that the standardization platform that was established earlier has laid a

foundation for automation by tools. The input raw material is available in a standard

form and the standard processes will transform the input into standard output. This level

of standardization at various levels has allowed for complete automation by even

replacing human labor with assembly tools. However, still manual involvement is

required to customize the product based on specific needs.

4.4 Development of Products by Non-Technical Users

The availability of ALP Dialect Generation and an assembly tool like eScript has

introduced a new way of developing ALP products by facilitating non-technical users to

perform the tasks as if performed by an expert. This is possible by bundling the

knowledge and experience of the experts in processes and tools to automate production

processes. In case of ALP case study, the scale and the variety of products requires

huge number of developers as well as language experts. We have developed

standardization, sound extraction and sound factory tools for non-technical users,

especially NGOs with no technical knowledge and minimum computer literacy. With

this effort of standardization and automating production processes, the ALP product for

a local dialect can be produced by NGOs by providing sound elements of new dialect as

input to our tools. TCS has been collaborating with a number of NGOs (Mahita for

Telugu language, Siasat for Urdu language) for delivering CBFL with the burden of

developing ALP products on its own. The work undertaken during this thesis enables

TCS to delegate the development of product variants to NGOs by providing a set of

processes and tools. We have piloted this approach to generate a portion of Urdu-in-

Telugu product and have been successful. We are planning to delegate the task of

creating script and recording sound elements to the local governments such that they

can produce the ALP product based on local requirements.

In the next chapter, we will explain the result of our engineering efforts towards

automating the family of ALP products, Prerak Training Problem, and our solution to it.

43

Chapter 5

Practice & Results

In this chapter, we summarize the engineering contribution of this thesis along with the

results of this effort. Section §5.1 presents the ALP Factory that we have developed as

a solution to the ALP problem. We then present the supporting repositories of ALP

Factory in Section §5.2. The process of developing ALP products using ALP Factory is

explained in Section §5.3. In Section §5.4, we present evaluation of ALP Factory using

two case studies. A detailed quantitative analysis of effort reduction is presented in

Section §5.5. We brief the Prerak Training Problem that is similar to the ALP problem in

Section §5.6.1 and explain Prerak Training Factory as a solution to it in Section §5.6.2.

5.1 ALP Factory

The ALP problem that we have presented in Section §1.2.1 is concerned with

automating the development of ALP products corresponding to all Indian languages and

their major dialects. More generally, the ALP problem is concerned with the scale and

variety inherent in the ALP family of products. We have presented how we have tackled

this problem by exploring and analyzing the problem domain (Chapter §2), building a

standard platform (Chapter §3), and automating production processes (Chapter §4)

throughout the thesis. In this section, we summarize the ALP Factory that resulted from

CHAPTER 5. PRACTICE & RESULTS

44

our experience of automating the development of the ALP family of products. An ALP

Factory essentially comprises of a set of standard processes, tools, and components

that facilitate production of ALP products even by non-technical users and with

minimum human labor.

Figure 5.1 Core components of ALP Factory

ALP Factory mainly consists of four core components as shown in Figure §5.1. A

solution from the problem domain forms the basis for further activities of ALP Factory.

ALP Factory consists of a standard platform comprising of a uniform product structure, a

filing cabinet structure at the implementation level that is applicable to all ALP products,

standard processes of developing the product, standard components that assist during

this process and a number of automated production processes composed using the

assembly tool eScript. ALP Factory also consists of supporting repositories and a

number of tools like Standardization Factory, Sound Factory among others, that assist

in automating process steps or which can be used as stand-alone tools. We have

explained each of the components shown in Figure §5.1 throughout the thesis. Table

Problem Domain Exploration

• Uniform model and methodology for ALP class of problems

• CBFL Technology

• Design of solution in the problem domain

A Standard Platform

• Uniform product structure based on a standard nomenclature

• Standard production processes for development of sub-systems like Reader, Writing and others.

• Standard visual and sound elements

Automated production proceses

• Standardization process

• Sound extraction process

• Product structure creation process

• Dialect generation process

Repositories & Tools

• Components Repository

• Process Repository

• Tools Repository

ALP Factory


45

§5.1 summarizes the specific tools we have developed during ALP Factory. The goal of

these tools is to capture expert’s experience and enable a novice user without this

experience to perform the same tasks at accepted levels of productivity and quality. In

the next section, we explain the repositories of components, tools, and processes that

we have developed to support the ALP Factory.

Table 5.1 Important tools in ALP Factory

Tools Brief Description

Standardization

Factory

Converts an existing ALP product consisting of around 20,000 visual

elements and around 2,500 sound elements as per standard

nomenclature.

Structure Factory Creates 40% of ALP product by generating 640 scenes and organizes

them into packages based on standard product structure.

Sound Extraction

Factory

Extracts sound elements (around 2,500) of an existing ALP product and

places them in a standard filing cabinet structure.

Sound Factory

Replaces around 2,500 sound elements of an existing ALP product with

sound elements of new dialect in a single step.

5.2 Supporting Repositories in ALP Factory

Throughout the thesis, we have emphasized the significance of various kinds of

repositories that played a supporting role in our approach. In this section, we explain the

various kinds of repositories that we have developed in the context of ALP case study.

Components Repository: Visual and sound elements are the major components of an

ALP product. We have created repositories of visual as well sound elements that are

common across the ALP family of products. The elements in the repository are as per

the standard nomenclature and are designed to be customized. ALP Factory provides a

common components repository for every new product generated from it.

Tools Repository: As part of ALP Factory, we have created a repository of tools that

enhances productivity and quality of ALP products. eScript is a significant tool that

needs special mention in our repository of tools. We have used this tool to automate


46

development processes. We have illustrated this tool in Section §4.3 and summarized

the other tools of ALP Factory in previous section.

Process Repository: The notion of process repository plays a crucial role in our

approach as all the ideas we have developed revolve around processes. Process

repository consists of the most important processes of ALP case study modeled at a

granular level of detail. Chapter §4 of this thesis has detailed a couple of processes in

ALP case study.

5.3 Development of ALP products using ALP Factory

We have explained two types of ALP products in Section §2.3.3. ALP Base Product aids

in teaching a language to adult illiterates using its native language as medium of

instruction and an ALP Product-in-Dialect version aids in teaching a language using any

Indian language dialect as medium of instruction. The ALP Factory that we have

developed during this thesis can be used to develop either of these products. In this

section, we briefly explain the development process of these products.

5.3.1 ALP Base Product

A high-level process of creating an ALP base

product using ALP Factory is shown in Figure

§5.2. The process starts by analyzing the

primers from NLM for the corresponding

language and organizing the content for ALP

Factory. A set of templates representing parts of

standard product structure are designed based

on culture of the language. The required sub-

systems like Reader, Writing and other parts of

an ALP product are configured based on

requirements of the specific product. The creation Figure 5.2 Process of creating

ALP base product using ALP

Factory

Organize content for ALP Factory

Standardization Design templates

Structure Factory

Configure ALP product

Customize generated product

NLM primers


47

of the ALP base product is done by using Structure Factory tool, which is essentially the

ALP product structure creation process illustrated in Section §4.2.1. This process

creates only 40% of the ALP base product and hence it is required to customize the

generated product based on specific requirements. The creation of ALP base product is

supported by providing a repository of common components, which reduces the

development effort. The standard processes of development make it easy for the

developer to change only the required parts and hence improve productivity. We have

also developed additional tools to support the creation of an ALP base product. For

example, “publish all” tool publishes all scenes (around 740) of an ALP product at once.

5.3.2 ALP Product-in-Dialect

The process of developing an ALP Product-in-

Dialect version is shown in Figure §5.3. This

process is essentially based on the dialect

generation process illustrated in Section §4.2.2.

The process starts by standardizing an existing

base product, developing sound elements in

new dialect, and applying the ALP factory tools

on the base product. The existing base product

is standardized using Standardization Factory

tool. Sound Extraction tool extracts all the sound

elements from a base product and places them

according to the standard nomenclature. We

have also developed a tool that provides a

sound report consisting of information about all

the sound elements, such that the sound elements developed for new dialect are as per

standards. These sound elements and sound report are provided as input to language

experts for development of sound elements in new dialect. Sound Factory is applied

with base product and sound elements of new dialect as input, which generates an ALP

Product-in-dialect variant of the existing product.

Standardization

Sound Extraction & Report

Sound Factory

Develop sound elements for new

dialect

ALP Product-in-Dialect

Existing ALP base product

Figure 5.3 Process of creating ALP

Product-in-Dialect using ALP Factory


48

5.4 Evaluation

The central goal of ALP Factory is to reduce human effort during development and

maintenance of ALP Products and we have tried to achieve this goal by automating the

software development processes; however the automation process would still require

some amount of manual effort in terms of providing raw material to ALP Factory and

customizing the generated product. Table §5.2 lists the key raw material required in

constructing an ALP Product and ALP Product-in-Dialect, along with the format of the

raw material and the effort of creating it. For example, instruction material and script for

sound elements are two mandatory inputs that can come either in print material or in

electronic form. In case of Indian Languages, the instruction material comes from SRCs

under the aegis of NLM but in case of other languages the instruction material has to be

created from scratch. During our analysis of existing ALP Products, we came to know

that there are special cases like ALP Urdu, ALP Spanish, and ALP Arabic where the

instruction material was created by language experts and the effort for creating the

instruction material varied from language to language. Creating visual and sound

elements are two inputs that require most of the manual effort even while using ALP

Factory. The table also shows that creating a dialect version of an existing ALP Product

requires fewer amounts of raw material and customization and is the best case where

minimum amount of effort is required to create ALP Product-in-Dialect. On the other

hand, creating an ALP Product from scratch requires more raw material and

customization. It requires around 708.13 person-hours to customize a generated ALP

Product whereas it takes only 2.5 person-hours to create the final product in case of

ALP Product-in-Dialect. However, in case of an ALP Product-in-Dialect, it is assumed

that an existing ALP Product is provided as input and is amenable for standardization

The source of data in this table comes from project management reports of ALP Product

which are created by measuring the effort for creating each of the raw materials and the

effort in converting this raw material to products. A detailed explanation of the effort

distribution and customization are given in the later part of this section.


49

Table 5.2 Effort of key inputs required for creating an ALP Product and ALP Product-in-

Dialect

Input/Raw Material Format

ALP Product ALP Product-in-

Dialect

Required Effort

(Person-hours)

Required Effort

(Person-hours)

Instruction Material Print material/ Electronic form

- -

Design Templates Flash Templates 32hrs -

Visual Elements Bitmaps, Graphics 163hrs -

Script for sound elements Print material / Electronic form

160hrs 150hrs

Sound Elements Wav and MP3 100hrs 100hrs

Existing ALP Product Flash source

files/Directory structure

- -

Sound Duration Report Excel report 0.08hrs

Effort in creating raw material required for ALP Factory

455hrs 250.08

hrs

Effort for generating the products using ALP Factory

2hrs 12hrs

Effort for customizing the products 708.13

hrs 2.5hrs

Total Effort for creating final products

1165.13hrs (0.55

person-years)

264.58hrs

(0.15 person-years)

We have used ALP Factory to develop ALP Spanish, ALP Arabic and parts of ALP

Kannada and also piloted ALP Urdu-in-Telugu and ALP Telugu-in-Urdu Products. With

the background presented in this section, we present the case study of ALP Spanish to

illustrate the process of developing an ALP Product using ALP Factory and ALP Urdu-

in-Telugu Dialect to illustrate the process of developing ALP Product-in-Dialect using

ALP Factory.


50

5.4.1 Case Study: ALP Spanish – Illustration of creating ALP Product

using ALP Factory

We have used ALP Factory to significantly reduce development effort of ALP Spanish

product. ALP Spanish is a special case of ALP products as it is not an Indian language

and does not have instruction material associated with it. However, TCS has

collaborated with a Spanish Scholar at EFL University (English and Foreign

Languages), Hyderabad and came up with instruction material which is in accordance

with the uniform methodology of NLM. We are involved during the software

development of ALP Spanish product and Figure §5.4 outlines the key activities during

this process along with inputs (first row) and outputs (last row) at each of the steps.

The process shown in Figure §5.4 basically creates 40% of ALP Product consisting of

the directory structure (around 740 scenes) organized according to the uniform product

structure presented in Section §3.2, a set of tool and component repositories. The

content in this structure is filled by populating the flash development environment with

tools and invoking them through processes. Further customization of the generated

product requires around 0.55 person-years, which essentially means that 89% of the

development work is automated through this process. (Effort detail is presented in

Section §5.5). To summarize, the inputs for generating an ALP Product are instruction

material (available for all Indian languages and their major dialects provided by NLM

and SRCs), a set of design templates and ALP Factory.


51

Figure 5.4 Process of creating ALP Spanish Product using ALP Factory

Create instruction material for Spanish language

• NLM Primers, Teaching Methodology are provided as guidance (Input)

• This manual step is specifically for Spanish language as instruction material is not available. However, this step can be skipped in case of Indian languages as the instruction material is provided by NLM, SRCs.

• Instruction material for Spanish language (Fig §5.5 - (Output))

Design templates

• Instruction material for Spanish language, Templates of standard product structure

• This is a manual step where templates for Spanish language are derived from standard templates provided along with ALP Factory and are customized for Spanish.

• Static templates for creating ALP Spanish product structure (Fig §5.6)

Configure ALP Product

• Static templates for creating ALP Spanish product structure

• Structure Factory

• Product Configuration

Create ALP Product

• Product Configuration

• ALP Factory

• ALP Spanish product structure consisting of 40% of the product along with component and tool repositories

Customize Generated ALP Product

• ALP Spanish product structure

• This is a manual step where the generated ALP Spanish product structure has to be customized and content has to be filled

• ALP Spanish Product (Fig §5.7)


52

Figure 5.6 A design template to create lessons of Spanish language showing the

repository of visual elements.

Figure 5.5 An excerpt from a lesson of instruction material for Spanish


53

Figure 5.7 ALP Spanish under development

5.4.2 Case Study: ALP Urdu-in-Telugu Dialect - Illustration of creating

ALP Product-in-Dialect using ALP Factory

ALP Urdu was developed by TCS and was deployed on field in collaboration with Siasat

Daily, a newspaper in Urdu and also an NGO based out of Hyderabad. This was field

tested across various centers in Hyderabad and made around 9,000 people literate. A

major request was to produce ALP Urdu version with Telugu as medium of instruction

such that people who know Telugu can learn Urdu. This essentially means that visual

part of the ALP Product (Urdu) remains intact where as the medium of instruction

changes to Telugu. We have used ALP Factory to create a piloted version of ALP Urdu-

in-Telugu product. Figure §5.8 outlines the key activities during creation of ALP Urdu-in-

Telugu Dialect along with inputs and outputs at each of the steps.


54

Figure 5.8 Process of creating ALP Urdu-in-Telugu Dialect

Standardize existing product

• ALP Urdu – Base Product (Fig §5.9) - Input

• Standardization Factory

• ALP Urdu in standard form with each and every element following standard nomenclature (Output)

Extract sound elements from standard ALP Urdu product

• Standardized ALP Urdu (Fig §5.10)

• Sound Extraction Factory

• Extracted sound elements organized as per standard nomenclature i.e., Sound Elements in Urdu (Folder)

Generate sound duration report

• Sound Elements in Urdu (Fig §5.11– Left)

• Sound Report Generation

• Report of sound duration of all sound elements i.e., Sound elements in Urdu with duration (Fig §5.11– Right)

Create script for sound elements

• Sound Elements in Urdu

• This is a manual step where a language expert listens to Urdu sound elements and writes the script for Telugu sound elements

• Script for Telugu Sound Elements

Record sound elements as per new dialect

• Script for Telugu Sound Elements, Standard Sound Elements Folder, Generated Sound Report (Fig §5.11 – Right)

• This is a manual step where a language expert records sound elements based on the script

• Sound elements in Telugu organized as per standard nomenclature

Create ALP Urdu-in-Telugu Dialect

• Standardized ALP Urdu, Sound Elements in Telugu

• Sound Factory

• ALP Urdu-in-Telugu Dialect


55

To summarize, the inputs for generating an ALP Product-in-Dialect are ALP Product,

Sound Elements in Required Dialect and ALP Factory. Hence, for producing an ALP

Product-in-Dialect, the only manual effort required is to write the script and record 2,500

sound elements in new dialect and the rest of the work is automated with ALP Factory.

Given an ALP Product and the sound elements in required dialect in specified format,

an ALP Product-in-Dialect can be produced in less than 0.15 person-years (Effort detail

is presented in Section §5.5).

Figure 5.9 A scene from existing ALP Urdu product


56

Figure 5.10 A scene from Standardized ALP Urdu showing processed output of a tool

Figure 5.11 Tool generating sound report (Left) and generated report (Right)


57

5.5 Quantitative Analysis

Development of an ALP Product essentially has two key effort intensive activities:

Creating the product structure (directory structure) in accordance to the

instruction material.

Filling the product structure by performing tasks in flash development

environment.

and we have addressed these two major activities in ALP Factory to reduce the effort.

In this section, we will present the work breakdown structure of an ALP Product along

with the effort of creating the product without and with ALP Factory. We have used

Microsoft Project Professional13 to document the project management activities and

used the following metrics to calculate the effort during ALP Product Development.

person-hour: A unit of one hour’s work done by one person is person-hour.

person-day: Amount of work done by one person in one working day and in the context

of this thesis, a person-day is equivalent to an amount of work done in 8 person-hours.

person-month: Amount of work done by one person in a month and in the context of this

thesis, amount of work done in 22 person-days i.e., 176 person-hours.

person-year: Amount of work done by one person in a year and in the context of this

thesis, amount of work done in 12 person-months i.e., 2112 person-hours.

We use person-hours to detail the effort for each of the tasks and activities during ALP

Product development.

Figure §5.12 and Figure §5.13 show the work break down structure of an ALP Product.

This structure is essentially based on the uniform product structure described in Section

§3.2 but drills down to a detail level and shows the tasks to be performed to create the

13

Microsoft Project Professional is a project management tool that assists projects managers in developing plans, assigning resources to tasks, tracking progress, managing budgets and analyzing workloads.


58

individual parts of the product structure at different levels. This work break down

structure was created during project planning phase of ALP Product by the project

manager and then each of the individual tasks is assigned to the available resources

(developers). The estimated effort for each of the individual tasks is assigned by project

manager and the responsibility of completing those tasks is left with the developers.

The second column in Figure §5.12 shows the effort of creating the specific parts of the

product structure without using ALP Factory. The data in this column represents the

actual effort put in by the developers for completing the tasks and this data was entered

by developers during actual ALP Product development. The next column shows the

effort for completing each of the tasks using ALP Factory. We have populated this data

by performing each of the individual tasks using ALP Factory and filling the effort for

every task. The effort required for most of the atomic tasks during ALP Product

development is measured in the order of minutes however when this details are entered

into the project management tool, the effort is converted into person-hours by the tool.

Also, the amount of effort for cumulative tasks is automatically calculated by the tool

based on the effort entered for atomic tasks. For example, the cumulative effort for an

Act is calculated by the tool given the effort for the scenes in that act.

To develop an ALP Product without ALP Factory, the cumulative amount of effort is

10,589.75 person-hours (2112 person-hours * 5.01) i.e., 5.01 person-years and the

effort to develop the same product using ALP Factory is 1165.13 person-hours (0.55

person-years). This does not include the initial effort of creating ALP Factory which

amounts to 1.5 person-years. However, as the factory was built as part of research

work, this effort includes a number of other activities which do not directly contribute to

ALP Factory and hence this effort cannot be directly considered under production effort.


59

Figure 5.12 Work breakdown structure of ALP Product (Showing at an outline view of 5)


60

Figure 5.13 Continued from Figure 5.12 showing remaining parts


61

Figure §5.14 shows the work break down structure to develop a scene in an ALP

Product. A scene at the physical product structure is a flash development file which will

be filled by the content of instruction material by performing a sequence of operations in

the flash development environment. The work patterns of 740 scenes in an ALP Product

are similar but the specific inputs for every task vary during the development of scenes.

Figure 5.14 Work breakdown structure of ALP Product at Scene level (Showing at an

outline view of 10)


62

Based on the data available from Figures §5.12, §5.13, §5.14 which are essentially the

project management reports of ALP Product Development, we present a number of

charts showing the effort distribution for different parts of ALP Product and then

compare the efforts distribution without and with ALP Factory.

Figure §5.15 shows the comparison of effort to develop and maintain an ALP Product

and ALP Product-in-Dialect without and with ALP Factory. The amount of work to be

done has been reduced from 5.01 person-years to 0.55 person-years in case of an ALP

Product amounting to 89% reduction in the effort whereas in case of an ALP Product-in-

Dialect, the amount of work to be done has been reduced from 0.6 person-years to 0.15

person-years amounting to 75% reduction in the amount of work to be done. The

remaining percent of the work has to be done manually and of which most of the effort

is towards development of visual and sound elements.

5.01

0.60.550.15

0

1

2

3

4

5

6

ALP Base Product ALP Product-in-Dialect

Pe

rso

n-Y

eas

Figure 5.15. Comparison of Effort Distribution without and with ALP Factory

Without ALP Factory With ALP Factory

Reduction in Effort 89%

%

75%


63

Figure §5.16 shows the distribution of

effort across different sub-systems of

an ALP Product. The Reader sub-

system constitutes 42% of the effort

in an entire ALP Product and eBook

part requires 13% of the effort. The

reduction of effort using ALP Factory

for each of the sub-systems is shown

in Figure §5.17. The chart shows that

a significant amount of reduction was

achieved in all the sub-systems with

most significant reduction in case of Arithmetic sub-system. The percentage of

reduction in effort using ALP Factory for each of the sub-systems is also shown in the

chart and the rest of the work has to be done manually.

88.74% 89.24% 95.65% 73.52%

0.00

500.00

1,000.00

1,500.00

2,000.00

2,500.00

3,000.00

3,500.00

Reader Writing Arithmetic eBook

Effo

rt in

per

son

ho

urs

Figure 5.17. Sub-System Wise Effort Comparison without and with ALP Factory


42%

30%

15%

13%

Figure 5.16. Effort Distribution of Sub-Systems in ALP Product

Reader

Writing

Arithmetic

eBook


64

There are 27 Chapters in an ALP Product organized into Books in Reader, Writing and

eBook sub-systems according to the instruction material as well as the work break down

structure. Hence this constitutes a huge amount of effort during ALP Product

Development. Even though every chapter is unique in its content, development of a

Chapter constitutes similar tasks across all chapters. A Chapter is divided into a

succession of Acts and the effort involved in creating each of the acts is shown in Figure

§5.18. During the creation of a chapter, the act of forming words (Act 3) constitutes

most of the effort (27%) while the act of introducing new sounds and words constitutes

13% of the effort.

The reduction of effort during the creation of acts in a chapter without and with ALP

Factory is shown in Figure §5.19. On an average, the effort to create an act without

using ALP Factory is around 22 person-hours and this has been reduced to less than 5

person-hours using ALP Factory. The chart shows the reduction for one chapter

whereas considering the number of chapters (27) in an ALP Product, the amount of

effort reduced is significant.

19%

14%

27%

13%

13%

14%

Figure 5.18. Effort Distribution in a Chapter

Act 1 (Introduction)

Act 2 (Comparing Sounds)

Act 3 (Forming Words)

Act 4 (Sentences)

Act 5 (New Sounds and Words)

Act 6 (Exercise & Summary)


65

Throughout the thesis, we have repeated that an ALP Product consists of 740 scenes

and development of scenes involves performing a series of operations in flash

development environment to fill the structure. In Figure §5.20, we present the key tasks

involved during development of a scene. The chart shows that 29% of the effort in

creating scenes is to create layers corresponding to stage, sound, button and so on. Of

all the tasks, most part of creating visual and sound elements still has to be done

manually even while using ALP Factory. The reduction of effort in development of a

scene by using ALP Factory is shown in Figure §5.21. The chart shows the effort to

create layers has almost been nullified as most of the tasks related to this work are

automated using ALP Factory. It can be observed that even though creation of visual

elements is supported by component repositories, the reduction of effort is less as still

the visual elements have to be created manually. Creation of sound elements involves

writing the script for the sound and recording the sound elements. On an average, the

amount of effort to create a scene has been reduced from 9 person-hours to 1.5 person-

hours using ALP Factory.

0

5

10

15

20

25

30

35

40

Act 1 (Introduction

Act 2 (Comparing

Sounds)

Act 3 (Forming Words)

Act 4 (Sentences)

Act 5 (New Sounds and

Words)

Act 6 (Exercise & Summary)

Effo

rt in

Pe

rso

n H

ou

rsFigure 5.19. Chapter Wise Effort Comparison without and with

ALP Factory

Without ALP Factory ALP Factory


66

5%

29%

19%10%

10%

5%

10%

10%

2%

Figure 5.20. Scene Wise Effort Distribution

Creating Stage

Creating Layers

Variable Layers for Alphabets

Creating Timelines

Creating Animation (Motion Tweens)

Creating Keyframes

Creating Visual Elements

Creating Sound Elements

Setting Properties of Visual & Sound Elements

0

0.5

1

1.5

2

2.5

3

3.5

Creating Stage

Creating Layers

Variable Layers for Alphabets

Creating Timelines

Creating Animation

(Motion Tweens)

Creating Keyframes

Creating Visual

Elements

Creating Sound

Elements

Setting Properties of Visual & Sound Elements

Effo

rt in

Pe

rso

n H

ou

rs

Figure 5.21. Scene Wise Effort Comparision without and with Factory



67

Figure §5.22 shows the effort distribution for creating an ALP Product-in-Dialect. The

chart shows that most of the effort while creating an ALP Product-in-Dialect is in

creating the script for sound elements (57%) and for recording the sound elements

(38%). It should be noted that these tasks are largely independent of technology and

can be performed by even non-technical people. The technical tasks involved in

creating the product are reduced to less than 5% using ALP Factory and even these

tasks are performed by the assembly tool eScript thus minimizing the need for technical

people during development. Table §5.3 shows the effort details for creating an ALP

Product-in-Dialect.

Table 5.3 Effort Distribution for creating an ALP Product-in-Dialect

Activity/Task Effort (Person-Hours)

ALP Product-in-Dialect 264.58 hrs

Standardize an existing ALP Product 2 hrs

Extract sound elements from standard ALP Product 0.5 hrs

Generate sound duration 0.08 hrs

Create script for sound elements 150 hrs

Record sound elements as per new dialect 100 hrs

Create ALP Product-in-Dialect 12 hrs

1% 0%0%

57%

38%

4%

Figure 5.22 . Effort Distribution for creating an ALP Product-in-Dialect

Standardize an existing ALP Product

Extract sound elements from standard ALP Product

Generate sound duration

Create script for sound elements

Record sound elements as per new dialect

Create ALP Product-in-Dialect


68

The effort reduction during maintenance of an ALP Product for individual sub-systems is

shown in Figure §5.23. The overall effort to maintain an ALP Product without using ALP

Factory is 2837 person-hours and the effort using ALP Factory is 227.02 person-hours

leading to 91.9% reduction in effort. This reduction in effort is possible as ALP Factory

enables assembling of ALP Product given the directory structure and the inputs for

making changes. However, assembly of ALP Product works when the expected inputs

are as per the standard nomenclature. The most common tasks during maintenance

and the effort reduction using ALP Factory are shown in Figure §5.24. It should be

noticed that the effort for the task “Creating Inputs for Change” is same without and with

ALP Factory i.e., the inputs like visual elements and sound elements have to be created

manually and should be given as input to ALP Factory.

To summarize, the charts presented in this section detail the effort in creating ALP

Products without and with ALP Factory and all of these quantitative details are with

respect to the development and maintenance of a single ALP Product. However, one

major goal of this thesis is cater to a family of ALP Products ((22 X 3) X (22 X3)) and

considering such a large scale of products, the amount of savings to be had is

0

200

400

600

800

1,000

1,200

Reader Writing Arithmetic eBook

Effo

rt in

Pe

rso

n H

ou

rs

Figure 5.23. Effort Comparison during Maintenance of ALP Product



69

enormous and hence emphasizing the significance and impact of the work presented in

this thesis.

5.6 Prerak Training

In this section, we will briefly present Prerak Training Factory, which we have developed

as a preliminary solution to Prerak Training Problem. During the development of Prerak

Training Factory, we followed a similar process that we have used for ALP Factory.

5.6.1 Prerak Training Problem

We have presented the ALP Problem that exhibits the characteristics of mass scale and

variety in Section §2.3.3. We then illustrated our solution to this problem by automating

the development of ALP products and explained it throughout the thesis. In this section,

we present the Prerak Training problem that is similar to the ALP problem. Delivering

ALP products to adult illiterates of corresponding language or dialect is a major

0

100

200

300

400

500

600

700

800

Changing Visual Elements

Changing Sound Elements

Animation Changes

Changing Stage Creating Inputs for Change

Effo

rt in

Pe

rso

n H

ou

rs

Figure 5.24. Task Level Effort Comparison during Maintenance of ALP Product



70

challenge that needs to be addressed. We have briefed about delivering ALP product to

adult illiterates with the support of Government and NGOs in Section §2.4. Prerak is the

person who facilitates this delivery by running and teaching an ALP product at the

centres14 created and maintained by Government or NGOs. Teaching adult illiterates of

a particular language using ALP products does not require a trained teacher as teaching

instructions are embedded in the product. However, necessary training has to given to

preraks to facilitate the running and teaching of a language using ALP products. A

prerak is a person who has studied 9th or 10th class or sometimes even studied less and

has some basic leadership qualities, and who can effectively run a class. The current

mode of delivering prerak training by TCS is to conduct a workshop by inviting preraks

to TCS office or sending a trainer to the respective centres of Governments or NGOs

along with distribution of physical training material under the programme called as

“Training the Trainer”. However, TCS’ experience of using this mode of delivering

training is constrained by following issues and challenges:

Firstly, technical resources and infrastructure are required to facilitate training.

Providing training to a number of preraks and at a number of centres in a uniform

way is a daunting task.

Another major challenge is to motivate preraks to attend the training programme.

Preraks may not know how to effectively read and understand the physical

training material.

To combat the above challenges, we have proposed the use of eLearning Systems

(training software) to assist the training process. The idea is to distribute training

software along with ALP products, such that the preraks can train themselves by using

this training software at their own place and at a convenient time. However, the major

challenge of this proposal is to develop the training software for every ALP product in

the ALP initiative.

The Prerak Training problem is concerned with automating the development of training

software for the ALP family of products. This means that the training software has to be

14

National Literacy Mission has set up Continuing Education Centres (CECs) at village level to promote literacy under Continuing Education scheme and NGOs have setup their own centres.


71

developed and customized for every ALP product corresponding to a language or

dialect. We have designed and implemented Prerak Training Factory as a preliminary

solution to the Prerak Training problem in the similar lines of ALP Factory. This solution

consists of a standard platform for creating the prerak training material and automates

some of the development processes.

5.6.2 Design of Prerak Training Factory

The design of Prerak Training Factory involves an additional step than the design of

ALP Factory. We have proposed the use of eLearning Systems to assist prerak training

and hence there is no prior version of prerak training software available to us. We have

developed a version of prerak training software based on material prepared by TCS and

then progressed towards the design of Prerak Training Factory. The design process

starts by understanding and analyzing the problem domain, building a standard platform

for the class of problems, automating production processes and then developing

repositories to support the factory. In this section, we will explain each of these aspects.

(i) Prerak Training Software

The core idea of prerak training software is to present the training material developed by

TCS in an extremely simple form to preraks by exploiting multimedia technologies. We

found that various parts of the training material have to be presented using different

technologies for effective delivery of training. The major formats we have considered for

delivering various parts of the training material during the development of prerak training

software are summarized in Table §5.4.

We have analyzed each of these technologies for their applicability in the context of

prerak training software. For example, an audio format is good for providing motivation

to the preraks and explaining the process of teaching. Screencasts 15 are useful to

explain how to open an ALP product and navigate through various parts of the product.

15

Screencasts are recordings of computer screen activities in a digital medium supported by audio narration of events happening on the screen [90].


72

We concluded that an integrated approach comprising of a number of technologies to

deliver various parts of training material makes the delivery of prerak training effective.

Table 5.4 Overview of technologies for delivering training content

Figure §5.25 shows a screenshot during development of prerak training software. This

screencast teaches navigating through various chapters of the ALP product and using

the menu items of ALP product. Figure §5.25 also shows that the screencast uses a

Method Format of material

Digital material The textual training material is presented in electronic form.

Audio Audio explanations of the training material is provided.

Video A movie or DVD that presents prerak training content is developed.

Presentation Presentations along with voiceover are used to explain the content.

Multimedia software Multimedia software based on prerak training content is developed.

Screencasts Screencasts are developed for various parts of the content.

Integrated Approach Various parts of the content can be developed using different ways

such as video, text, audio, screencasts, and other formats.

Figure 5.25 Screenshot of development of prerak training software


73

visual screen for explaining ALP product (1), audio for narrating the instructions (2), text

annotations to describe parts of the screen (3) and subtitles to explain the narration (4).

We have analyzed the training material and technologies, and mapped between various

parts of the training material and appropriate technologies suitable to deliver the

material. Table §5.5 shows a portion of the mapping. For example, the usage of ALP

product is delivered by creating a screencast, providing a narration of the usage of ALP

product and developing a presentation that explains its usage.

Table 5.5 Overview of technologies for delivering training content

However, the goal of Prerak Training Factory is to develop this training software for the

ALP family of products. In the rest of this chapter, we will explain the process that we

have followed in coming with a solution to the Prerak Training Problem.

(ii) Problem Domain Exploration

We have explained in Section §2.1 that TCS’ responsibility is to develop ALP products

and delivering ALP products is the responsibility of a number of organizations like

Government and NGOs. However, TCS also has the responsibility of providing training

to preraks on the usage of ALP products. Collaborating with a number of Government

Agencies and NGOs, and driven by field experience, TCS’ field experts have developed

a uniform training material suitable across all the languages. We came up with a

Content Training Format

Overview/Adult Literacy Programme Audio + Presentation

Overview/ALP Product Screencast + Audio + Presentation

Overview/ALP on the field Audio + Presentation

Computer Literacy Audio + Video + Presentation

ALP Product usage Screencast + Audio + Presentation

ALP Factory usage Screencast + Audio + Presentation

Centre maintenance Audio + Presentation + Excel


74

customized version of this uniform training material that forms the basis for development

of prerak training software.

(iii) Building a Standard Platform

In this section, we present the standard platform that we have built as part of Prerak

Training Factory.

Uniform product structure

Based on the training material

developed during problem domain

exploration, we came up with a uniform

product structure for prerak training

software. A portion of this uniform

product structure is shown in Figure §5.6

[A] and its corresponding folder structure

showing various formats of the training

software is shown in Figure §5.6 [B].

We have developed various parts of

prerak training using appropriate

technologies. For example, the overview

module consists of an introduction to

adult literacy programme, its importance,

creation, and maintenance of centres for

running ALP products. This module is

delivered using audio instruction and

illustrated using pictures. Installation and

navigation process of ALP products is

illustrated using screencasts. One of the

important contributions of ALP Factory is

to enable non-technical users in Figure 5.26 Uniform product structure for Prerak training software


75

development of ALP products. Preraks with basic computer literacy can use ALP

Factory to develop and customize ALP products. Hence, we have developed a training

module for ALP Factory usage. We have used videos and screencasts to deliver the

training modules for corresponding ALP products and developed them in different

languages.

Standard Production Processes

Figure §5.27 shows a high-level process during development of a typical prerak training

software. This production process is the composition of sub-processes for training

modules of Overview, Computer Literacy, Product Training, and Factory Training. Each

of these processes is refined to further granular level of detail until atomic tasks are

obtained. For example, Product Training process further consists of modules for

navigating main menu of ALP product, teaching process of Reader, Writing, Arithmetic,

and eBook. The “link” action is used to compose production processes. On the similar

lines of developing processes in ALP Factory, we have developed standard production

processes for most time-consuming parts of developing prerak training software. We

made sure that development processes are made explicit, are modeled at a granular

level of detail, and reflect the operational process followed by developers.

Some of the processes that a Prerak has to perform during his role:

Operating the computer

o Procedure for switching “ON” computer

Figure 5.17 A high-level process during development of prerak training software


76

o Procedure for switching “OFF” computer

Surfing through lessons

Preparation and Facilitation

o Process before starting the class

o Starting the class

o Conducting the class

o Concluding the class

General Troubleshooting

Training software should consist of modules corresponding to each of these processes.

(iv) Automating Production Processes

Producing training material for Preraks in the language of an ALP product is crucial

considering the background of Prerak. We have analyzed the contents of training

material developed during problem domain exploration, and observed that most parts of

training material are common across the ALP family of products. This requires the

instruction medium of prerak training software to be in a local dialect. We have adapted

the dialect generation process explained in Section §4.2.2 to suit this scenario.

The use of different technologies to deliver various parts of training material requires

different development processes. The two major inputs of automating training software

development are (i) standard prerak training software and (ii) sound elements of new

dialect. We have developed a script using our assembly tool eScript that uses these two

inputs and replaces the sound elements in standard product with new sound elements,

and hence generating training software for different ALP products. However, the prerak

training software is still maturing to reach a standard level and thus needs few more

phases of refinements.

(v) Repositories & Tools


77

We have developed repositories of components, tools, and processes that support

Prerak Training Factory. The presence of different technologies has forced us to use

different tools during development process. We have used screencast tools to create

videos and screencasts corresponding to various parts of training material. We have

used sound tools to record the instructions for training material. Most importantly, we

have used the assembly tool eScript to invoke various tools and achieve automation.

Figure §5.28 presents the concrete output of our efforts towards developing Prerak

Training Factory. It mainly consists of a uniform instruction material and teaching

methodology, a standard platform consisting of a uniform product structure and

standard development processes. We have automated the production processes for

development of training material for ALP product usage and ALP Factory usage. We

have also used tools for different technologies along with the assembly tool eScript.

However, the Prerak Training Factory that we have developed during this thesis is still

under revision. Nevertheless, it has provided further illustration of our approach.

In the next chapter, we will present the TALES approach that provides a solution to the

Automation problem introduced in Section §1.2.2.

Problem Domain Exploration

• Uniform instruction material for preraks

• Uniform teaching methodology to train the trainers

A Standard Platform

• Uniform product structure

• Standard production processes for development of sub-systems like Computer Literacy, ALP Product, and ALP Factory usage

Automated production proceses

• ALP Product usage

• ALP Factory usage

Repositories & Tools

• eScript

• Screencast Tools

• Sound Tools

Prerak Training Factory

Figure 5.28 Major components of Prerak Training Factory

78

Chapter 6

The TALES Approach

(Towards Automating the Development

of a Family of eLearning Systems)

In this chapter, we present an approach towards automating the development of a

family of eLearning Systems. Section §6.1 presents the motivation for our approach.

Section §6.2 describes the insights from our experience of ALP Factory and Prerak

Training Factory. Section §6.3 explains the insights from manufacturing that we use to

develop our approach. Section §6.4 provides pointers to various activities of TALES

approach. Problem domain exploration is explained in Section §6.5. Section §6.6

explains various kinds of standardization and their significance in TALES approach.

Section §6.7 describes the notion of Virtual Assembly Lines and finally in Section §6.8,

we brief the supporting repositories of TALES approach.

6.1 Motivation

The Automation Problem that we have presented in Section §1.2.2, demands for an

approach towards automating the development of a family of eLearning Systems. The

CHAPTER 6. THE TALES APPROACH

79

major motivation for such an approach is the ever-increasing usage of computers as an

aid to teaching in a wide variety of scenarios and the pressure on software industry to

produce a number of similar but distinct eLearning Systems at higher levels of

productivity and quality. eLearning Systems for multilingual societies like India involve

another dimension in terms of delivering these systems in multiple languages. The ALP

problem and Prerak Training problem that we have presented in this thesis cater to the

development of a number of similar but distinct eLearning Systems.

An analysis of ALP Problem, Prerak Training Problem and other similar problems

reveals that they involve development of eLearning Systems that exhibit the following

key characteristics.

Mass Scale: A solution has to be developed for a “class of problems” rather than

a single problem.

Variety: The products to be developed are similar but distinct meaning that they

have commonalities and variabilities.

Multimedia components: The eLearning Systems catering to these problems

involve multimedia components and the development of these systems involves

little or no coding.

It is a capital-intensive task to develop these kinds of systems because of the scale and

variety. A promising direction is to develop them as a family of products and automate

their development. In this chapter, based on our experience towards solving the ALP

problem, Prerak Training Problem, and drawing inspiration from traditional

manufacturing, we propose TALES approach as a solution to the Automation problem.

Before presenting the TALES approach, we present the insights from our experience

during this thesis and insights from traditional manufacturing.

6.2 Insights from ALP Factory and Prerak Training Factory

Experience

We summarize our insights during the ALP Factory and Prerak Training Factory

experience as follows:


80

An experience of developing products manually is an important pre-requisite to

facilitate automation.

Understanding & analysis of problem domain is crucial for automation in terms of

having an underling theory for a "class of problems" and designing a solution

from the problem domain.

A standard platform based on the solution from problem domain comprising of

uniform product structure, standard processes, and components lays an

underlying infrastructure for further activities of automation.

We have learnt that building a standard platform requires deeper understanding

of development processes at operational level.

Automating production processes requires processes to be explicit and modeled

at a granular level of detail.

Tools bound by processes and an assembly tool for composing processes are

an important step towards automation.

Reusing repositories of components, tools, and processes speeds up the

automation process.

6.3 Insights from Traditional Manufacturing

Traditional manufacturing has matured in solving problems that exhibit the

characteristics of mass scale and variety. However, tremendous pressure from

customers for highly customized products and services forced the traditional

manufacturing industry to move from mass production to mass customization [68].

“Mass production is the tremendous increase in scale of the same product at low costs

whereas Mass customization is a tremendous increase in variety and customization of

the product without a corresponding increase in costs” [93]. A number of debates of

analogies between software industry and traditional manufacturing industries are

discussed in [20] [31] [32]. Jack Greenfield et.al have clarified this stand by explaining

that software industry is mainly concerned with economies of scope, which involves

development of similar but distinct products whereas traditional industries are interested

in economies of scale, which is production of same product at a mass scale [52]. Table


81

§6.1 shows that both mass production and mass customization are major concerns in

traditional manufacturing whereas it is only mass customization in case of software.

Table 6.1 Comparison of Traditional Manufacturing and Software Industry

Challenges/Industry

Traditional Manufacturing

Industry

Software Industry

Mass Production

×

Mass Customization

Our goal to automate the development of eLearning systems is in synergy with the goal

of mass customization as the problems we consider exhibit the characteristics of mass

scale and variety. Drawing inspiration from the classical works of Frederick Winslow

Taylor, Henry Ford, and “The Toyota Way”, we summarize our insights in relation to this

thesis as follows.

(i) Insights from the principles of scientific management (Taylor) [106]:

Taylor states that “It is only through enforced standardization of methods,

enforced adoption of the best implements and working conditions, and enforced

cooperation, that this faster work can be assured”.

He proposed that by dividing the work into constituent components and analyzing

the work leads to finding the “one best way” of doing work [74].

Frank Gilberth has extended the time study work of Taylor by eliminating waste

motions from work and hence improving productivity [47] [48].

A more detailed work and critical analysis of Taylor’s work is presented in [113]

(ii) Insights from Henry Ford’s Work [103]:

He introduced assembly lines to the world of manufacturing and enabled mass

production of cars by rapid transformation of raw material to finished goods by

employing assembly tools [110].


82

A complete and consistent “interchangeability of parts” was at the core of his

contribution [74].

An important contribution of his system was standardization -- standardized

components, standardized manufacturing processes, and a simple and easy to

manufacture (and repair) standard product [107].

An elaborate discussion of his work is presented in his book “My life and work” [43].

Even though the idea of mass production worked for a long time, the strong need for

customized products in emerging mass markets forced a move from mass production to

mass customization [68].

(iii) Insights from “The Toyota Way” [73]:

The major focus of The Toyota Production System (TPS) introduced after World

War II was to have a flexible production system that produces a variety of

products based on individual customer’s requirements.

The core of TPS is the set of 14 management principles that allow production of

products at high quality, low cost, short lead times, and flexibility.

Improving productivity was achieved by removing non-value added waste from

production lines.

They focused on flexible assembly lines to achieve mass customization tailored

to the needs of customized requirements.

An elaborated discussion of TPS is given in [73]. The progress of manufacturing

practices in automobile industry has evolved from mass production to lean production

[112]. The integration of lean and agile manufacturing paradigms for producing rapidly

configurable production processes in explained in [85]. TPS and the trends towards lean

production are more suited to environments where there is need for development of

customized products tailored to individual customer’s needs and hence these are in

synergy with software industry.


83

The essence of the works presented in this section can be summarized as follows:

Improving productivity and quality of products requires enforcement of

standardization across processes, components, and product structure.

Arriving at “one best way” of performing tasks by doing research, developing

assembly lines and tools is essential to speed up the development process.

Eliminating non-value added waste from processes and developing flexible

assembly lines is important to produce a variety of similar but distinct products.

In the rest of this chapter, we will have a detailed look at the TALES approach, which is

based on insights provided in this section and Section §6.2.

6.4 The TALES Approach

Drawing inspiration from traditional manufacturing and based on our experience of

developing ALP Factory and Prerak Training Factory, we propose TALES as an

•Detailed standard processes and "one best way"

•Processes empowered by tools

•Assembly tools

•Repositories

•Components

•Tools

•Processes

•Standardization provides aninfrastructure to build avariety of similar but distinctsystems.

•Types of standardization

• Product Structure

• Production Process

• Raw Material

•A detailed understanding & analysis of the problem domain

•Designing solution from the problem domain

•A theory for the class of problems

Problem Domain

ExplorationStandardization

Virtual Assembly Lines

Supporting Repositories

Figure 6.1 Core activities of TALES approach


84

approach to automating the development of a family of eLearning systems. Figure §6.1

shows the major activities of TALES approach. These activities are not sequential and

are performed iteratively until the required levels of productivity and quality is achieved.

The major goal of TALES approach is to produce a factory (like ALP Factory, Prerak

Training Factory) that speeds up the development of a family of eLearning Systems.

The next sections of this chapter elaborate the core activities of TALES approach.

6.5 Problem Domain Exploration

Understanding and analyzing a problem domain is a very crucial step in TALES

approach as this step determines the applicability of our approach to a “class of

problems”. Our approach is suitable to problems that exhibits the characteristics

outlined in Section §6.1. Our approach emphasizes the need of designing the solution

from the problem domain. In Section §2.5.2, we have illustrated the design process of

solution in the problem domain in ALP case study. The central idea of this design

process in the problem domain is to ensure that there underlies a theory or a common

methodology for the class of problems such that the operations performed on all of them

work in principle. In ALP case study, the underlying theory is established by NLM and

the CBFL methodology. The research done by NLM includes devising a “uniform

learning model” for teaching adult illiterates and “a uniform learning material” that works

for all Indian languages and their major dialects. This uniform model is further grounded

on theory of cognition and other fundamental principles like laws of perception.

6.6 Standardization

Development of products by assembling parts 16 and maintaining them by

interchanging parts are two fundamental challenges to be addressed in order to

achieve productivity and quality of eLearning Systems anticipated by TALES approach.

The underlying root cause for both of these challenges is the lack of standardization

16

We use the colloquial term “parts” to refer to sub-systems, components, tools and processes in the context of this thesis


85

mechanisms that drive mass-scale production and customization as in other mature

industries like manufacturing. We have presented how a standard platform consisting of

a uniform product structure, production processes, and components has laid a strong

foundation during development of ALP Factory (Chapter §3). In this section, we explain

the need for standardization in TALES approach and introduce various kinds of

standardizations focusing on product structure, production process, and raw material.

Standardization in TALES approach is based on:

A deeper understanding of development processes at the grass root level. This

means that the development process must be made explicit and each of the

process steps has to be standardized at operational level.

Understanding and analysis of the operation of product is at the root of

standardization and forms a basis for various kinds of standardization.

6.6.1 Role and Importance of Standardization

The insights presented in Section §6.2 and Section §6.3 reveal that standardization

provides an underlying infrastructure that facilitates “assembly of parts” during creation

of the product and “interchange of parts” during maintenance of the product.

Assembly of parts: In traditional manufacturing, an assembly process transforms the

raw material into finished goods by assembling parts in a standard manner. During

development, the specific product is derived by assembling a number of parts in a

certain order via an assembly line (process). The parts can be made by human or tools

and can come from in-house or external to the factory.

The communication between various parts is governed by standards, which includes the

services that are exposed and consumed by the parts. Assembly of parts happens only

through standard interfaces between the parts. In the ALP case study, parts are visual

and sound elements and assembling of parts involves integrating visual and sound

elements to create eLearning systems. We have considered the size, aesthetic look of

the elements along with their fit into the learning model during the assembly process.


86

Interchange of parts: In the context of software where mass customization is a major

concern, every product in a factory is unique. During maintenance, products should be

customized as per the changes in existing requirements and new requirements. To

produce the product as per new requirements, the old parts of the product should be

replaced by new parts. Variabilities in TALES approach are implemented using

Interchange of parts. Interchange of parts is only possible when there is standardization

of the parts and there are standard interfaces between the parts. Interoperability

between various parts of the product is also achieved through standardization.

In Section §4.2.2, we have illustrated the dialect generation process that replaces

(interchanges) sound elements of an existing ALP product with sound elements of new

dialect. This is possible because the existing parts (sound elements) and new parts are

standardized. Parts in the context of this thesis focus on visual elements, sound

elements, tools, and processes. However, irrespective of the parts, standardization

ensures that the interface of the parts follows a standard. For every kind of part,

standards are defined and standardization is employed. Thus, standardization plays an

important role and is significant to enable “assembly of parts” and “interchange of parts”.

6.6.2 Types of Standardization

Standardization is an umbrella concept that spans across a number of aspects. We

consider the following types of standardization during the TALES approach.

(i) Product structure standardization

Product structure consists of the organization of systems, sub systems, and

components of the product and their relationships. In traditional manufacturing, product

structure is the structural decomposition of a physical product into parts and is generally

concerned with the organization and maintenance of bill of materials [102]. Product

structure management [102] and advanced modeling techniques are used to manage

product structure in traditional manufacturing. Figure §6.2 shows a product structure


87

decomposition of a typical car assembly. The key components are refined until granular

level of the parts is reached.

However, in case of software, product structure is more than just functional

decomposition of product but is based on a deeper understanding of operational

character of the software product. In our approach, we start creating the product

structure from the problem domain and refine it in further stages. We have detailed the

break down structure of ALP product in the problem domain in Section §2.5.2 and then

created a uniform product structure for all products as presented in Section §3.2. This

structure is created during scoping and specifying the requirements of the ALP Factory

and products. This yields mainly two benefits. First, all the products follow a uniform and

consistent structure and hence understanding, creating and maintaining the product

structure is easy. This is very useful as different teams at different locations develop

products and all of them derive from the same product structure.

Figure 6.2 Product structure of a typical car


88

Assembly is the core operation that defines the relationship between parts/sub-systems

in our approach as shown in Figure §6.3. These parts are assembled by using tools and

assembly processes as explained in Section §4.2. The central idea of product structure

standardization is to expose the services that are required and consumed by each of

the parts in the product structure as shown in Figure §6.4. We have already explained

the notion of product structure standardization in ALP Factory in Section §3.2.

(ii) Production process standardization

The concept of standard, streamlined and optimized production processes form the

basis for efficient assembly lines in traditional manufacturing. The “one best way”

concept introduced by Taylor analyzes the work, and proposes a scientific approach to

performing the tasks. We have explained the notion of standard production processes in

ALP case study in Section §3.3. Process standardization plays an important role in

TALES approach as tools can be employed to enable process automation based on

these standard processes. We have explained how we have automated standard

production processes in ALP case study in Section §4.2. We have learnt the following

important lessons about processes that facilitate automation.

(a) Processes have to be explicit for facilitating automation: The central idea of TALES

approach is to reduce human labor by capturing the tasks performed by developers and

using tools to automate them. If the processes are not explicit, then human intervention

Figure 6.4 Standard parts & services in eLearning Systems

Figure 6.3 Assembly operation


89

is required to perform tasks denting the idea of automation. Hence, processes have to

be made explicit such that even a tool can perform the tasks. This means that the steps

performed by experts should be made explicit and captured in production processes.

This allows even a non-expert to use the captured knowledge and perform the tasks as

if performed by an expert. Furthermore, making the process explicit allows tools to

assist and even replace human labor. In the TALES approach, we have analyzed the

work of developers and captured their experience using processes and tools.

(b) Processes have to be detailed enough to be automated and hence for each of the

sub-systems in the product, a process is modeled and all of these processes are

integrated in a certain order to make up the production process. The experience of

building a number of products in the problem domain is the basis for production process

standardization and this experience is embedded in the processes and tools. If the

processes are not modeled at detail, then human intervention is required to provide the

detail and hence denting the idea of automation. In the TALES approach, we have

modeled the processes at a granular level of detail as illustrated in Section §4.2.

(c) Processes should reflect the operational development processes: The main purpose

of processes in the context of TALES approach is to use them for automation rather

than just for understanding and documentation. This mandates the need to model the

processes from operational point of view meaning that the processes should reflect the

operational processes at grass root level.

(iii) Raw material standardization

Raw material plays an important role in manufacturing. In the context of eLearning

Systems, raw material is in the form of visual components, sound components,

processes, tools and other elements that are used during development. Every process

step in the production process requires some raw material for processing and producing

the product for next step. The usage of tools in the production process is at the core of

manufacturing and for this tools and production processes to work, the raw material

should be available in a standard form. This means that the components or core assets


90

and other elements should have a standard interface. For every kind of component, the

services exposed and the services consumed should be in a standard form. This makes

the development of tools and automation of processes easier. This standardization also

allows other suppliers to provide components as raw material to the factory. In Section

§3.4, we have explained the notion of

raw material standardization in ALP

case study.

We have learnt that the notion of

standardization that we have

implemented in ALP Factory and the

concept of standardization in traditional

manufacturing are in harmony. Hence,

we have emphasized the role of

standardization in TALES approach and

the need to create various kinds of

standardization. Figure §6.5

summarizes and maps the various kinds

of standardization in ALP case study

and TALES approach.

6.7 Virtual Assembly Lines

The concept of assembly lines underlies traditional manufacturing industries to improve

productivity and quality of products and enable mass production. The core idea of

assembly lines was made popular by the famous assembly line of Henry Ford in which

products are generated at a faster rate by adding parts (usually interchangeable parts)

in an optimized order [110]. Mixed model assembly lines are used to handle the

demand for make-to-order products to achieve mass customization [21]. We propose

the concept of Virtual Assembly Lines (VALs) in the TALES approach that facilitates

automation of production processes.

Standardization

Product Structure

Reader

Writing

Arithmetic

eBook

Production Process

Standardization process

Sound extraction

Product structure creation

Dialect generation

Raw Material

Visual Elements

Sound Elements

Figure 6.5 Standardization in ALP case study


91

Bundling the experience of an expert into processes

and tools provides an important direction in the

TALES approach as it facilitates non-technical users

during production of products. Virtual Assembly Lines

assist the goal of reducing human labor and

improving productivity by leveraging on the

standardization platform and by employing tools.

Virtual Assembly Lines are a composition of

processes weaved along with tools. Standardization

acts as a backbone to virtual assembly lines as each

step of production processes takes raw material in a

standard form and delivers the product in a standard

way. Production process standardization is at the

core of VALs as these processes are weaved and automated. We have explained how

we have automated production processes in ALP case study in Section §4.2. Figure

§6.6 provides an outline of the key VALs of ALP case study. Standard production

processes consists of key processes of ALP case study like standardization process

and dialect generation process among others. The virtual assembly lines consist of

product structure creation and dialect generation. These two VALs are detailed in

Section §4.2.

In Section §4.4, we have illustrated the role of assembly tool eScript in facilitating the

development of ALP products by even non-technical users. The TALES approach

supports this concept by using VALs as they make the development processes explicit,

capture the knowledge of development, use standard inputs and outputs at each of the

process steps and finally employ tools at each of the process steps. An assembly tool

acts like a robot and performs the process steps without human intervention as if

performed by a developer.

The central idea of virtual assembly lines is to automate production processes by

employing tools at each of the process steps and facilitate assembly of parts during

development and interchange of parts during customization and maintenance. Virtual

Virutal Assembly Lines

Standard production

proceses

Standardization process

Structure creation

Dialect generation

Developed VALs

Product Structure

Creation VAL

Dialect Generation VAL

Figure 6.6 Virtual Assembly Lines in ALP Case Study


92

assembly lines also facilitate non-technical users to develop products as the knowledge

of an expert is embedded in processes hiding the non-technical user from technology.

6.8 Supporting Repositories

Throughout our experience of developing ALP Factory and Prerak Training Factory, we

have created and used a number of supporting repositories. The TALES approach

emphasizes that repositories are required to support automation process.

Components Repository is the set of components that will be used, adapted,

customized, and assembled during the TALES approach. Visual components and sound

components form major part of eLearning systems. Hence, a components repository in

TALES approach consists of standard visual and sound components.

Tools Repository provides a set of tools that automate production processes in the

TALES approach. The main goal of tools is to improve productivity and quality. With

continuous involvement from experts who perform the tasks, their experience is

embedded in the tools and this facilitates non-technical users to perform the tasks with

near efficiency as if experts perform them. Tools repository is a core part of virtual

assembly lines and support automation.

Process Repository is a set of standard processes that comprises of rote, menial, and

repetitive tasks during the development of a product. This repository forms the

underlying infrastructure upon which tools and virtual assembly lines are built. We have

learnt that the processes have to be explicit, detailed enough and should reflect

operational processes if they have to be automated. We have developed a process

repository for ALP case study consisting of standard processes with planned variations.

93

Chapter 7

Related Work

In this chapter, we present and explain the key ideas related to our thesis. In Section

§7.1, we revise the research context. Section §7.2 describes the work related to ALP

Factory and Section §7.3 elaborates the work related to TALES approach. The

important works of software product lines and software industrialization are explained in

Section §7.3.3 and Section §7.3.4. A brief discussion of our work in relation to the

presented works is described in Section §7.3.5.

7.1 Revising Research Context

In this thesis, we have presented ALP Factory as a solution to the ALP problem, Prerak

Training Factory as a preliminary solution to the Prerak Training Problem and the

TALES approach for the Automation problem. All of these efforts have involved

automating the development of a family of eLearning Systems. However, as mentioned

earlier, the term eLearning17 has different meanings in different contexts with varied

definitions [41]. The world of eLearning is constantly changing and evolving at a rapid

pace. The last decade has seen numerous advances in eLearning Systems from being

an alternative to class room based learning to using Web 2.0 and enhancing to

eLearning 2.0 [99]. The essence of these approaches is the integration of technology in

learning to enhance the teaching and learning process, rather than just being seen as a

17

A number of terms like e-learning, online learning, computer-based training (CBT), Web-based learning, distributed learning are used in the literature to broadly mean using computers for enhancing the learning and teaching process. An analysis of the terminology is given in [6].

CHAPTER 7. RELATED WORK

94

new flexible delivery medium [86]. The basic presumption of most of these approaches

towards eLearning is that the learners are literate and have basic computer literacy.

Development of software products for international markets has long been gaining

importance and different methods have been proposed such as [97] [57] [96] [23] [105].

Internationalization and localization are concerned with the adaptation of software

products based on cultural aspects and with minimum engineering efforts [55]. Unlike

multilingual systems that focus on generating the same software product for multiple

languages, the ALP problem that we have presented in this thesis focuses on the

development of similar but distinct products for multiple languages.

The eLearning Systems in the context of this thesis are unique for two main reasons:

(i) they are not web-based and not for an advanced learner who has basic computer

literacy. (ii) their development involves multimedia components with little or no coding.

With this context, we present the various ideas related to our work and provide a critical

discussion throughout the rest of this chapter.

7.2 ALP Factory and Related Work

In this section, we will explain ALP problem in relation to the classical problem of

making compilers for M machines and N languages and compare their solutions.

7.2.1 ALP Problem and the classical M X N compiler problem

Consider the classical problem of making M X N compilers for M programming

languages and N machines [62]. Making each compiler is a manually intensive task and

there is no end to the possibility of new languages and machines being invented. As a

result, the number of compilers needed grows non-linearly. On the similar lines,

consider the problem of developing ALP products for L languages and D dialects. This

requires development of L X D ALP products. However, to teach any Indian language

dialect using any other Indian language dialect as medium of instruction requires

development of (L X D) X (L X D) ALP products. It can be observed that both the


95

problems thrive for providing a solution to a mass scale of problems and of variety.

However, the similarity ends here, as the M X N problem requires translation of a

source language into target machine whereas in case of ALP problem, it is the

development of ALP products for different class of problems rather than just translation

from one language to another.

7.2.2 ALP Factory and Compiler Compilers

Automating the production of compilers i.e., compiler-compilers has been an

intellectually challenging task and has attracted research from early times [19]. To

achieve the goal of reducing effort in producing compilers for a number of languages

and machines, a universal intermediate language called UNCOL was proposed [30].

The core idea of this approach is to convert the problem-oriented language into UNCOL

and the converted UNCOL into to the target machine [62]. For M languages and N

machines, the approach of UNCOL reduces the effort of producing M X N compilers to

M + N compilers [101]. However, the lack of maturity in compiler technology eventually

caused the failure of UNCOL [75]. The Production Quality Compiler Compiler (PQCC)

experiment [71] attempted the automated construction of high quality, highly optimizing

compilers with inspiration from BLISS-11 compiler [114]. It has introduced the division

of compiler writing process into a number of phases and employed tools at each of the

phases that produce the corresponding artifacts (e.g. lexical analyzer, parser and code

generator) [71]. An important lesson from the PQCC experiment is to understand that

compiler compilers require not only a generic structure of compilers but also a precise

definition of the inputs and outputs of each of the phases of compiler construction

process to achieve automation [88]. However, the integration of the outputs generated

by various tools in compiler compilers has to be done by compiler developers still

requiring a lot of intensive work in compiler construction. Furthermore, the experiment

showed that “Tools do not make a process!” They only make it easier to perform the

tasks in a process because the compiler developers would still need to know how to

precisely write specifications, their order and how to integrate the outputs of tools.


96

The ALP Factory solution that we have presented to the ALP problem is an integration

of processes, tools, and components to automate the development of ALP products.

Both the efforts of ALP Factory and compiler compilers attempt automating the

development of products, rely on a generic structure of the product, emphasize that

precise specification of inputs and outputs supported by tools allows for quick and

economic development of products. However, unlike the PQCC experiment, the

development processes are made explicit in ALP Factory. Processes are also modeled

at a granular level of detail and are integrated with tools by using an assembly tool.

Furthermore, the burden of writing precise specifications, integrating outputs of tools is

relieved from developers by using an innovative assembly tool. The Prerak Training

Factory solution is on the similar lines of ALP Factory.

7.3 TALES Approach and Related Work

In this section, we will present the work related to the Automation problem and TALES

approach.

7.3.1 Automation Problem in a broader context

Improving software productivity is an age-old problem. This problem was intensified by

an ever-increasing reliance on software in everyday life and the mounting pressure for

quick and economic production of software from customers. Productivity is defined as a

ratio of output units produced per unit of input effort [59]. According to Barry W. Boehm,

there are three strategies to improve software productivity: working faster, working

smarter, and avoiding unnecessary work with the latter promising highest payoff [18].

Another research direction to improve productivity is given in [54] which focuses on the

dimensions of people, process and technology. An interesting paradigm to improve

productivity that is close to this thesis focuses on development of a family of problems

rather than a single problem [92]. Another direction that is close to this thesis is the idea

of software industrialization where software products are assembled from standard

reusable components rather than built from scratch [31]. We focus on these two

directions and compare our TALES approach with them.


97

7.3.2 Traditional approaches to improving productivity

Software reuse is a conventional approach to improving productivity by building

software systems from existing software assets rather than building them by scratch

[70]. A detailed survey and analysis of software reuse is provided in [70] [83] [44]. A

systems approach to software reuse that addresses a broad range of technical,

economic, managerial, organizational, and legal issues is presented in [66]. However,

despite several decades of intensive research, software reuse is still not an established

standard practice in software engineering [70]. Design patterns of object-oriented

software are another important direction in software reuse [46]. Components are

proposed as a solution that offer higher levels of reuse than objects [104]. Developing

systems by assembling components and maintaining them by customizing and

replacing the components resulted in directions of component-based development [33].

The essence of all these approaches is that productivity can be improved by following a

systematic approach to reuse focusing on various assets and developing a

methodology to build software by using these assets. The TALES approach is

systematic in developing various kinds of reusable assets (repositories) and facilitates

assembly and interchange of components but focuses on a family of systems unlike

these approaches, which focus on a single system. In this approach, we advocate that

one of the most important factors that can affect the success of software reuse is the

design and realization of the components likely to be reused, and particularly their

adequate standardization. We elaborated the standardization of components in Section

§3.4. However, standardization of components alone is not enough, standardization of

development processes and product structure are also very important to our approach.

7.3.3 Software Product Lines

Fostering reuse across a family of problems or a market segment is an emerging trend

in software reuse and is known as software product lines (SPLs) in literature. The goal

of SPLs and TALES approach is to build a family of products based on a common

platform. In addition, TALES approach also focuses on automating the development by


98

employing an innovative assembly tool. In our literature survey, we found very few

works that focus on building software product lines for eLearning Systems like [115] and

digital information products [91]. An approach to development of web-based eLearning

Systems focusing on web services and XML was presented in [115]. However,

development of these systems requires the presence of project managers and human

intervention for development of eLearning Systems. Conversely, the eLearning Systems

targeted by TALES approach differ as they involve little or no coding. The TALES

approach with the help of Virtual Assembly Lines allows for development of eLearning

Systems without much human intervention. However, TALES approach and Software

Product Lines share a number of concepts. In this section, we will briefly present some

of the concepts and discuss them in relation to the TALES approach.

(i) Overview

John Mcrolly introduced the notion of mass production in the context of software in the

famous NATO 1968 conference, where he proposed a library of reusable components

and automated techniques for customizing components to different degrees of precision

and robustness to achieve mass production [80]. The idea of solving a family of related

programs was introduced in [37] and then elaborated by David Parnas in [92]. He

argues that solving a family of problems collectively based on commonalities and then

focusing on the special properties of individual family members yields improved

productivity and quality [92]. Software product lines are a systematic reuse approach to

produce a family of similar but distinct products by capitalizing on the commonality that

software products share in a particular domain [27].

In the TALES approach, we have presented reusable component repositories (Section

§6.8) and our approach focuses on mass customization of components rather than

mass production as proposed by John Mcrolly.

(ii) Definitions & Core Ideas in Software Product Lines

Software product lines (SPLs) [27] and Software product families [94] [40] are two major

terminologies that are used in the literature to represent the idea of producing a family


99

of systems rather than individual systems. The resulting set of software products

emerging out of a software product lines effort is often termed as a software product

family [7]. Software Engineering Institute (SEI) has been conducting research on

software product lines for decades and has published several technical reports and

case studies [72].

a. “A software product line (SPL) is a set of software-intensive systems sharing a

common, managed set of features that satisfy the specific needs of a particular

market segment or mission, and that are developed from a common set of core

assets in a prescribed way”. [27].

The important aspects of this definition include shifting the focus from single

software development to SPL development based on distinguished features [14],

focusing on a targeted domain [89] by sharing common assets and following a

prescribed process [25] for development of family members. The SPLs produced by

TALES approach can be categorized under this definition.

b. “Software product line engineering (SPLE) is a paradigm to develop software

applications (software-intensive systems and software products) using platforms and

mass customization18” [94].

The TALES approach can be defined as a paradigm to automate a family of

eLearning Systems using a standard platform and enabling mass customization. The

major difference between our approach and SPLE is that we focus on not just

development but automating the development process meaning that the

development processes are captured and automated using an assembly tool and

hence facilitating non-technical users to develop products.

c. Domain Engineering is defined as “the activity of collecting, organizing and storing

past experience in building systems or parts of systems in a particular domain in the

form of reusable assets (e.g., architecture, models, code, and so on), as well as

providing an adequate means for reusing these assets [...] when building new

systems” [36]. It is concerned with defining and realizing the commonality and

18

Tseng and Jiao define mass customization as "producing goods and services to meet individual customer’s needs with near mass production efficiency" [100].


100

variability of a software product line, thus establishing a common software platform

for developing high-quality applications rapidly within the line.

TALES also emphasizes problem domain exploration as explained in Section §6.5.

However, one unique aspect of our approach is that the design of solution starts

from the problem domain and the class of problems rely on an underlying theory.

d. Application Engineering is “the process of building a particular system in the

domain” [36]. It is concerned with deriving specific applications by strategically

reusing the platform and by exploiting the variability built into the platform. VALs

capture the application engineering process in case of TALES approach and hence

minimize the involvement from developer. However, the user has to configure

products and give specific inputs for every product.

Both domain engineering and application engineering have a life cycle involving

requirements, design, realization, testing and are integrated with management

activities at technical and organizational level [27]. TALES approach does not

formally have life cycles for either domain engineering or application engineering

rather it focuses on automating the production processes.

e. Variability is a central aspect of software product lines that is concerned with the

ability of a software product line to change or customize a software system by

exploiting a common platform [60].

The notion of variability is captured in TALES approach during product structure

standardization and is further refined in production processes and tools. However,

we have not applied the extensive literature of variability in TALES approach. Our

approach focuses on foreseen variabilities by clearly articulating variations through a

standard platform and implementing it through “interchange of parts”.

(iii) Approaches

The software product lines community has seen a number of approaches in the last

several decades pertaining to different viewpoints. We outline the major approaches in

this section and relate them to our approach.


101

a. Organizational Viewpoint

McGregor et al. present two approaches to initiate software product lines from an

organization viewpoint: heavyweight or lightweight [79]. The heavyweight approach is

capital intensive as the organizations spend significant effort to perform domain

engineering and develop core assets before churning out the products of software

product line. On the other hand, in a lightweight approach, first product of software

product line is developed and mining efforts are used to extract commonalities. Success

has been reported by organizations using both the approaches [79] but some works

report that lightweight approach can reduce the barrier to large-scale reuse, as it is a

low-risk strategy with lower upfront cost [69].

The TALES approach can be undertaken either as a heavyweight approach or as a

lightweight approach. In case of ALP, we took a lightweight approach by mining the

existing assets. However, the choice of the approach should be decided by a number of

factors like organization, domain, and technology among other factors.

b. Adoption Models for creating and maintaining a software product line practice

Adopting a software product line practice in an organization requires a systematic

approach as they are capital-intensive and require an upfront investment. Krueger

defines three prominent adoption models [69] that help organizations establish and

operate a software product line practice. A proactive approach is similar to

conventional waterfall approach, suitable for organizations with huge resources. This

approach should be adopted when product variations on the foreseeable horizon can be

analyzed, designed, and implemented upfront. A reactive approach is more like spiral

or extreme programming approach to software development in which one or several

product variations are developed on each spiral. This approach is best suited when

product line requirements are not predictable, or there are not enough resources or time

during transition. On the other hand, an extractive approach reuses one or more

existing products for the product line initial baseline. This approach is effective for an

organization that wants a quick transition from single product development to a product


102

line approach. Kruger also suggests that a lightweight approach integrated with the

various adoption models results in dramatic reduction in the adoption barrier [69].

The TALES approach can be undertaken in proactive, reactive, or extractive approach

based on the specific class of problems. In case of ALP, we have followed the extractive

approach by starting from existing products and coming up with ALP Factory. To

summarize, we have followed a lightweight approach combined with an extractive

approach in case of ALP as suggested by Kruger but however, TALES is flexible to

adapt a combination of these approaches based on case by case.

c. Software Product Lines Methodologies

In over two decades of research in software product lines, a number of approaches and

a number of classifications have been proposed. We brief a few important directions

here. Process centric approaches like Feature Oriented Domain Analysis (FODA) [63],

Feature Oriented Product Line Software Engineering (FOPLE) [65] focus on the

organization of product lines and family members, and how the product lines strategy

affects an organization. The PuLSE™ (Product Line Software Engineering) is a method

that exploits reusable assets across a broad variety of products [15]. SEI’s Framework

for SPLs [28] supports organizations by providing the essential activities and practice

areas needed to succeed with software product lines. A comprehensive comparison of

various approaches like FORM [64], KobrA [8] to product line architectures including

feature modeling and domain-analysis techniques is provided in [77]. More recently, a

model driven and aspect-oriented approach to product lines is presented in [108].

Generative software development [35] focuses on feature driven development, domain-

specific languages for specifying and deriving product-line members.

TALES approach is process centric and is reliant on domain engineering to support the

automation of a family of similar but distinct eLearning Systems however it also relies a

lot on product structure as emphasized by product structure standardization. Tools are

at the core of virtual assembly lines that enable automation. However, the activities that

are performed during the TALES approach have to be refined to get to the state of

software product line practice.


103

(iv) Challenges

Software product lines have evolved into a research area after emanating from a plenty

of industrial experience. A number of successful case studies are documented based on

the experience of software product lines [111].

Software product lines promise quicker and faster development of software products

resulting in higher levels of productivity and quality gains [27] however strategies for

adoption of software product lines involve huge upfront investments, risks and impacts

on the organization and on the management along with time and money. Unpredictable

markets, domain understanding, and analysis play an important in the success of

software product lines. Despite a number of efforts in feature modeling, variability

modeling, domain analysis, product line architectures in the past two decades, software

product lines are still challenging and facing difficulties [98] [38].

Summary of this section:

The essence of this section is that TALES and Software product lines share the

common goal of developing a family of systems with TALES also aiming at automating

the development. They share a number of common ideas such as commonalities and

variabilites, standard process and tools. However, the kinds of systems that TALES

targets makes it distinct and the assembly tool that automates the development

process, is unique to it. Our approach also emphasizes the need for development

processes to be made explicit and modeled at a granular level of detail. On the other

hand, a number of practices in software product lines have matured life cycles and

activities whereas the TALES approach is yet to mature to that level. To summarize,

TALES is a complementary approach to software product lines, which enhances a

number of concepts to exploit the advantage of domain and employs innovative tools.

7.3.4 Towards Software Industrialization

Industrialization of software industry was anticipated long back in the famous 1968

NATO conference where the statement “software industry is not industrialized” was


104

inscribed [80]. Despite numerous advances in the long history of attempting

industrialization in the software industry, this statement remains valid in most aspects

even today. A brief survey of literature regarding software industrialization and software

factories reveals that the idea has evolved as a discontinuous pattern. The idea started

long back in the 1960s and even today, it is still an unfulfilled promise. During this

journey, it can be observed that the research on this topic is discontinuous meaning that

it is active for a decade, became inactive in the next and then active again. We have

analyzed that this pattern is mainly because of the immaturity of technology, software

development methodologies, and lack of infrastructure supporting software in the early

times. In this section, we briefly provide a few directions towards achieving software

industrialization and relate them with the TALES approach.

The software industry has been thriving for improving productivity and quality of

software systems since the term “software crisis” was coined during the NATO

conference in 1968. Many solutions have been proposed to solve this problem like

object oriented analysis, CASE tools and others however, it turned out that there is no

“silver bullet” to this problem [20]. Systematic software reuse was proposed as one of

the solutions to this problem that produces software at low cost and higher quality [16]

[17] [12]. Software factories was also proposed as one of the solutions to software crisis

however the term “software factory” means differently to different people in different

contexts. A brief survey encompassing the initial approaches to software factories was

given in [1] which describes the efforts of a Japanese approach to the industrialized

software organization [78], the experience-based component factory [13], which exploits

the experience of developing products. A historical interpretation of software factories is

provided in [34] which explains the software process evolution in five phases: basic

organization of structure (jobshop), technology tailoring and standardization, process

mechanization and support, process extension and support, and flexible automation.

The factory paradigm in the context of more dynamic markets based on principles

espoused by Deming [39] was suggested in [58]. Cantone describes the key aspects of

software factory engineering as “standardization of processes and products,

modularization of staff and “materials”, integration of tools and processes, flexibility of

tools and processes, management, i.e. planning and control, of the production and, last


105

but not least, reuse of experiences, all kinds of product and production related

experiences” [22]. Development of software by designing parts for specified tolerances

based on standards, processes and tools enables design of software in a way LEGO

blocks are used to build systems blocks [53]. Domain-specific kits have been proposed

based on this concept, which are used by software developers to develop certain parts

of a system at a lower cost and better quality [53].

However, despite of so many efforts, the vision of software factories to automate the

development of software products remained an unfulfilled promise as documented by

the number of failures in software engineering projects [49]. Some authors have

attributed these failures to the non-applicability of the factory concept to software but

Peter Wegner sums up the similarities and contradictions this way:

“Software products are in some respects like tangible products of conventional

engineering disciplines such as bridges, buildings, and computers. However, there are

also certain important differences that give software development a unique flavor.

Because software is logical not physical, its costs are concentrated in development

rather than production…”.

In Section §6.3, we have explained that software industry is more concerned with mass

customization than mass production. This notion was supported by Jack Greenfield et

al. by further clarifying that software industry is interested in economies of scope rather

than economies of scale [52]. He has also identified a number of reasons for the

unfulfilled promise of software factories like monolithic construction, one-off

development, and revived the idea of software factories by integrating a number of

critical innovations like software product lines, model driven development [52].

The literature has seen a shift in focus from software factories to software product lines

during the last several decades however the goal being economical production of

software systems at high quality, and time-to-market. Even though a little has been

referred to the concepts of software factories in the software product lines community, a

number of concepts can me mapped between the two. For example, domain specific

languages are called as domain specific kits; systematic software reuse is at the core of


106

both the approaches. A connection between a number of concepts between software

factories and software product lines was exemplified in [51].

Summary of this section:

The initial efforts towards software factories are inspired from traditional manufacturing

but are not fruitful mainly because of lack of maturity of technology and methodologies.

A new direction has started with the same purpose in the form of software product lines

that uses improved technologies and methodologies but these efforts have not

emphasized on the foundations laid down by the earlier initiatives in software factories.

The TALES approach presented in this thesis bridges the gap by learning from the

earlier experiences of software factories i.e., insights from traditional manufacturing and

capitalizing on the advancements in software product lines. The notion of problem

domain exploration plays a crucial role in both SPLs and software factories. However,

the idea of designing the solution from the problem domain is well emphasized in

TALES approach. Standardization of processes, product structure, and components has

its roots in traditional manufacturing and later from SPLs. Most of the approaches to

SPLs have been process centric but the TALES approach emphasizes the importance

of both product and process as exemplified by product structure standardization and

production process standardization. The notion of virtual assembly lines was inspired

from assembly lines of traditional manufacturing. Process mechanization and

optimization by modularizing the product structure and automating the processes by

employing tools was proposed in [34] and virtual assembly lines of TALES approach

implements them by automating production processes. The presence of an assembly

tool that captures the production process and automates them without human

intervention enabled TALES approach to move closer to software factories.

7.3.5 Discussion

The major goal of compiler compilers (Section §7.2.2), software product lines (Section

§7.3.3), and software industrialization (Section §7.3.4) and TALES approach is to

improve software productivity across a family of products. Our TALES approach


107

complements the earlier efforts by learning from them and providing new insights in

automating a family of eLearning Systems. Compiler construction attempted a solution

towards making a family of compilers. This effort has involved understanding the

domain, coming up with a common architecture for the family of compilers and using a

set of tools to reduce the development effort. However, the development process is still

complex and not explicit. The order of generated parts from tools is not clear and the

integration of these tools is done manually. The effort of compiler construction is still

complex as the focus was more on tools than on the process. With a number of

advancements and matured technologies, software product lines have emerged as a

paradigm to develop a family of solutions to a class of problems. These efforts have

focused on domain engineering, application engineering, variabilities, core assets, and

product line architectures to automate the development of a family of products that

involve coding. However, as repeated a number of times during this thesis, TALES

approach focuses on a family of products that involve little or no coding. In addition to

these, TALES approach emphasizes the significance of making development processes

explicit, modeling them at a lower level of detail pointing the need for a formal process

notation for modeling development processes. It also points to the strong need for

process analysis tools that verify the integrity of composed processes. The ideas of

standardization and virtual assembly lines in TALES approach have its roots in

traditional manufacturing and early efforts of software industrialization.

To summarize, TALES approach is inspired from traditional manufacturing and

complements software product lines. It is unique as it focuses on systems that involve

little or no coding and facilitates development of software products by even non-

technical users and even without human intervention. However, the maturity of the

approach and its applicability to commercial software systems is yet to be seen.

In the next chapter, we present the challenges that are left unanswered by TALES

approach.

108

Chapter 8

Conclusions & Future Work

In this chapter, we present the overall conclusions of this thesis. We summarize the

conclusions of this thesis in Section §8.1. Section §8.2 summarizes the core

contributions of this thesis followed by some of the challenges in Section §8.3. A few

possible future directions of our work are presented in Section §8.4.

8.1 Conclusions

This thesis has presented the results of an experiment in automating the development

of a family of eLearning systems undertaken at TCS, an Indian Software House. As part

of this experiment, we have presented ALP Factory as a practical solution to the ALP

problem and showed how this has drastically improved productivity during the

development of a family of ALP products. We have presented the Prerak Training

Factory as a preliminary solution to the Prerak Training Problem. We have also

presented the TALES approach to automate the development of a family of eLearning

systems that is borne out of our experience during this thesis and inspired from

traditional manufacturing. This approach progresses by first gaining a deeper

understanding of the problem domain, designing a solution based on this understanding

to handle the scale and variety of software products, creating various kinds of

standardizations to build a standard platform, automating production processes by

CHAPTER 8. CONCLUSIONS & FUTURE WORK

109

developing virtual assembly lines and building repositories of components, tools and

processes to support the entire process.

8.2 Contributions

In our efforts towards solving the ALP problem, Prerak Training Problem and the

Automation problem, we made a number of contributions. We summarize the major

contributions of this thesis in Table §8.1.

Table 8.1 Summary of contributions

Chapter Summary of contributions

ALP Case Study

& Problem Domain

Exploration

(Chapter 2)

1. We presented a detailed understanding and analysis of the ALP

problem.

2. We showed that the ALP problem exhibits the characteristics of

mass-scale and variety and then motivated the need for an

automated approach.

3. We presented the underlying uniform model in the ALP problem and

illustrated its importance during automating the development of a

family of ALP products.

4. We presented the design of solution within the problem domain in

ALP case study.

Building a Standard

Platform

(Chapter 3)

5. We created a uniform product structure for the family of ALP

products.

6. We presented standardized production processes and standardized

components that aid in automating the development of a family of

ALP products.

Automating

Production

Processes (Chapter

4)

7. We presented two of the most important production processes of ALP

case study and illustrated how we automated these processes.

a. ALP Product Structure Creation, that creates the product

structure of ALP products.

b. ALP Dialect Generation, that creates a variant of an existing

ALP product from standardized sound elements of new

dialect.


110

8. We detailed production processes by adding detail and then weaved

them with tools.

9. We illustrated the use of an innovative assembly tool in automating

the development process of the ALP family of products.

10. We demonstrated use of the eScript tool that enabled development of

software even by non-technical users with basic computer literacy.

Practice and Results

(Chapter 5)

11. We presented ALP Factory, which is the result of our experiment in

developing a solution to the ALP problem.

12. We presented the repositories of components, tools, and processes

that are developed as part of ALP Factory.

13. We showed that drastic improvements in productivity (89% for an

ALP Base Product and 75% for an ALP Product-in-Dialect) can be

achieved by using ALP factory for development of ALP products.

14. We have given a detailed quantitative analysis of the effort

distribution during development of ALP Products without and with

ALP Factory.

15. We introduced the Prerak Training Problem that is similar to ALP

Problem and presented Prerak Training Factory as a preliminary

solution to this problem.

The TALES

Approach

(Chapter 6)

16. We presented the insights from our experience of ALP Factory and

Prerak Training Factory.

17. We presented our insights from manufacturing to solve problems that

exhibit the characteristics of mass scale and variety. We learnt that

automation requires:

An analysis of problem domain and a scientific approach to

division of work to arrive at “one best way” of doing jobs.

A standard platform and various kinds of standardization

across processes, components, and product structure.

Flexible assembly lines and tools that facilitate rapid

production of a variety of similar but distinct products by

automating processes.

18. We presented the TALES approach towards automating the

development of a family of eLearning systems.


111

We emphasized the importance of problem domain

exploration and presented the need for designing the solution

from the problem domain.

We demonstrated the role of standardization in our approach

and presented various kinds of standardization focusing on

product structure, production process, and raw material.

We presented the concept of Virtual Assembly Lines that

automates production processes by employing tools.

We explained the importance of various repositories in

supporting the TALES approach.

8.3 Challenges

The work presented in this thesis so far has revealed insights of our experience in

developing a solution to handle the challenge of mass scale and variety in the family of

ALP products and the lessons that evolved into an approach to automating a family of

eLearning Systems. Although our work exposed some challenges, a close assessment

is necessary to reveal some limitations of this work.

(i) ALP Factory & Prerak Training Factory:

ALP case study is a 9-year-old project with a lot of existing work and is well studied.

This eased the work in this thesis and it is has to be seen as to how our approach

works in case of a new initiative.

It was easy to understand the scale and variety in case of ALP because of the

nature of problem domain but it is a major challenge to understand and analyze the

scale and variety in other family of products.

We did not present any techniques for developing uniform model and methodology

in the problem domain.

Standardization requires lot of research effort from the problem domain and in ALP

case study that research was done by NLM, SRCs and TCS easing our work. If we

take another family of products, then the research in problem domain and domain


112

analysis has to be undertaken along with our approach and we did not develop

techniques to do this activity.

The standardizations provided in ALP Factory will work for planned parts and

planned tolerance of changes. For example, for sound parts to be replaced in ALP

case study, the duration of the existing sound element should be ±10 seconds and if

the new sound element is not in this range, then it disturbs the sequence.

The development processes modeled as finite state machines become

unmanageable as the number of states, events, and actions become more and as

the number of FSMs become more.

Automating production processes presented in ALP works when the processes are

detailed enough and the tasks that are detailed can be performed without human

intervention. However, if some of the tasks require human intervention, then

complete automation is not possible (e.g., recording of sound elements for new

dialect) requiring customization of generating product.

Despite of numerous efforts, the ALP Factory is still not mature for commercial use.

The processes, tools, and components developed as part of this effort have to be

refined.

Prerak Training Factory is still a preliminary solution provided to the Prerak Training

Problem and hence requires further refinement in all activities of standard platform

automating production processes.

(ii) TALES Approach

The TALES approach we have presented requires upfront investment and currently

there are no economic models to justify the cost of the investment.

Standardization varies from context to context and hence it is difficult to assure that

only the presented types of standardizations are possible.

We proposed various types of standardizations but there currently there is no

support for synchronizing the various standardizations requiring manual effort.

Enforcing the teams to follow these standards is again a manual effort. Currently,

there is no validation mechanism to verify if the standardizations are followed.


113

The notion of expressing variability through current standardization notations is

limited.

It is difficult to capture the operational processes using current process modeling

techniques because of the level of detail in processes.

Parts are assembled to create product structure but the there are no tools that check

product integrity during product structure creation.

An assembly tool integrates processes in the TALES approach but there is no tool

support to ensure the integrity of composed processes.

8.4 Future Research Directions

Despite the progress we have made in this research, there is much space left for future

work. There are several ways to improve or extend our current research. Firstly, there

are previously mentioned limitations to our approach.

§1 IMPROVING ALP FACTORY & PRERAK TRAINING FACTORY

We plan to refine the standard processes and tools developed during ALP Factory and

make them available for commercial use. A natural extension to our work is employing

more tools to replace manual work to speed up automation. Recording sound elements

in a corresponding dialect is an example of a manual effort in ALP case study.

Availability of Text-to-Speech translator tools with required efficiency can help automate

this task and hence improving productivity. Prerak Training Factory has to be refined in

almost every aspect from improving the standard platform to developing tools in

automating production processes.

§2 TALES APPROACH

Even though TALES approach offered a number of insights in automating a family of

eLearning Systems, it also points to a number of challenges and future directions.

§ 2.1 DOMAIN TOOLS


114

We have developed ALP Factory, Prerak Training Factory during this thesis and

presented the need for development of other factories for literacy, computer literacy and

so on. These systems belong to the domain of eLearning and share a number of assets.

Domain tools help in reducing the effort towards development of factories for different

class of problems in the eLearning domain. There is also a strong need for analysis

tools that help in designing the solution within the problem domain.

§ 2.2 STANDARDIZATION NOTATIONS

We have already explained that standardization is not just functional decomposition of

product rather it involves description of compositional interfaces between various

components. The product structure in TALES approach is currently modeled using

structure diagrams, however ensuring the interfaces between components and

composition of components requires a more precise notation to describe

standardization. The TALES approach points towards development of notations for

various kinds of standardization.

§ 2.3 PROCESS NOTATION

The operational processes during production have to be captured in an unambiguous

and precise manner to facilitate automation. This demands for a process notation that

captures the processes along with meta-information like inputs and outputs at every

process step in a production process.

§ 2.4 PROCESS & PRODUCT INTEGRITY

Process Integrity: An assembly tool is used to integrate production processes during the

TALES approach. However, there is a strong need for tools that ensure the integrity of

processes.

Product Integrity: Virtual Assembly Lines in TALES approach create product structure at

each of the process steps by assembling parts. However, this does not ensure the

integrity of the product created pointing towards the need for tools that ensure product

integrity.


115

§ 2.5 TOOL SUPPORT

We have developed tools to support our ideas of standardization, virtual assembly lines

and used a number of tools like eScript, JSFL and others to automate production.

However, most of these tools are still at an immature state and further work is required

to improve them. We plan to provide tool support for synchronizing the various types of

standardizations and develop tools that assist in various activities of TALES approach.

§ 2.6 INTEGRATION WITH EXISTING APPROACHES

Integrating our approach into existing software product line approaches and other

efforts is another important direction of future work. We see that a number of concepts

we have introduced in this thesis can be adapted to a number of scenarios in the

existing literature. For example, we have modeled variabilities intrinsically in processes

at a granular level and this concept can be integrated with existing variability

mechanisms, which focus on product variabilities. Enabling standardization in feature

modeling is another example. On the hand, there is lot of scope for applying existing

techniques to TALES approach. Adapting variability modeling techniques to TALES

approach is an example. Extending the domain specific languages to focus on building

a theory in the problem domain is another example.

§ 2.7 SCOPE OF TALES APPROACH

We plan to extend the scope of our work by applying the TALES approach to other case

studies in the domain of eLearning and other relevant domains. More specifically, we

plan to apply our approach to developing eLearning Systems for school children. We

also plan to study how our approach works for commercial software applications where

there are code components rather than multimedia components.

Lastly, we hope that the ideas that we have presented in this thesis inspire our peer

researchers in the area of software engineering to contribute to problems that are of

technically challenging in nature and are of societal importance.

116

Bibliography

[1] Mathiassem L. Aaen, "The Software Factory: Contributions and Illusions," in Proceedings of the

Twentieth Information Systems Research Seminar in Scandinavia, 1997.

[2] A. Aamodt and E. Plaza, "Case-based reasoning," Proc. MLnet Summer School on Machine Learning

and Knowledge Acquisition, pp. 1-58, 1994.

[3] H. Abadzi, "Adult literacy: A review of implementation experience," Operations Evaluation

Department. Washington, DC: World Bank , 2003.

[4] K. Anand, "Integration of systems: Bridging systems by automation," in 20th National Conference

on Computer Education, Jameshedpur, India, Feb 2006.

[5] MV Ananthakrishnan, "ICT AND THE “LESS PRIVILEGED”: SOME INNOVATIVE EXPERIMENTS," in

International Conference on ICT in Education and Development, Bhopal, 2004.

[6] A. Anohina, "Analysis of the terminology used in the field of virtual learning," JOURNAL OF

EDUCATIONAL TECHNOLOGYAND SOCIETY, vol. 8, p. 91, 2005.

[7] M. Ardis, N. Daley, D. Hoffman, H. Siy, and D. Weiss, "Software product lines: a case study,"

Software-Practice and Experience, vol. 30, pp. 825-47, 2000.

[8] C. Atkinson, J. Bayer, and D. Muthig, "Component-based product line development: The KobrA

approach," in Proceedings of the First Software Product Line Conference, 2000, pp. 289-309.

[9] Azmath Ali, "Basic ALP - A Comprehensive Overview of ALP Products," TCS, Internal Report 2009.

[10] Azmath Ali, "CBFL Developments - An Overview," TCS, Internal Report 2009.

[11] S. Banerjee, "Revisiting the National Literacy Mission," Economic and Political Weekly, pp. 1274-

1278, 1993.

[12] Bruce H. Barnes and Terry B. Bollinger, "Making Reuse Cost-Effective," IEEE Softw., vol. 8, pp. 13-

24, 1991.

BIBLIOGRAPHY

117

[13] V., Caldiera, G., and Rombach, D. Basili, "Experience Factory, Encyclopedia of Software

Engineering," 1994.

[14] D. Batory, J.N. Sarvela, and A. Rauschmayer, "Scaling step-wise refinement," in IEEE Computer

Society Washington, DC, USA, 2003, pp. 187-197.

[15] J. Bayer et al., "PuLSE: A methodology to develop software product lines," in ACM New York, NY,

USA, 1999, pp. 122-131.

[16] Ted J. Biggerstaff and Alan J. Perlis, Software reusability: vol. 1, concepts and models, Ted J.

Biggerstaff and Alan J. Perlis, Eds.: ACM, 1989.

[17] Ted J. Biggerstaff and Alan J. Perlis, Software reusability: vol. 2, applications and experience, Ted J.

Biggerstaff and Alan J. Perlis, Eds.: ACM, 1989.

[18] B. Boehm, "Managing software productivity and reuse," Computer, vol. 32, pp. 111-113, 1999.

[19] RA Brooker, D. Morris, and JS Rohl, "Compiler Compiler Facilities in Atlas Autocode," The Computer

Journal, vol. 9, p. 350, 1967.

[20] F.P. Brooks, "No silver bullet: Essence and accidents of software engineering," IEEE computer, vol.

20, pp. 10-19, 1987.

[21] Joseph Bukchin, Ezey M. Dar-El, and Jacob Rubinovitz, "Mixed model assembly line design in a

make-to-order environment," Comput. Ind. Eng., vol. 41, pp. 405-421, 2002.

[22] G Cantone, "Software factory: modeling the improvement," IEEE CONFERENCE PUBLICATION, no.

359, pp. 124-129, 1992.

[23] J. Cardenosa, C. Gallardo, and A. Martin, "A Practical Case of Software Localization after System

Development," International Journal Information Technologies and Knowledge, vol. 1, pp. 121-128,

2007.

[24] Census of India, 2001.

[25] G. Chastek and J.D. McGregor, "Guidelines for developing a product line production plan,"

Software Engineering Institute, Technical Report CMU/SEI-2002-TR-006, 2002.

[26] S. Chimalakonda and K.V. Nori, "An exercise in building a Software Factory," IIIT Technical Report

IIIT/TR/2008/140, 2008.

[27] P. Clements and L. Northrop, Software product lines.: Addison-Wesley Reading MA, 2001.

BIBLIOGRAPHY

118

[28] P. Clements, L. Northrop, and others, "A framework for software product line practice," Web

document, 2004.

[29] (2009) Computer Based Functional Literacy Solution For Adult Literacy. [Online].

http://www.tcs.com/resources/case_studies/Pages/Corporate-Sustainability-Computer-Based-

Functional-Literacy.aspx

[30] M.E. Conway, "Proposal for an UNCOL," Commun. ACM, vol. 1, no. 10, pp. 5-8, 1958.

[31] B.J. Cox, "Planning the Software Industrial Revolution," IEEE software, vol. 7, pp. 25-33, 1990.

[32] B. Cox and E. Yourdon, "No Silver Bullet Revisted," Scientific American, p. 86, 1994.

[33] I. Crnkovic and M. Larsson, "Challenges of component-based development," The Journal of

Systems & Software, vol. 61, pp. 201-212, 2002.

[34] Michael A. Cusumano, "Software factory: a historical interpretation," IEEE Software, vol. 6, pp. 10-

73, 1989.

[35] K. Czarnecki, "Overview of generative software development," Lecture Notes in Computer Science,

vol. 3566, p. 326, 2005.

[36] K. Czarnecki and U.W. Eisenecker, "Generative Programming--Methods, Tools, and Applications,

2000," Boston: Addison Wesley, vol. 26, p. 832, 2000.

[37] OJ Dahl, EW Dijkstra, and CAR Hoare, Structured programming. London and New York: Academic

Press, 1972.

[38] Sybren Deelstra, Marco Sinnema, and Jan Bosch, "Experiences in software product families:

Problems and issues during product derivation," , 2004, pp. 165-182.

[39] W. Edwards Deming, Out of the Crisis.: The MIT Press, 2000, vol. 1.

[40] F. Van der, "Software product families in Europe: the Esaps & Cafe projects," IEEE software, pp.

41-49, 2002.

[41] L. Dublin, "If You Only Look Under the Street Lamps. Or Nine e-Learning Myths," Best of The

ELearning Guild's Learning Solutions: Top Articles from the EMagazine's First Five Years, p. 1, 2008.

[42] Khaled El Emam and A. G Koru, "A Replicated Survey of IT Software Project Failures," IEEE Softw.,

vol. 25, pp. 84-90, 2008.

[43] H. Ford, My life and work.: Cosimo Classics, 2007.

BIBLIOGRAPHY

119

[44] WB Frakes and K. Kang, "Software reuse research: Status and future," IEEE Transactions on

Software Engineering, vol. 31, pp. 529-536, 2005.

[45] N. Friesen, "Interoperability and learning objects: An overview of e-learning standardization,"

Interdisciplinary Journal of Knowledge and Learning Objects, vol. 1, pp. 23-31, 2005.

[46] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design patterns: elements of reusable object-

oriented software., 1995.

[47] F.B. Gilbreth, "Science in management for the one best way to do work," Classics in management,

pp. 243-291, 1960.

[48] F.B. Gilbreth and L.D. Brandeis, Primer of scientific management.: Adamant Media Corporation,

2005.

[49] Robert L. Glass, "Failure Is Looking More like Success These Days," IEEE Softw., vol. 19, p. 104,

2002.

[50] A.R. Golding and P.S. Rosenbloom, "Improving rule-based systems through case-based reasoning,"

In Proceedings of AAAI-91, 1991.

[51] Jack Greenfield, Steve Cook Keith, and Stuart Kent, Software Factories: Assembling Applications

with Patterns, Frameworks, Models & Tools.: John Wiley & Sons, 2004.

[52] J. Greenfield and K. Short, "Software factories: assembling applications with patterns, models,

frameworks and tools," in ACM New York, NY, USA, 2003, pp. 16-27.

[53] Martin L. Griss, "Software reuse: from library to factory," IBM Syst. J., vol. 32, pp. 548-566, 1993.

[54] P. Hantos and M. Gisbert, "Identifying software productivity improvement approaches and risks:

construction industry case study," IEEE Software, vol. 17, pp. 48-56, 2000.

[55] Z. He, DW Bustard, and X. Liu, "Software internationalisation and localisation: practice and

evolution," in National University of Ireland Maynooth, County Kildare, Ireland, Ireland, 2002, pp.

89-94.

[56] P. Hendriks, "Why share knowledge? The influence of ICT on the motivation for knowledge

sharing," Knowledge and process management, vol. 6, pp. 91-100, 1999.

[57] JD Herbsleb and D. Moitra, "Global software development," IEEE software, vol. 18, pp. 16-20,

2001.

[58] Watts S. Humphrey, "Software and the factory paradigm," Softw. Eng. J., vol. 6, pp. 370-376, 1991.

BIBLIOGRAPHY

120

[59] "IEEE standard for software productivity metrics," IEEE Std 1045-1992, 1993.

[60] M. Jaring and J. Bosch, "Representing variability in software product lines: A case study," Lecture

Notes in Computer Science, pp. 15-36, 2002.

[61] Capers Jones, "Why software fails," Softw. Dev., vol. 4, pp. 49-54, 1996.

[62] TB Steel Jr, "A first version of UNCOL," AFIPS Joint Computer Conferences, pp. 371-378, 1961.

[63] K.C. Kang, S.G. Cohen, J.A. Hess, W.E. Novak, and A.S. Peterson, Feature-oriented domain analysis

(FODA) feasibility study, 1990.

[64] K.C. Kang et al., "FORM: A feature-oriented reuse method with domain-specific reference

architectures," Annals of Software Engineering, vol. 5, pp. 143-168, 1998.

[65] KC Kang, J. Lee, and P. Donohoe, "Feature-oriented product line engineering," IEEE software, vol.

19, pp. 58-65, 2002.

[66] Y. Kim and E.A. Stohr, "Software reuse: survey and research directions," Journal of Management

Information Systems, vol. 14, no. 4, pp. 113-147, 1998.

[67] M. Knowles, The adult learner: A neglected species.: Gulf Publishing Company, 1973.

[68] S. Kotha, "From mass production to mass customization: the case of the National Industrial Bicycle

Company of Japan," European Management Journal, vol. 14, pp. 442-450, 1996.

[69] C. Krueger, "Eliminating the adoption barrier," IEEE Software, vol. 19, pp. 29-31, 2002.

[70] C.W. Krueger, "Software reuse," ACM Computing Surveys (CSUR), vol. 24, pp. 131-183, 1992.

[71] BW Leverett et al., "An overview of the production-quality compiler-compiler project," Computer,

vol. 13, pp. 38-49, 1980.

[72] (2009, Wed 16th Oct) Library Assets in Software Product Lines. [Online].

http://www.sei.cmu.edu/library/abstracts/productlines/

[73] J.K. Liker, The Toyota way: 14 management principles from the world's greatest manufacturer.:

McGraw-Hill Professional, 2004.

[74] E.A. Locke, "The ideas of Frederick W. Taylor: an evaluation," Academy of Management Review,

pp. 14-24, 1982.

[75] S. Macrakis, "From UNCOL to ANDF: Progress in standard intermediate languages," Open Software

BIBLIOGRAPHY

121

Foundation, macrakis@ osf. org, pp. 1-18, 1993.

[76] C. Marling, M.H. Sqalli, E.L. Rissland, H. H Muñoz-Avila, and D.W. Aha, "Case-based reasoning

integrations," AI magazine, vol. 23, pp. 69-86, 2002.

[77] M. Matinlassi, "Comparison of software product line architecture design methods: COPA, FAST,

FORM, KobrA and QADA," in IEEE Computer Society Washington, DC, USA, 2004, pp. 127-136.

[78] Y Matsumoto, "A Software Factory: An Overall Approach to Software Production," Software

Reusability, IEEE Computer Society, pp. 155- 178, March 1987.

[79] J.D. McGregor, L.M. Northrop, S. Jarrad, and K. Pohl, "Guest Editors' Introduction: Initiating

Software Product Lines," IEEE SOFTWARE, pp. 24-27, 2002.

[80] M.D. McIlroy, "Mass produced software components," Software Engineering Concepts and

Techniques, pp. 88-98, 1969.

[81] M.H. Meyer and A.P. Lehnerd, The power of product platforms: building value and cost leadership.:

Free Press, 1997.

[82] J. Mezirow, "A critical theory of adult learning and education," Adult education quarterly, vol. 32,

p. 3, 1981.

[83] H. Mili, F. Mili, and A. Mili, "Reusing software: Issues and research directions," IEEE Transactions

on Software Engineering, vol. 21, pp. 528-562, 1995.

[84] U. Nations, "Human development report 2007/2008," Norway [HDI fact sheet]. Retrieved January,

vol. 20, p. 2009, 2008.

[85] J. Ben Naylor, M.M. Naim, and D. Berry, "Leagility: integrating the lean and agile manufacturing

paradigms in the total supply chain," International Journal of Production Economics, vol. 62, pp.

107-118, 1999.

[86] M. Nichols, "A theory for eLearning," Educational Technology & Society, vol. 6, pp. 1-10, 2003.

[87] K.V. Nori, "Some Lessons from an Experiment in eLearning: TCS’Computer Based Functional

Literacy Programme," International Journal of The Computer, the Internet and Management, vol.

12, pp. 248-249, 2004.

[88] KV Nori, S. Kumar, and M.P. Kumar, "Retrospection on the PQCC compiler structure," in Springer,

1987, pp. 500-527.

[89] L.M. Northrop, "SEI's software product line tenets," IEEE software, pp. 32-40, 2002.

BIBLIOGRAPHY

122

[90] G. R. Notess, "Casting the Net: Podcasting and Screencasting," ONLINE -WESTON THEN WILTON-,

vol. 29; NUMB 6, pp. 43-45, 2005.

[91] A. Oberweis, V. Pankratius, and W. Stucky, "Product lines for digital information products,"

Information Systems, vol. 32, pp. 909-939, 2007.

[92] D. Parnas, "On the Design and Development of Program Families," TSE, vol. SE-2, pp. 1-9, 1976.

[93] B.J. Pine and S. Davis, Mass customization: The new frontier in business competition.: Harvard

Business School Pr, 1999.

[94] K. Pohl, G. Bockle, and F. Van Der, Software Product Line Engineering: Foundations, Principles, and

Techniques.: Springer-Verlag New York Inc, 2005.

[95] J. Prentzas and I. Hatzilygeroudis, "Integrations of rule-based and case-based reasoning," , vol. 4,

2003, pp. 81-85.

[96] M. Purvis, P. Hwang, M. Purvis, N. Madhavji, and S. Cranefield, "A Practical Look At Software

Internationalisation," Journal of Integrated Design and Process Science, vol. 5, pp. 79-90, 2001.

[97] F. Rafii, S. Perkins, B. Coll, and MA Wellesley, "Internationalizing software with concurrent

engineering," IEEE Software, vol. 12, pp. 39-46, 1995.

[98] Claudio Riva and Christian Del Rosso, "Experiences with Software Product Family Evolution,"

Principles of Software Evolution, International Workshop on, vol. 0, p. 161, 2003.

[99] C. Safran, D. Helic, and C. Gütl, "E-Learning practices and Web 2.0," Proceedings of ICL 2007, pp. 1-

8, 2007.

[100] G. Salvendy, Handbook of industrial engineering: technology and operations management.: Wiley-

Interscience, 2001.

[101] TB Steel, "Uncol: The myth and the fact," Annual Review in Automated Programming, vol. 2, pp.

325-344, 1961.

[102] D. Svensson and J. Malmqvist, "Strategies for product structure management at manufacturing

firms," Journal of Computing and Information Science in Engineering, vol. 2, p. 50, 2002.

[103] K. Sward, The Legend of Henry Ford.: Rinehart, 1948.

[104] C. Szyperski, J. Bosch, and W. Weck, "Component Oriented Programming," Lecture Notes in

Computer Science, vol. 1743, pp. 184-184, 1999.

BIBLIOGRAPHY

123

[105] D. Taylor, Global software: developing applications for the international market.: Springer-Verlag

New York, Inc. New York, NY, USA, 1992.

[106] F.W. Taylor, The principles of scientific management. New York: Harper Bros., 1991.

[107] F. Thompson, "Fordism, post-Fordism and the flexible system of production," Salem, Oregon.

Williamette University. retrieved June, vol. 23, p. 2005, 2005.

[108] M. Voelter and I. Groher, "Product line implementation using aspect-oriented and model-driven

software development," , 2007, pp. 233-242.

[109] F Wagner, Modeling Software with Finite State Machines: A Practical Approach.: Auerbach

Publications, 2006.

[110] C.R. Walker and R.H. Guest, The man on the assembly line. Cambridge, MA: Hardvard University

Press, 1952.

[111] David M. Weiss, "The Product Line Hall of Fame," in Proceedings of the 2008 12th International

Software Product Lines Conference, 2008, p. 395.

[112] J.P. Womack, D.T. Jones, and D. Roos, The machine that changed the world.: Rawson Associates

New York, 1990.

[113] J.C. Wood and M.C. Wood, FW Taylor: critical evaluations in business and management.:

Routledge, 2002.

[114] W.A. Wulf, R.K. Johnsson, C.B. Weinstock, S.O. Hobbs, and C.M. Geschke, The Design of an

Optimizing Compiler.: Elsevier Science Inc. New York, NY, USA, 1975.

[115] D. Zhou, Z. Zhang, S. Zhong, and P. Xie, "The Design of Software Architecture for E-Learning

Platforms," Lecture Notes in Computer Science, vol. 5093, pp. 32-40, 2008.

TOWARDS AUTOMATING THE DEVELOPMENT OF...

Documents

Transcript of TOWARDS AUTOMATING THE DEVELOPMENT OF...