Документирование программных средств
При разработке ПС создается большой объем разнообразной документации. Она
необходима как средство передачи информации между разработчиками ПС, как средство
управления разработкой ПС и как средство передачи пользователям информации,
необходимой для применения и сопровождения ПС. На создание этой документации
приходится большая доля стоимости ПС.
Эту документацию можно разбить на две группы: Документы управления разработкой ПС; Документы, входящие в состав ПС.
Документы управления разработкой ПС, протоколируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков и между коллективом разработчиков и менеджерами (managers) - лицами, управляющими разработкой. Эти документы могут быть следующих типов: Планы, оценки, расписания: эти документы создаются менеджерами для
прогнозирования и управления процессами разработки и сопровождения; Отчеты об использовании ресурсов в процессе разработки: Создаются менеджерами; Стандарты: Эти документы предписывают разработчикам, каким принципам, правилам, соглашениям они должны следовать в процессе разработки ПС. Эти стандарты могут быть как международными или национальными, так и специально созданными для организации, в которой ведется разработка данного ПС; Рабочие документы. Это основные технические документы, обеспечивающие связь между разработчиками. Они содержат фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также рабочие (временные) версии документов, которые должны войти в ПС; Заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками.
|
|
|
Документы, входящие в состав ПС (product documentation), описывают программы
ПС как с точки зрения их применения пользователями, так и с точки зрения их
разработчиков и сопроводителей (в соответствии с назначением ПС). Здесь следует
отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС
(в ее фазах применения и сопровождения), но и на стадии разработки для управления
процессом разработки (вместе с рабочими документами) - во всяком случае они должны
быть проверены (протестированы) на соответствие программам ПС. Эти документы
образуют два комплекта с разным назначением:Пользовательская документация ПС (П-документация). Документация по сопровождению ПС (С-документация).
Пользовательская документация ПС объясняет пользователям, как они должны действовать, чтобы применить данное ПС. Она необходима, если ПС предполагает какое-либо взаимодействие с пользователями. К такой документации относятся документы, которыми руководствуется пользователь при инсталяции ПС (при установке ПС с соответствующей настройкой на среду применения ПС), при применении ПС для решения своих задач и при управлении ПС (например, когда данное ПС взаимодействует с другими системами). Эти документы частично затрагивают вопросы сопровождения ПС, но не касаются вопросов, связанных с модификацией программ.
|
|
|
Билет 4
Структурный подход разработки программного обеспечения
Сущность структурного подхода к разработке ПО заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие: принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения; принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
|
|
|
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие: принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных; принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы; принцип непротиворечивости - заключается в обоснованности и согласованности элементов; принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие: SADT модели и соответствующие функциональные диаграммы; DFD диаграммы потоков данных; ERD диаграммы "сущность-связь".
|
|
|
На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.
Модульное программирование
Модульное программирование является развитием и совершенствованием процедурного программирования и библиотек специальных программ. Основная черта модульного программирования - стандартизация интерфейса между отдельными программными единицами.
Модуль- это отдельная функционально-законченная программная единица, которая структурно оформляется стандартным образом по отношению к компилятору и по отношению к объединению ее с другими аналогичными единицами и загрузке.
Программный модуль- это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса. Это означает, что каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым, физически разделен с другими модулями программы. Более того, каждый разработанный программный модуль может включаться в состав разных программ, если выполнены условия его использования, декларированные в документации по этому модулю. Таким образом, программный модуль может рассматриваться и как средство борьбы со сложностью программ, и как средство борьбы с дублированием в программировании (т.е. как средство накопления и многократного использования программистских знаний).
Для оценки приемлемости выделенного модуля используются некоторые критерии. Так, Хольт предложил следующие два общих таких критерия: хороший модуль снаружи проще, чем внутри; хороший модуль проще использовать, чем построить.
Майерс предлагает использовать более конструктивные характеристики программного модуля для оценки его приемлемости: размер модуля; прочность модуля; сцепление с другими модулями; рутинность модуля (независимость от предыстории обращений к не-му).
При разработке программного модуля целесообразно придерживаться следующего порядка: изучение и проверка спецификации модуля, выбор языка программирования; выбор алгоритма и структуры данных; программирование модуля; шлифовка текста модуля; проверка модуля; компиляция модуля.
Существуют методы восходящей и нисходящей разработки структуры программы.
Билет 5
Понятие жизненного цикла ПО.
Под жизненным циклом ПС понимают весь период его разработки и эксплуатации начиная от момента возникновения замысла ПС и кончая прекращением всех видов его использования.
В настоящее время можно выделить пять основных подходов к организации процесса создания и использования ПС:
-водопадный подход. При таком подходе разработка ПС состоит из цепочки этапов. На каждом этапе создаются документы, используемые на последующем этапе. В исходном документе фиксируются требования в ПС. В конце этой цепочки создаются программы включаемые в ПС.
-исследовательское программирование. Этот подход предполагает быструю (насколько это возможно) реализацию рабочих версий программ, выполняющих лишь в первом приближении требуемые функции. После экспериментального применения реализованных программ производится их модификация с целью сделать их более полезными для пользователей. Этот процесс повторяется до тех пор пока ПС не будет достаточно приемлемо для пользователей. Такой подход применялся на ранних этапах развития программирования, когда технологии программирования не придавали большого значения. В настоящее время этот подход применяется для разработки таких ПС для которых пользователи не могут точно сформулировать требования (например: для разработки систем искусственного интеллекта).
-прототипирование. Этот подход моделирует начальную фазу исследовательского программирования вплоть до создания рабочих версий программ, предназначенных для проведения экспериментов с целью установить требования к ПС. В дальнейшем должна последовать разработка ПС по установленным требованиям в рамках какого-либо другого подхода (например, водопадного).
-формальные преобразования. Этот подход включает разработку формальных спецификаций ПС и превращение их программы путем корректных преобразований. На этом подходе базируется CASE-технология.
-сборочное программирование. Этот подход предполагает, что ПС конструируется главным образом из компонентов, которые уже существуют. Должно быть некоторое хранилище (библиотека) таких компонент, каждая из которых может многократно использоваться в разных ПС. Такие компоненты называются повторно используемыми. Процесс разработки ПС при данном подходе состоит скорее из сборки программ из компонент, чем из их программирования.
Дата добавления: 2018-04-04; просмотров: 2236; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!