Информационные технологии. Ответы

 

В соответствие с RUP жизненный цикл программного продукта состоит из серии относительно коротких итераций:

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

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

1. Начало — основное внимание уделяется задачам анализа.
2. Разработка — основное внимание уделяется проектированию и опробованию ключевых проектных решений.
3. Построение — наиболее велика доля задач разработки и тестирования.
4. Передача — решаются в наибольшей мере задачи тестирования и передачи системы Заказчику.

Основные процессы RUP:

• Бизнес моделирование
• Управление требованиями
• Анализ и проектирование
• Реализация
• Тестирование
• Развертывание

Вспомогательные процессы RUP:

• Конфигурационное управление и управление изменениями
• Управление проектом
• Управление средой разработки

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

№7 Модели быстрого развития и экстремального программ-я ЖЦИС

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

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

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

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

№8 Методы исследования и способы описания предметной области.

Исследование  предметной области дает основу для  построения целей ИС и решаемых задач. Наиболее важными при определении целей проекта создания информационной системы является получение полной информации о бизнес процессах предприятия. Примерами получаемой инф-ции является:

1. официальные правила деятельности
2. неофициальные правила деятельности
3. правила документооборота
4. система управления качеством
5. правила не оформляемого документооборота

Только после  полного анализа всех элементов  присутствующих в деятельности подразделений  предприятия возможно успешное определение  целей проекта и эффективное  планирование дальнейших действий:

• Реинжиниринг бизнес процессов и активностей предприятия;
• Определение потребностей предприятия;
• Оценка возможных перспектив развития;

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

• Совершенствование организационной структуры;
• Оптимизация бизнес процессов;
• Выбор оптимальной модели решения.

Возможны следующие  проекции (модели) предприятия:

• Структура процессов, функциональная модель (методологии IDEF0 и DFD).
• Логика процессов, потоковая модель (методология IDEF3).
• Поведение процессов, динамическая модель (методологии IDEF2 и STD).
• Данные процессов, информационная модель (методологии IDEF1X и ERD).

При создании ИС рекомендуется построить как  минимум две модели: функциональную, определяющую процессы и правила, с  помощью которых система выполняет  свою миссию, и информационную.  
 

№9 Предпроектное обследование предметной области

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

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

Второй подход, достаточно часто применяемый при построении АСОИУ, включает в себя проведение информационного обследования объекта (предметной области), выявление основных информационных потоков, построения, как правило, имитационной модели функционирования объекта и далее выход также на инфологическое и рабочее проектирование.

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

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

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

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

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

На ряду со структурным  подходом существует и более мощный подход называемый объектно-ориентированным  ООП. Эта методология создана  для проектирования больших и сложных систем.

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

Объектная модель имеет четыре главных элемента: абстрагирование, инкапсуляция, модульность, иерархия.

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

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

№10 Технология разработки малых проектов

Малое программное  средство (МПС) – продукт, создаваемый  одним программистом или малым  коллективом (2…3 человека).

Достоинства работы в одиночку:

• Нет необходимости согласовывать сроки, разделение труда, распределение средств
• Нет ответственности перед коллегами
• Свободный выбор работ и заказчиков
• Свободный выбор технологии производства работ, возможность опускать какие-то

Недостатки:

• Нужно быть универсалом: производить переговоры, вести договорную работу, самостоятельно выполнять весь цикл работ от составления внешнего описания до сопровождения МПС
• Нужно иметь юридическое прикрытие (ЧП, ООО) или работать на условиях физического лица
• Полная ответственность перед заказчиком
• Необходимость самостоятельно оценивать свою работу
• Необходимость напрямую работать со всеми категориями заказчиков (от директора до оператора)

Обычно ЖЦРП МПС имеет итеративный характер:

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

На каждом этапе  работы не завершаются полностью  до начала следующего этапа.

Пример  реализации ЖЦРП МПС:

1. Предварительное знакомство с предметной областью
2. Обследование предприятия (отдела, участка, рабочего места). Выявление горизонтальных и вертикальных связей с другими участками
3. Знакомство с входящей и исходящей (по отношению к ПС) документацией. Формирование структур данных на их основе (проектирование БД).
4. Оценка стоимости разработки ПС и заключение предварительного договора на разработку.
5. Разработка ПС на основе своих представлений о предметной области (предварительная реализация). Документирование принятой модели сущностей и связей. Документирование процесса разработки. Проектирование и создание (или заполнение) словарей и справочников.
6. Тестирование на первичном материале заказчика.
7. Опытная эксплуатация. Доводка ПС согласно мелких изменений требований.
8. Документирование ПС. Составление FAQ по вопросам пользователей.
9. Придание ПС «товарного вида» - написание инсталлятора, систем защиты, счетчика запусков или журнала действий пользователя и т.п.
10. Достижение окончательных договоренностей по оплате разработки и внедрения.
11. Постановка цели и определение стоимости сопровождения ПС.
12. Сопровождение и внесение изменений в ПС. Совмещение требований различных пользователей: настройкой, условной компиляцией.
13. Разработка новых версий ПС: новые алгоритмы (ускорение) или новые возможности (расширение). Изменение интерфейсной части, улучшение адаптируемости, мобильности на новые или старые платформы.
14. Выделение из готового ПС модулей многократного использования, документирование в тексте или написание документации, составление и документирование библиотек.
15. Разработка и предложение заказчику новых ПС, улучшающих или расширяющих возможности внедренного ПС.