Добавлен: 25.10.2018
Просмотров: 6988
Скачиваний: 27
использования, диаграммы классов и др. – для объектно-ориентированного
подхода.
Процедур, определяющих практическое применение метода
(последовательность и правила построения моделей, критерии, используемые для
оценки результатов).
Методы реализуются через конкретные технологии и поддерживающие их
методики, стандарты и инструментальные средства, которые обеспечивают
выполнение процессов ЖЦ ПО.
Технология проектирования определяется как совокупность технологических
операций проектирования в их последовательности и взаимосвязи, приводящая к
разработке проекта ПО.
ТРЕБОВАНИЯ К ТЕХНОЛОГИИ
Современная технология проектирования должна обеспечивать:
1. Соответствие стандарту ISO/IEC 12207: 1995 (поддержка всех
процессов ЖЦ ПО).
2. Гарантированное достижение целей разработки ЭИС в рамках
установленного бюджета, с заданным качеством и в установленное время.
3. Возможность
декомпозиции проекта
на
составные
части,
разрабатываемые группами исполнителей ограниченной численности (3-7 чел.), с
последующей интеграцией составных частей.
4. Минимальное время получения работоспособного ПО ЭИС. Речь идет
не о сроках готовности всей ЭИС, а о сроках реализации отдельных подсистем.
Практика показывает, что даже при наличии полностью завершенного проекта
внедрение ЭИС идет последовательно по отдельным подсистемам.
5. Независимость получаемых проектных решений от средств
реализации ЭИС (СУБД, ОС, языков и систем программирования).
6. Поддержка
комплексом
согласованных
CASE
–
средств,
обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ ПО.
Реальное применение любой технологии проектирования ПО ЭИС в
конкретной организации и конкретном проекте невозможно без выработки ряда
стандартов (правил, соглашений), которые должны соблюдаться всеми
участниками проекта. К таким стандартам относятся:
1.
Стандарт проектирования.
2.
Стандарт оформления проектной документации.
3.
Стандарт интерфейса конечного пользователя с системой.
Стандарт проектирования должен устанавливать:
Набор необходимых моделей (диаграмм) на каждой стадии
проектирования и степень их детализации.
Правила фиксации проектных решений на диаграммах, в том числе
правила именования объектов (включая соглашения по терминологии), набор
атрибутов для всех объектов и правила их заполнения на каждой стадии, правила
оформления диаграмм (включая требования к форме и размерам объектов) и т.д.
Требования к конфигурации рабочих мест разработчиков, включая
настройки ОС, настройки CASE – средств и т.д.
Механизм обеспечения совместной работы над проектом, в том числе
правила интеграции подсистем проекта, правила поддержания проекта в
одинаковом для всех разработчиков состоянии (регламент обмена проектной
информацией, механизм фиксации общих объектов и т.д.), правила анализа
проектных решений на непротиворечивость и т.д.
Стандарт
оформления проектной документации. Он должен
устанавливать:
комплектность, состав и структуру документации на каждой стадии
проектирования (в соответствии со стандартом ГОСТ Р ИСО 9127 – 94
«Системы обработки информации. Документация пользователя и
информация на упаковке потребительских программных пакетов»);
требования к оформлению документации (включая требования к
содержанию разделов, подразделов, пунктов, таблиц и т.д.);
правила подготовки, рассмотрения, согласования и утверждения
документации с указанием предельных сроков на каждой стадии;
требования к настройке издательской системы, используемой в качестве
встроенного средства подготовки документации;
требования к настройке CASE – средств для обеспечения подготовки
документации в соответствии с установленными правилами.
Стандарт интерфейса конечного пользователя с системой. Он должен
регламентировать:
Правила оформления экранов (шрифты и цветовая палитра), состав и
расположение окон и элементов управления.
Правила использования клавиатуры и мыши.
Правила оформления текстов помощи.
Перечень стандартных сообщений.
Правила обработки реакций пользователя.
Стандарт пользовательского интерфейса для диалоговых информационных
технологий фирмы IBM с некоторыми пояснениями приведен в приложении 1
данной работы.
Детальное конструирование ПО
СУЩНОСТЬ СТРУКТУРНОГО ПОДХОДА. МЕТОДЫ ДОКУМЕНТИРОВАНИЯ ПО
Сущность структурного подхода. Принципы, на которых базируется
структурный подход. Метод SADT. Метод DFD.
Проблема сложности является главной проблемой, которую приходится
решать при создании больших систем любой природы, в том числе и ЭИС. Ни
один разработчик не в состоянии выйти за пределы человеческих возможностей и
понять все систему в целом. Единственно эффективный подход к решению этой
проблемы заключается в построении сложной системы из небольшого количества
крупных частей, каждая из которых, в свою очередь, строится из частей меньшего
размера и т.д., до тех пор, пока самые небольшие части можно будет строить из
имеющегося материала. Этот подход известен под самыми разными названиями,
среди них такие, как «разделяй и властвуй», иерархическая декомпозиция и др. по
отношению к проектированию сложной программной системы это означает, что ее
необходимо разделять (декомпозировать) на небольшие подсистемы, каждую из
которых можно разрабатывать независимо от других. Это позволяет при разработке
подсистемы любого уровня держать в уме информацию только о ней, а не обо всех
остальных частях системы. Правильная декомпозиция является главным способом
преодоления сложности разработки больших систем. Понятие «правильная» по
отношению к декомпозиции означает следующее:
1. Количество связей между отдельными подсистемами должно быть
минимальным.
2. Связность отдельных частей внутри каждой подсистемы должна быть
максимальной.
Структура системы должна быть таковой, чтобы все взаимодействия между ее
подсистемами укладывались в ограниченные, стандартные рамки:
1. Каждая подсистема должна инкапсулировать свою содержимое
(скрывать его от других подсистем).
2. Каждая подсистема должна иметь четко определенный интерфейс с
другими подсистемами.
На сегодняшний день в программной инженерии существуют два основных
подхода к разработке ПО ЭИС, принципиальное различие которых обусловлено
разными способами декомпозиции систем. Первый подход называется
функционально-модульным или структурным. В его основу положен принцип
функциональной декомпозиции, при которой структура системы описывается в
терминах иерархии ее функций и передачи информации между отдельными
функциональными элементами. Второй, объектно-ориентированный подход
использует объектную декомпозицию. При этом структура системы описывается в
терминах объектов и связей между ними, а поведение системы описывается в
терминах обмена сообщениями между объектами.
Итак, сущность структурного подхода к разработке ПО ЭИС заключается в ее
декомпозиции (разбиении) на автоматизируемые функции: система разбивается на
функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те
- на задачи и так далее до конкретных процедур. При этом система сохраняет
целостное представление, в котором все составляющие компоненты
взаимоувязаны. При разработке системы «снизу-вверх», от отдельных задач ко всей
системе,
целостность
теряется, возникают
проблемы
при описании
информационного взаимодействия отдельных компонентов.
Все наиболее распространенные методы структурного подхода базируются на
ряде общих принципов:
1. Принцип «разделяй и властвуй»;
2. Принцип иерархического упорядочения - принцип организации
составных частей системы в иерархические древовидные структуры с добавлением
новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы
являются второстепенными, т.к. игнорирование любого из них может привести к
непредсказуемым последствиям (в том числе и к провалу всего проекта»).
Основными из этих принципов являются:
1. Принцип абстрагирования - выделение существенных аспектов системы
и отвлечение от несущественных.
2. Принцип непротиворечивости обоснованность и согласованность
элементов системы.
3. Принцип структурирования данных - данные должны быть
структурированы и иерархически организованы.
В структурном подходе в основном две группы средств, описывающих
функциональную структуру системы и отношения между данными. Каждой группе
средств соответствуют определенные виды моделей (диаграмм), наиболее
распространенными среди них являются:
DFD (Data Flow Diagrams) - диаграммы потоков данных;
SADT (Structured Analysis and Design Technique - метод структурного анализа и
проектирования) - модели и соответствующие функциональные диаграммы;
ERD (Entity - Relationship Diagrams) - диаграммы «сущность-связь».
Практически во всех методах структурного подхода (структурного анализа) на
стадии формирования требований к ПО используются две группы средств
моделирования:
1. Диаграммы, иллюстрирующие функции, которые система должна
выполнять, и связи между этими функциями - DFD или SADT (IDEF0).
2. Диаграммы, моделирующие данные и их отношения (ERD).
Конкретный вид перечисленных диаграмм и интерпретация их конструкций
зависят от стадии ЖЦ ПО.
На стадии формирования требований к ПО SADT - модели и DFD
используются для построения модели “AS-IS” и модели “TO-BE”, отражая таким
образом существующую и предлагаемую структуру бизнес - процессов
организации и взаимодействие между ними (использование SADT - моделей , как
правило, ограничивается только данной стадией, поскольку они изначально не
предназначались для проектирования ПО). С помощью ERD выполняется описание
используемых в организации данных на концептуальном уровне, не зависимо от
средств реализации базы данных (СУБД).
На стадии проектирования DFD используются для описания структуры
проектируемой системы.
Перечисленные модели в совокупности дают полное описание ПО ЭИС
независимо от того, является ли система существующей или вновь
разрабатываемой.
ТЕМА 7. ТЕСТИРОВАНИЕ ПО
ТЕСТИРОВАНИЕ - СПОСОБ ОБЕСПЕЧЕНИЯ КАЧЕСТВА
Качество
программного
продукта
характеризуется
набором
свойств,определяющих, насколько продукт "хорош" с точки зрения
заинтересованных сторон, таких как заказчик продукта, спонсор,конечный
пользователь, разработчики и тестировщики продукта, инженеры поддержки,
сотрудники отделов маркетинга, обучения и продаж. Каждый из участников
может иметь различное представление о продукте и о том,насколько он
хорош или плох, то есть о том, насколько высоко качество продукта. Таким
образом, постановка задачи обеспечения качества продукта выливается в
задачу определения заинтересованных лиц, их критериев качества и затем
нахождения оптимального решения,удовлетворяющего этим критериям.
Тестирование является одним из наиболее устоявшихся способов
обеспечения качества разработки программного обеспечения и входит в
набор эффективных средств современной системы обеспечения качества
программного продукта.
Правильное определение тестирования таково: Тестирование — процесс
выполнения программы с намерением найти ошибки.
Невозможно гарантировать отсутствие ошибок в нетривиальной программе;
в
лучшем случае можно попытаться показать наличие ошибок. Если программа
правильно ведет себя для солидного набора тестов, нет основании
утверждать,
что в ней нет ошибок; со всей определенностью можно лишь утверждать, что
не
известно, когда эта программа не работает. Конечно, если есть причины
считать
данный набор тестов способным с большой вероятностью обнаружить все
возможные
ошибки, то можно говорить о некотором уровне уверенности в правильности
программы, устанавливаемом этими тестами.
Психологические эксперименты показывают, что большинство людей,
поставив цель
(например, показать, что ошибок нет), ориентируется в своей деятельности
на
достижение этой цели. Тестовик подсознательно не позволит себе
действовать
против цели, т. е. подготовить тест, который выявил бы одну из оставшихся в
программе ошибок. Поскольку мы все признаем, что совершенство в
проектировании и кодировании любой программы недостижимо и поэтому
каждая
программа содержит некоторое количество ошибок, самым плодотворным
применением тестирования будет найти некоторые из них. Если мы хотим
добиться
этого и избежать психологического барьера, мешающего нам действовать
против
поставленной цели, наша цель должна состоять в том, чтобы найти как
можно