Ресурси - це другий тип складових, що забезпечують підтримку виконання процесів життєвого циклу програмного забезпечення. Розрізняють такі ресурси: інструменти, методи, виконавці.
Інструменти - це засоби, за допомогою яких здійснюються процеси життєвого циклу. Інструменти можуть бути реалізовані як програмно, так і апаратно. Далі розглядатимуться лише програмно реалізовані інструменти.
Перехід від «програмування в малому» до «програмування у великому» розширив погляд на розробку програмного забезпечення в двох напрямах:
- визнання важливості фаз аналізу і проектування зажадало розробки нових методів;
- нові методи потребували відповідної інструментальної підтримки.
Тому в 1970р. зусилля дослідників були спрямовані на уточнення поняття процесу і розробку відповідних методів, а, починаючи з 1980-х, почали розроблятися інструменти для реалізації процесів на основі нових методів.
Типи інструментів. Інструменти поділяють на два типи: вертикальні або окремі, горизонтальні або інтегральні.
Вертикальні інструменти призначені для виконання окремих дій або процесів у життєвому циклі програмного забезпечення. Наприклад, таких: створення людино-машинних інтерфейсів; створення баз даних і знань; специфікація вимог; виконання доменного аналізу; кодування (програмування); тестування; супровід; документування; реструктурування.
Вертикальні інструменти можуть бути таких типів: синтаксичні, семантичні, структурні.
Синтаксичні інструменти - принцип їх дії ґрунтується на використанні синтаксичного аспекту представлення інформації. Це сканери, синтаксичні аналізатори, реструктуризатори і мовно-орієнтовані редактори.
Семантичні інструменти - принцип їх дії ґрунтується на використанні семантичного аспекту представлення інформації, Це інтерпретатори, компілятори, верифікатори і валідатори.
Структурні інструменти - принцип їх дії ґрунтується на структурному представленні інформації. Це контролери версій, діаграмери.
Горизонтальні інструменти призначені для виконання всіх процесів життєвого циклу або лише декількох процесів (стадій) у певному аспекті. Наприклад, таких:
- аналіз і проектування - інструменти Computer Aided Software Engineering-Analysis and Design (CASE-AD);
- управління проектом - інструменти CASE - Project Management (CASE-PM);
- управління якістю - інструменти CASE - Quolity Management (CASE-QM);
- реверсивна інженерія - інструменти Computer Aided Reverse Engineering (CARE).
Горизонтальні інструменти, як правило, складаються з декількох інструментів, об'єднаних методологією побудови. Розрізняють такі методології побудови інтегральних інструментів: мовно-орієнтована, структурно-орієнтована, методо-орієнтована, набір інструментів.
Мовно-орієнтована методологія. Відповідно до неї, весь набір інструментів побудований, орієнтуючись на конкретну мову. Зазвичай, це мова програмування зі своїм середовищем програмування. Особливістю таких середовищ є те, що вони, як правило, орієнтовані на швидку розробку. Середовище містить всі інструменти, що необхідні для створення, тестування, налагодження і швидкої зміни коду. Інструмент будується як монолітна система і працює в інтерактивному режимі. До того ж у середовищі зберігається вся синтаксична і семантична інформація (результат синтаксичного розбирання, структура і семантичний опис), що забезпечує розуміння програми.
Структурно-орієнтована методологія. Спочатку суть методології полягала в тому, щоб дати користувачеві інтерактивний інструмент, наприклад! синтаксично орієнтований редактор для введення програм у термінах мовних конструкцій. Потім ця ідея була поширена на інтерактивну підтримку семантичного аналізу, виконання і налаштування програм. У кінцевому результаті ця методологія заснована на маніпулюванні програмними структурами І забезпечує різні погляди на програми, які генеруються з однієї і тієї ж програмної структури, стеження за інформацією, важливою для користувача. Тому структурно-орієнтована методологія забезпечує такі аспекти:
- багаторівневий погляд на програмні структури;
- семантичні обчислення;
- генерацію структурно-орієнтованих середовищ. Методо-орієнтована методологія. Ця методологія орієнтує на
використання одного методу при побудові середовища. Розглядають методи двох типів:
- розробки - орієнтовані на реалізацію робочого процесу;
- управління - орієнтовані на реалізацію макро- і мікро-процесів,
Прикладами методів першого типу є SREM, SADT, OOD, PSL/PSA, а також діаграми даних і управління, ER-діаграми, мережі Петрі, мови специфікацій, PDL. Методи другого типу використовуються для побудови CASE, які зазвичай бувають двох типів, орієнтовані на виконання декількох або всіх робочих процесів і на ви конання процесів управління проектом.
Методологія - набір інструментів. Суть її полягає у відсутності якої-небудь методології. Середовища будуються з сукупності невеликих інструментів, орієнтованих на виконання фази кодування (редактор, компілятор, налагоджувальник, лінкер). Сюди можуть Входити інструменти контролю версій і управління конфігураціями.
Середовища розробки програмного забезпечення. Важливу роль в інструментальній підтримці процесів життєвого циклу відіграють середовища розробки. Середовище розробки (Software Development Environment - SDE) - це сукупність апаратних і програмних інструментів, використовуваних для розробки програм і програмних продуктів. Розрізняють середовища програмування, орієнтовані на реалізацію окремих процесів (вертикальні) і середовища розробки програмного забезпечення, орієнтовані на весь життєвий цикл (горизонтальні). Раніше розглядалися методології побудови середовищ розробки програмного забезпечення. Далі розглянемо їх моделі.
Загальна схема SDE моделі така:
SDE Model =( {Структури},
{Механізми},
{Управління}).
Структури - це об'єкти і агрегати об'єктів, на які впливають механізми в процесі розробки програмного забезпечення.
Прості структури - файлові. Складніші будуються на основі абстрактних синтаксичних дерев, графів, баз даних. Основні функції структур такі:
- підтримувати інтеграцію інструментів у SDE;
- мати достатньо інформації, необхідної для роботи механізмів І виконання управління;
- забезпечувати управління змінами програмного забезпечення, що розробляється.
Зазвичай, для вирішення завдань у SDE пропонується використовувати різні типи структур.
Механізми - це мови, інструменти і фрагменти інструментів, які маніпулюють структурами в SDE. Стосовно програміста, механізми можуть бути видимі і приховані.
Якщо детальніше вивчені механізми, то більше вони мають тенденцію вбудовуватися всередину середовища і складати основу генераторної частини інструментів. Наприклад, Jass - генератор синтаксичних аналізаторів. До того ж, чим більш узгоджуються механізми і структури, тим глибшим є аналіз взаємозв'язків між частинами програмного забезпечення і вірогідніша поява адекватної методології, наприклад, аналіз діаграм даних, використовуваний для управління змінами або програмно-базоване тестування.
Управління - це вимоги, що впливають на користувача SDE у процесі розробки програмного забезпечення. Виражаються вимоги у формі правил, стратегій, методик. Зазвичай інструменти і структури, створюючи SDE, визначають управління. Розрізняють типи управління: підтримуване і захищене.
Підтримуване управління припускає наявність у SDE механізмів і структур, що забезпечують підтримку управління. Наприклад, низхідна розробка програмного забезпечення - управління, яке підтримується в багатьох SDE.
Захищене управління припускає не тільки підтримку, але і не можливість порушити його в SDE. Захист може бути реалізований за допомогою механізмів і структур SDE або організаційно - зовні в SDE у формі певного консенсусу розробників.
Розрізняють типи управління: спрямовані на механізми і структури і спрямовані на управління.
Другий тип управління називається високорівневим або метауправ-лінням. Наприклад, усі проект повинні бути реалізовані мовою ADA.
Метод - це систематичний процес дослідження, який у контексті інженерії реалізується для дослідження і створення програмного забезпечення.
В інженерії програмного забезпечення доводиться розробляти і описувати в різних аспектах велику і різноманітну кількість компонентів, використовуючи такі засоби:
- описи - техніка і нотації, представлені за допомогою синтаксису, діаграм, таблиць, що використовуються в документуванні програмного забезпечення;
- моделі - математичні структури, що представляють аспекти компонентів програмного забезпечення;
- моделювання - створення моделі та експериментування для отримання інформації про програмне забезпечення.
Вказані засоби використовуються в рамках трьох таких процесів (рис. 4.2):
- аналіз домена (специфікування вимог) - у результаті виконання процесу визначається «що повніша робити» програмна система;
- аналіз вимог - у результаті виконання процесу визначається «що робить» програмна система;
- проектування - у результаті виконання процесу визначається «як робить» програмна система.
Очевидно, що опис і розробку програмного забезпечення не можна виконати в рамках одного методу. Усі використовувані в інженерії програмного забезпечення метоли поділяють на дві групи: загальнонаукові методи і методи інженерії програмного забезпечення.
Рис. 4.2. Процеси програмного забезпечення
Своєю чергою загальнонаукові методи поділяють на три такі групи:
- теоретичні методи - абстрагування, формалізація, аксіоматика, узагальнення;
- емпіричні методи - спостереження, порівняння, контроль, розрахунок, вимірювання, ідентифікація, науковий експеримент;
- емпірико-теоретичні методи - аналіз і синтез, індукція і дедукція, перевірка гіпотез, моделювання.
Теоретичні методи пізнання спрямовані на дослідження абстрактних об'єктів, їх властивостей і відносин. Ці методи: дають можливість отримувати нові знання про об'єкти і явища шляхом дослідження властивостей абстрактних об'єктів і відносин між ними. Теоретичні методи є найбільш потужним інструментом для прогнозування, створення нових областей знань і служать основою фундаментальних наук. Вони ж лежать в основі багатьох методів інженерії програмного забезпечення,
Емпіричні методи пізнання поділяють па дві групи. Перша - методи якісної оцінки: спостереження, порівняння, контроль. Друга група - кількісної оцінки: розрахунок, ідентифікація, вимірювання і експеримент. Велике значення серед усіх експериментальних методів пізнання для інженерії програмного забезпечення мас. вимірювання, за допомогою якого отримують кількісну інформацію щодо програмного забезпечення. Наявність вимірювальної інформації про досліджуваний об'єкт дає можливість забезпечити ефективну реалізацію всіх емпіричних методів пізнання - від спостереження до експерименту.
Емпірико-теоретичні методи дають змогу досліджувати різні сторони об'єктів і явищ, розчленовуючи їх на складові для деталь нішого вивчення. Найповніше отримання додаткової інформації, що міститься в неявному вигляді в результатах, отриманих за допомогою емпіричних методів, забезпечують емпірико-теоретичні методи встановлення ступеня істинності гіпотез, а також складають основу методів проектування нових технічних засобів і технологічних процесів, основу технічних наук і методів підвищення продуктивності праці на виробництві.
Методи інженерії програмного забезпечення можна розглядати в контексті двох доменів: прикладного і реалізаційного (рис. 4.3).
Суть розробки програмного забезпечення полягає в реалізації процесу, який починається з ідентифікації вимог у прикладному домені і закінчується створенням програмного продукту, який відповідає цим вимогам у реалізаційному домені. На практиці процес розробки має ітераційний характер і кожна ітерація використовує два Види аналізу (рис. 4,4).
Рис. 4.4. Зв'язок доменів і моделей
Перший вид аналізу спрямований на розуміння вимог, а другий - на розуміння того, як програмний продукт повинен задовольняти цю вимогу. Па рис. 4.5 показано як спочатку відрізняються погляди замовника і розробника на одне й те саме питання і як, реалізуючи доменні знання, за допомогою ітерацій «сходиться» розуміння того, «що повинно робити» і «що робить» програмне забезпечення.
Рис. 4.5. Розбіжність поглядів замовника та розробника
На рис. 4.5 ∆ показує початкову розбіжність поглядів замовника і розробника на продукцію програмного забезпечення.
Моделі можуть бути дескриптивні і прескриптивні. Дескриптивна модель показує, як програмний продукт повинен «поводитися». Ця модель має бути перетворена в прескриптивну модель, що показує, який програмний продукт «поводитиметься» так, як визначає дескриптивна модель. Мета першої моделі - показати, як програмний продукт відповідатиме вимогам, а мета другої - забезпечити однозначне виконання вимог тими, хто конструюватиме програмний продукт.
Дескриптивні моделі - концептуальні, прескриптивні - формальні. Обидві категорії моделей повинні бути точними і недвозначними. Проте формальні моделі повинні містити додаткові критерії коректності для створюваного програмного продукту. Оскільки мета концептуальної моделі - описувати вимоги, то і якість моделі визначає те, наскільки добре програмні продукти відповідають вимогам прикладного домена. Визначення такої відповідності - процес суб'єктивний і називається валідацією. Якщо формальна модель існує, то основні властивості програмного продукту встановлені і можна встановлювати його коректність відносно до формальної моделі. Процес встановлення коректності називається верифікацією. Таким чином, валідація має справу з проблемою (вимоги), а верифікація з продуктом (реалізація вимог). Очевидно, що для однієї проблеми може бути декілька концептуальних моделей, а для кожної концептуальної - декілька формальних моделей, У цьому сенсі немає кращої реалізації проблеми, а формальні моделі відіграють важливу роль у процесі розробки програмного продукту, оскільки без них не можна визначити коректність проектування і реалізації.
Таким чином, усі методи інженерії програмного забезпечення можна розділити на два типи. Перший тип - проблемно-орієнтовані методи, що забезпечують краще розуміння проблеми і пропонованого рішення. Другий тип - продукто-оріентовані методи, що забезпечують коректну трансформацію формальної специфікації в супроводжувану реалізацію. Очевидно, що можуть бути методи, які забезпечують обидва аспекти процесу розробки. У табл. 4.2 наведено методи інженерії програмного забезпечення.
Таблиця 4.2
| Порядковий номер | Назва методу | Автор | Рік походження |
| 1 | Рівні абстракції | Е. Дейкстра | 1968 |
| 2 | Покрокове уточнення | Н. Вірт | 1971 |
| 3 | Функціональна декомпозиція, модуляризація | - | - |
| 4 | Структурне проектування | У. Стивенс, Г. Мейерс, Л. Константіне | 1991 |
| 5 | З'єднання, скріплення, приховування | Д. Парнас | 1972 |
| 6 | Структурне програмування | Е. Дейкстра | 1972 |
| 7 | Абстрактні типи даних | Б, Лісков С. Зайліс | 1975 |
| 8 | Структурний аналіз | Т. Де Марко | 1978 |
| 9 | PSL/QSA | Д. Тихросв Е. Херши | 1977 |
| 10 | ERM | С.Чен | 1976 |
| 11 | JSP/JSD | К. Джексоні | 1977 |
| 12 | Vienna Development methud | ІБМ | 1970 |
| 13 | Simula 67, об'ектно-оріентоване програмування ля | У. Даал, А. Кей | 1976 |
| 14 | Об'сктно-орієнтованне проектування | Г. Буч | 1980 |
| 15 | Домєнний аналіз | Р. Прието-Діаз | 1991 |
| 16 | Об'єктно-орієнтований аналіз | Е. Йодон, П. Коад | 1978 |
Розглянемо ці методи докладніше.
Рівні абстракції (Е. Дейкстра, 1968). Ґрунтуючись на досвіді системи мультипрограмування Т.Н.Е., Дейкстра запропонував розробляти програмне забезпечення за рівнями. Перший низький рівень забезпечує балові сервіси для реалізації наступних, рівнів і ґрунтується на можливостях тієї машини, що реально існує. Кожен наступний рівень використовує сервіси поперед нього. Процес Створення рівнів продовжується до тих пір, доки по буде реалізований найвищий рівень абстракції. Наводиться приклад з управлінням пам'яті. На базовому рівні (машинна мова) відомі канальні команди для обміну даними між різними типами пам'яті. На першому рівні проектується механізм управління перериваннями - вплив на сигнали переривання, але без деталей маскування, відкриття, закривання, блокування, черговості. На наступному рівні проектується канальний супервізор - зберігається можливість управління каналами без зайвих деталей і, нарешті, на ще вищому рівні адміністратор пам'яті організовує обмін. Метод можна віднести як до методів розробки, так і управління.
Покрокове уточнення (Н. Вірт, 1971). Цей метод ґрунтується на таких принципах:
- розкладання простору рішень на підпростори;
- ітеративне вирішення завдання (повторення дій);
- аналіз ефективності розкладання (наступне поліпшення виконується лише у вигідному напрямі).
Мета покрокового уточнення полягає в зменшенні ризику, пов'язаного із застосуванням рішень під час програмування. Розділений процесу розробки програмного забезпечення на кроки дає змогу планувати його створення, відкладаючи реалізацію певних модулів, шляхом заміни їх заглушками, що імітують міжмодульні інтерфейси.
Наприклад, метод МЕТА (X. Ледгард, 1973) використовує низхідне уточнення.
Необхідна умова роботи методу - наявність точного і стабільного опису завдання, а результат S - програма.
Функціональна декомпозиція — це метод низхідного аналізу програмного забезпечення шляхом опису функцій, котрі йога утворюють і уявлення про їх реалізацію у вигляді функціональних зв'язаних модулів. Модуль називається функціонально зв'язаним, якщо містить компоненти, спрямовані на виконання однієї функції. Додаток, побудований з функціонально зв'язаних модулів, легко будувати і супроводжувати.
Модуляризація (Д. Парнас, 1972). Цей метод заснований на трьох фундаментальних принципах: з'єднання, скріплення, приховування інформації. Метод призначений для вирішення завдання розбиття програми на модулі, яка називається модуляризацією. Використовуються такі критерії модуляризації:
- з'єднання - поєднання частин модуля із зовнішнім оточенням повинне бути слабким;
- скріплення - скріплення частин, що входять до складу модуля має бути сильним;
- приховування - інформація, що міститься в модулі, повинна бути прихованою.
Модуль мас тіло, яке містить опис функції, що вирішується модулем, і інтерфейс, що забезпечує зв'язок модуля з його користувачами.
Структурне програмування (Е. Дейктра, 1972). Цей метод обмежує написання програм шляхом використання лише трьох типів операторів: послідовне з'єднання, вибір і повтор. Такий операторний базис достатній для написання будь-якої програми. Програми називаються структурними, а процес програмування - структурним. Метод передбачає також способи переходу від неструктурних програм до структурних.
Абстрактні типи даних (Б, Лісков, С. Зайліс, 1975). Суть методу полягає в розширенні концепції структур даних визначуваними операціями над ними. Перші реалізації абстрактних типів даних могли здійснюватися вже в підпрограмних мовах програмування (Paskal, С) шляхом використання процедурного типу або вказівного тину на підпрограму. У подальшому в мовах програмування були введені спеціальні конструкції (модуль, клас), спрямовані на ефективну реалізацію абстрактних типів даних.
Структурний аналіз (Т. де Марко, 1978). Метод аналізу специфікацій вимог за допомогою діаграм (управління, дані, перехід станів) - PSL/PSA (Д. Тіхроєв, 1977) шляхом ієрархічної декомпозиції вирішення проблеми. Людино-машинна техніка реалізована у вигляді мов і призначена для структуризації документації і аналізу інформації. Мови PSL/PSA використовують графічні діаграми {System Analisys and Design Techik - SADT), які застосовують для опису даних, перетворення інформації і процесів, що відбуваються в системах (рис. 4.6).
Рис. 4.6. Діаграма SADT
ER-моделювання (С. Чен, 1976). Метод опису прикладного домена за допомогою спеціальних діаграм «суть-зв'язок» (Enitity -Relation - ER), Метод використовує три типи нотацій: сутність, зв'язок (відношення), з'єднання.
Наприклад, діаграма на рис. 4.7 описує домен «комп'ютер — програма».
ER-модель використовується для опису логічних схем баз даних.
Рис. 4.7. ER-Діаграма:
□-сутність; ◊-(зв'язок,відношення) − − - з’єднання
Позначення 1 і т біля з'єднань показують їх тип (у цьому прикладі і «один - до багатьох»).
Системне програмування Джексона (К. Джексон, 1977). Метод використовує структурні оператори (проходження, вибір, повторения) для представлення логічних структур програмного забезпечення.
Віденський метод (IBM, 1970). Метод ґрунтується па операційному підході до опису семантики мов програмування. Суть методу полягає в тому, що завдання семантики здійснюється шляхом опису певних системних пристроїв - автоматів, що володіють па м'ятно і структурними станами.
Метод був розроблений для представлення семантики мови програмування PL/1, а потім використовувався для опису програмного забезпечення.
Simula 67 (У. Дал, Л. Keй, 1976), Мова програмування, до якої вперше введено поняття класу. Основним поняттям у мові був об'єкт - екземпляр блоку. Безліч об'єктів утворюють клас. Класи можуть складатися з підкласів (ієрархія, контейнер) у сучасному розумінні Згодом мова Simula 67 стала основою побудови мов об'єктно-орієнтованого програмування.
Об'єктно-орієнтоване проектування (Г. Буч, 1980). Суть методу полягає у використанні поняття об'єкта при аналізі наочної об ласті і проектуванні програмного забезпечення,
Доменний аналіз (Р. Прісто-Діаз, 1991). Метод спрямований на аналіз наочних областей з метою визначення повторно використовуваних рішень.
Об'єктнно-орієнтований аналіз (Е. Йодон, П. Коад. і 978). Є розширенням методу структурного аналізу шляхом використання об'єктів.
Усі перелічені методи можна розташувати в матриці (рис. 4.8),
| Тип моделі | Зорієнтованість методів, | проблемно-орієнтовані | продукто-орієнтовані |
| Концептуальний | І Структурний аналіз ER-модель Об'єктно-орієнтований аналіз | ІІ Структурно проектування О'бєктно-оріентоване проектування | |
| Формальні моделі | ІІІ JSD VDM | IV Рівні абстракцій; Покрокова розробка Доведення правильності JSD ОО - програмування |
Рис. 4.8. Відповідність типів моделей і методів
Програмні процеси реалізують фахівці. Більшість програмних Процесів є настільки складними, що не можуть бути виконані одним або двома особами, тому шин зазвичай, утворюють певну структуру (організацію), характер якої, як і властивості окремих осіб, відіграють дуже важливу роль у розробці програмних продуктів.
Отже, розглянемо дві складових персоналу:
- кваліфіковані фахівці, здатні викопувати роботи зі створення програмного забезпечення;
- організації - об'єднання людей, що ставлять за мету виконання робіт зі створення програмного продукту.
Фахівці. Нині відомий дуже широкий спектр фахівців, які можуть залучатися до розробки програмного забезпечення.
Фахівцями комісії SEEPP розроблений етичний кодекс інженера з програмного забезпечення. Він включає такі аспекти:
- суспільні інтереси - дії програмістів повинні відповідати суспільним інтересам;
- клієнт і працедавець - програмісти повинні вчиняти так, щоб якнайкраще задовольнити вимоги клієнта і працедавця, але при цьому дотримуватись суспільних інтересів;
- продукт — програмісти повинні бути впевнені в тому, що створюванні ними програмні продукти і пов'язані з продуктами модифікації відповідають професійним найвищим стандартам;
- критицизм - інженери-програмісти повинні дотримуватися цілісності і незалежності своїх думок, формуючи здоровий професійний критицизм мислення;
- Менеджмент - менеджери і лідери, керівники груп з розробки ПО, зобов'язані дотримуватися стичних норм у процесі розробки і супроводу програм;
- професіоналізм - програмісти зобов'язані бути чесними і підтримувати репутацію професіоналів, не забуваючи про дотримання суспільних інтересів;
- колегіальність - програмісти зобов'язані підтримувати своїх колег;
- самовдосконалення - програмістам слід постійно підвищувати свою кваліфікацію, що сприятиме їх професійному зростанню, а також формувати етичний підхід до професійної діяльності.
Культуру складають безліч цінностей, цілей і принципів, що керують діями, пріоритетами і рішеннями окремих осіб або групи, які працюють задля реалізації загальної мети. Культура груп - розробників програмного продукту дуже сильно впливає на якість продукту, продуктивність розробників і робочу обстановку в групі.
На ринку праці використовуються різні методи і моделі, які можна розділити на дві групи:
- підбору персоналу;
- розвитку персоналу.
До моделей підбору персоналу належать такі:
- індикатор типів (модель) Майерса-Брігтса (МВТІ) - застосовується для ідентифікації чотирьох біполярних видів поведінки на основі 16 різних описів персональних властивостей особи;
- модель функціональних міжособових відносин орієнтації поведінки (FIRO-B) - застосовується для ідентифікації типів міжособових відносин шляхом вимірювання трьох аспектів, які позначаються як «залучення», «контроль» і «прихильність»;
- модель сортування темпераментів Кейрси - застосовується для тестування осіб (шляхом опитування) на основі чотирьох типів темпераментів;
- модель міжпроцесорної взаємодії Келера (РСМ) - застосовується для ідентифікації типу особи на основі шести тилів осіб з використанням транзакційного аналізу. Транзакції - це «мінісценарії» поведінки. Застосування здійснюється шляхом спостереження. Модель враховує результати змін характеристик особи впродовж життя.
Наведені моделі дають змогу розпізнавати особові шаблони і передбачати характер взаємодій між співробітниками в організації.
Моделі розвитку персоналу застосовуються для підвищення кваліфікації фахівців.
Організація. В інженерії програмного забезпечення розглядається два поняття, що характеризують організації, розробляючи [програмне забезпечення: «культура» і «структура».
Існують такі визначення організацій:
- система, яка обмінюється матеріалами, кадрами, робочого си лою і енергією з навколишнім середовищем;
- група людей, що мають певну формальну мету;
- група людей, що координують свої дії для досягнення організаційних цілей.
Структура сучасних організацій визначена в XVIII ст., у роботах французького гірського інженера Генрі Файола. Він запропонував ряд принципів менеджменту, які лежать і сьогодні в основі функціонування більшості організацій. Наприклад, розподіл праці; централізація; управління; дисципліна; ієрархічна структура; функціональне орієнтування; «стартова ніша» спеціальності; шлях рішень і просувань, який спрямований вертикально вгору зі «стартової ніші», нарівні з діями в рамках проекту, розподіленим на категорії відповідно до дисциплін і спеціальностей,
Основною характеристикою організації є її зрілість. Незрілу організацію характеризують такі аспекти:
- спеціальні процеси, імпровізовані їх виконавцями і керівництвом;
- процеси і правила, строго не дотримувані або не обов'язкові;
- високий ступінь залежності від розробників;
- можливість виникнення проблем, пов'язаних з цінами і графіками;
- невідповідність графіків функціональним властивостям, якості продукту або послуги;
- непередбачувана якість продукту. Характеристики зрілої організації такі:
- визначені, документовані і постійно удосконалювані процеси;
- документовані процеси, які є сумісними з фактичним способом виробництва;
- видима підтримка з боку керівництва і розробників;
- добре контрольована поведінка, що перевіряється;
- виконувані і використовувані вимірювання продуктів і процесів;
- виконувані технології.
У структурному аспекті відомо багато різних типів структур організацій, які варіюються навколо трьох основних тинів структур: функціональна, проектна, матрична.
Функціональна структура - припускає розділення співробітників за функціональними обов'язками.
Проектна структура - припускає розподіл структури за функціональними підрозділами, орієнтованими на виконання проекту.
Матрична структура - припускає розділення співробітників з функціональних підрозділів за виконуваними проектами з підпорядкуванням їх менеджерові матричного проекту.