55
К настоящему времени наибольшее распространение получили
следующие основные модели жизненного цикла:
1. Задачная модель;
2. Каскадная модель (или системная);
3. Спиральная модель (настоящее время).
Задачная модель. Разработка системы "снизу-вверх" от отдельных задач
ко всей системе (задачная модель) единый поход к разработке неизбежно
теряется, возникают проблемы при информационной стыковке отдельных
компонентов. По мере увеличения количества задач трудности нарастают,
приходится постоянно изменять уже существующие программы и структуры
данных. Скорость развития такой системы замедляется, что тормозит и развитие
самой организации. Однако в отдельных случаях такая технология может
оказаться целесообразной:
Крайняя срочность. Необходимо чтобы хоть как-то задачи решались
иначе потом придется все сделать заново.
Эксперимент и адаптация заказчика. Алгоритмы не понятны,
решения определяются методом проб и ошибок.
На основании вышеизложенного можно сделать общий вывод, что
достаточно большую эффективность информационной системы таким способом
создать невозможно.
Каскадная модель. В небольших по объему однородных
информационных системах каждое приложение представляло собой единое
целое. Для разработки такого типа приложений применялся каскадный способ,
основной характеристикой которого является разбиение всей разработки на
этапы, причем переход от одного этапа на следующий происходит только после
того, как будет полностью завершена работа на текущем этапе. Каждый этап
завершается выпуском полного комплекта документации, достаточной для того,
чтобы разработка могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в
следующем:
на каждом этапе формируется законченный набор проектной
документации, отвечающий критериям полноты и согласованности;
56
выполняемые в логичной последовательности этапы работ
позволяют планировать сроки завершения всех работ и соответствующие
затраты.
Рис. 2.1 Каскадная схема разработки
Каскадный подход хорошо зарекомендовал себя при построении
информационных систем, для которых в самом начале разработки можно
достаточно точно и полно сформулировать все требования, с тем, чтобы
предоставить разработчикам свободу реализовать их как можно лучше с
технической точки зрения. В эту категорию попадают сложные расчетные
системы, системы реального времени и другие подобные задачи. Однако в
процессе использования этого подхода обнаружился ряд его
недостатков, вызванных прежде всего тем, что реальный процесс создания
систем никогда полностью не укладывался в такую жесткую схему. В процессе
создания постоянно возникала потребность в возврате к предыдущим этапам и
уточнении или пересмотре ранее принятых решений. В результате реальный
процесс создания программного обеспечения принимал следующий вид:
Рис. 2.2 Реальный процесс разработки ПО по каскадной схеме
57
Основным недостатком каскадного подхода является существенное
запаздывание с получением результатов. Согласование результатов с
пользователями производится только в точках, планируемых после завершения
каждого этапа работ, требования к информационным системам "заморожены" в
виде технического задания на все время ее создания. Таким образом,
пользователи могут внести свои замечания только после того, как работа над
системой будет полностью завершена. В случае неточного изложения
требований или их изменения в течение длительного периода создания
программного обеспечения, пользователи получают систему, не
удовлетворяющую их потребностям. Модели (как функциональные, так и
информационные) автоматизируемого объекта могут устареть одновременно с
их утверждением. Сущность системного подхода к разработке ИС заключается в
ее декомпозиции (разбиении) на автоматизируемые функции: система
разбивается на функциональные подсистемы, которые в свою очередь делятся на
подфункции, подразделяемые на задачи и так далее. Процесс разбиения
продолжается вплоть до конкретных процедур. При этом автоматизируемая
система сохраняет целостное представление, в котором все составляющие
компоненты взаимоувязаны. Таким образом, данная модель основным
достоинством имеет системность разработки, а основные недостатки - медленно
и дорого.
Спиральная модель: Для преодоления перечисленных проблем была
предложена спиральная модель жизненного цикла (рис. 3), делающая упор на
начальные этапы жизненного цикла: анализ и проектирование. На этих этапах
реализуемость технических решений проверяется путем создания прототипов.
Каждый виток спирали соответствует созданию фрагмента или версии
программного обеспечения, на нем уточняются цели и характеристики
проекта, определяется его качество и планируются работы следующего витка
спирали. Таким образом, углубляются и последовательно конкретизируются
детали проекта и в результате выбирается обоснованный вариант, который
доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл
создания системы. Неполное завершение работ на каждом этапе позволяет
58
переходить на следующий этап, не дожидаясь полного завершения
работы на текущем. При итеративном способе разработки недостающую работу
можно будет выполнить на следующей итерации. Главная же задача - как можно
быстрее показать пользователям системы работоспособный продукт, тем самым,
активизируя процесс уточнения и дополнения требований [21, стр. 49] .
Основная проблема спирального цикла - определение момента перехода
на следующий этап. Для ее решения необходимо ввести временные ограничения
на каждый из этапов жизненного цикла. Переход осуществляется в соответствии
с планом, даже если не вся запланированная работа закончена. План
составляется на основе статистических данных, полученных в предыдущих
проектах, и личного опыта разработчиков. На рисунке 2.3 представлено
графическое изображение спиральной модели жизненного цикла ИС.
Рис. 2.3 Спиральная модель ЖЦ ИС
Наиболее оптимальным вариантом является спиральная модель, так как в
ней были учтены все недостатки каскадной и задачной модели. В рамках
доработки уже существующей ИС частенько возникают новые замечания от
пользователей которые можно реализовать на новом витке спиральное модели.
Для реализации модуля, автоматизирующего работу по учету труда и
заработной платы на частном предприятии «Оптимал» выбрана стратегия
жизненного цикла программного обеспечения – каскадная модель. В каскадной
модели планирование тестирования и испытаний производится на ранних
стадиях разработки программного средства, упрощена оценка промежуточных
59
результатов разработки, облегчен процесс управления и контроля за ходом
разработки.
В соответствии с СТБ ИСО/МЭК 12207–2003 все модели жизненного
цикла программного обеспечения содержат процессы: основные,
вспомогательные, организационные.
К основным процессам жизненного цикла программного обеспечения
относятся:
анализ;
проектирование;
реализация;
внедрение;
сопровождение.
Цель этапа «Анализ» - формирование технического задания. Этап
разбивается на подэтапы, задачи которых: определений требований к ИС,
определение функций ИС и стратегий автоматизации, обоснование проектных
решений по техническому, информационному и программному обеспечению.
Результативная информация - это документация по техническому заданию.
Информация для анализа берется из интернета и отдела планирования.
Цель этапа «Проектирование» - разработка проекта автоматизации и
разработка информационного обеспечения задачи. Разработка проекта
автоматизации включает в себя разработку плана-графика, архитектуры проекта,
анализ рисков, а также оценку стоимости проекта. Разработка информационного
обеспечения задачи включает в себя разработку информационного модели,
классификаторов и прототипов экранных форм. Результативная информация -
это проектная документация.
Цель этапа «Реализация» - разработка программного обеспечения ИС.
Этап включает в себя подготовку к разработке ПО и разработку ПО.
Результативная информация - это документация по ПО.
Цель этапа «Внедрение» включает в себя установку элементов ПО ИС и
технического обеспечения, а также их тестирование и устранение выявленных
ошибок. Этап разбивается на два подэтапа: создание среду функционирования
ИС и тестирование ИС.
60
Цель этапа «Сопровождение» - мониторинг и доработка программного и
технического обеспечения ИС в процессе эксплуатации, а также работа с
пользователями.
К вспомогательным процессам цикла программного обеспечения
относятся:
1. Документирование;
2. Управление конфигурацией;
3. Обеспечение качества;
4. Верификация;
5. Аттестация;
6. Совместный анализ;
7. Аудит;
8. Решения проблем.
К организационным процессам жизненного цикла программного
обеспечения относятся
1. Управление;
2. Создание инфраструктуры;
3. Процесс усовершенствования;
4. Процесс обучения.
Процесс разработки состоит следующих этапов, выполняемых
разработчиком. Описание каждого этапа применительно к разрабатываемому
модулю, автоматизирующего работу по учету труда и заработной платы на
частном предприятии «Оптимал», отражено в таблице 2.1.
Таблица 2.1
Описание этапов жизненного цикла разрабатываемого модуля
Наименование
этапа
Описание этапа
1
2
Подготовка
процесса
разработки
Выбрана модель жизненного цикла программного
средства. Приняты решения о применяемых методах,
инструментальных средства разработки и языках
программирования.
61
Продолжение таблицы 2.1
1
2
Анализ требований
к системе
Определены общая, техническая и программная
архитектуры проекта. Проанализировано назначение
программного средства и, на основании выполненного
анализа, уточнены требования к нему. Также на данном
этапе оговорены планы сборки и квалификационных
испытаний системы.
Проектирование
программных
средств
Требования к программному средству преобразованы в
его архитектуру, осуществлено детальное проектирование
программного средства. Произведено распределение
технических требований к компонентам между
программными модулями.
Программирование
и тестирование
программных
средств
Осуществляется кодирование и тестирование
программных модулей, а также оценка полученных
результатов
Сборка и
квалификационные
испытания
программных
средств
Осуществлена сборка программных модулей, технической
конфигурации, и ручных операций в единую подсистему.
Проведено тестирование и оценка качества собранной
подсистемы с моделируемыми исходными данными.
Ввод в действие и
обеспечение
приемки
программных
средств
Разработанный проект введен в действие в среде
эксплуатации, проведено заказчиком приемочных
испытаний с целью проверки пользователем соответствия
системы исходным требованиям.
Эксплуатация и
сопровождение
определяются недоработки и согласованность работы всех
компонентов. При выявлении недоработок определяются
перечень указаний для исправлений разработчиком
62
Разработка модуля по учету труда и заработной платы на частном
предприятии «Оптимал» предполагает первоначальный анализ существующих
решений на предприятии и выборе стратегий внедрения.
Существуют следующие основные стратегии внедрения системы:
1. Параллельная стратегия - когда одновременно работают старая
(ручная) и новая система, и их выходные документы сравниваются. Если они
согласуются длительное время, осуществляется переход на новую систему.
2. «Скачок». Эта стратегия привлекательна, но не рекомендуется.
3. «Пилотный проект». Это наиболее часто используемая стратегия.
«Пилотный проекта» - это тактика «скачка», но применяемая к ограниченному
числу процессов. Область применения стратегии - небольшой участок
деятельности. Такой подход снижает риск и наиболее надежен. Практически все
предприятия применяют эту тактику сегодня.
4. «Узкое место» - это малая часть производственного процесса. При
использовании похода «узкое место» план внедрения выполняется только для
«узкого места» и для людей, работающих в нем. Точность данных повышается
только для изделий в этом "узком месте"; переподготовка - только для людей,
работающих в нем; анализ эффекта затрат делается только для него и т.д.
Для реализации модуля по учету труда и заработной платы на частном
предприятии «Оптимал» наиболее подходящей стратегией внедрения является
стратегия параллельного внедрения. Разрабатываемое программное средство
является дополнением к уже существующему на частном предприятии
«Оптимал» информационному обеспечению и входит в состав большого
функционального блока, выполняемого бухгалтером, реализуемого не только
при помощи компьютерной техники.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Разработка модуля по учету труда и заработной платы на частном
предприятии «Оптимал» может быть связана с возможными рисками,
возникающими на различных этапах жизненного цикла.
Основные риски, возникающие на этапах жизненного цикла
программного обеспечения:
63
выявление и анализ требований;
проектирование программного обеспечения;
программирование;
тестирование программного обеспечения.
Выявление и анализ требований. Выявление и анализ требований играют
важную роль в успехе проекта разработки программного обеспечения, так как
большая часть ошибок происходит на ранних стадиях разработки.
Это связано с природой разработки программного обеспечения: выполняемая
работа базируется на ранее выполненной. Например, проектирование
выполняется на основе требований, программирование реализуется на основе
модели проектирования, а тестирование производится на основе написанного
текста программы.
Первый вариант двусмысленности заключается в том, что пользователь
может интерпретировать одно и то же требование по-разному.
Второй вариант состоит в том, что у нескольких читателей возникает
разное понимание того, что означает требование.
Проектирование. Риски, возникающие на этапе проектирования, играют
важную роль в процессе разработки программного обеспечения и требуют
особого внимания, так как основные технические вопросы решаются именно на
этом этапе.
1. Сложность архитектуры программного обеспечения
Архитекторы программного обеспечения не всегда придерживаются
правила «Не порождайте сущностей сверх необходимого». Но ведь именно
простота, понятность и единая концептуальная целостность обеспечивают
эффективную реализацию системы.
2. Неудобный пользовательский интерфейс
Разработка пользовательского интерфейса является частью любого
проекта, связанного с созданием программного обеспечения. Интерфейс
пользователя является точкой взаимодействия человека и программы, зачастую
имеющей сложную функциональность. Именно через интерфейс пользователь
судит о программе в целом; более того, часто решение об использовании
программного обеспечения пользователь принимает по тому, насколько ему
64
удобен и понятен пользовательский интерфейс. Следовательно, от того
насколько удобным будет разработанный интерфейс пользователя будет
зависеть и успех продукта.
3. Неправильная структура базы данных
При разработке программного обеспечения проектирование базы данных
требует особого внимания и ответственности, так как стоимость допущенных на
этом этапе ошибок особенно велика. Проблемы, которые могут произойти на
этапе проектирования базы данных:
некорректность схемы базы данных по отношению к предметной
области;
несоответствие аппаратным ограничениям;
сложность и неудобная работа с базой данных;
невозможность к поддержке и сопровождению.
4. Неоптимальный выбор структур данных. Структуры данных влияют
на эффективность алгоритмов и, следовательно, на производительность
программного обеспечения.
5. Неоптимальный выбор языка программирования. При разработке
программного обеспечения имеется огромный выбор языков программирования,
в лабиринтах которых можно легко заблудиться. Для того чтобы выбор языка
программирования оказал благоприятное влияние на реализацию системы,
необходимо учитывать следующие факторы:
целевая платформа;
гибкость языка;
время реализации;
производительность;
сопровождение программного обеспечения;
предметная область разрабатываемой системы;
необходимость в использовании библиотек;
опыт разработчиков.