Компьютерный форум
Правила
Вернуться   Компьютерный форум > Форум программистов > Теория программирования > Общие вопросы создания ПО
Перезагрузить страницу Создание программного обеспечения
Ответ
 
Опции темы Опции просмотра
  (#1 (permalink)) Старый
NaN NaN вне форума
Member
 
Сообщений: 36
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 05.08.2009
Red face Создание программного обеспечения - 21.03.2010, 15:32

Добрый %time%, возникла проблема - решил написать программу по всем требованиям ГОСТа и тд.
только где взять материал? пока прочёл лишь ГОСТ19.201 :rules:
мб кто знает где можно почитать про функциональные и нефункциональные требования к программе, подготовку ТЗ. И вообще - подскажите хорошую книгу по проектированию ПО. Хочу составить программу с плагинной архитектурой, ибо захотелось не просто HelloWorld написать...
Благодарю!
Ответить с цитированием
  (#2 (permalink)) Старый
Влад Влад вне форума
Специалист
 
Сообщений: 3,884
Сказал(а) спасибо: 1
Поблагодарили 25 раз(а) в 25 сообщениях
Регистрация: 27.06.2002
Адрес: Санкт-Петербург
По умолчанию 21.03.2010, 16:07

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

Анализ, управление требованиями и управление проектами - это отдельная область программистской деятельности, имеющая очень мало общего с кодированием. Во всяком случае, вот некий список литературы, которую будет полезно почитать (все книги существуют в электронном виде, гугл в помощь):
Брукс Фредерик Мифический человеко-месяц.pdf
Вигерс Карл Разработка требований к программному обеспечению.pdf
Панкаж Джалота Управление программным проектом на практике.djvu
Ларман Крэг Применение UML и шаблонов проектирования.djvu


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)) Старый
NaN NaN вне форума
Member
 
Сообщений: 36
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 05.08.2009
По умолчанию 21.03.2010, 21:25

Спасибо за совет! Список весьма полезен.
Я немного неточно написал:
1 задача - именно по ГОСТам, понять как строятся отношения Подрядчика-Заказчика, хотел спросить может быть есть ещё нормативные документы.
2 задача - непосредственное проектирование ПО, структура программы и т.д.
Ответить с цитированием
  (#4 (permalink)) Старый
Влад Влад вне форума
Специалист
 
Сообщений: 3,884
Сказал(а) спасибо: 1
Поблагодарили 25 раз(а) в 25 сообщениях
Регистрация: 27.06.2002
Адрес: Санкт-Петербург
По умолчанию 22.03.2010, 00:48

По порядку:
1. ГОСТы, вообще говоря, не описывают, "как строятся отношения Заказчика и Подрядчика". ГОСТам на эти самые отношения глубоко наплевать. Отношения Заказчика и Подрядчика (Исполнителя) регулируются Договором между ними. Именно Договор определяет - что именно поручает Заказчик сделать Исполнителю (а Исполнитель - принимает на себя обязательства сделать), в какие сроки, и сколько это будет стоить. ТЗ обычно идет Приложением к Договору, и содержит уже более детальные требования Заказчика, а также определяет состав отчетных материалов и порядок приемки этих материалов. Само ТЗ может также содержать приложения. Грубо говоря, задача ТЗ - это провести четкую границу между тем, что делать надо (и за что по Договору немалые деньги будут уплочены), и тем, что делать не надо (за что — деньги уже не плотют). И все. Оно объем работ должно четко обозначить. А вовсе не расписывать в деталях, какую такую хрень программисту надо сделать, штоб закодить все по бумажке. ТЗ определяет этапы работ, сроки, и часто — стоимость этапов. И - самое существенное, в чем смысл его! - отчетность, требования к приемке и обеспечению испытаний.

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

Разработка хорошего ТЗ - это, я бы сказал, своего рода искусство, которое приходит с опытом; ничего страшного, если получится "первый блин комом". Как правило, ТЗ пишет Исполнитель - зачастую это отдельный (и нередко - отдельно оплачиваемый! Но в любом случае, стоимость разработки ТЗ учитывается в общей стоимости работ) этап работы - он, Исполнитель, все-таки лучше знает, что он может сделать и как, чтобы удовлетворить требованиям Заказчика. При разработке ТЗ есть две опасности: а). Исполнитель формулирует ТЗ в самых общих выражениях, надеясь в дальнейшем подогнать "то, что получилось" под расплывчатое ТЗ. Как правило, такая хитрость приводит к обратному результату: на приемке Заказчик и Исполнитель начинают трактовать любую неясность в ТЗ каждый в свою пользу; ну и результат - понятен и плачевен.... б). Другая крайность - в ТЗ описываются все-все-все мельчайшие подробности, вплоть до деталей реализации отдельных функций программы. И это тоже абсолютно излишне - ТЗ должно формулировать полезный для Заказчика функционал, ограничения, налагаемые на реализацию, и не должно касаться подробностей его внутренней реализации. Смотри выше - ТЗ должно обозначить границы объема работ, и не более того.
Отмечу, что ТЗ содержит ключевые требования к ПО, но - не все требования. Все требования к ПО всегда шире, чем то, что явно прописано в ТЗ. И создать полный и непротиворечивый перечень требований (SRS, Software Requirements Specification) - задача отдельного человека в проекте, аналитика. Равно как и отслеживание этих требований, трассировка "требование -> код".

Кроме собственно ТЗ, еще один важнейший документ - Программа и методика испытаний (ПиМИ). Чем раньше этот документ появится и будет согласован Заказчиком и Исполнителем, тем лучше для них обоих. Заказчик с момента его согласования четко понимает, что именно и как именно он будет принимать; Исполнитель же получает по сути дела приемочный тест-план.

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


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)) Старый
NaN NaN вне форума
Member
 
Сообщений: 36
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 05.08.2009
По умолчанию 22.03.2010, 19:17

Спасибо за объёмный ответ! Буду копать...
Ответить с цитированием
Ads.
Ads
Ответ

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

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

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


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Разработка программного обеспечения на заказ. smileboy Работа 0 22.12.2011 20:12
Разработка программного обеспечения на заказ. smileboy Софт и программы 0 21.12.2011 21:23
Создание программного обеспечения для видеосистемы сергей123 Информационные технологии 1 17.03.2011 15:11
Разработка программного обеспечения Picxcel IT 0 27.01.2011 16:31
Написание программного обеспечения для работы в XLS&XML vbeketov Вопросы начинающих программистов 3 09.03.2010 16:35
Подтверждение программного обеспечения Exmap Вопросы начинающих программистов 19 21.10.2008 14:28
Вакансия:Тестировщик программного обеспечения leto Работа 0 05.09.2007 19:48
вакансия:Тестировщик программного обеспечения 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
Установка программного обеспечения на компьютер BD Visual C++ 3 01.11.2004 15:51



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