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

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

Голосов: 6

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

Приведенный ниже текст получен путем автоматического извлечения из оригинального PDF-документа и предназначен для предварительного просмотра.
Изображения (картинки, формулы, графики) отсутствуют.
                            Спецификация программы
                           (головного модуля)

                           Текст головного модуля




                Спецификация                     Спецификация
                1-ой подзадачи                  3-ей подзадачи



                                 Спецификация
                                 2-ой подзадачи


      Рисунок 1.5 - Первый шаг формирования модульной структуры про-
граммы при конструктивном подходе

       Аналогичные действия производятся при программировании любого
другого модуля, который выбирается из текущего состояния дерева про-
граммы из числа специфицированных, но пока еще не запрограммированных
модулей. В результате этого производится очередное деформирование дерева
программы, например, такое, которое показано на рисунке 1.6.
       Архитектурный подход к разработке программы представляет собой
модификацию восходящей разработки, при которой модульная структура
программы формируется в процессе программирования модуля. Но при этом
ставится существенно другая цель разработки: повышение уровня исполь-
зуемого языка программирования, а не разработка конкретной программы.
Это означает, что для заданной предметной области выделяются типичные
функции, каждая из которых может использоваться при решении разных за-
дач в этой области, и специфицируются, а затем и программируются отдель-
ные программные модули, выполняющие эти функции. Так как процесс вы-
деления таких функций связан с накоплением и обобщением опыта решения
задач в заданной предметной области, то обычно сначала выделяются и реа-
лизуются отдельными модулями более простые функции, а затем постепенно
появляются модули, использующие ранее выделенные функции. Такой на-
бор модулей создается в расчете на то, что при разработке той или иной про-
граммы заданной предметной области в рамках конструктивного подхода
могут оказаться приемлемыми некоторые из этих модулей. Это позволяет
существенно сократить трудозатраты на разработку конкретной программы
путем подключения к ней заранее заготовленных и проверенных на практике
модульных структур нижнего уровня. Так как такие структуры могут много-
кратно использоваться в разных конкретных программах, то архитектурный
                                                                         21


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

                       Спецификация программы
                          (головного модуля)

                         Текст головного модуля


             Спецификация                      Спецификация
             1-ой подзадачи                   3-ей подзадачи


                 Текст                            Текст
            головного модуля                 головного модуля
             1-ой подзадачи                   3-ей подзадачи


               Спецификация
               2-ой подзадачи

                                   Текст
                              головного модуля
                               2-ой подзадачи




                Спецификация                  Спецификация
               2.1-ой подзадачи              2.2-ой подзадачи

     Рисунок 1.6 - Второй шаг формирования модульной структуры про-
граммы при конструктивном подходе.

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

22


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




                                                                      23


           Методы разработки структуры программ


          Нисходящие                      Восходящие


           Классический                 Классический
              подход                       подход

              Классическая              Классическая
               нисходящая                восходящая
               разработка                разработка
                                     (не рекомендуется)

              Классическая              Классическая
               нисходящая                восходящая
               реализация                 реализация
                                     (не рекомендуется)


          Конструктивный              Архитектурный
              подход                      подход


           Конструктивная             Архитектурная
             разработка                 разработка

           Конструктивная             Архитектурная
             реализация                 реализация


                           Целенаправленная
                           конструктивная
                              реализация
     Рисунок 1.7 - Классификация методов разработки структуры программ




24


     1.7 Отладка и тестирование ПС

       Отладка ПС − это деятельность, направленная на обнаружение и ис-
правление ошибок в ПС с использованием процессов выполнения его про-
грамм. Тестирование ПС − это процесс выполнения его программ на некото-
ром наборе данных, для которого заранее известен результат применения или
известны правила поведения этих программ. Указанный набор данных назы-
вается тестовым или просто тестом. Таким образом, отладку можно пред-
ставить в виде многократного повторения трех процессов: тестирования, в
результате которого может быть констатировано наличие в ПС ошибки, по-
иска места ошибки в программах и документации ПС и редактирования про-
грамм и документации с целью устранения обнаруженной ошибки. Другими
словами:
       Отладка = Тестирование + Поиск ошибок + Редактирование
       В зарубежной литературе отладку часто понимают только как процесс
поиска и исправления ошибок (без тестирования), факт наличия которых ус-
танавливается при тестировании. Иногда тестирование и отладку считают
синонимами. В нашей стране в понятие отладки обычно включают и тести-
рование, поэтому мы будем следовать сложившейся традиции.
       Тестирование – процесс многократного повторения программы с це-
лью обнаружения ошибок. Тестирование – составная часть отладки.
       Отладка имеет место тогда, когда программа со всей очевидностью
работает неправильно. Поэтому отладка начинается всегда в предвидении
отказа программы. Если же оказывается, что программа работает верно, то
она тестируется. Часто случается так, что после прогона тестов программа
вновь подвергается отладке. Таким образом, тестирование устанавливает
факт наличия ошибки, а отладка выявляет ее причину.
       Основная цель выделения отладки и тестирования как отдельных эта-
пов создания программы заключается в том, чтобы обратить внимание обяза-
тельности обеих стадий и на необходимость специального планирования
временных затрат по каждой из них в отдельности.
       Нельзя гарантировать, что тестированием можно установить наличие
каждой имеющейся в ПС ошибки. Поэтому возникает две задачи. Первая за-
дача: подготовить такой набор тестов и применить к ним ПС, чтобы обнару-
жить в нем по возможности большее число ошибок. Однако чем дольше про-
должается процесс тестирования (и отладки в целом), тем большей становит-
ся стоимость ПС. Отсюда вторая задача: определить момент окончания от-
ладки ПС (или отдельной его компоненты). Признаком возможности оконча-
ния отладки является полнота охвата пропущенными через ПС тестами (т.е.
тестами, к которым применено ПС) множества различных ситуаций, возни-
кающих при выполнении программ ПС, и относительно редкое проявление
ошибок в ПС на последнем отрезке процесса тестирования. Последнее опре-
деляется в соответствии с требуемой степенью надежности ПС, указанной в
спецификации его качества.
       Заповеди, предложенные Майерсом, по тестированию ПС.
                                                                       25


       Заповедь 1. Считайте тестирование ключевой задачей разработки ПС,
поручайте его самым квалифицированным и одаренным программистам;
нежелательно тестировать свою собственную программу.
       Заповедь 2. Хорош тот тест, для которого высока вероятность обна-
ружить ошибку, а не тот, который демонстрирует правильную работу про-
граммы.
       Заповедь 3. Готовьте тесты как для правильных, так и для неправиль-
ных данных.
       Заповедь 4. Документируйте пропуск тестов через компьютер; деталь-
но изучайте результаты каждого теста; избегайте тестов, пропуск которых
нельзя повторить.
       Заповедь 5. Каждый модуль подключайте к программе только один
раз; никогда не изменяйте программу, чтобы облегчить ее тестирование.
       Заповедь 6. Пропускайте заново все тесты, связанные с проверкой ра-
боты какой-либо программы ПС или ее взаимодействия с другими програм-
мами, если в нее были внесены изменения (например, в результате устране-
ния ошибки).
       Существуют следующие методы тестирования ПС:
        1) Статическое тестирование – ручная проверка программы за сто-
лом.
        2) Детерминированное тестирование – при различных комбинациях
исходных данных.
        3) Стохастическое – исходные данные выбираются произвольно, на
выходе определяется качественное совпадение результатов или примерная
оценка.
       Имеется два подхода к тестированию:
        1) Структурное тестирование – метод «белого ящика», тестируется
логика программы, внутренняя структура программы.
        2) Функциональное тестирование – метод «черного ящика»- тести-
руется спецификация, т.е. вход/выход без учета знаний о ее структуре.
       В нашей стране различаются два основных вида отладки (включая
тестирование): автономную и комплексную отладку ПС.
        Автономная отладка ПС означает последовательное раздельное тес-
тирование различных частей программ, входящих в ПС, с поиском и исправ-
лением в них фиксируемых при тестировании ошибок. Она фактически
включает отладку каждого программного модуля и отладку сопряжения мо-
дулей.
       Комплексная отладка означает тестирование ПС в целом с поиском и
исправлением фиксируемых при тестировании ошибок во всех документах
(включая тексты программ ПС), относящихся к ПС в целом. К таким доку-
ментам относятся определение требований к ПС, спецификация качества ПС,
функциональная спецификация ПС, описание архитектуры ПС и тексты про-
грамм ПС.



26


     1.8 Надежность ПС

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

     1.9 Документация ПС

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

                                                                        27


         При разработке ПС создается и используется большой объем разно-
 образной документации. Она необходима как средство передачи информа-
 ции между разработчиками ПС, как средство управления разработкой ПС и
 как средство передачи пользователям информации, необходимой для приме-
 нения и сопровождения ПС. На создание этой документации приходится
 большая доля стоимости ПС.
         Эту документацию можно разбить на две группы:
        − документы управления разработкой ПС;
        − документы, входящие в состав ПС.
         Документы управления разработкой ПС (software process documenta-
 tion) управляют и протоколируют процессы разработки и сопровождения ПС,
 обеспечивая связи внутри коллектива разработчиков ПС и между коллекти-
 вом разработчиков и менеджерами ПС (software managers) − лицами, управ-
 ляющими разработкой ПС. Эти документы могут быть следующих типов:
        − планы, оценки, расписания. Эти документы создаются менеджерами
для прогнозирования и управления процессами разработки и сопровождения
ПС;
        − отчеты об использовании ресурсов в процессе разработки. Созда-
 ются менеджерами;
        − стандарты. Эти документы предписывают разработчикам, каким
принципам, правилам, соглашениям они должны следовать в процессе разра-
ботки ПС. Эти стандарты могут быть как международными или националь-
ными, так и специально созданными для организации, в которой ведется раз-
работка ПС;
        − рабочие документы. Это основные технические документы, обес-
печивающие связь между разработчиками. Они содержат фиксацию идей и
проблем, возникающих в процессе разработки, описание используемых стра-
тегий и подходов, а также рабочие (временные) версии документов, которые
должны войти в ПС;
        − заметки и переписка. Эти документы фиксируют различные детали
взаимодействия между менеджерами и разработчиками.
         Документы, входящие в состав ПС (software product documentation),
 описывают программы ПС как с точки зрения их применения пользователя-
 ми, так и с точки зрения их разработчиков и сопроводителей (в соответствии
 с назначением ПС). Здесь следует отметить, что эти документы будут ис-
 пользоваться не только на стадии эксплуатации ПС (в ее фазах применения
 и сопровождения), но и на стадии разработки для управления процессом
 разработки (вместе с рабочими документами) − во всяком случае, они долж-
 ны быть проверены (протестированы) на соответствие программам ПС. Эти
 документы образуют два комплекта с разным назначением:
        − пользовательская документация ПС (П-документация);
        − документация по сопровождению ПС (С-документация).
         Пользовательская документация ПС (user documentation) объясняет
 пользователям, как они должны действовать, чтобы применить разрабаты-

28


 ваемое ПС. Она необходима, если ПС предполагает какое-либо взаимодей-
 ствие с пользователями. К такой документации относятся документы, кото-
 рыми должен руководствоваться пользователь при инсталляции ПС (при ус-
 тановке ПС с соответствующей настройкой на среду применения ПС), при
 применении ПС для решения своих задач и при управлении ПС (например,
 когда разрабатываемое ПС будет взаимодействовать с другими системами).
 Эти документы частично затрагивают вопросы сопровождения ПС, но не ка-
 саются вопросов, связанных с модификацией программ.
        В связи с этим следует различать две категории пользователей ПС:
 ординарных пользователей ПС и администраторов ПС.
        Ординарный пользователь ПС (end-user) использует ПС для решения
 своих задач (в своей предметной области). Это может быть инженер, проек-
 тирующий техническое устройство, или кассир, продающий железнодорож-
 ные билеты с помощью ПС. Он может и не знать многих деталей работы
 компьютера или принципов программирования.
        Администратор ПС (system administrator) управляет использованием
 ПС ординарными пользователями и осуществляет сопровождение ПС, не
 связанное с модификацией программ. Например, он может регулировать
 права доступа к ПС между ординарными пользователями, поддерживать
 связь с поставщиками ПС или выполнять определенные действия, чтобы
 поддерживать ПС в рабочем состоянии, если оно включено как часть в дру-
 гую систему.
        Состав пользовательской документации зависит от аудиторий пользо-
 вателей, на которые ориентировано разрабатываемое ПС, и от режима ис-
 пользования документов. Под аудиторией здесь понимается контингент
 пользователей ПС, у которого есть необходимость в определенной пользова-
 тельской документации ПС. Удачный пользовательский документ сущест-
 венно зависит от точного определения аудитории, для которой он предназна-
 чен. Пользовательская документация должна содержать информацию, необ-
 ходимую для каждой аудитории. Под режимом использования документа по-
 нимается способ, определяющий, каким образом используется этот документ.
 Обычно пользователю достаточно больших программных систем требуются
 либо документы для изучения ПС (использование в виде инструкции), либо
 для уточнения некоторой информации (использование в виде справочника).
        В соответствии с работами можно считать типичным следующий со-
 став пользовательской документации для достаточно больших ПС:
       − общее функциональное описание ПС дает краткую характеристику
функциональных возможностей ПС. Предназначено для пользователей, кото-
рые должны решить, насколько необходимо им данное ПС;
       − руководство по инсталляции ПС предназначено для администрато-
ров ПС. Оно должно детально предписывать, как устанавливать системы в
конкретной среде, файлы, представляющие ПС, и требования к минимальной
конфигурации аппаратуры;


                                                                        29


       − инструкция по применению ПС предназначена для ординарных
пользователей. Содержит необходимую информацию по применению ПС, ор-
ганизованную в форме удобной для ее изучения;
       − справочник по применению ПС предназначен для ординарных поль-
зователей. Содержит необходимую информацию по применению ПС, органи-
зованную в форме удобной для избирательного поиска отдельных деталей;
       − руководство по управлению ПС предназначено для администрато-
ров ПС. Оно должно описывать сообщения, генерируемые, когда ПС взаимо-
действует с другими системами, и как должен реагировать администратор на
эти сообщения. Кроме того, если ПС использует системную аппаратуру, этот
документ может объяснять, как сопровождать эту аппаратуру.
        Разработка пользовательской документации начинается сразу после
 создания внешнего описания. Качество этой документации может сущест-
 венно определять успех ПС. Она должна быть достаточно проста и удобна
 для пользователя (в противном случае, это ПС вообще не стоило создавать).
 Поэтому, хотя черновые варианты (наброски) пользовательских документов
 создаются основными разработчиками ПС, к созданию их окончательных
 вариантов часто привлекаются профессиональные технические писатели.
        Документация по сопровождению ПС (system documentation) описы-
 вает ПС с точки зрения ее разработки. Эта документация необходима, если
 ПС предполагает изучение того, как оно устроено (сконструировано), и мо-
 дернизацию его программ. Сопровождение − это продолжающаяся разра-
 ботка. Поэтому в случае необходимости модернизации ПС к этой работе
 привлекается специальная команда разработчиков-сопроводителей. Этой
 команде придется иметь дело с такой же документацией, которая определяла
 деятельность команды первоначальных (основных) разработчиков ПС, − с
 той лишь разницей, что эта документация для команды разработчиков-
 сопроводителей будет, как правило, чужой (она создавалась другой коман-
 дой). Чтобы понять строение и процесс разработки модернизируемого ПС,
 команда разработчиков-сопроводителей должна изучить эту документацию,
 а затем внести в нее необходимые изменения, повторяя в значительной сте-
 пени технологические процессы, с помощью которых создавалось первона-
 чальное ПС.
        Документацию по сопровождению ПС можно разбить на две группы:
       − документация, определяющая строение программ и структур дан-
 ных ПС и технологию их разработки;
       − документация, помогающая вносить изменения в ПС.
        Документация первой группы содержит итоговые документы каждо-
 го технологического этапа разработки ПС. Она включает следующие доку-
 менты:
        − внешнее описание ПС (Requirements document);
        − описание архитектуры ПС, включая внешнюю спецификацию каж-
 дой ее программы (подсистемы);


30



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