Ответственный за управление проектом

АННОТАЦИЯ
Настоящий документ является планом конфигурационного управления для проекта
“SeaBattle”. Утвержденный план обязателен для выполнения всеми участниками данного
проекта.
ВВЕДЕНИЕ
1.1. Цель документа
Целью настоящего документа
управления в данном проекте.
является
планирование
конфигурационного
1.2. Нормативная основа
Настоящий план основан на СТП СК ФТ «Конфигурационное управление при
выполнении проектов разработки прикладного программного обеспечения и
документации. Версия 2.0.0».
1.3. Сведения о документе
Номер версии:
Дата утверждения:
0.0.1.
02.04.2008 г.
Термины, сокращения и определения
Сокращение, термин
Расшифровка сокращения или термина
КУ
Конфигурационное управление
Репозиторий
База данных конфигурационного управление. Хранилище
объектов конфигурационного управления.
Артефакт
Входной или выходной объект процесса разработки
программного обеспечения. Например, входным артефактом
является файл, содержащий техническое задание, а выходным
- файл исходного кода imitator.cpp. Не все артефакты
размещаются в репозитории, например, результат компиляции
исходного кода – исполняемый EXE файл рекомендуется не
помещать в репозиторий.
Объект
конфигурационного
управления
Любой объект, хранящийся в репозитории проекта.
2.1 Описание инструментальных средств
Идентификатор
комплекса/комп
онента
LBAT
MNCP
MDCP
SITL
Инструментальное средство
Номер версии
инструментального
средства
Microsoft .NET Framework
3.5
Microsoft Visual Studio 2005 Professional
9.0
NUnit for .Net 2.0
2.4.6
2.2Стандарт именования
2.2.1 Наименования файлов
<имя файла исх. кода>=<имя класса, определенного в файле>.h (С++);
<имя файла исх. кода>=<имя класса, реализованного в файле>.cpp (С++);
<имя файла исх. кода>=<имя интерфейса, определенного в файле>.cs (С#);
<имя файла исх. кода>=<имя класса, опред-го и реализ-го файле>.cs (С#).
Примечание: Помещайте каждый класс в отдельный файл.
2.2.2 Наименования объектов на языках программирования
Общие рекомендации:
1)
не именовать объекты наименованиями, отличающимися только регистром,
например, SystemIO и SystemIo, Color и COLOR;
2)
использовать только целые слова (русск. или англ.) и общепринятые
аббревиатуры (IO, UI), если иностр. эквивалент слова неизвестен, то
необходимо заглянуть в словарь (например, имена shetchik, oshibka,
менедж_устр недопустимы, т. е. д. б. сounter,
error,
менеджер_устройств).
Классы и интерфейсы
Имена
классов
всегда
начинаются
с
заглавной
буквы,
например,
ККонтроллер_доступа,
Загрузчик_работ,
CDefaultManager,
ИКонтроллер_доступа, ISignal. Для классов возможны префиксы: “C-” (англ.),
“К-” (русск.). Для интерфейсов обязательны префиксы: “I-” (англ.), “И-” (русск.).
Следующий за префиксом символ всегда должен быть заглавным. Для классов
использование префиксов необязательно.
При выборе имени для класса, необходимо помнить, что классу должна
соответствовать некоторая сущность, определяемая такой частью речи, как
существительное, т. е. если сущности не существует, то и класса быть не должно. Пример
неверного именования класса: ВЖурнал (существительное отвечает на вопрос “Что?”, а
здесь существительное в роли обстоятельства отвечает на вопрос “Куда?”), CScan (здесь
вообще глагол, что больше подходит для наименования метода).
Методы классов и функции
Методы классов и функции должны всегда начинаться с заглавного символа,
например, Печать(), Старт(), SaveFile(), OpenSession(). Параметры
методов и функций должны начинаться с прописного символа, например,
SetTimeout(int timeout).
При выборе наименования для метода или функции следует отдавать предпочтение
глаголам в повелительном наклонении (например, Включить(), Выключить(),
Установить(), ScanSignal()) или существительным, обозначающим действия или
команды (Старт(), Стоп_работа()).
Свойства классов
Наименования свойств всегда должны начинаться с заглавного символа, префиксы
не допускаются. Примеры: Status,
Color,
Speed,
Код_ошибки,
Диагностика, Результат_работы.
Открытые члены классов
Имена открытых членов классов должны начинаться с прописного символа,
префиксы
не
рекомендуются.
Примеры:
менеджер_ЦГ,
контроллер_доступа_к_журналу, left_engine (но не m_left_engine).
Закрытые члены классов
Наименования закрытых членов классов (private и protected) полностью аналогично
открытым членам, но предваряются символом “_”. Примеры: _менеджер_ЦГ,
_контроллер_доступа_к_журналу, _left_engine.
Перечисления
При объявлении перечисления все символы должны быть заглавными, например,
RAINBOW_COLOR, MODULATION_TYPE, а значения перечислений должны только
начинаться с заглавного символа, например, Red, Orange, Yellow, Green … и Amplitude,
Frequency …
Специфика управляемого кода (Managed C++, С#)
Не рекомендуется применять для обработки ошибок возвращаемые значения
методов, обработка ошибок должна опираться на исключения.
Соглашения o едином стиле главного меню графических интерфейсов
1.3.1. Пункт меню “Справка”
Если программный компонент содержит графический интерфейс, необходимо чтобы
главное меню пользовательского приложения содержало пункт ”Справка”. Данный пункт
должен включать:
1. Пункт “Справка F1”
При обращении к этому пункту должна отображаться справочная информация по
данному программному компоненту.
2. Пункт “О программе”
При обращении к этому пункту должна отображаться следующая информация:
2.1 Название приложения;
2.2 Номер версии;
2.3 Разработчик;
2.4 Год и место разработки данного продукта.
Например:
2. ПОРЯДОК СБОРКИ И ФОРМИРОВАНИЯ ВЕРСИЙ
2.1. Взаимозависимости компонентов/комплексов
-
-
Характеристика компонента/комплекса:
Функция – подсистема является самостоятельной функциональной подсистемой
(верхний уровень архитектуры);
Содержание Web – подсистема является содержанием разрабатываемого Web – узла;
Сервис пользователей – подсистема является набором компонент обеспечивающих
интерфейс пользователя в функциональной подсистеме;
Бизнес сервис – подсистема является набором компонент обеспечивающих бизнес
логику функциональной подсистемы;
Сервис данных – подсистема является набором компонент, обеспечивающих связь
функциональной подсистемы с базой данных;
База данных – подсистема является базой данных для функциональной подсистемы.
Инструмент
–
подсистема
является
вспомогательным
средством
для
разработки/отладки разрабатываемых в рамках проекта компонентов/комплексов.
Характер зависимости:
Разработка – разработка зависимой подсистемы может быть полностью завершена
только после завершения данной подсистемы;
Сборка – сборка зависимой подсистемы может быть осуществлена только после
сборки данной подсистемы;
Изменение – при необходимости внести изменения в зависимую подсистему
необходимо также внести изменения в данную подсистему;
Тестирование – для проведения тестирования зависимой подсистемы необходимо
провести тестирование данной подсистемы.
РАСПРЕДЕЛЕНИЕ РОЛЕЙ В ПРОЕКТЕ
Ответственный за управление проектом
Шаханов Михаил Дмитриевич
Интегратор (ответственный за конфигурационное управление проекта)
Голубев Павел Алексеевич
Ответственный за управление изменениями
Костин Олег Юрьевич
Ответственный за управление документацией
Ручкина Юлия Дмитриевна
Ответственный за контроль качества ПО
Чалкова Наталья Валерьевна
Ответственный за управление требованиями
Сидоров Анатолий Юрьевич
Ответственные за разработку комплексов/компонентов
Должность
студент
Идентификатор
компонента/комплекса
Фамилия И.О.
База данных
Добрушский
Костин
Новиков
студент.
GUI
Соколов
Шаханов
Голубев
студент
Сервер
Глазырин
Князев
Напылов
Ручкина
студент
Клиент
Дунаев
Шевченко
Чалкова
Сидоров