Вимоги до структури системи 5 страница
Основна частина роботи повинна містити етапи вирішення індивідуального завдання шляхом аналізу досягнутих результатів в обраній предметній області.
Висновки повинні містити результати виконаної роботи.
Індивідуальні завдання
Розробити діаграму станів для систем, список яких надано в лабораторній роботі 3.1 або узгодити вибір процесу з викладачем.
Запитання для самоперевірки
1. Пояснити доцільність створення діаграми станів.
2. Назвати основні елементи діаграми станів.
3. Пояснити взаємовідношення «стан-дія».
4. Назвати відомі псевдостани.
5. Що таке сторожова умова?
6. Як виникають нетригерні переходи?
7. Пояснити відмінності між тригерними та нетригерними переходами.
Лабораторна робота 3.5.
РОЗРОБКА ДІАГРАМИ ДІЯЛЬНОСТІ В СЕРЕДОВИЩІ IBM RATIONAL ROSE
Мета:вивчити призначення та порядок розробкидіаграми діяльності в середовищі IBM Rational Rose.
Завдання:розробитидіаграму діяльності для обраної системи, оформити звіт із виконаної роботи, представити його для захисту.
Основні теоретичні відомості
Діаграма діяльності представляється у формі графа, вершинами якого є стани дії або діяльності, а дугами – переходи від одного стану дії до іншого.
Основним напрямком використання діаграм діяльності є візуалізація особливостей реалізації операцій класів, коли необхідно представити алгоритми їх виконання.
Стан діяльності служить для подання процедурної послідовності дій, що вимагають певного часу.
Графічно стани діяльності і дії зображуються однаковою фігурою, що нагадує прямокутник з опуклими дугами по боковим сторонам. Усередині цієї фігури записується ім'я діяльності або дії у формі виразу. Воно повинне бути унікальним у межах однієї діаграми діяльності.
При побудові діаграми діяльності використовуються тільки нетриггерні переходи. На діаграмі такий перехід зображується суцільною лінією зі стрілкою.
Графічно розгалуження на діаграмі діяльності позначається символом розв'язку, зображуваного у формі маленького ромба, без текста усередині. У ромб може входити тільки одна стрілка від того стану дії, після виконання якого потік керування повинен бути продовжений по одній з гілок, що йдуть далі. Прийнято вхідну стрілку приєднувати до верхньої або лівої вершини символу розв'язку. Вихідних стрілок може бути дві або більше, але кожній з них вказується відповідна сторожова умова у формі булевого виразу.
Доріжка – графічна область діаграми діяльності, що містить елементи моделі, відповідальність за виконання яких належить окремим підсистемам.
Порядок виконання роботи
Ознайомитися з літературою [1, 2, 14-16], побудувати діаграму діяльності станів за прикладом розглянутої моделі банкомата, що показана на рис. 3.5. Для цього виконати послідовність дій 1-22.
Рис. 3.5. Діаграма діяльності для моделі банкомата
1. Активізувати діаграму діяльності для обраного елемента моделі або моделюємої системи в цілому одним з наступних способів:
· на панелі інструментів «стандартна» клацнути по кнопці із зображенням діаграми станів та вибрати подання і тип розроблювальної діаграми;
· у браузері проекту виділити логічне подання або подання варіантів використання і виконати операцію контекстного меню: New ® Activity Diagram;
· у головному меню Browse ® State Machine Diagram вибрати подання і тип розроблювальної діаграми.
2. Вивчити призначення окремих кнопок панелі інструментів.
3. Задати ім'я «Діаграма діяльності ATM» новій діаграмі діяльності, а в секцію її документації ввести текст «Діаграма діяльності описує послідовність дій клієнта при використанні банкомата».
4. Додати нову діяльність на діаграму та ввести її ім'я «Вставити картку».
5. Додати діяльності з іменами «Ввести ПІН-код», «Вибрати тип транзакції», «Ввести суму», «Одержати довідку про стан рахунку», «Одержати готівку», «Одержати чек», «Одержати картку» і «фінальний стан».
6. Додати символи розгалуження(рішення), розташувавши їх між діяльностями з іменами «Ввести ПІН-код» і «Вибрати тип транзакції», «Вибрати тип транзакції» і «Ввести суму», «Ввести суму» і «Одержати довідку про стан рахунку», «Одержати готівку» і «Одержати чек», і «Одержати картку». При цьому останній символ рішення буде використовуватися в якості символу з'єднання.
7. Додати перехід, спрямований від діяльності «Ввести ПІН-код» до символу «рішення».
8. Додати перехід зі сторожовою умовою «[ПІН-код вірний]», спрямований від символурішення до діяльності «Вибрати тип транзакції». Для завдання сторожової умови даного переходу слід ввести текст «ПІН-код вірний» у поле введення «Guard Condition» на вкладці «Detail» вікна специфікації властивостей даного переходу. При цьому текст сторожової умови вводити без дужок.
9. Додати перехід зі сторожовою умовою «[ПІН-код невірний]», спрямований від символурішення до символу з'єднання.
10. Додати перехід, спрямований від діяльності «Вибрати тип транзакції» до символурішення.
11. Додати перехід зі сторожовою умовою «[вибір зняття суми]», спрямований від символурішення до діяльності «Ввести суму».
12. Додати перехід зі сторожовою умовою «[вибір способу одержання довідки]», спрямований від символурішення до діяльності «Одержати довідку про стан рахунку».
13. Додати перехід, спрямований від діяльності «Ввести суму» до символурішення.
14. Додати перехід зі сторожовою умовою «[сума не перевищує кредит]», спрямований від символурішення до діяльності «Одержати готівку».
15. Додати перехід зі сторожовою умовою «[сума перевищує кредит]», спрямований від символурішення до символу з'єднання.
16. Додати перехід, спрямований від діяльності «Одержати готівку» до символурішення.
17. Додати перехід зі сторожовою умовою «[обраний друк чека]», спрямований від символурішення до діяльності «Одержати чек».
18. Додати перехід зі сторожовою умовою «[друк чека не обраний]», спрямований від символурішення до символу з'єднання.
19. Додати перехід, спрямований від діяльності «Одержати чек» до символу з'єднання.
20. Додати перехід, спрямований від діяльності «Одержати довідку про стан рахунку» до символу з'єднання.
21. Додати перехід, спрямований від символу з'єднання до діяльності «Одержати картку».
22. Додати перехід, спрямований від діяльності «Одержати картку» до фінального стану.
Оформлення результатів роботи
Результати лабораторної роботи оформлюються у вигляді звіту, обов'язковими елементами, якого: титульний аркуш; формулювання мети та завдання роботи; основна частина; висновки.
Основна частина роботи повинна містити етапи вирішення індивідуального завдання шляхом аналізу досягнутих результатів обраної предметної області.
Висновки повинні містити результати виконаної роботи.
Індивідуальні завдання
Розробити діаграму станів для систем, список яких надано в лабораторній роботі 3.1 або узгодити вибір бізнес-процесів з викладачем.
Запитання для самоперевірки
1. Назвати основне призначення діаграм діяльності.
2. Як позначаються діяльності на діаграмі?
3. Назвати основні елементи діаграми діяльності.
4. Які переходи використовуються на діаграмі діяльності?
5. Що подається ромбом на діаграмі діяльності?
6. Пояснити призначення сторожової умови на діаграмі діяльності.
7. Як зветься графічна область діаграми діяльності, що містить елементи моделі?
Модуль ІV. Реалізація об’єктно-орієнтованих програмних систем
Лабораторна робота 4.1
ДІАГРАМА КОМПОНЕНТІВ В СЕРЕДОВИЩІ IBM RATIONAL ROSE
Мета:вивчити призначення та порядок побудови діаграми компонентів в середовищі IBM Rational Rose.
Завдання:розробити діаграму компонентів для обраної інформаційної системи, оформити звіт та представити його для захисту.
Основні теоретичні відомості
Діаграма компонентів описує особливості фізичного подання системи, що дозволяє визначити архітектуру розроблювальної системи, установивши залежності між програмними компонентами, у ролі яких може виступати вихідний, бінарнийкод. Пунктирні стрілки, що з'єднують модулі, показують відносини взаємозалежності, аналогічні тим, які мають місце при компіляції вихідних текстів програм. Основними графічними елементами діаграми компонентів є компоненти, інтерфейси і залежності між ними.
Для графічного подання компонента використовується спеціальний символ – прямокутник із вставленими ліворуч двома більш дрібними прямокутниками. Усередині прямокутника записується ім'я компонента і, можливо, додаткова інформація. Цей символ є базовим позначенням компонента в мові UML.
У мові UML для компонентів визначені наступні стереотипи:
· «file» – визначає найбільш загальний різновид компонента, який представляється у вигляді довільного фізичного файлу;
· «executable» – визначає різновид компонента-файлу, який є здійсненним файлом і може виконуватися на комп'ютерній платформі;
· «document» – визначає різновид компонента-файлу, який представляється у формі документа довільного змісту, що не є здійсненним файлом або файлом з вихідним текстом програми;
· «library» – визначає різновид компонента-файлу, який представляється у формі динамічної або статичної бібліотеки;
· «source» – визначає різновид компонента-файлу, що представляє собою файл із вихідним текстом програми, який після компіляції може бути перетворений у виконуємий файл;
· «table» – визначає різновид компонента, який представляється у формі таблиці бази даних.
Відношення залежності на діаграмі компонентів зображується пунктирною лінією зі стрілкою, спрямованою від клієнта або залежного елемента до джерела або незалежного елемента моделі.
Відношення реалізації інтерфейсу позначається на діаграмі компонентів звичайною лінією без стрілки.
Порядок виконання роботи
Ознайомитися з літературою [1, 2, 14-16], побудувати діаграму компонентів за прикладом розглянутої моделі банкомата, що показана на рис. 4.1. Для цього виконати послідовність дій 1-12.
1. Активізувати діаграму компонентів одним з наступних способів:
· на панелі інструментів«стандартна» клацнути на кнопку із зображенням діаграми компонентів;
· розкрити подання компонентів Component View у браузері і двічі клацнути на піктограмі Main;
· через пункт меню Browse ® Component Diagram.
2. Вивчити призначення панелі інструментів необхідних для розробки діаграми компонентів.
3. Додати компонент на діаграму. Змінити ім'я діаграми, запропоноване за замовчуванням «Main», на «Діаграма компонентів АТМ», а першому доданому компоненту задати ім'я «Mainatm.exe».
Компоненту «Mainatm.exe» вибрати стереотип «EXE» із вкладеного списку, оскільки стосовно до розроблювальної моделі передбачається реалізація цього компонента у формі виконуємого файлу.
Рис. 4.1.Діаграма компонентів моделі банкомату
4. Додати компонент з ім’ям «Mainbank», для якого вибрати стереотип «Main Program» і додати залежність між двома компонентами. За результатом цих дій на діаграмі з'явиться зображення відносини залежності у формі пунктирної лінії зі стрілкою, що з'єднує два обрані компоненти.
5. Додати компонент з ім’ям «Пристрої Банкомата», для якого задати стереотип «Task Specification».
6. Додати компоненти з іменами «Пристрій читання картки», «Клавіатура Банкомата», «Принтер Банкомата», «Екран Банкомата», «Пристрій видачі готівки», яким задати стереотип «Task Body».
7. Додати залежність від компонента «Mainatm.exe» до компонента «Пристрої Банкомата».
8. Додати залежність від компонента «Пристрій читання картки» до компонента «Пристрою Банкомата».
9. Додати залежність від компонента «Клавіатура Банкомата» до компонента «Пристрої Банкомата».
10. Додати залежність від компонента з «Принтер Банкомата» до компонента «Пристрої Банкомата».
11. Додати залежність від компонента «Екран Банкомата» до компонента «Пристрої Банкомата».
12. Додати залежність від компонента «Пристрій видачі готівки» до компонента «Пристрої Банкомата».
Проконтролювати відповідність виду діаграми компонентів можна по рис. 4.1.
Оформлення результатів роботи
Результати лабораторної роботи оформлюються у вигляді звіту, обов'язковими елементами, якого: титульний аркуш; формулювання мети та завдання на роботу; основна частина; висновки.
Основна частина роботи повинна містити етапи вирішення індивідуального завдання шляхом аналізу досягнутих результатів обраної предметної області.
Висновки повинні містити результати виконаної роботи.
Індивідуальні завдання
Розробити діаграму станів для систем, список яких надано в лабораторній роботі 3.1 або узгодити вибір теми з викладачем.
Запитання для самоперевірки
1. До якого класу діаграм відноситься діаграма компонентів?
2. Назвати основні елементи діаграми компонентів.
3. Що таке компонент та яких видів він буває?
4. Як графічно відображається компонент на діаграмі компонентів?
5. Які стереотипи визначені в UML для компонентів?
6. Які властивості компонента відображаються на відповідній діаграмі?
7. Які відношення існують в діаграмі компонентів та як вони відображаються?
Лабораторна робота 4.2
ДІАГРАМА РОЗГОРТАННЯ В СЕРЕДОВИЩІ IBM RATIONAL ROSE
Мета:вивчити призначення і порядок розробкидіаграми розгортання в середовищі IBM Rational Rose.
Завдання:розробити діаграму розгортання для обраної інформаційної системи, підготувати звіт з виконаної роботи та представити його для захисту.
Основні теоретичні відомості
На діаграмі розгортання представлені вузли виконання програмних компонентів реального часу, процесів і об'єктів.
Діаграма розгортання застосовується для представлення загальної конфігурації і топології розподіленої програмної системи і містить зображення розміщення компонентів по окремих вузлах системи. Крім того, діаграма розгортання показує наявність фізичних сполук – маршрутів передачі інформації між апаратними пристроями, задіяними в реалізації системи.
Діаграма розгортання містить графічні зображення процесорів, пристроїв, процесів і зв'язків між ними. На відміну від діаграм логічного подання, діаграма розгортання є єдиною для системи в цілому, оскільки повинна відображати всі особливості її реалізації.
Вузол являє собою фізично існуючий елемент системи, який володіє обчислювальним ресурсом або є технічним пристроєм. Графічно вузол на діаграмі розгортання зображується у формі тривимірного куба. Вузол має ім'я, яке вказується всередині цього графічного символу. Самі вузли можуть представлятися як на рівні типу, так і на рівні екземпляра.
Зображення вузлів можуть розширюватися, щоб включити додаткову інформацію про специфікації вузла. Якщо додаткова інформація відноситься до імені вузла, то вона записується під цим ім'ям у формі поміченого значення
Як доповнення до імені вузла можуть використовуватися різні текстові стереотипи, які явно специфікують призначення цього вузла. Для цього використовуються наступні текстові стереотипи: "processor", "sensor", "modem", "net", "printer" та інші, зміст яких зрозумілий з контексту.
В якості відносин виступають фізичні з'єднання між вузлами, а також залежності між вузлами і компонентами, які допускається зображати на діаграмах розгортання.
Сполучення є різновидом асоціації і зображуються відрізками ліній без стрілок.
Порядок виконання роботи
Ознайомитися з літературою [1, 2, 14-16], побудувати діаграму розгортання за прикладом розглянутої моделі банкомата, що показана на рис. 4.2. Для цього виконати послідовність дій 1-8.
Рис. 4.2.Діаграма розгортання розробляємої моделі управління банкоматом
1. Активізація діаграми розгортання виконується одним із таких способів:
• на панелі інструментів «стандартна» вибрати мишею зображення діаграми розгортання;
• в браузері проекту подвійним клацанням по піктограмі уявлення розгортання (Deployment View);
• виконати операцію головного меню: Browse ® Deployment Diagram.
2. По спеціальній панелі інструментів вивчити кнопки із зображенням графічних примітивів, що необхідні для розробки діаграми розгортання.
3. На діаграму розгортання додати вузол типу процесор і задаємо йому ім'я «Банкомат №1», для якого у формі примітки вкажемо позначене значення: «{адреса = вул. Садова, буд.5}».
4. Додати з'єднання вузлів з іменами «Банкомат №1» і «Мережа».
5. Додати процесор з ім'ям «Банкомат №2», якому задати значення у формі примітки: «{адреса = вул. Паркова, б.7}», а на вкладці властивостей «Detail» визначити новий процес і вибрати для нього ім'я «MainATM» з вкладеного списку.
6. Додати процесор з ім'ям «Банкомат №3», якому задати примітку: «{адреса = вул. Лісова, д.9}», а на вкладці властивостей «Detail» визначити новий процес і вибрати для нього ім'я «MainATM» з вкладеного списку.
7. Додати процесор з ім'ям «Сервер Банку», якому на вкладці властивостей «Detail» визначити новий процес з ім'ям «MainBank».
8. Додати з'єднання між вузлом «Мережа» і вузлами з іменами «Банкомат №2», «Банкомат №3» і «Сервер Банку».
Построенная таким образом диаграмма развертывания будет иметь следующий вид рис. .
Оформлення результатів роботи
Результати лабораторної роботи оформлюються у вигляді звіту обов'язковими елементами, якого є: титульний аркуш; формулювання мети та завдання на роботу; основна частина; висновки. Зразок титульного листа наведений у Додатку 1.
Основна частина роботи повинна містити етапи вирішення індивідуального завдання шляхом аналізу досягнутих результатів в обраній предметній області.
Висновки повинні містити результати виконаної роботи.
Індивідуальні завдання
Розробити діаграму станів для систем, список яких надано в лабораторній роботі 3.1 або узгодити вибір бізнес-процесів з викладачем.
Запитання для самоперевірки
1. Чи можна діаграму розгортання виключити з процесу розробки інформаційної системи?
2. Що входить до основних елементів діаграми розгортання?
3. Які відносини застосовують в діаграмах розгортання?
4. Як на діаграмах розгортання позначають вузел?
5. Які властивості може мати вузел?
6. Які стереотипи використовують в діаграмах розгортання?
7. Чи припустиме використання фізичних зєднань на діаграмі розгортання?
Лабораторна робота 4.3
ПІДГОТОВКА МОДЕЛІ ДЛЯ ГЕНЕРАЦІЇ ПРОГРАМНОГО КОДУ В СЕРЕДОВИЩІ IBM RATIONAL ROSE
Мета:вивчити призначення і порядок підготовки моделі до генерації програмного кода в середовищіIBM Rational Rose
Завдання:обрану інформаційну модель підготувати для генерації програмного кода, оформити звіт з виконаної роботита представити його для захисту.
Основні теоретичні відомості
Однією з найбільш важливих властивостей програми IBM Rational Rose є можливість генерації програмного коду на декількох мовах програмування, яка може бути використана розробником після побудови моделі. Для цієї мети в середовищі IBM Rational Rose присутній досить великий вибір мов програмування і схем баз даних.
Загальна послідовність дій, які необхідно виконати для генерації програмного коду в середовищі IBM Rational Rose, складається з наступних етапів:
1. Перевірити модель на відсутність помилок.
2. Створити компоненти для реалізації класів.
3. Відобразити класси на компоненти.
4. Вибрати мову програмування для генерації тексту програмного коду.
5. Встановити властивості генерації програмного коду.
6. Вибрати класси, компоненти або пакети.
7. Генерувати програмний код.
Особливості виконання кожного з етапів можуть змінюватися залежно від вибору мови програмування або схеми бази даних.
В якості мови реалізації проекту рекомендується вибирати мову програмування ANSI C ++, яка не вимагає інсталяції додаткових програм і поставляється практично у всіх конфігураціях IBM Rational Rose.
Порядок виконання роботи
Ознайомитися з літературою [1, 2, 14-16].
1. Поміняти імена класів, атрибутів і операцій, при цьому діаграма класів моделі банкомату буде мати вид (рис. 4.3).
Рис. 4.3. Діаграма класів моделі банкомату
2. Перевірити модель шляхом виконання операції головного меню: Tools Check Model. Проконтролювати результати перевірки моделі на наявність помилок у вікні журналу. Усунути помилки і попередження, про що має свідчити чисте вікно журналу (рис. 4.4).
Рис. 4.4.Вид журналу за відсутності помилок за результатами перевірки
3. Перейменувати компоненти, задавши їм англомовні імена. Відповідна діаграма компонентів моделі банкомата матиме вигляд, представлений на рис. 4.5.
Рис. 4.5.Діаграма компонентів моделі банкомата після перетворення імен компонентів
4. Компоненту «MainATM.exe» для генерації програмного коду вибрати класи «ATMTransaction» і «ATMController» (рис. 4.6).
Рис. 4.6. Діалогове вікно налаштування властивостей реалізації класів у компоненті «MainATM.exe»
5.Для вибору мови ANSI C ++ в якості мови реалізації моделі виконати операцію головного меню «Tools Options», в результаті чого викликається діалогове вікно налаштування параметрів моделі. На вкладці «Notation» у рядку «Default Language» з вкладеного списку слід вибрати мову ANSI C ++.
6. Змінити мову в рядку «Language» на вкладці «General» вікна специфікації властивостей компонента, для чого з вкладеного списку слід вибрати мову ANSI C ++ (рис. 4.7).
Після вибору мови програмування привести у відповідність типи атрибутів, типи аргументів і значень операцій. З цією метою потрібно переглянути всі класи діаграми класів і змінити ті типи даних, які не є синтаксично допустимими в обраній мові програмування. Для мови ANSI C ++ слід замінити тип Integer на int, Boolean на bool, Currency на float. Інакше відповідні виправлення доведеться виконувати вручну після генерації програмного коду.
7. З моделі системи управління банкоматом для генерації програмного коду мовою ANSI C ++ виберемо компонент з ім'ям «MainATM.exe». Для генерації коду потрібного елементу виділити в браузері проекту і виконати операцію контекстного меню: ANSI C ++ Generate Code_. В результаті цього буде відкрито діалогове вікно, що запрошує вибрати класи для генерації програмного коду обраною мовою програмування (рис. 4.8).
Рис. 4.7.Вікно специфікації властивостей компонента «MainATM.exe» при виборі мови його реалізації
Рис. 4.8.Вікно вибору класів для генерації програмного коду
8. Для перегляду і редагування створених файлів з текстом програмного коду мовою ANSI C ++ призначений вбудований текстовий редактор, який можна відкрити за допомогою операції контекстного меню ANSI C ++ ® Browse Header_ або ANSI C ++ ® Browse Body_ для обраного класу в браузері проекту.
Після генерації програмного коду для компонента «MainATM.exe» кожному класу, реалізованому в даному компоненті, відповідатиме 2 файли з текстом коду на мові ANSI C ++. Так, наприклад, для класу «ATMTransaction» буде згенеровано заголовний файл з розширенням «h» (рис. 4.9) і файл реалізації з розширенням «cpp» (рис. 4.10).
Рис. 4.9.Вид вбудованого текстового редактора з завантаженим в нього заголовного файлу ATMTransaction.h
Рис. 4.10.Вид вбудованого текстового редактора з завантаженим в нього заголовними файлами «ATMTransaction.cpp»
8. Далі робота виконується в обраному інтегрованому середовищі програмування, наприклад, MS Visual C ++ або Borland C ++.
Оформлення результатів роботи
Результати лабораторної роботи оформлюються у вигляді звіту обов'язковими елементами, якого є: титульний аркуш; формулювання мети та завдання на роботу; основна частина; висновки. Зразок титульного листа наведений у Додатку 1.
Основна частина роботи повинна містити етапи вирішення індивідуального завдання шляхом аналізу досягнутих результатів в обраній предметній області.
Висновки повинні містити результати виконаної роботи.
Індивідуальні завдання
Розробити діаграму станів для систем, список яких надано в лабораторній роботі 3.1 або узгодити вибір бізнес-процесів з викладачем.
Запитання для самоперевірки
1. Який порядок генерації коду в середовищі IBM Rational Rose?
2. Які мови програмування підтримує середовище IBM Rational Rose?
3. Які діаграми не є обов’язковими для генерації програмного коду?
4. Який вигляд приймає програмний код після проведення операції генерація коду?
5. Назвати послідовність операцій для вибору мови програмування.
6. Показати порядок вибору компонентів для генерації коду.
7. Назвати порядок дій для перевірки моделі на наявність помилок.
Лабораторна робота 4.4.
ОЦІНКА РОЗМІРУ ТА ВАРТОСТІ ПРОЕКТУ
Мета: набуття навиків у прогнозуванні числових характеристик проектів ПЗ з використанням конструктивної моделі вартості (COnstructive COst MOdel).
Завдання: оцінити витрати на програмування за моделлю СОСОМО.
Основні теоретичні відомості
СОСОМО – це множина моделей, яка дозволяє обчислити вартість проекту ПЗ. В якості одиниці виміру вибрати кількість рядків коду (LOC). СОСОМО дає усереднене значення оцінок. СОСОМО включає наступні моделі:
- базову СОСОМО (застосовується у фазі специфікування вимог);
- проміжну СОСОМО (застосовується у фазах розробки множин вхідних умов проекту, наприклад - досвід персоналу, апаратні обмеженні, обмеження у інструментах розробки);
- удосконалену СОСОМО (застосовується після розробки ПЗ).
Основними виразами базового СОСОМО є:
Е = ab´ (KLOC )bb, (4.1)
D = cbdb, (4.2)
де E - людино-місяці проекту; КLОС - кількість тисяч рядків коду; ab, bb, сb та db коефіцієнти, які дані у табл. 4.2, D - час розробки у календарнихмісяцях.
Таблиця 4.2
Типи проектів
| Тип проекту | ab | bb | cb | db |
| Organic | 2.4 | 1.05 | 2.5 | 0.38 |
| Semi-detached | 3.0 | 1.12 | 2.5 | 0.35 |
| Embedded | 3.6 | 1.20 | 2.5 | 0.32 |
Тип „Organic" представляє відносно невеликий та простий проект, який виношується невеликою командою з добрим досвідом.
Тип „Semi-detached" передбачає середній за розміром та складністю проект, в якому команда має змішаний рівень досвіду і відносно жорсткі вимоги.
Тип „Embedded" представляє проект, який виконується в умовах жорстких технічних, програмних та експлуатаційних обмежень.