1. Технічне завдання

Розробити систему управління контентом, яка буде забезпечувати функціонування веб-сайту ПП «Віконера».

1. Розробити дизайн клієнтської частини сайту.

   1. Спроектувати загальну концепцію дизайну для головної та внутрішніх сторінок сайту.

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

   3. Виокремити елементи дизайну у зовнішні графічні файли.

   4. За допомогою мови розмітки XHTML і таблиць стилів CSS створити шаблони головної та внутрішньої сторінок.

2. Реалізувати ядро системи управління контентом.

   1. Написати програмні модулі для:

      1. зберігання інформації у вигляді розділів та сторінок;

      2. відображення новин;

      3. представлення графічних зображень у вигляді фотогалереї;

      4. проведення опитувань на сайті;

      5. реалізації можливості пошуку інформації;

      6. реалізації контактної форми;

      7. забезпечення обмеженого доступу до системи управління контентом; передбачити можливість існування адміністраторів двох типів: головні адміністратори сайту та адміністратори розділу;

   2. Створити скрипти для додавання, оновлення та видалення даних для кожного модуля сайту.

   3. За допомогою графічного редактора Adobe Photoshop створити елементи дизайну системи адміністрування; виокремити їх у зовнішні графічні файли; за допомогою мови розмітки XHTML і таблиць стилів CSS створити шаблон сторінки системи адміністрування;

3. Наповнити сайт інформацією.

2. Аналіз аналогічних розробок

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

№п/п	Назва системи	Недоліки
1	PHP Nuke	Немає можливості пошуку по сайту, немає модуля «Контактна форма», немає можливості групування сторінок сайту за тематичними розділами, занадто спрощене розподілення доступу між адміністраторами.
2	Drupal	Немає модуля «Контактна форма», не передбачена можливість групування сторінок сайту за тематичними розділами
3	TinyPortal	Немає можливості пошуку по сайту, немає модуля «Контактна форма», не передбачене групування сторінок сайту за тематичними розділами, немає можливості розподілення доступу між адміністраторами, відсутня статистика відвідування.
4	XYZSite	Дана система є комерційною, немає модуля «Контактна форма», не передбачене групування сторінок сайту за тематичними розділами.
5	S.Builder	Дана система є комерційною, немає модуля «Контактна форма», не передбачене групування сторінок сайту за тематичними розділами, відсутня статистика відвідування.

3. Вибір архітектури

Для реалізації даного проекту було використано клієнт-серверну архітектуру:

Рис.6.1. Клієнт-серверна архітектура

Web-сервер – це сервер, який надає доступ до сайтів World Wide Web. Коли користувач дає браузеру команду відкрити той чи інший документ на сайті, браузер підключається до відповідного серверу і робить запит до нього на вміст документу.

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

Наприклад, в порівнянні з файл-серверною архітектурою. Для файлової архітектури потрібний файловий сервер, а для клієнт-серверної потрібні сервер баз даних. Інакше кажучи, сервер для достатньо великої системи необхідний у будь-якому випадку, хоча б тому, що на ньому бажано мати апаратний RAID та пристрій для резервного копіювання. А раз сервер все одно потрібний, то чому його не використовувати в якості сервера баз даних!? Набагато простіший та надійніший сервер баз даних. І швидше, тому-що, при файл-серверній архітектурі, кожний клієнт переглядає блоки файлів на мережевому диску і шукає те, що йому потрібно. При клієнт-серверній архітектурі клієнти посилають SQL-запит, при цьому зворотно по мережі посилають відповіді на ці запити, тобто лише ті дані, які потрібні. Тобто шукає в базі лише СКБД, клієнти нічого не шукають. По мережі передаються лише запити і відповіді на них, а не шматки величезних файлів.