Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: IT_USER от 11 Сентября 2014, 14:00:41
-
Добрый день!!
В этой теме я хотел бы попробовать с вашими подсказками и рекомендациями пройти стадии выявления требований, анализа и проектирования.
Еще одно допущение: допустим, что ценность и необходимость программы уже доказана.
Умышленные Допущения и Ограничения:
На данный момент пользователи могут использовать следующие типы архивов: ZIP, RAR, TAR. Пользователи располагают свободными и коммерческими программами для работы с RAR и TAR. Но вот с ZIP бесплатных программ нет.
Уважаемые участники и жители форума! По возможности и при желании высказывайте свои предложения, замечания и критику.
-
Если вы хотите создать продукт для рынка, то классическая инженерия требований (requirements engineering) вам в этом слабо поможет, смотрите методы из продуктового управления (product management).
Современные техники создания продуктов с нуля предполагают такие фазы работ:
1. Найти и доказать ценность продукта
2. Построение бизнеса по созданию и развитию продукта
Работа по поиску и обоснованию ценности продуктов сводится к выработке и проверке гипотез о проблемах людей и возможных решениях этих проблем людей.
-
Формулировка проблемы «Отсутствие возможности работы с ZIP архивами» мне кажется надуманной.
Простой способ это проверить — выйти на улицу и спросить у первых попавшихся 30 человек, есть ли у них такая проблема.
Технари часто формулируют проблему, как отсутствие того решения, которое у них уже есть в голове.
Велосипед решает не проблему отсутствия велосипеда, а проблему дешёвого и здорового перемещения.
Отвёртка решает не проблему отсутствия отвёртки, а проблему сложности надёжного скрепления материалов.
И т.д.
-
В базовой литературе формула продукта (как заказного, так и для открытого рынка), имеет 4 компонента:
1. Чью проблему решаем
2. Какую проблему
3. Каким образом
4. Чем наше решение лучше конкурентов.
-
Ответ на вопрос «чью проблему» позволяет получить предварительную оценку размера аудитории.
Ответ на вопрос «какую проблему» позволяет уточнить размер аудитории и получить представление о важности и сложности проблемы.
Проблемой называется не любая ситуация, а лишь такая, которая ведёт к значимым для носителя проблемы последствиям. Отдельный философский вопрос — является ли неосознаваемая проблема проблемой или нет.
-
Проблемы
P1. Отсутствие возможности работы с ZIP архивами
…
Ведь по сути моя программа ничего "оригинального" не предлагает. Все то же, что есть у конкурентов (платных)
Может я чего-то не понимаю, но вроде 7-zip:
А. Бесплатная
Б. Мультиплатформенная
В. Работает с ZIP
Г. В целом терпимо
-
на маке у меня есть https://itunes.apple.com/ru/app/the-unarchiver/id425424353?mt=12
-
Добрый день, Denis.
Спасибо, что откликнулись и написали свои мысли по моей теме.
Скорее всего я не совсем верно обозначил суть задачи...
Задача заключается в следующем: понять и попрактиковаться с помощью участников этого форума в выявлении требований к ПО, созданию UseCase. Хотелось бы конечно спросить мнения живущих на форуме людей по поводу диаграмм классов и взаимодействия, кооперации... Но это позже.
В качестве примера я взял программу, которая будет работать с ZIP архивами и придумал вымышленную ситуацию в которой нет бесплатных программ по работе с ZIP. Все это конечно есть и куча написано платных и бесплатных программ...
Предлагаю опустить работы по выявлению рынка, стратегии продукта и т.д. Просто по умолчанию решено делать архиватор. Вот я и решил попрактиковаться в анализе и проектировании на примере реализации несложной программки. Думаю понятнее стало теперь)))
в Итоге вот что получается:
Необходимо разработать архиватор для работы с ZIP архивами. Постановщик требований, аналитик, архитектор, программист - это все я.
-
Может я чего-то не понимаю, но вроде 7-zip:
А. Бесплатная
Б. Мультиплатформенная
В. Работает с ZIP
Г. В целом терпимо
Это все верно, но для примера допустим, что этой программы нет)
-
Современные техники создания продуктов с нуля предполагают такие фазы работ:
1. Найти и доказать ценность продукта
2. Построение бизнеса по созданию и развитию продукта
Работа по поиску и обоснованию ценности продуктов сводится к выработке и проверке гипотез о проблемах людей и возможных решениях этих проблем людей.
Денис, предлагаю опустить все эти работы по данному направлению, так как цель создания этого топика - практика выявления требований к ПО с дальнейшим проектированием. Давайте допустим, что все это уже сделано виртуально и есть необходимость в создании такой программы
-
Необходимо разработать архиватор для работы с ZIP архивами. Постановщик требований, аналитик, архитектор, программист - это все я.
Хорошо, делайте, а мы посмотрим:)
-
ок, тогда я бы рекомендовал доработать разделы
1. Цели создания ПО
2. Назначение ПО
3. Контекст применения
и переформулировать ключевые свойства.
«Работать с ZIP» — это не фича, не потребность и не задача.
-
В продуктовой разработке рамки продукта становятся ясны после выявления ценности — в идеальном варианте, становится понятно, какую одну фичу нужно сделать, чтобы быстро выйти на рынок и получить клиентов.
В заказной разработке определить рамки ПО помогает заказчик, который приоритизирует с помощью аналитика проблемы и фичи и с помощью ПМа обрезает рамки по срокам и деньгам.
-
В вашем случае вы можете решить волюнтаристски, какие фичи делать.
Рекомендую делать не более 5-ти фич.
-
ок, тогда я бы рекомендовал доработать разделы
1. Цели создания ПО
2. Назначение ПО
3. Контекст применения
и переформулировать ключевые свойства.
Денис, я верно понимаю, что мне необходимо разработать документ VISION?
-
Ну прямо полноценную концепцию делать не надо, если у вас нет задачи обосновать инвестору эффективность проекта и логически доказать, что нужно делать именно эти фичи для достижения целей проекта.
Можно сделать её замену, которую я называю карточкой проекта.
Вот пример карточки (https://docs.google.com/document/d/1S5M6ABCR1q9JLWInbxzd63z1g_xE02PETMtCrXCdA9s/edit?usp=sharing), с заполнения которой мы начинаем на моём онлайн-курсе.
-
Ок, значит делаю "Карточку проекта".
Я просмотрел пример карточки и у меня возникли некоторые вопросы:
1. У меня получается, что заказчик отсутствует. Это может быть такое? В связи с этим вопросом автоматом вопрос про то, что писать в Целях заказчика?
2. про "Количество экранов" и "Количество отчетов". На данном этапе я точно не могу сказать сколько будет отчетов и экранов. По этому заполнил поля примерными значениями.
Еще получается, что конкурентов нет :) (Я же первый хочу создать бесплатный архиватор см. самое начало темы)
Карточку проекта я прикрепил.
-
Заказчик — это роль. Заказчик выбирает, чью и какую проблему решать. В вашем случае заказчиком выступаете вы сами или директор воображаемой вами компании-разработчика.
Цель для заказчика: Предоставить бесплатный архиватор
Пользователи: Любые пользователи компьютеров
Вот вы говорите «Я, Роман Сидоркин, хочу предоставить ВСЕМ пользователям компьютеров бесплатный архиватор».
А зачем вам это? И зачем им это? Многие люди могут себе позволить платный архиватор. Многие пользователи хотят платить за софт, чтобы получить гарантии его работоспособности. Многие пользователи мобильных компьютеров (смартфонов) не нуждаются в бесплатном архиваторе.
Как говорится, максимальный охват аудитории — только у атомной бомбы. Чем Уже размер вашей аудитории, тем больше шансов, что вы сможете по-настоящему понять её потребности и решить её проблему.
Решаемая проблема:
• Сложность просмотра и работы с ZIP архивами
Какая именно сложность? Проблема раскрывается через последствия. Если у проблемы нет последствий, связанных с нежелательными расходами ресурсов, таких как деньги, время и когнитивная мощность человека, то это не проблема.
При распаковке архива, созданного на Windows, на MacOS происходит порча имён файлов и пользователю трудно в них ориентироваться — а именно, он теряет несколько минут на выбор нужного файла и/или их ручное переименование (потеря времени)?
Встроенные средства ОС для работы с ZIP-архивами не поддерживают архивирование файлов объёмом больше 4Гб? А именно — ему приходится искать способы сначала разбить большой файл на несколько, а потом уже архивировать (потеря времени)?
Половине пользователей не удаётся понять, как сжать файл системными средствами и им приходится платить больше за трафик или хранилище в облаке или просить помочь знакомых (потеря времени, денег, репутации)? таскать на флешке с риском потери (потеря нервов, риск финансового ущерб)?
От того, какую проблему решаем, напрямую зависит состав фич.
-
Но если вам не интересна фаза бизнес-анализа, то можно идти дальше и делать контекстную диаграмму, например.
-
Денис, спасибо за ответы!
Вот что у меня получилось:
Заказчик – IT_USER (Я)
Решаемая проблема:
1.Потеря времени, связанная с необходимостью переименования распакованных файлов, в связи с порчей имен файлов, вызванная распаковкой архива.
2.Потеря времени, связанная с поиском способов разбиения большого файла на несколько в связи с невозможностью встроенными средствами Windows осуществления архивации файлов объемом больше 4Гб
3.Трудность освоения функционала по архивации и распаковке архивов ZIP встроенными средствами Windows.
В соответствии с Проблемами, получается следующий список Фичей:
1. Устранение фактов порчи имен файлов в процессе распаковки
2. Возможность задания размера сегмента, на которые будет делиться большой файл при архивации
3. Простой и легкий интерфейс упаковки и распаковки файлов
4. Возможность выбора степени сжатия, алгоритма сжатия.
5. Поддержка шифрования и парольная защита архива, так и отдельных файлов в архиве
-
Но если вам не интересна фаза бизнес-анализа, то можно идти дальше.
Мне бы не очень хотелось долго сидеть на фазе Бизнес-анализа. Но пропустить её я не хочу. Поэтому я хочу наполнить документа "Карточка проекта" данными, которые минимально или хотя бы уместно подходили бы под мою задачу. Так сказать документ на троечку чтобы... Так как в данный момент бизнес-анализ не особо интересует...
-
Немного забегая вперед...
Вот обдумываю варианты использования. Получается что на верхнем уровне абстракции у меня есть следующие варианты использования:
1. UC "Упаковка файлов в архив"
2. UC "Распаковка файлов из архива"
3. UC "Тестирование архива"
4. UC "Удаление архива"
Я верно понимаю, что такие Варианты использования, как: "Просмотр содержания архива", "Шифрование архива", "Добавление файлов в Архив", "Обновление файлов в архиве" - не нужно описывать в верхнем уровне абстракции или все возможные расширяемые и включаемые Варианты использования нужно поместить на верхний уровень... Я думаю, что добавление элементов в диаграмму нужно осуществлять поэтапно...
-
На типовой диаграмме способов применения приложения показываются все группы сценариев, которые заканчиваются ценным для пользователя результатом, который он может пойти и применять уже за рамками приложения.
-
На типовой диаграмме способов применения приложения показываются все группы сценариев, которые заканчиваются ценным для пользователя результатом, который он может пойти и применять уже за рамками приложения.
Денис, я верно понял, что в моем случае на диаграмме вариантов использования будут следующие сценарии:
1. UC "Упаковка файлов в архив"
2. UC "Распаковка файлов из архива"
3. UC "Тестирование архива"
4. UC "Удаление архива"
5. UC "Создание само распаковывающегося архива"
6. UC "Шифрование архива"
Следующие сценарии, к примеру: "Задание параметров архивации", "Выбор файлов", "Просмотр содержимого архива" , не имеют сами по себе (отдельно от контекста) ценности для пользователя, верно? (связи я не расставляю пока что... просто набросок)
-
Ответить на этот вопрос однозначно нельзя. Я рекомендую формулировки способов применения в виде «Сделать <результат>», например, «Написать письмо», «Забронировать билет». В ваших формулировках непонятно как минимум, архив — это файл или виртуальное пространство типа vault? Зачем тестировать архив? Что это за дикие пользователи такие, для которых тестирование архивов является ценным результатом?
Способы применения не появляются из воздуха, лучше их выявлять из контекстных сценариев (или бизнес-процессов). Вы пропустили важные шаги.
-
В ваших формулировках непонятно как минимум, архив — это файл или виртуальное пространство типа vault?
Значит все же необходимо написать Vision, так как там есть раздел про термины и сокращения?
Способы применения. Их выявлять из контекстных сценариев (или бизнес-процессов). Вы пропустили важные шаги.
Что именно я пропустил? Подскажите мне, пожалуйста... Какого описания у меня нет?
Возможно стоит написать пользовательские требования?
А что, Варианты использования и сценарии не описывают уже требования к ПО? Ведь с них начинается разработка...
-
Use Cases — это и есть часть пользовательских требований (функциональных).
Для продуктов для домашнего пользования я рекомендую выделять use case'ы из контекстных сценариев.
Разработайте несколько описаний жизненных ситуаций для персонажей и из них станет понятно, какие юскейсы нужны.
-
Значит все же необходимо написать Vision, так как там есть раздел про термины и сокращения?
Термины и сокращения — это типовая часть ЛЮБОГО документа, а не только концепции. Если проект большой, делается в виде отдельного документа — Глоссария. В вашем случае вы можете или ввести определение по тексту и далее его использовать, или использовать более точные формулировки, типа «Создать упакованный ФАЙЛ».
-
Денис, я верно понимаю, что в моем случае лучшим выбором станет Гибкая методология разработки ПО? Я спрашиваю это в связи с тем, что Истории пользователей - артефакт, фигурирующий в AGILE и XP...
-
А кто сказал слово «история»?
Context Scenario, Usage Scenario, Use Case и User Story — это 4 разных человека. Я говорил про первый.
-
Разработайте несколько описаний жизненных ситуаций для персонажей
Вот что у меня получилось:
1.Как пользователь я могу создать архив и поместить в него один, несколько файлов или всю директорию для уменьшения места на диске.
2.Как пользователь я могу выбрать степень сжатия при создании архива, что бы наиболее эффективно использовать свободное место на диски и уменьшить объем архива для дальнейшего его перемещения на дискету, диск или флешку.
3.Как пользователь я хочу просматривать архив, выбирая файлы и директории, которые необходимо вытащить из него при необходимости
4.Как пользователь я хочу распаковывать содержимое, как всего архива, так и отдельных файлов с целью работы с ними или иного использования
5.Как пользователь я хочу защитить архив или отдельные файлы в архиве с целью предотвращения несанкционированного использования моих файлов и информации
6.Как пользователь я хочу работать с удобной и легкой для освоения программой.
7.Как пользователь я хочу, чтобы в случае каких-либо ошибок и сбоев мои данные не исчезли.
-
Это перечень пользовательских требований в формате неполных пользовательских историй (без очень полезного компонента «зачем»), а не контекстные сценарии.
Вы свалились ещё глубже по процессу.
-
Context Scenario, Usage Scenario, Use Case и User Story — это 4 разных человека. Я говорил про первый.
Вы меня пряма запутали... из всех слов мне не понятно только Context Scenario... Остальные это Вариант использования, сценарий использования и история пользователя
-
Статьи про контекстные сценарии:
http://peredelka.wordpress.com/2011/11/08/3-10-%D0%BA%D0%BE%D0%BD%D1%82%D0%B5%D0%BA%D1%81%D1%82%D0%BD%D1%8B%D0%B5-%D1%81%D1%86%D0%B5%D0%BD%D0%B0%D1%80%D0%B8%D0%B8-%D0%B2%D0%B7%D0%B0%D0%B8%D0%BC%D0%BE%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8/
https://confluence.sakaiproject.org/display/SLIB/Example+Context+Scenario
http://www.slideshare.net/pablohart/creating-context-scenarios
-
Мне кажется я запутался... И не совсем понимаю в какой последовательности что писать. Вы можете мне помочь вернуться на "верную дорогу"? Я все же хочу разобраться во всем, чтобы не было двусмысленностей... ???
-
Например, если вы хотите поработать с «требованиями» в формате Agile то можно остановиться на том списке 1-7, который вы написали выше.
Если вы хотите написать требования к ПО в формате IEEE 830 (http://school.system-analysis.ru/wp-content/uploads/2014/09/IEEE-830-1998.-%D0%9C%D0%B5%D1%82%D0%BE%D0%B4%D0%B8%D0%BA%D0%B0-%D1%81%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-%D1%81%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D0%B9-%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B9-%D0%BA-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%BC%D1%83-%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8E.pdf), то там много возможных работ.
Если вы хотите написать требования в формате Вигерса (http://analyst.by/attaches/srs_template.doc), то там тоже много возможных работ.
Вам какой вариант интереснее?
-
Вам какой вариант интереснее?
Мне бы хотелось и попробовать вариант Вигерса и AGile. Я так понимаю, что для AGILE я уже написал...
Вот что у меня получилось:
Василий, прейдя с работы и сев за компьютер, выходит в Интернет. Долго ходит по страницам, читает новости, проверяет почту, ищет новые программы… И вот однажды находит на просторах Интернета программу – архиватор ZIPARCH. В описании к ней он вычитал, что она бесплатная и поддерживает работу с архивами ZIP. Василий скачал её и обрадовался тому, что устанавливать её совсем не надо. Она готова к работе сразу из места сохранения её на диске пользователя. Василий два раза щелкнул на ярлык и запустилась программа. Василий сразу разобрался с интерфейсом программы и решил попробовать поместить в архив несколько файлов. Василий выбрал пункт меню создания архива. Программа открыла небольшое окно в котором Василий выбрал путь к новому архиву и ввел его имя. Далее Василий указал несколько файлов, которые он хотел бы видеть в архиве и нажал на кнопку архивации. Скорее всего в связи с небольшим объемом файлов, программа мгновенно проинформировала Василия о благополучном создании архива. Василий открыл папку, которую от указал в параметрах и действительно нашел там архив ZIP. Так как у него на компьютере были и иные архиваторы (платные) он смог открыть новый архив и удостовериться в том, что там те файлы, которые должны быть. Далее Василий решил проделать все тоже самое, но изменив степень сжатия и алгоритм шифрования. Программа выполнила все что требуется! Следующим этапом освоения Василием программы стала проверка распаковки созданного этой же программой архива. Он выбрал в программе пункт извлечения файлов, указал путь к архиву и нажал кнопку извлечения. В итоге проделанных действий, Василий получил в папке которую указал еще одну папку – в которой содержались файлы из архива. На следующий день, Василий решил за архивировать файлы с работы и поставить на них пароль. Процедура была очень простая: указал путь к архиву, перечислил файлы для архивации и указал пароль. Если Василий при создании архива не указал имя и путь, то программа выводила предупреждение и Василий вводил требуемые данные. Программа выводила предупреждения и в случаях когда Василий не указывал имя архива при извлечении файлов, не указывал пароль к защищенному архиву. На работе архив замечательно открывался, и Василий работал с созданным архивом даже при использовании стороннего архиватора.
-
Еще вопрос: Так вот эти контекстные сценарии к какому из мной предпочитаемых вариантов подходят?
Можно ли параллельно до какой-то точки пробовать работать с требованиями по AGILE и Вигерсу одновременно?
-
Обратите внимание, что ваш контекстный сценарий описывает, как гик нашёл программку и баловался с ней, а не то, как у здорового нормального человека (шучу) возникла потребность и он её решил с помощью вашего архиватора.
Он смог запаковать! Он смог распаковать! ЗАЧЕМ???
Решайте значимые проблемы людей, а не (только) играйтесь с технологиями.
Если девушка Алиса хочет послать реферат на 30 Гб однокурснице, а он не пролазит в почту — вот реальная ситуация, в которой её может спасти архиватор (и не только).
Программы должны решать реальные проблемы людей, иначе весь процесс разработки требований превращается в фантазирование по применению одних технологий, не несущих ценности (например, задействование всех 9 диаграмм UML) для создания других технологий, не несущих ценности.
Поднимитесь уровнем выше, не проектируйте детальное взаимодействие с ПО, опишите сначала, как программа помогает в различных жизненных ситуациях.
-
Еще вопрос: Так вот эти контекстные сценарии к какому из мной предпочитаемых вариантов подходят?
Можно ли параллельно до какой-то точки пробовать работать с требованиями по AGILE и Вигерсу одновременно?
Требования не возникают из воздуха, они ВЫЯВЛЯЮТСЯ. Анализ контекстных сценариев — это одна из множества техник выявления требований. Эта техника может применяться как в Agile, так и в классическом подходе к работе с требованиями.
Формально в Agile требований нет, есть поводы для разговора — User Story. User Story как единица функциональности может иметь различный набор приложений, поясняющих её — макеты интерфейсов, тесты, бизнес-правила. Вот только по идеологии Agile создавать такие приложения в отрыве от команды нельзя, они делаются под конкретный коллектив по необходимости.
В отличие от них, в классической разработке требований могут создаваться отдельные документы разных уровней, такие как бизнес-требования, концепция, техническое задание, технический проект, которые в принципе предполагают допустимость ситуации, что точный потребитель требований заранее не известен, и поэтому они должны быть выполнены на определённом уровне качества.
-
Какую технологию разработки требований применяю я:
1. Предварительные исследования и проблематизация
Выявление заинтересованных лиц
Изучение и описание автоматизируемой деятельности
Изучение системы понятий, существующих в предметной области
Разработка концептуальной модели предметной области
Создание словаря терминов
Исследование и описание проблемных ситуаций
Создание целостной модели проблемы
2. Разработка бизнес-требований
Постановка целей преобразований/автоматизации
Определение перечня процессов и бизнес-функций, которые должны быть автоматизированы/улучшены
Определение целевых показателей процессов
Определение перечня задач пользователей
Определение организационных ограничений
3. Создание концепции приложения/системы
Определение границ системы
Определение ключевых возможностей системы
Определение приоритетов свойств системы
3. Разработка пользовательских требований
Описание ролей пользователей
Разработка сценариев решения задач пользователем
Уточнение предположений о характеристиках пользователей
Разработка требований к качеству в использовании
4. Разработка технических требований к ПО
Разработка реестра функциональных требований
Разработка диаграммы и словаря данных
Разработка требований к внешнему качеству системы
Описание интерфейсов взаимодействия с окружением
Уточнение технических ограничений и предположений
-
Денис, доброго времени суток!
Надеюсь, что теперь контекстные сценарии описывают не балавство)
Имя персонажа №1: Михаил Иванов.
Краткая информация о персонаже №1: он студент, учится на 1 курсе.
Контекстный сценарий для Михаила Иванова
1. Михаил очень отзывчивый человек и часто готов прийти на помощь. Он хорошо учится и по этому у него хорошая успеваемость, но за это он расплачивается отсутствием свободного (личного) времени. Большая часть времени уходит на изучение и работу над выполнением институтских заданий. Обычно во время сессий и экзаменов Михаил пользуется большим спросом среди своих однокурсников. Часто приходится пересылать большие объемы данных по почте или на сменных носителях. Недавние проблемы с отправкой больших файлов, Михаил решил путем использования бесплатного и эффективного архиватора ZipArch.
2. Михаил отправляет по возможности свои примеры курсовых работ и лекций своим однокурсникам – лентяям в архиве, что значительно сокращает размер исходных файлов. Заботясь о том, чтобы не было лишних вопросов, Михаил часто прибегает к использованию самораспаковывающихся версий архивов. Это полностью решает частые проблемы, связанные со звонками и просьбами помочь открыть архив. Так как зачет уже завтра, а прочесть и вникнуть в лекции Михаила нужно уже сегодня.
3. Друзья Михаила, узнав о существовании программы ZipArch, о которой собственно и рассказал сам Михаил тоже стали пользоваться этим архиватором. Теперь Михаил и его друзья, кто обладает этим архиватором обмениваются картинками, лекциями и прочим интересным материалом. Михаил иногда пересылал свои стихи лучшим друзьям для критики в архиве с паролем – тем самым защищая данные от несанкционированного использования.
4. При помощи программы ZipArch Михаил может пересылать в сжатом (запакованном) виде не только отдельные файлы, но и каталоги с подкаталогами.
Имя персонажа №2: Васин Глеб Петрович.
Краткая информация о персонаже №2: сотрудник частной фирмы
Контекстный сценарий для Васина Глеба Петровича
1. Глеб Петрович Васин – недавно работает в частной организации. Он рядовой сотрудник. В эго фирме применяется политика использования только лицензионного программного обеспечения. В связи с этим на компьютерах стоит оригинальная операционная система и простенький офисный пакет от известного бренда. Ставить что-то не лицензионное не допускается. В связи с тем, что Глеб Петрович новый сотрудник, то компьютер ему достался от предыдущего коллеги, которого уволили. ИТ отдел удалил всю информацию с компьютера, переустановил операционную систему и подготовил рабочее место. В связи со спецификой работы, Глебу часто приходится передавать файлы больших объемов по сети. Это порождает большие нагрузки на сетевое оборудование, трата времени. На фирме есть коммерческий архиватор, но он установлен только у босса. Глеб долго мучился с проблемами передачи по сети, по почте больших объемов данных, пока не нашел бесплатную программу ZipArch. Так как этот архиватор был бесплатным, то его использование не противоречило политике безопасности.
2. Глеб легко установил архив и стал его использовать для своих рабочих обязанностей. Программа быстро архивировала и эффективно сжимала файлы.
3. Вскоре Глеб стал рекомендовать ставить эту программу своим коллегам. Коллеги быстро разобрались с интерфейсом программы. Этот архиватор решил проблемы коллектива, связанные с пересылкой огромных объемов документов.
4. Босс, узнав о новой программе, был приятно удивлен и разрешил использование в фирме этой программы. Также он ввел порядок по созданию и шифрованию архива. Теперь вся конфиденциальная информация шифровалась и использовалась внутри организации.
5. Для отправки особых документов клиентам фирмы, сотрудники использовали самораспаковывающиеся архивы, а также архивы с паролем.
-
АУУУУУУУУУУУУУУ!!! где советчики?)) ???