Главная Оформление

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

23.07.2019

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

С чего все начиналось

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

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

Однако, история развития проектного менеджмента как дисциплины относительно молода: ее относят к 30-м годам XX века и связывают с разработкой специальных методов координации инжиниринга крупных проектов в США - авиационных в «US Air Corporation» и нефтегазовых в фирме «Exon». В СССР в этот же период начала развиваться теория и практика поточной организации работ по реализации крупных строительных проектов.

Появление новой дисциплины

Предпосылки для внедрения принципов проект-менеджмента в процесс разработки ПО зародились в конце 60х - начале 70-х годов прошлого века, когда произошло событие, которое вошло в историю как первый кризис программирования. Событие состояло в том, что стоимость ПО стала приближаться к стоимости аппаратуры («железа»), а динамика роста этих стоимостей позволяла прогнозировать, что к середине 90-х годов все человечество будет заниматься разработкой ПО для компьютера. Развитие микроэлектроники привело к резкому увеличению производительности ЭВМ при значительном снижении стоимости. Начали уходить ограничения для аппаратных средств, оставшиеся ограничения приходятся на долю ПО. Это приводило к тому, что умение строить новые программы отставало от требований к новым программам.
Другая тенденция развития зародилась внутри самой отрасли и была основана на усилении взгляда на разработку программ, как на более чем простое «кодирование». Вместо этого программное обеспечение рассматривается как имеющее полный жизненный цикл, начинающийся с появления концепции и проходящий стадии проектирования, разработки, ввода в действие, сопровождения и развития. Смещение фокуса внимания с кодирования породил разработку методологий и развитого инструментария, вооруживших команды инженеров, занятых на всех этапах жизненного цикла программного обеспечения.
Тогда и заговорили о программной инженерии(технологии промышленного программирования) как о некоторой дисциплине, целью которой является сокращение стоимости программ. Такая проблема должна решаться более грамотной организацией процесса разработки. Это и привело к развитию методологий проектирования ПО и возведения его в главенствующие составляющие разработки.

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

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

Методологии в программной инженерии

С этого момента программирование «обрастает» различными дополнительными видами деятельности: разработкой требований, планированием, тестированием, конфигурационным управлением, проектным менеджментом, созданием различной документации (проектной, пользовательской и пр.). Разработка программного кода предваряется анализом и проектированием (первое означает создание функциональной модели будущей системы без учета реализации, для осознания программистами требований и ожиданий заказчика; второе означает предварительный макет, эскиз, план системы на бумаге).
Все эти и другие дополнительные виды деятельности, выполняемые в процессе промышленного программирования и необходимые для успешного выполнения заказов и будем называть программной инженерией. Получается, что так мы обозначаем, во-первых, некоторую практическую деятельность, а во-вторых, специальную область знания. Или другими словами, научную дисциплину. Ведь для облегчения выполнения каждого отдельного проекта, для возможности использовать разнообразный положительный опыт, достигнутый другими командами и разработчиками, этот самый опыт подвергается осмыслению, обобщению и надлежащему оформлению. Так появляются различные методы и практики (best practices) – тестирования, проектирования, работы над требованиями и пр., архитектурных шаблонов и пр. А также стандарты и методологии, касающиеся всего процесса в целом. Вот эти-то обобщения и входят в программную инженерию как в область знания.
Таким образом методологии в программной инженерии являются одной из самых динамично развивающихся составляющих области знаний, т.к. несут в себе практическую составляющую.
Современная классификация методологий управление проектом или моделей жизненного цикла проекта согласно SWEBOK выглядит следующим образом.
Методологии управления проектами:
  • традиционная(каскадная, водопадная) модель;
  • cпиральная модель;
  • итеративная и инкрементная модель(эволюционный подход).

Подробнее о методологиях

Как видно из названия традиционные методологии построены на последовательном выполнении всех фаз проекта и конечный продукт будет получен только после выполнения всех этапов. Возвращение на предыдущий этап не предусмотрено и при появлении критических ошибок весь проект начинается сначала. Основным примером таких методологий разработки является каскадная модель или модель Водопад. Источником данной модели принято считать статью Уинстона Ройса вышедшею в 1970 году. Однако, сам Ройс описывал эту модель как пример противопоставленный итеративной модели, применимый только для очень простых проектов и сам пользовался итеративными методологиями. Так же Ройс писал, что в особо сложных местах проекта и при применении новых, ранее не используемых технологий, промежуточные этапы можно повторить дважды и заказчик по окончанию проекта получает вторую версию продукта. Такой подход нельзя назвать итеративным, но и однозначно последовательным тоже. На начальном периоде она сыграла ведущую роль как метод регулярной разработки сложного ПО. В 70x - 80x годах XX века модель была принята как стандарт министерства обороны США.
По мере развития методологий каскадная модель подвергалась жесткой критики со стороны всех исследователей, предлагавших свои методологии. Последовательное выполнение этапов разработки не дает изменить требования к программному продукту до самого релиза. Чем больше проект тем больше накапливается проблем в процессе проектирования. И реализация изменений в следующей версии продукта иногда становится не целесообразной. Продукт необходимо писать с 0 . Таким образом стоимость работоспособной версии не оправдано сильно растет. А процент успешно завершенных проектов ничтожно мал. Однако, можно ли назвать традиционные методологии разработки отжившими свой век? Не совсем. Для проектов затрагивающих безопасность жизнедеятельности строго поставленные требования и высокая степень формализации является основополагающим и необходимым фактором.
Кроме того, несмотря, на модную сейчас критику традиционной модели, она играет важную роль, потому что налагает на процесс разработки требование крайне необходимой для него дисциплинированности, с помощью которой удается благополучно обходить неструктурированные процессы типа «пишем и правим». Данная модель внесла фундаментальный вклад в понимание процессов разработки ПО следующими утверждениями:
  • процесс должен подчиняться дисциплине, разумному планированию и управлению;
  • реализация продукта должна быть отложена до полного понимания целей этой реализации.

Спиральная модель ЖЦ стала следующим (после водопадной) этапом развития методологий разработки, поскольку она решает основную проблему каскадной модели. Каждая фаза водопадного процесса разработки в спиральной методологии завершается этапом прототипирования и управления рисками. Этап прототипирования после каждой фазы проекта позволяет определить, насколько текущее состояние проекта соответствует первоначальному плану. По итогам прототипирования выполняется либо переход к следующей фазе, либо возвращение на одну из предыдущих фаз. Однако фазы и последовательность фаз остаются линейными. Автором данной модели является Барри Боэм, опубликовавший в 1988 году статью «A Spiral Model of Software Development and Enhancement». Не смотря на то, что в SWEBOK данная модель выделена отдельно от итеративной, при описании моделей напрашивается вывод об отнесении спиральной методологии к семейству итеративных. Это обуславливается и возможностью изменения требований между этапами и выпуска прототипов продукта после каждого цикла. Возможно такое разделение связано с авторской принадлежностью методологий.

Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Упоминания о данной методологии начали появляться задолго до статьи У. Ройса и появления самой программной инженерии. Истоки концепции итеративной разработки прослеживаются в относящихся к 30-м годам работах эксперта по проблемам качества продукции Уолтера Шеварта из Bell Labs. Важной вехой в истории является осуществленный в 50-е годы проект по разработке сверхзвукового реактивного самолета X-15. По мнению участников этих работ, применение данной методологии в значительной степени определило успех проекта.
Наиболее обсуждаемые сейчас гибкие методологии разработки (Agile методологии) относятся именно к итеративным моделям ЖЦ. При описании любой из гибких методологий упоминается принцип разделения на итерации. Однако, особенность данных методологий это упор на человеческий фактор, а не на документацию проекта, что никак не обозначается в описании итеративной и инкрементной методологии.

Гибкие методологии разработки начали появляться на фоне быстрорастущего усложнения технологий и всеобщей информатизации. Теперь заказчиком в большинстве случаев является лицо далекое от информационных технологий. Для такого заказчика главным является готовый продукт, а не фолианты документации. При экспоненциально растущем темпе развития информационных технологий сроки на разработку ПО сократились и стали жестче. Теперь нет времени на долгое планирование, написание документации и полновесное тестирование. Программный продукт может устареть еще до релиза. В противовес традиционным методологиям разработки итеративные методологии делят выполнение проекта на короткие итерации, ограниченные по времени. После каждой итерации заказчику продукта предоставляется результат. Предусмотрен откат на предыдущие итерации. Появление гибких методологий не привязано к конкретной дате, так как начиная с середины 90х годов начали появляться и внедряться практически параллельно. Это были методологии разработки такие как: Scrum (1995), экстремальное программирование (1996), Crystal Clear, Lean, Kanban и другие. Созданный в феврале 2001 года, Agile-манифест, провозгласил философию гибких методологий разработки и задал вектор развития данных методологий.

Современный этап развития методологий

Сейчас выбор методологии проектирования как никогда подвержен влиянию маркетинга. Все больше появляется консультантов по внедрению agile, коучеров, проводящих бесконечные тренинги, семинары, вэбинары, бесконечные встречи, конференции, круглые столы. Все эти мероприятия направлены на продажу внедрения в ИТ-компаниях за большие деньги приглашенными специалистами или повышения рейтинга компаний, которые уже внедрили гибкие методологии.
Гибкие методологии сейчас - это в большей степени свод знаний по организации работы людей с психологической точки зрения. Такие методологии помогают команде проявлять творческую составляющую, умение работать в команде, навыки коммуникации и прочее. Техническая сторона организации работ все больше уходит на второй план. Только ХР(Экстремальное программирование) имеет в своем арсенале такие инженерные практики как разработка через тестирование, метафоры и рефакторинг. Эти практики с успехом применяются в сочетании с другими методологиями. При некачественном внедрении Agile мы получаем то, что сейчас происходит на рынке IT продуктов. Рынок перенасыщен некачественными, нестабильными продуктами, не отвечающими требованиям не к функционалу, ни к интерфейсу. При этом, что скорость выпуска таких продуктов, благодаря пропагандируемому Agile принципу непрерывной интеграции, постоянно растет.

С набирающим обороты снижением качества выпускаемых IT продуктов стали появляться методологии, стремящиеся это качество повысить. Такой методологией стал DEvOps.
Термин «devops» был популяризирован на конференции «Дни DevOps» («DevOps Days») в 2009 году в Бельгии. С тех пор такая методология все больше набирает популярность.Это отчасти связано с тем, что принципы DevOPs пропагандируют не отказ от действующей в организации методологии, а сочетание с ней. Общая концепция DevOps заключается в усилении кооперации между группами разработки(DEVelopments) и эксплуатации(OPerations) в рамках одной организации, несущими ответственность за разработку ПО. Данная методология это без преувеличения новый виток эволюции методологий разработки поскольку ориентирована не только на удовлетворение требований заказчика в жестко определенные сроки, но и повышение качества и стабильности продукта.

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

Источники

Управление проектами разработки ПО. Дисциплина «Гибкие технологии разработки программного обеспечения» автор: Д.Г. Шопырин

Без развития методов проектирования структур управления затрудняется совершенствование управления и повышение эффективности производства, так как:

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

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

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

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

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

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

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

Системность подхода к формированию организационной структуры проявляется в следующем: 1) не упускать из виду ни одну из управленческих задач, без решения которых реализация целей окажется неполной; 2) выявить и взаимоувязать применительно к этим задачам систему функций, прав и ответственности по вертикали управления – от генерального директора предприятия до мастера участка; 3) исследовать и организационно оформить все связи и отношения по горизонтали управления, т. е. по координации деятельности разных звеньев и органов управления при выполнении общих текущих задач и реализации перспективных межфункциональных программ; 4) обеспечить органическое сочетание вертикали и горизонтали управления, имея в виду нахождение оптимального для данных условий соотношения централизации и децентрализации с управлении. Все это требует тщательно разработанной поэтапной процедуры проектирования структур, детального анализа и определения системы целей, продуманного выделения организационных подразделений и форм их координации.

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

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

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

От специфического для машиностроения,строительстваи других отраслей науки и техники понятия«проект» (англ. design) в значении «проектная документация» следует отличать используемое в области деятельностиуправление проектами в контекстеменеджмента понятие«проект» (англ. project, отлат.projectus - брошенный вперёд, выступающий) в значении «некоторая задача с определёнными исходными данными и требуемыми результатами (целями), обусловливающими способ её решения», «программа», «комплекс работ» и т. п.

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

Понятие «проектирование» не включает в себя стадию реализации проекта.

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

Методы проектирования

Основная статья: Методы проектирования

    Эвристические методы

    • Метод итераций (последовательного приближения)

      Метод декомпозиции

      Метод контрольных вопросов

      Метод мозговой атаки (штурма)

      Теория решения изобретательских задач (ТРИЗ)

      Метод морфологического анализа

      Функционально-стоимостной анализ

      Методы конструирования

    Экспериментальные методы

    • Цели и виды экспериментальных методов

      Планирование эксперимента

      Машинный эксперимент

      Мысленный эксперимент

    Формализованные методы

    • Методы поиска вариантов решений

      Методы автоматизации процедур проектирования

      Методы оптимального проектирования

3 Процесс формирование организационной структуры

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

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

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

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

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

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

 - определение проектной численности подразделений;

 - распределение задач и работ между конкретными исполнителями;

 - установление ответственности за их выполнение;

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

 - расчеты затрат на управление и показателей эффективности аппарата управления в условиях проектированной организационной структуры.

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

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

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

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

SADT - методология структурного анализа и проектирования (Structured Analysis and Design Technique). Основана на понятиях функционального моделирования. Является методологией, отражающей такие системные характеристики, как управление, обратная связь и исполнители.

IDEF0 - методология функционального моделирования (INTEGRATION DEFINITION FOR FUNCTION MODELING). Применяется для описания рабочих процессов (Work Flow). Разработана на основе SADT. По сути одно и тоже.

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

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

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

IDEF4 - объектно-ориентированная методология. Отражает взаимодействие объектов. Удобна для создания программных продуктов на объектно-ориентированных языках (например С++). Пока широкого распространения не нашла. Более широко сейчас используется UML.

UML - (Unified Modeling Language) язык визуального моделирования, основанный на объектно-ориентированном подходе. UML включает в себя двенадцать типов диаграмм, которые позволяют описать статическую структуру системы и ее динамическое поведение.

В настоящий момент к семейству IDEF можно отнести следующие стандарты:

IDEF0 - Function Modeling - методология функционального моделирования. С помощью наглядного графического языка IDEF0, изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков - в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique);

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

IDEF1X (IDEF1 Extended) - Data Modeling - методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» (ER - Entity-Relationship) как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

IDEF2 - Simulation Model Design - методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN - Color Petri Nets);

IDEF3 - Process Description Capture - Документирование технологических процессов, IDEF3 - методология документирования процессов, происходящих в системе (например, на предприятии), описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 - каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;

IDEF4 - Object-Oriented Design - методология построения объектно-ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

IDEF5 - Ontology Description Capture - Стандарт онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация;

IDEF6 - Design Rationale Capture - Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения "знаний о способе" моделирования, их представления и использования при разработке систем управления предприятиями. Под "знаниями о способе" понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, "знания о способе" интерпритируются как ответ на вопрос: "почему модель получилась такой, какой получилась?" Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;

IDEF7 - Information System Auditing – Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF8 - User Interface Modeling - Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интефейсов в большей степени создают внешний вид интефейса. IDFE8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интефеса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфес для выполнения операции);

IDEF9 - Scenario-Driven IS Design (Business Constraint Discovery method) - Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение;

IDEF10 - Implementation Architecture Modeling - Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF11 - Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF12 - Organization Modeling - Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF13 - Three Schema Mapping Design - Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF14 - Network Design - Метод проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, сущестующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением матеральными ресурсами, что позволяте достичь существенной экономии;


Похожая информация.


Методологии проектирования

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

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

CASE-средства, поддерживающие объектно-ориентированное проектирование используют методологию RUP (Rational Unified Process) и нотации языка UML.

RUP – методология разработки ПО, в основе которой лежат 6 принципов:

1. Компонентная архитектура (реализуется и тестируется на ранних стадиях проекта).

2. Работа над проектом в сплоченной команде, ключевая роль в которой принадлежит архитекторам.

3. Ранняя идентификация и непрерывное устранение возможных рисков

4. Концентрация на выполнении требований заказчика.

5. Ожидание изменения в требованиях, проектных решениях и реализации в процессе разработки.

6. Постоянное обеспечение качества на всех этапах разработки проекта.

Представление системы на языке UML.

1. Представление использования – основная часть модели описания системы.

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

3. Компонентное представление – описание структуры и взаимосвязей модулей системы.

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

5. Представление распределения – описание физической архитектуры системы.

Каждое представление состоит из диаграмм, которые строятся из своих нотаций. Для структурного подхода используется методология SADT (Structured Analysis and Design Technique). Главным разработчиком методологии был Дуглас Росс. Он разработал язык структурного анализа, используемый для описания исследуемого объекта. Этот язык лег в основу стандартов семейства IDEF . В настоящее время семейство IDEF включают следующие стандарты:

IDEF0 – стандарт функционального моделирования

IDEF1Х – стандарт моделирования потоков данных

IDEF2 – стандарт динамического моделирования систем

IDEF3 – стандарт документирования процессов

IDEF4 – стандарт построения объектно-ориентированных систем

IDEF5 – стандарт онтологического (принципиального, структурного) исследования систем.

Лекция 8. Язык UML

Диаграммы UML

Описание языка UML состоит из двух взаимодействующих частей:

1) семантики языка UML (это мета-модели, определяющие синтаксис и семантику понятий объектного моделирования на языке UML);

2) нотаций языка UML (графические нотации для визуального представления семантики языка).

Семантика определяется для двух видов объектной модели:

1) структурных моделей (они же статические модели), которые описывают структуру сущностей или компонентов системы;

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

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

В терминах языка UML определены следующие виды диаграмм:

1) диаграмма вариантов использования;

2) диаграмма классов (будет напоминать структуру БД);

3) диаграммы поведения (включают три вида диаграмм – диаграммы состояний, диаграммы деятельности, диаграммы взаимодействия, которые включают два вида диаграмм – диаграмма последовательности, диаграмма коопераций);

4) диаграммы реализации (включают два вида диаграмм – диаграммы компонентов и диаграммы развертывания).

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

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

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

Диаграмма реализации – физическая модель.

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

1) определение общих границ и контекста моделируемой предметной области;

2) формулирование общих требований к функциональному поведению проектируемой системы;

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

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

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

Основные элементы диаграммы:

1) действующее лицо – актер или сущность;

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

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

2) вариант использования;

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

3) отношения;

Отношение. Отношение – вариант использования представляет собой внешнюю спецификацию последовательности действий.

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

Отношение ассоциации представляет собой структурное отношением, показывающие, что объекты …

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

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

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

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

4) примечания.

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

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

Мышление стратегическими схемами (выработка стратегии и соблюдение
стратегии).

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

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

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

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

Течтэмы объединены в семь групп:

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

"Режимы мышления" предназначены для осознания, контроля и приспособления образа мышления к задачам проектирования. Методом Мэтчетта используется перечень контрольных вопросов:

  1. Какие потребности являются: жизненно важными, очень важными, важными, желательными?
  2. Каковы потребности: функциональной системы, потребителя, фирмы, внешнего мира?
  3. Каковы потребности на каждом из перечисленных ниже 10 этапов существования изделия: проектирование и деталировка, отработка, изготовление деталей, сборка, испытание и отладка, окончательная отделка и упаковка, сбыт, монтаж, эксплуатация и использование, тех. обслуживание и уход?
  4. Какие сведения можно получить, если задать 6 основных вопросов анализа трудовых операций: что нужно сделать (потребности), почему это нужно сделать (причина), когда это нужно сделать (время), где это нужно сделать (место), кем или с помощью чего это должно быть сделано (средства), как это сделать (метод)?
  5. Каким образом каждую часть проекта можно: исключить, объединить с другими частями, унифицировать, перенести, модифицировать, упростить?
  6. Какие эффекты, потребности, ограничения вызовет каждая деталь комплекса в отношении любой др. детали этого комплекса?

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