Основи програмної інженерії

Модуль 1

1. В чому полягає предмет програмної інженерії?

2. Як пов’язана інфраструктура програмної інженерії та базовий процес програмної інженерії?

3. Які можна виділити аспекти інфраструктури програмної інженерії?

4. Яким чином реалізується базовий процес програмної інженерії на рівні організації та проекту розробки ПС?

5. Який компонент техніко-технологічного аспекту інфраструктури програмної інженерії є найважливішим?

6. Який компонент кадрового аспекту інфраструктури програмної інженерії є найважливішим?

7. В чому полягають особливості ролей компанії-розробника ПЗ на рівні організації та на рівні проекту?

8. Які фактори впливають на склад команди розробника ПЗ на рівні проекту?

9. В чому полягає техніко-технологічний аспект інфраструктури програмної інженерії?

10. В чому полягає кадровий аспект інфраструктури програмної інженерії?

11. Які ролі на рівні проекту несуть найбільшу відповідальність за забезпечення якості програмного продукту?

12. Які ролі на рівні організації несуть найбільшу відповідальність за забезпечення якості програмного продукту?

13. Опишіть компоненти техніко-технологічного аспекту інфраструктури програмної інженерії.

14. Опишіть компоненти кадрового аспекту інфраструктури програмної інженерії.

15. Що таке програмна система?

16. Що викликало необхідність створення міжнародних стандартів в області програмної інженерії?

17. Чим обумовлена структура стандарту SWEBOK?

18. В яких розділах SWEBOK розглядаються питання забезпечення якості ПЗ?

19. Які групи вимог висуваються до програмної системи?

20. В чому полягає процес верифікації вимог?

21. Яка мета верифікації вимог до ПЗ?

22. Як здійснюється аналіз та оцінка якості проекту ПЗ?

23. В чому різниця між архітектурним стилем та шаблоном проектування?

24. Опишіть методи проектування програмної системи.

25. Чи приділяється увага якості ПЗ на етапі конструювання?

26. Охарактеризуйте рівні та прийоми тестування.

27. В чому полягає роль тестування в забезпеченні якості програмного продукту?

28. В чому полягає процес супроводу ПЗ?

29. Які існують прийоми супроводу ПЗ?

30. Яким чином проблема якості ПЗ відображена у SWEBOK?

31. В чому різниця між різними моделями життєвого циклу ПЗ?

32. Опишіть процеси життєвого циклу ПЗ.

33. Що таке модель життєвого циклу ПЗ та яка мета її створення?

34. Охарактеризуйте поняття моделі життєвого циклу та перелічите їхні види.

35. Дайте характеристику каскадної моделі життєвого циклу.

36. Дайте характеристику спіральної моделі життєвого циклу.

37. Дайте характеристику інкрементної моделі життєвого циклу.

38. Дайте характеристику стандартизованої моделі життєвого циклу.

39. В чому переваги та недоліки каскадної моделі життєвого циклу?

40. В чому переваги та недоліки спіральної моделі життєвого циклу?

41. В чому переваги та недоліки інкрементної моделі життєвого циклу?

42. Опишіть основні процеси стандартизованої моделі життєвого циклу.

43. Які цілі підтримуючих процесів стандартизованої моделі життєвого циклу?

44. Дайте визначення вимог до програмної системи.

45. На якому етапі життєвого циклу фіксується контракт між замовником та розробником ПЗ?

46. Опишіть джерела даних щодо вимог до ПЗ.

47. Порівняйте різні види вимог до ПЗ.

48. В чому полягає принцип приховування інформації в об’єктно-орієнтованому аналізі?

49. Поясніть нотацію, що використовується на діаграмі варіантів використання.

50. Які задачі вирішує трасування вимог?

51. Поясніть базові відношення, що використовуються у діаграмах варіантів використання.

52. Яким чином вимоги описуються у документації?

53. Наведіть приклади різних видів функціональних вимог.

54. Наведіть приклади різних видів нефункціональних вимог.

55. Поясніть, які проблеми вирішує аналітик при аналізі вимог.

56. В чому полягають переваги та недоліки різних методів збору вимог?

57. В чому різниця між процесами верифікації та валідації вимог?

58. Яким чином здійснюється формалізація вимог?

59. Розробіть діаграму варіантів використання для програмної системи, що підтримує роботу супермаркету.

60. Розробіть діаграму варіантів використання для програмної системи, що підтримує он-лайн продаж залізничних квитків.

61. Розробіть діаграму варіантів використання для програмної системи, що підтримує продаж квитків у метрополітені.

62. Розробіть діаграму варіантів використання для програмної системи, що підтримує бронювання готелю через мережу Інтернет.

63. Розробіть діаграму варіантів використання для програмної системи, що підтримує система інтернет-банкінгу.

64. Розробіть діаграму варіантів використання для програмної системи, що підтримує роботу бібліотеки.

65. Розробіть діаграму варіантів використання для програмної системи, що підтримує роботу соціальної мережі.

66. Розробіть діаграму варіантів використання для програмної системи, що підтримує роботу Інтернет-магазину.

67. Розробіть діаграму варіантів використання для програмної системи, що підтримує роботу корпоративної телефонної мережі.

68. Розробіть діаграму варіантів використання для програмної системи, що підтримує роботу кол-центру.

69. Розробіть діаграму варіантів використання для програмної системи служби підтримки мобільного оператора.

70. Розробіть діаграму варіантів використання для програмної системи, що підтримує роботу автомату поповнення рахунків.

71. Розробіть діаграму варіантів використання для програмної системи, що підтримує технологію «розумного будинку».

72. Розробіть діаграму варіантів використання для програмної системи, що підтримує роботу системи комутації телефонних дзвінків.

73. Розробіть діаграму варіантів використання для програмної системи, що підтримує роботу системи обробки результатів соціологічних опитувань.

74. Дайте характеристику структурного методу проектування ПЗ.

75. Наведіть основні особливості та можливості об’єктно-орієнтованого проектування.

76. Поясніть нотацію, що використовується на діаграмах компонентів та розгортання.

77. Дайте характеристику методології SADT.

78. В чому різниця між діаграмами структури та поведінки в UML?

79. Опишіть основні елементи UML діаграм.

80. З яких частин складається програмний компонент?

81. Опишіть, з чого складається зовнішня частини програмного компонента.

82. Дайте характеристику методології компонентної розробки програмної системи.

83. В чому переваги та недоліки компонентної методології розробки програмної системи?

84. В чому різниця між діаграмами компонентів та розгортання?

85. Побудуйте діаграму компонентів програмної системи, що підтримує роботу Інтернет-магазину.

86. Побудуйте діаграму компонентів програмної системи, що підтримує роботу супермаркету.

87. Побудуйте діаграму компонентів програмної системи, що підтримує роботу системи інтернет-банкінгу.

88. Побудуйте діаграму компонентів програмної системи, що підтримує роботу служби підтримки мобільного оператора.

6 ) інфраструктура - умови середовища та методичне забезпечення базового процесу ПІ і підтримка дій його виконавців , що займаються виробництвом програмного продукту ;

 Програмобудування великих програмних проектів стає інженерним за своєю суттю. У ньому , крім програмістів , беруть участь :

- Менеджери , які планують і керують проектом , відстежують терміни і витрати ;

- Інженери служби зберігання готових компонентів;

- Технологи , які визначають інженерні методи і стандарти, що регламентують і регулюють процес побудови програмних проектів ;

- Тестувальники , які перевіряють правильність виконання процесів , збір даних при тестуванні і оцінку якості компонентів і системи в цілому. Менеджер проекту - це головна діюча особа проектом , відповідальна за проектування и контроль Виконання робіт спеціальнімі службами інфраструктурі проекту в організації , зокрема служби веріфікації , тестування , якості ТОЩО .

7) Розробка ПЗ – це процес визначення архітектури, набору компонентів, їх інтерфейсів, інших характеристик системи і кінцевого складу програмного продукту.

Область знань «Проектування ПЗ (Software Design)» складається з таких розділів:

– базові концепції проектування ПЗ (Software Design Basic Concepts),

– ключові питання проектування ПЗ (Key Issue in Software Design),

– структура й архітектура ПЗ (Software Structure and Architecture),

– аналіз і оцінка якості проектування ПЗ (Software Design Quality Analysis and Evaluation),

– нотації проектування ПЗ (Software Design Notations),

– стратегія і методи проектування ПЗ (Software Design Strategies and Methods).

8) Важливим завданням управління проектом є формування команди. Керівникам проекту і функціональних підрозділів, що беруть участь у створенні проекту, на цій стадії приходиться вирішувати ряд специфічних задач, пов'язаних з мотивацією праці, конфліктами, виконанням, контролем, відповідальністю, комунікаціями, владою, лідерством і т.п.

Створення професіональної команди для нового проекту ‑ один із основних обов’язків проект-менеджера на першому етапі його роботи. Цей процес вимагає ряд навиків управління у визначенні, відборі і об’єднанні в команду спеціалістів із різних відділів і організацій.

Формуючи команду, проект-менеджер збирає разом групу людей, намагаючись об’єднати їх загальною ціллю і єдиними задачами. Новизна, унікальність, ризик і швидкоплинність — всі ці риси притаманні новому проекту, вони ж і визначають труднощі при формуванні команди. Створення команди для нового проекту ускладнено ще й тим, що ці люди не працювали разом, не мають загальних цінностей і норм, але повинні працювати ефективно і синхронно. Необхідний тривалий час, щоб всередині групи виникло командне почуття, щоб встановсь загальні норми, стандарти і цінності. Щоб проект був успішним, згрупування людей повинно відбутися до того, як команда почне працювати “на повну потужність”.

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

9) До технічних ресурсів належать: комп’ютери, пристрої (принтери, сканери тощо), сервери і т.п., до програмних – загальносистемне ПЗ середовища розробки, напрацювання колективу, оформлені у вигляді компонентів повторного використання, та інформаційне забезпечення. Технологічні та методичні ресурси складають методики, процедури, правила, рекомендації стандартів з процесу і керування персоналом разом  з комплектом документів, що встановлює регламент виконання і регулювання процесів ЖЦ, застосовуваних для розв’язання конкретних задач проекту.

10) Людські ресурси – це групи розробників і служб керування проектом, планами, якістю, ризиком, конфігурацією, а також перевірки правильності виконання проекту розробниками Подиляються вони на технологiв,тестувальникiв,конструювальникiв,проектувальникiв,менеджерiв тощо.

16) Первоначальное развитие аутсорсинга, а также относительно низкая стоимость человеческих ресурсов в развивающихся странах третьего мира привело к взрыву мыльного пузыря .com 1990-х годов. Это оказало негативное воздействие на многие аспекты профессии программного инженера. Например, некоторые студенты в развитых странах не хотели получать образование, связанное с программной инженерией из-за страха оффшорного аутсорсинга (импорт программных продуктов или услуг из других стран) и вытеснения иностранными рабочими. Когда североамериканцы будут уходить с работы, азиаты только прибывать на неё. Когда азиаты будут уходить с работы, европейцы будут на неё приезжать. Это обеспечивает непрерывную возможность иметь людей, следящих за критически важными бизнес-процессами 24 часа в сутки, без выплаты компенсации за сверхурочную работу и не лишая людей сна. Поэтому, чтобы люди не зависимо от страны могли создавать ПО на одном уровне, были созданыобщие международные сдандарты в области программной инженерии

17) Назначение SWEBOK — в объединении знаний по инженерии программного обеспечения

призванных обеспечить следующее:

определить необходимый набор знаний и рекомендуемые практики;

определить этические и профессиональные стандарты;

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

18) Проектирование программного обеспечения (Software Design)

Конструирование программного обеспечения (Software Construction)

Тестирование программного обеспечения (Software Testing)

Сопровождение программного обеспечения (Software Maintenance)

Управление конфигурацией программного обеспечения (Software Configuration Management)

19) К программной системе выдвигаются две группы требований:функциональные и не функциональные

20) Верификация требований - процесс проверки соответствия требований потребностям, их непротиворечивости, полноты, реализуемости, соответствия стандартам

26 2.1.1 Модульное тестирование (Unit testing)позволяет проверить функционирование отдельно взятого элемента системы. Что считать элементом – модулем системы определяется контекстом. 2.1.2 Интеграционное тестирование (Integration testing)Данный уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями. 2.1.3 Системное тестирование (System testing) охватывает целиком всю систему. системное тестирование, обычно фокусируется на нефункциональных требованиях – безопасности, производительности, точности, надежности т.п. тестируются интерфейсы к внешним приложениям, аппаратному обеспечению, операционной среде и т.д.3.1 Техники, базирующиеся на интуиции и опыте инженера>>Специализированное тестирование Тесты основываются на опыте, интуиции и знаниях инженера, рассматривающего проблему с точки зрения имевшихся ранее аналогий. 3.1.2 Исследовательское тестирование (Exploratory testing) определяется как одновременное обучение, проектирование теста и его исполнение. 3.2 Техники, базирующиеся на спецификации (Specification-based techniques)>>3.2.1 Эквивалентное разделение <приложения> (Equivalence partitioning) Рассматриваемая область приложения разделяется на коллекцию наборов или эквивалентных классов, которые считаются эквивалентными с точки зрения рассматриваемых связей и характеристик <спецификации>. 3.2.2 Анализ граничных значений (Boundary-value analysis) Тесты строятся с ориентацией на использование тех величин, которые определяют предельные характеристики тестируемой системы. 3.2.3 Таблицы принятия решений (Decision table)Такие таблицы представляют логические связи между условиями (могут рассматриваться в качестве “входов”) и действиями (могут рассматриваться как “выходы”). 3.2.4 Тесты на основе конечного автомата (Finite-state machine-based)Строятся как комбинация тестов для всех состояний и переходов между состояниями, представленных в соответствующей модели (переходов и состояний приложения).3.2.5 Тестирование на основе формальной спецификации (Testing from formal specification)Для спецификации, определенных с использованием формального языка, возможно автоматически создавать и тесты для функциональных требований. 3.2.6 Случайное тестирование (Random testing)тесты генерируются случайным образом по списку заданного набора специфицированных характеристик. 3.3 Техники, ориентированные на код (Code-based techniques)>>3.3.1 Тесты, базирующиеся на блок-схеме (Control-flow-based criteria) Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В какой-то степени напоминает тесты на основе конечного автомата. Отличие – в источнике набора тестов. Максимальная отдача от тестов на основе блок-схемы получается когда тесты покрывают различные пути блок-схемы – по-сути, сценарии потоков работ (поведения) тестируемой системы.3.3.2 Тесты на основе потоков данных (Data-flow-based criteria)В данных тестах отслеживается полный жизненный цикл величин (переменных) – с момента рождения (определения), на всем протяжении использования, вплоть до уничтожения (неопределенности).3.3.3 Ссылочные модели для тестирования, ориентированного на код (Reference models for code-based testing – flowgraph, call graph)Является не столько техникой тестирования, сколько контролем структуры программы, представленной в виде дерева вызовов (например, sequence-диаграммы, определенной в нотации UML и построенной на основе анализа кода). 3.4 Тестирование, ориентированное на дефекты (Fault-based techniques)>>Как это ни странно звучит на уровне названия таких техник тестирования, они, действительно, ориентированы на ошибки. Точнее – на специфические категории ошибок. 3.4.1 Предположение ошибок (Error guessing)Направлены на обнаружение наиболее вероятных ошибок, предсказываемых, например, в результате анализа рисков.3.4.2 Тестирование мутаций (Mutation testing)Мутация – небольшое изменение тестируемой программы, произошедшее за счет частных синтаксических изменений кода (в частности, рефакторинга). Соответствующие тесты запускаются для оригинального и всех “мутировавших” вариантов тестируемой программы.3.5 Техники, базирующиеся на условиях использования (Usage-based techniques)3.5.1 Операционный профиль (Operational profile)Базируется на условиях использования системы.3.5.2 Тестирование, базирующееся на надежности инженерного процесса (Software Reliability Engineered Testing)Базируется на условиях разработки системы.3.6 Техники, базирующиеся на природе приложения (Techniques based on the nature of the application)Описанные выше техники могут применяться к любым типам программных систем. 3.7 Выбор и комбинация различных техник (Selecting and combining techniques)>>3.7.1 Функциональное и структурное (Functional and structural)Техники тестирования, строящиеся на основе спецификаций или кода часто называют функциональными или структурными, соответственно. Оба подхода не должны противопоставляться, но дополнять друг друга.3.7.1 Определенное или случайное (Deterministic vs. random)Обычно тесты можно распределить по данным группам на основе используемой политики выбора или определения входных параметров тестов.

27Тестирование (software testing) – деятельность, выполняемая для оценки и улучшения качества программного обеспечения. Эта деятельность, в общем случае, базируется на обнаружении дефектов и проблем в программных системах.

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

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

28Сопровождение поддерживает функционирование программного продукта на протяжении всего операционного жизненного цикла, то есть периода его эксплуатации. В процессе сопровождения фиксируются и отслеживаются запросы на модификацию (также называемые “запросами на изменения” – change requests, в частности, в контексте конфигурационного управления), оценивается влияние предлагаемых изменений, модифицируется код и другие активы (артефакты) продукта, проводится необходимое тестирование и, наконец, выпускается обновленная версия продукта. Кроме того, проводится обучение пользователей и обеспечивается их ежедневная поддержка при работе с текущей версией продукта. В SWEBOK отмечается, что сопровождение, с точки зрения операций отслеживания и контроля, обладает большим содержанием, чем разработка (в общем понимании). Объем и активность операций по контролю разработки в большой степени зависит от сложившихся практик, внутрикорпоративных регламентов и требований, а также применяемых методологий и концепции управления (в частности – проектного менеджмента). Так или иначе, отслеживание и контроль – ключевые элементы деятельности по сопровождению программного обеспечения (как и других ИТ-активов предприятия).

• 29 Понимание программных систем (Program Comprehension)

• 4.2 Реинжиниринг* (Reengineering)

• 4.3 Обратный инжиниринг* (Reverse engineering)

• 4.1.1 Формирование представления об эксплуатируемой/сопровождаемой системе: включает восстановление, в первую очередь, бизнес- и функциональных требований к системе;

• 4.1.2 Восстановление детального дизайна системы: включает идентификацию всех компонентов системы и создание модели вызовов и других связей между компонентами;

• 4.1.3 Рефакторинг: как возможный процесс структурных изменений, вносимых в систему, в частности для улучшения возможностей по ее дальнейшему сопровождению (включая модификацию, связанную с расширением функциональности);

• 4.1.4 Переработка системы: создание нового релиза/версии системы в той же форме (например, с использованием той же технологической платформы), что и текущая (эксплуатируемая) версия;

• 4.1.5 Создание новой системы: рассматривает текущую версию и систему в целом, как устаревшую – legacy.

• 30Данная глава (область знаний) рассматривает вопросы качества программного обеспечения, выходя за рамки <отдельных> процессов жизненного цикла. Качество программного обеспечения является постоянным объектом заботы программной инженерии и обсуждается во многих областях знаний (что вполне обосновано, если учесть поистине катастрофический уровень проваленных проектов и неудовлетворенность пользователей программных продуктов, ставшая притчей во языцех для программной индустрии). В общем случае, SWEBOK описывает ряд путей достижения качества программного обеспечения. В частности, эта область знаний касается статических техник, не требующих выполнения оцениваемых программных систем, в отличие от динамических техник, рассмотренных в области знаний SWEBOK “Тестирование”.

30 Яким чином проблема якості пз відображена у swebok?

Якість ПЗ – набір властивостей продукту (сервісу або програм), що характеризують його здатність задовольнити встановлені або передбачувані потреби замовника. Поняття якості має різні інтерпретації залежно від конкретної програмної системи і вимог до неї. Крім того, у різних джерелах таксономія (класифікація) характеристик у моделі якості розрізняється.

31 В чому різниця між різними моделями життєвого циклу пз?

Каскадна модель життєвого циклу (модель водоспаду, англ. waterfall model) була запропонована у 1970 р. У. Ройсом. Принципова особливість каскадної моделі - перехід на наступну стадію здійснюється тільки після повного завершення роботи на поточній стадії, повернення на пройдені стадії не передбачається. Кожна стадія закінчується одержанням результатів, що є вхідними даними для наступної стадії, та випуском повного комплекту документації. Вимоги до ПЗ, визначені на стадії формування вимог, документуються у вигляді технічного завдання і фіксуються на весь час розроблення. Критерієм якості розробки за такої моделі є точність виконання специфікацій технічного завдання.

Спіральна модель (spiral model) була розроблена у середині 1980-х років Барі Боемом. Вона ґрунтується на класичному циклі Демінга PDCA (plan-do-check-act). При використанні цієї моделі ІС створюється в кілька ітерацій (витків спіралі) методом прототипування.

Суттєва особливість спіральної моделі ЖЦ ПЗ полягає в тому, що прикладне ПЗ створюється не відразу, а частково, з використанням методу прототипування.  На кожній ітерації виробляється ретельна оцінка ризику перевищення термінів і вартості проекту, щоб визначити необхідність виконання ще однієї ітерації, ступінь повноти і точності розуміння вимог до системи, а також доцільність припинення проекту. Спіральна модель позбавляє користувачів і розробників ПЗ від необхідності повного й точного формулювання вимог до системи на початковій стадії, оскільки вони уточнюються на кожній ітерації. У такий спосіб уточнюються і послідовно конкретизуються деталі проекту і зрештою вибирається обґрунтований варіант, який і реалізується.

Ітераційний процес розроблення відображає об'єктивно спіральний цикл створення системи. Неповне завершення робіт на кожній стадії дає змогу переходити на наступну стадію, не чекаючи повного завершення роботи на поточній. При ітеративному способі розроблення відсутню стадію можна буде виконати на наступній ітерації. Головне завдання - якнайшвидше показати користувачам системи працездатний продукт, активізуючи процес уточнення і доповнення вимог.