Software & Systems

Как известно [1-2], любая разработка программного изделия (ПИ) имеет свой жизненный цикл (ЖЦ), который определяет ее начало и конец. Характерным свойством нового сложного проекта ПИ является изменение представления о нем в процессе выполнения проекта [3]. Это происходит в результате накопления новых знаний о ПИ в течение его разработки. В этих условиях с целью обеспечения высокой эффективности разработки для каждого проекта ПИ необходимо иметь модель ЖЦ, наилучшим образом отражающую особенности именно данного ПИ. В практике разработки ПИ имеется некоторое множество хорошо зарекомендовавших себя моделей ЖЦ [4]. Однако выбор модели ЖЦ целесообразно осуществлять по формальной процедуре, при этом разумно опираться на имеющиеся результаты предшествующей работы. Авторы накопили интересный опыт в использовании моделей ЖЦ в итоге выполнения более чем 10 проектов ПИ по методологии СММ [2].

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

Перечень характеристик проекта ПИ. Доступность ресурсов. В число ресурсов входит длительность выполнения проекта, состав исполнителей, обеспечение финансами и инструментальными средствами и т.п. Если ресурсы для проекта поддаются оценке и являются доступными, удобно пользоваться моделью водопада или V-образной моделью. Однако если ресурсы ограничены или плохо поддаются оценке, следует использовать одну из моделей ЖЦ, учитывающих риски, – инкрементную или спиральную.

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

Сложность проекта определяется числом подсистем ПИ, количеством связей между ними, степенью новизны разрабатываемого ПИ и т.п. С ростом сложности проекта появляется необходимость в использовании моделей ЖЦ, отличных от водопада и V-образной модели.

Низкая – все показатели сложности проекта низкие. Средняя – характеристики сложности имеют смешанный характер. Некоторые показатели сложности проекта высокие, а некоторые низкие. Высокая – все показатели сложности проекта высокие.

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

Низкая – ожидаемая стоимость проекта не превосходит определенной суммы. Средняя – ожидаемая стоимость проекта равна определенной сумме. Высокая – ожидаемая стоимость проекта превосходит определенную сумму.

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

Низкая – ожидаемая стоимость доработок ПИ ниже определенной суммы. Высокая – ожидаемая стоимость доработок ПИ выше определенной суммы.

Степень изменения требований. Функциональные требования к ПИ, определенные заказчиком, могут изменяться в ходе разработки ПИ. Если одновременно меняется ряд связанных функций или изменения захватывают широкую область, то происходит значительное изменение требований заказчика к ПИ, которое может повлечь за собой большие затраты на их осуществление. Если область, затрагиваемая изменениями, невелика, затраты на изменения требований могут быть незначительными. Низкая и высокая степень может быть определена разными способами, например: низкая – изменение требований затрагивает менее пяти интерфейсов и в целом охватывает менее десяти процессов; высокая – изменение требований затрагивает пять и более интерфейсов и охватывает десять и более процессов.

Простота использования модели ЖЦ определяется тем, как ЖЦ способствует организации интегрального управления проектом (объединению процесса разработки ПИ и процесса управления проектом).

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

Определение требований заказчика к ПИ, то есть того, что должно делать ПИ, является наиболее критическим этапом проекта.

Неопределенные – требования к ПИ плохо поддаются определению, поскольку заказчик не в состоянии однозначно определить свои потребности; разработчики сами составляют часть требований по предположениям о нуждах заказчика. Определенные – требования к ПИ однозначно определены, измеряемы и поддаются тестированию (проверяемы).

Продолжительность существования ПИ – это отрезок времени от момента разработки ПИ до момента его изъятия из эксплуатации.

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

Технология разработки ПИ: существующая, которая применялась в предыдущих разработках, и новая, которая ранее не применялась командой, выполняющей проект.

Эффективность разработки ПИ отражает соотношение прибыли от использования (продажи) ПИ и стоимости разработки, если прибыль можно определить.

Низкая – показатель соотношения прибыли и стоимости ниже, чем определенное значение. Высокая – показатель соотношения прибыли и стоимости для проекта превышает определенное значение.

Достижение уровня качества ПИ. Модель ЖЦ выбирается в зависимости от того, возможно ли получить продукт заданного уровня качества при первой генерации.

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

Степень непостоянства требований отражает степень изменения требований к ПИ в процессе разработки.

Низкая определяет постоянство требований в ходе разработки. Средняя – требования меняются незначительно в ходе разработки. Высокая – требования меняются постоянно; приходится часто изменять многие компоненты ПИ, что приводит к изменениям в целом.

Повторное использование поставленных продуктов и документов указывает на потенциальное сокращение сроков разработки ПИ.

Низкое – возможность повторного использования продуктов из других реализаций ограничена, составляет, например, менее 15%. Высокое – повторное использование продуктов из других реализаций составляет не менее 15%.

Разрешение рисков. В иные модели ЖЦ риски входят как фактор разработки, тогда как некоторые не учитывают риски вовсе. Поэтому необходимо определить, имеются ли риски в проекте и каково их влияние на ход выполнения проекта в случае их проявления.

Нет – разрешение рисков при выборе модели ЖЦ не учитывается. Да – при выборе модели жизненного цикла необходимо учитывать риски.

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

Нет – указывает на отсутствие необходимости в изменениях требований; да – на наличие неопределенности.

Наличие неизвестных требований означает, что имеются требования, которые не определены, но имеют существенное значение для решения поставленных перед ПИ задач.

Нет – все требования определены. Да – некоторых требований может недоставать или они подлежат доопределению.

Спиралевидная модель ЖЦ разработок. Содержание набора описаний, определяющих важнейшие этапы ЖЦ ПИ и взаимосвязи между ними, приведем на примере спиралевидной модели ЖЦ. Одна из разновидностей такой модели представлена на рисунке. В этой модели выделено семь фаз: {1} – фаза концептуализации проекта ПИ (определение целей и задач проекта); {2} – фаза планирования и составления требований (составление планов, требований заказчика к ПИ); {3} – фаза проектирования ПИ (высокоуровневое проектирование, детальное проектирование); {4} – фаза кодирования и отладки (создание кодов ПИ, модульное и интеграционное тестирование, тестирование работоспособности); {5} – фаза системного тестирования (подтверждение соответствия ПИ требованиям заказчика, подтверждение работоспособности ПИ, определение качества ПИ); {6} – заключительная фаза (сдача ПИ заказчику, ретроспективный отчет о проекте); {7} – фаза сопровождения (изменения ПИ, связанные с изменениями среды окружения и условий использования).

Первые три и пятая фазы могут начинаться практически одновременно. Кроме того, первые две или три фазы могут быть охвачены обратной связью для уточнения результата работы на любой из них с разным числом итераций. Фазы {4}–{7} выходят за границу спирали. Фаза {6} является заключительной при выполнении проекта ПИ. На этой фазе осуществляется сдача заказчику всех установленных контрактом продуктов и составление ретроспективного отчета о проекте с целью анализа и сохранения приобретенных новых знаний. На фазе сопровождения основной является работа по выполнению изменений в ПИ. Эти изменения могут быть связаны с устранением обнаруженных дефектов при повседневной эксплуатации ПИ, с выполнением дополнительных пожеланий заказчика и т.п. Организации-субподрядчики, как правило, фазу {7} не включают в ЖЦ и сопровождением ПИ не занимаются.

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

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

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

Проект может перейти на следующую фазу, если: 1) концепция разработана так, что она может быть осмысленно обсуждена, 2) может быть принято решение об окончании ее разработки, 3) в ней заложена разумная возможность быстрого решения или перерешения проблемы, поставленной в проекте.

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

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

Составление проектного плана. В действительности фаза {2} начинается практически одновременно с фазой {1}. Результаты работ на фазах {1} и {2} могут оказывать взаимное влияние друг на друга, приводящее к их уточнению или корректировке. На фазе {2} составляется проектный план, который включает в себя планы разработки ПИ, управления конфигурацией, предотвращения дефектов, управления качеством и другие планы, предусмотренные стандартным процессом предприятия [1-2].

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

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

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

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

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

Составление требований. На фазе {2} также составляются, согласовываются и утверждаются спецификации требований заказчика к ПИ. Составление однозначных, хорошо понятных и тестируемых требований заказчика к ПИ является сложной задачей. Большую пользу при составлении требований приносит конструирование прототипов, поскольку прототипы являются эффективным средством анализа требований. Кроме того, прототипирование уменьшает риск выпуска некачественного ПИ, усиливает взаимодействие и взаимопонимание заказчика и разработчика. В практике составления требований существует два вида прототипов. Первый из них – быстрый (прототип на выброс), второй – эволюционный (прототип для последующей разработки).

Первый вид прототипа разрабатывается быстро (не более 2-3 дней). Как правило, программирование такого прототипа осуществляется на каком-либо языке высокого уровня. Этот вид прототипа создается для прототипирования только тех частей ПИ, которые менее всего понятны. Он используется для понимания или проверки некоторых требований, для тестирования отдельных требований на предмет возможности проектирования и т.п. Быстрый прототип строится без учета его качества, он не является продуктом проекта и не поставляется заказчику, после использования он, как правило, уничтожается.

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

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

Проектирование ПИ. Фаза {3} может начинаться практически одновременно с фазой {1}. Она предназначена для разработки высокоуровневой (высокоуровневое проектирование) и детализированной (детальное или низкоуровневое проектирование) модели заказанного ПИ. Эти модели строятся в соответствии с проектным планом на основе разукрупнения требований заказчика к ПИ. Они определяют архитектуру ПИ (набор описаний, определяющий главные модули системы и взаимосвязи между ними) и его структуру (набор компонентов, из которых состоит ПИ, и взаимосвязи между ними). Модели также обусловливают организацию каждого компонента и межкомпонентных интерфейсов, устанавливают структуры данных для объединения компонентов в систему, определяют алгоритмы реализации предписанных функций и т.п.

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

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

Большую пользу для дальнейшего контроля над реализацией требований заказчика в разрабатываемом ПИ приносит создание матрицы отслеживания (МО), заполнение которой начинается на фазе {2} и продолжается в течение {3-5} фаз ЖЦ. В МО каждому требованию заказчика к ПИ (каждой позиции из спецификации требований) на фазе {3} ставятся в соответствие компоненты высокоуровневого и детального проектирования (уникальные имена модулей высокоуровневого и детального проектирования).

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

На фазе {4} перед началом кодирования создается базовая версия ПИ (согласованная и утвержденная спецификация ПИ, служащая в дальнейшем основой для его последующей разработки). Далее заполняется матрица отслеживания, в которую заносятся имена программных модулей в соответствии с теми компонентами спецификаций проектирования, функции и задачи которых они выполняют.

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

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

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

Системное тестирование. Фаза {5} заключается в выполнении системного тестирования сборки базовой версии ПИ [2,6], поступившей в группу системного тестирования. Системное тестирование ПИ проводится с целью обнаружения дефектов в нем, а также выявления его работоспособности и надежности защиты от неумелых действий пользователя. Кроме того, выясняется степень соответствия ПИ требованиям заказчика и сопроводительным документам (руководству пользователя, инструкции по установке и т.п.).

Обычно фаза {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.