Спомагателните процеси на жизнения цикъл включват. Модели на жизнения цикъл на софтуера. Жизненият цикъл какво е това във формален смисъл

Структурата на жизнения цикъл на софтуера в съответствие със стандарта ISO/IEC 12207 се основава на три групи процеси (фиг. 1):

основните процеси от жизнения цикъл на софтуера (придобиване, доставка, разработка, експлоатация, поддръжка);

спомагателни процеси, които осигуряват изпълнението на основните процеси (документация, управление на конфигурацията, осигуряване на качеството, проверка, сертифициране, оценка, одит, решаване на проблеми);

организационни процеси (управление на проекти, създаване на проектна инфраструктура, дефиниране, оценка и подобряване на самия жизнен цикъл, обучение).

Ориз. 1. Процеси жизнен цикъл софтуер.

Процес на придобиване(процес на придобиване). Състои се от действия

и задачи на клиента, закупуващ софтуера. Този процес обхваща следните стъпки:

1) започване на придобиване;

2) изготвяне на предложения за кандидатстване;

3) изготвяне и коригиране на договора;

4) надзор върху дейността на доставчика;

5) приемане и завършване на работата.

Процес на доставка(процес на доставка). Той обхваща дейностите и задачите, изпълнявани от доставчик, който предоставя на клиента софтуерен продукт или услуга. Този процес включва следните стъпки:

1) започване на доставката;

2) изготвяне на отговор на оферти;

3) изготвяне на договора;

4) планиране;

5) изпълнение и контрол;

6) проверка и оценка;

7) доставка и завършване на работите.

Процес на развитие(процес на развитие). Той предвижда действията и задачите, изпълнявани от разработчика, и обхваща създаването на софтуер и неговите компоненти в съответствие с посочените изисквания, включително изготвяне на проектна и оперативна документация, подготовка на материали, необходими за тестване на работоспособността и подходящото качество на софтуера продукти, материали, необходими за организиране на обучение на персонал и др.

Процесът на разработка включва следните стъпки:

1) анализ на системните изисквания;

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

3) анализ на софтуерните изисквания;

4) проектиране на софтуерна архитектура;

5) подробен софтуерен дизайн;

6) програмно кодиране и тестване;

7) софтуерна интеграция;

8) тестване за квалификация на софтуер;

9) системна интеграция;

10) квалификационно изпитване на системата;

11) инсталиране на софтуер;

12) приемане на софтуер.

Оперативен процес(оперативен процес). Той обхваща дейностите и задачите на оператора – организацията, която управлява системата. Този процес включва следните стъпки:

1) оперативни тестове;

2) работа на системата;

3) потребителска поддръжка.

Процес на поддръжка(процес на поддръжка). Той предвижда дейностите и задачите, изпълнявани от придружаващата организация (служба за поддръжка). Този процес се активира с промени (модификации) софтуерен продукти свързана документация, причинена от възникнали проблеми или необходимостта от надграждане или адаптиране на софтуера. Според стандарта IEEE-90 поддръжката се отнася до извършване на промени в софтуера за отстраняване на грешки, подобряване на производителността или адаптиране към променящите се условия на работа или

изисквания. Промените в съществуващия софтуер не трябва да нарушават

неговата цялост. Процесът на поддръжка включва прехвърляне на софтуер в друга среда (миграция) и завършва с извеждането на софтуера от експлоатация.

Процесът на поддръжка обхваща следните стъпки:

1) анализ на проблеми и заявки за модификация на софтуера;

2) модификация на софтуера;

3) проверка и приемане;

4) трансфер на софтуер в друга среда;

5) извеждане от експлоатация на софтуер.

Групата от спомагателни процеси включва:

Документация;

Управление на конфигурацията; осигуряване на качеството;

Проверка; атестация;

Съвместна оценка;

Разрешаване на проблема.

Процес на документиране(процес на документиране). Той предоставя формализирано описание на информацията, създадена по време на жизнения цикъл на софтуера. Процесът на документиране включва следните стъпки:

1) проектиране и разработка;

2) издаване на документация;

3) поддържане на документация.

Процес на управление на конфигурацията(процес за управление на конфигурацията). Той включва прилагането на административни и технически процедури през целия жизнен цикъл на софтуера за определяне на състоянието на софтуерните компоненти в системата, управление на софтуерни модификации, описване и докладване за състоянието на софтуерните компоненти и заявки за модификации, осигуряване на пълнота, съвместимост и коректност на софтуерни компоненти, управление на съхранение и доставка ВКЛ. Според стандарта IEEE-90 под конфигурация на софтуера се разбира съвкупността от неговите функционални и физически характеристики.

характеристики, установени в техническа документацияи внедрени в софтуер.

Управлението на конфигурацията ви позволява да организирате, систематично отчитате и контролирате промените в софтуера на всички етапи от жизнения цикъл. Общи принципи и препоръки за управление на конфигурацията на софтуера са отразени в проекта на стандарт ISO/I EC CD 12207-2: 1995 „Информационни технологии – Процеси на жизнения цикъл на софтуера. Част 2.

Управление на конфигурацията за софтуер". Процесът на управление на конфигурацията включва следните стъпки:

1) идентификация на конфигурацията;

2) контрол на конфигурацията;

3) като се вземе предвид състоянието на конфигурацията;

4) оценка на конфигурацията;

5) управление на освобождаването и доставка.

Процес за осигуряване на качеството(процес за осигуряване на качеството). Той предоставя подходяща гаранция, че софтуерът и процесите на неговия жизнен цикъл отговарят на определени изисквания и одобрени планове. Качеството на софтуера се разбира като набор от свойства, които характеризират способността на софтуера да отговаря на определени изисквания. За да се получат надеждни оценки на създавания софтуер, процесът на осигуряване на неговото качество трябва да се извършва независимо от субектите, пряко свързани с разработката на софтуер. Могат да се използват резултатите от други поддържащи процеси, като проверка, атестиране, оценка с участие, одит и разрешаване на проблеми. Процесът на осигуряване на качеството включва следните дейности:

1) осигуряване на качеството на продукта;

2) осигуряване на качеството на процеса;

3) осигуряване на други показатели за качеството на системата.

Процес на проверка(процес на проверка). Състои се в това да се установи, че софтуерните продукти, които са резултат от някакво действие, напълно отговарят на изискванията или условията, предвидени от предишни действия (верификация в тесен смисъл означава формално доказателство за коректност на софтуера).

Процес на атестиране(процес на валидиране). Той предвижда определяне на пълнотата на съответствието на посочените изисквания и създадената система или софтуерен продукт със специфичното им функционално предназначение. Сертифицирането обикновено се разбира като потвърждение и оценка на надеждността на софтуерното тестване.

Съвместен процес на оценяване(съвместен процес на преглед). Той е предназначен за оценка на състоянието на работата по проекта и софтуера, създаден по време на изпълнението на тези работи (действия). Той се фокусира основно върху планирането и управлението на ресурсите на проекта, персонала, оборудването и инструментите.

Процес на одит(одитен процес). Това е определяне на съответствието с изискванията, плановете и условията на договора.

Процес за разрешаване на проблеми(процес за разрешаване на проблеми). Той осигурява анализ и разрешаване на проблеми (включително открити несъответствия), независимо от техния произход или източник, които са открити по време на разработка, експлоатация, поддръжка или други процеси. Всеки открит проблем трябва да бъде идентифициран, описан, анализиран и разрешен.

Групата организационни процеси от жизнения цикъл на софтуера включва:

Контрол;

Създаване на инфраструктура;

подобрение;

Излизане на нови версии;

Образование.

Процес на управление(управленски процес). Състои се от дейности и задачи, които могат да бъдат изпълнявани от всяка страна, управляваща собствените си процеси. Тази страна (мениджър) отговаря за управлението на пускането на продукти, управлението на проекти и управлението на задачи на свързани процеси като придобиване, доставка, разработка, експлоатация, поддръжка и др.

Инфраструктурен процес(инфраструктурен процес). Той обхваща избора и поддръжката (поддръжката) на технологии, стандарти и инструменти, избора и инсталирането на хардуер и софтуер, използвани за разработване, експлоатация или поддръжка на софтуер. Инфраструктурата трябва да бъде модифицирана и поддържана в съответствие с промените в изискванията за съответните процеси. Инфраструктурата от своя страна е един от обектите на управление на конфигурацията.

Процес на подобрение(процес на подобрение). Той осигурява оценка, измерване, контрол и подобряване на процесите на жизнения цикъл на софтуера. Подобряването на процесите на жизнения цикъл на софтуера е насочено към повишаване на производителността на всички специалисти, участващи в тях чрез подобряване на използваната технология, методите на управление, избора на инструменти и обучение

персонал.

Процес на обучение(тренировъчен процес). То обхваща първоначално обучение и последващо продължаващо обучение на персонала.

Здравейте, скъпи хабровци! Мисля, че ще бъде интересно някой да си спомни какви модели на разработка, внедряване и използване на софтуер е съществувало по-рано, какви модели се използват основно сега, защо и какво всъщност е това. Това ще бъде моята малка тема.

Всъщност какво е жизнен цикъл на софтуера- поредица от събития, които се случват със системата в процеса на нейното създаване и по-нататъшно използване. С други думи, това е времето от началния момент на създаване на софтуерен продукт до края на неговото разработване и внедряване. Жизненият цикъл на софтуера може да бъде представен под формата на модели.

Модел на жизнения цикъл на софтуера- структура, съдържаща процесите на действие и задачи, които се изпълняват по време на разработването, използването и поддръжката на софтуерен продукт.
Тези модели могат да бъдат разделени на 3 основни групи:

1. Инженерен подход
2. Като се има предвид спецификата на задачата
3. Съвременни технологии за бързо развитие

Модел за кодиране и обработка на грешки

1. Формулиране на проблема
2. производителност
3. Проверка на резултата
4. Ако е необходимо, преминете към първата точка

Модел на жизнения цикъл на софтуера Waterfall (Waterfall)

предимства:

• Последователно изпълнение на етапите на проекта в строго определен ред
• Позволява ви да оцените качеството на продукта на всеки етап

• Липса на обратна връзка между етапите
• Не отговаря на реалните условия на разработка на софтуерен продукт

Каскаден модел с междинно управление (Whirlpool)

V модел (разработване чрез тестване)

Разработване на прототипи на базата на модел

1. Изясняване на неясни изисквания (прототип на потребителския интерфейс)
2. Изберете едно от редица идейни решения (изпълнение на сценарии)
3. Анализирайте осъществимостта на проекта

1. Хоризонтални и вертикални
2. Еднократна и еволюционна
3. хартия и разкадровки

Моделът принадлежи към втората група.

Спирален модел на жизнения цикъл на софтуера

предимства:

• Бързи резултати
• Повишаване на конкурентоспособността
• Промяната на изискванията не е проблем

• Липса на регулиране на етапа

Благодаря ви много за вашето внимание!

Структурата на жизнения цикъл съгласно ISO/IEC 12207 се основава на три групи процеси: основни, спомагателни, организационни.

Основни процеси на жизнения цикъл.

Основните процеси включват набор определени действияи свързани задачи, които трябва да се изпълняват по време на жизнения цикъл на софтуерния продукт (SP).

Основните процеси от жизнения цикъл на софтуера включват процесите на придобиване, доставка, разработка, експлоатация и поддръжка.

Процесът на придобиване обхваща дейностите на клиента за придобиване на софтуера. Тези действия включват:

• 1) Инициирането на придобиване включва много задачи, включително идентифициране на клиента на неговите нужди от придобиване, разработване или подобряване на системата PP.
• 2) Изготвянето на предложения за кандидатстване предполага разработване и изготвяне на предложения, които да съдържат: изисквания към разработваната или закупуваната система; списък на необходимия софтуер; правила и условия; технически ограничения.
• 3) Изготвянето и коригирането на договора включва следните задачи: избор от доставчика на критерия за оценка на предложенията; избор на конкретен доставчик въз основа на анализ на предложенията; подготовка и сключване на договор с доставчик; внасяне на промени (ако е необходимо) в договора в процеса на неговото изпълнение.
• 4) Надзорът върху дейността на доставчиците се извършва в съответствие с действията, предвидени в процеса на съвместна оценка на одита.
• 5) Приемане и завършване на работата.

В процеса на приемане се подготвят и извършват необходимите тестове. Завършването на работата по договора се извършва при изпълнение на всички условия за приемане.

Процесът на доставка обхваща дейностите и задачите на доставчика при снабдяването на клиента със софтуер или услуга.

Тези действия включват:

• 1) Започването на доставката се състои в разглеждане на тръжните предложения от доставчика и приемане на решение.
• 2) Изготвянето на отговор на оферти се извършва в съответствие с взетите решения.
• 3) Изготвянето на договора се извършва след като клиентът избере конкретен доставчик.
• 4) Планирането се извършва след сключване на договора и включва следните задачи: вземане на решение от доставчика относно извършването на работа самостоятелно или с участието на подизпълнител; разработване от доставчика на план за управление на проекта, съдържащ организационна структурапроект, разделение на отговорностите, Технически изискваниякъм средата за разработка, управление на подизпълнители.
• 5) Изпълнение и контрол.
• 6) Проверка и оценка.
• 7) Доставката и завършването на работата се извършва в съответствие с действията, договорени в процеса на започване на приемане и завършване на работата.

Процесът на разработка обхваща действията и задачите на разработчика и предвижда следните основни области на работа:

• 1) Създаване на софтуер и неговите компоненти с определени изисквания, включително изготвяне на проектна и експлоатационна документация.
• 2) Подготовка на материали, необходими за тестване на производителността и качеството на софтуера.
• 3) Подготовка на материали, необходими за организиране на обучение на персонала и др.

Оперативният процес обхваща действията и задачите на оператора - организацията, участваща в експлоатацията на разработения софтуер. Тези действия включват: подготвителна работа, оперативно тестване, работа на системата, потребителска поддръжка е да предостави помощ и съвет, когато бъдат открити грешки по време на работата на софтуера.

Последващ процес. Този процес се активира в случай на промени (модернизация) на софтуера и свързаната с него документация, причинени от възникнали проблеми.

Основната цел на тези процеси е създаването на надежден софтуерен продукт, който да отговаря напълно на изискванията на клиента в сроковете, определени с договора.

Поддържа процеси на жизнения цикъл

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

Процесът на документиране осигурява формализирано описание на информацията, създадена по време на жизнения цикъл на софтуера.

Този процес включва:

• 1) Подготвителната работа, която е необходима за определяне и съгласуване задължителен списъкдокументи и документирани процедури.
• 2) Проектиране и разработване на документация, които се извършват в процеса на работа върху софтуера и се завършват едновременно с приключването на жизнения му цикъл.
• 3) Освобождаване на документация, която се извършва, когато е готова.
• 4) Поддръжката включва действия за коригиране и актуализиране на документацията по време на жизнения цикъл на софтуерните продукти.

Процесът на управление на конфигурацията включва прилагането на административни и технически процедури през целия жизнен цикъл на софтуера.

Софтуерната конфигурация се разбира като съвкупността от нейните функционални и физически характеристики, установени в техническата документация и внедрени в софтуера.

Този процес включва:

• 1) Подготвителната работа, която е да се планира управлението на конфигурацията.
• 2) Идентификация на конфигурацията - установява правила, чрез които е възможно еднозначно да се идентифицират и разграничат софтуерните компоненти и техните версии. В допълнение, всеки компонент и неговите версии имат уникално идентифициран набор от документация.
• 3) Конфигурационен контрол - предназначен за систематична оценка на предложените модификации на софтуера и тяхното координирано внедряване, като се отчита ефективността на всяка модификация и цената на нейното внедряване.
• 4) Отчитане на състоянието на конфигурацията - е регистриране на състоянието на софтуерните компоненти, изготвяне на отчети за всички внедрени и отхвърлени модификации на версиите на софтуерните компоненти.
• 5) Оценка на конфигурацията – състои се в оценка на функционалната пълнота на софтуерните компоненти.
• 6) Управлението на пускането и доставката включва производството на основни копия на програми и документация, тяхното съхранение и доставка на потребителите в съответствие с процедурата, приета от организацията.

Процесът на осигуряване на качеството осигурява адекватна гаранция, че продуктът и процесите на неговия жизнен цикъл отговарят на определени изисквания и одобрени планове.

За да се получат надеждни оценки на създавания софтуер, процесът по осигуряване на неговото качество трябва да се извършва независимо от субектите, пряко свързани с разработването на софтуер.

Процесът на проверка се състои в доказване, че ПП, което е резултат от някакво действие, напълно отговаря на изискванията или условията, които зависят от предишни действия.

Проверката може да се извърши както от самия изпълнител, така и от друг специалист на тази организация, както и от специалист на организация на трета страна. Проверката в тесен смисъл означава формално доказване на правилността на ПП. Този процес може да включва анализ, оценка и тестване.

Процесът на сертифициране включва определяне на пълнотата на съответствие с определените изисквания за създаваната система или софтуер.

Сертифицирането обикновено се разбира като потвърждение и оценка на надеждността на тестването на софтуерни продукти. Одобрението трябва да гарантира пълно съответствие, както и възможността за безопасното и надеждно използване от потребителя.

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

Процесът на одит е определяне на съответствието с изискванията, плановете и условията на договора, както хода на работата по създаването на софтуера, така и самия продукт.

Одитът служи за установяване на съответствието на реалната работа и отчети, така че одиторите (одиторите) не трябва да бъдат пряко зависими от разработчиците на софтуер.

Процесът на разрешаване на проблеми включва анализиране и разрешаване на проблеми, открити по време на разработка, операции и други процеси, независимо от техния проблем или източник. Всеки открит проблем трябва да бъде идентифициран, описан, анализиран и разрешен.

Разрешаването на проблемите се извършва през целия жизнен цикъл на SP.

Организационни процеси на жизнения цикъл

Основната цел на организационните процеси е да организира процеса на разработване на надежден софтуерен продукт, който напълно отговаря на изискванията на клиента в рамките на сроковете, определени с договора, и да управлява този процес. Организационните процеси включват управление, създаване на инфраструктура, подобряване и обучение.

Процесът на управление на проекти се състои от дейности и задачи, които могат да бъдат изпълнявани от всяка страна, управляваща собствените си процеси. Тази страна (мениджър) отговаря за управлението на пускането на продукта, проекта и задачите на свързаните процеси, като придобиване, доставка, разработка, експлоатация, поддръжка и др.

Процесът на създаване на инфраструктура обхваща избора и поддръжката (поддръжката) на технологии, стандарти и инструменти, избора и инсталирането на хардуер и софтуер, използвани за разработване, експлоатация и поддръжка на софтуерни продукти.

Процесът на усъвършенстване предвижда оценка, измерване, контрол, подобряване на процесите от жизнения цикъл на софтуера.

Подобряването на процесите от жизнения цикъл на софтуера е насочено към повишаване на производителността на всички специалисти, участващи в тях, чрез подобряване на използваната технология, методите на управление, избора на инструменти и обучението на персонала.

Процесът на обучение обхваща първоначално обучение и последващо развитие на персонала. Основните процеси до голяма степен зависят от нивото на знания и квалификация на персонала.

За този процес трябва да се планират необходимите ресурси и технически средства за автоматизация.

Разработването на софтуер е невъзможно без разбиране на така наречения жизнен цикъл на софтуера. Обикновеният потребител може да не трябва да знае това, но е желателно да научи основните стандарти (по-късно ще бъде казано защо това е необходимо).

Какъв е жизненият цикъл във формален смисъл?

Под жизнения цикъл на всеки е обичайно да се разбира времето на неговото съществуване, като се започне от етапа на разработка и до момента на пълно отказване от употреба в избраната област на приложение, до пълното премахване на приложението от употреба.

С прости думи, Информационни системипод формата на програми, бази данни или дори „операционни системи“ са търсени само ако данните и възможностите, които предоставят, са подходящи.

Смята се, че определението за жизнен цикъл не се прилага по никакъв начин за тестване на приложения, като бета версиите, които са най-нестабилни при работа. Самият жизнен цикъл на софтуера зависи от много фактори, сред които една от основните роли играе средата, в която ще се използва програмата. Все пак човек може да различи общи условияизползвани при дефинирането на концепцията за жизнения цикъл.

Първоначални изисквания

• формулиране на проблема;
• анализ на взаимните изисквания на бъдещия софтуер към системата;
• дизайн;
• програмиране;
• кодиране и компилиране;
• тестване;
• отстраняване на грешки;
• внедряване и поддръжка на софтуерния продукт.

Разработването на софтуер се състои от всички гореспоменати етапи и не може без поне един от тях. Но за контрол на такива процеси се установяват специални стандарти.

Стандарти за процес на жизнен цикъл на софтуера

Сред системите, които предопределят условията и изискванията за такива процеси, днес могат да се назоват само три основни:

• GOST 34.601-90;
• ISO/IEC 12207:2008;
• Oracle CDM.

За втория международен стандарт има руски аналог. Това е GOST R ISO / IEC 12207-2010, който отговаря за системите и софтуерното инженерство. Но жизненият цикъл на софтуера, описан в двете правила, е по същество идентичен. Това се обяснява доста просто.

Видове софтуер и актуализации

Между другото, за повечето от известните в момента мултимедийни програми те са средството за запазване на основните конфигурационни настройки. Използването на този тип софтуер, разбира се, е доста ограничено, но разбирането на общите принципи на работа със същите медийни плейъри не пречи. И ето защо.

Всъщност те имат жизнен цикъл на софтуера само на нивото на периода на актуализация за версията на самия плейър или инсталирането на кодеци и декодери. А аудио и видео транскодерите са основни атрибути на всяка аудио или видео система.

Пример, базиран на FL Studio

Първоначално виртуалното студио-секвенсор FL Studio се нарича Fruity Loops. Жизненият цикъл на софтуера в основната му модификация е изтекъл, но приложението е донякъде трансформирано и придобива сегашния си вид.

Ако говорим за етапите от жизнения цикъл, в началото, на етапа на поставяне на задачата, бяха зададени няколко задължителни условия:

• създаване на барабанен модул, подобен на ритъм машини като Yamaha RX, но с използване на еднократни семпли или WAV последователности, записани на живо в студия;
• интеграция в операционна системапрозорци;
• възможност за експортиране на проекта във формати WAV, MP3 и OGG;
• съвместимост на проекта с допълнителното приложение Fruity Tracks.

На етапа на разработка бяха използвани инструментите на езиците за програмиране C. Но платформата изглеждаше доста примитивна и не позволяваше на крайния потребител необходимо качествозвук.

В тази връзка, на етапа на тестване и отстраняване на грешки, разработчиците трябваше да следват пътя на немската корпорация Steinberg и да приложат поддръжка на Full Duplex режим в изискванията за основния звуков драйвер. Качеството на звука стана по-високо и ви позволява да променяте темпото, височината и да прилагате допълнителни FX ефекти в реално време.

Краят на жизнения цикъл на този софтуер се счита за пускането на първата официална версия на FL Studio, която, за разлика от своите предци, вече имаше пълноправен интерфейс на секвенсор с възможност за редактиране на параметри на виртуален 64-канален миксираща конзола с неограничено добавяне на аудио записи и MIDI записи.

Това не беше ограничено. На етапа на управление на проекта беше въведена поддръжка за свързване на плъгини във формат VST (първо втора, а след това трета версия), разработен някога от Steinberg. Грубо казано, всеки виртуален синтезатор, който поддържа VST-host, може да се свърже с програмата.

Не е изненадващо, че скоро всеки композитор може да използва аналози на "железните" модели, например пълните набори от звуци на някога популярния Korg M1. Освен това. Използването на модули като Addictive Drums или универсалния плъгин Kontakt направи възможно възпроизвеждането на живи звуци на истински инструменти, записани с всички нюанси на артикулация в професионални студия.

В същото време разработчиците се опитаха да постигнат максимално качество, като създадоха поддръжка за драйвери ASIO4ALL, които се оказаха с главата и раменете над режима Full Duplex. Съответно битрейтът също се увеличи. Към днешна дата качеството на експортирания аудио файл може да бъде 320 kbps при честота на дискретизация от 192 kHz. Това е професионален звук.

Що се отнася до първоначалната версия, жизненият й цикъл може да се нарече напълно завършен, но подобно твърдение е относително, тъй като приложението само е променило името си и е получило нови функции.

Перспективи за развитие

Какви са етапите от жизнения цикъл на софтуера вече е ясно. Но развитието на такива технологии си струва да се спомене отделно.

Излишно е да казвам, че всеки разработчик на софтуер не се интересува от създаването на мимолетен продукт, който е малко вероятно да остане на пазара за няколко години. В бъдеще всеки гледа към дългосрочната му употреба. Това може да се постигне различни начини. Но като правило почти всички се свеждат до пускането на актуализации или нови версии на програми.

Дори в случая с Windows подобни тенденции могат да се видят с просто око. Малко вероятно е днес да има поне един потребител, използващ системи като модификации 3.1, 95, 98 или Millennium. Техният жизнен цикъл приключи след пускането на версията XP. Но версиите на сървъра, базирани на NT технологии, все още са актуални. Дори Windows 2000 днес е не само много актуален, но дори превъзхожда най-новите разработки в някои параметри на инсталация или сигурност. Същото важи и за системата NT 4.0, както и за специализирана модификация на Windows Server 2012.

Но във връзка с тези системи поддръжката все още се декларира на самите високо ниво. Но сензационната за времето си Vista очевидно преживява упадъка на цикъла. Той не само се оказа недовършен, но имаше толкова много грешки в себе си и пропуски в системата му за сигурност, че може само да се гадае как едно такова несъстоятелно решение може да бъде пуснато на софтуерния пазар.

Но ако говорим за факта, че разработването на софтуер от всякакъв тип (управление или приложение) не стои неподвижно, то е само възможно. В крайна сметка днес това се отнася не само за компютърни системи, но и за мобилни устройствав които прилаганите технологии често изпреварват компютърния сектор. Появата на процесорни чипове, базирани на осем ядра - отколкото не най-много най-добрият пример? Но не всеки лаптоп може да се похвали с такъв хардуер.

Някои допълнителни въпроси

Що се отнася до разбирането за жизнения цикъл на софтуера, може да се каже, че той е приключил в определен момент от време, то е много условно, тъй като софтуерните продукти все още имат поддръжка от разработчиците, които са ги създали. По-скоро краят се отнася до наследени приложения, които не отговарят на изискванията съвременни системии не могат да работят в тяхната среда.

Но дори като се вземе предвид технологичният прогрес, много от тях в близко бъдеще може да се окажат несъстоятелни. Тогава ще трябва да вземете решение или да пуснете актуализации, или да преразгледате напълно цялата концепция, която първоначално е била включена в софтуерния продукт. Оттук и новият цикъл, който включва промяна на първоначалните условия, средата за разработка, тестване и възможно дългосрочно приложение в определена област.

Но в компютърните технологии днес се дава предпочитание на разработването на автоматизирани системи за управление (ACS), които се използват в производството. Дори операционните системи, в сравнение със специализираните програми, губят.

Същите среди, базирани на Visual Basic, остават много по-популярни от Windows системите. И изобщо не говорим за приложен софтуер за UNIX системи. Какво да кажа, ако почти всички комуникационни мрежи на едни и същи Съединени щати работят изключително за тях. Между другото, системи като Linux и Android също първоначално са създадени на тази платформа. Следователно най-вероятно UNIX има много повече перспективи от другите продукти, взети заедно.

Вместо общо

Остава да добавим, че само в този случай основни принципии етапи от жизнения цикъл на софтуера. Всъщност дори първоначалните задачи могат да се различават много значително. Съответно разликите могат да се наблюдават на други етапи.

Но основните технологии за разработване на софтуерни продукти с последващата им поддръжка трябва да са ясни. За останалото трябва да се вземат предвид спецификата на създавания софтуер, средата, в която се предполага, че той работи, както и възможностите на програмите, предоставяни на крайния потребител или продукцията, и много други.

В допълнение, понякога жизнените цикли могат да зависят от уместността на инструментите за разработка. Ако например някой език за програмиране стане остарял, никой няма да пише програми въз основа на него и още повече - да ги прилага в автоматизирани системиуправление на производството. Тук на преден план излизат дори не програмисти, а маркетолози, които трябва да реагират своевременно на промените на компютърния пазар. А в света няма толкова много такива специалисти. Най-търсените стават висококвалифицирани кадри, способни да бъдат в крак с пазара. И именно те често са така наречените „сиви кардинали“, от които зависи успехът или провалът на определен софтуерен продукт в IT сферата.

Въпреки че не винаги разбират същността на програмирането, те ясно могат да определят моделите на жизнения цикъл на софтуера и продължителността на тяхното използване въз основа на световните тенденции в тази област. Ефективно управлениечесто дава по-осезаеми резултати. Да, поне PR технологии, реклама и т.н. Потребителят може да не се нуждае от някакво приложение, но ако се рекламира активно, потребителят ще го инсталира. Това вече е, така да се каже, подсъзнателно ниво (същият ефект на 25-ия кадър, когато информацията се поставя в съзнанието на потребителя, независимо от него).

Разбира се, подобни технологии са забранени в света, но много от нас дори не осъзнават, че все още могат да се използват и да въздействат на подсъзнанието по определен начин. Какво струва „зомбирането“ на новинарски канали или интернет сайтове, да не говорим за използването на по-мощни средства, като инфразвуково излагане (това е използвано в една оперна постановка), в резултат на което човек може да изпита страх или неадекватност емоции.

Връщайки се към софтуера, си струва да добавим, че някои програми използват звуков сигнал при стартиране, за да привлекат вниманието на потребителя. И проучванията показват, че такива приложения са по-жизнеспособни от другите програми. Естествено, жизненият цикъл на софтуера също се увеличава, независимо за каква функция е бил първоначално възложен. И това, за съжаление, се използва от много разработчици, което поражда съмнения относно законността на подобни методи.

Но не е наша задача да съдим това. Възможно е в близко бъдеще да бъдат разработени инструменти за идентифициране на подобни заплахи. Засега това е само теория, но според някои анализатори и експерти, преди практическо приложениеостава много малко. Ако вече създават копия на невронните мрежи на човешкия мозък, тогава какво да кажа?

Анотация.

Въведение.

1. Жизненият цикъл на софтуера

Въведение.

Стъпки на процеса на програмиране на Райли

Въведение.

1.1.1. Формулиране на проблема.

1.1.2. Дизайн на решение.

1.1.3. Алгоритъм за кодиране.

1.1.4. Програмна поддръжка.

1.1.5. Софтуерна документация.

Заключение към параграф 1.1

1.2. Определение на ZhTsPO според Lehman.

Въведение.

1.2.1 Дефиниция на системата.

1.2.2. Изпълнение.

1.2.3. Обслужване.

Заключение към т. 1.2.

1.3. Фази и произведения на програмата за жизнения цикъл според Boehm

1.3.1. каскаден модел.

1.3.2. Икономическа обосновкакаскаден модел.

1.3.3. Подобряване на каскадния модел.

1.3.4. Дефиниране на фазите на жизнения цикъл.

1.3.5. Основна работа по проекта.

литература.

Въведение

Индустриалното приложение на компютрите и нарастващото търсене на програми поставиха спешни задачи за значително увеличаване на производителност при разработка на софтуер, разработване на индустриални методи за планиране и проектиране на програми, пренасяне на организационни, технически, технически, икономически и социално-психологически техники, модели и методи от сферата на материалното производство в сферата на компютрите. Сложен подход към процесите на разработка, експлоатация и поддръжка на софтуера поставят редица належащи проблеми, чието решение ще премахне "тесните места" при проектирането на програми, ще намали времето за завършване, ще подобри избора и адаптирането на съществуващите програми и може би ще определи съдбата на системите с вградени компютри.

В практиката на разработване на големи софтуерни проекти често няма единен подходдо оценката на разходите за труд, сроковете на работа и материалните разходи, което пречи на повишаването на производителността на разработката на софтуер и в крайна сметка - ефективно управлениежизнен цикъл на софтуера. Тъй като програма от всякакъв вид се превръща в продукт (с изключение, може би, образователни, макетни програми), подходът към нейното производство трябва да бъде подобен в много отношения на подхода към производството на промишлени продукти, а проблемите с дизайна на софтуера стават изключително важни . Тази идея е в основата на B.U. Boehm "Проектиране на софтуерно инженерство", който използвахме, за да напишем това срочна писмена работа. В тази книга софтуерният дизайн се отнася до процеса на създаване на дизайн за софтуерен продукт.

1 Жизненият цикъл на софтуера

ВЪВЕДЕНИЕ

LCPE е непрекъснат процес, който започва от момента на вземане на решение за необходимостта от създаване на софтуер и завършва в момента, в който той бъде напълно изтеглен от експлоатация.

Има няколко подхода за дефиниране на фазите и дейностите на жизнения цикъл на софтуера (SLLC), стъпките на процеса на програмиране, водопадни и спираловидни модели. Но всички те съдържат общи основни компоненти: описание на проблема, дизайн на решение, изпълнение, поддръжка.

Най-известната и пълна, може би, е структурата на жизнения цикъл според Бьом, която включва осем фази. Тя ще бъде представена по-подробно по-късно.

Един от настроикиможе да служи като описание на горното ниво според Lehman, което включва три основни фази и представлява описание на програмата на жизнения цикъл в най-общия случай.

И за промяна, ето стъпките от процеса на програмиране, представени от Д. Райли в книгата “Използване на езика Modula-2”. Тази идея според мен е много проста и позната и ще започнем с нея.

1.1 Стъпки от процеса на програмиране на Riley

Процесът на програмиране включва четири стъпки (фиг. 1):

постановка на проблема, т.е. получаване на адекватна представа за това каква задача трябва да изпълнява програмата;

проектиране на решение на вече поставен проблем (по принцип такова решение е по-малко формално от окончателната програма);

програмно кодиране, т.е. превод на проектираното решение в програма, която може да се изпълнява на машина;

програмна поддръжка, т.е. текущ процес на коригиране на грешки в програмата и добавяне на нови функции.

Ориз. 1.Четири стъпки за програмиране.

Програмирането започва от момента, в който потребител, т.е. някой, който има нужда от програма за решаване на проблем, създава проблем системен анализатор.Потребителят и системният анализатор съвместно определят формулировката на проблема. След това последният се прехвърля алгоритмисткойто отговаря за проектирането на решението. Решението (или алгоритъмът) е последователност от операции, чието изпълнение води до решаване на проблем. Тъй като алгоритъмът често не е адаптиран за изпълнение на машина, той трябва да бъде преведен в машинна програма. Тази операция се извършва от енкодера. Придружаващият програмист е отговорен за последващите промени в програмата. И системният анализатор, и алгоритмистът, и кодерът, и придружаващият го програмист - всички те са програмисти.

В случай на голям софтуерен проект, броят на потребителите, системните анализатори и алгоритмите може да бъде значителен. Освен това може да се наложи да се върнете към предишни стъпки поради непредвидени обстоятелства. Всичко това служи като допълнителен аргумент в полза на внимателното проектиране на софтуера: резултатите от всяка стъпка трябва да бъдат пълни, точни и разбираеми.

1.1.1 Постановка на проблема

Един от най важни стъпкипрограмирането е формулировка на проблема. Той функционира като договор между потребителя и програмиста(ите). Подобно на юридически лошо изготвен договор, лошото изявление за мисия е безполезно. С добра постановка на проблема, както потребителят, така и програмистът ясно и недвусмислено представят задачата, която трябва да се изпълни, т.е. в този случай се вземат предвид интересите както на потребителя, така и на програмиста. Потребителят може да планира да използва софтуера, който все още не е създаден, въз основа на знанието, че може. Добрата постановка на проблема служи като основа за формиране на неговото решение.

Формулиране на проблема (програмна спецификация); по същество означава точно, пълно и разбираемо описание на това, което се случва, когато се изпълнява конкретна програма. Потребителят обикновено гледа на компютъра като на черна кутия: за него няма значение как работи компютърът, но е важно компютърът да може да прави това, от което се интересува потребителят. Фокусът е върху взаимодействието между човек и машина.

Характеристики на добрата постановка на проблема:

точност, т.е. изключване на всяка неяснота. Не трябва да има въпрос какъв ще бъде изходът на програмата за даден вход.

пълнота, т.е. разглеждане на всички опции за даден вход, включително погрешно или неочакван вход, и определяне на подходящия изход.

Яснота, т.е. трябва да е разбираемо както за потребителя, така и за системния анализатор, тъй като формулировката на проблема е единственият договормежду тях.

Често изискванията за точност, пълнота и яснота са в противоречие. По този начин много правни документи са трудни за разбиране, тъй като са написани на официален език, който ви позволява да формулирате определени разпоредби с най-голяма точност, изключвайки дори най-незначителните несъответствия. Например, някои въпроси в изпитните работи понякога са формулирани толкова точно, че студентът прекарва повече време за разбиране на въпроса, отколкото за отговор. Освен това ученикът може изобщо да не схване основния смисъл на въпроса поради Голям бройподробности. Най-добрата постановка на проблема е тази, която постига баланс на трите изисквания.

Стандартната форма на формулиране на проблема.

Помислете за следната формулировка на проблема: „Въведете три числа и изведете числата в ред“.

Такова твърдение не отговаря на горните изисквания: не е нито точно, нито пълно, нито разбираемо. Наистина, трябва ли числата да се въвеждат по едно на ред или всички числа на един ред? Изразът „по ред“ означава ли подреждане от най-голямо към най-малко, от най-малко към най-голямо или същия ред, в който са въведени.

Очевидно е, че подобно твърдение не отговаря на много въпроси. Ако вземем предвид отговорите на всички въпроси, тогава формулировката на проблема ще стане многословна и трудна за разбиране. Поради това Д. Райли предлага да се използва стандартната форма за поставяне на проблема, която осигурява максимална точност, пълнота, яснота и включва:

име на задачата (схематична дефиниция);

общо описание (кратко изложение на задачата);

грешки (необичайните опции за въвеждане са изрично изброени, за да покажат на потребителите и програмистите действията, които машината ще предприеме в такива ситуации);

пример (добър пример може да предаде същността на проблема, както и да илюстрира различни случаи).

Пример. Постановка на проблема в стандартен формуляр.

ЗАГЛАВИЕ

Сортирайте три цели числа.

ОПИСАНИЕ

Вход и изход на три цели числа, сортирани от най-малкото до най-голямото.

Въвеждат се три цели числа, по едно число на ред. В този случай цяло число е една или повече последователни десетични цифри, които могат да бъдат предшествани от знак плюс "+" или знак минус "-".

Трите въведени цели числа се извеждат, като и трите се показват на същия ред. Съседните числа са разделени с интервал. Числата се показват от най-малкото до най-голямото, отляво надясно.

1) Ако са въведени по-малко от три числа, програмата изчаква допълнително въвеждане.

У дома » Полезен » Спомагателните процеси на жизнения цикъл включват. Модели на жизнения цикъл на софтуера. Жизненият цикъл какво е това във формален смисъл