В случае, если выбран, путь автоматизации, при помощи заказного ПО или при помощи разработки ПО своими силами, то для того, чтобы упростить последующее сопровождение и развитие программы необходимо разработать своего рода "стандарт" на написание программ, и программу контроля качества.

При этом в стандарт могут входить различные по своей сути требования. Попытаюсь перечислить основные из них:

1. Среда разработки
2. Список используемых сторонних программных продуктов.
3. Список модулей (компонентов) сторонних разработчиков, которые могут быть применены при разработке и требования к ним.
4. Требования к структуре проекта
5. Требования к порядку и объему документирования
6. Требования к оформлению исходного кода программы
7. Требования к внешнему виду программы (Интерфейсу)
8. Требования к хранению исходников и ведению истории изменений.
9. Порядок внесения изменений в вышеперечисленные требования.

И все эти требования будут бесполезны - если нет схемы выполнения и контроля выполнения этих требований (так называемой программы качества).

Если часть из этих пунктов достаточно просты, либо уже неплохо описаны в литературе, то некоторые из них у каждого разработчика свои. Теперь об этом более подробно:

1. Среда разработки - на этом этапе надо просто определить и описать язык(и) программирования , на котором(ых) пишется программа и версия применяемого программного продукта.

2. Список используемых сторонних программных продуктов вам потребуется если прогррамме для работы потребуются какие либо программы сторонних производителей. Это может быть сервер БД или же любые другие программы (например Excel).

3. Список модулей (компонентов) сторонних разработчиков, которые могут быть применены при разработке и требования к ним - это очень серьезный вопрос, и недостаточное внимание к нему может привести к целому ряду нежелаемых последствий. Смысл этого пункта в том, что в рамках одного проекта (или в рамках одного коллектива) не должно существовать компонентов схожих по своей функциональности. Эти компоненты не должны конфликтовать между собой. Все компоненты должны быть тщательно отобраны, протестированы и разрешены для использования в рамках проекта (желательно, чтобы у всех разработчиков был установлен один и тот же набор компонентов). Мы применяем целый ряд сторонних компонентов.


4. Требования к структуре проекта - этот пункт граничит с ТЗ, но он необходим потому, что программу можно написать несколькими разными путями, и в любом случае она будет работать, но в рамках одного проекта должна существовать единая (с техническои (технологической) точки зрения) линия. И только описав ее на этом этапе в дальнейшем это можно как-то контроллировать. Как правило очень важно отразить следующие требования (которые часто могут не отображаться в ТЗ).

• Каким образом будет реализовываться программа с точки зрения интерфейса (MDI, SDI, несколько независимых приложений)
• Каким образом будет осуществляться разделение на функциональные модули
• Каким образом модули будут взаимодействовать между собой
• Будут ли они иметь какие либо совместно используемые модули
• Каким образом будет расширяться функциональность проекта
• Каким образом будет происходить обработка ошибок

5. Требования к порядку и объему документирования - тут прежде всего необходимо выбрать программу, в которой будет осуществляться написание документации, и определить структуру и объем документации.

6. Требования к оформлению исходного кода программы - об эти требования уже существует достаточно подробная литература.

7. Требования к внешнему виду программы - здесь нет универсального рецепта, но все формы в программе должны быть выполнены в едином стиле.

8. Требования к порядку хранения и ведения версий. - Для этого надо выбрать систему контроля версий и правила ведения архива программ, занесения новых файлов в архив и хранение истории изменений.

9. Для того, чтобы вышеперечисленные требования не тормозили развитие проекта очень важно, чтобы существовал достаточно простой порядок внесения изменений этих требований, но, чтобы этот порядок мешал внести хаос в разработку.
Ну и напоследок - для того, чтобы все этого заработало - необходимо, чтобы эти требования выполнял каждый работник коллектива (без исключений). Собственно насколько я понимаю умение работника соблюдать эти требования и является способностью человека работать в комманде.

Что касается нашего программного обеспечения, то у нас уже давно сложилась следующая ситуация:

1. При проектировании мы строго ограничиваемся архитектурой Клиент-Сервер.
2. Для разработки программ мы используем Borland Delphi 7.
3. Программное обеспечение работает под управлением ОС Microsoft Windows.
4. База данных функционирует под управлением СУБД Microsoft SQL Server (MSSQL). При этом для функционирования программы не требуется никакого дополнительного ПО. (Тут стоит отметить, что в связи с тем, что мы используем компонеты для доступа к БД собственной разработки,при наличии требований заказчика, мы можем в очень короткий срок перевести программу на СУБД Oracle.)
5. Наше программное обеспечение работает под управлением единой базовой программы и может работать как с интерфейсом в стиле MDI так и с интерфейсом в стиле SDI.
6. Разделение на модули происходит при помощи стандартных bpl - Package (Delphi).
7. Программа может поставляться как в виде одного исполняемого файла, в который включены все модули, так и в виде отдельных библиотек, которые подключаются к программе - загрузчику.
8. Расширение функциональность программы происходит путем добавления отдельных модулей. Программа может поставляться частично или полностью с исходниками, при этом поддерживается возможность подмены стандартных модулей на пользовательские.
9. Обработка ошибок возвращаемых Базой Данных происходит в клиентской программе. При этом есть возможность руссифицировать текст ошибок путем правки текстового конфигурационного файла обработки ошибок.
10. Документирование проводится при помощи программы Help&Manual
11. Существует несколько разновидностей форм, при этом все они наследуются от одной базовой формы.