Головна

Інтегральний показник компактності

  1.  А. Ціна - показник якості.
  2.  Автопротоліз води. Іонний добуток води. Водневий показник.
  3.  Аналітичне вирівнювання по показовою кривою
  4.  Б) показове вбивство представників влади
  5.  В якості залежної змінної може виступати практично будь-який показник, що характеризує, наприклад, діяльність підприємства або курс цінного паперу.
  6.  ВОДНЕВИЙ ПОКАЗНИК. ГІДРОЛІЗ СОЛЕЙ
  7.  Час реакції як показник функціонального стану людини


Таблиця побудови альтернативних сценаріїв

 зміст операції  позначення  грошові витрати  Тимчасові витрати
 здача частини нерухомості в суборенду  P1
 впровадження нових технологій  P2
 кваліфікація існуючого персоналу  P3
 наймання нових працівників  P4
 скорочення штату працівників  P5
 покупка нового більш дешевого обладнання  P6
 продовження роботи з колишнім обладнанням  P7
 організація збуту продукції  P8
 продовження виробництва колишньої продукції  P9
 розробка нової конкурентноздатної продукції  P10

 сценарій  інтегральна оцінка
 гроші  час
 P1  P2  P3  P5  P6  P8  P9  P11  
 P1  P2  P4  P5  P6  P8  P9  P11  
 P1  P2  P3  P5  P7  P8  P9  P11  
 P1  P2  P4  P5  P7  P8  P9  P11  
 P1  P2  P3  P5  P6  P8  P10  P11  
 P1  P2  P4  P5  P6  P8  P10  P11
 P1  P2  P3  P5  P7  P8  P10  P11  
 P1  P2  P4  P5  P7  P8  P10  P11  


висновок

Тенденції розвитку сучасних інформаційних технологій приводять до постійного зростання складності інформаційних систем, створюваних у різних галузях економіки. Для успішної реалізації проекту об'єкт проектування повинен бути, перш за все, адекватно описаний, повинні бути побудовані повні і функціональні несуперечливі і інформаційні моделі інформаційної системи. Накопичений до теперішнього часу досвід проектування ІС показує, що це логічно складна, трудомістка і тривала за часом робота, що вимагає високої кваліфікації що в ній фахівців. Однак до недавнього часу проектування ІС виконувалося в основному на інтуїтивному рівні із застосуванням неформалізованих методів, заснованих на мистецтві, практичному досвіді, експертних оцінках і дорогих експериментальних перевірках якості функціонування ІС. Крім того, в процесі створення і функціонування ІС інформаційні потреби користувачів можуть змінюватися чи уточнюватися, що ще більше ускладнює розробку і супровід таких систем. У 70-х і 80-х роках при розробці ІС досить широко застосовувалася структурна методологія, що надає в розпорядження розробників строгі формалізовані методи опису ІС та прийнятих технічних рішень. Вона заснована на наочній графічній техніці: для опису різного роду моделей ІС використовуються схеми і діаграми. Наочність і строгість засобів структурного аналізу дозволяла розробникам і майбутнім користувачам системи з самого початку неформально брати участь в її створенні, обговорювати і закріплювати розуміння основних технічних рішень. Однак широке застосування цієї методології та дотримання її рекомендаціям при розробці конкретних ІС зустрічалося досить рідко, оскільки при неавтоматизированной (ручний) розробці це практично неможливо. Дійсно, вручну дуже важко розробити і графічно представити строгі формальні специфікації системи, перевірити їх на повноту і несуперечність, і тим більше змінити. Якщо все ж вдається створити сувору систему проектних документів, то її переробка при появі серйозних змін практично нездійсненна. Ручна розробка зазвичай породжувала такі проблеми:

1. неадекватна специфікація вимог;

2. нездатність виявляти помилки в проектних рішеннях;

3. низька якість документації, що знижує експлуатаційні якості;

4. затяжний цикл і незадовільні результати тестування.

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

Перераховані фактори сприяли появі програмно-технологічних засобів спеціального класу - CASE-засобів, що реалізують CASE-технологію створення і супроводу ІС. Термін CASE (Computer Aided Software Engineering) використовується в даний час в досить широкому сенсі. Первісне значення терміна CASE, обмежене питаннями автоматизації розробки лише програмного забезпечення (ПО), в даний час набуло нового змісту, що охоплює процес розробки складних ІС в цілому. Тепер під терміном CASE-засобу розуміються програмні засоби, що підтримують процеси створення і супроводу ІС, включаючи аналіз і формулювання вимог, проектування прикладного ПЗ (додатків) і баз даних, генерацію коду, тестування, документування, забезпечення якості, конфігураційне управління і управління проектом, а також інші процеси. CASE-засоби разом із системним ПЗ і технічними засобами утворюють повну середу розробки ІС.

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

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

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




 Курсова робота |  Вступ |  Початкова структура підприємства |  розрахунок коефіцієнтів |  реструктуризація підприємства |

© 2016-2022  um.co.ua - учбові матеріали та реферати