Основные типовые действия администратора в Системе
Требования к программному и аппаратному обеспечению компьютера пользователя
Требования к программному обеспечению ПК пользователя:
— Windows Vista/7/8/10 или Mac OS X 10.5-10.8;
Рекомендуемые браузеры:
— Google Chrome версии 46.0 и выше;
— Mozilla Firefox версии 41.0 и выше;
— Internet Explorer версии 9 ивыше;
— Safari (для Mac OS X) версии 7.0 и выше;
— YaBrowser версии 15.9 или выше;
— Opera версии 32 или выше;
Требования к сети
Рекомендованная входящая/исходящая скорость соединения – от 256 кбит/с. Доступ к Системы осуществляется через браузер по портам TCP 80.
Требования к аппаратному обеспечению
Требования к пользовательскому аппаратному обеспечению, для работы с системой не предъявляются.
Требования к персоналу (пользователю)
Для эксплуатации Системы предъявляются следующие требования к квалификации конечных пользователей:
— опыт работы с персональными компьютерами;
— опыт использования веб-браузера.
Выполнение системы
Загрузка и запуск Системы
Конечному пользователю не требуется установка Системы. Для запуска Системы необходимо отправить заявку на сайте есмс.рф. На указанный в заявке электронный адрес будет отправлено письмо содержащее следующие данные:
В одном из перечисленных рекомендуемых веб-браузеров (см. раздел Требования к программному и аппаратному обеспечению компьютера пользователя. Рекомендуемые браузеры), необходимо перейти по полученной в письме ссылке и ввести реквизиты для авторизации (логин и пароль) в личном кабинете.
Выполнение Системы
Система является веб-приложением. Вся функциональность доступна конечному пользователю через веб-браузер и выполняется при нажатии на гиперссылки внутри самого приложения. На компьютеры конечных пользователей выводятся лишь результаты вычислений, которые происходят на серверах.
Завершение работы Системы
В Системе не предусмотрена возможность завершения работы приложения. Пользовательский сеанс считается завершенным в тот момент, когда конечный пользователь производит деавторизацию в Системе или закрывает все браузеры (окна браузеров), которые относятся к Системе.
Программное обеспечение
1 Изучите материал страницы
2 Ответьте на вопросы теста ЗДЕСЬ
Программное обеспечение (англ. software) – это совокупность программ, обеспечивающих функционирование компьютеров и решение с их помощью задач предметных областей. Программное обеспечение (ПО) представляет собой неотъемлемую часть компьютерной системы, является логическим продолжением технических средств и определяет сферу применения компьютера.
ПО современных компьютеров включает множество разнообразных программ, которое можно условно разделить на три группы (рис. 3.1):
1. Системное программное обеспечение (системные программы);
2. Прикладное программное обеспечение (прикладные программы);
3. Инструментальное обеспечение (инструментальные системы).
Системное программное обеспечение (СПО) – это программы, управляющие работой компьютера и выполняющие различные вспомогательные функции, например, управление ресурсами компьютера, создание копий информации, проверка работоспособности устройств компьютера, выдача справочной информации о компьютере и др. Они предназначены для всех категорий пользователей, используются для эффективной работы компьютера и пользователя, а также эффективного выполнения прикладных программ.
Центральное место среди системных программ занимают операционные системы (англ. operating systems). Операционная система (ОС) – это комплекс программ, предназначенных для управления загрузкой, запуском и выполнением других пользовательских программ, а также для планирования и управления вычислительными ресурсами ЭВМ, т.е. управления работой ПЭВМ с момента включения до момента выключения питания. Она загружается автоматически при включении компьютера, ведет диалог с пользователем, осуществляет управление компьютером, его ресурсами (оперативной памятью, дисковым пространством и т.д.), запускает другие программы на выполнение и обеспечивает пользователю и программам удобный способ общения – интерфейс – с устройствами компьютера. Другими словами, операционная система обеспечивает функционирование и взаимосвязь всех компонентов компьютера, а также предоставляет пользователю доступ к его аппаратным возможностям.
ОС определяет производительность системы, степень защиты данных, выбор программ, с которыми можно работать на компьютере, требования к аппаратным средствам. Примерами ОС являются MS DOS, OS/2, Unix, Windows 9х, Windows XP.
Сервисные системы расширяют возможности ОС по обслуживанию системы, обеспечивают удобство работы пользователя. К этой категории относят системы технического обслуживания, программные оболочки и среды ОС, а также служебные программы.
Системы технического обслуживания – это совокупность программно-аппаратных средств ПК, которые выполняют контроль, тестирование и диагностику и используются для проверки функционирования устройств компьютера и обнаружения неисправностей в процессе работы компьютера. Они являются инструментом специалистов по эксплуатации и ремонту технических средств компьютера.
Для организации более удобного и наглядного интерфейса пользователя с компьютером используются программные оболочки операционных систем – программы, которые позволяют пользователю отличными от предоставляемых ОС средствами (более понятными и эффективными) осуществлять действия по управлению ресурсами компьютера. К числу наиболее популярных оболочек относятся пакеты Norton Commander (Symantec), FAR (File and Archive manageR) (Е.Рошаль).
Служебные программы ( утилиты, лат. utilitas – польза) – это вспомогательные программы, предоставляющие пользователю ряд дополнительных услуг по реализации часто выполняемых работ или же повышающие удобство и комфортность работы. К ним относятся:
программы-упаковщики (архиваторы), которые позволяют более плотно записывать информацию на дисках, а также объединять копии нескольких файлов в один, так называемый, архивный файл (архив);
антивирусные программы, предназначенные для предотвращения заражения компьютерными вирусами и ликвидации последствий заражения;
программы оптимизации и контроля качества дискового пространства;
программы восстановления информации, форматирования, защиты данных;
программы для записи компакт-дисков;
драйверы – программы, расширяющие возможности операционной системы по управлению устройствами ввода/вывода, оперативной памятью и т.д. При подключении к компьютеру новых устройств необходимо установить соответствующие драйверы;
коммуникационные программы, организующие обмен информацией между компьютерами и др.
Некоторые утилиты входят в состав операционной системы, а некоторые поставляются на рынок как самостоятельные программные продукты, например, многофункциональный пакет сервисных утилит Norton Utilities (Symantec).
Прикладное программное обеспечение (ППО) предназначено для решения задач пользователя. В его состав входят прикладные программы пользователей и пакеты прикладных программ (ППП) различного назначения .
Прикладная программа пользователя – это любая программа, способствующая решению какой-либо задачи в пределах данной проблемной области. Прикладные программы могут использоваться либо автономно, либо в составе программных комплексов или пакетов.
Пакеты прикладных программ (ППП) – это специальным образом организованные программные комплексы, рассчитанные на общее применение в определенной проблемной области и дополненные соответствующей технической документацией. Различают следующие типы ППП:
ППП общего назначения – универсальные программные продукты, предназначенные для автоматизации широкого класса задач пользователя. К ним относятся:
Текстовые редакторы (например, MS Word, Word Perfect, Лексикон);
Табличные процессоры (например, MS Excel, Lotus 1-2-3, Quattro Pro);
Системы динамических презентаций (например, MS Power Point, Freelance Graphics, Harvard Graphics);
Системы управления базами данных (например, MS Access, Oracle, MS SQL Server, Informix);
Графические редакторы (например, Сorel Draw, Adobe Photoshop);
Издательские системы (например, Page Maker, Venture Publisher);
Системы автоматизации проектирования (например, BPWin, ERWin);
Электронные словари и системы перевода (например, Prompt, Сократ, Лингво , Контекст);
Системы распознавания текста (например, Fine Reader, Cunei Form).
Системы общего назначения часто интегрируются в многокомпонентные пакеты для автоматизации офисной деятельности – офисные пакеты – Microsoft Office, StarOffice и др.
методо-ориентированные ППП, в основе которых лежит реализация математических методов решения задач. К ним относятся, например, системы математической обработки данных (Mathematica, MathCad, Maple), системы статистической обработки данных (Statistica, Stat).;
проблемно-ориентированные ППП предназначены для решения определенной задачи в конкретной предметной области. Например, информационно-правовые системы ЮрЭксперт, ЮрИнформ; пакеты бухгалтерского учета и контроля 1С: Бухгалтерия, Галактика, Анжелика; в области маркетинга –Касатка, Marketing Expert; банковская система СТБанк;
интегрированные ППП представляют собой набор нескольких программных продуктов, объединенных в единый инструмент. Наиболее развитые из них включают в себя текстовый редактор, персональный менеджер (органайзер), электронную таблицу, систему управления базами данных, средства поддержки электронной почты, программу создания презентационной графики. Результаты, полученные отдельными подпрограммами, могут быть объединены в окончательный документ, содержащий табличный, графический и текстовый материал. К ним относят, например, MS Works. Интегрированные пакеты, как правило, содержат некоторое ядро, обеспечивающее возможность тесного взаимодействия между составляющими.
Обычно пакеты прикладных программ имеют средства настройки, что позволяет при эксплуатации адаптировать их к специфике предметной области.
Транслятор (англ. translator – переводчик) – это программа-переводчик, которая преобразует программу с языка высокого уровня в программу, состоящую из машинных команд. Трансляторы реализуются в виде компиляторов или интерпретаторов, которые существенно различаются по принципам работы.
Компилятор (англ. compiler – составитель, собиратель) читает всю программу целиком, делает ее перевод и создает законченный вариант программы на машинном языке, который затем и выполняется. После компилирования получается исполняемая программа, при выполнении которой не нужна ни исходная программа, ни компилятор.
Интерпретатор (англ. interpreter – истолкователь, устный переводчик) переводит и выполняет программу строка за строкой. Программа, обрабатываемая интерпретатором, должна заново переводиться на машинный язык при каждом очередном ее запуске.
Откомпилированные программы работают быстрее, но интерпретируемые проще исправлять и изменять.
Общие сведения о программном обеспечении
На рис.1.1 показаны три основные группы программных технологий. Базовые технологии по мере своего развития влияют на массовые тенденции и дисциплины, и они применяются во всех областях и направлениях программной разработки. Большинство из известных сейчас таких технологий существуют последние 25 лет. Технологические концепции и методологии объединяют базовые методики, которые используются во многих различных отраслях и продуктах. Консолидированные технологии опираются на концепции и предоставляют готовые технические решения. В тех случаях, когда технологии принадлежат к двум таким группам, они отнесены к более общей группе.
На рис.1.1 можно заметить ряд тенденций, характерных для эволюции программного обеспечения за последние годы:
Каждая из этих тенденций оказывает серьезное влияние на инженерные продукты и на формирование программной отрасли. Microsoft с Windows или Sun с Java – пример того, как отдельная компания определяет развитие технологии, но технологии от этих производителей добились успеха благодаря тому, что они создавались и широко распространялись в отраслях. Невозможно даже представить себе Windows без Intel и всей экосистемы поставщиков и провайдеров сервисов. Точно так же банки создали банкоматы и разработали множество связанных с ними программных технологий, таких как распределенная и защищенная обработка транзакций. Компании розничной торговли стимулировали разработку кассовых аппаратов и необходимого программного обеспечения для поддержки цепочки поставки, в том числе штрих-коды и средства радиочастотной идентификации ( RFID ).
Некоторые технологии прошли очень долгий период развития либо никогда не были полностью разработаны. График их перехода к широкому использованию напоминает синусоиду, что свойственно инновациям, которые переходят от этапа начальных исследований и опытных эксплуатаций к широкому отраслевому применению, а затем все повторяется снова [25]. Это объясняет, почему успешные компании практически в одночасье могут потерпеть крах – просто потому, что они своевременно не предложили определенную технологию. Программные менеджеры также часто склонны к стабилизации, а не к росту, – их интересует эффективность, и они недооценивают экспериментирование и инновации.
Программные технологии полезны, если они широко используются. Однако любая конкретная технология в одних отраслях начинает завоевывать популярность быстрее, чем в других. Хороший тому пример – долгая и трудная дорога к пользователям, которую прошли полезные пакеты инструментов для генерации кода и инженерии программного обеспечения. Когда эти пакеты появились вместе с технологией, они еще не были готовы для повсеместного применения, а позже не был готов рынок. Такой же оказалась и судьба экспертных систем и систем искусственного интеллекта. Сейчас они применяются почти везде, поскольку в отрасли осознали, что экспертная система не является автономной технологией, а должна быть интегрирована в другие продукты. На рис.1.2 показан этот эффект на примере обеспечения безопасности информации.
Ориентированность на конкретную предметную область заменила универсальность 1990-х годов. Первые CASEи распределенные компонентные модели увязли в попытках решить сразу слишком большое количество проблем. Когда в отрасли осознали, что различные предметные области имеют свои специфические потребности и скорости внедрения, то оказалось, что достаточно лишь оптимизировать технологию, предложив ее конкретному рынку. Инструменты моделирования сразу же стали пользоваться популярностью после того, как были адаптированы к потребностям конкретных предметных областей, таких как встроенные контроллеры или телекоммуникационные протоколы.
Программные процессы, как для инженерии, так и для управления, стимулировали эволюцию технологий с 1980-х годов. Сложность программных систем растет быстрее, чем люди в состоянии к ней адаптироваться. Эти трудности были уже в 1960-х годах, но тогда ситуация начала терять свою остроту после того, как ведущие отрасли перенесли свое внимание на процесс инженерии программного обеспечения. Как следствие, разработка программного обеспечения за последние 25 лет кардинально изменилась, превратившись из индивидуального творчества в дисциплину программной инженерии.
Сейчас трудно поверить, что 25 лет назад большая часть программного обеспечения и его разработчики и пользователи действовали изолированно. Программная интеграция лучше всего стала видна с появлением Интернета и его огромными темпами роста, благодаря развитию средств взаимодействия. Компонентные платформы и открытые стандарты еще больше усиливают эту тенденцию. Успешное внедрение и интеграция отнюдь не тривиальны – чтобы предложить что-то полезное инженерам, новые технологии, процессы и средства инженерии нуждаются в аппарате глубокого управления изменениями.
1.3. Качество и характеристики программного обеспечения
Рассматривая, оценивая и анализируя программные системы и отдельные программы, останавливаются на показателях качества программ и их основных характеристиках. Качество ПО – это совокупность свойств, определяющих полезность изделия (программы) для пользователей в соответствии с функциональным назначением и предъявленными требованиями. Характеристика качества программы – понятие, которое отражает отдельные факторы, влияющие на качество программ и поддающиеся измерению [23].
Каждая ПС должна выполнять определенные функции, т.е. делать то, что задумано. Хорошая ПС должно обладать еще целым рядом свойств, позволяющим успешно ее использовать в течение длительного периода, т.е. обладать определенным качеством. Качество ( quality ) ПС – это совокупность его характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей [23]. Это не означает, что разные ПС должны обладать одной и той же совокупностью таких свойств в их наивысшей степени. Повышение качества ПС по одному из таких свойств часто может быть достигнуто лишь ценой изменения стоимости, сроков завершения разработки и снижения качества этой ПС по другим его свойствам. Качество ПС является удовлетворительным, когда она обладает указанными свойствами в такой степени, чтобы гарантировать успешное ее применение.
Совокупность свойств ПС, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этой ПС, т.е. от позиции, с которой должно рассматриваться качество этой ПС. Поэтому при описании качества ПС, прежде всего, должны быть фиксированы критерии отбора требуемых свойств ПС. В настоящее время критериями качества ПС ( criteria of software quality ) принято считать:
Во многих случаях функциональность и надежность являются обязательными критериями качества ПС, причем обеспечение надежности красной нитью проходит по всем этапам и процессам разработки ПС. Остальные критерии используются в зависимости от потребностей пользователей в соответствии с требованиями к ПС.
К основным характеристикам программ и программных систем относится сложность программной системы. При оценке сложности программ, как правило, выделяют три основные группы метрик [23]:
Оценки первой группы наиболее просты и, очевидно, поэтому получили широкое распространение. Традиционной характеристикой размера программ является количество строк исходного текста. Под строкой понимается любой оператор программы, поскольку именно оператор, а не отдельно взятая строка является тем интеллектуальным «квантом» программы, опираясь на который можно строить метрики сложности ее создания.
Непосредственное измерение размера программы, несмотря на свою простоту, дает хорошие результаты. Конечно, оценка размера программы недостаточна для принятия решения о ее сложности, но вполне применима для классификации программ, существенно различающихся объемами. При уменьшении различий в объеме программ на первый план выдвигаются оценки других факторов, оказывающих влияние на сложность. Таким образом, оценка размера программы есть оценка по номинальной шкале, на основе которой определяются только категории программ без уточнения оценки для каждой категории.
К группе оценок размера программ можно отнести также и метрику Холстеда. Основу метрики Холстеда составляют четыре измеряемых характеристики программы:
– число уникальных операторов программы, включая символыразделители, имена процедур и знаки операций (словарь операторов);
– число уникальных операндов программы (словарь операндов); N1 – общее число операторов в программе;
– общее число операндов в программе.
Опираясь на эти характеристики, получаемые непосредственно при анализе исходных текстов программ, М. Холстед вводит следующие оценки:
словарь программы 
,
Как писать функциональные требования
Сегодня мы хотим рассказать о том, как наша продуктовая команда подходит к подготовке функциональных требований для разработчиков при создании новых продуктов и фич.
На этапе разработки может возникнуть много неожиданностей, особенно если не четко описать задачу. Разработку и функционирование одной и той же фичи разные участники команды могут понимать по-разному, поэтому продакт-менеджеры отвечают за создание продукта от разработки концепции до окончательного релиза. И важная часть этого процесса — подготовка функциональных требований.
Вопрос описания задач для разработчиков мы уже затрагивали в статье Как менеджерам научиться ставить задачи разработчикам, но в ней мы говорили больше про административные моменты, а сегодня речь пойдет скорее о технических. Это крайне важная составляющая любого бизнеса, продажи которого идут через интернет. Каждая компания, активно развивающаяся в интернет-среде, по сути превращается в бизнес по производству программного обеспечения. Но несмотря на это, компетенции в области управления требованиями, как правило, наращиваются очень медленно.
В результате мы часто видим одну и ту же картину: в отдел разработки постоянно падают задачи от разных отделов, требования в этих задачах описаны размыто, и как только что-то выпускается в бой – сразу же возвращается на доработку (ведь постановщик не до конца описал, что хотел, а разработчик сделал так, как посчитал нужным). Итог очевиден: непредсказуемые сроки выполнения задач, которые могут исчисляться месяцами, демотивированная команда, напряженные отношения внутри коллектива, недовольные клиенты, отставание от конкурентов и так далее.
Этой статьей мы хотим дать простой рецепт, который положит начало решению подобных проблем. Его можно смело рекомендовать к изучению (более того, к действию) всем, кто ставит задачи.
В разных компаниях существуют различные подходы к написанию функциональных требований, но в Retail Rocket мы остановились на этом варианте и пока не жалеем.
Функциональные требования: что это такое и зачем они нужны
Для начала давайте разберемся, что такое функциональные требования.
Функциональные требования — это постановка задачи разработчику. Все, что не указано в требованиях, делается на усмотрение разработчика, что часто расходится с представлением продакт-менеджер об ожидаемом результате. Поэтому требования должны содержать ответы на все возможные вопросы по задаче.
Функциональные требования, как правило, состоят из:
User story
User story описывает, что делает пользователь определенной роли для достижения результата, и что нужно сделать разработчику, чтобы воплотить эту задачу в жизнь.
Как правило используется шаблон:
Существуют различные примеры применения этой методологии. Например, так это работает в Trello:
В Retail Rocket мы создаем User Stories в Google Docs, используя таблицы. Это помогает упростить процесс коммуникации между различными командами, поскольку каждый может оставить комментарии и дать фидбек.
Например, так выглядит задача об отслеживании NPS для интернет-магазина:
Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.
Use cases
Use cases описывает поведение пользователя по шагам при взаимодействии с разрабатываемым продуктом.
Задача пользователя — это то, что делает пользователь для достижения краткосрочных целей.
Если пользователь решает задачу на разрабатываемой странице несколькими путями, то на каждое решение должен быть написан свой use case. Например, если доступ к затрагиваемому функционалу находится на нескольких страницах, нужно написать отдельный use case на каждый способ перехода пользователя к функционалу.
Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.
Цель пользователя в том, чтобы хранить изображения в нашей платформе и использовать их для создания email-кампаний.
Примеры use case’ов:
Почему функциональные требования так важны
Используя такой формат функциональных требований, вы предоставляете команде разработки четкие инструкции. Кроме того, вы можете показать, как интерфейс выглядит со стороны клиента и как он решает его задачи. Такой подход помогает презентовать вашу идею и избежать недопониманий в команде.
Обычно постановка задачи разработчикам рождает у них множество вопросов, от ответов на которые зависит сложность и срок реализации. Для уточнения деталей им приходится тратить время на коммуникацию вместо своей прямой работы — создания классных фич и улучшения продукта. И даже в процессе коммуникации не всегда выясняются все тонкости, если постановщик задачи только отвечает на возникающие вопросы, но не проходит путь пользователя сам.
Возьмем наш пример про галерею. Если бы продакт-менеджер просто пришел с задачей создать галерею, только на одном пункте про удаление файлов разработчикам пришлось бы уточнять:
Функциональные требования помогают продакт-менеджеру продумать и четко сформулировать все сценарии взаимодействия пользователя с интерфейсов в рамках задачи.
Чем точнее поставлена задача и чем больше деталей есть у разработчиков до начала работы, тем эффективнее идет работа. Не тратится время на долгую и подчас бессмысленную коммуникацию. В этом случае все стороны в выигрыше: разработчики получают четкое понимание, что и как нужно сделать, а поставщик задачи получает выполненную работу именно в том виде, в каком он ее себе представлял.
А как вы подходите к постановке задач разработчикам?