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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Презентация «Стандарты документирования процессов жизненного цикла программных средств»

Описание презентации по отдельным слайдам:

Описание слайда:

Стандарты документирования процессов жизненного цикла программных средств
Стандартизация, сертификация и техническое документоведение

Описание слайда:

Документирование
Документирование — это процесс записи инфор­мации, получаемой в процессе жизненного цикла или деятель­ности
Действия: планирование, проектирование, производство, редактирование, распространение и сопровождение документов
ГОСТ серии 19
ГОСТ серии 34
ГОСТ Р ИСО/МЭК 8631—94
ГОСТ Р ИСО 9127, ГОСТ Р ИСО/МЭК ТО 9294—93

Описание слайда:

ГОСТ Р ИСО/МЭК ТО 9294—93 «Информационная технология. Руководство по управлению документированием программного обеспечения»
Определение стратегий, стандартов, процедур, ресурсов и планов, которыми должны заниматься руководители, для того чтобы эффективно управлять документи­рованием ПО
Принципы:
1) Программная документация важна и ее следует планировать, описывать, проверять, утверждать, выпу­скать, распространять и сопровождать
2) Руководство и стимулирование персонала при проведении требуемого документирования, обеспечение его ресурсами
3) Признаки руководства: опубликование отчетов о стратегии документи­рования, процедур документирования, наличие стандартов и руководств, по документированию, выделение ресурсов для документирования, планирование документирования, постоянная проверка

Описание слайда:

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

Описание слайда:

Требования эффек­тивного документирования (изложены в стратегии)
Документация должна охватывать весь жизненный цикл ПО
Документирование должно быть управляемым
Документация должна соответствовать ее читательской аудитории
Работы по документированию должны быть объединены в об­щий процесс разработки ПО
Должны быть определены и использованы стандарты по доку­ментированию
Должны быть определены средства поддержки

Описание слайда:

Стандарты и руководства для…
Модели жизненного цикла ПО
Типов и взаимосвязей документов
Содержания документа
Качества документа
Форматов документа
Обозначения документа

Описание слайда:

Процедуры
Планирование
Подготов­ка
Конфигурационное управление
Проверка
Утверждение
Про­изводство
Хранение
Дублирование
Распространение
Модерни­зация
Продажа
ПРОЦЕДУРЫ ОПРЕДЕЛЯЮТ ПОСЛЕДОВАТЕЛЬНОСТЬ ДОКУМЕНТИРОВАНИЯ

Описание слайда:

Ресурсы для документирования
Персонал
Должны быть обучены методам документирования и четко выполнять свою роль в документировании
Средства
Инструментальные средства
Финансирование
Отдельные статьи бюджета

Описание слайда:

План документирования
Что должно быть сделано?
Как это должно быть сделано?
Когда это должно быть сделано?
Кто это должен делать?
График документирования
Требования к структуре, содержанию, формату, комплектности, хранению

Описание слайда:

График документирования
Для планирования документов
Для проверки плана и принципов документирования
Для подготовки проектов и проверки их на техническую точность, полноту и соответствие
Для редактирования при внесении комментариев, появившихся при проверке
Для проведения согласования
Перевода
Распространения

Описание слайда:

Вопросы
1. Что такое программная документация?
2. Чем, в первую очередь, вызвана необходимость документиро­вания программных средств?
3. Что входит в состав документации управления разработкой программных средств?
4. Что представляют собой внутренняя программная документа­ция?
5. Для чего предназначены документы, входящие в состав про­граммных средств?
6. Что представляет собой единая система программной докумен­тации?
7. Для чего предназначен документ «Техническое задание»?
8. Что может входить в документацию пользователя?
9. Какими свойствами должна обладать документация пользова­теля?
10. Для чего необходима внешняя программная документация?

Если Вы считаете, что материал нарушает авторские права либо по каким-то другим причинам должен быть удален с сайта, Вы можете оставить жалобу на материал.

Курс повышения квалификации

Охрана труда

Курс профессиональной переподготовки

Библиотечно-библиографические и информационные знания в педагогическом процессе

Курс профессиональной переподготовки

Охрана труда

Ищем педагогов в команду «Инфоурок»

Найдите материал к любому уроку, указав свой предмет (категорию), класс, учебник и тему:

также Вы можете выбрать тип материала:

Общая информация

Похожие материалы

Презентация «Стандарты в области программной инженерии»

Презентация Сертификация программных средств

Презентация «Роль стандартизации в управлении качеством программного обеспечения»

Презентация «Основные направления работ по стандартизации в сфере информационных технологий

Презентация «Обеспечение качества программного обеспечения»

Пример подведения итогов анкетирования родительской общественности по удовлетворенности деятельностью МДОУ

Презентация по психологии к уроку на тему «Психология и возраст. Аспекты возрастной психологии»

Кроссворд по швейным профессиям

Не нашли то что искали?

Воспользуйтесь поиском по нашей базе из
5360060 материалов.

Вам будут интересны эти курсы:

Оставьте свой комментарий

Авторизуйтесь, чтобы задавать вопросы.

Новые аккредитационные показатели для вузов вступят в силу с 1 марта

Время чтения: 1 минута

До конца 2024 года в РФ построят около 1 300 школ

Время чтения: 1 минута

Минпросвещения разработает внеучебные курсы для школьников

Время чтения: 1 минута

В России планируют создавать пространства для подростков

Время чтения: 2 минуты

Путин поручил не считать выплаты за классное руководство в средней зарплате

Время чтения: 1 минута

Учителям предлагают 1,5 миллиона рублей за переезд в Златоуст

Время чтения: 1 минута

Подарочные сертификаты

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

Все материалы, размещенные на сайте, созданы авторами сайта либо размещены пользователями сайта и представлены на сайте исключительно для ознакомления. Авторские права на материалы принадлежат их законным авторам. Частичное или полное копирование материалов сайта без письменного разрешения администрации сайта запрещено! Мнение администрации может не совпадать с точкой зрения авторов.

Источник

Научная электронная библиотека

Соловьев С. В., Цой Р. И., Гринкруг Л. С.,

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

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

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

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

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

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

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

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

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

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

Документы, входящие в состав ПС (software product documen­ta­tion), описывают программы ПС как с точки зрения их применения пользователями, так и с точки зрения их разработчиков и сопроводителей (в соответствии с назначением ПС). Следует отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС (в ее фазах применения и сопровождения), но и на стадии разработки для управления процессом разработки (вместе с рабочими документами). Во всяком случае, они должны быть проверены (протестированы) на соответствие программам ПС.

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

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

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

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

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

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

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

Можно считать типовым составом следующий состав пользовательской документации для достаточно больших ПС:

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

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

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

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

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

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

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

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

 документацию, определяющую строение программ и структур данных ПС и технологию их разработки;

 документацию, помогающую вносить изменения в ПС.

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

 внешнее описание ПС (Requirements document);

 описание архитектуры ПС (description of the system architect­ture), включая внешнюю спецификацию каждой ее программы (подсистемы).

 для каждой программы ПС описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля;

 для каждого модуля спецификацию и описание его строения (design description);

 тексты модулей на выбранном языке программирования (program source code listings);

 документы установления достоверности ПС (validation docu­ments), описывающие, как устанавливалась достоверность каждой программы ПС, и как информация об установлении достоверности связывалась с требованиями к ПС.

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

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

Создание и использование пакета прикладных программ (ППП) от формирования концепции и требований к первой версии до изъятия его из эксплуатации со­провождается документированием объектов и процессов жизненно­го цикла ППП.

По своему назначению документацию ППП можно классифицировать как:

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

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

 документацию тестирования компонентов и комплексов про­грамм;

 документацию испытаний ППП;

 документацию сопровождения и управления конфигурацией ППП.В состав проектной документации входят:

 отчет по обследованию предметной области, для которой предназначен разрабатываемый ППП, с описанием комплекса за­дач;

 описание концепции проектирования;

 техническое задание на проектирование;

 спецификации эскизного и технического проекта;

 документация на разработанные программные модули пакета;

 общее описание программного обеспечения, используемого при разработке и функционировании пакета (описание выбранной технологии автоматизированного проектирования ППП, операцион­ной системы, других программных средств).

В состав документации тестирования входят:

 программа (сценарии) тестирования;

 итоговый отчет о результатах тестирования.В состав документации испытаний входят:

 описание методов и методик испытаний;

 акт завершения работ;

 акт приемки ППП в эксплуатацию.В состав документации сопровождения управления конфигу­рацией входят:

 отчеты пользователей о выявленных дефектах и предло­жения по корректировке программ;

 журнал выявленных дефектов и предложений по совершенствованию и развитию версии ППП;

 журнал подготовленных и утвержденных корректировок, а также реализованных изменений в новой версии пакета;

 отчет о результатах эксплуатации снятой с сопровождения версии пакета;

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

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

 руководство администратора программного средства, кото­рое регламентирует функции администрирования, процедуры по инсталляции и подготовке ППП к эксплуатации, порядок и средства ведения базы данных и восстановления ин­формации при сбоях;

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

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

В процессе сопровождения в програм­мы вносятся различные изменения:

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

Выход коммерческого программного продукта на рынок про­граммных средств связан с организацией продаж массовому поль­зователю. Как правило, для каждого программного продукта существует своя форма кривой продаж, которая отражает спрос V во времени t (рис. 11).

Эксплуатация программного продукта идет параллельно с его сопровождением, при этом эксплуатация программ может начи­наться и в случае отсутствия сопровождения, или продолжаться в случае завершения сопровождения еще какое-то время. После сня­тия программного продукта с продажи его сопровождение может выполняться определенное время.

Рис. 11. Кривая продаж программного продукта

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

Длительность жизненного цикла для различных программных продуктов неодинакова. Для большинства современных программ­ных продуктов длительность жизненного цикла измеряется двумя-тремя годами. Хотя достаточно часто встречаются и давно снятые с производства программные продукты.

Источник