СЛОВАРЬ ТЕРМИНОВ ПРОГРАММНОЙ ИНЖЕНЕРИИ

 

Абстракция – способность отделить существенные черты предмета (объекта) от второстепенных, видеть идею, которая будет реализована.

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

Агрегация – объединение ряда понятий в новое понятие (отношение типа «часть-целое»), общие признаки которого могут быть суммой признаков других компонентов или быть новым признаком.

Акторы – действующие лица, которые управляют работой системы.

Анализ требований – отображение функций системы и ее ограничений в модели предметной области.

Артефакт – любой продукт деятельности специалистов по разработке ПО.

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

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

Валидация – проверка соответствия разработки программной системы требованиям заказчика.

Верификация – проверка правильности реализации функций системы на каждом этапе жизненного цикла с учетом требований.

Взаимодействие объектов – связь между объектами через механизмы посылки сообщений друг другу.

Гарантия качества программного обеспечения – действия на каждом этапе жизненного цикла по проверке и подтверждении достигаемого качества соответственно стандартам и процедурам.

Диаграмма – графическое представление сценариев работы системы с помощью классов, состояний, событий и т.п.

Домен предметной области - спектр задач проблемы, которые допускают похожие приемы их решения.

Задача системы – способ (технология) достижения цели системы с конкретными числовыми (в том числе временными) характеристиками.

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

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

Инженерия качества – процесс управления предоставлением продуктам ПО свойств качества (надежность, отказоустойчивость и т.п.).

Инженерия требований – сбор, анализ, оформление условий и ограничений на разработку системы в виде спецификации, согласованной как с заказчиком, так и с исполнителем.

Институт инженеров по электротехнике и радиоэлектронике ( Institute of Electrical, and Electronics Engineers, IEEE) – профессиональная организация, в центре внимания которой лежат разработки в области электроники, электротехники и программного обеспечения.

Институт технологий разработки программного обеспечения ( Software Engineering Institute, SEI) – институт, созданный с целью обеспечить качество программного обеспечения.

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

Информационное обеспечение – набор средств, для предоставления информации пользователям о содержании и условиях ее применения.

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

Каркас (фрейм) – разновидность абстрактной архитектуры для определения выделенных компонентов.

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

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

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

Конкретизация – добавление существенных признаков, для расширения содержания некоторого понятия и сужения объема понятия.

Конечные пользователи системы – профессиональные лица, которые заказывают компьютерную систему и пользуются ею.

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

Конфигурация – вариант (версия) изготовленной программной системы из отдельных экземпляров компонентов и подсистем.

Концептуальное моделирование – процесс построения модели проблемы, ориентированной на понимание ее человеком.

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

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

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

Модель зрелости возможностей ( Capability Maturity Model, CMM) – системный метод, позволяющий оценить потенциал организации в целом относительно разработки программного обеспечения. Создан в Институте разработки программного обеспечения (г. Питтсбург).

Модель Жизненного Цикла – типовая схема последовательности работ на процессах разработки некоторого типа программного продукта.

Модель процесса – определенная последовательность действий, сопровождающая изменение состояния программного объекта.

Модель состояний – отображение динамики изменения состояния объекта класса, которое изменяет его поведение.

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

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

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

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

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

Объектно – ориентированная модель – структура и совокупность объектов, которые взаимодействуют между собой, обладают свойствами и поведением.

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

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

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

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

Проектирование – преобразования требований в последовательность проектных решений и в архитектуру системы.

Проектирование концептуальное – уточнение понимания и согласование деталей требований к системе.

Проектирование архитектурное – определение структурных особенностей строящейся системы.

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

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

Спецификация – описание алгоритма, правил, ограничений действий объектов с учетом стандартов, критериев качества и др.

Событие – явление, которое провоцирует смену определенного состояния и переход к другому состоянию в системе.

Состояние (домена, системы, объекта и тому подобных) – фиксация определенных свойств на определенный момент или интервал времени.

Сценарий – конкретная последовательность действий, которая иллюстрирует поведение и выполнение экземпляра варианта использования.

Структура системы – множество элементов и отношений между ними.

Требование – соглашение или договор между заказчиком и исполнителем системы относительно свойств ее функций, условий работы в заданной среде.

Управление качеством – комплекс способов и системной деятельности по планированию, управлению и оценке качества программного обеспечения.

Функциональные требования – это условия и ограничения на цели, функции системы и принципы их выполнения на компьютере.

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

 

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Амблер С. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки. Библиотека программиста.- СПб.: Питер, 2005г.- 412с.

2. Уэнди Боггс, Майкл Боггс. UML и Rational Rose 2002. –Издательство «Лори», 2004.-с.509

3. Г.Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на С++, 2-е изд. Пер. с англ.-М.: «Издательство БИНОМ», СПб.: Невский диалект, 1998г. -560с.

4. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя.- М.: ДМК, 2000г.- 432с.

5. Бобровский С.И. Технологии C#Builder. Разработка приложений для бизнеса. Учебный курс.- СПб.: Питер, 2007. -672c.

6. Брауде Э. Технология разработки программного обеспечения.- СПб.: Питер, 2004г.- 655с.

7. Вигерс Карл. Разработка требований к программному обеспечению / Пер. с англ.- М.: Издательско –торговый дом «Русская Редакция», 2004. – 576с.

8. Иванова Г.С. Технология программирования: Учебник для вузов. -2-е изд., стереотип.- М.: Изд-во МГТУ им. Н.Э Баумана, 2003.- 320с.

9. Калянов Г.Н. CASE- технологии. Консалтинг при автоматизации бизнес – процессов, 2-е изд.- М.: Горячая линия-Телеком, 2000г.-320с.

10. Киммел П. UML. Основы визуального анализа и проектирования = UML. Универсальный язык программирования \ Пол Киммел: перевод с англ. Кедрова Е.А.- М.: НТ Пресс, 2008.-272с.

11. Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование: Пер. с англ.- М.: ДМК Пресс, 2001.- 176с.

12. Алистер Коберн. Современные методы описания функциональных требований к системам. Издательство «Лори», 2002.-263с.

13. Леффингуэлл, Дин, Уидриг, Дин. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. Пер. с англ.- М.: Издательский дом «Вильямс», 2002г.-448с.

14. Маклаков С.В. Моделирование бизнес-процессов с ALLFusion Process Modeler (BPwin 4.1).-М.: ДИАЛОГ-МИФИ, 2003 – 240с.

15. Марка Д.А., Маг-Гоуэн К. Методология структурного анализа и проектирования.- М.: МетаТехнология, 1993г.

16. Мацяшек, Лешек, А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML: Пер. с англ.-М.: Издательский дом «Вильямс», 2002г.- 432с.

17. Орлов С.А. Технологии разработки программного обеспечения. Учебное пособие. 2-е изд.- СПб.: Питер, 2003г.-480с.

18. Пышкин Е.В. Основные концепции и механизмы объектно-ориентированного программирования. – СПб.: БХВ - Петербург, 2005.- 640с.

19. Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов на примере разработки книжного Internet -магазина: Пер. с англ.- М.: ДМК Пресс, 2002г.- 160с.

20. Соммервилл, Иан. Инженерия программного обеспечения, 6-е издание.: Пер. с англ.- М.: Издательский дом «Вильямс», 2002г.-624с.

21. Фаулер М. UML. Основы, 3-е издание. – Пер. с англ.- СПб: Символ-Плюс, 2006.-192с.

22. Jacobson, Ivar, Object-Oriented Software Engineering: A Use Case Driven Approach (Addison-Wesley Object Technology Series), Reading, MA: Addison-Wesley, 1994.

23. Larry Constantine and Lucy Lockwood, Software for Use, Addison-Wesley, 2000.

24. К.Чарнецки, У.Айзенекер. Порождающее программирование: методы, инструменты, применение. Для профессионалов. – Спб.: Питер, 2005. – 731с.

25. Кубеков Б.С. Учебно-методический комплекс по дисциплине «Технология программирования» для студентов КазНТУ имени К.И.Сатпаева по специальности 050704 –Вычислительная техника и программное обеспечение. –Алматы: КазНТУ, 2004.- 103с.

26. Кубеков Б.С. Учебно-методический комплекс по дисциплине «Объектно-ориентированное программирование» для студентов КазНТУ имени К.И.Сатпаева по специальности 050704 –Вычислительная техника и программное обеспечение. –Алматы: КазНТУ, 2006.- 94с.

27. Кубеков Б.С. Учебно-методический комплекс по дисциплине «Технология разработки программного обеспечения» для студентов КазНТУ имени К.И.Сатпаева по специальности 050704 –Вычислительная техника и программное обеспечение. –Алматы: КазНТУ, 2007.- 99с.

28. Кубеков Б.С. Учебно-методический комплекс по дисциплине «Программная инженерия» для студентов КазНТУ имени К.И.Сатпаева по специальности 050602 –Информатика. –Алматы: КазНТУ, 2007.- 98с.

29. Кубеков Б.С. Учебно-методический комплекс по дисциплине «Сетевые технологии программирования» для студентов КазНТУ имени К.И.Сатпаева по специальности 050704 –Вычислительная техника и программное обеспечение. –Алматы: КазНТУ, 2008.- 85с.

30. Кубеков Б.С. Указательный тип в языках программирования C/C++: Учеб.пособие.- Алматы: КазНТУ, 2008.- 103с.

 

 

Приложение А. Образец документа – концепции (Техническая спецификация)

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

Содержание

Введение

В данном разделе необходимо представить общую характеристику документа-концепции в целом; наряду с этим он должен содержать следующие подразделы.

Цель документа-концепции

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

⇐ Предыдущая24252627282930313233Следующая ⇒

Поделиться: