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

Содержание:

ВВЕДЕНИЕ

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

К международным организациям по стандартизации относятся следующие: ISO - International Organization for Standardization, ITU - International Telecommunication Union, IEC - International Electrotechnical Commission.

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

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

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

Основным стандартом, определяющим структуру жизненного цикла, является ГОСТ Р ИСО/МЭК 12207-02.

Объект исследования – программные системы.

Предмет исследования – жизненный цикл программной системы.

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

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

– описать каскадную модель разработки программной системы;

– описать спиральную модель разработки программной системы;

– описать этапы жизненного цикла проекта автоматизации;

– описать процесс тестирования и отладки программной системы;

– разработать программную систему.

Глава 1. Жизненный цикл разработки программной системы

1.1. Каскадная модель разработки программной системы

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

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

– каскадная модель (70-80-е годы 20 века);

– спиральная модель (80-90-е годы 20 века)^[2].

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

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

Все этапы завершается запуском полно­го комплекта документов, достаточных для того, чтобы дальнейшая разработка могла вестись другой командой разработчиков^[3].

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

– на всех этапах формирования конечного набора проектных документов, которая отвечает четким критериям по полноте и согласованности^[4];

– выполняемые этапы работ позволяют соблюдать поставленные сроки по завершению необходимых работ и осваивать некоторые затраты на разработку программной системы^[5].

Рисунок 1 – Каскадная схема разработки программной системы

Каскадный подход хорошо зарекомендовал себя в процессе непосредственной разработки программных средств, для которых в начале разработки выполнения разработки можно доста­точно полно и точно сформулировать необходимые требования, для предоставления разработчикам свободы в практической реализации их как мож­но эффективней с технической точки зрения^[6].

К данной категории относятся прикладные программные системы реального времени, сложные расчетные прикладные программные системы и дру­гие подобные задачи^[7].

Однако, следует отметить, что в процессе практического применения данного подхода появляется определенные его определенные недостатки, которые вызваны прежде всего тем, что реальный процесс по созданию программной системы никогда в полной мене не укладывался в такую жесткую схему^[8].

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

В результате реальный процесс по созданию программной системы принимает следую­щий вид, представленный на рис. 2.

Рисунок 2 – Схема реального процесса разработки программной системы по каскадной схеме

Основным недостатком каскадного подхода является существен­ное запаздывание с получением результатов. Согласование резуль­татов с пользователями производится только в точках, планируе­мых после завершения каждого этапа работ, требования к ИС «за­морожены» в виде технического задания на все время ее создания^[9].

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

1.2. Спиральная модель разработки программной системы

Для преодоления проблем при использовании каскадной модели разработки программной системы была предложена спиральная модель жизненного цикла, делающая упор на начальных этапах жизненного цикла: анализ и проектирование. На перечисленных этапах реализуе­мость технических решений может быть проверена за счет создания прото­типов системы^[10].

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

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

Рисунок 3 – Схема спиральной модели жизненного цикла

Разработка итерациями отражает объективно существующий спиральный цикл по созданию программной системы^[11]. Неполное завершение работ на всех этапах позволяет выполнить переход на следующий этап, не дожидаясь завершения работы на текущем этапе. При итера­тивном способе разработки недостающую работу можно будет выполнить на следующей итерации^[12].

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

1.3. Этапы жизненного цикла проекта автоматизации

Понятие жизненного цикла является одним из ключевых понятий методологии непосредственного проектирования информационных систем. Жизненный цикл информационной системы – это непрерывный процесс, начинающийся с момента принятия соответствующего решения о создании информационной системы и заканчивающийся в момент полного изъятия ее из эксплуатации^[13].

Основным стандартом, определяющим структуру жизненного цикла, является ГОСТ Р ИСО/МЭК 12207-02. Согласно стандарту структура жизненного цикла основывается на трех группах процессов:

– основные процессы (заказ, поставка, разработка, эксплуатация, сопровождение);

– вспомогательные процессы:

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

– организационные:

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

Основные процессы

Заказ;

Поставка; Разработка;

Эксплуатация; Сопровождение

Документирование;

Управление конфигурацией;

Обеспечение качества;

Верификация;

Аттестация;

Совместный анализ;

Аудит;

Разрешение проблем

Управление проектами;

Создание инфраструктуры проекта;

Усовершенствова-ние;

Обучение

Рисунок 4 – Структура жизненного цикла программных средств

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

Глава 2. Тестирование и отладка программной системы

2.1. Виды тестирования

Функциональное тестирование.

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

Тестирование «белого ящика» (white box) представляет собой использование операций тестирования на соответствие программной системы некоторым требованиям с учетом знаний внутренней структуры реализации программной системы (при наличии исходного кода и технической спецификации)^[17].

Тестирование «черного ящика» (black box) представляет собой тестирование на соответствие программной системы заявленным требованиям без знания внутренней структуры реализации программной системы.

Системное тестирование.

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

Тестирование производительности.

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

Нагрузочное тестирование.

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

Стресс тестирование.

Стресс тестирование представляет собой тестирование, которое предназначено для выполнения проверки полной работоспособности программной системы при наличии нестандартных нагрузок и для выявления максимально возможного пика программной системы, при котором программная система будет работать правильно и без сбоев^[18]. Так же стресс тестирование используется для выявления результатов, при которых программная система переходит в нерабочее состояние, т.е. выходит из строя.

Регрессионное тестирование.

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

Модульное тестирование.

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

Тестирование безопасности.

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

Тестирование локализации.

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

Юзабилити тестирование.

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

2.2. Тестирование надежности

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

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

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

Надежность и правильность программной системы.

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

1. Число ошибок в программной системе представляет собой определенную величину «ненаблюдаемую», наблюдаются не сами возникающие ошибки, а результат их проявления в конечной программной системе.

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

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

4. Надежность характеризуется частотой проявления возможных ошибок, но не их количества; в то же время хорошо является известным, что ошибки могут проявляться с разной частотой: множество ошибок будут неопределенными после нескольких месяцев и даже лет конечной эксплуатации программной системы, но, с другой стороны, нетрудно найти примеры, когда одна ошибка может привести к неверному выполнению программной системы при любых исходных данных, т.е. к некоторой нулевой надежности^[20].

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

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

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

В качестве примера рассмотрим метод восходящего тестирования.

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

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

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

2.3. Организация процесса тестирования

Тестирование программной системы одновременно проводится по нескольким направлениям:

1. Проверка кода (review): в процессе которой тестер просматривает визуально исходный код программной системы и ищет в нём имеющиеся ошибки, а так же выполняет поиск различных несоответствий программного кода и требований, предъявляемых к нему. Под требованиями к программному коду понимается определенный стандарт, которого должны придерживаться разработчики программной системы, реакция на те или иные действия со стороны среды воздействия на программную систему, поведение программной системы в различных ситуациях [16].

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

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

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

Стандарт ISO 9001.

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

Стандарт ISO/IEC 12207 и IEEE/EIA 12207.

ISO/IEC 12207 - это международный стандарт, описывающий структуру процессов жизненного цикла ПО от концепции до изъятия из обращения. Стандарт IEEE/EIA 12207 - адаптация ISO/IEC 12207 для США.

В соответствии с этими стандартами в той или иной отрасли производства выдвигаются требования к тестированию ПО. Например в авиации США на основе ISO/IEC 12207 был выработан стандарт RTCA( Requirements and Technical Concepts for Aviation). В нём перечислены следующие требования к тестированию верхнего и нижнего уровня. Тестирование верхнего уровня:

– предъявляемые требования высокого уровня должны содержать системные требования к определенной программной системе;

– предъявляемые требования высокого уровня должны формулироваться с учётом архитектуры определенной программной системы;

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

– откомпилированный и готовый к использованию программный код должен удовлетворять требованиям, которые предъявляются к определенной программной системе;

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

Тестирование нижнего уровня предполагает:

– выполнение проверки (Verification) требований нижнего уровня к программной системе;

– выполнение полной проверки архитектуры некоторой программной системы;

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

– выполнение контроля исполняемых процедур тестирования программной системы;

– проверка независимости программной системы от тестирования. Т.е. программная система не должно перестраиваться особым образом под выполняемые тесты;

– выполнение тестирования должно несколько раз покрывать исходный код программной системы, для обнаружения определённого класса возможных ошибок;

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

Таким образом, среди видов тестирования были выделены и описаны: Функциональное тестирование; системное тестирование; тестирование производительности; нагрузочное тестирование; стресс тестирование; регрессионное тестирование; модульное тестирование; тестирование безопасности; тестирование локализации; юзабилити тестирование. Более подробно расписано тестирование надежности. Также, было описана организация процесса тестирования по стандарту ISO/IEC 12207 и IEEE/EIA 12207.

Глава 3. Реализация программной системы

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

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

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

Администрирование почты представляет собой процесс анализа и обработки писем (входящий и исходящий контент). Если пользователю нужно написать или ответить на 5 – 10 сообщений, особых затруднений возникнуть не должно. А вот, если нужно сделать массовую рассылку 200 клиентам или более могут возникнуть серьезные проблемы учета этих писем. Для решения данной проблемы нужно сделать первые шаги автоматизации процесса рассылки e-mail сообщений.

Рассылку e-mail сообщений можно организовать на следующих положениях:

– подключение к серверу электронной почты и авторизация пользователя;

– формирование письма e-mail средствами текстового редактора, наполнение его необходимыми данными;

– формирование списка e-mail адресов рассылки, для чего целесообразно использовать отдельный файл с адресами;

– отправка сообщения при помощи специального скрипта на языке программирования Python.

3.2. Алгоритмизация программы

Существуют три основных протокола для работы с электронной почтой. Самый старый из них называется POP (Post Office Protocol). Его суть в том, что программное обеспечение для работы с электронной почтой (не браузер) подключается к удалённому серверу, скачивает письма на компьютер пользователя, и они становятся доступны без подключения к интернету. Это было хорошей идеей в те времена, когда к интернету подключались нечасто, и было нормальным не иметь выхода в Сеть, но в настоящее время такого почти не бывает.

Текущим стандартом доступа к электронным ящикам является протокол IMAP (Internet Message Access Protocol). Он намного быстрее и больше соответствует тому, как интернет используется в наши дни. Он позволяет нескольким пользователям подключаться к одному ящику и поддерживает их соединение в течение всей сессии.

Web-браузеры получают доступ к электронной почте с помощью дополнительного протокола – HTTP, но в основе лежат всё те же POP и IMAP.

В основном для получения писем с сервера используются POP (актуальная версия POP3) и IMAP. Но для того чтобы отправить письмо, нужен другой протокол – SMTP (Simple Mail Transfer Protocol). Всё потому, что нельзя просто отправить письмо получателю. Его нужно отправить на сервер, с которого получатель это письмо скачает, используя IMAP и POP3.

Для начала нужно подключить подходящий модуль Python – Smtplib, который поставляется вместе с Python, для этого необходимо ввести следующую команду:

import smtplib

Для получения справки по модулю можно воспользоваться специальной функцией help:

help(smtplib)

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

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

smtpObj = smtplib.SMTP('smtp.gmail.com', 587)

Переменная smtpObj является объектом типа SMTP, которую можно назвать в любом удобном виде.

Следующее, что нужно сделать для установления соединения, это «сказать» SMTP-объекту, что сообщение должно быть зашифровано. Для этого следует воспользоваться следующим оператором:

smtpObj.starttls()

Это позволит сообщить Gmail, что хотим, чтобы наше соединение шифровалось с помощью протокола TLS (Transport Layer Security), который на сегодняшний день является стандартом для интернет-коммуникаций. Сам по себе TLS не является криптографическим алгоритмом, он скорее сообщает, что необходимо использовать шифрование или соединение не должно быть установлено.

Для того чтобы авторизоваться, нужно всего лишь написать:

smtpObj.login('tt0065746@gmail.com','12aAs123')

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

smtpObj.sendmail("tt0065746@gmail.com","michaels.byrnel@vice.com","The end my freand!")

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

smtpObj.quit()

Полный программный код программы представлен в Приложении. Таким образом, были продемонстрированы основные программные решения, использовав которые можно получить желаемую программу рассылки e-mail.

3.3. Порядок работы с программой

Для начала работы с программой необходимо сформировать список рассылки e-mail адресов и записать их в текстовый файл, содержание которого представлено на рис. 5. Файлы e-mail адресов и письма рассылки должны быть в папке, в которой находится запускаемая программа.

Рисунок 5 – Содержание файла рассылки e-mail адресов

Далее, необходимо составить письмо рассылки в виде тактового файла, содержание которого представлено на рис. 6.

Рисунок 6 – Содержание файла письма рассылки e-mail

Запуск программы можно выполнить при помощи программы TextMate или среды Python. Интерфейс программной среды разработки представлен на рис. 7.

Рисунок 7 – Интерфейс среды разработки

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

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

Рисунок 8 – Результат выполнения программы

Проверить результат выполнения программы, можно посмотрев соответствующий почтовый ящик, указанный в файле e-mail рассылки. Так, сообщение было отправлено на адрес tt0065746@gmail.com, рис. 9.

Рисунок 9 – Результат приема сообщения

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

ЗАКЛЮЧЕНИЕ

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

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

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

Международные организации по стандартизации ISO - International Organization for Standardization, ITU - International Telecommunication Union, IEC - International Electrotechnical Commission разрабатывают стандарты, в частности по разработке программных систем.

Основным стандартом, определяющим структуру жизненного цикла, является ГОСТ Р ИСО/МЭК 12207-02.

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Архипенков С. Хранилища данных. От концепции до внедрения / С. Архипенков, Д. Голубев, О. Максименко. - М.: Диалог-Мифи, 2017. – 528 c.
2. Венделева М.А. Информационные технологии в управлении.: Учебное пособие для бакалавров / М.А. Венделева, Ю.В. Вертакова. - Люберцы: Юрайт, 2016. – 462 c.
3. Гаврилов М.В. Информатика и информационные технологии: Учебник / М.В. Гаврилов, В.А. Климов. - Люберцы: Юрайт, 2016. – 383 c.
4. Грошев А.С., Закляков П. В. Информатика: учеб. для вузов – 3-е изд., перераб. и доп. – М.: ДМК Пресс, 2015. – 588 с.
5. Грошев А.С. Информационные технологии : лабораторный практикум / А. С. Грошев. – 2-е изд. – М.-Берлин: Директ-Медиа, 2015. – 285 с.
6. Дарков А.В. Информационные технологии: теоретические основы: Учебное пособие / А.В. Дарков, Н.Н. Шапошников. - СПб.: Лань, 2016. – 448 c.
7. Долганова О.И. Моделирование бизнес-процессов: Учебник и практикум для академического бакалавриата / О.И. Долганова, Е.В. Виноградова, А.М. Лобанова. - Люберцы: Юрайт, 2016. – 289 c.
8. Дюваль М. Непрерывная интеграция. Улучшение качества программного обеспечения и снижение риска / Дюваль, М. Поль. - М.: Вильямс, 2016. – 240 c.
9. Ерохин В.В. Безопасность информационных систем: учеб пособие / В.В. Ерохин, Д.А. Погонышева, И.Г. Степченко. - М.: Флинта, 2016. – 184 c.
10. Згадзай О.Э. Информационные технологии в юридической деятельности: Учебное пособие / О.Э. Згадзай и др. - М.: ЮНИТИ, 2016. – 335 c.
11. Илюшечкин В.М. Основы использования и проектирования баз данных. – М.:Юрайт, 2015. – 224 с.
12. Информатика для экономистов: учебник для академического бакалавриата/Под ред. В.П. Полякова.- М.: Юрайт, 2015. – 524 с.
13. Информационные системы и технологии: Научное издание. / Под ред. Ю.Ф. Тельнова. - М.: ЮНИТИ, 2016. – 303 c.
14. Кузнецов С.Д. Основы баз данных / С.Д. Кузнецов. - М.: Бином, 2017. – 484 c.
15. Овчаров Л.А. Автоматизированные банки данных / Л.А. Овчаров, С.Н. Селетков. - М.: Финансы и статистика, 2016. – 262 c.
16. Олифер В., Олифер Н. Компьютерные сети (принципы, технологии, протоколы). - СПб.: Питер, 5-е изд., 2016. – 992 с.
17. Романова Ю.Д. Информационные технологии в управлении персоналом: Учебник и практикум / Ю.Д. Романова, Т.А. Винтова, П.Е. Коваль. - Люберцы: Юрайт, 2016. – 291 c.
18. Сальникова Л.С. Современные коммуникационные технологии в бизнесе: Учебник / Л.С. Сальникова. - М.: Аспект-Пресс, 2015. – 296 c.
19. Советов Б.Я. Информационные технологии: теоретические основы: Учебное пособие / Б.Я. Советов, В.В. Цехановский. - СПб.: Лань, 2016. – 448 c.
20. Элькин В. Д. Информационные технологии в юридической деятельности: учебное пособие для бакалавров / В. Д. Элькин. - М.: Юрайт, 2016. – 527 с.

ПРИЛОЖЕНИЕ

Исходный код программы

# подключение необходимых библиотек

from smtplib import SMTP_SSL

from email.MIMEText import MIMEText

# функция отправки сообщения

def sendMail(client_mail, message, header):

# e-mail отправителя сообщения

my_donor_mail="tt0065746@gmail.com"

# формат текста сообщения, кодировка

msg = MIMEText(message, "html", "utf-8")

# заголовок отправляемого сообщения

msg['Subject'] = header

# e-mail отправителя сообщения

msg['From'] = my_donor_mail

# e-mail получателя сообщения

msg['To'] = client_mail

# описываем используемое подключение

smtp = SMTP_SSL()

# подключение к smtp gmail, указываем smtp.gmail.com

smtp.connect('smtp.gmail.com')

# выполняем аутентификацию пользователя почты

smtp.login(my_donor_mail, '12aAs123')

# отправляем ообщение

smtp.sendmail(my_donor_mail, client_mail, msg.as_string())

# закрываем соединение

smtp.quit()

# подключаем список e-mail адресов рассылки

mail_list='s.txt'

# текст e-mail рассылки

mail_body='email.txt'

# заголовок сообщения

header='Mail'

# считываем файл сообщения

f=open(mail_body, 'r')

# присваиваем текст сообщения переменной

message=f.read()

# закрываем файл сообщения

f.close()

# отправляем сообщение, цикл для отправки нескольких сообщений

for mail in open(mail_list, 'r'):

try:

# воспользовавшись функцией, отправляем сообщение,

# передаем mail, message, header

sendMail(mail, message, header)

# если успешная отправка, выводим сообщение с адресом отправки

print 'Send to: '+mail[:-1]

except:

# если не успешная отправка, выводим сообщение с адресом отправки

print 'NOT send to: '+mail[:-1]

f.close()

1. Архипенков С. Хранилища данных. От концепции до внедрения / С. Архипенков, Д. Голубев, О. Максименко. - М.: Диалог-Мифи, 2017. – 528 c. ↑

2. Гаврилов М.В. Информатика и информационные технологии: Учебник / М.В. Гаврилов, В.А. Климов. - Люберцы: Юрайт, 2016. – 383 c. ↑

3. Дарков А.В. Информационные технологии: теоретические основы: Учебное пособие / А.В. Дарков, Н.Н. Шапошников. - СПб.: Лань, 2016. – 448 c. ↑

4. Грошев А.С. Информационные технологии : лабораторный практикум / А. С. Грошев. – 2-е изд. – М.-Берлин: Директ-Медиа, 2015. – 285 с. ↑

5. Венделева М.А. Информационные технологии в управлении.: Учебное пособие для бакалавров / М.А. Венделева, Ю.В. Вертакова. - Люберцы: Юрайт, 2016. – 462 c. ↑

6. Грошев А.С., Закляков П. В. Информатика: учеб. для вузов – 3-е изд., перераб. и доп. – М.: ДМК Пресс, 2015. – 588 с. ↑

7. Информатика для экономистов: учебник для академического бакалавриата/Под ред. В.П. Полякова.- М.: Юрайт, 2015. – 524 с. ↑

8. Ерохин В.В. Безопасность информационных систем: учеб пособие / В.В. Ерохин, Д.А. Погонышева, И.Г. Степченко. - М.: Флинта, 2016. – 184 c. ↑

9. Овчаров Л.А. Автоматизированные банки данных / Л.А. Овчаров, С.Н. Селетков. - М.: Финансы и статистика, 2016. – 262 c. ↑

10. Сальникова Л.С. Современные коммуникационные технологии в бизнесе: Учебник / Л.С. Сальникова. - М.: Аспект-Пресс, 2015. – 296 c. ↑

11. Дюваль М. Непрерывная интеграция. Улучшение качества программного обеспечения и снижение риска / Дюваль, М. Поль. - М.: Вильямс, 2016. – 240 c. ↑

12. Долганова О.И. Моделирование бизнес-процессов: Учебник и практикум для академического бакалавриата / О.И. Долганова, Е.В. Виноградова, А.М. Лобанова. - Люберцы: Юрайт, 2016. – 289 c. ↑

13. Згадзай О.Э. Информационные технологии в юридической деятельности: Учебное пособие / О.Э. Згадзай и др. - М.: ЮНИТИ, 2016. – 335 c. ↑

14. Илюшечкин В.М. Основы использования и проектирования баз данных. – М.:Юрайт, 2015. – 224 с. ↑

15. Информационные системы и технологии: Научное издание. / Под ред. Ю.Ф. Тельнова. - М.: ЮНИТИ, 2016. – 303 c. ↑

16. Олифер В., Олифер Н. Компьютерные сети (принципы, технологии, протоколы). - СПб.: Питер, 5-е изд., 2016. – 992 с. ↑

17. Кузнецов С.Д. Основы баз данных / С.Д. Кузнецов. - М.: Бином, 2017. – 484 c. ↑

18. Элькин В. Д. Информационные технологии в юридической деятельности: учебное пособие для бакалавров / В. Д. Элькин. - М.: Юрайт, 2016. – 527 с. ↑

19. Романова Ю.Д. Информационные технологии в управлении персоналом: Учебник и практикум / Ю.Д. Романова, Т.А. Винтова, П.Е. Коваль. - Люберцы: Юрайт, 2016. – 291 c. ↑

20. Советов Б.Я. Информационные технологии: теоретические основы: Учебное пособие / Б.Я. Советов, В.В. Цехановский. - СПб.: Лань, 2016. – 448 c. ↑