Проектная документация
Sergey Makarov
крупного интернет проекта?
Видение проекта (Vision)
Пользовательские истории (User stories)
Функциональность (срезы версий)
Планирование
Сводный план проекта
Документ оценки рисков (Risk assessment document)
Карта сайта (Site map)
Персонажи (Personas)
Сортировка карточек (Card sorting)
Структурные схемы страниц (Wire frames)
Карта структурных схем страниц (Wire frames map)
Схема навигации
Сценарии взаимодействия (use cases)
Что следует добавить?
Есть ли вообще какие комментарии у участников относительно перечня как
такового и конкретных документов в частности?
Может ли кто-либо поделиться образцами конкретных документов и
тематической литературой? (я могу намылить то что есть, по запросу=)
Solonitsyn Yury
"Сортировку карточек"?
В моем понимании (не претендую в этом на полную правильность данных) схемы
навигации, структурные схемы страниц, карты сайтов, карты структурных схем
(что это???) и сценарии использования относятся уже не проектной, а к
"конструкторской" документации, то есть, разрабатываются в процессе
реализации конкретных решений. Эти документы служат руководством для
разработчиков и дизайнеров.
Проектная документация, скорее, предназначена инвесторам и менеджерам, она
позволяет оценить реализуемость проекта, потенциальную выгоду от его
реализации, сроки ввода в эксплуатацию и другие подобные параметры.
Если я в чем-то не прав, поправьте меня.
Hienadz Drahun
> тематической литературой? (я могу намылить то что есть, по запросу=)
Как раз сейчас читаю книгу Dan Brown "Communicating Design -
Develpoing Web Site Documentation about Design and Planning"/ Там как-
раз про это.
Taras Brizitsky
Sergey Makarov
Александр Хмелевский
сайте можно ознакомится с описанием каждого в отдельности и посмотреть
примеры.
http://www.uimodeling.ru/process/documents/
Hienadz Drahun
> сайте можно ознакомится с описанием каждого в отдельности и посмотреть
> примеры.http://www.uimodeling.ru/process/documents/
>
Спасибо, замечательные примеры.
Еще посмотрите книгу Карла Вигерса "Разработка требований к
програмному обеспечению"
http://www.ozon.ru/context/detail/id/1594986/
Образцы документов по Вигерсу:
http://www.processimpact.com/goodies.shtml
podlec
По ходу изучения составления проектной документации наткнулся на
расхождении во мениях как по самим документам, так и по их структуре.
Этот вот факт наводит на мысль прочесть и изучить как можно больше и
выработать наиболее удовлетворяющий подход (сначала общий а потом -
частный) для работы внутри своей команды. Естественно, главное - чтобы
этот подход позволял оптимально решать поставленные задачи. Под
подходом я тут понимаю состав документов и их структуру :)
Зимин Дмитрий
У вас Sitemap от "Wireframe map" чем отличается? Просто у меня это
примерно одно и тоже. :)
Что такое карта сайта? Я обычно определяю её как "наглядная схема
основных страниц и взаимосвязей между ними". А карта экранов тогда что
отображает?
Спасибо.
On 18 дек, 13:48, Sergey Makarov <vela...@gmail.com> wrote:
Заур Гиясов
> Немного оффтопик:
>
> У вас Sitemap от "Wireframe map" чем отличается? Просто у меня это
> примерно одно и тоже. :)
> Что такое карта сайта? Я обычно определяю её как "наглядная схема
> основных страниц и взаимосвязей между ними". А карта экранов тогда что
> отображает?
> Спасибо.
Для меня карта сайта - это структура сайта - его строение. А карта
экранов - это структура действий. Внешне эти две вещи могут иметь
блоки с одинаковыми названиями и даже, возможно, схожую структуру. Но,
по сути, они преследуют разную задачу. Карта экранов показывает, что
должна отобразить система в ответ на какое-либо действие пользователя
- это динамическая структура. Карта сайта отображает строение сайта
или раздела - это статическая структура.
Sergey Makarov
многому у вас научился, за что вам отдельное спасибо =)
Sergey Makarov
формализации требований, и проектирования в общем.
Sergey Makarov
разделов сайта. По сути - это высокоуровневая карта сайта, в то время
как Wireframe map - это карта структурных схем страниц, которую в
принципе формализовать для всего сайта в одном документе очень сложно
(а тем более потом распечатать), так что Wireframe map, на мой взгляд,
стоит составлять для каждого раздела отдельно, это как взгляд на
структуру сайта под микроскопом (по сравнению с Site map). Каждый
раздел может содержать более 50 Wireframe отдельных страниц. В карте
сайта (Site map), мы пишем, что это - раздел "Контакты", а в Wireframe
map для раздела "Контакты" может быть несколько Wireframe (например,
если применяются ограничения для определённых групп пользователей, или
применяются Ajax-технологии для отображения определённых элементов
управления, информации).
Sergey Makarov
Состав проектной документации v.1.2
Общие документы
Видение проекта
Цели и задачи проекта
Бизнес-требования
Концепция решения
Рамки проекта
Сводный план проекта
Сводный документ оценки рисков
Карта сайта
Пользователи
Группы пользователей
Общая схема навигации
Документы разделов
Видение раздела
Цели и задачи раздела
Бизнес-требования
Концепция решения
Рамки раздела
Карта раздела
Документ оценки рисков
Пользователи
Группы пользователей
Персонажи
Пользовательские истории
Сценарии взаимодействия
Структурные схемы страниц
Структурные схемы страниц
Карта структурных схем страниц
Функциональность (Срезы версий)
Схема навигации
Sergey Makarov
On 18 дек, 16:21, "Solonitsyn Yury" <je...@adesignlab.ru> wrote:
> Интересно, зачем вы хотите приводить как отдельный проектный документ
> "Сортировку карточек"?
>
> В моем понимании (не претендую в этом на полную правильность данных) схемы
> навигации, структурные схемы страниц, карты сайтов, карты структурных схем
> (что это???) и сценарии использования относятся уже не проектной, а к
> "конструкторской" документации, то есть, разрабатываются в процессе
> реализации конкретных решений. Эти документы служат руководством для
> разработчиков и дизайнеров.
>
> Проектная документация, скорее, предназначена инвесторам и менеджерам, она
> позволяет оценить реализуемость проекта, потенциальную выгоду от его
> реализации, сроки ввода в эксплуатацию и другие подобные параметры.
>
> Если я в чем-то не прав, поправьте меня.
Да, действительно, "Сортировка карточек" в большей степени инструмент,
чем документ, но в конечном итоге результаты применения данного
инструмента оформляются в виде документа, который формализует все
достигнутые в ходе эксперимента результаты: фото отсортированных
потенциальными пользователями карточек, их комментарии заметки
организаторов, выводы. Это обуславливает моё решение включить данные
документы в возможный общий перечень.
Майевтик
Во-первых, хотел бы вас попросить нумеровать списки -- это необходимо
для удобства отсылки к его элементам и обсуждения.
Во-вторых, набор проектной документации полезно представлять в виде
графа, чтобы было наглядно видно, какой документ/артефакт является
источником для какого.
В-третьих, вы традиционно для интернетчиков вольно обращаетесь со
словом Проект.
В промышленности, науке и бизнесе есть следующие 2 устойчивых значения
этого слова:
1. Проект как организованная деятельность.
2. Проект как модель будущего.
По всей видимости там, где у вас написано <<Видение проекта>> стоит
читать <<Видение продукта>>, т.к. понятие <<видение проекта>> во 2-м
смысле абсурдно, а в первом -- не подходит по контексту. Иначе, если бы
под проектом имели бы в виду не только описание продукта, а достижение
какой-то масштабной цели (например, занятие доли на рынке или
зарабатывание суммы в N денег), то вам бы пришлось много места в
перечне документов уделить концепции продвижения, плану разработки,
плану продвижения, плану кадрового обеспечения, плану закупок и и.д.
В-четвёртых, у вас нигде не сказано про нефункциональные требования, а
они могут серьёзно влиять на технические возможности продукта
обеспечивать нужный уровень безопасности, надёжности,
производительности, масштабируемости.
В-пятых, пропущены специфические для веба требования, типа
операционной среды, требования к формату заголовков, URL и т.д. -- им в
приведённой структуре просто нет места.
В-шестых, из моего опыта, И пользовательские истории И сценарии
взаимодействия для одного продукта -- это несколько избыточно. Имеет
смысл остановиться на чём-то одном.
В-седьмых, и это следует из пропущенных неф.требований, целиком и
полностью отсутствуют документы, описывающие технические решения
продукта -- документ архитектуры системы, модель базы данных, документы
с описаниями проектных решений по подсистемам, сценарии интеграции,
описание технической платформы и инфраструктуры. Т.е. я бы согласился,
если бы высказали, что речь идёт о проектной документации на ПРОДУКТ,
или на Пользовательские качества Продукта, т.е., по сути, на
проектирование его как чёрного ящика. Но любой современный большой
Продукт -- это не только оболочка, но и то, что под ней.
В-восьмых, напоследок, проектная документация -- это конечно круто, но
качество её зачастую определяется ПРЕДпроектной документацией, и
знать, что в неё должно входить, какого качества и полноты и как
использоваться при создании Проектной документации -- очень и очень
полезно. Garbage In, Garbage Out :)
Sergey Makarov
On 23 дек, 22:20, Майевтик <denis.bes...@gmail.com> wrote:
> Здравствуйте, Сергей и участники!
>
> Во-первых, хотел бы вас попросить нумеровать списки -- это необходимо
> для удобства отсылки к его элементам и обсуждения.
Я на данный момент не определил оптимальный порядок, поэтому не стал
нумеровать, чтобы неявно не влиять на мнение участников.
> Во-вторых, набор проектной документации полезно представлять в виде
> графа, чтобы было наглядно видно, какой документ/артефакт является
> источником для какого.
Есть две причины, по которым я не разместил объектный граф:
1. я здесь не нашёл интерфейс для размещения изображений;
2. Вот схема: http://picasaweb.google.com/velarix/ziUXLD#5283306422119631666
3. Вот граф: http://picasaweb.google.com/velarix/DropBox?authkey=tJu6RCyl6lg#5283340063761984946
> В-третьих, вы традиционно для интернетчиков вольно обращаетесь со
> словом Проект.
> В промышленности, науке и бизнесе есть следующие 2 устойчивых значения
> этого слова:
> 1. Проект как организованная деятельность.
> 2. Проект как модель будущего.
>
> По всей видимости там, где у вас написано <<Видение проекта>> стоит
> читать <<Видение продукта>>, т.к. понятие <<видение проекта>> во 2-м
> смысле абсурдно, а в первом -- не подходит по контексту. Иначе, если бы
> под проектом имели бы в виду не только описание продукта, а достижение
> какой-то масштабной цели (например, занятие доли на рынке или
> зарабатывание суммы в N денег), то вам бы пришлось много места в
> перечне документов уделить концепции продвижения, плану разработки,
> плану продвижения, плану кадрового обеспечения, плану закупок и и.д.
Хм... возможно. Я оперировал общепринятыми понятиями (пример:
http://www.uimodeling.ru/process/documents/vision.html)
> В-четвёртых, у вас нигде не сказано про нефункциональные требования, а
> они могут серьёзно влиять на технические возможности продукта
> обеспечивать нужный уровень безопасности, надёжности,
> производительности, масштабируемости.
Да, действительно, какой на ваш взгляд правильный перечень документов,
касающихся нефункциональных требований?
> В-пятых, пропущены специфические для веба требования, типа
> операционной среды, требования к формату заголовков, URL и т.д. -- им в
> приведённой структуре просто нет места.
Эти специфические требования как раз и входят в перечень
нефункциональных?
> В-шестых, из моего опыта, И пользовательские истории И сценарии
> взаимодействия для одного продукта -- это несколько избыточно. Имеет
> смысл остановиться на чём-то одном.
Хм... пользовательские истории (User stories) описывают
функциональность продукта в первом приближении, а сценарии
взаимодействия пользователя с системой (Use case) детализируют
непосредственно алгоритм взаимодействия (причём, не затрагивая
интерфейс). Хотя для небольших проектов, возможно и достаточно
пользовательских истории. по моему скромному мнению это два различных
документа.
> В-седьмых, и это следует из пропущенных неф.требований, целиком и
> полностью отсутствуют документы, описывающие технические решения
> продукта -- документ архитектуры системы, модель базы данных, документы
> с описаниями проектных решений по подсистемам, сценарии интеграции,
> описание технической платформы и инфраструктуры. Т.е. я бы согласился,
> если бы высказали, что речь идёт о проектной документации на ПРОДУКТ,
> или на Пользовательские качества Продукта, т.е., по сути, на
> проектирование его как чёрного ящика. Но любой современный большой
> Продукт -- это не только оболочка, но и то, что под ней.
Буду признателен, если вы приведёте краткий список документов,
описывающих непосредственно технические решения (кроме тех, которые вы
уже привели).
> В-восьмых, напоследок, проектная документация -- это конечно круто, но
> качество её зачастую определяется ПРЕДпроектной документацией, и
> знать, что в неё должно входить, какого качества и полноты и как
> использоваться при создании Проектной документации -- очень и очень
> полезно. Garbage In, Garbage Out :)
На мой взгляд Видение проекта (кстати, термин из MSF) как раз
выступает в качестве предпроектной документации.
Вот пронумерованный список (для простоты я упустил деление на
категории: "Общие" и "Документы разделов"):
1. Видение проекта
1.1. Цели и задачи проекта
1.2. Бизнес-требования
1.3. Концепция решения
1.4. Рамки проекта
1.5. Функциональность (Срезы версий)
2. Сводный план проекта
3. Сводный документ оценки рисков
4. Календарный график проекта
5. Пользователи
5.1. Группы пользователей
5.2. Персонажи
5.3. Пользовательские истории
5.4. Сценарии взаимодействия
6. Карта сайта
7. Структурные схемы страниц
7.1. Карта структурных схем страниц
8. Схема навигации
В общем и целом, при составлении перечня документации я стремился
придерживаться последовательности детализации - от общего видения, к
конкретным интерфейсным решениям.
Sergey Makarov
On 23 дек, 22:20, Майевтик <denis.bes...@gmail.com> wrote:
> Здравствуйте, Сергей и участники!
>
> Во-первых, хотел бы вас попросить нумеровать списки -- это необходимо
> для удобства отсылки к его элементам и обсуждения.
Я на данный момент не определил оптимальный порядок, поэтому не стал
нумеровать, чтобы неявно не влиять на мнение участников.
> Во-вторых, набор проектной документации полезно представлять в виде
> графа, чтобы было наглядно видно, какой документ/артефакт является
> источником для какого.
Есть две причины, по которым я не разместил объектный граф:
1. я здесь не нашёл интерфейс для размещения изображений;
2. Вот схема: http://picasaweb.google.com/velarix/ziUXLD#5283306422119631666
3. Вот граф: http://picasaweb.google.com/velarix/DropBox?authkey=tJu6RCyl6lg#5283340063761984946
> В-третьих, вы традиционно для интернетчиков вольно обращаетесь со
> словом Проект.
> В промышленности, науке и бизнесе есть следующие 2 устойчивых значения
> этого слова:
> 1. Проект как организованная деятельность.
> 2. Проект как модель будущего.
>
> По всей видимости там, где у вас написано <<Видение проекта>> стоит
> читать <<Видение продукта>>, т.к. понятие <<видение проекта>> во 2-м
> смысле абсурдно, а в первом -- не подходит по контексту. Иначе, если бы
> под проектом имели бы в виду не только описание продукта, а достижение
> какой-то масштабной цели (например, занятие доли на рынке или
> зарабатывание суммы в N денег), то вам бы пришлось много места в
> перечне документов уделить концепции продвижения, плану разработки,
> плану продвижения, плану кадрового обеспечения, плану закупок и и.д.
Хм... возможно. Я оперировал общепринятыми понятиями (пример:
http://www.uimodeling.ru/process/documents/vision.html)
> В-четвёртых, у вас нигде не сказано про нефункциональные требования, а
> они могут серьёзно влиять на технические возможности продукта
> обеспечивать нужный уровень безопасности, надёжности,
> производительности, масштабируемости.
Да, действительно, какой на ваш взгляд правильный перечень документов,
касающихся нефункциональных требований?
> В-пятых, пропущены специфические для веба требования, типа
> операционной среды, требования к формату заголовков, URL и т.д. -- им в
> приведённой структуре просто нет места.
Эти специфические требования как раз и входят в перечень
нефункциональных?
> В-шестых, из моего опыта, И пользовательские истории И сценарии
> взаимодействия для одного продукта -- это несколько избыточно. Имеет
> смысл остановиться на чём-то одном.
Хм... пользовательские истории (User stories) описывают
функциональность продукта в первом приближении, а сценарии
взаимодействия пользователя с системой (Use case) детализируют
непосредственно алгоритм взаимодействия (причём, не затрагивая
интерфейс). Хотя для небольших проектов, возможно и достаточно
пользовательских истории. по моему скромному мнению это два различных
документа.
> В-седьмых, и это следует из пропущенных неф.требований, целиком и
> полностью отсутствуют документы, описывающие технические решения
> продукта -- документ архитектуры системы, модель базы данных, документы
> с описаниями проектных решений по подсистемам, сценарии интеграции,
> описание технической платформы и инфраструктуры. Т.е. я бы согласился,
> если бы высказали, что речь идёт о проектной документации на ПРОДУКТ,
> или на Пользовательские качества Продукта, т.е., по сути, на
> проектирование его как чёрного ящика. Но любой современный большой
> Продукт -- это не только оболочка, но и то, что под ней.
Буду признателен, если вы приведёте краткий список документов,
описывающих непосредственно технические решения (кроме тех, которые вы
уже привели).
> В-восьмых, напоследок, проектная документация -- это конечно круто, но
> качество её зачастую определяется ПРЕДпроектной документацией, и
> знать, что в неё должно входить, какого качества и полноты и как
> использоваться при создании Проектной документации -- очень и очень
> полезно. Garbage In, Garbage Out :)
На мой взгляд Видение проекта (кстати, термин из MSF) как раз
Rus
Скажите пожалуйста что вы имеете ввмду под Рамками прокта? (к
сожалению не нашел описание в предыдущих ответах, возможно пропустил?)
Сергей, скажите пожалуйста схема навигации может отличатся для разных
групп пользователей? Как вы думаете может стоит совместить Карту сайта
и схему навигации в один пункт или возможно Схему навигации разместить
над/под Картой сайта?
Возможно с Календарным графиком всего проекта будут сложноти ведь он
идет раньше чем определены группы пользователей и истории, т.е. полная
функциональность проекта еще не известна.
Предложние: может быть после утверждения "окончательного" варианта
проектной документации стоит сделать пример?
Майевтик
> 1. я здесь не нашёл интерфейс для размещения изображений;
> 2. Вот схема:http://picasaweb.google.com/velarix/ziUXLD#5283306422119631666
Да, спасибо!
> > По всей видимости там, где у вас написано <<Видение проекта>> стоит
> > читать <<Видение продукта>>...
> Хм... возможно. Я оперировал общепринятыми понятиями (пример:http://www.uimodeling.ru/process/documents/vision.html)
От того, что Юра Ветров сотоварищи написал это у себя на сайте,
понятие общепринятым не становится ) Я ему ту же самую претензию
предъявляю, что и вам )
Фраза <<Видение проекта (vision) -- это краткое описание сути будущего
продукта>> ошибочна уже в своём построении, <<Видение стула -- это
описание стола>>. Всё-таки проект и продукт -- разные вещи, возможен и
проект продукта и продукт проекта, только тут слово проект будет
использоваться в разных смыслах. А для <<видения>> есть устойчивое слово
<<концепция>>.
> Да, действительно, какой на ваш взгляд правильный перечень документов,
> касающихся нефункциональных требований?
Обычно достаточно взять Supplementary Specifications из RUP.
> > В-пятых, пропущены специфические для веба требования, типа
> > операционной среды, требования к формату заголовков, URL и т.д. -- им в
> > приведённой структуре просто нет места.
>
> Эти специфические требования как раз и входят в перечень
> нефункциональных?
По Вигерсу нефункциональные требования состоят из:
* Бизнес-правил
* Внешних интерфейсов
* Атрибутов качества
* Ограничений
Требования к URL можно формально отнести к внешним интерфейсам, это не
очень принципиально, главное про них не забыть)
> > В-шестых, из моего опыта, И пользовательские истории И сценарии
> > взаимодействия для одного продукта -- это несколько избыточно. Имеет
> > смысл остановиться на чём-то одном.
>
> Хм... пользовательские истории (User stories) описывают
> функциональность продукта в первом приближении, а сценарии
> взаимодействия пользователя с системой (Use case) детализируют
> непосредственно алгоритм взаимодействия (причём, не затрагивая
> интерфейс). Хотя для небольших проектов, возможно и достаточно
> пользовательских истории. по моему скромному мнению это два различных
> документа.
Ну функциональность можно действительно с разной степенью приближения
описывать,
на уровне Features/Характеристик (а именно это должно быть, имхо, в
концепции продукта прежде всего), на уровне Scenario, на уровне User
Story, на уровне Use Case, на уровне Functional Requirement. Если User
Story служит заменой Features, тогда понятно.
> Буду признателен, если вы приведёте краткий список документов,
> описывающих непосредственно технические решения (кроме тех, которые вы
> уже привели).
Ну кроме тех, что я привёл, остальное зависит от класса и назначения
системы.
Подробнее перечень возможной тех.документации можно посмотреть в РД
50-34.698-90, например.
> На мой взгляд Видение проекта (кстати, термин из MSF) как раз
> выступает в качестве предпроектной документации.
Ну да, я так тоже предполагаю считать )
Вот только и оно тоже не из воздуха пишется, по хорошему.
Я использую следующую предварительную проработку:
Для публичных продуктов:
1. Описание рынка
2. Структурная модель предметной области
3. Процессная модель предметной области / предприятия
4. Модель сегментации и спроса аудитории (Анализ спроса)
5. Модель предложения (Конкурентный анализ)
Для проектов по автоматизации бизнеса -- только 2 и 3.
> 2. Сводный план проекта
Что такое сводный план?
Sergey Makarov
> Добрый день, Сергей.
>
> Скажите пожалуйста что вы имеете ввмду под Рамками прокта? (к
> сожалению не нашел описание в предыдущих ответах, возможно пропустил?)
Это термин из области методологии MSF (Microsoft Solution Framework)
(www.software.unn.ru/msf/Lectures/Lec7/MSF_Lec7.doc).
Также существует понятие "управления рамками проекта", как средства
борьбы с головной болью большинства проектных менеджеров -
"разрастанием рамок проекта".
> Сергей, скажите пожалуйста схема навигации может отличатся для разных
> групп пользователей? Как вы думаете может стоит совместить Карту сайта
> и схему навигации в один пункт или возможно Схему навигации разместить
> над/под Картой сайта?
Я подразумевал под схемой навигации структуру элементов управления
(меню, навигация). Естественно она может отличаться для различных
групп пользователей, имеющих отличия в уровне доступа к разделам
сайта, в том случае, если это имеет влияние на элементы управления
(например, ссылка "Новости партнёров" в горизонтальном меню
отображается только для групп "Партнёры" и "Администраторы").
Естественно оба документа взаимно влияют друг на друга, но они всё-же
отличаются, карта сайта (site map) описывает структуру сайта с точки
зрения информации и сервисов, а схема навигации описывает элементы
управления в текстовом виде (http://www.uimodeling.ru/process/
documents/site-map.html).
> Возможно с Календарным графиком всего проекта будут сложноти ведь он
> идет раньше чем определены группы пользователей и истории, т.е. полная
> функциональность проекта еще не известна.
Итерационно-инкрементальная (в противовес каскадной, водопадной)
модель жизненного цикла подразумевает реализацию принципов "Живых
документов" (living documents) (http://ru.wikipedia.org/wiki/
Microsoft_Solutions_Framework), то есть календарный график, как и вся
проектная документация должен иметь версионность, и изменяться при
необходимости. Версионность позволит откатиться на несколько решений
назад, в случае, если выбрано неправильное направление, изменились
внешние условия, поступила новая информация и пр. То есть мы сначала
пишем краткий календарный график, чтобы иметь хоть какое-то
представление, а в дальнейшем увеличиваем уровень детализации,
точности.
> Предложние: может быть после утверждения "окончательного" варианта
> проектной документации стоит сделать пример?
Думаю, что это хорошая идея. Можно для примера взять какой-то
маленький проект и для него разработать документацию. Есть гугл-докс,
для того, чтобы провести коллективную работу. Только, думаю, после
нового года, и нужно определить круг заинтересованных лиц, участников
=)
Sergey Makarov
> > Есть две причины, по которым я не разместил объектный граф:
> > 1. я здесь не нашёл интерфейс для размещения изображений;
> > 2. Вот схема:http://picasaweb.google.com/velarix/ziUXLD#5283306422119631666
> > 3. Вот граф:http://picasaweb.google.com/velarix/DropBox?authkey=tJu6RCyl6lg#52833...
>
> Да, спасибо!
Ну и как? =)
> > > По всей видимости там, где у вас написано <<Видение проекта>> стоит
> > > читать <<Видение продукта>>...
> > Хм... возможно. Я оперировал общепринятыми понятиями (пример:http://www.uimodeling.ru/process/documents/vision.html)
>
> От того, что Юра Ветров сотоварищи написал это у себя на сайте,
> понятие общепринятым не становится ) Я ему ту же самую претензию
> предъявляю, что и вам )
=))) Согласен, хорошо.
> Фраза <<Видение проекта (vision) -- это краткое описание сути будущего
> продукта>> ошибочна уже в своём построении, <<Видение стула -- это
> описание стола>>. Всё-таки проект и продукт -- разные вещи, возможен и
> проект продукта и продукт проекта, только тут слово проект будет
> использоваться в разных смыслах. А для <<видения>> есть устойчивое слово
> <<концепция>>.
Да - это ошибочное (даже просто с точки зрения семантики) утверждение!
Это я что-ли написал? Прошу прощения! о_О =)
А "Видение" (Vision) я позаимствовал из MSF =)
(http://74.125.77.132/search?q=cache:YlfU3rXCE8gJ:www.software.unn.ru/
msf/Templates/1_Envisioning/%25CA%25EE%25ED%25F6%25E5%25EF
%25F6%25E8%25EF%25F0%25EE%25E5%25EA%25F2%25E0.doc+видение
+проекта&hl=ru&ct=clnk&cd=1&gl=ru)
> > Да, действительно, какой на ваш взгляд правильный перечень документов,
> > касающихся нефункциональных требований?
>
> Обычно достаточно взять Supplementary Specifications из RUP.
Спасибо, взял на заметку, обязательно ознакомлюсь.
> > > В-пятых, пропущены специфические для веба требования, типа
> > > операционной среды, требования к формату заголовков, URL и т.д. -- им в
> > > приведённой структуре просто нет места.
>
> > Эти специфические требования как раз и входят в перечень
> > нефункциональных?
>
> По Вигерсу нефункциональные требования состоят из:
> * Бизнес-правил
> * Внешних интерфейсов
> * Атрибутов качества
> * Ограничений
Понял, я как раз читаю Карла Вигерса, то, что посоветовал Hienadz
Drahun =)
> Требования к URL можно формально отнести к внешним интерфейсам, это не
> очень принципиально, главное про них не забыть)
Да, согласен.
Это план мероприятий без привязки ко времени, то есть общее описание
последовательности всех действий, которые необходимо выполнить.
(http://www.software.unn.ru/msf/Templates/2_Planning/%D1%E2%EE%E4%ED%FB
%E9%20%EF%EB%E0%ED%20%E8%20%F1%E2%EE%E4%ED%FB%E9%20%EA%E0%EB%E5%ED
%E4%E0%F0%ED%FB%E9%20%E3%F0%E0%F4%E8%EA%20%EF%F0%EE%E5%EA%F2%E0.doc)
Sergey Makarov
Sergey Makarov
http://yandex.ru/yandsearch?text="Видение+продукта"+vision&stpar2=/h0/tm11/s2&stpar4=/s2
По мне так тоже словосочетание "Видение проекта" является
неоднозначным, но словосочетанием "Видение продукта", по всей
видимости оперируем только мы с тобой, Майевтик =)))
Hienadz Drahun
> неоднозначным, но словосочетанием "Видение продукта", по всей
> видимости оперируем только мы с тобой, Майевтик =)))
Попробовал поискать по гуглу на английском.
Оба выражения достаточно распространены.
Product Vision - является более правильным
Project Vision - является более распространенным.
Sergey Makarov
Хм.. , у Карла Вигерса, в книге "Разработка требований к программному
обеспечению" словосочетания "Project Vision" или "Видение проекта"
совсем не встречается. Один раз встречается словосочетание "Product
Vision", которое переведено как "Образ продукта".
Но есть, например "Документ об образе и границах проекта" (vision and
scope document). =)
Да, не хотелось бы спотыкаться на терминологии, но всё же однозначное
толкование терминов необходимо.
В общем то, можно сформировать краткий глоссарий терминов, для того,
чтобы можно было беспрепятственно продолжить обсуждение состава
проектной документации.
Я понимаю под словосочетанием "Видение проекта" - именно видение
проекта, но не продукта. И вообще я решил заменить документ "Видение
проекта" на "Документ об образе и границах проекта" (ссылаясь на
шаблон, предложенный Карлом Вигерсом).
Из структуры шаблона "Документа об образе и границах проекта"* явно
видно, что реч идёт именно о проекте в целом...
1. Бизнес-требования
1.1. Исходные данные
1.2. Возможности бизнеса
1.3. Бизнес-цели и критерии успеха
1.4. Потребности клиента или рынка
1.5. Бизнес-риски
2. Образ решения
2.1. Положение об образе проекта
2.2. Основные функции
2.3. Предположения и зависимости
3. Масштабы и ограничения проекта
3.1. Объём первоначально запланированной версии
3.2. Объём последующих версий
3.3. Ограничения и исключения
4. Бизнес-контекст
4.1. Профили заинтересованных лиц
4.2. Приоритеты проекта
4.3. Операционная среда
Хотя пункт 2.1, особенно в контексте пункта 2.2 меня сильно смутил. =)
У кого-нибудь есть оригинал книги на английском?
Hienadz Drahun
Vision and Scope Document это сокращение от Product Vision and Project
Scope Document. (см. главу 5: Establishing the Product Vision and
Project Scope)
Оригинал структуры этого документа:
1. Business Requirements
1.1 Background, Business Opportunity, and Customer Needs
1.2 Business Objectives and Success Criteria
1.3 Business Risks
2. Vision of the Solution
2.1 Vision Statement
2.2 Major Features
2.3 Assumptions and Dependencies
3. Scope and Limitations
3.1 Scope of Initial and Subsequent Releases
3.2 Limitations and Exclusions
4. Business Context
4.1 Stakeholder Profiles
4.2 Project Priorities
Sergey Makarov
есть и почта!
Кто-то может грамотно и понятно (для него) сформулировать вопрос на
английском?
Sergey Makarov
В указанном выше материале разделяют понятие требования к продукту и
требования к проекту...
Hienadz Drahun
оригинала книги Виггерса.
Майевтик
замечания по тексту полтуторагодичной давности, которые остались без
ответа (ник Cybrarian) -- вот такой веб2.0.
Если вы присмотритесь к тому, что вообще написано на той странице, на
которую ссылаетесь, то увидите, что сначала идёт заголовок <<Требования
к ПРОДУКТУ и ПРОЦЕССУ>>, а следующими абзацами идут Требования к
ПРОДУКТУ и Требования к ПРОЕКТУ. Я не знаю, что тому виной --
небрежность верстальщика или автора, но вкупе с фразами типа <<нотация
RUP>> и общей слабой проработанностью курса можно сделать вывод, что
заслуга профессора Маглинца только в том, что он профессор и первым
сделал курс на эту тему.
Майевтик
Product Vision соответствует термин Концепция системы, которая есть в
ГОСТовских потоках работ и рекомендациях по составу документации.
Если посмотрите мою презентацию и выступление на http://pmdays.ru, то
увидите, что я там тоже оперирую терминами Концепция продукта и
Концепция проекта.
On 29 дек, 21:25, Sergey Makarov <vela...@gmail.com> wrote:
> Ххех =)http://yandex.ru/yandsearch?text="Видение+продукта"+vision&stpar2=/h0/tm11/s2&stpar4=/s2
Майевтик
Если мы готовим конференцию, например, то это безусловно проект. И
хотя его результатом будет продукт типа <<событие>> (+ ещё множество
побочных), понятно, что участникам проекта будет проще использовать
понятие, привязанное к типу продукта, например, Event Concept (50k
упоминаний), а не абстрактно-обобщённое Product Concept.
On 29 дек, 21:43, Hienadz Drahun <hienadz.dra...@gmail.com> wrote:
Юрий Ветров
Согласен с твоей трактовкой разницы между продуктом и проектом, но
загвоздка в том что терминология "продукт" давно устоялась в среде
разработчиков десктопного ПО, но еще далека от нормального понимания
создателями веб-сервисов, порталов и прочих интернет-продуктов. Наши
клиенты среди тех, кто не воспринимают слово "продукт" как то что
касается веб-разработок. Поэтому мы скорее на их стороне, чем
стремимся не ошибиться в кругу профессионалов.
Solonitsyn Yury
применять.
Тупое составление документов в соответствии с ГОСТ (или другим стандартом)
приводит к появлению унылых документов, написанных канцелярским языком.
Разобравшись в том, для чего составляется каждый документ, можно подготовить
его качественнее или вообще не готовить, если это не требуется в данной
ситуации. Освободившееся время можно потратить на что-нибудь более полезное
для дела :)
Anatoly Shikhov
> применять.
Полностью согласен.
Как раз в этом месяце у нас в конторе был предновогодний аврал по
проектам.
Контора не маленькая, люди по разным этажам здания раскиданы.
В результате документирование было вот в таком виде:
1. Общие Wareframes, остальное правилось по ходу просмотра, отписками
по email, в аську или при личном общении.
2. Графические дизайны, опять таки с незначительными комментариями в
асьек исполнителю.
3. DOC-файлы, отправка письмом с кратким комментарием, куда и что
вставлять.
В общем, это не Agile даже, а самое настоящее XP, экстремальная
разработка то бишь:)
Гланое что это отлично работает. Парням из группы девелопмента не надо
париться над прочтеним документа,
т.к. общее видение проекта им периодически объясняется на планерках.
Дизайнеру тоде не надо выкатывать кучу бумаги.
Но, если команда будет масштабироваться в сторону увеличения,
то могут начаться проблемы коммуникации, тогда-то и придется
использовать какие-то
более продвинутые методы... Нет не писать кучу документов, а
использовать делегирование полномочий,
иерархию и какие-нибудь там средства телефонного, видео или веб-
конференсинга.
Те кто научился работать с фрилансерами отлично сочетают Skype, ICQ,
мобилу и что-то типа баг-треккера.
При этом, пишутся ключевые сжатые ТЗ, а сразу по сдаче производится
тщательное тестирование этих
маленких частей системы.
Фуф... чем ближе к утру, тем больше букв... странно не правда ли:)
Sergey Makarov
проекта"?
И пунктов в структуре меньше...
On 30 дек 2008, 13:16, Hienadz Drahun <hienadz.dra...@gmail.com>
wrote:
Sergey Makarov
почитать на тему проектной документации:
1. Леффингуэлл, Уидриг: Принципы работы с требованиями к ПО.
Унифицированный подход (Managing Software Requirements: A Unified
Approach)
2. Коберн: Современные методы описания функциональных требований к
системам (Writing Effective Use Cases)
3. Вигерс: Разработка требований к программному обеспечению (Software
Requirements) [цифра]
4. Халл, Джексон: Разработка и управление требованиями [цифра]
Особое спасибо Денису Бескову =) (http://beskov.livejournal.com/)
А кто-нибудь сталкивался с документом основных рыночных требований
(market requirements document, MRD)?
afriki
Я сейчас как раз занимаюсь разработкой процесса подготовки
предпроектной документации для среднего размера порталов и мои
размышления привели к следующему процессу:
1. Формулируются цели и стратегия бизнеса
2. Формулируется проблема, которую мы собираемся решить: цели и
задачи ресурса (редизайна, разработки)
3. Потенциальный пользователь и его потребности
4. Анализ рынка и конкурентной среды
5. Бизнес-концепция (В этом документе рассматриваются следующие
вопросы: суть и содержание бизнеса (что), аудитория/потребитель (для
кого) , бизнес-модель (где бабло) и конкурентные преимущества (почему
именно наши слоны). )
6. Функциональные требования
7. Проектирование структуры ресурса
8. Прототипирование основных страниц
9. Проектирование навигации
10. Разработка графических макетов
По завершении процесса мы имеем следующий пакет документов:
0. Project overview*
1. Бизнес-концепция
2. Функциональные требования
3. Макеты
4. Гайдлайн
* не знаю как это лучше назвать, но в этом документе на простом
человечьем языке дается краткая выжимка по проекту: что, зачем, для
кого, преимущества, возможности пользователя, структура, описание
основных страниц, этапность разработки и этапность развития; вобщем,
это именно тот документ, который дает общее представление о проекте,
одинаково читабелен для всех заинтересованных сторон и тд.
Имх, этих документов (при условии прохождения всех описанных этапов)
более чем достаточно для составления детальных планов, контроля над
"разбуханием" проекта, и, что немаловажно, это более-менее
гарантирует, совпадение плана с фактом.
Меня еще интересовал процесс формирования некоторой понятийной базы, в
рамках которой все стороны могли бы до начала разработки договориться
о том, что, зачем и каким образом они собираются делать для достижения
каких целей.
On 18 дек 2008, 13:48, Sergey Makarov <vela...@gmail.com> wrote:
> Адекватен ли такой перечень проектной документации для довольно
> крупного интернет проекта?
>
> Видение проекта (Vision)
> Пользовательские истории (User stories)
> Функциональность (срезы версий)
> Планирование
> Сводный план проекта
> Документ оценки рисков (Risk assessment document)
> Карта сайта (Site map)
> Персонажи (Personas)
> Сортировка карточек (Card sorting)
> Структурные схемы страниц (Wire frames)
> Карта структурных схем страниц (Wire frames map)
> Схема навигации
> Сценарии взаимодействия (use cases)
>
> Что следует добавить?
> Есть ли вообще какие комментарии у участников относительно перечня как
> такового и конкретных документов в частности?
> Может ли кто-либо поделиться образцами конкретных документов и
> тематической литературой? (я могу намылить то что есть, по запросу=)
Denis Beskov
Я использую приблизительно такой набор документов и поток работ в
общем случае:
http://www.flickr.com/photos/maieutic/3195119828/sizes/o/
В качестве атрибутов класса указаны компоненты артефакта, в качестве
методов — роли участников деятельности по созданию артефакта.
Sergey Makarov
В "Юзабилити бюллетене" опубликована статья на обсуждаемую тему:
http://upa.org.ru/UsabilityBulletin-30.aspx?EntryID=818
Интересно услышать комментарии, аргументированные возражения и
дополнения.
На сегодняшний день я уже и сам могу кое-что добавить, думаю, что в
последующих публикациях мне удастся сделать это, а ваши мнения будут
для этого очень кстати! =)