Сопровождение (продолжение) Документирование сопровождения - pismo.netnado.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Сопровождение (продолжение) Документирование сопровождения - страница №1/1

Сопровождение

(продолжение)

Документирование сопровождения
Существует большая разница между тем, чтобы просто написать и запрограммировать некоторую функцию и тем, чтобы изготовить её как качественный программный продукт. В идеале слово “продукт” подразумевает, что программа и все, что связано с процессом ее создания, полностью отчуждается от создателя и может жить и развиваться без его участия. А главное условие для этого – качественная документация.

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

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

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

При создании особо сложных систем целесообразно выделение специального кол­лектива, обеспечивающего организацию и реализацию основных сис­темных работ по документообороту. Совокупные затраты на документирование крупных программных продуктов могут достигать 20 – 30% от общей трудоемкости проекта и от задействованного в проекте числа специалистов.
На каждый программный продукт должна разрабатываться документация двух типов:


  • для разработчиков;

  • для пользователей различных групп.

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


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

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

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

Текст программы с необходимыми комментариями.

Описание программы - сведения о логической структуре и функционировании программы.

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


Непосредственно для пользователя используются:

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

Руководство системного программиста - сведения для проверки, обеспечения функционирования и настройки программы в конкретных условиях.

Руководство программиста - сведения для эксплуатации программного обеспечения.

Руководство оператора - сведения для обеспечения процедуры общения оператора с вычислительной системой.

Руководство по техническому обслуживанию - сведения для применения тестовых и диагностических программ при обслуживании технических средств.

Программа и методика испытаний должны содержать требования, подлежащие проверке при испытании программного обеспечения, а также порядок и методы их контроля.

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

Содержание пояснительной записки по стандарту (ГОСТ 19.404—79) должно включать следующие разделы:



  • введение;

  • назначение и область применения;

  • технические характеристики;

  • ожидаемые технико-экономические показатели;

  • источники, используемые при разработке.

Раздел “Технические характеристики” должен содержать следующие подразделы:



  • постановку задачи

  • описание применяемых математических методов;

  • описание алгоритмов функционирования программы;

  • описание организации входных и выходных данных;

  • описание состава технических и программных средств.

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

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



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

  • излагайте ясно, используйте короткие предложения;

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

  • будьте точны и рациональны — длинные и запутанные руководства обычно никто не читает, например, лучше привести рисунок формы, чем долго ее описывать.

Руководство пользователя”, как правило, содержит следующие разделы:



  • общие сведения о программном продукте;

  • описание установки;

  • описание запуска;

  • инструкции по работе (или описание пользовательского интерфейса);

  • сообщения пользователю.

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


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

  • общие сведения о программном продукте;

  • структура;

  • настройка;

  • проверка;

  • дополнительные возможности;

  • сообщения системному программисту.

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

Структура программы” - сведения о составных частях программы и связях между ними.

Проверка программы” - описание способов проверки работоспособности программы, например контрольные примеры.

Сообщения системному программисту” - тексты сообщений, выдаваемых в ходе выполнения настройки и проверки программы, а также в ходе ее выполнения, описание их содержания и действий, которые необходимо предпринять по этим сообщениям.
Какое, собственно, отношение описанная выше система документирование имеет к сопровождению? Надо ясно понимать, что сопрвождение – это большая часть жизненного цикла программного продукта. Именно – продукта, а не просто программы. Живого организма, достигшего своей зрелости и постепенно дряхлеющего в силу объективных законов природы.

Все доработки или усовершенствования, которые неизбежно происходят во время сопровождения, должны обязательно основываться на имеющейся документации и сопровождаться необходимыми доработками и имзменениями в документировании. При этом должна сохраняться непротиворечивость и адекватность. Для сложного программного комплекса это возможно только при очень хорошо организованной системе документирования, включающей разного рода способы автоматизации управления проектом. Это так называемые CASE-средства (Computer-Aided Software/System Engineering).

Стандарт оформления проектной документации должен устанавливать:


  • комплектность, состав и структуру документации на каждой стадии проектирования;

  • требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),

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

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

  • требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.



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

В нашем представлении слово “стандартный” обозначает – обычный, один из многих таких же. Делать стандартно – значит делать так, как делали до тебя уже много раз. Идея стандартизации в том и состояла, чтобы сделать много, чтобы это было быстро, дешево, хватило на всех.

В области информационных технололий понятие стандарта начинает несколько модифицироваться. Почему, например, клавиша Esc на любой клавиатуре расположена в левом верхнем углу и имеет во всех программах примерно одинаковое значение? Этот стандарт де-факто возник как результат опробования разных вариантов. Один из них получил наибольшее распространение. Может он и не самый лучший, но достаточно удобен. Дельше – дело случая и стремления всех участников компьютерного сообщества к скорейшему распространению своих разработок. Разработчики программ или компьютеров внимательно следят за самыми распространенными решениями и стараются присоединиться к большинству. Иначе они просто теряют шансы на популярность. В результате популярные решения растут как снежный ком и быстро становятся “стандартными”. Стандартные компьютерные интерфейсы, стандартные резмеры мониторов, стандартное расположение клавиш … Сеть авторитетных в мире институтов стандартизации в этом процессе играет роль катализатора. Принятие какого-то ANSI-стандарта служит для тысяч разработчиков по всему миру сигналом в скорейшему переходу на этот стандарт. И это автоматически приводит к реальному ускорению прогресса. Ведь действительно, есть масса удобств в том, что все одинаково понимают язык “C” или HTML или CSS-таблицы. Здесь есть что-то похожее на то, как муравьи с помощью пахучих меток управляют своими колониями.

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

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

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


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

За последние 20 лет разработано множество стандартов для разработки и документирования жизненого цикла ПО (см. приложение к лекции 07), что пора уже подумать о стандарте на стандарты.. Назовем эти стандарты базовыми.

Признанными лидерами в разработке стандартов являются следующие организации:


  • Американский Национальный институт стандартов (ANSI).

  • Институт инженеров по электронике и радиоэлектронике IEEE (США).

  • Международная организация по стандартизации (ISO). ЕС предписывает следование стандартам ISO любой организации, имеющей дело со странами Евросоюза.

  • Институт технологий программного обеспечения SEI, учрежденный Министерством обороны США.


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

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

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

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

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

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

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


  • группы стандартов управления жизненным циклом сложных проектов систем и программных средств, возглавляемой стандартами менеджмента – CMMI и ISO 9000;

  • группы стандартов проектирования, разработки, сопровождения и управления конфигурацией – ISO 15288 и ISO 12207;

  • группы стандартов оценивания и обеспечения качества, безопасности и документирования в жизненном цикле программных средств, с головными стандартами – ISO 9126 и ISO 25000.


Содержание некоторых стандартов
Описание тестирования:

Стандарт ANSI/IEEE 829-1983 на Документацию по тестированию программного обеспечения (STD — Software Test Documentation) содержит разделы:



  • План тестирования (Тестируемые элементы, границы, подход, ресурсы, расписание, персонал).

  • Проект тестирования (Тестируемые элементы, подход, план в подробностях).

  • Тестовые варианты (Наборы входных данных и событий).

  • Тестовые процедуры (Шаги настройки и выполнения тестовых вариантов).

  • Отчет о проведении тестирования элементов (Тестируемый элемент, физическое местоположение результатов, ответственный за проведение тестов).

  • Журнал испытаний (Хронологическая запись, физическое местоположение теста, название теста).

  • Отчет о происшествиях во время тестирования (Документирование любого события, имевшего место во время тестирования, требующего дальнейших расследований).

  • Итоговый отчет о тестировании (Итог всего перечисленного).

Концептуальные и организационные основы административного управления жизненным циклом и качеством ПС в системе СММ, а также CMMI:2003, определены в восьми базовых принципах, которые декларированы в стандартах ISO 9000:2000 и ISO 15504:1-9.



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

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

Принцип 3 Вовлечение персонала. “Люди составляют сущность предприятия на всех уровнях, и их полноценное участие в деятельности способствует применению их способностей на благо целей предприятия”.

Принцип 4 Процессный подход. “Желаемый результат достигается более эффективно, когда требуемые ресурсы и деятельность специалистов предприятия управляются как единый связанный процесс”.

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

Принцип 6 Постоянное усовершенствование. “Непрерывное усовершенствование процессов и повышение качества продукции должно быть постоянной стратегической целью предприятия и его специалистов”.

Принцип 7 Подход к принятию решений основанный на фактах. “Эффективные решения должны базироваться на анализе только реальных данных и достоверной информации”.

Принцип 8 Взаимовыгодные отношения с поставщиками. “Предприятие-пользователь и его поставщики-разработчики взаимозависимы, и взаимовыгодные отношения между ними повышают способность обоих производить качественную продукцию”.

В стандарте ISO 15504 каждый из приведенных принципов прокомментирован комплексом действий, необходимых для их реализации в проектах.


ISO 9126-1—ISO 9126-4 - характеристики качества.

Первая часть ISO 9126-1 распределяет атрибуты качества программных средств по шести характеристикам, используемым в остальных частях стандарта.

ISO 9126-2 и ISO 9126-3 — посвящены формализации соответственно внешних и внутренних метрик характеристик качества сложных программных средств.

ISO 9126-4 — предназначена для покупателей, поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества программных средств. В ней обосновываются и комментируются выделенные показатели сферы (контекста) использования программных средств и группы выбранных метрик для пользователей.


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

  • стандарт IEEE 830-1993,

    • результат: спецификация требований к программному обеспечению (SRS – Software Requirement Specification), включающая

      • общее описание (С-требования или требования заказчика)

      • конкретные требования (D-требования или требования разработчика);




  • стандарт ГОСТ 19.201-78 (ГОСТ 34.602-89),

    • результат:

      • техническое задание (С-требования или требования заказчика)

      • функциональная спецификация (D-требования или требования разработчика).