Підходи до створення ІУС

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

Усі найбільш поширені методології структурного підходу базуються на ряді загальних принципів [8]. У якості двох базових принципів використовуються наступні:

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

• принцип ієрархічного упорядкування - принцип організації складових частин проблеми в ієрархічні деревоподібні структури з додаванням нових дета Виділення двох базових принципів не означає, що інші принципи є другорядними, оскільки ігнорування будь-якого з них може привести до непередбачуваних наслідків (у тому числі і до провалу всього проекту). Основними з цих принципів є наступні:

• принцип абстрагування - полягає у виділенні істотних аспектів системи і відволікання від несуттєвих;

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

• принцип несуперечності - полягає в обгрунтованості та узгодженості елементів;

• принцип структурування даних - полягає в тому, що дані повинні бути структуровані і ієрархічно організовані.лей на кожному рівні.

У структурному аналізі використовуються в основному дві групи засобів, що ілюструють функції, виконувані системою і відносини між даними. Кожній групі засобів відповідають певні види моделей (діаграм), найбільш поширеними серед яких є наступні [2,7,10]:

• SADT (Structured Analysis and Design Technique) моделі і відповідні функціональні діаграми;

• DFD (Data Flow Diagrams) діаграми потоків даних;

• ERD (Entity-Relationship Diagrams) діаграми "сутність-зв'язок".

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

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

В Україні діє державний стандарт на стадії створення автоматизованих систем ГОСТ 34.601-90. Існує і міжнародний стандарт на стадії життєвого циклу програмної продукції (ISO 12207:1995). Як власне АС, так і компоненти АС є складними системами і при їх проектуванні можна використовувати один із стилів проектування:

– нізхідний (Top-of-Design); чітка реалізація спадного проектування призводить до спіральної моделі розробки ПЗ, на кожному витку спіралі блоки попереднього рівня деталізуються, використовуються зворотні зв'язки (альтернативою є так звана каскадна модель, що відноситься до почергової реалізації частин системи);

– висхідний (Bottom-of-Design);

– еволюційний (Middle-of-Design).

Найчастіше використовується низхідний стиль блочно-ієрархічного проектування. Розглянемо етапи низхідного проектування АС. Верхній рівень проектування АС часто називають рівнємконцептуального проектування. Концептуальне проектування виконують в процесі передпроектних досліджень, формулювання ТЗ, розробки ескізного проекту та прототипування (згідно з ГОСТ 34.601-90, ці стадії називають формуванням вимог до АС, розробкою концепції АС і ескізним проектом).

Передпроектні дослідження проводять шляхом аналізу (обстеження) діяльності підприємства (компанії, установи, офісу), на якому створюється або модернізується АС. При цьому потрібно отримати відповіді на питання: що не влаштовує в існуючій технології? Що можна поліпшити? Кому це потрібно і, отже, яким буде ефект? Перед обстеженням формуються і в процесі його проведення уточнюються цілі обстеження - визначення можливостей і ресурсів для підвищення ефективності функціонування підприємства на основі автоматизації процесів управління, проектування, документообігу і т.п. Зміст обстеження - виявлення структури підприємства, виконуваних функцій, інформаційних потоків, наявних досвіду і засобів автоматизації. Обстеження проводять системні аналітики (системні інтегратори) спільно з представниками організації-замовника. На основі аналізу результатів обстеження будують модель, яка відображатиме діяльність підприємства на даний момент (до реорганізації). Таку модель називають "As Is". Далі розробляють вихідну концепцію АС. Ця концепція включає в себе пропозиції щодо зміни структури підприємства, взаємодії підрозділів, інформаційним потокам, що виражається в моделі "To Be" (як має бути). Результати аналізу конкретизуються в ТЗ на створення АС. У ТЗ вказують потоки вхідної інформації, типи вихідних документів і послуг, що надаються, рівень захисту інформації, вимоги до продуктивності (пропускної спроможності) і т.п. ТЗ направляють замовнику для обговорення і остаточного узгодження.

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

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

При концептуальному проектуванні застосовують ряд специфікацій, серед яких центральне місце займають моделі перетворення, зберігання і передачі інформації. Моделі, отримані в процесі обстеження підприємства, є моделями його функціонування. У процесі розробки АС моделі, як правило, зазнають істотних змін (перехід від "As Is" до "To Be") і в остаточному вигляді модель "To Be" розглядають в якості моделі проектованої АС. Розрізняють функціональні, інформаційні, поведінкові та структурні моделі.

Функціональна модель системи описує сукупність виконуваних системою функцій.

Інформаційні моделі відображають структури даних - їх склад і взаємозв'язки.

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

Структурні моделі характеризують морфологію системи (її побудову): склад підсистем, їх взаємозв'язку. Змістом наступних етапів низхідного проектування (згідно з ГОСТ 34.601-90, це стадії розробки технічного проекту, робочої документації, введення в дію) є уточнення переліків придбаного устаткування і готових програмних продуктів, побудова системного середовища, детальне інфологічне проектування БД і їх первісного наповнення, розробка власного оригінального програмного забезпечення, яка, у свою чергу, ділиться на ряд етапів низхідного проектування. Ці роботи складають зміст робочого проектування. Після цього випливають закупівля та інсталяція програмно-апаратних засобів, впровадження та дослідна експлуатація системи.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Вхід вплив вихід	\|	Загальні відомості про CASE

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.01 сек.