Единое окно доступа к образовательным ресурсам

Технология разработки программного обеспечения: Учебное пособие

Голосов: 6

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

Приведенный ниже текст получен путем автоматического извлечения из оригинального PDF-документа и предназначен для предварительного просмотра.
Изображения (картинки, формулы, графики) отсутствуют.
           − для каждой программы ПС − описание ее модульной структуры,
включая внешнюю спецификацию каждого включенного в нее модуля;
       − для каждого модуля − его спецификация и описание его строения;
       − тексты модулей на выбранном языке программирования;
       − документы установления достоверности ПС, описывающие, как
устанавливалась достоверность каждой программы ПС и как информация об
установлении достоверности связывалась с требованиями к ПС.
       Документы установления достоверности ПС включают, прежде всего,
документацию по тестированию (схема тестирования и описание комплекта
тестов).
       Документация второй группы содержит руководство по сопровожде-
нию ПС, которое описывает особенности реализации ПС (в частности, труд-
ности, которые пришлось преодолевать) и как учтены возможности развития
ПС в его строении (конструкции). В нем также фиксируются, какие части
ПС являются аппаратно- и программно-зависимыми.
       Общая проблема сопровождения ПС − обеспечить, чтобы все его
представления шли в ногу (оставались согласованными), когда ПС изменяет-
ся. Чтобы этому помочь, связи и зависимости между документами и их час-
тями должны быть отражены в руководстве по сопровождению, и зафикси-
рованы в базе данных управления конфигурацией.

     1.10 Перечень вопросов, изучаемых в курсе «Технология разра-
ботки программного обеспечения»

       1 Сущность предмета ТП, его задачи. Актуальность проблемы техно-
логии программирования. История развития ТП.
       2 Типы ПО.
       3 Уникальное ПО и ПО, как продукция. Требования к ПО как к про-
дукции. Доведение ПО до товарного уровня.
       4 Жизненный цикл ПС. Модели жизненного цикла ПС.
       5 Водопадная модель ЖЦ ПС.
       6 Каскадная модель ЖЦ ПС. Усовершенствование каскадной модели
ЖЦ ПС.
       7 Спиральная модель ЖЦ.
       8 Понятие качества ПО. Критерии качества ПО: функциональность,
надежность, их примитивы.
       9 Критерии качества: легкость применения, эффективность, их прими-
тивы.
       10 Критерии качества: сопровождаемость, мобильность, их примити-
вы.
       11 Функциональные и конструктивные критерии качества. Факторы,
определяющие качество ПО.
       12 Оценка качества ПО (показатель качества, единичный, комплекс-
ный, групповой). Методы определения числовых показателей качества.

                                                                       31


       13 Стиль программирования. Типы комментариев, их расположение.
Выбор имен переменных. Размещение операторов. Пользовательский интер-
фейс (командный, графический).
       14 Цель модульного программирования. Основные характеристики
программного модуля. Размер модуля. Рутинность модуля.
       15 Связность модуля.
       16 Сцепление модулей.
       17 Методы разработки структуры ПС. Восходящая разработка ПС.
Архитектурный подход разработки ПС.
       18 Нисходящая разработка ПС. Конструктивный подход разработки
ПС. Метод целенаправленной конструктивной реализации.
       19 Вспомогательные средства проектирования ПС (схемы Варнье-
Орра, СИС, схемы HIPO, привести примеры).
       20 Порядок разработки программного модуля.
       21 Структурное программирование. Схемы передач управления.
       22 Методы проектирования модуля: пошаговая детализация; анализ
сообщений.
       23 Методы проектирования модуля: метод расширения ядра, специ-
фикация модуля, иерархическое проектирование модулей.
       24 Вспомогательные средства проектирования модулей: таблицы дан-
ных, таблицы решений. Документация.
       25 Источники ошибок в ПС: интеллектуальные возможности челове-
ка, модель перевода информации. Причины появления ошибок.
       26 Методы обнаружения ошибок. Логические ошибки. Ошибки в чи-
словых расчетах.
       27 Основные понятия отладки и тестирования. Различие между от-
ладкой и тестированием. Преимущество тестирования сверху вниз. Проверка
программ в нормальных, экстремальных и исключительных ситуациях.
       28 Основные принципы тестирования программ. Заповеди по тести-
рованию, предложенные Г. Майерсом. Методы тестирования, два подхода к
тестированию.
       29 Тестирование модулей: тестирование путей, структур управления,
ветвлений, специальных значений.
       30 Логическая организация данных. Представление данных (внешнее,
внутреннее). Физическая организация данных. Эргономические факторы при
проектировании данных.
       31 Выбор и обоснование языка программирования. Критерии выбора
языка программирования.
       32 Сравнение языков программирования (типы данных, подпрог-
раммы, работа с динамической памятью, обработка исключительных ситуа-
ций, параллельная обработка программных модулей и др.)
       33 Характеристика языка АДА.
       34 Внешнее описание ПС.
       35 Определение требований к ПС.

32


       36 Функциональная спецификация ПС. Методы контроля внешнего
описания ПС.
       37 Техническое задание на разработку ПС.
       38 Организация процесса проектирования ПС.
       39 Понятие архитектуры ПС. Основные классы архитектур ПС. Кон-
троль архитектуры ПС.
       40 Определение основных компонентов системы: потоков данных и
процессов.
       41 Вспомогательные средства проектирования ПС (функциональные
схемы, ПЕРТ-диаграмма, сети Петри). Проектная документация.
       42 Необходимость коллективной разработки ПО.
       43 Метод бригады главного программиста. Состав бригады.
       44 Обязанности главного программиста.
       45 Функции заместителя главного программиста.
       46 Работа членов бригады. Работа секретаря (библиотекаря).
       47 Преимущества и трудности бригадного подхода.
       48 Проблемы оценки квалификации отдельных специалистов в коллективе.
       49 Организация контроля при коллективной разработке программ.
       50 Современная организация коллектива разработчиков ПС. Организация
коллективов для создания очень больших комплексов программ.
       51 Прикладное тестирование специалистов.
       52 Понятие и классификация ППП. Структура и основные компоненты
ППП.
       53 Этапы развития пакетов прикладных программ (ППП).
       54 Показатели качества ППП.
       55 Разработка и оформление модулей в ППП.
       56 Системный анализ библиотеки модулей. Средства сборки программ.
       57 Технология разработки ППП. Автоматизация разработки ППП.
       58 Документация, создаваемая и используемая в процессе разработки про-
граммных средств.
       59 Пользовательская документация ПС.
       60 Документация по сопровождению ПС.
       61 Документация ПО. Стандартизация программной документации. Еди-
ная система программной документации (ЕСПД). Классификация и обозначение
стандартов ЕСПД.
       62 Назначение ЕСПД, область распространения и состав ЕСПД. Виды
программных документов. Виды эксплутационных документов. Схемы алгорит-
мов.
       63 Стадии разработки программной документации.
       64 Общие требования к программным документам.
       65 Техническое задание. Требования к содержанию и оформлению.
       66 Программа и методика испытаний. Текст программы, описание про-
граммы, пояснительная записка, описание применения (документация).
       67 Руководство системному программисту, руководство программисту,
руководство оператору. IEEE.
                                                                      33


      68 Общая характеристика состояния применения ЕСПД. Межгосударст-
венные стандарты.
      69 Расчет стоимости ПС.
      70 Расчет экономической эффективности от внедрения ПС.
      71 Надежность ПС. Показатели надежности: качественные, порядковые,
количественные.
      72 Факторы, определяющие надежность ПО.
      73 Применение статистики к расчету надежности ПО.
      74 Модели, базирующиеся на теории надежности технических систем.
      75 Модель ошибок Шумана. Модель надежности.
      76 Модели, сеющие предварительные ошибки.

     2 Курсовое проектирование

     2.1 Общие требования

       Курсовой проект должен включать оттестированное программное
средство и пояснительную записку.
       Пояснительная записка проекта должна иметь следующую структуру:
       - титульный лист установленного образца (Приложение А);
       - техническое задание (Приложение Б);
       - содержание курсового проекта (Приложение В).
       В графической части курсового проекта могут быть представлены
следующие результаты:
       - функциональная структура ПС, показывающая функциональное на-
значение всего ПС и его отдельных частей;
       - модульная (иерархическая) структура ПС, фиксирующая результаты
проектирования ПС;
       - диаграммы наследования, зависимостей, классов и структур классов
ПС, фиксирующие результаты объектно-ориентированного проектирования
ПС;
       - схемы алгоритмов, иллюстрирующих основные методы и алгоритмы,
реализованные в ПС;
       - результаты работы ПО, показывающие наиболее типичные результа-
ты в форме графиков, таблиц, примеров выходной документации и т.п.

     2.2 Общие требования к разработке ПС

      Разработка ПС является определяющим элементом курсового проек-
тирования и может     вестись с использованием какого-либо подхода про-
ектирования например, водопадной модели разработки ПС (см. пункт 1.2).
      Можно придерживаться следующих этапов жизненного цикла ПС см.
рисунок 2.1.


34


           Рисунок 2.1 - Этапы жизненного цикла ПС

       Целью этапа анализа является описание задачи, которое должно быть
полным, последовательным, доступным для чтения и обзора различными за-
интересованными сторонами, позволяющим производить сравнение с реаль-
ными условиями.
          В ходе этого этапа решаются задачи:
       - уточнение требований, приведенных в задании на проектирование;
       - разработка спецификаций на ПС.
       Итогом выполнения этого этапа являются эксплуатационные и функ-
циональные спецификации, содержащие конкретное описание ПС.
       Эксплуатационные спецификации должны содержать сведения о бы-
стродействии ПО, затратах памяти, требуемых технических средствах, на-
дежности и т.д. Функциональные спецификации       определяют     функции,
которые должно выполнять ПС. Спецификации должны быть полными, точ-
ными и ясными.
       Цель этапа       проектирования - иерархическое разбиение слож-
ной задачи создания ПО на подзадачи меньшей сложности.
       На этапе проектирования решаются следующие задачи:
       - формирование структуры ПС и разработка алгоритмов, задаваемых
спецификациями;
       - определение состава модулей с разделением их на иерархические
уровни;
       - выбор структуры информации в базе данных;
       - фиксация межмодульных интерфейсов.
       Результатом работы на этом этапе являются спецификации на от-
дельные модули, дальнейшая декомпозиция которых нецелесообразна.
       Этап реализации или программирования включает в себя непосредст-
венное кодирование текстов программ на выбранном алгоритмическом языке
программирования. Цель этого этапа - получение текстов программ.
       Цель этапа тестирования и отладки - выявление в ПС ошибок, провер-
ка работоспособности ПС, его соответствие спецификациям.
       В ходе этого этапа решаются      следующие задачи:
       - подготовка данных для отладки;
       - планирование отладки;
       - испытание ПО.
       Результатом работы должно являться оттестированное и отлаженное
ПС.
       На этапе сопровождения возможно расширение функциональных воз-
можностей ПС, уточнение существующих, а также устранение ошибок. В
курсовом проекте, как правило, выполняются четыре этапа проектирования.

                                                                       35


       Примерные временные        соотношения между отдельными видами
работ представлены в таблице 2.1.
       Разработка ПС должна начинаться с тщательного изучения задания
на курсовое проектирование.
       Этапы анализа и проектирования должны быть формализованы с по-
мощью одного из рекомендуемых средств:
       - аппарат формальных спецификаций;
       - методы структурного анализа;
       - методы объектно-ориентированного анализа;
       - методы объектно-ориентированного проектирования.

        Таблица 2.1 - Распределение времени по этапам   разработки ПС
        (в % к общему времени разработки)
                         Этапы разработки ПС                    Всего
     Виды работ         Анализ Проекти- Програм- Отладка
                                рование    мирование и тести-
                                                      рование

     Анализ требова-    13                                       13
     ний и разработка
     спецификаций
     Подготовка дан-          2          2            4          8
     ных для отладки
     Планирование       2                2            4          8
     отладки
     Проектирование           13                                 13
     Тестирование       5     5          4            11         25
     Программирова-                      8                       8
     ние
     Испытание ПС                                     17         17
     Документирова-                      4            4          8
     ние
     Всего              20    20         20           40         100



        2.3 Организация графического интерфейса

       Разрабатываемое в курсовом проектировании ПС должно быть обяза-
тельно оснащено графическим пользовательским интерфейсом, что соответ-
ствует современным тенденциям и требованиям рынка на ПО.
       Под графическим пользовательским интерфейсом (GUI - Graphical
User Interface) понимается некоторая система (среда), служащая для органи-
зации диалога      ПС с пользователем на основе графического многоокон-

36


ного представления данных. В среде GUI организацию всего взаимодействия
с пользователем берет на себя именно сама среда, оставляя ПС делать только
свою работу.
       К общим принципам, лежащим в основе графического пользова-
тельского интерфейса, относятся:
       - графический режим работы;
       - представление ряда объектов пиктограммами;
       - многооконность;
       - использование указывающего устройства - мыши;
       - адекватность изображения на экране изображаемому объекту
(принцип WYSIWIG - What You See Is What You Get);
       - наглядность;
       - стандартизация всех основных действий и элементов (все програм-
мы для данной графической среды         выглядят и ведут себя совершен-
но одинаково, используют одинаковые принципы функционирования);
       - наличие большого числа стандартных элементов (кнопок, полей ре-
дактирования, переключателей и т.д.), которые могут использоваться при
конструировании ПС, делая их похожими в обращении и облегчая процесс их
написания.
       В основе современного графического пользовательского интерфейса
лежат две основные концепции.
       Первой из них является понятие программы, управляемой данными.
       Как правило, эта концепция практически      реализуется через ме-
ханизм сообщений. Внешние устройства (клавиатура, мышь, таймер) посы-
лают сообщения модулям программы о наступлении тех или иных событий
(например, при нажатии клавиши или передвижении мыши). Поступающие
сообщения попадают в очередь сообщений, откуда извлекаются приклад-
ной программой.
       Таким образом, программа не должна все время опрашивать мышь,
клавиатуру и другие устройства в ожидании, не произошло ли чего-нибудь,
заслуживающего внимания. Когда событие произойдет, программа получит
извещение об этом с тем, чтобы надлежащим образом его обработать. По-
этому программы для таких сред обычно представляют собой цикл обработ-
ки сообщений: извлечь очередное сообщение, обработать его, если оно ин-
тересно, либо передать стандартному обработчику сообщений, обычно вхо-
дящему в систему и представляющему собой стандартные действия системы
в ответ на то или иное событие.
       Сообщения могут посылаться не только устройствами, но и отдель-
ными частями программы (в частности, возможна посылка сообщения себе).
Так один модуль может послать сообщение другому модулю, или меню
посылает сообщение о выборе определенного пункта. При этом существует
также способ прямой посылки сообщения, минуя очередь, когда непосредст-
венно вызывается обработчик сообщений адресата.
       Второй основополагающей концепцией является понятие окна как
объекта. Окно - это не просто прямоугольная область на экране, это и про-
                                                                        37


грамма (процедура, функция), способная выполнить различные действия,
присущие окну. Одним из основных таких действий является реагирование
на поступающие сообщения и посылка сообщений другим объектам.
       Одной из основных функций окна является перерисовка содержания
окна. Любое окно должно уметь при получении соответствующего запроса
перерисовать себя (или свою часть) на экране. Перерисовка может реализо-
вываться или как реакция на специальное сообщение, или как виртуальная
функция (при использовании объектно-ориентированных языков). В состав
любой GUI обязательно входит достаточно мощный графический модуль,
обеспечивающий выполнение всех основных графических операций и под-
держивающий отсечение изображения по заданной (в том числе и довольно
сложной) области отсечения. За счет этого реализуется возможность перери-
совки фрагмента окна - устанавливается область отсечения, совпадающая с
требуемым фрагментом, а затем выполняется запрос на перерисовку. При от-
работке запроса на перерисовку окна можно определить размер текущей об-
ласти и не пытаться рисовать то, что заведомо будет отсечено.
       Среди окон вводятся отношения принадлежности и следования, т.е.
любое окно может иметь окно-родителя, которому оно принадлежит, и, сле-
довательно, задается во внутренних координатах родительского окна, отсе-
кается в размерах родительским окном и уничтожается при уничтожении ро-
дительского окна. Любое окно может иметь и принадлежащие ему окна (по-
докна), причем последние некоторым образом упорядочиваются. Тем самым
окна могут образовывать древовидные структуры подчинения.
       Родительское окно и принадлежащие ему подокна могут обменивать-
ся сообщениями друг с другом. Эти сообщения обычно разделяются на два
класса - запрос на выполнение окном некоторого действия и сообщение, опо-
вещающее окно о том, что в другом окне (обычно подокне) произошли неко-
торые изменения.
       Любая подобная система должна предоставлять для работы некото-
рый стандартный набор типов окон, из которых пользователь может стро-
ить свои программы.
       В состав окна могут входить другие окна и действовать при этом как
единое целое. Например, в состав окна-списка может входить скроллер.
       Среди окон обычно выделяются окна, предназначенные для ведения
диалога с пользователем, ввода данных и т.п. Обычно в их основе лежит
стандартное окно с большим набором подокон, играющих роль управляющих
элементов. Как правило, диалоговое окно (или процедура, ведущая диалог)
снабжается специальной функцией для координации работы управляющих
элементов. Например, диалог для выбора файла.
       Кроме стандартных окон пользователь может создавать свои собст-
венные типы окон, либо добавляя какие-то новые свойства, либо переопреде-
ляя часть старых и наследующих все остальное.
       При работе с клавиатурой важную роль играет понятие фокуса ввода.
Фокус ввода - это то окно, которому поступают все сообщения от клавиатуры.
Существует несколько способов перемещения фокуса ввода:
38


       - при нажатии кнопки мыши фокус передается тому окну, над кото-
рым это произошло;
       - окна диалога обычно переключают фокус между управляющими
элементами диалога при нажатии определенных клавиш (стандартно это Tab
и Shift-Tab);
       - посредством явного вызова функции установки фокуса ввода.
       Окну, теряющему фокус ввода, обычно посылается уведомление об
этом, и оно может предотвратить переход фокуса от себя. Окну, получаю-
щему фокус, передается сообщение о том, что оно получило фокус ввода.

     2.4 Требования к программной документации

       При разработке документации необходимо придерживаться требова-
ний СТП101-00 и стандартов ЕСПД. Стандарт предприятия разработан с уче-
том всех действующих ГОСТов на документацию. При работе над курсовым
проектом необходимо изучить следующие разделы:
       - оформление текста;
       - титульный лист;
       - аннотация;
       - содержание;
       - введение;
       - основная часть;
       - изложение текста;
       - заключение;
       - оформление иллюстраций;
       - построение таблиц;
       - список использованных источников;
       - приложения;
       - графическая часть;
       - схемы;
       - кодирование документов;
       - общие требования к оформлению курсовых проектов (работ).
       В стандарте ЕСПД необходимо обратить внимание на следующие
разделы:
        − виды программных документов ГОСТ 19.101-77;
       − стадии разработки ГОСТ 19.102-77;
       − техническое задание. Требования к содержанию и оформлению
ГОСТ 19.201-78;
        − схемы алгоритмов, программ данных и систем ГОСТ 19.701-90;
       − текст программы ГОСТ 19.401-78;
       − описание программы ГОСТ 19.402 -78;
       − программа и методика испытаний ГОСТ 19.301-79
       − пояснительная записка ГОСТ 19.404-79;
       − описание применения ГОСТ 19.502-78;

                                                                     39


      − руководство системному программисту ГОСТ 19.503-79;
      − руководство программиста ГОСТ 19.504-79;
      − руководство оператору ГОСТ 19.505-79.

     2.5 Содержание курсового проекта

       Курсовой проект должен иметь следующую структуру и состоять из
разделов.
       Аннотация
       Введение
       1 Общие сведения о программном средстве
       1.1 Основное функциональное назначение программного средства
       1.2 Полное наименование программного средства
       1.3 Условное обозначение программного средства
       1.4 Разработчики программного средства
       2 Техническое задание
       2.1 Основание для разработки
       2.2 Назначение разработки
       2.3 Требования к программному средству
       2.4 Требования к программной документации
       2.5 Требования к эргономике и технической эстетике
       2.6 Стадии и этапы разработки
       2.7 Порядок контроля и приемки
       3 Пояснительная записка
       3.1 Декомпозиция поставленной задачи
       3.2 Общая архитектура программного средства
       3.3 Реализация функционального назначения программного средства
       3.4 Разработка алгоритма решения задачи
       3.4.1 Детальная разработка алгоритмов отдельных подзадач
       3.5 Структурная организация данных
       3.6 Разработка интерфейса ПС
       3.7 Описание структуры выходной информации
       4 Руководство системного программиста
       4.1 Общие сведения о программном средстве
       4.2 Структура программного средства
       4.3 Установка программного средства
       4.4 Проверка программного средства
       4.5 Сообщения системному программисту
       5 Руководство программиста
       5.1 Назначение и условия применения программного средства
       5.2 Характеристика программного средства
       5.3 Работа с программным средством
       5.4 Входные и выходные данные
       5.5 Сообщения программисту
       6 Руководство пользователя
40



    
Яндекс цитирования Яндекс.Метрика