1
ПО Аналитика / Re: Управление требованиями с помощью VS TFS 2010
« : 05 Декабря 2010, 11:54:12 »
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
2
Проектирование / Re: Использование ВИ диаграммы для описания сложных систем
« : 02 Февраля 2010, 15:26:15 »
Я воспринимаю ВИ как оглавление вначале книги, как нечто что помогает организовать структуру требований. И в этой роли ВИ для меня очень полезны. Поэтому все случаи, когда я сталкивался с большим количеством ВИ, с моей точки зрения это были примеры неправильно написаных ВИ (странно, когда оглавление больше чем книга).
Группировать диаграмму ИС на части, группируя по подсистемам – я не делаю.
Помню или могу себе представить 3 ситуации, когда это приходило (или могло прийти) в голову.
1-я ситуация:
Я наанализировал много ВИ, понял (или пообщался с проектировщиком) сколько у меня компонент в системе и хочу разложить все по полочкам.
Здесь проблемы в том, что:
1) ВИ компонентов - это ВИ другого уровня, они не соответствуют ВИ системы.
2) почти все ВИ системы, затрагивают несколько компонент, поэтому устанавливать принадлежность к какому-то одному компоненту некорректно.
Поэтому в любом случае придется перерабатывать ВИ.
2-я ситуация:
Перед началом анализа я решил «упростить» себе задачу анализа путем декомпозиции. По каким-то причинам мне понятно, сколько у меня компонент и я хочу выявлять и анализировать требования отдельно по компонентам.
Здесь у меня проблема в том, что мне не проще, а наоборот сложнее работать с компонентами:
1) Например, у меня два компонента: клиент и сервер. В процесс анализа незаметно вкрадывается задача проектирования взаимодействия между клиентом и сервером
2) Описывая требования для компонента легко потерять настоящие цели проекта.
Готов предположить, что после выполнения работы проектировать станет легче, но намного ли? Думаю, что в эту ситуацию попадают те, кто пытается совмещать роли аналитика и проектировщика.
3-я ситуация:
Мне все равно надо писать ТЗ на компоненты, т.к. компоненты будут изготавливливаться разными организациями.
Если такая ситуация возникла, нужно как-то справляться с проблемами описанными в пп. 1-2 , но в этом случае понятно зачем.
Группировать диаграмму ИС на части, группируя по подсистемам – я не делаю.
Помню или могу себе представить 3 ситуации, когда это приходило (или могло прийти) в голову.
1-я ситуация:
Я наанализировал много ВИ, понял (или пообщался с проектировщиком) сколько у меня компонент в системе и хочу разложить все по полочкам.
Здесь проблемы в том, что:
1) ВИ компонентов - это ВИ другого уровня, они не соответствуют ВИ системы.
2) почти все ВИ системы, затрагивают несколько компонент, поэтому устанавливать принадлежность к какому-то одному компоненту некорректно.
Поэтому в любом случае придется перерабатывать ВИ.
2-я ситуация:
Перед началом анализа я решил «упростить» себе задачу анализа путем декомпозиции. По каким-то причинам мне понятно, сколько у меня компонент и я хочу выявлять и анализировать требования отдельно по компонентам.
Здесь у меня проблема в том, что мне не проще, а наоборот сложнее работать с компонентами:
1) Например, у меня два компонента: клиент и сервер. В процесс анализа незаметно вкрадывается задача проектирования взаимодействия между клиентом и сервером
2) Описывая требования для компонента легко потерять настоящие цели проекта.
Готов предположить, что после выполнения работы проектировать станет легче, но намного ли? Думаю, что в эту ситуацию попадают те, кто пытается совмещать роли аналитика и проектировщика.
3-я ситуация:
Мне все равно надо писать ТЗ на компоненты, т.к. компоненты будут изготавливливаться разными организациями.
Если такая ситуация возникла, нужно как-то справляться с проблемами описанными в пп. 1-2 , но в этом случае понятно зачем.
3
Реализация / Re: Реализация шаблона MVC
« : 09 Ноября 2009, 17:20:28 »Однако я слышал, читал, видел - что MVC активно используется для веб-приложений. Фаулер даже напирал при этом как на особенность веб-приложений.
Видимо, Фаулер прочитал мой пост и передумал (и дату своей статьи задним числом поставил):
GUI Architectures - http://martinfowler.com/eaaDev/uiArchs.html
Есть непрофессиональный перевод этой статьи http://www.rusdoc.ru/articles/18358/.
В ней MVC - не очень рекламируется, а рекламируется MVP.
4
Тестирование / Re: Бакалаврская работа "Тестирование программ СИ, разработка ПО"
« : 03 Ноября 2009, 10:15:22 »
Важной составляющей тестирования является оценка покрытия ("Coverage tools"). Бесплатный инструмент я знаю только один http://sourceforge.net/projects/covtool .
Многие считают, что тестирование без анализа покрытия кода, как велосипед без руля.
Многие считают, что тестирование без анализа покрытия кода, как велосипед без руля.
5
Тестирование / Re: Бакалаврская работа "Тестирование программ СИ, разработка ПО"
« : 03 Ноября 2009, 10:06:15 »
Надо отметить, что тестирование бывает разных видов и для разных видов тестирования используются разные программы.
Как минимум тестирование бывает модульное, интеграционное, приемочное, нагрузочное.
Программы для модульного тестирования привязаны к языку программирования. (т.е. в гугл необходимо вводить "модульное тестирование с++" )
Программы для других видов тестирования привязаны не столько к языку программирования, сколько виду самого приложения: Windows ли это приложение, Web-приложение или Web-сервис. (т.е. в гугл необходимо вводить "тестирование windows приложений" и результаты будут иметь отношение к приложениям написанным в т.ч. на С++)
Для модульного тестирования программ на С++ существует много бесплатных и очень похожих фреймворков http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks. Среди них можно выделить относительно молодой "Google C++ Testing Framework" http://code.google.com/p/googletest/w/list , вобравший в себя много хороших техник из других фреймворков.
Бесплатными также являются фреймворки для создания "заглушек" при модульном тестировании, такие как Mockpp (http://mockpp.sourceforge.net) или "Google C++ Mocking Framework" (http://code.google.com/p/googletest/w/list)
Для остальных видов тестирования (применительно к с++) я имел отношение к тестированию только windows-приложений и только с помощью платной программы WinRunner.
Как минимум тестирование бывает модульное, интеграционное, приемочное, нагрузочное.
Программы для модульного тестирования привязаны к языку программирования. (т.е. в гугл необходимо вводить "модульное тестирование с++" )
Программы для других видов тестирования привязаны не столько к языку программирования, сколько виду самого приложения: Windows ли это приложение, Web-приложение или Web-сервис. (т.е. в гугл необходимо вводить "тестирование windows приложений" и результаты будут иметь отношение к приложениям написанным в т.ч. на С++)
Для модульного тестирования программ на С++ существует много бесплатных и очень похожих фреймворков http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks. Среди них можно выделить относительно молодой "Google C++ Testing Framework" http://code.google.com/p/googletest/w/list , вобравший в себя много хороших техник из других фреймворков.
Бесплатными также являются фреймворки для создания "заглушек" при модульном тестировании, такие как Mockpp (http://mockpp.sourceforge.net) или "Google C++ Mocking Framework" (http://code.google.com/p/googletest/w/list)
Для остальных видов тестирования (применительно к с++) я имел отношение к тестированию только windows-приложений и только с помощью платной программы WinRunner.
6
Реализация / Re: Задания разработчикам.
« : 30 Октября 2009, 09:29:18 »
положим, да, архитектурный дизайн.
Хочу узнать как результаты работы аналитика превращаются в задачи JIRA.
Хочу узнать как результаты работы аналитика превращаются в задачи JIRA.
7
Реализация / Задания разработчикам.
« : 29 Октября 2009, 16:30:55 »
Посоветуйте пожалуйста материалы (книги, статьи), в которых затрагиваются вопросы и приводятся примеры связанные с постановкой заданий разработчикам по результатам работы аналитика.
8
Реализация / Re: Реализация шаблона MVC
« : 29 Октября 2009, 15:24:09 »
Здравствуйте,
паттерн MVC наверное самый замученный паттерн. Собственно он перестал быть паттерном как таковым, сейчас можно говорить о семействе паттернов MVC. Можно ввести в codeproject.com запрос MVC и увидеть реализации с абсолютно непохожими друг на друга связями между M-V-C (собственно и сами M,V,C многие трактуют по-разному).
Это произошло из-за того, что паттерн в первоначальном виде (SmallTalk) для большинства задач просто неприменим. Паттерн жив, видимо, потому, что заложенная в нем идея вообще-то работает и способна приносить бизнес-эффект.
В оригинальном MVC: контроллер - это просто преобразователь движений мыши, прерываний от клавиатуры и в нечто осмысленное, вроде "нажата кнопка А". Ну просто не было во времена SmallTalk ни WinForms, ни MFC, ни Qt, ни даже TurboVision. Эти фреймворки это "C" и "часть V" из комлекта MVC. Эсли вы используете эти фреймворки, то вы реализуете "оставшуюся часть V" и "M". Попытка натянуть их снова на паттерн MVC порождает разночтения.
Единственное применение чистого MVC, которое я вижу сейчас - это консольное приложение: Model - бизнес-логика, Controller (модуль управляющий InputStream), View (модуль, управляющий OutputStream).
Когда сегодня говорят MVC (Ruby on Rails, MVC.Net, Castle.Net) на самом деле имеют ввиду Model View Presenter. Где View, наконец-то получил право иметь методы вида OnButton1Pressed и по шаблону Observer сообщать о событиях Presenter -у. A Presenter наконец-то полноправно организует взаимодействие Model и View так, что Model ничего не знает о View.
Посмотрите паттерн Model View Presenter, все должно стать на свои места.
паттерн MVC наверное самый замученный паттерн. Собственно он перестал быть паттерном как таковым, сейчас можно говорить о семействе паттернов MVC. Можно ввести в codeproject.com запрос MVC и увидеть реализации с абсолютно непохожими друг на друга связями между M-V-C (собственно и сами M,V,C многие трактуют по-разному).
Это произошло из-за того, что паттерн в первоначальном виде (SmallTalk) для большинства задач просто неприменим. Паттерн жив, видимо, потому, что заложенная в нем идея вообще-то работает и способна приносить бизнес-эффект.
В оригинальном MVC: контроллер - это просто преобразователь движений мыши, прерываний от клавиатуры и в нечто осмысленное, вроде "нажата кнопка А". Ну просто не было во времена SmallTalk ни WinForms, ни MFC, ни Qt, ни даже TurboVision. Эти фреймворки это "C" и "часть V" из комлекта MVC. Эсли вы используете эти фреймворки, то вы реализуете "оставшуюся часть V" и "M". Попытка натянуть их снова на паттерн MVC порождает разночтения.
Единственное применение чистого MVC, которое я вижу сейчас - это консольное приложение: Model - бизнес-логика, Controller (модуль управляющий InputStream), View (модуль, управляющий OutputStream).
Когда сегодня говорят MVC (Ruby on Rails, MVC.Net, Castle.Net) на самом деле имеют ввиду Model View Presenter. Где View, наконец-то получил право иметь методы вида OnButton1Pressed и по шаблону Observer сообщать о событиях Presenter -у. A Presenter наконец-то полноправно организует взаимодействие Model и View так, что Model ничего не знает о View.
Посмотрите паттерн Model View Presenter, все должно стать на свои места.
9
Варианты Использования (Use Case) / Re: Пользовательские Сценарии или как уйти от ВИ и перейти к иерархии ПТ
« : 18 Октября 2009, 18:32:18 »
Я задавал вопрос потому, что так и не понял убедил ли Эдуард в итоге Александра, что "Пользовательские Сценарии" являются избыточным понятем. В качестве примера я предлагал рассмотреть Word, для того, чтобы самому сделать вывод, нужны ли мне "Пользовательские Сценарии"
Юрий, спасибо за предложенный вариант со слотами ВИ, к сожалению я сейчас ничего не могу сказать по этому поводу, мне нужно разобраться что такое "Слоты ВИ". Если это помимо всего прочего, возможность создавать иерархию сценариев в рамках одного ВИ, то, похоже, действительно, без "Пользовательский Сценариев" вполне можно обойтись.
По поводу того, зачем пытаться искусственно натягивать требования на форму ВИ - тут я согласен с упоминавшимся мнением, что ВИ - это еще и способ мышления. Собственно, ВИ предрасполагает все время отталкиваться от целей пользователя, что позволяет избегать некоторых проблем, например, YAGNI ("Не факт, что это вам понадобится").
Насчет Word, да, пожалуй, я переборщил. Для того, чтобы понять чем можно заменить "Пользовательские Сценарии" достаточно было бы WordPad.
В итоге, являются ли слоты ВИ средством, заменяющим "Пользовательские Сценарии"?
Юрий, спасибо за предложенный вариант со слотами ВИ, к сожалению я сейчас ничего не могу сказать по этому поводу, мне нужно разобраться что такое "Слоты ВИ". Если это помимо всего прочего, возможность создавать иерархию сценариев в рамках одного ВИ, то, похоже, действительно, без "Пользовательский Сценариев" вполне можно обойтись.
По поводу того, зачем пытаться искусственно натягивать требования на форму ВИ - тут я согласен с упоминавшимся мнением, что ВИ - это еще и способ мышления. Собственно, ВИ предрасполагает все время отталкиваться от целей пользователя, что позволяет избегать некоторых проблем, например, YAGNI ("Не факт, что это вам понадобится").
Насчет Word, да, пожалуй, я переборщил. Для того, чтобы понять чем можно заменить "Пользовательские Сценарии" достаточно было бы WordPad.
В итоге, являются ли слоты ВИ средством, заменяющим "Пользовательские Сценарии"?
10
Варианты Использования (Use Case) / Re: Пользовательские Сценарии или как уйти от ВИ и перейти к иерархии ПТ
« : 18 Октября 2009, 00:03:55 »
Интересная ситуация. Я подумал, что если передо мной поставить задачу описать пользовательские требования для текстового процессора типа word, я знаю как это сделать используя подход Александра или используя форму ФТ и совершенно теряюсь как это сделать с помощью ВИ (CRUD ВИ).
Эд, не могли бы вы в качестве примера написать текст ВИ для текстового редактора типа word. (буквально 10 строчек, так чтобы было понятно, как они в принципе будут выглядеть)
Эд, не могли бы вы в качестве примера написать текст ВИ для текстового редактора типа word. (буквально 10 строчек, так чтобы было понятно, как они в принципе будут выглядеть)
11
Варианты Использования (Use Case) / Re: Ссылка на алгоритмы при написании вариантов использования
« : 16 Октября 2009, 14:07:41 »накладная - объект предметной области, а не артефакт проектирования.Под артефактами проектирования я понимал алгоритмы, и отчасти пользовательский интефейс. Накладную я не обижал
Формулировка Вами связи, через "некую сущность" не вполне понятна. Нельзя просто написать "общую сумму по накладным"? только стоило бы конкретизировать про какие конктретно накладные в этом случае идет речь.это понятно.
12
Варианты Использования (Use Case) / Re: Ссылка на алгоритмы при написании вариантов использования
« : 16 Октября 2009, 14:02:44 »Для этого используется трассировка проектных артефактов к ВИ. Их можно демонстрировать на диаграмме или указывать в контексте артефактов ссылки на ВИ ими реализуемыеСпасибо, Эд. Понятно, по крайней мере такое понятие существует.
13
Варианты Использования (Use Case) / Re: Ссылка на алгоритмы при написании вариантов использования
« : 16 Октября 2009, 13:30:24 »
Эд, вы имеете ввиду разделение БВИ/СВИ ?
БВИ я делал только в курсовике в институте, у меня не было позывов создавать ссылки на алгоритмы.
БВИ я делал только в курсовике в институте, у меня не было позывов создавать ссылки на алгоритмы.
14
Варианты Использования (Use Case) / Re: Ссылка на алгоритмы при написании вариантов использования
« : 16 Октября 2009, 13:25:07 »
Да, у нас тоже как-то получается ВИ раньше артефактов проектирования (собственно я и помещаю ВИ в раздел анализ требований, а не в раздел проектирование/реализация), но мы же все из себя такие итеративные
Считается ли связью ВИ2 - ФТ1 - ВИ1, если
ВИ1:
i. Пользователь вводит номер накладной
ВИ2:
j. Система отображает "некая сущность" (см ФТ1)
ФТ1:
Система должна вычислять общую сумму по накладным
Стоит ли вообще стремиться указывать такие связи?
Считается ли связью ВИ2 - ФТ1 - ВИ1, если
ВИ1:
i. Пользователь вводит номер накладной
ВИ2:
j. Система отображает "некая сущность" (см ФТ1)
ФТ1:
Система должна вычислять общую сумму по накладным
Стоит ли вообще стремиться указывать такие связи?
15
Варианты Использования (Use Case) / Re: Ссылка на алгоритмы при написании вариантов использования
« : 16 Октября 2009, 12:30:11 »
Даже не встоль экзотических случаях, как военные системы, когда заказчик приносит в клюве алгоритм подписанный главным чекистом страны, не лишним будет указать, что под "остатком товара" на складе я понимаю не некое число, которое вычисляется путем умножения температуры воздуха на гравитационную константу.