Методология и технология разработки информационных систем

Курсовая работа Методология и технология разработки информационных систем

• Введение 3
• Глава 1. Основные понятия 5
• 1.1 Информационные системы 5
• 1.2 Методологии разработки информационных систем 8
• Глава 2. Методология разработки информационных систем 10
• 2.1 Методологии разработки информационных систем в отечественной литературе 10
• 2.2 Методологии разработки информационных систем в зарубежной литературе 8
• Глава 3. Технология разработки информационных систем 19
• Глава 4. Государственные и международные стандарты в области разработки программного обеспечения 4
• 4.1 Международный стандарт ISO/IEC 12 207: 1995;08−01 4
• 4.2 Стандарты комплекса ГОСТ 34 6
• 4.3 Стандарты комплекса ГОСТ 19 10
• Практическая часть 12
• Заключение 18
• Список используемых источников 19

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

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

Цель данной курсовой работы — изучить теоретический материал по тематике курсовой работы и разработать фрагмент информационной системы «Учебно-методический ресурс» .

Для достижения этой цели были поставлены следующие задачи:

проанализировать источники литературы по теме курсовой работы;

раскрыть следующие понятия: «Информационная система», «Методология разработки информационных систем», «Технология разработки информационных систем» ;

классифицировать методологии разработки программного обеспечения по отечественным и зарубежным источникам;

рассмотреть и изучить государственные и международные стандарты в области разработки программного обеспечения;

разработать фрагмент информационной системы «Учебно-методический ресурс» .

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

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

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

В третьей главе изучается понятие «Технология разработки информационных систем» и классифицируются технологии разработки программного обеспечения по отечественным источникам.

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

В практической части рассмотрен процесс создания фрагмента информационной системы «Учебно-методический ресурс» .

Глава 1. Основные понятия

1.1 Информационные системы

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

Сам термин «информационные системы» включает два важных понятия — «информация» и «система» .

Информация (лат. information — сообщение, разъяснение; лат. informo — придаю вид, формирую, организую) — сведения о лицах, предметах, фактах, событиях, явлениях и процессах независимо от формы их представления.

Система (греч. system — целое, составленное из частей соединение) — это совокупность элементов, образующих определенную целостность, единство и взаимодействующих друг с другом для достижения определенной цели. [10, c.16]

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

Рис. 1. Структура ИС

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

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

В Федеральном законе «Об информации, информатизации и защите информации» дается следующее определение:

" Информационная система — организационно упорядоченная совокупность документов (массивов документов) и информационных технологий, в том числе и с использованием средств вычислительной техники и связи, реализующих информационные процессы". [1]

Информационная система в программировании — это прикладная программная подсистема, ориентированная на сбор, хранение, поиск и обработку текстовой и/или фактографической информации, работающая в режиме диалога с пользователем. [9, c.15]

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

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

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

1.2 Методологии разработки информационных систем

Любая теоретическая или практическая сфера деятельности использует присущие только ей способы решения поставленных задач. Эти способы называются методами. Метод — это способ достижения какой-либо цели, решения конкретной задачи; совокупность приемов или операций практического или теоретического освоения действительности. [6, c.450]

Методология — совокупность методов, применяемых в какой-либо области человеческой деятельности. [4, c.217]

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

Методология науки дает характеристику компонентов научного исследования — его объекта, предмета анализа, задачи исследования, совокупности исследовательских средств, необходимых для решения задачи данного типа, а также формирует представление о последовательности движения исследователя в процессе решения задачи. [11, c.56]

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

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

обеспечение создания информационных систем, отвечающих целям и задачам предприятия и соответствующих предъявляемым к ним требованиям;

гарантия создания системы с заданными параметрами в течение заданного времени в рамках оговоренного заранее бюджета;

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

обеспечение создания информационных систем, отвечающих требованиям открытости, переносимости и масштабируемости;

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

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

Глава 2. Методология разработки информационных систем

2.1 Методологии разработки информационных систем в отечественной литературе

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

Методологии создания информационных систем можно классифицировать по нескольким отличительным признакам. (Рис.2)

Классификация по ядрам методологий

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

Ядра методологий определяются способом описания алгоритмов. К основным ядрам методологий относят:

методология императивного программирования;

методология объектно-ориентированного программирования;

методология функционального программирования;

методология логического программирования;

методология программирования в ограничениях.

Рассмотрим ядра методологий подробнее.

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

Методы и концепции.

Метод изменения состояний заключается в последовательном изменении состояний. Метод поддерживается концепцией алгоритма

Метод управления потоком исполнения заключается в пошаговом контроле управления. Метод поддерживается концепцией потока исполнения.

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

Методы и концепции.

Метод объектно-ориентированной декомпозиции заключается в выделении объектов и связей между ними. Метод поддерживается концепциями инкапсуляции, наследования и полиморфизма.

Метод абстрактных типов данных лежит в основе инкапсуляции. Метод поддерживается концепцией абстрагирования.

Метод пересылки сообщений заключается в описании поведения системы в терминах обмена сообщениями между объектами. Метод поддерживается концепцией сообщения.

Методология функционального программирования — способ составления программ, в которых единственным действием является вызов функции, единственным способом расчленения программы на части — введение имени для функции и задание для этого имени выражения, вычисляющего значения функции, а единственным правилом композиции — оператор суперпозиции функции. Функциональная методология является одной из старейших. По происхождению она тесно связана с лямбда-исчислением, изобретенным еще в начале 30-х годов XX века логиком Алонзо Черчен. Эта методология используется теоретиками программирования и является средством лабораторных исследований искусственного интеллекта. [7, c.80]

Методы и концепции.

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

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

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

Методология логического программирования — подход, согласно которому программа содержит описание проблемы в терминах фактов и логических формул, а решение проблемы система выполняет с помощью механизмов логического вывода. Логическое программирование начинает свой отсчет времени с конца 60-х годов XX века, когда Корделл Грин предложил использовать резолюцию как основу логического программирования. Алан Колмеро создал язык логического программирования Prolog в 1971 году. Логическое программирование пережило пик популярности в середине 80-х годов XX века, когда оно было положено в основу проекта разработки программного и аппаратного обеспечения вычислительных систем пятого поколения.

Методы и концепции.

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

Метод унификации — это механизм сопоставления с образцом для создания и декомпозиции структур данных.

Методология программирования в ограничениях — это подход, при котором в программе определяется тип данных решения, предметная область решение и ограничения на значение искомого решения. Решение находится системой. Методология предлагает двухуровневую архитектуру, интегрирующую компонент ограничения и программный компонент. Компонент ограничений обеспечивает основные операции и состоит из системы выводов на фундаментальных свойствах системы ограничений. Операции, окружающие компонент ограничений, реализуются программно-языковым компонентом. Методология возникла в начале 80-х годов XX века как перспективная область исследований на стыке символьных вычислений, искусственного интеллекта, исследования операций и интервальной арифметики.

Методы и концепции.

Метод описательной модели вычислений заключается в том, что программа на языке программирования содержит описание понятий и задач. Метод поддерживается концепцией модели.

Классификация по топологической специфике методологий

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

Методология структурного императивного программирования — подход, заключающийся в задании хорошей топологии императивных программ, ориентированной на сокращение количества общих затрат на разработку программного обеспечения. Сокращение будет иметь место и в результате того, что и проектные модели, и программный код будут иметь хорошую структурированность, позволяющую избежать многих ошибок. В случае данной методологии хорошую топологию задают отказ от использования глобальных данных и, в большинстве случаев, оператора безусловного перехода, разработка модулей с сильной связностью и обеспечение их независимости от других модулей. Подход базируется на двух основные принципах построения: последовательная декомпозиция алгоритма решения задачи сверху вниз; использование структурного кодирования. Данная методология является важнейшим развитием императивной методологии. Создателем структурного подхода считается Эдсгер Дейкстра. Ему также принадлежит попытка соединить структурное программирование с методами доказательства программ.

Методы и концепции.

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

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

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

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

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

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

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

Смешанные методологии.

Смешанные методологии включают объединение методов нескольких методологий. Наиболее часто объединяются методологии функционального и логического программирования. Существуют исследовательские работы в области объединения объектно-ориентированного и логического программирования. Ряд исследований посвящен вопросам унификации методологий программирования.

Петров В.Н. в своей книге «Технологии разработки программного обеспечения» приводит еще одну методологию — RAD (Rapid Application Development).

Методология быстрой разработки приложений RAD.

На начальном этапе существования компьютерных информационных систем их разработка велась на традиционных языках программирования. Однако по мере возрастания сложности разрабатываемых систем и увеличения запросов пользователей потребовались новые средства, обеспечивающие значительное сокращение сроков разработки. Это послужило предпосылкой к созданию целого направления в области программного обеспечения — инструментальных средств для быстрой разработки приложений. Развитие этого направления привело к появлению на рынке программного обеспечения средств автоматизации практически всех этапов жизненного цикла информационных систем. Эти средства приобрели название методологии быстрой разработки приложений RAD (Rapid Application Development).

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

Под методологией быстрой разработки приложений обычно понимается разработки информационных систем, основанный на трех основных элементах:

небольшой команде программистов (обычно от 2 до 10 человек);

тщательно проработанный производственный график работ, рассчитанных сравнительно короткий срок разработки (от 2 до 6 мес);

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

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

используется итерационная (спиральная) модель разработки;

полное завершение работ на каждом из этапов жизненного цикла не обязательно;

в процессе разработки информационной системы необходимо тесное действие с заказчиком и будущими пользователями;

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

тестирование и развитие проекта осуществляются одновременно с разработкой;

разработка ведется немногочисленной и хорошо управляемой командой профессионалов;

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

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

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

2.2 Методологии разработки информационных систем в зарубежной литературе

Формально методологии можно разделить на два типа — классические (монументальные, предсказуемые, где все этапы детально проектируется заранее и не допускается отклонение от первоначального плана) и их противоположность — адаптивные (гибкие, где в процессе работы допустимо и даже типично перепроектирование). В зависимости от начальных условий и характера поставленной задачи, может применяться как классическая, так и адаптивная методология (Рис.4).

Классическая (монументальная) методология применяется, если:

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

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

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

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

Адаптивная (agile — гибкая или lightweight — легкая) методология применяется, если:

Не ясны или изменяются требования к системе.

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

Необходимо как можно быстрее получить первые версии работающей программы.

Решаемая программой задача трудно поддается документированию.

На реализацию всех требований есть достаточный запас времени.

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

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

Используется система контроля версий.

Оформление кода стандартизировано.

Первоочередное исправления ошибок перед внесением любых других изменений.

Выполняется регулярное резервное копирование всех проектных данных.

Используются инструментальные средства автоматизации документирования исходного кода и ведения списков ошибок.

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

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

Потребность в альтернативе классическим (монументальным) методологиям, которые в основном основаны на документации, привела к тому, что в 2001 году был проведен семинар, куда были приглашены представители различных адаптивных (гибких) методологий. Результатом работы стал манифест гибкой разработки ПО (Manifest for Agile Software Development) (см. Приложение 1).

Более подробно остановимся на адаптивных (гибких) методологиях, так как они наиболее активно развиваются и используются в настоящее время.

Методология SCRUM.

Данная методология предназначена для небольших команд разработчиков. Проект начинается с создания «резерва свойств системы» (backlog). Резерв свойств — это набор функций системы, которые необходимо реализовать. Сами функции могут быть описаны с помощью пользовательских сценариев или более традиционных требований. Контроль над резервом имеет только один человек, обычно это заказчик системы. Резерв постоянно изменяется, функции дополняются и сортируются по приоритетам.

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

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

Отличительной чертой SCRUM является проведение ежедневных 15−30 минутных совещаний, которые так и называются scrum (потасовка). В ходе этих совещаний лидер команды задает каждому следующие вопросы:

Что удалось сделать из выбранных для данной итерации функций за прошедший день?

Были ли какие-либо проблемы с реализацией?

Что планируется сделать за сегодняшний день?

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

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

Экстремальное программирование (eXtreme Programming или XP)

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

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

Семейство методологий Crystal.

Crystal — это не просто методология, это целое семейство методологий, разработанное Алистером Коберном.

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

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

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

Степень важности нарастает по вертикальной оси. Величина команды нарастает по горизонтальной оси. В результате получается семейство методологий. Чем ниже критичность и чем меньше команда, тем более «легкую» методологию нужно использовать. Самой легкой из всего семейства является методология Crystal Clear. Главные принципы данной методологии:

Вся команда разработчиков (до 6 человек) находится в одном помещении. Это позволяет сократить временные затраты на коммуникацию.

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

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

Средства контроля версий кода обеспечивают коллективное владение кодом.

Семейство методологий Crystal построено на итеративной разработке. Продолжительность итерации может изменяться в предела от 1 до 4 месяцев. Чем меньше итерация, тем лучше.

Важной особенностью Crystal является непрерывная настройка методологии. Это позволяет постепенно адаптировать ее для конкретной команды и конкретного проекта. Пожалуй, ни в одной другой методологии настройке не уделяется такого внимания.

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

Открытый исходный код (Open Source).

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

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

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

Адаптивная методология (Adaptive Software Development или ASD).

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

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

В ASD обычный статический жизненный цикл «Планирование — Проектирование — Конструирование» заменен на динамический «Обдумывание — Взаимодействие — Обучение» .

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

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

Функционально-ориентированная разработка (Feature Driven Development или FDD).

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

FDD включает пять процессов, последние два из которых повторяются для каждой функции:

разработка общей модели;

составление списка необходимых функций системы;

планирование работы над каждой функцией;

проектирование функции;

конструирование функции.

Разработчики в FDD делятся на «хозяев классов» и «главных программистов». Главные программисты привлекают хозяев задействованных классов к работе над очередным свойством. Для сравнения, в ХР нет персонально ответственных за классы или методы. К работе над любым классом может привлекаться любой из участников разработки.

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

Метод разработки динамических систем (Dynamic System Development Method или DSDM).

DSDM — методология, созданная Дженнифером Стаплетоном, позволяющая разрабатывать проект в короткие сроки с использованием ограниченного количества ресурсов, предусмотренного бюджетом. DSDM стремиться сократить связующие звенья между заказчиком и разработчиком, аналитиком и дизайнером, между членима команды и между разными уровнями управления, чтобы обеспечить более эффективные процесс разработки программного обеспечения. Фиксируя время разработки (обычно 6 месяцев) и устанавливая ограничения на используемые ресурсы, намного проще создать процесс разработки, отвечающий требованиям заказчиков.

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

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

DSDM неприменима если:

проект не сводится к итеративному приложению, где функциональность становится очевидна заказчику через пользовательский интерфейс;

не определена группа пользователей;

проект зависит от сложных внутренних вычислений.

Основные принципы DSDM:

Активное вмешательство пользователя (в идеале, пользователи и разработчики разделяют рабочее пространство, поэтому решения могут приниматься на месте).

Команда должна иметь возможность принимать решения без ожидания подтверждения вышестоящими уровнями (команда состоит как из разработчиков, так и из заказчиков).

Требования заказчика — прежде всего.

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

Разработка итеративная, управляемая пользовательским откликом. Итерации свойственны всей разработке ПО (разработчики постоянно улучшают систему посредством итераций, что дает им возможность извлекать пользу от вовлечения пользователей).

Все изменения обратимы (возвращение — основная черта DSDM).

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

Глава 3. Технология разработки информационных систем

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

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

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

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

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

технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3−7 человек);

обеспечивать минимальное время получения работоспособной системы;

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

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

Технологии характеризуются в двух измерениях: вертикальном (представляющем процессы) и горизонтальном (представляющем стадии).

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

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

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

Существуют несколько технологических подходов.

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

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

Каскадные технологические подходы.

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

Каскадно-возвратный подход — разрешены возвраты к предыдущим стадиям и пересмотр или уточнение ранее принятых решений;

Каскадно-итерационный подход — предусматривает последовательные итерации каждого процесса до тех пор, пока не будет достигнут желаемый результат;

Каскадный подход с перекрывающимися процессами предполагает наличие специализированных команд, позволяющих сократить передаваемую документацию. Следующий процесс начинается до завершения текущего. Несколько процессов могут выполняться параллельно;

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

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

Каркасные подходы.

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

Модель процессов Microsoft Solution Framework (MSF) представляет собой технологический подход, базирующийся на наборе моделей, правил и спецификаций, применяемых при создании и распространении программных продуктов, а также обеспечивающих более эффективное использование технологий для решений проблем бизнеса. Он позволяет количественно выражать степень завершенности работы над проектом и адаптировать методы управления им в соответствии с изменяющимися потребностями.

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

Генетические подходы.

Синтезирующее программирование предполагает синтез программы по ее спецификации. Документ на языке спецификаций является базисом для последующей реализации;

Сборочное (расширяемое) программирование предполагает, что программа собирается путем переиспользования уже известных фрагментов;

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

Подходы на основе формальных преобразований.

Технология стерильного цеха складывается из следующих частей:

разработка функциональных и пользовательских спецификаций;

планирование разработки;

формальная верификация;

статическое тестирование.

Формальные генетические подходы

Формальное синтезирующее программирование использует математическую спецификацию — совокупность логических формул;

Формальное сборочное программирование использует спецификацию как композицию уже известных фрагментов;

Формальное конкретизирующее программирование использует смешанные вычисления и конкретизацию по аннотациям.

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

Ранние технологические подходы быстрой разработки.

Эволюционное прототипирование — первый прототип включает создание развитого пользовательского интерфейса.

Итеративная разработка — первый прототип уже должен включать завершенное ядро системы.

Постадийная разработка — должна решить недостаток первых двух подходов — невозможность определения сроков завершения проектов.

Адаптивные подходы.

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

Адаптивная разработка. В основе лежат три стадии — обдумывание, сотрудничество и обучение. Результаты планирования в данном подходе всегда не предсказуемы. В отличие от обычного планирования, отклонения в котором ведут к ошибкам, здесь отклонения ведут к правильным решениям. Обязательства и планы программистов и заказчиков пересматриваются в течение всего процесса разработки.