Удобство эксплуатации:

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

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

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

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

На значения критериев (показателей) качества ПС и изделий (продуктов) оказывают влияние:

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

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

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

• модульность – такое построение программ из отдельных компонент-модулей, при котором изменение одного из компонент-модулей оказывает минимальное воздействие на другие компоненты-модули.

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

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

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

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

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

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

Основные этапы создания программных средств и изделий (продуктов), входящих в состав по аис.

Жизненный цикл программного средства и изделия (продукта):

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

• проектирование структуры ПС в составе изделия;

• программирование (создание программного кода), тестирование (на соответствие поставленным требованиям), автономная и комплексная отладка программ (устранение ошибок);

• документирование ПС, подготовка эксплуатационной и технологической документации;

• продажа (распространение) программного изделия (продукта);

• эксплуатация программного изделия (продукта) пользователями;

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

• снятие программного изделия (продукта) с продажи, отказ от сопровождения.

Маркетинг и спецификация программного изделия (продукта) включает:

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

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

• установление требований пользователя к характеру взаимодействия с программ­ным изделием (продуктом), типу пользовательского интерфейса (система меню, использование манипулятора мышь, типы подсказок, виды экранных документов и т.п.);

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

• составление задания на разработку программного изделия (продукта).

Проектирование структуры ПС в составе программного изделия (продукта):

- детализацией функций обработки отдельными модулями;

- разработка структуры программного продукта (архитектуры программных модулей, извзаимосвязей);

- разработка структуры информационной базы (базы данных);

- выбор методов и средств создания программ - технологии программирования.

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

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

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

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

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

Требуется постоянная программа маркетинговых мероприятий и поддержки программных продуктов. Как правило, для каждого программного продукта существует своя форма кривой продаж, которая отражает спрос.

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

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

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

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

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

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

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

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

Основным недостатком каскадного подхода является существенное запаздывание с получением ре­зультатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ПО "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требова­ний или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. По некоторым статистическим оценкам, сделанным на ос­нове опыта разработок АСУ прошлых лет, по указанной причине переделывалось до 60-70% ПО АС.

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

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

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является полу­чившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается подход к разработке ПО, определяемый следующими условиями: небольшая команда программистов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказ­чиком.

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

Жизненный цикл ПО по концепции RAD состоит из четырех фаз: анализ и планирование требований; проектирование; построение; внедрение.

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

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

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

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

• общая информационная модель системы;

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

• точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

• построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

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

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

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

Взаимодействие специалистов при разработке и эксплуатации ПО

Постановщик задачи – определяет цели, назначение, требования и описание решаемой задачи, алгоритмы про­грамм.

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

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

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

Администрато­р базы данных - поддерживает работу и целостность базы данных, обеспечивает работу мно­гих приложений.

Конечный пользователь - основной потребитель прикладных программ в АИС (должен иметь элементарные знания и навыки работы с вычислительной техникой).

Особенности разработки программного обеспечения

1. Принципиальная невозможность исключения ошибок в программах.

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

Нельзя показать правильность ПС и его тестированием: тестирование может лишь продемонстрировать наличие в ПС ошибки. Альтер­нативой правильного ПС является надежное ПС.

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

3. Принципиальная незавершаемостьПС: при использовании созданных программ в составе АИС неиз­бежно возникает необходимость их доработки, связанная либо с исправлением скрытых дефектов программ, не обнаруженных на этапе проверки, либо с модификациями программ по запросам поль­зователей.

4. На сопровождение ПО АС приходится значительная доля трудозатрат (по различным ис­точникам, около 50 % или выше). Выполняются практически все виды работ, что и на первых четырех этапах разработки. Разница заключается лишь в том, что объектом проведения этих работ является уже готовая программа. При ее доработке может потребоваться внести изменения в экс­плуатационную документацию, исходные тексты программ или другую программную документа­цию.

Усредненное распределение трудозатрат по этапам жизненного цикла ПО

(по различным проблемным областям и реально выполненным разработкам)

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

Единая система про­граммной документации (ЕСПД) – определяется комплексом государственных стандартов (ГОСТ 19), ус­танавливающих правила разработки, оформления и обращения программ и программной документа­ции. Некоторые из них разработаны около 20 лет назад, однако ещё применяются из-за отсутствия новых стандартов.

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

Коды (номера) и содержание основных групп документов ЕСПД:

0 - основные термины и определения в области ПО; условные знаки и правила описания алгоритмов и программ.

1 - виды программ и программных документов; стадии разработки; обозначения программ и программных документов.

2 - требования к содержанию и оформлению технического задания на создание программного сред­ства.

3 - требования к содержанию и оформлению программы и методики испытаний программного сред­ства.

4 - требования к содержанию и оформлению документа «Описание программы».

5 - требования к содержанию и оформлению описания применения программного средства; требования к содержанию и оформлению руководств системного программиста, программиста и оператора.

Процедуры (этапы) проектирования программных систем

Процедура ГОСТ ЕСПД 19.0…

• Предпроектные исследования

• Техническое задание

• Эскизный проект

• Технический проект

• Рабочий проект

• Испытания

• Внедрение

Процедура GUIDS – методика создания объектно-ориентированной архитектуры

• Идея

• Требования

• Архитектура

• Создание

• Проверка

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

• Постановка задач

• Определение структур данных

• Определение формата структур данных

• Выбор алгоритма

• Обеспечение модульности

• Повторение предыдущих шагов для каждого модуля

Процедура проектирования на Visual Basic 5.0

• Разработка интерфейса пользователя

• Разработка баз данных

• Визуальное программирование

• Программирование процедур на Visual Basic 5.0

• Тестирование

Защита программных продуктов

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

Целями защиты являются: ограничение несанкционированного доступа к программам или их преднамеренное разрушение и хищение; исключение несанкционированного копирования (тиражирования) программ.

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

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

аппаратуры - подключение к компьютеру аппаратных средств для считывания программ и данных или их физического разрушения;

специализированных программ - приведение программного продукта или базы данных в неработоспособное состояние (например, вирусное заражение), несанк­ционированное копирование программ и базы данных и т.д.

Способы защиты программных продуктов и баз данных:

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

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

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

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

Различают две категории прав:

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

моральные, - обеспечивающие защиту личности автора в его произведении.

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

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

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

В лицензионном соглашении оговариваются все условия эксплуатации программ, в том числе создание копий.

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

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

Этикеточная лицензия — лицензия на одну копию программного продукта или базы данных.

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

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

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

Подготовка документации на программные средства (пс) в соответствии с имеющимися госТами

1. Основные вопросы при разработке программных средств

Когда программист-разработчик получает в той или иной форме задание на программирование, перед ним, перед руководителем проекта и перед всей проектной группой встают вопросы:

что должно быть сделано, кроме собственно программы?

что и как должно быть оформлено в виде документации?

что передавать пользователям, а что - службе сопровождения?

как управлять всем этим процессом?

что должно входить в само задание на программирование?

Кроме упомянутых вопросов есть и другие.

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

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

2. Общая характеристика состояния

Основу отечественной нормативной базы в области документирования ПС составляет комплекс стандартов Единой системы программной документации (ЕСПД). Основная и большая часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Сейчас этот комплекс представляет собой систему межгосударственных стандартов стран СНГ (ГОСТ), действующих на территории Российской Федерации на основе межгосударственного соглашения по стандартизации.

Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПС, и связаны, по большей части, с документированием функциональных характеристик ПС. Следует отметить, что стандарты ЕСПД (ГОСТ 19) носят рекомендательный характер. Впрочем, это относится и ко всем другим стандартам в области ПС (ГОСТ 34, Международному стандарту ISO/IEC, и др.). Дело в том, что в соответствии с Законом РФ "О стандартизации" эти стандарты становятся обязательными на контрактной основе - то есть при ссылке на них в договоре на разработку (поставку) ПС.

Говоря о состоянии ЕСПД в целом, можно констатировать, что большая часть стандартов ЕСПД морально устарела.

К числу основных недостатков ЕСПД можно отнести:

ориентацию на единственную, "каскадную" модель жизненного цикла (ЖЦ) ПС;

отсутствие четких рекомендаций по документированию характеристик качества ПС;

отсутствие системной увязки с другими действующими отечественными системами стандартов по ЖЦ и документированию продукции в целом, например, ЕСКД;

нечетко выраженный подход к документированию ПС как товарной продукции;

отсутствие рекомендаций по самодокументированию ПС, например, в виде экранных меню и средств оперативной помощи пользователю ("хелпов");

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

Итак, ЕСПД нуждается в полном пересмотре на основе стандарта ИСО/МЭК 12207-95 на процессы жизненного цикла ПС об этом стандарте далее будет сказано подробнее).

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

Международный стандарт ISO/IEC 12207: 1995-08-01 на организацию ЖЦ продуктов программного обеспечения (ПО) - казалось бы весьма неконкретный, но вполне новый и отчасти "модный" стандарт.

Стандарты комплекса ГОСТ 34 на создание и развитие автоматизированных систем (АС) - обобщенные, но воспринимаемые как весьма жесткие по структуре ЖЦ и проектной документации. Но эти стандарты многими считаются бюрократическими до вредности и консервативными до устарелости. Насколько это так, а насколько ГОСТ 34 остается работающим с пользой - полезно разобраться.

В своей статье Е.З.Зиндер подробно останавливается на методике Oracle CDM (Custom Development Method) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах АС с опорой на инструментарий Oracle.

2.1. Краткое представление стандартов еспд

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

стандарты ЕСПД вносят элемент упорядочения в процесс документирования ПС;

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

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

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

Стандарты ЕСПД (как и другие ГОСТы) подразделяют на группы, приведенные в таблице:

Обозначение стандарта ЕСПД строят по классификационному признаку:

Обозначение стандарта ЕСПД должно состоять из:

числа 19 (присвоенных классу стандартов ЕСПД);

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

двузначного числа (после тире), указывающего год регистрации стандарта.

Перечень документов ЕСПД.

ГОСТ 19.001-77 ЕСПД. Общие положения.

ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов.

ГОСТ 19.102-77 ЕСПД. Стадии разработки.

ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов.

ГОСТ 19.104-78 ЕСПД. Основные надписи.

ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам.

ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом.

ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.

ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению.

ГОСТ 19.301-79 ЕСПД. Порядок и методика испытаний.

ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению.

ГОСТ 19.402-78 ЕСПД. Описание программы.

ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению.

ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению.

ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению.

ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению.

ГОСТ 19.504-79 ЕСПД. Руководство программиста.

ГОСТ 19.505-79 ЕСПД. Руководство оператора.

ГОСТ 19.506-79 ЕСПД. Описание языка.

ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.

ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом.

ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.

ГОСТ 19.781-90. Обеспечение систем обработки информации программное.

Термины и определения.

Из всех стандартов ЕСПД остановимся только на тех, которые могут чаще использоваться на практике.

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

Гост (ст сэв) 19.201-78 (1626-79). Еспд. Техническое задание. Требование к содержанию и оформлению. (Переиздан в ноябре 1987г с изм.1).

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

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

• введение;

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

• назначение разработки;

• требования к программе или программному изделию;

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

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

• стадии и этапы разработки;

• порядок контроля и приемки;

• в техническое задание допускается включать приложения.

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

ГОСТ (СТ СЭВ) 19.101-77 (1626-79). ЕСПД. Виды программ и программных документов (Переиздан в ноябре 1987г с изм.1). Устанавливает виды программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.

Виды программ

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

Виды эксплуатационных документов

В зависимости от способа выполнения и характера применения программные документы подразделяются на подлинник, дубликат и копию (ГОСТ 2.102-68), предназначенные для разработки, сопровождения и эксплуатации программы.

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

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

Гост 19.102-77. Еспд. Стадии разработки.

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

Стадии разработки, этапы и содержание работ

Примечания:

Допускается исключать вторую стадию разработки, а в технически обоснованных случаях ? вторую и третью стадии. Необходимость проведения этих стадий указывается в техническом задании.

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

Гост 19.103-77 еспд. Обозначение программ и программных документов

Программа и ее документ "Спецификация" имеют следующую структуру обозначения:

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

Код страны-разработчика и код организации-разработчика присваивают в установленном порядке.

Регистрационный номер присваивается в порядке возрастания, начиная с 00001 до 99999, для каждой организации-разработчика.

Номер издания программы или номер редакции. номер документа данного вида, номер части документа присваиваются в порядке возрастания с 01 до 99. (Если документ состоит из одной части, то дефис и порядковый номер части не указывают).

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

Гост 19.105-78 еспд. Общие требования к программным документам.

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

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

Правила оформления документа и его частей на каждом носителе данных устанавливаются стандартами ЕСПД на правила оформления документов на соответствующих носителях данных.

Гост 19.106-78 еспд. Требования к программным документам, выполненным печатным способом.

Программные документы оформляют:

на листах формата А4 (ГОСТ 2.301-68) при изготовлении документа машинописным или рукописным способом;

допускается оформление на листах формата А3;

при машинном способе выполнения документа допускаются отклонения размеров листов, соответствующих форматам А4 и А3, определяемые возможностями применяемых технических средств; на листах форматов А4 и А3, предусматриваемых выходными характеристиками устройств вывода данных, при изготовлении документа машинным способом;

на листах типографических форматов при изготовлении документа типографским способом.

Расположение материалов программного документа осуществляется в следующей последовательности:

титульная часть:

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

титульный лист (первый лист документа);

информационная часть:

аннотация;

лист содержания;

основная часть:

текст документа (с рисунками, таблицами и т.п.)

перечень терминов и их определений;

перечень сокращений;

приложения;

предметный указатель;

перечень ссылочных документов;

часть регистрации изменений:

лист регистрации изменений.

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

Следующий стандарт ориентирован на документирование результирующего продукта разработки:

Гост 19.402-78 еспд. Описание программы.

Состав документа "Описание программы" в своей содержательной части может дополняться разделами и пунктами, почерпнутыми из стандартов для других описательных документов и руководств:

ГОСТ 19.404-79 ЕСПД. Пояснительная записка,

ГОСТ 19.502-78 ЕСПД. Описание применения,

ГОСТ 19.503-79 ЕСПД. Руководство системного программиста,

ГОСТ 19.504-79 ЕСПД. Руководство программиста,

ГОСТ 19.505-79 ЕСПД. Руководство оператора.

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

Надо также выделить

Гост 19.301-79 еспд. Программа и методика испытаний,

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

Наконец, последний по году принятия стандарт.

Гост 19.701-90 еспд. Схемы алгоритмов, программ, данных и систем. Обозначения условные графические и правила выполнения.

Он устанавливает правила выполнения схем, используемых для отображения различных видов задач обработки данных и средств их решения и полностью соответствует стандарту ИСО 5807:1985.

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

ГОСТ 19781-90 Обеспечение систем обработки информации программное. Термины и определения.

Разработан взамен ГОСТ 19.781-83 и ГОСТ 19.004-80 и устанавливает термины и определения понятий в области программного обеспечения (ПО) систем обработки данных (СОД), применяемые во всех видах документации и литературы, входящих в сферу работ по стандартизации или использующих результаты этих работ.

ГОСТ 28388-89 Системы обработки информации. Документы на магнитных носителях данных. Порядок выполнения и обращения.

Распространяется не только на программные, но и на конструкторские, технологические и другие проектные документы, выполняемые на магнитных носителях.

2.2. Стандарты комплекса гост 34

ГОСТ 34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов. Мотивы и получившиеся результаты описаны ниже в "Особенностях" ГОСТ 34. Объектами стандартизации являются АС различных (любых!) видов и все виды их компонентов, а не только ПО и БД.

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

Из всех существующих и не реализованных групп документов будем основываться только на Группе 0 "Общие положения" и Группе 6 "Создание, функционирование и развитие АС". Наиболее популярными можно считать стандарты ГОСТ 34.601-90 (Стадии создания АС), ГОСТ 34.602-89 (ТЗ на создание АС) и методические указания РД 50-34.698-90 (Требования к содержанию документов). Стандарты предусматривают стадии и этапы выполнения работ по созданию АС, но не предусматривают сквозных процессов в явном виде.

Для общего случая разработки АС стадии и этапы ГОСТ 34 приведены в таблице:

Описано содержание документов, разрабатываемых на каждом этапе. Это определяет потенциальные возможности выделения на содержательном уровне сквозных работ, выполняемых параллельно или последовательно (то есть по сути - процессов), и составляющих их задач. Такой прием может использоваться при построении профиля стандартов ЖЦ проекта, включающего согласованные подмножества стандартов ГОСТ 34 и ISO12207.

Главный мотив: разрешить проблему "вавилонской башни".

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

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

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

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

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

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

   • определять уровень качества результата;

   • выбирать те конкретные методики (с их моделями ЖЦ, набором документов и др.), которые наиболее подходят к условиям разработки и соответствуют используемым Информационным Технологиям;

   • работать, таким образом, с минимальными ограничениями эффективных действий проектировщика АС.

Разработчики комплекса стандартов 34 выбрали способ, близкий к первому из указанных выше, то есть пошли по пути, более близкому к схемам конкретных методик, чем к стандартам типа ISO12207. Тем не менее, благодаря общности понятийной базы стандарты остаются применимыми в весьма широком диапазоне случаев.

Степень адаптивности формально определяется возможностями:

• опускать стадию эскизного проектирования и объединять стадии "Технический проект" и "Рабочая документация";

• опускать этапы, объединять и опускать большинство документов и их разделов;

• вводить дополнительные документы, разделы документов и работы;

• динамически создавая т. н. ЧТЗ - частные технические задания - достаточно гибко формировать ЖЦ АС; как правило, этот прием используется на уровне крупных единиц (подсистем, комплексов), ради которых считается оправданным создавать ЧТЗ, однако нет никаких существенных оснований сильно ограничивать этот способ управления ЖЦ.

Стадии и этапы, выполняемые организациями - участниками работ по созданию АС, устанавливаются в договорах и техническом задании, что близко к подходу ISO.

Введение единой, достаточно качественно определенной терминологии, наличие достаточно разумной классификации работ, документов, видов обеспечения и др. безусловно полезно. ГОСТ 34 способствует более полной и качественной стыковке действительно разных систем, что особенно важно в условиях, когда разрабатывается все больше сложных комплексных АС, например, типа CAD-CAM, которые включают в свой состав АСУТП, АСУП, САПР-конструктора, САПР-технолога, АСНИ и др. системы.

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

Разделение понятий ПТК и АС закрепляло принцип, по которому АС есть не "ИС с БД", но:

• "организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т. д.) или их сочетаниях" (по РД 50-680-88), что особенно актуально в аспектах бизнес-реинжиниринга;

• "система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций" (по ГОСТ 34.003-90).

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

Степень обязательности:

прежняя полная обязательность отсутствует, материалы ГОСТ34 по сути стали методической поддержкой, причем чаще для заказчиков, имеющих в стандарте набор требований к содержанию ТЗ и проведению испытаний АС. При этом польза ГОСТ34 может многократно возрасти в случае их более гибкого использования при формировании профиля ЖЦ АС.

Ключевым документом взаимодействия сторон является ТЗ - техническое задание на создание АС. ТЗ является основным исходным документом для создания АС и его приемки, ТЗ определяет важнейшие точки взаимодействия заказчика и разработчика. При этом ТЗ разрабатывает организация-разработчик (по ГОСТ 34.602-89), но формально выдает ТЗ разработчику заказчик (по РД 50-680-88).

2.3. Государственные стандарты рф (гост р)

В РФ действует ряд стандартов в части документирования ПС, разработанных на основе прямого применения международных стандартов ИСО. Это - самые "свежие" по времени принятия стандарты. Некоторые из них впрямую адресованы руководителям проекта или директорам информационных служб. Вместе с тем они неоправданно мало известны в среде профессионалов. Вот их представление.

ГОСТ Р ИСО/МЭК 9294-93 Информационная технология. Руководство по управлению документированием программного обеспечения. Стандарт полностью соответствует международному стандарту ИСО/МЭК ТО 9294:1990 и устанавливает рекомендации по эффективному управлению документированием ПС для руководителей, отвечающих за их создание. Целью стандарта является оказание помощи в определении стратегии документирования ПС; выборе стандартов по документированию; выборе процедур документирования; определении необходимых ресурсов; составлении планов документирования.

ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению. Стандарт полностью соответствует международному стандарту ИСО/МЭК 9126:1991. В его контексте под характеристикой качества понимается "набор свойств (атрибутов) программной продукции, по которым ее качество описывается и оценивается". Стандарт определяет шесть комплексных характеристик, которые с минимальным дублированием описывают качество ПС (ПО, программной продукции): функциональные возможности; надежность; практичность; эффективность; сопровождаемость; мобильность. Эти характеристики образуют основу для дальнейшего уточнения и описания качества ПС.

ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов. Стандарт полностью соответствует международному стандарту ИСО 9127:1989. В контексте настоящего стандарта под потребительским программным пакетом (ПП) понимается "программная продукция, спроектированная и продаваемая для выполнения определенных функций; программа и соответствующая ей документация, упакованные для продажи как единое целое". Под документацией пользователя понимается документация, которая обеспечивает конечного пользователя информацией по установке и эксплуатации ПП. Под информацией на упаковке понимают информацию, воспроизводимую на внешней упаковке ПП. Ее целью является предоставление потенциальным покупателям первичных сведений о ПП.

ГОСТ Р ИСО/МЭК 8631-94 Информационная технология. Программные конструктивы и условные обозначения для их представления. Описывает представление процедурных алгоритмов.

2.4. Международный стандарт iso/iec 12207: 1995-08-01

Первая редакция ISO12207 подготовлена в 1995 году объединенным техническим комитетом ISO/IEC JTC1 "Информационные технологии, подкомитет SC7, проектирование программного обеспечения".

По определению, ISO12207 ? базовый стандарт процессов ЖЦ ПО, ориентированный на различные (любые!) виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.

Очень важные ЗАМЕЧАНИЯ СТАНДАРТА:

1. Процессы, используемые во время ЖЦ ПО, должны быть совместимы с процессами, используемыми во время ЖЦ АС. (Отсюда понятна целесообразность совместного использования стандартов на АС и на ПО.)

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

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

ОПРЕДЕЛЕНИЯ СТАНДАРТА:

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

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

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

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

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

Каждый процесс ЖЦ разделен на набор действий, каждое действие - на набор задач. Очень важное отличие ISO: каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.).

В стандарте ISO12207 описаны:

1. 5 основных процессов ЖЦ ПО:

   • Процесс приобретения. Определяет действия предприятия-покупателя, которое приобретает АС, программный продукт или сервис ПО.

   • Процесс поставки. Определяет действия предприятия-поставщика, которое снабжает покупателя системой, программным продуктом или сервисом ПО.

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

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

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

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

   • решения проблем;

   • документирования;

   • управления конфигурацией;

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

     • Процесс верификации;

     • Процесс аттестации;

     • Процесс совместной оценки;

     • Процесс аудита.

3. 4 организационных процесса:

   • Процесс управления;

   • Процесс создания инфраструктуры;

   • Процесс усовершенствования;

   • Процесс обучения.

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

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

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

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

Примеры:

• выполнение Процесса приобретения в части анализа и фиксации требований к системе или ПО может вызывать исполнение соответствующих задач Процесса разработки;

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

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

Такой характер позволяет реализовывать любую модель ЖЦ.

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

При этом разработчик должен установить и документировать как требования к программному обеспечению:

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

2. Внешние связи (интерфейсы) с единицей программного обеспечения;

3. Требования квалификации;

4. Спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и вероятностью травмы персонала;

5. Спецификации защищенности,

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

7. Определение данных и требований базы данных;

8. Установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации);

9. Документация пользователя;

10. Работа пользователя и требования выполнения;

11. Требования сервиса пользователя.

(Интересно и важно, что эти и аналогичные характеристики хорошо корреспондируются с характеристиками АС, предусматриваемыми в ГОСТ 34 по видам обеспечения системы.)

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

Итак, ISO12207 имеет набор процессов, действий и задач, охватывающий наиболее широкий спектр возможных ситуаций при максимальной адаптируемости.

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

По этой причине центральным стандартом, положения которого берутся за начальный "стержневой" набор положений в процессе построения профиля стандартов ЖЦ для конкретного проекта, полезно рассматривать именно ISO12207. Этот "стержень" может задавать модель ЖЦ ПО и АС, принципиальную схему гарантирования качества, модель управления проектом

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

В настоящее время во ВНИИ стандартов подготовлены предложения по совершенствованию и развитию комплекса стандартов по документированию ПС.

Справочная информация

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

ИПК "Издательство стандартов", Территориальный отдел распространения НТД (магазин "Стандарты"), 17961, Москва, ул. Донская, д. 8, тел. 236-50-34, 237-00-02, факс/тел. 236-34-48 (в части ГОСТ и ГОСТ Р).

ВНИИКИ Госстандарта России (читальный зал), 103001, Москва, Гранатный пер. д. 4, тел. 290-50-94 (в части международных, зарубежных стандартов и других НТД).

2.?? Стадии разработки по, регламентированных госТами.

В нашей стране жизненный цикл разработки ПО установлен стандартом ГОСТ 19.102-77 Стадии разработки программ и программной документации и содержит следующие стадии и этапы: 1. Техническое задание (ТЗ). 2. Эскизный проект (ЭП). 3. Технический проект (ТП). 4. Рабочий проект (РП). 5. Внедрение. В табл. 2.1 показаны стадии разработки и этапы, их составляющие. Неверно предполагать, что жизненный цикл разработки ПО согласно ГОСТ 19.102-77 есть последовательное выполнение стадий и этапов, определенных в таблице 2. В реальном жизненном цикле трудно провести четкую и определенную границу между этапами, а сам процесс создания ПО является итеративным: после завершения некоторого этапа почти всегда есть необходимость в коррекции уже выполненных этапов и стадий с целью внесения уточнений. При разработке принципиально нового ПО иногда бывает необходимо осуществить пробную реализацию с целью получения информации, требующейся для принятия решения на некоторой стадии.

Таблица 2.1

Стадии разработки	Этапы работ
Техническое задание	1. Обоснование необходимости разработки программ. 2. Выполнение научно-исследовательских работ (НИР). 3. Разработка и утверждение технического задания.
Эскизный проект	1. Разработка эскизного проекта. 2. Утверждение эскизного проекта.
Технический проект	1. Разработка технического проекта. 2. Утверждение технического проекта.
Рабочий проект	1. Разработка программы. 2. Разработка программной документации. 3. Испытание программы.
Внедрение	1. Подготовка и передача программы.

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

Техническое задание.

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

выбор языков программирования; определение необходимости проведения НИР на последующих стадиях; согласование и утверждение ТЗ.

Результатом выполнения данной стадии является техническое задание, оформленное в соответствии с ГОСТ 19.105-78 (изм. 09.1981.) Общие требования к программным документам и ГОСТ 19.106-78 Общие требования к программным документам, выполненным печатным способом на листах формата 11 и 12 (по ГОСТ 2.301-68). Эскизный проект. Основные этапы и содержание работ на стадии Эскизный проект приведены в таблице 2.2.

Таблица 2.2

Этапы работ	Содержание
Разработка ЭП	1. Предварительная разработка структуры входных и выходных данных. 2. Уточнение методов решения задач. 3. Разработка общего описания алгоритма решения задачи. 4. Разработка технико-экономического обоснования.
Утверждение ЭП	1. Разработка пояснительной записки. 2. Согласование и утверждение эскизного проекта.

Конкретное содержание работ стадии эскизного проекта и их объем определяет степень сложности разрабатываемого ПО. Результатом выполнения данной стадии является полное описание архитектуры ПО. Как правило, это описание делается на нескольких уровнях иерархии. На верхнем уровне детализации выделяются основные подсистемы, которым присваиваются имена, устанавливаются связи между подсистемами, их функции, получаемые путем декомпозиции предполагаемых функций ПО. Затем процедура декомпозиции выполняется для каждой подсистемы, выделяются модули, составляющие данную подсистему. В конечном итоге, получается иерархически организованная система, состоящая из уровней, каждый из которых представляет собой совокупность взаимосвязанных модулей. Единицы, выделяемые на различных иерархических уровнях функциональной архитектуры системы, определяются по усмотрению разработчика. Стандарты ЕСПД различают программные единицы только с точки зрения их документирования. Результаты эскизного проекта отображаются в документе Пояснительная записка к эскизному проекту, оформленному в соответствии с ГОСТ 19.105-78 и ГОСТ 19.404-79. После утверждения пояснительной записки она становится программным документам, правила дублирования, учета, хранения которого определяется ГОСТ 19.601-78 Общие правила дублирования, обращения, учета и хранения и ГОСТ 19.602-78 Правила дублирования, учета и хранения программных документов, выполненных печатным способом. Последующие стадии и этапы разработки ПО могут выявить необходимость внесения изменений в ЭП. Эти изменения должны быть отражены в пояснительной записке в соответствии с ГОСТ 19.603-78 Общие правила внесения изменений в программные документы и ГОСТ 19.602-78 Правила внесения изменений в программные документы, выполненные печатным способом. В качестве примера, ниже приводится фрагмент расширенного описания работ стадии эскизного проекта. 1. Разработка эскизного проекта ПО. разработка плана совместных работ на разработку ПО; разработка и обоснование математической модели системы на ЭВМ и описание результатов моделирования; разработка и обоснование алгоритмов и временных графиков функционирования ПО по всем режимам работы; разработка и обоснование ресурсов памяти для реализации алгоритмов; разработка перечня документов на ПО; разработка и обоснование структуры БД, внешних входных и выходных данных; разработка и обоснование алгоритмов информационного обеспечения; определение взаимосвязей между видами программ; разработка и обоснование набора тестов для проверки ПО; разработка и обоснование организации наращивания и развития ПО; оформление пояснительной записки и ведомости эскизного проекта ПО (в соответствии с ГОСТ 19.105-78, ГОСТ 19.404-79 и ГОСТ 2.106-68 ЕСКД. Текстовые документы); согласование и утверждение ЭП.

Технический проект.

Основные этапы и содержание работ на стадии Технический проект приведены в таблице 2.3. Содержанием работ на этой стадии является проектирование структуры ПО. Результатом - реализующий заданный и утвержденный в техническом задании комплекс программ как иерархическая структура программных модулей, заданных своими функциональными спецификациями. Форма представления результата - Пояснительная записка к техническому проекту согласно ГОСТ 19.105-78, ГОСТ 19.404-79. Разработка структуры ПО заключается в выделении всех программных компонентов по функциональным признакам, определение функциональных спецификаций модулей и уточнение внешних функциональных спецификаций, структуры входных и выходных данных, определении операционной среды, языковых средств и конфигурации аппаратных средств. Спецификации модулей являются внешними характеристиками и содержат все сведения, необходимые вызывающим модулям. На последующих стадиях разработки спецификации оформляются в виде комментариев в начале текста исходной программы модуля. На данной стадии спецификации оформляются в виде комментария на принятом в организации, занимающейся разработкой ПО, языке спецификаций

Таблица 2.3.

Этапы работ	Содержание
Разработка ТП	1. Уточнение структуры входных и выходных данных. 2. Разработка алгоритмов решения задач. 3. Определение формы представления входных и выходных данных. 4. Определение синтаксиса и семантики языка. 5. Разработка структуры программы. 6. Окончательное определение конфигурации технических средств.
Утверждение ТП	1. Разработка плана мероприятий по разработке и внедрению программ. 2. Разработка пояснительной записки. 3. Согласование и утверждение ТП.

Фрагмент описания работ стадии технического проекта приведен ниже. 1. Разработка технического проекта ПО.

разработка плана совместных работ на разработку ПО; распараллеливание задач применительно к возможностям ЭВМ и систем обмена информации и разработка организационной структуры программ; формализация программно-аппаратных и внутризадачных интерфейсов; разработка алгоритмов управления вычислительным процессом и процессами обмена, его исследование и оптимизация; разработка и комплексное решение вопросов обеспечения устойчивой работы на программном уровне; разработка модели и исследование на ней возможности реализации всех функций системы управления в рамках имеющихся вычислительных ресурсов на основе выбранного управляющего алгоритма и оптимизация структуры программ до получения удовлетворяющего результата; уточнение структуры и определение формы представления БД, внешних входных и выходных данных; разработка проекта описания программы для каждого вида программ ПО; уточнение алгоритмов ПО и алгоритмов информационного обеспечения в процессе решения задач; разработка проекта описания текстовых программ ПО; разработка плана реализации ПО; разработка проектов технических условий на ПО; разработка и обоснование решений по надежности функционирования ПО; разработка программы и правил испытаний ПО; уточнение временных графиков функционирования программ ПО в процессе решения задач; оформление пояснительной записки и ведомости технического проекта ПО (в соответствии с ГОСТ 19.105-78, ГОСТ 19.404-79 и ГОСТ 2.106-68 ЕСКД. Текстовые документы); согласование и утверждение ТП. Рабочий проект. Основные этапы и содержание работ на стадии Рабочий проект приведены в таблице 2.4.

Таблица 2.4

Этапы работ	Содержание
Разработка ПО	Программирование и отладка программ.
Разработка программной документации	1. Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77.
Испытание ПО	1. Разработка, согласование и утверждение программ и методики испытаний 2. Проведение предварительных государственных, межведомственных приемо-сдаточных и других видов испытаний. 3. Корректировка ПО и программной документации по результатам испытаний.

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

Кроме рассмотренного выше жизненного цикла программ, установленного 19 - ой системой стандартов, необходимо иметь в виду, что существует жизненный цикл автоматизированных систем, установленный ГОСТ 34.601-90.

Имеет смысл рассмотреть стадии и этапы разработки АС, так как 19-я система стандартов в настоящее время морально устарела и более современным представляется жизненный цикл АС. Анализ жизненных циклов разработки ПО, установленных ГОСТ 19.102 и ГОСТ 34.601, а также международных стандартов, регламентирующих данный процесс, будет приведен ниже.

2. Постановка задачи на создание инструментальных программных средств реализации ин­формационных технологий.

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

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

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

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

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

• содержание функций обработки входной информации при решении задачи;

• требования к периодичности решения задачи;

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

• состав и форма представления выходной информации;

• источники входной информации для решения задачи;

• пользователи задачи (кто осуществляет ее решение и пользуется результатами реше- ния).

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

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

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

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

Алгоритм решения задачи имеет ряд обязательных свойств:

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

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

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

• массовость — пригодность алгоритма для решения определенного класса задач.

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

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

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