Фамилия, Имя, Отчество (на русском) сотрудника

Должность (на русском)

Отдел, Название фирмы (на русском)

-----------------------------------------------------------------------------

Телефон (7-095) (код страны, код города),

ХХХ-ХХ-ХХ (телефон)

Подпись, выполненная по такому стандарту, должна выгля­деть так:

Иванов Иван Иванович, системный аналитик,

отдел системного анализа, ЗАО «Б&С»

------------------------------------------------

Телефон (7-095) 964-16-44

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

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

На практике удобно выделять рабочее пространство на пространства:

· аналитиков;

· программистов;

· тестеров;

· специалистов отдела внедрения;

· конической поддержки.

Анализ и проектирование. Обычно для целей функционирования аналитического отдела разрабатывается ряд стандартов, Которые регламентируют, как правило:

· применение методик структурного анализа или методов объектно-ориентированного анализа;

· описание бизнесс-процессов предметной области одним или несколькими программными средствами (Rational Rose, Erwin, BPwin и др.);

· ограничение или расширение использования отдельных элемен­тов для выбранной методологии анализа или выбранного программного средства, поддерживающего эту методологию. На­пример, для объектно-ориентированного анализа, выполняе­мого с помощью Rational Rose, использование диаграмм состояний (State Diagram), диаграмм последовательности (Sequence Diagram);

· правила хранения проектно-аналитической документации (ПАД), правила кодирования имен файлов.

Например, всю проектно-аналитическую документацию стандар­та на хранение одна из фирм — разработчиков банковского программного обеспечения разделила на следующие типы документов:

• Постановка задачи;
• Техническое задание;
• Спецификация;
• Аналитическая записка;

• Описание технологий;
• Настройки;
• Консалтинговый документ;
• Маркетинговый документ;
• Нормативный документ;
• Внутренний регламент банка;
• Внешний документ;
• Организационный документ;
• Рабочий документ.

По основным видам документов разрабатываются стандартные шаблоны, документ должен иметь обязательные части, на пример для постановки задачи может использоваться следующий стандартный шаблон:

Шапка.

Наименование постановки, код постановки

Автор, дата создания

Модифицировавший сотрудник, дата модификации

Тело постановки

Первичные данные для постановки:

Описание бизнес-процессов:

Постановка задачи:

Ограничения, допущения

Изменение в структуре данных

Изменение в структуре классов

Основная часть постановки

Приложения

Пример одного из стандартов для хранения проектно-аналитической документации приведен ниже.

Разработка. Стандарты разработки помогают разобраться исходном коде программы, повышают читаемость исходного кода, использование стандартных шаблонов сокращает время разработки программного документа.

Разработка программного обеспечения включает в себя стандарты, которые регламентируют следующее.

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

• Структуру директорий разработки. Регламентирует расположение директорий сборки, директорий исходных текстов, директорий документации, директории базы данных.

• Документирование исходного кода.
• Регламент отладки программы. Использование заглушек, драйверов, отладочного протокола.
• Регламент использования конструкций языка программирова­ния. Правила использования основных структур языка — цик­лов, условных операторов, операторов присваивания, операторов выбора. Например, может содержать запрет некоторых синтаксических особенностей: выход из цикла по оператору бе­зусловного перехода; запрет на использование имен глобаль­ных переменных в подпрограммах. Как правило, данный под­стандарт описывает «правила хорошего тона» — то, что сло­жилось исторически, накоплено с опытом, связано с конкретным языком программирования.
• Визуальный интерфейс. Регламентирует использование элементов интерфейса, их взаимное расположение, выравнивание на экране
• Сообщения, выдаваемые программой. Регламентирует исполь­зование видов сообщений, формирование текста сообщений, использование знаков препинания. Например, данным стандар­том может быть запрещено использование сообщений в исход­ном тексте программы, для этого используется специальный файл сообщений, такой подход облегчает национальную локализацию (перевод интерфейса программы с одного национального о языка на другой).
• Регламент проектирования базы данных.
• Регламент работы с программным обеспечением, используемым при разработке (среда разработки, компиляторы и пр.).
• Регламент программирования отдельных частей программно-I о средства (механизмы настроек, программирования бизнес-транзакций, конверторов данных, многопользовательская работа и методы блокировки пользователей).
• Ведение версий разрабатываемого программного обеспечения.

Тестирование. Стандарты, связанные с тестированием и оцен­ки надежности программных средств, могут включать в себя:

· стандарт на разработку методики тестирования;

· стандарт на разработку и создание карт тестирования;

· регламент проведения нагрузочных испытаний.

В процессе тестирования (особенно при применении методов итого ящика) широко используются внутрифирменные стандарты разработки программного обеспечения.

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