Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Разработка информационных систем. Учебное пособие

.pdf

Скачиваний:

Добавлен:

07.09.2026

Размер:

1 Мб

Скачать

☆

<<< < Предыдущая 1 2 3 4 56 / 106 7 8 9 10 > Следующая >>>

4.1. Организация разработки ПО ИС

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

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

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

 алгоритмисты, обеспечивающие разработку или выбор математиче- ского обеспечения и концептуальную целостность системы;

 программисты, обеспечивающие разработку и отладку программ;

 тестировщики, обеспечивающие генерацию тестов и проверку систе-

мы;

 технологи, обеспечивающие эффективную работу инструментального программного обеспечения;

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

 документологи, обеспечивающие документирование системы, редак- тирование, формирование и выпуск программной документации;

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

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

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

 широкое применение аналитического подхода;

 эволюционное преобразование системы;

 формирование документации параллельно с процессом разработки.

Аналитический подход заключается в применении к исходной задаче

4. Технологии разработки ИС

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

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

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

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

1) получается иерархическая структура ПО, которая включает на верх-

нем уровне управляющую систему (монитор), на среднем уровне состоит из отдельных подсистем, а на низшем уровне – из отдельных модулей;

2) получается логическая структура базы данных, что позволяет ре-

шить вопрос о включении в состав ИС типовой СУБД или её разработку.

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

4.2. RAD-технология

внести соответствующие коррективы, а также обеспечить работоспособность наиболее ответственной части ПО.

Процесс отладки программы в общем времени её разработки занимает

около 50–90 % времени, на что влияет сложность алгоритма, используемый язык программирования, инструментальная система с имеющимися средствами отладки и другие факторы. Процесс отладки программ завершается формированием эксплуатационной документации и документации сопровождения, которые оформляются в соответствии со стандартами, отражёнными в составе Единой системы программной документации.

В процессе испытаний, прежде всего, проверяют основную версию ПО,

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

4.2. RAD-технология

Появление технологии RAD (быстрая разработка приложений) связана

с именами Б. Бема, С. Шульца и Дж. Мартина. В основе технологии RAD лежит спиральная модель ЖЦ. Основные моменты, связанные с RADтехнологией, сводятся к следующему:

 сокращается время создания ИС за счёт интенсивного участия в про-

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

 основная трудоёмкость работ переходит от стадии «Исследование и

обоснование создания ИС» к стадиям разработки, причём возможности заказчика ИС по контролю и влиянию на процесс разработки ИС существенно расширяются.

4.2.1. Особенности применения RAD-технологии

RAD-технологию эффективно применять в следующих случаях:

1. Заказчик неоднозначно и не в полном объёме владеет информацией о

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

2. Заказчик в качестве важнейшего требования определяет требования к

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

4. Технологии разработки ИС

3. Накладываются жёсткие требования на сроки реализации проекта,

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

4. Финансовые ресурсы проекта ограничены, в связи с чем его реализа-

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

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

 широкое применение прототипирования и участия пользователей в

процессе создания ИС;

 в связи с использованием спиральной модели ЖЦ, можно выполнять

следующий этап разработки без окончания работ на предыдущем этапе ЖЦ, что позволяет применять неоднократный возврат на ранние этапы ЖЦ;

 эффективность использования для распараллеливания работ;  возможность широкого использования CASE-средств.

Ранее указывалось, что в RAD-технологии применяется спиральная модель ЖЦ ИС, в которой многократно повторяются стадии: «Анализ требований и планирование», «Проектирование», «Реализация» и «Внедрение».

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

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

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

Выше отмечалось, что наибольший эффект RAD-технология даёт при разработке систем средней сложности, для которых, обычно, создаётся несколько прототипов с пользовательскими интерфейсами, но с различным

4.2. RAD-технология

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

Необходимо отметить, что при разработке систем с чёткими и практи-

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

4.2.2. Прототипирование

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

С помощью прототипов можно решить следующие основные задачи.

1. Формирование полных и корректных требований к системе. Для ре-

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

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

2. Проанализировать варианты альтернативных решений. С помощью

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

Известны следующие основные разновидности прототипов:

1. Горизонтальные или поведенческие.

2. Вертикальные или структурные.

3. Одноразовые или исследовательские.

4. Эволюционные.

4. Технологии разработки ИС

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

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

 существует неуверенность в эффективности применяемого подхода к архитектуре системы;

 необходимо выполнить оптимизацию алгоритмов;

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

 необходимо провести проверку важных временных требований.

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

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

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

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

4.3. Методология MSF 4.0 for Agile Software Development

Для повышения эффективности проектов, реализуемых по своим технологиям, компания Microsoft разработала пакет MSF (Microsoft Solutions Framework). Ниже рассматривается версия пакета MSF 4.0. Эта версия имеет инструментальную поддержку – Microsoft Visual Studio 2005 Team System, которая фактически является интегрирующей средой, предоставляющей использование инструментов, обеспечивающих все стадии процесса создания IT-продукта.

Рассмотрим подробнее направление MSF for Agile Software Develop- ment версии MSF 4.0 [3].

4.3.1. Модель процессов MSF

Модель процессов обладает свойствами как каскадной, так и спиральной модели ЖЦ. MSF-модель находит применение при реализации многих IT-проектов на всех этапах ЖЦ.

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

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

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

Модель MSF-процесса отражает полный ЖЦ проекта.

4. Технологии разработки ИС

4.3.2. MSF-модель проектной группы

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

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

 тесное сотрудничество коллег внутри группы;

 требования заказчика – прежде всего;

 заинтересованность в качественном, конечном результате;

 самосовершенствование – фактор эффективной работы.

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

Таблица. 4.1

Основные задачи ролевых кластеров

Ролевой

кластер

Основные задачи

Бизнес-

аналитик

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

4.3. Методология MSF 4.0 for Agile Software Development

Окончание табл. 4.1

Ролевой

кластер

Основные задачи

Менеджер

проекта

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

Архитектор

проекта

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

ру;

 упрощает разработку за счёт декомпозиции системы на понятные

и простые части

Разработчик

проекта

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

Тестировщик

проекта

 выявляет проблемы в продукте, снижающие его качество;  обнаруженные проблемы описывает вредными последствиями с

предложением вариантов их устранения

Архитектор проекта, решая свои задачи, фактически закладывает

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

В MSF-модели проектной группы предусматривается выполнение от-

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

4. Технологии разработки ИС

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

 роль разработчиков не объединяется с другой ролью;  избегание возможных конфликтов интересов.

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

 ролевые лидеры отвечают за управление проектом, а члены проект- ной группы отвечают за успех проекта;

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

Рассматриваемая модель MSF-группы рекомендует делить большие группы, работающие параллельно, на более мелкие группы,

Проект ИС – комплект документов, регламентирующих и раскрывающих проектные решения по разработке и эксплуатации ИС. Проект ИС описывает её архитектуру, технические и программные средства с их характеристиками, структуры данных и другие проектные решения.

Проект практически всегда ограничен по времени и представляет собой процесс создания продукта или услуги. Методология MSF предусматривает три дисциплины управления – проектами, рисками и подготовкой, которые направлены на повышение эффективности процесса:

4.3.3. Управление проектами

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

<<< < Предыдущая 1 2 3 4 56 / 106 7 8 9 10 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]