1

Для всех / Re: Распродаю библиотеку

« : 10 Июня 2015, 22:39:29 »

Добрый день.
Я бы приобрел вот это:

Проектирование реляционных баз данных. Джен Л. Харрингтон
Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения. Марри Кантор.
Разработка Пользовательского Интерфейса. Тео Мандел
Практическое руководство по проектированию и разработке пользовательского интерфейса, Роберт Дж. Торрес

Где и как можно забрать книги? Готов подъехать в сб. или вс. по Москве, если это возможно.

2

Для всех / Re: Пишем ТЗ по ГОСТ 34

« : 09 Апреля 2015, 02:12:03 »

Спасибо всем, что помогаете разобраться в таком нелёгком деле, как работа по ГОСТ34

Добавлю от себя список некоторых вопросов, с которыми сталкивался в процессе:
- Возможно ли в рамках разработки документации часть написать по ГОСТ34, а часть допустим по 19? Т.е. ТЗ пишем по 34, а руководство оператора по 19?
- Возможно ли оставить пакет документов без единого ТЗ, сразу оформить несколько ЧТЗ на каждую из подсистем?
- Как правильно отформатировать документ(ы)? Шрифт, поля, интервалы и тд.
- Какие из документов, описанных в 34201 являются СТРОГО обязательными?
- Насколько подробно необходимо описывать требования именно в ТЗ? И как понять, что необходимый уровень точности уже достигнут. (Здесь будем исходить из того, что подробные ФТ пишутся все-таки на стадии ТП, а в ТЗ пишутся требования верхнего уровня).

Могу добавить еще вопросы относительно ПМИ, если это пойдет в эту же тему.

3

О Сайте и Форуме / Re: А у нас новый сайт!

« : 07 Марта 2015, 03:56:22 »

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

В разделе "Примеры" форума в темах (просмотрел верхние темы за 2014 год) куда-то пропали картинки. Интересные были посты, а теперь остался голый текст Было бы здорово восстановить картинки...

4

Для всех / Re: Пишем ТЗ по ГОСТ 34

« : 21 Февраля 2015, 02:51:56 »

Приветствую всех еще раз!
Чтобы не плодить схожие темы на форуме, продолжу эту тему (тем более что вопрос все про тот же ГОСТ 34).

Собственно мой вопрос: как грамотно и корректно описать методику проверки требований к видам обеспечения - математическому, информационному и т.д. Нужно ли вообще описывать это в ПМИ (ведь требования в ТЗ к ним указаны, значит как-то надо понять, что требования выполнены).

К примеру - вот такое требование:
Система должна позволять расширять возможности информационного обмена путем  интеграции новых внешних систем.
Как его проверять? Проделать интеграцию с новой внешней системой? Но на такой тест может понадобиться отдельный релиз системы и отдельное ТЗ.

Или вот такое требование:
Структура данных и способ организации должны позволять наращивать объем накопленных данных в системе, а также вносить изменения в систему вслучае изменения законодательства...
Как проверить - начать вносить изменения прямо в момент сдачи системы на глазах у заказчика? Но это тоже может оказаться трудоемким процессом.

В поиске полезных примеров документации  случайно наткнулся на вот такой ресурс - Информационное общество Минэкономразвития. http://aisup.economy.gov.ru/pubportal/ Оказывается, там на суд общественности выкладывают документацию к различным продуктам, сделанным по заказу министерства.

Вот несколько занимательных примеров, из ПМИ в одном из документов оттуда:

Действия пользователя (Д): Нажать кнопку «Регистрация».
Ожидаемый результат (Р): Пользователь пытается зарегистрироваться.

(Д) Нажать «Войти».
(Р) Пользователю отображается следующие элементы экрана: поля ввода учетной записи (адрес электронной почты e-mail и пароль); кнопка «Вход»; форма для восстановления пароля.

А вот так предлагают тестировать быстродействие:
(Д) Последовательно зайти на все информационные страницы
(Р) Загрузка любой страницы, занимает не более 5 секунд.

Может ли кто-нибудь поделиться примером про тестирование требований к видам обеспечения, дать ссылку на книгу или еще какой-нибудь источник? Облазил весь интерент, грамотных примеров так и не нашел

5

Sparx / Re: Как изменить внешний вид класса со стереотипом Boundary/Entity?

« : 22 Января 2015, 12:22:43 »

Огромное спасибо! Сделал через "Use stereotype icons".

6

Sparx / Как изменить внешний вид класса со стереотипом Boundary/Entity?

« : 22 Января 2015, 00:37:54 »

Приветствую всех. Подскажите, пожалуйста, кто знает.

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

Пользуюсь версией EA 9.

7

Для всех / Re: Пишем ТЗ по ГОСТ 34

« : 06 Декабря 2014, 02:40:00 »

Спасибо всем за ответы.
Возник новый вопрос - кто может поделиться информацией как правильно отформатировать документ ТЗ по ГОСТ 34?
Название шрифта, размер, поля, интервал и т.д.
В ГОСТ 2 такую информацию не нашел

8

Для всех / Re: Пишем ТЗ по ГОСТ 34

« : 18 Октября 2014, 22:58:16 »

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

То есть раздел "Требования к функциям (задачам), выполняемым системой" - должен представлять собой полное описание всех функциональных требований в развернутой форме со всеми входными и выходными параметрами?

А как же тогда быть с ТП? там вроде был такой документ - "Описание автоматизируемых функций".

9

Для всех / Пишем ТЗ по ГОСТ 34

« : 18 Октября 2014, 16:38:16 »

Приветствую всех.
Возникла необходимость написать ТЗ в соответствии с ГОСТ 34. Нужны ваши советы и рекомендации.
При написании возник следующий вопрос.

В ГОСТе 34.602 есть такой пункт: "Требования к функциям (задачам), выполняемым системой", где нужно указать
по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации.

В интернете нашел несколько рабочих примеров (довольно известных it компаний), в которых пишут эти требования вот
таким образом (к одной из подсистем):
- Внесение кредитной оценки УП
- Создание дисциплин
- Фиксация окончания формирования УП

то есть никакой конкретики - кем внесение? зачем? какие предусоловия? и тд.

Не очень понимаю, в чем смысл такого описания этого пункта в ТЗ? Если мы, допустим, имеем список подробно описанных ФТ, где каждое требование пронумеровано, то там понятно как потом проверить, как сослаться на это требование. А что делать с таким описанием и как оно вообще может нам помочь?

По сути краткое описание подсистем мы уже сделали в том же ТЗ немного выше, пункт 4.1.1 "Требования к структуре и функционированию системы".

До этого момента предполагал, что в пункте "Требования к функциям (задачам), выполняемым системой" нужно приводить четкие и конкретно сформулированные ФТ по каждой из подсистем. В таком случае только один этот пункт ТЗ может потянуть на 100 с лишним страниц (это нормально?).

Разъясните, пожалуйста, ситуацию с этим пунктом ТЗ, кто знает.
Заранее спасибо.