1 ЗАГАЛЬНІ ПИТАННЯ АНАЛІЗУ СПОЖИВЧОЇ ЯКОСТІ ІНФОРМАЦІЙНИХ СИСТЕМ БУДІВЕЛЬНИХ ОРГАНІЗАЦІЙ.

1.1 Особливості та структура інформаційних систем будівельних організацій.

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

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

2 МЕТОДИ ПОРІВНЯЛЬНОГО АНАЛІЗУ І ВИБОРУ КОМПОНЕНТІВ ІНФОРМАЦІЙНИХ СИСТЕМ БУДІВЕЛЬНИХ ОРГАНІЗАЦІЙ.

2.2 Порівняльний аналіз кошторисного програмного забезпечення за критерієм функціональної повноти.

2.3 Аналіз та вибір компонентів ІВ будівельних організацій на основі експертних методів.

3 ВІЗУАЛЬНЕ ТА ЕКОНОМІКО-СТАТИСТИЧНЕ МОДЕЛЮВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ БУДІВЕЛЬНИХ ОРГАНІЗАЦІЙ.

3.1 Побудова інформаційної моделі ІС будівельної організації з урахуванням мови UML.

3.2 Моделювання трудовитрат користувачів ІВ будівельних організацій.

3.3 Визначення необхідної кількості ліцензій на програмне забезпечення в ІС будівельної організації.

Рекомендований список дисертацій

• Порівняльна оцінка споживчої якості програмних засобів автоматизації діловодства 2002 рік, кандидат економічних наук Пахомов, Євген В'ячеславович

• Податковий облік: економіко-математичні моделі, методи та програмні засоби для оцінки та мінімізації витрат ресурсів на ведення та моніторинг 2011 рік, доктор економічних наук Батьківщина, Ольга Валеріївна

• Формалізований аналіз предметної галузі та вибір системи підтримки прийняття рішень в управлінні підприємствами: На прикладі підприємств хлібопродуктів 2003 рік, кандидат економічних наук Чувіков, Сергій Володимирович

• Розробка автоматизованої системи визначення вартості будівництва у режимі віддаленого доступу 2007 рік, кандидат технічних наук Спіцин, Олександр Вікторович

• Формування інформаційного забезпечення для побудови та вибору систем автоматизації бухгалтерського обліку у бюджетних організаціях: На прикладі вищих навчальних закладів 2002 рік, кандидат економічних наук Широбокова, Світлана Миколаївна

Введення дисертації (частина автореферату) на тему «Інформаційні системи будівельних організацій: моделювання та оцінка споживчої якості»

Подібні дисертаційні роботи за спеціальністю «Математичні та інструментальні методи економіки», 08.00.13 шифр ВАК

• Економіко-математичні та інструментальні методи забезпечення споживчої якості проектованих інформаційних систем для малих підприємств 2006 рік, доктор економічних наук Шполянська, Ірина Юріївна

• Економіко-математичні моделі з метою оцінки якості інформаційного забезпечення діяльності інвестиційної компанії 2000 рік, кандидат економічних наук П'ятина, Олена Євгенівна

• Моделювання інформаційних процесів у системі управління вузом 2000 рік, кандидат економічних наук Щербаков, Сергій Михайлович

• Аналіз та моделювання інформаційної системи обліку прав на цінні папери 2005 рік, кандидат економічних наук Долженко, Віктор Олексійович

• Розробка та дослідження інформаційних систем для оцінки характеристик споживчої якості програмних продуктів, побудованих з використанням СУБД MS Access, IC Підприємство, ORACLE 2004 рік, кандидат економічних наук Кривошеєва, Марія Олександрівна

Висновок дисертації на тему «Математичні та інструментальні методи економіки», Кудінов, Дмитро В'ячеславович

Список літератури дисертаційного дослідження кандидат економічних наук Кудінов, Дмитро В'ячеславович, 2012 рік

Зверніть увагу, наведені вище наукові тексти розміщені для ознайомлення та отримані за допомогою розпізнавання оригінальних текстів дисертацій (OCR). У зв'язку з чим у них можуть бути помилки, пов'язані з недосконалістю алгоритмів розпізнавання. У PDF файлахдисертацій та авторефератів, які ми доставляємо, подібних помилок немає.

Бурхливий розвиток будівельної індустрії та високі норми прибутковості дозволяли не звертати уваги на втрати у різних стадіях проекту, оскільки ринок за його зростання прощав усі помилки у сфері управління та фінансування.

Система управління — це, перш за все, добре налаштований інструмент для бізнесу. Але важлива не лише «скрипка Страдіварі», украй необхідний і майстер, який візьме інструмент та зіграє на ньому. Таким чином, ми поговоримо про мистецтво — мистецтво створення систем управління бізнесом та мистецтво їх застосування в будівельній індустрії, хоча ці правила стосуються будь-якої галузі після їхнього відповідного коригування. Адже важко придумати щось нове у проектному управлінні чи російському бухгалтерському обліку, у бюджетуванні та управлінському обліку. Відмінності — у деталях, які й формують специфіку кожної галузі та кожного підприємства. Розглянувши роль інформаційних систем на різних етапах будівельного процесу, перейдемо до конкретного досвіду девелоперської компанії "Система-Галс", що представляє бізнес-напрямок "Будівництво та нерухомість" АФК "Система".

Інформаційні системи на різних етапах будівництва

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

Інвестор/керівна компанія

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

Замовник

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

Підрядник

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

Експлуатуюча компанія

У рамках своєї діяльності експлуатуюча компанія насамперед потребує добре поставленого управлінського обліку. Які-небудь додаткові бізнес-процеси відсутні (з розгляду виключено промислову автоматизацію, оскільки вона вважається частиною підсистеми бухгалтерського та управлінського обліку, наприклад, у сфері обліку витрати газу, води, світла тощо).

Проектувальник

Бізнес проектувальника заснований на наданні послуг з проектування та розробки документації та крім документообігу спеціалізованих систем, таких як AutoCad або ArchiCad, та бухгалтерської програми інших систем не потребує. Понад те, цей елемент процесу дуже специфічний і відокремлений з інших може працювати у межах єдиної системи лише області документооборота.

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

Модель взаємодії підприємств представлена ​​на рис. 1. Нормативні та бюджетні, базові техніко-економічні показники спускаються від інвестора/керуючої компанії до замовника, який після уточнення та затвердження спускає їх у вигляді завдання підрядникам. У зворотному порядку як елемент системи контролінгу від підрядника до інвестора піднімається система звітності з повним розшифруванням понесених витрат та причин відхилення від початкових показників. Залежно від того, афілійований підрядник замовнику чи інвестору чи ні, розрізняється і модель інформаційної взаємодії: це може бути робота в єдиній системі з глибокою деталізацією інформації, а може бути випадок, коли генпідрядні організації лише подають відомості про закриття робіт у узгодженому форматі на регулярній основі.

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

Основний механізм контролю над процесом — звітність, що має різні рівні деталізації залежно від специфіки підприємства. Взаємини замовника та підрядника будуються на базі щомісячної звітності щодо виконання та оплати, а також на підставі контролю за ключовими подіями та документацією.

Організація процесу девелопменту у ВАТ «Система-Галс»

ВАТ "Система-Галс" у своїй роботі покриває практично всі етапи будівельного процесу. У цій частині ми розповімо, які інформаційні системи забезпечують діяльність компанії та як вони взаємодіють між собою. Спочатку в «Системі-Галс» планувалося впровадити Oracle E-Business Suite як єдине рішення щодо бізнес-напрямку «Будівництво та нерухомість». Але проаналізувавши всю специфіку діяльності компанії, розглянувши впроваджені в Росії та у світі системи управління для будівельного комплексу та оцінивши бюджети та поставлені терміни, ми вирішили рухатися у трьох напрямках: єдина системадокументообігу, єдина система проектного управління та єдина система фінансового управління. Усі три системи формують інформаційне рішення із загальними ключовими довідниками, потоком інформації та користувачами.

Впровадження почалося із системи документообігу. Нас цікавили такі блоки: контроль за дорученнями, канцелярія, архів документів, бізнес-процеси. Після детального аналізу представлених на ринку продуктів та проведеного тендеру було обрано систему Directum.

У результаті вже за два місяці запрацювала канцелярія, за три — контроль доручень і деякі бізнес-процеси, а архів документів можна було створювати практично відразу. Таким чином, менш ніж за півроку в системі вже працювало понад сто користувачів та понад тридцять компаній.

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

Інші дві системи чітко поділяються на два блоки – проектний та фінансовий облік. Проектний облік стосується основної діяльності компанії – девелопменту. ВАТ «Система-Галс» реалізує велику кількість проектів, керує ними, і це повинно мати прозору, зрозумілу та сучасну основу. В якості такої основи була обрана система, яка, по суті, є промисловим стандартом у світовій практиці управління проектами з календарного планування, — Primavera, розширена модулем PMControlling з обліку договорів, створення первинної документації та бюджетування, що дозволило автоматизувати управління проектами. Спочатку планувалося провести дослідну експлуатаціюна чотирьох пілотних проектах із подальшою передачею у промислову експлуатацію. Але після налаштування системи під бізнес-процеси компанії було вирішено запускати її не за пілотною схемою, а одразу в продуктивну експлуатацію. Таким чином, уже за два місяці в системі велося понад сотню проектів.

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

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

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

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

Вибираючи фінансову систему, ми виходили з того, що нам необхідний досяжний результат за короткий час і розумні гроші. Ситуація сьогодні така, що практично всі великі системи пропонують однакові можливості. Але часто виявляється, що хоч і декларується наявність інструменту, наприклад, з бюджетування, це зовсім не означає, що ви отримаєте його через місяць. Тобто від вас знадобиться кропітка і складна робота з налаштування бюджетної моделі, її відпрацювання та доведення до промислового використання. Таким чином, головне в системі — не лише можливість щось реалізувати і наявність базового функціоналу (як правило, його треба переробляти під потреби компанії), а й швидкість, складність та вартість адаптації під бізнес-моделі.

Є чудовий приклад на цю тему, який демонструвався на системі Microsoft Dynamix AX (Axapta) зі збирання велосипеда. Чим не промислове виробництво? Однак дійсність така, що цей простий приклад дуже далеко віддалений від реальної системи, і знадобиться багато людино-днів перетворення їх у справжній промисловий вид.

Таким чином, проаналізувавши світові та російські системиМи схилилися до платформи «1С:Підприємство». До того ж компанія «1С» декларує підтримку методології ERP, що в принципі нас влаштовувало. Перерахуємо основні блоки, які зазнали автоматизації:

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

Таким чином, ми отримали інтегровану систему (рис. 2), що складається зі спеціалізованих підсистем, що повністю задовольняють кінцевих замовників.

І як фінальний акорд у компанії було створено внутрішній інформаційний портал.

Як ми вже зазначали вище, найбільшою проблемою при впровадженні є небажання людей переходити на нову систему, оскільки для цього потрібно перебудовуватися, а люди здебільшого — консерватори. Але все залежить від керівництва. Якщо топ-менеджмент схвалює ідею та бере участь у політичних питаннях проекту, то перехід на нову систему має пройти гладко. Крім того, всередині компанії треба знайти менеджера, який має великі права з регулювання процесу. Така людина не повинна бути простим фахівцем — це менеджер не нижче за заступника фінансового директора або, наприклад, директора з автоматизації. І при цьому він не повинен мати жодних інших оперативних функцій, крім впровадження. Окремо питання про впровадження потрібно вирішити з основним бухгалтером, оскільки від нього залежить підсумковий перехід на нову систему. Головний бухгалтер — це або основний двигун впровадження, або основне його гальмо. Ще одну складність при впровадженні становить інтеграція різних систем. Ця робота спричиняє синхронізацію величезної кількості даних (як правило, довідників) між системами, що пов'язано з помилками, за якими доводиться стежити щодня. Як правило, інтеграція потрібна, якщо на момент впровадження великої системи вже є добре налагоджена система меншого масштабу, яку краще залишити. Наприклад, якщо при впровадженні інформаційного комплексу вже є працюючий блок виробничого обліку (білінгова система у стільникового оператора, система управління проектами у девелопера або складський облік у логістичної компанії), то в цьому випадку потрібно, по-перше, не зруйнувати його, а по- по-друге, дуже уважно знайти правильний ключ (код) для синхронізації та експорту-імпорту даних між системами.

Поточні ІТ-тенденції у будіндустрії

У сучасному будівельному комплексі намітилася чітка тенденція до використання інформаційних систем у своїй діяльності. Спочатку будівельні компанії не цікавилися інформаційними системами через власні високі доходи і нерозвиненість систем управління. Але з розвитком галузі, ускладненням схем фінансування, виходом на міжнародні ринки, зміною організаційних структур та зростанням бізнесу з'явилася потреба у таких рішеннях (у методології та інструментарії). В результаті багато компаній вступили на шлях автоматизації. Але, як це зазвичай буває, не проводився детальний аналіз потреби, а продукти розглядалися щодо змісту формальних блоків. Більше того, в галузі девелопменту та будівництва системи управління проектами почали розвиватися лише в нафтових компаніях із західним капіталом, що стосується цивільного та інфраструктурного будівництва, то тут розвиток методологій проектного управління та впровадження систем почався лише у 2007—2008 роках. Фінансові системи, включаючи управлінський та бухгалтерський облік, спочатку будувалися на різних платформах – на типізованих промислових рішеннях та власних розробках. Але останнім часом акцент став зміщуватися у бік ERP-систем як російського, і західного походження. Основних причин тут дві: побудова вертикально інтегрованих холдингів за участю виробничих підприємств та структуризація схеми управління компаніями, що ставить перед ІТ-системами найширше коло завдань, вирішення яких кустарними методами в таблицях Microsoft Excel вже неможливо. Це бюджетування та управлінський облік, оперативне планування та казначейство, міжнародна звітність, бухгалтерський та податковий облік, об'єднані єдиними довідниками та побудовані на єдиному плані чи пов'язаній групі рахунків. Таким чином, ми отримуємо складне завдання, яке потребує насамперед методологічного вирішення всіх перелічених питань. У цьому концепцію побудови всієї системи повинні розуміти як фахівці групи впровадження, а й управлінці виробничих і підтримуючих підрозділів.

На цьому полі конкурують лише чотири компанії: SAP, Oracle, «1С» та Microsoft. Вибір між ними є прерогативою підприємства, і радити тут щось складно, тим більше, що питання це часто буває політизовано. Варто зазначити лише, що останнім часом усі системи сильно просунулися у напрямі будівельної специфіки та управління проектами як на російському, так і міжнародному ринку. Але вони призначені для фінансового сектора, а в секторі виробничому все залежить від компанії та її бізнес-процесів. Крупному замовнику, в портфелі якого перебуває понад дві тисячі проектів в активній фазі, підійде хороша системауправлінського обліку та бюджетування, побудована на будь-якій платформі. У той же час для середньої компанії, що має від ста до тисячі проектів, також необхідний індустріальний підхід до проектного управління, але в даному випадку розглядається докладніша деталізація подій, бюджетних статей та ін. У невеликих фірмах, які мають близько п'ятдесяти проектів, застосовується стандартний проектний підхід та відповідна методологія. Отже, маємо три рівні інформаційних систем: промислові, комбіновані, проектні. Інструмент реалізації інформаційної системи на кожному рівні може бути єдиним (наприклад, Primavera плюс PMControlling плюс «1C:Підприємство» або власна розробка плюс Microsoft Dynamix AX), але можуть застосовуватися і локальні інструменти типу Microsoft Project, які не вимагають трудомісткого впровадження.

2/2009 Вісник

ІНФОРМАЦІЙНІ СИСТЕМИ УПРАВЛІННЯ БУДІВЕЛЬНИМИ ПРОЕКТАМИ

Є.Г. Пєнкіна

У сучасному будівельному бізнесі активно використовуються інформаційні технології та спеціалізоване програмне забезпечення. Це системи автоматизованого проектування (САПР), системи управління проектною документацією та кошторисне програмне забезпечення. Кошторисні системи дають оцінку проекту з погляду обсягів робіт, вартості, загальної потреби у ресурсах у проекті, але з надають таких важливих успішного виконання проекту відомостей, як календарний план робіт, графік потреби у ресурсах, календарний профіль витрат.

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

Інформаційна система управління будівельними проектами (ІСУСП) являє собою організаційно-технологічний комплекс методичних, технічних, програмних та інформаційних засобів, спрямований на підтримку та підвищення ефективності процесів планування та управління проектами, в основі якого лежить комплекс спеціалізованого програмного забезпечення.

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

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

Визначення та аналіз ефективності інвестицій;

використання математичних методів розрахунку часових, ресурсних, вартісних параметрів проектів;

Централізоване зберігання інформації з графіку робіт, ресурсів та цін;

Можливість швидкого аналізу впливу змін у графіку, ресурсному забезпеченні та фінансуванні на план проекту;

Забезпечення контролю за виконанням робіт проектів;

Можливість автоматизованої генерації звітів та графічних діаграм, розробки документації за проектом;

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

На сьогоднішній день існує достатня кількість програмного забезпечення для здійснення управління будівельними проектами. Однак далеко не завжди вдається вибрати саме те, що достатньо задовольняє потребам будівельного підприємства. Крім того, навіть виконавши це завдання та обравши правильний комплекс коштів, у більшості випадків підприємству складно попередньо оцінити ефект від впровадження обраного програмного забезпечення.

ВЕСТНИК 2/2009

Нині питання організаційного забезпечення ІСУСП опрацьовано недостатньо добре.

По-перше, відсутня відповідна система критеріїв, що дозволяє здійснювати вибір оптимальної для цієї будівельної організації системи управління будівельними проектами (ІСУСП).

Необхідно розуміти, що програмний продукт не допоможе, якщо не поставлена ​​система управління проектами в організації. Якщо не буде розроблено стандарт та регламенти. Тому первинна система продукт повинен задовольняти вимогам проектованої системи. І тут може виникнути проблема - якщо програмне забезпечення (ПЗ) не забезпечує отримання необхідної інформації, то й користь від нього різко падає. Тому і вибір системи має бути усвідомлений. Потрібно визначити, який продукт необхідний системи управління проектами, що є у будівельної організації.

При цьому алгоритм вибору виглядає так:

1. Сформулювати вимоги до пакета, заздалегідь визначивши необхідні функції. Це важливий етап, оскільки за відсутності належної уваги можуть бути втрачені дуже суттєві вимоги до продукту.

2. Скласти таблицю порівняння специфікацій функцій різних систем. Один із можливих варіантів представлений у табл. 1.

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

Табл. 1. Порівняння специфікацій функцій різних систем

Вимоги під час вибору ПЗ Функції, що реалізуються в системі

Інтерфейс користувача Настроюваний інтерфейс

Контекстна допомога

Зручність доступу до даних

Графічні можливості

Поділ інтерфейсу за ролями

Стандартні майстри, шаблони та подання екрану

Управління даними Зручність доступу та передачі інформації

Захист від несанкціонованого доступу

Інтеграція даних з іншими програмами

Можливості розмежування прав доступу

Наявність функцій OLAP

Механізм планування Використання ієрархічної структури ресурсів

Тимчасовий аналіз за методом критичного шляху

Аналіз вартості та освоєного обсягу

Аналіз ризиків

Використання кількох вихідних планів

Використання шаблонів звітів

Забезпечення спільної роботиНаявність Web-додатків

Архітектура клієнт-сервер

Надання доступу до даних віддалених користувачів

Оповіщення та нагадування про роботи

2/2009 ВЕСТНИК

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

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

Оцінка ефективності ґрунтується на визначенні, виборі критеріїв для розгляду та оцінки системи за цими якостями. Деякі відмінності в наборі критеріїв, які безпосередньо впливають на ефективність проекту, існують і можуть залежати від характеристики будівельних проектів і складу системи, але в цілому вони єдині для всіх (рис. 1).

Управління часом проекту

Управління вартістю проекту

Управління якістю проекту

Управління цілями проекту

Основні

Управління інтеграцією (завершенням) _проекту_

Управління людським та ресурсами

Управління поставками та контрактами

Управління інформацією та комунікаціями

Управління ризиками проекту

Допоміжні

Рис. 1. Критерії оцінки ефективності проекту

Вимоги при виборі ПОФункції, що реалізуються в системіІнтерфейс користувачаКонструктивний інтерфейсКонтекстна допомогаЗручність доступу до данихГра-фічні можливостіРозподіл інтерфейсу за ролямиСтандартні майстри, шаблони та подання екрануУправління данимиЗручність доступу і передачіінформаціїІЗахист -руванняВикористання ієрархічної структури ресурсівТимчасовий аналіз за методом критичного шляхуАналіз вартості та освоєного обсягуАналіз ризиківВикористання кількох вихідних планівВикористання шаблонів звітівЗабезпечення спільної роботиНаявність Web-додатківАрхітектура клієнт-серверНадання доступу до даних віддалених користувачівОповіщення

Кількісна оцінка ефективності інформаційної системи може розраховуватися за такими основними критеріями:

Відхилення за часом - зрушення у розкладі проекту, викликані відставанням або випередженням робіт;

Відхилення за вартістю проекту - відхилення бюджету проекту, спричинені його перевитратою чи недовитратою;

ВЕСТНИК 2/2009

Відхилення за якістю – усунення недоліків, знайдених під час перевірки та оцінки якості – оцінка ефективності роботи команди проекту з усунення недоліків, виявлених у ході виконання проекту.

До кожного певного критерію проекту виробляються вагові показники (к1, к2, к3 тощо.), які відповідають важливості даного критерію.

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

(к1 * АТ + до 2 * АС + до 3 * АТ) АЕ = --- (1)

ДЕ - відхилення від застосування інформаційної системи управління

АТ - відхилення за часом

АС - відхилення щодо вартості проекту

АТ - відхилення за якістю

Значення коефіцієнтів АЕ відповідають розподілам спеціальної складеної шкали, що дозволяє класифікувати відхилення від застосування тієї чи іншої ІСУСП.

Це один із можливих методів кількісної оцінки ефективності інформаційних систем. Також можна використовувати якісні. Наприклад, на основі експертної оцінки критичних факторів успіху (КФУ), виконання яких необхідне для успішної реалізації будівельного проекту.

Ефективність ІСУП залежить від таких факторів, як:

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

Чітке планування робіт - розуміння шляхів досягнення мети (за рахунок яких робіт буде досягнуто мети проекту, в які терміни, які ресурси для цього будуть потрібні);

Облік вимог користувачів - визначає задоволеність системою практичної роботи;

Наявність необхідних технологічних та фінансових засобів;

Наявність підготовленого персоналу (підготовленість співробітників до здійснення проекту конкретного профілю, готовність провести навчання співробітників чи набір відповідних фахівців, інколи залучення консультантів).

Отже, використовуючи як систему критеріїв, і методи оцінки ефективності, можна здійснювати вибір оптимальної системи управління будівельними проектами.

Рецензент: д.т.н., проф. С.А. Синенко, кафедра САПР у будівництві МДСУ

Бурхливий розвиток будівельної індустрії та високі норми прибутковості дозволяли не звертати уваги на втрати у різних стадіях проекту, оскільки ринок за його зростання прощав усі помилки у сфері управління та фінансування.

Але сьогодні часи легких грошей та високоприбуткових проектів минули, і власники дедалі пильніше дивляться на процеси проектного управління. У зв'язку з цим під особливу увагу потрапляють системи управління проектами та управлінського обліку. Крім того, з дрібних компаній, які ведуть один-два проекти, багато хто виріс у лідерів галузі і справлятися з зростанням потоку інформації і тим більше контролювати хід і якість реалізації проектів не в змозі. Ми опускаємо такі питання, як зношеність основних фондів, серйозний рівень непрофесіоналізму над ринком всіх стадіях управління, юридичні і внутрішньокорпоративні складності (хоча зрозуміло, що це у результаті є основним перешкодою у впровадженні систем управління).

Система управління — це, перш за все, добре налаштований інструмент для бізнесу. Але важлива не лише «скрипка Страдіварі», украй необхідний і майстер, який візьме інструмент та зіграє на ньому. Таким чином, ми поговоримо про мистецтво - мистецтво створення систем управління бізнесом та мистецтво їх застосування у будівельній індустрії, хоча ці правила відносяться до будь-якої галузі після їхнього відповідного коригування. Адже важко придумати щось нове у проектному управлінні чи російському бухгалтерському обліку, у бюджетуванні та управлінському обліку. Відмінності - у деталях, які формують специфіку кожної галузі та кожного підприємства. Розглянувши роль інформаційних систем на різних етапах будівельного процесу, перейдемо до конкретного досвіду девелоперської компанії "Система-Галс", що представляє бізнес-напрямок "Будівництво та нерухомість" АФК "Система".

Інформаційні системи на різних етапах будівництва

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

Інвестор/керівна компанія

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

Замовник

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

Підрядник

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

Експлуатуюча компанія

У рамках своєї діяльності експлуатуюча компанія насамперед потребує добре поставленого управлінського обліку. Які-небудь додаткові бізнес-процеси відсутні (з розгляду виключено промислову автоматизацію, оскільки вона вважається частиною підсистеми бухгалтерського та управлінського обліку, наприклад, у сфері обліку витрати газу, води, світла тощо).

Проектувальник

Бізнес проектувальника заснований на наданні послуг з проектування та розробки документації та крім документообігу спеціалізованих систем, таких як AutoCad або ArchiCad, та бухгалтерської програми інших систем не потребує. Понад те, цей елемент процесу дуже специфічний і відокремлений з інших може працювати у межах єдиної системи лише області документооборота.

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

Модель взаємодії підприємств представлена ​​на рис. 1. Нормативні та бюджетні, базові техніко-економічні показники спускаються від інвестора/керуючої компанії до замовника, який після уточнення та затвердження спускає їх у вигляді завдання підрядникам. У зворотному порядку як елемент системи контролінгу від підрядника до інвестора піднімається система звітності з повним розшифруванням понесених витрат та причин відхилення від початкових показників. Залежно від того, афілійований підрядник замовнику чи інвестору чи ні, розрізняється і модель інформаційної взаємодії: це може бути робота в єдиній системі з глибокою деталізацією інформації, а може бути випадок, коли генпідрядні організації лише подають відомості про закриття робіт у узгодженому форматі на регулярній основі.

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

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

Організація процесу девелопменту у ВАТ «Система-Галс»

ВАТ "Система-Галс" у своїй роботі покриває практично всі етапи будівельного процесу. У цій частині ми розповімо, які інформаційні системи забезпечують діяльність компанії та як вони взаємодіють між собою. Спочатку в «Системі-Галс» планувалося впровадити Oracle E-Business Suite як єдине рішення щодо бізнес-напрямку «Будівництво та нерухомість». Але проаналізувавши всю специфіку діяльності підприємства, розглянувши впроваджені у Росії системи управління для будівельного комплексу і оцінивши бюджети і поставлені терміни, ми вирішили рухатися у трьох напрямах: єдина система документообігу, єдина система проектного управління та єдина система фінансового управління. Усі три системи формують інформаційне рішення із загальними ключовими довідниками, потоком інформації та користувачами.

Впровадження почалося із системи документообігу. Нас цікавили такі блоки: контроль за дорученнями, канцелярія, архів документів, бізнес-процеси. Після детального аналізу представлених на ринку продуктів та проведеного тендеру було обрано систему Directum.

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

Основна проблема, з якою довелося зіткнутися, була з людським чинником: по-перше, звички і небажання їх змінювати, а по-друге, страх перебувати під постійним контролем. Саме ці дві причини гальмують експлуатацію системи документообігу.

Інші дві системи чітко поділяються на два блоки – проектний та фінансовий облік. Проектний облік стосується основної діяльності компанії – девелопменту. ВАТ «Система-Галс» реалізує велику кількість проектів, керує ними, і це повинно мати прозору, зрозумілу та сучасну основу. В якості такої основи була обрана система, яка, по суті, є промисловим стандартом у світовій практиці управління проектами з календарного планування, - Primavera, розширена модулем PMControlling з обліку договорів, створення первинної документації та бюджетування, що дозволило автоматизувати управління проектами. Спочатку планувалося провести дослідну експлуатацію на чотирьох пілотних проектах із подальшою передачею у промислову експлуатацію. Але після налаштування системи під бізнес-процеси компанії було вирішено запускати її не за пілотною схемою, а одразу в продуктивну експлуатацію. Таким чином, уже за два місяці в системі велося понад сотню проектів.

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

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

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

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

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

Є чудовий приклад на цю тему, який демонструвався на системі Microsoft Dynamix AX (Axapta) зі збирання велосипеда. Чим не промислове виробництво? Однак дійсність така, що цей простий приклад дуже далеко від реальної системи, і знадобиться багато людино-днів для перетворення їх у справжній промисловий вид.

Таким чином, проаналізувавши світові та російські системи, ми схилилися до платформи «1С:Підприємство». До того ж компанія «1С» декларує підтримку методології ERP, що в принципі нас влаштовувало. Перерахуємо основні блоки, які зазнали автоматизації:

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

Кордони впровадження поширювалися як на «Систему-Галс», а й у всі проектні та операційні компанії. Водночас внутрішня команда впровадження разом із комплексами опрацьовувала методологічні аспекти, що дозволило значно скоротити терміни проекту. Основна стрижнева ідея полягала в тому, що всі системи, включаючи систему управління проектами, повинні ґрунтуватися на єдиному плані рахунків. Виходячи з цієї ідеї в основу було покладено план рахунків МСФЗ, розширений відповідними управлінськими розрізами.

Таким чином, ми отримали інтегровану систему (рис. 2), що складається зі спеціалізованих підсистем, що повністю задовольняють кінцевих замовників.

І як фінальний акорд у компанії було створено внутрішній інформаційний портал.

Як ми вже зазначали вище, найбільшою проблемою при впровадженні є небажання людей переходити на нову систему, оскільки для цього потрібно перебудовуватися, а люди здебільшого – консерватори. Але все залежить від керівництва. Якщо топ-менеджмент схвалює ідею та бере участь у політичних питаннях проекту, то перехід на нову систему має пройти гладко. Крім того, всередині компанії треба знайти менеджера, який має великі права з регулювання процесу. Така людина не повинна бути простим фахівцем - це менеджер не нижче за заступника фінансового директора або, наприклад, директора з автоматизації. І при цьому він не повинен мати жодних інших оперативних функцій, крім впровадження. Окремо питання про впровадження потрібно вирішити з основним бухгалтером, оскільки від нього залежить підсумковий перехід на нову систему. Головний бухгалтер - це або основний двигун впровадження, або основне його гальмо. Ще одну складність при впровадженні становить інтеграція різних систем. Ця робота спричиняє синхронізацію величезної кількості даних (як правило, довідників) між системами, що пов'язано з помилками, за якими доводиться стежити щодня. Як правило, інтеграція потрібна, якщо на момент впровадження великої системи вже є добре налагоджена система меншого масштабу, яку краще залишити. Наприклад, якщо при впровадженні інформаційного комплексу вже є працюючий блок виробничого обліку (білінгова система у стільникового оператора, система управління проектами у девелопера або складський облік у логістичної компанії), то в цьому випадку потрібно, по-перше, не зруйнувати його, а по- по-друге, дуже уважно знайти правильний ключ (код) для синхронізації та експорту-імпорту даних між системами.

Поточні ІТ-тенденції у будіндустрії

У сучасному будівельному комплексі намітилася чітка тенденція до використання інформаційних систем у своїй діяльності. Спочатку будівельні компанії не цікавилися інформаційними системами через власні високі доходи і нерозвиненість систем управління. Але з розвитком галузі, ускладненням схем фінансування, виходом на міжнародні ринки, зміною організаційних структур та зростанням бізнесу з'явилася потреба у таких рішеннях (у методології та інструментарії). В результаті багато компаній вступили на шлях автоматизації. Але, як це зазвичай буває, не проводився детальний аналіз потреби, а продукти розглядалися щодо змісту формальних блоків. Більше того, в галузі девелопменту та будівництва системи управління проектами почали розвиватися тільки в нафтових компаніях із західним капіталом, що стосується цивільного та інфраструктурного будівництва, то тут розвиток методологій проектного управління та впровадження систем розпочався лише у 2007-2008 роках. Фінансові системи, включаючи управлінський та бухгалтерський облік, спочатку будувалися на різних платформах – на типізованих промислових рішеннях та власних розробках. Але останнім часом акцент став зміщуватися у бік ERP-систем як російського, і західного походження. Основних причин тут дві: побудова вертикально інтегрованих холдингів за участю виробничих підприємств та структуризація схеми управління компаніями, що ставить перед ІТ-системами найширше коло завдань, вирішення яких кустарними методами в таблицях Microsoft Excel вже неможливо. Це бюджетування та управлінський облік, оперативне планування та казначейство, міжнародна звітність, бухгалтерський та податковий облік, об'єднані єдиними довідниками та побудовані на єдиному плані чи пов'язаній групі рахунків. Таким чином, ми отримуємо складне завдання, яке потребує насамперед методологічного вирішення всіх перелічених питань. У цьому концепцію побудови всієї системи повинні розуміти як фахівці групи впровадження, а й управлінці виробничих і підтримуючих підрозділів.

На цьому полі конкурують лише чотири компанії: SAP, Oracle, «1С» та Microsoft. Вибір між ними є прерогативою підприємства, і радити тут щось складно, тим більше, що питання це часто буває політизовано. Варто зазначити лише, що останнім часом усі системи сильно просунулися у напрямі будівельної специфіки та управління проектами як на російському, так і міжнародному ринку. Але вони призначені для фінансового сектора, а в секторі виробничому все залежить від компанії та її бізнес-процесів. Величезному замовнику, в портфелі якого перебуває понад дві тисячі проектів в активній фазі, підійде хороша система управлінського обліку та бюджетування, побудована на будь-якій платформі. У той же час для середньої компанії, що має від ста до тисячі проектів, також необхідний індустріальний підхід до проектного управління, але в даному випадку розглядається докладніша деталізація подій, бюджетних статей та ін. У невеликих фірмах, які мають близько п'ятдесяти проектів, застосовується стандартний проектний підхід та відповідна методологія. Отже, маємо три рівні інформаційних систем: промислові, комбіновані, проектні. Інструмент реалізації інформаційної системи на кожному рівні може бути єдиним (наприклад, Primavera плюс PMControlling плюс «1C:Підприємство» або власна розробка плюс Microsoft Dynamix AX), але можуть застосовуватися і локальні інструменти типу Microsoft Project, які не вимагають трудомісткого впровадження.

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

Щодо фінансових систем, то тут переважатимуть тенденції до розвитку систем, які дозволяють за прийнятні бюджетні кошти та терміни вибудувати повнофункціональне рішення.

Денис Бадіков,
Директор Департаменту розвитку систем корпоративного управління ВАТ «Система-Галс»
[email protected]
Максим Кантарович,
Директор з інновацій ВАТ «Система-Галс»
[email protected]

Надіслати свою гарну роботу до бази знань просто. Використовуйте форму нижче

Студенти, аспіранти, молоді вчені, які використовують базу знань у своєму навчанні та роботі, будуть вам дуже вдячні.

Розміщено на http://www.allbest.ru/

Зміст

• Вступ
• 2.2 Нормальні форми
• 2.5 Алгоритм синтезу
• 2.8 Створення схеми даних
• 2.9 Вибір засобів розробки
• 3. Розробка інформаційної системи
• 3.1 Режим користувача
• 3.2 Режим роботи інвестором
• 3.3 Режим роботи управителя
• 3.4 Режим роботи директором
• 4. Безпека та санітарно-гігієнічні умови праці на робочому місці користувача ПЕОМ
• 4.1 Характеристика санітарно-гігієнічних умов праці
• 4.2 Вентиляція
• 4.3 Розрахунок освітлювальної установки
• 4.4 Режим праці
• 4.5 Вимоги щодо організації робочого місця
• 4.6 Електрична безпека
• Висновки
• 5. Розрахунок економічної ефективності проекту
• 5.1 План маркетингу
• 5.2 Цілі, завдання та методи оцінки інвестицій
• 5.3 Вибір та опис розроблюваного та альтернативного варіантів
• 5.4 Розрахунок вкладень на етапі розробки та налагодження основного варіанта
• 5.5 Розрахунок вкладень на етапі розробки та налагодження альтернативного варіанта
• 5.6 Розрахунок вкладень за роками етапу експлуатації
• 5.7 Підсумкові показники техніко-економічної ефективності
• Висновки
• Висновок
• Додаток 1Скрипт створення БД вMYSQL

Вступ

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

p align="justify"> Комп'ютеризація будівництва в технічному плані означає створення автоматизованих робочих місць, оснащених засобами обчислювальної техніки. Складність розв'язуваних управлінських завдань змушує розвивати та використовувати в інвестиційно-будівельній діяльності процеси розробки та впровадження програм, що реалізують конкретні комп'ютерні технологіїна наявних нині технічних засобах. Комп'ютеризація будівництва підвищує рівень знань та навичок у середовищі керівників та виконавців, змушує управлінський персонал ефективно використовувати у своїй повсякденній діяльності наявні засоби обчислювальної техніки з програмним забезпеченням будівельного виробництва.

В інвестиційно-будівельних компаніях широко застосовується інженерна системотехніка будівництва, а саме: автоматизовані системи управління будівництвом (АСУС), системи автоматизованого проектування (САПР), автоматизовані системи обробки даних та документації (АСОД) та інші, що сприяють підвищенню ефективності та якості управління.

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

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

Таким чином, в умовах конкурентної боротьби в ринковій економіці інвестиційно-будівельні компанії постійно потребують інформаційних систем управління. Створення такої системи є метою даної роботи.

1. Проектування інформаційної системи

1.1 Сутність інформаційної системи

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

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

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

1.2 Функціональна специфікація

Система має забезпечувати незалежну роботу наступним категоріям користувачів: директор, керуючі, інвестори та клієнти.

На Головному екрані програми відображається загальна інформація про компанію, її історію, реквізити, побудовані та споруджувані об'єкти нерухомості. Цей екран насамперед призначається для потенційних клієнтів компанії. Також на цьому екрані є кнопка входу до програм для авторизованих користувачів.

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

Інвестори здійснюють фінансування та стежать за перебігом будівництва. Кожен об'єкт може мати кілька Інвесторів, а також один Інвестор може фінансувати кілька об'єктів нерухомості.

автоматизація інформаційна система користувача

Управляючі здійснюють нагляд за будівництвом. Один керуючий може відповідати за один об'єкт нерухомості одночасно. Також керівники займаються питаннями постачання будівельних матеріалів та залученням до роботи будівельників, які на даний момент не зайняті на іншому об'єкті. Будівельник вважається вільним, якщо об'єкт, що будується, готовий.

Будівельники займаються будівництвом об'єкта під керівництвом Керівників. Кожен Будівельник має свою спеціальність.

Матеріали необхідні для будівництва поставляються у необхідній кількості, і їхня вартість є основною статтею витрат Компанії.

1.3 Підходи до проектування ІВ

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

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

· Об'єктно-орієнтований підхід – використовує об'єктну декомпозицію. Система описується термінах об'єктів і зв'язків з-поміж них, а поведінка системи у термінах обміну з-поміж них.

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

З'явилася методологія структурного програмування. Основою даної методології є процедурна декомпозиція програмної системи та організація окремих модуліву вигляді сукупності виконуваних процедур.

У другій половині 80-х років з'явилася методологія об'єктно-орієнтованого програмування

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

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

“Об'єктно-орієнтовані системи більш відкриті та легше піддаються внесенню змін, оскільки їх конструкція базується на стійких формах. Це дає можливість системі розвиватись поступово і не призводить до повної її переробки навіть у разі суттєвих змін вихідних вимог”.

У цьому дипломному проекті використовується методологія об'єктно-орієнтованого підходу для опису бізнес-процесів підприємства.

1.4 Уніфікована мова моделювання UML

В даний час уніфікована мова моделювання UML є візуальною мовою моделювання, яка дозволяє системним архітекторам представити своє бачення системи у стандартній та легкій для розуміння формі. Крім того, UML представляє ефективний механізм спільного використанняпроектних рішень та взаємодії розробників один з одним.

Сформувати бачення системи – надзвичайно важливий момент. До появи мови UML процес розробки часто ґрунтувався на зроблених припущеннях. Системний аналітик повинен був оцінити потреби клієнтів, сформулювати завдання у зрозумілій для фахівця формі, передати результати свого аналізу програмісту і сподіватися, що кінцевий програмний продукт буде саме ту систему, яка потрібна клієнту.

Оскільки процес розробки системи багато в чому залежить від людської діяльності, то будь-якій стадії можуть виникати помилки. Аналітик може неправильно зрозуміти клієнта та створити незрозумілий для нього документ. Результати роботи аналітика можуть виявитися неочевидними для програмістів, які створять складну у використанні програму, яка дозволяє клієнту вирішити вихідне завдання.

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

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

Ключовим аспектом процесу проектування є його правильна організація, коли аналітики, клієнти, програмісти та інші фахівці, які беруть участь у розробці системи, здатні зрозуміти один одного і дійти спільної думки. Мова UML забезпечує таку можливість.

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

Потреба як процес розробки обумовлює необхідність створення стандартних умовних позначень. Мова UML є саме такою системою позначень.

Попередні версії UML почали використовуватися в галузі створення програмного забезпечення, а на підставі відгуків споживачів проводилися суттєві доопрацювання. Багато корпорацій відчули, що мова UML може бути корисною для досягнення їх стратегічних цілей. Це призвело до виникнення консорціуму UML, до якого увійшли такі компанії, як DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments, Rational та інші. У 1997 році консорціум виробив першу версію UML і представив її на розгляд групі OMG (Object Management Group), відгукнувшись на її запит щодо подання пропозицій стандартної мови моделювання.

Після розширення консорціуму вийшла версія 1.1 мови UML, яку група OMG прийняла наприкінці 1997 року. Після цього OMG приступила до супроводу UML і випустила в 1998 дві його нові версії. Мова UML стала стандартом де-факто у галузі розробки програмного забезпечення. В даний час ця мова продовжує активно розвиватися

Мова UML призначена для вирішення наступних завдань:

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

o Забезпечити вихідні поняття мови UML можливістю розширення та спеціалізації для більш точного представлення моделей системи в ООАП (об'єктно-орієнтований аналіз та проектування) конкретної предметної галузі.

o Жодна з конструкцій мови UML не повинна залежати від особливостей її реалізації у відомих мовах програмування.

o Заохочувати розвиток ринку об'єктних інструментальних засобів.

o Здатність удосконалюватися.

o Інтегрувати в себе нові та найкращі досягнення практики

В рамках мови UML уявлення про модель складної системи фіксуються у вигляді спеціальних графічних конструкцій, що отримали назву діаграм. У термінах мови UML визначено такі види діаграм:

· Діаграма варіантів чи прецедентів використання (use case diagram)

· Діаграма класів (class diagram)

· Діаграми поведінки (behavior diagrams)

o Діаграма станів (statechart diagram)

o Діаграма діяльності (activity diagram)

· Діаграми взаємодії (interaction diagrams)

o Діаграма послідовності (sequence diagram)

o Діаграма кооперації (collaboration diagram)

· Діаграми реалізації (implementation diagrams)

o Діаграма компонентів (component diagram)

o Діаграма розгортання (deployment diagram)

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

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

1.5 CASE засіб Rational Rose

Rational Rose – потужний CASE-засіб для проектування програмних систем будь-якої складності. Однією з переваг цього програмного продукту буде можливість використання діаграм мовою UML. Можна сказати, що Rational Rose є графічним редактором UML діаграм

CASE-засіб Rational Rose з часу своєї появи зазнав серйозної еволюції і перетворився на сучасний і потужний засіб аналізу, моделювання та розробки програмних систем. Саме в Rational Rose 98/2000 мова UML стала базовою технологією візуалізації та розробки програм, що визначило популярність та стратегічну перспективність цього інструментарію.

В рамках Rational Rose існують різні програмні інструментарії, що відрізняються між собою діапазоном реалізованих можливостей.

Те, що пакет дозволяє створювати складні програмні системи від задуму до створення вихідного коду, приваблює як проектувальників, а й програмістів - розробників. У поєднанні із засобами документування він дає повне уявлення про проект. Виділимо такі переваги від застосування цього пакета:

· Скорочення час розробки;

· Зменшення ручної праці, збільшення продуктивності;

· Поліпшення споживчих якостей створюваних програм;

· Здатність вести великі проектичи групу проектів;

· дозволяє бути мовою спілкування між різними розробниками.

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

1.6 Діаграма варіантів використання

Розробка даної діаграми має такі цілі:

· Визначити загальні межі та контекст моделюваної предметної області на початкових етапах проектування системи

· Сформулювати загальні вимоги до функціональної поведінки проектованої системи.

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

· Підготувати вихідну документацію для взаємодії розробників системи з її замовниками та користувачами.

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

Кошти Rational Rose дозволяють для опису функціональної системи скористатися графічним редактором для побудови Use Case діаграм (сценаріїв). Опишемо основні елементи див. таблицю 1.1.

Рис 1.1 Діаграма прецедентів

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

Рис.1.2 Діаграма керівника

Діаграмистанів.

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

На діаграмі станів може бути один і лише один початковий стан. У той же час може бути стільки кінцевих станів, скільки вам потрібно або їх може не бути взагалі. Коли об'єкт перебуває у певному стані, можуть виконуватися різні процеси.

Процеси, які у цей момент, коли об'єкт перебуває у певному стані, називаються діями (actions).

Зі станом можна пов'язувати такі дані: діяльність, вхідна дія, вихідна дія та подія.

Діяльність (activity) - це поведінка, що реалізується об'єктом, доки він у цьому стані. Діяльність зображують усередині самого стану; її позначення має передувати слово do (робити) та двокрапка.

Вхідна дія (entry action) - це поведінка, яка виконується, коли об'єкт переходить у цей стан. Вхідну дію також показують усередині стану, його позначення передують слово entry (вхід) та двокрапка.

Вихідна дія (exit action) подібна до вхідної. Однак воно здійснюється як складова частинапроцесу виходу із цього стану. Вихідну дію зображують усередині стану, його опису передують слово exit (вихід) та двокрапка.

Переходом (transition) називається переміщення об'єкта з одного стану до іншого. На діаграмі всі переходи зображують у вигляді стрілки, що починається на початковому стані і закінчується наступним.

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

Рис.1.3 Діаграма станів "Об'єкта будівництва"

Діаграмадіяльності

Виділено об'єкт, дані про який необхідно зберігати у базі даних.

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

Кошти Rational Rose дозволяють для опису функціональної системи скористатися графічним редактором для побудови Activity діаграм (діяльності).

Діаграми діяльностей краще використовувати у таких ситуаціях:

· Аналіз варіанта використання. На цій стадії нас не цікавить зв'язок між діями та об'єктами, а потрібно лише зрозуміти, які дії повинні мати місце та які залежності у поведінці системи. Зв'язування методів та об'єктів виконується пізніше за допомогою діаграм взаємодії;

· Аналіз потоків робіт (workflow) у різних варіантах використання. Коли варіанти використання взаємодіють друг з одним, діаграми діяльностей є сильним засобом уявлення та аналізу їхньої поведінки.

Рис.1.4 Діаграма активності "Створення об'єкта"

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

Діаграми взаємодії

Діаграми взаємодії (interaction diagrams) описують поведінку взаємодіючих груп об'єктів. Кожна діаграма описує поведінку об'єктів лише одного прецеденту. На діаграмі зображуються об'єкти і ті повідомлення, якими обмінюються між собою. Визначають три типи повідомлень:

· Інформаційні (informative) - повідомлення, що забезпечують об'єкт-одержувач інформацією для оновлення його стану;

· Повідомлення - запити (interrogative) - повідомлення, що вимагають видачу інформації про об'єкт-одержувача;

· Імперативні (imperative) - повідомлення, що запитують у об'єкта-отримувача виконання дії.

Існує два види діаграм взаємодії:

· Послідовності (sequence diagrams);

· Кооперативні (collaboration diagrams).

На діаграмі послідовності об'єкт зображується у вигляді прямокутника на вершині пунктирної вертикальної лінії. Ця вертикальна лінія називається лінією життя (lifeline) об'єкта. Вона є фрагментом життєвого циклу об'єкта у процесі взаємодії.

Кожне повідомлення відображається у вигляді стрілки між лініями життя двох об'єктів. Повідомлення з'являються, як показано на сторінці, зверху вниз. Кожне повідомлення позначається щонайменше ім'ям повідомлення; при бажанні можна додати також аргументи та деяку керуючу інформацію і, крім того, показати самоделегування (self-delegation) - повідомлення, яке об'єкт посилає самому собі, при цьому стрілка повідомлення вказує на ту саму лінію життя.

Рис.1.5 Діаграма послідовності "Призначення будівельника на об'єкт"

Висновок по діаграмі: виділено об'єкти сутності (список користувачів, об'єкт, список будівельників) та граничні об'єкти – сторінки (вікно введення пароля, вікно поточного об'єкта).

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

Рис.1.6. Кооперативна діаграма "Призначення будівельника на об'єкт

Алгоритм роботи із системою через WEB-інтерфейс

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

Для проектування веб-сайту вживається діаграма класів.

Rational Rose містить Add In під назвою Web Modeler для проектування сайтів.

Послідовність дій під час створення Web програми:

ü Підключити Web Modeler за допомогою пункту меню Add In - Add In Manager - Web Modeler. У меню Tools з'явиться новий пункт Web Modeler

ü Змінити установки, прийняті за умовчанням Tools - Options - Notation - Default Language - Web Notation

Використовується спеціальний стереотип, що дозволяє виділяти html-сторінки. На основі створеної діаграми автоматично генерується пов'язані HTML-сторінки.

Рис.1.7 Алгоритм роботи з програмою

2. Проектування бази даних

2.1 Вимоги до бази даних

1) Мінімальна надмірність. Дані, які у пам'яті ЕОМ, можуть містити як корисну, і шкідливу надмірність. Шкідлива надмірність завжди має місце, коли кожен користувач змушений створювати для своїх додатків окремий набір даних. Якщо декільком користувачам були б одні й самі дані, всі вони повторювалися у кожному наборі. Таку надмірність часто називають неконтрольованою, оскільки про її існування окремі користувачі можуть і не підозрювати. До корисної надмірності можна віднести періодичні копії даних, що зберігаються в базі даних. Ця надмірність легко контролюється. Більше того, вона є необхідною, наприклад, для відновлення даних, зруйнованих при випадкових збоях у роботі ЕОМ. Таким чином, вимогу мінімальної надмірності слід розуміти як усунення шкідливої ​​(неконтрольованої) та зведення до мінімуму корисної (контрольованої) надмірності.

2) Цілісність даних. Цілісність даних полягає у підтримці правильності даних. Забезпечується відновленням даних після руйнування в результаті випадкових збоїв у роботі ЕОМ, а також усунення суперечливості даних, що полягає у появі різних екземплярів для тих самих атрибутів. Суперечливість може з'явитися при оновленні надлишкових даних, якщо оновлення буде виконано лише на частині даних.

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

4) Незалежність даних. Забезпечує можливість зміни структури баз даних без зміни прикладних програм користувачів. Розуміється у двох аспектах, а саме, як логічна та фізична незалежність.

Логічна незалежність пропонує можливість зміни логічної структури баз даних, не торкаючись прикладних програм.

Фізична незалежність має на увазі таку ж можливість фізичної структури баз даних, включаючи як способи розміщення даних на фізичних носіях, так і методи доступу до даних (тобто операції пошуку, читання та запису даних на згадку про ЕОМ). Забезпечення незалежності даних є основною метою, що переслідується під час створення бази даних.

5) Продуктивність. Характеризується часом відповіді інформаційної системи, що використовує бази даних, запити користувачів. При цьому, запити на дані повинні задовольнятися з такою швидкістю, яка потрібна для використання даних.

6) Гнучкість та здатність до розширення. Розуміється як здатність бази даних до нарощування даних, а також збільшення кількості можливих додатків та розширення функцій у межах кожної програми.

2.2 Нормальні форми

Реляційна база даних, спроектована відповідно до концептуальної схеми, може мати ряд серйозних недоліків, наприклад, містити інформаційну надмірність, і (або) у процесі обробки даних можуть виникати різні аномалії. Щоб усунути ці недоліки, тобто. Створити базу даних "хорошої", необхідно привести всі відносини бази даних до "сильних" нормальних форм.

Нині відомо кілька нормальних форм. Перша нормальна форма (позначатимемо 1НФ), далі - у міру "посилення" - 2НФ, 3НФ, нормальна форма Бойса-Кодда (НФБК) та 4 НФ. Практика показує, що приведення БД хоча б до 3НФ дозволяє уникнути здебільшого майже всіх недоліків.

Перша нормальна форма (1НФ).

Відношення зі схемою R та безліччю функціональних залежностей F знаходиться в 1НФ, якщо будь-який екземпляр схеми R задовольняє наступним умовам:

кожен атрибут схеми має унікальне ім'я;

елементи кортежів з тим самим ім'ям повинні бути визначені на тому самому домені;

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

кожен елемент кортежу повинен мати єдине значення, групи значень, що повторюються, неприпустимі;

щодо не повинно бути кортежів, що повторюються.

Друга нормальна форма (2 НФ).

Відношення зі схемою R і безліччю функціональних залежностей F знаходиться у 2НФ, якщо воно знаходиться в 1НФ, і кожен неключовий атрибут функціонально повно залежить від будь-якого можливого первинного ключа схеми-відносини R.

Проте, схема зв'язку, що у 2 НФ, також має недоліки. Зокрема, множина залежностей, визначена на цій схемі, може містити транзитивні залежності, які можуть призводити до небажаних наслідків (аномалій видалення).

Третя нормальна форма (3 НФ).

Схема відносин R з безліччю функціональних залежностей F знаходиться в 3НФ, якщо воно знаходиться у 2 НФ, і кожен неключовий атрибут прямо, а не транзитивно залежить від будь-якого можливого ключа схеми відношення.

Однак, 3НФ може мати недоліки, пов'язані з ключовими атрибутами. У наведеному прикладі отримана 3 НФ не викликає аномалій при обробці даних, так як в результуючих декомпозиційних підсхеми відсутні залежності ключових атрибутів від інших атрибутів. Якщо ця умова порушується, то можливі аномалії обробки даних.

Нормальна форма Бойса Кодда (НФБК).

Нормальна форма Бойса-Кодда "сильніша", ніж третя нормальна форма. Схема відносин R з безліччю функціональних залежностей F знаходиться в НФБК, якщо ліва частина кожної залежності (ХА) F, де А Х є первинний або можливий первинний ключ.

Якщо ставлення перебуває у НФБК, воно перебуває й у третій нормальній формі, але з навпаки.

Теоретично реляційних баз даних доведено, що будь-яке відношення може бути замінено набором декомпозиційних підсхем, кожна з яких перебуватиме в 3НФ, а декомпозиція матиме як властивість сполуки без втрат інформації, так і властивість збереження вихідної множини функціональних залежностей. При приведенні до НФБК у випадку гарантується лише здійсненність якості з'єднання без втрат інформації.

2.3 Нормалізація схем відносин

Для побудови реляційної реалізації концептуальної схеми БД, яка була хоча б у 3 НФ, можна використовувати два способи:

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

метод синтезу, що полягає у конструюванні (синтезі) набору декомпозиційних підсхем, що задовольняють певним властивостям, із заданої множини атрибутів обраної предметної області на основі заданої множини функціональних залежностей, що зв'язують ці атрибути.

Обидва методи повинні забезпечити збереження результуючої декомпозиції як властивості з'єднання без втрат інформації, так і збереження функціональних залежностей.

На практиці частіше використовується метод синтезу, оскільки метод декомпозиції має низку серйозних недоліків. Зазначимо основні їх.

Складність алгоритму вища, ніж поліноміальна.

Число породжених декомпозиційних підсхем може виявитися значно більшим, ніж необхідно, при цьому інформацію про них треба обов'язково зберігати на кожному кроці розбиття, та й сам алгоритм розбиття досить складний.

При декомпозиції схеми відношення можуть виникнути часткові залежності, які можуть породжувати в результаті зайві декомпозиційні підсхеми.

2.4 Інтеграція власних уявлень

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

Інтегрованеподаннякористувачів,представленеввиглядідіаграми

2.5 Алгоритм синтезу

Вихідними для роботи алгоритму синтезу є безліч атрибутів U і безліч функціональних залежностей F, визначене на U.

Результатом роботи алгоритму є схема автоматизованої системи управління у вигляді набору декомпозиційних підсхем (R1, R2,., Rp), що задовольняють наступним умовам.

Кожна підсхема Ri з БД повинна бути хоча б у ЗНФ щодо безлічі функціональних залежностей F і відповідно G.

Синтезована інформаційна система містить мінімальний набір декомпозиційних підсхем Ri, I == 1,., Р. Ця умова захищає інформаційну систему від надмірності.

Для будь-якого екземпляра r (БД), що задовольняє F, виконується співвідношення. Ця умова гарантує здійсненність якості з'єднання без втрат інформації.

Схема автоматизованої системи управління, що задовольняє умовам 1,2 та 3, називається повною схемою автоматизованої системи управління.

Розглянемо кроки алгоритму.

Крок1 . Будуємо розширене безліч F функціональних залежностей, що має наступну структуру залежностей:

F = ((X I -> Y I) | (X I -> Y I) F, Y I = X I + \ X I). Цей крок робиться з метою побудови надлишкового або умовно ненадлишкового покриття F, що дозволить певною мірою задовольнити умову 3. Повністю забезпечити умову 3 вдасться після введення в розгляд поняття еквівалентності функціональних залежностей на кроці 5.

Крок 2. Будуємо надлишкове покриття F, виключаючи з F у будь-якій послідовності зайві залежності.

Очевидно, це покриття не канонічне.

Крок3 . Якщо серед функціональних залежностей з F" немає залежності, що включає всі атрибути з U, то додаємо до F" тривіальну залежність U-> Ш.

Крок4 . Перетворюємо отримані нетривіальні залежності елементарному виду (без зайвих атрибутів у лівих частинах).

Залежність X I - > Y I є елементарною, якщо не існує таких наборів атрибутів X J X I , що (X j - > Y I ) . Якщо - існує, то залежність X I - > Y I замінюється залежністю (X J - > Y I).

Крок 5. Розбиваємо множину отриманих залежностей на класи еквівалентності. Це робиться для того, щоб на наступному кроці залишити в кожному класі одного представника, тим самим мінімізувати кількість декомпозиційних підсхем результуючої БД і повністю задовольнити умові 3.

Залежності X I - >Y I і X J - > Y J називатимемо еквівалентними, якщо

, тобто. мінімальний ранг має залежність, що містить усі атрибути з U, а якщо її немає, то - тривіальна залежність U - > Ш. Всім залежностям із одного класу еквівалентності призначаємо однаковий ранг. Незрівнянним залежностям ранги призначаємо довільно.

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

Крок7 . Виконуємо транзитивну редукцію залежностей із більшим рангом залежно з меншим рангом. Рухаючись по діаграмі знизу вгору (від залежностей з більшим рангом до залежностей з меншим рангом), для кожної поточної залежності виключаємо з правих частин всіх залежностей, розташованих вище поточної, атрибути, які містяться в правій частині поточної залежності (для тривіальної залежності атрибути виключаємо її лівої частини).

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

Безлічатрибутів:

U = (mNo, mName, mCost, count, oNo, oAddress, oType, oStoreys, oState, eNo, eName, ePost, eState, eSalary, sum, iNo, iName, iPhone)

Безлічфункціональнихзалежностей:

F = (mNo®mName, mNo®mCost, mName®mNo, mName®mCost,

(oNo, mNo) ®count,

oNo®oAddress, oNo®oType, oNo®oStoreys, oNo®eNo, oNo®oState, oNo®oCost

eNo®eName, eNo®ePost, eNo®eState, eSalary

iNo®iName, iNo®iPhone,

(iNo, oNo) ®sum )

Крок 1. Розширена множина функціональних залежностей:

mNo + =mNo, mName, mCost =>mNo® (mName, mCost)

mNo + =…=>mNo®…

(oNo, mNo) + = oNo, mNo, count => (oNo, mNo) ?®count

oNo + = oNo, oAddress, oType, oStoreys, oState, oCost, eNo => oNo® (oAddress, oType, oStoreys, eNo, oState, oCost)

oNo + =…=>oNo®…

eNo + = eNo, eName, ePost, eState, eSalary => eNo® (eName, ePost, eState, eSalary)

eNo + =…=>eNo®…

iNo + = iNo, iName, iPhone => iNo® (iName, iPhone)

iNo + =…=>iNo®…

(iNo, oNo) + =iNo, oNo, sum=> (iNo, oNo) ®sum

(mNo, oNo, iNo, eNo) + =mNo, mName, mCost, count, sum, oNo, oAddress, oType, oStoreys, iNo, iName, iPhone, eNo, eName, ePost, eState, eSalary, oState, oCost

=> (mNo, oNo, iNo, eNo) ® (mName, mCost, count, sum, oAddress, oType, oStoreys, oState, iName, iPhone, eName, ePost, eState, eSalary, oCost)

F= (mNo® (mName, mCost), mNo®…, (oNo, mNo) ?®count, oNo® (oAddress, oType, oStoreys, eNo, oState, oCost), oNo®…, eNo® (eName, ePost, eState, eSalary), eNo®…, iNo® (iName, iPhone), iNo®…, (iNo, oNo) ®sum, (mNo, oNo, iNo, eNo) ® (mName, mCost, count, sum, oAddress, oType, oStoreys, oState, iName, iPhone, eName, ePost, eState, eSalary) )

Крок 2. Надлишкове покриття

F"= (mNo® (mName, mCost), (oNo, mNo) ?®count, oNo® (oAddress, oType, oStoreys, oState, oCost, eNo), eNo® (eName, ePost, eState, eSalary), iNo® (iName , iPhone), (iNo, oNo) ®sum, (mNo, oNo, iNo, eNo) ® (mName, mCost, count, sum, oAddress, oType, oStoreys, iName, iPhone, eName, ePost, eState, eSalary) )

Крок 3. Тривіальна залежність

Тривіальну залежність додавати не потрібно, оскільки є залежність, що містить повний набір атрибутів.

Крок 4. Елементарний вид залежностей

Усі залежності елементарні.

Крок 5. Еквівалентність залежностей

Еквівалентних залежностей немає.

Крок 6. Ранжування залежностей

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

Залежно X I Y I і X J Y J будемо називати еквівалентними, якщо (X I Y I) = (X J Y J).

Ранжуємо отримані залежності за наступним правилом rang (X I Y I) > rang (X J Y J), якщо (X I Y I) (X J Y J).

Всім залежностям із одного класу еквівалентності призначаємо однаковий ранг. Незрівнянним залежностям ранги призначаємо довільно.

Крок 7. Діаграма ранжованих залежностей (2 НФ):

У кожному класі еквівалентних залежностей залишаємо по одному представнику. З таблиці видно, що у разі еквівалентних залежностей немає.

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

Виконуємо транзитивну редукцію залежностей з більшим рангом залежно з меншим рангом в такий спосіб.

Рухаючись по діаграмі знизу - вгору (від залежностей з більшим рангом до залежностей з меншим рангом), для кожної поточної залежності виключаємо з правих частин всіх залежностей, розташованих вище поточної, атрибути, які містяться в правій частині поточної залежності (для тривіальної залежності атрибути виключаємо з її лівої частини).

Крок 8. Отримуємо сукупність декомпозиційних підсхем

Після проходження алгоритму було отримано 6 таблиць із відповідними первинними ключами:

R1 = oNo, oAddress, oType, oStoreys, oState, oCost, eNoз ключем oNo

R2 = eNo, eName, ePost, eState, eSalary з ключем eNo

R3 = oNo, mNo, count з ключем (oNo, mNo)

R4 = mNo, mName, mCostз ключемmNo

R5 = iNo, iName, iPhone з ключем iNo

R6 = iNo, oNo, sum з ключем (iNo, oNo)

Rational Rose Data Modeler засіб проектування БД

Автори Data Modeler передусім орієнтувалися створення інструменту проектування фізичної моделі даних. При цьому не відбулося відмови від UML як від засобу моделювання даних, а деяким чином було зміщено акценти: тепер UML передбачається використовувати для побудови логічної моделі. По суті, логічна модель - це та сама об'єктна модель, що складається з об'єктів - сутностей. Перехід від логічної моделі до фізичної та навпаки в частині моделювання даних забезпечується Rational Rose автоматично. Для цього введено відповідність елементів моделей.

Таблиця 2.1 Відповідність елементів логічної та фізичної моделі

Таким чином, концептуально модуль Data Modeler не є заміною UML у деякому його підмножині, а лише дає прихильникам об'єктних технологій потужний засіб ефективної побудови фізичних схем БД.

Перелік основних можливостей Data Modeler включає:

1. Data Modeler підтримує більшість можливостей структурних CASE-засобів щодо фізичного моделювання даних;

2. Data Modeler забезпечує генерацію ефективної фізичної структури БД, що підтримує механізми забезпечення цілісності посилання;

3. Data Modeler тісно інтегрований з Rational Rose, а діаграма Data Model природним чином вписується в загальну технологію розробки програмного забезпечення з використанням лінійки продуктів фірми Rational Software Corporation;

4. Можна відмовитись від інтеграції Rational Rose з іншими засобами генерації фізичних моделей.

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

Створення логічної моделі

Основні компоненти діаграми Data Modeler – це сутності, атрибути та зв'язки. Кожна сутність є безліччю подібних індивідуальних об'єктів, званих екземплярами. Кожен екземпляр індивідуальний і має відрізнятися від решти екземплярів. Атрибут виражає певну властивість об'єкта. На фізичному рівні сутності відповідає таблиця, екземпляру сутності – рядок у таблиці, а атрибуту – колонка таблиці.

Робота Data Modeler заснована на відомому механізмі відображення об'єктної моделі реляційну. Результатом є побудова діаграми "сутність - зв'язок" та подальша генерація опису бази даних на SQL.

Діаграма класів (class diagram) служить уявлення статичної структури моделі системи у термінології класів об'єктно-орієнтованого програмування. Діаграма класів може відображати, зокрема, різні взаємозв'язки між окремими сутностями предметної області, такими як об'єкти та підсистеми, а також описує їхню внутрішню структуру та типи відносин. На цій діаграмі не вказується інформація про тимчасові аспекти функціонування системи. З цього погляду діаграма класів є подальшим розвитком концептуальної моделі проектованої системи.

Подібні документи

Вивчення теорії управління освітніми установами та ВНЗ. Проектування, реалізація та впровадження автоматизованої інформаційної системи для автоматизації кафедри ВНЗ. Опис розробленої системи, розрахунок економічної ефективності проекту.

дипломна робота , доданий 09.03.2010


Вивчення діяльності компанії "Пітер-Лада". Структура управління мережею автосалонів. Уніфікована мова моделювання UML. Проектування логічної моделі баз даних. Кошти, що використовуються для побудови системи обліку. Розрахунок ефективності інвестицій.

дипломна робота , доданий 05.06.2011


Логічне проектування бази даних автоматизації діяльності будівельної компанії. Класифікація зв'язків. Реляційна модель бази даних Функціональні залежності між атрибутами. Вибір ключів. Нормалізація відносин. Запити до бази даних.

курсова робота , доданий 26.05.2015


Проектування функціональної структури підсистеми "Склад". Даталогічне проектування інформаційної базиданих та опис застосовуваних засобів захисту інформації. Особливості роботи з NET Framework. Розрахунок економічної ефективності проекту.

дипломна робота , доданий 29.06.2011


Автоматизація процесу підбору кандидатів прийому працювати. Проектування системи тестування кадрового відділу компанії, її інформаційне забезпечення. Проектування бази даних та її інтерфейсу. Розрахунок економічної ефективності проекту.

дипломна робота , доданий 22.03.2017


Створення інформаційної системи для автоматизації діяльності компанії щодо реєстрації доставки вантажів транспортної компанії. Аналіз предметної галузі. Методологія функціонального моделювання IDEF0. Контекстна діаграма. Вартісний аналіз у BPwin.

контрольна робота , доданий 05.02.2014


Концепція бази даних, моделі даних. Класифікація бази даних. Системи керування базами даних. Етапи, підходи до проектування баз даних. Розробка бази даних, яка дозволить автоматизувати ведення документації необхідної для діяльності ДЮСШ.

курсова робота , доданий 04.06.2015


Створення бази даних інформаційної системи для обліку продажу побутової технікиі автоматизації документообігу в phpMyAdmin. Функціональна діаграма IDEF0. Створення нового користувача, таблиць, записів у таблиці. Організація сайту на локальному сервері

курсова робота , доданий 11.05.2014


Розробка інформаційної системи "Салон портьєр" для автоматизації діяльності менеджера фірми, що займається пошиттям портьєр на замовлення. Створення та обґрунтування проекту бази даних. Створення запитів, форм, звітів. Тестування програмної програми.

курсова робота , доданий 07.02.2016


Аналіз існуючих розробок та вибір стратегії автоматизації діловодства в взаємовідносинах постачальників лікарських препаратів з аптекою. Розробка проекту бази даних аптеки "Рігла". Обґрунтування економічної ефективності розроблення бази даних.