Software Development Life Cycle, Open Source Engineering

Open Source Science Journal Vol.1, No. 2, 2009

111

Software Development Life Cycle,

Open Source Engineering Component

Sorin PAVEL

Academy of Economic Studies, Bucharest, Romania

[email protected]

Abstract: The open source engineering process is presented as a field of software

practice and research. The stages of open source development life cycle are defined. The

objectives, resources, time periods, results and risks are settled. The open character of every

life cycle component is outlined. Through comparison with the development life cycle of the

non-open source software, the ripple effect is defined. The development life cycle is integrated

in one, unique concept specific to open source engineering.

Keywords: software engineering, open source, development life cycle.

1. Open source engineering

Through the latest years, a distinct field appeared, giving the fundaments of the open

source software development practice. The open source software is now a reality and such

products already available show a great quality proving that the techniques, methods and the

tools work efficiently.

The open source engineering roots itself in software engineering which underlies the

industrial software production.

The software engineering chapters refer to:

- software life cycle with individual approach for every phase, from requirements

elaboration, software design, testing, to software reengineering;

- dealing with the quality side of the development process and the software product;

- considering the economics and the efficiency aspects from cost planning, resource

need and activities graph to the profitability estimation;

- developing all the activities concordantly with the project management requirements

in order to assure the IT investment success

In the current literature on this matter, there are many publications of large interest.

[1] covers all aspects of programming process from the phase of initial design, to the

maintenance of a finished product and even planning for new versions. However, the bulk of

the code concentrates on actual techniques for writing good code, from naming of variables

upwards. When issues get controversial, they are noted as such, and the strengths and

weaknesses of each argument are presented. Examples of good and bad code are given in

Pascal, C, Basic, Fortran and Ada. Chapter headlines include: characteristics of high-quality

routines, general issues in using variables, controlling loops, layout and style of programming.

In [2] the author uses a four-layered approach for software engineering:

- tools, meaning automation or semi-automated support for the methods and process;

- methods or technical know-how;

- processes that holds the layers together and the basis for management control of a

software project;

- quality issues.

The software engineering sections considered by the author are five:

- the software process including process models like evolutionary, waterfall and agile

development – XP and DSDM;


112

- modeling including requirements and design for architectural, component level, user

interface, pattern based and web application parts;

- quality management including techniques for review, quality assurance, testing,

formal verification and metrics;

- managing software projects including general project management, metrics,

estimating, scheduling, risk and maintenance and reengineering;

- advanced topics including process improvement and emerging trends.

Software architecture as important part of software engineering is treated in [5],

covering:

- the fundamentals and process of software architecture;

- the role and activities of the software architect;

- managing stakeholders interested in architecture;

- focusing on what is architecturally significant.

Some definitions and concepts included are based on IEEE 1471: “Recommended

Practice for Architectural Description”.

[3] also focuses on software architecture and show how a beautiful architecture

produces a robust, elegant, flexible and maintainable software design. It breaks down the

subject from the beginning discussing the scope, structure and roles of a good architecture,

giving examples of best practices. The effects of poor architecture are well described: missed

deadlines, high cost of changes, excessive complexity and staffing problems.

ISEB offers foundation and more advanced certificates in various IT fields. Software

testing as a software engineering phase is one of them. [4] covers software lifecycle activities

and the corresponding review and test methods. The “V model” and iterative are both

considered along with various levels of testing and reasons for system, acceptance, unit and

integration tests. Static and dynamic analyses are given a good coverage and technical content

is backed by the techniques of test management based on risk, the use of metrics and tool

support.

Besides books, there are some scientific magazines on software engineering like IEEE

Software [6] which deals with issues concerning:

- requirements analysis;

- software and process design and architecture;

- programming techniques and tools;

- software testing;

- software career development;

- human aspects of software engineering.

Another magazine for software professionals is Better Software [7] with issues on:

testing, tools, defect tracking, security, metrics and management. Other journals in the same

field are: ACM Transactions on Software Engineering Methodology, IEEE Transactions on

Software Engineering, Springer Empirical Software Engineering, Springer Software and

Systems Modeling, Wiley Journal of Software Maintenance and Evolution, Automated

Software Engineering, International Journal of Agent Oriented Software Engineering,

Software Quality Journal, Knowledge Engineering and Software Engineering and so on.

In 1995 the Economic Informatics Department of the Academy of Economic Studies

held the 2nd International Conference of Economic Informatics having Software Engineering

as main theme. The sections of the conference were:

- Methods, Technics and Programming Tools

- Security, Standards and Software Quality

- Open System and Distributed Processing

- Multimedia

- Databases


113

- Searching Methods in Solution Space

- Expert Systems in Economy

- Information Systems

- Economic Modelling

- Statistical Methods

The Conference was an opportunity for a complete overview of the local and

international research results concerning theoretical and practical software engineering.

In informational society and especially in knowledge based society, the field of

software engineering acquires special importance because of the growth in application

complexity and because of the necessity for quick, reliable and quality driven products.

2. The open source target group

Open source software is a structure that operates with two target groups. The first one

is consisted of the programmers, designers, testers which contribute to product making. The

one who is making an offer should know if the problem proposed is:

- interesting in itself by difficulties;

- challenging by the resources it needs and by the degree of newness.

The second target group is consisted of the users. The one who is making the offer

should also have an image of this group. If the challenge is persuasive enough, other software

developers will draw near and contribute to the new component. The developers target group

is chosen using the information found in:

- websites with comments on the current open source software developments;

- the rhythm of entering the market of identical open source components, or similar

techniques used by applications that need new cycles of software engineering;

- existent software products which, giving a certain complexity level, a medium

productivity and using forecast models, estimate close enough the number of

specialists for each category: analysts, programmers, designers, managers.

Giving the open source software users, the final users are identified – those who have

data and want results, along with the intermediate users – who take open source components

and integrate them in their own applications. Setting the target group structure, and especially

quantifying the impact of an open source proposal is the key of success regarding both the

quality and the number of the participants.

Open source is one of the few activities which illustrate how quantity over a certain

level means quality. If many programmers participate, they will elaborate different versions of

the same procedure. Giving a certain performance criterion, differentiation means:

- existence of a small number of very effective procedures;

- existence of a small number of poor procedures;

- existence of a large number of procedures with similar accepted medium performance,

not extraordinary but not useless.

That means that the more and different open source programmers, the bigger chance to

have efficient procedures.

The target group study gets more interesting when the one making the offer wants a

certain technology, because the estimation of the ones who use new technologies is only done

by similarity, lacking enough information for model using.

It’s well known that just one percent of the programmers are oriented on new

technologies. If we apply the same proportion, we get the dimension of the target group,

which has to be corrected with the fraction of the programmers that are oriented on open


114

source development. The estimated number of the target group members is ENTG, following

the relation:

ENTG=A*B*NP

Where:

NP – number of programmers;

B – coefficient of those oriented on new technologies;

A – coefficient of those oriented on open source;

The number of open source users is estimated using market research for similar

applications. In case of impossibility of market research, the number of open source users,

NOSU, follows the relation:

NOSU=NUIOS+NFUOS

Where:

NUIOS – number of users that integrate open source components in their own

products;

NFUOS – number of final users of open source.

If, for a given successful open source software, the number of uses is known, the

proposed application is estimated to have the same impact, having the same number of similar

users, NSUOS. Using a risk coefficient, C, the relation becomes:

NUFOS=C*NSUOS

For discovering the intermediary users of open source components, NIUOS, the

relation includes the weight of reused opens source components, D, the programmers’

productivity in medium components, WP, and their complexity, CY as follows:

NIUOS=D*WP*CY

These simple, coefficient-based models only create a rough overview because of their

level of aggregation and the relative character of the coefficients which might present large

fluctuations in time.

The databases of solitary or group initiators for open source applications should be

consistent in order to offer a realistic fundament of the project.

3. Requirement analysis

In classic software development cycle, requirements are rigorous, clear statements that

define all the elements needed for building a software application. Contrary, the open source

requirements have an open character, meaning that:

- the first form of an open source requirements contains enough elements in order for all

developers to understand the goals, input data, algorithms, technology and results;

- the following forms are based upon the previous ones; the open character allow the

developers to:

o add fields to input data structure;

o change computation models;

o add final results.

Everyone that contributes to the development to an open source component adds or

improves what is already created. There are few exceptions when changes are referring to

software fundamental concepts.

Requirements are like old, popular poetry. Somebody composes a text, and other

anonym authors like the composer himself enrich the text adding new lines, without changing

original sense.


115

Compared to the classical software requirements described in diverse software

engineering books, the open source software requirements are described by:

- flexibility which means that both the designers and the developers have enough room

to adapt and change requirements;

- openness to adopt the contributions of all who participates in the open source

application development; if requirements are build on a tree structure, the open

character allows the text to receive other text insertions on one level, Figure 1, and

also text details, Figure 2.

Fig. 1. Adding text on the same detail level

New texts containing model descriptions, C4 and C5, are added to the initial structure.

Fig. 2. Increasing detail level

In Figure 2, for requirement text C2, further details are given by adding texts C21 and

C22. As in the classical case, the consistency of the entire requirements text has to be assured

by:

- adding different data, in order to increase the level of description details;

- adding new computation modules which increases the application’s level of

complexity by bringing new elements in order to complete the workflow;

- adding new results which better describes the behavior of both the open source

collectivity and the software product.

Because of their maximum level of transparency and voluntariness, the open source

products impose continuity as the one and only manner of work.

Continuity requires:

- use of methods and techniques that are well known and accessible to many

programmers;

S

C1 C2 C3

C21 C22

S

C1 C2 C3 C4 C5


116

- building texts using the exact base method, in order for specialists to contribute to

requirements analysis;

- keeping all that was done before, without changing anything that would languish the

process; changes bring local alteration but also modify preceding phases which would

require reloads of previously closed sessions.

The specific character of open source development processes resides in:

- understanding what has already been defined in requirements until present time;

- accepting the elements within specifications;

- parallel building of elements that differentiates from already existing parts, without

excluding functioning modules or almost working sequences;

- simple isolation of texts accomplished through different concepts or technology,

stating methods to undertake existing data and offer compatible results; the

independent character is gained only at the requirements level when new text for

distinct component is defined; arriving to a collage of requirements, the solid base for

developing a competitive open source product is established.

Requirements analysis as a time process allows understanding evaluation about the

open source product role along with verification of specialists’ capacity for materializing own

contributions first through clear texts of definition and then through code lines that form

subprograms.

In open source product development, the condition that requirements analysis is done

by specialists that were also very skillful programmers becomes obtainable. Those who have

practical contributions to open source development are shrewd programmers who:

- have rich experience;

- have practical verified results;

- know how to develop usable requirements for other programmers;

- have the harshness necessary which reflects in requirements;

- use common terminology.

Within requirements, there are coding details that clearly states what is to be done and

especially how. Instead of ambiguous definitions, requirements include:

- code lines for describing input data as operands, having type, length and initial values;

- description of algorithms using diagrams or pseudo code;

- clear coding indications about control structures, parameters passing methods and

even details for deleting approximate approaches.

If requirements contain graphic representations, they become familiar by the way of

including explanations, by involving keywords from coding languages, by undertaking

identifiers built on C++ or C# syntax rules. Therefore, programmers assume directly those

elements into their sequences.

Requirements have a natural structure regarding the coding activity. Program structure

follows the same pattern as requirements structure. From each requirements section clearly

appear software components, assuring a qualitative interaction between this phase of the

development life cycle and others. Requirements also contain test datasets and directives for

the testing process. The coding experience shows how the test datasets must be elaborated in

order to cover all the branches of the software tree.

In requirements several issues have to be clearly stated:

- computation formulae;

- input data;

- results structure.

Those who read requirements and analyses the three elements above know how to

build test datasets that include all the details.

Three matrices are built:


117

A – reflects how data covers computation formulae;

B – shows how computation formulae cover results;

C – displays how the test dataset uses input data, computation data and leads to

results.

It is extremely important to insist on the very cases that are most frequent in real life.

An open source product must first satisfy those users that have the most significant weight

and then deal with special cases.

The test dataset points:

- quantitative approach by considering the increased data volume workflow;

- qualitative approach by identifying distinctive types of individuals in collectivity and

assigning them diverse datasets in structure, representation forms and correctness

criteria.

There are trap cases which have to be verified: processing that executes only when

conditions are met and processing that never executes. This is why the test datasets must be

accompanied by results that would block the process. Those workflows are not allowed.

Test datasets are undertaken from other similar applications, underlining the high

versatility and the open character of open source software.

Test datasets are anytime added and the more diverse they are, the highest chances to

verify the true level of software quality by complex testing.

4. Open source product design

Product design is the phase where the opens source application takes shape. First, after

a deep requirements analysis the way of working and the resources are clear. Software

applications typology includes:

- applications that run and display results without input data from users;

- applications that let the user select values from multiple choices, and command the

processing; the user gets a table with a set of values and explanations;

- applications that ask for an input file, X, execute the processing and returns file Y with

other representation; it is important to exist the application that inputs file Y an returns

file X;

- applications that generate other user-defined applications; applications that generate

online stores, or versions of a complex software, through customization;

- applications that process strings by certain rules, and lead to other modified strings; it

is also important to build the software that process the modified string, in order to get

the original one;

- applications that validates data in a file by marking each field whether it belongs to its

range and especially if the value is correct, related to the other fields in the structure;

this kind of software needs to be general and in the same time customizable in a way

that it’s not costly or error prone;

- applications that define, load and exploit databases, allowing standard reports;

- applications that transcode a piece of software from one coding language, Li, to

another, Lj;

- applications that operates on source texts written in coding language Li in order to

optimize it by deleting inefficient parts;

- applications that implement algorithms, aiming dimension and performance growth,

but obtaining strong interfaces that are close to the intuitive models, which draw the

user near;


118

- applications that are destined to solve problems as: testing knowledge and abilities of

future drivers, managing books in a library, managing the income and expenses budget

of individual persons and families, managing mail, converting handwriting in ASCII

text, converting spoken text in ASCII text, teaching students, testing students; all of

this applications are correct and complete and available at a certain address, in terms

and rules established by the owner.

In the product design phase, the software is assigned to a class from those mentioned

above. By similarity, it follows:

- the estimated complexity;

- the performance level;

- estimated effort until an operational version is available;

- estimated time when the product will be operational.

By studying the open source product requirements from a technical point of view, the

following aspects will be mentioned:

- the coding language;

- the type of database;

- the working standards;

- the tools and techniques used.

Secondly, the whole software structure is divided in subsystems, relating elements

from requirements with coding blocks: main program, procedures and code line sequences.

Requirements clearly state the procedures which form the open source product.

In open source production, there are stipulated precise rules about homogeneity of

frames, so that distinct procedures are written for distinct processing.

Thirdly, in the product design phase the degree of generality of the open source

software is established.

Through defined data, designed storage, and especially through the open character of

the adopted control structures, all the necessary and sufficient conditions are met to reach the

maximum generality level.

The output of the design phase includes:

- list of the modules that need to be built, with details about parameters, results and

processing formulae that have to be implemented;

- software structure as a graph where the nodes are program modules and the edges

show how the modules are called within the application;

- forms of storing the initial data and versions of initial data; all input data is conserved

for eventual processing in any moment.

The designer, being an experimented specialist, builds such a structure in order to

assure a high measure of reusability for other open source components in usage.

Fourthly, the design process crosses several steps. The first one is carried by the

person who has the idea of making the open source product. He frames initial requirements

and an initial project. The design process results in:

- additional details to procedures by adding parameters to the list, by establishing new

computation formulae which leads to new results, only suggested in requirements,

without details;

- additional procedures for processing that doesn’t exceed the context defined in

requirements, but offer ways to increase diversity of results;

- additional procedures that add flexibility concerning the methods of data acquisition,

the methods of passing initial data and the methods of performing selections and

processing results using a desktop, laptop, mobile phone or i-pod; they also include

forms of displaying results, knowing that graphical representations are more

suggestive.


119

All of this in a software architecture that is understood by all of the participants.

5. Coding

The coding phase is the most expected by the programmers, because writing code

lines is what they do best.

When programmers face the process of open source component development, they

adopt the following approaches, as they:

- develop open source code under the strict rules provided in requirements like the

disciplined soldiers follows orders;

- identify modules unvalued in requirements, modify the requirements and build the

modules discovered; a change of messages between the virtual team members starts at

this point in order to adopt the alteration;

- trace the necessity of new procedures that would gain overall performance; this

situation appears mostly in the testing process and is a way to increase the quality

level.

Code elaboration is done by adding new source lines that effectuates processing

written in requirements, as in Figure 3. Programmers deal with details regarding:

- variables’ name;

- variables’ type and building of derivate data types;

- used instructions;

- referred classes;

- needed level of aggregation.

Fig. 3. Source Code from an Open Source library [8]


120

If the programmers choose to identify open source components for reusability, the

following cases appear:

- components that undertake the same processing already exist; then, procedures are

copied as they are and integrated in the under-construction module;

- the identified components process incompletely; the programmer adds parameters,

processing instructions, keeping the building philosophy of that open source product;

- identified components only contain few elements of what is needed for the current

open source product; the programmer operates major modifications and additions

which leave only few elements of the initial version; most times is better to build a

brand new procedure than to radically modify an existing one.

The experimented programmers have already refined the instruction sequences

structures; therefore they optimize the software simultaneously with writing the code.

Programming is learned by writing code and also by analyzing and learning from code

written by other programmers. Those who approach open source software are programmers

who have disponibility to undertake procedures made by others, but only after they have

analyzed the source code and have accepted the quality level. That means that the large

majority of open source programmers perfect their profession by:

- individual study of documentation that accompanies the frameworks used for

developing software code;

- analysis of own software, especially in the testing process, when is their duty to

eliminate errors, identify their own programming mistakes and correct them;

- analysis of code written by others as open source code, in order to chose the most

appropriate product; it’s necessary for the programmer to understand the meaning of

every instruction within the analyzed open source component, to state whether the

instruction is fit or not; he must operate modifications to improve the component when

he integrates;

- participating at trainings and courses at his workplace, and gaining recognition

through international certificates.

Open source programmers are a unique category by the open character of their work

method, because they:

- accept to work without being paid;

- work for a given goal with severe initial restrictions;

- work as a part of a virtual team where all the terms and the quality levels are auto-

imposed;

- lack face-to-face communication and chief-subordinate relation, which determines a

new communication approach;

- have a strong will to go beyond their limitations, and that generates an alert rhythm of

self-training, open source being a way to test the assimilation of new technologies,

new programming methods and new tools; there is one thing to keep the pace in a

software company where news appear depending on the company’s capacity to buy

new technologies and there’s other thing to be in line with everything new in the field,

and to know how to use efficiently latest technologies, languages and tools for

software development, practicing through open source.

Because software applications address a large number of users, the source code must

be of high-quality. Every programmer wants to display their latest knowledge and to illustrate

it in code lines. Approaching an open source product is voluntarily and comes from the wish

to contribute with a well-crafted program that would generate appreciations, especially if the

author’s name and e-mail address is on sight.


121

The problem of auto-documenting the procedures is differently solved if, during the

project, it’s stated the necessity of explicitly writing comments, especially if previous

procedures already have large comments which:

- explain all variables;

- describe processing sequences significations;

- decipher meaning of constants, whether they define array dimensions, repetition

limitations or error codes for understanding abnormal processing breaks.

Outside open source software development, programmers write applications and

others test it, which lead to some weak points. In open source development, programmers

want to write quality code lines because testing is also their duty. They know that is better to

work well from the start that to patch poor sequences.

This way, the code writing gains importance because is the most practical related to

software production.

6. Testing Open Source Software

Firstly, every programmer tests his own procedures before integrating in open source

product.

Testing becomes a phase that takes place simultaneously with:

- requirements development for new processing functions, neglected by the ones who

launched the open source product idea, or by the contributors;

- coding the procedures that lingered and which complete the initial open source

project;

- own testing by programmers of new components before integrating in the product;

- optimizing the software; already exploited procedures are being improved, for higher

performance in processing speed, problem dimension and especially the precision and

generality of results.

If the following notations are used:

EIR – elaboration of initial requirements;

OSD – open source product design;

C – coding;

OST – open source testing;

OPT – own procedures testing;

OSO – open source product optimization;

DE – documentation elaboration;

NPR – new procedures requirements elaboration;

NPD – new procedures design;

NPC – new procedures coding;

NPT – new procedures testing;

The Gantt diagram for Open source product development is illustrated in Figure 4.


122

Fig. 4. GANTT Graph of open source product development

In order to mark simultaneity of operation progress in the new form, Figure 5 shows

the updated Gantt graph.

Fig. 5. Open source product elaboration graph

EOSP – execution of open source product.

The character of open source product development is apparently chaotic because of

the situation when procedures are being written while the product is executed. But this is also

the case of classical software development, when the owner gets executable versions of the

software, long before the product is finalized.

If a house is built and the owner moves in when it’s ready, meaning it’s completely

wall-faced, it’s clean and has all utilities, the owner moves his furniture and lives there. The

constructor has no reason to come back and work there. Everything is ready.

There are cases when the owner, forced by circumstances comes and lives in an

unfinished house. During this time, the constructor works until it’s finished. This is the

situation for open source products but also the case of many operational systems that are

being committed to use before they reach the final version.

Testing open source products is done using:

- test datasets defined in requirements by the project initiator; the datasets come from

the practical problem that has led to the present initiative and they are only one side of

the matter;

- examples of problems from the field literature, which is a great advantage especially

through the existence of intermediate results which truly verifies the correctness of

implementing the solving algorithm; the large diversity of problems leads to covering

many cases; the drawback is linked to the fact that data series, variables and

restrictions have small dimensions;

- datasets presented in other software documentations, allowing blending the datasets;

in product documentation data is described along with the product behavior for

EIR

OSD

C

OST

NPR1

NPD1

NPC1

NPC1

NPR2

NPD2

NPC2

NPC2

EOSP

EIR

OSD

C

OST

NPR

NPD

NPC

NPC OST

T0


123

specified data; open source testing uses the same datasets and records the product

behavior; the new open source product must have better performance; if not the testing

results orient developers’ activities to increasing performance; reloading the tests and

measuring the results must reflect diminished differences; if the process is continued,

the final open source product will be better; the open character of open source

development and the simultaneity of testing with coding permit this dynamic and

efficient approach; only finalized procedures are integrated.

Testing open source software is a continuous process that is realized for:

- separate procedures made by each programmer;

- different structures of the open source product, depending on the needs of the user

programmer.

Because of that, step by step, the testing process stabilizes, by filtering the tested

versions, so that all resources are focused on the final versions of the open source product.

It is extremely important to know exactly, all the work undertaken in the testing

process:

- listing the used test datasets;

- giving details about the behavior of the open source product for every test dataset,

stating that, in cases when events occurred, the caused were identified and corrections

were made, showing the new code;

- the results of measurement concerning product behavior, durations, processing

volumes and results quality.

Software testing remains an open process, for every user or programmer. The testing

progress is related to intense communication from all to all. All testers comment on the forum

and anyone who wants operates on the procedures to rectify the poor source code.

Fig. 6. An Open Source Forum

The open source forums are places where business and technical users meet and

exchange knowledge on open source issues. Some of them are focused on Business Solutions,


124

like www.opensourceforum.com, others on Open Source Technology News, like

www.opensourcegroups.com Figure 6, and other on software solutions, like http://java-

source.net. The ultimate goal of open source forums is creating an environment that

encourage free communication between participants.

7. Implementing Open Source Software

Implementing the product is the main objective for any open source developer.

Implementation means:

- executing the open source product for solving a practical need of the user;

- undertaking open source components in own software products for processing data

and obtaining results.

The open source software is implemented without waiting for the final form of

elaboration or testing. Each time somebody implements open source software, the risks are

assumed related to the stage the open source software is.

In the absence of complete testing, implementation assumes all the risks caused by

errors within procedures that lead to:

- incomplete results;

- incorrect results;

- breaks in execution;

- infinite loop cycling;

- automate stochastic behavior.

When the user implements a stabile open source product, from testing perspective, the

risks are controlled, and the quality of results does not exceed the safe range established.

8. Auto-documentation in Open Source Development

Auto-documentation is done gradually by each programmer, by:

- writing own comments;

- including explanations from requirements;

- developing existent comments, by adding significant details regarding the executable

program and the evolution of every variable that has been defined.

If in classical programming, the developers avoid including comments in source texts,

in open source software comments are a clear manifestation of each programmer exigency.

The excess of comments doesn’t harm the source texts as long as they remain consistent

related to the whole product. In case of having fluctuant stiles of programming, the auto-

documentation suffers. There are applications with rich comments, but also applications with

just instructions so that who wants to improve the text, has to:

- decipher the meaning of variables;

- identify what process is implemented in sequences;

- localize the results.

The hermetic way of writing code lines has devastating effects on the programmers

who have different style.


125

9. Conclusions

Developing open source software is a complex process, having scattered phases along

the entire life cycle which take place simultaneously.

Because costs don’t matter, rolling back to previous stages for modifications is

frequent and profound. The expected effect is strictly related to the increase performance.

The entire development cycle is iteratively convergent, the returns improving the

requirements content, architecture structure, coding techniques and auto-documentation which

facilitates ulterior integration in other software applications.

The weight of the phases varies in time, but finally, when the product structure

stabilizes, the ratio between life cycle development stages come close to the one recorded in

classical teams in IT&C companies.

The duration of a complete life cycle development for an open source product is

longer than classical approach, because the planning of activities doesn’t take place,

considering the voluntary participation. In return, the open source product is used

immediately after some base procedures are implemented.

There is always something to do on open source software. Each programmer wants to

contribute in a certain place that he chooses for himself where he:

- adds requirements;

- refines a procedure for better quality;

- runs a test and solicits improvements;

- optimizes the source code of a procedure;

- introduces comments in a program sequence;

- builds a new procedure and adds text to requirements;

- combines two or more procedures to obtain a single one, more complex and more

powerful;

- modifies a source code in order to increase legibility;

- defines classes and transforms classical programming techniques in object-oriented

programming methods;

- replace poor procedures with procedures from other open source components that are

being used with qualitative results.

The analysis of development life cycle follows the open source product evolution and

only the auto-imposed exigencies of the developers determines reaching deadlines and respect

resources while having functional and qualitative outputs. The open source software is

developed in order to solve practical problems, that’s way its structure is clearly stated from

the beginning and all the additional information clarifies it even more.

A minimum level of complexity and a maximum level of generality is the target for all

programmers. The objective is hard to reach.

Open source codes are flexible and, through the way of building, permit processing for

a wide range of problems. If the open source product is a collection of data processing

procedures, the data processing types will be enumerated on a list. The processing is selected

by mouse click or by entering a symbol – letter, number. The programmer who wants to add a

new processing procedure, will continue building the symbols list, will test the character

tasted and will launch the procedure in case of equality. Completions are easy to realize.

Through all phases of development life cycle the spirit imposed by the initiator must be kept.

In case of wanting a qualitative leap, the programmer who assumes it must:

- demonstrate through added components that the technology brings major advantages

for all users;

- convict all other programmers to build open source components only using that

technology;


126

- modify, assisted by a powerful tool, the existing procedures, the translation objective

being to homogenize all existent procedures to the new technology.

Because the future open source software is extremely beneficial for the IT industry, a

complete approach for the open source technologies development must be undertaken. While

in virtual companies the selection of programmers and messages leads to an explicit

collaborative structure, the open source software production characterize the virtual company

with implicit messages that accompanies final products and intermediate stages. The

communication is indirect, through the product: each member of the virtual team, takes the

product as input, executes necessary operations and offer as output a different product.

For a rigorous approach, through all the work that is done, records must be taken to

form datasets which allows computation of indexes that characterize both the development

life cycle and the open source product itself.

References

[1] S. McConnell, Code Comlpete: A practical handbook of software Construction, Microsoft

Press, 2004, 960 pg.

[2] Software Engineering: A Practitioner’s Approach, McGraw Hill Higher Education, 7th

Revised Edition, 2009, 928 pg.

[3] D. Spinellis and G. Gousios, Beautiful Architecture, O’Reilly Media, 2009, 432 pg.

[4] B. Hambling, P. Morgan and A. Samaroo, Software testing: an ISEB foundation, British

Computer Society, 2008, 224 pg.

[5] N. Rozanski and E. Woods, Software Systems Architecture: Working with stakeholders

using viewpoints and perspectives, Addison Wesley, 2005, 576 pg.

[6] IEEE Software, November/December 2009, Vol. 26, Issue 6, 95 pg.

[7] Better Software, November/December 2009, Vol. 11, Issue 7, 45 pg.

[8] http://www.koders.com/csharp/fidE6DDE44CA2DEF14023E6EBB855AB4BFFD777D2

63.aspx?s=calculator#L5

Author

Sorin Lucian PAVEL has graduated the Faculty of Economic Cybernetics,

Statistics and Informatics from the Bucharest Academy of Economic

Studies in 2008. He is currently following Master’s in Software Project

Management and the Doctoral School in Economic Informatics, both at the

Academy of Economic Studies.

Documents

Software Development Life Cycle, Open Source Engineering