Надіслати свою хорошу роботу в базу знань просто. Використовуйте форму, розташовану нижче
Студенти, аспіранти, молоді вчені, які використовують базу знань в своє навчання і роботи, будуть вам дуже вдячні.
Розміщено на http://www.allbest.ru/
закриття проекту
1. Задачі закриття проекту
Кожен проект неминуче закінчується. Але хто з учасників проекту захоче спеціально цим займатися? Завдання виконані. Повноваження можна передавати. Кожен думає про те, що його чекає, і сподівається, що це буде новий хвилюючий проект. Тим часом ретельне управління стадією закриття не менш важливо, ніж управління будь-який інший стадією проекту. За нашими спостереженнями, компанії, які вміло здійснюють закриття і аналіз, в подальшому процвітають. Це ті компанії, які не мають проектів, що продовжуються нескінченно довго, і які не повторюють помилок.
Заключна фаза проекту включає неприємно велика кількість завдань. У минулому і на невеликих проектах обов'язком менеджера проекту було проконтролювати, щоб всі завдання були завершені і не було невирішених питань, так званих «вільних кінців». Цей підхід вже не актуальний в наші дні. Сьогодні в проектних організаціях, В яких багато проектів виконуються одночасно, відповідальність за завдання щодо закриття розподілені між менеджером проекту, проектними командами, офісами по управлінню проектами, наглядовим органом і незалежним експертом по вилученню уроків ретроспективним методом. Багато завдань накладаються один на одного, відбуваються одночасно і вимагають координації та співпраці серед зазначених сторін.
Три головні завдання закриття проекту:
1. Згортання проекту.Головне завдання щодо згортання проекту - переконатися, що проект схвалений і прийнятий замовником. Інші види діяльності щодо згортання включають: закриття рахунків, оплату рахунків, перерозподіл обладнання та персоналу, пошук нових можливостей для працівників проекту в плані подальшої роботи, закриття об'єкта і остаточний звіт. Широко використовуються запитальники (переліки) щоб ні одне із завдань в метушні не загубилося. У багатьох компаніях левову частку завдань щодо закриття в основному виконує ОУП у співпраці з менеджером проекту. Остаточний звіт пишеться одним спеціально призначеним членом ОУП, який збирає дані від всіх учасників. У менших організаціях і на невеликих проектах ці види діяльності виконуються менеджером проекту і командою.
2. Оцінка результатів (ходу проекту) і якості управління проектом.Оцінюється ефективність команди, окремих членів команди і проект-менеджера. Продавці і замовник можуть дати свої дані. Оцінка головних гравців дає важливу інформацію на майбутнє.
3. Витяг уроків ретроспективним методом.Витяг уроків повинно сприяти успіху поточних і майбутніх проектів. Сьогодні витяг уроків з ретроспективної методології здебільшого входить в компетенцію незалежного експерта. Цей експерт також забезпечує головні дані для звіту про закриття проекту, який включає отримані уроки. Ці післяпроектні укладення повинні обговорюватися командою на предмет охоплення всіх питань - не упустили чи чого.
Не всі проекти отримують чітке визначення «завершений» і здаються замовнику. Безвідносно до умов, за якими проект закінчується, сам процес закриття одноманітний, хоча підсумки можуть бути самими різними.
2. Типи закриття проекту
управління заключний проект
На деяких проектах закінчення не така певна, як сподівалися. Хоча в документі про обсяг проекту може бути чітко сформульовано закінчення проекту, фактичне закінчення може цього і не відповідати. На щастя, велика частина проектів все ж мають певне закінчення. Регулярний аналіз проектів виявляє ті з них, закінчення яких будуть відрізнятися від плану. різні типи закриттів виходячи з причин визначені нижче.
Нормальне. Найбільш поширена ситуація із закриттям проекту - просто завершений проект. Для багатьох IТ-проектів розвитку закінчення має на увазі здачу остаточного варіанту розробки у виробництво і створення нового продукту або послуги. Для інших внутрішніх IТ-проектів, таких як удосконалення (апгрейдинг) систем або створення нової системи контролю над запасами, - закінчення настає, коли результат інтегрований в поточні операції. Під час реалізації могли з'явитися деякі зміни в обсязі, витратах і графіку.
Раніше покладеного терміну. Для деяких проектів можлива така ситуація: дострокове завершення, коли деякі частини проекту виключаються. Наприклад, у проекті розвитку нового продукту менеджер з маркетингу може наполягати на виробництві моделей перед випробуваннями:
«Я повинен прямо зараз поглянути на новий продукт, навіть якщо він ще не досконалий. Ранній вихід на ринок буде означати великий прибуток! Упевнений, що ми зможемо продати величезну кількість. Якщо не зробити це зараз, іншої можливості вже може не бути! »
Цим здійснюється тиск на проект, з метою завершити його швидше і почати виробництво. Перш ніж піддатися цій формі тиску, повинні бути ретельно проаналізовані і оцінені вищим керівництвом і всіма учасниками. Наслідки і ризики, які асоціюються з цим тиском. Занадто часто переваги ілюзорні, небезпечні і несуть великі ризики.
«Вічні» проекти. Деякі проекти можуть тривати невизначено довгий час, так що люди звикають до думки, що вони «вічні». Відмітна особливість такого проекту - постійні додавання, що передбачає погано сформульований обсяг проекту. У якийсь момент група, що займається аналізом, повинна рекомендувати, як з цим покінчити або як почати новий проект. Наприклад, додавши нову функцію до старого проекту, можна замінити цілий сегмент «нескінченного» проекту.
Провальні проекти. Це проекти, які зазвичай легко ідентифікувати і після аналізу особливою групою - закрити. Однак необхідно всіма засобами повідомити іншим технічні або інші причини скасування проекту; ні при одному розкладі не можна допускати, щоб учасники проекту несли на собі почуття провини за скасований проект або щоб у них виникло почуття, що вони просто брали участь в ньому. Багато проектів закінчуються невдачею, тому що є обставини, над якими команда проекту не владна.
Зміна пріоритетів. Пріоритети компанії часто змінюються, а стратегія набуває інший напрямок. Наприклад, під час фінансової кризи 2008-2010 рр. компанії змінили пріоритет - вони перейшли від проектів для отримання прибутку до проектів по збереженню та економії коштів і зниження витрат. Група з нагляду безперервно переглядає відбір проектів відповідно до змін в напрямку розвитку компанії. Проекти, які не завершені, можуть бути замінені або скасовані. Іншими словами, проект може початися з високим пріоритетом, але його статус буде значно знижений або скасований під час життєвого циклу, у міру того як змінюються умови. Якщо змінюються пріоритети, то і проекти можуть стати непотрібними.
Проекти можуть бути скасовані з різних причин. Іноді необхідно внести деякі зміни в загальний процес закриття - під той тип скасування, з яким ви маєте справу.
3. Операції по закриттю проекту
Багато проблем для менеджера проекту і членів команди залишилися позаду. Для менеджера проекту і учасників операції зі згортання проекту, без яких не можна його завершити, часто бувають проблематичними. Це те ж саме, що запитати після вечірки: «Є добровольці зробити прибирання?» Більшість робіт рутинна і нудна. Мотивація може стати проблемою номер один. Наприклад, звіт про передачу обладнання і складання остаточних звітів виглядають «тупий» адміністративною роботою для професіоналів проекту, так як вони індивідуалісти, орієнтовані на дії. Проблема для менеджера проекту полягає в тому, щоб змусити команду все ж думати про залишилася роботі і здачі замовнику. Передавши учасникам план / графік закриття і аналізу заздалегідь, ви тим самим:
1) зробите так, що команда прийме факт, що проект рано чи пізно закінчиться, і
2) підготуєте її до переходу на інші проекти.
Ідеальний сценарій - підготувати призначення для членів команди і оголосити про це, коли проект завершений. Цим можна тонко підігріти інтерес членів в плані завершення проекту і вимагати від підлеглих дотримання термінів.
Здійснювати процес закриття слід через кілька операцій згортання. Багато компаній складають довгий список для закриття проекту - в міру накопичення досвіду. Такий список дуже допомагає гарантувати, що нічого не буде упущено в метушні. Нижче вказані шість головних операцій:
1. Отримати «добро» від замовника, що проект прийнятий.
2. «Кінець сеансу» від використовуваних ресурсів і вивільнити їх для нових проектів.
3. Оголосити про нові призначення членів команди.
4. Закрити рахунки і перевірити, чи всі рахунки оплачені.
5. Здати проект замовнику.
6. Написати заключний звіт.
Виконання всіх деталей щодо закриття проекту може здатися непосильною ношею. Деякі компанії мають контрольні переліки, що включають більше сотні пунктів! Там детально розписано, що робити з об'єктами, командами, персоналом, замовниками, продавцями і самим проектом. Фрагмент такого списку наводиться нижче (табл.).
Контрольний перелік питань щодо закриття проекту
|
Виконано чи ні (Так / Ні) |
|||
|
команда |
|||
|
Чи готовий графік розпуску персоналу проекту? Затверджено він? |
|||
|
Оголосили членам команди, що вони вільні / або отримали нове призначення? |
|||
|
Чи були зроблені оцінки роботи членів команди? |
|||
|
Чи були персоналу запропоновані послуги щодо подальшого працевлаштування та консультації по кар'єрному росту? |
|||
|
Продавці / підрядники |
|||
|
Чи був проведений аналіз роботи кожного продавця? |
|||
|
Закрили чи рахунки за проектом і чи сплачені вони? |
|||
|
Замовник / користувачі |
|||
|
Видав замовник документ з приймання продукту? |
|||
|
Чи відбулася з замовником бесіда для аналізу проекту «вглиб» і його оцінки? |
|||
|
Опитано користувачі - наскільки вони задоволені результатом? Командою проекту? Продавцями? Навчанням? Підтримкою? Технічним обслуговуванням? |
|||
|
Обладнання та об'єкти |
|||
|
Чи були ресурси за проектом передані на інші проекти? |
|||
|
Закрили чи договори з оренди обладнання? |
|||
|
Призначено чи дата для аналізу з нагоди закриття проекту і сповіщено про це учасники? |
|||
|
Позначте ті завдання, які вимагають подальшого пояснення |
4. Складання остаточного звіту
Остаточний звіт по проекту підсумовує результати проекту та дає корисну інформацію для безперервного поліпшення. Хоча остаточний звіт підігнаний під конкретну компанію, його зміст зазвичай зводиться до наступних тем: звіт про виконану роботу, аналіз, рекомендації, отримані уроки та додаток.
Звіт про виконану роботу. Цей звіт просто висвітлює ключові відкриття і факти, пов'язані з реалізацією проекту. Наприклад, були чи не були досягнуті цілі проекту щодо замовників. Чи задоволені стейкхолдери тим, що їх стратегічні наміри реалізувалися? Як зреагував користувач на якість і результати? Завдання проекту використовувалися, як було задумано, і вони дали очікувані вигоди? Остаточне час проекту, витрати і обсяг. Вказуються всі головні проблеми, з якими зіткнулися на проекті, і як ними займалися, Ключові уроки, які витягли.
Аналіз. Дані про хід проекту, ефективності керівництва і витягнутих уроках вивчаються з метою поліпшити майбутні проекти. Аналіз детально описує основні причини проблем і успіхів. Коротко робиться розбір по «фактом» - як слідували місії проекту та цілям, процедурам, як використовували ресурси компанії. Прийнято збирати дані, «побачені» компанією і командою проекту. ОУП або експерти часто використовують запитальники, щоб вибрати ті питання і події, які повинні бути розглянуті в подальшому. Наприклад: «Чи була культура компанії підтримуючої і відповідає цьому типу проекту? Чому? Чому ні? »Або:« Чи був у команди достатній доступ до ресурсів компанії - людям, бюджету, відділам, обладнання? »ОУП також представляє графіки по проекту, порівняння витрат, дані за обсягом та інші необхідні дані, за якими можна скласти« історію »результативності. Ця інформація використовується при створенні остаточного звіту за проектом.
Рекомендації. Зазвичай рекомендації - це головне, що можна зробити для поліпшення. Вони часто технічні за своєю природою і сфокусовані на вирішенні проблем, що виникли. Наприклад, щоб уникнути переробок, звіт по будівельним проектом рекомендував перейти на більш міцні будівельні матеріали. В інших випадках вони можуть включати відмову від підрядника або припинення роботи з ним.
Витяг уроків. Ймовірно, витягнуті уроки - найцінніший внесок процесу закриття. Якщо отримані дані і оцінки від стейкхолдерів, уроки повинні бути коротко і чітко сформульовані. Акцентуйте необхідність допомогти іншим на майбутніх проектах. На практиці команди нових проектів, які вивчають звіти по минулим проектам, подібним їх ненишнему, витягають чимало корисної інформації. Команди проектів пізніше часто помічають: «Рекомендації - хороша річ, але ось витягнуті уроки допомогли нам уникнути багатьох пасток і дозволили виконати проект без зривів».
Розміщено на Allbest.ru
подібні документи
Вивчення об'єктів і суб'єктів в управлінні проектів, а також їх взаємодії в процесі реалізації проекту. Методи керівництва і керівні заходи щодо забезпечення виконання проекту. Життєвий цикл проекту та його фази. Основні учасники проекту.
контрольна робота, доданий 18.02.2017
дипломна робота, доданий 21.03.2011
Сутність і вимоги до проектів у соціальній роботі. Фази життєвого циклу проекту. Аналіз створення та системи управління основними функціями проекту на прикладі проекту ГБОУ ЦВР "Раменкі". Основні шляхи ефективного впровадження соціального проекту.
курсова робота, доданий 14.11.2016
Основні завдання оцінки інноваційного проекту, збирання та аналіз відомостей про перспективність управлінських рішень, організованих в проект. Оцінка економічної ефективності проекту, ризиків, зовнішніх умов. Критерії оцінки інноваційного проекту.
доповідь, доданий 18.07.2010
Класифікація базових понять управління проектами. Відмінність проекту від виробничої системи. Життєвий цикл і фази проекту. Процеси управління проектом, виконання та контролю, аналізу. Орієнтовна команда проекту, його зовнішнє і внутрішнє оточення.
курсова робота, доданий 17.11.2013
Основні поняття і принципи управління проектами. Критичні роботи та шляхи. Розрахунок резервів часу проекту. Модифікований варіант діаграми Ганта. Створення проекту і установка параметрів. Розробка мережевого графіка проекту. Оцінка вартості проекту.
курсова робота, доданий 14.01.2011
Загальне поняття про життєвий цикл проекту. Основні процеси управління проектом. Аналіз життєвого циклу і процесів нафтогазового проекту на прикладі проекту діяльності ВАТ "ЛУКОЙЛ". Оцінка фази життєвого циклу проекту і рекомендації з управління ним.
курсова робота, доданий 13.01.2014
Визначення поняття "проект". Характеристики проекту як об'єкта управління. Функції управління проектами. Список компетенцій менеджера програмного проекту. Вироблення концепції реалізації проекту, її апробація та експертиза. Життєвий цикл проекту.
презентація, доданий 14.08.2013
курсова робота, доданий 11.11.2014
Сутність, цілі та зміст контролю ходу реалізації проекту. Характеристика методів простого і детального контролю. Основні стадії зміни змісту проекту. Можливі варіанти дій, які використовуються в разі відхилення проекту від наміченого плану.
У житті кожної людини час від часу виникають ситуації, коли все заплановане навіть самим ретельним чином йде зовсім не так, як було спочатку задумано. Саме в такі моменти, як то кажуть, опускаються руки, хочеться все кинути і забути про намічених планах і. Але чи варто вважати свої помилки, промахи і невдачі такими фатальними?
Однією з головних причин нашого негативного ставлення до помилок і невдач є те, що ще з дитинства багатьом з нас прищеплювали прагнення бути кращими, яка має на увазі: якщо робити щось, то робити найкращим чином, або не робити взагалі. Подібні настанови, звичайно, хороші, але нерідко в процесі дорослішання людини вони трансформуються з цілком розумною позиції «сім разів відміряти і один раз відрізати» в своєрідну патологію, вкрай негативно впливає на життя людини. У підсумку виходить, що, стаючи дорослими, деякі з нас дуже болісно ставляться до будь-яких невдач, намагаються відразу ж про них забути і усунути зі свого життя все, що може про них нагадати.
Однак завжди потрібно брати до уваги те, що будь-який, навіть самий провальний проект може містити в собі чудові покажчики на зміну руху в тому чи іншому потрібному напрямку. Але для розуміння цього потрібно сформувати в собі правильне ставлення до своїх невдач.
Вчіться робити розумні помилки
Як такі, помилки можна розділити на дві категорії: є дурні помилки - це помилки, які відбуваються людьми через халатне ставлення до чого-небудь або безпечності. А є помилки розумні - вони відбуваються в разі, коли людина йде на усвідомлений ризик або проводить будь-якої.
Вчинення таких помилок є чудовим «робочим» матеріалом і їжею для розуму. У багатьох випадках це говорить про те, що людина розвивається і вміє ризикувати заради досягнення мети. Саме в цьому випадку підхід до вилучення уроків з невдач є здоровим, адже людина вже з самого початку орієнтований на активну роботу над собою і своїми діями. Не буде зайвим сказати і те, що для досягнення видатних результатів потрібно здійснювати видатні вчинки. Не потрібно боятися експериментувати і реалізовувати нові стратегії.
Витягнуті з помилок уроки потрібно обов'язково застосовувати на практиці
Будь-яка помилка як така має бути здійснена тільки один раз, тому що один лише її факт уже мав би чогось навчити. А це означає, що якщо дія було скоєно неправильно, то потрібно зробити будь-які зміни. Але щоб ці зміни вступили в силу і справили новий ефект, потрібно брати до уваги минулий досвід - тільки так відбувається навчання. Є навіть такі уроки, отримати які ніяким іншим способом, крім здійснення помилки, взагалі не представляється можливим. Тому, якщо розглядати помилки і невдачі з позиції навчання, то вони є чудовими «вчителями».
Дуже важливим є також і те, що вчинення помилок повинно безпосередньо впливати на вироблення нового. Але величезна кількість людей просто забуває про витягнутих уроках. І далеко не всі будують всю свою подальшу діяльність з їх урахуванням. І, незважаючи на те, що це здається цілком логічним (робити висновки і здійснювати нові дії) і адекватним, в більшості випадків люди лише індульгіруют, займаються самобичуванням і «планують» зайнятися розбором своїх же польотів коли-небудь потім. Це і є прекрасним поясненням того, що багато так ні чого й не навчаються на своїх помилках.
На додаток до цього можна сказати, що якщо попросити людину пояснити, який урок він виніс зі своєї помилки, то, цілком ймовірно, він зможе зробити це з завидною завзяттям. Але от якщо попросити його вже про те, щоб він надав новий план дій, заснований на витягнутих зі своїх невдач уроках, то, швидше за все, він просто округлити очі і потисне плечима. Далеко нерідкі випадки, коли люди просторікують про те, як можна легко і просто змінити наявний стан, але все слова так і залишаються лише словами, адже нові знання просто не використовуються.
І ще одним серйозним моментом є те, що у деяких людей є схильність до того, щоб закривати на помилки очі або просто перекладати провину за їх вчинення на інших. І тут важливо зрозуміти, що така поведінка найгірше впливає, в першу чергу, на самого його ініціатора. Закривати на помилки очі значить свідомо стояти на одному і тому ж місці, абсолютно не просуваючись уперед. А перекладати провину на інших - це аналогічне стояння на місці, доповнене невмінням або небажанням бути відповідальним за себе, свої вчинки і, врешті-решт, за своє життя.
Вчіться на помилках інших
У наш час існує величезна кількість матеріалів, присвячених опису життя і діяльності відомих і успішних людей. Найбільш неординарних результатів домагалися люди, які не мали якимись сврехспособностямі, але ті, хто здійснював найбільшу кількість помилок і ті, хто навчався на них. Про це говорили такі люди як Томас Едісон, Йоганн Вольфганг Гете, Михайло Ломоносов, Володимир Ленін, Франсуа де Ларошфуко, Максим Горький, Лев Толстой, Аристотель, Конфуцій та інші видатні особистості.
Так навіть якщо і не звертатися до сторонніх джерел, можна побачити сотні прикладів того, що і як варто робити і чого і як робити не варто. Це можуть бути родичі, друзі, знайомі, колеги по роботі. Потрібно тільки не бути сліпим до того, що відбувається і вчитися використовувати чужий досвід.
Резюмуючи все вищевикладене, можна привести ряд прийомів, які дозволять отримувати від помилок і невдач виключно користь:
- Якщо вас спіткала невдача, замість того щоб обурюватися з цього приводу, потрібно максимально об'єктивно подивитися на речі і постаратися зрозуміти, що ж сталося насправді. Найчастіше заважають нам бачити реальний стан речей.
- Якщо вас спіткала невдача, потрібно думати не про те, що сталося в результаті, а про те, що послужило причиною цього: які ваші думки, переконання і дії направили вас на неправильний шлях.
- Знайшовши причину своєї невдачі, обов'язково врахуйте це. Усвідомте, що це всього лише ще один спосіб того, як робити не треба, і надалі так не робіть.
- Завжди потрібно намагатися і зберігати тверезий погляд на речі. Зайва емоційність спотворює суть речей і не дозволяє приймати вірні рішення.
- Ні в якому разі не потрібно займатися самобичуванням і самокопанієм. Якщо помилка зроблена, значить, так тому і бути, і так повинно було статися. Намагайтеся виробляти філософський погляд на речі.
- Завжди пам'ятайте про те, що кожна помилка - це нова можливість, яка дає вам унікальний шанс. Дуже рідко вдається передбачити абсолютно все. Ми - люди, а людям властиво помилятися.
- Звертайте увагу на те, що роблять інші люди і використовуйте їх досвід в своїх цілях. Вчіться на чужих помилках і зможете уникнути своїх власних.
- Пам'ятайте, що неможливо домогтися нового результату, постійно здійснюючи одні й ті ж дії. Шукайте нові способи.
Задумайтесь на дозвіллі над тим, що саме невдачі є загартуванням вашого характеру і волі, а також уміння досягати поставлених цілей навіть тоді, коли здається, що весь світ проти вас. Абсолютно неважливо, скільки помилок ви зробите на своєму шляху до успіху. Важливим є те, що кожна нова помилка наближатиме вас до нього. Та й той, хто жодного разу не помилявся і не відчував гіркоту поразки, ніколи не зможе по-справжньому насолодитися успіхом і перемогою.
Тому, не потрібно нескінченно обмірковувати свій невдалий досвід. Просто аналізуйте свої дії, виймайте уроки, робіть відповідні висновки і ніколи не бійтеся нових невдач. Не дозволяйте своїм помилкам зробити вас їх жертвою. Не існує ідеальних людей. І не помиляється ніколи лише та людина, яка нічого не робить.
І наостанок невелика напуття:
«Пам'ятай, що змінити свою думку і дотримуватися того, що виправляє твою помилку, більш відповідає свободі, ніж наполегливість у своїй помилці»
Марк Аврелій
Захистимо майбутнє,
витягуючи уроки з минулого
УРОКИ, ДОБУТІ З АВАРІЇ
|
Дата події: |
Заходи щодо локалізації та усунення причин аварії: Провести позачергову перевірку знань керівників, фахівців і робітників ЗАТ «КапіталАгро». Укомплектувати штат газової служби фахівцями. Провести позачергові інструктажі обхідників, операторів виробничої котельні. Витягнуті уроки: Неприпустимо відхилення від проектних рішень при виконанні будівельних робіт на об'єктах мереж газорозподілу і газоспоживання. Штат підприємства необхідно укомплектовувати навченим і атестованим персоналом.
|
|
|
Найменування організації: |
ВАТ «КапіталАгро» |
|
|
відомча приналежність: |
||
|
Місцеаварії: |
Газопровід на вводі в будинок механічного очищення стоків і повітродувної |
|
|
вид аварії: |
викид небезпечних речовин, вибух, руйнування споруд |
|
|
Короткий опис аварії: В результаті руйнування підземного газопроводу в приміщенні електрощитової будівлі механічного очищення стоків стався вибух газу, що надійшов в приміщення по підземних комунікацій. Наслідки аварії: (В т.ч. наявність постраждалих, збиток) В результаті вибуху зруйновано зовнішня стіна приміщення щитової і пошкоджена частина кабелів. Травмований один робочий. Економічні збитки становить 226 000 руб. 1. Технічні причини аварії: 1.1. Руйнування труби нероз'ємного з'єднання сталь-поліетилен через утворення дефекту у вигляді розшарування на внутрішній поверхні поліетиленовою труби.Урокі самозцілення, витягнуті з досвіду роботи хірурга з винятковими ... врятувати вас від автомобільної аварії, А людина, що зупиняється, ... Сполучених Штатах, де сталася аварія на атомній електростанції. В цьому... Урок № Тема: «Азбука дорожньої безпеки»урокІсторія появи автомобіля. матеріали до уроку1. Історія виникнення і еволюція ... причини порушень, що призводять до аварій. Мають значення і багато ... ситуацію і приступити до вилучення потерпілого з-під коліс, з кабіни і т.п. Робити ... Урок № Тема: «Історія розвитку автомототранспорту»уроклюдей при аваріях, А так само і самих аварій виробники автомобілів ... оцінити ситуацію і приступити до вилучення потерпілого з-під коліс, з кабіни і т. п. Робити це ... причина ДТП? урок № 9. Тема: «Залікова урок»Мета уроку: Повторення пройденого ... Станіслав Лем Фантастика і футурологія Книга 2оглядБіологи врахували при її конструюванні уроки, витягнуті з помилок природи, коли вона ... з сталактитових голок під час аварії, - це знову деяке скорочення і ... мінімуму надлишку, зрозуміло, помилково; аварії, Викликані вичерпанням запасів реактивного палива ... | ||
Ось список правил по розробці ПО, які я вивів для себе за роки практики.
Розробка
1. Починайте з невеликих речей, потім розширюйте їх.
Як при створенні чогось нового, так і при додаванні функціональності до готовим системам, я завжди починаю з дуже простої версії, що не робить майже нічого з необхідних функцій. Потім я розширюю це рішення крок за кроком, до тих пір поки воно не стане тим, що було заявлено спочатку. У мене ще ніколи не виходило розписати в плані всі деталі вже на старті. Замість цього, я все краще і краще розумію те, що потрібно отримати в процесі розробки і використовую ці знання в проекті.
Мені подобаються ці слова Джона Галла: «Будь-яка досить складна система, яка працює, так чи інакше свого часу еволюціонувала з простої системи, яка працювала».
2. Змінюйте щось одне за один раз.
Якщо при розробці програма починає провалюватися на якомусь тесті або деяка функція перестає працювати, то набагато простіше знайти причину, якщо ви поміняли код тільки в одному місці. Іншими словами, краще використовувати невеликі ітерації, ніж намагатися зробити все і відразу. Зробіть щось одне, переконайтеся, що це працює, повторіть.
Це також може бути застосовано і на рівні коммітов в систему контролю версій. Якщо вам треба провести рефакторинг, то перш ніж додати якусь нову фічу, спочатку зафіксуйте зміни для рефакторинга, а тільки потім (окремим коммітов) додайте цю фічу.
3. Додавайте логирование і обробку помилок на ранніх стадіях.
Коли я беруся за розробку нової системи, одна з перших речей, яку я роблю - це додавання логування та обробки помилок. Обидві ці речі приносять користь з самого початку роботи над проектом. У будь-якій програмі, яка більше пари десятків рядків коду, вам потрібно знати, що відбувається в процесі виконання. І особливо ці дані важливі тоді, коли щось працює не так, як було заплановано.
Приблизно те ж саме і з обробкою помилок - якщо вже винятків все одно не уникнути, і вони будуть кидатися на протязі всього життя проекту, то чому б не почати обробляти їх систематично вже на самому початку?
4. Кожна нова строчка коду повинна бути виконана хоча б один раз.
Перш ніж закінчити роботу по будь-якої функціональної можливості, її потрібно протестувати. Адже інакше як ви зрозумієте, що вона робить саме те, що повинна? часто кращий варіант для цього - автоматичні тести, хоча бувають і інші варіанти. В цілому не важливо як, але головне, що управління має отримати кожна написана вами рядок коду.
Іноді може бути складно відтворити необхідні умови, щоб зайти в усі гілки коду. На щастя, у вас є можливість трохи смухлевать, не обов'язково намагатися відтворювати повністю бойові умови. Наприклад, вилов помилок бази даних можна перевірити спеціально припустившись помилки в написанні назви колонки. Або можна тимчасово инвертировать умова всередині if, тоді випадок «помилка сталася» поміняється місцями з «все пройшло коректно». Це корисно для помилок, які в принципі відбуваються дуже рідко і їх складно зімітувати.
Іноді мені трапляються баги, які показують, що певна рядок коду взагалі ніколи не повинна працювати. Вона може виглядати цілком нормально зовні, під час code-review, але все одно не працювати так, як повинна. Ви уникнете таких ситуацій, якщо приймете за правило завжди виконувати хоча б один раз кожну нову рядок.
5. Тестируйте по частинах перш, ніж перевіряти весь проект на працездатність.
Чим ретельніше ви протестуєте окремі складові, тим більше часу заощадите. Часто можна зіткнутися з проблемою налагодження взаємодії між окремими компонентами. І якщо ви будете впевнені в тому, що кожен з них працює коректно, ви зможете приділити достатньо часу вирішенню цього завдання.
6. Абсолютно все займає більше часу, ніж ви думаєте.
Особливо в програмуванні. Оцінити, скільки часу піде на реалізацію того чи іншого завдання, дійсно важко, навіть якщо все йде гладко. Але коли мова йде про розробку ПО, необхідно брати до уваги той факт, що можуть виникнути несподівані проблеми: в найпростіше злиття може закрастися баг, оновлення фреймворка викличе необхідність змінити деякі функції, або виклик API дасть непередбачуваний або невірний результат.
Схоже старий Хофштадтера мав рацію, коли формулював свій закон: «На будь-яку справу потрібно більше часу, ніж здавалося на початку, навіть якщо ви враховували при цьому закон Хофштадтера».
7. Спочатку зрозумійте, що робить даний код.
Здебільшого програмування має на увазі зміна існуючого коду. Навіть якщо ви включили в проект щось зовсім нове, це нове повинно стати частиною написаного коду. Більш того, необхідно зрозуміти знайдене рішення перш, ніж додавати його. Інакше ви можете порушити працездатність чогось, що вже було реалізовано. Тому вміння читати код так само важливо, як уміння його писати. І це ще одна причина, чому начебто просте завдання по врахуванню коду може зайняти більше часу, ніж здається: потрібно розуміти контекст, в якому відбуваються зміни.
8. Читайте і запускайте код.
На щастя, є два методи розуміння коду, які відмінно доповнюють один одного. Ви можете читати код і ви можете дивитися, що відбувається коли він виконується. Запуск на виконання може непогано вам допомогти в розумінні того, для чого цей код був написаний. Але переконайтеся, що ви використовуєте обидва підходи.
налагодження
9. Помилки будуть завжди.
Мені не дуже подобається підхід «Зробити все з першого разу». Не має значення, скільки зусиль ви витратите, помилки будуть все одно ( «Ми про це не подумали ...»). Набагато продуктивніше запустити додаток і виправляти баги в міру надходження.
10. Реагуйте на звіти про помилки.
Кожен розробник повинен витрачати частину свого часу на розбір звітів про помилки та їх виправлення. Це дає більш глибоке розуміння того, як працює система, чого від неї чекають клієнти, наскільки складно підтримувати систему. Крім того, це відмінний спосіб відчути відповідальність за свою розробку. Не упускайте цю можливість.
11. Відтворення проблему.
Першим кроком по виправленню будь-якого бага має бути вопроизведение помилки. Тоді ви можете бути впевнені, що, коли ви виправите програму, помилка зникне. Це просте правило допоможе вам уникнути ситуації, коли ви припускаєте проблему там, де її немає, і переконатися, що рішення буде працювати.
Іноді є кілька проблем, про які ви знаєте. Різні помилки можуть взаємодіяти один з одним і викликати дивну поведінку. Замість того, щоб шукати причину такої поведінки, виправте відомі помилки і перевірте, чи залишилися симптоми.
13. Співпадінь не буває.
Не вірте в збіги, коли займаєтеся тестуванням або налагодженням. Ви поміняли значення таймера, і система стала перезавантажуватися частіше? Це не збіг. Ви додали нову функціональність, і інша функція стала працювати повільніше? Досліджуйте!
14. Враховуйте тимчасові мітки.
Використовуйте їх при налагодженні, дивіться на взаімосвязь.К наприклад, якщо приблизно за 3000 мс до того, як система перезапустити, був відправлений запит, можливо таймер запустив будь-які дії, які призвели до перезапуску.
співробітництво
15. Найефективніша комунікація - лицем до лиця.
Живий діалог не замінять відеоконференції, чат, дзвінок або електронна пошта. Дивно, наскільки краще стають ідеї і рішення, якщо обговорити їх з колегами.
16. Гумовий каченя.
Якщо ви зіткнулися з труднощами, ви можете піти до колеги і розповісти йому про свою проблему. Найчастіше, в процесі пояснення, ви самі прийдете до рішення, навіть якщо колега не сказав ні слова. Звучить як магія, але працює досить часто.
17. Запитуйте.
Читання і запуск коду - відмінний спосіб зрозуміти, як він працює. Але якщо у вас є можливість запитати кого-небудь компетентного (автора програми, наприклад), використовуйте її. Можливість поставити запитання і отримати на нього відповідь, а потім, виходячи з відповіді задати додаткові питання, дозволить вам отримати інформацію за кілька хвилин замість кількох днів.
18. Визнайте заслуги інших.
Говоріть, напимер: «Маркусу прийшла в голову чудова ідея ...», замість: «ми спробували ...». Намагайтеся згадати всіх, хто вам допоміг.
Різне
19. Експериментуйте.
Якщо ви не впевнені, як працює та чи інша особливість мови, ви можете просто написати маленьку програму, яка продемонструє це на прикладі. Той же самий метод можна застосовувати і коли ви тестируете складну систему. Що трапиться, якщо я передам -1 як аргумент? А чи не впаде сервіс, коли я перезавантажений машину? Досліджуйте, як що працює - ви напевно виявите якісь помилки, і крім того, глибше зрозумієте систему.
20. Поспите.
Якщо ви працюєте над складним завданням або зіткнулися з проблемою, спробуйте поспати, перш ніж приймати рішення. Ваше підсвідомість все одно працює над вирішенням, навіть якщо ви не думаєте про нього. У підсумку, на ранок ви легко знайдете відповідь, який здасться вам очевидним.
21. Міняйтеся.
Не бійтеся пробувати себе на різних ролях час від часу. Робота з різними людьми, різними продуктами, в різних компаніях стимулює. Багато людей рік за роком сидять на одній і тій же роботі, змінюючи щось у своєму житті тільки під впливом зовнішніх обставин.
Часто задається питання: а чи навчаються наші діти?
Джордж Буш $ мл., Флоренс, Південна Кароліна, 11 січня 2000 року
Сподіваємося, що до цього моменту нам вже вдалося з достатньою ясно $ стю показати, що таке фаззінга, чому він ефективний і як його застосовувати для виявлення прихованих помилок в програмному коді. Ми чесно попереджали заздалегідь, що ця книга спрямована на целе $ ву аудиторію перш за все трьох категорій: розробників, контро $ леров якості і дослідників безпеки. В цьому розділі рассмот $ рим життєвий цикл розробки ПЗ (SDLC, software development life $ cycle) і визначимо, як представники кожної з цих категорій мо $ жет використовувати фаззінга для розробки безпечного програмного забезпечення.
Життєвий цикл розробки ПЗ
Коли $ то технологія фаззінга використовувалася виключно дослі $ дователей безпеки вже після затвердження розробленого про $ продуктом, але зараз розробники навчилися широко застосовувати фаззінга для виявлення вразливостей раніше, під час SDLC. Microsoft прий $ ла фаззінга як ключовий компонент Trustworthy Computing Security Development Lifecycle (життєвого циклу розробки безпеки комп'ютеризації, що заслуговує на довіру) .1 Ця методологія в від $
1 http://msdn.microsoft.com/library/default.asp?url=/library/en+us/dnsecure/
криту пропонує розробникам «застосовувати засоби тестування безпеки, в тому числі інструменти фаззінга», під час фази осу $ ществления проекту, що називається життєвим циклом розвитку без $ пасности (Security Development Lifecycle, SDL). Microsoft розробила ідею SDL, яка відображає фази їх власного SDLC; обидва ці цик $ ла показані на рис. 25.1.
списки функцій | специфікації | ||
якість | Тестування і верифікація |
||
Основні | |||
принципи | Розробка нового коду | ||
архітектура | функціональні | ||
Виправлення помилок |
|||
документація | специфікації | ||
вимоги | планування | Реалізація | верифікація |
тестування безпеки
Обробка програмного переривання | образциЛучшіе планування безпеки | безпечний | вико | створення | планаПодготовка | звіту безпеки | остаточний |
||
програм | і програм | ||||||||
аналізатакі | документації | ||||||||
простору | |||||||||
безпеки | |||||||||
моделювання безпеки | для продукту | ||||||||
тестування | |||||||||
Сервісні
підтримки
продукту та оновлення безпеки
Підтримка і технічне обслуговування
обслуговування
безпеки
і обробка
Мал. 25.1. SDLC і SDL компанії Microsoft
За цим паралельним процесам можна зрозуміти, що Microsoft дійшла до ідеї контролю безпеки під час кожної фази SDLC. Це важ $ ве визнання тієї ролі, яку має відігравати безпеку на про $ тяженіі всього SDLC. Також потрібно пам'ятати про які знайшли відображення на цих діаграмах необхідності вплетення безпеки в тканину SDLC, а не просто про паралелізації процесів. Розробники, контролери якості і дослідники безпеки повинні працювати спільно і до $ ордініровать свої зусилля для досягнення спільної мети - створення безпечного коду.
У методології SDLC не бракує, але для наших цілей використовуємо оригінальну модель водоспаду Вінстона Ройса (Winston Royce) 1 з $ за
1 http://en.wikipedia.org/wiki/Waterfall_process
її простоти і широти застосування. Модель водоспаду використовує по $ отже підхід до розробки ПЗ: життєвий цикл разработ $ ки складається з п'яти фаз. Цей підхід проілюстровано на рис. 25.2.
Тепер розглянемо питання застосування фаззінга на кожній з цих стадій.
Підхід Microsoft до безпеки
Немає нічого несподіваного в тому, що Microsoft широко впроваджує безпеку в свій SDLC. Технології Microsoft домінують на ринку і, отже, часто піддаються перевірці на без $ небезпека. Хоча існують сумніви з приводу того, що у Mi $ crosoft великі перспективи на фронті безпеки, не можна від $ Ріца, що корпорація вже зробила серйозні кроки в цьому напрямку.
Візьмемо, наприклад, Microsoft Internet Information Services (IIS) 1, веб $ сервер Microsoft. В даний час загальновідомі 14 вразливий $ мостей у версії 5.x.2 Версія же 6.x, випущена ще на початку 2003 року, має всього три відомі ошібкі3, жодну з кото $ яких не можна вважати критичною.
Покращення в області безпеки частково пов'язані з вдосконалення $ шенствованию безпеки нижнього рівня - перевіркою буфе $ ра / GS4, запобіганням виконання даних (Data Execution Prevention, DEP) і безпечної структурної обробкою исключе $ ний (Safe Structured Exception Handling, SafeSEH) 5; а одне з са $ мих довгоочікуваних удосконалень в Windows Vista - ран $ домізація компонування адресного простору (Address Space Layout Randomization, ASLR) .6 Додатково до цього Microsoft при $ вабила до роботи над проблемами безпеки і людські ре $ сурси, запустивши такі програми, як Secure Windows Initia $ tive.7 фаззінга - одна з багатьох технологій, що використовуються з $ трудниками цього підрозділу для вдосконалення без $ пасности, зниження якої можна спостерігати зараз.
Глава 25. Витягнуті уроки
вимоги
планування
Реалізація
верифікація
Технічне обслуговування
Мал. 25.2. Оригінальна модель водоспаду Ройса
аналіз
Фаза аналізу включає в себе збір інформації, яку необхідно вивчити перед початком проекту. Ця фаза передбачає і роботу з ко $ кінцевого користувачами - адже потрібно дізнатися, що вони хочуть підлозі $ чить. Хоча в цій фазі SDLC фаззінга і не з'являється безпосередньо, раз $ работчікам, контролерам якості і дослідникам безпеки важливо вже зараз почати роздумувати про те, чи буде він відповідним способом тестування на більш пізніх стадіях.
планування
Планування програми - це створення абстрактного представле $ ня про проект. Ця фаза може включати різні технології моделює $ вання в залежності від модельованого рішення - обладнання це, програма або компоненти бази даних. На цій стадії беруть $ ся рішення про мови програмування і програмних бібліотеках, які будуть задіяні в процесі кодування.
Коли всі рішення прийняті, в центрі уваги опиняються здійснювала $ вімость фаззінга і можливі підходи до нього. На цій стадії визна $ деляются дві найважливіші деталі, від яких залежить загальний підхід. Спочатку вирішується, які програмні і апаратні платформи бу $ дуть задіяні. Це вплине на те, які інструменти і класи фаззінга будуть використані. Наприклад, якщо ваш проект - це кін $ сольний додаток для Linux, підійде фаззінга змінної середовища. Якщо проект повинен працювати під Windows, чи будуть в ньому елементи управління ActiveX, помічені як безпечні для скриптинга і проявляють свої функції на зовнішніх веб $ сайтах? Якщо так, то повинен бути застосований фаззінга COM $ об'єктів.
Мережеві протоколи для межпроцессной комунікацій зазвичай вибі $ раются якраз на цій стадії SDLC. Якщо, наприклад, одним з требо $
