Повторне використання компонентів ІС

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

За оцінками експертів, 75 % таких робіт дублюють одна одну: на тисячах підприємств створюються програми складського обліку, нарахування зарплати, розрахунку витрат на виробництво продукції, складання маршрутів деталей на виробничому конвеєрі тощо. Хоч більшість із цих програм типові, але кожного разу знаходяться особливості, що не дозволяють застосувати розроблену раніше програму. Тому нині активно розвивається напрямок водночас і науковий, і інженерний, який названо повторним використанням або компонентним розробленням програм.

Компонентне розроблення - це метод побудови ПЗ як композицій готових компонент з конструкцій за каталогом.

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

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

Менеджмент розроблення ІС

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

Аналіз проектів, що зазнали краху, дав можливість виділити найбільш поширені причини провалів. До них можна віднести такі:

• o керівники проектів не розуміють вимог замовника;
• o масштаби проекту визначено неправильно;
• o зміни проекту провадяться з великими труднощами;
• o розробники змінюють обрану технологію проектування;
• o замовник змінює вимоги;
• o обраний термін виконання проекту нереальний;
• o користувач не ухвалює деяких рішень;
• o інвестиції втрачено;
• o для реалізації проекту не вистачає виконавців;
• o менеджери проекту не застосовують прогресивних методів керівництва.

Методологія створення ІС

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

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

Відомі такі стандарти життєвого циклу ІС:

• o ГОСТ 34.601-90;
• o ISO/IEC 12207:1995;
• o Custom Development Method (методика Oracle);
• o Rational Unif ied Process (RUP);
• o Microsoft Solutions Framework (MSF) включає 4 фази: аналіз, проектування, розробка, стабілізація; припускає використання об'єктно орієнтованого моделювання;
• o екстремальне програмування (Extrкme Programming, ХР). В основі методології - командна робота, ефективна комунікація між замовником і виконавцем протягом усього проекту з розробки ІС. Розробка ведеться з використанням послідовних прототипів.

Стандарт ГОСТ 34.601-90 передбачає такі стадії й етапи створення автоматизованої системи (АС):

• 1. Формування вимог до АС:
  • o обстеження об'єкта й обґрунтування необхідності створення АС;
  • o формування вимог користувача до АС;
  • o оформлення звіту про виконання робіт і заявки на розробку АС.
• 2. Розробка концепції АС:
  • o вивчення об'єкта;
  • o проведення необхідних науково-дослідних робіт;
  • o розробка варіантів концепції АС і вибір варіанта концепції АС, що задовольняє вимоги користувачів;
  • o оформлення звіту про виконану роботу.
• 3. Технічне завдання; розробка і затвердження технічного завдання на створення АС:
• 4. Ескізний проект:розробка попередніх проектних рішень щодо системи і її частин; розробка документації на АС і її частини.
• 5. Технічний проекті
• o розробка проектних рішень щодо системи і її частин;
• o розробка документації на АС і її частини;
• o розробка й оформлення документації на постачайня комплектуючих виробів;
• o розробка завдань на проектування в суміжних частинах проекту.
• 6. Робоча документація:
  • o розробка робочої документації на АС і її частини;
  • o розробка й адаптація програм.
• 7. Введення в дію: підготовка об'єкта автоматизації і персоналу.
• 8. Супровід АС:
  • o виконання робіт відповідно до гарантійних зобов'язань;
  • o післягарантійне обслуговування.

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

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

Стандарт ISO/IEC 12207:1995 (Information Technology Software Life Cycle Processes) є основним нормативним документом, що регламентує склад процесів життєвого циклу ІС.

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

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