OSS FACTORY: DEVELOPMENT MODEL BASED AT OSS

PRACTICES

Ana Isabella Muniz and José Augusto de O. Neto

Universidade Federal de Campina Grande (UFCG)

Av. Aprigio Veloso, 882- Cx Postal: 10.106, Paraíba, Brazil

Keywords: Open Source, Architecture Pattern, Student, business model.

Abstract: In this paper we present OSS Factory (Open Source Software Factory), an ecosystem aligning software

demands, undergraduation Computing students qualification and Open Software practices in a collaborating

relation, dedicated to produce open software applications to cope with market demands, using students

codification potential. A contest among students attending software engineering courses (or volunteers),

guided by professors and coordinated by a central entity is the force to move OSS Factory. To validate the

elements and interaction proposed, experiments applying the structure described in the paper have been

performed, and positive results were achieved.

1 INTRODUCTION

Since its first moves, Open Software (OS)

phenomena has gained credibility as a concrete

alternative to response world wide TI demands, no

mater if in simple home based activities or, mainly,

corporations´ needs. It’s hard to point a TI

department which does not use or has considered

adopting an OS based technology.

In the other hand, the volume of demand for

OS software’s, or improvements on those largely

used, has grown fast in last years. A research

recently developed in Brazil among small

municipalities, with no more than one hundred

thousand inhabitants, has pointed OSS software as a

promising alternative to their need of business

processes automation. In the scenario researched,

technological limitations to develop applications

using internal staff and budget shortage were main

factors to suggest OS software as an alternative. In

addition, software houses have not showed interest

in exploiting this small municipalities market.

A third issue concerning OS software its how

the popularity it has reached did not push any

expressive transformation into academy bounds.

There is no remarkable reordering in Software

Engineering curriculum, towards accommodates OS

community practices, or any orchestrated movement

to drive students closer to OS world.

The objective of this paper is to present OSS

Factory (figure 1), which is an iteration model

conceived from practical experiments, where the

three factors mentioned before were integrated to

overcome their difficulties.

Figure 1: OSS Factory architecture.

OSS Factory engine, detailed in section 2, will

integrate the three vertices of figure 1, associating

ones needs to others abilities, in continuous

interactions that will bring positive outcomes to all

involved.

Open Software world can expand its limits of

influence and actuation, so far mostly restricted to

technologies directed to support back office

services, such operating systems, and web, e-mail

and application servers. In this new scenario, OS can

Software

Demand

SE Teachin

OS Practices

OSS

Factory

616

Isabella Muniz A. and Augusto de O. Neto J. (2007).

OSS FACTORY: DEVELOPMENT MODEL BASED AT OSS PRACTICES.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - ISAS, pages 616-623

DOI: 10.5220/0002395806160623

 SciTePress

expand today communities to include less

specialized personnel, different from high or

medium expertise profile typically found in present

communities (Lima, 2005). In present days, taking

part as an affective member, with frequent

contributions accepted, of an OSS community is a

privilege of high level programmers, because the

complexity of low level software they hostage.

Observing OS Software popularization, we can

notice that main steps in their success walk were

moved by their militant’s enthusiasm, as a

spontaneous process, lacking of any systematic

coordination capable of, for instance, to make OS

culture natural part of TI professional qualification.

Today, OS software reach academy simply through

communities and the products they offer freely to

students access (MySQL, 2006) (Hibernate,

2006)(Eclipse, 2006). Except by few and eventual

conferences, commonly dedicate to a restrict public,

with no high scale publicity, the very first contact

between students and OS world comes from student

individual attitude, downloading and installing the

most popular OS tools.

Fallowing a predefined flow of activities,

combined to OS practices of software engineering,

students attending undergraduation Computing

courses are able to establish a contact with Free

Software culture under a new and different

perspective. Instead of mere OS technologies users,

under-qualification professional take part of OS

world as member of a development community,

contributing with applications engineering. In this

process students are lead by Software Engineering

best practices, in a way that they can improve their

analysis, design and coding, and extend those

abilities with OS related aspects, giving them a more

extensive and distinct qualification.

Software manufactured by OSS Factory will be

able to support deficient areas, with low/none

technological capacities do develop their own

solution or with funding impossibilities to purchase

available property software. In the experiments we

relate further in this paper, software applications

were dedicate to automate Brazilian small

municipalities business process. However, as

described in section 2, OSS Factory can easily

reconfigured do address other business process

demands.

The rest of paper is organized according to the

following structure: section 2 presents OSS

overview, along with detailed description of each of

its elements. Section 3 related contest dynamic.

Section 4 shows a real experiment applying OSS

Factory production dynamics, followed by outcomes

obtained from the experiment Section 5 points some

related work. Final concerns are related on section 6,

titled Conclusions, bring final impressions and

overall results obtained from OSS Factory

experiments.

2 OSS FACTORY OVERVIEW

Figure 2: OSS Factory overview.

2.1 Demands

Demands are the source of OSS Factory motivation.

As already menssioned, the tipical demands filled

out by OSS Factory operation come from segments

with TI needs and no technological capacity to

produce, or fund capacity to acquire them.

In study case presented in Section 4, small

municipalities in Brazil are responsible for OSS

Factory demands. According to diagnosis resulted

from SOFTEX researches (Softex, 2004), 96% of

these municipalities are habited in maximum by 100

thousand people (IBGE, 2001). They are similar in

administrative structure, as well, they have few or

none capacity to make IT infra-structure

investments. From these two characteristics (low

budget and similar business process), comes the

insight that OS applications, modelled and built

according to one of these municipalities business

processes, could be applied to the most part or all of

them, because of their process compatibility and no

costs of license, natural for OSS.

In the experiments where OSS Factory was put

in operation, demands were presented by direct

contact with small municipalities. One of their main

demands comes from business process hardly tied to

legal constraints, which the administrator is

obligated to be compliant with. Frequent changes in

legislation result in considerable efforts to keep

OSS FACTORY - DEVELOPMENT MODEL BASED AT OSS PRACTICES

617

compliance. Other common class of demands come

from social programs, supported by Federal

Government. These programs impose some pattern

procedures to the municipalities, impacting directly

in their business process and, in most cases,

requiring a minimum level of automation. In both

case, each demand of automation or support

originate in municipalities fulfils Demands box, to

be dealt by OSS Factory movements.

2.2 Contest (Competition)

Once demands are identified, a contest involving

professors and undergraduation Computing courses

students are is carried out. Contest is managed by an

entity that will be mainly responsible supervision,

with predefined activities towards software

application development that will fill out demands

found in first phase of OSS Factory. From now on,

that entity will be referred as Coordinator Entity

(CE). One single contest can address either one

demand or a group of them, depending on

professors/CE convenience and applications

complexity.

In each edition, application functional

requirements elicited from demands are divided

through contest time window. How long is this

period also must be set up among professors and

CE? Following an iterative process, students submit

the code they produce for evaluation, made by

professors and CE consultants. Grades are assigned

to the code, ranking participants in a partial result

for that phase. After that, a new phase is started,

considering requirements not addressed yet. When

all phases are accomplished, partial results are

joined and those students who have summed higher

score are the concert winners.

2.3 Tutor

Typical undergraduation Computing curriculum

include courses dedicated to Software Engineering

practices. In this context, practices mean laboratory

activities, going beyond theorical teaching and

demanding from students analysis, design,

codification, test and deployment activities. The

whole cycle is supported by classical processes and

oriented by professor in charge of the course.

Every semester, professors are obligated to

repeat efforts to find adequate applications to be

delivery as practical project to his courses. Adequate

means in a complexity and time consumption

compliant to students background and scope bounds

of his course. After not much long, this procedure

extinguishes professor possibilities and the same

applications are repeated time after time, or

professor is forced to specify application associated

to no imaginary projects, with now real clients and

requirements.

When inserted in the contest, professor will be

provided periodically with projects specifications,

arisen from real demands identified from real

clients, ready to assign among students during his

course.

2.4 Students

Students that participate to the contest can improve

their Software Engineering abilities, going beyond

traditional courses, mainly for the following reasons:

Motivation: they will work on real requirements,

elucidated from clients that will truly adopt the

application they will build, instead of usual mock

applications assigned by professors every year;

Besides, according to their performance, they may

be monetarily rewarded by his efforts, gain good

exposition to software houses market, personal

satisfaction and pride

Good practices: having contact with tutorials, being

pressured to obey recommended design,

architecture, documentation and interface patterns

delivered by CE, because they are considered in

evaluations, students will leave the process with

Software Engineering best practices naturally

incorporated.

Focussing the big picture, in the former scenario

we can find productive capacity of hundred or

thousand students being allocated in to-be-never-

used applications. Signing this great amount of

students contests, CE will have a small software

development army, obtaining the same benefits that

Open Software communities currently get from great

numbers law (Moura et. all, 2006). In addiction,

client demands are solved with no cost in software

production phase.

2.5 “done” Applications

Every time OSS Factory repeats the production

process (a contest edition) the set of application

ready to use is increased, offered with no licensing

restriction, except those typical for OS software

(keeping it OS, making modifications always public,

etc.). The mechanism used to deploy applications is

a collaborative web portal (Flo-pref Library, 2006),

where the community composed by CE, Software

Engineering professors, students signed in OSS

ICEIS 2007 - International Conference on Enterprise Information Systems

618

Factory development activities and clients who have

applications installed (or interested in adopting any

of them) may freely interact, evolving the software

already built, in the same dynamics found in OS

software communities.

Clients can access applications through different

manners. The most simple of them is just

downloading directly from web portal. Depending

on complexity, application deployment may require

support for installation, personnel training and

preliminary data insertion before being ready to use.

These activities may be accomplished by specialized

small companies, inserted in a regional economic

development context (Moura et. all, 2006).

There are few details hid in OSS Factory

structure described above. Those details must be

addressed end actually resolved to allow smooth

interaction among factory’s parts. When the whole

structure runs into operation, there are a number of

convention that must be previously defined, in order

do permit that each of participants may play his role,

offering the services expected from him and, at the

same time, receiving all the benefits from others

players.

We mention now some of details and convention

that need to be set before OSS Factory operation:

1) How to present demands in a clear

language, enough to guarantee that the

application will correctly address demands

requirements?

2) How professor will hear about the contest?

What support material will he count with to

deal with his students, besides demands

description?

3) Which criteria will be used to classify and

rank contest participants? Different

paradigms and technologies can be

evaluated under horizontal, no-distinction

criteria?

4) Who coordinates the contest? How

coordination is carried out?

5) How communication process, assumed to

be fluent among participants, will happen

in OSS Factory domains?

Next section describes details of OSS Factory

components, capable to answer questions above,

providing a more realistic understanding of factory’s

operation.

2.6 Technology kits

An Architectural model, followed by technological

patterns, was proposed to be adopted by all

participants of OSS Factory. This model helps to

maintain compatibility among applications

conceived during students contest. For instance, a

specific application selected to a contest edition may

be just a fraction of client demands, which has been

divided to be accommodated in time window

available to that edition. In the next edition,

remaining demands will be implemented and it is

desirable that they can easily extend the first part,

without any compatibility drawbacks. The

architectural model defined aims to mould

applications to become easy to maintain, to evolve

and to be integrated each other.

Along with compatibility issues, architecture is

expected to be easy do learn and work with.

Students with basic development abilities must be

able to adopt it. In the other hand, the same

architecture must be well designed, up to current

development patterns, otherwise will face resistance

from more advanced developers. As a final

requirement, the architecture must allow students to

produce plain application (1-tier, browser-servlet,

for example) or more scalable designs (2, 3, n-tiers),

that will contribute to their development capacities.

2.7 Training Kit

Technological Patterns established to OSS Factory’s

applications intend to contribute to students software

engineering qualification. Students can access

information kits, built based on software

engineering best practices, a technologies adequate

to market current expectations.

The training process is coordinated through

pedagogical support items, available on contest web

portal, freely accessed by all participants, students

and professors as well. Training kit is composed by

the following items:

a) Architectural mode description.

This document presents the architecture

overview. Each of its elements identified and

briefly described, based on the role played in

the structure. The document is detailed enough

to be comprehensive and followed by

beginners, who had never built applications

under that type of architecture;

b) Tutorials comprehending each of technologies

defined as OSS Factory pattern.

Considering architecture definitions include a

series of technologies constraints, it is

fundamental to provide OSS Factory’s players

with pedagogical support to domain those

technologies. The tutorials go through

technologies details, and can be compacted by

OSS FACTORY - DEVELOPMENT MODEL BASED AT OSS PRACTICES

619

professors, according to students profile and

needs, to accelerate students learning;

c) Complete applications example to download.

Small applications, fully implemented, where

all technological patterns defined in OSS

Factory’s architecture can be found and

analyzed, with entire source code and full

documentation. This material obeys a practice

typically adopted by software developers, when

trying to learn new technologies solving

problems never faced before. In these situations,

developers use to search source code of already

done (and working well) applications, compare

with the code they are writing, trying to map

similarities and differences between them, in a

way to understand new technology or a

puzzling problem.

2.8 Didactic Kit

This kit is mostly dedicated to professors. Before

starting a new course, is part of professor’s work to

plain carefully the activities to be developed. Define

book and reference material to be followed, to

prepare didactic material, presentation slides,

exercises, to prepare web page to interact with

students during the course, to define examinations

and to schedule topics through course period, are

example of such activities.

These preparative activities are determinant to

the quality of course and can, therefore, interfere in

student learning.

Didactic kit provide by OSS Factory hold, in

resume, the items listed bellow:

a) A web page template;

b) Class scheduling, proposing a division of

discipline content along course period;

c) Class content, offered in presentation

slides;

d) Exercise lists;

e) Examination proposal, per chapter;

f) Spreadsheet models to grades registration;

g) Bibliography recommended;

h) Free e-books.

The kit motivates professors to join OSS

Factory, gaining qualification to him and his

students. Besides, taking part of the process,

professors will propagate OS practices in under

graduate students, as a real alternative for software

development.

Qualification offered by Didactic Kit is based on

well succeeded experiences and classical authors;

2.9 Infrastructure Kit

OSS Factory is supported by a web portal used to

give publicity to activities and, mainly, to provide

and coordinate communication flow among

participants. Among most important features,

students, volunteers and professors subscriptions,

Kit’s hostage and distribution, information

concerning appraisals, schedules and description of

contest dynamics.

This web portal is also OSS application

repository, where students will upload source code

and documentation they produce in every phase of

contest.

3 A MODEL OF FREE

SOFTWARE CONTEST

Figure 3: OSS Contest model.

The contest was managed by Entity Coordinator

(CE), represented by the nucleus of Via Digital (Via

Digital, 2006) project, located at the Federal

University of Campina Grande (UFCG -

www.dsc.ufcg.edu.br), whose role can be

undertaken by an institution or an involved OS

community. This entity has as fundamental

attributions:

a) Select and authorize professors to perform

during the contest.

b) Define the standard architecture of the

applications.

c) Define the software requirements.

d) Construct and maintain the contest portal.

e) Awards.

ICEIS 2007 - International Conference on Enterprise Information Systems

620

3.1 Contest Dynamics

The coordinating entity

The contest begins when publishes on web portal the

list (or single) applications to be CE portal

availability of the components to be developed.

After this event, comes enrolment of the

competing teams and volunteers. The difference

between the two types of participants is that first

ones are taking a course from a professor with

credentials by CE, while the others have personal

interest in the contest and seek insertion in the

competition by the professor. It is up to the

professor with credentials, according to his/her

possibilities and management, to limit the number of

volunteers enrolled under his/her responsibility – the

professor with credentials himself/herself does this.

After enrolment, the period of contributions by

the enrolled groups and volunteers begins.

Depending on the modality of contest, the

contributions can be offered or not. Figure 4 shows

the dynamics of the contest. Notice that the traced

elements report the activities concerning only to

interactive modality.

Figure 4: Contest dynamics.

In the first modality, the phase after the

specification and enrolment is along period of

implementation, which will end with the submission

of contributions completely constructed by the

students. CE will define which applications each

credentialed professor will evaluate and these

evaluations will compose the ranking of the ones

who will be awarded prizes. In none of the

modalities a professor will be allowed to evaluate

participants under his/her own guidance.

In the interactive modality, the implementation

will happen in cycles, fulfilling a sequence

requirement in which the CE will fraction the initial

specification of the applications. At the end of the

deadline for implementing a requirement, the

submitted contributions will be judged by the

credentialed professors. After the contributions are

evaluated, a ranking iteration will be formed for

each application and a score will be attributed

according to the position of the participant (group or

volunteer) in the ranking.

At the end of the last iteration, the score obtained

by the groups in each stage will be computed,

defining the winner of the contest.

4 A CASE STUDY

In the section, a real case will be presented, where

the proposal described in item 2 goes through some

practical experiences

Conception

With the beginning of the school year at the Federal

University of Campina Grande (UFCG) and the

Integrated College of Patos (FIP), the deficiency for

new software projects with real applications in the

market is great. After the creation of the business

model [6] to be implemented by Via Digital (Via

Digital, 2006), we found the opportunity to create an

inter-city contest among students of these two

universities.

Construction

The first contest was implemented in UFCG’s

Software Engineering Laboratory (SEL) discipline

of the Computer Science course. In this class, there

were 12 students enrolled, thus forming six groups

of two students each. The professor of this discipline

exerted the role of tutor of all the groups, lecturing

about the process, as well as about the technologies

that were used during all of the life cycle of the

software. In this case the development process YP

(easYProcess, 2006) was adopted.

The groups received professor’s tutorship on

their questions, and were evaluated by a committee

formed by three chairs. These were responsible for

choosing the application which would be the target

of the contest. For this choice a list of demands was

surveyed, involving six city halls in Brazil during an

event of Free Software (SOLISC, 2005). This

assessed priorities from 1 (low) to 5 (high). The

demand reaching the highest priority would be

chosen for the contest. At the time, the chosen

component was the Pharmacy and Medicine Control

(ViaCOM). The CE met all the desired requisites at

the city hall (specifically the Health Department).

After that, a chronogram with all the activities and

deliverables was elaborated to be given to each

group.

OSS FACTORY - DEVELOPMENT MODEL BASED AT OSS PRACTICES

621

Evaluation

In a previous phase of interaction with city halls,

two other teams of discipline of SEL developed two

applications, as project of disciplines, established in

the demands of these city halls. That experimental

phase tried to create an architectural standard that

could allow interoperability among applications

(done and to be done). Besides, the experiments

were base to documentation standards (code, user

guide and configuration and installation manuals)

aiming to optimise communication and

understanding of application. In addition, interface

design standard was established, in order to allow

easy recognition and use of application. This has

revealed important to accelerate users learning

curve. The evaluation of these results can be

observed in (Moura et. all, 2006).

Table 1: Evaluation criteria.

Criteria

Eliminatory Classificatory

Conforming to the

architectural structure

• Code parameters

9 Tests

9 Project patterns

9 Cohesion e coupling

Functionalities

(specific/delivered)

• Conformity with

documentation pattern

These standards had collaborated in the

definition of kits that have been described in section

2. CE forwards these kits to professors, who

divulged specifications to the groups. All of these

initial artefacts were displayed on a web page, used

to follow-up of the groups. On this page, each group

could obtain information about the deliverables

dates, case studies, patterns (architectural,

documentation, and interface), observations about

each group, as well as evaluation criteria adopted by

the CE, as describe at table 1 following.

Evaluation was made in of ten days intervals,

due to the chronogram of the disciplines. All the

groups used CVS (CVS, 2006) to manage system

changes and versions. The CE, in turn, downloaded

the projects and evaluated them according to the

criteria described above. After each deliverable, a

winning group was chosen, and the other groups

began using that group’s code, not necessarily

having to erase the previous project, but taking

advantage of the best part of each one and thus

creating an even better project.

Experience of code exchanging among groups

have been not positive and found strong resistance

from students, because of considerable overhead

demanded to continue other group’s source code.

Based on these results current evaluation

methodology does not recommend any exchange of

source code among participants.

At FIP, the Information Systems course, not

having the same reality in the formation of students,

the professor of the Information Systems Laboratory

discipline divided the class into 5 groups, and

contrary to UFCG, opted not to follow the patterns

conceived by the CE. Instead, he used all this

material (Didactic, Technology and Training Kits)

and performed training with the students so that they

could create a application with quality, even without

following any patterns. At every iteration (fifteen

days), the professor performed an evaluation of the

groups. The one that obtained the best grades was

evaluated by the CE examining the UFCG groups.

At the end of all the stages of the process, the

group with the best performance had its system

(code and documentation) awarded.

To the end of the contest some data had been

raised referring the production of the implemented

applications, as it shows the table 2:

Table 2: Pós-Contest results.

Indicators: Numbers:

Tutors 2

Students 30

Applications 7

Use Cases 300

Documentation (JavaDoc) 10.504 (lines)

Unit/Accept Testes 140/350

City halls (Clients) 5

14%

29%

43%

conception

construction

implantation

production

Figure 5: Distribution map of applications.

From table 2 the great contribution can be

observed to be given by the academy in the

ICEIS 2007 - International Conference on Enterprise Information Systems

622

production of information systems with real

applications. In an only period of learning stage (4

months) 30 students of software engineering had

obtained to produce 7 software applications. In

figure 5, is shown the distribution of applications in

phases, has that 43% of these systems are in full use

in city halls and 29% already are being implanted.

Also it can be observed, the strong concern in the

good attendance to the customer, therefore the

necessity to carry through tests, to register and

possess a friendly interface.

5 FUTURE WORKS

A next stage of experiments involving all the aspects

of the OSS Factory is in an elaboration phase. In this

round, the same elements will be working, only the

community of students and professors included will

be increased.

The purpose of the experiment is to evaluate the

complexity of managing a larger quantity of people

involved, geographically spread out, with more

heterogeneous institutions, students and professors

than in the first edition of the contest.

With the results to the second experiment, it is

intended to launch a more ambitious edition of the

contest in 2007, with national extension, and

probably involving the construction of more than

one application in the competition, where the

aspects conceived in the first phase and improved in

the second phase will escalate to quantities of

participants near the communities of the most

popular OSS.

At present, we have only a sentiment of

compatibility with the model proposed with the

modus operandi of the OSS community. With a

greater popularization of OSS, this contact could be

extended. We intend to more precisely detect the

community’s acceptability of the model OSS

Factory, with the development induced by requisites

and awards, consequently less free than dynamics of

classic communities.

6 CONCLUSIONS

The proposal of the OSS Factory is to have

coordination among its three vertexes, so as to

extract potentialities from each one of them,

attending to the demands of the others.

Each element and relative activities within OSS

Factory context was conceived and defined in an

incremental set of experiments, under Via Digital

project.

Recent experiments performed show that its

dynamics contributes on teaching of practical

software engineering courses, with real and

motivating activities using specialized didactic

material, which makes possible improvements in

students qualification process. These results have

been obtained in real cases of OSS Factory

operation. At the same time, the performance of

OSS Factory showed to be capable of responding to

demands and solving real problems at small city

halls, through typical practices of OSS

communities.

With new experiments, scalability of the model

will be assessed, as well as its performance in

producing applications that will produce the

automatization to other business processes.

REFERENCES

Lima, C. A. Práticas para Gerência e Desenvolvimento de

Projetos de Software Livre. Federal University de

Campina Grande, 2005.

MySQL – Available at: http://www.mysql.org – Last

access: December 11/2006.

Hibernate - Available at: http://www.hibrenate.org – Last

access: December 11/2006.

Eclipse - Available at: http://www.eclipse.org – Last

access: December 11/2006.

SOFTEX, Report - Projeto Aplicação de Software Livre

em Prefeituras. SOFTEX Association, 2004.

IBGE, Censo 2001, Instituto Brasileiro de Geografia e

Estatística (IBGE - The Brazilian Institute of

Geography and Statistics). Available at

www.ibge.gov.br , 2001.

Moura, A. et. All. Open Source Software in Small City

Governments and the Promotion of Regional

Entrepreneurship. eChallenges Proceedings 2006.

Barcelona, october 2006.

FLOApp - Available at:

http://flopref.paqtc.org.br:8080/flop/ – Last access:

December 11/2006.

Via Digital – O caminho inteligente para a informatização

pública.Available at: http://www.viadigital.ufsc.br –

Last access: December 11/2006.

easYProcess Development Process. Available at:

http://www.dsc.ufcg.edu.br/~yp – Last access:

December 11/2006.

SOLISC - Available at: http://www.solisc.org.br – Last

access: December 11/2006.

CVS - Available at: http://www.cvshome.org – Last

access: December 11/2006.

OSS FACTORY - DEVELOPMENT MODEL BASED AT OSS PRACTICES

623