Основываясь на опыте реализации крупных проектов в данной отрасли, специалисты по разработке программного обеспечения (ПО) разработали различные методы, преследующие различные цели. Среди прочего, они должны обеспечивать качество создаваемого ПО, а также его пригодность на протяжении всего жизненного цикла, повышать его пригодность для повторного использования и сокращать время доставки. Они улучшают работу и координацию в распределенных командах разработчиков. Исследователи Надин Витерс и Бернадетт Фрич разработали два примера инструментов программной инженерии:
- системы контроля версий (VCS) в качестве инструмента разработки ПО;
- гибкая разработка ПО, в качестве примера более стратегического метода разработки.
1. Системы управления версиями
В значительной степени, исследовательское программное обеспечение разрабатывается не только отдельными учеными, но и является общей задачей большой группы разработчиков, некоторые из которых работают одновременно в разных местах. Для такой совместной работы каждый разработчик должен всегда точно знать, какие изменения были сделаны другими разработчиками, и что они могут повлиять на его или ее работу.
Системы контроля версий (VCS) управляют сложными проектами с большим количеством участников. Они отслеживают различные состояния ПО и всегда поддерживают восстановление определенных версий программного обеспечения. Ученый может повторить численный эксперимент или обработку данных с точно такой же версией ПО и тем самым доказать воспроизводимость результатов. Поэтому VCS полезны не только для сотрудничающих команд, но и для отдельных разработчиков, так как они улучшают сотрудничество в будущем.
Первые системы управления версиями были разработаны в 1970-х годах, где они изначально помогали в администрировании Unix-системы путем протоколирования изменений в конфигурационных файлах и т.д. и разработке оперативных систем.
Позже сфера его применения распространилась на все типы файлов и документов и особенно на код ПО. Они выполняют несколько задач. Изменения записываются в журнал, чтобы можно было понять, кто что и когда сделал.
Предыдущие состояния могут быть восстановлены таким образом, чтобы случайные изменения или неудачные попытки можно было обратить вспять. Все штаты архивированы. Это позволяет получить доступ ко всем версиям. Совместный доступ к файлам от нескольких разработчиков будет координироваться, и он будет немедленно оповещать о конфликтующих действиях.
Современные системы управления версиями также поддерживают одновременную работу над несколькими ветвями разработки проекта и, таким образом, позволяют одновременно выполнять различные подзадачи. Когда модель совместно разрабатывается несколькими учеными, VCS необходима для обеспечения эффективности кодирования и предотвращения конфликтов посредством одновременных и противоречивых изменений. Однако это часто требует фундаментальных изменений в индивидуальном рабочем процессе ученых-разработчиков. Изменения в коде должны постоянно проверяться, чтобы система могла выполнять свои функции.
В некоторых случаях тот факт, что работа каждого разработчика заметна, в том числе и на неготовых стадиях, может означать психологическое препятствие, которое необходимо преодолеть. Помимо вопросов, которые могут быть улучшены VCS, важно установить лучшие практики интеграции VCS в процесс развития. Команда разработчиков должна договориться о подходящих способах работы с VCS. Только в этом случае возможности этого инструмента могут быть использованы в полной мере, а его разработка - усовершенствована. Для научного сектора важную роль играют решения с открытым исходным кодом для систем управления версиями.
2. Разработка гибкого программного обеспечения
Разработчиками в основном используется линейный подход к разработке ПО, подобно так называемой модели водопада, основан на дискретных фазах анализа, проектирования, кодирования и тестирования. Фазы строятся друг на друге и выполняются в заранее определенной последовательности. Характерной чертой данного подхода является последовательное выполнение ранее запланированных мероприятий. Таким образом, обеспечивается высокий уровень надежности планирования.
Однако существует риск того, что последующие изменения требований могут быть приняты во внимание только с большим трудом или огромными усилиями. Требования к ПО в научных проектах часто неясны с самого начала. Это влечет за собой риски при реализации модели водопада. Поскольку требования к ПО меняются в соответствии с обычной в научном контексте итеративной процедурой, целесообразно использовать гибкую процедуру, которая позволяет быстро адаптироваться к изменениям.
Многие гибкие методы и практики зародились на основе Манифеста о разработке гибкого программного обеспечения. Они характеризуются постоянным сопоставлением ожиданий с фактическим состоянием разрабатываемого программного обеспечения. Таким образом, они обеспечивают большую гибкость.
Свойства ПО сформулированы с точки зрения пользователя, записаны и приоритизированы в Product Backlog владельцем продукта. Эти требования постепенно внедряются командой разработчиков в относительно короткие промежутки времени (так называемые спринты).
Команда разработчиков несет ответственность за предоставление функциональных возможностей в том порядке, в котором этого хочет владелец продукта. Она сама организуется и решает, как работать. В конце каждого спринта находится готовый продукт. В конце цикла продукт, требования (возможно, измененные) и процедура пересматриваются и дорабатываются в следующем спринте.
Применение гибкости в научном проекте может происходить по-разному. С одной стороны, гибкое управление часто оказывается частью общего проекта, неотъемлемой частью которого является разработка программного обеспечения. Затем разработка ПО осуществляется по тем же принципам, что и другие части проекта.
С другой стороны, гибкий подход к разработке ПО может быть внедрен и в другие методы общего управления проектами. В этом случае важно, чтобы руководитель проекта понимал специфику гибкого метода и принимал их во внимание при планировании всего проекта.
Поскольку качество ПО в решающей степени зависит от имеющихся знаний и навыков его разработчиков, существует большая потребность в дальнейшем обучении вовлеченных людей. Благодаря проведенным работам с программным обеспечением в настоящее время существует обширная сеть экспертов, которые делятся своим опытом и знаниями в области программирования и передовой практикой.
Разработка высококачественного ПО требует времени и кадровых ресурсов. Средства управления программным обеспечением могут поддерживать и совершенствовать разработку научного ПО, однако его интеграция в проектные группы требует координации и консенсуса в отношении способов его применения.
Этот процесс отбора и интеграции должен рассматриваться как часть процесса разработки программного обеспечения в рамках проекта. Для решения проблемы недостаточной осведомленности и знаний в области средств программной инженерии большое внимание следует уделять подготовке кадров и рассматривать ее в качестве части исследовательского проекта.
В рамках проекта и за его пределами следует содействовать обмену знаниями и опытом между научными специалистами и инженерами-программистами в целях преодоления препятствий в области коммуникации и культуры.
