Водоспадна модель Аналіз вимог Проектування Реалізація Інтеграція Тестування Складається специфікація продукту Складається архітектура продукту Розробка вихідного коду Інтеграція окремих частин вихідного коду Тестування та усунення дефектів

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

Типові компоненти архітектури програмного продуктута типові вимоги до ПЗ Організація програми Основні класи системи Організація даних Бізнес–правила Інтерфейс користувача Управління ресурсами Безпека Продуктивність Масштабованість Взаємодія з іншими системами (інтеграція) Інтернаціоналізація, локалізація Введення-виведення даних Обробка помилок

Типові компоненти архітектури програмного продукту та типові вимоги до ПЗ. Відмовостійкість – сукупність властивостей системи, що підвищує її надійність шляхом виявлення помилок, відновлення та локалізації поганих наслідків для системи. При розробці будь-який реальної системиДля забезпечення відмовостійкості необхідно передбачати всілякі ситуації, які можуть призвести до збою системи та розробити механізми обробки збоїв. Надійність – здатність системи протистояти різним відмовам та збоям. Відмова – це перехід системи внаслідок помилки у повністю непрацездатний стан. Збій – помилка у роботі системи, яка призводить до виходу системи з ладу. Чим менше відмов та збоїв за якийсь певний інтервал часу, тим система вважається надійнішою.

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

Чи зрозуміло описана загальна організація програми; чи включає специфікація огляд архітектури та її обгрунтування. Чи зрозуміло описана загальна організація програми; чи включає специфікація огляд архітектури та її обгрунтування. Чи адекватно визначено основні компоненти програми, їх сферу відповідальності та взаємодію з іншими компонентами. Чи адекватно визначено основні компоненти програми, їх сферу відповідальності та взаємодію з іншими компонентами. Чи всі функції, зазначені у специфікації вимог, реалізовані розумною кількістю компонентів системи. Чи всі функції, зазначені у специфікації вимог, реалізовані розумною кількістю компонентів системи. Чи наведено опис найважливіших класів та їх обґрунтування. Чи наведено опис найважливіших класів та їх обґрунтування. Чи наведено опис організації БД. Чи наведено опис організації БД. Чи визначені усі бізнес правила. Чи визначені усі бізнес правила. Чи описано їх впливом геть систему. Чи описано їх впливом геть систему. Контрольний список питань, який дозволяє зробити висновок щодо якості архітектури:

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

Рефакторинг ПЗ Код повторюється; реалізація методу надто велика; занадто велика вкладеність циклів, або сам цикл дуже великий; клас має погану зв'язність (властивості та методи класу повинні описувати лише 1 об'єкт); інтерфейс класу не формує узгоджену абстракцію; метод приймає дуже багато параметрів. Необхідно намагатися, щоб кількість параметрів була розумно мінімальною; окремі частини класу змінюються незалежно з інших частин класу; Рефакторинг передбачає адаптацію програмного забезпечення до нового апаратного забезпеченнята до нових ОС, нових засобів розробки, нових вимог, а також архітектури та функціональності ПЗ. Це зміна внутрішньої структури програмного забезпечення без зміни його зовнішньої поведінки, покликане забезпечити модифікацію програмного забезпечення. Розумні причини проведення рефакторингу:

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

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

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

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

Інформатика, кібернетика та програмування

Ітерація N Уніфікований процес розробки програмного забезпечення USDP Модель варіантів використання описує випадки, у яких програма буде використовуватися. Аналітична модель визначає базові класи додатку. Модель проектування описує зв'язки та відносини між класами та виділеними об'єктами Модель розгортання описує розподіл програмного забезпечення по комп'ютерам.

Заняття №20
Загальні принципита підходи до розробки ПЗ

Моделі розробки ПЗ

1. Водоспадна
2. Каскадна модель
3. Спіральна
4. Екстремальне програмування
5. Інкрементальна
6. Методологія MSF

Водоспадна модель

Спіральна модель

Інкрементальна розробка

Аналіз вимог

Проектування

Реалізація

Компонентне

тестування

Інтеграція

Тестування

єдиного цілого

Ітерація 1 Ітерація 2 …. Ітерація N

Уніфікований процес розробки програмного забезпечення (USDP)

1. Модель варіантів використання описує випадки, в яких додаток буде використовуватися.
2. Аналітична модель визначає базові класи додатку.
3. Модель проектування описує зв'язки та відносини між класами та виділеними об'єктами
4. Модель розгортання визначає розподіл програмного забезпечення на комп'ютерах.
5. Модель реалізації визначає внутрішню організацію програмного коду.
6. Модель тестування складається з компонентів, тестових процедур і різних варіантів тестування.

Методологія MSF

Типові компоненти архітектури програмного продукту та типові вимоги до ПЗ

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

Надійність ¦ здатність системи протистояти різним відмовим і збоям.

Відмова Це перехід системивнаслідок помилки у повністю непрацездатний стан.

Збій ¦ помилка в роботі системи, яка не призводить до виходу системи з ладу.

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

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

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

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

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

Відповідно до міжнародного стандарту ISO/IEC 12207 «Інформаційні технології – Процеси життєвого циклу ПЗ» процес розробки ПЗ містить наступні етапи життєвого циклу ПЗ:

1) аналіз системних вимогта сфери застосування;

2) проектування архітектури системи;

3) аналіз вимог до ПЗ (специфікації, зовнішні інтерфейси,);

4) проектування архітектури;

5) детальне проектування кожної одиниці;

6) кодування ПЗ (програмування)

7) тестування одиниць;

8) інтеграція (об'єднання ПЗ) та тестування сукупності одиниць ПЗ;

9) кваліфікаційні випробування ПЗ (комплексне тестування);

10) інтеграція системи одиниці структури ПЗ повинні бути об'єднані з одиницями апаратних засобів;

11) кваліфікаційні випробування системи;

12) встановлення ПЗ.

Таким чином, процес розробки ПЗ має свій початок від системи, де це ПЗ буде використано і завершується знову в системі.

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

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

Спіральна модель життєвого циклу. «Важкі та полегшені» (швидкі) технології розробки ПЗ

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

Схема спірального ЖЦ ПЗ. Однак реальний процес створення ПЗ не завжди вкладається в таку жорстку схему і часто виникає потреба повернення попередніх етапів з уточненням або переглядом прийнятих рішень.

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

Головне завдання якнайшвидше досягти працездатного ПЗ, активізуючи тим самим процес уточнення та доповнення вимог. Це так звана спіральна модель ЖЦ ПЗ.

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

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

Існує напрямок «Швидких технологій» розробки ПЗ (Agile Software Development), що дає ідеологічне обґрунтування поглядам, пов'язаним із спіральною моделлю ЖЦ. Ці технології базуються на чотирьох ідеях:

Інтерактивна взаємодія індивідуумів важливіша за формальні процедури та інструменти,

Працююче ПЗ важливіше за наявність документації на нього,

Співпраця із замовником важливіша за формальні договори,

Швидке реагування на зовнішні зміниважливіше за суворе дотримання намічених планів.

Рис. 8.2 - Схема спірального ЖЦ ПЗ

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

Правильність цих принципів певною мірою, коли розробку програмного забезпечення веде невелику кількість кваліфікованих і відданих справі «фанатів») для розробки деяких видів програмного забезпечення заперечувати важко. Однак, Agile технології і це визнають їх ідеологи застосовні в програмних проектах певного класу і масштабу, так само, як і взагалі спіральна модель ЖЦ, а там, де помилки ПЗ призводять до деяких незручностей або втрат відшкодованих коштів.

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

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

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

«Важкі та полегшені» технології розробки ПЗ . Розробники багатьох видів ПЗ вважають каскадну модель життєвого циклу надто регламентованою, надто документованою та важкою і тому нераціональною. Існує напрямок «Швидких технологій» (легких технологій) розробки ПЗ (Agile Software Development), що дає ідеологічне обґрунтування цих поглядів. Ці технології базуються на чотирьох ідеях:

1. інтерактивна взаємодія індивідуумів важливіша за формальні процедури та інструменти,

2. працююче ПЗ важливіше за наявність документації на нього,

3. співпраця із замовником важливіша за формальні договори з ним,

4. швидке реагування на зовнішні зміни важливіше за суворе дотримання намічених планів.

Правильність цих принципів крім третього певною мірою (розробку ПЗ веде невелику кількість кваліфікованих програмістів - «фанатів», які не потребують контролю та додаткової мотивації) для розробки ПЗ заперечувати важко. Однак, Agile технології і це визнають їх ідеологи застосовні в програмних проектах певного класу і масштабу, так само як і взагалі спіральна модель ЖЦ, а саме там, де помилки ПЗ призводять до деяких незручностей або втрат відшкодованих коштів і там, де вимоги до ПЗ постійно змінюються , так як були заздалегідь погано визначені, і потрібна швидка адаптація до цих змін.

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

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

Аналіз множини програмних проектів показав, що полегшені технології, що проповідують принципи самоорганізації, що акцентують використання індивідуальних здібностей розробників, короткі ітерації розробки в спіральній моделі, ХР, SCRUM поширені і часто також призводять до успіху, максимально використовуючи особливості роботи в малих колективах.

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

У великих колективах розробників проблема управління виходить на передній план.

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

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

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

Моделі розробки програмного забезпечення Водоспадна Каскадна модель Спіральна Екстремальне програмування UI Prototyping Інкрементальна W-Model Testing Уніфікований процес розробки програмного забезпечення (USDP) Методологія MSF

Водоспадна модель Аналіз вимог Складається специфікація продукту Проектування Складається архітектура продукту Реалізація Розробка вихідного коду Інтеграція окремих частин вихідного коду Тестування та усунення дефектів

Екстремальне програмування Аналіз вихідних вимог Проектування Інтеграція Реалізація Тестування Нові вимоги Аналіз/Твердження/модифікація плану розробки Випуск продукту

UI Prototyping Випуск продукту Розробка програмного забезпечення з урахуванням змін Уточнення вимог та специфікації Зміна прототипу та доопрацювання деякої функціональності Базова функціональність Прототип інтерфейсу Попередня специфікація

Інкрементальна технологія Ітерація 1 Ітерація 2 …. Аналіз вимог Проектування Реалізація Компонентне тестування Інтеграція Тестування єдиного цілого Ітерація N

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

Уніфікований процес розробки програмного забезпечення (USDP) Збір вимог Ітер 1. Ітер N Проектування Ітер 1…. Ітер N Реалізація Ітер 1. Ітер N Конструювання Ітер 1…. Ітер N Тестування Ітер 1…. Ітер N

Типові компоненти архітектури програмного продукту та типові вимоги до ПЗ Ø Ø Ø Ø Організація програми Основні класи системи Організація даних Бізнес–правила Інтерфейс користувача Управління ресурсами Безпека Продуктивність Масштабованість Взаємодія з іншими системами (інтеграція) Інтернаціоналізація, локалізація Введення-виведення даних Обробка

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

Типові компоненти архітектури програмного продукту та типові вимоги до ПЗ Крива надійності N t 1 t Чим далі, тим важче буде знайти помилку. Чим складніша система, тим більша ймовірність відмов та збоїв.

Типові компоненти архітектури програмного продукту та типові вимоги до ПЗ Ø Можливості реалізації архітектури, що розробляється. Ø Надлишкова функціональність. Ø Прийняття рішення про придбання готових компонентів ПЗ. Ø Стратегія змін.

Контрольний список питань, що дозволяє зробити висновок про якість архітектури: Ø Чи ясно описано загальну організацію програми; Ø Ø Ø включає специфікація огляд архітектури та її обґрунтування. Чи адекватно визначено основні компоненти програми, їх сферу відповідальності та взаємодію з іншими компонентами. Чи всі функції, зазначені у специфікації вимог, реалізовані розумною кількістю компонентів системи. Чи наведено опис найважливіших класів та їх обґрунтування. Чи наведено опис організації БД. Чи визначені усі бізнес правила. Чи описано їх впливом геть систему.

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

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

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

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

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

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

1. Призначення технології програмування. Історія розвитку технології програмування. Типи програмних проектів Складові технології програмування. Проект, продукт, процес та персонал

2. Життєвий цикл програми. Циклічний характер розробки. Основні поняття технології програмування. Процеси та моделі. Фази та витки. Віхи та артефакти. Зацікавлені особи та працівники.

3. Виявлення та аналіз вимог. Вимоги до програмного забезпечення. Схема розроблення вимог. Управління вимогами.

4. Архітектурне та детальне проектування. Реалізація та кодування. Тестування та верифікація. Процес контролю за якістю. Методи «білої скриньки» та «чорної скриньки». Інспектування та огляди. Цілі тестування. Верифікація, валідація та системне тестування. Супровід і розробка, що триває.

5. Моделі процесу розробки. Водоспадні та конвеєрні моделі. Спіральні та інкрементні моделі. Гнучкі моделі процесу розробки.

6. Конструювання моделі процесу. Виявлення вимог до процесу. Використовувані фази, віхи та артефакти. Вибір процесу архітектури. Порядок проведення типового проекту. Документовані процедури.

7. Моделі команди розробників. Колективний характер розробки. Оптимальний розмір команди. Підпорядкованість учасників проекту. Розвиток команди та розвиток персоналу. Спеціалізація, кооперація та взаємодія.

8. Моделі команди розробників. Ієрархічна модель команди. Метод хірургічної бригади. Модель команди дорівнює.

9. Природа програмування. Наука програмування. Мистецтво програмування. Ремесло програмування. Парадигми програмування. Структурне програмування. Логічне програмування. Об'єктно-орієнтоване програмування.

10. Програмна архітектура. Подієве управління. Архітектура клієнт/сервер. Служби. Тришарова архітектура. Проектування програм. Концептуальне проектування. Логічне проектування. Детальне проектування.

1. Новіков підходи до розробки ПЗ » http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Екстремальне програмування. - Спб.: Пітер, 2002.

3. Технологія розробки програмного обеспечения. - СПб. : Пітер, 2004.

4. Брукс-мол. проектуються та створюються програмні комплекси. М: Наука, 1975; нове видання перекладу: Міфічний людино-місяць. СПб.: СИМВОЛ +, 1999.

5. Алгоритми + структури даних = програми. М., Світ, 1978.

6. Систематичне програмування. Вступ. М: Світ, 1977.

7. Структурне програмування. М.: Світ, 1975.

8. Дисципліна програмування. М: Світ, 1978.

9. Технології розроблення програмного забезпечення. - СПб.: Пітер, 2002.

10. Терехов програмування. М: БІНОМ, 2006.

11. Рамбо Дж. Уніфікований процес розробки програмного забезпечення. СПб: Пітер, 2002.

Економічна теорія для менеджерів

Курс економічної теорії: підручник для вузів / За ред. . -Кіров: «АСА», 2004. Колемаєв -математичне моделювання. Моделювання макроекономічних процесів та систем: підручник. М.: ЮНІТІ-ДАНА, 2005. Бажин кібернетика. Харків: Консул, 2004. Леушин практикум з методів математичного моделювання: навчальний посібник. Нижегородський держ. техн. унив.- Н. Новород, 2007. Політикам про економіку: Лекції нобелівських лауреатів з економіки. М: Сучасна економіка і право, 2005. Черемних. Розвинений рівень: Підручник.-М.: ІНФРА-М, 2008. Еволюція інститутів мініекономіки. Інститут економіки УРО РАН, - М.: Наука, 2007.

Технології розробки та прийняття управлінських рішень [Н]

І. Теорія прийняття рішень: підручник. – К.: Іспит, 2006. – 573 с. І. Ухвалення рішень. Теорія та методи розробки управлінських рішень. Навчальний посібник. – М.: Березень, 2005. – 496 з Г. Розробка управлінського рішення – М.: Видавництво «Дело», 2004 р. – 392 с. Г. Експертні оцінки та прийняття рішень. - М.: Патент, 1996. - 271 с. Таха // Введення у дослідження операцій = Operations Research: An Introduction. - 7-ме вид. – М.: «Вільямс», 2007. – С. 549-594. Г. Тейл. Економічні прогнози та прийняття рішень. М.: "Прогрес" 1970. К. Д. Льюїс. Методи прогнозування економічних показників. М.: «Фінанси та статистика» 1986. Г. С. Кільдішев, А. А. Френкель. Аналіз часових рядів та прогнозування. М.: «Статистика» 1973. О. Кім, Ч. У. М'юллер, У. Р. Клекка та ін. Факторний, дискримінантний та кластерний аналіз. М.: «Фінанси та статистика» 1989. Ефективний менеджер. Книга 3. Ухвалення рішень. - МІМ ЛІНК, 1999 Туревський та управління автотранспортним підприємством. - М: Вища школа, 2005. , ; за ред. . Системний аналіз в управлінні: навчальний посібник. - М.: Фінанси та статистика, 2006. , Тиньков: навчальний посібник. - М.: КНОРУС, 2006.

Моделювання бізнес-процесів в інтегрованих системах управління

"Моделювання бізнес-процесів з AllFusion Process Modeler (BPwin 4.1) Діалог-МІФІ" 2003 "Створення інформаційних систем з AllFusion Modeling Suite" вид. "Діалог-МІФІ" 2003 "Практика функціонального моделювання з AllFusion Process Modeler 4.1. (BPwin) Де? Навіщо? Як?" вид. "Діалог-МІФІ" 2004 Дубейковське моделювання з AllFusion Process Modeler (BPwin). вид. "Діалог-МІФІ" 2007 Д. Марка, К. МакГоуен "Методологія структурного аналізу та проектування SADT" 1993 класичний працю з методології SADT. Черемний аналіз систем: IDEF-технології, Моделювання та аналіз систем. IDEF технології. Практикум. M.: Фінанси та статистика, 2001. , "Структурні моделі бізнесу: DFD-технології" http://www. /Level4.asp? ItemId=5810 "Теорія та практика реорганізації бізнес-процесів"2003/P50.1.. Методологія функціонального моделювання. М: Держстандарт Росії, 2000. http://www. IDEF0, IDEF3, DFD http://www. Моделювання бізнес-процесів засобами BPwin http://www. /department/se/devis/7/ IDEF0 у моделюванні бізнес-процесів управління http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

Оцінка ефективності програмних продуктів

1. Архітектура ІТ

2. Домени процесів управління.

3. Перелік процесів домену Планування та Організація

4. Перелік процесів домену Придбання та впровадження

5. Перелік процесів домену Експлуатація та Супровід

6. Перелік процесів домену Моніторинг та Оцінка

7. Характеристика рівнів моделі зрілості процесів

9. KPI та KGI їх взаємозв'язок та призначення

1. 10. Загальні заходи контролю у ІТ та заходи контролю додатків. Зони відповідальності та обов'язки бізнесу та ІТ.

Cobit 4.1 Російське видання.

Правове регулювання створення та використання інтелектуальної власності

1. Перерахуйте інтелектуальні права на результати інтелектуальної діяльності та розкрийте їх зміст.

2. Перерахуйте види договорів щодо розпорядження винятковим правом. Охарактеризуйте кожен із зазначених договорів щодо розпорядження винятковим правом.

4. Охарактеризуйте основні положення правової охорони Програми для ЕОМ як об'єкта авторського права.

5. Порівняйте основні положення правової охорони Бази даних як об'єкта авторського права та як об'єкта суміжних прав.

6. Охарактеризуйте умови патентоспроможності об'єктів патентних прав: винаходів; корисних моделей; промислових зразків.

7. Розкрийте зміст критеріїв патентоспроможності винаходу: новизна; винахідницький рівень; промислова застосовність.

8. Охарактеризуйте умови та порядок отримання патенту на винахід, корисну модель або промисловий зразок, а також умови, що забезпечують дію патентів та терміни їх дії.

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

10. Перерахуйте засоби індивідуалізації, що охороняються, і дайте їх порівняльну характеристику.

1. , Право інтелектуальної власності в Російської Федерації, Підручник // М, Проспект, 2007 р.

2. , Право інтелектуальної власності, навчальний посібник // М, РІОР, 2009

Управління проектами та розробкою ПЗ [ І]

Кент Бек - Екстремальне програмування Фредерік Брукс - Міфічний людино-місяць або як створюються програмні системи. Том де Марко – Deadline. Роман про керування проектами. Том де Марко, Тімоті Лістер - Вальсуючи з ведмедями. Том де Марко, Тімоті Лістер - Людський фактор _ успішні проекти та команди. Алістер Коуберн – Кожному проекту своя методологія. Алістер Коуберн - Люди як нелінійні та найважливіші компоненти у створенні програмного забезпечення. Андрей Орлов – Записки автоматизатора. Професійна сповідь. Філіп Крачтен - Вступ до Rational Unified Process. Хенрік Кніберг - Scrum і XP: нотатки з передовою. Презентації лекцій з курсу