MODEL OF INCOMPLETE LIFE CYCLE OF SOFTWARE
Authors:
1.
Siberia State Industrial University
(Senior Lecturer of the Department of Automation and Information Systems )
Russian Federation
Russian Federation
2.
Siberia State Industrial University
(Senior Lecturer of the Department of Automation and Information Systems; Leading Informatization Specialist of the Department of Systems and Network Technologies )
3.
Siberian State Industrial University
(Doctor of Technical Sciences, Professor; Professor of the Department of Automation and Information Systems )
Type:
Article
Pages:
from 65
to 70
Status:
Published
Received:
05.04.2015
Accepted:
28.02.2020
Published:
25.04.2015
Subject area:
VAC 05.12.2013 Системы, сети и устройства телекоммуникаций
VAC 05.13.01 Системный анализ, управление и обработка информации (по отраслям)
VAC 05.13.06 Автоматизация и управление технологическими процессами и производствами (по отраслям)
VAC 05.13.10 Управление в социальных и экономических системах
VAC 05.13.18 Математическое моделирование, численные методы и комплексы программ
VAC 05.13.19 Методы и системы защиты информации, информационная безопасность
UDK 004.04
GRNTI 20.01 Общие вопросы информатики
GRNTI 28.01 Общие вопросы кибернетики
GRNTI 49.01 Общие вопросы связи
GRNTI 50.01 Общие вопросы автоматики и вычислительной техники
GRNTI 82.01 Общие вопросы организации и управления
VAC 05.13.01 Системный анализ, управление и обработка информации (по отраслям)
VAC 05.13.06 Автоматизация и управление технологическими процессами и производствами (по отраслям)
VAC 05.13.10 Управление в социальных и экономических системах
VAC 05.13.18 Математическое моделирование, численные методы и комплексы программ
VAC 05.13.19 Методы и системы защиты информации, информационная безопасность
UDK 004.04
GRNTI 20.01 Общие вопросы информатики
GRNTI 28.01 Общие вопросы кибернетики
GRNTI 49.01 Общие вопросы связи
GRNTI 50.01 Общие вопросы автоматики и вычислительной техники
GRNTI 82.01 Общие вопросы организации и управления
Language:
Russian
Keywords:
life cycle, model, release, software
Abstract (English):
The development of large software projects requires considerable efforts. The known regulatory models of the entire life cycle, which are used by large companies, cover all the stages and phases of the life project and, ultimately, significantly increase the development costs. With the growth of the complexity of the projects, there is a necessity to use the technological process that imposes on the activities of the technical staff and decreases the costs. The article considers a model of incomplete life cycle of software and hardware based on the iterations and testing suitable for use by mobile teams of programmers in a highly optimizing costs and resources. The abovementioned approach is based on the adopted in the system analysis input-output model of the "black box", which is acquires functionality during the process of development in line with the business requirements. The key difference from all previously considered normative models of the software life cycle is to make the developers focus on the ever-changing needs of the customers. The situations, when all the stakeholders clarify their vision of architecture and functions of the system, are taken into account. Following the natural tendencies of the development of the software, the presented model of partial life cycle is based on the elements of agile development, in particular, test-driven development, when the applied tool allows you organically to embed modular tests into the projects.
The development of large software projects requires considerable efforts. The known regulatory models of the entire life cycle, which are used by large companies, cover all the stages and phases of the life project and, ultimately, significantly increase the development costs. With the growth of the complexity of the projects, there is a necessity to use the technological process that imposes on the activities of the technical staff and decreases the costs. The article considers a model of incomplete life cycle of software and hardware based on the iterations and testing suitable for use by mobile teams of programmers in a highly optimizing costs and resources. The abovementioned approach is based on the adopted in the system analysis input-output model of the "black box", which is acquires functionality during the process of development in line with the business requirements. The key difference from all previously considered normative models of the software life cycle is to make the developers focus on the ever-changing needs of the customers. The situations, when all the stakeholders clarify their vision of architecture and functions of the system, are taken into account. Following the natural tendencies of the development of the software, the presented model of partial life cycle is based on the elements of agile development, in particular, test-driven development, when the applied tool allows you organically to embed modular tests into the projects.
Keywords:
life cycle, model, release, software
life cycle, model, release, software
Введение Многие формализованные подходы, в частности спиральная и каскадная (водопадная) модель [1], предусматривают последовательное прохождение программного продукта по определенным этапам жизненного цикла (ЖЦ): постановка задачи, анализ рисков, анализ требований, построение проектных спецификаций, проектирование, реализация, тестирование, ввод в эксплуатацию и сопровождение, вывод из эксплуатации. Такие громоздкие нормативные модели в условиях оперативных изменений требований заказчиков на практике создают проблемы, для решения которых изначально не были предназначены. Зачастую снижение производительности коллектива разработчиков влечет за собой изменение графика работ и увеличение бюджета проекта. Сама идеология предварительного алгоритмического проектирования изначально предполагает отсутствие гибкости, «монолитность» документации и первоначального кода, т. к. разработчики не всегда могут оперативно реагировать на изменения требований заказчика. К сожалению, многие коллективы разработчиков считают, что процесс создания программного обеспечения (ПО) пока еще является недостаточно всеобъемлющим и формализованным, тем самым они способствуют неконтролируемому росту разнообразных стандартов проектирования, диаграмм, нотаций и спецификаций. Так, например, стандарт UML 2.0 (Unified Modeling Language) [2] предусматривает возможность использования 14 типов диаграмм, из которых на практике обычно используется не больше половины. Недостатки применения моделей полного жизненного цикла Современная разработка сложного ПО и объектно-ориентированный подход предполагают в первую очередь наличие гибкой и масштабируемой архитектуры, способной оперативно реагировать на изменения потребностей заказчика в условиях, когда сам заказчик не всегда способен четко сформулировать требования к системе на этапе проектирования. Действительно, откуда заказчик может взять требования к пользовательскому интерфейсу приложения, когда обычно на практике эти требования должны эволюционировать в соответствии с пожеланиями постоянных пользователей? Откуда заказчик может знать заранее, какой интерфейс ему будет нужен? Более того, недостаточная обратная связь на стадии программирования ведет к неконтролируемому росту затрат при сопровождении. Очевидно, что большинство моделей полного ЖЦ в достаточной степени избыточны, неэффективны и слишком дороги для использования в условиях конкурирующего и динамично развивающегося рынка ПО. В конечном счете, документация и диаграммы никогда не смогут устранить архитектурные недостатки дизайна системы, а также учесть постоянное накопление и развитие опыта разработчика. Гибкие методики разработки ПО Гибкие методики, такие как Crystal [2], Scrum [3], XP [2, 4], предусматривают быструю поставку начальной версии работающей программы заказчику для тестирования, игнорируя на начальном этапе многие проектные требования и подразумевая последующее расширение функциональности программы. Основная цель - обеспечение непрерывности развития проекта с возможностью оперативного реагирования на изменения требований бизнеса. Тяжеловесные модели полного ЖЦ слишком неуклюжи, чтобы предусмотреть полный пересмотр заказчиком своего «видения» на этапе завершения проекта. Гибкие методики предлагают коллективам разработчиков ПО сконцентрироваться на качестве выпускаемого продукта в ущерб документации и прочим артефактам проектно-процессной деятельности. Программный продукт выпускается короткими итерациями, каждая из которых заканчивается определенной сборочной версией, которая поступает в эксплуатацию, а также используется заказчиком для уточнения требований и предварительного тестирования. Разработчики и заказчики формируют сроки и бюджет каждой итерации, оценивая предыдущие достигнутые результаты и требуемый прирост функционала от версии к версии. При этом предварительный сбор детальной информации о требованиях к системе, принятый в моделях полного ЖЦ будет пустой тратой времени и сил, поскольку конечная реальность может оказаться другой. Конкретные детали требований со временем могут и должны изменяться в процессе взаимодействия с ответственным представителем заказчика. В связи с этим в практической деятельности целесообразно оперировать понятиями ЖЦ отдельной сборочной версии или итерации, что позволит сконцентрировать видение заказчиков и разработчиков на функциональном, более узком аспекте деятельности ИТ-коллективов, связанных в первую очередь с разработкой ПО. Таким образом, в гибкой разработке этапы проектирования, программирования и сопровождения непрерывны, неотделимы друг от друга и входят в состав отдельной короткой итерации разработки. Модель неполного ЖЦ ПО Предложена модель неполного жизненного цикла, которая основана на последовательном уточнении архитектуры программного комплекса, представленной, исходя из основополагающих принципов системного анализа, в виде «серого ящика» на i-й итерации изменения бизнес-требований. Нулевая итерация представляет собой пустую сборочную версию r(Ø), компоненты которой не определены. Обозначим одно бизнес-требование как , где формирует пространство всех требований заказчика. Таким образом, совокупность бизнес-требований (заказчика) для i-й итерации проектных изменений можно описать вектором (Business Requirements), где i изменяется от 1 до некоторого k, определяющего стадию ввода в эксплуатацию программного продукта. В условиях трасформации требований, когда некоторое их подмножество остается неизменным, а другое «уточняется», измененные требования можно представить как - уточнение и детализация заказчиком своих пожеланий. Необходимо отметить, что некоторые координаты вектора изменений равны нулю, т. к. изменения соответствующего не требуются. Для каждого необходимо произвести рефакторинг кода и выполнить тестирование, поэтому вектору однозначно соответствует вектор на i-м шаге уточнения требований. На вход ящика поступают изменения , обусловленные текущими требованиями заказчика и оформленные в виде новых бизнес-потребностей - самых общих соображений по поводу функциональности, без фиксации конкретных деталей. Выходы «серого ящика» отражают прохождение (или непрохождение) тестов функциональности, используемых для актуализации архитектуры системы в рамках необходимых требований. Таким образом, на каждой итерации происходит уточнение «черного ящика» до тех пор, пока он не превращается в «белый ящик», пригодный для промышленного использования (рис. 1). Рис. 1. Модель неполного ЖЦ итерации сборочной версии Обозначим Rp = {ri |iI} как множество сборочных версий одного проекта, последовательно формируемых разработчиком в процессе уточнения бизнес-требований заказчика; p - номер проекта. Также обозначим одну сборку как , тогда начальную сборку как r(Ø). Таким образом, начальную итерацию можно рассматривать как реализацию изменений требований относительно «черного ящика». На рис. 2 показаны два проекта, для каждого из которых наблюдается собственная линия сборок. Рис. 2. Итерационная модель ЖЦ сборочной версии По аналогии с версионной моделью ЖЦ услуги, представленной в [5], приведем итерационную модель ЖЦ сборочной версии ПО. Итерационная модель услуги описывает эволюцию отдельных версий сервиса по стадиям ЖЦ ITIL [6], к которым относится стратегия, проектирование, трансформация и эксплуатация услуг. Предлагаемая нами модель, в отличие от версионной [5], позволяет с максимальной степенью адаптировать разработку ПО под постоянно изменяющиеся потребности заказчика в условиях значительной неопределенности. Модель ЖЦ сборочной версии опирается на современные тенденции в индустрии ПО, в частности, на управляемую модель на основе разработки [2, 4], паттерны проектирования [2] и поддерживается большинством сред разработки промышленного масштаба, таких как MS Visual Studio и Oracle JDeveloper. Процедура последовательного улучшения программно-технического обеспечения включает в себя учет добавленных (или изменяющихся) бизнес-требований для каждой i-й итерации формирования очередной сборочной версии (рис. 3). Неполная модель ЖЦ ПО, опробованная нами в проектах [7-9], подходит для разработки крупных программных систем в условиях оптимизации затрат. Сравнение подходов к разработке производилось на основе двух подобных проектов, выполненных в 2014 г. в Сибирском государственном индустриальном университете. Рис. 3. Процедура последовательного (итерационного) улучшения ПО Первый проект использовал спиральную модель полного ЖЦ, в котором наряду со штатными сотрудниками принимали участие сторонние разработчики. Он представляет собой web-сайт университета (http://www.sibsiu.ru), выполненный на базе системы управления CMS 1C «Битрикс». Проект прошёл множество (около 20) полных спиралей разработки: - оценка и разрешение рисков; - определение целей; - разработка и тестирование; - планирование и т. д. А также все необходимые этапы: - написание технического задания; - выбор, закупка и установка CMS; - разработка макета дизайна (сторонние специалисты); - вёрстка шаблона; - разработка инфоблоков и дополнительный модулей для CMS «Битрикс»; - наполнение сайта (перенос информации со старого сайта); - обучение персонала; - написание отчёта. Общее время разработки составило около 6 месяцев при работе двух программистов, одного дизайнера, двух контент-менеджеров и сторонних специалистов. Второй проект - система мониторинга эффективности деятельности университета (http://monitoring.sibsiu.ru) - был выполнен полностью «с нуля» силами штатных разработчиков с применением модели неполного ЖЦ. В связи с мобильностью группы разработки и близостью к заказчику у разработчиков была возможность постоянного уточнять цель и задачи, что позволило избежать большого количества итераций разработки. Проект прошёл примерно 12 итераций уточнения требований и следующие этапы: - первичная постановка цели; - разработка макета дизайна; - вёрстка шаблона; - разработка функционала; - обучение персонала; - написание отчёта. Техзадание было кратким, отражающим только цели разрабатываемой системы, поэтому степень неопределённости и риски срыва сроков проекта были высоки. Вся работа была выполнена за 4 месяца силами трех человек. Заключение Дано описание модели неполного ЖЦ программно-технического обеспечения, основанной на итерациях и тестировании, пригодной для использования мобильными коллективами программистов в условиях оптимизации затрат и ресурсов. Приведенный подход опирается на принятую в системном анализе вход-выходную модель «черного ящика», которая приобретает функциональность в процессе разработки в соответствии с бизнес-требованиями.
1. Rassel Dzh. Zhiznennyy cikl programmnogo obespecheniya / Dzh. Rassel // Bookvika Publishing, 2012. 89 s.
2. Martin R. S. Agile software development / R. S. Martin, Dzh. V. N'yukirk, R. S. Koss // Principles, Patterns and Practicies Principles, Patterns and Practicies. M.: Vil'yams, 2004. 752 s.
3. Cohn Mike. Scrum: Succeedind with Agile: Software Development Using Scrum (Addison-Wesley Signature Series). M.: Vil'yams, 2011. 576 s.
4. URL: http://www.jot.fm/books/review7.pdf.
5. Zimin V. V. Osnovy upravleniya zhiznennym ciklom servisa sistem informatiki i avtomatizacii (luchshie praktiki ITIL): ucheb. posobie / V. V. Zimin, A. A. Ivushkin, S. M. Kulakov, K. A. Ivushkin. Kemerovo: Kuzbassvuzizdat, 2013. 500 s.
6. OGC-ITIL V3-6. Service Lifecycle. Introduction ITIL TSO, 2007. 173 p.
7. Dobrynin A. S. O formirovanii kompleksa instrumental'nyh sredstv IT-provaydera dlya postroeniya raspisaniy processa vnedreniya servisa / A. S. Dobrynin, S. M. Kulakov, V. V. Zimin, N. F. Bondar' // Nauchnoe obozrenie. 2013. № 8. S. 93-101.
8. Koynov R. S. Ob ispol'zovanii principa soglasovannogo upravleniya v zadachah vnedreniya IT-servisa / R. S. Koynov, A. S. Dobrynin, S. M. Kulakov, V. V. Zimin // Vestn. razvitiya nauki i obrazovaniya. 2013. № 6. S. 23-27.
9. Dobrynin A. S. Formirovanie raspisaniy v zadachah vremennogo planirovaniya / A. S. Dobrynin, S. M. Kulakov, R. S. Koynov, A. V. Grachev // Vestn. Astrahan. gos. tehn. un-ta. Ser.: Upravlenie, vychislitel'naya tehnika i informatika. 2014. № 4. S. 103-111.
