Software Development Life Cycle, Open Source Engineering ...


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Development Life Cycle, Open Source Engineering ...

  1. 1. Open Source Science Journal Vol.1, No. 2, 2009 Software Development Life Cycle, Open Source Engineering Component Sorin PAVEL Academy of Economic Studies, Bucharest, Romania 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; 111
  2. 2. Open Source Science Journal Vol.1, No. 2, 2009 - 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 112
  3. 3. Open Source Science Journal Vol.1, No. 2, 2009 - 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 113
  4. 4. Open Source Science Journal Vol.1, No. 2, 2009 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. 114
  5. 5. Open Source Science Journal Vol.1, No. 2, 2009 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. S C1 C2 C3 C4 C5 Fig. 1. Adding text on the same detail level New texts containing model descriptions, C4 and C5, are added to the initial structure. S C1 C2 C3 C21 C22 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; 115
  6. 6. Open Source Science Journal Vol.1, No. 2, 2009 - 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: 116
  7. 7. Open Source Science Journal Vol.1, No. 2, 2009 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; 117
  8. 8. Open Source Science Journal Vol.1, No. 2, 2009 - 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. 118
  9. 9. Open Source Science Journal Vol.1, No. 2, 2009 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] 119
  10. 10. Open Source Science Journal Vol.1, No. 2, 2009 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. 120
  11. 11. Open Source Science Journal Vol.1, No. 2, 2009 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. 121
  12. 12. Open Source Science Journal Vol.1, No. 2, 2009 OST NPC OST C NPC OSD NPD EIR NPR T0 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. EOSP OST NPC1 NPC2 C NPC1 NPC2 OSD NPD1 NPD2 EIR NPR1 NPR2 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 122
  13. 13. Open Source Science Journal Vol.1, No. 2, 2009 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, 123
  14. 14. Open Source Science Journal Vol.1, No. 2, 2009 like, others on Open Source Technology News, like Figure 6, and other on software solutions, like http://java- 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. 124
  15. 15. Open Source Science Journal Vol.1, No. 2, 2009 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; 125
  16. 16. Open Source Science Journal Vol.1, No. 2, 2009 - 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] 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. 126