ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 06.11.2023

Просмотров: 811

Скачиваний: 6

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Литература к главе 6
1.
Henry, S. and Kafura, D. Software Structure Metrics Based on In- formation Flow. IEEE Transactions on Software Engineering, vol. 7, No. 5, pp. 510-518, Sept. 1981.
2.
McCabe, T. J. A Complexity Measure. IEEE Transactions on Soft- ware Engineering, vol. 2: pp. 308-320. No.4, Apr 1976.
3.
Page-Jones, M. The Practical Guide to Structured Systems Design.
Englewood Cliffs, NY: Yourdon Press, 1988.
4.
Parnas, D. On the Criteria to the Be Used in Decomposing Systems into Modules. Communications of the ACM vol. 15 (12), December, 1972, pp. 1053-1058.
5.
Yourdon, E., and Constantine, L. Structured Design: fundamentals of a discipline of computer program and systems design. Englewood Cliffs,
NJ: Prentice-Hall, 1979.
6.
Баманн П., Френцель М., Ханцшман К. и др. Программные сис- темы: Пер. с нем./Под ред. Бахманна. – М.: Мир, 1988. – 288 с.
7.
Басс Л., Клементс П., Кацман Р. Архитектура программного обеспечения на практике. 2-е изд. – СПб.: Питер, 2006. – 575 с.
8.
Буч Г., Рамбо Д., Якобсон И. Язык UML, Руководство пользова- теля. 2-е изд. : Пер. с англ. мухин Н. – М.: ДМК Пресс, 2007. – 496 с.
9.
Вирт Н. Алгоритмы и структуры данных. Пер. с англ. – М.:
Мир, 1989. – 358 с.
10. Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разра- ботки программного обеспечения: учебное пособие / под ред. Л.Г. Гага- риной. – М.: ИД «ФОРУМ»: ИНФРА-М., 2008. – 400 с.
11. Грегор
Дж.
Программная архитектура. http://ooad.asf.ru/standarts/Library/Architecture/index.aspx
12. Дейкстра Э.В. Дисциплина программирования. Пер. с англ.
В.В.Мартынюк, И.X. Зусман, Л.В.Ухов – М.: Мир, 1978 13. Зелковец М., Шоу А., Гэннон Дж. Принципы разработки про- граммного обеспечения: Пер. с англ. – М.: Мир. 1982 – 368 с.
14. Зиглер К.. Методы проектирования программных систем: Пер. с англ. – М .: Мир, 1985. – 328 с.
15. Кватрани Т., Палистрает Д. Визуальное моделирование с помо- щью IBM Rational Software Architect и UML. Пер. с англ. – М.: КУДИЦ-
ПРЕСС. – 2007. – 192 с.
16. Киммел П. UML. Основы визуального анализа и проектирова- ния = UML. Универсальный язык программирования / Пол Киммел; пер. с англ. Кедрова Е.А. – М. : НТ Пресс, 2008. – 272 с.
17. Крылов Е.В., Острейковский В.А., Типикин Н.Г. Техника раз- работки программ: в 2 кн. Кн. 2. Технология, надежность и качество программного обеспечения. – М.: Высшая шк., 2008. – 469 с.
18. Кулямин В. В. Технологии программирования. Компонентный подход. [Электронный ресурс]. Режим доступа: http://lib.mdpu.org.ua/e- book/vstup/L/Jogolev.pdf

303 19. Лисков Б.. Гатэг Дж. Использование абстракций и специфика- ций при разработке программ: Пер. с англ. – М.: Мир, 1989. – 424 с.
20. Майерс Г. Надежность программного обеспечения: пер. с англ.
– М.: Мир, 1980. – 360 с.
21. Макконнел С. Профессиональная разработка программного обеспечения. – Пер. с англ. – СПб.: Символ-Плюс, 2006. – 240 с.
22. Мартин Р., Ньюкирк Дж., Косс Р. Быстрая разработка про- грамм: принципы, примеры, практика. Вильямс, 2004. – 752 с.
23. Модели реализации объектно-ориентированных программных систем - Связность объектов. http://2programmer.ru/tehnolog5?start=16 24. Назаров С.В. Операционные системы специализированных вы- числительных комплексов: теория построения и системного проектиро- вания. – М.: Машиностроение, 1989. – 400 с.
25. Назаров С.В. Сложность программной системы. Сборник науч- ных трудов по материалам международной научно-практической кон- ференции «Современные направления теоретических и прикладных ис- следований ‘2011», том 2 Технические науки. – Одесса: Черноморье,
2011. с. 58 – 65 26. Назаров С.В. Формальное описание методики разработки мо- дульной архитектуры программной системы. В кн.: Сборник научных трудов по материалам международной научно-практической конферен- ции ПЕРСПЕКТИВНЫЕ ИННОВАЦИИ В НАУКЕ, ОБРАЗОВАНИИ,
ПРОИЗВОДСТВЕ И ТРАНСПОРТЕ '2011. Одесса: Черноморье, 2011.
Т. 5. C. 3—11 27. Нильссон Дж. Применение DDD и шаблонов проектирования.
Проблемно-ориентированное проектирование приложений с примерами на C# и .NET. Издательство: Вильямс. 2008. – 560 с.
28. Новичков А. Метрики кода и их практическая реализация в IBM
Rational ClearCase http://anovichkov.msk.ru/?p=13 29. Новичков А. Метрики кода. http://anovichkov.msk.ru/?p=1196 30. Орлов С.А. Технологии разработки программного обеспечения:
Учебник/ С. Орлов. – СПб.: Питер, 2002 – 464 с.: ил.
31. Полис Г., Огастин Л., Лоу К., Мадхар Д. Разработка программ- ных проектов на основе Rational Unnified Process (RUP). – М.: ООО
«Бином-Пресс», 2009. – 256 с.
32. Программные системы: Пер. с нем./ Под ред. П. Захманна. – М.:
Мир. – 1988. – 288 с.
33. Разработка спецификаций. Средства специфицирования ПО. http://www.cs.nuos.edu.ua/textbooks/SWDevelop/SaprSW1/page5.htm
34. Савчук И. Почему объектно-ориентированное программирова- ние провалилось? http://blogerator.ru/page/oop_why-objects-have-failed
35. Таненбаум Э. Современные операционные системы. Изд-е 4.
СПб., Питер, 2011. – 1120 с.
36. Тассел В. Стиль, разработка, эффективность, отладка и испыта- ние программ: Пер. с англ. – М.: Мир. 1985 – 332 с.
37. Турский В. Методология программирования: пер. с англ. – М .:
Мир, 1981. – 264 с.


304 38. Фанг Дж. Введение в IBM Rational Application Developer, учеб- ное руководство. Пер. с англ. – М.: КУДИЦ-ПРЕСС. – 2006. – 592 с.
39. Холстед М. X. Начала науки о программах / Пер. с англ В. М.
Юфы. — М: Финансы и статистика, 1981. – 128 с,
40. Хьюз Дж., Мичтом ДЖ. Структурный подход к программиро- ванию: Пер. с англ. – М .: Мир, 1980. – 280 с.
41. Цикритзис Д.. Бернстайн Ф. Операционные системы. Пер с англ. М.: Мир, 1977

305
Глава 7
ТЕХНИКО-ЭКОНОМИЧЕСКИЙ АНАЛИЗ ПРОЕКТОВ
ПРОГРАММНЫХ СИСТЕМ
7.1. Технико-экономический анализ при планировании жизнен-
ного цикла программных систем
В фундаментальной монографии Липаева В.В. [12], посвященной вопросам технико-экономического обоснования проектов сложных про- граммных средств, отмечается, что целью разработки программных сис- тем является создание программной системы заданного качества в усло- виях ограниченных ресурсов. Для достижения этой цели используются современные технологии и средства автоматизации разработки ПС раз- личных классов. В процессе разработки выделяются и реализуются ча- стные подцели, которые способствуют достижению основной цели раз- работки ПС.
Обеспечение ЖЦ любых изделий (продуктов) требует определенных затрат ресурсов, причем их тем больше, чем выше качество этого изде- лия. Многие проекты программных систем потерпели неудачу из-за от- сутствия у разработчиков и заказчиков правильного представления о финансовых, трудовых, временных и иных ресурсах, необходимых для реализации проекта. Существенными факторами, влияющими на трудо- емкость, длительность реализации и качество ПС, являются ограниче- ния ресурсов, доступных для обеспечения их жизненного цикла, а также возможная эффективность их использования. Поэтому одной из основ- ных задач обеспечения ЖЦ ПС является технико-экономический анализ и обоснование необходимых ресурсов для создания ПС в соответствии с требованиями контракта.
При планировании ЖЦ ПС часто имеется определенный заказчик- потребитель, который способен задать основные цели, характеристики программного продукта и обеспечить ресурсы для реализации проекта.
Однако часто инициатором разработки является разработчик-поставщик
ПС, который самостоятельно принимает решения о проектировании за счет собственных ресурсов и предполагает возместить затраты путем реализации программного продукта на рынке. Сюда относятся крупные компании, производящие системное программное обеспечение: опера- ционные системы, СУБД, системы программирования, различные инст- рументальные средства и т.п.
Таким образом, при технико-экономическом анализе и обосновании проектов ПС возможны два сценария. По первому сценарию создание и весь жизненный цикл программной системы ориентируется на массовое тиражирование и распространение их на рынке среди неизвестных пользователей в различных сферах и внешней среде применения. При этом отсутствует конкретный внешний потребитель-заказчик, который определяет требования к ПС и финансирует ее разработку. По второму сценарию разработка проекта ПС предполагается для конкретного по-


306 требителя-заказчика с определенным, относительно небольшим (иногда единичным) тиражом и с известной областью и внешней средой приме- нения.
Заметим, что эти сценарии принципиально различаются методами технико-экономического анализа и обоснования их характеристик. Пер- вый сценарий базируется на маркетинговых исследованиях рынка про- граммных продуктов и стремлении поставщика занять на рынке выгод- ное место. Для этого поставщику необходимо определить на рынке всю гамму близких по назначению и функциям ПС, оценить их эффектив- ность, стоимость и применимость, а также возможную конкурентоспо- собность предполагаемого к разработке программного продукта для потенциальных пользователей и их возможное число (вспомним MS
DOS!).
В этом сценарии создания программного продукта следует оценить рентабельность затрат на обеспечение всего жизненного цикла ПС, вы- явить факторы, функциональные, экономические и конструктивные по- казатели качества, которые способны привлечь достаточное число по- купателей и оправдать затраты на предстоящую разработку. Для этого разработчикам необходимо произвести оценку возможной конкуренто- способности предполагаемой продукции на рынке, как правило, по кри- терию отношения эффективность-стоимость.
При выборе поставщика и продукции покупатель стремится макси- мизировать это соотношение как за счет выбора ПС с максимальной эффективностью и качеством, так и за счет минимальной стоимости покупаемого продукта. В этом сценарии при организации проектирова- ния вся ответственность за цели, функции и показатели качества проек- та ложатся на его руководителей. Ответственную роль должны играть специалисты по маркетинговому анализу предполагаемому распростра- нению продукта на рынке. Они должны определить конъюнктуру и риск успешного продвижения продукта на рынок, сроки и график выполне- ния этапов жизненного цикла, достаточность ресурсов для реализации проекта и перспективы экономической эффективности, длительного развития, модификаций и распространения версий ПС.
Второй сценарий предполагает наличие определенного заказчика- потребителя конкретного проекта программной системы, который опре- деляет основные технические и экономические требования. Он выбира- ет конкурентоспособного поставщика-разработчика, которого оценива- ет на возможность реализовать проект с необходимым качеством с уче- том ограничения требуемых бюджета, сроков и других ресурсов. При этом результаты разработки не обязательно подлежат широкому тира- жированию, могут не поступать на рынок, маркетинговые исследования для таких проектов являются второстепенными и предварительно могут не проводиться. Однако для заказчика и разработчика при заключении контракта необходимо достаточно достоверное прогнозирование требо- ваний к программному продукту и технико-экономическое обоснова- ние требуемых ресурсов по трудоемкости, стоимости, срокам и другим показателям. Заказчик заинтересован в получении ПС высокого качест-


307 ва при минимальных затратах, а разработчик желает получить макси- мальную плату за созданный продукт и достаточные ресурсы на его реализацию.
Противоположность интересов поставщика и потребителя при оцен- ке стоимости и других ресурсов проекта, требует поиска компромисса, при котором заказчик не переплатит за конкретное выполнение работ и весь проект, а разработчик не продешевит, выполняя эти работы (см. раздел 7.5 данной главы). Поэтому оба партнера заинтересованы в дос- товерном технико-экономическом прогнозировании и обосновании про- екта ПС. При технико-экономическом анализе и обосновании процесса разработки и всего жизненного цикла ПС автор монографии [12] реко- мендует учитывать следующие цели.
Первая цель состоит в прогнозировании реальных затрат на разра-
ботку определенного проекта компонентов и ПС в целом с учетом их сложности и требуемого качества. Для этого должна быть изучена су- ществующая практика разработки программных систем и/или обобще- ны технико-экономические показатели (ТЭП) современных проектов
ПС. Такие обобщения должны выявить трудоемкость (стоимость) и производительность труда при разработке программ определенных классов и назначения, а также основные факторы, влияющие на эти по- казатели при создании конкретных программных систем. Кроме того, необходимо определить длительность всего процесса разработки про- грамм и отдельных его этапов. Для этого должны быть разработаны и внедрены методики сбора первичных технико-экономических данных и их обработки по завершенным или находящимся в процессе разработки проектам ПС. В результате могут быть получены современные значения основных ТЭП создания программных систем разных классов.
Вторая цель – создание методов и методик прогнозирования за-
трат и длительности создания программных систем. Методики долж- ны учитывать полученные значения ТЭП, основные характеристики создаваемых ПС, а также технологию, оснащенность и организацию их разработки. Получаемые прогнозы позволят эффективно планировать разработки, управлять созданием ПС и осуществлять их проекты в со- ответствии с заданными требованиями, сроками и затратами на основе анализа аналогов-прототипов.
Третьей целью анализа является обоснование и создание методов и
средств снижения совокупных затрат и сроков разработки сложных
программных систем. При этом возникают следующие задачи: эффективное распределение общих трудовых ресурсов, используе- мых при разработке ПС; развитие и повышение экономической эффективности технологий, применяемых для создания программных систем различных классов; рациональное повышение уровня комплексной автоматизации раз- работки ПС; выбор методов и инструментальных средств, в наибольшей степени способствующих снижению длительности создания и совокупных затрат на ПС, а также повышению их качества.


308
Четвертой целью технико-экономического исследования процессов
разработки ПС является создание методических и нормативных доку-
ментов, как основы промышленной разработки аналогичных про- граммных продуктов. Наличие таких нормативных документов может коренным образом изменить характер разработки ПС и приблизить его к отрасли современного регламентированного промышленного проек- тирования. В результате появится возможность управления затратами на разработку, количеством и качеством создаваемых ПС и их компо- нентов на различных этапах проекта.
В качестве основного критерия эффективности новой техники и ПС, в частности широко применяется критерий экономии совокупных за- трат общественного труда [12], которая получается в результате внедре- ния этой техники. Однако во многих случаях созданная техника способ- ствует повышению качества изделий или является принципиально но- вой продукцией, что затрудняет ее оценку по критерию непосредствен- ной экономической эффективности. Поэтому широко применяется кри- терий минимальных приведенных затрат, которые требуются при созда- нии и эксплуатации анализируемых изделий. Приведенные затраты включают затраты на проектирование, эксплуатацию изделий по всему жизненному циклу или пересчитанные к годовому интервалу времени.
Во многих случаях эффективность новой техники и ПС в процессе проектирования приходится прогнозировать в условиях неопределен- ности целей, различных факторов и характеристик. Обычно недостаточ- но известны перспективы внедрения и эксплуатации объектов разработ- ки – новых программных продуктов. Трудно формализуемыми и оцени- ваемыми являются размеры (масштабы) и структура систем, взаимодей- ствие основных подсистем, цели, функции и критерии оценки эффек- тивности их функционирования. Значительные неопределенности со- держатся в технико-экономических характеристиках технологий, а так- же инструментальных средств автоматизации проектирования и изго- товления ПС. В результате экономический анализ и прогнозы могут иметь значительный разброс оцениваемых показателей.
Программно-целевое планирование и промышленная разработка ПС как продукции, по мнению автора монографии [12], целесообразны только для определенных классов ПС. Таких классов предлагается три.
К первому классу относятся программы автоматизированного или авто- матического управления, встроенные в системы управления жесткого реального времени. Второй класс представляется информационно- справочными системами организационного и административного управления, которые функционируют вне жесткого реального времени.
Сюда также отнесены системы автоматизации проектирования. К треть- ему классу относятся ПС решения научно-исследовательских и инже- нерных задач.
Здесь почему-то забыт четвертый широкий класс ПС, относящийся к системному программному обеспечению. Это наиболее сложные и крупные программные системы, к которым относятся операционные системы, системы управления базами данных, языки и системы про-