лучшие книги по экономике
Главная страница

Главная

Замовити роботу

Последние поступления

Форум

Создай свою тему

Карта сайта

Обратная связь

Статьи партнёров


Замовити роботу
Книги по
алфавиту

Б
В
Г
Д
Е
Ж
З
И
К
Л
М
Н
О

системи підтримки прийняття рішень

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]

 

Розділ 8

Створення, впровадження та оцінювання СППР

8.1. Концептуальні засади розроблення СППР


8.1.1. Підходи до створення СППР


Загальні зауваження
У літературних джерелах із СППР наводяться різні підходи до проектування і розроблення таких систем. Кожний із авторів не погоджується з тим, що якась одна з цих методологій є найкращою для побудови різних типів СППР. Проте, якщо менеджери і аналітики СППР добре розуміють різні методи, то вони можуть бути інформованішими і можуть запропонувати кращі альтернативи для побудови або купівлі специфічної СППР.
У сьомому розділі були розглянуті різні підходи (школи) щодо створення СППР. Хоча, як уже зазначалося, в «чистому» вигляді жодний із них не застосовується, проте можна зробити деякі узагальнення. Школи аналізу рішень, числення рішень і дослідження рішень реалізують так званий орієнтований на рішення підхід, а школа процесу впровадження (реалізації) — відстоює метод, орієнтований на процес створення СППР. Інколи цей метод називають еволюційним методом розроблення.
На думку багатьох авторів, орієнтований на рішення підхід здається найкращим для проектування СППР. Методологія розроблення СППР у межах цього підходу включає три кроки:

  1. Проведення орієнтованої на рішення діагностики.
  2. Аналіз технічної здійснюваності проекту чи його техніко-економічне обґрунтування.
  3. Розв’язання принципового питання: купувати готове чи створювати програмне забезпечення СППР.

Згідно з Пауером, якщо прийнято рішення спроектувати нову СППР (http://dssresources.com/dssbookslides/ch4desdev/sld001(до 0026).htm), то в розпорядженні розробників є три альтернативні підходи:

  1. Підхід на основі розроблення життєвого циклу системи SDLS (Systems Development Life Cycle). Інколи його називають одностайним (завершена система). Як буде показано пізніше, у ньому часто застосовується макетування (прототипування) СППР.
  2. Швидке прототипування (Rapid Prototyping). Часто цей підхід ще називають методом швидкого успіху (Quick-Hit Method, дослівно — метод натискування клавіш) або стрімким розробленням додатку (rapid application development — RAD). Він передбачає широке застосування різних технологій, зокрема, СППР-генераторів.
  3. Розроблення кінцевим користувачем (End-User Develop­ment), тобто дати змогу менеджерам самим розробити для себе СППР, використовуючи технологічні засоби типу СППР-інструментарій і СППР-генератор.

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

Діагностика процесів прийняття рішень

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

  1. Організація збору даних щодо поточного прийняття рішення з використанням різних методів як, наприклад, інтерв’ю, спостереження, анкетування і хронологічних записів (ці та інші методи будуть описані пізніше);
  2. Когерентне (взаємозв’язане) описування поточного процесу прийняття рішення;
  3. Специфікація нормативних вимог щодо того, як рішення мають розроблятися в майбутньому з урахуванням створення СППР.

Ці дії взаємозалежні і забезпечують зворотний зв’язок для аналітика. У багатьох СППР за розроблення проектів ще не дотримуються того, щоб виконати повномасштабну діагностику процесу прийняття рішень. Скорочене дослідження часто необхідне завдяки витратним міркуванням, обмеженням доступу до менеджерів або через інші організаційні обмеження. Як наслідок, аналітики СППР мають виконувати продуктивну діагностику тільки після обмеженого дослідження ситуації.
Інколи в процесі діагностики використовується метод критичних факторів успіху (Critical Success FactorsCSF), за якого проектування фокусується на окремих менеджерах та на поточних постійних і програмованих їхніх інформаційних потребах. Якщо організаційні цілі потім були досягнуті, то ці ключові ділянки активності (зазвичай, від трьох до шести факторів) мають потребувати ретельної і узгодженої уваги від менеджерів.
Діагностика процесів прийняття рішення має закінчитися підготовкою техніко-економічного обґрунтування (ТЕО) СППР. ТЕО містить ключові питання і умови щодо майбутньої СППР,
а також відповідь на запитання: «Побудувати чи придбати СППР?» Якщо прийнято рішення створити СППР, то потрібно вибрати один із трьох підходів для цього (на основі життєвого циклу системи, швидке макетування чи розроблення кінцевим користувачем).
Оскільки методологія підходу до розроблення СППР на основі розроблення життєвого циклу систем і питання щодо макетування (прототипування) будуть далі розглянуті окремо, то стисло зупинимося на розробленні СППР кінцевим користувачем і стрімкому розробленні додатку RAD.
Розроблення СППР кінцевим користувачем
За розроблення СППР кінцевим користувачем відповідальність за формування і супроводження СППР повністю лягає на менеджера, який її будує. Наразі розроблене потужне програмне забезпечення кінцевого користувача, доступне для менеджерів, і тому багато менеджерів мають здатність і відчувають потребу в розробленні своєї настільної СППР. Вони часто використовують електронні таблиці, подібні до таблиць Microsoft Excel чи Lotus 1-2-3 як інструментальні засоби розроблення СППР. Використовуючи пакет електронних таблиць, менеджери можуть аналізувати широкий діапазон питань, зокрема, вплив різних бюджетних операцій на корпоративні цілі чи цілі окремих департаментів або відділень. Виходячи з наслідків такого аналізу, вони вибирають альтернативу, що найкраще відповідає потребі їхнього відділу чи корпорації. Також, менеджери можуть розробляти відповідні інструментальні засоби з метою полегшення аналізу стану ринку, робити проекти і прогнози на своєму робочому місці.
Головною перевагою розроблення СППР самим кінцевим користувачем є те, що особа, яка хоче мати комп’ютерну підтримку, буде сама її створювати. Менеджер, який сам будує СПРР, повністю контролює ситуації і розв’язки, які отримує. Розроблення СППР кінцевим користувачем може також інколи швидше закінчитися і забезпечити економію витрат.
Розроблення кінцевим користувачем комплексної СППР є менш бажаним. Менеджерам платять за те, щоб управляти, а не за те, щоб розробляти системи підтримки прийняття рішень. Відомо, що професіонали з інформаційних технологій можуть цю роботу виконати значно краще і набагато швидше. Також менеджери не підготовлені для тестування системи, створення документації, забезпечення нагромадження і захисту даних та розроблення досконалого інтерфейсу користувача. Аналітики СППР мають допомогти менеджерам розробити комплексніший проект підтримки прийняття рішень. Вони можуть допомогти менеджеру будувати, документувати і тестувати додаток. Менеджерам потрібно робити наголос на змісті СППР і не занадто бути залученим до розширеного проектування і розроблення СППР.
Стрімке розроблення додатку RAD
Методологією розроблення додатків інформаційних систем, яка має на меті забезпечити швидку відповідь на потреби користувача, є стрімке розроблення додатка (rapid application development (RAD). Цей термін, який запропонований комп’ютер­ним консультантом Мартіном Ямесом (Martin James), стосується швидкого створення життєвого циклу системи без погіршення її якості. Для цього підходу застосовуються й інші назви: швидке прототипування (Rapid Prototyping) або метод швидкого успіху (Quick-Hit Method, дослівно — метод натискування клавіш). Підхід передбачає широке застосування різних технологічних засобів, зокрема, СППР-генераторів. Проте загальноприйнятих стандартів RAD щодо окреслення етапів і фаз розроблення інформа­ційних систем та діапазону застосовуваних технологічних засобів поки що не розроблено. Різні автори по-своєму трактують цю методологію.
Стрімке розроблення додатка (RAD) — це інтегрований ряд підходів, методологій та інструментальних засобів, що в сукупності утворюють загальну стратегію розроблення СППР, яка називається інформаційним інжинірингом. Термін «інформаційний інжиніринг» (Information engineering — IE) — запропонував M. Ямес для означення загального підходу до розроблення системи, що трактується як дії в межах фірми (підприємства).
На застосування RAD суттєво впливають такі істотні елементи: персонал управління, робоча сила, методології й інструментальні засоби. Управлінський песонал має повністю підтримувати RAD і забезпечити умови для праці, які сприяли б вищій активності і швидкому створенню інформаційної системи.
Стосовно робочої сили, то скоріше, ніж використовувати одну команду, яка виконує всі дії з проектування життєвого циклу системи, RAD передбачає можливість використовувати кілька спе­ціалізованих команд, що ефективніше. Члени цих команд мають бути фахівцями з методологій і інструментальних засобів розроб­лення систем, щоб виконати спеціалізовані завдання для швидкого створення системи. M. Ямес використовує термін «SWAT team» — команда SWAT, де SWAT — абревіатура від «skilled with advanced tools».
Основна методологія RAD — це швидке розроблення життєвого циклу, що складається з чотирьох фаз: планування вимог, проектування для користувача (user design), конструювання і перемикання на нову систему (cutover). До методологічних засобів RAD належить і макетування.
Інструментальні засоби RAD складаються переважно з мов четвертого покоління (fourth-generation languages) і CASE—інструментальних засобів, які полегшують макетування і генерування кодів (програм). Мови четвертого покоління надали можливість інформаційним спеціалістам або користувачам генеру­вати комп’ютерні коди без використання загальноприйнятих мов програмування. Прикладами мов четвертого покоління є Natural, FOCUS і SQL. Як уже зазначалося, за побудови СППР методом RAD застосовуються СППР-генератори.
Розглянемо особливості застосування швидкого макетування в методології RAD. Загальне описання макетування СППР для методології SDLC буде зроблено далі окремо.
Існують різні версії швидкого макетування. Типова методологія макетування, зазвичай, включає п’ять кроків:
1. Ідентифікація вимог користувача.
2. Розроблення першого ітераційного прототипу СППР.
3. Дальший розвиток і модифікація ітераційного прототипу СППР.
4. Тестування СППР і повернення за необхідності до третього кроку.
5. Повномасштабне впровадження.
Макетування розвинулось як реакція на недоліки і обмеження SDLC-підходу. До розроблення СППР за цим методом аналітики разом з потенційними користувачами формулюють вимоги. Ці вимоги конкретизуються в загальних термінах орієнтованої на рішення діагностики і проектування. Аналітик потім розробляє прототип діючої системи.
Аналітики СППР використовують інструментальні засоби як, наприклад, системи керування базами даних і генератори задач додатків СППР, які сприяють прискоренню розроблення. Прототип не може дати відповіді на те, яким має бути доступ до реальної бази даних, або яка екранна «допомога» потрібна. Ці та інші можливості потребують тривалого часу для розроблення. Властивості, яких бракує, додаються пізніше, якщо тільки користувачі загалом задоволені тим, як функціонує прототип.
Швидке розроблення додатка RAD забезпечує послідовне нарощуване розроблення з постійним зворотним зв’язком із потенційними користувачами. Одного разу схвалений прототип може бути розширений у середовищі його розроблення або цей прототип може застосовуватися як специфікація для СППР, яка розробляється з використанням мови Java, C або C++. Коли прототип повторно програмується (репрограмується), то він стає деталізованою специфікацією і перетворюється в діючу систему. Найкращий підхід до розроблення на основі макетування — це коли фактично прототип розвивається безпосередньо в готовий виріб.
8.1.2. Фактори, які визначають
інжиніринг СППР

Як і будь-яка інформаційна система, яка призначається для розв’язання певного кола завдань, система підтримки прийнят­тя рішень створюється в результаті інжинірингу систем. Інжи­ніринг систем — це виконання систематизованого процесу — сукупності дискретних і взаємопов’язаних кроків (фаз), з допо­могою яких розв’язують певне завдання. Ці фази трансформують операційні потреби (тобто потреби ОПР у підтримці і в системах для вдосконалення, розширення і посилення власних міркувань) у конкретну конфігурацію системи (апаратні засоби, програмне забезпечення і необхідні периферійні пристрої, які можна за необхідності використовувати).
Процес інжинірингу (тобто процес проектування та розроблення) СППР значною мірою залежить від впливу таких факторів, які підлягають одночасному розгляду: середовища СППР; мети СППР; елементів СППР; способів об’єднання компонентів СППР; потрібних ресурсів.
Слід зазначити, що на відміну від процесу створення управлінських автоматизованих систем, де на перше місце ставиться ресурсний фактор, у СППР цей показник береться до уваги в останню чергу.
Елементами, які зумовлюють дію середовища СППР, є: профіль задачі; правила і процедури, які заздалегідь визначені в даній предметній галузі; рівень використання СППР (операційний, керівництво, стратегічне планування); фаза прийняття рішень, яка потребує підтримки; функціональна галузь; спосіб доступу (чи буде система дійсно інтерактивною).
Мета СППР створює основу для оцінювання системи. Зрозуміло, що СППР належить роль підтримки прийняття рішень, але за допомогою аналізу очікуваної ролі значення системи окреслюється в певні конкретні цільові конструкції. СППР можна побудувати для різних рівнів та використовувати для розв’язання широкого діапазону проблем (від вузькоспеціалізованих систем до систем із загальними аналітичними властивостями). СППР для керівника досить високого рівня (виконавча інформаційна система) в корпорації є прикладом максимально спеціалізованої системи, а готові СППР для керівника середньої ланки промисловості можуть бути прикладом узагальненого варіанта. Нарешті, важливо визначити процес, який потребує підтримки (це може бути, наприклад, процес мислення або такий, що призначений для комунікації і координації).
Компоненти СППР відображають скоріше функціональний,
а не формальний поділ системи на окремі підсистеми з погляду її проектування, тобто на перший план виступає питання стосовно того, що буде робити дана СППР, зокрема, використовуючи поняття її архітектури, передусім створюють користувацький інтерфейс, систему керування даними і систему керування моделями.
Користувацький інтерфейс на даному етапі аналізу охоплює питання формування входів і виходів системи: він сам по собі має керувати синтаксичними аспектами діалогу; контроль діалогу повинен підтримувати контекст взаємодії; перетворювач запитів мусить керувати переходом від словника користувача до внутрішнього словника моделювання в системі і надавати словник для доступу до даних.
Керування даними охоплює модуль механізму доступу (базу даних і СКБД, сховища і вітрини даних), словник даних, засоби запитів і функції переміщення блоків даних між запам’ято­вуючими пристроями різного рівня та виділення з метою організації доступу до зовнішніх джерел і для з’єднання з іншими системами.
Керування моделями і операціями моделювання сприяє логічному вибиранню даних (за допомогою процесу, який керує моделлю). Сюди належить СКБМ, яка використовується для генерування, вибирання і поновлення відповідних параметрів, пере­структурування моделей і створення «довідника» моделей; застосування моделей; процесор команд моделювання та необхідний інтерфейс бази даних.
Важлива роль в інженерії СППР відводиться зв’язкам інтерфейсу користувача, бази моделей і СКБМ, бази даних і СКБД із переліченими вище елементами середовища СППР.
Аналізуючи ресурси, які потрібно використовувати в процесі інжинірингу СППР, необхідно звернути увагу на наявність апаратних засобів оброблення інформації і на розроблення або придбання засобів програмного забезпечення, на забезпечення трудовими ресурсами і необхідними даними.
Розглядом цих факторів, упорядкованих у заданій послідовності, реалізується ідея системного підходу до створення складного проекту: аналіз факторів дає змогу відтворити етапи, починаючи з побудови загальної схеми ситуації в контексті прийняття рішень і закінчуючи абстрактним проектом системи, який потім розглядається з урахуванням наявних ресурсів. Такий ідеалізований проект СППР у довгостроковому плані має потенційну цінність, оскільки розроблення комп’ютерних систем часто являє собою поступовий ітеративний процес, який охоплює кілька поколінь і тому в ході майбутніх розроблень можна буде реалізувати ті аспекти плану, що в даний час нездійснені через обмеження ресурсів.
8.1.3. Рекомендації щодо проектування
СППР на основі підходу з урахуванням
життєвого циклу системи

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

  1. «мігруюча» система і проблема — проектування системи, а також ступінь розуміння проблеми змінюються з часом. Ці зміни викликані динамічними аспектами впровадження СППР. Одночасний вплив двох процесів — навчання ОПР і побудови СППР — суттєво ускладнюють окреслення точних меж системи;
  2. еволюція системи — в процесі проектування передбачається розширення можливостей СППР;
  3. «м’які» і «тверді» можливості СППР — узагальнені та існуючі «м’які» можливості пізніше перетворюються у «тверді» і здійснюються. Це пояснюється тільки тією обставиною, що на початку користувач у змозі вкласти більше зусиль у науку і ви­тратити більше засобів на побудову систем, ніж у наступних фазах;
  4. «слабке» і «сильне» проектування — необхідно визначити ознаки відмінності в процесі проектування між «слабким» і «сильним» підходами: у разі «слабкого» підходу враховуються тільки пріоритети ОПР за існуючих можливостей комп’ютера. Замовник не чинить тиску на користувача (тобто на особу, яка приймає рішення). «Сильний» підхід проявляється як результат тиску з боку замовника з метою підвищення результативності прийняття рішень ОПР, у той час як ця особа поводиться пасивно, боячись змін. У такому разі бракує внутрішньої мотивації у користувача щодо змін у процесі прийняття рішень.

Основним аспектом процесу проектування, який визначає стратегію створення системи, є «навчання»: СППР не розв’язує проблему до кінця, а лише посилює використання власного уміння ОПР у розв’язанні проблеми. Отже, метою побудови СППР спочатку є підтримка, а потім — розвиток підтримки стосовно прийняття рішень. Ініціююча система має бути настільки близькою до процесу прийняття рішень (тобто до процедур, викону­ваних ОПР у вигляді діалогу наказів), щоб стати легкою і привабливою для користувача.
8.1.4. Проектувальники
та управління проектом СППР

Команда проектувальників СППР
Щоб побудувати комплексну СППР з використанням або підходу SDLC, або підходу макетування, потрібно мати команду розробників. Як тільки система повністю розроблена, також може виникати потреба в групі для її підтримки (супроводження). Деякі крупномасштабні СППР створюються командами в 2—3 особи або навіть групами більше 10 осіб. Членами команди СППР є різні фахівці з організації, а також з інформаційних систем.
Будь-який проект розроблення СППР потребує комбінації додат­кової майстерності його учасників. Зазвичай вся потрібна майстерність не проявляється в одній особі. Необхідно залучати людей, навчених працювати в графічних і об’єктно-орієнтованих технологіях, які неупереджені й наділені багатою уявою. Тому в більшості ситуацій, коли це потрібно, формується раціональний склад учасників команди проектантів СППР. Як правило, виділяються такі організаційні ролі щодо створення СППР: менеджер або користувач, посередник, розроблювач СППР або аналітик, технічний підтримувач, системний програміст. Слід зауважити, що, по-перше, один учасник розроблення СППР може виконувати кілька ролей, і, по-друге, фор­мування команди розробників СППР може змінюватися під час розроблення системи. Крім того, команда повинна мати лідера — виконавчого спонсора (навіть якщо він формально займає посаду), вибраного серед вищих менеджерів компанії.
Виконавчий спонсор — це вищий менеджер, який має доступ до інших старших виконавців і має достатній вплив за розв’я­зання політичних проблем. Цей лідер має особливо активно включатися в процес розроблення. Включення такої особи в групу розробників і підтримання з нею регулярних контактів (у вигляді інформування) може допомогти їм отримати необхідний доступ до ресурсів, даних і моделей. Як уже зазначалося, важливо включати в команду також кінцевого користувача (творця рішень), щоб гарантувати, що СППР буде відповідати потребам організації у створенні рішень.
Управління проектом СППР
Перехід від неформального дослідження пропозиції або власного бажання створити СППР до формального проектування є важливим кроком. Виконавчий спонсор має сприяти призначенню менеджера, відповідального за проект у цілому. Початковими завданнями менеджера проекту є: діагностика, розроб­лення техніко-економічного обґрунтування, визначення цілей і сфери дії запропонованого проекту. Як тільки дані завдання будуть виконані, то виконавчому спонсору потрібно буде приймати рішення: або проштов­хнути проект, або відстрочити будь-яку подальшу роботу над
проектом. Залежно від сфери дії проекту СППР виконавчий спонсор може безпосередньо його фінансувати або фінансування може бути складовою частиною бізнесу і планування інформаційних систем.
Мета проекту масштабної СППР має бути стратегічно мотивованою, мати сильну виконавчу підтримку і відповідати потребам бізнесу. Як тільки проект буде схвалений, то потрібно розробити методологію і план проектування та сформувати команду проектувальників. Якщо проектування буде здійснюватися з застосуванням зовнішніх ресурсів, то має бути започаткований процес створення запитів-пропозицій, а потім оцінювання пропозицій. Якщо розроблення буде виконуватися приватно, то потрібно розв’язати питання про інструментальні й технічні засоби для нього. Аналіз здійснимості мав би визначити, чи проект може бути розроблений власними силами.
Менеджер проекту визначає плани його здійснення і управляє щоденними діями, які пов’язані з проектом, координує його ресурси та бюджет, хід підготовки звітів, вносить зміни до вимог і завдань, підтримує відносини з продавцями, спонсорами і штатними працівниками ІСМ. Менеджер проекту СППР може бути вибраний із фахівців з інформаційних систем або з функціонального департаменту. Він повинен мати добру технічну майстерність, розраховувати дії людей і бути обізнаним у бізнесі.

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]


ВНИМАНИЕ! Содержимое сайта предназначено исключительно для ознакомления, без целей коммерческого использования. Все права принадлежат их законным правообладателям. Любое использование возможно лишь с согласия законных правообладателей. Администрация сайта не несет ответственности за возможный вред и/или убытки, возникшие или полученные в связи с использованием содержимого сайта.
© 2007-2019 BPK Group.