I’ve started this topic in the previous 2 posts (part 1 and part 2). Here are some more thought regarding the project management for large software projects.

Usually software development doesn’t imply the use of any version control system. All other approaches could be applied or not to individual projects. It dependents on the specifics of developed system, on many other factors, the most important of which, in our opinion, ability to control all the approaches, availability of necessary skills and resources and quality of the developed system.

There is a separate discipline of software engineering, which deals with this kind of organizational objectives without any reference to methodology — it is a configuration management. Configuration Management is a core discipline that helps to manage and control requirements specification, the process of software project development and information on the status of individual tasks and the entire project as a unit. The project success largely depends on how the process of configuration management was streamlined. On the one hand it can save the project, but on the other hand it can bury it.

Glossary of IEEE 610 describes configuration management as “a discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements”.

But it’s a rather formal definition. The following software and tools that programmers face on duty every day will allow you to understand how this definition works in practice:

* Subversion; CVS; Git; Mercurial; Bazaar; Microsoft Visual SourceSafe; ClearCase; Perforce.
* Ant; Nant; Maven; Phing; make; nmake; Cmake; MSBuild; Rake.
* JUnit; NUnit; CPPUnit; DUnit; PHPUnit; PyUnit; Test:: Unit; vbUnit; JsUnit.
* PMD; FxCop; PHP_CodeSniffer; PyChecker, lint.
* JavaDoc; phpDocumentor; CppDoc; RDoc; PyDoc; NDoc; Doxygen.
* CruiseControl; CruiseControl.NET; TeamCity; xinc; Atlassian Bamboo; Hudson.
* Jira, Trac, Mantis, Bugzilla, TrackStudio.

I hope this information was useful for at least some of you and will highly appreciate comments and any other kind of feedback.

Beginning of the article read here.

Programmers look at the same project from the different position (in comparison with managers) and they focus their attention on other issues: architectural design, database, UML-diagrams and all these stuff. In theory it means “to spend the whole day in order to fly in 5 minutes”. If you take these steps as number “0” in software development process, in practice the project will begin with the step number “1” – with the development. It is not quite correct approach, but it’s the only possible approach when developers can’t give the exact answers to the questions put at the very beginning of software development. (Tell us about the other possible way out, if you know it
Agile methodologies are known as attempt to solve these problems (and we like this approach, we even used it in our corporate brand – Oxagile). But agile methodologies work mainly on organizational level. Programming level is connected with other issues.

Let’s consider the essence of flexible methodologies to software development from programmers’ position. Here are some commonly used approaches:

1. Version control
2. Build management
3. U-testing
4. Static source code analysis
5. Code based document generation (javaDoc, phpDoc, Doxygen, etc.)
6. Continuous integration