Добавлен: 23.11.2023
Просмотров: 66
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
2. Краткий отчет о практике
В настоящее время Синергия – один из крупнейших частных экономических вузов страны. В структуре университета 10 факультетов и 58 кафедр. Обучение осуществляется в рамках всех возможных форматов: очного, заочного, вечернего, выходного дня, дистанционного. Преподавательскую деятельность осуществляют около 600 докторов и кандидатов наук, аспирантов, экспертов. Студенческий состав насчитывает 35 000 человек. 48 представительств и филиалов МФПУ «Синергия» работает в России и странах СНГ, а также в Великобритании, Сингапуре, США, Израиле и ОАЭ. К настоящему моменту выпускниками вуза является около 70 000 человек.
Миссия университета «Синергия» – содействовать успеху людей и организаций. В обучении соблюдаются такие ключевые принципы, как индивидуальный подход к студенту, построение программ обучения с учетом последних трендов в бизнесе, практическая направленность обучения. Абитуриент может выбрать удобную ему форму обучения, включая дистанционное, чтобы наиболее полно использовать потенциал вуза и раскрыть свой собственный.
Предметную область можно определить, как сферу человеческой деятельности, выделенную и описанную согласно установленным критериям. В описываемое понятие должны входить сведения об ее элементах, явлениях, отношениях и процессах, отражающих различные аспекты этой деятельности. В описании предметной области должны присутствовать характеристики возможных воздействий окружающей среды на элементы и явления предметной области, а также обратные воздействия этих элементов и явлений на среду. Работа по изучению и анализу предметной области: проектировании интеллектуальных систем оказывает решающее влияние на эффективность ее работы.
Специфика предметной области может оказывать существенное влияние на характер функционирования проектируемой интеллектуальной системы, выбор метода представления знаний, способов рассуждения о знаниях, и т. д.
Предметную область можно определить, как объект или производственную систему со всем комплексом понятий и знаний о ее функционировании. При исследовании проблемной области необходимы знания о задачах, решаемых в производственной системе, и стоящих перед ней целях. Определяются также возможные стратегии управления и эвристические знания, используемые в процессе эксплуатации производственной системы.
Одна из первых задач, с решением которых сталкивается разработчик программной системы - это изучение, осмысление и анализ предметной области. Дело в том, что предметная область сильно влияет на все аспекты проекта: требования к системе, взаимодействие с пользователем, модель хранения данных, реализацию и т.д.
Анализ предметной области, позволяет выделить ее сущности, определить первоначальные требования к функциональности и определить границы проекта. Модель предметной области должна быть документирована, храниться и поддерживаться в актуальном состоянии до этапа реализации. Для документирования могут быть использованы различные средства.
Для управления обсуждением области действия проекта можно использовать методику «будет - не будет». В простейшем случае - это список с двумя столбцами, в одном из которых записывается, что проект будет делать, а во втором - что не входит в проект. Такой список, формируется заинтересованными лицами при рассмотрении каждой бизнес-цели проекта, используя любую технику, например метод «мозгового штурма». Полученные характеристики позволяют четко определить границы проекта и довольно просто преобразуются в предположения, которые фиксируются в документе.
Функциональная область действия определяет услуги, предоставляемые системой, и вначале до конца неизвестны. В определении услуг системы может помочь список «Действующее лицо/Цель», в котором перечислены все цели пользователя, поддерживаемые системой. При его разработке в первую графу вписываются имена основных действующих лиц, т.е. тех, кто имеет цели, во вторую графу - цель каждого действующего лица, а в третью - приоритет или предположение о том, в какую версию войдет эта услуга.
Для определения основных функций продукта можно использовать, например, краткое описание варианта использования. Описание каждой функции можно представить также в виде списка, состоящего из трех граф: действующее лицо, цель и краткое описание варианта использования.
Анализ предметной области является основой для анализа осуществимости проекта и определения образа (концепции) продукта и границ проекта.
Разработка новых программных систем должна начинаться с анализа осуществимости. На основании анализа предметной области, общего описания системы и ее назначения необходимо принять решение о продолжении или завершении проекта. Для этого необходимо ответить на следующие вопросы.
Отвечает ли система бизнес-целям организации-заказчика и организации-разработчика?
Можно ли реализовать систему, используя известные технологии и не выходя за пределы заданной стоимости и заданного времени?
Можно ли объединить систему с другими уже эксплуатируемыми системами?
Для ответа на первый (и главный) вопрос нужно опросить заинтересованных лиц, например, менеджеров подразделений, в которых будет использоваться система, для выяснения того,
-что произойдет с организацией, если система не будет введена в эксплуатацию;
-как система будет способствовать целям бизнеса;
-какие текущие проблемы поможет решить система и т.д.
После получения и обработки информации готовится отчет, в котором должны быть даны рекомендации относительно продолжения разработки системы.
Постановку бизнес-задачи надо обсуждать с Заказчиком, или будущим Владельцем системы.
Вопросы, которые ему стоит задать, это:
Почему вообще пошла речь о создании системы?
В чём Вы видите её назначение?
Какие бизнес-возможности она должна реализовать?
Какие проблемы должна решить?
В качестве «Стандарта» на вопросы такого рода смотрите шаблон документа «Stakeholder Request», например, из RUP. Бизнес-требования может выразить Заказчик или Эксперты предметной области. Они обычно фиксируются в виде списка из 10-30 ключевых свойств продукта - в качестве шаблона см. Vision из RUP.
Бизнес-моделирование надо проводить на основе информации от, а лучше совместно с экспертами предметной области. Вопросы по сути сводятся к «Что, почему, когда, как и кем происходит в предметной области и как оно взаимосвязано?»:
Каковы основные понятия предметной области, их определения и взаимосвязи? Результат можно оформить в виде глоссария и/или концептуально-семантической модели предметной области.
На основании каких правил - международных, федеральных, муниципальных, районных и т.д. законов, указов, стандартов, спецификаций, регламентов и т.д. - происходит то, что происходит в предметной области? Результат оформляете в виде структурированного списка или прикрепляете к элементам концептуальной модели.
Что реально (какие процессы, события, факты) происходит и в какой последовательности, взаимосвязи? Результат оформляете в виде сценариев описания бизнес-процессов (что достаточно универсально) или диаграмм SADT (IDEF0, IDEF3, DFD) / ARIS (eEPC и т.д.) / UML (Business Use-case Diagram (BUC) + Activity Diagram + Sequence Diagram). Это один из сложнейших этапов.
Какими свойствами обладает каждое из выделенных понятий - структурными и поведенческими? Результат описывается в виде таблиц с атрибутами Концептуальных сущностей или Детальной концептуальной моделью - ER - IDEF1X / UML Class Diagram (BOM).
Существует российский стандарт функционального моделирования P 50.1.028-2001, созданный на основе IDEF0.
Определение требований - частично Бизнес-требования и Требования, проистекающие из предметной области вы уже определили выше, теперь осталось исследовать Пользовательские требования и Системные требования и ограничения к отдельным аспектам качества системы. Пользовательские требования, как можно понять, нужно выявлять из общения с потенциальными пользователями системы. Вопросы:
На какую систему будет похожа создаваемая?
С какими системами и как давно вы работаете?
Какое у вас образование?
Каковы ваши ожидания от системы - что и как она должна делать, какие задачи помогать решать, как должна выглядеть?
Какие шаги необходимо предпринять для решения каждой задачи?
В каком случае вы будете считать, что система «Хороша»?
Результаты анкетирования/интервьюирования обычно представляют в виде пользовательских историй (User Story, Agile) или Пользовательских сценариев (Use-case), также возможно их диаграммное представление средствами диаграмм потока работ (IDEF3), ARIS, Activity/State UML Diagram. Подробнее про работу с Пользователями могут рассказать специалисты по Проектированию взаимодействия, интерфейсам и эргономике.
Системные требования нужно выяснять у IT-специалистов Заказчика, если таковые имеются, из специфики контекста использования системы, опыта построения аналогичных систем (у IT-Экспертов-Архитекторов) и Специалистов по отдельным аспектам системы, значимым для данного проекта (Юристы, Эргономисты, и т.д.) и Заказчика:
Будет ли система единичной или тиражируемой?
В каких странах она будет работать?
Насколько важна информация, хранящаяся, обрабатываемая и передающаяся системой?
Каков возможный ущерб от потери той или иной информации?
Сколько пользователей будет работать с системой сегодня, завтра, через год?
Переработанный результат оформляется в виде Системных требований (Software Requirement Specification, стандарт IEEE-STD-830-1998, или ТЗ ГОСТ 34-602-89 или неформально в виде Supplementary Specificaion из RUP).
Приложения для настольных компьютеров подобны широкоугольным объективам в том смысле, что в типичных случаях они отображают значительный объем информации, который позволяют предоставлять пользователю экраны большого размера. В отличие от этого мобильные приложения напоминают увеличительное стекло или объектив с переменным фокусным расстоянием. Они предоставляют пользователю возможность быстро просматривать необходимые подробные данные, быстро переходить к ограниченным наборам данных и получать к ним доступ, а также принимать решения в реальном масштабе времени. Как правило, мобильные приложения пре доставляют более специализированный набор сценариев по сравнению с приложениями, ориентированными на настольные компьютеры. Очень важно точно определиться с тем, на каких сценариях должно специализироваться ваше приложение.
Прежде чем приступать к реальной разработке приложения, определите подмножество функциональных средств, к которым пользователь сможет получать быстрый доступ в манере, свойственной мобильным устройствам. В случае создания нового приложения, аналога которого для настольных компьютеров не существует, выпишите ключевые сценарии, которые пользователи смогут выполнять с помощью вашего приложения, а также порядок действий пользователя, обеспечивающий использование этих сценариев на мобильном устройстве. Во многих случаях вам будет легче придать этим сценариям реальные очертания, если вы подготовите соответствующие рисунки или создадите прототипы. Если подразумевается определенная группа конечных пользователей, пообщайтесь с ними и предоставьте им возможность поработать некоторое время с экспериментальными версиями своих приложений, чтобы они могли дать о них свои отзывы.
Для всех проектов разработки программного обеспечения, кроме самых тривиальных, важно иметь единственный «руководящий документ», в котором определяются:
-требования проекта и целевое назначение завершенного продукта;
-философия проекта;
-архитектура приложения;
-текущее состояние работ в данном направлении;
-план, в соответствии с которым продукт будет переводиться из его текущего состояния в состояние успешного завершения.
Для крупных проектов могут предусматриваться дополнительные документы, но всегда должен существовать один основной документ самого верхнего уровня, в котором определяются основные цели проекта, его нынешнее состояние и план работ. Этот документ должен быть реально действующим документом, который, по мнению всех участников группы, правильно определяет направления работы.
Единственный руководящий документ, который управляет всем процессом разработки, должен включать несколько разделов:
Цели проекта. В этом разделе основного документа должно быть ясно указано, для чего предназначается завершенный продукт, и какая философия лежит в основе проекта.
Состояние проекта. Этот раздел основного документа содержит точное описание текущего состояния проекта. Он является частью календарного плана проекта и позволяет судить о степени приближения работ над проектом к завершению. Здесь должны быть определены контрольные точки проекта, на достижение