Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Основы разработки информационных систем. Учебное пособие.pdf
вий, которые могут либо выполняться, либо нет. Когда они выполняются,
говорят, что тест пройден. Прохождение теста подтверждает поведение,
предполагаемое программистом.
Среда разработки должна быстро реагировать на небольшие модификации кода. Архитектура программы должна базироваться на использовании
множества сильно связанных компонентов, которые слабо сцеплены друг с
другом, благодаря чему тестирование кода упрощается.
TDD не тольк
о предполагает проверку корректности, но и влияет на дизайн программы. Опираясь на тесты, разработчики могут быстрее представить,
какая функциональность необходима пользователю. Таким образом, детали
интерфейса появляются задолго до окончательной реализации решения.
Рефакторинг (англ. refactoring) или реорганизация кода – процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и име
ющий целью облегчить понимание её работы. В основе рефакторинга лежит последовательность небольших эквивалентных (т.е. сохраняющих поведение) преобразований. Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью, и в то же
время вся последовательность может привести к существенной перестройке
программы и улучшению её согласованности и чёткости.
Рефактор
инг изначально не предназначен для исправления ошибок и
добавления новой функциональности, он вообще не меняет поведение программного обеспечения и это помогает избежать ошибок и облегчить добавление функциональности. Он выполняется для улучшения понятности кода
или изменения его структуры, для удаления «мёртвого кода» – всё это для
того, чтобы в будущем ко
д было легче поддерживать и развивать.
Парное программирование – техника программирования, при которой
исходный код создаётся парами людей, программирующих одну задачу, сидя
за одним рабочим местом. Один программист («ведущий») управляет компьютером и в основном думает над кодированием в деталях. Другой программист («штурман») сосредоточен на картине в целом и непрерывно просматри
вает код, производимый первым программистом. Время от времени
они меняются ролями, обычно каждые полчаса.
Формальные инспекции кода представляют собой формализированную
процедуру просмотра кода, для этого используют специальные чек-листы,
в которых указаны правила, которые должен соблюдать программист при
разработке кода.
Формальная инспекция кода выглядит примерно так.
Координатор инспекции назначает дату инспекцио
нного собрания и инспекторов, которые должны до собрания самостоятельно изучить инспектируемый фрагмент кода. В назначенное время собираются координатор инспекции, секретарь, автор кода и инспекторы. Кто-то из инспекторов или руководитель начинают читать код строчку за строчкой (для удобства желательно его заранее распечатать вместе с номерами строк). Инспект
ора указы-
31
вают на найденные ими проблемы, автор кода отвечает на вопросы инспекторов – если все соглашаются, что ошибка действительно имеется, то секретарь её записывает. Координатор инспекции следит за процессом в целом,
например, за тем, чтобы обсуждения одной ошибки не затягивались.
По окончании инспекции составляется отчёт с её результатами.
Простота проектирования. Гибкие методологии исходят из того, что в
процессе работы условия задачи могут неоднократно меняться, а значит,
разрабатываемый продукт не следует проектировать заблаговременно
целиком и полностью. Попытка детально спроектировать систему в самом
начале работы является напрасной тратой времени. Проектирование должно
выполняться небольшими этапами с учётом постоянно изменяющихся
требований. В каждый момент времени следует пытаться использовать
наиболее простой дизайн, который подходит для решения текущей задачи,
и менять его по мере того, как условия задачи меняются.
Метафора системы. Архитектура – это представление о компонентах
системы и их взаимосвязях между собой. Разработчикам необходимо проводить анализ архитектуры ПО для того, чтобы понять, в каком месте системы необходимо добавить новую функциональность, и с чем будет взаимодействовать новый компонент.
Метафора системы (system metaphor) – это аналог того, что в большинстве методик называется архитектурой. Метафора системы даёт команде
представление о том, каким образом система работает в настоящее время,
в каких местах добавляются новые компоненты и какую форму они должны
принять.
Стандарты кодирования. Все члены команды в ходе работы должны
соблюдать требования общих стандартов кодирования. Благодаря этому:
– члены команды не тратят время на глупые споры о вещах, которые
фактически никак не влияют на скорость работы над проектом;
– обеспечивается эффективное выполнение остальных практик.
Если в команде не используются единые стандарты кодирования, разработчикам становится сложнее выполнять рефакторинг; при смене партнёров в парах возникает больше затруднений; продвижение проекта затрудняется. Необходимо добиться того, чтобы было сложно понять, кто является
автором то
го или иного участка кода, – вся команда работает унифицированно, как один человек. Команда должна сформировать набор правил,
а затем каждый член команды должен следовать этим правилам в процессе
кодирования. Перечень правил не должен быть исчерпывающим или слишком объёмным. Задача состоит в том, чтобы сформулировать общие указания, благодаря кот
орым код станет понятным для каждого из членов команды. Стандарт кодирования поначалу должен быть простым, затем он может
постепенно усложняться по мере наработки опыта группой разработчиков.
Не нужно тратить слишком много времени на предварительную разработку
стандарта.
32
Коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить
изменения в любой участок программы. Парное программирование поддерживает эту практику: работая в разных парах, все программисты знакомятся со всеми частями кода системы. Важное преимущество коллективного
владения кодом в том, что он
о ускоряет процесс разработки, поскольку при
появлении ошибки её может устранить любой программист.
Право каждого программиста изменять код ведёт к риску появления
ошибок, вносимых программистами, которые считают, что знают, что делают, но не рассматривают некоторые зависимости. Хорошо определённые
юнит-тесты решают эту проблему: если нерассмотренные зависимости порождают ошибки, то следующий запуск юнит-тест
ов будет неудачным.
40-часовая рабочая неделя даёт гарантию для команды от перегрузок,
одного из вида потерь в бережливом производстве. Надо очень чётко понимать, что количество отработанных часов не равно количеству сделанного
функционала, как и в любой интеллектуальной и инженерной деятельности.
33
3. ДОКУМЕНТИРОВАНИЕ ПРОЦЕССА РАЗРАБОТКИ
И СОПРОВОЖДЕНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Документация для программного обеспечения – это справочный текст и
визуальная информация, описывающие и отображающие процесс разработки,
производства, эксплуатации и сопровождения программного продукта, его
потребительские свойства и технические характеристики.
Виды документации для программного обеспечения.
В соответствии с таким определением, техническая документация по ПО
состоит из четырёх основных типов:
1) архитектурная/проектная – включает описание основных положений,
используемых при создании ПО и рабочей среды;
2) техническая – алгоритмы, код, интерфейсы, АРI;
3) пользовательская – руководства для пользователей программы;
4) маркетинговая – содержащая рекламную информацию о продукте.
3.1. АРХИТЕКТУРНАЯ/ПРОЕКТНАЯ ДОКУМЕНТАЦИЯ
Как правило, программный продукт описывают в общих чертах. Например, программист в проекте может обосновать, почему структура данных
организована таким (а не другим) способом, почему именно так строится
конкретный класс. В проекте выделены образцы. Часто даются инструкции о
том, как выполнить обновление программы.
Техническая документация не только указывает конкретные коды.
Она, как правило, также описывает различные аспекты того, что этот код делает. Она имеет явно выраженный технический характер и используется в
основном для описания и определения API, алгоритмов и структур данных.
При её составлении возможно использование генераторов документации
(Doxygen, NDoc, javadoc и др.), что даёт возможность постоянно поддерживать
такую документацию в актуальном состоянии. Они получают информацию из
специальным образом оформленных комментариев в исходном коде и создают
справочные руководства в каком-либо формате, например в виде текста или
HTML. В последнем случае техническая документация является частью исходного кода. Тогда одни и те же инструменты можно использовать как для сборки программы, так и для сборки в то же время документации к ней.
Хорошая пользовательская документация состоит из:
• вводного руководства, где рассматриваются общие вопросы выпол-
нения типичных задач. Наиболее полезное для новых пользователей, последовательно проводит по ряду шагов, служащих для выполнения каких-либо
типичных задач;
• тематического руководства, где каждая глава посвящена разъясне-
нию какого-либо раздела эксплуатации программы. Больше подходит для
ршенствующихся пользователей;
сове
34
• алфавитного справочника для опытных пользователей, хорошо
знающих, что нужно искать – часто это хорошо воспринимается продвинутыми пользователями, хорошо знающими, что они ищут.
Во многих случаях разработчики программного продукта ограничивают
набор пользовательской документации лишь встроенной системой помощи
(англ. online help), содержащей справочную информацию о командах или
пунктах меню. Работа по обучению новых пользователей и поддержке совершенствующихся пользователей перекладывается на частных издателей,
часто оказывающих значительную помощь разработчикам.
3.2. МАРКЕТИНГОВАЯ ДОКУМЕНТАЦИЯ
Используется для рекламы как самого программного продукта и его составляющих, так и других программных продуктов компании. Она часто информирует покупателя о свойствах продукта, объясняет его преимущества
перед конкурирующими решениями. Часто бывает так, что именно коробка
продукта и другая маркетинговая информация дают самое чёткое и простое
представление о способах использования и возможностях программы.
Стандарты для разработки ПО. Основой для создания любой доку-
ментации на программные продукты служат стандарты.
Современных стандартов по разработке технической документации для
программного обеспечения в Российской Федерации до сих пор нет ещё со
времён СССР, хотя стандарты и модернизируются. Последнее обновление –
ГОСТ 2.015–2013.
В таких условиях IT-компании вопрос разработки документации для
программного обеспечения решают по-разному. Одни пытаются копировать
и внедрять западные стандарты. другие – использовать отечественные, третьи – создают свои собственные.
Актуальные вопросы при разработке документации ПО. В любом
случае актуальными при разработке технической документации для программного обеспечения будут такие основные вопросы:
• какова нормативная база и как её следует применять?
• какая именно документация нужна среди огромного количества до-
кументов?
Остановимся на этих вопросах подробнее.
В настоящее время действуют следующие стандарты документирования:
ГОСТ 19.201 (Единая система программной документации (ЕСПД));
ГОСТ 2.015–2013 (Единая система конструкторской документации (ЕСКД));
ГОСТ 34.602 (Комплекс стандартов на автоматизированные системы
(КСАС)).
Указанные стандарты с 2006 г. применять необязательно. В соответствии с нормами Федерального закона № 184-ФЗ «О техническом регулировании» вместо стандартов применяются специально разработанные технические регламенты. Но ГОСТы по-прежнему нужно применять при разработке
35
документации для государственных заказчиков, а также для крупных организаций (особенно с государственным участием). Последние, как правило, разрабатывают собственные стандарты на основе указанных ГОСТов.
Следует также помнить, что в соответствии с ФЗ «О техническом регулировании» национальные стандарты имеют всегда приоритет над международными. Таким образом, использовать международные стандарты можно
лишь в случаях, если последние не противоречат национальным! Благо, свободы действий отечественные стандарты предоставляют намного больше
зарубежных. Последние пересматриваются каждые 5 – 7 лет и характеризуются большей конкретизацией, но отображают весь актуальный опыт за указанный период времени. Отечественные же (не имея столь разработанной
конкретики) характеризуются глубокой разработкой концептуальных моментов. Это позволяет создавать на их основе неплохие стандарты в соответствии с требованиями времени.
3.3. ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Основным документом на создание программного продукта является
технические задание, которое используется для разработки (проектирования)
программы и её испытания.
В ТЗ устанавливается назначение программного продукта, что разрабатывается, его технические характеристики, качество и технико-экономические показатели, а также указания по выполнению стадий документации
(конструкторской, программной, технологической и т.п.), её состав и другие
специальные требования.
Техническое задание – это юридический документ, который в качестве
приложения включается в договор на выполнение проектных работ по созданию программы и является основой такого договора.
ТЗ может быть выполнено как в качестве эскизного проекта (описываются структура системы и её функции без технологий реализации решения),
так и в форме технического проекта (детальное описание выбранной технологии реализации проекта). ТЗ может составляться также в общих чертах
(для инвесторов, к примеру) и с самой подробной детализацией (для программистов и в иных случаях).
Часто ТЗ является единственным документом для описания разрабатываемого программного продукта. В таких случаях особо важно, чтобы оно
разрабатывалось и изготовлялось профессионалами.
3.4. ОПИСАНИЕ ТРЕБОВАНИЙ
К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
Любая программная система создаётся для решения одной или нескольких проблем будущих пользователей программной системы. Программа – это
ни что иное, как некоторый алгоритм, заложенный в компьютер для решения
определённого круга задач, работа которого должна принести пользователю
ощутимый результат.
36
Здесь кроется одна из проблем разработки программного обеспечения (ПО). Программисты и пользователи говорят на разных языках. Программисты знают, как писать программы, а пользователи знают, или, по
крайней мере, должны знать, что должна делать для них программа. Однако
пользователи – не идеальный источник информации. Большинство пользователей знают, как выполнять свою работу, однако далеки от понятия того, как
переложить всё это на компьютер и часто не могут изложить свои требования
к будущей системе.
Традиционный подход решения этой проблемы – это поручение определения требования аналитикам, которые проводят с пользователями интервью,
выявляя их реальные потребности. Но даже аналитикам трудно получить непротиворечивый и в дальнейшем мало изменяемый список требований, если
не использовать систематизированный подход к определению требований.
Основная цель рабочего процесса определения требований состоит в
том, чтобы направить процесс разработки на получение правильной системы.
А правильная система – это система, которая делает то, что необходимо и
ничего более. Конечно, нашим программистам трудно делать систему так,
чтобы ничего от себя не приложить, и тем более ничего не забыть. Описание
требований должно быть достаточно хорошим, для того чтобы между пользователями и разработчиками могло быть достигнуто понимание того, что
система должна делать и чего не должна. В противном случае пользователи
будут считать, что система может сделать для них всё, а программисты не
будут понимать, какие функции будущей системы обязательно должны будут
включены в первую версию, и без них нельзя обойтись, а какие можно отложить до будущего релиза.
Можно определить следующие шаги рабочего процесса определения
требований:
• перечисление возможных требований;
• осознание контекста системы;
• определение функциональных требований;
• определение нефункциональных требований;
• перечисление возможных требований.
Первое, что нужно сделать – это начать собирать всевозможные требования и идеи насчёт будущей системы. Это будет несистематизированный
список, в который должно попасть всё, что касается системы и приходит
в голову разработчикам, аналитикам и пользователям. Эти идеи будут кандидатами на реализацию в будущих версиях системы и используются для планирования работ.
Каждое предложение в списке должно иметь короткое название и краткое описание, в чём оно состоит, также для дальнейшей работы необходима
дополнительная информация для планирования и последующей реализации
требований, в которые могут входить:
• состояние предложения (например, предложено, одобрено, включено
в план, утверждено);
37
• трудоёмкость в человеко-часах или стоимость реализации;
• приоритет (например, критический, важный или вспомогательный);
• уровень риска, связанного с реализацией предложения (например,
критический, значительный или обычный).
Этот список в ходе работ может уменьшаться, когда требования преобразуются в другие артефакты, например – варианты использования или нефункциональные требования, и увеличиваться, когда выдвигаются новые
предложения.
Осознание контекста системы. Для того чтобы верно определить тре-
бования, разработчики системы должны понимать контекст (часть предметной области), в котором работает система. Существует по крайней мере два
подхода к описанию контекста системы:
1) моделирование предметной области;
2) бизнес-моделирование.
Модель предметной области описывает важные понятия предметной
области и их связи между собой. Нельзя путать модель предметной области с
логической и физической моделями системы. Модель предметной области
описывает только объекты предметной области, но не показывает, как программная система будет с ними работать. Данная модель также позволяет
составить глоссарий системы для лучшего её понимания пользователями и
разработчиками.
Бизнес-модель описывает процессы (существующие или будущие), ко-
торые должна поддерживать система. Бизнес-модель можно представить как
подмножество модели предметной области. Кроме определения бизнесобъектов, вовлечённых в процесс, эта модель определяет работников, их обязанности и действия, которые они должны выполнять.
Определение функциональных требований. Подход к выявлению
системных требований основан на использовании вариантов использования
системы (Use Cases), которые охватывают как функциональные, так и нефункциональные требования, которые специфичны для конкретного варианта
использования.
Для пользователя важно, чтобы система выполняла определённые действия для него, при этом пользователь определённым образом взаимодействует с
системой, использует её для своих целей. Таким образом, если определить все
возможные варианты использования системы пользователями или другими
внешними процессами, то мы получим функциональные требования к ней.
Однако каждый конкретный пользователь работает с системой посвоему, поэтому для определения действительных вариантов использования
системы необходимо досконально знать потребности всех заинтересованных
пользователей, провести анализ полученной информации и систематизировать её в действительные варианты использования системы, т.е. абстрагироваться от конкретных пользователей и исходить от бизнес-задач.
38
В дополнение к вариантам использования необходимо определить, как
должен выглядеть пользовательский интерфейс для реализации того или иного варианта использования; набросать эскизы, обсудить их с пользователями,
создать прототипы и отдать их на тестирование пользователям.
Определение нефункциональных требований. К нефункциональным
требованиям относятся такие свойства система, как ограничения среды и
реализации, производительность, зависимость от платформы, расширяемость, надёжность и т.д. Под надёжностью понимаются такие характеристики, как пригодность, точность, средняя наработка на отказ, число ошибок на
тысячу строк программы, число ошибок на класс.
Требования по производительности – это скорость, пропускная способность, время отклика, используемая память. Многие требования, связанные с
производительностью должны быть описаны в конкретных вариантах использования, а не в разделе относящейся ко всей системе.
Также можно отметить, что часто нефункциональные требования не могут быть привязаны к конкретному варианту использования и должны быть
вынесены в отдельный список дополнительных требований к системе.
39
4. РАЗРАБОТКА ДОКУМЕНТАЦИИ
ПРОГРАММНЫХ СРЕДСТВ И ЕЁ СТАНДАРТИЗАЦИЯ
4.1. ПРОЦЕСС ДОКУМЕНТИРОВАНИЯ
Возрастающие масштабы применения программных средств и их сложность вызывают необходимость в полной, точной и понятной документации
на программное средство, доступной пользователям. Часто документация
разрабатывается после создания соответствующего программного средства.
Однако с точки зрения её качества необходимо, чтобы она создавалась в процессе разработки программного средства.
Процесс документирования программных средств и систем регламентирует международный стандарт ISO/IEC 12207:1995 и его аутентичный аналог
СТБ ИСО/МЭК12207–2003 [1, 8].
В данном стандарте процесс документирования определяется как процесс формализованного описания информации, созданной в процессе или
работе жизненного цикла.
Процесс документирования включает планирование, проектирование,
разработку, выпуск, редактирование, распространение и сопровождение документов по программному продукту.
В соответствии с ИСО/МЭК 12207 процесс документирования состоит
из четырёх работ (рис. 4.1) и семи задач (работы в списке указаны слева,
задачи справа):
• подготовка процесса документирования:
− разработка и реализация плана обозначения документов, выпускае-
мых в процессах жизненного цикла программных средств;
• проектирование и разработка (документации):
− проектирование документов согласно стандартам на документацию;
− подтверждение источника и соответствия исходных матер
документов;
ПО СТАНДАРТУ ISO/IEC 12207:1995
иалов для
40
Рис. 4.1. Структура процесса документирования в соответствии
с СТБ ИСО/МЭК 12207–2003