Незважаючи на наявність діалектів і відмінностей в синтаксисі, в більшості своїй тексти SQL-запитів, що містять, DDL і DML, можуть бути досить легко перенесені з однієї СУБД в іншу. Існують системи, розробники яких спочатку закладалися на застосування щонайменше кількох СУБД (наприклад: система електронного документообігу Documentum може працювати як з Oracle, так і з Microsoft SQL Server і IBM DB2). Природно, що при застосуванні деяких специфічних для реалізації можливостей такої переносимості добитися вже дуже важко. Наявність стандартів і набору тестів для виявлення сумісності і відповідності конкретній реалізації SQL загальноприйнятому стандарту тільки сприяє «стабілізації» мови. Правда, варто звернути увагу, що сам по собі стандарт місцями занадто формалізований і роздутий в розмірах, наприклад, Core-частину стандарту SQL:2003 включає понад 1300 сторінок тексту.Незважаючи на наявність міжнародного стандарту ANSI SQL-92, багато компаній, СУБД (наприклад, Oracle, Sybase, Microsoft, MySQL), що займаються розробкою, вносять зміни до мови SQL, вживаної в розроблених ними СУБД, тим самим відступаючи від стандарту. Таким чином з'являються специфічні для кожної конкретної СУБД діалекти мови SQL.
2. Розробка програми (компоненту)
2.1 Загальний опис програми (компоненту)
Програмний продукт повинен забезпечувати основні функції інтернет- магазину. Продукт дозволяє зробити покупку, використовуючи стандартні форми:
•назва товару
•вартість
Також повинна існувати можливість накопичення вибраних товарів в корзині і можливість реєстрації постійних клієнтів. Крім того слід забезпечити можливість існування бек-офісу, для виконання адміністративних функцій. У адміністратора існує можливість у будь-який момент отримувати статистику сайту, що включає в себе загальну кількість користувачів, замовлень, число зареєстрованих користувачів. Також адміністратор має можливість блокування доступу до сайту користувачів з заданою IP-адресою або діапазоном адрес. Також існує можливість блокування зареєстрованих користувачів. Крім того, адміністратор має можливість виводу печаті вмісту корзину замовлень.
Крім того на сайті існує система рейтингу товарів, що задається кількістю додавань до корзини цього товару. Також користувач може у будь-якиий відмінити вміст корзини.
Також на сайті в наявності повинна бути гнучка система скидок товару. Скидка додається до сайту за допомогою бек – офісу. Вона може задаватися для окремих товарів. Також скидка повинна бути прогресивною тобто її розмір прямо порційний вартості товару.
2.2 Технічне завдання. Додаткова специфікація
1. Введення
1.1. Найменування продукту: «Інтернет-магазин»»
1.2. Призначення продукту та сфера застосування.
Програма призначена для вибору товарів по різноманітним критеріям, що занесені в базу даних та мають наступні дані:
1.2.1. Найменування
1.2.2. Вартість
1.2.3. Наявність
Також необхідне формування бази даних клієнтів з наступними даними:
1.2.4. ПІБ клієнта.
1.2.5. Адреса.
Програма надає користувачу веб - інтерфейс для формування замовлення.
2. Вимоги до програми
2.1. Вимоги до функціональних характеристик
Програма повинна забезпечувати виконання наступних функцій:
2.1.1. Виконувати пошук по наявним товарам.
2.1.2. Виконувати реєстрацію клієнтів.
2.1.3. Додавати нових клієнтів до бази даних.
2.1.4. Оформлення замовлення.
2.1.5. Забезпечувати можливість прогресивних знижок.
2.1.5. Різноманітні функції адміністрування.
2.2. Вимоги до надійності
2.2.1. Вимоги для надійного забезпечення функціонування програми.
Надійне функціонування програми повинне бути забезпечене виконанням Замовником сукупності організаційно - технічних норм, перелік яких наведено нижче:
а) організація неперервного живлення технічних засобів;
б) використання ліцензійного програмного забезпечення;
в) регулярне виконання вимог ГОСТ 51188-98. Захист інформації.
2.2.2. Інтервал відновлення після відмови
Інтервал відновлення після відмови, що викликано збоєм живлення технічних засобів (іншими зовнішніми факторами), не фатальним збоем (не крахом) операційної системи, не повинно бути більш ніж 30-ти хвилин при дотримання експлуатації технічних та програмних засобів. Інтервал відновлення після відмови, викликаного несправністю технічних засобів, фатальним збоем ( крахом) операційної системи, не повинно бути більш ніж час, необхідний для ремонту несправностей технічних засобів і пере інсталяції програмних засобів.
2.2.3. Відмови із-за некоректних дій користувача
Відмови із-за некоректних дій користувача при взаємодії з програмою через інтерфейс користувача недопустимі.
3. Вимоги експлуатації
3.1. Кліматичні вимоги до експлуатації
Кліматичні вимоги до експлуатації, при яких забезпечується робота програми повинні відповідати кліматичним умовам експлуатації наявних технічних засобів.
3.2. Вимоги до кваліфікації та численності персоналу.
Мінімальна кількість персоналу, необхідного для роботи програми, може складати одну штатну одиницю—кінцевого користувача програми — адміністратора.
3.3. Вимоги до технічних засобів
Для виконання ролі технічного засобу необхідна наявність комп’ютера , що здатний виконувати роль веб – сервера.
3.4. Вимоги до інформаційної та програмної сумісності
3.4.1 Вимоги до коду та мови програмування
Додаткові вимоги не вимагаються
3.4.2. Вимоги до програмних засобів
Системні програмні засоби,що використовуються програмою, повинні бути надані ліцензійною версією операційної системи Windows Server або будь- якою з вільних Unix-систем.
3.4.3. Вимоги до захисту інформації та програм
Вимоги до захисту інформації та програм не вимагаються
4. Вимоги до програмної документації
4.1. Попередній склад програмної документації
Склад програмної документації повинен включати в себе:
4.1.1. технічне завдання;
4.1.2. програма та методика тестування;
4.1.3. інструкція оператора;
5. Техніко – економічні вимоги
5.1. Економічні переваги розробки
Орієнтовний економічний розрахунок не проводиться. Аналогії внаслідок унікальності вимог до розробки не проводяться.
6. Стадії та етапи розробки
6.1. Стадії розробки
Розробка повинна включати в себе 3 стадії:
1. розробка технічного завдання;
2. робоче проектування;
3. впровадження.
6.2. Етапи розробки
На стадії розробки технічного завдання повинен бути виконаний етап розробки, погодження і затвердження технічного завдання.
На стадії робочого проектування повинні бути виконі наступні етапи робот
1. розробка програми;
2. розробка програмної документації;
3. тестування програми.
На стадії впровадження повинна бути виконана розробка, підготовка і передача програми.
6.3. Зміст робот по етапам
На стадії розробки технічного завдання повинен бути виконані наступні роботи:
1. постановка задачі;
2. з’ясування вимог до технічних засобів;
3. з’ясування вимог до програми;
4. з’ясування етапів, строків та стадій розробки програми та документації до неї.
5. погодження та затвердження технічного завдання.
На етапі розробки програми повинна бути виконана робота з кодування та наладки програми. На етапі розробки документації повинна бути виконана розробка програмних документів в погоджені з вимогами до складу документації.
На етапі тестування програми повинні бути виконані наступні види робіт:
1. розробка, погодження та утвердження методики тестування;
2. проведення приймально- сдавальних тестувань ;
3. коректування програми і програмної документації по результатам тестування.
На етапі підготовки до здачі програми повинна бути виконана робота по підготовці і передачі програми і програмної ддокументації в експлуатацію на об’єктах Замовника.
7. Порядок контроля та приймання
7.1. Види тестування
Приймально – сдавальне тестування повинне проводитися на об’єкті Замовника в обумовлені строки.
Приймально – сдавальне тестування програми повинне проводитися згідно інструкції, розробленої Виконавцем і узгоджене з Замовником програми і методикою тестування.
7.2. Загальні вимоги прийомки роботи
На основі Протоколу проведення тестування Виконувач разом з Замовником підписує Акт прийому-здачі програми в експлуатацію.
2.3.Діаграма «сутність-зв'язок»
Діаграма «сутність-зв'язок» відношень у системі представлена в додатку В.
2.4 Діаграма потоків даних (DFD)
Діаграма потоків даних у системі наведена в додатку С.
2.5 Реалізація
Весь процес кодування виконувався в середовищі програмування Netbeans 6.7.1 на мові програмування PHP.Концептуально важливі частини коду наведені у додатку А.
2.6 Програма та методика тестування
Враховуючи специфіку розробки веб – програм більш доречною для тестування продукту є функціональна модель тестування (або тестування «чорного ящика»).
У зв’язку з цим необхідно розбити програмний продукт на функціональні частини та розробити набор тестів для кожної із них.
Розроблений програмний продукт можна розбити на наступні частини:
•адміністративна частина
•частина користувача
Для адміністративної частини можна запропонувати наступні тести
1.Перевірка коректності вводу товарів на сайт.
2.Перевірка роботи адміністративних функцій.
3.Перевірка коректної взаємодії користувача та адміністратора.
4.Перевірка відсутності SQL-іньекцій.
5.Перевірка коректної роботи системи знижок
Для частини користувача можна запропонувати наступні тести
1.Перевірка коректного доступу на сайт.
2.Перевірка коректності замовлення і накопичення товарів в корзині.
3.Тест реєстрації на сайті.
Заданий набор тестів дозволяє протестувати всі компоненти програми та перевірити коректність обробки вхідних та вихідних даних за короткий термін, що є вкрай важливою обставиною при веб-розробці.