distributed software development collaboration tools

The last post attempted to define distributed software development collaboration tools in generalities.  This one will aim for specifics, with examples of existing tools.

Distributed software development teams need to collaborate.  Besides the basic hardware, development software, and communications infrastructure needed there are the following specialized tool sets:

Design:

• documents
• requirements, specifications
• diagrams

Development:

• version control
• automated builds
• unit and functional testing
• source code navigation and viewing
• code coverage and analysis
• generators

Deployment:

• packaging
• automated deployment
• system monitoring
• acceptance
• integration tests
• reporting

Overall:

• Planning
• Budgeting
• Communication
• Feedback

A typical software development team might have the following collaboration tools:

A wiki & file share for documentation.  Email, forums, instant message for communication.  A task management tool like MS Project or Basecamp.  A spreadsheet for budgeting.

A build script (ant, maven, make, rake).
Code generators (Appfuse, Hibernate).
Code coverage and analysis (Cobertura, Emma).
Continous integration server. (Cruise Control, Hudson)
Source code repository (CVS, Subversion, Git).
Repository browsing, code search, etc. (ViewVC, Fisheye).

A bug tracking tool. (Jira, Bugzilla)
Code tests (JUnit, TestNG)
Test case management (Test Director, Testopia)
Test automation (Selenium, Watir, Mercury Winrunner, QTP)
Requirements tracking (Harvest, Requisite pro)

Packaging and deployment scripts.
Smoke tests.
Performance tests.
Monitoring tools.

Distributed software development collaboration

I wrote a related post at oneshore.blogspot.com.

Software development requires collaboration in three areas: Development, Quality Assurance, and Project Management.  I’ve posted about this previously.  Development is the central process, which creates the actual artifact, the software product.  Software creation goes through three stages, that I called the “3 Ds” — design, development, and deployment.  They are not necessarily linear.

Quality assurance (QA) and project management (PM) are the ancillary processes to creation, that are nonetheless vital, though sometimes informal to the point of being not explicit.  They occur, at least implicitly, at all three stages of development.  The more explicitly a process is defined, the better it can be improved.  Defining the process facilitates teaching it as well.  That’s not to say that good project management and quality assurance can’t be performed implicitly.  But it does make it harder to teach and pass on, and requires a degree of talent that is not always guaranteed.

So the goal of One Shore is to identify, improve, and develop the tools that facilitate collaboration of software development and the ancillary processes of quality assurance and project management, through the stages of design, development, and deployment.