University-Based Software Development Methodologies*
##AUTHORSPLIT##<--->
Universities are not only centers of imparting education but also participate actively in research and development (R and D). These dual roles of universities, especially R and D, have immense impact in the development, expansion and dissemination of technology. From the inception of computers [1] to the expansion of internet [2], universities with their indomitable student power mentored by their faculty are always in the forefront of innovation and refinement of processes. In the current scenario where countries are striving hard for poverty eradication, universities should not confine themselves for exploring new technology and maintaining teaching excellence. They should promote entrepreneurship so that community businesses flourish. The focal point of this paper is to demonstrate how universities can incorporate software development activities within their academic stream through continuous refinement, collaboration and controlled outsourcing. However one of the models of this research also supports the idea of fostering newly born software development companies. The rationale of this model is derived from the success of software incubators in many countries. I have projected this notion by emphasizing the need of setting up of a ‘Virtual Software Mall’ of group of inter linked web based companies operating within the domain of universities web services. In short, this paper presents three models of university based software development, namely: Stepwise Project Refinement (SPR), Distributed Project Development (DPD), and Virtual Software Mall (VSM).
Introduction
Software development is an ever-changing process involving individuals and groups. New ways and techniques are constantly being evolved to reduce the complexities of design phase and to speed up the task of overall development process. The two commonly used software design techniques are top-down and bottom up approaches. Dijkstra [3] has shown how we can design software by breaking down a large problem into smaller problems. Each smaller problem is a functional abstraction which can then be defined using a method called step-wise refinement [4]. It has been found that step-wise refinement is a very good technique for teaching computer programming to novice users [5]. Moreover, it can also be used to transform trivial student projects into a well organized software product. A related work on this approach is done by [10] without emphasizing the importance of professional evaluation for overhauling and error correction after each refinement. They have done refinement mainly in the context of open education while I have borrowed their modus operandi into SPR model and showed how it can refine countless small student projects (developed in a university/academic environment) to produce a commercially viable product. Another implementation of refinement leads to automatic development by augmenting feature modules to the application in the incremental fashion [21]. However in a university environment where focus is on trial and error [22] and students are supposed to develop insight and learn the underlying technology, a stepwise refinement technique based upon product evaluation is more demanding. This way, students will learn how to catch and remove bugs and the steps of software development life cycle (SDLC) with special reference to the maintenance phase. The project evaluation is done through outsourcing and this brings professional expertise in these class room projects.
Normally in computing courses a teacher divides the students into small groups and then students develop projects using “intergroup” and “interagroup” collaborations. Collaborations act as an invigorating agent in problem solving. [6] has highlighted the concept of pair programming which is basically a ‘collaboration in small’. Another form of collaboration ‘open collaboration’ is one in which we open the doors of collaboration for everybody. This type of model is being practiced by open source development organizations through projects like Linux, GNU [9] etc. It broadens the spectrum of collaboration so that anybody at anytime can enter into software development process. The Open Source development model (OSSDM) invites plethora of software development expertise and can be exploited by universities to complete their projects and overcome their technical deficiencies if any. However due to enormity of research work done in the areas of SPR, DPD, and software incubators, I have not included OSSDM in my current research and left it for future study and exploration.
A variation of OSSDM is possible when a university coordinates with some other universities/organizations in the development and validation of small project units. This can be termed as ‘restricted collaboration’; i.e., we are restricting the number of organizations who can participate in the development process. [8] has shown how students in a US university collaborated with the students of a Swedish university. Tools of email and IRC are utilized to exchange ideas and code. Collaborations can also invite conflicts. Some of these conflicts can be healthy and can improve the final product. Collaboration can also be used to handle the development constraints in addition to accelerating the pace of work [7]. In this context we can view the restricted collaboration as a collaboration among different software development units which are monitored by global and local coordinators. A global coordinator (GC) is used to oversee and coordinate the overall development process while local coordinators monitor the each individual development group/organization. One important work done by GC is to decompose the main task into subtasks. It then distributes these subtasks to other organizations. These organizations develop and validate the task separately and then send them back to the global coordinator which integrates them into a unified product. However in the DPD model for UBSD, I recommend that once a project is up and running, its better that a university should ‘hand off’ the project by outsourcing the maintenance phase to some other contractor preferably the distributed development partner. Thus in DPD model as against the SPR model, outsourcing is enforced as a result of dependency factor and with an objective of developing high quality software products with reduced or almost negligible in house development. In other words in DPD, outsourcing is not meant to gain superiority over competitors, however the consequence can be to enhance the pace of development. [17] has discussed the perils of outsourcing and quoted an example of improper coding by the outsourced company during the hype of y2k bug removal.
3553-6857
Thus a model for outsourcing can be formulated based upon the following two approaches mentioned in the surveyed literature. One is the less authoritative partnership based model [18] in which the outsourced company merges with the client as stakeholders in the project. The other one is the conventional, less flexible contract based model [19] in which both the vendor and the vendee have to fulfill the obligations of the contract for the success of outsourced project. I have preferred a combination of the two: a controlled partnership based outsourcing mechanism. This can be accomplished by improving client satisfaction and building client’s trust [20] on third party developments by automated distribution of binaries at the client site on scheduled dates for evaluation, testing and integration. Thus the client feedback will proscribe the incremental buildup of the software project. The techniques of distributed software development are gaining momentum as the concepts of distributed software engineering are being streamlined. The idea is widely applied in the automobile industry where different components of automobile are built at different places and then merge together as a cohesive unit. This practice is followed in software development also typically in a distributed software development paradigm to facilitate concurrent development of software units. This emphasizes the need of proper decomposition technique. One such technique is discussed in [23] which partitions the software application into a set of activities. I have extended this idea by associating activities with a user interface (UI) as in a event driven programming. Initially a core application is developed as a combination of UI elements and activities represented by deferred event handlers. An activity can have subactivities encased within it; thus, forming an activity module which can be outsourced for concurrent development. As the activity development and validation process completes, activity modules are integrated into the core application.
Toward the end of last millennium, Sir Syed University (http://www.ssuet.edu.pk) located in Karachi, Pakistan, added another dimension towards their field of activities. Coupled with the demand of increasing economic desirability by faculty and boosting industrial liaison for improving students’ skills, they launched the project of ‘software incubators’. Undergraduate students’ final year projects were used as seeds to the incubator. The incubator project was directly associated with the university’s Computer Engineering department and thus lacked professional supervision. Though it was a bold attempt of industrial liaison, the project was not able to make any dent in the local market and no other Pakistani university followed on their footsteps to set up ‘software incubators’. Later they transformed themselves into technology nourishment centers (http://www.stipk.com). However there are many success stories about the software incubators on the web. University at Stony Brook has provided a set of guidelines and rules for renting campus facilities and services to a potential new business entrant. Services aim at providing proper guidance to overcome technical, financial and administrative barriers. Fund raising is achieved by developing attractive business plans to win donor agencies support and confidence. In this regard university must identify software projects from local market which can generate quick monetary returns to the new companies growing under universities shed. Student surveys can provide quick glance of market needs and prospects.
Why Universities Pursue Software Development?
Universities belong to a unique class of institutions which perform both research and development. On the other hand, the trait of software houses is just the development. No doubt they adopt and promote processes and tools generated by expensive university research. There are many reasons why the universities do not involve in software development:
i) Software development is a full time job where a team of experts mutually interact to undertake the challenge
ii) Software development is marred by delays, bugs, and above all the end product is too costly to meet the customer’s budget
The cost factor is so embarrassing that organizations buy the computer hardware but do not go for automating their processes with a customized software. Instead they use end user computing tools to abridge the shortcomings of specialized products.
Let us see the advantages of launching university based software houses:
i) availability of cheap but well tested software products
ii) availability of highly skilled graduates trained in a professional environment to meet up the challenges of growing software industry
iii) quick delivery of research benefits to the market place
iv) increased sources of income for university, faculty and students’
If we go through the historical survey, we will find that most of the innovations are the results of university research and development. Eniac [15], Mark1 [1], BSD Operating System, Kerberos [11], standardization of Internet Protocols again in [11] are just few names from a grand list of projects which are the gifts of university research and development. With reduced endowments and funding for R and D projects, universities must come up with new ventures to deal with this financial crunch. Endeavors like software development centers can open new avenues of fund generation for the universities.
University Project Development Methodologies
The strategies of university software development are different from the software development carried out at the software houses. Academic environment and tight faculty schedule tend to impose restrictions on this activity. Lack of professional expertise can thwart development of any commercialized software product even in its infancy stages. Conversely universities are home for high end machines equipped with software design, development, monitoring, testing and debugging tools. Normally all most all the labs in any university in any part of the world is now internet enabled and is derived by DNS, web, internet, or database servers. Email, chatting and Net meeting tools are commonly used by students for fun or for enhancing their intellectual ideas. Proper utilization of university students for software coding and testing can boost very encouraging results. Thus the heart of problem lies in mirroring the activities of computer science faculty and students with the activities of developers of software houses and undermining the drawbacks of professional software development skills attributed to faculty and students with open and restricted collaboration and outsourcing. Currently, there are large number of universities engaged in software development activities. They have provided web sites containing information about their activities.
Stepwise Project Refinement
In a university environment projects are assigned to the students for a semester period. Albeit, students develop projects during this period, but it’s very difficult to develop a sophisticated product in such a short time span. The project may contain numerous bugs and incomplete functionalities and it may not be feasible for commercialization. This coarse version of product can however be improved if we identify its shortcomings and then hand it over to a new group of students for further refinement and advancement. Thus giving rise to a methodology called stepwise project refinement (SPR). The SPR synthesizes the project in a stepwise fashion, semester by semester, and eventually evolving a correct and comprehensive software. After each refinement, the project underg'es a evaluation phase whereby its bugs and drawbacks are identified.
The refinement process continues until all the bugs B and Drawbacks D are removed and the project reaches a fixed point state where the refinement process returns the original project without any modifications. If X is the software and R represents the refinement process then,
X=R(X)
Also referred as fixed point theorem [16]. The main phases of SPR are as follows:
i) Development: which identifies the phase in which a ‘base product’ is developed from scratch. The base product is the starting point for the refinement process. Based upon the modules or components of base product and student skills, different levels of refinements can be achieved, each adding more complexity to the base product.
ii) Evaluation: which analyzes the base product and identifies its bugs and the various components that were not delivered in the Development phase. We emphasize that the evaluation phase must be outsourced for critical analysis of the project to determine its commercial viability and lack of professional elegance. Thus taking care of Quality assurance along with the identification of bugs in the ‘base product’ and its future product line.
iii) Refinement: which involves the implementation of undelivered components and subsequent testing to phase out the bugs identified in step 2.
SPR is a recursive process represented by R. It has a base case and a general case. The general case has a recursive call for the next iteration of the refinement process while the base case provides the termination condition to stop the refinement process. The base case occurs when the sum of both bugs B and drawbacks D are minimized to zero. Initially the base product, P, is evaluated to identify its weaknesses. It’s then refined and new modules, h are added to the base product to redress its weaknesses. The newly refined product (P+ h ) is then again evaluated to find new bugs and drawbacks. This process is repeated again and again and it represents the general case of SPR.
This can be stated mathematically as:
R(P, h , B, D) = h + (B+D) * R(P+ h , h , B- D B, D – D D)
where D B and D D represent the removed bugs and drawbacks from R respectively.
One important aspect of any software development endeavor is to maintain the project documentation for maintenance and for future understanding of the project. The documentation in SPR should not only suffice the above goal but it’s a good idea if our documentation can help us in tracking the stepwise development of the project. This way students’ would be able to see the previous drawbacks and bugs and counter solutions to expunge them from the code. The tree data structure can be used in this regard as proposed in [24] and this technique can be termed as ‘refinement tree’ [13]. The refinement tree would have different levels as shown in Figure 1 below.
Figure 1: Refinement Tree
At each level, except the root, it has two nodes: evaluation node and the refinement node. Evaluation node’s descendants would explicitly describe the program errors and deficiencies while the children of refinement node describe the corrective measures taken during the refinement process. The evaluation node for the next level also branches out as the child of the refinement node. This process continues until the drawbacks and bugs leave perish and with no more refinement needed. In short, refinement tree shows different maturity levels for the SPR model using a stair structure. As we progress from top stair to the stair below it or in other words from level 0 to level 1, the application grows and finally at the last stair level represented by N, the application attains the most advanced version.
Another technique for program understanding, Program Activity Diagram (PAD) can be derived from flow charts as discussed in [14]. Instead of showing the entire program activity, the program flow can be modeled diagrammatically in terms of object instances and method invocation. It’s not out of place to mention about the UML approach which is mainly used for object representation. However it’s primarily useful in the design phase whereas PAD can be used for debugging and understanding the software in the maintenance phase. Thus PAD can be very useful in viewing the temporal changes occurring in the project as a result of refinements. Fig.2a shows the symbols required for representing a software using PAD. Fig.2b uses these symbols for representing a library software. The main ( ) invokes make_menu( ) which creates three objects (studentRecord::sR, employeeRecord::eR, bookRecord::bR). We have only shown the actions of sR which continues in Fig.2c. sR invokes four methods: addStudent ( ), deleteStudent ( ), display ()
Fig. 2a, PAD Legends
Fig. 2b, PAD for a library software (Part I)
edit_student ( ) and Student ( ). The working of the above mentioned four functions is given below:
addStudent ( ): Inputs ID, Name, Program, Semester and Section for a student and then initialize the student object created in this method by calling its “mutator” functions.
display ( ): Inputs a student ID. Creates a student object. Retrieves its attributes by calling “accessor” functions and then displays them.
edit_Student ( ) : Inputs the student attributes viz ID, Name, Programming Semester and alter its fields by the newly inputted attributes through the mutator functions.
DeleteAstudent ( ): will delete a particular student from the database.
Fig. 2c, PAD for a library software (Part II)
Distributed Project Development (DPD)
The advancements in computer network has brought the possibility of developing software modules at different locations and merging these modules to produce the final product. One of the premise of this technique is to triumph over the scarcity of in-house development skills and talent which can be a potential problem in a university environment too. The above mentioned deficiency can pose a serious problem for adopting software development as a business activity in a university environment. The answer to this drawback is to form a consortium of well judged companies and concurrently develop software by outsourcing its components to these companies. Thus laying the foundation of DPD. The fundamental principles which derive DPD are collaboration, coordination and communication among the companies in the consortium. For simplicity, let us term the above three characteristics as 3Cs.
In this model, though tasks are distributed, there is a need for centralize control to monitor and startup the activities. The centralize control is achieved by designating a GC as discussed earlier. GC is responsible for task decomposition, distribution and integration. The six steps for DPD are listed below:
i) Decomposition: In this step, the software is broken down into small activities. The activities can be mutually interlinked, one leading to the next one, or can be activated separately.
ii) Distribution: An activity interdependence diagram is developed to find out linkages between various activities as shown in the Fig.3. It’s better to distribute interlinked activities to the same contractor.
Fig3. Activity Interdependence Diagram
A related task in this regard is to create ‘Pathway Expressions’. The possible pathway expressions for Fig.3 are:
A1[A4[A7]]]---------------(1)
A2[A6[A8]]]---------------(2)
A3[A5[A9[A7,A8]]]]----(3)
The pathway expressions can help us in:
a) proper task distribution
b) prioritization of activities during implementation
c) locating activity interdependence
For example, GC can use expression (1) for assigning activity modules A4 & A7 to a outsourced company. Activity modules A7 and A8 can have the highest priority. From (3), it’s clear that A7 and A8 are encased within A9 and are pre-requisites for complete functionality of A9.
iii) Synthesization: In this step each contractor develops its own portion of activity module and compiles it to produce an error free object module.
iv) Serialization: Object module along with the source code is then stored in a shared repository .
v) Integration: This involves linking of stored object modules to generate an executable file. The binary thus formed is then stored on the customer site.
vi) Feedback: Customer runs the executable and then sends its comments to the GC which passes it on to the concerned contractor. In this way, users are acting as co-developers and in the light of their comments software development progresses effectively and surely.
Along with 3Cs, the other important aspect of DSD is management and control. Lack of proper guidance and supervision can have adverse effects on DPD. A problem system for DPD is discussed in detail in [25]. At Bahria university, my students are working on a project to develop an application to facilitate DPD. The main interface of application known as DSDSoft is shown in Fig.4a and Fig.4b
Fig. 4a, Interface of DSDSoft Application showing PAD
Fig. 4b, Interface of DSDSoft Application showing code
It provides the functionality for compiling and building the executable. This is done in response to altering the contents of shared repository. An email is sent to GC. GC can then rebuild the application and in due course the newly created binary is stored on customer site. Individual users can log into the system and can involve in discussions among themselves or with the GC. Currently logged in users can be viewed using the login window. The application also gives provision to the global coordinator to view the source code and PAD of the remote developing team at any instance for the sake of determining group progress. This is achieved by traversing the particular link from the projects tree window and choosing between coding and PAD. The selected stuff can then be visible in the project coding window which act as a white board. Thus allowing GC to highlight any section of code, underline any statement or write comment on this white board for the purpose of clarity and discussion and it becomes visible on client applications of all distributed development partners who are currently logged in.
Virtual Software Mall (VSM)
VSM is a group of interrelated web based companies engaged in software development and its associated businesses. The objective is to establish a virtual community promoting a common cause of software development through mutual help and connivance. Due to frequent ups and downs in political and economic conditions, the software industry in general has suffered a tremendous pressure and new entrants in particular have encountered many vexing problems. To overcome this situation why not we design a model for proper guidance and technological support of the new entrants through universities IT infrastructure and its teaching staff. This back up and lending of expensive equipment will not only remove the gloomy picture for new entrants but also show new avenues for existing companies for salvaging their declining software businesses.
VSM is based upon the idea of software incubators which we have already discussed in the introductory section. Like the software incubators, the lifeblood of VSM is also the small and medium sized businesses operating in conjunction with universities’ IT department. Its distinguishing characteristic is the interdependency of product among the companies in the Mall such that the product of one company acts as the raw material for the other. Secondly there exists an intention among the sister companies of Mall to achieve prosperity for the entire business community of the Mall through mutual cooperation and problem solving. The above characteristics can be exploited for gluing the companies in the Mall together on a single website. Thus forming a VSM.
Preferably non redundant businesses with strong inter-product bondages in different areas of software development like feasibility study, designing, coding, testing, maintenance, marketing, quality control, packaging and distribution can be ideal to be launched through VSM. Non redundancy will make sure that companies do not succumb to internal competition. Slowly and gradually, the companies can grow by selling or rendering services to each other or merge together to form a larger concern. Thus, instead of growing sprawlingly, VSM companies would grow by concentrating on a niche.
Conclusion
Three models for software development in a university environment are discussed. Two of the models namely: Stepwise Project Refinement and Distributed Project Development have been experimented using a group of students and found to be very useful in creating enthusiasm among students for software development. The third model viz Virtual Software Mall is a by product of software incubators and is currently being evaluated at Bahria University for successful launching.
Acknowledgment
I want to thank all my students who participated in the project of SPR and DPD. Without their interest, I wouldn’t be able to explore the above mentioned techniques. In addition to this, I want to thank my ex-colleague, Mr. Sabir Ali for providing me access to his research account and for reviewing the first draft of my paper respectively.
References
[1] S.H. Lavington, “The Manchester Mark I & Atlas: A Historical Perspective”, Communication of ACM, Jan, 1978, Vol.21, Number1.
[2] Harley Hahn, Rick Stout,”The Internet Complete Reference”, Osborne McGraw Hill, (c) 1994
[3] U. Eindhoven, “Notes on Structured Programming”, EWD 249, Technical The Netherlands, 1969.
[4] David Gries, “What should we teach in an introductory programming course?”, SIGCSE Bulletin 6,1, (Feb, 1974) pp.81-89.
[5] R.R. Oldeh'eft, R.V.Roman, “Methodology For Teaching Introductory Computer Science”, pp.123-128.
[6] M.A.Domino, R.W.Collins, A.R.Hevner, C.F.Cohen, “Conflict in Collaborative Software Development”, SIGMIS Conference, 03, April 10-12, 2003, pp 44-51.
[7] “Accelerating Software Development Through Collaboration”, ICSE’02, May 19-25,2002,Orlando, Florida, USA, pp.559-563.
[8] “Learning from Students: Continuous Improvement in International Collaboration”,ITICSE’02, Jun 24-26, 2002 Aahus, Denmark, pp.136-140.
[9] Richard Stallman, “The GNU Project”, copyright(c) 1998,2001,
[10] B.D.Faber, “Educational Models and Open Source: Resisting the Proprietary University”, SIGDOC’02, Oct 20-23, 2002, ACM, pp.31-38
[11] W.Richard Stevens,”Unix Network Programming”, (c) 1990 by Prentice Hall Inc.
[12]J.W.E Greene, Measures For Excellence Managing Major Distributed Software Development”,Copyright Quantitative Software Management Ltd”, www.qsm.com.
[13] R'el Wieringa,”Traceability & Modularity in Software Design”, Dept. of Computer Science, University of Twente, P.O.Box 217, 7500, AE Enschede, the Netherlands
[14] Richard O. Parker,”Easy Object Programming for Windows Using Visual C++” (c) 1995 by Prentice Hall
[15] Saul Rosen “Electronic Computers: A Historical Survey”, Computing Surveys Vol. 1, No.1, Mar 1969, pp.7-36
[16] http://interzone.com/~cleving/Page.dirpg.math2.html
[17] Lauren Weinstein, “Outsourced and Out of Control”, Feb 2004, Vol. 47, No.2, Communications of ACM, p-120
[18] “IT OutSourcing Evolution-Past, Present and Future”, May 2003, Vol. 46, No.5, Communications of the ACM, pp. 84-89
[19] Thomas Kern, “The Gestalt of an Information Technology OutSourcing Relationship: an Exploratory Analysis”,
[20] Rajiv Sabherwal, “The Role of Trust In OutSourced IS Development Projects”, Feb 1999, Vol. 42, No.2, Communications of ACM, pp. 80-87
[21] D. Batory, J.N. Sarvala, “Scaling Step-wise Refinement”, Int. Conference on Software Engineering, May 2003, Portland, Oregon.
[22] “Software Development: What it is, What it should be, and How to get There”, ACM SIGSOFT, Software Engineering Notes, Vol. 28, No.2, Mar 2003, pp. 1-4,
[23] Takuaya Katayanema, “A Hierarchical and Functional Approach to Software Process Description”, ACM, 0-89791-314-0/88/0005/0087.
[24] Niklous Wirth, “Program Development by Stepwise Refinement”, Communications of the ACM, Vol. 14, No. 4, April 1971, pp. 221-227
[25] htttp://sern.ucalgary.ca/~maurer/ICSE98WS/
Submissions/Kudo/kudo_PMS.html
About the Author
Zulfiqar A. Khan received his B.E. in computer systems from N.E.D. university, karachi, Pakistan, in 1991 and an M.S. in computer science from Wayne State University in Detroit in 1997. Khan’s major fields of interest are software development, algorithms, as well as distributed and client/server computing. He has worked as a programmer/analyst for Ford Motor Co. and UMI. For the last seven years, he has been working as a faculty member in different Pakistani universities. He is currently associated with Bahria University, karachi campus, as a permanent faculty member.
E-mail: [email protected]
Bahria University (
http://www.bimcs.edu.pk)
* Editor’s Note: This article has not been edited to meet T.H.E. Journal’s style or standards.
This article originally appeared in the 01/01/2005 issue of THE Journal.