Новини освіти і науки:

G+

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

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

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

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

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

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

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

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

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

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

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

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

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

<== попередня сторінка	\|	наступна сторінка ==>
Типи знань	\|	Планування проекту

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.01 сек.