МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ
РЕСПУБЛИКИ КАЗАХСТАН
АТЫРАУСКИЙ ИНСТИТУТ НЕФТИ И ГАЗА
«ТЕХНОЛОГИЧЕСКИЙ» ФАКУЛЬТЕТ
Кафедра
«МАТЕРИАЛОВЕДЕНИЕ И ТЕХНОЛОГИЯ НОВЫХ МАТЕРИАЛОВ»
Дисциплина: «Концепция современного естествознания
»
Р Е Ф Е Р А Т
На тему: «ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ
»
Выполнил студент: Дюсенов М.
С.
Группы: АиУ - 08 к/о
Проверила: Дюсекенова Сауле Рафаиловна
Оценка:
__________________________
Подпись:
__________________________
«
___
»
_______________20
10г.
Атырау, 2010
ПЛАН
1.1.
Специфика разработки программных средств.
1.2.
Специфика разработки программных средств.
1.3.
Жизненный цикл программного средства.
1.4.
Понятие качества программного средства.
1.5.
Обеспечение надежности - основной мотив разработки программных средств.
1.6.
Методы борьбы со сложностью.
1.7.
Обеспечение точности перевода.
1.8.
Преодоление барьера между пользователем и разработчиком.
1.9.
Контроль принимаемых решений.
1.10.
Курс "Принципы разработки программного обеспечения с использованием RUP, эффективных юзкейсов и программного обеспечения IBM Rational Suite"
ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ
Специфика разработки программных средств. Жизненный цикл программного средства. Понятие качества программного средства. Обеспечение надежности - основной мотив разработки программного средства. Методы борьбы со сложностью. Обеспечение точности перевода. Преодоление барьера между пользователем и разработчиком. Обеспечение контроля правильности принимаемых решений.
1.1.
Специфика разработки программных средств.
Разработке программных средств присущ ряд специфических особенностей [3.1].
Прежде всего следует отметить некоторое противостояние: неформальный
характер требований к ПС (постановки задачи) и понятия ошибки в нем, но формализованный
основной объект разработки - программы ПС. Тем самым разработка ПС содержит определенные этапы формализации, а переход от неформального к формальному существенно неформален.
Разработка ПС носит существенно творческий характер
(на каждом шаге приходится делать какой-либо выбор, принимать какое-либо решение), а не сводится к выполнению какой-либо последовательности регламентированных действий. Тем самым эта разработка ближе к процессу проектирования каких-либо сложных устройств, но никак не к их массовому производству. Этот творческий характер разработки ПС сохраняется до самого ее конца.
Следует отметить также особенность продукта разработки. Он представляет собой некоторую совокупность текстов (т.е. статических
объектов), смысл же (семантика) этих текстов выражается процессами обработки данных и действиями пользователей, запускающих эти процессы (т.е. является динамическим
). Это предопределяет выбор разработчиком ряда специфичных приемов, методов и средств.
Продукт разработки имеет и другую специфическую особенность: ПС при своем использовании (эксплуатации) не расходуется и не расходует используемых ресурсов.
1.2.
Жизненный цикл программного средства.
Под жизненным циклом
ПС понимают весь период его разработки и эксплуатации (использования), начиная от момента возникновения замысла ПС и кончая прекращением всех видов его использования [3.1 - 3.4]. Жизненный цикл включает все процессы создания и использования ПС (software
process
).
Различают следующие стадии жизненного цикла ПС (см. рис. 3.1): разработку ПС, производство программных изделий (ПИ) и эксплуатацию ПС.
Стадия разработки (development
) ПС состоит из этапа его внешнего описания, этапа конструирования ПС, этапа кодирования (программирование в узком смысле) ПС и этапа аттестации ПС. Всем этим этапам сопутствуют процессы документирования и управление (management
) разработкой ПС. Этапы конструирования и кодирования часто перекрываются, иногда довольно сильно. Это означает, что кодирование некоторых частей программного средства может быть начато до завершения этапа конструирования.
Внешнее описание (Requirementsdocument
) ПС является описанием его поведения с точки зрения внешнего по отношению к нему наблюдателю с фиксацией требований относительно его качества. Внешнее описание ПС начинается с определения требований к ПС со стороны пользователей (заказчика).
Конструирование (design
) ПС охватывает процессы: разработку архитектуры ПС, разработку структур программ ПС и их детальную спецификацию.
Кодирование (coding
) создание текстов программ на языках программирование, их отладку с тестированием ПС.
На этапе аттестации
ПС производится оценка качества ПС, после успешного завершения которого разработка ПС считается законченной.
Программное изделие (ПИ)
- экземпляр или копия, снятая с разработанного ПС. Изготовление
ПИ - это процесс генерации и/или воспроизведения (снятия копии) программ и программных документов ПС с целью их поставки пользователю для применения по назначению. Производство
ПИ - это совокупность работ по обеспечению изготовления требуемого количества ПИ в установленные сроки [3.1]. Стадия производства ПС в жизненном цикле ПС является, по-существу, вырожденной (не существенной), так как представляет рутинную работу, которая может быть выполнена автоматически и без ошибок. Этим она принципиально отличается от стадии производства различной техники. В связи с этим в литературе эту стадию, как правило, не включают в жизненный цикл ПС.
Стадия эксплуатации
ПС охватывает процессы хранения, внедрения и сопровождения ПС, а также транспортировки и применения (operation) ПИ по своему назначению. Она состоит из двух параллельно проходящих фаз: фазы применения ПС и фазы сопровождения ПС [3.4, 3.5].
Применение (operation)
ПС - это использование ПС для решения практических задач на компьютере путем выполнения ее программ.
Сопровождение (maintenance)
ПС - это процесс сбора информации о его качестве в эксплуатации, устранения обнаруженных в нем ошибок, его доработки и модификации, а также извещения пользователей о внесенных в него изменениях [3.1, 3.4, 3.5].
1.3. Понятие качества программного средства.
Каждое ПС должно выполнять определенные функции, т.е. делать то, что задумано. Хорошее ПС должно обладать еще целым рядом свойств, позволяющим успешно его использовать в течении длительного периода, т.е. обладать определенным качеством. Качество
ПС - это совокупность его черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей [3.6]. Это не означает, что разные ПС должны обладать одной и той же совокупностью таких свойств в их высшей возможной степени. Этому препятствует тот факт, что повышение качества ПС по одному из таких свойств часто может быть достигнуто лишь ценой изменения стоимости, сроков завершения разработки и снижения качества этого ПС по другим его свойствам. Качество ПС является удовлетворительным, когда оно обладает указанными свойствами в такой степени, чтобы гарантировать успешное его использование.
Совокупность свойств ПС, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этого ПС, т.е. от позиции, с которой должно рассматриваться качество этого ПС. Поэтому при описании качества ПС должны быть прежде всего фиксированы критерии
отбора требуемых свойств ПС. В настоящее время критериями качества ПС принято считать [3.6-3.10]:
функциональность,
надежность,
легкость применения,
эффективность,
сопровождаемость,
мобильность.
Функциональность
- это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС.
Надежность
подробно обсуждалась в первой лекции.
Легкость применения
- это характеристики ПС, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя.
Эффективность
- это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов.
Сопровождаемость
- это характеристики ПС, которые позволяют минимизировать усилия по внесению изменений для устранения в нем ошибок и по его модификации в соответствии с изменяющимися потребностями пользователей.
Мобильность
- это способность ПС быть перенесенным из одной среды (окружения) в другую, в частности, с одной ЭВМ на другую.
Функциональность и надежность являются обязательными критериями качества ПС, причем обеспечение надежности будет красной нитью проходить по всем этапам и процессам разработки ПС. Остальные критерии используются в зависимости от потребностей пользователей в соответствии с требованиями к ПС - их обеспечение будет обсуждаться в подходящих разделах курса.
1.4. Обеспечение надежности - основной мотив разработки программных средств.
Рассмотрим теперь общие принципы обеспечения надежности ПС, что, как мы уже подчеркивали, является основным мотивом разработки ПС, задающим специфическую окраску всем технологическим процессам разработки ПС. В технике известны четыре подхода обеспечению надежности [3.11]:
· предупреждение ошибок;
· самообнаружение ошибок;
· самоисправление ошибок;
· обеспечение устойчивости к ошибкам.
Целью подхода предупреждения ошибок - не допустить ошибок в готовых продуктах, в нашем случае - в ПС. Проведенное рассмотрение природы ошибок при разработке ПС позволяет для достижения этой цели сконцентрировать внимание на следующих вопросах:
· борьбе со сложностью,
· обеспечении точности перевода,
· преодоления барьера между пользователем и разработчиком,
· обеспечения контроля принимаемых решений.
Этот подход связан с организацией процессов разработки ПС, т.е. с технологией программирования. И хотя, как мы уже отмечали, гарантировать отсутствие ошибок в ПС невозможно, но в рамках этого подхода можно достигнуть приемлемого уровня надежности ПС.
Остальные три подхода связаны с организацией самих продуктов технологии, в нашем случае - программ. Они учитывают возможность ошибки в программах. Самообнаружение ошибки в программе означает, что программа содержит средства обнаружения отказа в процессе ее выполнения. Самоисправление ошибки в программе означает не только обнаружение отказа в процессе ее выполнения, но и исправление последствий этого отказа, для чего в программе должны иметься соответствующие средства. Обеспечение устойчивости программы к ошибкам означает, что в программе содержатся средства, позволяющие локализовать область влияния отказа программы, либо уменьшить его неприятные последствия, а иногда предотвратить катастрофические последствия отказа. Однако, эти подходы используются весьма редко (может быть, относительно чаще используется обеспечение устойчивости к ошибкам). Связано это, во-первых, с тем, что многие простые методы, используемые в технике в рамках этих подходов, неприменимы в программировании, например, дублирование отдельных блоков и устройств (выполнение двух копий одной и той же программы всегда будет приводить к одинаковому эффекту - правильному или неправильному). А, во-вторых, добавление в программу дополнительных средств приводит к ее усложнению (иногда - значительному), что в какой-то мере мешает методам предупреждения ошибок.
1.5. Методы борьбы со сложностью.
Мы уже обсуждали в лекции 2 сущность вопроса борьбы со сложностью при разработке ПС. Известны два общих метода борьбы со сложностью систем:
· обеспечения независимости компонент системы;
· использование в системах иерархических структур.
Обеспечение независимости компонент означает разбиение системы на такие части, между которыми должны остаться по возможности меньше связей. Одним из воплощений этого метода является модульное программирование. Использование иерархических структур позволяет локализовать связи между компонентами, допуская их лишь между компонентами, принадлежащими смежным уровням иерархии. Этот метод, по-существу, означает разбиение большой системы на подсистемы, образующих малую систему. Здесь существенно используется способность человека к абстрагированию.
1.6. Обеспечение точности перевода.
Обеспечение точности перевода направлено на достижение однозначности интерпретации документов различными разработчиками, а также пользователями ПС. Это требует придерживаться при переводе определенной дисциплины. Майерс предлагает использовать общую дисциплину решения задач, рассматривая перевод как решение задачи [3.11]. Лучшим руководством по решению задач он считает книгу Пойа "Как решать задачу" [3.12]. В соответствии с этим весь процесс перевода можно разбить на следующие этапы:
· Поймите задачу;
· Составьте план (включая цели и методы решения);
· Выполните план (проверяя правильность каждого шага);
· Проанализируйте полученное решение.
1.7. Преодоление барьера между пользователем и разработчиком.
Как обеспечить, чтобы ПС выполняла то, что пользователю разумно ожидать от нее? Для этого необходимо правильно понять, во-первых, чего хочет пользователь, и, во-вторых, его уровень подготовки и окружающую его обстановку. Поэтому следует - привлекать пользователя в процессы принятия решений при разработке ПС, - тщательно освоить особенности его работы (лучше всего - побывать в его "шкуре").
1.8. Контроль принимаемых решений.
Обязательным шагом в каждом процессе (этапе) разработки ПС должна быть проверка правильности принятых решений. Это позволит обнаруживать и исправлять ошибки на самой ранней стадии после ее возникновения, что, во-первых, существенно снижает стоимость ее исправления и, во-вторых, повышает вероятность правильного ее устранения.
· С учетом специфики разработки ПС необходимо применять везде, где это возможно,
· смежный контроль,
· сочетание как статических, так и динамических методов контроля.
Смежный контроль означает, проверку полученного документа лицами, не участвующими в его разработке, с двух сторон: во-первых, со стороны автора исходного для контролируемого процесса документа, и, во-вторых, лицами, которые будут использовать полученный документ в качестве исходного в последующих технологических процессах. Такой контроль позволяет обеспечивать однозначность интерпретации полученного документа.
Сочетание статических и динамических методов контроля означает, что нужно не только контролировать документ как таковой, но и проверять, какой процесс обработки данных он описывает. Это отражает одну из специфических особенность ПС (статическая форма, динамическое содержание).
Курс "Принципы разработки программного обеспечения с использованием RUP, эффективных юзкейсов и программного обеспечения IBM Rational Suite"
Большое внимание в курсе обучения уделяется вопросам Управления требованиями (Requirements management) и Управления изменениями (Change management), без удовлетворительного решения которых невозможно построение качественного программного продукта.
В качестве единой методологической основы в курсе используется Rational Unified Process (RUP). При этом особое внимание обращается на необходимость следовать его основополагающим принципам: итеративной разработке, управлении проектом, построенном на учете рисков и юзкейсах, большом внимании к архитектуре; на необходимость выработки собственного процесса разработки на основе RUP, опираясь на лучшие методы, описанные в RUP, а также любые источники, включая собственные методы разработки. Даются соответствующие рекомендации, касающиеся построения такого процесса.
В курсе также рассматриваются юзкейсы, поскольку все дисциплины RUP базируются на них (RUP декларирует себя как «use-case driven» подход). Однако позиция автора курса состоит в том, что применение юзкейсов на основе RUP вызывает большие трудности. Эффективные юзкейсы Алистера Коберна (Alistair Cockburn) получили за последнее время широкое признание, поскольку они с успехом решают все проблемы, с которыми ранее приходилось сталкиваться. В ходе обучения даются рекомендации, показывающие, как правильно строить юзкейсы, для того, чтобы они стали практическим инструментом, который используется всеми, кто имеет отношение к проекту. Кроме того, демонстрируется возможность использования RequisitePro для работы с эффективными юзкейсами, рассматривается принципиальная возможность организации управления итеративной разработкой на основе их (т.е. эффективных юзкейсов и RequisitePro) совместного использования.
Вопросы, касающиеся использования UML и Rational Rose, решаются с опорой на прагматический подход: в курсе представлены методы, лучшие из всех возможных, с которыми автор курса сталкивался как при личном участии в проектах, так и при изучении литературы (как правило, англоязычной). Весь процесс разработки проиллюстрирован на основе единого примера.
В курсе показано, что инструменты, входящие в IBM Rational Suite должны быть настроены для совместной работы в рамках единого, хорошо продуманного процесса. В частности, продемонстрировано, как организовать совместную работу Rational Rose и RequisitePro для управления требованиями; ClearQuest и RequisitePro для управления изменениями в требованиях; RequisitePro, MS Project и ClearQuest для организации групповой разработки. Аспекты использования ClearCase и различных инструментов тестирования рассматриваются в процессе обучения на концептуальном уровне.
Курс предназначен для всех тех, кто интересуется современными подходами к разработке программного обеспечения на основе методологии, технологий и инструментальных средств, предлагаемых компанией IBM Rational.
Программа курса
Унифицированный процесс разработки программного обеспечения (Rational Unified Process)
· Современный взгляд на RUP как на совокупность базовых принципов, процесс разработки и фреймворк
· Базовые принципы RUP
· приверженность итеративной схеме разработки (iterative approach)
· большое внимание к рискам (risk-driven, risk mitigation)
· управление проектами на основе юзкейсов (use case driven)
· сфокусированность на архитектуре (architecture-centric)
· Сущность итеративной разработки. Сопоставление ее с последовательной («waterfall») моделью.
· Риски в итеративной и последовательной моделях разработки
· RUP как процесс разработки программного обеспечения
· Два измерения RUP: статическая и динамическая составляющие
· Элементы динамической структуры: итерации, фазы, вехи (milestones)
· Фазы Inception, Elaboration, Construction, Transition. Предназначениекаждойизних
· Основные элементы статической структуры: роли, артефакты, активности и рабочие потоки (workflows). Дисциплины: основные и вспомогательные. Их роль и место в организации процесса разработки
· Дополнительные элементы статической структуры. SPEM – профиль UML, используемый для построения статической структуры
· RUP как процессный адаптируемый фреймворк
· Набор лучших методов в контексте всех дисциплин
· Средства доступа к этим методам: web-браузер и Extended Help (доступ из любого продукта, входящего в Rational Suite)
· Инструменты конфигурирования процесса под конкретную роль. Понятие plug-in элемента, как средства расширения собственной конфигурации RUP Использование инструмента RUP Builder
· RDN – сайт для обмена plug-in элементами, расширяющими RUP
· Средства разработки для расширения RUP с использованием IBM Rational Rose в нотации профиля UML SPEM. Использование инструмента Rational Process Workbench
Введениев UML и IBM Rational Rose
UML. Структура языка: модельные элементы, диаграммы, средства расширения. Необходимость инструментальной поддержки.
Введение в IBM Rational Rose
Интерфейс с пользователем
Демонстрация основных приемов работы на примере юзкейсных диаграмм.
Стереотипы. Различные приемы их использования.
Построение новых моделей на основе фреймворков. Мастер – Framework Wizard Add-in.
Обеспечение переносимости моделей в Rational Rose с использованием Virtual Path Map.
Принципы организации групповой разработки модели
Моделирование бизнес-процессов
Понятие бизнес-процесса. Реинжиниринг бизнес-процесса (BPR)
Моделирование бизнес-процессов c использованием Rational Rose
Диаграммы активностей (Activity diagram)
Использование бизнес-юзкейсов
Использование модели данных при построении Domain Model
Диаграммы состояний (Statechart diagram)
Управление требованиями
Общая схема работы с требованиями в RUP
Классификация требований по схеме FURPS+. Требования функциональные и нефункциональные. Атрибуты качества (Quality attributes)
Понятие стейкхолдера (заинтересованное лицо). Запрос стейкхолдера (Stakeholder Request) и рекомендации по его документальному оформлению в RUP. Роль системного аналитика в преобразовании запросов стейкхолдеров в унифицированный набор документов
Основные документы для работы с требованиями: Vision, Use cases, Supplementary Specification и Glossary. Принципы адаптации для конкретных проектов. Роль фич (features) при написании Vision
Использование юзкейсов при написании функциональных требований. Акцент на текстовую природу юзкейса. Роль UML в Управление требованиями
Эффективные юзкейсы А. Коберна. Сравнение с классическими юзкейсами, определяемыми в RUP. Важнейшие характеристики эффективных юзкейсов: тип шаблона, бизнес/система, черный/прозрачный, уровень целей
Четыре уровня точности эффективного юзкейса. Принципы для определения достаточного для конкретного юзкейса уровня точности
Основные модели, на которых базируются эффективные юзкейсы: пользователи со своими целями и стейкхолдеры со своими интересами
Три уровня целей для юзкейсов. Фундаментальная роль юзкейсов уровня целей пользователя (User goals) для покрытия функциональных требований к системе
Технические приемы написания юзкейсов. Примеры достаточно сложных юзкейсов. Паттерны для эффективных юзкейсов, помогающие оценить качество их написания
Введение в IBM Rational RequisitePro
Роль IBM Rational RequisitePro в эффективной организации Управления требованиями
Основные понятия: проект, требование, документ, база данных. Основные механизмы для установления связей между требованиями. Их роль в Управлении изменениями
Атрибуты требований. Рекомендации RUP по их использованию. Роль атрибутов в управлении процессом разработки
Рекомендации RUP по использованию RequisitePro в конкретном проекте. Документ Requirements Management Plan. Необходимость его написания и рекомендации по его построению
Три способа представлений (view) требований, находящихся в Базе данных RequisitePro: Attribute Matrix, Traceability Matrix, Traceability Tree
Организация обсуждения требований в режиме онлайн. Принципы использования E-mail Reader
Использование RequisitePro для работы с эффективными юзкейсами. Принципы организации итеративной разработки. Демонстрация на примерах конкретных проектов
Организация совместной работы IBM Rational RequisitePro, MS Project и IBM Rational ClearQuest для организации групповой разработки
Объектно-ориентированный анализ и дизайн с использованием IBM Rational Rose
Схема перехода от юзкейсов к объектному дизайну. Реальные проблемы, которые с этим связаны. Системные события и системные операции. Использование Диаграмм последовательностей (Sequence diagram).
Роль объектно-ориентированного анализа (ООА) как вспомогательного этапа, предшествующего объектно-ориентированному дизайну (OOD). Использование диаграмм классов (Class Diagram) для построения Концептуальной модели предметной области.
Схема перехода от модели объектного анализа к модели объектного дизайна (Design Model). Использование контрактов системных операций для облегчения этого перехода. Реализация контрактов в IBM Rational Rose.
Использование Диаграмм взаимодействия (Interaction Diagram): Диаграмм последовательностей (Sequence diagram) и Диаграмм кооперации (Collaboration diagram) при выполнении Объектного дизайна.
Роль паттернов дизайна при построении Объектного дизайна. Паттерныгруппы GRASP: Information Expert, Creator, Low Coupling, High Cohesion, Controller. Примеры использования этих паттернов.
Обзор паттернов группы GoF. Примеры их использования.
Введение в IBM Rational ClearQuest
Роль IBM Rational ClearQuest в эффективной организации Управления изменениями в проекте. Принципы функционирования в клиент-серверной среде.
Основные понятия: Схемы (Schemas), Схемные репозитории (Schema repositories), Базы данных и Соединения (Connections).
Планирование процесса Управления изменениями. Фундаментальная роль модели перехода из одного состояния в другое - State Transition Model. Понятия – state, action, rule. Идентификация ключевых ролей, которые используют в IBM Rational ClearQuest.
Использование IBM Rational ClearQuest в режиме Клиента. Интерфейс с пользователем, Основные операции возможные в этом режиме.
Использование IBM Rational ClearQuest в режиме администрирования. ClearQuest Designer. Проектирование новых схем и адаптация существующих. Организация работы со Схемным репозиторием.
Основные предопределенные схемы: Defect и Enhancement Request. Их место и роль в общем процессе разработки. Принципы организации совместной работы IBM Rational ClearQuest, IBM Rational ClearCase и Test Manager для работы со схемой Defect.
Совместная работа IBM Rational ClearQuest и IBM Rational RequisitePro при работе со схемой Enhancement Request для организации Управления изменениями, которые связанны с требованиями. Демонстрация на конкретном примере.
Совместная работа IBM Rational ClearQuest и MS Project c использованием компоненты Traker, входящей в IBM Rational Suite, для организации групповой работы. Демонстрация на конкретном примере.
Введение в TestManager
TestManager – открытый и расширяемый фреймворк для обеспечения всех инструментов, артефактов и данных. Связанных с тестированием. Организация интерфейса с пользователем
Рабочий поток (workflow), связанный с использованием TestManager. Основные виды работ (activities) в рамках этого рабочего потока: планирование, проектирование, реализация, исполнение и оценка результатов
Принципы интеграции TestManager с другими инструментами, входящими в IBM Rational Suite. Совместная работа IBM Rational ClearQuest
Организация функционального тестирования (functional testing)
Организация тестирования, связанного с оценкой производительности разрабатываемой системы (performance testing)
Введение в SoDA
Принципы построения отчетов в SoDA. Возможность извлечения информации из любого продукта, входящего в IBM Rational Suite. Понятие Domain (источник информации)
Организация интерфейса с пользователем. Режимы работы: документ (Document) и отчет (Report). Принцип согласования между документом и источником в режиме Document на основе процесса Intelligent Document Merging
Схема построения шаблона (Template) отчета в SoDA на основе объектно-ориентированного подхода. Команды, используемые для построения Template: OPEN, REPEAT, DISPLAY, LIMIT. Примеры использования
Литература
.
1. Е.А. Жоголев. Введение в технологию программирования (конспект лекций). - М.: "ДИАЛОГ-МГУ", 1994.
2. М. Зелковец, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. - М.: Мир, 1982. - С. 11.
3. К. Зиглер. Методы проектирования программных систем. - М.: Мир, 1985. - С. 15-23.
4. Дж. Фокс. Программное обеспечение и его разработка. - М.: Мир, 1985. - С. 53-67, 125-130.
5. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. - P. 5-10.
6. Criteria for Evaluation of Software. ISO TC97/SC7 #383.
7. Revised version of DP9126 - Criteria of the Evaluation of Software Quality Characteristics. ISO TC97/SC7 #610. - Part 6.
8. Б. Боэм, Дж. Браун, Х. Каспаридр. Характеристики качества программного обеспечения. - М.: Мир, 1981. - С. 17-24.
9. В.В. Липаев. Качество программного обеспечения. - М.: Финансы и статистика, 1983. - С. 18-30.
10. Б. Шнейдерман. Психология программирования. - М.: Радио и связь, 1984. - С. 99-103.
11. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. С. 32 - 48.
12. Д. Пойа. Как решать задачу. - М.: Наука, 1961.
|
