Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Vell

Страницы: 1 2 »
1
Почему? Ребенок видит, что другие ходят на ногах и сам начинает.
Если бы кругом все ходили на руках, то и он бы на руках стал ходить.

Может я немного неправильно выразился, но я хотел сказать что не хочу набивать шишки которые можно обойти. Вспоминается высказываение: Только дураки учаться на своих ошибках, умные люди учаться на ошибках других людей. Я не хочу сказать что все кто совершают ошибки глупые люди, но вот те кто не учатся на ошибках других и не учитывают опыт других, вот те явно не являются умными.

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


Я хотел сказать немного другое. На момент разработки иметтся представление о том что делается как и зачем. Но вот дальше есть как минимум два возможных варианта:
1. програмист со временем сам забывает что он там делал, и что бы вникнуть ему надо время. Вникать приходится по двум причниам: доработка новым функционалом или исправление ошибки (которые часто должны быть решены еще вчера)
2. програмисты имеют свойство уходить... соответственно если другой разработчик садится на проект по одной из двух вышеописанных причин, он и представления о том что это за программа и как в ней что работает, и как там что править...
3. + еще возможна ситуация когда надо к проекту подключить человека, и дабы не дергать разработчика с вопросами а что тут и как, можно прочесть документ и спросить уж реально непонятное...

... всё равно нельзя сразу перепрыгнуть к разработке полноценной документации отличного качества. Постепенно, когда разработчики начнут привыкать, плюс у Вас накопится какая-то информация об отработке проблем, Вам станет понятно, чего не хватает, и тогда можно будет скорректировать подход.
...

хочется просто пропустить пару детских шагов, опыт других поколений ведь не зря скапливается. :)

3
Работа / Re: Сколько Вы получаете?
« : 04 Ноября 2009, 00:30:32 »
ну я тоже по роду своей деятельности не чистый аналитик. компания небольшая поэтому приходится сочетать несколько направлений работ...

4
Задача стоит в том чтобы новый человек прочитал некий документ в которм бы ему стала понятна работа как всей системы в целом, так и ее компонентов в частности если это необходимо (например при исправлении ошибки или дописании новых функций в каком-то конкретном модуле). Это нужно что бы новый человек не дергал предыдущего разработчика с вопросами а как это работает (часто это просто невозможно - разработчики имеют свойство уходить).

5
Работа / Re: Сколько Вы получаете?
« : 03 Ноября 2009, 22:09:48 »
14 (всего 1 год стажа). работаю в таганроге.

Просто немного непонятно как считать среднюю если зарплата в Москве или Питере это провинциальная ЗП * 2 или 3

6
Работа / Re: Знание английского языка
« : 03 Ноября 2009, 22:05:00 »
Знание английского, даже для чтения технической литературы должно быть на уровне, а то можно так исказить смысл исходного текста, что те тексты которые уже есть будут просто идеальными... можно сказать, что лучше не делать чего-то, чем делать это плохо...

div, ситуация аналогичная. Например, есть лекции. Конспект сделан в виде некоторых тезисов с красивыми картинками и выжимками самой сути. Прошу почитать - проверю на следующем занятии, просто задаю вопросы и прошу на них ответить. Ноль. Говорю в следующий раз будет тоже самое. Реагируют пару человек.

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

7
К сожалению уровень разработчиков в документировании систем заканчивается расставлением комментариев в самых сложных участках кода.
У меня тоже не очень много опыта в плане организации работ по документированию систем. Прочитал книгу по урпавлению требованиями из нее почерпнул первые идеи о структуре и подходах.

Заставить написать такой документ возможно, но нельзя просто сказать тебе надо писать документацию, но не сказав как она должна выглядеть, тогда этот процесс будет очень формален: из разряда ты написал документацию... да вон там валяется... Сейчас у разработчиков есть понимание необходимости написания такой документации... есть проблема в том как правильно организовать этот процесс.

Все конечно понимают что сроки реализации, при написании такой документации, увеличатся, но все с этим согласны, так как надеемся что это принесет результат в будующем.

Ontology Nazi спасибо за пример документа, он мне помог понять что должно быть в нем и примерно в каком порядке. мы его скорее всего будем использовать как отправную точку.

Водолей идея с мозговм штурмом тоже имеет свой смысл. Из раззных методик и документов можно будет выбрать только то что нам действительно необходимо (то в чем мы будем видеть смысл при дальнейшей работе с документом)

8
Доброго времени суток.

Очень интересует вопрос организации процесса документирования разработки нового программного обеспечения (написания технической документации). Работаю в компании которая занимается написанием ПО для медицины (являюсь руководителем отдела), хотелось бы поднять уровень документирования систем у себя на более высокий уровень. Сейчас документирование выражено написанием комментариев в исходном коде программы и в БД (пакеты, функции). Нет единого документа который бы описывал все функции системы в полном объеме и давал понимание как взаимодествуют эти функции.

Уже есть много разработок которые не документированы вообще или документирова очень плохо, и у разработчиков уходить много времени на изучение исходного кода, что бы исправить ошибку в логике программы или дописать новые функции, спасает то что есть еще люди которые тем или иным образом учавствовали в разработке этого ПО. Сейчас должен начаться новый проект, соответственно хочется начать сразу и правильно что бы потом как можно меньше пришлось переделывать...

Хотелось бы услышать рекомендации или личный опыт организации такого процесса. Если есть возможность (было бы просто замечательно)  хочется почитать какой-нибудь составленный документ описывающий систему с точки зрения разработчика (написаный разработчиком для разработчиков).

Изучая данную проблему я нашел описание структуры Modern SRS Package у Леффингуэлла. Документ мне в целом понравился... но мне кажется что он очень сложный и запутанный (и по этому документу есть ряд вопросов по его организации и заполнению). Использовал ли кто эту структуру для создания технической документации?

PS
Если я правильно понимаю то данный документ должен писаться всеми участниками проекта:
руководитель проекта - описывает бизнес логику, создает модели, фиксирует пользовательские и бизнес требования;
разработчики - описываю функции реализующие пользователькие требования, интерфейсы функций и взаимодествия между функциями


9
спасибо за коментарии. учтем при переработке материала :)

10
Занимаюсь написанием дипломной работы по теме разработка ИС.
Хочу для себя получить опыт разработки подобных систем, их документирования, управления требованиями...

Написал документ об обзоре и границах для данного проекта, просьба прокоментировать что сделано не правильно, что можно было бы изменить...


Так же набросал UseCase для данной ИС, если будет нужен могу выложить

11
ПО Аналитика / Re: FAQ - все продукты Telelogic
« : 19 Февраля 2008, 23:44:14 »
ну в общем то да тут все сходится именно к удобству, эргономике работы с данным средством.

В кинжке Леоненкова все стрелки идут от краев, а не от центра. И объекты в этой же книжке создаются там где потребуется, а не сверху. Просто если создается много объектов внутри то они просто физически не поместятся сверху.

На счет других средств: я пользовался только этим и все. :) У меня пока не очень большой опыт работы с UML.

12
Обучение / Re: Моедль образования "AS IS"
« : 19 Февраля 2008, 23:37:30 »
Да студент нынче пошел "неважный", мелкий какой-то.

Да я полностью согласен что некоторые студенты ленятся. Есть такая категория людей которым просто нужен диплом о высшем образовании, они знают что место им уже приготовлено и они не заморачиваются над изучением дисциплин, сдал и ему хватает...

Есть же студенты которые твердят мне это не надо (Раньше сам таким грешил).Хотя потом понимаешь что предмет то нужен был. :)

Про развитие мативации у таких студентов говорить очень сложно.

Но если студент проявляет какойто интерес к предмету, тогда с ним надо вступать в контакт. Кстати воопрос даволно таки не простой. Я сам дошел до понимания того что мне надо изучать как можно больше, хотя на начальных курсах был не очень прилежным учеником. Но все таки старался понимать предмет а не заучивать его (это касается профильных дисциплин).

Как вариант сейчас пришло на ум, что бы мативировать студента на ранних курсах нужен студент с этойже специальности но курс так 4 или 5 и + выпускник этой специальности,  которые проведут какое-то мероприятие, показывающее нужность данной дисциплины. Но тут важна грань такого мероприятия, если оно воспримется слушателями как пропоганда, то эффект будет только отрицательный, а если все провести грамотно, то можно повысить мативацию студента. Мне кажется что слова "старшего товарища" воспринимаются куда лучше чем слова преподавателя. Сколько сам в личных беседах со знакомыми принимал их советы, хотя услышав такой совет от преподавателя мог восприянть его в штыки...

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

Вот еще одно что не очень люблю. Что нам рассказывают сухую теорию, что само по себе и не плохо... Но вот только нет никакого приложения этой теории к реальности, не к практике а вот именно к реальности. Это мягко говоря не радует... :(

Вспоминается высказывание одного студента на лекции: Если бы он знал как стать богатым он бы там щас не стоял. (Не в обиду будет сказано преподавателям). Я понимаю что есть так называемые "идейные", на них сейчас и держится вся свера образования, за что им огромное спасибо.

Тема очень даже интересная: "Как сделать наше образование лучше". Главное что бы мы потом начали предлагать конкретные советы или пути решения данной проблемы.

13
Обучение / Моедль образования "AS IS"
« : 19 Февраля 2008, 11:15:22 »
Причем вообще форма преподавания в наших вузах меня вообще бесит - но это совсем другая тема.

Я сам преподаватель. Меня тоже не устраивает форма преподавания. ...[/quote]

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

Для начала мне кажется не мешало бы построить это в моедли "как есть". А потом в "Как должно быть".

Цитировать
А что конкретно Вас бесит? Можете ли Вы перечислить пункты? Желательно в порядке убывания значимости (или степени раздражения). Я довольно часто пытался выяснять у студентов, что же им не нравится в системе обучения, к сожалению ничего серьезного мне не сказали (что впрочем понятно)

Первое что мне мягко говоря не нравится это форма проведения лекци. Мы приходим на пару, пишем под диктовку полтора часа, то что можно прочитать в электронном или в бумажном виде. (Благо курсы лекций есть в библиотеке). Мне было бы больше приятней когда мы прочиатв предварительно материал той же лекции, приходя на пару услышали бы материал, который в силу возраста, малого кругозора (или других объективных причин), мы не можем понять, уловить или вообще знать. Ведь согласитесь тонкостей в любой профильной дисциплине достаточно...

Второе это "тупость" во время проведения практических и лабораторных занятий. Пример вчера был на практике по Проектированию АСОИУ. Преподаватель сказала выпишите все UML диаграммы которые вы прошли на лекциях. Что меня очень сильно покаробило. Как сказал одногрупник, занимать контрольным списыванием на 4 курсе это бред!!! и я сним польностью согласен. проведение практик опять должно показывать практический опыт работ по данной дисциплине, их тонкости, нюансы. Должны рассказывать про стандартные ошибки котрые возникают у других людей. а то что они читают с листов я и сам дома могу прочитать.

Это основное что меня не устраивает в ныне существующей форме преподавания в ВУЗе

Еще конечно хотелось бы увидеть полную системность в подходе к обучению студентов. Развитие мативации, преподавание полного комплекса дисциплин для нормальной работы в дальнейшем.

Системность в принципе есть, но какаято она не полная чтоли... Некоторые дисциплины вообще вырваны из контекста обучения. Некоторые связаны хорошо, ну глубины знаний в них не хватает (даже могут не давать так называемых ориентиров). Конечно многие преподаватели говорят что сейчас образование это в большей части самообразование студента. Я сдесь спроить не стану, но все равно преподаватель задает первый кругозор и глубину проработки по предмету.

про мативацию и говорить нечего! Профильные преподаваетли иногда слишком халатно относятся к своим предметам, а вот всякие гуманитарные строят из своих предметов просто идолы для поклонения, хотя там хватитт токо обзора (например у нас в этом семестре такой предмет - политология).

Ну а то что не хватает некоторых дисциплин - этот факт тоже на лицо, в соседней теме очень много говорили про управления требованиями, у нас эту тему даже не затрагивали ни в курсе проектирования АСОИУ ни в каких других... что конечно очень жаль.

Это я все говорю про свой вуз. Есть конечно вузы где данных проблем по большому счету нету, но все равно возможны другие... Как говориться идеал не достижим, но к нему надо стремиться. Нам рассказывали о проведении лабораторных практических работ по средствам WEB (блогов форумов), данное средство имеет как свои плюсы так и минусы.

PS это все что у меня наболело за 4 года обучения. Возможно в порыве я упустил какието аспекты, детали о которых хотел рассказать, или которые мне не нравятся в нашей структуре преподавания. Но как база от это высказывание может служить отправной точкой для дальнейшего обсуждения.

14
Работа / Re: Литература по специальности
« : 19 Февраля 2008, 01:23:44 »
кому будет интересно, если не ошибаюсь таже книга на русском языке.

Название: Принципы работы с требованиями к программному обеспечению. Унифицированный подход
Авторы: Дин Леффингуэлл, Дон Уидриг
Ориг. название: Managing Software Requirements: A Unified Approach First Edition. Dean Leffingwell, Don Widrig
издательство: Вильямс
дата выхода: май 2002
ISBN 5-8459-0275-4
страниц: 448
Размер: DJVU
Формат: 4.7 Mb

Аннотация
Цитировать
Книга посвящена вопросам формирования требований и работе с ними при разработке сложных систем программного обеспечения. Недостаточное внимание к этому аспекту разработки может привести к превышению расходов, затягиванию сроков выполнения или даже полной неудаче проекта. Авторы предлагают хорошо зарекомендовавшие себя методы выявления, документирования, реализации и тестирования требований, используя для их описания как прецеденты, так и более традиционные методы. Особое внимание уделяется пониманию потребностей пользователей, определению масштаба проекта и обработке изменений. Все этапы иллюстрируются обсуждением полномасштабного рабочего примера. Книга предназначена для всех участников проекта - как членов команды разработчиков, так и пользователей или заказчиков. Ее задача - помочь создать в рамках отведенного времени и бюджета высококачественную систему программного обеспечения, удовлетворяющую реальные потребности клиентов.

ссылка:
_http://rapidshare.com/files/15201109/ManagingSoftwareRequirements.rar

PS пожелание к гуру в обасти анализа. вы очень много говорить что надо читать книжки (с этим я полностью согалсен) но выбор литературы очень широк. И было бы очень полезно если бы специалистами в этой области был бы составлен список литературы которую обязан прочитать каждый уважающий себя начинающий или сложившийся специалист. причем хотелось бы видеть список литературы в порядке убывания значимости. Потому что мне кажется что от последовательности прочтения подобной литературы зависит очень многое.

Потом конечно бы было просто замечательно если появились бы ссылки на статьи каких-то известных людей в этой области, потому что книжка книжкой а статьи умных людей (после изученой литературы) дают очень большой скачек в развитии как кругозора так и профессиональных показателей работника.

PSS
сам являюсь студентом 4 курса ТТИ ЮФУ по специальности Автоматические системы обработки информации и управления (кафеда: Системный Анализ и Телекомкникации). Сейчас стал отчетливо понимать что программа обучения дает лишь поверхностные знания в области системного анализа. (Приче вообще форма преподавания в наших вузах меня вообще бесит - но это совсем другая тема).  Поэтому начиаю освоение дополнительных источников информации. Прочитал курс на интуите про управления требованиями. Познавательно. Но еще больше понял что заню очень мало и что этих знаний не достаточно дл нормальной работы.

15
ПО Аналитика / Re: FAQ - все продукты Telelogic
« : 11 Февраля 2008, 21:30:49 »
пора на Rational Rose переходить :)

Страницы: 1 2 »