Trac Case Studies in SCM and Project Management

This page described a few examples of Trac layouts. Each case should include Trac Layout (x Projects / x repositories), Trade Off (Positive / Negative), ticket process, usage of Trac plugins, components items and non standard reports. We will have a generic section and a Real-world. You do not need to provide real company names.

What follows are different possibilities when structuring your Trac process. While you can find instructions for installing Trac on specific systems at TracInstallPlatforms on the main Trac site, this is for putting everything together.

See also ​ProjectManagementIdeas for a proposal how Trac can be used in project management.

Generic, idealized models

Small teams

One Trac Project - One Repository (one project within Repository) - One Databases

Central Planning

Multiple Trac Projects - One Repository (many projects within Respository) - Multiple Databases

TracMultipleProjects/SingleEnvironment

Managed Chaos

Multiple Trac Projects - Multiple Repositories - Multiple Databases

TracMultipleProjects/MultipleEnvironments

Rapid Development

Multiple Trac Projects - One Repositories - Single Datebase

TracMultipleProjects/MultipleEnvironmentsSingleDatabase

Real-world studies

GPI Argentina

• This company uses Trac for all the Java software factory projects and internal organization.

Arenalogic F16 simulator build using Trac development

• This company uses Trac for c++ development of advanced military f16 simulators.

Boreste

• This company uses Trac for Embedded Systems development.
• Selected Trac to support Brazilian Model for Software Development Process (MPS.BR) -"G" Level- implementation

Trac Lay-out:

• 60+ projects on TracMultipleProjects/MultipleEnvironmentsSingleDatabase

• Plugins: TagsPlugin (_{builds co-relation among wiki pages and others}), IniAdminPlugin, AutoWikifyPlugin (_{automatically links insertion to existing wiki pages}), GanttCalendarPlugin, GraphvizPlugin (_{Processes graphics}), SqliteToPgScript (_{database "translation"}), GridModifyPlugin, MasterTicketsPlugin (_{aid traceability while performing requirements change management}), TicketImportPlugin (_{CSV issues-features, requirements, tasks, artifacts- imported at once}), TimingAndEstimationPlugin (_{keep track of work done, allows comparison with previous estimates}), TracWysiwygPlugin (_{turns edition easier.}), WikiCssPlugin (_{Environment customization}), NoteBoxPlugin,
• Macros: ComponentsProcessorMacro (_{artifact definition and management}), ChangeLogMacro, PlannedMilestonesMacro (_reports), ProgressMeterMacro (_monitoring), TocMacro (_{list sub-pages, show hierarchy -like in a PBS or WBS- recently deprecated in favor of TitleIndex}),
• Other tools: GAFYD Spreadsheets (_{support Wideband Delhi for time and effort estimation}), Planner (_{basic constraint analysis, resource allocation, estimate total project time})

Pro:

• Integration (Wiki, Issue system, Repository)
• Roughness (Apache + Postgre + SVN) on Linux server
• Easy to implement Intranet, Knowledge base and Product Management
• Light: requires few resources to work

Constraints:

• Requires process workarounds to get working stuff which is basic to others PM tools
• Wiki templates limited to the time a wiki page is created. Hard to maintain: wiki-pages which have common content have to be re-edited individually. Editing wiki template at once will be the must. (TracDev/Proposals/AdvancedWikiFormatting#Transclusion will help)
• No integrated support for roles. Existing plugins maybe?.
• Not easy to implement configuration management without hard coding (required for "F" level and up).
• Lack of "Smart reports"
  • No Project Added Value monitoring

Results:

1. Initial goals for this company where achieved
   1. have a tool which could support his processes in a 5 year round;
   2. allowing to obtain a formally qualified process for system development;
   3. low TCO;
   4. and requiring the less as possible IT Support.
2. Achieved MPS.BR "G" level