Техническая документация является составляющей проекта по созданию, внедрению, сопровождению, модернизации и ликвидации информационной системы на всем протяжении жизненного цикла.
Комплекс технических документов, который регламентирует деятельность разработчиков, называется нормативно-методическим обеспечением (НМО). В данный комплекс входят:
ü руководящие документы;
ü методики и положения;
ü инструкции и т. д.
Основным назначением технической документации является обеспечение эффективных процедур разработки и использования информационной системы как программного продукта, а также организация обмена между разработчиками и пользователями ИС.
Таким образом, можно выделить следующие функции технической документации:
ü дает описание возможностей системы;
ü обеспечивает фиксацию принятых и реализованных проектных решений;
ü определяет условия функционирования ИС;
ü предоставляет информацию об эксплуатации и обслуживании ИС;
ü регламентирует процедуру защиты информации, регулирует права различных групп пользователей;
Техническая документация. Виды технической документации
ü определяет возможности модернизации системы.
Перед составлением технической документации необходимо иметь ответы на следующие вопросы:
ü что и зачем должно быть документировано?
ü для кого предназначен тот или иной документ?
ü какие ошибки может допустить пользователь и что нужно сделать для их устранения?
ü как и в каких условиях будет использоваться документ?
ü каковы сроки разработки документа?
ü как будет обновляться и поддерживаться документация, каковы механизмы и сроки внесения изменений и пересмотра документов и кто ответственен за реализацию этих действий, а также за хранение, неизменность и контроль за исполнением?
ü кто будет оценивать документ и как он соотносится с отраслевыми или ведомственными требованиями на сертификацию разработки?
Ответы на эти вопросы должны быть получены на ранних стадиях разработки информационной системы и входить в состав разрабатываемой в рамках проекта документации.
Как правило, к технической документации предъявляются следующие основные требования:
ü документы должны быть точными, полными и, по возможности, краткими, иметь четкое и однозначное толкование;
ü документация должна создаваться параллельно с разработкой самой информационной системы;
ü обязанности по документированию системы лежат на ее разработчике;
Исходя из последнего требования к документации, необходимо рассмотреть основные стандарты, которые используются в области информационных систем на территории Российской Федерации.
В настоящее время существует несколько классификаций стандартов на проектирование и разработку информационных (автоматизированных) систем. Классический способ классификации группирует стандарты по двум признакам.
По объекту стандартизации:
ü стандарты на продукты и услуги;
ü стандарты на процессы и технологии.
По предмету стандартизации:
Почему техническая документация — это интересно
ü функциональные стандарты (стандарты на языки программирования, протоколы, интерфейсы);
ü стандарты на организацию жизненного цикла (ЖЦ) автоматизированных систем и программного обеспечения.
Альтернативная классификация группирует стандарты по статусу:
ü официальные стандарты;
ü стандарты «де-факто».
В свою очередь официальные стандарты подразделяются на:
þ международные стандарты (ISO, ANSI, IDEF0/1);
þ стандарты Российской Федерации (ГОСТ);
þ отраслевые стандарты;
þ ведомственные стандарты.
Стандартами «де-факто» являются официально никем не утвержденные, но фактически действующие стандарты.
Как правило, в каждую из этих групп входят документы, существенно разные по степени обязательности для организаций, конкретности и детализации содержащихся требований, открытости и гибкости, а также адаптируемости к конкретным условиям.
Отдельно выделяют корпоративные стандарты.
Для большинства сложных проектов приходится создавать свои комплексы нормативных и методических документов, регламентирующих процессы, этапы, работы и документы конкретных программных продуктов. Такие стандарты называют корпоративными и представляют собой соглашение о единых правилах организации технологии или управления в организации. К таким стандартам относятся:
ü стандарты проектирования;
ü стандарты оформления проектной документации;
ü стандарты пользовательского интерфейса.
Стандарт проектирования должен устанавливать:
þ набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;
þ правила именования объектов, оформления диаграмм, включая требования к форме и размерам объектов и т. д.
þ требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы;
þ правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии, правила проверки проектных решений на непротиворечивость.
Стандарт оформления проектной документации должен устанавливать:
þ комплектность, состав и структуру документации на каждой стадии проектирования;
þ требования к ее оформлению, включая требования к содержанию разделов, подразделов, пунктов, таблиц и т. д.
þ правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;
þ требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;
þ требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.
Стандарт интерфейса пользователя должен устанавливать:
þ правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;
þ правила использования клавиатуры и мыши;
þ правила оформления текстов помощи;
þ перечень стандартных сообщений;
þ правила обработки реакции пользователя.
За основу корпоративных стандартов могут приниматься отраслевые, национальные или международные стандарты. Сюда могут относиться различные методические материалы ведущих фирм-разработчиков ПО, научных центов, фирм-консультантов, консорциумов по стандартизации.
Отечественными стандартами являются стандарты ЕСПД (Единой Системы Программной Документации) серии ГОСТ 19.ХХХ и комплекс стандартов на автоматизированные системы серии ГОСТ 34.ХХХ, созданные в 80-90-е годы двадцатого века. Кроме того, существуют более современные стандарты на программное обеспечение.
Перечень стандартов ГОСТ 19.ХХХ
Единая Система Программной Документации
ü ГОСТ 19.001-77 Общие положения
ü ГОСТ 19.101-77 Виды программ и программных документов
ü ГОСТ 19.102-77 Стадии разработки
ü ГОСТ 19.103-77 Обозначения программ и программных документов
ü ГОСТ 19.104-78 Основные надписи
ü ГОСТ 19.105-78 Общие требования к программным документам
ü ГОСТ 19.106-78 Требования к программным документам, выполненным печатным способом
ü ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению
ü ГОСТ 19.202-78 Спецификация. Требования к содержанию и оформлению
ü ГОСТ 19.301-79 Программа и методика испытаний. Требования к содержанию и оформлению
ü ГОСТ 19.401-78 Текст программы. Требования к содержанию и оформлению
ü ГОСТ 19.402-78 Описание программы
ü ГОСТ 19.403-79 Ведомость держателей подлинников
ü ГОСТ 19.404-79 Пояснительная записка. Требования к содержанию и оформлению
ü ГОСТ 19.501-78 Формуляр. Требования к содержанию и оформлению
ü ГОСТ 19.502-78 Описание применения. Требования к содержанию и оформлению
ü ГОСТ 19.503-79 Руководство системного программиста. Требования к содержанию и оформлению
ü ГОСТ 19.504-79 Руководство программиста. Требования к содержанию и оформлению
ü ГОСТ 19.505-79 Руководство оператора. Требования к содержанию и оформлению
ü ГОСТ 19.506-79 Описание языка. Требования к содержанию и оформлению
ü ГОСТ 19.507-79 Ведомость эксплуатационных документов
ü ГОСТ 19.508-79 Руководство по техническом обслуживанию. Требования к содержанию и оформлению
ü ГОСТ 19.601-78 Общие правила дублирования, учета и хранения
ü ГОСТ 19.602-78 Правила дублирования, учета и хранения программных документов, выполненных печатным способом
ü ГОСТ 19.603-78 Общие правила внесения изменений
ü ГОСТ 19.604-78 Правила внесения изменений в программные документы, выполненных печатным способом
Стандарты ЕСПД практически не имеют содержательной составляющей и дают формальные требования к составу, содержанию и оформлению документов, описывающих программу на разных стадиях ее жизненного цикла.
Комплекс ГОСТ 34 задумывался как всеобъемлющий комплекс взаимоувязанных межотраслевых документов и рассчитанный на взаимодействие заказчика и разработчика. Он должен был разрешить проблему «вавилонской башни», при которой в различных отраслях и областях деятельности использовалась плохо согласованная или несогласованная нормативно-техническая документация. Объектами стандартизации являются автоматизированные системы различных видов и все виды их компонентов, а не только программное обеспечение и базы данных. Комплекс рассчитан на взаимодействие заказчика и разработчика, при этом в нем предусмотрено, что заказчик может разрабатывать систему для себя сам.
Перечень стандартов ГОСТ 34.ХХХ
Стандарты информационной технологии
ü ГОСТ 34.003-90 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения
ü ГОСТ 34.201-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании автоматизированных систем
ü ГОСТ 34.320-96 Информационные технологии (ИТ). Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы
ü ГОСТ 34.321-96 Информационные технологии (ИТ). Система стандартов по базам данных. Эталонная модель управления данными
ü ГОСТ 34.601-90 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания
ü ГОСТ 34.602-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
ü ГОСТ 34.603-92 Информационная технология (ИТ). Виды испытаний автоматизированных систем
ü РД 50-34.698-90 Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов
Многие авторы считают эти стандарты морально устаревшими, однако ими продолжают активно пользоваться при оформлении проектной документации. Если разрабатывается документация на программу (систему), созданную под конкретную организацию, следует воспользоваться требованиями ГОСТов 34. Если разрабатывается документация на программу массового применения, то следует использовать ГОСТы серии 19.
Если говорить о более поздних отечественных стандартах, следует выделить ГОСТ Р 51904-2002 Программное обеспечение встроенных систем. Общие требования к разработке и документированию, который был разработан Государственным научно-исследовательским институтом авиационных систем с участием Научно-исследовательского института стандартизации и унификации.
Данный стандарт распространяется на процессы разработки и документирования программного обеспечения встроенных систем реального времени и все действия, имеющие отношение к разработке программного обеспечения. Стандарт подготовлен в развитие ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств, о котором пойдет речь в п. 2.3.
Отдельно стандарт ГОСТ Р 51904-2002 в части подготовки документов будет рассмотрен в главе 9 «Программное обеспечение».
Международные стандарты применяются для разработки документации международного уровня. Как правило, они не бесплатные, так как разрабатываются не государственными организациями, но, в отличие от отечественных, разработаны недавно.
В основе практически всех современных промышленных технологий создания программных средств лежит международный стандарт ISO/IEC 12207 Information technology. System and software engineering. Software life cycle processes (ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств).
Первая редакция стандарта ISO/IEC 12207 была опубликована в августе 1995 г. и явилась первым международным стандартом, содержавшим представительный набор процессов жизненного цикла в отношении программного обеспечения, которое рассматривалось как часть большой системы, а также применительно к программным продуктам и услугам. Стандарт определяет процессы, виды деятельности и задачи, которые используются при приобретении программного продукта или услуги, а также при поставке, разработке, применении по назначению, сопровождении и прекращении применения программных продуктов.
Основными характеристиками данного стандарта являются:
ü динамичность: один процесс при необходимости вызывает другой или его часть, что позволяет реализовать любую модель жизненного цикла;
ü адаптивность: стандарт предусматривает исключение процессов, видов деятельности и задач, неприменимых в конкретном проекте.
Кроме того, существуют международные стандарты (на английском языке), которые направлены на написание документации:
1. IEEE Std 1063-2001 «IEEE Standard for Software User Documentation» – стандарт для написания руководства пользователя. В документе обозначены требования к структуре, содержимому и формату инструкций пользователя.
2. IEEE Std 1016-1998 «IEEE Recommended Practice for Software Design Descriptions» – стандарт для написания технического описания программы. Представлены рекомендации к документам, описывающим архитектуру программного обеспечения.
3. ISO/IEC FDIS 18019:2004 «Guidelines for the design and preparation of user documentation for application software» – стандарт для написания руководства пользователя. В данном документе есть большое количество примеров. Также в приложениях есть чек-листы «что не забыть сделать в процессе разработки документации» и «что должно быть».
Документ особенно полезен начинающим специалистам.
4. ISO/IEC 26514:2008 «Requirements for designers and developers of user documentation» – стандарт для дизайнеров и разработчиков пользователей документации.
Международных стандартов довольно много, в каждой стране они свои, так как один и тот же стандарт не всегда может подойти и европейским, и азиатским компаниям.
Источник: mti58.ru
Техническая документация в разработке ПО: кто, зачем, когда и как описывает проект
Привет! Меня зовут Даша Григорьева, я технический писатель в компании 65apps. Мы занимаемся разработкой сложных мобильных решений, и моя задача — подготовка технической документации по проектам. Очень часто роль технического писателя бывает недооцененной в компании (не у нас, конечно). Поэтому я хочу рассказать, зачем компании-разработчику нужен такой специалист, что такое технический проект, чем он отличается от ТЗ и почему это все необходимо для разработки мобильного приложения.
Общаясь с большим количеством компаний, я все еще встречаю твердое убеждение в том, что написание технического задания для разработки ПО — пустая трата времени и денег. Мы в 65apps считаем иначе. Поэтому приведу несколько аргументов в пользу технической документации и расскажу, кто и как ее пишет.
Техническая документация позволяет оценить стоимость разработки и согласовать функциональность будущей системы. При возникновении споров о стоимости и сроках разработки той или иной фичи она может стать определенной гарантией для заказчика. С другой стороны, если возникнет потребность в развитии приложения, документация облегчит процесс доработки и даст четкое понимание, возможно ли встроить новую функциональность в существующую систему.
Другой пример — государственные организации или организации, чья деятельность ограничивается или подчиняется законам и надзорным органам. Они обязаны осуществлять разработку ПО по всем правилам и с соблюдением всех стандартов. В таких проектах техническая документация, подготовленная по ГОСТам, — необходимое условие.
И разумеется, грамотно составленная и актуальная документация необходима для того, чтобы каждый участник в процессе разработки мог обращаться к документам, если возникают вопросы по конкретной задаче или по всей системе в целом.
Техническое задание и технический проект — два разных документа. Техническое задание отвечает на вопрос «что нужно сделать?», его составляет аналитик в самом начале проекта. Технический проект разрабатывает технический писатель. Этот документ создается после ТЗ и отвечает на вопрос «как нужно делать?».
Кто пишет техническую документацию
Обычно разработкой ТЗ занимается аналитик. Именно он общается с заказчиком / заинтересованным лицом и выявляет у него требования. В сложных случаях к процессу можно привлечь менеджера проекта, разработчиков, тестировщиков и других специалистов. Чем сложнее проект — тем больше требований к документации.
Серьезные заказчики из крупных корпораций и госсектора требуют составлять документацию в соответствии с ГОСТами, а это задача очень трудоемкая, требующая внимательности к деталям и постоянной вовлеченности в процесс. И это не только ТЗ, но и технический проект, полностью описывающий все используемые в разработке решения, подходы и методологии. На него также распространяются ГОСТы. Подготовкой такой документации должен заниматься специалист — технический писатель.
Для крупных проектов иметь в штате технического писателя просто необходимо. Разработка решений для крупных заказчиков может длиться год и более, это довольно долгий срок. За это время возникает достаточное количество изменений, провоцирующих обновление документации. Кроме того, любая долгосрочная разработка ПО предполагает развитие. В этом случае актуальная техническая документация позволит снизить риски, закладываемые в работу исполнителей.
Исключение может быть сделано для представителей госсектора. Таким организациям необязательно иметь в своем штате специалистов соответствующего профиля, так как при возникновении необходимости всегда можно обратиться к профессионалам, которые выполнят качественно свою работу.
Кто такой технический писатель
Строго сформулированного перечня должностных обязанностей технического писателя не существует: каждая компания формирует его сама, а иногда возлагает на такого специалиста и дополнительные задачи. Поэтому иногда бывает сложно даже определить род деятельности технического писателя. В нашей компании такой специалист составляет документацию, необходимую для дальнейшей разработки программного обеспечения.
Для этого он собирает информацию и материалы от участников проекта и документирует эти данные согласно требованиям заказчика, в том числе и в соответствии с ГОСТами. Речь идет о ГОСТ 19 «Единая система программной документации» и ГОСТ 34 «Информационная технология. Комплекс стандартов на автоматизированные системы». Также технический писатель следит за актуальностью технической информации, если это необходимо на длительных и сложных проектах.
Какая техническая документация нужна разработчику
Рассмотрим идеальный с точки зрения ГОСТа процесс разработки системы.
Все начинается с требований заказчика или заинтересованных лиц, которые необходимо выявить и обязательно зафиксировать в документе «Техническое задание».
Техническое задание — это документ, регламентирующий бизнес-цели, общее описание системы, объем работ, границы проекта, а также порядок разработки, оценки и приемки. Данный документ отвечает нам на вопрос «что нужно сделать?» и фактически является постановкой задачи.
Аналитик составляет ТЗ и согласует его со всеми заинтересованными сторонами. После того как собраны и утверждены все требования, можно приступать к созданию прототипов будущей системы и разработке программного обеспечения.
На этом этапе начинается разработка макетов, сценариев, архитектуры и др. Раз уж мы говорим об эталонном процессе разработки, то все это должно быть описано в техническом проекте, который также использует часть информации из ТЗ.
Технический проект — это совокупность документов, описывающих и обосновывающих все подходы, методы, архитектурные и технические решения, применяемые для создания системы. Например, в технический проект включают макеты интерфейсов, описание протоколов для интеграции со смежными системами и оборудованием, пользовательские сценарии, описание алгоритма и их формирование, структура серверов и баз данных, а также другие требования к системе и ее взаимодействию с другими внешними системами.
это далеко не все: существует много стандартов для написания технической документации, и для каждой страны они свои. В отечественных стандартах есть отдельно ГОСТ на создание автоматизированных работ и на программное изделие. Например, технический проект по ГОСТу 19 «Единая система программной документации» может включать в себя следующий перечень работ:
- уточнение структуры входных и выходных данных,
- разработка алгоритма решения задачи,
- определение формы представления входных и выходных данных,
- определение семантики и синтаксиса языка,
- разработка структуры программы,
- окончательное определение конфигурации технических средств,
- разработка плана мероприятий по разработке и внедрению программ,
- разработка пояснительной записки,
- согласование и утверждение технического проекта.
Теперь, когда есть четкое понимание архитектуры, функциональности и дизайна проекта, можно перейти к разработке системы и ее тестированию.
На этапе тестирования, помимо проверки работоспособности системы, проверяется также выполнение всех требований, зафиксированных в документах, что позволяет разрешить спорные ситуации с заказчиком.
Когда составлять техническую документацию
Выше я описала идеальный процесс создания программного обеспечения, но иногда некоторые документы технического проекта составляют уже после этапа разработки.
Есть проекты, в которых важно иметь полную документацию до начала работ. Это касается решений с высокими требованиями к безопасности, соблюдению законодательства и т. д. Например, мобильные приложения для банков. В этом случае важно сначала продумать все детали системы (информационная безопасность клиентов и самого банка, соответствие законам). На это уйдет больше времени, но позволит избежать финансовых и репутационных рисков.
Если разработка идет по методологии Agile, то нет смысла прописывать всю документацию до старта работ. Если заказчику важно работать по спринтам и контролировать ход разработки, документацию можно дописывать параллельно основному процессу.
В нашей компании возможны оба варианта — мы умеем адаптироваться под условия и пожелания заказчика.
На сегодняшний день технический писатель не самая распространенная специальность, но для серьезной компании-разработчика такой сотрудник не менее важен, чем, например, аналитик.
Техническая документация обязательно разрабатывается для госзаказчиков, она необходима и для долгосрочных проектов, на которых с бОльшей вероятностью могут меняться подрядчики. Имеет смысл создавать технический проект для ноу-хау технологий и проектов высокой сложности — документация понадобится отделу QA, чтобы отличить баги и фич.
- технический писатель
- техническое задание
- техническая документация
- Управление разработкой
- Подготовка технической документации
Источник: habr.com
Оформление программной документации
Пожалуй, самым неприятным и тяжелым
этапом программистской работы является создание
программной документации.
К сожалению, обычно этому либо не учат
совсем, либо, в лучшем случае, не обращают на
качество
получаемых
документов
должного
внимания. Тем не менее, владение этим
искусством
является
зачастую
одним
из
важнейших фактором, определяющим качество
программиста.
4.
Во-первых, умение создавать программную
документацию определяет профессиональный уровень
программиста.
Заказчик не будет вникать в тонкости и
особенности даже самой замечательной программы.
Заказчик будет сначала читать документацию.
Большую роль играет в этом и психологический
фактор. В частности, во всем мире ценилась (и
ценится
сейчас)
былая
советская
школа
программирования. Современные же отечественные
программисты котироваться перестали. Класс не тот.
Нынче
программы
уже
не
пишутся,
а составляются (а это — «две большие разницы»).
5.
Созданный в «классическом» стиле пакет
программной документации (далее – ПД) создаст у
вашего заказчика или работодателя самое что ни на
есть благоприятное впечатление. Тем более, если автор
ПД будет избегать фраз вида «кликните на
скроллбар…», «винт» и т.п.
К сожалению, за подобной жаргонной трескотней
обычно скрывается либо скудость мыслей, либо полная
пустота (неизгладимое впечатление произвел на автора
рассказ одного его знакомого о неком «геймере»,
который с кем-то там то ли «чатился», то ли
«модераторством» занимался или что-то в этом роде.).
Язык ПД – это своего рода бюрократический, весьма
консервативный язык.
Появилась даже особая специальность – технический
писатель, т.е. человек, умеющий создавать программную
документацию
6.
Во-вторых, грамотно составленный (точнее, созданный)
пакет ПД избавит вас от многих неприятностей. В частности,
избавиться от назойливых вопросов и необоснованных
претензий
можно
просто
отослав
пользователя
к
документации.
Это касается прежде всего важнейшего
.
документа – Технического задания. Можно напомнить о
многомиллионном иске к компании IBM. Этот иск предъявило
одно крупное издательство, неудовлетворенное качеством ВТ и
программного обеспечения. IBM суд выиграла. И выиграла
только благодаря тому, что предъявила подписанное обеими
сторонами Техническое задание. Было это давно, еще в 70-х гг.,
однако сути дела это не меняет.
7.
Важно создать первый пакет ПД. Этого будет
достаточно, чтобы на его основе строить все последующие,
используя его как образец или шаблон. Но сделать это надо
очень качественно. Не спеша. Очень основательно.
Для начала необходимо вооружиться ГОСТами. ГОСТ
определяет все. В частности, в него входит и интересующая
нас Единая система программной документации (ЕСПД).
Пожалуй, самое сложное – это достать сам ГОСТ. ГОСТ
должен быть только в печатном оригинальном виде.
Продаются они (по крайней мере, так было раньше) в
специальных магазинах.
И никаких цитат и вторичных источников. ГОСТ – это
закон. И тем более, никаких Интернетов (представьте себе суд,
выносящий приговор, пользуясь распечаткой Уголовного
Кодекса, скачанного с какого-нибудь сайта). Не верьте никому,
кроме оригинала.
8. ТЕХНИЧЕСКОЕ ЗАДАНИЕ (ГОСТ 19.201-78)
Согласно ГОСТу, настоящий стандарт (переизданный в
ноябре 1987 г.) устанавливает порядок построения и
оформления технического задания на разработку программы
или программного изделия для вычислительных машин,
комплексов и систем независимо от их назначения и области
применения.
Надо быть предельно внимательным и осторожным,
создавая его, т.к. зачастую умело (и грамотно) составленное ТЗ
определяет успех всей работы. Именно ТЗ согласовывается с
Заказчиком, который обычно стремится внести как можно
больше противоречивых и завышенных требований. Задача же
Исполнителя – наоборот, облегчить себе жизнь.
9. ОБЩИЕ ПОЛОЖЕНИЯ
10.
разделе
Наименование
и
область
применения
указывают
наименование,
краткую
характеристику области применения программы или
программного изделия и объекта, в котором используют
программу или программное изделие.
В
В разделе Основание для разработки должны быть
указаны:
документ (документы), на основании которых ведется
разработка;
организация, утвердившая этот документ, и дата его
утверждения;
наименование и (или) условное обозначение темы разработки.
Применительно к специфике учебного процесса
основанием может служить задание на курсовое
проектирование, приказ по институту от __.__. за N ___.,
договор __.__. за N ___., и т.п.
11.
В разделе Назначение разработки должно быть указано
функциональное и эксплуатационное назначение программы
или программного изделия. Ограничиться здесь можно однойдвумя фразами. Главное – четко определить, для чего нужна
эта программа.
Например: Программа представляет собой ядро
автоматизированного рабочего места (АРМ) разработчика
непрерывных линейных систем автоматического управления
(САУ), позволяющее пользователю решать задачи анализа
простых моделей.
12.
Раздел Технические требования к программе или
программному изделию должен содержать следующие
подразделы:
требования к функциональным характеристикам;
требования к надежности;
условия эксплуатации;
требования к составу и параметрам технических средств;
требования к информационной и программной совместимости;
требования к маркировке и упаковке;
требования к транспортированию и хранению;
специальные требования.
Иными
словами,
здесь
начинается
конкретика.
Описывается то, что должна делать программа и как она
должна выглядеть.
13.
Требования к функциональным характеристикам.
Здесь должны быть указаны требования к составу
выполняемых функций, организации входных и выходных
данных, временным характеристикам и т.п.
Например: Программа должна
вычислять … строить… создавать …
позволять
…
Исходные данные : текстовый файл с заданной …
Выходные данные : графическая и текстовая
информация — результаты анализа системы…; текстовые
файлы — отчеты о … диагностика состояния системы и
сообщения о всех возникших ошибках.
14.
Требования к надежности.
Должны быть указаны требования к обеспечению
надежного функционирования (обеспечение устойчивого
функционирования, контроль входной и выходной
информации, время восстановления после отказа и т.п.).
Здесь «выгадать» что-то сложно. В лучшем случае может
пройти вариант, при котором ваша программа работает
только с абсолютно корректными данными. Обычно
Заказчик на это не идет, но попробовать можно.
Например: Программа должна работать с заданной
расширенной матрицей инциденций исследуемого графа в
соответствии с алгоритмом функционирования, выдавать
сообщения об ошибках при неверно заданных исходных
данных , поддерживать диалоговый режим в рамках
предоставляемых пользователю возможностей.
15.
Условия эксплуатации.
Должны быть указаны условия эксплуатации (температура
окружающего воздуха, относительная влажность и т.п. для
выбранных типов носителей данных), при которых должны
обеспечиваться заданные характеристики, а также вид
обслуживания, необходимое количество и квалификация
персонала.
С этим пунктом сложностей обычно не возникает. К
сожалению, пункт о профессиональности пользователя Заказчиком
подразумевается обязательно. Это, конечно, лишний повод
придраться к вашей программе. Впрочем, здесь можно
ограничиться фразами вида «Условия эксплуатации программы
совпадают с условиями эксплуатации ПЭВМ IBM PC и
совместимых с ними ПК», «Программа должная быть рассчитана
на непрофессионального пользователя.» и т.п.
16.
Требования к составу и параметрам технических
средств.
Указывают необходимый состав технических средств с
указанием их технических характеристик.
Здесь главное – ничего не забыть и все предусмотреть,
с одной стороны (а то подсунут какой-нибудь IBM PC/XT с
монохромным дисплеем и без мыши), а с другой – не
переборщить с повышенными требованиями, иначе Заказчик
найдет более покладистого Исполнителя.
Например: Необходимо наличие IBM PC совместимого ПК с графическим адаптером EGA (VGA).
Необходимое дисковое пространство – не менее 600 Кб,
объем свободной оперативной памяти — не менее 400 Кб.
Желательно наличие драйвера EMS и манипулятора типа
«мышь».
17.
Требования
совместимости.
к
информационной
и
программной
Особенности те же, что и в предыдущем пункте. Здесь
должны быть указаны требования к информационным
структурам на входе и выходе и методам решения, исходным
кодам, языкам программирования. При необходимости
должна обеспечиваться защита информации и программ.
Например: Программа должна работать автономно
под управлением ОС MS DOS версии не ниже 3.3. Базовый
язык программирования — Turbo Pascal 6.0.
18.
Требования к маркировке и упаковке и требования к
транспортированию
и
хранению
являются
достаточно
экзотическими. В общем случае здесь указывают требования к
маркировке программного изделия, варианты и способы упаковки.
А в требованиях к транспортированию и хранению должны быть
указаны для программного изделия условия транспортирования,
места хранения, условия хранения, условия складирования, сроки
хранения в различных условиях.
Специальные требования – это весьма ответственная вещь. Их
лучше, по возможности, всячески избегать. И заявить об этом сразу.
Например:
Специальных
требований
к
временным
характеристикам программы не предъявляется. Специальных
требований к емкостным характеристикам программы не
предъявляется.
19.
Технико-экономические показатели. Этот самый сложный
для программиста пункт есть далеко не всегда. Он нужен прежде
всего тогда, когда вашей целью является обоснование огромной
эффективности и важности выполняемой работы. На Заказчика
этот пункт действует, обычно, очень хорошо. По крайне мере, это
лучшее обоснование сроков и денежных сумм разработки.
В этом разделе должны быть указаны: ориентировочная
экономическая
эффективность,
предполагаемая
годовая
потребность (например: предполагаемое число обращений к
комплексу в целом в год — 365 сеансов работы), экономические
преимущества
разработки
по
сравнению
с
лучшими
отечественными и зарубежными образцами или аналогами.
Помимо этого, желательно привести определение как
сметной стоимости разработки программы, так и определение
трудоемкости программирования.
20.
21.
В разделе Порядок контроля и приемки должны
быть указаны виды испытаний и общие требования к
приемке работы. Если возможно, то в этом пункте укажите,
что «контроль и приемка разработки осуществляются на
предоставляемой Заказчиком технике», иначе вас могут
обязать принести технику с собой.
Например: Контроль и приемка разработки
осуществляются на основе испытаний контрольноотладочных примеров. При этом проверяется выполнение
всех функций программы.
22.
В Приложениях к техническому заданию, при
необходимости, приводят:
перечень научно-исследовательских и других
работ, обосновывающих разработку;
схемы
алгоритмов,
таблицы,
описания,
обоснования, расчеты и другие документы, которые
могут быть использованы при разработке;
другие источники разработки.
23. ТЕКСТ ПРОГРАММЫ (ГОСТ 19.401-78)
Требования к оформлению текста программы достаточно
просты и естественны для грамотного программиста. Основное,
чем требуется руководствоваться при создании этого документа –
это то, что текст программы должен быть удобочитаемым.
По-прежнему
обязательным
является
составление
информационной части — аннотации и содержания.
Основная часть документа должна состоять из текстов одного
или нескольких разделов, которым даны наименования.
Текст каждого программного файла начинается с «шапки», в
которой указывается:
o
наименование программы,
o
автор,
o
дата создания программы,
o
номер версии,
o
дата последней модификации.
24.
Обязательными являются комментарии, а также
строгое соблюдение правил отступа. Помните,
оправдать
можно
даже
неумение
создавать
программную документацию. А некрасивый текст
программы – никогда. Ссылки на то, что этот текст
понятен самому автору всерьез не воспринимаются.
Тексты программ должно быть не стыдно давать читать
другим людям.
25. ПРОГРАММА И МЕТОДИКА ИСПЫТАНИЙ (ГОСТ 19.301-79)
В этом документе содержится описание того, что и
как необходимо сделать, чтобы убедиться (и убедить
Заказчика) в правильности работы программы.
Фактически, этот документ является определяющим
для приемо-сдаточных испытаний.
Грамотно составленная программа и методика
испытаний – это залог подписания акта сдачиприемки, т.е. того, во имя чего вы потратили столько
сил и времени.
26.
Формально этот ГОСТ используется для
разработки
документов
планирования
и
проведения испытательных работ по оценке
готовности и качества программной системы.
Документ содержит описание объекта и цели
испытаний, требования к программе и к
программной документации, средства и порядок
испытаний,
а
также
описание
тестовых
примеров.
27.
Составные части этого документа проще и нагляднее
описывать сразу в виде примеров.
Объект испытаний
Пример: Объектом испытаний является программа
…, предназначенная для …
Цель испытаний
Пример: Проверка надежности функционирования
программы.
Требования к программе
Пример: Функционирование программы не должно
приводить к сбою (фатальному нарушению работы
системы). Организация диалога должна
предусматривать защиту от ввода некорректных
данных. Программа должна выдавать диагностику
состояния системы и сообщения о любых возникших
ошибках … и т.п.
28.
Требования к программной документации
Пример: Состав программной документации,
предъявляемой на испытании:
описание программы (ГОСТ 19.402-78);
программа и методика испытаний (ГОСТ 19.301-79);
текст программы (ГОСТ 19.401-78).
29.
Средства и порядок испытаний
Пример: Программа работает в соответствии с
условиями эксплуатации ОС MS DOS (версия не ниже
3.0) на ПК типа IBM PC/AT, а также на совместимых
с ним. Для работы необходим также адаптер EGA
(VGA).
Порядок проведения испытаний:
Запуск программы осуществляется ….
Выбирается …
Нажимается …
Последовательно выбираются …
Тестовые примеры
Пример: Для проведения испытаний предлагаются …,
описание которых содержатся в файлах …Содержимое
тестовых файлов и результаты работы программы
приведены в Приложении 1.
Источник: ppt-online.org