Т е м а 1: Основные понятия и определения

Лекции по курсу:

Организация и планирование производства

программного обеспечения”

Т е м а 1: Основные понятия и определения

Системное и прикладное программное обеспечение

 

Режимы работы и функции ОС

При однопрограммном режиме каждая программа после ее запуска выполняется до конца, используя при этом все свободные ресурсы машины. В многопрограммном (мультипрограммном) режиме параллельно может выполняться… Для того чтобы выполнить какую-либо программу пользователя или обслуживающего программу, пользователь должен передать…

Себестоимость программного изделия (ПИ)

1) В структуре затрат (капитальных вложений), связанных с разработкой ПИ, выделяют предпроизводственные затраты (капитальные вложения на разработку… С = С+ С, руб., где С– затраты на разработку (проектирование) ПИ, руб.;

Формирование цены разработки (товара)

Цена – это фактор, непосредственно влияющий на прибыльность. Во-1-х, прибыль П есть разница между суммарной выручкой Вот продаж и… П = В- З, руб.

Стоимостная оценка ПИ (разработки)

где С– затраты на разработку (проектирование) ПИ, руб.; С– затраты, связанные с реализацией ПИ (проекта), руб. С= С+ С, руб.,

Тема 3: Цена в условиях инфляции

Ц= Ц∙, руб., где отражены следующие величины: на момент заключения договора:

Тема 4: Как измерять конкурентоспособность

Предположим, что наша фирма разрабатывает ПО и поставляет его производителю АСУП. Допустим также, что раньше мы продавали их по цене 10 тыс.… Совершенно очевидно, что ценность нового ПО для фирмы-потребителя выше, чем… Согласно микроэкономической теории эта величина удовлетворяет известному правилу равенства предельных издержек МС…

Тема 5: Оценка экономии от использования ПИ

Свойства качественного ПО.

1. возможности их использования в исходном виде; 2. удобство эксплуатации; 3. возможность применения в иных условиях.

Тема 6. Работа в программировании

Квантификация – (от лат. quantum – сколько и …фикация – оценка) – количественное выражение, измерение качественных признаков изучаемых объектов. Простое соотношение между этими метрическими характеристиками и работой,…

Вывод уравнения работы.

Шаг 2.Предположим далее, что каждый выбор из словаря неслучаен. Исследования методов сортировки показали, что самым быстрым способом поиска в… Шаг 3.На основании шагов №1 и №2 можно заключить, что программа порождается… Шаг 4. Т. к. объём программы V определяется как

Различные измерения времени.

Дж. Страуд определил «момент» как время, требуемое человеческому мозгу на выполнение наиболее элементарного различения. Он обнаружил, что в течение… Естественно, что программист, занимающийся реализацией алгоритма, способен в… Требование мысленной сосредоточенности предполагает, что максимальное внимание должно быть проявлено в процессе…

Л е к ц и я №3

Тема 7: УПРАВЛЕНИЕ РАЗРАБОТКОЙ ПРОГРАММНОГО ИЗДЕЛИЯ

Управление разработкой программных средств. Методы оценки затрат на разработку ПС

В рамках поставленной цели управления необходимо решить задачу оптимизации структуры ЖЦ как по продолжительности отдельных фаз цикла, так и по… Существенной особенностью процесса создания ПС является большой удельный вес… В зависимости от способа получения исходных данных при определении стоимостных и трудовых затрат на разработку ПС…

Качество программного изделия. Основные показатели качественного ПИ.

Методика определения показателей качества предложена коллективом авторов книги “Характеристики качества ПО” [1]. Она основана на составлении т.н.… В таблице приняты следующие условные обозначения: В – очень высокая положительная корреляция с качеством;

Надежность ПИ. Модели надежности.

Надежность – это свойство ПИ сохранять работоспособность в течение определенного периода времени, в определенных условиях эксплуатации с учетом… Работоспособным называется такое состояние ПИ, при котором оно способно… Причины отказа ПИ и технических систем (ТС) различны. Если для ТС причиной отказа м.б. физический износ узлов и…

Класс категория

Наименование АА000 АА010   АА020   АА030 . . . . . ВВ000 ВВ010 ВВ020 . . . . . СС000 СС010 . . . . . DD000 . . . . . DD030 . . . . . DD070   . . . . . DD071   . . . . . ЕЕ000 . . . . . FF000 . . . . . GG000   . . . . . UU000 Ошибки вычислений Неверно определяется общее число элементов Неверно вычислен физический или логический номер элемента Ошибка в вычислении индекса . . . . . Логические ошибки Ошибка в определении границ Логически неверное ветвление . . . . . Ошибки ввода-вывода Информация не выводится   Ошибки манипулирования данными . . . . . Данные потеряны или не хранятся . . . . . Ошибка при манипулировании с битами данными . . . . . Ошибочное использование операции изменения состояния бита . . . . . Ошибки в ОС . . . . . Ошибки компоновки . . . . . Ошибки в межпрограммных интерфейсах . . . . . Неясности

 

Для реализации этого пункта рекомендации целесообразно воспользоваться классификацией, которая построена по принципу “сверху вниз” с необходимым описанием контекста, в котором обнаружена ошибка.

На первом уровне классификационной схемы выделены 5 признаков ошибки:

1) где произошла ошибка;

2) на что похожа ошибка;

3) как была сделана ошибка;

4) когда произошла ошибка;

5) почему произошла ошибка.

Каждый признак представлен в виде набора категорий, разделов и подразделов.

Проблема создания надежных ПИ имеет 2 стороны:

- разработка средств и методов, применение которых в процессе создания ПИ позволит обеспечить ему высокие показатели надежности;

- развитие самой теории надежности: создание стройной системы показателей надежности; планирование уровня надежности на начальных этапах разработки ПИ; возможность оценить показатели надежности по результатам испытаний программ; контроль уровня надежности в процессе эксплуатации ПИ и т.д.

Известно, что ПИ создаются коллективами разработчиков на протяжении определенного времени. После этого они могут поставляться пользователям для эксплуатации по назначению. При этом возникает ряд задач организационного, методологического, структурного и технологического характера, требующих разрешения. Используемые технологии обычно охватывают какой-нибудь один или несколько этапов ЖЦ ПИ и ориентированы на определенный тип разрабатываемого ПИ. Например, ПИ обработки экономической информации. Наибольшую известность получили такие методы, как нисходящее проектирование, восходящее проектирование и метод расширения ядра. В основу последнего положен модульный принцип построения программ.

Нисходящее проектирования (проектирование сверху вниз) основано на пошаговом уточнении и анализе потоков данных.

Первоначально “идея” записывается на языке высокого уровня, возможно, с использованием математической символики, экономических и инженерных расчетов. В последующем осуществляется переход на более низкие иерархические уровни детализации проекта и языки низших уровней (схемы, диаграммы, псевдокоды) вплоть до алгоритмических.

В процессе эксплуатации ПИ могут подвергаться незначительным изменениям и корректировке. Процесс эксплуатации ПИ продолжается до полного морального износа вследствие изменений внешней среды функционирования.

Вопросами о том, как организовать и выполнять действия на любом из этапов ЖЦ для того, чтобы повысить надежность конечного продукта, какие средства и методы избрать (а во многих случаях и разработать) для достижения поставленной цели – получения надежных ПИ, занимается технология программирования (ТП).

ТП – это совокупность знаний о способах выполнения работ по всем этапам создания ПИ, которая позволяет при оптимальных затратах ресурсов получить ПИ с заданными потребительскими и эксплуатационными свойствами. Под ресурсами в данном случае понимаются время на создание ПИ (Т), стоимость (К), машинное время (Т) и т.д.

Анализ потока данных базируется на исследовании процессов передачи и преобразования входных элементов. Первоначальный поток данных разбивается на вход, преобразование и выход, интерпретируемые в программы управления вводом, выводом, непосредственно обработки информации.

Рекурсивно используемый на отдельных ветвях древовидной структуры программы метод разбиения на вход, преобразование, выход позволяет получить модули низшего уровня.

В методах расширения ядра и восходящего проектирования (проектирование снизу-вверх) больше внимания уделяется не определению функций всей программы в целом, а тем частным функциям, которые потребуются проектируемой программе.

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

В методе восходящего проектирования определяются функции самого низкого уровня, обеспечивающие такие элементарные операции, как управление внешней памятью, выбор библиотечных процедур и т.д. Далее разработанные модули, реализующие эти функции, используются для определения функций и создания модулей более высокого уровня. Это – такие как обновление файлов, корректировка информации и другие, которые, в свою очередь, включаются в части программы на более высоком уровне. Процесс продолжается до тех пор, пока разработка программы не будет завершена.

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

Специфика и реальные условия разработки различных ПИ вызвали необходимость создания технологий проектирования, облегчающих процесс разработки, обеспечивающих последовательное и детальное описание этапов проектирования, взаимодействия разработчиков и пользователей на этапе создания и поддержания ПИ. В конечном итоге они способствуют повышению качества создаваемого ПИ.

К таким ТП можно отнести HIPO-технологию и следующие технологии:

▪ PSL/PSA (Problem Statement Language/ Problem Statement Analyzer), включающая язык и анализатор постановки задач;

▪ SREM (Software Requirement Engineering Methodology) – методология разработки требований к ПО, ориентированная на разработку систем реального времени;

▪ PDM (Process Design Methodology) – методология проектирования процессов, предназначенная и для проектирования, и для тестирования ПС;

▪ SADT (Structured Analysis and Design Technique) – методология структурного анализа и проектирования, состоящая из графического языка ссылок и языка синхронизации. Она используется при разработке систем самых широких классов и т.д.

С целью управления надежностью ПС возникает необходимость определения количественных показателей надежности на различных этапах его разработки. Это обосновывается следующей необходимостью:

1. Надежность ПС, оставаясь ценным качеством, достигается в действительности за счет 2-х основных моментов: Во-1-х, за счет другой характеристики ПС, например объема программ, времени их выполнения, объема внешней памяти и т.д. Во-2-х, за счет характеристик процесса создания ПС, таких, как стоимость разработки (Кили Ц), материальные ресурсы, выделенные на создание ПС, график выполнения работ и т.д. Желательно, чтобы при выборе характеристик ПС и организации процесса его разработки можно было принимать компромиссные решения.

2. Количественные показатели надежности могут использоваться для оценки достигнутого уровня ТП, для выбора метода проектирования будущего ПС. Применение на практике любой новой идеи по технологии программирования связано с дополнительными затратами. Количественный показатель надежности позволяет установить критерии, по которым можно оценивать новые методы и вырабатывать рекомендации по их применению.

3. На этапе тестовых испытаний ПС показатели надежности могут служить критериями завершенности тестирования, т.к. выявлена высокая степень корреляции показателей надежности (например, средней наработки на отказ) с количеством проверок. Это позволяет связать надежность с плановыми сроками выполнения программного проекта.

4. При эксплуатации ПС часто возникает необходимость проведения работ по сопровождению. Известно, что внесение изменений, модификация ПС ухудшают надежность. Поэтому по количественному показателю надежности можно судить об эффективности и целесообразности внесения того или иного изменения.

Основным средством определения количественных показателей надежности являются модели надежности. Под ними понимают математическую модель, построенную для оценки зависимости надежности от заранее известных или оцененных в ходе создания ПС параметров. В связи с этим определение показателей надежности принято рассматривать в единстве 3-х процессов – предсказание, измерение, оценивание.

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

Измерение – это определение количественных показателей надежности, основанное на данных об интервалах между отказами, полученных при выполнении программ в условиях тестовых испытаний.

Оценивание – это определение количественных показателей надежности, основанное на данных об интервалах между отказами, полученными при испытании ПС в реальных условиях функционирования.

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

Рассмотрим классификацию моделей надежности ПС (МНПС), приведенную на Рис.1. МНПС подразделяются на аналитические и эмпирические. Аналитические модели дают возможность рассчитать количественные показатели надежности. Они основываются на данных о поведении программы в процессе тестирования (измеряющие и оценивающие модели). Эмпирические модели базируются на анализе структурных особенностей программ. Они рассматривают зависимость показателей надежности от числа межмодульных связей, от количества циклов в модулях, от отношения количества прямолинейных участков программы к количеству точек ветвления и т.д. Часто эмпирические модели не дают конечных результатов показателей надежности. Однако они включены в классификационную схему, т.к. развитие этих моделей позволяет выявлять взаимосвязь между сложностью ПС и его надежностью. Эти модели можно использовать на этапе проектирования ПС, когда осуществлена разбивка на модули и известна его структура.

Аналитические модели представлены двумя группами: динамические модели и статические. В динамических МНПС поведение ПС (появление отказов) рассматривается во времени. В статических моделях появление отказов не связывают со временем. Здесь учитывают только зависимость количества ошибок от числа тестовых прогонов (по области ошибок) или зависимость количества ошибок от характеристики входных данных.

Для использования динамических моделей необходимо иметь данные о появлении отказов во времени. Если фиксируются интервалы каждого отказа, то получается непрерывная картина появления отказов во времени. Это – группа динамических моделей с непрерывным временем. С другой стороны, может фиксироваться только число отказов за произвольный интервал времени. В этом случае поведение ПС может быть представлено только в дискретных точках. Это – группа динамических моделей с дискретным временем. Рассмотрим основные предпосылки, ограничения и математический аппарат моделей, представляющих каждую группу, выделенную на схеме.

 

7.3.1. Аналитические модели надежности

Аналитическое моделирование НПС включает четыре шага:

1) определение предположений, связанных с процедурой тестирования ПС;

 

 

Рис. 7.1. Классификационная схема МНПС

2) разработка или выбор аналитической модели, базирующейся на предположениях о процедуре тестирования;

3) выбор параметров моделей с использованием полученных данных ;

4) применение модели – расчет количественных показателей надежности по модели.

Динамические модели надежности

a) Модель Шумана может быть использована при определенным образом организационной процедуре тестирования. Использование модели Шумана предполагает,… Т.о., удельное число ошибок на одну машинную команду, оставшихся в системе… ε( τ) = ∙ ε( τ), (1)

Р е ш е н и е.

- ошибка, найденная соответственно на этапе тестирования О ÷ А ε( τ) = = = 0,011; - то же на этапе А ÷ В

Статические модели надежности

1) Модель Миллса. Использование этой модели предполагает необходимость перед началом тестирования искусственно вносить в программу (“засорять”)… Тестируя программу в течение некоторого времени, собирается статистика об… N = (21)

Эмпирические модели надежности

1) Модель Сложности. В литературе неоднократно подчеркивается тесная взаимосвязь между сложностью и надежностью ПС. Если придерживаться упрощенного… Под программным модулем в данном случае следует понимать программную единицу,… Некоторые базовые понятия для определения характеристик сложности даны в табл. 4.4.

Т е м а №8

Оценка экономической эффективности программного

Изделия

Экономическая эффективность ПИ оценивается на различных этапах жизненного цикла.

Основными источниками экономии при производстве ПИ являются выпуск их более высокого качества, снижение трудоемкости процессов производства ПИ и услуг по их внедрению и сопровождению, снижение доли условно-постоянных расходов, приходящихся на ПИ.

Расчет экономического эффекта, связанного с внедрением ПИ

Э = (З– З)∙А, (31) где Э – годовой экономический эффект от разработки ПИ, руб.; Зи З– суммарные затраты на единицу выпуска ПИ соответственно по базовому и новому вариантам, руб.;

Расчет текущих затрат (себестоимости) пользователя при эксплуатации ПИ

При расчете капитальных вложений в ПИ анализируются затраты изготовителя (или разработчика) и пользователя ПИ независимо от источников их… • затраты разработчика на научно-исследовательские и опытно-конструкторские… • затраты пользователя на приобретение ПИ, осуществляемые пользователем через механизм цен и хоздоговорных отношений,…

Коэффициент экономической эффективности применения ПИ

= ∙= ∙, где – полученная по всем источникам суммарная экономия от использования ПИ,… t – шаг расчета;

Варианты возможных расчетов экономического эффекта, связанного внедрением ПИ, в дипломных проектах

Достаточно сложным вопросом для тем с использованием вычислительной техники является анализ экономической целесообразности (прибыльности или безубыточности) их использования на практике. Из-за недостаточности данных подобный расчет часто полноценно провести затруднительно. Следует отметить, что затраты на приобретение дорогостоящей вычислительной техники и определенный уровень эксплуатационных издержек в той или иной степени могут перекрывать экономию, которую можно проследить. Т. е., в большинстве случаев на момент сдачи проекта заказчику прямой экономический эффект количественно рассчитать в стоимостном выражении бывает затруднительно. Но по некоторым задачам результатом перевода расчета на ЭВМ может являться экономия на стоимости обработки информации.

1) В случае автоматизации ручного труда (при решении различных прикладных задач, составлении отчетов, обработке информации, формировании информационных массивов, снятии исходных данных с датчиков и т.д.) годовая экономия, руб./год, может быть рассчитана следующим образом:

Э = З- З- С·,

где З– годовые затраты средств на обработку данных прежним методом (например, вручную), руб.;

З– годовые текущие затраты на решение проблемы с использованием ЭВМ, руб.;

С– разовые затраты подготовительного периода, включающие затраты на проектирование и внедрение разработки, т.е. себестоимость проектирования, руб.;

Р, Р – количество сеансов решения задачи на ЭВМ по данной программе соответственно за год и за все время ее предполагаемой эксплуатации (Р = 3 – 4 года).

Годовые затраты на обработку данных прежним методом (вручную) определяются по формуле

З= n·h·c,

где n– число человеко-часов, необходимых для однократного решения задачи;

h – периодичность решения задачи, число выполняемых расчетов или частота обработки информации в течение года;

c – стоимость одного человеко-часа работы специалиста, занятого решением проблемы, руб.

Число человеко-часов, необходимых, например, для одноразового решения задачи прежним методом (вручную)

n= ,

где d – количество документов (форм) с входной и выходной информацией;

P – количество единиц информации (обрабатываемых показателей) в среднем на документе;

t– средняя трудоемкость расчета одного показателя прежним методом (вручную), мин.

Стоимость одного человеко-часа работы специалиста

С = З·,

где З– часовая заработная плата специалиста, руб.;

П, Пи П– процент дополнительной зарплаты, единого социального налога и накладных расходов; их значение принимается по согласованию с экономистами на объекте практики.

При выполнении расчетов на ЭВМ годовая сумма затрат определяется по формуле

З= С· Т· h = С· Т,

где Т– затраты машинного времени на один просчет, ч;

Т– годовые затраты машинного времени на решение данной задачи, ч;

С– стоимость машино-часа пользователя (заказчика), руб.

2) При определении сравнительной экономической эффективности, руб./год, двух вариантов автоматизированной обработки информации при решении отдельных задач (проблем) сравниваются прямые затраты на обработку данных по вариантам автоматизации по следующей формуле:

Э = (З+ З·) - (З+ С·),

где Зи З– годовая сумма затрат при использовании соответственно старого и нового программных средств, руб.;

З– разовые затраты на старое программное средство, т.е. себестоимость проектирования или цена его покупки, руб.;

С– разовые затраты подготовительного периода, включающие затраты на проектирование и внедрение новой разработки, т.е. себестоимость проектирования, руб.;

Р, Р – количество сеансов решения задачи на ЭВМ с помощью старой и новой программ соответственно за год и за все время ее предполагаемой эксплуатации (Р = 3 – 4 года).

3) Аналогично может быть рассчитана экономия Эпо другим источникам. Например, разрабатываемое проектное решение экономит машинное время на решение задачи, ликвидирует затраты на приобретение и содержание дорогостоящего оборудования, сокращает количество персонала и т. д. При наличии соответствующих данных можно определить коэффициент отдачи от инвестированных в проект средств . Под инвестированными средствами К, руб., следует понимать затраты организации, приобретающей представленное в дипломном проекте техническое решение. Это – цена приобретения, включая НДС по соответствующей ставке и сопутствующие этому приобретению затраты (переустройство помещений, приобретение ЭВМ и других технических средств, дополнительное привлечение персонала и пр.):

= ,

где Э– экономия по отдельному i-му источнику, руб./год. Коэффициент отдачи с инвестированных средств, равный 30–35 %, как выше установлено, свидетельствует об экономической целесообразности внедрения разработки проекта у заказчика. = .

4) Как показывает мировая практика, крупные компании периодически меняют компьютерную систему управления или переходят на ее принципиально новую версию в среднем каждые пять лет. Это происходит, когда компания пересматривает свои бизнес-процессы или внедряет новые информационные технологии, либо когда устаревает существующая система управления. Принимая решение о применении качественно новой системы, предприятие должно действовать так же, как и при первоначальном ее внедрении – оценить эффективность этого процесса.

Для оценки эффективности внедрения компьютерных систем используются показатели возврата инвестиций (ROI – return on investment) и совокупной стоимости владения (TCO – total cost of ownership), а также анализ выгодности затрат (CBA – cost-benefits analysis).

Один из основных показателей оценки эффективности внедрения – совокупная стоимость владения (TCO). При расчете ТСО учитываются как первоначальные затраты (на внедрение), так и все последующие затраты (на эксплуатацию, доработку и т. п.). Недостаток использования этого показателя заключается в том, что он позволяет оценить лишь расходы на внедрение и эксплуатацию ERP-системы. ERP – это ИС управления ресурсами организации.

Поэтому расчет только ТСО не дает полного представления о целесообразности использования системы: чем больше пользователей работают в единой системе и чем сложнее бизнес-процессы, тем выше будет ТСО. Однако и польза от установки подобной системы будет значительно выше. Поэтому необходимо учитывать не только затраты, но и выгоды от внедрения ERP-системы, которые определяются с помощью показателя возврата инвестиций (ROI). Этот коэффициент позволяет оценить рентабельность вложений в покупку и внедрение ERP-системы и рассчитывается по формуле

ROI = [(PRS–ТСО) / ТСО] ∙ 100%,

где PRS – выгоды от внедрения системы, руб.

Совокупные затраты, связанные с владением технологией определяются по формуле

ТСО = /+ ,

где – себестоимость проекта (ПП), руб.;

– период морального старения, лет (например, =3 года);

– затраты на эксплуатацию системы, руб./год.

= ∙ ∙(+ ),

где – номинальный годовой фонд времени в днях;

– продолжительность использования разработки в течение рабочего дня, ч;

– часовая заработная плата оператора ЭВМ, руб.;

– стоимость машинного часа работы ЭВМ, на которой эксплуатируется разработка, руб.

В конечном счете, при полученном значении ROI,превышающем (30–35)% (т.е. ROI ≥30–35 %), вложения в покупку и внедрение ERP-системы могут быть признаны рентабельными.