• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Структура команди

У мережевій структурі команда співпрацює на щоденній основі. Стандарти якості гарантуються взаємним контролем роботи. Написання програм може виконуватися в командній роботі. Будь-який член команди, який йде з неї, може бути легко замінений. Мережа не повинна мати більше 8 чоловік.

Мал. 15.6.2. Мережева структура командної роботи.

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

Мал. 15.6.3. Зоряна структура командної роботи.

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

Критерії якості:

1. Відповідність вимогам користувача

2. Ефективність

3. Ремонтопридатність

4. Ергономіка

Якість ПЗ визначається всіма діями, зробленими на всіх етапах. Критерії якості і пріоритети повинні бути визначені. Критерії повинні документуватися в ПГЯПЗ. Якість програмного забезпечення залежить від якості виробничого процесу. Це визначено в стандартах ISO 900x.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

o стан;

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

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

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

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

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

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

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

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

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

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

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

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

· проблеми,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10. Завдання управління проектом

Чинник успіху проекту розробки ПЗ - відповідне управління. Його можна досягти шляхом розробки плану і його виконання по пунктам.

Проект розробки ПЗ підлягає:

· плануванню,

· організації,

· управлінню людськими ресурсами,

· спостереженню,

· моніторингу,

· контролю.

Критичними завданнями менеджера є:

· визначення ролей і призначення їх персоналу,

· управління шляхом інформування персоналу про їх роль в плані,

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

· моніторинг процесу,

· повідомлення про прогрес процесу клієнтові і вищим за посадою.

Мал. 15.11.1. Приклад діаграми організації проекту.

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

· визначення програми,

· визначення дій,

· оцінка ресурсів і часу,

· визначення схеми завдання,

· визначення графіка роботи і вартості.

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

Завдання і відповідальність менеджера по проектах

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

Читайте також:

1. III. Географічна структура світового ринку позичкового капіталу
2. VІ. План та організаційна структура заняття
3. Адміністративно – територіальний устрій і соціальна структура Слобожанщини у половині XVII – кінці XVIII століття
4. Акти з охорони праці, що діють в організації, їх склад і структура.
5. АРХІВНІ ДОВІДНИКИ В СИСТЕМІ НДА: ФУНКЦІЇ ТА СТРУКТУРА
6. Атомно-кристалічна структура металів
7. Базова алгоритмічна структура
8. Банківська система та її структура. Функції Центрального банку.
9. Безцехова виробнича структура.
10. Будова систем: підсистема, елемент, структура, зв'язок.
11. Бухгалтерська оцінка капіталу банку. Структура капіталу
12. Бюджетна структура

Переглядів: 1426