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

Введение.

 

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

Важная категория интегрированных решений – система обработки информации предприятия. Такую систему мы привыкли называть АСУ – автоматизированная система управления.

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

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

Современные СУБД в основном являются приложениями Windows, так как данная

среда позволяет более полно использовать возможности персонально ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных ПК

обусловил не только широкий переход к среде Windows, где разработчик

программного обеспечения может в меньше степени заботиться о

распределении ресурсов, но также сделал программное обеспечение ПК в

целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ.

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

можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland

Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз

данных Microsoft SQL Server и Oracle, используемые в приложениях,

построенных по технологии «клиент-сервер». Фактически, у любой

современной СУБД существует аналог, выпускаемый другой компанией, имеющий

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

работать со многими форматами представления данных, осуществлять экспорт

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

Общепринятыми, также, являются технологи, позволяющие использовать

возможности других приложений, например, текстовых процессоров, пакетов

построения графиков и т.п., и встроенные версии языков высокого уровня

(чаще – диалекты SQL и/или VBA) и средства визуального программирования

интерфейсов разрабатываемых приложений. Поэтому уже не имеет

существенного значения на каком языке и на основе какого пакета написано

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

того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD

(от английского Rapid Application Development), основанная на широко

декларируемом в литературе «открытом подходе», то есть необходимость и

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

разработки более гибких и мощных систем обработки данных. Поэтому в одном

ряду с «классическими» СУБД все чаще упоминаются языки программирования

Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать

необходимые компоненты приложений, критичные по скорости работы, которые

трудно, а иногда невозможно разработать средствами «классических» СУБД.

Современный подход к управлению базами данных подразумевает также широкое

использование технологии «клиент-сервер».

I. Введение

Настоящее техническое задание, оформленное в соответствии с ГОСТ 19.201-78, содержит требования к редактору, предназначенного для просмотра и редактирования информации о прокате автомобилей на ПЭВМ.

II. Основание для разработки

§ Основание для разработки

Основанием для разработки текстового редактора является задание на курсовой проект по дисциплине “Технология разработки программного обеспечения”.

§ Исполнитель и заказчик

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

Исполнителем разработки, выполняемой по настоящему ТЗ, является студентка группы 4468 Корнева А.А.

§ Наименование

Программе, разрабатываемой по настоящему ТЗ, присваивается наи­ме­но­ва­ние: "Автоматизированная информационная система "Клиент", в дальнейшем по тексту именуемая АИСК.

III. Назначение разработки

АИСК предназначена для выполнения следующих действий с информацией о прокате автомобилей на ПЭВМ:

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

- просмотра информации о доступных автомобилях;

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

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

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

IV. Требования к программе и программному изделию

§ Требования к составу

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

§ Требования к функциональным характеристикам

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

АИСК должна выполнять следующие функции:

- создавать базу данных о доступных автомобилях;

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

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

- редактировать созданную или открытую базу данных;

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

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

- сохранять созданную или открытую базу данных в текстовый файл на НГМД или НЖМД под заданным именем;

- выводить на монитор ПЭВМ или принтер справочную информацию о программе и порядке ее эксплуатации;

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

Требования к редактированию базы данных:

При редактировании базы данных АИСК должна выполнять следующие функции:

- вводить символы в информационное поле, отмеченное курсором;

- осуществлять навигацию по программе с помощью клавиатуры или “мыши”;

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

- удалять выделенные информационные поля с помощью клавиатуры;

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

- копировать с помощью клавиатуры или манипулятора типа “мышь” выделенные информационные поля в буфер обмена;

- вырезать с помощью клавиатуры или “мышью” выделенные информационные поля в буфер обмена;

- вставлять с помощью клавиатуры или “мышью” в информационное поле или позицию этом, отмеченную курсором, текстовое содержимое буфера обмена;

§ Требования к надежности

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

§ Условия эксплуатации

АИСК должен функционировать в соответствии с заданными в настоящем ТЗ тре­бованиями, в составе ПО ПЭВМ, при эксплуатации ПЭВМ. Условия эксплуа­тации должны соответствовать условиям эксплуатации ПЭВМ, тре­бо­ва­ния к которым предъявляются в эксплуатационной доку­мен­та­ции ПЭВМ или ее составных частей.

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

АИСК должна функционировать на ПЭВМ со следующими характеристиками

- процессор не ниже Pentium II 500МГц;

- объем ОЗУ не менее 128 Мб;

- НГМД 3,5 (1,44 Мб);

- НЖМД не менее 8 Гб;

- графический адаптер не хуже SVGA 8 Мб;

- монитор не хуже SVGA 0.26, 15 дюймов;

- сетевая плата, совместимая с Ethernet;

- манипулятор типа “мышь”;

- струйный или лазерный принтер формата А4.

Штатным носителем АИСК является НЖМД ПЭВМ. Технологическим носи­те­лем АИСК является НГМД.

Объем ОЗУ, используемого АИСК при своем функционировании, не должен превышать 64 кб.

§ Требования к информационной и программной совместимости

В качестве языков программирования АИСК должен быть использован язык программирования Си++.

АИСК должна функционировать на ПЭВМ с одной из операционных систем MS Windows 95, MS Windows 98, MS Windows NT, MS Windows 2000, MS Windows XP.

Для реализации интерфейса между АИСК и пользователем должны использоваться средства графического интерфейса операционной системы.

Для реализации интерфейса между АИСК и другими программами из состава ПО ПЭВМ должны использоваться средства буфера обмена операционной системы.

§ Требования к маркировке и упаковке

Маркировка НГМД с АИСК должна проводиться в соответствии с требованиями ГОСТ 19.102-77 (“ЕСПД. Стадии разработки программ и программной документации”)ЕСПД.

§ Требования к транспортировке и хранению

Требования к транспортировке

АИСК должна транспортироваться:

- в составе ПЭВМ, записанный на НЖМД ПЭВМ;

- на НГМД.

Условия транспортировки АИСК в составе ПЭВМ должны соответствовать условиям транспортировки ПЭВМ, требования к которым предъявляются в эксплуатационной документации ПЭВМ или ее составных частей.

Условия транспортировки АИСК на НГМД должны соответствовать условиям транспортировки НГМД, требования к которым предъявляются в эксплуатационной документации НГМД.

Требованию по хранению

АИСК должна храниться:

- в составе ПЭВМ, записанный на НЖМД ПЭВМ;

- на НГМД.

Условия хранения АИСК в составе ПЭВМ должны соответствовать условиям хранения ПЭВМ, требования к которым предъявляются в эксплуатационной документации ПЭВМ или ее составных частей.

Условия хранения АИСК на НГМД должны соответствовать условиям хранения НГМД, требования к которым предъявляются в эксплуатационной документации НГМД.

§ Специальные требования

Требования не предъявляются.

V. Требования к программной документации

§ Требования к составу документации

Состав документации определяется Исполнителем на этапе разработки переч­нем разрабатываемых документов и согласовывается с Заказчиком.

В комплект документации в обязательном порядке должны входить:

- спецификация;

- текст программы;

- руководство оператора;

- загрузочные модули;

- программа и методика испытаний.

§ Требования к оформлению документации

Программная документация должна быть разработана и оформлена в соот­ветст­вии с ЕСПД.

VI. Технико-экономические требования

Трудоемкость разработки, отладки и испытаний АИСК должна быть согласована Испол­нителем и Заказчиком на этапе заключения договора на выполнение работ.

Перечень сокращений

НГМД - накопитель на гибких магнитных дисках

НЖМД - накопитель на жестких магнитных дисках

ОЗУ - оперативное запоминающее устройство

ПО - программное обеспечение

ПЭВМ - персональная электронная вычислительная машина

ТЗ - техническое задание

АИСК- Автоматизированная информационная система “Клиент”

 

ОПИСАНИЕ ЗАДАЧИ.

Наименование задачи:

Автоматизация управления работой дилера по прокату легковых автомобилей

 

Цель работы дилера:

Прокат легковых автомобилей на заказ по каталогу.

Функции дилера:

• Заключение договоров на поставку автомобилей;
• Ведение каталога автомобилей, предлагаемых в прокат;
• Приём заказов у клиентов на прокат автомобилей;
• Работа с клиентами: реклама автомобилей, подготовка сведений о автомобилях, взятых в прокат, анализ прокатов, ведение справочника клиентов;
• Отправка сведений о клиентах в правоохранительные органы;
• Ведение расчётов за автомобили, сданные в прокат;
• Учёт валютного курса.

Бизнес – правила:

• Сведенья о клиентах хранятся 5 лет с момента последнего заказа;
• При отказе от поставленного автомобиля с клиента удерживается 9% суммы оплаты по счёту, данная величина должна регулироваться;
• просрочка предоставления автомобиля клиенту оплачивается фирмой «ЮГ-АВТО» из расчёта 0,2% в день от стоимости проката, данная величина может регулироваться;
• При сдаче автомобиля клиентом после указанных сроков с клиента удерживается штраф: 110% от суммы за прокат за день в день.
• При пропаже автомобиля и неявки клиента на клиента возбуждается уголовное дело по факту угона.
• вся ответственность за автомобиль во время его использования возлагается нВ клиента. И в случае аварии по вине клиента ремонт делается за счёт клиента.

Требования к программе:

Программа должна работать под управлением операционных систем MS Windows 95, MS Windows 98, MS Windows NT, MS Windows 2000, MS Windows XP.

Перечень вводимой информации:

адрес

дата

водительские права

запрос

количество

имя

марка машины

номер

номер и серия паспорта

номер кредитки

отчество

состояние

цвет

цена

фамилия

 

Перечень печатных отчётов:

· номенклатура предлагаемых к прокату автомобилей;

· список клиентов;

· анализ прокатов;

· список заказов;

· счёт на прокат.

Требования к оснащению офиса фирмы компьютерной теникой:

ПЭВМ со следующими характеристиками:

- процессор не ниже Pentium II 500МГц;

- объем ОЗУ не менее 128 Мб;

- НГМД 3,5 (1,44 Мб);

- НЖМД не менее 8 Гб;

- графический адаптер не хуже SVGA 8 Мб;

- монитор не хуже SVGA 0.26, 15 дюймов;

- сетевая плата, совместимая с Ethernet;

- манипулятор типа “мышь”;

- струйный или лазерный принтер формата А4.

Пользователи банков данных.

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

1. Проектирование
2. Реализация
3. Эксплуатация
4. Модернизация и развитие
5. Полная реорганизация

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

Основные категории пользователей и их роль в функционировании банка данных:

§ Конечные пользователи. Это основная категория пользователей, в интересах которых и создаётся банк данных. В зависимости от особенностей создаваемого банка данных круг его конечных пользователей может существенно различаться. Это могут быть случайные пользователи, обращающиеся к БД время от времени за получением некоторой информации, а могут быть регулярные пользователи. В качестве случайных пользователей могут рассматриваться, например, возможные клиенты фирмы, рассматривающие каталог автомобилей, которые доступны для проката, с обобщённым или подробным описанием того или иного автомобиля. Регулярными пользователями могут быть сотрудники фирмы, работающие со специально разработанными для них программами, которые обеспечивают автоматизацию их деятельности при выполнении их должностных обязанностей. Например, менеджер имеет в своём распоряжении программу, которая помогает ему планировать и распределять текущие заказы, контролировать ход их выполнения, заказывать поступление новых автомобилей для новых заказов. Главный принцип состоит в том, что от конечных пользователей не должно требоваться каких-либо специальных знаний в области вычислительной техники и языковых средств.

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

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

Наиболее сложные обязанности возложены на группу администратора БД. В составе группы администратора БД должны быть:

o системные аналитики;

o проектировщики структур данных и внешнего по отношению к банку данных информационного обеспечения;

o проектировщики технологических процессов обработки данных;

o системные и прикладные программисты;

o операторы и специалисты по техническому обслуживании..

Модель данных.

Общие положения

Ядром любой базы данных является модель данных. Модель данных представляет

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

манипулирования данными. С помощью модели данных могут быть представлены

объекты предметной области и взаимосвязи между ними.

Модель данных — совокупность структур данных и операций их обработки.

СУБД основывается на использовании иерархической, сетевой или реляционной

модели, на комбинации этих моделей или на некотором их подмножестве [I].

Рассмотрим три основных типа моделей данных: иерархическую, сетевую и

реляционную.

 

Иерархическая модель данных

 

Иерархическая структура представляет совокупность элементов, связанных

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

отношениями, образуют ориентированный граф (перевернутое дерево).

К основным понятиям иерархической структуры относятся: уровень, элемент

(узел), связь. Узел — это совокупность атрибутов данных, описывающих

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

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

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

только одну вершину (корень дерева), не подчиненную никакой другой вершине

и находящуюся на самом верхнем (первом) уровне. Зависимые (подчиненные)

узлы находятся на втором, третьем и т.д. уровнях. Количество деревьев в

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

К каждой записи базы данных существует только один (иерархический) путь

от корневой записи.

 

Сетевая модель данных

В сетевой структуре при тех же основных понятиях (уровень, узел, связь)

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

 

 

Реляционная модель данных

 

Понятие реляционный (англ. relation — отношение) связано с разработками

известного американского специалиста в области систем баз данных Е. Кодда.

Эти модели характеризуются простотой структуры данных, удобным для

пользователя табличным представлением и возможностью использования

формального аппарата алгебры отношений и реляционного исчисления для

обработки данных.

Реляционная модель ориентирована на организацию данных в виде двумерных

таблиц. Каждая реляционная таблица представляет собой двумерный массив и

обладает следующими свойствами:

. каждый элемент таблицы — один элемент данных;

. все столбцы в таблице однородные, т.е. все элементы в столбце имеют

одинаковый тип (числовой, символьный и т.д.) и длину;

. каждый столбец имеет уникальное имя;

. одинаковые строки в таблице отсутствуют;

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

Отношения представлены в виде таблиц, строки которых соответствуют кортежам

или записям, а столбцы — атрибутам отношений, доменам, полям.

Поле, каждое значение которого однозначно определяет соответствующую

запись, называется простым ключом (ключевым полем). Если записи однозначно

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

имеет составной ключ.

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

ввести в состав ключа второй таблицы (возможно совпадение ключей); в

противном случае нужно ввести в структуру первой таблицы внешний ключ —

ключ второй таблицы.

 

Процесс проектирования.

Построение ДПД:

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

 

Прокат автомобилей [1]
Сбор заявок [1.1]
Прием заявок [1.1.1]
Анализ заявок [1.1.2]
Сохранение заявок [1.1.3]
Сбор сведений о клиенте [1.2]
Прием информации о клиенте [1.2.1]
Анализ информации о клиенте [1.2.2]
Сохранение информации о клиенте [1.2.3]
Сбор сведений о наличии авто [1.3]
Запись сведений о наличии ВС [1.3.3]
Анализ сведений о наличии авто [1.3.2]
Прием сведений о наличии авто [1.3.1]
Запрос инфо [1.4]
проверка информации о клиенте [1.5]
подготовка сведений о клиенте [1.5.1]
проверка сведений о клиенте [1.5.2]
сохранение данных [1.5.3]
Передача машины клиенту [1.7]
приём машины [1.7.1]
Прием сведений [1.7.2]
Подготовка данных для передачи и передача [1.7.3]
регистрация машины на данного клиента [1.6]
Оформление заказа [1.6.3]
Подбор авто [1.6.1]
регистрация машины на клиента [1.6.2]

 

 

А) 1 уровень

 

В) 2 уровень

С) 3 уровень

1) Сбор заявок

2) Сбор сведений о клиенте

3) Сбор сведений о наличии авто

4) Проверка информации о клиенте

5) Регистрация автомобиля на данного клиента

6) Передача автомобиля клиенту

Словарь данных.

Управленческим инструментарием разработки при проектировании БД является словарь данных (СД).

Внедрение БД на любом предприятии занимает довольно продолжительное время. Её расширение происходит по мере разработки и интеграции используемых прикладных программ. В процессе эксплуатации вводятся новые элементы данных, а те, которые использовались при проектировании БД, могут быть изменены.

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

Словарь данных призван помогать пользователю в выполнении следующих функций:

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

 

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

СД можно рассматривать как «метабазу данных», в которой хранится информация о БД.

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

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

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

Примером СД может быть реляционная модель данных.

 

Список литературы.

1) «Эффективная работа с СУБД» Рубен Ахаян, Андрей Горев, Сергей Макашарипов, Издательство «Питер», 1997 год

2) «Базы данных» Карпова, Издательство «Питер», 2003 год

3) «Разработка программных проектов на основе RUP» Гари Поллис, Лиз Огастин, Крис Лоу, Джас Мадхар, Издательство «Бином», 2005 год

Введение.

 

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

Важная категория интегрированных решений – система обработки информации предприятия. Такую систему мы привыкли называть АСУ – автоматизированная система управления.

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

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

Современные СУБД в основном являются приложениями Windows, так как данная

среда позволяет более полно использовать возможности персонально ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных ПК

обусловил не только широкий переход к среде Windows, где разработчик

программного обеспечения может в меньше степени заботиться о

распределении ресурсов, но также сделал программное обеспечение ПК в

целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ.

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

можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland

Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз

данных Microsoft SQL Server и Oracle, используемые в приложениях,

построенных по технологии «клиент-сервер». Фактически, у любой

современной СУБД существует аналог, выпускаемый другой компанией, имеющий

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

работать со многими форматами представления данных, осуществлять экспорт

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

Общепринятыми, также, являются технологи, позволяющие использовать

возможности других приложений, например, текстовых процессоров, пакетов

построения графиков и т.п., и встроенные версии языков высокого уровня

(чаще – диалекты SQL и/или VBA) и средства визуального программирования

интерфейсов разрабатываемых приложений. Поэтому уже не имеет

существенного значения на каком языке и на основе какого пакета написано

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

того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD

(от английского Rapid Application Development), основанная на широко

декларируемом в литературе «открытом подходе», то есть необходимость и

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

разработки более гибких и мощных систем обработки данных. Поэтому в одном

ряду с «классическими» СУБД все чаще упоминаются языки программирования

Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать

необходимые компоненты приложений, критичные по скорости работы, которые

трудно, а иногда невозможно разработать средствами «классических» СУБД.

Современный подход к управлению базами данных подразумевает также широкое

использование технологии «клиент-сервер».

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

 

Под жизненным циклом ПС понимают весь период его разработки и эксплуатации (использования), начиная от момента возникновения замысла ПС и кончая прекращением всех видов его использования [1 - 4]. Жизненный цикл включает все процессы создания и использования ПС (software process). Различают следующие стадии жизненного цикла ПС (см. рис. 1): разработку ПС, производство программных изделий (ПИ) и эксплуатацию ПС.

 

.

Разработка начинается с выработки требований к ПИ. На эту фазу приходится, как правило, 50% стоимости и 32% трудозатрат.

Фаза использования начинается с того момента, как изделие передается пользователю.

На этой фазе обычно выполняется обучение персонала, внедрение и настройка.

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

Процесс сопровождения продолжается параллельно эксплуатации ПИ. На расширение функциональных возможностей ПИ – 78% времени, на выявление ошибок – 17%. Обучение расширенным возможностям – 5%.

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

Особенности эти проявляются на этапах создания и эксплуатации.

Приведем это в форме таблицы.

 

Наименование этапов	Содержание работы
Производственно-техническое назначение	ПИ
1. Разработка	Определение требований пользователя. Определение конструктивных элементов. Проектирование элементов. Изготовление опытного образца и его испытания. Создание технологии массового производства.	-----//-----   -----//-----   -----//----- реализация и тестирование __________
2. Ввод в эксплуатацию	Массовое производство	копирование
3. Эксплуатация и обслуживание	Постановка пользователю.
Техническое обслуживание (ремонт). Возвращение изделия на доработку. Расширение функциональных возможностей.	___________ сопровождение сопровождение
4. Снятие с эксплуатации	Физический износ Моральный износ	__________ -----//-----

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

Начальный этап проектирования ПИ состоит из следующих процессов:

1. Анализ и разработка требований к ПИ.

2. Определение целей создания ПИ.

3. Разработка внешних спецификаций проекта.

I процесс.

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

а) выявить наличие информации, необходимой для выполнения планируемых функций;

б) определить трудоемкость и стоимость предстоящей работы;

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

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

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

Можно установить две фазы в выработке требований.

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

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