3.2. Методи проектування. Життєвий цикл та вимоги до іс

На сьогодні існування декількох методів побудови автоматизованих інформаційних систем (АІС), серед яких можна виділити наступні:

Метод " знизу-нагору".

Основною метою було не створення тиражируемых продуктів, а обслуговування співробітників конкретної установи. Цей підхід багато в чому зберігався й при автоматизації й сьогодні. В умовах постійно мінливих законодавства, правил ведення виробничої, фінансово-господарчої діяльності й бухгалтерського обліку керівникові зручно мати поруч посередника між спущеною зверху новою інструкцією й комп'ютером.

Створюючи свої відділи й керування автоматизації, підприємства й банки намагалися облаштуватися самотужки. Однак періодичне "перетрушення" інструкцій, складності, пов'язані з різними виставами користувачів про тих самих дані, безперервна робота програмістів по задоволенню всі нових і нових побажань окремих працівників і як наслідок - невдоволення керівників своїми програмістами.

У цьому випадку, при наявності кваліфікованого штату програмістів, цілком стерпно були автоматизовані окремі, важливі з погляду керівництва робочі місця. Загальна ж картина "автоматизованого підприємства" проглядалася недостатньо добре, особливо в перспективі.

Метод " зверху-униз".

Із усього спектра проблем розроблювачі виділили найбільш помітні: автоматизацію ведення бухгалтерського аналітичного обліку й технологічних процесів. Для банків це в основному - розрахунково-касове обслуговування, для промислових підприємств - автоматизація процесів проектування й виробництва.

Системи були спроектовані "зверху", тобто в припущенні, що одна програма повинна задовольняти потреби всіх користувачів.

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

"Дуалізму" і багатокомпонентність.

Новий підхід до проектування АІС полягає в збалансованій комбінації двох попередні. У першу чергу це ставилося до ідеології побудови ядра системи: "Автоматизована бухгалтерія - аналітичний облік".

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

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

Життєвий цикл інформаційної системи — період часу, який починається з моменту ухвалення рішення про необхідність створення ІС і закінчується в момент її повного вилучення з експлуатації.

Поняття життєвого циклу є одним з базових понять методології проектування ІС.

Методологія проектування ІС описує процес створення й супроводу систем у вигляді життєвого циклу (ЖЦ) ІС, представляючи його як деяку послідовність стадій і виконуваних на них процесів. Для кожного етапу визначаються склад і послідовність виконуваних робіт, одержувані результати, методи й засобу, необхідні для виконання робіт, ролі й відповідальність учасників і т.д. Такий формальний опис ЖЦ ІС дозволяє спланувати й організувати процес колективної розробки й забезпечити керування цим процесом.

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

Початкова стадія

На початковій стадії встановлюється область застосування системи й визначаються граничні умови. Для цього необхідно ідентифікувати всі зовнішні об'єкти, з якими повинна взаємодіяти розроблювальна система, і визначити характер цієї взаємодії на високому рівні. На початковій стадії ідентифікуються всі функціональні можливості системи й проводиться опис найбільш істотних з них.

Стадія уточнення

На стадії уточнення проводиться аналіз прикладної області, розробляється архітектурна основа інформаційної системи.

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

Наприкінці стадії уточнення проводиться аналіз архітектурних розв'язків і способів усунення головних факторів ризику в проекті.

Стадія конструювання

На стадії конструювання розробляється закінчений виріб, готове до передачі користувачеві.

По закінченню цієї стадії визначається працездатність розробленого програмного забезпечення. Стадія передачі в експлуатацію

На стадії передачі в експлуатацію розроблене програмне забезпечення передається користувачам. При експлуатації розробленої системи в реальних умовах часто виникають різного роду проблеми, які вимагають додаткових робіт із внесення коректив у розроблений продукт. Це, як правило, пов'язане з виявленням помилок і недоробок.

Наприкінці стадії передачі в експлуатацію необхідно визначити, досягнуті мети розробки чи ні.

У цей час відомі й використовуються наступні моделі життєвого циклу:

Каскадна модель (рис. 3.1)передбачає послідовне виконання всіх етапів проекту в строго фіксованому порядку. Перехід на наступний етап означає повне завершення робіт на попередньому етапі.

Поетапна модель із проміжним контролем (рис. 3.2). Розробка ИС ведеться ітераціями із циклами зворотного зв'язку між етапами.

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

Спіральна модель (рис. 3.3).На кожному витку спирали виконується створення чергової версії продукту, уточнюються вимоги проекту, визначається його якість, і плануються роботи наступного витка. Особлива увага приділяється початковим етапам розробки - аналізу й проектуванню, де

Реалізовуваність тих або інших технічних розв'язків перевіряється й обґрунтовується за допомогою створення прототипів (макетування).

Рис. 3.1. Каскадна модель ЖЦ ІС

Рис. 3.2. Поетапна модель із проміжним контролем

Рис. 3.3. Спіральна модель ЖЦ ІС

Можна виділити наступні позитивні сторони застосування каскадного підходу:

- на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти й погодженості;

- виконувані в логічній послідовності етапи робіт дозволяють планувати строки завершення всіх робіт і відповідні витрати.

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

Спіральна модель ЖЦ була запропонована для подолання перерахованих проблем. На етапах аналізу й проектування реализуемость технічних розв'язків і ступінь задоволення потреб замовника перевіряється шляхом створення прототипів. Кожний виток спирали відповідає створенню працездатного фрагмента або версії системи. Це дозволяє уточнити вимоги, мети й характеристики проекту, визначити якість розробки, спланувати роботи наступного витка спирали. У такий спосіб глибшаються й послідовно конкретизуються деталі проекту й у результаті вибирається обґрунтований варіант, який задовольняє дійсним вимогам замовника й доводить до реалізації.

Основна проблема спірального циклу - визначення моменту переходу на наступний етап. Для її розв'язку вводяться тимчасові обмеження на кожний з етапів життєвого циклу, і перехід здійснюється відповідно до плану, навіть якщо не вся запланована робота закінчена. Планування проводиться на основі статистичних даних, отриманих у попередніх проектах, і особистого досвіду розроблювачів.

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

Вимоги до ІС

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

1. Локалізація інформаційної системи. У зв'язку з тим, що найбільш великими розроблювачами інформаційних систем є закордонні компанії, система повинна бути пристосована до користування українськими компаніями. Причому тут мається на увазі локалізація як функціональна (облік особливостей російського законодавства й систем розрахунків), так і лінгвістична (система допомоги й документація російською мовою).

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

3. У випадку впровадження системи на велике підприємство зі складною організаційною структурою, необхідна реалізація дистанційного доступу для того, щоб інформацією могли користуватися всі структурні підрозділи організації. Система повинна забезпечувати можливість роботи в єдиній централізованій базі даних

4. У силу впливу зовнішніх і внутрішніх факторів (змін напрямку бізнесу, зміни в законодавстві й т.п.), система повинна бути адаптивної. Застосовне до Росії, ця якість системи повинна розглядатися більш серйозно, тому що в нас у країні зміни законодавства й правил обліку відбуваються в кілька раз частіше, чим у країнах зі стабільною економікою.

5. Необхідна можливість консолідації інформації на рівні підприємств (об'єднання інформації філій, дочірніх компаній і т.д.), на рівні окремих завдань, на рівні тимчасових періодів.

Ці вимоги є основними, але далеко не єдиними критеріями вибору корпоративної інформаційної системи для підприємства.

Вимоги до систем керування персоналом

Структура й інтерфейс користувача

Нижче перераховані найбільш важливі ( з погляду користувача) вимоги для вивчення, освоєння й подальшого застосування Hr-Систем:

• в основу функціонування ПО повинна бути покладена чітко певна модель предметної області, яка тільки переведена в програмний код;

• програма повинна мати дружній користувацький інтерфейс — екранний вид усіх документів повинен бути наближений до стандартного, а основні дії — відповідати стандартному набору функціональних клавіш, прийнятому в популярних офісних додатках;

• логіка роботи Hr-Системи повинна бути інтуїтивно зрозуміла, тобто послідовність дій користувача повинна максимально відповідати його діям, які він звик виконувати в повсякденній діяльності;

• кілька способів виконання тих самих дій — команди головного й контекстного меню, швидкі клавіші, кнопки панелей інструментів;

• розвинена система спливаючих підказок і визначень на елементах різних форм;

• неправильні дії користувача повинні фіксуватися програмою й пропонуватися послуги майстра (wizard);

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

• програма повинна мати гнучке настроювання параметрів, як числових, так і функціональних, а для базових версій гаслом повинне бути: "усі настроювання — без програміста";

• підтримувати посилання на нормативно-правову базу й мати можливість поповнювати її — згодом — самими користувачами;

• довідкова система повинна бути досить повної й містити загальноприйняту термінологію, а користувач повинен одержувати підтримку через Web-Сайт розроблювача;

• можливість роботи розподілених офісів підприємств через Internet;

• використання електронних Класифікаторів і Довідників.

Для забезпечення безпеки й адміністрування необхідно забезпечувати:

• авторизацію й контроль прав доступу;

• захист інформації від випадкової втрати й несанкціонованого доступу;

• схоронність документів і ведення їх архівів;

• оповіщення про виняткові ситуації й помилках.

Вимоги до обробки інформації:

- повнота й достатність інформації для реалізації функцій керування;

- своєчасність надання інформації;

- забезпечення необхідного ступеня вірогідності інформації залежно від рівня керування;

- економічність обробки інформації: витрати на обробку даних не повинні перевищувати одержуваний ефект;

- адаптивність до мінливих інформаційних потреб користувачів.