DevBuzz - Ресурс для Менеджеров проектов, Системных аналитиков, и Веб-разработчиков

Почему я люблю свою профессию?

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

Поэтому при знакомстве с блондинками я просто говорю, что я айтишник, тем более, что если меня спросят подробности, например, что я сегодня делал — я вряд-ли смогу объяснить.

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

Я учился в физико-математическом классе экспериментальной гимназии, дальше — поступил в 3 разных ВУЗа и в итоге получил образование программиста в МГТУ им.Баумана в Москве.

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

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

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

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

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

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

Мне нравится, а Вам?

Интернет-магазин — хороший инструмент продаж.

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

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

Критериями выбора думаю должно быть следующее:

— цена движка

— граммотная архитектура, позволяющая дополнять движок модулями и обновлять его безболезненно

— наличие коммьюнити — сообщества профессионалов различной направленности, работающих с этой платформой и к которым можно обратиться за необходимыми доработками

— функционал, предоставляемый из коробки

Наиболее распространенны следующие платформы для создания веб-магазина:

— Webasyst Shop-Script

— Magento

— Joomla Virtuemart

— OpenCart

— Bitrix

Рассмотрим каждую из них поподробней:

Webasyst Shop-Script

Российский производитель. Изначально заточен под российский рынок. Из коробки имеет такой функционал, как поддержка всех распространенных служб доставки и систем приема платежей, интеграция с 1С:Управление торговлей 8.1 и т.п.

Движок прост в дорабтке, поэтому легко расширяем.

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

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

Magento

Движок мирового уровня. Создан в Украине, очень быстро набравший популярность и известность. На сегодня принадлежит компании eBay и используется крупнейшими компаниями в качестве решения для создания интернет-магазина. Имеет очень гибкую архитектуру, за счет чего возможно очень серьезное наращивание движка без боязни приостановки работ в случае большого количества изменений. За это приходится платить большой ресурсоёмкостью движка — он потребляет много ресурсов и нужно приложить усилия, чтобы заставить его работать быстро.

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

Magento имеет бесплатную версию Community Edition, а также платные версии Enterprise Edition, Enterprise Premium Edition.

Также существуют сборки, например Российская сборка Magento, адаптированная под российский рынок.

Joomla Virtuemart

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

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

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

OpenCart

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

Продолжение следует…

Вначале скажу, что если нужна единая идентификация, то нужно смотреть в сторону OpenID. И вот хорошее видео, в котором объясняется, что это такое:

http://www.youtube.com/watch?v=1BbHQNnK9ds

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

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

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

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

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

Это заключается в регистрации, т.е. как правило создании как минимум логина и пароля.

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

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

Второй вопрос, который возникает — дублирование личной информации от сервиса к сервису. Например, многие сервисы требуют email пользователя, его ФИО и т.п. Для этого есть возможность заполнить дублируемую информацию единожды опять же там же, где создавался логин и пароль и по запросу выдавать эту информацию другим сервисам, в которых мы регистрируемся. При этом пользователь уже не должен вводить заново повторяющуюся информацию, а только определяет, желает ли он предоствить ту или иную информацию данному сервису из уже заполненных ранее данных.

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

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

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

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

Сценарии использования

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

Теперь нам нужно описать, каким образом пользователь будет получать этот результат в системе.

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

Главное окно

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

Непосредственно сценарии

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

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

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

Запутал окончательно? Тогда пример:

Задача:

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

Сценарий:

1. Пассажир в главном окне системы нажимает кнопку Наличие мест.

2. Система отображает окно.

Здесь нужно привести некоторый прототип этого окна. В нем должны быть продуманы основные, а желательно все поля, таблицы, кнопки, которые потребуются пользователю для того, чтобы сделать следующий шаг. А следующим шагом в нашем примере является логично выбор маршрута, на который пассажир хочет выяснить наличие мест. Каким образом пассажир может выбрать требуемый поезд? Указав некоторые его параметры — период времени, в который этот поезд отправляется, откуда пассажир будет уезжать и куда ему нужно попасть. Также он может указать номер поезда. Номер поезда — это его маршрут, поэтому это альтернатива только части параметров — пункту отбытия и пункту прибытия. Т.е. окно у нас может состоять из следующих элементов:

— Выбор одного из двух параметров:

— станция отбытия и станция прибытия

— номер поезда

— Даты От и До отправления поезда

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

Номер поезда — текстовое поле.

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

Также должна быть кнопка, нажатие на которую инициирует поиск. Назовем её (как это ни странно) «Поиск».

Всё это мы рисуем удобным нам способом и вставляем прототип окна в наш документ.

И описываем, что означают эти наши поля.

Продолжаем с нашим сценарием:

3. Пассажир вводит параметры искомого рейса и нажимает кнопку «Поиск»

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

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

— номер поезда

— пункт начала маршрута / пункт конца маршрута

— дата отбытия из пункта отправления пассажира

— время отбытия из пункта отправления пассажира

— дата прибытия в пункт прибытия пассажира

— время прибытия в пункт прибытия пассажира

— количество свободных мест типа плацкарт/купе/люкс

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

6. Пассажир выбирает наиболее подходящий ему поезд и нажимает на строку этого поезда

7. Система отображает окно с подробной информацией о свободных местах в выбранном поезде

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

Я думаю, что было бы удобно получить информацию с разбивкой по вагонам и с разбивкой по типам вагонов. Т.е. страница будет состоять из блоков, каждый из блоков начинается с номера вагона и его типа (плацкарт/купе/люкс). Далее либо можно просто написать количество свободных мест в данном вагоне, либо написать количество свободных мест по типам мест верхних/нижних/верхних боковых/нижних боковых, либо указать все номера мест от 1 до N и для каждого места указать — свободно или занято.

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

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

Вот и всё, наш сценарий описан.

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

Точно также описываем все остальные сценарии использования.

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

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

Кто я?

Друзья, хочу начать с философского вопроса: а что же основное в создании информационной системы? Что мы создаем?

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

Ну вот, так как же нам описать систему так, чтобы ничего не забыть?

Цели

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

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

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

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

И т.д.

Бизнес-процессы

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

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

Типы пользователей

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

Получается, что для описания системы, нам нужно знать, кто будет пользоваться системой. Конечно здесь имеются ввиду не имена конкретных пользователей — Иван Петрович, Василь Семеныч, а их роли — типы пользователей. Можно это назвать еще должностью человека в системе. Т.к. роль будет определять набор результатов, которые этот пользователь хочет получить от системы. Например: менеджер по продажам, бухгалтер, анонимный посетитель сайта, зарегистрированный посетитель сайта, администратор системы, руководитель компании, клиент и т.д. Все эти пользователи (роли, типы пользователей) будут пользоваться системой для получения несколько различных результатов. Хотя некоторые их потребности могут и совпадать.

Варианты использования системы

Еще нам нужно знать сами результаты, которых хочет достичь каждый тип пользователя, используя нашу систему. После того, как мы знаем, кто будет пользоваться системой, мы для каждого типа пользователя даем название каждому результату, который он должен получать, используя нашу будущую систему. Например, это может быть «Учет прихода товара», или «Поиск отеля», или «Создание нового пользователя», «Получение отчета о финансовых показателях». Мы называем возможности пользователя в системе. Или еще можно сказать, его должностные обязанности по работе с системой.

Сценарии использования

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

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