WIXLIB

International Journal of Computer and Information Technology (ISSN: 2279 – 0764)Volume 03 – Issue 06, November 2014Lessons Learned in Academic Hybrid SoftwareDevelopment Projects – A RetrospectiveRobert F. Roggio*, Dalila CastillaSchool of ComputingUniversity of North FloridaJacksonville, FL USA 32224*Email: broggio {at} unf.eduAbstract— According to some researchers, a hybrid approach canhelp to optimize the software development lifecycle by combiningtwo or more methodologies. The Rational Unified Process (RUP)and Scrum are two methodologies that successfully complementeach other to improve the software development process.However, the literature has shown only few case studies onexactly how organizations are successfully applying this hybridmethodology and the benefits and issues found during theprocess. To help fill this literature gap and to provide a majordevelopment project for a five-person team of first year softwareengineering graduate students at The University of NorthFlorida, the Lobbyist Registration and Tracking System for theCity of Jacksonville (COJ), FL was designed and implementedusing a hybrid approach that integrated RUP and Scrum withinIBM's Collaborative Lifecycle Management (CLM) solution.While it is safe to generalize and assert that it is typical forsoftware development projects to encounter challenges both inthe corporate community as well as in academe, the hybriddevelopment approach using RUP, Scrum, and CLM in anacademic setting presented some unique issues. The purpose ofthis paper is thus to convey the distinctive issues arising from thehybrid approach in an academic setting to provide empiricalevidence of these problems with suggestions as to how they mightbe avoided. The details of the year-long development project arereported in thesis nt;academe’;THE PROBLEMSA. Team Composition and Work SchedulesThe two-semester graduate-level project was undertaken atThe University of North Florida (UNF) as part of the softwareengineering track within the Master of Science in Computerand Information Sciences degree program. The class hadapproximately 18 first-semester students, who were dividedinto three teams of six students. Team 1 developed thelobbyist tracking system. (No special significance wasassigned to team numbers and no one had a problem withbeing called Team 2 or Team 3.)www.ijcit.comTeam 1 consisted of five individuals (one dropped withinthe first week of class). Of the five, two were wellexperienced developers who worked in UNF ITS (InformationTechnology Services), which handles academic andadministrative computing university-wide. Although new tothe graduate program, their skills were quite good and theyhad software development experience within the framework ofthe systems that the university develops and maintains. Theother three individuals were similarly new to a graduate levelprogram, but had no experience in practical softwaredevelopment other than coursework. They also had noexperience in the core technologies selected to develop thesystem.Because of the rigidity of semester scheduling and theneed to develop software quickly and on time, there was littletime for these students to learn classroom best practices ofsoftware engineering while concurrently learning developmentenvironments, complex tools, experience very diverse teamdynamics, and merge all these characteristics into a cogentsuccessful development team environment. Regardless, theytook their roles and supported other projects’ activitiesrequired in order to deliver an application that met the client’sexpectations and requirements.As it turned out, the team worked quite well together anddid not experience problems that oftentimes developmentteams encounter. In retrospect, this was likely attributable tothe maturity of the individuals to pool their differing levels ofexpertise. In particular, the two experienced individuals tookon the bulk of the design and programming efforts, while theother team members provided database design, interfacedesign, undertook documentation of use cases, developed andran test scripts, ensured traceability and similar activities skills that could be obtained essentially from course work.Given this high degree of cooperation, serious schedulingcomplications nevertheless arose – not unique to teamprojects. But these arose from several levels. The class mettwice a week in the evenings from 6-7:15pm.Theexperienced team members worked from 9-5pm and were thusunavailable during the day for development team meetings;the other team members were full time graduate students andwere available during the days, but all had families and1269

International Journal of Computer and Information Technology (ISSN: 2279 – 0764)Volume 03 – Issue 06, November 2014spouses, which made meeting during the evenings other thanclass nights very difficult. Because the class met two times aweek, this only left hours after class, which effectively meantthe team usually remained after class after a long day.Management of the team, that is, the delegation ofresponsibilities was equitably determined, and each teammember played a primary role, such as project manager,primary programmer, quality control individual, tester, anddatabase developer. Each also had a secondary or backuprole. The management and integration of these activitiesduring available times (and all team members could notalways meet at available times), made the coordination ofteam efforts very difficult.Coordinating team member times for meetings is not anunusual problem in development teams in an academicenvironment. But another difficulty arose in trying to meetwith the clients, all of whom were City of Jacksonvilleemployees, who worked daily until 5pm. Students could notmeet as a group during the day in downtown with the clientsand the clients could not easily drive on to campus during theday. All modern development techniques agree on the criticalimportance of essential customer – developer relationships.During the next academic year, the two-course softwareengineering course sequence was scheduled to meet once perweek from 6 - 8:45pm. It was envisioned that this schedulewould leave more available times for team members toorganize their meeting times.B. The Collaborative Life Cycle Management (CLM)SolutionThe CLM is an extremely powerful tool. It covers allelements of the software lifecycle, and the capabilities forkeeping everything together while providing a comprehensivesolution is really outstanding. But it is not easy to learnespecially for students who lack software developmentexperience. Further, learning this solution and effectivelyusing this solution with its vast array of features whileconcurrently learning principles and practices of softwareengineering is daunting even for the most ambitious student.While tutorials are available, the lack of prior experience withthe CLM together with the students learning basic softwaredevelopment principles via the Rational Unified Process(RUP) and digesting the management of the developmentprocess with Scrum [2] proved to be a formidable challenge.Tech support within the School of Computing at UNF oftenwrestled with providing a stable environment for CLM. CLMwas hosted on a UNF computer, which proved to be reasonablyeffective. Yet many of the features inherent in the CLM, suchas burn-down charts, velocity charts, and using the vastfacilities within CLM to manage and track development andtesting had to be eschewed by the development teams in orderto meet the time constraints of iterations and sprints. Dates forthese deliverables together with examinations, presentations,and more, often precluded exploiting some of the real power ofthe CLM.www.ijcit.comC. Client Project Manager (PM)Initially the software engineering professor for this coursesequence met with the lawyer in the Ethics and ComplianceOffice to learn about requirements. Representatives from thisoffice later met with students one time for a serious question /answer period. From this meeting and from additionalmeetings between the professor and the Ethics andCompliance Office, use cases were developed – but by thedevelopment team (not by the client). Development startedonce a reasonably solid set of use cases were developed andapproved by the client for comments. It was not until wellinto the second semester that the COJ established a ProjectManager to oversee what the students were doing from aclient-perspective. Unfortunately, 60'% or more of elapsedproject time had been spent.More effective clientrepresentation was sorely needed. This was not the way toproceed.D. Changing RequirementsPerhaps the once constant in software development ischange. All modern development environments embracechange and certainly the RUP [1] and managing developmentvia Scrum support this reality. While experienced developersknow that change will occur and expect it and react to it, it isalways bit unsettling especially for new developers, who wantrequirements to be firm, complete, and unchanging. But theylearn very quickly. Requirements that are “must haves”suddenly become changed and generally more complicatedand comprehensive. This is frustrating to a student who islooking at the end of a semester dates, exam schedules, andclosure. But for sure, change occurs.As it turned out, most of the “must haves” in the lobbyistapplication remained solid, but the team did experience some“requirements creep.” A number of 'nice to haves' crept in too.These may often seem rather simple, and indeed sometimesthey are. Oftentimes they are not. Despite the experience onthe team, the first stage of the project (about one semester)consisted of five iterations of about two weeks each once theproject got started; the second stage, which was partially basedon the RUP (elaboration) but essentially development (usedConstruction and Transition for recognizing artifacts / workitems) was planned to be five sprints based on Scrum. Threemore sprints were added to implement the ‘nice to haves’ andschedule deployment activities (see Figure 1).E. Version Control and PoliticsUnfortunately, politics and other unforeseen circumstancessometimes occur. This development effort was no exception.When the project was nearing completion and demonstrationshad been provided to the client who applauded the fine workand seemingly everyone was happy, versioning and politicscome to center stage.While universities technologies often seem to lag ascompared to the industrial sectors, the converse seems to betrue when operating or working with state or city1270