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

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

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

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

В соответствии с международным стандартом ISO/IEC 12207 «информационные технологии – Процессы жизненного цикла ПО» процесс разработки ПО содержит следующие этапы жизненного цикла ПО:

1) анализ системных требований и области применения;

2) проектирование архитектуры системы;

3) анализ требований к ПО(спецификации, внешние интерфейсы,);

4) проектирование архитектуры ПО;

5) детальное проектирование каждой единицы ПО;

6) кодирование ПО (программирование)

7) тестирование единиц ПО;

8) интеграция (объединение ПО) и тестирование совокупности единиц ПО;

9) квалификационные испытания ПО (комплексное тестирование);

10) интеграция системы единицы структуры ПО должны быть объединены с единицами аппаратных средств;

11) квалификационные испытания системы;

12) установка ПО.

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

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

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

Спиральная модель жизненного цикла ПО. «Тяжелые и облегченные» (быстрые) технологии разработки ПО

Рассмотренная модель жизненного цикла (ЖЦ) относится к модели каскадного типа. Этот тип модели ЖЦ хорош для ПО, для которого в самом начале разработки возможно полно и точно сформулировать все требования к ПО.

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

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

Главная задача как можно быстрее достичь работоспособного ПО, активизируя тем самым процесс уточнения и дополнения требований. Это так называемая спиральная модель ЖЦ ПО.

На каждом витке спирали выполняется создание версии продукта, уточняются требования к ПО и планируются работы следующего витка. Спиральная модель ЖЦ ПО отражает объективно существующий процесс итеративной разработки ПО (рис. 8.2).

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

Существует направление «Быстрых технологий» разработки ПО (Agile Software Development), дающее идеологическое обоснование взглядам, связанным с спиральной моделью ЖЦ. Эти технологии базируются на четырех идеях:

Интерактивное взаимодействие индивидуумов важнее формальных процедур и инструментов,

Работающее ПО важнее наличия документации на него,

Сотрудничество с заказчиком важнее формальных договоров,

Быстрое реагирование на внешние изменения важнее строгого следования намеченным планам.

Рис. 8.2 - Схема спирального ЖЦ ПО

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

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

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

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

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

«Тяжелые и облегченные» технологии разработки ПО. Разработчики многих видов ПО считают каскадную модель жизненного цикла слишком регламентированной, слишком документированной и тяжелой и поэтому нерациональной. Существует направление «Быстрых технологий» (легких технологий) разработки ПО (Agile Software Development), дающее идеологическое обоснование этим взглядам. Эти технологии базируются на четырех идеях:

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

2. работающее ПО важнее наличия документации на него,

3. сотрудничество с заказчиком важнее формальных договоров с ним,

4. быстрое реагирование на внешние изменения важнее строгого следования намеченным планам.

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

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

Примером Agile технологий является «Экстремальное программирование» (ХР). Итерации в ХР очень короткие и состоят из четырех операций: кодирования, тестирования, выслушивание заказчика, проектирование. Принципы ХР – минимальность, простота, участие заказчика, короткий цикл, тесные взаимодействия разработчиков – они должны сидеть в одной комнате, ежедневных оперативных совещаний совместно с заказчиком представляются разумными и давно применяются не только в быстрых технологиях, но в ХР они доведены до экстремальных значений.

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

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

В больших коллективах разработчиков проблема управления – выходит на передний план.

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

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

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

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

Как получится…

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

Разработка «Как получится»

А как обстоит дело с применением итеративного подхода? Увы, как правило, он в таких проектах не используется. Прежде всего потому, что он бы позволил еще на первых итерациях оценить проект как крайне сомнительный и требующий срочного вмешательства более высокого руководства для наведения порядка. Ведь в итеративном проекте традиционный ответ программиста, что у него уже все на 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, в отличие от большинства других методологий, позволяет в широком диапазоне выбирать степень формализации и итеративности процесса разработки в зависимости от особенностей проектов и разрабатывающей организации.

А почему это так важно - мы обсудим в следующей части.

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: заметки с передовой. Презентации лекций по курсу

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

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

1. Принцип «разделяй и властвуй»;

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

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

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

2. Принцип непротиворечивости,обоснованность и согласованность элементов системы.

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

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

· DFD (Data Flow Diagrams) - диаграммы потоков данных;

· SADT (Structured Analysis and Design Technique - методология структурного анализа и проектирования) - модели и соответствующие функциональные диаграммы: нотации IDEF0 (функциональное моделирование систем), IDEF1х (концептуальное моделирование баз данных), IDEF3х (построение систем оценки качества работы объекта; графическое описание потока процессов, взаимодействия процессов и объектов, которые изменяются этими процессами);

· ERD (Entity - Relationship Diagrams) - диаграммы «сущность-связь».

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

1. Диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - DFD или SADT (IDEF0).

2. Диаграммы, моделирующие данные и их отношения (ERD).

Конкретный вид перечисленных диаграмм и интерпретация их конструкций зависят от стадии ЖЦ ПО.

На стадии формирования требований к ПО SADT-модели и DFD используются для построения модели “AS-IS” и модели “TO-BE”, отражая таким образом существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними (использование SADT-моделей, как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ПО). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимо от средств реализации базы данных (СУБД).

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

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

Базовыми принципами структурного подхода являются:

o принцип "разделяй и властвуй";

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

Основными из этих принципов являются:

o абстрагирование - выделение существенных аспектов системы;

o непротиворечивости - обоснованность и согласованность элементов системы;

o структурирование данных - данные должны быть структуро-ване и иерархически организованы.

Методические основы технологий создания программного обеспечения

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

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

o трудностей проектируемой системы;

o необходимой полноты ее описания;

o знаний и навыков участников проекта;

o времени, отведенного на проектирование.

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

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