630_Poletajkin_A.N._Sotsial'nye_iehkonomicheskie_informatsionnye_sistemy_
.pdfСтруктура ЖЦ ИС по стандарту ISO/IEC 12207, положенного в основу ГОСТ Р ИСО/МЭК 12207–99 [16], базируется на трех группах процессов:
основные процессы ЖЦ ИС (приобретение, поставка, разработка, эксплуатация, сопровождение и т.п.);
вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, документо-
оборотом, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ,
обучение).
Вспомогательные процессы предназначены для поддержки выполнения основных процессов, обеспечения качества проекта, организации верификации, проверки и тестирования ИС. Организационные процессы определяют действия и задачи, выполняемые как заказчиком (пользователем), так и разработчиком проекта для управления основными и вспомогательными процессами.
Разработка включает в себя все работы по созданию ИС и ее компонентов в соответствии с заданными требованиями, а именно:
оформление проектной и эксплуатационной документации;
подготовку материалов, необходимых для проверки работоспособно-
сти и качества программных продуктов;
подготовку обучающих материалов для персонала;
и т.д.
Разработка ИС включает в себя, как правило, анализ предметной области, проектирование и реализацию.
Эксплуатация включает в себя работы по внедрению компонентов ИС в эксплуатацию, при этом предполагается:
конфигурирование базы данных и рабочих мест пользователей;
обеспечение эксплуатационной документацией;
обеспечение обучения персонала;
локализацию проблем и устранение причин их возникновения;
модификацию ИС в рамках установленного регламента;
подготовку предложений по совершенствованию, развитию и модернизации системы;
и т.д.
Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством работ.
81
Обеспечение качества проекта связано с проблемами верификации, проверки, а также тестирования ИС.
Верификация – это процесс определения того, отвечает ли текущее состояние разработки, достигнутое на данном этапе, требованиям данного этапа.
Проверка позволяет оценить соответствие параметров разработки заданным требованиям. Проверка частично совпадает с тестированием, которое связано с идентификацией различий между действительными и ожидаемыми результатами и оценкой соответствия характеристик ИС заданным требованиям.
Управление конфигурацией является одним из вспомогательных процессов, поддерживающий прежде всего такие основные процессы ЖЦ, как разработка и эксплуатация ИС. При создании проектов сложных ИС (состоящих из многих компонентов, каждый из которых может иметь разновидности и/или версии) возникает проблема учета связей и функций множества их компонентов, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией также позволяет организовать, систематически учитывать и отслеживать внесение изменений в ИС на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурацией ИС отражены в стандарте ISO/IEC 12207.
Каждый процесс ЖЦ ИС характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Например, результатами анализа являются функциональные, информационные модели и соответствующие им диаграммы. ЖЦ ИС носит итерационный характер: результаты очередного этапа очень часто вызывают изменения в проектных решениях, выработанных на более ранних этапах.
2.3.4 Модели жизненного цикла ИС
В однородных ИС, которые создавались ранее, каждое приложение представляло собой единое целое. Для разработки такого типа систем применялся так называемый каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после полного завершения работ на текущем (рис. 2.6). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена на следующем этапе другой командой разработчиков.
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию
82
попадают сложные расчетные системы, системы реального времени и другие системы, решающие подобные задачи. Однако в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания ИС никогда полностью не укладывался в такую жесткую схему. В процессе создания ИС постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ИС принимал следующий вид
(рис. 2.7).
Рис. 2.6. Каскадная схема разработки ИС
Рис. 2.7. Реальный процесс разработки ИС по каскадной схеме
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов разработки. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, заказчики могут внести свои замечания только после того, как работа над системой будет полностью завер-
83
шена. В случае неточного изложения требований или их изменения в течение длительного периода создания ИС, заказчики получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) объекта информатизации могут устареть одновременно с их утверждением.
Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ (рис. 2.8), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов ИС, реализующих эти решения. Каждый виток спирали (итерация) соответствует созданию фрагмента или версии ИС, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующей итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до конечной реализации.
Разработка итерациями отражает объективно существующий спиральный цикл создания информационной системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем этапе. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача – как можно быстрее показать заказчиками системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Рис. 2.8. Спиральная модель ЖЦ ИС
Особенности спиральной модели заключаются в том, что степень готовности продукта считается возрастающей величиной в зависимости от времени работы над продуктом. Процесс разработки состоит из определенной последовательности этапов. Функция возрастания степени готовности программного продукта от времени изображается в полярной системе координат, где угол ра-
84
диус-вектора определяет время, отсчитанное от начала работы над очередной версией, а абсолютная величина радиус-вектора определяет степень готовности продукта. При разработке очередной версии продукта все этапы повторяются в той же последовательности, а задачей является увеличение степени функциональной полноты продукта.
Основная проблема спирального цикла – определение момента перехода на следующий этап. Для ее решения вводятся временные ограничения на каждый из этапов жизненного цикла. Данный план составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа завершена.
2.3.5 Принципы управления жизненным циклом ИС
Управление жизненным циклом ИС основывается в основном на управле-
нии жизненным циклом ее программной части – приложения. В процессе совершенствования ЖЦ ИС в соответстии с CMMI выработалось понятие об
управлении жизненным циклом приложений (application life cycle management – ALM) – концепция управления программным проектом на всех этапах его жизненного цикла. Для реализации этой концепции компания Microsoft предлагает решение на основе Visual Studio. Технологии ALM расширяют Visual Studio до VSTS и позволяют разработчикам контролировать жизненный цикл создания ПО ИС, сокращая время разработки, устраняя издержки и внедряя непрерывный цикл реализации бизнес-ценностей.
Управление жизненным циклом приложения в VSTS базируется на сле-
дующих принципах:
Продуктивность (productivity) обеспечивается возможностью совместной работы и управлением сложностью продукта. Все элементы проекта (требования, задачи, тестовые случаи, ошибки, исходный код и построения) и отчеты централизованно управляются через VSTS. Инструменты визуального моделирования архитектуры, возможности управления качеством кода и средства тестирования позволяют управлять сложностью продукта.
Интеграция (integration) обеспечивается возможностями VSTS по предоставлению всем участникам проекта информации о состоянии дел, что упрощает коммуникацию между членами команды и обеспечивает прозрачность хода процесса проектирования.
Расширяемость (extensibility) обеспечивается API-интерфейсом служб VSTS и интегрированной средой разработки (integrated development environment – IDE). API-интерфейс служб VSTS позволяет создавать собственные инструменты и расширять существующие. IDE позволяет конечным поль-
85
зователям и сторонним разработчикам добавлять инструменты с дополнительными функциями.
Фактически, при создании программного продукта необходимо вначале спроектировать архитектуру, что возлагается на архитектора программного продукта. На основе архитектуры осуществляется разработка, что является предназначением разработчика программного продукта. Созданный продукт необходимо тестировать на его соответствие требованиям заказчика, что осуществляет тестировщик. Совместную командную работу архитектора, разработчика и тестировщика обеспечивают VSTS, предоставляя им необходимый инструментарий и функциональные возможности для выполнения требуемых работ.
2.4 Гибкие технологии разработки ИС
На основе спиральной модели строятся так называемые гибкие методо-
логии (agile) разработки ИС, при котором программный продукт создается по-
степенно, небольшими шагами, включающими реализацию определенного набора требований [31]. При этом предполагается, что требования могут изменяться. Команды, использующие гибкие методологии, формируются из универсальных разработчиков, которые выполняют различные задачи в процессе соз-
дания программного продукта.
При использовании гибких методологий минимизация рисков осуществляется путём сведения разработки к серии коротких циклов, называемых итерациями, продолжительностью 2-3 недели. При этом итерация представляет собой набор задач, запланированных на выполнение в определенный период времени. На каждой итерации создается работоспособный вариант системы, в которой реализуются наиболее приоритетные (для данной итерации) требования заказчика. На каждой итерации выполняются все необходимые виды деятельности. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что текущий продукт готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов требований к ИС, возможно, вносит коррективы в проект системы.
2.4.1 Значение гибкой разработки
Для методологии agile декларированы ключевые постулаты, позволяющие командам достигать высокой производительности. Их четыре:
1. Люди и взаимодействие. Люди – важнейшая составная часть успеха гибкой разработки. Отдельные члены команды и хорошие коммуникации
86
чрезвычайно важны для высокопроизводительных команд. Для содействия коммуникации гибкие методологии предполагают частые обсуждения результатов работы и внесение изменений в решения. Обсуждения проводятся ежедневно длительностью несколько минут, а также по завершению каждой итерации с анализом результатов работ и ретроспективой. Для эффективных коммуникаций при проведении собраний участники команд должны придерживаться следующих ключевых правил поведения:
-уважение мнения каждого участника команды;
-правдивость при любом общении;
-прозрачность всех данных, действий и решений;
-уверенность, что каждый участник поддержит команду;
-приверженность команде и ее целям.
Для создания высокопроизводительных команд в гибких методологиях кроме эффективной команды и хороших коммуникаций необходим также совершенный программный инструментарий.
2.Работающее программное обеспечение важнее всеобъемлющей до-
кументации. Все гибкие методологии выделяют необходимость доставки заказчику небольших фрагментов работающего ПО через заданные временные интервалы. Программное обеспечение, как правило, должно пройти уровень модульного тестирования, тестирования на уровне системы (взаимодействие
сБД, пользовательский интерфейс и т.п.). Объем документации при этом должен быть минимальным. В процессе проектирования команда должна поддерживать в актуальном состоянии короткий документ, содержащий обоснования решения и описание структуры.
3.Сотрудничество с заказчиком важнее формальных договоренно-
стей по контракту. Для успешного завершения проекта необходимо регулярное и частое общение с заказчиком ИС. Заказчик должен регулярно участвовать в обсуждении принимаемых решений по проекту, высказывать свои отзывы, пожелания и замечания. Вовлечение заказчика в процесс разработки ИС необходимо для создания качественного продукта.
4.Оперативное реагирование на изменения важнее следования пла-
ну. Способность адекватного реагирования на изменения во многом определяет успех проекта. В процессе создания ИС очень часто изменяются требования заказчика. Заказчики очень часто точно не знают, чего хотят, до тех пор, пока не увидят работающий продукт. Гибкие методологии ищут обратную связь от заказчиков в процессе создания ИС. Оперативное реагирование на изменения необходимо для создания продукта, который удовлетворит заказчика и обеспечит высокую ценность для бизнеса.
87
2.4.2 Принципы гибкой разработки
Постулаты гибкой разработки поддерживаются двенадцатью принципами [31]. В конкретных методологиях гибкой разработки определены процессы
иправила, в большей или меньшей степени соответствующие этим принципам:
1.Высшим приоритетом считать удовлетворение пожеланий заказчика посредством поставки полезного ПО в сжатые сроки с последующим непрерывным обновлением. Гибкие методологии подразумевают быструю поставку начальной версии ИС и частые обновления. Целью команды является поставка первой работоспособной версии в течение нескольких недель с момента начала проекта. В дальнейшем ИС с постепенно расширяющейся функциональностью должны поставляться каждые несколько недель. Заказчик может начать промышленную эксплуатацию системы, если сочтет ее достаточно функциональной. Также заказчик может просто ознакомиться с текущей версией ИС и предоставить свой отзыв с замечаниями.
2.Не игнорировать изменение требований, даже на поздних этапах разработки. Гибкие процессы предполагают учет изменений для обеспечения конкурентных преимуществ заказчика. Команды, использующие гибкие методологии, стремятся сделать структуру программы качественной и универсальной, с минимальным влиянием изменений на систему в целом.
3.Поставлять новые работающие версии ИС часто, с интервалом от одной недели до двух месяцев, отдавая предпочтение меньшим срокам. При этом ставится цель поставить систему, удовлетворяющую потребностям пользователя, с минимумом сопроводительной документации.
4.Заказчики и разработчики должны работать совместно на протяжении всего проекта. Считается, что для успешного проекта заказчики, разработчики
ивсе заинтересованные лица должны общаться часто и помногу для целенаправленного совершенствования продукта.
5.Проекты должны воплощать в жизнь целеустремленные люди. Создание нормальных и благоприятных условий работы для команды, обеспечение необходимой поддержки.
6.Самый эффективный и продуктивный метод передачи информации команде разработчиков и обмена мнениями внутри нее – разговор лицом к лицу. В гибких проектах основной способ коммуникации – простое человеческое общение. Письменные документы создаются и обновляются постепенно по мере разработки ИС и только в случае необходимости.
7.Работающая система – основной показатель прогресса в проекте. О приближении гибкого проекта к завершению судят по тому, насколько имеющаяся в данный момент версия ИС отвечает требованиям заказчика.
88
8.Гибкие процессы способствуют долгосрочной разработке. Заказчики, разработчики и пользователи должны быть в состоянии поддерживать неизменный темп сколь угодно долго.
9.Непрестанное внимание к качественному проектированию и техническому совершенству повышает отдачу от гибких технологий. Члены гибкой команды стремятся создавать качественный код, регулярно выполняя рефакто-
ринг.
10.Простота – искусство достигать большего, делая меньше. Члены команды решают текущие задачи максимально просто и качественно. Если в будущем возникнет какая-либо проблема, то в качественный код имеется возможность внести изменения без существенных трудозатрат.
11.Самые лучшие архитектуры, требования и проекты производят самоорганизующиеся команды. В гибких командах задачи поручаются не отдельным членам, а команде в целом. Команда сама решает, как лучше всего реализовать требования заказчика. Члены команды совместно работают над всеми аспектами проекта. Каждому участнику разрешается вносить свой вклад в общее дело. Нет такого члена команды, который бы единолично отвечал за архитектуру, требования или тесты.
12.Команда должна регулярно задумываться над тем, как стать ещё более эффективной, а затем соответственно корректировать и подстраивать свое поведение и работу. Гибкая команда постоянно корректирует свои правила, соглашения, организацию и взаимоотношения.
2.4.3 Методологии гибкой разработки
Вышеприведенным принципам в определенной степени соответствует ряд методологий гибкой разработки:
1.Agile Modeling – набор понятий, принципов и приёмов (практик), позволяющих быстро и просто выполнять моделирование и документирование в проектах разработки программного обеспечения.
2.Agile Unified Process (AUP) – упрощенная версия IBM Rational Unified Process (RUP), которая описывает простое и понятное приближение (модель) для создания программного обеспечения для бизнес-приложений.
3.Open UP – это итеративно-инкрементальный метод разработки программного обеспечения. Позиционируется как лёгкий и гибкий вариант
RUP.
4.Agile Data Method – группа итеративных методов разработки программного обеспечения, в которых требования и решения достигаются в рамках сотрудничества разных кросс-функциональных команд.
89
5.DSDM – методика разработки динамических систем, основанная на концепции быстрой разработки приложений (Rapid Application Development, RAD). Представляет собой итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя.
6.Extreme Programming (известное сокращенное название – XP). Одна из наиболее известных гибких методологий разработки программного обеспечения. Модель процесса разработки при этом выглядит как частая последовательность выпусков (releases) продукта, настолько частых, насколько это возможно. При этом требуется, чтобы в новый выпуск входила новая функциональность [55].
7.Adaptive software development (ASD) – адаптивная разработка программ.
8.Feature Driven Development (FDD) – разработка, ориентированная на по-
степенное добавление функциональности [56].
9.Getting Real – итеративный подход без функциональных спецификаций, использующийся для веб-приложений.
10.Microsoft Solutions Framework (MSF) fog Agile Software Development –
гибкая методология разработки ПО, которая представляет собой обоб-
щение лучших проектных практик, когда-либо использованных командами разработчиков компании Microsoft [13], является составной частью продукта VSTS в ключе таких шаблонов конкретных процессов, как
CMMI, Agile и Scrum.
11.Scrum – подход к разработке новых сервисов и продуктов (не обязательно программных), основу которого составляет сплоченная работа небольшой универсальной команды, которая разрабатывает проект на всех фазах ЖЦ ИС [29]. Позволяет гибко разрабатывать проекты небольшими командами (7 человек плюс/минус 2) в условиях изменяющихся требований. Процесс разработки итеративен и предоставляет большую свободу команде. Кроме того, метод очень прост – легко изучается и применяется на практике [6].
Следует отметить, что в чистом виде гибкие методологии разработки ИС редко используются на практике командами разработчиков. Как правило, успешные команды применяют полезные приемы и свойства нескольких процессов, подстраивая их под конкретное представление команды о гибкости процес-
са разработки конкретных ИС.
2.5Задания для самостоятельного выполнения
1.Приведите пример правил обработки информации при описании бизнес-
90