CC BY
37
Вурф-классификация позволяет решить еще одну задачу, например, задачу упорядоченного группирования организмов внутри класса позвоночных. В БД (табл. 1) позвоночные представлены следующими подвидами: млекопитающие, рыбы, птицы и рептилии. Если исключить млекопитающих, то оставшиеся позвоночные будут строго упорядочены С ПОМОЩЬЮ вурф-параметра в следующей последовательности: шпицы (И'=1,08..1,11) — рептилии (\У=!,2.. 1,42) — рыбы (\М=148.. 1.8). В классе беспозвоночных вурф-сорти ровка выделяет подвид клещей.
Чтобы подтвердить «правильность» и устойчивость пред'южешюгоалгоритма классификации, необходимо использовать более обширный статистический материал. В частности, предполагается про-вест анализ множества генетических текстов людей разных полой, рас, национальностей, возрастов, а также наших ближайших «родственников» из группы приматов.
БнОлиографпчоский список
I. Задорожпикои К.Г. Генетическая система кдк носитель принципа гармонии. Открытие Золотого Вурфп генетической
системы // М. : Академия Тринитарнзма», Эл К-> 77*6567. иубл.11739,24.12.2004.
2. Гуменюк А.С., Шнынов С.Н.. Морозенко ІЇ.ІЗ-. Родио-ноп И.11. Пример применения средств интервального анализа для Ср.ІІШПНИЯстроя НуКЛеСГТИЛНЫХИОСЛ«*Д(>»'»Т1‘Л1.НОСГТРЙ и клпстсрн-злцнв организмов // Мат-лы XVI Всероссийского семинара «Нейроиііформіїгикп,<!« приложения И аіІсІЛИЗДШШЬІХ» ; подред. .АН. Горбаня и В.М. Мирнее*». - Красноярск : Изд-во ИВМ СО РАН. 2008. - С. 166 —170,
3. Гуменкж А.С. Осредстпахописания и анализа строя цепи событий //СИБРЕСУРС-11-2005 : доклады 11-й науч.-прані, конф.. Барнаул. Томск: Том. гос. ун-т, 2005. - С. 234 —239.
КЛИКУШИН Юрий Николаевич, доктор технических наук, доцент, профессор кафедры «Технология электронной аппаратуры».
Адрес для переписки: 64*1050, г. Омск, пр. Мира, 11.
Статья посту пила в редакцию 25.09.2009 г.
V) Ю. Н. Клнкушнн
удк 004:57 Д. Н. МАТВИЕНКО
Омский государственный технический университет
ИННОВАЦИОННЫЕ МЕТОДОЛОГИИ
ПЕРЕПРОЕКТИРОВАНИЯ
«УНАСЛЕДОВАННЫХ»
ПРОГРАММНЫХ СИСТЕМ_____________________
Приводится описание опыта команды разработчиков, решающей задачу внедрения механизмов тест-ориентироаанной разработки (Test-Driven Development, TDD) в существующий проект (СУБД «Деканат», ОмГТУ), первоначально не адаптированный к использованию TDD-инструментария. Проведен анализ возможностей и ограничений, возникающих при необходимости внесения изменений на уровне методологии проектирования системы, подчеркивается необходимость оптимизации процесса документирования требований к проекту.
Ключевые слова: тест-ориентированная разработка, методология, тестирование, документирование.
Постановки задачи
С целью научно-практического исследования возможностей ТОй-архитектуры была поставлена задача преобразования студенческого проекта (СУБД «Деканат»: язык РНР, база данных МуБОЬ) в систему, разработаннуюсучетом промышленных требований к контролю качества программного обеспечения 111. 11а первый взгляд это означает переписывание исходного кода «с чистого лис га». Покажем на примере, что задача может быть решена менее радикальными способами.
О методиках разработки
Анализ «унаследованного» проекта показывает, что система разрабатывалась в рамках классической
методологии построения программных средств (ПС), известной под названием «Модель водопада».
Следуя модели водопада, разрабо тчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап определения требований. Далее происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. Программистами выполняется создание исходного кода проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов, Заключительная стадия — тестирование и отладка продукта: устраняются все недочёты, допущенные на предыдущих этапах. После этого программный продукт внедряется и обеспечивается его поддержка, внесение
ОМСКИЙ НАУЧНЫЙ МСІНИК МІ 3 <83, №» ИНФОРМАЦИОННА ИХНОЛОГИИ
ИНФОРМАЦИОННЫЕ TIXHOA
ОЗший Список требований Спринт {Итерации) Промежуточная версии
список ipL-бооаимй ддя текущей птерпции ал» демонстрации прироста
фуикииомллмиости
Ргавиа Bocklcg SprlM Backlog
working loCTemef l
Рис. 1. Методология «Scrum»
нивой функциональности и устранение ошибок, выявленных при использовании.
Тем самым модель водопада подразумевает, что переход к последующей фазе разработки происходит только после полного и успешного завершения предыдущей; переходов назад, вперед или перекрытии фаз не происходит.
Для реализации базового принципа TDD «Test First» {«Тестирование в первую очередь») модель водопада неприменима.
Таким образом, находясь еще очень далеко от начала процесса модернизации кода, команда исследователей столкнулась с первой проблемой: унаследованная система проектировалась без учета возможностей расширения функциональности. Предыдущим коллективом разрабо тчиков допущена концептуальная ошибка, характерная для многих учебных проектов: отсутствие разделения дизайна и бизнес-логики (логики функционирования) программной системы.
Соответственно, первым шагом станет изменение подхода к проектированию,системы. Нас будут инте-ресовать «гибкие» («Agile»1) методы разработки.
Большинство «гибких» методологий нацелены па минимизацию рисков нугём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся отодной до четырех недель. Каждая итерация выглядит как программный проект в миниатюре и включает все задачи, необходимые Mil выдачи прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что «гибкий» программный проект готов к демонстрации прироста функциональности после каждой итерации.
Выбор конкретной «гибкой» методики является субъективным для каждого коллектива разработчиков; в пашем случае предпоч тение отдано методике «Scrum».
Scrum — это алгоритм процесса, который включает набор методов и предварительно определенных ролей, Главные действующие роли:
1. «ScrumMasier» — координа тор (руководитель) проекта.
2. «ProductOwner» («Владелецпродукта») — представитель интересов заказчика или конечных пользователей системы.
3. «ScrumTeam» («Команда») — коллектив разработчиков.
Итерация в методике Scrum называется «спринтом» («Sprint»). На протяжении каждого спринта создается функциональный рост программного обеспечения. Длительность спринта определяется Командой и. как правило, составляет 15-30 дней (рис. 1). После каждого спринта допустима переоценка приоритетов для актуальных задач.
Наборы требований поступают из заранее сформированного документа. который называется «Общий список требований» («Product Backlog»). Задачи, выполняемые о текущем спринте, определяются Владельцем продукта с учетом мнения Команды на «Совете по планированию» («Sprint Planning Meeting»).
О роли технического задания
в тестировании программного обеспечения
Для программ, создаваемых на уровне продукции производственно-технического назначения и отчуждаемых от разработчика, испытания (тестирования) являются одним из важнейших этапов жизненного цикла, па котором проверяются и фиксируются достигнутые показатели качества программного средства.
В соответствии с ГОСТ 10504 01 под испытанием
промышленной продукции понимают экспериментальное определение количественных и/или качес твенных характеристик объекта испытания как результата воздействия на него:
— при его функционировании;
— при моделировании объекта и/или воздействия.
Под испытанием программной продукции следует
понимать экспериментальное определение количественных и/или качественных характеристик продукции при ее функционировании в реальной среде и/ или моделировании среды функционирования.
Целью испытания является выяснение степени соответствия созданного комплекса программ техническому заданию, полученному от заказчика. I !еоб-ходимо сделать выводе пригодности данного ПС к использованию по своему назначению. Если вывод отрицательный, то образец программы возвращается на дорабо тку. Таким образом, перекрывается дос туп недоброкачественной продукции к пользователю. Непосредственно в ходе испы таний качество продукта может и не измени ться, гак как локализация ошибок в общем случае не является целью испытания.
В зарубежной литературе, в том числе в стандартах на программное обеспечение, понятие «испытание» часто отождествляют с понятием «тестирование». Например, в документе IEEE 829-1983 «Докумен-тациятестов программного обеспечения» (США) дано следующее определение тестирования: «...процесс активного анализа ПО на предмет обнаружения расхождений между реальными и требуемыми нормами функциональности с целью оценки характеристик элементов ПО». Сучетом высказашn.tx соображений термин «тестирование», используемый в зарубежной литературе, будем интерпретировать как испытание м етодом тестирования.
Важная особенность испытаний программы состоит в наличии достаточно полных эталонов, которым должен соответствовать комплекс программ, — требований технического задания.
За относительно короткий период нриомо-сдаточных испытаний трудно провести достаточно полное тестирование, демонстрирующее достигнутое качество сложного комплекса программ. Поэтому для обеспечения высокого качества программных систем и техническом падании целесообразно задавать технологию проектирования и условия поэтапной проверки основных компонент в процессе разработки. Для гугого в процессе формирования технических требований задаются основы методики тестирования и проверяемые характеристики программ при испытаниях.
В этом случае испытатель получает возможность поэтапно и глубоко знакомиться с создаваемым изделием в процессе разработки. Одновременно уточняется и конкретизируется техническое задание.
Применение принципов TDD можно считать развитием данного направления: условия поэтапной проверки программных компонент не просто описываются в техническом задании — механизмы проверки внедряются непосредственно в исходный код программного продукта, а роли разработчика и испытателя интерпретируются в зависимости от выбранной «гибкой» методологии.
Проследим, какданныетеоротические принципы реализованы в методологии Scrum.
Product backlog — одно из базовых понятий Scrum — это документ, содержащий список требований к функциональности, которые упорядоченны по степени важнос ти. Элементы этого списка называются «историями» («User Story»). Product backlog открыт для редактирования всем участникам Scrum-процесса, что является принципиальным отличием от «классического» подхода..
Обязательные поля в Product Backlog:
— <i ID» — уникальный идентификатор. Порядковый номер, применяемый для идентификации историй в случае их переименования.
— «Название» («Name») — Краткое описание истории. Должно быть однозначным, чтобы и разработчики, и Владелец продукта могли понять, о чем идёт речь и отличить одну ис торию от другой.
— «Важность» («Importance») — степень важности данной истории, по мнению Владельца продукта. Обычно представляет собой натуральное число, иногда для этой цели используются числа Фибоначчи. Чем больше значение, тем выше приоритет.
— «Предварительная оценка» («Initial Estimate») —начальная оценка объёма работ, необходимого
ми реализации истории по сравнению с друг ими историями. Измеряется в «Story Points». Приблизительно соответствует числу «идеальных человекодней».
— «Как продемонстрировать» («How to Demo») — краткое пояснение того, как завершённая задача будет продемонстрирована в конце спринта. Данное поле может представлять собой код автоматизированного теста для приёмо-сдаточного испытания.
Применение описанных методик позволяет осуществить относительно плавный переход между двумя принципиально различными моделями пос троения программных продуктов. Постепенное замещение «традиционной» архитектуры проекта «гибкой» архитектурой происходит итеративно на отдельных, функционально изолированных сегмеш ах кода. В настоящее время завершена переработка «ядра» и основных модулей СУБД «Деканат» в соответствии с принципамитест-ориентированного программирования.
Помимо решения научно-исследовательских задач и осуществления «творческого поиска» разработка системы СУБД «Деканат» ориентирована на наращивание функциональности и практическое применение. Планируется дальнейшее развитиетсмы адаптации научных проектов к промышленным стандартам разработки программного обеспечения.
Примечания
'Всфере применения и гибкой» разработки ни данный момент не существует общепризнанной русской терминологии; для однозначности толкования понятий здесь и далее в тексте, как правило, приводятся оригинальные английские наименования процессов и объектов.
Библиографический список
1. Матвиенко, Д.И. Особенности тест ориентированной разработки программного обеспечении/Д.Н. Матвиенко// Омский научный вестник. Серии Приборы, машины и технологии. -2008. - N«3 (70). - С. 105- 107.
МАТВИЕНКО Дмитрий Николаевич, аспирант кафедры «Технология электронной аппаратуры». Адрес для переписки: 644050, г. Омск, пр. Мира, 11.
Статья поступила в редакцию 29.09.2009 г.
© Д. П. Матвиенко
Книжная полка
Компиляторы: принципы, технологии и инструментарий [Текст] / Альфред В. Ахо [и др.]; пер. с англ. И. В. Красикова. — 2-е изд. — М.: Вильямс, 2008. — 1175 с.: рис., табл. — Предм. указ.: с. 1167-1175. — ЮВЫ 978-5-8459-1349-4.
Издание начинается с изложения основных принципов разрабо тки компиляторов, включая детальное рассмотрение локсическогои синтаксического анализа и генерации кода. Особенностью данного издания являет ся широкое освещение вопросов оптимизации кода, в том числе для работы в многопроцессорных сис темах. Строгость изложения материала смягчается большим количеством практических примеров. Написание компиляторов охватынаеттакие области знаний, как языки программирования, архитек тура вычислительных систем, теория языков, алгоритмы и технология создания программного обеспечения. Помочь в освоении этих технологий и соотве тствующего инструментария и призвана данная книга. В первую очередь издание предназначено для студентов и преподавателей соответствующих специальностей, кроме того, книга будет полезна всем, кто работает над созданием компиляторов или просто интересуется данной темой.
