Основи програмної ніженерії. Умови виникнення інженерії програмного забезпечення
 Скачать 215.87 Kb.
|
|
46.Домени, методи, моделі розробки програмного забезпечення. Домени ПЗ Конкретний домен: речі, об’єкти (відчутні дії)(ІПЗ) Абстрактний домен: інформація, концепції (не відчутні дії)(КН) Моделі розробки ПЗ: Каскадна модель. Основні базові види діяльності, що виконуються в процесі створення ПЗ (такі як розробка специфікацій, проектування, атестаця та моделювання ПЗ), представляються як окремі етапи цього процесу. Еволюціонна модель. Тут послідовно виконуються етапи формування вимог, розробка ПЗ та його атестація. Початкова програмна система швидко розробляється на основі деяких абстрактних загальних вимог. Потім вони уточнюються і деталізуються відповідно о вимог замовника. Далі система доробляється і тестується відповідно до нових уточнених вимог. Модель формальної розробки системи. Основана на розробці формальної математичної моделі специфікації програмної системи і перетворенні цієї специфікації методом спеціальних математичних методів в виконувані програми. Перевірка відповідності специфікації і системних компонентів також виконується математчними методами. Модель розробки ПЗ на основі створених компонентів. Припускає, що окремі складові частини програмної системи вже існують, тобто створені раніше. В цьому випадку технологічний процес створення ПЗ основну увагу приділяє інтеграції окреих компонентів в загальне ціле, а не їх створенню. Методи розробки ПЗ: Метод низсхідного. (метод покрокової деталізації) Суть методу заключається у визначенні специфікацій компонентів системи шляхом повлідовного виділення в її складі окремих складових і їх послідовної деталізації до рівня, забехпечующого ожнозначне розуміння того, що і як потрібно розробляти та реалізувати. Модульна розробка. Реалізації методу низсхідного проектування тісно зв’язана з іншим розумінням програмування - модульно розробкою, так як на практиці при декомпозиції складної програми виникає питання про розумну межу її роздріблення на складові частини. Разом з цим поняття модульності не можна зводити тільки до представлення складних програмних комплексів в виді набору окремих функціональних блоків. Структурна розробка. це дисципліна, що об’єднує дукілька взаємозв’язаних спообів створення ясних, лугких для розуміння програм. Єфективність використвння сучасних універсальних мов програмування в багато чому заключається удобством написання з їх длплмогою структурних програм. 47. це структурні рішення, призначені для розробки програмного забезпечення і включають системні моделі, формалізовані нотації і правила проектування, а також способи управління процесом розробки. Відповіді на питання на іспит Теоритична частина ОПІ 48.Персонал. Загальні положення. Персонал- це люди які реалізують більшість програмних процесів але так як одна людина не може реалізувати це одна тому люди як правило утворюють деяку структуру, характер якої ,також як і властивості окремих особистостей грають дуже важливу роль в розробці програмних продуктів. Таким чином, є дві складових персоналу які можуть розглядатися -Люди (Кваліфіковані фахівці) -Організації 49.Моделі підбору персоналу. Є три моделі підбору персоналу Індикатор типів (модель) Майерса-Брігса(MBTI). Модель функціональних міжособисних відносин оріїнтації поведінки(FIRO-B) Модель міжпроцесного взаємодії Кернела(PCN) MBTI-це інтроспективний опитувальник самозвіту,показує різні психологічні переваги в тому, як люди спиймають світ і приймають рішення. Тест намагаєтся виділити Інтроверсія або ексороверсія Відчуття або інтуіція Мислення або почуття Судження або сприйняття FIRO-B – опитання призначений для оцінки поведінки людини в трьох основних областях міжособистих потреб: Включення Контролю Афекту PCM- застосовуєтся для ідентифікації типу особи на основі шести типів осіб з використанням транзакційного аналізу 50.Структура організацій. Структура організації — це її внутрішня побудова, яка характеризує склад підрозділів і систему зв'язку, підпорядкованість і взаємодію між ними. Також є три типи структур організації Функціональна Проектна Матрична Функціональна- припускає поділ співробітників за функціональними обов’язками Проектна-припускає розподіл струкури по функціональним підрозділам, орієнтованим на виконання проекту Матрична-структура передбачає подіо співробітників з функціональних підрозділів по виконуваних проектам з підпорядкуванням їх менеджерові матричного проекту 51.Програмні продукти, уніфікований процес. 52.Типи інженерії програмного забезпечення. Взаємозв’язок інженерій. 53.Зворотня інженерія. Методи зворотної інженерії 54.Повторне використання. Загальні положення. Повторне використання - це використання для нових розробок будь-яких порцій формалізованих знань, здобутих під час реалізації завершених розробок програмних систем. Також ви можем розрізняти два методи використання ПВ а) їх можуть використовувати не лише їхні розробники; б) їх можна адаптувати для створення нових систем. Є також два процеси створення ПВ Перший процес - створення ПВ.Він включає такі кроки: а) вивчення спектра завдань, що вирішуються, виявлення серед них загальних підходів до вирішення; б) побудову для них компонент, які реалізують знайдені підходи або окремі їхні елементи, котрі ми назвали повторно використовуваними компонентами; в) побудову каталогу, націленого на пошук необхідних компонент. Для успішної реалізації цього процесу необхідно мати певний досвід у вирішенні не одного, а кількох подібних завдань, що дозволяє виявити як їхні спільні риси, так і розбіжності, щоб знайти загальне вирішення для їхньої реалізації, а також способи настроювання на характерні для кожного завдання особливості. Другий процес - конструювання цільових систем з готових компонент.Він передбачає такі кроки: а) зрозуміти, що має робити нова цільова система, для чого вона створюється і які вимоги до неї ставляться; б) знайти у каталозі серед готових компонент ті, які вважаються підходящими, і зрозуміти, що вони роблять; в) зіставити мету нової розробки з можливостями знайдених ПВК і прийняти рішення про доцільність використання їх; г) застосувати відібрані ПВК й інтегрувати їх до нової розробки, забезпечивши необхідні поєднання. 55.Шляхи створення повторно використовуваних компонентів. По отношению к этим процессам разработка и применение ПИК могут идти двумя путями: синхронно; асинхронно Синхронный путь Используется, когда запрос на требуемый ПИК удовлетворяется одновременно с разработкой или сопровождением ПО. Это осуществляется или путем поиска соответствующего ПК в процессе анализа существующего ПО (в том числе и разрабатываемого), настройки его и передачи в разработку ПО в качестве ПИК. Очевидно, что репозитарий, создаваемый таким путем, будет зависеть от запросов на ПИК, характера разрабатываемого ПО, времени, требуемого на удовлетворение запроса, и т.д. Асинхронный путь Создает условия для производства ПИК по плану. Обычно ПИК выделяются из существующего ПО или создаются путем обобщения существующих ПК. 56.Створення компонентів, які повторно використовуються. Повторного використання програмного забезпечення (повторного використання програмного забезпечення) повинен мати знання про програмне забезпечення, що використовується для створення цілого ряду нових програмного забезпечення зменшити вартість розробки і супроводу програмного забезпечення. Повторного використання програмного забезпечення полягає в підвищенні продуктивності і якості програмного забезпечення важливої технології. Ранні повторного використання програмного забезпечення на рівні коду, повторне основному були спеціально називається програма повторного використання знань, а пізніше розширений за рахунок включення домену знаннями, досвідом в області розробки, проектні рішення, архітектура, вимоги, дизайн, код і документацію і всі інші зацікавлені сторони.
Фон Програмне забезпечення повторного використання комп'ютерного програмного забезпечення інженерних методів і теорій. 60 років "криза програмного забезпечення", так що програмістам зрозуміти важко підтримувати витрати на програмне забезпечення надзвичайно високі, коли програмне забезпечення розширення, загальна вартість цього програмного забезпечення можна сказати, що ніхто не може собі дозволити, і навіть якщо ми ставимо високі Засоби важко отримати надійні продукти та ідеї повторного використання програмного забезпечення є основним способом вирішити цю проблему. Мислення Основна ідея повторного використання програмного забезпечення є те, що програмне забезпечення складається з різних функціонує як частина "пакет", що складається з організму, запис в конструкції кожен компонент може бути призначений для виконання тієї ж роботи, спільні кошти, так що якщо виконання різних роботи компонентів створюються, роботу написання конкретного програмного забезпечення виявляється підключеної до різних компонентів тканини організму на прості питання, які для кінцевого якості програмних продуктів і робіт з технічного обслуговування необхідні зміни. Характеристики та стан Програмне забезпечення повторного використання існуючих програмних компонентів, які будуть використовуватися для побудови нової системи програмного забезпечення. Програмне забезпечення може бути мультиплексированную інгредієнти зазвичай називають повторно використовуваних компонентів, незалежно від повторно використовуваних компонентів використані недоторканими або внести відповідні зміни перед використанням, поки воно використовується для створення нового програмного забезпечення, можна було б назвати мультиплексу . Повторного використання програмного забезпечення не тільки повторно використовувати програми, він також включає в себе процес виробництва програмного забезпечення, готова продукція, створювана будь-якої діяльності повторного використання, такі як планування проектів, ТЕО, визначення вимог, аналіз моделі, дизайн моделі, докладний опис, вихідний код, тести і так далі. Якщо в системі використовується кілька разів в ідентичній повторного використання програмних компонентів не відома, і відома як загальний, змінювати програмне забезпечення, воно працювати на новій апаратної й програмної платформи не називається мультиплексування і називаються значення програмного забезпечення зміни. Рівень Наступним найбільш ймовірно, щоб виробити значні переваги для повторного використання програмного забезпечення в життєвому циклі деяких основних етапів розвитку програмних продуктів повторного використання, відповідно до рівня абстракції можуть бути розділені на наступні рівні мультиплексування: Код У тому числі об'єктного коду та повторне використання вихідного коду. Які націлені на найнижчий рівень повторного використання коду, найдовша історія, більшість мов програмування в даний час систем операційної підтримки забезпечення з'єднання (Link), кріплення (зв'язування) та інші функції для підтримки такого повторного використання. Джерело повторного використання коду рівня трохи вище цільової повторне використання коду, програмісти поставити деякі думки в повторне використання програмного коду копіюються в вашу власну програму, але вона має тенденцію виробляти деякі старі помилки невідповідності коду. Хочете, щоб досягти великомасштабних повторне використання вихідного коду розраховувати лише на багаторазово використовуваний компонент містить велику бібліотеку компонентів. Таких, як "зв'язування та впровадження об'єктів» (OLE) технологій, як на рівні підтримки джерела і визначити компоненти використовуються для побудови нової системи, а також дозволяє цим компонентам у рівні об'єкта код все ще деякі незалежні повторно використовуваних компонентів, які можуть працювати При занадто гнучким для різних нових комбінацій різних додатків. Дизайн Дизайн результати більш високому рівні абстракції, ніж вихідний, так що це мультиплексування менше постраждали від впровадження інформаційних технологій, так що повторно використовувані компоненти більше можливостей повторного використання та модифікації потрібно менше. Це мультиплексування трьома способами, перший спосіб полягає в розробці результатів від існуючої системи, щоб витягти деякі компоненти багаторазового використання дизайну, і ці компоненти на нові системи; Другий спосіб полягає в існуючому Система всіх проектних документів у новій програмно-апаратній платформі повторної реалізації, яка призначена для застосування до ряду конкретних реалізації; третій шлях не залежить від конкретного додатка, є плани з розвитку деяких багаторазові дизайну компонентами. Аналіз Це є результатом більш високого рівня, ніж повторне використання дизайну, багаторазові компоненти аналізу предметної області для певних речей або деякі питання більш високого рівня абстракції рішення, з розробки та реалізації умов надали мало впливу, так що багаторазові більше шансів. Повторне, є три способи аналізу результатів з існуючої системи для вилучення повторно використовуваних компонентів для нової системи аналізу, аналізу з повним документ в якості вхідних даних для генерації різних апаратних і програмних платформ та інших умов для досягнення кількох проектної документації; залежить від конкретних додатків, спеціально розроблених аналіз ряду компонентів багаторазового використання. Тестова інформація Охоплює процедури випробувань і тестів повторного використання інформації повторного використання. Перше тесту в програмне забезпечення, що використовується в тестуванні нового програмного забезпечення, або внести зміни в програмне забезпечення, коли новий раунд випробувань у використанні. Останній знаходиться в процесі тестування допомогою використання програмного забезпечення для автоматичного запису процесу тестування, у тому числі тестерів кожної операції, вхідні параметри, тестів і середу та іншу інформацію. Цей рівень мультиплексування, незручності і аналіз, проектування, програмування, точні рівень мультиплексированную порівняння, тому що це не те ж саме мультиплексированную різних рівнях абстракції, але іншого роду інформацію, але форма інформації см. , як правило, в програмний код цілком рівні. Оскільки процес виробництва програмного забезпечення в основному позитивний процес, що більшість з процесу виробництва програмного забезпечення, щоб зробити програмний продукт від високий рівень абстракції, щоб сформувати форму низькому рівні абстракції, так що більш високий рівень мультиплексування легко керувати більш низького рівня комплексу використання, повторного використання і, отже, чим вище рівень, тим більше нагород, доступних, тому результати аналізу і проектування результати високо цінуються. Користувачі можуть придбати аналізу виробника деталей і частин дизайну, власного дизайну або програмування, майстер системи пошиття одягу, розширення, технічного обслуговування, розвиток та інші види діяльності. Принципові труднощі Повторного використання програмного забезпечення з різними труднощами, як технічних, так і нетехнічних питання або проблеми, що впливають на широке поширення практика повторного використання програмного забезпечення. Технічні фактори Компонент відмінності між систем і додатків. Деякі розробники створювати компоненти, для досягнення деяких інших людей у розвитку системи при використанні тільки право, від змісту до зовнішніх інтерфейсів точно в лінію, або протягом декількох змін, це не просте питання, члени до певної суми з метою підтримки ефективної повторного використання, в той час як велика кількість компонентів, необхідних для отримання високих інвестицій і довгострокового накопичення, поєднання компонентів, знайдених труднощі, коли члени досягти більшого числа, користувачі хочуть знайти його самостійно потрібних компонентів, і дійшли висновку, що це дійсно їх власним потребам, не є легким завданням, повторне використання на основі методологій розробки програмного забезпечення та програмного забезпечення процесу нової галузі досліджень і практики, потрібна нова теорія, методи і сприятливому середовищі В даний час ця область досліджень і практичного досвіду, є недостатніми. Людський фактор Розробка програмного забезпечення є творчою роботою, вже давно займається в цій галузі людей сформувалася звичка: любить створювати свої власні не люблю використовувати чужий матеріал, особливо якщо ви хочете розробляти програмне забезпечення для інших, щоб внести деякі зміни в повторне використання, вони часто люблю себе, щоб написати ще одну. Управління факторами У програмне забезпечення для управління виробництвом, уроки з минулого, а також повторне використання деяких дуже скоординованої системи цілей і політики, такі як обчислювальна навантаження для повторного використання частини грати великі знижки, або навіть не працюють, інший , а не на початку проекту свідомо створення повторно використовуваних компонентів у напрямку зусиль, але він буде завершений, щоб переконатися, в змозі знайти ряд компонентів багаторазового використання. Ці недоліки заважають повторне використання та повторне підвищення рівня розширення масштабу, і навіть вчинені повторно послабити ентузіазм персоналу. Освітні чинники У освіта програмного забезпечення і навчання в галузі науки і техніки, відсутність інформації на програмне забезпечення повторного використання змісту, мало досвіду в цій області і навчальних матеріалів, навіть в інших програмах, згаданих у підручниках і повторного використання програмного забезпечення, і його обсяг і зміст досить слабка. Правові фактори Є ще деякі правові питання, наприклад, багаторазово використовуваний компонент в системної помилки сталися при додатку компоненти і додатки розробники розробники не є виробником, то хто повинен нести відповідальність? Крім того, авторське право, та інших аспектів державної політики, є деякі невирішені питання. 57 Метод проектирования ПО, основанный на повторном использовании, предполагает максимальное использование уже имеющихся программных объектов. Такие объекты могут радикально различаться размерами. Повторно используемые приложения. Можно повторно использовать целые приложения либо путем включения их в систему без изменения других подсистем, либо с помощью разработки семейств приложений, работающих на разных платформах и адаптированных к требованиям конкретных заказчиков. Повторно используемые, компоненты. Можно повторно использовать компоненты приложений - от подсистем до отдельных объектов. Например, система распознавания текста, разработанная как часть системы обработки текстов, может повторно использоваться в системах управления базами данных. Повторно используемые функции. Можно повторно использовать программные компоненты, которые реализуют отдельные функции, например, математические. Основанный на стандартных библиотеках метод повторного использования применяется в программировании последние 40 лет. 58 повторное использование компонентов должно быть систематическим, плановым и включенным во все организационные программы организации-разработчика. В Японии повторное использование известно много лет и является неотъемлемой частью "японского" метода разработки ПО. Многие компании, например, Hewlett-Packard, успешно применяют повторное использование в своих разработках. Опыт этой компании представлен в фундаментальной книге. Альтернативой повторному использованию программных компонентов является применение программных генераторов. Согласно этому подходу информация, необходимая для повторного использования, записывается в систему генератора программ с учетом знаний о той предметной области, где будет эксплуатироваться разрабатываемая система. В данном случае в системной спецификации должно быть точно указано, какие именно компоненты выбраны для повторного использования, а также описаны их интерфейсы и то, как они должны компоноваться. На основе такой информации генерируется система ПО 59 Використання SSOT дозволить створити більш міцну та зрозумілу кодову базу. Дублювання коду – марна трата часу та ресурсів. Вам доведеться підтримувати ту саму логіку і тестувати код відразу в двох місцях, причому якщо ви зміните код в одному місці, його потрібно буде змінити і в іншому. Найчастіше дублювання коду відбувається через незнання системи. Перш ніж щось писати, виявіть прагматизм: огляньтеся. Можливо, ця функція десь реалізована. Можливо, ця бізнес-логіка існує у іншому місці. Повторне використання коду завжди розумне рішення. 60 Повышение стоимости сопровождения системы (Недоступность исходного кода компонента может привести к увеличению расходов на сопровождение системы, так как повторно используемые системные элементы могут со временем оказаться не совместимыми с изменениями, производимыми в системе) Недостаточная инструментальная поддержка (CASE-средства не поддерживают разработку ПО с повторным использованием компонентов. Интегрирование этих средств с системой библиотек компонентов затруднительно или даже невозможно. Если процесс разработки ПО осуществляется с помощью CASE-средств, повторное использование компонентов можно полностью исключить) Синдром "изобретения велосипеда" (Некоторые разработчики ПО предпочитают переписать компоненты, так как полагают, что смогут при этом их усовершенствовать. Кроме того, многие считают, что создание программ "с нуля" перспективнее и "благороднее" повторного использования написанных другими программ) Содержание библиотеки компонентов (Заполнение библиотеки компонентов и ее сопровождение может стоить дорого. В настоящее время еще недостаточно хорошо продуманы методы классификации, каталогизации и извлечения информации о программных компонентах) Поиск и адаптация компонентов (Компоненты ПО нужно найти в библиотеке, изучить и адаптировать к работе в новых условиях, что "не укладывается" в обычный процесс разработки ПО) 61 Повторное использование, основанное на генераторах программ, возможно только тогда, когда можно идентифицировать предметные абстракции и их отображение в исполняемый код. Поэтому для компоновки и управления предметными абстракциями используются, как правило, проблемно-зависимые языки (например, языки четвертого поколения). Вот предметные области, в которых применение такого подхода может быть успешным. Генераторы приложений для обработки экономических данных. На входе генератора – описание приложения на языке четвертого поколения или диалоговая система, где пользователь определяет экранные формы и способы обработки данных. На выходе – программа на каком-либо языке программирования, например, COBOL или SQL. Генераторы программ синтаксического анализатора. На входе генератора – грамматическое описание языка, на выходе – программа грамматического разбора языковых конструкций. Генераторы кодов CASE-средств. На входе генераторов – архитектура ПО, а на выходе - программная реализация проектируемой системы. Разработка ПО с использованием программных генераторов экономически выгодна, однако существенно зависит от полноты и корректности определения абстракций предметной области. Данный подход можно широко использовать в перечисленных выше предметных областях и в меньшей степени при разработке систем управления и контроля. Главное преимущество этого подхода состоит в относительной легкости разработки программ с помощью генераторов. Однако необходимость глубокого понимания предметной области и ее моделей ограничивает применимость данного метода. 62 https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/izuchite-upravlenie-kachestvom-programmnogo-obespecheniia/izmerenie-programmnogo-obespecheniia 63 https://ce-na.ru/articles/o-nematerialnykh-aktivakh/ocenka_programmnogo_obespecheniya/ 64 Существуют разнообразные модели, методы и средства оценки стоимости программного обеспечения. В частности, на практике уверенно используются алгоритмические модели и неалгоритмические методы оценки стоимости ПО. В первом случае применяются математические формулы, а во втором - определенные принципы и схемы. К не алгоритмическим относятся методы price-to-win, оценка по Паркинсону, экспертная оценка и оценка по аналогии. Модели оценки стоимости ПО более понятны, точны и прозрачны. 65 Развитие компьютерных систем и постоянное внедрение инноваций привело к тому, что все популярные алгоритмы оценивания также развиваются, позволяя учитывать десятки разнообразных критериев, определять риск неудачи, принимать во внимание профессионализм команды разработчиков. Самыми продвинутыми и распространенными системами оценки стоимости разработки ПО являются: COCOMO (Constructive Cost Model) — имеющая несколько способов оценивания затрат на производство того или иного программного обеспечения. Применяя различные способы учета рабочих факторов, можно получить наиболее четкую схему затрат: как финансов, так и рабочих часов команды. SEER — многоплановая программа оценки, разработанная на базе алгоритмов оценки разработки проектов НАСА. Постоянное расширение дополнительных категорий привело к тому, что данное ПО позволяет определять стоимость проектов в зависимости от области применения, например: IT-индустрия, промышленность, финансы. Существует несколько более мелких программ, которые обладают схожими функциями, но пока не получили должного распространения из-за некоторых недоработок. Программное обеспечение — это интеллектуальная собственность, которая наделяет ее владельца соответствующими правами. Без оценки этой собственности нельзя в полной мере сказать, что дают эти права и полезны ли они кому-либо. Помимо прав существует и момент постановки программного обеспечения на баланс организации. В дальнейшем это ПО будет фигурировать в бухгалтерском учете, для которого необходимо знать стоимость программы. Также стоит упомянуть и о составлении лицензионного соглашения на получение прав использования программного обеспечения, которое нельзя создать без соответствующей оценки. При оценке программного обеспечения зачастую применяются доходный или расходный подходы. Они позволяют максимально точно оценить стоимость ПО и, исходя из этого, производить дальнейшие манипуляции с ним. 66 Алгоритмічні методи базуються на матема- тичних моделях, тому їхні результати є перед- бачуваними та повторюваними, але в багатьох випадках універсальні алгоритмічні моделі (такі як СОСОМО) мають достатньо низьку точність оцінки. Тому для підвищення точності оцінки постійно розробляються нові методи калібрування алгоритмічних моделей, які ма- ють на меті підвищити точність оцінки у кож- ному конкретному застосуванні, або на пев- ному підприємстві. В статті розглядається новий підхід до ка- лібрування моделі СОСОМО шляхом на змен- шення кількості параметрів моделі, який дозво- ляє підвищити точність та повторюваність ре- зультатів оцінки вартості ПЗ. Ефективність цього підходу тестується як основна гіпотеза дослідження: "Для будь-якого конкретного домену та організаційної ситуації існує така модель COCOMO з редукованою кількістю параметрів, якій відповідає вище значення PRED та менша дисперсія, ніж у ви- падку загальної моделі COCOMO". З практичної точки зору, усунення змінних параметрів вартості сприяє підвищенню ефек- тивності моделі вартості, яка підлаштована до існуючих в організації історичних даних та поточних проектів. Однак, якщо організація вносить значні зміни до методики роботи, які стосуються видалених із моделі змінних пара- метрів вартості (наприклад, перехід від розроб- ки звичайних бізнес-застосувань до розробки систем реального часу та критичних з точки зору безпеки систем), це буде значним ризиком отримання похибок оцінки. Тому метод буде випробуваний із наступним припущенням: "Прогнози щодо точності оцінки правдиві лише для проектів, аналогічних тим, що представлені у калібрувальному масиві даних" |