Учебное пособие по выполнению и оформлению курсовых, дипломных и квалификационных работ москва 2002 2 аннотация
 Скачать 0.53 Mb.
|
|
Московский государственный технический университет им. Н.Э. Баумана Факультет Информатики и систем управления Кафедра Компьютерные системы и сети Г.С. Иванова, Т.Н. Ничушкина Проектирование программного обеспечения Учебное пособие по выполнению и оформлению курсовых, дипломных и квалификационных работ МОСКВА 2002 2 АННОТАЦИЯ Настоящее учебное пособие содержит указания и рекомендации по выполнению и оформлению курсовых и квалификационных работ, связанных с разработкой про- граммных продуктов. В пособии описываются порядок выполнения, оформления и требования к представляемым документам. Особое внимание обращено на оформле- ние текстовых и графических документов: технического задания, расчетно- пояснительной записки и плакатов. В приложении приводятся примеры технического задания и оглавления расчетно-пояснительной записки. Пособие предназначено для студентов всех курсов специальности «Компьютер- ные системы и сети». 3 Оглавление ВВЕДЕНИЕ........................................................................................................................................................... 4 1. ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ .......................................................... 4 2. ПОСТАНОВКА ЗАДАЧИ. РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ ..................................... 8 3. АНАЛИЗ ТРЕБОВАНИЙ И ОПРЕДЕЛЕНИЕ СПЕЦИФИКАЦИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ СТРУКТУРНОМ ПОДХОДЕ ............................................................................... 11 3.1. С ПЕЦИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ СТРУКТУРНОМ ПОДХОДЕ ................................. 11 3.2. Д ИАГРАММА ПЕРЕХОДОВ СОСТОЯНИЙ ................................................................................................. 13 3.3. Ф УНКЦИОНАЛЬНЫЕ ДИАГРАММЫ ......................................................................................................... 15 3.4. Д ИАГРАММЫ ПОТОКОВ ДАННЫХ .......................................................................................................... 17 3.5. Д ИАГРАММЫ ОТНОШЕНИЙ КОМПОНЕНТОВ ДАННЫХ ............................................................................ 21 4. ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ СТРУКТУРНОМ ПОДХОДЕ .......................................................................................................................................................... 27 4.1. Р АЗРАБОТКА СТРУКТУРНОЙ И ФУНКЦИОНАЛЬНОЙ СХЕМ ..................................................................... 27 4.2. И СПОЛЬЗОВАНИЕ МЕТОДА ПОШАГОВОЙ ДЕТАЛИЗАЦИИ ДЛЯ ПРОЕКТИРОВАНИЯ СТРУКТУРЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ........................................................................................................................ 28 4.3. С ТРУКТУРНЫЕ КАРТЫ К ОНСТАНТАЙНА ................................................................................................ 32 5. АНАЛИЗ ТРЕБОВАНИЙ И ОПРЕДЕЛЕНИЕ СПЕЦИФИКАЦИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ ОБЪЕКТНОМ ПОДХОДЕ .................................................................................... 34 5.1. UML – СТАНДАРТНЫЙ ЯЗЫК ОПИСАНИЯ РАЗРАБОТКИ ПРОГРАММНЫХ ПРОДУКТОВ С ИСПОЛЬЗОВАНИЕ ОБЪЕКТНОГО ПОДХОДА ..................................................................................................................................... 34 5.2. О ПРЕДЕЛЕНИЕ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ ....................................................................................... 35 5.3. П ОСТРОЕНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ ..................................................... 40 5.4. О ПИСАНИЕ ПОВЕДЕНИЯ С ИСТЕМНЫЕ СОБЫТИЯ И ОПЕРАЦИИ ............................................................ 44 6. ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ ОБЪЕКТНОМ ПОДХОДЕ47 6.1. Р АЗРАБОТКА СТРУКТУРЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ ОБЪЕКТНОМ ПОДХОДЕ ........................ 47 6.2. О ПРЕДЕЛЕНИЕ ОТНОШЕНИЙ МЕЖДУ ОБЪЕКТАМИ ................................................................................. 49 6.3. У ТОЧНЕНИЕ ОТНОШЕНИЙ КЛАССОВ ...................................................................................................... 52 6.4. П РОЕКТИРОВАНИЕ КЛАССОВ ................................................................................................................. 55 6.5. К ОМПОНОВКА ПРОГРАММНЫХ КОМПОНЕНТОВ .................................................................................... 59 6.6. П РОЕКТИРОВАНИЕ РАЗМЕЩЕНИЯ ПРОГРАММНЫХ КОМПОНЕНТОВ ДЛЯ РАСПРЕДЕЛЕННЫХ ПРОГРАММНЫХ СИСТЕМ .................................................................................................................................... 60 7. ПРАВИЛА ОФОРМЛЕНИЯ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ ....................................................... 61 7.1. О ФОРМЛЕНИЕ ТЕКСТОВОГО И ГРАФИЧЕСКОГО МАТЕРИАЛА ................................................................. 61 7.2. О ФОРМЛЕНИЕ РИСУНКОВ , СХЕМ АЛГОРИТМОВ , ТАБЛИЦ И ФОРМУЛ .................................................... 62 7.3. О ФОРМЛЕНИЕ ТЕКСТОВ ПРОГРАММ ...................................................................................................... 64 7.4. О ФОРМЛЕНИЕ ПРИЛОЖЕНИЙ ................................................................................................................. 65 7.5. О ФОРМЛЕНИЕ СПИСКА ЛИТЕРАТУРЫ .................................................................................................... 65 СПИСОК ЛИТЕРАТУРЫ ............................................................................................................................... 66 ПРИЛОЖЕНИЕ 1. ТИТУЛЬНЫЙ ЛИСТ И ПРИМЕР ТЕХНИЧЕСКОГО ЗАДАНИЯ ..................... 67 ПРИЛОЖЕНИЕ 2. ТИТУЛЬНЫЙ ЛИСТ РАСЧЕТНО-ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ................ 71 ПРИЛОЖЕНИЕ 3. ПРИМЕРЫ СОДЕРЖАНИЯ РАСЧЕТНО-ПОЯСНИТЕЛЬНЫХ ЗАПИСОК... 72 4 ВВЕДЕНИЕ Создание современной программной системы – весьма трудоемкая задача: обыч- ный размер ПО превышает сотни тысяч операторов. Для эффективного создания по- добных программных продуктов специалист должен иметь представление о методах анализа, проектирования, реализации и тестирования программных систем; ориентиро- ваться в существующих подходах и технологиях. Проектирование программных продуктов, как и любых других сложных систем, выполняется поэтапно с использованием блочно-иерархического подхода, который подразумевает разработку продукта по частям с последующей сборкой. На каждом эта- пе выполняются определенные проектные операции, которые соответствующим обра- зом документируются. Последовательность выполнения этапов и их результаты непо- средственно следуют из используемой модели жизненного цикла программного обес- печения (ПО). Кроме того, реализованная система также должна сопровождаться разного рода программной документацией, например, спецификацией, руководством программиста, руководством пользователя, руководством оператора. Таким образом, владение навы- ками создания программной документации, безусловно, необходимо будущему разра- ботчику ПО. 1. ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Жизненным циклом ПО называют период от момента появления идеи создания не- которого ПО до момента завершения его поддержки фирмой-разработчиком или фир- мой, выполнявшей сопровождение. Состав процессов жизненного цикла регламентируется международным стандар- том ISO/IEC 12207: 1995 «Information Technology – Software Life Cycle Process» («Ин- формационные технологии – Процессы жизненного цикла ПО»). ISO – International Organization of Standardization – Международная организация по стандартизации, IEC – International Electrotechnical Commission – Международная комиссия по электротехни- ке. Этот стандарт только называет и определяет процессы жизненного цикла, не кон- кретизируя в деталях, как реализовывать или выполнять действия и задачи, включен- ные в эти процессы. При этом процесс жизненного цикла определяется как совокуп- ность взаимосвязанных действий, преобразующих некоторые входные данные в выход- 5 ные. Каждый процесс характеризуется определенными задачами и методами их реше- ния, а также исходными данными и результатами. Так в соответствии со стандартом все процессы делятся на три группы: * основные процессы (приобретение, поставка, разработка, эксплуатация, сопрово- ждение); * вспомогательные процессы; обеспечивают выполнение основных процессов (до- кументирование, управление конфигурацией, обеспечение качества, верификация, ат- тестация, оценка, аудит); * организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение жизненного цикла ПО, обучение). Указанные действия можно условно сгруппировать, выделив следующие основные этапы (в скобках указаны соответствующие стадии разработки по ГОСТ 19.102–77 «Стадии разработки»): • постановка задачи (стадия «Техническое задание»); • анализ требований и разработка спецификаций (стадия «Эскизный проект»); • проектирование (стадия «Технический проект»); • реализация (стадия «Технический проект»). Постановка задачи. В процессе постановки задачи четко формулируют назначе- ние ПО и определяют основные функциональные, эксплуатационные и технологиче- ские требования к нему. Функциональные требования определяют функции разрабаты- ваемого ПО, эксплуатационные – особенности его эксплуатации, а технологические – особенности процесса разработки: подход, архитектуру, технологию, среду или язык программирования. Требования к ПО, имеющему прототипы, обычно выполняют по аналогии, учиты- вая структуру и характеристики уже существующих программных продуктов. Для формулирования требований к ПО, не имеющему аналогов, иногда необходимо провес- ти специальные исследования, называемые предпроектными. В процессе таких иссле- дований определяют разрешимость задачи, возможно, разрабатывают методы ее реше- ния (если они новые) и устанавливают наиболее существенные характеристики разра- батываемого ПО. Обычно этап постановки задачи заканчивается разработкой техниче- ского задания. Анализ требований и определение спецификаций. Спецификациями называют точное формализованное описание функций и ограничений разрабатываемого ПО. Со- 6 ответственно различают функциональные и эксплуатационные спецификации. Сово- купность спецификаций представляет собой общую логическую модель проектируемо- го ПО. Для получения спецификаций выполняют анализ требований технического зада- ния, формулируют содержательную постановку задачи, выбирают математический ап- парат формализации, строят модель предметной области, определяют подзадачи и вы- бирают или разрабатывают методы их решения. Часть спецификаций может быть опре- делена в процессе предпроектных исследований и, соответственно, зафиксирована в техническом задании. На этапе также целесообразно сформировать тесты для поиска ошибок в проекти- руемом ПО, обязательно указав ожидаемые результаты. Проектирование. Задачей этого этапаявляется определение подробных специфи- каций разрабатываемого ПО. Процесс проектирование сложного ПО обычно включает: * проектирование общей структуры – определение основных частей (компонентов) и их взаимосвязей по управлению и данным; * декомпозицию компонентов и построение структурных иерархий в соответствии с рекомендациями блочно-иерархического подхода; * проектирование компонентов. Результатом проектирования является детальная модель разрабатываемого ПО вместе со спецификациями его компонентов всех уровней. Тип модели зависит от вы- бранного или заданного подхода (структурный, объектно-ориентированный или ком- понентный) и конкретной технологии проектирования. Однако в любом случае процесс проектирования охватывает как проектирование обрабатывающих программ (подпро- грамм) и определение взаимосвязей между ними, так и проектирование данных, с кото- рыми взаимодействуют эти программы или подпрограммы. Принято различать также два аспекта проектирования: * л о г и ч е с к о е п р о е к т и р о в а н и е , включающее те проектные операции, кото- рые непосредственно не зависят от имеющихся технических и программных средств, составляющих среду функционирования будущего программного продукта; * ф и з и ч е с к о е п р о е к т и р о в а н и е , котороезаключается впривязке к конкрет- ным техническим и программным средствам среды функционирования. 7 Реализация.Реализация представляет собой процесс поэтапного написания кодов программы на выбранном языке программирования (кодирование), их тестирование и отладку. Сопровождение. Сопровождение– это процессвыпуска и внедрения новых версий программного продукта. Причинами выпуска новых версий могут служить: * необходимость исправления ошибок, выявленных в процессе эксплуатации пре- дыдущих версий; * необходимость совершенствования предыдущих версий, например, улучшения интерфейса или расширения состава выполняемых функций; * изменение среды функционирования, например, появление новых технических средств и/или программных продуктов. На этом этапе в программный продукт вносят необходимые изменения, которые могут потребовать пересмотра проектных решений, принятых на любом этапе. В настоящее время при разработке ПО в основном используется спиральная схема (рис. 1.1), согласно которой программный продукт создается не сразу, а итерационно с использованием прототипов. Прототипом называют действующий программный про- дукт, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО. При использовании спиральной схемы на первой итерации, как правило, специфи- цируют, проектируют, реализуют и тестируют интерфейс пользователя. На второй – добавляют некоторый ограниченный набор функций. На последующих этапах этот на- бор расширяют, наращивая возможности данного продукта. Основным достоинством данной схемы является то, что, начиная с некоторой ите- рации, обеспечившей определенную функциональную полноту, продукт можно пре- доставлять пользователю. Это, в свою очередь, позволяет: * сократить время до появления первых версий программного продукта; * заинтересовать большое количество пользователей, обеспечивая быстрое про- движение следующих версий продукта на рынке; * ускорить формирование и уточнение спецификаций за счет появления практики использования продукта; * уменьшить вероятность морального устаревания системы за время разработки. ПоявлениеCASE-технологий (Computer-Aided Software/System Engineering – Авто- матизированная технология разработки ПО/систем) снизило трудоемкость отдельных 8 этапов жизненного цикла ПО за счет автоматизации трудоемких операций. Современ- ные CASE-средства существенно увеличивают производительность труда программи- стов, улучшают качество создаваемого ПО и автоматизируют формирование проектной документации для всех этапов жизненного цикла в соответствии с современными стан- дартами. 2. ПОСТАНОВКА ЗАДАЧИ. РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ Процесс создания нового ПО начинают с постановки задачи, в процессе которой определяют требования к программному продукту. Это один из наиболее ответствен- ных этапов в процессе создания ПО. От того насколько полно определены функции бу- дущего программного продукта и другие требования к нему, во многом зависит стои- мость разработки и ее качество. Техническое задание представляет собой документ, в котором формулируют ос- новные цели разработки, требования к программному продукту, определяют сроки и этапы разработки и регламентируют процесс приемно-сдаточных испытаний. В форму- лировании технического задания участвуют как представители заказчика, так и пред- ставители исполнителя. В основе этого документа лежат исходные требования заказ- чика, анализ передовых достижений техники, результаты выполнения научно- исследовательских работ, предпроектных исследований, научного прогнозирования и т.п. Основными факторами, определяющими характеристики разрабатываемого ПО, являются: * исходные данные и требуемые результаты, которые определяют функции про- граммы или системы; * среда (программная и аппаратная), в которой разрабатываемое ПО будет функ- ционировать, может быть задана, а может выбираться для обеспечения параметров, указанных в техническом задании; * возможное взаимодействие с другим ПО и/или конкретными техническими сред- ствами – также может быть определено, а может выбираться исходя из набора выпол- няемых функций. Разработка технического задания выполняется в следующей последовательности. Прежде всего, устанавливают набор выполняемых функций, а также перечень и харак- теристики исходных данных. Затем определяют набор результатов, их характеристики 9 и способы представления. Далее уточняют среду функционирования ПО: конкретную комплектацию и параметры технических средств, версию используемой операционной системы и, возможно, версии и параметры другого установленного ПО, с которым предстоит взаимодействовать будущему программному продукту. В тех случаях, когда разрабатываемое ПО собирает и хранит некоторую информа- цию или включается в управление каким-либо техническим процессом, необходимо также четко регламентировать действия программы в случае сбоев оборудования и энергоснабжения. На техническое задание существует стандарт (ГОСТ 19.201–78). В соответствие с этим стандартом техническое задание должно содержать следующие разделы: * введение; * основания для разработки; * назначение разработки; * требования к программе или программному изделию; * требования к программной документации; * технико-экономические показатели; * стадии и этапы разработки; * порядок контроля и приемки. При необходимости допускается в техническое задание включать приложения. Рассмотрим более подробно содержание каждого раздела. Введение должно включать наименование и краткую характеристику области при- менения программы или программного продукта. Основное назначение введения – продемонстрировать актуальность данной разработки и показать, какое место эта раз- работка занимает в ряду подобных. Раздел Основания для разработки должен содержать наименование документа, на основании которого ведется разработка, организации, утвердившей данный документ, и наименование или условное обозначение темы разработки. Таким документом может служить план, приказ, договор и т.п. Раздел Назначение разработки должен содержать описание функционального и эксплуатационного назначения программного продукта с указанием категорий пользо- вателей. Раздел Требования к программе или программному изделию должен включать сле- дующие подразделы: 10 * требования к функциональным характеристикам; * требования к надежности; * условия эксплуатации; * требования к составу и параметрам технических средств; * требования к информационной и программной совместимости; * требования к маркировке и упаковке; * требования к транспортированию и хранению; * специальные требования. Наиболее важным из перечисленных выше является подраздел Требований к функ- циональным характеристикам. В этом разделе должны быть перечислены выполняе- мые функции и описаны состав, характеристики и формы представления исходных данных и результатов. В этом же разделе при необходимости указывают критерии эф- фективности: максимально допустимое время ответа системы, максимальный объем используемой оперативной и/или внешней памяти и др. В подразделе Требования к надежности указывают уровень надежности, который должен быть обеспечен разрабатываемой системой и время восстановления системы после сбоя. Для систем с обычными требованиями к надежности в этом разделе иногда регламентируют действия разрабатываемого продукта по увеличению надежности ре- зультатов (контроль входной и выходной информации, создание резервных копий про- межуточных результатов и т. п.). В подразделе Условия эксплуатации, указывают особые требования к условиям эксплуатации: температуре окружающей среды, относительной влажности воздуха и т.п. Как правило, подобные требования формулируют, если разрабатываемая система будет эксплуатироваться в нестандартных условиях или использует специальные внешние устройства, например, для хранения информации. Здесь же указывают вид об- служивания, необходимое количество и квалификация персонала. В подразделе Требования к составу и параметрам технических средств указывают необходимый состав технических средств с указанием их основных технических харак- теристик: тип микропроцессора, объем памяти, наличие внешних устройств и т.п. При этом часто указывают два варианта конфигурации: минимальный и рекомендуемый. В подразделе Требования к информационной и программной совместимости при необходимости можно задать методы решения, определить язык или среду программи- рования для разработки, а также используемую операционную систему и другие сис- 11 темные и пользовательские программные средства, с которыми должно взаимодейство- вать разрабатываемое ПО. В этом же разделе при необходимости указывают, какую степень защиты информации необходимо предусмотреть. В разделе Требования к программной документации указывают необходимость на- личия руководства программиста, руководства пользователя, руководства системного программиста, пояснительной записки и т.п. На все эти типы документов также суще- ствуют ГОСТы. В разделе Технико-экономические показатели рекомендуется указывать ориенти- ровочную экономическую эффективность и экономические преимущества по сравне- нию с существующими аналогами. В разделе Стадии и этапы разработки указывают стадии разработки, этапы и со- держание работ с указанием сроков разработки и исполнителей. В разделе Порядок контроля и приемки указывают виды испытаний и общие тре- бования к приемке работы. В приложениях при необходимости приводят: перечень научно-исследовательских работ, обосновывающих разработку; схемы алгоритмов, таблицы, описания, обоснова- ния, расчеты и другие документы, которые могут быть использованы при разработке. В зависимости от особенностей разрабатываемого продукта разрешается уточнять содержание разделов, т.е. использовать подразделы, вводить новые разделы или объе- динять их. Пример титульного листа технического задания на учебный программный продукт представлен в приложении 1. |