Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (2)

Наибольший вклад в теги

Все теги (16)

Лучшие ответы пользователя

Все ответы (14)
  • Акт о приеме и передаче выполненных работ

    @Aisu_Kuge
    На самом деле всё зависит от масштабов работы.
    Например всё очень удобно делать через календарный план. Там вы расписываете этапы работы по срокам. Вначале подготовительные этапы. Когда начинается очередной этап разработки, то после передачи продукта заказчику он должен заполнять акт сдачи-приёмки.

    Приведу основные этапы нашего последнего проекта (в скобках основная отчётная документация):

    1. Изучение объекта (Отчёт по результатам анализа. Описание решений по интеграции.)

    2. Разработка и утверждение технического задания и технического проекта (ТЗ, ТП (Описание автоматизируемых функций, Описание организации информационной базы)).

    3. Разработка рабочей документации на систему, разработка или адаптация программ (Руководство администратора, Руководство пользователя + сам Опытный Образец ПО, Задание по безопасности, Протокол оценки задания по безопасности)

    4.1. Интеграция и проведение предварительных испытаний (Программа и методика испытаний. Акт предварительных испытаний. Доработанный Опытный Образец (далее — ОО), Доработанный комплект рабочей документации (далее — РД))

    4.2. Проведение опытной эксплуатации, приемочных испытаний (Акт завершения опытной эксплуатации, Доработанный ОО, Доработанный комплект РД, Акт приемочных испытаний.)

    5. Ввод в промышленную эксплуатацию (Акт приёмки в Промышленную эксплуатацию)

    Но это кусочки. Проект был большой, длился год. Там очень много другой, более специфической документации. То что приведено выше — основные элементы, которые вы можете взять себе на вооружение.
    Ответ написан
    3 комментария
  • ТЗ на разработку программного обеспечения?

    @Aisu_Kuge
    Советовал бы взять за шаблон хорошего ТЗ упрощённые рекомендации PMBoK к проекту, а именно:

    1. Разработка устава проекта (документация первоначальных требований, экономического обоснования, составление перечня заинтересованных лиц)
    2. Разработка плана проекта, т.е. определяем в первом приближении как будет производится разработка и как будет производится контроль.
    3. Собираем требования.
    4. Определяем содержание, разбиваем его на операции, оцениваем ресурсы и время на каждую операцию.
    4.1. Технические подробности, как должна себя вести система в тех или иных случаях, описать требования к дизайну.
    5. Оцениваем весь бюджет разработок.
    6. Желательно как-нибудь описать качество (какие-нибудь характеристики, вроде времени обрабатывания запроса) итогового продукта.
    7. Готовим подробную смету по проекту (включая туда сотрудников, которые будут работать над проектом, и их з/п на время проекта).
    8. Перечень лиц, кто отвечает за контроль хода выполнения работы и качества выполненной работы.

    Всю информацию сводим в единый документ. Тогда и проблем будет по минимуму.

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

    Всё это актуально вне зависимости от методологии разработки.
    Ответ написан
    1 комментарий
  • Как определить, что запущена портативная версия программы?

    @Aisu_Kuge
    Совсем не понятно что это за продукт. Больше бы инфы.

    Обычно в портативных версия настройки лежат в *.ini. Как вариант защиты от «портатирования» программы — перенести настройки в реестр и при инсталляции вносить в программу инфу, где лежат настройки. Если их там нет, то настойчиво требовать переустановить программу.
    Ответ написан
    2 комментария
  • Акт о приеме и передаче выполненных работ

    @Aisu_Kuge
    MindMinimal, судя из опыта, много последующих доработок проходит, когда не собраны нормально требования, либо собраны на скорую руку по принципу «На отъе....». Наша организация выступает в качестве заказчика на разработки, так вот есть у нас руководители, для которых, в принципе, проект и делается, но которые считают, что «все предусмотреть не возможно». Поэтому на начальном этапе они в требования закладывают «главное, чтобы работало». А затем начинают «двигать кнопки и пытаться натыкать котят там, где они не уместны».

    От этого вас спасёт совместная детальная проработка требований и добавление в договор пунктов про доработки (двигать кнопки — бесплатно, добавить новую форму или функцию — по договорённости сторон, но не менее 2,5% от начальной стоимости работ).
    Ответ написан
    1 комментарий
  • Акт о приеме и передаче выполненных работ

    @Aisu_Kuge
    Была статья на Хабре, но в избранное в своё время забыл добавить, но смысл таков:
    — А мой друг или дядя, Пётр, специалист в этом деле, он говорит, что лучше так сделать…
    — Да ваш друг гений, дайте мне его контакты, я его найму себе, ведь он в несколько секунд оценил технологии разработки, время на саму разработку, предвидел возможные доработки и заложил их в проект. А также столь скорый и поверхностный анализ гарантированно защищает от различных факапов.

    На Хабре была хорошая статья по ТЗ (но я не сохранил, может кто поможет найти) на сайт (свой, извини)
    Ответ написан
    Комментировать

Лучшие вопросы пользователя

Все вопросы (3)