CC BY
82
темного тестирования. Системное тестирование ПИ проводится с целью обнаружения дефектов в нем, а также выявления его работоспособности и надежности защиты от неумелых действий пользователя. Кроме того, выясняется степень соответствия ПИ требованиям заказчика и сопроводительным документам (руководству пользователя, инструкции по установке и т.п.).
Обычно фаза {5} начинается с участия одного из системных тестировщиков (или руководителя группы системного тестирования) в обсуждении планов по проекту ПИ и в составлении спецификаций требований заказчика. В начале фазы {5} создается согласованный с основными вехами проектного плана план системного тестирования. Само системное тестирование осуществляется циклически в соответствии с процедурой системного тестирования (ПСТ). ПСТ - это документ, определяющий критерии успешного завершения всех видов системного тестирования и последовательность шагов, обеспечивающих многократный запуск ручных тестов и автоматизированных тестовых комплектов. Началом цикла системного тестирования служит момент поступления сборки базовой версии ПИ для системного тестирования, а его концом - получение отчета о завершении одного выполнения всех тестов и тестовых комплектов, предусмотренных ПСТ. Продолжительность цикла системного тестирования, как правило, не должна превышать одного месяца, а по каждой сборке базовой версии ПИ планируется не менее трех циклов системного тестирования.
Заключительная фаза. Фаза {6} является заключительной в разработке ПИ, на ней заканчиваются все работы по проекту ПИ, осуществляется сдача разработанного ПИ заказчику и проводится ретроспективный обзор проекта в целом.
Сопровождение ПИ - это процесс адаптации поставленного ПИ к новым условиям использования с сохранением его функциональных свойств. При
сопровождении ПИ обычно производится его исправление, не затрагивающее функционального назначения ПИ и включающее в себя локализацию и устранение обнаруженных дефектов в программных модулях ПИ, переработку интерфейсных программных модулей, модификацию кодов, документации или структуры баз данных ПИ и т.п. В результате сопровождения может возникнуть необходимость обновления ПИ, приводящего к изменениям функциональных возможностей. В этом случае следует подавать заявки на его изменение на предприятие, поставляющее ПИ. Изменение ПИ осуществляется по специальной процедуре.
В заключение отметим, что для каждого нового проекта ПИ, выполняемого в АОЗТ "Информационные деловые услуги" (г.Санкт-Петербург), определялась модель ЖЦ по приведенной в статье процедуре. Именно это и использование изложенного набора описаний, определяющих важнейшие этапы ЖЦ ПИ и взаимосвязи между ними, позволили выполнить более 10 проектов ПИ с качеством 5 сигма [2] в сроки, установленные контрактами с конкретными заказчиками, без превышения выделенных средств.
Список литературы
1. Humphrey G. Managing the Software Process - Reading: Addison-Wesley, 1989. - 494 p.
2. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Процесс разработки программных изделий. - М.: Наука, Физматлит. - 2000. - 176 с.
3. Brooks F.P.Jr. The Mythical Man-Month. - S.L.: Addison-Wesley, 1975. Русский перевод: Брукс Ф.П. (мл.) Как проектируются и создаются программные комплексы (Серия: Библиотека программиста). - М.: Наука, 1979. - 152 с.
4. Леман М.М. Программы, жизненные циклы и законы эволюции программного обеспечения //ТИИЭР /Пер. с англ. -1980. - Т.68. - №9. - С.26-45.
5. Myers G.J. The Art of Software Testing. - New York: John Wiley & Sons, 1979. - 177 p.
6. Никифоров В.В., Домарацкий Я.А. //Программные продукты и системы. - 1998. - №4. - С. 40-43.
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНЫХ ИЗДЕЛИЙ
А.Н. Домарацкий, Н.К. Ласточкин
Технологический процесс технической разработки программных изделий (технология разработки ПИ) является одним из ключевых процессов при их производстве. От его совершенства и неукоснительного соблюдения зависят практически все свойства поставляемого ПИ. Современная технология разработки ПИ базируется на предписаниях процесса, который построен в соответствии с международными рекомендациями [1-3]. В нашей стране пока еще не получила широкого распространения разработка ПИ по правилам процесса. В этой связи нам представляется полезным ознакомление читателей журнала с опытом, который мы накопили в течение последних семи лет, выполняя контракты заказчика по разра-
ботке ПИ по установленному процессу [4]. В АОЗТ "Информационные деловые услуги" (г. Санкт-Петербург) процесс разработан в соответствии с рекомендациями СММ [1].
Описание технологии разработки ПИ на каждом предприятии, занятом производством ПИ, представляет собой наиболее важный документ для внутреннего пользования. В этом документе обычно описываются установленные процедуры, стандарты и собственные находки по разработке ПИ. Он, как правило, недоступен для постороннего ока. Для облегчения понимания того, что содержат в себе подобные документы, сначала приведем авторизованный перевод соответствующего раздела из [1], а во второй
7
части статьи дадим описание фрагмента нашего шаблона для спецификации требований заказчика. Приведенный фрагмент шаблона не претендует на роль эталона, однако его использование показало действенность принятых ограничений и позволило выполнить в срок с качеством 5 сигма [4] более 10 проектов ПИ.
Ключевая область СММ
«Технология разработки»
Целью ключевой области является развитие способностей предприятия к определению, интегрированию и результативному исполнению задач технологического процесса разработки ПИ. Такой процесс обусловливает от начала до конца всю технологическую деятельность по эффективному созданию качественных ПИ, включая выполнение задач по технической разработке ПИ. Кроме того, технологический процесс определяет все необходимые стандарты, методы и средства разработки ПИ.
Технология разработки ПИ определяет порядок выполнения таких задач, как анализ и составление требований к ПИ, разработка архитектуры программной системы, ее высокоуровневое и детальное проектирование. К задачам технологии разработки относятся также создание программных кодов компонентов ПИ, модульное и интеграционное тестирование, тестирование работоспособности и системное тестирование ПИ.
Технология разработки регламентирует формы и процедуры создания документации, необходимой для выполнения задач разработки ПИ. К такой документации относятся спецификации требований к ПИ, спецификации высокоуровневого и детального проектирования, планы и процедуры тестирования и т.д.
Технология разработки устанавливает процедуру проведения обзоров продуктов проекта. Обзоры проводятся для обеспечения гарантии их качества, гарантии того, что каждая последующая задача разработки ПИ решается на основе результатов, полученных при решении предшествующих задач. А полученные текущие результаты необходимы для решения последующих задач (включая задачи эксплуатации и сопровождения ПИ).
Правила реализации ключевых приемов. Каждый проект должен следовать документированной организационной политике. Такая политика обычно подразумевает, что задачи технологии разработки ПИ выполняются в соответствии с проектным процессом, полученным путем подгонки стандартного процесса [1-3], а для разработки и сопровождения ПИ используются установленные методы и средства. При этом планы решения отдельных задач создаются в строгом соответствии с установками проектного процесса.
Условия реализации ключевых приемов. Для
выполнения задач технологии разработки ПИ предоставляются все необходимые ресурсы. К таким ресурсам относятся сотрудники, квалификация которых позволяет осуществлять составление требований к ПИ и их анализ, выполнять высокоуровневое и детальное проектирование, кодирование, тестирование,
отладку и сопровождение ПИ. К ресурсам принадлежат также инструментальные средства для выполнения задач технологии разработки ПИ. Это - системы управления базами данных, различные графические средства, средства отслеживания, инструментальные средства моделирования и создания прототипов и т.п., а также языки и системы программирования, редакторы, компиляторы, генераторы тестов, анализаторы охвата тестами кода ПИ и т.п.
Технический персонал, вовлеченный в реализацию задач технологии разработки ПИ, должен пройти дополнительное обучение. Примерами подготовки может служить освоение правил составления требований к ПИ, методов, соглашений и стандартов, выбранных согласно проектному процессу для анализа требований к ПИ, изучение концепции проектирования. К примерам обучения можно отнести также освоение новых языков программирования и стандартов кодирования, методики модульного и интеграционного тестирования, приемы системного тестирования и т.п.
Технический персонал, реализующий задачи технологии разработки ПИ, должен получать дополнительные знания в смежных дисциплинах. К таким дисциплинам относится, например, управление конфигурацией ПИ, оценка качества продуктов проекта, способы улучшения стандартного и проектного процессов и т.п.
Руководители проекта всех рангов должны получить дополнительные знания в технических аспектах проекта ПИ (например, предметная область, для которой разрабатывается ПИ, инструментальные средства и методы технологии разработки ПИ, успехи, достигнутые в разработке ПИ, руководство по управлению проектом с использованием выбранных методов и средств и т.д.).
Деятельность по реализации ключевых приемов. В соответствии с формальной процедурой определяются и интегрируются задачи, методы и инструментальные средства технологии разработки ПИ. Такая процедура предписывает, что технологические задачи по разработке ПИ создаются в строгом соответствии с требованиями заказчика к ПИ, а созданные задачи интегрируются в единую технологию по директивам проектного процесса. Методы и инструментальные средства, необходимые для успешного применения технологии разработки ПИ выбираются исходя из стандартов, определенных проектным процессом, из требований контракта, простоты их использования и наличия сервисного обслуживания. При этом учитывается уровень квалификации участников проекта и возможность их переподготовки. Обоснование выбора отдельных методов и инструментальных средств документируется, обозревается и сохраняется. Инструментальные средства разработки ПИ помещаются в систему конфигурационного управления.
По формальной процедуре разрабатываются спецификации требований к ПИ, они документируются и систематически проверяются путем их анализа. Процедура устанавливает, что сотрудники, вовлеченные в разработку спецификаций требований к
8
ПИ, анализируют их с целью выявления и разрешения неоднозначностей и сомнительных мест в их описании. Требования к ПИ охватывают функциональные требования, требования к составу и структуре ПИ, к его компонентам и отдельным модулям, а также к программированию, к организации данных, интерфейсам, среде окружения, выходным документам и т.д. Для анализа требований используются эффективные методы. Примерами методов для анализа требований могут служить функциональная декомпозиция, объектно-ориентированная декомпозиция, имитация, моделирование, создание прототипов, генерация сценариев. Результаты анализа требований и обоснование выбранной альтернативы документируются. Требования к ПИ подвергаются анализу системными тестировщиками, которые устанавливают, что они ясно сформулированы и выполнимы, согласованы друг с другом и тестируемы. Методы проверки и обоснования того, что каждое требование к ПИ выполнимо, документируются. Примерами методов проверки и обоснования выполнимости могут служить демонстрация, тестирование выполнимости отдельных функций ПИ, анализ полноты и т.п. Требования к ПИ документируются и обозреваются с целью их улучшения (повышения обозримости). В обзорах участвуют руководители проектов и руководители разработки ПИ, руководитель независимой группы системного тестирования и другие компетентные сотрудники. Спецификации требований к ПИ обозреваются и утверждаются заказчиком, а также изменяются по указанию заказчика в соответствии с директивами проектного процесса. Документ с требованиями заказчика к ПИ помещается в систему конфигурационного управления.
На основе спецификаций требований к ПИ по формальной процедуре осуществляется проектирование ПИ. Эта процедура, как правило, регламентирует, что процесс проектирования состоит из двух этапов - высокоуровневого и детального проектирования. Результат проектирования состоит также из двух частей - архитектуры ПИ (компоненты ПИ и взаимосвязи между ними) и спецификаций детального проектирования (алгоритмы реализации отдельных функций, интерфейсы, структуры данных и т.п.). Разрабатываются, обозреваются и документируются критерии приемлемости результатов проектирования. Примерами таких критериев может служить корректность выполнения функции, удовлетворение принятому стандарту, простота конструкции и т.п. Там, где это разумно, необходимо применять стандарты. Например, стандарты для интерфейсов системы, для интерфейса человек-машина, для интерфейса телекоммуникаций и т.п.
Для конструирования ПИ выбираются, обозреваются и документируются соответствующие методы. К таким методам можно отнести создание прототипов, структурное моделирование, повторное использование конструкций, объектно-ориентированное конструирование и т.п. Архитектура ПИ разрабатывается на ранней стадии проекта в рамках ограничений, установленных моделью жизненного цикла ПИ и принятой технологией. Архитектура устанав-
ливает высокоуровневую структуру ПИ и определяет внутренний и внешний интерфейсы. Разработанная архитектура ПИ документируется и обозревается с целью определения ее соответствия требованиям заказчика, полноты и достаточности для реализации детальной разработки.
По результатам высокоуровневого проектирования осуществляется детальная разработка всех определенных компонентов ПИ. Все результаты проектирования документируются в виде спецификаций, которые затем подвергаются обзору с целью выявления и устранения отклонений и недостатков. Спецификации проектирования помещаются в систему конфигурационного управления и изменяются всякий раз, когда изменяются требования заказчика к ПИ.
Код ПИ разрабатывается, документируется и проверяется в соответствии с формальной процедурой. Эта процедура определяет, что создание программного кода ПИ осуществляется путем преобразования спецификаций высокоуровневого и детального проектирования в коды программ. Для этого определяются и документируются системы программирования, методы, стандарты программирования и кодирования. Примерами методов программирования могут служить, например, структурное программирование, повторное использование кода и т.п. Последовательность разработки кода программных модулей, реализуется по плану, который создается в соответствии с директивами проектного процесса. Каждый программный модуль подвергается тщательному обзору и тестированию с целью обнаружения и устранения отклонений. Программный код помещается в систему конфигурационного управления и изменяется всякий раз, когда изменяются требования к ПИ или его архитектура.
В соответствии с формальной процедурой выполняется тестирование ПИ. Такая процедура обусловливает разработку критериев завершения тестирования, которые документируются, обозреваются заказчиком и всеми заинтересованными лицами, участвующими в проекте ПИ. Определяются, документируются, обозреваются и применяются виды тестирования (например, модульное и интеграционное тестирование, тестирование работоспособности ПИ и его системное тестирование). Могут быть установлены и виды системного тестирования (функциональное, сценарное тестирование, тестирование защиты от неумелых действий пользователя и т.д.). Определяется, документируется, обозревается стратегия тестирования. Например, функциональная (стратегия черного ящика), структурная (стратегия белого ящика), статистическая стратегия. Вводятся, документируются и обозреваются критерии готовности тестов и зона достижения тестами кодов ПИ, например, зона охвата тестами кодов ПИ, путь или ветви тестирования, профиль тестирования. Выполняется повторное тестирование в каждом виде тестирования всякий раз, когда производятся изменения в ПИ или в среде его окружения. Планы и процедуры тестирования и состояние тестов подвергаются тщательному обзору до того, как их передают для использования, а также они управляются и контролируются. Если
9
необходим более строгий контроль, то все тестовое хозяйство может быть помещено в систему конфигурационного управления. Планы тестирования и процедуры тестирования изменяются всякий раз, когда изменяются требования к ПИ или архитектура ПИ.
По формальной процедуре составляются планы модульного, интеграционного тестирования, тестирования работоспособности ПИ и системного тестирования, в соответствии с которыми выполняется тестирование. Все эти планы составляются на основе проектного плана, документируются и утверждаются. Готовность тестовых комплектов и процедуры тестирования обозревается сотрудниками, ответственными за требования к ПИ и за возможности их тестирования, за архитектуру и детальную разработку ПИ. Тестирование ПИ выполняется путем сравнения результатов тестирования со спецификациями высокоуровневого и детального проектирования, а также с требованиями к ПИ.
Модульное, интеграционное тестирование, тестирование работоспособности и системное тестирование планируются и выполняются для того, чтобы удостовериться (подтвердить), что ПИ соответствует предъявляемым требованиям. Модульное, интеграционное тестирование и тестирование работоспособности ПИ выполняется с целью подтверждения его соответствия спецификациям высокоуровневого и детального проектирования (верификация ПИ). Системное тестирование выполняется для того, чтобы продемонстрировать заказчику и конечным пользователям работоспособность ПИ, соответствие предъявляемым требованиям (валидация ПИ). Ресурсы для тестирования ПИ должны выделяться как можно раньше, чтобы обеспечить подготовку процесса тестирования. Планы тестирования документируются и обозреваются как разработчиками, так и заказчиками с целью выявления несогласо-ванностей в них, для устранения выявленных недостатков и улучшения планов. Планы тестирования включают в себя подход к верификации и валидации ПИ, обязанности предприятия-разработчика, субподрядчиков, заказчиков и конечных пользователей, перечень оборудования тестирования, требования поддержки тестовых комплектов и т.п.
Примеры обязательной деятельности для подготовки тестирования: подготовка документации тестирования, планирование ресурсов для тестирования, для разработки тестовых комплектов и т.п.
План и процедуры системного тестирования подготавливаются группой независимого системного тестирования. План системного тестирования документируется и обозревается системными тестиров-щиками, заказчиком или конечными пользователями до начала тестирования с целью его улучшения, и после обзора план системного тестирования утверждается. Проблемы, выявленные во время тестирования, документируются и отслеживаются для их устранения. Результаты тестирования управляются и контролируются.
На основе формальной процедуры разрабатывается сопроводительная документация, предназначенная для эксплуатации и сопровождения ПИ. Про-
цедура определяет, что для разработки документации используются соответствующие методы и инструментальные средства (например, обработка слов, повторное использование документации, текстовые процессоры и т.п.). Для составления планов подготовки документации, ее разработки и поддержания выделяются высококвалифицированные специалисты или проводится специальное обучение специалистов в предметной области ПИ. Первые версии документации разрабатываются как можно раньше в жизненном цикле ПИ и предоставляются заказчику, конечным пользователям и ответственным за сопровождение ПИ для обзора и обеспечения обратной связи. К документации ПИ относится руководство пользователей, оперативная документация, руководство операторов, руководство сопровождения и т.п. Документация подвергается тщательному обзору разработчиками, заказчиком, конечными пользователями и ответственными за сопровождение ПИ. Окончательные версии документации проверяются при системном тестировании ПИ. Сопроводительная документация управляется и контролируется.
В соответствии с формальной процедурой собираются и анализируются данные об отклонениях, выявленных при проведении всех видов обзоров и тестирования. Примеры собираемых данных включают в себя описания и категории отклонений, уровни серьезности отклонений, модули, содержащие отклонение, а также модули, на которые влияет отклонение, деятельность, при которой появилось отклонение (обзор или тестирование). К собираемым данным относится также описание выполняемого сценария, выявляющего отклонение, ожидаемые и фактические результаты, вызывающие отклонение, и другие данные.
Поддерживается согласованность в продуктах проекта ПИ, включая требования к ПИ, планы разработки ПИ, спецификации высокоуровневого и детального проектирования ПИ, программный код, планы и процедуры тестирования. Результаты любой работы документируются, а документация всегда должна быть в наличии. Документация, отражающая требования к ПИ, спецификации проектирования, программные коды и состояние процесса тестирования, управляется и контролируется. Изменения в продуктах, планах, описаниях процесса проектирования обозреваются и анализируются с целью улучшения ПИ. Проектный процесс обусловливает необходимость определения влияния любого изменения до того, как оно произведено. При необходимости изменения в требования к ПИ вносятся до изменений любых других продуктов или деятельности. Изменения во всех продуктах проекта и описаниях процесса координируются, обсуждаются и согласовываются рабочими группами (среди них группы: разработки ПИ, независимого системного тестирования, оценки качества ПИ, управления конфигурацией ПИ, управления контрактом, поддержки документации и т.п.). Изменения отслеживаются до полного завершения проекта.
Сбор и анализ метрик. Осуществляются и накапливаются измерения характеристик продуктов
10
проекта и свойств процесса, производится анализ собранных данных. Результаты анализа используются для определения работоспособности и качества ПИ. Примеры измерений: количество, типы и уровень серьезности отклонений, выявленных в продуктах проекта в процессе всех видов обзоров и тестирования; реальные последствия, вызываемые обнаруженными отклонениями, соответствие поведения ПИ требованиям заказчика и другие данные.
Результаты измерений используются для определения состояния деятельности по технической разработке и технологии разработки ПИ. Примеры измерений: состояние на текущий момент (в течение всего жизненного цикла ПИ) каждой позиции спецификаций требований к ПИ, спецификаций проектирования; отчеты о выявленных проблемах, об их значимости и времени их актуальности; трудоемкость анализа изменений в продуктах проекта для каждого предложенного изменения и по всей их совокупности; количество изменений, введенных в проектный план по категориям (интерфейсы, защита ПИ от неумелых действий пользователя, конфигурация ПИ и т.п.); планируемый размер изменений; стоимость выполнения и тестирования внесенных изменений; фактический размер и стоимость и т.д.
Отслеживание хода реализации ключевых приемов. Деятельность по технологии разработки ПИ периодически проверяется администрацией предприятия. Главной задачей периодических проверок (обзоров) является обеспечение графика выполнения технической разработки ПИ и получение объективной информации для эффективного управления разработкой. Периоды проверок (обзоров) определяются нуждами предприятия и могут изменяться по мере выработки механизма отслеживания. По каждой проверке (обзору) готовится отчет, который распространяется среди всех заинтересованных лиц и групп, вовлеченных в проект.
Администрацией проверяется производительность создания ПИ, расходование финансов, соблюдение графиков, расходование технических и людских ресурсов. По результатам проверок (обзоров) разрешаются конфликты и вопросы. Описываются вновь установленные риски технической разработки ПИ. Составляется таблица действий по разрешению выявленных проблем с указанием срока выполнения и ответственных за их разрешение. Мероприятия, указанные в таблице, отслеживаются и проверяются на предмет их завершения.
Деятельность по технологии разработки ПИ проверяется руководителем проекта периодически и при необходимости. Проверке подлежит деятельность всех групп, вовлеченных в проект. На соответствие плану проверяется также производительность технических средств, нарастание стоимости проекта, производительность программирования и т.п. Проверяется использование критических ресурсов целевых вычислительных средств; текущие прогнозы и текущие реальные данные сравниваются с исходными прогнозами. Проверяется согласованность работ, распределенных между группами. Описываются неразрешимые на уровне руководителя проекта кон-
фликты и вопросы, а также вновь выявленные риски. Определяются необходимые мероприятия, составляется таблица действий. Эта таблица отслеживается и проверяется на предмет завершения описанных в ней мероприятий. По каждой проверке готовится и распространяется отчет среди всех заинтересованных лиц и групп, вовлеченных в проект.
Группа оценки качества обозревает или проверят деятельность и результаты работ по технологии разработки ПИ, по результатам составляет отчеты. Обзорам и (или) проверкам подвергаются требования заказчика к ПИ с целью подтверждения того, что они полны, содержательны, выполнимы и тестируемы. Обозреваются также критерии завершения каждой задачи технологии разработки ПИ, проверяется следование планам и процедурам тестирования разработчиками. Кроме того, обозревается соблюдение планов и процедур системного тестирования, удовлетворение критериям завершения тестирования. Осуществляется документирование, отслеживание выявленных отклонений и проблем и т.п.
Фрагмент шаблона «Спецификации требований заказчика к ПИ»
Определение. Требования заказчика к ПИ (функциональные спецификации проектирования - ФСП) являются обязательным документом для проведения разработки ПИ, в котором установлены функциональные и другие требования заказчика к ПИ, методология и методы использования ПИ, ограничения заказчика к среде окружения ПИ, требования ко всем создаваемым при разработке ПИ документам. ФСП -это архитектура ПИ с точки зрения заказчика.
ФСП является базовым документом для выполнения фазы «Планирование», «Проектирование» и «Системное тестирование».
ФСП оформляются в соответствии с установленным шаблоном, утверждаются заказчиком и администрацией, входят в состав контрактной книги как отдельный раздел. Для внесения изменений и дополнений в ФСП на последующих фазах жизненного цикла ПИ выпускаются дополнения. Разработка, согласование и утверждение дополнений к ФСП осуществляется в том же порядке, который установлен для самих ФСП.
ФСП обычно состоят из трех разделов, а именно: цель создания ПИ, требования, порядок контроля и приемки.
Цель создания ПИ. В начале раздела дается полное точное название ПИ, сокращенное его наименование и условное обозначение (шифр, код). Далее обосновывается необходимость, актуальность, перспективность и цель разработки ПИ, а также практическая значимость поставленной цели для заказчика и реальная польза, которую ее достижение может принести. Цель должна быть понятна и достижима. Достижение цели должно быть измеримо. Если это возможно, описываются какие-либо количественные критерии и оценки ее достижения. Можно сделать декомпозицию цели на подцели и показать достижимость подцелей по этапам.
11
В качестве обоснования цели необходимо указывать признаки добавленной стоимости, например:
- в результате разработки ПИ появляется возможность решения задач (указать, какие задачи), для решения которых ранее не существовало готовых программных средств;
- реализация в ПИ новых методов (алгоритмов), решающих с большей эффективностью в каком-либо определенном смысле поставленные перед заказчиком задачи (коротко указать, в чем смысл новых методов или алгоритмов, указать предполагаемые конкретные цифры по эффективности);
- получение ПИ, позволяющих решать задачи большей размерности (указать размерность решаемых задач) по сравнению с имеющимися на мировом уровне;
- получение ПИ, имеющих менее жесткие ограничения (обязательно указывать количественные оценки улучшений) по реакции на запрос, быстродействию и пр. в сравнении с существующими.
Важно указать несколько альтернатив для достижения цели с перечнем составляющих их задач. Определить критерий выбора между альтернативами (минимизация затрат, минимизация сроков, получение приоритета, некоторый смешанный критерий).
В разделе необходимо определить возможные практические ограничения и препятствия при выполнении данного проекта.
Требования. Разработка ФСП осуществляется на фазе планирования и составления требований. В этом разделе будут описаны лишь состав и правила оформления требований к ПИ.
При описании набора ФСП требования располагают в зависимости от степени их важности, начиная с самых важных или наиболее характерных. Если имеются требования, подлежащие уточнению в процессе выполнения разработки ПИ, то они записываются: «... окончательные требования по ... уточняются в процессе выполнения разработки ПИ на фазе . жизненного цикла ПИ и согласовываются с заказчиком ...».
Функциональные требования. В разделе описываются все функциональные требования.
Функциональные требования в части решаемых средствами ПИ задач. К таким требованиям относятся описания основных задач и функций, подлежащих выполнению средствами данного ПИ, методы и алгоритмы, реализуемые внутри ПИ. К ним принадлежат также основные ограничения на параметры решаемых задач и выполняемых функций, временные ограничения на параметры работы ПИ, точность решаемых ПИ задач и т.п.
Функциональные требования по взаимодействию пользователя с ПИ в рабочих, экстремальных и аварийных режимах (методы и формы взаимодействия пользователя с ПИ); точность и полнота представления входных и управляющих данных; наличие средств полной (частичной) генерации (инсталляции) ПИ; наличие средств анализа работоспособности и диагностики.
Требования по совместной работе ПИ с аппаратными средствами, операционной и программной
средой. Эти требования касаются конфигурации аппаратных средств, допустимых для ПИ; версии операционных систем и программных пакетов, расширяющих возможности операционных систем. К ним относятся также требования, определяющие процесс взаимодействия с другими ПИ, режимы работы данного ПИ.
Требования к составу и структуре ПИ. В разделе описывается перечень программных компонентов, из которых состоит ПИ (библиотеки, пакеты, программные системы, программный комплекс). В описание включаются средства управления, генерации, диалога, контроля работы и диагностики. В этот раздел включаются также функции и взаимосвязи компонентов, их взаимодействие в рабочем режиме, при генерации (инсталляции), контроле, диагностике.
Требования к программным компонентам и модулям. В разделе указываются требования к отдельным компонентам ПИ, в том числе к средствам управления данными, средствам ввода и вывода информации, входному языку, интерфейсам программных средств, к средствам генерации (инсталляции) ПИ, сервисным средствам ПИ, средствам защиты ПИ, средствам контроля и диагностики.
В этом же разделе устанавливаются требования по организации функционирования ПИ и определяются ограничения, которые должны выполняться при функционировании ПИ, в том числе по объему используемой оперативной памяти, времени решения задач, реализуемых с помощью ПИ.
Требования к программированию. Здесь указываются языки программирования, которые должны (могут) быть использованы при программировании; операционные системы, под управлением которых должно функционировать ПИ; средства автоматизации программирования, используемые при разработке ПИ.
Требования к организации входных и выходных данных. В разделе определяются формы (форматы, носители) представления входных данных и языки их описания, используемые в ПИ; формы (форматы, носители) представления данных, управляющих процессом функционирования, и языки их описания для данного ПИ. Здесь же устанавливаются формы представления выходных данных, обеспечиваемые разрабатываемым ПИ; требования относительно возможности управления потоком выходных данных в процессе функционирования ПИ. Кроме того, в раздел включаются (если подобное есть в функциональных требованиях) требования к точности представления исходных данных и получаемых результатов решаемых задач.
Требования к комплексу технических и программных средств. В разделе приводятся следующие требования: к комплексу технических средств, на который ориентируется разрабатываемое ПИ; к комплексу технических средств, на котором должна проводиться разработка ПИ; к режимам работы комплекса технических и программных средств при использовании данного ПИ.
Требования по составу выходных материалов. Здесь указывается полный перечень выходных мате-
12
риалов (в том числе ПИ на машинном носителе) и подлежащих разработке программных документов с указанием фаз жизненного цикла ПИ, на которых разработка должна выполняться, а также требования к качеству изготовления текстовых документов и тип машинных носителей ПИ.
Порядок контроля и приемки. В этом разделе устанавливаются общие требования к контролю работ по разработке ПИ и приемке выполненных работ на различных фазах жизненного цикла ПИ. Определяются критерии определения качества ПИ, представитель заказчика (или другие персоны, указанные заказчиком), который будет осуществлять опытную эксплуатацию готового ПИ.
В заключение отметим, что при определении набора рубрик шаблона и их содержания мы руководствовались принципом разумной достаточности и исходили из обеспечения возможности составления однозначных, хорошо понятных и тестируемых требований к ПИ. При этом не ставилась задача доказательства полноты и достаточности набора требований к ПИ, включенного в шаблон (это очень сложная задача). Успешное выполнение с высоким качеством более 10 проектов ПИ для различных предметных областей подтвердило разумность такого подхода к составлению требований.
Описания конкретных процедур и стандартов технологии разработки ПИ представляют собой интеллектуальную собственность предприятия и, как правило, не подлежат огласке. Однако в первой части статьи есть все указания на то, что должно быть сделано для получения эффективной технологии разработки ПИ. А вот как это должно быть сделано, выносится на суд конкретного предприятия. Заметим, что большую пользу при этом приносит изучение предшествующего опыта работы и включение в новую технологию лучшего, что было достигнуто в разработке ПИ.
Список литературы
1. Paulk M.C., Curtis B., Chrissis M.B., Weber Ch.V. Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. - Pittsburgh: Software Engineering Institute, 1993. - 533 p.
2. Humphrey G. Managing the Software Process - Reading: Addison-Wesley, 1989. - 494 p.
3. Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем (ISO/IEC TR 15504): - Изд-во: Компания "АйТи", Книга и бизнес. - 2001. - 348 с.
4. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Процесс разработки программных изделий. - М.: Наука, Физматлит. - 2000. - 176 с.
АВТОМАТИЗАЦИЯ ИНТЕГРИРОВАННОГО УПРАВЛЕНИЯ
ПРОЕКТАМИ
А.Н. Домарацкий, Н.К. Ласточкин, В.П. Морозов
Как показывает опыт, трудность внедрения процесса [1] заключается в том, что при разработке программного изделия (ПИ) главным действующим лицом является человек, который, как известно, обладает и достоинствами, и недостатками. Однако при внедрении процесса приходится сталкиваться больше с недостатками человека, чем с его достоинствами. Причем проявляются прежде всего те недостатки, которые порождены природой человека, - сопротивление всему, что ограничивает его свободу в каком-либо смысле. Этот недостаток проявляется даже тогда, когда некоторое ограничение свободы выбора организационной культуры при проведении работ по созданию ПИ дает положительный результат и приводит к удачному выполнению программного проекта.
Поскольку процесс - это систематизированный набор механизмов, формальных процедур и стандартов, обусловливающий успешное выполнение проекта, то всю деятельность по проекту он ограничивает определенными рамками. Эти рамки воспринимаются многими программистами (особенно программистами со стажем успешной работы) как ограничение свободы в их труде, хотя процесс не несет никаких ущемлений свободы в их творческой деятельности.
В таких условиях требуются значительные усилия и терпение со стороны руководства предприяти-
ем, чтобы наладить работу программистов по установленному процессу. С ростом совершенства процесса растет набор механизмов, процедур и стандартов, которые необходимо выполнять или соблюдать, что еще в большей степени вызывает сопротивление внедрению процесса со стороны программистов. В этой ситуации для сокращения этапа внедрения процесса необходимо использование автоматизированных средств выполнения механизмов, процедур и соблюдения стандартов. Таким автоматизированным средством является система, описанию которой посвящена настоящая статья. Эта система разработана и применяется в АОЗТ ИДУ с 1998 года; она получила название "Автоматизированная система интегрированного управления проектами (АСС)". С использованием системы АСС происходит объединение деятельности по управлению проектом и технической разработкой ПИ в единый интегрированный проектный процесс.
АСС состоит из трех согласованных автоматизированных рабочих мест (АРМ), предназначенных для руководства предприятия, руководителей проектов и разработчиков ПИ. Наибольшими функциональными возможностями из перечисленных АРМов обладает АРМ руководителя проекта. С его помощью можно осуществлять автоматизированное составление и редактирование проектных планов раз-
13
