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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

o стан;

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

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

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

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

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

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

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

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

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

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

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

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

· проблеми,

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

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

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

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

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

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

Визначення продуктивності

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

· кількість рядків виконаного і тестованого коду впродовж місяця,

· кількість інструкцій кінцевого коду, написаного за певний проміжок часу,

· розмір документації, написаної за певний проміжок часу,

· кількість тестових прикладів, підготовлених за певний проміжок часу.

Сучасні інструменти замінюють використання вище перерахованих методів, наприклад:

1. Мови високого рівня => короткий код, висока продуктивність,

2. Бібліотеки, генератори => велика кількість програм за короткий проміжок часу.

Для аналітиків і проектувальників іноді важко вибрати певні методи. Від цього залежить їхній рівень професійності.

Складання графіків проекту

Складання графіків проекту виконується менеджером по проектах. Воно містить:

· планування календаря:

o дата початку проекту,

o робочі дні, свята в межах даного періоду часу,

o години роботи на день,

· розбиття проекту на завдання,

· визначення параметрів завдань,

· визначення необхідних ресурсів для конкретних завдань,

· доступність ресурсів,

· послідовність і час виконання конкретних завдань.

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

· час виробництва,

· час початку,

· час необхідного закінчення,

· інші обмеження часу.

Економічні аспекти

Якість програми - тільки один чинник, який впливає на фінансовий стан компанії.

Іншими чинниками є:

· маркетинг і реклама

· репутація виробника

· вигляд і зміст гарантії

· комфорт клієнта

· контроль версій

У вартість компанії входить і чинник прибутку. Вартість складається з:

· внутрішні інвестиції

· вартість реорганізації

· вартість навчання

· вартість інструментів CASE

· вартість тестування

Дохід можна очікувати через деякий час після інвестування в компанію.