8 Этапы технического проектирования систем. Стр 18
Этапы подразделяют на составные части – проектные процедуры(подготовка чертежей,оптимизация параметров итд) Процедуры можно разделить на более мелкие проектные операции. Проектированиe делится на стадии, этапы и процедуры. При проектировании сложных объектов выделяют стадии
научно-исследовательских работ (НИР),
опытно-конструкторских работ (ОКР) или Этап эскизного проекта
технического проекта,
рабочего проекта,
испытаний опытного образца.
Стадию НИР во многих случаях можно разделить на стадии
предпроектных исследований,
технического задания,
технического предложения.
На этих стадиях последовательно изучаются потребности в получении новых изделий с заданным назначением, исследуются физические, информационные, конструктивные и технологические принципы построения изделий и возможности реализации этих принципов, прогнозируются возможные значения характеристик и параметров объектов.
Результатом НИР является формулировка технического задания (ТЗ) на разработку нового объекта.
На стадии ОКР разрабатывается эскизный проект изделия, проверяются, конкретизируются и корректируются принципы и положения, установленные на стадии НИР.
На стадии технического проекта принимаются подробные технические решения и прорабатываются все части проекта. На стадии рабочего проекта создается полный комплект конструкторско-технологической документации, достаточный для изготовления объекта.
На стадии испытаний опытного образца (или пробной партии при крупносерийном производстве) получают результаты, позволяющие выявить возможные ошибки и недоработки производства изделий.
Проектирование разделяется также на этапы.
Этап проектирования – это условно выделенная часть проектирования, сводящаяся к выполнению одной или нескольких проектных процедур, объединенных по признаку принадлежности получаемых проектных решений к одному иерархическому уровню и (или) аспекту описаний. Проектная процедура – часть проектирования, заканчивающаяся получением проектного решения. Примерами проектных процедур служат синтез функциональной схемы устройства, оптимизация параметров функционального узла….
9
Внешнее проектирование в первую очередь охватывает обоснование требований к системе и обобщение сведений об объекте исследования
Завершение внешнего проектирования является поворотным моментом для всего проекта. Процесс внешнего проектирования и предшествовавшие процессы концентрировались вокруг взаимодействия системы и пользователя; остальные процессы проектирования касаются внутренней структуры программного обеспечения. По этой причине проверка их правильности приобретает исключительное значение.
Этап внутреннего проектирования направлен преимущественно на синтез системы, удовлетворяющей поставленным техническим условиям. Этот этап в первую очередь связан с рассмотрением, расчетом и сопоставлением ряда возможных вариантов технических реализаций. На этом этапе осуществляется последовательное приближение к выбору наилучшего в данном случае варианта принципа действия системы. ЗЦ, так и точные ( количественные) методы синтеза
Внутреннее проектирование определяет, как изделие должно функционировать. Модули, подпрограммы, оверлейные структуры, динамические таблицы, блок-схемы и таблицы решений являются строительным материалом при внутреннем проектировании
В инженерном проектировании следует различать "внутреннее" и "внешнее" проектирование. Первое связано с созданием рабочих чертежей (технического и рабочего проектов), которые служат основными документами для изготовления технической системы на производстве; второе - направлено на проработку общей идеи системы, ее исследование с помощью теоретических средств, разработанных в соответствующей технической науке.
Иногда разработку ТЗ наз. Внешним проектированием, а реализацию – внутренним
10
ехническое задание - это основа порядка в работе над проектом и главный ориентир. Только по выполнению всех требований, отмеченных в ТЗ, проект может считаться законченным.
Место ТЗ в структуре проектирования
Проектирование — это процесс (разработки проекта), который обладает определённой структурой, то есть последовательностью и составом стадий и этапов, совокупностью процедур и привлекаемых технических средств, взаимодействием участников процесса.
Стадии проектирования регламентированы стандартами.
Техническое задание (по ГОСТ 2.103-68 к стадиям разработки не относится),
Техническое предложение,
Эскизный проект,
Технический проект,
Стадии рабочего проекта.
Решение любой задачи начинается с её осмысления и уточнения исходных данных. Те (технические) требования, которые выдаются заказчиком, формулируются на языке потребителя-неспециалиста и не всегда бывают технически четкими и исчерпывающими. Перевести требования на язык предметной области, сформулировать задачу максимально полно и грамотно, обосновать необходимость её решения, это и есть главная цель ТЗ, обязательный этап работы. Исполнитель выполняет его в тесном контакте с заказчиком. Фактически это означает, что работа исполнителя над проектом уже началась. В машиностроении этот этап иногда называют внешним проектированием.
Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.
В тз указывают след. Данные:
1)назначение объекта
2)условия эксплуатации
3)требования к выходным параметрам (в виде условий работоспособности)
Ко всему прочему, ТЗ должно содержать и сроки выполнения работ. Конечно же, эта часть технического задания прописывается, когда описания всех разделов, функционалов и требований сформированы.
Техническое задание (также — техзадание, ТЗ) — технический документ (спецификация), оговаривающий набор требований к системе и утверждённый как заказчиком/пользователем, так и исполнителем/производителем системы. Такая спецификация может содержать также системные требования и требования к тестированию.
Техническое задание позволяет:
исполнителю — понять суть задачи, показать заказчику «технический облик» будущего изделия, программного изделия или автоматизированной системы;
заказчику — осознать, что именно ему нужно;
обеим сторонам — представить готовый продукт;
исполнителю — спланировать выполнение проекта и работать по намеченному плану;
заказчику — требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ;
исполнителю — отказаться от выполнения работ, не указанных в ТЗ;
заказчику и исполнителю — выполнить попунктную проверку готового продукта (приёмочное тестирование — проведениеиспытаний);
избежать ошибок, связанных с изменением требований (на всех стадиях и этапах создания, за исключением испытаний).
В зависимости от ожиданий заказчика существует три альтернативы для выбора шаблона Технического задания. Если заказчик требует оформления документации в соответствии с государственным стандартом, выбор делается в сторону стандарта ГОСТ 34.602-89. Подготовка Технического задания по ГОСТ 34.602-89 требует значительных временных затрат.
Если поставлены сжатые сроки подготовки ТЗ и заказчик не требует оформления документации в соответствии с государственным стандартом, то можно использовать шаблон технического задания по стандарту IEEE Std 830. Стандарт IEEE Std 830 предполагает, что детальные требования могут быть обширными и не существует оптимальной структуры для всех систем. По этой причине, стандартом рекомендуется обеспечивать такое структурирование детальных требований, которое делает их оптимальными для понимания. Стандартом рекомендуются различные способы структурирования детальных требований для различных классов систем.
Существует и третья альтернатива для выбора шаблона Технического задания, когда заказчик предлагает использовать принятый в компании Корпоративный шаблон для описания требований к информационным системам.
11 иерархич уровни проектирования
Детализация представления проектируемой системы.
(мета)системный уровень. Общие задачи проектирования систем, машин и процессов
функционально-логический, функционально-логический (на котором проектируются функциональныеи логические схемы)
Макроуровень (отдельные устройства, узлы приборов)
Микроуровень(отдельные детали и эл. Машин),
Нисходящее проектирование программ заключается в постепенной, пошаговой детализации , выполняемой программы, при этом на каждом этапе детализации должны быть рассмотрены альтернативные варианты решения и выбранные наилучшие, которые затем реализуются в виде подпрограмм.
Разделение описаний проектируемых объектов на иерархические уровни по степени подробности отражения свойств объектов составляет сущность блочно-иерархического подхода к проектированию. Соответственно возможно разделение проектирования как процесса на группы проектных процедур, связанных с получением и преобразованием описаний выделенных уровней и называемых иерархическими уровнями проектирования.
Иерархические уровни технологического проектирования выделяют всоответствии с группами задач проектирования принципиальных схем технологических процессов, маршрутной и операционной технологии.
Принцип декомпозиции предполагает структуризацию (разбиение) представлений соответствующего уровня описания объекта на составные части с целью их раздельного проектирования с учетом согласования принимаемых решений (на одном уровне).
Принцип иерархичности предполагает структуризацию представлений об объектах и их составных частях по степени конкретизации и детализации описания с целью последовательного наращивания сложности описания объекта в сочетании с декомпозицией (связь между разными уровнями).
Восходящее, нисходящее, смешанное проектирование
Для сложн. Систем предпочитают нисходящее проектирование либо комбинацию.
Если решение задач высоких иерархических уровней предшествует решению задач более низких иерархических уровней, то проектирование называют нисходящим. Если раньше выполняются этапы, связанные с низшими иерархическими уровнями, проектирование называют восходящим. У каждого из этих двух видов проектирования имеются преимущества и недостатки. При нисходящем проектировании система разрабатывается в условиях, когда ее элементы еще не определены и, следовательно, сведения о их возможностях и свойствах носят предположительный характер. При восходящем проектировании, наоборот, элементы проектируются раньше системы, и, следовательно, предположительный характер имеют требования к элементам. В обоих случаях из-за отсутствия исчерпывающей исходной информации имеют место отклонения от потенциально возможных оптимальных технических результатов. Однако нужно помнить, что подобные отклонения неизбежны при блочно-иерархическом подходе и что какой-либо приемлемой альтернативы блочно-иерархическому подходу при проектировании сложных объектов не существует
12 Модели процесса разработки программного продукта
Процесс разработки программного продукта требует определенной организации. Для этого были разработаны методы проектирования.Наиболее распространенными моделями процесса разработки программ являются "водопадная" модель "спиральная" модель. "Водопадная" модель выдвигает следующие требования к процессу разработки программ:
Строгое соблюдение последовательности этапов: новый этап не начинается, пока не закончен предыдущий.
Фиксация в документации и контроль независимыми экспертами результатов каждого этапа.
Возврат к предыдущим этапам при обнаружении ошибок в строгой обратной последовательности.
Наряду с очевидными достоинствами "водопадная модель" имеет недостатки, наиболее ощутимый заключается в невозможности организации доступа к общим данным и распаралелливания процесса разработки программного продукта.
Особенность "спиральной модели" заключается в том, что "степень готовности" продукта считается возрастающей величиной в зависимости от времени и этапа разработки.Функция возрастания " степени готовности" изображается в полярной системе координат в виде спирали."Спиральная" модель по сравнению с "водопадной" моделью имеет достоинства:
предусмотрено быстрое прототипирование будущей программы
предусмотрена разработка программ с созданием последовательных версий.
На практике удобнее применять комбинированную модель процесса разработки, когда за основную модель принимается "спиральная", в которой этапам разработки сопоставляются соответствующие этапы "водопадной " модели.
К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:
каскадная модель (70-85 г.г.);
спиральная модель (86-90 г.г.).
В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 1.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем [2]:
на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Рис. 1.1. Каскадная схема разработки ПО
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако, в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимал следующий вид (рис. 1.2):
Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.
Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 1.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
