Компьютерный форум
Правила
Вернуться   Компьютерный форум > Форум программистов > Теория программирования > Общие вопросы создания ПО
Перезагрузить страницу Где можно узнать побольше о создании программного обеспечения
Ответ
 
Опции темы Опции просмотра
  (#1 (permalink)) Старый
just_vladimir just_vladimir вне форума
Member
 
Сообщений: 420
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 08.11.2006
По умолчанию Где можно узнать побольше о создании программного обеспечения - 30.03.2008, 23:50

Скажите, что можно почитать полезного по вопросам создания ПО, какие подходы, методологии, инструменты используются, как они все между собой связаны. Статьи, книги и тому подобное. Кто в своей личной практике, что использует? Тоесть про RUP, XP, Agile подходы и что там еще существует, какие при этом используются CASE средства? Что есть что и когда стоит, а когда не стоит использовать?

Заранее спасибо всем отписавшимся.

ЗЫ: тоесть хочу получить более структурированное представление обо всем этом и понять, какие ниши что занимает.
Ответить с цитированием
  (#2 (permalink)) Старый
Влад Влад вне форума
Специалист
 
Сообщений: 3,884
Сказал(а) спасибо: 1
Поблагодарили 25 раз(а) в 25 сообщениях
Регистрация: 27.06.2002
Адрес: Санкт-Петербург
По умолчанию 31.03.2008, 13:58

Хм. А зачем?


The difference between theory and practice is that in theory, there is no difference between theory and practice, but in practice, there is.
Ответить с цитированием
  (#3 (permalink)) Старый
just_vladimir just_vladimir вне форума
Member
 
Сообщений: 420
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 08.11.2006
По умолчанию 31.03.2008, 14:50

Ну блин, даже не знаю что ответить то Может лучше чем интересным поделитесь?
Ответить с цитированием
  (#4 (permalink)) Старый
Влад Влад вне форума
Специалист
 
Сообщений: 3,884
Сказал(а) спасибо: 1
Поблагодарили 25 раз(а) в 25 сообщениях
Регистрация: 27.06.2002
Адрес: Санкт-Петербург
По умолчанию 31.03.2008, 17:08

Каков вопрос - таков и ответ. Спроси что-нибудь конкретное, а?
Видишь ли, штука в том, что в тот момент, когда ты придешь на работу в некую фирму, не ты будешь решать, какой методологии разработки ПО (waterfall, XP, RUP...) следовать, а - тебе прикажут следовать принятой в фирме схеме и использовать принятые инструменты. Через энное количество лет, когда ты дорастешь до PM или даже SIO/SEO и сможешь сам принимать такие решения, все само собой придет в какую-то систему. Учти, что к этому моменту и инструментальные средства, скорее всего, изменятся, а возможно, и методологии....

А нужные тебе книги в электронном виде живут здесь: http://www.proklondike.com/index.php?mainpart=4&page=8

ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств.
ГОСТ Р ИСО/МЭК ТО 15271-2002 Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207. (Процессы жизненного цикла программных средств)
ГОСТ Р ИСО/МЭК ТО 16326-2002 Программная инжененрия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом


The difference between theory and practice is that in theory, there is no difference between theory and practice, but in practice, there is.
Ответить с цитированием
  (#5 (permalink)) Старый
Влад Влад вне форума
Специалист
 
Сообщений: 3,884
Сказал(а) спасибо: 1
Поблагодарили 25 раз(а) в 25 сообщениях
Регистрация: 27.06.2002
Адрес: Санкт-Петербург
По умолчанию 31.03.2008, 17:41

Да, и самое главное: управление проектом - это прежде всего управление людьми, а не waterfall, RUP, XP или чо-то еще.

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


The difference between theory and practice is that in theory, there is no difference between theory and practice, but in practice, there is.
Ответить с цитированием
Ads.
  (#6 (permalink)) Старый
just_vladimir just_vladimir вне форума
Member
 
Сообщений: 420
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 08.11.2006
По умолчанию 31.03.2008, 23:52

Спасибо за ссылки, почитаю. Все что Вы сказали, на счет того, что прийдешь и будешь работать так как скажут, я понимаю.
И у меня еще вопрос, может даже более конкретный, на сколько часто Вы в своей практике используете UML диаграммы(а также IDEF, некие произвольные картинки), все ли из них используете или только некоторые из них?
Ответить с цитированием
  (#7 (permalink)) Старый
Alexiski Alexiski вне форума
Любитель давать советы
 
Сообщений: 4,274
Сказал(а) спасибо: 27
Поблагодарили 54 раз(а) в 54 сообщениях
Регистрация: 16.10.2005
По умолчанию 01.04.2008, 10:32

В свете начавшихся дискуссий не могу не отметить книжку Берлинский Константин - Набор серебрянных пуль
Весьма интересные взгляды у автора.
Цитата:
Войны ИТ-методологов не затихают. Каждые несколько лет нам преподносится совершенно новая, быстрая, легкая, простая, эффективная методика (или новая версия "старой"). И уж она наконец-то решит главную проблему - построение качественного ПО в срок. Я думаю, что правда о методологиях заключается в том, что их не существует...
Привел бы еще несколько цитат, но книжка в PDF, копирование отключено, а конвертировать лень.

Цитата:
Мое личное мнение, то что от желания людей выполнить проект зависит сильно больше, чем от всех самых прогрессивных процессов и методологий, вместе взятых.
...
А планы и методологии - это хорошая штука только до тех пор, пока они являются помощью менеджеру и команде в их основной деятельности (создании продукта), а не их основной деятельностью (создание планов).
Сразу вспоминается старая шутка: "никак не пойму, за что мне платят деньги - за видимость работы, которую я создаю или за работу по созданию этой видимости"
А если серьезно, то технологии - это вопрос доверия менеджмента к разработчикам. Программистский коллектив - субстанция творческая, в чем-то даже богемная, а ну как они не над проектом задницы просиживают, а дурью маются. Вот и возникает желание поставить их в какие-то рамки.
Ответить с цитированием
  (#8 (permalink)) Старый
Alexiski Alexiski вне форума
Любитель давать советы
 
Сообщений: 4,274
Сказал(а) спасибо: 27
Поблагодарили 54 раз(а) в 54 сообщениях
Регистрация: 16.10.2005
По умолчанию 01.04.2008, 10:40

Цитата:
прийдешь и будешь работать так как скажут
...
на сколько часто Вы в своей практике используете UML диаграммы
Вот именно так - когда руководству захотелось новых методов - использовал.

Основные возникшие проблемы:
1) реальные диаграммы получаются весьма большими и быстро теряют наглядность
2) не получается как положено: сначала диаграммы, потом проект. По ходу разработки проект начинает отходить от диаграмм, потом сидишь и правишь диаграммы под то, что получилось.

В общем, у меня получился скорее инструмент для осмысливания уже сделанного, а не для разработки нового.
Ответить с цитированием
  (#9 (permalink)) Старый
Влад Влад вне форума
Специалист
 
Сообщений: 3,884
Сказал(а) спасибо: 1
Поблагодарили 25 раз(а) в 25 сообщениях
Регистрация: 27.06.2002
Адрес: Санкт-Петербург
По умолчанию 01.04.2008, 14:41

Цитата:
А если серьезно, то технологии - это вопрос доверия менеджмента к разработчикам. Программистский коллектив - субстанция творческая, в чем-то даже богемная, а ну как они не над проектом задницы просиживают, а дурью маются. Вот и возникает желание поставить их в какие-то рамки.
Я бы не согласился.
Если менеджеры нанимают таких разработчиков, которым они не доверяют, - гнать надо этих менеджеров. За непрофессионализм. Ибо нанимают они - непрофессиональных разработчиков (hint: профессионализм разработчика определяется не только знанием языковых фич и фреймворков, но и способностью делать то, что "надо", а не то, что "хочется".) Я что-то слабо верю в успех проекта, когда непрофессиональные менеджеры нанимают непрофессиональных же разработчиков и, не доверяя им и их опыту, пытаются наладить формальное управление.... Позволю себе процитировать Тома ДеМарко, Deadline:
Цитата:
Четыре основных правила менеджмента
1. Найти нужных людей.
2. Дать им ту работу, для которой они лучше всего подходят.
3. Не забывать о мотивации.
4. Помогать им сплотиться в одну команду и работать так дальше.
Все остальное — административная ерундистика.
Далее. Если менеджер не знает, чем занимается его подчиненный, - то ли он действительно занят проектом, то ли дурью мается, - это признак непрофессионализма этого менеджера. Нет у него четкого плана хода разработки, не отслеживаются промежуточные вехи. Отсюда, как правило, и растет желание "поставить эту богему в какие-то рамки". Технологии же - это не вопрос доверия менеджмента к разработчикам, а - всего лишь средство обеспечения устойчивости и безотказности разработки.


The difference between theory and practice is that in theory, there is no difference between theory and practice, but in practice, there is.
Ответить с цитированием
  (#10 (permalink)) Старый
Влад Влад вне форума
Специалист
 
Сообщений: 3,884
Сказал(а) спасибо: 1
Поблагодарили 25 раз(а) в 25 сообщениях
Регистрация: 27.06.2002
Адрес: Санкт-Петербург
По умолчанию 01.04.2008, 14:56

Цитата:
Основные возникшие проблемы:
1) реальные диаграммы получаются весьма большими и быстро теряют наглядность
2) не получается как положено: сначала диаграммы, потом проект. По ходу разработки проект начинает отходить от диаграмм, потом сидишь и правишь диаграммы под то, что получилось.
Именно так. А если нет времени на то, чтобы "сидеть и править диаграммы под то, что получилось", то очень быстро возникает ситуация, когда от диаграмм (неактуальных) становится больше вреда, чем пользы, и все на них быстренько забивают... После чего их со спокойной совестью можно отправить в Корзину.


The difference between theory and practice is that in theory, there is no difference between theory and practice, but in practice, there is.
Ответить с цитированием
  (#11 (permalink)) Старый
just_vladimir just_vladimir вне форума
Member
 
Сообщений: 420
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 08.11.2006
По умолчанию 04.04.2008, 23:12

Большое спасибо, ваши ответы действительно мне очень важны. В связи с чем я завел разговор об этом, нам в ВУЗе чуть ли не на каждом предмете рассказывают о всевозможных чудесных диаграммах, подходах и тому подобному, но какой то человеческой системы в этом не видно, вроде и то хорошо и это хорошо. А на работе столкнулся с тем, что почти нигде нету нормальной доки, не то чтобы там еще чего нить, так что во многом приходится по долгу разбираться. Вот и охото узнать, что, в каком случае и как следует применять исходя из реальности, так чтобы не попадать в крайности, чтоб методологии не становились самоцелью, но и не отказываться от них вообще, так как они явно создавались не просто так.
Ответить с цитированием
  (#12 (permalink)) Старый
Влад Влад вне форума
Специалист
 
Сообщений: 3,884
Сказал(а) спасибо: 1
Поблагодарили 25 раз(а) в 25 сообщениях
Регистрация: 27.06.2002
Адрес: Санкт-Петербург
По умолчанию 05.04.2008, 12:26

Цитата:
... нам в ВУЗе чуть ли не на каждом предмете рассказывают о всевозможных чудесных диаграммах, подходах и тому подобному, ....
Повесь над своим столом плакат крупными буквами:
"Серебряной пули" не существует.


The difference between theory and practice is that in theory, there is no difference between theory and practice, but in practice, there is.
Ответить с цитированием
Ads
  (#13 (permalink)) Старый
just_vladimir just_vladimir вне форума
Member
 
Сообщений: 420
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 08.11.2006
По умолчанию 05.04.2008, 13:29

Блин, это то понятно, еще бы некоторые преподы это понимали, а лучше бюрократы в министерстве, составляющие программы... Но все равно ведь нужно как-то уметь находить баланс между документацией и её отстутствием, между текстовыми описаниями и диаграммами, регламентированной последовательностью разработки и относительной свободой.
Ответить с цитированием
  (#14 (permalink)) Старый
Влад Влад вне форума
Специалист
 
Сообщений: 3,884
Сказал(а) спасибо: 1
Поблагодарили 25 раз(а) в 25 сообщениях
Регистрация: 27.06.2002
Адрес: Санкт-Петербург
По умолчанию 06.04.2008, 12:04

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

А "баланс между документацией и её отстутствием, между текстовыми описаниями и диаграммами, регламентированной последовательностью разработки и относительной свободой" - главным образом, регулируется бюджетом (в б`ольшей степени) и сроками проекта. Есть, конечно, и другие факторы, - если это военная разработка, то вести ее просто придется по установленному ГОСТом процессу, независимо от того, как считает разработчик.
Ответить с цитированием
  (#15 (permalink)) Старый
just_vladimir just_vladimir вне форума
Member
 
Сообщений: 420
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 08.11.2006
По умолчанию 06.04.2008, 14:04

Цитата:
главным образом, регулируется бюджетом (в б`ольшей степени) и сроками проекта
Тоесть надо понимать, что сложностью проекта.

Цитата:
Есть, конечно, и другие факторы, - если это военная разработка, то вести ее просто придется по установленному ГОСТом процессу, независимо от того, как считает разработчик.
О да, нам и про свежайшие ГОСТ'ы 80ых годов тоже рассказывали
Ответить с цитированием
Ответ

Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Trackbacks are Вкл.
Pingbacks are Вкл.
Refbacks are Выкл.


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Разработка программного обеспечения на заказ. smileboy Софт и программы 0 21.12.2011 21:23
Регистрация своего программного обеспечения SergPas Офтопик 10 25.07.2011 22:11
Разработка программного обеспечения Picxcel IT 0 27.01.2011 16:31
Создание программного обеспечения NaN Общие вопросы создания ПО 4 22.03.2010 19:17
Написание программного обеспечения для работы в XLS&XML vbeketov Вопросы начинающих программистов 3 09.03.2010 16:35
Подтверждение программного обеспечения Exmap Вопросы начинающих программистов 19 21.10.2008 14:28
вакансия:Тестировщик программного обеспечения leto Работа 0 20.07.2007 11:07
вакансия:Тестировщик программного обеспечения leto Работа 0 10.07.2007 18:33
Оценка стоимости программного обеспечения Dian Мысли вслух 3 21.06.2007 17:52
Защита программного обеспечения MSwift Алгоритмы 6 16.05.2006 14:36
выбор программного обеспечения urak Prolog 4 14.03.2006 15:27
Где узнать побольше про treeView imported_BoBo .NET 1 31.12.2004 03:25



Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Нardforum.ru - компьютерный форум и программирование, форум программистов