модуль1

11. Життєвий цикл ПЗ

Жизненный цикл программного обеспечения, как и любого другого изделия отображает состояние изделия во времени и пространстве, процессы, которые связаны с изделием средства осуществления процессов

Жизненный цикл состоит из фаз. Сущность фаз - выполнение процессов с помощью ресурсов (методы, средства, инструменты, персонал) и получение продуктов.

11. Процеси. Загальне поняття

Процесс – это ряд взаимосвязанных видов деятельности (действий), преобразующих входы в выходы. Согласно стандарту IЕЕЕ610 процесс определяется как последовательность этапов, направленных на достижение конкретной цели.

Стандартный процесс	это описание фундаментальных элементов процесса, которые будут включены в каждый определенный процесс
Определенный процесс	это пошаговое ряда определения видов длительности для достижения определенной цели.

■метапроцесс - действия, которые выполняет некоторая организация при проведении бизнеса, связанного с программным обеспечением. В центре процесса этого типа находятся экономика организации, долговременная стратегия и возврат инвестиций в ПО;

■ макропроцесс - действия, которые выполняются при реализации некоторого проекта программного обеспечения с учетом ограничений по стоимости, срокам и качеству.

■ микропроцесс - действия, которые выполняются командой разработчиков проекта про и направленные на получение конкретных результатов.

11. СМ модель

• Зрелость процесса программного обеспечения определяется как степень, с которой процесс явно определен, управляется, измеряется и контролируется, а также эффективен

• В настоящее время для оценки культуры персонала разработан кодекс этики инженера программного обеспечения, а для оценки уровня зрелости культуры организаций используется широко известная модель, разработанная в SEI Capability Matuvity Model (CMM) и ее дальнейшее развитие СММІ

  1. Предствник організації замовника перевіряє працюючу організацію

  2. Замовник звертається до незалежно оцінювача. Недолік- кожен замовник звертається до оцінювача

  3. Розробник отримує сертифікат якості в органзіції оцінювача з хорошою довірою як у замовника так і у розробника. Результат- довіра замовника

Міратек 3+ Софт лайн4

СММ Р-СММ

11. Культура інженерії ПЗ. Загальні концепції

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

Культура ІПЗ-сукупність орієнтованих на якість позицій розробників ,людських відношень і людських процесів.(якщо підприємство працює з з орієнтацією на якість і з повагою до замовника, то це великий +)

Культура вища за економіку. В основі будь-якої діяльності і виробництві лежить культура. Лихачов.

Культура ІПЗ характеризується

• ясными организационными целями;

• обязательством менеджмента вести организацию к достижению установленных целей;

• средой, которая позволяет каждому разработчику совершенствовать и эффективно применять свои знания и навыки;

• измерениями, позволяющими отбирать эффективные процессы.

11. Культура інженерії програмного забезпечення. Модель Константіноса.

Четыре организационных парадигмы:

Закрита	стабільна, секретна, незначна гнчкість, ниххідний процес прийняття рішеньт, нема іновацій, автторитарність	армія, спецслужба, не для підприємства
Відкрита	іновації, співробітництво, переговори, адаптація, колективне прийняття рішень	та середні пп. Великі пп намагаються містити ці характеристики ,але не можуть: У Майкрософт будь-хто може підійти до Гейтса з своїм питаням
Синхронна	Гармонійність ,рівність, ефективність, консерватизм , непрактичність керівництва	Радянські наукові центри, інститути досліджень: сильні традиції, немає іновацій
Випадкова	Незалежність ініціатив ,творчість і винахідництво, нестабільність, неформальність	Нема замовника, нема обмежень у часі. Студенська артистична група

11. Культура інженерії програмного забезпечення. Модель де Грака

Римский путь используют структурные методы больше формализмов крупные программы CASE инструменты строго управляемые проекты max документации управлять проектами

Греческий путь обьектно-ориентированные методы меньше формализмов меньше программ отдельные инструменты частично управляемые проекты min документации писать программы

11. Зв’язок культури з організацією ,яка розроблює ПЗ.

Любая «здоровая» культура должна включать три следующих существенных компонента:

• персональное обязательство каждого разработчика создавать качественные продукты путем систематического применения передового опыта инженерии программного обеспечения;

• обязательство менеджеров всех уровней обеспечивать среду, в которой качество программного обеспечения (во всех его аспектах) являться фундаментальной концепцией и каждый разработчик может реализовывать эту концепцию;

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

11. Домен ПЗ: дві точки зору.

С точки зрения компьютерных наук,	С точки зрения І П З
конструирование компьютерных программ – это математические действия подобные решению, например, дифференциальных уравнений.	программное обеспечение приобретает черты конструктивного инженерного домена, а конструирование компьютерных программ – становится частью соответствующей индустрии.

11. Еволюція індустрії ПЗ

Фази розвитку галузі

Фази розвитку ІПЗ

Стандарт IEEE 1074 “Standard for Developing Software Life Cycle Processes” предоставляет список процессов и действий по разработке и сопровождению программного обеспечения, а также список действий по поддержке самого жизненного цикла, который может быть отображен на процессы и организован таким же образом, как и любая модель жизненного цикла. Кроме того, этот стандарт идентифицирует и связывает другие стандарты IEEE с действиями по поддержке процессов жизненного цикла. В принципе, стандарт IEEE 1074 может быть использован для построения процессов, соответствующих любой модели жизненного цикла.

11. Процеси стандарту ІЕЕЕ 1074.Процеси менеджменту проекту

12. Процеси стандарту ІЕЕЕ 1074.Процеси попередньої розробки

11. А3 Процеси розробки стандарту ІЕЕЕ 1074

Ці групи виконуюють при розробці продуктів ПЗ

А.3.1 Діяльності спрямовані на розробку вимог до ПЗ:загальні вимоги до системжи та функціонального відображення усіх вимог на апараттне забезпечення.

А.3.1.1 Визначення та розробка вимог

А.3.1.2 Визначення вимог до інтерфейсу

А.3.1.3 Пріоритезація та інтеграція до ПЗ

• 500 тис на неправильну організацію даних а в замовника багато старих ПК

• В кінці озвучується ціна проекту

• Початок роботи зафіксувати в документації, детолізація(що отримати в кінці), заключити контракт

• Виявлення помилок на етапі розробки в 100 раз гірше чим виявити на етапі проектування.

А.3.2 Діяльності з проектування: розробка узгоджених і структурованих представлень ПЗ . Розробник фокусується на компонентах програмної системи. На рівні детально проектування розлядають сруктури даних та алгоритми для кожного елемента.

А.3.2.1 Виконання архітектурного проектування

А.3.2.2 Проектування без даних

А.3.2.3 Проектуванн інтерфейсів

А.3.2.4 Виконання детально проектування

• Не можна відразу писати код

• Архітектура проекту

А.3.3 Діяльності з реалізації

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

А.3.3.1 Створення виконуваного коду

А.3.3.2 Створення робочої документації

А.3.3.3 Виконання ітерації

• Створена комунікаційна система EWSD (більше 2000 програм) займає кімнату

11. А.4Процеси післярозробки стандарту ІЕЕЕ 1074

Дя група викнується для встановлення експлуатації, супроводу ,підтримки та зняття продуктів ПЗ

А.4.1 Діяльності з встановлення

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

А.4.1.1 Розповсюдження ПЗ

А.4.1.1 Встановлення ПЗ

А.4.1.3 Прийняття ПЗ у експлуатаційному середовищі

• Віндовс встановлюється 50 хв – хороший інсталятор.

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

А.4.2.1 Експлуатація системи

А.4.2.2 Забезпечення технічної допомоги та консультацій

А.4.2.3 ведення журналу запитів на підтримку

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

А.4.3 Діяльності з супроводу

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

А.4.3.1 Ідентифікація портеб у вдосконаленні

А.4.3.2 Реалізація методу звітування проблем

А.4.3.3 Повне застосування циклу розробки

• Супермаркет(доповнення коду)

• Супровід міняє програмний код(є системні помилки або треба доповнити)

• Підтримка- користувач сам вирішує питання.

А.4.4 Діяльності зі зняття

Включає видалення існуючої системи з активної підтримки або шляхом підтримки заміщення новим ПЗ

А.4.4.1Повідомлення користувача

А.4.4.2 Проведення паралельних операцій

А.4.4.3Зняття системи

• Залишаться системні папки після видалення

• Існують деінсталатори

• Бібліотека мала систему відомостей про книжки. До кінця 90-х застаріла. Знову вводити старі дані в нову систему нераціонально.

10. Процеси стандарту ІЕЕЕ 1074 Інтегровані процеси

А.5.3 Діяльності з розробки документації

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

А.5.3.1 Реалізація документації

А.5.3.2 Випуск та розповсюдження документації

• Документаці переходить з фази у фазу життєвого циклу ПЗ

А.5.4 Діяльності з з навчання

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

А.5.3.1 Розробка навчальних матеріалів

А.5.3.2 Валідація навчальної програми

А.5.3.3 Реалізація навчальної програми

10. Проект-

11. Задача-дія, яка має початок та завершення. Перервана задача- задача, виконання якої розподілене у календарному плані(наприклад. Якщо для виконання задачі потрібно 2 дні, то можливо розприділити частину роботи на понеділок і четвер)Сумарна задача- задача, що містить підзадачіКолонка „Тривалість” показує тривалість кожної задачі у днях. Надалі у колонках „Початок” та „Закінчення” вказується початок та закінчення етапів розробки. Інші колонки користувач може настроювати за потребами проекту, який розробляється

12. На діаграмі Ганта визначаються зв’язки наступних типів зв’язків:

• Finish-to-Start (FS) (завершення до початку) – наступна операція починається тільки після закінчення попередньої;

• Start-to-Start (SS) (початок до початку) – операції розпочинаються одночасно;

• Finish-to-Finish (FF) (завершення до завершення) – операції повинні закінчитися одночасно;

• Start-to-Finish (SF) (початок до завершення) – одна операція не може завершитися доки інша не розпочнеться.

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

11. Призначення опису вимог

10. WBS OSB