- Requirements - in user terms; the "what"
- Modeling and Design - in technical terms; an overview of "how"
- Project Management (backlog, etc.) - requirements and dates
- Configuration Management - technology components
- Build Management - technology components
- Testing - components, tests (and possibly requirements)
- Release and Deployment - more components
- Bug, Issue and Defect Tracking - user terms, requirements, etc.
- Requirements have an overview in the backlog, on the scrumboard. Details can be captured in text documents written using simple markup like RST or Markdown. You don't need much because this is an ongoing conversation.
- Modeling and Design is a mixture of UML pictures and narrative text. Again, simpler tools are better for this. Tool integration can be accomplished with a simple web site of entirely static content showing the current state of the architecture and any detail designs need to clarify the architecture. Write in RST, build it with Sphinx.
- Project Management should be simply the backlog. This is digested into periodic presentations to various folks outside the scrum team. There isn't much that can be automated.
- Source Code Control, sometimes called Revision Control. See the Comparison of Revision Control Software page for more information.
- Software Configuration Management; the actual deployment of assets. See the Comparison of Configuration Management Software page for more information.
Build Management might be interesting for complex, statically compiled applications. Use of a dynamic language (e.g., Python) can prevent this. Build management should be little more than Ant, Maven or SCons.
Additional tools include the Build Automation list of tools.
Testing is part of the daily build as well as each developer's responsibility. It should be part of the nightly build, and is simply a task in the build script.
Overall integration or acceptance testing, however, might require some additional tools to exercise the application and confirm that some suite of requirements are met. It may be necessary to have a formal match-up between user stories and acceptance tests.
Release and Deployment can be complex for some architectures. The article on Software Deployment doesn't list any tools. Indeed, it says "Because every software system is unique, the precise processes or procedures within each activity can hardly be defined."
Something that's important is a naming and packaging standard, similar to that used by RPM's or Python .egg files. It can be applied to Java .EAR/.WAR/.JAR files. Ideally, the installed software sits in a standard directory (under /opt) and a configuration file determines which version is used for production.
Perhaps most important is the asset tracking, configuration management aspect of this. We need to plan and validate what components are in use in what locations. For this BCFG2 seems to embody a sensible approach.