Creating a development process using SourceForge (TM)
Copyright (c) 2001 by Frank V. Castellucci
All rights reserved
SourceForge.net
For those working on, or wanting to work on, complex large scale projects,
SourceForge is not quite ready to support the project team in meeting
the challenges faced during the software development life cycle (SDLC).
The lack of some fundamental tools and support for the work flows
that occur around them (e.g. Configuration Management, Change Control,
Project Planning), coupled with the implementation of SourceForge
itself may present barriers too large to overcome.
It is my belief, and all I have to go on is my perspective, that SourceForge
was "written" and did not have a larger scope strategy
and design in mind. This may be the by-product of reading too much
into the Cathedral and the Bazaar, a marketing rush job to get something
out the door or just my imagination.
The intent of this document is not to flame SourceForge but to position
what is available in a more favorable and productive light. I'll do
this by suggesting pragmatic and practical processes around the existing
tools and services. That being said let's get right to the meat of
the matter (as the title suggests), which may be rephrased as a question:
"How can I leverage the existing Source Forge tools to support
a structured development process?".
My assumption is that the processes and artifacts defined in this
document are understood. If this assumption is not true, for the reader,
then I would suggest learning about them and I would encourage you
to consider this document as a reasonable framework or starting point
for your project.
This document is dedicated to the hard working people that make SourceForge
possible, especially the ones that don't let geeps like me rattle
their cages.
VA Linux Systems and SourceForge are trademarks of VA Linux Systems,
Inc. Linux is a registered trademark of Linus Torvalds.
An inventory of terms, tools and services is in order:
- Terms
-
- Administrator - A SourceForge user that has initiated, or controls,
a SourceForge hosted project. This does not imply the administrator
is the project manager, although most times they are.
- Artifact - A typical product or result.
- Developer - A SourceForge user that is made part of a project team,
typically involved to contribute code.
- User - This is anyone who has registered for an account with SourceForge.
This does not imply developer status or affiliation to any particular
project(s).
- Methodology - An organized, documented set of procedures, processes
and guidelines for one or more phases of the software development
life cycle, such as analysis or design.
- Process - a particular course of action intended to achieve a result.
- WorkFlow - The set of relationships between all the activities in
a project, from start to finish. Activities are related by different
types of trigger relationships. Activities may be triggered by external
events or by other activities.
- Work Products - are the artifacts of a particular work flow in the
development life cycle. Some examples of work products include: Requirement
specifications, Use Case diagrams or specifications (I hope both),
architectural scope definitions, flow charts, or data flow diagrams.
- Tools
-
- Documentation Manager - Facilitates documentation being attached directly
to the projects page, as opposed to web pages or bundled up in project
releases. Documentation can be categorized, with the administrator
is in charge of creating the categories.
- Forum - Threaded discussion area(s) supporting a reasonable level
of collaboration.
- Tracker (Abstraction) - A generic artifact management facility that
supports state changes with a reasonable degree of collaboration.
States and categories are administrator defined. While it may not
be obvious, Bug Manager and Support Manager are predefined trackers.
- Bug Tracker - This is a tracker that (syntacticly) provides defect
tracking. It allows both signed on and anonymous (configurable) access,
state group.
- Support Tracker - This is a tracker that (syntacticly) provides user
support management. It is intended to be used to report request for
help, not defects or features.
- Permissions Manager - If you started a project on SourceForge, you
are the project administer. As the administer you can control team
member access and control over the various SourceForge tools.
- Task Manager - This can best be described as a glorified To-Do list.
- Release Manager - Provides management and administration of project
releases (whatever that may be).
- Services
-
- CVS Server - Each project is given a CVS tree for code, scripts, documentation,
web-sites, etc.
- Shell Account - Anyone involved in a project gets a shell account
on the SourceForge shell server.
- Web Account - Each project is allocated a web site to hawk itself.
In addition, you can optionally request a MySQL database. SourceForge
project URL are easy to spot : http://someproject.sourceforge.net.
- Compile Farms - Servers which allow projects to perform off-site compilations
of their project code.
As defined in the terms: a process is the course of action one takes
to achieve a result. While not trying to boil the ocean with this
document, I will express ways to leverage the tools for the following
work flows that, should, occur in everyone's project:
- Requirements and Use Case Management
- Analysis and Design
- Development
There are more processes in a true SDLC than I have listed here but
I consider the above to be the absolute minimum work flows, in my
experience, that will lead to some level of success. Given the current
tool set of SourceForge, these are also the most approachable.
Each of the work flows will be described first by the entry condition
assumptions, SourceForge tools that are used, the work products that
are artifacts of the work flow, any setup that is needed and the process
itself. In addition, because the size of the project may have a direct
impact to the artifacts and tools being used, I've indicated where
the differences to be considered are between small, medium and large
scale efforts.
Sure, there are projects where the process involves nothing more than
starting the editor and designing as you code, but the majority of
them just become dead wood in the archive of SourceForge.
- Vision document or ability to produce one
- Project registered with SourceForge
- Diagram notation standard
- HTML presentation standard
- Trackers
- Documentation Manager
- Multimedia Manager
- Forums
- Standards and guidelines documentation
- Requirement Specification
- Architecture Description
- Requirements (Tracker)
- Features (Tracker)
- Use Case Diagram and Specification (optional)
- Actor Diagram and Specification (optional)
- Data flow diagrams (optional)
- Create the following private Trackers: Requirements, Features, Non-Functional
Requirements
- For each Tracker, max out the overdue day counter
- Create the following documentation categories: Project Overview, Architecture,
Requirements, Standards, Use Cases (optional)
- Create the following private trackers: System Requirements, Interface
Requirements, Features, Hardware Constraints, Software Constraints
- For each tracker, max out the overdue day counter
- Create the following documentation categories: Project Overview, Scope,
Architecture, Requirements, Use Cases, Project Standards
Your on your own here, skip to the end of this document and ignore.
Needless to say that implementing the management of process on the
web would be a project unto itself, a paradox thingy.
The process:
- If you haven't already, publish the Vision document and post a forum
message linking to the document.
- If you haven't already, publish any standards and/or guidelines for
the project or for relevant artifacts for this work flow.
- For large projects, define the scope of the problem space and publish
to the appropriate documentation category.
- Create work products: Requirement specifications and/or Use Case diagrams
and specifications. Don't forget reviewing the Suggested Features
list if one exists.
- Categorize the diagrams and specifications accordingly (functional,
non-functional, feature, etc.).
- Publish the work products to the relevant documentation category and/or
upload diagrams using multimedia. Documentation should contain links
to the diagrams of course.
- Create an individual tracker entry in the relevant tracker that links
to the associated document.
- Repeat steps 4 through 7 as necessary.
- Analyze the requirements and constraints to define the initial architecture(s).
- Publish the architecture(s) to the appropriate documentation category,
and any supporting diagrams (component, data flow, etc.) to multimedia.
You may be tempted to attach the work products to the tracker entry...don't!
You may be tempted to define a CVS tree...not yet!
You want the outside world to see your progress and understand the
system under design thereby opening the potential for positive collaboration.
As well as making it easier on the team when you need to edit the
document it also make access by team members manageable as the tracker
entry is an index to the body text definition. This forms the basis
of traceability for the individual requirement throughout the development
life cycle.
In effect, we are using the Trackers as a bag to collect the work
units from a development standpoint. The ability to move a Tracker
artifact to other defined Trackers in the project enable some level
of change control as you will see later on.
- Requirements and Use Cases are validated.
- Architecture has been validated.
- Trackers
- Documentation Manager
- Multimedia Manager
- Forums
- Component or subsystem specifications and diagrams (optional)
- Based on your chosen methodology, any specifications and diagrams
which support the design effort.
- Requirements and Use Case Specification (derived) and diagrams (optional)
- Create the following documentation categories: Analysis (optional),
Design
- Create appropriate user forums
- Create the following documentation categories: Interface Design (optional),
Analysis and Design
- Create appropriate user forums
What are you still doing here?
The process:
- If you haven't already, publish any standards and/or guidelines for
the project or for relevant artifacts for this work flow.
- Create work products as defined by your methodology.
- Categorize the diagrams and specifications accordingly.
- For the contextual support of the work product, capture the driving
aspect (requirements, use cases, etc.) as a link.
- Publish the work products to the relevant documentation category and/or
upload diagrams using multimedia manager. Documentation should contain
links to the diagrams of course.
- Repeat steps 2 through 5 as needed.
- When a new analysis or design artifact is posted, drop a line in a
relevant forum so that others may view and collaborate on it.
- When complete, you should define the CVS tree.
Remember, you are still communicating the solution as it unfolds and
are ripe for the opportunities that interested parties may have to
offer. Open Source is not just about source code, and if it is then
it needs to change it's definition.
We often kid ourselves into thinking we have all the answers, which,
by definition, is an egotistical and myopic view when considering
both subject matter and the globalization potential offered through
tools like SourceForge.
- Enough details in a design are available to develop something with
a high degree of confidence.
- The appropriate coding standards have been defined.
- The CVS tree has been defined.
- Trackers
- CVS
- File Release Manager
- News
- Create the following public tracker: Accepted Requirements
- For each Tracker, max out the overdue day counter
- Setup the CVS tree
- Create the following public tracker: Accepted Requirements, Accepted
Features
- For each Tracker, max out the overdue day counter
- Activate the Patch Manager
Wow, what a mascocist.
The process:
- Develop a candidate list of requirements by prioritization review,
sizing or release objectives.
- From the home of the Tracker, where the candidate requirements live,
move it to the respective Accepted Requirement/Feature tracker.
- For non-functional requirements or constraints, you may consider state
changes on the individual records instead.
- Assign some one or group to the Accepted.
- Develop and unit test your work.
- Build verify your changes.
- Check the code in and in the comment section of the CVS check-in,
refer to the Accepted Requirement/Feature identifier.
- Repeat steps 1 through 7 as needed.
- When ready, create a release and include the list of Requirements/Features
that have made the cut.
- Optionally, close the Accepted artifact.
- Post a News article about your release.
- Send me five (5) dollars US
It is useful to limit what people are working on to what has been
justified, analyzed and designed. It will limit the universe of defects
that can crop up with a piece of unauthorized code and define the
acceptance criteria for a release. If it isn't requirements or features
driven, it shouldn't find it's way into the system.
While unit and build verification testing may seem a tad contrary
to the ``Release Early and Release Often'' mantra, it (unit
testing) becomes an important standard for the project for a number
of reasons: first, no one likes a release that they must download
and install for it to do nothing, or to blow up if it even loads,
and as importantly, it forms a contract that the team has with each
other that says ``No code shall be checked in before it's time.''.
For any of us that have refreshed a code base only to find that it
can't even compile, you'll know what I mean.
Finally, fear not that you have lost information by closing the completed
artifact record. If you have maintained the rigor throughout the process
you have the documentation work products to back up what has been
done. You may consider marking the document as complete with a release
identifier in it as well.
Creating a development process using SourceForge (TM)
This document was generated using the
LaTeX2HTML translator Version 99.2beta6 (1.42)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -no_subdir -split 0 -show_section_numbers /tmp/lyx_tmpdir1356OWFtIe/lyx_tmpbuf1356CKU7if/SourceForgeProcess.tex
The translation was initiated by Frank V. Castellucci on 2001-05-06
Frank V. Castellucci
2001-05-06