И. Соммервилл - Инженерия программного обеспечения (1133538), страница 143
Текст из файла (страница 143)
Чем больше различных интерфейсов, тем чаще будут встречаться в них несоответствия и избыточность. 3. Ойем оагсиьи, исиольлуеммх в силлаке. Высокие значения этого показателя (количество файлов, размер базы даппьпс и т.д.) показывают значительную сложность системы. г Д КЛЮЧЕВЫЕ ПОНЯТИЯ Наследуемой называют систему, разработанную давно и.долго зксплуатируемую; 'но все еще не - обходимую и полезную дял бизнес-девтельности. -, " . Несмотря на несомненную попсзность этих покззатезей, получение Их чисЛовых значений может потребовать значительных расходов.
Кроме того, это также не абсолютные и не универсальные характеристики качества наследуемых систем. При использоынии количественных показателей следует учесть еще размер и возраст системы. 26. Наследуемые системы 549 . ф,, вйй 'сйствма —, зтгг нв только прйкладные пррГ(и(ммы, 'ЭтО.кОмплюксные„сОциятехнйче.
"" " 'ззйзй(ютеоньте'систвмын составными частями которых:являются'бизнес-пройесссчй чйрикла(~-';. ,. „"",'й(Й?ПМ(яй((а(КО6ЕСйеЙВНйЕ,' ПОтвудцбржхм И'аааратНПЕ4редтстща'! ":*'"~":-.:. Ли""':О-'' ф 62 пйшщатвацюадедуе(ямг",систем созданы с использованием фуню(йаиальибЙ(рбвшЙровщаюго: яЬЙдц?Ййегчей" анФ',прццсщшмюк,'саббй,,ю?мя(яКодзвййадвбствующйх йодйра айщйЮ~свььзаййых'посрб((саам'-'первдайй(ЙЙЙ пщтЙЙетров Й абвйебт?ю'-тюполь- "„цт(щнщщциями, и те, которые обрабатывщот(тметй ттанных, Оба типа систем соотввт- -стйуяф„'стргуьктурной модели "вход-процесс-выход'.
" 4, °,"' ' а том'; что следует делать с системой (заменить, модернизировать либо оставить в испгу; ~'„.фуа(твании),' оснодывзется на оценках бизнес-пригодности, качества прикладного ПО и систем- ~':,;!-""„=:йонга окружеййя, 'бй' 'т,"сБизивс-припввюсть ~ апредшм~ Й ~~'ащай~ ~~ бимюс-аавп. (-''е., „", Качество. системы зависимо от качества бизнес-процесса,'.качества прикладного ПО, а таске от г,,,:,", качества' ммрапвщсредсщ «программных средств поддврщщ. Упражнения 26.1. Объясните, чем определяется важность наследуемых систем в деловой сфере. 26.2.
Приведите три причины усложнения понимания системы вследствие участия многих специалистов в измененвщ системы. 26.3. Какие проблемы могут возникнуть в случае программирования разных частей системы на различ- ных языках? 26.4. Какова роль монитора дистанционной обработки при сборе системой данных ог разных терминалов? Каким образом современные системы типа клиент/сервер снижают нагрузку на монитор дистанционной обработки? 26.6. Большинство наследуемых систем созданы на основе функционально-ориентированного подхода.
Объясните, почему функционально-ориентированное проектирование наследуемых систем зффективнее обьекгно-ориентированного. 26.6. С учетам представленной ниже информации расширьте систему расчета заработной платы (см. рис. 26.6) и постройте соответствующую диаграмму потока данных, описывающую вычисления в втой системе. ° Учетная запись о работнике содержит тарифный разряд, определяющий размер его заработной маты. ° Сверхурочная работа, если выплаты за нее ниже определенной суммы, оплачивается на уровне основной почасовой ставки. Тариф сверхурочных часов указан в учетных документах работника. Сумма удержанных налогов зависит от специального налогового кода работника, который указан в его тгютной записи, а также ат оклада. Суммы окладов и ежемесячных отчислений, зависящих от налогового кода, указаны в налоговой таблице.
26.7. Чем можно обосновать списание системы даже тогда, когда она имеет высокие оценки качества и бизнес-пригодности? 550 Часть 7П. Эволхоцня программного обеспечения 26.8. Предложите 10 вопросов, которые можно задать пользователям системы для оценки бизнеспроцесса. 26.9. Объясните, почему проблемы с программным обеспечением поддермщ могут стать причиной замены наследуемых систем. 26.10.
Руководство компании поручила еам организовать и провести оценку системы таким образом, что. бы доказать необходимость замены системы, поскольку она устарела и непригодна к использованию. Вы знаете, что зто приведет к сокращению ряда специалистов, обслуживакхцих старую сис. тему. Наша оценка доказывает обратное — система отличается высоким уровнем качества и бизнес-пригодности. Как вы отобразите этот факт в отчете руководству компании? Модернизация программного обеспечения 444 "4 Настоящая глава посвящена вопросам изменения программного обеспечения и описывает различные способы модификации программных систем. Прочитав эту главу, вы должны: знать основные стратегии иодерпизации про. граммных систем, а именно: сопровождение системы, эволюцию системной архитектуры и реинжениринг программного обеспечения; ориентироваться в принципах сопровождения ПО и понимать причины увеличения расходов на сопровождение систем; знать, каким образом наследуемую систему иожно преобразовать в распределенную систему клиент/сервер, чтобы продлить срок эксплуатации системы и обеспечить более эффективное ее использование на основе современных аппаратных средств.
г,;Содержаниес ':.:-...'.; 4:;:.,;.:~.=-'~М~4Ва: ~~ф 27.1. Динамика развития программ 27.2. Сопровождение программного обеспечения 27.5. Эволюция системной архитектуры 552 ~Масть УП. Эволюция программного обеспечении Невозможно создать систему, которая не потребует изменений в будущем. Как только программное обеспечение вводится в эксплуатацию, возникают новые требования к системе, обусловленные непрерывным развитием бизнес-процессов и все возрастающими общими требованиями к программным системам. Иногда в системе следует изменвть не. которые составляющие в целях повышения производительности или улучшения других характеристик, а также для исправления обнаруженных ошибок. Все это требует дальнейшего развития системы после ее ввода в эксплуатацию.
Полная зависимость органиэаций от программного обеспечения, которое к тому же обходится в достаточно круглую сумму, объясняет исключительную важность серьезного отношения к ПО. Это предусматривает дополнительные вложения в эволюцию уже эксплуатируемой системы с тем, чтобы обеспечить прежний уровень ее производительности. Существует несколько стратегических подходов к процессу модернизации ПО [889]. 1.
Сояйовождение пфозРпммного обесяечгккя Это наиболее часто используемый подход, который заключается в изменении отдельных частей ПО в ответ на растущие тре. бования, но с сохранением основной системной структуры. Подробнее этот вопрос освещен в разделе 27.2. 2. Эаааюцил сисжемнай архкэмхжуры. Этот подход более раликаяьный, чем сопровождение ПО, так как предполагает существенные изменения в программной системе.
Эта стратепзя модернизации ПО подробно раскрыта в разделе 27.3. 3. Реинжениринг программного абгглгчеккя. Кардинально отличается от других подходов, так как модернизация предусматривает не внесение каких-то новых компонентов, а наоборот, упрощение сисгемы и удаление из нее всего лишнего. При этом возможны изменения в архитектуре, но без серьезных переделок. Этому вопросу посвящена глава 28.
Приведенные стратегии не исключают одна друго. Иногда для упрощения системы перед изменением архитекгуры или для переделки некоторых ее компонентов применяется реинжениринг. Некоторые части системы заменяются серийными, а более стабилы ные системные компоненты продолжают функционирование. Как уже упоминалось в главе26, выбор стратегии модерниэации системы осповываетсл не только на технических характеристиках, но и на том, насколько хорошо система поддерживает деловую активность компании.
Разные стратегии могут также применяться к отдельным частям системы или к отдель. ным программам наследуемой системы. Сопровождение приемлемо для программ со стабильной н четкой структурой, не требующей особого внимания. Для других программ, которые постоянно контактируют со многими пользователями, можно изменить архитектуру так, чтобы интерфейс пользователя запускался на машине клиента. Еще один компонент в этой жс системе можно заменить аналогичной программой стороннего производителя. Однако при реинжсниринге обычно необходимо изменять все компоненты системы.
Изменения в ПО служат причиной появления многочисленных версий системы и ее компонентов. Поэтому особенно важно внимательно следить за всеми этими изменениями, а также за тем, чтобы версия компонента соответствовала той версии системы, в которой он применяется. Управление изменениями системы называется управлением конфи~уранией и обсуждается в главе 29. 27.