Я работаю в IT последние 15 лет, хотя программированием начал заниматься значительно раньше. Основное направление моей деятельности как системного архитектора была организация разработки программ, разработка концепций и верхнеуровневой архитектуры и контроль выполнения концепции на протяжении проекта. Кроме управления разработкой ПО и создания архитектуры, я время от времени занимаюсь решением сложных технических проблем и написанием некоторых критически важных участков кода, где необходимо не только знание самого языка и среды разработки, но и их внутренней организации, иногда преподносящей неприятные сюрпризы.
Проекты, над которыми я работаю, чаще всего связаны с разработкой заказного или инвестиционного программного обеспечения. Также мне приходилось работать с встроенным ПО и программами, ориентированными на выпуск «хитов» (что, с лёгкой руки Джоэля Спольски, я называю далее игровым ПО, хотя на самом деле некоторые игровые проекты ближе к инвестиционным).
Заказное программное обеспечение может быть предназначено для внутреннего или внешнего заказчика. Эксклюзивные права на разработанную систему получает заказчик, и работа над развитием системы в дальнейшем может быть передана другому исполнителю.
В отличие от заказного ПО, работа над инвестиционным программным обеспечением ведётся самим исполнителем на деньги внутреннего или внешнего инвестора. Как правило, права на код системы остаётся у исполнителя, что стимулирует непрерывную работу по улучшению своего продукта и последовательный выпуск версий с более развитой функциональностью.
Встроенное программное обеспечение поставляется вместе с аппаратной частью и, грубо говоря, не подлежит сопровождению, поскольку отзыв партии устройств производителем – дело очень затратное и потому исключительное.
Разработка игровых хитов также практически не содержит фазы сопровождения. Кроме того, пользователи игровых программ, даже столкнувшись с ошибкой в игре, очень редко загружают обновлённую версию. Поэтому разработка игр, как правило, имеет свою экономику и свой процесс разработки.
Нашими заказчиками являются органы власти, крупные государственные и коммерческие организации и, конечно, мы сами. Поэтому в смысле заказного ПО в нашем процессе часто присутствует некоторая разница между процессами разработки продуктов для внутреннего и для внешнего заказчиков. Некоторые нюансы я укажу в этой статье. Уровень формализации отношений с заказчиком у нас варьируется от проекта к проекту очень широко. В целом, чем больше бюджет проекта, тем выше формальность. Государственный заказчик или крупные коммерческие предприятия (особенно с государственным участием) обычно имеют законодательные ограничения на формирование, размещение заказа и приёмку результатов работ. Ещё одним ограничением крупных организаций является тот факт, что их персонал, являющийся источником требований и основным пользователем наших систем, имеет очень ограниченную доступность для исполнителей, хотя бы вследствие своей занятости. Однако для небольших организаций уровень формализации падает и иногда уходит в противоположную крайность, где возникает недостаточный уровень ответственности заказчика в рамках проекта.
Другая сторона наших заказных проектов – высокие требования к функциональности. Это и высокая нагрузка на все системы, и большая географическая распределённость, и высокие требования к точности вычислений при очень ограниченных временных рамках. Часто в наших проектах появляются элементы исследовательской работы и творческого поиска, направленного на решение нетривиальных проектных задач. Иногда нам приходится комбинировать в рамках одного процесса разработки разные методологии, например, вставляя в общий процесс, близкий к RUP, один или несколько этапов почти чистого scrum, порождая что-то вроде проекта в проекте. Это позволяет нам сохранять невысокий уровень вовлеченности пользователей, связанный с природой проекта, с гибкостью разработки в условиях высокой неопределённости требований. В этом плане для меня важен именно подготовительный этап, во время которого можно выбрать необходимую методологию и выстроить оптимальный процесс разработки. Один из примеров применения гибкой методологии я описал в статье «Применение agile при разработке проекта для государственного заказчика» .
В качестве примера работы над инвестиционным проектом я могу привести разработку комплексной системы безопасности, которую мы создавали как «коробочный» продукт. Под моим руководством было выпущено последовательно четыре версии этой системы, пользователями которой стали самые разные коммерческие и государственные организации, включая мэрию Москвы, АФК «Система», банки, бизнес-центры и, конечно, наш собственный офис. Первая версия была не очень успешной, но у нас была стратегия развития, которая позволила нам успешно захватить рынок и пережить сложные времена кризиса. Опыт работы над этим и ещё несколькими инвестиционными проектами тоже был учтён при формировании используемого мной процесса разработки.
Наш процесс представляет собой последовательность определённых этапов. Приведённая мной классификация ПО сделана только, чтобы показать возможную разницу в организации разработки различных программных средств. Делая обзор процесса разработки, я остановлюсь только на различиях именно самого процесса касаемо разных видов ПО. Однако надо помнить, что различия между процессами разработки разных видов ПО гораздо глубже, поэтому при планировании каждого этапа необходимо учитывать эти нюансы.
Важно понимать, что переход процесса от одного этапа к другому не имеет чёткой границы. Как правило, работы следующего этапа начинаются по мере выполнения 80-90% работ по предыдущему этапу. Особенно это касается разработки требований, когда в ряде случаев снятие неопределённости происходит лишь к концу проекта. Безусловно, наличие такой неопределённости в проекте является существенным риском и должно находиться под постоянным контролем.
Процесс разработки заказного ПО
Обзор процесса разработки начнём с наиболее общего случая – разработки заказного программного обеспечения. Схема процесса приведена на рисунке 1.Рисунок 1. Процесс разработки заказного программного обеспечения.
Работа над проектом начинается с подготовительного этапа. Цель этапа состоит в том, чтобы на основе предложений заказчика создать некоторую концепцию будущей системы и, отталкиваясь от этой концепции, провести оценку востребованности и реализуемости проекта. Если решение о привлечении исполнителя принимается заказчиком на конкурсной основе, то предварительный этап фактически является стадией подготовки потенциального исполнителя к конкурсу, включая формирование необходимой документации.
Не нужно тратить время и ресурсы на проект, чья концепция признаётся невостребованной или нереализуемой. Такой проект должен быть завершён. В ряде случаев требуется некоторая итеративная работа с заказчиком по коррекции концепции проекта, пока либо не будет достигнут приемлемый баланс требований заказчика и затрат исполнителя, либо не будет принято решение о сворачивании работ.
Проект, концепция которого выглядит приемлемой для реализации, выходит на этап разработки требований. На этом этапе исполнитель должен сформировать перечень всех явных и скрытых потребностей заказчика. Часто оказывается, что заказчик либо не определился со своими потребностями, либо его потребности вступают в противоречие между собой, с возможностями заказчика или с возможностями исполнителя. Целями этапа являются выявление всех скрытых потребностей, решение конфликтов требований, формирование целостного технического решения и анализ реализуемости подготовленного решения.
Иногда уточнение требований приводит к пересмотру концепции проекта. Если после уточнения всех требований не удаётся найти приемлемого технического решения, проект приходится сворачивать либо откладывать на некоторое время в ожидании более приемлемых обстоятельств.
Если техническое решение найдено, исполнитель приступает к разработке архитектуры будущей системы. Цель этапа – определение верхнеуровневой логической и физической архитектуры, полностью покрывающей все требования заказчика. При разработке архитектуры проводится рецензирование и уточнение концепции, требований и предварительного технического решения, что даёт возможность предупредить наиболее опасные риски.
После завершения проектирования архитектуры необходимо снова провести ревизию основных параметров проекта и решить, в состоянии ли исполнитель завершить проект. Полезно на стадии разработки архитектуры отказаться от излишних и слишком громоздких функций. Оптимизация архитектурного решения часто помогает вписаться в приемлемые параметры проекта. В иных случаях требуется более радикальное сокращение функционала разрабатываемой системы. Однако даже остановка проекта на этой стадии, если она происходит по веским причинам, должна восприниматься как победа: продолжение работ в таком случае может привести только к ещё большим потерям.
Если баланс был найден, и удалось создать приемлемую архитектуру системы, исполнитель может переходить к реализации и поставке системы. Реализация может проходить в один или несколько этапов. Для небольших проектов одноэтапная поставка всего функционала системы может быть вполне приемлемой. Однако, чем больше проект, тем выше зависимости подсистем внутри создаваемой системы. В этих условиях следует делить реализацию на несколько этапов так, чтобы в конце каждого этапа команда разработчиков имела готовый к поставке продукт. При этом самый важный, фундаментальный функционал должен разрабатываться на ранних этапах, а надстройки, работающие поверх этих основных компонентов, следует реализовывать позднее. В таком случае наиболее опасные для системы ошибки будут исправлены на первых этапах, и риск того, что прикладная функциональность системы будет основана на нестабильной основе, будет значительно снижен.
После поставки полностью завершённой системы проект заказного ПО обычно переходит к этапу опытной эксплуатации. Цель этого этапа заключается в проверке качества работы разработанной системы в реальных условиях эксплуатации. Как правило, на этом этапе исполнитель совместно с заказчиком проводит измерение количественных метрик, позволяющих определить качество созданной системы. В первую очередь проверяются функциональные характеристики качества, затем – нефункциональные. При наличии несоответствий исполнитель корректирует код системы.
Полностью отлаженная и настроенная система вводится в промышленную эксплуатацию. Как правило, исполнитель должен сопровождать систему, по крайней мере, в течение срока гарантии. Выявляемые несоответствия должны исправляться. Пользователи и обслуживающий персонал заказчика должны получат оперативную консультативную поддержку.
Наконец, приходит момент, когда система перестаёт устраивать заказчика по какой-либо причине. Наступает этап вывода системы из эксплуатации. Впрочем, для заказного ПО этот этап не всегда актуален, поскольку заказчик может воспользоваться своими эксклюзивными правами на систему и отстранить исполнителя от дальнейших работ по сопровождению и развитию системы ещё до того, как она потеряет актуальность.
Любой проект в конечном счёте приходит к своему завершению. Этап прекращения проекта имеет целью анализ результатов, внесение изменений в процесс разработки на основе полученного опыта и пополнение базы знаний разработчиков новыми эффективными решениями и предостережениями, а также новыми готовыми компонентами, которые можно будет использовать в следующих проектах.
Осталось отметить ещё два этапа процесса разработки. Бывает, что обстоятельства не позволяют продолжать реализацию проекта, но результаты проделанной работы показывают, что у проекта может быть будущее. Закрывать такой проект преждевременно. Поэтому вместо полной остановки работ исполнитель может временно приостановить деятельность по проекту, зафиксировав достигнутые результаты. Как только обстоятельства позволят, проект можно буде возобновить, расконсервировав инфраструктуру, вернув в проект разработчиков и восстановив состояние проекта. Важно, однако, возобновлять работу с того этапа, на котором проект был прерван, повторно проведя ревизию достигнутых результатов.
Процесс разработки инвестиционного ПО
Процесс разработки инвестиционного ПО отличается тем, что параллельно может идти работа сразу над несколькими версиями продукта: пока первая версия сопровождается, вторая уже реализуется, а для третьей формулируются требования. Процесс показан на рисунке 2.
Рисунок 2. Процесс разработки инвестиционного программного обеспечения.
Как нетрудно заметить, при разработке инвестиционного ПО имеют место те же этапы, которые были рассмотрены выше для процесса разработки заказного программного обеспечения. Но отличие состоит в том, что этапы относятся не ко всему продукту, а к отдельной версии продукта. Исключение составляет этап прекращения проекта: проект не может завершиться, пока идёт работа хотя бы над одной версией продукта.
Обратите внимание на момент начала работ над следующей версией продукта. Этот момент настаёт, как только пройден этап создания архитектуры текущей разрабатываемой версии. До этого на этапах формирования требований и создания архитектуры, как правило, идёт обсуждение, какие функции следует реализовать в текущей версии, а какие перенести на будущее. И только тогда, когда требования к текущей версии сформулированы, рецензированы и подтверждены архитектурой системы, имеет смысл думать о следующей версии.
Кроме того, после разработки архитектуры, как правило, у аналитиков и архитекторов проекта появляется некоторая свобода действий, поскольку на этапах поставки основная нагрузка ложится на программистов. Эту свободу можно использовать для проработки концепции и требований для следующей версии.
В принципе, можно перенести начало работ над следующей версией на более поздний срок. Например, вполне допустимо сначала ввести текущую версию в опытную или даже промышленную эксплуатацию, и только после этого начать работу над следующей версией. Но нужно помнить, что такое решение неприменимо в случае высокой конкуренции: вас просто опередят и выдавят с рынка. Решение нужно принимать, исходя из всего комплекса обстоятельств, влияющих на ваш бизнес.
Говоря о процессе разработки инвестиционного ПО, нужно понимать, что работа над несколькими версиями имеет ряд явных и скрытых взаимозависимостей между параллельными ветками процесса.
Во-первых, исправления несоответствий, выявленных в ранней версии, должны вноситься и в версию, где они были обнаружены, и во все более поздние версии, включая разрабатываемые. Это касается не только кода программы, но и всех остальных артефактов проекта: технической и пользовательской документации, справочной системы, оценок и планов работ и т.п. Причём исправления должны вноситься немедленно, поскольку уменьшить стоимость исправлений вам не удастся, но, если не внести исправления сразу, их стоимость на более поздних стадиях может увеличиться в десятки и даже сотни раз.
Во-вторых, для параллельной работы над несколькими версиями нужна особая инфраструктура проекта, включая организацию контроля версий кода и документации, контроля заданий и несоответствий, утилит автоматической сборки и тестирования и т.п. Нельзя допустить, чтобы работа над одной версией продукта блокировала выполнение задач по другим версиям только из-за того, что инфраструктура проекта не позволяет запустить два процесса сборки одновременно для разных версий продукта.
Особое внимание нужно уделить стендам, на которых проводится тестирование: на них должны быть развёрнуты все версии продукта, которые были выпущены ранее (по меньшей мере, те версии, которые сопровождаются), и все версии, разработка которых ведётся в настоящий момент.
В-третьих, в работе над несколькими версиями могут быть одновременно задействованы одни и те же участники. Имеется большой риск, что ключевой сотрудник может погрязнуть в работе над одной версией программы и допустить существенное превышение сроков по задачам, связанным с другой версией.
В-четвёртых, имеет место обратная ситуация, когда персонал, работающий над одной версией, ничего не знает о том, какие решения принимаются в рамках работ над другой версией. Частично проблема снимается, если исправления всей документации и кода будут немедленно распространяться на все более поздние версии, о чём я говорил выше. Но одними исправлениями дело не должно ограничиваться. Нужно, чтобы команда, работающая над одной версией, понимала, почему были приняты те или иные решения при работе над другой версией. Для этого нужна база знаний для разработчиков – специальная информационная система, в которой должны описываться все проблемы, с которыми столкнулись разработчики при работе над той или иной версией продукта, и способы решения этих проблем. База знаний должна рассылать всем участникам проекта уведомления о поступлении новых записей. Нельзя пускать на самотёк взаимодействие двух команд, работающих над разными версиями одного продукта.
Процесс разработки встроенного ПО
Как уже отмечалось выше, встроенное ПО отличается от заказного тем, что его крайне сложно сопровождать.Допустим, вы выпускаете программы для холодильников. После того, как ПО поставлено производителю, десятки тысяч устройств начинают расходиться по всему миру, и вы понятия не имеете, где они окажутся. И если один из холодильников выйдет из строя по вине вашего софта, то проще заплатить неустойку, чем возвращать холодильник на завод и проводить диагностику. Конечно, можно подготовить инженеров для дилерских центров, которые смогут провести диагностику на месте и заменить прошивку вашей системы, но это всё равно очень дорого.
Таким образом, при разработке встроенного ПО возникает сразу несколько важных ограничений.
Во-первых, поставка выполняется в рамках только одного этапа: никто не будет встраивать в устройства наполовину работающую программу.
Во-вторых, при поставке вы должны уделить особое внимание качеству программы, поскольку с момента внедрения её внутрь железного ящика менять её будет очень сложно. Особое внимание нужно уделить этапу опытной эксплуатации, когда программа внедряется в ограниченную партию устройств, и эти устройства проходят комплексные испытания в различных режимах эксплуатации. Вы должны собрать максимум информации о динамике поведения вашей системы, проанализировать эту информацию и доработать ПО.
В-третьих, когда устройство с вашим ПО ушло в серию, вы имеете очень мало возможностей для исправления ошибок. По факту, такие исправления возможны только в случае брака ПО, приводящего к неработоспособности всей партии устройств, из-за чего производитель будет вынужден отозвать эту партию, а вы получите большое чёрное пятно на свою репутацию.
Наконец, в-четвёртых, этапа вывода из эксплуатации у встроенного ПО нет. Программу просто выбрасывают вместе с устройством. Поэтому, как только для партии устройств, в которых работает ваше ПО, истекает гарантийный срок, можно переходить к закрытию проекта.
Процесс разработки встроенного ПО показан на рисунке 3.
Рисунок 3. Процесс разработки встроенного программного обеспечения.
Процесс разработки игр
Игровое программное обеспечение было выделено мной по причине специфики их производства и эксплуатации. Бизнес игрового ПО основан на выпуске хитов. Один успешный хит оплачивает расходы на создание нескольких игр, которые остаются незамеченными пользователями. Поэтому процесс разработки одной игры взаимосвязан с процессами разработки других игр.Ещё одним фактором, выделяющим производство игр, является тот факт, что игра интересна пользователю либо пока он не прошёл последний уровень, либо пока у него не произошла фатальная ошибка. Это значит, что вторую версию игры он не будет покупать или даже бесплатно загружать только ради исправлений нескольких ошибок.
Указанные факторы сказываются на процессе разработки игрового ПО. Процесс представлен на рисунке 4.
Рисунок 4. Процесс разработки игрового программного обеспечения.
Нужно отметить следующие особенности процесса разработки игрового ПО.
Прежде всего, при производстве игр крайне важно качество концепции. Если концепция игры не позволяет создать хит, то дальнейшая работа бессмысленна. Ситуация, когда большинство проектов заканчиваются на подготовительном этапе, для разработки игрового ПО типична.
При разработке требований и архитектуры для игрового ПО часто повторно используются наработки, полученные при работе над предыдущими проектами. В этом плане также дополнительный вес получает этап прекращения проекта, когда все полезные наработки должны быть зафиксированы в базе знаний разработчиков.
Поставка игрового программного обеспечения происходит в рамках одного единственного этапа. Даже если сначала создаётся некое ядро, «движок» игровой системы, его работу невозможно проверить без реализации всего функционала системы.
Для игрового ПО нет этапов опытной эксплуатации и вывода из эксплуатации. Игры сразу поступают в продажу, а после использования просто удаляются пользователем по мере утраты интереса к ним.
Заключение
В рамках статьи я попытался сделать обзор «верхнего уровня» процесса разработки прикладного программного обеспечения. Каждый этап процесса, безусловно, нуждается в отдельном обсуждении с обязательным учётом особенностей разрабатываемых программных средств.Отмечу, что рассматриваемая здесь схема процесса является результатом обобщения моего личного опыта разработки различных программных средств. Как любое обобщение, моя схема является абстракцией. И, как любая абстракция, у неё есть свои границы применимости. Нельзя бездумно применять эту схему к конкретному проекту. Важно понимать, что каждый проект имеет свои нюансы, влияющие на организацию процесса разработки. И поэтому для каждого проекта приведённую здесь схему нужно адаптировать, а в ряде случаев потребуется разработать принципиально другой подход.
ВВЕДЕНИЕ
ОБЩАЯ ЧАСТЬ
Цель разработки
· просмотреть фотоальбом;
· производить поиск по сайту;
СПЕЦИАЛЬНАЯ ЧАСТЬ
Постановка задачи
Разработать 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-сайт являться визитной карточкой преподавателя.
Эта методология проектирования соединяет в себе объектную декомпозицию, приемы представления физической, логической, а также динамической и статической моделей системы.
Типовой проект включает в себя следующие этапы разработки программного обеспечения :
- анализ требований к проекту;
- проектирование;
- реализация;
- тестирование продукта;
- внедрение и поддержка.
Анализ требований к проекту
На этом этапе формулируются цели и задачи проекта, выделяются базовые сущности и взаимосвязи между ними. То есть, создается основа для дальнейшего проектирования системы.
В рамках данного этапа не только фиксируются требования заказчика, но и проводится их формирование - клиентам подбирается оптимальное решение их проблем, определяется необходимая степень автоматизации, выявляются наиболее актуальные для автоматизации бизнес-процессы.
При анализе требований определяются сроки и стоимость разработки ПО, формируется и подписывается ТЗ на разработку программного обеспечения.
Проектирование
На основе предыдущего этапа проводится проектирование системы. Эта методология проектирования соединяет в себе объектную декомпозицию, приемы представления физической, логической, а также динамической и статической моделей системы.
Во время проектирования разрабатываются проектные решения по выбору платформы, где будет функционировать система языка или языков реализации, назначаются требования к пользовательскому интерфейсу, определяется наиболее подходящая СУБД. Разрабатывается функциональная спецификация ПО: выбирается архитектура системы, оговариваются требования к аппаратному обеспечению, определяется набор орг. мероприятий, которые необходимы для внедрения ПО, а также перечень документов, регламентирующих его использование.
Реализация
Данный этап разработки программного обеспечения организован в соответствии с моделями эволюционного типа жизненного цикла ПО. При разработке применяются экспериментирование и анализ, строятся прототипы, как целой системы, так и ее частей. Прототипы дают возможность глубже вникнуть в проблему и принять все необходимые проектные решения еще на ранних этапах проектирования. Такие решения могут затрагивать разные части системы: внутреннюю организацию, пользовательский интерфейс, разграничение доступа и т.д. В результата этапа реализации появляется рабочая версия продукта.
Тестирование продукта
Тестирование тесно связано с такими этапами разработки программного обеспечения как проектирование и реализация. В систему встраиваются специальные механизмы, которые дают возможность производить тестирование системы на соответствие требований к ней, проверку оформления и наличие необходимого пакета документации.
Результатом тестирования является устранение всех недостатков системы и заключение о ее качестве.
Внедрение и поддержка
Внедрения системы обычно предусматривает следующие шаги:
- установка системы,
- обучение пользователей,
- эксплуатация.
К любой разработке прилагается полный пакет документации, который включает в себя описание системы, руководства пользователей и алгоритмы работы.
Поддержка функционирования ПО должна осуществляться группой технической поддержки разработчика.
Материал не является исчерпывающим и предоставлен лишь для ознакомления с основными проблемами, существующими в данной сфере. Для получения подробной информации о сотрудничестве обратитесь к нашим менеджерам или звоните по нижеуказанному номеру.
Apple никогда не выпустила бы iPhone, если бы не разработки советских и российских ученых. Об этом обозреватель ресурса Rusvesna Алексей Гумилёв, по словам которого в «яблочный» смартфон «просто напичкали уже существующие плюшки, истоки изобретения которых лежат в России».
Возможно, вы ещё не слышали, что это американцы победили фашистов, первыми полетели в космос и что это у них придумали всё самое лучшее. Мобильники и интернет – вот чем пытается повысить авторитет Америки современное молодое поколение.
А никто не думал, что родина этих изобретений в России? Пусть не в том виде, в котором мы их знаем нынче, но это так. Даже первая американская мобила была размером с домашний миксер, а пульт связи весил 12 кг. Но это не американская находка, а советская. Ещё в 1957 году мобильный телефон изобрёл Куприянович.
«Огромное количество всех изобретений имеет начало в Советской или постсоветской России».
Гусеничный ход, трамвай, самолёт, вертолёт, парашют, баллистическая ракета, космический корабль, первый спутник Земли, космическая станция, луноход, электронный микроскоп, пересадка органов, искусственные органы, первая в мире АЭС, водородная мощь и многое другое – это всё изобретено русскими. Всё, начиная с лампочки, изобрели русские. Не говоря уж о элементарной сварке металлов, без которой американские танки и прочий военный хлам казались бы совсем убогими и сплошь напичканы заклёпками.
Радио, телевизор, мультипликация, видеомагнитофон, фото- и видеосъёмка, система беспроводного управления и даже компьютер – это всё лежит в основе нынешних американских гаджетов. Все изобретения модернизировались всем миром и утеряли тот первозданный вид и функционал, что мы наблюдаем нынче.
Карманный телефон Куприяновича весил 70 граммов
Это далеко не все инновации, которые присвоили себе американцы и подытожили: «Русские деградировали, а мы изобрели iPhone». Да не в США изобрели этот айфон, в него просто напичкали уже существующие плюшки, истоки изобретения которых лежат в России. Все эти плюшки не имели мирового патента, поскольку являлись секретными военными разработками Союза.
Потом эти плюшки рассыпались по миру и их модернизировали и уменьшили в Азии, Америке и Европе, а отсутствие патента дало возможность присвоить их изобретение себе. Какой нафиг Стив Джобс, будь он покоен? Ещё скажите, что он лично делал электронные платы, сидя с дымящимся паяльником в руке. Подавляющее большинство электронной начинки всех без исключения гаджетов (iPhone тоже) произведено и собрано под одним корпусом в Китае.
Как видим, Америка присвоила себе всё, что создала Россия.
Аннотация: Понятие процесса разработки ПО. Универсальный процесс. Текущий процесс. Конкретный процесс. Стандартный процесс. Совершенствование процесса. Pull/Push стратегии. Классические модели процесса: водопадная модель, спиральная модель. Фазы и виды деятельности.
Достоинством этой модели явилось ограничение возможности возвратов на произвольный шаг назад, например, от тестирования – к анализу, от разработки – к работе над требованиями и т.д. Отмечалось, что такие возвраты могут катастрофически увеличить стоимость проекта и сроки его выполнения. Например, если при тестировании обнаруживаются ошибки проектирования или анализа, то их исправление часто приводит к полной переделке системы. Этой моделью допускались возвраты только на предыдущий шаг, например, от тестирования к кодированию , от ПО эта модель активно критиковалась, практически, каждым автором соответствующих статей и учебников. Стало общепринятым мнение, что она не отражает особенностей разработки ПО . Недостатками водопадной модели являются:
- отождествление фаз и видов деятельности, что влечет потерю гибкости разработки, в частности, трудности поддержки итеративного процесса разработки;
- требование полного окончания фазы-деятельности, закрепление результатов в виде подробного исходного документа (технического задания, проектной спецификации); однако опыт разработки ПО показывает, что невозможно полностью завершить разработку требований, дизайн системы и т.д. – все это подвержено изменениям; и причины тут не только в том, что подвижно окружение проекта, но и в том, что заранее не удается точно определить и сформулировать многие решения, они проясняются и уточняются лишь впоследствии;
- интеграция всех результатов разработки происходит в конце, вследствие чего интеграционные проблемы дают о себе знать слишком поздно;
- пользователи и заказчик не могут ознакомиться с вариантами системы во время разработки, и видят результат только в самом конце; тем самым, они не могут повлиять на процесс создания системы, и поэтому увеличиваются риски непонимания между разработчиками и пользователями/заказчиком;
- модель неустойчива к сбоям в финансировании проекта или перераспределению денежных средств, начатая разработка, фактически, не имеет альтернатив "по ходу дела".
Однако данная модель продолжает использоваться на практике – для небольших проектов или при разработке типовых систем, где итеративность не так востребована. С ее помощью удобно отслеживать разработку и осуществлять поэтапный контроль за проектом. Эта модель также часто используется в оффшорных проектах 1От английского offshore – вне берега, в расширенном толковании – вне одной страны. с почасовой оплатой труда. Водопадная модель вошла в качестве составной части в другие модели и методологии, например, в MSF .
Спиральная модель была предложена Бэри Боемом в 1988 году для преодоления недостатков водопадной модели, прежде всего, для лучшего управления рисками. Согласно этой модели разработка продукта осуществляется по спирали, каждый виток которой является определенной фазой разработки. В отличие от водопадной модели в спиральной нет предопределенного и обязательного набора витков, каждый виток может стать последним при разработке системы, при его завершении составляются планы следующего витка. Наконец, виток является именно фазой, а не видом деятельности, как в водопадной модели, в его рамках может осуществляться много различных видов деятельности, то есть модель является двумерной.
Последовательность витков может быть такой: на первом витке принимается решение о целесообразности создания ПО , на следующем определяются системные требования , потом осуществляется проектирование системы и т.д. Витки могут иметь и иные значения.
Каждый виток имеет следующую структуру (секторы):
- определение целей, ограничений и альтернатив проекта;
- оценка альтернатив, оценка и разрешение рисков; возможно использование прототипирования (в том числе создание серии прототипов), симуляция системы, визуальное моделирование и анализ спецификаций; фокусировка на самых рисковых частях проекта;
- разработка и тестирование – здесь возможна водопадная модель или использование иных моделей и методов разработки ПО;
- планирование следующих итераций – анализируются результаты, планы и ресурсы на последующую разработку, принимается (или не принимается) решение о новом витке; анализируется, имеет ли смысл продолжать разрабатывать систему или нет; разработку можно и приостановить, например, из-за сбоев в финансировании; спиральная модель позволяет сделать это корректно.
Отдельная спираль может соответствовать разработке некоторой программной компоненты или внесению очередных изменений в продукт. Таким образом, у модели может появиться третье измерение.
Спиральную модель нецелесообразно применять в проектах с небольшой степенью риска, с ограниченным бюджетом, для небольших проектов. Кроме того, отсутствие хороших средств прототипирования может также сделать неудобным использование спиральной модели.
Спиральная модель не нашла широкого применения в индустрии и важна, скорее в историко-методологическом плане: она является первой итеративной моделью, имеет красивую метафору – спираль, – и, подобно водопадной модели, использовалась в дальнейшем при создании других моделей процесса и методологий разработки ПО .
