сувалося, що ювелірний виріб може складатися з декількох матеріалів. Крім того, постійним клієнтам майстерня надає
Введення
Для успішної реалізації проекту об'єкт проектування (ІС) повинен бути перш за все адекватно описаний, повинні бути побудовані повні і несуперечливі функціональні та інформаційні моделі ІС. Накопичений до теперішнього часу досвід проектування ІС показує, що це логічно складна, трудомістка і тривала за часом робота, що вимагає високої кваліфікації що в ній фахівців. Проте до недавнього часу проектування ІС виконувалося в основному на інтуїтивному рівні із застосуванням неформалізованих методів, заснованих на мистецтві, практичному досвіді, експертних оцінках і дорогих експериментальних перевірках якості функціонування ІС. Крім того, у процесі створення та функціонування ІС інформаційні потреби користувачів можуть змінюватися чи уточнюватися, що ще більш ускладнює розробку і супровід таких систем. p align="justify"> У 70-х і 80-х роках при розробці ІС досить широко застосовувалася структурна методологія, що надає в розпорядження розробників строгі формалізовані методи опису ІС та прийнятих технічних рішень. Вона заснована на наочній графічній техніці: для опису різного роду моделей ІС використовуються схеми та діаграми. Наочність і строгість коштів структурного аналізу дозволяла розробникам і майбутнім користувачам системи з самого початку неформально брати участь в її створенні, обговорювати і закріплювати розуміння основних технічних рішень. Однак, широке застосування цієї методології і проходження її рекомендаціям при розробці конкретних ІС зустрічалося досить рідко, оскільки при неавтоматизованої (ручний) розробці це практично неможливо. Дійсно, вручну дуже важко розробити і графічно представити суворі формальні специфікації системи, перевірити їх на повноту і несуперечність, і тим більше змінити. Якщо все ж таки вдається створити сувору систему проектних документів, то її переробка при появі серйозних змін практично нездійсненна. Ручна розробка зазвичай породжувала такі проблеми:
В· неадекватна специфікація вимог;
В· нездатність виявляти помилки в проектних рішеннях;
В· низька якість документації, що знижує експлуатаційні якості;
В· затяжний цикл і незадовільні результати тестування.
З іншого боку, розробники ІС історично завжди стояли останніми в ряду тих, хто використовував комп'ютерні технології для підвищення якості, надійності та продуктивності у своїй власній роботі (феномен "шевця без чобіт").
Перераховані фактори сприяли появі програмно-технологічних засобів спеціального класу - CASE-засобів, що реалізують CASE-технологію створення і супроводу ІС. Термін CASE (Computer Aided Software Engineering) використовується в даний час в досить широкому сенсі. Первісне значення терміна CASE, обмеж...
