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


Мал. 5.2.

Такими аспектами є:

  1. договірний аспект, в якому замовник і постачальник вступають в договірні відносини і реалізують процеси придбання та поставки;
  2. аспект управління, який включає дії управління особами, які беруть участь в ЖЦ ПО (постачальник, замовник, розробник, оператор та ін.);
  3. аспект експлуатації, що включає дії оператора з надання послуг користувачам системи;
  4. інженерний аспект, який містить дії розробника або служби супроводу за рішенням технічних завдань, пов'язаних з розробкою або модифікацією програмних продуктів;
  5. аспект підтримки, пов'язаний з реалізацією допоміжних процесів, за допомогою яких служби підтримки надають необхідні послуги всім іншим учасникам робіт. В цьому аспекті можна виділити аспект управління якістю ПЗ, що включає процеси забезпечення якості, верифікацію, атестацію, спільну оцінку і аудит.

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

5.6. Моделі і стадії ЖЦ ПО

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

Стандарт ISO / IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ. Його положення є загальними для будь-яких моделей ЖЦ, методів і технологій розробки ПЗ. Стандарт описує структуру процесів ЖЦ ПО, але не конкретизує, як реалізувати або виконати дії і завдання, включені в ці процеси.

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

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

  1. формування вимог до ПЗ;
  2. проектування (розробка системного проекту);
  3. реалізація (може бути розбита на підетапи: детальне проектування, кодування);
  4. тестування (може бути розбите на автономне та комплексне тестування і інтеграцію);
  5. введення в дію (впровадження);
  6. експлуатація та супровід;
  7. зняття з експлуатації.

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

Стадія формування вимог до ПЗ є однією з найважливіших і визначає значною (навіть вирішальною!) Мірою успіх всього проекту. Початком цієї стадії є отримання схваленої і затвердженої архітектури системи з включенням основних угод про розподіл функцій між апаратурою і програмами. Цей документ повинен також містити підтвердження загального уявлення про функціонування ПО з включенням основних угод про розподіл функцій між людиною і системою.

Стадія формування вимог до ПЗ включає наступні етапи.

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

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

    • моделі "AS-IS" ( "як є"), що відбиває існуюче на момент обстеження стан справ в організації і дозволяє зрозуміти, яким чином працює дана організація, а також виявити вузькі місця і сформулювати пропозиції щодо поліпшення ситуації;
    • моделі "TO-BE" ( "як повинно бути"), що відбиває уявлення про нові технології роботи організації.

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

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

Стадія проектування включає наступні етапи.

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

    Основу системного проекту складають моделі проектованої системи, які будуються на моделі "TO-BE". Результатом розробки системного проекту повинна бути схвалена і підтверджена специфікація вимог до ПО: функціональні, технічні та інтерфейсні специфікації, для яких підтверджена їх повнота, проверяемость і здійсненність.

  2. Розробка детального (технічного) проекту. На цьому етапі здійснюється власне проектування ПО, що включає проектування архітектури системи і детальне проектування. Таким чином, дається відповідь на питання: "Як побудувати систему, щоб вона задовольняла вимогам?"

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

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

Завершенням стадії детального проектування є наскрізною

Федеральним агентством з технічного регулювання і метрології РФ 01.03.2012 р натомість ДСТУ ISO / IEC 12207-99 прийнятий стандарт ДСТУ ISO / IEC 12207-2010 «Інформаційна технологія. Системна і програмна інженерія. Процеси життєвого циклу програмних засобів », ідентичний міжнародному стандарту ISO / IEC 12207: 2008« System and software engineering - Software life cycle processes ».

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

Процеси життєвого циклу ПО

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

  • процеси угоди - два процеси;
  • процеси організаційного забезпечення проекту - п'ять процесів;
  • процеси проекту - сім процесів;
  • технічні процеси - одинадцять процесів;
  • процеси реалізації програмних засобів - сім процесів;
  • процеси підтримки програмних засобів - вісім процесів;
  • процеси повторного застосування програмних засобів - три процесу.
  • Основні:
    • Придбання (дії і завдання замовника, котре купує ПО)
    • Поставка (дії і завдання постачальника, який постачає замовника програмним продуктом або послугою)
    • Розробка (дії і завдання, що виконуються розробником: створення ПО, оформлення проектної та експлуатаційної документації, підготовка тестових і навчальних матеріалів і т. Д.)
    • Експлуатація (дії і завдання оператора - організації, що експлуатує систему)
    • Супровід (дії і завдання, що виконуються супроводжує організацією, тобто службою супроводу). Супровід - внесень змін до ПО з метою виправлення помилок, підвищення продуктивності або адаптації до умов, що змінилися роботи або вимогам.
  • допоміжні
    • Документування (формалізоване опис інформації, створеної протягом ЖЦ ПО)
    • Управління конфігурацією (застосування адміністративних і технічних процедур на всьому протязі ЖЦ ПО для визначення стану компонентів ПО, управління його модифікаціями).
    • Забезпечення якості (забезпечення гарантій того, що ІС і процеси її ЖЦ відповідають заданим вимогам і затвердженим планам)
    • Верифікація (визначення того, що програмні продукти, які є результатами певної дії, повністю задовольняють вимогам або умовам, обумовленим попередніми діями)
    • Атестація (визначення повноти відповідності заданих вимог і створеної системи їх конкретному функціональному призначенню)
    • Спільна оцінка (оцінка стану робіт по проекту: контроль планування та управління ресурсами, персоналом, апаратурою, інструментальними засобами)
    • Аудит (визначення відповідності вимогам, планам і умовами договору)
    • Дозвіл проблем (аналіз і рішення проблем, незалежно від їх походження або джерела, які виявлені в ході розробки, експлуатації, супроводу або інших процесів)
  • організаційні
    • Управління (дії і завдання, які можуть виконуватися будь-якою стороною, що управляє своїми процесами)
    • Створення інфраструктури (вибір і супровід технології, стандартів і інструментальних засобів, вибір і установка апаратних і програмних засобів, які використовуються для розробки, експлуатації або супроводу ПО)
    • Удосконалення (оцінка, вимір, контроль і удосконалення процесів ЖЦ)
    • Навчання (початкове навчання і подальше постійне підвищення кваліфікації персоналу)

Кожен процес включає ряд дій. Наприклад, процес придбання охоплює наступні дії:

  1. Ініціювання придбання
  2. Підготовка заявочних пропозицій
  3. Підготовка та коригування договору
  4. Нагляд за діяльністю постачальника
  5. Приймання та завершення робіт

Кожна дія включає ряд завдань. Наприклад, підготовка заявочних пропозицій повинна передбачати:

  1. Формування вимог до системи
  2. Формування списку програмних продуктів
  3. Встановлення умов і угод
  4. Опис технічних обмежень (середовище функціонування системи і т. Д.)

Стадії життєвого циклу ПО, взаємозв'язок між процесами і стадіями

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

Стандарт ДСТУ ISO / IEC 12207-2010 не пропонує конкретну модель життєвого циклу. Його положення є загальними для будь-яких моделей життєвого циклу, методів і технологій створення ІС. Він описує структуру процесів життєвого циклу, що не конкретизуючи, як реалізувати або виконати дії і завдання, включені в ці процеси.

Модель ЖЦ ПО включає в себе:

  1. стадії;
  2. Результати виконання робіт на кожній стадії;
  3. Ключові події - точки завершення робіт і прийняття рішень.

Анотація.

Вступ.

1. Життєвий цикл ПЗ

Вступ.

Кроки процесу програмування по Райлі

Вступ.

1.1.1. Постановка задачі.

1.1.2. Проектування рішення.

1.1.3. Кодування алгоритму.

1.1.4. Супровід програми.

1.1.5. Програмна документація.

Висновок до п. 1.1

1.2. Визначення ЖЦПО по Леману.

Вступ.

1.2.1 Визначення системи.

1.2.2. Реалізація.

1.2.3. Обслуговування.

Висновок до п. 1.2.

1.3. Фази і роботи ЖЦПО по Боема

1.3.1. Каскадна модель.

1.3.2. Економічне обгрунтування каскадної моделі.

1.3.3. Удосконалення каскадної моделі.

1.3.4. Визначення фаз життєвого циклу.

1.3.5. Основні роботи над проектом.

Література.


Вступ

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

У практиці розробок великих програмних проектів часто відсутня єдиний підхіддо оцінювання витрат праці, термінів проведення робіт і матеріальних витрат, що стримує підвищення продуктивності розробки ПО, а в кінцевому рахунку - ефективне управління життєвим циклом ПЗ. Оскільки програма будь-якого типу стає виробом (крім, може бути, навчальних, макетних програм), підхід до її виготовлення багато в чому повинен бути аналогічний підходу до виробництва промислової продукції, і питання проектування програм стають надзвичайно важливими. Ця ідея лежить в основі книги Б.У. Боема «Інженерне проектування програмного забезпечення», яку ми використовували при написанні даної курсової роботи. У цій книзі під проектуванням ПО розуміється процес створення проекту програмного вироби.


1 Життєвий цикл ПЗ

ВСТУП

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

Існує кілька підходів при визначенні фаз і робіт життєвого циклу програмного забезпечення (ЖЦПО), кроків процесу програмування, каскадна і спіральна моделі. Але всі вони містять загальні основоположні компоненти: постановка задачі, проектування рішення, реалізація, обслуговування.

Найбільш відомою і повної, мабуть, є структура ЖЦПО по Боема, що включає вісім фаз. Вона і буде представлена ​​в подальшому найбільш докладно.

Одним з можливих варіантів може послужити опис верхнього рівня по Леману, що включає три основні фази і представляє опис ЖЦПО в найзагальнішому випадку.

І, для різноманітності, - наведемо кроки процесу програмування, представлені Д.Райлі в книзі «Використання мови Модула-2». Це уявлення, по-моєму, є досить простим і звичним, з нього і почнемо.

1.1 Кроки процесу програмування по Райлі

Процес програмування включає чотири кроки (рис. 1):

постановка задачі, тобто отримання адекватного уявлення про те, яке завдання має виконати програма;

проектування рішення вже поставленого завдання (в загальному, таке рішення є менш формальним, ніж остаточна програма);

кодування програми, т. е. переклад спроектованого рішення в програму, яка може бути виконана на машині;

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

Мал. 1.Четире кроку програмування.

Програмування починається з того моменту, коли користувач, Тобто той, хто потребує програми для вирішення завдання, викладає проблему системному аналітику.Користувач і системний аналітик спільно визначають постановку задачі. Остання потім передається алгоритмісти, Який відповідає за проектування рішення. Рішення (або алгоритм) представляє послідовність операцій, виконання яких призводить до вирішення завдання. Оскільки алгоритм часто не пристосований до виконання на машині, його слід перевести в машинну програму. Ця операція виконується кодувальником. За наступні зміни в програмі несе відповідальність сопровождающійпрограмміст. І системний аналітик, і алгоритмісти, і кодировщик, і супроводжуючий програміст - всі вони є програмістами.

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

1.1.1 Постановка завдання

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

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

Характеристики Доброю Постановки Завдання:

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

повнота, Тобто розгляд всіх варіантів для заданого введення, включаючи помилковий або непередбачений введення, і визначення відповідного висновку.

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

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

Стандартна форма постановки завдання.

Розглянемо наступну постановку задачі: «Ввести три числа і вивести числа в порядку».

Така постановка не задовольняє наведеним вище вимогам: вона не є ні точної, ні повної, ні зрозумілої. Дійсно, чи повинні числа вводитися по одному на рядку або все числа на одному рядку? Чи означає вираз «в порядку» впорядкування від більшого до меншого, від меншого до більшого або той же порядок, в якому вони були введені.

Очевидно, що подібна постановка не відповідає на безліч запитань. Якщо ж врахувати відповіді на всі питання, то постановка задачі стане багатослівній і важкою для сприйняття. Тому Д. Райлі пропонує для постановки завдання користуватися стандартною формою, яка забезпечує максимальну точність, повноту, ясність і включає:

найменування завдання (схематичне визначення);

загальний опис (короткий виклад завдання);

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

приклад (хороший приклад може передати сутність завдання, а також проілюструвати різні випадки).

Приклад. Постановка завдання в стандартній формі.

НАЗВА

Сортування трьох цілих чисел.

ОПИС

Введення і виведення трьох цілих чисел, відсортованих від меншого числа до більшого.

Вводяться три цілих числа по одному числу на рядку. При цьому цілим числом є одна або декілька послідовних десяткових цифр, яким може передувати знак плюс «+» або знак мінус «-».

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

1) Якщо введено менше трьох чисел, програма чекає додаткового введення.

Стандарти життєвого циклу ПО

  • ГОСТ 34.601-90
  • ISO / IEC 12207: 1995 (російський аналог - ГОСТ Р ISO / IEC 12207-99)

Стандарт ГОСТ 34 .601-90

ітераційна модель

Альтернативою послідовної моделі є так звана модель итеративной і інкрементальною розробки (англ. iterative and incremental development, IID ), Що отримала також від Т. Гілбі в 70-і рр. назва еволюційної моделі. Також цю модель називають итеративной моделлюі інкрементальною моделлю .

Модель IID передбачає розбиття життєвого циклу проекту на послідовність ітерацій, кожна з яких нагадує «міні-проект», включаючи всі процеси розробки в застосуванні до створення менших фрагментів функціональності, в порівнянні з проектом в цілому. мета кожної ітерації- отримання працюючої версії програмної системи, що включає функціональність, певну інтегрованим змістом усіх попередніх і поточної ітерації. Результат фінальної ітерації містить всю необхідну функціональність продукту. Таким чином, із завершенням кожної ітерації продукт від нього бере зріст - інкремент- до його можливостей, які, отже, розвиваються еволюційно. Ітеративна, Інкрементальний і еволюційність в даному випадку є вираз одного і той же сенсу різними словами зі злегка різних точок зору.

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

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

Різні варіанти ітераційного підходу реалізовані в більшості сучасних методологій розробки (RUP, MSF,).

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

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

На кожній ітерації оцінюються:

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

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

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

  1. Дефіцит фахівців.
  2. Нереалістичні терміни і бюджет.
  3. Реалізація невідповідної функціональності.
  4. Розробка неправильного користувальницького інтерфейсу.
  5. Перфекціонізм, непотрібна оптимізація і відточування деталей.
  6. Безперервний потік змін.
  7. Брак інформації про зовнішні компонентах, що визначають оточення системи або залучених в інтеграцію.
  8. Недоліки в роботах, виконуваних зовнішніми (по відношенню до проекту) ресурсами.
  9. Недостатня продуктивність одержуваної системи.
  10. Розрив в кваліфікації фахівців різних областей.

У сьогоднішній спіральної моделі визначено наступний загальний набір контрольних точок:

  1. Concept of Operations (COO) - концепція (використання) системи;
  2. Life Cycle Objectives (LCO) - цілі і зміст життєвого циклу;
  3. Life Cycle Architecture (LCA) - архітектура життєвого циклу; тут же можливо говорити про готовність концептуальної архітектури цільової програмної системи;
  4. Initial Operational Capability (IOC) - перша версія створюваного продукту, придатна для дослідної експлуатації;
  5. Final Operational Capability (FOC) - готовий продукт, розгорнутий (встановлений і налаштований) для реальної експлуатації.

Методології розробки ПО

  • Microsoft Solutions Framework (MSF). Включає 4 фази: аналіз, проектування, розробка, стабілізація, передбачає використання об'єктно-орієнтованого моделювання.
  • Екстремальне програмування (англ. Extreme Programming, XP). В основі методології командна робота, ефективна комунікація між замовником і виконавцем протягом усього проекту з розробки ІС. Розробка ведеться з використанням послідовно допрацьовувати прототипів.
  • ЕСПД - комплекс державних стандартів Російської Федерації, що встановлюють взаємопов'язані правила розробки, оформлення та обігу програм і програмної документації.

література

  • Братищенко В.В.Проектування інформаційних систем. - Іркутськ: Изд-во БГУЕП, 2004. - 84 с.
  • Вендров А.М.Проектування програмного забезпечення економічних інформаційних систем. - М.: Фінанси і статистика, 2000..
  • Грекул В.І., Денищенко Г.Н., Коровкина Н.Л.Проектування інформаційних систем. - М.: Інтернет-університет інформаційних технологій - ІНТУІТ.ру, 2005.
  • Мишенин А.І.Теорія економічних інформаційних систем. - М.: Фінанси і статистика, 2000. - 240 с.

Примітки


Wikimedia Foundation. 2010 року.

Розвиток ВТ постійно розширює класи розв'язуваних завдань пов'язаних з обробкою інформації різного характеру.

Це в основному три види інформації і відповідно три класи завдань, для вирішення яких використовуються комп'ютери:

1) Обчислювальні завдання, пов'язані з обробкою числової інформації. До них відноситься, наприклад, завдання вирішення системи лінійних рівнянь великої розмірності. Раніше була основною, домінуючою галуззю використання ЕОМ.

2) Завдання з обробки символьної інформації, пов'язані зі створенням, редагуванням і перетворенням текстових даних. З рішенням таких завдань пов'язаний працю, наприклад, секретаря-друкарки.

3) Завдання з обробки графічної інформації тобто схем, креслень, графіків, ескізів і т.д. До таких завдань належить, наприклад, завдання розробки конструктором креслень нових виробів.

4) Завдання з обробки алфавітно-цівровой інформації - ІС. В даний час стало однією з основних областей применеия ЕОМ і завдання все ускладнюються.

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

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

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

малюнок

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

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

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

Життєвий циклПО - це безперервний і упорядкований набір видів діяльності, що здійснюється і керований в рамках кожного проекту з розробки і експлуатації ПО, що починається з моменту появи ідеї (задуму) створення деякого програмного забезпечення і прийняття рішення про необхідність його створення і закінчується в момент його повного вилучення з експлуатації з причин:


а) морального старіння;

б) втрати необхідності вирішення відповідних завдань.

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

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

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

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

проектування

Реалізація

Тестування та налагодження

Впровадження, експлуатація та супровід.

Найпростіше уявлення ЖЦ програми (каскадний технологічний підхід до ведення життєвого циклу):

процеси

проектування

програмування

тестування

супровід

Аналіз Проектування Реалізація ТестірованіеВнедреніеексплуатація

і налагодження та супровід

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

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

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

етап реалізаціївключає написання програми.

Відмінності в вппаратном забезпеченні і програмному забезпеченні особливо видно на етапі експлуатації. Якщо товари широкого вжитку проходять етапи виведення на ринок, зростання, зрілості і занепаду, то життя ПО більше схожий на історію недобудованого, але постійно добудовувався і підновляти будівлі (літака) (Абонент).

ЖЦ ПО регламентується багатьма стандартами в тому числі і міжнародними.

Мета стандартизації ЖЦ складних ПС:

Узагальнення досвіду та результатів досліджень безлічі фахівців;

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

Стандарти включають:

Правила опису вихідної інформації, способів і методів виконання операцій;

Встановлюють правила контролю технологічних процесів;

Встановлюють вимоги до оформлення результатів;

Регламентують зміст технологічних і експлуатаційних документів;

Визначають організаційну структуру колективу розробників;

Забезпечують розподіл і планування завдань;

Забезпечують контроль за ходом створення ПС.

У Росії діють стандарти, що регламентують ЖЦ:

Стадії розробки ПО-ГОСТ 19.102-77

Стадії створення АС - ГОСТ 34.601 -90;

ТЗ на створення АС - ГОСТ 34.602-89;

Види випробування АС - ГОСТ 34.603-92;

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

У зв'язку з цим слід зазначити міжнародний стандарт ISO / IEC 12207-1999 - «Інформаційні технології - Процеси життєвого циклу програмного забезпечення».

ISO - International Organization of Standardization - Міжнародна організація по стандартизації, IEC - International Electrotechnical Commission - Міжнародна комісія з електротехніки.

Він визначає структуру ЖЦ ПО і його процеси.

Тобто створення ПО це не таке просте завдання, тому й існують стандарти, в яких все розписано: що потрібно робити, коли і як.

Структура ЖЦ ПО за міжнародним стандартом ISO / IEC 12207-95 базується на трьох групах процесів:

1) основні процеси ЖЦ ПО (придбання, поставка, розробка, експлуатація, супровід). Ми основну увагу приділимо останнім.

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

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

2. Верифікаціяце процес визначення того, чи відповідає поточний стан ПО, досягнуте на даному етапі, вимогам цього етапу.

3. Атестація- підтвердження експертизою і поданням об'єктивних доказів того, що конкретні вимоги до конкретних об'єктів повністю реалізовані.

4. Спільний аналіз (оцінка) – систематичне визначення ступеня відповідності об'єкта встановленим критеріям.

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

3) організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка та поліпшення самого ЖЦ, навчання).

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

Ми будемо розглядати ЖЦ ПО з точки зору розробника.

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

За стандартом життєвий цикл ПО ІС включає в себе наступні дії:

1) виникнення і дослідження ідеї (задуму);

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

3) аналіз вимог до інформаційної системи - визначення її

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

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

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

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

7) детальне проектування програмного забезпечення - докладний

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

8) кодування ПО -– Розробка та документування

кожного програмного компонента;

9)тестування ПО - розробка сукупності тестових процедур і даних для їх тестування, тестування компонентів, оновлення документації для користувачів, оновлення плану інтеграції ПО;

10) інтеграція ПО–збірка програмних компонентів в відповідність з

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

11) кваліфікаційне тестування ПО – тестування ПО в

присутності замовника для демонстрації його відповідності

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

12) інтеграція системи – збірка всіх компонетов інформаційної системи, включаючи ПЗ і обладнання;

13) кваліфікаційне тестування ІС – тестування системи на

відповідність вимогам до неї та перевірка оформлення і повноти документації;

14) установка ПО – установка ПО на обородованіе замовника і перевірка його работоспособюності;;

15) приймання ПО – оцінка результатів кваліфікованого

тестування ПО і інформціонной системи в цілому і

документування результатів оцінки спільно із замовником, атестація і остаточна передача ПО замовнику.

16) Управління та розробка документації;

17) експлуатація

18) супровід - процес створення і впровадження нових версій

програмного продукту.;

19) завершення експлуатації.

Зазначені дії можна згрупувати, умовно виділивши наступні основні етапи розробки ПО:

· Постановка завдання (ТЗ) (по ГОСТ 19.102-77 стадія «Технічне завдання»)