Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Проектирование и разработка информационных систем. Учебное пособие для СПО

.pdf

Скачиваний:

Добавлен:

08.09.2026

Размер:

2 Мб

Скачать

☆

<<< < Предыдущая 1 2 34 / 174 5 6 7 8 9 10 11 12 13 14 15 16 17 > Следующая >>>

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

1.2. Проектирование (системный синтез)

Системный синтез (см. гл. 3) начинается с этапа проектирования ИС, который, в свою очередь, делится на:

– эскизное (архитектурное) проектирование;

– проектирование детальное.

Задача эскизного проектирования — разработка архитек- туры и интерфейса проекта ИС. Что же понимается под этими понятиями?

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

Термин «интерфейс» (от англ, interface: inter внутрь, face лицо; в буквальном переводе «лицом к лицу») имеет три значения:

1) связь между двумя обрабатывающими компонентами;

2) полная совокупность соглашений о входных и выход-

ных сигналах, которыми могут обмениваться:

– устройство — устройство;

– программа — среда — программы;

– человек — система обработки;

3) (физическая) реализация интерфейса.

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

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

первичных концептуальных положений до проработки деталей структуры, функционирования, объектов, интерфейса и т.д. проектируемой ИС.

Рассмотрим также понятие бизнес-процесса

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

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

1. Производительность. Если критическим требованием

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

2. Защищенность. В этом случае архитектура должна

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

3. Безопасность. В этом случае архитектуру следует спро-

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

4. Надежность. В этом случае следует разработать архи-

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

5. Удобство сопровождения. Здесь архитектуру системы

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

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

1.3. Кодирование (системный синтез)

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

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

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

Современное программирование использует объектноориентированную парадигму (ООП), которая пришла на смену

парадигме структурного программирования, впрочем, вобрав все постулаты последней. Она базируется на трех «китах»:

– наследовании;

– инкапсуляции;

– полиморфизме.

Следует обратить внимание на последнее достижение в этой области — технологию XP-экстремального программирования.

Отладка — наиболее трудоемкий процесс в проектировании. Скрытые ошибки иногда проявляются при первом же запуске самой простой программы, а иногда «прячутся» годами. В систему ошибки попадают, конечно, не по желанию разработчика просто надо быть морально готовыми к тому, что в столь сложной системе, какой является программа объемом в сотни тысяч строк, избежать ошибок невозможно. Выявление скрытых ошибок в таком комплексе специалисты приравнивают к искусству.

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

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

Рис. 1.3. Процесс отладки

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

Исследователи насчитывают 169 типов ошибок, которые

объединены в 19 больших классов:

1) логические;

2) ошибки манипулирования данными;

3) ошибки ввода / вывода;

4) ошибки в вычислениях;

5) ошибки в пользовательских интерфейсах;

6) ошибки в операционной системе и вспомогательных

программах;

7) ошибки компоновки;

8) ошибки в межпрограммных интерфейсах;

9) ошибки в интерфейсах «Программа системное ПО»;

10) ошибки при обращении с внешними устройствами;

11) ошибки сопряжения с БД;

12) ошибки инициализации БД;

13) ошибки изменений по запросу извне;

14) связанные с глобальными переменными;

15) повторяющиеся;

16) ошибки в документации;

17) нарушение технических требований;

18) неопознанные;

19) ошибки оператора.

Важно отметить, что далеко не все ошибки исходят от разработчика. По данным разных исследователей, от 6 до 19 % ошибок порождаются ошибками в документации! Вот уж воистину «не верь глазам своим!» — приходится проверять все, что вы еще только собираетесь использовать, и для этого разрабатывают специальные тесты.

1.4. Верификация и аттестация

Верификацией и аттестацией называют процессы проверки и анализа, в ходе которой проверяется соответствие программного обеспечения ТЗ и требованиям заказчиков (рис. 1.4).

Рис. 1.4. Верификация на этапах разработки ПО

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

Верификация (проверка правильности) отвечает на вопрос, соответствует ли ИС техническому заданию, в частности функциональным и системным требованиям.

Аттестация проводится после верификации и выявляет, насколько система соответствует ожиданиям заказчика, а не только требованиям ТЗ. Итогом аттестации являются документы, подписываемые как заказчиком, так и разработчиком.

В верификации и аттестации используются две основные методики: инспектирование и тестирование.

Инспектирование сравнительно новое явление в программировании. Оно осуществляет статическую проверку ПО, то

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

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

Инспектирование — эффективный метод обнаружения ошибок, и что немаловажно, оно значительно дешевле тестирования программ. Более 60 % ошибок в программах можно обнаружить с его помощью.

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

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

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

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

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

1.4.1. Тестирование на этапе разработки требований

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

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

1) сравнительный анализ;

2) дискуссионные группы;

3) обследование объекта.

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

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

– Адекватны ли эти требования? Действительно ли именно такой продукт компания хочет создать?

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

– Совместимы ли требования между собой? Требования к продукту (и его функции) могут оказаться логически или пси-

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

– Выполнимы ли они? Не требуется ли для нормальной эксплуатации продукта более быстрое аппаратное обеспечение, больший объем памяти, более высокая пропускная способность, большее разрешение (и т. д.), чем указано в документации?

– Разумны ли они? К сожалению, качество продукта и его рентабельность стоят по разную сторону баррикад: с одной стороны — производительность продукта, его надежность и нетребовательность к ресурсам, а с другой — время и стоимость его разработки. Найдено ли самое оптимальное соответствие между всеми этими характеристиками? Не требуется ли от продукта абсолютная безупречность, молниеносная работа и готовность конкурировать с программным обеспечением, которого еще нет и в проекте? Отдельные из этих требований вполне достижимы, но не одновременно и не для одного и того же продукта. Поэтому при планировании принципиально важно правильно расставить приоритеты.

– Поддаются ли они тестированию? Насколько легко можно будет определить, соответствует ли инженерно-проектная документация требованиям к программному продукту.

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

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

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

– Многие языки или системы разработки не подходят для создания быстрого и дешевого прототипа.

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

1.4.2. Тестирование на этапе проектирования

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

– Действительно ли проект хорош? Будет ли на его основе создан эффективный, компактный, хорошо тестируемый и легкий в сопровождении и модернизации продукт?

– Соответствует ли проект требованиям? Проект должен быть формализованным выражением требований, представленных в документации этапа планирования.

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

<<< < Предыдущая 1 2 34 / 174 5 6 7 8 9 10 11 12 13 14 15 16 17 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]