ОПИ-2. Министерство науки и образования рф
 Скачать 1.52 Mb.
|
|
Рис.3 Для учета влияния на С различных факторов удобно пользоваться коэффициентами (рейтингами) изменения трудоемкости (КИТ) - M(i, j), учитывающими зависимость j-го фактора от i-й составляющей совокупных затрат. В них входят факторы процесса непосредственной разработки, факторы программной и аппаратурной оснащенности, а также квалификация специалистов. Непосредственно затраты на разработку можно представить как частное от размера ПС и производительности труда Р = 1 / А, корректи- руемой произведением коэффициентов изменения трудоемкости (КИТ - М (i, j) ): П Е C= х ПM(i, j) = A х ПЕ х ПМ(i, j) (2) Р i,j i,j Длительность разработки программных средств является важнейшим технико-экономическим показателем, поскольку часто она определяет общие сроки разработки систем, а значит, быстроту реализации идей в различных областях автоматизации. В таблице 3 за начало разработки ПС принят момент начала создания технического задания (Т3), а за окончание — завершение испытаний программного продукта в целом или момент предъявления его на испытания. Таблица 3 Коэффициенты моделей для оценки трудоемкости разработки программных средств Коэффициент Коэффициент Модель и тип G Н программных средств 2,5 0,38 Базовая - КОМОСТ Детализированная модель СОСОМО: 2,5 0,32 - встроенный; 2,5 0,35 - полунезависимый; 2,5 0,38 - независимый. СССОМО 11.2000 3,67 0,328 Крупный проект 100 KSLOC ПРОМЕТЕЙ 3,51 0,31 Системы реального времени; 3,78 0,28 Информационно-поисковые системы. Диапазону размеров современных ПС в три-четыре порядка (до 10 млн. строк) соответствуют приблизительно такие же диапазоны изменения трудоемкостей и стоимостей их разработок. Однако, очевидна принципиальная нерентабельность разработки даже очень сложных ПС более 5 лет. С другой стороны, программы даже в несколько тысяч строк по полному технологическому циклу с испытаниями как продукции редко создаются за время, меньшее, чем полгода-год. Таким образом, вариация длительностей разработок ПС много меньше, чем вариация их трудоемкостей, и не превышает десятикратный диапазон. Длительности разработок Т ограничены сверху и снизу, и одним из основных факторов, определяющих эти границы, является объем программ – П. Относительный «консерватизм» значений длительностей по сравнению с трудоемкостью определяется объективной необходимостью создавать ПС в рациональные сроки. Любые ПС должны поступать на эксплуатацию до того, как в них пропадает необходимость. Их цели, концептуальная основа и алгоритмы не должны устареть за время разработки. Отсюда появляется верхний предел допустимых длительностей разработки. Этот верхний предел не может иметь единственное значение для любых классов и объемов ПС. Однако недопустима его вариация в том же диапазоне, что и размер. Поэтому на практике по мере возрастания размеров ПС увеличиваются коллективы специалистов-разработчиков, что обеспечивает основной прирост необходимой трудоемкости. Чем крупнее создаваемое ПС, тем большие усилия обычно прилагаются для автоматизации и совершенствования технологии разработки. Это также способствует замедлению роста длительностей разработки, однако по мере увеличения сложности программ, длительность их разработки все же заметно возрастает. Стремление ограничивать длительность реальных разработок ПС приводит к объективному формированию верхнего предела, за которым распространяется зона «нерациональных» длительностей, зависящих от размера и трудоемкости ПС. Даже для довольно сложных ПС, имеющих размер свыше 500 тыс. строк, вряд ли допустима длительность разработки более 3-5 лет. Большие длительности, иногда имеющиеся на практике, обусловлены в основном низкой квалификацией разработчиков и заказчиков, недостаточной автоматизацией технологии, малым коллективом специалистов и рядом других, преимущественно организационных и технологических причин. Подобные ситуации чаще встречаются при относительно небольших разработках (10 - 50 тыс. строк), когда у руководителей и коллектива мал опыт их проведения, следствием чего является избыточный оптимизм в начале разработки, а также пренебрежение технологией и организацией работ. Границу снизу определяют естественный технологический процесс коллективной разработки и необходимость выполнения ряда взаимоувязанных работ на последовательных этапах, которые обеспечивают получение ПС требуемого качества. Подготовка текстов программ, их тестирование, комплексирование, документирование и испытания могут проводиться только последовательно, и каждый этап требует определенного времени. Попытки форсировать отдельные этапы работ, как правило, приводят к увеличению продолжительности других этапов. Подключение дополнительных специалистов увеличивает затраты на разработку и только в некоторых пределах дает сокращение сроков. В некоторых случаях увеличение числа специалистов может давать обратный эффект - длительность разработки увеличивается вместе с увеличением затрат. Под воздействием перечисленных факторов формируется объективный минимум длительностей - граница снизу области «невозможного», зависящая в первую очередь от объема, разрабатываемых ПС. Нижняя граница длительностей еще более «консервативна», чем верхняя. Изменение этой границы возможно в небольших пределах только за счет совершенствования технологии, повышения программной и аппаратурной оснащенности разработки, а также роста коллективной квалификации разработчиков и заказчиков. Практическая граница «нерациональных» длительностей имеет значения, приблизительно вдвое большие, чем значения границы «невозможных» длительностей, при том же объеме ПС. Это означает, что даже большие усилия по автоматизации и организации разработки программ приводят к сокращению длительностей только в 2 - 3 раза, в то время как трудоемкость уменьшается значительно больше. По результатам реальных разработок может быть оценена средняя или наиболее вероятная длительность разработок ПС определенного класса при заданных условиях. Конкретное распределение длительностей зависит от исходных данных, имеющихся в базе данных технико-экономических показателей завершенных разработок, и от метода их усреднения. Для конкретного планирования длительностей создания ПС определенных классов необходимо для каждого предприятия исследовать и обобщать технико-экономические показатели реальных разработок, однородных по технологии и другим условиям. Такие обобщения при конкретных условиях разработок позволяют получить опорные абсолютные значения длительностей для некоторых размеров ПС. Эти абсолютные значения могут быть использованы для расчета коэффициентов регрессии с целью прогнозирования длительностей разработок на базе выявленных закономерностей и реальных опорных значений для конкретных условий разработки. Обобщенные данные длительности разработки Т по классам программ в ряде работ аппроксимировались уравнениями регрессии по методу наименьших квадратов в зависимости от размера ПС и от трудоемкости их разработки (таблица 2): T = G x C Н . (3) Зависимости Т от размера программ П значительно различаются для классов ПС. Это определяется различием сложности классов программ, применяемых языков программирования и единиц измерения объема ПС, следствием чего является различие значений размера созданных программ при одной и той же длительности и трудоемкости разработки. Чтобы исключить ошибки, связанные с неопределенностью измерения размера программ, исследована зависимость длительности разработки от ее трудоемкости. Учитывалась только трудоемкость непосредственной разработки программ С без затрат на средства автоматизации разработки. Обработка тех же, что выше, наборов данных позволила получить коэффициенты уравнения регрессии представленные в таблице 2. Средние значения длительности разработки классов ПС практически не различаются в зависимости от трудоемкости разработки программ. Оценка требуемого среднего числа специалистов для конкретного проекта ПС предварительно может быть рассчитана путем деления оценки величины трудоемкости разработки (2) на длительность разработки (3). Однако рациональное число специалистов, участвующих в проекте ПС распределяется не равномерно по этапам работ. Поэтому целесообразно определять число и квалификацию необходимых специалистов с учетом этапов разработки комплексов программ. Средняя производительность труда коллектива специалистов при разработке сложного полностью нового комплекса программ Р в выражении (2) может служить ориентиром для сравнения эффективности труда при создании различных проектов ПС. Эта характеристика, конечно, различается для различных классов, размеров и других параметров комплексов программ, однако диапазон этих различий не столь велик как изменения размера, требований к качеству и других параметров. Так при диапазоне изменения размеров программ СРВ на четыре порядка средняя производительность труда изменяется только в два раза, что в ряде случаев существенно облегчает упрощенные оценки и прогнозирование ТЭП. При разработке программных модулей и компонентов отдельными специалистами или небольшими группами производительность труда при написании одних и тех же текстов автономных программ может различаться в десяток раз в зависимости от их таланта и трудоспособности и достигать тысяч строк за человеко-месяц. Однако достаточно полное тестирование, документирование, комплексирование и оформление в крупные комплексы программного продукта, приводят к снижению интегральной производительности до величин в несколько сотен строк текста за человеко-месяц. Для крупных проектов класса СРВ 80-е годы приводятся величины 100 - 150 строк на человеко-месяц, в отечественных проектах в те же годы эта величина приближалась к 80 - 100. Совершенствование технологии, квалификации специалистов и инструментальных средств автоматизации разработки позволили в последние годы повысить среднюю производительность труда при создании полностью новых оригинальных программных продуктов СРВ в несколько раз по экспертным оценкам до величин 300 - 500 строк на чело- веко-месяц. При разработке ПС необходимо учитывать, что экономические, временные, вычислительные и другие ресурсы па разработку и весь ЖЦ программ всегда ограниченны и используемые затраты для улучшения каждой характеристики должны учитывать эти ограничения. Для рационального распределения этих ресурсов необходимо знать как отражается изменение затрат на улучшении каждой характеристики качества ПС. Эта взаимосвязь затрат ресурсов и значений каждой характеристики зависит от назначения, а также от ряда свойств и других особенностей комплекса программ, что усложняет учет влияния таких связей. Тем не менее, выявлены основные тенденции такого взаимодействия, которые могут служить ориентирами при выборе и установлении требований к определенным характеристикам качества в конкретных проектах ПС. Схема работы программы по вычислению ТЭП: БИБЛИОГРАФИЯ 1. А.М. Вендров. Проектирование программного обеспечения экономических информационных систем. Учебник. М.: «Финансы и статистика». 2000. - 339 с. 2. А.М. Вендров. Практикум по проектированию программного обеспечения экомических информационных систем. М.: «Финансы и статистика». 2002. -190 с. 3. Практические аспекты информатизации. Стандартизация, сертификация и лицензирование. Справочная книга руководителя. Под редакцией Л.Д. Реймана. М.: 2000. -259с. 4. В.В. Липаев. Качество программных средств. Методические рекомендации. М.: «Янус-К». 2002. – 298с. 5. Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ./Под ред. А.А. Красилова. М.:Радио и связь, 1985. 6. В.В. Липаев, А.И. Потапов. Оценка затрат на разработку программных средств. М.: Финансы и статистика. 1988. 7. С.А. Орлов. Технологии разработки программного обеспечения. Учебник для вузов. М., Санкт-Петербург: «Питер». 2002. 8. Г. Коллинз, Дж. Блей. Структурные методы разработки систем: от стратегического планирования до тестирования. М.: «Статистика», 1980. 260с.:ил. 9. ГОСТ Р ИСО 9127 – 94 «Системы обработки информации. Документация пользователя и информация на упаковке потребительских программных пакетов». 10. ГОСТ 34601 – 90. «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания». 11. ГОСТ 34601 – 89. «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». 12. ГОСТ 34601 – 92. «Информационная технология. Виды испытаний автоматизированных систем». 13. Информационные системы в экономике. Под ред. Проф. В.В. Дика. Учебник для вузов, М., «Финансы и статистика». 1996. – 270 с. ПРИЛОЖЕНИЕ О СТАНДАРТЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА ДЛЯ ДИАЛОГОВЫХ ИТ Стандарт фирмы IBM. Проектирование пользовательского интерфейса на персональном компьютере.- Вильнюс, 1992 Стандартизация и согласованность интерфейса экономят время пользователя и разработчика . Пользовательский интерфейс включает в себя три понятия: общение приложения с пользователем, общение пользователя с приложением, язык общения. Язык общение определяется разработчиком программного приложения. Свойствами интерфейса являются наглядность и конкретность. Наиболее распространенный ранее командный интерфейс имел ряд недостатков (многочисленность команд, отсутствие стандарта для приложения), что ограничивало круг его применения. Для преодоления этих недостатков были предприняты попытки его упростить (например, NC). Однако настоящим решением проблемы стало создание графической оболочки для ОС. В настоящее время практически все распространенные ОС используют для своей работы графический интерфейс. Примером здесь может служить интерфейс, разработанный в исследовательском центре Пало Альто фирмы Xerox для компьютеров Macintosh фирмы Apple. Немного позже была разработана графическая оболочка под названием Microsoft Windows, реализующая технологию WIMP и удовлетворяющая стандарту CUA. Новшеством были применение мыши, выбор команд из меню, предоставление программам отдельных окон, использование для обозначения программ образов в виде пиктограмм. Удобство интерфейса и богатство возможностей делают Windows оптимальной системой для повседневной работы. Приложения, написанные под Windows, используют тот же интерфейс, поэтому его единообразие сводит к минимуму процесс обучения работе с любым приложением. Выход на рынок Windows-95 еще более упростил работу пользователя, так как интерфейс стал еще более простым, документированным, включающим встроенные коммуникационные возможности. Одной из важнейших функций интерфейса является формирование у пользователя одинаковой реакции на одинаковые действия приложений, их согласованность. Согласование должно быть выполнено в трех аспектах: физическом, который относится к техническим средствам (пока отсутствует), синтаксическом, который определяет последовательность и порядок появления элементов на экране (язык общения) и последовательность запросов (язык действий), семантическом, который обусловлен значениями элементов, составляющих интерфейс. Согласованность интерфейса экономит время пользователя и разработчика. Для пользователя уменьшается время изучения, а затем использования системы, сокращается число ошибок, появляется чувство комфортности и уверенности. Разработчику согласованный интерфейс позволяет выделить общие блоки интерфейса, стандартизировать отдельные элементы и правила взаимодействия с ними, сократить время проектирования новой системы. Разработка пользовательского интерфейса состоит из проектирования панелей и диалога. Панель приложения разделена на три части: место действий, тело панели, область функционирования клавиш. Преимущество использования меню действий (и выпадающего меню) заключается в том, что эти действия наглядны и могут быть запрошены пользователем установкой курсора, функциональной клавишей вводом команды либо каким-то другим простым способом. На цветном экране меню действий имеет обычно другой цвет по отношению к цвету панели. На монохромном экране используется сплошная линия для его отделения. Меню действий содержит объекты, состоящие из одного или нескольких слов. Два последних из них резервируются для действий “выход” и “справка”. Размещаются объекты слева направо по мере убывания частоты их использования. Возможны системы с многоуровневой системой выпадающих меню, но оптимальное число уровней – три, т.к. иначе могут появиться трудности в понимании многоуровневых меню. Тело панели содержит элементы тела панели: разделители областей, идентификатор и заголовок панели, инструкцию, заголовки столбца, группы, поля; указатель протяжки; область сообщений и команд; поля ввода и выбора (см.прил.2.1.). Область функциональных клавиш – необязательная часть, показывающая соответствие клавиш и действий, которые выполняются при их нажатии. В области функциональных клавиш отображаются только те действия, которые доступны на текущей панели. Для указания текущей позиции на панели используется курсор выбора. Для более быстрого взаимодействия можно предусмотреть функциональные клавиши, номер объекта выбора, команду или мнемонику. Разбивка панели на области основана на принципе “объект-действие”. Этот принцип разрешает пользователю сначала выбрать объект, затем произвести действия с этим объектом, что минимизирует число режимов, упрощает и ускоряет обучение работе с приложениями и создает для пользователя комфорт. Если панель располагается в отдельной ограниченной части экрана, то она называется окном, которое может быть первичным или вторичным. В первичном окне начинается диалог, и если в приложении не нужно создавать другие окна, окном считается весь экран. Первичное окно может содержать столько панелей, сколько нужно для ведения диалога. Вторичные же окна вызываются из первичных. В них пользователь ведет диалог параллельно с первичным окном. Часто вторичные окна используются для подсказки. Первичные и вторичные окна имеют заголовок в верхней части окна. Пользователь может переключаться из первичного окна во вторичное и наоборот. Существует также понятие “всплывающие окна”, которые позволяют улучшить диалог пользователя с приложением, ведущийся из первичного или вторичного окна. Когда пользователь и ЭВМ обмениваются сообщениями, диалог движется по одному из путей приложения, т.е. пользователь перемещается по приложению, выполняя конкретные действия. При этом действие необязательно требует от компьютера обработки информации. Оно может обеспечить переход от одной панели к другой, от одного приложения к другому. Если пользователь перешел к другой панели и его действия привели к потере информации, рекомендуется требовать подтверждение того, следует ли ее сохранять. При этом пользователю предоставляется шанс сохранить информацию, отменить последний запрос, вернуться на один шаг назад. Путь, по которому движется диалог, называется навигацией. Он может быть изображен в виде графа, где узлы - действия, дуги - переходы. Диалог состоит из двух частей: запросов на обработку информации и навигации по приложению. Часть запросов на обработку и навигацию является унифицированной. Унифицированные действия диалога – это действия, имеющий одинаковый смысл во всех приложениях. Некоторые унифицированные действия могут быть запрошены из выпадающего меню посредством действия “команда” функциональной клавишей. К унифицированным действиям диалога относятся: "отказ", “команда”, “ввод”, “выход”, “подсказка”, “регенерация”, “извлечение”, “идентификаторы”, “клавиши”, “справка” (см. прил.3). Существующий стандарт закрепляет названия унифицированных действий на английском языке. При переводе на русский названия могут не совпадать в разных приложениях. |