Материал: для поступления в магистратуру

111

способность удовлетворять заданные потребности пользователей.

Качество ПС является удовлетворительным, когда оно обладает указанными свойствами в такой степени, чтобы гарантировать успешное его использование.

Критерии качества ПС:

-функциональность,

-надежность,

-легкость применения,

-эффективность,

-сопровождаемость,

-мобильность.

Функциональность - это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС.

ЛегкостьпримененияэтохарактеристикиПС,которыепозволяютминимизироватьусилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя.

Эффективность - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов.

Сопровождаемость - это характеристики ПС, которые позволяют минимизировать усилия по внесению изменений для устранения в нем ошибок и по его модификации в соответствии с изменяющимися потребностями пользователей.

Мобильность - это способность ПС быть перенесенным из одной среды (окружения) в другую, в частности, с одной ЭВМ на другую.

Обязательные критерии качества: функциональность и надежность.

Групповая разработка, управление версиями, организация коллектива разработчиков, документирование

Системы управления версиями — это программное обеспечение, помогающее отслеживанию изменений, внесенных в код с течением времени. Когда разработчик редактирует код,системауправленияверсиямисоздаетмоментальныйснимокфайлов.Затемэтотмоментальный снимок сохраняется, чтобы при необходимости им было можно воспользоваться позже.

Без контроля версий разработчики могут удерживать на своем компьютере несколько копий кода. Это опасно, так как можно легко изменить или удалить файл в неправильной копии кода, что может привести к потере работы. Системы управления версиями решают эту проблему, управляя всеми версиями кода, но Выполнив рабочую группу с одной версией за раз.

Рабочие процессы управления версиями предотвращают Chaos всех пользователей, использующих собственный процесс разработки с различными и несовместимыми средствами. Системы управления версиями обеспечивают принудительную обработку и разрешения, чтобы все пользователи оставались на одной странице.

Каждая версия имеет описание того, что делают изменения в версии, например исправление ошибки или добавление функции. Эти описания помогают команде отслеживать изменения в коде по версии, а не по отдельным изменениям файла. Код, хранящийся в версиях, можно в любой

112

момент при необходимости просмотреть и восстановить из системы управления версиями. Это позволяет легко создать новую работу с любой версией кода.

Управление версиями синхронизирует версии и гарантирует, что изменения не конфликтуют с другими изменениями других. Группа использует систему управления версиями для устранения конфликтов, даже если пользователи делают изменения одновременно.

Управление версиями сохраняет историю изменений по мере того, как команда сохраняет новые версии кода. Этот журнал позволяет узнать, кто, зачем и когда внес изменения. Журнал дает группам уверенность в экспериментах, так как в любое время можно легко выполнить откат до предыдущей хорошей версии. Журнал позволяет любому пользователю выполнять базовые операции из любой версии кода, например для исправления ошибки в предыдущем выпуске.

Функции автоматизации системы управления версиями сохраняют время и создают противоречивые результаты. Автоматизируйте тестирование, анализ кода и развертывание, сохраняя новые версии в системе управления версиями.

Когда проектная команда включает более двух человек неизбежно встает вопрос о распределении ролей, прав и ответственности в команде. Конкретный набор ролей определяется многими факторами - количеством участников разработки и их личными предпочтениями, принятой методологией разработки, особенностями проекта и другими факторами. Практически в любом коллективе разработчиков можно выделить перечисленные ниже роли. Некоторые из них могут вовсе отсутствовать, при этом отдельные люди могут выполнять сразу несколько ролей, однако общий состав меняется мало.

Заказчик (заявитель). Эта роль принадлежит представителю организации, заказавшей разрабатываемуюсистему.Обычнозаявительограниченвсвоемвзаимодействиииобщаетсятолько с менеджерами проекта и специалистом по сертификации или внедрению. Обычно заказчик имеет право изменять требования к продукту (только во взаимодействии с менеджерами), читать проектную и сертификационную документацию, затрагивающую нетехнические особенности разрабатываемой системы.

Менеджер проекта. Эта роль обеспечивает коммуникационный канал между заказчиком и проектной группой. Менеджер продукта управляет ожиданиями заказчика, разрабатывает и поддерживает бизнес-контекст проекта. Его работа не связана напрямую с продажей, он сфокусирован на продукте, его задача - определить и обеспечить требования заказчика. Менеджер проекта имеет право изменять требования к продукту и финальную документацию на продукт.

Менеджер программы. Эта роль управляет коммуникациями и взаимоотношениями в проектной группе, является в некотором роде координатором, разрабатывает функциональные спецификации и управляет ими, ведет график проекта и отчитывается по состоянию проекта, инициирует принятие критичных для хода проекта решений.

Менеджер программы имеет право изменять функциональные спецификации верхнего уровня, план-график проекта, распределение ресурсов по задачам. Часто на практике роль менеджера проекта и менеджера программы выполняет один человек.

Разработчик. Разработчик принимает технические решения, которые могут быть реализованы и использованы, создает продукт, удовлетворяющий спецификациям и ожиданиям заказчика, консультирует другие роли в ходе проекта. Он участвует в обзорах, реализует возможности продукта, участвует в создании функциональных спецификаций, отслеживает и исправляет ошибки за приемлемое время. В контексте конкретного проекта роль разработчика может подразумевать, например, инсталляциюпрограммного обеспечения, настройку продуктаили услуги. Разработчик имеет доступ ко всей проектной документации, включая документацию по тестированию, имеет право на изменение программного кода системы в рамках своих служебных обязанностей.

Специалист по тестированию. Специалист по тестированию определяет стратегию тестирования, тест-требования и тест-планы для каждой из фаз проекта, выполняет тестирование системы, собирает и анализирует отчеты о прохождении тестирования. Тест-требования должны покрывать системные требования, функциональные спецификации, требования к надежности и нагрузочной способности, пользовательские интерфейсы и собственно программный код. В реальности роль специалиста по тестированию часто разбивается на две - разработчика тестов и

113

тестировщика. Тестировщик выполняет все работы по выполнению тестов и сбору информации, разработчик тестов - всю остальные работы.

Специалист по контролю качества. Эта роль принадлежит члену проектной группы, который осуществляет взаимодействие с разработчиком, менеджером программы и специалистами по безопасности и сертификации с целью отслеживания целостной картины качества продукта, его соответствия стандартам и спецификациям, предусмотренным проектной документацией. Следует различать специалиста по тестированию и специалиста по контролю качества. Последний не является членом технического персонала проекта, ответственным за детали и технику работы. Контроль качества подразумевает в первую очередь контроль самих процессов разработки и проверку их соответствия определенным в стандартах качества критериям.

Специалист по сертификации. При разработке систем, к надежности которых предъявляются повышенные требования, перед вводом системы в эксплуатацию требуется подтверждение со стороны уполномоченного органа (обычно государственного) соответствия ее эксплуатационных характеристик заданным критериям. Такое соответствие определяется в ходе сертификации системы. Специалист по сертификации может либо быть представителем сертифицирующих органов, включенным в состав коллектива разработчиков, либо наоборот - представлять интересы разработчиков в сертифицирующем органе. Специалист по сертификации приводит документацию на программную систему в соответствие требованиям сертифицирующего органа либо участвует в процессе создания документации с учетом этих требований. Также специалист по сертификации ответственен за все взаимодействие между коллективом разработчиков и сертифицирующим органом. Важной особенностью роли является независимость специалиста от проектной группы на всех этапах создания продукта. Взаимодействие специалиста с членами проектной группы ограничивается менеджерами по проекту и по программе.

Специалист по внедрению и сопровождению. Участвует в анализе особенностей площадки заказчика, на которой планируется проводить внедрение разрабатываемой системы, выполняет весь спектр работ по установке и настройке системы, проводит обучение пользователей.

Специалист по безопасности. Данный специалист ответственен за весь спектр вопросов безопасности создаваемого продукта. Его работа начинается с участия в написании требований к продукту и заканчивается финальной стадией сертификации продукта.

Инструктор. Эта роль отвечает за снижение затрат на дальнейшее сопровождение продукта, обеспечение максимальной эффективности работы пользователя. Важно, что речь идет о производительности пользователя, а не системы. Для обеспечения оптимальной продуктивности инструктор собирает статистику по производительности пользователей и создает решения для повышения производительности, в том числе с использованием различных аудиовизуальных средств. Инструктор принимает участие во всех обсуждениях пользовательского интерфейса и архитектуры продукта.

Технический писатель. Лицо, осуществляющее эту роль, несет обязанности по подготовке документации к разработанному продукту, финального описания функциональных возможностей. Также он участвует в написании сопроводительных документов (системы помощи, руководство пользователя).

Документация, создаваемая на различных этапах жизненного цикла

Синхронизация всех этапов разработки происходит при помощи документов, которые создаются на каждом из этапов. Документация при этом создается и на прямом отрезке жизненного цикла - при разработке программной системы, и на обратном - при ее верификации. Попробуем на примере V-образного жизненного цикла проследить, какие типы документов создаются на каждом из отрезков и какие взаимосвязи между ними существуют (Рис 1.8).

Результатом этапа разработки требований к системе являются сформулированные требования к системе: документы, описывающие общие принципы работы системы, ее взаимодействие с "окружающей средой" - пользователями системы, а также, программными и аппаратными средствами, обеспечивающими ее работу. Обычно параллельно с требованиями к системе создается план верификации и определяется стратегия верификации. Эти документы определяют общий подход к тому, как будет выполняться тестирование, какие методики будут применяться, какие аспекты будущей системы должны быть подвергнуты тщательной проверке. Еще одна задача,

114

решаемая при помощи определения стратегии верификации - определение места различных верификационных процессов и их связей с процессами разработки.

Верификационный процесс, работающий с системными требованиями - это процесс валидации требований, сопоставления их реальным ожиданиям заказчика. Забегая вперед, скажем, что процесс валидации отличается от приемо-сдаточных испытаний, выполняемых при передаче готовой системы заказчику, хотя может считаться частью таких испытаний. Валидация является средством доказать не только корректность реализации системы с точки зрения заказчика, но и корректность принципов, положенных в основу ее разработки.

Рис. 1.8. Процессы и документы при разработке программных систем

Требования к системе являются основой для процесса разработки функциональных требований и архитектуры проекта. В ходе этого процесса разрабатываются общие требования к программному обеспечению системы, к функциям, которые она должна выполнять. Функциональные требования часто включают в себя определение моделей поведения системы в штатных и нештатных ситуациях, правила обработки данных и определения интерфейса пользователя. Текст требования, как правило, включает в себя слова "должна, должен" и имеет структурувида"Вслучае,еслизначениетемпературынадатчикеABC достигает30ивышеградусов Цельсия, система должна прекращать выдачу звукового сигнала". Функциональные требования являются основой для разработки архитектуры системы - описания ее структуры в терминах подсистем и структурных единиц языка, на котором производится реализация - областей, классов, модулей, функций и т.п.

На базе функциональных требований пишутся тест-требования - документы, содержащие определение ключевых точек, которые должны быть проверены для того, чтобы убедиться в корректности реализации функциональных требований. Часто тест-требования начинаются словами "Проверить, что" и содержат ссылки на соответствующие имфункциональные требования. Примером тест-требований для приведенного выше функционального требования могут служить "Проверить, что в случае падения температуры на датчике ABC ниже 30 градусов Цельсия система выдает предупреждающий звуковой сигнал" и "Проверить, что в случае, когда значение температуры на датчике ABC выше 30 градусов Цельсия, система не выдает звуковой сигнал".

Одна из проблем, возникающая при написании тест-требований - принципиальная нетестируемость некоторых требований: например, требование "Интерфейс пользователя должен быть интуитивно понятным" невозможно проверить без четкого определения того, что является

115

интуитивно понятным интерфейсом. Такие неконкретные функциональные требования обычно впоследствии видоизменяют.

Архитектурные особенности системы также могут служить источником для создания тесттребований, учитывающих особенности программной реализации системы. Примером такого требования является, например, "Проверить, что значение температуры на датчике ABC не выходит за 255".

На основе функциональных требований и архитектуры пишется программный код системы, для его проверки на основе тест-требований готовится тест-план - описание последовательности тестовых примеров, выполняющих проверку соответствия реализации системы требованиям. Каждый тестовый пример содержит конкретное описание значений, подаваемых на вход системы, значений, которые ожидаются на выходе, и описание сценария выполнения теста.

Взависимости от объекта тестирования тест-план может быть подготовлен либо в виде программы на каком-либо языке программирования, либо в виде входного файла данных для инструментария, который выполняет тестируемую систему и передает ей значения, указанные в тест-плане, либо в виде инструкций для пользователя системы, описывающей необходимые действия, которые нужно выполнить для проверки различных функций системы.

Врезультате выполнения всех тестовых примеров собирается статистика об успешности прохождения тестирования - процент тестовых примеров, для которых реальные выходные значения совпали с ожидаемыми, так называемых пройденных тестов. Не пройденные тесты являются исходными данными для анализа причин ошибок и последующего их исправления.

На этапе интеграции осуществляется сборка отдельных модулей системы в единое целое и выполнение тестовых примеров, проверяющих всю функциональность системы.

На последнем этапе осуществляется поставка готовой системы заказчику. Перед внедрением специалисты заказчика совместно с разработчиками проводят приемо-сдаточные испытания - выполняют проверку критичных для пользователя функций согласно заранее утвержденной программе испытаний. При успешном прохождении испытаний система передается заказчику, в противном случае отправляется на доработку.

Структурное проектирование, CASE-средства, реинжиниринг программных систем

Структурное программирование – это процесс пошагового разбиения алгоритма на все более мелкие части, с целью получить такие элементы, для которых можно легко написать конкретные предписания.

Два принципа структурного программирования:

1.последовательная детализация «сверху – вниз»

2.ограниченность базового набора структур для построения алгоритмов любой степени

сложности Требования структурного программирования:

1.программа должна составляется мелкими шагами, таким образом, сложная задача разбивается на достаточно простые, легко воспринимаемые части.

2.логика программы должна опираться на минимальное число достаточно базовых управляющих структур (линейные, разветвляющиеся и циклические структуры)

Основные свойства и достоинства структурного программирования:

1.уменьшение сложности программ

2.возможностьдемонстрацииправильностипрограммнаразличныхэтапахрешениязадачи

3.наглядность программ

4.простота модификации (внесения изменения) программ.

Современные средства программирования должны обеспечивать максимальную защиту от возможных ошибок разработчика.

Тут можно провести аналогию с развитием методов управления автотранспортом. Сначала безопасность обеспечивалась за счет разработки правил движения. Затем появилась система