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

Критерии эффективности использования программных продуктов

При оценке эффективности использования информационной системы управления проектами необходимо рассматривать обширный набор аспектов-критериев. Существуют различные подходы к оценке эффективности использования ИСУП (Project Management Value), основывающиеся на методиках различных организаций (как коммерческих, так и независимых научных), оптимизированных для использования в разных областях хозяйственной деятельности.

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

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

Одна из методологий качественной оценки эффективности основана на экспертной оценке Критических факторов успеха (КФУ), выполнение которых необходимо для успешной реализации проекта.

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

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

Данный метод рекомендуется использовать неоднократно на этапе выполнения проекта. Его проводят циклически через определенные промежутки времени, например, каждый месяц или при закрытии этапа проекта.

На основе анализа успешных проектов, было выявлено несколько критических факторов, оказывающих наибольшее влияние на проект.

В соответствии с разработанной моделью успех проекта зависит от таких факторов, как:

· взаимоотношения с Заказчиком предусматривают активную работу с Заказчиком при разработке проекта, информирование его о продвижении работ в рамках проекта;

· учет потребительских требований определяет удовлетворенность пользователей результатами проекта, обеспечивает успешную сдачу системы в эксплуатацию;

· наличие необходимых технологий (используемые в проекте технологические решения доступны, надежны, опробованы, осуществляется необходимый контроль их правильного использования);

· наличие подготовленного персонала (подготовленность сотрудников к осуществлению проекта конкретного профиля, готовность провести обучение сотрудников или набор соответствующих специалистов, иногда привлечение консультантов).

Количественная оценка эффективности проектной деятельности компании может проводиться методом сравнительного анализа тенденций изменения определённых характеристик:

· отклонения по стоимости проекта отклонения бюджета проекта, вызванные его перерасходом или недорасходом;

· отклонения в расписании сдвиги в расписании проекта, вызванные отставанием или опережением работ;

В рамках ССП организация рассматривается и оценивается в четырех перспективах:

· в перспективе, связанной с финансовым состоянием (общепринятые финансовые показатели);

· в перспективе, связанной с позицией компании на рынке (число клиентов, доля рынка и т.д.);

· в перспективе, связанной с внутренними бизнес процессами (насколько они настроены и эффективны);

· в перспективе, связанной с развитием и обучением персонала.

Для каждой определённой цели компании вырабатываются ключевые показатели деятельности (КПД, Key Performance Indicator KPI). С помощью подбора ключевых показателей деятельности, которые являются, по сути, измерителями достижимости целей, компания получает хорошо сбалансированную картину кратко- и среднесрочных целей, финансовых и нефинансовых показателей деятельности.

Методика КПЭ инструмент, облегчающий процесс принятия управленческих решений за счет обеспечения руководства полноценной информацией.

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

Дата добавления: 2016-03-20 ; просмотров: 5492 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

Источник

Сопровождение и продвижение программного обеспечения отраслевой направленности

Вы будете перенаправлены на Автор24

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

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

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

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

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

Готовые работы на аналогичную тему

В последнее время озникли нестандартные программные продукты, не поддающиеся классификации по типовым критериям, такие как, к примеру, программа электронного собеседника.

Сопровождение и продвижение программного обеспечения отраслевой направленности

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

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

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

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

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

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

Аналитики способны применять несколько методик для выявления требований клиента к программному обеспечению отраслевой направленности. Это могут быть интервью или применение фокус групп и формирование перечня требований. Более современными являются методы формирования прототипов и сценариев применения. Если потребуется, то аналитик может применять комбинирование этих методик для выявления уточнённых требований заинтересованных субъектов. То есть он должен сформировать систему, удовлетворяющую все деловые потребности.

Источник

Характеристики качества программного обеспечения отраслевой направленности: корректность, устойчивость, расширяемость, многократность использования, совместимость, эффективность, переносимость, верификация, поддержка целостности, легкость использования

1498105610hlrfk

Характеристики качества программного обеспечения отраслевой направленности: корректность, устойчивость, расширяемость, многократность использования, совместимость, эффективность, переносимость, верификация, поддержка целостности, легкость использования

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

Критерий оценки качества программного обеспечения.

Характеристики качества программного обеспечения

Обеспечивает правильную обработку на правильных данных

«Элегантно» завершает обработку ошибок

Может легко адаптироваться к изменяющимся требованиям

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

Может легко использоваться с другим программным обеспечением

Эффективное использование времени, компьютерной памяти, дискового пространства и т. д.

Можно легко перенести на другие аппаратные и программные средства

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

Защищает себя от неправильного обращения и неправильного употребления

Для пользователя и для будущих программистов

Корректность и устойчивость

Легко спутать термины «Корректная программа» и «Устойчивая программа». Корректная программа работает, когда поданы на вход правильные данные. Она отвечает всем требованиям к спецификации данных и не терпит неудачу внутри заданного диапазона. Устойчивость подразумевает не только правильность. Устойчивая программа способна обработать ситуации, не запланированные проектом. Эти ситуации включают некорректный ввод пользователя, аппаратный отказ и ошибки во время выполнения программы. Устойчивые системы терпят неудачу элегантно, без потери критических данных. Легко увидеть, что обе характеристики необходимы для любой системы, которая будет оценена как высококачественное программное обеспечение. Если система некорректна, то она бесполезна. Если система неустойчива, то она окажется неспособной справиться с задачей в реальной ситуации.

Простота проекта. Более простые проект и архитектура позволяют произвести изменения намного быстрее и легче, чем при сложном проекте.

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

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

Многократность (повторность) использования и совместимость

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

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

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

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

Характеристика качества ПИ

Понятность – легкость понимания документации, сопровождающей ПИ.

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

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

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

Открытость ПИ – дает возможность понять назначение каждого оператора ПИ при чтении ее текста, т. е. каждый из идентификаторов должен нести смысловую нагрузку, например, SUM= CENA*KOL.

Согласованность ПИ – бывает внутренняя и внешняя.

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

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

Структурированность ПИ – делает его понятным для пользователя. Она предполагает создание ПИ в соответствии с определенными требованиями: использование при программировании трех базовых конструкций:

1. а) линейная структура б) условный переход в) цикл

2. Подробное комментирование текста программ.

3. Использование модульного программирования (отдельная программная единица).

4. Ограничение на объем модулей (количество операторов).

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

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

Например, независимые ПИ:

– отсутствие в нем одного из модулей (нет перехода с года на год, нет перехода с века на век);

– некомплектная документация (т. е. нет документа целиком, либо раздела в документе).

Например: если ведутся расчеты банковским операциям, то разумная точность – 3 знака после запятой, с последующим округлением до 2 знаков. Если в программе производятся расчеты по биологическим экспериментам, на молекулярном уровне, то точность по 10-12 знаков после запятой.

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

Часто характеристика эффективности вступает в противоречие с другими характеристиками качественного ПИ.

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

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

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

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

Человеческий фактор: (сервис)

1. Легкость использования ПИ.

2. ПИ должно удовлетворять требованиям пользователя.

3. ПИ должно реализовывать потенциальные потребности пользователя.

4. Необходимо при разработке ПИ следовать золотому правилу: относить к людям так же, как бы ты хотел, чтобы относились к тебе.

Мобильность – возможность работы ПИ в различных ОС.

Неконструктивность понятия правильной программы.

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

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

1.1.3. Надежность программного средства.

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

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

Технология программирования как технология разработки надежных программных средств.

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

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

Критерии надежности программ.

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

Факторы, снижающие надежность функционирования про­грамм. На надежность функционирования КП влияют, прежде всего, факторы, вызывающие сбой или отказ при исполнении программы:

искажения исходной информации, поступающей от внешних абонентов;

самоустраняющиеся отказы или сбои в аппаратуре ЭВМ;

не выявленные ошибки в программах.

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

Первопричинами искажений данных, поступающих от внеш­них абонентов, могут быть:

искажения данных на первичных носителях информации при их подготовке;

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

шумы и сбои в каналах связи при передаче сообщений по телекодовым линиям связи;

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

потери или искажения сообщений в ограниченных буферных накопителях ЭВМ;

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

Самоустраняющиеся отказы и сбои в аппаратуре ЭВМ явля­ются заметным фактором, влияющим на надежность функцио­нирования программы. Существуют ВС, характеризующиеся средним временем наработки на отказ аппаратуры, исчисляе­мым десятками тысяч часов. Однако, для однопроцессорных ЭВМ наработка на устойчивый отказ, как правило, измеряется сотня­ми или тысячами часов. В однопроцессорных ЭВМ значительно чаще происходят сбои или трудно обнаруживаемые кратковре­менные отказы. Некоторая часть аппаратных сбоев может приво­дить к искажениям исполнения программ или к искажениям данных. Сбои, которые не удается обнаружить и зафиксировать при функционировании КП в процессе нормальной обработки информации, происходят на Один-два порядка чаще, чем устой­чивые отказы, т. е. наработка на сбой оценивается десятками часов.

Не выявленные ошибки в сложных КП, являются основной причиной ненадежности функционирования большинства из них. Хотя в процессе отладки основная часть ошибок в программах обнаруживается и устраняется, всегда есть риск проявления какой-то ошибки при некотором, ранее не испытан­ном сочетании исходных данных. Разнообразие и внешняя случайность реальных сочетаний переменных в исходных данных, об­рабатываемых программой, создают такие ситуации, при которых последствия отдельных ошибок в программах проявляются аналогично последствиям сбоев в аппаратуре ЭВМ.

Источник

Adblock
detector