ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.11.2023
Просмотров: 796
Скачиваний: 6
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Литература к главе 2
1. A configuration of the Rational Unified Process for System Engi- neering (RUP SE). http://www.cs.ut.ee/
kiho/TVTkonspekt/xTP165.pdf 2. IEEE_1471. http://en.wikipedia.org/wiki/IEEE_1471 3. McGovern J, Ambler
S, Stevens M, Linn J, Sharan V, and Jo E.
The Practical Guide to Enterprise Architecture. Prentice Hall, 2003 4. MDD. Общий обзор и концепция разработки, управляемой мо- делями. http://www.ibm.com/developerworks/ru/library/mdd/ch1/ch1.html#a uthor1 5. Object Management Group. http://en.wikipedia.org/wiki/Object_Management_Group
6. Software Engineering Institute, Carnegie Mellon. www.sei.cmu.edu/architecture/definitions/html
7. SWEBOK http://ru.wikipedia.org/wiki/SWEBOK.
8. Архитектура. http://ru.wikipedia.org/wiki/%C0%F0%F5%E8%F2%E5%EA%F2
%F3%F0%E0 9. Басс Л., Клементс П., Кацман Р. Архитектура программного обеспечения на практике. 2-е изд. – СПб.: Питер, 2006. – 575 с.
10. Брукс Ф. Мифический человеко-месяц или как создаются про- граммные системы. — Пер. с англ. – СПб.: Символ-Плюс, 2001.
– 304 с: ил.
11. Буч Г., Рамбо Д., Якобсон И. Язык UML, Руководство пользова- теля. 2-е изд. : Пер. с англ. мухин Н. – М.: ДМК Пресс, 2007. –
496 с.
12. Данилин
А.В., Слюсаренко А.И. Архитектура предприятия. http://www.intuit.ru/shop/ebooks/product.xhtml?id=2493646 13. Дейкстра Э. Дисциплина программирования. http://khpi- iip.mipk.kharkiv.edu/library/extent/dijkstra/pp/ewdx01.pdf.......
14. Илес П. Что такое архитектура программного обеспечения? http://www.ibm.com/developerworks/ru/library/eeles/
15. Крачтен
Ф. Введение в Rational Unified Process. 2-е издание.
Издательство: Диалектика, 2002. – 240 с.
16. Леоненков А. Объектно-ориентированный анализ и проектиро- вание с использованием UML и IBM Rational Rose. Изд. Ин- тернет-университет информационных технологий, Бином. Ла- боратория знаний, 2006. – 320 с.
17. Майерс Г. Надежность программного обеспечения: Пер. с англ.
– М .: Мир, 1980. – 360 с.
18. Михайловский Н. Архитектура информационной системы, оценка рисков и совокупная стоимость владения. http://kacit.ru/assets/files/soa/is_arc.pdf
81 19. Назаров С.В., Широков И.А. Современные операционные сис- темы. М.: Интернет-университет Информационных технологий,
БИНОМ. Лаборатория знаний, 2010. 279 с.
20. Сервис-ориентированная архитектура. http://ru.wikipedia.org/wiki/%D1%E5%F0%E2%E8%F1 21. Соснин П.И. Архитектурное моделирование систем, интенсив- но использующих программное обеспечение. http://www.ict.edu.ru/ft/005651/62328e1-st15.pdf
22. Турский В. Методология программирования: пер. с англ. – М .:
Мир, 1981. – 264 с.
23. Фейгин Д. Концепция SOA. "Открытые системы", №6, 2004 24. Цикритзис Д.. Бернстайн Ф. Операционные системы. Пер с англ. М.: Мир, 1977 25. Чернышов Л.Н. Эволюция программных систем: от модульной до сервис-ориентированной. Материалы конференции по вы- числительной механике и современным прикладным программ- ным системам (ВМСППС), Алушта, Крым, 2005, –
М.:Вузовская книга, 2005.
82
Глава 3
ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНЫХ СИСТЕМ
3.1. Понятие жизненного цикла программных систем
Понятие жизненного цикла программных систем (ЖЦ ПС) является одним из базовых в программной инженерии. ЖЦ ПС определяется как период времени, который начинается с момента принятия решения о необходимости создания ПС и закачивается в момент ее полного изъя- тия из эксплуатации. Основным нормативным документом, регламенти- рующим состав процессов ЖЦ ПС, является международный стандарт
ISO/IEC 12207: 1995 “Information Technology – Software Life Cycle Pro- cess” (ISO – International Organization for Standardization – Международ- ная организация по стандартизации, IEC – International Electrotechnical
Commission – Международная комиссия по электротехнике) [3]. Этот стандарт определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены в процессе создания и даль- нейшего использования ПС.
В данном стандарте ПС (или программный продукт) определяется как набор компьютерных программ, процедур и, возможно, связанной с ними документацией и данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные (Г. Майерс называет это трансляцией данных [20]). Каждый процесс характеризуется определенными задачами и методами их ре- шения. В свою очередь, каждый процесс разделен на набор действий, а каждое действие – на набор задач. Каждый процесс, действие или зада- ча инициируется и выполняется другим процессом по мере необходи- мости, причем не существует заранее определенных последовательно- стей выполнения (естественно, при сохранении связей по входным дан- ным).
Следует отметить, что в бывшем Советском Союзе, а затем в России создание программного обеспечения (ПО) первоначально, в 70-е годы прошлого столетия, регламентировалось стандартами ГОСТ ЕСПД
(Единой системы программной документации – серии ГОСТ 19.ХХХ
[13]), которые были ориентированы на класс относительно простых программ небольшого объема, создаваемых отдельными программиста- ми. В настоящее время эти стандарты устарели концептуально и по форме, их сроки действия можно считать законченными и их использо- вание нецелесообразно.
Процессы создания автоматизированных систем (АС), в состав кото- рых входит и ПО, регламентированы стандартами ГОСТ 34.601-90
”Информационная технология. Комплекс стандартов на автоматизиро- ванные системы. Стадии создания”, ГОСТ 34.602-89 “Информационная технология. Комплекс стандартов на автоматизированные системы.
Техническое задание на создание автоматизированной системы” и
ГОСТ 34.603-92 “Информационная технология. Виды испытаний авто-
83 матизированных систем” [14]. Однако многие положения этих стандар- тов устарели, а другие отражены недостаточно, чтобы их можно было использовать для серьезных проектов создания ПС. Поэтому в отечест- венных разработках целесообразно использовать современные между- народные стандарты.
В соответствии со стандартом ISO/IEC 12207 [2,7] все процессы ЖЦ
ПО разделены на три группы (рис. 3.1).
Рис. 3.1. Процессы ЖЦ ПО
В группах определено пять основных процессов: приобретение, по-
ставка, разработка, эксплуатация и сопровождение. Восемь вспомога- тельных процессов обеспечивают выполнение основных процессов, а именно документирование, управление конфигурацией, обеспечение ка-
чества, верификация, аттестация, совместная оценка, аудит, разре-
шение проблем. Четыре организационных процесса обеспечивают
управление, создание инфраструктуры, усовершенствование и обуче-
ние.
3.2. Основные процессы ЖЦ ПС
3.2.1. Процесс приобретения состоит из действий и задач заказчика, приобретающего ПС. Данный процесс охватывает следующие действия:
1) инициирование приобретения;
2) подготовку заявочных предложений;
3) подготовку и корректировку договора;
4) надзор за деятельностью поставщика;
5) приемку и завершение работ.
Инициирование приобретения включает следующие задачи:
84 1) определение заказчиком своих потребностей в приобретении, разра- ботке или усовершенствовании системы, программных продуктов или услуг;
2) анализ требований, предъявляемых к системе;
3) принятие решения относительно приобретения, разработки или усо- вершенствования существующей ПС;
4) проверку наличия необходимой документации, гарантий, сертифика- тов, лицензий и поддержки в случае приобретения программного продукта;
5) подготовку и утверждение плана приобретения, включающего тре- бования к системе, тип договора, ответственность сторон и т.д.
Заявочные предложения должны содержать:
1) требования, предъявляемые к системе;
2) перечень программных продуктов;
3) условия приобретения и соглашения;
4) технические ограничения (например, по среде функционирования системы).
Заявочные предложения направляются к выбранному поставщику или нескольким поставщикам в случае тендера. Поставщик – это орга- низация, которая заключает договор с заказчиком на поставку системы,
ПС или программной услуги на условиях, оговоренных в договоре.
Подготовка и корректировка договора включает следующие задачи:
1) определение заказчиком процедуры выбора поставщика, включаю- щей критерии оценки предложений возможных поставщиков;
2) выбор конкретного поставщика на основе анализа предложений;
3) подготовку и заключение договора с поставщиком;
4) внесение изменений (при необходимости) в договор в процессе его выполнения.
Надзор за деятельностью поставщика осуществляется в соответствии с действиями, предусмотренными в процессах совместной оценки и ау- дита. В процессе приемки подготавливаются и выполняются необходи- мые тесты. Завершение работ по договору осуществляется в случае удовлетворения всех условий приемки.
3.2.2. Процесс поставки охватывает действия и задачи, выполняемые поставщиком, который снабжает заказчика программным продуктом или услугой. Данный процесс включает следующие действия:
1) инициирование поставки;
2) подготовку ответа на заявочные предложения;
3) подготовку договора;
4) планирование работ по договору;
5) выполнение и контроль договорных работ и их оценку;
6) поставку и завершение работ.
Инициирование поставки заключается в рассмотрении поставщиком заявочных предложений и принятии решения о согласии с выставлен- ными требованиями и условиями или предложение своих условий. Воз- можно также согласование предложений поставщика и заказчика.
Планирование включает следующие задачи:
85 1) принятие решения поставщиком относительно выполнения работ своими силами или с привлечением субподрядчика;
2) разработку поставщиком плана управления проектом, содержащего организационную структуру проекта, разграничение ответственно- сти, технические требования к среде разработки и ресурсам, управ- ление субподрядчиками и др.
3.2.3. Процесс разработки предусматривает действия и задачи, вы- полняемые разработчиком, и охватывает работы по созданию ПС и ее компонентов в соответствии с заданными требованиями. Сюда включа- ется оформление проектной и эксплуатационной документации, подго- товка материалов, необходимых для проверки работоспособности и ка- чества программных продуктов, материалов, необходимых для органи- зации обучения персонала и др.
Процесс разработки включает следующие действия:
1) подготовительную работу;
2) анализ требований, предъявляемых к системе;
3) проектирование архитектуры системы;
4) анализ требований, предъявляемых к программной системе;
5) проектирование архитектуры программной системы;
6) детальное проектирование программной системы;
7) кодирование и тестирование программной системы;
8) интеграцию программной системы;
9) квалификационное тестирование программной системы;
10) интеграцию системы;
11) квалификационное тестирование системы;
12) установку программной системы;
13) приемку программной системы.
Подготовительная работа начинается с выбора модели ЖЦ ПС, со- ответствующей масштабу, значимости и сложности проекта. Действия и задачи процесса разработки должны соответствовать выбранной моде- ли. Разработчик должен выбирать, адаптировать к условиям проекта и использовать согласованные с заказчиком стандарты, методы и средства разработки, а также составить план выполнения работ.
Анализ требований, предъявляемых к системе, подразумевает опре- деление ее функциональных возможностей, пользовательских требова- ний, требований к надежности, безопасности, требований к внешним интерфейсам, производительности и т.д. Требования к системе оцени- ваются, исходя из критериев реализуемости и возможности проверки при тестировании.
Проектирование архитектуры системы заключается в определении компонентов ее оборудования (аппаратуры), программного обеспечения и операций, выполняемых эксплуатирующим систему персоналом. Ар- хитектура системы должна соответствовать требованиям, предъявляе- мым к системе, а также принятым проектным стандартам и методам.
Анализ требований к программной системе предполагает определе- нии следующих характеристик для каждого компонента ПО:
86 1) функциональных возможностей, включая характеристики произво- дительности и среды функционирования компонента;
2) внешних интерфейсов;
3) спецификаций надежности и безопасности;
4) эргономических требований;
5) требований к используемым данным;
6) требований к установке и приемке;
7) требований к пользовательской документации;
8) требований к эксплуатации и сопровождению.
Требования к программной системе оцениваются, исходя из крите- риев соответствия требованиям, предъявляемым к системе в целом, реа- лизуемости и возможности проверки при тестировании.
Проектирование архитектуры ПС включает следующие задачи для каждого компонента ПС:
1) трансформацию требований к ПС в архитектуру, определяющую на высоком уровне структуру ПС и состав ее компонентов;
2) разработку и документирование программных интерфейсов ПС и баз данных (БД);
3) разработку предварительной версии пользовательской документа- ции;
4) разработку и документирование предварительных требований к тес- там и плана интеграции ПС.
Детальное проектирование ПС включает следующие задачи:
1) описание компонентов ПС и интерфейсов между ними на более низ- ком уровне, достаточном для последующего кодирования и тестиро- вания;
2) разработку документирование детального проекта базы данных;
3) обновление (при необходимости) пользовательской документации;
4) разработку и документирование требований к тестам и плана тести- рования компонентов ПС;
5) обновление плана интеграции ПС.
Кодирование и тестирование ПС включает следующие задачи:
1) кодирование и документирование каждого компонента ПС и базы данных, а также подготовку совокупности тестовых процедур и дан- ных для их тестирования;
2) тестирование каждого компонента ПС и БД на соответствие предъ- являемым к ним требованиям с последующим документированием результатов тестирования;
3) обновление документации (при необходимости);
4) обновление плана интеграции ПС.
Интеграция ПС предусматривает сборку разработанных компонен- тов ПС в соответствии с планом интеграции и тестирования агрегиро- ванных компонентов. Для каждого из агрегированных компонентов раз- рабатываются наборы тестов и тестовые процедуры, предназначенные для проверки каждого из квалификационных требований при после- дующем квалификационном тестировании. Квалификационное требо- вание – это набор критериев или условий, которые необходимо выпол-