Научная электронная библиотека

Монографии, изданные в издательстве Российской Академии Естествознания

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРИКЛАДНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Соловьев С. В., Цой Р. И., Гринкруг Л. С.,

КАЧЕСТВО ПАКЕТОВ ПРИКЛАДНЫХ ПРОГРАММ

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

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

 ISO 9000-3:1991. Общее руководство качеством и стандар­ты по обеспечению качества. Указания по приме­нению ISO 9001 при разработке, поставке и обслуживанию про­граммного обеспечения;

 ISO 9126:1991 ИТ. Оценка программного продукта. Харак­терис­ти­ки качества и руководство по их применению;

 ISO 12119:1994. Требования к качеству и тестированию;

 ГОСТ 28195-89. Оценка качества программных средств. Общие положения;

 ГОСТ 28806-90. Качество программных средств. Термины и определения.

Например, в международном стандарте ISO 9126:1991 реко­менду­ется шесть основных характеристик качества программных изделий, каждая из которых детализируется несколькими факторами (рис. 12).

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

Рис. 12. Характеристики качества программного изделия

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

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

Например, для обобщенной характеристики качества пакета прикладных программ при сравнении его с аналогами можно использовать комплексный пока­затель качества:

 

Пример расчета комплексного показателя качества J, для данных, приведенных в табл. 4, показывает, что новый пакет прикладных программ обладает более высокими потребительскими характеристика­ми по сравнению с аналогом.

Основные понятия и показатели надежности программных средств

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

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

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

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

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

При применении понятий надежности к программным средствам следует учитывать особенности и отличия этих объектов от тра­диционных технических систем, для которых первоначально разра­батывалась теория надежности:

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

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

 для повышения надежности комплексов программ особое зна­чение имеют методы введения в программные средства временной, программной и информационной избыточности;

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

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

С учетом перечисленных особенностей теория надежности стала развиваться в особом направлении - надежности программных средств (Software Reliability).

К задачам теории и анализа надежности сложных программных средств можно отнести следующие:

 формулирование основных понятий, используемых при ис­следо­вании и применении показателей надежности программных средств;

 выявление и исследование основных факторов, определяю­щих характеристики надежности сложных программных комплек­сов;

 выбор и обоснование критериев надежности для комплексов программ различного типа и назначения;

 исследование дефектов и ошибок, динамики их изменения при отладке и сопровождении, а также влияния на показатели на­дежности программных средств;

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

 исследование методов и средств контроля и защиты от иска­жений программ, вычислительного процесса и данных путем ис­пользования различных видов избыточности и помехозащиты;

 разработка методов и средств определения, прогнозирования характеристик надежности в жизненном цикле комплексов про­грамм с учетом их функционального назначения, сложности, струк­турного построения и технологии разработки.

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

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

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

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

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

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

Эти расхождения можно назвать дефектом программного изделия. Тогда количественной характеристикой качества можно считать плотность оставшихся в программном изделии дефектов после по­ставки его заказчику.

Плотность дефектов в ПИ приня­то определять как отношение количества оставшихся в ПИ дефектов к общему размеру его программного кода.

Размер программного кода ПИ измеряется числом строк кода (LOC - Lines of Code) или тысяч строк кода (KLOC). Для обеспече­ния возможности сравнения размеров кодов, написанных на разных языках программирования, применяется единица измерения «тысяча строк эквивалентного ассемблерного кода» (KAELOC - К of Assembler Equivalent Lines of Code).

Для различных языков программирования статистически выявлены коэффициенты пересчета KLOC данного языка программирования в KAELOC, которые представлены в табл. 5.

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

Тогда можно считать, что в ПИ размером в 1 000 KAELOC распределение вероятностей строк кода, содержащих дефекты и принятых за случайные величины, подчиняется нормальному закону распределения, плотность вероятности которого определяется по формуле

 

В практике производства программного изделия считают, что его качество имеет уровень is, если количество строк кода, не содержащих дефек­ты, попадает в интервал [m - is; m + is] относительно математического ожидания m.

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

Например, интеграл   при s = 1.

Поэтому количество строк, содержащих дефекты, составляет 31,73 % от всех строк кода.

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

Таблица 6

Плотности дефектов в поставляемом ПИ в зависимости от уровня его качества

Тогда при уровне качества 6 сигм заказчику может быть постав­лено программное изделие, в котором может быть только 3-4 дефекта на миллион строк ассемблерного эквивалента.

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

Существует правило: если организация хочет иметь возможность выпускать программное изделие с уровнем качества is в плановые сро­ки без превышения установленных людских и финансовых ресурсов, необходимо, чтобы в этой организации был достигнут уровень качества выполнения проекта в целом не ниже, чем (i - 1) сигма. Концепция качества Six Sigma

Концепцию качества «6 сигма» (Six Sigma) в 80-х годах пред­ложила корпорация Motorola. Ее инженеры пришли к выводу, что новые продукты, которые часто не оправдывают ожиданий пользо­вателей, можно с самого начала производить без дефектов.

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

Прежние методики контроля качества, предлагаемые в 70-е и 80-е годы, были направлены «на устранение дефектов ради само­го их устранения». Данная методика предусматривает постоянное и комплексное управление качеством. Она, как большинство программ, связанных с управлением, основана на использовании различных метрик качества, например, «важность для качества» (critical-to-quality - CTQ).

Как только за­казчики определили, что для них наиболее важно, компания определяет, какие дей­ствия могут больше всего повлиять на оперативное вы­полнение заказа, и количественно оценивают эти действия посредст­вом CTQ. Или посредством количества дефектов в 1 000 KAELOC. Возможно более широкое понятие «вероятного числа де­фектов на миллион» экземпляров продукта (defect-per-million opportunity - DPMO).

Развитие этих и других идей менеджмента качества привело к появлению в 1986 году серии стандартов ISO 9000, определяю­щих требования к системам качества компаний. Стандарты ISO 9000

Разработчиком стандартов является Международная органи­зация стандартизации (ISO), находящаяся в Женеве. Например, версия 1994 года - ISO 9000:1994 и версия ISO 9000:2000.

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

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

Составляющими ISO 9000:1994 являются, во-первых, собст­венно стандарты, на соответствие которым и проходит сертифика­ция:

 ISO 9001 - обеспечение качества при проектировании, раз­работке, производстве, монтаже и обслуживании;

 ISO 9002 - обеспечение качества при производстве, монтаже и обслуживании;

 ISO 9003 - обеспечение качества при окончательном контро­ле и испытаниях.

Фактически, стандарты 9002 и 9003 являются выборками из стандарта 9001.

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

Что же необходимо для внедрения полноценной системы качества? Во-первых, это обязывает предприятие задокументиро­вать всю свою деятельность по указанным в табл. 8 двадцати на­правлениям, а также обеспечить реальное функционирование бизнес-процессов в организации в полном соот­ветствии с ними. Конечным этапом становится проверка соответствия разработанной системы управления требованиям стандарта ISO 9000 и сер­тификация системы качества соответствующей аудиторской фир­мой. Во-вторых, это рекомендации по выбору и внедрению систе­мы качества:

 ISO 9000 - содержит рекомендации по выбору соответствующей систе­мы качества;

 ISO 9004 - это рекомендации по внедрению систем качества. В-третьих, словарь терминов ISO 8402. В-четвертых, рекомендации по проведению аудитов сис­тем качества ISO 10011, 10012, 10013.

Существуют также национальные версии этих стандартов. В России разработана серия ГОСТов под общим названи­ем ИСО 9000. Она принципиально не отличается от международной серии.

Таблица 8 Составляющие стандартов ISO 9001, 9002 и 9003

Знак «+» означает, что требование предъявляется; «-» - требование отсутствует; «+*» - требование облегчено.

Хотя это и дорогостоящее дело, но компании стремятся соответ­ствовать ISO 9000, т.к. возрастают требования заказчиков. К тому же это отличный маркетин­говый ход: «Мы сертифицированы по ISO 9000, нам можно дове­рять». И, конечно же, этот процесс с лихвой должен окупиться последующим снижением потерь, неизбежно возникающих при вы­пуске товара, не удовлетворяющего требованиям потребителя. СТАДИИ РАЗРАБОТКИ ПАКЕТОВ
ПРИКЛАДНЫХ ПРОГРАММ

Виды работ Период жизненного цикла пакетов прикладных программ (ППП) состоит из трех фаз (рис. 13): разработки, эксплуатации и сопровожде­ния. Причем фазы эксплуатации и сопровождения протекают па­раллельно.

Рис. 13. Взаимосвязь фаз жизненного цикла (ЖЦ) ППП

Процессы, происходящие в каждой фазе, регламентирует стандарт ISO/IEC 12207. Фаза разработки каскадной и спиральной модели ЖЦ состоит из следующих этапов:

Фаза разработки включает:

1. Формирование требований к ППП:

 концептуализация проекта;

 планирование работ;

 разработка требований.

2. Проектирование:

 разработка внешних спецификаций;

 разработка внутренних спецификаций (или низкоуровневое, техническое проектирование).

3. Программирование (кодирование) модулей.

4. Тестирование:

 модульное (автономное) тестирование;

 комплексное (интеграционное) тестирование;

 системное тестирование. Формирование требований к ППП

Главной целью формирования требований является отраже­ние потребностей пользователей. К пользователям создаваемого программного продукта можно отнести заказчика и массового потребителя.

Поэтому проекты по созданию пакетов прикладных программ можно разбить на две группы: управляемые заказчиком (заказные ППП) и независимые от заказчика (коммерческие ППП).

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

Заказчики заинтересованы в наличии строго определенного регламента на все процессы выполнения заказа.

Для этого, как ми­нимум, необходимо:

 критерии оценки трудоемкости и длительности проекта;

 прозрачность проекта, т.е. возможность тотального контро­ля по ходу выполнения проекта на полноту и качество.

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

Нередко во взаимоотношениях заказчика и разработчика возникает ситуация: один знает что, но не знает как, а другой, наоборот, понимает как, но не знает что. Поэтому наиболее оптимальной является совме­стная работа разработчиков и заказчиков по выработке требований (рис. 14).

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

1. Концептуализация проекта:

 на основе исследования предметной области сформулировать цели создания ППП;

 описать функциональные задачи, для решения которых предназначен создаваемый ППП, и их взаимосвязь;

 выявить наличие информации, необходимой для выполнения планируемых функций;

Рис. 14. Вариант структуры исполнителей по проекту создания

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

 разработать концепцию проектирования (выбрать модель ЖЦ ПО, технологию и стандарты проектирования, и соответствую­щие программные средства).

2. Планирование работ:

 оценить трудовые и стоимостные затраты, сроки выполне­ния;

 разработать план-график работ с указанием перечня работ, сроков выполнения, исполнителей работ, связанных с созданием ППП, и форму представления результатов работ;

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

3. Разработка детальных требований к ППП:

 сформулировать требования к входным и выходным данным, к конфигурации технических и программных средств, в среде которых может работать проектируемый ППП;

 описать требования к надежности функционирования ППП (защита информации, уровень обеспечения безопасности при сбоях в работе, возможности восстановления работоспособности);

 указать требования к оформлению и содержанию технологической и эксплуатационной документации;

 определить порядок контроля и приемки этапов работы, критерии завершенности разработки и начала эксплуатации.

Требования анализируются на протяжении всего времени раз­работки проекта. Это способствует лучшему пониманию решаемой проблемы и помогает выбрать оптимальное решение.

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

 достаточным для идентификации целей ППП, его среды, преимуществ и ограничений для пользователя, состава и конфигурации ресурсов для его работы;

 достаточно полным, чтобы в последующем при разработке исключить серьезные модификации и пересмотр требований;

 достаточным для просмотра и утверждения руководством заказчика и разработчика на основе его реализуемости в соответствии с выбранными критериями. Проектирование

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

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

 доведение до минимума ошибок пользователя;

 обнаружение ошибок пользователя в случае их возникнове­ния;

 доведение до минимума сложности разрабатываемого ППП.

Фредерик Брукс, один из создателей операционной системы OS/360 для ЭВМ IBM 360/370, отмечал. «Если сразу не определена единая концепция системы, не созданы проектные спецификации («чертежи») системы, то дальнейшее развитие и сопровождение такой системы не только становится трудоемким делом, но и при­водит к росту хаотичности структуры системы в дальнейшем».

Существует два основных подхода к про­ектированию программного обеспечения (ПО):

 структурный;

 объектно-ориентированный.

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

Основными принципами структурного подхода являются:

 принцип абстрагирования - выделение существенных характеристик системы и отвлечение от несущественных;

 принцип иерархического упорядочивания - организация составных частей системы в иерархические древовидные структуры;

 принцип непротиворечивости - обоснованность и согласованность элементов системы;

 принцип структурированности данных - данные должны быть структурированы и иерархически организованы.

Этот подход реализован, например, в методе SADT (Structured Analysis and Design Technique), в CASE-технологии Silverrun (Silverrun Technologies, Inc.). Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами.

Основными понятиями объектно-ориентированного подхода являются объект и класс, а основными принципами:

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

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

 иерархия - расположение абстракций по уровням, создание ран­жированных или упорядоченных структур классов и объектов;

 полиморфизм - способность класса принадлежать более чем одному типу;

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

Этот подход реализован во многих современных проектных технологиях, например, в семействе CASE-средств Rational Rose (Rational Software).

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

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

В процессе внешнего проектирования становятся возможными проверка правильности промежуточного уровня проекта и сопос­тавление его с поставленными целями. Появляется контрольная точка для руководства проектом.

Детальный внешний проект каждой функции пользователя должен включать следующую информацию:

1. Описание входных данных. Точное описание синтаксиса (формат, допустимые значения, области изменения) и семантики данных, вводимых пользователем.

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

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

4. Характеристики надежности. Описывается влияние возможных отказов функций на систему, на файлы пользователя.

5. Эффективность. Описание ограничений, которые накладываются на эффективность функций (затрачивае­мое время, занимаемая память).

6. Замечания по составу программных средств, языкам проек­тирования, алгоритмам процедур, операций и методам их реали­зации, но без детализации внутреннего устройства функции.

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

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

Чтобы изменения в проекте не приводили к дополнительным ошибкам, следует соблюдать следующие правила:

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

2. Фиксировать результаты каждого этапа процесса проектиро­вания. Требования и цели фиксируются после их утверждения, внешние спецификации - после успешного завершения проверки их правильности. Изменения должны также проходить формальную процедуру утверждения.

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

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

Далее формируются структура программного изделия и общие правила взаимодействия компонентов.

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

 функция - внешнее описание действий, выполняемых моду­лем, без указания того, как эти действия производятся;

 логика модуля - внутренний алгоритм модуля, т.е. то, как модуль выполняет функцию;

 контекст - конкретное использование модуля, среда его применения.

При использовании модульно-иерархической структуры:

 улучшается проектирование ППП, так как сложную проблему легче понять, разбив ее на отдельные функцио­нальные части;

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

 упрощается проведение работ по тестированию, отладке и сопровождению, так как в модулях небольшого размера легче по­нять логику программы, организовать проверку, оценить время, не­обходимое для проведения работ;

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

Спецификации модулей должны содержать следующую ин- форма­цию:

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

 функция - определяется, что делает модуль, когда он вы­зван, а также его назначение. Этот элемент спецификации не дол­жен содержать сведения о том, как функция реализуется;

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

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

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

Методология, технология и инструментальные средства проектирования ПО

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

CASE-средства. Общая характеристика и классификация  

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

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

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

 мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком;

 интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;

 использование специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты:

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

 графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

 средства разработки приложений и генераторы кодов;

 средства конфигурационного управления;

 средства документирования;

 средства тестирования;

 средства управления проектом;

 средства реинжиниринга.

Современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit), и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:

 применяемым методологиям и моделям систем и БД;

 степени интегрированности с СУБД;

 доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

 средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

 средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

 средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

 средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично в Silverrun;

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

Вспомогательные типы включают:

 средства планирования и управления проектом (SE Compa­nion, Microsoft Project и др.);

 средства конфигурационного управления (PVCS (Intersolv));

 средства тестирования (Quality Works (Segue Software));

 средства документирования (SoDA (Rational Software)).

Технология проектирования

Технология проектирования определяется как совокупность трех составляющих:

 пошаговой процедуры, определяющей последовательность технологических операций проектирования;

 критериев и правил, используемых для оценки результатов выполнения технологических операций;

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

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

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

 должна поддерживать полный ЖЦ ПО;

 должна обеспечивать достижение целей разработки ИС с заданным качеством и в установленное время;

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

 должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;

 должна обеспечивать минимальное время получения работоспособной ИС;

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

 должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (СУБД, операционных систем, языков и систем программирования);

 должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.

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

 стандарт проектирования;

 стандарт оформления проектной документации;

 стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

 набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

 правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов;

 требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта;

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

Стандарт оформления проектной документации должен уста- навливать:

 комплектность, состав и структуру документации на каждой стадии проектирования;

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

 требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;

 требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

 правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

 правила использования клавиатуры и мыши;

 правила оформления текстов помощи;

 перечень стандартных сообщений;

 правила обработки реакции пользователя.

Методология RAD

Одним из возможных подходов к разработке ПО является методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий три элемента:

 небольшую команду программистов (от 2 до 10 человек);

 короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев);

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

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

Жизненный цикл ПО согласно методологии RAD состоит из четырех фаз:

 фаза анализа и планирования требований;

 фаза проектирования;

 фаза построения;

 фаза внедрения.

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

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

CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60-90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:

 общая информационная модель системы;

 функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

 точно определенные с помощью CASE-средств интерфейсы между автономно разрабатываемыми подсистемами;

 построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

 определяется необходимость распределения данных;

 производится анализ использования данных;

 производится физическое проектирование базы данных;

 определяются требования к аппаратным ресурсам;

 определяются способы увеличения производительности;

 завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода. Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени) и приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается. Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, определяется следующим образом: менее 1 000 функциональных элементов - один человек; 1 000-4 000 функциональных элементов - одна команда разработчиков; более 4 000 функциональных элементов - из расчета 4 000 функциональных элементов на одну команду разработчиков.

Отметим основные принципы методологии RAD:

 разработка приложений итерациями;

 необязательность полного завершения работ на каждом из этапов жизненного цикла;

 обязательное вовлечение пользователей в процесс разработки ИС;

 необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

 необходимое использование генераторов кода;

 использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;

 тестирование и развитие проекта, осуществляемое одновременно с разработкой;

 ведение разработки немногочисленной, хорошо управляемой командой профессионалов;

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

Инструменты разработки программных средств

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

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

 редакторы;

 анализаторы;

 преобразователи;

 инструменты, поддерживающие процесс выполнения программ.

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

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

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

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

Спецификации модулей можно рассматривать как технические задания группам программистов на кодирование (программирование) внутренней логики каждого модуля.

Этот процесс состоит из следующих действий:

 изучение спецификации модуля - проверяется правиль­ность, понятность и внутренняя непротиворечивость информации;

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

 выбор алгоритма и структуры данных - выполняя оригинальные разработки, или используя опыт предыдущих работ;

 собственно программирование;

 компиляция (трансляция) модуля - это действие означает переход к тестированию модуля. Компилятор, строя машинную программу, проводит проверку правильности синтаксиса и частично семантики исходной программы.

Большое влияние на качество создаваемой программы оказывает стиль программирования (правила, приемы, формы программирования, которые, в принципе, являются общими, независимыми от конкретного алго­ритмического языка). Стилю программирования посвящено немало замечательных книг, например, «Стиль, разработка, эффективность, отладка и испытание программ» Д. Ван Тассела. Под фактором хорошего стиля программирования автор, пре­жде всего, понимает простоту и «удобочитаемость» программы (реализация знаменитого KISS принципа: Keep It Simple, Stupid! - Делай проще, глупец!). В частности, он отмечает: «Начинающие программисты думают, что они пишут программы для машин. Опытные программисты зна­ют, что пишут программы для людей».

Другим фактором, в некото­рой степени определяющим первый, является использование идей структурного программирования, которые соответствуют общим принципам структурного подхода:

 разбиение задачи на ряд небольших подзадач;

 широкое применение стандартных подпрограмм;

 использование простых логических программных структур: линейной (например, операторы присваивания), ветвления (напри­мер, оператор ЕСЛИ) и циклической (например, оператор DO).

И, конечно же, знание особенностей и нюансов ис­пользуемого языка программирования.

Переход к спиральной модели жизненного цикла ППП привел к появлению экстремального программирования (ХР - extremely Pro­gram­ming), как стилю и методу современного программирова­ния.

Основные принципы ХР - это достаточно простые и здоровые идеи, применяемые в экстремальных ситуациях:

 стремиться к простоте (все тот же KISS принцип);

 создавать код небольшими итерациями и работать так, чтобы как можно быстрее выдать готовый продукт;

 двигаться вперед по мере конкретизации стоящих перед вами задач (не тратить время на создание чего-то грандиозного и всеобъемлющего);

 рассматривать модульное и функциональное тестирование как важнейшую часть проекта, а не как необязательное дополнение;

 работать напрямую с потребителями и пользователями, стремясь превратить их в участников группы разработки;

 сделать так, чтобы каждый из причастных к проекту ощу­щал себя ответственным за него, но в то же время не допускать, чтобы тот или иной специалист становился единственным экспертом в какой-то определенной части проекта;

 стимулировать постоянную переработку кода (то есть переписывание и совершенствование программ).

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

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

Как начинается проект разработки для парного программиро­вания? В рамках модели ХР большая часть работы над проектом формулируется с помощью карт CRC (Class, Responsibility, Collaboration - «класс, обязанности, сотрудничество») - листов бумаги представляющих собой объекты данного проекта.

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

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

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

Как только код, реализующий решение задачи, за которое от­вечала та или иная пара, завершен, запускается определенный ранее тест. Если тестирование завершается успешно, код интегри­руется в репозиторий (хранилище), где к нему могут обращаться все члены группы разработчиков. Измененный код должен поме­щаться в репозиторий каждые несколько часов (по крайней мере, раз в сутки). При этом все разработчики будут получать актуаль­ный код. Такой подход снижает вероятность возникновения в про­екте ошибок, связанных с нестыковкой версий.

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

Последний шаг - выполнение всех модульных и функцио­нальных тестов. Вполне вероятно, что этот процесс придется по­вторить несколько раз, пока не удастся достичь корректной работы и взаимодействия всех объектов. Может понадобиться провести несколько CRC-сессий; объекты, не прошедшие функциональное тестирование, должны быть переданы для доработки другой паре программистов.

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

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