ння від графіка або просто вади в реалізації, які неможливо або колись виправити. У цьому сенсі корпоративна культура компанії Microsoft передбачає будь-яких комплексів: тут без коливань «ріжуть по живому», віддаючи пріоритет своєчасності викиду продукту на ринок. Статистичні дані по основних продуктах Microsoft показують, що в середньому близько 25% містяться у вихідній специфікації (розрекламованих, а тому очікуваних споживачем) функціональних особливостей зникають до часу випуску продукту; якщо ж вважати і те, що привнесено, то кінцева функціональність буде відрізнятися від вихідної на 30% і більше.
На основі функціональної специфікації менеджери з розробки, постійно консультуючись з проектувальниками, починають на модульній основі створювати горизонтальну архітектуру продукту. Головне, що на цій стадії всі основні функції ПО розбиваються на кілька груп (зазвичай три-чотири групи). Відповідно, формується стільки ж підпроектів, робота над якими буде вестися послідовно. Розбиття проводиться на основі вже наявної класифікації функцій за ступенем важливості. Найбільш важливі (1/3 від загальної кількості, якщо груп усього 3) потрапляють в перший підпроект; інші, менш пріоритетні, реалізуються в рамках другого підпроекту, і нарешті, інші, найменш значущі функції виконуються в останньому підпроекту. Кожен підпроект закінчується випуском проміжної «контрольної» версії продукту (milestone release).
програма мова алгоритм специфікація
Визначена таким чином архітектура проекту відображається на організаційну структуру: для реалізації окремих Функцій в рамках одного підпроекту призначаються невеликі команди (small feature teams), які і працюють паралельно і максимально автономно. Для них визначається графік роботи і виділяються необхідні ресурси, за рамки яких виходити не рекомендується. Причому велике значення на розглянутому етапі надається свідомому прийняттю цих рамок самими розробниками, які мають можливість детально проаналізувати призначену їм задачу. У результаті графік, планований з точністю до дня, часто виявляється занадто оптимістичним.
Слід звернути увагу на дуже спрощений підхід до розробки архітектури програмного продукту: по суті, саме поняття архітектури зводиться до допоміжного інструментарію, підлеглого інтересам організаційного планування і управління. Між тим, з точки зору сучасних уявлень добре структурована архітектура продукту є необхідна умова його успішної розробки і - що особливо важливо!- Подальшого розвитку. Саме тому найвизначніші авторитети в області Software Engineering, наприклад Граді Буч, розглядають архітектуру, визначальну логічну і фізичну структури програмної системи, як основу належних стратегічних і тактичних проектних рішень з метою побудови якісного продукту.
Відомо, що багато продуктів компанії Microsoft, створені на хисткій основі завідомо неповної і постійно змінюваної специфікації, багато в чому ущербні. Саме в цьому розгадка дивних на перший погляд відмінностей послідовних версій одного і того ж продукту, не кажучи вже про продукти різних, але в той же час спадкоємних ідеологічно. Яскравий тому приклад - реалізація механізмів DLE - OLE - ActiveX. Консервативна «несуча конструкція», якою є архітектура ПО, гнеться і ламається під вантажем малокерованими мутацій і деформацій. В результаті - маса проблем при реалізації такого бажаного принципу розробки, як повторне викори...
