14 pages

Please download to get full document.

View again

of 14
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Tools for Teams: A Survey of Web-Based Software Project Portals Jordi Cabot and Greg Wilson Dept. of Computer Science University of Toronto {jcabot,gvwilson} August 31, 2009 Abstract Web-based project portals are at the heart of modern software development, but have been studied much less than individual-oriented desktop tools like integrated development environments. In July–September 2008, we compared several popular portals and interviewed their developers in order to find out w
  Tools for Teams: A Survey of Web-BasedSoftware Project Portals Jordi Cabot and Greg WilsonDept. of Computer ScienceUniversity of Toronto {  jcabot,gvwilson } @cs.utoronto.caAugust 31, 2009 Abstract Web-based project portals are at the heart of modern software devel-opment, but have been studied much less than individual-oriented desktoptools like integrated development environments. In July–September 2008,we compared several popular portals and interviewed their developers inorder to find out what needs they were intended to satisfy, how their fea-ture sets had been chosen, and how they were likely both to evolve andto shape the evolution of distributed software development. Our key find-ings are that (1) most portals are strongly biased toward agile methods(and in fact may primarily exist in order to support agile development ingeographically distributed teams), (2) the teams building these portals donot use agile methodologies themselves, but instead rely on informal col-lections of best practices, (3) as elsewhere, there is a clear trend towardhosted services, and (4) none of the portals studied provided any kindof support for modeling or user experience design, and only one directlysupported test management. 1 Introduction If you pick a software development project at random, the odds are good that itssource code, bug reports, mailing list archives, and so on reside in a web-basedportal. Whether it’s a hosted service like SourceForge 1 or an installed systemlike Trac 2 , in many ways that portal is the project: individual developers mightcome and go, but the portal’s contents live on, and with them, the project.Despite their widespread use, software project portals have been studiedmuch less than individual-oriented tools such as integrated development en-vironments (IDEs) [6]. To begin to rectify this, in July–September 2008 weexamined the features of several representative portals and interviewed their 1 2 1  developers. Our research goals were to determine what needs those tools wereintended to serve, how their feature sets had been chosen (e.g, how their de-velopers had translated perceived needs into functionality) and how they werelikely to evolve. To our knowledge, this is the first general study of web-basedsoftware project management tools, though their importance was pointed outin [1]; for comparisons of pre-web tools see [5].We begin below by describing what a minimal portal might contain. We thenexplain how we selected and collected data about eleven specific portals. Theremaining sections analyze our findings and speculate about the likely futureevolution of software portals. It is important to note that for every system weincluded there were several others that we left out. Our choices should thereforenot be taken as a judgment or recommendation. 2 What’s (In) a Portal? Just as programmers may use “editors” ranging from Notepad through Vi toEclipse, so too do online project management tools range from shared to-dolists to multimedia collaborative environments. To be called a software projectportal, however, we felt a system must have at least a few specific features.The first is some kind of task management, such as a to-do list, bug tracker,or full-blown workflow management system. For us, this is what makes projectmanagement tools distinct from other kinds of groupware.The second core feature is a document repository. Systems aimed primarilyat developers typically integrate a third-party version control system such asSubversion 3 , while systems aimed at broader audiences usually include a simplerfile upload mechanism. Both allow stakeholders to share and modify content,and to see who else has done so.Conversational tools are third on the list. These include email, chat, wikis,blogs, bulletin boards, and other ways for stakeholders to communicate andcoordinate. A growing number of systems present content in several forms, e.g.,by providing RSS notification of updates to bulletin boards, or wiki transcriptsof chat conversations.Last but not least is search. One reason people use portals is to link thedisparate pieces of information that comprise a project; one of the benefits of doing this is that a single query can then find email messages, version controlcheck-in comments, and wiki pages all at once.Other components tend to revolve around these four core capabilities. Forexample, some include a calendaring tool so that stakeholders can schedule workitems (e.g., by grouping them into iterations, and then binding those iterationsto target delivery dates). Others include time-tracking tools to help consultantswith billing and schedule management; a tagging mechanism; a report generator;a web API for remote scripting and administration; customizable fine-grainedaccess control; or a continuous integration back-end to automatically re-buildand re-test code. As with document repositories, these may be more or less 3 2  developer-centric, i.e., may require greater or lesser degrees of technical sophis-tication to use. 3 Gathering Data Since dozens of portals exist 4 , we had to decide which to include in our study.Our initial pool of candidates consisted of systems that one author had examinedwhen selecting a portal to use in undergraduate software engineering courses.We enlarged the pool by conducting web searches for keywords prominent inthose systems’ descriptions of themselves, by including systems that previously-added systems compared themselves too, and through word-of-mouth referralsfrom colleagues and attendees at various conferences. The list was then filteredagain according to the following criteria:1. The system had an active developer community.2. It was being used by people other than its developers.3. Many or all of its users were software developers using it for softwareprojects.4. Someone central to its development was willing to be interviewed. We didnot request contact with specific people but instead asked for intervieweesplaying a key role in the tool conception and development (founders, CIOs,chief developers or similar). To our pleasant surprise, only two of thegroups we approached declined to take part 5 and thus were removedfrom the study.Our final list of portals was: ã Acunote 6 ã Assembla 7 ã BaseCamp 8 ã DotProject 9 ã Google Code 10 ã IBM Jazz 11 4 Or partially exist, or may have existed but are now moribund. 5 Due to confidentiality issues we cannot identify these two tools nor provide more detailedinformation about the people we intervieweed 6 7 8 9 10 11 3  ã Mingle 12 ã Rally 13 ã SourceForge 14 ã Trac 15 ã VersionOne 16 Having selected these systems, we itemized the features offered by each inthe areas of authentication, collaboration tools, document management, worktracking, and time management, and where feasible gave it a test drive to vali-date and fill in gaps in their self-descriptions.We then set up an interview with a key member of its development team. Wesrcinally intended to conduct hour-long structured interviews, but intervieweesperceived their systems and markets in such different terms that no questionscript made sense for everyone. We did, however, cover all of the following areas: ã When and why did you start developing the portal? ã Why did you decide to create a new portal instead of adopting or extendingan existing system? ã What user needs did you set out to satisfy? ã What was your initial business model? ã Does the portal favor any software development process? ã What software development process do you use yourselves? ã Who are your typical users, and how do you determine their requirements? ã How do you determine user requirements? ã How do you rank affordability, extensibility, flexibility, reliability, security,and usability as development drivers? ã Is it open source, closed source, or some mix of the two? ã Is it free to use or not? (This is orthogonal to the open/closed questions,since some groups provide a free service on top of closed-source software,while others offer a stripped-down version under an open license and apremium version with extra closed-source features for a fee.) 12 13 14 15 16 4
Similar documents
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!