![[icon]](http://l-userpic.livejournal.com/91586538/593145) |
Системный анализ в Разработке ПО и Другие
|
| При выполнении проекта по разработке ПО почти всегда речь идет только о документе «техническое задание». Однако существует другой, не менее важный документ, предшествующий техническому заданию — это концепция.
Темы данного семинара: 1. Понятие концепции (vision). Место концепции в жизненном цикле разработки ПО 2. Взаимосвязь концепции с артефактами проекта по разработке ПО 3. Структура концепции 4. Примеры документа "концепция" в различных методологиях разработки ПО 5. А у нас все не так! (ответы на вопросы)
Докладчики: Векленко Ирина и Сурова Ирина
Дата и время проведения: 26 ноября 2009 года с 19:00 до 21:30
Место проведения: Москва, Архангельский переулок, 1/1/9, строение 1, офис 423. Компания «Заказные ИнформСистемы».
Регистрация | comments: 3 comments or Leave a comment  |
| 12 ноября отмечается Всемирный День Юзабилити (см. http://worldusabilityday.org). Этот праздник проходит уже в пятый раз по всему миру. В этот же день на сайте WorldUsabilityDay.ru состоится онлайн-семинар Аарона Маркуса.
А 14 ноября, в субботу, в Москве пройдёт бесплатная конференция World Usability Day 2009, посвященная этому празднику. На неё приглашены в качестве докладчиков: Влад Головач, Артем Горбунов, Андрей Бибичев и другие известные специалисты — всего будет 11 докладов, а также несколько блиц-докладов и мастер-классы от Екатерины Сугак и Дмитрия Сатина.
Полный текст программы можно посмотреть на wud2009.ru/programm/
Среди участников конференции будет много специалистов по интерфейсам со всей России, в том числе Платон Днепровский, Андрей Сикорский и Митя Павлов.
На конференции ожидается чай с плюшками, компьютеры Apple в избытке и свободном доступе и много полезного общения! :)
В перерывах будут розыгрыши призов от компаний-спонсоров и экскурсии в юзабилити-лабораторию 1С.
Конференция бесплатная, но количество мест ограничено, так что спешите! Регистрация доступна на wud2009.ru/reg Для тех, кто не сможет прийти на конференцию будет онлайн-траснляция докладов. | comments: 2 comments or Leave a comment  |
| Наткнувшись на форуме SQL.ru на вопрос о том, как спроектировать организационную структуру компании-разработчика ПО, я стал размышлять следующим образом:- Большинство компаний развиваются и растут эволюционно, начиная с небольшой группки энтузиастов-предпринимателей
- У большинства компаний структура разная
- Организационная структура определяется структурой процессов, набором функций, количеством человек, выполняющих функции, компетенциями и амбициями отдельных участников
- Структура процессов определяется рынком, историческими условиями, личными компетенциями отдельных ключевых сотрудников
- Набор функций для разных компаний относительно одинаков
Таким образом понятно, что оргструктура — это штука достаточно опосредованно зависимая от многого другого (прежде всего — от исторического наследия), идеальных и оптимальных оргструктур не бывают, бывают лишь более или менее эффективные с разных точек зрения (инвестор, владелец, топ, менеджер среднего звена, заказчик).
Ну что же, давайте начнём с наиболее простого и инвариантного — набора функций.
Они, на первый взгляд, таковы для компаний любого масштаба (3 - 30.000 человек):- Управление компанией
- PR, Реклама
- Развитие бизнеса
- Маркетинг
- Финансы
- Продажи
- Производство
- Сопровождение
- Кадровый учёт и менеджмент
- Бухгалтерия
- АХО
- Охрана и безопасность
- Юридическое обеспечение
Если что-то важное забыл — допишите.
Теперь можно идти дальше и попытаться распределить функции по категориям процессов. | comments: 15 comments or Leave a comment  |
| Так сложилось, что для многих около-IT-шных людей является новостью, что существуют следующие области знаний относительно организации деятельности в индустрии создания ПО и оказания IT-услуг:
1. BAM: Описание производственной деятельности, модернизация этих описаний, воплощение в практику новых моделей деятельности (Business Analysis, Business Modeling, Business Process Reengineering). Ключевые слова: Workflow, ARIS, BPMS, Р 50.1.028-2001
2. SP: Организация процесса создания ПО (aka Software Engineering, Software Process Management). Ключевые слова: Брукс, CMMI, SWEBOK, RUP, MSF, Agile, XP, ISO 12207
3. PM: Управление (IT)-проектами (Project Management). Ключевые слова: PMBOK, Арчибальд, ДеМарко/Листер, Макконнел, Беркун, MS Project
4. RQDM: Разработка и управление требованиями. Ключевые слова: BABOK, Леффингуэлл, Вигерс, Коберн, Requisite Pro, IEEE 830-1998.
5. SASD: Системный анализ и проектирование ПО (System Analysis & Software Design). Ключевые слова: UML, Буч, Gang of Four.
6. SA: Архитектура ПО (Software Architecture). Ключевые слова: EABOK, Фаулер, IEEE 1471.
7. UID: Проектирование пользовательских интерфейсов (User Interface Design): Ключевые слова: Раскин, Купер, Норман, Константайн.
8. P: Создание ПО (Programming).
9. QAT: Обеспечение качества и тестирование (Quality Assurance & Testing).
10. CM: Конфигурационное управление (Configuration Management). Ключевые слова: CMBOK, VCS.
Дисклеймер №1. Области знаний (и деятельности) 2 (SP), 3 (PM) и 4 (RQDM) -- это разные области знаний. Если вы об этом не знаете, то это не значит, что это не так.
Причём 1 (BAM), 2 (SP) и всё остальное -- это три разных уровня работы и детализации.
BAM говорит о том, как организовывать и улучшать деятельность вообще. SP говорит о том, как организовывать деятельность в разработке ПО. Остальные 3-10 посвящены отдельным производственным процессам, проистекающим в ходе разработки ПО.
Дисклеймер №2. Я сознательно специализируюсь на области знаний 4 (RQDM). Также захожу немного в 1 (BAM), 2 (SP), 5 (SASD) и 7 (UID). Иногда, совсем редко -- в 3 (PM), 6 (SA) и 9 (QAT).
Возможно, дальше ситуация будет меняться (больше всего из профессиональных областей в плане развития меня сейчас интересует маркетинг продуктов и управление людми), но пока это так.
Поэтому думать, что я могу выступать в качестве эксперта (и имею претензию на это) в областях, отличных от RQDM -- неразумно.
| comments: 45 comments or Leave a comment  |
| 8 октября в ГУ-ВШЭ на Покровском бульваре, 11 в 8 вечера пройдёт очередная встреча из цикла #uidesignersmeetup, на которой мы попробуем совместить интересы аналитиков и проектировщиков интерфейсов и я расскажу о следующем:
Часть 1 (40 мин)
- Процесс разработки требований: основные фазы, роли, работы, формы представления результатов по лучшим мировым практикам
- Бизнес-аналитик / системный аналитик: в чём разница?
- Как разработка требований связана с проектированием интерфейсов
Часть 2 (40 мин)
- Как выстроить эффективную коммуникацию между аналитиком и проектировщиком интерфейса
- Как строить процесс разработки требований в команде из 5, 15, 25 человек
- Кто может выполнять роль аналитика, если его нет в команде явно
Обсуждения (Полчаса)
Регистрация
| comments: 2 comments or Leave a comment  |
| Увидев вопиющий пример нарушения здравого смысла в посте горе-пма, не удержался, чтобы сформулировать собственные правила процедуры согласования:
1. Участники процесса согласовании должны заранее знать о том, что они будут принимать участие в согласовании.
2. У участников процесса должна быть картина правил игры этого процесса — что за документ вообще, какие в нём разделы, откуда они берутся, кто за что отвечает, каков порядок согласования, каковы зоны полномочий под документу. Как в случае типового документа и процедуры, так и в случае специфического, разового случая.
3. Если виза участника согласования влияет на содержание документа, то они должны привлекаться к его разработке на всём цикле его создания, а не только в конце. Если какие-то решения приняты до них, то должны быть им озвучены, далее все решения по документу создаются с его участием.
4. На момент, когда документ присылается человеку на подписание — он уже должен знать его содержание.
5. На процесс согласования у участников должно явным образом выделяться время в планах и должностных инструкциях.
6. Сроки согласования документа должны строиться с учётом ресурсной загрузки специалистов, а не просто сваливаться сверху и ставить их перед фактом.
7. Большие документы подаются на изучение частями по мере проработки.
8. Чтобы исключить затягивание срока рецензирования, делается очная, если необходимо — многочасовая встреча с совместным проходом по документу. | comments: 83 comments or Leave a comment  |
| Чтобы перебить свой обычный критическо-теоретический тон, я решил рассказать о своём профессиональном пути. И мне полезно вспомнить, и у вас контекст для вопросов появится, может ещё и связи кое-какие удастся восстановить.
Итак, 2000-й год. Я на 4-м курсе специальности САПР Бауманки. (Про свои первые попытки подработки в виде рисования электросхем в Автокаде и посещения вербошоу Гербалайфа я так уж и быть, рассказывать не буду). У нас ещё не пошли толком спецпредметы, и из-за военки, на которую я не ходил, образовывалось значительное количество свободного времени.
Мы только что прошли курс по информационному обеспечению САПР, который на практике сводился к теории и практике реляционных баз данных. Один из моих преподавателей и будущий научник по диплому предложил мне подумать о работе с базами данных у своего знакомого. Речь шла о небольшой компании из 5-и человек, которая делала базы данных и приложения для ГТК РФ. Недолго думая, я прошёл короткое собеседование и устроился на полставки.
Офис мы делили вместе с компанией Гроссмейстер на территории института дальней радиосвязи — НИИДАР.
Мои рабочие дни начались с изучения СУБД Oracle 8 через чтение документации и выполнение тестовых заданий оттуда. Позже я занялся программированием и разработкой отчётов в Oracle Developer. Мы писали процедуры обработки данных на PL/SQL, строили формы в Oracle Forms и Oracle Reports. Среда разработки у Oracle Developer достаточно специфическая и с позиционированием и обработкой данных в отчётах возиться приходилось изрядно. Основной темой программ и отчётов были различные данные о таможенных декларациях, налоговых ставках и поступлениях за различные периоды времени.
ТЗ на создаваемые нами программы писал наш начальник, который сам же программировал большую и наиболее сложную часть программ. Стиль подготовки и взращивания молодых специалистов (а у меня на тот момент была достаточно слабая подготовка как специалиста) у руководства оказался очень своеобразным — предполагалось, что для освоения промышленной разработки ПО достаточно тыкаться по документации, пробовать, задаваться вопросами и изредка советоваться у коллег. В целом можно сказать, что этот опыт был изрядно фрустрирующим, с одной стороны работа со структурами данных в БД — это довольно увлекательное занятие для новичка с инженерным мышлением, с другой стороны, представлений о том, как эффективно организовать свой процесс разработки ПО не было и в ходе такого «ковбойского программирования» не появлялось.
На территории заказчика я впервые столкнулся с политическими играми, типичными для заказчиков государственных. Как оказалось, у ГТК была своя собственная подструктура, ответственная за автоматизацию — так называемый главный научно-информационный вычислительный центр (ГНИВЦ) и, как я понял, мы конкурировали с ними за бюджеты на подряд.
Особенным фаном была сборка, а затем развёртывание, тестирование и настройка очередных дистрибутивов на территории заказчика — нередко такие работы занимали по несколько часов с вылезающими ошибками, отладкой на месте и т.д.
После приблизительно полугода работы я решил начать изучать английский на втором высшем (что позже оказалось не самой лучшей идеей) и временно прекратил рабочую деятельность.
Под конец работы я уже практически начал нащупывать свою нишу «постановщика задач» для программиста — с одним из парней у нас образовался тандем, где я описывал ему логику работы интерфейса, а он реализовывал задуманное. Также удалось почитать кое-что про хранилища данных, OLAP и многомерные кубы на примере Oracle, что позже весьма пригодилось.
| comments: 14 comments or Leave a comment  |
| На прошедшей конференции PM-Labs 2009 был представлен доклад «Компании-разработчики ПО: светлая и темная сторона», в котором Тимур Хайруллин и Юля Нечаева говорили о различиях в подходах к управлению процессами и людьми в продуктовых и аутсорсинговых компаниях. На удивление бурный протест со стороны слушателей вызвал тезис об усредненном соотношении разработчиков к тестировщикам как 5:1.
Так как приведенная цифра действительно основана не на суровой статистике, а на собственных наблюдениях, ребята решили провести опрос и докопаться до истины: каково же среднее соотношение разработчиков и тестировщиков в компаниях, работающих на просторах бывшего Союза.
Поучаствуйте в опросе, плс.
| comments: 5 comments or Leave a comment  |
| Предыстория
В сети мы общаемся с людьми, а иногда и сервисами. Для этого есть такие типичные форматы, как почта, мессенджер, социальная сеть.
Когда-то проектировщики интерфейсов этих систем решили основную задачу — (как-то) организовать диалог. Теперь пришло время пойти дальше.
Если присмотреться к взаимодействию людей в ходе диалога, то мы можем заметить, что с разными собеседниками человек выстраивает разный контакт и в смысле содержания разговора и в смысле отношений к диалогу и людям как таковым. Есть ли что-то общее, типичное в этих вариациях коммуникаций?
На самом деле, есть. Есть такие типичные контексты деятельности и взаимоотношений, как:- Любимые
- Друзья
- Родственники
- Коллеги
- Одноклассники/Сокурсники
- Знакомые
- Знакомства
- Сервисы
(Этот список условно приоритезирован по важности, что мы сможем использовать в дальнейшем).
Гипотеза Вообще говоря, вам не всё равно, кто вам написал. Ваша реакция будет различна. Если сообщение написал вам лично или опубликовал его в блоге ваш любимый человек или друг — то наверное стоит прислать его вам смской? Если сообщение написал знакомый — то будет достаточно поместить его в ваш почтовый ящик / ленту подписок.
Любой собеседник, вступивший с вами в контакт, может быть отнесён к одному или нескольким таким контекстам.
Если сервис знает о приближении дня рождения вашего родственника, он может оповестить об этом вас за неделю и порекомендовать подарок на сумму X, если речь идёт о дне рождения знакомого — оповестить за 3 дня и предложить подарок на сумму X/2.
Проблема Однако большинство коммуникационных сервисов не знают, кем вам приходится тот или иной собеседник и не умеют варьировать своё поведение в зависимости от вашего отношения к нему. Да, ряд сервисов позволяет делать персональные настройки, фильтры, на конкретного человека/сервис, но т.к. пользователь не имеет таких контекстов в интерфейсе по умолчанию, сразу, немудрено, что этими настройками умеет и пользуется малый процент.
Собственно говоря, корень проблемы в том, что понятия Адресная книга (Список контактов) и Диалоги (Переписка) сейчас сильно оторваны друг от друга по крайней мере в почте (outlook, mail.ru, почта яндекса, gmail) и во многих социальных сетях. Мессенджеры этой проблемой не страдают, т.к. все дискуссии у них организованы ЧЕРЕЗ список конактов. Но проблемы с варьированием поведения у них остаются.
Возможное решение
Каждый коммуникационный сервис может предлагать сразу после регистрации набор готовых ролевых контекстов типа перечисленных выше, чтобы дальнейшую коммуникацию с каждым новым собеседником вести в определённом контесте с определёнными специфическими для него функциями и свойствами.
Мир будущего
Видится, что в мире будущего социальная сеть, почта и мессенджер сольются в единое целое.
Резюмируя решения:- Готовые контексты (5-7) как контейнеры, пространства для общения.
- Различное поведение сервисов, учиывающее контекст.
См. также: | comments: 17 comments or Leave a comment  |
| Ищу специалиста, который может провести 4-8 часовой тренинг по разработке нефункциональных требований к ПО.
Что ожидается:- Атрибуты качества ПО по ИСО9126.
- Вклад атрибутов качества в успех продукта для их разных категорий.
- Источники требований к качеству ПО.
- Методы выявления требований к качеству ПО.
- Способы задания требований к аспектам качества.
- Способы проверки сответствия требований к аспектам качества.
- Разработка профилей качества для разных категорий продуктов / видов релизов.
| comments: 24 comments or Leave a comment  |
| Иногда мне задают вопросы про разные задачи и про людей. Вообще сейчас кризис и люди, которые умеют решать задачи, нужны. Так вот я решил поделиться тем, что знаю. Заодно некоторые люди узнают, чем же они занимаются %) Ну и себе памятку составить. Если кто против своего упоминания — черкните мне, вынесу. Если хотите что-то уточнить или вписаться — тоже пишите, но учтите, что я пишу только про тех, кого знаю и в качестве работы кого я не сомневаюсь.
Визионерство
ailev , urbansheep
Анализ рынка
oddboy , justdoitbaby
Определение продукта
lavale , afriki , milaya_o , patamyshta
Продажи
ideali
Реклама
_subtle_ , soulskeeper
PR
klemka
Разработка требований
aivanova , alextheraven , bas4all , make_summer
Управление проектами
blanditiae , gastarblogger , dastilda , milaya_o , cornerles , ay5
Проектирование интерфейсов
eril , jvetrau
Клиентсайд-разработка
quappa , dixi
Вёрстка
tachisis
Проектирование и разработка архитектуры
ivbeg , raa , tobe , agreb
Руководство командой разработчиков
tobe , raa , agreb
Фасилитация
ideali , allileja
Постановка процессов обеспечения качества
slavapankratov , atermath , ivbeg
Постановка процессов разработки
cartmendum , zibsun
Тексты
urbansheep , ay5
Администрирование систем
rdesperado
Организация технической поддержки
meatreach
Документация пользователя
akeepaki , orie , nat_crow
Организация оффлайн-движухи (aka Event Management)
_lothar_ , nikolaj , lost_in_net , allileja , beejess
Журналистика
an_chous , lorbit | comments: 40 comments or Leave a comment  |
| Очередное предложение для разноображивания жизни.
Возмусь курировать ваш проект с целью вашего обучения, проходясь по цепочке маркетинг -> концепция -> требования -> проектирование. Берусь не за каждый проект, а лишь за те, которые понравятся.
Другой вариант — вы делаете некоммерческий проект, тему которого выдвигаю я.
Сейчас у меня есть на выбор следующие эрудиция и эстампы: 1. Развитие сайта UML2.ru 2. Веб-сервис управления задачами 3. http://beskov.ru/2006/04/17/region-site-concept-basics/
Свои заявки присылайте на systemdesigncoach @ beskov.ru
Если у вас есть продукт, то опишите его в форме: 1. Кто является пользователем 2. Какую его проблему решаем 3. Каким образом 4. Чем это лучше того, что есть сейчас 5. Кто и за что платит | comments: 13 comments or Leave a comment  |
| Как вы знаете, завтра (уже сегодня) в мск проходит конференция по веб-разработке REMIX.
Хорошее отличие этого года — то, что вы сможете сами принять участие в освещении этого события и получить более полную картину происходящего благодаря сервису фильтрации twitter-контента twihoo.
Как узнать, что пишут о конференции? Зайдите на twihoo.com/remix и знакомьтесь с отзывами в реальном времени:

Как сообщить своё мнение миру? Запостите сообщение в twitter с хеш-тегом #remixru и в течении нескольких минут оно появится по ссылке выше. Кроме того, вы всегда сможете вернуться и ознакомиться с отзывами о прошедшем событии.
Как задать вопрос организаторам REMIX? Напишите в twitter пользователю @remixru
Enjoy! | comments: Leave a comment  |
| | Придумал вопрос — Перечислите виды визуальных моделей систем, которые вы знаете в порядке убывания их полезности и поясните выбранный порядок. | comments: 51 comments or Leave a comment  |
| Что мне интересно:
Профессия
- Профиль профессии UX-аналитика и проектировщика: знания и умения
- Критерии и показатели эффективности работы UX-специалиста
- Как должна быть построена програма обучения специалиста и почему
Рынок
- Как эффективно продавать себя как UX-специалиста
- Обзор рынка UX в России и сравнение с мировым
Процессы
- Интеграция UX и SE (Software Engineering)-процессов
- Особенности организации UX-процесса для разных категорий продуктов
- Принципы и методы кастомизации UX-процесса под проект
- Организация командной работы UX-специалистов
Аудит продукта
- Изучение паттернов использования продуктов: недорогие технические средства мониторинга пользовательской активности для веб-систем
- Организация комплексного юзабилити-аудита продукта
- Связь бизнес-показателей и пользовательских качеств продукта для разных их категорий
Задачи по этапам
- Обзор методов изучения аудитории продуктов от простых к сложным
- Сравнение и особенности описания взаимодействия пользователя через User Story, Use Case и Scenario
- Взаимосвязь концепции продукта и концепции интерфейса
- Примеры создания разных концепций интерфейсов разными командами для одной задачи (конкурс?)
- Типовые решения типовых задач: регистрация, авторизация, почтовые оповещения, интерактивные оповещения, переписка, журнал событий, списки контактов, фильтры, тэги, календарь событий
Спецтемы
- Разработка полноценной системы навигации через клавиатуру и горячие клавиши
- Принципы и примеры построения расширяемого интерфейса
- Особенности проектирования взаимодействия для мобильных устройств
- Проектирование социального взаимодействия в сообществах
Что я могу попробовать рассказать:
- Обзор рынка UX в России и сравнение с мировым
- Обзор методов изучения аудитории продуктов от простых к сложным
- Сравнение и особенности описания взаимодействия пользователя через User Story, Use Case и Scenario
- Взаимосвязь концепции продукта и концепции интерфейса
- Связь бизнес-показателей и пользовательских качеств продукта для разных их категорий
| comments: 6 comments or Leave a comment  |
| Деятельность по созданию ТЗ состоит из 3-х важных фаз, выполняемых итерационно:- Выявление требований
- Документирование требований
- Согласование требований
Поскольку на грабли продолжаем наступать, описываю минимальный сценарий разработки ТЗ:
- Заказчик рассказывает Аналитику своё представление о продукте, Аналитик задаёт необходимые вопросы и получает ответы.
- Аналитик пишет 1-ю версию требований.
- Аналитик обсуждает 1-ю версию требований с Разработчиком на предмет принципиальной реализуемости, вносит правки, получает версию 2.
- Аналитик обсуждает версию 2 требований с Заказчиком на предмет соответствия его интересам и представлениям, задаёт вопросы, получает фидбек.
- Аналитик создаёт версию 3 на основании фидбека и согласует её у Заказчика с правками до 4-й версии.
- Аналитик обсуждает версию 4 с Разработчиком и закрывает все вопросы последнего, получая версию 5.
Итого — для самого малого проекта нужно: МИНИМУМ 5 версий документа, 3 сессии работы с Заказчиком, 2 сессии работы с Разработчиком.
Для самого малого проекта, ЕСЛИ ВСЁ ИДЁТ ГЛАДКО:- 5 версий — это 5 часов документирования требований (по часу на версию).
- 5 сессий общения — 5 часов выявления и согласования требований (по часу на сессию).
Таким образом самый малый проект тянет на 10 часов работы по требованиям. (Но это затраты, которые практически всегда окупаются). | comments: 40 comments or Leave a comment  |
| Если я тебе зачем-то нужен:
Добавь меня в МК и узнай мой номер телефона, имейл, Skype, Gtalk и всегда имей доступ к актуальным данным.
| comments: 4 comments or Leave a comment  |
| С удовольствием послушал Вировца месяц назад, очень полезно и конструктивно было. Верю, что с точки зрения бизнеса было эффективно и правильно строить развитие продукта, опираясь на отзывы сейлов, продающих корпоративные пакеты.
Но. Сейчас (за последние годы) аудитория кандидатов сильно сместилась от менеджмента в сторону специалистов.
Сегодня наблюдал, как тётя заполняет анкету на HH.ru, задавая мне вопросы почти по каждому полю, попадая в тупики и т.д.
И возникают вопросы к ребятам, которые делали его интерфейсы — а каким таким usability вы на проекте занимались, какие проблемы решали, что решили, а что — нет и почему? | comments: 12 comments or Leave a comment  |
![[icon]](http://l-userpic.livejournal.com/91586538/593145) |
Системный анализ в Разработке ПО и Другие
|
|