МАРК РЕГНЕРУС ДОСЛІДЖЕННЯ: Наскільки відрізняються діти, які виросли в одностатевих союзах
РЕЗОЛЮЦІЯ: Громадського обговорення навчальної програми статевого виховання ЧОМУ ФОНД ОЛЕНИ ПІНЧУК І МОЗ УКРАЇНИ ПРОПАГУЮТЬ "СЕКСУАЛЬНІ УРОКИ" ЕКЗИСТЕНЦІЙНО-ПСИХОЛОГІЧНІ ОСНОВИ ПОРУШЕННЯ СТАТЕВОЇ ІДЕНТИЧНОСТІ ПІДЛІТКІВ Батьківський, громадянський рух в Україні закликає МОН зупинити тотальну сексуалізацію дітей і підлітків Відкрите звернення Міністру освіти й науки України - Гриневич Лілії Михайлівні Представництво українського жіноцтва в ООН: низький рівень культури спілкування в соціальних мережах Гендерна антидискримінаційна експертиза може зробити нас моральними рабами ЛІВИЙ МАРКСИЗМ У НОВИХ ПІДРУЧНИКАХ ДЛЯ ШКОЛЯРІВ ВІДКРИТА ЗАЯВА на підтримку позиції Ганни Турчинової та права кожної людини на свободу думки, світогляду та вираження поглядів
Контакти
Тлумачний словник Авто Автоматизація Архітектура Астрономія Аудит Біологія Будівництво Бухгалтерія Винахідництво Виробництво Військова справа Генетика Географія Геологія Господарство Держава Дім Екологія Економетрика Економіка Електроніка Журналістика та ЗМІ Зв'язок Іноземні мови Інформатика Історія Комп'ютери Креслення Кулінарія Культура Лексикологія Література Логіка Маркетинг Математика Машинобудування Медицина Менеджмент Метали і Зварювання Механіка Мистецтво Музика Населення Освіта Охорона безпеки життя Охорона Праці Педагогіка Політика Право Програмування Промисловість Психологія Радіо Регилия Соціологія Спорт Стандартизація Технології Торгівля Туризм Фізика Фізіологія Філософія Фінанси Хімія Юриспунденкция |
|
|||||||
Чотири «П» у розробці ПЗПлан Тема: Введення у процес розробки ПЗ. 1. Чотири «П» у розробці ПЗ 2. Вплив структурного і ОО програмування на процес розробки ПЗ 3. Повторне використання компонентів (модульний підхід) у процесі розробки ПЗ 4. Вимоги до процесу, проекту, продукту і персоналу У 80-ті і 90-ті роки минулого століття в області розробки ПЗ переважали дві тенденції. Одна – це поява різноманітних додатків, у тому числі для Web. Друга – це розквіт інструментальних засобів і парадігм (підходів до проектування, таких як ООП). Але, не дивлячись на появу нових тенденцій, основні етапи розробки ПЗ залишилися незмінними, а саме: − Визначення процесу розробки ПЗ − Управління проектом розробки − Опис цільового ПП − Проектування ПП − Розробка ПП (тобто його програмування) − Тестування частин ПП − Інтеграція частин і тестування ПП в цілому − Супроводження ПП Система розробки ПЗ містить у собі персонал, процес, проект і продукт. Схематично це можна позначити так: Проектування ПЗ – це процес створення додатків реальних розмірів і практичної значущості, що задовільняють заданим вимогам функціональності і продуктивності, таких, наприклад, як текстовий редактор, електронна таблиця, ОС, або програма контролю несправностей космічної станції. Програмування – це лише один з видів діяльності, що входять до циклу розробки ПЗ. Як народжуються складні і придатні до використання додатки? Стандартна послідовність кроків така: 1. Зрозуміти природу і сферу застосування ПП Перш за все необхідно визначити суть проекта. Необхідно уявити масштаби проекту, з’ясувати терміни, фінанси і персонал, який є в наявності. 2. Вибрати процес розробки і створити план З самого початку проекту повинна вестися документація, яка у ході розробки буде, звісно, змінюватися і оновлюватися. Такий процес називається управлінням конфігураціями. Потім визначаются методи розробки. Після цього складається загальний план проекту, який містить у собі план-графік. Цей план буде уточнюватися протягом усього ЖЦП, по мірі того, як будуть уточнюватися вимоги до проекту і деталі реалізації. Наприклад, деталі плана-графіку не можуть бути проробленим доти, доки не буде визначена архітектура додатку. 3. Зібрати вимоги Цей крок складається з обговорення проекту з замовниками і іншими учасниками, зацікавленими у виконанні. 4. Спроектувати і зібрати продукт 5. Виконати тестування продукту 6. Випустити продукт і забезпечити його супроводження
Розробка ПЗ – дуже молода галузь інженерної науки. Вона піддається постійним і швидким змінам. 1998 рік – вперше у США стало можливим зареєструватися у якості інженера ПЗ. В цій галузі сформувалося багато цікавих ідей. Яких??? Вплив структурного і ОО програмування З моменту зародження технологія розробки ПЗ мала кілька підйомів. Один із них пов’язаний з з листо Едсгера Дійкстри в Асоціацію ОТ (АСМ) «Про шкоду використання операторів GO TO». Він запропонував концепцію струтурного програмування. Концепція Дійкстри полягала у тому, що для запису будь-якої програми в принципі достатньо тільки трьох конструкцій управління – послідовного виконання, розгалуження і циклу. Наступний крок у розвитку структурного програмування пов’язаний з введенням апапрату функцій, які дозволяють розбити структурну програму на окремі частини. При такому підході програма пишеться у термінах виклику функцій верхнього рівня, які реалізуються за допомогою функцій більш низького рівня і так далі. Це – процес спадного Спадне структурне програмування стало стилем написання програм і без нього навряд чи був би можливим прогрес у області розробки ПЗ. Але структурним програмам у такому вигляді не вистачало одної дуже важливої властивості – в їх структурі безпосередньо не відображалися сутності предметної області і тому програми було важко модифікувати в умовах змінення вимог. У зв’язку з цим виникла парадігма об’єктної орієнтованості, яка заснована на використанні об’єктів, що об’єднують у собі дані і функціональність.
Повторне використання компонентів
Кажуть, що Генрі Форд зробив революцію у виробництві автомобілів, коли помітив, що вузли автомобіля можна стандартизувати, так що при складанні автомобілів даної моделі можна буде використовувати будь-який екземпляр того вузла, що потрібен. Це здешевило процес складання й зробило автомобілі доступними по ціні широким верствам населення. Настільки ж важливою в цей час стає можливість при розробці одних додатків запозичити ідеї, архітектуру, проект і вихідний код інших додатків. Якщо додатки проектують таким чином, що різні їх частини можуть бути використані багаторазово, то насамкінець це призводить до зменшення вартості розробки додатків. Однак щоб це було можливим, додатки повинні бути модульними. Модульність додатка як раз і означає, що він складається з частин, що можуть бути легко ідентифіковані і модифіковані. Із цієї причини при правильному проектуванні програмного продукту особлива увага повинна приділятися модульности, особливо на стадії розробки архітектури. Модульний підхід також важливий на етапах детального проектування й реалізації. Вимоги до процесу, проекту, продукту і персоналу Ціль будь-якого програмного проекту полягає у виробництві деякого програмного продукту (наприклад, текстового редактора). Те, як у рамках проекту створюється продукт, являє собою процес. Оскільки критичним для успіху справи є взаємодія членів команди, то у розгляд включається і персонал. У сучасній практиці розробки програмного забезпечення існує п'ять ключових вимог до разробки програмного забезпечення. Перша з них - заздалегідь вибрати свою шкалу виміру якості для проекту й продукту. Наприклад, "500 рядків повністю протестованого програмного коду, написаного однією людиною за місяць" або "не більш трьох помилок на тисячу рядків програмного коду". Друга вимога полягає в зборі інформації із усіх проектів з метою створення бази для оцінки майбутніх проектів. Третє положення говорить, що всі вимоги, схеми, програмні коди й матеріали тестування повинні бути легко доступні всім членам команди. Суть четвертої умови полягає в тому, що всі учасники команди повинні дотримуватися вибраного процесу розробки. П’ята вимога у тому, що обрані показники якості повинні постійно вимірюватися і ці вимірювання повинні контролюватися.
При чому підкреслюється той факт, що нічого не можна досягнути без участі членів команди, що працює над проектом. Наприклад, створення програм тільки по проекту (пункт 4,б) – це вимога, яка може бути проконтрольованою у проекті, і яка вимагає певних зусиль з боку персоналу, що працює над проектом. Досягнення конкретних, завчасно встановлених і таких, що можуть бути виміряними, цілей – ось головна вимога до проекту і кінцевому програмному продукту. Всі п’ять вимог мають своє переломлення до конкретного проекту і всі п’ять залежать від діяльності людей. Читайте також:
|
||||||||
|