Программы для анализа рынка

1. Анализ рынка существующих решений

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

GraphXquatoR

GraphXquatoR – программа  для построения графиков функций,  уравнения которых вы введете.  Программа строит как 2D, так и 3D графики функций. В отличие от других программ, здесь можно создавать сколько угодно вкладок и на каждой вкладке можно создать сколько угодно графиков (их кол-во ограничено только памятью компьютера).

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

Master Function

 Программа Master Function предназначена для анализа функций и построения их графиков.

Возможности программы:

• Построение графиков функций любой сложности, заданных обычным текстовым выражением (например 4sin(3x+tgx));
• возможность отыскания производной в текстовом виде;
• вычисление значения определенного интеграла;
• построение касательных и нормалей;
• таблица значений функции в разных точках;
• построение графиков прямых и парабол по известным точкам;
• утилита решения квадратных уравнений;
• одновременная работа с 16 функциями;
• простой и понятный интерфейс;
• HELP на русском языке.

ZyukaGraphik V 1.1

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

2. АРХИТЕКТУРА  ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

2.1. Модель жизненного цикла

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

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

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

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

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

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

Основным нормативным  документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации.

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

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

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

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

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

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

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

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

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

2.2.Описание  общей структуры проекта

 

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

Главная форма. В программе должна быть панель управления и область построения графиков.

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

Область построения графиков – область в которой будут строиться графики, она должна обладать навигацией.

3. РЕАЛИЗАЦИЯ ПРОГРАММНОГО ПРОДУКТА

После разработки архитектуры очень важно выбрать  аппаратную платформу и необходимые  средства разработки.

3.1. Программно  аппаратная платформа

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

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

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

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

Исходя из того, что платформа IBM PC является наиболее распространенной в России, было принято решение  разрабатывать наше ПС именно под  эту аппаратную платформу.

Проанализировав системное программное обеспечение IBM PC-совместимой компьютерной техники, были получены следующие результаты: 63 % - ОС семейства Windows, 26 % - Linux, 11 % - Free BSD, Open BSD, SCO, Mac OS X, Novell NetWare и т.д. Исходя из этих результатов, а также из соображения, что программное обеспечение должно функционировать на как можно большем количестве платформ, было принято решение разрабатывать ПС с таким расчетом, чтобы обеспечить функционирование, как его отдельных компонентов так и всего комплекса в целом на одной основной программной платформе Windows.

3.2. Среда разработки проекта

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

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

Delphi — императивный, структурированный, объектно-ориентированный язык программирования, диалект Object Pascal.

Delphi — результат  развития языка Турбо Паскаль,  который, в свою очередь, развился  из языка Паскаль. Паскаль был полностью процедурным языком, Турбо Паскаль, начиная с версии 5. 5, добавил в Паскаль объектно-ориентированные свойства, а Delphi — объектно-ориентированный язык программирования с возможностью доступа к метаданным классов в компилируемом коде, также называемом интроспекцией.

Последняя на сегодняшний  день версия - 2009. Delphi является мощным и  универсальным средством разработки приложений, RAD-оболочкой. Ее вместе с  библиотекой VCL, на которой оболочка основана и написана, можно назвать  действительно революционной. Сравнение с C++ Builder 4 показывает, что производительность Pascal-кода, сгенерированного Delphi, всего на 4-5% меньше, чем кода C++.

Простота, скорость и эффективность Delphi объясняют ее популярность. Delphi имеет один из самых  быстрых компиляторов, порождающий, тем не менее, весьма и весьма неплохой объектный код. Есть и другие достоинства: простота изучения Object Pascal; облегчающие жизнь нововведения - вроде свойств (properties); программы, написанные на Delphi, не требуется снабжать дополнительными библиотеками (в отличие от связки C++/MFC). В самом деле, VCL предоставляет удобный, легко расширяемый объектно-ориентированный интерфейс к Windows, что ни в коей мере не мешает программисту опускаться в самые глубины Windows API. Создателям оригинальных компонентов это приходится делать довольно часто, в отличие от "просто программистов". Как было сказано выше, модель программирования в Delphi - компонентная, что позволяет пользоваться компонентами, написанными другими разработчиками, даже не имея их исходного кода и уж подавно не изучая его.

Применение  компонентной модели приводит к тому, что довольно многое в поведении  объектов программировать не нужно  вообще, и многое, на что в других средах ушли бы недели, можно сделать  за часы или даже минуты. Оно и понятно - это ведь RAD-среда. К достоинствам можно отнести очень быстрый браузер классов и мгновенный вывод подсказки автозавершения кода (code completion).

Достоинства:

1. простой и мощный язык программирования Pascal.
2. удобная и полная объектная модель.
3. достаточно удобная среда разработки.
4. мощные средства разработки приложений баз данных.
5. быстрота разработки приложения.

3.3. Реализация программного продукта

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

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

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