Wiki Welard - Внесок користувача [uk]

W10 SATA

2023-02-16T15:35:32Z

Omind:

Прежде всего проверьте наличие доступных обновлений BIOS от производителя компьютера и установите их, если есть. Если обновлений нет, выполните следующие шаги, чтобы переопределить метод, с помощью которого встроенный драйвер обнаруживает устройства на определенных портах. 

Откройте командную строку с полномочиями администратора. 

В окне командной строки введите следующую команду и нажмите клавишу ВВОД: devmgmt.msc 

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

Запомните номер шины в обзоре свойств (в примере ниже это 1). 

* Windows 7
reg.exe add HKLM\SYSTEM\CurrentControlSet\Services\msahci\Controller0\Channelx\ /f /v TreatAsInternalPort /t REG_DWORD /d 0x00000001

* Windows 8 - 10
reg.exe add HKLM\SYSTEM\CurrentControlSet\Services\storahci\Parameters\Device /f /v TreatAsInternalPort /t REG_MULTI_SZ /d x
Где x — номер шины 

В Windows 10 и 8.1 вместо MSAHCI используется драйвер StorAHCI, поэтому местоположение параметра реестра TreatAsInternalPort другое. Перейдите в ветку реестра 

HKLM\SYSTEM\CurrentControlSet\Services\storahci\Parameters\Device 

создайте мультистроковый (REG_MULTI_SZ) параметр TreatAsInternalPort, в каждой строке которого нужно указать номер порта SATA контроллера, который нужно пометить “внутренним”. Например, чтобы пометить внутренними все диски с 0 до 3, в качестве значения TreatAsInternalPort нужно указать:
0 
1 
2 
3 
0-3 - Bus Number диска (свойства диска - общие - размещение)

W10 SATA

2023-02-16T15:34:52Z

Omind:

Прежде всего проверьте наличие доступных обновлений BIOS от производителя компьютера и установите их, если есть. Если обновлений нет, выполните следующие шаги, чтобы переопределить метод, с помощью которого встроенный драйвер обнаруживает устройства на определенных портах. 

Откройте командную строку с полномочиями администратора. 

В окне командной строки введите следующую команду и нажмите клавишу ВВОД: devmgmt.msc 

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

Запомните номер шины в обзоре свойств (в примере ниже это 1). 

# Windows 7
reg.exe add HKLM\SYSTEM\CurrentControlSet\Services\msahci\Controller0\Channelx\ /f /v TreatAsInternalPort /t REG_DWORD /d 0x00000001

# Windows 8 - 10
reg.exe add HKLM\SYSTEM\CurrentControlSet\Services\storahci\Parameters\Device /f /v TreatAsInternalPort /t REG_MULTI_SZ /d x
Где x — номер шины 

В Windows 10 и 8.1 вместо MSAHCI используется драйвер StorAHCI, поэтому местоположение параметра реестра TreatAsInternalPort другое. Перейдите в ветку реестра 

HKLM\SYSTEM\CurrentControlSet\Services\storahci\Parameters\Device 

создайте мультистроковый (REG_MULTI_SZ) параметр TreatAsInternalPort, в каждой строке которого нужно указать номер порта SATA контроллера, который нужно пометить “внутренним”. Например, чтобы пометить внутренними все диски с 0 до 3, в качестве значения TreatAsInternalPort нужно указать:
0 
1 
2 
3 
0-3 - Bus Number диска (свойства диска - общие - размещение)

W10 SATA

2023-02-16T15:32:46Z

Omind: Створена сторінка: Прежде всего проверьте наличие доступных обновлений BIOS от производителя компьютера и...

Прежде всего проверьте наличие доступных обновлений BIOS от производителя компьютера и установите их, если есть. Если обновлений нет, выполните следующие шаги, чтобы переопределить метод, с помощью которого встроенный драйвер обнаруживает устройства на определенных портах.

Откройте командную строку с полномочиями администратора.

В окне командной строки введите следующую команду и нажмите клавишу ВВОД: devmgmt.msc

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

Запомните номер шины в обзоре свойств (в примере ниже это 1).
Windows 7
reg.exe add HKLM\SYSTEM\CurrentControlSet\Services\msahci\Controller0\Channelx\ /f /v TreatAsInternalPort /t REG_DWORD /d 0x00000001

Windows 8 - 10
reg.exe add HKLM\SYSTEM\CurrentControlSet\Services\storahci\Parameters\Device /f /v TreatAsInternalPort /t REG_MULTI_SZ /d x
Где x — номер шины

В Windows 10 и 8.1 вместо MSAHCI используется драйвер StorAHCI, поэтому местоположение параметра реестра TreatAsInternalPort другое. Перейдите в ветку реестра
HKLM\SYSTEM\CurrentControlSet\Services\storahci\Parameters\Device
создайте мультистроковый (REG_MULTI_SZ) параметр TreatAsInternalPort, в каждой строке которого нужно указать номер порта SATA контроллера, который нужно пометить “внутренним”. Например, чтобы пометить внутренними все диски с 0 до 3, в качестве значения TreatAsInternalPort нужно указать:
0
1
2
3
0-3 - Bus Number диска (свойства диска - общие - размещение)

Windows10

2023-02-16T15:26:24Z

Omind:

[[W10_Activation]] Активация windows

[[W10_updates]] windows updates problem

[[W10_program]] program installation

[[W10_SATA]] SATA диски як флешки

Windows

2023-02-16T15:25:27Z

Omind:

* [[Windows boot]]
* [[Keyboard|Keyboard]]
* [[Fixboot]]
* [[Thunderbird]]
* [[Terminal Server]]
* [[VirtualBox Network Fix]]
* [[Unformat_ntfs]]
* [[Windows-console-command]]
* [[MMC]] MMC could not create the snap-in
* [[Windows Scheduler console ]] schtasks
* [[Windows10]] (Активация, тюнинг, SATA)
* [[Windows_Netowork]] (Make connection Private)
* [[Windows_God mode]] Windows God mode
* [[Windows_Server]] Windows Server tips
* [[windows l2tp tunel ]]

Windows Server

2022-12-27T11:18:42Z

Omind:

HKEY_CURRENT_USER\Control Panel\Desktop\LogPixels
=> if LogPixels does not exist then create a new DWORD-value
=> Type in Decimal Value:
96 for Smaller 100%
120 for Medium 125%
144 for Larger 150%
Then Goto „HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\IgnoreClientDesktopScaleFactor“
=> if IgnoreClientDesktopScaleFactor does not exist then create a new DWORD-value
=> Type in Decimal Value:
Turn on 1
(Turn off 0)

Проверил на W2019 server, работает

[https://forum.ixbt.com/topic.cgi?id=7:43359 нашел тут]

Windows Server

2022-12-27T11:18:20Z

Omind:

HKEY_CURRENT_USER\Control Panel\Desktop\LogPixels
=> if LogPixels does not exist then create a new DWORD-value
=> Type in Decimal Value:
96 for Smaller 100%
120 for Medium 125%
144 for Larger 150%
Then Goto „HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\IgnoreClientDesktopScaleFactor“
=> if IgnoreClientDesktopScaleFactor does not exist then create a new DWORD-value
=> Type in Decimal Value:
Turn on 1
(Turn off 0)

Проверил на W2019 server, работает
[https://forum.ixbt.com/topic.cgi?id=7:43359 нашел тут]

Esence-software-development

2022-09-09T14:25:31Z

Omind:

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

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

На початковому етапі розвитку обчислювальної техніки ПЗ розроблялися за принципом «кодування - усунення помилок»

На сучасности етапі широко використовуються три базові методології розробки ПО:
* каскадна;
* інкрементна;
* еволюційна.

Існують тісні взаємозв'язки між моделлю ЖЦ, обраної при реалізації процесу розробки ПС, використовуваними методологіями і технологіями розробки ПС і рівнем якості розробленого програмного продукту. 
'''Каскадна методологія''' являє собою одноразовий прохід всіх етапів розробки. Дана методологія базується на повному визначенні всіх вимог до програмного засобу або системи на початку процесу розробки. Кожен етап розробки починається лише після завершення попереднього етапу. Повернення до вже виконаних етапів не передбачається. проміжні продукти розробки в якості версії програмного засобу не розглядаються.
Використання даної методології найбільш ефективно в наступних випадках:
# при розробці проектів з чіткими, незмінними протягом ЖЦ вимогами і зрозумілою реалізацією;
# при розробці проектів невисокої складності;.
# при виконанні великих проектів в якості складової частини моделей ЖЦ, що реалізують інші методології розробки. 
[[Файл:Kaskad.jpg|міні]]
 
'''Інкрементна методологія''' являє собою багаторазовий прохід етапів розробки із запланованим поліпшенням результату.
Дана методологія базується на повному визначенні всіх вимог до програмного засобу (системи) на початку процесу розробки. Однак повний набір вимог реалізується поступово відповідно до плану в послідовних циклах розробки. 
Результат кожного циклу називається інкрементом. 
Перший інкремент реалізує базові функції програмного засобу. В подальших інкрементах функції програмного засобу поступово розширюються, поки не буде реалізований весь набір вимог. Відмінності між інкрементами сусідніх циклів в ході розробки поступово зменшуються. Результат кожного циклу розробки може поширюватися як чергова версія поставки програмного засобу або системи. 
Використання даної стратегії найбільш ефективно в наступних випадках:
# при розробці проектів, в яких більшість вимог можна сформулювати заздалегідь, але частина з них можуть бути уточнені через визначений період часу;
# при розробці складних проектів з заздалегідь сформульованими вимогами; для них розробка системи або програмного засобу за один цикл пов'язана з великими труднощами;
# при необхідності швидко поставити на ринок продукт, що має базові функціональні властивості;
# при розробці проектів з низькою або середнім ступенем ризиків;
# при виконанні проекту з застосуванням нових технологій.
 
[[Файл:Iteracia.jpg|міні]]
 
'''Еволюційна методологія''' являє собою багаторазовий прохід етапів розробки. Дана методологія базується на частковому визначенні вимог щодо розроблюваного програмного засобу або системи на початку процесу розробки. Вимоги поступово уточнюються в послідовних циклах розробки. Результат кожного циклу розробки зазвичай являє собою чергову версію програмного засобу або системи. 
Слід зазначити, що в загальному випадку для еволюційної методології характерним є істотно менша кількість циклів розробки при більшій тривалості циклу в порівнянні з інкрементною методологією. При цьому результат кожного циклу розробки (чергова версія програмного засобу значно відрізняється від результату попереднього циклу. 
Використання даної методології найбільш ефективно в наступних випадках:
# при розробці проектів, для яких вимоги занадто складні, невідомі заздалегідь, непостійні або вимагають уточнення;
# при розробці складних проектів, в тому числі:
* великих довгострокових проектів;
* проектів зі створення нових, які не мають аналогів ПЗ або систем;
* проектів зі середнім і високим ступенем ризиків;
* проектів, для яких потрібна перевірка концепції, демонстрація технічної здійсненності або проміжних продуктів;
# при розробці проектів, що використовують нові технології. 
[[Файл:Spiral1.jpg|міні]]

[https://ppt-online.org/659746 Методології створення ПЗ]

'''Каскадна модель (waterflow model)'''
[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf] 26 ст.
Водоспадна модель (каскадна схема) запропонована в 1970 році Вінстоном Ройсом. і використовувалася в розробці програмного забезпечення (рис. 2.2), яке передбачало, що перехід на наступну стадію здійснюється після того, як повністю будуть завершені проектні операції попередньої стадії і отримані всі вихідні дані для наступної стадії.
Коротка характеристика каскадної схеми розробки програмного
забезпечення:
* фіксований набір стадій;
* кожна стадія закінчується документованим результатом;
* наступна стадія починається тільки після закінчення попередньої.
Недоліки:
* негнучкість;
* фаза повинна бути завершена до переходу до наступної;
* набір фаз фіксований;
* важко реагувати на зміни вимог.
 
'''Ітеративна модель (Iterative and incremental development) – модель з проміжним контролем'''
[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf] 30 ст.
Каскадна модель життєвого циклу не є ідеальною, оскільки лише дуже прості завдання проходять всі етапи без будь-яких ітерацій (повернень на попередні кроки процесу).
Наприклад, при програмуванні може виявитися, що реалізація деякої функції неефективна і вступає в протиріччя з вимогами до продуктивності системи. У цьому випадку потрібні зміни проекту, а можливо, і переробка специфікацій. 

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

Класична ітераційна модель абсолютизує можливість повернень на попередні етапи. Ця обставина відображає істотний аспект програмних розробок: прагнення заздалегідь передбачити всі ситуації використання системи і неможливість в більшості випадків досягти цього. Всі традиційні технології програмування спрямовані лише на те, щоб мінімізувати повернення. Але суть від цього не змінюється: при поверненні завжди доводиться повторювати побудову того, що вже вважалося готовим.
Схема, що підтримує ітераційний характер процесу розробки, була названа схемою з проміжним контролем. Контроль, який виконується за даною схемою після завершення кожного етапу, дозволяє при необхідності повернутися на будь-який рівень і внести необхідні зміни. Основна небезпека використання такої схеми пов'язана з тим, що розробка ніколи не буде завершена, постійно перебуваючи в стані уточнення та вдосконалення. 

Мета кожної ітерації в розробці ПЗ – отримання працюючої версії програмної системи, що включає функціональність, визначену інтегрованим змістом усіх попередніх і поточної ітерацій. Результат фінальної ітерації
містить всю необхідну функціональність продукту. Таким чином, із завершенням кожної ітерації продукт розвивається інкрементно (нарощує функціональність).
З точки зору структури життєвого циклу і процесу розробки така модель є ітеративною (iterative), а з точки зору розвитку продукту – інкрементною (incremental). Досвід індустрії розробки ПЗ показує, що неможливо розглядати кожен з цих поглядів ізольовано. Тому цю модель часто називають моделлю ітеративної і інкрементної розробки (Iterative and incremental development, IID).
 
'''Спіральна модель'''
[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf] 31 ст.
Для подолання перелічених проблем в середині 80-х років XX ст. була запропонована спіральна схема (рис. 2.4). Відповідно до даної схеми програмне забезпечення створюється не відразу, а ітераційно з використанням методу прототипування, що базується на створенні прототипів. Саме поява прототипування призвело до того, що процес
модифікації програмного забезпечення перестав сприйматися, як «необхідне зло», а став сприйматися як окремий важливий процес.
Прототипом називають діючий програмний продукт, який реалізує окремі функції і зовнішні інтерфейси розроблюваного програмного забезпечення.
На першій ітерації, як правило, специфікують, проектують, реалізують і тестують інтерфейс користувача. На другий - додають деякий обмежений набір функцій.
На наступних етапах цей набір розширюють, нарощуючи можливості даного продукту. 
Основною перевагою даної схеми є те, що, починаючи з деякої ітерації, на якій забезпечена певна функціональна повнота, продукт можна надавати користувачеві, що дозволяє:
* скоротити час до появи перших версій програмного продукту;
* зацікавити велику кількість користувачів, що забезпечує швидке просування наступних версій продукту на ринку;
* прискорити формування та уточнення специфікацій за рахунок появи практики використання продукту;
* зменшити ймовірність морального старіння системи за час розробки.
 

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

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

Файл:Spiral1.jpg

2022-09-09T14:25:05Z

Omind:

Spiral1

Esence-software-development

2022-09-09T14:23:44Z

Omind:

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

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

На початковому етапі розвитку обчислювальної техніки ПЗ розроблялися за принципом «кодування - усунення помилок»

На сучасности етапі широко використовуються три базові методології розробки ПО:
* каскадна;
* інкрементна;
* еволюційна.

Існують тісні взаємозв'язки між моделлю ЖЦ, обраної при реалізації процесу розробки ПС, використовуваними методологіями і технологіями розробки ПС і рівнем якості розробленого програмного продукту. 
'''Каскадна методологія''' являє собою одноразовий прохід всіх етапів розробки. Дана методологія базується на повному визначенні всіх вимог до програмного засобу або системи на початку процесу розробки. Кожен етап розробки починається лише після завершення попереднього етапу. Повернення до вже виконаних етапів не передбачається. проміжні продукти розробки в якості версії програмного засобу не розглядаються.
Використання даної методології найбільш ефективно в наступних випадках:
# при розробці проектів з чіткими, незмінними протягом ЖЦ вимогами і зрозумілою реалізацією;
# при розробці проектів невисокої складності;.
# при виконанні великих проектів в якості складової частини моделей ЖЦ, що реалізують інші методології розробки. 
[[Файл:Kaskad.jpg|міні]]
 
'''Інкрементна методологія''' являє собою багаторазовий прохід етапів розробки із запланованим поліпшенням результату.
Дана методологія базується на повному визначенні всіх вимог до програмного засобу (системи) на початку процесу розробки. Однак повний набір вимог реалізується поступово відповідно до плану в послідовних циклах розробки. 
Результат кожного циклу називається інкрементом. 
Перший інкремент реалізує базові функції програмного засобу. В подальших інкрементах функції програмного засобу поступово розширюються, поки не буде реалізований весь набір вимог. Відмінності між інкрементами сусідніх циклів в ході розробки поступово зменшуються. Результат кожного циклу розробки може поширюватися як чергова версія поставки програмного засобу або системи. 
Використання даної стратегії найбільш ефективно в наступних випадках:
# при розробці проектів, в яких більшість вимог можна сформулювати заздалегідь, але частина з них можуть бути уточнені через визначений період часу;
# при розробці складних проектів з заздалегідь сформульованими вимогами; для них розробка системи або програмного засобу за один цикл пов'язана з великими труднощами;
# при необхідності швидко поставити на ринок продукт, що має базові функціональні властивості;
# при розробці проектів з низькою або середнім ступенем ризиків;
# при виконанні проекту з застосуванням нових технологій.
 
[[Файл:Iteracia.jpg|міні]]
 
'''Еволюційна методологія''' являє собою багаторазовий прохід етапів розробки. Дана методологія базується на частковому визначенні вимог щодо розроблюваного програмного засобу або системи на початку процесу розробки. Вимоги поступово уточнюються в послідовних циклах розробки. Результат кожного циклу розробки зазвичай являє собою чергову версію програмного засобу або системи. 
Слід зазначити, що в загальному випадку для еволюційної методології характерним є істотно менша кількість циклів розробки при більшій тривалості циклу в порівнянні з інкрементною методологією. При цьому результат кожного циклу розробки (чергова версія програмного засобу значно відрізняється від результату попереднього циклу. 
Використання даної методології найбільш ефективно в наступних випадках:
# при розробці проектів, для яких вимоги занадто складні, невідомі заздалегідь, непостійні або вимагають уточнення;
# при розробці складних проектів, в тому числі:
* великих довгострокових проектів;
* проектів зі створення нових, які не мають аналогів ПЗ або систем;
* проектів зі середнім і високим ступенем ризиків;
* проектів, для яких потрібна перевірка концепції, демонстрація технічної здійсненності або проміжних продуктів;
# при розробці проектів, що використовують нові технології. 

[https://ppt-online.org/659746 Методології створення ПЗ]

'''Каскадна модель (waterflow model)'''
[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf] 26 ст.
Водоспадна модель (каскадна схема) запропонована в 1970 році Вінстоном Ройсом. і використовувалася в розробці програмного забезпечення (рис. 2.2), яке передбачало, що перехід на наступну стадію здійснюється після того, як повністю будуть завершені проектні операції попередньої стадії і отримані всі вихідні дані для наступної стадії.
Коротка характеристика каскадної схеми розробки програмного
забезпечення:
* фіксований набір стадій;
* кожна стадія закінчується документованим результатом;
* наступна стадія починається тільки після закінчення попередньої.
Недоліки:
* негнучкість;
* фаза повинна бути завершена до переходу до наступної;
* набір фаз фіксований;
* важко реагувати на зміни вимог.
 
'''Ітеративна модель (Iterative and incremental development) – модель з проміжним контролем'''
[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf] 30 ст.
Каскадна модель життєвого циклу не є ідеальною, оскільки лише дуже прості завдання проходять всі етапи без будь-яких ітерацій (повернень на попередні кроки процесу).
Наприклад, при програмуванні може виявитися, що реалізація деякої функції неефективна і вступає в протиріччя з вимогами до продуктивності системи. У цьому випадку потрібні зміни проекту, а можливо, і переробка специфікацій. 

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

Класична ітераційна модель абсолютизує можливість повернень на попередні етапи. Ця обставина відображає істотний аспект програмних розробок: прагнення заздалегідь передбачити всі ситуації використання системи і неможливість в більшості випадків досягти цього. Всі традиційні технології програмування спрямовані лише на те, щоб мінімізувати повернення. Але суть від цього не змінюється: при поверненні завжди доводиться повторювати побудову того, що вже вважалося готовим.
Схема, що підтримує ітераційний характер процесу розробки, була названа схемою з проміжним контролем. Контроль, який виконується за даною схемою після завершення кожного етапу, дозволяє при необхідності повернутися на будь-який рівень і внести необхідні зміни. Основна небезпека використання такої схеми пов'язана з тим, що розробка ніколи не буде завершена, постійно перебуваючи в стані уточнення та вдосконалення. 

Мета кожної ітерації в розробці ПЗ – отримання працюючої версії програмної системи, що включає функціональність, визначену інтегрованим змістом усіх попередніх і поточної ітерацій. Результат фінальної ітерації
містить всю необхідну функціональність продукту. Таким чином, із завершенням кожної ітерації продукт розвивається інкрементно (нарощує функціональність).
З точки зору структури життєвого циклу і процесу розробки така модель є ітеративною (iterative), а з точки зору розвитку продукту – інкрементною (incremental). Досвід індустрії розробки ПЗ показує, що неможливо розглядати кожен з цих поглядів ізольовано. Тому цю модель часто називають моделлю ітеративної і інкрементної розробки (Iterative and incremental development, IID).
 
'''Спіральна модель'''
[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf] 31 ст.
Для подолання перелічених проблем в середині 80-х років XX ст. була запропонована спіральна схема (рис. 2.4). Відповідно до даної схеми програмне забезпечення створюється не відразу, а ітераційно з використанням методу прототипування, що базується на створенні прототипів. Саме поява прототипування призвело до того, що процес
модифікації програмного забезпечення перестав сприйматися, як «необхідне зло», а став сприйматися як окремий важливий процес.
Прототипом називають діючий програмний продукт, який реалізує окремі функції і зовнішні інтерфейси розроблюваного програмного забезпечення.
На першій ітерації, як правило, специфікують, проектують, реалізують і тестують інтерфейс користувача. На другий - додають деякий обмежений набір функцій.
На наступних етапах цей набір розширюють, нарощуючи можливості даного продукту. 
Основною перевагою даної схеми є те, що, починаючи з деякої ітерації, на якій забезпечена певна функціональна повнота, продукт можна надавати користувачеві, що дозволяє:
* скоротити час до появи перших версій програмного продукту;
* зацікавити велику кількість користувачів, що забезпечує швидке просування наступних версій продукту на ринку;
* прискорити формування та уточнення специфікацій за рахунок появи практики використання продукту;
* зменшити ймовірність морального старіння системи за час розробки.
 

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

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

Esence-software-development

2022-09-09T14:23:19Z

Omind:

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

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

На початковому етапі розвитку обчислювальної техніки ПЗ розроблялися за принципом «кодування - усунення помилок»

На сучасности етапі широко використовуються три базові методології розробки ПО:
* каскадна;
* інкрементна;
* еволюційна.

Існують тісні взаємозв'язки між моделлю ЖЦ, обраної при реалізації процесу розробки ПС, використовуваними методологіями і технологіями розробки ПС і рівнем якості розробленого програмного продукту. 
'''Каскадна методологія''' являє собою одноразовий прохід всіх етапів розробки. Дана методологія базується на повному визначенні всіх вимог до програмного засобу або системи на початку процесу розробки. Кожен етап розробки починається лише після завершення попереднього етапу. Повернення до вже виконаних етапів не передбачається. проміжні продукти розробки в якості версії програмного засобу не розглядаються.
Використання даної методології найбільш ефективно в наступних випадках:
# при розробці проектів з чіткими, незмінними протягом ЖЦ вимогами і зрозумілою реалізацією;
# при розробці проектів невисокої складності;.
# при виконанні великих проектів в якості складової частини моделей ЖЦ, що реалізують інші методології розробки.
[[Файл:Kaskad.jpg|міні]]
 
'''Інкрементна методологія''' являє собою багаторазовий прохід етапів розробки із запланованим поліпшенням результату.
Дана методологія базується на повному визначенні всіх вимог до програмного засобу (системи) на початку процесу розробки. Однак повний набір вимог реалізується поступово відповідно до плану в послідовних циклах розробки. 
Результат кожного циклу називається інкрементом. 
Перший інкремент реалізує базові функції програмного засобу. В подальших інкрементах функції програмного засобу поступово розширюються, поки не буде реалізований весь набір вимог. Відмінності між інкрементами сусідніх циклів в ході розробки поступово зменшуються. Результат кожного циклу розробки може поширюватися як чергова версія поставки програмного засобу або системи. 
Використання даної стратегії найбільш ефективно в наступних випадках:
# при розробці проектів, в яких більшість вимог можна сформулювати заздалегідь, але частина з них можуть бути уточнені через визначений період часу;
# при розробці складних проектів з заздалегідь сформульованими вимогами; для них розробка системи або програмного засобу за один цикл пов'язана з великими труднощами;
# при необхідності швидко поставити на ринок продукт, що має базові функціональні властивості;
# при розробці проектів з низькою або середнім ступенем ризиків;
# при виконанні проекту з застосуванням нових технологій.
 
[[Файл:Iteracia.jpg|міні]]
'''Еволюційна методологія''' являє собою багаторазовий прохід етапів розробки. Дана методологія базується на частковому визначенні вимог щодо розроблюваного програмного засобу або системи на початку процесу розробки. Вимоги поступово уточнюються в послідовних циклах розробки. Результат кожного циклу розробки зазвичай являє собою чергову версію програмного засобу або системи. 
Слід зазначити, що в загальному випадку для еволюційної методології характерним є істотно менша кількість циклів розробки при більшій тривалості циклу в порівнянні з інкрементною методологією. При цьому результат кожного циклу розробки (чергова версія програмного засобу значно відрізняється від результату попереднього циклу. 
Використання даної методології найбільш ефективно в наступних випадках:
# при розробці проектів, для яких вимоги занадто складні, невідомі заздалегідь, непостійні або вимагають уточнення;
# при розробці складних проектів, в тому числі:
* великих довгострокових проектів;
* проектів зі створення нових, які не мають аналогів ПЗ або систем;
* проектів зі середнім і високим ступенем ризиків;
* проектів, для яких потрібна перевірка концепції, демонстрація технічної здійсненності або проміжних продуктів;
# при розробці проектів, що використовують нові технології. 

[https://ppt-online.org/659746 Методології створення ПЗ]

'''Каскадна модель (waterflow model)'''
[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf] 26 ст.
Водоспадна модель (каскадна схема) запропонована в 1970 році Вінстоном Ройсом. і використовувалася в розробці програмного забезпечення (рис. 2.2), яке передбачало, що перехід на наступну стадію здійснюється після того, як повністю будуть завершені проектні операції попередньої стадії і отримані всі вихідні дані для наступної стадії.
Коротка характеристика каскадної схеми розробки програмного
забезпечення:
* фіксований набір стадій;
* кожна стадія закінчується документованим результатом;
* наступна стадія починається тільки після закінчення попередньої.
Недоліки:
* негнучкість;
* фаза повинна бути завершена до переходу до наступної;
* набір фаз фіксований;
* важко реагувати на зміни вимог.
 
'''Ітеративна модель (Iterative and incremental development) – модель з проміжним контролем'''
[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf] 30 ст.
Каскадна модель життєвого циклу не є ідеальною, оскільки лише дуже прості завдання проходять всі етапи без будь-яких ітерацій (повернень на попередні кроки процесу).
Наприклад, при програмуванні може виявитися, що реалізація деякої функції неефективна і вступає в протиріччя з вимогами до продуктивності системи. У цьому випадку потрібні зміни проекту, а можливо, і переробка специфікацій. 

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

Класична ітераційна модель абсолютизує можливість повернень на попередні етапи. Ця обставина відображає істотний аспект програмних розробок: прагнення заздалегідь передбачити всі ситуації використання системи і неможливість в більшості випадків досягти цього. Всі традиційні технології програмування спрямовані лише на те, щоб мінімізувати повернення. Але суть від цього не змінюється: при поверненні завжди доводиться повторювати побудову того, що вже вважалося готовим.
Схема, що підтримує ітераційний характер процесу розробки, була названа схемою з проміжним контролем. Контроль, який виконується за даною схемою після завершення кожного етапу, дозволяє при необхідності повернутися на будь-який рівень і внести необхідні зміни. Основна небезпека використання такої схеми пов'язана з тим, що розробка ніколи не буде завершена, постійно перебуваючи в стані уточнення та вдосконалення. 

Мета кожної ітерації в розробці ПЗ – отримання працюючої версії програмної системи, що включає функціональність, визначену інтегрованим змістом усіх попередніх і поточної ітерацій. Результат фінальної ітерації
містить всю необхідну функціональність продукту. Таким чином, із завершенням кожної ітерації продукт розвивається інкрементно (нарощує функціональність).
З точки зору структури життєвого циклу і процесу розробки така модель є ітеративною (iterative), а з точки зору розвитку продукту – інкрементною (incremental). Досвід індустрії розробки ПЗ показує, що неможливо розглядати кожен з цих поглядів ізольовано. Тому цю модель часто називають моделлю ітеративної і інкрементної розробки (Iterative and incremental development, IID).
 
'''Спіральна модель'''
[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf] 31 ст.
Для подолання перелічених проблем в середині 80-х років XX ст. була запропонована спіральна схема (рис. 2.4). Відповідно до даної схеми програмне забезпечення створюється не відразу, а ітераційно з використанням методу прототипування, що базується на створенні прототипів. Саме поява прототипування призвело до того, що процес
модифікації програмного забезпечення перестав сприйматися, як «необхідне зло», а став сприйматися як окремий важливий процес.
Прототипом називають діючий програмний продукт, який реалізує окремі функції і зовнішні інтерфейси розроблюваного програмного забезпечення.
На першій ітерації, як правило, специфікують, проектують, реалізують і тестують інтерфейс користувача. На другий - додають деякий обмежений набір функцій.
На наступних етапах цей набір розширюють, нарощуючи можливості даного продукту. 
Основною перевагою даної схеми є те, що, починаючи з деякої ітерації, на якій забезпечена певна функціональна повнота, продукт можна надавати користувачеві, що дозволяє:
* скоротити час до появи перших версій програмного продукту;
* зацікавити велику кількість користувачів, що забезпечує швидке просування наступних версій продукту на ринку;
* прискорити формування та уточнення специфікацій за рахунок появи практики використання продукту;
* зменшити ймовірність морального старіння системи за час розробки.
 

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

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

Файл:Iteracia.jpg

2022-09-09T14:21:26Z

Omind:

Iteracia

Файл:Kaskad.jpg

2022-09-09T14:20:54Z

Omind:

Kaskad

Computer-human-interfaces

2022-09-09T10:19:58Z

Omind:

== Проектування та розробка людино-комп’ютерних інтерфейсів програмного забезпечення. ==
Комп'ютер – це машина, а не біологічна істота. Як будь-який технічний пристрій, комп'ютер обмінюється інформацією з людиною за допомогою набору певних правил, обов'язкових як для машини, так і для людини. Ці правила в комп'ютерній літературі називаються інтерфейсом. 

'''Командний інтерфейс.''' Командний інтерфейс називається так, бо в цьому виді інтерфейсу людина подає «команди» комп'ютеру, а комп'ютер їх виконує і видає результат. 

'''WIMP – інтерфейс (Window – вікно, Image – образ, Menu – меню, Pointer – покажчик).''' Характерною особливістю цього виду інтерфейсу є те, що взаємодія з користувачем ведеться не за допомогою команд, а за допомогою графічних образів – меню, вікон інших елементів. 

'''SILK – інтерфейс (Speech – мова, Image – образ, Language – мова, Knowlege – знання).''' Цей вид інтерфейсу найбільш наближений до звичайної, людської форми спілкування. У
рамках цього інтерфейсу йде звичайна «розмова» людини і комп'ютера. При цьому комп'ютер знаходить для себе команди, аналізуючи людську мову і знаходячи в ній ключові фрази.
[[Файл:111.jpg|міні|центр]]

Файл:111.jpg

2022-09-09T10:19:38Z

Omind:

Взаємодія

Computer-human-interfaces

2022-09-09T09:14:32Z

Omind: Створена сторінка: == Проектування та розробка людино-комп’ютерних інтерфейсів програмного забезпечення....

Software-development-analisys

2022-09-07T15:06:39Z

Omind:

== Технології розробки та аналізу вимог до програмного забезпечення. ==
 
[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf] Ст.12
Під '''технологією розробки програмного забезпечення (ТРПЗ)''' розуміється сукупність узагальнених і систематизованих знань, або наука про оптимальні способи (прийоми) проведення процесу розробки програмного забезпечення, що забезпечує в заданих умовах отримання програмної продукції із заданими властивостями. 
Це інженерний підхід до розробки програмних засобів ЕОМ, що охоплює методологію програмування, проблеми забезпечення надійності програм, оцінки робочих характеристик і якості проектів. 
Розглядає питання управління проектуванням систем програмного забезпечення, а також засоби і стандарти розробки програм. 
Охоплює процес розробки програмного забезпечення від появи потреби в ньому до його виготовлення, передачі користувачеві, модифікації в процесі експлуатації і припинення його використання внаслідок морального старіння. 
Вимоги:
# стандартизація мов проектування програм, оформлення та випробування модулів.
# контроль якості
# не містити неперевірений функціонал
# у замовника повинно бути чітке уявлення про можливості і умови експлуатації, при яких гарантується функціональність та якість ПЗ.
# людський фактор зведений до мінімуму
# документування усіх етапів розробки
# наявність інформаційно-довідкової системи
# бути простою в освоєнні та наявністю підказок
# містити автоматичні засоби хронологічної фіксації
 

'''Вимоги до ПЗ є такі''': системні, функціональні і нефункціональні вимоги. 
'''Системні вимоги (system requirements)''' визначають зовнішні умови виконання системних функцій і обмежень на створення продукту, а також вимоги до опису
програмно-апаратних підсистем. Системні вимоги накладають обмеження на архітектуру системи, засоби її візуального подання і функціонування. Для опису системних вимог використовують спеціальні шаблони і форми, що допомагають уявити вхідні і вихідні дані й автоматизувати ці вимоги. 
'''Функціональні вимоги''' – це перелік функцій або сервісів, які повинна надавати система, а також обмежень на дані і поводження системи при їхньому виконанні. 
'''Нефункціональні вимоги''' визначають умови виконання функцій (наприклад, захист інформації у БД, аутентифікація доступу до ПС тощо) у середовищі, що безпосередньо не пов'язані з функціями, а відбивають потреби користувачів щодо їх виконання. Ці вимоги характеризують принципи взаємодії із середовищами або іншими системами, а також визначають показники часу роботи, захисту даних і досягнення якості з урахуванням рекомендацій використовуваного стандарту. 

Вони можуть встановлюватися як числові значення (наприклад, час чекання відповіді, кількість клієнтів, що обслуговуються і ін.) у різних одиницях виміру, включаючи, наприклад, ймовірність (значення ймовірності безвідмовної роботи системи – показника її надійності). Для більшості сучасних ПС вимоги складаються з умов й обмежень типу:
* конфіденційність, безпека і захист даних;
* відмовостійкість;
* одночасність доступу користувачів до системи;
* час чекання відповіді при звертанні до системи (продуктивність);
* склад виконуваних функцій системи (запуск, швидкість реакції й ін.);
* положення стандартів з виконання сформульованих вимог.

Software-development-analisys

2022-09-07T14:52:26Z

Omind:

== Технології розробки та аналізу вимог до програмного забезпечення. ==
 
[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf] Ст.12
Під '''технологією розробки програмного забезпечення (ТРПЗ)''' розуміється сукупність узагальнених і систематизованих знань, або наука про оптимальні способи (прийоми) проведення процесу розробки програмного забезпечення, що забезпечує в заданих умовах отримання програмної продукції із заданими властивостями. 
Це інженерний підхід до розробки програмних засобів ЕОМ, що охоплює методологію програмування, проблеми забезпечення надійності програм, оцінки робочих характеристик і якості проектів. 
Розглядає питання управління проектуванням систем програмного забезпечення, а також засоби і стандарти розробки програм. 
Охоплює процес розробки програмного забезпечення від появи потреби в ньому до його виготовлення, передачі користувачеві, модифікації в процесі експлуатації і припинення його використання внаслідок морального старіння. 

'''Вимоги до ПЗ є такі''': системні, функціональні і нефункціональні вимоги. 
'''Системні вимоги (system requirements)''' визначають зовнішні умови виконання системних функцій і обмежень на створення продукту, а також вимоги до опису
програмно-апаратних підсистем. Системні вимоги накладають обмеження на архітектуру системи, засоби її візуального подання і функціонування. Для опису системних вимог використовують спеціальні шаблони і форми, що допомагають уявити вхідні і вихідні дані й автоматизувати ці вимоги. 
'''Функціональні вимоги''' – це перелік функцій або сервісів, які повинна надавати система, а також обмежень на дані і поводження системи при їхньому виконанні. 
'''Нефункціональні вимоги''' визначають умови виконання функцій (наприклад, захист інформації у БД, аутентифікація доступу до ПС тощо) у середовищі, що безпосередньо не пов'язані з функціями, а відбивають потреби користувачів щодо їх виконання. Ці вимоги характеризують принципи взаємодії із середовищами або іншими системами, а також визначають показники часу роботи, захисту даних і досягнення якості з урахуванням рекомендацій використовуваного стандарту. 

Вони можуть встановлюватися як числові значення (наприклад, час чекання відповіді, кількість клієнтів, що обслуговуються і ін.) у різних одиницях виміру, включаючи, наприклад, ймовірність (значення ймовірності безвідмовної роботи системи – показника її надійності). Для більшості сучасних ПС вимоги складаються з умов й обмежень типу:
* конфіденційність, безпека і захист даних;
* відмовостійкість;
* одночасність доступу користувачів до системи;
* час чекання відповіді при звертанні до системи (продуктивність);
* склад виконуваних функцій системи (запуск, швидкість реакції й ін.);
* положення стандартів з виконання сформульованих вимог.

Software-development-analisys

2022-09-07T14:39:27Z

Omind: Створена сторінка: == Технології розробки та аналізу вимог до програмного забезпечення. == '''Вимоги до ПЗ...

== Технології розробки та аналізу вимог до програмного забезпечення. ==
 
'''Вимоги до ПЗ є такі''': системні, функціональні і нефункціональні вимоги. 
'''Системні вимоги (system requirements)''' визначають зовнішні умови виконання системних функцій і обмежень на створення продукту, а також вимоги до опису
програмно-апаратних підсистем. Системні вимоги накладають обмеження на архітектуру системи, засоби її візуального подання і функціонування. Для опису системних вимог використовують спеціальні шаблони і форми, що допомагають уявити вхідні і вихідні дані й автоматизувати ці вимоги. 
'''Функціональні вимоги''' – це перелік функцій або сервісів, які повинна надавати система, а також обмежень на дані і поводження системи при їхньому виконанні. 
'''Нефункціональні вимоги''' визначають умови виконання функцій (наприклад, захист інформації у БД, аутентифікація доступу до ПС тощо) у середовищі, що безпосередньо не пов'язані з функціями, а відбивають потреби користувачів щодо їх виконання. Ці вимоги характеризують принципи взаємодії із середовищами або іншими системами, а також визначають показники часу роботи, захисту даних і досягнення якості з урахуванням рекомендацій використовуваного стандарту. 

Вони можуть встановлюватися як числові значення (наприклад, час чекання відповіді, кількість клієнтів, що обслуговуються і ін.) у різних одиницях виміру, включаючи, наприклад, ймовірність (значення ймовірності безвідмовної роботи системи – показника її надійності). Для більшості сучасних ПС вимоги складаються з умов й обмежень типу:
* конфіденційність, безпека і захист даних;
* відмовостійкість;
* одночасність доступу користувачів до системи;
* час чекання відповіді при звертанні до системи (продуктивність);
* склад виконуваних функцій системи (запуск, швидкість реакції й ін.);
* положення стандартів з виконання сформульованих вимог.

Esence-software-development

2022-09-07T13:53:22Z

Omind: Omind перейменував сторінку з Обговорення:Esence-software-development на Esence-software-development

== Представлення та сутність моделей життєвого циклу розробки програмного забезпечення. ==
На початковому етапі розвитку обчислювальної техніки ПЗ розроблялися за принципом «кодування - усунення помилок»

На сучасности етапі широко використовуються три базові методології розробки ПО:
* каскадна;
* інкрементна;
* еволюційна.

Існують тісні взаємозв'язки між моделлю ЖЦ, обраної при реалізації процесу розробки ПС, використовуваними методологіями і технологіями розробки ПС і рівнем якості розробленого програмного продукту. 
'''Каскадна методологія''' являє собою одноразовий прохід всіх етапів розробки. Дана методологія базується на повному визначенні всіх вимог до програмного засобу або системи на початку процесу розробки. Кожен етап розробки починається лише після завершення попереднього етапу. Повернення до вже виконаних етапів не передбачається. проміжні продукти розробки в якості версії програмного засобу не розглядаються.
Використання даної методології найбільш ефективно в наступних випадках:
# при розробці проектів з чіткими, незмінними протягом ЖЦ вимогами і зрозумілою реалізацією;
# при розробці проектів невисокої складності;.
# при виконанні великих проектів в якості складової частини моделей ЖЦ, що реалізують інші методології розробки.
 
'''Інкрементна методологія''' являє собою багаторазовий прохід етапів розробки із запланованим поліпшенням результату.
Дана методологія базується на повному визначенні всіх вимог до програмного засобу (системи) на початку процесу розробки. Однак повний набір вимог реалізується поступово відповідно до плану в послідовних циклах розробки. 
Результат кожного циклу називається інкрементом. 
Перший інкремент реалізує базові функції програмного засобу. В подальших інкрементах функції програмного засобу поступово розширюються, поки не буде реалізований весь набір вимог. Відмінності між інкрементами сусідніх циклів в ході розробки поступово зменшуються. Результат кожного циклу розробки може поширюватися як чергова версія поставки програмного засобу або системи. 
Використання даної стратегії найбільш ефективно в наступних випадках:
# при розробці проектів, в яких більшість вимог можна сформулювати заздалегідь, але частина з них можуть бути уточнені через визначений період часу;
# при розробці складних проектів з заздалегідь сформульованими вимогами; для них розробка системи або програмного засобу за один цикл пов'язана з великими труднощами;
# при необхідності швидко поставити на ринок продукт, що має базові функціональні властивості;
# при розробці проектів з низькою або середнім ступенем ризиків;
# при виконанні проекту з застосуванням нових технологій.
 
'''Еволюційна методологія''' являє собою багаторазовий прохід етапів розробки. Дана методологія базується на частковому визначенні вимог щодо розроблюваного програмного засобу або системи на початку процесу розробки. Вимоги поступово уточнюються в послідовних циклах розробки. Результат кожного циклу розробки зазвичай являє собою чергову версію програмного засобу або системи. 
Слід зазначити, що в загальному випадку для еволюційної методології характерним є істотно менша кількість циклів розробки при більшій тривалості циклу в порівнянні з інкрементною методологією. При цьому результат кожного циклу розробки (чергова версія програмного засобу значно відрізняється від результату попереднього циклу. 
Використання даної методології найбільш ефективно в наступних випадках:
# при розробці проектів, для яких вимоги занадто складні, невідомі заздалегідь, непостійні або вимагають уточнення;
# при розробці складних проектів, в тому числі:
* великих довгострокових проектів;
* проектів зі створення нових, які не мають аналогів ПЗ або систем;
* проектів зі середнім і високим ступенем ризиків;
* проектів, для яких потрібна перевірка концепції, демонстрація технічної здійсненності або проміжних продуктів;
# при розробці проектів, що використовують нові технології.
[https://ppt-online.org/659746 Методології створення ПЗ]

'''Каскадна модель (waterflow model)'''
[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf] 26 ст.
Водоспадна модель (каскадна схема) запропонована в 1970 році Вінстоном Ройсом. і використовувалася в розробці програмного забезпечення (рис. 2.2), яке передбачало, що перехід на наступну стадію здійснюється після того, як повністю будуть завершені проектні операції попередньої стадії і отримані всі вихідні дані для наступної стадії.
Коротка характеристика каскадної схеми розробки програмного
забезпечення:
* фіксований набір стадій;
* кожна стадія закінчується документованим результатом;
* наступна стадія починається тільки після закінчення попередньої.
Недоліки:
* негнучкість;
* фаза повинна бути завершена до переходу до наступної;
* набір фаз фіксований;
* важко реагувати на зміни вимог.
 
'''Ітеративна модель (Iterative and incremental development) – модель з проміжним контролем'''
[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf] 30 ст.
Каскадна модель життєвого циклу не є ідеальною, оскільки лише дуже прості завдання проходять всі етапи без будь-яких ітерацій (повернень на попередні кроки процесу).
Наприклад, при програмуванні може виявитися, що реалізація деякої функції неефективна і вступає в протиріччя з вимогами до продуктивності системи. У цьому випадку потрібні зміни проекту, а можливо, і переробка специфікацій. 

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

Класична ітераційна модель абсолютизує можливість повернень на попередні етапи. Ця обставина відображає істотний аспект програмних розробок: прагнення заздалегідь передбачити всі ситуації використання системи і неможливість в більшості випадків досягти цього. Всі традиційні технології програмування спрямовані лише на те, щоб мінімізувати повернення. Але суть від цього не змінюється: при поверненні завжди доводиться повторювати побудову того, що вже вважалося готовим.
Схема, що підтримує ітераційний характер процесу розробки, була названа схемою з проміжним контролем. Контроль, який виконується за даною схемою після завершення кожного етапу, дозволяє при необхідності повернутися на будь-який рівень і внести необхідні зміни. Основна небезпека використання такої схеми пов'язана з тим, що розробка ніколи не буде завершена, постійно перебуваючи в стані уточнення та вдосконалення. 

Мета кожної ітерації в розробці ПЗ – отримання працюючої версії програмної системи, що включає функціональність, визначену інтегрованим змістом усіх попередніх і поточної ітерацій. Результат фінальної ітерації
містить всю необхідну функціональність продукту. Таким чином, із завершенням кожної ітерації продукт розвивається інкрементно (нарощує функціональність).
З точки зору структури життєвого циклу і процесу розробки така модель є ітеративною (iterative), а з точки зору розвитку продукту – інкрементною (incremental). Досвід індустрії розробки ПЗ показує, що неможливо розглядати кожен з цих поглядів ізольовано. Тому цю модель часто називають моделлю ітеративної і інкрементної розробки (Iterative and incremental development, IID).
 
'''Спіральна модель'''
[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf] 31 ст.
Для подолання перелічених проблем в середині 80-х років XX ст. була запропонована спіральна схема (рис. 2.4). Відповідно до даної схеми програмне забезпечення створюється не відразу, а ітераційно з використанням методу прототипування, що базується на створенні прототипів. Саме поява прототипування призвело до того, що процес
модифікації програмного забезпечення перестав сприйматися, як «необхідне зло», а став сприйматися як окремий важливий процес.
Прототипом називають діючий програмний продукт, який реалізує окремі функції і зовнішні інтерфейси розроблюваного програмного забезпечення.
На першій ітерації, як правило, специфікують, проектують, реалізують і тестують інтерфейс користувача. На другий - додають деякий обмежений набір функцій.
На наступних етапах цей набір розширюють, нарощуючи можливості даного продукту. 
Основною перевагою даної схеми є те, що, починаючи з деякої ітерації, на якій забезпечена певна функціональна повнота, продукт можна надавати користувачеві, що дозволяє:
* скоротити час до появи перших версій програмного продукту;
* зацікавити велику кількість користувачів, що забезпечує швидке просування наступних версій продукту на ринку;
* прискорити формування та уточнення специфікацій за рахунок появи практики використання продукту;
* зменшити ймовірність морального старіння системи за час розробки.
 

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

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

Обговорення:Esence-software-development

2022-09-07T13:53:22Z

Omind: Omind перейменував сторінку з Обговорення:Esence-software-development на Esence-software-development

#ПЕРЕНАПРАВЛЕННЯ [[Esence-software-development]]

Esence-software-development

2022-09-07T13:15:20Z

Omind:

Esence-software-development

2022-09-07T13:02:16Z

Omind: Створена сторінка: == Представлення та сутність моделей життєвого циклу розробки програмного забезпеченн...

Software-concepts

2022-09-07T10:52:30Z

Omind:

== Базові поняття створення програмних продуктів. ==
 
'''Технологія програмування''' – дисципліна, що вивчає технологічні процеси програмування та порядок їх проходження. 
'''Системна інженерія (System engineering)''' – розділ науки, що вивчає питання розробки комп'ютерних систем (архітектура, дизайн, інтеграція ПЗ та ін.). 
'''Програмна інженерія (Software engineering)''' – дисципліна, спрямована на розробку і супровід програмного забезпечення систем, що функціонують надійно і ефективно, можуть удосконалюватися і еволюціонувати і відповідають вимогам, визначених замовником. 
'''Програмування (Programming)''' – процес підготовки завдань для їх вирішення за допомогою комп'ютера; ітераційний процес складання програм. 
'''Програма''' – дані, призначені для управління конкретними компонентами системи обробки інформації з метою реалізації певного алгоритму, послідовність машинних команд, призначених для досягнення конкретного результату. 
'''Програмне забезпечення (ПЗ / Software)''' – комп'ютерні програми, процедури, а також документація і дані, що стосуються функціонування комп'ютерної системи. 

Вперше термін software ввів відомий статистик Джон Тьюк (John Tukey) в 1958 році для позначення різниці апаратного забезпечення ЕОМ (hardware) від засобів обробки даних. Бьярне Страуструп (Bjarne Stroustrup) відзначив, що добре ПЗ неможливо побачити, але можна відчути, коли воно працює з помилками.
За видами виконуваних функцій програмне забезпечення підрозділяється на системне, прикладне та інструментальне. Такий поділ є умовним, оскільки широке впровадження комп'ютеризації призвело до того, що майже кожна програма має ознаки декількох видів ПЗ. 

'''Інтегроване середовище розробки програмного забезпечення (Integrated development environment, IDE)''' - це система програмних засобів, що використовується програмістами для розробки програмного забезпечення.Як правило, середовище розробки включає текстовий редактор, компілятор і/або інтерпретатор, засоби автоматизації збирання, налагодження та різноманітні інструменти для конструювання графічного інтерфейсу користувача. Значного поширення об'єктно-орієнтованого програмування
(ООП) призвело до того, що сучасні інструменти розробки включають браузер класів та інспектор об'єктів.
На сьогодні в середовища розробки підключають систему керування версіями, засоби тестування та ін. 

[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf БАЗОВІ ПОНЯТТЯ]

'''Технологія розробки програмного забезпечення''' - це система інженерних принципів для створення економічного ПО з заданими характеристиками якості.
Будь-яка технологія розробки ПЗ базується на деякій методології або сукупності методологій.

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

Розробка модульних ПП ґрунтується на використанні '''структурних методів проектування''', метою яких є розбиття за деякими правилам проектованого програмного засобу на структурні компоненти. До структурних методів проектування відносяться такі класичні методи,як структурне програмування, проектування «зверху-вниз» і «знизу-вверх», метод розширення ядра, а також ряд сучасних методів і методологій розробки ПЗ.

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

[https://ppt-online.org/659746]

Software-concepts

2022-09-07T10:51:55Z

Omind: Створена сторінка: == Базові поняття створення програмних продуктів. == '''Технологія програмування''' – д...

== Базові поняття створення програмних продуктів. ==
 
'''Технологія програмування''' – дисципліна, що вивчає технологічні процеси програмування та порядок їх проходження. 
'''Системна інженерія (System engineering)''' – розділ науки, що вивчає питання розробки комп'ютерних систем (архітектура, дизайн, інтеграція ПЗ та ін.). 
'''Програмна інженерія (Software engineering)''' – дисципліна, спрямована на розробку і супровід програмного забезпечення систем, що функціонують надійно і ефективно, можуть удосконалюватися і еволюціонувати і відповідають вимогам, визначених замовником. 
'''Програмування (Programming)''' – процес підготовки завдань для їх вирішення за допомогою комп'ютера; ітераційний процес складання програм. 
'''Програма''' – дані, призначені для управління конкретними компонентами системи обробки інформації з метою реалізації певного алгоритму, послідовність машинних команд, призначених для досягнення конкретного результату. 
'''Програмне забезпечення (ПЗ / Software)''' – комп'ютерні програми, процедури, а також документація і дані, що стосуються функціонування комп'ютерної системи. 

Вперше термін software ввів відомий статистик Джон Тьюк (John Tukey) в 1958 році для позначення різниці апаратного забезпечення ЕОМ (hardware) від засобів обробки даних. Бьярне Страуструп (Bjarne Stroustrup) відзначив, що добре ПЗ неможливо побачити, але можна відчути, коли воно працює з помилками.
За видами виконуваних функцій програмне забезпечення підрозділяється на системне, прикладне та інструментальне. Такий поділ є умовним, оскільки широке впровадження комп'ютеризації призвело до того, що майже кожна програма має ознаки декількох видів ПЗ. 

'''Інтегроване середовище розробки програмного забезпечення (Integrated development environment, IDE)''' - це система програмних засобів, що використовується програмістами для розробки програмного забезпечення.Як правило, середовище розробки включає текстовий редактор, компілятор і/або інтерпретатор, засоби автоматизації збирання, налагодження та різноманітні інструменти для конструювання графічного інтерфейсу користувача. Значного поширення об'єктно-орієнтованого програмування
(ООП) призвело до того, що сучасні інструменти розробки включають браузер класів та інспектор об'єктів.
На сьогодні в середовища розробки підключають систему керування версіями, засоби тестування та ін.
[http://eprints.library.odeku.edu.ua/id/eprint/291/1/HnatovskayaHA_Texnologii_stvorennya_program_produktov_KL_2015.pdf БАЗОВІ ПОНЯТТЯ]

'''Технологія розробки програмного забезпечення''' - це система інженерних принципів для створення економічного ПО з заданими характеристиками якості.
Будь-яка технологія розробки ПЗ базується на деякій методології або сукупності методологій.

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

Розробка модульних ПП ґрунтується на використанні '''структурних методів проектування''', метою яких є розбиття за деякими правилам проектованого програмного засобу на структурні компоненти. До структурних методів проектування відносяться такі класичні методи,як структурне програмування, проектування «зверху-вниз» і «знизу-вверх», метод розширення ядра, а також ряд сучасних методів і методологій розробки ПЗ.

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

[https://ppt-online.org/659746]

Software-developing

2022-09-07T10:40:21Z

Omind:

== Процеси розробки програмного забезпечення відповідно до стандарту ISO/IEC 12207. ==

ISO/IEC 12207 було опубліковано 1 серпня 1995 року і це був перший міжнародний стандарт, що надав повний набір процесів життєвого циклу, діяльностей і завдань для програмного забезпечення, яке є частиною більшої системи, а також для автономних програмних продуктів і послуг.

'''Життєвий цикл і його процеси'''
Відповідно до стандарту ISO / IEC 12207 2008 - Системна і програмна інженерія - Процеси життєвого циклу програмних засобів.

'''Життєвим циклом (ЖЦ)''' програмного продукту або системи є сукупність процесів, робіт і завдань, яка включає в себе розробку, експлуатацію та супровід програмного засобу або системи і охоплює їхнє життя від формулювання концепції до утилізації ПП.
ЖЦ ПП складається з процесів. Кожен процес ЖЦ включає набір робіт. Кожна робота поділяється на набір задач.
З поняттям ЖЦ ПС і систем тісно пов'язане поняття моделі ЖЦ.
'''Модель життєвого циклу''' - це формалізована, абстрактна конструкція, яка відображає взаємозв'язок і послідовність виконання процесів ЖЦ і їх основних складових.
Процеси ЖЦ ПП діляться на три групи:
* основні;
* допоміжні;
* організаційні.

'''Основні процеси життєвого циклу''' - це процеси, які реалізуються під управлінням основних сторін, які беруть участь в життєвому циклі програмних засобів. Основними сторонами є замовник, постачальник, розробники, користувачі і персонал супроводу програмних продуктів. До основних процесів відноситься п'ять процесів:
* замовлення;
* поставка;
* розробка;
* експлуатація;
* супровід.

'''Процес розробки''' складається з робіт і завдань, які виконуються розробником. Даний процес містить тринадцять робіт:
# підготовка процесу розробки;
# аналіз вимог до системи;
# проектування системної архітектури;
# аналіз вимог до програмних засобів;
# проектування програмної архітектури;
# технічне проектування програмних засобів;
# програмування і тестування програмних засобів;
# збірка програмних засобів;
# кваліфікаційні випробування програмних засобів;
# збірка системи;
# кваліфікаційні випробування системи;
# введення в дію програмних засобів;
# приймання програмних засобів.

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

'''Організаційні процеси''' життєвого циклу - це процеси, призначені для створення в деякій організації та вдосконалення організаційних структур, що охоплюють процеси життєвого циклу і відповідний персонал.
До організаційних процесів відноситься чотири процесу:
* управління (управлінські);
* створення інфраструктури (інфраструктурні)
* удосконалення (процеси розвитку)
* навчання.
[https://ppt-online.org/659746 Основи інженерії програмного забезпечення]

Software-developing

2022-09-07T10:38:39Z

Omind:

== Процеси розробки програмного забезпечення відповідно до стандарту ISO/IEC 12207. ==

ISO/IEC 12207 було опубліковано 1 серпня 1995 року і це був перший міжнародний стандарт, що надав повний набір процесів життєвого циклу, діяльностей і завдань для програмного забезпечення, яке є частиною більшої системи, а також для автономних програмних продуктів і послуг.
Життєвий цикл і його процеси
Відповідно до стандарту ISO / IEC 12207 2008 - Системна і програмна інженерія - Процеси життєвого циклу програмних засобів.
Життєвим циклом (ЖЦ) програмного продукту або системи є сукупність процесів, робіт і завдань, яка включає в себе розробку, експлуатацію та супровід програмного засобу або системи і охоплює їхнє життя від формулювання концепції до утилізації ПП. ЖЦ ПП складається з процесів. Кожен процес ЖЦ включає набір робіт. Кожна робота поділяється на набір задач.
З поняттям ЖЦ ПС і систем тісно пов'язане поняття моделі ЖЦ.
Модель життєвого циклу - це формалізована, абстрактна конструкція, яка відображає взаємозв'язок і послідовність виконання процесів ЖЦ і їх основних складових.
Процеси ЖЦ ПП діляться на три групи:
* основні;
* допоміжні;
* організаційні.

'''Основні процеси життєвого циклу''' - це процеси, які реалізуються під управлінням основних сторін, які беруть участь в життєвому циклі програмних засобів. Основними сторонами є замовник, постачальник, розробники, користувачі і персонал супроводу програмних продуктів. До основних процесів відноситься п'ять процесів:
* замовлення;
* поставка;
* розробка;
* експлуатація;
* супровід.

'''Процес розробки''' складається з робіт і завдань, які виконуються розробником. Даний процес містить тринадцять робіт:
# підготовка процесу розробки;
# аналіз вимог до системи;
# проектування системної архітектури;
# аналіз вимог до програмних засобів;
# проектування програмної архітектури;
# технічне проектування програмних засобів;
# програмування і тестування програмних засобів;
# збірка програмних засобів;
# кваліфікаційні випробування програмних засобів;
# збірка системи;
# кваліфікаційні випробування системи;
# введення в дію програмних засобів;
# приймання програмних засобів.

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

'''Організаційні процеси''' життєвого циклу - це процеси, призначені для створення в деякій організації та вдосконалення організаційних структур, що охоплюють процеси життєвого циклу і відповідний персонал.
До організаційних процесів відноситься чотири процесу:
* управління (управлінські);
* створення інфраструктури (інфраструктурні)
* удосконалення (процеси розвитку)
* навчання.
[https://ppt-online.org/659746 Основи інженерії програмного забезпечення]

Software-developing

2022-09-07T10:37:43Z

Omind:

ISO/IEC 12207 було опубліковано 1 серпня 1995 року і це був перший міжнародний стандарт, що надав повний набір процесів життєвого циклу, діяльностей і завдань для програмного забезпечення, яке є частиною більшої системи, а також для автономних програмних продуктів і послуг.
Життєвий цикл і його процеси
Відповідно до стандарту ISO / IEC 12207 2008 - Системна і програмна інженерія - Процеси життєвого циклу програмних засобів.
Життєвим циклом (ЖЦ) програмного продукту або системи є сукупність процесів, робіт і завдань, яка включає в себе розробку, експлуатацію та супровід програмного засобу або системи і охоплює їхнє життя від формулювання концепції до утилізації ПП. ЖЦ ПП складається з процесів. Кожен процес ЖЦ включає набір робіт. Кожна робота поділяється на набір задач.
З поняттям ЖЦ ПС і систем тісно пов'язане поняття моделі ЖЦ.
Модель життєвого циклу - це формалізована, абстрактна конструкція, яка відображає взаємозв'язок і послідовність виконання процесів ЖЦ і їх основних складових.
Процеси ЖЦ ПП діляться на три групи:
* основні;
* допоміжні;
* організаційні.

'''Основні процеси життєвого циклу''' - це процеси, які реалізуються під управлінням основних сторін, які беруть участь в життєвому циклі програмних засобів. Основними сторонами є замовник, постачальник, розробники, користувачі і персонал супроводу програмних продуктів. До основних процесів відноситься п'ять процесів:
* замовлення;
* поставка;
* розробка;
* експлуатація;
* супровід.

'''Процес розробки''' складається з робіт і завдань, які виконуються розробником. Даний процес містить тринадцять робіт:
# підготовка процесу розробки;
# аналіз вимог до системи;
# проектування системної архітектури;
# аналіз вимог до програмних засобів;
# проектування програмної архітектури;
# технічне проектування програмних засобів;
# програмування і тестування програмних засобів;
# збірка програмних засобів;
# кваліфікаційні випробування програмних засобів;
# збірка системи;
# кваліфікаційні випробування системи;
# введення в дію програмних засобів;
# приймання програмних засобів.

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

'''Організаційні процеси''' життєвого циклу - це процеси, призначені для створення в деякій організації та вдосконалення організаційних структур, що охоплюють процеси життєвого циклу і відповідний персонал.
До організаційних процесів відноситься чотири процесу:
* управління (управлінські);
* створення інфраструктури (інфраструктурні)
* удосконалення (процеси розвитку)
* навчання.
[https://ppt-online.org/659746 Основи інженерії програмного забезпечення]

Software-developing

2022-09-07T10:34:50Z

Omind:

ISO/IEC 12207 було опубліковано 1 серпня 1995 року і це був перший міжнародний стандарт, що надав повний набір процесів життєвого циклу, діяльностей і завдань для програмного забезпечення, яке є частиною більшої системи, а також для автономних програмних продуктів і послуг.
Життєвий цикл і його процеси
Відповідно до стандарту ISO / IEC 12207 2008 - Системна і програмна інженерія - Процеси життєвого циклу програмних засобів.
Життєвим циклом (ЖЦ) програмного продукту або системи є сукупність процесів, робіт і завдань, яка включає в себе розробку, експлуатацію та супровід програмного засобу або системи і охоплює їхнє життя від формулювання концепції до утилізації ПП. ЖЦ ПП складається з процесів. Кожен процес ЖЦ включає набір робіт. Кожна робота поділяється на набір задач.
З поняттям ЖЦ ПС і систем тісно пов'язане поняття моделі ЖЦ.
Модель життєвого циклу - це формалізована, абстрактна конструкція, яка відображає взаємозв'язок і послідовність виконання процесів ЖЦ і їх основних складових.
Процеси ЖЦ ПП діляться на три групи:
* основні;
* допоміжні;
* організаційні.

'''Основні процеси життєвого циклу''' - це процеси, які реалізуються під управлінням основних сторін, які беруть участь в життєвому циклі програмних засобів. Основними сторонами є замовник, постачальник, розробники, користувачі і персонал супроводу програмних продуктів. До основних процесів відноситься п'ять процесів:
- замовлення;
- поставка;
- розробка;
- експлуатація;
- супровід.

'''Процес розробки''' складається з робіт і завдань, які виконуються розробником. Даний процес містить тринадцять робіт:
1) підготовка процесу розробки;
2) аналіз вимог до системи;
3) проектування системної архітектури;
4) аналіз вимог до програмних засобів;
5) проектування програмної архітектури;
6) технічне проектування програмних засобів;
7) програмування і тестування програмних засобів;
8) збірка програмних засобів;
9) кваліфікаційні випробування програмних засобів;
10) збірка системи;
11) кваліфікаційні випробування системи;
12) введення в дію програмних засобів;
13) приймання програмних засобів.

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

'''Організаційні процеси''' життєвого циклу - це процеси, призначені для створення в деякій організації та вдосконалення організаційних структур, що охоплюють процеси життєвого циклу і відповідний персонал.
До організаційних процесів відноситься чотири процесу:
- управління (управлінські);
- створення інфраструктури (інфраструктурні)
- удосконалення (процеси розвитку)
- навчання.

Software-developing

2022-09-07T10:15:48Z

Omind: Створена сторінка: ISO/IEC 12207 було опубліковано 1 серпня 1995 року і це був перший міжнародний стандарт, що нада...

ISO/IEC 12207 було опубліковано 1 серпня 1995 року і це був перший міжнародний стандарт, що надав повний набір процесів життєвого циклу, діяльностей і завдань для програмного забезпечення, яке є частиною більшої системи, а також для автономних програмних продуктів і послуг.
Життєвий цикл і його процеси
Відповідно до стандарту ISO / IEC 12207 2008 - Системна і програмна інженерія - Процеси життєвого циклу програмних засобів.
Життєвим циклом (ЖЦ) програмного продукту або системи є сукупність процесів, робіт і завдань, яка включає в себе розробку, експлуатацію та супровід програмного засобу або системи і охоплює їхнє життя від формулювання концепції до утилізації ПП. ЖЦ ПП складається з процесів. Кожен процес ЖЦ включає набір робіт. Кожна робота поділяється на набір задач.
З поняттям ЖЦ ПС і систем тісно пов'язане поняття моделі ЖЦ.
Модель життєвого циклу - це формалізована, абстрактна конструкція, яка відображає взаємозв'язок і послідовність виконання процесів ЖЦ і їх основних складових.
Процеси ЖЦ ПП діляться на три групи:
- основні;
- допоміжні;
- організаційні.

'''Основні процеси життєвого циклу''' - це процеси, які реалізуються під управлінням основних сторін, які беруть участь в життєвому циклі програмних засобів. Основними сторонами є замовник, постачальник, розробники, користувачі і персонал супроводу програмних продуктів. До основних процесів відноситься п'ять процесів:
- замовлення;
- поставка;
- розробка;
- експлуатація;
- супровід.

'''Процес розробки''' складається з робіт і завдань, які виконуються розробником. Даний процес містить тринадцять робіт:
1) підготовка процесу розробки;
2) аналіз вимог до системи;
3) проектування системної архітектури;
4) аналіз вимог до програмних засобів;
5) проектування програмної архітектури;
6) технічне проектування програмних засобів;
7) програмування і тестування програмних засобів;
8) збірка програмних засобів;
9) кваліфікаційні випробування програмних засобів;
10) збірка системи;
11) кваліфікаційні випробування системи;
12) введення в дію програмних засобів;
13) приймання програмних засобів.

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

'''Організаційні процеси''' життєвого циклу - це процеси, призначені для створення в деякій організації та вдосконалення організаційних структур, що охоплюють процеси життєвого циклу і відповідний персонал.
До організаційних процесів відноситься чотири процесу:
- управління (управлінські);
- створення інфраструктури (інфраструктурні)
- удосконалення (процеси розвитку)
- навчання.