Організація розробки АСУ, Комерція, Різне, статті

Розробка АСУ – тривалий процес, в якому беруть участь колективи різного призначення, різної відповідальності, підпорядкованості і навіть мають свої цілі, відмінні від цілей розробників. Наприклад, керівництво організації-замовника зацікавлене у дешевій розробці з отриманням якнайшвидшого ефекту від автоматизації, а у розробників – власні наукові та виробничі плани. Іноді працівники організації-замовника вважають, що автоматизація не дуже-то й потрібна (мовляв, жили без неї – проживемо і далі), інші розглядають необхідність взаємодії з розробки чиками як перешкоду, що заважає їм виконувати свої прямі обов’язки, треті турбуються, що в нових умовах вони виявляться не при справах і т. п. В будь-якому випадку для співробітників апарату управління участь в створенні АСУ – додаткова турбота, тому ще раз доречно відзначити, що розробка АСУ, впровадження засобів автоматизації не повинні позначатися на виконанні організацією своїх функцій.

На чолі розробок АСУ повинен стояти керівник організації-замовника, або один з його заступників, причому у великих системах доцільно його звільнити на цей час від всіх інших обов’язків (хоча на практиці таке вдається здійснити вкрай рідко). Необхідність участі керівництва організації в розробках АСУ пов’язана з двома основними моментами. По-перше, впровадження ЕОМ часто вимагає внесення суттєвих змін в систему, її методи роботи, структуру, документи і т. д., і тільки керівництво організації може санкціонувати подібні зміни і затверджувати прийняті проектні рішення (Бувають випадки, коли доводиться звертатися і до вищих інстанцій). По-друге, знову-таки тільки керівництво організації може забезпечити необхідне участь її співробітників в розробці АСУ і взаємодія з розробниками.

Керівник, який займається питаннями впровадження обчислювальної техніки, повинен бути в курсі ходу розробок і затверджувати всі основні принципові рішення. Часто таке твердження носить формальний характер: затверджуються, «не дивлячись», всі пропозиції розробників. Це одна з поширених помилок при розробці АСУ, нерідко призводить до негативних по наслідків. Зазвичай до групи керівництва розробкою, яка розглядає всі принципові питання входять 5-7 провідних працівників організацій замовника і розробника.

Як уже говорилося, одна з першочергових задач керівника розробки АСУ – забезпечити проведення на високому рівні обстеження існуючої системи і розробки технічного завдання, а потім і ескізного проекту. Для цього затверджуються відповідні плани робіт, складаються списки співробітників організації-замовника, інформація від яких буде корисна при їх розробці. Остаточну розробку технічного завдання та ескізного проекту не слід доручати занадто великого колективу. Практика показує, що група з 4-5 чоловік цілком справляється з цією роботою. Проте це повинні бути найбільш компетентні фахівці з організацій замовника і розробника.

Як ми вже знаємо, розробка АСУ ведеться по підсистемам – структурним і функціональним. На чолі цих розробок також повинні бути достатньо компетентні працівники. Доцільно, щоб керівники розробок основних підсистем входили в керівну групу з розробки всієї АСУ. В процесі розробки окремих підсистем доводиться вирішувати ряд питань, що мають загальне значення для всієї системи, таких, як інформаційне взаємодія окремих підсистем, загальна система класифікаторів і нормативів, загальні сервісні програми і т. д. Керівники повинні забезпечити єдність підходу при вирішенні цих та подібних питань і врахування інтересів окремих підсистем.

Розробка підсистем ведеться за окремими задачами, вибір яких і затвердження черговості їх вирішення також входять в обов’язки керівників розробки автоматизованої системи. Розробка окремих задач ведеться групами системників і програмістів, керівництво повинно забезпечити їх ув’язку між собою. В процесі створення АСУ розробляється ряд проектів з окремим завданням, підсистем, всій системі. Ці проекти повинні містити конкретний матеріал, який потрібно (і можна) впроваджувати. Практика ж показує, що це, здавалося б, елементарне вимога не завжди виконується, в той же час очевидно, що загальні міркування впровадити не вдається (звідси також випливає вимога максимальної стандартизації та однаковості при написанні всіх проектів). Конкретності проектів або їх частин (що дозволяє їх безпосереднє використання) можна добитися, якщо заздалегідь чітко обумовити, які матеріали, в якому обсязі і якої призначення вважаються остаточними результатами і пред’являються до здачі.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*