1. Что такое промышленный программный продукт. Дать определения пакета прикладных программ, программной системы.
Пакет прикладных программ (ППП) – называется множество или совокупность (организованная), программ и модулей, позволяющая решать целый класс задач. ППП с дружественным профессионально-ориентированным интерфейсом пользователя называется программной системой (ПС).
ПС, обладающая качествами промышленного изделия, называется ППИ (промышленное программное изделие).
ППИ применяются в различных отраслях деятельности, они управляют или сами управляются событиями физического мира. Системы подобного рода обычно имеют большое время жизни и большое количество пользователей. Пользователи таких систем оказываются в зависимости от их нормального функционирования.
2. Основные причины неудач программных проектов. Критичность и масштабность программных проектов.
Кризис в разработке ПО выражается в том, что большие проекты выполняются с отставанием от графика или превышают сметы расходов. Разработанный продукт не обладает требуемыми функциональными возможностями, производительность его низка, качество не устраивает потребителей.
Только 16,2% завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме; 31,1% проектов были аннулированы до завершения; для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%.
Основные причины кризиса:
1. Нечеткая и неполная формулировка требований к ПО
2. Недостаточное вовлечение пользователей в работу над проектом
3. Отсутствие необходимых ресурсов
4. Неудовлетворительное планирование и отсутствие грамотного управления проектом
5. Частое изменение требований и спецификаций
6. Новизна и несовершенство используемой технологии
7. Недостаточная поддержка со стороны высшего руководства
8. Недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта.
Критичность и масштабность проекта.
Существует 4 уровня критичности. C – самый низкий. Дефекты вызывают потерю удобства (word завис), d – дефекты вызывают потерю возместимых средств (хакер в банке), e – дефекты вызывают потерю невозместимых средств (станция отправлена на Марс, а она не вернулась), l – дефекты создают угрозу человеческой жизни.
Масштабность: 1-6 человек – малый масштаб, 6-20 человек – средний масштаб, свыше 20 – крупный масштаб.
3. Жизненный цикл программного обеспечения. Дать краткую характеристику каждого этапа.
· обследование системы – на этой стадии поверхностно изучается и описывается существующая задача, выявляются организационные проблемы и необходимость автоматизации, делается грубая оценка стоимости автоматизации
· планирование – на данном этапе разрабатывается техническое задание, техническое задание должно описывать требование к назначению и функции к новой системе, также специфицируется аппаратное и программное обеспечение необходимое для работы системы, рассчитывается стоимость разработки и составляется календарный план
Первые две стадии разработки не зависят от используемой методологии программирования.
· системный анализ – целью данного этапа является моделирование существующей системы, для понимания того, как она функционирует, результатом данного этапа является аналитическая модель программной системы. Данная модель должна быть составлена в терминах предметной области
На основе этой модели должно быть выработано понимание проблемы достаточное для проектирования системы.
· системное проектирование – на данном этапе определяется общая архитектура системы
· программное проектирование – на данном этапе строятся программные модули системы
· кодирование, тестирование, отладка – модели разработанные на этапе программного проектирования воплощаются в конкретный программный код, реализуются подсистемы, которые тестируются и отлаживаются
· системное документирование – на данном этапе окончательно оформляется проектно-техническая документация на систему
· внедрение – включает инсталляцию программной системы на аппаратную базу заказчика и обучение персонала
· использование и оценка – на данном этапе осуществляется эксплуатация системы, выявление ошибок в ее функционировании, оценка эффективности ее работы, принимаются решения о поддержке и сопровождении системы, а также принимается решение о ее развитии.
4. Каскадные модели разработки ПО.
Модель водопада (waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
В оригинальной модели водопада Ройса, следующие фазы шли в таком порядке:
1. Определение требований
2. Проектирование
3. Конструирование (также «реализация» либо «кодирование»)
4. Интеграция
5. Тестирование и отладка (также «верификация»)
6. Инсталляция
7. Поддержка
Следуя модели водопада, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка — внесение новой функциональности и устранение ошибок.
Тем самым, модель водопада подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не происходит.
V- образная модель является развитием каскадной (жизненный цикл) и используется тогда, когда требования к программной системе четко определены на начальных этапах.
Основным отличием данной модели является то, что для каждого этапа жизненного цикла имеется связанный этап, который позволяет проверить правильность принятых решений.
«+» данной модели является механизм контроля.
«-» : выполнять этот контроль затруднительно, поскольку документы, разработанные на начальных этапах, часто бывают неоднозначными.
5. Итеративные модели разработки ПО.
Разработка коммерческих продуктов – это серьезное предприятие, которое требует большого количества времени и ресурсов. Практично было бы разделить работу на небольшие куски или мини проекты. Каждый мини проект будет итерацией, а результат итерации – это приращение. Итерации относятся к шагам рабочих процессов, а приращение к выполнению проекта. Для максимальной эффективности, итерации должны быть управляемыми. На каждой итерации определяют и описывают уместные для этой итерации варианты использования. Создают проект, использующий выбранную архитектуру в качестве направляющей, а затем его реализуют. Если итерация достигает своей цели, процесс разработки переходит на следующую. Для получения максимальной экономии, команда разработчиков должна выбирать только те итерации, которые требуются для выполнения цели проекта.
Управляемый итеративный процесс имеет ряд преимуществ:
1. управляемая итерация ограничивает финансовые риски затратами на одно приращение
2. управляемая итерация снижает риск не поставки продукта в установленные договором сроки. При раннем обнаружении соответствующего риска времени можно внести этот риск в план на ранних этапах разработки
3. управляемая итерация ускоряет темпы процесса разработки в целом
4. управляемый итеративный процесс направлен на удовлетворение желаний пользователя
Спиральная модель разработки ПО
Риск: не уложиться во времени, в финансы.
Спиральная модель декомпозирует проект на риск ориентированные подпроекты. Под рисками понимаются факторы, в результате действия которых разработка ПО может закончиться неудачей. В начале каждого этапа (подпроекта) анализируются риски, затем они ранжируются (по уровню критичности) и начинается реализация того подпроекта, который имеет самый высокий уровень
«-» основная доработка на последнем этапе.
Эволюционная модель
Эволюционная модель используется для проектов малого и среднего масштаба с нечетко определенными требованиями. Само название говорит о том, что процесс создания программного продукта проходит через некоторую эволюцию, развитие за определенное количество итераций.
Преимущества данной модели:
· Предполагается нечеткая формулировка требований и реагирование на их изменение.
· Процесс разработки – в непрерывном общении с клиентом.
Недостатки:
· Невозможно четко определить количество итераций, а соответственно рассчитать сроки и стоимость выполнения проекта.
· Слабый анализ рисков.
Адаптивная модель
Адаптивная модель используется в тех случаях, когда требования к проекту полностью неизвестны и могут очень быстро меняться в процессе разработки
Это выражается в 3 компонентах данной модели
· Размышляйте (как бы деятельность планирования)
· Сотрудничайте (взаимодействие между всеми сторонами, вовлеченными в проект)
· Учитесь – предназначен для оценки эволюционного развития продукта
Преимущества адаптивной модели:
· Позволяет работать над проектами, требования для которых полностью неизвестны на начальном этапе.
Недостатки:
· Основной недостаток – невозможность полноценного управления проектом.
6. Почему программные системы сложны. Привести пять признаков сложной системы.
Сложность программных систем (ПС) обусловлена следующим:
· сложность реальной предметной области, из которой происходит заказ на разработку
· трудность управления процессом разработки
· необходимость обеспечить достаточную гибкость программы
· неудовлетворительные способы описания больших дискретных систем
Пять признаков сложной системы:
1. сложные системы часто являются иерархическими и состоят из взаимосвязанных подсистем, которые в свою очередь также могут быть разделены на подсистемы и т. д. в плоть до низкого уровня
2. выбор какие компоненты в данной системе считаются элементарными относительно произволен и в большей степени остаются на усмотрение разработчика
3. внутрикомпонентная связь обычно сильнее, чем связь между компонентами
4. иерархические системы обычно состоят из немногих типов подсистем по-разному скомбинированных и организованных
5. любая работающая сложная система является результатом развития работающей более простой системы, сложная система, спроектированная с нуля никогда не будет работать, следует начинать с работающей простой системы
7. Техническое задание. Перечислить и охарактеризовать разделы, входящие в техническое задание.
Составление технического задания состоит из следующих этапов:
1. введение
2. основание для разработки
3. назначение разработки
4. требования к программному продукту (основной раздел)
5. требования к программной документации
6. технико-экономические показатели
7. стадии и этапы разработки (составление календарного плана)
8. порядок контроля и приемки
9. приложения
Введение – в данном разделе указывают наименование, краткую характеристику области применения программного продукта и объекта в котором используют программный продукт.
Основание для разработки – в данном разделе указывают:
1. документ или документы, на основании которых ведется разработка
2. организация утвердившая этот документ и дата его утверждения
3. наименование и (или) условное обозначение темы разработки
Назначение разработки – в этом разделе указывается функциональное и эксплуатационное назначение продукта.
Требования к программному продукту – данный раздел содержит следующие подразделы:
1. требования к функциональным характеристикам – в подразделе должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. д.
2. требования к надежности – в подразделе должны быть указаны требования к обеспечению надежного функционирования (контроль входных и выходных данных, обработка ошибок вычисления, время восстановления системы после отказов и т. д.)
3. требования к условиям эксплуатации – в подразделе должны быть указаны условия эксплуатации (температура воздуха, влажность и т. д.) при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала
4. требования к составу и параметрам технических средств – в подразделе указывается необходимый состав технических средств с указанием их основных характеристик
5. требования к информационной и программной совместимости – в подразделе должны быть указаны требования к информационным структурам на входы и выходы методом решения исходным языкам, языком программирования и программным средствам используемым программой, при необходимости должна обеспечиваться защита информации и программы
6. требования к маркировке и упаковке – в подразделе, в общем случае, указываются требования к маркировке продукта, варианты и способы упаковки
7. требования к транспортировке и хранению – в подразделе для продукта должны быть указаны условия транспортировки, место хранения, сроки хранения в различных условиях
Требования к программной документации – в этом разделе должен быть указан предварительный состав программной документации и при необходимости специальные требования к ней.
Технико-экономический показатель – в данном разделе указываются:
1. ориентировочная экономическая эффективность
2. предполагаемая годовая потребность
3. экономические преимущества разработки по сравнению с существующими аналогами
Стадии и этапы разработки (календарный план) – в данном разделе устанавливаются необходимые стадии разработки, этапы и содержания работ, перечень программных документов, которые должны быть согласованы, разработаны и утверждены, а также сроки разработки и исполнители.
Порядок контроля и приемки – в этом разделе указываются виды испытаний и общие требования к приемке работы.
Приложения – приложения составляются по следующим документам:
1. в приложениях к техническому заданию приводят перечень научно-исследовательских работ, обосновывающих разработку
2. схемы, таблицы, описания, обоснования и документы, необходимые для разработки.
8. Технология экстремального программирования.
Принципы:
1. Игра-планирование. Быстрое определение области действия следующей реализации путем объединения деловых приоритетов и технических оценок
2. Частая смена версий. Быстрый запуск производства простой системы. Смена версии каждые 2 недели.
3. Метафора. Вся разработка ведется на основе простой общедоступной идеи.
4. Простое проектирование. Проектирование выполняется настолько просто, насколько возможно.
5. Тестирование. Непрерывное написание тестов для разработанных модулей. Тесты создаются заказчиками. Тесты выполняются безупречно.
6. Реорганизация. Система реконструируется, но ее поведение не изменяется.
7. Парное программирование. Код каждой подсистемы пишется 2 программистами, причем работают посменно.
8. Коллективное владение кодом. Каждый может вносить изменения в код в любое время.
9. Непрерывная интеграция. Система интегрируется и собирается по нескольку раз в день.
10. 40-часовая рабочая неделя.
11. Локальный заказчик. В группе разработчиков постоянно присутствует представитель заказчика.
12. Стандарты кодирования.
9. Унифицированный процесс разработки программного обеспечения. Жизненный цикл унифицированного процесса.
Результатом каждого цикла является новый выпуск системы, а каждый выпуск – это готовый к поставке продукт. Для того чтобы эффективно выполнить цикл разработчикам необходимо иметь представление о программном продукте. (см. рисунок ниже).
Описание:
1. Модель вариантов использования со всеми вариантами использования.
2. Модель анализа целью, которой является уточнение вариантов использования.
3. Модель проектирования, в которой реализуется модель вариантов использования.
4. Модель развертывания, в которой компоненты распределяются по узлам, а каждый узел – компьютер.
5. Модель реализации – это диаграмма компонентов.
6. Модель тестирования, которая предназначена для тестирования и отладки нашего программного продукта.
Разделение цикла разработки на фазы.
Каждый цикл осуществляется в течение некоторого времени. Это время делится на следующие фазы:
- анализ и планирование требований
- проектирование
- построение
- внедрение
 |
Каждая фаза заканчивается вехами.
Веха – это измеримый и определяемый результат.
Вехи служат многим целям, наиболее важная из них дать руководителям возможность принять некие критические решения перед переходом на следующую фазу разработки.
10. Унифицированный процесс разработки программного обеспечения. Первый этап.
Цели:
1) Понять что создавать
Для реализации данной цели необходимо определить концепцию, границы системы, уточнить кому система нужна и во сколько она обойдется.
2) Выяснить ключевые функции системы
Для реализации данной цели необходимо определить какой функционал является ключевым для приложения или использует ключевые интерфейсы системы, определить какие функции должны быть реализованы, определить какие функциональности охватывают облатсь архитектуры не охватывают никакие другие ключевые варианты использования.
3) Выявить хотя бы одно возможное решение
Необходимо построить хотя бы одну архитектуру
4) Оценить стоимость, сроки и риски
5) Решить какому процессу следовать и какие средства использовать
Выбор процесса означает: настройку унифицированной технологии программного обеспечения под конкретный проект т. е. определения масштаба проекта, степени его формализации, а также выбор утилит для поддержки процесса. Определяется набор технологий и программных средств, которые будут использоваться при решении проекта.
Начальная фаза как правило выполняется за 1 итерацию. Однако некоторые проекты могут потребовать несколько итераций.
Причины:
1) Проект вели и команде трудно понять его границы
2) Существуют большие технологические риски, которые необходимо уменьшить путем создания прототипа
3) Система не имеет аналогов и трудно понять, что она должна делать
4) Есть множество заинтересованных сторон и их взаимоотношения сложны
5) Трудно получить экономическое обоснование с первого раза
11. Унифицированный процесс разработки программного обеспечения. Этап проектирования.
Цели:
1) Более глубоко понять требования
Для реализации данной цели необходимо описать подавляющее количество требований необходимых для нормального функционирования системы и удовлетворения требований заказчика. Необходимо получить одобрение от заинтересованных лиц, чтобы убедиться в правильности данных требований. Реализация данной цели позволит построить подробный план проекта.
2) Спроектировать и реализовать базовую архитектуру
Необходимо спроектировать, реализовать и протестировать структурный каркас системы. Нет необходимости реализовывать полную функциональность данного каркаса. Однако он позволит принять ключевые решения и получить одобрение заказчика.
3) Снизить существенные риски и дать более четкую оценку сроков и стоимости
Производится анализ выполнения первых двух щелей и на основе этого строится оценка стоков и стоимости выполнения проекта.
4) Уточнить претендент разработки
Необходимо уточнить набор программных инструментов, которые будут использоваться в ходе реализации построения программной системы.
Количество итераций:
Если подобные проекты уже выполнялись, то фаза проектирования может быть выполнена за 1 итерацию, однако, если отсутствует опыт в разработке систем подобного рода для реализации данной фазы может потребоваться 2-3 итерации.
12. Унифицированный процесс разработки программного обеспечения. Этап внедрения.
Цели:
1) Провести бета-тестирование для проверки соответствия программы ожиданиям пользователя
Требуется выполнение задач по исправлению ошибок, внесение усовершенствований повышающих быстродействие системы и надежности ее функционирования.
2) Научить пользователя и обслуживающий персонал работать самостоятельно.
Необходимо организовать семинары, на которых пользователи и обслуживающий персонал получат необходимые знания о программном продукте. Выполнение данной задачи гарантирует, то что в организации будет достаточное количество квалифицированного персонала для эксплуатации системы.
3) Подготовить площадку для развертывания системы и конвертирования рабочих баз данных
Для запуска системы в эксплуатацию может потребоваться закупка нового ПО и оборудования, подготовка места для него и обеспечить перевод ранее накопленных данных в новую систему.
4) Подготовить упаковку, тиражирование, провести маркетинговое исследование, разработать рекламные материалы, выпуск дистрибутивов в продажу
5) Достичь соглашения между заинтересованными сторонами в том, что программный продукт для выпуска готов и соответствует критериям оценки определенным в техническом задании.
6) Повысить производительность при выполнении будущих проектов на основе приобретенного опыта.
Количество итераций фазы внедрения зависит от сложности проекта: 1-3
13. Принципы унифицированного процесса.
1. Начинайте наступление на главные риски с самого начала разработки и ведите их непрерывно иначе риски подойдут в наступление на вас.
Необходимо проанализировать основные риски проекта и попытаться их минимизировать, как можно раньше. Если главные риски не минимизированы, проект с большой вероятностью закончится неудачей
2. Обеспечьте выполнение требований заказчика
Документируйте требования таким образом, чтобы они были понятны заказчику и при этом в ходе выполнения проекта строго придерживайтесь данных требований, чтобы гарантированно их выполнение.
3. Сконцентрируйтесь на исполняемой программе
Документы являются слабым показателем действительного прогресса поскольку их оценка субъективна и их важность вторична по отношению к самой программе. Исполняемый код, который компилируется и успешно проходит тесты, лучший показатель прогресса.
4. Приспосабливайтесь к изменениям с самого начала проекта
Современные приложения слишком сложны, чтобы можно было получить все требования с самого начала. Это означает, что для того чтобы создать хорошую систему необходимо позволять изменения и с самого начала приспосабливаться к тому, что они будут.
5. С самого начала закладывайте исполняемую архитектуру
Многие риски в проекте можно свести к минимуму, если реализовать исполняемую архитектуру на основе ключевых вариантов использования на ранних стадиях разработки.
6. Стройте систему из компонентов
Приложения на основе компонентов более гибкие с точки зрения изменений. В них радикально снижены затраты по обслуживанию. Компоненты облегчают повторное использование и позволяют быстро создавать качественные приложения.
7. Сделайте качество образом жизни, а не запоздалой идеей.
Обеспечение высокого качества касается не только группы тестировщиков. Оно касается всех членов команды и требует от них проведения раннего тестирования до передачи системы команде тестеров.
14. Работа с кадрами. Перечислить роли разработчиков и дать характеристику каждой из них.
Персонал – это физические лица, которые являются движущей силой программного проекта.
Роли разработчиков являются важнейшими при создании программного продукта с использованием унифицированного процесса.
1. Архитектор проекта
2. Ответственные за подсистему
3. Прикладные программисты
1. Архитектор проекта – это его творец, который отвечает за эволюцию и сопровождение архитектуры системы. Для малых и средних проектов требуется участие одного или максимум двух архитекторов. Для крупных проектов количество архитекторов может измеряться десятками. Архитектор проекта не обязательно самый главный разработчик, но он должен иметь достаточно власти, для того чтобы принимать стратегические решения. Архитекторы необязательно самые лучшие программисты, хотя они должны владеть программой в определенной степени. Архитекторы должны хорошо владеть средствами моделирования программных систем. Очень плохая практика нанимать архитектора со стороны.
2. Ответственные за подсистему – это те люди, которые проектируют программные структуры (классы) для реализации тех или иных функциональных возможностей. Они отвечают за проектирование целого ряда подсистем. Каждый ответственный в сотрудничестве с архитектором разрабатывает, обосновывает и согласовывает с другими разработчиками интерфейсы своих подсистем. Ответственные за подсистемы возглавляют их реализацию, тестирование и выпуск версий в течение всей эволюции системы. Ответственные за подсистемы должны хорошо знать систему обозначений и организацию процесса объектно-ориентированной разработки.
3. На прикладных программистов возлагается выполнение двух обязанностей:
1. Некоторые из них отвечают за реализацию подсистемы под руководством ее ведущего. Эта деятельность может включать в себя проектирование некоторых классов, но в основном она связана с реализацией и последующим тестированием спроектированных классов.
2. Другие, отвечают за написание классов спроектированных архитектором, реализуя тем самым функциональные точки системы.
Прикладные программисты должны быть хорошими программистами, знающими достоинства и недостатки различных языков программирования. Кроме того, они должны разбираться в системе обозначений используемых при моделировании программных систем на том уровне, чтобы иметь возможность прочитать готовый проект.
Дополнительные роли разработчиков в крупных программных проектах.
1. Менеджер проекта отвечает за управление материалами проекта, заданиями, ресурсами и графиком работ.
2. Аналитик отвечает за развитие и интерпретацию требований конечных пользователей. Он должен быть экспертом проблемной области.
3. Инженер по повторному использованию управляет хранилищем материалов проекта. Активно ищет общее и добивается его использования. Находит, разрабатывает и приспосабливает компоненты для общего использования в рамках проекта.
4. Контролер качества (тестер) измеряет результаты процесса разработки, задает общее направление и участвует в тестировании всех версий программного продукта.
5. Менеджер интеграции отвечает за сборку совместимых друг с другом версий, категорий и подсистем в релизе программной системы.
6. Ответственный за документацию (технический писатель) готовит документацию по выпускаемому продукту для конечного пользователя.
7. Системный администратор управляет физическими компьютерными ресурсами в проекте.
8. Технический писатель составляет техническую документацию
15. Дать определения проекта, процесса, продукта с точки зрения унифицированного процесса разработки программного обеспечения.
Четыре «П» унифицированного процесса:
Персонал – реальные люди, которые участвуют в проекте. Под персоналом понимаются не только непосредственные разработчики, а все заинтересованные лица.
Проект – организационная сущность при помощи которой происходит управление разработкой ПО.
Продукт – артефакты, создаваемые в течении жизни проекта (модель, документ и т. д.)
Процесс – определение полного набора видов деятельности, необходимых для преобразования требования пользователя в готовый программный продукт.
Утилиты автоматизируют процесс.
16. Использование языка UML при проектировании сложных программных систем. Какие диаграммы используются в UML для создания моделей программной системы.
UML (Unified Modeling Language, предложенный James Rumbaugh, Grady Booch and Ivar Jacobson, Rational Software Corp)
Проблема разработки программного обеспечения сводится к затруднениям разработчиков, вынужденных преодолевать множество преград во время разработки программного продукта. Программисты нуждаются в управляемом методе работы.
Необходим процесс, который:
1. обеспечил бы руководство деятельностью команды
2. управлял бы задачами отдельного разработчика и команды в целом
3. указывал бы, какие артефакты следует разработать
4. представлял бы критерии для отслеживания и измерения продуктов и функционирования проекта
Наличие такого процесса, хорошо определенного и хорошо управляемого – основное отличие удачных проектов от неудачных. Прежде всего, унифицированный процесс – это сумма различных видов деятельности предназначенных для преобразования требований пользователя в программную систему.
Унифицированный процесс – это больше, чем единичный процесс, это обобщенный каркас процесса, который может быть специализирован для широкого круга программных систем. Унифицированный процесс – компонентно ориентирован, это означает, что программная система создается на основе компонентов связанных хорошо определенными интерфейсами. Для разработки модели программной системы унифицированного процесса, используют унифицированный язык моделирования (UML).
С точки зрения визуального моделирования, UML можно охарактеризовать следующим образом. UML предоставляет выразительные средства для создания визуальных моделей, которые:
o единообразно понимаются всеми разработчиками, вовлеченными в проект и
o являются средством коммуникации в рамках проекта.
Унифицированный Язык Моделирования (UML):
o не зависит от объектно-ориентированных (ОО) языков программирования,
o не зависит от используемой методологии разработки проекта,
o может поддерживать любой ОО язык программирования.
UML является открытым и обладает средствами расширения базового ядра. На UML можно содержательно описывать классы, объекты и компоненты в различных предметных областях, часто сильно отличающихся друг от друга.
При визуальном моделировании на UML используются различные виды диаграмм, каждая из которых может содержать элементы определенного типа. Типы допустимых элементов и отношений между ними зависят от вида диаграммы.
1. Use case diagram (диаграммы сценариев);
Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций.
2. Deployment diagram (диаграммы топологии);
Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ. При помощи данной диаграммы проектировщик может произвести анализ необходимой аппаратной конфигурации, на которой будут работать отдельные процессы системы, и описать их взаимодействие между собой и другими аппаратными устройствами. Этот тип диаграмм также позволяет анализировать взаимодействие процессов, работающих на разных компьютерах сети.
3. State diagram (диаграммы состояний);
Диаграммы состояний (State) предназначена для отображения состояний объектов системы, имеющих сложную модель поведения.
4. Activity diagram (диаграммы активности);
Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activity diagram не в том, чтобы отражать состояния, а в том, чтобы отражать бизнес-процессы объекта.
5. Interaction diagram (диаграммы взаимодействия);
Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.
6. Sequence diagram (диаграммы последовательностей действий);
Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений.
7. Collaboration diagram (диаграммы сотрудничества);
Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта, и типы этих сообщений.
8. Class diagram (диаграммы классов);
Этот тип диаграмм позволяет создавать логическое представление системы, на основе которого можно генерировать исходный код описанных классов.
Значки диаграммы позволяют отображать сложную структуру систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы
9. Component diagram (диаграммы компонент).
Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при проектировании физической структуры системы.
Диаграмма компонентов показывает организацию и взаимосвязи программных компонентов, представленных в исходном коде, двоичных или выполняемых файлах. Связи в данном типе диаграммы представляют зависимости одного компонента от другого.
17. Основные элементы диаграммы классов. Охарактеризовать каждый из них.
Class diagram (диаграмма классов) является основной диаграммой проекта, отражающей логическую структуру проектируемой системы. При помощи диаграммы классов создается описание внутренней структуры системы, отражающей отдельные составляющие блоки системы (классы), функциональное наполнение этих блоков (атрибуты и операции классов) и взаимодействие между ними (связи между классами).
Class (класс)
Класс — это установки структуры и шаблона поведения для некоторого множества реальных объектов, которые в дальнейшем будут определены в программе на основе данного шаблона. Класс — это некоторая абстракция реального мира. Когда эта абстракция принимает конкретное воплощение, она называется объектом.
Несмотря на то, что создание диаграмм классов является во многом не формализуемым процессом, можно выделить несколько основных этапов.
1 этап: Определение классов.
При идентификации классов нашей системы воспользоваться следующей методологией, которая состоит из двух шагов:
- Перечисление кандидатов в классы, найденных в постановке проблемы.
- Исключение ненужных и некорректных классов.
При выявлении кандидатов в классы выделяются все понятия (прежде всего, существительные), имеющие отношение к нашей системе.
Из списка кандидатов в классы исключаются «плохие классы» согласно следующим критериям:
а) Избыточные классы. Если два класса отражают одну и ту же информацию, то сохраняется наиболее информативное имя.
Совет:
При исключении избыточного класса обратите внимание, не является ли он частным случаем своего синонима. Возможно, в этом случае будет присутствовать связь наследования, и исключаемый класс будет присутствовать на схеме.
б) Нерелевантные классы. Если класс не используется в решении проблемы, он должен быть исключен. Это определяется здравым смыслом, поскольку в другом контексте класс может быть важен.
в) Неясные классы. Класс должен быть характерным, специальным. Некоторые пробные классы могут иметь плохо определенные границы или быть слишком широкими.
г) Атрибуты. Имена, которые изначально описывают другие объекты, должны быть утверждены как атрибуты
Совет:
Если независимое существование свойства является важным, или свойство является сложным объектом, то делайте его классом, а не атрибутом.
д) Операции. Если имя описывает операцию, которая применяется к объектам, а не манипулирует ими с собственными правами, то это не класс.
е) Конструкции реализации. Конструкции, являющиеся подсистемами, функциональными блоками или устройствами, используемыми в системе, должны быть исключены из модели. Они могут быть нужны позднее, на последующих стадиях проектирования, но не сейчас.
2 этап: Определение связей между классами.
Классы редко бывают изолированы, чаще всего они вступают в отношения друг с другом. Эти отношения показываются при помощи различного вида связей. Типы связей влияют на получаемый при генерации на основе диаграмм исходный код.
В диаграмме классов используются следующие виды связей:
• Unidirectional association (однонаправленная ассоциация);
• Dependency (зависимость);
• Association class (ассоциированный класс);
• Generalization (наследование);
• Realization (реализация).
Unidirectional Association
Одна из важных и сложных типов связи, которая используется в диаграмме классов. Данная связь показывает, что объекты одного класса взаимодействуют с объектами другого класса.
Пример ненаправленной связи
Рис. 3.7
Пример связи
Aggregate показывает, что один класс не просто использует, а содержит другой.
Рис. 3.8
Пример агрегирования класса
Агрегирование означает физическое включение объектов одного класса в объекты другого класса.
Association Class (ассоциированный класс)
Используйте данный тип связи для отображения свойства ассоциации.
Рис. 3.9
Пример использования Association Class
Dependency or instantiates (зависимость или реализация)
Этот тип связи позволяет показать, что один класс использует объекты другого. Использование может осуществляться при передаче параметров или вызове операций класса. Графически этот вид связи отражается пунктирной стрелкой (рис. 3.10).
Рис. 3.10
Пример связи Dependency or instantiates
Generalization
Данный тип связи позволяет указать, что один класс является родительским по отношению к другому, при этом будет создана связь наследования класса. Пример такой связи показан на рис. 3.11.
Рис. 3.11
Пример связи Generalization
Выделение связей (ассоциаций)
Любая зависимость между классами или ссылка одного класса к другому является ассоциацией. Атрибуты не должны быть ссылками на класс при моделировании, вместо них используются ассоциации.
Ассоциации часто соответствуют глаголам и глагольным фразам. Они включают физическое размещение (следующий, часть чего-либо, содержит), прямые действия (едет), коммуникацию (говорит кому-то), обладание (имеет) или удовлетворение некоторых условий (работает на, управляет).
Этап 3: Определение атрибутов классов
Атрибуты являются свойствами объектов, таких, как имя, вес, скорость или цвет. При выделении атрибутов, следует учитывать следующие определения:
1. Атрибут должен быть характерен непосредственно для данного класса.
2. Атрибут должен отображать, одну и только одну характеристику класса. Если выделенный атрибут являлся сложным объектом либо содержит некоторую совокупность характеристик, выделите атрибут в отдельный класс, либо разбейте его на несколько простых атрибутов.
3. При описании классов, входящих в состав схемы наследования, для каждого атрибута необходимо определить будет ли он общим для классов-наследников или специфичным для определенного класса. В первом случае атрибут включается в базовый класс, во втором – в соответствующий класс-наследник.
Этап 4:
Выделение операторов (методов) классов.
Операторы класса представляют собой действия, функции которые может совершать тот или иной класс.
При выделении операторов, следует учитывать следующие определения:
1. Метод класса должен быть свойственным тому классу, где он определен.
2. Отметим, что для обеспечения доступа к методу извне содержащего его класса может быть осуществлен только в том случае, если метод описан с открытыми (Public) правами доступа. Закрытые (Private) методы также обычно инициируются открытыми методами.
3. Операторы не должны быть слишком сложными, состоящими из множества различных функций. В этом случае необходимо разбить оператор на более простые составляющие.
4. Исключение из правила принадлежности метода классу составляют методы по созданию и удалению объектов класса. Подобные методы не могут быть включены в класс, так как класс не может вызвать метод создания собственного объекта. Создание объекта класса может произойти лишь извне, то есть из другого класса.
5. Соблюдайте принцип полноты методов класса. Если, например в классе присутствует метод Добавить запись, то должен быть определен метод Удалить запись. Должна присутствовать возможность сохранения и чтения добавленной записи, следовательно должны присутствовать методы Считать запись и Сохранить запись.
18. Диаграмма вариантов использования, ее назначение. Рассказать о варианте использования и действующем лице. Правила построения диаграммы вариантов использования.
Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций.
Диаграмма вариантов использования одна из наиболее важных моделей проектирования систем по той причине, что если функционал не вошел в диаграмму, он не будет реализован в системе.
Включает следующие элементы:
· Actor (актер)
Данный инструмент используется для создания действующих лиц в системе. На диаграмме Use Case значком actor обозначают пользователей системы, для того чтобы определить задачи, выполняемые пользователями и их взаимодействие.
Обычно значком Actor обозначают объект, который:
• взаимодействует с системой или использует систему;
• передает или принимает информацию в систему;
• является внешним по отношению к системе.
· варианты (прецеденты)
· Связи
Unidirectional Association (однонаправленная связь)
Данный инструмент позволяет обозначать связи между элементами. На диаграмме Use Case эти связи могут быть определены между use case и actor.
Значок Unidirectional Association позволяет создать однонаправленную связь класса с классом или класса с интерфейсом.
Dependency or instantiates (зависимость или реализация)
Значок Dependency or instantiates позволяет создать связь зависимости. Установка этого типа связей показывает, что класс использует другой класс как параметр в одном из методов.
Generalization (наследование)
Значок Generalization позволяет создать связь наследования, то есть создается подкласс для соединенного этой связью класса, наследуемого из родительского класса.
Типы вариантов использования:
1. критичные (выбираются из ключевых, ложатся в основу архитектуры)
2. ключевые (без которых система не имеет смысла)
3. обычные
Создание диаграммы вариантов использования
Этап 1:
При создании диаграммы вариантов использования начинаем с выделения действующих лиц (или, актеров) участвующих во взаимодействии с системой
Этап 2:
Следующим шагом является выделение возможностей (функций, вариантов использования), которые программа должна предоставлять данным пользователям.
Совет:
- Вариантами использования могут быть только те возможности, которые будут реализованы в системе.
- Старайтесь не вдаваться в детали методов реализации, которые будут использоваться при реализации данного программного продукта. Старайтесь опираться, прежде всего, на внешнее представление программы, поставьте себя на место конечных пользователей программы, которые «не знают», каким образом работает та или иная функция программы, однако вполне могут пользоваться всеми ее возможностями.
- Вариант использования это всегда какое-то действие. Не допускайте имен, обозначающих некие объекты. Вместо этого используйте действия над этими объектами.
- При определении количества вариантов использования, размещаемых на диаграмме, придерживайтесь правила «золотой середины». Каждый вариант использования должен быть не слишком обобщенной, а вполне конкретной функцией. Однако большого количества функций также следует избегать, так как схема может потерять свою наглядность. В этом случае, некоторые варианты использования можно объединить.
Этап 3:
Следующим важным шагом является создание связей между Актерами и вариантами использования.
Совет:
- Ассоциацию “Пользователь - Вариант использования” отображает связь использования. Обратная ассоциация «Вариант использования – пользователь” показывает, что “Вариант использования” при инициализации передает некоторую информацию пользователю.
- Не забывайте о том, что каждый пользователь на диаграмме представляет собой «Роль», которую играет тот или иной внешний объект. Причем один и тот же человек может играть несколько ролей в системе.
Правила построения вариантов использования:
1. диаграмма вариантов использования не учитывает временную последовательность.
2. Каждый вариант использования должен быть инициирован действующим лицом за некоторыми исключениями: включения и расширения.
3. нельзя моделировать связь между действующими лицами
Правила выявления вариантов использования:
· что пользователь хочет делать с системой?
· будет ли пользователь работать с информацией с помощью системы?
· нужно ли информировать о внешних событиях?
· должна ли система информировать пользователя о внешних событиях?
Как убедиться в том, что выявлены все варианты использования?
1. присутствует ли каждое функциональное требование хотя бы в одном варианте использования
2. учтено ли, как будет работать с системой каждое заинтересованное лицо
3. какую информацию будет передавать системе каждое заинтересованное лицо
4. какую информацию будет получать от системы каждое заинтересованное лицо
5. учтены ли вопросы, связанные с эксплуатацией
6. учтены ли все внешние системы, которые будут взаимодействовать нашей
7. какой информацией будет обмениваться каждая внешняя система с нашей
23. Диаграмма классов. Ее назначение. Что она включает. Рассказать об основных видах связей между классами.
Диаграмма классов - статическая структурная диаграмма, описывающая структуру системы; она демонстрирует классы системы, их атрибуты, операторы и связи между классами. ДК присущи общие для всех диаграмм свойства: имя и графическое содержание, являющееся одной из проекций модели. Но отличается от остальных специфичным содержанием.
ДК обычно содержит следующие сущности:
- классы;
- интерфейсы;
- кооперации;
- отношения зависимости, обобщения и ассоциации.
Для ДК используются следующие типы связей:
- Наследование (генерализация)
это связь между общей сущностью – суперклассом, или родителем, и более специализированной разновидностью этой сущности – подклассом, или потомком. Связь иногда называют связью "is a", имея в виду, что класс-потомок является частным случаем класса-предка. Класс-потомок наследует все атрибуты и операции класса-предка, но в нём могут быть определены дополнительные атрибуты и операции.
- Зависимость
это связь по применению, когда изменение в спецификации одного класса может повлиять на поведение другого класса, использующего первый класс. Если интерфейс 2го класса изменяется, это влияет на поведение объектов 1го класса. Показывается прерывистой линией со стрелкой, направленной к классу, от которого имеется зависимость.
- Ассоциация
это структурная связь, показывающая, что объекты одного класса некоторым образом связаны с объектами другого или того же самого класса. Допускается, чтобы оба конца ассоциации относились к одному классу. В ассоциации могут связываться два класса, и тогда она называется бинарной. Допускается создание ассоциаций, связывающих сразу n классов (они называются n-арными ассоциациями). Графически изображается в виде линии, соединяющей класс сам с собой или с другими классами.
С понятием ассоциации связаны 4 важных дополнительных понятия: имя, роль, кратность и агрегация. Ассоциации может быть присвоено имя, характеризующее природу связи. Другим способом именования ассоциации является указание роли каждого класса, участвующего в этой ассоциации. Роль класса задаётся именем, помещаемым под линией ассоциации ближе к данному классу. Кратность (multiplicity) (мощность) роли ассоциации - характеристика, указывающая, сколько объектов класса с данной ролью может или должно участвовать в каждом экземпляре ассоциации. Наиболее распространённым способом задания кратности роли ассоциации является указание конкретного числа или диапазона:
Иногда в требуется отразить то, что ассоциация между двумя классами имеет специальный вид "часть-целое". Тогда класс "целое" имеет более высокий концептуальный уровень, чем класс "часть". Ассоциация такого рода называется агрегатной (агрегацией):
Бывают случаи, когда связь "части" и "целого" настолько сильна, что уничтожение "целого" приводит к уничтожению всех его "частей". Агрегатные ассоциации, обладающие таким свойством, называются композитными (композициями):
24. Дать определение тестированию и отладке. Особенности и объекты тестирования. Автономное и комплексное тестирование.
Тестирование - процесс поиска, обнаружения ошибок.
Отладка – процесс устранения ошибок, выявленных на стадии тестирования.
Особенности тестирования:
- отсутствует программа-эталон, которой должны соответствовать все результаты тестирования проверяемой программы;
- невозможно создать тестовый набор для исчерпывающей проверки программы;
- следует избегать трудно или невоспроизводимых тестов;
- нужно создавать тесты, которые действительно находили бы ошибки, а не демонстрировали правильность выполнения программы;
- нет формализованных критериев качества программ и процесса их испытания;
- для тестирования нужно привлекать сторонних специалистов.
Наиболее характерными объектами тестирования являются:
1. требования и спецификация;
2. программные модули;
3. группы программ, решающие законченные функциональные возможности.
Автономное тестирование
Это метод, который включает автономную проверку отдельного модуля или подсистемы. Весь программный комплекс не тестируется, проверяется лишь структура компонента и вычисления и преобразования данных внутри него.
Разделяют восходящее и нисходящее направления автономного тестирования.
При восходящем тестируются физические модули самого нижнего уровня, затем – вызывающие их модули, и т. д. до самого высшего.
Плюсы: модули тестируются детально, это позволяет устранить большое количество ошибок; относительная простота подготовки тестов.
Минусы: нужно постоянно обновлять набор тестовых данных при подключении нового модуля; большая вероятность появления новых ошибок при подключении модулей; необходимо имитировать работу вышестоящих модулей.
При нисходящем в первую очередь проверяется главный модуль, затем – модули более низких уровней и т. д.
Плюсы: накапливаются тестовые данные, которые можно не менять при подключении модулей.
Минусы: более трудный поиск ошибок; необходимо имитировать работу нижестоящих модулей.
Существует также раздельное тестирование, являющееся разновидностью восходящего. Оно используется для раздельно компилируемых физических модулей.
Комплексное тестирование
Это метод, который включает исследование структуры всего комплекса, связи между модулями, внешние связи, возможности эксплуатации и т. д. Здесь проверяется решение задач с типовыми исходными данными, исследуется поведение комплекса в критических ситуациях и правильность использования ресурсов памяти и процессора.
Для упрощения процедуры тестирования рекомендуется сначала проводить тестирование по отдельным функциональным группам.
Дополнительный метод тестирования – инспекция кода, когда разработчиком проводится «ручное» тестирование, группа специалистов просматривает код, чтобы устранить типичные ошибки. Метод довольно действенный – позволяет устранить до 70% ошибок.
25. Дать определение тестированию и отладке. Локализация ошибок. Классификация ошибок.
Тестирование - процесс поиска, обнаружения ошибок.
Отладка – процесс устранения ошибок, выявленных на стадии тестирования.
Отладка включает в себя локализацию ошибки – выяснение её местоположения в программе. Программа что-то принимает на вход и выдаёт что-то на выходе. Первое при локализации ошибки – это понять, где происходит сбой. Для этого можно уменьшать кол-во параметров, подаваемых на вход программы и добиться двух малоразличимых наборов входных параметров, чтобы при одном из них программа работала, а при другом нет.
Классификация ошибок:
Это неточность написания кода, несоблюдение синтаксиса языка; простейшие ошибки, выявляются компилятором.
- опечатки
Это ошибки программиста при синтаксически верном коде; компилятором пропускаются; обнаружить довольно сложно, для этого используют метод инспекции кода.
- ошибки реализации алгоритма
Это все ошибки, вызванные неверным программированием при верном алгоритме:
1) ошибки распределения свободной памяти;
2) ошибки доступа к памяти, доступ по неинициализированному указателю;
3) использование неинициализированных переменных.
- ошибки алгоритма
Логические ошибки, которые приводят к неверному результату даже при совершенной реализации; трудно обнаружимы, т. к. работают с другими типами ошибок.
- ошибки метода
Неверное описание метода вычисления; тяжело обнаружимы, т. к. нужна высокая квалификация по предметной области; только при полной уверенности в том, что все ошибки реализации устранены и алгоритм правилен, можно предположить, что ошибка заключается в методе.
Для облегчения отладки существует способ, который заключается в том, чтобы в программу при написании встраивать средства обнаружения ошибок и реакции на них. Это называется безопасным программированием.
26. Оценки ошибок.
Обычно если в программе найдено большое кол-во ошибок, то, скорее всего, их там ещё больше. Поэтому используются методы оценки количества ошибок в программе:
- намеренное внесение ошибок
(N-n) – количество оставшихся ошибок; N – неизвестное кол-во ошибок.
Метод основам на том, что в код программы вносится опред-е кол-во ошибок (S); при этом считается, что % намеренно внесённых и реальных ошибок при тестировании будет одинаков. При тестировании обнаруживается n реальных ошибок и s внесённых. Вычисление строится на основе пропорции.
- объединение модулей
Большинство ошибок содержится в сопряжении модулей и операторах ввода-вывода. Обычно они затрагивают несколько модулей. После того, как проведено тестирование каждого отдельного модуля, они объединяются в систему. В ходе экспериментов выяснено, что в 90% новых модулей и в 15% старых нужно вносить изменения. Причём в ≈15% новых модулей и 6% старых нужно внести более 10ти изменений.
27. Правила и принципы построения интерфейса пользователя.
Правила:
«Эффективность»
Система не должна мешать эффективной работе пользователей, которые имеют большой опыт работы с ней. (Нарушением правила является ориентирование системы только на новичков или на профессионалов).
«Доступность» (указание)
Система должна быть достаточно понятной, чтобы юзер, никогда раньше ею не пользовавшийся, но хорошо знающий предметную область, мог без помощи начать её использовать.
«Непрерывное движение вперёд»
Система должна способствовать непрерывному росту знаний, умений, навыков юзера и приспосабливаться к его меняющемуся опыту.
«Соблюдение контекста»
Система должна быть согласована со средой, в которой ей предстоит работать.
«Поддержка»
Система должна способствовать более простому и лёгкому решению задач.
Принципы разработки юзерского интерфейса:
1) Человеку свойственно ошибаться
Система должна быть терпима к ошибкам юзера и не падать из-за ошибок входных данных.
2) Чел по меркам компа осознаёт информацию и действует медленнее.
3) «Глаз быстрее руки»
На нажатие клавиши требуется меньше времени, чем на перемещение курсора с одного объекта на другой.
4) Правило «7±2»
В кратковременной памяти заурядный чел держит 5-9 объектов. Если кол-во объектов интерфейса больше, то его труднее воспринимать.
5) Чел быстрее узнаёт что-либо, чем вспоминает, как оно называется.
Проще выбрать из списка.
6) На изучение нового требуется время.
Принципы построения интерфейса:
Принцип простоты
Самые распространённые операции должны выполнятся максимально просто, причём должны быть ссылки на более сложные операции.
Принцип видимости
Все функции и данные, нужные для использования в задаче, должны быть видны, когда юзер выполняет эту задачу.
Принцип толерантности
Система должна быть терпима к ошибкам юзера: минимальный ущерб системе (засчёт отмены и повтора действий), гибкий интерфейс.
Принцип структуризации
Интерфейс дб целесообразно структурирован: родственные части дб связанны, а независимые разделены; похожие элементы должны выглядеть похоже, а непохожие различаться.
Принцип обратной связи
Юзер должен получать сообщение от системы о выполнении её действий. Сообщения дб краткими и понятными.
Принцип повторного использования
Следует многократно использовать внутр. и внеш. компоненты, чтобы способствовать единообразию интерфейса.
28. Документирование. Состав и содержание документов прилагаемых к программной системе.
Документирование должно начинаться одновременно с началом разработки продукта и в процессе разработки должны быть сформированы следующие документы: текст программ с необходимыми комментариями, описание программы – сведения о конечном продукте, программа и методика испытаний, техническое задание (см №7), пояснительная записка (схема алгоритма, общее описание алгоритма и/или функционирования программы, обоснование принятых решений), руководство пользователя, руководство администратора.
Руководство администратора (системного программиста).
Руководство системного программиста должно содержать следующие разделы: общие сведения о программе (назначение функций программ, сведения о технических и программных средствах обеспечивающих выполнение данной программы), структура программы (сведения о структуре программы и ее составных частях, сведения о связях между составными частями, сведения о связях с другими программами), настройка программы(должно быть приведено описание действий по настройке программы, на условие конкретного применения (описание настройки на конкретное оборудование). При необходимости приводят поясняющий пример), проверка программы(должно быть приведено описание способов проверки, позволяющих дать общее заключение о работоспособности программы), дополнительные возможности(должно быть приведено описание дополнительных разделов функциональных возможностей), сообщения системному программисту(тесты сообщений выдаваемых в ходе выполнения настройки, проверки программы, а также в ходе выполнения программы описание содержания данных сообщений, а также действий, которые необходимо по ним предпринять)
В зависимости от особенностей, отдельные разделы допускается объединять, а также вводить новые разделы.
Руководство пользователя (оператора).
Руководство оператора должно содержать следующие разделы: назначение программы, условия выполнения программы, выполнение программы(должна быть указана последовательность действий пользователя, обеспечивающих загрузку, выполнение и завершение программы, последовательности действий, с помощью которых пользователь может управлять выполнением программы, а также реакция программы на эти действия), сообщение оператору (пользователю)( тесты сообщений выдаваемых в ходе выполнения настройки, проверки программы, а также в ходе выполнения программы, описание содержания данных сообщений, а также действий, которые необходимо по ним предпринять).
29. Что такое качество с точки зрения квалиметрии. Дать определение свойству и показателю качества ПО. Основные задачи решаемые при оценке качества.
Квалиметрия- наука, определяющая основные термины в области качества продукции, устанавливаемая группой показателей качества, определяющая методы получения количественных значений показателей качества и методы определения уровня качества различных образцов промышленной продукции.
Качество программного обеспечения – совокупность свойств программного обеспечения, обуславливающих его пригодность удовлетворять определенные потребности потребителя и специалистов, участвующих в создании сопровождения программного обеспечения, т. е. не все свойства входят в качество программного обеспечения, а только та их совокупность, которую определяет потребность в нем. Если по каким-то причинам исчезает потребность в программном обеспечении, его качество считается нулевым.
Свойство программного обеспечения – объективная особенность программного обеспечения, проявляющаяся при его разработке, эксплуатации и сопровождении. Свойство программного обеспечения можно разделить на 2 группы: функциональные и конструктивные.
Функциональные свойства отражают возможности и специфику применения программы и определяют степень её соответствия своему назначению
Конструктивные свойства слабо зависят от функциональных и оценивают программу с точки зрения того, как она сконструирована.
Свойства могут быть простыми и сложными. Для объективной оценки качества программного обеспечения, его свойство необходимо охарактеризовать количественно.
Показатель качества – количественная оценка свойства входящего в состав качества программного обеспечения наряду с показателями качества могут присутствовать словесные оценки называемые признаком
Основные задачи, решаемые при оценке качества программного обеспечения: планирование уровня качества (предусматривает создание нормативных документов по оценке качества, создание специализированных групп, которые контролируют качество выпускаемого программного обеспечения); контроль значений и показателей качества в ходе разработки; эксплуатационный контроль заданного уровня качества; методическое руководство разработкой нормативных документов в области качества.
30. Оценка качества программного обеспечения. Методы оценки свойств программного обеспечения.
Качество программного обеспечения – совокупность свойств программного обеспечения, обуславливающих его пригодность удовлетворять определенные потребности потребителя и специалистов, участвующих в создании сопровождения программного обеспечения, т. е. не все свойства входят в качество программного обеспечения, а только та их совокупность, которую определяет потребность в нем. Если по каким-то причинам исчезает потребность в программном обеспечении, его качество считается нулевым.
Свойство программного обеспечения – объективная особенность программного обеспечения, проявляющаяся при его разработке, эксплуатации и сопровождении. Свойство программного обеспечения можно разделить на 2 группы: функциональные и конструктивные.
Функциональные свойства отражают возможности и специфику применения программы и определяют степень её соответствия своему назначению
Конструктивные свойства слабо зависят от функциональных и оценивают программу с точки зрения того, как она сконструирована.
Свойства могут быть простыми и сложными. Для объективной оценки качества программного обеспечения, его свойство необходимо охарактеризовать количественно. Показатель качества – количественная оценка свойства входящего в состав качества программного обеспечения наряду с показателями качества могут присутствовать словесные оценки называемые признаком.
Методы оценки свойств программного обеспечения: по способам получения информации и по источникам получения информации.
По способам получения информации:
Измерительный метод- основан на получении информации о свойствах программного обеспечения с использованием инструментальных средств: определение числа строк исходного каскада, число комментариев, число операторов, число ветвлений.
Регистрационный метод – основан на получении информации во время испытания программного обеспечения(регистрация ошибок, скорость выполнения тех или иных операций), фиксируются ошибки, скорость выполнения операций.
Органолептический метод – основан на использовании информации, получаемой в результате анализа восприятия органов чувств. Применяется для определения показателей качества таких, как удобство применения и эффективность.
Расчетный метод – основан на использовании теоретических и эмпирических зависимостей, статистических данных, накапливающих при испытании, эксплуатации и сопровождении программного обеспечения.
По источникам получения информации:
Традиционный метод
Экспертный метод – применяется в тех случаях, когда задача не может быть решена никакими др. методами. Определение значений показателя качества в этом методе дело группы экспертов. Социологический метод – основан на обработке специальных анкет в опроснике.
31. Система обеспечения качества по серии стандартов ISO.
ISO – 9000 – описывает систему управления качествами – “основы и словарь”
Сертификат ISO 9001 — это официальный документ, подтверждающий качество работ и услуг организации за счет гарантии соответствия всех процессов на предприятии стандарту по качеству ISO 9001, именно поэтому сертификат качества ISO 9001 может гарантировать потребителю высокое качество товаров, работ и услуг
Получение сертификата в соответствии со стандартом ISO 9000
Для того, чтобы организация получила сертификат необходимо создать в организации всеобъемлющую систему качества – TQM(Total Quality Management). В базовые элементы всеобщей системы качества входят.
1. Вовлеченность высшего руководства. Смысл заключается в том, что весь руководящий состав компании должен быть вовлечен и участвовать в процессе повышения качества, начиная от начальных этапов создания бизнеса и формирования стратегических целей, до конкретных тактических решений, способствующих повышению качества продукции.
2. Вовлеченность покупателей. Необходимо, для получения своевременной информации о нарушении качества, а также для получения информации о потребностях в том или ином товаре.
3. Разработка продуктов для качества. Для разработки продуктов для качества должны задаваться высшие параметры производительности, удовлетворения потребностей покупателя в удобном внешнем виде, сервисе и других параметрах.
4. Разработка производственных процессов в соответствии с требованиями качества. Производственные процесс должен быть построен в соответствии с определенными факторами, которые должны исключать неправильное функционирование оборудования, некачественные материалы, неправильное выполнение рабочими своих обязанностей. Стандарты ISO 9000 позволяют исключить данные факторы из производственного процесса.
5. Контроль производственного процесса. Все этапы производства должны проходить жесткий контроль. Чтобы достичь высшего качества продукции необходимо осуществлять постоянный контроль продукции. А так же следить, чтобы процесс производства шел в соответствии с нормативными документами.
6. Развитие партнерских взаимоотношений с поставщиками. Развитие партнерских отношений необходимо для получения качественных материалов, деталей и компонентов для производства продукции.
Для получения сертификата организация проводит внутренний аудит системы качества. При проведении внутреннего аудита анализируется система качества организации для выявления недостатков. В соответствии с результатами анализа создается план корректирующих мероприятий, в котором указываются недостатки, срок их устранения, лица ответственные за их устранение. Для проведения аккредитации проводится внешний аудит. Внешний аудит проводится сотрудниками сертифицирующих органов. По результатам внешнего аудита производятся те же действия, что и по результатам внутреннего. Если недочеты в системе качества отсутствуют или незначительны предприятие получает сертификат. Систему качества необходимо поддерживать и подтверждать работоспособность. Подтверждение происходит путем повторной сертификации., которая в первое время проводится раз в год, а затем раз в 3 года.
Схемы сертификации.
1. Выборка образца из партии.
2. Выборка у производителя
3. Выборка у продавца.
4. Оценка производства(процесса).
Для того, чтобы обеспечить заданное качество программного продукта необходимо, чтобы он удовлетворял характеристикам, приведенным в стандарте ISO 9126:
6 факторов качества, каждый из которых описывается с помощью атрибутов.
1) функциональность – пригодность к исполнению
1.1. пригодность к определенной работе
1.2. точность, правильность
1.3. способность к взаимодействию
1.4. соответствие стандартам и правилам
1.5. защищенность
2) надежность
2.1. зрелость и законченность
2.2. устойчивость к отказам
2.3. способность к восстановлению работоспособности после сбоев
3) практичность, удобство использования
3.1. понятность
3.2. удобство обучения
3.3 работоспособность
4) эффективность
4.1 временные характеристики
4.2. использование ресурсов
5) сопровождаемость
5.1. анализируемость
5.2. изменяемость, удобство внесения изменений
5.3. риск возникновения неожиданно эффектов при внесении изменений
5.4. контролируемость, удобность, правильность
6) переносимость, мобильность
6.1. адаптируемость
6.2. устанавливаемость, удобство установки
6.3. способность к сосуществованию с др. ПО
6.4. удобство замены другого ПО данным.
