Что такое система защиты. Структура системы защиты. Привилегии. Отмена восстановления системы

Apple никогда не выпустила бы iPhone, если бы не разработки советских и российских ученых. Об этом обозреватель ресурса Rusvesna Алексей Гумилёв, по словам которого в «яблочный» смартфон «просто напичкали уже существующие плюшки, истоки изобретения которых лежат в России».

Возможно, вы ещё не слышали, что это американцы победили фашистов, первыми полетели в космос и что это у них придумали всё самое лучшее. Мобильники и интернет – вот чем пытается повысить авторитет Америки современное молодое поколение.

А никто не думал, что родина этих изобретений в России? Пусть не в том виде, в котором мы их знаем нынче, но это так. Даже первая американская мобила была размером с домашний миксер, а пульт связи весил 12 кг. Но это не американская находка, а советская. Ещё в 1957 году мобильный телефон изобрёл Куприянович.

«Огромное количество всех изобретений имеет начало в Советской или постсоветской России».

Гусеничный ход, трамвай, самолёт, вертолёт, парашют, баллистическая ракета, космический корабль, первый спутник Земли, космическая станция, луноход, электронный микроскоп, пересадка органов, искусственные органы, первая в мире АЭС, водородная мощь и многое другое – это всё изобретено русскими. Всё, начиная с лампочки, изобрели русские. Не говоря уж о элементарной сварке металлов, без которой американские танки и прочий военный хлам казались бы совсем убогими и сплошь напичканы заклёпками.

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

Карманный телефон Куприяновича весил 70 граммов

Это далеко не все инновации, которые присвоили себе американцы и подытожили: «Русские деградировали, а мы изобрели iPhone». Да не в США изобрели этот айфон, в него просто напичкали уже существующие плюшки, истоки изобретения которых лежат в России. Все эти плюшки не имели мирового патента, поскольку являлись секретными военными разработками Союза.

Потом эти плюшки рассыпались по миру и их модернизировали и уменьшили в Азии, Америке и Европе, а отсутствие патента дало возможность присвоить их изобретение себе. Какой нафиг Стив Джобс, будь он покоен? Ещё скажите, что он лично делал электронные платы, сидя с дымящимся паяльником в руке. Подавляющее большинство электронной начинки всех без исключения гаджетов (iPhone тоже) произведено и собрано под одним корпусом в Китае.

Как видим, Америка присвоила себе всё, что создала Россия.

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

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

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

Все, конечно, верно. Вместо функций и процедур теперь программист оперирует с интерфейсами компонент, бизнес-объектов, сервисов, что позволяет ему в кратчайшие сроки создавать сложные программные комплексы. Однако «интеллекта» в этих комплексах не больше, чем в самой примитивной бактерии. Такие прикладные системы как Facebook и Amazon – не более чем нагромождение различного функционала для структурированного сбора, хранения и представления данных. При работе с ними человека данные становятся информацией. Без человека эти системы – просто наборы нулей и единиц. Поэтому ценность таких систем определяется ценностью для человека организуемой ими информации. При этом идеи организации информации принадлежат тому же человеку, а не системам.

Но идеи организации не проектируются, не разрабатываются как ПО. Они рождаются в головах изобретателей в результате творческого процесса. Далее такие идеи реализуются в системах типа Oracle, DB2, AutoC AD, Microsoft Windows и т.д. А эти системы уже не строятся на базе компонентно-сервисного подхода. Здесь все куда более сложно! Ни одна из имеющихся методологий разработки программного обеспечения не в состоянии полноценно поддерживать процесс создания системного ПО. Тут у каждой фирмы свое ноу-хау, своя история.

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

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

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

Нужно ли заказчику понимание проблем разработки ПО? Конечно, нужно, если он «грамотный» заказчик. Например, когда потенциальный исполнитель ему с гордостью заявляет о своей приверженности к Agile и Scrum, есть над чем задуматься. Во-первых, у исполнителя явно не все в порядке с организацией собственного производства. Во-вторых, исполнитель не умеет и не хочет работать с клиентом. Есть еще и в-третьих, и в-четвертых...

«Грамотный» заказчик всегда пытается найти «грамотного» исполнителя. И критерием отбора здесь отнюдь не является знание Scrum. Имеется множество факторов, на которые заказчик обращает внимание. Но это уже коммерческая информация – не для статьи.

Модель жизненного цикла информационной системы

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

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

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

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

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

Эксплуатационные работы можно подразделить на подготовительные и основные. К подготовительным относятся:

• конфигурирование базы данных и рабочих мест пользователей;
• обеспечение пользователей эксплуатационной документацией;
• обучение персонала.

Основные эксплуатационные работы включают:

• непосредственно эксплуатацию;
• локализацию проблем и устранение причин их возникновения;
• модификацию программного обеспечения;
• подготовку предложений по совершенствованию системы;
• развитие и модернизацию системы.

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

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

Процесс разработки программного обеспечения (англ. software development process, software process) – структура, согласно которой построена разработка программного обеспечения (ПО).

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

Выделяют следующие основные модели процесса или методологии разработки ПО:

• Каскадная разработка или модель водопада (англ. waterfall model) – модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
• Итеративная разработка (англ. iteration – повторение) – выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование – Реализация – Проверка – Оценка (англ. plan-do-check-act cycle).

Каскадная модель

В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «каскадная модель», и обсуждал недостатки этой модели. Там же он показал, как эта модель может быть доработана до итеративной модели.

В оригинальной каскадной модели Ройса, следующие фазы шли в таком порядке:

1. Определение требований
2. Проектирование
3. Конструирование (также «реализация» либо «кодирование»)
4. Воплощение
5. Тестирование и отладка (также «верификация»)
6. Инсталляция
7. Поддержка

Переход от одной фазы к другой происходит только после полного и успешного завершения предыдущей.

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

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

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

• анализ требований заказчика
• проектирование
• разработка
• тестирование и опытная эксплуатация
• сдача готового продукта.

Рис. Каскадная модель разработки

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

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

Третий этап – реализация проекта. Здесь осуществляется разработка программного обеспечения (кодирование) в соответствии с проектными решениями, полученными на предыдущем этапе. Методы, используемые для реализации, не имеют принципиального значения. Результатом выполнения данного этапа является готовый программный продукт.

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

Последний этап – сдача готового проекта. Главная задача этого этапа – убедить заказчика, что все его требования выполнены в полной мере.

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

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

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

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

Методику «Каскадная модель» довольно часто критикуют за недостаточную гибкость и объявление самоцелью формальное управление проектом в ущерб срокам, стоимости и качеству. Тем не менее, при управлении большими проектами формализация часто являлась очень большой ценностью, так как могла кардинально снизить многие риски проекта и сделать его более прозрачным. Поэтому даже в PMBOK 3-ей версии формально была закреплена только методика «каскадной модели» и не были предложены альтернативные варианты, известные как итеративное ведение проектов.

Начиная с PMBOK 4-ой версии удалось достичь компромисса между методологами, приверженными формальному и поступательному управлению проектом, с методологами, делающими ставку на гибкие итеративные методы. Таким образом, начиная с 2009 года, формально Институтом Проектного Менеджмента (PMI) предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе как плюсы от методики «Водопада», так и достижения итеративных методологов.

В каскадной модели процесса разработки программного обеспечения процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. На основе такой методологии построены российские стандарты и ГОСТы по созданию автоматизированных систем (34-й и 19-й серий), например

ГОСТы 34-й серии:

• ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»;
• ГОСТ 34.201-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»;
• ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;
• ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем»;
• ГОСТ 34.320-96 «Информационные технологии. Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы»;
• ГОСТ 34.321-96 «Информационные технологии. Система стандартов по базам данных. Эталонная модель управления данными».

ГОСТы 19-й серии:

• ГОСТ 19.001-77 «Единая система программной документации. Общие положения»;
• ГОСТ 19.101-77 «Единая система программной документации. Виды программ и программных документов»;
• ГОСТ 19.102-77 «Стадии разработки»;
• ГОСТ 19.103-77 «Обозначения программ и программных документов»;
• ГОСТ 19.104-78 «Основные надписи»;
• ГОСТ 19.105-78 «Общие требования к программным документам»;
• ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»;
• ГОСТ 19.201-78 «Техническое задание, требования к содержанию и оформлению»;
• ГОСТ 19.202-78 «Спецификация. Требования к содержанию и оформлению» и др.

Методические указания:

• РД-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы требования к содержанию документов».

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

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

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

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

Данная модель разработки хороша в следующих ситуациях:

• при внедрении для проектов длительностью от нескольких недель до 2–3 месяцев, т. к. описанные требования не успевают устареть;
• при внедрении систем, где нет подзадач и нескольких этапов разработки функционала (например, после разработки основного функционала СЭД нужно будет доработать ее взаимодействие с системой бухгалтерского учета, а требований к этому взаимодействию пока нет);
• когда требования к создаваемой системе четко определены и зафиксированы.

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

Недостатки каскадной модели. Перечень недостатков каскадной модели при ее использовании для разработки информационных систем достаточно обширен. Вначале просто перечислим их, а затем рассмотрим основные из них более подробно:

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

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

Кроме того, используемые при разработке информационной системы модели автоматизируемого объекта, отвечающие критериям внутренней согласованности и полноты, могут в силу различных причин устареть за время разработки (например, из-за внесения изменений в законодательство, колебания курса валют и т. п.). Это относится и к функциональной модели, и к информационной модели, и к проектам интерфейса пользователя, и к пользовательской документации.

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

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

Рис. Реальный процесс разработки по каскадной схеме.

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

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

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

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

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

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

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

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

Высокий уровень риска. Чем сложнее проект, тем больше продолжительность каждого из этапов разработки и тем сложнее взаимосвязи между отдельными частями проекта, количество которых также увеличивается. Причем результаты разработки можно реально увидеть и оценить лишь на этапе тестирования, то есть после завершения анализа, проектирования и разработки – этапов, выполнение которых требует значительного времени и средств. Как уже было отмечено, запоздалая оценка порождает серьезные проблемы при выявлении ошибок анализа и проектирования – требуется возврат проекта на предыдущие стадии и повторение процесса разработки. Однако возврат на предыдущие стадии может быть связан не только с ошибками, но и с изменениями, произошедшими в предметной области или в требованиях заказчика за время разработки. Причем возврат проекта на доработку вследствие этих причин не гарантирует, что предметная область снова не изменится к тому моменту, когда будет готова следующая версия проекта. Фактически это означает, что существует вероятность того, что процесс разработки «зациклится», и система никогда не дойдет до сдачи в эксплуатацию. Расходы на проект будут постоянно расти, а сроки сдачи готового продукта постоянно откладываться.

Поэтому можно утверждать, что сложные проекты, разрабатываемые по каскадной схеме, имеют повышенный уровень риска. Этот вывод подтверждается практикой: по сведениям консалтинговой компании The Standish Group в США более 31 % проектов корпоративных информационных систем (IT-проектов) заканчивается неудачей; почти 53 % IT-проектов завершается с перерасходом бюджета (в среднем на 189 %, то есть почти в два раза); и только 16,2 % проектов укладывается и в срок, и в бюджет.

Помимо рассмотренных существует еще один серьезный недостаток, присущий каскадной модели разработки, на который также следует обратить внимание. Этот недостаток связан с конфликтом (не всегда явным) между разработчиками, участвующими в выполнении проекта. Конфликт обусловлен тем, что возврат части проекта на предыдущую стадию обычно сопровождается поиском причин и виновных. А так как однозначно персонифицировать ответственного за ошибки можно далеко не всегда, попытки поиска виноватых могут сильно усложнить отношения в коллективе. Как следствие, в рабочей группе часто ценится не тот руководитель, который имеет высокую квалификацию и больший опыт, а тот, кто умеет «отстоять» своих подчиненных, обеспечить им более удобные условия работы и т.п. В результате появляется опасность снижения и квалификации, и творческого потенциала всей команды. Соответственно, техническое руководство проектом начинает в большей степени подменяться организационным руководством, все более детальной проработкой должностных инструкций и все более формальным их исполнением. Тот, кто не умеет организовать работу, обречен бороться за дисциплину. И здесь возникает проблема несовместимости дисциплины и творчества. Чем строже дисциплина, тем менее творческой становится атмосфера в коллективе. Такое положение вещей может привести к тому, что наиболее одаренные кадры со временем покинут коллектив.

Модель итеративной и инкрементальной разработки

Альтернативой каскадной модели является модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью.

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение – инкремент – к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения.

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

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

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).

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

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

Рис. Возможный ход работ по итеративной модели

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

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

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

Спиральная модель

Развитием идеи итераций является спиральная модель жизненного цикла ПО, предложенная Барри Боэмом (Barry Boehm) в своей статье 1986 года. Она предлагает каждую итерацию начинать с выделения целей и планирования очередной итерации, определения основных альтернатив и ограничений при ее выполнении, их оценки, а также оценки возникающих рисков и определения способов избавления от них, а заканчивать итерацию оценкой результатов проведенных в ее рамках работ.

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

Спиральная модель основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

Рис. Изображение хода работ по спиральной модели согласно Боему

Рисунок изображает вариант классической спиральной модели Боэма, ориентированный на работы процесса разработки, соответствующие СТБ ИСО/МЭК 12207-2003.

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

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

1. Постановка задач (Objective setting) – определяются цели этой фазы, то есть витка, ограничения процесса, результаты, план управления, потенциальные риски и альтернативные стратегии, исходя из рисков.

2. Оценивание и сокращение рисков (Risk assessment and reduction) – для каждого найденного риска делается анализ, предпринимаются некоторые действия для сокращения рисков (например, риск, чьи требования не являются адекватными: изготавливается прототип).

3. Разработка и проверка достоверности (Development and validation) – выбирается модель разработки, исходящая из оцененных рисков (модель должна быть такой, чтобы помочь снизить риски). Например, если в пользовательском интерфейсе имеется самый большой риск, то тогда может помочь прототипирование.

4. Планирования (Planning) – проект рассматривается и делается решение о том, переходить ли на следующий виток, если решают продолжить, делается план для следующей фазы.

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

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

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

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

В квадранте 2 – оценка альтернативных вариантов, идентификация и разрешение рисков – выполняется оценка альтернативных вариантов, рассмотренных в предыдущем квадранте; оценка возможных вариантов разрешения рисков. Выполняется прототипирование как основа для работ следующего квадранта.

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

В квадранте 4 – планирование следующей фазы – выполняются действия, связанные с разработкой планов проекта, управления конфигурацией, тестирования, установки системы.

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

Боэм формулирует десять наиболее распространенных (по приоритетам) рисков:

1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. «Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. «Разрыв» в квалификации специалистов разных областей знаний.

Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.

На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача – как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла – определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:

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

Жизненный цикл программного обеспечения по методологии RAD состоит из четырех фаз:

• фаза определения требований и анализа
• фаза проектирования
• фаза реализации
• фаза внедрения.

Спиральная модель ориентирована на большие, дорогостоящие и сложные проекты. В условиях, когда бизнес цели таких проектов могут измениться, но требуется разработка стабильной архитектуры, удовлетворяющей высоким требованиям по нагрузке и устойчивости, имеет смысл применение Spiral Architecture Driven Development. Данная методология, включающая в себя лучшие идеи спиральной модели и некоторых других, позволяет существенно снизить архитектурные риски, что является немаловажным фактором успеха при разработке крупных систем.

Работа над проектом в соответствии со спиральной моделью начинается с определения заказчиком потребности в разработке системы или программного продукта (центр квадранта 1). Первая создаваемая версия системы основывается на предварительных требованиях заказчика. Затем начинается планирование следующего цикла, учитывающее требования и пожелания заказчика, сформулированные им по результатам работ соответствующего уровня 3-го квадранта. Каждая последующая версия более точно воплощает требования заказчика. Степень вносимых изменений от одной версии программы к следующей уменьшается с каждой новой версией. В результате получается конечная система (программный продукт).

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

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

Количество итераций модели выбирается в соответствии со сложностью проекта. Работы каждой итерации должны бать адаптированы под конкретный проект.

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

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

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

Рис. Спиральная модель жизненного цикла информационной системы.

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

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

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

При использовании спиральной модели при выполнении соответствующего ей проекта проявляются следующие ее преимущества:

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

Рассмотрим преимущества итерационного подхода более подробно:

• Итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика.
• При использовании спиральной модели отдельные элементы информационной системы интегрируются в единое целое постепенно. При итерационном подходе интеграция производится фактически непрерывно. Поскольку интеграция начинается с меньшего количества элементов, то возникает гораздо меньше проблем при ее проведении (по некоторым оценкам, при использовании каскадной модели разработки интеграция занимает до 40 % всех затрат в конце проекта).
• Уменьшение уровня рисков. Данное преимущество является следствием предыдущего, так как риски обнаруживаются именно во время интеграции. Поэтому уровень рисков максимален в начале разработки проекта. По мере продвижения разработки ожидаемый уровень рисков снижается. Данное утверждение справедливо при любой модели разработки, однако при использовании спиральной модели снижение уровня рисков происходит с наибольшей скоростью. Это связано с тем, что при итерационном подходе интеграция выполняется уже на первой итерации, и на начальных итерациях выявляются многие аспекты проекта, такие как пригодность используемых инструментальных средств и программного обеспечения, квалификация разработчиков и т.п.
• Итерационная разработка обеспечивает большую гибкость в управлении проектом, давая возможность внесения тактических изменений в разрабатываемое изделие. Например, можно сократить сроки разработки за счет снижения функциональности системы или использовать в качестве составных частей системы продукцию сторонних фирм вместо собственных разработок. Это может быть актуальным в условиях конкурентной борьбы, когда необходимо противостоять продвижению изделия, предлагаемого конкурентами.
• Итерационный подход упрощает повторное использование компонентов (реализует компонентный подход к программированию). Это обусловлено тем, что гораздо проще выявить (идентифицировать) общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Анализ проекта после проведения нескольких начальных итераций позволяет выявить общие многократно используемые компоненты, которые на последующих итерациях будут совершенствоваться.
• Спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно могут корректироваться критические параметры эффективности, что в случае каскадной модели доступно только перед внедрением системы.
• Итерационный подход дает возможность совершенствовать процесс разработки – анализ, проводимый в конце каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации.

Недостатки спиральной модели. При использовании спиральной модели применительно к неподходящему ей проекту, проявляются следующие ее недостатки:

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

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

Планирование работ обычно проводится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

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

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

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

ВВЕДЕНИЕ

ОБЩАЯ ЧАСТЬ

Цель разработки

· просмотреть фотоальбом;

· производить поиск по сайту;

СПЕЦИАЛЬНАЯ ЧАСТЬ

Постановка задачи

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

Web-сайт должен быть разработан на движке WordPress.

Web-сайт должен выполнять задачи:

· информирования по актуальным вопросам;

· простой навигации, доступный поиск информации на сайте;

· предоставления просмотра методических разработок и лекционных материалов;

· возможности скачивания лекций и лабораторных работ;

· предоставления доступа к просмотру изображений в фотоальбомах на сайте;

· возможности прохождения теста для всех пользователей на сайте.

· предоставления возможности предложить тему, используя обратную связь.

Web-сайт должен:

· иметь понятный и простой в использовании интерфейс;

· корректно работать в любом браузере;

· Быть адаптированным под мобильные устройства.

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

Требования к входным и выходным данным

Входные данные

· Информация, размещаемая на сайте;

· Текстовые документы, размещаемые на сайте в формате.pdf и.docx;

· Изображения, размещаемые на сайте (.jpg, .png);

· Запросы, вводимые пользователями сайта, для поиска информации;

· Данные Host для размещения сайта в интернете;

· Выбранные варианты ответов в тестировании;

· Сообщение, отправляемое на emailадминистратора пользователем.

Выходные данные :

· Ответы на запрос пользователя;

· Скаченные файлы с сайта;

· Результаты тестирования.

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

Состав технических средств необходимых для разработки данного программного продукта:

Процессор: Intel Celeron1.80 GHz;

Дисплей: любой;

Видеокарта: NVIDIAGeForceGT 630 илиRadeonHD 6750 1 GB.

Дисковое пространство: 500МЬ;

Жесткие диски: 2 Gb свободного места на диске;

Состав программных средств необходимых для разработки данного программного продукта:

Операционная система: Unix, Windows 7,8,10

Доступ к интернету

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

Браузеры: Google Chrome, Яндекс Браузер, Opera, Mozilla Firefox и др.

Описание алгоритма

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

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

При выборе пункта меню «Методические разработки» происходит переход на страницу где описывается какие материалы для изучения предоставляют данные разработки. Выбранный пункт меню разделен на 4 подпункта «Учебные пособия», «Открытые уроки», «Лабораторные работы» и «Лекционные материалы».

· Выбрав подпункт «Учебные пособия» будут предоставлены учебники, учебные пособия, по которым были разработаны темы программ по дисциплинам, конкретные уроки, лабораторные работы, тесты и другое.

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

· Подпункт «Лекционные материалы» предоставляет возможность изучения лекций по преподаваемым дисциплинам, а именно Информатика, Операционные системы и Базы данных.

· Подпункт «Лабораторные работы» позволяет скачать практические задания по дисциплинам.

Пункт меню «Обратная связь» имеет форму для связи с администратором, посредством отправки сообщения на email. Данный пункт позволяет предложить тему для публикации или сообщить об ошибках на web-сайте.

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

Пункт «Фотоальбом» позволяет просмотреть изображений, а именно фотографий преподавателя на мероприятиях, уроках, конкурсах, со студентами и т.д.

Структурная схема

Описание процесса отладки

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

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

Web-сайт разработан, используя возможности WordPress, что позволяет по меньшей мере избавить разработку от синтаксических ошибок, но не избавляет от логических.

Перечень ошибок

· Некорректная работа визуального редактора в админке web-сайта.

Решение: изменение настроек работа WordPress.

· Некорректный процесс просмотра изображений

Решение: проверка взаимодействий плагинов между собой, замена плагина галлереи на более совместимый с другими.

· Ошибки в результатах тестирования

Решение: изменение кода в блоке результатов тестирования.

· Некорректная кликабельность ссылок

Решение: изменение кода

ОРГАНИЗАЦИЯ ПРОИЗВОДСТВА

Инструкция пользователю

Для использования данного сайта, необходимо иметь доступ к Интернету.

Выбрать браузер;

В поисковой строке ввести адрес сайта minkata.ru;

Зайдя на сайт выбрать необходимый пункт меню:

· Методические разработки (данный раздел предназначен для изучения методики преподавания, и самостоятельного изучения предмета по средствам скачивания и выполнения лабораторных и практических заданий, изучения лекций и пособий, по которым ведется учебная программа)

o Лабораторные работы

o Лекционные материалы

§ Базы данных

§ Информатика

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

o Открытые уроки

§ Урок по Базам данным

§ Урок по Информатике

§ Урок по Операционным системам

· Обратная связь (данный раздел предназначен для связи с администратором, по средствам отправки сообщения)

· Тестирование (данный раздел предназначен для самостоятельного контроля знаний)

o Базы данных

o Информатика

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

· Фотогалерея (в данном разделе находятся фотографии, для просмотра)

ЭКОНОМИЧЕСКАЯ ЧАСТЬ

Расчет стоимости материалов

Материалы и покупные изделия рассчитывают по нормам расхода материалов методом прямого счета по формуле:

,

где q М j – норма расхода j-го материала на разработку ПП, шт; Ц М j – цена единицы j-го материала, р; Н ТР – норма транспортных расходов. Результаты вычислений представляют в таблице 2.

Таблица 2 - Затрат на материалы

ОХРАНА ТРУДА

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

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

При работе оператора в положении ”сидя” используются следующие параметры рабочего пространства:

1. ширина не менее - 700 мм;

2. глубина не менее - 400 мм;

3. высота рабочей поверхности стола над полом - 750 мм.

Под рабочей поверхностью стола предусматривается место для ног:

1. высота не менее - 600 мм;

2. ширина не менее - 500 мм;

3. глубина не менее - 400 мм.

При необходимости обзора рабочего места высота последнего должна превышать - 1200 мм. Кресло оператора должно обеспечивать надежную опору для тела. Высота сиденья примерно - 500 мм.

Проходы должны иметь ширину, позволяющую людям разминуться, примерно - 800 мм.

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

Профзаболеваний

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

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

1. Срочных извещений о случаях профзаболеваний и травматизма;

2. Регистрационных карт.

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

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

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

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

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

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

Требования к помещению машинного зала

1. Помещения с ВДТ и ПЭВМ должны иметь естественное и искусственное освещение.

2. Естественное освещение должно осуществляться через световые излучения, ориентированные преимущественно на север и северо-восток и обеспечивать коэффициент естественной освещенности (КЕО) не ниже 1.5%.

3. Расположение рабочих мест с ВДТ и ПЭВМ для взрослых пользователей в подвальных помещениях не допускается.

4. В случаях производственной необходимости, эксплуатация ВДТ и ПЭВМ в помещениях без естественного освещения может проводиться только по согласованию с органами и учреждениями Государственного санитарно-эпидемиологического надзора.

5. Площадь на одно рабочее место с ВДТ или ПЭВМ для взрослых пользователей должна составлять не менее 6.0 кв.м. и объем не менее 20.0 куб.м.

6. При входе в ВЦ с ВДТ и ПЭВМ следует предусмотреть встроенные или пристенные шкафы (полки) для хранения одежды, зонтов и сумок персонала.

7. Производственные помещения, в которых для работы используются преимущественно ВДТ и ПЭВМ (диспетчерские, операторские, расчетные и др.) не должны граничить с помещениями, в которых уровни шума и вибрации превышают нормируемые значения (механические цеха, мастерские, гимнастические залы и т.п.).

8. Звукоизоляция ограждающих конструкций помещений с ВДТ и ПЭВМ должна отвечать гигиеническим требованиям и обеспечивать нормируемые параметры шума согласно требованиям раздела 6 настоящих Санитарных правил:

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

Кабинеты с вычислительной техникой должны иметь смежное помещение – лаборантскую – площадью не менее 18.0 кв.м. с двумя входами: на лестничную площадку или в рекреацию.

1. Для внутренней отделки интерьера помещений с ВДТ и должны использоваться диффузно - отражающие материалы с коэффициентом отражения для потолка – 0.7 – 0.8; для стен – 0.5 – 0.6; для 0.3 – 0.5.

2. Полимерные материалы, используемые для внутренней отделки интерьера помещений с ВДТ и ПЭВМ, должны быть разрешены для применения органами и учреждениями Государственного санитарно-эпидемиологического надзора.

3. Для отделки внутреннего интерьера помещений с ВДТ и ПЭВМ применять полимерные материалы (древесностружечные плиты, пенистый бумажный пластик, синтетические ковровые покрытия) отделяющие в воздух вредные химические вещества.

4. Поверхность пола в помещениях эксплуатации ВДТ и ПЭВМ должна быть ровной, без выбоин, нескользкой, для удобной очистки и уборки, обладать антистатическими свойствами.

СПИСОК ЛИТЕРАТУРЫ

1. ГОСТ Р ИСО/МЭК 12190-2000 «Информационная технология. Пакеты программ. Требование к качеству».

2. Владимир Дронов, HTML 5, CSS 3 и Web 2.0., разработка современныхWeb-сайтов.

3. Джон Дакетт Основы веб-программирования с использованием HTML, XHTML и CSS.

4. Йен Ллойд, создай свой веб-сайт с помощью HTML и CSS, Питер 2013 г.- 330 c.

5. Стив Суэринг, Тим Конверс, Джойс Парк. PHP и MySQL. Библия программиста, 2-е издание = PHP 6 - М.: «Диалектика», 2011 г.

6. Beginning Web Programming with HTML, XHTML, and CSS,Эксмо,2011г. С 200-219.

7. SEO-подсказки [сайт] URL:https://devaka.ru/articles/32-most-important-seo-tips (дата обращения 2.06.2017)

8. Оптимизация тега title [сайт] URL: https://devaka.ru/articles/title-tag-optimization (дата обращения 2.06.2017)

9. Sitemap [сайт] URL: https://yandex.ru/support/webmaster/indexingoptions/sitemap.html?lang=en?lang=en (дата обращения 27.05.2017)

10. Использование robots.txt [сайт] URL: https://yandex.ru/support/webmaster/controlling-robot/robots-txt.xml (дата обращения 29.05.2017)

ВВЕДЕНИЕ

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

Активное развитие Интернета привело к возможности создания web-сайтов для предоставления различного рода информации и услуг.

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

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

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

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

Создание электронного web-сайта способствует решению такой проблемы, как постоянное обновление информационного материала.

Так же электронные публикации имеют экономические преимущества: время создания - меньшее, обновление – быстрее.

Кроме того, благодаря используемым современным технологиям доступ к web-сайту может осуществляться с любого мобильного устройства с доступом в интернет.

Таким образом, тема дипломного проекта «Разработка web-сайтапреподавателя» является актуальной, так как данная разработка является огромным преимуществом для преподавателя. Web-сайт преподавателя объединяет вокруг себя всех заинтересованных в образовательном процессе лиц. На web-сайтенаходится информация, и каждый участник образовательного процесса может использовать ее в своих целях, направляя ее для решения своих задач. При этом аудитория сайта не ограничена группой студентов и коллегами, адрес сайта доступен онлайн каждому, вне зависимости от места нахождения его посетителя.

ОБЩАЯ ЧАСТЬ

Цель разработки

Целью проекта является разработка и реализация web-сайта преподавателя.

Web-сайт преподавателя - это пространство для внеклассного взаимодействия со студентами, учениками и коллегами. На сайте размещается информация для домашнего изучения, задания, что позволяет изучать предмет удаленно.

Данный электронный web-сайт позволяет:

· ознакомиться с электронным портфолио преподавателя;

· ознакомиться со статьями на сайте;

· ознакомиться со списком лекций учебных программам по дисциплинам;

· просмотреть лекционные материалы по дисциплинам, а также скачать;

· скачать методические указания к лабораторным работам;

· просмотреть учебные пособия;

· изучить описание открытых уроков;

· заниматься удаленно дисциплинами, которые ведет преподаватель;

· просмотреть фотоальбом;

· производить поиск по сайту;

· пройти тестирование для подготовки к письменному тесту;

· связаться с администратором, с помощью обратной связи;

Анализ использования разработки

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

Сайт содержит полезные статьи по тем или иным вопросам, а также тематические тесты.

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

Личный web-сайта является необходимым элементом имиджа специалиста, современные тенденции таковы, что web-сайт иметь просто необходимо.

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

Решение многих проблем возможно только с использованием электронных web ресурсов.

Этот web-сайт являться визитной карточкой преподавателя.

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

Текст разделен на три части. В первой я расскажу о пяти важных шагах по формализации таких разработок. Эта формализация поможет не только закрепить за компанией права на эти разработки, но и сократить юридические риски, связанные с «перехватом» прав на ПО бывшими сотрудниками, а также экономические риски неправильного учёта ПО как актива. Из второй части станет понятно, какими правами на программный продукт, созданный для компании, обладают непосредственно программисты. И в третьей части я поясню, почему так важно правильно оформлять документы и с какими рисками может столкнуться компания-разработчик.

Опыт последних трёх лет показывает, как изменилось отношение компаний ко внутренним разработкам. Даже простой, созданный «на коленке» софт, воспринимается как некая сущность, имеющая свою ценность. В некоторых компаниях ценность внутренних разработок увеличилась еще и под влиянием политики импортозамещения: для них написанное собственной командой программистов ПО – альтернатива зарубежным продуктам, часто уже достаточно близкая к ним по функциональности. Как бы то ни было, организации стремятся формализовать внутренние разработки – мы видим это по количеству соответствующих обращений в наш департамент.

Пять шагов к формализации внутренних разработок

Под формализацией мы имеем в виду прежде всего надлежащее документальное оформление созданного результата интеллектуальной деятельности. Нужно чётко понимать, что в соответствии с действующим законодательством авторское право на программу для ЭВМ возникает с момента ее создания в силу самого факта её создания. Справедливо, что если сотрудник, работающий в организации по трудовому договору, занимается разработкой программного продукта для компании, то данный программный продукт должен принадлежать компании, поскольку это относится к его обязанностям, и именно за это он получает заработную плату и иные виды компенсации (премии и другие выплаты компенсационного характера). Однако крайне важно понимать, что в авторском праве разграничены две вещи - авторское право (нематериальное) и т.н. исключительное право (материальное право, право распоряжаться объектом авторского права). И если авторское право возникает в силу создания и принадлежит физическим лицам, создавшим продукт, то «материальное» право подлежит тонкой документальной настройке. Механизм по защите внутренних разработок включается в пять шагов.

Шаг первый. В рамках трудового договора формализуйте функции сотрудников и подчеркните, что в обязанности сотрудника входит разработка служебных произведений, программ для ЭВМ, баз данных и т.д. Также проверьте тот трудовой договор, который уже подписан сторонами – это может быть типовой документ, в котором пункты о разработке служебных произведений могут быть не указаны. В этом случае заключите с разработчиком дополнительное соглашение, в котором следует сделать акцент на функциональных задачах специалиста, а также прописать принадлежность возникающих исключительных прав компании нанимателю. Также в договоре обязательно должен быть указан порядок уплаты авторского вознаграждения за созданные программы ЭВМ. Авторское вознаграждение может быть включено в заработную плату, премирование, либо иные виды материального поощрения.

Шаг второй. Всегда составляйте служебное задание на разработку программы для ЭВМ. Строго говоря, с него должна начинаться любая разработка. Служебное задание готовится в свободной форме. Оно содержит цели конкретного проекта, разработку которого планируется начать, а также некое краткое описание функциональности либо задач, которые создаваемое приложение будет решать. Совсем идеально, если служебные задания будут готовиться под конкретные модули разрабатываемого решения и содержать в себе полное и чёткое техническое задание на каждый модуль. Если такой документ отсутствует, рекомендуется его разработать для текущих проектов, либо составить новый на развитие ранее разработанного продукта, в котором следует дополнительно прописать принадлежность исключительных прав компании. Своим заказчикам мы упрощаем жизнь и предлагаем им готовые шаблоны, но вы можете написать и в свободной форме.

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

Шаг третий. Сделайте так, чтобы разработчик (если он один) или тим-лидер (если у вас отдел разработки) подготовили вам докладную записку о выполнении служебного задания. В ней содержится информация о функциональности разработанного модуля, либо о функциональности продукта в целом. Также в обращении должен быть тезис о том, что программный продукт к эксплуатации готов. Фактически докладная записка фиксирует документально факт выполнения служебного задания и представляет собой аналог акта приёма-передачи.

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

Шаг пятый. После приказа по организации о том, что продукт введен в эксплуатацию, следует подготовить распоряжение о постановке ПО на бухгалтерский баланс, определить его начальную стоимость, полезный срок использования и пр. Как это сделать? Необходимо создать экспертный совет, который в рамках обсуждения функциональности ПО выдаст рекомендации и оценки, связанные со стоимостью программного обеспечения. Рекомендации экспертов лучше формулировать в виде протокола, который затем должен быть передан в бухгалтерию. Начальная стоимость определяется самостоятельно компанией-разработчиком и чаще всего включает в себя непосредственно прямые затраты. Не стоит завышать стоимость ПО, т.к. после постановки на бухгалтерский учет компания должна будет платить налоги, которые будут зависеть от начальной стоимости. Подробные правила формирования в бухгалтерском учете и бухгалтерской отчетности информации о нематериальных активах организаций устанавливает ПБУ 14/2007 (Положение по бухгалтерскому учету «Учет нематериальных активов», приложение к приказу Минфина РФ от 27.12.2007 №153н).

Итак, чтобы внутренняя разработка была полностью формализована, она должна быть защищена следующими документами:

1. Служебное задание
2. Докладная записка о выполнении задания
3. Акт приемки программного продукта к эксплуатации в компании
4. Распоряжение о постановке программного обеспечения на бухгалтерский баланс

Толково и правильно проведенный процесс формализации превращает внутреннюю разработку в программный актив. Говоря юридическим и бухгалтерским языком, таким образом получается нематериальный актив, повышающий капитализацию компании. Несмотря на нематериальный статус, у программного актива много общего с обычными активами, но, прежде всего, – это его стоимость. Компания может зарабатывать, например, передавая неисключительные права на программный продукт другим компаниям/пользователям или использовать его в организации, оптимизируя расходы на задачи, которые ранее не были автоматизированы, сокращая трудозатраты на их выполнение. Если данная разработка является дорогостоящим продуктом, она существенно увеличит капитализацию компании.

На Хабре неоднократно поднимался вопрос о важности регистрации приложений в Роспатенте. На мой взгляд, это весьма желательно, поскольку свидетельство Роспатента описывает не программный продукт как таковой, а совокупность его характеристик, определяющие его ценность для пользователя. Вложив деньги и время в защиту приложения, вы можете в какой-то степени обезопасить свою разработку от повторения. Важно: Роспатент при регистрации производит формальную экспертизу поступившей заявки, но не производит детальную экспертизу программного продукта. Поэтому правильное составление заявки на интеллектуальную защиту программного продукта – действительно другая история. При этом отмечу, что в соответствии с действующим законодательством России государственная регистрация программы для ЭВМ не является обязательной. То есть нельзя сказать, что если вы не зарегистрируете программу для ЭВМ в Роспатенте, то не сможете защитить свои права на неё, т.к., повторюсь, авторское право возникает в силу создания продукта, а не в силу его регистрации где бы то ни было.

На что может рассчитывать рядовой разработчик?

Это очень частый вопрос со стороны программистов: «Какую выгоду я, как создатель, получаю от формализации написанного мною приложения?» Если работодатель, для которого разработчик создал приложение, юридически правильно это приложение формализовал, программисту остается так называемое личное неимущественное право автора. Никаких денежных бенефитов оно с собой, скорее всего, не несет, поскольку создатель уже получил вознаграждение за выполненную работу, и никакими имущественными правами на написанный им софт он уже не обладает. Неимущественные права позволяют потешить собственное эго и добавить проект в портфолио. Например, автор разработки вправе сам предложить название ПО, разрешать указывать свое имя в контексте приложения. Но имейте в виду, что право указывать имя автора, либо его не указывать, тоже регулируется вышеупомянутым трудовым договором. Отмечу ещё, что неимущественные права распространяются в том числе на несколько человек, то есть у продукта может быть несколько авторов.

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

Почему важна бумажная работа?

Мне и моим коллегам нередко приходится сталкиваться с ситуацией, когда собственник или топ-менеджеры компаний-заказчиков даже не знают, какое ПО и для каких целей создала команда разработки. Информацию о таком софте мы получаем на самом первом этапе процедуры Software Asset Management, когда специальные средства сканируют серверы и ПК в компании-заказчике. Обнаружив такие «артефакты», мы вместе с ответственными сотрудниками поднимаем необходимую документацию и по крайней мере понимаем, что перед нами внутренняя разработка.

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

Если остались вопросы – пишите в комментариях, я постараюсь ответить.