Тарифы МТС 

Технологии разработки программного обеспечения. Системный подход к разработке ПО. Временной и "пространственный " аспекты системного подхода. Каскадная модель жизненного цикла ПО Подходы к разработке по


Водопадная модель Анализ требований Проектирование Реализация Интеграция Тестирование Составляется спецификация продукта Составляется архитектура продукта Разработка исходного кода Интеграция отдельных частей исходного кода Тестирование и устранение дефектов












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








Типичные компоненты архитектуры программного продукта и типичные требования к ПО Организация программы Основные классы системы Организация данных Бизнес–правила Пользовательский интерфейс Управление ресурсами Безопасность Производительность Масштабируемость Взаимодействие с другими системами (интеграция) Интернационализация, локализация Ввод-вывод данных Обработка ошибок


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




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


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


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


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


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


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


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


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

1.Кодирование

На этапе разработки ПП выполняются следующие основные действия: кодирование; тестирование; разработка справочной си­стемы ПП; создание документации пользователя; создание вер­сии и инсталляции ПП,

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

При кодировании необходимо следовать стандарту на выбран­ный язык, например, для языка С - это ANSI С, а для C++ - ISO/IEC 14882 «Standartforthe C++ ProgrammingLanguage».

Кроме общепринятого стандарта на язык программирования в компании могут использоваться разработаны и свои дополнитель­ные требования к правилам написания программ. В основном они касаются правил оформления текста программы.

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

На этапе кодирования программист пишет программы и сам их тестирует. Такое тестирование называется модульным. Все воп­росы, связанные с тестированием ПП, рассмотрены в гл. 10, здесь же описана технология тестирования, которая применяется на этапе разработки ПП. Эта технология называется тестированием «стеклянного ящика» (glassbox); иногда ее еще называют тестиро­ванием «белого ящика» (whitebox) в противоположность класси­ческому понятию «черного ящика» (blackbox).

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

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

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

2.Полный охват кода. Программист всегда может определить, какие именно фрагменты кода работают в каждом тесте. Он видит, какие еще ветви кода остались непротестированными, и может подобрать условия, в которых они будут протестированы. Ниже описано, как отслеживать степень охвата программного кода про­веденными тестами.

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

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

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

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

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

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

Структурное тестирование является одним из видов тестирования «стеклянного ящика». Его главной идеей является правиль­ный выбор тестируемого программного пути. В противоположность ему функциональное тестирование относится к категории тестиро­вания «черного ящика». Каждая функция программы тестируется путем ввода ее входных данных и анализа выходных. При этом внутренняя структура программы учитывается очень редко.

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

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

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

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

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

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

У хорошо документированного ПП имеются следующие преимущества.

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

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

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

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

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

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

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 выполняется описание используемых в организации данных на концептуальном уровне, не зависимо от средств реализации базы данных (СУБД).

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

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

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

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

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

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

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