Содержание:

Введение……………………………………………………………....3

Жизненный цикл ПС…………………………………………………5

Техническое задание…………………………………………………9

Описание предметной области…………………………………......14

Описание, постановка задачи и разработка бизнес-правил………18

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

Модель данных………………………………………………………23

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

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

Введение.

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

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

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

• Обеспечивать получение общих или детализированных данных по итогам работы;

• Позволять легко определять тенденции изменения важнейших показателей;

• Обеспечивать получение информации, критической по времени, без существенной задержки;

• Выполнять точный и полный анализ данных.

Современные СУБД в основном являются приложениями 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-ая фаза выработки требований пользователя. На этой фазе вырабатываются требования к входным данным, информационным потокам, выходным данным, документации, среде, вычислительным ресурсам.

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

Требования являются определенными в том объеме, в котором они фиксируются в документации.

За полноту и точность сформулированных требований к ПИ отвечает пользователь. Проектировщик отвечает за качество описания требований и их реализуемость.

II процесс. Разработка и описание целей (т.е. процесс разработки в проектировании).

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

При описании целей возможно возникновение следующих ошибок:

1. Противоречивость в описании сформулированных целей;

2. Наличие поверхностно выявленных целей, не отражающих специфических особенностей разрабатываемого ПИ (например, зарплата);

3. Цели создания ПИ с точки зрения пользователя (цели продукта) и цели проекта (с точки зрения проектировщика) противоречивы (т.е. несогласованность разработки и пользователя).

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

1. Краткое описание. В нем кратко определяется общее назначение разрабатываемого ПИ и его функций.

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

3. Подробное описание функциональных задач. Оно характеризует однозначное восприятие требований пользователей – разработчиков.

4. Документация – определяются состав документов, выдаваемый каждому пользователю.

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

6. Совместимость. Указываются стандарты, которым необходимо следовать в процессе разработки, а также другие программные продукты, с которыми разрабатываемое ПИ должно быть совместимо.

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

8. Безопасность. Формируются цели в отношении обеспечения безопасности ПИ (сохранение информации, пароль, гриф секретно).

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

10. Установка. Описываются методы и средства настройки ПИ на конкретные условия эксплуатации (требования на ограничения по настройке, разделение на 5 человек).

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

а) среднее время наработки на сбой для каждого вида сбоя (ПИ, пользователь, отдельная функция) и степень важности сбоя (для ПО для систем реального времени);

б) среднее время восстановления ПИ после сбоя;

в) цели по числу ошибок ПИ по категориям сложности и время обнаружения;

г) последствия сбоев системы и наиболее важных функций;

д) допустимый объем данных, утрачиваемых во время сбоя и уровень обеспечения безопасности;

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

ж) возможности обнаружения ошибок пользователя и аппаратуры, а также восстановления работоспособности.

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

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

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

III процесс. Разработка внешних спецификаций проекта. Упрощенно – это разработка инструкций пользователю.

При их написании разработчик должен решить три проблемы:

1. Доведение до минимума ошибок пользователя;

2. Обнаружение ошибок пользователя в случае их возникновения;

3. Доведение до минимума сложности разрабатываемого программного изделия.

Разработка внешних спецификаций разбивается на 2 части:

1. Предварительный внешний проект.

2. Детальный внешний проект.

Предварительный внешний проект содержит описание функций по составляющим компонентам ПИ (Решить какие функции необходимо описать в инструкции).

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

1. Описание входных данных;

2. Описание выходных данных;

3. Преобразование системы (например, обновление массива начисления и удержания по заработной плате после расчета за месяц, при перерасчете. Оно должно быть написано с точки зрения пользователя);

4. Характеристика надежности. Описывается влияние всех возможных отказов функции на систему.

5. Эффективность. Описываются все ограничения (память, время и т.д.).

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

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

Предметная область:

Прокат автомобилей.

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

1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Надежность АИСК должна быть обеспечена правильностью алгоритмических решений и программирования. Время восстановления АИСК после отказа не должна превышать 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 (“ЕСПД. Стадии разработки программ и программной документации”)ЕСПД.

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

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

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

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

- на НГМД.

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

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

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

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

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

- на НГМД.

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

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

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

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