6. Розвиток компанії по розробці програмного забезпечення

Існує п'ять рівнів процесу розробки ПЗ:

• Початковий рівень. На цьому рівні немає ніяких стандартів. Рішення ухвалюються непродумано. Цей рівень може спостерігатися в старих компаніях.

• Рівень копіювання. Підприємства діють так само. Немає ніякої формальної документації, але стандарти де-факто існують.

• Керований рівень. Стандарти добре визначені і робота контролюється. Є працівники, відповідальні за ухвалення і оновлення стандартів.

• Вимірюваний рівень. Процес вимірюємо не з точки зору стандартів, а з точки зору деяких мір, введених для удосконалення системи.

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

7. Документація проекту

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

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

• Схвалені документи - це інструкції для виробників.

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

• Стандарти - документи, що описують необхідні стандарти.

• Робочі документи - різноманітні документи з ідеями рішень. Автори можуть бути членами команди. Якщо їх схвалять, вони можуть стати стандартами.

• Повідомлення - примітки, коментарі, букви, які використовуються для комунікації між членами команди.

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

• інформація про всі версії,

• інформація про клієнтів і версії, які вони придбали,

• ПЗ і апаратні вимоги до версії,

• інформація про компоненти (класи, об'єкти, модулі), потрібні для версії,

• інформація про можливі зміни версії,

• інформація про виявлені помилки.

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

• унікальна ідентифікаційна структура із заголовком, автором і номером документа;

• номери послідовності і опис містять:

  • тип документа,

  • номер документа,

  • номер версії,

  • дата версії,

  • стан;

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

• процедури введення змін; хто відповідальний; яким принципам слід дотримуватися;

• гарантія якості документа і персона, відповідальна за процес.

Додаткові елементи можуть бути введені в інфраструктуру, наприклад, рівень конфіденційності документів.

Інфраструктура звіту

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

Звіти важливі для продуктивності проекту.

Звіти стану роботи

На регулярній основі (наприклад, щомісячно) управління повинне організовувати зустрічі, для яких повинні готуватися звіти по темах:

• технічний стан,

• стан ресурсів,

• проходження графіку,

• проблеми,

• фінансовий стан.

Корпорації повинні описати стиль звіту, носії і дистрибутивну форму, вміст і т.п.

Звіт пакету роботи

Коли пакет завдань виконано, треба написати звіт про завершення робочого пакету. Управління перевіряє звіт і, якщо він схвалюється, видає свідоцтво завершення робочого пакету.

Часові таблиця

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