план разработки по образец

Проектирование программного обеспечения

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

За 13 лет опыта компании «Эдисон» в аутсорс-разработке для средних и крупных компаний из России, США, Европы и Австралии мы выработали собственную схему проектирования ПО, о которой в этом посте и расскажем.

Зачем нужно проектирование программного обеспечения

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

Проектируя ПО заранее, разработчик получает возможность:

Подготовительный этап

В зависимости от особенностей проекта порядок разработки программного обеспечения может отличаться, но в общем виде он такой:

При подготовке к проектированию решаются организационные вопросы:

Этапы и результаты проектирования

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

Требования к техническому заданию на разработку программного обеспечения

Минимально достаточное ТЗ должно:

Примеры техзаданий на разработку ПО

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

ТЗ на программное обеспечение Protector

Объект ТЗ: разработка и интеграция с существующей системой модульного ПО для мониторинга удаленных устройств охраны
Заказчик: ООО «ВТИМБ»

Сценарии использования образовательной системы

Объект ТЗ: создание образовательной системы

ТЗ на разработку ПО SMPP-шлюз

Объект ТЗ: разработка программного обеспечения SMPP-шлюза
Заказчик: IMT

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

Проектирование — для больших парней

За годы работы нами написаны сотни техзаданий на разработку программного обеспечения различной степени сложности, и мы понимаем, что роль разработки подробного ТЗ сложно переоценить. Бывало, работали с ТЗ на более чем 1000 страниц, и для крупных проектов — это оправдано и необходимо. Тем не менее не стоит забывать о принципе целесообразности — нет смысла писать ТЗ на 20 страниц для двухдневной разработки продукта.

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

Источник

Планирование программных разработок: делюсь опытом

Сегодня я хочу поделиться своей методикой планирования времени в разработке ПО, которая может быть очень быстро внедрена в небольших коллективах. Она очень проста во внедрении и «поддержке», чем показала себя очень эффективной.В разное время, имея разные задачи и разные ограничения в управлении разработкой, я испробовал всё: от Microsoft Project и онлайн-сервисов до «самописных» решений. У каждого варианта есть свои недостатки и преимущества, и каждый из них заслуживает отдельной статьи. Сегодня речь пойдет о наиболее простом варианте — управление релизной разработкой в Excel-е. Также я поделюсь шаблоном этого плана, который каждый может доработать «под себя».

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

Итак, задача: упорядочить процессы разработки и поддержки продуктов компании при следующих условиях: основную часть задач составляют задачи длительностью от дня до трех недель, каждая затрагивает одного разработчика и одного тестировщика, разработка ведется на «релизной» основе — раз в неделю оттестированные модули включаются в очередную версию, каждая задача имеет конкретного внутреннего «заказчика» (менеджеры), которому, конечно, важна дата релиза, где появится его задача, общее число параллельных задач в производстве — от десяти до пятидесяти.

Как я уже говорил выше, я испробовал разные способы упорядочивания работы с такими проектами. Microsoft Project, например, не обладает достаточной степенью гибкости в управлении изменениями в плане, он предназначен для управления связанными в проект задачами, в которых их очередность объясняется их сущностью, а не порядком поступления или срочностью. Менять задачи в плане Project местами довольно неудобно, особенно, если это нужно делать часто. Да и вообще, для описанной задачи там всё неудобно.

Использовать сервисы web-based, как онлайновые, так и инсталлируемые на офисный сервер — лучше, потому что среди них выбор больше. Например, на прошлом месте работы я внедрил JIRA и мы ее очень активно использовали. Но минусов у нее хватает… Решения, которое нужно было мне, я среди них не нашел. Если кто-то может его подсказать, буду рад.Возвращаясь к теме планирования задач с использованием Microsoft Excel.

Вот так выглядит план:

Итак, строки плана — задачи. Столбцы имеют следующую структуру:

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

Внизу автоматически суммируются часы по всем задачам одного типа на неделю. Предполагается, что задачами одного типа занимаются программисты одной специализации, поэтому эти часы можно соотнести с доступными часами этих программистов. Как рассчитывать доступные для планирования часы — у каждого по-своему, например, можно заложить процентов 20 на исправление багов и на непредсказуемые срочные доработки, а 80 оставить для планирования.Прошедшие недели «сворачиваем» минусиками сверху. Новые недели добавляем копированием предыдущей недели на следующий период. При копировании можно автоматически пересчитывать даты и номер недели.Как только задача полностью выполнена, в блоке сделано ставим «Да». Настраиваем фильтр так, чтобы он НЕ показывал сделанные задачи (снимаем галочку с «да» в первом столбце).Очень удобно, что при всем при этом работает фильтрация (Filter в «экселе») по строке 5, с заголовками. Это позволяет отвечать на вопросы:

Как только задач становится больше 50, или задачи более сложны по структуре, или исполнителей много, или вы чувствуете, что эксель — слишком сложный или неподходящий инструмент для планирования, тогда нужно искать что-то более подходящее, благо на рынке довольно много готовых решений. Для относительно простых ситуаций (а их все-таки большинство) данного инструмента, IMHO, было бы достаточно… если бы не следующий абзац.

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

Строки — исполнители (люди, группы или целые отделы), столбцы — время. Приходит новая задача — падает в «неразобранное». Я ее оттуда перетаскиваю на нужную строку, она либо раздвигает стоящие там уже задачи, либо перетаскиваю в хвост этих задач у конкретного исполнителя, и она цепляется в «водопад» после последней. Перетаскиванием я могу произвольно менять порядок очередных задач для исполнителя, но задачи для него всегда выстраиваются в «водопад». Либо могу переносить задачу с одного исполнителя на другого, тогда перестраивается «водопад» у обоих. После нажатия на кнопку «Применить » мне демонстрируется перечень изменений (заказчик — задача — старая дата — новая дата) и по нажатию на кнопку «Разослать» происходит уведомление заказчиков и исполнителей об изменениях. Текущая задача может быть в любой момент прервана, ее остаток может быть пересмотрен по времени и поставлен куда-нибудь в будущее или перенесен в блок «неразобранное» или вообще удален. Что происходит в этом случае? Все следующие задачи сдвигаются.

Источник

План разработки по образец

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

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

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

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

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

В таблице приведены некоторые опытные данные:

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

Пример Итерации для внутреннего телефонного коммутатора

Определение числа итераций

В очень простом проекте можно ограничиться одной итерацией на каждом из этапов.

Для более объемного проекта разработка будет вестись следующим образом:

Для большого проекта с рядом новых и неопробованных технологий схема может быть следующей:

Итак, цикл разработки может быть следующим:

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

Риски, объем и сложность проекта могут вносить свои коррективы:

Сопоставление обзоров в традиционной водопадной последовательности с итеративным подходом

В проекте, разрабатываемом по методу водопада, в конце каждой стадии проводится критический обзор создаваемых рабочих продуктов, а именно:

В Rational Unified Process (RUP) обзор компонентов соответствующих рабочих продуктов проводится по их завершении в итерации, но вехи (и обзор, соответственно,) планируются на окончание четырех этапов, начального, уточнения, построения и внедрения. Руководитель проекта, желающий применять RUP, может столкнуться с необходимостью сгладить этот конфликт, возникающий, например, из-за обязательств по контракту. В идеале руководитель проекта должен попытаться убедить заказчика в том, что подход на основе этапов и итераций дает большую прозрачность хода проекта и снижает риски, вследствие чего отпадает необходимость в SRR, SSR и пр. Однако это не всегда возможно, и тогда руководитель проекта должен запланировать время для таких обзоров. В RUP можно указать моменты, в которые эти важные рабочие продукты, точнее говоря, их эквиваленты в RUP, оказываются фактически завершенными, хотя это не всегда совпадает с этапами или итерациями.

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

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

Организация проекта

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

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

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

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

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

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

На каждом этапе в ходе проекта на передний план выступают определенные группы задач:

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

© Copyright IBM Corp. 1987, 2006. Все права защищены..

Источник

12.2 План разработки ПО

12.2 План разработки ПО

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

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

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

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

1) выбор методов и средств разработки требований;

2) выбор методов и средств проектирования ПО;

3) выбор языков программирования, средств кодирования, компиляторов, редакторов связей и загрузчиков;

4) аппаратную поддержку для инструментальных средств.

Читайте также

8.1.3 План документирования

8.1.3 План документирования 8.1.3.1 Общие положения Документатор должен подготовить план документирования, в котором должны быть определены задания, выполняемые при создании конкретной документации. Данный план должен быть официально согласован заказчиком, что

6.5.2. План сертификации

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

12.1 План сертификации в части ПО

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

12.3 План верификации ПО

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

12.4 План квалификационного тестирования ПО

12.4 План квалификационного тестирования ПО План квалификационного тестирования ПО содержит информацию для проведения квалификационного тестирования (испытаний) систем и подсистем ПО, описание тестовой среды, которая будет использована при тестировании,

12.5 План управления конфигурацией ПО

12.5 План управления конфигурацией ПО План управления конфигурацией ПО устанавливает методы, используемые для достижения целей процесса управления конфигурацией ПО на протяжении жизненного цикла ПО. Разделы плана следующие:— Среда: описание среды управления

12.6 План обеспечения качества ПО

12.6 План обеспечения качества ПО План обеспечения качества ПО устанавливает методы, которые должны быть использованы для того, чтобы достичь цели процесса обеспечения качества ПО. Содержание плана следующее:— Среда: описание среды обеспечения качества, включая область

12.7 План установки ПО

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

12.8 План передачи ПО

12.8 План передачи ПО План передачи ПО определяет аппаратное и программное обеспечение, а также другие ресурсы, необходимые для поддержки жизненного цикла передаваемого ПО, и описывает планы разработчиков для поставки передаваемых элементов через организации,

Источник

8 принципов планирования разработки, упрощающих жизнь

Скажем прямо, русскому человеку планировать тяжело. Люди в России сильны импровизацией и умением собираться в критический момент, выдавая поразительные результаты. Но жизнь показывает, что команда программистов на подобной идеологии далеко не уедет. Героические усилия в одно время не смогут компенсировать пофигизм в другое.

Что общего у зомби-апокалипсиса и разработки ПО? Простые правила помогают пережить и то, и другое

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

Команды разработчиков допускают такие ошибки при планировании создания ПО.

1. Планировать сроки должны программисты, а не менеджеры

Частая ошибка, когда руководитель проекта, не понимающий должным образом объем и специфику задач, устанавливает сроки проекта не в соответствии с опытом, возможностями и компетенциями команды, а опираясь на собственные представления, желания или запросы клиента. Программистам в подобных группах не позавидуешь. Расхождения запланированных и реальных сроков составляет 40-80%. Атмосфера в коллективе создается гнетущая и отбивающая желание работать. Проблемы следуют одна за другой, а виноватыми выставляются непосредственные разработчики.

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

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

3. Проект разбивайте на мелкие этапы с четкими целями и обязательным обсуждением результатов

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

4. Члены команды должны максимально плотно взаимодействовать друг с другом

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

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

На первоначальном этапе планирования нельзя предусмотреть все ситуации. Поэтому нужно зарезервировать время про запас, чтобы команде не пришлось торопиться и, как следствие, совершать ошибки. Не стоит игнорировать необходимость отладки и доведения ПО до уровня стабильной работы и приемлемого количества багов. Выпуск сырого продукта из-за жесткой экономии времени не разумен. Методология Agile предполагает изменчивость внешних условий и необходимость быстрой и безболезненной адаптации к ним.

6. Нельзя торопиться, нарушать план и уменьшать время разработки ПО

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

7. Документируйте планирование с помощью подходящего таск-менеджера

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

8. Расставляйте приоритеты задачам и концентрируйтесь на главном

Старайтесь в первую очередь реализовывать наиболее важный функционал. Имейте ввиду, что какими-то фичами в процессе разработки придется пожертвовать, равно как и реализацией части идей. А расставить приоритеты возможно исключительно через общение и обмен мнениями.

А что вы думаете по поводу планирования в разработке ПО? Оставляйте свои комментарии к статье. Мы будем рады услышать ваше мнение.

Источник