Обзор программного обеспечения


Конструкторско-технологическая часть



страница5/10
Дата06.11.2016
Размер2.42 Mb.
Просмотров2742
Скачиваний0
1   2   3   4   5   6   7   8   9   10

2. Конструкторско-технологическая часть

2.1. Выбор жизненного цикла информационной системы


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

Стандарт ГОСТ 34.601-90 насчитывает следующие стадии и этапы создания автоматизированной системы[22]:

1. Формирование требований к автоматизированной системе

1. Обследование объекта и обоснование необходимости создания автоматизированной системы;

2. Формирование требований пользователя к автоматизированной системе;

3. Оформление отчета о выполнении работ и заявки на разработку автоматизированной системы;

2. Разработка концепции автоматизированной системы

1. Изучение объекта

2. Проведение необходимых научно-исследовательских работ

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

4. Оформление отчета о проделанной работе

3. Техническое задание

1. Разработка и утверждение технического задания на создание автоматизированной системы;

4. Эскизный проект

1. Разработка предварительных проектных решений по системе и частям автоматизированной системы;

2. Разработка документации на автоматизированную систему и ее части;

5. Технический проект

1. Разработка проектных решений по системе и частям автоматизированной системы

2. Разработка документации на автоматизированную систему и ее части;

3. Разработка и оформление документации на поставку комплектующих изделий

4. Разработка заданий на проектирование в смежных частях проекта;

6. Рабочая документация

1. Разработка рабочей документации на автоматизированную систему и ее части

2. Разработка и адаптация программ;

7. Ввод в действие

1. Подготовка объекта автоматизации;

2. Подготовка персонала;

3. Комплектация автоматизированной системы поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

4. Строительно-монтажные работы;

5. Пусконаладочные работы;

6. Проведение предварительных испытаний;

7. Проведение опытной эксплуатации;

8. Проведение приемочных испытаний;

8. Сопровождение автоматизированной системы

1. Выполнение работ в соответствии с гарантийными обязательствами;

2. Послегарантийное обслуживание;

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

1. Водопадная (каскадная, последовательная) модель[21]



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

Этапы проекта в соответствии с каскадной моделью:



  1. Формирование требований;

  2. Проектирование;

  3. Реализация;

  4. Тестирование;

  5. Внедрение;

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

Преимущества:

  • Полная и согласованная документация на каждом этапе;

  • Легко определить сроки и затраты на проект.

Недостатки:

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

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

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

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

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

2. Итерационная модель[21]

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

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

Итерационный подход имеет и свои недостатки, которые являются обратной стороной достоинств.



  • Продолжительное время нет полного понимания какими возможностями должен обладать проект и какие должны быть наложены ограничения.

  • На каждой итерации происходит отбрасывание части сделанной на предыдущем этапе работы.

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

3. Спиральная модель[21]

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

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

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

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

На основе спиральной модели реализована технология быстрой разработки приложений (RAD-технология).

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



Этапы проекта в соответствии с каскадной моделью:

  1. Формирование требований:

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

Так же выбран способ ввода и представления подписи в системе. Подпись будет вводиться посредствам сенсорного экрана.

Таким образом, основными требованиями к системе являются:


  • Отказ от самостоятельной оценки пользователем характеристик почерка;

  • Возможность системы работать с оригиналом почерка;

  • Возможность ввода подписи посредствам сенсорного экрана;

  1. Проектирование:

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

Система разбита на три модуля:

- модуль ввода подписи;

- модуль обработки характеристик подписи;

- модуль оценивания результатов обработки характеристик подписи;

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

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

Также от пользователя требуется выделить буквы подписи. Для этого требуется обвесит буквы, входящие в подпись.

Модуль обработки характеристик подписи. Для обработки характеристик подписи используются алгоритмы, разработанные на предыдущем этапе.

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



Характеристика подписи

Результат анализа

Характеристика личности

Амплитуда

Увеличивается

Человек постепенно развивает активность от начала к концу деятельности.

Амплитуда

Уменьшается

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

Амплитуда

Ровная

Работоспособность сохраняется на стабильном уровне от начала до конца деятельности.

Первичным ключом базы данных будет являться составной ключ «Характеристика подписи» и «Результат анализа».

  1. Реализация:

Для реализации системы были выбраны:

  • Операционная система Android версии 4.0 и выше;

  • IDE Eclipse, JDK 6, Android SDK и SQLite;

  • Язык высокого уровня Java;

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

  • MainActivity – основной класс, отображающий содержимое экрана и управляющий работой остальных классов;

  • SgnAnlsView – класс, реализующий возможность ввод подписи;

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

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

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

  • Analysis – класс, производящий непосредственную оценку характеристик подписи;

  1. Тестирование

Для тестирования компонентов системы использовались юнит-тесты на основе JUnit4. Тестирование проводилось для:

  • основных и вспомогательных функций ввода подписи;

  • функций, выполняющих оценку характеристик подписи;

  • функций, выполняющих передачу данных между классами;

  • функций, занимающихся обработкой результатов;

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

Каталог: data -> 2013
2013 -> Федеральное государственное автономное образовательное
2013 -> «Визуальный образ персонажей массового кинематогрфа в историческом контексте»
2013 -> 2 раздел анализ предметной области 5
2013 -> Магистерская диссертация
2013 -> Влияние вовлеченности на готовность платить за коллекционные товары
2013 -> Выражение гендерных характеристик в англоязычном "глянцевом" дискурсе
2013 -> Продакт Плейсмент и перспективы его развития в сети Интернет
2013 -> 1Лекции первого полугодия
2013 -> «Правовое рассмотрение компьютерного мошенничества», Ницца, 22 октября 1992 года, грамота «весьма достойно»


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   10


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал