2.4. Процес створення систем
Етапи процесу створення системи показані на мал. 2.4. Ці етапи дуже впливають на процес розробки програмного забезпечення відповідно до каскадної моделі, що описується в главі 3.
Рис. 2.4. Процес
створення системи
Опишемо основні відмінності між процесом створення систем і процесом розробки програмного забезпечення.
Залучення в процес розробки систем різноманітних інженерних дисциплін. Процес створення систем звичайно вимагає залучення різноманітних інженерних дисциплін. Це може привести до значних утруднень у розробці систем, оскільки кожна дисципліна використає свою термінологію.
Невеликий масштаб повторних робіт при розробці систем. Після прийняття рішень у процесі розробки систем (наприклад, про установку певних типів радіолокаторів у системі керування польотами) внесення змін у систему може виявитися досить дорогим. Перепроектування системи часто просто неможливо. Це одна із причин широкого використання ПО при створенні найрізноманітніших систем - програмні компоненти роблять системи більше гнучкими й дозволяють внести зміни в розроблювальну систему у відповідь на нові вимоги, пропоновані до неї.
У команду розроблювачів систем неминуче включаються фахівці різних профілів. Команда розроблювачів повинна мати широке коло знань, щоб всебічно розглянути всі системні можливості при прийнятті яких-небудь рішень. Розглянемо систему керування польотом (СУП), у якій використається радіолокаційна або яка-небудь інша сенсорна система для визначення місцезнаходження літаків (див. мал. 2.3). На мал. 2.5 схематично показані ті інженерні дисципліни, якими повинні володіти члени команди розроблювачів системи.
Рис.
2.5. Інженерні дисципліни,
що утягуються в процес системотехніки
Для багатьох систем існує практично нескінченна кількість способів декомпозиції (розбивки) системи на підсистеми. При цьому фахівці різних профілів можуть пропонувати різні варіанти структурної моделі системи, які будуть містити різні функціональні компоненти. Тим самим можливий найширший діапазон альтернативних моделей. Вибір певної моделі не обов'язково ґрунтується тільки на технічних аргументах. Нехай, наприклад, однієї з альтернатив у розробці СУП є установка нової радіолокаційної системи замість модернізації існуючої. Якщо в команду розроблювачів входять будівельники, то вони можуть наполягти саме на цьому варіанті створення СУП, тому що він забезпечить роботою і їх, і будівельні підрозділи, які вони представляють. При цьому для обґрунтування потрібного варіанта можуть, звичайно, залучатися й технічні аргументи.
Оскільки ПО по своїй природі є гнучким і порівняно набудовува_ легко, часте рішення багатьох несподіване виниклих проблем перекладається на плечі фахівців із програмного забезпечення. Нехай, наприклад, при створенні СУП невдало обраний місце розташування однієї радарної установки - на екрані локатора іноді відбувається роздвоєння зображень. Для видалення цього ефекту необхідно пересунути радарну установку, що практично не здійсненно. Рішенням цієї проблеми може бути створення спеціального ПО, що допоможе видалити роздвоєння зображень. Але в цьому випадку може знадобитися могутніша обчислювальна техніка, чим та, котра споконвічно запланована, і це, у свою чергу, також може стати певною проблемою.
Перед фахівцями із програмного забезпечення часто ставляться завдання, які необхідно вирішувати без збільшення вартості апаратних засобів. Тому багато хто так звані програмні помилки не є наслідком яких-небудь "уроджених" рис або властивостей ПО. Вони можуть бути результатом спроби модернізувати програмне забезпечення відповідно до змін вимог, пропонованих до створюваної системи. Гарним прикладом такої помилки може служити збій у системі керування багажем в аеропорті Денвера [329].