change management in a team-based distributed software

8
, Change Management in a Team-based Distributed Software Development Environment: A Ca~e Study of BasicSupportsusing WWW Samuel A AJILA (Ph.D.) Department of ComputerScience & JnformationSystems VISTA University, PIE X61 3, Port Elizabeth 6000, SouthAfrica, Tel: +27 0414083295, E-mail: aiila-s(fi)Delican.vista.ac.za Abstract Software development is a distributed activity involving different people in diverse geographical locations. These people have different roles. backgrounds. and tastes. Collaboration and coordination are needed for team-basedsoftware development.Change managementis part of th is coordination. This paperpresents a case study based on an integrated software detvelopment environment (ISDE) that includes changemanagement tools. The distribution of change related information is supported by simple Internet tools. We present architectural issues. the reason for change management. a conceptual view and a conceptual architecture of the ISDE supported by real life application. Keywords: Change management, Distributedteam- based Development, WWW, and Software Evolution. 1.0 Introduction Large softwaredevelopmentis not always confined to a single development group or geographical location. It may involve different research and development teams in dispersed geographical locations. In addition, each team may have preference for a particular development environment and they may have access to different hardware architectures. In caseof any change to the process of softwaredevelopment, the different collaborating teams must be informed of this change and the consequencesthat may arise from it. The changesin Information Technology (IT) will affects the practice of software development especially when the task is carried out in a distributedmanner. The introduction of new, cheap, and fast network technology, and new programming languages such as Java, Telescript, and HTML will bring about radical changes in IT workplace. Sofuo,'are development will becomemore and more distributedwith a wide geographical spread allover the world. Software developers can now work at home or any location they choose to be. With this comes the problem of project management especially the issue of change management. World Wide Web (WWW) technology provides platform for distributed tool services. This is true whether it is an entire Internet or a local within an organization Intranet. The HTTP GET mechanism (HTTP protocol) includes facilities that allow a client to requestinformation from the server. The request can be specific or general. The advantages of WWW include [8]: . Quick access to distributed data and infonnation; Multimedia communication; . . Structured search for infonnation using search engines; and Hardwareindependence and linking of different document types. . The rest of this paperis structured as follows. Section two presents the architectural issues. Section three tries to answer the question "Why Change Management." Section four presents CIT -VISTA- NET concepts, approach, and conceptual architecture and sectionfive gives a conclusion. 2.0 Architectural Issues We have identified four different approaches [2] that address the differences between the collaborating softwaredevelopment teams. ) . The first approachis a situation whereby each team decides to use its own Software DevelopmentEnvironment (SDE) which is not compatible with other SDEs within the project group. In this case, sharing and collaboration between the members of the group will be done outside of the developmentenvironments. A major problem here is data conversion and perhaps lack of commondictionary. 2. A secondapproach is the situation whereby the the sameSDE, but run of the SDE. This is scenario in (I) above teamsdecideto use independent instances closely relatedto the ~

Upload: others

Post on 20-May-2022

3 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Change Management in a Team-based Distributed Software

,

Change Management in a Team-based Distributed Software DevelopmentEnvironment: A Ca~e Study of Basic Supports using WWW

Samuel A AJILA (Ph.D.)Department of Computer Science & Jnformation Systems

VISTA University, PIE X61 3, Port Elizabeth 6000, South Africa,Tel: +27 0414083295, E-mail: aiila-s(fi)Delican.vista.ac.za

Abstract

Software development is a distributed activityinvolving different people in diverse geographicallocations. These people have different roles.backgrounds. and tastes. Collaboration andcoordination are needed for team-based softwaredevelopment. Change management is part of th iscoordination. This paper presents a case study basedon an integrated software detvelopment environment(ISDE) that includes change management tools. Thedistribution of change related information issupported by simple Internet tools. We presentarchitectural issues. the reason for changemanagement. a conceptual view and a conceptualarchitecture of the ISDE supported by real lifeapplication.

Keywords: Change management, Distributed team-based Development, WWW, and SoftwareEvolution.

1.0 Introduction

Large software development is not always confinedto a single development group or geographicallocation. It may involve different research anddevelopment teams in dispersed geographicallocations. In addition, each team may havepreference for a particular development environmentand they may have access to different hardwarearchitectures. In case of any change to the processof software development, the different collaboratingteams must be informed of this change and theconsequences that may arise from it.

The changes in Information Technology (IT) willaffects the practice of software developmentespecially when the task is carried out in adistributed manner. The introduction of new, cheap,and fast network technology, and new programminglanguages such as Java, Telescript, and HTML willbring about radical changes in IT workplace.Sofuo,'are development will become more and moredistributed with a wide geographical spread alloverthe world. Software developers can now work at

home or any location they choose to be. With thiscomes the problem of project management especiallythe issue of change management.

World Wide Web (WWW) technology providesplatform for distributed tool services. This is truewhether it is an entire Internet or a local within anorganization Intranet. The HTTP GET mechanism(HTTP protocol) includes facilities that allow a clientto request information from the server. The requestcan be specific or general. The advantages of WWWinclude [8]:. Quick access to distributed data and

infonnation;Multimedia communication;.

. Structured search for infonnation using searchengines; andHardware independence and linking of differentdocument types.

.

The rest of this paper is structured as follows. Sectiontwo presents the architectural issues. Section threetries to answer the question "Why ChangeManagement." Section four presents CIT - VISTA-NET concepts, approach, and conceptual architectureand section five gives a conclusion.

2.0 Architectural Issues

We have identified four different approaches [2] thataddress the differences between the collaboratingsoftware development teams.

) . The first approach is a situation whereby eachteam decides to use its own SoftwareDevelopment Environment (SDE) which is notcompatible with other SDEs within the projectgroup. In this case, sharing and collaborationbetween the members of the group will be doneoutside of the development environments. Amajor problem here is data conversion andperhaps lack of common dictionary.

2. A second approach is the situation whereby thethe same SDE, but runof the SDE. This isscenario in (I) above

teams decide to useindependent instancesclosely related to the

~

Page 2: Change Management in a Team-based Distributed Software

except that the problem of data conversion isminimized and it is possible to use the samevocabular)' across the board.

3. The third approach is when teams decide toshare the same instance of SDE, whichdistinguishes between teams, but provides foreffective sharing, cooperation, andcollaboration among them. In this case, thegroup must decide who (or which team) willcontrol the performance of the developmentprocess and determine the degree of autonomyprovided for each team.

4. The fourth approach is a situation whereby theSDE is fully distributed, that is, where alldevelopment teams are treated as members ofone large tean1 sharing everything. This issomehow analogous to distributed databasesystems where data is distributed and access ismore or less transparent. This is similar to thethird spectrum above except that there is nocontrol because everything is open and data istransparent to all group members.

In this paper, we are interested in the fourthapproach where the SDE is fully distributed andteam members are treated as belonging to one largeteam sharing everything. However, because ofimportance attached to change related informationand the cost of the consequences of a change, we aregoing to introduce some form of control similar tospectrum three.

3. Wh}' Change Management?

This section is better introduced with an examplebased on a typical scenario. This scenario isflexible. It provides base line information withoutspecifications and policies. The scenario is asfollows:

Seven research teams based in seven differentcampuses - A. B. C, D. E, F, and G. aredeveloping a software project. Parts of thesoftware have already been designed andcodified. Testing and integration is on-goingin three campuses C. D, and G. The projectcoordinator is located in campus A and theSDE central server is also in campus A.

.

The testing and integration team at campus Dreports a problem. The project problem is thenspecified and forwarded to the projectcoordinator at campus A.

A project team member at campus B is assignedto analyze and propose a solution to theproblem. After the analysis, the team memberdiscovers that the problem affects four differentmodules in the software that has been designedand developed at four different campuses. Inaddition, t\vo of the modules have beendelivered as beta versions to r o differentindustry applications. Two separate teams todevelop new applications are currently usingthese tWo modules.

.

The project coordinator finally approves thechange process and the process startsaccordingly. The process entails the following:

.

Assignment of resources,Modification of design documents,Modification code,Handling of impact of change,Analysis and testing,ApprovaVrejection, andIf approved, release of new version to thevarious development teams for integration.

1.

2....J.4.5.6.7.

The change is then finalized..In the absence of good tools and assistance towardchange management, the above scenario is difficult tomanage. In this example, we have only given theglobal view and not the detail fine grain granularityview. The fine grain view will add to the complexityof analysis the management of change.

In general, change management is necessary becauseof software evolution. Software evolution is thechange process that covers the process life cycle ofsoftware. The end result is to satisfy the need of users.as well as the development teams. Softwareevolution may be caused by [1][7]:

Changes in software requirements;Changes in functional specification and design ofthe software;Changes in performance specification (i.e.changes in the specification of the availableresources such as storage, response time, etc.);Historic changes in software implementation(programming language, operating system andsupport provided by other tools such as databaseetc.);Changes betWeen specification andimplementation of the software; andChanges in strategic needs (desire to improveperformance etc.).

.

.

.

.

.

.~l'

fiqq

Page 3: Change Management in a Team-based Distributed Software

Specifically, the software development processevolution could be influenced by [4][6]:

. Historical experience obtained in the use of thesoftware development process;

. Introduction of new ideas or tools into the

SDE;Changes in management of process enactment;.

.

.The software process context; andThe process of development itself.

The general factors are basically internal to thesoftware development process while some of thespecific factors are external to the software process.

CIT -VISTA-NET:4.Approach, and Architecture

CIT - VISTA-NET is; an integrated softwaredevelopment environment based on World WideWeb. The basic idea is to have an integrated SDEthat includes change management tools as part theactive processes.

CIT-VISTA-NET was born out of a need. VistaUniversity is a multi campus institution with sevencontact campuses and one distance educationcampus. Incidentally, each campus has a sub-department of Computer Science and InformationSystems. As a department, we teach the samecourses, carry out projects together, and have onlyone head of department situated at one of thecampuses. Often we need to meet to discussprojects, student matters, and general administrativeproblems. Apart from the cost, it is ofteninconvenient to physically fly to all the campusesand it affects both teaching and research output ofthe department. It is even worst with softwareproject development. The number of qualified andresearch oriented academic staff in each campus arerelatively few and we need to put our resourcestogether in order to produce quality results.Therefore CIT-VISTA-NET is part of a biggerproject that will enhance linkage of the subdepartments together for better teaching andresearch. In order to satisfy part of these needs, wethen propose an integrated software developmentenvironment (ISDE) that supports the changemanagement process.

The Integrated Software Development Environmentconsists of:

Process Manager: - The process manager setsgoals and regu lates production process through

.

the team manager- and the task builder. Itreceives standards from the environment anduses them to control and administer theproduction process and its output. Thesestandards are predefined basic elements. Theyinclude activity. role. and resource. Activity isan atomic or composite operation. This is aimedat generating or modifying a given set ofcomponents. Activity implements rules andprocedures. Activity has inputs, intermediateresults, and outputs. A resource is an assetneeded by an activity for it to be carried out. Theresource can be a performer or tool. Theperformer is a human agent. In our case, wehave team manager and task builder. The Teammanager provides information on theperformance of the production process allowingthe process manager to determine ~'hether goalsare being realized or if corrective action isrequired. A role is an entity that identifies theskill needed by the performer in order to carryout its duty.

Concepts,

Software production process and tool:Software production process consists ofdesigners, programmers, reviewers, and a testingteam. Software development tool is an entity,that is, a piece of software. It can be employed incarrying out an activity. Tools are characterizedby the operations they implement, their cost, andtheir availability. In our case, the softwaredevelopment tools include editors, compilers,workbench, design methods, specificationmethods, browser, pager, debugger, and mailsoftware.

.

Product: - The set of artifacts to be developed,delivered and maintained in a project is calledproduct. Product has sub products and it iscomposed of life cycle objects such asrequirement. specification, design, code, test andintegration. This is in agreement with the designof the change management tool. Figure 3.1indicates that the product receives input from andgives output to the environment. It uses thesoftware development tools and the processmanager controls it.

.

. Change Management Tool: The change

management tool is based on a model called"What-If" What-If evaluates a priori the impactof object change in a software system. Themodel is generic and it covers the entire lifecycle process. It is based on a "mixed softwareviews" approach. In this approach, we are able toexplain object change in terms of the life cycle

-6~

Page 4: Change Management in a Team-based Distributed Software

view, combination of life cycle sub views, andthe domain specific view. The domain specificview allo"'s the specification of fine grainobjeCts and the life 'cycle view (eventually sublife cycle view) allows the specification of

medium and ~ig size granularities. Oneimportant thing about What-If is that it is apriori, which means that one can explain theconsequences of change, before it is even carriedout. This is particularly useful in

691

Page 5: Change Management in a Team-based Distributed Software

distributed team-based development becausethe consequences of a change can be very costlyand dangerous. Using the a priori option, onecan decide not to carry out the change if it willbe too costly to implement or re-design thechange process entirely.

. The Project base: The project base consists ofall the entities involved in the development ofthe software. It contains a database of all theobjects, a fact base of all the dependencyrelations and a knowledge base containing pre-defined indirect relations, integrity constraints,and historical factors [3). In the project base allthe objects have uniform representation in orderto facilitate their interpretation and evolution.They are also persistent because at creationeach object receives a unique internalidentification.

I

The interpretation associated with the ISDE acts as acontroller and gives assistance when it is required.Its principal actions are the following:

1. Activate the necessary operations based on theteam manager directives;

2. Verify the constraints attached to the executionprocess; and

CIT-VISTA-NET Conceptual Architecture.

3. Give assistance to the developer by checkingthe impact of the change and record thehistory of change information for future use.

With this. the team manager (\\1th the approval ofthe process manager) can distribute the changeinformation to all the teams using e-mail andplace it on the WWW.

The conc~ptual architecture (figure 3.2) describesth~ interaction betWeen the s).'stem components.The product repository stocks all the informationrelated to software development - design tool,soft\lt'are artifacts, documentation, etc. The factand rule base holds the dependency r~lationsbetWeen software objects, indirect relations, andintegrity constraints attached to the enactment andcontro! of the production process. A relation(direct or indirect) is a bi-directional associationbetWeen tWo software objects [3]. The databasecontains infonnation on the attributes associatedwith an object. An attribute is characterized by - aname, a type, and an initial value, The changemanagement tool creates the objects, the directrelations, calculates the indirect relations, andgives answers to queries. Standard queries havebeen developed and the user is allowed to createother queries through the user interface.

692

Page 6: Change Management in a Team-based Distributed Software

Vista University netWorks infrastructure span eightsites, around the country with high capacity bond. AnetWork is present with slower v.' AN linksinterconnecting the various sites. The CIT - VIST A-NET is located at the Port Elizabeth campus, whichalso manages the Computer Science andInformation Systems Intranet.

5.0 Conclusion

S. A. Ajila. 'Dealing with Impact Analysisof Objects Change in a Distributed Team-Based Software Development: BasicConcepts and Perspectives', In Processsupport for Distributed Team-basedSoftware Development (PDTSD'99) incollaboration with 3rd WorldMulticonference SCI'99 &:. ISAS'99, Vol.2, 531 - 536, July 31 - August 4, 1999,Orlando. Florida. USA.

[3] S. A. Ajila, 'Specification of DependencyRelations in Software ChangeManagement', To appear In Proceedingsof Software Development Theor)', Practiceand Experience - Issues and Challenges for [8]the 21- Century, University of Botswana incollaboration with UNU- InternationalInstitute for Software Technology,Gaborone, Botswana. . [9]

[4] J. C. Derniame, A. Kaba and D. Waste I I(Ed.). 'Software Process: Principles,Methodology and Technology', LectureNotes in Computer Science No. 1500,Springer, 1999.

ISDE based on WWW that can give assistanceand perfonn change management at least, givesindication as to the consequences of a change. Inour case, the impact analysis is done iz priori andthis is advantageous in the sense that the cost ofthe change could be calculated before it is carriedout. In addition, we have based our design onsimple Internet tools such as WWW and e-mailbecause WWW technology provides platform fordistributed tool services and it is independent ofhardware. Our next move is to investigate thepossibility of porting our system on SAP/R3systems and possibly used ORACLE as adatabase engine.

H. Yee Teh, S. Jarzabek and P. F. Tiako,'WWW-based Communication Tool forDistributed Team-based SoftwareDevelopment', In Process support forDistributed Team-based SoftwareDevelopment (PDTSD'99) incollaboration with 3M WorldMulticonference SCI'99 & ISAS'99,Vol. 2, 585 - 590, July 31 - August 4,1999, Orlando, Florida, USA.

[5)

[6] A Kaba, 'Des m~canismes pourI'evolution des proceede dedeveloppment de logiciels. Ph.D. thesis,Departement de formation Doctrale enInformatic, Centre de Recherche enInformatic de Nancy (CRIN-CNRS nowLORIA-CNRS), Institut NationalPolyrechnique de Lorraine, Nancy,France, July 1996.

[7] M. M. Lehman and L. A. Belady,'Program evolution: Process of softwarechange. APIC Studies in DataProcessing No 27, 1985, AcademicPress.

B. Scholz-Reiter and E. Stickel (Ed.),'Business Process Modelling', Springer,July 1996.

P. F. Tiako. 'Modeling the Federation ofProcess Sensitive EngineeringEnvironments: Basic Concepts andPerspectives", In Gruhn, Y., Editor,Proceeding of Software ProcessTechnology - EWSPT'98, LNCS vol.Technology - EWSPT'98, LNCS vol.1487, Springer-Verlag. September 1998.

Page 7: Change Management in a Team-based Distributed Software

(IS] Do Heimbinger. Exr.;ri.:n.:.:... \\ilh nn Oh.i~cl Mnnn~.:r lor:I Prl)c.:~ Centred Environment. In Prl)C. 01" the 18th Vl.DBConlcr~nce. Vancou\o.:r. CD,,". 1992.

(16] B. Krishnamunhy ilnd N.S. Bilrghouli. Provence;' AProcC:$s ViSUilliSiltion and Enilctmcnl En\1ronmc:nt. InProccedings of thc founh Europcan Sott\\arl: Engincl:ringConti:rcncc. Garmisch-Pilrtcnkirchcn. GcnTlany. Springcr-V.:rlag. Scp 1993. pp. 451-465.

[Ii] P.J. Kammer: G. A. Bolcer. M. Bergman. RequirementsFor Supponing Dynamic and Adaptive Workflo\\" on theW\VW. CSCW.98 Workshop on Adaptiv~ Workflow Syst~ms.

\Volt: "Foundations For th~ Study ofIn Proc. Of Ih~ ACM

Soft\\'ar~ Engin~cring NolC:s.

[18] D.E Perry. and A.L.Soft\\'are Architecture".SIGPLAN/SIGSOFT.I i(4):40S2. Oct 1992.

[19J D. Tombros and A. Geppert. "A Survey of DatabaseSupport for Process-Centred Son"'are Dc:velopmentEnvironments", T~chnical Rc:port 95,28, Institut fur Intormatik.Universitat Zurich.

[20) L.J. Oster\veil. "Soft\varc: Pro(jessc:s are Soft\\"are Too". InProc. of th.: 2nd Inti Conf. On the Software Process. B.:rlin.Germany. IEEE Press.

[21] Workflo\\" Management Coalition. "Interrace I : ProcessDefinition Interchange Process Modc:I". Doc. WFMC TC-1016-P. Rc:lease 7.04. Novc:mber 12. 1998.hlll'::;\\\\ \\". \\"linC:.llrl!

694

Page 8: Change Management in a Team-based Distributed Software

World Multico"nference5 ystB- ni[~ :5

, ' ,\1

~. ,".

~

onCy.

and ticsInfornla .,~ ..'1.

..

...,I"I

01

...,.,

.='

2000