Главная страница
Навигация по странице:

  • «КОНСТРУЮВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ »

  • РОБОТУ ПРИЙНЯВ викладач Кравченко В. Г. Білет №21 1

  • КОМП. Вітровчак. Державного вищого навчального закладу


    Скачать 377.55 Kb.
    НазваниеДержавного вищого навчального закладу
    Дата14.10.2021
    Размер377.55 Kb.
    Формат файлаdocx
    Имя файлаВітровчак.docx
    ТипДокументы
    #247282

    МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

    ФАХОВІЙ КОЛЕДЖ ІНФОРМАЦІЙНИХ СИСТЕМ І ТЕХНОЛОГІЙ

    ДЕРЖАВНОГО ВИЩОГО НАВЧАЛЬНОГО ЗАКЛАДУ

    «КИЇВСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ

    імені ВАДИМА ГЕТЬМАНА»

    ЕКЗАМЕНАЦІЙНА РОБОТА

    З ДИСЦИПЛІНИ «КОНСТРУЮВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ»

    РОБОТУ ВИКОНАВ

    студент групи 471

    Вітровчак О.В.










    РОБОТУ ПРИЙНЯВ

    викладач

    Кравченко В. Г.




    Білет №21
    1

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

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

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

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

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

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

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

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

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

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

    Виходячи з можливості внесення змін, як в процес, так і в проміжний продукт було створено спіральну модель ЖЦ

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

    Дана модель ЖЦ допускає аналіз продукту на витку розробки, його перевірку, оцінку правильності та прийняття рішення про перехід на наступний виток або повернення на попередній виток для доопрацювання на ньому проміжного продукту.

    Відмінність цієї моделі від каскадної полягає в можливості багато разів повертатися до процесу формулювання вимог і до повторної розробки версії системи з будь-якого процесу моделі.

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

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

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

    Процес – це сукупність взаємопов’язаних ресурсів і дій, яка має чітко визначені входи і виходи і створює в результаті цінність (додану вартість).

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

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

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

    Всі процеси проекту пов’язані своїми результатами – результат виконання одного процесу стає вихідною інформацією для іншого

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

    Власник процесу – учасник проекту, відповідальний за хід та результат всього процесу в цілому.

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



    З погляду процесного підходу виділяють дві групи пов’язаних з проектом процесів:

    1) процеси управління проектом;

    2) процеси життєвого циклу проекту.

    Процеси можуть бути розбиті на п’ять основних груп, що реалізують різні функції управління проектом:

    1) процеси ініціації – ухвалення рішення про початок виконання проекту;

    2) процеси планування – визначення цілей і критеріїв успіху проекту і розробка робочих схем їхнього досягнення;

    3) процеси виконання – координація людей та інших ресурсів для виконання плану;

    4) процеси моніторингу і управління – визначення відповідності плану і виконання проекту поставленим цілям і критеріям успіху та прийняття рішень про необхідність застосування коригувальних впливів, визначення необхідних коригувальних впливів, їхнє узгодження, затвердження і застосування;

    5) процеси завершення – формалізація виконання проекту і підведення його до впорядкованого фіналу.

    Взаємозв’язки між групами процесів – логічні. Багато процесів виконуються паралельно, у тому числі і процеси з різних груп. Основні процеси в проекті не відбуваються послідовно, а накладаються один на одного, причому їх активність також є змінною.

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

    Наприклад, цілі проекту не можуть бути визначені при відсутності розуміння того, як створити продукт.

    Для майбутнього успіху проекту та його результативності згідно з процесним підходом слід проаналізувати:

    – чи ефективно проект структурований;

    – чи оптимально спроектовані ланцюжки організаційно-технологічної взаємодії підпроцесів всередині структури;

    – як організована взаємодія структур.
    3
    У методології наукових досліджень розрізняють поняття «об'єкт» і «предмет» пізнання.

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

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

    • політична економія — система виробничих відносин;

    • економічна статистика — кількісна характеристика економічних явищ;

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

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

    Призначення і особливості

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

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

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



    написать администратору сайта