tag:blogger.com,1999:blog-53167472617533814932024-03-06T04:01:38.663+03:00Все для аналитиковUnknownnoreply@blogger.comBlogger20125tag:blogger.com,1999:blog-5316747261753381493.post-63711737450195011592012-07-10T17:53:00.000+04:002012-07-10T17:53:28.233+04:00Проблемы при использовании user story<div dir="ltr" style="text-align: left;" trbidi="on">
<a href="http://jamesshore.com/Presentations/Beyond%20Story%20Cards.html" target="_blank">Статья от Jim Shore о трудностях при использовании US</a><br />
<br /></div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-70238122384952525212012-06-05T08:41:00.001+04:002012-06-05T08:41:53.681+04:00Тестирование юзабилити<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
<br /></div>
<a href="http://usethics.ru/blog/lib/testing_by_the_cheap/">Методы usability тестирования</a><br />
<a href="http://usethics.ru/blog/lib/software_checklist/">Примерный список вопросов при проверке юзабилити</a>
</div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-1981363255433448542012-05-02T12:53:00.002+04:002012-05-02T12:53:38.692+04:00Прототипы. В чем их делать?<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<a href="http://habrahabr.ru/company/aiken/blog/129653/">Описание самых распространенных инструментов для прототипирования</a>
</div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-19336997251093734732012-03-30T08:20:00.002+04:002012-03-30T08:20:20.528+04:00Как делать прототипы на бумагеКакие инструменты при этом использовать?
На какой стадии остановиться?
Кто может делать такие прототипы?
Все это и больше в статье: <a href="http://www.cmsmagazine.ru/library/items/usability/art-of-sketching-in-design-prototype/">Искусство рисования эскизов при разработке прототипа</a>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-62030966419337271652011-09-12T09:03:00.002+04:002011-09-12T09:05:20.808+04:00Почему (почти) каждому Web-сайту нужна СУРБД<div dir="ltr" style="text-align: left;" trbidi="on">
<a href="http://www.ibm.com/developerworks/ru/library/wa-rdbms/index.html">Одна из областей, в которой часто возникают проблемы при попытках избежать осложнений на слишком ранних стадиях, – это откладывание принятия решений по структуре базы данных до тех пор, пока вы не окажетесь в безвыходном положении. <br> Системы управления реляционными базами данных – СУРБД (Relational Data Base Management Systems – RDBMS) не обязательно ограничивают ваши возможности или имеют слишком сложную архитектуру, хотя иногда их плохая репутация приводит разработчиков в ужас. Немного поразмыслив о том, что именно должен делать ваш сайт, можно быстро выработать разумную схему; также несложно предусмотреть расширяемые механизмы хранения, например таблицу конфигурации в серверных компонентах БД.</a></div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-68638965606810949012011-09-09T22:01:00.000+04:002011-09-09T22:01:11.152+04:00Что такое хорошее ТЗ?<div dir="ltr" style="text-align: left;" trbidi="on">
Вопрос, который волнует начинающих аналитиков: как написать хорошее ТЗ.<br />
На самом деле, советы можно давать или совсем в общем, или же по каждому проекту отдельно.<br />
Итак, общие рекомендации.<br />
<br />
<a name='more'></a>1. ТЗ должно быть полным, но не чрезмерным. Объем ТЗ зависит от проекта и, с одной стороны, есть соблазн написать такое ТЗ, в котором бы содержалось вся необходимая информация по проекту. С другой стороны, чем больше объем документа, тем сложнее его читать и работать с ним. <br />
Полнота ТЗ определяется не количеством страниц, а тем, что там приведены все требования, выполнение которых позволяет удовлетворить ожидания заказчика.<br />
2. Требования должны хорошо читаться. Это означает, что требования должны быть согласованы и находиться в самом документе так, чтобы их можно было легко и логично найти.<br />
3. Требования не должны в себе содержать элементы дизайна, но дизайн сценариев должен ссылаться на требования.<br />
<br />
Надо иметь в виду, что нельзя написать такое ТЗ, чтобы к нему не было вопросов. Они всегда будут. Вопрос только в их количестве и качестве.<br />
<br />
<br />
<b>life hack</b><div>
1. В текстовом редакторе имеет смысл создать заранее шаблон, включающий стили оформления текста и структуру самого документа. Это позволит быстрее создавать текст самого ТЗ. Можно ориентироваться на ГОСТ, можно на RUP. </div>
<div>
2. Включать в текст много поясняющих схем и картинок. При этом, картинки и схемы не заменяют текст, они его дополняют и иллюстрируют. Картинки и схемы можно располагать как в конце документа, так и по ходу чтения. В любом случае их надо подписывать и составлять список рисунков и таблиц с указанием названия и номера страницы. </div>
<div>
3. В документе должны быть гиперссылки. Это позволяет легко ориентироваться в документе. </div>
<div>
4. Должен быть лист согласований. Если ТЗ не согласованно, то потом могут возникнуть серьезные претензии у всех сторон. </div>
<div>
5. Название документа должно отражать номер версии. Это позволяет не запутаться в том насколько последняя версия документа есть у всех заинтересованных сторон. </div>
<div>
<br /></div>
<div>
<br /><div style="text-align: center;">
<br /></div>
<div style="text-align: center;">
<br /></div>
</div>
</div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-81908292976345362852011-08-29T23:50:00.000+04:002011-08-29T23:50:27.289+04:00Анализ требований<div dir="ltr" style="text-align: left;" trbidi="on">К моменту анализа все требования должны быть <a href="http://foranalysts.blogspot.com/2011/08/blog-post_22.html">собраны</a> и <a href="http://foranalysts.blogspot.com/2011/08/blog-post_25.html">проверены</a>.<br />
Дальше необходимо проанализировать требования. Анализ преследует несколько целей:<br />
<br />
<a name='more'></a><br />
<br />
1. исключение противоречащих друг другу требований. Объединение схожих требований.<br />
2. определение границ проекта. Для этого желательно бы классифицировать требования на 4 группы:<br />
<br />
<ul style="text-align: left;"><li>Must. Без выполнения хотя бы одного требования уровня Must проект не может считаться выполненным. </li>
<li>Should. Требования, которыми можно пренебречь в какой-либо итерации при наличии веской причины. </li>
<li>Could. Требования, которые желательно выполнить. Они, в основном, влияют на удовлетворенность пользователей. </li>
<li>Won't. Требования, которые можно выполнить только в том случае, если остались ресурсы. </li>
</ul><div>Такая классификация носит название <a href="http://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4_MoSCoW">Метод MoSCoW</a></div><div>При анализе требований также желательно выделить риски (им будет посвящена отдельная запись в блоге). </div><div><br />
</div><div>3. Документирование требований. Документирование может заключаться в описании:</div><div><ul style="text-align: left;"><li>сценариев использования</li>
<li>пользовательских историй</li>
<li>списка требований</li>
<li>спецификаций</li>
</ul><div>Каждый из вышеперечисленных способов создания аналитической документации имеет свои достоинства и недостатки. Под каждый проект и каждую команду разработки можно выбирать любой из указанных способов документации. </div></div></div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-31359225570965126112011-08-25T01:24:00.001+04:002011-09-06T13:47:05.624+04:00Проверка требований<div dir="ltr" style="text-align: left;" trbidi="on">
После того как требования собраны, необходимо сделать несколько вещей сразу:<br />
1. Проверить требования.<br />
2. Проанализировать требования.<br />
3. Расставить приоритеты.<br />
<br />
Проверка требований заключается в ответе на следующие вопросы:<br />
<br />
<br />
<a name='more'></a><br />
<br />
1. Корректно ли требование. Отражает ли требование реальную потребность (need), желание (desire), или обязательство (obligation)? Определена ли основная причина появления требования? <br />
Пример: повышение количества удовлетворенных клиентов это некорректное бизнес-требование. Корректным бизнес-требованием будет уменьшение времени подготовки документа до 1 часа. Такое требование является обязательством и является корневым. <br />
<br />
2. Целостно (complete) ли требование? Требование сформулированно в виде законченного предложения? Требование целиком размещено в одном месте документа, таким образом, что у читателя не возникает необходимости обращаться к дополнительной информации, чтобы понять это требование? <br />
<br />
3. Ясно (clear) ли требование? Требование недвусмысленно и непротиворечиво? Все ли заинтересованные лица согласны со значением требования? <br />
Пример: В любой коробке лежит приз. Требование двусмысленно. Непонятно, в одной только коробке лежит приз или в каждой коробке лежит приз. Правильно требование: в каждой коробке находится приз, выбранный случайным образом из списка призов. <br />
<br />
4. Согласованно (consistent) ли требование? Не противоречит ли требование другим требованиям? Соответствуют ли используемые термины терминам других требований и словарю?<br />
Пример: Пользователь имеет возможность самостоятельно настроить «частоты» под свои критерии. Должно быть объяснение "частот", так как их трактовка в случае сайта не совпадает с общепринятой. <br />
<br />
5. Проверяемо (verifiable) ли требование? Можем ли мы утверждать, что система соответствует требованию? Возможно ли определить для требования ясные, недвусмысленные тесты (criterion) типа "прошел/не прошел" (pass/fail)? Возможно ли установить, что требование прошло проверку (inspection), анализ (analysis), показ (demonstration) или тест (test)?<br />
Пример: Новые добавленные приложения помещаются в начало списка. Это легко проверяемое требование. В отличие от "система должна предоставлять возможность легкого перехода по виджетам". <br />
<br />
6. Трассируемо (traceable) ли требование? Имеет ли требование уникальное обозначение, так, что на него может быть сделана однозначная ссылка? <br />
Трассируемость требований особенно важна, если требований больше 50 и они имеют разный приоритет. <br />
<br />
7. Выполнимо (feasible) ли требование? Может ли требование быть реализовано в пределах стоимости (cost) и расписания (schedule)? Реализуемо ли технически требование с точки зрения применяемой (current) технологии? Требование физически достижимо (physically achievable)?<br />
Пример: доступ к системе должен осуществляться в режиме 24/7. Это требование, в целом, выполнимо, но очень дорого. Если его изменить как "система не должна простаивать более 3 часов в месяц", то такое требование становится гораздо более реальным и выполнимым. <br />
<br />
8. Отделено ли требование от дизайна (design independent)? Обоснованы ли требования, налагающие ограничения на дизайн? Позволяет ли формулировка требования реализовать его более чем одним способом?<br />
Пример: Вывод призов на странице списком: изображение + текстовое описание. Это уже не требование, это уже решение по дизайну. Более правильным будет следующая формулировка: пользователь должен иметь возможность просмотра изображений и описаний призов. <br />
<br />
9. Неделимо (atomic) ли требование? Действительно ли формулировка требования содержит только одно требование? Отсутствуют ли в требованиях такие слова ("и", "или", "но" ), которые могут указывать на наличие нескольких требований в формулировке требования. <br />
Пример: пользователь может авторизоваться и выбрать себе каталог для загрузки фотографий. На самом деле, авторизация не является требованием, это условие для появления возможности выбора каталога для загрузки. <br />
<br />
При проверке требований желательно, чтобы проверял не тот человек, создававший исходный список. Дело в том, что длительной работе с требованиями "глаз замыливается" и трудно самостоятельно их оценить. Проверку требований проще поручать старшему аналитику, начальнику отдела аналитики, техническому директору или тестировщику. <br />
<br /></div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-76226992825874641702011-08-22T23:25:00.000+04:002011-08-22T23:25:17.726+04:00Где и как взять требования по проекту<div dir="ltr" style="text-align: left;" trbidi="on"><b>Источники требований</b><br />
<br />
<ul style="text-align: left;"><li>Фирма-заказчик и ее контактные лица. Это основной источник. Только он может рассказать что же надо делать. В частности, заказчик может представить описание бизнес-процессов, регламенты работы, и самое главное - представления заказчика о проекте. </li>
<li>Законодательство и нормативные акты. Это важно. Мы даже не задумываемся о влиянии законодательства на проекты, а зря. Например, если в проекте требуется указать имя/фамилию, то пользователь должен дать согласие на обработку персональных данных. </li>
<li>Анализ конкурентов. Помогает найти действительные конкурентные преимущества того или иного проекта или продукта. Часто этим пунктом пренебрегают и зря. </li>
</ul><div><b>Извлечение требований</b></div><div><a name='more'></a>Основные методы:</div><div><br />
<ul style="text-align: left;"><li>Интервью. Иначе говоря, расспросы заказчика и всех заинтересованных лиц. </li>
<li>Анкетирование. Заказчик должен ответить в письменном виде на вопросы в виде тестов или в свободной форме. От правильно поставленных вопросов сильно зависит успешность проекта. </li>
<li>Наблюдение за деятельностью. Это используется в тех случаях, когда надо автоматизировать сложный процесс. </li>
<li>Анализ документов и документации. Сюда входит как анализ законодательства, так и анализ процессов в самой фирме-заказчике. </li>
<li>Мозговой штурм. Этот метод используется по принципу "А давайте решим, что в проекте еще не хватает"</li>
<li>Сценарии и <a href="http://foranalysts.blogspot.com/2011/08/blog-post_12.html">прототипирование</a>. Позволяет определить действительно ли все требования учтены, но, к сожалению, приходится тратить очень много сил. </li>
<li>Встречи с клиентов "Правильно ли мы понимаем, что вам нужно?". Позволяет на ранних этапах скорректировать как сами требования, так и их приоритеты. </li>
</ul></div><div><br />
</div><div>Для каждого метода есть свои особенности и секреты. В целом, ничего сложного ни в одном методе нет, надо только их грамотно и к месту применять. </div><div><br />
</div><div>На этапе выявления требований самое важное - это их записывать. Классифицировать, обрабатывать, задавать приоритет, удалять дубликаты это все позже, на этапе анализа требований. </div><div>При записи требований очень удобно их нумеровать и вести в табличном виде:</div><div>Номер | Краткое описание (название) | Откуда взялось это требование | Полное описание.<br />
<br />
При фиксации требований лучше сразу их записывать в максимально проверяемом виде и учитывать их <a href="http://foranalysts.blogspot.com/2011/08/blog-post_18.html">характеристики</a>.<br />
При получение комплекта требований важно также записывать откуда оно взялось. Потому что одно дело требование высказал работник непосредственно автоматизируемого участка и совсем другое дело, если начальник департамента, состоящего из множества отделов.<br />
<br />
</div><div><br />
</div><div><br />
</div><div><br />
</div><br />
<br />
<br />
</div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-2473598710901660752011-08-21T23:55:00.000+04:002011-08-21T23:55:19.518+04:00Атрибуты качества программного обеспечения<div dir="ltr" style="text-align: left;" trbidi="on"><span class="Apple-style-span" style="background-color: white; color: #282828; font-family: Arial, sans-serif; font-size: 12px; line-height: 18px;"></span><br />
Про атрибуты качества рассказывалось <a href="http://foranalysts.blogspot.com/2011/08/blog-post_17.html#more">здесь</a>. Если рассмотреть эту группу более внимательно, то можно выделить основные группы:<ul style="text-align: left;"><li>runtime - это атрибуты, относящиеся ко времени работы приложения или системы; </li>
<li>design определяет ключевые аспекты проектирования приложения или системы.</li>
</ul><br />
В общем случае, каждая из групп влияет на другую. Рассмотрим их подробнее. <span class="Apple-style-span" style="background-color: white; color: #282828; font-family: Arial, sans-serif; font-size: 12px; line-height: 18px;"><br />
</span><br />
<a name='more'></a><b>Группа runtime. </b>Иначе говоря, требования из этой группы возникают на этапе проектирования и решения, принимаемые по этой группе очень трудно и дорого менять. <div><b>Надежность</b> - требование, описывающее поведение приложения или системы в нештатных ситуациях (примеры: автоматический перезапуск, восстановление работы, сохранение данных, дублирование важных данных, резервирование логики).<br />
<b>Доступность</b> - атрибут качества, определяющий время непрерывной работы приложения или системы. Чтобы определить этот параметр, обычно указывают максимально допустимое время простоя системы.<br />
<b>Требования к времени хранения данных</b> Чтобы определить этот параметр, указывают продолжительность хранения данных. При этом, надо иметь в виду, что требования по времени хранения бывают двух видов:</div><div><ul style="text-align: left;"><li>хранить всегда пока проект существует. Например, данные пользователя. </li>
<li>хранить ограниченное время. Например, результаты какого-либо запроса пользователя можно хранить только во время сессии. </li>
</ul></div><div><div><b>Гибкость/Масштабируемость</b> - требования к горизонтальному и/или вертикальному масштабированию приложения или системы.К требованиям вертикальной масштабируемости могут относиться, например, возможность переноса приложений на более мощные системы, поддержка большого объема памяти и файлов. К требованиям горизонтальной масштабируемости могут относиться, например, возможность использования технологий кластеризации.<br />
Вертикальное масштабирование обычно направлено на повышение производительности системы. Горизонтальное масштабирование, помимо производительности, позволяет повысить отказоустойчивость системы. <br />
<b>Требования к удобству использования</b> системы/приложения (с точки зрения пользователя) и требования к удобству и простоте поддержки (Usability)<br />
<b>Требования к безопасности (целостность проекта)</b>, включают в себя три большие категории: </div><div><ul style="text-align: left;"><li>требования, связанные с разграничением доступа, </li>
<li>требования, связанные с работой с приватными данным, </li>
<li>требования, направленные на снижение рисков от внешних атак</li>
</ul></div><div><b>Требования к конфигурируемости</b> приложения, взаимодействия и расположения компонентов можно условно разделить на четыре уровня:<br />
1. конфигурируемость на основе предопределенного набора параметров (predefined configurability), когда необходимый уровень модификации достигается путем изменения значений параметров из предопределенного набора;<br />
2. конфигурируемость на основе предопределенного набора базовых объектов (framework constrained configurability), когда необходимый уровень модификации достигается путем перекомпоновки предопределенного набора процессов, сущностей и служебных процедур;<br />
3. конфигурируемость путем реализации новых базовых объектов (basis reimplementation), когда обеспечивается расширение набора процессов и сущностей;<br />
4. конфигурируемость путем новой реализации системы (system reimplementation), когда система должна устанавливаться и настраиваться с нуля.<br />
<b>Требования к производительности</b> <b>решения</b>, иначе говоря, эффективность решения определяется в терминах количества одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, а также скорости и пропускной способности каналов связи. А также ограничения, накладываемые на объем доступной памяти, процессорного времени, дискового пространства, пропускную способность сети, при которых приложение должно эффективно выполнять возложенные на него задачи.</div><div><br />
<b>Группа design time </b>или требования, которые могут быть изменены в процессе разработки или эксплуатации<br />
<b>Требования к повторному использованию реализации или компонентов</b> приложения или системы (Reusability). Такие требования возникают там, где общие компоненты используются несколькими модулями разрабатываемой системы.<br />
<b>Требования к расширяемости</b> (Extensibility) приложения или системы в связи с появлением новых функциональных требований. Сильно пересекается с требованиями масштабируемости проекта.<br />
<b>Требования к переносимости</b> (Portability) приложения или системы на другие платформы.<br />
<b>Требования к взаимодействию между компонентами</b> решения, между внешними компонентами, использование стандартных протоколов и технологий взаимодействия (Interoperability). Это возможность использования нескольких стандартных протоколов для обмена данными между одной из подсистем разрабатываемой системы и внешней системой-поставщиком данных<br />
<b>Требования к поддержке системы или приложения</b> (Supportability). Среди этих параметров могут быть названы такие как, например, дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе<br />
<b>Требования к модульности приложения или системы</b> (Modularity). Обычно такие требования указывают, каким образом система должна быть разделена на модули, или перечисляют список обязательных модулей, которые должны входить в состав системы.<br />
<b>Требования к возможности тестирования</b> (Testability) приложения или системы определяют объем требований к автоматическому и ручному тестированию, наличие необходимого инструментария<br />
<b>Требования к возможности и простоте локализации</b> (Localizability) приложения или системы определяют возможности и специфические архитектурные требования, накладываемые процессом локализации. Эти требования содержат также перечень языков, на которые предполагается выполнять локализацию приложения или системы<br />
<b>Требования к совместимости между версиями приложений, между различными приложениями и внешними подсистемами</b> (Compatibility) определяют предыдущие версии продукта или системы, а также список версий внешнего ПО, с которыми должны быть совместимы разрабатываемый продукт или система.<br />
<br />
<br />
<br />
</div></div><div><br />
</div><div>При подготовке этой статьи использовались следующие материалы:</div><div><a href="http://softwarepeople.ru/blog/2011/07/11/non-functional-requirements01/">Нефункциональные требования к ПО</a></div><div>Карл Вигерс. Разработка требований к ПО.</div><div><a href="http://www.system-approach.ru/downloads/09-QA-intro.pdf">Введение в использование атрибутов качества</a></div><div><br />
</div></div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-81250123118883355562011-08-21T22:36:00.002+04:002011-08-21T23:58:39.575+04:00Виды нефункциональных требований<div dir="ltr" style="text-align: left;" trbidi="on"><a href="http://foranalysts.blogspot.com/2011/08/blog-post_17.html">Расширение предыдущего поста</a><br />
К требованиям атрибутов качества ПО относят требования FURPS или FURPS+. Эта модель требований представлена Грейди и Касуэлл, работающими в тот момент времени в компании Hewlett-Packard.<br />
FURPS:<br />
<ul style="text-align: left;"><li>Функциональность (Functionality). Какие функции должны быть в системе. </li>
<li>Удобство использования (Usability). Удобство работы пользователей. </li>
<li>Надежность (Reliability). Устойчивость к отказам. </li>
<li>Производительность (Performance). Скорость, эффективность, потребление ресурсов, пропускная способность, время отклика.</li>
<li>Сопровождаемость (Supportability). Все вместе: Тестируемость, расширяемость, адаптируемость, ремонтопригодность, совместимость, настраиваемость, удобство обслуживания, локализуемость, портативность.</li>
</ul><div style="text-align: left;">"+" означает добавление требований по интерфейсным решениям, дизайну и реализации.<br />
В целом, создание аналитической документации по модели FURPS+ позволяет создать качественно документированный проект. </div><div style="text-align: left;"><br />
</div></div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-10596091166099494892011-08-21T14:43:00.000+04:002011-08-21T14:43:06.424+04:00Сертификация и руководства<div dir="ltr" style="text-align: left;" trbidi="on"><a href="http://www.apkit.ru/committees/education/meetings/standarts.php">стандарты Ассоциации предприятий компьютерных и информационных технологий </a><br />
<br />
<a href="http://swebok.sorlik.ru/software_engineering.html">SWEBOK: Руководство к своду знаний по программной инженерии</a><br />
<br />
<a href="http://www.theiiba.org/AM/Template.cfm?Section=Body_of_Knowledge&Template=/CM/HTMLDisplay.cfm&ContentID=4926">BABOK:Руководство к Своду знаний по бизнес-анализу</a><br />
<br />
<a href="http://www.pmi.org/PMBOK-Guide-and-Standards/Standards-Library-of-PMI-Global-Standards.aspx">Руководство PMBOK: Свод знаний по управлению проектами</a><br />
<br />
<br />
</div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-13964195651282761612011-08-18T22:37:00.000+04:002011-08-18T22:37:29.690+04:00Характеристики требований<div dir="ltr" style="text-align: left;" trbidi="on">Продолжение серии статей о требованиях. <a href="http://foranalysts.blogspot.com/2011/08/blog-post_17.html">Часть 2</a>.<br />
Требования должны обладать следующими характеристиками:<br />
1. <b>Единичность</b>. Это означает, что требование относится только к одному свойству. Например, система должна выполнять такое-то действие. Пример хорошего требования: система должна позволять регистрацию пользователей. Пример плохого требования: система должна позволять авторизацию пользователей по данным социальных сетей и запрашивать из социальных сетей и публиковать на стене пользователя в социальной сети определенную информацию. Почему это требование некорректное - не указаны социальные сети, а далеко не все разрешают сторонним приложения размещать информацию на стене пользователя, а, во-вторых, тут объединены два требования. <div><a name='more'></a></div><div><br />
</div><div>2. <b>Атомарность</b>. Атомарность означает, что требования дальше нельзя разбить или уточнить. Например, пользователь может авторизоваться с помощью <конкретный список социальных сетей>. Плохое требование: пользователь может выбрать статью для чтения и прокомментировать ее. Это два требования, которые надо разбивать и конкретизировать дальше. </div><div><br />
</div>3. <b>Завершённость</b>. Требование целиком приведено в одном месте документации. Не должно быть такого, чтобы в разных частях документа с требованиями шла речь об одном и том же функционале. <div><br />
</div><div>4. <b>Последовательность</b>. Требование не должно противоречить другим требованиям и ограничениям системы. Пример плохого требования: система должна запрашивать из социальных сетей адрес электронной почты пользователя. Дело в том, что социальные сети не дают такой информации. Если требуется адрес электронной почты пользователя, то он должен быть запрошен от самого пользователя, а не от внешних источников. </div><div><br />
</div><div>5. <b>Отслеживаемость (Трассируемость)</b>. Это означает, что требования зафиксировано в документации и можно понять откуда оно взялось. Например, требование подтверждения возраста это требование этического комитета заказчика. </div><div><br />
</div><div>6. <b>Актуальность</b>. Это означает, что требование не устарело. Например, требование должно соответствовать современному законодательству. Или техническим реалиям. Вряд ли сейчас найдется много пользователей IE5 и Netscape Navigator. </div><div><br />
</div><div>7. <b>Выполнимость</b>. Требование можно выполнить в рамках существующих технологий. Например, можно требовать, чтобы система давала отклик при маленькой нагрузке ( что такое маленькая нагрузка тоже надо конкретизировать) в течение не более 3-х секунд, но нельзя требовать 1 миллисекунду при больших нагрузках. </div><div><br />
</div><div>8. <b>Понятность</b>. Это означает, что нельзя использовать жаргон, фраза должна пониматься всеми одинаково. Т.е. фраза "казнить нельзя помиловать" не должна использоваться.</div><div><br />
</div><div>9. <b>Проверяемость</b>. Это означает, что выполнение требования можно проверить. Пример плохого требования: система должна работать быстро. Или сайт должен иметь понятную систему навигации. Или должен использовать интуитивно-понятный интерфейс. Кстати, на будущее, я напишу отдельную статью по поводу того, что не бывает интуитивного-понятного интерфейса. </div><div><br />
</div><div>10. <b>Обязательность</b>. Без выполнения этого требования пользователь не сможет в полной мере использовать систему. Не самое простое условие к требованию, между прочим. Например, рассмотрим интернет-магазин. Обычно, требования расписываются с точки зрения пользователя: посмотреть описание товара, выбрать товар, оформить заказ и прочее. Но в данном случае необходимым требованиями будут возможность добавления нового товара на витрину и удаление с витрины товара, которого нет в наличии. </div><div><br />
</div><div>11. <b>Полнота</b>. Самое сложное требование. Полнота системы требований – свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает все то, что требуется от разрабатываемой системы. Иначе говоря, надо зафиксировать все, что система должна делать. Если на начальном этапе это не указать, то можно сильно ошибиться при проектировании и выборе архитектуры. При этом, надо понимать, что очень трудно сразу указать для системы, которую еще только надо спроектировать, весь функционал. Поэтому, часто на первых этапах указывают требования крупными мазками, а не в терминах функциональных требований. </div><div><br />
</div><div>При фиксации требований очень важно не делать такую ошибку, как формулировать требования в виде "как система должна работать". Надо использовать подход "что система должна делать". Пример плохих требований: Пользователь нажимает красную кнопку в углу формы и переходит на следующий этап выбора товара в интернет-магазине. Пример хорошего требования: при выборе определенного товара пользователю предлагается перейти в корзину для оформления заказа или продолжить просмотр каталога. Дело в том, что вариантов реализации может быть множество и не надо заранее себя ограничивать. Более того, очень важно избегать субъективного подхода. Если что-то удобно именно вам, это не означает, что удобно всем. </div><div><br />
</div><div><br />
</div><div><br />
<div><br />
</div></div></div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-12034269142544092082011-08-17T00:42:00.003+04:002011-08-21T23:56:53.022+04:00Виды требований<div dir="ltr" style="text-align: left;" trbidi="on"><div style="text-align: left;">Продолжаем разговор о требованиях. <a href="http://foranalysts.blogspot.com/2011/08/blog-post_15.html">Часть 1</a></div><div style="text-align: left;">Повторим, что такое требование:</div><ul style="text-align: left;"><li>Условие или возможность, требуемая пользователем для решения задач или достижения целей.</li>
<li>Условие или возможность, которыми система/компонент системы должна обладать для обеспечения условий контракта, стандартов, спецификаций или др. регулирующими документами.</li>
<li>Описание условий или возможностей, перечисленных в предыдущих пунктах.</li>
</ul>Кратко: требование это зафиксированное желание пользователя, которое должна выполнять система. <br />
<div>Это определение неидеально. Потому что есть требования, которые пользователь явно не высказывает, например, работа системы в режиме 24/7, или пользователь высказал какое-нибудь пожелание, но оно не было реализовано. Особый случай: требование высказано в устной форме. На мой взгляд, если требование не зафиксировано в письменном виде, то оно не существует. </div><div>Требования можно разделить на две большие группы: </div><div style="text-align: left;"><ul style="text-align: left;"><li>функциональные требования</li>
<li>нефункциональные требования</li>
</ul><a name='more'></a></div><div><br />
</div><div><br />
</div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPKaBGoDSKhD2zUc4yvSdiuhEqmqbf5MDhv4V05xHWgd8CFTzsq40NYJHpBvjNI5DmSEZYmmCDrutU1m-Qo7K-Zi51Dv0g0BEMIUZayTHQrTkbr2xAMsNbdq2mRJeZws8YJnWQ4CtXjKg/s1600/requirements_wiegers.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="306" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPKaBGoDSKhD2zUc4yvSdiuhEqmqbf5MDhv4V05xHWgd8CFTzsq40NYJHpBvjNI5DmSEZYmmCDrutU1m-Qo7K-Zi51Dv0g0BEMIUZayTHQrTkbr2xAMsNbdq2mRJeZws8YJnWQ4CtXjKg/s400/requirements_wiegers.jpg" width="400" /></a></div><div style="text-align: left;"><br />
</div><div><br />
</div><div><br />
</div><div><br />
</div><div><br />
</div><div><br />
</div><div><br />
</div><div><br />
</div><div><br />
</div><div><br />
</div><div><br />
</div><div><br />
</div><div><br />
</div><div><br />
</div><div><br />
</div><div style="text-align: left;"><br />
</div><div style="text-align: left;"><br />
</div><div style="text-align: left;"><br />
</div><div style="text-align: left;"><br />
</div><div style="text-align: left;">На картинке показано как разделение требований по группам, так и документы, в которых требования фиксируются. </div><div style="text-align: left;"><b>Функциональные требования</b> - что система должна делать. </div><div style="text-align: left;">К функциональным требованиям относят:</div><div style="text-align: left;"><ul style="text-align: left;"><li>Бизнес-требования. Что система система должна делать с точки зрения бизнеса. Слово "бизнес" в данном контексте ближе к слову "заказчик". Пример бизнес-требования: промо-сайт, привлекающий внимание определенной аудитории к определенной продукции компании. </li>
<li>Пользовательские требования – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases). Иначе говоря, пользовательские требования - это что может сделать пользователь: зарегистрироваться, посмотреть определенную информацию, пересчитать данные по определенному алгоритму и прочее.</li>
<li>Функциональные требования – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. Другими словами, что будут делать разработчики, чтобы выполнить пользовательские требования. </li>
</ul><div>В группу функциональных требований относят и <b>системные требования</b>. Эти характеристики могут описывать требования как к аппаратному обеспечению (тип и частота процессора, объём оперативной памяти, объём жесткого диска), так и к программному окружению (операционная система, наличие установленных системных компонентов и сервисов и т. п.). Обычно такие требования составляются производителем или автором ПО. Например, для игры это могут быть требования такого типа: видеокарта - объём памяти от 64 Мб, совместимость сDirectX 9.0b и новейшие драйвера. Для сайта: ОС - Windows не ниже XP, браузеры IE не ниже 7.0 и так далее.</div><div><br />
</div><div>Почему важно указывать системные требования и утверждать их у заказчика? Если не указать, например, что важно обеспечить просмотр сайта в IE 6, то разработчики вполне могут выбрать такое архитектурное решение, которое не позволит корректно отображать сайт. Системные требования напрямую зависят от целевой аудитории проекта. </div><div><br />
</div><div>Вторая группа требований это <b>нефункциональные требования</b>. Иначе говоря, как будет работать система и почему именно так. </div><ul style="text-align: left;"><li>Бизнес-правила. Они определяют почему система работать должна именно так, как написано. Это могут быть ссылки на законодательство, внутренние правила заказчика и прочие причины. Часто упускают этот раздел и получается, что некоторые системные решения выглядят нетипичным и совсем неочевидными. Например, многие табачные компании и компании, производящие алкоголь требуют постоянного доказательства того, что промо-сайтами пользуются люди, достигшие определенного возраста. Это бизнес-правило (подтверждение возраста) возникает по требованию этических комитетов заказчика, хотя и несколько противоречит маркетинговым целям и требованиям по usability. </li>
<li>Внешние интерфейсы. Это не только интерфейсы пользователя, но и протоколы взаимодействия с другими системами. Например, часто сайты связаны с CRM системами. Особенности протокола взаимодействия "сайт-CRM" также относятся к нефункциональным требованиям. </li>
<li>Атрибуты качества. Атрибуты касаются вопросов прозрачности взаимодействия с другими системами, целостности, устойчивости и т.п. К таким характеристикам относятся:</li>
<ul><li>легкость и простота использования (usability)</li>
<li>производительность (performance)</li>
<li>удобство эксплуатации и технического обслуживания (maintainability)</li>
<li>надежность и устойчивость к сбоям (reliability)</li>
<li>взаимодействия системы с внешним миром (interfaces)</li>
<li>расширяемость (scalability)</li>
<li>требования к пользовательским и программным интерфейсам (user and software interface).</li>
</ul></ul><a href="http://foranalysts.blogspot.com/2011/08/blog-post_4853.html">Более подробно про атрибуты качества</a><br />
<ul style="text-align: left;"><li>Ограничения – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, ...). Ограничения часто основываются на бизнес-правилах.</li>
</ul><div style="text-align: left;">Относительно состава групп функциональных и нефункциональных требований до сих пор нет согласия. Разные авторы и эксперты могут как добавлять, так и исключать подгруппы требований. Например, часто ограничения объединяют с бизнес-правилами, а бизнес-требования объединяют с ключевыми потребностями.<br />
<br />
Существует прекрасная методика <a href="http://foranalysts.blogspot.com/2011/08/blog-post_3440.html">FURPS+</a>, позволяющая создать качественную документацию при разработке ПО сколь угодно большой сложности. </div><div style="text-align: left;"><br />
</div><div style="text-align: left;">Все вышесказанное относится только к дисциплине "Управление требованиями" в рамках методологии RUP. В рамках ГОСТ и определения требований другие и сами требования разбиваются на совершенно другие группы.<br />
<br />
<a href="http://foranalysts.blogspot.com/2011/08/blog-post_18.html">Читать про характеристики требований</a></div><div><br />
</div></div></div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-27076312763320371702011-08-15T22:00:00.002+04:002011-08-18T21:20:05.879+04:00Требования к ПО<div dir="ltr" style="text-align: left;" trbidi="on">Относительно управления требованиями уже написано много статей, существует много книг и подкастов. Но там редко встретишь самое главное: что такое требование и зачем оно нужно. <b>Требования к программному обеспечению</b> — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Т.е. фактически, что система должна делать.<br />
<div>Сайт с конкурсом это не требование. Требование в данном случае - сайт должен позволять пользователю:</div><div>1) идентифицировать себя. Иначе никто не сможет узнать, что выиграл именно этот пользователь</div><div>2) участвовать в конкурсе. Пока еще не уточняется что это за конкурс, что там пользователь будет делать и как. Пока обозначим самое главное - участие. </div><div>3) получить результаты. Тем или иным способом. В почту, на стену в социальной сети, на странице сайта. Пока неважно. </div><div>Это описание требований крупными мазками. </div><div><a name='more'></a>Потом уже можно конкретизировать существующие требования. </div><div>Разберем другой вид "требований": система должна работать быстро и не падать. Это не требование. Требованием в данном случае будут:</div><div>система должна предоставлять отклик в течение <определенное время><br />
система должна восстанавливаться в течение <определенное время>.</div><div><br />
</div><div>Поэтому, в управлении требованиями самое важное - это правильно записать требования, а потом уже их анализировать, и уж тем более ими управлять.<br />
Следующая статья: <a href="http://foranalysts.blogspot.com/2011/08/blog-post_17.html">Виды требований</a></div></div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-66991264006324645642011-08-12T21:15:00.001+04:002011-08-12T21:15:55.994+04:00Прототипирование<div dir="ltr" style="text-align: left;" trbidi="on"><b>Надо или не надо делать прототип?</b><br />
Компания, в которой хоть раз сделали прототип и сэкономили время и силы на разработке, будет делать его и в других проектах.<br />
Компания, в которой раньше прототипы не делались, очень плохо и трудно приходит к мысли, что прототипы необходимы.<br />
На самом деле, прототипы практически всегда очень желательно делать. Но не всегда нужны именно динамические прототипы. Более того, создание динамического прототипа может потребовать не меньше усилий, чем создание работающего варианта. В таких случаях достаточно нарисовать формы и разметить положение и размер всех элементов.<br />
<br />
<a name='more'></a><br />
<br />
<br />
<b>Какие прототипы бывают</b><br />
В основном, под прототипом понимают динамическую форму, гораздо реже используются статические прототипы.<br />
Иногда в качестве прототипа вполне сойдет и пара-тройка основных форм.<br />
<br />
<b>Как можно делать прототип?</b><br />
1. На бумаге. Рисовать, раскрашивать. Достоинства:- быстро, просто, можно делать в любом месте. Недостатки: постоянно приходится переделывать, нет возможности сразу внести много изменений.<br />
2. Макетирование на бумаге. Заранее составляются основные элементы, которые потом раскладываются на бумаге в определенных местах. Достоинства: быстро, просто, позволяют прийти к согласию относительно расположения основных блоков. Недостатки: трудно оценить размеры блоков, требует значительной переработки в дальнейшем.<br />
3. Создание прототипа в какой-нибудь программе из офисных пакетов. Достоинства: офисные пакеты стоят практически на всех ПК, создается быстро, позволяет легко менять цветовую гамму, расположение блоков и их размер. Недостатки: в офисных пакетах нет большого количества стандартных форм, нельзя создать динамический прототип.<br />
4. В специальных программах для создания прототипов. Достоинства: большое количество стандартных форм, возможность легкого изменения размеров и расположения блоков, возможность создания динамического прототипа. Недостатки: платность программ, нужно время на их освоение, трудность при создании своих элементов.<br />
5. С помощью средств разработки. Такие прототипы, чаще всего, делаются при разработке ПО. Они позволяют быстро определить расположение основных элементов на экране. Достоинства: наглядность и возможность оценить как это все будет выглядеть для пользователя. Недостатки: необходимо уметь пользоваться средой разработки, а так же ее установка на локальном ПК.<br />
6. В какой-нибудь программе для дизайна. Достоинства: можно подобрать красивые цветовые и визуальные решения. Недостатки: нельзя сделать динамический прототип, необходимо серьезное владение программой.<br />
<br />
<b>В какой последовательности делается прототип?</b><br />
1. Собираются требования от заказчика. Определяется суть проекта.<br />
2. Составляется предварительный список страниц/экранных форм проекта.<br />
3. Определяются основные элементы каждой страницы или экранной формы.<br />
4. Определяется цель и глубина прототипа (статический или динамический, определение необходимости создания прототипа сразу в нужной цветовой гамме, надо ли отрисовывать все варианты реакций на событие в случае динамического прототипа). Например, страница регистрации пользователя на сайте. В случае неправильного заполнения полей должно выводиться сообщение об ошибке. При создании динамического прототипа можно сделать отдельные реакции на каждый вариант ошибки, что потребует много сил и времени, а можно просто учесть, что сообщение об ошибке требует места для вывода.<br />
5. Создание прототипа.<br />
6. Редактирование прототипа и документации по проекту.<br />
<br />
Пропуск стадий 2-4 приводит к лишней трате сил и времени. При создании прототипа необходимо очень четко понимать для кого он создается.<br />
Если прототип создается для утверждения у заказчика, то он требует более детальной проработки.<br />
Если прототип создается для разработчиков, то цветовая гамма вряд ли нужна, можно обойтись стандартным оформлением, но требуется проработка всех реакций управляющих элементов.<br />
Если прототип создается для того, чтобы менеджер проекта в деталях представлял все особенности проекта, то не требуется ни особой глубины проработки, ни использование нужной цветовой гаммы и вида элементов.<br />
<br />
<br />
<b>О чем важно помнить при создании прототипа</b><br />
<i>Навигация</i>. И не только средствами браузера. Прототип должен обеспечивать понятную навигацию по проекту.<br />
<i>Дизайн</i>. Если сделать качественный прототип, то дизайнер может ограничиться только его раскраской вместо предложения именно дизайна. Иногда дизайнеры плохо смотрят на прототип и при создании макетов убирают какие-либо блоки. Общего решения этой проблемы нет и быть не может. Можно для создания первого макета дизайнеру только обозначить список основных блоков, а потом уже доделывать макеты с учетом прототипа.<br />
<i>Заказчик</i>. Многие заказчики, глядя на прототип, не видят последующего за ним окончательного решения. Им кажется, что все так и останется и они недовольны убожеством проекта. Или, наоборот, заказчик не хочет смотреть на прототип, требует показать ему уже функционирующий проект. На самом деле, имеет смысл все-таки показать заказчику и выслушать его замечания. Другое дело, что прототип не должен отдаваться на растерзание всей фирме заказчика. Мнение бухгалтера или завхоза не должно приниматься в разработку без особых на то причин.<br />
<i>Документация</i>. Прототип не служит заменой техническому заданию. Прототип дополняет, но не заменяет ТЗ. Должно быть и то и другое.<br />
<i>Разработчики</i>. Разработчики, получив для изучения прототип могу более адекватно оценить трудоемкость и связность проекта. При этом, разработчики часто ленятся читать ТЗ. Но все моменты невозможно отразить в прототипе, поэтому разработчик должен получить и комплект документов. В конце проекта, когда выяснится, что разработчик сделал все по прототипу, но не сделал то, что описано в документации, может возникнуть конфликт. С другой стороны, прототип помогает разработчику наглядно понять и представить, что он должен сделать, а это часто трудно после прочтения только текстов.<br />
<br />
<br />
Ссылки по теме:<br />
1. <a href="http://habrahabr.ru/blogs/ui/18696/">Результаты опросов и исследований на хабре</a><br />
2. <a href="http://habrahabr.ru/qa/4089/">Много полезного в комментариях</a><br />
3. <a href="http://www.amazedev.com/prototyping_tools_site2009_presentation/">Обзор средств прототипирования в блоге, посвященному юзабилити</a><br />
4. <a href="http://blog.dvteam.ru/?p=15">Еще один инструмент прототипирования</a><br />
5. <a href="http://uibook2.usethics.ru/">«Дизайн пользовательского интерфейса2 Искусство мыть слона» — это электронная книга о дизайне пользовательских интерфейсов</a><br />
6. <a href="http://gui.ru/">Очень интересный сайт, посвященный gui. Много материала</a><br />
7. <a href="http://vremenno.net/design/illustrator-wireframing-2/">Общие советы относительно прототипирования</a><br />
8. <a href="http://habrahabr.ru/blogs/ui/70001/">Сводная таблица средств прототипирования</a></div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-21410591735715189652011-08-11T20:41:00.000+04:002011-08-11T20:41:26.886+04:00Какие вопросы не решает аналитик<div dir="ltr" style="text-align: left;" trbidi="on">На разные проектах в разных организациях на аналитика возлагают решение совершенно разных вопросов.<br />
Где-то достаточно написать хорошую концепцию, где-то необходимо расписывать подробным образом поведение пользователя и реакцию всех управляющих элементов. Но есть вопросы, которые лежат обычно вне компетенции аналитика.<br />
<br />
<a name='more'></a><br />
<br />
Например, аналитик не должен решать какую цветовую гамму использовать на проекте, как должны выглядеть кнопки.<br />
Более того, аналитик не должен принимать решения о размещении управляющих элементов на странице. Единственное, что касается аналитика - это список управляющих элементов на странице и их реакция на действие пользователя. Другое дело, что если на проекте нет дизайнера и специалиста по usability, то такие вопросы просят решить аналитика.<br />
<br />
Также часть вопросов лежит на менеджере проекта. Например, какое-то действие должно происходить с определенной периодичностью. Если нет необходимости использования результатов этого действия в других местах, то аналитик может указать только цикл - раз в сутки, раз в неделю и так далее. Но решение о том в какое конкретное время должно происходить действие, особенно, если оно отличается от стандартных начала календарных суток, должен принимать не аналитик. Хотя здесь все зависит от деталей проекта.<br />
<br />
Еще часть вопросов лежит вне компетенции аналитика - проектирование. Какие классы будут, как будет организована передача информации от одного объекта к другому.<br />
Если проект очень большой, то необходимо вести учет классов и объектов, а также типов сообщений, которыми могут обмениваться объекты. Такая работа также выпадает из поля деятельности аналитика.<br />
<br />
Отдельный вопрос про прототипирование проекта. С одной стороны, аналитику проще всего по своей документации составить действующий прототип. С другой стороны, так как "глаз уже замылен", то трудно отследить недостатки собственноручно написанной документации, поэтому, желательно отдавать прототипирование другому человеку. </div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-43235752254267409112011-08-10T23:49:00.002+04:002011-08-10T23:57:42.994+04:00Какая документация должна сопровождать проект<div dir="ltr" style="text-align: left;" trbidi="on">Прежде всего, надо определить кто пишет и с какой целью.<br />
ПМ (руководитель проекта) пишет документацию с точки зрения управления. Т.е. ПМ оценивает какие стадии у проекта, их трудоемкость и предварительную стоимость.<br />
Для этого ПМ должен очень хорошо представлять что именно будет сделано, поэтому его оценка основывается на аналитических документах.<br />
К аналитическим документам относятся:<br />
<br />
<ol style="text-align: left;"><li>Business vision. В этом документе кратко обозначается цели и задачи проекта, для кого он делается и какой примерной функционал будет реализован в проекте. Здесь же может указываться как проект будет развиваться. </li>
<li>Системная документация (ТЗ, пояснительные записки, функциональная и нефункциональная спецификация). Выбор формы и типов документа зависит от целей проекта, предпочитаемой методологии (ГОСТ, RUP, MSF)</li>
<li>Прототип, если он создается. Необходимость создания прототипа сильно зависит от проекта, его сложности и предпочтений команды разработки.</li>
</ol><div><a name='more'></a></div><div>Документ, который составляют очень редко, но я не видела проекта, в котором он был бы не нужен - guide line (руководство по стилю). В этом документе указываются рекомендованные цвета, виды кнопок и управляющих элементов, шрифты и их размеры. Этот документ нужен для того, чтобы проект не страдал от смены дизайнера или от смены его цветовых предпочтений. </div><div><br />
</div><div>После создания аналитической документации наступает очередь документов проектировщика/архитектора. Проектировщик может разрабатывать документацию по классам/объектам, которые необходимо будет сделать в рамках объекта, прописывает их взаимодействие. </div><div>Архитектор подбирает и описывает техническое решение. </div><div><br />
</div><div>Одновременно с проектировщиком/архитектором может начинаться работа по созданию тестовой документации. Сюда входят тест-сеты, тест-планы и так далее.<br />
<br />
Также может создавать пользовательская документация: руководство пользователя, руководство разработчика, руководство администратора системы, руководство модератора и так далее.</div><div><br />
</div><div>Чем грозит пропуск отдельных документов и целых блоков?</div><div>И ничем и всем сразу. </div><div>Если проект маленький и выполняется "на коленке" одним человеком, то можно вообще ничего не писать. </div><div>Но если проект чуть больше, чем создание своей странички в социальной сети, пропуск стадии создания документации приведет к тому, что часть задумок и идей будет не реализована или реализована неправильно и/или с нарушением сроков и бюджета. </div><br />
<br />
</div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-8223049541441191972011-08-06T21:07:00.000+04:002011-08-06T21:07:21.373+04:00Блог о бизнес-моделировании<div dir="ltr" style="text-align: left;" trbidi="on"><a href="http://mainthing.ru/ru/">Много вкусного материала о бизнес-моделировании</a>.<br />
Также есть ссылки на сопутствующие блоги, сайты, семинары</div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5316747261753381493.post-47626470072802294432011-08-06T20:56:00.000+04:002011-08-06T20:56:34.568+04:00Bizagi Business Process Management (BPM)<div dir="ltr" style="text-align: left;" trbidi="on"><br />
<br />
Программа позволяет создавать схемы бизнес-процессов. <br />
<br />
Bizagi Process Modeler распространяется бесплатно, есть обучающее видео и подробные руководства пользователей. <div><a href="http://www.bizagi.com/index.php">Ознакомиться с программой </a></div></div>Unknownnoreply@blogger.com