Структурный подход. Системный подход к разработке ПО. Временной и "пространственный " аспекты системного подхода. Каскадная модель жизненного цикла ПО Подходы к разработке по
1. Каскадная (англ. waterfall) - стандартная модель разработки
Каскадная модель разработки - модель, при которой все этапы разработки ведутся последовательно - последующий этап начинается после полного завершения предыдущего.
Такая модель включает следующие этапы процесса разработки ПО:
В первую очередь определяются технические параметры будущей программы, в результате утверждается список требований к программному обеспечению. Далее происходит переход к проектированию, в процессе которого создается документация, описывающая для программистов план и способ реализации требований.
После полного завершения проектирования программистами выполняется реализация (конструирование) проекта. На стадии воплощения происходит интеграция всех компонентов проекта. Только после полного завершения этих стадий производится тестирование и отладка готового продукта. Далее программный продукт можно внедрять и после внедрения осуществлять поддержку - вносить новый функционал и устранять ошибки.
Основные плюсы каскадной разработки:
2. Гибкая методология разработки программного обеспечения (Agile software development)
Ряд методологий разработки программного обеспечения, предусматривающий совместную работу представителей заказчика и разработчиков. В основе гибкого метода разработки лежит итеративный подход, динамическое формирование требований и их реализация короткими этапами.
Результатом каждого такого этапа, включающего цикл итерраций, является некий миниатюрный программный проект,
Методов гибкой разработки несколько, из наиболее известных - Scrum, экстремальное программирование, DSDM.
Основные плюсы гибкой разработки:
| минимизация рисков; постепенное наращивание функционала программного продукта; небольшой объем письменной документации; запуск базовой версии программы в кратчайшие сроки. | |||
Существуют и минусы: |
|||
| невозможность точного определения бюджета проекта; невозможность определения точных сроков готовности проекта; не подходит для государственных и бюджетных организаций; требует мотивации от ответственных представителей заказчика. | |||
Agile-манифест разработки программного обеспеченияМы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что: Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева. |
Принципы гибкой разработки:
|
Удовлетворение клиента за счёт быстрой и бесперебойной поставки необходимого программного обеспечения; |
В первой части мы выбрали для сравнения методологий разработки ПО такие показатели, как отношение методологии к итеративной разработке и степень формальности в оформлении рабочих материалов и вообще в проведении разработки. В этой части мы используем названные показатели для сравнения наиболее известных методик разработки ПО.
Как получится…
Увы, это самая сложная для описания категория - ведь в нее входят как продукт судорожных метаний новичка, пытающегося любой ценой выполнить свой первый проект, так и вполне зрелые и устоявшиеся методологии, вобравшие в себя многолетний и разнообразный опыт конкретных команд разработчиков и даже описанные во внутренних регламентах. Поскольку люди, способные разработать собственную методологию, как правило, могут сами оценить ее в плане итеративности и формализованности, будем ориентироваться на новичков. Увы, чаще всего это означает, что правил ведения разработки либо не существует вообще, либо они разработаны и приняты, но не выполняются. Естественным в таких условиях является крайне низкий уровень формализма разработки. Так что с этим все понятно.
Разработка «Как получится»
А как обстоит дело с применением итеративного подхода? Увы, как правило, он в таких проектах не используется. Прежде всего потому, что он бы позволил еще на первых итерациях оценить проект как крайне сомнительный и требующий срочного вмешательства более высокого руководства для наведения порядка. Ведь в итеративном проекте традиционный ответ программиста, что у него уже все на 90% готово, проходит только до момента завершения первой итерации…
Структурные методологии
Структурные методологии
Структурные методы - это группа методологий, разработанных, как правило, еще до широкого распространения объектно-ориентированных языков. Все они предполагают каскадную разработку. Хотя, как выяснилось, еще в той статье, которую часто цитируют как первое изложение каскадного подхода, было сказано, что желательно начинать проект с разработки прототипа, то есть выполнять как минимум две итерации.
Тем не менее основу этих методологий составляют последовательный переход от работы к работе и передача результатов (документов) очередного этапа участникам последующего.
Также все эти методологии предполагают высокоформализованный подход, хотя высказывания о разумном количестве документации можно найти и в них. Одним из неочевидных примеров того, что методологии разработки ПО развивались не только на Западе, является цитата из изданной в нашей стране в начале 1980-х годов книги, гласящая, что степень формализации задания на программирование должна определяться исходя из того, насколько хорошо сработались аналитик и программист. И это при том, что тематика книги предполагала разработку достаточно критических, как их теперь называют, систем, ошибки в которых ведут к серьезным потерям или даже к катастрофам.
Гибкие методологии
Гибкие методологии базируются на десяти принципах, из которых мы назовем лишь те, которые определяют оценку этих методологий по выбранным параметрам:
- главное - удовлетворить заказчика и предоставить ему продукт как можно скорее;
- новые выпуски продукта должны появляться раз в несколько недель, в крайнем случае - месяцев;
- наиболее эффективный способ передачи знаний участникам разработки и между ними - личное общение;
- работающая программа - лучший показатель прогресса разработки.
Таким образом, эти методы явно ориентированы на итеративную разработку ПО и на минимальную формализацию процесса. Впрочем, относительно второго пункта необходимо сделать оговорку: названные методы ориентированы на минимально допустимый для данного проекта уровень формализации. По крайней мере, одна из методологий, входящих в группу гибких, - Crystal - имеет модификации, предназначенные для выполнения процессов с различным количеством участников и разной критичностью разрабатываемого ПО (критичность ПО определяется возможными последствиями ошибок, которые могут меняться в диапазоне от незначительных финансовых потерь на исправление ошибки до катастрофических). Чтобы дальнейшее сравнение с гибкими методологиями не было беспредметным, приведем краткие описания нескольких из них.
eXtreme Programming, или XP (экстремальное программирование)
Методология XP, разработанная Кентом Беком (Kent Beck), Уордом Каннингемом (Ward Cunningham) и Роном Джеффрисом (Ron Jeffries), является сегодня наиболее известной из гибких методологий. Иногда само понятие «гибкие методологии» явно или неявно отождествляют с XP, которая проповедует коммуникабельность, простоту, обратную связь и отвагу. Она описывается как набор практик: игра в планирование, короткие релизы, метафоры, простой дизайн, переработки кода (refactoring), разработка «тестами вперед», парное программирование, коллективное владение кодом, 40-часовая рабочая неделя, постоянное присутствие заказчика и стандарты кода. Интерес к XP рос снизу вверх - от разработчиков и тестировщиков, замученных тягостным процессом, документацией, метриками и прочим формализмом. Они не отрицали дисциплину, но не желали бессмысленно соблюдать формальные требования и искали новые быстрые и гибкие подходы к разработке высококачественных программ.
При использовании XP тщательное предварительное проектирование ПО заменяется, с одной стороны, постоянным присутствием в команде заказчика, готового ответить на любой вопрос и оценить любой прототип, а с другой - регулярными переработками кода (так называемый рефакторинг). Основой проектной документации считается тщательно прокомментированный код. Очень большое внимание в методологии уделяется тестированию. Как правило, для каждого нового метода сначала пишется тест, а потом уже разрабатывается собственно код метода до тех пор, пока тест не начнет выполняться успешно. Эти тесты сохраняются в наборах, которые автоматически выполняются после любого изменения кода.
Хотя парное программирование и 40-часовая рабочая неделя и являются, возможно, наиболее известными чертами XP, но все же носят вспомогательный характер и способствуют высокой производительности разработчиков и сокращению количества ошибок при разработке.
Crystal Clear
Crystal - семейство методологий, определяющих необходимую степень формализации процесса разработки в зависимости от количества участников и критичности задач.
Методология Crystal Clear уступает XP по производительности, зато максимально проста в использовании. Она требует минимальных усилий для внедрения, поскольку ориентирована на человеческие привычки. Считается, что эта методология описывает тот естественный порядок разработки ПО, который устанавливается в достаточно квалифицированных коллективах, если в них не занимаются целенаправленным внедрением другой методологии.
Основные характеристики Crystal Clear:
- итеративная инкрементная разработка;
- автоматическое регрессионное тестирование;
- пользователи привлекаются к активному участию в проекте;
- состав документации определяется участниками проекта;
- как правило, используются средства контроля версий кода.
Помимо Crystal Clear, в семейство Crystal входит еще несколько методологий, предназначенных для выполнения более крупных или более критических проектов. Они отличаются несколько более жесткими требованиями к объему документации и вспомогательным процедурам, таким как управление изменениями и версиями.
Feature Driven Development
Функционально-ориентированная разработка (Feature Driven Development, FDD) оперирует понятием функции или свойства (feature) системы, достаточно близким к понятию сценария использования, применяемому в RUP. Едва ли не самое существенное отличие - это дополнительное ограничение: «каждая функция должна допускать реализацию не более чем за две недели». То есть если сценарий использования достаточно мал, его можно считать функцией, а если велик, то его надо разбить на несколько относительно независимых функций.
FDD включает пять процессов, причем последние два повторяются для каждой функции:
- разработка общей модели;
- составление списка необходимых функций системы;
- планирование работы над каждой функцией;
- проектирование функции;
- конструирование функции.
Работа над проектом предполагает частые сборки и делится на итерации, каждая из которых реализуется с помощью определенного набора функций.
Разработчики в FDD делятся на «хозяев классов» и «главных программистов». Главные программисты привлекают хозяев задействованных классов к работе над очередным свойством. Для сравнения: в XP нет персонально ответственных за классы или методы.
Общие черты
Список гибких методологий в настоящее время достаточно широк. Тем не менее описанные нами методологии дают весьма полное представление обо всем семействе.
Практически все гибкие методологии используют итеративный подход, при котором детально планируется только ограниченный объем работ, связанный с выпуском очередного релиза.
Практически все гибкие методологии ориентированы на максимально неформальный подход к разработке. Если проблему можно решить в ходе обычной беседы, то лучше именно так и поступить. Причем оформлять принятое решение в виде бумажного или электронного документа нужно только тогда, когда без этого невозможно обойтись.
Гибкие методологии
ГОСТы
ГОСТы, как и описываемые в следующем разделе требования модели CMM, не являются методологиями. Они, как правило, не описывают сами процессы разработки ПО, а только формулируют определенные требования к процессам, которым в той или иной степени соответствуют различные методологии. Сравнение требований по тем же критериям, по которым мы сравниваем методологии, поможет сразу определиться с тем, какими методологиями стоит пользоваться, если вам нужно выполнить разработку в соответствии с ГОСТ.
В настоящее время в России действуют старые ГОСТы 19-й и 34-й серий и более новый ГОСТ Р ИСО МЭК 122207. ГОСТы 19-й и 34-й серий жестко ориентированы на каскадный подход к разработке ПО. Разработка в соответствии с этими ГОСТами проводится по этапам, каждый из которых предполагает выполнение строго определенных работ, и завершается выпуском достаточно большого числа весьма формализованных и обширных документов. Таким образом, сразу строгое следование этим стандартам не только приводит к каскадному подходу, но и обеспечивает очень высокую степень формализованности разработки.
Требования ГОСТов
ГОСТ 12207, в отличие от стандартов 19-й и 34-й серий, описывает разработку ПО как набор основных и вспомогательных процессов, которые могут действовать от начала и до завершения проекта. Модель жизненного цикла может выбираться исходя из особенностей проекта. Таким образом, этот ГОСТ явно не запрещает применение итеративного подхода, но и явно не рекомендует его использование. ГОСТ 12207 также более гибок в части требований к формальности процесса разработки. В нем содержатся только указания на необходимость документирования основных результатов всех процессов, но нет перечней требуемых документов и указаний относительно их содержания.
Таким образом, ГОСТ 12207 допускает итеративную и менее формализованную разработку ПО.
Модели зрелости процесса разработки (CMM, CMMI)
Помимо государственных и международных стандартов, существует несколько подходов к сертификации процесса разработки. Наиболее известными из них в России являются, по-видимому, CMM и CMMI.
CMM (Capability Maturity Model) - модель зрелости процессов создания ПО, которая предназначена для оценки уровня зрелости процесса разработки в конкретной компании. В соответствии с этой моделью имеется пять уровней зрелости процесса разработки. Первый уровень соответствует разработке «как получится», когда на каждый проект разработчики идут как на подвиг. Второй соответствует более-менее налаженным процессам, когда можно с достаточной уверенностью рассчитывать на положительный исход проекта. Третий соответствует наличию разработанных и хорошо описанных процессов, используемых при разработке, а четвертый - активному использованию метрик в процессе управления для постановки целей и контроля их достижения. И наконец, пятый уровень означает способность компании оптимизировать процесс по мере необходимости.
Требования CMM и CMMI
После появления CMM стали разрабатываться специализированные модели зрелости для создания информационных систем, для процесса выбора поставщиков и некоторые другие. На их основе была разработана интегрированная модель CMMI (Capability Maturity Model Integration). Кроме того, в CMMI была предпринята попытка преодолеть проявившиеся к тому времени недостатки CMM - преувеличение роли формальных описаний процессов, когда наличие определенной документации оценивалось значительно выше, чем просто хорошо налаженный, но не описанный процесс. Тем не менее CMMI также ориентирован на использование весьма формализованного процесса.
Таким образом, основой моделей CMM и CMMI является формализация процесса разработки. Они нацеливают разработчиков на внедрение детально описанного в регламентах и инструкциях процесса, который, в свою очередь, не может не требовать разработки большого объема проектной документации для соответствующего контроля и отчетности.
Связь CMM и CMMI с итеративной разработкой более опосредованная. Формально ни та ни другая не выдвигают конкретных требований к тому, чтобы придерживаться каскадного или итеративного подхода. Однако, по мнению ряда специалистов, CMM в большей степени совместима с каскадным подходом, в то время как CMMI допускает также и применение итеративного подхода.
RUP
Безусловно, RUP - это итеративная методология. Хотя формально обязательность выполнения всех фаз или какого-то минимального числа итераций нигде в RUP не обозначена, весь подход ориентирован на то, что их достаточно много. Ограниченное количество итераций не позволяет в полной мере использовать все преимущества RUP. Вместе с тем RUP можно применять и в практически каскадных проектах, включающих реально всего пару итераций: одну в фазе «Построение», а другую в фазе «Передача». Кстати говоря, в каскадных проектах реально используется именно такое количество итераций. Ведь проведение испытаний и опытной эксплуатации системы предполагает внесение исправлений, которые могут подразумевать определенные действия, связанные с анализом, проектированием и разработкой, то есть фактически являются еще одним проходом через все фазы разработки.
Методология RUP
Что касается формальности методологии, то здесь RUP представляет пользователю весьма широкий диапазон возможностей. Если выполнять все работы и задачи, создавать все артефакты и достаточно формально (с официальным рецензентом, с подготовкой полной рецензии в виде электронного или бумажного документа и т.д.) проводить все рецензирования, RUP может оказаться крайне формальной, тяжеловесной методологией. В то же время RUP позволяет разрабатывать только те артефакты и выполнять только те работы и задачи, которые необходимы в конкретном проекте. А выбранные артефакты могут выполняться и рецензироваться с произвольной степенью формальности. Можно требовать детальной проработки и тщательного оформления каждого документа, предоставления столь же тщательно выполненной и оформленной рецензии и даже, следуя старой практике, утверждать каждую такую рецензию на научно-техническом совете предприятия. А можно ограничиться электронным письмом или наброском на бумаге. Кроме того, всегда остается еще одна возможность: сформировать документ в голове, то есть обдумать соответствующий вопрос и принять конструктивное решение. И если это решение касается только вас, то ограничиться, например, комментарием в коде программы.
Таким образом, RUP - итеративная методология с очень широким диапазоном возможных решений в части формализации процесса разработки.
Подведем итоги второй части статьи. RUP, в отличие от большинства других методологий, позволяет в широком диапазоне выбирать степень формализации и итеративности процесса разработки в зависимости от особенностей проектов и разрабатывающей организации.
А почему это так важно - мы обсудим в следующей части.
Сейчас в программной инженерии е два основных подхода к разработке ПО ИС, принципиальное различие между которыми обусловлено разными способами декомпозиции систем: функционально-модульный (структурный) подход, в основу которого положен принцип функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами, и объектно ориентированный подход, что использует объектную декомпозицию, описывает структуру ИС в терминах объектов и связей между ними, а поведение системы - в терминах обмена сообщениями между объектами.
Итак, сущность структурного подхода к разработке ПО ИС заключается в ее декомпозиции на автоматизированные функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, они - на задачи и так до конкретных процедур. При этом ИС сохраняет целостность представления, где все составляющие взаимосвязаны. При разработке системы "снизу вверх", от отдельных задач ко всей системе, целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.
Базовыми принципами структурного подхода являются:
o принцип "разделяй и властвуй";
o принцип иерархического упорядочения - принцип организации составных системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. Выделение двух базовых принципов не означает, что остальные принципы второстепенные, поскольку игнорирование любого из них может привести к непредсказуемым последствиям.
Основными из этих принципов являются:
o абстрагирование - выделение существенных аспектов системы;
o непротиворечивости - обоснованность и согласованность элементов системы;
o структурирование данных - данные должны быть структуро-ване и иерархически организованы.
Методические основы технологий создания программного обеспечения
Визуальное моделирование. Моделью ПО в общем случае называют формализованное описание системы ПО на определенном уровне абстракции. Каждая модель определяет конкретный аспект системы, использует набор диаграмм и документов заданного формата, а также отражает мысли и является объектом деятельности различных людей с конкретными интересами, ролями или задачами.
Графические (визуальные) модели являются средствами для визуализации, описания, проектирования и документирования архитектуры системы. Состав моделей, используемых в каждом конкретном проекте, и степень их детальности в общем случае зависят от следующих факторов:
o трудностей проектируемой системы;
o необходимой полноты ее описания;
o знаний и навыков участников проекта;
o времени, отведенного на проектирование.
Визуальное моделирование очень повлияло на развитие CASE-средств в частности. Понятие CASE (Computer Aided Software Engineering) используется в широком смысле. Первоначальное значение этого понятия, ограничено только задачами автоматизации разработки ПО, в настоящее время приобрело новый смысл, охватывающий большинство процессов жизненного цикла ПО.
CASE-технология представляет собой совокупность методов проектирования ПО, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения ПО и разрабатывать применение в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методах структурного или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.
1. Назначение технологии программирования. История развития технологии программирования. Типы программных проектов. Составные части технологии программирования. Проект, продукт, процесс и персонал
2. Жизненный цикл программы. Циклический характер разработки. Основные понятия технологии программирования. Процессы и модели. Фазы и витки. Вехи и артефакты. Заинтересованные лица и работники.
3. Выявление и анализ требований. Требования к программному обеспечению . Схема разработки требований. Управление требованиями.
4. Архитектурное и детальное проектирование. Реализация и кодирование. Тестирование и верификация . Процесс контроля качества. Методы «белого ящика» и «чёрного ящика». Инспектирование и обзоры. Цели тестирования. Верификация, валидация и системное тестирование. Сопровождение и продолжающаяся разработка.
5. Модели процесса разработки. Водопадные и конвейерные модели. Спиральные и инкрементные модели. Гибкие модели процесса разработки.
6. Конструирование модели процесса. Выявление требований к процессу. Используемые фазы, вехи и артефакты. Выбор архитектуры процесса. Порядок проведения типового проекта . Документированные процедуры.
7. Модели команды разработчиков. Коллективный характер разработки. Оптимальный размер команды. Подчиненность участников проекта. Развитие команды и развитие персонала. Специализация, кооперация и взаимодействие.
8. Модели команды разработчиков. Иерархическая модель команды. Метод хирургической бригады. Модель команды равных.
9. Природа программирования. Наука программирования. Искусство программирования. Ремесло программирования. Парадигмы программирования. Структурное программирование. Логическое программирование. Объектно-ориентированное программирование.
10. Программная архитектура. Событийное управление. Архитектура клиент/сервер. Службы. Трёхслойная архитектура. Проектирование программ. Концептуальное проектирование. Логическое проектирование. Детальное проектирование.
1. Новиков подходы к разработке ПО» http://window. /window_catalog/files/r60368/itmo307.pdf.
2. Экстремальное программирование. – Спб.: Питер, 2002.
3. Технология разработки программного обеспечения. – СПб. : Питер, 2004.
4. Брукс-мл. проектируются и создаются программные комплексы. М.: Наука, 1975; новое издание перевода: Мифический человеко-месяц. СПб.: СИМВОЛ+, 1999.
5. Алгоритмы + структуры данных = программы. М., Мир, 1978.
6. Систематическое программирование. Введение. М.: Мир, 1977.
7. Структурное программирование. М.: Мир, 1975.
8. Дисциплина программирования. М.: Мир, 1978.
9. Технологии разработки программного обеспечения. – СПб.: Питер, 2002.
10. Терехов программирования. М.: БИНОМ, 2006.
11. Рамбо Дж. Унифицированный процесс разработки программного обеспечения. СПб: Питер, 2002.
Экономическая теория для менеджеров
Основные микроэкономические теории. Примеры применения в анализе экономических процессов. Основные макроэкономические теории. Примеры применения в анализе экономических процессов. Принципы и методы управления экономическими процессами. Инструментарий оценки уровня развития экономических процессов Проблемы расширенного воспроизводства. Факторы экономического роста российской экономики. Критерии и индикаторы устойчивого развития. Сглаживание циклических колебаний. Роль мультипликатора и акселератора в оценке темпов развития экономики. Производственные функции в экономике. Примеры применения в анализе экономических процессов. Прибыль. Расчет показателей, влияющих на прибыль, графическое изображение точки безубыточности . Методология реализации инвестиционной политики.Курс экономической теории : учебник для вузов / Под ред. . –Киров: «АСА», 2004. Колемаев -математическое моделирование. Моделирование макроэкономических процессов и систем: учебник. М.:ЮНИТИ-ДАНА, 2005. Бажин кибернетика. Харьков: Консул, 2004. Леушин практикум по методам математического моделирования: учебное пособие . Нижегородский гос. техн. унив.- Н. Новород, 2007. Политикам об экономике: Лекции нобелевских лауреатов по экономике. М.: Современная экономика и право, 2005. Черемных. Продвинутый уровень: Учебник.-М.:ИНФРА-М, 2008. Эволюция институтов миниэкономики. Институт экономики УРО РАН,- М.: Наука, 2007.
Технологии разработки и принятия управленческих решений [ Н]
Принятие решений как основа деятельности менеджера. Введение в теорию принятия решений. Основные понятия теории принятия решений. Модели управления бизнесом и их влияние на принятие решений. Различные способы классификации решений. Классификации: по степени формальности, по степени рутинности, по периодичности, по срочности, по степени достижения целей, по способу выбора альтернативы. Основные методы принятия решений. Волевые методы принятия решений. Цели принятия решений. Время при поиске решений. Основные ошибки Математические методы принятия решений. Математические аспекты теории принятия решений. Исследование операций. Математический подход к принятию решений. Дерево решений. Модели разработки и принятия решений. Теория игр. Математические методы принятия решений. Математические аспекты теории принятия решений. Модели теории очередей. Модели управления запасами. Модель линейного программирования. Транспортные задачи. Имитационное моделирование. Сетевой анализ. Экономический анализ. Ограниченность рациональных моделей. Особенности разработки и принятия решений в группе. Метод определения групповой сплоченности на основе степени связности множеств. Методики принятия коллективного решения. Метод консенсуса. Методы голосования. Творческие методы принятия решений. Мозговой штурм. Конференция идей. Корабельный совет. Метод «Мысленных шляп» по де-Боно. Теория решения изобретательских задач (ТРИЗ). Идеальное конечное решение. Примеры задач и их решения при помощи ТРИЗ. Применение методов ТРИЗ при принятии уникальных и творческих решений. Методы разработки идей решений и их адаптация к ситуации. Модель дерева целей . Стратегия согласования интересов. Формирование решений по согласованию интересов. Методы определения интересов контрагентов . Системы поддержки принятия решений (экспертные системы). История создания систем принятия решений. Классификация систем принятия решений. Типовая структура экспертной системы. Способы представления знаний. Способы логического вывода. Применение экспертных систем на практике.И. Теория принятия решений: учебник. - М.: Экзамен, 2006. - 573 с. И. Принятие решений. Теория и методы разработки управленческих решений. Учебное пособие. - М.: МарТ, 2005. - 496 с Г. Разработка управленческого решения - М.: Издательство «Дело», 2004 г. - 392 с. Г. Экспертные оценки и принятие решений.- М.: Патент, 1996. - 271 с. Таха // Введение в исследование операций = Operations Research: An Introduction. - 7-е изд. - М.: «Вильямс», 2007. - С. 549-594. Г. Тейл. Экономические прогнозы и принятие решений. М.: «Прогресс» 1970. К. Д. Льюис. Методы прогнозирования экономических показателей. М.: «Финансы и статистика» 1986. Г. С. Кильдишев, А. А. Френкель. Анализ временных рядов и прогнозирование. М.: «Статистика» 1973. О. Ким, Ч. У. Мьюллер, У. Р. Клекка и др. Факторный, дискриминантный и кластерный анализ. М.: «Финансы и статистика» 1989. Эффективный менеджер. Книга 3. Принятие решений. – МИМ ЛИНК, 1999 Туревский и управление автотранспортным предприятием. - М.: Высшая школа, 2005. , ; под ред. . Системный анализ в управлении: учебное пособие. – М.: Финансы и статистика, 2006. , Тиньков: учебное пособие. – М.: КНОРУС, 2006.
Моделирование бизнес-процессов в интегрированных системах менеджмента
По каким принципам выделяют бизнес-процессы? В чем заключается проблема целостного описания бизнес-процессов. Что такое система, какими свойствами она обладает? Роль системного анализа в моделировании бизнес-процессов? Процесс, как объект управления. Окружение процесса. Основные элементы бизнес-процесса. Достоинства и недостатки функционального и процессного менеджмента. Управленческий цикл PDCA. Этапы цикла управления процессами. Цикл PDCA и реализация требований стандарта ISO 9001:2008. Методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования). Сущность. Основные положения. Как представляется функциональная модель деятельности в методологии IDEF0? Что обозначают работы в диаграммах функциональной модели, как они отображаются по методологии IDEF0? Для чего предназначены стрелки в диаграммах функциональной модели, каковы их типы и виды? Методология DFD. Сущность. Основные компоненты диаграмм DFD. В чем особенности DFD-диаграмм, что в них описывается? В чем особенности объектов DFD-диаграмм? Что обозначают стрелки на диаграмме DFD? Методология IDEF3. Сущность. Средства документирования и моделирования. В чем особенности IDEF3-диаграмм, что в них описывается? В чем особенности объектов IDEF3-диаграмм? И стрелок? Классификация процессов. Типовые бизнес-процессы. Реинжиниринг и его технология. Когда целесообразно применять реинжиниринг при управлении компанией? Мониторинг и измерение процессов. Показатели процессов организации. Численная и рейтинговые оценки процессов."Моделирование бизнес-процессов с AllFusion Process Modeler (BPwin 4.1)Диалог-МИФИ" 2003 "Создание информационных систем с AllFusion Modeling Suite" изд. "Диалог-МИФИ" 2003 "Практика функционального моделирования с AllFusion Process Modeler 4.1. (BPwin) Где? Зачем? Как?" изд. "Диалог-МИФИ" 2004 Дубейковский моделирование с AllFusion Process Modeler (BPwin). изд. "Диалог-МИФИ" 2007 Д. Марка, К. МакГоуэн "Методология структурного анализа и проектирования SADT" 1993 г. классический труд по методологии SADT. Черемных анализ систем: IDEF-технологиис, Моделирование и анализ систем. IDEF-технологии. Практикум. M.: Финансы и статистика, 2001. , “Структурные модели бизнеса: DFD-технологии” http://www. /Level4.asp? ItemId=5810 "Теория и практика реорганизации бизнес-процессов"2003/ P50.1.. Методология функционального моделирования. М.: Госстандарт России, 2000. http://www. IDEF0, IDEF3, DFD http://www. Моделирование бизнес-процессов средствами BPwin http://www. /department/se/devis/7/ IDEF0 в моделировании бизнес-процессов управления http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.
Оценка эффективности программных продуктов
1. Архитектура ИТ
2. Домены процессов управления.
3. Перечень процессов домена Планирование и Организация
4. Перечень процессов домена Приобретение и Внедрение
5. Перечень процессов домена Эксплуатация и Сопровождение
6. Перечень процессов домена Мониторинг и Оценка
7. Характеристика уровней модели зрелости процессов
9. KPI и KGI их взаимосвязь и назначение
1. 10.Общие меры контроля в ИТ и меры контроля приложений. Зоны ответственности и обязанности бизнеса и ИТ.
Cobit 4.1 российское издание.
Правовое регулирование создания и использования интеллектуальной собственности
1. Перечислите интеллектуальные права на результаты интеллектуальной деятельности и раскройте их содержание.
2. Перечислите виды договоров по распоряжению исключительным правом. Охарактеризуйте каждый из указанных договоров по распоряжению исключительным правом.
4. Охарактеризуйте основные положения правовой охраны Программы для ЭВМ как объекта авторского права .
5. Сравните основные положения правовой охраны Базы данных как объекта авторского права и как объекта смежных прав.
6. Охарактеризуйте условия патентоспособности объектов патентных прав: изобретений; полезных моделей; промышленных образцов.
7. Раскройте содержание критериев патентоспособности изобретения: новизна; изобретательский уровень; промышленная применимость.
8. Охарактеризуйте условия и порядок получения патента на изобретение, полезную модель или промышленный образец, а также условия, обеспечивающие действие патентов, и сроки их действия.
9. Дайте определение «ноу-хау» и перечислите условия, при создании которых возникает и осуществляется правовая охрана секретов производства.
10. Перечислите охраняемые средства индивидуализации и дайте их сравнительную характеристику.
1. , Право интеллектуальной собственности в Российской Федерации, учебник // М, Проспект, 2007 г.
2. , Право интеллектуальной собственности, учебное пособие // М, РИОР, 2009 г.
Управление проектами и разработкой ПО [ И]
Что такое методология, зачем она нужна. Общая структура методологии, основные элементы методологии. Принципы конструирования собственной методологии. Примеры различных артефактов, ролей, компетенций, граничных условий. Структура методологии по Коуберну, метрики методологии. Критерии проекта по Коуберну. Критерии выбора методологии, матрица Коуберна. Жизненный цикл проекта. Водопадная и итерационные модели жизненного цикла. Границы применимости для водопадной и итерационной моделей. RUP как пример итерационной методологии. Основные концепции RUP, границы применимости. Роль человека в разработке ПО. Гибкие методологии, основные принципы гибких методологий. Причина возникновения гибких методологий. Scrum как пример гибкой методологии. Роли, артефакты, деятельности в Scrum. Границы применимости Scrum. Экстремальное программирование (XP) Идеи, ценности, основные практики, границы применимости. Сходства и различия между Scrum и XP. Сбор и управление требованиями. Основные практики, термины, принципы. Подходы к документированию проекта и продукта, основные виды документов. Примеры практик по управлению требованиями из рассмотренных в курсе методологий. Планирование разработки ПО. Типы планов, управление риском, популярные риски. Примеры практик по планированию разработки из рассмотренных в курсе методологий. Тестирование при разработке ПО. Понятие сборки (билда) программного продукта. Основные методы тестирования, термины. Примеры практик по тестированию из рассмотренных в курсе методологий. Понятие сборки (билда), способы хранения кода, инструменты. Два принципа организации работы с системой контроля версий. Особенности процесса выпуска/выкладки продукта для разных категорий продуктов, примеры практик. Современные концепции архитектуры ПО, многоуровневые архитектуры, критерии архитектуры. Список необходимых решений при проектировании ПО, подходы к выбору системы хранения данных.Кент Бек - Экстремальное программирование Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы. Том де Марко - Deadline. Роман об управлении проектами. Том де Марко, Тимоти Листер - Вальсируя с медведями. Том де Марко, Тимоти Листер - Человеческий фактор_ успешные проекты и команды. Алистер Коуберн - Каждому проекту своя методология. Алистер Коуберн - Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения. Андрий Орлов - Записки автоматизатора. Профессиональная исповедь. Филипп Крачтен - Введение в Rational Unified Process. Хенрик Книберг - Scrum и XP: заметки с передовой. Презентации лекций по курсу
Водопадная модель Анализ требований Проектирование Реализация Интеграция Тестирование Составляется спецификация продукта Составляется архитектура продукта Разработка исходного кода Интеграция отдельных частей исходного кода Тестирование и устранение дефектов
Унифицированный процесс разработки программного обеспечения (USDP) Модель вариантов использования, описывает случаи, в которых приложение будет использоваться. Аналитическая модель описывает базовые классы для приложения. Модель проектирования описывает связи и отношения между классами и выделенными объектами Модель развертывания описывает распределение программного обеспечения по компьютерам. Модель реализации описывает внутреннюю организацию программного кода. Модель тестирования состоит из тестирующих компонентов, тестовых процедур и различных вариантов тестирования
Типичные компоненты архитектуры программного продукта и типичные требования к ПО Организация программы Основные классы системы Организация данных Бизнес–правила Пользовательский интерфейс Управление ресурсами Безопасность Производительность Масштабируемость Взаимодействие с другими системами (интеграция) Интернационализация, локализация Ввод-вывод данных Обработка ошибок
Типичные компоненты архитектуры программного продукта и типичные требования к ПО Отказоустойчивость – совокупность свойств системы, повышающая ее надежность путем обнаружения ошибок, восстановления и локализации плохих последствий для системы. При разработке любой реальной системы для обеспечения отказоустойчивости необходимо предусматривать всевозможные ситуации, которые могут привести к сбою системы и разработать механизмы обработки сбоев. Надежность – способность системы противостоять различным отказам и сбоям. Отказ – это переход системы в результате ошибки в полностью неработоспособное состояние. Сбой – ошибка в работе системы, которая не приводит к выходу системы из строя. Чем меньше отказов и сбоев за какой-то определенный интервал времени, тем система считается надежнее.
Типичные компоненты архитектуры программного продукта и типичные требования к ПО Возможности реализации разрабатываемой архитектуры. Возможности реализации разрабатываемой архитектуры. Избыточная функциональность. Избыточная функциональность. Принятие решение о приобретении готовых компонент ПО. Принятие решение о приобретении готовых компонент ПО. Стратегия изменений. Стратегия изменений.
Ясно ли описана общая организация программы; включает ли спецификация обзор архитектуры и ее обоснование. Ясно ли описана общая организация программы; включает ли спецификация обзор архитектуры и ее обоснование. Адекватно ли определены основные компоненты программы, их области ответственности и взаимодействие с другими компонентами. Адекватно ли определены основные компоненты программы, их области ответственности и взаимодействие с другими компонентами. Все ли функции, указанные в спецификации требований, реализованы разумным количеством компонентов системы. Все ли функции, указанные в спецификации требований, реализованы разумным количеством компонентов системы. Приведено ли описание самых важных классов и их обоснование. Приведено ли описание самых важных классов и их обоснование. Приведено ли описание организации БД. Приведено ли описание организации БД. Определены ли все бизнес правила. Определены ли все бизнес правила. Описано ли их влияние на систему. Описано ли их влияние на систему. Контрольный список вопросов, который позволяет сделать вывод о качестве архитектуры:
Контрольный список вопросов, который позволяет сделать вывод о качестве архитектуры: Описана ли стратегия проектирования пользовательского интерфейса. Описана ли стратегия проектирования пользовательского интерфейса. Сделан ли пользовательский интерфейс модульным, чтобы его изменения не влияли на оставшуюся часть системы. Сделан ли пользовательский интерфейс модульным, чтобы его изменения не влияли на оставшуюся часть системы. Приведено ли описание стратегии ввода-вывода данных. Приведено ли описание стратегии ввода-вывода данных. Проведен ли анализ производительности системы, которая будет реализовываться с использованием данной архитектуры. Проведен ли анализ производительности системы, которая будет реализовываться с использованием данной архитектуры. Проведен ли анализ надежности проектируемой системы. Проведен ли анализ надежности проектируемой системы. Проведен ли анализ вопросов масштабируемости и расширяемости системы. Проведен ли анализ вопросов масштабируемости и расширяемости системы.
Рефакторинг ПО Код повторяется; реализация метода слишком велика; слишком большая вложенность циклов, или же сам цикл очень большой; класс имеет плохую связность (свойства и методы класса должны описывать только 1 объект); интерфейс класса не формирует согласованную абстракцию; метод принимает слишком много параметров. Необходимо стараться, чтобы количество параметров было разумно минимальным; отдельные части класса изменяются независимо от других частей класса; Рефакторинг предполагает адаптацию программного обеспечения к новому аппаратному обеспечению и к новым ОС, новым средствам разработки, новым требованиям, а также архитектуре и функциональности ПО. Это изменение внутренней структуры ПО без изменения его внешнего поведения, призванное обеспечить модификацию ПО. Разумные причины проведения рефакторинга:
Рефакторинг ПО при изменении программы требуется параллельное изменение нескольких классов. При возникновении такой ситуации необходимо провести реорганизацию классов с целью минимизации в будущем мест возможных изменений; приходиться параллельно изменять несколько иерархий наследования; приходиться изменять несколько блоков case. Необходимо провести модификацию программы таким образом, чтобы сделать реализацию блока case, а вызывать ее в нужном количестве раз в программе; родственные элементы данных, используемые вместе, не организованы в классы. Если вы неоднократно используете один и тот же набор элементов данных, то целесообразно рассмотреть объединение этих данных и выполняемые над ними операции поместить в отдельный класс;
Рефакторинг ПО метод использует больше элементов другого класса, чем собственного. Это означает, что метод нужно переместить в другой класс и вызывать его из старого; элементарный тип данных перегружен. Для описания сущности реального мира лучше использовать какой- либо класс, чем перегружать какой-либо существующий тип данных; класс имеет слишком ограниченную функциональность. Лучше от этого класса избавиться, перенеся его функциональность в другой класс; по цепи методов передаются «бродячие» данные. Данные, передаваемые в метод только для того, чтобы он их передал другому методу, называются «бродячими». При возникновении таких ситуаций постарайтесь изменить архитектуру классов и методов, чтобы от них избавиться.
Рефакторинг ПО объект-посредник ничего не делает. Если роль класса сводится к перенаправлению вызовов методов в другие классы, то лучше всего такой объект-посредник устранить и выполнять вызовы других классов непосредственно; один класс слишком много знает о другом классе. В этой ситуации необходимо сделать инкапсуляцию более строгой, чтобы обеспечить минимальное знание наследника о своем родителе; метод имеет неудачное имя; данные-члены являются открытыми. Это стирает грань между интерфейсом и реализацией, неизбежно нарушает инкапсуляцию, и ограничивает гибкость программы; размещать комментарии в исходном коде;
Рефакторинг ПО подкласс использует только малую долю методов своих предков. Такая ситуация возникает тогда, когда новый класс создается только лишь для наследования нескольких методов из базового класса, а не для того, чтобы описать какую-либо новую сущность. Для того, чтобы этого избежать, необходимо преобразовать базовый класс, таким образом, чтобы он давал доступ новому классу только к необходимым ему методам; код содержит глобальные переменные. Глобальными должны быть только те переменные, которые в действительности используются всей программной. Все остальные переменные должны быть либо локальными, либо должны стать свойствами каких-либо объектов; программа содержит код, который может когда-нибудь понадобиться. При разработке системы целесообразно предусмотреть места, куда в будущем может быть добавлен исходный код.
