Совершенствование производства ПО и эволюция программного обеспечения

Лекция 7. СОВЕРШЕНСТВОВАНИЕ ПРОИЗВОДСТВА ПО И ЭВОЛЮЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Цели Цель настоящей лекции - ознакомление с тем, как усовершенствовать производство программного обеспечения, чтобы в итоге получать более качественный программный продукт, а также обзор темы наследуемых систем и структуры таких систем. Изучив эту лекцию, вы должны: • знать основные принципы совершенствования производства ПО, а также понимать, насколько важен этот процесс; • знать факторы, влияющие на качество программного продукта и производительность разработчиков ПО; • понимать модель оценки уровня развития производства, которую можно применять для оценки качества технологии производства в больших организациях, разрабатывающих ПО; • понимать, почему совершенствование на основе модели оценки уровня развития производства может быть применимо к производству не всех типов программного обеспечения. • иметь понятие о наследуемых системах и о причинах особого значения этих систем для развития компаний во многих сферах бизнеса; • знать общие структуры наследуемых систем; • понимать принципы функционально-ориентированного проектирования, на котором основывается большинство стратегий по разработке наследуемых систем; • уметь оценивать наследуемые системы с различных точек зрения. За последние несколько лет значительно возрос интерес специалистов, работающих в сфере инженерии ПО, к процессу совершенствования технологии разработки программных систем. Под совершенствованием технологии разработки программных систем подразумевается изучение существующего производства и внесение изменений в целях улучшения качества продукта и/или снижения издержек и времени разработки. Литература по данной тематике в основном рассматривает совершенствование производства как способ улучшения качества продукта, что подразумевает снижение количества недостатков в готовом продукте. Только после этого задачами изменения производства ПО становится снижение себестоимости или сокращение продолжительности работы над продуктом. Как уже отмечалось, между качеством продукта и качеством его производства существует тесная взаимосвязь. Считается, что повышение качества производства непосредственно влечет за собой получение более качественного продукта. Процесс разработки сам по себе достаточно сложен и состоит из целого ряда этапов. Как программный продукт, так и процесс его разработки, можно охарактеризовать (и оценить) определенными свойствами или параметрами; некоторые из них приведены в табл. 1. Таблица 25.1. Параметры производства ПО Параметр Описание Понятность Четкое и доступное для понимания описание технологии разработки ПО Наглядность результата Оценка реализации проекта по ясным и ощутимым результатам Наличие средств поддержки Насколько производство ПО поддерживается CASE-средствами Приемлемость Степень одобрения и применяемости разработчиками данного процесса создания ПО Безотказность Организация работы таким образом, чтобы избежать или исправить те ошибки технологического процесса, которые вызовут неполадки в готовом продукте Устойчивость к сбоям Стабильное функционирование производства при возникновении непредусмотренных проблем Удобство сопровождения Способность технологического процесса к развитию при изменении системных требований и степень возможности внесения необходимых изменений Скорость Время, за которое будет завершен процесс разработки системы, соответствующий данной спецификации Практически невозможно сразу довести до совершенства все без исключения параметры производства. Например, если необходимо быстро завершить разработку и ускорить работу, следует «снизить» параметр наглядности результата, поскольку это свойство требует регулярной подготовки документации через определенные интервалы времени, что замедляет процесс создания программного продукта. Совершенствование производства - понятие сложное и означает не только выбор методов, средств или самой модели технологического процесса. Правы окажутся те, кто укажет на определенное сходство в деятельности всех организаций, разрабатывающих похожие типы программного обеспечения. Однако не следует забывать об организационных факторах, нормативах и стандартах организации-разработчика, которые также влияют на ход производства. В процессе совершенствования производства всегда должна быть учтена специфика организации, более того, этот процесс должен стать частью ее деятельности. Исходная модель процесса совершенствования производства показана на рис. 1. Этот процесс требует времени и осуществляется поэтапно. Каждый этап может иметь продолжительность до нескольких месяцев. Условием успеха совершенствования производства является приверженность организации поставленной цели, а также готовность вложить для ее реализации определенное количество ресурсов. Такая деятельность невозможна без утверждения высшего руководства организации и наличия бюджета, достаточного для проведения необходимых изменений в организации. Рис. 1. Процесс совершенствования производства Процесс совершенствования производства состоит из нескольких ключевых этапов. 1. Анализ производства. Этот этап включает исследование используемого процесса создания ПО и разработку его модели для подготовки и изучения соответствующей документации. В некоторых случаях можно ввести количественные параметры процесса, что позволит получить дополнительную информацию для исследования. Количественные измерения до и после внедрения изменений помогут дать более объективную оценку преимуществ или проблем, возникших в результате изменения производства. 2. Определение необходимых изменений. Здесь результаты анализа производства используются для определения критических параметров качества, графика работ и себестоимости, которые могут оказать влияние на качество готового продукта. Деятельность по совершенствованию производства должна сконцентрироваться на ослаблении влияния этих параметров путем выбора новых методов и средств технологического процесса. 3. Введение изменений в производство. На этом этапе новые методы и средства внедряются в существующий технологический процесс. Здесь особенно важно иметь достаточно времени для внесения изменений в технологический процесс, а также обеспечить совместимость этих изменений с существующими производственными процессами и организационными стандартами. 4. Обучение измененному процессу производства. Успешное изменение производства невозможно без предварительного обучения персонала, поскольку разработчики и менеджеры, ответственные за выполнение проекта, могут не принять изменений. Часто изменения производства без необходимого обучения персонала приводят скорее к снижению качества продукта, чем к его повышению. 5. Отработка параметров производства. Введенные изменения никогда не дадут полного эффекта, на который вы могли бы надеяться. Вслед за реализацией нововведений должна произойти своего рода настройка, при которой обнаруживаются самые мелкие проблемы и неполадки и делаются необходимые поправки. Этот процесс может продолжаться в течение нескольких месяцев, пока разработчики не будут удовлетворены результатами. После внесения одного или нескольких изменений процесс совершенствования можно повторить, включая этап анализа, определение «узких» мест и т.д. Это более практичный способ, чем введение всех изменений сразу. Кроме проблем в обучении, при многочисленных изменениях будет трудно оценить эффективность каждого из них. Для приобретения программного обеспечения компании обычно должны выложить немалую сумму. Естественно, чтобы оправдать затраты, программные продукты должны находиться в использовании по крайней мере несколько лет. Жизненный цикл программ может быть самым разным, но, как правило, большие системы успешно функционируют и более десяти лет. Некоторые компании не отказываются и от таких систем, которым уже по 20 лет и более. От многих из них все еще зависит деятельность крупных компаний, и малейшая ошибка в системе приводит к сбою их деловой активности. Именно такие системы и получили название наследуемых (legacy system). Это, конечно же, не те старые системы, которые были разработаны и запущены в самом начале эры вычислительной техники. Деловая активность находится в постоянном развитии, обусловленном многими факторами, в том числе эволюцией экономики на национальном и международном уровнях, изменением рынка, законов, менеджмента и структурными преобразованиями. Эти факторы служат причиной появления новых или изменения существующих требований к программному обеспечению, что непосредственно приводит к модификации существующих систем. За несколько лет наследуемая система может пережить целый ряд подобных изменений, совершаемых разными специалистами, поскольку одному человеку практически невозможно полностью освоить систему во всех аспектах. Предприниматели, как правило, настроены на систематическое обновление и модернизацию существующего оборудования. Однако, что касается списания и замены наследуемых систем современным ПО, такие действия могут повлечь за собой серьезный риск и необратимые последствия в деятельности компаний. Многие менеджеры не желают рисковать, устанавливая неизвестное и непредсказуемое современное ПО. Замена наследуемой системы - дело рискованное по многим причинам. 1. Редко можно найти такую наследуемую систему, которая имеет полное и точное техническое описание. Старое описание может быть утеряно, а если оно и существует, вряд ли там будут указаны все изменения, сделанные в системе. Поэтому трудно сравнивать технические характеристики и функциональные возможности старой системы с характеристиками ее возможной преемницы. 2. Функционирование наследуемой системы тесно связано с деловой активностью компании. При замене системы деятельность компании также претерпит изменения, что может привести к непредсказуемым расходам и необратимым последствиям. 3. Некоторые встроенные в систему правила, регулирующие область торгово-промышленных отношений компании, могут быть нигде не документированы. Эти правила обеспечивают своеобразные рамки, в которых должна вестись коммерческая деятельность, и нарушение этих рамок окажет не самое лучшее влияние на развитие бизнеса. Например, страховая компания могла включить в систему правила оценки риска страховых полисов. Если эти правила не выполняются, компания может быть вовлечена в работу с полисами высокой степени риска, что в дальнейшем вызовет большие затраты на выплату страховых возмещений. 4. Создание новых программных систем связано с риском, так как новизна системы подразумевает появление непредусмотренных проблем. Поставщик ПО может доставить программный продукт не вовремя, либо может измениться его цена. Использование наследуемых систем избавляет организацию от риска, связанного с их заменой. Однако модернизация старой системы становится дороже с каждым годом эксплуатации. Возрастающая стоимость модернизации системы, находящейся в эксплуатации несколько лет, определяется многими факторами. 1. Отдельные части системы разрабатывались разными командами программистов, поэтому в них отсутствует единство стиля программирования. 2. Система либо ее отдельные части могут быть написаны с помощью языков, давно вышедших из употребления. Трудность подбора специалистов, знающих эти языки, усугубляется дорогостоящими договорами на внешнее сопровождение системы. 3. Документация системы часто бывает устаревшей и не отвечает современным требованиям. Иногда единственной документацией может остаться исходный код программ. В особо трудных случаях исходный код давно утерян, и все, что доступно, — это функционирующая версия программы. 4. Долгие годы эксплуатации могут оказать разрушительное воздействие на систему и исказить ее настолько, что она станет практически недоступной для понимания. Кроме того, в систему могут быть добавлены либо подогнаны к ней другие программы. 5. Система может быть оптимизирована для экономного использования памяти или для быстрого выполнения. Это создает дополнительные трудности для программистов, владеющих современными технологиями инженерии программного обеспечения и не имеющих понятия о хитростях и тонкостях программирования данной системы. 6. Данные, с которыми работает система, могут содержаться в разных файлах с несовместимыми структурами. Отсюда высокая вероятность дублирования данных, кроме того, они могут быть устаревшими, неполными либо неточными. Организация, использующая большое количество наследуемых систем, сталкивается с серьезной проблемой. Продолжая использовать и модернизировать наследуемые системы, она тем самым значительно повышает свои расходы. Решение заменить наследуемую систему новой также связано с большими расходами, более того, новая система неспособна конкурировать с наследуемой в плане оптимальной поддержки целевой деятельности компании. Поэтому многие организации занимаются поиском новых технологий разработки ПО, позволяющих продлевать жизненный цикл наследуемых систем и снижающих затраты по их использованию. 1. Качество продукта и производства Идея совершенствования производства основывается на том, что технологический процесс является критическим фактором, непосредственно влияющим на качество продукта. Автор этой идеи - американский инженер Деминг (W. E. Deming), который работал над проблемой улучшения качества в промышленности Японии после второй мировой войны. Японцы в течение долгих лет самоотверженно трудились над совершенствованием процесса производства. Это, несомненно, стало основой высокого качества японских товаров. Деминг (и другие) ввел метод статистического контроля качества, который основан на простом подсчете недостатков продукта и соотнесении их с производственным процессом. Для устранения замеченных недостатков производственный процесс совершенствуется до тех пор, пока в конце концов не будут устранены все недоработки. Этим гарантируется предсказуемость результатов изменения процесса и снижение количества недоработок. Затем изменения проходят стадию стандартизации и начинается новый этап совершенствования. В промышленности взаимосвязь «производство-продукт» прослеживается достаточно четко. Совершенствование производства само по себе ведет к повышению качества готовой продукции. Другое дело - неосязаемые и зависящие от интеллектуальной деятельности процессы производства ПО, которые к тому же не подлежат автоматизации. Ведь качество программного продукта зависит не только непосредственно от производственного процесса, но и от процесса проектирования, в котором главную роль играет человеческий фактор. Хотя для некоторых видов ПО ключевым в отношении качества является технологический процесс, однако при реализации новых задач люди, вовлеченные в процесс разработки, остаются ключевым фактором. Существует четыре фактора, принципиальных для качества любой продукции, связанной так или иначе с интеллектуальной деятельностью, будь то программное обеспечение или же книги, фильмы и другие продукты, основой которых является проектирование. Эти факторы представлены на рис. 2. Эти факторы могут оказывать различное воздействие, которое зависит от размера и вида программного проекта. Для очень больших систем, состоящих из отдельных подсистем и разрабатываемых разными командами программистов, технология разработки является ключевым фактором, влияющим на качество конечного продукта. Для таких проектов проблемными оказываются вопросы интеграции, управления и обеспечения взаимодействия. Так как разработка ПО продолжается несколько лет, состав рабочих групп может меняться, кроме того, они состоят из специалистов с самыми разными возможностями и опытом. Состав группы может полностью поменяться за период выполнения проекта. Из этого следует, что влияние талантливых специалистов, имеющих особые навыки, не является доминирующим. Рис. 2. Основные факторы, влияющие на качество программного обеспечения Однако, если говорить о небольших проектах, где над реализацией работает несколько профессионалов, качество работы членов команды более важно, чем качественный технологический процесс. Если все члены команды имеют высокую квалификацию и достаточно опытны, более вероятно получение высококачественного продукта. В том случае, если команда не имеет навыков и опыта, качество технологического процесса может способствовать повышению качества продукции, однако не устранит в полной мере все погрешности и недоработки. С другой стороны, в небольших командах хорошо разработанная технология имеет особое значение. Ведь члены команды не могут посвятить все свое время кропотливой бумажной работе. Наоборот, они проводят основную часть времени за разработкой и программированием системы, поэтому хорошие средства поддержки окажутся удачным подспорьем и повысят производительность труда. В больших проектах базовый уровень технологического процесса важен для управления потоком информации. Парадоксально, но при этом снижается влияние средств поддержки высокого уровня. Члены команды, стараясь понять различные компоненты системы, больше времени тратят на общение, чем на сам процесс программирования. Именно это, а не средства разработки, оказывается доминирующим фактором, влияющим на их производительность. Факторы, положенные в основу прямоугольника на рис, 2, наиболее критичны. Качество продукта пострадает в любом случае, как только будет неправильно произведен расчет средств на выполнение проекта (независимо от его размера) либо будет представлен нереальный график работ, что сделает невозможным своевременное выполнение проекта. Для успешной реализации проекта необходимо достаточное количество материальных и временных ресурсов. В противном случае проект может спасти только высококвалифицированный и преданный персонал. И даже тогда при остром дефиците средств может пострадать качество конечного продукта. Довольно часто оказывается, что причина появления на рынке программных продуктов низкого качества кроется отнюдь не в слабом управлении, плохо налаженном производстве или необученном персонале. Причина в другом: компании борются за выживание. Чтобы заполучить контракт на разработку программного продукта, многие компании дают заниженную оценку затрат. Назначение заниженной «выигрышной» цены — это необратимое следствие системы конкуренции. Поэтому неудивительно, что контроль качества товаров в таких условиях оказывается нелегкой задачей. 2. Анализ и моделирование производства Анализ и моделирование производства ПО предполагает изучение используемых процессов разработки и их моделирование для определения ключевых параметров. Частные варианты этих моделей постоянно используются в качестве примеров при рассмотрении отдельных тем, таких, как разработка требований, проектирование и т.д. Анализ действующей технологии основан на ее тщательном изучении в целях выявления взаимосвязей между различными стадиями процесса производства. Первым шагом будет, несомненно, анализ качества, цель которого - определение основных параметров модели производства. Далее: исследователь должен перейти к количественному анализу процесса разработки с использованием различных показателей, значения которых определяются автоматически или вручную. Только после этого технологический процесс можно представить в виде модели. Анализ технологического процесса можно начать, принимая за основу его стандартную модель, которая существует в большинстве компаний или может определяться заказчиком. В таких стандартных моделях почти всегда определены основные этапы разработки и жизненный цикл создаваемых программных продуктов. Стандартные модели удобны для начала анализа процесса создания ПО. Однако такие модели слишком обобщенные и предназначены лишь для общего описания основных этапов процесса разработки программного обеспечения. Всегда важно проникнуть в суть модели и выявить реально действующий процесс. Кроме того, действующий процесс может значительно отличаться от формальной модели. В анализе производственного процесса используется два метода. 1. Анкетирование и опросы. Специалисты, работающие над программным проектом, заполняют анкеты, предоставляя информацию о реальном ходе проекта. Для официальной анкеты ответы уточняются во время индивидуальных интервью. 2. Этнографические исследования. Этнографическое исследование – метод качественного исследования, при котором исследователь наблюдает за объектом исследования изнутри, погружаясь в естественную среду, в которой живет и работает целевая аудитория. Он используется для: • понимания потребностей, желаний и мотивации целевой аудитории; • изучения привычек, повседневных практик, образа жизни целевой аудитории; • разработки, дизайна и тестирования нового продукта, услуги или сайта. Благодаря этому типу анализа раскрываются все тонкости и сложности, недостижимые для понимания в случае применения других методик. Каждый из этих подходов имеет свои достоинства и недостатки. Если правильно составить вопросы, анкетирование поможет провести анализ сравнительно быстро. И наоборот, некорректно сформулированные или неверные вопросы приведут к созданию неправильной модели процесса. Кроме того, такой анализ имеет много общего с оцениванием. Поэтому опрашиваемые могут не сказать правду и даже дать те ответы, которые, по их мнению, будут желательны проводящему опрос. Этнографический анализ на первый взгляд даст более верные результаты. Однако эта процедура достаточно длительная и кропотливая, она может продолжаться несколько месяцев. Кроме того, здесь данные основаны на внешнем наблюдении за процессом. Полный анализ происходящего должен проводиться с самой начальной стадии внедрения проекта и до поставки готового продукта заказчику и его последующего сопровождения. Это может оказаться непрактичным, так как график внедрения некоторых проектов растягивается на несколько лет. Поэтому этнографический анализ принесет больше пользы при детальном рассмотрении отдельных фрагментов процесса производства. Результатом анализа можно считать модель производственного процесса любого уровня детализации. На абстрактном уровне производственные процессы в разных организациях кажутся похожими. Однако, в зависимости от типа разрабатываемого программного обеспечения и рабочей среды организации, типовые модели детализируются и принимают определенный конкретный вид. Для первоначального обсуждения процесса разработки типовая модель незаменима. Однако информации, которая в ней содержится, не достаточно для анализа процесса и внесения изменений. Для совершенствования процесса необходимы данные об этапах разработки, выходных результатах каждого такого этапа, персонале, качестве коммуникаций, графике работ и других компонентах деятельности организации по реализации проекта, так как все это может повлиять на создание ПО и должно быть учтено в модели производственного процесса. В табл. 2 описаны элементы, входящие в состав детализированной модели технологического процесса создания ПО (с указанием, как эти элементы изображаются на схеме модели). Модель также должна отображать нерабочие периоды времени в реализации проекта и взаимозависимость между этапами процесса разработки и контрольными проектными элементами, поскольку эти этапы можно выполнять как параллельно, так и последовательно. Все элементы проекта взаимосвязаны, например один и тот же специалист может быть задействован на разных этапах создания ПО. Контрольные проектные элементы могут зависеть от других контрольных элементов и даже от взаимоотношений между специалистами, работающими над проектом. Детализированные модели процесса создания ПО отличаются чрезвычайной сложностью. Создание единой модели, отображающей все аспекты производственного процесса, является крайне трудной и ответственной задачей. Чтобы показать, насколько сложными бывают подобные модели, рассмотрим фрагмент процесса тестирования отдельного программного модуля большой системы, где используется процесс управления конфигурацией. На рис. 3 показаны взаимоотношения между процессом тестирования, входом и выходом этого процесса, а также между пред- и постусловиями. Таблица 2. Элементы модели процесса создания ПО Элемент модели Описание Действие (изображается прямоугольником с закругленными краями без тени) Имеет четко поставленную цель, определены «вход» и «выход» действия. Примеры действий: подготовка тестовых данных для тестирования модулей, написание кода функции или модуля, редактирование документов и т.п. Обычно действие представляет собой элементарную часть этапа процесса, выполняется одним человеком или группой и не может быть разбито на более мелкие действия Этап процесса (изображается прямоугольником с закругленными краями и с тенью) Состоит из набора действий, связанных между собой и решающих общую задачу. Примеры этапов: анализ требований, проектирование системной архитектуры, планирование тестирования системы и т.д. Контрольный проектный элемент (изображается как прямоугольник с тенью) Это реальный результат действия или этапа, предусмотренный планом проекта Условие (изображается параллелограммом) Может быть либо предусловием и соблюдаться до начала выполнения этапа или действия, либо постусловием, которое должно выполняться после окончания действия или этапа Роль (изображается в виде круга) Очерчивает область ответственности лиц, работающих над проектом. Примеры ролей: менеджер по конфигурации, специалист по тестированию, проектировщик ПО и т.п. Несколько ролей могут выполняться одним и тем же специалистом, так же как и одна роль может быть разделена между несколькими лицами Исключение (в приведенном ниже примере не присутствует, изображается в виде ромба) Это описание способов изменения технологического процесса в случае возникновения ожидаемых либо непредвиденных обстоятельств. В основном учитываются непредвиденные обстоятельства, поэтому присутствие этого элемента в модели зависит от изобретательности и предвидения менеджеров и разработчиков Связь (изображается направленной стрелкой) Отображает обмен информацией между людьми либо между человеком и компьютерными системами поддержки. Связи разделяются на формальные и неформальные. К формальным относится утверждение менеджером контрольного проектного элемента, примером неформальных связей может быть общение разработчиков по электронной почте для выяснения непонятных мест в документации Рис. 3. Процесс тестирования программного модуля На рис. 4 этап тестирования модуля разложен на составляющие действия. Этот фрагмент демонстрирует лишь малую часть общего процесса тестирования программных модулей. Четыре основных потока действий включают подготовку тестовых данных, написание тестовых процедур, проведение тестирования и создание отчетности о результатах тестирования. Рис. 4. Действия по тестированию модуля Я намеренно не включил в эту модель пред- и постусловия и данные о входе и выходе этапа, так как это только усложнит модель и затруднит ее понимание. Не следует пытаться вместить всю информацию в одну-единственную модель. Лучше создать несколько моделей разного уровня обобщения и связать их какими-либо общими элементами, будь то действия или контрольные проектные элементы. Одни модели могут представлять этапы процесса производства, другие - данные, управляющие выполнением процесса. Исключения в процессе создания ПО Сам по себе процесс создания программного обеспечения - понятие достаточно сложное. Даже если организация разработала модель технологического процесса создания ПО, это еще не значит, что разработчики не столкнутся с какой-либо проблемой, не предусмотренной заранее. В действительности реагирование на такие непредусмотренные проблемы - часть повседневной работы менеджеров проекта. Поэтому идеальной представляется модель технологического процесса, которую можно легко изменять в ходе решения возникающих проблем. Ниже приведены примеры непредусмотренной ситуаций, к которым менеджер должен быть готов практически каждый день. 1. Ключевые разработчики могут заболеть и не выйти на работу как раз перед решающей проверкой проекта. 2. Невозможен обмен данными вследствие неисправности линий связи. 3. Вполне вероятно изменение структуры компании, в результате чего менеджеры будут тратить больше времени на решение организационных вопросов, вместо того чтобы работать над проектом. 4. Возможно вовлечение большего количества персонала в разработку нового проекта, имеющего больший приоритет, чем текущий. В основном непредвиденные ситуации влияют на ресурсы, бюджет и график работ. Практически невозможно предусмотреть все экстремальные ситуации и включить их в организационную модель процесса. Поэтому в большинстве случаев менеджерам проектов приходится на ходу справляться с возникающими трудностями и вносить соответствующие изменения в стандартный процесс создания ПО. 3. Измерение производственного процесса Измерение процесса создания ПО заключается в сборе количественных данных, характеризующих этот процесс. Сбор количественных показателей производственного процесса - необходимая составляющая его совершенствования. Эти показатели помогают узнать, насколько повысилась эффективность процесса после внесения изменений. Например, можно провести измерение времени и средств, потраченных на тестирование до изменения производства. Если совершенствование было эффективным, это должно снизить затраты, время или то и другое. Однако измерения сами по себе ничего не скажут об улучшении качества конечного продукта. Дополнительно необходимо иметь представление о значении показателей программного продукта и сопоставлении полученных результатов с новым процессом разработки. Среди показателей процесса разработки выделим три вида. 1. Время, потраченное на выполнение отдельного этапа работ. Это может быть только рабочее время выполнения этапа, календарное время выполнения этапа или время работы отдельного специалиста. 2. Ресурсы, необходимые для реализации этапа работ. Ресурсы могут подсчитываться в человеко-днях, затратах на командировки либо ресурсах вычислительной техники. 3. Количество повторений одного и того же события. Среди таких событий можно назвать количество ошибок, обнаруженных при проверке программного кода, количество изменений в системных требованиях, среднее количество измененных строк кода и т.д. Первые два вида показателей применяются для определения эффективности изменений процесса. Например, процесс разработки содержит несколько фиксированных временных точек, среди которых создание системной спецификации, завершение проектирования системной архитектуры, завершение формирования тестовых данных. При этом можно измерить время и средства, потраченные на переход от одной фиксированной точки к другой. Полученные результаты помогут определить те составляющие процесса, которые нуждаются в совершенствовании. После выполнения изменений следует измерить показатели процесса с тем, чтобы получить данные об эффективности изменений. Измерение количества повторений одного события имеет более непосредственное отношение к качеству программного продукта. Например, обнаружение большего количества ошибок с помощью новой программы проверки, вероятно, улучшит качество готового продукта. Основная проблема, связанная с измерением процесса создания ПО, - необходимость знать, что именно следует измерить. Для решения этого вопроса предлагается парадигма GQM (Goal-Question-Metric - цель-вопрос-показатель), с помощью которой определяется вид измерения и способ его использования. Эта парадигма основана «на трех китах». 1. Цель. Что является целью компании по совершенствованию процесса создания ПО? Это может быть повышение производительности труда программистов, сокращение времени разработки, повышение надежности готового продукта и т.д. 2. Вопросы. Это детализация поставленной цели. Как правило, каждая цель соотносится с рядом вопросов. Приведем примеры вопросов к указанным выше целям. • Как повысить количество строк кода, отлаженных программистом? • Как сократить время заключительного этапа разработки требований? • Как повысить эффективность проверки системы на надежность? 3. Показатель. Это та информация, которая поможет ответить на сформулированные вопросы, в частности определить, достигнуты или нет поставленные цели. Например, можно определить показатель производительности программистов, выражаемый в строках написанного ими кода, такой показатель, как уровень их профессионального опыта, показатель, равный количеству официальных контактов между заказчиком и исполнителем по каждому изменению системных требований, а также показатель количества проведенных тестов для выявления ошибок в системе. Главное преимущество данного подхода состоит в том, что в нем разделены организационная деятельность (цели) и процесс производства (вопросы). Внимание концентрируется на сборе определенных данных и предусматривает разные способы анализа результатов измерения в зависимости от поставленного вопроса. Подход GQM был объединен с описанной в следующем разделе моделью оценки уровня развития, разработанной Институтом инженерии программного обеспечения (США), что нашло свое воплощение в методе совершенствования процесса разработки ПО. Разработчики этого метода предлагают поэтапный подход к совершенствованию процесса создания ПО. Этот подход основан на введении измерений только после того, как организация достигнет достаточного уровня развития технологии. Подход предлагает руководство и практические советы по внедрению измерений в целях совершенствования производства. 4. Модель оценки уровня развития Институт инженерии программного обеспечения (Software Engineering Institute - SEI) при университете Карнеги-Меллон, получающий финансирование от Министерства обороны США, занимается распространением технологий создания ПО. Институт был учрежден с целью расширить возможности индустрии программного обеспечения в США, особенно для организаций, финансируемых Министерством обороны. В середине 80-х годов институт начал исследования по оценке возможностей компаний - разработчиков ПО. Особое внимание было уделено тем компаниям, которые подали заявки на финансирование проектов от Министерства обороны. Результатом такой работы явилась модель оценки уровня развития в создании ПО. Модель оказалась чрезвычайно эффективным средством, сумевшим убедить сообщество программистов отнестись более серьезно к вопросу совершенствования процесса разработки ПО. Модель разбивает процесс создания ПО на пять этапов (рис. 5). Рис. 5. Модель оценки уровня развития SEI 1. Начальный уровень. На этом уровне компания не имеет установленных процедур управления персоналом и планирования проектов. Даже если формальные процедуры для контроля над проектами и существуют, нет действующих механизмов проверки правильности использования этих процедур. Такая компания может успешно заниматься разработкой ПО, однако качество конечного продукта, а также ход выполнения проекта (соблюдение бюджета и графика работ) предсказать трудно. 2. Уровень повторения. В компании уже сложился определенный стиль управления, имеются системы управления качеством и конфигурацией. Название уровня обусловлено тем, что на данной стадии организация уже способна повторять проекты одного типа. Однако все-таки чувствуется недостаток организационной модели технологического процесса. Успех проекта зависит в основном от умения менеджеров вдохновить команду разработчиков и от возможности формализовать интуитивно понятный процесс разработки. 3. Уровень становления. Компания вводит стандартную технологию создания ПО, обеспечивая возможность совершенствования производственного процесса на количественном уровне. Приводятся в действие процессуальные нормы, которые гарантируют выполнение стандартного процесса во всех проектах. 4. Уровень управления. Компания уже имеет стандартную технологию создания ПО и программу сбора количественных данных. Накапливаются данные о показателях программных продуктов и процесса производства, которые впоследствии используются для совершенствования технологии разработки ПО. 5. Уровень оптимизации, которым предусматривается определенная приверженность организации-разработчика делу непрерывного совершенствования процесса создания ПО. Это означает, что совершенствование заложено в бюджете и плане деятельности организации и является ее неотъемлемой частью. Первая версия модели оценки уровня развития подверглась жесткой критике за свою неопределенность. После приобретения опыта применения этой модели была разработана ее новая версия. В ней были сохранены все пять уровней, однако теперь они более строго соотносились с ключевыми составляющими процесса создания ПО (рис. 6.). Результатом совершенствования процесса должно быть внедрение в производство этих ключевых составляющих, а не достижение некоторого уровня, определенного моделью. Такой подход был использован при разработке модели оценки уровня развития системы управления требованиями. Рис. 6. Ключевые составляющие процесса создания ПО (©1993 IEEE) Работа над моделью оценки уровня развития в SEI проводилась с учетом методов статистического контроля качества в промышленности. Допуская некоторое сходство между промышленным производством и производством программного обеспечения, я все же не думаю, что возможен простой перенос результатов, полученных в промышленности, в сферу разработки ПО. Как уже упоминалось в разделе 1, качество программного продукта может испытывать на себе влияние личностных факторов, например опыта и знаний программистов. В этой области деятельности такие факторы не менее важны, чем производственные. Модель SEI оценки уровня развития достаточно весома и важна, однако я бы не советовал применять ее как единственную основу, определяющую весь процесс создания ПО. Она была предназначена в основном для компаний, которые занимаются разработкой программных систем для Министерства обороны, и служб, с ним связанных. Эти системы отличаются большими размерами и длительным сроком эксплуатации, а также сложностью интерфейса с аппаратным обеспечением и другими системами ПО. Над созданием таких систем работают достаточно большие команды программистов, которые должны подчиняться требованиям и стандартам, разработанным Министерством обороны США. Первые три уровня модели SEI относительно легки для понимания. Среди основных составляющих процесса создания ПО есть и те, которые часто применяются в промышленном производстве. Некоторые организации-разработчики в состоянии достигнуть высших уровней модели, однако стандарты и процедуры, используемые на этих уровнях, не всегда понятны широкому кругу специалистов. Известны случаи, когда успешно работающая компания не соответствует модели SEI, что вызвано обстоятельствами, присущими только данной организации. Проблемы, с которыми организация может столкнуться на высших уровнях модели, никоим образом не ставят под сомнение полезность самой модели SEI. Однако на три основные проблемы все же стоит обратить внимание. Именно они могут снизить возможности организации в создании высококачественных продуктов. 1. Модель сосредоточена исключительно на управлении проектом, а не на процессе создания программного продукта. В модели не учтены такие важные факторы, как использование определенных технологий, например прототипирования, формальных и структурных методов, средств статического анализа и т.п. 2. В модели отсутствует анализ рисков и решений]. Ранее мы отмечали важность оценки рисков, что позволяет обнаруживать проблемы прежде, чем они окажут воздействие на процесс разработки. 3. Не определена область применения модели, хотя авторы признают, что модель не является универсальной и подходящей всем организациям. Однако авторы не дают четкого разграничения организаций, которые могут или не могут внедрять модель в свою деятельность. Небольшие компании находят эту модель слишком бюрократичной. В ответ на эту критику были разработаны стратегии совершенствования технологического процесса для малых организаций. Возможно сравнение модели оценки уровня развития со стандартами ISO 9000 управления качеством. Каждая составляющая процесса из модели оценки уровня развития может сравниваться с требованиями процесса управления качеством. В большинстве случаев можно обнаружить взаимосвязь между составляющими процесса модели SEI и требованиями ISO 9000. Модель SEI более детализирована и предоставляет основу для совершенствования процесса создания ПО, что не предусмотрено в стандартах ISO 9000. Организации, которые дошли до второго или третьего уровней развитая по модели SEI, более других соответствуют стандартам ISO 9000. Однако в связи с определенной абстрактностью стандартов ISO 9000 организации и на первом уровне развития могут претендовать на соответствие этим стандартам. Институт SEI разработал несколько других моделей оценки уровня развития, например: модель оценки уровня развития процесса разработки программных систем, модель оценки приобретения, предназначенную для оценки приобретенного организацией программного и аппаратного обеспечения, модель оценки уровня развития персонала и др. Говоря о модели SEI оценки уровня развития, иногда забывают о том, что главной целью создания модели было намерение Министерства обороны США оценить возможности поставщиков программного обеспечения. На данный момент пока не существует четких требований к достижению определенного уровня развития организаций-разработчиков. Однако принято считать, что у организации, достигшей высокого уровня, больше шансов выиграть тендер на поставку ПО. Модель оценки уровня развития ориентирована в основном на оценивание всей организации, а не отдельных проектов. С точки зрения разработчиков, это справедливо. Если организация находится, скажем, на первом уровне модели, это совсем не значит, что ее проекты должны котироваться так же низко. Отдельные команды программистов могут работать на более высоком уровне. Основой оценивания уровня организации-разработчика является анкета, которая должна определить ключевые процессы в деятельности организации. Она заполняется путем опроса менеджеров разных проектов. Ответы, занесенные в анкету, анализируются, после чего выводится общий счет. Модель процесса оценивания показана на рис. 7. Рис. 7. Процесс оценивания уровня развития организации Основной недостаток этого процесса оценивания, на наш взгляд, состоит в чрезмерном внимании к достижению высокого уровня. Организация обязана выполнить все предписанные моделью действия на определенном уровне, только тогда ей будет присвоен этот уровень. Даже если организация достигла 80% по второму уровню и 70% по третьему, все равно она будет котироваться первым уровнем. Здесь уместен более структурированный подход, учитывающий применяемые в данной организации виды деятельности и стандарты. Метод оценивания уровня развития и совершенствования производственного процесса SPICE отличается большей гибкостью. Этот метод был предложен в качестве основы для улучшения стандарта ISO. В нем были сохранены уровни модели SEI, но добавлены другие ключевые виды деятельности (например, процесс «заказчик-поставщик»), которые проходят через все уровни. Целью проекта Bootstrap было расширение и адаптация модели SEI к более широкому кругу организаций. В результате появилась одноименная модель, в которой сохранены основные принципы модели SEI, однако имеется ряд нововведений. • Предлагается система управления качеством для поддержки процесса совершенствования производства ПО. • Проведено разграничение организации, методологии и технологии. • Предложена базовая модель процесса разработки ПО (создана по образцу модели, используемой в Европейском аэрокосмическом агентстве). Рассматриваемые модели оценки развиваются с учетом всех альтернативных подходов. 5. Классификация процессов совершенствования Как уже отмечалось, классификация процессов совершенствования производства программного обеспечения по модели SEI больше подходит для процесса разработки больших и длительно эксплуатируемых систем, создаваемых большими компаниями-разработчиками. Для малых и средних компаний-разработчиков данная модель подходит не в полной мере. Вместо того чтобы разбивать процесс совершенствования производства на уровни и строить между ними нестойкие взаимосвязи, рациональнее, по моему мнению, применить обобщенную классификацию процессов совершенствования производства, которая подходит большинству организаций и программных проектов. Можно выделить несколько общих типов процессов совершенствования. 1. Неформальный процесс. Не имеет четко выраженной модели совершенствования производства. Его с успехом может использовать отдельная команда разработчиков. Неформальность процесса никоим образом не исключает такие формальные действия, как управление конфигурацией; однако при этом сами действия и их взаимосвязи не предопределены заранее. 2. Управляемый процесс. Имеет подготовленную модель, которая управляет процессом совершенствования. Модель определяет действия, их график и взаимосвязи между ними. 3. Методически обоснованный процесс. Подразумевается, что введены в действие определенные методы (например, систематически применяются методы объектно-ориентированного проектирования). Для процессов этого типа будут полезными CASE-средства поддержки проектирования и анализа процессов. 4. Процесс непосредственного совершенствования. Имеет четко поставленную цель совершенствования технологического процесса, для чего существует отдельная строка в бюджете организации и определены нормы и процедуры внедрения нововведений. Частью такого процесса является количественный анализ процесса совершенствования. Эту классификацию не назовешь четкой и исчерпывающей - некоторые процессы могут одновременно относиться к нескольким типам. Например, неформальность процесса является выбором команды разработчиков. Эта же команда может выбрать определенную методику разработки, имея при этом все возможности непосредственного совершенствования процесса. Такой процесс подпадает под классификацию неформальный, методически обоснованный, непосредственного совершенствования. Необходимость приведенной классификации обусловлена тем, что она предоставляет своего рода костяк для комплексного совершенствования технологии создания ПО и дает возможность организации выбирать разные типы процессов совершенствования. На рис. 8 показаны соотношения между разными типами программных систем и процессами совершенствования их разработки. Знание типа разрабатываемого продукта сделает соответствие между программными системами и процессами совершенствования, показанное на рис. 8, полезным при выборе процесса совершенствования. Например, требуется создать программу поддержки перехода ПО с одной компьютерной платформы на другую. Такая программа имеет достаточно короткий срок эксплуатации, поэтому в ее разработке не требуются стандарты и специальное управление процессом совершенствования, как при создании долгоживущих систем. Рис. 8. Применимость процессов совершенствования Многие технологические процессы в наше время имеют CASE-средства поддержки, поэтому их можно назвать поддерживаемыми процессами. Методически обоснованные процессы поддерживаются инструментальными средствами анализа и проектирования. Эффективность средства поддержки зависит от применяемого процесса совершенствования. Например, в неформальном процессе могут использоваться типовые средства поддержки (средства прототипирования, компиляторы, средства отладки, текстовые процессоры и т.п.). Вряд ли в неформальных процессах будут использоваться на постоянной основе более специализированные средства поддержки. На рис. 9 показан широкий спектр средств поддержки, применяемых при разработке ПО. Эффективность отдельных средств напрямую зависит от типа выбранного процесса совершенствования. Например, с финансовой точки зрения только инструментальные средства анализа и проектирования подойдут для сопровождения методически обоснованного процесса. Специализированные средства применяются для совершенствования определенных процессов разработки ПО. Рис. 9. Средства поддержки процессов совершенствования 6. Структуры наследуемых систем Понятие «наследуемая система» гораздо шире понятия «старые и давно используемые системы ПО», хотя именно программный компонент этих систем нас интересует больше всего. Наследуемая система представляет собой сложную социотехническую систему, основанную на использовании вычислительной техники, которая включает программное обеспечение, аппаратные средства, используемые данные и бизнес-процессы. Изменения одной из составляющих системы влечет за собой изменение других ее компонентов. Эти системы разрабатывались с учетом организационных стратегий и планов конкретной организации, но не всегда учитывали объективные инженерные критерии. Логические составляющие наследуемых систем и взаимосвязи между ними перечислены ниже и показаны на рис. 10. 1. Аппаратные средства. В большинстве своем наследуемые системы были созданы для работы на больших универсальных электронно-вычислительных машинах, которые уже не выпускаются. Эти машины отличаются дороговизной эксплуатации и несовместимы с современными вычислительными средствами. 2. Программные средства поддержки. Наследуемая система может основываться на самых разных средствах поддержки, начиная с операционных систем и обслуживающих программ и заканчивая компиляторами, используемыми при создании системы. Все это может быть давно устаревшим и не поддерживаться их производителями. 3. Прикладное программное обеспечение. Как уже отмечалось, прикладная система, обеспечивающая услуги в сфере бизнеса, обычно состоит из нескольких отдельных программ, которые разрабатывались в разное время. Часто термин «наследуемая система» относится именно к этим прикладным программам, а не ко всей системе в целом. 4. Данные. Это данные, с которыми работает прикладная система. Многие системы за время эксплуатации накапливают огромное количество данных, среди которых можно обнаружить как неверные, так и дубликаты, содержащиеся в разных файлах. 5. Бизнес-процессы. Это вид деловой активности для достижения коммерческих целей. Если взять в качестве примера страховую компанию, бизнес-процессом в ней может быть применение политики страхования, а для промышленной компании бизнес-процессом будет считаться прием заказа на производство определенного продукта и определение технологии производственного процесса. 6. Политика и правила деловой активности. Здесь определяются способ ведения и различные ограничения деловой активности компании. Эти политики и правила часто лежат в основе построения и эксплуатации наследуемых прикладных систем. Рис. 10. Компоненты наследуемых систем Другой взгляд на наследуемые системы представлен на рис. 11, где наследуемая система показана в виде многоуровневой модели. Каждый уровень зависит от нижнего, взаимодействуя с ним посредством интерфейса. В идеале эти интерфейсы должны позволять проводить изменения на отдельных уровнях без влияния или согласования с другими уровнями. Социотехническая система Бизнес - процессы Прикладное программное обеспечение Программные средства поддержки Аппаратное обеспечение Рис. 11. Многоуровневая модель наследуемой системы На практике вмешательство в один уровень обязательно повлечет за собой изменения на других уровнях. Это происходит по нескольким причинам. 1. Изменения на каком-либо уровне в большинстве случаев связаны с внедрением новых средств. Чтобы вышестоящий уровень мог использовать эти средства, его нужно также изменить. Например, на уровень программных средств поддержки внедряется новая база данных, которая предоставляет доступ к данным с помощью Web-броузера. Тогда уровень бизнес-процессов потребуется изменить для того, чтобы иметь возможность использовать это средство. 2. Изменение программного обеспечения может снизить скорость выполнения системы, для ее повышения нужно установить новые аппаратные средства. Повышение производительности системы провоцирует внесение изменений для использования возможностей, которые ранее были недоступны. 3. Сохранение интерфейсов аппаратных средств со временем часто становится невозможным, особенно в случае кардинальных изменений в аппаратном обеспечении. Такое может случиться с компанией, которая решит перейти от мэйнфреймов (больших ЭВМ) к системе клиент/сервер, где, как правило, работают с разными операционными системами. В этом случае необходима серьезная модернизация прикладного программного обеспечения. Прикладное программное обеспечение наследуемой системы — это не только отдельная программа, а целый комплекс программ. Конечно, первоначально в системе может быть только одна программа, работающая с одним-двумя файлами данных, однако со временем в систему могут быть включены другие программы, осуществляющие обмен данными и связь с другими системными программами. Таким же образом с поступлением новой информации пополняются изначальные файлы данных. Этот процесс отображен на рис. 12. Программы осуществляют обмен файлами данных, поэтому изменения в одной программе обязательно отразятся на других. Рис. 12. Наследуемые прикладные системы В наше время еще можно найти системы, которые используют отдельные файлы для хранения данных, однако большинство систем уже перешли на централизованное хранение информации в базах данных (рис. 13). Преимущество такого подхода заключается в том, что для представления данных используются логические и физические модели данных. Это позволяет избежать или снизить уровень избыточности и дублирования информации, правильно оценить воздействие на данные каких-либо изменений в системе. Кроме того, базы данных обеспечивают средства обработки транзакций, гарантирующие восстановление данных. Ими также обеспечивается диалоговое обновление информации. Запросы на обновление информации могут поступать с различных терминалов и в разное время. Возьмем для примера банковскую систему, насчитывающую сотни терминалов, с которыми работают кассиры в филиалах и клиенты, пользующиеся банкоматами. Обработка всех отдельных транзакций сконцентрирована в центральной базе данных счетов. Монитор дистанционной обработки (например, система CICS от IBM) может обрабатывать и помещать в буфер вводные данные из многих различных источников. В банковской системе он принимает транзакции от филиалов и банкоматов, при этом возможна первичная обработка на месте. Затем транзакции помещаются в буфер и предоставляются в базу данных счетов в виде последовательного списка; база данных обновляет счета клиентов и подтверждает завершение обработки транзакций. Эта процедура показана на рис. 14. Рис. 13. Система с централизованной базой данных Рис. 14. Обработка транзакций с использованием монитора дистанционной обработки Наследуемые системы с централизованными базами данных также имеют недостатки. 1. Система управления базой данных может быть устаревшей и несовместимой с современными СУБД, используемыми в бизнесе. Из всех современных систем баз данных, применяемых в бизнесе, наиболее эффективными считаются реляционные базы данных. Однако многие наследуемые системы используют иерархические или сетевые базы данных. Такие базы данных создавались скорее для повышения функциональности системы, чем для удобства управления данными. Современная вычислительная техника снимает требование повышения функциональности системы, но переход к реляционным моделям данных может оказаться слишком дорогостоящим. 2. Монитор дистанционной обработки часто создавался для специализированных баз данных, рассчитанных на эксплуатацию на мэйнфреймах. Поэтому такой монитор не подойдет для современных баз данных. Эта часть системы подлежит обязательной замене, вследствие чего возрастают расходы и риск, связанные с изменениями системы. 7. Проектирование наследуемых систем Практически все наследуемые системы были созданы до того, как объектно-ориентированный подход стал широко использоваться при создании ПО. Поэтому, вместо того чтобы представлять собой совокупность взаимосвязанных объектов, программы в таких системах структурированы как множество подпрограмм и функций. Каждая подпрограмма обеспечивает определенную часть функциональности системы и в случае необходимости вызывается другими подпрограммами. В некоторых же языках программирования подпрограммы оперируют собственными данными, имея в то же время доступ к совместно используемым данным. В других языках (например, ранние версии COBOL) для всех подпрограмм открыт совместный доступ к общим данным. Стратегия функционально-ориентированного проектирования ПО предусматривает декомпозицию программ на ряд функций и подпрограмм, взаимодействующих с централизованной совместно используемой памятью (рис. 15). Информация о локальном состоянии функций обрабатывается только в процессе их исполнения. Такая стратегия является частью многих структурных методов, разработанных в конце 70-х - начале 80-х годов. Она получила название «нисходящее проектирование» и «структурное проектирование». Сотни тысяч прикладных программ разработаны с помощью этих методов и соответствующих CASE-средств. Рис. 15. Функционально-ориентированный подход к проектированию ПО Функционально-ориентированное проектирование скрывает детали алгоритмов в подпрограммах и функциях, однако информация о состоянии системы при этом открыта. В этом могут таиться проблемы, поскольку функция способна изменить состояние системы непредвиденным образом. Изменения в самой функции и состоянии системы могут привести к изменениям в поведении других функций. Это большая проблема наследуемых систем, особенно если представить, сколько разных людей вносили изменения в систему за время ее существования: один человек едва ли способен разобраться в том, каким образом взаимодействуют разные части системы. Функциональный подход к проектированию будет эффективен лишь в том случае, если свести к минимуму количество открытой информации о состоянии системы и сделать обмен информацией более явным. Системы, которые зависят от входных данных или сигналов и не зависят от предыстории входных данных, обладают определенной функциональной направленностью. Большинство систем обработки деловой информации предназначены для обработки отдельных (дискретных) записей. Работа с новой записью не зависит от результатов обработки предыдущей. Поэтому при создании таких систем выгоднее использовать функциональное программирование. Системы обработки деловой информации представляют собой самый большой класс наследуемых систем и разделяются на два типа. 1. Системы пакетной обработки данных. Ввод-вывод данных осуществляется в пакетном режиме из файлов, а не с терминала пользователя. Такими системами являются программы начисления заработной платы, выписки счетов и т.д. 2. Системы обработки транзакций. Ввод-вывод данных представляет собой серию транзакций, обрабатываемых системой управления базой данных, при этом транзакции генерируются терминалом пользователя. Конечно, эти различные системы могут также использовать общие данные. Например, банк при работе со счетами использует систему обработки транзакций, но при создании выписок из банковских счетов клиентов используется система пакетной обработки данных. Обе системы (пакетной обработки данных и обработки транзакций) действуют в соответствии с моделью «вход-процесс-выход», показанной на рис. 16. Системы осуществляют ввод данных из одного или нескольких источников, обрабатывают их и выдают выходные данные, которые в той или иной степени связаны с входными. В качестве примера можно рассмотреть систему телефонных счетов, где входными данными являются записи о звонках клиента и информация со счетчика коммутатора АТС, которые затем обрабатываются компьютером, в результате на выходе системы - счета за пользование телефоном. Рис. 16. Модель «вход-процесс-выход» Системные компоненты ввода, обработки и вывода информации также могут быть разбиты по принципу «вход-процесс-выход», например следующим образом. 1. Компонент входа может включать непосредственный ввод информации с терминала пользователя (вход), проверку достоверности данных и исправление некоторых ошибок (процесс), затем помещение данных в очередь на обработку (выход). 2. В компонент обработки может входить получение транзакции из очереди (вход), подсчет данных, создание новой записи по результатам подсчета (процесс) и помещение новой записи в очередь на печать (выход). 3. Компонент выхода состоит из считывания записей из очереди (вход), форматирования записей в соответствии с формой вывода (процесс) и последующей отправки их на печать (выход). При проектировании функционально-ориентированных систем часто используются диаграммы потоков данных. Диаграммы потоков данных — это функциональное представление, где прямоугольник с закругленными краями представляет функцию, выполняющую преобразование данных, а стрелка - элемент данных, обрабатываемый функцией. Файлы и другие хранилища данных представлены в виде прямоугольников. Диаграммы отображают сквозной процесс обработки, т.е. показывают все функции системы, которые взаимодействуют с данными, когда они (данные) проходят по разным стадиям обработки и преобразований. Для иллюстрации функционально-ориентированного проектирования с помощью диаграммы потоков данных рассмотрим рис. 17, на котором показана структура системы по расчету заработной платы. Это система пакетной обработки данных. Она считывает информацию о служащих компании, затем рассчитываются платежи и отчисления за месяц, после чего начисляется заработная плата. Рассмотрим, как эта система реализует структуру «вход-процесс-выход». Рис. 17. Потоковая диаграмма системы выплаты зарплат 1. Функции «Считывание записи о служащем», «Считывание данных о платежах за месяц» и «Проверка правильности данных о служащем» реализуют ввод и проверку данных о каждом сотруднике. 2. Функция «Расчет зарплаты» обрабатывает всю информацию об окладе до удержания налогов по каждому служащему, а также данные об отчислениях с зарплаты. Результатом этого является «чистая» зарплата за месяц. 3. Функции вывода осуществляют запись в ряд файлов, в которых содержится отдельная информация по отчислениям с зарплаты. Эти файлы обрабатываются другими программами после того, как будет произведен расчет данных для всех служащих. Вслед за этим следует распечатка платежной ведомости, в которой указаны суммы выплат и отчислений. Удачным примером системы обработки транзакций является система, контролирующая сеть банкоматов. На услуги, предоставляемые пользователям, не влияют предварительные операции, поэтому они могут рассматриваться как отдельные транзакции. В листинге 1 приведена упрощенная версия такой системы. Следует заметить, что вместо языка программирования Java я использовал функционально-ориентированный язык. Java - объектно-ориентированный язык программирования, поэтому не подходит для описания функционально-ориентированных систем. Листинг 1. Описание системы управления банкоматами ВХОД loop repeat Печать_сообщение(«Добро пожаловать! Вставьте Вашу карточку») until Карточка_ввод Счет_номер:= Считывание_карточка; Получение_счет (РIN_код, Счет_баланс, Наличность_доступность); ПРОЦЕСС if карточка_недействительна (РIN_код) then Задержать_карточку; Print («Карточка задержана - пожалуйста, свяжитесь с Вашим банком»); else repeat Печать_операция_выбор_сообщение; Кнопка:= Получение_кнопка; case Получение_кнопка is when Наличность_только => Выдача_наличность_(Наличность_доступна, Сумма_выдача); when Печать_остаток => Печать_клиент_остаток (Счет_остаток); when Отчет => Заказ_отчет (Счет_номер); when Чековая_книжка => Заказ_чековая_книжка (Счет_номер); end case; Print («Нажмите ПРОДОЛЖИТЬ для других операций либо СТОП»); Кнопка:= Получение_кнопка; until Кнопка = СТОП ВЫХОД Извлечь_карточку; Print («Пожалуйста, извлеките Вашу карточку»); Обновление_счет (Счет_номер, Счет_выдача); end loop; В этом проекте работа системы реализуется в виде цикла, где операции начинают выполняться после ввода пользователем карточки. Системные функции (Выдача_наличность, Получение_счет, Заказ_отчет, Заказ_чековая_книжка и др.) можно определить при реализации системы. Контроль за состоянием системы, осуществляемый программой, минимален. Операции по обслуживанию клиентов выполняются индивидуально и не взаимодействуют между собой. Очевидно, что функционально-ориентированное проектирование будет использоваться при разработке программных систем еще много лет. Конечно, эта технология не привязана к разработке наследуемых систем, она может использоваться и для создания новых систем в следующих ситуациях. 1. При создании систем обработки данных, основанных на работе с транзакциями и обновлении баз данных. Программа, обрабатывающая транзакции, не нуждается в информации о предыдущих транзакциях, поэтому нет необходимости в объектах, работающих с локальными данными. Здесь наблюдается следование модели «вход-процесс-выход», которая рассмотрена выше. 2. В компаниях, вложивших значительные средства в структурные методы, соответствующие CASE-средства и обучение персонала. Здесь будут неоправданными риск и затраты, связанные с переходом на объектно-ориентированное проектирование. Хотя функционально-ориентированный подход во многом считается устаревшим, объектно-ориентированное проектирование в подобных ситуациях не будет оправданным. Таким образом, перед нами стоит интересная задача: обеспечить совместную работу двух подходов к программированию - объектно-ориентированного и функционально-ориентированного. 8. Оценивание наследуемых систем Организации, деятельность которых во многом зависит от наследуемых систем и средства которых на их сопровождение и модернизацию ограниченны, должны хорошо подумать над тем, как получить максимум от вложений в наследуемую систему. Это прежде всего означает корректную оценку наследуемой системы и выбор наиболее подходящей стратегии ее модернизации. Существует четыре стратегических пути решения этой задачи. 1. Полностью отказаться от системы. Это решение применимо в случае, если система не отвечает своим задачам поддержки бизнес-процессов. Например, со времени установки системы бизнес-процессы изменились настолько, что уже практически не зависят от работы системы. Чаще всего это случается там, где универсальные ЭВМ были заменены персональными компьютерами, а устаревшее программное обеспечение было модернизировано в той мере, в которой это необходимо для продолжения его работы на ПК. 2. Продолжить сопровождение системы. Это решение подходит в ситуациях, когда система более или менее стабильна и все еще полезна в работе, а пользователи не требуют ее значительного изменения. 3. Модернизировать систему для улучшения сопровождения. Этот путь следует выбрать тогда, когда качество работы системы снизилось в результате частых изменений, причем дальнейшие изменения все еще будут необходимы. 4. Заменить старую систему более новой. Этот вариант применяется в том случае, если в связи с появлением современных аппаратных средств старая система становится непригодной в эксплуатации или если уже имеются подобные системы, и разработка новых на их основе не будет слишком дорогостоящей. Естественно, нет однозначного решения данной проблемы - к системе, состоящей из нескольких отдельных программ, можно применить несколько различных подходов. При оценивании наследуемую систему нужно рассматривать под разными углами зрения. С коммерческой точки зрения необходимо провести оценку полезности и пригодности системы для бизнеса. Что же касается перспективы дальнейшей работы системы, нужно в первую очередь оценить качество прикладного ПО, а также программных и аппаратных средств поддержки данной системы. Комбинация двух оценок - бизнес-пригодность и качество - поможет решить, что же делать с наследуемой системой дальше. Для демонстрации применения такой комплексной оценки рассмотрим организацию, использующую в работе 10 наследуемых систем. Качество и бизнес-пригодность каждой из этих систем были оценены с помощью некоторых количественных показателей. Результаты оценивания представлены на рис. 18. Рис. 18. Бизнес-пригодность и качество систем На рис. 18 видно четыре группы систем, которые определяются следующими оценками. 1. Низкое качество, низкая бизнес-пригодность. Решение оставить такие системы в действии дорого обойдется, а отдача в бизнесе будет незначительной. Такие системы - прямые кандидаты на списание. 2. Низкое качество, высокая бизнес-пригодность. Такие системы вносят немалый вклад в бизнес-деятельность, поэтому списывать их нельзя. Однако низкий уровень качества означает высокие расходы на сопровождение системы. Такие системы подлежат модернизации или замене (при условии наличия другой подходящей системы). 3. Высокое качество, низкая бизнес-пригодность. Такие системы не очень полезны, но недороги в эксплуатации. Риск вследствие замены таких систем не оправдан, поэтому их можно оставить в работе и в дальнейшем списать. 4. Высокое качество, высокая бизнес-пригодность. Их можно оставить, ведь высокое качество означает отсутствие необходимости модернизации или замены системы. Поэтому с ними продолжаем работать, как и прежде. В идеале для решения того, что делать с системой дальше, должны использоваться подобные объективные оценки. Однако неоднократно отмечалось, что в действительности при принятии таких решений главную роль играют организационные или политические соображения. Например, при слиянии компаний будут использоваться системы более сильного (в политическом смысле) партнера, а все другие системы будут списаны. Или если руководство компании примет решение о переходе на новую вычислительную технику, то прикладные программы также подлежат замене. Также и в случае ограниченного бюджета, который не позволяет провести модернизацию системы в текущем году, поэтому будет продолжено сопровождение старой системы, даже с неблагоприятными экономическими перспективами. 8.1. Оценка бизнес-пригодности Оценка бизнес-пригодности системы в определенной мере субъективна, поскольку не существует идеальных объективных методов ее определения. Здесь, как во всех случаях субъективного оценивания, полагаясь только на одно мнение, вы получите весьма искаженный результат. Чтобы избежать этого, я предлагаю подход, который предусматривает оценивание бизнес-пригодности системы под разными углами зрения. Предлагаю несколько опорных точек зрения и соответствующих вопросов, которые помогут в оценке бизнес-пригодности. 1. Точка зрения конечного пользователя системы. Насколько эффективна данная система для поддержки работы пользователя? Какой процент использования функциональных возможностей системы? 2. Точка зрения заказчиков. Является ли работа системы ясной и понятной для заказчика? Имеются ли ограничения при взаимодействии заказчика с системой? 3. Точка зрения менеджеров. Какое влияние оказывает система на деятельность их подразделения? Оправданы ли средства, потраченные на сопровождение системы? Насколько важными для работы подразделения являются данные, обрабатываемые системой? 4. Точка зрения менеджеров группы сопровождения системы. Трудно ли найти специалистов для работы с системой? Можно ли ресурсы, затрачиваемые на сопровождение системы, вложить в другие системы с большей эффективностью? 5. Точка зрения руководства компании. Насколько зависит от системы достижение коммерческих целей компании и решение бизнес-задач? После определения опорных точек зрения необходимо проинтервьюировать представителей каждой группы и сравнить их ответы. Это даст четкую оценку бизнес-пригодности системы. 8.2. Оценка качества системы Из представления наследуемых систем, показанного на рис. 11, видно, что их составными частями также являются бизнес-процесс, аппаратные средства и программные средства поддержки. Чтобы оценить качество системы, нужно изучить все ее уровни, только после этого можно поместить ее на одну из позиций в схеме, показанной на рис. 18. Но универсального метода оценки качества системы не существует. Оценка зависит от вида системы и деловой сферы, в которой она используется. Оценка бизнес-процесса Оценивание качества бизнес-процесса тесно связано с оцениванием бизнес-пригодности системы. Но учитывая, что бизнес-процесс составляет часть наследуемой системы, для решения об уровне качества необходимо иметь достаточно подробную информацию о бизнес-процессе. Это важный момент, поскольку при неудовлетворительном качестве бизнес-процесса необходимо вносить соответствующие изменения в систему. Для оценки бизнес-процесса я бы предложил подход, ориентированный на сопоставлении разных опорных точек зрения. Вот несколько вопросов, которые можно использовать для такого сопоставления. 1. Существует ли в организации четкая модель бизнес-процесса, а также процедуры для контроля соответствия бизнес-процесса этой модели? 2. Следуют ли разные подразделения компании одинаковым бизнес-процессам при выполнении одинаковых функций? 3. Каким образом специалисты, вовлеченные в процесс, адаптировали его к условиям своей работы? 4. Есть ли необходимость во взаимосвязи с другими бизнес-процессами, и насколько эта взаимосвязь ясна пользователям? 5. Поддерживается ли бизнес-процесс наследуемыми прикладными системами? Предоставляется ли необходимая информация? Требуется ли для процесса дублирование данных в разных местах? При этом вас не должны удивлять совершенно разные ответы на эти вопросы от разных групп интервьюируемых. Например, менеджеры могут считать процесс достаточно эффективным, хотя на самом деле он таковым не является. Составляя мнение о качестве бизнес-процесса, не следует полагаться на сопроводительную документацию. Лучше сосредоточиться на ответах лиц, участвующих в реальных бизнес-процессах. Оценка окружения На рис. 11 видно, что окружение прикладной системы включает ПО поддержки (операционные системы, компиляторы, служебные программы и т.д.) и аппаратные средства, на которых исполняется система. Фактор окружения иногда является ключевым при принятии решения об изменениях в прикладной системе, поэтому важна оценка системного окружения. Для оценивания системного окружения необходимо изучить саму систему и процесс ее сопровождения. Например, полезной окажется информация о стоимости эксплуатации аппаратных средств и ПО поддержки, количестве сбоев аппаратных средств за определенный период времени, а также о частоте настройки ПО поддержки. В табл. 3 приведены факторы, которые будут полезными при оценке системного окружения. Обратите внимание, что не все факторы чисто технического характера. Например, необходимо оценивать также надежность поставщиков аппаратных средств и программного обеспечения. Если поставщики ушли с рынка, это означает отсутствие надлежащего сопровождения системы. Оценка прикладного ПО Процесс оценивания качества существующего прикладного программного обеспечения значительно отличается от процесса оценивания качества во время разработки ПО. Это обусловлено спецификой наследуемых систем, состоящей в том, что они создавались с применением тех технологий и стандартов, которые, может быть, уже отошли в прошлое, структура системы изменена вследствие частых изменений, а системная документация, возможно, устарела. Некоторые факторы, которые следует учитывать при оценке качества прикладного ПО, описаны в табл. 4. Таблица 3. Факторы системного окружения Фактор Вопросы для оценки фактора Стабильность поставщиков аппаратных средств и ПО Присутствует ли поставщик на рынке? Насколько стабилен поставщик в финансовом плане и каковы прогнозы относительно его присутствия на рынке? Если поставщик ушел с рынка, то кем осуществляется сопровождение систем? Количество сбоев аппаратных средств и ПО Характеризуются ли аппаратные средства высоким уровнем сбоев в работе? Является ли ПО поддержки причиной аварийных перезагрузок системы? Возраст аппаратных средств и ПО Каков «возраст» аппаратного и программного обеспечения? Даже если оно работает без сбоев, переход к новым системам может оказаться экономически выгодным Производительность Насколько производительность системы соответствует требованиям современных бизнес-процессов? Испытывают ли пользователи неудобства, связанные с проблемами производительности системы? Необходимость в средствах поддержки Какие средства поддержки требуются для сопровождение программного и аппаратного обеспечения? Если на сопровождение уходит значительное количество средств, то может разумнее заменить систему? Стоимость эксплуатации Насколько велика стоимость эксплуатации аппаратных средств и затраты на закупку лицензий на программные средства поддержки? Затраты на сопровождение устаревшей техники могут быть несравнимо выше, чем на содержание более современной техники. Кроме того, ежегодное обновление лицензий на ПО может также дорого обходиться Способность к взаимодействию с другими системами Возникают ли проблемы, связанные с интерфейсом между данной и другими системами? Можно ли использовать компиляторы или другие средства с текущей версией операционной системы? Требуется ли эмуляция аппаратных средств? Таблица 4. Факторы, используемые при оценке качества прикладного ПО Фактор Вопросы для оценки фактора Простота понимания Насколько трудно понять исходный код действующей системы? Каков уровень сложности используемых управляющих структур? Присвоены ли переменным значащие имена, показывающие их назначение? Документация Какая системная документация имеется в наличии? Является ли эта документация полной, последовательной и отвечающей современным требованиям? Данные Есть ли четкая модель данных, используемых в системе? Дублируются ли данные в разных файлах системы? Производительность Соответствует ли качество выполнения системы современным требованиям? Влияет ли производительность системы на работу пользователей? Язык программирования Есть ли современные компиляторы для языка программирования, с помощью которого создавалась система? Используется ли этот язык для создания современных систем? Управление конфигурацией Распространяется ли действие системы управления конфигурацией на все версии всех частей системы? Есть ли четкое описание всех версий системных компонентов? Тестовые данные Имеются ли тестовые данные? Есть ли записи о тестированиях, проведенных после введения в систему новых компонентов? Обслуживающий персонал Реально ли найти специалистов для обслуживания данной системы? Много ли профессионалов, способных разобраться с этой системой? При проведении анализа качества системы также полезными будут количественные показатели. 1. Количество изменений, внесенных в систему. Частые изменения искажают структуру системы и усложняют проведение последующих модернизаций. Чем выше этот показатель, тем менее качественной будет система. 2. Количество пользовательских интерфейсов, используемых системой. Этот показатель особенно важен для систем, интерфейс которых основан на использовании различных форм ввода (каждую форму можно рассматривать как отдельный интерфейс). Чем больше различных интерфейсов, тем чаще будут встречаться в них несоответствия и избыточность. 3. Объем данных, используемых в системе. Высокие значения этого показателя (количество файлов, размер базы данных и т.д.) показывают значительную сложность системы. Несмотря на несомненную полезность этих показателей, получение их числовых значений может потребовать значительных расходов. Кроме того, это также не абсолютные и не универсальные характеристики качества наследуемых систем. При использовании количественных показателей следует учесть еще размер и возраст системы.