Основные этапы проектирования автоматизированных систем на основе Российских и международных стандартов - polpoz.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Название работы Кол-во страниц Размер
1 Возникновение и этапы развития общей экономической теории 1 41.32kb.
Пособие предназначено для студентов специальности 230105 Программное... 3 352.82kb.
Методические указания по курсу «Идентификация и диагностика систем»... 7 1129.64kb.
1 Основные свойства мягких систем 1 58.01kb.
Проблемы проектирования и создания систем электроснабжения для крупных... 1 73.25kb.
Рабочая программа для студентов специальности 090105. 65 «Комплексное... 1 216.78kb.
Проектирование информационных систем 1 115.81kb.
Применение cax систем в области бпла 1 105.1kb.
Построение Автоматизированных информационно-измерительных систем... 1 26.63kb.
Основные этапы проведения аудита 1 303.16kb.
Федеральное государственное бюджетное 1 392.31kb.
Формирование бухгалтерского баланса в условиях реорганизации 3 719.67kb.
1. На доске выписаны n последовательных натуральных чисел 1 46.11kb.

Основные этапы проектирования автоматизированных систем на основе Российских и международных - страница №1/1

Министерство образования РФ

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

Кафедра информационных технологий и автоматизированных систем.

РЕФЕРАТ

по дисциплине «Введение в профессию»

на тему «Основные этапы проектирования автоматизированных систем на основе Российских и международных стандартов»

Выполнил: Борисов В.В.

Группа АСУз-13

Проверил:

д.э.н., профессор

Файзрахманов Р.А.

Пермь 2014

Оглавление


Введение. 2

Необходимость соблюдения технологического процесса. 3

Модели жизненных циклов разработки ПО. 5

Ступенчатая и водопадная модели. 5

Спиральный метод. 8

Рациональный унифицированный процесс. 9

Что такое унифицированный процесс (UP)? 10

Начальная фаза. 14

Фаза развития. 16

Формализация при унифицированном процессе. 17

Заключение. 19



Введение.


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

По степени сложности, количества составляющих компонентов, требований к надежности, отказоустойчивости и безопасности работы некоторые современные программные системы вполне сопоставимы с проектами по созданию нового пассажирского авиалайнера. Примером таких систем могут служить крупнейшие СУБД вроде Oracle, или операционная система Windows 7, стоимость разработки которой превышает 1 миллиард долларов, а коллектив разработчиков составляет 3000 человек. Таким образом, разработка программного обеспечения требует такой же высокой инженерной культуры, как машиностроение и проектирование зданий.

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

Необходимость соблюдения технологического процесса.


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

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

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

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

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

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

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

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


Модели жизненных циклов разработки ПО.


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

Ступенчатая и водопадная модели.


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

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

Основная проблема ступенчатой модели состоит в том, что на практике практические невозможно завершить один этап, не «прощупав» следующий. На этапе проектирования, нельзя поставить окончательную точку, не написав по крайней мере нескольких фрагментов кода. И вообще, как можно переходить к тестированию, если модель не обеспечивает возможность возврата к этапу кодирования?

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



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


Спиральный метод.


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

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


Рациональный унифицированный процесс.


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

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

  • Вместо простого предложения среды разработки РУП включает набор программных средств для работы с такой средой.

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

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

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

Для некоторых организаций такой продукт, как РУП может быть слишком «тяжелым». Команды с различными средами разработки или со стесненным бюджетом вряд ли захотят или смогут позволить себе стандартизацию на основе готовой системы разработки с использованием программных методов. Вопросы освоения новой технологии тоже могут стать проблемой для отдельных коллективов – тому, кто не знаком с упомянутыми выше продуктами, придется приложить определенные усилия для их освоения.

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

Что такое унифицированный процесс (UP)?


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

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

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

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

В рамках унифицированного процесса работа над проектом включает четыре основных фаз:


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

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

  3. Конструирование – итеративная реализация оставшихся менее критичных и простых элементов, подготовка к развертыванию.

  4. Передача – бета-тестирование и развёртывание.

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

В рамках UP существует несколько основных дисциплин:


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

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

  3. Проектирование. Сюда относиться модель проектирования, которая отражает программные объекты.


Начальная фаза.


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

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

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

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



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

  2. Если да, то проводятся измерения и выполняется бурение пробной скважины.

  3. Оценивается нефтяной запас и целесообразность затрат на разработку.

  4. Начинается разработка.

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

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

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

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

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

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

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

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

Фаза развития.


Фаза развития – это первая последовательность итераций, в течение которых решаются следующие задачи.

  • Реализуются и тестируются базовые архитектурные элементы.

  • Изучается и стабилизируется большая часть требований.

  • Обосновываются и устраняются основные риски.

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

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

Фаза развития – это не стадия проектирования или подготовки к реализации, как могло бы быть в рамках, например, каскадного процесса разработки («водопадного» процесса).

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

На фазе развития в рамках проектирования и бизнес-моделирования создаются следующие артефакты:

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

Модель проектирования. Это набор диаграмм, описывающих логику проектного решения. Сюда относятся диаграммы программных классов, диаграммы взаимодействия объектов, диаграммы пакетов и т.д.

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

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

Прототипы интерфейса пользователя. Описание интерфейса пользователя, способов навигации и т.д.

Формализация при унифицированном процессе.


Неотъемлемой частью унифицированного процесса является использование языка моделирования UML применяемого для построения большинства артефактов UP. Этот визуальный язык определяет набор графических обозначений, которые интуитивно понятны, и которые легко рисовать от руки. В контексте унифицированного процесса UML применяется в следующих случаях:

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

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

  • В процессе обратного проектирования UML-средство читает исходный код или выполняемые файлы и генерирует диаграммы классов, последовательностей и пакетов на языке UML. Эти «чертежи» позволяют читателю лучше понять общую структуру системы и принципы взаимодействия её элементов.

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

В качестве языка программирования – полные выполняемые спецификации программных систем на языке UML. Выполняемый код можно автоматически сгенерировать. Однако разработчику его сложно осознать или модифицировать – человек работает только с «языком программирования UML». Такой способ использования UML требует отображения всей логики системы или её поведения (возможно с использованием диаграмм взаимодействия или состояний). Он также предает разработке робастность и надежность.

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

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

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



Концептуальный аспект – диаграммы описывают сущности реального мира или предметной области.

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

Аспект программной реализации – диаграммы интерпретируются как описания программной реализации на базе конкретной технологии или языка (например Java).

Заключение.


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

Список литературы:



1. Крэг Ларман, Применение UML 2.0 и шаблонов проектирования. М.: Вильямс, 2007 г.

2. Солтер Н. А., Клеппер С. Д., С++ для профессионалов. М.::Диалектика, 2006.


izumzum.ru