Сложни софтуерни интегрирани системи. Основни понятия.


Категория на документа: Информатика


Фиг.6. Повторно използване на съществуващите активи, чрез ориентирани към услуги архитектури

Непрекъснат фокус върху качеството

Предимства: По-високо качество и по-ранна представа за нивото на прогрес.

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

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

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

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

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

Фиг.7. Тестването започва рано и се разширява при всяка итерация

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

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

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

Основните предизвикателства, които стоят пред разработчиците на тези системи са:
> Промени и адаптация на всички нива - Софтуерните интензивни системи не са статични, и тяхната среда е непрестанно променяща се: за да се адаптирта към новите изисквания системите са обект на непрекъснати модификации, надстройки и конфигуриране. Тъй като те комуникират през глобална инфраструктура като интернет, тяхната среда непрекъснато се променя. Системите трябва да се адаптират към тези условия, като в същото време продължават да бъдат надеждни;
> Неотложен дизайн - не-механична нагласа. Ние вече няма да бъдем в състояние да приемаме "механично" отношение при разработването на софтуерни системи - нарастващата сложност и динамика на софтуерните интензивни системи ще ни принуди да създаваме системи, където само части от системите са под контрол на дизайнерите и където са необходими нови и различни абстракции; Моделиране на макро-равнище - в софтуерни системи, състоящи се от голям брой автономни и разпределени компоненти, вече няма да е възможно да се моделира и анализира поведението на системата по отношение на поведението на нейните компоненти. Вместо това ще бъде необходимо да се фокусираме върху поведението на системите на макро-ниво като цяло, например, по статистически методи;
> Качество и надеждност - традиционните приложения и системи, показват това, което можем да наречем точкова коректност: те са проектирани с точно определена представа за правилно поведение. Системите, които се адаптират към околната среда ще имат по-сложна дефиниция на точността. Правилното поведение при определени обстоятелства трябва да се избира в зависимост от редица минали, настоящи и бъдещи условия: адаптирането трябва да бъде процес коригиран както по отношение на историята на системата, така и към съответния момент;
> Инфраструктура от следващо поколение - софтуерът трябва да бъде в състояние да се развива, но все пак да остане съответстващ на целта на неговия създател. Това изисква софтуера да усети, възприеме и разбере каква е сегашната цел . Това изисква автоматична поддръжка за развитието на мрежовия софтуер, както и гъвкав протокол за този софтуер, който да се занимава с вътрешните, както и външни грешки. За тази цел ще трябва да се изгради автокаталитичен софтуер, който поддържа непрекъснато пренаписване и преход на кода, вместо системи в преходно състояние;
> Наука за софтуерните интензивни системи - тя трябва да предостави теория, методи и средства за осигуряване на софтуерната адаптивност. Това би трябвало да позволи предвидимост в присъствието на несигурност, характеризирана като разликата между средната и най-лошата стойност на поведение. Науката за СИС трябва също да осигури средства за справяне с отклонения от номиналното поведение, включително грешки, атаки и повреди в базовата физическа платформа;
> Нова форма на сложност - преди тридесет години, научната общност е изправена пред проблема за справяне с това, което наричаме физиологична сложност: софтуерни приложения, които са много сложни обекти, в смисъл, че те изискват сложно преплитане на части, за да се осигури решение на проблема. Предизвикателството, пред софтуерните интензивни системи не е толкова в разработването на "големи парчета на софтуер", а по-скоро това, което ние наричаме социална сложност - фактът, че от (дори и много простите) софтуерните приложения се изисква да присъединят в момента на изпълнение (т.е. динамично) съществуващите системи, в които те трябва да си взаимодействат с други лица, много често по начини, които не са били планирани и да се налага да разчитат на хетерогенни мрежи от физически разпределени и динамично променящи се места, свързани чрез често ненадеждни комуникационни инфраструктури;
> Автономни сензорни мрежи - повсеместната компютризация, комуникация и интелигентните потребителски интерфейси ще доведат до нови видове системи, например, автономни сензорни мрежи. Това са мрежи от безброй много малки, разпределени, автономни, повсеместни и невидими микрокомпютърни системи. Тези системи ще доведат до технически проблеми, като миниатюризация, енергийни доставки, както и безжични комуникации, а също и до софтуерни проблеми, като разпределени алгоритми, самоорганизация и мащабируемост на големи мрежи. Контрол, препрограмиране и централизация ще бъдат заменени с автономия и разпределено функциониране;
> Мулти-дисциплинарни методи за дизайн - основна характеристика на вградените системи и СИС като цяло, е нарастващия обем на софтуера, който контролира или си взаимодейства с механични устройства. Тъй като софтуерът не е субектит на физически ограничения, на механични или електрически устройства, използването на софтуер за контрол на системи създава почти неограничена сложност в компонентните взаимодействия. Софтуерните инженери нямат методи,за да се справят с ограниченията, наложени от това, което трябва да бъде мулти-дисциплинарен дизайн и процес на развитие. Предизвикателството е да изгради теория, методи и инструменти за разработка на софтуер, които гарантират, че екстрафункционалните изисквания за дадена платформа, са изпълнени.

Източници

1. Integration in software intensive systems, Victoria Stavridou, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.9146&rep=rep1&type=pdf
2. Software Engineering for Software-Intensive Systems:I Introduction, Assistant Professor Dr. Holger Giese, University of Paderborn, http://www2.cs.uni-paderborn.de/cs/ag-schaefer/Lehre/Lehrveranstaltungen/Vorlesungen/SoftwareEngineeringForSoftwareIntensiveSystems/WS0506/SEfSIS-I.pdf
3. Software System Integration, Software Engeneering Institute, Carnegie MellonUniversity, http://www.sei.cmu.edu/productlines/frame_report/softwareSI.htm
4. Analyzing the Actual Execution of a Large Software-Intensive System for Determining Dependencies, Trosky B. Callo Arias, Paris Avgeriou, Department of Mathematics and Computing Science, University of Groningen, http://www.cs.rug.nl/paris/papers/WCRE08.pdf
5. Defining Execution Viewpoints for a Large and Complex Software-Intensive System, Trosky B. Callo Arias,Pierre America and Paris Avgeriou, Department of Mathematics and Computing Science - University of Groningen http://www.cs.rug.nl/~paris/papers/WICSA09.pdf
6. ISO/IEC/IEEE 42010 Systems and software engineering, Wikipedia, http://en.wikipedia.org/wiki/ISO/IEC_42010
7. 42010-2011 - IEEE ISO/IEC/IEEE Systems and software engineering -- Architecture description, https://standards.ieee.org/findstds/standard/42010-2011.html
8. 42010-2011 - IEEE ISO/IEC/IEEE Systems and software engineering -- Architecture description, http://www.iso-architecture.org/ieee-1471/
9. 42010-2011 - IEEE ISO/IEC/IEEE Systems and software engineering -- Architecture description, https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:42010:ed-1:v1:en
10. Software Intensive Systems, Report, ftp://ftp.cordis.europa.eu/pub/ist/docs/fet/strat-6.pdf
11. The "4+1" View Model of Software Architecture, Philippe Kruchten, http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf
12. Institute for software integrated systems, http://www.isis.vanderbilt.edu/
13. Key principles for business-driven development, http://www.ibm.com/developerworks/rational/library/oct05/kroll/index.html




Сподели линка с приятел:





Яндекс.Метрика
Сложни софтуерни интегрирани системи. Основни понятия. 9 out of 10 based on 2 ratings. 2 user reviews.