26. Документація по супроводу програмних засобів.

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

Документація по супроводу ПЗ можна розбити на дві групи:

(1) документація, що визначає будову програм і структур даних ПЗ і технологію їх розробки;

(2) документацію, що допомагає вносити зміни до ПЗ.

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

- Зовнішній опис ПЗ (Requirements document).

- Опис архітектури ПЗ (description of the system architecture), включаючи зовнішню специфікацію кожної її програми.

- Для кожної програми ПЗ - опис її модульної структури, включаючи зовнішню специфікацію кожного включеного в неї модуля.

- Для кожного модуля - його специфікація і опис його будови (design description).

- Тексти модулів на вибраній мові програмування (program source code listings).

- Документи встановлення достовірності ПЗ (validation documents), що описують, як встановлювалася достовірність кожної програми ПЗ і як інформація про встановлення достовірності зв'язувалася з вимогами до ПЗ.

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

Документація другої групи містить

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

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

27. Людський чинник в управлінні проектами. Завдання n-личностей. Закон Брукса. Підходи до управління групами і керівництва ними.

ІТ-МЕНЕДЖЕРИ часто забувають про вплив людського чинника на вирішення технічних завдань. Не залишайте без уваги членів проектної групи і покладайте на них обгрунтовані надії.

Керівництво групою: завдання ІТ-МЕНЕДЖЕРОВ

Людський чинник - один з найважливіших в управлінні ІТ-ПРОЄКТАМІ, але часто його ігнорують. Джон Макдоналд, глава компанії Macdonald Dettwiler and Associates, в своїй доповіді "Мистецтво і наука системної інженерії в міжнародному контексті", зробленому на симпозіумі Incose в 1998 році, відмітив, що успіх проекту безпосередньо пов'язаний з використовуваними талантами, і, що важливіше, способом, відповідно до якого керівництво використовує ці таланти в проекті.

Проте ІТ-МЕНЕДЖЕРИ часто рахують себе всього лише технічними керівниками, забуваючи про те, як людський чинник впливає на вирішення технічних завдань. "ІТ-менеджером" я називаю будь-яку людину, керівну розробкою, управлінням, установкою, підтримкою або обслуговуванням ІТ-СИСТЕМ і програмного забезпечення, в яких бере участь група людей. Іноді такого фахівця називають менеджером програмного проекту, ІТ-керівником, ведучим ІТ-розробником і так далі

До керівництва ІТ-СПЕЦИАЛІСТАМІ застосовні багато аспектів теорії управління. Ми обговоримо деякі стилі управління, але головне, про що слід пам'ятати, що незалежно від того, який стиль або комбінацію стилів ви виберете, покладайте лише обгрунтовані надії і прагніть приділяти увагу всім членам команди.

Людський чинник управління проектом

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

Завдання n осіб

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

Мал. 1. Кількість робочих зв'язків швидко збільшується із зростанням числа членів проектної групи

Висока вірогідність того, що при збільшенні кількості чоловік багато зв'язків будуть неефективними. Це пояснює закон Брукса:

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

Не можна формувати групи, ігноруючи лічносиниє стосунки.

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

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

Теорія Y (Макгрегор)

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

Менеджерові, що діє згідно Теорії Y, просто потрібно надати ресурси, визначити цілі і більше не втручатися в роботу групи

Теорія Z

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

Теорія Z припускає наявність внутрішнього механізму управління. Додаткову дію надають культурні норми конкретної корпорації. Японські компанії відомі своїм колективним ухваленням рішень і відповідальністю на всіх рівнях компанії.

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

Теорія W

Для кожного проекту, згідно Теорії W, слід створювати взаємовигідні умови, формувати такий же процес і проводити взаємовигідний продукт.

Взаємовигідні умови.- це ті, виграш від яких може отримати кожен:

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

2. Формувати розумні надії. Необхідно створювати розумні і взаємно здійсненні очікування в кожному аспекті людських відносин.

3. Сприяти спілкуванню. Створити атмосферу, що підтримує виграшні для співробітників умови

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

Висновок: зі всіх теорій найбільш підходить Теорія W.