16. Виды документов, выпускаемых на ПО по этапам разработки системы.

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

22

разработчика ЦВМ,

разработчика ОС,

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

разработчика системы, использующей встроенную ЦВУ и ПО для неё.

разработчика прикладного ПО,

пользователя ПО.

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

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

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

Можно выделить три категории документов на ПО:

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

Документация на программную продукцию(конструкторская, эксплуатационная, ТУ),

Документация управления проектом.

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

Впроектных документах определяются:

цели функционирования системы,

критерии эффективности функционирования системы и их значения,

структура системы - разбиение системы на составные части и взаимодействие частей,

устройство и характеристики подсистем,

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

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

[Введите текст]

Большая часть информации, содержащейся в проектной документации, непосредственно при производ-

стве и эксплуатации системы не используется. Эта информация и документы разработчика она объясняет

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

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

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

Конструкторская документация на ПО - тексты программ ПО или код программ ПО, загружаемый на исполнение в ЦВМ.

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

Эксплуатационно-техническая документация на ПО (ЭТД) содержит эти сведения, а также описание алгоритма, входных и выходных данных , и т.п.

Кроме того на программную продукцию имеется документ, называемый формуляр или ТУ. Этот документ говорит каким характеристикам соответствует программное изделие и оговаривает методы проверки этих характеристик при приёмосдаточных испытаниях.

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

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

17.Итеративный характер проектирования ПО. Стадии проектирования.

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

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

24

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

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

1)формирование требований к системе,

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

3)разработка и утверждение технического задания (ТЗ) на систему,

4)эскизный проект на систему

5)технический проект, на этой стадии выпускается рабочая документация.

Технические предложения и эскизный проект защищаются перед заказчиком системы.

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

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

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

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

Задачи, решаемые на различных стадиях проектирования ПО.

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

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

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

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

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

18. Цена ошибок проектирования. Проектирование, основанное на моделиро-

вании (Model-Based Systems Engineering - MBSE).

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

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

пах жизненного цикла ПО.

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

26