1

Бизнес-анализ и Целеполагание / Re: Цель разработки\приобритения ПО и АС. Какова она как правило ?

« : 16 Марта 2012, 17:31:30 »

Иногда еще встречается вариант: "Не зависить ни от кого в материальном и техническом плане при поддержке ПО и АС и дальнейшей разработке". Касается каких-то внутренних разработок больших неповоротливых компаний.

2

Для всех / Re: современные проблемы системного анализ

« : 25 Октября 2011, 12:36:46 »

Мне кажется все озвученное вытекает из одной большой проблемы: заказчики пока не понимают необходимость тщательной работы над требованиями. В моей (небольшой пока) практике встречалось  два ключевых типа Заказчика: те, которые вообще не понимают зачем нужен этап сбора и формализации требований и считают его просто вымогательством денег. И те, кто смирился с тем, что исполнители хотят видеть какие-то требования, по которым будет вестись разработка. В этом случае ТЗ выливается в простую формальность из разряда: "Напишите что-нибудь коротенькое за 3-4 дня". Гораздо проще "начать хреначить прям сразу", чтобы видеть какой-то результат. И не важно, что потом будет переписываться весь проект. 
Да и в общем, культуры разработки программного обеспечения у нас в стране, наверное, пока нет.

3

Для всех / Re: Кто такие it-гуру и признанные эксперты?

« : 24 Октября 2011, 11:07:49 »

Абсолютно согласна с выше озвученными тезисами, но позволю себе добавить еще вот что:

Например, когда на сайте компании размещено что-нибудь вроде "является системным интегратором №1", то рядом всегда стоит маленькая звездочка, в описании которой ниже будут указаны результаты опроса или исследования, в котором и было это установлено.

Сейчас какого интегратора не возьми - каждый будет номер один. По опросу того журнала, который он патронирует или с которым просто поддерживает дружеские отношения. Не все, но по большей части. Так что в данном случае, мне кажется, наглость - второе счастье  

4

Для всех / Re: а получили как всегда

« : 24 Октября 2011, 10:59:01 »

На эту тему слышал следующую историю:
Американские спецслужбы выкрали у нас чертежи сверхсекретной подводной лодки. Построили. Получился паровоз Черепанова.
По дипломатическим каналам отправили протест.
Наши долго извинялись: "Все правда! Только вы выкрали чертежи, но забыли взять лист изменений!"

а есть еще один вариант концовки: "Все так, только там в конце сноска была: "После сборки изделие доработать напильником".

А картинка замечательная, одна из тех что просится над рабочим местом

5

Системный Анализ и Требования / Re: Примеры в ТЗ

« : 29 Июня 2011, 15:18:50 »

Архитектурнозначимые - те, которые оказывают значительно влияние на архитектуру. Это как раз, те требования, которые следует выявить как можно раньше. А вот как они на самом деле выглядят и чем отличаются от неАЗ, не вем

Мне кажется это очень сложно. Подобные вещи можно выявить на этапе ТП. А ведь заказчик все время хочет подписать все поскорее и начать работу. Кроме того, эта бумажка - гарант его правильного вложения денег, потому, мне кажется, ему гораздо понятнее будут именно функциональные требования, требования назначения.

А вообще все зависит от заказчика и от исполнителя. Я сотрудничала с людьми, которые согласовывали только 2 документа с заказчиком: описание бизнес-требований (буквально 1-2 листа кратко) и требования формата use case + мокапы. Процесс согласования был длительный и болезненный, но позволял на выходе получить готовое ТЗ на разработку, заказчик же получал представление о том, как будет выглядеть его система, а все возможные "А давайте сюда добавим кнопочку" ликвидировались на этом этапе.

6

Системный Анализ и Требования / Re: Макеты интерфейсов + ГОСТ

« : 29 Июня 2011, 15:03:01 »

Качество чего хотите улучшить? За счет шаблона из ГОСТ?

Я просто пытаюсь сделать свою работу хорошо в тех условиях, в которые меня поставили. Если у меня нет выбора и надо использовать только ГОСТ, это, как мне кажется, не повод делать что-то на недостаточно высоком уровне качества.

Если уж заговорили о ГОСТ, разве есть такой документ как Проект?

Я в данном случае привела полностью пункт ТТЗ. Не хватает только примечания о том, что документ должен быть согласован в течение такого-то времени.
Интересно именно структурирование документа. Мне раньше приходилось писать похожие вещи. В результате получался объемный документ вида: use case + мокапы к нему. Но в данном случае (госзаказчик) я не думаю, что кто-то станет читать подобные объемные вещи.

Что касается ГОСТ 2.105-95. Как бы с ГОСТ знакома и проблем с его использованием не было. Собственно он и был использован. В итоге документ получился в виде описания 3-4 основных экранных форм. Смутило меня то, что данный документ был в ТТЗ в одной куче с типичными набором документации на ПО по ГОСТ 19.  Он и еще один "Проект формата автоматизированного отчета".

7

Системный Анализ и Требования / Re: Макеты интерфейсов + ГОСТ

« : 28 Июня 2011, 16:39:06 »

Ну я как бы и не пытаюсь спорить с этим тезисом! И свою проблему на текущий момент решила  "заглушкой". Просто хочется улучшить качество, послушав мысли умных людей

8

Системный Анализ и Требования / Макеты интерфейсов + ГОСТ

« : 28 Июня 2011, 16:15:06 »

Коллеги, здравствуйте.

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