Меню

Что входит в состав документации управления разработкой программных средств

Документирование программных средств

При разработке ПС создается большой объем разнообразной документации. Она

необходима как средство передачи информации между разработчиками ПС, как средство

управления разработкой ПС и как средство передачи пользователям информации,

необходимой для применения и сопровождения ПС. На создание этой документации

приходится большая доля стоимости ПС.

Эту документацию можно разбить на две группы: Документы управления разработкой ПС; Документы, входящие в состав ПС.

Документы управления разработкой ПС, протоколируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков и между коллективом разработчиков и менеджерами (managers) — лицами, управляющими разработкой. Эти документы могут быть следующих типов: Планы, оценки, расписания: эти документы создаются менеджерами для

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

Документы, входящие в состав ПС (product documentation), описывают программы

ПС как с точки зрения их применения пользователями, так и с точки зрения их

разработчиков и сопроводителей (в соответствии с назначением ПС). Здесь следует

отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС

(в ее фазах применения и сопровождения), но и на стадии разработки для управления

процессом разработки (вместе с рабочими документами) — во всяком случае они должны

быть проверены (протестированы) на соответствие программам ПС. Эти документы

образуют два комплекта с разным назначением:Пользовательская документация ПС (П-документация). Документация по сопровождению ПС (С-документация).

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

Структурный подход разработки программного обеспечения

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

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

В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие: SADT модели и соответствующие функциональные диаграммы; DFD диаграммы потоков данных; ERD диаграммы «сущность-связь».

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

Модульное программирование

Модульное программирование является развитием и совершенствованием процедурного программирования и библиотек специальных программ. Основная черта модульного программирования — стандартизация интерфейса между отдельными программными единицами.

Модуль— это отдельная функционально-законченная программная единица, которая структурно оформляется стандартным образом по отношению к компилятору и по отношению к объединению ее с другими аналогичными единицами и загрузке.

Программный модуль— это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса. Это означает, что каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым, физически разделен с другими модулями программы. Более того, каждый разработанный программный модуль может включаться в состав разных программ, если выполнены условия его использования, декларированные в документации по этому модулю. Таким образом, программный модуль может рассматриваться и как средство борьбы со сложностью программ, и как средство борьбы с дублированием в программировании (т.е. как средство накопления и многократного использования программистских знаний).

Читайте также:  Как вносить в 1с остатки по основным средствам

Для оценки приемлемости выделенного модуля используются некоторые критерии. Так, Хольт предложил следующие два общих таких критерия: хороший модуль снаружи проще, чем внутри; хороший модуль проще использовать, чем построить.

Майерс предлагает использовать более конструктивные характеристики программного модуля для оценки его приемлемости: размер модуля; прочность модуля; сцепление с другими модулями; рутинность модуля (независимость от предыстории обращений к не-му).

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

Существуют методы восходящей и нисходящей разработки структуры программы.

Понятие жизненного цикла ПО.

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

В настоящее время можно выделить пять основных подходов к организации процесса создания и использования ПС:

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

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

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

формальные преобразования. Этот подход включает разработку формальных спецификаций ПС и превращение их программы путем корректных преобразований. На этом подходе базируется CASE-технология.

сборочное программирование. Этот подход предполагает, что ПС конструируется главным образом из компонентов, которые уже существуют. Должно быть некоторое хранилище (библиотека) таких компонент, каждая из которых может многократно использоваться в разных ПС. Такие компоненты называются повторно используемыми. Процесс разработки ПС при данном подходе состоит скорее из сборки программ из компонент, чем из их программирования.

Дата добавления: 2018-04-04 ; просмотров: 1277 ; Мы поможем в написании вашей работы!

Источник



Документация, создаваемая и используемая в процессе разработки программных средств.

ДОКУМЕНТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ

Документация, создаваемая и используемая в процессе разработки программных средств.

При разработке ПС создается и используется большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство передачи пользователям информации, необходимой для применения и сопровождения ПС. На создание этой документации приходится большая доля стоимости ПС.

Эту документацию можно разбить на две группы [13.1]:

· Документы управления разработкой ПС.

· Документы, входящие в состав ПС.

Документы управления разработкой ПС (software process documentation) управляют и протоколируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков ПС и между коллективом разработчиков и менеджерами ПС (software managers) — лицами, управляющими разработкой ПС. Эти документы могут быть следующих типов [13.1]:

· Планы, оценки, расписания. Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения ПС.

· Отчеты об использовании ресурсов в процессе разработки. Создаютсяменеджерами.

· Стандарты. Эти документы предписывают разработчикам, каким принципам, правилам, соглашениям они должны следовать в процессе разработки ПС. Эти стандарты могут быть как международными или национальными, так и специально созданными для организации, в которой ведется разработка ПС.

· Рабочие документы. Это основные технические документы, обеспечивающие связь между разработчиками. Они содержат фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также рабочие (временные) версии документов, которые должны войти в ПС.

· Заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками.

Документы, входящие в состав ПС (software product documentation), описывают программы ПС как с точки зрения их применения пользователями, так и с точки зрения их разработчиков и сопроводителей (в соответствии с назначением ПС). Здесь следует отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС (в ее фазах применения и сопровождения), но и на стадии разработки для управления процессом разработки (вместе с рабочими документами) — во всяком случае, они должны быть проверены (протестированы) на соответствие программам ПС. Эти документы образуют два комплекта с разным назначением:

Читайте также:  Средство для блеска волос как называется

· Пользовательская документация ПС (П-документация).

· Документация по сопровождению ПС (С-документация).

Источник

12) Документирование — Технологии программирования

Primary tabs

Forums:

лекция к третьей аттестации по технологиям программирования ФКН ВГУ

_____________________________________________
Источники(читать подробнее)=
Ключевые слова и фразы(для поиска)=
Документирование ТП ФКН ВГУ

Wed, 12/28/2011 — 17:48

Документирование

Документирование

Любой проект должен сопровождаться хоть какой-то документацией (прим. редактора = например readme файл с иноформацией о том как именно использовать «таблетку» — это,так сказать , минимальная документация)

Цели документирования

Документация, создаваемая при разработке программных средств необходима для =

  1. передачи информации между разработчиками ПС,
  2. управления разработкой ПС,
  3. передачи пользователям информации, необходимой для применения и сопровождения ПС

Классы документов

Эту документацию можно разбить на две группы: =

  1. документы управления разработкой ПС (программного средства) — то есть документы, которые предназначены прежде всего для самих разработчиков и их начальства,
  2. документы, входящие в состав ПС — документы , предназначенные прежде всего для конечных пользователей или же обслуживающего персонала.
  1. Описание проекта
  2. Планы
  3. Задания исполнителям (задание распределённое между конкретными людьми или группами, участвующими в реализации проекта)
  4. отчёт о ходе работ — создаются менеджерами для контролирующих органов
  5. Протоколы встреч и обсуждений
  6. Отчёты о результатах активности
  7. Журналы
  1. Технические требования
  2. Технические спецификации
  3. Сведения о выпуске (Release notes)
  4. Руководства (напр — по эксплуатации и настройки)

ДОКУМЕНТИРОВАНИЕ ПРОЦЕССА РАЗРАБОТКИ (Process documentation)

Документы управления разработкой ПС (process documentation), протоколируют процессы разработки и сопровождения ПС
Они обеспечивают связи внутри коллектива разработчиков и между коллективом разработчиков и менеджерами, управляющими разработкой

  1. Планы, оценки, расписания — Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения
  2. Отчеты об использовании ресурсов в процессе разработки — Также создаются менеджерами для контролирующих органов

Стандарты.

Стандарты — это документы предписывают разработчикам, каким принципам, правилам, соглашениям они должны следовать в процессе разработки ПС

Стандарты могут быть как международными или национальными, так и специально созданными для организации, в которой ведется разработка данного ПС

Рабочие документы.

Рабочие документы — это основные технические документы, обеспечивающие связь между разработчиками — актуальны в определённое время в рамках процесса разработки

Они содержат фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также рабочие (временные) версии документов, которые должны войти в ПС

Заметки и переписка.

Заметки и переписка — Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками

Product documentation (ДОКУМЕНТАЦИЯ ПРОДУКТА)

Документы, входящие в состав ПС (product documentation), описывают ПС =

  1. с точки зрения его применения пользователями,
  2. с точки зрения его разработчиков и сопроводителей (в соответствии с назначением ПС)

Эти документы используются не только на стадии эксплуатации ПС, но и на стадии разработки для управления процессом его разработки

Типы документов продукта

Эти документы образуют два комплекта с разным назначением:

  1. пользовательская документация ПС (П-документация),
  2. документация по сопровождению ПС (С-документация)

Пользовательская документация


Пользовательская документация ПС
(user documentation) объясняет пользователям, как они должны действовать, чтобы применить данное ПС
К этому типу документации относятся документы, которыми руководствуется пользователь при:

  1. при инсталляции ПС,
  2. при применении ПС для решения своих задач,
  3. при управлении ПС (например, когда данное ПС взаимодействует с другими системами)

Категории пользователей

Следует различать две категории пользователей ПС:

  1. ординарных пользователей ПС (те , кто используют ПС для решения своих прикладных задач)
  2. и администраторов ПС

Ординарный пользователь ПС (end-user) использует ПС для решения задач в своей предметной области и может не знать многих деталей работы компьютера или принципов программирования

Администратор ПС
(system administrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ

Например, Администратор ПС может =

  1. регулировать права доступа к ПС между ординарными пользователями,
  2. поддерживать связь с поставщиками ПС,
  3. выполнять определенные действия для поддержания ПС в рабочем состоянии

Состав документации

Состав пользовательской документации зависит от аудиторий пользователей, на которых ориентировано данное ПС, и от режима использования документов
Пользовательская документация должна содержать информацию, необходимую для каждой пользовательской аудитории

Режим использования документа

Под режимом использования документа понимается способ, определяющий, каким образом используется этот документ

Обычно пользователю достаточно больших программных систем требуются =

  • либо документы для изучения ПС (использование в виде инструкции),
  • либо для уточнения некоторой информации (использование в виде справочника)

Состав пользовательской документации =

  1. Общее функциональное описание ПС с краткой характеристикой функциональных возможностей ПС. Предназначено для пользователей, решающих, насколько необходимо им данное ПС = позволяет получить общее представление о программном средстве — и решить нужно ли оно вообще или нет.
  2. Руководство по инсталляции ПС, предназначенное для системных администраторов. Оно должно детально описывать действия по установке системы и определять требования к конфигурации аппаратуры.
  3. Инструкция по применению ПС. Предназначена для ординарных пользователей и содержит необходимую информацию по применению ПС , организованную в форме удобной для изучения
  4. Справочник по применению ПС. Предназначен для ординарных пользователей и содержит необходимую информацию по применению ПС, организованную в форме удобной для избирательного поиска — (например в виде файла windows-спрпавки)
  5. Руководство по управлению ПС. Предназначено для системных администраторов и должно описывать сообщения, генерируемые при взаимодействии ПС с другими системами, а также способы реагирования на эти сообщения — Если ПС использует системную аппаратуру, то этот документ может объяснять, как сопровождать эту аппаратуру
Читайте также:  Дезинфицирующее средство cat экспресс

Разработка пользовательской документации

Разработка пользовательской документации начинается сразу после создания внешнего описания и ее качество может существенно определять успех ПС.

Она должна быть достаточно проста и удобна для пользователя, поэтому к созданию их окончательных вариантов часто привлекаются профессиональные технические писатели

Уже с начала выполнения целей проекта надо определиться с форматом документации ,с тем чтобы он соответствовал конечному варианту.

Не всегда получается изложить мысли разработчика в форме понятной для пользователя — но надо стараться или же привлекать так называемых «технических писателей»

——
Для обеспечения качества пользовательской документации разработан ряд стандартов , в которых

  1. предписывается порядок разработки этой документации,
  2. формулируются требования к каждому виду пользовательских документов,
  3. определяются их структура и содержание

Документация сопровождения

Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки

Эта документация необходима, если предполагается изучение устройства ПС и модернизация его программ

То есть тексты пишутся для разработчиков , подобных исполнителям (исполнители — это те, кто изначально создали ПС)

В случае необходимости модернизации ПС к этой работе привлекается специальная команда разработчиков-сопроводителей.

Этой команде придется иметь дело с такой же документацией, что и команде первоначальных разработчиков, — с той лишь разницей, что документация для команды разработчиков-сопроводителей будет чужой (она создавалась другой командой)

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

Документация по сопровождению ПС можно разбить на две группы: =

и технологию их разработки =содержит итоговые документы каждого технологического этапа разработки ПС и включает следующие документы:

  1. внешнее описание ПС (Requirements document — то есть описание , с точки зрения зависимости от параметров среды , в которой будут выполняться коды ПС — например — зависимость от операционной системы);
  2. описание архитектуры ПС (description of the system architecture), включая внешнюю спецификацию каждой ее программы;
  3. для каждой программы ПС — описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля;

И ещё =

  1. для каждого модуля — его спецификация и описание его строения (design description);
  2. тексты модулей на выбранном языке программирования (program source code listings);
  3. документы установления достоверности ПС (validation documents), описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС

Документы установления достоверности ПС включают прежде всего документацию по тестированию (схема тестирования и описание комплекта тестов), но могут включать и результаты других видов проверки ПС, например, доказательства свойств программ — то есть теоретическое обоснование «правильности».

= содержит Руководство по сопровождению ПС (system maintenance guide), которое описывает:

  1. известные проблемы, связанные с ПС,
  2. какие части системы являются аппаратно- и программно-зависимыми,
  3. возможности дальнейшего развития ПС

Общая проблема сопровождения ПС заключается в обеспечении согласованности всех его представлений при внесении в него любых изменений

Чтобы этому помочь, связи и зависимости между документами и их частями должны быть зафиксированы

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

Решению этой проблемы может помочь автоматизация этого вида деятельности
Для автоматического формирования документации к программному проекту используются специальные CASE-средства, называемые генераторами документации

Генератор документации

Генератор документации — программа или пакет программ, позволяющая получать документацию, предназначенную для программистов (документация на API) и/или для конечных пользователей системы, по особым образом комментированному исходному коду и, в некоторых случаях, по исполняемым модулям, полученным на выходе компилятора

Принципы работы генератора документации

Генератор анализирует исходный код программы, выделяя синтаксические конструкции, соответствующие значимым объектам программы (типам, классам, процедурам/функциям и т. п.)

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

На основе всей собранной информации формируется готовая документация в одном из общепринятых форматов.

_____________
матфак вгу и остальная классика =)

Источник