Чотири «П» у розробці ПЗ

План

Тема: Введення у процес розробки ПЗ.

1. Чотири «П» у розробці ПЗ

2. Вплив структурного і ОО програмування на процес розробки ПЗ

3. Повторне використання компонентів (модульний підхід) у процесі розробки ПЗ

4. Вимоги до процесу, проекту, продукту і персоналу

У 80-ті і 90-ті роки минулого століття в області розробки ПЗ переважали дві тенденції. Одна – це поява різноманітних додатків, у тому числі для Web. Друга – це розквіт інструментальних засобів і парадігм (підходів до проектування, таких як ООП). Але, не дивлячись на появу нових тенденцій, основні етапи розробки ПЗ залишилися незмінними, а саме:

− Визначення процесу розробки ПЗ

− Управління проектом розробки

− Опис цільового ПП

− Проектування ПП

− Розробка ПП (тобто його програмування)

− Тестування частин ПП

− Інтеграція частин і тестування ПП в цілому

− Супроводження ПП

Система розробки ПЗ містить у собі персонал, процес, проект і продукт. Схематично це можна позначити так:

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

Як народжуються складні і придатні до використання додатки? Стандартна послідовність кроків така:

1. Зрозуміти природу і сферу застосування ПП

Перш за все необхідно визначити суть проекта. Необхідно уявити масштаби проекту, з’ясувати терміни, фінанси і персонал, який є в наявності.

2. Вибрати процес розробки і створити план

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

3. Зібрати вимоги

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

4. Спроектувати і зібрати продукт

5. Виконати тестування продукту

6. Випустити продукт і забезпечити його супроводження

Розробка ПЗ – дуже молода галузь інженерної науки. Вона піддається постійним і швидким змінам. 1998 рік – вперше у США стало можливим зареєструватися у якості інженера ПЗ. В цій галузі сформувалося багато цікавих ідей.

Яких???

Вплив структурного і ОО програмування

З моменту зародження технологія розробки ПЗ мала кілька підйомів. Один із них пов’язаний з з листо Едсгера Дійкстри в Асоціацію ОТ (АСМ) «Про шкоду використання операторів GO TO». Він запропонував концепцію струтурного програмування.

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

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

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

Але структурним програмам у такому вигляді не вистачало одної дуже важливої властивості – в їх структурі безпосередньо не відображалися сутності предметної області і тому програми було важко модифікувати в умовах змінення вимог.

У зв’язку з цим виникла парадігма об’єктної орієнтованості, яка заснована на використанні об’єктів, що об’єднують у собі дані і функціональність.

Повторне використання компонентів

Кажуть, що Генрі Форд зробив революцію у виробництві автомобілів, коли помітив, що вузли автомобіля можна стандартизувати, так що при складанні автомобілів даної моделі можна буде використовувати будь-який екземпляр того вузла, що потрібен. Це здешевило процес складання й зробило автомобілі доступними по ціні широким верствам населення.

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

Модульний підхід також важливий на етапах детального проектування й реалізації.

Вимоги до процесу, проекту, продукту і персоналу

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

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

Роль чотирьох "П" у досягненні п'яти ключових вимог демонструє рисунок:

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

Наприклад, створення програм тільки по проекту (пункт 4,б) – це вимога, яка може бути проконтрольованою у проекті, і яка вимагає певних зусиль з боку персоналу, що працює над проектом. Досягнення конкретних, завчасно встановлених і таких, що можуть бути виміряними, цілей – ось головна вимога до проекту і кінцевому програмному продукту. Всі п’ять вимог мають своє переломлення до конкретного проекту і всі п’ять залежать від діяльності людей.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Інформаційні видання	\|	Основні класифікаційні ознаки ІС

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.005 сек.