Вопрос 7. Групповая разработка, управление версиями.

Управление версиями:

Visual Source safe, PVCS….

Храним версии в едином репозитории. Для уменьшения пространства можно применять иерархическую структуру версий и хранить только отличающиеся файлы.

Применяем операции CheckOut (берем файл из репозитория и монополизируем доступ к нему до окончания процесса исправления), CheckIn (возвращает измененный файл в репозиторий).

//Замечание:

Для предотвращения ситуации, когда разноверсионные модули одного и того же приложения работают с разными типами (разметками) данных, эти разметки тоже необходимо хранить в репозитории, а модулям назначать CRC. Доступ к данным при записи/чтении можно монополизировать, но это может грозить приостановкой работы всего приложения (особенно если используется единая БД, ибо придется строить транзитивное замыкание графа процессов и ресурсов, с которыми они работают, которое может охватить все ресурсы.). Решение – разбить программу на объекты, которые содержат как данные, так и код, общение между объектами (запрос данных) – при помощи сообщений. Каждый объект может разрабатываться независимо от других, следовательно возможна групповая разработка. //Проблема – посылка сообщения – трудоемкая операция, но можно выстроить объекты в конвейер.

Вопрос 8. Организация коллектива разработчиков.

Иерархическая: проблема – интерфейсы, комплексная отладка занимает много времени, теряется время на коммуникацию (осуществляется через верхние уровни), теряется смысл сообщений. Минус: все решения принимаются одним человеком, но он может заблуждаться, может знать меньше.

Ядро: один пишет прототип, потом из него возникает продукт. Проблема: сложен переход.

Матричная модель: в ней есть узкие специалисты, которые заняты сразу в нескольких проектах.

Проблема – люди зацикливаются на своей работе, структуризация продукта, не все могут быть одинаково загружены.

"Хирургическая" схема: главный "хирург", зам. гл. "хирурга", подмастерья (документатор, специалист по оптимизации, менеджер). Работает для небольших комплексов, для больших проектов – плохо.

+: нет проблемы согласования, программа получается концептуально целой и грамотной

-: увеличение рисков, все хотят быть главными хирургами, но не подмастерьями.

Вопрос 9. Документирование.

ЕСПД – единая система проектной документации.

Документы:

1). ТЗ :

1. название (полное и краткое)

2. цели разработки

3. разработчики

4. технические требования

4.1, 4.2…

//Вложенность пунктов – не более 4.

Технические требования: функциональные (то, что должна делать программа), нефункциональные (эргономика, переносимость).

В ТЗ должны быть указаны сроки и этапы (полезно декомпозировать работы при оценке сроков), чем заканчивается работа

2). ПМИ (программа и методика испытаний) - структурно совпадает с ТЗ, указывается, как оценивать каждый пункт

3). User Guide – должен быть подробный

4). РСП (руководство системного программиста) - - включает инструкцию по установке

5)* - Исходный код и комментарии, может быть API.