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в тощо.

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

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

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

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

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

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

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

26 Уровни тестирования

2.1.1 Модульное тестирование (Unit testing)

Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы. Что считать элементом – модулем системы определяется контекстом. Наиболее полно данный вид тестов описан в стандарте IEEE 1008-87 “Standard for Software Unit Testing”, задающем интегрированную концепцию систематического и документированного подхода к модульному тестированию.

2.1.2 Интеграционное тестирование (Integration testing)

Данный уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями.

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

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

Интеграционное тестирование – постоянно проводимая деятельность, предполагающая работу на достаточно высоком уровне абстракции. Наиболее успешная практика интеграционного тестирования базируется на инкрементальном подходе, позволяющем избежать проблем проведения разовых тестов, связанных с тестированием результатов очередного длительного этапа работ, когда количество выявленных дефектов приводит к серьезной переработке кода (традиционно, негативный опыт выпуска и тестирования только крупных релизов называют “big bang”).

2.1.3 Системное тестирование (System testing)

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

На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному обеспечению, операционной среде и т.д.

3. Техники тестирования (Test Techniques)

3.1 Техники, базирующиеся на интуиции и опыте инженера (Based on the software engineer’s intuition and experience)

3.1.1 Специализированное тестирование (Ad hoc testing)

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

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

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

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

В данном определении тестирования выделены слова, определяющие основные вопросы, которым адресуется данная область знаний:

Динамичность (dynamic): этот термин подразумевает тестирование всегда предполагает выполнение тестируемой программы с заданными входными данными. При этом, величины, задаваемые на вход тестируемому программному обеспечению, не всегда достаточны для определения теста. Сложность и недетерминированность систем приводит к тому, что система может по разному реагировать на одни и те же входные параметры, в зависимости от состояния системы. В данной области знаний термин “вход” (input) будет использоваться в рамках соглашения о том, что вход может также специфицировать состояние системы, в тех случаях, когда это необходимо. Кроме динамических техник проверки качества, то есть тестирования, существуют также и статические техники, рассматриваемые в области знаний “Software Quality”.

28 процес супроводу ПЗ

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

29 прийоми супроводу ПЗ

Техники сопровождения (Techniques for Maintenance)

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

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

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

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

Реинжиниринг определяется как детальная оценка (examination) и перестройка программного обеспечения для формирования понимания, воссоздания (на уровне модели и, в ряде случаев, требований) и дальнейшей реализации его <функций> в новой форме (например, с использованием новых технологий и платформ, при сохранении существующей и расширением и облегчением возможностей добавлений новой функциональности). Отмечается, что в индустрии существуют различные позиции в отношении реинжиниринга – одни считают, что реинжиниринг является наиболее радикальной и затратной формой изменений программных систем, другие, что такой подход может применяться и для не столь кардинальных изменений (например, как смена платформы или архитектуры). Реинжиниринг, обычно, провидится не столько для улучшения возможностей сопровождения (maintainability), сколько для замены устаревшего программного обеспечения. В принципе, реинжиниринг можно рассматривать как самостоятельный проект, включающий в себя, как отмечает SWEBOK, формирование концепции, применение соответствующих инструментов и техник, анализ и приложения опыта проведения реинжиниринга, а также оценку рисков и преимуществ, связанных с такими работами.

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

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

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

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

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

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

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

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

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

Основні процеси життєвого циклу - Primary Processes

1.1. Замовлення - Acqusition

1.2. Постачання - Supply

1.3. Розробка - Development

1.4. Експлуатація - Operation

1.5. Супровід – Maintenance

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

Модель ЖЦ ПЗ - це структура, що визначає послідовність виконання і взаємозв'язок процесів, дій, задач протягом ЖЦ.

Модель ЖЦ конкретного ПЗ інформаційної системи визначає характер процесу створення цього ПЗ, що означає сукупність упорядкованих у часі, об'єднаних у стадії робіт.

Життє́вий цикл програ́много забезпе́чення — сукупність окремих етапів робіт, що проводяться у заданому порядку протягом періоду часу, який починається з вирішення питання про розроблення програмного забезпечення і закінчується припиненням використання програмного забезпечення..

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

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

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

• каскадна модель;

• спіральна модель.