Файл: Методические указания Методические указания.pptx

Web;
Mobile;
Server-Side;
и так далее.

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

Занимается производством графической составляющей интерфейсов.
Этот человек разрабатывает визуальную часть пользовательского интерфейса. Основными целями работы UI дизайнера являются: интуитивность восприятия, простота, юзабилити и эстетика интерфейса ПО.

Quality Assurance (QA)

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

Human Resource (HR)

Занимается первичным подбором кандидатов.
Он обеспечивает прозрачное прохождение всех этапов собеседований при трудоустройстве.

Team Leader

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

Tech Leader

Отвечает за грамотный аргументированный выбор технических решений:

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

Scrum Master

Scrum, Agile, KanBan, гибкие методологии, и прочие теоретические знания, которые крайне бесполезны без практики и опыта.
Scrum Master — это специалист, который помогает команде применять методологию Scrum правильно, объясняет правила методологии, контролирует их выполнение. Сейчас к командам разработки стали прикреплять роль Scram Master. Он отвечает за грамотное применение той или иной гибкой методологии (бывает, что даже той, которая не касается Scrum вообще).

Project Manager (PjM)

Отвечает за старт, ведение и сдачу проектных работ.
Эта роль классического управленца процессами. Работа над проектом начинается с Project Manager’а, ведётся (ставит задачи), контролируется (контроль качества и эффективности) и сдаётся тоже им. В большинстве компаний Project Manager управляет проектным фондом.

Архитектор (Architect)

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

Бизнес Аналитик (Business Analyst)

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

Системный аналитик (System Analyst)

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

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

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

Причинами того, что возможности группы превышают сумму возможностей участников этой группы являются следующие факторы:

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

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

1. Введение 1.1. Наименование программы 1.2. Назначение и область применения 2. Требования к программе 2.1. Требования к функциональным характеристикам 2.2. Требования к надежности 2.2.1. Требования к обеспечению надежного функционирования программы 2.2.2. Время восстановления после отказа 2.2.3. Отказы из-за некорректных действий пользователей системы 3. Условия эксплуатации 3.1. Климатические условия эксплуатации 3.2. Требования к квалификации и численности персонала 3.3. Требования к составу и параметрам технических средств 3.4. Требования к информационной и программной совместимости 3.4.1. Требования к информационным структурам и методам решения 3.4.2. Требования к исходным кодам и языкам программирования 3.4.3. Требования к программным средствам, используемым программой 3.4.4. Требования к защите информации и программ 3.5. Специальные требования 4. Требования к программной документации 4.1. Предварительный состав программной документации 5. Технико-экономические показатели 5.1. Экономические преимущества разработки 6. Стадии и этапы разработки 6.1. Стадии разработки 6.2. Этапы разработки 6.3. Содержание работ по этапам 7. Порядок контроля и приемки 7.1. Виды испытаний 7.2. Общие требования к приемке работы

1. Введение

1. Введение
1.1. Наименование программы
Наименование программы: «АСУ «______________»»
1.2. Назначение и область применения
Программа предназначена для автоматизации обработки данных клиентов кафе/бара. Она оперирует следующими данными:
возможные персональные данные о клиент;
данные по обслуживанию клиента;
данные по дисконтной системе;
^
2.1. Требования к функциональным характеристикам
Программа должна обеспечивать возможность выполнения перечисленных ниже функций:
возможность вывода данных о клиенте по запросу;
возможность расчета скидок;
добавление/удаление клиентов;
изменение данных о клиенте;
возможность изменения дисконтной системы;

2.2.1 Требования к обеспечению надежного функционирования программы
Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:
организацией бесперебойного питания технических средств;
использованием лицензионного программного обеспечения;
регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов
Со стороны разработчика:
автоматическое создание резервных копий;
система автоматического обновления программы;
автоматическое восстановление системы;

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

^
3.1. Требования к квалификации и численности персонала
Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 1 штатной единицы — оператор ПК. В перечень задач, выполняемых оператором ПК, должны входить:
ведение базы данных по клиентам;
задачи установки (инсталляции) и поддержания работоспособности системных программных средств — операционной системы;
задача установки (инсталляции) программы;
задача создания резервных копий базы данных.

3.2. Требования к составу и параметрам технических средств ^
процессор с тактовой частотой 2.0Hz, не менее;
оперативную память объемом, 1Гигабайт, не менее;
свободное дисковое пространство не менее 1гб;
сетевая карта;

Программное обеспечение представляет из себя самостоятельное исполняемое приложение. Формат базы данных совместим с ADO.
^
Пользователи работают с базой данных через системный интерфейс.
3.3.3. Требования к исходным кодам и языкам программирования
Дополнительные требования не предъявляются.
^
Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows XP.
^
Требования к защите информации и программ не предъявляются.
3.5. Специальные требования
Специальные требования не предъявляются. ^
4.1. Предварительный состав программной документации
Состав программной документации должен включать в себя:
техническое задание;
программу и методики испытаний;
руководство оператора;

5.1. Экономические преимущества разработки
Программа является бесплатным продуктом, финансовые средства не затрачиваются, и преимуществом является ускорение автоматизации обработки данных клиентов кафе/бара
^
6.1. Стадии разработки
Разработка должна быть проведена в три стадии:
Разработка технического задания;
Рабочее проектирование;
Внедрение.
^
На стадии разработки технического задания должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания. На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ: