19 ноября, понедельник 07:58
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Как составить техническое задание на разработку ПО?

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Как составить техническое задание на разработку ПО?

    Глупый, конечно, вопрос. Для тех, кто имеет соответствующее образование, это не проблема, я думаю. А как быть тем, у кого нет? Где хотя бы почитать, какие-то может нормы есть, ГОСТы. Может, у кого свое есть, поделитесь. Конкретное содержание не принципиально. Как оно выглядит хоть?
    Ткните носом, короче, буду шибко благодарен.

  • #2
    Было! ЕСКД называлось (Единая система конструкторской документации). Там и про техническое задание, и про технический проект. Еще Эр-Винчики, БП-Винчики живут... CASE-средства... Увы, Интернет-ссылок не знаю.
    Извините, что снова "попался под ноги"
    Да пребудет с Тобою Великая Сила! ©

    Комментарий


    • #3
      На форуме это было... поищи повнимательнее...


      вот тут примерно... http://dom.bankir.ru/showthread.php?...143&#post48143
      Подавая сигналы в рог будь всегда справедлив, но строг. ©

      Комментарий


      • #4
        Romsan - огромное спасибо. То, что нужно!!!
        Но на чье-нибудь ТЗ я бы все же глянул, для профилактики

        Комментарий


        • #5
          Кинь мыло пришлю пример
          А на самом деле форма технического задания отлична для различных организаций в которых работаешь. И уверены ли Вы что Вам требуется именно техническое задание, а не постановка задания?

          Комментарий


          • #6
            не проблема, я думаю

            В разработке ПО это как раз и есть самая большая проблема (если речь идет о постановке задачи).

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

            Комментарий


            • #7
              ZON
              уверены ли Вы что Вам требуется именно техническое задание, а не постановка задания?
              Не уверены "Хочу все знать" (c), а с какого боку подойти, не знаю.

              Jene
              В разработке ПО это как раз и есть самая большая проблема (если речь идет о постановке задачи).
              Ну да, согласен. Только я имел в виду, что для соответвтующих образом подготовленных людей это легче, чем для неподготовленных.

              Комментарий


              • #8
                Согласен с предыдущим автором...
                У меня например диплом по Интернет-банкингу - копался , копался в Нете, кучи информации накопал - диплом-то напишу, а вот со сдачей отчета по практике и программы по практике = беда... И вот почему: практика у меня по Интернет-банкингу - сплошная аналитическая работа... Посему с ТЗ тоже беда...
                Если есть у кого идеи - буду очень рад пообщаться...

                Комментарий


                • #9
                  all_in_one намылил. Правда не моё... поэтому "во избежании" )
                  Подавая сигналы в рог будь всегда справедлив, но строг. ©

                  Комментарий


                  • #10
                    Romsan
                    А можно мне тоже на мыло. Интересно посмотреть.

                    Комментарий


                    • #11
                      так вываливайте сюда - обсудим

                      Комментарий


                      • #12
                        Shamai угу©

                        Виталий Власов ИМХО, для публичного обсуждения не годится... ибо стоит копирайт.
                        Подавая сигналы в рог будь всегда справедлив, но строг. ©

                        Комментарий


                        • #13
                          Понял , тогда на мыло yes146n@mail.ru Плиз

                          Комментарий


                          • #14
                            Как составить техническое задание на разработку ПО?
                            Это на практике сильно зависит от того, кто пишет и кому адресовано (то есть кто будет выполнять). Поскольку ситуации по жизни различны, стандартного формата на все случаи нет.

                            Если я пишу ТЗ на некий программный продукт, который будет делать другой исполнитель (группа), то есть я - заказчик, я пользуюсь следующими постулатами:

                            - все, что явно не задано, сделано не будет,
                            - все, что не определено явно и однозначно, будет сделано неправильно.

                            Эти постулаты родственны правилу "если хочешь сделать что-то как следует, делай это сам" и порождают другое правило: "если хочешь, чтобы что-то было сделано как следует, составь исчерпывающее описание требуемого".

                            Пример нарушения постулатов: недавно написал ТЗ на некий АРМ человеку, которого лично уважаю. В спешке многое упустил - и получил:
                            - для полей, где явно не указал метод проверки - проверок нет,
                            - для колонок, для которых явно не указал заголовки, выбраны какие-то несусветные слова
                            и тд и тп. И при всем моем раздражении я сам был виноват: это МОИ проблемы. Ну не знал человек этого и не думал об этом. Пришлось тратить время на исправления...

                            Если я пишу ТЗ на некий программный продукт сам себе ("чтобы было" или заказчик требует), стараюсь, чтобы он был максимально полезен для моей репутации (побольше красивых слов - скромность есть кратчайший путь к бесславию!) и максимально безопасен с точки зрения возможных претензий к результату его выполнения (поменьше конкретных требований). Что на самом деле нужно делать - я и так знаю.
                            Последний раз редактировалось mgolovanov; 13.02.2002, 16:04.
                            М.Голованов

                            Комментарий


                            • #15
                              К_Маркелов
                              Помимо ГОСТов, составлявших Единую Систему Конструкторской Документации (ЕСКД), были еще и ГОСТы Единую Систему Программной Документации (ЕСПД). Думаю, их никто не отменял.
                              Со ссылками не помогу, но сами книжки у меня были, выбросить не мог....

                              Комментарий


                              • #16
                                Кое-какие ГОСТы времен Союза ССР:
                                http://softdev.omskreg.ru/gost/index.asp

                                Комментарий


                                • #17
                                  JAO были еще и ГОСТы Единую Систему Программной Документации (ЕСПД)
                                  Извините, Уважаемый Яков Озадовский! Вы совершенно правы. Про ЕСПД-то я и забыл...
                                  Да пребудет с Тобою Великая Сила! ©

                                  Комментарий


                                  • #18
                                    К_Маркелов
                                    Про ЕСПД-то я и забыл
                                    Я тоже. Хотя для своего времени был хороший "сходняк". Да и сейчас можно использовать... чтоб чего-нибудь не забыть. Но от жизни они отстали.

                                    Берите здесь: http://vmk-mvmk.ksu.ru/~sas/doc/gosts/gost19.htm
                                    М.Голованов

                                    Комментарий


                                    • #19
                                      Сообщение от mgolovanov
                                      К_Маркелов
                                      Про ЕСПД-то я и забыл
                                      Я тоже. Хотя для своего времени был хороший "сходняк". Да и сейчас можно использовать... чтоб чего-нибудь не забыть. Но от жизни они отстали.

                                      Берите здесь: http://vmk-mvmk.ksu.ru/~sas/doc/gosts/gost19.htm
                                      Господа, хотелось бы узнать есть ли где ресурсы РУ-нете в которых можно узнать о международных стандартах создания ПО (ТЗ на создание ПО) или где взять пример?
                                      mailto:gennius@ilit.ru

                                      Комментарий


                                      • #20
                                        вот сайт по ГОСТам: http://www.vniiki.ru
                                        Хотя не все "нужные" ГОСТы там есть, но все-таки кое что можно найти.
                                        Опять же большинство ГОСТов разрабабтывалось давно, еще в советские времена, поэтому не совсем отражают текущие реалии.
                                        Потому лично я беру их за основу, а затем творчески перерабатываю для каждой конкретной ситуации.

                                        Комментарий


                                        • #21
                                          Есть один совет.
                                          В свое время надо было заказать программный модуль и исполнитель требовал, чтобы работа была сделана в соответствии с тех. заданием. Нам удалось убедить его в том, что для написания тех.задания "писатель" должен обладать специфическими знаниями и навыками, которые "эксплуататор" готового решения не имеет. Сделали так: мы написали бизнес-требования с максимально-возможным описание функционала. Исполнитель на основе этого документа сам для себя сваял тех.задание, которое мы внимательно изучили, согласовали и утвердили. Модуль был написан, установлен и запущен в эксплуатацию.

                                          Комментарий


                                          • #22
                                            Сообщение от agm66
                                            Есть один совет.
                                            В свое время надо было заказать программный модуль и исполнитель требовал, чтобы работа была сделана в соответствии с тех. заданием. Нам удалось убедить его в том, что для написания тех.задания "писатель" должен обладать специфическими знаниями и навыками, которые "эксплуататор" готового решения не имеет. Сделали так: мы написали бизнес-требования с максимально-возможным описание функционала. Исполнитель на основе этого документа сам для себя сваял тех.задание, которое мы внимательно изучили, согласовали и утвердили. Модуль был написан, установлен и запущен в эксплуатацию.
                                            Отличный совет!

                                            Иначе говоря, если переводить это на язык мировой практики заказных разработок, сначала была написана СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ (Software Requirements Specification). Это тот документ, на основании которого заказчик принимает работу. Если продукт делает то, что требовалось, и так, как требовалось, у него нет оснований увиливать оит приемки и оплаты.

                                            Далее была написана ПРОЕКТНАЯ СПЕЦИФИКАЦИЯ (Software Design Specification). Это описание того, как продукт будет устроен и в какой среде будет работать. Утверждение этой спецификации в контексте вышеприведенной реплики, очевидно, тоже было важно для исполнителя, особенно, наверное, точное описание требуемой среды, так как, утверждая среду, заказчик не сможет отказаться от приемки и оплаты на основании того, что у него-де нет той версии ОС, в которой работает продукт, того сервера БД, который использован, и так далее.

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

                                            - функциональные требования, то есть описание тоо, что и как продукт и его составные части (если система распределенная) должны делать и с какими параметрами;

                                            - нефункциональные требования, где описывается оборудование, среда исполнения и все прочее, что иначе вошло бы в проектную спецификацию.

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

                                            Таким образом, получается ровно один документ - СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ, на основании которого исполнитель делает, а заказчик принимает работу.

                                            Сразу замечу что содержание этого документа, описанное мною не соответствует принятому в постсоветском пространстве термину "ТЕХНИЧЕСКОЕ ЗАДАНИЕ". Это вообще термин какой-то странноватый - что задание, понятно, но почему только техническое? Поэтому, чтобы исключить недоразумения, мы в договоре пишем: "разработка.... и прием в опытную ... осуществдляются на основании СПЕЦИФИКАЦИИ ТРЕБОВАНИЙ, разрабатываемой совместно представителями Заказчика и Исполнителя согласно плану-графику выпролнения работ ..." и так далее.
                                            М.Голованов

                                            Комментарий


                                            • #23
                                              2 mgolovanov

                                              Не будете ли Вы так добры скинуть мне пример Спецификации требований.

                                              Комментарий


                                              • #24
                                                Сообщение от Shuric
                                                2 mgolovanov

                                                Не будете ли Вы так добры скинуть мне пример Спецификации требований.
                                                Да сколько угодно... но зачем это Вам? Понимаете, этот документ должен констатировать все существенные детали конкретного проекта. С другой стороны, каждый проект в разработке ПО уникален - нет двух одинаковых. Это не штамповка деталей, кто бы что бы ни говорил о т.н. "промышленной разработке ПО" (фу, бред какой-то...). Просто Исполнитель должен минимизировать РИСК НЕПРИЕМКИ результата, а Заказчик - РИСК НЕСООТВЕТСТВИЯ его ожиданиям. Вот и все. Что Важно Заказчику? - получить ПОЛЕЗНЫЙ результат. Что нужно Исполнителю? - ПРОДАТЬ результат.

                                                Если Вы - Заказчик, просто составьте список всех общих требований, а потом детализируйте каждое из них насколько нужно -сами или с помощью Исполнителя. Если Вы Исполнитель. - попытайтесь получить список всех общих требований и сами или с участием Заказчика детализируйте каждое из них насколько нужно - так, чтобы Вам стало понятно, что сделать нужно, а что не нужно.
                                                М.Голованов

                                                Комментарий


                                                • #25
                                                  Уважаемые Господа!

                                                  Помогите! Очень нужен образец ТЗ на разработку сайта. Что и как там должно быть я уже хорошо себе представляю, а вот с тем чтобы перенести это знание на бумагу - проблема. Да ещё и словами, легко и, главное, однозначно понимаемыми программистом. Поэтому очень нужен шаблон, чтобы понимание иметь хоть с какой стороны начать.

                                                  Буду премного благодарна за любой отклик!

                                                  С уважением,
                                                  Ольга Загоскина

                                                  ola_mail@mail.ru

                                                  Комментарий


                                                  • #26
                                                    для небольшой программки, IMHO, подойдет:

                                                    http://www.izcity.com/data/soft/article376.htm

                                                    Комментарий


                                                    • #27
                                                      Можете ли и мне сбросить пример Спецификации требований? Ума не приложу как нужно оформить на бумаге

                                                      Комментарий


                                                      • #28
                                                        Shuric, прошу поделиться собранными образцами спецификации требований и технического задания, очень срочно нужно. мой адрес ludmila03091979@yandex.ru

                                                        Комментарий


                                                        • #29
                                                          Assol, прошу Вас помочь разобраться с аналогичной проблемой, удалось ли найти примеры? сбросьте мне ludmila03091979@yandex.ru Буду благодарна за отклик

                                                          Комментарий


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

                                                            Комментарий

                                                            Пользователи, просматривающие эту тему

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X