Тема 1. Введення в програмну інженерію

Підготували

студенти груп СН-II

Палка Олег і Дубчак Андрій

Історія та основні поняттяВідмінності програмної інженерії від інших галузейЕволюція підходів до управління програмними проектамиМоделі процесу розробки ПЗ та їх вибірЯк діяти, щоб програмний проект був успішним ?Підіб’ємо підсумки

Історія та основні поняття

IT-проекти

Програмна інженерія

Програмне забезпечення

(ПЗ)

Програмнийпродукт (ПП)

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

Мистецтво

Наука

Бізнес

Історія та основні поняття

Професійне програмування

Професійний програміст

Професійний програміст

vs.Професіонал

Якість ПП

ПП

Процес розробки і його модель ПЗ

ПЗ

ПЗ чи ПП?

• IT-проекти – це проекти в галузі інформаційних технологій. Далі розглядатимемо лише ті IT-проекти, метою яких є розробка програмного забезпечення.

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

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

• Програмне забезпечення (ПЗ, Software) – це набір комп'ютерних програм, процедур і пов'язаної з ними документації і даних (ISO/IEC 12207).

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

Короткий конспект

Відмінності програмної інженерії від інших галузей

“Хаос”

Хто винен ?

Що робити ?

Люди Бюджет Принципи

Творчість

Абстрактне мислення

Системне мислення

Маніакальна старанність

Пізнання новинок у IT

“ Програміст повинен володіти …”

• Доповідь “Хаос”: 35% проектів – завершилися в термін – успіх; 46% проектів – завершилися з запізненням – невдача; 19% проектів – повністю провалилися – провал.• Найчастіше витрати на створення ПЗ такі: 60% – розробка; 40% – тестування;• Творчість – це інтелектуальна діяльність людини, закони якої нам

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

• Програмування – це проектування і тільки проектування. Роль конструкторського бюро для програмного проекту виконують компілятор і збірник програм.

• «Менеджери програмних проектів зможуть добитися більшого, якщо будуть застосовувати методи управління, характерні для кіноіндустрії».

Короткий конспект

Еволюція підходів до управління програмними проектами

Моделі розробки ПЗ:

“Як вийде” “Водоспад” “Гнучке управління” “Метод чистих поставок”

Розімкнена система управління Жорстке управління

зі зворотним зв'язком

Розрахунок опорної траєкторії,

вимірювання відхилень,

розрахунок нової траєкторії і корекція

для виходу на неї

СамонаведенняПовна довіра технічним

лідерам

Представники не бере участь в проекті

Розрахунок опорної траєкторії (план

проекту), вимірювання

відхилень, корекція і повернення на

опорну траєкторію

Розрахунок опорної траєкторії,

вимірювання відхилень, уточнення

мети, розрахунок нової траєкторії і

корекція для виходу на неї

Планування неформальне і словесне

«Плани - ніщо, планування - все»

(Ейзенхауер, Дуайт Девід)

Час і бюджет, як правило, не контролюються

Аналогія: балістичний політ без зворотного зв'язку. Можна, але недалеко і неточно

Краще, але не ефективно

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

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

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

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

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

Короткий конспект

Моделі процесу розробки ПЗ

Вибір моделі процесу розробки ПЗВага моделі Переваги Недоліки

«Важкі» методи

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

Наявність кваліфікованих керівників проекту. Великі затрати на проектування та аналіз проекту. Бюрократизація процесу роботу.

«Легкі» методи

Зменшення затрат на проектування та аналіз проекту. Виділення більшості часу на роботу над проектом. Робота не розподілена по ролях. Неформальні комунікації

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

Вибір моделі процесу та досягнення успіху в проекті

1. Ставимо цілі

a) Всі члени команди вважають концепцію реалістичною. b) У проекту є обгрунтування економічної ефективності. c) Розроблено прототип користувальницького інтерфейсу. d) Розроблена специфікація цільових функцій програмного продукту. e) З кінцевими користувачами продукту налагоджена двосторонній

зв'язок

2. Визначаємо спосіб досягнення цілей

a) Є детальний письмовий план розробки продукту. b) У список завдань проекту включені «другорядні» завдання

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

c) Після кожної фази проекту оновлюється розклад і бюджет. d) Архітектура та проектні рішення документовані. e) Є план забезпечення якості, що визначає тестування і рецензування. f) Визначено план багатоетапної поставки продукту. g) У плані враховані навчання, вихідні, відпустки, лікарняні. h) План проекту та розклад схвалений всіма учасниками команди.

3. Контролюємо і управляємо реалізацією

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

b) У проекту є менеджер, причому тільки один! c) У плані проекту визначені «бінарні» контрольні точки. d) Всі зацікавлені сторони можуть отримати необхідну інформацію

про хід проекту. e) Між керівництвом та розробниками встановлені довірчі відносини. f) Встановлена процедура управління змінами в проекті. g) Визначені особи, відповідальні за рішення про прийняття змін у

проекті. h) План, розклад і статусна інформація по проекту доступна кожному

учаснику. i) Код системи проходить автоматичне рецензування. j) Застосовується система управління дефектами.

4. Аналізуємо загрози

a) Є список ризиків проекту. Здійснюється його регулярний аналіз та оновлення.

b) Керівник проекту відстежує виникнення нових ризиків. c) Для кожного підрядника визначено особу, відповідальну за роботу з

ним.

5. Працюємо над створенням команди

a) Досвід команди достатній для виконання проекту. b) У команди достатня компетенція в прикладній області. c) У проекті мається технічний лідер. d) Чисельність персоналу достатня. e) У команди є достатня згуртованість. f) Всі учасники прихильні проекту.

0 - навіть не чули про це; 1 - чули, але поки не застосовуємо; 2 - застосовується частково; 3 - застосовується в повній мірі.

Поправочні коефіцієнти:

для малих проектів (до 5 осіб) - 1.5; для середніх (від 5 до 20 чоловік) - 1.25.

Результат:

< 40 - завершення проекту сумнівно. 40-59 - середній результат.

В ході проекту слід очікувати серйозні проблеми.

60-79 - хороший результат. Проект, швидше за все, буде успішним. 80-89 - відмінний результат. Імовірність успіху висока. > 90 - чудовий результат. 100% шансів на успіх.

Система оцінювання:

Тест Стів Макконнелла для визначення успішності проекту

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

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

• Щоб програмний проект став успішним, необхідно: Чітко ставити цілі; Визначати спосіб досягнення цілей; Контролювати і управляти реалізацією; Аналізувати загрози і протидіяти їм; Створювати команду.

Підіб’ємо підсумки