Главная База знаний "Allbest" Программирование, компьютеры и кибернетика Ревьюирование программных продуктов

Ревьюирование программных продуктов

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

Рубрика Программирование, компьютеры и кибернетика
Вид отчет по практике
Язык русский
Дата добавления 28.11.2022
Размер файла 2,0 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Министерство образования Иркутской области

Государственное бюджетное профессиональное образовательное учреждение

Иркутской области

«Ангарский промышленно-экономический техникум»

(ГБПОУ ИО «АПЭТ»)чс

Отчет

по практической подготовке в виде учебной практики

Ревьюирование программных продуктов

по специальности 09.02.07 Информационные системы и программирование

Голощапова Мелисса Вадимовна

г. Ангарск

2021-2022 уч. г

Содержание

  • Введение
  • 1. Основная часть
    • 1.1 Охрана труда и техника безопасности во время прохождения практики
      • 1.1.1 Общие требования охраны труда
      • 1.1.2 Требования охраны труда перед началом работы
      • 1.1.3 Требования охраны труда во время работы
      • 1.1.4 Требования охраны труда в аварийных ситуациях
      • 1.1.5 Требования охраны труда по окончании работы
    • 1.2 Использование метрик программного продукта при ревьюировании Проверка целостности программного кода. Анализ потоков данных
    • 1.3 Использование метрик стилистики. Выполнение измерений характеристик кода
    • 1.4 Исследование кода вредоносных программ
  • 2. Менеджмент программного проекта
    • 2.1 Описание сценариев использования программного продукта Оценка трудоемкости и сроков разработки ПО
    • 2.2 Оценка стоимости проекта
    • 2.3 Обоснование выбора вида диаграммы для динамического моделирования
  • Заключение
  • Библиографический список

Ведение

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

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

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

Для достижения поставленной цели были поставлены следующие задачи:

- Ознакомиться и инструктажем по технике безопасности во время прохождения практики;

- ознакомится и провести ревьюирование проверки целостности программного продукта;

- выполнить измерение характеристик кода;

- провести анализ кода вредоносных программ;

- провести описание сценариев использования программного продукта;

- провести оценку трудоёмкости и сроков разработки ПО;

- оценить стоимость проекта

- провести обоснования выбора вида диаграммы для динамического моделирования.

1. Основная часть

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

1.1 Охрана труда и техника безопасности во время прохождения практики

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

1.1.1 Общие требования охраны труда

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

При эксплуатации персонального компьютера на работника могут оказывать действие следующие опасные и вредные производственные факторы:

- повышенный уровень электромагнитных излучений;

- повышенный уровень статического электричества;

- пониженная ионизация воздуха;

- статические физические перегрузки;

- перенапряжение зрительных анализаторов.

Работник обязан:

Выполнять только ту работу, которая определена его должностной инструкцией.

Содержать в чистоте рабочее место.

Соблюдать режим труда и отдыха в зависимости от продолжительности, вида и категории трудовой деятельности (Приложение 1).

Соблюдать меры пожарной безопасности.

Рабочие места с компьютерами должны размещаться таким образом, чтобы расстояние от экрана одного видеомонитора до тыла другого было не менее 2,0 м, а расстояние между боковыми поверхностями видеомониторов - не менее 1,2 м.

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

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

Рабочая мебель для пользователей компьютерной техникой должна отвечать следующим требованиям:

- высота рабочей поверхности стола должна регулироваться в пределах 680 - 800 мм; при отсутствии такой возможности высота рабочей поверхности стола должна составлять 725 мм;

- рабочий стол должен иметь пространство для ног высотой не менее 600 мм, глубиной на уровне колен не менее 450 мм и на уровне вытянутых ног не менее 650 мм;

- рабочий стул (кресло) должен быть подъемно - поворотным и регулируемым по высоте и углам наклона сиденья и спинки, а также - расстоянию спинки от переднего края сиденья;

- рабочее место должно быть оборудовано подставкой для ног, имеющей ширину не менее 300 мм, глубину не менее 400 мм, регулировку по высоте в пределах до 150 мм и по углу наклона опорной поверхности подставки до 20 градусов; поверхность подставки должна быть рифленой и иметь по переднему краю бортик высотой 10 мм;

- рабочее место с персональным компьютером должно быть оснащено легко перемещаемым пюпитром для документов.

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

За невыполнение данной Инструкции виновные привлекаются к ответственности согласно правилам внутреннего трудового распорядка или взысканиям, определенным Кодексом законов о труде Российской Федерации.

1.1.2 Требования охраны труда перед началом работы

- Подготовить рабочее место.

- Отрегулировать освещение на рабочем месте, убедиться в отсутствии бликов на экране.

- Проверить правильность подключения оборудования к электросети.

- Проверить исправность проводов питания и отсутствие оголенных участков проводов.

- Убедиться в наличии заземления системного блока, монитора и защитного экрана.

- Протереть антистатической салфеткой поверхность экрана монитора и защитного экрана.

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

1.1.3 Требования охраны труда во время работы

Работнику при работе на ПК запрещается:

- прикасаться к задней панели системного блока (процессора) при включенном питании;

- переключать разъемы интерфейсных кабелей периферийных устройств при включенном питании;

- допускать попадание влаги на поверхность системного блока (процессора), монитора, рабочую поверхность клавиатуры, дисководов, принтеров и других устройств;

- производить самостоятельное вскрытие и ремонт оборудования;

- работать на компьютере при снятых кожухах;

- отключать оборудование от электросети и выдергивать электровилку, держась за шнур.

Продолжительность непрерывной работы с компьютером без регламентированного перерыва не должна превышать 2-х часов.

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

1.1.4 Требования охраны труда в аварийных ситуациях

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

Не приступать к работе до устранения неисправностей.

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

1.1.5 Требования охраны труда по окончании работы

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

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

1.2 Использование метрик программного продукта при ревьюировании

Проверка целостности программного кода. Анализ потоков данных

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

- n1 - число уникальных операторов программы, включая символы-разделители, имена процедур и знаки операций (словарь операторов);

- n2 - число уникальных операндов программы (словарь операндов);

- N1 - общее число операторов в программе;

- N2 - общее число операндов в программе. +, *, /, - это операторы x, у, z, 999, -25, number1 - это операнды. На основании этих характеристик рассчитываются оценки:

- Словарь программы (Halstead Program Vocabulary, HPVoc):

n = n1 + n2;

- Длина программы (Halstead Program Length, HPLen):

N = N1 + N2;

- Объем программы (Halstead Program Volume, HPVol):

V = N log2 n;

- Сложность программы (Halstead Difficulty, HDiff):

D = (n1/2) Ч (N2 / n2);

- На основе показателя HDiff предлагается оценивать усилия программиста при разработке при помощи показателя HEff (Halstead Effort):

H = D Ч V.

Вопросы пункта:

1. Где можно использовать метрики Холстеда?

Метрики Холстеда предлагают разумный подход к решению следующих задач:

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

- определение норм первоначальных ошибок;

- количественная оценка языков программирования и эффекта модульности;

- обоснование метода измерения различий между программами, написанными специалистами разного уровня.

2. Чем определяются характеристики программы?

В основе вычисления метрик Холстеда лежит концепция, согласно которой алгоритм состоит только из операторов и операндов, на анализе которых и происходит определение хар-к программам.

3. Как оценить качество реализации алгоритма по метрикам?

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

4. В чем недостаток программометрии?

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

Замещение «управление людьми» на «управление цифрами», которые не учитывает опыт сотрудника и их другие качества.

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

Задание:

Даны целые числа A1,…, A80. Получить сумму тех чисел данной последовательности, которые

а) кратны 5;

б) нечетны и отрицательны;

в) удовлетворяют условию A[i]<i2.

На таблице 1 представлен результат вычисления метрики Холстеда.

Таблица 1. Вычисление метрики Холстеда

Вариант задания №3

Код программы:

Код оптимизированной программы:

using System;

using System. Collections. Generic;

using System. Linq;

using System. Text;

using System. Threading. Tasks;

using System.IO;

namespace Test

{

public class Test

{

public static void Main (string[] args)

{

var N = 80;

var arr = new int[N];

Random rnd = new Random();

for (int i = 0; i < N; i++)

arr[i] = rnd. Next (-100, 100);

for (int i = 0; i < N; i++)

Console. Write (arr[i] + «»);

Console. WriteLine();

 // 1)

Console. WriteLine(«1) {0}», arr. Where (a => a% 5 == 0).Sum());

 // 2)

Console. WriteLine(«2) {0}», arr. Where (a => (a% 2 == 1) || (a < 0)).Sum());

 // 3)

 // i

int index = I*I;

Console. WriteLine(«3) {0}», arr. Where (a => a < arr[index]).Sum());

Console. ReadKey();

}

}

}

using System;

namespace Test

{

public class Test

{

public static void Main (string[] args)

{

var N = 80;

var arr = new int[N];

Random rnd = new Random();

for (int i = 0; i < N; i++)

arr[i] = rnd. Next (-100, 100);

for (int i = 0; i < N; i++)

Console. Write (arr[i] + «»);

Console. WriteLine();

 // 1)

Console. WriteLine(«1) {0}», arr. Where (a => a% 5 == 0).Sum());

 // 2)

Console. WriteLine(«2) {0}», arr. Where (a => (a% 2 == 1) || (a < 0)).Sum());

 // 3)

 // i

int index = I*I;

Console. WriteLine(«3) {0}», arr. Where (a => a < arr[index]).Sum());

Console. ReadKey();

}

}

}

Расчет метрики:

Расчет метрики:

n = 15+6=21

N = 90+100=191

V = 412

D = 85.5

H = 35226

n = 15+6=21

N = 81+37=118

V = 412

D = 85.5

H = 35227

На таблице 2 представлен словарь операторов программы.

Таблица 2. Словарь операторов

Словарь операторов

=

14

<

3

>

3

*

1

+

5

;

15

If

2

for

3

var

2

Int

4

Console

6

Main

1

()

12

{}

5

%

5

N1=15

Сумма: 81

В таблице 3 представлен словарь операндов программы

Таблица 3. Словарь операндов

Словарь операндов

N

3

Arr

3

Index

6

Sum()

3

Rnd

5

I

17

N1==6

Сумма: 37

Вывод: Таким образом, количество тестовых прогонов будет равно 9. Исходя из сложности по Холстеду можно сделать вывод, что в программе содержатся 30 уникальных операторов и операндов, их общее число равно 191, а объем программы составляет 412.

Ответы на вопросы:

1 Какой процесс называют «Оптимизацией программы»?

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

2 Какие существуют способы оптимизации? Для чего они применяются?

Способы оптимизации:

- Количественный (используется, когда есть математическая зависимость между показателями);

- Экспертный (используется, когда другие методы не возможны или экономически не оправданы);

- Экспериментальные (используется, когда необходимо получить результаты, близкие к оптимальным).

3 Приведите примеры приемов алгоритмической оптимизации.

Примеры приёмов алгоритмической оптимизации представлены на рисунках 1 - 2:

Рисунок 1. Пример 1

Рисунок 2. Пример 2

1.3 Использование метрик стилистики. Выполнение измерений характеристик кода

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

Наиболее простой метрикой стилистики и понятности является оценка уровня комментированности программы F:

F=Nком/Nстр,

где Nком - количество комментариев в программе;

Nстр - количество строк или операторов исходного текста.

Таким образом, метрика F отражает насыщенность программы комментариями.

Исходя из практического опыта принято считать, что Fі0.1, т.е. на каждые десять строк программы должен приходиться минимум один комментарий. Как показывают исследования, комментарии распределяются по тексту программы неравномерно: в начале программы их избыток, а в середине или в конце - недостаток. Это объясняется тем, что в начале программы, как правило, расположены операторы описания идентификаторов, требующие более «плотного» комментирования. Кроме того, в начале программы также расположены «шапки», содержащие общие сведения об исполнителе, характере, функциональном назначении программы и т.п. Такая насыщенность компенсирует недостаток комментариев в теле программы, и поэтому приведенная формула недостаточно точно отражает комментированность функциональной части текста программы.

Более удачен вариант, когда вся программа разбивается на n равных сегментов и для каждого из них определяется Fi:

Fi=sign(Nком/Nстр-0.1),

при этом уровень комментированности программы считается нормальным, если выполняется условие: F=n. В противном случае какой либо фрагмент программы дополняется комментариями до нормального уровня.

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

Таблица 4. Расчет метрики стилистики

Вариант задания №3

Код программы:

Код оптимизированной программы:

using System;

using System. Collections. Generic;

using System. Linq;

using System. Text;

using System. Threading. Tasks;

using System.IO;

namespace Test

{

public class Test

{

public static void Main (string[] args)

{

var N = 80;

var arr = new int[N];

Random rnd = new Random();

for (int i = 0; i < N; i++)

arr[i] = rnd. Next (-100, 100);

for (int i = 0; i < N; i++)

Console. Write (arr[i] + «»);

Console. WriteLine();

 // 1)

Console. WriteLine(«1) {0}», arr. Where (a => a% 5 == 0).Sum());

 // 2)

Console. WriteLine(«2) {0}», arr. Where (a => (a% 2 == 1) || (a < 0)).Sum());

 // 3)

 // i

int index = 0;

Console. WriteLine(«3) {0}», arr. Where (a => a == arr[index]).Sum());

Console. ReadKey();

}

}

}

using System;

namespace Test

{

public class Test

{

public static void Main (string[] args)

{

var N = 80;

var arr = new int[N];

Random rnd = new Random();

for (int i = 0; i < N; i++)

arr[i] = rnd. Next (-100, 100);

for (int i = 0; i < N; i++)

Console. Write (arr[i] + «»);

Console. WriteLine();

 // 1)

Console. WriteLine(«1) {0}», arr. Where (a => a% 5 == 0).Sum());

 // 2)

Console. WriteLine(«2) {0}», arr. Where (a => (a% 2 == 1) || (a < 0)).Sum());

 // 3)

 // i

int index = 0;

Console. WriteLine(«3) {0}», arr. Where (a => a == arr[index]).Sum());

Console. ReadKey();

}

}

}

Расчет метрики:

Расчет метрики:

F=5/40=0,19

F=5/37=0.17

Вывод: Уровень комментированности программы считается нормальным, потому что выполняется условие: F=n.

1.4 Исследование кода вредоносных программ

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

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

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

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

- Интернет-сайты различных команд, занимающихся написанием вредоносных программ;

- отчеты специализированных программ, предназначенных для предупреждения пользователей о возможной опасности при посещении ресурсов сети Интернет (McAfee SiteAdvisor, StopBadware);

- электронная почта;

- файлообменные сети общего пользования;

- поисковые системы сети Интернет.

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

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

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

- могут существовать несколько различающихся экземпляров одного вредоносного кода;

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

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

Основным этапом исследования является непосредственно анализ вредоносного кода. Для этого применяется reverse code engineering (RCE) - набор методик и инструментов для анализа, разработанного ПО с целью выявления его архитектуры, методов и особенностей работы. На русский язык этот термин переводится как обратное проектирование, реверсивное программирование, реинжиниринг.

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

1. проверку целостности исследуемого объекта (эту операцию могут осуществлять некоторые антивирусы, например, Антивирус Касперского);

2. проверка на наличие слоев паковки и их идентификация (PEiD);

3. распаковка, если требуется. Этот процесс зависит от использованного паковщика, наиболее популярным является UPX (upx.sourceforge.net);

4. получение информации о поведении исследуемого объекта средствами системного мониторинга;

5. контроль изменений среды, в которой выполнен исследуемый код.

Контролируемыми элементами в таком случае могут являться:

- файловая система (FileMon);

- реестр (RegMon, RegShot);

- запущенные процессы (Process Explorer);

- открытые порты (PortMon, netstat);

- сетевая активность (IRIS Network Traffic Analyzer, Ethereal);

- вызов API-функций (Kerberos, ApiMonitor, ApiSpy32);

- данные о пользователях, группах, сервисах.

6. Совместное использование дизассемблера и отладчика для более детального изучения программы (IDA; Softlce, OllyDbg).

Последним этапом в исследовании является оформление результатов. Ниже в качестве примера приведены результаты, полученные в результате исследования вредоносной программы Backdoor. Win32. Sumatrix.

Объект исследования. Троянская программа, предоставляющая удаленный доступ к компьютеру. Является приложением Windows (PE EXE-файл). Упакована с помощью UPX. Имеет размер в упакованном виде 4 608 байт, в неупакованном - 7 168 байт.

Инсталляция. После запуска вредоносная программа помещает свою копию в корневой каталог Windows под именем «rundIl32.exe». Затем в зависимости от собственных настроек троян способен добавлять следующие данные в реестр:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run] a = «%WinDir%\rundIl32.exe»

* [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]

c = «%WinDir%\rundIl32.exe» В ОС Windows NT 4.0, 2000, XP, 2003 кроме того вносятся изменения в следующие ветви реестра:

* [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]

Shell = «explorer.exe rundIl32.exe»

* [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows]

load = «%WinDir%\rundIl32.exe» run = «%WinDir%\rundIl32.exe» В ОС Windows 9x, ME модифицируются:

* секция [boot] файла «%WinDir%\system.ini»,

параметр shell = «explorer.exe rundIl32.exe» * секция [windows] файла «%WinDir%\win.ini», параметр load = «%WinDir%\rundIl32.exe» параметр run = «%WinDir%\rundIl32.exe» Также троянская программа скрывает свое присутствие в списке задач в ОС Windows 95, 98, ME.

Деструктивная активность. Backdoor. Win32. Sumatrix сочетает в себе следующие функции:

- при установке связи с сетью Интернет - отправка «хозяину» ICQ-сообщения, содержащего сетевое имя компьютера, IP-адрес, версию ОС, информацию для установки удаленного доступа (открытый порт, пароль) - функция не работоспособна;

- завершение сеанса текущего пользователя (ОС Windows NT 4.0, 2000, XP, 2003) или выключение компьютера (ОС Windows 9x, ME);

- получение сведений о местонахождении системных директорий ОС;

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

- запуск программ, указанных злоумышленником;

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

Кроме того, вредоносная программа имеет простой механизм аутентификации (по паролю).

Рекомендации по удалению:

1. завершить процесс «rundIl32.exe»;

2. удалить файл «rundIl32.exe» из каталога Windows;

3. удалить указанные выше параметры в реестре и конфигурационных файлах.

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

- создания вирусных энциклопедий в информационных целях;

- анализа существующих и развивающихся возможностей вредоносных программ и связанных с этим угроз;

- разработки сигнатур, позволяющих идентифицировать вредоносный код;

- защиты от вредоносного ПО.

Контрольные вопросы

1. К каким видам угроз безопасности относятся программные закладки?

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

Программные закладки относятся к программам с потенциально опасными последствиями.

2. Способы защиты от клавиатурных шпионов.

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

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

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

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

4. Привести пример использования «потайных дверей» не в деструктивных целях.

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

5. Привести пример использования логических «бомб» не в деструктивных целях.

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

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

2. Менеджмент программного проекта

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

2.1 Описание сценариев использования программного продукта Оценка трудоемкости и сроков разработки ПО

Сценарий - некоторая последовательность действий, иллюстрирующая поведение системы.

В разработке программного обеспечения и системном проектировании сценарии использования представляют из себя описание поведения системы, которым она отвечает на внешние запросы. Сценарии использования описывают то, «кто» и «что» может сделать с рассматриваемой системой. Методика сценариев использования применяется для выявления требований к поведению системы.

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

Сценарии использования описывают что и как конкретно должна делать система в ответ на запросы пользователей, не касаясь при этом непосредственно дизайнов интерфейсов.

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

Рисунок 3. Диаграмма работы программного продукта

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

Чаще всего вопрос трудозатрат на разработку электронного курса возникает, когда:

вы - разработчик и вам нужно сориентировать заказчика, сколько времени займет разработка курса,

вы - руководитель СДО и вам нужно спланировать загрузку сотрудников на внутреннюю разработку курсов (или бюджет или календарный план обучения по срокам и количеству курсов, которые должны быть разработаны в течение года).

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

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

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

Если говорить о методах оценки трудозатрат, то их можно разделить на три группы:

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

2. Формальные методы. Предполагают оценку трудозатрат согласно определенным алгоритмам и формулам.

3. Комбинированные методы. Методы, представляющие собой объединение формальных оценок и оценок, данных экспертами.

1. Экспертные методы.

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

Преимущества экспертных методов:

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

Предложить совместное эффективное решение проблемы;

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

Недостатки экспертных методов:

Субъективность;

Не учитываются возможности имеющихся ресурсов;

Трудоемкость;

Для корректировки начальных планов в процессе работы требуется повторное привлечение экспертов.

Метод оценки по аналогии.

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

Этапы этого метода оценки:

Определение возможных характеристик текущего проекта;

Выбор наиболее похожих, уже завершенных проектов, чьи оценки можно найти;

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

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

Расчет трудозатрат на разработку учебного плана. Этапы создания плана и примерная трудоемкость приведены в таблице 4.

Таблица 4. Примерная трудоемкость

Этапы

Трудозатраты

Разработка замысла (технического задания) курса

9

Разработка методического материала курса

38

Разработка дизайна

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

Разработка мультимедийной информации

120 часов (приведена примерная трудоемкость разработки, при условии того, что «под руками» есть все необходимые исходные данные - чертежи, фотографии и, желательно, доступ к изделию).

Разработка практических упражнений

40 часов (оценка трудоемкости приведена для 2-3 небольших упражнений на знание устройства и правил использования изделия)

Формирование модулей и слайдов курса в редакторе курсов8

24 часа

Проверка и тестирование курса

8 часов

Загрузка курса в СДО

1 час

Итого:

265

2.2 Оценка стоимости проекта

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

Рисунок 4. Распределение стоимости проекта в течение его жизненного цикла

На рисунке 3 представлены различные виды оценок стоимости проекта с указанием цели оценок и их точности. Чтобы оценить стоимость проекта, требуется знать стоимость составляющих проект ресурсов, время выполнения работ и стоимость этих работ. Таким образом, оценка стоимости начинается с определения структуры ресурсов и работ проекта. Данные задачи решаются в рамках планирования проекта (гл. 13), а в модуль оценки стоимости должны поступать результаты выполнения этого процесса.

Стоимость проекта определяется ресурсами, необходимыми для выполнения работ, в том числе:

- оборудование (покупка, взятие в аренду, лизинг);

- приспособления, устройства и производственные мощности;

- рабочий труд (штатные сотрудники, нанятые по контракту);

- расходные товары (канцелярские принадлежности и т.д.);

- материалы;

- обучение, семинары, конференции;

- субконтракты;

- перевозки и т.д.

Виды оценок стоимости проекта

Таблица 5. Виды оценок стоимости проекта

Стадия проекта

Вид оценки

Цель оценок

Погрешность, %

Концепция проекта

Предварительная

Оценка

жизнеспособности/ реализуемости проекта

Оценка жизнеспособности / финансовой реализуемости проекта

25-40

Обоснование инвестиций

Факторная

Укрупненный расчет стоимости/ предварительная смета

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

20-30

Технико-экономическое обоснование

Приближенная

Сметно-финансовый расчет

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

15-20

Тендеры, переговоры и контракты

Разработка рабочей документации

Окончательная

Сметная документация

Основа для расчетов и для управления стоимостью проекта

3-5

Реализация проекта

Фактическая

По уже реализованным работам

Оценка стоимости уже произведенных работ

0

Прогнозная

По предстоящим работа

Оценка стоимости работ, предстоящих к реализации

3-5

Сдача в эксплуатацию

Фактическая

0

Прогнозная

3-5

Эксплуатация

Фактическая

0

Прогнозная

3-5

Завершение проекта

Фактическая

Полная оценка стоимости проекта

0

Все затраты можно классифицировать как:

- прямые и накладные расходы;

- повторяющиеся и единовременные. Например, ежемесячные платежи за использование производственных мощностей - повторяющиеся затраты, закупка комплекта оборудования - единовременные затраты;

- постоянные и переменные по признаку зависимости от объема работ;

- плату за сверхурочное рабочее время.

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

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

1. Определение потребностей работы в ресурсах.

2. Разработку сетевой модели.

3. Разработку структуры разбиения работ.

4. Оценку затрат в разрезе структуры разбиения работ.

5. Обсуждение СРР (структура разбиения работ) с каждым из функциональных управляющих.

6. Выработку основного направления действий.

7. Оценку затрат для каждого элемента СРР.

8. Согласование базовых затрат с высшим уровнем управления

9. Обсуждение с функциональными управляющими потребности в персонале.

10. Разработку схемы линейной ответственности.

11. Разработку детальных графиков.

12. Формирование суммарного отчета по затратам.

13. Включение результатов оценки затрат в документы проекта.

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

Различают три вида затрат:

- обязательства;

- бюджетные затраты (сметная стоимость работ, распределенная во времени);

- фактические затраты (отток денежной наличности).

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

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

Фактические затраты отражают расходы, возникающие при выполнении работ проекта, либо в момент выплаты денежных средств.

Реальное соотношение этих видов затрат зависит от нескольких факторов, включающих в себя:

- соотношение между объемами трудовых ресурсов, материалов и субконтрактов в проекте;

- политику оплаты счетов в организации;

- период поставки основного оборудования;

- график выполнения работ по субконтрактам;

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

Понимание разницы между описанными «выражениями» затрат позволит эффективно управлять общими расходами проекта.

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

- стоимость исследований и разработок: проведение прединвестиционных исследований, анализ затрат и выгод, системный анализ, детальное проектирование и разработка опытных образцов продукции, предварительная оценка продукции проекта, разработка проектной и другой документации на продукцию;

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

- затраты на строительство: производственные и административные помещения (строительство новых или реконструкция старых);

- текущие затраты: заработная плата, материалы и полуфабрикаты, транспортировка, управление информацией, контроль качества и пр.;

- снятие продукции с производства: затраты на переоборудование производственных мощностей, утилизация остатков

2.3 Обоснование выбора вида диаграммы для динамического моделирования

Диаграммы Ганта (англ. Gantt chart, также ленточная диаграмма) - это популярный тип столбчатых диаграмм, который используется для иллюстрации плана, графика работ по какому-либо проекту. Является одним из методов планирования проектов, представляет собой изображение календарного графика задач в проекте. График Ганта является своеобразным стандартом в области управления проектами, ведь именно с его помощью появляется возможность показать структуру выполнения всех этапов проекта наглядно.

Диаграммы Ганта позволяет

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

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

- детально проанализировать реальный ход выполнения задач.

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

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

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

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

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

В электронном виде диаграмма Ганта строится с помощью таких средств, как: MS Project, MS Visio, Primavera и прочее

Основные принципы построения диаграммы:

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

a. По времени - делить на примерно равные временные промежутки;

b. По характеру работ - делить проект на различные блоки работ, отличные друг от друга по содержанию и характеру;

c. По результатам - выделить значимые, измеряемые результаты

2) Декомпозиция этапов на меньшие и конкретные работы (задачи). Если возможно, то максимально подробно, если нет - руководствуйтесь принципами из пункта 1, то есть, разделите каждый этап как минимум еще на 3 задачи.

3) Определение последовательности работ

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

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

6) Определение потребности в ресурсах:

a. людские ресурсы - определить ответственных по каждой задаче;

b. машины и механизмы;

c. помещения;

d. материалы и так далее.

7) Определение стоимости ресурсов и трудозатрат

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

Оптимизация диаграммы Ганта:

1) Рассмотрите возможность выполнения задач параллельно.

2) Определите крайние точки проекта и отдельных задач.

3) Установите связи для последовательных задач.

4) Задачи, которые можно сделать позже передвиньте в конец.

5) Определите критичный путь - последовательность задач, которая определяет длительность проекта, и рассмотрите каждую на возможность сокращения по времени.

Основные достоинства и недостатки описанного метода планирования и управления.

Главным преимуществом является графическая подача материала. Удобство работы с графиками Ганта - возможность чётко выделить и обозначить этапы работы над проектом и одновременное отображение мероприятий и сроков их выполнения. За счёт представления заданий в виде различных цветных полос все члены команды могут буквально с первого взгляда определить свои задачи.

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

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2025, ООО «Олбест» Все наилучшее для вас